MVP 2026.09.14

Codex·Claude로 만든 AI 프로토타입, 상용화할 때 '살릴 코드'와 '버릴 코드'의 기술적 기준

바이브코딩으로 만든 MVP 코드를 외주사에 보여주면 '처음부터 다시 짜야 한다'고 하지만, 실제로는 UI와 도메인 흐름의 60% 이상을 보존할 수 있습니다. 8년 차 풀스택 개발사가 실제 상용화 스프린트에서 재사용하는 영역과 전면 재작성하는 영역의 엔지니어링 기준을 공개합니다.

#큐룸#바이브코딩#AI프로토타입#리팩토링#Nextjs#Django#코드리뷰

AI 프로토타입 상용화 리팩터링: 코드 진단, 경계 분리, 테스트 — 코드 진단 · 경계 분리 · 테스트

Codex나 Claude Code 같은 도구를 다루며 "나도 이제 개발자 없이 혼자 서비스를 만들 수 있겠다"고 느낀 비개발자 창업자분들이 많습니다. 실제로 1~2주 만에 멋진 랜딩 페이지와 작동하는 프로토타입 화면을 만들어냅니다.

하지만 첫 결제 유저를 받거나 투자자에게 시연하기 위해 개발사나 시니어 개발자에게 코드를 보여주면, 열에 아홉은 똑같은 말을 합니다:

*"남이 AI로 짠 스파게티 코드는 유지보수가 불가능합니다. 처음부터 뼈대를 다시 짜야 하니 2,000만 원 견적부터 시작합니다."*

과연 그 말이 사실일까요?

8년간 풀스택 개발사 큐룸(QUROOM)을 운영하며 수많은 바이브코딩 프로토타입을 실서버 상용 제품으로 승격시켜 온 엔지니어 관점에서 말씀드리면, 그 말은 절반만 맞고 절반은 틀렸습니다.

AI가 생성한 코드에는 분명 치명적인 보안 허점과 데이터 무결성 결함이 존재합니다. 하지만 화면 레이아웃과 도메인 인터랙션까지 전부 폐기할 필요는 전혀 없습니다.

이번 글에서는 프로토타입을 살리면서 1~2주 단기 스프린트로 안전하게 상용화하는 '살릴 코드'와 '버릴 코드'의 구체적 기술 기준을 정리합니다.

1. 전면 재구축하지 않고 살려야 하는 코드 (60~70% 보존)

비개발자 창업자가 AI와 수십 시간 대화하며 만든 산출물 중 가장 가치 있는 것은 '정교한 아키텍처'가 아니라 '도메인 지식이 녹아든 화면 흐름과 사용자 인터랙션'입니다. 이 영역은 그대로 재사용해야 시간과 비용을 아낄 수 있습니다.

① UI 레이아웃 및 반응형 스타일 (Tailwind CSS)

보존 가치: AI 도구가 가장 압도적으로 잘하는 영역입니다. Flexbox, Grid, 모바일 반응형 패딩, 다크모드 색상 팔레트 등은 사람이 손으로 일일이 짜는 것보다 AI가 작성한 코드가 훨씬 빠르고 직관적입니다.
실무 조치: 화면 렌더링에 문제가 없다면 스타일 코드는 한 줄도 건드리지 않고 그대로 유지합니다.

② 도메인 입력 폼과 인터랙션 컴포넌트

보존 가치: 날짜 선택기, 모바일 이미지 업로더 프리뷰, 단계별 위저드(Step 1 ➡️ Step 2 ➡️ Step 3) 전환 로직은 비즈니스 의도가 명확히 반영되어 있습니다.
실무 조치: 상태 관리(useState)의 위치만 정리할 뿐, 컴포넌트의 HTML/JSX 뼈대는 100% 재활용합니다.

③ 라우팅 구조와 페이지 정보 위계

보존 가치: /dashboard, /projects/[id]/settings, /billing 등 서비스가 가져야 할 페이지 계층 구조는 창업자가 기획한 비즈니스 로직 그 자체입니다.
실무 조치: Next.js App Router나 Django 템플릿/URLconf의 경로 구조를 그대로 승계합니다.

2. 보안과 안정성을 위해 반드시 걷어내고 재작성할 코드

반면, 아래의 4가지 영역은 AI 도구가 무책임하게 임시 코드로 채워 넣는 대표적인 취약 지점입니다. 이 부분은 타협 없이 엔지니어가 직접 재작성해야 합니다.

🚫 1. Client-Side에 노출된 비밀키와 비즈니스 로직

문제점: AI에게 "결제 연동해줘"라고 하면 브라우저 자바스크립트 코드(page.tsx 등)에 토스페이먼츠나 OpenAI Secret Key를 그대로 적어놓거나, 결제 승인 API를 클라이언트에서 직접 호출해 버립니다.
위험성: 브라우저 F12 개발자 도구만 열면 누구나 API 키를 탈취해 토큰을 도용하거나 결제 금액을 100원으로 위조할 수 있습니다.
해결책: 모든 민감한 API 통신과 결제 승인은 반드시 서버 측 엔드포인트(Server Actions 또는 Django Views)로 이전하고, HMAC 서명 검증을 적용합니다. 결제 보안의 상세 구현은 큐룸 빌드노트: 포트원 V2 결제 웹훅 멱등성 가이드에 정리되어 있습니다.

🚫 2. 관계와 무결성 제약이 빠진 RDBMS 스키마

문제점: Django 모델에서 user_id를 CharField나 IntegerField로 저장하고, 결제·예약 중복을 막을 DB 제약을 두지 않는 경우가 있습니다. null=False는 기본값이므로 미명시 자체는 문제가 아닙니다.
위험성: FK가 없으면 존재하지 않는 사용자를 참조하는 고아 데이터와 중복 결제·예약이 생길 수 있습니다. 회원 탈퇴 후 주문을 보존하는 것 자체는 문제가 아닙니다.
해결책: 관계는 ForeignKey와 적절한 on_delete로 정의하고, 중복은 unique=True 또는 UniqueConstraint로 차단합니다.

🚫 3. 로컬 호스트 하드코딩과 환경변수 혼재

문제점: 코드 곳곳에 fetch("http://localhost:3000/api/...")나 특정 절대 경로가 하드코딩되어 있습니다.
위험성: 로컬 컴퓨터에서는 잘 돌지만, 실서버에 배포하는 순간 502 Bad Gateway 에러를 내며 멈춥니다.
해결책: 도메인과 환경변수를 .env로 완전 격리하고 빌드 타임과 런타임을 분리합니다. 배포 환경 격리는 실서버 배포 장애 4가지와 해결 절차를 참고하십시오.

🚫 4. N+1 쿼리와 비동기 에러 핸들링 누락

문제점: 데이터 목록을 불러올 때 for 루프 안에서 매번 DB 조회를 날리거나, 외부 API 실패 시 try-catch 없이 서버 전체를 다운시킵니다.
해결책: select_related() / prefetch_related() 적용 및 Sentry 실시간 에러 트래킹을 붙여 장애를 감지합니다.

3. 바이브코딩 SOS 피니셔: 1~2주 안정화 스프린트 로드맵

큐룸이 실제 바이브코딩 의뢰 프로젝트에서 진행하는 단기 상용화 스프린트 절차입니다:

1단계: 코드 진단 (1~2일차) ➡️ UI 화면 컴포넌트를 온전히 보존한 상태에서 클라이언트에 노출된 API 키와 민감 보안 로직 백엔드 분리
2단계: 백엔드 & DB 강화 (3~5일차) ➡️ 데이터베이스 마이그레이션 정리, 유니크 제약, 외래키 연결 및 트랜잭션 무결성 확보
3단계: 실서버 격리 배포 (6~8일차) ➡️ 월 1~2만 원대 VPS 환경에 Git Push 배포 환경 구축 (VPS Dokku 배포 가이드 참조)
4단계: 런칭 검수 (9~10일차) ➡️ 실결제 테스트, 알림톡 발송, 에러 로깅 확인 후 클라이언트 인수인계 및 정식 런칭

4. 창업자를 위한 실전 조언

외주 개발사에 프로토타입 코드를 들고 갈 때 "처음부터 다시 짜야 한다"는 말에 무조건 위축될 필요는 없습니다.

"UI 레이아웃과 화면 흐름은 그대로 사용하고, DB 스키마 정규화와 API 보안 가드레일, 결제 트랜잭션만 백엔드로 교체하는 스프린트로 진행하고 싶습니다"라고 먼저 제안해 보십시오.
이때 과업 제외 범위를 명확히 못 박지 않으면 또다시 추가금 분쟁이 생길 수 있으므로, 외주 개발 계약 시 분쟁을 예방하는 5대 제외 범위 가이드의 WBS 양식을 활용하시기 바랍니다.

📚 함께 읽으면 좋은 큐룸(QUROOM) 기술 아티클

＊ 본 글은 8년 차 1인 풀스택 개발사 큐룸(QUROOM)의 실제 경험을 바탕으로 AI와 함께 작성했습니다.