Faire가 자체 시스템을 걷어낸 이유

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 핵심 정량 성과

4.2 조직적 운영 효과

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