AI-DLC는 'AI-driven Development Lifecycle'의 약자로,소프트웨어 개발 라이프사이클(SDLC)을 보강합니다. AI-DLC는 AI를 중심으로 완전히 구축된 소프트웨어 개발 방법론을 의미하며, 대규모 언어 모델(LLM) 또는 모델 그룹을 소프트웨어 개발의 모든 단계에서 적극적인 협력자로 취급합니다.
2025년 AWS의 Raja SP가 처음 사용한 용어이며, 그의 백서 'AI-Driven Development Lifecycle(AI-DLC) Method Definition'[x]에서 AI-DLC 방법론은 근본적으로 인간 중심적인 기존 방법(예: 애자일, 스크럼)과는 달리 기계와 인간의 협업으로 소개됩니다. 저자는 이러한 변화를 마차가 자동차로 대체된 것에 비유합니다. 하지만 단순히 애자일에 AI를 더하는 것만으로는 (흔히 Henry Ford가 말한 것으로 잘못 인용되는 비유를 빌리자면) '더 빠른 말'을 만들어낼 수 없습니다. AI-DLC는 더욱 근본적인 진화를 의미합니다.
최근 몇 년 동안 AI 도구들이 SDLC에 통합되어 왔지만, AI-DLC는 AI 통합을 한 단계 더 발전시킨 것을 의미합니다. 요컨대, AI는 단순한 코드 생성 도구에 그치지 않습니다. AI는 단순히 개발의 일부가 아니라 그 중심에 있습니다. AI와 인간 간의 협업은 지속적으로 이루어지며 인간 엔지니어는 감독하는 역할에 더 집중합니다.
또한 이는 AI 모델 자체가 어떻게 구축되는지를 설명하는 'AI 라이프사이클'이라는 용어와도 구별됩니다. AI 라이프사이클은 AI 모델이 소프트웨어 개발을 지원하는 데 어떻게 사용되는지를 설명하는 용어가 아닙니다.
Raja SP의 백서는 AI-DLC의 기반을 나타내는 10가지 원칙을 정의합니다.
AI는 단순히 기존 소프트웨어 개발 방법론에 추가하는 방식이어서는 안 됩니다. AI는 단순한 생산성 도구가 아니라 핵심 참여자입니다. AI가 항상 존재했다면 SDLC는 어떤 모습일지 질문하며, 그 결과가 AI 중심의 AI 네이티브 SDLC입니다.
전통적인 AI 지원 개발은 개발자가 생성형 AI에게 개별 작업을 수행하도록 지속적으로 지시하는 형태로 나타납니다. 새로운 패러다임에서는 개발자가 AI에게 도움을 요청하고 AI가 작업을 수행할 때까지 기다리는 대신, 개발자가 자신의 의도를 설명하면 AI가 에이전트 기능을 사용하여 계획을 수립하고, 질문하고, 실행하고, 검증하고, 유지보수하는 모든 과정을 수행하며, 동시에 인간 파트너로부터 승인을 적극적으로 구합니다.
이전의 방법론에서는 개발 팀이 자체 설계 기술을 선택할 수 있었습니다. AI-DLC는 설계를 중앙 집중화하고 엔지니어링 분야를 방법론 자체에 도입합니다. 도메인 주도 설계(DDD), 행동 주도 개발(BDD), 테스트 주도 개발(TDD)과 같은 방식은 워크플로에 필수적인 요소가 됩니다. 이를 통해 엔지니어링 품질을 표준화할 수 있습니다.
AI는 100% 자율적일 수 없습니다. 이 백서는 AI가 인간의 판단으로부터 이점을 얻을 수 있도록 AI 결정에 대한 휴먼인더루프(human-in-the-loop) 검증 및 감독을 권장합니다.
기업용 소프트웨어에는 단순한 코드 작성 이상의 복잡성이 있습니다. 대규모 시스템은 여러 서비스, 아키텍처, 다양한 종류의 사용자 및 이해관계자로 구성되어 있으며, 필연적으로 수년간의 까다로운 기술 부채로 구성됩니다. AI-DLC의 핵심 가치 중 하나는 프로젝트 전체에 걸쳐 이러한 모든 맥락을 보존하여, 개발자들이 이러한 고유하고 전체적인 이해를 지속적으로 활용할 수 있도록 한다는 점입니다.
AI-DLC는 소프트웨어 개발을 혁신하지만, 필요한 경우 인간이 참여하는 역할은 그대로 유지합니다. 프로젝트 전반에 걸쳐 지속적인 피드백 문화를 유지하여 개발이 비즈니스 목표에 부합하도록 합니다. 이러한 접점들은 자동화되고 문서화되므로 사람들은 최선의 결정을 내리는 데 집중할 수 있습니다.
저자는 조직이 하룻밤 사이에 새로운 방법론으로 전환할 수 없다는 점을 인식했습니다. 이 프로세스는 점진적이며 조직에 이미 익숙한 기존 개념 및 워크플로와 통합되므로 도입에 따른 혼란이 최소화됩니다.
AI는 여러 분야에 걸쳐 작업을 수행하고 컨텍스트를 유지할 수 있기 때문에 이전에는 별도의 전문가 팀이 필요했던 작업을 이제 더 높은 수준의 이해를 갖춘 보다 통합된 팀에서 완료할 수 있습니다. 그 결과, 업무 인계 빈도가 줄어듭니다.
기존 SDLC는 작업을 계획, 설계, 구현, 테스트 및 배포와 같은 개별 단계로 나눕니다. 각 단계가 끝나면 정보가 한 단계에서 다음 단계로 전달됩니다. AI-DLC는 이러한 단계를 작업이 동시에 비선형적으로 발생하는 연속적인 흐름으로 취급하여 이러한 경계를 모호하게 만듭니다. 그 결과, 피드백 루프가 짧아지고 진행 속도가 빨라집니다.
AI-DLC는 모든 프로젝트에 대해 엄격한 워크플로를 규정하지 않고, 적응형으로 동작합니다. 미리 정해진 절차를 통해 프로젝트를 강제로 진행시키지 않습니다. 모든 시나리오에서 AI는 목표와 제약 조건을 분석하고 특정 프로젝트에 가장 적합한 맞춤형 워크플로를 생성합니다.
Think 뉴스레터를 통해 AI, 자동화, 데이터 등 가장 중요하고 흥미로운 업계 동향에 대한 최신 소식을 받아보세요. IBM 개인정보 보호정책을 참조하세요.
이 프레임워크는 다음과 같은 질문을 던집니다. 소프트웨어 개발이 인간의 한계를 중심으로 구축되지 않았다면 어땠을까? 워터폴이나 애자일 같은 기존의 방법론은 사람으로 구성된 팀의 업무 조율을 돕기 위해 고안되었습니다. AI는 이러한 핵심 가정을 근본적으로 바꿉니다.
사양 중심 개발(SDD) 방법론을 사용하는 AI-DLC는 엄격한 프로세스보다는 의도를 강조하고, AI가 사양을 가장 잘 충족하는 무언가를 구축하는 방법을 스스로 파악하도록 합니다. 이러한 의도에서 파생된 유닛(unit)은 의도를 달성하기 위한 AI의 경로를 나타내는 작업 집합입니다. 볼트(bolt)는 작업 단위가 실행되는 반복 과정을 의미합니다.
작업은 여러 단계로 진행됩니다. 시작 단계에서는 의도를 파악하고, 이를 몹 정교화(mob elaboration)를 통해 단위로 변환합니다. 몹 정교화는 여러 직무로 구성된 팀과 AI 시스템이 협력하여 고수준의 비즈니스 아이디어를 사용자 스토리로 전환하는 협업형 소프트웨어 기획 방식입니다.
요구 사항 분석은 여기에서 시작됩니다. 비기능 요구 사항(NFR)은 중요한 속성, 가드레일 및 제약 조건을 정의합니다. 위험 평가도 이 단계에서 수행되지만, 위험과 요구 사항은 라이프사이클 전반에 걸쳐 지속적으로 점검되고 재평가됩니다.
스티어링 파일(steering file)은 에이전트가 따라야 하는 규칙, 제약 조건, 아키텍처 표준 및 워크플로를 정의하는 저장소에 저장된 마크다운 문서입니다. 스티어링 파일은 시작 단계에서 만들어지지만, AI-DLC의 세 단계 모두에 관여합니다. 또한 프로젝트 전반에서 AI 에이전트를 위한 지속적인 정보 소스 역할을 합니다.
구축 단계는 실행이 이루어지는 단계입니다. 몹 구축 중에는 인간 팀과 AI가 공동으로 코드를 작성하고, 테스트하고, 배포합니다.
최종 운영 단계에서 AI는 시작 단계의 비즈니스 요구 사항과 구축 단계의 기술적 결정을 사용하여 배포를 관리하고 인프라를 자동화하며 라이브 시스템을 모니터링합니다.
SDLC의 각 단계에서 AI는 중심적인 역할을 합니다.
기존 SDLC에서는 사람이 비즈니스 목표를 프로젝트 계획으로 수동으로 변환합니다. 여라 조직에서 AI 어시스턴트가 간략한 목표를 구체적인 계획으로 전환하는 데 도움을 주는 워크플로를 실험해 왔습니다. AI-DLC에서 AI 에이전트는 명확한 질문을 하고, 모호성을 식별하고, 제안을 하고, 놓칠 수 있는 기회를 찾아냅니다. 이 문서들은 스토리와 프로젝트 로드맵으로 변환됩니다. 에이전틱 AI는 프로젝트 전반에 걸쳐 이러한 컨텍스트를 유지합니다.
AI-DLC에서 AI는 단순히 회의를 요약하는 데 그치지 않고, 이메일, 지원 티켓, 대화 내용 및 문서를 분석하여 개발이 시작되기 전에 충돌과 격차를 식별합니다. 누군가가 한 회의에서 다른 회의에서 명시된 프로젝트 타임라인과 충돌하는 핵심 이벤트를 제기하는 경우, 에이전트는 이러한 잠재적 불일치에 플래그를 지정하고 해결책을 제공할 수 있습니다. 이를 통해 개인이나 팀이 유지하기 어려운 프로젝트를 처음부터 끝까지 포괄적으로 이해할 수 있습니다.
소프트웨어 엔지니어링의 핵심 작업인 코드 작성은 SDLC에서 AI가 유용하게 활용될 수 있는 가장 직관적인 영역이며, AI가 가장 자율적인 역할을 수행하는 영역이기도 합니다. AI 코딩 에이전트는 프로젝트 컨텍스트, 코딩 표준, 비즈니스 로직을 이해하고 이를 염두에 두고 자율적으로 코드를 작성할 수 있습니다. 개발자는 의사 결정을 검증하고 AI가 생성한 코드를 개선합니다.
AI는 완료될 때까지 기다리지 않고 개발 전반에 걸쳐 지속적으로 테스트를 생성하고 실행하기 때문에 테스트는 더 광범위한 검증 단계로 대체됩니다. 또한 코드의 결함을 분석하고, 회귀를 감지하고, 아키텍처 제약 조건을 준수하는지 검증합니다. 이 작업은 모든 단계에서 백그라운드에서 이루어집니다.
AI-DLC 내에서 배포는 지속적으로 최적화되는 또 다른 프로세스입니다. 에이전트는 릴리스 계획을 준비하고, 인프라 구성을 검증하고, 문서를 생성하고, 프로덕션 롤아웃을 모니터링하고, CI/CD 파이프라인을 최적화합니다. AI는 릴리스가 안정적이고 안전하게 유지될 뿐만 아니라 운영 목표에 부합하도록 적극적으로 지원합니다.
AI-DLC는 프로덕션 시스템을 지속적인 피드백 소스로 취급하여 기존 소프트웨어 유지보수를 뛰어넘습니다. AI는 전체 라이프사이클에 걸쳐 지식을 보존함으로써 각 릴리스가 이전 개발 주기에서 배운 교훈을 활용할 수 있도록 합니다.
이 백서는 조직이 다양한 의식을 실천하고 자체 오케스트레이션 도구에 AI-DLC를 내장하도록 권장하며, 이는 상당한 점검의 필요성을 최소화하는 것을 목표로 합니다.
이 프레임워크는 Kiro 및 Amazon Q Developer와 같은 AWS 도구를 중심으로 표준화되어 있습니다. 하지만 IBM Bob 및 Claude Code와 같은 에이전트 플랫폼과도 함께 사용할 수 있습니다.
예를 들어, IBM Bob은 AI-DLC에 맞게 구조적으로 최적화된 엔드투엔드 에이전트 개발 파트너입니다. IBM Bob은 높은 수준의 의도를 파악하고 초기 애플리케이션 설계 구조를 차례대로 구축하는 Ask 및 Plan 모드를 제공합니다. 코드를 작성, 수정 및 리팩토링하거나 버그를 수정하거나 새 파일을 생성할 수 있는 에이전트 모드가 있습니다. 또한 사용자는 특수 역할, 도구 제한 및 팀 워크플로를 사용하여 사용자 지정 모드를 구축하여 Bob의 행동을 조정할 수 있습니다.