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

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

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

AI-DLC v2의 공정은 32단계, 스코프(Scope)는 9종. 연재에서는 그렇게 기술해 왔습니다. 이것은 출하 시점의 수치이며, 고정된 양이 아닙니다.

플러그인 메커니즘은 공정 그 자체를 외부에서 추가하는 구조입니다. 새로운 스테이지를 가져올 뿐만 아니라, 기존 스테이지에 항목을 추가할 수도 있습니다. 비기능 설계(Non-functional design) 스테이지에 '테스트 하네스(Test Harness) 설계'라는 절차와 결과물을 추가하는 식입니다.

본 기사에서는 추가할 수 있는 것의 종류, 기존 스테이지에 추가된 내용이 어떻게 섞이는지, 그리고 플러그인이 하나도 없을 때 core가 변하지 않음을 어떻게 보장하는지를 풀어냅니다.

플러그인은 plugins/<이름>/에 둡니다. 선언 파일이 해당 플러그인이 무엇을 가져오는지 열거합니다.

출하 시에는 test-pro라는 참고 구현이 하나 포함됩니다. 테스트의 포괄성을 다루는 플러그인으로, 위의 모든 것을 사용하고 있습니다.

플러그인이 가져오는 스테이지는 core의 스테이지와 동일한 형태를 가집니다. 프론트매터(Frontmatter)에 번호·페이즈(Phase)·주담당·모드를 갖추고 있으며, plugin: 필드로 누구의 소유인지를 나타낸다는 점만 다릅니다.

번호를 매기는 방식에 기교가 있습니다. 참고 구현은 2개의 스테이지를 가지며, 그중 구축 페이즈의 것은 3.85라는 번호로, 구축 페이즈의 기존 스테이지(3.1~3.7) 뒤에 끼어듭니다. 소수를 사용함으로써, core 측의 번호 매기기를 바꾸지 않고 삽입할 수 있습니다.

실행 조건도 core의 스테이지와 동일하게 작성할 수 있습니다. 참고 구현의 통합 테스트 스테이지는 "플러그인이 활성화되어 있고, 빌드가 여러 작업 단위에 걸쳐 있을 때 1회만"이라는 조건을 가집니다. 이는 모든 스테이지 공통의 산문 필드로, 플러그인 고유의 것이 아닙니다.

이와 별도로, 기계가 읽을 수 있는 기동 조건 필드도 있습니다. 참고 구현의 운영 페이즈 스테이지가 "어떤 결과물의 생산자가 계획에 포함되어 있을 때"라는 형태로 작성되어 있지만, 현재는 형식이 올바른지 검증할 뿐 평가 자체는 미구현 상태입니다 (후술할 "지금 추가할 수 없는 것").

플러그인은 core의 스테이지 파일을 수정하지 않고도, 그 내용에 절차나 결과물을 추가할 수 있습니다.

추가를 작성한 파일에는 어떤 스테이지가 대상인지와 무엇을 추가할지가 선언되어 있습니다. 참고 구현이 NFR 설계 스테이지에 추가하고 있는 것을 예로 들면 다음과 같습니다.

• 만드는 결과물을 1개 추가 (테스트 하네스 설계)
• 읽는 결과물을 1개 추가 (임의 취급)
• **필수 헤딩(Heading)**을 1개 추가 ("Test Harness Design")
• 본문 파편을 지정된 위치에 삽입

삽입 위치는 이름으로 지정합니다. 참고 구현은 "절차의 마지막"을 지정하고 있으며, 여러 플러그인이 같은 위치를 노릴 경우를 대비해 순서를 나타내는 수치도 덧붙입니다.

즉, core의 스테이지 정의는 그대로 유지되면서, 합성된 결과가 실제로 사용됩니다.

합성을 수행하는 것은 세션 시작 시마다 실행되는 하나의 스크립트입니다. 동일한 내용을 두 번 넣지 않도록 설계되어 있으며, 변경 사항이 없으면 아무 작업도 하지 않고 종료됩니다. 수행하는 작업은 다음 4가지입니다.

새로운 스테이지를 복사합니다. 이미 동일한 이름이 있다면 덮어쓰지 않습니다.

추가 사항을 혼합합니다. 생성할 결과물(Artifacts), 읽을 결과물, 센서, 필수 헤더(Mandatory headings)는 대상 스테이지의 선언에 더해집니다 (중복은 제거됩니다). 읽을 결과물의 경우, 필수 여부나 조건부 여부에 대한 정보도 유지됩니다.

본문 파편을 삽입합니다. 내용의 해시(Hash)를 확인하여 동일한 것을 두 번 넣지 않도록 합니다. 버전이 올라갔을 때의 교체 작업에도 대응하며, 여러 플러그인이 섞이더라도 순서가 결정됩니다.

그래프를 재구성합니다. 새로운 스테이지가 추가되었으므로, 엔진이 공정을 추적할 수 있도록 의존 그래프(Dependency graph)를 재컴파일합니다. 이를 수행하지 않으면 추가된 스테이지는 존재하지 않는 것과 같습니다.

합성 과정에서 누락된 사항이 있으면 기록에 남으며, 진단 명령어가 이를 출력합니다. 실패를 묵인하지 않는 설계입니다.

AI-DLC는 5종류의 배포물을 생성하지만, 플러그인 또한 각각의 형태로 투영됩니다 (Kiro는 CLI와 IDE 두 가지를 산정합니다).

Claude와 Codex에는 원래 플러그인 메커니즘이 있으므로, 그 방식에 따른 형태로 출력됩니다. Kiro는 폴더를 배치하고 명시적으로 합성을 실행하는 방식입니다.

플러그인을 실행해도 되는지에 대한 검증도 각 하네스(Harness)의 메커니즘에 맡깁니다. AI-DLC 고유의 검증은 따로 두지 않습니다. 해당 환경의 방식을 따릅니다.

확장 메커니즘을 도입하면 사용하지 않는 사람에게도 영향을 주기 쉽습니다. 이 부분은 그렇게 되지 않도록 설계되었습니다.

플러그인이 하나도 없다면, core의 출력은 바이트 단위로 동일합니다. 스테이지의 프론트매터(Frontmatter)에 추가된 필드는 core의 스테이지에서 전혀 사용하지 않으므로, 컴파일 결과가 변하지 않습니다.

나아가, 배포물 생성에는 차이 검출(Drift detection) 기능이 내장되어 있습니다. 다시 생성한 결과가 기존 것과 단 1바이트라도 다르면 실패로 처리됩니다. 플러그인 측의 투영 또한 동일한 검사 대상입니다. 게다가 플러그인 측의 생성은 core의 배포물 디렉토리를 전혀 수정하지 않습니다.

설치 측에도 선택권이 있습니다. 어떤 플러그인의 내용을 사용자에게 보여줄지 선택할 수 있습니다.

여기서, core 자신은 암묵적인 플러그인으로 취급됩니다. 이름은 aidlc이며, 선택에서 제외할 수도 있습니다. 제외하면 선택된 플러그인이 가져오는 명령어와 스코프(Scope)만 보이는 환경이 됩니다 (워크스페이스를 준비하는 초기화 단계는 선택 여부와 관계없이 항상 유지됩니다).

"core가 있고 그 주변에 확장이 있는" 것이 아니라, core와 확장 모두 동일한 메커니즘으로 취급됩니다.

참조 구현(Reference implementation)은 모든 종류를 사용하고 있지만, 기구(Mechanism)로서 아직 완성되지 않은 부분이 있습니다. 1차 자료에서 '미뤄둔 과제'로 명시하고 있는 것은 조건식에 의한 활성화 평가, 의존하는 스테이지 지정의 합산 메커니즘, 배포 방식 및 고정 버전 관리 등입니다.

확장 지점을 먼저 결정하고, 구현을 단계적으로 채워나가는 형태입니다.

플러그인 메커니즘이 변화시킨 것은, '32개 스테이지', '9종류의 스코프'가 고정된 수치가 아니게 되었다는 점입니다. 연재에 등장하는 수치는 모두 출하 시점의 것이며, 설치 환경에 따라 늘어날 수 있습니다.

설계 측면에서 눈에 띄는 점은 두 가지입니다.

첫 번째는, 기존 스테이지를 수정하지 않고 더한다는 선택입니다. core의 파일은 그대로 둔 채, 선언된 추가 사항을 합성 시에 혼합합니다. 따라서 core의 업데이트와 플러그인의 업데이트가 충돌하지 않습니다.

두 번째는, core 자신을 암묵적인 플러그인으로 취급했다는 점입니다. 특별 대우를 없애고 동일한 메커니즘에 태웠기 때문에, 'core만 있는 경우'와 '플러그인만 있는 경우'를 모두 동일한 기구로 표현할 수 있습니다. 확장 메커니즘을 나중에 추가할 때는 본체를 특별 대우로 남겨둔 채 외부에 붙이는 것이 구현하기 편하지만, 그렇게 하지 않은 형태입니다.

이전 글: 협업의 토폴로지 (Topology of Collaboration)

다음 글: 에이전트 계층 (Agent Hierarchy)

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