AI-DLC 그 이후: AI에게 어디까지 맡길 것인가에 따라 갈리는 개발 프로세스론

서론

2025년 7월 31일에 AWS가 AI-DLC (AI-Driven Development Life Cycle)를 제창한 이후, 곧 1년이 지나갑니다. 당초에는 "AI를 중심으로 개발 프로세스를 재구성하는" 방법론으로 제시되었으나, 그 이후의 논의는 아직 하나의 정답으로 수렴하지 않은 듯합니다.

지금 보이는 논의의 중심은 "AI를 사용할 것인가"가 아닙니다. AI에게 어디까지 실행을 위임할 것인가. 인간은 어느 시점에 관여할 것인가. 설계 의도나 아키텍처상의 일관성을 누가 유지할 것인가. 논점은 이 부근으로 옮겨가고 있는 것으로 보입니다.

본고에서는 공개된 자료와 논의를 바탕으로, 독자적인 관점에서 AI-DLC 주변의 입장을 세 가지로 정리합니다. 이는 AI와 인간의 역할 분담을 해석하기 위한 편의적인 분류입니다.

출발점으로서의 AI-DLC

AI-DLC는 기존의 SDLC (Software Development Life Cycle)에 AI를 사후에 추가하는 발상이 아니라, 개발 라이프사이클 그 자체를 AI 중심으로 재구성하는 제안입니다.

AWS의 원형에서는 AI 활용에 두 가지 안티 패턴 (Anti-pattern)이 있다고 했습니다. 하나는 AI를 보조적인 작업에 가두는 "AI 지원형". 다른 하나는 AI에게 모든 공정을 통째로 맡기는 "AI 자율형"입니다. AI-DLC는 그 중간을 목표로 했습니다.

기본이 되는 것은 "AI가 실행을 주도하고, 인간이 중요한 판단을 담당한다"는 사고방식입니다. AI는 계획을 세우고, 모호한 점을 질문하며, 요구사항, 설계, 코드, 테스트, IaC (Infrastructure as Code)까지 생성합니다. 다만, 중요한 판단에서는 인간의 확인을 기다립니다.

프로세스는 크게 Inception, Construction, Operations의 세 단계로 나뉩니다. 요구사항 정의는 Mob Elaboration, 설계와 구현은 Mob Construction으로서 진행됩니다. 기존의 스프린트 (Sprint)에 해당하는 긴 반복이 아니라, 몇 시간에서 며칠 단위의 Bolt로 세밀하게 진행한다는 점도 특징입니다.

즉 원형의 AI-DLC는 "AI가 제안하고 인간이 검증한다"가 아니라, "AI가 공정을 움직이고 인간이 요점을 잡는다"는 방법론이었습니다. 그 이후의 분기는 이 경계선을 어디에 긋느냐의 차이로 보면 이해하기 쉽습니다.

세 가지 입장

본고에서는 대략 다음과 같은 세 가지 계통으로 분류했습니다.

계통	AI의 역할	인간의 역할	적합한 문맥	우려 사항
공식·거버넌스계	공정 전체를 진행하고 결과물을 생성함	요점에서 검증·승인함	대규모 조직, 규제 산업, 표준화	의례화, 동기화 부하, 설계 사상의 유지
...
이하, 각각을 살펴보겠습니다.

공식·거버넌스계

첫 번째 계통은 AWS와 그 주변에서 추진하는 공식 노선입니다. 원형의 AI-DLC를 유지하면서 실운용에 맞춰 개정을 거듭하고 있습니다.

큰 움직임은 2025년 11월의 Adaptive Workflows 공개입니다. 여기에서는 모든 안건을 동일한 절차에 밀어 넣는 것, 공정별 깊이를 조정할 수 없는 것, AI의 자동화가 인간의 검증을 앞지르는 것이 과제로 꼽혔습니다. 그 대책으로서 안건에 따라 공정을 선택하고, 깊이를 바꾸며, 중요한 판단점에 인간의 확인을 삽입하는 방향으로 나아가고 있습니다.

나아가 awslabs/aidlc-workflows에서는 Amazon Q Developer나 Kiro뿐만 아니라, Cursor, Cline, Claude Code, GitHub Copilot 등 여러 에이전트 (Agent) 환경에 대응하는 형태로 확장되고 있습니다. 2.0 Preview에서는 AI 에이전트를 "검증 가능하고 자기 수정하는 엔지니어링 워크플로우"로 만들겠다는 방향성도 제시되었습니다.

이 계통이 중시하는 것은 속도만이 아닙니다. 요구사항, 설계, 코드, 테스트, IaC, 승인 기록을 연결하여 누가 무엇을 확인했는지를 남기는 것입니다. 금융 서비스 대상 기사에서도 인간의 감독, 판단 권한, 설명 책임을 다하는 것이 강조되고 있습니다. 배경에는 의료, 금융, 공공 등 감사나 규제 대응이 무거운 영역에서 AI 개발을 확산시키고 싶다는 사정이 있습니다.

한편, 비판 측이 문제 삼는 것은 승인 플로우나 감사 추적 (Audit Trail)만으로는 설계 의도나 아키텍처상의 일관성까지 보증할 수 없다는 점입니다. AI가 그때마다 그럴듯한 설계안을 내놓고 인간이 승인하는 형태라면, 개별 판단은 타당하더라도 반복을 거치며 설계 사상이 유지된다고 단정할 수 없습니다.

Peter Tilsen은 AI-DLC의 과제로 Conceptual Clarity, Reflection / Learning, Context Memory의 취급이 아직 약하다고 지적하고 있습니다. 이는 "공정을 어떻게 돌릴 것인가"뿐만 아니라 "공정을 넘나들며 무엇을 기억하고 어떤 설계 원칙을 유지할 것인가"라는 문제입니다.

공식계(Formal system)는 거버넌스를 강화하면서 AI의 실행력도 수용하는 방향으로 나아가고 있습니다. 다만, 팀 전원이 참여하는 동기적(Synchronous) 검증은 조직에 따라 부담이 될 수 있으며, 승인자가 반드시 장기적인 아키텍처 구상의 담당자라는 보장도 없습니다. 여기에 미해결된 논점이 남아 있습니다.

자율 에이전트계 (Autonomous Agent system)

두 번째 계통은 자율적인 코딩 에이전트(Coding Agent)를 전제로, AI-DLC를 보다 경량화하여 재해석하려는 움직임입니다. AWS의 "팀이 AI를 둘러싸는" 형태보다는, 한 명의 개발자와 에이전트가 고속으로 개발을 진행하는 상황을 주로 상정합니다.

대표적인 예 중 하나가 Bushido Collective의 "AI-DLC 2026"입니다. 여기서는 Elaboration, Execution, Operation, Reflection의 4단계를 채택합니다. git worktree, 테스트, lint, 타입 체크(Type check), Pull Request, 배포 플로우를 조합하여, 품질 게이트(Quality gate)를 통과하지 못하면 다음 단계로 진행할 수 없는 메커니즘을 중시합니다.

기본이 되는 사고방식은 "완료 기준(Definition of Done)이 명확하다면, 인간의 감독은 최소화할 수 있다"는 것입니다. 무엇을 충족해야 완료되는지를 먼저 정의하고, 실행은 에이전트에게 맡깁니다. 중간 과정의 문맥(Context)은 파일이나 커밋된 결과물에 남깁니다. 인간이 매번 모든 것을 감시하는 것이 아니라, 기준, 테스트, 타입, PR을 통해 제어하는 방식입니다.

specs.md 또한 사양 생성만을 수행하는 Simple Flow, 보다 경량화된 실행을 포함하는 FIRE Flow, AI-DLC를 본격적으로 구현하는 AI-DLC Flow로 나누어져 있습니다. 이 역시 상황에 따라 방법론의 무게감을 선택하는 발상입니다.

이 계통의 관심사는 승인 플로우를 두텁게 만드는 것보다, 에이전트에게 작업을 맡겼을 때 제어력을 잃지 않는 것에 있습니다. 대화 세션이 바뀌더라도 의도나 진척도를 잃지 않아야 하며, 실패할 경우 테스트나 타입 체크에서 멈춰야 하고, 결과물은 리뷰 가능한 크기의 변경 단위로 분할되어야 합니다. 따라서 인간이 매번 순차적으로 감독하는 대신, 목적, 완료 조건, 체크 절차를 미리 명문화하여 에이전트가 그 범위 내에서 자율적으로 움직일 수 있도록 합니다.

약점은 기준으로 정의하기 어려운 항목을 다루는 문제입니다. 테스트나 타입으로 잡아낼 수 있는 오류는 막을 수 있어도, 책임 분담의 붕괴, 기존 패턴으로부터의 이탈, 향후 변경 여지(Extensibility)와 같은 관점은 놓치기 쉽습니다. 개별 변경 사항은 문제없이 동작하더라도, 전체적으로 설계가 조금씩 어긋나는 문제는 실무에서 architectural drift(아키텍처 드리프트)라고 불리기도 합니다.

Reflection은 배움을 남기는 메커니즘이지만, 그 자체가 설계 사상을 계속 유지하는 주체가 되는 것은 아닙니다. 자율계에서는 인간이 처음에 부여하는 의도와 완료 기준의 질이 최종적인 품질을 크게 좌우합니다.

인간 이해·규율계 (Human-centric/Discipline system)

세 번째 계통은 과도한 자동화에 신중한 입장입니다. AI를 부정하는 것은 아니지만, 인간이 설계와 이해를 놓아버리는 것을 경계합니다.

대표적인 비판으로 "agentic-waterfall"이 있습니다. 여기서는 동기적인 AI 페어 프로그래밍(Pair programming)과 비동기적으로 움직이는 자율 에이전트가 구분됩니다. 전자의 경우 인간은 AI의 작업을 지켜보며 멈추고, 수정하고, 토론할 수 있습니다. 후자의 경우 AI가 사양을 전달받아 독립적으로 구현한 뒤 마지막에 PR을 제출합니다. 비판론자들은 이 비동기형 모델이 구조적으로 워터폴(Waterfall) 모델로의 회귀라고 주장합니다. 구현과 리뷰가 분리되어 피드백이 늦어지고, 문맥을 다시 읽어들이는 과정이 필요하기 때문입니다.

엔터프라이즈 개발 측면에서의 비판도 유사한 입장입니다. 대규모의 장수명(Long-lived) 시스템에서는 AI가 생성한 코드라 할지라도 인간이 의도, 영향 범위, 기존 제약 사항, 과거의 실패 사례를 이해해야 합니다. 문제는 코드의 줄 수가 아니라, 그 변경이 시스템 전체에 어떤 영향을 미치는가 하는 점입니다.

이 계통의 입장에서는 인간이 단순한 승인자가 아닙니다. 설계 의도, 책임 분담, 제약 사항, 판단 근거를 제시하는 역할을 맡습니다. AI는 수족으로서 코드와 테스트를 고속으로 생성하지만, 설계의 방향을 잡고 이해하는 것은 인간의 역할입니다.

다만 이 입장에도 약점은 있습니다. AI가 대량의 변경을 만들어내는 상황에서 인간이 모든 것을 계속 이해하고 있기는 어렵습니다. AI의 장점인 속도 또한 저하됩니다. 또한, 이는 유지보수 책임을 지는 시니어 엔지니어나 엔터프라이즈 측의 입장이 강하게 반영된 관점이라는 반론이 있을 수 있습니다.

따라서 최근의 논의에서는 인간이 모든 출력을 일일이 확인하느냐, 아니면 AI에게 완전히 맡기느냐라는 이분법적 선택이 아니게 되고 있습니다. Martin Fowler 사이트의 논의에서는 인간이 AI의 작업 루프(Work loop) 안에 들어올 뿐만 아니라, 사양(Specification), 테스트, 품질 체크, 설계 규칙, 리뷰 관점을 포함하는 '하네스(Harness)'를 설계하고 개선하는 역할이 제시되고 있습니다. 인간의 업무는 개별 결과물을 수정하는 것에서, AI가 좋은 결과물을 내기 쉬운 환경을 만드는 것으로 확장되고 있습니다.

횡단하는 실천: 사양 주도와 하네스

세 가지 계통을 횡단하는 실천으로서 사양 주도 개발(Spec-Driven Development)이 있습니다. 이는 AI에게 코드를 작성하게 하기 전에 사양을 먼저 작성하는 사고방식입니다. 사양을 단 한 번만 사용하는 spec-first, 유지보수에도 계속 사용하는 spec-anchored, 사양을 주요 결과물로 삼고 코드를 생성물로 간주하는 spec-as-source는 그 의미가 크게 다릅니다.

사양 주도는 독립된 네 번째 유파라기보다, 어떤 계통에도組み込める(결합할 수 있는) 직교하는 사고방식입니다. 공식 계통에서는 감사 가능한 결과물이 되고, 자율 계통에서는 완료 기준이 되며, 규율 계통에서는 인간이 설계 의도를 남기는 매체가 될 수 있습니다.

마찬가지로 중요한 것이 하네스(Harness)의 개념입니다. AGENTS.md, architecture.md, 설계 규칙, 정적 분석, 구조 테스트, 커스텀 lint, 리뷰용 에이전트, CI 상의 평가 등을 조합하여 AI의 생성을 전후에서 제어합니다. 이는 인간의 이해를 완전히 대체하는 것은 아니지만, 암묵지나 설계 원칙을 실행 가능한 형태로 근접시키려는 시도입니다.

요약

AI-DLC 이후에 베스트 프랙티스로서 통일된 방법론이 탄생한 것은 아닙니다. 오히려 다루는 시스템이나 팀의 규모, 감사, 유지보수 요구사항에 따라 합리적인 경계선이 달라진다는 점이 보이기 시작했습니다.

공식·거버넌스 계통은 AI에게 공정을 움직이게 하면서 인간의 승인과 추적 가능성을 높입니다. 자율 에이전트 계통은 완료 기준과 품질 게이트(Quality gate)를 중시하며 실행을 최대한 AI에게 위임합니다. 인간 이해·규율 계통은 설계와 문맥을 이해하는 주체로서 인간을 남겨둡니다. 차이는 AI를 어디까지 신뢰하느냐에 있습니다. 장기적인 기술 비전까지 위임할 것인가, 상세 설계부터 위임할 것인가, 코드 생성만을 위임할 것인가. 그 차이에 따라 적절한 프로세스의 형태는 달라집니다.

다만, 최신 실천에서는 수렴해 가는 부분도 있습니다. 공식 계통은 Adaptive Workflows나 2.0 Preview를 통해 AI를 '검증 가능하고 자기 수정하는 워크플로'에 편입시키는 방향으로 나아가고 있습니다. 이는 자율 계통이 중시해 온 완료 기준 및 품질 게이트와 거의 같은 발상입니다. 반대로 규율 계통이 놓지 않으려 했던 설계 의도나 드리프트(Drift) 탐지 역시, 2026년 초에 확산된 "Agent = Model + Harness"라는 관점 아래에서 가이드와 센서의 설계 문제로 논의되기 시작했습니다. 사양 주도와 하네스는 이제 어떤 계통에서도 참조되는 공통 기반이 되어가고 있습니다.

결정적인 도구(lint, 타입, 구조 테스트)는 중복이나 복잡도, 아키텍처 드리프트(Architectural drift)와 같은 구조적 일탈을 포착합니다. LLM에 의한 판단은 의미적 중복이나 과잉 구현을 확률적일지라도 잡아내려 합니다. 이 모두는 지금까지 인간이 암묵적으로 담당해 온 판단을 실행 가능한 형태로 외부화하려는 시도입니다. 즉, 최신 노력의 상당수는 '승인'을 넘어 '구상'의 일부까지 기계적으로 대응 가능하게 만들려 하고 있습니다.

하지만 여기에는 한계도 남아 있습니다. 설계 의도의 오독, 과도한 구현, 지시 사항의 착오와 같이 영향력이 큰 오류에 대해서는 현재로서는 유효한 대응 방법이 없습니다. '승인과 구상은 같지 않다'는 문제는 하네스를 통해 경감할 수는 있어도 사라지지는 않습니다. 복잡한 시스템에서는 책임 분담, 제약, 과거의 판단 이유, 피해야 할 방향성이 코드, 문서, 이력, 암묵지에 분산되어 있으며, 그 전체상을 파악하는 주체는 아직 완전히 기계로 대체될 수 없습니다.

AI 개발 프로세스의 선택은 결국 어디까지 AI에게 맡길 것인가로 귀결되며, 이는 동시에 인간이 떠맡을 책임의 형태를 선택하는 것이기도 합니다. 그리고 수렴이 진행될수록 그 책임은 개별 결과물을 승인하는 것에서, AI가 좋은 구상을 유지하기 쉬운 하네스 그 자체를 설계하고 계속해서 유지보수하는 것으로 옮겨갈 것으로 보입니다.

참고

AWS 공식·관련

AI-Driven Development Life Cycle: Reimagining Software Engineering (AI-주도 개발 생명 주기: 소프트웨어 엔지니어링의 재구상)
Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC) (AI-주도 개발 생명 주기(AI-DLC)를 위한 적응형 워크플로우 오픈 소스화)
awslabs/aidlc-workflows
AI-Driven Development Lifecycle for Financial Services (금융 서비스를 위한 AI-주도 개발 생명 주기)

커뮤니티 및 파생

TheBushidoCollective/ai-dlc
specs.md: The AI-Native SDLC: Reimagined (specs.md: AI-네이티브 SDLC: 재구상)
AI-DLC Flow Overview (AI-DLC 흐름 개요)
The AI-DLC Handbook (AI-DLC 핸드북)

비판 및 검토

The AI-Driven Development Lifecycle (AI-DLC): A critical, yet hopeful view (AI-주도 개발 생명 주기(AI-DLC): 비판적이면서도 희망적인 관점)
agentic-waterfall (에이전트 기반 폭포수 모델)
The Vibe Check Failed (바이브 체크 실패)
What is AI-DLC? (AI-DLC란 무엇인가?)

Insights

AI-DLC 그 이후: AI에게 어디까지 맡길 것인가에 따라 갈리는 개발 프로세스론

요약

핵심 포인트

서론