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

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

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

개요

스코프 (scope)는 워크플로에서 어떤 스테이지를 실행하고, 어떤 것을 스킵할지 결정하는 선택입니다. AI-DLC v2의 공정은 총 32개의 스테이지가 있지만, 안건에 따라 필요한 공정은 다릅니다. 버그 수정에 시장 조사는 필요하지 않고, PoC (개념 실증)에 운영 설계도 필요하지 않습니다. 스코프는 "이번에는 어떤 작업인가"를 한 단어로 선언하고, 그에 따라 공정을 좁힙니다. poc부터 enterprise까지 9종이 준비되어 있으며, 모두 코드가 아닌 파일로 정의됩니다.

스코프는 공정의 압축과 깊이의 기본값을 결정하는 기점입니다. 본 기사에서는 9종의 카탈로그, 각 스코프가 실행/스킵하는 스테이지, 자유 문구로부터의 자동 추정, 그리고 코드 변경 없이 늘릴 수 있는 파일 정의라는 메커니즘을 읽어냅니다.

스코프란

AI-DLC v2의 공정은 총 32개의 스테이지가 있지만, 매번 그 전부를 거치는 것은 아닙니다. 스코프는 "이번 작업은 어떤 종류인가"를 한 단어로 선언하고, 그에 따라 공정을 좁히는 축입니다.

AI-DLC v2에는 워크플로의 동작을 조정하는 독립된 축이 3개 있습니다. 스코프는 그 가장 바깥쪽에서 "어디를 실행할 것인가"를 담당합니다.

축	결정하는 것
스코프	어떤 스테이지를 실행할 것인가 (+깊이의 기본값)
...

깊이와 테스트 전략의 단계 그 자체는 별도 기사 「깊이」에서 다룹니다. 각 스테이지가 무엇을 하는지는 별도 기사 「공정과 에이전트」에서 다룹니다. 스코프의 전체상에서의 위치는 별도 기사 「개념 맵」에서 다룹니다. 본 기사는 그중 어느 것을 실제로 실행할 것인가에 집중합니다.

스코프가 결정하는 두 가지

스코프를 하나 선택하면 연쇄적으로 두 가지가 결정됩니다.

• EXECUTE / SKIP의 압축— 전체 스테이지 중 어떤 것을 실행하고 어떤 것을 스킵할 것인가.
• 깊이의 기본값— 실행할 스테이지를 어디까지 만들어낼 것인지에 대한 초기값. 이것은 사람이 나중에 --depth로 덮어쓸 수 있습니다.

9종의 스코프 카탈로그

스코프는 core/scopes/aidlc-<name>.md로서 9개가 정의되어 있습니다. 각 파일의 프론트매터 (파일 도입부의 메타 정보)가 해당 이름·깊이의 기본값·자동 추정에 사용하는 키워드를 가집니다.

스코프 (Scope)	깊이 기본값	키워드 (자동 추정 트리거)	용도
bugfix	Minimal	fix, bug, broken	기존 코드의 특정 버그를 수정
refactor	Minimal	refactor, clean up, simplify	동작을 바꾸지 않고 정리
poc	Minimal	proof of concept, prototype, poc, spike	실현 가능성을 빠르게 확인
security-patch	Minimal	security, CVE, vulnerability, patch	취약성에 긴급 대응하고 배포까지 완료
mvp	Standard	mvp, minimum viable	운영을 생략하고 핵심을 최단 기간에 출시
infra	Standard	infrastructure, deploy, infra	인프라 변경
feature	Standard	(없음)	신규 기능의 기본값. 실무적인 깊이
workshop	Standard (테스트는 Minimal)	workshop, lab, training	가이드가 포함된 집합 연습
enterprise	Comprehensive	(없음)	규제 대응. 모든 공정 + 완전한 감사 추적 (Audit Trail)

feature와 enterprise만이 키워드를 가지지 않습니다. enterprise는 "속도와 맞바꾸어 생략하는 것"을 하지 않는, 의도적으로 수동 선택하는 스코프이기 때문입니다. feature는 후술하듯 캐치올 (Catch-all, 누락된 항목을 받아주는 역할)로, 어떤 키워드에도 해당하지 않는 입력이 마지막에 도달하는 기본값입니다.

실행하는 스테이지와 생략하는 스테이지

스코프별로 32개 스테이지 중 몇 개를 EXECUTE(실행) 하는지, 그리고 무엇을 생략하는가·왜 생략하는가를 1차 자료의 설명문을 바탕으로 요약한 것이 다음 표입니다. 전체 32×9 매트릭스는 끝부분의 부록에 두었습니다.

스코프 (Scope)	EXECUTE	무엇을 생략하는가 / 남기는가 (이유)
enterprise	32 / 32	아무것도 건너뛰지 않음. 문서화되지 않은 판단의 비용이 스테이지를 실행하는 비용보다 높기 때문에 모든 공정을 유지
feature	32 / 32	실행 범위는 enterprise와 동일. 차이점은 깊이 (Standard)뿐임. 절차는 가볍지만 처음부터 끝까지 관통함
workshop	25 / 32	아이디어 구상 (Ideation) 7개 스테이지를 모두 SKIP. 주제는 퍼실리테이터가 사전에 결정하기 때문. 설계부터 운영까지는 그대로 보여주되, 테스트만 Minimal
mvp	22 / 32	아이디어 구상의 시장 조사·팀 구성·승인 인수인계, 그리고 운영 페이즈 전체 7개 스테이지를 SKIP. MVP는 제품을 증명하지만, 아직 운영을 책임지지는 않음
infra	13 / 32	제품 기능 측면 (아이디어 구상 전체·앱 설계·코드 생성)을 SKIP. NFR (비기능 요구사항) / 인프라 설계와 배포·관측 가능성(Observability)을 실행. 9개 유형 중 유일하게 (인프라는 배포 구성부터 시작하며, 앱 소스부터 시작하지 않기 때문에) reverse-engineering을 SKIP
security-patch	9 / 32	설계 절차는 거의 모두 SKIP. 단, bugfix와 달리 deployment-pipeline / deployment-execution은 EXECUTE (배포되지 않는 수정은 취약성을 막지 못함). 요구사항은 requirements-analysis가 아닌 nfr-requirements로 기록
poc	8 / 32	동작하는 코드까지의 좁은 경로만. bugfix 구성에 intent-capture (가설의 의도를 파악)를 추가한 형태. 설계·운영·계획은 생략 (Spike는 일회성임)
refactor	8 / 32	bugfix와 거의 동일 + functional-design (유지해야 할 동작의 목표 형태를 그림). 신제품도 신규 배포 측면도 없으므로 발견·운영은 스킵
bugfix	7 / 32

최소. 초기화 + reverse-engineering / requirements-analysis / code-generation / build-and-test. 기지 시스템에 대한 증분 작업이므로 그 외에는 불필요 |

bugfix

・refactor

・security-patch

이 세 가지는 "부트스트랩(bootstrap)할 것이 없는" 증분형으로, 모두 첫 번째 시작(별도 기사 「워킹 스켈레톤(Walking Skeleton)」에서 다룹니다)의 절차를 스킵한다는 점이 공통적입니다.

보충 (1차 자료 내의 불일치)

core/scopes/aidlc-enterprise.md의 설명문에는 "전체 32개 스테이지를 EXECUTE 하는 것은 enterprise뿐이다"라고 적혀 있지만, 실제로는 feature도 32/32입니다 (aidlc-feature.md 자체가 "runs every stage"라고 명시함). 두자의 차이는 실행 범위가 아니라 깊이뿐이라는 것이 실제 파일에서 읽을 수 있는 정확한 모습입니다.

또한 stage-protocol.md §8의 스코프 표는 개략적인 수치("~25" 등)로, 실제 수치와 약간의 차이가 있습니다 (mvp는 실제 22, bugfix는 7, refactor는 8, security-patch는 9, workshop은 표에 미게재). 본 기사의 수치는 각 스테이지의 프런트매터(frontmatter)에 있는 scopes:를 전수 집계한 실제 수치입니다.

스코프의 결정 방식

스코프 확정에는 "자동으로 짐작하는" 단계와 "최종적으로 어떤 값을 채택할지"의 단계가 있습니다.

키워드에 의한 자동 추정

사용자가 /aidlc ~를 고쳐줘와 같이 자유 문장으로 요청했을 때, aidlc-utility.ts의 inferScopeFromText()가 각 스코프의 keywords를 대조하여 짐작합니다. 규칙은 결정론적입니다.

• 단어 경계 매칭 (Word Boundary Match). bug는 debug나 fixture에는 해당하지 않습니다.
• 스코프를 알파벳 순으로 탐색하여 가장 먼저 일치하는 것을 채택 (호출할 때마다 결과가 동일하도록).
• 입력 문장이 키워드를 포함하고 있더라도 5어를 초과하는 경우(6어 이상), 또는 어떤 키워드에도 해당하지 않는 경우는 feature로 폴백(fallback)합니다. 이는 설명문에 우연히 키워드가 섞인 프로젝트 기술을 실수로 좁은 스코프로 분류하지 않기 위한 보험입니다.

이처럼 자동 추정은 출발점의 제안에 그치며, 판단이 어려울 경우 가장 넓은 feature로 기울도록 설계되어 있습니다.

최종적으로 채택되는 값

실행 시 실제 스코프를 결정하는 것은 aidlc-orchestrate.ts의 resolveScope()이며, 우선순위는 다음과 같습니다.

• state 파일에 기록된 스코프 (워크플로 진행 중에는 이것)
• --scope 플래그
• 환경 변수 AWS_AIDLC_DEFAULT_SCOPE
• 기본값 DEFAULT_SCOPE = "feature"

사람이 처음에 선택하는 흐름

신규 프로젝트에서 스코프를 명시하면 워크플로가 생성됩니다.

• /aidlc --scope <name> (또는 /aidlc <name>)로 해당 스코프의 워크플로를 시작.
• bugfix / feature / mvp / security-patch에는 키워드 자동 추정을 거치지 않고 고정으로 실행되는 전용 러너(runner) /aidlc-<scope>가 있습니다. 그 외의 스코프는 --scope를 통해 도달합니다.

사람이 --scope나 전용 러너로 명시하면 자동 추정보다 해당 설정이 우선됩니다.

깊이 기본값과의 관계

스코프가 결정하는 또 다른 요소는 깊이의 **기본값(default)**입니다. stage-protocol.md §8 「Depth Guidance」가 scope $\rightarrow$ depth 대응 관계를 정하고 있습니다.

깊이 기본값	스코프
Minimal	poc, bugfix, refactor, security-patch
Standard	feature, mvp, infra, workshop
Comprehensive	enterprise

스코프(Scope)가 결정하는 것은 깊이(depth)의 "기본값(default)"까지이며, 깊이의 단계 그 자체(질문량이나 결과물의 완성도)에는 관여하지 않습니다. 그 내용은 별도의 기사 「깊이(depth)」에서 다룹니다. 본 기사와 관련된 내용은 다음과 같습니다.

• 깊이는 스코프로 초기값이 결정되지만, 사람이 --depth로 나중에 덮어쓸 수 있습니다.
• 테스트 전략(test strategy)은 통상적으로 깊이를 따르지만, 스코프가 독자적인 기본값을 선언하고 있다면 그것이 우선됩니다 (workshop은 깊이가 Standard여도 테스트는 Minimal입니다). --test-strategy로 독립적으로 덮어쓸 수도 있습니다.
• 따라서 "Standard의 완성도 + Minimal의 테스트"와 같은 조합도 만들 수 있습니다.

스코프의 파일 정의

스코프의 구현은 "스코프를 늘리는 것이 얼마나 쉬운가"와 직결됩니다.

스코프는 다른 부품(센서나 에이전트)과 동일한 **파일 정의(file definition)**입니다 (추가 코드가 필요하지 않습니다). 정의는 두 곳으로 나뉩니다.

• 아이덴티티(Identity): core/scopes/aidlc-<name>.md 파일 1개 (깊이/키워드/설명 + 설명문).
• 멤버십(Membership): 전체 32개 스테이지 각각의 프런트매터(frontmatter)에 있는 scopes: 리스트. "이 스테이지는 어떤 스코프에서 실행되는가"를 각 스테이지 측에서 선언합니다.

빌드 시 aidlc-graph.ts compile이 **각 스테이지의 scopes:를 전치(transpose)**하여 EXECUTE/SKIP 그리드(scope-grid.json)를 생성합니다. 실행 시에는 이 그리드와 .md 파일의 프런트매터를 합성하여 스코프 정의를 복원합니다. 결과적으로 스코프를 늘리는 것은 "aidlc-<name>.md를 하나 두고, 대상 스테이지에 scopes: 태그를 추가하는 것"뿐입니다. 코드 변경은 불필요합니다.

새로운 스코프를 추가하면 /aidlc --scope <name>, --doctor, 키워드 자동 추정이 모두 자동으로 감지합니다. 본 기사의 EXECUTE/SKIP 수치가 "스코프 정의 파일의 설명문"이 아니라 "각 스테이지의 프런트매터 집계"를 진실로 삼는 이유는, 바로 그곳이 유일한 원천이기 때문입니다.

EXECUTE / SKIP 풀 매트릭스 (Full Matrix)

전체 스테이지 × 9종. ● = EXECUTE, ・ = SKIP. 각 스테이지의 프런트매터 scopes:를 집계한 것입니다. 열은 대체로 넓은 순서입니다.

페이즈 (Phase)	스테이지 (Stage)	ent	feat	work	mvp	infra	sec	poc	ref	bug
initialization	state-init	●	●	●	●	●	●	●	●	●
...	합계 (Total)	EXECUTE / 32	32	32	25	22	13	9	8	8

약어: ent=enterprise / feat=feature / work=workshop / mvp=mvp / infra=infra / sec=security-patch / poc=poc / ref=refactor / bug=bugfix.

참조 원문

파일	내용
core/scopes/ (9개 파일)	9종의 스코프 (scope) 정의. 각 프론트매터 (frontmatter) (name / depth / keywords / description / testStrategy) 및 "왜 해당 스테이지를 EXECUTE/SKIP 하는가"에 대한 설명문
core/aidlc-common/stages/ (32개 파일)	총 32개 스테이지. 각 프론트매터의 scopes: 리스트가 EXECUTE/SKIP의 유일한 근원 (부록 매트릭스는 이를 집계)
core/aidlc-common/protocols/stage-protocol.md	§8 Depth Guidance에 scope→depth 기본 대응표, 테스트 전략의 기본값 및 덮어쓰기 (override) 규칙
core/tools/aidlc-utility.ts	inferScopeFromText() : 키워드의 단어 경계 매칭 (word boundary match) · 알파벳 순서 첫 번째 일치 (first-match) · 5단어 초과 시 feature 폴백 (fallback)
core/tools/aidlc-orchestrate.ts	resolveScope() : state → --scope → 환경 변수 → 기본 feature의 우선순위
core/tools/aidlc-lib.ts	loadScopeMapping() : 그리드 (.stages) + .md 프론트매터를 합성하여 스코프 정의를 복원
CHANGELOG.md	0.5 계열: scope-mapping.json 폐지 → scopes/*.md + 각 스테이지 scopes: 태그의 파일 작성 (file-authored) 방식 전환, compile 시 전치 (transpose), /aidlc-<scope> 러너 (runner)

관련 기사

이전 기사: 진행의 핵심

다음 기사: 깊이

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

Discussion