AI-DLC는 코딩 도구가 아니라 개발 절차를 바꾼다
AWS AI-DLC를 분석하며 개발자의 역할, 요구사항 도출 방식, 기존 개발 절차와의 차이, Spec Kit과 Kiro Specs 같은 비슷한 도구들과의 차이를 정리한다.
AI-DLC를 볼 때 먼저 봐야 할 것은 도구 목록이 아니다. 핵심은 개발이 어떻게 바뀌는가다.
AI-DLC가 바꾸는 것은 “AI가 코드를 대신 써준다” 정도가 아니다. 더 정확히는 개발자의 역할을 바꾼다. 개발자는 코드 작성자에서 맥락 제공자, 의사결정자, 검증자, 승인자에 가까워진다.
기존에는 개발자가 요구사항을 이해하고, 설계하고, 코드를 쓰고, 테스트하고, 배포했다. AI 코딩 도구를 쓰더라도 이 흐름은 대체로 유지됐다. AI는 중간중간 코드를 보조하거나 테스트 초안을 만들거나 문서를 정리하는 역할이었다.
AI-DLC는 이 흐름을 더 크게 바꾸려 한다. AI가 요구사항 분석, 질문 생성, 설계, 작업 단위 분해, 코드 생성, 테스트 계획까지 단계별로 수행한다. 사람은 각 단계에서 답하고, 검토하고, 승인한다.
한 줄로 말하면 이렇다.
AI-DLC는 AI에게 개발을 맡기는 방법이 아니라, AI와 함께 개발하는 절차를 다시 설계하는 방법이다.
개발자의 역할이 먼저 바뀐다
기존 개발 절차를 단순화하면 요구사항 이해에서 배포까지 개발자가 한 줄로 밀고 가는 흐름에 가깝다. AI-DLC에서는 AI가 단계별 산출물을 만들고, 사람이 중간중간 검토하고 승인하고 검증하는 흐름으로 바뀐다.
차이는 명확하다. 기존에는 개발자가 머릿속에 많은 맥락을 들고 움직였다. AI-DLC에서는 그 맥락을 파일과 산출물로 계속 남긴다.
요구사항, 질문 답변, 설계 결정, 작업 단위, 테스트 계획, 승인 기록이 저장소 안에 남는다. AI는 다음 단계에서 그 산출물을 다시 읽고 이어간다. 그래서 대화창의 기억보다 저장소의 문서가 더 중요해진다.
AI가 사람을 인터뷰해 요구사항을 도출한다
AI-DLC에서 특히 중요한 변화는 요구사항 도출 방식이다.
사람이 완성된 요구사항을 AI에게 넘기는 구조가 아니다. 사람이 처음부터 완벽한 PRD를 써야 하는 것도 아니다. 오히려 AI가 사람을 인터뷰하면서 요구사항을 구체화한다.
예를 들어 사람이 이렇게 시작한다고 해보자.
고객 주문 관리 API를 만들고 싶다.일반적인 AI 코딩에서는 바로 API 구조를 만들거나 코드를 생성하려 할 수 있다. AI-DLC에서는 먼저 모호한 부분을 질문으로 만든다.
Q. 주문 상태는 어떤 단계를 가져야 하나?
A) created, paid, shipped, cancelled
B) created, confirmed, fulfilled, cancelled
C) 직접 정의
[Answer]:Q. 결제 시스템과 연동해야 하나?
A) 지금은 안 한다
B) 외부 PG와 연동한다
C) 내부 결제 서비스와 연동한다
[Answer]:사람이 답하면 AI는 그 답을 바탕으로 요구사항 문서를 만든다. 그리고 사람은 그 문서를 검토하고 승인한다.
이 흐름은 단순한 질의응답이 아니다. 요구사항을 만들기 위한 인터뷰다.
이 부분이 AI-DLC의 출발점이다. 개발자는 AI에게 “요구사항은 이거야”라고 완성본을 주는 사람이 아니라, AI가 좋은 질문을 하도록 맥락을 주고, 그 질문에 답하면서 요구사항을 확정하는 사람이 된다.
기존 개발과 AI-DLC의 차이
기존 개발에서는 요구사항과 설계가 코드 바깥에 있거나, 회의와 티켓과 사람의 기억에 흩어져 있는 일이 많다. 구현이 진행되면서 실제 의사결정은 코드와 PR 댓글에 남고, 처음의 의도와 나중의 구현 사이에는 간격이 생긴다.
AI-DLC는 이 간격을 줄이려 한다. 요구사항부터 설계, 작업 단위, 코드 생성, 테스트까지 이어지는 연결을 문서로 남긴다.
그래서 AI-DLC의 핵심은 “AI가 더 많은 코드를 만든다”가 아니다. 핵심은 AI가 만든 산출물을 사람이 검토할 수 있는 단계로 쪼개고, 그 단계들을 저장소 안에 남기는 것이다.
AI-DLC의 핵심 아이디어
AWS의 AI-DLC 소개 글은 기존 AI 활용을 두 가지로 나눈다. 하나는 AI-assisted development다. 문서 작성, 코드 완성, 테스트 생성처럼 특정 작업을 보조하는 방식이다. 다른 하나는 AI-autonomous development다. 요구사항을 주면 AI가 전체 앱을 만들어주길 기대하는 방식이다.
AI-DLC는 이 둘 사이에서 다른 방향을 제안한다. AI가 적극적으로 실행하되, 사람의 승인과 검증을 개발 절차 안에 넣는다.
핵심 아이디어는 네 가지다.
첫째, 대화가 아니라 산출물이 상태다.
AI와 나눈 대화는 쉽게 길어지고 사라진다. AI-DLC는 요구사항, 설계, 질문 답변, 작업 계획, 감사 로그를 파일로 남긴다. 그래서 세션이 바뀌어도 다음 작업이 파일을 기준으로 이어질 수 있다.
둘째, AI autonomous가 아니라 human-gated autonomous다.
AI가 많은 일을 한다. 하지만 중요한 단계마다 사람이 승인한다. AI는 제안하고 실행하지만, 최종 결정권자는 사람이다.
셋째, 코딩 전에 ambiguity를 강제로 드러낸다.
“주문 관리”, “관리자 권한”, “빠르게”, “안전하게” 같은 말은 해석이 갈릴 수 있다. AI-DLC는 이런 모호함을 질문 파일로 끌어낸다. 개발자는 답변하면서 실제 요구사항을 확정한다.
넷째, 요구사항, 설계, 코드, 테스트 사이의 추적성을 남긴다.
어떤 요구사항이 어떤 유저스토리로 이어졌는지, 어떤 작업 단위가 어떤 코드로 구현됐는지 추적하려 한다. 이것은 특히 큰 팀, 규제 산업, 보안 요구가 있는 조직에서 중요하다.
AI-DLC의 전체 Flow
main 브랜치 기준 AI-DLC는 크게 세 단계로 설명된다.
INCEPTION
무엇을 왜 만들지 정리한다.
요구사항, 유저스토리, 설계, 작업 단위를 만든다.
CONSTRUCTION
어떻게 만들지 정리하고 구현한다.
기능 설계, NFR, 인프라 설계, 코드 생성, 빌드와 테스트를 수행한다.
OPERATIONS
배포와 운영, 모니터링으로 확장되는 영역이다.
main 기준으로는 아직 placeholder 성격이 강하다.v2 프리뷰에서는 구조가 더 커진다. 5 phases, 32 stages, 11 agents로 확장된다.
Initialization
워크스페이스를 초기화하고 상태를 만든다.
Ideation
의도, 시장성, 범위, 팀 구성을 정리한다.
Inception
요구사항, 유저스토리, 설계, 작업 단위를 구체화한다.
Construction
bolt 단위로 설계, 구현, 테스트를 진행한다.
Operation
배포, 관측성, incident response, 피드백 루프를 다룬다.
이 흐름에서 중요한 것은 중간중간의 승인 게이트다. AI-DLC는 AI가 혼자 달리는 구조가 아니라, AI가 달리고 사람이 게이트에서 방향을 확인하는 구조다.
비슷한 도구들과 무엇이 다른가
AI-DLC를 보면 자연스럽게 GitHub Spec Kit, Kiro Specs, Cursor rules, Claude Code skills, Codex AGENTS.md 같은 것들이 떠오른다. 모두 AI 코딩을 그냥 프롬프트에 맡기지 않고, 구조화된 절차나 규칙을 주려는 시도다.
하지만 범위가 다르다.
Spec Kit과 Kiro Specs는 대체로 스펙을 잘 만들어 구현으로 연결하는 도구에 가깝다. AI-DLC는 그보다 범위가 넓다. 요구사항 도출, 설계, 작업 분해, 코드 생성, 테스트, 운영, 감사 로그까지 전체 개발 생명주기를 AI 중심으로 재구성하려 한다.
비교를 항목별로 풀면 이렇다.
GitHub Spec Kit
- 중심 개념: spec-driven development
- 기본 흐름: constitution -> specify -> plan -> tasks -> implement
- 주요 산출물: spec, plan, tasks
- 범위: 기능 구현 중심
- 사람 역할: 스펙 작성과 검토
- 강점: 가볍고 범용적이다.
- 부담: 스펙 품질이 낮으면 구현 품질도 흔들린다.
Kiro Specs
- 중심 개념: IDE 안의 feature spec
- 기본 흐름: requirements -> design -> tasks
- 주요 산출물: requirements.md, design.md, tasks.md
- 범위: 기능/버그 단위
- 사람 역할: 요구사항, 설계, 태스크 검토
- 강점: IDE 통합과 task 실행 경험이 좋다.
- 부담: Kiro의 spec 흐름에 묶인다.
AWS AI-DLC
- 중심 개념: AI 중심 SDLC
- 기본 흐름: ideation -> inception -> construction -> operation
- 주요 산출물: 요구사항, 설계, 작업 단위, 코드, 테스트, 감사 로그
- 범위: 전체 개발 생명주기
- 사람 역할: 단계별 승인, 검증, 규칙 관리
- 강점: 추적성, 감사, 팀 단위 프로세스에 강하다.
- 부담: 가장 무겁고 절차가 많다.
조금 더 풀어보면 이렇다.
GitHub Spec Kit은 “스펙이 구현을 이끈다”는 생각이 강하다. /speckit.specify로 무엇을 만들지 정의하고, /speckit.plan으로 기술 계획을 세우고, /speckit.tasks로 작업을 쪼갠 뒤, /speckit.implement로 구현한다. 스펙 기반 개발을 여러 AI coding agent에서 쓸 수 있게 만든 툴킷에 가깝다.
Kiro Specs는 IDE 안에서 기능이나 버그 수정을 requirements.md, design.md, tasks.md로 정리한다. 개발자가 요구사항, 설계, 작업 목록을 보고 실행할 수 있게 해준다. 기능 단위 개발에는 매우 직관적이다.
AI-DLC는 더 무겁다. 기능 하나의 스펙을 만드는 수준을 넘어, 팀이 AI와 함께 개발하는 전체 리듬을 바꾸려 한다. v2에서는 11개의 domain-expert agent, 32개 stage, scope와 depth, audit trail, sensors, learning loop까지 갖춘다.
그래서 선택 기준은 간단하다.
| 상황 | 더 맞는 선택 | 이유 |
|---|---|---|
| 빠르게 기능 하나를 스펙 기반으로 만들고 싶다 | Spec Kit 또는 Kiro Specs | 기능 단위의 요구사항, 설계, 작업 분해를 가볍게 시작할 수 있다. |
| IDE 안에서 요구사항/설계/태스크를 자연스럽게 관리하고 싶다 | Kiro Specs | requirements.md, design.md, tasks.md 흐름이 IDE 안의 기능 개발에 잘 맞는다. |
| 큰 팀, 기존 코드베이스, 보안/감사/운영까지 포함해 AI 개발 절차를 만들고 싶다 | AI-DLC | 승인 게이트, 감사 로그, 운영 피드백까지 포함한 전체 개발 생명주기 관리에 더 가깝다. |
AI-DLC는 “또 다른 스펙 도구”라기보다, 스펙 도구를 포함한 AI-native 개발 운영 모델에 가깝다.
개발자는 실제로 무엇을 해야 하나
AI-DLC가 잘 작동하려면 개발자가 손을 놓으면 안 된다. 오히려 더 분명한 역할을 해야 한다.
첫째, 초기 의도를 제공해야 한다.
”무엇을 만들고 싶은지”, “누가 쓰는지”, “왜 필요한지”, “이번 범위에서 제외할 것은 무엇인지”를 말해야 한다.
둘째, AI의 질문에 답해야 한다.
AI가 만든 질문 파일은 귀찮은 부가 작업이 아니라 요구사항 도출 과정이다. 좋은 답변이 좋은 요구사항을 만든다.
셋째, 요구사항 문서를 검토해야 한다.
AI가 정리한 요구사항이 실제 의도와 맞는지 봐야 한다. 특히 “하지 않을 것”이 빠졌는지 확인해야 한다.
넷째, 설계와 작업 단위를 승인해야 한다.
컴포넌트 경계, API, 데이터 모델, NFR, 인프라 선택은 코드보다 먼저 위험을 만든다. 이 단계에서 검토하지 않으면 나중에 생성된 코드를 많이 버릴 수 있다.
다섯째, 생성 코드와 테스트를 검증해야 한다.
AI가 코드를 만들었다고 끝이 아니다. 빌드, 테스트, 동작 확인, 보안 검토, 기존 코드와의 일관성 확인이 필요하다.
여섯째, 팀 규칙과 제약 조건을 관리해야 한다.
금지 라이브러리, 선호 아키텍처, 인증 방식, 로깅 규칙, 테스트 기준, 배포 정책 같은 것들은 AI가 추측하면 안 된다. 팀이 명시해야 한다.
정리하면 개발자는 덜 타이핑하지만, 더 많이 판단한다.
줄어드는 일과 늘어나는 일
AI-DLC를 도입하면 줄어드는 일이 있다.
- 반복적인 문서 초안 작성
- 기본 코드 뼈대 작성
- 테스트 초안 작성
- 기존 코드 구조 분석
- 설계안 초안 만들기
- 작업 목록 분해
하지만 늘어나는 일도 있다.
- 요구사항을 검증 가능한 문장으로 바꾸기
- AI 질문에 답하기
- 산출물 리뷰하기
- 설계 결정 승인하기
- 팀 규칙과 금지 사항 명시하기
- 생성 코드가 실제 요구사항을 만족하는지 확인하기
- 감사 로그와 추적성을 관리하기
생산성은 “사람이 할 일이 사라져서” 생기는 것이 아니다. 사람이 반복 작업을 덜 하고, 판단과 검증에 더 많은 시간을 쓰게 되면서 생긴다.
이 점을 놓치면 AI-DLC는 오히려 무겁고 답답한 절차가 된다. 반대로 이 점을 받아들이면 AI-DLC는 큰 코드베이스와 큰 팀에서 AI를 안전하게 쓰기 위한 구조가 된다.
AI-DLC가 잘 맞는 경우
AI-DLC는 모든 프로젝트에 맞는 방식은 아니다.
잘 맞는 경우는 다음과 같다.
- 기존 코드베이스가 크고 맥락 복원이 어려운 경우
- 여러 사람이 요구사항과 설계를 함께 검토해야 하는 경우
- 보안, 규제, 감사, 추적성이 중요한 경우
- AI가 만든 코드의 근거와 결정 과정을 남겨야 하는 경우
- 개발뿐 아니라 배포와 운영까지 같은 흐름에 넣고 싶은 경우
반대로 부담스러울 수 있는 경우도 있다.
- 개인이 빠르게 만드는 작은 실험
- 단순한 UI 수정
- 명확한 한 줄 버그 수정
- 문서화 비용이 결과물보다 큰 작업
- 스펙보다 빠른 프로토타입이 더 중요한 상황
물론 AI-DLC에도 poc, bugfix, refactor 같은 가벼운 scope가 있다. 하지만 방법론 자체의 방향은 여전히 “절차화, 산출물화, 승인 게이트”다. 이 비용을 감당할 이유가 있을 때 가치가 크다.
정리
AI-DLC를 “AWS가 만든 또 하나의 AI 코딩 워크플로” 정도로 보면 핵심을 놓친다.
AI-DLC의 진짜 변화는 개발의 시작점을 바꾸는 데 있다. 개발자는 완성된 요구사항을 AI에게 던지는 사람이 아니다. AI와 인터뷰하면서 요구사항을 도출하고, AI가 만든 산출물을 검토하고, 각 단계에서 승인하며, 생성된 코드가 실제 의도와 맞는지 검증하는 사람이 된다.
기존 개발에서 중요한 질문은 이것이었다.
누가 코드를 어떻게 구현할 것인가?
AI-DLC에서는 질문이 조금 바뀐다.
AI가 무엇을 기준으로 구현해야 하며, 사람은 어떤 지점에서 검증하고 승인할 것인가?
이 변화가 중요하다.
AI-DLC는 AI에게 개발을 통째로 맡기는 방식이 아니다. AI가 개발 생명주기의 많은 작업을 수행하게 하되, 사람의 맥락과 승인과 검증을 절차 안에 박아 넣는 방식이다.
그래서 AI-DLC의 핵심은 코딩 자동화가 아니라 개발 절차의 재설계다.