---
title: "클로드 코드로 브레인스토밍부터 병합까지 돌리는 로컬 자율 개발 파이프라인"
published: 2026-05-19T23:35:23.000Z
canonical: https://jeff.news/article/3019
---
# 클로드 코드로 브레인스토밍부터 병합까지 돌리는 로컬 자율 개발 파이프라인

claude-autopilot은 클로드 코드 위에서 아이디어 정리, 스펙 작성, 계획, 구현, 마이그레이션, 검증, 풀 리퀘스트, 리뷰, 병합까지 이어주는 오픈소스 CLI다. 로컬 저장소와 사용자의 API 키로 동작하고, 위험도 기반 코드 리뷰, 다중 모델 검토, 테스트 게이트, 실행 상태 엔진을 내세운다.

## 로컬에서 도는 자율 개발 파이프라인

- `claude-autopilot`은 클로드 코드(Claude Code) 위에서 개발 작업을 끝까지 밀어붙이는 오픈소스 CLI임
  - 흐름은 브레인스토밍 → 스펙 → 계획 → 구현 → 마이그레이션 → 검증 → 풀 리퀘스트 → 리뷰 → 병합까지 이어짐
  - 설치는 `npm install -g @delegance/claude-autopilot@latest`로 하고, 라이선스는 MIT임
  - 요구사항은 Node 22 이상, 깃허브 CLI, 모델 API 키, 클로드 코드 CLI, superpowers 클로드 코드 플러그인임

- 핵심 포지션은 “호스팅 에이전트 서비스”가 아니라 “내 터미널에서 도는 자동화 파이프라인”임
  - 저장소는 사용자 머신에 남고, 별도 호스팅 워크스페이스나 원격 샌드박스를 쓰지 않음
  - 다만 모델 프롬프트, diff, 파일 컨텍스트는 설정한 LLM 제공자에게 전송될 수 있음
  - 완전 로컬만 원하면 클로드 코드 런타임과 리뷰 어댑터까지 전부 로컬 엔드포인트로 맞춰야 한다고 못 박음

> [!WARNING]
> “로컬에서 돈다”는 말이 곧 “모델 입력이 외부로 안 나간다”는 뜻은 아님. 클로드 코드 쪽 제공자 설정과 리뷰 어댑터 설정을 모두 로컬로 맞춰야 진짜 로컬 전용에 가까워짐.

- 데모 숫자는 꽤 공격적으로 제시됨
  - 파이썬 코드베이스에서 실제 자율 실행 한 번이 12분, 2.20달러, 신규 테스트 5개, 수동 개입 0회였다고 함
  - 넥스트.js 픽스처에 심은 13개 버그를 `claude-autopilot scan --all`과 Claude Opus 조합으로 13개 모두 잡았다고 주장함
  - 같은 세트에서 Sonnet은 보통 11개, Groq 경유 Llama 3.3 70B는 독립 테스트에서 8개를 잡았다고 밝힘

## 리뷰와 검증을 파이프라인에 박아 넣음

- 차별점으로 내세우는 건 위험도 기반 리뷰 깊이임
  - 스펙 frontmatter에 risk를 low, medium, high로 선언함
  - low는 코드엑스 리뷰 1회, medium은 2회, high는 3회 순차 리뷰를 돌림
  - 인증, 멀티테넌시, 샌드박싱, 과금, secret, 마이그레이션, 행 수준 보안, 배포·권한, 벡터 DB 테넌시 같은 키워드는 위험도를 자동으로 올리는 쪽으로 설계됨

- 단, 이 강제력은 하드 CLI 게이트라기보다 클로드 코드 스킬 지시문에 가까움
  - `.claude/skills/autopilot/SKILL.md`를 읽고 팀에 맞게 tier 규칙이나 자동 에스컬레이션 키워드를 바꿀 수 있음
  - 팀에서 정말 강제하고 싶으면 병합 단계나 CI에서 패스 횟수를 별도로 검증하도록 확장해야 함

- “멀티 모델 회의” 기능도 별도 명령으로 제공함
  - `claude-autopilot council`이 같은 diff나 설계 질문을 Claude, Codex, Gemini 같은 3개 이상 모델에 병렬로 던지고 합의를 요약함
  - 기본 파이프라인은 더 싸고 빠른 순차 코드엑스 리뷰를 쓰고, council은 더 높은 엄격도가 필요할 때 opt-in하는 구조임

- 자동 수정은 테스트 게이트와 묶여 있음
  - `claude-autopilot fix --verify`는 패치를 적용한 뒤 전체 테스트를 돌림
  - 테스트가 실패하면 변경을 되돌리는 방식이라, “수정 제안만 던지고 끝”인 도구보다 운영 흐름에 더 가깝게 붙음
  - Cursor BugBot이나 Copilot 댓글도 실제 버그와 오탐으로 나눠 triage하고, 실제 버그는 자동 수정하는 흐름을 내세움

## 실행 상태, 마이그레이션, 배포까지 범위를 넓힘

- v6의 실행 상태 엔진은 긴 자동화 실행을 파일 기반 상태 머신처럼 다룸
  - `.guardrail-cache/runs/<ulid>/events.ndjson`에 타입이 있는 이벤트를 계속 append함
  - 실행별 디렉터리, 상태, 비용, 마지막 단계, 이벤트 tail을 볼 수 있음
  - per-run 10달러, per-phase 5달러 같은 하드 예산 상한을 설정할 수 있음

- 마이그레이션 단계는 꽤 보수적으로 설계하려고 함
  - Rails, Alembic, Django, Prisma, Drizzle, golang-migrate, dbmate, Flyway, Supabase CLI, Ecto, TypeORM 등을 감지함
  - 구조화된 argv를 써서 셸 인젝션을 피하고, 프로덕션 실행에는 4개 플래그 기반 CI 게이트와 해시 체인 감사 로그를 둔다고 설명함
  - `none@1`로 아예 마이그레이션을 건너뛰는 설정도 가능함

- 배포는 기본 autopilot 경로가 아니라 opt-in 단계임
  - Vercel, Fly.io, Render, generic 어댑터를 제공함
  - 로그 스트리밍, 상태 확인, 헬스 체크 실패 시 bounded auto-rollback 같은 기능을 어댑터 계약으로 맞춤
  - 빌드 로그가 풀 리퀘스트 댓글로 나갈 때는 `AKIA`, `sk-`, `ghp_`, `xoxb-` 같은 패턴을 마스킹함

> [!IMPORTANT]
> 13개 버그를 모두 잡았다는 벤치마크는 “그 도구가 목표로 삼은 버그 카테고리를 심은 픽스처” 기준임. 현실 저장소 전체의 탐지율이나 오탐률을 그대로 보장하는 숫자는 아님.

## 개발팀 입장에서 볼만한 포인트

- 기존 도구 대비 포지셔닝은 “내 스택 그대로”임
  - `npm test`, `prisma migrate`, `gh pr create`처럼 터미널에서 되는 명령을 파이프라인 단계로 묶는 방식임
  - Devin이나 Factory처럼 호스팅 샌드박스에 코드를 올리는 모델과 선을 긋고 있음
  - Cursor나 Copilot agent mode처럼 단발성 에이전트가 아니라, 스펙과 계획, 검증, 리뷰 산출물을 디스크에 남기는 쪽을 강조함

- 팀용 대시보드는 아직 디자인 파트너 단계임
  - 실행 이력, 비용 집계, 멤버 관리를 위한 호스팅 대시보드는 초기 접근만 열려 있음
  - CLI는 대시보드 없이도 계속 완전히 쓸 수 있다고 설명함
  - v8.0.0에서는 호스팅 대시보드 업로드를 별도 optional 패키지로 빼서 로컬 전용 설치를 더 가볍게 만들 계획임

- 다음 버전에서 의존성 정리도 예고됨
  - v8.0.0부터 `tsx` 번들 fallback이 사라지고, 프로젝트 로컬 dev dependency로 설치하거나 전역 경로를 지정해야 함
  - Supabase 관련 optional dependency도 대시보드 업로드 패키지 분리와 함께 더 느슨해질 예정임

---
## 기술 맥락

- 이 도구가 IDE를 새로 만들지 않고 클로드 코드 스킬로 붙은 이유는, 개발팀이 이미 쓰는 터미널과 저장소 흐름을 그대로 타기 위해서예요. 새 워크스페이스로 코드를 옮기면 권한, secret, 테스트 환경, 네트워크 접근 같은 문제가 바로 생기거든요.

- 위험도 기반 리뷰는 비용과 품질 사이의 타협이에요. 모든 오타 수정에 3번 리뷰를 돌리면 돈과 시간이 새고, 인증이나 과금 변경을 1번만 보면 사고가 날 수 있으니까 변경 위험도에 따라 리뷰 강도를 바꾸는 거예요.

- 실행 상태 엔진이 중요한 이유는 자율 개발 파이프라인이 한 번에 끝나지 않을 수 있기 때문이에요. 중간에 프로세스가 죽거나 예산이 초과되거나 외부 API 상태가 애매해졌을 때, 파일로 남은 이벤트와 참조를 보고 어디까지 갔는지 판단해야 해요.

- 마이그레이션과 배포를 opt-in으로 둔 것도 현실적인 선택이에요. 코드 수정은 되돌리기 쉬운 편이지만 데이터베이스와 프로덕션 배포는 부작용이 훨씬 크기 때문에, 팀별 게이트와 감사 로그를 붙일 여지를 남긴 거예요.

- 벤치마크는 유용하지만 해석을 조심해야 해요. 13개 버그를 모두 잡았다는 건 타깃 카테고리 재현성에는 의미가 있지만, 실제 서비스 코드의 오탐률, 도메인 특화 버그, 레거시 패턴까지 다 커버한다는 뜻은 아니에요.

## 핵심 포인트

- 로컬 CLI로 동작하며 호스팅 에이전트나 원격 샌드박스를 쓰지 않음
- 스펙 위험도에 따라 코드엑스 리뷰를 1회, 2회, 3회로 늘리는 정책 기반 리뷰를 제공함
- 13개 보안·품질 버그가 심어진 넥스트.js 픽스처에서 클로드 오퍼스 기준 13개 모두 탐지했다고 주장함
- 실행 상태를 디스크에 남기고 예산 상한, 재시작, JSON 이벤트, CI 연동을 지원함

## 인사이트

이 도구의 재미있는 지점은 “코딩 에이전트”라기보다, 이미 쓰는 터미널·테스트·깃허브 흐름 위에 LLM 단계를 촘촘히 엮은 파이프라인이라는 점이다. 다만 리뷰 강제력이 하드 게이트가 아니라 스킬 지시문에 가까운 부분은 팀에서 그대로 믿기보다 CI 정책으로 보강해야 한다.