Youtube: (4) AWS re:Invent 2025 - Introducing AI driven development lifecycle (AI-DLC) (DVT214) - YouTube
AI Driven Development LifeCycle(AI-DLC) 소개
아래는 영상 스크립트의 전체 흐름을 유지하면서, 시간순으로 제목 구조를 넣어 Markdown 형태로 재구성한 설명입니다.
0:00–1:09 세션 시작과 발표자 소개
이 세션은 AI가 소프트웨어 개발을 어떻게 바꾸고 있는지를 AWS의 실제 경험과 고객 사례를 바탕으로 설명하는 자리로 시작됩니다. 발표자는 AWS에서 AI 엔지니어링 프랙티스를 이끄는 Anupam Mishra와, 개발자 혁신 팀을 이끄는 Raja이며, 두 사람은 Amazon 내부 팀과 여러 고객사에서 AI를 활용해 소프트웨어를 개발하며 얻은 학습을 공유하겠다고 소개합니다. 또한 발표 후에는 별도의 Q&A 시간도 예정되어 있다고 안내합니다.
1:10–3:26 청중 파악과 현장의 공통 질문
발표는 먼저 청중의 역할과 AI 활용 경험을 확인하는 것으로 시작됩니다. 개발자, 제품 관리자, DevOps/인프라 담당자, 엔지니어링 매니저, CTO, VP of Engineering 등 매우 다양한 역할이 참석해 있음을 확인하고, 이미 절반 정도는 AI를 개발에 사용 중이지만 만족도는 엇갈린다는 점도 드러납니다.
이어서 발표자들은 지난 1년 동안 전 세계 100개 이상의 기업과 대화하며 발견한 세 가지 공통된 고민을 정리합니다.
개발자들의 혼란
AI가 개발을 바꾼다고는 하지만, 실제로 무엇을 바꿔야 하는지, 어떤 훈련이 필요한지, 어떤 도구를 써야 하는지 혼란스럽다는 점입니다.도구의 홍수
매주 새로운 도구가 나오면서, 어떤 도구가 더 나은지 판단하기 어렵고, 도구를 옮겨 다니는 것 자체가 피로를 만든다는 점입니다.리더들의 고민
조직을 AI 네이티브하게 만들고 싶지만, 그것이 정확히 무엇을 뜻하는지, 그리고 수천 명의 개발자에게 어떻게 확산시켜야 하는지 막막하다는 점입니다.
3:27–5:13 AI 생산성의 역설
발표자들은 먼저 **“AI를 쓰면 정말 생산성이 크게 오르는가?”**라는 질문을 냉정하게 다룹니다. ThoughtWorks의 연구에 따르면 실무에서 체감되는 속도 향상은 대략 10~15% 수준이며, 이는 기대했던 폭발적인 변화와는 다를 수 있습니다.
또 다른 예로, 오픈소스 개발자들을 두 팀으로 나누어 AI 사용 여부를 비교한 실험도 소개됩니다. AI를 사용한 개발자들은 스스로 더 생산적이었다고 느꼈지만, 실제 결과를 분석해 보니 오히려 생산성이 낮게 나온 사례도 있었다고 설명합니다. 이를 통해 발표는 “체감 생산성”과 “실제 생산성”은 다를 수 있으며, AI의 효과를 측정하는 방식 자체가 중요하다는 문제의식을 제시합니다.
5:14–8:10 현재 많이 보이는 두 가지 안티패턴
1) AI Managed 접근: 문제를 통째로 던지는 방식
첫 번째 안티패턴은 복잡하고 모호한 문제를 AI에게 그대로 던지고, AI가 처음부터 끝까지 자율적으로 해결해주길 기대하는 방식입니다. 발표자들은 이것이 작은 프로토타입에는 통할 수 있지만, 실제 운영 환경의 애플리케이션처럼 수많은 설계 판단과 협업이 필요한 상황에서는 잘 작동하지 않는다고 말합니다. 무엇보다 AI가 한 번에 너무 많은 코드를 생성하면, 개발자는 그 코드에 자신 있게 이름을 올리기 어렵고, 결국 배포 속도도 기대만큼 나오지 않습니다.
2) AI Assisted 접근: 사람은 그대로, AI는 부분적으로만 쓰는 방식
두 번째 안티패턴은 그 반대로, 숙련된 개발자가 모든 사고와 분해, 설계를 직접 하고 AI는 작은 함수 구현이나 보안 리뷰 같은 좁은 작업에만 끼워 넣는 방식입니다. 이 방법은 안정적이기는 하지만, 정작 중요한 지적 부담은 여전히 사람이 모두 지고 있기 때문에 생산성 향상이 제한적입니다. 게다가 조직의 프로세스도 여전히 AI 이전 시대의 방식—문서 전달, 대기, 회의 중심—으로 유지되기 때문에, AI로 절약한 시간이 다른 곳에서 다시 소모됩니다.
청중에게 손을 들어 확인한 결과, 이러한 현상은 실제 현장에서도 널리 관찰되고 있음을 확인합니다.
8:11–10:30 실험을 통해 AI-DLC를 만들게 된 배경
발표자들은 여기서 문제의식을 한 단계 더 밀어붙입니다. 단순히 10~15% 개선이 아니라, 2배, 3배, 5배, 10배 수준의 도약은 불가능한가를 질문한 것입니다. 이를 위해 내부적으로 다양한 실험을 진행했고, 그 과정에서 신규 서비스(그린필드)와 기존 대규모 코드베이스(브라운필드) 모두를 대상으로 여러 도구와 접근법을 테스트했습니다.
이후에는 고객과 함께 실제 문제를 풀어보는 방식으로 실험을 확장했고, 이미 중요하다고 판단된 고객의 실제 업무를 AI를 활용해 얼마나 짧은 주기로 해결할 수 있는지를 검증했습니다. 이러한 100회 이상의 실험을 바탕으로 도출한 것이 바로 **AI-DLC(AI-Driven Development Lifecycle)**입니다.
발표자들은 AI-DLC를 단순한 도구 모음이 아니라, 생산 등급의 시스템을 만들기 위해 필요한 역할, 의식(ritual), 도구가 함께 작동하는 개발 방식으로 정의합니다.
10:31–13:56 AI-DLC의 핵심 원칙
AI는 먼저 계획하게 하고, 사람은 그 계획을 검증해야 한다
AI는 기본적으로 매우 “도와주려는” 성향이 있기 때문에, 요구보다 더 많은 것을 만들려는 경향이 있습니다. 예를 들어 쇼핑 사이트를 만들어 달라고 하면, 필요하지 않은 인증, 로그 관리, 기타 부가 기능까지 과잉 생성할 수 있습니다. 그래서 AI-DLC에서는 AI에게 바로 구현을 시키기보다, 먼저 “무엇을 할 것인지 계획(plan)” 을 만들게 하고, 사람이 그것을 검토하고 수정합니다. 그런 다음 AI가 실행하고, 마지막으로 사람이 다시 결과를 검증합니다.
즉, AI의 사고 방향과 인간의 사고 방향을 먼저 정렬한 뒤 실행한다는 것이 핵심입니다.
SDLC에서 대부분의 시간은 코딩에만 쓰이지 않는다
발표자들은 실제 소프트웨어 개발에서 시간이 가장 많이 드는 부분은 코딩 자체가 아니라, 대기, 의존성, 회의, 승인, 재작업이라고 지적합니다. 보안팀은 위협 모델을 기다리고, 운영팀은 배포를 기다리며, QA는 새 릴리스를 기다리고, 그 사이에는 정렬 회의와 에스컬레이션 회의가 반복됩니다.
따라서 AI로 코딩만 빨라져서는 충분하지 않습니다. 인간 사이의 커뮤니케이션 구조까지 함께 재설계해야만 진짜 생산성 도약이 가능하다는 점을 강조합니다.
13:57–17:17 AI 시대에 맞는 새로운 협업 방식
스프린트는 몇 주가 아니라 몇 시간 단위가 되어야 한다
기존 애자일에서는 2주, 4주짜리 스프린트가 자연스럽게 작업의 순차 진행을 만들었습니다. 하지만 발표자들은 AI 시대에는 이 단위가 너무 길다고 말합니다. AI를 전제로 하면, 의사결정과 정렬, 작업 실행이 몇 시간 또는 하루 이내에 일어나야 한다는 것입니다.
Mob Elaboration: 모두가 한 방에 모여 요구를 정교화하는 방식
이를 위한 대표적인 의식이 Mob Elaboration입니다. 제품 관리자, 개발자, QA, 운영 담당자 등 관련된 사람들이 같은 공간(물리적이든 가상이든)에 모여, 반나절 정도 AI를 활용해 요구를 정교화합니다. AI는 의도를 바탕으로 스토리를 만들고, 참석자들은 이를 즉시 검토하고 보완합니다. 그 결과, 보통 수주 또는 수개월이 걸리던 요구 분석과 작업 분해가 몇 시간 안에 끝나는 경험을 만들 수 있다고 설명합니다.
Mob Construction: 구현도 분리하지 않고 함께 진행한다
요구 정리가 끝나면 구현도 분리된 팀이 각자 하는 방식이 아니라, 작고 교차기능적인 팀이 함께 빠르게 움직이는 방식으로 진행합니다. 발표자들은 AI 시대에는 더 이상 큰 “두 판 피자 팀”이 아니라, 한 판 피자 정도의 작은 팀이 더 적합하다고 말합니다. 이 팀들은 서로 API 명세를 주고받고 동시에 의사결정을 하며, AI를 활용해 빠르게 구현을 이어갑니다.
17:18–20:20 AI-DLC의 전체 구조: Inception, Construction, Operation
AI-DLC는 기존 애자일 위에 AI를 덧붙이는 방식이 아니라, 처음부터 AI를 전제로 다시 설계한 개발 방법론입니다. 전체 흐름은 크게 다음 세 단계로 구성됩니다.
- Inception
- Construction
- Operation
보통 9개의 세부 단계로 표현되지만, 이것은 고정된 체크리스트가 아니라 상황에 따라 적응하는 워크플로입니다. 예를 들어 단순한 버그 수정은 모든 단계를 거칠 필요가 없지만, 브라운필드에서 중요한 기능을 추가하는 작업이나 그린필드 프로젝트는 대부분의 단계를 거치게 됩니다.
각 단계는 공통적으로 다음 순환을 따릅니다.
- AI가 해당 단계의 계획을 제안한다.
- 사람이 이를 검증하고 수정한다.
- AI가 산출물을 만든다.
- 사람이 다시 검증한다.
이 과정을 거치면서 단계가 내려갈수록 문맥은 더 풍부해지고, AI의 출력도 더 정확해집니다.
20:21–22:23 고객 사례로 보는 적용 결과
Wipro 사례
Wipro와 함께 진행한 한 엔터프라이즈 헬스케어 프로젝트에서는, 서로 다른 3개 국가에 있는 분산 팀이 모여 5일 동안 하루 4시간씩, 총 20시간 작업했고, 원래 몇 달 걸릴 예정이던 일을 마무리할 수 있었다고 설명합니다. 중요한 점은 단지 더 빨랐다는 것이 아니라, 품질과 이해도, 팀의 몰입감까지 더 좋아졌다는 피드백입니다.
Dhan 사례
주식 거래 분야의 핀테크 기업 Dhan은 새로운 애플리케이션을 출시하는 데 원래 2개월 정도를 예상했지만, AI-DLC 방식으로 48시간 안에 구현했고, 그 다음 주에 실제로 릴리스할 수 있었다고 공유합니다.
22:24–41:59 실무 적용에서 얻은 핵심 학습
이 구간에서는 발표자들이 현장에서 반복적으로 확인한 실천 원칙들을 정리합니다.
22:24–23:22 바이브 코딩의 한계와 코드 소유권
발표자들은 AI에게 계속 수정 지시를 내리며 언젠가 동작하게 만드는 식의 바이브 코딩(vibe coding) 이 생산 환경의 개발 방식으로는 적합하지 않다고 말합니다. 결국 코드에 서명하는 것은 개발자 자신이며, 따라서 코드 한 줄 한 줄을 이해하고 디버깅할 수 있어야 한다는 점을 강조합니다.
23:23–24:27 작업은 작고 명확하게 쪼개야 한다
AI에게 “이커머스 플랫폼을 만들어줘”처럼 넓고 모호한 지시를 주기보다, 작고 비모호한 단위로 분해한 작업을 주는 것이 훨씬 잘 작동합니다. 예를 들어 “이 코드 조각에 SQL 인젝션 취약점이 있는지 검토하라”는 식의 요청은 범위가 명확하므로 결과 품질이 높아집니다.
24:28–25:48 컨텍스트 윈도우는 무조건 크다고 좋은 것이 아니다
많은 사람은 컨텍스트 윈도우가 커질수록 더 많은 것을 던질 수 있으니 좋다고 생각하지만, 발표자들의 경험은 다릅니다. 너무 많은 코드와 과거 대화가 쌓이면 오히려 AI가 혼란스러워질 수 있습니다. 따라서 지금 작업과 관련 없는 정보는 적극적으로 잘라내고, 필요할 때는 컨텍스트를 초기화하거나 압축해야 한다고 설명합니다.
25:49–26:53 기존 코드 스타일을 따라 하게 만드는 것이 효과적이다
브라운필드에서는 AI에게 장황하게 설명하는 것보다, 이미 존재하는 서비스나 코드 조각을 참조로 주고 그것을 따라 비슷한 구조를 만들게 하는 방식이 훨씬 정확합니다. 인증, 로깅, 에러 처리 같은 패턴을 자연스럽게 재사용하게 할 수 있기 때문입니다.
26:54–28:04 속도가 빨라질수록 테스트 기준도 높아져야 한다
AI로 릴리스 속도가 빨라지면, 같은 품질 수준을 유지하더라도 버그가 더 자주 발생할 수 있습니다. 따라서 단위 테스트와 통합 테스트를 훨씬 더 촘촘하게 준비해야 하며, 이는 AI가 구현 중 스스로 방향을 교정하는 데에도 큰 도움이 됩니다.
28:05–29:17 토큰 대비 의미 밀도를 높여야 한다
발표자들은 “semantics per token ratio”, 즉 토큰 대비 의미 밀도가 중요하다고 말합니다. 예를 들어 “builder pattern으로 리팩터링하라”는 짧지만 의미가 풍부한 지시는 AI에게 효과적입니다. 반대로 긴 설명으로 같은 뜻을 우회해서 전달하면 토큰은 많아지지만 의미 밀도는 낮아집니다. 결국 AI와 상호작용할 때는 짧더라도 의미가 압축된 표현이 중요합니다.
29:18–30:22 모델의 학습 현실을 이해해야 한다
AI는 모든 언어와 패턴 조합에 똑같이 강한 것이 아닙니다. 발표에서는 Go 언어에서 Domain-Driven Design을 적용해 달라고 했을 때 기대와 다르게 동작한 사례를 소개합니다. 즉, AI가 어떤 자료로 학습되었는지를 이해하고, 언어와 설계 패턴의 실제 궁합을 고려해야 한다는 뜻입니다.
30:23–31:49 몰입 시간을 보호해야 한다
예전에는 개발 중에 검색과 복사/붙여넣기를 위해 IDE 밖으로 자주 나가야 했지만, AI 덕분에 이제는 한 곳에서 더 오래 몰입할 수 있게 되었습니다. 하지만 중간에 회의로 끊기면 사람도 흐름을 잃고, AI와의 작업 맥락도 단절됩니다. 그래서 발표자들은 회의 없는 시간대 확보, 예를 들어 “오후에는 회의 금지” 같은 실험이 실제로 매우 효과적이라고 말합니다.
31:50–34:17 개발 환경과 CI/CD가 받쳐주지 않으면 병목이 생긴다
AI는 코딩과 단위 테스트를 빠르게 진행할 수 있지만, 개발 환경, 통합 환경, 스테이징, CI/CD 파이프라인이 미성숙하면 그 속도를 전혀 따라가지 못합니다. 그러면 개발은 빠르게 앞서가는데 배포와 피드백이 밀려 버전 차이가 커지고, 결국 전체 흐름이 무너집니다. 따라서 절약한 시간을 QA, 테스트 자동화, CI/CD 정비에 재투자해야 한다고 강조합니다.
34:18–36:00 브라운필드도 충분히 가능하지만, 의미 기반 컨텍스트가 필요하다
많은 고객이 “AI는 새 프로젝트에는 강하지만 기존 레거시 코드에는 약하지 않느냐”고 묻습니다. 발표자들의 답은 “그렇지 않다” 입니다. 다만 거대한 코드베이스를 그냥 통째로 넣는 방식이 아니라, 호출 그래프, 클래스 구조, 함수 역할, 의존성 같은 의미 기반 요약 정보를 만들어 AI가 어디를 바꿔야 하는지 판단하게 해야 합니다.
36:01–37:08 MCP 도구가 오히려 컨텍스트를 잡아먹을 수 있다
MCP 서버와 도구가 많아질수록 좋아 보이지만, 현재 구조에서는 각 도구의 설명 정보도 컨텍스트에 포함되기 때문에 실제 작업에 쓸 수 있는 토큰을 줄여버릴 수 있습니다. 따라서 지금 작업에 필요 없는 MCP는 비활성화하는 관리가 필요하다고 설명합니다.
37:09–38:09 측정은 엔드투엔드로 해야 한다
AI의 효과를 평가할 때 단순한 코드 라인 수나 부분적인 지표보다, “무언가를 만들기로 결정한 시점부터 실제로 출시되는 시점까지 걸린 시간” 을 기준으로 보는 것이 더 의미 있다고 말합니다. 여기에 AI를 적용한 경우와 적용하지 않은 경우를 비교하는 A/B 방식의 기준선이 유용합니다.
38:10–39:05 기술 부채가 심하면 패치보다 재작성(rewrite)이 빠를 수 있다
발표자들은 AI 시대에는 과거보다 재작성 비용이 훨씬 낮아졌기 때문에, 단순히 버전 업그레이드나 임시 패치를 반복하는 대신, 경우에 따라서는 몇 주 더 들여서 깔끔하게 다시 만드는 편이 장기적으로 더 유리할 수 있다고 제안합니다.
39:06–40:11 AI는 시니어 엔지니어가 아니라 인턴에 가깝다
AI는 매우 자신감 있게 말하지만, 그 내용이 항상 맞는 것은 아닙니다. 그래서 발표자들은 AI를 아이디어가 많은 인턴처럼 다루라고 조언합니다. 즉, 질문하고 검증하고 수정하게 해야 하며, 개발자가 주도권을 놓아서는 안 됩니다.
40:12–41:59 정답을 기다리지 말고 직접 실험해야 한다
아직 “어느 회사가 이미 완전히 검증했으니 그 방식을 따라가면 된다”는 수준의 황금 표준은 존재하지 않습니다. 따라서 조직은 안전한 실험을 설계하고, 반복하면서 자신만의 방식으로 학습해야 합니다. 책이나 발표만으로는 부족하고, 실제로 AI와 함께 작업하면서만 “어느 정도가 작은 작업인지”, “어떤 문맥이 잘 먹히는지” 같은 감각을 익힐 수 있다고 설명합니다.
42:00–44:48 무엇을 성과로 볼 것인가: 속도, 품질, 예측 가능성
발표자들은 AI-DLC의 효과를 단지 빠른 코딩이 아니라 속도(velocity), 품질(quality), 예측 가능성(predictability) 으로 봐야 한다고 말합니다. 특히 예측 가능성은 “우리가 약속한 것을 실제로 얼마나 전달하는가”의 관점에서 중요합니다. 발표에서는 AI 이전에는 10개를 약속해 2개만 전달하던 수준이었다면, AI 시대에는 80% 이상의 예측 가능성도 기대할 수 있다고 설명합니다.
조직에서 실험할 때는 복잡하게 접근할 필요 없이, 백로그에 있는 실제 작업 하나를 골라 기존 방식의 추정치와 AI-DLC 적용 결과를 비교하면 된다고 제안합니다. 이를 여러 팀에서 반복하면 조직 차원의 평균 효과를 볼 수 있습니다.
44:49–53:36 데모: FastAPI 이슈를 AI-DLC로 해결하는 과정
마지막 실전 예시는 GitHub의 FastAPI 오픈소스 이슈를 대상으로 진행됩니다. 이 이슈는 FastAPI가 특정 HTTP QUERY 메서드를 지원하도록 개선해 달라는 요청입니다.
이 데모에서는 Amazon Q Developer와 Kiro에 적용할 수 있는 AI-DLC용 steering files(규칙 파일) 을 사용합니다. 도구는 먼저 현재 저장소가 기존 코드베이스임을 감지하고, 자동으로 다음 작업을 수행합니다.
브라운필드 역공학
애플리케이션 구조, 데이터 흐름, 기존 API, 기술 스택, 핵심 컴포넌트를 분석해 의미 기반 컨텍스트를 만듭니다.요구사항 명확화
AI가 필요한 질문을 던지고, 사용자는 관련 표준 문서 URL을 제공해 구현 기준을 분명히 합니다.적응형 워크플로 계획
이 작업이 단순 결함 수정 또는 기술적 변경에 가깝다고 판단해, 모든 단계를 수행하지 않고 필요한 단계만 선택합니다.파일 단위의 변경 계획 제시
어떤 파일을 어떻게 바꾸겠다는 계획을 먼저 보여주고, 사람이 확인한 뒤 진행합니다.기존 구조를 따르는 코드 생성과 테스트
FastAPI가 사용하는 Starlette 구조를 그대로 따르며 코드를 생성하고 테스트까지 수행합니다.
발표자는 이 과정을 통해 몇 시간 만에 실제 Pull Request 수준의 결과물을 만들 수 있었고, 무엇보다 사람 입장에서 매 단계의 맥락을 이해하고 검증했기 때문에 코드에 대한 신뢰와 소유감이 높았다고 설명합니다.
53:37–56:00 더 배울 수 있는 자료와 오픈소스 리소스
발표 마지막에는 세 가지 실습 자원이 소개됩니다.
자기주도 학습 영상 자료
오늘 세션보다 더 깊이 있게 AI-DLC를 익힐 수 있는 영상입니다.워크숍
Kiro와 함께 실제 지침을 따라가며 업계별 사용 사례를 연습할 수 있는 실습형 자료입니다.오픈소스 AI-DLC 워크플로
발표에서 사용한 규칙과 흐름이 공개되어 있어, 누구나 직접 써 보고 개선 의견을 낼 수 있습니다.
56:01–58:37 기업 도입 방식과 커뮤니티
발표자들은 실제 기업 도입이 보통 다음 순서로 진행된다고 설명합니다.
- 리더의 문제의식과 후원
- 작은 성공 사례(Signature Wins) 확보
- 여러 팀으로 확산
- 조직에 맞춘 커스터마이징
실제로 어떤 고객은 Scrum Master를 AI-DLC Master 역할로 전환하기도 했고, 어떤 팀은 AI-DLC 전파를 전담하는 조직을 만들기도 했습니다. 또 AWS는 고객과 함께 실제 문제를 풀어보는 Unicorn Gym 방식도 운영하고 있다고 소개합니다.
아울러, AI 네이티브 개발의 미래—팀 크기, 역할 변화, 새로운 선언문—를 함께 논의하기 위한 AI-Native Builders Community도 운영 중이며, 관심 있는 리더와 실무자들이 참여해 경험을 교류해 달라고 요청합니다.
58:38–59:13 마무리
발표는 AI가 소프트웨어 개발 방식을 근본적으로 바꾸고 있으며, 그 변화는 도구만의 문제가 아니라 사람과 프로세스, 협업 방식을 함께 다시 설계하는 문제라는 메시지로 마무리됩니다. 발표자들은 각자의 조직에서 직접 실험하고, 다시 그 학습을 공유함으로써 더 나은 개발의 미래를 함께 만들어 가자고 제안하며 세션을 끝맺습니다.
한 줄 요약
AI-DLC는 “AI에게 코드를 맡기는 방법”이 아니라, 인간과 AI가 계획-검증-실행-검증의 루프 안에서 함께 일하도록 개발 수명주기 전체를 다시 설계한 방법론입니다.
원하시면 제가 이 내용을 이어서
- 슬라이드용 요약본,
- 회의록 스타일,
- 블로그용 정리본
형태로도 다시 바꿔드릴 수 있습니다.