이 글에서 사용하는 주요 용어 정의
| 백그라운드 에이전트 | 메인 세션과 별도로 뒤에서 계속 작업을 진행하는 서브에이전트 |
| Worktree | 하나의 저장소에서 별도 브랜치를 독립된 디렉터리로 체크아웃하는 Git 기능 |
| Draft PR | 아직 리뷰 준비가 끝나지 않았음을 표시하는 초안 상태의 Pull Request |
| MCP(Model Context Protocol) | 에이전트가 외부 도구·데이터에 JSON-RPC로 접근하게 해주는 프로토콜 |
| stdio 서버 | 표준입출력을 통해 로컬에서 실행되는 MCP 서버 방식 |
| scope(범위) | MCP 서버 설정을 저장할 범위(local/user/project) 지정 옵션 |
도입
Claude Code를 "코드를 대신 짜주는 도구"에서 "혼자 일을 처리하는 에이전트"로 완성시키는 두 조각이 있습니다. 하나는 작업이 끝나면 알아서 커밋·푸시·PR까지 만드는 백그라운드 자동화이고, 다른 하나는 외부 시스템에 실제로 접근할 수 있게 해주는 MCP 연결입니다. 둘 중 하나만 있으면 반쪽짜리입니다. 백그라운드 자동화만 있으면 GitHub 이슈를 직접 읽고 반영할 방법이 없고, MCP만 있으면 작업이 끝난 뒤 사람이 일일이 커밋·PR을 만들어야 합니다. 오늘은 이 두 기능을 각각 자세히 살펴보고, 함께 썼을 때 어떤 그림이 나오는지 정리해보겠습니다.
첫 번째 조각 — 백그라운드 서브에이전트 자동 PR
무엇이 달라졌나
2026년 7월 1일 배포된 Claude Code v2.1.198부터, 백그라운드로 실행되는 서브에이전트가 작업을 마치면 사람에게 확인받지 않고 직접 커밋 → 푸시 → Draft PR 생성까지 끝냅니다. 이전에는 서브에이전트가 코드를 다 작성해도 이를 커밋하고 푸시하고 PR을 여는 과정은 사람이 처리해야 했습니다.
[claude agents로 작업 위임]
│
▼
[worktree에서 독립적으로 코드 작성]
│
▼
[작업 완료]
│
├─→ git commit (자동)
├─→ git push (자동)
└─→ Draft PR 생성 (자동)
│
▼
[사람은 "리뷰 가능한 PR"만 확인하면 됨]실행과 알림
# 백그라운드 에이전트에게 기능 구현을 위임
claude agents run "결제 모듈 리팩터링 진행하고, 완료되면 알려줘"같은 릴리즈에서 백그라운드 에이전트 알림 기능도 함께 추가되어, 입력이 필요하거나 작업이 끝나면 Notification 훅이 agent_needs_input / agent_completed 이벤트로 발동합니다. 여러 서브에이전트를 동시에 돌려도 각자 알아서 PR까지 정리해주고, 끝난 순서대로 알림을 받을 수 있습니다.
장점과 한계
| 장점 | 작업 완료 후 수동으로 커밋·푸시·PR 생성하던 단계를 완전히 생략 |
| 장점 | 여러 백그라운드 에이전트를 동시에 돌려도 각자 PR까지 정리 |
| 주의사항 | 자동 커밋·푸시가 기본값이라, 원치 않는 브랜치에 푸시될 위험을 우려하는 목소리도 있음 |
| 주의사항 | 실제로 GitHub 이슈에는 이 자동 커밋/푸시/PR 기능을 끌 수 있는 설정을 요청하는 의견도 올라와 있음 |
두 번째 조각 — MCP 서버 연동
MCP가 뭔가, Skill과 뭐가 다른가
| 역할 | 지식(Knowledge) — 어떻게 할지 아는 지침 | 행동(Action) — 실제로 무언가를 수행 |
| 형태 | SKILL.md + 보조 스크립트 | 실행 가능한 서버 프로세스 |
| 통신 방식 | Claude가 마크다운을 읽고 참고 | JSON-RPC로 실제 함수 호출 |
| 예시 | "PR 리뷰 시 이 체크리스트를 확인" | GitHub API로 실제 PR 코멘트 작성 |
Skill이 "요리 레시피"라면, MCP는 "실제로 재료를 썰고 불을 켜는 손"에 해당합니다. 백그라운드 자동 PR이 아무리 강력해도, GitHub 이슈를 읽고 관련 코드를 찾아 반영하려면 결국 GitHub에 실제로 접근하는 통로가 필요한데, 그 통로가 MCP입니다.
등록 명령과 범위 설정
# 로컬 stdio 서버(npm 패키지) 등록
claude mcp add github -- npx -y @modelcontextprotocol/server-github
# 원격 HTTP 서버 등록
claude mcp add --transport http my-server https://example.com/mcp# 현재 프로젝트에서만, 나만 사용 (기본값)
claude mcp add github -- npx -y @modelcontextprotocol/server-github
# 내 모든 프로젝트에서 공통으로 사용
claude mcp add --scope user github -- npx -y @modelcontextprotocol/server-github
# 팀원과 공유 (프로젝트 루트 .mcp.json에 저장, git 커밋됨)
claude mcp add --scope project github -- npx -y @modelcontextprotocol/server-github옵션(--transport, --env, --scope 등)은 서버 이름보다 앞에 오고, --(더블 대시) 뒤에는 실제 실행할 명령과 인자를 적습니다. --scope project로 등록하면 .mcp.json이 저장소에 커밋되어 팀원들도 동일한 MCP 서버를 그대로 쓸 수 있습니다.
동작 흐름
claude mcp add 실행
│
▼
설정 파일에 서버 정의 저장 (local/user/project)
│
▼
세션 시작 시 Claude Code가 정의를 읽음
│
▼
서버 실행/연결 → 사용 가능한 도구 목록 조회
│
▼
Claude가 필요할 때 해당 도구를 실제로 호출두 기능을 함께 쓰는 실전 워크플로우
두 기능을 조합하면 "이슈 확인 → 구현 → PR 오픈"까지 사람 개입 없이 이어지는 흐름을 만들 수 있습니다.
1. GitHub MCP 서버로 열려 있는 이슈 목록을 확인
→ "server-github"가 실제로 GitHub API를 호출해 이슈를 가져옴
2. 백그라운드 에이전트에게 특정 이슈 해결을 위임
claude agents run "이슈 #482 버그 고치고 완료되면 알려줘"
3. 에이전트가 worktree에서 독립적으로 코드 수정
4. 작업 완료 시 자동으로 커밋 → 푸시 → Draft PR 생성
(Notification 훅으로 agent_completed 알림 수신)
5. MCP GitHub 서버를 통해 생성된 PR에 자동으로 코멘트나 라벨 추가도 가능이 조합의 핵심은 MCP가 "무엇을 봐야 하는지"를 알려주고, 백그라운드 자동화가 "본 것을 실제 결과물로 만드는" 역할을 나눠 맡는다는 점입니다.
함께 쓸 때 주의할 점
- MCP로 외부 시스템에 접근 권한을 부여한 상태에서 백그라운드 자동 커밋·푸시까지 켜두면, 사람이 확인하지 않은 변경이 실제 저장소에 반영되는 범위가 넓어집니다. 팀 저장소에서는 브랜치 보호 규칙과 리뷰 필수화를 함께 설정하는 것이 안전합니다.
- MCP 서버 자체도 신뢰할 수 있는 출처(공식 패키지, 검증된 저장소)인지 확인한 뒤 등록하는 것이 좋습니다.
마무리
백그라운드 자동 PR은 "작업 이후"를 자동화하고, MCP는 "작업에 필요한 정보 접근"을 자동화합니다. 두 기능을 각각 알고 있는 것과, 조합해서 하나의 파이프라인으로 쓰는 것은 체감 생산성 차이가 큽니다. 다만 자동화 범위가 넓어지는 만큼, 팀 저장소에서 도입할 때는 브랜치 보호·리뷰 규칙 등 안전장치를 함께 갖추고 시작하시길 권해드립니다.
참고 자료
'AI' 카테고리의 다른 글
| Codex CLI Terminal-Bench 91.9% 달성, 실제 체감 차이는 뭘까 (0) | 2026.07.27 |
|---|---|
| Claude Code 안전하게 오래 쓰는 법, Plan Mode·체크포인트·컨텍스트 압축 3종 세트 (1) | 2026.07.26 |
| Claude Code Skills, Hooks, Subagents, MCP 언제 뭘 써야 할까 (0) | 2026.07.26 |
| Claude Code Hooks 완전정리, PreToolUse·PostToolUse로 자동화하는 법 (0) | 2026.07.25 |
| Claude Cowork 기능이란? 멀티디바이스 AI 협업 한 번에 이해하기 (0) | 2026.07.23 |
