AI한테 “앱 만들어줘” 한 마디가 왜 오히려 느린가
한 세션 = 한 항목, 의존 인지 분할이 속도를 만드는 메커니즘
AI한테 “이 앱 만들어줘” 한 줄 던지고 기다렸다가, 절반쯤 가서 컨텍스트가 터지거나 길을 잃어본 적 있으신가요. 빠르게 가려고 통으로 맡겼는데 오히려 느려지는 그 현상 말입니다.
저도 처음엔 “AI니까 다 맡기면 빠르겠지”라고 생각했습니다. 해보니 달랐습니다. myWiki를 build-plan 스킬로 B1~B17까지 실제로 지으면서, 왜 쪼개는 게 빠른지를 메커니즘 단위로 확인했습니다. 오늘 노가리치면서 개발한 그 경험이 제품 데모이자 제작 방법론이라는 걸 6시간째 라이브로 보고 있었으니까요.
문제: 통으로 던지면 느려진다
한 세션에 전부 넣으려다 컨텍스트 한계에 부딪히면 품질이 떨어집니다. AI가 앞부분 설계를 잊고 중간에 다른 방향으로 짜기 시작합니다. 재작업이 쌓이죠.
계획 없이 진행하면 더 큰 문제가 생깁니다. 중간에 설계 충돌이 발견되면 되돌리는 비용이 엄청납니다. 영속성 레이어를 다 짜고 나서 도메인 계약이 틀렸다는 걸 알면, 그 위에 쌓인 게 전부 흔들립니다.
build-plan의 분할 원리 — “한 세션 = 한 항목 = 자족적 단위”
build-plan 스킬이 하는 일은 목표를 **“한 세션에 독립 실행 가능한 단위”**로 쪼개는 겁니다. 여기서 핵심은 단순 체크리스트가 아니라는 거예요. 항목마다 의존 관계와 모드(plan/auto), 게이트 태그가 붙습니다.
구조는 이렇습니다.
- 줄기(계약) — 전체가 의존하는 기반 계약. B1~B5 같은 영속성·도메인·게이트웨이 레이어. 계약이 틀어지면 가지 전체로 전파되니 사람 게이트를 넣습니다.
- 가지(병렬) — 줄기 계약이 굳은 다음 내려오는 독립 슬라이스들. B6~B11처럼 worktree로 격리해 동시 실행 가능합니다.
- 통합 → 검증 — 가지를 합치고 끝을 맺는 구간.
목표 크기에 따라 right-size합니다. 작은 목표는 평면 리스트로 충분하고, 큰 목표만 이 줄기→가지 구조가 값어치를 합니다.
시간이 단축되는 4가지 메커니즘
이게 이 글의 심장입니다.
① 컨텍스트가 안 터진다
한 항목 = 한 세션 = 한 컨텍스트. 세션 안에서 처리하는 범위가 명확하니 컨텍스트 한계에 걸리지 않습니다. 품질이 유지되고 재작업이 줄어듭니다.
② 줄기 계약을 먼저 확정한다
myWiki에서 줄기 B1~B5를 완료하고 통합 main 검증을 돌렸을 때 실버그 두 건(next-env.d.ts ESLint 충돌, .env 빈 placeholder)이 잡혔습니다. 가지로 내려가기 전에 잡았으니 슬라이스 6개가 그 오류를 상속하지 않았습니다. 계약 게이트가 값을 한 장면이었습니다.
③ worktree 병렬로 벽시계 시간을 압축한다
가지 B6~B11은 worktree로 격리해 동시 실행합니다. 워크플로우 하나로 팬아웃하면 순차 실행 대비 벽시계 시간이 줄어듭니다. 이 구간이 자동화 ROI가 제일 높습니다. B6 미완 상태에서도 B7을 진행할 수 있었던 건 격리 결정을 미리 내렸기 때문입니다.
④ plan/auto 분할로 사람 개입을 최소화한다
auto 구간(가지)에서 사람 개입은 0입니다. 에이전트가 루틴한 편집을 알아서 처리합니다. 사람은 계약·핵심 지능·배포 같은 게이트에서만 시간을 씁니다.
여기서 재밌는 경험을 했습니다. auto 모드로 돌리는데 MikroORM v6 설계문서와 실제 v7 세팅이 충돌하는 순간, 에이전트가 자기 판단으로 넘어가지 않고 올려줬습니다. “auto = 절대 안 물어봄”이 아닙니다. 모드 축(plan/auto)과 에스컬레이션 축은 따로 돕니다. 4레버 방법론에서 말하는 것처럼, 중요하고 되돌리기 어려운 결정, 그리고 사용자 몫인 결정은 모드를 뚫고 올라옵니다.
실전 경험 — 여유롭다는 게 증거였다
한창 작업 중에 이런 생각이 들었습니다. “todo 만들어놓고 돌리니까 너무 여유로운데? 이거 없이 프로젝트 개발할 때는 진짜 정신없었는데.”
예전에 정신없던 이유가 있었습니다. 의존 그래프와 “다음 뭐였지”가 전부 머릿속에 있었기 때문입니다. “이거 하려면 저게 먼저고, 아 근데 저기 손대면 여기 깨지고…” 그 상태를 사람 워킹메모리로 들고 있으니 미칠 수밖에요.
build-plan.md가 그 상태를 머리 밖 종이로 빼낸 겁니다. 뇌에서 RAM을 비운 거죠.
그리고 역할이 바뀌었습니다. 예전엔 모든 키 입력을 직접 쳤다면, 지금은 에이전트가 실행하고 에스컬레이션만 올라옵니다. 사람은 “방향과 판단”에 앉아 있고, AI가 “실행과 검증”을 지고 갑니다. 여유는 농땡이가 아니라 시스템이 설계대로 도는 증거였습니다.
언제 안 맞나 — 솔직한 한계
작은 목표에 풀 build-plan을 붙이면 ceremony 오버헤드가 이득보다 큽니다. 평면 리스트면 충분합니다.
“무인 전구간” 욕심도 함정입니다. 줄기 계약이 0.5% 틀어진 채 자동으로 흐르면 가지 6개와 통합 4개가 전부 그 오류를 상속합니다. 사람이 디버깅하는 비용이 자동화로 아낀 것보다 커집니다. 계약·핵심 지능·배포는 사람 게이트가 의도된 분할선입니다.
한 번 해보신다면
다음에 큰 걸 AI한테 맡길 때, 바로 “만들어줘” 하지 말고 먼저 이렇게 해보세요.
“한 세션에 끝낼 수 있는 단위로 쪼개고, 뭐가 뭐에 의존하는지 표시해줘.”
쪼갠 단위에 의존과 게이트만 붙여도 통으로 던졌을 때보다 빠르고 덜 엉킵니다. 구체적인 포맷이 궁금하다면 빌드플랜 지시서 작성법을 참고하세요. 그게 build-plan이 하는 일입니다.
<- 이전 편: AI 에이전트에게 지시서 쓰는 법 · 심화: Claude Code 4레버 방법론 · 배경: 스킬의 비밀 · 배경: 마이위키 탄생 스토리]