매주 1300개의 PR을 작성하는 AI가 있다면?
Stripe에선 이게 현실이다. 2026년 2월, Stripe는 자사의 내부 AI 코딩 에이전트 Minions에 대한 상세한 기술 블로그를 공개했다. 놀라운 건 단순한 자동완성이나 코파일럿 수준이 아니라는 점이다. Minions는 사람의 감독 없이 처음부터 끝까지 코드를 작성하고, PR을 올리고, CI를 돌리고, 실패하면 스스로 고친다. 사람은 그저 마지막에 리뷰만 하면 된다.
GitHub Copilot이나 Cursor를 써본 개발자라면 알 것이다. 이런 도구들은 분명 생산성을 높여주지만, 결국 옆에서 계속 지켜봐야 한다. 자동완성을 수락할지 말지, 에이전트가 삽질하고 있진 않은지 확인해야 한다. 반면 Minions는 완전히 혼자 일한다. 개발자는 아침에 출근해서 “이거 좀 해줘” 하고 티켓을 던지면, 저녁에 PR이 올라와 있다.
이게 진짜 가능한가? 어떻게 만들었나? 그리고 우리도 쓸 수 있나? 하나씩 파헤쳐보자.
Minions가 뭔데?
Minions는 Stripe가 내부적으로 개발한 무인(unattended) 코딩 에이전트다. 핵심 특징은 이렇다:
- 매주 1300개 이상의 PR을 작성 (Part 1 기준 1000개에서 증가)
- 사람이 작성한 코드는 단 한 줄도 없음 - 100% AI가 작성
- 사람은 리뷰만 함 - 코드 작성부터 테스트 수정까지 전부 AI
- 원샷(one-shot) 엔드투엔드 - 시작부터 끝까지 자동으로 처리
일반적인 AI 코딩 도구와의 가장 큰 차이는 감독자(supervisor)가 없다는 점이다. Cursor나 Claude Code는 옆에서 개발자가 계속 지켜보고 개입한다. 하지만 Minions는 완전히 격리된 환경(devbox)에서 혼자 작업하고, 끝나면 PR만 올린다.
왜 필요했을까?
Stripe는 거대한 모노레포(monorepo)를 운영한다. 코드베이스가 워낙 크다 보니 단순 반복 작업도 엄청나게 많다. 예를 들면:
- 라이브러리 마이그레이션 (deprecated API를 새 API로 교체)
- Lint 규칙 적용
- 타입 정의 업데이트
- 공통 패턴을 따르도록 리팩토링
이런 작업들은 단순하지만 손이 많이 가고, 여러 파일에 걸쳐 있어서 시간이 오래 걸린다. 사람이 하기엔 너무 지루하고, 완전 자동화하기엔 너무 복잡한 그 애매한 영역. Minions가 정확히 이 영역을 공략한다.
인프라: Devbox가 핵심이다
Minions의 성공 비결 중 하나는 이미 존재하던 인프라를 활용했다는 점이다. Stripe 개발자들은 원래 로컬 맥북이 아니라 Devbox라는 클라우드 개발 환경에서 작업한다.
Devbox란?
- AWS EC2 인스턴스로 돌아가는 개발 환경
- 모든 소스코드가 이미 체크아웃되어 있고, 서비스 실행 가능
- VS Code나 IDE가 SSH로 원격 연결해서 작업
- 10초 안에 즉시 사용 가능 - 미리 워밍업된 풀(pool)에서 가져옴
DevOps 용어로 “Cattle, not pets”라는 표현이 있다. 애완동물처럼 하나하나 소중히 관리하는 게 아니라, 가축처럼 대체 가능하고 표준화된 환경이라는 뜻이다. Devbox가 딱 그렇다. 엔지니어 한 명이 동시에 5-6개의 Devbox를 돌리는 게 일상이다.
왜 Devbox가 중요한가?
AI 에이전트가 제대로 작동하려면:
- 병렬화(parallelizable) - 여러 작업을 동시에 처리
- 예측 가능(predictable) - 매번 동일한 환경
- 격리(isolated) - 서로 간섭하지 않고, 실수해도 피해 최소화
로컬 맥북에서 이걸 구현하려면 컨테이너나 git worktree 같은 복잡한 설정이 필요하다. 하지만 Devbox는 기본적으로 이 모든 특성을 제공한다. 개발자를 위해 만든 인프라가 AI에게도 완벽했던 것.
특히 중요한 건 격리다. Devbox는 QA 환경에서 돌아가기 때문에, 실제 유저 데이터나 프로덕션 서비스에 접근할 수 없다. AI가 뭔가 잘못 건드려도 한 Devbox 안에서만 망가진다. 그래서 확인(confirmation) 프롬프트 없이도 AI에게 전권을 줄 수 있다.
에이전트 아키텍처: Blueprint라는 마법
일반적으로 LLM 시스템을 오케스트레이션하는 방법은 두 가지다:
1. Workflow (워크플로우)
미리 정의된 그래프 형태로 작업을 진행한다. 각 노드가 특정 작업을 담당하고, 엣지(edge)가 실행 흐름을 제어한다. 결정론적(deterministic)이라 예측 가능하지만, 유연성이 떨어진다.
[린트 실행] → [테스트 실행] → [PR 생성]
2. Agent (에이전트)
“도구가 달린 루프(loop with tools)” 패턴. LLM이 스스로 판단해서 도구를 호출하고, 결과를 보고 다음 행동을 결정한다. 유연하지만 예측 불가능하고, 헛발질할 수 있다.
while not task_complete:
next_action = llm.decide(current_state, tools)
result = execute(next_action)
current_state = update(current_state, result)
Minions의 선택: Blueprint
Stripe는 둘 다 쓰되, 섞었다. 이름하여 Blueprint - 코드로 정의된 워크플로우인데, 각 노드가 결정론적 코드일 수도 있고, 에이전트 루프일 수도 있다.
예를 들어 Minions의 blueprint는 이런 식이다:
[작업 이해] (에이전트)
↓
[코드 구현] (에이전트)
↓
[린터 실행] (결정론적 코드)
↓
[변경사항 푸시] (결정론적 코드)
↓
[CI 실행 대기] (결정론적 코드)
↓
[CI 실패 수정] (에이전트)
↓
[2차 푸시] (결정론적 코드)
왜 이게 좋은가?
- 토큰 절약 - “항상 마지막에 린트 돌려”같은 건 LLM에게 물어볼 필요 없다. 그냥 코드로 강제하면 된다.
- 안정성 - LLM이 삽질할 여지를 줄인다. “작은 상자에 LLM을 가둬두는” 게 시스템 전체의 신뢰성을 높인다.
- 맞춤화 - 팀마다 다른 blueprint를 만들 수 있다. 특정 마이그레이션 작업용 blueprint 같은 것도 가능.
실제로 Stripe는 이 접근법이 토큰 비용과 CI 비용을 크게 절감하면서도 성공률을 높였다고 밝혔다.
컨텍스트 수집: 어떻게 코드베이스를 이해하나?
거대한 코드베이스에서 AI가 제대로 작동하려면 적절한 컨텍스트가 필요하다. Stripe는 두 가지 방법을 쓴다.
1. Rule Files (규칙 파일)
CLAUDE.md, AGENTS.md 같은 파일 형식이다. 특정 디렉토리나 파일 패턴에 대한 가이드를 제공한다.
<!-- .cursorrules 예시 -->
이 디렉토리에서는:
- logging.Logger 대신 우리 커스텀 logger 사용
- API 호출 시 반드시 timeout 설정
- 테스트는 반드시 @integration 데코레이터 사용
Stripe의 코드베이스가 워낙 크기 때문에, 글로벌 규칙은 최소화하고 디렉토리별 규칙을 선호한다. 그렇지 않으면 컨텍스트 윈도우가 규칙으로만 가득 찰 테니까.
재밌는 건 표준화다. Stripe는 Cursor의 .cursorrules 포맷을 채택했다. 그리고 이걸 Claude Code가 읽을 수 있는 포맷으로도 동기화한다. 결과적으로 Minions, Cursor, Claude Code 세 가지 에이전트가 모두 같은 규칙을 공유한다.
2. MCP (Model Context Protocol)
정적 파일만으로는 부족하다. 네트워크 호출로 동적으로 정보를 가져와야 할 때가 많다:
- 내부 문서 검색
- 티켓 세부사항
- 빌드 상태
- 코드 인텔리전스 (어떤 함수가 어디서 쓰이는지 등)
이를 위해 Stripe는 Toolshed라는 중앙화된 MCP 서버를 만들었다.
Toolshed의 특징:
- 500개 가까운 MCP 도구 보유
- 내부 시스템과 SaaS 플랫폼 연동
- 모든 에이전트가 공유 - no-code 에이전트 빌더, Slack 봇, CLI 에이전트 등
- 도구를 Toolshed에 추가하면 수백 개의 에이전트가 즉시 사용 가능
물론 Minions가 500개 도구를 다 쓰는 건 아니다. “작은 상자” 원칙에 따라 작업에 맞는 일부 도구만 제공한다. 사용자가 추가로 필요한 도구 세트를 설정할 수도 있다.
보안 측면에서도 중요하다. Minions는 자율적이지만, 파괴적인 작업은 못하게 제어된다. 애초에 Devbox가 QA 환경이라 실제 유저 데이터나 프로덕션에 접근 불가하고, 네트워크도 제한되어 있다.
반복과 피드백: 한 번에 성공하기 위한 여러 번의 시도
“원샷(one-shot)”이라고 해서 정말 한 번에 끝나는 건 아니다. 사람 개입 없이 자동으로 피드백을 받고 수정한다는 뜻이다.
왼쪽으로 피드백 이동(Shift Left)
개발자 생산성의 핵심 원칙 중 하나다. 문제를 최대한 빨리 발견할수록 좋다는 뜻이다.
- CI에서 실패하는 것보다 → IDE에서 미리 알려주는 게 낫다
- 푸시 후 발견하는 것보다 → 저장할 때 발견하는 게 낫다
Stripe는 이미 이런 시스템을 갖추고 있었다:
- Pre-push hooks - 푸시하기 전에 자동으로 린트 수정
- 백그라운드 데몬 - 린트 규칙을 미리 계산하고 캐싱, 1초 이내에 결과 제공
Minions는 이 시스템을 그대로 활용한다. 린트는 blueprint의 결정론적 노드로 로컬에서 먼저 처리하고, CI에 푸시하기 전에 루프를 돈다.
CI 반복 전략
모든 테스트를 로컬에서 돌릴 순 없다. Stripe는 300만 개가 넘는 테스트가 있으니까. 그래서 CI는 필수다. Minions의 전략은 이렇다:
- 1차 푸시 - 코드 작성 완료 후 CI 실행
- 자동 수정 - autofix 가능한 실패는 자동 적용
- 에이전트 재개입 - autofix 불가능한 실패는 다시 에이전트에게 전달, 로컬에서 수정
- 2차 푸시 - 수정 후 다시 CI 실행
- 사람에게 전달 - 2차 시도 후에도 실패하면 사람이 개입
왜 2번만?
무한 루프를 돌리면 토큰 비용, 컴퓨팅 비용, 시간이 모두 늘어난다. 그리고 2번 넘어가면 수익률이 체감(diminishing returns)한다. LLM이 계속 같은 실수를 반복할 가능성이 높기 때문이다.
이 밸런스가 Stripe에겐 최적이었다고 한다.
다른 도구들과 비교하면?
| 특징 | GitHub Copilot | Cursor | Claude Code | Stripe Minions |
|---|---|---|---|---|
| 자동완성 | ✅ 최고 수준 | ✅ 강력 | ✅ 좋음 | ❌ 해당없음 |
| 채팅 보조 | ✅ 기본 | ✅ 강력 | ✅ 최고 수준 | ❌ 해당없음 |
| 에이전트 모드 | ❌ 없음 | ✅ Composer (감독 필요) | ✅ 있음 (감독 필요) | ✅ 완전 자율 |
| 무인 작동 | ❌ | ❌ | ❌ | ✅ |
| PR 자동 생성 | ❌ | 부분적 | 부분적 | ✅ 전체 플로우 |
| CI 자동 수정 | ❌ | ❌ | ❌ | ✅ |
| 컨텍스트 관리 | 기본 | Rule files | CLAUDE.md | Rules + MCP + Toolshed |
| 대상 사용자 | 개인 개발자 | 개인/팀 | 개인/팀 | 기업 내부 |
써볼만한가?
솔직히 말하자면, Minions를 바로 쓸 순 없다. 이건 Stripe의 내부 도구다. 하지만 핵심 아이디어는 적용 가능하다:
- 인프라를 먼저 갖춰라 - 클라우드 개발 환경이 있으면 에이전트가 훨씬 안전하고 효과적이다
- Blueprint 패턴 - 전부 에이전트에게 맡기지 말고, 결정론적 코드와 섞어라
- 컨텍스트 표준화 -
.cursorrules같은 표준 포맷을 쓰면 여러 도구가 같이 쓸 수 있다 - MCP 활용 - 동적 정보 제공을 위해 MCP 서버를 구축하라
오픈소스 세계에서도 비슷한 시도가 있다:
- Goose - Minions의 기반이 된 Block의 오픈소스 에이전트 (Stripe가 fork함)
- Aider - 터미널 기반 AI 코딩 도구, git 통합이 좋음
- SWE-agent - 연구용이지만 엔드투엔드 작업 가능
결론: 개발자가 사라지진 않는다
Minions를 보고 “개발자 일자리가 위험하다”고 생각할 수 있다. 하지만 현실은 좀 다르다.
Minions가 하는 일:
- 반복적인 마이그레이션
- 린트 규칙 적용
- 간단한 버그 수정
- 타입 정의 업데이트
개발자가 여전히 해야 하는 일:
- 아키텍처 설계
- 복잡한 비즈니스 로직
- 코드 리뷰
- 시스템 전체 맥락 이해
- 보안 검토
Stripe 엔지니어들은 Minions 덕분에 지루한 작업에서 해방되어 더 중요한 일에 집중할 수 있게 됐다. 주니어 개발자가 하던 단순 작업을 AI가 대신하고, 주니어는 더 어려운 걸 배우고, 시니어는 더 전략적인 일에 집중한다.
그리고 흥미로운 점은, 인간 개발자 경험 향상에 투자한 것들이 모두 AI에게도 유용했다는 거다:
- 빠른 Devbox → AI도 빠르게 작업
- 좋은 문서 → AI도 잘 이해
- 빠른 피드백 루프 → AI도 빠르게 학습
- 명확한 린트 규칙 → AI도 따르기 쉬움
개발자 경험(DX)에 대한 투자가 AI 시대에 배당을 준 셈이다.
우리가 배울 점
Stripe Minions는 단순한 “AI가 코드 짜주는 도구” 그 이상이다. 이건 소프트웨어 엔지니어링의 미래 한 단면을 보여준다:
- 자동화 가능한 건 자동화하되, 사람이 검증한다
- 인프라가 중요하다 - 좋은 개발 환경이 좋은 AI 환경이다
- 점진적 도입 - 처음부터 완벽할 순 없다. 작은 것부터 시작하고 개선하라
- 표준을 따르라 - Cursor rules, MCP 같은 표준은 생태계를 만든다
2026년 현재, AI 코딩 에이전트는 이제 “실험”이 아니라 실전이다. Stripe에서 매주 1300개 PR이 AI 손에서 나온다. 이건 시작일 뿐이다.
당신의 팀에서도 “Minions 같은 거 만들어볼까?” 고민하고 있다면, 이 글이 힌트가 되길 바란다. 그리고 기억하자 - AI는 도구다. 중요한 건 그걸 어떻게 쓰느냐다.
참고 자료:
- Minions: Stripe’s one-shot, end-to-end coding agents—Part 2
- Minions: Stripe’s one-shot, end-to-end coding agents—Part 1
- Building Effective Agents - Anthropic
- Cursor Rules Documentation