Faire, 1인과 Swarm이 끝낸 18개월치 작업

요약

• Faire는 자체 에이전트 인프라를 접고 클라우드 에이전트를 도입했습니다.
• 18개월짜리 대규모 코드 전환을 엔지니어 1명이 에이전트 무리로 마쳤습니다.
• 도구 유지 관리 부담을 덜고 온전한 실행 환경을 주는 편이 효과적입니다.

자체 구축 인프라가 남긴 뜻밖의 청구서

소프트웨어 개발 조직이 인공지능 코딩 에이전트를 도입할 때 겪는 일반적인 흐름이 있습니다. 개발자 개인의 로컬 편집기 안에서 쓰기 시작해, 점차 여러 작업을 백그라운드에서 동시에 돌리는 자동화로 나아갑니다. 하지만 개인 컴퓨터의 연산 능력과 메모리 한계에 부딪히고, 작업 열 개를 확인하느라 터미널 창 열 개를 번갈아 오가는 번거로움이 생겨납니다. 기술 역량이 뛰어난 기업은 이 문제를 풀기 위해 클라우드 서버에 자체 에이전트 구동 환경을 직접 만들기도 합니다.

북미 도매 전자상거래 마켓플레이스를 운영하는 Faire도 같은 선택을 내렸습니다. Faire의 수석 엔지니어(Principal Engineer)인 Luke Bjerring은 자체 호스팅 서버에서 백그라운드로 작동하는 사내 에이전트 시스템 Samurai를 만들어 운영했다고 밝혔습니다. 하지만 직접 만든 시스템은 곧 다른 문제를 만들었습니다. 전용 서버를 유지하고, 머신을 부트스트래핑하며, 사내 개발자 경험을 관리하는 데 막대한 비용과 공수가 들어갔습니다. 숙련된 엔지니어들이 사용자에게 비즈니스 가치를 주는 제품 개발 대신 인프라 유지 관리에 매달려야 했습니다.

결국 Faire는 Samurai를 그만두기로 결정했습니다. 자체 인프라를 걷어내고 관리형 클라우드 에이전트 플랫폼인 Cursor를 도입했습니다. 2026년 5월 26일 Cursor 공식 블로그에 공개된 고객 사례는 이 결정 뒤에 나타난 구체적인 변화를 다루고 있습니다.

복잡한 개발 환경과 18개월짜리 기술 부채

Faire 엔지니어링 조직이 겪던 기술적 걸림돌은 인프라 유지 관리 부담뿐만이 아니었습니다. 에이전트가 코드를 단순히 작성하는 수준을 넘어 빌드와 테스트까지 혼자 마치려면 사람 개발자와 똑같은 환경이 주어져야 합니다. 하지만 Faire의 개발 환경은 고도로 파편화되어 있었습니다.

백엔드와 프런트엔드 코드는 서로 다른 저장소로 분리되어 있었습니다. 사내 패키지 의존성은 Gradle과 Bazel이라는 두 가지 서로 다른 빌드 시스템에 복잡하게 얽혀 있었습니다. 게다가 사내 인프라와 서비스 접근 권한은 별도의 AWS 자격 증명 뒤에 엄격하게 격리되어 있었습니다. 이런 구조에서는 에이전트가 가상 환경을 띄우더라도 필요한 도구를 내려받거나 사내 시스템에 접근하다가 설정 단계에서 멈추기 일쑤였습니다.

그사이 레거시 기술 부채는 계속 쌓여 있었습니다. 소매업체(retailer)가 쓰는 대규모 웹 애플리케이션 프런트엔드 전반에는 구형 상태 관리 라이브러리인 MobX가 깊게 박혀 있었습니다. 이 코드를 React 기본 상태 관리로 전환하는 작업은 수백 개 파일에 걸친 비즈니스 로직을 하나하나 검증해야 하는 노동 집약적인 일이었습니다. 팀 전체가 매달려도 최소 18개월이 걸릴 것으로 예상되었습니다.

여기에 Slack 중심의 사내 소통 문화 속에서 채널로 쏟아지는 버그 보고 조사, 풀 리퀘스트(PR)에서 터지는 지속적 통합(CI) 실패 원인 분석, 코드 리뷰어 지정 같은 일상적인 잡무가 개발자들의 집중 시간을 끊임없이 갉아먹고 있었습니다.

환경 통제와 자율 실행 파이프라인

Faire는 엔지니어가 인프라 관리 대신 제품 개발에 집중할 수 있도록 Samurai를 중단하고, 격리된 가상 컴퓨터 환경인 가상 머신(VM)을 제공하는 Cursor 클라우드 에이전트 기반으로 개발 파이프라인을 재구성했습니다. 클라우드 에이전트는 로컬 컴퓨터의 자원 한계가 없는 독립된 VM에서 작동하므로, 개발자는 더 이상 여러 갈래의 작업 디렉터리인 로컬 워크트리를 번거롭게 관리하거나 열 곳에 달하는 원격 환경에 일일이 접속할 필요가 없습니다. 대신 하나의 화면 안에서 동시에 여러 에이전트를 지휘하며 작업합니다.

가장 먼저 푼 문제는 복잡한 빌드 환경 설정이었습니다. Faire는 에이전트 주도 온보딩을 활용했습니다. Cursor가 저장소를 분석해 필요한 도구 체인과 의존성을 파악한 뒤, 팀이 버전 관리할 수 있는 환경 설정 파일을 자동으로 만듭니다. 더 엄격한 통제가 필요한 작업에는 Dockerfile로 명확한 실행 환경을 정의했습니다. 이를 통해 에이전트는 격리된 VM 안에서 Gradle과 Bazel 빌드를 돌리고, 필요한 AWS 자격 증명을 거쳐 테스트를 통과시키는 완전한 실행 루프를 사람 개입 없이 완주할 수 있게 되었습니다.

실제 구현 과정에서는 세션마다 수 기가바이트에 달하는 패키지와 빌드 결과물을 매번 새로 내려받지 않도록 원격 빌드 캐시를 적극 활용했을 가능성이 높습니다. VM이 뜰 때 사전 빌드된 스냅샷을 마운트하고, AWS의 임시 토큰 발급 방식을 이용해 최소한의 권한을 동적으로 주입하는 방식으로 시작 시간을 단축했을 것입니다.

개발 워크플로도 일상적인 협업 도구 안으로 깊숙이 들어왔습니다. Faire 디자이너들은 Figma 디자인 시스템을 React 컴포넌트로 변환할 때 Playground라는 사내 도구를 사용합니다. 클라우드 에이전트는 이 Playground 서버를 스스로 띄우고 React 컴포넌트를 작성한 뒤, 컴포넌트가 실제로 화면에서 작동하는 모습을 영상으로 녹화해 디자이너가 바로 확인할 수 있도록 전달합니다. 또한 엔지니어들이 기술적인 대화를 나누는 Slack 스레드에서 @cursor를 부르면, 에이전트가 대화 맥락을 그대로 전달받아 조사를 마친 뒤 완성된 PR을 가져옵니다.

사람이 프롬프트를 넣지 않아도 돌아가는 25개 이상의 자동화

Faire의 변화에서 눈에 띄는 대목은 사람이 일일이 프롬프트를 입력하지 않아도 작동하는 상시 자동화(Cursor Automations)입니다. 현재 Faire에는 25개 이상의 자동화가 켜져 있으며, 매주 2,000회 이상 에이전트를 자율적으로 실행합니다.

대표적인 자동화 흐름은 세 가지입니다. 첫째는 Slack 버그 분류 자동화입니다. 전용 채널로 들어오는 버그 보고를 상시 감시하다가, 버그가 올라오면 클라우드 에이전트가 코드베이스를 조사해 수정 PR을 열고 분석 요약을 전달합니다. 둘째는 PR 자가 치유입니다. PR에서 CI가 실패하면 자동화가 즉시 실패 로그를 파악하고 수정 커밋을 푸시해 PR을 갱신합니다. 셋째는 지능형 PR 라우팅입니다. PR의 작성자와 코드 크기, 위험도를 분석해 알맞은 코드 리뷰 흐름으로 코드를 보냅니다.

실제 CI 자가 치유는 빌드 시스템에서 실패 웹훅을 받는 즉시 시작되었을 것입니다. 에이전트가 로그에서 오류 위치를 파악하고, 격리된 VM에서 동일한 빌드 명령을 재현해 로컬 테스트가 통과하는 것을 확인한 뒤에야 수정 커밋을 원격에 반영하는 방식으로 동작했을 가능성이 높습니다.

18개월짜리 전환을 혼자 마친 Swarm 오케스트레이션

Faire는 팀 전체가 18개월 동안 매달려야 할 것으로 예상됐던 MobX 마이그레이션 과제를 Swarm이라는 에이전트 조율 체계로 풀어냈습니다.

전체 구조는 명확하게 분업화되었습니다. 먼저 스크레이퍼가 대규모 소매업체 웹 앱 코드베이스 전체를 훑어 MobX가 쓰인 모든 지점을 찾아낸 뒤 작업 목록을 Amazon S3에 저장합니다. Swarm은 이 목록을 순서대로 읽으며 격리된 VM에서 실행되는 Cursor 클라우드 에이전트에 세부 마이그레이션 작업을 맡깁니다. 에이전트가 담당 코드의 상태 관리를 React 기본 방식으로 고치고 테스트를 통과해 PR을 머지하면, Swarm은 곧바로 다음 작업을 에이전트 무리에 띄웁니다.

MobX 마이그레이션 Swarm 구조

이 대규모 전환은 수백 개 파일이 얽혀 있는 만큼, 실제로는 파일 간 의존성 관계를 미리 분석해 서로 충돌하지 않는 모듈 묶음을 에이전트들에 병렬로 할당했을 것입니다. S3 작업 큐 역시 단계별 상태를 나누어 관리하고, 앞선 에이전트의 머지로 충돌이 발생하면 최신 코드를 반영해 단위 테스트를 다시 수행하는 안전장치를 두었을 것으로 보입니다.

그 결과 엔지니어 한 명이 에이전트 무리를 조율하며 전체 마이그레이션을 끝마쳤습니다. 18개월치 팀 작업이 1인의 오케스트레이션 업무로 압축된 셈입니다.

사내 플랫폼 도구 제작에서도 비슷한 속도 변화가 나타났습니다. Faire 플랫폼 팀의 시니어 엔지니어인 Blair McAlpine은 PR마다 원격 인터랙티브 샌드박스를 띄워 주는 빌드 프리뷰 도구를 만들 때 Cursor의 계획 모드를 활용했습니다. 전체 요구사항을 단계별 계획으로 나누고 각 단계를 개별 PR 하나로 범위를 정한 뒤 에이전트에 실행을 맡겼습니다. 클라우드 에이전트 하나가 2시간 동안 연속으로 다섯 개의 쌓인(stacked) PR을 생성했고, 완성까지 몇 주가 걸릴 것으로 예상했던 플랫폼 도구를 하루가 채 지나지 않아 만들어 냈습니다.

빌드 프리뷰 도구의 계획 모드

측정된 성과와 사람의 역할 변화

Faire가 사내 시스템을 걷어내고 클라우드 에이전트로 전환한 결과는 분명한 수치로 나타났습니다.

매주 생성되고 머지되는 주간 PR 처리량은 기존 대비 2배로 늘었습니다. 코드 생산을 넘어선 엔지니어링 전체 산출량은 2~3배에 가까워졌습니다. 팀 전체의 1년 반 치 업무였던 대규모 프런트엔드 마이그레이션은 에이전트 무리를 이끈 엔지니어 단 한 명이 완수했습니다. 25개 이상의 상시 자동화 파이프라인은 매주 2,000회가 넘는 무인 에이전트 실행을 안정적으로 처리하고 있습니다. 몇 주짜리 플랫폼 도구 개발은 단 하루 만에 끝났습니다.

이 변화로 엔지니어들의 일상도 달라졌습니다. Samurai 서버를 관리하고 개발 환경 오류를 고치느라 소모되던 고급 엔지니어들의 역량이 본래 목적인 제품 기능 개발로 온전히 돌아왔습니다. Faire 엔지니어링 조직의 병목은 코딩에서 기획과 디자인, 배포 같은 앞뒤 단계로 옮겨 갔습니다.

Faire는 이렇게 새로 생긴 여력을 지금의 조직 규모 안에서 더 야심 찬 제품 과제를 추진하는 데 다시 배분하고 있습니다.

기업 리더와 실무자가 가져갈 교훈

Faire의 사례는 인공지능 전환을 고민하는 조직에게 중요한 기준점을 제시합니다.

첫째, 모든 것을 직접 만들려는 사내 인프라의 유혹을 경계해야 합니다. 초기에는 자체 시스템을 구축하는 것이 보안이나 맞춤화 측면에서 매력적으로 보일 수 있습니다. 하지만 가상화 환경 관리와 도구 연동, 개발자 경험 지원에 들어가는 운영 부채는 결국 비즈니스 핵심 제품에 투입되어야 할 엔지니어링 역량을 갉아먹습니다. 인프라 운영 비용을 덜어내고 엔지니어가 비즈니스 가치에 집중하게 만드는 것이 실질적인 생산성을 얻는 지름길입니다.

둘째, 에이전트의 성패는 코딩 실력이 아니라 온전한 실행 환경이 결정합니다. 그럴듯한 코드를 생성하는 것과 복잡한 사내 빌드 시스템에서 의존성을 내려받고 격리된 VM 안에서 테스트를 끝까지 통과시키는 것은 전혀 다른 문제입니다. 독립된 환경에서 자격 증명과 빌드 도구를 완전히 다룰 수 있을 때만 에이전트가 사람의 손을 타지 않고 끝까지 작업을 마칠 수 있습니다.

셋째, 진정한 생산성 확장은 채팅창 프롬프트가 아니라 무인 자동화에서 나옵니다. 개별 개발자가 인공지능과 대화하며 코드를 한 줄씩 다듬는 방식만으로는 조직 차원의 획기적인 도약을 만들기 어렵습니다. Slack 채널의 오류를 감시하고, 실패한 CI 파이프라인을 스스로 치유하며, 작업 큐를 통해 대규모 기술 부채를 자율적으로 해소하는 상시 파이프라인을 갖출 때 비로소 2,000회 이상의 무인 실행과 두 배의 처리량이 가능해집니다.

---

출처

Cursor Blog (customers) — Faire doubles PR throughput with Cursor Cloud Agents — https://cursor.com/blog/faire — 2026-05-26