일주일을 멈추고 에이전트로 갈아탄 Affirm

1. 왜 이 사례인가

기업이 코딩 에이전트를 도입하는 방식은 대개 점진적입니다. 관심 있는 팀부터 먼저 써 보고, 효과가 확인되면 범위를 조금씩 넓힙니다. 하지만 Affirm은 다른 길을 택했습니다. 2026년 2월, 일주일 동안 평소 하던 엔지니어링 업무를 멈추고 800명이 넘는 엔지니어에게 실제 업무를 기획부터 구현, 테스트, 코드 리뷰까지 에이전트로 처리하게 했습니다. 이 프로젝트의 이름은 AI Retooling Week였습니다.

Affirm은 연간 1억 3,000만 건이 넘는 거래를 처리하는 신용 네트워크를 운영합니다. 돈을 다루는 회사라 사소한 실수도 큰 비용으로 이어지며, 품질은 계약상 결코 타협할 수 없는 조건입니다. 이런 회사가 전사 개발 업무를 일주일간 멈춘 결과, 2026년 4월 기준 Affirm의 전체 PR 가운데 60% 이상이 에이전트 지원을 받아 작성되고 있습니다. 넉 달 전만 해도 이 비율은 거의 0이었습니다.

이 사례를 눈여겨볼 이유는 성공적인 수치보다 그 과정을 솔직하게 기록했다는 데 있습니다. 글을 쓴 개발자 생산성 조직 책임자 Daniel Martin은 준비 과정과 워크플로를 소개한 뒤, 그 주에 무엇이 막혔는지를 가감 없이 적었습니다. 코드 생성이 빨라지자 리뷰, CI, 문서, 도구 연동 같은 기존 병목이 한꺼번에 드러났고, 몇 주 뒤에는 CI 파이프라인이 멈추는 일까지 일어났습니다. 코딩 에이전트를 조직 전체로 넓히려는 기업이 무엇을 먼저 준비해야 하는지 생생하게 보여 주는 사례입니다.

2. Problem

Affirm의 신용 네트워크를 더 확장하려면 품질 좋은 소프트웨어를 더 빠르게 배포해야 했습니다. 하지만 개발 속도를 가로막는 제약이 적지 않았습니다. 원문은 금융을 다루는 사업 특성과 함께, 12년 동안 쌓여 온 모노레포의 구조적 병목을 원인으로 꼽습니다. 비대해진 테스트 스위트, 수작업에 의존하는 코드 리뷰, 불안정한 CI, 필요한 배포 속도를 따라가지 못하는 인프라가 문제였습니다.

AI 도구를 전혀 쓰지 않고 있던 것은 아닙니다. Affirm은 2025년 내내 AI 지원 개발에 투자했고, 12월에는 엔지니어의 80% 이상이 AI 개발 도구를 매주 활용하고 있었습니다. 바로 그 무렵 차세대 도구들이 기술적 기준점을 넘어섰습니다. 원문은 Anthropic의 Opus 4.5 같은 모델이 등장하면서 코딩 에이전트가 코드베이스를 탐색하고, 접근 방식을 계획하며, 코드를 작성하고, 테스트를 실행해 오류를 수정하는 전 과정을 사람의 개입을 최소화한 채 안정적으로 수행할 수 있게 되었다고 설명합니다.

진짜 문제는 엔지니어 사이의 격차였습니다. Affirm의 데이터와 인터뷰에 따르면 수십 명의 엔지니어는 이미 이 도구를 자사 코드베이스에 능숙하게 쓰며 일하는 방식을 완전히 바꾸고 있었지만, 나머지 800명은 그렇지 못했습니다. 게다가 이 격차는 시간이 갈수록 점점 더 벌어지고 있었습니다. 결국 당면 과제는 소수만이 누리던 가속을 800명 전체 개발자에게 빠르게 넓히는 일이었습니다.

확인된 사실: 연간 1억 3,000만 건 이상의 거래, 돈을 옮기는 사업 특성, 12년 된 모노레포의 병목(테스트 스위트, 수작업 리뷰, 불안정한 CI, 배포 인프라), 2025년 12월 기준 엔지니어 80% 이상이 AI 개발 도구 주간 사용, 수십 명의 선도 사용자와 나머지 800명의 격차.

3. Solution

3.1 경영진이 정한 일주일

1월 중순, Affirm 사장(President)은 전사 메시지를 통해 에이전트 방식의 AI 개발이 소프트웨어를 만드는 핵심 방식이 될 것이라고 공식 선언했습니다. 같은 메시지에서 AI Retooling Week의 일정도 못 박았습니다. 그 주에는 필수 회의를 뺀 모든 회의를 멈추고, 제품 출시 일정을 미루며, 모든 엔지니어와 매니저가 주말까지 실제 업무 하나를 처음부터 PR 제출까지 완전히 에이전트 방식으로 완수해야 했습니다.

점진적인 확산 대신 전용 주간을 정한 이유는 앞서 언급한 격차 때문이었습니다. 도구를 이미 잘 쓰는 엔지니어와 그렇지 못한 동료 사이의 차이가 갈수록 벌어지고 있었고, 경영진은 이 간극을 단기간에 메우기를 바랐습니다.

3.2 9명이 2주 동안 만든 기본 워크플로

Retooling Week를 앞두고 Affirm은 엔지니어 9명으로 태스크포스 성격의 워킹 그룹을 꾸렸습니다. 이들의 과제는 2주 안에, 보통의 Affirm 개발자라면 누구나 별도 설정이나 전문 지식 없이도 코딩 업무 대부분을 자동화할 수 있는 표준 워크플로를 만드는 것이었습니다. 이 그룹이 내린 세 가지 핵심 결정이 이후의 성패를 좌우했습니다.

* 기본 도구 하나: Claude Code를 표준 에이전트 도구로 지정하고, 워크플로 전체를 이 도구의 기능에 맞춰 설계했습니다. 엔지니어들이 첫날부터 뚜렷한 출발점을 갖고 시작할 수 있게 하기 위함이었습니다.

* 로컬 우선 개발: 도구 생태계가 아직 하나의 중앙 플랫폼으로 통합되지 않았고, 엔지니어가 곧바로 실질적인 생산성을 낼 수 있어야 했기 때문입니다.

* 판단이 필요한 곳의 명시적인 사람 확인 지점: 의도 정의, 계획 승인, 최종 코드 리뷰와 병합은 사람이 직접 맡고, 그 외의 기계적인 반복 작업은 안전성이 보장되는 한 최대한 자동화했습니다.

“기본”이 곧 “필수”를 뜻하지는 않았습니다. 다른 도구를 선호하는 엔지니어는 공유된 산출물을 조금만 수정해 활용할 수 있었고, 기본 워크플로가 맞지 않는 팀은 테크 리드가 책임지고 맞춤 조정을 진행했습니다. 전파한 기본 원칙은 도구의 종류와 상관없이 단순명료했습니다. 계획(Plan), 리뷰(Review), 실행(Execute), 검증(Verify), 리뷰(Review), 전달(Deliver)의 여섯 단계입니다.

3.3 작업 하나, 에이전트 세션 하나, PR 하나

워크플로의 기본 규칙은 작업 하나 = 에이전트 세션 하나 = PR 하나였습니다. 핵심은 의사결정을 작업 앞단으로 당기는 데 있었습니다. 코드를 구현하면서 에이전트와 질문을 주고받는 대신, 계획 단계에서 아키텍처와 범위를 먼저 확정하고 좁게 나눈 작업을 에이전트에게 넘기는 방식입니다. 이렇게 하면 엔지니어는 작업마다 독립된 worktree를 생성해 여러 작업을 병렬로 매끄럽게 처리할 수 있습니다. Affirm은 각 단계마다 맞춤형 사내 도구를 구축했습니다.

* 계획: 에이전트 지원 계획 스킬이 요구사항을 구조화된 구현 계획으로 변환하고, 범위를 뚜렷하게 나눈 세부 작업으로 쪼갭니다.

* 리뷰: 코드를 작성하기 전에 담당 엔지니어가 이 계획을 직접 검토하고 승인합니다.

* 실행: 에이전트가 전용 worktree 안에서 배정된 작업 하나를 실제로 구현합니다.

* 검증: 에이전트가 로컬에서 테스트와 린터를 실행하고, 발견된 문제를 스스로 고치며 코드를 자체 검토합니다. CI가 실패하면 빌드 로그를 직접 읽어 원인을 분석하고 수정안을 작성합니다. CI를 완전히 통과할 때까지 이 과정을 스스로 반복합니다.

* 리뷰: 담당 엔지니어가 에이전트의 최종 산출물을 검토하고 다듬습니다. 이때 엄격한 원칙을 세웠습니다. 검토하지 않은 AI 산출물을 동료에게 보내지 않는다는 점입니다. 리뷰어도 팀의 아키텍처 맥락이 담긴 보조 도구로 PR을 검토하지만, 코드는 직접 눈으로 읽고 자신의 판단으로 에이전트가 놓친 결함을 잡아냅니다.

* 전달: 사람의 최종 승인을 받아 안전하게 병합합니다.

이 모든 과정의 밑바탕에는 코드베이스의 계층마다 세심하게 배치한 컨텍스트 파일이 있었습니다. 코딩 스타일, 도메인 지식, 팀의 주요 결정을 에이전트가 언제든 찾아볼 수 있게 정리해 둔 것입니다. 이러한 도구들은 사내 플러그인 형태로 배포되었고, 각 팀이 직접 만든 스킬을 공유할 수 있는 중앙 마켓플레이스도 함께 운영했습니다.

3.4 배우면서 일하는 한 주

Retooling Week의 일정은 학습과 실제 업무가 조화를 이루도록 설계했습니다. 월요일에는 경영진의 킥오프와 함께 실제 업무 과제로 전체 워크플로를 시연하는 라이브 데모를 진행했고, 화요일에는 실제 난제에 도구를 적용하는 방법을 보여 주는 “art of the possible” 세션을 온·오프라인으로 열었습니다. 수요일은 방해 없는 집중 작업 시간, 목요일은 팀별 데모 세션이었으며, 금요일에는 엔지니어링 리더들이 선정하고 전사가 투표한 우수 사례 데모를 발표했습니다.

한 주 내내 시간대별 전용 지원 채널을 가동하고, 막힌 엔지니어를 위한 헬프데스크 세션을 운영했으며, 팀별 에이전트 PR 제출 현황 순위표를 투명하게 공개했습니다. 작업과 코드베이스의 특성에 따라 진행 속도와 난이도가 다를 수밖에 없음을 처음부터 인정했고, 완성도보다는 새로운 시도와 실험 자체를 독려했습니다.

확인된 사실: 1월 중순 사장의 전사 메시지, 필수가 아닌 회의 중단과 출시 일정 연기, 모든 엔지니어·매니저의 에이전트 PR 제출 목표, 9명 워킹 그룹과 2주 준비, Claude Code 기본 도구·로컬 우선·사람 확인 지점의 세 가지 결정, 테크 리드의 맞춤 조정, 여섯 단계 사고방식, 작업·세션·PR 1:1:1 원칙과 worktree 병렬 작업, 단계별 사내 도구, 검토하지 않은 AI 산출물 공유 금지 규칙, 다층 컨텍스트 파일, 사내 플러그인과 스킬 마켓플레이스, 요일별 일정과 지원 체계.

4. Impact

4.1 Retooling Week의 측정 결과

Affirm은 팀별 및 워크플로 단계별 도입률, PR 생성 수, 오픈된 PR 대비 병합된 PR의 비율까지 세밀하게 추적했습니다.

원문에서는 “에이전트 지원” PR을 “Claude가 전부 작성했을 가능성이 매우 높은” PR로 정의합니다. 도입 초기 반신반의하던 엔지니어들도 주 중반을 지나며 실질적인 효용을 체감하기 시작했고, 여러 팀에서 주가 끝나기도 전에 이 업무 방식을 앞으로 어떻게 이어 갈지 묻기 시작했습니다.

4.2 드러난 병목

원문은 이번 프로젝트에서 얻은 가장 소중한 수확이 무엇이 잘 작동하지 않는지를 여과 없이 파악한 것이라고 밝힙니다.

* 변경 리뷰: 전사 설문에서 가장 많은 불만이 쏟아진 단계였습니다. 전체 응답자의 약 40%가 주관식 설문에서 묻지도 않았는데 이 문제를 스스로 꼽았습니다. PR이 리뷰 단계에서 며칠씩 묶이는 일이 빈번했고, 쏟아져 나오는 PR 물량을 기존의 수작업 리뷰 방식으로는 감당하기 어려웠습니다.

* CI 속도와 안정성: 단위 테스트 실행 시간은 p75 기준 약 8분 수준이었지만, 임시 테스트 환경에서 돌아가는 전체 E2E 회귀 테스트는 100분이 넘게 걸렸습니다. 에이전트 기반 개발의 핵심인 “변경, 검증, 수정, 재검증”의 빠른 피드백 루프를 염두에 두고 만든 인프라가 아니었습니다.

* 도구 연동: 엔지니어들은 수십 개의 MCP를 통해 에이전트를 사내 시스템 곳곳에 연결하고 싶어 했습니다. 연동을 중앙에서 통제하는 것은 필수적인 보안 원칙이었으나, 요청이 한꺼번에 쏟아지면서 검토 체계가 마비되었습니다. 연동 지점이 늘어날수록 보안 위험도