배경 및 맥락

Claude Code 같은 AI 코딩 도구의 사용성을 높이기 위해 개발자 커뮤니티는 여러 워크플로우 실험을 진행 중입니다. 특히 Hacker News에서 고점수(947점, 댓글 580개)를 받은 글들은 단순한 팁을 넘어 "AI와 인간의 협업 방식"에 대한 근본적인 질문을 제기합니다. 더 나은 워크플로우를 찾으려는 시도들이 점점 늘어나면서, "어떻게 하면 AI가 정말 효율적으로 도움을 줄 수 있을까?"는 커뮤니티의 핵심 화두가 되었습니다.

Boris Tane의 "How I use Claude Code: Separation of planning and execution"은 이런 흐름 속에서 나온 실질적인 방법론입니다. 단순히 "빠르게 코드 생성하기"가 아니라, "계획을 먼저 수립한 후 AI의 실행을 승인하는" 구조를 강조함으로써, AI의 생산성과 인간의 통제 사이의 균형을 찾는 과정을 보여줍니다.

---

핵심 내용

Three-Phase Workflow: Research → Plan → Implement

Boris의 핵심 방법론은 AI에게 즉시 코드를 작성하도록 하지 않는 것입니다. 대신 세 단계의 명확한 분리를 유지합니다.

1. Research Phase (조사)

• AI에게 "이 기능을 구현하려면 어떤 기술이 필요할까?"를 묻기
• 현재 프로젝트의 기존 코드, 패턴, 의존성 확인
• 가능한 구현 방식들의 장단점 정리
• 결과물: 마크다운 문서 형태의 기술 검토 (plan.md로 저장)

2. Plan Phase (계획)

• Research 단계의 결과를 바탕으로 "정확히 어떤 파일을 만들고, 어디를 수정할 것인가?"를 작성
• API 스펙, 데이터 구조, 모듈 간 의존성을 명시적으로 기술
• "이 함수는 이렇게 호출될 것이다" 같은 구체적 예시 포함
• 인간의 승인 단계: 계획이 합리적인지 검토. 문제가 있으면 수정 요청
• 핵심: AI가 이 단계에서는 코드를 작성하지 않음

3. Implement Phase (구현)

• Plan이 승인된 후에야 "plan.md의 명세대로 코드를 작성해줘"라고 요청
• AI는 명확한 스펙을 보고 거의 실수 없이 구현
• 사용자는 이미 구현 방식을 알고 있으므로, 코드 검토가 빠름

왜 이 방식이 효과적인가?

1. 토큰 낭비 방지: AI가 임의로 여러 방향으로 시도하지 않음
2. 의도 명확화: 사용자가 "정말 원하는 것"을 글로 표현하면서 자신의 생각도 정리됨
3. 컨텍스트 윈도우 효율화: 긴 논의 대신 "이 plan.md를 따라 구현해"라는 짧은 지시로 충분
4. 디버깅 속도: 문제가 생기면 "plan의 어느 부분이 잘못됐나?"로 바로 추적 가능

실무 변형들 (Hacker News 토론에서):

• Ticket-Based Approach: plan.md 대신 ticket_*.md 같은 티켓 시스템 사용. PM이 큰 작업을 여러 티켓으로 쪼개고, 에이전트가 각 티켓을 처리
• Context Window 관리: /reset 명령어로 대화 윈도우를 초기화하면서도 이전의 plan을 참고하는 구조
• Subtask 분해: 복잡한 작업을 더 작은 하위 작업으로 나누면, 각 하위 작업의 컨텍스트가 충분히 명확해져서 AI의 실수가 줄어듦

---

경쟁 구도 / 비교

AI 코딩 도구 사용 시 다른 접근 방식들:

접근법	설명	장점	단점
"그냥 하고 빠르게 코드 작성"	AI에게 즉시 구현을 요청	빠른 시작	자주 수정 필요, 토큰 낭비
Plan-First (Boris의 방법)	계획 승인 후 구현	명확한 의도, 효율적, 디버깅 용이	초기에 시간 소요
Ticket-Based System	PM이 요구사항을 티켓으로 분해, 에이전트 처리	확장 가능, 팀 협업에 적합	초기 설정 복잡
Interactive Refinement	AI와 계속 대화하면서 점진적 개선	유연함	방향성 불명확, 토큰 많이 소비

Boris의 방식이 주목받은 이유는 "가장 간단하면서도 효과적"이기 때문입니다. 추가 도구나 복잡한 설정 없이, markdown 파일 하나로 전체 프로세스를 관리합니다.

---

의미

AI-Human Collaboration의 새로운 모델:

Boris의 워크플로우는 "AI는 어시스턴트일 뿐, 최종 결정은 인간이 한다"는 원칙을 실행합니다. 계획 단계에서의 인간의 검토가 바로 이 원칙을 구체화한 것입니다. 따라서 결과물이 단순히 "AI가 작성한 코드"가 아니라 "인간의 의도를 명확히 정의한 후 AI가 구현한 코드"가 됩니다.

개발 생산성의 패러다임 전환:

전통적으로는 개발자가 "머릿속으로 계획하고 → 코드를 작성하고 → 테스트하고 → 수정"하는 선형 프로세스를 따랐습니다. Boris의 방법은 "계획 단계를 AI와 협력하면서 명시적으로 작성하고 → 구현은 AI가 담당"합니다. 이렇게 되면 개발자는 고수준의 설계 사고에 집중할 수 있고, 단순 코딩은 AI가 처리합니다.

팀 확장성:

개별 개발자뿐 아니라 팀 수준에서도 이 방법론이 적용됩니다. PM이나 시니어 개발자가 detailed plan을 작성하면, 주니어 개발자나 AI 에이전트가 구현합니다. 이는 지식 전이(knowledge transfer)와 품질 관리를 동시에 달성합니다.

앞으로의 전망:

• 표준화 가능성: "planning document"가 코드 리뷰와 같은 수준의 중요성을 가질 수 있습니다.
• 멀티에이전트 확장: oh-my-ag 같은 멀티에이전트 시스템에서도 각 에이전트가 "다음 단계의 plan"을 작성하는 cascade 구조로 확장 가능합니다.
• 코드 리뷰의 변화: 앞으로는 "코드 리뷰"가 아닌 "plan 리뷰"가 더 중요해질 수 있습니다. 왜냐하면 코드는 plan으로부터 거의 자동으로 유도되기 때문입니다.