테마
AI-DLC 실전 적용 가이드
AI-DLC 개념과 원칙에서 본 철학은 "AI가 계획하고 질문하며, 사람이 검증한 뒤에만 구현한다"입니다. 이 페이지는 그 철학을 공식 구현체 awslabs/aidlc-workflows(2026-10-26 기준 v2.11.1)로 실제로 쓸 때 알아야 할 것만 정리합니다.
시작은 한 줄입니다
설치와 Kiro 설정은 개념과 원칙 페이지에 있습니다. 설정이 끝나면 하려는 일을 설명하는 것으로 시작합니다.
text
/aidlc Build a REST API for inventory managementAI-DLC는 설명을 읽고 맞는 워크플로 프로필을 제안합니다. 맞는 프로필이 없으면 작업에 맞춰 stage 조합을 제안하는 composer를 권합니다. 어느 경우든 경로를 사용자가 확인한 뒤에 시작합니다. 프로필을 직접 고르려면 /aidlc <프로필>을 씁니다.
어떤 작업에 어떤 프로필을 고르나
AI-DLC는 모든 작업을 같은 절차로 돌리지 않습니다. 공식 구현체는 11개 프로필을 제공합니다. stage 수는 모든 프로필이 먼저 실행하는 Initialization 3개 stage를 뺀 30개 기준입니다.
| 프로필 | 공식 설명 (Best for) | Stage | 시작 |
|---|---|---|---|
| Classic | V1 방식의 절차로 Inception과 Construction을 거쳐 Build and Test에서 끝남 | 15 / 30 | /aidlc classic |
| Express | 요구사항 → 코드 → 테스트의 가장 가벼운 경로 | 7 / 30 | /aidlc express |
| Feature | 전체 라이프사이클을 쓰는 프로덕션 기능 | 30 / 30 | /aidlc feature |
| Enterprise | 완전한 추적성이 필요한 규제·고신뢰 작업 | 30 / 30 | /aidlc enterprise |
| MVP | Operation phase 없이 만드는 첫 제품 증분 | 20 / 30 | /aidlc mvp |
| Proof of concept | 최소 구현으로 실현 가능성 검증 | 5 / 30 | /aidlc poc |
| Bugfix | 집중 수정과 회귀 테스트가 필요한 알려진 결함 | 6 / 30 | /aidlc bugfix |
| Refactor | 제품 동작을 바꾸지 않는 기존 코드 개선 | 7 / 30 | /aidlc refactor |
| Infrastructure | 환경, IaC, 배포 기반, 비용 작업 | 10 / 30 | /aidlc infra |
| Security patch | CVE나 특정 취약점 대응 | 7 / 30 | /aidlc security-patch |
| Workshop | 진행자가 이끄는 교육·그룹 세션 | 23 / 30 | /aidlc workshop |
공식 문서가 강조하는 판단 기준 두 가지입니다.
- 요구사항이 이미 분명하면 Express처럼 가벼운 경로가 맞습니다.
- 문제 자체가 아직 불분명해 시장 조사, 타당성 분석, 범위 탐색이 필요하면 Classic이 아니라 Feature나 Enterprise를 고르라고 안내합니다.
팁
큰 작업이나 워크숍 전에는 공식 가이드의 Vision Document 작성 안내와 Technical Environment Document 작성 안내를 먼저 보세요. 무엇을 왜 만드는지, 어떤 기술 환경에서 만드는지를 미리 적어 두면 첫 질문이 줄어듭니다.
질문에 답하는 방법
질문이 필요한 stage에서 AI-DLC는 질문을 파일로 만들고 답하는 방식을 세 가지 중에서 고르게 합니다.
| 방식 | 공식 설명 | 맞는 상황 |
|---|---|---|
| Guide me | 에이전트가 질문을 하나씩(또는 묶어서) 대화로 안내 | 빠뜨림 없이 따라가고 싶을 때 |
| Edit file | 질문 파일의 빈 답란을 직접 채움 | 원하는 바를 이미 알고 글로 적는 편이 빠를 때 |
| Chat | 자유롭게 대화하면 에이전트가 결정 사항을 뽑아 기록 | 아이디어를 탐색하거나 요구사항이 아직 흐릴 때 |
- 어느 방식이든 결과는 같은 질문 파일에 기록되며, 이 파일이 결정의 원본입니다.
- 방식은 작업마다 한 번 고르면 이후 stage에서 재사용되고, 중간에 바꿔도 이미 받은 답은 유지됩니다.
- 각 질문에는
[Product owner],[Developer]처럼 보통 답할 사람이 붙습니다. 팀이 질문을 나눠 맡을 수 있고, 혼자라면 제품에 관한 질문과 구현에 관한 질문을 구분해 볼 수 있습니다. 누구든 어떤 질문에나 답해도 됩니다.
승인 게이트에서 답하는 방법
Initialization의 3개 stage를 제외한 모든 stage는 승인 게이트로 끝납니다. 다음 stage로 넘어가기 전에 에이전트의 결과를 확인하는 지점입니다. phase 경계에서는 추가로 verification gate가 자동 추적성 검사를 돌립니다.
기본 게이트의 선택지는 Approve와 Request Changes입니다. 같은 stage에서 Request Changes가 세 번 반복되면 현재 버전으로 넘어가는 Accept as-is가 추가되고, Ideation·Inception에서는 건너뛴 stage를 되살리는 Add Skipped Stage가 나타날 수 있습니다. 공식 문서는 동료에게 답하듯 자기 말로 답하라고 안내합니다. 선택지 문구를 그대로 다시 입력할 필요가 없습니다.
| 이렇게 답하면 | AI-DLC는 |
|---|---|
1, approved, looks good | 승인하고 다음 stage로 진행 |
rename the handler, no, split the tests | 변경 요청으로 받고 그 말을 피드백으로 반영해 다시 제시 |
looks fine but rename the handler | 승인과 지시를 함께 처리하고 한 줄로 결과를 알림 |
Approve, but let's stop there for today | 승인하고 작업을 멈춤. 나중에 /aidlc --resume으로 이어감 |
| 질문 | 답을 주고, 다음 답을 기다림 |
hmm, not sure처럼 정말 모호한 답 | 짧은 질문 하나로 되물음 |
게이트, 계획 승인(Code Generation stage의 Approve Plan, AI-DLC 자체 절차이며 Kiro Plan 모드와 다릅니다), 체크포인트에서 내린 결정은 사용자의 답과 함께 감사 기록(audit trail)에 남습니다. Construction에서는 일상적인 체크포인트를 멈추지 않고 통과하도록 미리 고를 수 있습니다.
Kiro Spec, Plan 모드와 비교
셋 다 "코드를 쓰기 전에 계획하고 사람이 확인한다"는 생각을 공유하지만, 서로 다른 도구입니다. 공식 Kiro 가이드에 따르면 Kiro 시작 화면의 Spec, Plan, Bug Fix, Quick Spec은 Kiro 자체 워크플로이고 AI-DLC는 그 목록에 나타나지 않으며, AI-DLC는 채팅에서 aidlc 에이전트로 시작합니다.
AI-DLC (/aidlc) | Kiro Spec | Kiro Plan 모드 | |
|---|---|---|---|
| 무엇인가 | 5 phase·33 stage의 개발 라이프사이클 방법론 구현체 | Kiro의 구조화된 개발 세션 | 실행 전에 변경 계획을 보여 주는 Kiro 모드 |
| 다루는 범위 | Ideation부터 Operation까지 (프로필에 따라 줄어듦) | Requirements → Design → Tasks → 구현 | 이번 요청에서 바꿀 파일·내용·순서 |
| 사람이 확인하는 곳 | Initialization 3개를 제외한 stage마다 승인 게이트, phase 경계 verification gate | 각 문서 검토 (Quick Spec은 한 번에 생성) | 전체 계획을 한 번 승인 |
| 남는 것 | aidlc/의 산출물, aidlc-state.md, 감사 기록 | .kiro/specs/<이름>/의 requirements·design·tasks | 대화 안의 계획 |
| 시작 | aidlc 에이전트에서 /aidlc | Specs 패널 또는 Spec 세션 | 계획만 보여 달라고 요청 |
어떻게 구분해 생각하면 되나
- 세 가지는 다루는 범위가 다릅니다. Plan 모드는 이번 요청의 변경 계획, Kiro Spec은 한 기능의 요구사항·설계·작업, AI-DLC는 선택한 프로필이 정한 phase와 stage를 다룹니다.
- 각자 질문·확인 지점·산출물을 따로 관리하는 별개의 도구입니다. 작업마다 어떤 도구로 진행할지 고르면 됩니다.
Kiro 기능 자체는 Spec 세션과 Plan 모드에서 설명합니다.
원문 개념에서 현재 구현으로 달라진 점
원문 블로그는 AI-DLC를 개념과 3단계로 소개했습니다. 아래 표는 원문과 현재 공식 구현체의 설명을 나란히 놓은 것입니다.
| 원문 블로그 | 현재 공식 구현체 (v2.11.1) |
|---|---|
| Inception · Construction · Operations 3단계 | 5 phase: Initialization(워크스페이스 준비, 3 stage), Ideation(7), Inception(9), Construction(7), Operation(7) |
| 반복 패턴: 계획 → 질문 → 사람 검증 후 구현 | 33 stage마다 입력·단계·출력·담당 에이전트가 정해지고, Initialization 3개를 제외한 stage마다 승인 게이트 |
| (작업 유형별 절차 조절은 설명하지 않음) | 11개 워크플로 프로필로 작업 종류에 따라 stage·depth·test strategy를 조절 |
| Mob Elaboration·Mob Construction: 사람 팀 전체가 AI의 질문과 제안을 검증 | 사람이 각 게이트에서 결정. 공식 문서는 3~5명이 한 기능 전체를 맡는 팀을 본떠 "Small Mob, Broad Agents" 라고 설명 |
| (에이전트 구성은 설명하지 않음) | 14 에이전트(도메인 전문가 11, reviewer 2, composer 1) |
| 맥락을 리포지토리에 영속 저장 | aidlc-state.md 상태, 126종 audit event, 팀 지식과 학습된 규칙 |
| Amazon Q Developer rules, Kiro custom workflows로 구현 가능 | 하나의 하네스 중립 코어를 Claude Code, Kiro CLI·IDE, Codex CLI, Cursor, opencode, GitHub Copilot에서 실행 |
공식 문서는 Classic 프로필을 "V1 방식의 절차(V1-style ceremony)"로 설명합니다. Ideation을 건너뛰고 Operation은 자리만 남겨 둡니다. 원문 블로그의 3단계와 비슷해 보이지만, 공식 문서가 둘을 같은 것이라고 말하지는 않습니다.
하네스 엔지니어링
이 용어는 두 맥락에서 쓰이므로 구분해서 이해해야 합니다.
AI-DLC 공식 문서에서의 의미. 공식 Harness Engineer Guide는 AI-DLC가 팀에 맞게 동작하도록 방법론 자체를 재구성하는 사람을 위한 안내입니다. 어떤 stage를 실행할지 바꾸고, 다루지 않는 도메인의 에이전트를 추가하고, scope를 조이고, 팀의 규칙을 가르치고, stage에 결정론적 검사(sensor)를 연결합니다. 이 모든 작업을 코드 없이 Markdown·JSON 데이터 파일로 합니다.
| 문서 | 대상 | 바꾸는 것 |
|---|---|---|
| User Guide | AI-DLC로 소프트웨어를 만드는 사람 | 없음. /aidlc를 실행하고 게이트에서 답함 |
| Harness Engineer Guide | 팀에 맞게 AI-DLC의 동작을 다듬는 사람 | stage, 에이전트, scope, 규칙, sensor, 지식 (데이터) |
| Developer Reference | AI-DLC 자체를 고치는 사람 | 엔진, hooks, CLI 도구 (코드) |
업계에서의 넓은 의미. 최근 AI 코딩 분야에서는 에이전트가 안정적으로 일하도록 실행 환경·의도 명세·피드백 루프를 설계하는 일 전반을 하네스 엔지니어링이라고 부르기도 합니다(예: OpenAI, "Harness engineering"). Kiro에서 컨텍스트를 설계하는 방법은 Context Engineering에서 다룹니다.
다음에 읽을 문서
- AI-DLC 워크플로 구조 참고 — 공식 구현체의 phase·stage·에이전트·depth를 요약
- AI 코딩 방법론 비교 — AI-DLC, Kiro Spec-Driven, Ralph Loop를 같은 기준으로 비교
- 공식 가이드: User Guide · Workflow Profiles · Interaction Modes · Running AI-DLC on Kiro
AI-DLC 관련 사실은 awslabs/aidlc-workflows v2.11.1 문서와 AWS DevOps Blog 원문을 기준으로 합니다. 수치와 명령은 릴리스마다 바뀔 수 있으니 공식 문서를 확인하세요.