기획 없이 코딩하는 AI를 멈추는 법 — Planning Gate 만들기

지난 글에서 Why 체인을 만들었다.
AI가 바로 실행하지 않고 "왜?"를 물어서 내 진짜 의도를 파악하게 만드는 장치.

Why를 묻는 과정은, 내 머릿속에 있는 생각을 AI한테 이해시키는 데 확실히 도움이 됐다.
그러나 내 머릿속 그림을 그대로 구현하기 위해서는, 그것만으로는 충분하지 않았다.

Why만으로는 부족했던 내 마음 읽히기

Why 체인은 의도를 파악하는 데는 탁월하다.
"왜 이게 필요한가?"를 파고들면, 표면 요청 뒤에 숨은 진짜 목적이 드러나니까.

그러나 의도를 알았다고 해서 바로 코딩에 들어가도 되는 건 아니었다.

"교사용 피드백 작성 도구 만들어줘."
Why 체인을 돌리면 "교사가 채점 후 학생별 맞춤 피드백을 빠르게 전달하고 싶다"는 핵심 동기까지 도달한다.
좋다. 근데 그 다음이 문제다.

이 도구, 기존에 만들던 AI 채점 시스템 위에 얹는 건가 별개인가?
피드백을 교사가 직접 쓰는 건가, AI가 초안을 만들어주는 건가? 학부모한테도 전달되어야 하나? 화면은 몇 개짜리인가?

이런 질문들에 답이 없는 채로 코딩에 들어가면, AI는 자기 나름의 가정을 깔고 열심히 달린다.
결과물을 보면 "아... 이게 아닌데." 그리고 처음부터 다시.

딸깍의 환상에서 썼던 경험이 또 떠올랐다.
GPT한테 기획을 맡겼다가 100개 파일 체인지, 40개 커밋의 괴물 PR이 탄생했던 그 사건.
그때도 결국 문제는 같았다.
기획에 구멍이 있으면 AI는 그 구멍을 추론으로 메우는데, 그 추론이 매번 다르다.
비결정적이니까.
오늘은 A 방향으로 메우고, 내일은 B 방향으로 메우고.
부분마다 전제가 다른 기괴한 결과물이 탄생하는 거다.

Why는 "왜"에 답하지만, "뭘", "어디까지", "어떻게"에는 답하지 않는다.

기획의 부재

돌이켜보면 당연한 건데, 나는 기획 단계를 통째로 건너뛰고 있었다.

Why로 의도를 파악하고 → 바로 코딩.
그 사이에 기획이 없었다.
"뭘 만들 건지"를 체계적으로 정리하는 과정 없이 의도만 가지고 바로 작업을 하기 때문에 문제가 발생한다.

사람한테 일을 시킬 때도 "이거 왜 하는지"만 설명하고 "뭘 어디까지 어떻게"를 안 알려주면 결과물이 제각각이잖나.
AI도 똑같다.
아니, 매일 기억이 리셋되고, 일 하다 말고 갑자기 퇴사해버리기도 하는(컨텍스트가 날아가는) AI한테는 더 치명적이다.

그래서 이를 방지하기 위한 스킬을 만들어보았다.
Planning Gate. AI가 코딩에 들어가기 전에 "기획이 충분한가?"를 구조적으로 점검하는 게이트.

기획을 구조적으로 점검하기

기획을 어떻게 구조화할지 고민하다 《기획의 정석》을 떠올렸다.
며칠 전, 이 책을 읽고 독후감을 쓴 적이 있다.
그때 가장 인상 깊었던 건 "기획이란 상대방의 뇌리에 강렬한 기억을 남기는 싸움"이라는 문장이었다.
기획의 전제조건이 '나'가 아니라 '나 아닌 상대방'이라는 것.
그래서 제목을 "기획은 연애다"로 붙였었다.

그때는 사람 대 사람의 이야기로 읽었는데, 시간이 지나고 보니 AI와의 협업에도 똑같이 적용할 수 있겠다는 생각이 들었다.
AI라는 상대방의 뇌리(컨텍스트)에 내 의도를 명확하게 심어야 한다.
상대방이 뭘 모르는지 파악하고, 그 빈틈을 채워줘야 한다.
이것이 바로 기획이다.

이 책은 기획을 10가지 습관으로 정리하는데, 이걸 AI 스킬에 맞게 세 단계로 재구성했다.

Phase 1 — 이해도 체크 (게이트) AI가 요청을 얼마나 이해했는지 스스로 점검하는 단계.
4개 차원에서 이해도를 %로 매기고, 전부 80% 이상이어야 다음으로 넘어간다.
Phase 2 — 기획 아웃풋 게이트를 통과하면 비로소 구조를 시각화하고, 실행 계획을 세우고, 기대효과를 정리한다.
Phase 3 — 문서화 모든 결과를 docs/planning/ 폴더에 마크다운 파일로 저장한다.
이게 이후 개발의 기준 문서가 된다.

핵심은 Phase 1이다.
AI가 "내가 정말 이해했나?"를 수치로 판단하게 만드는 것.

Phase 1: 네 가지 질문

게이트에서 점검하는 4개 차원은 이렇다.

Focus — 근본적으로 중요한 게 뭘까. 여러 가지를 한다고 하는데, 진짜 핵심은 뭔가. 이것도 하고 저것도 하고 싶다는 요청에서 가장 중요한 한 가지를 골라내는 단계.
Why — 왜 필요한가. 지금 뭐가 불편한가. 누가 쓰는가. 이전 글의 Why 체인이 여기에 들어간다.
Definition — 문제가 날카로운가. "이 도구가 하는 것"과 "하지 않는 것"의 경계가 명확한가. 기존 시스템과의 관계는?
Dividing — 쪼갤 수 있는가. 기능을 겹침 없이 나눌 수 있는가. 우선순위는?

재미있는 건 각 차원마다 AI가 적용하는 도구가 다르고, 그것도 상황에 따라 바뀐다는 거다.

예를 들어 Why 차원. 기본은 5 Whys다.
"왜 필요한가?"를 반복해서 근본 원인을 찾는 토요타식 질문법.

근데 사용자가 "피드백 도구 만들어줘"처럼 문제 대신 해결책을 먼저 말하면? 5 Whys로는 파기가 어렵다.

이때 JTBD(Jobs to Be Done)로 전환한다.
"이 교사가 이 도구를 '고용'해서 해결하려는 일이 뭔가?"로 질문이 바뀌는 것이다.
같은 Why 차원인데 접근 도구가 달라지면 파고드는 방향도 달라진다.

표에도 어떤 도구를 적용했는지 명시해서, 나도 "아, 이 관점으로 보고 있구나"를 알 수 있게 했다.

이해도 표

AI가 요청을 분석하면 이런 표를 뱉는다:

차원	적용 도구	이해한 내용	판단 근거	이해도
Focus	Eisenhower	피드백 작성 효율화	채점인지 피드백 문구인지 불분명	65%
Why	JTBD	빠르게 양질의 피드백 전달 (추정)	구체적 job이 추정 수준	50%
Definition	Problem Statement	피드백 작성에 어려움	범위 불명확, 기존 시스템 관계 불명	40%
Dividing	-	분해 불가	범위가 안 정해져서 쪼갤 수 없음	20%

전체 이해도 44%. 게이트 미통과.
AI가 80% 미만인 차원에 대해 재질문을 한다.

이때 질문 순서는 책에 나온 4MAT이라는 학습 이론을 빌렸다.
Why(왜?) → What(뭘?) → How(어떻게?) → What if(만약?) 순서로 물어야 사람이 자연스럽게 생각을 풀어낸다는 것.
한 번에 3개 이상 질문을 쏟아내지 않고, 가장 이해도가 낮은 차원부터 질문한다.

이 사이클을 반복해서 4개 차원 전부 80% 이상이 되면, 비로소 Phase 2로 넘어간다.

기획이 바뀌면?

처음 만들 때만 기획이 필요한 게 아니다.
"여기에 학부모 전달 기능도 넣고 싶어"
이런 변경 요청이 올 때도 기획 문서가 있어야 한다.

그래서 기획 변경 모드도 만들었다.
AI가 docs/planning/ 폴더를 확인해서, 해당 도구의 기획 문서가 이미 있으면 자동으로 변경 모드로 들어간다.

기존 기획 문서를 불러와서, 변경 요청이 4개 차원 각각에 어떤 영향을 주는지 체크한다.
Focus가 바뀌나? Scope이 넓어지나? 기능 트리에 새 가지가 필요한가?
영향받는 차원만 재평가하고, 다시 80% 게이트를 통과하면 문서를 버전 업데이트한다.
Concept 자체가 완전히 바뀌는 대규모 변경이면, 기존 문서를 아카이브하고 처음부터 새로 쓴다.

변경 이력이 쌓이면, "이 도구가 왜 이 모양이 됐는지"의 맥락이 남는다.
이전 글에서 "설계도가 많은 사람이 이긴다"고 썼는데, 이 기획 문서가 바로 그 설계도다.
AI가 퇴사하든 신입 AI가 투입되든, 문서만 있으면 재건축이 가능하다.

실제 프롬프트 예시

Planning Gate는 Claude Code의 Skill로 만들었다. (2편에서 다룬 것과 같은 방식) 스킬 안에 들어가는 프롬프트의 일부를 보여주면:

도구 선택 규칙:

기본 도구를 먼저 적용한다.  
요청의 성격이 기본 도구와 맞지 않으면 대안 도구를 선택한다.  
어떤 도구를 적용했는지 표에 명시한다.  
같은 차원이라도 재질문 사이클에서 도구를 바꿀 수 있다.

Why 차원의 전환 신호:

기본 도구: 5 Whys (토요타)  
"왜 이게 필요한가?"를 반복해서 근본 원인을 찾는다.  

- 전환 신호: 사용자가 문제보다 해결책을 먼저 말할 때  
대안 도구: JTBD (Jobs to Be Done)  
"이 사용자가 이 도구를 고용해서 해결하려는 일(job)이 뭔가?"로 전환한다.

게이트 통과 조건:

4개 차원 모두 80% 이상이어야 Phase 2로 넘어간다.  
하나라도 80% 미만이면, 해당 차원에 대해 재질문한다.  
사용자가 "이 정도면 됐어"라고 말하면, 현재 이해도를 경고와 함께 표시하고 넘어갈 수 있다.

기획 변경 모드 진입:

요청을 받으면 먼저 docs/planning/ 디렉토리를 확인한다.  
- 기획 문서가 없다 → 신규 기획 모드  
- 기획 문서가 있다 → 기획 변경 모드

이런 식으로, AI한테 "이런 상황에서는 이렇게 행동해라"를 꽤 구체적으로 적어놓는다.
전체 스킬 파일은 200줄이 넘는데, 결국 하는 일은 하나다.
코딩에 들어가기 전에 기획이 충분한지 확인해라.

Why 체인에서 Planning Gate로

정리하면 이런 흐름이다.

1편에서 Codex가 코드를 감시하게 만들었다 — 결과물의 품질을 지키는 장치.
2편에서 그걸 재사용 가능한 Skill로 바꿨다 — 프로젝트마다 반복하지 않게.
3편에서 Why 체인으로 의도를 파악하게 만들었다 — 방향을 잡는 장치.
4편, 이번 글에서 Planning Gate로 기획을 강제했다 — 방향뿐 아니라 범위와 구조까지 잡는 장치.

점점 AI에게 맡기는 범위가 넓어지고 있는데, 역설적으로 사람이 신경 써야 할 부분도 같이 명확해지고 있다.
AI가 못하는 건 코딩이 아니라, "뭘 만들어야 하는지 결정하는 것"이니까.

기획이란 상대방이 뭘 원하는지 알아내고, 내 의도를 상대방의 머릿속에 명확하게 심는 일.
AI와의 협업도 결국 마찬가지이다.
상대가 사람이든 AI든, 기획이 빠지면 서로 다른 그림을 그리게 된다.

결국 기획이다.
AI 시대에도, 아니 AI 시대이기 때문에 더.