'그냥 내보내면 돼'는 바이브 코딩 (vibe-coding)에서 가장 비용이 많이 드는 조언이다

"코드가 감당할 수 없을 만큼 커지면 그냥 내보내면(export) 됩니다." 이는 바이브 코딩 (vibe-coding)에서 가장 반복되는 안심시키는 말이며, 동시에 가장 큰 비용을 치르게 하는 말이기도 합니다.

이 제안은 이론적으로는 타당해 보입니다. Lovable, Bolt, v0와 같은 샌드박스(sandbox)에서 MVP를 구축하고, 그것이 샌드박스에 담기에는 너무 커지는 순간, 내보내기(export) 버튼을 눌러 코드를 자신의 저장소(repo)에 넣은 다음 Cursor나 Claude Code로 작업을 이어가면 됩니다. 종속성(lock-in)도 없고, 코드는 당신의 것이니까요.

하지만 실제로 그렇게 실행하면, '작업을 이어가기 위해' 계획했던 주말은 AI 에이전트(agent)가 추측하며 헤매는 3주로 변해버립니다.

내보내기 버튼은 작동합니다. 문제는 내보내기 결과물(export) 그 자체입니다.

내보내기는 바이트(bytes)를 줄 뿐, 코드베이스(codebase)를 주지 않는다

코드 내보내기는 스냅샷(snapshot)입니다. 당신은 버튼을 클릭한 그 순간에 존재했던 파일들을 얻게 되며, 그 외의 것은 아무것도 얻지 못합니다.

당신이 얻지 못하는 것들:

• Git 히스토리 (Git history). 커밋(commit)도 없고, "왜 이렇게 바뀌었는지"에 대한 기록도 없으며, 이분법적 탐색(bisect)도 불가능합니다. 저장소는 하나의 거대한 초기 커밋으로 시작됩니다.
• 컨벤션 (Conventions). 왜 인증(auth) 로직이 여기는 lib/auth.ts에 있고 저기는 utils/session.ts에 있을까요? 아무도 결정하지 않았습니다. 생성기(generator)가 세션에 따라 표류했기 때문입니다.
• 의존성 이야기 (A dependency story). 샌드박스는 당신이 선택하지 않은 버전들을 고정(pin)해 두었고, 세 개의 프롬프트(prompt)가 각각 다른 라이브러리를 요구했기 때문에 세 개의 상태 관리(state) 라이브러리가 뒤섞여 있으며, 삭제를 요청했던 기능의 데드 코드(dead code)를 남겨두었습니다.
• 다음 도구를 위한 맥락 (Any context for the next tool). 내보낸 파일은 당신이 곧 열게 될 IDE에 대해 아무것도 알지 못합니다.

만약 당신이 모든 코드를 직접 한 줄 한 줄 읽을 생각이라면 이 정도는 괜찮습니다. 하지만 바이브 코딩 (vibe-coding) 도구를 사용하는 사람 중 그 누구도 모든 코드를 직접 읽지는 않을 것입니다. 그것이 바로 이 도구들을 사용하는 목적이니까요.

에이전트는 파일뿐만 아니라 컨벤션을 읽는다

내보낸 코드의 모든 불일치는 에이전트가 추측해야 하는 갈림길이 되며, 에이전트는 매 프롬프트마다, 영원히 추측을 반복하게 됩니다. 내보내기(export)는 재생성 비용(regeneration tax)을 끝내지 못했습니다. 단지 그 비용을 당신의 저장소(repo)로 옮겨 영구적으로 만들었을 뿐입니다.

재생성 비용은 코드를 따라 집으로 찾아온다

샌드박스(sandbox) 안에서 당신은 크레딧(credits)으로 비용을 지불했습니다. 매 세션마다 인증 흐름(auth flow)을 다시 유도했고, 그 대가로 토큰(tokens)을 지불했습니다. 사람들은 내보내기를 하면 그것이 끝날 것이라고 가정합니다.

그렇지 않습니다. 통화(currency)가 바뀔 뿐입니다.

이제 당신은 에이전트의 혼란으로 비용을 지불합니다. 모델은 무엇이 표준(canonical)인지 파악하기 위해 일관성 없는 파일들을 다시 읽느라 컨텍스트(context)를 소모합니다. 앱의 절반과 일치하는 코드를 배포하고 나머지 절반은 망가뜨립니다. 당신은 명문화되지 않은 컨벤션(conventions)을 검사하는 인간 린터(human linter)가 되어 리뷰 시간을 허비하게 됩니다.

단계	지불하는 것	이유
샌드박스 내에서	크레딧 / 토큰	매 세션마다 기본 사항을 재생성함
...
해지한 구독 서비스가 여전히 요금을 청구하듯, 에이전트가 읽을 수 없는 코드베이스에서 허비하는 시간으로 비용을 청구합니다.

에이전트가 기반을 다질 수 있는 소유권은 차원이 다른 문제다

"당신이 코드를 소유한다"와 "당신의 에이전트가 코드를 확장할 수 있다"는 같은 주장이 아닙니다. 전자는 라이선스(license)에 관한 것이고, 후자는 구조(structure)에 관한 것입니다.

파일 시스템 에이전트가 실제로 당신의 속도를 높여주려면, 저장소는 내보내기 방식으로는 구조적으로 포함할 수 없는 것들을 갖추고 있어야 합니다:

• CLAUDE.md (및 .cursorrules): 스택(stack), 컨벤션(conventions), 그리고 명확하지 않은 규칙들을 명시하여 에이전트가 이를 잘못 추론하지 않도록 합니다.
• 일관된 기능 패턴 (consistent feature pattern): 엔티티를 추가하는 한 가지 방식, 화면을 추가하는 한 가지 방식 — 그래야 "X에 대해서도 똑같이 해줘"라는 명령이 발명(invention)이 아닌 복제(copy)가 됩니다.
• 프롬프트 라이브러리 (ai/prompts/): 이 코드베이스가 기능을 어떻게 구축하기를 원하는지 이미 알고 있는, 테스트된 프롬프트들.
• 배포 스크립트 (Deploy scripts): 프로젝트 특유의 절차(환경 변수 로드, 빌드, 배포)를 인코딩하여 에이전트가 이를 새로 만들다가 망가뜨리지 않도록 합니다.

그 중 어느 것도 스냅샷(snapshot)에 살아남지 못합니다. 왜냐하면 그 중 어느 것도 실제로 존재한 적이 없기 때문입니다. 그것은 컨벤션(conventions)이 무엇인지 결정한 인간에 의해 작성되어야 합니다.

결판을 내는 테스트

당신이 내보내기(export)를 생각하고 있는, 바이브 코딩(vibe-coded)으로 만든 앱을 아무거나 가져와 보세요. 그것을 내보냅니다. Cursor에서 엽니다. 그리고 프롬프트를 하나 입력합니다:

앱의 나머지 부분과 일치하는 결제 페이지를 추가해줘

만약 에이전트(agent)가 단 한 번의 시도(one shot)로 일관된 결과물을 내놓는다면, 당신은 진짜 코드베이스(codebase)를 가진 것이니 계속 유지하십시오. 만약 에이전트가 새로운 레이아웃을 만들어내고, 다른 곳에서는 사용하지 않는 경로에서 임포트(import)를 하며, 당신이 그 차이를 조정하느라 오후 시간을 다 허비하게 만든다면, 그 내보내기는 당신에게 기반(foundation)이 아닌 바이트(bytes)만을 준 것입니다. 그리고 이 기능 이후의 모든 기능은 똑같이 오후 시간을 잡아먹을 것입니다.

그 테스트가 바로 우리가 키트(kits)를 내보내기 형식이 아닌 리포지토리(repos) 형태로 제공하는 이유입니다. 모든 OTF 키트는 당신이 온전히 소유하는 풀스택(full-stack) 코드이지만, 정말 중요한 부분은 코드 주변의 모든 것입니다. 에이전트가 가장 먼저 읽는 CLAUDE.md, 이를 반영하는 .cursorrules, ai/prompts/에 있는 40개 이상의 테스트된 프롬프트(prompts), 기능을 추가하는 하나의 일관된 방식, 그리고 이를 실제 도메인이나 앱스토어(App Store)로 전달하는 배포 스크립트(deploy scripts) 같은 것들 말입니다. 당신은 이것을 한 번만 구매하면 됩니다. 당신의 에이전트는 자신이 직접 작성한 코드를 읽는 것과 같은 방식으로 이것을 읽을 것입니다.

"그냥 내보내면 돼"라는 말은 바이트를 추출하는 것이 어려운 작업이라고 가정합니다. 하지만 어려운 부분은 결코 바이트가 아니었습니다. 그것은 바로 컨벤션(conventions)입니다. 그리고 스냅샷(snapshot)은 기록되지 않은 것을 스냅샷할 수 없습니다.