큰 작업을 구간으로 나누는 이유 — 내 도구들이 다 같은 모양인 것을 알았을 때

AI와 큰 일을 할 때 매번 쓰는 패턴 — 왜 구간을 나누고 경계에 게이트를 두나

어느 날 제 도구들을 나란히 놓고 보다가 이상한 걸 발견했습니다. 콘텐츠 파이프라인, 빌드플랜, 제품 설계 파이프라인… 만든 맥락도 시점도 다 다른데, 생긴 모양이 전부 똑같았어요. 큰 작업을 구간으로 나누고, 구간 경계마다 게이트를 두는 구조였습니다. 우연이 아니라는 생각이 들었습니다. AI와 큰 일을 할 때 작동하는 어떤 원리가 있는 게 아닐까 싶었어요.

한 번에 다 맡기면 생기는 세 가지 문제

먼저 왜 이 패턴이 필요한지부터요. 큰 덩어리를 AI에게 통째로 던지면 세 가지 문제가 생깁니다.

첫 번째는 컨텍스트 한계입니다. 긴 작업을 한 세션에 몰아넣으면 중반을 넘기면서 품질이 무너지기 시작해요. 앞서 정한 것들을 모델이 점점 잊어버립니다.

두 번째는 오류 상속입니다. 앞 단계에서 0.5%만 틀어져도 그 위에 쌓이는 모든 게 그 오류를 물려받아요. build-plan 세션에서 실제로 경험한 일인데, 계약 레이어(영속성, 도메인 계약 같은 것들)가 잘못된 상태로 구현으로 흘러가면 나중에 고치는 비용이 처음부터 다시 하는 것보다 클 수 있습니다.

세 번째는 사람이 끼어들 지점이 사라지는 것입니다. 다 끝나고 나서야 “이건 내가 원한 게 아닌데”를 발견하게 됩니다. 그때는 이미 늦었고요.

어디서나 통하는 네 가지 원리

실제로 작동하는 분할 방식에는 패턴이 있었습니다.

① 의존 순서 — 계약과 뼈대부터, 그 위에 살. build-plan이 줄기(계약 레이어)를 먼저 세우고 그 위에 가지를 병렬로 펼치는 이유입니다. 콘텐츠 파이프라인에서 시드(seed)를 먼저 정리하고 나서 본문을 쓰는 것도 같은 원리입니다.

② 한 구간 = 한 컨텍스트 — 그래야 터지지 않습니다. build-plan에서 “한 세션 = 한 항목 = 자족적 단위”로 설계한 것도, 콘텐츠 파이프라인을 seed·draft·published 세 구간으로 나눈 것도 이 원리 때문입니다.

③ 경계마다 게이트 — 검수, 검증, 환각 체크가 구간 사이에 들어갑니다. build-plan에서 줄기 항목에 게이트(✓)를 붙여 사람이 계약을 리뷰하게 한 것, 콘텐츠 파이프라인에서 draft → 검수 → published 사이에 raw 대조 단계를 넣은 것이 그 예입니다.

④ 구간별 자동/수동 — 어디는 AI가 자율로, 어디는 사람이 직접. build-plan에서 가지 구간(B6~B11)은 auto, 줄기와 배포는 사람 게이트인 것처럼요. 콘텐츠에서 본문 작성은 AI가 하고, 검수는 사람이 하는 것처럼.

도구마다 이 패턴이 어떻게 다르게 나타나나

같은 원리가 맥락마다 다른 모양으로 나옵니다.

build-plan에서는 줄기(계약) → 가지 → 통합 → 검증 → 배포 순으로 흐르고, 줄기 통합 후 게이트에서 잠깐 멈춥니다. 줄기가 계약 레이어라 틀어지면 가지 여섯 개에 전파되기 때문에 특히 조심합니다.

콘텐츠 파이프라인은 seed → draft → published로 나뉘고, 각 경계에서 검수와 raw 대조가 들어갑니다. 이번 영상도 이 파이프라인으로 만들었는데, raw 원본을 직접 읽고 대조하는 단계가 있어서 내용을 지어내는 걸 구조적으로 막을 수 있었습니다.

product-pipeline은 요구사항 → 아키텍처 결정(ADR) → 시스템 설계 → API 계약 → 앱 아키텍처 순으로 흐르고, 각 단계마다 사람이 객관식 선택을 합니다. AI가 추천은 하되, 방향 결정은 사람이 합니다.

auto 모드여도 중요한 건 멈춥니다 — 그게 진짜 안전망

build-plan 세션에서 실제로 있었던 일입니다. MikroORM 설계 당시 v6로 했는데 세팅이 v7으로 돼 있어서 골격이 완전히 바뀌는 상황이었어요. 항목이 auto 모드였는데도 에이전트가 멈추고 물어봤습니다.

처음에는 “auto인데 왜 물어보지?”라고 생각했는데, 돌아보면 당연했습니다. auto는 “계획을 먼저 보여주지 않는” 것이지, “아무것도 안 묻는” 게 아닙니다. 결정이 구간 안에 갇히면 auto로 처리하고, 폭발 반경이 크거나 되돌리기 어렵거나 진짜 사람 몫인 결정은 모드를 뚫고 올라옵니다.

이게 정적인 게이트(항목별 auto/plan 표시)보다 훨씬 강력한 안전망입니다. 미리 분류한 것에서 놓친 케이스를 실행 중에 잡아주니까요.

언제 이 방식이 안 맞나

모든 작업에 구간을 나누는 게 좋은 건 아닙니다.

작은 작업에는 구간을 나누는 ceremony가 이득보다 비쌉니다. 간단한 수정 하나에 줄기/가지/게이트를 설계하는 것 자체가 낭비입니다. 항목이 서너 개면 평면 리스트면 충분해요.

탐색적 작업, 즉 진행하면서 구간이 계속 재정의되는 작업도 마찬가지입니다. 뭘 만들지 아직 모르는 단계에서 엄격한 분할을 강제하면 오히려 발목을 잡습니다.

실제로 써보니 달랐던 것

build-plan 방식으로 myWiki를 개발하면서 가장 놀랐던 건 역할이 바뀌었다는 것입니다. 예전에는 모든 키 입력을 제가 쳤는데(실행자), 지금은 에이전트가 실행하고 저한테는 에스컬레이션만 올라옵니다(관리자). 여유가 생겼어요. 노가리치면서 개발하는 것 자체가 가능해졌습니다.

이 여유가 농땡이가 아닌 이유는 — 시스템이 설계대로 도는 증거이기 때문입니다. 구간이 나뉘어 있고, 경계에 게이트가 있고, 에스컬레이션이 제대로 올라오면 실행은 AI가 처리합니다. 사람이 해야 할 것은 방향과 판단뿐이고요.

한 가지만 챙긴다면

AI에게 큰 작업을 맡기기 전에 딱 두 가지를 먼저 정해보세요.

① 이 작업을 어떤 구간으로 나눌까
② 구간 경계에서 뭘 확인할까

이 두 개만 있어도, 통째로 던졌을 때보다 덜 터지고 덜 엉킵니다. 그리고 AI가 멈추고 물어볼 때, 그게 성가신 게 아니라 시스템이 작동하는 신호임을 알면 — 더 편하게 일할 수 있습니다.

방법: 빌드플랜 스킬로 개발 시간 단축하기 · 심화: Claude Code 4레버 방법론 · 배경: 마이위키 탄생 스토리 · 함께 보기: 에이전트 컨텍스트 끊김과 세컨드브레인 통합 · 함께 보기: 코딩 전에 결정부터 — product-pipeline 스킬