[특집] 플랜 모드는 죽었다 — AI 코딩에서 '계획서'는 사라지고 '이해'의 문제만 남았다

크게 보기

들어가며: 계획에 모든 것을 걸었던 사람

글은 이렇게 시작합니다.

올해 초까지만 해도 나는 AI로 소프트웨어를 만들 때 계획이 가장 중요한 부분이 될 거라고 믿었다. 그 믿음이 얼마나 강했던지, 그 생각 하나를 중심으로 데스크톱 코딩 앱을 통째로 만들어 출시했다.

쓴 사람은 아이먼 나딤(Ayman Nadeem) 입니다. GitHub에서 7년 넘게 정적 분석 도구를 만들고 키웠던 시니어 엔지니어로, 2023년 공동 창업자 딜런 드로버와 함께 Y Combinator(W24) 출신 스타트업 Nuanced를 세웠습니다. 그리고 2026년 9월 24일, 자기 블로그에 「Plan mode is dead(플랜 모드는 죽었다)」라는 글을 올렸습니다.

이 글이 특별한 이유는 제목의 도발보다 쓴 사람의 위치에 있습니다. 바깥에서 "플랜 모드 별로던데요"라고 말하는 사용자가 아니라, 플랜 모드가 부족하다고 느껴 더 좋은 플랜 모드를 제품으로 만들었던 사람이 "내가 틀렸다"고 말하는 글입니다.

반응은 빨랐습니다. 다음 날 해커뉴스 첫 화면에 올라 9월 27일 기준 553점, 댓글 477개가 달렸습니다. 맨 위 댓글은 다름 아닌 Claude Code를 만든 보리스 체르니(Boris Cherny) 의 것이었습니다.

[저는 Claude Code를 만듭니다] 대체로 동의합니다. (…) 플랜 모드는 쓸모가 있었고, 이제는 쓸모가 없습니다.

플랜 모드를 만든 사람과 더 나은 플랜 모드를 만들려던 사람이 같은 결론에 이른 셈입니다. 무슨 일이 있었던 걸까요? 먼저 글 전체의 흐름을 한눈에 보겠습니다.

원문은 길지 않지만, 그 뒤에는 소프트웨어 공학이 56년 동안 벌여 온 오래된 논쟁이 숨어 있습니다. "먼저 계획하라"와 "만들면서 배워라"의 줄다리기입니다. 그 이야기부터 시작해 보겠습니다.

---

1부. 플랜 모드란 무엇이었나

Shift+Tab 두 번, "아직 코드는 쓰지 마"

AI 코딩 도구를 써 보지 않은 분을 위해 짧게 설명하겠습니다.

2025년 초의 코딩 에이전트는 빠르지만 성급했습니다. "로그인 기능 만들어 줘"라고 하면 저장소를 제대로 둘러보지도 않고 파일 열두 개를 고쳐 버리곤 했습니다. 방향이 틀렸다는 걸 알았을 때는 이미 수천 줄이 쌓여 있었고, 그걸 읽고 걷어내는 건 사람 몫이었습니다.

그래서 등장한 것이 플랜 모드(plan mode) 입니다. 2025년 6월 무렵 Claude Code에서 Shift+Tab을 두 번 누르면 켜지는 기능으로 널리 쓰이기 시작했고, 같은 달 Windsurf도 '플래닝 모드'를 내놓았습니다. 원리는 단순합니다.

비유하자면 인테리어 공사 전에 도면을 먼저 보여 달라고 하는 것입니다. 벽을 부순 뒤에 "여기 말고 저기였는데요"라고 하면 늦으니까요.

재미있는 건 이 기능의 속사정입니다. 해커뉴스 댓글에서 체르니는 이렇게 털어놓았습니다.

플랜 모드가 하는 일은 사용자 메시지마다 작은 알림을 덧붙이는 것뿐입니다. "지금은 플랜 모드입니다. 아직 코드를 쓰지 마세요." (…) 어느 일요일 밤 늦게 떠올린 아이디어였죠. 플랜 모드는 처음부터 끝까지 프롬프트였습니다. 도구 목록을 바꾼 적도 없습니다. 그렇게 하면 프롬프트 캐시가 깨지거든요.

즉 플랜 모드는 모델에게 특별한 능력을 준 게 아니라, "잠깐 멈추고 생각부터 말해"라는 말버릇을 기능으로 만든 것이었습니다.

스펙 주도 개발 붐

2025년 여름에는 한 걸음 더 나아간 흐름이 생겼습니다. 스펙 주도 개발(spec-driven development) 입니다.

말하자면 업계 전체가 "AI에게 일을 맡기려면 문서부터 잘 써야 한다"는 쪽으로 기울었습니다. 나딤의 Nuanced도 이 흐름 위에 있었습니다. 2026년 6월에는 스스로를 '스펙 주도 개발 작업 공간'이라 불렀고, 광고 문구는 "생각하기 위한 AI 코딩 앱" 이었습니다.

플랜 모드의 두 가지 일

나딤은 글 초반에 이 모든 도구가 해 온 일을 두 가지로 나눕니다. 이 구분이 글 전체의 열쇠입니다.

크게 보기

역사적으로 플랜 모드는 두 가지 목적을 가졌다. (1) 에이전트가 따를 수 있을 만큼 정확한 지시를 명세했고, (2) 사람이 자기가 무엇을 만들고 있는지 이해하도록 도왔다.

나는 1번이 모델이 좋아지면서 빠르게 쓸모없어지고 있다고 생각한다. 2번은 그 어느 때보다 중요하다. 하지만 플랜 모드는 그 일에 맞는 추상화가 아니다. 우리가 동시에 돌리는 에이전트 수가 늘수록 더욱 그렇다.

"플랜 모드는 죽었다"는 제목만 보면 "이제 생각 없이 AI에게 맡기면 된다"는 말처럼 들립니다. 그런데 실제 주장은 정반대에 가깝습니다. 사람이 이해해야 한다는 필요는 더 커졌는데, 그 필요를 채우는 방식이 틀렸다는 겁니다. 이 차이를 놓치면 글 전체를 오해하게 됩니다.

---

2부. 56년 묵은 논쟁: 먼저 계획할까, 만들며 배울까

플랜 모드를 둘러싼 논쟁은 AI와 함께 태어난 게 아닙니다. 소프트웨어라는 분야가 생긴 이래 계속된 싸움의 최신판입니다. 아래 연표를 눌러 가며 따라가 보세요.

폭포수의 원전은 폭포수를 경고했다

소프트웨어 공학 수업에서 '폭포수 모델'을 배울 때 늘 따라 나오는 이름이 윈스턴 로이스(Winston Royce) 입니다. 1970년 8월 발표한 「대형 소프트웨어 시스템 개발의 관리」에 요구사항 → 설계 → 구현 → 테스트 → 운영이 계단처럼 흘러내리는 그림이 있기 때문이죠.

그런데 논문을 실제로 읽어 보면 반전이 있습니다. 로이스는 그 그림 바로 다음에 이렇게 씁니다.

나는 이 개념을 믿는다. 하지만 위에서 설명한 구현은 위험하고 실패를 부른다.

이유도 분명히 적었습니다. 테스트 단계가 되어서야 처음으로 타이밍·저장 공간·입출력 같은 것들이 "분석된 것이 아니라 실제로 경험되는" 순간이 오는데, 그때 설계 결함이 드러나면 일정이나 비용이 최대 100%까지 초과될 수 있다는 겁니다. 그래서 로이스가 내놓은 처방 중 하나가 이것이었습니다.

크게 보기

3단계: 두 번 만들어라(DO IT TWICE).

5단계: 고객을 참여시켜라. (…) 요구사항은 합의한 뒤에도 폭넓게 해석될 수 있다.

공정하게 말하면, 로이스는 같은 논문에서 "소프트웨어 개발 관리의 첫 번째 규칙은 문서화 요구를 무자비하게 강제하는 것"이라고도 썼습니다. 문서를 버리자는 사람은 아니었습니다. 다만 "한 번에 쭉 흘러내려 끝낸다"는 그림은 로이스가 위험하다고 경고한 버전이었는데, 세상은 경고 대신 그림을 베껴 갔습니다. 참고로 논문에는 '폭포수(waterfall)'라는 단어가 한 번도 나오지 않습니다.

5년 뒤 프레더릭 브룩스는 『맨먼스 미신』에서 같은 이야기를 더 짧게 했습니다.

그러니 하나는 버릴 계획을 세워라. 어차피 그렇게 될 테니.

그런데도 왜 모두 "먼저 계획"했나: 변경 비용 곡선

로이스와 브룩스가 경고했는데도 업계가 수십 년 동안 앞쪽의 계획에 매달린 데는 합리적인 이유가 있었습니다.

1981년 배리 보엠(Barry Boehm) 은 『소프트웨어 공학 경제학』에서 TRW·IBM 등의 프로젝트 데이터를 모아, 결함을 늦게 발견할수록 고치는 비용이 단계마다 가파르게 뛴다는 것을 보여 줬습니다. 요구사항 단계에서 한 줄 고치면 될 일이, 배포 후에는 설계를 뜯고 데이터를 옮기고 고객에게 사과하는 일이 됩니다.

천공 카드를 쓰던 시절을 떠올려 보세요. 코드를 한 줄 고치면 카드를 새로 뚫어 제출하고 다음 날 결과를 받았습니다. 한 번 잘못 가면 하루가 날아가는 세상에서는 오래 생각한 뒤 한 번에 가는 것이 가장 싼 전략이었습니다.

1999년 켄트 벡(Kent Beck) 은 이 곡선을 뒤집어 읽었습니다.

폭포 모델은 그냥 나타난 게 아니다. 소프트웨어를 바꾸는 비용이 시간이 갈수록 극적으로 오른다는 충격적인 측정에 대한 합리적 반응이었다.

그렇다면 반대로, 변경 비용을 낮추면 계획을 미리 다 할 이유도 사라지지 않을까? 테스트 자동화, 지속적 통합, 작은 배포로 곡선을 눕힌다면 분석·설계·구현·테스트를 "조금씩, 개발 내내" 섞어도 된다는 것이 익스트림 프로그래밍(XP)의 기술적 전제였습니다. 벡은 고객에 대해 이런 문장도 남겼습니다.

그들은 몰랐다. 스스로 모순됐다. 마음을 바꿨다.

2년 뒤인 2001년 2월, 17명이 유타의 스키장에 모여 애자일 선언을 씁니다. "포괄적인 문서보다 작동하는 소프트웨어를", "계획을 따르기보다 변화에 대응하기를".

아래 그래프에서 시대를 바꿔 가며 '가장 싼 계획량'이 어디로 움직이는지 보세요. 이 곡선이 이 특집 전체를 꿰는 직관입니다.

핵심은 이겁니다. 계획을 얼마나 할지는 취향이 아니라 경제학입니다. 잘못 간 길을 되돌리는 비용이 크면 계획이 이득이고, 작으면 만들어 보는 게 이득입니다. 나딤도 정확히 이 논리를 씁니다.

예전에는 잘못된 방향으로 가는 비용이 훨씬 컸다. 하지만 에이전트가 시스템을 더 잘 이해하게 되면서, 스스로 행동하고 자기 작업을 테스트하는 능력도 좋아졌다.

2024~25년 초기 에이전트는 되돌리기 비용이 컸습니다. 에이전트가 쓴 엉뚱한 코드 수천 줄을 사람이 읽고 걷어내야 했으니까요. 플랜 모드는 그 시기에 딱 맞는 도구였습니다. 2026년의 에이전트는 방향이 틀리면 스스로 테스트를 돌려 알아채고 몇 분 만에 다시 씁니다. 곡선의 바닥이 왼쪽으로 미끄러진 것입니다.

설계는 재료와의 대화

계획의 경제학과 별개로, 사람이 실제로 어떻게 생각하는가를 다룬 연구 흐름도 있습니다.

1973년 도시계획가 호르스트 리텔과 멜빈 웨버는 사회 정책 문제를 연구하며 '고약한 문제(wicked problem)'라는 개념을 만들었습니다. 그들의 관찰은 날카롭습니다.

문제를 이해하는 데 필요한 정보는, 그 문제를 어떻게 풀 생각인가에 달려 있다. (…) 먼저 이해하고, 그다음에 해결할 수는 없다.

쇼핑몰 쿠폰 기능을 예로 들어 볼까요. "첫 구매 고객에게 10% 쿠폰"이라는 요구는 명확해 보입니다. 그런데 막상 만들어 보면 질문이 쏟아집니다. 회원 등급 할인과 겹치면? 탈퇴 후 재가입하면 또 '첫 구매'인가? 해외 카드는 반올림이 다른데? 이 질문들은 만들기 시작해야 비로소 보입니다. 책상 앞에서 아무리 오래 생각해도 다 떠오르지 않습니다.

1983년 도널드 쇤(Donald Schön) 은 『성찰적 실천가』에서 건축가, 치료사, 경영자 같은 전문가들이 실제로 일하는 모습을 관찰했습니다. 그들은 머릿속 설계도를 그대로 옮기지 않았습니다.

크게 보기

나는 설계를 상황의 재료와 나누는 대화로 보려 한다. (…) 상황이 말대꾸를 하고, 설계자는 그 말대꾸에 응답한다.

쇤은 1996년 인터뷰에서 이를 더 쉽게 풀었습니다. "설계자가 설계를 미리 머릿속에 다 갖고 있다가 그저 옮기기만 하는 경우는 드물다." 도예가는 흙을 만지며 "여기가 너무 얇네"라는 흙의 대답을 듣고 손을 고칩니다. 요리사는 레시피를 끝까지 읽고 불을 켜는 게 아니라 맛을 보며 간을 맞춥니다.

크게 보기

2022년 10월에는 AI 연구에서도 같은 결론이 나옵니다. 프린스턴과 구글 연구진의 ReAct 논문은 언어 모델이 생각(Thought) → 행동(Action) → 관찰(Observation) 을 번갈아 할 때 "계획을 세우고, 추적하고, 고쳐 나간다"는 것을 보였습니다. 한 번에 긴 계획을 세우고 끝까지 밀어붙이는 것보다, 조금 생각하고 조금 해 보고 결과를 보는 편이 더 잘 풀었습니다. 오늘날 거의 모든 코딩 에이전트가 이 루프 위에서 돌아갑니다.

그리고 가장 중요한 연결고리: 나우르

이 특집에서 가장 중요한 인물은 따로 있습니다. 튜링상 수상자 피터 나우르(Peter Naur) 가 1985년에 쓴 짧은 에세이 「이론 쌓기로서의 프로그래밍」입니다.

크게 보기

나우르의 주장은 이렇습니다. 프로그래밍의 진짜 결과물은 코드도 문서도 아닙니다.

프로그래밍은 프로그래머가 어떤 통찰, 즉 이론을 형성하는 활동으로 보아야 한다.

이 '이론'이란 "이 시스템은 왜 이렇게 생겼고, 이 부분을 바꾸면 어디가 흔들리며, 이 요구가 들어오면 어디를 고치면 되는가"를 아는 감각입니다. 나우르는 이 앎이 원리적으로 규칙이나 문서로 다 옮겨질 수 없다고 봤습니다. 그래서 이렇게 씁니다.

새로 온 사람이 프로그램 텍스트와 다른 문서들을 익힐 기회를 갖는 것만으로는 불충분하다.

프로그램의 죽음은 그 이론을 가진 프로그래머 팀이 해체될 때 일어난다.

회사에서 겪어 보신 분이 많을 겁니다. 코드도 있고 위키도 있는데, 그 시스템을 만든 사람이 퇴사하면 아무도 손을 못 댑니다. 문서에는 "무엇을"이 적혀 있지만 "왜 다른 방법이 아니라 이 방법인지"는 사람 머릿속에만 있었기 때문입니다.

나우르를 알고 나면 나딤의 실패가 새롭게 보입니다. 스펙 문서에 계획을 담으면 이해도 담길 거라는 기대, 그것이 바로 나우르가 40년 전에 불가능하다고 한 일이었습니다.

---

3부. Nuanced 이야기: 계획에 집을 지어 주고 싶었다

좀비가 된 기분

나딤이 Nuanced를 만든 동기는 솔직하고 공감이 갑니다.

크게 보기 원문 삽화: 코드 생성 속도는 로켓처럼 빨라졌는데, 그걸 다루는 인터페이스는 아직 마차다. (출처: Ayman Nadeem, 「Plan mode is dead」)

모델은 몇 분 만에 수천 줄을 쓸 수 있었다. 즉 무엇을 왜 만드는지 생각해 보기도 전에 거대한 유지보수 부담을 물려받는다는 뜻이었다.

코드를 쉽게 만드는 쾌감은 컸지만, 그 뒤에 숨는 게 있었습니다. 이게 왜 중요한지, 중요하긴 한지, 제품·디자인·인프라 결정을 제대로 따져 보는 불편한 일입니다. 나딤은 이렇게 고백합니다.

나는 종종 제품 결정을 의식적으로 내리기도 전에 제품을 갖고 있었다. 내가 아키텍처를 덜 명세하면, 에이전트가 그 빈틈을 멋대로 채웠다.

크게 보기 원문 삽화: 에이전트가 만든 코드 속에서 길을 잃다. (출처: Ayman Nadeem)

문제는 이런 오해들이 채팅 표면 아래 여러 파일 깊숙이 퍼져 나간다는 점이었습니다. 겉으로는 대화가 매끄러운데, 수면 아래에선 인증 모듈에 숨은 가정, 스키마에 박힌 제품 결정, API 경계에 스민 의도가 엉켜 있었습니다.

크게 보기 원문 삽화: 채팅 수면 아래를 낚시하듯 문제를 찾아다니기. (출처: Ayman Nadeem)

Conductor나 Codex 앱처럼 에이전트 여러 개를 병렬로 돌리는 도구가 나오면서 증상은 더 심해졌습니다.

이 경험에는 나를 정신적으로 단절된, 좀비 같은 상태로 만드는 무언가가 있었다. (…) 예전만큼 깊이 집중하고 이해할 수 없다고 느꼈다. 그래서 생성된 결과가 맞는지 검증하기도 더 어려워졌다.

주목할 점은 나딤이 코드를 한 줄씩 보던 시절로 돌아가고 싶었던 게 아니라는 것입니다. 오히려 자연어로 아이디어를 다루는 편이 더 쉽고 효율적이라고 느꼈습니다. 원한 건 이것이었습니다. "코드 위를 자신 있게 항해하되, 시스템이 어떻게 돌아가는지에 대한 이해는 잃지 않는 것."

계획이 백스크롤로 사라진다

당시 플랜 모드의 가장 큰 불편은 계획이 머물 집이 없다는 것이었습니다. Claude Code CLI에서 Conductor로, 다시 Codex로 옮겨 다니는 동안 나딤은 계획을 채팅으로 다듬고, 고칠 부분을 복사해 새 메시지에 붙여 넣는 일을 반복했습니다. 계획은 대화가 길어질수록 스크롤 위로 사라지는 "덧없는 텍스트 덩어리"였습니다.

그래서 계획을 살아 숨 쉬는 영속 문서로, 개발을 이끄는 '일급 요소'로 만들고 싶었습니다. 이유는 네 가지였습니다.

꿈의 워크플로

Nuanced는 이렇게 동작했습니다. '스레드'를 열어 만들고 싶은 것을 이야기하면, 시스템이 모호한 점과 사람이 정해야 할 결정을 짚어 주고, 함께 영속적인 계획에 도달한 뒤에야 구현이 시작됩니다. 그리고 Nuanced가 그 계획대로 구현하며 요구사항을 지키는지 확인합니다. 의도에서 출발해 구현, 리뷰, 검증까지 이어지는 끝에서 끝까지의 파이프라인이었습니다.

나딤은 이것을 단순한 코딩 앱이 아니라 "인간 정신을 위한 보철물(혹은 내 ADHD 머리를 위한)"로 봤다고 씁니다. 지시하는 도구인 동시에 무슨 일이 일어나는지 놓치지 않게 해 주는 도구.

아이디어만 보면 흠잡을 데가 없습니다. 그런데 왜 실패했을까요?

---

4부. 네 가지 오판

나딤은 "기존 도구의 빈틈이나 개발 방식이 바뀌고 있다는 생각 자체가 틀린 건 아니었다"고 먼저 선을 긋습니다. 틀린 건 구현이었고, 이유는 네 가지였습니다.

• 나는 계획하기(planning)와 계획서(a plan)를 혼동했다
• 모델이 정말 좋아졌다
• 아무도 AI가 쓴 글을 읽고 싶어 하지 않는다
• 우리는 계획과 구현을 흐름을 끊는 방식으로 떼어 놓았다

하나씩 사례와 함께 보겠습니다.

오판 1. 계획하기 ≠ 계획서

첫 번째로 배운 것은 우리가 계획하기와 계획서를 혼동했다는 사실이다. 둘은 같은 것이 아니다. (…) 초기 사용자들은 그 스펙에 놀라울 만큼 관심이 없었다.

이 구분에는 유명한 선배가 있습니다. 1957년 11월 14일, 미국 대통령 드와이트 아이젠하워는 한 연설에서 이렇게 말했습니다.

크게 보기

계획은 쓸모없다. 그러나 계획하는 일은 전부다. (…) 비상사태란 정의상 예상하지 못한 일이다. 그러니 계획한 대로 일어나지 않는다. 그래서 가장 먼저 할 일은 선반 위의 계획들을 몽땅 창밖으로 던지고 다시 시작하는 것이다. 그러나 계획을 해 본 적이 없다면, 적어도 지적으로는 일을 시작할 수 없다.

노르망디 상륙 작전을 지휘한 사람의 말이라 무게가 다릅니다. 1944년 6월, 아이젠하워는 수년에 걸친 작전 계획을 갖고 있었지만 마지막 순간 날씨 때문에 날짜를 하루 미뤄야 했습니다. 그때 빠르게 판단할 수 있었던 건 두꺼운 계획서 덕분이 아니라, 계획하는 과정에서 머릿속에 쌓인 이해 덕분이었습니다.

나딤의 깨달음도 같습니다. 가치가 있었던 건 '생각할 공간'이었지, 그 생각을 거대한 구조화된 문서로 보존하는 것이 아니었습니다. 사람들은 생각은 하고 싶어 했지만, 그 결과물을 다시 읽고 싶어 하지는 않았습니다. 나우르가 옳다면 당연한 일입니다. 이해는 문서가 아니라 생각한 사람 머릿속에 남으니까요.

오판 2. 모델이 너무 좋아졌다

모델이 컨텍스트와 메모리로 큰 코드베이스를 이해하는 능력이 좋아지면서, 저장소를 탐색하고 합리적인 가정을 세우는 데 뛰어나졌다. 잘 생각된 결과를 얻으려고 모델에게 일일이 지시할 필요가 줄었다.

그리고 이 글에서 가장 날카로운 문장이 이어집니다.

처음엔 모델의 능력이 '사람의 생각을 돕는 더 좋은 인터페이스'와 경쟁 관계라고 생각하지 않았다. 그런데 여러 면에서 그랬다. 모델이 혼자 믿고 내릴 수 있는 결정이 하나 늘 때마다, 사람에게 보여 줘야 할 결정은 하나 준다.

숫자로 보면 속도가 실감 납니다. AI 평가 기관 METR은 "사람 전문가가 몇 시간 걸리는 작업을 AI가 절반 확률로 해내는가"를 재는 '시간 지평'을 추적합니다.

METR 측정치. 16시간이 넘는 값은 METR 스스로 "신뢰하기 어렵다"고 밝히며, 오차 범위가 매우 넓습니다(Opus 4.6은 5.3~60.6시간). 2023년 이후 이 값은 약 4개월(129일)마다 두 배가 됐습니다.

1시간짜리 일을 맡기려면 계획서가 필요 없지만, 5분짜리 일만 믿고 맡길 수 있다면 큰 작업을 5분 단위로 쪼개 주는 사람의 계획이 필수입니다. 플랜 모드가 태어난 2025년 6월과 이 글이 나온 2026년 9월 사이에 이 막대는 몇 배로 자랐습니다.

현장의 증언도 같습니다. 체르니는 해커뉴스에서 이렇게 썼습니다. "Fable 초기 버전을 쓰다가 제가 더는 플랜 모드를 쓰지 않는다는 걸 깨달았습니다. 모델이 그냥 알아들었거든요. Opus 5.5에 와서는 Opus도 그 지점에 이르렀다고 느낍니다." 에세이가 나오기 하루 전인 9월 23일에는 Claude Code 팀의 Thariq가 X에 "플랜 모드를 없애고 Shift+Tab을 생각의 깊이(effort) 조절에 쓰는 걸 검토 중이다. 모델에게 이제 플랜 모드가 필요하지 않다고 생각한다"고 올렸습니다.

그러면 모든 작업에서 계획이 필요 없어진 걸까요? 아닙니다. 계획이 필요한 정도는 작업마다 다릅니다. 아래 다이얼로 직접 가늠해 보세요.

오판 3. AI가 쓴 글은 읽기 괴롭다

세 번째 이유는 뼈아픈 만큼 웃깁니다.

스펙은 정보는 더 많이 담았지만 명료함은 더 만들어 내지 못했다. 스펙은 길었다. 중요한 결정을 담았고, 쓸모 있어 보이는 맥락도 많았다. 문제는 그것이 AI가 쓴 글이었다는 점이다. AI가 쓴 글 특유의 호흡과 지나치게 구조화된 성격은 읽기를 몹시 어렵게 만든다. 내 눈은 자꾸 풀렸다.

크게 보기

AI가 쓴 긴 문서를 받아 본 적이 있다면 이 느낌을 아실 겁니다. 제목, 소제목, 체크 표시, "견고하고 확장 가능한", "사용자 경험을 최우선으로"…. 틀린 말은 하나도 없는데, 아무것도 결정하지 않는 문장이 대부분입니다. 직접 확인해 보세요.

2025년 10월 마틴 파울러의 사이트에 실린 비르기타 뵈켈러(Birgitta Böckeler) 의 스펙 주도 도구 비평도 같은 증상을 짚었습니다. Spec Kit은 "리뷰해야 할 마크다운 파일을 정말 많이 만들었고, 그것들은 반복적이었다." Kiro에서는 작은 버그 하나가 사용자 스토리 4개, 인수 조건 16개로 불어났습니다. 뵈켈러의 결론은 이랬습니다. "이 마크다운 파일들을 다 리뷰하느니 차라리 코드를 리뷰하겠다."

Nuanced 팀의 대응은 한 번 더 헛발을 디뎠습니다. 스펙을 없애는 대신 스펙 투어(Spec Tour) 를 만든 겁니다. 문서 전체를 흡수하라고 요구하는 대신 중요한 부분을 안내해 주는 기능이었죠.

크게 보기

그러나 그것은 복잡성의 층을 하나 더 덧붙였을 뿐이다. 내 화면에 주의를 요구하는 텍스트가 더 늘었다. 스펙을 쓸 만하게 만들려고 더 짧은 버전을 생성해야 한다면, 애초에 전체 문서는 왜 있었던 걸까?

이 질문은 모든 AI 문서 도구에 던질 만합니다. 요약의 요약이 필요한 문서라면, 문서가 틀린 겁니다. 블레즈 파스칼의 오래된 사과가 떠오릅니다. "시간이 없어서 편지를 길게 썼습니다." 짧게 쓰는 데는 판단이 필요합니다. 무엇이 중요하고 무엇을 버릴지 아는 것, 그것이 바로 나우르가 말한 '이론'입니다.

오판 4. 계획과 구현을 떼어 놓았다

마지막 이유가 이 글의 심장입니다. Nuanced의 작업 흐름은 이랬습니다.

채팅 → 질문에 답하며 모호함 해소 → 스펙 생성 → 스펙 리뷰 → 스펙 수정 → 승인 → 구현 → 코드 리뷰

크게 보기 원문 삽화: Nuanced의 작업 흐름은 폭포였다. (출처: Ayman Nadeem)

실제 생각은 이런 식으로 일어나지 않는다. (…) 보통은 문제의 일부를 이해하고, 무언가를 시도하고, 처음 생성된 결과에서 새로운 걸 배우고, 그래서 마음을 바꿔 다른 걸 시도한다. 한 걸음 한 걸음이 새로운 질문을 드러낸다. (…) 우리 인터페이스는 사용자가 구현을 시작하려면 생각을 서둘러 '끝내도록' 강요했다. (…) 폭포를 거슬러 올라갈 방법은 없었다.

로이스가 1970년에 "위험하고 실패를 부른다"고 경고한 바로 그 그림을, 2026년의 AI 앱이 여덟 단계로 다시 그린 셈입니다. 리텔과 웨버의 말대로 "먼저 이해하고 그다음에 해결할 수는 없는데", 인터페이스가 그걸 요구했습니다.

같은 쿠폰 기능을 두 방식으로 만들어 보면 차이가 선명해집니다.

나딤은 새로운 흐름을 이렇게 정리합니다.

크게 보기 원문 삽화: 옛 흐름은 선형, 새 흐름은 반복. (출처: Ayman Nadeem)

그 루프 안에서도 여전히 엄청난 양의 계획이 일어난다. 다만 그것이 '계획서'라는 이름의 문서로 나타날 필요가 없을 뿐이다. 내가 저지른 가장 큰 실수는 계획을 산출물로 만든 것이다. 사람의 이해를 돕는 과정을 설계했어야 했다.

덤: 플랜 모드와 빌드 모드라는 이상한 구분

Nuanced에는 플랜 모드와 빌드 모드가 따로 있었습니다. 플랜 모드는 늘 스펙을 만들고, 빌드 모드는 스펙 없이 작은 작업을 처리합니다. 합리적으로 들리지만, 사용자는 매번 메타 질문을 해야 했습니다. "이 작업은 계획할 가치가 있나?" 그리고 그렇다면 버튼이나 단축키로 모드를 켜는 걸 기억해야 했습니다.

크게 보기

이것은 AI가 이미 가진 맥락을 바탕으로 대신 해 줘야 할 구분처럼 느껴졌다. 어떤 모드에 있어야 하는지 기억하는 것이 오히려 인지 부담을 늘렸다.

일을 하려고 앉았는데 "이 일을 어떤 방식으로 할지"부터 결정해야 하는 것. 식당에서 메뉴를 고르기 전에 "오늘은 신중하게 고르는 날인가, 대충 고르는 날인가"를 먼저 정하라는 것과 비슷합니다. 앞의 다이얼에서 본 네 가지 질문(되돌릴 수 있나, 모호한가, 영향이 큰가, 모델이 채울 수 있나)은 사실 에이전트가 저장소와 대화 맥락만 봐도 대부분 답할 수 있습니다.

그리고 나딤은 스스로를 미드위트 밈에 비유합니다.

크게 보기 원문 삽화: 미드위트 밈. 양 끝은 "채팅이면 돼", 가운데는 "새 인터페이스가 필요해". (출처: Ayman Nadeem)

인터넷에서 유명한 이 밈은 초보자와 달인은 같은 단순한 답을 말하고, 어중간하게 아는 사람만 복잡한 답에 매달린다는 농담입니다. 나딤은 계획이 기본값이 아니라 필요할 때만 일어나는 단순한 채팅이 사실은 꽤 훌륭했다고 인정합니다. 자기가 밈의 가운데에 서 있었다는 고백입니다.

---

5부. 그래도 '이해'는 풀리지 않았다

오해하지 말아야 할 것: 이해의 문제는 오히려 커졌다

여기까지 읽고 "그럼 이제 계획 없이 AI에게 다 맡기면 되는구나"라고 생각했다면, 나딤이 가장 경계하는 오독입니다. 글의 마지막 절 제목은 "우리는 아직 이해의 문제를 풀지 못했다" 입니다.

무엇을 만들지, 왜 중요한지 생각하고 결정을 평가하는 일은 여전히 중요하다. 사람들은 무슨 일이 일어나고 있는지에 대해 일관된 머릿속 그림을 쌓아야 한다. 다만 거대한 AI 생성 텍스트가 그 인터페이스는 아니라고 생각한다. 채팅으로 결정을 풀어 가는 게 더 직관적으로 느껴지지만, 시스템이 바뀔 때 그 이해를 최신으로 유지하는 것은 여전히 열린 문제다.

실제로 2025~26년에 나온 데이터들은 이 문제가 가볍지 않다는 걸 보여 줍니다.

구글 크롬 팀 출신 애디 오스마니(Addy Osmani)는 이런 상황에 이해 부채(comprehension debt) 라는 이름을 붙였습니다. "시스템에 존재하는 코드의 양과, 그중 누군가가 진짜로 이해하고 있는 양 사이의 벌어지는 틈"입니다. 기술 부채가 '나중에 고쳐야 할 코드'라면, 이해 부채는 '나중에 누군가 이해해야 할 코드'입니다. 나우르식으로 말하면, 이론 없는 프로그램이 늘어나는 겁니다.

해커뉴스에서 가장 많은 답글(90여 개)이 달린 반론도 이 지점을 찔렀습니다. 한 사용자(taurath)는 이렇게 썼습니다. "개발자들에게서 이해가 빠져나가는 걸 실시간으로 보고 있다. 불쌍한 개발자들은 지표는 멋지게 나오는데 아무것도 배우지 못하고, 엄청난 부채를 쌓고 있다." 플랜 모드를 없애자는 글에 대한 반론이라기보다, 나딤이 남긴 '풀리지 않은 문제'에 대한 절박한 동의에 가깝습니다.

5개에서 수백 개로

문제는 에이전트 수가 늘수록 기하급수적으로 어려워집니다.

크게 보기

2026년 2월 앤트로픽의 니컬러스 칼리니는 Claude 16개를 병렬로 돌려 약 2,000개 세션, 2만 달러로 10만 줄짜리 C 컴파일러를 만든 실험을 공개했습니다. 그는 성과만큼이나 경고를 강조했습니다. "테스트가 통과하는 걸 보고 일이 끝났다고 여기기 쉽지만, 실제로 그런 경우는 드물다." "프로그래머가 직접 검증해 본 적 없는 소프트웨어를 배포한다는 생각은 진짜 걱정거리다." 그리고 9월에는 Claude Code가 조정자 하나가 일을 쪼개 여러 클라우드 스레드에 나눠 주는 기능을 베타로 열었습니다. 에이전트 수십 개가 하나의 코드베이스를 동시에 바꾸는 것이 특별한 일이 아니게 됐습니다.

그 문제는 에이전트가 5개에서 수백 개로 늘면 더 어려워진다. 따라잡는다는 것이 모든 대화를 읽고 코드 변경마다 설명을 요청하는 일일 수는 없다. 에이전트는 사람의 주의가 가장 큰 효과를 낼 수 있는 가장 적은 곳을 찾아내고, 그 주의가 쓸모 있도록 충분한 맥락을 올려 줘야 한다.

이 문장을 직접 계산해 보면 왜 이게 유일한 길인지 보입니다.

되돌릴 수 있는 문, 되돌릴 수 없는 문

그렇다면 '사람의 주의가 가장 큰 효과를 내는 곳'은 어디일까요? 가장 오래되고 실용적인 기준 하나를 소개합니다. 제프 베이조스가 2015년 아마존 주주 서한에 쓴 한 방향 문과 두 방향 문입니다.

크게 보기

어떤 결정은 중대하고 되돌릴 수 없거나 거의 되돌릴 수 없다. 한 방향 문이다. 이런 결정은 체계적으로, 신중하게, 천천히, 깊이 숙고하고 상의해서 내려야 한다. (…) 하지만 대부분의 결정은 그렇지 않다. 바꿀 수 있고 되돌릴 수 있다. 두 방향 문이다.

베이조스는 이어서 경고합니다. 조직이 커지면 두 방향 문에도 한 방향 문의 무거운 절차를 쓰는 경향이 생기고, 그 결과는 "느림, 생각 없는 위험 회피, 부족한 실험, 그리고 줄어든 발명"이라고요. 모든 작업에 스펙 문서를 요구하는 플랜 모드가 바로 이 실수였습니다.

AI 코딩에 옮기면 이렇게 정리할 수 있습니다.

마이클 나이가드가 2011년에 제안한 설계 결정 기록(ADR, Architecture Decision Record) 이 좋은 본보기입니다. ADR은 시스템 전체를 설명하는 긴 문서가 아니라, 결정 하나마다 한 쪽짜리 기록입니다. 맥락, 결정, 결과. 47쪽 스펙과 달리 읽는 데 1분이면 되고, 나중에 "왜 이렇게 했지?"라는 질문에 정확히 답합니다. 계획서가 아니라 결정의 흔적을 남기는 방식입니다.

2026년, 현장은 이미 움직이고 있다

그렇다면 플랜 모드 이후의 도구는 어떤 모습일까요? 나딤은 답을 모른다고 솔직하게 말하지만, 해커뉴스 토론과 현장의 움직임에서 몇 가지 방향이 보입니다.

반론도 들어 보자

공정을 위해, 플랜 모드를 여전히 아끼는 목소리도 소개합니다. 해커뉴스에는 이런 반론들이 있었습니다.

• "플랜 모드 덕에 협업자가 된다." 매일 플랜 모드를 쓴다는 한 사용자는 계획 단계가 있어서 자신이 수동적인 승인자가 아니라 적극적인 협업자가 된다고 했습니다.
• "추측이 틀리면 소용없다." 에이전트가 알아서 가정을 세운다 해도, 내 의도를 잘못 짐작하면 요구가 덜 명세된 문제는 그대로라는 지적입니다.
• "좋은 계획은 밤샘 작업을 가능하게 한다." 계획이 탄탄하면 "좋아, 진행해" 한 마디로 밤새 에이전트를 돌릴 수 있다는 경험담도 있었습니다.
• "코드부터, 질문은 나중에." 반대편 극단에서 '그냥 바이브 코딩'을 옹호하는 목소리도 있었습니다.

흥미로운 건 이 반론들이 나딤의 결론과 크게 부딪치지 않는다는 점입니다. 적극적인 협업자가 되는 것, 의도를 정확히 전하는 것, 큰 작업 전에 방향을 맞추는 것, 모두 계획하기의 가치입니다. 나딤이 버린 건 계획하기가 아니라 계획서라는 산출물과 모드 전환이었습니다. 아이젠하워의 문장으로 돌아가면, 논쟁의 양쪽 모두 "계획하는 일은 전부"라는 데는 동의하고 있는 셈입니다.

---

6부. 그래서 우리는 무엇을 해야 할까

이 글을 읽는 개발자와 팀을 위해, 원문과 이 특집의 연구들을 실천 목록으로 옮겨 보겠습니다.

---

맺으며: 인터페이스는 바뀌어도

크게 보기 원문 삽화: 플랜 모드의 장례식. 2025–2026. (출처: Ayman Nadeem)

원문 마지막 삽화는 장례식입니다. 묘비에는 '플랜 모드 2025–2026'. 채 두 해를 살지 못한 기능입니다. 그런데 그 옆에서 우는 로봇이 함께 그려져 있다는 게 의미심장합니다. 플랜 모드는 사람만을 위한 게 아니라, 아직 서툴렀던 AI를 위한 보조 바퀴이기도 했으니까요. 바퀴를 떼는 건 자전거 타는 법을 배웠다는 뜻이지, 길을 아는 법까지 배웠다는 뜻은 아닙니다.

나딤은 글을 이렇게 맺습니다.

우리는 아직 점점 더 유능해지는 수백 개의 에이전트가 동시에 시스템을 바꾸는 동안 사람이 방향을 잃지 않게 돕는 법을 풀지 못했다. 하지만 더 깊은 문제, 즉 사람이 시스템을 어떻게 이해하고, 복잡한 정보의 위계를 어떻게 탐색하며, 강력한 도구를 어떻게 쓰는가는 변치 않는 문제라고 생각한다. 인터페이스는 그것을 움직이는 기술과 함께 계속 바뀐다. 복잡함을 이해할 수 있게 만들어야 한다는 필요는 바뀌지 않는다.

1970년 로이스는 "두 번 만들라"고 했고, 1985년 나우르는 "이론은 사람 머릿속에 있다"고 했습니다. 2026년의 우리는 에이전트 덕분에 두 번이 아니라 열 번도 만들 수 있게 됐습니다. 남은 질문은 하나입니다. 그 열 번의 시도에서 배운 것이 누구의 머릿속에 남는가.

플랜 모드는 죽었습니다. 하지만 계획하는 일, 그리고 이해하는 일은 이제 막 새로운 모양을 찾기 시작했습니다.

---

참고 자료

• Ayman Nadeem, 「Plan mode is dead」, 2026년 9월 24일 — aymannadeem.com (본문 원문 삽화 7장은 이 글에서 인용)
• 해커뉴스 토론 「Plan mode is dead」 — news.ycombinator.com/item?id=49840054 (553점·댓글 477개, 2026년 9월 27일 기준)
• Winston W. Royce, "Managing the Development of Large Software Systems", Proc. IEEE WESCON, 1970
• Frederick P. Brooks Jr., 『The Mythical Man-Month』, 1975
• Barry Boehm, 『Software Engineering Economics』, 1981
• Horst Rittel & Melvin Webber, "Dilemmas in a General Theory of Planning", Policy Sciences 4(2), 1973
• Donald Schön, 『The Reflective Practitioner』, 1983
• Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming 15(5), 1985
• Kent Beck, "Embracing Change with Extreme Programming", IEEE Computer, 1999
• 애자일 소프트웨어 개발 선언, 2001 — agilemanifesto.org
• Dwight D. Eisenhower, National Defense Executive Reserve Conference 연설, 1957년 11월 14일 — American Presidency Project
• Jeff Bezos, 2015 Letter to Shareholders — Amazon
• Shunyu Yao 외, "ReAct: Synergizing Reasoning and Acting in Language Models", arXiv:2210.03629, 2022
• Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl", martinfowler.com, 2025년 10월 15일
• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025년 7월 10일 및 2026년 2월 24일 후속 보고
• METR, 시간 지평(Time Horizons) 측정 데이터, 2026년 5월 갱신
• Judy Hanwen Shen & Alex Tamkin, "How AI Impacts Skill Formation", arXiv:2601.20245, 2026
• Faros AI, "The AI Productivity Paradox Report 2025", 2025년 7월 23일
• Addy Osmani, "Comprehension Debt – the hidden cost of AI generated code"
• Nicholas Carlini, 병렬 Claude로 C 컴파일러 만들기, 앤트로픽, 2026년 2월 5일