본 기사의 위치— 본 기사는 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의 각 스테이지에는 주 담당자 (Lead)와 보조 (Support)가 할당됩니다. 그렇다면 이 두 존재는 스테이지가 진행되는 동안 실제로 어떻게 협업할까요? 기존에는 이 질문에 대한 답이 없었습니다. 보조는 '컨덕터 (Conductor)가 자신 내부에서 맡는 관점'이었기에, 독립된 참여자가 아니었기 때문입니다.

지금, 그것을 결정하는 필드가 있습니다. 스테이지의 프론트매터 (Frontmatter)에 있는 mode로, 누가 누구와 대화할 것인가라는 협업의 형태 (토폴로지, Topology)를 가리킵니다. 실제로 작동하는 것은 4가지입니다. 모든 역할을 혼자서 맡는 inline, 초안을 둘러싸고 검토하는 subagent, 순차적으로 손을 대는 pipeline, 일제히 의견을 내는 mob입니다 (스키마는 agent-team을 하나 더 수용하지만, 미래를 위한 예약이며 런타임 (Runtime)을 가지지는 않습니다).

본 기사에서는 이 4가지가 무엇을 바꾸는지, 협업의 기록이 왜 파일로 남는지, 그리고 의견이 갈렸을 때 누가 결정하는지를 풀어냅니다.

불변의 역할과 가변적인 관계

먼저 변하지 않는 부분을 정리합니다. 역할은 4가지 토폴로지 모두에서 동일합니다.

• 주 담당자… 해당 스테이지의 produces 성과물을 소유함
• 보조… 자신의 작업을 작성하는 참여자
• 리뷰어 (Reviewer)… 종료 후 외부에서 검증함 (선언된 스테이지만 해당)

그리고 상호작용은 모두 컨덕터를 경유합니다. 참여자 간의 상호작용은 모두 컨덕터가 수행한 위임과, 컨덕터가 가져온 응답으로 이루어집니다. 에이전트 (Agent)가 서로를 호출하는 일은 없습니다. 위임하는 것은 컨덕터뿐입니다.

변하는 것은 관계를 맺는 방식입니다. 보조가 독립적으로 움직이는지, 누가 누구의 작업을 볼 수 있는지, 의견이 갈리면 어떻게 할 것인지. mode가 그 부분을 결정합니다.

4가지 형태

32개 스테이지 중 28개는 inline입니다. 지배적인 것은 기존 방식이며, 나머지 4개가 실제로 다른 에이전트를 기동합니다.

inline

컨덕터가 주 담당자와 보조의 페르소나 (Persona)를 자신의 문맥에 읽어 들여, 주 담당자의 출력을 먼저 만든 후, 거기에 각 보조의 관점을 겹쳐서 통합합니다. 보조를 기동해서는 안 된다고 명시되어 있습니다. 기동은 다른 3가지를 위해 남겨두었습니다.

subagent

허브 앤 스포크 방식입니다. 먼저 주 담당자를 기동하여 초안을 작성하게 하고, 다음으로 각 보조를 해당 초안에 대해 기동합니다. 이때 보조끼리는 서로를 보지 못합니다. 특정 보조에게 전달하는 지시에는 다른 보조의 작업이 포함되지 않습니다. 마지막에 다시 한번 주 담당자를 기동하여 통합하게 합니다.

작법(Convention) 발견 스테이지가 이 형태입니다. 파이프라인 배포 (Pipeline Deploy)가 초안을 작성하고, 품질 (Quality) · 개발자 (Developer) · DevSecOps가 서로 보이지 않는 상태에서 검토하며, 사람과의 면담으로 판단을 채우고, 주 담당자가 통합합니다.

pipeline

체인 방식입니다. 주 담당자를 선두로 하여, 보조가 선언된 순서대로 하나씩 움직이며, 각 단계가 상류의 작업을 모두 확인합니다. 단계에서 성과물을 직접 수정해도 좋으며, 직렬 구조이므로 충돌이 발생하지 않습니다. 마지막 단계가 성과물을 완성합니다.

리버스 엔지니어링 (Reverse Engineering)이 바로 이 형태입니다. 개발자가 스캔하고, 아키텍트가 통합하여 작성하는 2단계의 사슬(Chain)로, 이전부터 존재하던 구조에 이름이 붙은 것입니다. 순서 그 자체가 의미를 갖는 형태입니다.

mob

하나의 방으로 간주한 형태로, 경계가 있는 라운드(Round)로 진행됩니다. 라운드 1에서는 모든 보조(Assistant)를 주 담당자의 초안에 대해 병렬로 기동하며, 이때 서로를 보지 않습니다. 각자가 자신의 작업을 작성하고, 주 담당자가 이를 통합합니다.

유저 스토리 (User Story)가 이 형태입니다. 프로덕트가 주 담당이며, 디자인·개발자·품질 부문이 병렬적으로 의견을 냅니다.

각자가 작성하는 기록

subagent와 mob에서는, 기동된 보조가 자신의 파일을 작성합니다 (pipeline은 후술하는 바와 같이 예외입니다). 저장 위치는 정해져 있습니다.

<기록 디렉토리>/<페이즈>/<스테이지>/contributions/<에이전트 이름>.md

에이전트마다 별도의 파일이므로, 병렬로 기동해도 충돌이 발생하지 않습니다. 내용도 정해져 있어, 첫 번째 줄에는 작성자를 나타내는 표식, 이어서 통합 가능한 형태로 작성된 내용, 그리고 입장 표명(동의 또는 이의, 각각 한 줄의 이유 포함)이 나열됩니다.

성과물을 편집하는 것은 주 담당뿐입니다 (pipeline은 예외로, 사슬의 각 단계가 직접 다시 씁니다). 실제 협업 현장에서 각자가 자신의 메모를 작성하고, 정리하는 역할이 본문에 반영하는 형태에 가깝습니다.

그리고 이 파일은 스테이지의 기록의 일부로 남습니다. 이의가 응답 텍스트 속에서 흘러가 사라지는 것이 아니라, 디스크에 남습니다.

pipeline만은 contribution 파일을 요구하지 않습니다. 사슬이 성과물에 가한 편집 그 자체가 협업의 기록이 되기 때문입니다.

이의 분류

mob에는 의견이 갈렸을 때의 절차가 있습니다. 라운드 1에서 남은 이의를 종류별로 분류합니다.

판단의 문제(양측의 입장이 모두 타당한 경우. 범위·리스크를 취하는 방식·우선순위 등)는 스테이지 도중에 사람에게 묻습니다. 구조화된 질문으로 제시하고, 사람의 재결을 받은 후 통합을 계속합니다. 승인 단계에서 사후에 승인하는 것이 아니라, 사람도 방의 참여자로 취급한다는 사고방식입니다.

지식의 문제(상세 내용을 아는 자가 결론을 낼 수 있는 경우)는 라운드 2로 넘깁니다. 이의를 제기한 에이전트에게 수정된 초안과 다른 참여자의 입장을 전달하여, 이의를 철회할지 유지할지 확인합니다. 라운드는 최대 2개입니다.

분류를 거친 후에도 유지된 이의는 승인 게이트(Approval Gate)의 완료 보고에 축자적으로 인용됩니다. 사람이 판단할 때 반대 의견이 그대로 눈에 들어오게 하기 위함입니다.

사람 없이 돌아가는 자율 모드(Autonomous Mode) 구축 중에는 도중에 사람에게 묻는 절차를 건너뜁니다. 이의는 기록되며, 마지막 배치의 게이트에서 표면화됩니다. 무인 루프를 멈추지 않기 위해서입니다.

병렬로 실행할 수 없는 환경에서의 약속

모든 하네스(Harness)가 병렬 기동을 할 수 있는 것은 아닙니다. 불가능한 환경에서는 subagent의 스포크(Spoke)도 mob의 라운드 1도 순차적으로 실행됩니다.

하지만 전달하는 지시는 바꾸지 않습니다. 각 참여자가 볼 수 있는 것은 토폴로지(Topology)가 허용한 범위 내에 머물며, 옆의 작업이 보이도록 하지는 않습니다.

불변하는 것은 '누가 무엇을 볼 수 있는가'라는 약속이지, 동시에 움직이는 것이 아니다라고 명시되어 있습니다. 병렬성은 구현상의 편의일 뿐, 설계의 본질은 아닙니다.

완료의 증거로서의 기록

contribution 파일에는 또 다른 역할이 있습니다. 완료에 대한 결정론적인 증거입니다.

mob과 보조를 선언한 subagent의 스테이지에서는, 선언된 보조의 파일이 누락되었거나 첫 번째 줄의 표식이 없는 경우 해당 스테이지를 완료할 수 없습니다. 정상적으로 실행되었음에도 파일을 분실한 경우를 위한 탈출구로서, 환경 변수로 제외할 수 있습니다.

이는 품질을 판정하는 것이 아닙니다. 내용의 좋고 나쁨은 보지 않고,

mode

가 바꾼 것은 에이전트의 편성이 아니라 **관계의 형성 방식 (Topology)**입니다. 역할은 4가지 토폴로지 (Topology) 모두에서 동일하며, 상호작용이 컨덕터 (Conductor)를 경유한다는 점도 변하지 않습니다.

그중에서도 눈길을 끄는 것은 협업의 기록을 파일로 남겼다는 점입니다. 누가 무엇을 작성했고, 누가 어디에서 이의를 제기했는지가 디스크에 남습니다. 응답 텍스트 안에서 사라지지 않으므로 나중에 추적할 수 있습니다. 게다가 그 파일이 그대로 완료의 증거로서 기계적으로 검사됩니다. 기록을 위해 만든 것이 검증에도 사용되는 형태입니다.

또 다른 하나는 의견이 갈렸을 때 사람을 방(Room)으로 들여보냈다는 것입니다. 판단의 문제는 스테이지 (Stage) 도중에 사람에게 묻고, 지식의 문제만을 한 라운드 더 돌립니다. 남은 이의는 승인 단계로 축자적으로(verbatim) 전달됩니다. 사람을 마지막 승인자로만 머물게 하지 않고, 토론의 참여자로 다루도록 설계되어 있습니다.

참조원 (References)

관련 기사

이전 기사: 병렬 실행

다음 기사: 플러그인 기구

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

Discussion