바이브 코딩 프로젝트의 구조적 문제와 4시간 복구 스프린트

바이브 코딩은 자연어 지시와 AI 코딩 도구를 활용해 애플리케이션을 빠르게 구현하는 작업 방식을 뜻한다. 초기에는 화면과 기능이 빠르게 늘어나지만, 출시가 가까워지면 인증·데이터·결제·배포처럼 여러 계층을 가로지르는 문제가 드러나기 쉽다.

이 현상을 특정 기술 스택의 결함이나 사용자의 프롬프트 능력만으로 설명해서는 안 된다. 핵심은 누가 구조적 일관성을 통제하는지, 각 구성 요소의 책임이 명확한지, 완료 여부를 검증할 테스트가 있는지다.

바이브 코딩 프로젝트가 후반에 막히는 이유

화면의 완성과 서비스의 완성은 다르다

초기 개발에서는 버튼, 입력 폼, 목록처럼 눈에 보이는 결과가 빠르게 만들어진다. 그러나 실제 서비스에는 다음과 같은 보이지 않는 조건이 필요하다.

• 사용자가 자신의 데이터에만 접근하도록 하는 권한 검사
• 중복 요청과 네트워크 재시도를 견디는 데이터 처리
• 결제 성공, 실패, 취소, 환불과 웹훅 검증
• 입력값 검증과 오류 복구
• 데이터베이스 변경 및 기존 데이터 이전
• 비밀키 관리, 로그, 모니터링, 백업과 복원
• 배포 후에도 핵심 기능이 유지되는 자동 테스트

화면이 동작한다는 사실만으로 이러한 조건이 충족되지는 않는다. 후반에 발견되는 결함은 갑자기 생긴 것이 아니라, 초기 구현에서 확인되지 않은 채 누적된 경우가 많다.

AI는 저장소 전체의 설계 의도를 항상 유지하지 못한다

AI 코딩 도구는 주어진 파일, 대화 문맥, 검색된 코드와 지시에 따라 변경안을 생성한다. 프로젝트 규칙이 문서화되지 않았다면 다음과 같은 불일치가 생길 수 있다.

• 같은 데이터 조회를 서버 컴포넌트, API 경로, 브라우저 코드에서 각각 다르게 구현
• 인증 상태를 쿠키, 클라이언트 상태, 외부 SDK에서 중복 관리
• 동일한 검증 규칙을 화면과 서버에 서로 다르게 작성
• 오류를 근본적으로 해결하지 않고 예외 처리나 조건문만 추가
• 기존 추상화를 찾지 못해 유사한 함수와 데이터 모델을 반복 생성

이 상태에서 새로운 오류를 고치면 한 계층의 수정이 다른 계층의 가정을 깨뜨릴 수 있다. 사용자는 AI가 같은 자리를 맴돈다고 느끼지만, 실제로는 AI가 따라야 할 단일한 구조와 검증 기준이 없는 상황일 수 있다.

React·Next.js·Supabase 조합을 정확히 이해하기

React, Next.js, Supabase를 단순히 나쁜 조립형 스택으로 규정하는 것은 정확하지 않다. 각 기술은 널리 사용되는 독립적인 역할과 장점을 가지고 있다.

Next.js는 화면만 담당하는 도구가 아니라 서버 기능도 제공한다. Supabase 역시 단순 데이터베이스가 아니라 인증과 스토리지 등을 포함할 수 있다. 문제는 여러 기능을 사용할 때 권한과 비즈니스 규칙의 최종 책임이 어디에 있는지 정하지 않는 데서 발생한다.

예를 들어 주문 생성 규칙이 브라우저 코드, Next.js 서버 경로, Supabase 데이터베이스 정책에 분산되어 있으면 오류를 추적하기 어렵다. 반대로 쓰기 작업은 서버 서비스 계층을 통하고, 데이터베이스 정책은 최종 방어선으로 사용한다는 규칙을 정하면 같은 스택도 안정적으로 운영할 수 있다.

Ruby on Rails가 대안이 될 수 있는 이유

관례 우선으로 선택지를 줄인다

Ruby on Rails의 대표 원칙인 관례 우선은 반복적으로 내려야 하는 구조적 결정을 프레임워크의 기본 규칙으로 통일한다. 모델, 컨트롤러, 데이터베이스 변경, 작업, 메일, 테스트의 위치와 연결 방식이 비교적 예측 가능하다.

AI 코딩에서는 이 예측 가능성이 특히 유용하다. 명확한 관례를 따르면 AI가 새 기능을 전혀 다른 패턴으로 추가할 가능성을 낮추고, 사람이 변경 내용을 검토하기도 쉬워진다.

웹 서비스의 공통 기능을 한 체계에서 다룬다

Rails는 데이터베이스 접근, 라우팅, 서버 렌더링, 비동기 작업, 메일, 실시간 통신, 테스트와 배포를 위한 공식 구성 요소 및 경로를 제공한다. 이에 따라 별도 도구 간 연결부를 줄일 수 있다.

다만 다음과 같은 한계도 분명하다.

• 결제 처리에는 Stripe 같은 외부 결제사업자가 여전히 필요하다.
• 관리자 페이지가 모든 요구에 맞게 자동 완성되는 것은 아니다.
• 인증 기능을 생성하거나 라이브러리로 구성해도 권한 설계와 보안 검토는 별도 작업이다.
• 복잡한 실시간 인터페이스나 독립적인 모바일 API에는 추가 설계가 필요하다.
• Rails 경험이 없는 팀이라면 학습과 채용 비용이 발생한다.

따라서 Rails는 AI가 모든 문제를 해결하게 만드는 도구가 아니라, AI와 사람이 따라야 할 기본 경로를 좁혀 주는 선택지다.

4시간 만에 무엇을 해결할 수 있는가

로그인, 결제, 관리자 기능, 데이터 이전, 보안 검토와 운영 배포를 포함한 임의의 서비스를 4시간 안에 완성할 수 있다는 보편적 근거는 없다. 현실적인 4시간의 목표는 다음과 같다.

• 현재 구조와 실패 지점을 파악한다.
• 유지 보수와 재구현 중 하나를 선택한다.
• 가장 중요한 사용자 흐름 하나를 작동시킨다.
• 테스트 가능한 새 기준선을 만든다.
• 가능하면 스테이징 환경에 배포한다.
• 남은 위험과 후속 작업을 목록으로 남긴다.

4시간 재구현이 가능한 조건

다음 조건이 많이 충족될수록 짧은 재구현이 가능해진다.

1. 필요한 화면과 사용자 흐름이 이미 확정되어 있다.
2. 핵심 데이터 항목과 관계가 정리되어 있다.
3. 디자인을 새로 논의하지 않고 기존 화면을 참고할 수 있다.
4. 저장소, 도메인, 배포 환경과 외부 서비스 계정에 즉시 접근할 수 있다.
5. 기존 데이터 이전을 생략하거나 작은 표본만 옮겨도 된다.
6. 결제는 샌드박스의 기본 성공 흐름처럼 좁은 범위로 제한한다.
7. Rails와 배포 환경을 이해하는 작업자가 AI의 출력을 검토한다.

몇 달 동안 진행한 기존 프로젝트가 도움이 되는 이유도 여기에 있다. 그 기간에 사용자 흐름, 필수 필드, 실패 사례와 우선순위가 구체화되었다면 탐색 시간이 줄어든다. 다만 기획이 자동으로 완벽해졌다는 뜻은 아니며, 기존 프로젝트에서 검증된 요구사항만 재사용해야 한다.

실전 4시간 복구 스프린트

1단계: 원본을 보존한다

수정 전에 저장소의 별도 브랜치나 사본을 만들고 데이터베이스를 백업한다. AI 대화에 API 키, 데이터베이스 비밀번호, 개인식별정보를 붙여 넣지 않는다. 이미 노출했다면 해당 비밀정보를 폐기하고 새로 발급하는 것이 안전하다.

2단계: 기술 스택을 증거와 함께 조사한다

AI에게 단순히 기술 스택을 추측하게 하지 말고 다음 자료를 확인하도록 요구한다.

• 패키지와 버전이 기록된 매니페스트 및 잠금 파일
• 데이터베이스 스키마와 마이그레이션
• 인증과 세션을 처리하는 파일
• API 경로와 서버 함수
• 배포 설정, 환경변수 이름, 외부 서비스 SDK
• 자동 테스트와 지속적 통합 설정

사용할 수 있는 요청 예시는 다음과 같다.

저장소를 읽고 프론트엔드, 서버, 데이터베이스, 인증, 스토리지, 결제, 배포, 테스트 도구를 표로 정리하라. 각 판단의 근거가 되는 파일 경로를 적고, 비즈니스 규칙이 중복된 위치와 서버·클라이언트 경계 위반 가능성을 표시하라. 코드는 아직 수정하지 말고 비밀값은 출력하지 마라.

3단계: 핵심 수직 흐름 하나만 고른다

수직 흐름은 화면부터 서버 로직과 데이터 저장까지 연결되는 하나의 완전한 경로다. 예를 들면 다음과 같다.

• 회원 가입 → 로그인 → 프로필 조회
• 상품 선택 → 주문 생성 → 결제 샌드박스 승인
• 관리자 로그인 → 게시물 작성 → 공개 페이지 노출

한 번에 여러 화면을 만드는 것보다 핵심 흐름 하나를 성공·권한 없음·잘못된 입력 조건으로 검증하는 편이 구조적 위험을 더 빨리 드러낸다.

4단계: 완료 조건을 테스트로 고정한다

AI에게 기능 구현만 요청하면 화면상 성공 사례에 맞춘 코드가 나올 수 있다. 최소한 다음 조건을 자동 테스트 또는 반복 가능한 점검표로 고정한다.

• 정상 사용자는 작업을 완료할 수 있다.
• 로그인하지 않은 사용자는 보호된 데이터에 접근할 수 없다.
• 다른 사용자의 식별자를 입력해도 해당 데이터에 접근할 수 없다.
• 잘못된 입력은 저장되지 않고 이해 가능한 오류를 반환한다.
• 같은 결제 또는 쓰기 요청이 반복되어도 중복 처리되지 않는다.

5단계: 스테이징까지만 배포한다

4시간 스프린트의 배포는 일반적으로 운영 확정이 아니라 스테이징 검증으로 보는 것이 안전하다. 실제 사용자와 결제를 받기 전에는 보안, 데이터 이전, 백업 복원, 모니터링과 장애 대응을 별도로 확인해야 한다.

기존 프로젝트를 고칠지 다시 만들지 결정하는 기준

파일 수가 많거나 오류가 있다는 이유만으로 전면 재작성해서는 안 된다. 재작성은 기존에 해결했던 예외 상황을 잃고 새로운 결함을 만들 수 있다. 먼저 작은 수직 흐름을 두 방식으로 구현해 개발 속도, 테스트 가능성, 코드 이해도와 배포 위험을 비교하는 것이 좋다.

출시 전 별도로 확인할 항목

4시간 기준선이 만들어져도 다음 항목은 남을 수 있다.

• 권한 모델과 Rails 보안 설정 검토
• 결제 웹훅 서명, 중복 방지, 취소와 환불 처리
• 운영 데이터 이전 및 건수·합계 검증
• 데이터베이스 백업과 실제 복원 시험
• 오류 추적, 로그 보존, 가용성 모니터링
• 부하 시험과 비용 추정
• 개인정보 처리, 이용약관과 관련 법적 검토
• 접근성, 브라우저 및 모바일 환경 점검
• 장애 시 롤백 절차와 담당자 지정

결론

바이브 코딩 프로젝트의 후반 정체는 AI의 코딩 능력만으로 설명되지 않는다. 자유도가 높은 구성에서 규칙, 책임 경계, 테스트와 운영 기준을 정하지 않으면 AI가 만든 국소적인 해법이 서로 충돌하기 쉽다.

Ruby on Rails는 관례와 통합된 구조를 통해 이러한 자유도를 줄이는 실용적인 대안이 될 수 있다. 그러나 모든 프로젝트를 Rails로 다시 만드는 것이 정답은 아니다. 먼저 현재 스택을 증거 기반으로 조사하고, 핵심 흐름을 정한 뒤, 4시간을 완제품 제작 시간이 아니라 구조를 검증하고 복구 가능한 기준선을 만드는 시간으로 사용해야 한다.