AI-DLC v2는 기존 AI 개발 도구와 무엇이 다른가

이 글은 AI 기반 개발 방법론을 검토 중인 개발 리더와 아키텍트를 위해 썼습니다. 다 읽고 나면 AI-DLC(AI-Driven Development Life Cycle)가 GitHub Spec Kit, Kiro, BMAD-METHOD 같은 도구와 어디서 같고 어디서 다른지, 그리고 도입 전에 무엇을 점검해야 하는지 판단할 수 있습니다. 내용은 2026년 9월 공개된 AI-DLC v2를 기준으로 합니다.

AI-DLC는 어떤 문제의식에서 나왔나

AI를 개발에 쓰는 방식은 지금까지 크게 두 갈래였습니다. 하나는 코드 자동완성이나 테스트 작성을 돕는 보조형이고, 다른 하나는 한 문단의 요구사항만으로 애플리케이션 전체를 만들어 내는 자율형입니다. AWS는 2025년 7월 AI-DLC를 소개하면서 두 방식 모두 속도나 품질 중 한쪽에서 아쉬움이 남는다고 보고, AI를 개발 전 과정의 중심 협업자로 두는 방식을 제안했습니다(AWS DevOps Blog).

AI-DLC는 기존 개발 프로세스에 AI를 덧붙이지 않습니다. 사람 중심 프로세스에서 생겨난 계획 회의 같은 부수 활동을 줄이도록 생애주기 자체를 다시 설계했습니다(AI-DLC 2026 paper). AI는 상세 작업 계획을 세우고 불명확한 부분을 먼저 질문하며, 비즈니스 맥락이 필요한 결정은 사람에게 넘깁니다.

핵심 개념

AI-DLC는 작업을 다음 순서로 다룹니다.

개념	의미
의도(Intent)	이번에 달성하려는 비즈니스 목표
작업 단위(Unit)	Intent를 독립적으로 진행할 수 있게 나눈 묶음
실행 주기(Bolt)	몇 시간에서 며칠 단위의 짧고 집중된 구현 주기
공동 정제(Mob Elaboration)	팀과 AI가 한자리에서 요구사항을 함께 다듬어 초기에 모호함을 걷어내는 방식

생애주기는 기획(Inception), 구축(Construction), 운영(Operations) 세 단계로 나뉘며, 단계마다 입력, 산출물, 의사결정 지점이 정해져 있습니다(AIDLC Collaborative Docs).

v2에서 달라진 점

AWS는 v2(Adaptive Workflows)를 공개하면서 v1의 한계 두 가지를 직접 짚었습니다. 모든 프로젝트를 같은 단계로 진행하게 하는 획일적인 워크플로와, 단계별 깊이를 조절하기 어려운 점입니다(AWS DevOps Blog, Adaptive Workflows). v2는 이를 해결하기 위해 구조를 크게 바꿨습니다(awslabs/aidlc-workflows).

역할 에이전트 오케스트레이션. v1은 하나의 LLM이 마크다운 규칙을 따라 움직였습니다. v2에서는 PM, UX, 애플리케이션 아키텍트, 시스템 아키텍트, 아키텍처 리뷰어, 개발자, 코드 리뷰어 같은 역할 에이전트를 두고, 사용자와 대화하는 오케스트레이터가 단계마다 필요한 에이전트를 부릅니다. 프로젝트 성격에 맞춰 어떤 단계를 어떤 순서로 거칠지도 그때그때 구성합니다.

2단계 승인. 각 단계는 리뷰 에이전트의 판정(READY 또는 NOT-READY)과 사람의 승인을 모두 거칩니다. 단계별로 완전 자동(full)과 사람 감독(supervised) 중 하나를 고를 수 있습니다.

추적 가능한 상태 기록. 진행 상태와 승인 이력이 state.json, audit.json, workflow.json 파일과 YAML 원본(엔터티, 규칙, 계약)으로 남습니다. 문서 내용이 서로 다르면 YAML 원본을 기준으로 삼습니다.

사람의 역할 변화. v1에서는 사람이 마크다운 문서를 읽고 질문 항목에 직접 답을 채워야 했습니다. v2에서는 에이전트가 문서를 읽고 정리하며, 사람은 요약을 검토해 승인합니다. 도입 부담은 줄었지만, 사람이 세부 내용을 확인하지 않고 승인할 여지도 커졌다는 점은 함께 기억해 둘 필요가 있습니다.

v2는 특정 도구에 묶이지 않으며 Kiro IDE와 Kiro CLI, Claude Code, Codex, Cursor, GitHub Copilot에서 사용할 수 있습니다.

다른 오픈소스 방법론과 무엇이 같은가

현재 AI 개발 방법론은 명세 주도 개발(Spec-Driven Development, SDD) 계열이 주류입니다. 대표적인 도구는 다음과 같습니다.

GitHub Spec Kit: 슬래시 커맨드로 명세 작성부터 구현까지 진행하며, 프로젝트 최상위 규칙 문서를 constitution이라고 부릅니다.
Kiro: 기능마다 requirements.md, design.md, tasks.md를 남기는 Spec 기능을 IDE 수준에서 제공합니다.
BMAD-METHOD: 단계별로 역할 에이전트를 나누고, 에이전트끼리 파일을 주고받으며 진행합니다.
OpenSpec, Tessl 등: 저장소 안의 마크다운 명세와 스캐폴딩 도구를 중심으로 동작합니다.

이 도구들은 독립적으로 출발했지만 비슷한 구조에 도달했습니다(Nimbalyst, 2muchcoffee). 명세가 기준이 되고 코드는 그 결과물로 취급됩니다. 진행은 대부분 명세 작성, 계획, 작업 분해, 구현의 4단계를 따릅니다. 단계마다 사람이 산출물을 읽고 승인해야 하며, 프로젝트 전반의 규칙 문서와 기능별 명세를 나눠 관리합니다. AI-DLC도 이 흐름을 그대로 포함합니다.

무엇이 다른가

차이는 다루는 범위와 협업 방식에서 드러납니다.

항목	AI-DLC v2	GitHub Spec Kit	Kiro Spec	BMAD-METHOD
성격	개발 생애주기 방법론	SDD 툴킷	IDE에 내장된 SDD 기능	역할 에이전트 방법론
범위	기획, 구축, 운영	명세에서 구현까지	명세에서 구현까지	명세에서 구현까지
에이전트 구성	역할 에이전트 + 오케스트레이터	단일 에이전트 중심	단일 에이전트 중심	역할별 에이전트
승인 방식	리뷰 에이전트 + 사람	단계별 사람 검토	단계별 사람 검토	단계별 사람 검토
팀 협업 방식	Mob Elaboration, Mob Construction	별도 규정 없음	별도 규정 없음	별도 규정 없음
실행 환경	Kiro, Claude Code, Codex, Cursor, Copilot	여러 코딩 에이전트	Kiro IDE, Kiro CLI	여러 코딩 에이전트

표의 "단일 에이전트 중심"과 "별도 규정 없음"은 각 도구의 공개 문서에 해당 기능이 명시되어 있지 않다는 뜻이며, 확장 기능이나 사용 방식에 따라 달라질 수 있습니다.

정리하면, SDD 도구들은 명세에서 구현까지 개발 전반부에 집중합니다. AI-DLC는 같은 흐름 위에 운영 단계, 역할 에이전트 오케스트레이션, 팀 단위 협업 방식을 더한 방법론입니다. 같은 Kiro 환경에서 일한다면 Kiro Spec은 기능 단위 명세 도구로, AI-DLC는 그 위에서 프로젝트 전체를 이끄는 방법론으로 구분해 보면 이해하기 쉽습니다.

도입 전에 알아 둘 한계

병목이 코드 작성에서 검증으로 옮겨갑니다. AI가 코드, 테스트, IaC를 몇 시간 만에 만들어 내면 개발 속도를 묶는 요인은 코드 리뷰 대기열, 보안 점검, 거버넌스 처리 용량이 됩니다(Wiz Academy). 리뷰와 스캔이 자동화되어 있지 않으면 생성 속도가 그대로 대기열에 쌓일 수 있습니다.

코드와 런타임 동작 사이의 차이를 따로 확인해야 합니다. 저장소의 코드만으로는 배포 후 어떤 자격 증명, 데이터, 네트워크 경로를 실제로 쓰는지 알기 어렵습니다. 생성량에 맞추려면 정적 분석(SAST), 오픈소스 구성 분석(SCA), 시크릿 스캔, IaC 스캔을 지속적으로 실행하고, 런타임 검증과 승인 이력 기록을 함께 갖추는 것이 좋습니다(Wiz Academy).

방법론을 운영하는 데 시간이 듭니다. v2는 단계를 꼼꼼히 거치는 만큼 짧은 워크숍 안에 끝내기 어려울 수 있습니다. 첫 과제는 기획 단계에서 범위를 좁혀 시작하는 편이 안전합니다.

기존 시스템 고도화(Brownfield)는 준비가 더 필요합니다. 레거시 코드, 불완전한 문서, 흩어진 아키텍처 지식은 LLM 기반 개발에서 고유한 어려움을 만듭니다(arXiv 2512.01155). AI-DLC는 현재 상태, 추가할 것, 바꾸면 안 되는 것을 나눠 적는 Vision 문서로 이를 보완합니다. 여러 저장소와 소유권 경계, 생략할 수 없는 변경관리 절차가 있는 대규모 조직이라면 이 조건까지 함께 설계해야 합니다(DataOps Labs).

시작할 때 점검할 것

코드 리뷰와 보안 스캔이 어느 정도 자동화되어 있는지 먼저 확인합니다.
첫 과제는 2주 스프린트 안에 끝낼 수 있는 실제 업무로 범위를 정합니다.
기존 시스템을 고도화한다면 "바꾸면 안 되는 것"을 팀이 먼저 합의합니다.
아키텍처, 보안, 데이터처럼 영향이 큰 단계는 사람 감독(supervised) 모드로 두고, 요약뿐 아니라 원문 검토를 승인 조건에 넣습니다.