'그냥 만들어줘'가 실패하는 순간 | Plan Mode
AI에게 바로 코드를 시키면 실패하는 두 지점과, Plan Mode로 탐색·계획·실행을 분리하는 사이클을 익힙니다
Overview
Part 1에서 LLM 작동 원리, Claude Code 인터페이스, Context 관리를 다뤘습니다. 이제 작은 Todo 앱을 만들 차례입니다. 그런데 빈 폴더에서 AI에게 바로 "Todo 앱 하나 만들어줘"라고 엔터를 치면, 원하지 않은 결과가 돌아오기 쉽습니다. 이 레슨에서는 왜 그런지, 그리고 Plan Mode가 이 문제를 어떻게 막는지 살펴봅니다.
학습 목표
- AI에게 바로 코드를 시키면 안 되는 두 지점을 설명할 수 있습니다
- Plan Mode의 탐색 → 계획 → 실행 사이클을 이해합니다
- Plan Mode에 진입해 계획을 주고받고 실행으로 이어지는 흐름을 직접 따라 합니다
'그냥 만들어줘'가 어긋나는 두 지점
"Todo 앱 하나 만들어줘"라는 한 문장 안에는 대답되지 않은 질문이 열 개가 넘습니다. 어떤 프레임워크를 쓸까요? 데이터는 메모리에 쌓을까요, 파일에 저장할까요, DB에 넣을까요? 완료한 항목은 지울까요 남겨 둘까요? UI는 순수 HTML 일까요, 컴포넌트 라이브러리일까요?
이 질문들이 답 없이 남는 이유는 두 곳에 있습니다. AI는 이 프로젝트를 처음 보고, 개발자는 자신이 원하는 걸 다 알지 못합니다. Plan Mode는 쓰기를 잠가 탐색을 강제하는 모드로, 이 두 공백을 함께 메웁니다.
빈 책상으로 출근하는 AI

CLAUDE.md 레슨에서 살펴본 것처럼, LLM은 매 세션마다 프로젝트를 처음 보는 신입 사원과 같습니다. CLAUDE.md가 기본 매뉴얼을 건네주지만, 지금 고쳐야 할 코드의 구체적인 맥락까지 담고 있지는 않습니다.
탐색 없이 "코드 짜줘" 요청만 받으면, AI는 빈 책상에서 추측으로 코드를 씁니다. 프로젝트에 이미 있는 유틸을 모른 채 새로 함수를 짜거나, 이 코드베이스에는 쓰이지 않는 라이브러리를 import 하는 결과가 나옵니다.
자신의 요구를 다 알지 못하는 개발자

AI만 빈 책상은 아닙니다. 개발자도 자신이 원하는 걸 처음부터 정확히 알지 못합니다. Todo 앱을 예로 들어 보겠습니다.
- 완료한 항목은 바로 삭제하나요, 취소선만 긋고 남기나요?
- 새로 고침 해도 남아 있어야 하나요, 세션마다 비워지나요?
- 여러 기기에서 동기화되어야 하나요, 혼자만 쓰나요?
- 수정은 어떤 UI로 하나요 (인라인 편집? 별도 모달?)
"간단한 Todo 앱" 한 마디로는 위 질문들이 전부 묻히지만, 코드를 쓰기 시작하는 순간 하나씩 어긋나기 시작합니다. 요구사항이 흐릿한 채로 AI에게 요청을 던지면, AI도 같은 안개 속에서 추측으로 코드를 씁니다.
러버덕킹(Rubber Ducking)이란?
프로그래머들이 책상 위 고무 오리에게 문제를 소리 내 설명하면서 생각을 정리하는 디버깅 기법입니다. 상대에게 풀어 말하는 과정 자체가 막힌 지점을 드러냅니다. Plan Mode는 AI를 이 오리 자리에 앉혀, 반응과 질문을 주고받으며 요구사항을 다듬게 합니다.
Plan Mode: 탐색만 가능한 모드
탐색 후 실행
Plan Mode- 코드베이스 파악
- 기존 패턴 확인
- 계획 수립
즉시 실행
탐색 없이 바로- 추측으로 작성
- 기존 유틸 중복 구현
- 관례에 어긋난 패턴
Plan Mode는 AI의 쓰기 도구(Edit, Write)와 Bash 실행을 잠그고, 읽기 도구(Read, Grep, Glob, LS, 웹 검색)만 쓸 수 있는 모드입니다. Shift+Tab 을 두 번 누르면 진입합니다. 쓰기가 차단돼 있으니 AI는 자연스럽게 코드베이스를 먼저 읽는 쪽으로 움직입니다. 첫 출근한 신입에게 "먼저 코드부터 읽어보고 오라"고 말하는 것과 같은 효과입니다.
탐색 → 계획 → 실행 사이클
작업을 설명하면 AI가 관련 파일을 읽고 현재 구조를 파악합니다. 탐색에는 빠르고 저렴한 모델을 보조로 쓸 수 있으므로, 수만 토큰을 읽어도 비용 부담이 크지 않습니다.
탐색이 끝나면 AI가 변경 계획 초안과 미해결 질문을 함께 내놓습니다. "완료한 항목을 보관할까요, 삭제할까요?" 같은 질문은 개발자가 스스로 물어본 적 없는 것들입니다. AI가 역으로 질문하는 것은 한계가 아니라 사이클의 가장 큰 가치입니다. 답을 주면 AI가 계획을 다시 고쳐 보여 줍니다. 만족스러운 계획이 나올 때까지 주고받기를 반복합니다.
계획을 승인하면 AI가 그 계획에 따라 코드를 작성합니다. 탐색 단계에서 쌓은 맥락이 그대로 이어지므로, 처음부터 "코드 짜줘"로 시작했을 때보다 훨씬 정확한 결과가 나옵니다.
Plan Mode 사이클 따라가기
강사가 Plan Mode의 전체 사이클을 시연합니다. 보면서 다음 세 가지에 주목하세요.
- 읽기 도구만 노출: 터미널에 Read, Grep, Glob 같은 읽기 도구만 뜨고, Edit·Write·Bash는 등장하지 않는 것을 확인하세요
- AI의 역질문: 계획 중간에 AI가 개발자에게 세부사항을 물어봅니다. 이것이 앞서 설명한 러버덕킹의 실제 모습입니다
- 계획 다듬기: 질문과 피드백을 주고받으며 계획이 구체화되는 과정을 보세요. 초안과 최종안을 비교하면 변화가 확실히 드러납니다
핵심 포인트 정리
- '그냥 만들어줘'가 실패하는 데는 두 지점이 있습니다: AI는 세션마다 프로젝트를 처음 보고, 개발자는 자신이 원하는 걸 처음부터 정확히 모릅니다
- Plan Mode는 쓰기를 잠가 탐색을 강제합니다: 파일을 고칠 수 없으니 AI는 추측 대신 코드베이스를 먼저 읽게 됩니다
- 탐색 → 계획 → 실행 사이클은 한 번의 진입으로 이어집니다:
Shift+Tab을 두 번 눌러 Plan Mode에 들어가고 계획을 승인하면 실행 단계로 넘어갑니다. 탐색에서 쌓은 맥락이 실행 단계까지 이어지므로 코드가 더 정확해집니다
FAQ
-
Q: 계획 세우는 시간 자체가 낭비 아닌가요?
- A: 잘못된 방향으로 작성된 코드를 되돌리는 비용이 계획을 검토하는 비용보다 훨씬 큽니다. 계획이 짧으면 검토도 빠르게 끝납니다.
-
Q: 한두 줄짜리 작은 수정에도 Plan Mode를 써야 하나요?
- A: 변경 범위가 명확하고 파일 하나 안에서 끝나는 작업이라면 굳이 쓸 필요 없습니다. Plan Mode는 변경 범위가 흐릿하거나 여러 파일·여러 단계가 얽혀 있을 때 가장 큰 효과를 냅니다.
이어서 배울 내용
Plan Mode로 계획을 주고받는 틀을 배웠습니다. 다음 레슨에서는 그 틀을 채울 재료(AI에게 무엇을 만들지 알려 주는 법)를 익힙니다. AI 협업에 유리한 기술 스택의 선택 기준과, AI가 추측하지 않도록 요구사항을 쓰는 법을 다룹니다.
- AI 협업에 유리한 기술 스택 선택 기준
- 자연어로 스펙 작성하는 방법