Claude Code로 MVP를 만드는 속도는 이제 놀랍지 않다. 진짜 문제는 그 다음이다. localhost:3000에서 작동하던 코드가 프로덕션 URL로 올라가는 순간, 전혀 다른 환경의 규칙들이 작동하기 시작한다. dev.to에 올라온 시니어 백엔드 테크 리드의 'Claude Code 프로덕션 체크리스트'는 이 지점을 정확히 찌른다. 지난 6개월간 수십 명의 비기술 창업자가 Claude Code MVP를 프로덕션에 올리는 과정을 도왔는데, 런칭 후 2주 안에 같은 15가지 문제가 반복해서 터진다는 것이다.
그 중에서도 팀 리드로서 내가 가장 먼저 들여다보는 건 비밀 키 관리와 환경 분리다. .env 파일이 git 히스토리에 한 번이라도 커밋됐다면, 레포가 현재 private이어도 키는 이미 노출된 것이다. 더 흔한 실수는 개발 환경과 프로덕션 환경이 같은 API 키를 공유하는 것—테스트 스크립트 하나가 실제 Stripe 청구를 500건 날리거나, Stripe 웹훅 서명 검증 없이 페이로드를 그대로 신뢰해 누구나 임의 이벤트로 계정에 크레딧을 쌓을 수 있게 된다. 더 황당한 건 sk_test_로 시작하는 테스트 키를 프로덕션에 그대로 올려 '첫 매출'을 축하했다가 3일 뒤 Stripe 잔고가 0원임을 발견하는 케이스다. AI가 생성한 코드는 이런 환경 차이를 기본적으로 모른다.
AI 엔드포인트 레이트 리미팅 부재도 빠짐없이 등장하는 문제다. /api/chat 라우트에 레이트 리밋이 없으면 스크래퍼 하나가 for 루프로 수백 달러의 OpenAI 청구서를 만들어 준다. CORS가 *로 열려 있으면 인증된 사용자로 위장한 요청이 어디서든 들어올 수 있다. 소스맵이 퍼블릭 번들에 포함되면 누구나 Chrome DevTools에서 TypeScript 원본 코드와 OpenAI 프롬프트 로직을 읽을 수 있다. 이 중 어느 것도 코드 자체의 버그가 아니다. 프로덕션 환경이 요구하는 규칙을 아무도 알려주지 않았을 뿐이다.
이 체크리스트가 흥미로운 이유는 단순한 실수 목록이 아니라, Claude Code가 만들어주는 속도와 프로덕션 환경의 복잡성 사이의 간극을 정확히 드러내기 때문이다. AI는 런타임 버전을 핀하지 않고, 데이터베이스 백업을 기본으로 켜지 않으며, 크론잡 모니터링을 세팅하지 않는다. 코드는 빠르게 만들어지지만, 코드 바깥의 운영 맥락은 여전히 사람이 설계해야 한다.
여기서 두 번째 관점이 맞물린다. 같은 dev.to에서 나온 'AI 딜리버리 파이프라인' 아티클은 이 문제를 구조적으로 정면 돌파한다. 핵심 명제는 간단하다: AI는 프로세스가 아니다. AI는 워커다. 파이프라인이 제약하고, 검증하고, 기록하고, 에스컬레이션한다. 채팅 창 하나에 전체 워크플로우를 넣는 방식—요구사항 설명, 레포 분석, 파일 수정, 테스트 실행, 결과 요약—은 소규모 실험에는 통하지만 장기 프로젝트, 공유 레포, 프로덕션 시스템에서는 깨진다.
이 파이프라인이 최소한으로 답해야 할 질문들이 있다. 이 요청이 실행할 만큼 충분히 성숙했는가? AI에게 얼마나 많은 자율성을 줄 것인가? AI가 볼 수 있는 컨텍스트의 범위는 어디까지인가? AI가 변경할 수 있는 것과 없는 것은 무엇인가? 언제 AI가 멈추고 사람에게 물어야 하는가? 작업이 완료됐다는 근거는 무엇인가? 이 질문들에 답하지 않으면 AI는 여전히 채팅창 안에서 즉흥 연주를 하고 있는 것이다. Task Intake, Execution Mode Router, Human Gate, Evidence Contract—이 구조들은 AI를 더 스마트하게 만들기 위한 것이 아니라, 프로젝트가 AI를 더 잘 통제하기 위한 것이다.
세 번째 관점은 Human Gate의 위치 문제다. 많은 AI 워크플로우가 Human-in-the-loop를 최종 승인 단계로만 설계한다. 하지만 이미 AI가 핵심 코드를 수정하고, 외부 액션을 트리거하고, 프로젝트 상태를 오염시키고, PR을 열었다면 최종 승인 버튼은 이미 늦다. 위험한 부작용은 이미 발생했다. 같은 필자의 'Human Gates and Release Boundaries' 아티클은 이 지점을 명확히 한다: 사람은 리스크 경계에 서야 한다, 워크플로우 끝이 아니라. 결제·보안·DB 스키마·프로덕션 배포·비가역적 외부 액션—이런 경계에 Gate가 있어야 한다. PR 머지와 릴리즈 준비와 프로덕션 검증을 하나의 'done'으로 압축하면 프로젝트는 리스크 통제권을 잃는다.
이 세 가지 관점을 팀 리드 입장에서 하나로 엮으면 꽤 명확한 그림이 나온다. Claude Code는 MVP를 빠르게 만들어준다. 하지만 그 속도는 두 가지를 숨긴다. 코드 바깥의 운영 리스크(키 관리, 레이트 리밋, 백업, 모니터링)와 파이프라인 없이 AI에게 넘긴 의사결정 권한이다. 전자는 체크리스트로 막을 수 있다. 후자는 구조로 막아야 한다.
내일 당장 팀에서 써먹을 수 있는 순서로 정리하면 이렇다. 첫째, Claude Code로 만든 코드를 배포하기 전에 환경 변수·웹훅 서명·레이트 리밋·소스맵·런타임 버전 고정을 한 번이라도 직접 확인하라. 이 다섯 가지만 잡아도 런칭 후 2주 안에 터지는 문제의 절반 이상을 막는다. 둘째, 팀이 AI를 쓰는 방식이 여전히 '채팅창 하나에 전부'라면, Task Intake와 Execution Mode 구분부터 시작하라. 모든 작업에 같은 수준의 자율성을 주는 건 가장 위험한 기본값이다. 셋째, Human Gate를 최종 PR 리뷰에만 두지 말고, 결제·보안·배포 경계마다 앞당겨라. 사람이 병목이 되는 게 두렵다면, Gate의 수를 줄이는 게 아니라 Gate의 위치를 리스크 기준으로 재설계하는 것이 맞다.
AI 코딩 도구가 빨라질수록 이 구조의 필요성은 커진다. 모델은 바뀌고, CLI 툴은 바뀌고, MCP와 에이전트 아키텍처는 계속 진화한다. 그 변화 속에서 팀의 내구성 있는 자산은 '더 좋은 AI 도구'가 아니라 태스크를 어떻게 정의하고, 컨텍스트를 어떻게 전달하고, 실행을 어떻게 제약하고, 증거를 어떻게 수집하고, 사람이 언제 개입하는지를 팀이 명시적으로 설계했는가에 있다. Claude Code MVP가 프로덕션에서 버티는가 무너지는가는 코드 품질보다 이 파이프라인 설계의 차이로 갈린다.