최근 연구 흐름도 같은 지점을 짚고 있습니다. 2026년 5월 공개된 논문 Collaborator or Assistant? How AI Coding Agents Partition Work Across Pull Request Lifecycles는 AI 코딩 에이전트 PR에서 두 축을 분리합니다. 하나는 누가 작업을 시작하는가, 다른 하나는 누가 완료와 merge를 승인하는가입니다. 논문은 일부 collaborator형 workflow에서 agent-initiated PR이 매우 높게 나타나지만, 최종 merge 권한은 거의 항상 사람에게 남는다고 분석합니다.

이 흐름을 저는 Agentic PR Governance라고 부르겠습니다. 에이전트가 PR을 여는 것은 곧 표준 기능이 됩니다. 하지만 좋은 팀과 위험한 팀의 차이는 PR 생성량이 아니라, 작업 시작 권한·검증 증거·review owner·merge 권한을 분리해서 운영하는가에서 갈릴 가능성이 큽니다. 이 글은 AI PR Review Backlog OS, Test Evidence Pipeline, Repo-local Agent Policy, Agent Workspace Lease Broker와 이어집니다.

이 글에서 얻는 것

• AI coding agent PR을 단순 자동화가 아니라 PR lifecycle governance 문제로 보는 기준을 얻습니다.
• operational agency와 merge governance를 분리해 팀 정책으로 설계하는 방법을 이해할 수 있습니다.
• agent-authored PR에 필요한 risk label, validation evidence, owner review, cost budget 기준을 정리할 수 있습니다.
• 자동 merge, draft PR, 사람 승인, 보호 브랜치 사이의 트레이드오프를 판단할 수 있습니다.

핵심 개념/이슈

1) PR을 여는 권한과 merge하는 권한은 같은 것이 아니다

사람 개발자도 branch를 만들고 PR을 열 수 있지만, main branch에 들어가려면 리뷰와 check를 통과해야 합니다. 에이전트도 같은 구조로 봐야 합니다. 문제는 에이전트가 빠르게 많은 PR을 만들 수 있다는 점입니다. 생성 비용이 낮아지면 검토 비용이 병목이 됩니다.

그래서 첫 번째 원칙은 operational agency와 merge governance를 분리하는 것입니다.

중요한 것은 “에이전트가 못 믿을 존재라서 막자"가 아닙니다. 자동화는 시작과 실행을 빠르게 만들고, 사람은 의도와 영향 판단을 맡는 식으로 역할을 나누자는 것입니다. 이 역할 분리가 없으면 에이전트 PR은 생산성 도구가 아니라 review queue를 채우는 새 입력 채널이 됩니다.

2) agent-authored PR에는 evidence가 PR 본문에 남아야 한다

에이전트가 만든 PR에서 reviewer가 가장 답답한 지점은 “무엇을 실제로 확인했는지"입니다. 요약은 그럴듯하지만 테스트를 돌렸는지, 실패한 명령은 무엇인지, 변경 범위가 지시와 맞는지, 보안 스캔을 했는지 알 수 없으면 리뷰어가 처음부터 다시 검증해야 합니다.

따라서 PR template에 최소 evidence를 강제하는 편이 좋습니다.

agent_pr_evidence:
  requested_task: "ISSUE-1842: pagination duplicate fix"
  agent_id: "copilot/codex/claude/custom"
  changed_scope:
    - "src/orders/api"
    - "src/orders/repository"
  validation:
    tests_run:
      - "./gradlew test --tests OrderPaginationTest"
    checks_failed:
      - "full integration test skipped: local db unavailable"
    secret_scan: "passed"
  risk_label: "medium"
  human_review_required:
    - "orders-codeowner"

좋은 evidence는 길 필요가 없습니다. 다만 재현 가능해야 합니다. “테스트했습니다"보다 어떤 명령을 실행했고 무엇이 실패했는지가 중요합니다. 이 기준은 Test Evidence Pipeline에서 말한 방향과 같습니다.

3) 모든 issue를 agent에게 주면 안 된다

에이전트는 작은 국소 변경에서 강합니다. 하지만 모호한 제품 결정, 보안 경계 변경, 데이터 마이그레이션, 과금 로직, 권한 정책처럼 실패 비용이 큰 작업은 자동 할당 기준을 다르게 둬야 합니다.

추천 risk label 기준:

숫자로는 처음 2주 동안 low/medium issue의 10~20%만 에이전트에 배정하는 것이 현실적입니다. merge rate, review time, rollback rate, reopened issue rate를 보고 확대합니다. agent PR이 많아졌는데 reopen이 늘면 생산성이 아니라 품질 부채가 늘어난 것입니다.

4) 리뷰어의 병목은 코드 읽기가 아니라 의도 복원이다

사람이 만든 PR도 리뷰가 어렵지만, 에이전트 PR은 의도 복원이 더 어렵습니다. 에이전트는 여러 파일을 한 번에 바꾸고, 실패한 접근을 최종 diff에는 남기지 않으며, 지시의 빈칸을 임의로 채울 수 있습니다. 리뷰어는 “코드가 맞나” 이전에 “이 변경이 원래 issue를 맞게 해석했나"를 확인해야 합니다.

그래서 agent PR에는 아래 세 가지가 특히 중요합니다.

• 작은 작업 단위: 300줄 이하 diff부터 시작, 800줄 이상이면 분할 요청
• 명시적 non-goal: 이번 PR에서 하지 않은 것 2~3개 기록
• owner map: 변경 파일별 review owner 자동 지정

PR 크기 기준은 팀마다 다르지만, 에이전트 도입 초기에 1,000줄 이상의 diff를 자주 만들게 두면 review 신뢰가 빨리 무너집니다. 우선 작은 PR에서 통과율과 반려 사유를 학습해야 합니다. AI PR Review Backlog OS에서 말했듯이 backlog 운영은 생성량을 따라가는 문제가 아니라, 리뷰 가능한 단위로 자르는 문제입니다.

5) merge 권한은 “나중에 자동화"할 영역이지 출발점이 아니다

자동 merge는 매력적입니다. agent가 issue를 고치고 테스트를 통과시키고 바로 merge하면 throughput이 좋아 보입니다. 하지만 이 구조는 required checks, owner review, release risk, rollback path가 충분히 쌓인 뒤에야 의미가 있습니다.

자동 merge를 검토할 수 있는 최소 조건은 아래 정도입니다.

• 변경 유형이 low risk label로 제한된다.
• diff size가 100~300줄 이하이고 지정된 경로 안에만 있다.
• required checks와 secret scan이 통과했다.
• CODEOWNERS 또는 review bot 정책을 만족했다.
• 최근 30일 agent PR rollback/revert rate가 1% 미만이다.
• PR 생성부터 merge까지 모든 evidence가 남는다.

이 조건을 만족하지 못하면 자동 merge가 아니라 자동 PR 생성 + 사람 승인으로 충분합니다. 생산성은 merge 버튼을 없애서만 나오지 않습니다. 사람에게 검토 가능한 evidence를 주는 것만으로도 review time은 줄어듭니다.

실무 적용

1) agent PR state machine을 만든다

에이전트 PR을 일반 PR과 같은 흐름에만 넣으면 통제가 어렵습니다. 별도 상태를 작게라도 둡니다.

eligible_issue
  -> assigned_to_agent
  -> draft_pr_opened
  -> evidence_attached
  -> human_review_requested
  -> changes_requested | approved
  -> merge_ready
  -> merged | closed

각 전이에 gate를 둡니다. 예를 들어 evidence_attached 없이는 review 요청을 못 하게 하고, risk_label=high이면 assigned_to_agent 전에 사람 설계 승인을 요구합니다. 이 구조는 Workflow State Contract와 같은 문제입니다. 상태가 없으면 운영자는 PR 목록을 보고도 무엇이 막혔는지 알 수 없습니다.

2) repo-local policy에 에이전트 제한을 적는다

에이전트에게 매번 “조심해서 해"라고 말하는 방식은 오래가지 않습니다. repo 안에 정책을 둡니다.

agent_policy:
  allowed_labels:
    - agent-ok
    - good-first-agent-task
  blocked_paths:
    - "infra/prod/**"
    - "billing/migrations/**"
    - ".github/workflows/release.yml"
  max_diff_lines: 500
  required_evidence:
    - tests_run
    - failed_commands
    - secret_scan
    - risk_label
  merge_policy:
    default: "human_required"
    auto_merge_allowed: false

이 정책은 Repo-local Agent Policy의 실무 적용입니다. 핵심은 모델에게 보이는 지침과 CI/PR 규칙이 같은 방향을 보게 만드는 것입니다. 문서만 있고 enforcement가 없으면 곧 drift가 생깁니다.

3) 운영 지표를 생산량보다 품질 중심으로 본다

에이전트 도입 지표를 PR 개수로 잡으면 잘못된 행동을 유도합니다. 진짜 봐야 할 것은 review와 운영 결과입니다.

권장 지표:

특히 high-risk mislabel은 강하게 봐야 합니다. 보안, 결제, 권한, migration 변경이 low risk로 들어오면 PR 품질 문제가 아니라 governance 사고입니다.

트레이드오프/주의점

첫째, gate를 너무 세게 걸면 에이전트의 장점이 사라집니다. 문서 수정 하나에도 긴 승인 절차를 요구하면 아무도 쓰지 않습니다. 그래서 low risk와 high risk를 분리해야 합니다. 문서·테스트·작은 버그는 빠르게, 권한·결제·infra는 느리게 가는 식입니다.

둘째, 사람 승인도 만능은 아닙니다. reviewer가 PR evidence를 신뢰하지 못하면 결국 모든 명령을 다시 돌립니다. 그러면 에이전트가 시간을 줄인 만큼 사람이 검증 시간을 다시 씁니다. evidence 형식을 표준화하고, 실패한 명령도 숨기지 않게 하는 이유가 여기에 있습니다.

셋째, agent identity를 흐리면 책임 경계가 무너집니다. 사람이 요청했고 에이전트가 작성했으며 사람이 merge했다면, 각각의 역할이 PR metadata에 남아야 합니다. 그래야 나중에 품질 이슈가 생겼을 때 prompt 문제인지, tool 환경 문제인지, review policy 문제인지 분리할 수 있습니다.

넷째, 비용도 governance 대상입니다. 긴 agent session은 실제 비용과 대기 시간을 만듭니다. issue 하나당 agent runtime 30분, 재시도 2회, 변경 파일 20개 같은 제한을 먼저 두고 예외는 label로 승인하는 편이 안전합니다. 이 흐름은 Usage Metered AI Coding Budget와도 맞닿아 있습니다.

의사결정 우선순위는 위험 분류 정확도 > 검증 증거 > owner review > merge 속도 > PR 생성량입니다. PR 생성량은 가장 보기 쉬운 지표지만, 가장 쉽게 오해하는 지표이기도 합니다.

체크리스트 또는 연습

운영 체크리스트

• agent에게 자동 할당 가능한 issue label이 제한되어 있다.
• agent PR에는 risk label과 변경 범위가 명시된다.
• PR 본문에 테스트 명령, 실패한 명령, secret scan 여부가 남는다.
• high risk 경로는 agent 단독 PR 생성 또는 자동 merge에서 제외된다.
• CODEOWNERS 또는 owner map이 agent PR에도 동일하게 적용된다.
• draft PR이 48시간 이상 방치되면 stale 처리된다.
• agent PR의 revert/reopen/high-risk mislabel 지표를 따로 본다.
• 자동 merge는 low risk, 작은 diff, required checks 통과, 낮은 revert rate 조건에서만 검토한다.

연습

1. 최근 20개 issue를 low/medium/high/blocked로 분류해 보세요. agent에게 바로 맡길 수 있는 것이 30%를 넘지 않으면 정상입니다. 처음부터 대부분을 자동화하려는 것이 더 위험합니다.
2. agent PR template을 만들어 requested_task, changed_scope, tests_run, failed_commands, risk_label, human_review_required를 필수 필드로 넣어 보세요.
3. 지난 한 달 PR 중 800줄 이상 diff를 찾아, agent가 만들었다면 reviewer가 의도를 복원할 수 있었을지 평가해 보세요. 어렵다면 max diff line 정책이 필요합니다.
4. billing, auth, .github/workflows, infra/prod 같은 high-risk path를 blocked list로 정하고, 예외 승인 절차를 5줄로 작성해 보세요.

Agentic PR Governance의 목표는 에이전트를 느리게 만드는 것이 아닙니다. 오히려 반대입니다. 에이전트가 잘하는 작은 실행은 더 많이 맡기되, merge와 책임 판단은 설명 가능한 증거 위에서 하자는 것입니다. 2026년의 개발 조직에서 중요한 질문은 “AI가 PR을 만들 수 있나"가 아니라, 그 PR이 어떤 권한과 증거를 가지고 main branch 앞까지 왔는가가 될 가능성이 큽니다.