Amazon Web Services 한국 블로그

프런티어 개발팀은 어떻게 AI 네이티브 개발을 재창조하는가?

이 글은 AWS AI Blog 채널에 게시된 How frontier teams are reinventing AI-native development의 한국어 번역본입니다.

프런티어 개발팀은 단순히 AI를 사용해 더 빠르게 코딩하는 것이 아닙니다. 그들은 소프트웨어가 어떻게 만들어지는지 재설계하고 있습니다. 그 결과 생산성이 4.5배, 경우에 따라 10배 이상으로 향상됩니다.

소프트웨어 엔지니어 6명과 76일만에 기존에 12개월에서 18개월 동안 30명의 개발자가 필요한 프로젝트를 완성했습니다. 이것은 가정이 아닙니다. 실제로 Amazon Bedrock팀이 AI를 단순한 코딩 지름길로 여기지 않고 AI를 그들의 작업 방식의 기초로 삼기 시작했을 때 벌어진 일입니다. 이들 프런티어 개발팀은 5개월 만에 지난 10년간 합친것 보다 더 많은 코드를 가진 제품을 출시했습니다.

현재 AI를 네이티브로 쓰는 팀들과 다른 팀들 사이의 격차는 빠르게 벌어지고 있습니다. AI 코딩 에이전트는 소프트웨어가 작성되는 속도를 근본적으로 바뀌었지만, 고객에게 도달하는 속도는 아직 바꾸지 못했습니다. 커밋이 급증하고 있으며, CI/CD 파이프라인도 그 어느 때보다 분주합니다. 하지만, 프로덕션 단계에 투입된 제품들은 같은 속도를 유지하지 못하고 있습니다. 병목 현상은 에이전트가 산출물을 만들어 내는 능력에 있는게 아닙니다. 오히려, 에이전트가 올바른 결정을 내리기 위해 필요한 지식에 접근하고, 개발팀이 그 현실에 맞춰 작업을 재구성하려는 의지 부족입니다.

이 문제를 해결한 팀들을 저는 “프런티어 개발팀”이라고 부릅니다. 그들은 똑똑한 사람들이 있는 개발팀이 아닙니다. 이들은 다양한 산업과 기업 규모에 걸쳐 존재하며, AI 도입을 단순한 도구 출시가 아닌 공학적 투자로 취급하는 공통된 모범 사례를 공유합니다. 따라서, (어떤 규모의 조직의) 어떤 개발 팀도 프런티어 개발팀이 될 수 있습니다.

어떻게 그게 가능한지 저희가 배운 것을 공유해드리겠습니다.

Amazon의 AI 네이티브 개발을 위한 세 가지 경로

AI 네이티브 소프트웨어 개발은 AI를 소프트웨어 구축의 기초로 삼으며, 인간 전문가가 점점 더 유능한 에이전트들을 지휘합니다. 팀이 에이전트를 어떻게 지휘하느냐에 따라 결과가 결정됩니다. Amazon에서 AI의 주요 동인은 개발자들이 문서화, 조정, 운영과 같은 비코딩 작업에 소요되는 시간을 줄이고, 기술 부채를 해소하며, 수천 개의 소규모 ‘투 피자’ 개발자 팀 간의 코딩 불일치를 최소화하는 것이었습니다.

우리는 수백 개의 엔지니어링 팀을 대상으로 실험을 진행했으며, 최소 세 가지 경로를 확인했습니다: 전문가들이 도전을 해결하는 길잡이 이니셔티브, 명확한 계획에 따라 실행하는 구조화된 스프린트, 그리고 기존 접근법과 AI 적응 워크플로우를 반으로 나누는 현장 실험입니다. 각각의 경로는 구조가 다르지만 같은 통찰로 수렴합니다.

  • 패스파인더 방식: 이는 제한된 통제된 실험이었습니다. 여섯 명의 수석 엔지니어가 단 하나의 임무를 받았습니다. 원래 약 30명의 개발자가 12개월에서 18개월 동안 일하는 것으로 추정되는 Amazon Bedrock 추론 엔진을 재구축하는 것이었습니다. 개발 인원을 늘리기보다는 소규모 팀은 첫 몇 주를 AI를 중심으로 워크플로우를 재설계하고, 개별 작업에서 목표 지향적 결과로 전환했습니다. 여러 AI 에이전트를 병렬로 운영하고, 비근무 시간에도 AI가 독립적으로 작동할 수 있는 시스템을 구축하는 데 집중했습니다. 그 결과, 이 프로젝트는 76일 만에 완료되었습니다. 개별 개발자의 생산성은 정규화된 커밋 속도(저장소 복잡도와 팀 규모를 반영한 주당 커밋 수)로 측정해보니, 약 20배 가량 증가했습니다. 커밋 수는 주당 2회에서 40회로 늘었습니다. 개발팀은 지난 10년간 프로젝트에서 생산된 라인 수보다 5개월 만에 더 많은 고품질 코드를 출시했습니다.
  • 구조화된 스프린트: Amazon Prime Video 파이낸셜 시스템즈 팀은 패스파인더 모델에서 영감을 받아 10일간의 실험을 진행했습니다. 개발자 6명이 한방에서 근무, 컨텍스트 전환 없음 , 온콜 근무 없음, 다른 프로젝트 없음, 제한된 회의가 제공되는 환경에서 일했습니다. 선임 엔지니어가 3주간 구체적인 요구사항과 작업으로 나누는 작업을 진행했습니다. 개발팀은 복잡한 기능 작업에는 스펙 기반 (Spec-driven) 개발, 요구사항이 명확한 작업에는 직접 에이전트 지원 개발을 사용했습니다. 10일 동안 (예상 커밋 96회에 비해) 556건의 커밋을 생산했고, 90주 프로젝트 예상치를 24주로 단축했습니다. 이는 거의 6배의 처리량과 4배의 가속을 의미합니다. 이러한 결과는 AI 기반 향상의 세 가지 요인이 합쳐진 데 기인한다고 보았습니다: 1) 낮은 판단을 요하는 작업 가속화(1.5배), 2) 높은 판단을 요하는 작업에 대한 더 높은 집중(컨텍스트 전환 없이 1.5배), 그리고 에이전트가 캡처한 도메인 전문성에 대한 즉각적인 접근(1.5배). 단 한 가지 요소를 제거하더라도, 그 이점은 사라집니다. 개발팀은 이제 도메인 지식을 캡슐화하는 상세한 제품 사양과 집중 시간을 확보하는 자율 에이전트를 통해 이 세 가지 요소를 정상 운영에서 최적화할 수 있습니다.
  • 대규모 현장 실험: 이러한 결과를 토대로 테스트를 진행한 50개 이상의 개발팀 중, 새로운 도구와 규칙을 모두 도입한 25개 팀이 단순히 기존 워크플로우에 AI를 추가한 팀보다 더 좋은 성과를 냈습니다. Amazon Store는 일반적인 개발팀이 그동안 밀린 작업을 처리하는 구조화된 파일럿을 진행했으며, 특별한 조건이나 엄선된 엔지니어 없이 Kiro와 같은 맞춤형 AI 도구를 사용했습니다. 중간 생산성 향상은 4.5배였으며, 일부 팀은 정규화된 배포 속도(스프린트당 배포 기능, 과거 기준선과 정규화됨)에서 10배 이상 개선되었습니다. 특히, Perfect Order Experience 팀은 2주 동안 걸리던 작업을 한나절만에 배포하고, WW Grocery 팀은 디자인 문서 작성 시간을 5일에서 몇 시간으로 줄였습니다.

다른 방식으로 실험을 했지만 , 같은 교훈을 얻었는데, 바로 도구가 아니라 워크플로우가 중요하다는 점입니다.

프런티어 팀이 되기 위한 다섯 단계

세 가지 경로 모두에서 가장 높은 성과를 내는 팀은 공통된 논리를 가진 다섯 가지 모범 사례를 얻어냈습니다. 바로, AI 에이전트가 작업 맥락에 참여하는 장벽을 줄이고, 독립적으로 할 수 있는 작업량을 늘리라는 것입니다.

이 점에서 프런티어 개발팀들은 이전 방식과 다르게 일합니다. 이전에는 개별 코드 생성 속도에 최적화된 접근법인데요. 프런티어 팀은 다른 무언가를 최적화합니다: 즉, 정확하고 프로덕션 준비가 된 소프트웨어가 고객에게 도달하는 속도입니다.

  1. 에이전트 맥락에 투자하세요! 에이전트 조종 파일과 팀 관례, 코딩 표준, 테스트, 코드베이스 탐색에 관한 지침을 통해 에이전트가 프로젝트와 지식을 더 쉽게 활용할 수 있도록 막대한 투자를 합니다. Amazon Bedrock 인프라 팀은 모든 코드와 문서를 모노레포에 저장하고, AI 에이전트가 생성하는 인라인 해설을 영구 메모리로 관리했습니다. 이 단계를 건너뛰는 팀들은 왜 에이전트들이 같은 실수를 반복하는지 의아해합니다.
  2. 숨고르기를 통해 속도를 올리세요! 앞서 언급한 모범 사례는 시간이 걸리고 팀들이 인내심을 갖도록 요구합니다. 높은 성과를 보인 팀은 새로운 AI 모델을 배우면서 처음에는 작업이 느려졌다고 보고했습니다. 그들은 교차 기능 전문성을 에이전트용 재사용 가능한 문서에 변환했습니다. 언어 모델이 이를 추론할 수 있도록 저장소를 재구성했으며, AI 소비를 위한 주석과 코드 분할 재설계를 추가했습니다. 이러한 학습 곡선을 극복하고 기대 결과를 자세히 정의한 팀들이 나중에 더 빠른 속도를 경험했습니다. 반대로 워크플로우를 바꾸지 않고 즉각적인 성과를 기대했던 팀들은 실망했습니다. 아마 처음 2주는 느리게 느껴질 거예요. 다만, 이후 몇 주가 훨씬 더 빠르게 느껴질 것으로 예상하세요. 2주차에 포기한 팀은 복리 효과를 누리지 못했습니다.
  3. 에이전트에 일을 계속 시키세요! 프런티어 팀은 명확한 결과를 가진 잘 구분된 작업의 적체를 꾸준히 유지하며, 여러 에이전트를 병렬로 운영하고 비동기적으로 출력을 검토했습니다. 개발자들은 주요 특징을 짧은 시간 내에 완료한다고 보고하며, 에이전트가 작업을 완료하기를 적극적으로 기다리지 않아도 작업이 진행됩니다. 한 수석 엔지니어는 에이전트가 일하는 동안, 엔지니어가 코드 검토, 운영 지원, 회의 사이를 오가며 작업했기 때문에 ‘몇 시간의 연속된 시간’으로 완전한 변경 사항을 출시했습니다.
  4. 코드를 작성하기 전에 의도를 명확히 하세요! 구조화된 명세서, 상세한 요구사항 문서, 또는 잘 구체화된 작업 분해 등을 통해 프런티어 팀은 에이전트가 코드를 생성하기 전에 ‘완료’가 무엇인지 명확한 맥락을 보장했습니다. 이 방식을 사용하는 일부 팀은 코드의 1–2%만 손으로 작성하면서도 이전보다 1인당 커밋 수를 훨씬 더 많이 만들어 내고 있다고 말했습니다.
  5. 조기 테스팅을 통해 문제를 발견하세요! 프런티어 팀은 에이전트가 모든 통합 테스트를 로컬에서 실행하고 코드가 파이프라인에 도달하기 전에 스스로 수정할 수 있도록 테스팅 도구를 미리 구축합니다. 프라임 비디오 팀은 자동화된 가드레일, 부품 테스트, 성능 테스트, 그리고 문제를 조기에 발견하는 포맷터에 투자했습니다. 코드 검토는 코드 스타일과 명명 규칙보다는 인터페이스 정의와 아키텍처 결정에 초점을 맞추게 되었습니다.

오늘날 기술 리더들이 할 수 있는 일

사실 모든 개발팀이 이런 성과를 내는 것은 아닙니다. 컨텍스트 구축 단계를 건너뛰거나, AI를 임시적인 대체물로 취급하거나, 즉각적인 성과를 기대하지만 일관되게 업무 방식을 재구성하지 않는 팀은 성과가 저조했습니다. 현재, 업계 전반의 개발자들이 AI 코딩 도구를 도입하고 있습니다. 모든 곳이 생산 증가를 보이는 것은 아닙니다. 그들은 잘못된 도구를 사용하고 있지도 않습니다. 다만, 그들은 잘못된 워크플로우 안에 그러한 도구를 사용하고 있을 뿐입니다.

주요 요점은 다음과 같습니다:

  1. AI가 최상의 성능을 발휘하도록 작업 방식을 바꾸세요.
  2. 결과를 내기 위해서는 세 가지 요소가 팔요합니다다:
    “낮은 판단 작업을 처리하는 AI”  x  “높은 판단 작업에 끊임없이 집중하는 것” x “도메인 전문성에 대한 즉각적인 접근”
  3. 먼저 계획을 짜고, 그 다음에 확장하세요.

우리가 해야할 실질적인 출발점은 AI를 광범위하게 도입하는 것이 아닙니다. 오히려 의도적인 파일럿을 해보는 것입니다. 첫 몇 주 동안 에이전트 컨텍스트(스티어링 파일, 명세 템플릿, 모노레포)를 구축하는 작은 팀부터 시작해 프로덕션용 코드를 작성해 보세요. 그러한 파일럿 개발팀에 워크플로우를 재구성할 권한을 부여하세요. 커밋 속도, 배포 빈도, 해결 시간, 그리고 개발자 만족도 점수를 직접 측정하세요. 그 후, 파일럿팀이 배운 것을 활용해 회사 조직 전체를 위한AI 개발 가이드을 만들면 됩니다.

생산성이 4.5배에서 10배 이상으로 향상된 팀은 단순히 더 나은 기술을 도입한 것이 아닙니다. 그들은 그것을 다르게 다루는 방법을 알아냈습니다. 그 결정은 오늘날 모든 엔지니어링 조직에 적용되어 있습니다. 물론, 코드 커밋 속도는 이야기의 일부에 불과합니다. 우리는 출시 관리, 운영, 보안 운영의 간소화, EOL 업그레이드 등등 소프트웨어 엔지니어링과 관련된 수많은 단순 작업 등 소프트웨어 개발 수명 주기의 모든 측면을 돕고자 합니다.

Kiro를 사용했던 프런티어 개발팀의 사례에 대해 더 자세히 살펴보시고, 오는 6월 17일 AWS Summit New York 기조 연설에서 AI 네이티브 개발에 대해 더 자세히 알아보세요!

– Swami Sivasubramanian, Vice President for Agentic AI, AWS

더 읽어 보기