AI로 풀어보는 AI-DLC v2: 결과물의 흐름

본 기사의 위치— 본 기사는 awslabs/aidlc-workflows 리포지토리의 규범 규칙 및 이용 가이드를 소재로 하여, 필자가 AI를 활용해 읽어내고 정리한 해석입니다. AWS가 공식적으로 발표한 방법론이 아니며, 1차 자료의 번역이나 요약도 아닙니다.

시리즈— 본 기사는 AI로 풀어보는 AI-DLC v2 시리즈의 일부입니다.

참조한 버전— Claude Code 구현을 대상으로, 2026년 6월 시점의 v2.1.3 (커밋 c95070e, core/)을 참조하고 있습니다. Kiro・Codex 구현은 대상에서 제외되어 기술 내용이 다를 수 있습니다. OSS 구현은 업데이트가 계속되고 있으므로, 최신 상태는 공식 리포지토리를 확인해 주시기 바랍니다.

AI-DLC v2의 각 스테이지는 버전 관리되는 markdown 결과물을 하나씩 생성합니다. 의도 (intent)에서 시작하여 요구사항(requirements)・스토리(story)・작업 단위(work unit)・설계(design)를 거쳐 코드로 이어집니다. 페이즈(phase)가 진행될수록 결과물의 추상도는 낮아지고 해상도는 높아집니다. 이러한 단계적인 상세화가 결과물 흐름의 골격을 형성합니다.

결과물끼리는 안정 ID를 부여하여 복사하는 방식으로는 연결되지 않습니다. 각 스테이지는 상류의 결과물을 어휘명으로 지칭하며, 실체 파일은 그것을 만든 생산자(producer)의 디렉토리에 단 한 곳에만 존재합니다. 본 기사에서는 명칭에 의한 연결・'1 결과물 = 1 생산자'라는 불변 조건・생산자 디렉토리로의 배치・작업 단위별 경로 해결(path resolution) 등, 결과물이 어떻게 만들어지고 어디에 배치되며 어떻게 이름으로 연결되는지를 풀어냅니다.

AI-DLC v2의 5개 페이즈는 각각 고유한 목적과 주요 성과 (key outcome)를 가집니다. 방법론의 원칙 파일이 이를 표로 나타내고 있습니다.

페이즈	목적	주요 성과 (원문)
초기화 (Initialization)	부트스트랩 (Bootstrap)	Configured workspace ready for workflow (워크플로우용으로 구성된 워크스페이스)
발상 (Ideation)	구상을 검증함	Approved initiative brief (승인된 구상 브리프)
구상 (Inception)	상세화함	Detailed execution plan (상세한 실행 계획)
구축 (Construction)	만듦	Working tested code (동작하는 테스트 완료된 코드)
운영 (Operation)	배포·운영함	Production system with monitoring (모니터링 기능이 포함된 운영 시스템)

「승인된 구상 → 상세한 실행 계획 → 동작하는 테스트 완료된 코드」라는 흐름이 그대로 추상도의 구배(gradient)가 됩니다. 각 스테이지가 실제로 만드는 결과물 (프론트매터(frontmatter)의 produces)을 순서대로 나열하면 이 구배가 보입니다.

의도가 요구사항이 되고, 요구사항이 스토리가 되며, 스토리가 작업 단위로 분할되고, 설계를 거쳐 코드가 됩니다. 원칙 파일이 내세우는 원칙 3이 이 핵심을 방법론 자체의 언어로 선언하고 있습니다. 각 스테이지는 버전 관리되는 markdown을 기록으로 남겨 완전한 결정 기록 (complete decision record)을 만든다고 말입니다. 각 단계는 이전 단계를 소재로 하여 만들어집니다.

스테이지의 프론트매터 (파일 도입부의 메타 정보)에는 결과물을 다루는 두 가지 필드가 있습니다. produces는 해당 스테이지가 만드는 결과물로, 단순 이름의 배열입니다 (예: ["requirements", "requirements-analysis-questions"]). consumes는 필요로 하는 상류 결과물로, {artifact, required, conditional_on?} 형태의 객체 배열입니다.

produces:
- requirements
consumes:
...

requirements-analysis는 intent-statement (발상 페이즈의 intent-capture가 만든 결과물)를 이름으로 소비합니다. required: false는 "있으면 사용하고, 없어도 중단하지 않는다"는 의미입니다. 참고로, 여기까지의 두 필드는 결과물의 의존성을 나타내지만, 이와 별개로 순서의 의존성을 나타내는 requires_stage라는 필드도 있습니다. 이 produces / consumes / requires_stage

이러한 선언이 그대로 DAG(스테이지를 점으로, 의존성을 화살표로 나타내는 순환하지 않는 지도)의 에지(edge)가 됩니다. 컴파일된 그래프는 결과물을 파일 경로가 아닌 **어휘명 (lexical name)**으로 유지하며, 생산자(producer)와 소비자(consumer)를 찾는 함수 역시 이름 기반입니다.

이 연결이 성립하기 위한 전제 조건은 하나의 결과물을 produces 하는 스테이지는 정확히 하나라는 불변 조건입니다. 소비자 측은 이 1:1 관계를 전제로, 소비한 결과물의 생산자를 유일하게 특정합니다 (producersOf(name)[0]로 확정). 실제 데이터로도 확인되었으며, 모든 스테이지의 produces를 집계하면 122개의 결과물이 있으며, 동일한 결과물을 여러 스테이지가 만드는 사례는 단 하나도 없습니다. 그래프 검사(validateScope)는 생산자가 없는 consumes를 에러로 감지하여 이 1:1 관계를 준수하도록 강제합니다. 연결의 기점은 intent-capture입니다. 이 스테이지의 consumes는 빈 배열이며, 아무것도 소비하지 않습니다. 여기서부터 하류(downstream)의 모든 결과물이 명시적인 연쇄를 통해 연결됩니다.

어휘명만으로는 파일을 여는 측의 컨덕터(Conductor, LLM)가 실체에 도달할 수 없습니다. 결정론적인 엔진이 run-stage의 지시(directive)를 구성할 때, 이름을 **실제 경로 (actual path)**로 해결(resolve)합니다. 해결 대상은 활성화된 intent의 기록 디렉토리인 aidlc/spaces/<space>/intents/<YYMMDD>-<label>/ (이하 <record>) 하위입니다. 소비되는 결과물은 그것을 소비하는 스테이지가 아니라, 그것을 만든 스테이지의 디렉토리에 거주합니다.

• 비 per-unit (작업 단위별로 나뉘지 않는) 결과물:
  <record>/<phase>/<slug>/<name>.md

• 예:
  application-design이 requirements를 소비하더라도, 경로는 자신의 하위가 아닌 <record>/inception/requirements-analysis/requirements.md (requirements-analysis 생산자의 하위)로 해결됩니다.

requirements를 소비하는 스테이지가 여러 개 있더라도, 실체 파일은 생산자 디렉토리에 단 하나만 존재합니다. 소비자 측은 모두 그 주소를 명시합니다. 복사본은 생성되지 않습니다.

AI-DLC v2에는 "결과물에 안정적인 ID를 부여하고, 페이즈(phase)마다 복사(copy-forward)하여 이력을 남기는" 식의 메커니즘은 없습니다. core/와 CHANGELOG.md를 copy-forward, stable id, provenance로 검색해도 해당 구현은 나오지 않습니다. 연결의 실체는 복사가 아니라, 한 곳에 거주하며 어휘명으로 참조된다는 물리적 배치와 명시적 참조의 조합 그 자체입니다.

구축(construction) 페이즈의 일부 스테이지는 작업 단위(Unit of Work)마다 한 번씩 실행됩니다. per-unit 여부를 판단하는 근거는 노드의 프론트매터(frontmatter)에 있는 **for_each: unit-of-work**입니다. 해당되는 것은 5개 스테이지(nfr-requirements / nfr-design / functional-design / infrastructure-design / code-generation)입니다. 이 결과물들은 construction/<unit>/을 사이에 둔 경로로 해결됩니다.

<record>/construction/<unit>/<slug>/<name>.md

<unit>이라는 세그먼트는 구조화된 produces / consumes에는 전혀 나타나지 않습니다. 프론트매터의 배열은 어디까지나 있는 그대로의 이름이며, 작업 단위 세그먼트는 엔진이 경로를 구성하는 순간에 삽입됩니다.

엔진은 이 삽입 과정을 작업 단위마다 반복하며 수행합니다. 컴파일된 작업 단위 DAG가 있다면, 엔진은 질의가 있을 때마다 아직 결과물이 모두 갖춰지지 않은 첫 번째 작업 단위를 선택하고, 그 실제 이름을 produces / consumes / memory 경로에 삽입한 run-stage를 하나 발행합니다 (해결된 이름은 directive.unit...

에도 기재됩니다). 「어디까지 완료되었는가」에 대한 장부는 상태의 추가 필드가 아니라, 디스크 상의 결과물 존재 여부로 판정되기 때문에 엔진은 읽기 전용 (read-only) 상태를 유지합니다. 리터럴 플레이스홀더 {unit-name}

이 발행되는 것은, 작업 단위 DAG가 없는 스코프나 컴파일 전 등의 폴백 (fallback) 경우에만으로 격하되었습니다.

per-unit 여부는 소비하는 스테이지가 아니라 소유자 (생산자)의 속성에 의해 결정됩니다. functional-design (per-unit)이 units-generation (non per-unit)이 만든 unit-of-work를 소비할 때는, 소유자가 per-unit이 아니기 때문에 접두사가 붙지 않고 <record>/inception/units-generation/unit-of-work.md로 해결됩니다. 주소는 언제나 소유자가 결정하므로, 작업 단위를 가로질러도 연결은 깨지지 않습니다.

또한, 각 스테이지의 .md가 가진 outputs: 프론트매터 (frontmatter)는 런타임에서는 비 로드 베어링 (non load-bearing) (실행 시에는 참조되지 않음 = 경로 계약이 아닌 설명용)입니다. 엔진은 outputs:를 읽지 않고, produces[]의 이름을 기록 디렉토리로 해결합니다. outputs:는 경로 계약이 아니라 문서라고 core 스스로가 명시하고 있습니다. 해설 docs에 남아 있는 구 aidlc-docs/... 형식의 배치 설명과 상충하는 경우에는 구현을 정답으로 간주하십시오.

작업 단위마다 run-stage를 발행하는 동안, 스테이지의 승인 게이트 (approval gate)는 모든 작업 단위가 갖춰질 때까지 억제됩니다. 마지막 작업 단위의 결과물이 모두 나온 재진입 (re-entry) 시에 처음으로 스테이지 단일 승인 게이트가 한 번 제시됩니다. 조기 승인 거부를 포함한 이 동작은 별도 기사 「승인 게이트」에서 다룹니다.

「소비되는 결과물은 생산자의 디렉토리에 거주한다」라는 규약에는 단 하나의 예외가 있습니다. 리버스 엔지니어링이 만드는 9가지 결과물만은 기록 디렉토리가 아니라 공간 레벨의 codekb aidlc/spaces/<space>/codekb/<repo>/에 거주합니다. 기록 디렉토리는 하나의 intent에 종속되는 반면, codekb는 intent를 가로질러 영속하는 코드베이스 지식 베이스이기 때문입니다. 기존 코드를 밑바탕으로 사용할 때만 소비되는 조건부 연결 (conditional_on: brownfield)을 포함하여, 브라운필드 (brownfield) 고유의 결과물 군은 별도 기사 「브라운필드」에서 다룹니다.

지금까지 구성한 연속체 (명시적 연결과 생산자 디렉토리로의 배치)는 페이즈 (phase)의 경계에서 「사슬」로서 검증됩니다. 의도 → 요구사항 → 스토리 → 설계 → 코드 → 테스트가 끊김 없이 연결되어 있는가. 다만, 그 검증 자체는 별도 기사 「페이즈 경계 검증」에서 다룹니다. 본 기사가 집중한 것은 사슬의 소재, 즉 결과물이 어떻게 만들어지고, 어디에 놓이며, 어떻게 참조되는가였습니다. 소재가 올바르게 연결되어 있기 때문에 경계에서 사슬로서 검증할 수 있습니다.

이름에서 경로로의 해결은 모두 결정론적인 엔진의 작업이며, 컨덕터 (LLM)에게 재도출시키지 않습니다. aidlc-orchestrate.ts의 주석에 따르면, 경로의 조립은 교과서적인 도구의 작업이며, 그것을 LLM에게 넘기는 것은 설계의 취지 그 자체를 반전시키는 것이라고 합니다. 본 기사가 다룬 것은 그 해결의 결과 = 무엇이 어디에 거주하는가에 대한 규약이며, 해결 기제 그 자체 (질의·지시·보고)는 별도 기사 「진행의 핵심」에서 다룹니다. 연결을 유지하는 역할은 저장할 때마다 발생하며, 상류 결과물이 본문에서 실제로 참조되고 있는지를 조언으로서 포착하는 메커니즘은 별도 기사 「센서」에서, 결과물의 생성·갱신 기록은 별도 기사 「상태와 감사」에서 다룹니다.

파일	내용
core/knowledge/aidlc-shared/ai-dlc-principles.md
5단계의 목표와 주요 성과. 원칙 3 「Traceable artifacts (추적 가능한 결과물)」
core/tools/aidlc-orchestrate.ts
결과물 경로(artifact path) 해결. resolveArtifactPath (주소 = 소유자의 하위) · resolveConsumePath (생산자는 1:1로 [0] 확정) · isPerUnit ／ {unit-name} 삽입 · buildRunStageDirective (발행 시 이름 → 경로)
core/tools/aidlc-graph.ts
그래프는 결과물을 어휘명(vocabulary name)으로 보유. producersOf ／ consumersOf (이름으로 조회) · validateScope (생산자가 없는 consumes를 에러 처리하여 1:1 관계를 준수하도록 강제)
core/aidlc-common/stages/inception/requirements-analysis.md
produces ／ consumes (conditional_on: brownfield 포함)의 실례
core/aidlc-common/stages/ideation/intent-capture.md
사슬의 기점. consumes: [] (아무것도 소비하지 않음)
core/aidlc-common/stages/construction/functional-design.md
per-unit 스테이지 (for_each: unit-of-work)의 실례
core/aidlc-common/stages/construction/code-generation.md
per-unit의 종단. outputs:가 기록 디렉토리 상대 경로이며 engine-resolved(엔진에 의해 해결됨)임을 명시
core/sensors/aidlc-upstream-coverage.md
consumes:의 상류 결과물이 출력 본문에서 참조되고 있는지를 저장(save)마다 검사
CHANGELOG.md
어휘명 → 기록 디렉토리 해결, 생산자가 주소를 갖는 규약, per-unit for_each의 엔진 구동 (2.1.2), codekb 배치 도입 경위

이전 기사: 깊이

다음 기사: 워킹 스켈레톤 (Walking Skeleton)

목차: AI로 풀어보는 AI-DLC v2