[바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트

TL;DR

AI와 긴 프로젝트를 진행할 때는 전체 작업을 한꺼번에 맡기지 않는다.

하나의 대화에서는 하나의 주제만 다루고, AI에게 그 주제에 맞는 역할을 부여한다.

이미 확정된 문서를 컨텍스트로 제공한 뒤 Plan Mode에서 범위와 결과물을 먼저 정리한다.

AI의 제안과 사용자의 결정을 구분하고, 대화 전체가 아니라 확정된 내용만 문서로 남긴다.

그 문서를 다음 대화의 컨텍스트로 사용하는 반복 과정이 컨텍스트 엔지니어링이다.

AI가 지금 무엇을 위해, 어떤 역할로, 어떤 정보를 참고하고, 어디까지 작업해야 하는지를 명확하게 준비하는 과정이다.

 

ㅁ 들어가며

AI와 짧은 작업을 할 때는 한 번의 요청만으로도 충분할 수 있다.

문장을 다듬거나 작은 아이디어를 정리하는 일이라면 결과를 바로 확인하고 수정하면 된다.

 

하지만 하나의 서비스를 만드는 일은 다르다.

여러 번의 대화가 이어지고, 결정해야 할 주제가 계속 바뀐다.

서비스의 목적을 정한 사람과 화면을 설계하는 AI가 같은 기준을 보지 않으면 프로젝트는 쉽게 흔들린다.

이럴 때 필요한 것은 더 화려한 프롬프트가 아니라 대화를 결정으로 바꾸고, 그 결정을 다음 대화에 전달하는 반복 방식이다.

하나의 주제 선택
      │
      ▼
페르소나 지정
      │
      ▼
기존 문서 제공
      │
      ▼
Plan Mode 토론
      │
      ▼
불필요한 확장 제거
      │
      ▼
핵심 결정
      │
      ▼
문서화
      │
      ▼
다음 단계의 컨텍스트로 사용

이 흐름을 차례로 살펴보자.

ㅁ AI에게 모든 일을 한꺼번에 맡기면 왜 흔들릴까?

긴 프로젝트에는 서로 다른 종류의 질문이 들어 있다.

  어떤 서비스를 만들 것인지 정하는 질문,

  사용자가 무엇을 보게 될지 정하는 질문,

  어떤 기술적 방향이 적합한지 검토하는 질문,

  어떤 정보를 관리할지 정하는 질문

은 서로 연결되어 있지만 같은 질문은 아니다.

 

이 모든 것을 한 번에 요청하면 AI는 빈칸을 채우기 위해 범위를 넓히기 쉽다.

사용자가 지금 원하는 것은 서비스의 목적을 정하는 일인데, AI는 화면과 기술, 데이터 구조, 향후 기능까지 한꺼번에 제안할 수 있다.

많은 답을 받는다고 프로젝트가 더 선명해지는 것은 아니다.

현재 결정할 주제와 나중에 다룰 주제가 섞이면 오히려 무엇부터 선택해야 할지 어려워진다.

 

AI와의 협업은 “전체 프로젝트를 알아서 완성해 달라”고 맡기는 방식보다,

  한 번에 하나의 결정을 함께 완성하는 방식에 가깝다.

ㅁ 하나의 대화에서는 왜 하나의 주제만 다뤄야 할까?

대화를 시작하기 전에 먼저 이번에 결정할 주제를 하나 고른다.

서비스의 목적을 정하는 대화라면 화면의 색상이나 개발 방법으로 넘어가지 않는다.

사용자 경험을 정하는 대화라면 이미 확정된 목적을 기준으로 사용자가 어떤 순서로 행동하는지에 집중한다.

 

예를 들어 프로젝트의 주제를 다음처럼 나눌 수 있다.

1. 서비스의 목적
2. 사용자 경험
3. 기술적 방향
4. 데이터 구조
5. 기능 인터페이스
6. 작업 계획

이 목록은 모든 프로젝트가 반드시 따라야 할 고정된 절차가 아니다.

중요한 것은 서로 다른 종류의 결정을 구분하는 것이다.

한 단계의 결과를 문서로 확정한 뒤, 그 문서를 들고 다음 주제로 이동한다.

식당을 준비하는 과정으로 생각하면 더 쉽다.

지금 식당의 콘셉트를 정하고 있다면 메뉴판 디자인이나 주방 설비를 함께 결정하지 않는다.

콘셉트가 정해진 뒤에야 다음 담당자가 그 기준을 이어받을 수 있다.

ㅁ AI에게 역할을 부여하면 무엇이 달라질까?

주제를 골랐다면 AI에게 현재 작업에 맞는 역할을 부여한다.

역할을 부여하는 이유는 AI에게 더 많은 권한을 주기 위해서가 아니다.

오히려 생각할 관점을 제한하기 위해서다.

같은 식당을 보더라도 메뉴 기획자, 주방 설계자, 요리사, 운영 담당자가 집중하는 부분은 다르다.

현재 주제	AI에게 부여할 역할
서비스 목적	서비스 기획자
사용자 흐름	UX 설계자
기술 방향	기술 책임자
블로그 재구성	기술 콘텐츠 에디터

 

역할과 함께 제외할 범위도 알려 주면 관점이 더 분명해진다.

너는 지금 서비스 기획자다.
Speed Quiz의 목적과 핵심 사용자 경험만 정리한다.
기술 구현이나 화면 세부 내용은 확장하지 않는다.

이 요청에서 중요한 부분은 “서비스 기획자”라는 이름보다 “무엇에 집중하고 무엇을 확장하지 않는가”라는 경계다.

좋은 페르소나는 AI를 더 자유롭게 만드는 것이 아니라 현재 주제에 머물게 한다.

ㅁ 기존 문서를 왜 먼저 제공해야 할까?

새 대화를 시작할 때마다 이전 과정을 처음부터 설명할 필요는 없다.

이미 확정된 문서를 제공하면 된다.

예를 들어 서비스의 목적과 요구사항이 PRD에 정리되어 있다면, 사용자 경험을 논의할 때 그 PRD를 먼저 제공한다.

AI는 “어떤 서비스를 만들고 있는가”를 다시 추측하지 않고, 확정된 목적을 기준으로 다음 질문에 집중할 수 있다.

이때 관련 문서를 모두 한꺼번에 넣는 것이 항상 좋은 것은 아니다.

현재 작업에 필요한 기준만 선택해야 한다.

화면 흐름을 논의하는데 검토 중인 기술 아이디어나 오래된 메모까지 함께 주면 어떤 정보가 우선인지 다시 모호해질 수 있다.

 

문서를 제공할 때는 세 가지를 분명히 한다.

• 이 문서가 현재 작업의 기준이라는 점
• 문서에서 이미 확정된 내용을 임의로 바꾸지 않는다는 점
• 문서에 없는 내용은 추측하지 않고 필요한 경우 질문한다는 점

문서는 AI가 모든 것을 기억하게 만드는 장치가 아니다.

지금 필요한 기억을 정확히 선택해 주는 장치다.

ㅁ Plan Mode에서는 무엇을 확인해야 할까?

기존 문서를 제공했다면 바로 최종 결과를 만들기보다 Plan Mode에서 이번 작업의 경계를 확인한다.

Plan Mode는 단순히 실행을 늦추는 단계가 아니다.

결과를 만들기 전에 무엇을 결정해야 하는지 함께 검토하고, 잘못된 방향으로 빠르게 달려가는 일을 줄이는 과정이다.

 

이때 다음 다섯 가지를 확인한다.

1. 이번에 결정할 내용은 무엇인가?
2. 이미 확정된 내용은 무엇인가?
3. 아직 결정되지 않은 내용은 무엇인가?
4. 이번 단계에서 제외할 내용은 무엇인가?
5. 최종 결과물은 어떤 형태인가?

AI가 너무 많은 내용을 제시하면 범위를 다시 줄인다.

- 지금은 화면 구성만 다룬다. 기술 구현은 다음 단계에서 정리한다.
- 현재 목적에 필요한 내용만 남긴다. 확장 아이디어는 이번 문서에 포함하지 않는다.

충분히 논의한다는 것은 아이디어를 끝없이 늘린다는 뜻이 아니다.

어떤 선택지가 있는지 살펴보고, 지금 필요한 것만 남기는 일이다.

ㅁ AI의 제안과 사용자의 결정은 어떻게 구분할까?

AI가 제시한 내용은 검토할 수 있는 제안이다.

그럴듯하고 구체적으로 보이더라도 사용자가 채택하기 전까지는 확정된 요구사항이 아니다.

이 구분이 없으면 대화 중 잠깐 나온 아이디어가 다음 단계에서 반드시 구현해야 할 기능처럼 바뀔 수 있다.

AI는 자신이 앞서 제안한 내용을 문맥의 일부로 보고 계속 발전시킬 수 있기 때문이다.

따라서 대화 중에는 상태를 명확하게 표시한다.

• 제안: 검토 중이며 아직 채택하지 않은 내용
• 확정: 사용자가 선택했고 다음 작업의 기준이 되는 내용
• 제외: 이번 범위에서 다루지 않기로 한 내용

AI의 역할은 선택지를 정리하고 놓친 관점을 보여 주는 것이다.

무엇을 채택할지는 사용자가 결정한다.

바이브 코딩은 AI가 방향을 대신 정하는 과정이 아니라, 사용자가 AI의 도움을 받아 결정을 더 빠르게 구체화하는 과정이다.

ㅁ 왜 대화 전체를 문서로 남기면 안 될까?

하나의 대화에는 최종 결정만 들어 있지 않다.

질문, 중간 아이디어, 잘못 이해한 내용, 제외하기로 한 제안도 함께 남아 있다.

이 대화 전체를 다음 단계의 기준으로 사용하면 AI는 다시 무엇이 중요한지 해석해야 한다.

검토만 했던 기능을 확정된 요구사항으로 받아들이거나, 이미 수정한 내용을 이전 답변에서 다시 가져올 수도 있다.

대화가 끝나면 다음 순서로 정리한다.

1. 이번 대화에서 결정한 내용을 고른다.
2. 목적과 맞지 않는 제안은 제외한다.
3. 결정된 내용을 짧고 명확하게 다시 쓴다.
4. 아직 검토 중인 내용은 확정된 결정과 구분한다.
5. 하나의 주제에 맞는 문서로 저장한다.

문서는 대화의 요약본과도 조금 다르다.

대화에서 무슨 말을 했는지를 줄이는 것이 아니라, 다음 작업에 필요한 결정만 남기는 것이 목적이다.

이 과정을 거치면 대화는 사라져도 결정은 남는다.

사용자는 프로젝트의 방향을 계속 통제할 수 있고, AI는 다음 작업에서 참고할 명확한 기준을 얻는다.

ㅁ 문서를 다음 대화의 컨텍스트로 어떻게 사용할까?

확정된 문서는 다음 대화의 출발점이 된다.

서비스 목적을 정리한 문서는 UX를 논의할 때 사용하고, 확정된 UX 문서는 기술적 방향을 검토할 때 참고한다.

각 문서는 이전 단계의 결정을 보존하면서 다음 단계가 임의로 출발하지 않게 한다.

이때 다음 대화에는 긴 이전 대화 대신 필요한 문서와 현재 작업의 지시를 제공한다.

이 PRD는 확정된 기준이다.
너는 UX 설계자의 관점에서 사용자가 보게 될 화면과 이용 순서만 검토한다.
기술 선택과 구현 방법은 이번 범위에서 제외한다.
먼저 결정할 내용과 확인이 필요한 내용을 정리한다.

 

이것은 특별한 프롬프트 문법이 아니다.

목적, 역할, 기준 문서, 작업 범위, 기대 결과물을 분명히 전달한 예시다.

문서를 다음 컨텍스트로 사용하는 순간, 문서는 단순한 기록이 아니라 사람과 AI 사이의 공통 기억이 된다.

ㅁ 이 반복 과정은 왜 컨텍스트 엔지니어링일까?

컨텍스트 엔지니어링이라는 말은 어렵게 들리지만, 핵심은 간단하다.

AI가 지금 무엇을 위해, 어떤 역할로, 어떤 정보를 참고하고, 어디까지 작업해야 하는지를 명확하게 준비하는 과정이다.

 

이를 다섯 가지 요소로 정리할 수 있다.

요소	확인할 질문
목적	이번 작업을 왜 하는가?
역할	AI는 어떤 관점으로 검토해야 하는가?
참고 문서	무엇이 이미 확정된 기준인가?
작업 범위	이번에는 어디까지 다루는가?
기대 결과물	대화, 초안, 확정 문서 중 무엇을 만드는가?

컨텍스트 엔지니어링은 프롬프트를 길게 쓰는 기술만을 뜻하지 않는다.

좋은 기준 문서를 만들고, 현재 작업에 필요한 문서만 고르고, AI가 집중할 범위와 역할을 제공하는 전체 과정에 가깝다.

 

여기에 SSOT와 MECE 원칙을 적용하면 기준은 더 선명해진다.

하나의 결정은 하나의 문서에서 관리하고, 각 문서는 겹치지 않는 역할을 맡되 필요한 내용은 빠짐없이 담는다.

그러면 AI가 충돌하는 정보를 임의로 조합하거나 비어 있는 부분을 추측할 가능성을 줄일 수 있다.

물론 구조화된 컨텍스트가 AI의 오류나 할루시네이션을 완전히 없애 주는 것은 아니다.

다만 어떤 정보를 우선해야 하는지 분명하게 만들고, 불필요한 추측이 필요한 상황을 줄여 준다.

ㅁ Speed Quiz에는 이 방식을 어떻게 적용했을까?

Speed Quiz는 이 협업 방식을 설명하기 위한 사례다.

중요한 것은 어떤 기능을 어떤 코드로 만들었는지가 아니라, 하나의 서비스를 만들기 위한 결정을 어떻게 나누고 연결했는가다.

먼저 “어떤 서비스를 만들 것인가”라는 주제를 다루고 그 결과를 PRD로 남겼다.

다음 대화에서는 PRD를 기준으로 사용자가 보게 될 흐름을 정리했다.

그 다음에는 확정된 목적과 경험을 바탕으로 기술적 방향을 검토했다.

각 단계에서 AI에게 현재 주제에 맞는 역할을 부여했고, 이번에 다루지 않을 범위를 함께 정했다.

AI가 제시한 모든 내용을 요구사항으로 채택하지 않고, 필요한 결정만 골라 문서에 남겼다.

그렇게 만들어진 문서가 다음 단계의 컨텍스트가 되었다.

 

Speed Quiz의 사례를 한 줄로 정리하면 다음과 같다.

하나의 주제를 논의한다 → 결정만 문서로 남긴다 → 그 문서로 다음 주제를 시작한다.

이 방식이라면 사용자가 처음부터 모든 개발 지식을 알고 있을 필요는 없다.

지금 결정할 질문을 분명하게 만들고, AI와 함께 선택지를 검토하고, 확정된 결과를 다음 단계에 전달하면 된다.

ㅁ 마무리 — 대화는 사라져도 결정은 남아야 한다

AI와 긴 프로젝트를 시작하기 전에 다음 내용을 확인해 보자.

• 지금 대화에서 다룰 주제는 하나인가?
• AI에게 현재 주제에 맞는 역할을 주었는가?
• 이미 확정된 문서를 기준으로 제공했는가?
• 이번 단계에서 제외할 범위를 밝혔는가?
• AI의 제안과 사용자의 결정을 구분했는가?
• 대화 전체가 아니라 확정된 내용만 문서로 남겼는가?
• 그 문서를 다음 대화의 컨텍스트로 사용할 수 있는가?

이 질문에 답할 수 있다면 프로젝트 전체를 한꺼번에 지시하지 않아도 된다.

사용자는 매 단계에서 하나의 결정에 집중하고, AI는 현재 역할과 범위에 집중할 수 있다.

바이브 코딩의 핵심은 AI에게 모든 일을 맡기는 것이 아니다.

사용자가 목적과 범위를 결정하고, AI가 그 결정을 구체화하도록 돕고, 문서가 다음 협업을 이어 주게 만드는 것이다.

처음부터 완벽한 문서를 만들 필요도 없다.

지금 결정한 내용을 분명하게 남기고, 다음 대화에서 그 문서를 정확한 기준으로 사용하는 것부터 시작하면 된다.

그렇게 쌓인 문서는 어느 순간 하나의 서비스를 만들기 위한 설계가 되어 있을 것이다.

ㅁ 함께 읽으면 좋은 글

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트

 - PRD부터 API까지 문서의 역할과 SSOT·MECE 원칙

ㅇ Context Note — AI 대화의 컨텍스트는 왜 “쌓지 않고 구조화”해야 할까?

 - ChatGPT와 함께 컨텍스트를 문서 중심으로 관리하기 위해 만든 도구이다.

 - GPT Atlas에서 트리 구조의 노트, 마크다운 편집기, ChatGPT 대화창을 함께 사용하며 필요한 컨텍스트를 구조화할 수 있다.