AI로 풀어보는 AI-DLC v2: 깊이 (depth)

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

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

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

깊이 (depth)는 워크플로우가 각 스테이지에서 결과물을 어디까지 만들어낼지를 결정하는 설정입니다. 실행하는 스테이지의 수는 바꾸지 않습니다. 하나하나의 완성도, 즉 컨덕터 (Conductor, 진행 역할 AI)가 내는 질문의 수와 완성되는 결과물의 상세함이 달라집니다. 값은 최소한·표준·포괄적의 3단계로, 동일한 스테이지를 얕게 혹은 깊게 돌릴 수 있습니다.

깊이가 있기 때문에 버그 수정과 같은 가벼운 안건은 요점만 좁히고, 규제 대응과 같은 무거운 안건은 구석구석까지 채우는 식의 조정을 하나의 메커니즘 안에서 할 수 있습니다. 본 기사에서는 깊이가 어떤 3단계를 취하는지, 테스트 완성도를 결정하는 테스트 전략 (test strategy)과 어떻게 나뉘는지, 그리고 언제 어떻게 바꿀 수 있는지를 풀어냅니다.

AI-DLC v2에는 워크플로우의 동작을 바꾸는 독립된 축이 3개 있습니다. 깊이는 그중 '각 스테이지의 완성도'를 담당합니다.

축	결정하는 것
스코프 (Scope)	어떤 스테이지를 실행할 것인가
...

스코프에는 9가지 종류가 있으며, 안건의 성질에 따라 실행할 스테이지를 전환합니다. 그 목록과 활용법은 별도 기사 「스코프」에서 다룹니다. 본 기사는 남은 두 가지, 깊이와 테스트 전략에 집중합니다.

깊이가 취할 수 있는 값은 최소한 (Minimal)・표준 (Standard)・포괄적 (Comprehensive)의 3단계입니다.

깊이	결과물의 완성도	적합한 상황
최소한	핵심 판단만을 얇게. 임의의 항목은 생략	버그 수정・패치・PoC
...

변하는 것은 결과물의 분량과 컨덕터가 각 스테이지에서 내는 질문의 수입니다. 최소한이라면 1 스테이지당 24문항으로 빠르게 진행되고, 표준은 58문항, 포괄적은 8문항 이상을 들여 구석구석까지 채웁니다. 이것들은 기준일 뿐 상한선은 아니어서, 설명이 모호하면 최소한이라도 질문을 늘리고, 요구사항이 명확하면 포괄적이라도 줄입니다. 또한, 답변 간의 모순 검출 및 해소만은 어떤 깊이에서도 반드시 수행합니다.

깊이는 결과물 (문서·도표·질문)의 완성도만을 결정하며, 테스트의 개수에는 관여하지 않습니다. 테스트를 어디까지 완성할지는 테스트 전략이라는 별도의 축이 담당합니다. 테스트 전략의 값도 깊이와 마찬가지로 최소한·표준·포괄적의 3단계입니다.

두 가지가 분리되어 있기 때문에, "결과물은 표준으로 확실히 만들되, 테스트는 최소한으로 빠르게 돌린다"와 같은 조합을 선택할 수 있습니다. 테스트 전략의 기본값은 깊이를 따르며, 깊이를 표준으로 설정하면 테스트 전략도 표준이 됩니다. 예외는 연수용 workshop 스코프뿐이며, 깊이는 표준으로 유지하되 테스트 전략만 최소한으로 설정합니다. 학습을 위해 결과물은 갖추되, 테스트는 가볍게 하여 페이스를 유지하려는 목적입니다.

--test-strategy 플래그를 사용하면 깊이와 독립적으로 테스트 전략만 덮어쓸 수 있습니다. --depth standard --test-strategy minimal이라고 하면, 표준 결과물에 최소한의 테스트라는 구성이 됩니다.

깊이의 기본값은 스코프가 결정합니다. 어떤 스코프가 어떤 깊이를 기본값으로 하는지는 별도 기사 「스코프」에서 다룹니다. 결정된 기본값은 워크플로우 초기화 시 상태 파일 (aidlc-state.md)에 기록되어 확정됩니다.

그 후, 사람은 나중에 깊이를 변경할 수 있습니다. 변경할 수 있는 상황은 3가지입니다.

타이밍	방법
기동 시	--depth 플래그로 지정 (예: --scope bugfix --depth comprehensive)
스코프 확인 시	제시된 스코프를 확인하는 단계에서 깊이를 변경
승인 게이트 (Approval Gate)	재작업 피드백으로서 다른 깊이를 요구

우선순위는 단순하여, 명시적인 지정이 있으면 그것을 사용하고, 없으면 스코프의 기본값을 사용합니다. 깊이나 테스트 전략을 변경하면 감사 로그에 DEPTH_CHANGED가 기록됩니다.

TEST_STRATEGY_CHANGED로 기록이 남습니다. 승인 게이트(Approval Gate) 자체는 별도의 기사 「승인 게이트」에서 다룹니다.

동일한 스테이지 그룹을 통과하더라도, 깊이(depth)가 달라지면 결과물의 완성도(weight)는 크게 달라집니다.

안건	깊이	결과물의 완성도
버그 수정	최소한 (Minimal)	수정에 필요한 질문만 포함. 요구사항은 수 건, 설계 결정 기록 (ADR) 없음
...

엔진도 에이전트도 스테이지의 수도 변하지 않습니다. 변하는 것은 「어디까지 파고들 것인가」뿐입니다.

파일	내용
core/tools/aidlc-utility.ts	깊이(depth)·테스트 전략(test strategy)의 enum (minimal / standard / comprehensive) 및 해결 로직 (테스트 전략의 기본값은 깊이를 따름)
core/aidlc-common/protocols/stage-protocol.md	§8 깊이별 질문 수의 기준·결과물 규모, 승인 게이트에서의 변경, 모순 탐지는 모든 깊이에서 필수
core/scopes/ (9개 파일)	각 스코프(scope)의 depth 기본값. aidlc-workshop.md만 testStrategy: Minimal을 분리
core/tools/aidlc-audit.ts	감사 이벤트 DEPTH_CHANGED / TEST_STRATEGY_CHANGED 정의

이전 기사: 스코프

다음 기사: 결과물의 흐름

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