PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우

이경규·2026년 9월 8일

PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우

AI Coding Agent의 역할은 지금까지 주로 Pull Request를 만드는 것에 집중돼 있었다.

Issue
  ↓
Agent
  ↓
Repository 조사
  ↓
구현
  ↓
Test
  ↓
Pull Request
  ↓
Human Review

그런데 실제 개발에서는 PR을 만드는 순간 일이 끝나지 않는다.

오히려 그다음부터 일이 시작되는 경우가 많다.

Reviewer Comment 7개

CI 2개 실패

base branch 변경

Merge Conflict 발생

수정 후 다시 CI

새로운 Review Comment

또 수정

작은 기능 하나라도 PR이 Merge되기까지 몇 시간에서 며칠이 걸린다.

2026년 9월 2일 공개된 VS Code 1.136에는 이 마지막 구간을 Agent에게 맡기는 Agent Merge Preview가 추가됐다. VS Code는 Agent Merge를 “PR을 merge-ready 상태까지 가져가는 기능”으로 설명한다. Agent가 Review Feedback을 처리하고, Required CI 실패를 수정하고, Base Branch와 충돌하면 최신 상태로 맞추고 Merge Conflict를 해결한 뒤 필요한 Workflow를 다시 실행한다. 이 과정을 PR이 Merge 가능한 상태가 될 때까지 반복한다.

이건 생각보다 큰 변화다.

Coding Agent가:

코드를 만드는 Agent

에서:

Software Change를 끝내는 Agent

로 이동하고 있기 때문이다.

1. 개발에서 가장 긴 시간은 코딩이 아닐 수도 있다

예를 들어 Feature 구현 자체는 Agent가 20분 만에 끝냈다고 하자.

하지만 실제 흐름은 이렇게 된다.

20분
구현

↓

15분
CI

↓

2시간
Reviewer 확인 대기

↓

Review Comment

↓

20분
수정

↓

15분
CI

↓

Base Branch 변경

↓

Conflict

↓

다시 수정

↓

다시 Review

코드 작성 시간은 전체 Lead Time의 일부일 뿐이다.

AI Coding Agent가 구현 속도를 크게 올리면 오히려 새로운 병목이 생긴다.

Coding Throughput
↑↑↑

PR Merge Throughput
→

Agent는 PR을 빠르게 만들어내는데 사람이 Review하고 CI 실패를 정리하고 Conflict를 처리하는 속도는 그대로인 것이다.

Agent Merge는 정확히 이 지점을 노린다.

2. Agent Merge가 실제로 하는 일

현재 VS Code Agent Merge가 처리할 수 있는 영역은 크게 네 가지다.

Review Feedback

Failed Required Checks

Merge Conflicts

Final Merge / Merge Queue

구체적으로는 PR에서 해결되지 않은 Review Thread, changes requested Review, Repository Maintainer나 Copilot Reviewer가 남긴 새로운 Comment를 Agent가 읽고 대응할 수 있다. Required CI Check가 실패하면 원인을 조사해 수정하고 Workflow를 다시 실행할 수 있으며, Branch가 Base Branch보다 뒤처지면 업데이트하고 Conflict를 해결할 수도 있다. 설정에 따라 마지막 Merge 또는 Merge Queue 등록까지 가능하다.

즉 기존 구조:

Agent
  ↓
PR
  ↓
사람
  ↓
Review 대응
  ↓
CI 대응
  ↓
Conflict 해결
  ↓
Merge

가:

Agent
  ↓
PR
  ↓
Agent Merge
  │
  ├─ Review 대응
  ├─ CI 수정
  ├─ Conflict 해결
  ├─ Workflow 재실행
  └─ Merge-ready 확인
  ↓
Human Gate
  ↓
Merge

로 바뀐다.

3. 사실 완전히 새로운 기능 하나가 갑자기 생긴 것은 아니다

VS Code에서는 이전부터 PR의 Failed CI를 확인하고 Agent에게 Fix Checks를 요청하거나 새 Review Comment를 Address Comments로 넘기는 흐름이 발전해왔다.

1.136의 Agent Merge는 이 각각의 작업을 지속적인 Loop로 묶었다는 점이 중요하다.

예전:

CI 실패
→ 사람이 Fix Checks 클릭

Comment 도착
→ 사람이 Address Comments 클릭

Conflict 발생
→ 사람이 다시 Agent 호출

지금:

Agent Merge ON
       ↓
PR 상태 감시
       ↓
Blocker 발생
       ↓
Agent 실행
       ↓
수정
       ↓
Push
       ↓
Check
       ↓
새 Blocker?
       │
      YES
       ↓
다시 처리

Agent가 PR 상태를 지속적으로 관리하는 Worker가 된 것이다.

4. PR 자체가 하나의 장기 실행 Task가 된다

기존 Agent Task:

"로그인 버그 수정해."

Agent Merge 이후에는 실제 Task Boundary가 더 길어진다.

로그인 버그 수정

↓

PR 생성

↓

Reviewer 요청 반영

↓

CI 안정화

↓

Base Branch 최신화

↓

Conflict 해결

↓

최종 Required Checks 통과

이 전체가 하나의 작업이 된다.

즉 Agent가 다루는 단위가:

Code Change

에서:

Pull Request Lifecycle

로 올라간다.

그리고 이 변화는 상당히 중요하다.

5. 실제로 VS Code에서 사용하는 방법

현재 Agent Merge는 Preview 기능이다.

먼저 설정에서 활성화한다.

{
  "chat.agentMerge.enabled": true
}

PR과 연결된 Agent Session을 연 뒤 Agents Window에서 Agent Merge를 활성화한다.

Command Palette에서는:

Enable Agent Merge for Active Session

또는:

Configure Agent Merge for Active Session

을 사용할 수 있다.

Agent Merge 메뉴에서는 어느 작업까지 Agent에게 허용할지도 정할 수 있다.

6. 설정을 보면 Agent Merge의 설계가 더 잘 보인다

현재 관련 주요 설정은 다음과 같다.

{
  "chat.agentMerge.enabled": true,

  "chat.agentMerge.addressReviews": true,

  "chat.agentMerge.fixCI": true,

  "chat.agentMerge.resolveConflicts": true,

  "chat.agentMerge.mergePullRequest": "never",

  "chat.agentMerge.mergeMethod": "auto",

  "chat.agentMerge.replyAttribution": true
}

여기서 특히 중요한 것이:

mergePullRequest

다.

현재 선택지는:

always

ifUnchanged

never

다.

개발팀에서 처음 도입한다면 never부터 시작하는 편이 좋다.

Agent
→ Merge-ready까지

Human
→ 실제 Merge

경계를 유지하는 것이다.

7. 왜 처음부터 자동 Merge까지 켜지 않는 게 좋을까

Agent가 다음을 해결했다고 하자.

Review Comment
PASS

CI
PASS

Merge Conflict
해결

Required Checks
PASS

그러면 안전할까?

반드시 그렇지는 않다.

예를 들어 CI를 고친 방법이:

깨지는 테스트의 assertion 수정

일 수도 있다.

Reviewer의 Comment를 해결한 방법이:

원래 의도와 다른 우회 구현

일 수도 있다.

Conflict를 해결하면서:

Base Branch의 중요한 변경 삭제

가 발생할 수도 있다.

기계적으로는 모두 PASS인데 제품은 틀릴 수 있다.

8. Agent Merge에서 가장 위험한 것은 ‘Green 만들기’다

Agent에게:

PR을 Merge 가능한 상태로 만들어.

라는 Goal을 주면 모델은 자연스럽게:

Green CI

를 목표로 삼는다.

그런데:

Green CI
=
Correct Software

는 아니다.

대표적으로 이런 문제가 있다.

Test FAIL

↓

Agent

↓

Product Code 수정

이면 괜찮을 수 있다.

하지만:

Test FAIL

↓

Agent

↓

Test Expectation 수정

↓

PASS

라면 반드시 확인해야 한다.

9. 테스트 코드는 Specification이 될 수 있다

예를 들어 원래 요구사항이:

인증되지 않은 사용자는
HTTP 401을 받아야 한다.

라고 하자.

Test:

expect(response.status).toBe(401)

그런데 실제 구현이 403을 반환한다.

Agent Merge가 CI를 통과시키기 위해:

expect(response.status).toBe(403)

으로 바꿨다.

CI는 Green이다.

하지만 요구사항은 깨졌다.

이런 변경은:

CI Repair

가 아니라:

Specification Change

다.

둘을 반드시 분리해야 한다.

10. 그래서 Agent Merge에도 권한 경계가 필요하다

추천하는 정책은 이렇다.

자동 허용

Formatting

Lint 수정

명백한 Compile Error

단순 Import

Reviewer가 구체적으로 요구한 작은 수정

Mechanical Merge Conflict

확인 후 진행

Test Assertion 변경

Public API 변경

새 Dependency

Database Schema

Architecture 변경

Security 관련 코드

Auth / Payment

사람이 결정

요구사항 변경

보안 정책 변경

Production Migration

Test 삭제

Required Check 제거

Branch Protection 변경

즉 Agent Merge를 켠다고 Agent에게 PR에 관한 모든 결정 권한을 넘기는 것은 아니다.

11. Merge Conflict도 생각보다 위험하다

Conflict 해결은 Agent에게 굉장히 잘 맞는 작업처럼 보인다.

예:

<<<<<<< feature

새 구현

=======

main의 새 구현

>>>>>>> main

하지만 Conflict는 단순 문자열 충돌이 아니다.

두 Branch 모두 올바른 변경일 수 있다.

예:

feature
→ 새로운 Cache

main
→ Race Condition 수정

Agent가:

feature쪽 선택

해서 Conflict Marker를 없애면 Git은 정상이다.

하지만 main의 Race Condition 수정이 사라질 수 있다.

12. 좋은 Conflict Resolution은 ‘둘 다 이해’해야 한다

따라서 Agent에게:

Conflict marker 없애.

가 아니라:

Base branch의 변경 목적과
feature branch의 변경 목적을 모두 확인하고
두 요구사항을 보존하는 방향으로 해결해.

라고 해야 한다.

특히 다음 파일은 Conflict 자동 해결 Risk를 높게 보는 편이 좋다.

Authentication

Database

Concurrency

Build Configuration

Dependency Lock

Infrastructure

Security Policy

13. Agent Merge를 ‘PR 유지보수 Agent’로 보는 게 가장 정확하다

Agent Merge를:

Automatic Merger

라고 생각하는 것보다:

PR Maintenance Agent

라고 생각하면 이해하기 쉽다.

주요 역할:

Review Follow-up

CI Repair

Branch Sync

Conflict Resolution

Workflow Retry

이다.

즉 사람이 PR을 만든 뒤 매번 들어가서 관리하던 잔업을 Agent가 맡는다.

14. 개발자가 가장 자주 하는 PR 잔업이 사라질 수 있다

실제로 이런 상황이 많다.

Reviewer:

여기 optional 처리해주세요.

개발자:

수정
commit
push

30분 뒤 CI:

lint failure

개발자:

다시 수정
push

그 사이 main 변경:

branch behind

개발자:

pull
resolve
push

새 Review:

이 Test도 추가해주세요.

다시 개발자가 들어간다.

이 과정 하나하나는 어렵지 않다.

문제는 Attention을 계속 끊는다는 것이다.

15. Agent Merge의 진짜 가치는 Context Switching 감소다

개발자에게 PR 하나는 끝난 작업처럼 보여도 머릿속에는 계속 남는다.

PR #128
CI 기다리는 중

PR #131
Reviewer 답변 기다림

PR #133
Conflict 발생

PR #135
새 Comment

그러면 개발자는 다음 Feature를 개발하면서도 계속 Notification을 확인한다.

Agent Merge가 제대로 동작하면:

PR #128
Agent가 CI 처리

PR #131
Agent가 Comment 대응

PR #133
Agent가 Conflict 조사

가 된다.

사람은:

Decision Needed

Risk High

Merge Ready

일 때만 돌아오면 된다.

이게 훨씬 큰 생산성 변화일 수 있다.

16. 좋은 Agent는 모든 Comment를 무조건 받아들이면 안 된다

Reviewer가:

이거 Singleton으로 바꾸는 게 좋겠습니다.

라고 Comment를 남겼다고 하자.

Agent가 곧바로:

Singleton으로 변경

하면 안 될 수도 있다.

왜냐하면 Repository Architecture에서는 Singleton을 금지하고 있을 수 있기 때문이다.

좋은 Agent의 행동은:

Review Comment
      ↓
Repository Rule
      ↓
Architecture Context
      ↓
충돌?
   │       │
  NO      YES
   │       │
   ▼       ▼
수정    Decision Needed

이다.

즉 Comment는 명령이 아니라 입력이다.

17. 그래서 AGENTS.md와 Review Skill이 더 중요해진다

예를 들어 Repository에:

# Review Rules

- Singleton 추가 금지
- Public API 변경은 확인 필요
- 새로운 외부 Dependency는 자동 추가하지 않는다
- Test assertion 변경은 요구사항을 확인한다
- 기존 Security validation을 제거하지 않는다

가 있다면 Agent Merge도 이 기준을 따라야 한다.

Agent가 강해질수록 Repository의 규칙이 더 중요해진다.

18. PR Description도 Agent의 Context가 된다

좋은 PR에는 단순 변경 목록만 있는 것이 아니라:

왜 바꿨는가

무엇을 바꿨는가

무엇은 바꾸지 않았는가

어떻게 검증했는가

가 있어야 한다.

예:

## 목표

로그인 중 중복 요청 문제 해결.

## 원인

Loading 상태 반영 전에
버튼을 다시 누를 수 있었음.

## 변경

요청 시작 즉시 버튼을 disabled 처리.

## 변경하지 않은 것

Authentication API
Retry Policy

## 검증

Unit Test
E2E Login Flow

이 정보가 있으면 이후 Agent가 Reviewer Comment나 CI Failure를 처리할 때 원래 Goal을 잃을 가능성이 줄어든다.

19. Agent Merge는 ‘원래 Goal’을 계속 보존해야 한다

PR Lifecycle이 길어질수록 Agent가 원래 문제를 잊을 가능성이 있다.

예:

Goal
중복 Login Request 방지

그런데 세 번 수정하고 Conflict까지 해결한 뒤:

현재 코드
Login Button 항상 disabled

가 되어버릴 수도 있다.

CI만 보면 통과할 수 있다.

따라서 각 Repair Cycle마다:

Original Goal

Acceptance Criteria

Current Diff

New Blocker

를 같이 봐야 한다.

20. Review Feedback도 등급을 나누는 게 좋다

모든 Comment가 동일하지 않다.

예:

CRITICAL

Security
Data Loss
Incorrect Authorization

MAJOR

Logic Bug
Concurrency
Architecture
Regression

MINOR

Naming
Formatting
Small Refactor

Agent Merge가 처리할 때도:

MINOR
→ 자동

MAJOR
→ 수정 후 재검증

CRITICAL
→ Human Notify

처럼 다르게 가져갈 수 있다.

21. GitHub의 기존 보호장치를 없애면 안 된다

Agent Merge가 강해져도 GitHub Ruleset이나 Branch Protection이 더 중요해진다.

GitHub는 Protected Branch에서:

Pull Request Review
Required Status Checks
Conversation Resolution
Merge Queue
성공한 Deployment
Signed Commit
Force Push 제한

같은 조건을 강제할 수 있다.

즉:

Agent

를 신뢰하는 것이 아니라:

Agent
+
Repository Policy

를 신뢰하는 것이다.

22. 추천 Architecture는 이렇다

                    Feature / Bug
                         │
                         ▼
                    Coding Agent
                         │
                         ▼
                     Pull Request
                         │
                         ▼
                  Independent Review
                         │
                         ▼
                    Agent Merge
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        Comments       CI Fail      Conflict
            │            │            │
            └────────────┼────────────┘
                         ▼
                     Agent Fix
                         │
                         ▼
                   Build / Tests
                         │
                         ▼
                    Re-review
                         │
                         ▼
                  GitHub Ruleset
                         │
                         ▼
                    Merge Queue
                         │
                         ▼
                     Human Gate
                         │
                         ▼
                       main

핵심은 Agent Merge가 GitHub Ruleset보다 위에 있지 않다는 것이다.

23. CI는 Agent의 상사가 되어야 한다

Agent가:

완료했습니다.

라고 해도 CI가 실패하면 완료가 아니다.

Agent Opinion
    ↓

상관없음

CI Result
    ↓

실제 Gate

라는 구조가 좋다.

Required Status Check를 Protected Branch에 설정하면 해당 Check가 통과해야 Merge할 수 있다.

Agent Merge 역시 Required Check가 Pending이면 기다리고, 실제 Merge 직전에 PR이 Ready 상태인지 다시 확인한다.

24. Security Check 역시 Required로 만드는 편이 좋다

예:

Unit Test

Integration Test

Lint

CodeQL

Dependency Review

Secret Scan

등을 Required Check로 둔다.

GitHub Ruleset은 Status Check뿐 아니라 Code Scanning 결과 등도 Merge 조건으로 사용할 수 있다.

그러면 Agent가:

Security Warning 무시하고 Merge

하기 어렵다.

25. Code Owner도 여전히 중요하다

예를 들어:

/auth/**
→ Security Team

/payment/**
→ Payment Team

/database/**
→ Backend Lead

처럼 특정 영역을 CODEOWNERS로 관리할 수 있다.

Agent가 Review Comment를 전부 해결하더라도:

Security Code Owner Approval

이 없으면 Merge되지 않게 할 수 있다.

Agent가 강해질수록 권한 경계가 더 중요해진다.

26. Copilot Review까지 완전히 자동화할 수도 있지만 주의가 필요하다

GitHub Copilot은 현재 PR Code Review를 수행하고 Severity 기반 Comment를 남길 수 있다. 기본적으로 Copilot Review는 Required Approval로 계산되지 않지만, 현재 Public Preview인 Copilot Approvals를 별도로 활성화하면 Repository의 Required Approval을 만족시키도록 구성할 수도 있다.

기술적으로는:

Coding Agent
     ↓
Copilot Review
     ↓
Agent Merge
     ↓
Copilot Approval
     ↓
Merge

처럼 거의 사람 없는 Flow도 가능해지고 있다.

하지만 모든 Repository에서 이걸 기본값으로 두는 것은 권하지 않는다.

27. 작성 Agent와 Reviewer가 같은 실패를 공유할 수 있기 때문이다

예를 들어 요구사항을 Agent가 잘못 이해했다.

Requirement
A

Agent 이해
B

Agent는 B를 구현한다.

AI Reviewer도 B라는 구현 자체는 훌륭하다고 평가한다.

Implementation
PASS

Architecture
PASS

Tests
PASS

하지만 실제 Product Requirement는 A다.

즉:

Wrong Requirement Interpretation
+
Good Implementation
+
Good AI Review
=
Wrong Software

가 가능하다.

그래서 고위험 변경에서는 사람의 Product/Architecture 판단이 여전히 필요하다.

28. 추천하는 도입 단계는 네 단계다

1단계 — Agent Merge는 관찰만

Review Feedback
CI Failure
Conflict

를 보고 어떤 행동을 할지 확인한다.

실제 Merge는 사람.

2단계 — 유지보수 자동화

addressReviews = true
fixCI = true
resolveConflicts = true

mergePullRequest = never

로 사용한다.

개인 프로젝트에서도 가장 현실적인 시작점이다.

3단계 — Low Risk PR 자동 Merge

예:

Documentation

Tests

Formatting

Dependency Patch

Internal Refactor

같은 변경만 자동 Merge 후보로 둔다.

4단계 — Risk-based Merge

LOW
→ Agent Merge 가능

MEDIUM
→ AI Review + Required Checks

HIGH
→ Code Owner + Human

CRITICAL
→ 자동 Merge 금지

로 발전시킨다.

29. `ifUnchanged` 옵션이 흥미로운 이유

Agent Merge 설정에는:

always

ifUnchanged

never

가 있다.

특히 ifUnchanged는 꽤 좋은 안전 장치다.

의미를 단순화하면:

Agent가 Repair를 위해
PR을 실제로 변경하지 않았다면

→ Merge 가능

하지만 Agent가 Repair Turn에서 코드를 변경했다면:

→ 자동 Merge하지 않음

으로 운영할 수 있다.

즉:

기존 PR 그대로 모든 Check PASS

와:

Agent가 방금 새 코드를 수정한 PR

을 동일하게 취급하지 않는 것이다.

실무적으로 꽤 합리적인 구분이다.

30. PR 수정 후 독립 Re-review를 넣는 게 좋다

가장 추천하는 구조는:

Human / AI Review
       ↓
Finding
       ↓
Agent Merge Fix
       ↓
새 Commit
       ↓
Independent Re-review

다.

특히:

Auth

Payment

Data

Concurrency

Infrastructure

같은 변경이라면 필수에 가깝다.

왜냐하면 Review Comment 하나를 해결하면서 다른 Bug를 만들 수 있기 때문이다.

31. Claude를 독립 Reviewer로 넣는 구조도 가능하다

최근 다뤘던 멀티에이전트 구조를 응용하면:

Codex
→ 구현

Claude
→ Review

Agent Merge
→ CI / Comment / Conflict 처리

Claude
→ Re-review

Runtime QA
→ 실제 검증

처럼 가져갈 수 있다.

중요한 것은 특정 모델 조합이 아니다.

작성

검토

수정

재검토

의 Context를 분리하는 것이다.

32. QA는 Merge 전에 한 번 더 필요하다

CI가 모두 Green이어도 UX가 깨질 수 있다.

Web이라면:

Playwright

Browser

Screenshot

Video

Console

Network

으로 Runtime QA를 할 수 있다.

iOS:

Simulator

Accessibility

Recording

Runtime Log

Android:

Emulator

Semantics

Logcat

같은 검증을 추가할 수 있다.

즉:

PR Ready

와:

Product Ready

를 구분한다.

33. Merge Queue와 Agent Merge는 상당히 잘 맞는다

GitHub Merge Queue는 여러 PR이 동시에 main으로 들어가는 환경에서 각 PR을 최신 Base 상태와 함께 검사하고 순서대로 Merge하도록 설계돼 있다.

Agent Merge가:

PR을 Merge-ready 상태까지 유지

하고,

Merge Queue가:

최신 main과 함께 최종 검증

을 하는 구조다.

Agent Merge
     ↓
Merge-ready
     ↓
Merge Queue
     ↓
Latest Base Integration
     ↓
Required Checks
     ↓
Merge

Agent가 많아져 PR 생성량이 늘수록 이런 구조의 가치가 커진다.

34. 결국 Agent Merge는 ‘Self-healing PR’에 가깝다

앞으로 PR은 정적인 변경 묶음이 아니라 조금 다른 형태가 될 수 있다.

PR 생성
  ↓
환경 변화
  ↓
스스로 수정
  ↓
Feedback 반영
  ↓
CI 복구
  ↓
Base Branch 동기화
  ↓
다시 검증

일종의:

Self-maintaining Change

다.

이건 상당히 큰 변화다.

35. 하지만 Self-healing과 Self-correcting은 다르다

Agent가:

Test를 Green으로 만들었다.

고 해서:

제품을 올바르게 만들었다.

는 뜻은 아니다.

Agent Merge는:

Operational Blocker

를 잘 처리할 수 있다.

그러나:

Product Intent
Architecture Trade-off
Security Risk Acceptance

까지 자동으로 결정하는 것은 다른 문제다.

여기에는 여전히 사람의 판단이 필요하다.

36. 그래서 가장 중요한 것은 Merge Policy다

Agent가 얼마나 똑똑한지보다:

무엇을 Agent에게 맡길 것인가?

를 정하는 것이 중요하다.

예를 들어:

agent_merge:

  review_feedback:
    auto: true

  ci_failure:
    auto: true

  merge_conflict:
    auto: true

  test_expectation_change:
    approval: required

  dependency_addition:
    approval: required

  auth_change:
    human_review: required

  production_config:
    auto_merge: false

이런 Policy가 있으면 Agent가 바뀌어도 Workflow는 유지된다.

37. 개인 개발자에게도 꽤 유용하다

혼자 개발하면 이런 일이 많다.

PR 만들었는데

CI 하나 깨짐

↓

나중에 고쳐야지

다른 작업 시작.

몇 시간 뒤:

아 맞다.

다시 돌아온다.

Agent Merge가 있으면:

PR
↓
CI Fail
↓
Agent Fix
↓
CI
↓
Merge Ready

까지 뒤에서 진행시킬 수 있다.

개인 개발자에게도 Attention 절약 효과가 꽤 클 수 있다.

38. 여러 Agent를 쓰면 더 중요해진다

Agent 1:

Feature A PR

Agent 2:

Bug Fix PR

Agent 3:

Refactor PR

가 동시에 생겼다고 하자.

이제 사람에게:

PR 3개 관리

업무가 생긴다.

그런데 각 PR마다 Agent Merge가 붙으면:

PR A → Agent 유지관리

PR B → Agent 유지관리

PR C → Agent 유지관리

를 할 수 있다.

사람은:

Needs Decision

Security Risk

Merge Ready

만 보는 방향으로 갈 수 있다.

39. Multi-Agent의 진짜 병목을 건드리는 기능이다

멀티에이전트가 발전하면서 가장 먼저 발생하는 문제가 있다.

Agent 생성 속도
>
Human 처리 속도

이다.

Agent Merge는 이것을:

Agent 생성

+

Agent 유지관리

로 확장한다.

즉 Agent가 만들어낸 PR을 다른 단계의 Agent가 끝까지 돌보는 구조다.

이게 Engineering Agent 시스템에 가까워지는 이유다.

40. 앞으로 Issue부터 Merge까지 하나의 Agent Graph가 될 수 있다

결국 이런 형태가 자연스럽다.

                        Issue
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                  Implementation Agent
                          │
                          ▼
                         PR
                          │
               ┌──────────┴──────────┐
               ▼                     ▼
          Review Agent             CI
               │                     │
               └──────────┬──────────┘
                          ▼
                     Agent Merge
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
        Feedback Fix   CI Recovery   Conflict
             │            │            │
             └────────────┼────────────┘
                          ▼
                      Re-review
                          │
                          ▼
                      Runtime QA
                          │
                          ▼
                     Merge Queue
                          │
                          ▼
                       Human Gate
                          │
                          ▼
                         main

이제 Agent의 작업 경계가:

Issue → Code

가 아니라:

Issue → Verified Merge

까지 늘어난다.

41. 개발자의 역할 역시 한 단계 올라간다

예전 개발자는:

코드를 작성하고

CI를 보고

Review Comment를 수정하고

Conflict를 해결하고

Merge했다.

Agent 환경에서는 점점:

Goal 설정

Architecture 결정

Risk 판단

Agent Policy 설정

Exception 승인

최종 결과 Review

를 맡게 된다.

구현의 세부 작업보다 Software Change 전체의 품질을 관리하는 역할로 이동하는 것이다.

42. Agent Merge를 쓰면서 측정해볼 지표

실제 도입했다면 단순:

Agent Merge 사용 횟수

를 볼 필요는 없다.

다음이 더 중요하다.

PR Lead Time

Review → Fix Time

CI Recovery Time

Conflict Resolution Time

Human Intervention Count

Agent Repair Count

Re-review Rejection Rate

Regression Rate

특히:

Human Intervention Count

가 재미있다.

Agent Merge를 넣었는데 사람이 여전히 PR마다 열 번씩 개입해야 한다면 큰 효과가 없는 것이다.

43. 좋은 Agent Merge는 사람을 많이 부르지 않는다

예:

PR 시작

Agent Review 대응

CI 수정

Conflict 해결

CI 재실행

↓

Human

"Merge 가능"

이면 성공적이다.

반대로:

Comment 1
→ 질문

CI
→ 질문

Conflict
→ 질문

Workflow
→ 질문

이라면 단순 Automation을 복잡하게 만든 것에 가깝다.

목표는:

Agent Activity ↑

가 아니라:

Human Attention ↓

이어야 한다.

44. Agent가 직접 Merge했다면 Provenance도 남겨야 한다

앞으로는:

누가 Merge했는가?

만으로 부족할 수 있다.

어떤 Agent가

어떤 Review Comment를 해결했고

어떤 CI를 고쳤고

어떤 Conflict를 해결했으며

마지막 변경 후 어떤 Test를 실행했는가

도 중요하다.

즉 Agent Merge가 발전할수록:

Agent Provenance

의 중요성도 커진다.

PR Timeline이 일종의 Agent 작업 감사 로그가 되는 것이다.

45. GitHub의 기존 Review/Ruleset이 사라지는 게 아니다

오히려 반대다.

Agent가 더 많은 변경을 만들수록:

Protected Branch

Required Review

Required Checks

Ruleset

Code Owner

Merge Queue

같은 기존 Engineering Control이 더 중요해진다.

GitHub도 Ruleset을 이용해 PR Review, Status Check, Code Scanning 같은 조건을 병합 전에 강제할 수 있도록 제공하고 있다.

Agent는 그 조건을 통과하도록 일하는 Worker다.

조건 자체를 결정하는 존재가 아니다.

46. 제가 처음 적용한다면 이렇게 시작한다

개인 프로젝트:

{
  "chat.agentMerge.enabled": true,
  "chat.agentMerge.addressReviews": true,
  "chat.agentMerge.fixCI": true,
  "chat.agentMerge.resolveConflicts": true,
  "chat.agentMerge.mergePullRequest": "never"
}

그리고 GitHub에서는:

Required Tests

Required Build

Code Scanning

Conversation Resolution

정도만 먼저 둔다.

Agent에게는 Merge-ready까지만 맡긴다.

실제 Merge는 직접 한다.

47. 익숙해지면 Low Risk만 자동화한다

예:

docs/**

tests/**

internal tooling

formatting

dependency patch

등은 자동화 범위를 늘린다.

반면:

auth/**

payment/**

database/**

infra/**

security/**

는 계속 Human Gate를 둔다.

즉 Repository Path 자체를 Risk Signal로 사용할 수도 있다.

48. Agent Merge가 의미하는 더 큰 변화

지금까지 AI Coding 경쟁은 대부분:

누가 코드를 더 잘 만드는가?

였다.

그런데 개발자가 실제 원하는 것은 코드가 아니다.

원하는 것은:

Issue 해결

이다.

그래서 Agent의 작업 범위는 자연스럽게:

Code Generation
        ↓
Repository Modification
        ↓
Build / Test
        ↓
Pull Request
        ↓
Review Response
        ↓
CI Recovery
        ↓
Merge

로 계속 확장된다.

Agent Merge는 이 흐름에서 꽤 상징적인 기능이다.

마무리

VS Code 1.136의 Agent Merge는 표면적으로 보면 작은 기능처럼 보인다.

Review Comment 처리

CI 수정

Conflict 해결

자동 Merge

정도다.

하지만 개발 Workflow 관점에서는 의미가 훨씬 크다.

Coding Agent의 완료 지점이:

"PR 만들었습니다."

에서:

"PR이 Merge 가능한 상태입니다."

로 이동하기 때문이다.

VS Code의 현재 Agent Merge는 PR을 지속적으로 감시하면서 unresolved review feedback, required CI failure, base branch update와 merge conflict 같은 Blocker를 처리하고, 설정에 따라 Merge 또는 Merge Queue까지 이어갈 수 있다. 기능은 아직 Preview이고 Agent Merge를 활성화하면 Session이 Autopilot + Assisted permissions로 바뀌며 모델 요청도 소비하므로 자동화 범위를 확인한 뒤 켜야 한다.

그리고 여기서 가장 중요한 것은:

AI가 Merge할 수 있다.

가 아니다.

더 중요한 것은:

AI에게 무엇까지 Merge 과정에서
스스로 판단하도록 허용할 것인가?

다.

Test가 깨졌다고 Test를 바꿔도 되는가.

Reviewer 의견이 Architecture Rule과 충돌하면 무엇을 따라야 하는가.

Merge Conflict를 해결하면서 Base Branch의 중요한 수정이 사라지지 않았는가.

새 Commit이 들어온 뒤 기존 Approval은 여전히 유효한가.

이런 문제는 단순 Automation으로 해결되지 않는다.

그래서 앞으로 좋은 PR Workflow는:

Agent
+
Repository Rules
+
Independent Review
+
CI
+
Runtime QA
+
Human Gate

의 조합이 될 가능성이 높다.

Agent Merge를 도입한다고 Branch Protection이나 Required Check가 필요 없어지는 게 아니다.

오히려 GitHub는 Protected Branch와 Ruleset을 이용해 Required Review, Required Status Check, Conversation Resolution, Merge Queue, Code Scanning 등의 조건을 강제할 수 있다. Agent가 강해질수록 이런 Agent가 임의로 우회할 수 없는 결정적 규칙이 더 중요해진다.

결국 Coding Agent 시대의 PR은 정적인 코드 묶음에서 조금씩 바뀌고 있다.

PR
=
변경된 코드

가 아니라:

PR
=
계속 관찰하고
피드백을 받고
실패를 복구하고
최신 Branch와 맞추고
검증을 반복하는
살아 있는 Software Change

에 가까워진다.

그리고 앞으로 Agent 경쟁의 중요한 기준도 바뀔 것이다.

누가 PR을 가장 빨리 만드는가가 아니라, 누가 개발자의 Attention을 가장 적게 사용하면서 PR을 안전하게 Merge-ready 상태까지 가져가는가.

Agent Merge가 흥미로운 이유가 바로 여기에 있다.

AI가 코드를 쓰기 시작한 다음 단계는 AI가 자신이 만든 Software Change의 생명주기를 관리하기 시작하는 것이다.

참고 자료

Visual Studio Code 1.136 — September 2, 2026
VS Code 1.136에서 Agent Merge Preview가 공개됐다. Review Feedback, Failed Checks, Merge Conflict를 Agent가 반복 처리해 PR을 Merge-ready 상태까지 가져가는 기능과 Multi-root Agent Session 등이 함께 추가됐다.

Visual Studio Code — Agents Window / Agent Merge
Agent Merge의 실제 동작, 활성화 방법, Review·CI·Conflict 처리와 Merge Queue/자동 Merge 옵션, Autopilot 및 Permission 관련 주의사항이 설명돼 있다.

Visual Studio Code — AI Settings Reference
addressReviews, fixCI, resolveConflicts, mergePullRequest, mergeMethod, replyAttribution 등 Agent Merge의 세부 설정을 확인할 수 있다.

GitHub — Protected Branches / Rulesets
Required Review, Required Status Check, Conversation Resolution, Merge Queue, Code Scanning 같은 Repository 수준의 병합 조건을 강제할 수 있다.

GitHub — Copilot Code Review
Copilot을 PR Reviewer로 활용하고 Review Comment를 Agent에게 다시 구현시키는 Workflow를 제공한다. Copilot Approval은 별도 설정 시 Required Approval에 포함할 수 있지만 현재 Public Preview다.

핵심 참고 포인트

Agent Merge의 핵심은 단순한 자동 Merge가 아니다. PR 생성 이후의 Review 대응 → CI 복구 → Branch 동기화 → Conflict 해결 → 재검증이라는 반복적인 유지보수 업무를 Agent가 지속적으로 맡는 것이다.

실무에서는 처음부터 mergePullRequest: always로 두기보다 Review·CI·Conflict 처리는 Agent에게 맡기고 실제 Merge는 사람이 수행하는 never 구성부터 시작하는 것이 안전하다. 이후 Low Risk 변경에 한해 ifUnchanged나 Merge Queue를 단계적으로 도입할 수 있다.

그리고 Agent가 강해질수록 CI Green을 Software Correct로 착각하지 않는 것이 중요하다. Agent Merge는 PR의 운영적 Blocker를 제거하는 데 강하지만 Product Intent와 Architecture·Security 판단까지 대체하는 시스템은 아니다. Agent는 PR을 고치고, Repository Policy와 Test가 검증하며, 중요한 결정은 사람에게 남기는 구조가 가장 현실적이다.

이경규

iOS 앱 개발자

이전 포스트

MCP 다음은 MHS다: AI Agent가 실제 기계를 움직이는 시대

다음 포스트

PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우