AI-DLC: AI 시대에 SDLC를 다시 생각하다

지난 시리즈에서 다룬 하네스 엔지니어링에 이어 개발 절차에 대해 AWS가 내놓은 접근이 AI 주도 개발 생애주기(AI-Driven Development Life Cycle, AI-DLC)입니다.

AWS는 AI-DLC를 기존 소프트웨어 개발 생애주기(Software Development Life Cycle, SDLC)에 AI 코딩 기능을 추가하는 수준이 아니라, AI를 개발의 중심 협업자로 놓고 라이프사이클을 재구성하는 방법론으로 소개했습니다.¹⁾

^{[그림 1] AI-assisted는 기존 절차를 유지하고 일부 작업을 가속하는 방식, AI-DLC는 사람의 의도와 결정을 축으로 절차를 다시 구성하는 방식}

AWS는 AI-DLC의 주요 원칙 중 하나를 AI Powered Execution with Human Oversight로 설명합니다.¹⁾ AI가 상세한 계획을 만들고 필요한 것을 되물으며 작업을 실행하지만, 중요한 결정에는 사람이 참여합니다. 핵심은 AI가 사람을 대체하는 것이 아니라 사람의 역할이 반복적인 생산 작업에서 의도, 비즈니스 컨텍스트, 아키텍처 결정, 검증, 승인 쪽으로 옮겨갑니다.

AI-DLC를 처음 보면 단계가 많은 무거운 프로세스라고 생각하기 쉽습니다. 하지만 AWS가 AI-DLC Adaptive Workflow를 오픈소스로 공개하면서 지적한 문제 중 하나가 모든 상황에 같은 워크플로를 적용하는 방식이었습니다.²⁾ 작은 버그 수정과 대규모 기업 시스템 개발이 동일한 절차와 동일한 수준의 산출물을 요구하면 비효율적입니다. 그래서 중요한 것이 적용 깊이의 조절입니다. 필요한 곳에서는 엔지니어링 원칙을 엄격하게 적용하고, 그렇지 않은 곳에서는 절차의 깊이를 줄입니다. 이 원칙은 AI-DLC v2에서 Scope와 Depth라는 명시적인 구조로 발전합니다. 현재 AWS AI-DLC는 두 가지 구현체를 제공하고 있습니다. 얼마전 Github 공개 저장소의 Main 브랜치로 승격 된 v2와 이전 버전인 v1 브랜치로 이하 기술되는 구현체 구분을 V1과 V2로 나누어 설명하겠습니다.

AI-DLC V1과 V2: 서로 다른 엔지니어링 선택

V1과 V2는 단순한 신구 관계가 아니라 서로 다른 비용 구조를 가진 선택으로 보는 편이 유용합니다.

^{[그림 2] V1은 워크플로와 규칙을 LLM이 해석해 진행하고, V2는 엔진이 상태와 경로를 결정하고 승인 게이트와 감사 기록을 남긴다}

V1은 규칙과 Steering으로 만든 워크플로 뼈대에 가깝습니다. AWS도 2025년 Adaptive Workflow를 공개하면서 이를 AI 코딩 에이전트의 Rules/Steering을 통해 구현한다고 설명했습니다.²⁾ 가장 큰 장점은 가볍고 유연하다는 것입니다. 프로젝트에 규칙을 넣어 빠르게 사용할 수 있고, 마크다운(Markdown) 중심의 규칙을 바꾸면서 조직이나 프로젝트 특성에 맞는 워크플로를 빠르게 만들어 갈 수 있습니다. 반대로 다음에 어떤 단계로 갈지를 정하는 판단도 LLM의 컨텍스트와 규칙 해석에 더 많이 좌우됩니다. 유연성을 크게 가져가고 결정성은 상대적으로 덜 가져가는 접근입니다.

V2는 현재 정식 출시(General Availability, GA) 상태이며 아키텍처가 크게 달라졌습니다.³⁾

구성은 다음과 같습니다.

• 5개 Phase, 33개 Stage: Initialization, Ideation, Inception, Construction, Operation
• 14개 Agent: 도메인 전문가 11개, 품질 게이트 리뷰어 2개, 워크플로를 구성하는 Adaptive Workflows Composer 1개
• 11개 Adaptive Scope: enterprise부터 express까지의 범위를 제공하며 V1 방식에 해당하는 classic이 기본값입니다. /aidlc compose 명령으로 작업 성격에 맞는 Stage 계획을 조합할 수도 있습니다.
• 모든 Stage의 승인 게이트와 87개 이벤트 기반 감사 기록
• 세션 재개: 체크포인트에서 이어가기, 재실행, 특정 Stage로 이동, 새로 시작을 선택할 수 있습니다.
• 하나의 Harness-neutral Core

같은 Core가 7개 개발 환경에서 동작합니다. Kiro IDE, Kiro CLI, Claude Code, Codex CLI, Cursor, opencode, GitHub Copilot입니다.²⁾ 조직이 사용하는 코딩 에이전트가 여러 개로 나뉘어 있어도 동일한 개발 절차를 적용할 수 있다는 뜻입니다.

가장 중요한 아키텍처 변화는 결정론적으로 처리해야 할 영역을 LLM의 자연어 판단에서 분리했다는 것입니다. 정리하면 다음과 같습니다.

📌 LLM이 잘하는 일은 LLM에게, 코드가 더 잘하는 일은 코드에게 맡긴다.

^{[그림3] LLM은 추론과 설계와 생성, Engine은 경로 결정과 상태와 검증, Human은 결정과 승인을 담당한다}

AI-DLC v2가 주목할 만한 이유는 이것이 AI-DLC뿐 아니라 에이전트 하네스를 설계할 때 참고할 만한 일반적인 아키텍처 패턴이기 때문입니다. LLM에게 모든 것을 맡기는 대신, 정확해야 하는 상태 전이나 검증은 결정론적인 코드로 옮기는 것입니다.

다만 V2가 더 많은 것을 제공하는 만큼 관리해야 할 대상도 따라옵니다.

실제로 AIDLC Github 저장소에서는 인터페이스와 Stage 정의, Agent 구성, 설치 방식이 안정 단계에 들어섰다고 밝히면서도, 피드백에 따른 최적화가 계속되므로 의존하는 대상은 검증된 버전으로 고정(Pinning)하라고 권고합니다.²⁾ 따라서 이 차이는 V2의 단점이라기보다 더 강한 거버넌스와 추적성, 복구 가능성을 얻는 대신 더 많은 오케스트레이션 복잡도를 관리해야 하는 트레이드오프로 보는 편이 적절합니다.

두 개의 통제 축이 분리되면 무엇이 다른가

Kiro Enterprise가 다루는 것은 사용할 수 있는 모델의 범위, 연결할 수 있는 MCP의 범위, 외부 웹 접근의 허용 여부, AI 사용 활동의 추적입니다. AI-DLC가 다루는 것은 수행해야 하는 단계, 필요한 산출물, 리뷰가 끝난 항목, 승인의 주체, 다음 단계로 이동한 근거입니다.

^{[그림4] Kiro는 모델과 MCP, 웹, 권한, 로깅으로 런타임을 통제하고 AI-DLC는 단계와 상태, 리뷰, 승인, 감사로 라이프사이클을 통제한다}

한 문장으로 표현하면 Kiro가 에이전트 런타임의 거버넌스를 제공한다면, AI-DLC는 개발 라이프사이클의 거버넌스를 제공합니다. Kiro가 AI 개발자에게 모델과 컨텍스트, 도구, 자동화를 제공한다면 AI-DLC는 그 AI 개발자와 사람이 어떤 개발 절차와 통제 구조로 소프트웨어를 만들어야 하는지를 정의합니다.

실제 프로젝트에서 확인된 세 가지 패턴

방법론이 실제 프로젝트에 들어가면 공개된 기본 워크플로를 그대로 사용하는 것으로 끝나지 않습니다. LG CNS는 AI-DLC를 기반으로 여러 SI/SM 프로젝트에 적용 경험을 축적해 왔습니다. 고객 및 프로젝트 식별정보를 제외하고, 적용 과정에서 반복적으로 확인된 패턴을 세 가지 유형으로 정리합니다.

[유형 A] 대규모 Brownfield SM

운영 중인 기존 시스템은 신규 구축(Greenfield)과 업무 특성이 다릅니다. 아키텍처와 코드베이스가 이미 존재하고, 대부분의 개발은 티켓 또는 변경 요청 단위로 이루어집니다. 이 환경에서는 범용 워크플로를 그대로 쓰는 것보다 다음과 같이 조정하는 편이 효과적이었습니다.

• Brownfield 중심으로 진행 흐름 재구성
• 역공학(Reverse Engineering) 산출물 재사용
• 일부 설계 단계 경량화
• 테스트 케이스 생성 단계 추가
• 코드 품질 리뷰 단계 추가
• 구현 결정 게이트 추가
• 최종 요약 단계 추가

특히 중요한 원칙은 기본 AI-DLC와 프로젝트 커스터마이징을 분리하는 것이었습니다.

^{[그림 5] AWS AI-DLC 위에 Override와 Extension을 두고 그 결과로 프로젝트 전용 Harness를 만드는 3계층 구성}

그래야 AI-DLC가 업데이트되더라도 프로젝트 전용 규칙과 기본 프레임워크 사이의 경계를 관리할 수 있습니다. 여기서 얻은 첫 번째 교훈은 방법론을 그대로 적용하는 것이 아니라, 프로젝트가 일하는 방식을 하네스에 녹이는 과정이 중요하다는 것입니다.

[유형 B] 기존 플랫폼을 확장하는 Brownfield 개발

다른 유형의 프로젝트에서는 기존 애플리케이션과 아키텍처를 재사용하면서 새로운 기능을 반복적으로 확장했습니다. 처음에는 AI-DLC의 가장 큰 기대 효과를 코드 생성이라고 생각하기 쉽습니다. 하지만 여러 개발 주기가 쌓이면서 더 중요하게 확인된 것은 역공학, 요구사항, 아키텍처 결정, 작업 단위 분해, 구현 계획, 결정과 감사 기록 같은 산출물이었습니다.

한번 잘 만들어진 역공학 결과와 프로젝트 컨텍스트가 다음 개발 주기의 입력이 되고, 새로운 개발자가 참여했을 때는 온보딩 컨텍스트가 됩니다. AI-DLC의 가치는 코드 생성 속도만이 아니라, 프로젝트 지식(Knowledge)을 AI와 사람이 다시 사용할 수 있는 형태로 축적하는 데도 있습니다. 이 점은 Brownfield나 장기간 운영되는 시스템일수록 더 중요합니다. AI의 세션은 바뀔 수 있지만 프로젝트 지식은 지속되어야 하기 때문입니다.

[유형 C] 기업용 AI 개발 Harness

보다 복잡한 환경에서는 AI-DLC 위에 조직이나 프로젝트에서 필요한 규칙과 도구를 추가하는 형태로 확장할 수 있습니다. 도메인별 경로 분기, 조직과 프로젝트 규칙, 리뷰 게이트, 테스트 케이스, 코드 품질 리뷰, 최종 요약, 결정론적 검증 도구, 다중 작업 단위 실행 등이 그 예입니다.

LG CNS는 SI/SM 적용 경험과 축적된 프로젝트 지식을 기반으로 현재 AI-DLC 아키텍처를 활용한 기업용 하네스로 발전시키고 있습니다. 여기서 중요한 것은 기존 하네스 자산을 폐기하고 AI-DLC로 다시 시작하는 것이 아닙니다.

기존 프로젝트를 통해 축적한 지식과 규칙은 유지하면서, 상태·감사·경로 결정·검증과 같은 실행 제어 영역을 더 결정론적인 아키텍처로 발전시키는 접근입니다. 이 과정에서 AI-DLC의 아키텍처는 방법론 자체뿐 아니라 기업용 에이전트 하네스를 설계할 때도 참고할 만한 패턴을 제공합니다.

프로젝트 Harness에서 Enterprise Harness로

실제 기업 환경에서는 AI-DLC를 워크플로 파일 몇 개로만 보기는 어렵습니다. 프로젝트 적용이 반복될수록 그 위에 조직의 자산이 쌓이기 때문입니다.

^{[그림6] AWS AI-DLC에서 프로젝트 커스터마이징과 SI/SM 적용, 경험 정리를 거쳐 조직 표준과 결합된 기업용 Harness로 발전하는 순서}

LG CNS 역시 여러 SI/SM 프로젝트에서 AI-DLC 적용 경험을 축적하고 있으며, 현재 그 경험과 조직의 개발 표준, 보안, 지식을 결합하여 기업용 하네스로 발전시키고 있습니다. 장기적으로 중요한 과제는 특정 코딩 에이전트 하나를 조직 전체에 배포하는 일에 그치지 않습니다.

📌 어떤 코딩 에이전트를 사용하더라도 개발 절차와 품질, 지식을 일관되게 적용할 수 있는 엔지니어링 시스템을 만드는 것.

이것이 Enterprise Harness가 풀어야 할 더 큰 문제입니다.

AI Coding에서 AI Engineering System으로

AI 코딩은 빠르게 발전하고 있습니다. 하지만 앞으로의 경쟁은 코드 벤치마크 점수만으로 결정되지 않을 것입니다.

^{[그림7] 코드 자동완성에서 AI어시스턴트, 코딩에이전트, 하네스 엔지니어링, 엔터프라이즈 하네스, AI-DLC를 거쳐 AI 앤지니어링 시스템으로 이어지는 흐름}

이제 중요한 것은 다음과 같은 판단입니다.

• AI에게 제공할 컨텍스트와 도구
• 기업 정책 안에서 에이전트의 모델과 도구 접근을 통제하는 방법
• AI의 비결정적인 부분과 코드로 보장할 결정론적인 부분을 나누는 기준
• 사람과 AI가 함께 소프트웨어를 만들어갈 라이프사이클

Kiro는 AI 에이전트가 일하는 하네스를 개인의 개발환경에서 기업 영역까지 확장하고 있습니다. AI-DLC는 그 위에서 AI와 사람이 소프트웨어를 만드는 라이프사이클을 구조화하고 있으며, 이를 더 결정론적이고 검증 가능한 워크플로 엔진으로 발전시키고 있습니다. 그리고 기업에서는 이 둘을 조직의 방법론, 보안, 품질 기준, 지식과 연결하는 Harness Engineering이 중요한 과제가 될 것입니다.

AI 코딩의 다음 단계는 더 좋은 코딩 도구가 아닐지도 모릅니다. AI와 사람이 함께 소프트웨어를 만드는 엔지니어링 시스템을 설계하는 것, Kiro와 AI-DLC는 그 변화의 두 가지 축입니다.

요약

• AI-DLC Workflows 2.0은 현재 GA로, 5개Phase(Initialization·Ideation·Inception·Construction·Operation)와 33개 Stage, 14개 Agent(도메인 전문가 11, 품질 게이트 리뷰어 2, Composer 1), 11개 Adaptive Scope, 모든 Stage의 승인 게이트, 87개 이벤트 감사 기록, 세션 재개, Harness-neutral Core로 구성됩니다. 같은 Core가 Kiro IDE·Kiro CLI·Claude Code·Codex CLI·Cursor·opencode·GitHub Copilot 등 7개 개발 환경에서 동작합니다. 핵심 아키텍처 변화는 경로 결정과 상태 관리를 LLM의 자연어 판단에서 분리해 결정론적 코드로 옮긴 것입니다.
  
  
• AI-DLC V1과 V2는 신구 관계가 아니라 비용 구조가 다른 선택입니다. V1은 규칙·Steering 기반으로 가볍고 유연해 첫 도입, PoC, 소규모 팀, 빈번한 커스터마이징에 적합합니다. V2는 감사·컴플라이언스, 세션 복구, 멀티 에이전트 오케스트레이션, 기업 표준 하네스가 필요할 때 적합하지만 오케스트레이션 복잡도를 함께 관리해야 합니다.
  
  
• LG CNS는 복수의 SI/SM 프로젝트에 AI-DLC를 적용하면서 세 가지 패턴을 확인했습니다. 대규모 Brownfield SM에서는 기본 방법론과 프로젝트 커스터마이징을 분리하는 3계층 구성이 필요했고, 플랫폼 확장형 개발에서는 코드 생성 속도보다 역공학·요구사항·결정 기록 같은 재사용 가능한 프로젝트 지식의 축적이 더 큰 가치를 만들었습니다. 현재는 기존 하네스 자산을 폐기하지 않고 지식과 규칙은 유지하면서 상태·감사·경로 결정 영역만 AI-DLC 아키텍처로 이전하는 방식으로 기업용 하네스를 발전시키고 있습니다.

FAQ

Q1. AI-DLC는 기존 SDLC를 대체하는 건가요?

기존 SDLC에 AI 기능을 덧붙이는 것이 아니라, AI를 개발의 중심 협업자로 놓고 라이프사이클을 재구성하는 방법론입니다. 다만 AI가 사람을 대체하는 구조는 아닙니다. AI가 계획을 만들고 작업을 실행하되 중요한 결정에는 사람이 참여하며, 사람의 역할은 반복적인 생산 작업에서 의도 정의, 비즈니스 컨텍스트 제공, 아키텍처 결정, 검증, 승인으로 이동합니다. 또한 작은 버그 수정과 대규모 시스템 개발에 같은 깊이의 절차를 적용하지 않도록 적용 범위와 깊이를 조절하는 것이 전제입니다.

Q2. AI-DLC V1과 V2 중 무엇을 선택해야 하나요?

둘 중 하나가 항상 정답은 아닙니다. AI-DLC를 처음 도입하거나, 빠른 PoC가 목적이거나, 소규모 팀에서 워크플로를 자주 바꿔야 한다면 규칙 기반으로 가벼운 V1이 적합할 수 있습니다. 반대로 감사와 컴플라이언스가 중요하거나, 세션 복구가 필요하거나, 여러 팀이 공통 워크플로를 써야 하거나, 멀티 에이전트 오케스트레이션이 필요하다면 V2(Main 브랜치)를 검토할 만합니다. V2는 더 강한 추적성과 복구 가능성을 제공하는 대신 관리해야 할 오케스트레이션 복잡도가 늘어난다는 트레이드오프가 있습니다.

Q3. 기존에 만든 하네스 기반 자산이 있는데 AI-DLC로 가면 버려야 하나요?

그렇지 않습니다. 기존에 축적한 프로젝트 지식, 도메인 규칙, 보안 기준, 품질 기준, 개발 표준은 그대로 유지하면서 상태 관리, 감사 기록, 경로 결정, 리뷰어, 멀티 에이전트 실행처럼 결정론적 처리가 유리한 실행 제어 영역만 AI-DLC 런타임으로 옮기는 접근이 가능합니다.

참고자료

1) AWS, <AI-Driven Development Life Cycle: Reimagining Software Engineering>

2) AWS, <Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle>

3) AWS Labs, <aidlc-workflows: AI-DLC Workflows 2.0>

아래 목록을 클릭해 연관 콘텐츠를 확인하실 수 있습니다.

연관 콘텐츠 목록

• 1편 - 모델을 넘어 실행 환경으로: 기업 관점의 하데스 엔지니어링
• 2편 - AI와 사람이 함께 만드는 개발 프로세스, AI-DLC

본 콘텐츠는 저작권법에 의해 보호받는 저작물로 LG CNS에 저작권이 있습니다.

사전 동의 없이 2차 가공 및 영리적인 이용을 금합니다.

관련 문의 사항은 LG CNS 공식 홈페이지로 문의주시기 바랍니다.

LG CNS 홈페이지 문의하기