AI-DLC Workflows v2 (awslabs/aidlc-workflows)는 AWS Labs가 공개한, AI 코딩 에이전트를 위한 개발 워크플로우 규칙 세트입니다. 공식 정의는 다음과 같습니다.

AI-DLC (AI-Driven Development Life Cycle) is a methodology for structuring AI-assisted software development into repeatable, traceable phases.

(AI-DLC는 AI 지원 소프트웨어 개발을 반복 가능하고 추적 가능한 단계로 구조화하기 위한 방법론입니다)

'5단계 32스테이지 14에이전트 9스코프'라는 숫자가 먼저 눈에 들어오지만, 이 글에서는 그 숫자의 내역보다는 왜 이런 형태가 되었는지를 다룹니다.

설계 사상을 먼저 파악해 두면, 개별 사양이 '그런 이유로 이렇게 되어 있구나' 하고 연결되어 읽을 수 있게 됩니다. 직접 코딩하기 전에 전체적인 그림을 잡고 싶은 분들께 적합합니다.

이 글에서 다룰 내용

• 무엇을 해결하려 하는가 (파편화와 하네스 중립)
• 'Small Mob, Broad Agents' — 왜 세부 전문가를 배치하지 않는가 -
• 2계층 구조의 오케스트레이션 — 순서를 결정하는 것은 AI가 아니다 - 실행했을 때 실제로 화면에 무엇이 나타나는가
• 결과물이 어디에 남는가 (space와 intent)
• 독립적인 3가지 축 (스코프, 깊이, 테스트 전략)

출발점은 AI 지원 개발의 파편화입니다.

에이전트에게 개발을 맡길 때, 도구마다 설정 파일의 위치나 작성 방식이 다릅니다. Claude Code라면 CLAUDE.md,
Cursor라면 .cursor/rules/,
Kiro라면 .kiro/steering/와 같습니다. 같은 '우리만의 방식'을 도구를 바꿀 때마다 다시 작성해야 합니다.

AI-DLC Workflows는 이를 **하네스 중립(harness-neutral)**인 하나의 코어에서 해결하려고 시도합니다. 방법론과 규칙을 한곳에 두고, 각 도구에 맞게 배포하는 방식입니다.

지원하는 도구로는 Claude Code, Kiro CLI, Kiro IDE, Codex CLI, opencode 등이 있습니다. 문서에는 '기존의 CLI 도구 내부에서 하나의 코어로부터 네이티브하게 구동된다'고 쓰여 있습니다.

또 한 번 강조되는 것은 사람이 판단을 가진다는 점입니다. 환영 배너 문구가 그대로 설계 방침이 되었습니다.

AI-DLC is an adaptive methodology that structures AI-assisted software development into repeatable, traceable phases while keeping you in control at every decision point. (AI-DLC는 AI 지원 소프트웨어 개발을 반복 가능하고 추적 가능한 단계로 구조화하는 적응적인 방법론이며, 모든 의사결정 지점에서 당신이 주도권을 유지하게 합니다)

'자율 실행'을 내세우는 프레임워크가 같은 문장의 후반부에서 '당신이 주도권을 가진다'고 말하고 있습니다. 이 양립시키는 방식이 이후의 설계에 나타납니다.

v2에서 가장 흥미로웠던 부분은 에이전트 배치(配役)에 대한 생각입니다. 문서에서는 **'Small Mob, Broad Agents (작은 모브, 넓은 에이전트)'**라는 단어로 설명합니다.

일반적으로 생각하면 32스테이지가 있다면 스테이지마다 전문 에이전트를 두고 싶을 것입니다. 하지만 이 프레임워크는 그렇지 않습니다.

Rather than recreating waterfall handoff chains with dozens of narrow specialists, the approach employs eleven broadly capable agents that participate across multiple stages, each carrying context forward to eliminate handoffs.

(수십 명의 좁은 전문가로 폭포수식 인계 체인을 재현하는 대신, 여러 스테이지에 걸쳐 참여하며 각각 컨텍스트를 전달하여 인계를 제거하는 11명의 광범위한 능력을 가진 에이전트를 활용합니다)

그 이유는 명확합니다. 문서에는 '에이전트가 적으면 인계(handover)가 적다. 에이전트의 경계는 정보가 손실될 수 있는 지점이다'라고 쓰여 있습니다.

그리고 이 사고방식의 근간은 인간 팀입니다.

a mob of 3-5 people covers an entire feature, each bringing broad skills rather than a single narrow specialty

(3~5명의 모브가 하나의 기능 전체를 커버하며, 각각이 단일한 좁은 전문성보다는 넓은 스킬을 가져옴)

모브 프로그래밍의 발상을 그대로 에이전트 배치에 담아냈습니다.

실제 배치를 보면 이 사상이 숫자로 나타납니다. aidlc-architect-agent는 9개 스테이지에 관여하며(최다), aidlc-developer-agent는 3개의 페이즈에 걸쳐 있습니다. 한 사람이 넓게 가진 설계입니다.

반면, aidlc-compliance-agent와 aidlc-devsecops-agent는 '지원만(support only)'으로 Lead를 가지지 않습니다. 교차적으로 체크하는 역할이기 때문에 주도하기보다는 옆에서 돕는 형태입니다.

배치의 전체적인 모습은 이렇습니다.

(각 14개의 명칭과 담당 영역은 상세 편에 정리했습니다.)

또 하나, 설계로 주목해야 할 것은 오케스트레이션의 구조입니다. 여기는 오해하기 쉬운 부분이라고 생각합니다.

document 설명에서는 결정론적인 엔진이 다음 단계를 결정하고, conductor(/aidlc 세션)가 그것을 실행하여 다음 것을 요청하는 왕복 과정이 있습니다.

여기서 중요한 점은, 어떤 스테이지를 다음에 실행할지 결정하는 것은 LLM이 아닙니다. 엔진 쪽입니다. 엔진이 상태를 관리하며 5페이즈 32스테이지의 정의를 읽고, 에이전트의 페르소나를 로드하며, 각 스테이지에서 승인 게이트를 제시합니다.

LLM이 담당하는 것은 전달된 스테이지의 내용을 실행하는 부분입니다. 순서 결정과 실행이 분리되어 있습니다.

이러한 분리가 있기 때문에 '같은 입력이라면 같은 순서로 작동한다'는 것이 보장됩니다. 역으로 말하면, LLM에게 자유로운 진행을 맡기지 않도록 의도적으로 설계한 것입니다.

스테이지의 실행 방식 또한 한 가지가 아니며, 4가지 종류가 있습니다.

설계 이야기가 이어졌으니, 실제 화면을 보겠습니다. 아래는 공식 문서에 게재된 출력 예시입니다.

먼저 실행합니다.

/aidlc Build a REST API for inventory management

Initialization의 3개 스테이지(작업 공간 생성, 프로젝트 감지, 상태 초기화)가 자동으로 진행된 후, 가장 먼저 나오는 것이 이것입니다.

─── Scope Detection ───────────────────────────────────────────
Detected scope: feature (Standard depth, Standard test strategy)
▸ Approve scope? [Yes / Change scope / Change depth / Change test strategy]
...

스코프, 깊이, 테스트 전략의 세 가지가 나란히 표시됩니다. 그리고 각각 개별적으로 변경할 수 있습니다. 여기가 '3개의 독립적인 축'이라는 설계가 처음으로 모습을 드러내는 장면입니다.

자연어 문장의 'Build a REST API...'에서는 특정 키워드를 잡아낼 수 없었기 때문에, 기본값인 feature가 선택되었습니다.

진행 중에는 다음과 같은 표시가 나옵니다.

[AIDLC] IDEATION > Intent Capture [▓▓▓▓▓░░░░░] 4/7 -- product

읽는 법은, 페이즈(IDEATION) > 스테이지(Intent Capture), 진행률 바, 4/7입니다.

(해당 페이즈의 몇 번째인지), 그리고 마지막의 product가 현재 작동하고 있는 에이전트입니다.

32개의 스테이지 중 어디에 있고, 누가 담당하고 있는지 한 줄로 알 수 있게 되었습니다.

스테이지가 시작되면, 대화 모드를 묻습니다.

▸ Choose interaction mode:
(1) Guide Me — agent asks structured questions
(2) Edit File — write directly to the artifact
...

세 가지 모두 최종적으로 같은 질문 파일에 수렴하기 때문에, 도중에 전환해도 답변이 손실되지 않습니다.

스테이지가 끝나면, 무엇을 할 수 있었는지 표와 선택지가 나옵니다.

# Intent Capture & Framing Complete
| Artifact | Contents |
|----------|----------|
...

승인하면 진행 상황이 표시됩니다.

Progress: 4/32 overall | 1/7 IDEATION stages complete. Next: Market Research

4/32가 된 것은, Initialization의 3개 스테이지 + 현재 스테이지로 네 번째라는 계산 방식입니다.

이 일련의 흐름이 32개의 스테이지 사이에서 반복됩니다(조건부 스테이지는 스코프에 따라 자동으로 건너뜁니다).

아까 스코프 확인 화면에 3개가 나란히 있던 것이 v2의 조정 메커니즘입니다. 각각 독립적으로 지정할 수 있습니다.

스코프가 기본 깊이를 주고, 깊이가 기본 테스트 전략을 주지만, 각각 덮어쓸 수 있습니다.

/aidlc --scope bugfix --depth standard
/aidlc --depth standard --test-strategy minimal

분리된 실용적인 의미는 공식에서 workshop 스코프로 보여주고 있습니다. 깊이는 Standard, 테스트는 Minimal라는 조합으로 이유가 첨부되어 있습니다.

Full artifacts for learning, but fast Nyquist testing to keep pace

(학습을 위해 산출물은 완벽하게 갖추지만, 페이스를 유지하기 위해 테스트는 빠른 Nyquist로)

교육에서는 산출물을 학습 자료로 갖추고 싶지만, 테스트를 대량으로 작성하게 하면 시간이 부족합니다. 두 축이 분리되어 있지 않으면 이 조합을 표현할 수 없습니다.

그리고 이 3개의 축이 있기 때문에 README에 쓰인 다음 내용이 성립됩니다.

The same engine runs a throwaway proof-of-concept and a regulated enterprise rollout — it just runs more of the stages, in more depth.

(같은 엔진이, 일회용 개념 증명과 규제 대상의 엔터프라이즈 배포를 모두 실행한다. 단지, 더 많은 스테이지를, 더 깊게 실행할 뿐이다)

32개라는 숫자는 '모두 하라'는 요구가 아니라, 선택지의 총 개수라는 의미입니다.

또 하나, 전체적인 그림으로 파악하고 싶은 것이 기록의 구조입니다. 두 가지 개념이 있습니다.

디렉토리 구조는 다음과 같습니다.

my-project/
├── .claude/ ← 하네스 엔진 (다른 것은 .kiro/ 나 .codex/)
├── aidlc/ ← AI-DLC의 모든 출력물
...

대부분의 사람들은 자동으로 생성되는 default space 하나만 사용하며, space 관리에 신경 쓸 필요가 없다고 문서에 적혀 있습니다. 여러 팀이 방법론을 나누고 싶을 때만 늘릴 수 있도록 설계되었습니다.

반면 intent는 일상적으로 증가합니다. 작업 중에 관련 없는 다른 작업을 시작하려고 하면, AI-DLC가 이를 '새롭고 무관한 작업'으로 인식하여 두 번째 intent를 나란히 시작할 것을 제안해 줍니다. 전환은 /aidlc intent <slug>

로 이루어지며, 각각 독립적으로 상태를 유지합니다.

intent의 디렉토리는 <YYMMDD>-<label> 형식입니다. 여기에 작은 설계가 들어 있었습니다.

the

<YYMMDD>
is a compact UTC date so records sort chronologically; the<label>
is a short, human-readable name.Identity itself is carried by a UUIDv7 in the registry, not the dir name (

( <YYMMDD>는 UTC의 축약 날짜로 기록이 시간 순서대로 정렬되도록 하기 위함입니다. <label>은 짧고 사람이 읽을 수 있는 이름입니다. 동일성 자체는 디렉토리 이름이 아니라 레지스트리의 UUIDv7가 담당합니다.)

디렉토리 이름은 '사람이 읽기 위해서' 할당하고, 기계적인 동일성은 별도로 UUIDv7로 가집니다. 따라서 같은 날에 같은 라벨의 작업이 두 개 있어도 충돌하지 않습니다.

이는 실무에서 효과적이라고 생각했습니다.

팀이 공유하는 자산(규칙/자료/기록)은 커밋되고, '지금 자신이 어디를 보고 있는지'라는 개인의 상태는 공유되지 않습니다. 모두가 같은 리포지토리에서 각기 다른 intent를 진행할 수 있도록 되어 있습니다.

감사 기록이 클론마다 별도의 파일 (<host>-<clone>.md )로 되어 있는 것도 같은 발상으로, 여러 사람이 동시에 작업해도 git의 충돌(conflict)이 일어나지 않습니다.

간단하게 정리하겠습니다. v1은 main 브랜치, v2는 v2 브랜치로서 공존하고 있습니다.

늘어난 부분을 설계 사상 측면에서 보면, 앞뒤로 확장되었다는 점이 특징입니다. 앞단에는 "애초에 해야 하는가" (Ideation)가, 뒷단에는 "계속해서 작동시킨다" (Operation)가 추가되었습니다. 개발 공정뿐만 아니라 그 전후 단계까지 책임지는 방향으로 확장되었습니다.

설계 사상 측면에서 보면, v2는 세 가지 판단으로 이루어져 있다고 생각했습니다.

① 에이전트는 적게, 넓게 가져간다. 32개의 스테이지가 있다고 해서 32명의 전문가를 배치하지 않습니다. 인수인계의 경계가 곧 정보 손실 지점이 되기 때문입니다. 인간의 몹 프로그래밍 (Mob Programming, 3~5명이 하나의 기능을 커버하는 방식)을 투영한 형태입니다.

② 순서를 결정하는 것은 AI가 아니다. 결정론적인 엔진이 다음 스테이지를 결정하고, LLM은 그 내용을 실행합니다. 이러한 분리가 있기 때문에 "동일한 입력이라면 동일한 순서"가 유지됩니다. 자율성을 높이기 위해, 진행 결정권은 오히려 기계 측에 고정해 두었습니다.

③ 조정은 세 가지 독립된 축으로 수행한다. 어떤 스테이지를 (Scope), 어디까지 자세하게 (Depth), 얼마나 테스트할 것인가 (Test Strategy). 이 세 축이 분리되어 있기 때문에, 동일한 엔진으로 일회성 프로토타입부터 규제 대응까지 다룰 수 있습니다.

32개 스테이지라는 숫자를 처음 보면 "무겁다"고 느껴질 수 있지만, 그것은 선택지의 총수입니다. 실제로 실행되는 것은 버그 수정의 경우 7개뿐입니다. **"망라적으로 준비해 둔 상태에서, 이번에 필요한 만큼만 선택한다"**는 구성 방식으로 이해하면 인상이 상당히 달라집니다.

한편, 이 정도 규모의 규칙 세트를 도입할 가치가 있는지는 프로젝트에 따라 다르다고 생각합니다. 승인 게이트(Approval Gate)와 감사 기록(Audit Log)이 그대로 요구사항이 되는 현장에서는 효과적이지만, 소수 인원이 빠르게 회전시키는 경우에는 게이트의 수가 곧 번거로움이 됩니다. 판단하기 위해서는 일단 한 번 돌려보는 것이 가장 빠르므로, 우선 bugfix의 7개 스테이지를 한 바퀴 돌려보는 것을 추천합니다.

공식 (v2 브랜치)

• awslabs/aidlc-workflows (v2 브랜치) — 본체. MIT-0, 집필 시점의 배지(Badge)는 2.5.53
• docs/guide/00-introduction.md — 공식 정의, Small Mob / Broad Agents, 오케스트레이션 루프 (Orchestration Loop), 하네스 중립 (Harness Neutral)
• docs/guide/02-your-first-workflow.md — 최초 실행의 화면 출력 (본 기사에서 인용한 4가지 예시)
• docs/guide/03-spaces-and-intents.md — space와 intent의 정의, 디렉토리 구조, git 관리의 경계
• docs/guide/05-scopes-and-depth.md — 9 스코프, 깊이, 테스트 전략
• docs/guide/06-agents.md — 14 에이전트의 배역

v1 (main 브랜치)

• awslabs/aidlc-workflows (main = v1) — 3 페이즈 구성