코딩 에이전트가 PR을 올리는 건 이미 익숙한 풍경이 됐다. 그런데 VS Code 1.136에 조용히 들어간 Agent Merge는 그다음 단계를 건드린다. 리뷰 코멘트 대응, CI 실패 수정, 머지 컨플릭트 해결, 워크플로우 재실행 — PR이 머지 가능한 상태가 될 때까지 이 루프를 에이전트가 반복한다. velog에 올라온 분석 글이 이 변화를 정확히 짚는다: 에이전트가 다루는 단위가 Code Change에서 Pull Request Lifecycle 전체로 올라갔다.
이게 왜 중요한가. 지금까지 에이전트 도입의 병목은 PR 이후에 있었다. 에이전트가 구현을 20분 만에 끝내도, 리뷰어 확인 대기 2시간, CI 실패 대응, 베이스 브랜치 충돌 처리, 새 코멘트 루프 — 실제 리드 타임의 대부분은 PR이 생성된 이후에 쌓인다. Agent Merge는 정확히 이 구간을 노린다. 에이전트가 PR 상태를 지속적으로 감시하고, 블로커가 생기면 처리하고, 다시 체크하는 PR Maintenance Worker가 되는 것이다.
팀 리드 입장에서 이 변화가 반가운 이유는 하나다. 개발자가 PR 하나에 Attention을 계속 끊기는 문제가 사라진다. PR #128 CI 기다리는 중, PR #131 리뷰어 답변 대기, PR #133 컨플릭트 발생 — 이 상태들을 머릿속에 들고 다음 피처를 개발하는 비용이 생각보다 크다. Agent Merge가 제대로 동작하면, 사람은 Decision Needed, Risk High, Merge Ready 시점에만 돌아오면 된다. 이게 진짜 생산성 변화다.
그런데 여기서 멈춰야 할 지점이 있다. Green CI ≠ Correct Software. Agent Merge에게 "PR을 머지 가능한 상태로 만들어"라는 목표를 주면, 모델은 자연스럽게 Green CI를 향해 움직인다. CI를 통과시키기 위해 테스트 assertion을 수정하거나, 리뷰어 코멘트를 원래 의도와 다른 우회 구현으로 처리하거나, 컨플릭트를 해결하면서 베이스 브랜치의 중요한 변경을 조용히 삭제할 수 있다. 기계적으로는 모두 PASS인데 제품은 틀린 상태가 된다.
이걸 막으려면 처음 도입 시 mergePullRequest: never부터 시작하는 게 맞다. 에이전트는 머지 레디 상태까지, 실제 머지는 사람이 — 이 경계를 유지하는 것이다. 허용 범위도 명확히 나눠야 한다. 포매팅, 린트 수정, 단순 임포트, 리뷰어가 구체적으로 요청한 소소한 수정은 에이전트에게 넘겨도 된다. 반면 테스트 assertion 변경, Public API 수정, 새 Dependency 추가, DB 스키마, 인증/결제 관련 코드는 반드시 사람이 확인해야 한다. 이 기준을 Repository Rule 파일로 명시해두면, 에이전트도 그 기준을 따라 "수정할지 / Human Notify 할지"를 판단하게 된다.
두 번째 문제는 맥락의 소멸이다. dev.to에 올라온 git why 프로젝트는 이 문제를 정면으로 다룬다. git blame은 누가 언제 바꿨는지를 알려준다. 하지만 왜 이 방식을 선택했는지, 어떤 대안을 검토했다가 버렸는지, 어떤 프롬프트가 이 diff를 만들어냈는지는 어디에도 남지 않는다. 에이전트와의 대화는 채팅창이 닫히는 순간 사라진다. 3개월 뒤 코드를 보면서 git blame을 돌렸더니 "당신이 4월에 고쳤음"이라는 답만 돌아오는 것이다.
git why가 선택한 해법은 단순하고 영리하다. 추론의 이유를 git trailer로 커밋 메시지에 직접 박아넣는 것. 서버도 없고, 데이터베이스도 없고, 클론하면 그냥 따라온다. Why:, Why-Prompt:, Why-Rationale:, Why-Alternatives:, Why-Agent: — 이 필드들이 커밋 오브젝트의 일부가 되기 때문에, 호스팅 대시보드와 코드 저장소가 따로 놀다가 언젠가 어긋나는 문제도 없다. 에이전트 설정 파일(CLAUDE.md 또는 .cursorrules)에 git why commit 명령을 쓰도록 지시하면, 에이전트가 커밋 시점에 스스로 맥락을 기록한다 — 나중에 사람이 기억을 되짚는 게 아니라.
이 두 흐름 — Agent Merge와 git why — 이 실무에서 만나면 어떤 그림이 될까. Agent Merge는 PR이 머지 가능한 상태에 도달하기까지의 반복 루프를 자동화하고, git why는 그 루프의 각 사이클마다 에이전트가 왜 그 결정을 했는지를 추적 가능하게 만든다. 나중에 "AI가 왜 테스트 assertion을 바꿨는가"를 git why HEAD로 바로 확인할 수 있다면, 팀 리드의 리뷰 부담이 실질적으로 줄어든다.
세 번째는 리뷰 루틴 자체의 재설계다. dev.to에 올라온 10분 AI PR 리뷰 체크리스트는 이 지점에서 실용적이다. 핵심은 그린 체크를 신뢰하지 말 것. 에이전트가 만든 PR일수록 PR 요약이 그럴싸하고, CI가 통과하고, 설명이 구체적으로 들린다 — 그런데 실제 diff와 느슨하게 연결돼 있는 경우가 많다. 이걸 저자는 "summary theater"라고 부른다. 요약은 인덱스로 쓰고, 검증의 근거로 쓰면 안 된다.
체크리스트를 구조화하면 이렇다. 1분: 이 변경이 해야 할 일을 한 문장으로 먼저 써라. 그게 안 되면 diff를 읽기 전에 멈춰야 한다. 2~3분: diff의 형태를 보라. 파일 목록과 diff 크기를 먼저 훑어서 범위 초과 여부를 판단한다. "여기 있는 김에" 손댄 리팩터링이 있다면 분리하거나 돌려보낸다. 4~6분: 행동을 추적하라. 에이전트의 설명이 아니라 코드의 입력-출력 경로를 직접 따라가라. 엣지 케이스, 실패 시나리오, 권한 처리, 루프 안의 비싼 호출 — 이것들이 핵심이다. 7~8분: 테스트를 테스트하라. 테스트의 존재가 커버리지의 증거가 아니다. assertion이 실제로 중요한 동작의 회귀를 잡을 수 있는지 읽어야 한다. 함수가 무언가를 반환한다는 것만 확인하는 테스트는 테스트 모양의 문서일 뿐이다. 9분: 요약을 마지막에 읽어라. 설득당하지 말고, 설명을 검증하라. 10분: 세 가지 중 하나를 선택하라. Merge / Request Changes / Split or Close.
이 세 가지를 팀 리드 관점에서 묶으면 하나의 구조가 보인다. 에이전트가 PR 라이프사이클을 관리하는 시대에, 팀 리드의 역할은 더 빠른 리뷰어가 아니라 더 좋은 판단 설계자가 되어야 한다는 것이다. 어디까지 에이전트가 자율적으로 처리할지 경계를 설계하고(mergePullRequest: never vs ifUnchanged), 에이전트가 내린 결정의 맥락이 추적 가능하도록 워크플로우를 구성하고(git why), 사람이 개입하는 10분이 실제로 가장 위험한 지점을 커버하도록 리뷰 루틴을 짜는 것이다.
Agent Merge를 도입하는 팀이 가장 먼저 해야 할 일은 설정 파일이 아니다. 에이전트에게 넘길 수 있는 결정과, 반드시 사람이 내려야 하는 결정의 목록을 만드는 것이다. 이 목록이 Repository Rule 파일이 되고, 에이전트의 행동 기준이 되고, 팀의 리뷰 체크리스트의 근거가 된다. Agent가 강해질수록 Repository의 규칙이 더 중요해진다 — velog 글의 이 문장이 지금 시점에서 가장 실용적인 조언이다.