전체 사례No. 038
Affirm의 일주일 멈춤 실험
전사 개발을 멈추고 AI 에이전트로 갈아탄 이유
- 사례 번호
- 038
- 1차 출처
- Affirm Tech Blog (Medium)
- 원문 게시
- 2026-04-27
요약
- Affirm은 일주일간 전사 개발을 멈추고 엔지니어 전원이 AI 에이전트로 일하는 실험을 진행했습니다.
- 엔지니어링 조직의 92%가 에이전트 PR을 냈으나, 코드 리뷰와 검사 시스템에 심각한 병목이 드러났습니다.
- AI 도입의 성공은 코드 작성이 아니라 쏟아지는 산출물을 소화할 검증 체계를 갖추는 데 있습니다.
80%가 이미 AI를 쓰는데 왜 전사 개발을 멈췄을까요
한 해 1억 3,000만 건이 넘는 금융 거래를 처리하는 신용 결제 네트워크 기업이 있습니다. 돈이 오가는 시스템인 만큼 작은 실수 하나도 곧바로 막대한 손실로 이어집니다. 품질과 안정성은 고객과의 약속이자 타협할 수 없는 기본 조건입니다. 바로 미국의 핀테크 기업 Affirm 이야기입니다.
그런데 2026년 2월, Affirm은 상상하기 힘든 결정을 내렸습니다. 회사의 정규 제품 출시 일정을 미루고 필수 회의가 아니면 모두 취소했습니다. 800명이 넘는 엔지니어링 조직 전체가 일주일 동안 하던 일을 멈췄습니다. 그들이 모여서 한 일은 단 하나였습니다. 인공지능 에이전트를 써서 아이디어 구상부터 코드 작성, 검사, 동료 검토까지 실제 업무를 온전히 수행해 보는 것이었습니다. 이 특별한 일주일의 이름은 ‘AI 재정비 주간(AI Retooling Week)‘이었습니다.
여기서 자연스럽게 한 가지 의문이 떠오릅니다. Affirm 엔지니어들은 인공지능 도구를 모르는 사람들이 아니었습니다. 2025년 12월 기준으로 이미 전체 엔지니어의 80% 이상이 업무용 AI 도구를 매주 활발하게 쓰고 있었습니다. 10명 중 8명이 이미 도구를 쓰고 있었는데, 금융 서비스를 다루는 회사가 왜 제품 출시까지 미루며 모든 개발자를 한곳에 몰아넣어야 했을까요?
소수의 질주와 벌어지는 격차를 방치할 수 없었습니다
통계의 착시 이면에는 깊은 고민이 숨어 있었습니다. Affirm이 내부 데이터와 인터뷰를 분석해 보니 명확한 현실이 드러났습니다. 수십 명의 소수 개발자는 차세대 인공지능 도구를 깊이 이해하고 일하는 방식을 근본적으로 바꾸고 있었습니다. Anthropic의 Opus 4.5 같은 모델이 등장하면서, 인공지능이 코드 저장소를 스스로 탐색하고 계획을 세워 코드를 고치고 실패를 반복 수정하는 자율적 에이전트 개발이 현실로 다가왔기 때문입니다.
하지만 이 새로운 도구의 혜택은 소수에게만 쏠려 있었습니다. 나머지 대다수 엔지니어는 여전히 기존 방식에서 크게 벗어나지 못했습니다. 문제는 이 격차가 시간이 흐를수록 더 빠르게 벌어지고 있었다는 점입니다. 일부만 고속 열차를 타고 앞서 나가고, 대다수는 보통 열차에 머물러 있다면 조직 전체의 생산성은 올라갈 수 없습니다.
조직 내부의 기술적 조건도 한계에 부딪히고 있었습니다. Affirm은 12년 동안 하나의 거대한 저장소에 모든 서비스의 코드를 모아 관리하는 ‘모노레포’ 구조를 유지해 왔습니다. 서비스 규모가 커지면서 검사할 코드가 지나치게 많아졌고, 사람이 일일이 눈으로 코드를 확인하는 검토 과정은 늘 정체되었습니다. 코드를 합쳐서 자동으로 검사해 주는 ‘지속적 통합(CI)’ 시스템은 자주 불안정해졌고 배포 환경도 속도를 따라가지 못했습니다.
점진적으로 팀마다 알아서 도입하게 두는 방식으로는 벌어지는 격차를 좁힐 수 없었습니다. 1월 중순, Affirm의 사장(President)은 전사 공지를 통해 결단을 내렸습니다. 에이전트 중심의 개발 방식을 핵심 업무 방식으로 공식 선언하고, 2월에 실행할 ‘AI Retooling Week’ 일정을 발표했습니다. 격차를 단숨에 좁히기 위해 회사가 일정을 멈추는 강력한 강제 장치를 가동한 것입니다.
아홉 명의 엔지니어가 2주 만에 만든 표준 경로
전체 개발자가 일제히 도구를 바꾸려면 혼란을 줄여 줄 표준 안내서가 필요했습니다. Affirm은 엔지니어 9명으로 작업 그룹을 꾸리고 딱 2주의 준비 기간을 주었습니다. 이들의 임무는 평범한 개발자라면 누구나 복잡한 설정 없이 대부분의 코딩 업무를 자동화할 수 있는 반복 가능한 작업 흐름을 만드는 것이었습니다.
작업 그룹은 세 가지 기본 원칙을 세웠습니다.
첫째, 복잡함을 없애기 위해 기본 도구를 딱 하나로 정했습니다. 도구의 표준으로 Claude Code를 선정하고, 첫날부터 누구나 헷갈리지 않고 시작할 수 있도록 모든 작업 흐름을 이 도구의 기능에 맞춰 작성했습니다.
둘째, 중앙 서버가 아닌 개발자 개인의 로컬 컴퓨터에서 먼저 실행되는 방식을 택했습니다. 아직 업계 전체에 중앙 집중형 도구 플랫폼이 정착하지 않은 상태였기 때문에, 개발자가 자신의 작업 환경에서 즉시 실행해 볼 수 있어야 했기 때문입니다.
셋째, 판단이 필요한 곳에는 반드시 사람이 개입하는 명시적 검문소를 두었습니다. 무엇을 만들지 의도를 정하고, 계획을 승인하고, 코드를 검토하고, 최종 반영을 결정하는 일은 인간의 몫으로 남겼습니다. 그 외의 기계적인 반복 작업만 최대한 안전하게 자동화했습니다.
이 표준 흐름은 강제가 아닌 권장이었습니다. 다른 도구를 선호하는 개발자는 가벼운 변환 과정을 거쳐 작업물을 활용할 수 있었고, 기본 방식이 맞지 않는 조직은 각 팀의 테크 리드가 책임지고 변형을 이끌었습니다. 개발자들이 기억해야 할 생각의 순서는 도구에 구애받지 않는 여섯 단계로 정리되었습니다. 바로 ‘계획(Plan)·리뷰(Review)·실행(Execute)·검증(Verify)·리뷰(Review)·전달(Deliver)‘이었습니다.
한 번에 한 가지 일만 작은 단위로 쪼개어 맡겼습니다
Affirm이 세운 핵심 규칙은 ‘하나의 과업은 하나의 에이전트 세션이어야 하고, 이것이 하나의 PR로 이어진다’는 1:1:1 원칙이었습니다. 여기서 PR(Pull Request)이란 개발자가 수정한 코드를 중앙 코드 저장소에 반영해 달라고 동료들에게 보내는 검토 요청서입니다.
보통 AI에게 코딩을 맡기면 코드를 짜는 중간에 대화가 길어지면서 엉뚱한 방향으로 흘러가기 쉽습니다. Affirm은 결정을 뒤로 미루지 않고 맨 앞단으로 당겼습니다. 코드를 쓰기 전에 계획 단계에서 구조와 범위를 완전히 확정 짓고, 아주 명확하게 좁혀진 과업만을 에이전트에게 넘겼습니다.
동시에 여러 일을 처리하기 위해 ‘worktree’라는 기술을 활용했습니다. 이는 하나의 코드 저장소 안에서 독립된 여러 작업 공간을 만들어 동시에 서로 다른 작업을 진행할 수 있게 돕는 깃(Git) 도구의 기능입니다. 개발자는 작은 단위의 과업을 여러 작업 공간에 나누어 에이전트들에게 병렬로 맡겼습니다.
단계마다 사내에서 자체 제작한 도구가 투입되었습니다.
- 계획(Plan) 단계에서는 AI 기획 도구가 요구 사항을 정밀한 실행 계획으로 바꾸고 작은 과업들로 쪼갭니다.
- 첫 번째 리뷰(Review) 단계에서는 개발자가 코드를 쓰기 전에 이 계획을 직접 검토하고 승인합니다. 설계가 틀리면 뒤통수를 맞기 때문입니다.
- 실행(Execute) 단계에서는 에이전트가 지정된 독립 작업 공간에서 단 하나의 과업을 코드로 구현합니다.
- 검증(Verify) 단계에서는 에이전트가 로컬 컴퓨터에서 자체 검사 프로그램을 돌려 오류를 잡고, 문법과 코딩 규칙을 다듬어 주는 도구인 ‘린터’를 실행해 스스로 코드를 다듬습니다. 또한 자동으로 통합 검사를 돌려주는 CI 환경에서 실패가 발생하면, 에이전트가 빌드 기록을 직접 긁어와 원인을 분석하고 수정안을 내며 통과할 때까지 이 과정을 되풀이합니다.
- 두 번째 리뷰(Review) 단계에서는 사람이 다시 등장합니다. Affirm은 “검토하지 않은 AI 산출물을 절대 동료에게 보내지 마라”는 엄격한 규칙을 세웠습니다. 검토자 역시 팀의 시스템 구조 맥락을 탑재한 에이전트를 보조로 쓰지만, 코드를 직접 읽고 판단하는 책임은 인간 검토자에게 두었습니다.
- 마지막 전달(Deliver) 단계에서 동료의 최종 승인을 받아 코드를 안전하게 반영합니다.
이 흐름을 지탱하기 위해 Affirm은 코딩 규칙, 도메인 지식, 과거 결정 사항을 계층별 파일로 정리해 에이전트가 쉽게 읽을 수 있도록 코드 곳곳에 배치했습니다. 이를 내부 플러그인으로 배포하고, 팀별로 필요한 기능을 만들어 공유하는 마켓플레이스도 함께 열었습니다.
재정비 주간의 진행 방식도 배움과 실습의 균형을 맞췄습니다. 월요일에는 사내 실시간 시연으로 시작했고, 화요일에는 실제 문제를 해결하는 기술 세션을 열었습니다. 수요일은 방해받지 않고 온전히 실전에 집중하는 시간을 보냈으며, 목요일에는 팀별 시연을, 금요일에는 전사 투표를 거쳐 최고의 성과를 뽐내는 축제로 마무리했습니다. 시차별 지원 채널과 헬프데스크가 상시 운영되었고 팀별 참여 현황판이 투명하게 공유되었습니다.
쏟아지는 코드 앞에서 멈춰 선 검사 시스템
결과는 표면적으로 대단한 성공처럼 보였습니다.
재정비 주간이 끝날 무렵, 매니저를 포함한 엔지니어링 조직의 92%가 최소 1건 이상의 에이전트 작성 PR을 제출했습니다. 1인당 약 250달러, 총 20만 달러에 가깝게 책정한 토큰 예산 중 실제로는 약 70%를 썼습니다. 2026년 4월 기준으로 Affirm 전체 PR 중 60% 이상이 ‘에이전트 지원 PR’이 되었습니다. Affirm 기술 블로그는 이 수치를 두고 ‘Claude가 전부 작성했을 가능성이 매우 높은 PR’이라고 밝혔습니다. 4개월 전만 해도 0%에 가까웠던 수치입니다. 주간 단위로 실제 시스템에 합쳐진 PR의 양도 1년 전보다 58%나 늘어났습니다.
하지만 이 실험의 실제 가치는 화려한 숫자가 아니라, 급격한 변화 속에서 무엇이 망가졌는지를 솔직하게 드러낸 데 있었습니다. 코드를 찍어내는 속도가 폭발적으로 빨라지자, 그동안 겨우겨우 버티고 있던 개발 파이프라인의 숨은 병목들이 동시에 터져 나왔습니다.
가장 먼저 사람이 막혔습니다. 전사 설문조사에서 응답자의 약 40%가 질문지에 항목이 없었는데도 ‘코드 리뷰’를 병목으로 직접 적어 냈습니다. 설문에서 가장 많이 꼽힌 병목이었습니다. 에이전트가 코드를 눈 깜짝할 사이에 만들어 PR을 올리자, 이를 읽고 검토해야 하는 동료들의 작업함에 PR이 며칠씩 방치되는 일이 벌어졌습니다.
그다음은 검사 시스템이었습니다. Affirm의 단위 기능 테스트는 p75(실행 4번 중 3번이 끝나는 시간) 기준으로 약 8분이 걸렸고, 실제 운영 환경과 유사한 임시 환경을 띄워 전체 흐름을 확인하는 종단간(E2E) 회귀 테스트는 무려 100분 이상이 걸렸습니다. 코드를 뚝딱 고치고 바로 확인하려는 에이전트에게 100분이라는 대기 시간은 너무나 길었습니다.
도구를 연결하는 방식에서도 문제가 생겼습니다. 개발자들은 에이전트를 사내 시스템과 연결하기 위해 수십 개의 MCP를 쓰고자 했습니다. MCP는 AI 모델이 외부 시스템의 데이터나 도구에 접근할 수 있게 돕는 오픈 프로토콜 규격입니다. 하지만 외부 연동이 늘어날수록 보안 위험이 커졌기 때문에 중앙 검토 창구에 과부하가 걸렸습니다. 실제 현장에서는 MCP보다 오히려 오래된 방식인 CLI 도구가 훨씬 더 안정적으로 돌아갔습니다. CLI는 검은 콘솔 화면에서 글자 명령어를 직접 입력해 프로그램을 실행하는 인터페이스입니다.
문서의 파편화도 발목을 잡았습니다. 10년 넘게 쌓인 수많은 기술 사양서가 여러 플랫폼에 흩어져 있었습니다. 숙련된 개발자는 경험으로 이를 찾아갔지만, 에이전트는 전후 맥락이 깔끔하게 정리되어 있지 않으면 양질의 코드를 만들지 못합니다. 플랫폼마다 MCP 지원이 제각각이라 엔지니어가 직접 문서를 찾아 에이전트에게 넘겨 주는 일이 잦았습니다.
결국 한계에 도달했습니다. 빠른 로컬 검사 환경이 없던 개발자들이 검사 결과를 확인하기 위해 무작정 코드를 중앙 CI 시스템으로 밀어 올렸기 때문입니다. Buildkite라는 빌드 도구의 대기열이 끝없이 치솟았고, 재정비 주간이 끝나고 몇 주 뒤, 누적된 부하를 견디지 못한 Affirm의 내부 테스트 격리(quarantine) 서비스와 CI 파이프라인 전체가 가동을 멈추고 말았습니다. 코드를 빠르게 찍어내는 에이전트가 기존 인프라의 모든 마찰 지점을 증폭시켜 거대한 장벽으로 만든 것입니다.
병목을 고치는 조직만이 속도를 얻습니다
Affirm은 실패를 확인한 뒤 투자의 방향을 전면 수정했습니다. 핵심은 코드를 만들어 내는 에이전트 자체가 아니라, 만들어진 코드를 검증하는 주변 환경을 고치는 일이었습니다.
회사는 재정비 주간을 이끈 한시적 전담 팀을 상설 팀으로 전환했습니다. 이 팀은 사내 도구의 연동을 체계적으로 관리하고, 토큰 비용을 통제하며, 기술 지원을 상시 제공하는 역할을 맡았습니다. 아키텍처 그룹은 흩어져 있던 기술 문서와 도메인 지식을 중앙으로 모아 에이전트가 참조하기 좋은 구조로 정리하는 일을 맡았습니다.
특히 망가졌던 검사 환경을 대대적으로 개조했습니다. CI가 실패했을 때 그것이 코드 자체의 잘못인지, 원래 가끔 실패하던 불안정한 테스트 때문인지, 아니면 인프라 시스템 오류인지 자동으로 분류하는 체계를 구축하기 시작했습니다.
실제 내부 파이프라인은 이런 방식으로 돌아갔을 것입니다. Buildkite의 오류 로그를 분석하고, 내부 테스트 격리 서비스에 등록된 불안정한 테스트 목록을 대조하며 다른 작업들의 인프라 상태를 함께 살폈을 것입니다. 만약 등록된 불안정한 테스트 문제라면 격리 처리를 하고, 인프라 장애라면 에이전트의 헛수고를 막기 위해 재시도를 중단시켰을 것입니다. 오직 코드 자체의 결함으로 확인된 로그만 에이전트에게 전달해 수정하게 함으로써 검사 시스템의 붕괴를 막는 차단기 역할을 수행하도록 설계했을 것입니다.
또한 Affirm은 완전히 새로운 위험을 막기 위한 실험도 시작했습니다. 하나의 에이전트가 코드와 테스트 코드를 한 번에 작성하면, 에이전트가 원래 요구 사항을 잘못 이해했더라도 자신이 짠 잘못된 논리에 맞춰 테스트 코드를 만들기 때문에 테스트가 정상적으로 통과해 버리는 문제가 생깁니다. 겉으로는 완벽해 보이지만 실제로는 결함이 있는 코드가 배포될 위험이 커지는 것입니다.
이를 해결하기 위해 Affirm은 여러 모델을 활용하는 독립 검증 시스템을 시범 운영하고 있습니다. 이 시스템 역시 사람이 사전에 승인한 초기 계획 문서를 바탕으로 돌아갔을 것입니다. 코드를 작성한 에이전트의 대화 기록은 배제한 채, 사람이 승인했던 초기 요구 조건과 최종 코드 변경점만을 다른 독립적인 AI 모델에게 전달했을 것입니다. 이를 통해 코드가 원래 의도에 맞게 짜였는지 객관적으로 교차 검증하고, 그 결과를 동료 검토자에게 체크리스트 형태로 제공하여 사람이 일일이 수천 줄의 코드를 눈으로 뒤지는 리뷰 부담을 덜어 주었을 것입니다.
도구보다 중요한 것은 일하는 구조의 재설계입니다
Affirm의 일주일 실험은 개발 조직뿐만 아니라 AI 도입을 고민하는 모든 기업 리더에게 분명한 교훈을 남깁니다.
첫째, 때로는 점진적인 권장보다 강제적인 전환이 훨씬 빠르고 강력합니다. Affirm이 일주일 동안 정규 업무를 멈추지 않았다면 몇 달이 걸려도 800명의 행동을 바꾸지 못했을 것입니다. 제품 출시를 미루더라도 새로운 방식을 학습할 수 있도록 시간을 보장해 준 경영진의 결단이 구성원들에게 실패해도 괜찮다는 심리적 안전감을 주었습니다.
둘째, 도구의 도입은 병목을 없애는 것이 아니라 이동시킬 뿐입니다. 코드를 작성하는 시간이 0에 수렴하면, 그동안 눈에 띄지 않던 검토, 확인, 문서화, 인프라의 마찰력이 거대한 병목으로 떠오릅니다. 생산성 향상은 에이전트 도구를 쥐여주는 순간이 아니라, 폭발적으로 쏟아지는 산출물을 소화할 수 있도록 검증 파이프라인을 뜯어고칠 때 비로소 완성됩니다.
셋째, 명확한 단 하나의 표준을 먼저 제시해야 합니다. 자유라는 이름으로 각자 도구를 찾아 쓰게 두면 조직은 파편화되고 격차는 벌어집니다. 기본 경로를 명확히 깔아 주되, 필요한 팀이 스스로 적응할 여지를 열어 두는 설계가 대규모 확산의 열쇠였습니다.
Affirm은 여전히 다음 단계의 숙제를 풀고 있습니다. 사람이 작성하지 않은 코드가 너무 빠르게 쌓이면서 전체 시스템의 덩치가 커지고, 시스템의 세부 동작을 깊이 이해하는 인간 엔지니어의 통찰력이 옅어지는 2차 문제를 경계하며 지켜보고 있습니다. AI 에이전트를 조직에 도입한다는 것은 단순히 최신 소프트웨어를 구독하는 일이 아닙니다. 그것은 일하는 방식, 검증하는 체계, 그리고 책임을 나누는 구조 전체를 다시 설계하는 일입니다.
출처
Affirm Tech Blog (Medium) — How Affirm Retooled its Engineering Organization for Agentic Software Development in One Week — https://medium.com/affirmengineering/how-affirm-retooled-its-engineering-organization-for-agentic-software-development-in-one-week-1fd35268fde6 — 2026-04-27 (Daniel Martin)