AI 코딩 에이전트 PR, 어떤 조건에서 병합해야 할까

AI 코딩 에이전트가 만든 PR(Pull Request)은 AI가 작성했다는 이유만으로 더 쉽게 병합해서도, 무조건 거부해서도 안 된다.

팀의 기본 병합 조건은 작성 주체와 관계없이 같아야 한다. 중요한 브랜치는 보호하고 현재 Revision을 대상으로 한 필수 검사가 통과해야 하며 변경의 영향을 이해하는 사람이 책임 있게 승인해야 한다. AI가 관여했다면 여기에 Agent의 권한, 작업 출처와 검토 가능성을 보여주는 증거를 추가한다.

따라서 병합 판단은 다음 다섯 질문으로 구성하는 편이 낫다.

변경이 보호 브랜치의 정상적인 PR 경로를 거쳤는가?
현재 병합하려는 Revision에 필요한 검사가 모두 실행됐는가?
변경 유형에 맞는 사람이 최신 Diff를 승인했는가?
누가 어떤 조건으로 변경을 만들었는지 추적할 수 있는가?
예외가 있었다면 그 이유와 책임자, 사후 검토 일정이 남았는가?

NIST SSDF는 조직이 보안 검사 기준을 정의하고 승인·거부·예외를 기록하며 코드 검토와 분석, 실행 가능한 코드 테스트 결과를 개발 흐름에 남기도록 권고한다. SLSA Source Track도 보호 브랜치, 기술 통제, Source Provenance와 사람이 이해할 수 있는 변경 표시를 중요한 보증 요소로 다룬다. 작성자가 사람인지 Agent인지는 이 구조 안의 한 입력이지, 병합 정책 전체를 대체하는 기준이 아니다. (nvlpubs.nist.gov)

보호 브랜치가 AI 전용 규칙보다 먼저다

AI PR을 관리하겠다고 별도의 라벨과 체크리스트부터 만드는 팀이 있다. 하지만 기본 브랜치에 직접 Push할 수 있고 실패한 검사가 단순 경고로만 표시되며 관리자가 아무 기록 없이 규칙을 건너뛸 수 있다면 AI 전용 체크리스트의 실효성은 낮다.

현재 GitHub, GitLab, Bitbucket, Azure Repos는 명칭과 세부 구현은 달라도 보호 브랜치, PR 또는 MR 경로, 필수 검사, 승인, 직접 Push 제한을 제공한다. 팀의 공통 기본선은 이 통제를 실제 병합 조건으로 강제하는 것이다. (docs.github.com)

공유되는 기본·Release 브랜치에는 적어도 다음 원칙이 적용돼야 한다.

직접 Push와 Force Push를 기본적으로 막는다.
모든 변경이 PR을 통해 들어오게 한다.
필수 검사가 실패하거나 실행되지 않았으면 병합할 수 없게 한다.
새 Commit이 추가되면 최신 변경에 대한 승인을 다시 확인한다.
우회 권한은 소수의 지정된 역할에만 부여한다.

여기서 중요한 것은 UI에 초록색 표시가 나타났다는 사실이 아니라 어떤 시스템이 어느 Revision에 대해 그 결과를 만들었는가다. GitHub Ruleset은 Write 권한을 가진 사람이나 Integration이 Status를 설정할 수 있다는 점을 전제로, 필요한 경우 특정 GitHub App만 검사 결과의 예상 발행자로 지정할 수 있게 한다. 팀에서 만든 자체 검사도 같은 원칙을 적용해야 한다. 검사 이름, 실행 주체, 대상 Commit, 결과 Artifact가 연결되지 않으면 그 초록색 표시는 충분한 증거가 아니다. (docs.github.com)

Required Checks는 “검사가 있었다”가 아니라 “필요한 증거가 남았다”는 뜻이다

모든 PR에 똑같은 검사 묶음을 적용하는 것은 관리하기 쉽지만 변경 위험과 맞지 않을 수 있다. 문서 오탈자와 IAM Policy 변경에 같은 검사만 요구하면 전자에는 과하고 후자에는 부족하다.

이 글에서는 검사를 네 층으로 나눈다.

기본 무결성 검사는 Build, 정적 검사, 팀이 정한 필수 테스트처럼 변경이 Repository의 기본 품질 조건을 깨지 않았는지 확인한다.

보안 검사는 Secret, 취약한 코드 패턴과 보안 정책 위반을 찾는다.

Dependency 검사는 Manifest와 Lockfile에서 직접·간접 Dependency, 취약점, License와 공급 출처가 어떻게 달라졌는지 확인한다.

변경 유형별 검사는 IaC Plan, 권한 Diff, Workflow Permission, 생성물 재현처럼 특정 변경에서만 필요한 증거를 만든다.

정확히 어떤 테스트를 선택할지는 변경 영향과 회귀 위험에 따라 달라진다. 그것은 별도 회귀 범위 설계의 문제다. 이 글에서 정하는 것은 선택된 검사가 병합 전에 반드시 실행되고 결과가 현재 Head Revision과 연결돼야 한다는 조건이다.

보안 검사가 실행되지 않았거나 결과를 평가할 수 없는 상태를 성공으로 처리해서도 안 된다. GitLab의 보안 승인 정책은 필요한 Scanner 결과가 없거나 정책을 평가할 수 없는 경우 추가 승인을 요구하는 Fail-closed 방식을 지원한다. SLSA도 조직이 주장하는 기술 통제가 지속적으로 적용됐다는 증거를 요구한다. 특히 권한, Secret, 배포 경로를 바꾸는 PR에서는 “검사 결과 없음”과 “문제 없음”을 구분해야 한다. (docs.gitlab.com)

AI Review는 보조 증거이지 인간 책임의 자동 대체물이 아니다

AI Code Review는 반복적인 패턴, 누락 가능성, 코드 설명을 빠르게 제공할 수 있다. 그렇다고 AI Review 결과만으로 인간 승인 요건을 충족했다고 간주할 수는 없다.

현재 GitHub Copilot Code Review는 Approve나 Request changes가 아니라 Comment를 남기며 Required Approval 수에 포함되지 않고 자체적으로 병합을 막지도 않는다. Atlassian Rovo Dev의 공식 문서에도 큰 PR에서는 Review Comment를 남기지 않을 수 있고 Dependency Lockfile과 Binary 등 일부 파일은 자동으로 건너뛴다고 명시돼 있다. (docs.github.com)

이 사례가 모든 AI Review의 한계를 동일하게 규정한다는 뜻은 아니다. 다만 다음 원칙은 분명하다.

AI Review를 사용하려면 무엇을 검사했고 무엇을 보지 않았는지 확인할 수 있어야 한다.

AI Review가 남긴 결과는 필수 검사나 인간 검토를 보조할 수 있다. 그러나 AI Review가 실행되지 않았거나 일부 파일을 제외했는데도 단순히 “AI 검토 완료”로 표시해서는 안 된다.

인간 승인이 반드시 필요한 변경

공유되는 기본 브랜치에는 일반적으로 변경을 만든 사람과 다른 승인자가 필요하다. AI Agent가 변경을 만들었다면 Agent에게 작업을 지시하고 결과를 제출한 사람과, 실제 Diff를 독립적으로 승인하는 사람을 구분하는 편이 안전하다.

GitHub의 현재 Copilot Agent 흐름에서도 Agent에게 작업을 할당한 사람의 승인이 Required Approval에 포함되지 않을 수 있고 별도 Reviewer가 필요하다. GitHub와 Azure Repos는 최신 Push를 만든 사람과 다른 승인자를 요구하는 통제도 제공한다. (docs.github.com)

다음 변경은 최소한 해당 영역을 책임지는 사람의 인간 승인을 병합 필수 조건으로 둬야 한다.

Secret과 Credential

실제 API Key, Token, Password, Private Key를 Source Code나 PR 설명에 넣어서는 안 된다. Secret Scanner가 Credential을 발견하면 Review 대상으로 넘기는 것이 아니라 우선 병합을 차단하고 값을 제거해야 한다. 이미 원격 Repository로 Push됐다면 해당 Credential의 폐기·교체 여부도 확인해야 한다. (docs.github.com)

다만 Secret Scan 통과가 Secret 부재를 증명하지는 않는다. GitLab의 Secret Push Protection도 지연과 오탐을 줄이기 위해 높은 신뢰도의 Pattern을 사용하며 일부 사용자 정의 Prefix Token은 탐지하지 못할 수 있다고 설명한다. 따라서 Secret 참조 경로, Environment Variable, Vault 연결, Token Scope와 Signing Key 사용을 바꾸는 PR은 Platform 또는 Security 책임자가 직접 검토해야 한다. (docs.gitlab.com)

Permission·IAM·인증·인가

Role, Policy, Service Account, OAuth Scope, Repository App 권한, 사용자 인증과 인가 로직 변경은 코드 줄 수가 작아도 영향이 크다.

승인자는 변경 전후에 누가 어떤 Resource에 접근할 수 있게 되는지 확인해야 한다. * 권한, 관리자 역할 추가, Tenant 경계 변경처럼 권한 범위를 넓히는 변경에는 변경 이유와 영향을 받는 Identity 목록이 필요하다. NIST SSDF와 SP 800-204D는 Source Code와 Configuration-as-Code를 Least Privilege로 보호하고 Code Commit·Build·Artifact 작업에 세분화된 권한을 정의할 것을 권고한다. (nvlpubs.nist.gov)

Dependency와 Lockfile

Dependency 변경에는 직접 추가한 Package뿐 아니라 Lockfile을 통해 바뀐 간접 Dependency도 포함된다. GitHub Dependency Review는 Manifest와 Lockfile의 직접·간접 변경, 알려진 취약점을 PR 단위로 비교할 수 있으며 해당 검사를 Required Check로 연결할 수 있다. (docs.github.com)

새 Package Registry나 Git Source를 추가하거나, Major Version을 올리거나, Build Plugin과 Post-install Script를 도입하는 변경에는 사람이 공급 출처와 실행 권한을 확인해야 한다. NIST SSDF도 Commercial·Open Source를 포함한 제3자 Component를 수명주기 동안 검증하도록 요구한다. (nvlpubs.nist.gov)

반대로 출처와 허용 범위가 미리 정해진 자동 Patch Update까지 항상 여러 명이 직접 승인해야 한다는 뜻은 아니다. 좁은 범위의 Trusted Automation, 취약점·License·Build 검사, 명시적인 Auto-merge 정책이 결합된 경우에는 조직이 제한적 예외를 설계할 수 있다. 예외는 Bot의 Identity와 변경 가능 범위가 고정돼 있고 정책이 언제 적용됐는지 감사할 수 있을 때만 성립한다. SLSA Source Track도 높은 보증 수준에서 명시적으로 정의된 Trusted Robot 예외 가능성을 둔다. (slsa.dev)

CI Workflow·Build·병합 규칙

CI Workflow와 Build Script는 검사 자체를 정의한다. 이 파일을 변경한 PR이 자신에게 필요한 검사를 제거하거나, 검사 결과를 임의로 성공 처리하거나, 더 넓은 Secret과 Repository 권한을 얻을 수 있다면 일반 애플리케이션 코드보다 더 강한 검토가 필요하다.

GitHub는 Copilot Agent가 변경한 Workflow를 실행하기 전에 사람이 내용을 확인하도록 기본 통제를 두고 있으며 Workflow가 민감한 Secret에 접근할 수 있다는 점을 별도로 경고한다. NIST도 악성 코드가 CI/CD 환경의 Signing Key, Cloud Credential과 Environment Secret을 탈취하지 못하도록 Client와 실행 환경을 보호할 것을 요구한다. (docs.github.com)

다음 파일은 Platform·Repository 관리자 또는 Security Owner를 자동 Reviewer로 지정하는 것이 좋다.

CI/CD Workflow와 공통 Pipeline Template
Branch Ruleset와 Merge Policy
CODEOWNERS 또는 Required Reviewer 설정
Build·Packaging·Signing Script
Repository App과 Action Permission
Secret을 사용하는 Workflow 정의

Infrastructure·Deployment Configuration

IaC, Kubernetes Manifest, Deployment Workflow, Runtime Configuration은 Source Code처럼 보여도 실제 환경의 Network, Compute, Identity, Data Store와 배포 권한을 바꾼다.

병합 전에는 Syntax 통과보다 실행 결과에 가까운 Plan 또는 Diff가 필요하다. 어떤 환경에 적용되는지, Resource가 새로 생기거나 제거되는지, Public Exposure·IAM·State가 어떻게 바뀌는지 확인할 수 있어야 한다. Azure Repos의 공식 보안 가이드도 Deployment·Infrastructure Code와 Shared Pipeline Template을 지정 Reviewer가 필요한 민감 경로의 예로 든다. (learn.microsoft.com)

Change Type × Merge Requirement Matrix

아래 Matrix는 특정 Source Control 제품의 기능표가 아니라, 공식 문서와 표준을 바탕으로 재구성한 팀 운영 권장안이다. 실제 검사 항목과 승인 수는 Repository의 위험 등급, 규제, 팀 규모에 맞게 조정해야 한다.

Change Type	Required Checks	Human Approval	병합 전 추가 증거
문서·주석·비실행 Metadata	문서 Build, Link·Format 검사, 기본 Secret Scan	보통 독립 Reviewer 1명. 범위가 고정된 Trusted Automation은 사전 승인 정책으로 예외 가능	실행 코드·Configuration·권한에 영향이 없다는 확인
일반 애플리케이션 코드	팀 기본 Build·정적 검사·선택된 테스트·보안 검사. 모두 현재 Head Revision 대상	변경을 만든 사람과 다른 Reviewer	변경 목적, 영향 Component, 검사 결과 링크
Test-only 변경	변경된 Test Suite와 기본 검사. Snapshot 대량 갱신 시 Diff 검증	Assertion 삭제·완화, Coverage 감소, 대량 Snapshot 변경은 Domain Owner 필수	제품 동작이 바뀐 것인지 Test 기대값만 바뀐 것인지 설명
Dependency·Manifest·Lockfile	직접·간접 Dependency Diff, 취약점, License, Build	새 공급 출처, Major Version, Build Plugin, Post-install Script는 인간 승인 필수	Package 출처, Manifest와 Lockfile의 관계, 새 실행 권한
Secret·Credential 참조	Push Protection, Secret Scan, Configuration 검증	Security 또는 Platform Owner 필수	실제 Secret 값 미포함, 노출 시 폐기·교체 기록, Scope 전후 비교
Permission·IAM·인증·인가	Policy 검사, 권한 Diff, 관련 보안 검사	Domain Owner와 독립 승인자 필수	변경 전후 Role·Principal·Resource·Tenant 경계
CI/CD·Build·Signing Workflow	Workflow 검증, Permission·Secret 접근 Diff, 예상 Check 발행자 확인	Platform 또는 Repository 관리자 필수. 작성자 단독 승인 금지	사용하는 Token·Secret·Environment, 검사 제거·완화 여부
Ruleset·Branch Policy·CODEOWNERS	Policy-as-Code 검사 또는 설정 Diff, 관리자 Audit	Repository 관리자와 독립된 Security·Platform 책임자	Bypass 대상, Required Check·Approval의 변경 전후
IaC·Deployment·Runtime Configuration	Validate, Plan, Policy Check, 대상 환경별 보안 검사	Platform Owner 또는 해당 Service Owner 필수	적용 환경, Resource·Network·IAM·State 변화
Generated Code·Generated Artifact	Build·재생성 검사, Hash·Provenance, 원본 Source와 Generator 검증	기능 영향을 설명할 수 있는 Domain Reviewer	Generator·Version·입력 Source·Base/Head Revision·생성 경로
대규모 Refactor·검토 불가능한 변경	관련 검사를 모두 실행하되, 통과 여부만으로 병합하지 않음	영향 영역별 Owner. 필요하면 두 번째 독립 Reviewer	PR 분할 계획, Review Map, 생성 파일과 수동 변경의 분리
Emergency Hotfix	시간 안에 가능한 검사를 실행하고 생략한 검사를 명시	미리 지정된 Override Authority와 Risk Owner	Incident ID, 우회 사유, 우회한 Control, 만료 시각, 사후 검토 기한

Matrix의 인간 승인 항목은 AI가 코드를 작성했다는 이유로 일괄 강화한 것이 아니다. 사람이 작성한 IAM 변경도 강한 승인이 필요하고 AI가 수정한 오탈자는 좁은 정책으로 처리할 수 있다. 판단 단위는 작성자 종류가 아니라 변경의 영향과 통제 실패 시 결과다.

Generated Code의 Provenance는 무엇을 남겨야 하나

Agent가 만든 코드의 출처를 남긴다고 해서 전체 Prompt나 모델의 내부 추론을 Repository에 복사해야 하는 것은 아니다. Prompt에는 Credential, 고객 정보, 내부 Architecture가 들어갈 수 있고 모델의 자연어 설명은 코드의 정확성을 입증하지도 않는다.

대신 정책 판단에 사용할 수 있는 관찰 가능한 기록을 남긴다.

text

agent_identity: ""
agent_provider_or_service: ""
human_requester: ""
task_or_issue: ""

repository: ""
target_branch: ""
base_revision: ""
head_revision: ""

generated_or_modified_paths: []
generator_or_tool_versions: []
external_tools_or_context_used: []

required_checks:
  - name: ""
    issuer: ""
    revision: ""
    result: ""
    evidence: ""

human_approver: ""
merge_actor: ""
merged_at: ""

SLSA Source v1.2는 Source Provenance를 Revision이 어떤 Process와 Contributor를 통해 만들어졌고 어떤 Parent Revision에서 왔는지 보여주는 정보로 정의한다. 또 사람이 Plain-text 변경을 이해할 수 있는 Diff를 제공하고 기술 통제와 Actor Identity를 Revision에 연결하도록 요구한다. (slsa.dev)

GitHub의 현재 Agent 흐름처럼 Commit에서 Agent Session Log로 이동할 수 있는 구현도 있다. 하지만 특정 Vendor의 Session 기능이 없더라도 Task, Agent Identity, Base·Head Revision, 실행한 검사와 인간 승인자를 연결하면 기본 감사 구조를 만들 수 있다. (docs.github.com)

Provenance가 있다고 코드가 맞다는 뜻은 아니다. Provenance는 어떻게 만들어졌고 어떤 통제를 거쳤는지를 보여준다. 정확성과 안전성은 별도의 Review와 검사로 판단해야 한다.

너무 큰 PR은 검사를 통과해도 병합하지 않을 수 있다

검토자가 이해할 수 없는 변경은 검토가 완료된 변경이 아니다.

AI Agent는 여러 파일을 빠르게 수정할 수 있어 하나의 PR 안에 기능 추가, Refactor, Dependency Update, 생성 파일과 Formatting 변경이 섞이기 쉽다. 이때 검사 결과가 모두 통과해도 각 변경의 의도와 영향이 분리되지 않으면 문제를 발견하거나 이후 원인을 추적하기 어렵다.

AI Review 도구 자체에도 Coverage 한계가 있다. 예를 들어 Rovo Dev는 1만 줄을 넘는 PR에서 Comment를 남기지 않을 수 있고 Lockfile·Binary·Snapshot 등 일부 파일을 자동 제외한다. 이 수치를 모든 팀의 병합 제한으로 사용할 수는 없지만 “AI가 검토했으니 큰 PR도 검토됐다”고 간주해서는 안 된다는 근거는 된다. (support.atlassian.com)

팀은 고정된 줄 수 하나보다 다음 신호를 함께 보는 편이 낫다.

서로 다른 목적의 변경이 한 PR에 섞였는가
Reviewer가 Diff를 설명할 수 있는가
생성 파일과 사람이 수정한 Source가 구분되는가
Dependency·IAM·Deployment 변경이 일반 코드에 묻혀 있는가
일부 디렉터리나 파일 형식을 Review 도구가 보지 못했는가
검사 실패 원인을 특정 변경으로 좁힐 수 있는가

검토 가능 범위를 넘었다면 PR을 기능·위험·Dependency 기준으로 나눈다. 나눌 수 없는 Migration이나 기계적 대규모 변환이라면 Source PR, 생성 결과, 재생성 명령, 샘플 검토 범위와 Integrity Check를 별도 증거로 남긴다.

Audit Trail은 누가 Merge 버튼을 눌렀는지만 기록해서는 부족하다

병합 기록에는 다음 질문의 답이 남아야 한다.

변경 의도를 승인한 책임자는 누구인가
실제 변경 Actor는 사람, App, Service Account 중 무엇인가
어떤 Base Revision에서 어떤 Head Revision이 만들어졌는가
어떤 검사를 어느 Identity가 실행했는가
Reviewer는 어느 Revision을 보고 승인했는가
어떤 규칙이 적용됐고 어떤 규칙이 우회됐는가
최종 병합 Actor와 시각은 무엇인가

Agent의 권한 모델은 제품마다 다르다. GitHub Copilot Cloud Agent처럼 App Identity와 특정 Branch로 제한될 수도 있고 GitLab처럼 Service Account를 사용할 수도 있으며 사용자 권한을 위임받아 동작할 수도 있다. 따라서 로그에는 단순히 AI 사용이라고 적는 대신 실제 Identity와 Scope를 남겨야 한다. (docs.github.com)

플랫폼 기본 Audit Log를 영구 원장으로 가정해서도 안 된다. 현재 GitHub Organization Audit Log는 최근 180일의 활동을 제공하고 Azure DevOps Audit Event의 기본 보존 기간은 90일이다. 더 긴 보존이 필요하다면 Export나 Audit Streaming 등 별도 보존 정책이 필요하다. (docs.github.com)

Emergency Override는 보호 규칙을 끄는 행위가 아니다

서비스 장애나 심각한 보안 문제를 처리할 때 모든 일반 검사와 승인을 기다리기 어려울 수 있다. 그렇다고 Branch Protection을 잠시 끄거나 관리자 계정으로 조용히 직접 Push하면, 긴급 변경이 가장 추적하기 어려운 변경이 된다.

Emergency Override는 일반 병합 조건을 없애는 것이 아니라 검증되지 않은 위험을 누가 어떤 이유로 일시 수용했는지 기록하는 별도 경로여야 한다.

text

override_id: ""
pull_request: ""
head_revision: ""

incident_or_change_id: ""
reason: ""
risk_owner: ""

bypassed_controls:
  - control: ""
    reason: ""

override_approver: ""
merge_actor: ""

approved_at: ""
expires_at: ""
post_review_due_at: ""

post_review_result: ""
follow_up_issues: []

우회 권한은 사전에 지정된 소수에게만 주고 가능하면 직접 Push보다 기존 PR의 특정 조건을 우회하는 방식을 택한다. GitLab의 현재 보안 승인 정책은 우회 권한을 특정 사용자·Role·Service Account에 한정하고 UI나 Push Option에서 사유를 요구하며 우회 Event를 Audit Log에 기록할 수 있다. GitHub 역시 Ruleset의 Bypass Request와 Rule Insight를 통해 요청자, 승인자, 상태와 실패·우회 규칙을 확인할 수 있다. (docs.gitlab.com)

영구 Exemption은 긴급 우회와 다르다. GitHub도 현재 일반 Bypass를 명시적인 Break-glass 동작과 Audit Signal이 남는 방식으로 설명하는 반면, exempt 유형은 통제를 조용히 건너뛰는 별도 설정으로 구분한다. 긴급 대응을 위해 광범위한 영구 Exemption을 주면 사후에 정상 자동화와 비정상 우회를 구분하기 어렵다. (github.blog)

사후 검토에서는 생략했던 검사를 실제 병합 Revision에 다시 실행하고 Domain Owner가 Diff를 검토하며 발견된 문제를 후속 PR이나 Issue로 연결한다. Override가 반복된다면 개인의 판단 문제가 아니라 검사 시간, 소유권, Runbook 또는 병합 정책의 구조적 문제인지도 확인해야 한다.

병합 가능과 출시 가능은 같은 판정이 아니다

Merge Gate를 통과했다는 것은 해당 변경을 보호 브랜치의 다음 상태로 받아들일 수 있다는 뜻이다. 운영 환경에 배포하거나 사용자에게 출시해도 된다는 의미까지 자동으로 포함하지는 않는다.

출시 판단에는 병합된 여러 변경의 결합 결과, 미해결 결함, 운영 준비, 관측 가능성, 복구 가능성과 잔여 위험이 함께 필요하다. 이 전체 판정은 상위 문서인 ‘출시 여부를 결정할 때 테스트 결과 외에 무엇을 확인해야 할까’가 소유한다.

요구사항과 코드·테스트의 관계를 찾는 일은 추적성 설계가, 실제 회귀 범위를 고르는 일은 위험 기반 회귀 전략이, 그중 무엇을 자동화할지는 테스트 자동화 포트폴리오가 각각 다룬다. 이 글의 역할은 그 결과들이 병합 전에 확인 가능한 증거로 제출되고 맞는 사람이 책임 있게 승인되도록 문을 설계하는 것까지다.