"이거 누가 좀 해줬으면" — 그 말이 제품이 된다
스프린트가 끝날 때마다 반복되는 그 장면이 있다. "changelog 누가 쓸 거야?" 침묵. Jira 티켓 업데이트 안 했다고 PM이 Slack DM을 보낸다. 422 에러 메시지는 읽어도 뭔지 모르겠다. 이 불편함들의 공통점은 하나다. 누구나 겪는데, 아무도 해결하려 안 한다는 것. 최근 dev.to에 올라온 세 편의 빌드 로그는 그 '아무도'를 자처한 개발자들의 이야기다. 그리고 더 흥미로운 건, 세 프로젝트 모두 거의 동일한 기술 패턴으로 수렴한다는 점이다.
케이스 1: changelog를 세 개 동시에 쓰는 AI — ShipLogs
ShipLogs 빌더가 짚어낸 문제는 정교하다. changelog 작성이 귀찮은 게 아니라, 같은 PR을 보고 개발자용·PM용·고객용 세 가지 문서를 따로 써야 한다는 사실이 진짜 고통이다. 기존 도구들(Release Drafter, semantic-release 등)은 하나의 포맷만 지원한다. 컨텍스트를 이해하는 게 아니라 PR 타이틀과 레이블을 그냥 긁어온다.
해결 구조는 간결하다. GitHub webhook → Next.js API Route → Claude Sonnet → Supabase → 대시보드. 핵심은 동일한 PR 데이터를 세 개의 시스템 프롬프트로 처리하는 것이다. 'Developer 모드'는 breaking change와 마이그레이션 스텝을, 'Customer 모드'는 혜택 중심의 블로그 글을 뽑아낸다. Claude의 Zod 기반 structured output 덕분에 응답이 항상 타입 안전한 JSON으로 내려온다. 프롬프트 캐싱(cache_control: ephemeral)으로 시스템 프롬프트를 재사용하면 요청당 비용이 약 $0.06 — 무료 티어 운영도 충분히 지속 가능한 수준이다.
케이스 2: Slack 메시지로 Jira를 자동 닫는 봇 — NudgeBot
NudgeBot 빌더의 인사이트는 더 예리하다. 개발자는 이미 Slack에서 자연어로 업무 상태를 말하고 있다. 그걸 또 Jira에 들어가서 클릭하는 건 순수한 컨텍스트 스위칭 비용이다. 이 프로젝트는 그 간극을 없앤다.
기술적으로 가장 흥미로운 부분은 Slack의 3초 응답 제한 문제 해결 방식이다. Slack Events API는 webhook을 받고 3초 안에 200 OK를 돌려주지 않으면 재시도를 때린다. OpenAI나 Jira API 호출이 3초 안에 끝날 리 없다. 해법은 Vercel의 waitUntil 함수 — 즉시 200을 반환하고, AI 파이프라인은 백그라운드에서 실행한다. 서버리스 함수 수명을 연장하는 이 패턴은 Next.js on Vercel에서 비동기 AI 작업을 다룰 때 반드시 알아둬야 할 레시피다.
할루시네이션 제어도 치밀하다. "내일 헤더 작업 시작할게요"라는 말에 AI가 '헤더 티켓'을 닫아버리면 재앙이다. Claude 3.5에게 단순히 "매칭 여부"를 묻는 대신, 0.0~1.0 사이의 confidence_score와 reasoning을 JSON으로 강제 반환시킨다. 0.95 이상일 때만 자동 처리, 그 아래는 사용자에게 확인 요청을 보낸다. AI 자동화에서 신뢰를 설계하는 방식의 교과서 같은 예시다.
케이스 3: 4xx 에러를 한국어로 설명해주는 프록시 — Inspekt
Inspekt는 가장 단순하지만 가장 즉각적인 DX 개선 사례다. 422 Unprocessable Entity를 마주할 때 느끼는 그 막막함 — "뭐가 잘못됐는지 알면 고치지" — 을 직접 겨냥한다. API 요청을 Inspekt 프록시로 라우팅하면, 실패 응답에 _diagnosis 필드가 추가된다. LLM이 스키마와 페이로드를 분석해 "이 필드 타입이 틀렸어요"를 바로 알려주는 것이다.
Vercel Edge Runtime 위에 올려 레이턴시를 최소화하고, 성공 응답은 그냥 패스스루 — 개발 흐름에 최소한으로 개입하는 설계 철학이 인상적이다.
세 프로젝트가 공유하는 설계 언어
표면적으로는 changelog 툴, Slack 봇, API 프록시로 전혀 다른 제품처럼 보인다. 하지만 아키텍처 레이어를 걷어내면 동일한 패턴이 드러난다.
① 팀 내부의 반복 고통을 정확히 언어화한다. 세 빌더 모두 "우리 팀이 매주 이걸 하는데 이상하지 않아?"라는 질문에서 출발했다. 거창한 시장 조사가 아니라, 본인이 직접 경험한 마찰이 MVP의 스펙이 됐다.
② Next.js App Router + Vercel + AI API 조합이 기본기다. webhook 수신, AI 호출, DB 저장, 대시보드까지 Next.js 단일 레포로 처리한다. 인프라 결정 비용이 제거되니 제품 설계에 집중할 수 있다.
③ AI 출력의 신뢰를 설계한다. 단순히 LLM에게 질문하는 게 아니라, structured output(Zod), confidence scoring, prompt caching 등으로 출력의 예측 가능성과 비용을 동시에 통제한다. "AI가 하겠지"가 아니라 "AI가 이 범위 안에서만 하도록" 설계하는 것이다.
1인 개발자에게 주는 시사점
이 세 케이스가 보여주는 가장 중요한 교훈은 제품화의 진입 장벽이 낮아졌다는 것이다. 하지만 그게 곧 아무나 성공한다는 뜻은 아니다. 오히려 기술 스택이 평준화될수록 '어떤 문제를 골랐는가'와 '신뢰를 어떻게 설계했는가'가 차별점이 된다.
ShipLogs의 free tier guardrail(1 repo, 3 changelogs/month) 설계는 작지만 중요한 비즈니스 판단이다. AI 비용은 사용자 수와 선형으로 증가하기 때문에, 무료 사용자 10,000명이 $6K/월 손실이 될 수 있다. 이를 $1.8K로 줄이는 캡 설계는 단순한 기능 제한이 아니라 지속 가능성을 위한 프로덕트 결정이다.
NudgeBot의 audit trail 기능도 마찬가지다. AI가 티켓을 자동으로 닫는다는 건 PM 입장에서 블랙박스다. 티켓에 "NudgeBot이 @Aditya의 Slack 메시지를 기반으로 완료 처리했습니다"라는 코멘트를 남기는 것은 기술적으로 단 하나의 API 호출이지만, 팀 내 신뢰를 만드는 UX 결정이다.
전망: "AI 미들웨어" 계층의 부상
세 제품의 공통 구조를 추상화하면 하나의 패턴이 보인다. 기존 도구(GitHub, Slack, Jira, REST API)와 사용자 사이에 AI 레이어를 끼워 넣는 것. 이 AI 미들웨어는 데이터를 변환하거나(ShipLogs), 의도를 파악하거나(NudgeBot), 오류를 해석한다(Inspekt).
이 패턴은 앞으로 더 많은 영역에서 복제될 것이다. 코드 리뷰 코멘트를 자동으로 팀 위키에 정리하는 봇, 회의 메모에서 Linear 이슈를 자동 생성하는 도구, CI 실패 로그를 Slack으로 번역해주는 프록시 — 모두 같은 설계 패턴 위에 있다.
중요한 건 이 기회가 대형 팀이나 전문 AI 회사만의 것이 아니라는 점이다. Next.js + Vercel + Claude/OpenAI 조합은 주말 프로젝트를 지속 가능한 SaaS로 만들기에 충분한 스택이다. 시작점은 여전히 같다. 지금 팀 안에서 가장 자주 "이거 누가 좀 해줬으면"이라는 말이 나오는 그 지점.