Minions 소개: 사람이 지켜보지 않는 Stripe의 사내 코딩 에이전트
Minions는 결제 인프라 기업인 Stripe가 사내에서 직접 만든 코딩 에이전트로, 작업을 한 번에 끝내는 원샷(One-shot) 을 목표로 설계됐고 실행 내내 사람이 개입하지 않는 완전 무인(Fully Unattended) 방식으로 동작합니다. 전형적인 실행은 Slack 메시지 한 줄에서 시작해, CI를 통과하고 사람 리뷰를 받을 준비가 끝난 풀 리퀘스트(Pull Request, PR)로 끝납니다. 그 사이에 사람과의 상호작용은 없습니다. Stripe에서 매주 병합되는 PR 가운데 1,300개 이상이 미니언이 작성한 것이며, 사람이 코드 리뷰는 하지만 그 안에 사람이 직접 타이핑한 코드는 한 줄도 들어가지 않습니다.
이 숫자가 눈에 띄는 이유는 미니언이 다루는 코드베이스 때문입니다. Stripe의 코드베이스는 몇 개의 거대한 저장소에 걸쳐 수억 줄 규모이고, 그 코드는 연간 1조 달러가 훌쩍 넘는 결제 거래를 실제 운영 환경에서 처리합니다. 아무 제약이 없는 상태에서 프로토타입을 새로 만드는 일과, 규제와 금융 기관 연동이 얽힌 성숙한 코드베이스를 고치는 일은 난이도가 전혀 다릅니다.
이번에 살펴볼 두 편의 글은 Stripe의 Leverage 팀 소속 엔지니어인 Alistair Gray가 stripe.dev 블로그에 나눠 게재한 것입니다. 2026년 2월 9일에 올라온 Part 1은 엔지니어가 미니언을 어떻게 쓰는지를 다루고, 열흘 뒤인 2월 19일의 Part 2는 그 안쪽 구현을 설명합니다. Part 1이 "주당 1,000개 이상" 이라고 적었던 수치를 Part 2가 "주당 1,300개 이상, Part 1 시점의 1,000개에서 증가" 로 갱신했는데, 두 글 사이 열흘 동안 일어난 변화입니다.
Stripe 엔지니어들은 여전히 Claude Code나 Cursor 같은 도구로 에이전트와 함께 계획하고 협업합니다. 미니언이 채우는 자리는 그 옆입니다. Stripe가 가장 부족한 자원 중 하나로 꼽는 것이 개발자의 주의(attention)인데, 사람이 지켜보지 않아도 되는 에이전트는 그 주의를 나누지 않고도 작업을 병렬로 늘릴 수 있게 해 줍니다. 원문은 특히 온콜(on-call) 당번 기간에 여러 미니언을 동시에 띄워 자잘한 이슈를 한꺼번에 처리하는 사용 패턴을 언급합니다.
Part 1은 첫 문장에서 업계 상황을 이렇게 정리합니다. 에이전틱 코딩은 새롭고 흥미로운 것에서 "기본 요건(table stakes)" 으로 넘어갔고, 바탕 모델이 계속 좋아지면서 무인 코딩 에이전트도 가능성에서 현실이 되었다는 것입니다. 실제로 Jules처럼 클라우드에서 비동기로 동작하는 코딩 에이전트가 여럿 등장했고, 요청을 던져 두고 결과를 나중에 확인하는 방식 자체는 더 이상 새롭지 않습니다. 미니언이 그 흐름 안에서 구별되는 지점은 실행 환경과 오케스트레이션이 전부 사내 개발 인프라 위에 올라가 있다는 것입니다. Slack 스레드 하나가 곧 작업 지시서가 되고, 에이전트는 Stripe 엔지니어가 매일 쓰는 것과 같은 개발 머신에서 같은 린터와 같은 CI를 통과한 뒤 사내 PR 템플릿을 채워 내놓습니다. Part 1과 Part 2는 각각 그 흐름의 바깥쪽과 안쪽을 보여 줍니다.
왜 기성 코딩 에이전트를 쓰지 않고 직접 만들었는가
두 편의 글을 관통하는 전제는 Stripe 코드베이스의 특수성입니다. 백엔드 대부분이 Ruby로 작성돼 있는데 Rails를 쓰지 않고, 타입 검사에는 Sorbet을 사용합니다. 원문의 표현대로 상대적으로 흔치 않은 스택입니다. 여기에 더해 코드 전반이 Stripe 안에서만 쓰이는 수많은 자체 라이브러리에 의존하고 있어서, LLM 입장에서는 학습 데이터에서 본 적 없는 이름들이 계속 등장합니다.
이 조합이 왜 부담이 되는지는 LLM이 코드를 생성하는 방식을 생각해 보면 됩니다. 모델은 공개된 코드에서 관찰한 관례에 크게 기대는데, Ruby 코드의 상당 부분은 Rails 관례 위에 세워져 있습니다. Rails를 쓰지 않는 대형 Ruby 코드베이스, 그것도 자체 라이브러리와 Sorbet 타입 시그니처로 감싸인 코드베이스는 모델이 기댈 관례가 훨씬 얇습니다. 여기에 결제라는 도메인이 더해집니다. Stripe의 코드는 금융 기관과 얽힌 복잡한 실제 의존 관계, 그리고 규제와 컴플라이언스(Compliance) 의무를 지켜야 하므로, 그럴듯해 보이지만 관례를 벗어난 코드가 만들어 내는 비용이 일반적인 애플리케이션보다 큽니다.
LLM 에이전트는 제약이 적은 시스템을 맨바닥에서 만들어 내는 일에는 능숙합니다. 문제는 그 반대편입니다. 원문은 "Stripe 정도의 규모와 복잡도, 성숙도를 가진 코드베이스를 고쳐 나가는 일은 본질적으로 훨씬 어렵다" 고 적으면서, 사람도 이 저장소에서 유효한 변경을 하려면 정교한 멘탈 모델을 세워야 하는데 에이전트가 제한된 컨텍스트 윈도우 안에서 같은 직관과 도구 사용법을 익히게 만드는 것이 어려운 과제라고 설명합니다.
그래서 Stripe가 선택한 답은 에이전트를 위한 별도 환경을 새로 만드는 것이 아니라, 이미 사람 엔지니어를 위해 오랫동안 다듬어 온 개발 생산성 기반 위에 에이전트를 올리는 것이었습니다. 소스 관리, 개발 환경, 코드 생성, CI(Continuous Integration)까지 개발 수명주기 전 단계에 걸쳐 쌓아 둔 도구가 있었고, 미니언의 하네스(Harness)는 그 도구들과 촘촘히 통합됩니다. 두 글에 반복해서 나오는 문장이 이 선택을 요약합니다.
"사람에게 좋은 것은 LLM에게도 좋습니다."
"if it's good for humans, it's good for LLMs, too."
Slack 멘션 한 줄에서 시작하는 작업 요청
미니언을 시작하는 입구는 여러 개입니다. CLI와 웹 인터페이스도 제공되지만, 엔지니어들이 가장 자주 쓰는 곳은 Slack입니다. 변경 사항을 논의하던 스레드에서 Slack 앱을 태그하면 그 자리에서 미니언이 실행되고, 에이전트는 스레드 전체와 거기 걸린 링크를 컨텍스트로 함께 읽습니다. 아래는 원문이 예시로 든 실제 호출 메시지입니다.
메시지를 보면 어떤 저장소에서 작업할지, 관련 사내 문서가 어디 있는지, 무엇을 만들어야 하는지가 사람에게 설명하듯 자연어로 적혀 있습니다. 별도의 프롬프트 양식이 아니라 평소 팀원에게 일을 넘길 때 쓰는 문장 그대로입니다.
한편 Slack 말고도 사내 애플리케이션 곳곳에 미니언 호출 지점이 마련돼 있습니다. 사내 문서 플랫폼, 기능 플래그(feature flag) 플랫폼, 사내 티켓 UI가 모두 미니언과 연동됩니다. 대표적인 예가 불안정한 테스트(flaky test) 처리입니다. CI 시스템이 flaky test를 감지하면 자동으로 티켓이 생성되고, 그 티켓에는 미니언으로 고치라는 버튼이 함께 표시됩니다.
작업이 진행되는 동안, 그리고 끝난 뒤에도 엔지니어는 웹 UI에서 미니언이 내린 판단과 실행한 동작을 순서대로 확인할 수 있습니다. 아래 화면에서 왼쪽 열에는 에이전트의 서술과 도구 호출이 번갈아 쌓이고, 파일 읽기와 파일 편집이 각각 어떤 경로를 대상으로 일어났는지가 그대로 남습니다. 오른쪽 열에는 작업 디렉토리에서 변경된 파일 15개가 추가와 삭제 줄 수와 함께 나열되며, 상단에는 브랜치 이름과 커밋 해시, 그리고 풀 리퀘스트를 만드는 버튼이 놓여 있습니다.
작업을 마친 미니언은 브랜치를 만들고 CI에 푸시한 뒤, Stripe의 PR 템플릿을 따르는 풀 리퀘스트를 준비해 둡니다. 코드가 괜찮아 보이면 엔지니어가 PR을 열고 다른 엔지니어에게 리뷰를 요청합니다. 마음에 들지 않으면 추가 지시를 주고, 미니언이 갱신한 코드를 같은 브랜치에 다시 푸시합니다. 완료된 실행을 엔지니어가 직접 이어받아 수동으로 고치는 것도 가능합니다. Stripe가 북극성(North Star)으로 삼는 것은 사람이 쓴 코드가 한 줄도 들어가지 않은 PR이지만, 완전히 정확하지 않은 실행이라도 엔지니어가 집중해서 작업하기에 좋은 출발점이 된다는 것이 원문의 설명입니다.
이 사용 방식은 사람이 옆에서 지켜보는 코딩 도구와 여러 지점에서 갈립니다. 아래 표를 통해 4가지 차이를 알아볼 수 있습니다.
| 항목 | 사람이 지켜보는 에이전트 (Cursor, Claude Code) | Minions |
|---|---|---|
| 실행 위치 | 개발자의 IDE와 로컬 셸 | 사내 데브박스, QA 환경에 격리 |
| 실행 중 개입 | 중단, 재지시, 승인 프롬프트 | 없음, 시작과 PR 사이에 상호작용 없음 |
| 권한 처리 | 위험한 명령마다 사람 확인 | 확인 없이 전체 권한, 영향 범위가 데브박스 하나로 한정 |
| 오케스트레이션 | 도구를 가진 루프 | 블루프린트, 결정적 노드와 에이전트 노드의 조합 |
원문이 구체적으로 소개하는 사용 사례를 모아 보면 미니언이 어떤 일에 투입되는지가 드러납니다. Slack 예시로 등장한 작업은 사내 도구의 개발 환경 전용 화면을 새로 만들고 백엔드 엔드포인트를 몇 개 추가하는 것이었고, 티켓 연동 예시는 CI가 자동으로 잡아낸 flaky test 수정이었으며, Part 2에는 완전히 결정적인 변환 스크립트로는 처리할 수 없는 코드베이스 마이그레이션을 팀이 전용 블루프린트로 만들어 실행한 사례가 나옵니다. 세 가지 모두 무엇을 만들어야 하는지를 한 번에 적어 넘길 수 있을 만큼 범위가 또렷한 작업입니다.
10초 만에 준비되는 격리 개발 환경, 데브박스
Part 2는 무인 에이전트를 규모 있게 운영하려면 개발 환경이 세 가지 성질을 가져야 한다고 정리합니다. 병렬 실행이 가능할 것, 예측 가능할 것, 격리돼 있을 것입니다. 에이전트들이 서로의 변경에 간섭하면 그 충돌을 해소하는 데 토큰이 낭비되고, 완전 자율로 실행하려면 사람의 개인 자격 증명이 올라간 민감한 머신에서 파괴적인 동작을 할 수 없도록 구조적으로 막아 두어야 합니다.
그러나 개발자 노트북에서 이 세 가지를 동시에 만족시키기는 어렵습니다. 컨테이너나 git worktree가 도움이 되지만 둘을 결합하기가 까다롭고, 개발자 셸의 모든 권한을 그대로 가지면서 적절히 제약된 로컬 에이전트를 만드는 일 자체가 근본적으로 어렵다는 것이 원문의 진단입니다. 에이전트 실행 환경을 컨테이너로 분리하려는 시도는 커뮤니티에도 container-use 같은 사례가 소개된 적이 있습니다.
Stripe는 이 문제를 새로 풀지 않았습니다. 미니언을 Stripe 엔지니어가 원래 쓰던 표준 개발 환경인 데브박스(devbox) 위에서 그대로 실행합니다. 데브박스는 Stripe 소스 코드가 들어 있고 개발 중인 서비스가 돌아가는 AWS EC2 인스턴스이며, 사람이 작성하는 Stripe 코드 대부분도 SSH로 데브박스에 원격 연결된 IDE 안에서 만들어집니다. DevOps 용어로 데브박스는 "애완동물이 아니라 가축(cattle, not pets)" 에 해당합니다. 오래 아껴 쓰는 맞춤 장비가 아니라, 표준화돼 있어 언제든 교체할 수 있는 자원입니다.
많은 엔지니어가 작업 하나당 데브박스 하나를 쓰고, 한 사람이 대여섯 개를 동시에 띄워 두기도 합니다. 이런 사용 패턴이 성립하려면 새 박스를 만드는 일이 부담스럽지 않아야 하므로, Stripe는 데브박스가 10초 안에 준비되는 것을 목표로 삼고 미리 만들어 예열해 둔 풀(pool)을 유지합니다. 이 풀에서는 원문이 열거한 아래 준비 작업이 사용자의 요청보다 먼저 끝나 있습니다.
-
거대한 git 저장소 클론: 수억 줄 규모의 주요 저장소를 미리 받아 두고 최근 master 사본으로 유지합니다.
-
빌드와 타입 검사 캐시 예열: Bazel 캐시와 타입 검사(Type Checking) 캐시를 미리 채워 첫 빌드와 첫 타입 검사가 오래 걸리지 않게 합니다.
-
코드 생성 서비스 기동: 데브박스에서 상시 동작하는 코드 생성 서비스를 미리 띄워 둡니다.
10초가 지나면 주요 저장소 전체가 최근 master 사본으로 체크아웃된 상태가 되어, 곧바로 REPL을 열거나 테스트를 실행하거나 코드를 고쳐 타입 검사를 하거나 웹 서비스를 띄울 수 있습니다.
미니언에게 이 환경이 주는 가장 큰 이점은 격리입니다. 데브박스는 운영 환경 리소스와 인터넷에서 차단돼 있어 사람의 권한 확인 없이 에이전트를 실행해도 안전하고, git worktree처럼 Stripe 규모에서 감당하기 어려운 방식을 쓰지 않고도 병렬 실행을 얻습니다. 정리하면, 데브박스는 LLM 에이전트가 등장하기 훨씬 전에 사람을 위해 만들어진 인프라인데 그 성질이 그대로 에이전트에게 맞아떨어진 경우입니다.
에이전트 실행 환경 격리 더 알아보기
container-use: AI 코딩 에이전트를 위한 컨테이너 기반 개발 환경 - PyTorchKR 소개 글
OpenAI, Windows용 Codex의 안전한 샌드박스 구축 여정 공개 - AppContainer와 제한 토큰, 방화벽 조합
CubeSandbox: 60ms 안에 부팅되는 AI 에이전트용 하드웨어 격리 샌드박스 - PyTorchKR 소개 글
goose를 포크해 만든 하네스, 사람이 없다는 것을 전제로
데브박스가 기존 자산이었다면, 에이전트 하네스는 미니언을 위해 새로 만든 부분입니다. Stripe는 2024년 말에 Block의 오픈소스 코딩 에이전트인 goose (
Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 (feat. Block, Linux Foundation))를 사내에서 포크해 Stripe의 LLM 인프라에 맞게 고쳤습니다. goose는 널리 쓰인 초기 코딩 에이전트 중 하나였고, 이후 Stripe는 포크의 기능 개발 방향을 사람이 감독하는 도구가 아니라 미니언 쪽에 맞춰 갔습니다. 사람이 함께 일하는 용도는 이미 엔지니어들에게 제공 중인 Cursor와 Claude Code 같은 외부 도구가 충분히 채우고 있었기 때문입니다.
Part 1은 이 포크에서 무엇을 고쳤는지도 밝힙니다. 에이전트 루프와 결정적 코드가 번갈아 실행되도록 오케스트레이션 흐름을 다시 짜면서 git 조작, 린터, 테스트 실행 같은 단계를 결정적 코드 쪽에 두었고, 그 결과 에이전트의 창의성과 Stripe가 요구하는 단계를 반드시 거친다는 보장을 함께 얻으려 했습니다. 이 발상이 Part 2에서 블루프린트라는 이름으로 정리됩니다.
원문이 미니언의 가장 독특한 지점으로 꼽는 것은 감독하는 사람의 부재입니다. 시중의 로컬 코딩 에이전트는 대개 엔지니어가 어깨너머로 지켜보는 상황에 최적화돼 있어서, 중단(interruptibility)이나 사람이 입력하는 명령으로 실행을 시작하고 방향을 트는 기능이 핵심을 이룹니다. 미니언은 그 기능들을 쓸 수 없습니다. 대신 반대편에서 얻는 것이 있는데, 격리된 데브박스 안이라면 에이전트가 저지를 수 있는 실수의 영향 범위(blast radius)가 데브박스 하나로 한정되므로 확인 프롬프트 없이 전체 권한으로 실행해도 됩니다.
하네스 설계 자체를 다루는 자료를 더 보고 싶다면 커뮤니티에 정리된 장시간 자율 코딩을 위한 에이전트 하네스 설계와 Learn Harness Engineering 강의 소개가 함께 읽기 좋습니다. 모델과 하네스의 조합이 코딩 성능을 어떻게 가르는지는 Artificial Analysis의 코딩 에이전트 벤치마크에서 수치로 확인할 수 있습니다.
goose와 에이전트 하네스 더 알아보기
goose GitHub 저장소 - Stripe가 포크한 Block의 오픈소스 코딩 에이전트
goose 공식 문서 - 확장(Extension)과 MCP 연동, 설정 방법
Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 - PyTorchKR 소개 글
블루프린트, 워크플로우의 결정성과 에이전트의 유연성을 한 실행 안에
Part 2는 Stripe의 개발 흐름에 맞춘 작은 최적화가 여럿 있었다고 하면서, 그중 미니언 구현에 더 근본적인 것으로 드러난 하나를 따로 다룹니다. Stripe가 블루프린트(Blueprint) 라고 부르는 오케스트레이션 방식입니다. 원문은 Anthropic이 정리한 워크플로우와 에이전트의 구분에서 출발합니다. 워크플로우(Workflow) 는 고정된 단계 그래프로 동작하는 LLM 시스템으로, 각 노드가 전체 목표 중 좁게 정의된 부분을 맡고 노드 사이의 실행 순서는 미리 정해진 간선이 통제합니다. 반면 에이전트(Agent) 는 도구를 가진 루프에 가까워서, LLM이 도구 호출 결과를 보고 다음에 무엇을 할지 스스로 판단합니다.
블루프린트는 코드로 정의한 워크플로우이면서, 개별 노드가 결정적(Deterministic) 코드일 수도 있고 특정 작업에 집중한 에이전트 루프일 수도 있습니다. 원문의 비유를 빌리면 블루프린트는 "결정적 코드와 엮인 에이전트 스킬의 모음" 이며, 결과적으로 결정적 코드 노드와 자유롭게 진행되는 에이전트 노드가 뒤섞인 상태 기계(State Machine)의 모습을 띱니다.
미니언을 구동하는 블루프린트에는 "Implement task", "Fix CI failures" 처럼 넓은 재량이 주어진 에이전트 노드가 있고, "Run configured linters", "Push changes" 처럼 LLM을 아예 호출하지 않고 코드만 실행하는 결정적 노드가 있습니다. 위 그림에서 구름 모양이 에이전트 노드, 사각형이 결정적 노드입니다. 린트 오류를 고치는 에이전트 노드와 린터를 실행하는 결정적 노드가 서로를 오가며 루프를 이루고, 그 아래에서 브랜치를 푸시한 뒤 CI 실패를 고치는 경로로 이어집니다.
| 구분 | 워크플로우 | 에이전트 | 블루프린트 |
|---|---|---|---|
| 실행 구조 | 고정된 단계 그래프, 노드마다 좁은 역할 | 도구를 반복 호출하는 단일 루프 | 코드로 정의한 그래프, 노드마다 결정적 코드 또는 에이전트 루프 |
| 다음 단계 결정 | 미리 정의된 간선 | LLM이 도구 호출 결과를 보고 판단 | 노드 종류에 따라 갈림 |
| 얻는 것 | 결정성 | 예상하지 못한 상황에 대한 유연성 | 한 실행 안에서 둘 다 |
이렇게 나눠 두는 실익은 비용과 신뢰성 양쪽에 걸쳐 있습니다. "실행이 끝나면 항상 변경분에 린트를 실행한다" 처럼 미리 예상할 수 있는 작은 결정을 코드로 정해 두면 규모가 커질수록 토큰과 CI 비용이 절약되고, 에이전트가 틀릴 기회 자체가 줄어듭니다. 원문은 이를 "LLM을 제한된 상자에 넣는 것" 이라고 표현하면서 그 효과가 쌓여 시스템 전체의 신뢰성으로 돌아온다고 정리합니다.
블루프린트가 순수한 에이전트 루프와 갈라지는 지점은 실행의 재현성입니다. 도구를 가진 루프 하나로 전부 처리하면 린트를 실행할지 말지, 브랜치를 언제 푸시할지까지 모델의 판단에 맡겨지기 때문에, 같은 작업을 두 번 실행해도 거쳐 간 단계가 달라질 수 있습니다. 반대로 전부 고정된 워크플로우로 짜면 예상하지 못한 상황이 나왔을 때 그래프 밖으로 나갈 방법이 없습니다. 블루프린트는 예상할 수 있는 단계만 그래프로 고정하고, 예상할 수 없는 부분에만 에이전트 노드를 배치하는 절충입니다.
블루프린트는 서브에이전트의 컨텍스트 엔지니어링(Context Engineering) 수단이기도 합니다. 노드 단위로 도구를 제한하거나, 시스템 프롬프트를 바꾸거나, 대화 컨텍스트를 그 하위 작업에 필요한 만큼만 남겨 단순화하는 조작이 블루프린트 구조 위에서 이뤄집니다. 팀마다 자기 목적에 맞는 블루프린트를 따로 만들 수도 있어서, 완전히 결정적인 코드 변환 스크립트(Codemod)로는 처리할 수 없는 까다로운 LLM 보조 마이그레이션을 블루프린트로 인코딩한 사례가 있다고 원문은 언급합니다. 작업마다 실행 구조를 직접 짜는 접근은 커뮤니티에 소개된 Claude Code 동적 워크플로우와도 문제 의식이 닿아 있습니다.
워크플로우와 에이전트 오케스트레이션 더 알아보기
Building Effective Agents - Anthropic이 정리한 워크플로우와 에이전트의 구분, 원문이 참조하는 글
12-Factor Agents: 운영 환경에서 신뢰할 수 있는 LLM 에이전트를 만들기 위한 12가지 원칙 - PyTorchKR 소개 글
Claude Code 동적 워크플로우: 작업마다 하네스를 직접 짜는 병렬 오케스트레이션 - PyTorchKR 소개 글
컨텍스트 수집 1: 디렉토리를 따라 조건부로 붙는 규칙 파일
Stripe 규모의 코드베이스에서 아무 안내 없이 풀어 놓은 에이전트는, 원문의 표현대로 린터가 잘 갖춰져 있더라도 모범 사례를 따르거나 적절한 라이브러리를 골라 쓰는 데 어려움을 겪습니다. CLAUDE.md나 AGENTS.md ( AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준) 같은 에이전트 규칙 파일 형식은 에이전트가 디렉토리 구조를 훑어 나가는 동안 코드베이스에 대한 지식을 자동으로 얻게 해 주는 장치입니다.
문제는 저장소 크기입니다. 무조건 적용되는 전역 규칙을 늘리면 에이전트가 일을 시작하기도 전에 컨텍스트 윈도우가 규칙으로 가득 차기 때문에, Stripe는 무조건 규칙을 매우 아껴 쓰고 거의 모든 규칙을 특정 하위 디렉토리나 파일 패턴에 한정해 둡니다. 에이전트가 파일 시스템을 이동하다가 해당 경로에 들어가면 그때 규칙이 자동으로 붙는 방식입니다.
규칙 파일을 에이전트마다 중복해서 두는 대신 사람이 쓰는 도구와 같은 컨텍스트를 읽게 하자는 것이 Stripe의 방침이었습니다. 그래서 조건부 적용을 지원하는 Cursor의 규칙 형식으로 표준화하고, 기존 자체 형식과 함께 그 규칙도 읽을 수 있도록 하네스를 고쳤습니다. 지금은 Cursor 규칙을 Claude Code가 읽을 수 있는 형식으로 동기화까지 하고 있어서, Stripe에서 가장 많이 쓰는 세 코딩 에이전트인 미니언, Cursor, Claude Code가 엔지니어들이 코드베이스에 작성해 둔 같은 안내를 공유합니다.
Cursor가 공식 문서에서 설명하는 .mdc 규칙 파일은 아래와 같은 형태입니다. Stripe의 실제 규칙 파일이 아니라 형식을 보여 주는 예시이며, globs 로 적용 대상을 좁히고 alwaysApply: false 로 무조건 적용을 끄는 부분이 위에서 말한 조건부 규칙에 해당합니다.
---
description: RPC service conventions
globs: src/api/**/*.ts
alwaysApply: false
---
- Use zod for all validation
- Define return types with zod schemas
- Export types generated from schemas
에이전트 규칙 파일 형식 더 알아보기
Cursor Rules 공식 문서 - .mdc 형식과 globs / alwaysApply 조합에 따른 적용 조건
AGENTS.md - 여러 코딩 에이전트가 공통으로 읽는 규칙 파일 규약
AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준 - PyTorchKR 소개 글
컨텍스트 수집 2: 500개에 가까운 도구를 모은 사내 MCP 서버 Toolshed
파일 시스템에서 읽어 오는 정적 컨텍스트만으로는 부족합니다. 미니언은 사용자 요청을 온전히 이해하기 위해 사내 문서, 티켓 상세 내용, 빌드 상태, 코드 인텔리전스(Code Intelligence) 같은 정보를 네트워크 도구 호출로 가져와야 합니다. 원문에 따르면 MCP ( [Deep Research] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료)는 공개되자마자 네트워크 도구 호출의 업계 표준으로 자리 잡았고, Stripe도 그 시점에 미니언을 MCP에 통합했습니다. Part 1은 코드 검색에 Sourcegraph를 쓴다고 밝히고 있으며, 미니언 실행이 시작되기도 전에 요청에 포함된 링크들을 상대로 관련 MCP 도구를 결정적으로 미리 실행해 컨텍스트를 채워 둔다고 설명합니다.
이 사전 실행이 노리는 것은 첫 턴의 컨텍스트 품질입니다. 에이전트가 스스로 판단해 도구를 호출하게 두면 티켓 링크 하나를 여는 데에도 턴이 소모되고, 필요한 문서를 끝내 열지 않을 가능성도 남습니다. 요청에 포함된 링크의 종류를 보고 대응하는 MCP 도구를 미리 호출해 두면 에이전트는 첫 판단을 내리는 시점에 이미 필요한 정보를 손에 쥐고 시작합니다.
MCP(Model Context Protocol)를 쓸 필요가 있는 곳은 미니언만이 아니었습니다. Stripe에는 노코드 사내 에이전트 빌더, 전용 서비스로 동작하는 커스텀 에이전트, 외부에서 들여온 상용 에이전트, 커맨드라인 에이전트 도구와 다른 코딩 에이전트, 에이전틱 Slack 봇까지 서로 다른 프레임워크 위에서 동작하는 에이전트가 다수 존재하고, 이들이 요구하는 도구 집합은 상당 부분 겹칩니다.
에이전트마다 필요한 도구를 각자 연동하면 같은 사내 시스템에 대한 클라이언트가 여러 벌 생기고, 인증 방식이 바뀌거나 API가 개편될 때마다 그 벌 수만큼 고쳐야 합니다. 그래서 Stripe는 Toolshed 라는 중앙 사내 MCP 서버를 만들었습니다. 엔지니어가 새 도구를 쉽게 작성하면 그 도구가 사내 에이전트 시스템에 자동으로 노출되는 구조이고, Toolshed에 도구 하나를 추가하는 순간 수백 개에 달하는 에이전트 전체가 그 기능을 갖게 됩니다. 현재 사내 시스템과 Stripe가 사용하는 SaaS 플랫폼을 아우르는 MCP 도구가 500개 가까이 등록돼 있습니다. Part 1 시점에는 400개 이상이라고 적혀 있었습니다.
물론 도구가 많다고 에이전트에게 다 주지는 않습니다. 원문은 에이전트가 "안목 있게 선별된 도구가 담긴 더 작은 상자" 를 받았을 때 가장 잘 동작한다고 보고, 에이전트마다 자기 작업에 필요한 부분 집합만 요청하도록 설정합니다. 미니언 역시 기본값으로는 의도적으로 작은 부분 집합을 받고, 사용자별 설정으로 주제별 도구 묶음을 추가할 수 있습니다. 도구를 몇 개까지 어떤 순서로 노출할지는 커뮤니티에서도 SkillComposer 연구처럼 별도 연구 주제가 될 만큼 결과에 영향을 줍니다.
미니언이 사람의 확인 없이 자유롭게 MCP 도구를 호출하는 만큼, Stripe는 도구가 파괴적인 동작에 쓰이지 못하도록 사내 보안 통제 프레임워크를 별도로 두고 있습니다. 다만 원문이 1차 방어선으로 꼽는 것은 그 프레임워크가 아니라 데브박스입니다. 데브박스는 QA(Quality Assurance) 환경에서 동작하기 때문에 미니언은 실제 사용자 데이터, Stripe 운영 서비스, 임의의 외부 네트워크 통신에 애초에 접근할 수 없습니다. 이 격리 역시 사람이 안전하게 실험할 환경을 만들려고 설계한 것이 에이전트에게 그대로 쓰인 경우입니다.
MCP와 사내 도구 서버 더 알아보기
Model Context Protocol 공식 사이트 - 사양과 SDK, 서버 구현 예시
Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료 - PyTorchKR 정리 글
Sourcegraph - Part 1이 코드 인텔리전스 도구로 언급한 코드 검색 플랫폼
피드백을 왼쪽으로 당기기: 300만 개의 테스트와 최대 2회의 CI
앞서 적었듯 미니언은 원샷을 목표로 하지만, 한 번에 끝내지 못했을 때 에이전트가 스스로 진척을 만들려면 자동화된 피드백이 필요합니다. Stripe에는 300만 개가 넘는 테스트가 이미 쌓여 있어서 피드백을 만들 재료 자체는 충분합니다. 문제는 그 피드백을 언제 주느냐입니다.
Stripe가 개발 생산성을 이야기할 때 쓰는 원칙이 "피드백을 왼쪽으로 당긴다(shifting feedback left)" 입니다. CI에서 실패할 자동 검사라면 IDE나 git push 시점에서 미리 걸러 즉시 알려 주는 편이 사람에게도 에이전트에게도 낫습니다. 실제로 Stripe에는 가장 흔한 린트 문제를 고치는 사전 푸시 훅(pre-push hook)이 있고, 백그라운드 데몬이 변경분에 적용될 린트 규칙을 미리 계산하고 실행 결과를 캐시해 두기 때문에 푸시 시점의 린트 수정이 보통 1초 안쪽에 끝납니다. Part 1은 같은 장치를 두고 각 git push마다 휴리스틱으로 린트를 골라 자동 실행하는 로컬 실행 파일이 5초 미만에 끝난다고 소개했습니다.
미니언도 이 체계를 그대로 사용합니다. 린터 일부를 에이전트 개발 루프 블루프린트 안의 결정적 노드로 두고, 브랜치를 푸시하기 전에 로컬에서 그 린트 노드를 반복해 통과시킵니다. 자동 포매터를 상대로 토큰과 CI 시간을 쓰는 일을 없애고, 브랜치가 첫 시도에서 CI를 통과할 확률을 높이려는 배치입니다.
피드백을 앞당기는 일은 사람보다 에이전트 쪽에서 이득이 더 큽니다. 사람은 CI 결과를 기다리는 동안 다른 작업을 하지만, 에이전트에게 그 대기 시간은 컨텍스트를 유지한 채 멈춰 있는 시간이고 CI 한 바퀴는 그대로 토큰과 컴퓨팅 비용으로 환산됩니다. 게다가 자동 포매터가 잡아 줄 공백 문제를 LLM에게 고치게 하는 것은 결정적인 코드가 1초 안에 처리할 일을 확률적인 모델에게 맡기는 것과 같습니다. 블루프린트가 린트를 결정적 노드로 떼어 놓은 이유가 여기서 다시 확인됩니다.
로컬에서 모든 테스트를 실행하는 것은 불가능하므로, 표준 미니언 블루프린트에는 전체 CI 스위트를 상대로 한 반복이 한 번 포함됩니다. 300만 개를 매번 전부 실행하는 것은 아니고, Part 1의 설명에 따르면 CI가 푸시된 변경과 관련된 테스트를 선별해 실행합니다. 미니언이 변경을 푸시하면 CI가 실행되고, 실패한 테스트 중 자동 수정(autofix)이 있는 것은 그대로 적용됩니다. 자동 수정이 없는 실패는 블루프린트의 에이전트 노드로 돌아가 미니언에게 로컬에서 고칠 기회가 한 번 더 주어집니다. 두 번째 푸시와 CI 실행까지 마치면 브랜치는 사람 운영자에게 넘어가 수동 검토를 받습니다.
| 계층 | 실행 시점 | 걸리는 시간 | 실패했을 때 |
|---|---|---|---|
| 사전 푸시 린트 훅 | git push 시점 | 보통 1초 미만 (Part 1 기준 5초 미만) | 가장 흔한 린트 문제를 그 자리에서 자동 수정 |
| 블루프린트 린트 노드 | 브랜치 푸시 전, 에이전트 루프 안 | 원문에 수치 없음 | 에이전트가 로컬에서 고치고 다시 린트 |
| 1차 CI | 브랜치 푸시 직후 | 원문에 수치 없음 | 자동 수정이 있으면 적용, 없으면 에이전트 노드로 전달 |
| 2차 CI | 두 번째 푸시 직후 | 원문에 수치 없음 | 사람 운영자에게 브랜치 인계 |
왜 CI를 한두 번만 실행하는가에 대한 답도 명시돼 있습니다. CI 실행은 토큰과 컴퓨팅, 시간을 모두 소모하고, LLM이 전체 CI 루프를 무한정 반복하는 데에는 한계 효용 체감이 있다는 판단입니다. 원문은 속도와 완성도 사이의 균형이라는 표현을 쓰면서, "가능하면 한 번, 많아야 두 번, 그것도 로컬에서 고칠 수 있는 것을 모두 고친 뒤에" 라는 지침이 적절한 지점이라고 설명합니다.
두 편의 글이 함께 말하는 것: 사람을 위한 투자가 에이전트에게 되돌아온다
Part 2의 마무리에서 Alistair Gray는 미니언이 Stripe가 AI로 엔지니어를 돕는 여러 방법 중 하나일 뿐이라고 선을 그으면서도, 에이전트 하네스와 MCP 같은 업계 표준 개념에 수년간 다듬어 온 사내 도구와 인프라를 섞은 좋은 예로 꼽습니다. 문서, 개발 환경, 반복 루프 어느 쪽이든 사람의 개발 생산성에 들인 투자가 에이전트 세계에서 되돌아왔다는 것이 두 편에 걸쳐 반복되는 관찰입니다.
이 관찰을 그대로 다른 조직에 옮기기는 쉽지 않고, 저자들도 그 점을 의식하고 있습니다. Part 1은 세부 사항 다수가 Stripe에만 해당하지만 일반화할 수 있는 교훈도 있다고 적었고, Part 2는 아예 미니언 흐름 중 Stripe에 특화된 부분에 집중하겠다고 밝히며 시작합니다. 실제로 10초 만에 준비되는 EC2 개발 환경, 300만 개의 테스트와 자동 수정, 500개에 가까운 사내 MCP 도구는 어느 것도 에이전트 도입을 위해 만든 것이 아니라 이미 있던 자산입니다. 그렇더라도 미니언이 성립하기 위해 어떤 조각들이 필요했는지에 대한 목록으로는 쓸 수 있습니다. 아래 표를 통해 원문이 밝힌 조각과 그것을 담당하는 Stripe의 자산을 정리했습니다.
| 무인 실행에 필요한 조건 | Stripe에서 그 역할을 하는 것 | 원문의 근거 |
|---|---|---|
| 병렬 실행과 상호 간섭 차단 | 작업당 하나씩 띄우는 데브박스 | 에이전트끼리 변경이 겹치면 충돌 해소에 토큰이 낭비됨 |
| 권한 확인 없이 실행해도 되는 안전성 | QA 환경에 격리된 데브박스, 운영 데이터와 외부 네트워크 차단 | 실수의 영향 범위가 데브박스 하나로 한정 |
| 반드시 수행돼야 하는 단계의 보장 | 블루프린트의 결정적 노드 | 린트와 푸시는 LLM을 호출하지 않고 코드로 실행 |
| 에이전트가 되돌려 받을 자동 피드백 | 사전 푸시 린트 훅, 300만 개 테스트, 자동 수정 | 한두 번의 CI 반복으로 수렴시키는 정책 |
| 사람과 에이전트가 공유하는 코드베이스 지식 | 하위 디렉토리에 조건부로 붙는 규칙 파일 | 미니언, Cursor, Claude Code가 같은 규칙을 읽음 |
| 사내 시스템에 대한 동적 접근 | 중앙 MCP 서버 Toolshed | 도구 하나를 추가하면 에이전트 전체가 사용 가능 |
다만 수치를 해석할 때 조심할 부분이 있습니다. 두 글이 제시하는 지표는 주당 병합 PR 수 한 가지이고, 미니언이 만든 PR의 수용률이나 롤백 비율, 리뷰에 걸린 시간, 사람이 이어받아 고친 비중 같은 품질 지표는 공개되지 않았습니다. 모든 PR이 사람 리뷰를 거친다는 점도 명시돼 있으므로, 1,300개라는 숫자는 사람 리뷰어의 부담이 사라졌다는 뜻이 아니라 코드를 처음 작성하는 단계가 옮겨 갔다는 뜻에 가깝습니다.
사내 코딩 에이전트를 직접 만든 사례를 더 찾아본다면, 커뮤니티에 소개된 Spotify의 코딩 에이전트 Honk가 규모와 문제 의식 면에서 비교하기 좋습니다. 조직 차원의 도입 방법론은 OpenAI가 공개한 AI 네이티브 엔지니어링 팀 구축 가이드에, 에이전트를 운영 환경에서 신뢰할 수 있게 만드는 일반 원칙은 12-Factor Agents에 정리돼 있습니다.
기업의 대규모 코딩 에이전트 운영 사례 더 알아보기
코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk - PyTorchKR 소개 글
OpenAI가 공개한, 소프트웨어 개발 주기별 AI 네이티브 엔지니어링 팀 구축 가이드 - PyTorchKR 소개 글
Cursor의 에이전트 스웜과 새로운 모델 경제학 - 병렬 에이전트 운영의 비용 구조를 다룬 PyTorchKR 소개 글
Minions, Stripe의 원샷 종단간 코딩 에이전트 Part 1 소개 블로그
Minions, Stripe의 원샷 종단간 코딩 에이전트 Part 2 소개 블로그
goose GitHub 저장소 (미니언 하네스가 포크한 Block의 오픈소스 코딩 에이전트)
Stripe 개발자 문서
더 읽어보기
-
Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 (feat. Block, Linux Foundation)
-
코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk (feat. Code with Claude 2026)
-
장시간 자율 코딩을 위한 에이전트 하네스 설계: GAN에서 영감 받은 멀티 에이전트 아키텍처 (feat. Anthropic)
-
Learn Harness Engineering: AI 코딩 에이전트를 신뢰할 수 있게 만드는 하네스 엔지니어링 강의
-
Artificial Analysis가 공개한 코딩 에이전트 벤치마크: 모델 + 하네스의 조합으로 평가한 벤치마크 결과
-
OpenAI가 공개한, 소프트웨어 개발 주기별 AI 네이티브 엔지니어링 팀 구축 가이드 (feat. Codex)
-
[Deep Research] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글이 유용하셨다면 아래
쪽 좋아요
를 눌러주세요 — 파이토치 한국 사용자 모임
이 새로운 소식을 정리하고 공유하는 데 힘이 됩니다! 