/plan-* 3종 — 한 PLAN 문서를 세 시선으로 통과시키기 (gstack 시리즈 3/6)

시리즈 2편에서 /office-hours로 컨셉의 모서리를 깎았다. 이번 글은 그 정제된 컨셉을 PLAN으로 옮길 때 한 머리가 아닌 세 시선을 통과시키는 자리, /plan-ceo-review·/plan-eng-review·/plan-design-review 3종이 car-game의 PLAN v1을 v2로 만들어 낸 과정을 다룬다.

왜 이런 스킬이 필요했나

PLAN을 한 사람이 짜면 그 사람의 사각지대가 PLAN에 그대로 박힌다. car-game의 PLAN v1은 엔지니어 머리로 짠 plan이었다 — 모듈을 어떻게 나눌지, 어떤 자료구조를 쓸지에는 답이 있었지만, "이 plan대로 가면 1주일 안에 끝나나?", "사용자가 Lv1과 Lv10을 같은 게임으로 느끼나?" 같은 질문에는 답이 없었다.

문제는 한 사람이 자기 사각지대를 자기 머리로 메우려 해도 한계가 있다는 점이다. 시선 자체가 다른 사람을 데려와야 사각지대가 줄어든다. 그런데 매 PLAN마다 CEO와 디자이너를 모셔올 수는 없다. /plan-* 3종은 이 어려움을 푸는 게이트다.

무엇을 하는 스킬인가

/plan-* 3종은 한 PLAN 문서를 받아 세 가지 다른 역할로 동시에 검토한다. 각 역할은 PLAN의 다른 차원을 본다:

• /plan-ceo-review — 범위·우선순위·일정. "이 약속이 너무 큰가? MVP는 어디서 자르나? 60% 진척에서도 publish 가능한가?"
• /plan-eng-review — 아키텍처·확장성·기술 부채. "이 구조가 나중에 N번 더 추가될 때 회귀 위험이 어떻게 되나? 패턴은 정착되어 있나?"
• /plan-design-review — 사용자 경험·진척감·일관성. "사용자가 진척을 느끼나? 처음과 끝의 톤이 다른가? 한 화면에 너무 많은 정보가 있지 않나?"

세 리뷰는 같은 PLAN 문서에 대해 완전히 다른 종류의 결함을 잡아낸다. 한 시선으로는 보이지 않는 게 다른 시선에는 명백히 보인다.

그림 설명: 가운데 노란 박스는 한 머리로 짠 PLAN v1이다. 세 시선이 PLAN을 둘러싸고 각자 다른 차원에서 결함을 가리킨다. 좌상의 CEO는 무엇을 자를까(범위·우선순위)를 묻고, 우상의 ENG는 어떻게 구조화할까(아키텍처)를 묻고, 하단의 DESIGN은 사용자가 무엇을 느낄까(경험)를 묻는다. 한 사람이 세 차원을 동시에 보는 것은 어렵지만, 세 시선을 따로 통과시키면 빠지는 부분이 적어진다.

car-game에서 이 스킬이 한 일

세 리뷰가 PLAN v1에서 잡은 결함과, 그것이 PLAN v2 + CHECKLIST v2에 어떻게 반영됐는지:

CEO 시선이 잡은 것

"Lv1~10 전부를 1주일 안에? 너무 큰 약속. MVP는 Lv1~3로 자르고, Lv4~10은 stretch goal로. 60% 진척에서도 publish 가능한 단위로 잘라라."

PLAN v1은 마일스톤이 한 덩어리(Lv1~10)였다. CEO 리뷰 후 마일스톤은 MVP(Lv1~3) + Stretch(Lv4~10) 두 단위로 쪼개졌고, MVP가 60% 진척 시점에서 publish 가능한 형태로 다시 설계됐다. 이는 CHECKLIST v2의 P1·P2 마일스톤 분리로 직접 반영됐다.

ENG 시선이 잡은 것

"spawner.js에 모든 장애물 타입을 한 함수로 박지 마라. priority chain 패턴으로 분리하라. 나중에 장애물 종류가 추가될 때마다 회귀 위험이 누적된다."

PLAN v1은 spawner를 단일 함수로 두었다. ENG 리뷰 후 spawner는 priority chain 패턴(pedestrian → parked → fixed → driving → oncoming, 각 단계마다 rate curve)으로 분리됐다. 이 결정 덕분에 이후 장애물 종류 11가지가 추가되는 동안 회귀가 거의 발생하지 않았다.

DESIGN 시선이 잡은 것

"Lv1과 Lv10의 도로색이 같으면 진척감이 안 느껴진다. 톤 변화 4단계(낮 → 오후 → 황혼 → 밤)를 도입하라."

PLAN v1은 도로색을 단일 #444로 두었다. DESIGN 리뷰 후 ROAD_TIERS 4단계 톤 시스템이 도입됐고, 레벨별 smoothstep 보간으로 점진적 변화를 주는 설계가 됐다. 이는 사용자가 "내가 진행하고 있다"는 감각을 시각으로 받게 만드는 핵심 기여다.

그림 설명: PLAN v1 → v2의 변화를 차원별로 정리한 표다. 같은 PLAN 문서의 세 차원(범위·아키텍처·UX)에서 각각 다른 시선이 다른 결함을 잡았다. 한 시선으로 다 잡으려 했다면 어느 한 차원은 비어 있는 채로 코드까지 흘러갔을 것이다. 표 아래 노란 박스는 세 리뷰의 결론이 합쳐져 도출된 PLAN v2 + CHECKLIST v2(U1~U29 항목)를 표시한다. CHECKLIST는 "이 세 시선이 잡은 것을 잊지 않는다"는 약속을 코드 레벨에서 추적하는 장치다.

핵심 메시지

PLAN을 한 머리로 짜지 말라. 세 시선이 각자 다른 차원을 본다. car-game에서 /plan-* 3종은 (1) MVP 마일스톤 분리(CEO), (2) spawner priority chain 패턴(ENG), (3) ROAD_TIERS 4단 톤 시스템(DESIGN) — 세 가지 결정적 변경을 PLAN v2에 박았다. 셋 중 하나라도 빠졌다면 1주일 안에 publish는 불가능했거나, 장애물 추가 시마다 회귀가 누적됐거나, 사용자가 진척감을 못 느꼈을 것이다.

다음 글은 이렇게 만든 PLAN을 들고 실제 구현 사이클로 들어간다. 첫 번째 게이트는 /review — 테스트가 못 보는 의미 부패를 청소하는 자리다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.