나눠서 정복한다Phase 시스템과 우공이산의 원리

하네스의 첫 번째 원칙

시리즈 3에서 하네스 엔지니어링이 왜 필요한지를 확인했다. 그렇다면 실제로 하네스를 설계할 때, 가장 먼저 고려해야 할 원칙은 무엇일까?

답은 하나다.

나눠서 정복한다 (Divide and Conquer).

이것은 새로운 아이디어가 아니다. 컴퓨터 과학의 고전이고, 공학의 기본 원리다. 하지만 AI 에이전트 시대에 와서, 이 원칙은 단순한 팁이 아니라 생존 전략이 되었다.

이유는 단순하다. AI의 컨텍스트 윈도우가 유한하기 때문이다. 그리고 그 유한함 안에서 의미 있는 결과를 내려면, 작업 자체를 AI가 소화할 수 있는 단위로 쪼개는 것 외에는 방법이 없다.

우공이산 — 어리석어 보이는 노인의 지혜

중국의 옛 이야기에 우공이산(愚公移山)이 있다. 90세 노인이 집 앞을 가로막은 거대한 산을 옮기겠다고 나선다. 사람들은 비웃는다. "평생 걸려도 못 옮길 산을 어떻게 옮기겠다는 거요?"

노인은 답한다.

"내가 못 옮기면 내 아들이, 아들이 못 옮기면 손자가 옮긴다. 산은 더 커지지 않지만 사람은 계속 불어난다. 언젠가는 반드시 옮겨진다."

이것이 분할 정복의 원형이다. 큰 문제를 한 번에 풀려고 하지 말고, 풀 수 있는 단위로 쪼개서 하나씩 처리하는 것.

AI에게 "시스템 전체를 리팩토링해줘"를 던지면 안 되는 이유

AI에게 "이 시스템 전체를 리팩토링해줘"라고 던지면 어떻게 될까?

• 컨텍스트 윈도우에 시스템 전체가 담기지 않는다 (블라인드 컨텍스트)
• 긴 세션에서 초반 결정이 후반에 묻힌다 (Context Rot)
• 어떤 결정이 어디서 내려졌는지 추적 불가 (추적성 부재)
• 중간에 실패해도 어디로 돌아가야 할지 모른다 (자기 수정 불가)
• 결과의 품질이 세션마다 달라진다 (비일관성)

시리즈 1, 2, 3에서 본 모든 한계가 한꺼번에 터진다. 그리고 이 한계는 프롬프트를 더 정교하게 다듬거나, 컨텍스트를 더 많이 넣는다고 해결되지 않는다.

"설계안을 작성해줘"라고 던지면 달라진다

같은 시스템을 다루더라도, 작업을 하나의 명확한 단위로 쪼개면 이야기가 달라진다.

❌ "이 시스템 전체를 리팩토링해줘"
    → 컨텍스트 폭발, 실패

✅ "이 요구사항을 기반으로 이 모듈의 설계안을 작성해줘"
    → 필요한 컨텍스트가 윈도우 안에 들어옴, 성공

무엇이 바뀌었는가? 작업의 크기가 바뀌었다. 그리고 그에 따라 필요한 컨텍스트의 크기가 바뀌었다. AI가 한 번에 처리해야 할 정보가 관리 가능한 수준으로 줄어든 것이다.

이것이 Phase 시스템의 출발점이다. 우공이 산을 옮기는 방식으로, AI가 소프트웨어를 만드는 것.

Phase 분할 — 컨텍스트 격리의 기술

Phase 시스템의 핵심 아이디어는 단순하다. 개발 프로세스를 여러 Phase로 나누고, 각 Phase가 독립된 목표와 제한된 컨텍스트를 갖게 한다.

각 Phase는 무엇을 가지는가

• 독립된 목표 — 이 Phase는 무엇을 만들어내는가
• 필요한 입력 — 이 Phase가 시작할 때 어떤 정보가 필요한가
• 산출물 — 이 Phase가 끝났을 때 어떤 문서/코드가 생성되는가
• 제한된 컨텍스트 — 이 Phase가 다루는 정보의 범위

예를 들어 이런 식이다:

Phase 1: 요구사항 분석
  입력:    사용자 요청 + 제약 조건
  산출물:  요구사항 명세서 (REQ-ID 포함)
  컨텍스트: 요구사항 자체만 — 아직 코드도, 설계도 없다

Phase 3: 아키텍처 설계
  입력:    요구사항 명세서 + 기존 코드 구조 요약
  산출물:  아키텍처 설계 문서
  컨텍스트: 설계에 필요한 정보만 — 구체적 구현은 아직 없다

Phase 5: 구현
  입력:    실패하는 테스트 + 설계 문서
  산출물:  테스트를 통과하는 코드
  컨텍스트: 구현에 필요한 정보만 — 다른 모듈의 디테일은 제외

컨텍스트 격리가 만드는 것

이 접근의 핵심은 각 Phase가 자기 일에 필요한 최소한의 컨텍스트만 본다는 것이다.

[ 전체 시스템을 한 번에 다룰 때 ]
컨텍스트 윈도우: ████████████████████ (100% 사용, Context Rot 발생)
AI의 판단 품질: ▆ (낮음)

[ Phase로 나눠서 다룰 때 ]
Phase 1 윈도우: ████ (20% 사용)          → AI 판단 품질: ██████ (높음)
Phase 3 윈도우: ██████ (30% 사용)        → AI 판단 품질: ██████ (높음)
Phase 5 윈도우: ████████ (40% 사용)      → AI 판단 품질: █████ (높음)

각 Phase의 컨텍스트 사용량이 작기 때문에 Context Rot이 발생하지 않는다. AI가 각 Phase의 정보를 명확하게 회상하고 정확하게 추론할 수 있는 영역에서 작업이 이뤄진다.

HBM이 유한하다면, 한 번에 조리대 위에 올리는 재료의 양을 줄이면 된다. Phase 분할은 이 원리를 워크플로우 레벨에서 실행한다.

추적성 — Phase를 관통하는 실

Phase로 나누면 자연스럽게 드는 의문이 있다.

"그러면 Phase 간의 맥락은 어떻게 유지하는가?"

Phase 1에서 내린 결정이 Phase 5의 구현에 영향을 주어야 한다. Phase 3에서 설계한 아키텍처가 Phase 7의 테스트에 반영되어야 한다. 컨텍스트 윈도우는 Phase마다 격리되는데, 어떻게 Phase 사이의 맥락이 이어지는가?

해답 — 추적 매트릭스

여기서 추적성 매트릭스(Traceability Matrix)가 등장한다. 모든 Phase가 공유하는 단일한 문서이고, 각 Phase가 이 문서를 업데이트한다.

[ 추적 매트릭스의 구조 ]

REQ-ID  | 요구사항 | 설계 | 테스트 | 구현 위치     | 결과
─────────────────────────────────────────────────────────
REQ-001 | 사용자   | ...  | UT-01  | auth.ts:45   | PASS
        | 로그인   |      | IT-02  | auth.ts:67   |
REQ-002 | 비밀번호 | ...  | UT-05  | hash.ts:12   | FAIL
        | 해싱     |      |        |              |

• Phase 1에서 요구사항을 등록하면서 REQ-ID를 부여한다
• Phase 4에서 테스트를 만들면서 해당 REQ-ID와 연결한다
• Phase 5에서 구현하면서 코드 위치(file:line)를 기록한다
• Phase 7에서 테스트 결과를 기록한다

이 매트릭스는 단일 출처(Single Source of Truth)로 기능한다. 어떤 Phase에 있든, 이 매트릭스만 보면 전체 프로젝트의 상태를 파악할 수 있다.

추적 매트릭스의 두 가지 역할

1. 컨텍스트 전달 도구. 새로운 Phase가 시작될 때, AI는 이전 Phase의 전체 대화 기록을 받는 대신 추적 매트릭스만 받는다. 매트릭스에는 이전 결정들의 핵심 요약이 구조화되어 있다. Phase 간의 맥락이 "요약된 형태"로 전달되는 것이다. 이것이 긴 세션의 Context Rot을 피하는 방법이다.

2. 검증과 감사 도구. 프로젝트가 끝난 후에도 이 매트릭스는 남는다. 6개월 뒤 버그가 발생했을 때, "이 코드는 어떤 요구사항에서 나왔는가?"를 역추적할 수 있다. 감사(audit)가 필요한 산업(금융, 의료, 임베디드)에서는 이것이 법적 요구사항이기도 하다.

추적성은 구조적 기억이다

시리즈 2에서 본 것처럼, AI의 기억력은 HBM에 묶여 있다. 추적 매트릭스는 이 물리적 한계를 구조적 기억으로 우회하는 방법이다.

AI가 모든 것을 기억하게 하는 대신, 기억해야 할 것을 명시적 문서로 만든다. 문서는 HBM 밖에 존재하고, 필요할 때만 Phase의 컨텍스트로 불러온다.

추적성은 단순한 관리 도구가 아니다. AI의 물리적 한계를 극복하기 위한 핵심 메커니즘이다.

자기 수정 — LOOPBACK으로 실패를 다루기

Phase 시스템을 완벽하게 설계해도, 실패는 일어난다. 테스트가 깨지고, 리뷰에서 문제가 발견되고, 예상치 못한 엣지 케이스가 튀어나온다.

실패 없는 개발은 존재하지 않는다. 중요한 것은 실패를 어떻게 다루느냐다.

실패의 두 가지 접근

실패를 다루는 방식에는 두 가지가 있다.

접근 1. 처음부터 다시 — 실패하면 맨 처음으로 돌아간다. 깨끗하지만 낭비가 크다. 대부분의 작업이 버려진다.

접근 2. 구조적 복귀 — 실패의 원인을 분류하고, 그 원인에 해당하는 Phase로만 돌아간다. 낭비를 최소화하고, 문제를 정확히 조준한다.

Phase 시스템은 두 번째 접근을 택한다. 이것이 LOOPBACK이다.

LOOPBACK의 원리

테스트가 실패했다고 해보자. 원인은 네 가지 중 하나다.

구현 버그        → Phase 5 (구현)로 돌아간다
테스트 설계 오류  → Phase 4 (테스트)로 돌아간다
아키텍처 결함    → Phase 3 (설계)로 돌아간다
요구사항 불명확  → Phase 1 (요구사항)로 돌아간다

각 실패에는 책임 Phase가 있다. 원인을 정확히 분류하면 그 Phase로만 돌아가면 된다. 나머지 Phase의 작업은 그대로 유지된다.

이것은 단순해 보이지만 강력하다. 전체 작업의 90%가 유효한 상태에서, 문제가 있는 10%만 고치는 것. 실패의 비용을 극적으로 낮춘다.

LOOPBACK의 한계 — 무한 루프 방지

LOOPBACK이 강력하다고 해서 무한히 사용할 수는 없다. 같은 Phase를 계속 반복하면 AI가 동일한 실수를 반복할 수 있고, 무한 루프에 빠질 수 있다.

그래서 LOOPBACK에는 제한이 있어야 한다.

[ LOOPBACK 제한의 예 ]
- 전체 프로젝트에서 최대 5회
- 같은 Phase는 최대 2회까지
- 한 Phase를 두 번 돌았는데도 실패 → 상위 Phase로 에스컬레이션
  (예: 구현을 두 번 고쳤는데도 실패 → 설계 결함 가능성)
- 최대 횟수 초과 → 자동 실행 중단, 인간에게 보고

중요한 것은 AI가 해결할 수 없는 영역이 존재한다는 것을 시스템 레벨에서 인정하는 것이다. 무한히 돌리는 것이 아니라, 일정 횟수 후에는 인간의 판단에 넘긴다.

이것이 AI와 인간의 협업 구조다. AI는 빠르게 반복하지만, 막힐 때는 겸손하게 멈추고 인간에게 넘긴다.

인간 개입 지점 — Gate

Phase 시스템은 완전 자율이 아니다. 특정 Phase 사이에는 Gate가 배치된다. 인간이 AI의 산출물을 검토하고 승인하는 지점이다.

Gate가 필요한 이유

AI는 빠르게 실행한다. 하지만 빠르다고 해서 옳은 방향으로 가는 것은 아니다.

• Phase 1에서 AI가 요구사항을 해석했다 → 이 해석이 맞는가?
• Phase 3에서 AI가 아키텍처를 설계했다 → 이 설계가 우리 시스템에 맞는가?
• Phase 5에서 AI가 구현을 완료했다 → 이 구현을 프로덕션에 올려도 되는가?

이 판단들은 인간의 책임 영역이다. 그리고 이 판단이 잘못되면 바로 다음 Phase들이 모두 잘못된 방향으로 간다. Phase가 많을수록 이 리스크는 커진다.

Gate는 이 리스크를 차단하는 체크포인트다.

Gate의 위치

모든 Phase 사이에 Gate를 두면 개발이 느려진다. 그렇다고 Gate가 없으면 AI가 잘못된 방향으로 폭주한다. 균형이 필요하다.

일반적으로 Gate는 방향이 결정되는 지점에 배치된다.

Phase 1 (요구사항) → [Gate: 요구사항 검토] → Phase 2, 3, 4...
Phase 3 (설계)    → [Gate: 설계 검토]     → Phase 4, 5, 6...
Phase 8 (리뷰)    → [Gate: 최종 승인]     → Phase 9 (완료)

이 세 곳은 공통점이 있다. 뒤로 돌리는 비용이 크다. 요구사항이 잘못된 상태로 구현까지 갔다면, 구현을 통째로 버려야 한다. 설계가 잘못된 상태로 테스트를 만들었다면, 테스트를 통째로 다시 만들어야 한다.

Gate는 비싼 실수를 사전에 막는 방어선이다.

Gate는 "검증"이 아니라 "판단"이다

Gate에서 인간이 하는 일은 단순한 체크가 아니다. "이 방향이 맞는가"에 대한 판단이다.

• AI가 요구사항을 이렇게 해석했는데, 이게 사용자의 진짜 의도인가?
• AI가 이런 설계를 제안했는데, 우리 시스템의 제약과 맞는가?
• AI가 구현을 완료했는데, 이 변경이 시스템 전체에 미치는 영향은?

이 질문들은 AI가 답할 수 없다. 사용자의 의도, 시스템의 역사, 팀의 컨벤션, 하드웨어 제약 — 모두 컨텍스트 윈도우 밖의 정보다. 개발자의 멘탈 모델에만 있는 것이다.

AI가 Phase를 실행하는 동안, 개발자는 Gate에서 기다린다.
하지만 이 "기다림"은 수동적 대기가 아니다. 능동적 판단 행위다.

분할 정복의 네 기둥

정리하면, Phase 시스템은 네 가지 기둥 위에 서 있다.

┌─────────────────────────────────────┐
│                                     │
│       Phase 시스템 (분할 정복)       │
│                                     │
├──────────┬──────────┬──────────┬────┤
│          │          │          │    │
│  Phase   │  추적    │  LOOP    │ Gate│
│  분할    │  성      │  BACK    │     │
│          │  (RTM)   │          │     │
│          │          │          │     │
│ 컨텍스트 │ 구조적   │ 실패의   │ 인간 │
│ 격리     │ 기억     │ 구조적   │ 판단 │
│          │          │ 복구     │ 지점 │
│          │          │          │     │
└──────────┴──────────┴──────────┴────┘

• Phase 분할 — 컨텍스트를 격리해 Context Rot을 피한다
• 추적성 (RTM) — Phase 간 맥락을 구조적 문서로 이어준다
• LOOPBACK — 실패를 원인별로 분류해 정확한 Phase로 복귀한다
• Gate — 비싼 실수를 사전에 막는 인간의 판단 지점

이 네 가지가 함께 있어야 분할 정복이 작동한다. 하나라도 빠지면 무너진다.

• Phase만 나누고 추적성이 없으면 → Phase 간 맥락이 사라진다
• 추적성만 있고 LOOPBACK이 없으면 → 실패할 때마다 처음부터 다시
• LOOPBACK만 있고 Gate가 없으면 → AI가 잘못된 방향으로 폭주
• Gate만 있고 Phase 분할이 없으면 → 컨텍스트 윈도우가 터진다

그런데 이것만으로 충분한가

Phase 시스템이 아무리 잘 설계되어 있어도, 그것을 운용하는 개발자의 마인드셋이 바뀌지 않으면 의미가 없다.

좋은 하네스를 갖고도 잘못된 질문을 던지면 잘못된 답이 나온다. AI에게 "이거 만들어줘"라고 던지고 검증 없이 커밋하면, Phase 시스템이 있든 없든 결과는 무너진다.

하네스는 도구다. 도구를 쓰는 것은 사람이다. 그리고 AI 시대의 사람 — 개발자 — 에게 요구되는 마인드셋이 있다.

• 병목이 "어떻게"에서 "무엇을"로 이동했다
• 질문을 설계하는 능력이 핵심 역량이 됐다
• 결과에 책임지는 자세가 더 중요해졌다
• 본질을 아는 사람이 유행을 쫓는 사람을 이긴다

실행이 싸질수록 판단이 비싸진다. 이 명제가 무엇을 의미하는지, 다음 편에서 파헤친다.

다음 편 예고

Phase 시스템은 AI의 물리적 한계를 구조로 극복하는 도구다. 하지만 도구만으로는 안 된다. 그 도구를 쓰는 개발자의 사고방식이 AI 시대의 경쟁력을 결정한다.

실행 비용이 10분으로 떨어진 시대에, 개발자에게 남은 가치는 무엇인가?