AI로 풀어보는 AI-DLC v2: 워킹 스켈레톤 (Walking Skeleton)

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

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

참조한 버전— Claude Code 구현을 대상으로, 2026년 6월 시점의 v2.1.3 (커밋 c95070e, core/)을 참조하고 있습니다. Kiro・Codex 구현은 대상에서 제외되며, 기술 내용이 다를 수 있습니다. OSS 구현은 업데이트가 계속되고 있으므로, 최신 상태는 공식 리포지토리를 확인해 주시기 바랍니다.

워킹 스켈레톤 (Walking Skeleton)은 Construction (구축) 페이즈의 첫 번째 Bolt를 모든 아키텍처 계층을 관통하는 최소한의 End-to-End 슬라이스로 만드는 절차입니다. 기능을 추가하기 전에, 표시(Display)부터 데이터(Data)까지 전 계층을 얇게 세로로 관통하는 구현을 먼저 한 줄 통과시켜, 각 계층의 연결점(배선·결합점)이 올바르게 연결되는지 확인합니다.

AI-DLC v2에서는 이것이 설계의 마음가짐에 그치지 않고, 워크플로우에組み込まれた(組み込まれた, 포함된) 절차가 되어 있습니다. 첫 번째 Bolt는 자율 모드(Autonomous mode) 설정과 관계없이 반드시 사람의 승인 게이트(Approval gate)를 거치며, 그 직후에 남은 진행 방식을 사람이 선택합니다. 본 기사에서는 첫 번째 Bolt가 언제 계획되고, 어떻게 판정되며, 어디에서 사람의 판단이 들어가는지를 풀어냅니다.

새로운 시스템을 계층별로 다 만든 다음 마지막에 한꺼번에 결합하면, 배선 문제는 종반부까지 드러나지 않습니다. 워킹 스켈레톤은 이 순서를 반대로 합니다. 얇더라도 끝에서 끝까지 관통하는 구현을 처음에 한 줄 통과시켜, 모든 결합점 (integration point)이 맞물리는 것을 먼저 확인합니다. 골격이 서서 걸을 수 있는 것을 확인한 뒤에, 살을 붙이는 기능을 후속 Bolt를 통해 추가해 나갑니다. 사고방식의 출처는 Alistair Cockburn의 『Crystal Clear』입니다.

여기서 말하는 Bolt (구축의 실행 단위)란, Construction의 설계부터 코드 생성까지의 스테이지 (3.1~3.5)를 작업 단위 (Unit of Work)별로 1회 통과시키는 배포 가능한 덩어리입니다. 빌드·테스트 (3.6)와 CI 파이프라인 (3.7)은 Bolt마다 실행되는 것이 아니라, 모든 Bolt가 끝난 뒤에 한 번만 실행됩니다. 첫 번째 Bolt가 이 워킹 스켈레톤에 해당하며, 이 단계만은 자율 모드 설정과 관계없이 반드시 사람의 승인을 거치며, 승인 직후에 "여기서부터 어떻게 실행할지"를 사람이 선택합니다.

어떤 Bolt를 워킹 스켈레톤으로 할지는 Inception의 **2.8 데리버리 플래닝 (Delivery Planning)**에서 결정됩니다. 여기서 Bolt의 실행 순서가 짜이며, 가장 처음에 배치할 Bolt가 골격으로서 표시됩니다.

Bolt를 어떤 순서로 만들지는 의존 관계를 충족하는 범위 내에서, 가치와 리스크의 우선순위에 따라 결정됩니다. 2.7이 의존 관계의 DAG (각 Bolt의 전후 관계를 화살표로 연결한 도표)를 만들고, 2.8은 그 경로를 선택합니다. 단순히 의존 관계의 전후로만 기계적으로 나열되는 순서 (Topological order)가 아니라, 어떤 가치와 리스크를 먼저 마주할 것인가라는, DAG만으로는 도출할 수 없는 사람의 가치 판단이기 때문입니다. 순서 정하기의 휴리스틱 (Heuristic)은 여러 가지가 있으며, 그중 하나가 walking-skeleton-first입니다 (그 외에 risk-first, value-first, WSJF (Weighted Shortest Job First), 그리고 이들의 hybrid 방식이 있습니다).

결정 사항은 데리버리 플래닝의 산출물에 남습니다. 스켈레톤과 순서 정하기에 직접적인 영향을 주는 것은 다음 표의 상위 2개입니다.

산출물	내용
bolt-plan.md	Bolt의 순서. 스켈레톤에 해당하는 Bolt에는 골격 마커가 붙으며, Definition of Done과 확신 가설을 병기한다
risk-and-sequencing-rationale.md	왜 그 순서인지에 대한 근거. DAG의 토폴로지컬 순서(Topological order)에서 벗어나는 경우에는 반드시 그 정당성을 기술한다
team-allocation.md	어떤 Bolt를 어떤 모브 (Mob, 공동으로 담당하는 소수 팀)가 담당할 것인가
external-dependency-map.md	외부 의존성 지도

여기서 말하는 확신 가설 (confidence hypothesis)이란, 해당 Bolt를 출하했을 때 검증 또는 반증할 수 있는 관측 가능한 동작을 의미합니다 (예: "1k-rps 부하에서 레이턴시 200ms 미만"). 골격 마커가 붙은 Bolt에는 무엇을 증명하기 위한 1개인지가 이러한 형태로 첨부됩니다.

Construction 단계에 진입하면, 첫 번째 Bolt (워킹 스켈레톤, Walking Skeleton)에는 특별한 승인 게이트 (approval gate)가 배치됩니다. 이 게이트는 자율 모드 (autonomy mode) 설정과 관계없이, 첫 번째 Bolt에서는 반드시 사람의 승인을 요구합니다. 후속 Bolt를 자율적으로 실행하도록 설정했더라도, 첫 번째 1개만큼은 반드시 사람이 확인합니다.

게이트는 해당 Bolt의 설계 산출물과 생성된 코드를 모두 대상으로 합니다. 살을 붙이기 시작하기 전에, 골격의 형태를 사람의 눈으로 확인해 두는 것입니다. 참고로 CI 등의 자동 실행 (--test-run)에서는 표준 Test-Run 오버라이드 (override)에 따라 이 게이트도 자동으로 승인됩니다. 게이트에서의 반려(rejection)나 "현 상태로 승인"과 같은 판단 메커니즘은 별도 기사 「승인 게이트」에서 다룹니다.

워킹 스켈레톤의 게이트가 승인된 직후에 딱 한 번, 컨덕터 (Conductor)는 "남은 Bolt를 어떻게 실행할 것인가"를 묻습니다. 답변은 자율 모드 (autonomy mode)로서 aidlc-state.md의 Construction Autonomy Mode에 기록되며, 이후의 진행 방식을 결정합니다. 선택지는 두 가지입니다.

• autonomous (자율) — 남은 Bolt를 게이트 없이 실행함
• gated (매 Bolt 승인) — Bolt 단위로 (병렬 배치라면 배치 단위로) 승인 게이트를 둠

gated라면 스켈레톤 이후의 Bolt에도 게이트가 나타나며, autonomous라면 게이트가 생략됩니다. 단, 코드 생성에 실패했을 때는 모드와 관계없이 반드시 정지하여 사람에게 문의합니다 (halt-and-ask). autonomous 모드에서도 예외적으로 사람에게 확인을 요청하는 유일한 케이스입니다.

첫 번째 1개는 반드시 사람이 확인하며, 그 경험을 바탕으로 어디까지 자율에 맡길지를 선택합니다. 게이트와 선택을 직후에 결합해 놓은 이유는 이 이중 구조를 성립시키기 위해서입니다. autonomous 모드에서 독립된 Bolt를 병렬로 실행하는 메커니즘은 별도 기사 「병렬 실행」에서, 어디까지 자율에 가깝게 가져갈 것인가라는 운영상의 판단은 별도 기사 「도입 판단」에서 다룹니다.

첫 번째 Bolt를 스켈레톤으로 할지 여부는 코드만으로는 결정할 수 없습니다. 이는 "이 팀은 워킹 스켈레톤을 수행할 것인가"라는 스켈레톤 방침 (skeleton stance)에 속하는 판단이기 때문입니다. stance는 on / off / scope-dependent의 세 가지 값 중 하나를 가지며, 상태 파일인 aidlc-state.md의 Skeleton Stance 필드에 기록됩니다. 팀이 자유 기술로 작성한 관례를 시스템이 다룰 수 있도록 이 세 가지 값으로 대응시킨 것입니다.

판정 흐름은 다음과 같습니다.

• 엔진은 첫 번째 Bolt의 지시 (directive)에 불리언 (boolean) 값을 넣지 않고, gate: "unresolved"를 붙여 판단을 보류한다. 파서 (parser) 단계에서는 결정할 수 없음을 명시한다.
• 컨덕터가 ## Walking Skeleton 기술을 해결 순서 memory/org.md → memory/team.md → memory/project.md (가장 구체적인 비어 있지 않은 기술이 우선함)에 따라 읽고 stance를 분류한다. "always", "그린필드(greenfield)에서는 매번"은 on, "never"는 off, "미지정" 또는 "team 계층이 비어 있음"은 scope-dependent (스코프별 기본값으로 폴백 (fallback))로 분류한다.
• report --skeleton-stance <on|off|scope-dependent>를 통해 엔진에 반환한다. 엔진은 이를 기록하고, 확정된 게이트가 포함된 동일한 Bolt를 재발행한다.

stance의 판정은 결정론적 (deterministic)으로 동작하는 엔진이 유일하게 스스로 결정하지 않고 컨덕터에게 판단을 위임하는 지점입니다. 엔진과 컨덕터의 역할 분담 관점에서의 위치 설정은 별도 기사 「진행의 핵심」에서 다룹니다.

scope-dependent일 때 사용하는 스코프별 기본값 (memory/org.md)은 다음과 같습니다.

스코프	기본 stance
그린필드 (Greenfield) 계열 스코프 (mvp / enterprise / feature / poc / workshop / infra)	스켈레톤을 가장 먼저 실행 (단독 또는 게이트 포함)
기존 코드에 대한 증분 작업 (bugfix / refactor / security-patch)	스켈레톤 절차를 스킵 (첫 번째 Bolt도 일반적인 Bolt로 실행)

증분 작업에서 스킵하는 이유는 처음부터 구축할 대상이 없기 때문입니다. 기존의 배선(wiring)은 이미 작동하고 있으므로, 골격(skeleton)을 다시 통과시킬 의미가 없습니다.

방침이 충돌할 때는 practices (팀이 정한 작법. 후술)가 우선합니다. bolt-plan.md가 있는 Bolt에 골격 마커(skeleton marker)가 붙어 있더라도, 팀의 practices가 현재 스코프에서 skeleton-off라고 규정하고 있다면, 컨덕터(conductor)는 마커가 아닌 practices로부터 stance를 판정하며, 이를 PRACTICES_OVERRIDE로 감사 이벤트(audit event)에 기록합니다. practices는 팀의 지속적인 목소리인 반면, bolt-plan의 마커는 단일 워크플로우에 대한 해석에 불과하기 때문입니다.

참고로 스코프별 기본값은 소스 코드 내에서 기술이 일치하지 않습니다. conductor.md의 산문에서는 infra를 스켈레톤 측에 포함하지 않지만, 코드 orchestrate.ts는 infra를 포함합니다. 위 표는 코드를 일차적 근거로 하여 infra를 그린필드(Greenfield) 측에 배치했습니다.

판정의 재료가 되는 ## Walking Skeleton 기술 자체는 Inception의 practices-discovery (작법 발견) 단계에서 채워집니다. 이는 팀의 5가지 실천 영역(Way of Working / Walking Skeleton / Testing Posture / Deployment / Code Style) 중 하나로, 승인 게이트(approval gate)를 거쳐 memory/team.md와 memory/project.md에 기록됩니다.

워킹 스켈레톤(Walking Skeleton)의 stance는 테스트 자세(testing posture)나 코드 스타일과 달리 코드만으로는 거의 읽어낼 수 없습니다 (팀의 판단 사항이기 때문입니다). 따라서 기존 코드베이스를 다루는 경우에도, 증거로 채워지지 않는 간극(gap)으로서 명시적으로 질문되는 항목이 됩니다. 브라운필드(Brownfield)에서의 취급은 별도 기사인 「브라운필드」에서 다룹니다.

파일	내용
aidlc-common/stages/inception/delivery-planning.md	딜리버리 플래닝 (Delivery Planning). 워킹 스켈레톤의 정의, 경제적인 Bolt 순서, bolt-plan.md의 마커와 확신 가설 (confidence hypothesis)
aidlc-common/protocols/stage-protocol.md	스테이지 프로토콜 (Stage Protocol). 워킹 스켈레톤 게이트, 자율 모드 선택, halt-and-ask
aidlc-common/conductor.md	컨덕터의 행동 규범. gate: "unresolved" 분류 절차와 PRACTICES_OVERRIDE
aidlc-common/stages/inception/practices-discovery.md	작법 발견 (Practices Discovery). ## Walking Skeleton stance 수집 및 승인 게이트
memory/org.md	조직 수준의 기본값. 스코프별 stance
knowledge/aidlc-delivery-agent/workflow-planning-guide.md	딜리버리 에이전트 계획 가이드. walking-skeleton-first 휴리스틱 (Cockburn)

이전 기사: 결과물의 흐름

다음 기사: 브라운필드

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