클로드 코드(Claude Code)나 커서(Cursor)로 이틀 만에 MVP를 완성했다. 배포 버튼을 누르기 직전, 무엇을 확인해야 할까.
저는 12개 사이트를 바이브코딩으로 직접 만들고 운영하고 있다. 초반에는 "일단 배포하고 나중에 고치자"는 방식으로 진행했다가 출시 다음날 환경변수가 빠져서 결제 오류가 났고, 이틀 뒤에는 SQL 쿼리가 인덱스를 타지 않아 서버 응답이 30초로 치솟은 경험이 있다. 모두 출시 전 30분이면 확인할 수 있는 항목이었다.
이 글은 바이브코딩 MVP를 프로덕션에 올리기 전에 혼자 빠르게 돌려볼 수 있는 42개 체크리스트를 6단계로 정리한다. AI가 생성한 코드는 구문이 맞아도 배포 환경에서 실패하는 경우가 많다. 체크리스트는 그 간격을 메우는 도구다.
바이브코딩 방식으로 만든 프로젝트는 전통적인 개발 방식과 몇 가지 측면에서 다르다. 코드 생성 속도가 빠른 대신 각 파일이 어떻게 연결되는지를 개발자가 직접 확인할 기회가 줄어든다. 클로드 코드가 라우터를 생성할 때 인증 미들웨어를 빠뜨리는 경우가 있고, 커서가 환경변수 이름을 미묘하게 다르게 참조하는 경우도 있다.
출시 전 체크리스트가 특히 필요한 이유는 세 가지다.
- AI 코드는 전체 맥락을 모른다. 각 파일을 따로 생성하다 보면 모듈 간 연결이 어긋나거나 타입이 맞지 않는 경우가 생긴다.
- 환경변수 누락은 배포 직후에 터진다. 로컬에서는
.env.local이 있어서 잘 동작하지만 프로덕션에는 해당 변수가 없어서 즉시 오류가 난다. - 성능 문제는 트래픽이 생긴 후에야 드러난다. N+1 쿼리나 인덱스 누락은 요청이 많아질 때 서버를 마비시킨다.
아래 42개 항목을 프린트하거나 PR 템플릿에 넣어두고 배포 직전마다 체크하는 것을 권장한다. 처음에 어색해도 3~4번 반복하면 몸이 기억한다.
배포 전 가장 먼저 확인할 것은 코드가 올바른 구조로 연결되어 있는가다. AI가 파일을 여러 번에 나눠 생성하다 보면 임포트 경로가 어긋나거나 불필요한 파일이 남는 경우가 생긴다.
바이브코딩으로 빠르게 만든 프로젝트에서 가장 자주 발생하는 보안 문제는 환경변수 누락이나 시크릿 하드코딩이다. 깃허브에 올리기 전에 반드시 확인해야 한다.
바이브코딩으로 생성된 코드에서 성능 문제는 숨어있다가 사용자가 늘어나는 시점에 터진다. 트래픽이 없는 상태에서는 N+1 쿼리도 빠르게 느껴진다. 배포 전에 직접 확인하는 것이 낫다.
바이브코딩 프로젝트에서 외부 API 연동은 개발 환경 테스트 모드로 동작하는 경우가 많다. 프로덕션 전환 시 이 설정을 바꾸지 않으면 실제 결제가 테스트 결제로 처리되거나, 개발 환경 데이터가 실 사용자에게 노출된다.
AI가 생성한 UI는 기능은 동작하지만 오류 상태나 빈 상태를 처리하지 않는 경우가 많다. 사용자가 처음 만나는 경험이 오류 화면이나 빈 화면이라면 이탈률이 높아진다.
서비스가 올라간 후 무슨 일이 벌어지는지 알아야 빠르게 대응할 수 있다. 바이브코딩으로 만든 MVP는 모니터링 설정 없이 배포되는 경우가 많다. 최소한의 관측 도구를 먼저 연결해야 한다.
혼자 개발한다면 이 체크리스트를 배포 직전에 한 번 훑는 것으로 충분하다. 팀이 있다면 깃허브 릴리스 노트나 PR 템플릿에 포함시켜 배포 담당자가 매번 확인하도록 만드는 것이 더 효과적이다.
실제 적용할 때 추천하는 방법 세 가지:
- 배포 전 15분 체크: 배포 버튼을 누르기 전 타이머를 15분 맞추고 위 42개 항목을 훑는다. 처음에는 30분 이상 걸리지만 익숙해지면 10분이면 된다.
- 깃허브 릴리스 체크박스:
RELEASE_CHECKLIST.md를 레포지터리에 두고 릴리스마다 새 이슈를 만들어 항목을 복붙한다. 이슈가 닫혀야 배포한다는 규칙을 팀과 공유한다. - CI 자동화 연결: 린트, 타입 검사, 취약점 스캔(
npm audit), 빌드는 CI/CD 파이프라인에 자동화한다. 사람이 매번 확인하지 않아도 되도록 만들면 체크리스트가 더 잘 지켜진다.
42개 항목 모두를 첫 배포부터 완벽하게 충족할 필요는 없다. 핵심은 환경변수 누락, 시크릿 하드코딩, 프로덕션 키 미전환 세 가지다. 이 세 가지만 놓치지 않으면 가장 자주 발생하는 초기 오류를 막을 수 있다.
바이브코딩 MVP를 배포할 때 가장 자주 놓치는 항목이 뭔가요?
실제 경험을 기준으로 보면 환경변수 미설정이 가장 흔하다. 로컬에서는 .env.local이 있어서 잘 동작하지만, 배포 플랫폼에 같은 변수를 등록하지 않으면 배포 직후 오류가 난다. 두 번째는 결제 API 테스트 키 미전환이다. 스트라이프 테스트 키로 개발하다가 프로덕션 키로 바꾸지 않으면 실제 결제가 처리되지 않는다. 세 번째는 데이터베이스 마이그레이션 누락이다. 로컬에서 스키마를 변경했지만 프로덕션 DB에는 적용하지 않은 경우다.
42개가 너무 많은데, 절대 놓치면 안 되는 5개만 고르면?
① 환경변수 완전 등록 — 프로덕션 배포 환경에 필요한 모든 변수를 등록한다. ② 시크릿 하드코딩 없음 — grep -r "password\|secret\|api_key" .로 소스코드를 확인한다. ③ 결제·외부 API 프로덕션 키 전환 — 테스트 모드가 아닌 실제 모드로 전환한다. ④ 프로덕션 빌드 통과 — npm run build가 에러 없이 완료되는지 확인한다. ⑤ 인증 미들웨어 적용 확인 — 로그인이 필요한 엔드포인트가 실제로 보호되고 있는지 수동으로 테스트한다.
클로드 코드가 만든 코드에서 보안 문제가 실제로 자주 발생하나요?
빈도보다 패턴이 중요하다. 직접 경험한 것으로는 ① 인증 미들웨어를 라우터에 연결하지 않고 별도 파일로만 만들어두는 경우 ② 폼 데이터를 서버에서 검증 없이 바로 DB에 저장하는 경우 ③ 에러 메시지에 스택 트레이스나 DB 스키마 정보를 그대로 포함해 응답하는 경우가 있었다. 이 패턴들은 AI가 코드를 잘못 만든 게 아니라 전체 흐름을 보지 못해서 발생한다. 파일별로 보면 맞지만 연결하면 빠진다.
모니터링 도구가 없어도 MVP를 출시해도 되나요?
출시 자체는 가능하지만, 무슨 일이 벌어지는지 알 수 없는 상태로 운영하는 것은 위험하다. 최소한 Sentry 무료 플랜 하나만 연결해도 런타임 오류 알림을 이메일로 받을 수 있다. 설치는 npm install @sentry/nextjs와 대시보드에서 DSN을 복사해 환경변수에 넣는 것으로 끝난다. 첫 실사용자가 오류를 만났을 때 개발자가 모르고 있는 상황을 막는 것이 핵심이다.
체크리스트를 매 배포마다 다 확인하면 배포가 너무 느려지지 않나요?
처음에는 30~40분 걸리지만 익숙해지면 10~15분으로 줄어든다. 더 중요한 점은 42개 중 절반 이상은 CI/CD에 자동화할 수 있다는 것이다. 린트, 타입 검사, 빌드, 취약점 스캔은 깃허브 액션에 넣으면 사람이 매번 확인할 필요가 없다. 나머지 수동 확인 항목(결제 키 전환, 웹훅 등록, DB 마이그레이션)은 한 번 놓치면 복구 비용이 훨씬 크다. 15분의 확인이 몇 시간의 장애 대응보다 낫다.
