Stripe가 에이전트 수백 개를 돌리다 localhost를 포기한 이유, 밤새 직접 돌려보니 납득됩니다

어젯밤 해커톤 룰이 하나 있었습니다. 저녁 8시에 개발을 위한 스펙과 하네스만 세팅하고, 아침 8시까지 키보드에서 손을 떼는 것. 12시간 동안 에이전트만으로 프로덕트를 완성하는 실험이었습니다.

이 실험을 통해 Stripe가 Minions 플랫폼을 공개하면서, 그리고 Ramp가 Inspect라는 자체 백그라운드 에이전트를 만든 후기를 안내하면서 “localhost는 끝났다”고 선언한 이유를 12시간 안에 전부 체감했습니다.

노트북에서 에이전트를 병렬로 띄우면 싸움이 시작된다

에이전트 여러 개가 한 머신에서 돌아가면 상태가 꼬입니다. 시크릿이 충돌하고, 포트가 겹치고, 머신이 슬립에 들어가는 순간 12시간 루프가 통째로 날아갑니다.

Stripe와 Ramp가 에이전트 아키텍처를 공개했을 때 공통점이 있었습니다. 둘 다 에이전트마다 독립 VM과 개발 컨테이너를 부여하는 구조를 택했습니다.

Stripe의 Minions는 “devbox”라 부르는 격리 환경에서 실행됩니다. 엔지니어가 사용하는 것과 동일한 머신 타입이지만, 프로덕션 리소스와 인터넷으로부터 완전히 격리되어 있습니다. 10초 만에 스핀업되며, git worktree 오버헤드 없이 병렬 태스크 실행을 지원합니다.

Ramp의 Inspect는 Modal Sandbox 위에 구축되었습니다. 각 세션이 Postgres, Redis, Temporal, RabbitMQ를 포함한 풀스택 개발 환경을 독립적으로 보유합니다. 세션 간 경합이 전혀 없고, 파일시스템 스냅샷 덕분에 거의 즉시 시작됩니다.

코딩 에이전트는 내 노트북과 내 집중력이 필요하지만, 백그라운드 에이전트는 둘 다 필요 없습니다. 실제로 밤새 돌리는 동안 머신 슬립 한 번에 전체 루프가 멈추는 걸 목격했습니다. 클라우드 VM에서는 이런 일이 일어나지 않습니다.

태스크를 순서대로 주면 쉬운 기능밖에 나오지 않는다

이번 해커톤에서 가장 뼈아팠던 지점입니다. 순차 실행으로 에이전트를 돌리면 단순한 CRUD는 나옵니다. 문제는 의존성이 생기는 순간입니다. 먼저 완성한 모듈을 뒤에 돌아가는 에이전트가 덮어쓰거나 충돌시키는 일이 반복됐습니다.

여기서 에이전트 플릿(fleet)과 에이전트 스웜(swarm)을 구분해야 합니다.

에이전트 플릿은 하나의 동일한 변경을 여러 저장소에 동시 적용할 때 쓰는 패턴입니다. Stripe가 주간 1,000개 이상의 PR을 머지할 수 있는 것도 이 구조 덕분입니다. 같은 마이그레이션, 같은 린트 수정을 수백 개 서비스에 한 번에 밀어넣는 방식입니다.

에이전트 스웜은 서로 다른 파트를 맡겨서 하나의 결과로 수렴시키는 패턴입니다. 프론트엔드, 백엔드, 테스트를 각각 다른 에이전트가 담당하고, PR 단위로 합치는 구조입니다.

순차가 아니라 병렬 실행 후 PR 단위로 합치는 구조가 아니면 복잡한 프로덕트는 만들 수 없습니다. 직접 돌려보니 병렬 + 머지 리뷰 조합이 순차 대비 완성도 차이가 확연했습니다.

Rate limit과 에이전트 간 소통은 프롬프트가 아니라 인프라로 풀어야 한다

12시간 루프에서 rate limit에 걸리지 않는 건 불가능했습니다. 거기에 에이전트가 만든 commit을 다른 에이전트가 리뷰하고, 스펙에서 모호한 부분을 자동으로 재판단하는 흐름까지 필요했습니다.

“시스템 프롬프트에 ‘파일 지우지 마’라고 쓰는 건 부탁이지 통제가 아니다”라는 표현이 있습니다. 정확히 맞는 말입니다.

Stripe는 이 문제를 실행 레이어에서 풀었습니다. Minions는 프로덕션 리소스와 인터넷 접근이 원천 차단되어 있어서, 권한 체크 없이도 안전하게 실행할 수 있습니다. 400개 이상의 MCP 도구를 “Toolshed”라는 내부 서버에 호스팅하고, 각 에이전트가 접근할 수 있는 도구 세트를 큐레이션합니다.

Ramp는 GitHub OAuth를 통해 PR이 반드시 실제 사용자 계정으로 생성되도록 설계했습니다. 앱 ID가 아닌 개인 계정으로 귀속되기 때문에, 리뷰 없이 코드가 머지되는 것을 구조적으로 방지합니다.

권한 범위를 실행 레이어에서 잠그고, 감사 로그를 남기고, 실패 반경을 제한하는 것. 이게 없으면 보안팀이 자율 에이전트를 승인할 리가 없습니다.

개인이 빨라져도 조직은 안 빨라질 수 있다

“거짓 정상(false summit)“이라고 부를 수 있는 현상이 있습니다. 코딩 에이전트를 도입하면 PR은 쏟아지는데 사이클 타임은 그대로입니다. 리뷰가 밀리고, CI가 깨지고, 머지 충돌이 쌓입니다.

해커톤에서도 에이전트가 코드를 빠르게 만드는 건 문제가 아니었습니다. 그 결과물을 합치고 검증하는 병목에서 시간이 전부 소모됐습니다.

Stripe는 이 병목을 자동화로 해소합니다. Minions는 에이전트 루프와 결정적 코드 연산을 인터리브하는 하이브리드 오케스트레이션을 사용합니다. 린팅, 테스트, git 연산이 항상 완료되도록 보장하면서도 에이전트의 창의성을 유지합니다. CI 테스트도 최대 2회 반복으로 제한해서, 끝없는 루프에 빠지지 않도록 설계했습니다.

Ramp는 머지된 PR 수를 핵심 성공 지표로 삼습니다. Inspect가 만든 PR의 50% 이상이 실제로 머지되고 있고, Inspect 자체의 80% 이상이 Inspect로 작성되었습니다.

백그라운드 에이전트가 PR 리뷰와 CI 실패 분석과 머지 충돌 해소를 사람보다 먼저 처리해야 조직 속도가 따라옵니다. “in the loop(직접 조작)“에서 “on the loop(결과만 검토)“로의 전환이 본질입니다.

승부처는 만드는 속도가 아니라 합치는 구조다

에이전트를 빠르게 만드는 건 이미 풀린 문제입니다. Stripe는 주간 1,000개 이상의 PR을, Ramp는 전체 PR의 절반 이상을 에이전트가 만들고 있습니다.

진짜 승부처는 에이전트가 만든 결과를 안전하게 합치는 시스템을 설계하는 것입니다. 격리된 실행 환경, 병렬 후 머지 구조, 인프라 수준의 거버넌스, 그리고 검증 자동화. 이 네 가지가 갖춰지지 않으면 에이전트는 빠른 장난감에 불과합니다.