# Stripe의 무인 코딩 에이전트 Minions, 매주 1,300개 PR을 사람 코드 없이 만드는 방법 (feat. goose, MCP)

**URL:** <https://discuss.pytorch.kr/t/stripe-minions-1-300-pr-feat-goose-mcp/11690>\
**Category:** 읽을거리&정보공유\
**Tags:** developer-productivity, stripe, goose, coding-agent, llm, mcp, agent-harness\
**Created:** [8월 23, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/stripe-minions-1-300-pr-feat-goose-mcp/11690 "2026-08-23T09:30:57Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![9bow](https://discuss.pytorch.kr/user_avatar/discuss.pytorch.kr/9bow/32/16301_2.png) [@9bow](https://discuss.pytorch.kr/u/9bow)\
**Post date:** [8월 23, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/stripe-minions-1-300-pr-feat-goose-mcp/11690/1 "2026-08-23T09:30:57Z")

</div>

![Stripe의 무인 코딩 에이전트 Minions가 Slack 멘션에서 풀 리퀘스트까지 진행하는 4단계 파이프라인](https://discuss.pytorch.kr/uploads/default/original/3X/6/3/63326230a7c0b4e970582ff6c143bf2c150b0414.jpeg)

## Minions 소개: 사람이 지켜보지 않는 Stripe의 사내 코딩 에이전트

Minions는 결제 인프라 기업인 [Stripe](https://stripe.com)가 사내에서 직접 만든 코딩 에이전트로, 작업을 한 번에 끝내는 **원샷(One-shot)** 을 목표로 설계됐고 실행 내내 사람이 개입하지 않는 **완전 무인(Fully Unattended)** 방식으로 동작합니다. 전형적인 실행은 Slack 메시지 한 줄에서 시작해, CI를 통과하고 사람 리뷰를 받을 준비가 끝난 풀 리퀘스트(Pull Request, PR)로 끝납니다. 그 사이에 사람과의 상호작용은 없습니다. Stripe에서 매주 병합되는 PR 가운데 1,300개 이상이 미니언이 작성한 것이며, 사람이 코드 리뷰는 하지만 그 안에 사람이 직접 타이핑한 코드는 한 줄도 들어가지 않습니다.

이 숫자가 눈에 띄는 이유는 미니언이 다루는 코드베이스 때문입니다. Stripe의 코드베이스는 몇 개의 거대한 저장소에 걸쳐 수억 줄 규모이고, 그 코드는 연간 1조 달러가 훌쩍 넘는 결제 거래를 실제 운영 환경에서 처리합니다. 아무 제약이 없는 상태에서 프로토타입을 새로 만드는 일과, 규제와 금융 기관 연동이 얽힌 성숙한 코드베이스를 고치는 일은 난이도가 전혀 다릅니다.

이번에 살펴볼 두 편의 글은 Stripe의 Leverage 팀 소속 엔지니어인 Alistair Gray가 [stripe.dev](https://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](https://docs.claude.com/en/docs/claude-code/overview)나 [Cursor](https://cursor.com) 같은 도구로 에이전트와 함께 계획하고 협업합니다. 미니언이 채우는 자리는 그 옆입니다. Stripe가 가장 부족한 자원 중 하나로 꼽는 것이 개발자의 주의(attention)인데, 사람이 지켜보지 않아도 되는 에이전트는 그 주의를 나누지 않고도 작업을 병렬로 늘릴 수 있게 해 줍니다. 원문은 특히 온콜(on-call) 당번 기간에 여러 미니언을 동시에 띄워 자잘한 이슈를 한꺼번에 처리하는 사용 패턴을 언급합니다.

Part 1은 첫 문장에서 업계 상황을 이렇게 정리합니다. 에이전틱 코딩은 새롭고 흥미로운 것에서 _"기본 요건(table stakes)"_ 으로 넘어갔고, 바탕 모델이 계속 좋아지면서 무인 코딩 에이전트도 가능성에서 현실이 되었다는 것입니다. 실제로 [Jules](https://discuss.pytorch.kr/t/jules-tools-web-jules-cli-google/7909)처럼 클라우드에서 비동기로 동작하는 코딩 에이전트가 여럿 등장했고, 요청을 던져 두고 결과를 나중에 확인하는 방식 자체는 더 이상 새롭지 않습니다. 미니언이 그 흐름 안에서 구별되는 지점은 실행 환경과 오케스트레이션이 전부 사내 개발 인프라 위에 올라가 있다는 것입니다. Slack 스레드 하나가 곧 작업 지시서가 되고, 에이전트는 Stripe 엔지니어가 매일 쓰는 것과 같은 개발 머신에서 같은 린터와 같은 CI를 통과한 뒤 사내 PR 템플릿을 채워 내놓습니다. Part 1과 Part 2는 각각 그 흐름의 바깥쪽과 안쪽을 보여 줍니다.

## 왜 기성 코딩 에이전트를 쓰지 않고 직접 만들었는가

두 편의 글을 관통하는 전제는 Stripe 코드베이스의 특수성입니다. 백엔드 대부분이 [Ruby](https://www.ruby-lang.org/ko/)로 작성돼 있는데 [Rails](https://rubyonrails.org/)를 쓰지 않고, 타입 검사에는 [Sorbet](https://sorbet.org/)을 사용합니다. 원문의 표현대로 상대적으로 흔치 않은 스택입니다. 여기에 더해 코드 전반이 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](https://slack.com/)입니다. 변경 사항을 논의하던 스레드에서 Slack 앱을 태그하면 그 자리에서 미니언이 실행되고, 에이전트는 스레드 전체와 거기 걸린 링크를 컨텍스트로 함께 읽습니다. 아래는 원문이 예시로 든 실제 호출 메시지입니다.

 ![Slack 스레드에서 미니언을 호출하는 메시지 예시](https://discuss.pytorch.kr/uploads/default/original/3X/9/8/983c5a8ef8f5f5e1ae3a56d46d24b5b9ca851c32.png)

메시지를 보면 어떤 저장소에서 작업할지, 관련 사내 문서가 어디 있는지, 무엇을 만들어야 하는지가 사람에게 설명하듯 자연어로 적혀 있습니다. 별도의 프롬프트 양식이 아니라 평소 팀원에게 일을 넘길 때 쓰는 문장 그대로입니다.

한편 Slack 말고도 사내 애플리케이션 곳곳에 미니언 호출 지점이 마련돼 있습니다. 사내 문서 플랫폼, 기능 플래그(feature flag) 플랫폼, 사내 티켓 UI가 모두 미니언과 연동됩니다. 대표적인 예가 불안정한 테스트(flaky test) 처리입니다. CI 시스템이 flaky test를 감지하면 자동으로 티켓이 생성되고, 그 티켓에는 미니언으로 고치라는 버튼이 함께 표시됩니다.

 ![불안정한 테스트 티켓에 붙은 AI 수정 시도 버튼](https://discuss.pytorch.kr/uploads/default/original/3X/c/2/c2a3aa64ec3e1bc875be49a055e8b090f72a1eb2.png)

작업이 진행되는 동안, 그리고 끝난 뒤에도 엔지니어는 웹 UI에서 미니언이 내린 판단과 실행한 동작을 순서대로 확인할 수 있습니다. 아래 화면에서 왼쪽 열에는 에이전트의 서술과 도구 호출이 번갈아 쌓이고, 파일 읽기와 파일 편집이 각각 어떤 경로를 대상으로 일어났는지가 그대로 남습니다. 오른쪽 열에는 작업 디렉토리에서 변경된 파일 15개가 추가와 삭제 줄 수와 함께 나열되며, 상단에는 브랜치 이름과 커밋 해시, 그리고 풀 리퀘스트를 만드는 버튼이 놓여 있습니다.

 ![미니언 실행을 관리하는 웹 인터페이스 화면](https://discuss.pytorch.kr/uploads/default/original/3X/7/7/779c29fa5af6d20d8b9fe7f8778f358327ed2169.png)

작업을 마친 미니언은 브랜치를 만들고 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](https://git-scm.com/docs/git-worktree)가 도움이 되지만 둘을 결합하기가 까다롭고, 개발자 셸의 모든 권한을 그대로 가지면서 적절히 제약된 로컬 에이전트를 만드는 일 자체가 근본적으로 어렵다는 것이 원문의 진단입니다. 에이전트 실행 환경을 컨테이너로 분리하려는 시도는 커뮤니티에도 [container-use](https://discuss.pytorch.kr/t/container-use-ai/7069) 같은 사례가 소개된 적이 있습니다.

Stripe는 이 문제를 새로 풀지 않았습니다. 미니언을 Stripe 엔지니어가 원래 쓰던 표준 개발 환경인 **데브박스(devbox)** 위에서 그대로 실행합니다. 데브박스는 Stripe 소스 코드가 들어 있고 개발 중인 서비스가 돌아가는 [AWS EC2](https://aws.amazon.com/ec2/) 인스턴스이며, 사람이 작성하는 Stripe 코드 대부분도 SSH로 데브박스에 원격 연결된 IDE 안에서 만들어집니다. DevOps 용어로 데브박스는 _"애완동물이 아니라 가축(cattle, not pets)"_ 에 해당합니다. 오래 아껴 쓰는 맞춤 장비가 아니라, 표준화돼 있어 언제든 교체할 수 있는 자원입니다.

 ![엔지니어가 사용 중인 데브박스 목록과 각 박스에서 실행 중인 미니언](https://discuss.pytorch.kr/uploads/default/original/3X/f/0/f070f796ffbb40e9cfffe7dc52b773b58e1a1b65.png)

많은 엔지니어가 작업 하나당 데브박스 하나를 쓰고, 한 사람이 대여섯 개를 동시에 띄워 두기도 합니다. 이런 사용 패턴이 성립하려면 새 박스를 만드는 일이 부담스럽지 않아야 하므로, Stripe는 데브박스가 10초 안에 준비되는 것을 목표로 삼고 미리 만들어 예열해 둔 풀(pool)을 유지합니다. 이 풀에서는 원문이 열거한 아래 준비 작업이 사용자의 요청보다 먼저 끝나 있습니다.

- **거대한 git 저장소 클론** : 수억 줄 규모의 주요 저장소를 미리 받아 두고 최근 master 사본으로 유지합니다.

- **빌드와 타입 검사 캐시 예열** : [Bazel](https://bazel.build/) 캐시와 타입 검사(Type Checking) 캐시를 미리 채워 첫 빌드와 첫 타입 검사가 오래 걸리지 않게 합니다.

- **코드 생성 서비스 기동** : 데브박스에서 상시 동작하는 코드 생성 서비스를 미리 띄워 둡니다.

10초가 지나면 주요 저장소 전체가 최근 master 사본으로 체크아웃된 상태가 되어, 곧바로 REPL을 열거나 테스트를 실행하거나 코드를 고쳐 타입 검사를 하거나 웹 서비스를 띄울 수 있습니다.

미니언에게 이 환경이 주는 가장 큰 이점은 격리입니다. 데브박스는 운영 환경 리소스와 인터넷에서 차단돼 있어 사람의 권한 확인 없이 에이전트를 실행해도 안전하고, git worktree처럼 Stripe 규모에서 감당하기 어려운 방식을 쓰지 않고도 병렬 실행을 얻습니다. 정리하면, 데브박스는 LLM 에이전트가 등장하기 훨씬 전에 사람을 위해 만들어진 인프라인데 그 성질이 그대로 에이전트에게 맞아떨어진 경우입니다.

### 에이전트 실행 환경 격리 더 알아보기

**container-use: AI 코딩 에이전트를 위한 컨테이너 기반 개발 환경** - PyTorchKR 소개 글

> [@container-use: AI 코딩 에이전트를 위한 컨테이너 기반 개발 환경](https://discuss.pytorch.kr/t/container-use-ai/7069):
>
> container-use 소개 AI 코딩 에이전트를 활용한 개발이 점점 보편화되면서, 각 에이전트가 독립적인 환경에서 안전하게 작업할 수 있는 인프라가 중요해졌습니다. Dagger의 container-use는 이러한 요구를 충족시키기 위해 등장한 오픈소스 도구로, 에이전트별로 격리된 컨테이너 환경을 제공하여 충돌 없이 병렬 작업을 가능하게 합니다. 특히 Claude Code, Cursor, VSCode, goose 등 다양한 MCP(Multi-agent Control Protocol) 호환 에이전트와의 통합을 지원하여, 실험적인 AI 개발에 최적화된 환경을 제공합니다. [container-use 사용 데모] container-use는 Dagger에서 개발한 오픈소스 프로젝트로, AI 코딩 에이전트들이 각자의 컨테이너 환경에서 독립적으로 작업할 수 있도록 지원합니다. 이 도구를 사용하면 에이전트마…

**OpenAI, Windows용 Codex의 안전한 샌드박스 구축 여정 공개** - AppContainer와 제한 토큰, 방화벽 조합

> [@OpenAI, Windows용 Codex의 안전한 샌드박스 구축 여정 공개: AppContainer부터 write-restricted Token, Windows Firewall까지](https://discuss.pytorch.kr/t/openai-windows-codex-appcontainer-write-restricted-token-windows-firewall/10252):
>
> Codex와 샌드박스, 그리고 Windows라는 까다로운 환경 [OpenAI Codex](https://openai.com/codex/)는 개발자의 노트북 위에서 동작하는 코딩 에이전트입니다. CLI 형태로 실행되거나 [VS Code 확장](https://marketplace.visualstudio.com/items?itemName=openai.chatgpt) 또는 데스크톱 앱 안에서 동작하며, 키보드 앞에 앉아 있는 사람과 클라우드에서 실행되는 모델 사이의 대화를 중개하면서 파일 편집, 테스트 실행, Git 브랜치 생성 같은 작업을 자동으로 수행합니다. 즉 Codex는 "사람이 할 수 있는 모든 일을 모델이 대신 해 주는" 도구이며, 동시에 그렇기 때문에 적절히 통제되지 않으면 위험할 수 있는 도구이기도 합니다. 이런 코딩 에이전트가 사용자 시스템 위에서 안전하게 동작하려면 샌드박스(sandbox) 가 필수입니다. 샌드박스란 운영체제가 강제하는 제약된 실행 환경으로, …

**CubeSandbox: 60ms 안에 부팅되는 AI 에이전트용 하드웨어 격리 샌드박스** - PyTorchKR 소개 글

> [@CubeSandbox: 60ms 안에 부팅되는 AI 에이전트용 하드웨어 격리 샌드박스](https://discuss.pytorch.kr/t/cubesandbox-60ms-ai/11146):
>
> CubeSandbox 소개 CubeSandbox는 AI 에이전트가 생성한 코드를 안전하게 실행하기 위한 고성능 샌드박스 서비스입니다. LLM이 만들어낸 코드는 신뢰할 수 없다는 전제에서 출발해야 하는데, Docker 컨테이너는 호스트와 커널을 공유하기 때문에 커널 취약점을 통한 탈출 위험이 남고, 전통적인 가상 머신은 격리 수준은 높지만 부팅에 수 초가 걸리고 메모리 오버헤드도 큽니다. 에이전트 하나가 수십 번씩 코드를 실행하고 동시에 수백 개의 에이전트가 돌아가는 환경에서는 이 두 방식 모두 한계가 뚜렷합니다. CubeSandbox는 RustVMM과 KVM 위에 구축한 MicroVM으로 이 문제를 풉니다. 샌드박스마다 전용 Guest OS 커널을 부여해 하드웨어 수준의 격리를 확보하면서도, 콜드 스타트 60ms 이내, 인스턴스당 메모리 오버헤드 5MB 미만이라는 수치를 제시합니다(READ…

## goose를 포크해 만든 하네스, 사람이 없다는 것을 전제로

데브박스가 기존 자산이었다면, 에이전트 하네스는 미니언을 위해 새로 만든 부분입니다. Stripe는 2024년 말에 [Block](https://block.xyz/)의 오픈소스 코딩 에이전트인 [goose](https://github.com/block/goose) (:pytorch::kr: [Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 (feat. Block, Linux Foundation)](https://discuss.pytorch.kr/t/goose-rust-mcp-ai-feat-block-linux-foundation/9777))를 사내에서 포크해 Stripe의 LLM 인프라에 맞게 고쳤습니다. goose는 널리 쓰인 초기 코딩 에이전트 중 하나였고, 이후 Stripe는 포크의 기능 개발 방향을 사람이 감독하는 도구가 아니라 미니언 쪽에 맞춰 갔습니다. 사람이 함께 일하는 용도는 이미 엔지니어들에게 제공 중인 Cursor와 [Claude Code](https://docs.claude.com/en/docs/claude-code/overview) 같은 외부 도구가 충분히 채우고 있었기 때문입니다.

Part 1은 이 포크에서 무엇을 고쳤는지도 밝힙니다. 에이전트 루프와 결정적 코드가 번갈아 실행되도록 오케스트레이션 흐름을 다시 짜면서 git 조작, 린터, 테스트 실행 같은 단계를 결정적 코드 쪽에 두었고, 그 결과 에이전트의 창의성과 Stripe가 요구하는 단계를 반드시 거친다는 보장을 함께 얻으려 했습니다. 이 발상이 Part 2에서 블루프린트라는 이름으로 정리됩니다.

원문이 미니언의 가장 독특한 지점으로 꼽는 것은 감독하는 사람의 부재입니다. 시중의 로컬 코딩 에이전트는 대개 엔지니어가 어깨너머로 지켜보는 상황에 최적화돼 있어서, 중단(interruptibility)이나 사람이 입력하는 명령으로 실행을 시작하고 방향을 트는 기능이 핵심을 이룹니다. 미니언은 그 기능들을 쓸 수 없습니다. 대신 반대편에서 얻는 것이 있는데, 격리된 데브박스 안이라면 에이전트가 저지를 수 있는 실수의 영향 범위(blast radius)가 데브박스 하나로 한정되므로 확인 프롬프트 없이 전체 권한으로 실행해도 됩니다.

하네스 설계 자체를 다루는 자료를 더 보고 싶다면 커뮤니티에 정리된 [장시간 자율 코딩을 위한 에이전트 하네스 설계](https://discuss.pytorch.kr/t/gan-feat-anthropic/9427)와 [Learn Harness Engineering 강의 소개](https://discuss.pytorch.kr/t/learn-harness-engineering-ai/10596)가 함께 읽기 좋습니다. 모델과 하네스의 조합이 코딩 성능을 어떻게 가르는지는 [Artificial Analysis의 코딩 에이전트 벤치마크](https://discuss.pytorch.kr/t/artificial-analysis/10183)에서 수치로 확인할 수 있습니다.

### goose와 에이전트 하네스 더 알아보기

**goose GitHub 저장소** - Stripe가 포크한 Block의 오픈소스 코딩 에이전트

> **[GitHub - aaif-goose/goose: an open source, extensible AI agent that goes...](https://github.com/aaif-goose/goose)**
>
> an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

**goose 공식 문서** - 확장(Extension)과 MCP 연동, 설정 방법

> **[goose | Your open source AI agent](https://block.github.io/goose/)**
>
> Your native open source AI agent. Desktop app, CLI, and API — for code, workflows, and everything in between.

**Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트** - PyTorchKR 소개 글

> [@Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 (feat. Block, Linux Foundation)](https://discuss.pytorch.kr/t/goose-rust-mcp-ai-feat-block-linux-foundation/9777):
>
> Goose 소개 AI 에이전트의 가능성은 코딩 보조를 훨씬 넘어섭니다. 파일 시스템을 탐색하고, 패키지를 설치하고, 셸 명령어를 실행하며, API를 호출하고, 테스트를 수행하는 등 복잡한 작업 흐름을 자율적으로 처리할 수 있어야 진정한 AI 에이전트라 할 수 있습니다. Block(구 Square)이 개발하여 오픈소스로 공개한 Goose는 이러한 비전을 구현한 범용 AI 에이전트입니다. 코드 작업, 리서치, 문서 작성, 자동화, 데이터 분석 등 다양한 영역에서 실질적인 작업을 수행할 수 있으며, 데스크톱 앱, CLI, API 세 가지 인터페이스를 모두 제공합니다. Goose는 2025년 1월 출시 이후 빠른 성장을 보이며 현재 42,500개 이상의 GitHub 스타를 기록하고 있습니다. 2025년 12월에는 Linux Foundation이 설립한 에…

## 블루프린트, 워크플로우의 결정성과 에이전트의 유연성을 한 실행 안에

Part 2는 Stripe의 개발 흐름에 맞춘 작은 최적화가 여럿 있었다고 하면서, 그중 미니언 구현에 더 근본적인 것으로 드러난 하나를 따로 다룹니다. Stripe가 **블루프린트(Blueprint)** 라고 부르는 오케스트레이션 방식입니다. 원문은 [Anthropic이 정리한 워크플로우와 에이전트의 구분](https://www.anthropic.com/engineering/building-effective-agents)에서 출발합니다. **워크플로우(Workflow)** 는 고정된 단계 그래프로 동작하는 LLM 시스템으로, 각 노드가 전체 목표 중 좁게 정의된 부분을 맡고 노드 사이의 실행 순서는 미리 정해진 간선이 통제합니다. 반면 **에이전트(Agent)** 는 도구를 가진 루프에 가까워서, LLM이 도구 호출 결과를 보고 다음에 무엇을 할지 스스로 판단합니다.

블루프린트는 코드로 정의한 워크플로우이면서, 개별 노드가 결정적(Deterministic) 코드일 수도 있고 특정 작업에 집중한 에이전트 루프일 수도 있습니다. 원문의 비유를 빌리면 블루프린트는 _"결정적 코드와 엮인 에이전트 스킬의 모음"_ 이며, 결과적으로 결정적 코드 노드와 자유롭게 진행되는 에이전트 노드가 뒤섞인 상태 기계(State Machine)의 모습을 띱니다.

 ![결정적 노드(사각형)와 에이전트 노드(구름)가 섞인 미니언 블루프린트 예시](https://discuss.pytorch.kr/uploads/default/original/3X/8/3/835bae8694affe60b124b8454b890cda2a288247.png)

미니언을 구동하는 블루프린트에는 _"Implement task"_, _"Fix CI failures"_ 처럼 넓은 재량이 주어진 에이전트 노드가 있고, _"Run configured linters"_, _"Push changes"_ 처럼 LLM을 아예 호출하지 않고 코드만 실행하는 결정적 노드가 있습니다. 위 그림에서 구름 모양이 에이전트 노드, 사각형이 결정적 노드입니다. 린트 오류를 고치는 에이전트 노드와 린터를 실행하는 결정적 노드가 서로를 오가며 루프를 이루고, 그 아래에서 브랜치를 푸시한 뒤 CI 실패를 고치는 경로로 이어집니다.

| 구분 | 워크플로우 | 에이전트 | 블루프린트 |
| --- | --- | --- | --- |
| 실행 구조 | 고정된 단계 그래프, 노드마다 좁은 역할 | 도구를 반복 호출하는 단일 루프 | 코드로 정의한 그래프, 노드마다 결정적 코드 또는 에이전트 루프 |
| 다음 단계 결정 | 미리 정의된 간선 | LLM이 도구 호출 결과를 보고 판단 | 노드 종류에 따라 갈림 |
| 얻는 것 | 결정성 | 예상하지 못한 상황에 대한 유연성 | 한 실행 안에서 둘 다 |

이렇게 나눠 두는 실익은 비용과 신뢰성 양쪽에 걸쳐 있습니다. _"실행이 끝나면 항상 변경분에 린트를 실행한다"_ 처럼 미리 예상할 수 있는 작은 결정을 코드로 정해 두면 규모가 커질수록 토큰과 CI 비용이 절약되고, 에이전트가 틀릴 기회 자체가 줄어듭니다. 원문은 이를 _"LLM을 제한된 상자에 넣는 것"_ 이라고 표현하면서 그 효과가 쌓여 시스템 전체의 신뢰성으로 돌아온다고 정리합니다.

블루프린트가 순수한 에이전트 루프와 갈라지는 지점은 실행의 재현성입니다. 도구를 가진 루프 하나로 전부 처리하면 린트를 실행할지 말지, 브랜치를 언제 푸시할지까지 모델의 판단에 맡겨지기 때문에, 같은 작업을 두 번 실행해도 거쳐 간 단계가 달라질 수 있습니다. 반대로 전부 고정된 워크플로우로 짜면 예상하지 못한 상황이 나왔을 때 그래프 밖으로 나갈 방법이 없습니다. 블루프린트는 예상할 수 있는 단계만 그래프로 고정하고, 예상할 수 없는 부분에만 에이전트 노드를 배치하는 절충입니다.

블루프린트는 서브에이전트의 컨텍스트 엔지니어링(Context Engineering) 수단이기도 합니다. 노드 단위로 도구를 제한하거나, 시스템 프롬프트를 바꾸거나, 대화 컨텍스트를 그 하위 작업에 필요한 만큼만 남겨 단순화하는 조작이 블루프린트 구조 위에서 이뤄집니다. 팀마다 자기 목적에 맞는 블루프린트를 따로 만들 수도 있어서, 완전히 결정적인 코드 변환 스크립트(Codemod)로는 처리할 수 없는 까다로운 LLM 보조 마이그레이션을 블루프린트로 인코딩한 사례가 있다고 원문은 언급합니다. 작업마다 실행 구조를 직접 짜는 접근은 커뮤니티에 소개된 [Claude Code 동적 워크플로우](https://discuss.pytorch.kr/t/claude-code-dynamic-workflows/10519)와도 문제 의식이 닿아 있습니다.

### 워크플로우와 에이전트 오케스트레이션 더 알아보기

**Building Effective Agents** - Anthropic이 정리한 워크플로우와 에이전트의 구분, 원문이 참조하는 글

> **[Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents)**
>
> Discover how Anthropic approaches the development of reliable AI agents. Learn about our research on agent capabilities, safety considerations, and technical framework for building trustworthy AI.

**12-Factor Agents: 운영 환경에서 신뢰할 수 있는 LLM 에이전트를 만들기 위한 12가지 원칙** - PyTorchKR 소개 글

> [@12-Factor Agents: 운영 환경에서 신뢰할 수 있는 LLM 에이전트를 만들기 위한 12가지 원칙](https://discuss.pytorch.kr/t/12-factor-agents-llm-12/10384):
>
> 12-Factor Agents 소개 12-Factor Agents는 "What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?" 라는 한 줄 질문에서 출발하는 LLM 에이전트 설계 원칙 모음입니다. HumanLayer의 Dex가 정리해 공개한 12개의 원칙 으로, 이름에서 짐작되듯이 [12 Factor Apps](https://12factor.net/) 의 정신을 LLM 기반 소프트웨어에 옮긴 형태를 취합니다. 저자는 plug-and-play 프레임워크(예: CrewAI, LangChain)부터 minimalist smolagents, production-grade LangGraph, Griptape에 이르기까지 "every…

**Claude Code 동적 워크플로우: 작업마다 하네스를 직접 짜는 병렬 오케스트레이션** - PyTorchKR 소개 글

> [@Claude Code 동적 워크플로우(Dynamic Workflows): 작업마다 하네스를 직접 짜는 병렬 오케스트레이션](https://discuss.pytorch.kr/t/claude-code-dynamic-workflows/10519):
>
> 동적 워크플로우(Dynamic Workflows) 소개 [Anthropic](https://www.anthropic.com)이 [Claude Code](https://www.claude.com/product/claude-code)에 동적 워크플로우(Dynamic Workflows) 를 도입했습니다. 핵심 아이디어는 간단합니다. 지금까지는 사람이 미리 짜둔 고정된 절차나 단일 에이전트의 한 번의 시도에 의존했다면, 이제는 Claude가 주어진 작업에 맞춰 오케스트레이션 스크립트를 그 자리에서 직접 작성하고, 그 스크립트가 수십에서 수백 개의 서브에이전트를 한 세션 안에서 병렬로 실행하는 방식입니다. 각 서브에이전트의 결과는 사용자에게 도달하기 전에 다른 에이전트가 검증합니다. 어떤 문제는 단일 에이전트가 한 번에 처리하기에는 너무 큽니다. 특히 복잡하고 오래된 레거시 코드베이스에서 서비스 전체를 훑는 버그 헌트, 수백 개 파일을 건드리는 마이그레이션, 또는 커밋 전에 모든 각도에서 스트레스 테스트하고 싶은 계획 같은 작업…

## 컨텍스트 수집 1: 디렉토리를 따라 조건부로 붙는 규칙 파일

Stripe 규모의 코드베이스에서 아무 안내 없이 풀어 놓은 에이전트는, 원문의 표현대로 린터가 잘 갖춰져 있더라도 모범 사례를 따르거나 적절한 라이브러리를 골라 쓰는 데 어려움을 겪습니다. [CLAUDE.md](https://docs.claude.com/en/docs/claude-code/memory)나 [AGENTS.md](https://agents.md/) (:pytorch::kr: [AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준](https://discuss.pytorch.kr/t/agents-md-openai-ai/7578)) 같은 에이전트 규칙 파일 형식은 에이전트가 디렉토리 구조를 훑어 나가는 동안 코드베이스에 대한 지식을 자동으로 얻게 해 주는 장치입니다.

문제는 저장소 크기입니다. 무조건 적용되는 전역 규칙을 늘리면 에이전트가 일을 시작하기도 전에 컨텍스트 윈도우가 규칙으로 가득 차기 때문에, Stripe는 무조건 규칙을 매우 아껴 쓰고 거의 모든 규칙을 특정 하위 디렉토리나 파일 패턴에 한정해 둡니다. 에이전트가 파일 시스템을 이동하다가 해당 경로에 들어가면 그때 규칙이 자동으로 붙는 방식입니다.

규칙 파일을 에이전트마다 중복해서 두는 대신 사람이 쓰는 도구와 같은 컨텍스트를 읽게 하자는 것이 Stripe의 방침이었습니다. 그래서 조건부 적용을 지원하는 [Cursor의 규칙 형식](https://cursor.com/docs/context/rules)으로 표준화하고, 기존 자체 형식과 함께 그 규칙도 읽을 수 있도록 하네스를 고쳤습니다. 지금은 Cursor 규칙을 Claude Code가 읽을 수 있는 형식으로 동기화까지 하고 있어서, Stripe에서 가장 많이 쓰는 세 코딩 에이전트인 미니언, Cursor, Claude Code가 엔지니어들이 코드베이스에 작성해 둔 같은 안내를 공유합니다.

Cursor가 공식 문서에서 설명하는 `.mdc` 규칙 파일은 아래와 같은 형태입니다. Stripe의 실제 규칙 파일이 아니라 형식을 보여 주는 예시이며, `globs` 로 적용 대상을 좁히고 `alwaysApply: false` 로 무조건 적용을 끄는 부분이 위에서 말한 조건부 규칙에 해당합니다.

```markdown
---
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` 조합에 따른 적용 조건

> **[Rules | Cursor Docs](https://cursor.com/docs/rules)**
>
> Configure persistent instructions with Project, Team, and User Rules, plus AGENTS.md. Learn best practices for effective coding guidelines.

**AGENTS.md** - 여러 코딩 에이전트가 공통으로 읽는 규칙 파일 규약

> **[AGENTS.md](https://agents.md/)**
>
> AGENTS.md is a simple, open format for guiding coding agents. Think of it as a README for agents.

**AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준** - PyTorchKR 소개 글

> [@AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준](https://discuss.pytorch.kr/t/agents-md-openai-ai/7578):
>
> AGENTS.md 소개 AGENTS.md는 OpenAI가 제안하는 새로운 문서 형식으로, AI 코딩 에이전트가 프로젝트를 이해하고 작업할 수 있도록 돕는 일종의 “에이전트 전용 README”입니다. 기존의 README.md 파일은 인간 개발자를 위한 프로젝트 개요, 설치 방법, 기여 지침 등을 담는 데 최적화되어 있습니다. 그러나 AI 에이전트가 프로젝트에 기여하기 위해 필요한 정보는 훨씬 더 구체적이고 절차 중심적일 때가 많습니다. 예를 들어, 빌드 명령어, 테스트 실행 절차, 코드 스타일 규칙 등은 사람이 직접 읽기에는 장황하거나 불필요할 수 있지만, 에이전트에게는 반드시 필요한 지침입니다. 이러한 필요를 충족하기 위해 AGENTS.md는 프로젝트 루트에 위치하여 AI 에이전트가 쉽게 접근할 수 있는 일관된 형식을 제공합니다. 현재 20,000개 이상의 오픈소스 프로젝트에서 이미 이…

## 컨텍스트 수집 2: 500개에 가까운 도구를 모은 사내 MCP 서버 Toolshed

파일 시스템에서 읽어 오는 정적 컨텍스트만으로는 부족합니다. 미니언은 사용자 요청을 온전히 이해하기 위해 사내 문서, 티켓 상세 내용, 빌드 상태, 코드 인텔리전스(Code Intelligence) 같은 정보를 네트워크 도구 호출로 가져와야 합니다. 원문에 따르면 [MCP](https://modelcontextprotocol.io/) (:pytorch::kr: [[Deep Research] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료](https://discuss.pytorch.kr/t/deep-research-model-context-protocol-mcp/6594))는 공개되자마자 네트워크 도구 호출의 업계 표준으로 자리 잡았고, Stripe도 그 시점에 미니언을 MCP에 통합했습니다. Part 1은 코드 검색에 [Sourcegraph](https://sourcegraph.com/)를 쓴다고 밝히고 있으며, 미니언 실행이 시작되기도 전에 요청에 포함된 링크들을 상대로 관련 MCP 도구를 결정적으로 미리 실행해 컨텍스트를 채워 둔다고 설명합니다.

이 사전 실행이 노리는 것은 첫 턴의 컨텍스트 품질입니다. 에이전트가 스스로 판단해 도구를 호출하게 두면 티켓 링크 하나를 여는 데에도 턴이 소모되고, 필요한 문서를 끝내 열지 않을 가능성도 남습니다. 요청에 포함된 링크의 종류를 보고 대응하는 MCP 도구를 미리 호출해 두면 에이전트는 첫 판단을 내리는 시점에 이미 필요한 정보를 손에 쥐고 시작합니다.

MCP(Model Context Protocol)를 쓸 필요가 있는 곳은 미니언만이 아니었습니다. Stripe에는 노코드 사내 에이전트 빌더, 전용 서비스로 동작하는 커스텀 에이전트, 외부에서 들여온 상용 에이전트, 커맨드라인 에이전트 도구와 다른 코딩 에이전트, 에이전틱 Slack 봇까지 서로 다른 프레임워크 위에서 동작하는 에이전트가 다수 존재하고, 이들이 요구하는 도구 집합은 상당 부분 겹칩니다.

에이전트마다 필요한 도구를 각자 연동하면 같은 사내 시스템에 대한 클라이언트가 여러 벌 생기고, 인증 방식이 바뀌거나 API가 개편될 때마다 그 벌 수만큼 고쳐야 합니다. 그래서 Stripe는 **Toolshed** 라는 중앙 사내 MCP 서버를 만들었습니다. 엔지니어가 새 도구를 쉽게 작성하면 그 도구가 사내 에이전트 시스템에 자동으로 노출되는 구조이고, Toolshed에 도구 하나를 추가하는 순간 수백 개에 달하는 에이전트 전체가 그 기능을 갖게 됩니다. 현재 사내 시스템과 Stripe가 사용하는 SaaS 플랫폼을 아우르는 MCP 도구가 500개 가까이 등록돼 있습니다. Part 1 시점에는 400개 이상이라고 적혀 있었습니다.

물론 도구가 많다고 에이전트에게 다 주지는 않습니다. 원문은 에이전트가 _"안목 있게 선별된 도구가 담긴 더 작은 상자"_ 를 받았을 때 가장 잘 동작한다고 보고, 에이전트마다 자기 작업에 필요한 부분 집합만 요청하도록 설정합니다. 미니언 역시 기본값으로는 의도적으로 작은 부분 집합을 받고, 사용자별 설정으로 주제별 도구 묶음을 추가할 수 있습니다. 도구를 몇 개까지 어떤 순서로 노출할지는 커뮤니티에서도 [SkillComposer 연구](https://discuss.pytorch.kr/t/skillcomposer-llm/11090)처럼 별도 연구 주제가 될 만큼 결과에 영향을 줍니다.

미니언이 사람의 확인 없이 자유롭게 MCP 도구를 호출하는 만큼, Stripe는 도구가 파괴적인 동작에 쓰이지 못하도록 사내 보안 통제 프레임워크를 별도로 두고 있습니다. 다만 원문이 1차 방어선으로 꼽는 것은 그 프레임워크가 아니라 데브박스입니다. 데브박스는 QA(Quality Assurance) 환경에서 동작하기 때문에 미니언은 실제 사용자 데이터, Stripe 운영 서비스, 임의의 외부 네트워크 통신에 애초에 접근할 수 없습니다. 이 격리 역시 사람이 안전하게 실험할 환경을 만들려고 설계한 것이 에이전트에게 그대로 쓰인 경우입니다.

### MCP와 사내 도구 서버 더 알아보기

**Model Context Protocol 공식 사이트** - 사양과 SDK, 서버 구현 예시

> **[What is the Model Context Protocol (MCP)? - Model Context Protocol](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro)**

**Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료** - PyTorchKR 정리 글

> [@\[Deep Research\] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료](https://discuss.pytorch.kr/t/deep-research-model-context-protocol-mcp/6594):
>
> MCP(Model Context Protocol) 개념 및 이해를 위한 학습 자료 MCP의 기본 개념 및 역할 MCP(Model Context Protocol)는 AI 모델과 외부 데이터 소스 또는 도구를 연결해주는 개방형 표준 프로토콜입니다. 쉽게 말해 AI 모델이 필요한 맥락(Context) 이나 정보를 외부에서 가져올 수 있도록 해주는 통로 역할을 합니다. 기존에는 언어 모델(LLM)이 자신에게 주어진 텍스트 외에 별도의 지식이나 데이터에 접근하기 어려워, 새로운 데이터 원본마다 별도 커스텀 통합이 필요했습니다 ([Introducing the Model Context Protocol \ Anthropic](https://www.anthropic.com/news/model-context-protocol#:~:text=As%20AI%20assistants%20gain%20mainstream,connected%20systems%20difficult%20to%20scale)). MCP는 이러한 문제를 해결하고자 등장했으며, AI 분야의 USB-C 포트와 같은 표준화된 연결 방식으로 비유됩니다 ([Introduction - Model Co…](https://modelcontextprotocol.io/introduction#:~:text=MCP%20is%20an%20open%20protocol,different%20data%20sources%20and%20tools)

**Sourcegraph** - Part 1이 코드 인텔리전스 도구로 언급한 코드 검색 플랫폼

> **[Sourcegraph — Code Understanding, Oversight and Evolution](https://sourcegraph.com/)**
>
> Give humans and agents complete context to understand, oversee, and evolve the world's largest, most complex codebases.

## 피드백을 왼쪽으로 당기기: 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](https://discuss.pytorch.kr/t/spotify-honk-feat-code-with-claude-2026/10775)가 규모와 문제 의식 면에서 비교하기 좋습니다. 조직 차원의 도입 방법론은 [OpenAI가 공개한 AI 네이티브 엔지니어링 팀 구축 가이드](https://discuss.pytorch.kr/t/openai-ai-feat-codex/10577)에, 에이전트를 운영 환경에서 신뢰할 수 있게 만드는 일반 원칙은 [12-Factor Agents](https://discuss.pytorch.kr/t/12-factor-agents-llm-12/10384)에 정리돼 있습니다.

### 기업의 대규모 코딩 에이전트 운영 사례 더 알아보기

**코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk** - PyTorchKR 소개 글

> [@코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk (feat. Code with Claude 2026)](https://discuss.pytorch.kr/t/spotify-honk-feat-code-with-claude-2026/10775):
>
> Spotify의 AI 전환 소개 코딩이 더 이상 소프트웨어 개발의 병목(bottleneck)이 아니게 된다면 무슨 일이 벌어질까요? [Spotify](https://www.spotify.com/)의 엔지니어링 조직은 지금 그 질문에 대한 답을 실제로 마주하고 있습니다. Spotify의 수석 아키텍트이자 엔지니어링 부사장인 니클라스 구스타브손(Niklas Gustavsson)은 [Code with Claude 2026](https://www.anthropic.com/) 행사에서, 수년간 쌓아온 내부 개발 플랫폼과 엔지니어링 모범 사례에 대한 투자가 어떻게 회사의 AI 전환을 이끌고 있는지를 발표했습니다. 이 글은 그 발표의 핵심을 정리하고, 한국의 개발자 관점에서 의미를 덧붙인 것입니다. 이 이야기가 흥미로운 이유는 단순히 "우리도 AI 코딩 도구를 도입했다"는 사례 보고가 아니기 때문입니다. Spotify가 강조하는 핵심 메시지는, AI 에이전트가 폭발적으로 유용해진 지금의 변화가 하루아침에 도구 하나…

**OpenAI가 공개한, 소프트웨어 개발 주기별 AI 네이티브 엔지니어링 팀 구축 가이드** - PyTorchKR 소개 글

> [@OpenAI가 공개한, 소프트웨어 개발 주기별 AI 네이티브 엔지니어링 팀 구축 가이드 (feat. Codex)](https://discuss.pytorch.kr/t/openai-ai-feat-codex/10577):
>
> AI 네이티브 엔지니어링 팀 구축 가이드 소개 OpenAI가 [Codex 공식 문서](https://developers.openai.com/codex)에 공개한 'Building an AI-Native Engineering Team' 가이드는, 소프트웨어 개발 생명주기(Software Development Lifecycle, SDLC) 의 계획부터 배포까지 7단계 전반에 코딩 에이전트를 도입하려는 엔지니어링 조직을 위한 실무 지침서입니다. 각 단계마다 기존 방식의 병목이 무엇인지, 코딩 에이전트가 어떻게 돕는지, 그리고 엔지니어의 역할이 어떻게 바뀌는지를 위임(Delegate), 검토(Review), 소유(Own) 라는 일관된 프레임워크로 정리하고, 바로 적용할 수 있는 시작 체크리스트를 단계별로 제공합니다. 이 가이드가 나온 배경에는 모델의 추론(reasoning) 지속 시간이 빠르게 길어지고 있다는 관찰이 있습니다. AI 평가 …

**Cursor의 에이전트 스웜과 새로운 모델 경제학** - 병렬 에이전트 운영의 비용 구조를 다룬 PyTorchKR 소개 글

> [@Cursor의 에이전트 스웜과 새로운 모델 경제학: '품질은 같아도 비용은 8배까지 차이날 수 있다'](https://discuss.pytorch.kr/t/cursor-8/11363):
>
> Cursor의 에이전트 스웜 소개: 수백 개의 에이전트를 하나의 목표로 묶기 AI 코드 에디터를 만드는 [Cursor](https://cursor.com)는 올해 초부터 "여러 에이전트를 협력시켜 하나의 목표를 향해 규모를 키우면, 지금까지 한 개의 에이전트로는 닿지 못하던 규모와 복잡도의 작업을 풀 수 있지 않을까" 라는 가설을 실험해 왔습니다. 이 실험의 상징적인 프로젝트는 [바닥부터 웹 브라우저를 만드는 장시간 스웜](https://cursor.com/blog/scaling-agents)이었습니다. 개념 증명으로는 성공했지만 완성도 높은 소프트웨어에는 한참 못 미쳤고, 그 과정은 철저히 경험적이었습니다. 백지 상태에서 시작해 안정적이고 효과적인 시스템을 향해 [조금씩 언덕을 오르듯 개선](https://cursor.com/blog/self-driving-codebases)해 온 것입니다. 이번 글은 그 다음 단계에 대한 이야기입니다. Cursor는 스웜을 "우연히 굴러가는 것" 이 아니라 "의도적으로 설계할 수 있을 만큼" 이해하는 것을 목표로 삼았고, 그 진전을 확인하기 위해 예전 스웜이 고전했던 과제로 되돌아갔습니다. 바로 오직 …

## 📜 Minions, Stripe의 원샷 종단간 코딩 에이전트 Part 1 소개 블로그

> **[Minions: Stripe’s one-shot, end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents)**
>
> Minions are Stripe’s homegrown coding agents, responsible for more than a thousand pull requests merged each week. Though humans review the code, minions write it from start to finish. Learn how they work, and how we built them.

## 📜 Minions, Stripe의 원샷 종단간 코딩 에이전트 Part 2 소개 블로그

> **[Minions: Stripe’s one-shot, end-to-end coding agents—Part 2](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2)**
>
> Minions are Stripe’s homegrown coding agents, responsible for more than a thousand pull requests merged each week. Though humans review the code, minions write it from start to finish. Learn how they work, and how we built them.

## :github: goose GitHub 저장소 (미니언 하네스가 포크한 Block의 오픈소스 코딩 에이전트)

> **[GitHub - aaif-goose/goose: an open source, extensible AI agent that goes...](https://github.com/aaif-goose/goose)**
>
> an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

## 📚 Stripe 개발자 문서

> **[Documentation](https://docs.stripe.com/)**
>
> Explore our guides and examples to integrate Stripe.

## 더 읽어보기

- [Goose: Rust로 구축된 MCP 기반 오픈소스 범용 AI 에이전트 (feat. Block, Linux Foundation)](https://discuss.pytorch.kr/t/goose-rust-mcp-ai-feat-block-linux-foundation/9777)

- [코딩은 더 이상 병목이 아니다, Spotify의 코딩 에이전트 Honk (feat. Code with Claude 2026)](https://discuss.pytorch.kr/t/spotify-honk-feat-code-with-claude-2026/10775)

- [장시간 자율 코딩을 위한 에이전트 하네스 설계: GAN에서 영감 받은 멀티 에이전트 아키텍처 (feat. Anthropic)](https://discuss.pytorch.kr/t/gan-feat-anthropic/9427)

- [Learn Harness Engineering: AI 코딩 에이전트를 신뢰할 수 있게 만드는 하네스 엔지니어링 강의](https://discuss.pytorch.kr/t/learn-harness-engineering-ai/10596)

- [Artificial Analysis가 공개한 코딩 에이전트 벤치마크: 모델 + 하네스의 조합으로 평가한 벤치마크 결과](https://discuss.pytorch.kr/t/artificial-analysis/10183)

- [AGENTS.md: OpenAI가 제안하는, AI 코딩 에이전트를 위한 새로운 문서 표준](https://discuss.pytorch.kr/t/agents-md-openai-ai/7578)

- [container-use: AI 코딩 에이전트를 위한 컨테이너 기반 개발 환경](https://discuss.pytorch.kr/t/container-use-ai/7069)

- [OpenAI가 공개한, 소프트웨어 개발 주기별 AI 네이티브 엔지니어링 팀 구축 가이드 (feat. Codex)](https://discuss.pytorch.kr/t/openai-ai-feat-codex/10577)

- [[Deep Research] Model Context Protocol(MCP) 개념 및 이해를 위한 학습 자료](https://discuss.pytorch.kr/t/deep-research-model-context-protocol-mcp/6594)

- [12-Factor Agents: 운영 환경에서 신뢰할 수 있는 LLM 에이전트를 만들기 위한 12가지 원칙](https://discuss.pytorch.kr/t/12-factor-agents-llm-12/10384)

* * *

_이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다._ 🤗

이 글이 유용하셨다면 아래↘쪽 좋아요👍를 눌러주세요 — [:pytorch:파이토치 한국 사용자 모임🇰🇷](https://pytorch.kr/)이 새로운 소식을 정리하고 공유하는 데 힘이 됩니다! 🤩