클로드 코드로 브레인스토밍부터 병합까지 돌리는 로컬 자율 개발 파이프라인

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

• claude-autopilot은 클로드 코드(Claude Code) 위에서 개발 작업을 끝까지 밀어붙이는 오픈소스 CLI임

  • 흐름은 브레인스토밍 → 스펙 → 계획 → 구현 → 마이그레이션 → 검증 → 풀 리퀘스트 → 리뷰 → 병합까지 이어짐
  • 설치는 npm install -g @delegance/claude-autopilot@latest로 하고, 라이선스는 MIT임
  • 요구사항은 Node 22 이상, 깃허브 CLI, 모델 API 키, 클로드 코드 CLI, superpowers 클로드 코드 플러그인임

• 핵심 포지션은 “호스팅 에이전트 서비스”가 아니라 “내 터미널에서 도는 자동화 파이프라인”임

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

• 데모 숫자는 꽤 공격적으로 제시됨
  • 파이썬 코드베이스에서 실제 자율 실행 한 번이 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- 같은 패턴을 마스킹함

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

• 기존 도구 대비 포지셔닝은 “내 스택 그대로”임

  • 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개 버그를 모두 잡았다는 건 타깃 카테고리 재현성에는 의미가 있지만, 실제 서비스 코드의 오탐률, 도메인 특화 버그, 레거시 패턴까지 다 커버한다는 뜻은 아니에요.