AI 코딩 도구가 이토록 빨라진 지금, 가장 무서운 건 '잘못된 것을 빠르게 만드는 능력'이다. CB Insights의 2024년 데이터에 따르면 스타트업 실패의 43%는 나쁜 코드 때문이 아니다. 충분히 고통스럽지 않은 문제, 아무도 소유하지 않는 실패를 해결하려 했기 때문이다. AI는 이 위험을 제거하지 않는다. 오히려 가속한다.
이 문제를 정면으로 다루는 도구가 최근 dev.to에 소개됐다. product-init은 Claude Code, Codex CLI 등 AI 코딩 에이전트에 붙이는 '하드 게이트 제품 발견 시스템'이다. 에이전트가 첫 번째 코드 라인을 쓰기 전에, 9개의 게이트를 통과하도록 강제한다. 첫 번째 게이트는 기술 스택을 묻지 않는다. 대신 이렇게 묻는다. "이게 실패하면 누가 해고되는가?" "사용자가 이 제품을 고용하는 Job은 무엇인가?" JTBD 정의가 없거나 Kill 기준이 빠져 있으면 파이프라인은 그냥 멈춘다. --skip 플래그는 없다.
9개 게이트는 Discovery Constitution(발견 헌장)부터 72시간 모니터링 Warranty까지, Clayton Christensen의 JTBD, Marty Cagan의 4가지 리스크 모델, Amazon PR-FAQ, Basecamp Shape Up 등 검증된 프레임워크를 AI 워크플로우 위에 겹쳐 놓은 구조다. 저자는 이 시스템으로 AI 기반 HR 인터뷰 제품을 단 한 세션에 배포했다. 랜딩 페이지, 인터뷰 룸, 후보자 대시보드, PDF 리포트, 프로덕션 배포, 핸드오프 패키지까지. 중요한 건 '완성됐다'는 사실이 아니라, 시스템이 끝까지 "이게 정말 배포될 자격이 있는가"를 물었다는 점이다.
하지만 게이트가 코드 품질 자체를 보장하지는 않는다. 여기서 두 번째 문제가 등장한다. AI가 생성한 코드는 기존 도구로는 잡히지 않는 고유한 버그 패턴을 가진다. 시니어 엔지니어가 리뷰하고, 테스트를 통과하고, 자신 있게 머지한 코드가 6주 후 프로덕션을 두 시간 다운시킨 실제 사례가 같은 날 dev.to에 올라왔다. 범인은 특정 부하 패턴에서만 발현되는 레이스 컨디션이었다. 린터도, SonarQube도, Snyk도 아무것도 잡지 못했다.
이유가 있다. AI 모델의 실패 패턴은 인간 개발자의 그것과 구조적으로 다르다. 존재하지 않는 API를 자신 있게 참조한다. "unlikely"하다고 판단한 엣지 케이스를 조용히 생략한다. async 패턴에서 레이스 컨디션과 unhandled promise rejection을 평균 이상으로 자주 만든다. 그리고 코드베이스 전체와 구조적으로 어긋나는 방식으로 구현하되, 그 불일치는 스케일 이전엔 드러나지 않는다. 현재 프로덕션 코드의 30~50%가 AI 생성임에도, 이 실패 패턴을 전용으로 잡는 도구는 아직 없다. 해당 아티클의 저자가 'Drift'라는 도구를 만들기 시작한 이유다.
세 번째 시각은 더 현실적이다. 같은 dev.to에서 개발자 Petarov는 Claude Code를 사이드킥 삼아 코더 전용 PWA 단어 퍼즐 '7 Coder Words'를 만든 경험을 공유했다. 그의 결론은 냉정하다. Claude는 과설계를 자주 했고, 변수 위치와 이름이 어긋났으며, 사운드 스프라이트 타이밍은 여러 번 수정해도 맞지 않았다. Playwright 테스트도 처음엔 실제로 버튼을 클릭하는 흐름을 이해하지 못했다. 그래도 그는 Claude를 계속 썼다. 픽셀 단위 클릭 핸들링 계산 같은 지루한 작업을 빠르게 처리해주는 공동 편집자로서.
세 글을 겹쳐 읽으면 하나의 패턴이 선명해진다. AI 개발 워크플로우의 실패는 세 개의 서로 다른 층위에서 발생한다. 첫째, 방향의 실패 — 만들 가치가 없는 것을 만든다. 둘째, 품질의 실패 — 기존 도구로 감지되지 않는 패턴으로 코드가 무너진다. 셋째, 협업의 실패 — AI의 한계를 모른 채 맡기면, 나중에 더 많은 시간을 수동 수정에 쓴다. product-init의 9게이트, Drift가 노리는 AI 전용 정적 분석, 그리고 Petarov의 공동 편집자 프레임은 각각 이 세 층위에 대응하는 대안이다.
결국 'AI로 빠르게 만들기'의 진짜 병목은 생성 속도가 아니다. 검증 루프의 설계다. 무엇을 만들지 결정하는 게이트, 생성된 코드의 숨은 패턴을 잡는 레이어, 그리고 AI와 인간이 각자의 강점을 가진 영역에서 협업하는 구조 — 이 세 단계가 없는 AI-First 개발은 그냥 빠른 기술부채 생성기다. 속도는 수단이지 목표가 아니다. 검증 없는 속도는 방향을 잃은 전력 질주일 뿐이다.
앞으로 주목할 방향은 명확하다. product-init 같은 프리-코딩 게이트가 AI 코딩 에이전트의 표준 레이어로 자리잡을 것이고, AI 생성 코드 전용 정적 분석 카테고리가 별도로 형성될 것이다. 디자인-개발 협업 도구들도 단순 코드 생성을 넘어 '검증 흐름을 어떻게 내재화하느냐'를 경쟁 포인트로 삼게 될 것이다. AI 에이전트가 실행 엔진이 된 세상에서, 프로덕트 판단력은 개발자의 마지막 고유 영역이 아니라 첫 번째 설계 의무가 됐다.