AWS의 AI-DLC (AI-Driven Development Life Cycle): robust하게 바이브 코딩

 

참고 링크

AWS AIDLC: https://aws.amazon.com/ko/blogs/devops/open-sourcing-adaptive-workflows-for-ai-driven-development-life-cycle-ai-dlc/

Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC) | Amazon Web Services

AIDLC Amazon Q real example: https://aws.amazon.com/ko/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/

Building with AI-DLC using Amazon Q Developer | Amazon Web Services

 

 

코드: https://github.com/awslabs/aidlc-workflows

GitHub - awslabs/aidlc-workflows: AI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules for AI coding agents

 

 

 

AI-DLC workflow: Humans decide and validate, AI plans and executes.

 

최근에 회사에서 AWS의 AI-DLC(AI-Driven Development Life Cycle)를 도입해서 배우게됐는데, 꽤 괜찮은 것 같아서 공유한다. AI-DLC는 SDLC(Software Development Life Cycle)의 AI Agent 버전이라고보면 된다. AI에게 코딩을 시키다 보면 종종 간단한 버그 하나 고쳐달라고 했는데 멀쩡한 코드를 갈아엎거나, "알아서 잘 만들어줘" 했더니 묻지도 않고 DB 스키마부터 인증 로직까지 제멋대로 결정해버린다. 인간은 전체 맥락에서 중요 포인트를 계속 머리속에서 홀딩할 수 있는 반면에 AI는 context를 sequence로 받아야 하기 때문에 모든 프로젝트 파일을 매번 다 훑을 수가 없어서 다시 찾아보거나 빠트리거나 한다. 반대로, 사람이 모든 구조를 완벽하게 이해하고 있지 않아 AI와 interact하면서 대충 말하면서 AI한테 혼란이 일어나기도 한다. AI에게 모든 context를 계속 holding한 상태로 작업할 수 있게하면서 rules (or harness)를 잘 이용하여 예측된 범위 내의 결과를 잘 도출해내도록 하는 것이 중요한데, AI-DLC가 그 대표적인 좋은 사례다.

---

1. AI-DLC (AI-Driven Development Life Cycle)

AI-DLC는 소프트웨어 개발 Lifecycle을 AI에게 맡기되, 중요한 결정은 사람이 승인하도록 구조화한 방법론이다. 반복적이고 정형화된 작업은 AI에 위임하고, 중요한 판단은 사람이 감독하도록 전략적으로 나눈다. 여기서 중요한 점은 AI-DLC가 특정 모델이나 API가 아니라는 것이다. 실제로는 AI 코딩 에이전트에게 주입하는 일련의 규칙(rules) 집합에 가깝다. 20개가 넘는 rule 파일로 구성되어 있고, 이 규칙들이 에이전트의 행동을 단계별로 제약한다. 현재는 Amazon Q Developer와 Kiro CLI에서 동작하며, AWS가 오픈소스로 공개했다.

 

2. 왜 AI-DLC를 쓰는가

기존 AI 코딩 도구의 문제는 "구조가 없다"는 것이다.

1) AI의 폭주를 막는다

LLM은 가정(assumption)을 만들고 빠르게 결과로 직행하려 한다. AI-DLC는 사용자를 대신해 함부로 가정하지 말고, 대신 명확히 하기 위한 질문을 하도록 에이전트에 명시적으로 지시

2) Human-in-the-loop

각 단계 사이에 사람의 승인. 주요 stage를 넘어가기 전에 사용자가 명시적으로 승인해야 한다. AI가 혼자 다음 단계로 진행하지 못한다.

3) 추적 가능성(Traceability)

모든 사용자 상호작용, 승인, 결정이 audit.md 파일에 raw input과 timestamp까지 포함해 기록된다. 나중에 "왜 이런 결정을 했지?"를 되짚을 수 있다.

4) 복잡도에 맞춘 적응

단순한 버그 수정은 planning을 건너뛰고 바로 코드 생성으로 가고, 복잡한 기능은 요구사항 분석과 아키텍처 설계, 상세 테스트를 거친다. 무거운 프로세스를 항상 강제하지 않는다.

 

3. 3개의 Phase

whole AI-dlc process in 두번째 링크

 

Inception, Construction, Operations 각 phase 안에는 여러 stage가 있고, stage는 **필수(mandatory)**와 **조건부(conditional)**로 나뉜다. 초록색이 필수, 노란색 점선 박스가 옵션. 적응형 워크플로우라서 요청과 코드베이스, 복잡도를 분석해 필요한 stage만 실행한다.

Inception (계획 · 아키텍처)

Inception은 계획과 아키텍처를 다룬다. 대표 stage:

• Workspace Detection — 현재 워크스페이스가 greenfield(신규)인지 brownfield(기존)인지 판별한다. brownfield면 Reverse Engineering으로, greenfield면 Requirements Analysis로 분기한다.
• Requirements Analysis — 요구사항을 정의하는 단계. 여기서 에이전트는 객관식(multiple-choice) 형식으로 질문하되, 항상 "Other" 같은 개방형 선택지를 포함하도록 지시받는다. 사용자가 답하면 모순이나 모호함이 있는지 검사하고, 합의가 끝날 때까지 다음 단계로 넘어가지 않는다.
• Workflow Planning — 요구사항을 분석해 어떤 stage를 실행하고 어떤 stage를 건너뛸지 execution-plan.md에 정리한다.

Construction (설계 · 구현)

Construction은 설계와 구현에 집중한다.

• Code Generation Planning — 바로 코딩하지 않고 먼저 계획부터 짠다. 요구사항과 설계 산출물을 분석해 비즈니스 로직, API 레이어, 데이터 레이어, 테스트, 문서, 배포 파일 생성을 명시적 단계로 쪼갠다. 각 단계는 체크박스가 달린 {unit-name}-code-generation-plan.md에 기록된다.
• Code Generation — 승인된 계획을 실제 코드로 실행한다. 완료된 단계는 체크박스로 표시되고 진행 상황이 추적된다.
• Build and Test — unit test, integration test, performance test 등 테스트 레이어를 문서화하고 빌드/패키징 지침을 생성한다.

Operations (배포 · 모니터링)

Operations는 배포와 모니터링을 다룬다.

4. 실제로 어떻게 동작하나 (Claude Code 기준)

AI-DLC는 특정 도구가 아니라 "방법론"이고, 무언가를 설치할 필요 없이 시작할 수 있도록 설계됐다. Claude Code는 프로젝트 메모리 파일인 CLAUDE.md를 통해 이 워크플로우를 주입한다.

rule 폴더 배치

저장소의 release zip을 풀면 aidlc-rules/ 폴더 안에 두 개의 하위 디렉터리가 있다. 핵심 워크플로우 규칙인 aws-aidlc-rules/, 그리고 핵심 규칙이 조건부로 참조하는 상세 규칙 aws-aidlc-rule-details/다.

Claude Code에서는 핵심 규칙을 CLAUDE.md로 복사하고, 상세 규칙은 .aidlc-rule-details/에 둔다.

my-project/
 ㄴ CLAUDE.md
 ㄴ .aidlc-rule-details/
 ㄴ common/
 ㄴ inception/
 ㄴ construction/
 ㄴ extensions/
 ㄴ operations/

 

이렇게 나누는 이유는 context window 절약이다. core-workflow.md(= CLAUDE.md)만 항상 로드되고, 상세한 phase·stage 규칙은 필요할 때만 .aidlc-rule-details/에서 동적으로 참조된다. 매 순간 필요한 정보만 context에 유지하는 구조다.

설정이 제대로 됐는지는 Claude Code를 프로젝트 디렉터리에서 실행한 뒤 /config로 현재 설정을 확인하거나, Claude에게 "What instructions are currently active in this project?"라고 물어보면 된다.

워크플로우 시작

트리거 문구가 필요하다. 채팅에서 "Using AI-DLC, ..."로 시작해 의도를 말하면 AI-DLC 워크플로우가 자동으로 활성화되고 거기서부터 안내한다. 혹은 AI

Using AI-DLC, let's build a web application to solve the river crossing puzzle.

 

이후 흐름은 다음과 같다. AI-DLC가 구조화된 질문을 던지면 답하고, AI가 생성한 모든 plan을 검토하며 감독·검증한다. 실행 계획(execution plan)을 보고 어떤 stage가 실행될지 확인한 뒤, 각 stage의 산출물을 검토하고 승인하면서 통제권을 유지한다. 모든 산출물은 aidlc-docs/ 디렉터리에 생성된다.

Extension으로 규칙 얹기

핵심 워크플로우 위에 보안·테스트 같은 규칙을 추가로 얹을 수 있다. Extension은 aws-aidlc-rule-details/extensions/ 아래에 카테고리별(security/, testing/ 등)로 정리된 마크다운 파일들이다.

동작 방식이 깔끔하다. 워크플로우 시작 시 AI-DLC는 extensions/ 디렉터리를 스캔해 *.opt-in.md 파일만 로드하고, Requirements Analysis 단계에서 각 opt-in 질문을 사용자에게 제시한다. 사용자가 opt-in하면 대응하는 규칙 파일이 로드되고, opt-out하면 로드되지 않는다. 한번 활성화된 extension 규칙은 blocking 제약이 되어, 각 stage에서 준수 여부를 검증한 뒤에야 다음으로 진행할 수 있다. 기본 제공되는 security extension 규칙은 방향성을 보여주는 참고용이라 production에 적용하기 전에 각 조직이 직접 만들고 커스터마이즈해 충분히 테스트해야 한다.

버전 관리

CLAUDE.md와 .aidlc-rule-details/는 저장소에 커밋해 버전 관리하는 것을 권장한다. 팀원들이 같은 워크플로우 규칙을 공유하게 된다.

5. Trade-off

AI-DLC가 만능은 아니다. 구조를 강제하지 않고 특정 작업에만 AI를 쓰는 가벼운 CLI 도구와 비교하면 분명한 비용이 있다.

• 무거운 프로세스 오버헤드 — 간단한 명령줄 프롬프트 대비 20개 이상의 규칙 파일, aidlc-docs/ 계층 구조 생성이 강제된다.
• 플랫폼 종속 — 임의의 LLM API가 아니라 Amazon Q나 Kiro를 요구한다. 다른 AI 코딩 어시스턴트에서는 동작하지 않을 수 있다.
• TDD와의 충돌 — 테스트 커버리지를 형식적 요구사항에 맞추는 대신, TDD의 반복적 이점은 줄어든다.

정리하면, AI-DLC는 엔터프라이즈급 거버넌스에 가깝고, 가벼운 도구는 해커 친화적인 생산성 부스터에 가깝다. 대규모 팀이 production-grade 소프트웨어를 통제 가능하게 만들어야 하는 상황이라면 AI-DLC가, 혼자 빠르게 뭔가 만들어보는 상황이라면 가벼운 도구가 더 잘 맞다.

 

참고 (개발 방법론)

TDD (Test-Driven Development)

테스트를 먼저 짜고, 그 테스트를 통과시키는 코드를 나중에 작성

• 흐름: Red → Green → Refactor. 실패하는 테스트 작성(Red) → 통과시키는 최소 코드 작성(Green) → 정리(Refactor)
• 단위(unit) 단위로 검증. 개발자 관점의 "이 함수가 제대로 동작하나"에 초점
• 장점: 회귀(regression) 방지, 설계가 테스트 가능한 형태로 강제됨
• 한계: 무엇을 테스트할지는 알려주지 않음. "기능이 맞게 정의됐나"는 보장 못 함

회귀: 잘 동작하던 기능이 코드 변경 후 다시 망가지는 것
회귀 테스트: 그걸 잡기 위해 기존 기능이 여전히 작동하는지 재확인하는 테스트

 

BDD (Behavior-Driven Development)

TDD를 비즈니스 언어로 확장한 것. 테스트를 "행동(behavior)" 명세로 쓴다.

• Given-When-Then 구조로 시나리오 작성 (주어진 상황 → 행동 → 기대 결과)
• Cucumber, SpecFlow 같은 도구로 자연어에 가까운 명세를 작성
• 기획자·QA·개발자가 같은 언어로 요구사항을 공유하는 게 목적
• TDD가 "코드가 맞나"라면, BDD는 "우리가 맞는 걸 만들고 있나"에 가까움

SDD (Spec-Driven Development)

명세(spec)를 먼저 확정하고, 그 spec에서 코드·테스트를 생성한다.

• AI 코딩 시대에 주목받는 방식. 모호한 요구사항을 명확한 spec으로 만드는 게 핵심
• 사람은 spec 작성과 검토에 집중하고, 구현은 AI 에이전트에 위임
• Kiro의 spec mode, GitHub Spec Kit 등이 이 흐름
• 앞서 다룬 AWS AI-DLC도 큰 틀에서 spec 우선 사고에 닿아 있음

TDD는 테스트 먼저, BDD는 행동 명세 먼저, SDD는 스펙 먼저. 뒤로 갈수록 "코드"보다 "무엇을 만들지 정의하는 것"에 무게가 실린다.