AI에게 계획부터 세우라고 했더니 구현보다 계획서를 읽는 시간이 더 길어졌다면, 필요한 질문은 “계획을 켤까, 끌까?”에서 시작하지 않습니다. 이 작업에서 무엇을 잘못 이해하면 다시 만드는 비용이 커지는지부터 살펴봐야 합니다. 계획을 짧게 만들더라도 목표, 지켜야 할 조건, 확인 방법은 남기는 편이 좋습니다.
왜 다시 Plan 모드 논쟁인가
Ayman Nadeem은 2026년 9월 24일 「Plan mode is dead」에서 자신이 만든 코딩 도구의 경험을 바탕으로 긴 계획 산출물과 계획·구현의 분리에 의문을 제기했습니다. 이는 제품 개발자의 견해이며, 모든 프로젝트에서 계획이 불필요하다는 통제 실험의 결론은 아닙니다. 특정 제품의 Plan 기능이 종료됐다는 소식도 아닙니다.
이 논쟁을 실제 작업에 적용할 때는 계획서의 분량과 사전 판단의 필요성을 나눠 보는 것이 유용합니다. 아래 기준과 양식은 원문을 번역한 내용이 아니라, 작은 개발 작업에 적용하도록 이 글에서 구성한 예시입니다.
계획을 줄여도 남겨야 할 세 가지
1. 목표: 사용자가 무엇을 할 수 있어야 하는가. “검색 기능 개선”보다 “검색어를 입력한 뒤 카테고리를 바꿔도 검색어가 유지된다”가 결과를 확인하기 쉽습니다. 구현 방법보다 사용자 동작을 먼저 적습니다.
2. 조건: 무엇이 유지돼야 하는가. 기존 URL로 들어오는 동작, 데이터 형식, 다른 화면의 기능처럼 변경 후에도 성립해야 할 조건을 적습니다. “기존 기능 유지”만 쓰면 어떤 동작을 확인해야 할지 알기 어렵습니다.
3. 확인: 어떤 입력에서 어떤 결과가 나오면 끝인가. “테스트 통과” 대신 “검색어가 있는 상태에서 카테고리 선택→해제→뒤로 가기 후 화면과 URL이 일치한다”처럼 관찰 가능한 기준을 적습니다.
작업의 크기보다 되돌리는 비용을 보세요
| 작업 | 먼저 합의할 내용 | 실행 전 확인 깊이 |
| 버튼 문구 수정 | 바꿀 위치·문구·줄바꿈 | 화면에서 바로 비교 |
| 목록 필터 추가 | 검색어 유지·URL·뒤로 가기 | 사용자 동작별 기대 결과 |
| 저장 데이터 형식 변경 | 기존 데이터 해석·호환·실패 처리 | 시험 데이터로 전환·복구 확인 |
| 요구가 불분명한 새 기능 | 대상 사용자·필수 결과·제외 범위 | 작은 시제품으로 요구부터 확인 |
표의 기준은 글자 수나 파일 수가 아닙니다. 코드가 몇 줄이어도 저장된 데이터를 바꾸면 영향이 클 수 있습니다. 반대로 여러 파일의 동일한 문구 변경은 범위가 명확하고 확인이 쉬울 수 있습니다.
예시 1: 목록 필터에는 짧은 계획부터
가상의 블로그 관리 화면에 카테고리 필터를 추가한다고 가정해 보겠습니다. 다음 정도면 첫 구현의 기준을 잡을 수 있습니다.
목표: 검색 결과를 카테고리별로 좁힌다.
범위: 글 목록 화면과 해당 URL의 필터 상태만 바꾼다.
유지 조건: 검색어는 유지하고, 필터 변경 시 페이지는 1로 돌아간다.
확인: 선택·해제·새로고침·뒤로 가기에서 URL과 목록이 일치한다.
미정 사항: URL 상태를 처리하는 기존 코드 위치를 확인한 뒤 구현한다.여기서 “기존 코드 위치를 확인한다”는 실제로 확인했다는 뜻이 아닙니다. 아직 모르는 내용을 미정으로 표시해 AI가 존재하지 않는 구조를 전제로 구현하는 일을 줄이려는 장치입니다. 조사 결과 서버와 화면의 필터 규칙이 다르면, 먼저 그 차이를 설명하고 계획을 고칩니다.
예시 2: 데이터 변경은 같은 다섯 줄로 끝내지 마세요
저장된 글의 카테고리를 문자열에서 숫자 ID로 바꾸는 상황은 다릅니다. 기존 글을 어떻게 읽을지, 모르는 문자열은 어디로 분류할지, 구버전 프로그램과 함께 동작할지까지 정해야 합니다.
이때는 “변환 스크립트 작성”을 완료 기준으로 삼기 어렵습니다. 대표 데이터와 예외 데이터를 따로 준비하고, 변환 전후 글 수·카테고리 대응 관계를 확인해야 합니다. 실패 시 어떤 데이터로 돌아갈지도 정해야 합니다. 실제 서비스에서는 운영 구조에 맞는 별도 검토가 필요하며, 이 예시는 실행용 마이그레이션 절차가 아닙니다.
복사해서 쓰는 최소 계획 요청문
아래 작업을 바로 구현하기 전에 짧은 계획을 작성해줘.
작업: [사용자가 얻게 될 결과]
유지할 조건: [기존 동작 또는 데이터 조건]
제외할 범위: [이번에 하지 않을 일]
완료 확인: [입력 → 기대 결과]
아직 확인하지 못한 가정은 사실처럼 쓰지 말고 따로 표시해줘.
되돌리기 어려운 변경이 있으면 그 부분의 전환·복구 방법을 먼저 설명해줘.계획을 읽을 때는 한 문장이라도 구체적인 오해를 발견할 수 있는지 확인해 보세요. “구현하고 검증한다”만 반복된다면 실제 결정을 거의 담고 있지 않을 수 있습니다. 반대로 목표와 실패 조건이 명확하면 짧은 계획도 충분히 유용합니다.
자주 묻는 질문
Plan 모드를 항상 꺼야 하나요? 그렇지 않습니다. 이 글은 특정 제품의 설정 추천이 아니라 작업에 맞게 계획의 깊이를 정하는 기준입니다.
계획은 몇 줄이 적당한가요? 고정된 정답은 없습니다. 위 다섯 줄은 단순한 화면 작업의 출발점이며, 데이터·권한·외부 시스템에 영향을 주면 더 자세한 검토가 필요합니다.
작업 도중 계획이 바뀌면 실패인가요? 새로 확인한 사실 때문에 바뀌는 것은 자연스럽습니다. 변경 이유와 완료 기준이 어떻게 달라졌는지를 함께 남기면 됩니다.
참고 자료와 확인 범위
자료 확인일: 2026년 9월 29일. 원저자의 견해와 이 글에서 작성한 가상 예시·요청문을 구분했습니다.