본 기사의 위치— 본 기사는 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의 각 기구는 문서나 개념도 상에서는 정연하게 작동합니다. 하지만 구현(core/) 단계로 들어가 보면, "조언에 그치고 멈추지 않는 검증", "형식은 있으나 아직 발행되지 않는 지시", "코멘트가 실체에 따라가지 못하는 부분"과 같은 격차가 보입니다. 이것들은 결함에 대한 고발이 아니라, 빠르게 움직이는 구현에 주석·형식·문서가 따라가는 과정 중에 있는 현재의 한계입니다.

본 기사는 도입을 검토하는 입장을 위해, 각 기구의 작동 방식 자체는 개별 기사에 맡기고, 그 "한계·주의점"의 측면만을 출처와 함께 일망적으로 살펴봅니다. 어디까지를 사양(specification)으로서 신뢰할 수 있고, 어디서부터가 미래의 영역인지. 과장하거나 부풀리지 않고, 소스를 직접 확인하며 읽어 내려갑니다.

조언에 그치는 검증과 유일한 정지점

"검증 게이트가 자동으로 차단(block)한다"는 이해는 구현상 성립하지 않습니다. 워크플로우를 멈추는 유일한 기구는 사람의 승인 게이트(approval gate)이며, 그 외의 "검증"은 모두 조언(advisory)입니다.

멈추지 않는 센서

4개의 센서는 모두 default_severity: advisory입니다. 발화 후크(fire hook)는 항상 exit 0을 반환하는 계약으로 되어 있어 (aidlc-sensor-fire.ts "always exit 0"), 잘못된 입력이나 파일 부재도 조용히 통과시킵니다. 코멘트 자체에 "Blocking semantics defer to the future ralph driver"라고 적혀 있듯이, 차단 기구는 애초에 미구현 상태이며 향후 드라이버 구현에 맡겨져 있습니다.

판정 로직 또한 불확실한 것은 PASSED로 판정합니다. 진리표(aidlc-sensor.ts의 코멘트)는 8개(a/0/b/c/d/e/f/default)가 있으며, 마지막 default는 "도달하지 않아야 함(should be unreachable)"이라고 주석이 달린 안전망입니다. 실제로 도달하는 7개 행 중 FAILED가 되는 것은 단 1개뿐입니다. 바로 "스크립트가 정상 종료(exit 0)하고, 동시에 pass === false"인 경우(c)입니다. 타임아웃 초과(a)는 FAILED가 아니라 제3의 결과인 BUDGET_OVERRIDE가 되며, spawn 실패·도구 부재(exit 127)·잘못된 JSON·예상치 못한 종료 코드는 모두 PASSED로 판정됩니다 ("Sensor outcomes are advisory").

센서가 PASSED를 반환한다고 해서 반드시 "문제가 없다"는 뜻은 아닙니다. "문제를 일으킬 근거를 찾지 못했다"에 가까운 상태입니다. 자세한 메커니즘은 별도 기사 「센서」에서 다룹니다.

멈추지 않는 리뷰어

리뷰어(Reviewer)는 결과물에 READY / NOT-READY 판정을 내리지만, NOT-READY 상태에서도 워크플로우는 멈추지 않습니다. 왕복 횟수 상한에 도달했음에도 여전히 NOT-READY라면, 미결된 지적 사항을 첨부하여 그대로 승인 게이트로 진행합니다 ("Proceed to approval gate with unresolved findings noted"). 프로토콜 자체에서도 "Does not block the workflow — the human always gets final say at the gate"라고 명시하고 있습니다. 학습 게이트(Learning gate, 스테이지 완료 시 학습 내용을 기록하는 조언적인 공정) 또한 마찬가지로 "advisory and additive — it never blocks the gate"입니다. 즉, 기계적인 검증(센서·리뷰어·학습 게이트)은 모두 문(gate)이 아니라 조언이며, 멈출지 여부에 대한 판단은 마지막에 사람에게 집중됩니다. 자세한 내용은 별도 기사 「리뷰어」, 「승인 게이트」에서 다룹니다.

합격/불합격을 가지지 않는 페이즈 경계 검증

감사 이벤트 PHASE_VERIFIED

는 페이즈 경계(Phase boundary)를 넘을 때마다 무조건 발행되며, 필드는 `

의 코멘트나 개수 표를 확정된 값으로 맹신하지 말고, 필요하다면 실체(파일 수·프론트매터 (Frontmatter))를 세어서 확인하는 것이 안전합니다. 스코프 (Scope)의 내역은 별도 기사 「스코프 (Scope)」에서 다룹니다.

주의점 읽는 법

여기서 언급한 한계들은 모두 결함을 고발하는 것이 아닙니다. 빠르게 움직이는 구현과, 이를 따라잡는 과정에 있는 코멘트·타입·문서 사이의 현재 격차입니다. 도입 판단 실무에 적용하면 다음과 같이 읽을 수 있습니다.

• 조언에 그치는 검증(센서·리뷰어 (Reviewer))에 「자동으로 차단하는 문」을 기대하지 마십시오. 차단하는 것은 승인 게이트 (Approval gate)뿐입니다.
• 타입으로서 존재하는 기능 (dispatch-subagent / present-gate)을 「사용 가능하다」고 전제하지 마십시오.
• core/의 코멘트나 개수의 산문을 확정 사양으로 맹신하지 말고, 필요하다면 실체를 세십시오.

도입 여부 자체를 어떻게 구성할지는 별도 기사 「도입 판단」에서, 전체적인 지도는 별도 기사 「개념 맵 (Concept map)」에서 다룹니다.

참조 원천

관련 기사

이전 기사: 상태와 감사

다음 기사: 도입 판단

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

Discussion