생성형 AI (Generative AI)를 소프트웨어 개발에 도입하는 움직임이 진행되는 가운데, 많은 현장에서는 "AI를 코드 보완 어시스턴트로 사용"하거나 "AI에게 통째로 생성하게 하기"의 양자택일로 흐르기 쉽습니다. 하지만 둘 다 개발 속도와 품질의 양립이라는 측면에서는 아쉬움이 남습니다.

그러한 가운데, AWS가 AI-DLC (AI-Driven Development Life Cycle)

라는 방법론을 제창하고, 워크플로우의 규칙군을 오픈 소스 (Open Source)로 공개했습니다. AI를 "보조"가 아닌 "개발의 추진역"으로 세운다는 발상의 전환이 특징입니다.

이번에는 이 AI-DLC가 어떤 사고방식의 방법론인지, 공식 블로그와 GitHub 리포지토리(Repository)에 더해 AWS가 공개하고 있는 방법론 정의 페이퍼 (Method Definition Paper, Raja SP 저)를 바탕으로 정리합니다. 용어 · 10가지 원칙 · 3단계 페이즈 · 기존 수법과의 대비까지 파악하여 전체상을 잡는 것을 목적으로 합니다. 실제로 코딩 에이전트 (Coding Agent)에組み込んで 구동하는 검증은 다음 회로 미룹니다.

항목	내용
이것은 무엇인가	AI를 개발 라이프사이클 (Life Cycle) 전체의 추진역으로 세우고, 인간이 요점의 의사결정을 담당하는 AWS 발(發) AI 네이티브 개발 방법론
...
기사에서 반복해서 등장하는 용어를 먼저 정리합니다. 정의는 방법론 정의 페이퍼에 기반합니다.

용어	의미
AI-DLC	AI-Driven Development Life Cycle. AI를 라이프사이클 전체의 중심에 세운 AI 네이티브 개발 방법론
...
AI-DLC의 위치를 파악하기 위해, 전통적인 워터폴 (Waterfall) 및 Agile (Scrum)과의 차이점을 정리합니다.

관점	워터폴 (Waterfall)	Agile (Scrum)	AI-DLC
진행 방식	요구사항 → 설계 → 구현 → 테스트 → 운영을 전 공정 완료 후 순차적으로 실행	짧은 스프린트 (Sprint)로 반복적으로 개발	AI가 Level 1 Plan을 제안하고, 인간의 검증을 거치며 반복
...
워터폴은 공정이 일방향이라 후속 공정으로 갈수록 되돌아오는 비용(Retake Cost)이 높아지는 것이 약점이었습니다. Agile은 그것을 짧은 반복으로 극복했지만, 설계 기법을 팀에 맡긴 결과 품질의 편차라는 과제가 남았습니다.

AI-DLC는 이 두 가지의 연장선상이 아니라 "제1원리로부터의 재설계 (Reimagine rather than Retrofit)"를 내걸고 있습니다. 반복 사이클을 몇 시간 ~ 며칠 단위의 Bolt까지 단축하고, 설계 기법을 코어로 도입하며, AI가 대화를 주도함으로써 워터폴의 약점(되돌아오는 비용)과 Agile의 과제(설계의 편차) 모두에 동시에 대응하려 하고 있다고 읽을 수 있습니다.

방법론 정의 페이퍼는 AI-DLC의 토대로서 다음의 10가지 원칙을 들고 있습니다.

원칙	요지
1. Reimagine rather than Retrofit	기존의 SDLC/Agile에 AI를 사후에 붙이는 것이 아니라, 제1원리로부터 재설계한다. "빠른 마차 대신 자동차가 필요하다"
...
공식 블로그에서도 이 방법론의 본질이 다음과 같이 제시되어 있습니다.

AI-DLC is an AI-centric transformative approach to software development that emphasizes two powerful dimensions: AI Powered Execution with Human Oversight ... and Dynamic Team Collaboration ...

요컨대, AI에게 전적으로 맡기는 것도 인간에게만 맡기는 것도 아니며, AI가 실무를 수행하면서 요점에서 인간이 키를 잡는 협업 모델입니다.

AI-DLC의 핵심은 "AI가 Level 1 Plan (구현 흐름)을 제안한다 → 인간이 검증·수정한다 → 더욱 서브 태스크 (Sub-task)로 분해한다"라는 재귀적인 루프입니다. 각 단계는 전략적인 의사결정 포인트이며, 인간의 감독이 loss function 처럼 작동하여 오류가 하류로 눈덩이처럼 커지기 전에 잘라냅니다.

생성된 성과물 (Intent · 유저 스토리 · 도메인 모델 · 테스트 계획 등)은 모두 영속화되어, AI가 라이프사이클 전체에서 참조하는 "컨텍스트 메모리 (Context Memory)"가 됩니다. 성과물은 상호 연결되어 전방·후방의 추적성 (Traceability, 예: 도메인 모델 요소와 특정 유저 스토리의 대응)이 확보됩니다.

이를 바탕으로 개발은 3가지 페이즈로 진행됩니다.

페이즈	AI의 역할	주요 의식(Ritual)·산출물
Inception (구상)	Intent(의도)를 유저 스토리(User Story)·NFR(비기능 요구사항)·리스크로 분해하여 Unit으로 구성	Mob Elaboration. 산출물은 PRFAQ, 유저 스토리, NFR, 리스크 기술, 측정 기준, 권장 Bolt
...

각 페이즈가 더 풍부한 문맥(Context)을 다음 단계로 전달함으로써, AI의 제안이 단계적으로 정확해집니다.

이 왕복 구조를 시계열(위에서 아래로)에 따른 '인간·AI·산출물'의 역할 분담으로 나열하면 다음과 같습니다. 인간과 AI가 각 단계에서 검증 및 제안을 주고받으며, AI가 생성한 산출물이 컨텍스트 메모리(Context Memory)로서 다음 단계로 인계됩니다.

인간 / Mob	AI	산출물 (컨텍스트 메모리)
Intent (의도)를 제시	Intent를 인식하고 Level 1 Plan을 생성	Level 1 Plan
...

표를 읽는 방법은 다음과 같습니다.

• 위에서 아래로 시계열로 진행되며, Inception → Construction → Operations 순으로 페이즈가 이동합니다.
• 인간과 AI는 각 행에서 제안과 검증을 주고받습니다 (Mob Elaboration / Mob Construction의 실시간 검증 루프).
• AI가 생성한 산출물은 영속화되어, 다음 단계 AI의 입력값 (컨텍스트 메모리)이 됩니다.

방법론 정의 페이퍼(Methodology Definition Paper)는 신규 개발과 기존 수정의 두 가지 시나리오로 구체적인 예를 보여줍니다.

• Green-Field (신규 개발): Product Owner가 "교차 판매(Cross-sell)를 위한 추천 엔진을 개발한다"와 같은 고수준의 Intent를 제시합니다. AI가 Level 1 Plan을 생성하고, 팀이 이를 검증한 후 Inception → Construction → Operations로 진행합니다. Inception 단계에서는 "주요 사용자는 누구인가"와 같은 명확화 질문부터 시작합니다.
• Brown-Field (기존 수정): 신규 기능 추가, NFR 최적화, 기술 부채 상환 등입니다. Construction 페이즈에서 먼저 AI가 기존 코드를 의미적으로 풍부한 모델 표현(정적 모델/동적 모델)으로 "끌어올리고(Lift) ", 개발자가 이를 검증 및 수정합니다. 이후의 흐름은 Green-Field와 동일합니다.

AI-DLC는 코딩 에이전트(Coding Agent)를 위한 스티어링 규칙(Steering Rules)

으로 제공됩니다. 프로젝트의 워크스페이스에 규칙 그룹을 배치하고 대응하는 에이전트에 로드함으로써, AI가 AI-DLC의 3단계 워크플로우에 따라 행동하게 됩니다.

지원 플랫폼은 폭넓으며, Kiro, Amazon Q Developer IDE Plugin, Cursor IDE, Cline, Claude Code, GitHub Copilot, OpenAI Codex가 지원됩니다. 예를 들어 Kiro의 경우, Kiro Steering Files로서 규칙을 .kiro/steering/

하위에 배치하는 형태가 됩니다.

또한, 방법론 정의 페이퍼의 Appendix A에는 AI와 상호작용하기 위한 프롬프트 예시가 수록되어 있습니다. 모든 산출물을 aidlc-docs/

하위(plans·requirements·story-artifacts·design-artifacts 등)에 저장하고, 계획을 승인한 후 작업을 진행하는 운영 방식이 제시되어 있습니다.

도입을 용이하게 하기 위한 접근법으로 페이퍼는 다음 두 가지를 꼽고 있습니다.

• Learning by Practicing: AI-DLC는 일련의 의식(Mob Elaboration / Mob Construction 등)이므로, 문서나 이론 학습이 아닌 실제 프로젝트에서 실천하며 습득합니다. AWS의 Solution Architect가 AI-DLC Unicorn Gym이라는 필드 오퍼링(Field Offering)으로 제공하고 있습니다.
• 개발자 경험(Developer Experience) 도구로의 통합: SDLC를 가로지르는 자사 오케스트레이션 도구(Cognizant FlowSource, Aspire CodeSpell, HCL AIForce 등)에 AI-DLC를 내장하여, 대규모 조직에서도 자연스럽게 실천할 수 있도록 합니다.

제약 및 전제 조건으로는 다음 사항들이 있습니다.

• 대상은 복잡한 시스템: 높은 설계 복잡성 및 다수의 트레이드오프 (Trade-off)를 수반하는 대규모/규제 하의 시스템 대상. 단순한 계통은 로우코드/노코드 (Low-code/No-code)가 적합
• 인간의 개입이 필수: 검증·의사결정·감독의 최종 책임은 개발자가 가짐. AI에 대한 완전한 방임은 상정되지 않음
• 팀 협업을 전제로 함: Mob Elaboration / Mob Construction은 「한 공간·공유 스크린·퍼실리테이터」를 상정한 협업 의식

여기에서는 기존의 플로우(시험 계획 → 테스트 데이터 → TDD → lint → PR → MR 리뷰)를 AI-DLC 지향적, 즉 AI-Driven 방식으로 재편하여 운영하는 방법을 정리합니다. 아래의 절차는 아직 실행하지 않은 설계 단계의 내용입니다 (※ 미검증). 실제 실행 로그는 다음 기사에서 다룹니다.

사용하는 도구는 코딩 에이전트 (Kiro CLI 또는 Amazon Q Developer)와, awslabs/aidlc-workflows가 배포하는 스티어링 룰 (Steering Rule)을 상정합니다.

• GitHub의 Releases에서 룰 ZIP 파일을 다운로드하여 Kiro의 스티어링 디렉터리로 배치합니다 (※ 아래는 미실행된 절차).

mkdir -p .kiro/steering
cp -R ~/Downloads/aidlc-rules/aws-aidlc-rules .kiro/steering/
cp -R ~/Downloads/aidlc-rules/aws-aidlc-rule-details .kiro/

• 이와 함께 결과물을 축적할 폴더 (컨텍스트 메모리 (Context Memory))를 준비합니다. 방법론 정의 페이퍼의 Appendix A에서는 aidlc-docs/ 하위 (plans・requirements・story-artifacts・design-artifacts 등)에 저장하는 운영 방식이 제시되어 있습니다.

이 부분이 가장 큰 전환점입니다. 인간이 절차를 나열하는 것을 그만두고, 의도(Intent)만을 AI에게 전달하여 AI가 Level 1 Plan을 제안하게 합니다.

• 다음과 같은 의도를 AI에게 전달합니다 (프롬프트 예시).

컴포넌트 X의 결합 시험을 완료하고 싶다.
사양서는 specs/ , 설계서는 design/ 에 있다.
결합 시험의 계획부터 검증까지의 진행 방식 (Level 1 Plan)을 제안해 주길 바란다.
...

• AI가 「시험 계획 → 테스트 데이터 → TDD → lint/security → PR → MR 리뷰」에 해당하는 흐름을 스스로 제안합니다. 인간은 그것을 리뷰하고, 과잉 또는 부족한 부분을 조정합니다 (Mob Elaboration에 해당). 여기서 인간은 「절차를 쓰는 사람」이 아니라 「승인하는 사람」으로 돌아갑니다.

승인한 Level 1 Plan에 따라 각 단계를 AI 주도로 진행합니다. 인간은 검증·승인에 집중합니다.

단계	AI 주도 운영 방식	결과물 저장 위치
시험 계획	AI가 설계서를 읽고, 시험 계획 초안과 관점의 누락을 제시. 인간이 승인	aidlc-docs/test-artifacts/plan.md
...

각 단계에서 AI가 생성한 결과물을 aidlc-docs/에 축적하고 링크함으로써, AI가 항상 이전 공정의 문맥 (컨텍스트 메모리 (Context Memory))을 참조할 수 있습니다. 사양 ↔ 시험 계획 ↔ 테스트 데이터 ↔ 결과의 추적성 (Traceability)이 유지됩니다.

갑자기 모든 공정을 돌리면 부담이 크므로, 우선 1개 컴포넌트 × 단계 1~3 (시험 계획 → 테스트 데이터 → TDD)으로 범위를 좁혀 왕복 과정을 체감해 보는 것을 추천합니다. 나머지 lint/PR/MR은 동일한 「AI 제안 → 인간 승인」 패턴의 확장입니다.

또한, Bolt (수 시간~수일의 반복)나 Mob (한 공간에 집합)와 같은 AI-DLC 의식을 단일 시험 단계에 억지로 도입할 필요는 없습니다. 이식해야 할 핵심은 「AI가 계획을 제안하고 인간이 검증하는 왕복 루프」와 「컨텍스트 메모리 (Context Memory)」 이 두 가지입니다.

• AI를 「어시스턴트」가 아닌 「추진역」으로 교체하고, 대화의 주도권까지 반전시키는 발상이 신선했습니다. 기존의 Agile에 생성형 AI를 사후에 추가하는 형태가 아니라, 라이프사이클 그 자체를 제1원리 (First Principles)로부터 재설계하고 있다는 점이 본질적인 차이라고 느낍니다.
• 인간의 검증을 loss function

（하류의 낭비를 조기에 제거하는 메커니즘）으로 파악하는 사고방식은, 임기응변식의 프롬프팅 (Vibe Coding)에서 규율 있는 엔지니어링으로 전환하려는 목적을 명확히 나타내고 있다고 생각합니다. 설계 기법 (DDD/BDD/TDD)을 방법론의 핵심에 통합하고 있는 점은 품질의 편차를 억제하는 데 실무적으로 효과적일 것 같습니다. 특히 DDD 스타일은 Unit을 느슨하게 결합된 경계가 있는 컨텍스트 (Bounded Context)로 분할하여 병렬 개발하려는 목적이 명확했습니다.

• 현장에서도 요구사항의 모호함이 재작업을 유발하기 쉬우므로, Inception 단계의 Mob Elaboration (명확화 질문 → 유저 스토리 · NFR · 리스크 합의)은 특히 효과적일 것이라고 생각합니다.
• 한편, Bolt (수 시간 ~ 수 일)라는 짧은 사이클이나 「한 방에 모이는 Mob」 형식은, 리모트 중심의 팀이나 기존 스크럼 (Scrum) 운용과의 조율이 필요할 것 같습니다. 도입 시의 체인지 매니지먼트 (Change Management)가 관건이 될 것입니다.
• 다음 단계로서, 본 기사의 실천 섹션에서 정리한 진행 방식을 실제로 돌려보고 싶습니다. 우선 작은 Unit을 하나, Kiro 혹은 Amazon Q Developer로 Inception → Construction까지 통과시켜, 체감 속도와 품질을 검증하여 다음 기사에 정리할 예정입니다.

배움을 심화하는 과정에서, 기존의 개발 플로우에 「AI 리뷰」, 「AI에 의한 테스트 생성」, 「AI로 PR 작성」을組み込어도(組み込んでも), AI-DLC가 지향하는 모습에는 도달할 수 없다는 것을 깨달았습니다. 방법론 정의 페이퍼는 이 차이를 AI-Assisted (AI가 특정 태스크를 보조)와 AI-Driven (AI가 개발을 구동)이라는 두 가지 패러다임으로 명확히 구분하고 있습니다.

경계를 나누는 것은 태스크에 AI를 몇 개 사용하는가가 아니라, 다음의 3가지 점입니다.

관점	AI-Assisted (각 태스크를 AI가 보조)	AI-Driven (AI-DLC가 지향하는 모습)
대화의 주도권	인간이 AI에게 요청한다. 인간이 주어	AI가 질문·제안하고, 인간은 승인자이다. 원칙 2 「Reverse the conversation direction」
...

공식 페이퍼에는 다음과 같이 적혀 있습니다.

AI recommends the Level 1 Plan based on the given pathway intention. Humans verify and moderate these AI-generated plans through interactive dialogue with AI

예를 들어 「시험 계획 작성 → AI 리뷰」, 「AI를 활용한 테스트 데이터 작성 (test data creation with AI)」, 「TDD (테스트 생성은 AI)」, 「lint/security」, 「PR 작성」, 「MR 리뷰 (AI 체크)」라는 일련의 흐름을 구성하더라도, 순서를 인간이 고정하고 AI에게 각 작업을 할당하고 있는 한은 AI-Assisted의 완성형에 머무릅니다. 동일한 태스크 군이라도 AI-Driven에 가깝게 만들려면, ① 기점을 Intent로 하여 AI에게 Level 1 Plan을 제안하게 한다 ② 각 단계에서 인간은 작성자가 아닌 승인자로 돌아간다 ③ 결과물 (사양 · 계획 · 데이터 · 결과 · 원인 분석)을 링크하여 AI가 항상 전 공정의 컨텍스트 (Context)를 참조하게 한다, 라는 재구성이 필요합니다. 차이점은 「태스크의 내용」이 아니라 「누가 단계를 쥐고 있으며, AI가 계획 계층에 포함되어 있는가」에 있습니다.

이 관점은 결합 시험과 같은 단일 페이즈에 AI-DLC를 도입하고 싶은 경우에도 유효합니다. AI-DLC를 페이즈 구조 전체로 가져오는 것이 아니라, 「AI가 계획을 제안하고 인간이 검증하는 왕복 루프」와 「컨텍스트 메모리 (Context Memory)」라는 핵심 메커니즘만을 이식하는 것이 현실적이라고 생각합니다.