바이브 코딩 결과물, 언제 배포해도 될까

바이브 코딩 결과물은 화면이 한 번 열렸다고 배포 준비가 끝난 것이 아니다. 핵심 작업을 처음부터 끝까지 다시 실행하고, 잘못된 입력에서 회복하며, 새로고침 뒤 필요한 상태를 복원하고, 공개 범위와 인계 방법을 설명할 수 있을 때 배포 후보가 된다. 이 기준은 KAAI 개인 AI 실무·프로젝트 리포트의 완료 판단 프레임을 개인 제작자가 바로 점검할 수 있게 풀어 쓴 것이다.

생성에서 배포로 바로 뛰지 않는다

AI가 코드를 만들거나 화면을 수정한 사실은 실행 증거와 다르다. 생성 뒤에는 실행, 테스트, 수정, 재검증, 릴리스 기록이 한 묶음으로 이어져야 한다. 오류를 고친 뒤에도 원래 되던 핵심 작업을 다시 확인해야 한다. 수정이 새로운 실패를 만들 수 있기 때문이다.

공급사 고객 사례인 Playco 사례에는 모델이 게임 엔진 안에서 장면을 편집하고 플레이·테스트·검증한 작업 방식이 소개돼 있다. 다만 사례에 나온 수동 수정 50% 감소는 Playco가 이전 모델과 비교해 보고한 값이다. 개인 프로젝트의 예상 생산성이나 보편적인 개선율로 옮길 수 없다. 참고할 것은 숫자가 아니라 생성물을 실제 환경에서 실행하고 검증하는 작업 흐름이다. 원문은 OpenAI의 Playco 고객 사례에서 확인할 수 있다.

테스트 수보다 실패 비용이 큰 순서를 고른다

처음부터 모든 경우를 검사할 수는 없다. 그래서 테스트 개수를 품질 점수처럼 세기보다, 실패했을 때 사용자가 가장 크게 멈추는 순서로 확인한다.

인증, 결제, 개인정보가 들어오면 검사 범위가 달라진다. 권한 분리, 민감정보 처리, 감사 기록, 전문 보안 검토를 별도 계획해야 한다. 정적 페이지에서 통과한 테스트를 서버와 사용자 계정이 있는 서비스의 안전성으로 확대해 해석해서는 안 된다.

오류 화면도 핵심 기능으로 취급한다

오류를 숨기면 화면은 깨끗해 보이지만 사용자는 다음 행동을 잃는다. 좋은 오류 화면은 무엇이 실패했는지, 입력이 보존됐는지, 다시 시도할 수 있는지, 도움이 필요하면 어디로 가야 하는지를 알려 준다.

• 입력 오류: 잘못된 필드 가까이에 허용 형식을 표시한다.
• 연결 오류: 재시도 가능 여부와 입력 보존 상태를 알린다.
• 권한 오류: 권한 요청 방법과 다른 경로를 구분한다.
• 복구 실패: 백업, 이전 버전 또는 지원 경로를 제시한다.

이 항목은 친절한 문구를 덧붙이는 문제가 아니다. 실패 뒤에도 사용자가 원래 작업으로 돌아가게 만드는 설계다. 재시도 버튼만 있어도 입력이 사라진다면 복구가 끝난 것이 아니다.

배포 직전에는 일곱 증거를 한곳에 모은다

배포 판단표에는 최소한 핵심 작업, 실패 처리, 재실행 절차, 저장·복원, 인계 자료, 공개 경계, 사용자가 끝내는 일이 포함돼야 한다. 각 항목 옆에는 ‘통과’라는 말보다 화면, 명령, 파일, URL, 확인 날짜처럼 다시 볼 수 있는 증거를 둔다.

KAAI 보고서의 직접 검증 앱은 HTTP 로드, 빈 입력, 준비 상태 판정, 저장·복원, 초기화, 접근성 구조, 390px 표시, 외부 요청 없음 등 8개 자동화 검사를 통과했다. 이 결과는 해당 정적 앱과 그 검사 조건에만 해당한다. 인증, 서버 데이터베이스, 결제, 침투 테스트와 실제 사용자 성과는 검증 범위가 아니었다. 검사 통과 수만 떼어 ‘안전한 서비스’라고 말하지 않는 이유다.

오늘 공개할 것과 다음 버전을 분리한다

모든 기능을 끝낸 뒤에만 배포할 수 있는 것은 아니다. 현재 약속한 핵심 작업과 공개 경계를 통과했다면 제한된 프로토타입으로 공개하고, 남은 기능은 다음 버전의 범위로 기록할 수 있다. 반대로 실패 복구와 데이터 경계가 비어 있는데도 ‘운영 가능’이라고 부르면 독자에게 실제보다 큰 약속을 하게 된다.

배포 버튼을 누르기 전 마지막 질문은 간단하다. ‘새 환경에서 같은 절차를 따라 핵심 작업을 끝내고, 실패해도 돌아오며, 누가 운영 책임을 맡는지 설명할 수 있는가.’ 답이 모호하다면 기능을 더 만들기보다 증거를 먼저 보완한다. 전체 단계와 직접 검증 범위는 보고서 원문에서 살펴볼 수 있다.