레벨 2를 시작하기 전에 AI-DLC v2의 뼈대(페이즈·스테이지·스코프), 인텐트·유닛·볼트, 사람의 역할, 실패할 때 되돌아가는 루프를 정리하고, GitHub 스펙킷(spec-kit)과 무엇이 같고 다른지 비교합니다.
레벨 1과 레벨 2#
레벨 1(1~4장)은 가장 짧은 poc 스코프로 동작 여부를 빠르게 확인했습니다. 아키텍처는 코드 생성 계획서 안에서 한꺼번에 정해졌고, 유저 스토리·설계 문서·유닛 분해는 없었습니다. 레벨 2는 같은 요청을 classic 스코프로 다시 만들며, 스펙 → 설계 → 시험 → 코드가 문서로 이어지는 과정을 살펴봅니다.
레벨 1 (poc) |
레벨 2 (classic) |
|
|---|---|---|
| 스테이지 | 8개: 초기화 3 → 의도 정리 → 요구사항 → 코드 생성 → 빌드와 테스트 | 18개: 초기화 3 → 팀 규칙 → 요구사항 → 유저 스토리 → 화면 → 도메인 설계 → 유닛 분해 → API 계약 → 볼트 계획 → 유닛마다 기능 설계·NFR·인프라 설계·코드 생성 → 빌드와 테스트 |
| 아키텍처가 정해지는 곳 | 코드 생성 계획서 안에서 한꺼번에 | 도메인 설계·유닛·계약 스테이지가 문서로 따로, 단계마다 승인 |
| 계획 승인 | 꺼짐 | 유닛마다 코드 계획을 승인 |
| 시험 | 기본 test-after, 하한 없음 | 팀 규칙에서 정함(이번엔 TDD), 커버리지 80% 하한 |
| 구현 단위 | 전체를 한 번에 | 유닛(서비스·화면) 단위로 차례대로 |
classic은 버전 1이 아닙니다. 레벨 2도 AI-DLC v2(2.11.2)입니다. classic은 v2 안의 스코프 이름이고, v1처럼 Inception·Construction 스테이지마다 사람이 승인하는 방식이라 붙은 이름입니다.
페이즈·스테이지·스코프#
AI-DLC v2는 다섯 페이즈, 33개 스테이지로 구성됩니다.
| 페이즈 | 스테이지 |
|---|---|
| 0 초기화 | 0.1 작업 기록 · 0.2 프로젝트 판별(새 프로젝트/기존 코드) · 0.3 상태 파일 |
| 1 Ideation | 1.1 의도 정리 · 1.2 시장 조사 · 1.3 타당성 · 1.4 범위 · 1.5 팀 구성 · 1.6 스케치 · 1.7 승인과 인계 |
| 2 Inception | 2.1 역설계(기존 코드) · 2.2 팀 규칙 · 2.3 요구사항 · 2.4 유저 스토리 · 2.5 화면 · 2.6 도메인 설계 · 2.7 유닛 분해 · 2.8 계약 설계 · 2.9 볼트 계획 |
| 3 Construction | 3.1 기능 설계 · 3.2 NFR 요구사항 · 3.3 NFR 설계 · 3.4 인프라 설계 · 3.5 코드 생성 · 3.6 빌드와 테스트 · 3.7 CI |
| 4 Operation | 4.1 배포 파이프라인 · 4.2 환경 준비 · 4.3 배포 · 4.4 관측 · 4.5 장애 대응 · 4.6 성능 검증 · 4.7 피드백 |
스코프는 이 가운데 실행할 스테이지를 고른 묶음입니다. 11개가 있으며, 상위 스코프가 하위 스코프를 모두 포함하지는 않습니다. 작업 종류에 따라 경로가 다릅니다(숫자는 초기화 3개를 포함한 값).
| 스코프 | 스테이지 | 무엇을 거치나 | 쓰는 곳 |
|---|---|---|---|
| poc | 8 | 의도 정리 → 요구사항 → 코드 → 테스트 | 되는지만 빨리 보기 (레벨 1) |
| bugfix | 9 | 요구사항 → 코드 → 테스트 → 배포 2단계 | 버그를 고쳐 내보내기 |
| express | 10 | 요구사항 → 코드 → 테스트 → (배포) | 설계 없는 최단 경로 |
| refactor · security-patch | 10 | 기존 코드 분석 + 코드·테스트·배포 | 정리, CVE 대응 |
| infra | 13 | 요구사항 + NFR·인프라 설계 + 배포·운영 | 인프라 변경 |
| classic | 18 | 팀 규칙 → 요구사항 → 스토리 → 화면 → 도메인 설계 → 유닛 → 계약 → 볼트 계획 → 유닛별 설계·코드 → 테스트 | v1식 설계 중심 (레벨 2) |
| mvp | 23 | classic + 아이디어 단계 일부(의도·타당성·범위·스케치) + CI | 첫 제품 |
| workshop | 26 | classic + CI + 운영 7단계 | 교육 |
| feature · enterprise | 33 | 전부. enterprise는 문서 깊이가 가장 깊음 | 실제 기능, 규제 업무 |
크기로 보면 대략 poc < classic < mvp < workshop < feature입니다. 하지만 bugfix에는 classic에 없는 배포 단계가 있고, poc에는 classic에 없는 의도 정리가 있습니다.
스코프 외에 따로 정할 항목이 둘 더 있습니다.
- 깊이(depth): 문서를 얼마나 자세히 쓸지 정합니다. minimal(핵심만 1~2쪽) / standard / comprehensive. 레벨 2는
--depth minimal로 짧게 썼습니다. - 시험 방식: TDD, BDD, ATDD, test-after. 스코프가 아니라 팀 규칙(
team.md의 Testing Posture)에서 정하고, 어느 스코프에서나 적용합니다.
인텐트 · 유닛 · 볼트#
| 개념 | 뜻 | 이 실습에서 |
|---|---|---|
| 인텐트(Intent) | 작업 하나. 요청 한 번이 인텐트 하나가 되고 기록 폴더가 생깁니다 | aidlc/spaces/default/intents/261105-voice-parking/ |
| 유닛(Unit of Work) | 따로 설계·구현·검증할 수 있는 단위. 의존 관계를 DAG로 적습니다 | 레벨 2에서 5개: search·reservation·payment 서비스, Vue 화면, 로컬 실행 스크립트 |
| 볼트(Bolt) | 유닛 하나 이상을 묶은 전달 단위. 완료 기준(Definition of Done)과 순서·위험을 함께 적습니다 | bolt-plan.md (2.9 볼트 계획) |
실행 순서는 볼트 계획이 아니라 유닛 의존 DAG를 따릅니다. 기본은 유닛을 하나씩 끝내는 방식(unit-major, 직렬)이고, 원하면 서로 의존하지 않는 유닛을 동시에 만들 수 있습니다(stage-major + swarm). 팀이 유닛을 나눠 맡을 때는 볼트마다 bolt-<id>_<유닛> 워크트리가 생깁니다.
산출물과 맡는 사람#
AI-DLC 에이전트 14개(전문가 11, 검토 전용 2, 단계 구성 제안 1)가 스테이지를 이끌고, 사람은 질문에 답하고 승인합니다. 스테이지마다 답하는 사람이 다릅니다.
| 스테이지 | 이끄는 에이전트 | 산출물 | 답하고 승인하는 사람 |
|---|---|---|---|
| 2.2 팀 규칙 | pipeline-deploy (+품질·개발·보안 검토) | team-practices.md → memory/team.md |
팀 리드·아키텍트 |
| 2.3 요구사항 | product | requirements.md (FR·NFR, 합격 기준, 출처 표시) |
PO·기획 |
| 2.4 유저 스토리 | product | stories.md (Given/When/Then, AC1.1.1), personas.md |
PO·기획 |
| 2.5 화면 | design | mockups.md, interaction-spec.md |
디자이너·PO |
| 2.6 도메인 설계 | architect | components.md, decisions.md (ADR) |
아키텍트 |
| 2.7 유닛 분해 | architect | unit-of-work.md, unit-of-work-dependency.md (DAG), unit-of-work-story-map.md |
아키텍트 |
| 2.8 계약 설계 | architect | contract-summary.md (서비스 사이 API) |
아키텍트·개발 리드 |
| 2.9 볼트 계획 | delivery | bolt-plan.md, 검증 명령(Construction Verification Command) |
개발 리드 |
| 3.1 기능 설계 (유닛마다) | architect | entities.md (데이터 모델), rules.md, functional-spec.md |
개발 리드 |
| 3.5 코드 생성 (유닛마다) | developer | 코드 계획 → 코드·시험, traceability.json |
개발자 (계획 승인) |
| 3.6 빌드와 테스트 | quality | 시험 결과, 요구사항 대비 검증표 | 개발 리드 |
모든 스테이지 끝에는 검토 에이전트(product-lead, architecture-reviewer)가 문서를 따로 읽고 문제점을 짚으며, 사람이 Approve / Request Changes를 고릅니다.
스펙킷과 비교#
GitHub 스펙킷은 명령 몇 개로 스펙 → 계획 → 작업 → 구현을 진행하는 도구입니다. 대응 관계는 다음과 같습니다.
| 스펙킷 | 스펙킷 산출물 | AI-DLC 대응 | AI-DLC 산출물 |
|---|---|---|---|
/speckit.constitution |
memory/constitution.md |
2.2 팀 규칙 + 기억 파일 계층 | org.md → team.md → project.md → phases/*.md |
/speckit.specify |
spec.md (사용자 시나리오, 요구사항) |
1.1 의도 정리, 2.3 요구사항, 2.4 유저 스토리 | intent-statement.md, requirements.md, stories.md |
/speckit.clarify |
spec의 Clarifications | 스테이지마다 질문지와 후속 질문 | *-questions.md, 답은 [Q3]처럼 출처로 남음 |
/speckit.plan |
plan.md, data-model.md, contracts/, research.md |
2.6 도메인 설계, 2.7 유닛, 2.8 계약, 3.1 기능 설계, 3.2~3.4 NFR·인프라 | components.md·ADR, 유닛 DAG, contract-summary.md, entities.md |
/speckit.tasks |
tasks.md |
2.9 볼트 계획, 유닛마다 코드 생성 계획 | bolt-plan.md, code-generation-plan.md |
/speckit.analyze |
일관성 보고 | 검토 에이전트, 센서, 추적표 | reviews/review-*.md, traceability.json |
/speckit.implement |
코드 | 3.5 코드 생성(유닛마다), 3.6 빌드와 테스트 | 코드, 시험 결과 |
크게 다른 점은 다음과 같습니다.
- 사람의 게이트: 스펙킷은 사람이 명령을 차례로 실행하고, AI-DLC는 스테이지마다 질문과 승인 게이트가 있어 승인 없이는 다음 단계로 넘어가지 않습니다.
- 유닛과 볼트: 스펙킷은 기능 하나를
tasks.md로 나눕니다. AI-DLC는 인텐트를 유닛 DAG로 나누고, 유닛마다 설계 → 코드를 반복합니다. - constitution의 모양: 스펙킷은 규칙을 한 파일에 담고, AI-DLC는 조직 → 팀 → 프로젝트 → 페이즈 계층으로 쌓습니다. 훅은 도구를 호출할 때마다 현재 단계의 규칙을 다시 넣습니다. 사람이 고쳐 준 것은 학습(learnings)으로
project.md에 쌓입니다. - 기록: AI-DLC는 질문·답·승인·센서·하위 에이전트 실행을 131종 이벤트로 감사 기록에 남깁니다.
- 여러 도구: 같은 엔진이 Claude Code, Kiro, Codex CLI, Cursor, opencode, GitHub Copilot에서 동작합니다.
시험과 되돌아가는 루프#
TDD를 팀 규칙으로 정하면 코드 생성 계획의 순서가 "계층마다 실패하는 시험을 먼저 쓰고, 그 시험을 통과시키는 구현을 쓴다"로 바뀝니다. 시험은 유저 스토리의 인수 조건 ID(AC2.2.1 등)와 요구사항 ID에 연결되고, traceability.json이 그 연결을 기록합니다.
랄프 루프와 비교: 랄프 루프는 시험을 통과할 때까지 같은 지시로 에이전트를 반복 실행하는 방식입니다. AI-DLC의 빌드와 테스트 단계에는 반복 횟수와 중단 조건이 정해진 실패 처리 절차가 있습니다.
- 단계 안에서 고치기 (최대 2번): 시험 설정, 빌드 스크립트, 환경 문제를 고칩니다.
- 원인 분류와 영향 추정: 생성된 코드·시험이나 코드 생성 때 고른 방식(라이브러리, 버전, 알고리즘)이 원인인지 파악하고, 수정 방법과 비용·위험을 추정합니다.
- 자동으로 되돌아가기 (최대 3번): 구현 단계에서 "Continue automatically"를 골랐다면, 원인이 된 유닛의 코드 생성을 다시 열고 이후 단계를 다시 실행합니다.
- 사람에게 묻기: 자동 모드가 아니거나 3번을 넘기거나 고칠 방법이 없으면 멈춥니다. 수정안과 영향을 보여 주고 선택을 요청합니다.
품질 목표(커버리지 하한 등)를 낮춰 통과시키는 것은 고치는 방법으로 인정하지 않습니다. 중단 여부는 사람이 정합니다.
레벨 1에서 다음 레벨로 잇기#
poc로 만든 결과를 다음 레벨에서 이어 쓰는 방법은 세 가지입니다(AI-DLC 문서 기준이며, 실제로 실행해 보지는 않았습니다).
- poc가 진행 중일 때:
/aidlc --scope mvp(또는 classic, feature)로 바꾸면 이미 승인한 스테이지는 그대로 두고 남은 계획만 새 스코프로 바뀝니다. - poc가 끝났을 때: 스코프만 바꾸면 마지막 단계 뒤의 스테이지(CI, 운영 등)만 다시 열립니다. 앞쪽 설계 단계는
/aidlc --stage user-stories,--stage units-generation처럼 지정해 되돌아가야 합니다. - 같은 폴더에서 새 인텐트로: poc 스코프 정의에서 권하는 방법입니다("되면 feature/mvp로 다시 잡아 실제 빌드에서 전체를 돌려라"). 코드가 있으므로 기존 코드 프로젝트로 판별되어 역설계(2.1)가 poc 코드를 분석합니다. 기억 파일(
project.md의 402 규칙,team.md)은 자동으로 이어지고, poc의 요구사항은/aidlc mvp Read <경로>/requirements.md …처럼 입력 문서로 넘깁니다.
레벨 2는 명확히 비교하기 위해 새 폴더에서 처음부터 만들었습니다.