수개월의 프로젝트를 수일로 줄인 AWS ProServe의 AI-DLC
새 프로젝트를 시작할 때면 수주간 이어지는 요구사항 정의와 끝없는 문서 작업에 지치기 마련이다. 합의된 문서를 만들고 다음 단계로 넘어가는 순차적 과정에서 정작 개발에 들어가는 시간보다 준비 시간이 더 길어지는 불편함은 업계의 상식에 가깝다. AWS Professional Services(AWS ProServe, AWS 전문 서비스 팀)는 이러한 기존 컨설팅의 리듬을 깨고 수행 기간을 수개월에서 수일 단위로 단축했다. 이는 기존 프로세스 위에 AI 도구를 얹은 것이 아니라, 딜리버리 프로세스 자체를 내부부터 완전히 재설계하여 AI 네이티브 환경을 구축했기에 가능했다.
APEX(Agentic AI ProServe Experiences, 에이전틱 AI 프로서브 경험 팀)가 이번 프로세스 재설계를 주도하며 전담 조직으로 움직였다. 이들은 AI-DLC(AI-Driven Development Lifecycle, AI 기반 개발 생명주기)라는 새로운 체계를 구축하여 적용했다. AI-DLC는 AWS 현장 팀들이 수백 차례의 고객 워크숍을 통해 직접 수행하며 정립하고 다듬은 실무 프로세스다. 단순히 코딩을 돕는 비서를 쓰는 수준을 넘어, 문서화나 조정, 상태 보고 같은 비코딩 오버헤드를 제거하고 AI를 개발 생명주기 전체의 기반으로 설정해 딜리버리 속도를 높였다.
실제 작동을 위해 도입한 ProServe Delivery Agent는 요구사항 정의부터 아키텍처 검증, 구현, 보안 리뷰, 테스트, 배포에 이르는 전 과정을 수행하는 멀티 에이전트 시스템이다. 시스템 내부에서는 슈퍼바이저 에이전트가 전체 흐름을 관리하며, 각 단계에 특화된 전문 서브 에이전트들을 적재적소에 배치하고 조율하는 오케스트레이션 방식으로 작동한다. 사람이 모든 티켓을 하나씩 순차적으로 처리하던 기존 방식에서 벗어나, AI 에이전트들이 생명주기 각 단계에서 유기적으로 협업하며 결과물을 만들어내는 구조로 전환했다.
AWS ProServe는 요구사항을 산문 형태의 문서가 아닌 구조화된 명세서로 정의하고, 이를 통해 여러 에이전트가 작업을 병렬로 수행하게 만드는 체계를 적용했다. 이러한 워크플로의 재설계가 수개월의 시간을 수일로 줄이는 실질적인 동력이 됐다. 실무자는 단순히 최신 도구를 도입하는 것에 그치지 않고, 명세서 중심 개발과 에이전트 병렬 처리라는 워크플로 전환이 현재 조직의 개발 환경에서 실효성이 있는지를 판단 기준으로 삼아야 한다.
문서 중심에서 명세서 중심으로: AI 네이티브 워크플로의 작동 방식
컨설팅 프로젝트에서 요구사항을 정의하고 문서를 만드는 데만 수개월을 쓰는 것은 흔한 일이다. AWS ProServe는 이 기간을 수일 단위로 단축했는데, 이는 단순히 AI 도구를 추가한 것이 아니라 워크플로 자체를 재설계했기 때문이다. 기존에는 긴 문서 기반의 탐색을 거쳐 워크숍에서 아키텍처를 결정하고, 스프린트 구현 후 단계별로 테스트와 보안 리뷰를 진행하는 순차적 구조였다. 이를 사람이 읽는 산문 형태가 아니라 AI와 사람이 동시에 읽을 수 있는 구조화된 명세서(Structured Specs) 중심으로 바꾸어 단일 진실 공급원(Source of Truth)으로 활용했다.
에이전트가 정확하게 움직이게 만드는 핵심은 스티어링 파일(Steering files)에 있다. 이는 아키텍처 표준과 과거 프로젝트에서 얻은 교훈을 코드화하여 에이전트가 상시 참조하도록 만든 지침서다. 구현 방식 역시 작업자가 티켓을 하나씩 순차적으로 처리하던 기존 방식에서 벗어났다. 컨설턴트가 명확하게 정의된 작업 단위를 여러 에이전트에게 동시에 할당하여 병렬로 수행하는 구조로 전환했다. 사람이 모든 과정을 관리하는 대신, 잘 설계된 작업 명세서를 통해 AI가 동시에 여러 결과물을 만들어내게 한 것이다.
품질 검증 단계인 테스트와 보안 리뷰는 빌드 루프 내부로 이동시키는 테스트 전진 배치(Shift-left testing) 방식을 적용했다. 에이전트가 결과물을 내놓기 전 로컬 환경에서 자체적으로 검증하고 수정하는 과정을 거치게 하여, 사람이 최종 검토하는 시점의 오류를 줄였다. 이 과정에서 Kiro, 아마존 베드락 에이전트코어(Amazon Bedrock AgentCore, 에이전트 구축 프레임워크), Strands 같은 도구를 사용했다. 하지만 생산성 향상의 본질은 특정 도구의 도입이 아니라, 도구에 맞춰 워크플로를 재설계한 점에 있다.
실무자가 이 모델을 적용할 때 고려할 판단 기준은 도구의 교체가 아니라 명세서 중심 개발의 실효성이다. 단순히 AI에게 자연어로 지시하는 방식으로는 기존의 순차적 병목을 해결할 수 없다. 명세서가 단순한 기록물이 아니라 에이전트가 준수해야 할 계약서 역할을 수행하고, 이를 통해 작업을 병렬로 쪼갤 수 있는 구조인지 확인해야 한다. 에이전트가 스스로 수정할 수 있는 검증 루프를 얼마나 앞단으로 배치하느냐가 전체 리드 타임을 결정한다.
코드 전달 속도 60% 향상과 '성과 기반' 과금 모델로의 전환
프로젝트 시작 전 몇 주 동안 요구사항을 정리하고 백로그를 만드는 작업은 실무자에게 가장 고통스러운 구간이다. LexisNexis는 Amazon Application Recovery Controller의 Region Switch 기능을 도입하며 Kiro와 AWS ProServe Delivery Agent를 함께 활용했다. 그 결과 수주가 소요되던 백로그 생성을 수시간으로 단축했고 코드 전달 속도를 60% 가속화했다. 모든 산출물에서 일관된 품질을 확보하며 리전 전환 테스트를 예정된 일정에 맞춰 성공적으로 마쳤다.
작업 속도가 비약적으로 빨라지자 비용을 청구하는 상업적 모델부터 바뀌었다. 기존 컨설팅은 투입된 인력의 시간과 자재를 기준으로 비용을 산정하는 Time and Materials 방식을 썼다. 이는 결과보다 투입 기간이 길어질수록 수익이 나는 구조라 효율 개선의 동기가 부족했다. AWS ProServe는 이를 실제 프로덕션 배포 결과에 기반한 고정 가격(Fixed-price) 계약으로 전환했다. 투입 시간이라는 비용 중심 사고에서 비즈니스 성과라는 가치 중심으로 기준을 옮긴 것이다.
이런 성과를 내는 운영 원칙은 단순하다. 사람은 무엇을 만들지 결정하는 의도(Intent)를 제공하고 AI가 이를 바탕으로 실제 결과물을 생성(Create)하며 다시 사람이 최종 검증(Verify)하는 루프를 돌린다. AI를 단순한 비서로 쓰는 것이 아니라 생성의 주체로 세우고 사람은 우선순위 결정과 품질 승인이라는 고부가가치 판단에만 집중한다. 이 과정에서 사람이 개입하는 게이트를 최소화하고 꼭 필요한 지점에만 배치해 흐름을 끊지 않는다.
실무에 적용하려면 도구 교체보다 워크플로 재설계 순서를 지켜야 한다. 우선 에이전트가 참조할 아키텍처 표준과 과거 사례를 코드화한 컨텍스트 구축에 투자한다. 그다음 요구사항을 산문이 아닌 구조화된 명세서 중심으로 작성해 에이전트가 읽을 수 있는 계약서로 만든다. 이렇게 정의된 작업을 여러 에이전트에게 병렬로 할당해 실행하고 테스트와 보안 리뷰를 빌드 루프 내부로 옮기는 테스트 전진 배치(Shift-left testing)를 적용한다.
결국 핵심은 도구의 교체가 아니라, 모호한 요구사항을 에이전트가 처리 가능한 구조화된 명세로 변환하는 설계 능력에 있다. 프로젝트의 성패는 수개월의 문서 작업이 아니라, 검증 루프를 얼마나 앞단으로 배치해 병렬 처리의 효율을 극대화하느냐에 달려있다.
지금 당장 조직의 개발 워크플로에서 수동으로 반복되는 문서화 단계를 찾아내고, 이를 구조화된 데이터로 정의할 수 있는지부터 검토해야 한다. AI가 수행할 수 있는 작업의 단위를 명확히 분절하는 것만이 실질적인 리드 타임 단축을 이끌어내는 유일한 경로다.
