계획 모드는 죽었다

Claude Code 개발에 참여하고 있으며, 계획 모드가 예전에는 유용했지만 이제는 그렇지 않다는 글의 요지에 대체로 동의함. Claude Code의 계획 모드는 매 사용자 메시지에 “계획 모드이니 아직 코딩하지 말라”는 짧은 안내를 붙이는 기능일 뿐임. 몇 달 전 일요일 밤, 새 세션마다 코딩 전에 함께 계획부터 세우자고 요청하기 귀찮아져서 만든 기능임. 계획 모드는 처음부터 프롬프트였으며 도구 구성을 바꾼 적은 없음. 도구를 바꾸면 프롬프트 캐시가 깨져 사용자 비용이 늘어나기 때문임. 몇 달 전 Fable 초기 버전을 쓰면서 모델이 의도를 알아듣고, 복잡한 작업의 계획 수립도 대화와 반복 수정으로 바뀌면서 계획 모드를 더는 쓰지 않게 됨. Opus 5.5도 이제 그 수준에 도달한 느낌임.
코드베이스를 이해하기 위해 변경 사항을 설명하는 자료를 만들어 달라고 요청하기도 함. 핵심 부분의 복잡한 변경에는 다이어그램이나 대화형 데모를 요청해 변경 내용과 검토한 대안을 이해함. 다른 사람과 미래의 Claude도 맥락을 파악할 수 있도록 이런 자료를 PR에 첨부하게 함.

내 경우는 정반대이며, Claude Code의 계획 모드만으로는 턱없이 부족함. 먼저 계획을 마크다운 파일로 작성하게 하고 plannotator로 검토하며 여러 차례 수정함. 대개 코드보다 주석이 걸림돌임.
그다음 새 세션에 계획을 전달하고 모호한 부분, 걸림돌, 빠뜨린 사항을 찾아 해결한 뒤 구현하게 함. 다시 plannotator로 검토하고 수정한 후 PR을 올림. 상상하던 바이브 코딩과는 다르겠지만, 코드·아키텍처·품질을 충분히 파악하고 장기적인 품질 저하도 방지할 수 있음.

구현에 시간을 잔뜩 낭비하기 전에 모델이 내릴 결정을 미리 확인할 수 있어 유용함. 모델이 똑똑해져도 내 의도를 잘못 추측한다면 불충분한 명세는 해결되지 않음.

계획 모드가 쓸모없어진 게 아니라 Claude Code의 구현이 부족한 것은 아닐까? 다른 에이전트 실행 환경에서는 계획 모드가 작업 흐름을 안정시켜 줌. 코드 생성은 전체 과정의 일부일 뿐이며, 작업을 실제 운영 환경에 배포하기까지의 과정에 구조를 부여하고 변경을 확정하기 전에 재정비할 기회를 줌.
지속 가능한 속도로 늦추는 것이 결과적으로 전체 과정을 더 빠르게 만듦. Claude의 계획 모드가 코드 생산을 가속하려는 목적이고 oh my pi의 계획 모드는 전략적인 목적이라면 평가가 다른 이유도 여기에 있을 수 있음. 억지로 쓸 필요는 없지만, 작업 흐름에서 제거하려면 가능한 부작용을 주의해야 함.

계획 모드는 코드베이스에 대한 머릿속 모델을 갱신하기 쉽게 해 줌. 필요한 변경을 모두 이해하고 유지하는 인지적 부담을 감수할 가치가 있는지도 판단할 수 있음. 이제 이것들이 가장 큰 제약이며, 코드 변경분을 일일이 읽는 방식은 더 이상 규모를 감당하지 못함.

모델이 의도를 알아듣는다는 데 동의하지 않음. Fable 5.1에 인증서로 원격 시스템과 안전하게 통신하는 짧은 Go 함수와 사용법을 요청했더니, 요구하지도 않은 파일 기반 개인 키를 강제함. 개인 키 파일 인자를 받고 tls.LoadX509KeyPair를 호출했는데, Go에는 HSM이나 KMS 등의 개인 키도 지원할 수 있는 crypto.Signer 가 있음. 보안을 제대로 이해한다면 개인 키 자체를 직접 제공해야 하는 설계를 택하지 않았을 것임.
Claude만의 문제는 아니며 ChatGPT와 Gemini도 각자의 차이는 있지만 비슷하게 동작함. ChatGPT만 서버 인증용 CA 파일을 받도록 해서 그 부분은 더 나았음. LLM이 소프트웨어 개발의 미래이자 어쩌면 현재이지만, 일부 영역에서 완전히 손을 떼기까지는 갈 길이 남아 있음. 여전히 설계 방향을 바로잡아야 하며 계획 모드가 여기에 도움이 됨.

개발자들이 코드를 이해하지 못하게 되고, 코드 검토는 의견 없는 승인 표시로 축소되며, 코드베이스는 아무도 읽지 못하는 비대한 덩어리가 되는 모습을 지켜보고 있음. 출시한 코드를 이해하고 책임져야 한다는 원칙이 무너지고 있음. 제품도 Conway의 법칙을 반영하듯 불투명해져, “명백한 결함이 없을 만큼 단순한” 대신 “명백한 결함을 알아볼 수 없을 만큼 복잡한” 형태가 됨.
계획 모드는 적어도 사람이 전략을 이해하고 설계와 아키텍처를 살펴볼 수 있게 도왔음. 자기 절제와 에이전트 통제로도 가능하지만 점점 이기기 어려운 싸움처럼 느껴짐. 뛰어난 개발자는 여전히 좋은 코드를 만들지만, 부족한 개발자는 아무것도 배우지 않으면서 지표만 좋아짐. 곧 갚아야 할 막대한 기술 부채를 쌓고 있다는 생각을 떨치기 어려움.

일부는 사실상 AI를 프로젝트의 의존성으로 추가하고 있음. 더는 자기 코드를 이해하지 못함.

비슷하게 느끼지만 초기 실험 결과 중 일부는 성공적으로 리팩터링했음. 우리 팀은 과거 대비 생산량 2배를 목표로 하되, AI로 모르는 것을 배울 수 있으니 제품 비전은 더 야심 차게 잡음. 코딩 2일, AI와 학습 3일을 목표로 삼아 효율 향상을 단순한 코드 증산보다 역량 개발에 활용함.

예전에도 서두르면 엉망이 됐듯 LLM으로 서둘러도 마찬가지임. 다만 속도와 규모가 업계에서 본 적 없는 수준으로 커질 것임.

시스템을 이해해야 한다는 데는 동의하지만, 이해를 놓쳤다고 해서 거대한 코드 더미를 반드시 수작업으로 헤쳐 나가야 한다는 전제에는 동의하지 않음. 코드베이스를 모르겠다면 에이전트에게 설명을 요청하면 됨. 최신 최상위 모델은 코드 작성보다 설명을 더 잘하기도 함. 말로 풀어 주고, 아키텍처·시퀀스 다이어그램을 만들고, 가정을 검증하는 테스트와 스크립트를 작성하며, 원하는 설계에 맞춰 리팩터링할 수도 있음.
이를 받아들이면 에이전트가 더 빠르고 잘 일할 수 있는 구조와 도구에 집중할 수 있음. 에이전트끼리 지시하는 폐쇄 루프를 만들고, 시스템의 검증 가능성과 결정성을 높여 강력한 속성 기반 테스트를 작성하게 하면 됨. 무엇을 왜 만드는지, 외부에서 관찰 가능한 모든 속성을 어떻게 검증할지에 집중하고 내부 구현은 에이전트에 맡길 수 있음. 이제 코드는 사실상 우리를 위한 것이 아님.

자기가 하는 일을 이해하기를 포기하는 모습이 정말 기이함. 나는 실행 계획 자체보다 기능 구현이나 버그 수정에서 생길 잠재적 문제를 이해하려고 계획 모드를 자주 사용함. AI의 가정이 틀리거나 전체 목표와 어긋나서 발견 사항을 고치거나 다시 쓰는 일도 흔함.
그런데도 잘못된 방향으로 가는 AI에 모든 결정을 맡겨도 괜찮다는 태도가 많음. 실제 작업에는 관심 없이 돈이나 지위만 보고 소프트웨어 업계에 들어온 이들이 아닌가 싶음.

업무에서 주로 Gemini CLI를 쓰는데, 계획 모드에서는 탐색 목적의 명령조차 실행할 수 없다는 점이 불편함. 실험하지 못한 채 학습 데이터나 내가 제공한 소스 코드·문서에 의존하니, 맥락의 상세함에 따라 자주 틀리게 됨. Python 한 줄 명령으로 실험할 수 있는 것만으로도 큰 도움이 됨. 예를 들어 D2로 SVG 그래프를 만들 때 Python으로 XML을 살펴 크기나 좌표가 제대로 배치됐는지 확인할 수 있음. 내가 렌더링 결과를 직접 보기 전에 저렴하게 실험하고 검증하는 방법임.

모델에게 계획을 세우고 질문하게 해도 질문이 핵심을 벗어나는 경우가 여전히 많음. “기존 시스템을 쓸까요, 다른 언어로 완전히 새로 만들까요?” 같은 질문에는 잔뜩 답해야 하는데, 정작 정말 모호한 부분은 멋대로 가정함.

계획 모드가 불필요해진 진짜 이유는 대화로 저장소를 변경하지 말라거나 특정 문서만 수정하라고 지시해도 에이전트가 따르기 때문임. 예전에는 사용 가능한 도구를 제한해 강제해야 했지만 이제 그 단계는 넘어섰음.

오용 가능성이 낮아졌다는 이유만으로 샌드박스 안전장치를 두지 않는 건 현명하지 않아 보임.

대화만으로 진행하면 적어도 기본적으로는 계획과 결정의 감사 기록도 남지 않음. 내 변경 지시는 주로 “변경 X의 계획을 제안해 파일 Y에 작성하라”, “파일 Y의 M~N 단계를 실행하라”는 형태임.
시간과 주의를 낭비해 보기 전에는 이런 절차의 가치를 알아보기 어려움. 대화만으로 만들어 나가는 건 낭비로 가는 급행열차임. 무엇을 만들고 싶은지 이해하지 못한 채 왜 Claude와 대화하는지도 잘 모르겠음.

초기 모델은 제멋대로 움직여서 계획 모드가 필요했지만, 지금 모델은 별도 모드가 필요 없을 만큼 지시를 잘 따름. 다만 실행용보다 더 똑똑한 모델로 계획하고, 완료 후 감사를 위해 계획을 저장하는 것은 여전히 가치가 있음.
계획 모드를 쓴다면 https://plannotator.ai/도 괜찮을 수 있음. 나는 기본 모델과 대화하며 방향을 잡은 뒤, 더 똑똑한 검토 모델과 반복해서 결함을 찾으며 계획 파일을 다듬음.

아직 Claude Code의 계획 모드를 꽤 많이 사용함. 원하는 내용과 대체로 맞을 때까지 계획을 반복해서 수정하고, 괜찮아지면 구현한 뒤 PR을 열도록 요청함.
유일한 아쉬움은 반복 수정 중 계획의 변경분을 더 쉽게 볼 수 없다는 것임. 이미 검토한 부분과 새로 검토해야 할 부분을 기억하는 데 드는 노력이 아까움. 개선도 생각했지만, 비효율적이더라도 검토 자체가 사고 과정이라고 느껴 일부러 없애지 않고 있음.

기능 구현이나 버그 수정 아이디어를 써 줄 때는 사람조차 첫 시도에 의도를 이해하리라 믿지 않음. 내 실수나 상대의 잘못된 가정이 언제나 끼어듦. 전체를 깨뜨리는 조건을 빠뜨리거나 앞서 말한 내용과 모순되는 부분을 확인해야 함.
모델이 아무리 좋아졌다 해도 사람보다 내 의도를 잘 이해하리라고 믿기는 어려움. 이 글은 결국 일단 코딩하고 질문은 나중에 하는 바이브 코딩을 권하는 것으로 보임. 여러 상황에서 타당한 선택일 수는 있지만, 적어도 그것이 무엇인지는 정확히 불러야 함.

지금은 계획용 스킬 묶음을 사용해 계획 모드와 비슷한 일을 하되, 후속 스킬이 참조할 문서를 생성하게 함. 기능을 구현하는 내내, 에이전트·모델·작업이 바뀌어도 방향을 유지해 줘서 지금까지 시도한 방법 중 가장 잘 작동함. 아직 이런 방식을 도입하지 않은 경우가 많고, 각자 작업 흐름을 만드는 무법지대처럼 느껴짐.
코딩을 일일이 지도하지 않게 될수록 진행 상황을 살필 다른 수단이 필요함. 현재 계획의 어느 단계인지, 테스트가 실제로 무엇을 하는지, 에이전트별 담당은 무엇인지 알아야 함. 이를 잘 해내는 제품은 아직 찾지 못했으며, 이것이 IDE의 다음 영역처럼 보임. 개발 환경보다는 통합 관리 환경에 가까울 것임. 가장 비슷했던 것은 whiteboard였지만 직접 써 본 결과는 좋지 않았음. https://dev.fast.

큰 프로젝트에 LLM을 써 보면 데이터와 기능이 고립되지 않는 것이 얼마나 유용한지 알 수 있음. CLI 앱이 다시 주목받는 이유도 LLM이 직접 다룰 수 있기 때문임. 그런데 정작 LLM 개발에 깊이 관여하는 이들 상당수는 또 하나의 고립된 앱을 만들고 있음.
더 나은 모델이 필요함. 대안으로는 거의 모든 작업을 담는 범용 도구가 있음. 터미널이나 텍스트 편집기·워드프로세서가 그런 역할을 할 수 있으며, 나는 모든 작업에 Emacs를 사용함. 업무 환경에서는 스프레드시트가 가장 좋은 선택일 가능성이 큼.