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의 설계 사상은 '사람이 주도권을 유지한 채 AI의 속도를 활용한다'는 하나의 점에 관통되어 있습니다. 승인 게이트(Approval Gate)에서 의사결정을 사람에게 고정하고, 결정론적인 엔진(Deterministic Engine)으로 진행을 예측 가능하게 하며, 학습 루프(Learning Loop)를 통해 같은 실수를 반복하지 않는다. 이 세 가지 원칙이 설계의 중추입니다.

본 기사에서는 각각의 원칙이 왜 필요하며, 어떻게 맞물려 돌아가는지를 풀어냅니다.

근본적인 문제 의식

AI에게 코드를 쓰게 하는 것은 이제 특별한 일이 아닙니다. 프롬프트(Prompt)를 던지면 함수가 돌아오는 시대입니다. 다만, 이것이 잘 작동하는 것은 작은 태스크(Task) 중일 때뿐이며, 프로젝트가 본격화되면 금세 파탄에 이릅니다.

이전 프롬프트에서 결정했던 방침을 다음 프롬프트가 잊어버립니다. 왜 그런 설계를 했는지 어디에도 남아 있지 않습니다. 모델이 "이쪽이 더 나을 것이다"라고 멋대로 판단을 내려, 깨달았을 때는 이미 늦어버린 상태가 됩니다.

이는 "모델이 똑똑하지 않아서" 발생하는 것이 아니라, "구조가 없어서" 발생하는 것이라는 점이 AI-DLC v2의 출발점입니다. 사람의 팀도 마찬가지입니다. 회의록도 없고, 승인 플로우(Approval Flow)도 없이 구두로만 진행하는 프로젝트는 대개 똑같이 파탄 납니다. AI가 고속으로 판단을 내릴 수 있게 된 지금이야말로, 사람이 따라잡을 수 있는 페이스로 의사결정을 가시화하는 메커니즘이 필요합니다. AI-DLC v2는 그러한 인식 하에 설계되었습니다.

가장 중시하는 세 가지 원칙

설계의 근저에는 다음과 같은 사고방식이 있습니다.

사람이 모든 의사결정을 쥐고 있다

전체 32개 스테이지 중 초기화 단계인 3개를 제외한 29개 스테이지에 승인 게이트(Approval Gate)가 있습니다. 에이전트(Agent)가 아무리 훌륭한 결과물을 만들어도, 사람이 "승인"이라고 말하지 않는 한 워크플로우(Workflow)는 앞으로 나아가지 않습니다.

그리고 이 승인 권한은 승계되지 않습니다. 어떤 스테이지에서 "추천하는 대로 진행해 줘"라고 승인하더라도, 그 허가는 해당 스테이지에 한정되며 다음 스테이지로 이어지지 않습니다. 자율 모드(Autonomous Mode)는 사람이 명시적으로 "자율적으로 실행해도 좋다"라고 말했을 때만 유효해집니다. 다소 보수적으로 보일 수 있지만, AI가 멋대로 달려 나갈 리스크와 비교하면 매번 버튼을 누르는 번거로움이 훨씬 작다는 판단입니다.

승인 권한을 단발성으로 끊어내는 것은 주권을 사람 측에 고정하기 위한 선택입니다. 게이트에서의 반려나 "현 상태로 승인"과 같은 기능은 별도 기사 「승인 게이트」에서 다룹니다. 첫 번째 시제품 단계에서는 설정과 관계없이 반드시 멈춘다는 메커니즘은 별도 기사 「워킹 스켈레톤(Walking Skeleton)」에서 다룹니다.

"다음에 무엇을 할지"는 AI에게 결정하게 하지 않는다

워크플로우의 라우팅(Routing), 즉 다음에 어떤 스테이지를 실행하고 어떤 스테이지를 스킵(Skip)할지는 결정론적인 엔진(Deterministic Engine)이 결정합니다. 엔진은 TypeScript로 제작된 도구 모음이며, 동일한 상황이라면 반드시 동일한 판단을 반환합니다. LLM의 역할은 "맡겨진 스테이지를 잘 수행하는 것"뿐입니다.

이러한 분리가 필요한 이유는 LLM이 라우팅 판단에서 "선의의 일탈"을 하기 쉽기 때문입니다. "여기는 스킵해도 괜찮겠지", "사용자가 급하니 승인은 생략하자". 이러한 판단을 구조적으로 봉쇄하지 않으면 반드시 어딘가에서 발생합니다. 엔진이 라우팅을 담당함으로써 워크플로우의 진행은 항상 예측 가능해집니다. 엔진과 컨덕터(Conductor, 엔진의 지시를 한 단계씩 실행하는 진행 역할)를 어떻게 나누고 있는지는 별도 기사 「진행의 핵심」에서 다룹니다.

같은 실수를 두 번 반복하지 않는다

사람이 에이전트의 실수를 바로잡았을 때, 그 수정 사항이 그 자리에서 사라져 버리는 것은 아까운 일입니다. AI-DLC v2에는 "학습 루프(Learning Loop)\

다만, 학습이 반영되는 것은 "다음 워크플로우부터"입니다. 현재 실행 중인 워크플로우 도중에 규칙이 바뀌면, 이미 승인한 게이트(Gate)의 전제가 무너져 버립니다. "쓰기는 즉시 수행하되, 반영은 다음 워크플로우부터". 이 규율이 실행 중인 워크플로우의 안정성을 담보합니다. 학습을 어떻게 가져오고 어디에 남길지는 별도 기사 「학습 루프(Learning Loop)」에서, 지켜야 할 규칙과 참조하는 지식(Knowledge)의 차이는 별도 기사 「규칙과 지식(Rule and Knowledge)」에서 다룹니다.

안정적인 이유

"쓰기는 즉시, 반영은 다음 회차"라는 규율은 AI-DLC v2만의 독자적인 아이디어는 아닙니다. 네트워크 공학에서 말하는 3계층 아키텍처(Three-plane architecture)와 같은 개념입니다.

현대의 라우터는 업무를 세 가지로 나눕니다. 설정을 입력하고 상태를 확인하는 "관리면(Management plane)", 경로를 계산하는 "제어면(Control plane)", 실제로 패킷을 전송하는 "데이터면(Data plane)"입니다. 경로 계산은 네트워크 구성이 변경되었을 때 한 번만 수행하며, 그 결과를 테이블에 저장합니다. 패킷이 전송되는 도중에 경로를 재계산하지는 않습니다.

AI-DLC v2의 구조도 이와 같습니다. 미리 단 한 번 "컴파일(Compile)"이 실행되어, 스테이지 정의·규칙·센서(Sensor, 결과물 저장 시 자동으로 실행되어 중단 없이 조언하는 메커니즘)를 스테이지 간의 의존 그래프(Dependency graph)로 고정합니다. 실행 중에는 해당 그래프를 참조할 뿐 재계산하지 않으므로, 워크플로우 도중에 동작이 변하는 일은 원리적으로 발생하지 않습니다. 이러한 안심감은 특히 여러 명이 병행하여 작업하는 상황에서 큰 효과를 발휘합니다. 센서가 구체적으로 무엇을 보고 있는지는 별도 기사 「센서(Sensor)」에서 다룹니다.

참고로, 이 설계 덕분에 "회복성(Resilience)"도 자연스럽게 얻을 수 있습니다. 감사 로그(Audit log), 상태 파일(State file), 결과물이 규율 있게 작성되어 있기 때문에, 세션이 끊기더라도 새로운 세션이 이전 상태를 복원할 수 있습니다. 무엇이 어디에 기록되는지는 별도 기사 「상태와 감사(State and Audit)」에서 다룹니다. 회복성을 억지로 만들어낸 것이 아니라, 데이터 관리 규율이 그대로 회복성으로 이어지는 것입니다.

담당 범위가 넓은 소수의 에이전트

AI-DLC v2의 에이전트는 13체(결과물을 만드는 11체 + 리뷰 전담 2체)입니다. 수십 명의 담당 범위가 좁은 전문가를 나열하는 방식은 취하지 않습니다.

에이전트 간의 경계는 정보가 손실되는 지점이기 때문입니다. 동일한 아키텍트가 설계 스테이지도, 이를 구현 단위로 나누는 스테이지도 담당한다면 핸드오프(Handoff) 문서가 필요 없습니다. 컨텍스트(Context)가 에이전트 내부에 남게 됩니다. 사람의 팀에서도 3~5명이 한 조를 이루어 피처(Feature) 전체를 담당하는 것이, 대규모 인원의 릴레이 방식보다 정보 유실이 적습니다. 그것과 같은 발상입니다.

에이전트끼리는 직접 호출하지 않습니다. 위임은 항상 컨덕터(Conductor)를 통해 이루어집니다. 덕분에 "누가 누구를 호출했는지"를 항상 하나의 평면적인 호출 관계로 추적할 수 있으며, 재귀적으로 깊어지는 호출 체인(Call chain)도 구조적으로 발생하지 않습니다. 13체가 각각 무엇을 맡는지는 별도 기사 「공정과 에이전트(Process and Agent)」에서 다룹니다.

버그 수정부터 엔터프라이즈까지 담당하는 단일 엔진

32개 스테이지를 모두 통과하는 것은 기능 개발이나 엔터프라이즈(Enterprise)이며, 버그 수정이라면 7개 스테이지, PoC(개념 증명)라면 8개 스테이지를 통과합니다. 이 전환은 "스코프(Scope)"라는 메커니즘이 담당합니다. 9개의 이름이 지정된 스코프가 스테이지별 실행/스킵(Skip)을 제어합니다.

나아가 "깊이(Depth)"가 결과물의 상세함을, "테스트 전략(Test strategy)"이 테스트의 철저함을 독립적으로 제어합니다. 엔진도 에이전트도 변하지 않습니다. 변하는 것은 "어떤 스테이지를 통과할 것인가"와 "각 스테이지에서 어디까지 파고들 것인가"뿐입니다. 어떤 스코프가 무엇을 통과하는지는 별도 기사 「스코프(Scope)」에서, 깊이에 어떤 단계가 있는지는 별도 기사 「깊이(Depth)」에서 다룹니다.

이를 통해 개념 증명과 규제 대응 프로젝트를 동일한 프레임워크에서 다룰 수 있습니다. 팀이 축적하는 학습 내용도 흩어지지 않고 한곳에 모입니다.

어떤 CLI에서도 동작하는 이식성

마지막은 구현 측면의 사상입니다. AI-DLC v2의 방법론은 core/ 디렉토리에 단 한 번 작성되어 있으며, 거기서부터 Claude Code, Kiro CLI, Codex CLI 각각을 위한 배포물이 생성됩니다. 어떤 CLI도 특별 대우를 받지 않으며, 동일한 소스에서 동일한 규칙으로 출력됩니다.

새로운 CLI 하네스(Harness)를 추가하는 데 필요한 것은 하나의 디렉토리와 하나의 매니페스트(Manifest) 파일뿐입니다. 방법론 본체에는 일절 손을 대지 않습니다. 방법론을 개선하면 모든 CLI에 반영되며, 특정 CLI만 뒤처지는 일도 없습니다.

요약

AI-DLC v2가 실현하고자 하는 것은 "AI의 속도를 활용하면서도, 사람이 뒤처지지 않는" 상태입니다. 승인 게이트 (Approval Gate)를 통해 주권을 유지하고, 엔진이 라우팅 (Routing)을 담당하여 예측 가능성을 확보하며, 학습 루프 (Learning Loop)를 통해 동일한 수정을 두 번 요구하지 않도록 합니다. 이 세 가지가 서로를 지탱하며 "현재의 워크플로우는 안정적으로 실행된다"와 "다음 워크플로우는 이전보다 더 똑똑하다"라는 두 가지 약속을 동시에 이행합니다.

워크숍의 작은 프로토타입부터 감사 추적 (Audit Trail)이 요구되는 엔터프라이즈 프로젝트까지, 동일한 엔진이 스코프 (Scope)를 전환하는 것만으로 대응할 수 있는 이유는 바로 이러한 토대가 있기 때문입니다. 앞서 언급한 세 가지 원칙은 다음 기사인 "개념 맵 (Concept Map)"에서 전체 구조 속의 위치를 정의하고, 이후 각 기사에서 하나씩 심층적으로 다룰 예정입니다.

참조원

파일	내용
`core/` 의 스테이지 `.md` (32개) / `tools/aidlc-graph.ts`
5단계 32스테이지 및 그 의존성 그래프 (컴파일러)
`aidlc-common/protocols/stage-protocol.md`
승인 게이트 (초기화를 제외한 각 스테이지 말단) · 깊이 · 학습 루프
`core/agents/` (13개 파일)
에이전트 13체 (결과물을 만드는 11체 + 리뷰 전담 2체)
`tools/aidlc-orchestrate.ts` / `aidlc-common/conductor.md`
결정론적 엔진 (Deterministic Engine)과 컨덕터 (Conductor)의 분리
`tools/aidlc-sensor.ts`
결과물 저장 시 실행되는 조언적 센서 (Advisory Sensor)
`core/scopes/*.md` (9개 파일)
9종의 스코프와 스테이지별 실행/스킵
`tools/aidlc-lib.ts`
3종의 배포 하네스 (Harness) (`KNOWN_HARNESS_DIRS` = `.claude` / `.kiro` / `.codex`. Kiro IDE는 `.kiro`를 공유하는 별도 패키징)