요즘 “플랜 모드”라는 말, 들어보셨나요?
Claude Code나 Cursor 같은 AI 코딩 도구를 써보셨다면 플랜 모드(Plan mode)를 한 번쯤 보셨을 거예요. 이게 뭐냐면, AI가 코드를 바로 고치지 않고 먼저 “이렇게 작업하겠습니다” 하는 계획서를 보여준 다음, 사람이 승인하면 그때 실제로 파일을 수정하는 방식이에요. 공사 들어가기 전에 설계도부터 보여주고 도장을 받는 거랑 비슷하죠.
그런데 최근 “Plan mode is dead(플랜 모드는 죽었다)”라는 도발적인 제목의 글이 나왔어요. 이 글에서는 원문의 논지를 그대로 옮기기보다는, 왜 이런 주장이 나올 수 있는지 배경과 양쪽 입장을 같이 정리해볼게요. 저자의 구체적인 주장은 원문에서 꼭 직접 확인해보세요.
플랜 모드는 왜 생겼을까요?
초창기 AI 코딩 에이전트는 솔직히 좀 불안했거든요. 요청을 살짝 오해하고는 엉뚱한 파일 스무 개를 신나게 고쳐놓는 일이 흔했어요. 되돌리기도 번거롭고, 토큰(AI가 처리하는 글자 조각 단위인데, 곧 비용이에요)도 낭비되고요.
그래서 “일단 멈추고, 계획부터 합의하자”는 안전장치로 플랜 모드가 등장했어요. 핵심은 계획 단계에서는 읽기 전용으로만 움직인다는 점이에요. 코드를 읽고 구조를 파악하기만 할 뿐 아무것도 바꾸지 않으니까, 사람이 안심하고 맡길 수 있었던 거죠.
“이제 필요 없다”는 쪽의 논리
플랜 모드가 불필요해졌다는 입장은 대체로 이런 흐름이에요.
첫째, 모델이 똑똑해졌어요. 요즘 모델은 작업하면서 스스로 할 일 목록을 만들고, 중간에 틀린 걸 발견하면 알아서 고쳐요. 별도 모드를 켜지 않아도 계획은 이미 에이전트 안에서 돌아가고 있는 셈이에요.
둘째, 되돌리기가 엄청 싸졌어요. git 브랜치, worktree(저장소 하나로 여러 작업 폴더를 동시에 쓰는 기능), 도구 자체의 체크포인트 기능 덕분에 AI가 잘못 짜도 금방 원상복구할 수 있거든요. 그러면 “계획서를 꼼꼼히 검토하는 시간”보다 “일단 해보고 결과물을 보는 시간”이 더 짧은 경우가 많아져요. 계획서는 결국 말일 뿐이고, 실제 코드와 테스트 결과가 훨씬 정확한 피드백이니까요.
셋째, 계획서에는 함정이 있어요. 그럴듯한 계획서를 승인했는데 실제 구현은 딴 방향으로 흘러가는 일이 생기고요. 사람은 매번 긴 계획서를 받다 보면 대충 훑고 “네 진행하세요”를 누르는 승인 피로에 빠지기 쉬워요. 그러면 안전장치가 형식적인 절차로 바뀌어버리죠.
“그래도 필요하다”는 쪽의 논리
반대편 이야기도 꽤 설득력 있어요. DB 마이그레이션, 결제 로직 수정, 대규모 리팩터링처럼 되돌리기 어렵거나 영향 범위가 큰 작업은 여전히 방향부터 맞추는 게 안전하거든요. 잘못된 방향으로 한 시간 달린 에이전트는 토큰 비용도 크고, 그 결과물을 리뷰하는 사람의 시간도 날아가요.
또 계획은 사람의 이해를 위한 문서이기도 해요. AI가 짠 코드도 결국 사람이 유지보수해야 하는데, 왜 이렇게 설계했는지 맥락을 남겨두는 데 계획 단계가 도움이 돼요.
업계 흐름: “모드”에서 “루프”로
흥미로운 건, 계획이 사라진다기보다 계획이 있는 자리가 바뀌고 있다는 점이에요. 예전에는 매번 대화로 계획을 합의했다면, 요즘은 이런 쪽으로 옮겨가고 있어요.
- 프로젝트 지침 파일: CLAUDE.md, AGENTS.md 같은 파일에 코딩 규칙, 아키텍처, 금지 사항을 적어두면 에이전트가 매번 그걸 읽고 움직여요. 사전 합의를 저장소에 박아두는 거죠.
- 테스트가 곧 명세: 통과해야 할 테스트를 먼저 정해두면, 에이전트는 계획서 대신 테스트를 기준으로 스스로 반복 수정해요.
- 짧은 반복 루프: 크게 계획하고 한 번에 실행하기보다, 작게 시도하고 확인하고 고치는 루프를 빠르게 여러 번 돌리는 방식이에요.
한국 개발자에게 주는 시사점
실무에서 바로 적용해볼 만한 포인트를 정리해볼게요.
1. 작업 크기별로 기준을 정해보세요. 버그 수정이나 작은 기능은 바로 실행하고 결과를 리뷰하고, 스키마 변경이나 여러 모듈에 걸친 작업은 계획부터 받는 식으로요.
2. 되돌리기 쉬운 환경을 먼저 만드세요. 커밋을 자주 하고, 테스트를 갖춰두면 에이전트에게 과감하게 맡길 수 있어요. 결국 테스트 없는 프로젝트는 플랜 모드에 더 의존할 수밖에 없어요.
3. 프로젝트 지침 파일에 투자하세요. 팀 컨벤션을 잘 정리해두면 매번 계획을 검토하는 수고가 확 줄어요.
4. 코드 리뷰 실력이 더 중요해져요. 계획서 대신 결과물을 보고 판단하는 비중이 커질수록, 코드를 빠르고 정확하게 읽는 능력이 핵심 역량이 돼요.
마무리
한 줄 정리: 플랜 모드가 정말 죽었다기보다는, 계획이 “매번 승인받는 절차”에서 “저장소에 내장된 지침과 테스트”로 옮겨가는 중이라고 보는 게 맞을 것 같아요.
여러분은 AI 코딩 도구 쓸 때 플랜 모드를 켜고 쓰시나요, 아니면 바로 실행하고 결과를 보시나요? 어떤 작업에서 플랜 모드가 확실히 도움이 됐는지, 혹은 오히려 방해가 됐는지 경험을 나눠주세요!
🔗 출처: Hacker News