본 기사의 위치— 본 기사는 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를 자신의 팀과 프로젝트에 도입해야 할까. 이 질문에 대해 1차 자료(core/)는 직접적인 답을 가지고 있지 않습니다. core에서 확인할 수 있는 것은 "무엇을·어디까지·어떤 전제하에 할 수 있는가"라는 능력과 제약까지이며, 그 너머의 "그래서 누구에게 적합한가"는 독자가 이끌어내야 할 추론입니다. 다만 한 가지, 상정된 용도를 공식이 한 단어로 명시한 1차 자료가 있습니다. 9종류의 스코프(Scope) 각각의 description입니다.

본 기사에서는 이 스코프의 상정 용도를 축으로 삼아, 도입을 통해 감수해야 할 것과 맞바꿔 얻는 것을 나열하여, 어떤 팀과 프로젝트에 솔직하게 적합한지를 풀어냅니다.

도입 판단은 리드(Lead)/아키텍트(Architect)/EM이 "이 프로젝트에 AI-DLC v2를 적용할 것인가"를 결정하는 장면입니다. 그런데 1차 자료를 읽어도 "도입해야 한다/하지 말아야 한다"라고 언급한 부분은 보이지 않습니다. core가 보여주는 것은 메커니즘의 능력과 제약까지입니다.

따라서 본 기사는 사실이 나타내는 능력과 제약을 판단의 재료로 치환하는 역할에 충실합니다. 메커니즘 자체는 설명하지 않으며, 각론은 심층 분석 기사로 넘깁니다. 다른 방식과의 우열도 논하지 않습니다. 다루는 것은 core가 실제로 지원하는 범위에서 본 프로젝트·팀과의 상성뿐입니다.

다행히 판단의 실마리가 될 1차 자료가 하나 있습니다. 스코프 정의의 description입니다. 이를 첫 번째 판단 축으로 삼습니다.

가장 먼저 작용하는 것은 "이번에는 어떤 종류의 프로젝트인가"입니다. AI-DLC v2는 프로젝트의 종류를 9가지 스코프로 나타내며, 각 스코프의 파일은 프론트매터(Frontmatter)의 description에 "무엇을 위한 것인가"를 한 단어로 적고 있습니다. 이는 추론이 아니라 공식이 배치한 1차적인 표명입니다.

이 description을 실마리로 치환한 것이 다음 표입니다. EXECUTE 열은 해당 스코프가 전체 32개 스테이지 중 실제로 몇 개를 실행하는지를 나타냅니다.

스코프	description (원문)	EXECUTE	적합한 프로젝트
enterprise	Regulated enterprise feature, full audit trail	32 / 32	규제·감사 추적(Audit trail)이 필요한 운영 환경 기능
feature	Default for new features, practical depth	32 / 32	신규 기능 전반. 고민된다면 여기 (기본값)
workshop	Facilitated group session with mandatory gates	25 / 32	연수·핸즈온·집체 연습
mvp	Skip operations, ship the core	22 / 32	운영을 뒤로 미루고 핵심을 최단 기간에 내놓는 프로젝트
infra	Infrastructure changes	13 / 32	인프라 변경
security-patch	CVE response	9 / 32	취약성에 긴급 대응하는 프로젝트
poc	Prove feasibility fast	8 / 32	실현 가능성을 빠르게 확인하는 검증
refactor	Clean up existing code	8 / 32	동작을 바꾸지 않는 정리
bugfix	Fix a specific bug	7 / 32	특정 버그 수정

읽는 방법은 두 가지입니다. description은 공식이 상정하는 프로젝트 상을 그대로 맞히고 있으므로, 현재 프로젝트가 어느 것에 가까운지에 따라 첫 번째 가늠을 할 수 있습니다. EXECUTE 수는 통과하는 공정의 무게이며, 똑같이 "도입한다"라고 해도 enterprise의 32개 공정과 bugfix

의 7개 공정에서는 맡게 되는 수고가 전혀 다릅니다. 안건 유형을 선택하는 것은 통과하는 공정 수를 선택하는 것이기도 합니다.

스코프 (scope)를 선택하는 메커니즘 자체(자동 추정 · --scope

· 깊이 기본값)는 별도 기사 「스코프」에서, 각 공정을 어디까지 정교하게 만드는지에 대한 깊이는 별도 기사 「깊이」에서 다룹니다.

도입하면 무엇을 짊어지게 되는가. core에서 읽어낼 수 있는 부담은 다음과 같습니다.

초기화 3개 공정을 제외한 전 29개 스테이지에 승인 게이트 (approval gate)가 있으며, 사람이 "승인"이라고 말할 때까지 워크플로 (workflow)는 진행되지 않습니다. 게다가 이 승인 권한은 승계되지 않습니다. 어떤 스테이지에서 "추천대로 진행해"라고 답하더라도, 그것은 해당 스테이지에 한정되며 다음 스테이지로 이어지지 않습니다. 자율적으로 실행하려면 대상 스테이지마다 사람이 명시적으로 허가해야 합니다.

방치(放置)에 가장 가까워질 수 있는 유일한 곳은 구축 페이즈의 Bolt (구축의 실행 단위) 루프입니다. 첫 번째 Bolt는 설정과 관계없이 항상 게이트가 있으며, 그 직후의 질문에서 "자율 (autonomous)"인지 "Bolt마다 승인 (gated)"인지를 단 한 번 선택합니다. autonomous를 선택하더라도 코드 생성에 실패했을 때는 반드시 멈춰서 사람에게 확인을 요청합니다. 도입하는 팀은 각 공정에서 결과물을 확인하고 승인하는 운영을 맡게 됩니다. 승인 반려나 "현 상태로 승인" 메커니즘은 별도 기사 「승인 게이트」에서, 첫 번째 Bolt가 항상 멈추는 이유는 별도 기사 「워킹 스켈레톤 (walking skeleton)」에서 다룹니다.

AI-DLC v2의 기계 검증 (4종의 센서)은 모두 조언 (advisory) 형태로 출하됩니다. 결과물을 독립적으로 평가하는 리뷰어 (reviewer) 역시 마찬가지로 조언에 그치며, NOT-READY를 반환하더라도 워크플로는 멈추지 않습니다. 멈출 수 있는 것은 승인 게이트의 사람뿐입니다. 즉, "도구가 품질을 보증한다"라고 읽을 수는 없습니다. 센서도 리뷰어도 구멍을 가시화하여 사람을 돕는 두 번째 눈일 뿐이며, 품질의 최종 책임은 사람에게 남습니다. 도입하더라도 리뷰 공수는 그대로 필요합니다. 리뷰어의 왕복 판정은 별도 기사 「리뷰어」에서, 저장할 때마다 실행되는 센서는 별도 기사 「센서」에서 다룹니다.

워크플로 진행을 기록하는 상태 파일에 대해, 그 형식의 이관 도구는 제공하지 않는다는 방침이 core 자체에 명시되어 있습니다. 오래된 형식을 감지하면 진단 커맨드는 "워크스페이스를 아카이브하고 다시 시작하라"고 권고합니다. 코드 내의 주석은 이를 "1.0 이전에는 이관을 제공하지 않는 방침 (pre-1.0 no-migration policy)"이라고 명시합니다. 선언된 결과물이 디스크에 없으면 완료를 거부하는 아티팩트 가드 (artifact guard)가 있어, 자동화 스크립트가 중단될 수 있는 파괴적 변경 (breaking change)입니다.

게다가 실용을 위해서는 능력이 높은 모델이 전제되어야 합니다. core 측에서 확인할 수 있는 것은 13개의 에이전트 중 8개에 modelOverride: opus가 붙는 정도까지이지만, 약한 모델은 리뷰나 학습 절차를 생략하는 경향이 있습니다. 도입은 "한 번 넣고 고정"하는 것이 아니라, 파괴적 변경을 추종하고 진행 중인 워크플로를 다시 만들어낼 각오를 포함합니다. 성숙도의 한계는 별도 기사 「한계와 주의점」에서 다룹니다.

짊어지는 것의 반대 급부가 얻는 것입니다. AI-DLC v2가 설계의 근간에 두는 것은 사람의 주권 (중요한 결정은 모두 승인 게이트를 통함), 예측 가능성 (다음에 할 일은 결정론적인 엔진이 결정하며, LLM에게 맡기지 않음), 학습의 축적 (사람의 수정을 영구적인 규칙으로 만들어 다음 워크플로부터 적용함)입니다.

얻는 것	무엇이 좋은가
주권	AI의 속도를 활용하면서도 의사 결정은 사람이 계속 쥐고 있을 수 있음
...
이것들이 효과를 발휘하는 곳은 "AI가 빠르게 작성하기를 원하지만, 사람이 뒤처지는 것은 곤란한" 팀입니다. 반대로 작은 일회용 스크립트를 최속으로 뽑아내고 싶을 뿐이라면, 29개의 게이트가 있는 주권 설계는 그만큼 무거워집니다 (그 용도로는 poc나 bugfix의 좁은 길이 마련되어 있습니다). 왜 이 세 가지를 근간에 두는지에 대해서는 별도 기사 「설계 사상」에서 다룹니다.

여기까지를 한 장으로 요약하면, 도입 판단은 "안건 유형 → 통과하는 공정의 무게 → 짊어지는 것"의 대응 관계로 읽을 수 있습니다.

그에 더해, 도입하기 전에 자문해야 할 것들이 있습니다.

• 매 스테이지의 승인 수고를 감당할 수 있는가. 감당할 수 없다면 방치 자동화를 기대한 도입은 맞지 않습니다.
• 사람의 리뷰 공수를 남겨둘 수 있는가. 센서도 리뷰어도 조언에 그치며, 품질의 최종 책임은 사람에게 남습니다.
• 움직이는 표적을 추종할 수 있는가. 파괴적 변경과 재구축을 허용할 수 있는 실험적·파일럿적인 구조인가.

세 가지에 "예"라고 답할 수 있는 팀의 description에 맞는 안건. 그곳이 AI-DLC v2의 솔직한 도입처입니다.

도입 판단은 core의 사실을 세 단계로 재해석하는 작업입니다. 안건 타입(Scope의 description)으로 방향을 가늠하고, 통과하는 공정 수로 무게를 측정하며, 승인·리뷰·성숙도라는 '떠맡는 것'과 주권·예측 가능성·학습이라는 '얻는 것'을 저울질합니다. 1차 자료에 "도입해야 한다"라는 단어는 없지만, 판단 축의 재료는 모두 core 안에 있습니다. 전체적인 모습은 별도 기사 「개념 맵 (Concept Map)」에서 다룹니다.

파일	내용
core/scopes/ (9개 파일)	9가지 Scope의 정의. 각 프론트매터 (Frontmatter) description (상정 용도의 1차 표명)과 EXECUTE/SKIP에 관한 산문. 판단 축 테이블의 원천
core/aidlc-common/stages/ (32개 파일)	총 32개 스테이지 (Stage). 각 프론트매터 scopes:의 집계가 EXECUTE 실수 (32/32/25/22/13/9/8/8/7)의 원천
knowledge/aidlc-shared/ai-dlc-principles.md	"Not every task requires all 32 stages…" 문구와 주권·예측 가능성·학습의 3원칙
aidlc-common/protocols/stage-protocol.md	초기화 3공정을 제외한 모든 스테이지의 승인 게이트 (Approval Gate), 자율은 추론하지 않는다 (준수 체크리스트 항목 7), autonomous/gated, 워킹 스켈레톤 (Walking Skeleton)과 래더 프롬프트 (Ladder Prompt), 실패 시의 halt-and-ask
core/sensors/	4종의 센서(Sensor) 모두 조언 (advisory·중단하지 않음)
core/agents/ (13개 파일)	13종의 에이전트 (Agent) 중 8종에 modelOverride: opus 적용
tools/aidlc-version.ts	AIDLC_VERSION = "2.1.3"
tools/aidlc-utility.ts	구버전 검출 시 archive-and-reinit 권고 및 "pre-1.0 no-migration policy"
tools/aidlc-lib.ts	3종의 배포 하네스 (Harness) (Claude Code·Kiro CLI·Codex CLI)
CHANGELOG.md	(core에서는 확인 불가능한 보충 정보) 2.1.3의 아티팩트 가드 (Artifact Guard, 파괴적 변경), 높은 능력을 가진 모델을 전제로 함

이전 기사: 한계와 주의점

다음 기사: 병렬 실행

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