최근 AI 에이전트(AI Agent)의 유행에 따라 조직이나 현장 내에서도 「AI 주도 개발(AI-Driven Development)」이라는 용어가 버즈워드(Buzzword)처럼 사용되기 시작했습니다. 하지만 실제로 AI를 이용한 개발을 실천하다 보면, 「AI 도구를 도입하는 것뿐」이라는 표면적인 이해에 대해 강한 위화감을 느끼는 장면이 매우 많았습니다.

본고는 그 「답답함」의 정체에 대해 제가 가진 지식을 바탕으로 생성 AI(Generative AI)와 대화하며 풀어내고, AI 주도 개발이 성립하기 위해 정말로 필요한 개발 기반 및 프로세스의 전제 조건에 대해 실천자의 관점에서 고찰 및 언어화하여 리포트한 것입니다.

(본고는 문서의 퇴고에 생성 AI를 활용하였으나, 내용의 고찰 및 의견은 저 개인의 의견입니다.)

주기

본고에서 사용하는 「AI 지원 개발」, 「AI 협력 개발」, 「AI 주도 개발」의 성숙 모델은 현 시점에서 업계 표준으로 확립된 분류가 아니라, AI 활용의 성숙 단계를 정리하고 설명하기 위해 필자가 정의한 개념 모델이다.

또한, 본고는 AI 주도 개발을 소프트웨어 공학(Software Engineering) 및 개발 프로세스의 관점에서 정리하고, 그 성립 요건과 향후 방향성에 대해 고찰한 것이다.

참고로, 유사한 목적을 가진 성숙도 모델로서 ELEKS의 「AI-SDLC Maturity Model」이나 Carnegie Mellon 대학교 SEI와 Accenture가 제안한 「AI Adoption Maturity Model」 등이 있다. 본고의 모델은 이것들을 참고하면서, 상황 파악과 AI 주도 개발의 사고방식을 알기 쉽게 전달하는 것을 목적으로 독자적으로 간략화 및 재구성한 것이다.

최근 「AI 주도 개발(AI-Driven Development: AIDD)」이라는 용어가 급속히 침투하고 있다. 하지만 AI 코딩 도구나 AI 에이전트를 도입하는 것만으로 개발 프로세스 전체가 AI 주도 개발로 이행될 수 있는 것은 아니다.

AI 주도 개발의 본질은 **「AI를 도입하는 것」이 아니라, 「AI가 자율적으로 개발을 진행할 수 있는 환경을 정비하는 것」**에 있다.

AI는 모호한 자연어만으로는 안정적인 성과를 내기 어렵다. 반면, 기계 판독 가능한 사양(Specification, 스펙), 충분한 컨텍스트(Context), 자동 테스트, CI/CD 파이프라인 등이 정비된 환경에서는 높은 재현성을 가지고 구현·검증·개선을 반복할 수 있다.

따라서 AI 주도 개발은 독립된 새로운 개발 기법이 아니라, 애자일 개발(Agile Development), CI/CD, 클라우드(Cloud), 클라우드 네이티브(Cloud Native), DevOps, DevSecOps, 플랫폼 엔지니어링(Platform Engineering) 등 지금까지 쌓아온 소프트웨어 개발 기술 및 개발 프로세스의 진화 연장선상에 위치한다.

본고에서는 AI 주도 개발의 본질을 정리함과 동시에, 그 성립 요건, 폭포수형(Waterfall) 개발과의 관계, 그리고 기업이 AI 주도 개발에 이르기까지의 성숙 프로세스에 대해 고찰한다.

AI 주도 개발이란 단순히 AI를 사용하여 코드를 보완하거나 생성하는 것이 아니다.

지향하는 모습은 인간이 정의한 사양을 바탕으로 AI가 **계획·구현·검증·수정을 자율적으로 반복하는 피드백 루프(Agentic Loop)**를 실현하는 것이다.

구체적으로 AI는 다음과 같은 공정을 반복적으로 실행한다.

• 사양을 바탕으로 한 각종 문서 생성
• 구현 코드 생성
• 테스트 코드 생성 및 실행
• 정적 분석(Static Analysis)
• 보안 체크(Security Check)
• 리팩터링(Refactoring)
• 에러 수정(Self-Healing)
• Pull Request 작성
• 리뷰 결과 반영

AI는 생성 결과나 테스트 결과를 지속적으로 피드백하며 자율적으로 개선을 반복한다. 즉, AI는 「코드를 쓰는 보조자」가 아니라, **개발 프로세스의 일부를 담당하는 에이전트(Agent)**로서 기능한다.

그러기 위해서는 인간의 해석에 의존하는 모호한 사양서가 아니라, AI도 엄격하고 일의적으로 해석할 수 있는 **기계 판독 가능한 사양(구조화 데이터, 타입, 제약 조건)**이 필요하다.

현재 논의되는 각종 개발 기법은 서로 경쟁하는 것이 아니라, 각각 서로 다른 레이어의 과제를 해결하기 위한 접근 방식이다.

※본고에서는 OpenAPI, 데이터베이스 스키마, 타입 정의, Terraform 등 기계 판독 가능한 사양을 단일 진실 공급원(Single Source of Truth, SSOT)으로 삼아 개발을 진행하는 스타일을 편의상 「스펙 주도 개발 (SDD)」이라 부른다.

【인간】
요건 정의·아키텍처 설계·제약 정의
│
...

이 모델에서 인간은 요건·설계·제약·품질 기준을 정의하고, AI는 해당 사양을 바탕으로 구현·검증·개선을 반복한다.

즉, 인간은 「무엇을 만들 것인가」와 「품질을 보증할 것인가」를 담당하고, AI는 「정의된 사양과 제약 범위 내에서 구현·개선 사이클을 고속화하는 역할」을 담당하는 역할 분담이 이루어진다. 이와 같이 인간과 AI가 각각 특기하는 영역을 분담함으로써 개발 속도와 품질의 양립을 목표로 하는 것이 AI 주도 개발의 본질이다.

AI 주도 개발은 갑자기 탄생한 것이 아니다. 소프트웨어 개발은 오랜 기간 동안 「더 짧은 사이클로, 더 안전하게, 더 고품질의 소프트웨어를 제공한다」는 과제를 해결하기 위해 진화해 왔다. AI 주도 개발은 그 진화의 연장선상에 위치하는 기술·개발 프로세스이다.

워터폴 (Waterfall)
│
▼
...

각 기술은 저마다 서로 다른 과제를 해결해 왔다.

AI는 이러한 자동화 기반 위에서 비로소 최대한의 능력을 발휘할 수 있다. 다시 말해, AI 주도 개발은 「AI만」으로 성립되는 것이 아니라, 자동화된 개발 기반과 표준화된 프로세스를 전제로 하여 비로소 성립한다.

(AI Development Maturity Model)

AI 주도 개발은 단번에 실현할 수 있는 것이 아니다. 실제 기업에서는 기존 프로세스 내에서 AI를 활용하는 단계부터 시작하여, 개발 기반과 프로세스의 성숙도에 따라 점진적으로 AI 중심의 개발로 이행해 나간다.

본고에서는 이 성숙 과정을 다음과 같은 3단계로 정리한다.

【Level 1: AI 지원 개발 (AI-assisted Development)】
인간 주체 / AI는 보조 도구
(Copilot, ChatGPT, Cursor, GitHub Copilot 등)
...

Level 1에서는 인간이 주체이며, AI는 어디까지나 작업 효율을 높이기 위한 지원 도구로 이용된다.

Level 2에서는 AI가 각 공정에 통합되어 인간과 협조하며 개발을 진행한다. 현재 많은 기업이 목표로 하는 AI 활용은 이 단계에 위치하는 경우가 많다.

Level 3에서는 AI를 기존 프로세스에 적용하는 것에 그치지 않고, AI가 최고의 능력을 발휘할 수 있도록 개발 프로세스 자체를 재설계한다.

여기서는 기계 판독 가능한 사양(SSOT)을 중심으로 AI가 자율적인 피드백 루프(Agentic Loop)를 구성하고, 인간은 요건·아키텍처·품질 보증·거버넌스를 담당한다. 따라서 Level 1 및 Level 2는 AI 주도 개발을 부정하는 것이 아니라, AI 주도 개발로 나아가기 위한 중요한 성숙 단계이다. 반면, Level 3는 단순한 AI 도구의 도입이 아니라 개발 프로세스 자체의 변혁을 동반한다는 점에서 본질적인 차이가 있다.

성숙도를 높이기 위해서는 AI 도구의 도입만으로는 불충분하다. 다음과 같은 기반 정비가 병행되어야 한다.

기계 판독 가능한 사양 (Machine-readable Specification, SSOT) 정비
OpenAPI · 스키마 · 타입 정의 (Type Definition)의 표준화
Infrastructure as Code (IaC)
자동 테스트 (Automated Testing)
CI/CD 파이프라인
DevSecOps
Platform Engineering
지식의 표준화
AI가 활용 가능한 문서 정비

즉, "AI를 도입하는 것"과 "AI 주도 개발 (AI-Driven Development)을 실현하는 것"은 동의어가 아니다. AI 주도 개발이란, AI가 능력을 최대한 발휘할 수 있도록 개발 프로세스 · 개발 기반 · 조직을 지속적으로 성숙시켜 나가는 노력 그 자체이다.

참고: 유사한 성숙도 모델에 대하여

본고에서 정의한 Level 1~3 모델은 업계 표준이 아니라, 어디까지나 현상을 파악하고 AI 주도 개발로 나아가는 경로를 알기 쉽게 보여주기 위한 간략화된 모델이다. 유사한 목적을 가진 기존 프레임워크로는 다음과 같은 것들이 있다.

• AI-SDLC Maturity Model (ELEKS): Tradition(전통형)부터 AI-Autonomous(AI 자율형)까지 5단계로 정리하며, 엔터프라이즈에서의 거버넌스 및 조직 변혁 관점을 중시하는 모델.
• AI Adoption Maturity Model (Carnegie Mellon 대학교 SEI · Accenture, 2026): 조직 전략, 워크플로우 재설계, 리스크 · 거버넌스, 엔지니어링 등 8개의 능력 영역으로부터 성숙도를 평가하는, 보다 범용적이고 엔터프라이즈 지향적인 프레임워크.
• Five Levels (Dan Shapiro): 자율 주행의 레벨 분야를 원용하여, AI가 어디까지 인간의 개입 없이 개발을 완수할 수 있는가라는 "자율성"의 관점에서 단계를 정의하는 모델.

이들은 평가 축이나 입도가 다르기 때문에 일률적으로 비교할 수는 없으나, 모두 "AI 도구의 도입"과 "조직 · 프로세스의 성숙"을 구분하여 파악하고 있다는 점에서 본고의 문제 의식과 일치한다.

AI가 고속으로 코드를 생성하더라도, 그 성과를 지속적이고 자동적으로 검증 · 개선할 수 없다면 개발 전체의 생산성 향상으로 이어지지 않는다. AI 주도 개발에서는 AI 스스로가 생성 결과를 평가하고 수정할 수 있는 피드백 루프 (Feedback Loop)를 성립시켜야 한다.

예를 들어, 자동 테스트가 존재하지 않는 경우 다음과 같은 상태가 된다.

【자동 테스트가 존재하지 않는 경우】

• AI가 코드 생성
• 인간이 수동 테스트
• 수정 사항 판단
• AI가 재생성
• 인간이 다시 수동 테스트

이 경우, AI의 생성 속도에 비해 인간의 확인 작업이 병목 (Bottleneck)이 되어 AI의 능력을 충분히 활용할 수 없다. 마찬가지로 다음과 같은 요소가 부족할 경우, AI 주도 개발의 효과는 제한적이다.

• CI/CD가 존재하지 않는 경우
  AI가 고속으로 코드를 생성하더라도 빌드 · 테스트 · 배포가 수작업이라면 릴리스까지의 리드 타임 (Lead Time)은 단축되지 않는다. AI에 의한 개발 속도 향상과 릴리스 프로세스의 속도가 일치할 때 비로소 가치가 발휘된다.

• DevSecOps가 존재하지 않는 경우
  AI에 의해 생성된 코드에 포함된 취약성이나 라이브러리 리스크를 지속적으로 검증할 수 없다면, 품질 문제나 보안 리스크를 고속으로 확대시킬 가능성이 있다. AI는 품질 보증 메커니즘이 아니라, 품질 보증 프로세스 위에서 동작하는 고속 생성 엔진이다.

• 기계 판독 가능한 사양이 존재하지 않는 경우
  AI가 자연어만을 입력값으로 사용하여 개발을 진행할 경우, 해석의 차이나 컨텍스트 (Context) 부족이 발생하기 쉽다. 반면, OpenAPI, Database Schema, Type Definition, Policy, Infrastructure Definition 등의 기계 판독 가능한 사양을 단일 진실 공급원 (Single Source of Truth, SSOT)으로서 관리함으로써, AI는 더욱 정확하고 재현성 높은 개발을 수행할 수 있다.

즉, AI 주도 개발의 본질은 "AI 자체의 성능"이 아니라 "AI가 능력을 발휘할 수 있는 개발 기반과 프로세스의 성숙도"에 있다.

AI 주도 개발은 워터폴 (Waterfall)형 개발의 역사적 의의나 유효성을 부정하는 것이 아니다. 대규모 시스템 개발이나 높은 품질 보증이 요구되는 영역에서는 계획적인 공정 관리나 리뷰 체계가 현재도 중요한 역할을 한다.

반면, 공정별로 명확한 분업이 이루어지거나 다수의 중간 결과물을 전제로 하는 프로세스에서는, AI에 의한 고속 피드백 루프와 구조적인 마찰이 발생한다.

기존 방식의 개발에서는 다음과 같은 작업이 존재한다.

• Excel 기반의 상세 설계서 작성
• 공정별 승인 플로우 (Approval Flow)
• 수동 테스트
• 수동 배포
• 개별 환경별 설정 작업

이러한 작업들은 품질 관리상 필요한 경우도 있지만, 한편으로는 AI에 의한 고속 생성·수정 사이클과 속도 차이가 발생한다. 예를 들어, AI가 몇 분 만에 코드 수정안을 생성할 수 있더라도, 리뷰·승인·환경 반영에 며칠이 소요된다면 개발 전체의 속도는 인간 측의 프로세스에 의해 제약된다.

기존의 폭포수 (Waterfall) 개발에서는 요구사항 정의 → 기본 설계 → 상세 설계 → 구현 → 단위 테스트와 같이 공정을 분리하여 관리한다.

반면, AI 주도 개발 (AI-Driven Development)에서는 상세 설계·구현·단위 테스트와 같은 공정의 경계가 점차 모호해지며, 하나의 반복적인 피드백 루프 (Feedback Loop)로 통합되는 경향이 있다. 예를 들어, 스펙 (Spec) 정의 → AI 구현 → 테스트 생성 → 검증 → 수정 → 재검증이라는 사이클을 고속으로 반복한다.

그 결과, 기존의 상세 설계서에 기재되어 있던 정보는 다음과 같이 보다 기계 판독이 가능한 (Machine-readable) 산출물로 이행되어 간다.

• OpenAPI
• 데이터베이스 스키마 (Database Schema)
• 타입 정의 (Type Definition)
• 테스트 코드 (Test Code)
• 아키텍처 결정 기록 (Architecture Decision Record, ADR)
• 소스 코드

기존의 SI 개발에서는 인월 (Man-month) 공수나 공정 단위의 견적·관리가 널리 이용되어 왔다. 하지만 AI 주도 개발에서는 다음과 같은 차이가 커진다.

• AI에 의해 고속화되는 작업
• 인간에 의한 판단이 필요한 작업
• 설계나 품질 보증 등 경험에 의존하는 작업

따라서 단순한 작업량이 아니라, "어떤 가치를 제공할 것인가", "어떤 품질을 보증할 것인가", "AI를 포함한 개발 능력을 어떻게 관리할 것인가"라는 관점으로의 전환이 요구된다.

AI 주도 개발은 단순히 AI 코딩 도구나 채팅 AI를 도입하는 것만으로는 실현할 수 없다. 그 본질은 기계 판독 가능한 사양 (SSOT, Single Source of Truth), AI에 의한 자율적인 구현·검증·개선 루프, 자동 테스트, CI/CD, IaC, DevSecOps, 플랫폼 엔지니어링 (Platform Engineering) 등, 지금까지 소프트웨어 업계가 쌓아온 개발 프랙티스 (Practices) 위에 AI라는 새로운 자율화 엔진을 결합하는 것이다.

또한, AI 주도 개발로의 전환은 단번에 이루어지는 것이 아니다. 현실적으로는 다음과 같은 성숙 프로세스를 거쳐 진화해 나간다.

AI 지원 개발 → AI 협업 개발 → AI 주도 개발

각 공정에 AI를 도입하려는 노력은 AI 주도 개발을 부정하는 것이 아니라, 그 실현을 향한 중요한 첫걸음이다. 한편, 최종적인 도달점에서는 AI를 기존 프로세스에 적용하는 것에 그치지 않고, AI를 전제로 개발 프로세스 자체를 재설계하는 것이 중요해진다.

향후 개발자의 역할은 "코드를 쓰는 사람"에서, **"무엇을 만들어야 하는지 정의하는 사람", "적절한 사양과 제약을 설계하는 사람", "AI의 생성물을 평가하는 사람", "시스템 품질을 보증하는 사람"**과 같이 더 상위의 설계·판단·감사를 담당하는 역할로 변화할 것이다.

AI의 성능 향상에만 기대할 것이 아니라, AI가 최대한의 능력을 발휘할 수 있는 프로세스·기반·조직을 정비해야만 진정한 AI 주도 개발이 실현된다.

단번에 Level 3 (AI 주도 개발)를 목표로 할 필요는 없다. 오히려 중요한 것은 자조직이 현재 어느 수준에 있는지를 정확히 파악하는 것이다.

• 자사의 사양서는 AI가 해석 가능한 형식인가, 아니면 자연어나 Excel에 의존하고 있는가
• 자동 테스트·CI/CD는 AI의 생성 속도에 걸맞은 속도로 피드백을 주고 있는가
• 리뷰나 승인 프로세스가 AI의 수정 사이클에 병목 (Bottleneck)이 되고 있지는 않은가

이러한 질문에 답하는 것이 AI 주도 개발로 나아가는 성숙 프로세스의 출발점이 된다. AI 도구의 도입은 목표가 아니라, 개발 프로세스와 조직을 지속적으로 성숙시켜 나가기 위한 긴 여정의 첫걸음에 불과하다고 생각해야 한다.

--
ELEKS, "AI-SDLC Maturity Model: Traditional to Autonomous Development"
https://eleks.com/blog/ai-sdlc-maturity-model/

--
Carnegie Mellon University Software Engineering Institute & Accenture, "The AI Adoption Maturity Model v1.0"

https://www.sei.cmu.edu/library/ai-adoption-maturity-model/ -
Augment Code, "AI SDLC 성숙도 모델: 당신은 어느 단계에 있습니까?"