I. 배경

소프트웨어 엔지니어링의 진화는 개발자가 저수준의 차별화되지 않는 작업을 추상화하여 복잡한 문제 해결에 집중할 수 있도록 하는 끊임없는 여정이었다. 초기 기계어에서 고수준 프로그래밍 언어, API와 라이브러리의 도입에 이르기까지, 각 단계는 개발자 생산성을 크게 향상시켰다. 이제 대규모 언어 모델(LLM)의 통합은 소프트웨어 생성 방식을 혁신하고 있으며, 코드 생성, 버그 탐지, 테스트 생성 등의 작업에 대화형 자연어 상호작용을 도입했다. 이것이 바로 AI가 세분화된 특정 작업을 향상시키는 AI-Assisted(AI 보조) 시대이다.

AI가 진화함에 따라, 그 적용 범위는 코드 생성을 넘어 요구사항 정교화, 계획 수립, 작업 분해, 설계, 그리고 개발자와의 실시간 협업으로 확장되고 있다. 이러한 전환은 AI가 개발 프로세스를 능동적으로 조율하는 AI-Driven(AI 주도) 시대를 열고 있다. 그러나 기존의 소프트웨어 개발 방법론은 인간 주도의 장기 프로세스를 위해 설계되었기에, AI의 속도, 유연성, 고급 역량(예:에이전틱)과 완전히 부합하지 않는다. 수동 워크플로우와 경직된 역할 정의에 대한 의존은 AI를 완전히 활용하는 능력을 제한한다. AI를 기존 방법론에 끼워 맞추는 것은 AI의 잠재력을 제한할 뿐만 아니라, 구시대적 비효율을 강화한다. AI의 변혁적 힘을 완전히 활용하려면, SDLC 방법론을 재구상해야 한다. 이 재구상은 AI를 중심 협력자로 두고, 워크플로우, 역할, 반복 주기를 정렬하여 더 빠른 의사결정, 원활한 작업 실행, 지속적 적응성을 가능하게 해야 한다.

이 논문은 AI의 역량을 완전히 통합하도록 설계된, 재구상된 AI 네이티브 방법론인 **AI-Driven Development Lifecycle (AI-DLC)**를 소개하고 정의하며, 소프트웨어 엔지니어링의 다음 진화를 위한 기반을 마련한다.

II. 핵심 원칙

이 섹션의 원칙들은 AI-DLC를 정의하는 기반을 형성하며, 그 단계, 역할, 산출물, 의식(ritual)을 형성한다. 이 가정들은 제안된 방법론을 검증하는 데 핵심적이며, 설계 뒤의 근본적 논리를 제공한다.

1. REIMAGINE RATHER THAN RETROFIT (끼워 맞추기가 아닌 재구상)
우리는 SDLC나 Agile(예: Scrum) 같은 기존 방법론을 유지하면서 AI를 끼워 맞추는 대신, 개발 방법론을 재구상하기로 선택한다. 이러한 전통적 방법론은 더 긴 반복 주기(수개월, 수주)를 위해 만들어졌고, 이로 인해 데일리 스탠드업이나 회고 같은 의식이 생겨났다. 반면, AI의 적절한 적용은 시간 또는 일 단위로 측정되는 빠른 주기를 만들어낸다. 이는 지속적이고 실시간적인 검증 및 피드백 메커니즘을 필요로 하며, 많은 전통적 의식을 덜 관련성 있게 만든다. AI가 단순, 중간, 어려운 작업 간의 경계를 줄인다면 노력 추정(예: 스토리 포인트)이 여전히 중요할까? 벨로시티 같은 지표가 여전히 관련이 있을까, 아니면 예를 들어 비즈니스 가치로 대체해야 할까? 또한, AI는 계획 수립, 작업 분해, 요구사항 분석, 설계 기법 적용(예: 도메인 모델링) 등 수동 관행을 자동화하는 방향으로 점점 진화하고 있어, 의도에서 코드로 이동하는 데 필요한 단계 수를 줄이고 있다. 이러한 새로운 역학은 끼워 맞추기가 아닌 제1원칙 사고에 기반한 재구상을 필요로 한다. 우리에게 필요한 것은 자동차이지, 더 빠른 마차가 아니다.

2. REVERSE THE CONVERSATION DIRECTION (대화 방향의 역전)
AI-DLC는 인간이 AI에게 작업 완료를 위해 대화를 시작하는 대신, AI가 인간과의 대화를 시작하고 주도하는 근본적 전환을 도입한다. AI는 고수준 의도(예: 새로운 비즈니스 기능 구현)를 실행 가능한 작업으로 분해하고, 추천을 생성하며, 트레이드오프를 제안함으로써 워크플로우를 주도한다. 인간은 승인자로서, 중요한 분기점에서 검증하고, 옵션을 선택하며, 결정을 확인한다. 이 AI 주도 접근법은 개발자가 고가치 의사결정에 집중할 수 있게 하면서 AI가 계획, 작업 분해, 자동화를 처리한다. 전통적 역학을 역전시킴으로써, AI-DLC는 인간의 참여가 목적 있게 이루어지도록 보장하며, 감독, 리스크 완화, 전략적 정렬에 집중하여 속도와 품질 모두를 향상시킨다. 이를 설명하는 비유는 구글 맵이다: 인간이 목적지(의도)를 설정하면, 시스템이 단계별 안내(AI의 작업 분해와 추천)를 제공한다. 그 과정에서 인간은 감독을 유지하고 필요에 따라 여정을 조정한다.

3. INTEGRATION OF DESIGN TECHNIQUES INTO THE CORE (설계 기법의 핵심 통합)
Scrum이나 Kanban 같은 Agile 프레임워크는 설계 기법(예: Domain Driven Design)을 범위 밖에 두고 팀이 자체적으로 선택하도록 권장한다. 이는 전반적으로 낮은 소프트웨어 품질로 이어지는 치명적 공백을 남겼다. 미국에서만 소프트웨어 품질 문제로 인한 비용이 2022년에 2.41조 달러로 추정되었다(연구). 설계 기법을 분리하는 대신, AI-DLC는 이를 핵심 구성요소로 통합한다. Domain Driven Design(DDD), Behavior Driven Development(BDD), Test-Driven Development(TDD)를 각각 따르는 팀을 위한 다양한 AI-DLC 변형이 존재할 것이다. 이 논문은 DDD 원칙을 사용하여 시스템을 독립적이고 적절한 크기의 바운디드 컨텍스트로 분해하여 빠르게 병렬 구축할 수 있는 DDD 버전의 AI-DLC를 논의한다. AI는 계획 수립과 작업 분해 중에 이러한 기법을 본질적으로 적용하며, 개발자는 검증과 조정만 하면 된다. 이 통합은 수동 중노동을 제거하면서 소프트웨어 품질을 유지하며 시간 또는 일 단위의 반복 주기를 가능하게 하는 핵심이다 (더 나은 시스템을 더 빠르게 구축이라는 만트라).

4. ALIGN WITH AI CAPABILITY (AI 역량과의 정렬)
이 논문은 AI의 미래 잠재력에 대해 낙관적이지만 현재 상태에 대해서는 완전히 현실적이다. AI-DLC는 현재 AI가 발전하고 있지만, 해석 가능성과 안전성을 보장하면서 고수준 의도를 실행 가능한 코드로 자율적으로 변환하거나 인간의 감독 없이 독립적으로 운영하는 데는 아직 신뢰할 수 없다는 것을 인식한다. 동시에, 개발자가 대부분의 지적 중노동을 수행하고 AI가 단순히 보조만 제공하는 AI-Assisted 패러다임은 개발에서 AI의 전체 잠재력을 해방하지 못한다. AI-DLC는 인간의 참여와 현재 AI의 역량 및 한계를 균형 잡는 AI-Driven 패러다임을 채택한다. 이 안에서 개발자는 검증, 의사결정, 감독에 대한 궁극적 책임을 유지한다. 이 균형은 개발자 판단이 제공하는 핵심 안전장치를 훼손하지 않으면서 AI의 강점을 효과적으로 활용하도록 보장한다.

5. CATER TO BUILDING COMPLEX SYSTEMS (복잡한 시스템 구축 대응)
AI-DLC는 지속적인 기능 적응성, 높은 아키텍처 복잡성, 수많은 트레이드오프 관리, 확장성, 통합 및 커스터마이징 요구사항을 요구하는 시스템 구축에 대응한다. 이는 고급 설계 기법, 패턴, 모범 사례의 적용을 필요로 하며, 일반적으로 대규모 및/또는 규제된 조직 내에서 여러 팀이 응집력 있게 작업하는 것을 포함한다. 비개발자 페르소나가 개발할 수 있고 트레이드오프 관리가 거의 또는 전혀 필요 없는 더 단순한 시스템은 AI-DLC의 범위 밖이며, 로우코드/노코드 접근법에 더 적합하다.

6. RETAIN WHAT ENHANCES HUMAN SYMBIOSIS (인간 공생을 강화하는 것은 유지)
방법론을 재구상하면서도, 인간의 검증과 리스크 완화에 핵심적인 기존 방법론의 산출물과 접점은 유지한다. 예를 들어, 유저 스토리는 무엇을 구축해야 하는지에 대한 인간과 AI의 이해를 정렬시키며, 잘 정의된 계약으로 작용한다. 재구상된 방법론에서도 유저 스토리를 그대로 유지할 것이다. 또 다른 예는 AI가 생성한 계획과 코드가 조직의 리스크 프레임워크를 준수하도록 보장하는 리스크 레지스터이다. 이러한 유지된 요소들은 정렬이나 안전성을 훼손하지 않으면서 빠른 반복을 허용하도록 실시간 사용에 최적화될 것이다.

7. FACILITATE TRANSITION THROUGH FAMILIARITY (친숙함을 통한 전환 촉진)
새로운 방법론은 광범위한 교육을 요구하지 않아야 하며, 기존 실무자라면 하루 만에 방향을 잡고 실천을 시작할 수 있어야 한다. 연상 학습을 통한 더 쉬운 채택을 지원하기 위해, AI-DLC는 현대화된 용어를 도입하면서도 이전 방법론의 익숙한 용어 간 기본 관계를 보존한다. 예를 들어, Scrum의 스프린트는 구축과 검증을 위한 반복 주기를 나타낸다. 하지만 스프린트는 AI 이전 시대에 보통 4~6주 길이였다. AI-DLC에서는 반복 주기가 연속적이며 시간 또는 일 단위이다. 따라서 스프린트를 의도적으로 이름을 바꿔야 한다. AI-DLC는 스프린트를 “볼트(Bolt)“로 리브랜딩하여, 전례 없는 속도를 제공하는 빠르고 집중적인 주기를 강조한다.

8. STREAMLINE RESPONSIBILITIES FOR EFFICIENCY (효율성을 위한 책임 간소화)
AI의 작업 분해 및 의사결정 수행 능력을 활용함으로써, 개발자는 인프라, 프론트엔드, 백엔드, DevOps, 보안 같은 전통적 전문화 사일로를 초월할 수 있게 된다. 이러한 책임의 수렴은 여러 전문 역할의 필요성을 줄여 개발 프로세스를 간소화한다. 그러나 프로덕트 오너와 개발자는 프레임워크에 필수적으로 남아, 감독, 검증, 전략적 의사결정에 대한 핵심 책임을 유지한다. 이러한 역할은 비즈니스 목표와의 정렬을 보장하고, 설계 품질을 유지하며, 리스크 관리 프레임워크 준수를 유지하여, 자동화와 인간 책임 간의 균형을 보존한다. 방법론 정의에서 우리는 제1원칙을 고수하여 역할을 최소한으로 유지하며, 추가 역할은 반드시 필요한 경우에만 도입한다.

9. MINIMISE STAGES, MAXIMISE FLOW (단계 최소화, 흐름 극대화)
자동화와 책임의 수렴을 통해, AI-DLC는 핸드오프와 전환을 최소화하여 지속적인 반복 흐름을 가능하게 하는 것을 목표로 한다. 그러나 인간의 검증과 의사결정은 AI가 생성한 코드가 경직되지(‘빠르게 굳는 시멘트’) 않고 미래 반복에 적응 가능하게 유지되도록 보장하는 데 여전히 핵심적이다. 이를 해결하기 위해, AI-DLC는 핵심 의사결정 분기점에서 인간의 감독을 위해 특별히 설계된 최소한이지만 충분한 수의 단계를 포함한다. 이러한 검증은 일종의 ‘손실 함수’ 역할을 하여, 낭비적인 하류 작업이 발생하기 전에 식별하고 제거한다.

10. NO HARD-WIRED, OPINIONATED SDLC WORKFLOWS (고정된, 독선적 SDLC 워크플로우 없음)
AI-DLC는 다양한 개발 경로(새 시스템 개발, 리팩토링, 결함 수정, 마이크로서비스 확장 등)에 대해 독선적 워크플로우를 규정하지 않는다. 대신, 진정한 AI-First 접근법을 채택하여 AI가 주어진 경로 의도에 기반한 Level 1 계획을 추천한다. 인간은 AI와의 대화형 대화를 통해 이러한 AI 생성 계획을 검증하고 조정하며, Level 2(하위 작업) 및 후속 계층 수준까지 이 프로세스를 계속한다. 작업 실행 수준에서 AI가 작업을 구현하고 인간은 결과의 검증과 확인을 통해 감독을 유지한다. 이 유연한 접근법은 방법론이 적응 가능하고 핵심 결정에 대한 인간의 통제를 유지하면서 AI 역량과 함께 진화할 수 있도록 보장한다.

III. 핵심 프레임워크

이 섹션은 AI-DLC의 핵심 프레임워크를 설명하며, 단계, 역할, 워크플로우, 주요 산출물을 상세히 다룬다.

1. ARTEFACTS (산출물)

인텐트(Intent): AI-DLC에서 인텐트는 비즈니스 목표, 기능, 또는 기술적 결과(예: 성능 확장)든 달성해야 할 것을 캡슐화하는 고수준 목적 선언이다. 이는 AI 주도 분해의 시작점으로, 인간의 목표를 AI 생성 계획과 정렬시킨다.

유닛(Unit): 유닛은 인텐트에서 도출된 응집력 있고 자기 완결적인 작업 요소로, 측정 가능한 가치를 전달하도록 특별히 설계된다. 예를 들어, 비즈니스 아이디어를 구현하려는 인텐트는 독립적 기능 블록을 나타내는 유닛으로 분해될 수 있으며, 이는 DDD의 서브도메인이나 Scrum의 에픽과 유사하다. 각 유닛은 기능 범위를 표현하는 일련의 작업(이 경우 유저 스토리)을 포함한다. AI-DLC의 맥락에서, 인텐트를 유닛으로 분해하는 프로세스는 AI가 주도하며, 개발자 및/또는 프로덕트 오너가 결과 유닛을 검증하고 다듬어 비즈니스 및 기술 목표와의 정렬을 보장한다. 유닛은 느슨하게 결합되어 하류에서 자율적 개발과 독립적 배포를 가능하게 한다.

볼트(Bolt): 볼트는 AI-DLC에서 가장 작은 반복 단위로, 유닛 또는 유닛 내 일련의 작업을 빠르게 구현하도록 설계된다. 볼트(Scrum의 스프린트와 유사)는 집중적 초점과 고속 전달을 강조하며, 구축-검증 주기가 주 단위가 아닌 시간 또는 일 단위로 측정된다. 각 볼트는 잘 정의된 작업 범위(예: 유닛 내 유저 스토리 모음)를 캡슐화하여, 지원하는 유닛의 전체 목표와의 정렬을 유지하면서 점진적 진행을 가능하게 한다. 유닛은 하나 이상의 볼트를 통해 실행될 수 있으며, 병렬 또는 순차적으로 실행될 수 있다. AI가 볼트를 계획하고 개발자/프로덕트 오너가 이를 검증한다.

도메인 설계(Domain Design): 도메인 설계 산출물은 인프라 구성요소와 독립적으로 유닛의 핵심 비즈니스 로직을 모델링한다. AI-DLC의 첫 번째 버전에서, AI는 도메인 주도 설계 원칙을 사용하여 애그리게이트, 값 객체, 엔티티, 도메인 이벤트, 리포지토리, 팩토리를 포함한 전략적 및 전술적 모델링 요소를 생성한다. **논리 설계(Logical Design)**는 적절한 아키텍처 설계 패턴(예: CQRS, 서킷 브레이커 등)의 올바른 선택을 사용하여 비기능 요구사항을 충족하도록 도메인 설계를 확장하여 변환한다. AI는 개발자의 검증을 위해 아키텍처 결정 기록(ADR)을 생성한다. 논리 설계 명세를 통해, AI는 적절한 AWS 서비스와 구성요소를 선택하여 잘 설계된 원칙을 준수하면서 코드와 단위 테스트를 생성한다. 이 단계에서 AI 에이전트는 단위 테스트를 수행하고,

결과를 분석하며, 개발자에게 수정 사항에 대한 추천을 제공한다. 배포 유닛(Deployment Units): 배포 유닛은 패키징된 실행 가능 코드(예: Kubernetes 환경용 컨테이너 이미지, AWS Lambda 같은 서버리스 함수), 구성(예: Helm Charts), 인프라 구성요소(예: Terraform 또는 CFN 스택)를 포함하는 운영 산출물로, 기능 수용, 보안, NFR 및 기타 리스크에 대해 테스트된다. AI는 기능 테스트, 정적 및 동적 보안 테스트, 부하 테스트 시나리오를 포함한 모든 관련 테스트를 생성한다. 테스트 시나리오와 케이스에 대한 인간의 검증과 조정 후, AI 에이전트는 테스트 스위트를 실행하고, 결과를 분석하며, 실패 지점을 코드 변경, 구성 또는 기타 의존성과 상관시킨다. 따라서 이러한 유닛은 기능 수용, 보안 준수, 비기능 요구사항(NFR) 준수, 운영 리스크 완화에 대해 엄격히 테스트되어 원활한 배포를 위한 준비 상태를 보장한다.

2. PHASES & RITUALS (단계 & 의식)

인셉션 단계(Inception Phase): 인셉션 단계는 인텐트를 포착하고 이를 개발을 위한 유닛으로 변환하는 데 초점을 맞춘다. 이 단계는 협업적 요구사항 정교화 및 분해 의식인 **“몹 엘라보레이션(Mob Elaboration)”**을 사용한다. 이는 퍼실리테이터가 이끄는 공유 화면이 있는 단일 공간에서 진행된다. 몹 엘라보레이션 동안, AI는 도메인 지식과 느슨한 결합 및 높은 응집력의 원칙을 활용하여 하류에서 빠른 병렬 실행을 위해 인텐트를 유저 스토리, 수용 기준, 유닛으로 초기 분해하는 것을 제안하는 중심 역할을 한다. 프로덕트 오너, 개발자, QA 및 기타 관련 이해관계자(몹)는 과소 설계되거나 과잉 설계된 부분을 조정하고 현실 세계의 제약과 정렬시키며 이러한 AI 생성 산출물을 협업적으로 검토하고 다듬는다. 이 단계의 산출물은 잘 정의된 유닛과 그

구성요소를 포함한다: a) PRFAQ, b) 유저 스토리, c) 비기능 요구사항(NFR) 정의, d) 리스크 설명(조직의 리스크 레지스터와 매칭, 있는 경우), e) 비즈니스 인텐트를 추적하는 측정 기준, f) 유닛을 구축할 수 있는 제안된 볼트. 몹 엘라보레이션은 수주 또는 수개월의 순차적 작업을 몇 시간으로 압축하면서, 몹 내부와 몹과 AI 간의 깊은 정렬을 달성한다.

구축 단계(Construction Phase): 구축 단계는 인셉션 단계에서 정의된 유닛을 테스트되고 운영 준비된 배포 유닛으로 변환하는 작업의 반복적 실행을 포함한다. 이 단계는 AI가 기술적 고려사항과 독립적으로 비즈니스 로직을 모델링하는 도메인 설계에서, 비기능 요구사항과 적절한 클라우드 설계 패턴이 적용되는 논리 설계로 진행된다. AI는 잘 설계된 원칙을 준수하면서 구성요소를 적절한 AWS 서비스에 매핑하여 논리 설계에서 상세한 코드를 생성한다. 이 단계는 기능, 보안, 운영 준비 상태를 보장하기 위한 자동화된 테스트로 마무리된다. 개발자는 각 단계에서 AI 생성 산출물을 검증하고 핵심 결정을 내리는 데 집중하여, 각 반복에서 품질과 적응성을 보장한다. 브라운필드(기존 애플리케이션) 시나리오에서, 구축 단계는 먼저 코드를 의미적으로 풍부한 모델링 표현으로 격상시켜 AI에 대한 컨텍스트가 간결하고 정확해지도록 하는 것을 포함한다. 제안되는 모델링 표현은 정적 모델(도메인 구성요소, 책임, 관계만)과 동적 모델(구성요소가 중요한 유스케이스를 실현하기 위해 어떻게 상호작용하는지)

요약

3단계 구조

  1. 인셉션 (Inception) — “무엇을 만들 것인가”

    • 몹 엘라보레이션: 팀 전원이 한 공간에서 AI와 함께 요구사항 정교화
    • AI가 인텐트 → 유저스토리 → 유닛으로 분해 제안
    • 인간이 검증·수정·승인
    • 산출물: 유저스토리, NFR, 리스크, 측정기준, 볼트 계획

  2. 구축 (Construction) — “어떻게 만들 것인가”

    • 도메인 설계 → 논리 설계 → 코드 생성 → 테스트 순서로 진행
    • AI가 각 단계를 수행하고, 개발자가 각 단계마다 검증
    • 몹 컨스트럭션: 팀이 한 공간에서 실시간 의사결정
    • 브라운필드(기존 시스템)는 먼저 코드를 모델로 역공학한 후 진행

  3. 운영 (Operations) — “어떻게 유지할 것인가”

    • AI가 메트릭/로그/트레이스 분석 → 이상 탐지 → 해결책 제안
    • 인간이 승인하면 AI가 실행