에이전트
GitHub Agent Merge: Copilot이 풀 리퀘스트를 대신 고칠 수 있을까
GitHub의 Agent Merge는 실패한 Actions 워크플로와 병합 충돌을 풀 리퀘스트에서 감시한다. 작동 방식, 비용, 한계를 정리한다.
풀 리퀘스트가 리뷰 준비를 마친 순간 GitHub Actions 워크플로가 실패한다. 원인을 조사하는 사이 기본 브랜치가 바뀌면서 병합 충돌까지 생긴다. GitHub의 Agent Merge는 이런 걸림돌을 감시하다가, 개발자가 다른 일을 하는 동안 해결 작업을 시작하도록 설계됐다.
10월 28일 GitHub는 github.com의 풀 리퀘스트 병합 상자에 Agent Merge를 직접 넣었다. Copilot은 실패한 Actions 워크플로, 병합 충돌, 또는 둘 다를 감시할 수 있다. 선택한 걸림돌이 나타나면 백그라운드에서 작업하며, 변경 사항을 검토하고 저장소의 병합 요건을 충족하는 일은 여전히 사용자의 몫이다(GitHub).
Agent Merge가 하는 일
GitHub에서 Agent Merge는 클라우드의 Copilot에 속한 기능이다. 풀 리퀘스트에서 기능을 켜고 처리할 걸림돌을 고르면, Copilot이 걸림돌을 감지했을 때 수리를 시도한다. GitHub는 에이전트가 시작된 이유를 풀 리퀘스트 타임라인에 올린다(GitHub Docs).
| 걸림돌 | Copilot이 할 수 있는 일 |
|---|---|
| 실패한 GitHub Actions 워크플로 | 원인을 조사하고 수정을 시도 |
| 병합 충돌 | 풀 리퀘스트 브랜치와 기본 브랜치 사이의 충돌 해결을 시도 |
수리 시도가 성공을 보장하지는 않는다. 테스트는 잘못된 단언문, 의존성 문제, 실제 회귀 때문에 실패할 수 있다. 충돌은 두 가지 유효한 변경이 맞붙은 경우일 수 있고, 이때 의도된 동작은 텍스트만으로 분명하지 않다. 변경을 받아들이기 전에 결과 diff를 확인하고 관련 검사를 다시 실행하거나 살펴봐야 한다.
GitHub에서 켜는 방법
클라우드의 Copilot을 쓸 수 있는 유료 Copilot 요금제가 필요하다. 조직이나 엔터프라이즈를 통해 접근 권한을 받는다면 해당 조직의 정책이 클라우드 기능을 허용해야 한다. 저장소의 Copilot 정책 Enable automations도 켜져 있어야 한다(GitHub Docs).
- GitHub에서 풀 리퀘스트를 연다.
- 병합 상자에서 Watch and fix를 선택한다.
- Fix failed Actions workflows, Resolve merge conflicts 또는 둘 다 고른다.
- 병합 상자와 풀 리퀘스트 타임라인에서 Agent Merge의 업데이트를 확인한다.
- Copilot이 만든 변경을 검토하고 워크플로 결과를 확인한다.
Settings → Copilot → Cloud에서 사용자가 만드는 풀 리퀘스트에 기본으로 켜 둘 수도 있다. 개별 풀 리퀘스트에서 멈추려면 병합 상자에서 Unassign Copilot을 선택한다. GitHub는 이 기능이 스택형 풀 리퀘스트와 포크에서 연 풀 리퀘스트를 지원하지 않는다고 밝힌다.
Agent Merge가 풀 리퀘스트를 병합할까
GitHub의 클라우드 기능은 풀 리퀘스트를 준비하고 유지할 뿐이다. 이 기능을 켠다고 자동 병합이 켜지지는 않는다. GitHub의 별도 자동 병합 기능을 Agent Merge와 함께 쓸 수 있으며, 이 경우 저장소가 요구하는 리뷰와 검사를 충족하면 병합된다(GitHub Docs).
이 구분은 중요하다. 자동 병합을 켜 두었다면 수리가 성공한 뒤 설정된 요건이 충족되는 즉시 병합될 수 있다. 수동 확인 단계가 항상 한 번 더 있으리라고 가정하지 말고 저장소 규칙과 제안된 변경을 검토해야 한다.
Copilot 앱의 경험은 다르다. GitHub에 따르면 앱 버전은 리뷰 댓글에도 대응할 수 있고, GitHub가 허용하면 풀 리퀘스트를 병합할 수도 있다. VS Code도 자체 옵션을 갖춘 실험적 Agent Merge 경험을 문서로 안내한다. 이런 환경을 GitHub의 Watch and fix와 같다고 봐서는 안 된다(GitHub Docs; VS Code).
비용은 얼마인가
Agent Merge의 클라우드 기능에는 유료 Copilot 요금제가 필요하다. AI 크레딧 사용량은 풀 리퀘스트에서 기능을 켠 사람에게 청구되며, 이 사람이 풀 리퀘스트 작성자와 다를 수도 있다. GitHub는 Agent Merge 문서에서 수리 한 건당 고정 비용을 밝히지 않는다. 사용량은 작업 내용과 사용된 모델에 따라 달라진다(GitHub Docs).
GitHub의 개인 청구 문서는 Copilot Pro를 월 10달러, Pro+를 39달러, Max를 100달러로 안내하며 요금제마다 포함된 AI 크레딧 허용량이 다르다. 이는 요금제 가격이지 Agent Merge 요금이 아니다. 수리 한 번에 소비되는 양은 해당 허용량과 청구 규칙 안에서 따로 집계되는 사용량이다(GitHub billing). 널리 켜기 전에 사용량 대시보드와 요금제 약관을 확인해야 한다.
수정은 어디에서 실행되나
Agent Merge는 클라우드의 Copilot에 속하지만, GitHub에 따르면 수정은 클라우드 샌드박스가 아니라 GitHub Actions 기반 개발 환경에서 실행된다. 저장소의 사용자 지정 지침, 에이전트 스킬, .github/workflows/copilot-setup-steps.yml의 설정 단계를 활용할 수 있다(GitHub Docs).
따라서 저장소의 설정이 결과에 영향을 준다. 빠진 의존성이나 부정확한 지침은 에이전트가 보는 내용을 바꿀 수 있다. 테스트, 권한, 워크플로 설정에 영향을 주는 변경은 특히 주의해서 봐야 한다. 녹색 검사 표시는 유용하지만 워크플로의 원래 의도나 보안이 유지됐다는 증거는 아니다.
우리의 시각
Agent Merge는 익숙한 마찰, 즉 검사를 기다리다 실패를 확인하고 병합 가능한 상태로 만들려고 브랜치로 돌아가는 일을 겨냥한다. 1인 개발자나 소규모 팀에게는 백그라운드 수리가 그런 흐름 끊김을 줄여 줄 수 있다.
가치는 제안되는 수정의 품질과 그것을 검증하는 데 드는 시간에 달려 있다. 검사가 명확한 풀 리퀘스트에서 시작하고, 처리할 걸림돌 유형만 골라 켜고, 에이전트의 diff를 원래 목표와 비교하자. 크레딧 사용량도 리뷰 시간과 함께 추적하자. 의미 있는 결과는 올바른 검사를 통과하는, 정확하고 유지보수하기 쉬운 변경이지 단순히 녹색이 된 병합 상자가 아니다.
출처
- GitHub, Agent Merge on pull requests, 2026년 10월 28일
- GitHub Docs, getting pull requests ready with Agent Merge, 확인일: 2026년 10월 29일
- GitHub Docs, managing pull requests in the Copilot app, 확인일: 2026년 10월 29일
- VS Code, Agents window, 확인일: 2026년 10월 29일
- GitHub Docs, individual Copilot billing, 확인일: 2026년 10월 29일
