범용 AI 태스크 주도 엔진이 중첩 루프 (Nested Loops)를 통해 어떻게 국소적 결함 허용 (Local Fault Tolerance) 및 안정성 보장을 달성하는지에 대하여.

파트 1: 시작하기

1. 문제점: 바이브 코딩 (Vibe Coding)에서 자율 운영으로

현재 주류인 AI 보조 개발은 여전히 바이브 코딩 (Vibe Coding) 단계에 머물러 있습니다. 즉, 인간이 프롬프트를 입력하면 AI가 응답하고, 인간이 수정하면 AI가 다시 응답하는 방식입니다. 이를 인간이 루프 안에 있는 모델 (Human in the Loop model)이라고 부를 수 있습니다. 모든 출력물에 대해 인간의 확인과 수정이 필요하며, 인간과 AI가 번갈아 가며 작업합니다.

이 모델에는 두 가지 문제가 있습니다.

첫 번째는 품질 관리 (Quality Control)의 상실입니다. AI 실행은 본질적으로 확률적 샘플링 (Probabilistic Sampling) 과정입니다. 외부 제어 구조의 개입이 없다면, AI는 쉽게 경로를 이탈할 수 있습니다. 예를 들어, 작업 중간에 다른 코드를 변경하거나, 변경 후 테스트 실행을 잊거나, 실패 시 무한 루프에 빠지거나, 충돌 후 상태를 잃어버려 처음부터 다시 시작해야 하는 경우가 발생할 수 있습니다. 더욱 위험한 것은 실제 구현하지 않고도 작업이 완료되었다고 스스로 선언하는 것입니다.

두 번째는 역량의 한계입니다. 인간이 루프 안에 있을 때, 궁극적인 병목 현상은 여전히 인간의 작업 시간과 에너지입니다. 한 사람이 하루에 8시간을 일한다면, AI 보조로 효율이 3배가 된다 하더라도 한계치는 24인시 (Person-hours)에 불과합니다. AI의 생산성을 진정으로 해방시키기 위해서는 인간이 루프 위에 있는 방식 (Human on the Loop)으로 이동해야 합니다. 즉, AI가 7x24시간 완전히 자율적으로 실행되고, 인간은 루프에서 벗어나 필요할 때만 개입하는 제어 요소가 되는 것입니다.

이는 단순히 운영 모드의 전환이 아니라 비용 구조의 변화를 의미합니다. AI가 7x24시간 자율적으로 실행될 수 있다면, 더 이상 작업 시간이 제약 사항이 되지 않습니다. 성능이 낮은 모델은 작업을 완료하는 데 더 오랜 시간이 걸리고 더 많은 토큰 (Tokens)을 소비할 수 있지만, 인간의 시간을 점유하지 않고 밤에도 실행할 수 있을 만큼 충분히 저렴합니다. 여러 미션 (Missions)이 서로 다른 로드맵 작업 항목들을 병렬로 처리할 수 있습니다. 비용 산정 방식은 "인시당 산출물"에서 "달러당 지능적 산출물"로 변화합니다.

Mission Driver는 이러한 전환을 실현하는 구체적인 제어 구조(control structure)입니다.

2. Mission Driver란 무엇인가 (1분 요약 버전)

Mission Driver는 선언적 작업 주도 엔진(declarative task-driven engine)입니다. 사용자가 목표(로드맵을 통해 기술됨)를 부여하면, 엔진은 자동으로 다음과 같은 루프(loop)에 진입합니다:

상태 점검 (초기 1회) → 계획 검토 → 계획 실행 → 새로운 계획 초안 작성 → (계획 검토로 복귀) → 더 이상 새로운 계획을 작성할 수 없을 때 → 심층 감사 (Deep audit) → (계획 검토로 복귀)...

이 루프는 목표가 달성되거나 감사 예산(audit budget)이 소진될 때까지 실행됩니다. 각 단계는 독립적인 AI 하위 프로세스(subprocess) 또는 스크립트 함수이며, 단일 단계의 실패가 전체 루프에 영향을 미치지 않습니다.

이는 Attractor-Guided Engineering(기사 끝부분에 오픈 소스 저장소 링크 제공)의 구성 요소이며, 소프트웨어 개발에만 국한되지 않습니다. 사용자 정의 흐름(flow), 프롬프트(prompt), 명령(command)을 구성함으로써 데이터 처리 및 문서 분석과 같은 시나리오로 자연스럽게 일반화될 수 있으며, 이는 완전 자율 AI 운영을 위한 보편적인 메커니즘입니다.

장기 실행(long-running execution)이 필요하고, 명확한 수락 기준(acceptance criteria)이 있으며, 다단계 반복(multi-step iteration)이 필요한 복잡한 작업에 적합합니다.

루프 엔지니어링 (Loop Engineering)은 AI 엔지니어링 분야에서 빠르게 부상하고 있는 설계 방법론입니다. 이는 선형적인 프롬프트(linear prompts) 대신 루프 구조를 사용하여 AI 시스템이 목표를 달성할 때까지 자율적으로 실행되도록 합니다. 이는 특정 도구의 독점적인 기능이 아니라, 특정 도구와 무관하게 설계할 수 있는 엔지니어링 패턴입니다. Mission Driver는 루프 엔지니어링의 범용 참조 구현체(general reference implementation)입니다.

3. 작동 원리: 루프 중첩 및 국소 결함 허용 (Loop Nesting and Local Fault Tolerance)

Vibe Coding을 하나의 무한 루프 (single infinite loop)로 본다면, Mission Driver의 핵심은 그 단일 루프를 중첩된 다층 루프 (nested multi-layer loops)로 분해하는 것입니다. Mission Driver의 메인 루프 (5단계 폐쇄 루프)가 가장 바깥쪽 레이어이며, 그 안에 내장된 내부 레이어들이 존재합니다: 즉, Plan Loop (EXEC_PLANS 서브플로우 내의 execute → check → audit → verify 사이클)와 선택적인 Audit Loop (DEEP_AUDIT 서브플로우 내의 다차원 감사 사이클)입니다. 이러한 중첩 구조를 이해하는 것이 Mission Driver가 왜 장기간 안정적으로 실행될 수 있는지를 이해하는 핵심입니다.

3개의 활성 계획 (active plans)이 있다고 가정할 때, plan-002의 실행이 차단(blockage)에 부딪힌다면 다음과 같습니다:

EXEC_PLANS:
  ├── plan-001: EXECUTE ✓ → CHECK ✓ → BUILD ✓ → completed ✓
  ├── plan-002: EXECUTE ✗ → 3회 재시도 후에도 실패 → 서브플로우 실패
...

plan-002의 실행 차단은 plan-001 및 plan-003에 아무런 영향을 미치지 않습니다. 차단 현상은 서브플로우 내에 국한되며, 형제 서브플로우 (sibling subflows)나 상위 루프 (parent loop)로 전파되지 않습니다. 이것이 바로 루프 중첩 (loop nesting)을 통해 구현된 국소 결함 허용 (local fault tolerance)입니다.

계획 실행 중에 AI는 실제 상황에 기반하여 결정합니다: 국소적으로 차단된 항목은 후속 트리거 조건이 기록된 상태로 Deferred But Adjudicated (판결되었으나 보류됨)로 이동하며, 나머지 범위는 정상적으로 완료됩니다. 만약 계획의 방향 전체가 잘못된 것으로 판명되면, superseded (대체됨) 또는 cancelled (취소됨)로 표시됩니다. 계획의 .md 파일 상태는 항상 AI 에이전트에 의해 관리됩니다.

각 단계의 실행 상태는 디스크에 영구 저장됩니다 (계획 파일 내의 체크박스). 프로세스가 충돌 후 재시작되면, 엔진은 디스크의 체크박스 표시를 스캔하여 히스토리를 다시 재생(replay)하지 않고 중단점 (breakpoint)부터 재개합니다.

Part 2: 시작하기

4. 퀵 스타트 (Quick Start)

Mission Driver의 소스 프로젝트는 AGE Template 프로젝트에 있습니다. 일반적으로, 우리는 자체 프로젝트에 tools/mission-driver.sh 스크립트를 추가하여 Mission Driver로의 호출을 프록시(proxy)하고, MISSION_DRIVER_HOME 환경 변수를 통해 Mission Driver 소스 디렉토리를 가리키도록 합니다.

시작하기 흐름 (Getting started flow):

1. AGE 템플릿을 다운로드하고, AI가 이를 읽어 프로젝트에 맞게 조정하도록 합니다 (문서 구조 조정, 명령 구성, 로드맵 초기화).
2. 테스트 명령어가 실행 가능한지 확인합니다 (npm test / mvn test / Playwright).
3. 일상적인 AI 대화에서, 계획 가이드(plan guide)에 따라 plans 디렉토리에 계획을 초안으로 작성하며, 계획과 로그를 축적합니다.
4. 미션(mission)을 시작합니다.

# 미션 설정 + 로드맵 생성
./tools/mission-driver.sh draft "your goal description"

...

모니터링 (Monitoring):

Mission Driver에는 내장된 시각적 모니터링 페이지가 있습니다.

open http://localhost:9300              # 브라우저 대시보드
cat _tmp/<runDir>/run-state.json        # 상태 읽기
tail -f _tmp/<runDir>/<mission>.log     # 로그 추적

중단 및 복구 (Interruption and Recovery):

# Ctrl-C 안전 중단 (엔진이 시그널을 포착하여 자식 프로세스를 정리함)
# 재실행 시 자동으로 재개됨
./tools/mission-driver.sh run <name>
...

사후 분석 (Postmortem):

./tools/mission-driver.sh analyze           # 가장 최근 실행 분석
./tools/mission-driver.sh analyze <runId>   # 특정 실행 분석

사후 분석(Postmortem)은 모든 이벤트와 로그를 스캔하고, 사후 분석 에이전트(postmortem agent)를 실행하며, 구조화된 보고서를 memory 디렉토리에 작성합니다. 동일한 모듈에 대한 후속 미션은 이러한 학습된 교훈(lessons learned)을 자동으로 로드합니다.

5. 4계층 정의 시스템 (The Four-Layer Definition System)

Mission Driver는 프로그래밍이 아닌 설정을 통해 사용되는 네 가지 계층의 정의로 구성됩니다.

5.1 Mission Config (missions/<name>.json)

무엇을 할지, 어디서 할지, 그리고 어떻게 검증할지를 선언하는 순수 정적 설정 (Pure static configuration)입니다:

{
  "name": "medical-qa",
  "description": "Generate QA training dataset from medical papers",
...

commands.test는 필수 필드이며, CHECK와 BUILD_VERIFY 모두 이를 실행합니다. build/lint/typecheck는 선택 사항이며, 누락된 경우 건너뜁니다. 런타임 상태 (Runtime state)는 _tmp/<runId>/run-state.json에 저장되며, mission.json에는 기록되지 않습니다.

5.2 Flow Definition

엔진의 핵심은 범용 상태 머신 DSL 실행기 (generic state machine DSL executor) (FlowEngine, 프로젝트 특정 로직 없음)입니다. Flow 정의는 단계(steps)가 어떻게 오케스트레이션되는지, 전이 (transitions)가 어떻게 발생하는지, 그리고 오류 발생 시 무엇을 할지를 선언합니다. 엔진은 고정된 단계에 얽매이지 않고 flow 설명에 따라 상태 머신을 진행시킵니다.

단순화된 flow 구조:

{
  "name": "my-flow",
  "entry": "CHECK",
...

• 단계 유형 (Step types): agent (AI 하위 프로세스), script (JS 함수), subflow (중첩된 서브플로우), group (그룹화된 단계)
• 제어 흐름 (Control flow): transitions는 단계 간의 점프 (goto/done/retry)를 정의합니다; forEach는 컬렉션을 반복하며 요소당 하나의 서브플로우를 실행합니다; when/otherwise는 조건부 건너뛰기를 위해 사용됩니다.
• 오류 처리 (Error handling): 각 단계는 maxRetries, onMaxRetries, onError, onUnknown을 설정할 수 있습니다; 엔진은 또한 전역 무한 루프 탐지 (ping_pong + max_cycles + max_total_steps) 기능을 제공합니다.

내장된 기본 flow (flows/mission-driver.json)는 지금까지 논의해 온 사이클입니다. 실제 구조는 다음과 같습니다: CHECK는 진입 시 단 한 번 실행된 후, 루프 본문인 REVIEW_PLANS → EXEC_PLANS → DRAFT_PLANS로 진입합니다; DRAFT_PLANS에 초안을 작성할 새로운 계획이 없으면 DEEP_AUDIT로 진입한 후 다시 루프 본문으로 돌아옵니다. 이는 하드코딩된 것이 아니라, 단지 **기본 설정 (default configuration)**일 뿐입니다. EXEC_PLANS와 DEEP_AUDIT 자체는 독립적으로 교체 가능한 서브플로우 (plan-execution.json / deep-audit-loop.json)입니다.

이는 완전히 새로운 워크플로우(workflows)를 설계할 수 있음을 의미합니다. 예를 들어, Plan 오케스트레이션(orchestration)이 필요 없는 코드 리뷰 워크플로우를 FETCH_PR → RUN_LINT → AI_REVIEW → POST_COMMENT와 같은 4단계 흐름으로 작성할 수 있습니다. 커스텀 플로우 JSON을 missions/flows/ 디렉토리에 배치하고 mission.json에 "flowName": "<custom>"을 설정하기만 하면 되며, 엔진은 변경되지 않은 상태로 유지됩니다.

5.3 Plan 파일

Plan은 특정 형식을 따라 AI에 의해 자동으로 생성되는 가장 작은 작업 단위입니다. Plan의 핵심은 단순히 할 일 목록(to-do list)을 정의하는 것이 아니라, 완료를 판단하는 방식에 대한 클로저 계약(closure contract)을 정의하는 것입니다. 표준 구조는 다음과 같습니다.

# 01 Purchase Order Approval Workflow Integration

> Plan Status: draft
...

상태 표시기(status markers)의 상위 3개 라인, 목표 및 비목표(Goals + Non-Goals, 범위 이탈 방지용), 각 단계(Phase)별 상태 + 체크박스 + 종료 기준(Exit Criteria), 그리고 클로저 게이트(Closure Gates)는 플랜 수준의 최종 점검 항목입니다. 체크박스는 기계가 읽을 수 있는 지속적 상태(persistent state)이며, 엔진은 체크박스를 스캔하여 중단점(breakpoints)부터 작업을 재개합니다. 완료로 표시하기 전에 모든 체크박스가 체크되어 있어야 합니다.

AGE 실무에서 인간은 일반적으로 Plan을 읽을 필요가 없습니다. Plan은 전적으로 AI에 의해 자율적으로 생성되고 업데이트됩니다.

5.4 Roadmap

Roadmap은 사람이 읽을 수 있고 제어 가능한 매크로 플랜(macro plan)입니다. docs/backlog/00-roadmap-authoring-guide.md 명세에 따라 작업 항목(work items)은 마일스톤(milestones)별로 그룹화되며, todo/ready/done의 세 가지 상태만 가집니다. 마일스톤 자체는 상태를 가지지 않습니다.

# Core Business Roadmap

> Prerequisites: All CRUD completed
...

DRAFT_PLANS는 AI 에이전트를 실행합니다: 전체 로드맵과 과거 플랜의 보류 항목(deferred items)을 읽고 → 프로젝트 컨텍스트와 planGuide를 읽은 뒤 → 다음 1~3개의 작업 항목을 선택합니다 → 플랜 초안(Status: draft)을 작성하고 → 독립적인 서브 에이전트를 호출하여 검토합니다. 승인되면 해당 항목들을 active로 표시합니다. 더 이상 초안을 작성할 작업이 남지 않으면 nothing을 반환하며, 엔진은 이를 바탕으로 감사(audit) 라운드에 진입할지 여부를 결정합니다.

6. 설정 및 커스터마이징

Mission Driver 엔진은 완전히 범용적입니다. 코드를 수정할 필요가 전혀 없으며, 설정(configuration)과 프롬프트 오버라이드(prompt overrides)를 통해 커스터마이징을 수행할 수 있습니다. 일반적으로 자신의 프로젝트에 mission-driver.sh 스크립트를 추가하기만 하면 됩니다. 이 스크립트는 환경 변수(environment variables)에 설정된 경로를 통해 AGE 템플릿 프로젝트의 Mission Driver 구현체를 호출합니다.