기능보다 흐름을,
사용자 관점을 먼저 생각합니다

모노레포 전환 — 코드 중복을 구조로 해결하다

배경 — 서비스 앱과 어드민 앱을 별도 레포로 운영하며 시작했지만, 기능이 늘어날수록 컴포넌트·타입·API 인터셉터가 두 레포에 중복되기 시작했습니다.

판단 — pnpm + Turborepo 기반 모노레포로 구조를 전환하고, 공유해야 할 것과 앱별로 남겨야 할 것을 먼저 구분했습니다.

트레이드오프 — 전환 후 CI/CD가 각각 독립 빌드되며 이중 빌드 문제가 새로 생겨, Remote Cache와 git diff 기반 Selective Build로 해결했습니다.

⚠ 재현 다이어그램 — 실제 레포 구조·패키지명은 예시로 재구성

모바일 ARS 인증 실패 — 폴링을 서버로 이관하다

배경 — Galaxy 등 일부 모바일 기기에서 전화 앱으로 전환하면 JS 실행이 정지되어 클라이언트 측 폴링이 끊기고, 인증 결과를 받지 못해 실패율 100%가 발생했습니다.

해결 — Next.js API Route 프록시를 도입해 서버가 백엔드 ARS API를 대신 호출하고 결과를 저장하도록 구조를 변경했습니다. 클라이언트는 앱 복귀 후 attemptId로 결과만 조회하면 되도록 만들어, 폴링 자체를 서버로 이관했습니다.

⚠ 재현 다이어그램 — 실제 코드·화면 미사용

프론트엔드 모니터링 체계 — 단계적으로 고도화하다

배경 — FE 로그 관리가 없어 오류 발생 시 원인 파악이 어려웠고, Slack 알림 연동 후에도 메시지가 시간이 지나면 소실됐습니다.

해결 — CloudWatch → Slack → Sentry 순으로 단계적으로 개선했습니다. 이벤트 한도를 고려해 GET을 제외한 POST/PUT/PATCH/DELETE와 FE 에러만 선별 수집하고, 발생 페이지·사용자 정보·Request/Response까지 노출되도록 커스터마이징했습니다.

⚠ 재현 목업 — 실제 데이터·화면 아님

배경 — SM Pay 관리자 페이지는 다양한 기능을 제공하지만, 그만큼 UI가 복잡하고 페이지마다 이벤트 핸들러가 많아 사용자가 원하는 작업을 하기까지 여러 단계의 조작이 필요했습니다. 클릭, 폼 입력, 필터링 등 반복적인 UI 조작이 사용자의 작업 효율을 떨어뜨리는 지점이었습니다.

접근 — 각 페이지에는 이미 특정 기능을 수행하는 API가 구축되어 있다는 점에 착안해, UI 조작 대신 자연어 대화로 그 페이지의 작업을 수행할 수 있는 구조를 설계했습니다. Groq API를 활용해 사용자의 자연어 요청을 해석하고, 해당 페이지에 이미 존재하는 API를 호출하도록 연결하는 방식입니다. 기존 UI를 대체하는 것이 아니라, 복잡한 이벤트 핸들러 체인을 자연어라는 더 단순한 인터페이스로 우회하는 접근입니다.

현재 상태 — 일부 페이지에 프로토타입을 적용해 동작을 검증했으며, 프로덕션 반영 전 단계입니다. 페이지별로 API 스펙이 상이해, LLM이 각 페이지의 API 컨텍스트를 정확히 이해하고 적절한 파라미터로 호출하도록 만드는 것이 핵심 과제입니다.

목표 — 사용자가 UI를 조작하는 대신, 채팅창에 원하는 작업을 말하는 것만으로 페이지 내 작업을 완료할 수 있는 경험을 제공하는 것입니다.

최종 목표 — 유료 AI API를 활용하여 모든 작업을 AI로 대체할 수 있도록 하는 것입니다.

⚠ 재현 다이어그램 — 실제 API·페이지 구조는 예시로 재구성

💬 실제 프로토타입 대화 화면 — 테스트 데이터 사용

Redux → React Query + Recoil 전환으로 상태 흐름을 단순화하고 신규 기능 개발 속도를 개선했습니다. 카카오맵 기반 창고 탐색 UX도 함께 개선했습니다.

B2B 에너지 대시보드를 신규 구축 단독 담당했습니다. 실시간 에너지 사용량 시각화 UI를 구현했습니다.

배경 — AI 모델을 활용해 LLM을 붙이고, 이를 학습시켜 블로그 요약·할 일 자동 체크 등 다양한 기능을 수행하는 agent AI로 발전시키는 것이 목표입니다.

작업 — 기존 inote-server(NestJS)는 그대로 유지하고, Python + Groq(추후 유료 모델로 교체 예정) 기반으로 LLM 전용 서버를 별도로 구성했습니다.

구현 — Groq API로 SSE 스트리밍 채팅을 구축해 응답을 실시간으로 흘려보내도록 만들었습니다. 사용자가 지금 작성 중인 글의 제목·카테고리를 매 요청마다 함께 보내 LLM이 "지금 쓰고 있는 글"을 인지한 채로 대화하도록 프롬프트 구조를 설계했고, 대화는 글쓰기 세션·일반 세션으로 나눠 저장하고 검색까지 붙였습니다. 최근에는 글쓰기 에디터(Tiptap)에 표 편집 툴바(행·열 추가/삭제, 셀 병합/분할, 표 삭제)를 추가했고, 카테고리 관리에 드래그 이동과 낙관적 업데이트를 적용했습니다. FE는 Vitest·Testing Library·MSW로 305개 테스트를 작성했고, 구현을 일부러 망가뜨려 테스트가 실패하는지 확인하는 방식(변이 확인)으로 검증하고 있습니다.

무료 호스팅 한도와 DB 이전 — 인프라를 다시 설계하다

배경 — Render 무료 플랜은 월 750시간 한도인데, BE와 AI 서버 두 개를 상시 깨워 두다 보니 이 한도를 초과했습니다.

판단 — AI 서버만 Vercel(Python/FastAPI)로 옮기기로 했습니다. 대안으로 검토했던 Koyeb은 가입 시점에 무료 플랜이 없어 제외했습니다.

트레이드오프 — DB도 Neon에서 Supabase로 옮기는 과정에서, Neon 무료 플랜의 콜드 스타트(약 5~6초)가 Prisma 기본 연결 타임아웃(약 5초)보다 길어 P1001 오류를 겪었습니다. 어긋나 있던 마이그레이션 3개를 테이블 21개 기준 단일 baseline으로 정리했는데, 배포 순서를 잘못 잡아 실패한 마이그레이션 기록이 새 마이그레이션을 막는 P3009 오류까지 겪었고, 원인을 추적해 해결했습니다.

결과 — 백업 → COPY 복원 → 행 수·내용 해시 대조로 데이터를 옮겨 BE 195행, AI 21행 모두 일치함을 확인했습니다. 처음엔 AI 대화 DB를 BE DB에 합치려 했지만, 서버리스 AI 서버가 BE의 사용자·계정·글 데이터까지 읽을 수 있게 되는 권한 문제와 수명주기 차이 때문에 별도 Supabase 프로젝트로 분리하는 쪽으로 판단을 바꿨습니다.

다음 과제 — 한국어 임베딩 모델(KURE-v1) 기반 기능입니다. 임베딩은 글을 "뜻이 비슷하면 가까운 숫자 묶음(벡터)"으로 바꾸는 방식으로, 이를 이용해 관련 글 추천 → 카테고리 제안·유사 글 알림 → 내 글 기반 AI 답변(RAG) 순으로 만들어 갈 계획입니다. 임베딩 서비스와 벡터 저장·동기화는 로컬에서 구현해, 비공개 글이 다른 사용자 결과에 나오지 않는 것까지 실제 데이터로 확인했고(운영 배포 전), 지금은 관련 글 추천 API를 만들고 있습니다. 공개 범위는 BE가 판정해 "요청자가 볼 수 있는 글 목록"만 AI에 넘기고 AI는 그 안에서만 순위를 매기는 구조라, AI가 후보 밖의 글을 돌려줄 수 없습니다. 다만 내 비공개 글까지 AI가 검색하려면 AI 서버가 요청자를 검증해야 하는데 현재는 FE가 전달한 user_id를 그대로 신뢰하고 있어, RAG에 앞서 인증 토큰 연동을 먼저 해결할 계획입니다.

배경 — 4년간 프론트엔드만 다뤄오면서, 백엔드·인프라 판단은 항상 다른 사람의 몫이었습니다. 이 경계를 스스로 넘어보고 싶어 가계부·자산관리 서비스를 기획하고, Next.js(FE)와 NestJS(BE)를 완전히 분리한 실무형 구조로 직접 만들기 시작했습니다.

판단 — 혼자 모든 걸 다루려 하기보다, AI와의 협업 자체를 구조화했습니다. Claude Code는 아키텍처 설계와 구현을, Cursor는 구현 이후 QA와 코드 리뷰를 전담하도록 역할을 분리해 운영했습니다.

막힌 지점 — FE(Vercel)와 BE(Render)를 서로 다른 도메인에 배포하면서 크로스 도메인 쿠키 인증 문제에 부딪혔고, AI와 함께 원인을 추적하며 해결했습니다.