PR을 고치는 루프가 생겼다: VS Code 1.136 Agent Merge의 자동 병합 경계

코딩 에이전트가 pull request를 만들었다고 일이 끝나는 건 아니다. 리뷰 댓글이 새로 달리고, 필수 CI가 깨지고, 그 사이 base branch가 앞서가면 다시 충돌을 풀어야 한다. 지금까지는 사람이 이 상태를 확인한 뒤 에이전트를 다시 불러 같은 일을 이어 붙이는 경우가 많았다.

9월 2일 공개된 Visual Studio Code 1.136의 Agent Merge는 이 마지막 구간을 반복 작업으로 만든다. PR에 연결된 agent session을 감시하고, 선택한 차단 요인이 남아 있으면 에이전트에게 다시 수정을 맡긴다. 리뷰 대응, 필수 CI 수정, branch update와 conflict 해결을 반복한 뒤 설정에 따라 merge 또는 merge queue 진입까지 이어갈 수 있다. 다만 이 기능은 Preview이고 기본값도 꺼져 있다. 이름만 보고 "안전하게 알아서 합쳐 주는 버튼"으로 이해하면 실제 권한 변화와 종료 조건을 놓치기 쉽다.

요약: Agent Merge는 병합 버튼이 아니라 상태 루프다

Agent Merge가 보는 입력은 PR의 현재 상태다. unresolved review thread, changes-requested review, maintainer나 Copilot PR reviewer의 새 댓글, 실패한 required check, 뒤처진 branch와 merge conflict를 선택적으로 처리한다. 각 차단 요인을 고친 뒤에는 workflow를 다시 돌리고, 필수 검사가 진행 중이면 기다린다. 병합 직전에도 PR이 준비됐는지 한 번 더 확인한다.

Agent Merge는 PR blocker를 다시 읽고 repair turn을 반복한다. 기본 설정에서는 마지막 병합을 자동으로 수행하지 않는다. 출처: code.visualstudio.com/docs/agents/run/agents-window#_finish-a-pull-request-with-agent-merge.

이 구조의 장점은 명확하다. 사람에게 "CI 다시 깨졌어요"라고 알려 주고 다음 지시를 기다리는 대신, 같은 session이 수정과 검증을 이어 간다. 반대로 한 번의 요청이 몇 차례 agent turn과 model request로 늘어날 수 있다. 자동화 범위는 Agent Merge를 켰다는 사실이 아니라 어떤 blocker를 선택했고, 마지막 merge 권한을 어디까지 줬는지로 정해진다.

기본 설정을 보면 보수적인 경계가 보인다

기능 자체를 여는 chat.agentMerge.enabled의 기본값은 false다. 켠 뒤에도 PR과 연결된 session에서 Agent Merge를 따로 활성화해야 한다. 공식 설정표에서 리뷰 대응, 필수 CI 수정, 충돌 해결은 각각 기본 true지만, 실제 자동 병합을 정하는 chat.agentMerge.mergePullRequest는 기본값이 never다.

자동 병합 선택지는 세 가지다. always는 선택한 유지보수 작업이 끝나면 병합하거나 merge queue에 넣는다. ifUnchanged는 Agent Merge의 repair turn이 PR을 바꾸기 전까지만 자동 병합한다. never는 수정 루프만 돌리고 마지막 병합은 남겨 둔다. merge method의 auto는 저장소가 허용하는 방식 중 squash, merge commit, rebase 순서로 처음 맞는 방식을 고른다. 특정 이력 정책이 있다면 auto에 맡기기보다 저장소 규칙과 같은 방법을 명시하는 편이 낫다.

수정 자동화와 병합 자동화는 별도 설정이다. 기능은 기본 꺼짐이고, mergePullRequest의 기본값은 never다. 출처: code.visualstudio.com/docs/agents/reference/ai-settings#_agent-sessions.

리뷰 thread 답글에는 자동 응답 attribution을 붙이는 설정도 기본으로 켜져 있다. 이 표시는 작은 기능처럼 보이지만, 사람이 쓴 답변과 에이전트가 남긴 답변을 구분하는 운영 기록이다. 자동화가 리뷰 대화에 직접 글을 쓰는 만큼 끄기 전에 감사와 책임 추적 방식을 먼저 정해야 한다.

활성화 순간 session의 권한도 바뀐다

공식 문서의 주의 문구는 Agent Merge가 agent turn을 시작하고, PR branch를 변경·동기화하며, model request를 소비한다고 적는다. 활성화하면 해당 session은 Autopilot과 Assisted permission으로 바뀐다. 단순 알림 기능이 아니라, repository에 쓰기를 수행하는 반복 실행으로 전환되는 셈이다.

Assisted는 모든 명령을 무조건 승인한다는 뜻은 아니다. VS Code 권한 문서의 정의와 실제 조직 정책, terminal·browser·MCP 도구의 승인 규칙을 함께 봐야 한다. 특히 branch protection, required checks, CODEOWNERS 같은 GitHub 쪽 통제는 에이전트 prompt와 별개로 유지해야 한다. 모델이 "준비됐다"고 판단하는 것과 저장소가 병합 조건을 충족했다고 판정하는 것을 같은 증거로 취급하면 안 된다.

비용 경계도 있다. 리뷰 댓글 하나, CI 실패 하나가 각각 새 repair turn을 부를 수 있다. Preview 단계에서는 session별 model request 수, 실행 시간, 수정 commit 수를 기록해 둬야 어떤 종류의 feedback이 루프를 길게 만드는지 볼 수 있다. 자동 병합 시간을 줄였더라도 review churn이나 테스트 비용이 늘면 전체 이득은 달라진다.

루프가 잘못된 대상을 따라가지 않게 만든 장치

Agent Merge는 session이 다른 branch나 PR을 추적하기 시작하면 자동으로 꺼지고, 다시 명시적으로 활성화해야 한다. 이 조건은 중요하다. 이전 PR에 준 자동화 승인이 새 PR로 조용히 넘어가면 승인 범위가 바뀌기 때문이다.

필수 검사가 pending일 때 기다리고, merge 또는 merge queue 진입 직전에 readiness를 재확인하는 것도 같은 이유다. 하지만 문서가 보장하는 것은 이 재확인 절차이지, 테스트가 충분하거나 리뷰 기준이 완전하다는 사실은 아니다. 저장소가 required로 지정하지 않은 보안 검사나 수동 승인 절차는 Agent Merge가 알아서 필수 조건으로 만들어 주지 않는다.

따라서 stop 조건을 저장소 밖에도 둬야 한다. 같은 check가 일정 횟수 이상 실패하거나, diff 규모가 임계치를 넘거나, 민감 경로가 바뀌면 자동 repair를 중단하고 사람에게 넘기는 방식이다. 공식 문서에는 이런 사용자 정의 예산이 Agent Merge의 기본 기능으로 명시돼 있지 않다. 조직의 workflow나 관측 도구로 보완해야 한다.

실전 적용: 자동 수정과 자동 병합을 분리한다

첫 도입에서는 mergePullRequest=never로 둔 채 리뷰 대응과 CI 수정만 시험하는 편이 안전하다. 작은 저장소의 낮은 위험 PR을 골라 Agent Merge가 만든 commit, 답글 attribution, check 재실행, conflict 해결을 하나씩 확인한다. 사람이 마지막 diff를 읽고 병합한다면 repair loop의 품질을 자동 merge 위험과 분리해 평가할 수 있다.

그다음 실패 조건을 일부러 넣는다. required test를 깨뜨리고, base branch를 앞서게 만들고, changes-requested review를 남긴다. 각 상태가 어떤 agent turn을 만들며 어떤 권한 prompt가 나타나는지 기록한다. branch나 PR을 바꿨을 때 Agent Merge가 실제로 꺼지는지도 확인한다.

ifUnchanged는 이름을 정확히 읽어야 한다. repair turn이 PR을 변경했다면 자동 병합하지 않는 보수적 선택이다. 단순히 check가 늦게 끝난 경우와 코드가 바뀐 경우를 나눌 수 있다. 충분한 시험 뒤에도 자동 병합이 필요하다면 이 모드부터 검토하고, always는 저장소의 required checks와 merge queue, 소유자 승인 규칙이 이미 단단한 경우에만 좁게 적용하는 편이 좋다.

관측 항목은 병합 성공률 하나로 끝내지 않는다. PR당 agent turn과 model request, CI 재실행 횟수, 자동 수정 뒤 사람이 추가한 변경, revert와 incident를 함께 본다. 빠르게 merge됐다는 숫자만 보면 잘못된 수정이 더 빨리 통과한 경우를 구분할 수 없다.

범위와 주의점

이 글은 VS Code 1.136 릴리스 노트와 현재 공식 Agents window·설정·권한 문서를 바탕으로 했다. Agent Merge는 Preview라 동작과 설정이 바뀔 수 있다. 이 글을 위해 실제 GitHub 저장소에서 장시간 repair loop나 자동 병합을 독립 재현하지는 않았다.

또한 Agent Merge가 해결하는 범위는 PR에 드러난 blocker다. 테스트 설계의 누락, 잘못된 요구사항, required로 등록되지 않은 보안 검사까지 발견한다는 보장은 없다. 그래서 첫 운영 목표는 사람을 병합 과정에서 없애는 것이 아니라, 반복 가능한 수정 루프와 마지막 승인 사이의 경계를 선명하게 만드는 데 둬야 한다.

참고 자료

• https://code.visualstudio.com/updates/v1_136
• https://code.visualstudio.com/docs/agents/run/agents-window#_finish-a-pull-request-with-agent-merge
• https://code.visualstudio.com/docs/agents/reference/ai-settings#_agent-sessions
• https://code.visualstudio.com/docs/agents/run/approvals#_how-autopilot-works
• https://code.visualstudio.com/docs/agents/run/approvals#_permission-levels