코드가 라우팅하고 모델이 일한다 - AI-DLC v2가 v1의 단일 LLM 판단을 쪼갠 방식

코드가 라우팅하고 모델이 일한다

TL;DR

• v1과 v2의 차이가 한 문장으로 규정되는데 v1은 하나의 LLM에게 다음에 무엇을 할지 결정하는 일과 그것을 하는 일을 모두 요청했지만, v2는 둘을 쪼개서 코드가 어느 스테이지가 다음에 실행될지 결정하고 LLM은 그 안에서 숙련된 작업을 한다는 것이다. 그래서 성질이 붙는다. 매 실행마다 재현 가능하며 32개 스테이지와 11개 도메인 에이전트, 의도당 하나의 상태 파일로 구성된다.
• 프레임워크의 위치가 정의로 제시되는데 에이전트는 모델 더하기 하네스이며 이 프레임워크는 하네스를 제공한다는 것이다. 그리고 배포 구조가 밝혀진다. 하나의 코어인 하네스 중립 소스가 네 개의 하네스인 Claude Code와 Kiro CLI, Kiro IDE, Codex CLI로 생성되며 바이트 동일성이 보호된다.
• 스테이지의 구조가 원자 단위로 규정되는데 모든 스테이지는 컴파일러의 계약인 타입 지정 프론트매터와 에이전트가 읽는 본문을 가진 단일 마크다운 파일이고 본문은 생성 전 안내인 피드포워드와 생성 후 확인인 피드백으로 세 구획으로 나뉜다는 것이다. 방법론인 Steps, 파일 쓰기마다 발동하는 검사인 Sensors, 이번 실행의 교정이 다음 실행이 읽는 상시 규칙이 되는 Learn이다.
• 결정적 부분과 확률적 부분이 명확히 갈린다. 오케스트레이터는 aidlc-state.md와 컴파일된 스테이지 그래프를 읽어 하나의 라우팅 지시를 내보내며, 같은 상태가 들어가면 매번 같은 다음 스테이지가 나온다는 것이다. 반면 11개 도메인 에이전트는 확률적이고 각 에이전트는 모델에 고정되며 세션 툴셋을 상속받는다.
• 스코프가 같은 엔진의 깊이를 조절하는데 9개 스코프가 의도로부터 자동 감지되며 버그픽스는 7스테이지, PoC는 8, 리팩터는 8, 보안 패치는 10, 인프라는 13, MVP는 22, 워크숍은 25, 피처와 엔터프라이즈는 32라는 것이다. 그리고 원리가 명시된다. 스코프는 서브그래프를 켜는 것이고 건너뛴 스테이지도 DAG 안에 남아 있다.

Source

AI-DLC v2 Core Concepts — Yong(AWS Employee), AWS Builder Center, 2026년 7월 21일 발행 · 7월 22일 수정 · AI-DLC WORKFLOWS v2.3.0 GA PREVIEW

이 페이지는 자바스크립트로 렌더링되는 SPA여서 curl로는 3,101바이트의 셸만 받힌다. 아카이브 사본도 없어 CDP 브라우저로 직접 렌더링해 본문 7,429자를 확보했다.

[builder.aws.com/content/3GnQs6zaYp4mAx9FWBulDkhWnBo/ai-dlc-v2-core-concepts](https://builder.aws.com/content/3GnQs6zaYp4mAx9FWBulDkhWnBo/ai-dlc-v2-core-concepts)

Knowledge

v1이 한 LLM에게 두 일을 맡겼던 문제

문서는 프레임워크의 성격을 먼저 규정한다. AI-DLC는 에이전트 주도 개발 수명주기 프레임워크라는 것이고 이 글의 범위가 제시된다. v2를 훑는데 스테이지가 어떻게 마크다운 파일인지, 스코프가 어떻게 깊이를 조절하는지, 하나의 엔진이 그것 전부를 어떻게 라우팅하는지라는 것이다. 핵심 변경은 대비로 제시된다. v1은 하나의 LLM에게 다음에 무엇을 할지 결정하는 일과 그것을 하는 일을 둘 다 요청했는데, v2는 그 둘을 쪼갠다는 것이다. 코드가 어느 스테이지가 다음에 실행될지 결정하고 LLM은 그 안에서 숙련된 작업을 하며 그래서 매 실행마다 재현 가능하다는 것이다. 규모도 수치로 제시된다. 32개 스테이지와 11개 도메인 에이전트, 그리고 의도당 하나의 상태 파일이라는 것이다.

정의도 하나 제시된다. 에이전트는 모델 더하기 하네스이며 이 프레임워크는 하네스를 제공한다는 것이다. 그리고 배포 구조가 밝혀진다. 하나의 코어, 즉 하네스 중립 소스가 네 개의 하네스로 가는데 Claude Code와 Kiro CLI, Kiro IDE, Codex CLI라는 것이다. 생성 방식도 명시된다. 생성되며 바이트 동일성이 보호된다는 것이다.

다섯 단계

모든 프로젝트가 다섯 단계를 거친다고 제시되는데 워크스페이스 스캐폴딩에서 프로덕션 운영까지이며 단계가 순서대로 열거된다. 0단계는 초기화인데 워크스페이스를 스캐폴딩하고 그린필드인지 브라운필드인지 감지한다는 것이다. 1단계는 착상인데 의도 포착과 명료화 질문, 스코프 정의라는 것이다. 2단계는 인셉션인데 요구사항과 스토리, 설계이며 무엇과 왜에 해당한다는 것이다. 3단계는 구축인데 유닛 루프이며 코드와 테스트, 센서 활성 상태라는 것이다. 4단계는 운영인데 배포하고 모니터링하고 루프를 닫는다는 것이다. 그리고 통제권이 강조된다. 거의 모든 스테이지에 승인 게이트가 있으며 당신이 통제권을 유지한다는 것이다.

원자 — 하나의 파일, 세 구획

스테이지의 구조가 규정된다. 모든 스테이지는 단일 마크다운 파일이며 타입 지정 프론트매터와 에이전트가 읽는 본문을 갖는데, 프론트매터의 성격은 컴파일러의 계약이라는 것이다. 본문의 분할도 제시된다. 본문은 세 구획으로 나뉘는데 생성 전에 안내하는 피드포워드와 생성 후에 확인하는 피드백이라는 것이다.

첫째가 피드포워드로서의 Steps인데 방법론이라는 것이다. 내용도 구체적이다. LLM이 따르는 번호 붙은 산문이며 방법론 소유자들이 저술하고 그 스테이지를 위해 로드되는 지식과 규칙, 페르소나가 함께 온다는 것이다. 둘째가 피드백으로서의 Sensors인데 검사라는 것이다. 동작이 서술된다. 임포트된 린터와 타입 체커가 모든 쓰기마다 발동해 출력을 검증하며 발견 사항은 감사 추적에 기록되고 조언적이며 절대 차단하지 않는다는 것이다. 셋째가 실행 간에 학습하는 피드백으로서의 Learn인데 피드백 이음새라는 것이다. 기제가 서술된다. 이번 실행의 교정이 다음 실행이 읽는 상시 규칙이 되며 무엇이 유지할 만한지는 사람이 결정한다는 것이다.

무엇이 그것을 움직이는가

두 부분이 결정적인 것과 확률적인 것으로 나뉜다. 오케스트레이터가 결정적인 쪽인데 aidlc-state.md와 컴파일된 스테이지 그래프를 읽어 하나의 라우팅 지시를 내보낸다는 것이다. 그리고 결정성이 명시된다. 같은 상태가 들어가면 같은 다음 스테이지가 나오며 매번 그렇다는 것이다. 주요 기능도 열거된다. next와 report라는 두 엔진 서브커맨드가 있으며 next는 9종의 지시 종류 중 하나를 내보내는데 run-stage와 present-gate, ask, invoke-swarm, done 같은 것들이라는 것이다. audit 샤드는 70개 이벤트의 구조화된 추적이며 타임스탬프가 붙고 클론별로 샤딩되고 --resume은 상태와 감사를 재로드해 스테이지 중간부터 이어받는다는 것이다.

11개 도메인 에이전트가 확률적인 쪽이다. 열거되면 Product와 Design, Delivery, Architect, AWS-Platform, Compliance, DevSecOps, Developer, Quality, Pipeline-Deploy, Operations라는 것이다. 각 에이전트의 조건도 명시된다. 각 에이전트는 하나의 모델에 고정되며 세션 툴셋을 상속받는다는 것이다. 그리고 전체 명부가 따로 제시된다. 전체적으로는 14개 에이전트 명부인데 reviewer와 composer, product-lead가 더해진 것이라는 것이다.

하나의 엔진, 여러 개의 문

커맨드 체계가 네 종류로 제시된다. 첫째는 하나뿐인 /aidlc이며 오케스트레이터인데, 전체 워크플로이며 스코프를 감지하고 모든 게이트를 걸으며 디스크에서 재개한다는 것이다. 둘째는 네 개인 스코프 러너이며 /aidlc-bugfix 같은 형태인데, 같은 루프에 하나의 스코프가 구워 넣어진 것이며 버그픽스와 MVP, 피처, 보안 패치라는 것이다. 셋째는 29개인 스테이지 러너이며 /aidlc-code-generation 같은 형태인데, 하나의 스테이지를 고립된 상태로 실행하며 당신의 워크플로를 절대 진행시키지 않도록 도구 차원에서 강제된다는 것이다. 넷째는 세 개인 세션 뷰이며 /aidlc-replay 같은 형태인데, 읽기 전용이며 replay와 session-cost, outcomes-pack이 있고 상태를 절대 변경하지 않는다는 것이다.

두 층위의 지식

지식이 두 층으로 분리된다. 방법론은 프레임워크와 함께 배포되며 .claude/knowledge/에 있고 규칙이 붙는다. 당신은 이것을 건드리지 않는다는 것이다. 팀 지식은 사용자가 관리하며 aidlc/spaces/<space>/knowledge/에 있고 보장이 붙는다. 프레임워크가 이것을 절대 덮어쓰지 않는다는 것이다. 디렉터리 구조도 예시된다. aidlc/knowledge/ 아래에 developer-agent/가 있고 그 안에 typescript-conventions.md와 api-design-patterns.md가 있다는 것이다. 그리고 quality-agent/ 아래 acceptance-criteria.md, architect-agent/, 그리고 aidlc-shared/ 아래 security-baselines.md가 있다는 것이다.

적응적 스코프 — 같은 엔진, 다른 깊이

스코프가 9개라고 제시되며 의도로부터 자동 감지되는데, 두 가지 예외가 명시된다. 피처는 키워드 없을 때의 포괄 기본값이고 엔터프라이즈는 명시적으로 선택해야 하며 /aidlc compose로 직접 재단할 수도 있다는 것이다. 스코프별 스테이지 수도 제시된다. 버그픽스가 7개, PoC가 8개, 리팩터가 8개, 보안 패치가 10개, 인프라가 13개, MVP가 22개, 워크숍이 25개, 피처가 32개, 엔터프라이즈가 32개라는 것이다. 그리고 원리가 명시된다. 스코프는 서브그래프를 켜며 건너뛴 스테이지는 DAG 안에 남아 있다는 것이다.

표준이 실제로 붙게 하는 방법

세 가지 강제 기제가 함께 작동한다고 제시된다. 첫째는 훅인데 종류가 열거된다. SessionStart와 PostToolUse, PreCompact, SubagentStop, Stop이며 그중 Stop 훅이 유일한 차단 게이트라는 것이다. 둘째는 센서인데 당신 자신의 린터와 타입 체커를 감싼다는 것이다. 동작과 성격도 명시된다. 파일 쓰기 시 발동하고 결과를 감사 추적에 넣으며 조언적이고 차단하지 않는다는 것이다. 셋째는 학습 루프인데 기제가 서술된다. 사람의 교정이 project.md의 영속 규칙이 되며 팀 단위로 승격 가능하고 다음 실행에 자동으로 적용된다는 것이다.

선택적 도구 — 더 날카로운 코드 품질

전제가 먼저 명시된다. 이 중 어느 것도 전제 조건이 아니며 AI-DLC는 Claude Code와 bun만으로도 돌아가지만 품질에는 두 개의 레버가 있다고 한다. 첫째 레버는 입력을 접지하는 것이며 쓰이는 오류를 줄이는 쪽이다. 두 수단이 제시된다. 에디터의 LSP인데 코드베이스에서 실제 심볼과 타입, 정의를 가져오며 Kiro에서는 /code라는 것이다. 효과가 명시된다. 에이전트가 추측한 API가 아니라 존재하는 API에 대고 쓴다는 것이다. 다른 하나는 AWS MCP 서버인데 실제 AWS API 형태와 가격, IaC를 준다는 것이다. 배포 방식도 밝혀진다. uvx를 통해 .mcp.json에 실려 오며 비차단이라는 것이다.

둘째 레버는 출력을 확인하는 것이며 게이트 전에 나머지를 잡는 쪽이다. 두 수단이 제시된다. 린트와 타입 체크가 센서로 배포되며 그 둘이 AI-DLC가 포함하는 것이라는 것이다. 그런데 조건이 붙는다. 센서는 당신이 설치하고 설정한 도구만 감싸며 eslint와 tsc 같은 것이라는 것이다. 다른 하나는 당신이 저술하는 Playwright e2e인데 그것을 자기 센서로 감싸라는 것이다. 그것이 검증하는 것도 명시된다. 컴파일된다는 것만이 아니라 그것이 실제로 작동한다는 것을 검증한다는 것이다.

그리고 두 레버의 관계가 정리된다. 접지가 앞단에서 오류를 줄이고 센서가 빠져나간 것을 잡으며 두 번째 절의 피드포워드와 피드백 분할을 코드 품질에 적용한 것이라는 것이다.

규모에서의 구축 — 자율 스웜

조건이 제시된다. 당신이 자율성을 부여하면 엔진이 invoke-swarm을 내보내고 컨덕터가 N개 유닛을 병렬로 펼친다는 것이다. 스웜은 엄격한 프로토콜을 따른다고 하며 네 단계가 열거된다. 펼치기는 N개 유닛이 동시에 실행되며 각각 새 컨텍스트에서 돈다는 것이다. 판정과 재검증은 심판이 병합 전에 다시 확인하는 것이며 거짓말하는 컨덕터에 대한 방어라는 것이다. 직렬화된 병합은 조작 방지이며 한 번에 하나씩, 전체 감사 추적과 함께라는 것이다. 그리고 실패 처리가 명시된다. 어떤 실패든 사람에게 바통을 돌려준다는 것이다.

심판의 성격이 규정된다. aidlc-swarm.ts는 결정적이고 상태 없는 심판이며 그것은 코드를 절대 쓰지 않고 판정한다는 것이다. 마지막으로 병렬성의 위치가 규정된다. 병렬 처리량은 해피 패스 최적화이며 절대 우회가 아니라는 것이다.

확장 — 코드보다 데이터

확장 방법이 제시된다. 스테이지를 추가하고 싶으면 타입 지정 프론트매터를 가진 마크다운 파일 하나를 넣고 그것이 속하는 스코프들을 태그하면 된다는 것이다. 그다음 두 명령이 제시된다. compile로 그래프와 그리드를 다시 만들고 /aidlc --doctor로 모든 스코프의 서브 DAG를 검증하며 필요 없는 것도 명시된다. TypeScript도 오케스트레이터 편집도 필요 없다는 것이다. 플러그인도 언급된다. 스테이지 묶음을 선택적 플러그인으로 번들할 수 있는데 호스트 네이티브 설치이며 코어 위에 조합되고 비활성 상태에서는 기본 트리를 바이트 동일하게 남긴다는 것이다. 글은 세 문장으로 끝난다. 하나의 엔진이고 여러 개의 문이며 코드가 라우팅하고 모델이 일한다는 것이다.

더 생각해보기

• 결정을 코드로 옮기고 작업만 LLM에 남기는 분할은 어떤 종류의 판단까지 코드로 표현할 수 있는가.
• 32개 스테이지를 마크다운 파일로 두는 설계는 방법론 변경 속도를 얼마나 올리며 무엇을 잃는가.
• 센서가 조언적이고 차단하지 않는다면, 실제로 품질을 막는 것은 Stop 훅 하나인가.
• 이번 실행의 교정이 다음 실행의 상시 규칙이 되는 학습 루프는 잘못된 교정도 같은 속도로 굳히는가.
• 스코프 자동 감지가 틀렸을 때의 비용은 7스테이지와 32스테이지 사이에서 어떻게 나타나는가.
• 스테이지 러너 29개가 워크플로를 진행시키지 못하도록 도구로 강제하는 설계는 무엇을 예방하려는 것인가.
• 거짓말하는 컨덕터 방어라는 표현은 실제로 어떤 실패를 겪고 나서 붙은 이름인가.
• 결정적이고 상태 없는 심판이 코드를 쓰지 않고 판정만 한다면 그 판정의 근거는 무엇으로 검증되는가.
• 하나의 코어가 네 하네스로 바이트 동일하게 생성된다는 보장은 하네스별 특성을 어디까지 포기하는가.
• 방법론 지식은 건드리지 못하고 팀 지식만 관리하게 나눈 경계는 조직 관행과 충돌할 때 어떻게 되는가.