결과물이 없는
시간

무언가를 만들고 싶었다. Cursor를 열었다. 프롬프트를 쳤다. 코드가 나왔다. 거의 됐다. 한 군데를 고쳤다. 다른 데가 깨졌다. 그걸 고쳤다. 두 군데가 더 깨졌다. 세 시간이 지났다. 직접 작성하지 않은 코드를 디버깅하고 있다.

익숙한가?

2025년, AI 코딩 도구의 채택률은 84%에 달했다. 그러나 같은 해, AI 도구의 정확도를 신뢰하는 개발자는 29%로 떨어졌다. 쓰는 사람은 늘었는데, 믿는 사람은 줄었다. 이 역설의 중심에 속도가 있다.

숫자가 말해준다. Veracode는 2025년 AI가 생성한 코드의 45%에 보안 취약점이 있다고 보고했다. LLM이 안전한 방법과 위험한 방법 중 선택할 때, 45%의 확률로 위험한 쪽을 골랐다. Java는 70%를 넘었다.

Apiiro는 Fortune 50 기업의 수만 개 레포지토리를 분석했다. AI 코딩 도구 도입 후 6개월 만에 월간 보안 결함이 10배 증가했다. 개발 속도는 4배 빨라졌지만, 보안 결함은 10배 늘었다. 속도가 빚을 만든 것이다.

Tenzai는 2025년 12월, Claude Code, Cursor, Devin 등 5개 주요 AI 코딩 도구를 동일한 3개 애플리케이션으로 비교 테스트했다. 15개 앱에서 69개의 취약점이 발견됐다. 결론은 이것이었다.

도구의 문제인가? 아니다. 도구는 시킨 대로 했을 뿐이다. 문제는 도구에게 시키는 방식에 있다. 맥락 없이, 계획 없이, 요구사항 정리 없이 "로그인 기능 만들어줘"라고 프롬프트를 치면, AI는 가장 흔한 패턴을 가장 빠르게 생성한다. 보안? 에지 케이스? 아키텍처 일관성? 시키지 않은 일은 하지 않는다.

Andrej Karpathy는 2025년 2월 "vibe coding"이라는 용어를 만들었다. "코드가 존재한다는 사실조차 잊어버리고, 분위기에 몸을 맡기는 코딩." 1년 뒤, 그는 용어를 바꿨다. "agentic engineering" — 에이전트를 조율하는 엔지니어링. 그리고 이렇게 덧붙였다.

바이브 코딩을 만든 사람조차 바이브만으로는 안 된다고 말하고 있다. 속도는 도구가 주는 것이 아니다. 계획이 주는 것이다.

문제는 AI 도구가 아니다. 문제는 뇌다. 인간의 워킹 메모리에는 한계가 있고, 계획 없이 코드부터 치는 행위는 그 한계를 전부 위반한다.

George Miller의 "7 +/- 2"는 유명하지만, Nelson Cowan의 2001년 후속 연구가 더 엄격하다. 청킹 전략 없이 순수하게 처리할 수 있는 정보는 3-4개뿐이다. 변수 값 하나, 함수 호출 흐름 하나, 에러 메시지 하나 — 그것만으로 워킹 메모리의 절반이 차버린다.

Gloria Mark의 연구는 더 불편한 사실을 알려준다. 중단 후 깊은 집중을 회복하는 데 평균 23분 15초가 걸린다. 바이브 코딩에서 "프롬프트 → 결과 확인 → 수정 요청" 사이클은 매번 컨텍스트 전환이다. 그리고 중단의 49%는 외부가 아니라 자기 자신이 만든다.

여기서 핵심적인 발견이 하나 있다. Zeigarnik 효과다.

Bluma Zeigarnik이 1927년에 발견한 이 현상은, 완료하지 않은 작업이 머릿속에 남아 인지 자원을 계속 점유한다는 것이다. 바이브 코딩으로 달리는 사람은 끊임없이 미완성 작업을 안고 달린다. 에러를 고치면 다른 에러가 생기고, 기능을 추가하면 기존 기능이 깨진다. 모든 미완성이 워킹 메모리를 잠식한다.

그런데 후속 연구에서 밝혀진 것이 있다. 미완료 작업 자체가 문제가 아니라, 그 작업에 대한 구체적 계획이 없는 것이 문제다. 계획을 세우면 — 단순히 다음 단계를 적어두기만 해도 — 인지 부담이 해소된다.

"결과물이 없어서 불안하다"는 감정의 정체는, 사실 "계획이 없어서 뇌가 과부하된 것"이다. 해법은 역설적으로 단순하다. 계획을 세워라. 문서로 써라. 머릿속의 미완성을 종이 위로 옮기는 순간, 뇌는 해방된다.

불편한 진실이 있다. 프로젝트에서 가장 생산적인 시간에는 코드가 한 줄도 없다.

아래의 5단계를 따르면, 코딩을 시작하기 전까지 최소 2-3시간을 쓰게 된다. 그 시간 동안 결과물은 코드가 아니라 문서다. 그리고 그 문서가 이후의 모든 것을 결정한다.

각 단계를 상세히 살펴보자. 그리고 각 단계에서 AI에게 건넬 수 있는 프롬프트를 제공한다. 대괄호 [ ] 안의 내용을 본인의 상황에 맞게 수정하고, AI에 붙여넣으면 된다.

Step 01 — 생각 정리

"로그인 기능 만들어줘"라고 프롬프트를 치기 전에, 그 로그인이 OAuth인지 이메일/비밀번호인지, 소셜 로그인이 필요한지, 세션 관리를 어떻게 할 것인지를 정리해야 한다. 정리되지 않은 생각은 정리되지 않은 코드가 된다.

AI에게 질문을 받으면서 생각을 구조화할 수 있다. 아래 프롬프트는 AI가 핵심 질문을 던지고, 답변을 정리해주는 역할을 한다.

Step 02 — 자료 수집

AI와 웹 검색을 활용하되, 수집한 자료를 정리하는 것이 핵심이다. 브라우저 탭 30개를 열어두는 것과, 핵심 정보를 문서 하나에 요약하는 것은 전혀 다른 행위다. 전자는 워킹 메모리를 소비하고, 후자는 워킹 메모리를 해방한다.

Step 03 — 문서 작성

PRD(Product Requirements Document)를 쓴다. 거창할 필요 없다. 핵심은 AI가 읽을 수 있는 구조화된 문서를 만드는 것이다. 이 문서가 AI와의 대화에서 "맥락"이 된다. 매번 처음부터 설명하는 대신, 문서를 참조시킨다.

Simon Willison(Django 공동 창시자)의 황금률이 여기에 적용된다.

Step 04 — 맥락 주입

시스템 프롬프트가 AI의 성격을 정하듯, 규칙 파일이 프로젝트의 성격을 정한다. CLAUDE.md, .cursorrules, 또는 사용하는 도구의 규칙 파일에 코딩 컨벤션, 금지 사항, 아키텍처 결정을 넣는다. AI는 매번 이 파일을 읽고 프로젝트 맥락을 파악한다.

규칙 파일이 없으면 AI는 매 대화마다 백지에서 시작한다. 규칙 파일이 있으면 AI는 프로젝트를 아는 동료처럼 행동한다.

Step 05 — 개발 + 디테일링

이제 코드를 쓴다. 그런데 이 시점에서 코딩은 놀랍도록 빠르다. 왜? AI가 모든 맥락을 알고 있기 때문이다. PRD가 있고, 규칙이 있고, 아키텍처가 결정되어 있다. AI는 "무엇을 만들지" 묻지 않는다. 바로 만든다.

Kent Beck의 원칙이 여기에 정확히 들어맞는다. "Make it work, make it right, make it fast." 먼저 동작하게 만들고, 올바르게 고치고, 그다음 최적화한다. 1-4단계에서 "right"의 기준을 이미 정의했으므로, 5단계에서는 "work"에 집중할 수 있다.

Martin Fowler의 기술 부채 분류가 경고하는 것이 있다. 계획 없이 쌓인 부채는 Reckless/Inadvertent — 무모하면서 자각도 없는 부채다. 네 가지 분면 중 최악이다. 부채가 있다는 사실조차 모르기 때문에, 갚을 방법도 모른다.

5단계 워크플로우는 이 최악의 분면을 피하기 위한 것이다. 1-4단계에서 무엇을 만들고 무엇을 만들지 않을지 결정했으므로, 5단계에서 발생하는 부채는 최소한 Prudent/Deliberate — 신중하고 의도적인 부채가 된다.