플랜 모드는 죽었다: Nuanced를 만든 개발자가 본 계획 인터페이스의 실패
- 저자는 코딩 속도를 따라잡지 못한 인터페이스 문제를 풀려고 데스크톱 코딩 앱 Nuanced를 직접 만들어 출시했으나 플랜 기반 접근이 실패함
- 플랜 모드의 두 기능 중 에이전트에 줄 정밀한 지시서 역할은 모델이 좋아지면서 빠르게 없어지는 반면 사람이 만드는 것을 이해하는 역할은 그대로 중요하다고 저자는 정리함
- 저자가 보기엔 사람이 시스템을 이해하는 요구는 남지만 플랜 모드는 그에 맞는 잘못된 추상화이며 병렬 에이전트를 여러 개 돌릴수록 부적합해짐
- Nuanced는 스레드별 채팅에서 모호한 점과 사용자 판단이 필요한 결정을 표면화해 영속적인 플랜 문서를 만들고 구현·리뷰·검증까지 이어가는 파이프라인을 지향함
- Codex의 주석 기능이 나오기 전까지 Claude Code CLI, Conductor, Codex를 오가며 플랜 조각을 메시지 사이에서 복사·붙여넣기로 다듬던 workflow가 기존 플랜 모드의 한계를 보여줌
Hacker News opinions
지금 같은 문제 겪고 있는 중임. Qwen 3.8 27b가 슈퍼바이저고 Qwen 3.5 4b가 6~15개 미니언, 검증은 Gemma 4 e4b가 하는 구조인데 플랜이 모든 준비를 앞에서 다 끝내려 해서 몇 분 줄 알던 게 몇 시간 걸리더라.
플래너한테 다 하지 말고 상위 레벨 계획만 짜라고 해. 코드도 구현 디테일도 넣지 말고.
그냥 Opus 5.5 하나 쓰고 신경 안 쓰면 되는 거 아닌가?
슈퍼바이저랑 미니언 그 구성을 어떻게 세팅한 거임? 어떤 하니스 썼어?
더 똑똑한 3.8 27B를 쓸 수 있으면 그냥 전부 그걸로 돌리지 왜 나눠 쓰는 거임?
나는 Claude 플랜 모드 매일 쓰는데 좋기만 함. 플랜에 피드백 줄 게 항상 나오고 쓰기 전에 계획을 확정하는 시간 분리가 필요한데 대체 뭐가 문제라는 건지 모르겠음. 트위터에서 이 '플랜 모드 죽이기' 흐름이 이상함. AI가 일자리를 뺐는다면서 정작 자기가 능동적으로 관여하는 핵심 기능을 없애자고 하네.
맞음. 플랜 모드 없이 어떻게 하는지도 이해가 안 감. 나는 반나절짜리 작은 일이 아니라 사람이면 몇 달에서 1년 걸릴 큰 일을 던지고, 플랜을 살아있는 문서로 만들어서 한두 시간 동안 계속 다듬어. 그다음 TODO.md에 알려진 버그랑 미래 기능을 나눠 관리하게 하고 뭔가 중요한 게 바뀌면 반드시 갱신하게 하지. Claude한테 '지금 어디까지 왔어?' 물어보면 백엔드 이식에서 벡터 로드에 오프셋을 못 접어 넣어서 892개 파일 중 11개가 -O3에서 add를 하나 더 내보낸다는 식으로 답이 나옴. 결과는 맞는데 코드가 길어지는 거지.
AI가 일자리를 없앤다 하는 사람과 플랜 모드 없애자는 사람이 같은 집단이라는 전제가 틀렸음. 서로 다른 그룹임.
나도 이 밀어붙이는 분위기를 이해를 못 하겠음. 켜두는 기능으로 유지하는 건 쉬울 텐데. 다들 우리 모델은 너무 똑똑해서 계획이 필요 없다는 광고처럼 보이는데, 내 워크플로에서 플랜 모드는 좋은 멘탈 리뷰 단계임. Ant 쪽 생각은 그냥 claude한테 계획하라고 하면 된다인 것 같은데 shift+tab이 훨씬 덜 귀찮음.
그 말이 맞아서 내가 Nuanced를 만든 건데, 에이전트 없이 일하던 방식에 인터페이스를 과적합한 것 같음. GitHub에 있을 때 ADR이랑 RFC, 디자인 문서를 많이 썼고 글쓰기가 사고를 명확히 해주는 방식이었거든. 근데 에이전트랑 일하면 내가 직접 쓰질 않아. 대충 의도만 던지면 모델이 빈칸을 채워서 내가 명시적으로 내리지 않은 결정들이 잔뜩 들어간 매끈한 플랜이 돌아오지. 플랜이 기술적으로 정확해도 핵심이 묻혀서 내 사고와 멀어져서 리뷰가 어려움. 그래서 협업 단계는 여전히 필요한데 플랜 모드 같은 생성된 산문이 맞는 인터페이스라는 생각은 줄어듦.
플랜 모드가 뭐가 문제라는 건지 잘 모르겠음. 면접하듯 질문을 주고받는 것까지 넣으면 실제 변경 전에 제안된 변경이 다 말이 되는지 확신할 수 있는 상태까지 갈 수 있거든. 이 글은 현실보다는 상업적 목적으로 보이고, VS Code 부가기능에는 예전부터 플랜 모드에서 선택하고 주석다는 기능이 있었는데 그걸 무시하더라. 'X는 죽었다' 류 문구는 10년 전에 질린 건데 아직 재등장할 때는 아닌 듯.
플랜 모드가 죽은 진짜 이유는 그냥 대화로 저장소 수정하지 마, 특정 문서만 수정해 라고 지시하면 에이전트가 따른다는 거임. 선택적 도구 사용으로 강제하던 시대는 지났음.
그건 기본적으로 플랜과 결정의 감사 기록도 안 남음. 내 변경 프롬프트는 대부분 '변경 X 계획 제안해서 파일 Y에 써라', '파일 Y의 M~N단계 실행해라' 식인데 이 과정이 왜 필요한지는 시간과 주의를 낭비해봐야 알게 됨. 그냥 대화로 만드는 방식은 낭비행 급행임.
오용 확률이 줄었다고 샌드박스 장치를 빼는 건 무모함.
동의함. 예전 모델이 제멋대로여서 플랜 모드가 나온 건데 지금 모델은 지시를 잘 따르니 별도 모드가 필요 없지. 다만 계획용으로 더 똑똑한 모델을 따로 쓰고 끝나면 감사를 위해 남기는 건 여전히 값어치가 있음. 플랜 모드 쓸 거면 같은 것도 있고, 나는 기본 모델로 방향을 잡은 다음 더 똑똑한 리뷰어와 반복해서 플랜 파일을 수렴시킴.
Claude Code의 플랜 모드가 사실상 폐기 수순에 접어든 건 '컨텍스트 비우고 구현' 옵션을 플래그 뒤로 숨겼을 때임. 그때 토론에서도 개발자들이 레거시 기능으로 보는 것 같았고, 새 모델은 긴 컨텍스트에서 굳이 이게 필요 없다는 쪽이었음.