원문: 9bow — Stripe의 무인 코딩 에이전트 Minions, 매주 1,300개 PR을 사람 코드 없이 만드는 방법 · 수집일: 2026-08-23

핵심 요지

Stripe의 사내 코딩 에이전트 Minions는 Slack 한 줄 요청에서 출발해 사람 개입 없이 PR까지 완성하는 원샷 무인(One-shot, Fully Unattended) 에이전트다. 매주 1,300개 이상 PR이 사람 코드 0줄로 병합되며, 비결은 모델 성능이 아니라 10초 예열 데브박스, 결정적 코드와 에이전트를 섞은 블루프린트, 500개 도구를 중앙 공급하는 MCP Toolshed, 조건부 규칙 파일과 shifting feedback left CI 전략 등 기존 개발 인프라를 에이전트에 그대로 재사용한 데 있다.

수집 범위

  • canonical URL: https://discuss.pytorch.kr/t/stripe-minions-1-300-pr-feat-goose-mcp/11690 (PyTorchKR Topic 11690, 9bow 작성, 2026-08-23 09:30 KST)
  • 원문 성격: stripe.dev 블로그 2편(Part 1 2026-02-09, Part 2 2026-02-19, Alistair Gray/Leverage 팀)을 GPT 모델로 정리한 2차 요약글 — 본 노트는 해당 PyTorchKR 요약의 전체 본문을 2026-08-23 webfetch로 수집해 정리
  • Stripe 원문 2편 전문은 별도 크롤링하지 않고 링크로 보존, 댓글/좋아요 등 상호작용 미포함

주요 내용

Minions 정의와 규모

  • 목표: 완전 무인 원샷 — Slack 메시지 → CI 통과 PR, 중간 사람 상호작용 없음. 사람은 코드 리뷰만 하고 타이핑 0줄
  • 규모: Part 1 “주당 1,000개+” → 10일 후 Part 2 “1,300개+“로 갱신, 수억 줄 monorepo(비-Rails Ruby+Sorbet+자체 라이브러리), 연간 1조 달러 결제 처리 코드베이스에서 달성
  • 맥락: 에이전틱 코딩이 table stakes가 된 시점, Jules 등 비동기 에이전트는 흔하나 Minions는 Slack 스레드→데브박스→린터/CI→PR 템플릿까지 사내 인프라 완전 통합이 차별점. Claude Code/Cursor로 협업하면서 attention 부족을 병렬 Minions로 해소(온콜 시 다수 동시 실행)

왜 기성 에이전트 대신 직접 만들었나

  • Stripe 스택 특수성: Ruby 비-Rails + Sorbet + 자체 라이브러리 다수 → 공개 관례에 기대기 어렵고 LLM이 학습 분포 밖 이름에 지속 노출
  • 도메인 난도: 결제·규제·금융기관 연동 → 그럴듯하지만 관례 벗어난 코드 비용이 일반 앱보다 큼. 성숙 코드베이스 수정은 멘탈 모델과 도구 사용법이 필요해 제한된 컨텍스트 윈도우로 익히기 어려움
  • 선택: 별도 환경 신설 대신 기존 dev 생산성 기반(소스관리·개발환경·코드생성·CI) 위에 하네스를 올려 “if it’s good for humans, it’s good for LLMs” 원칙 구현

Slack에서 시작하는 작업 요청

  • 진입점: CLI/웹 UI/Slack 중 Slack 최다 — 스레드에서 앱 태그 → 스레드 전체+링크를 컨텍스트로 자동 수집, 자연어 그대로 작성
  • 사내 연동: 문서 플랫폼·feature flag·티켓 UI — 대표 예 flaky test 자동 티켓 + “Minions로 고치기” 버튼
  • 웹 UI: 왼쪽 에이전트 서술+도구 호출·파일 경로, 오른쪽 변경 파일 diff(예시 15개), 상단 브랜치/커밋/PR 버튼
  • 완료 후 흐름: 브랜치 생성→CI 푸시→PR 템플릿 준비. 만족 시 PR 오픈·리뷰 요청, 불만족 시 추가 지시→동일 브랜치 재푸시, 수동 이어받기 가능. North Star는 사람 코드 0줄 PR
  • 비교: Cursor/Claude Code(IDE·로컬 셸, 중단/재지시/승인, 위험 명령 확인, 도구 루프) vs Minions(격리 데브박스 QA, 무개입, 확인 없이 전체 권한이지만 blast radius 1박스 제한, 블루프린트 혼합 오케스트레이션)
  • 사용 사례 3종: 사내 도구 dev 전용 화면+백엔드 엔드포인트, flaky test 수정, Codemod 불가한 마이그레이션용 전용 블루프린트

10초 격리 개발환경 데브박스

  • 무인 규모 운영 3조건: 병렬·예측 가능·격리. 노트북에서 동시 만족 난제(git worktree+컨테이너 결합 까다로움)
  • 해법: 기존 표준 EC2 데브박스(소스+서비스, SSH+IDE, cattle not pets) 재사용. 작업당 1박스, 1인 5-6개 동시 운용
  • 10초 준비를 위한 예열 풀: 거대 repo 미리 클론·recent master 유지, Bazel·타입 검사 캐시 예열, 코드 생성 서비스 기동 → 즉시 REPL/테스트/타입검사/웹서비스 가능
  • 이점: 운영 리소스·인터넷 차단으로 무확인 실행 안전, worktree 없이 병렬 확보. 사람용 인프라가 에이전트에 맞아떨어진 사례. 관련으로 container-use, Windows Codex 샌드박스, CubeSandbox(60ms MicroVM) 언급

goose 포크 하네스

  • 2024년 말 Block의 오픈소스 2026-04-05-goose 포크를 Stripe LLM 인프라에 맞춤 — 초기 널리 쓰인 코딩 에이전트, 이후 무인 방향으로만 발전 (협업은 Cursor/Claude Code가 담당)
  • 하네스 핵심 변경: 에이전트 루프↔결정적 코드 번갈아 실행, git/린터/테스트는 결정적 쪽 → 창의성+필수 단계 보장 (Part 2 블루프린트로 체계화)
  • 특징: 감독자 부재 → 중단/입력 불가 대신 격리 데브박스 덕에 확인 프롬프트 없이 전체 권한 실행이 가능

블루프린트: 결정성과 유연성의 혼합

  • 출발점: Anthropic의 워크플로우(고정 단계 그래프, 간선이 순서 통제) vs 에이전트(도구 루프, LLM이 다음 판단) 구분
  • 정의: 코드로 정의한 워크플로우 + 노드별 결정적 코드 또는 에이전트 루프 → 결정적(사각형)과 에이전트(구름)가 섞인 상태 기계. 예: “Implement task”/“Fix CI failures”는 에이전트 노드, “Run configured linters”/“Push changes”는 결정적 노드. 린트 수정 루프→푸시→CI 수정 경로로 이어짐
  • 효과: “항상 린트 실행” 같은 예상 가능한 결정을 코드로 고정하면 토큰·CI 비용 절약, 틀릴 기회 감소 — “LLM을 제한된 상자에 넣기” → 신뢰성 누적
  • 트레이드오프: 순수 루프는 같은 작업도 단계 상이(재현성 낮음), 순수 워크플로우는 예외에 취약 → 블루프린트는 예상 단계만 고정하고 예상 밖만 에이전트에 맡기는 절충
  • 컨텍스트 엔지니어링 수단: 노드 단위 도구 제한·시스템 프롬프트 교체·대화 컨텍스트 단순화. 팀별 맞춤 블루프린트로 Codemod 불가 마이그레이션 인코딩 가능. Claude Code Dynamic Workflows와 문제의식 공유

규칙 파일: 조건부 컨텍스트 수집 1

  • 과제: 린터만으론 모범사례·라이브러리 선택 불가, CLAUDE.md/AGENTS.md 같은 규칙 파일이 디렉토리 탐색 중 자동 지식 획득
  • 문제: 전역 규칙 증가 → 컨텍스트 윈도우 포화
  • Stripe 해법: 무조건 규칙 최소화, 대부분을 하위 디렉토리/파일 패턴에 조건부 적용(진입 시 자동 부착). Cursor 규칙 형식(.mdc, globs+alwaysApply:false)으로 표준화하고 자체 형식도 함께 읽기 + Claude Code 형식으로 동기화 → Minions/Cursor/Claude Code 3종이 동일 규칙 공유. 예시로 zod 검증·스키마 타입 규칙 제시

Toolshed: 500개 도구 중앙 MCP 서버 (컨텍스트 수집 2)

  • 필요: 정적 파일만으론 부족, 사내 문서·티켓·빌드·Code Intelligence는 MCP 호출로 수집. MCP는 공개 직후 표준, Stripe도 즉시 통합. Sourcegraph로 코드 검색, 요청 링크를 미리 결정적 MCP 호출로 채워 첫 턴 품질 확보
  • 문제: 노코드 빌더·커스텀 에이전트·상용 에이전트·CLI·Slack 봇 등 다수 프레임워크가 겹치는 도구 집합을 요구 → 에이전트별 연동 시 다벌 클라이언트·인증/API 변경 시 다벌 수정
  • 해법: 중앙 MCP 서버 Toolshed — 도구 작성 시 자동 노출, 1개 추가 시 수백 에이전트 즉시 사용. 사내+SaaS 500개 가까이(Part 1 시점 400+)
  • 운영: 전부 주지 않고 “작은 선별 상자”만 제공 — Minions 기본 작은 부분집합 + 사용자별 주제 묶음. 도구 수·순서가 성능에 영향(SkillComposer 연구). 보안은 파괴 방지 프레임워크보다 데브박스 QA 격리가 1차 방어선(실제 데이터·운영 서비스·외부망 접근 불가)

피드백을 왼쪽으로 당기기: 300만 테스트와 최대 2회 CI

  • 원칙: CI 실패 검사를 IDE/git push에서 미리 걸러 즉시 피드백(shifting left). Stripe는 흔한 린트 자동 수정 pre-push hook + 백그라운드 데몬의 변경분 린트 계산·캐시 → 푸시 시 린트 수정 <1초(Part 1 기준 <5초)
  • Minions 적용: 린터 일부를 블루프린트 결정적 노드로 두어 푸시 전 로컬 반복 통과 → 토큰·CI 절약, 첫 CI 통과율 향상. 사람보다 에이전트에 이득이 큼(대기=토큰·컴퓨팅 비용, 공백 수정은 결정적 1초 일을 LLM에 맡기는 셈)
  • CI 전략: 전체 테스트 로컬 실행 불가 → 표준 블루프린트는 관련 테스트 선별해 CI 1회 포함. 푸시→CI→autofix 자동 적용→autofix 없는 실패는 에이전트 노드 회귀 1회 → 2차 푸시·CI → 사람 인계. “가능하면 1회, 많아야 2회, 로컬에서 고칠 수 있는 건 다 고친 뒤”가 균형점

두 글이 함께 말하는 것

  • Alistair Gray 결론: Minions는 여러 AI 지원 방법 중 하나, 하네스+MCP+사내 도구 혼합의 좋은 예. 문서·환경·반복 루프 어디든 사람 생산성 투자가 에이전트에 되돌아옴
  • 일반화 주의: Part 1 “세부 다수는 Stripe 특화이나 교훈 일반화 가능”, Part 2 “Stripe 특화 흐름 집중”. 10초 EC2·300만 테스트·500 MCP는 에이전트용 신설이 아닌 기존 자산
  • 무인 실행 6조건-자산 매핑: 병렬/간섭 차단→데브박스, 안전→QA 격리, 필수 단계 보장→블루프린트 결정적 노드, 자동 피드백→pre-push 훅+테스트+autofix, 공유 지식→조건부 규칙, 동적 접근→Toolshed
  • 지표 한계: 공개 수치는 병합 PR 수뿐, 수용률·롤백·리뷰 시간·사람 수정 비중 등 품질 지표 미공개. 모든 PR 사람 리뷰 필수 → 1,300은 리뷰 부담 제거가 아닌 작성 단계 이동을 의미

해석과 적용 메모

  • Minions는 harness 설계가 모델보다 성패를 가른 대표 사례다. 300만 테스트·pre-push 훅·캐시 같은 피드백 인프라가 없으면 무인 루프는 CI 비용과 대기 토큰으로 바로 붕괴한다 — 하네스-인프라 동반 투자가 전제
  • 블루프린트는 moc-ai-agents-harness에서 다루는 “워크플로우+에이전트” 하이브리드 패턴의 실천형이다. 결정적 노드로 재현성·비용을 잡고 에이전트 노드로 예외를 처리하는 절충은 Stripe뿐 아니라 레거시 마이그레이션·대규모 Codemod 불가 작업에 일반화 가능
  • 데브박스 예열 풀·QA 격리 전략은 hermes-agent나 사내 devbox를 쓰는 조직이 에이전트를 병렬로 올릴 때 그대로 차용할 수 있다. container-use/CubeSandbox 같은 경량 격리 대안도 같은 3조건(병렬·예측·격리)으로 평가하면 된다
  • Toolshed처럼 mcp 도구를 중앙 서버에 500개 모아 두고 에이전트별 작은 부분집합만 노출하는 운영은 “도구 폭증→컨텍스트 오염”을 막는 현실적 해법이다. 도구 수·순서가 성능을 좌우한다는 SkillComposer 지적과 함께, 사내 MCP 도입 시 도구 선별 정책이 핵심
  • 1,300 PR 지표는 생산성으로 보이지만 리뷰 부담·품질 지표가 비공개라는 점을 함께 봐야 한다. 조직에 도입할 때는 병합 수뿐 아니라 롤백·재작업·리뷰 지연을 함께 측정해야 Minions식 무인이 실제로 attention을 아꼈는지 검증할 수 있다

누락·접근 제한

  • PyTorchKR 요약글 1개 본문만 수집 — 로그인/유료벽 없음, 공개 범위 전체 확보
  • Stripe 공식 블로그 원문 2편 전문, 댓글, 좋아요 등 상호작용 데이터는 본 수집에 미포함 — 필요 시 Part 1/2 원문 별도 인제스트 권장
  • 본문 이미지 4종(4단계 파이프라인, Slack 호출, 웹 UI, 블루프린트, 데브박스 목록)은 Discourse CDN에만 존재하며 로컬 복사 없음
  • 수치(1,300 PR, 300만 테스트, 500 MCP 도구, 10초 데브박스)는 원문 주장 인용 — Stripe 내부 메트릭 독립 검증 불가

관련 노트