하루 1,000달러 토큰으로 만드는 레거시 코드 AI 워룸

메타데이터

• 날짜: 2026-10-21
• 채널: aiDotEngineer (AI Engineer)
• 영상 ID: DouK81O8R3o
• 원문 URL: https://www.youtube.com/watch?v=DouK81O8R3o
• 발표자: Ford Prior, GEICO Claims Tech 그룹 Senior Staff Engineer·Tech Evangelist
• 길이: 18분 42초

📌 핵심 질문 / 핵심 논점

코딩 속도를 높인 뒤에도 의사결정·승인·도메인 맥락 수집이 느린 조직에서, 레거시 시스템을 안전하게 현대화하고 실제 변경까지 어떻게 연결할 것인가? GEICO는 도메인 지식과 판단권을 가진 사람들, 업무 맥락과 도구, 작업 규칙, 그리고 에이전트 군집을 한 공간에 모아 이를 해결하려 했다.

• GEICO의 레거시 보험 청구 시스템은 수백만 줄의 코드로 이뤄져 있으며, 한 번 구축한 깊은 도메인 맥락을 반복해서 활용할 수 있다.
• 하루에 AI 토큰 비용 1,000달러를 투입해 한 도메인을 처음부터 끝까지 파악하고, 오후 4시까지 에이전트 호출형 API 또는 실행 가능한 현대화 계획을 만드는 실험을 세 차례 진행했다.
• 재사용 가능한 기반은 특정 모델보다 GEICO의 지식·도구·개발 방법·판단권을 담은 FleetKit과, 사람의 승인 단계를 포함한 워룸 운영 방식이었다.

핵심은 코드 작성 자체를 더 자동화하는 데 그치지 않는다. 업무를 이해하고 결정을 내릴 적임자와 에이전트가 같은 흐름에서 협업하게 해, 빠른 개발 내부 루프(inner loop)를 조직의 의사결정·승인 외부 루프(outer loop)와 연결한다. 에이전트는 조사와 분석, 설계 산출물을 가속하고 사람은 핵심 판단과 승인 관문을 맡는다.

1. GEICO의 개발 병목은 코딩보다 위험 관리와 협업에 있다

1.1. 보험 청구 업무에서 소프트웨어가 맡는 역할

1. 보험 사고가 청구와 해결로 이어진다

   1. GEICO는 자동차 사고로 발생하는 손실(loss)을 보험 가입자가 신고하면 이를 청구(claim)로 처리한다.
   2. 청구 기술은 보험 계약을 실제 고객 경험으로 전환하며, 고객이 불필요한 방해를 최소화하고 가능한 한 빨리 다시 도로에 나가도록 돕는 결과를 해결(resolution)이라고 부른다.

2. 위험 관리가 개발 과정 전체를 규정한다

   1. GEICO는 기술 회사라기보다 위험 관리 회사이며, 위험 관리 원칙은 소프트웨어 개발·출시 방식에도 스며 있다.
   2. 따라서 코드 변경이 빨라져도 업무 맥락을 확인하고 여러 단계의 결정을 승인하는 과정이 함께 빨라지지 않으면 실제 고객 가치로 이어지기 어렵다.

3. Ford Prior의 역할은 개발 관행을 개선하는 것이다

   1. Prior는 GEICO 청구 기술 조직에 속한 Senior Staff Engineer이자 Tech Evangelist이며, 본인이 Berkshire Hathaway에서 유일한 Tech Evangelist인 것 같다고 소개했다.
   2. 약 300명의 엔지니어 조직은 당시 ‘피자 팀’이라 부르는 약 32개 팀으로 구성됐고, 각 팀에는 기술 리드와 사업 부문 담당자가 함께한다. Prior는 SDLC 모범 사례를 찾고 적용하며 Claims Innovation Lab을 운영한다.
   3. 그는 청구 도메인이 흥미로울 뿐 아니라 미국 경제에서 중요하다는 점을 알려 이 문제를 풀 우수 엔지니어를 끌어들이려 한다.

1.2. 내부 개발 루프는 빨라졌지만 외부 루프는 뒤처졌다

1. AI가 코딩 시간을 줄였지만 승인까지의 흐름은 남았다

   1. 최근 몇 년간 소프트웨어 개발 생명주기(SDLC)의 속도, 특히 코딩과 지적 작업이 집중된 빌드 구간을 줄이는 데 관심이 쏠렸다. GEICO에서도 에이전트가 이 단계를 크게 단축해 시간을 되찾았다.
   2. 진 킴(Jean Kim)의 개념을 빌리면 코딩·빌드에 해당하는 내부 루프(inner loop)는 가속됐지만, 그 밖의 의사결정·맥락 수집·승인 절차인 외부 루프(outer loop)는 여전히 병목이었다.
   3. 모든 일을 에이전트가 하고 사람이 각 단계에서 임원처럼 승인만 하는 미래를 상정할 수 있지만, 위험 관리 조직에서는 각 결정에 필요한 근거와 책임 구조를 함께 다뤄야 한다.

2. 패치와 마이너 작업이 엔지니어 시간을 잠식했다

   1. 약 6개월 전 백로그를 살펴보니, 최신 패치 적용이나 마이너 업그레이드를 처리한 뒤 경쟁력을 높이는 주요 변경(V1에서 V2, V3로의 변화)에 쓸 수 있는 여력은 좋은 날에도 25% 이하에 불과했다.
   2. GEICO는 여러 하네스(harness)와 모델에서 동작하는 자체 관리형 AI 에이전트에 패치·마이너 작업의 명세부터 배포까지 맡기기 시작했다.
   3. 목표는 반복 작업을 에이전트로 돌려 우수한 엔지니어가 경쟁 우위와 연결되는 주요 변경에 집중하고, 자신들이 가장 보람을 느끼는 일에 시간을 쓰게 하는 것이다.

3. 대규모 변경에는 협업과 정보 종합이라는 두 병목이 남았다

   1. 중요한 결정을 내려야 할 때마다 적임자들이 적시에 모여야 했지만, 적절한 사람들을 필요한 생애주기의 각 구간에 모으는 능력이 주요 작업의 속도 제한 요인이었다.
   2. 문제를 이해해 갈수록 관련 변수, 사실 확인(fact-checking), 레거시 코드 분석, 코드 구조 파악을 한데 엮어 의사결정 시점에 맞춰 통찰을 제공할 지능형 지원도 부족했다.
   3. 신뢰를 갖고 주요 변경을 출시하려면 협업 능력과 지능형 정보 종합이 함께 필요했다. GEICO는 둘 다 주요 변경 규모에서 부족하다고 판단했다.

2. AI 네이티브 워룸에서 세 가지 현대화 임무를 실험했다

2.1. 의사결정권자와 도메인 전문가, 에이전트 도구를 한데 모았다

1. 사람의 역할을 명확히 한 멀티플레이어 워룸

   1. AI 네이티브 워룸(multiplayer AI-native war room)은 해당 주제의 핵심 의사결정권자와 도메인 전문가(SME) 명단, 비용이 큰 AI 도구를 운용하는 드라이버(driver), 그리고 협업 공간으로 구성된다.
   2. 드라이버는 에이전트와 도구를 실제 업무 흐름에 투입하고, 관련 사람은 도메인 지식과 판단을 제공한다. 조직의 판단 책임을 에이전트에게 통째로 넘기지 않는 구조다.

2. 협업 도구와 코드·에이전트 실행 체계를 연결했다

   1. 협업 공간에는 대화 채널과 인터랙티브 디자인 스튜디오가 있고, 코드 저장소와도 연결된다.
   2. 워크플로, 에이전트 스킬, MCP와 엔터프라이즈 MCP, 에이전트 플릿(fleet)을 결합해 조사·사실 확인·종합을 처리한다.
   3. 발표자는 사용한 생산성 도구의 공급사 이름은 밝히지 않았지만, 핵심은 한 제품이 아니라 커뮤니케이션·설계·코드 저장소·업무 도구를 하나의 워룸 경험으로 묶은 데 있다.

2.2. 하루 1,000달러 실험의 범위와 세 가지 결과

1. 목표를 좁고 검증 가능한 결과로 정의했다

   1. 핵심 질문은 “레거시 핵심 기능을 호출하는 에이전트용 API를 어떻게 더 빠르게 제공할까?”였다.
   2. 청구 시스템은 수백만 줄 규모였지만, 도메인의 깊은 맥락은 한 번 구축하면 재사용할 수 있다는 가정 아래 시작했다.
   3. 하루 동안 AI 토큰 1,000달러어치를 사용해 사업 토폴로지 그래프, 복잡한 레거시 코드, 그 사이의 연결 관계를 포함해 도메인 하나를 끝까지 지도화하려 했다. 에이전트가 중대한 변경 한 건을 찾아 제안하게 하고, 범위를 레거시 청구 시스템의 에이전트 호출형 API로 좁혀 스킬 에이전트 플랫폼에 배포한 뒤 오후 4시에 상사에게 시연하는 목표를 세웠다.
   4. 이 실험은 세 번 반복됐고, 각 실행은 코드 현대화의 세 단계인 uplift, transform, reimagine 가운데 하나를 택했다. 이 분류는 Anthropic의 Code Modernization 플러그인에서 가져왔다.

2. 렌털 도메인에서는 기존 API를 개선했다 — Uplift

   1. 비교적 단순한 렌털 도메인은 기본 차량이 사고를 당했을 때 대체 렌터카를 제공하는 데 필요한 기술을 다룬다.
   2. 기존 기능을 대체하기보다 같은 기술의 새 버전을 구현하고 API를 확장하는 방식으로 uplift를 진행했다.
   3. 에이전트가 데이터를 찾아 정제하고 연결 관계를 파악한 결과, 고객에게 최신 렌터카 정보를 제공하면 월 8,500회의 호출을 절감할 수 있다고 제안했다.

3. 손해액과 전손 차량 도메인에서 더 큰 변화를 준비했다

   1. 손해액(damages) 도메인은 신고된 손실에 금액을 산정하는 역할을 한다. 이 영역에서는 손해액 데이터가 필요한 더 큰 업무 흐름을 열 수 있도록 에이전트 호출형 API들을 새로 만들었다(transform).
   2. 전손(salvage) 도메인은 차량이 전손 처리된 뒤 일어나는 일들을 다루며, 세 영역 가운데 가장 복잡한 것으로 소개됐다. 이 영역에서는 기존 구현보다 전면 재구상을 택했다(reimagine).
   3. 전손 임무는 API 명세와 설계 목업을 포함한 검증된 마이그레이션 계획으로 끝났다. 제품·기술 조직 각 수준의 담당자가 이를 승인하고 실행을 허가해, 상세 기술을 포함한 프로젝트 계획이 실제 구현 준비를 마쳤다.
   4. 에이전트는 이 과정에서 프로덕션 버그도 찾아냈다. 발표자는 세부 내용을 공개하지 않았지만 발견 자체가 놀라웠다고 밝혔다.

3. FleetKit은 조직 고유의 맥락을 에이전트 플릿 운영 규칙으로 바꾼다

3.1. 공급사 도구보다 GEICO 고유 자산이 대체하기 어려웠다

1. 벤더가 제공한 모델·하네스·현대화 플러그인

   1. Anthropic 측 구성은 하네스, 모델, FleetKit 협업, 코드 현대화 작업용 플러그인이었다.
   2. 발표자는 이 네 요소를 다른 벤더·모델·프레임워크로 교체할 수 있다고 강조했다. 이들만으로 GEICO의 업무를 이해하거나 의사결정을 내릴 수는 없다.

2. 조직의 지식·도구·방법·판단이 차별화 요소였다

   1. 지식(context)에는 지식 베이스, 소프트웨어 표준, 과거 결정을 추적하는 의사결정 고고학(decision archaeology)이 포함됐다.
   2. 도구(tools)에는 드라이버 컴퓨터에서 에이전트가 접근할 수 있는 도구 목록과 각 도구의 사용 지침이 포함됐다.
   3. 방법(methods)은 스킬과 GEICO 특유의 도메인별·고도로 최적화된 개발 관행이었다.
   4. 판단(judgment)은 누가 어떤 관문에서 결정을 내릴 수 있는지를 정의하며, SME와 리더십의 권한을 모두 포함했다.
   5. 이 자료는 두 저장소로 나눴다. 에이전트는 자료를 추가·수정할 수 있고 사람도 같은 방식으로 보정해, 맥락을 공동으로 축적하도록 했다.

3.2. FleetKit이 리서치와 구현을 승인 관문으로 연결한다

1. Markdown 규칙집이 시스템 프롬프트 위에서 작업을 조율한다

   1. FleetKit은 규칙·프로토콜·지침을 촘촘하게 구조화한 Markdown 모음이며, Anthropic의 Claude 계열 하네스와 아키텍처 변환 과제에 맞춰졌다.
   2. 시스템 프롬프트 자체라기보다 에이전트가 반드시 따라야 할 한 단계 위의 운영 규칙으로 작동한다. 발표자는 이전 세대 모델로는 이 수준의 조향이 어려웠고, 더 강한 추론·지시 이행 능력을 가진 모델이 필요하다고 봤다.
   3. FleetKit은 오픈소스가 아니었지만, 발표자는 구조가 본질적으로 복잡한 마법은 아니라며 다른 조직도 유사한 방식을 구성할 수 있다고 했다.

2. 리더 에이전트의 조사와 사람의 승인을 거쳐 빌더를 투입한다

   1. 목표를 받으면 FleetKit이 작업을 분해하고, 리더 에이전트를 보내 조사와 접근 방법 결정을 맡긴다.
   2. 조사 결과는 사람 개입(human-in-the-loop) 대기열에 들어간다. GitHub Issues처럼 사람이 논평·승인할 수 있고 다른 에이전트도 맥락을 보탤 수 있는 도구를 사용할 수 있다.
   3. 승인 관점에서 계획이 충분히 탄탄해지면 빌더 에이전트가 후속 구현을 맡는다. GEICO는 에이전트별 작업 추적에 Beads를 사용했다.
   4. 최종 산출물은 시스템 변경 요청 또는 코드 저장소의 코드 변경인 ‘material change’다. 에이전트가 만드는 자료는 토론용 초안에 머물지 않고 실제 변경 흐름으로 이어지도록 설계됐다.

3. 소프트웨어 개발을 캔버스에서 공장으로 바꾸려 했다

   1. Prior가 제시한 지향점은 소프트웨어 개발이 캔버스 위에서 자유롭게 작업하는 모습보다 공장(factory)처럼 반복 가능한 흐름으로 움직이는 것이다.
   2. 반복 가능한 규칙·산출물·승인 단계가 있으면 에이전트 플릿을 확장할 때 작업을 추적하고 비용을 관리하기 쉬워진다.

3.3. 워룸은 채널·산출물·클라우드와 로컬 에이전트를 연결한다

1. 미션별 채널과 9단계 프로세스로 협업을 운영했다

   1. FleetKit 소스를 포함한 세 저장소가 실행에 필요한 내용을 담고, 시스템은 Claude Code 세션과 플러그인을 시작한 다음 미션을 입력받는다.
   2. 미션에 맞춰 Slack 또는 사내 커뮤니케이션 플랫폼의 전용 채널을 만들거나 재사용한다. 관련 의사결정자와 프로젝트 구성원을 초대해 사람이 같은 맥락을 공유하게 한다.
   3. 에이전트가 9단계 프로세스의 각 이정표에 도달할 때마다 산출물 중 하나를 만든다. 필요한 제품 맥락이 빠지면 워룸의 담당자 명단을 이용해 제품 책임자를 찾아 직접 질문할 수 있다.

2. 워크시트와 설계 문서가 질문·검토를 구체화했다

   1. 하나는 사람이 내용을 채워 넣을 수 있는 HTML 워크시트였다. Cloud Artifacts로 만들고 자동 저장해, 에이전트가 발견한 정보 공백을 사람이 메우도록 했다.
   2. 다른 하나는 기존에 없던 아키텍처의 복잡한 시각화 등을 담은 설계 문서였다. 사람은 이를 편집할 수 있고 에이전트는 수정된 문서를 다시 읽어 세션 맥락에 반영했다.
   3. 제품 워크시트와 다이어그램은 팀이 프로젝트 뒤에도 보관할 만큼 품질이 높았다. 질문은 단순 확인이 아니라 사업 또는 기술의 미처 생각하지 못한 경계 사례를 드러냈고, 설계 문서는 평소 그릴 시간이 부족했던 시스템을 남겼다.

3. 클라우드 코드 분석과 로컬 MCP 에이전트가 서로 다른 맥락을 맡았다

   1. ‘코드 다이브(code dives)’ 에이전트는 클라우드에서 레거시 도메인별 언어를 대량 분석하고 코드 구조를 그래프로 만들었다.
   2. 로컬 에이전트는 드라이버의 노트북과 MCP들에 접근했다. 그중 일부 엔터프라이즈 MCP는 아직 프로덕션에 들어가기 전이었지만 GEICO 문제에 맞게 최적화돼 있었고, 코드베이스를 청크 단위로 다룬 데이터를 포함해 가치 있는 정보를 노출했다.
   3. 노트북의 구성요소와 동작 방식, FleetKit 업무와의 연결을 설명하는 bindings 파일을 드라이버가 제공했다. 이 설명이 로컬 도구를 에이전트 플릿의 작업에 연결했다.

4. 사람의 승인은 초반에 많고 뒤로 갈수록 줄었다

   1. Prior는 드라이버 노트북을 전체 실행의 런타임으로 사용했고, Code Modernization 플러그인에서 가져온 단계를 GEICO 요구에 맞게 조정했다.
   2. 9단계 중 부팅 이후 여덟 단계가 이어졌고, 일부 단계는 사람이 검토·승인해야 하는 워크시트를 생성했다. 현대화 여정의 초반에는 사람 입력이 많고 후반으로 갈수록 줄어드는 구조였다.
   3. 각 단계는 이전 단계가 필요한 산출물, 파일 등을 만들었는지 결정론적으로 확인했다. 다음 단계로 넘기기 전 결과물 존재 여부를 검사해, 누락된 산출물을 놓치지 않도록 했다.

4. 비용·모델 선택·승인 설계를 다음 개선 과제로 삼았다

4.1. 에이전트 플릿 비용과 모델 성능을 실제 작업으로 평가했다

1. 비동기 작업 감시를 위한 반복 실행도 비용을 만든다

   1. Prior는 실험에 상당한 토큰 비용을 썼다고 농담 섞어 말했다. 특히 Claude 기반 에이전트에게 cron으로 작업을 점검하게 두면 실행할 때마다 새 세션을 시작해 예산을 즉시 소모할 수 있다고 경고했다.
   2. 플릿 운영에서는 프롬프트 캐싱(prompt caching)이 예상보다 훨씬 많이 활용됐고, 하위 에이전트(subagent)의 특이 동작도 관찰됐다. 비용 추정에는 모델 호출뿐 아니라 반복 세션 실행과 에이전트 조율을 포함해야 한다.

2. 고가 모델을 기본값으로 두지 말고 도메인 코드로 비교한다

   1. 도메인 맥락을 충분히 만든 뒤 에이전트에 복잡한 레거시 코드를 작성하게 하고, 최근에 사람이 작성한 기존 코드를 골든 데이터(golden data)로 삼아 벤치마크했다.
   2. 이 비교에서 더 저렴한 Sonnet 계열 모델은 고가 Opus 계열과 동등하거나 더 나은 코드를 썼다. 발표에서 모델의 정확한 세부 버전명은 명료하지 않았지만, 결론은 과제별 벤치마크를 통해 적합한 모델을 고르는 일이 중요하다는 것이다.

4.2. 사람의 판단 관문과 맥락 수집을 강화해야 한다

1. 게이트 집행과 의사결정 모델을 개선한다

   1. Prior가 가장 큰 성과로 기대한 개선은 승인 게이트를 더 잘 강제(enhanced gate enforcement)하는 것이다.
   2. 하네스와 모델 선택 프레임워크 안의 의사결정 모델도 업데이트할 계획이었다. 에이전트가 다음 단계로 넘어가기 전에 누구의 판단이 필요한지 분명히 해야 한다.

2. Markdown 지식의 탐색·검색 방식을 개선한다

   1. 당시 팀의 맥락은 주로 Markdown 파일에 저장돼 있었고, Graphify나 Obsidian 같은 그래프 기반 도구를 쓰는 복잡한 방식은 적용하지 않았다.
   2. 방대한 맥락을 워룸에 제공하기 위한 검색·조회 방식을 더 최적화할 여지가 있었다. 파일을 축적하는 것뿐 아니라 필요한 근거를 적절한 시점에 찾아오는 검색 체계가 과제다.

3. 회의 음성을 데이터로 수집해 기억 손실을 줄인다

   1. Prior는 워룸 대화를 녹음해 자동 전사하고 싶었지만, 당시에는 회의 중 직접 빠르게 메모해야 했다.
   2. 기록을 손으로 받아 적는 동안 중요한 입력을 놓쳤을 수 있으므로, 음성(audio)을 데이터 원천으로 활용해 워룸의 논의와 판단 근거를 덜 손실되게 저장하려 했다.

4.3. 배포는 조직의 판단 능력과 사람의 다음 목표 선정에 달렸다

1. 작은 조직 단위에서 시작하고 소유권과 비용을 관리한다

   1. 조직 전반에 확대하기 전, 결정을 내리는 데 어려움을 겪는 팀을 찾아 워룸을 도입하고 직접 운영해 보는 방안을 제안했다.
   2. 각 조직의 문제에 맞게 도구를 자기 것으로 만들고 비용을 통제하면서 효과를 확인해야 한다.

2. 사람은 다음 ‘언덕’을 선택하고 에이전트는 현재 언덕을 오른다

   1. GEICO는 에이전트가 더 나은 작업 방식을 찾아 점점 개선되는 상황에서 사람을 어디에 개입시킬지 고민했다.
   2. 뛰어난 엔지니어가 에이전트가 현재 오른 언덕 다음에 정복할 목표를 고르게 해야 한다. 에이전트는 선택된 문제를 해결하고 사람은 중요한 판단과 다음 우선순위 설정을 맡는 구조다.

주요 발언 모음

“우리는 기술 회사가 아니다. 위험 관리 회사다.”

“내부 루프는 빨라졌지만, 내부 루프와 보조를 맞추는 외부 루프가 필요하다.”

“이런 방식에서 소프트웨어 개발은 캔버스에서 작업하는 것보다 공장에서 일하는 것에 가까워진다.”

“에이전트가 첫 번째 언덕을 오르는 동안, 우리의 가장 뛰어난 엔지니어가 다음 언덕을 고르게 해야 한다.”

핵심 데이터 & 수치

• 300명: Prior가 설명한 청구 기술 엔지니어 조직의 규모다.
• 약 32개 팀: 팀마다 기술 리드와 사업 담당자가 함께하는 ‘피자 팀’ 단위다.
• 25% 이하: 패치와 마이너 업그레이드를 처리한 뒤 주요 변경에 쓸 수 있던 엔지니어 여력이다(좋은 날 기준).
• 수백만 줄: 레거시 청구 시스템의 코드 규모다.
• 하루·토큰 1,000달러·오후 4시: 도메인 하나를 지도화하고 중요한 변경을 제안해 시연하겠다는 실험의 시간·비용·마감 목표다.
• 3회: 렌털·손해액·전손 도메인에서 수행한 현대화 임무 수다.
• 월 8,500회: 최신 렌터카 정보를 제공하는 변경으로 절감할 수 있다고 에이전트가 제안한 호출 수다.
• 9단계: 부팅 단계와 그 뒤의 여덟 작업 단계로 구성한 FleetKit 현대화 여정이다.
• 2종 에이전트: 레거시 코드를 분석하는 클라우드 코드 다이브와 로컬 MCP에 접근하는 에이전트다.
• 3개 저장소: FleetKit 실행에 필요한 자료와 FleetKit 소스를 보관하는 저장소 수다.

결론 및 시사점

1. 코드 생성 속도만 올려서는 조직의 전달 속도가 충분히 빨라지지 않는다. 결정권자와 도메인 전문가를 필요한 순간에 모으고, 조사 결과와 승인 단계를 같은 실행 흐름에 넣어야 한다.
2. 에이전트 플릿의 경쟁력은 모델 이름보다 조직 지식·접근 도구·도메인 방법·판단권을 구체화한 맥락에서 나온다. 모델과 플러그인은 바꿀 수 있지만 이런 맥락은 조직이 직접 축적해야 한다.
3. 복잡한 레거시 현대화는 목표를 작은 검증 단위로 나누고, 리더 에이전트의 조사·사람의 승인·빌더의 구현을 순서대로 연결하는 편이 안전하다.
4. 자동 생성된 워크시트와 다이어그램은 사람의 판단을 대체하지 않으면서 업무 공백과 경계 사례를 드러내고, 프로젝트 이후에도 남는 조직 자산이 될 수 있다.
5. 비용은 토큰 예산만이 아니라 세션 재시작, 에이전트 조율, 프롬프트 캐시, 승인 대기 흐름까지 포함해 관리해야 한다.
6. 실제 도메인 코드로 고가·저가 모델을 비교하고, 단계별 산출물 검증과 승인 관문을 강화해야 한다.
7. 소규모 팀에서 시작해 비용과 판단 흐름을 다듬고, 사람이 다음 목표를 정하며 에이전트가 실행을 맡는 운영 모델로 확장할 수 있다.

핵심 요약 (20줄)

GEICO는 코딩 속도는 빨라졌지만 의사결정과 승인, 업무 맥락을 모으는 외부 루프가 느리다는 문제를 확인했다. GEICO는 기술 회사보다 위험 관리 회사에 가까우며 위험 관리 원칙은 소프트웨어 개발과 배포에도 적용된다. 청구 기술은 사고로 발생한 손실을 고객이 다시 도로에 나설 수 있는 해결 과정으로 바꾸는 핵심 업무다. 약 300명의 엔지니어는 기술 리드와 사업 담당자가 짝을 이루는 약 32개 팀에서 일한다. 패치와 마이너 업그레이드 뒤 주요 변경에 쓸 수 있는 개발 여력은 좋은 날에도 25% 이하에 그쳤다. GEICO는 반복적인 패치 업무를 여러 모델과 하네스에서 동작하는 자체 관리형 에이전트에 맡기기 시작했다. 주요 변경의 병목은 적임자의 협업과 복잡한 도메인 정보의 신속한 종합이라는 두 가지였다. AI 네이티브 워룸은 의사결정자, 도메인 전문가, 도구를 운영하는 드라이버, 협업 도구와 에이전트 플릿을 한데 모은다. 하루 1,000달러의 토큰 예산으로 레거시 청구 도메인 하나를 분석하고 오후 4시까지 시연하는 실험을 세 차례 진행했다. 렌털 도메인의 uplift는 기존 API를 확장해 고객에게 최신 대체 차량 정보를 제공하고 월 8,500회의 호출을 절감하는 방안을 찾았다. 손해액 도메인의 transform은 손실 금액을 산정하는 데이터에 접근할 에이전트 호출형 API를 추가했다. 전손 도메인의 reimagine은 API 명세와 설계 목업이 승인된 구현 준비 완료 마이그레이션 계획을 만들었다. 전손 도메인 분석은 발표자가 세부를 공개하지 않은 프로덕션 버그도 발견했다. 대체 가능한 모델·하네스보다 GEICO의 과거 결정, 표준, 도구, 개발 방법과 판단권이 더 고유한 자산이었다. FleetKit은 Markdown 규칙으로 목표를 조사 리더와 승인 대기열, 구현 빌더에 연결하고 최종 코드 변경까지 이끈다. 사람은 GitHub Issues 같은 승인 대기열에서 계획을 검토하고 에이전트는 Beads로 작업 진행을 추적한다. 미션별 워룸은 자동 저장되는 HTML 워크시트와 편집 후 다시 읽을 수 있는 설계 문서를 만들었다. 클라우드 에이전트는 레거시 코드를 분석하고 로컬 에이전트는 드라이버 노트북의 MCP와 엔터프라이즈 도구를 활용했다. 실제 코드 벤치마크에서는 저렴한 Sonnet 계열이 고가 Opus 계열과 동등하거나 더 나은 결과를 낼 수 있어 모델 선택이 중요했다. 확장에는 승인 관문, Markdown 지식 검색, 회의 음성 기록과 비용 통제가 필요하며 사람은 에이전트가 오를 다음 목표를 골라야 한다.