Affirm — 엔지니어 800명이 일주일 동안 평소 개발을 멈추고 에이전트 워크플로로 갈아탄 방법

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을 1건 이상 제출한 엔지니어링 조직 비율(매니저 포함)	92%	Retooling Week 종료 시
그 주의 토큰 사용 예산	약 20만 달러 (엔지니어 1인당 약 250달러)	사전 설정
실제 토큰 사용액	예산의 약 70%	매일 모니터링
에이전트 지원 PR 비율	60% 이상 (넉 달 전 거의 0)	2026년 4월
주간 병합 PR 수	전년 대비 58% 증가	2026년 4월

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

4.2 드러난 병목

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

변경 리뷰: 전사 설문에서 가장 많은 불만이 쏟아진 단계였습니다. 전체 응답자의 약 40%가 주관식 설문에서 묻지도 않았는데 이 문제를 스스로 꼽았습니다. PR이 리뷰 단계에서 며칠씩 묶이는 일이 빈번했고, 쏟아져 나오는 PR 물량을 기존의 수작업 리뷰 방식으로는 감당하기 어려웠습니다.
CI 속도와 안정성: 단위 테스트 실행 시간은 p75 기준 약 8분 수준이었지만, 임시 테스트 환경에서 돌아가는 전체 E2E 회귀 테스트는 100분이 넘게 걸렸습니다. 에이전트 기반 개발의 핵심인 “변경, 검증, 수정, 재검증”의 빠른 피드백 루프를 염두에 두고 만든 인프라가 아니었습니다.
도구 연동: 엔지니어들은 수십 개의 MCP를 통해 에이전트를 사내 시스템 곳곳에 연결하고 싶어 했습니다. 연동을 중앙에서 통제하는 것은 필수적인 보안 원칙이었으나, 요청이 한꺼번에 쏟아지면서 검토 체계가 마비되었습니다. 연동 지점이 늘어날수록 보안 위험도 함께 커져 신중한 검토가 불가피했습니다. 게다가 실제 작업에서는 CLI가 MCP보다 더 안정적인 경우가 많았습니다. 표준화된 설정 기준과 명확한 담당 부서, 서비스 수준 합의(SLA)가 마련되지 않은 상태에서 무분별한 연동은 개발을 돕기는커녕 오히려 큰 짐이 되었습니다.
문서 접근성: Affirm에는 지난 10년 넘게 축적된 기술 및 제품 명세가 여러 문서 저장소와 소스 코드 곳곳에 흩어져 있었습니다. 숙련된 개발자는 경험으로 찾아갈 수 있지만, 에이전트가 정확한 결과물을 내려면 정리되고 일원화된 맥락 정보가 필수적입니다. MCP 연동을 지원하는 시스템과 그렇지 않은 시스템이 뒤섞여 있어, 엔지니어가 직접 문서를 찾아 에이전트에게 쥐여 주는 번거로운 작업을 반복해야 했습니다.
CI 부하: 로컬에서 즉시 검증할 환경이 부족하다 보니, 엔지니어들은 결과물을 확인하기 위해 코드를 CI에 바로 밀어 넣었습니다. 수많은 에이전트가 앞다투어 PR을 올리자 Buildkite에 병목이 발생해 대기 시간이 급증했고, 급기야 Retooling Week가 끝난 몇 주 뒤에는 사내 테스트 격리(quarantine) 서비스와 메인 CI 파이프라인 전체가 마비되는 사태까지 벌어졌습니다.

원문은 이 상황을 “에이전트 코딩은 개발 파이프라인에 있던 모든 마찰을 키웠다”는 한 문장으로 압축합니다. 코드 작성이 눈 깜짝할 사이에 이뤄지자, 수작업 리뷰와 파편화된 문서, 취약한 로컬 테스트 환경, 느린 CI 파이프라인 등 이전에는 조금 불편해도 넘어가던 요소들이 업무 전체를 멈추게 하는 치명적인 장애물로 드러난 것입니다.

확인된 사실: 위 표의 수치, “에이전트 지원” PR의 원문 설명, 주 중반의 인식 변화, 리뷰 병목(약 40% 자발 언급), 단위 테스트 p75 약 8분·E2E 100분 이상, MCP 연동 요청 폭증과 보안 검토 부담, CLI의 상대적 안정성, 문서 분산, Buildkite 대기 증가, 몇 주 뒤 테스트 격리 서비스와 CI 파이프라인 중단.

5. Insight

강제 장치가 점진적 확산보다 훨씬 빨랐습니다. 원문이 꼽은 첫 번째 교훈은, 일반 업무 회의를 전면 중단하고 경영진이 강력하게 뒷받침한 전용 주간이 몇 달에 걸친 점진적 전파보다 단 5일 동안 비교할 수 없이 많은 도입을 이끌어 냈다는 사실입니다. 엔지니어들에게 새로운 도구를 익힐 충분한 시간을 마련해 주었고, 조직 구성원 전체가 같은 출발선에서 시작할 수 있었습니다. 특히 제품 출시 일정을 미루겠다는 결정을 경영진이 전사 차원에서 먼저 공표한 점이 이러한 과감한 시도를 가능하게 만든 핵심 열쇠였습니다.

도구의 성능만큼 지원 조직의 존재가 중요합니다. 전담 엔지니어 그룹이 표준 경로를 미리 닦아 두고, 실시간 지원 채널을 운영하며 현장의 피드백을 즉각 반영했습니다. 원문은 이 팀이 없었다면 도구 사용 권한만 던져 주고 위키 문서 하나 올려둔 채 각자 알아서 잘 쓰기만을 바라는 수준에 그쳤을 것이라고 회고합니다. Affirm은 행사를 성공적으로 이끈 이 임시 조직을 상설 전담 팀으로 전환해 도구 연동 관리, 상시 지원, 비용 통제를 계속 맡겼습니다.

명확한 기본 도구를 정하고 그 위에 워크플로를 설계해야 합니다. 엔지니어들에게 절실했던 것은 어떤 도구를 써야 하는지, 올바른 작업 흐름은 무엇인지, 그리고 어디서부터 시작해야 하는지에 대한 분명한 가이드였습니다. 기본값을 명확히 제시하되 각 팀이 상황에 맞게 조정할 여지를 남겨 둔 유연성이 원문에서 꼽은 가장 성공적인 결정 중 하나였습니다.

코드 생성이 빨라지면 병목은 필연적으로 검증 단계로 이동합니다. 이번 프로젝트에서 드러난 문제들은 대부분 에이전트 자체의 성능이 아니라 리뷰, CI, 문서, 연동 같은 주변 환경에서 비롯되었습니다. 따라서 Affirm은 이후의 리소스를 검증 파이프라인을 개선하는 데 가장 많이 집중했습니다. 빌드 실패의 원인이 코드 자체의 결함인지, 불안정한 테스트 때문인지, 아니면 인프라 문제인지를 자동으로 가려내고, 로컬 테스트 환경을 대폭 강화하며, 무거운 테스트들을 훨씬 빠르고 가벼운 계층으로 전환하는 작업을 진행하고 있습니다.

같은 세션이 작성한 코드와 테스트는 서로의 오류를 가려버릴 위험이 있습니다. 에이전트가 요구사항을 잘못 이해한 상태에서 구현 코드와 단위 테스트를 동시에 작성하면, 테스트는 오류 없이 통과하고 코드 커버리지도 완벽해 보이지만 실제 결함은 그대로 프로덕션에 배포됩니다. Affirm은 이러한 맹점을 막기 위해 PR diff를 초기 인수 기준과 대조하고 복수의 서로 다른 모델을 교차 활용해 독립적으로 검증하는 시스템을 시범 운영하고 있습니다.

장기적으로 누적되는 2차 문제를 경계해야 합니다. 원문은 에이전트가 생성한 코드가 급증함에 따라 시간이 지나면서 코드베이스 비대화, 코드 리뷰 및 배포 병목, 사내 스킬과 컨텍스트 파일의 무분별한 난립, 실제 운영 시스템에 대한 개발자들의 이해도 저하 같은 복합적인 문제가 발생할 수 있다고 경고합니다.

복제 조건과 한계. 이 접근법은 경영진이 비즈니스 출시 일정을 기꺼이 늦출 수 있는 결단을 내릴 수 있고, 사전 준비 기간에 핵심 인력을 전담으로 투입할 수 있으며, 사내에 이미 도구의 효용을 검증한 소수의 선도 그룹이 존재하는 조직이어야 효과를 볼 수 있습니다. 아울러 60%와 58%라는 수치는 Affirm 엔지니어링 블로그가 자체적으로 공개한 결과이며, 58% 증가는 주간 병합 PR 수라는 단순 양적 지표입니다. Affirm 스스로 밝혔듯이, 코드 리뷰와 CI 인프라가 뒷받침되지 않는다면 PR 수의 증가는 개발 속도의 향상이 아니라 새로운 병목의 시작이 될 뿐입니다.

한 줄 요약: 코딩 에이전트를 전사적으로 안착시키려면 하나의 표준 도구와 명확한 사람 확인 지점을 갖춘 기본 워크플로를 구축하고, 일주일을 온전히 비워 전 직원이 몰입하게 하되, 필연적으로 뒤따라오는 코드 리뷰·CI·문서 병목을 해결할 인프라 투자를 반드시 병행해야 합니다.

6. 원문에 없는 추정 (구현 가설)

6.1 계획 산출물에서 PR까지 이어지는 작업 단위 추적

근거: 원문은 계획 스킬이 요구사항을 구조화된 계획과 범위가 분명한 작업으로 나누고, 작업 하나가 에이전트 세션 하나와 PR 하나에 대응하며, 작업마다 별도 worktree에서 병렬로 진행한다고 설명합니다. Retooling Week에는 팀별·단계별 도입률과 열린 PR 대비 병합 PR을 측정했고, 팀별 에이전트 PR 순위표를 운영했습니다. 에이전트 지원 PR은 “Claude가 전부 작성했을 가능성이 매우 높은” PR로 설명합니다.

계획 스킬의 산출물은 작업별 목표와 수정 범위, 완료 조건이 명시된 마크다운 문서 같은 파일 형태로 코드 저장소 내부나 엔지니어의 로컬 작업 공간에 저장되었을 가능성이 높습니다. 엔지니어가 이 계획을 승인하면 작업 파일 하나당 독립된 worktree와 작업 브랜치가 자동으로 생성되고, 에이전트 세션은 해당 작업 명세 파일을 읽어 들이며 개발을 시작했을 것입니다. 조직별·단계별 도입 현황과 에이전트 PR 순위표를 실시간으로 집계하기 위해서는 생성된 PR이 에이전트 표준 워크플로를 거친 것인지 구분할 명확한 메타데이터가 필요합니다. 커밋 메시지에 Claude Code가 자동으로 남기는 Co-authored-by 표기나 사내 플러그인이 생성 시점에 자동으로 달아 주는 PR 라벨을 판별 기준으로 삼았을 것으로 보입니다. “가능성이 매우 높은”이라는 원문의 신중한 표현을 감안하면, 이 판정은 개발자가 수동으로 등록한 데이터가 아니라 이러한 식별 단서를 바탕으로 사후 추정한 통계였을 가능성이 높습니다. 나아가 작업이 초기 계획 단계를 정상적으로 거쳤는지까지 검증하기 위해 해당 작업 명세 파일의 고유 ID를 PR 템플릿 본문에 자동으로 포함하는 방식을 취했을 것으로 추정됩니다.

6.2 CI 실패를 원인별로 나눠 에이전트에게 돌려주는 분류 단계

근거: 원문은 검증 단계에서 에이전트가 CI 빌드 로그를 가져와 실패 원인을 맞춰 보고 수정안을 내며 CI를 통과할 때까지 반복한다고 설명합니다. 동시에 빌드 실패가 코드 탓인지, 불안정한 테스트 탓인지, 인프라 문제인지를 지금은 사람이 조사해야 하며 이를 자동으로 분류하는 작업을 진행하고 있다고 밝힙니다. Buildkite 부하로 대기 시간이 늘었고, 테스트 격리 서비스와 CI 파이프라인이 멈춘 일도 있었습니다.

실패 분류 시스템은 Buildkite의 원시 실패 로그와 사내 테스트 격리 서비스의 불안정 테스트 목록, 그리고 동일한 시점에 실행된 다른 빌드 파이프라인들의 성공 여부를 교차 분석하는 방식으로 구현되었을 것으로 보입니다. 실패한 테스트 케이스가 이미 격리 서비스의 불안정 테스트 목록에 올라가 있다면 “불안정 테스트”, 같은 시각 여러 브랜치에서 동일한 환경 배포 단계가 일제히 실패했다면 “인프라”, 두 조건 모두에 해당하지 않고 이번 커밋에서 변경된 코드와 직접 연관된 테스트가 깨졌다면 “코드” 문제로 나누는 식입니다. 이 분류를 바탕으로 에이전트에게는 “코드”로 명확히 판별된 실패 건에 대해서만 로그를 전달해 수정을 시도하게 하고, 불안정 테스트는 자동 재실행이나 격리 처리를 거치며, 인프라 장애 시에는 에이전트의 무의미한 재시도를 즉시 차단해야 합니다. 원인을 알지 못하는 에이전트가 무제한으로 빌드를 재시도할 경우 CI 시스템 전체에 부하가 집중되므로, 이 자동 분류 파이프라인은 인프라 붕괴를 막기 위한 핵심적인 보호 장치로 설계되었을 가능성이 높습니다.

6.3 인수 기준과 diff를 대조하는 독립 검증

근거: 원문은 같은 세션에서 구현과 테스트를 함께 만들면 서로의 오류를 확인해 줄 수 있다고 지적하고, PR diff를 인수 기준과 대조하며 여러 모델로 독립 검증하는 시스템을 시범 운영하고 있다고 설명합니다. 계획 단계에서는 사람이 승인한 구조화된 계획이 먼저 만들어집니다.

독립 검증 파이프라인에서 기준으로 삼는 인수 조건은 코드를 실제로 구현한 세션이 아니라, 그 앞단에서 사람이 직접 검토하고 승인한 계획 단계의 원본 산출물에서 추출했을 가능성이 높습니다. 구현 세션이 사후에 생성한 작업 요약본을 기준으로 삼을 경우, 코드를 짤 때 발생한 잘못된 가정이 검증 단계에도 고스란히 복제되기 때문입니다. 검증을 담당하는 별도의 LLM은 구현 세션의 긴 대화 내역은 전혀 참조하지 않은 채, 원래의 인수 기준과 최종 PR diff, 그리고 관련 핵심 코드만을 입력받아 각 기준 항목을 diff가 실제로 충족하는지, 명세에 없는 불필요하거나 위험한 변경이 포함되지는 않았는지를 객관적으로 판정했을 것입니다. 구현에 사용한 모델과 다른 독립된 모델을 검증에 배치함으로써 단일 모델이 반복하기 쉬운 체계적 오류나 편향을 효과적으로 걸러낼 수 있습니다. 이 분석 결과는 PR 코멘트 형태로 등록되어 동료 리뷰어가 우선적으로 확인해야 할 체크리스트 역할을 했을 것으로 보입니다. 코드 리뷰가 조직 전체의 가장 큰 병목으로 꼽혔던 만큼, 이 독립 검증 시스템은 리뷰어가 방대한 전체 코드를 처음부터 일일이 뜯어보는 대신 명세와 어긋나거나 의심스러운 지점부터 집중적으로 검토할 수 있도록 돕는 실질적인 보조 수단으로 활용되었을 것으로 추정됩니다.

7. 출처

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 — Sr. Director of Engineering, Developer Productivity)