AI-DLC는 운영 유지보수에 어떻게 적용할까

AI 코딩 도구를 도입하면 코드 생성량은 바로 늘어난다. 존재하지 않는 메서드를 그럴듯하게 호출하거나 실제 상태코드와 다른 값을 만들고도 변경이 완료됐다고 판단하는 경우가 빈번하다. 한 저장소에서 빌드가 통과했지만 연결된 프런트엔드와 배치의 영향도를 놓치는 일도 있다.

**AI-DLC(AI-Driven Development Life Cycle)**는 이 문제를 모델의 주의력에만 맡기지 않는다. AI가 계획과 질문, 산출물을 만들고 사람이 핵심 결정을 승인하는 개발 수명주기를 워크플로우로 만든다. AWS가 2025년에 소개한 방법론은 Inception, Construction, Operations의 세 페이즈로 설명됐다.¹ 현재 v2 구현은 Initialization과 Ideation을 더해 5개 페이즈, 33개 스테이지로 확장됐고 11개 도메인 전문가와 2개 검토 전용 에이전트, 적응형 워크플로우 구성 에이전트를 포함한 14개 에이전트를 제공한다.²³

AI-DLC는 코드를 더 잘 생성하는 프롬프트 모음이 아니다. 작업에 필요한 단계만 고르고 단계마다 질문과 산출물을 남기며 사람의 승인과 검증을 다음 단계의 선행조건으로 삼는 체계다.

AI-DLC는 코드를 더 많이 만드는 도구가 아니다

일반적인 AI 코딩 도구는 요청과 결과 사이를 짧게 만든다. AI-DLC는 그 사이에 결정과 증적을 넣어서 요구사항이 충분한지, 기존 코드를 실제로 확인했는지, 설계와 구현이 연결되는지, 테스트와 배포 준비가 끝났는지를 단계별로 묻는다.

현재 v2는 모든 작업에 같은 절차를 강요하지 않는다. 전체 기능 개발은 33개 스테이지를 실행하지만 bugfix 범위는 7개, refactor는 8개, security-patch는 10개 스테이지로 줄어든다. 범위는 실행할 단계를 정하고 깊이는 각 단계가 만드는 산출물의 상세 수준을 정하며 테스트 전략은 별도로 조정한다.⁴

AWS 운영 유지보수 사례에서 먼저 봐야 할 전제

AWS 한국 기술 블로그에 공개된 LG CNS 사례는 대규모 운영 유지보수 현장에서 AI-DLC를 조정한 과정을 다룬다.⁵ 사례에서 눈에 띄는 것은 커스터마이징 32건보다 도입 전에 이미 갖춰져 있던 조건이다.

• 대상 애플리케이션의 현대화가 끝나 AI가 코드 구조를 분석할 수 있었다.
• 범용 기술 스택을 사용해 모델이 코드 패턴을 이해하기 쉬웠다.
• Amazon Q Developer를 먼저 사용하면서 보안 거버넌스 검토를 통과한 상태였다.

이 조건이 없었다면 워크플로우를 정교하게 만들어도 시작점에서 흔들렸을 가능성이 크다. 빌드 방법을 재현할 수 없고 회귀 테스트가 없으며 업무 규칙이 담당자의 기억에만 남아 있다면, AI는 잘못된 문맥을 더 빠르게 처리할 뿐이다.

사례가 해결한 문제도 운영 유지보수의 특성을 잘 보여 준다. 기본 워크플로우는 신규 개발 여부와 인프라 설계를 반복해서 물었고 AI는 실제로 없는 getUserName() 같은 메서드나 확인되지 않은 코드값을 만들었다. 프런트엔드, 백엔드, 배치가 여러 저장소로 나뉜 환경에서는 현재 저장소만 보고 변경해 다른 저장소의 영향도를 놓쳤다.⁵

LG CNS는 5개 시스템에서 1개월 동안 16건의 개발성 변경 요청에 AI-DLC를 적용했고 공개 글은 작업 유형 전반에서 표준공수를 일관되게 밑돌았다고 보고한다. 반복 패턴이 뚜렷한 작업에서 효과가 더 컸다는 설명도 있다.⁵ 다만 정확한 절감률, 품질 지표, 비교군과 독립 재현 자료는 공개되지 않았다. 이 수치를 우리 조직의 ROI 예상값으로 옮겨 적을 수는 없다. 사례는 가능성을 보여 주는 근거이며 투자 결정은 자체 기준선과 파일럿 결과로 내려야 한다.

DMM 사례가 보여 준 병목의 이동

DMM.com은 2025년 9월 1일부터 이틀 동안 4개 팀이 참여한 AI-DLC 워크숍을 진행했다. 제품 관리자, 디자이너, 엔지니어가 한 팀으로 요구사항과 구현 방향을 결정했고 모든 팀이 코드 생성부터 동작 확인까지 마쳤다고 보고했다.⁶

이 사례에서 더 유용한 대목은 단축률보다 병목에 대한 진단이다. DMM은 기존 개발 과정의 부담으로 코드 리뷰, 지식 이전, 테스트와 디버깅, 조정과 의사소통을 들었다. 워크숍의 시간 단축도 AI의 코드 생성뿐 아니라 실시간 공동 작업과 공정 사이의 대기 감소가 함께 만든 결과라고 설명한다. AI-DLC를 도입하면 승인 업무가 사라지는 것이 아니라 결정권자의 응답 속도가 전체 흐름을 좌우한다.

공개된 수치는 방향성 근거로만 읽어야 한다. 공수 표에는 4.5인월이 12인월, 1014인일이 38인일, 2주가 2일로 바뀌어 단축률이 2085%로 제시된다.

DMM이 남긴 과제를 파일럿 설계에 바로 반영한다. 업무 범위를 작게 나누고 결정권자의 시간을 확보하며 원격 환경에서 공동 판단을 어떻게 진행할지 정한다. 팀이 AI-DLC 절차를 익히도록 진행 책임자도 지정한다. 모델 호출 속도만 높이고 이 조건을 비워 두면 승인 대기시간이 새로운 병목이 된다.

사례에서 가져올 원칙과 그대로 복사하면 안 되는 구현

AWS 사례는 상류 방법론 원본을 직접 고치지 않고 조직별 차이를 별도 계층에 둔다. 이 원칙은 지금도 유효하다. 프레임워크를 업그레이드할 때 조직 규칙이 사라지지 않아야 하고 어떤 변경이 AWS 원본이며 어떤 변경이 사내 정책인지 구분할 수 있어야 한다.

구현은 현재 버전에 맞춰 다시 읽어야 한다. 사례 글은 Kiro의 Steering, Hook, Skill 위에 전사 공통·도메인·시스템의 3계층 Override를 구성했다. 현재 AI-DLC v2는 Kiro뿐 아니라 Claude Code, Codex CLI, Cursor, GitHub Copilot 등 여러 하네스에서 같은 코어를 사용한다. v2 규칙은 org → team → project → phase → stage를 누적하는 strict-additive 방식이며 런타임에서 하위 규칙이 상위 규칙을 조용히 덮어쓰는 overrides 블록을 사용하지 않는다. 충돌은 규칙을 기록할 때 검출한다.²⁷

공식 저장소도 한 URL 안에서 버전이 갈린다. 기본 main README는 맨 위에서 2.0 GA를 알리지만 아래 본문에는 Inception, Construction, Operations의 3페이즈 구성과 이전 배포 파일을 복사하는 설치 방식이 함께 남아 있다.⁸ 반면 v2 브랜치는 5개 페이즈와 33개 스테이지, 하네스 중립 코어와 dist/<harness>/ 배포 구조를 설명한다.² 저장소 루트만 북마크하면 개념은 2.0으로 읽고 설치 절차는 이전 구조에서 가져오는 혼용이 생길 수 있다.

애플리케이션 샘플 디렉터리와 병합 로직을 그대로 복제하기보다 다음 원칙을 옮기는 편이 안전하다.

1. 프레임워크가 배포한 방법론 지식과 에이전트 파일은 수정하지 않는다.
2. 회사 표준과 프로젝트 업무 지식은 팀 지식 계층에 둔다.
3. 반드시 지켜야 할 행동은 규칙으로 쓰고 결과를 기계적으로 확인할 항목은 센서나 테스트로 만든다.
4. 작업마다 필요한 범위와 승인 수준을 선택한다.
5. v2 브랜치와 릴리스·커밋, 하네스 구성을 함께 기록하고 업그레이드 전에 회귀 검증한다.

v2 공식 문서도 프레임워크 지식과 사용자 관리 팀 지식을 분리한다. 팀 지식은 회사 코딩 표준, 아키텍처 원칙, 보안 정책, 테스트 기준처럼 에이전트가 판단할 때 참고할 내용이다.⁹ 행동을 제한해야 한다면 지식을 반복해서 적기보다 규칙과 검증 장치를 둔다.

도입 전에 다섯 가지 계약을 작성한다

다음 다섯 가지는 AI-DLC의 공식 구성요소를 그대로 옮긴 목록이 아니라 운영 유지보수 조직이 파일럿 전에 합의할 내용을 재구성한 도입 계약이다.

1. 작업 범위 계약

먼저 AI-DLC에 맡길 변경 유형과 맡기지 않을 변경을 나눈다. 단순 결함 수정, 반복적인 API 변경, 테스트 보강처럼 결과를 검증하기 쉬운 업무부터 시작한다. 데이터 마이그레이션, 대규모 권한 변경, 되돌리기 어려운 운영 조작은 별도 승인과 수동 실행을 유지한다.

각 업무 유형에는 기본 범위, 반드시 실행할 단계, 생략할 수 없는 검증을 붙인다. bugfix라는 이름만 보고 자동으로 7단계를 선택하지 말고 여러 저장소와 공용 스키마를 건드리면 영향도 분석 단계를 다시 포함한다.

2. 문맥과 근거 계약

AI가 믿어도 되는 근거의 우선순위를 정한다. 실행 중인 소스와 스키마, 빌드 설정, 승인된 API 명세를 가장 위에 두고 오래된 위키나 예전 티켓은 보조 자료로 낮춘다. 코드에서 확인하지 못한 식별자와 코드값은 추측하지 않고 [VERIFY_REQUIRED]나 [CODE_VALUE_TBD]처럼 검토가 필요한 상태로 남긴다.

멀티 저장소 환경에는 API, 공유 DB, 이벤트 토픽, 공용 DTO와 배치 의존성을 찾는 경로가 필요하다. 저장소 목록만 주는 것으로는 부족하다. 어떤 변경 신호가 어느 저장소의 추가 분석을 요구하는지 규칙으로 적는다.

3. 승인과 권한 계약

사람의 승인은 산출물을 읽었다는 버튼이 아니다. 요구사항 승인, 구현 승인, 배포 승인처럼 결정의 종류와 책임자를 구분한다. 읽기, 파일 수정, 외부 시스템 호출, 커밋, 배포의 권한도 따로 둔다.

AI-DLC v2는 Initialization을 제외한 단계 끝에 승인 게이트를 두고 승인과 수정 요청을 상태와 감사 로그에 기록한다.¹⁰ 조직은 여기에 고위험 작업의 이중 승인, 업무시간 제한, 운영 자격증명 사용 금지 같은 실제 권한 경계를 연결한다.

게이트를 늘리는 것만으로 통제력이 생기지는 않는다. DMM 사례처럼 결정권자가 실시간으로 참여할 때는 흐름이 빨라지지만 승인자가 다른 업무에 묶이면 AI가 만든 산출물이 대기열에 쌓인다.⁶ 승인 계약에는 책임자뿐 아니라 응답 기한, 대리 승인자, 함께 검토할 시간대를 적는다.

4. 검증 계약

검증 계약은 “테스트를 실행한다”보다 구체적이어야 한다. 변경 전후의 빌드와 테스트, 영향받는 저장소, API·이벤트 계약, 데이터 정합성, 성능과 보안 기준을 작업 유형별로 정한다. 실행하지 못한 검사는 통과로 기록하지 않고 미검증 상태로 남긴다.

첫 번째 목표는 AI가 만든 코드의 합격률을 높이는 일이 아니다. 잘못된 변경이 승인이나 배포 단계로 넘어가지 못하게 만드는 일이다. 실패하면 중단하고 원인을 보여 주는 검증이, 결과를 그럴듯하게 설명하는 에이전트보다 중요하다.

5. 증적과 학습 계약

티켓, 브랜치, 질문과 답변, 설계 산출물, 코드 변경, 테스트 결과, 승인자와 배포 결과를 하나의 작업 식별자로 연결한다. AI-DLC v2는 의도별 상태 파일과 추가 전용 감사 로그를 사용해 현재 위치와 전체 사건 기록을 분리한다.¹¹

반복 교정은 규칙으로 남길 수 있지만 자동 승격하면 안 된다. 한 프로젝트의 예외를 조직 전체 규칙으로 넓히면 다른 시스템을 잘못 제한할 수 있다. v2 학습 루프도 확인된 교정을 기본적으로 프로젝트 범위에 기록하고 사용자가 선택할 때만 팀 범위로 넓힌다.⁷

30일 파일럿은 생산성보다 통제 가능성을 먼저 검증한다

첫 파일럿의 목표를 “개발 시간을 몇 퍼센트 줄인다”로만 잡으면 빠른 작업만 고르게 된다. 운영 유지보수에서는 같은 요청을 다시 실행할 수 있는지, 잘못된 가정을 중간에서 멈출 수 있는지, 사람이 결정 이유를 추적할 수 있는지가 먼저다.

1주차에 코드 생성을 제한하는 이유는 도구 성능을 낮게 보기 때문이 아니다. 조직의 문서와 코드가 AI에게 어떤 잘못된 신호를 주는지 초기에 찾기 위해서다. 이때 발견한 문제를 곧바로 전사 규칙으로 만들지 말고 프로젝트 지식과 검증 항목 중 어디에 둘지 구분한다.

AI PoC 운영 전환의 여섯 게이트와 마찬가지로 파일럿 리뷰는 Go, 조건부 Go, 중단 중 하나로 끝낸다. 조건부 Go에는 허용할 업무 유형과 저장소, 승인자, 만료일을 적는다. “조금 더 써 본다”는 결정은 검증 계획이 아니다.

측정표는 속도·품질·통제·경제성을 함께 본다

AI-DLC의 효과를 코드 생성량으로 측정하면 운영 조직의 부담을 놓친다. 승인과 재작업에 사람이 쓴 시간, 잘못된 영향도 분석을 복구한 비용, 감사 증적을 정리하는 시간까지 같은 작업 단위로 묶어야 한다.

목표값은 다른 회사의 사례에서 가져오지 않는다. 같은 조직의 기존 처리 기준선과 비교하고 업무 유형별로 나눈다. 파일럿 표본이 작으면 생산성 개선을 확정하기보다 어떤 조건에서 효과가 나타났는지 기록한다. 파일럿에서는 AI 실행시간과 함께 승인 대기, 결정 참여 인원, 회의시간, 운영 결함까지 기록해야 한다.

다음 상황에서는 확대를 멈춘다.

• 빌드와 회귀 테스트를 같은 조건으로 다시 실행할 수 없다.
• AI가 사용한 코드·문서·규칙의 출처를 설명할 수 없다.
• 미확정 코드값이나 존재하지 않는 식별자가 검증 전에 코드로 들어간다.
• 다른 저장소와 데이터 계약의 영향도를 확인할 책임자가 없다.
• 승인이나 감사 기록을 우회한 작업이 운영 변경으로 이어진다.

이 중 앞의 네 항목은 에이전트 설정만 고쳐서 해결되지 않을 수 있다. 코드베이스와 운영 체계 자체의 준비도가 부족하다는 신호다.

AI-DLC보다 현대화가 먼저인 조건

AI-DLC는 문서화되지 않은 레거시를 자동으로 이해하는 장치가 아니다. 코드와 빌드가 재현되고 변경 단위와 소유자가 보이며 테스트와 배포 결과를 증명할 수 있을 때 효과가 커진다. AWS 운영 유지보수 사례가 애플리케이션 현대화와 AI 가독성을 선행조건으로 제시한 이유도 여기에 있다.⁵

현대화의 범위를 전면 재작성으로 잡을 필요는 없다. 애플리케이션 현대화 진단과 전환 지도에서 다루듯 다음 변경이 어디에 영향을 주는지 설명할 수 있도록 의존성을 복원하고 빌드·테스트·관측성과 책임 경계를 갖추는 일부터 시작한다.

AI-DLC를 설치하고 업무를 거기에 맞추는 순서는 거꾸로다. 운영 조직의 실제 변경 흐름과 실패 비용을 확인한다. 그다음 다섯 계약을 작성하고 필요한 단계만 선택해 30일 동안 통제 가능성을 검증한다. 파일럿에서 남은 규칙과 지식, 검증 항목이 다음 시스템에도 재사용될 때 비로소 개인의 프롬프트가 조직의 개발 자산으로 바뀐다.

AI-DLC 도입 전 코드베이스 준비도와 30일 파일럿을 설계하려면 AX 컨설팅을 검토한다. 빌드·테스트·의존성과 운영 책임 경계를 먼저 복원해야 한다면 애플리케이션 현대화를 검토한다.

참고 자료