Faire — 사내 구축 시스템을 걷어내고 클라우드 에이전트로 주간 PR 처리량을 2배로 늘리다

1. 왜 이 사례인가

소프트웨어 개발 조직이 AI 코딩 에이전트를 도입할 때 흔히 겪는 성장통이 있습니다. 개발자 개인의 로컬 IDE에서 시작해 점차 백그라운드 자동화로 확장을 꾀하지만, 로컬 머신의 메모리·컴퓨팅 한계와 터미널 관리의 복잡성에 부딪힙니다. 일부 기술력 있는 기업들은 자체 클라우드 에이전트 인프라를 직접 구축(In-house)하는 길을 택하지만, 서버 프로비저닝, 샌드박스 보안, 도구 연동, 개발자 경험(DX) 유지보수에 막대한 엔지니어링 공수를 빼앗기며 ‘배보다 배꼽이 더 큰’ 상황에 직면합니다.

북미의 대표적인 B2B 도소매 이커머스 플랫폼 Faire의 전환 여정은 바로 이 지점에서 매우 명확한 기준점을 제시합니다. Faire는 자체 호스팅 인프라 기반으로 운영하던 사내 백그라운드 에이전트 시스템인 ‘사무라이(Samurai)‘를 과감히 폐기하고 상용 클라우드 에이전트 플랫폼인 Cursor로 전면 전환했습니다.

공개된 성과는 압도적입니다. 독립된 가상머신(VM) 환경을 갖춘 클라우드 에이전트를 대규모로 병렬 가동함으로써 주간 PR 처리량을 2배(2x)로 끌어올렸으며, 전체 엔지니어링 산출량은 2~3배에 육박하고 있습니다. 특히 팀 전체가 매달려 18개월이 걸릴 것으로 예상되었던 대규모 레거시 프론트엔드 마이그레이션(MobX → React 네이티브 상태 관리)을 단 1명의 엔지니어와 에이전트 플릿(fleet)의 협업으로 압축해 냈습니다.

아울러 개발자의 수동 프롬프트 입력 없이도 자동으로 동작하는 25개 이상의 상시 자동화(Cursor Automations)를 구축하여, 버그 트리아지·CI 자동 복구·코드 리뷰 라우팅 등에서 주당 2,000회 이상의 자율 에이전트 실행을 프로덕션에서 안정적으로 소화하고 있습니다. 엔지니어링 팀이 자체 인프라 관리 부담을 털어내고, 복잡한 개발 환경(Gradle, Bazel, AWS 권한 분리) 위에서 에이전트에게 온전한 개발 자율성을 부여한 대표적 모범 사례입니다.

2. Problem

Faire의 엔지니어링 조직이 직면했던 기술적·운영적 난관은 크게 세 가지였습니다.

2.1 로컬 에이전트 병렬화의 한계와 사내 인프라(Samurai)의 유지보수 부채

개발자 개인의 로컬 노트북에서 여러 에이전트를 동시에 실행하면 CPU와 메모리 자원이 순식간에 고갈됩니다. 터미널 창 10개를 띄워두고 각 작업의 진행 상태를 일일이 추적하는 것 자체가 또 다른 비효율적 노동이 되었습니다.

Faire의 루크 비어링(Luke Bjerring) 수석 엔지니어에 따르면, 회사는 이를 해결하기 위해 자체 호스팅 서버 위에서 동작하는 ‘사무라이(Samurai)‘라는 사내 백그라운드 에이전트 시스템을 직접 구축해 운용했습니다. 그러나 자체 서버 인프라를 유지하는 것은 엄청난 비용과 리소스를 요구했습니다. 서버 부트스트래핑, 머신 관리, 복잡한 가상화 인프라 유지보수를 위해 고급 엔지니어링 인력이 소모되었고, 정작 최종 고객에게 비즈니스 가치를 전달하는 본연의 제품 개발에 집중하지 못하는 본말전도가 발생했습니다.

2.2 이원화된 빌드 도구와 복잡한 엔터프라이즈 개발 환경

에이전트가 코드를 단순히 작성하는 것을 넘어, 빌드·테스트·검증까지 완결짓는 진정한 자율성을 갖추려면 사람 엔지니어와 동일한 완전한 개발 환경이 제공되어야 합니다. 그러나 Faire의 개발 환경은 고도로 파편화되어 있었습니다.

백엔드와 프론트엔드가 서로 분리된 저장소(separate repos)에 존재.
내부 패키지 의존성은 Gradle과 Bazel이라는 서로 다른 빌드 시스템으로 복잡하게 얽혀 있음.
사내 서비스 및 인프라 접근 권한이 서로 다른 AWS 자격 증명(credentials)으로 엄격히 격리되어 있음.

이처럼 복잡한 환경에서는 에이전트가 실행 포드나 컨테이너를 띄우더라도 필요한 도구체인을 설치하고 사내 내부 서비스에 접근하는 환경 구성(onboarding) 단계에서 빈번하게 실패할 수밖에 없었습니다.

2.3 18개월 규모의 레거시 마이그레이션과 반복적 잡무 병목

소매업체(retailer)가 매일 사용하는 핵심 웹 프론트엔드 애플리케이션 전반에 걸쳐 과거의 상태 관리 라이브러리인 MobX가 깊게 침투해 있었습니다. 이를 현대적인 React 네이티브 상태 관리로 전환하는 작업은 비즈니스 로직에 대한 섬세한 검증이 요구되면서도, 파일 수백 개를 일일이 수정해야 하는 전형적인 ‘고비용 노동 집약적’ 과제였습니다. 전체 엔지니어링 팀이 매달려도 최소 18개월이 소요될 것으로 추산되었습니다.

동시에 Slack 중심의 업무 환경에서 채널마다 쏟아지는 버그 리포트 분류, PR 생성 후 CI 파이프라인 실패 원인 분석, 코드 리뷰어 지정 및 라벨링과 같은 일상적이고 반복적인 엔지니어링 운영 업무가 개발자들의 집중 개발 시간을 지속적으로 잠식하고 있었습니다.

확인된 사실: 로컬 자원 제약 및 다중 터미널 관리 병목, 사내 에이전트 시스템 Samurai의 인프라 유지보수 부담, Gradle/Bazel/격리된 AWS 권한으로 인한 환경 구성 난제, 18개월 예상의 MobX 마이그레이션 부담, Slack 버그 트리아지 및 CI 실패 수동 대응에 따른 공수 소모.

3. Solution

Faire는 사내 시스템 Samurai를 과감히 걷어내고, 관리형 클라우드 에이전트 인프라와 상시 자동화 파이프라인을 유기적으로 결합했습니다.

3.1 관리형 클라우드 인프라로의 전환

Faire는 엔지니어가 인프라 구축 대신 제품 개발에 전념할 수 있도록 Cursor의 관리형 클라우드 인프라를 도입했습니다. 클라우드 에이전트는 로컬 자원 제약 없이 격리된 독립 가상머신(VM)에서 구동되므로, 개발자는 로컬 워크트리나 원격 터미널 세션 10개를 번거롭게 오갈 필요 없이 깔끔한 단일 대시보드에서 다수의 동시 에이전트를 직관적으로 지휘할 수 있게 되었습니다.

3.2 에이전트 주도 온보딩(Agent-led Onboarding)과 개발 환경 표준화

복잡한 Gradle·Bazel 빌드 환경과 AWS 권한 장벽을 해소하기 위해 에이전트 주도 온보딩 기능을 적용했습니다. 에이전트가 각 리포지토리를 스스로 탐색하여 필요한 도구체인과 의존성을 파악한 뒤, 팀이 버전 관리할 수 있는 환경 설정 파일(environment configuration)을 자동으로 생성하도록 했습니다. 엄격한 보안 통제가 필요한 워크플로의 경우 Dockerfile을 통해 개발 환경을 명시적으로 선언 및 관리했습니다.

이를 통해 에이전트는 독립 VM 환경에서 의존성을 내려받고, 사내 서비스와 통신하며, 코드를 빌드하고 테스트를 통과시키는 완전한 실행 루프를 사람의 개입 없이 스스로 완결할 수 있게 되었습니다.

3.3 디자인 시스템 연동과 Slack 기반 에이전트 호출

디자인 시스템 연동 (Playground): Faire 디자이너들이 사용하는 사내 도구 ‘Playground’(Figma 디자인을 React 코드로 변환) 서버를 클라우드 에이전트가 직접 띄울 수 있도록 구성했습니다. 에이전트는 React 컴포넌트를 코딩한 후, 디자이너가 브라우저에서 확인할 수 있도록 작업 결과 화면을 비디오 데모 영상으로 녹화하여 검토용으로 첨부합니다.
Slack 기반 인라인 트리거: 엔지니어링 대화가 집중되는 Slack 채널 스레드에서 @cursor를 호출하면, 대화 맥락이 클라우드 에이전트로 즉각 전달됩니다. 개발자는 여러 도구를 오가지 않고도 몇 분 뒤 에이전트가 생성한 완성된 PR을 받아보게 됩니다.

3.4 25개 이상의 상시 자동화 (Cursor Automations)

사람의 수동 프롬프트 입력 없이 이벤트 기반으로 자율 실행되는 25개 이상의 자동화를 구축하여 주당 2,000회 이상의 에이전트 런을 가동했습니다.

Slack 버그 트리아지: 지정된 Slack 채널의 장애 및 버그 보고를 실시간 모니터링하여, 클라우드 에이전트가 즉시 코드베이스를 조사하고 수정 PR을 생성한 뒤 요약 보고서를 회신.
PR 자동 치유 (PR Auto-healing): PR 생성 후 CI 파이프라인이 깨지면 자동화가 즉시 트리거되어 빌드·테스트 로그를 분석하고, 수정 커밋을 푸시하여 PR을 정상화.
지능형 PR 라우팅: 생성된 PR의 작성자, 코드 변경 규모, 위험도를 정량 판별하여 맞춤형 코드 리뷰 워크플로로 자동 분기 배정.

3.5 대규모 마이그레이션 오케스트레이터 ‘Swarm’

MobX에서 React 네이티브 상태 관리로의 전환을 위해 ‘Swarm’이라는 전담 에이전트 조율 파이프라인을 구축했습니다.

코드베이스 전체를 스크래핑하여 MobX가 사용된 모든 지점을 전수 탐색한 뒤 S3에 작업 목록을 적재.
Swarm 오케스트레이터가 S3 목록을 순차적으로 읽어 독립된 가상머신에서 실행되는 Cursor 클라우드 에이전트들에게 마이그레이션 태스크를 분할 할당.
한 에이전트가 작업을 완결하고 테스트를 통과하여 PR을 머지하면, Swarm이 즉시 다음 대상 파일을 에이전트 플릿에 연속적으로 디스패치.

3.6 플랫폼 엔지니어링 속도 혁신 (빌드 프리뷰 샌드박스)

블레어 맥알파인(Blair McAlpine) 시니어 플랫폼 엔지니어는 모든 PR마다 원격 인터랙티브 샌드박스를 띄워주는 프리뷰 도구를 개발할 때, Cursor의 계획 모드(Plan mode)를 활용했습니다. 단계별 계획을 수립하고 각 단계를 PR 단위로 나눈 뒤 클라우드 에이전트에 작업을 위임했습니다. 에이전트는 백그라운드에서 2시간 동안 자율 동작하며 5개의 연속된(stacked) PR을 생성했고, 수 주가 걸릴 것으로 예상되었던 도구 개발을 단 하루 만에 완성했습니다.

확인된 사실: Samurai 폐기 및 관리형 인프라 전환, 에이전트 주도 온보딩 및 Dockerfile 기반 환경 구성, Figma-Playground 비디오 데모 생성, Slack @cursor 연동, 25개 이상 상시 자동화와 주당 2,000+ 무인 런, S3 기반 MobX 마이그레이션 오케스트레이터 Swarm, 계획 모드를 통한 2시간 5개 스택 PR 생성 및 1일 내 프리뷰 도구 완성.

4. Impact

Faire가 달성한 생산성 지표와 리소스 절감 효과는 다음과 같습니다.

4.1 핵심 정량 성과

지표	도입 이전	클라우드 에이전트 도입 이후
주간 PR 처리량 (Throughput)	기준선	2배 (2x) 증가 (엔지니어링 산출량 2~3배 근접)
MobX 프론트엔드 마이그레이션 공수	전담 팀 기준 18개월 소요	엔지니어 1명 + 에이전트 플릿으로 완료
무인 자율 에이전트 실행 건수	-	주당 2,000회 이상 (2,000+/week)
상시 운영 자동화 파이프라인 수	-	25개 이상 활성화
빌드 프리뷰 샌드박스 개발 기간	수 주(weeks) 예상	1일 미만 (<1 day) (에이전트 2시간 동안 5개 스택 PR 생성)

4.2 조직적 운영 효과

자체 에이전트 호스팅 인프라(Samurai)를 유지보수하기 위해 낭비되던 엔지니어링 리소스를 완전히 회수하여 비즈니스 핵심 가치 개발로 재배치했습니다. 엔지니어링 생산성이 2~3배로 폭증함에 따라, 개발 조직 내부의 병목이 코딩에서 인접 기획·디자인·배포 프로세스로 이동하기 시작했으며 회사는 확보된 생산성 여력을 바탕으로 보다 도전적인 제품 개발 과제에 인력을 재배치하고 있습니다.

5. Insight

자체 인프라 구축(In-house)의 유혹을 경계해야 합니다. 대규모 에이전트 실행 환경을 사내에서 직접 구축하는 것은 초기에는 매력적으로 보이지만, 격리 샌드박스 유지, 개발자 경험(DX), 버전 관리, 확장성에 막대한 유지보수 비용을 초래합니다. 엔지니어링 리소스는 인프라 유지가 아닌 최종 사용자 비즈니스 가치 창출에 투입되어야 합니다.

에이전트의 완성도는 ‘실행 가능한 환경(Environment)‘이 결정합니다. 코드를 그럴듯하게 작성하는 것과, 빌드 도구(Gradle/Bazel)를 돌려 사내 의존성을 풀고 테스트를 통과시키는 것은 차원이 다른 문제입니다. 에이전트가 독자적인 VM 환경에서 의존성과 권한을 완전히 통제할 수 있을 때 비로소 사람의 개입 없는 완결된 작업이 가능해집니다.

대규모 레거시 기술 부채 해소의 표준 공식이 재정의되었습니다. 수개월 이상 팀 전체를 소모시키던 프론트엔드 상태 관리 마이그레이션을 ‘S3 작업 큐 + 에이전트 플릿(Swarm)’ 구조로 분할 실행함으로써, 엔지니어 1명이 오케스트레이터 역할을 맡아 엔드투엔드로 완결할 수 있음을 입증했습니다.

개발자 트리거에서 ‘상시 무인 자동화’로의 전환이 진정한 레버리지를 만듭니다. 개발자가 채팅창에 프롬프트를 쳐서 작업을 시키는 단계를 넘어, Slack 버그 신고 감지, CI 실패 시 자동 픽스 커밋 푸시, PR 라우팅 등 이벤트 기반의 상시 자동화(Automations)가 뒷받침될 때 주당 2,000회라는 대규모 무인 자동화가 현실화됩니다.

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

6.1 S3 기반 마이그레이션 오케스트레이터 ‘Swarm’의 동시성 제어 및 상태 머신

근거: 원문에서는 스크래퍼가 코드베이스 내 모든 MobX 사용처를 탐색해 S3에 목록을 저장하고, Swarm이 이를 읽어 개별 격리 VM의 클라우드 에이전트에 작업을 위임하며, 한 작업이 완료되어 PR이 머지되면 다음 작업을 디스패치했다고 설명합니다.

실제 프로덕션 환경에서 수백 개에 달하는 프론트엔드 파일의 마이그레이션을 안정적으로 수행하려면 단순 순차 루프 이상의 동시성 및 충돌 제어 메커니즘이 필수적입니다. Swarm은 파일 간 의존성 그래프(AST 기반 import 분석)를 사전에 파악하여, 상호 참조가 없는 독립된 모듈군을 클라우드 에이전트에 병렬 할당했을 것입니다.

S3 버킷 내 작업 큐는 todo/, in-progress/, review/, done/ 형태의 접두사(prefix) 상태 머신으로 관리되었을 공산이 큽니다. 에이전트가 작업을 시작할 때 S3의 조건부 쓰기(Conditional Put)를 이용해 분산 락(Distributed Lock)을 획득하고 작업 브랜치를 분기합니다. 만약 다른 에이전트의 선행 머지로 인해 베이스 브랜치 충돌이 발생하면, 에이전트 VM 내부에서 자동으로 git rebase main을 시도하고 컴파일 및 단위 테스트(Bazel/Jest)를 재실행하도록 설계되었을 것입니다. 사람이 PR을 수동 승인하는 병목을 최소화하기 위해, MobX 데코레이터 제거 및 React Hook 대체 로직의 구문 트리 동등성 검증 테스트를 통과한 PR은 자동으로 머지 큐로 라우팅되도록 가드레일을 결합했을 것으로 추정됩니다.

6.2 다중 AWS 권한 및 Bazel/Gradle 캐싱을 결합한 클라우드 VM 프로비저닝

근거: 원문에서는 백엔드와 프론트엔드가 분리된 리포지토리에 있고, Gradle과 Bazel로 패키지 의존성이 관리되며, 엄격히 분리된 AWS 자격 증명 뒤에 보호되어 있어 환경 구성이 매우 까다로웠다고 명시합니다.

에이전트가 세션을 시작할 때마다 수 기가바이트에 달하는 사내 내부 패키지와 Bazel 빌드 캐시를 처음부터 다운로드한다면 세션 준비에만 수십 분이 소요되어 실시간 사용이 불가능해집니다. 따라서 Faire는 사내 빌드 인프라와 Cursor 환경 사이에 원격 빌드 캐시(Remote Build Cache) 및 전용 미러 레지스트리를 연결했을 가능성이 높습니다.

VM 부팅 시 Cursor의 사전 구성 스크립트(setup script)가 팀별 사전 빌드 스냅샷(prebuilt snapshot)을 마운트하고, AWS IAM 역할(AssumeRole)을 통해 에이전트에게 필요한 최소 권한의 임시 토큰을 세션별로 안전하게 주입하는 구조를 취했을 것입니다. 아울러 Bazel의 샌드박스 빌드 특성을 유지하면서 에이전트가 로컬에서 실행 결과를 검증할 수 있도록, 컨테이너 내부 Docker 소켓 바인딩이나 소스 트리 격리 설정을 환경 설정 파일에 템플릿화하여 표준 배포했을 것으로 추론됩니다.

6.3 Slack 기반 CI 실패 자동 복구(Auto-healing)의 진단 루프

근거: 원문에서는 CI 실패 시 Cursor Automations가 즉시 동작하여 원인을 조사하고, 수정 코드를 푸시하며, PR을 업데이트한다고 명시합니다. 또한 Slack 중심 문화에서 @cursor 호출이 일상화되어 있습니다.

이 자동 복구 파이프라인은 GitHub Actions 또는 사내 CI 시스템의 실패 웹훅(Webhook)에서 시작될 것입니다. 웹훅 페이로드가 수신되면 자동화 러너는 1) 실패한 CI 단계의 원시 콘솔 로그를 파싱하여 스택 트레이스와 컴파일 에러 라인을 추출하고, 2) 실패한 PR 브랜치를 체크아웃한 클라우드 에이전트 VM을 즉시 기동합니다.

에이전트는 단순히 에러 메시지만 보고 코드를 고치는 것이 아니라, VM 내에서 실패했던 동일한 Bazel/Gradle 테스트 명령어를 로컬로 재실행하여 실패를 재현(reproduce)합니다. 이후 코드 수정을 적용하고 로컬 테스트가 통과(Green)하는 것을 확인한 뒤에만 원격 브랜치로 git push를 수행하도록 엄격한 루프를 강제했을 것입니다. 작업이 완료되면 PR 코멘트 및 원본 Slack 스레드에 “CI 실패 원인(의존성 누락 또는 타입 불일치) 분석 요약 및 커밋 번호”를 자동으로 멘션하여 개발자에게 피드백을 전달하는 관제 구조로 구현되었을 것입니다.

7. Sources

Primary: Cursor Blog (customers), “Faire doubles PR throughput with Cursor Cloud Agents”, 2026-05-26 발행.
URL: https://cursor.com/blog/faire
Key individuals quoted: Luke Bjerring (Principal Engineer at Faire), Blair McAlpine (Senior Engineer, Platform team at Faire).
Data status: 주간 PR 처리량 2배 증가, MobX 18개월 마이그레이션의 1인+플릿 압축, 25개 이상 상시 자동화, 주당 2,000회 이상 무인 에이전트 실행, 2시간 만에 5개 스택 PR 생성 등 수치는 Faire 엔지니어링 팀이 공식 고객 사례 연구를 통해 직접 검증 및 공개한 프로덕션 실측 데이터에 기반함.