LLM 리뷰어는 유용하지만, 일부 PR 체크는 결정론적(Deterministic)으로 유지되어야 합니다

AI 코딩 에이전트(AI coding agents)들이 풀 리퀘스트(Pull Request, PR)를 생성하는 능력이 점점 좋아지고 있습니다.

이는 리뷰 문제의 성격을 변화시킵니다.

일반적인 리뷰는 코드가 올바르게 보이는지, 설계가 타당한지, 그리고 엣지 케이스(edge cases)가 고려되었는지를 묻습니다.

이러한 질문들은 여전히 중요합니다.

하지만 AI가 생성한 풀 리퀘스트는 또한 다른 종류의 질문을 제기합니다:

에이전트가 의도된 작업 범위를 벗어나 무언가를 변경하지는 않았는가? 그리고 머지(merge)하기에 충분하고 반복 가능한 증거가 있는가?

저는 이것을 **판단(judgment)**과 **증거(evidence)**의 분리로 생각하기 시작했습니다.

LLM 리뷰어는 판단을 돕습니다. 에이전트 게이트(Agent Gate)는 결정론적인(deterministic) 머지 증거를 검증합니다.

저는 모든 리뷰 질문이 엄격한 CI 게이트(CI gate)가 되어야 한다고 생각하지는 않습니다. 코드 리뷰의 일부는 인간의 맥락(human context)이 필요합니다. 어떤 부분은 LLM이 의심스러운 패턴을 포착함으로써 이득을 얻습니다. 하지만 몇몇 체크 항목들은 충분히 기계적이어서, 머지 전에 결정론적이고, 반복 가능하며, 가시적이어야 한다고 생각합니다.

다음은 제가 AI 생성 PR을 고려할 때 현재 사용하고 있는 체크리스트입니다.

1. PR이 범위(scope) 내에 머물렀는가?

첫 번째 질문은 코드가 좋은가 하는 것이 아닙니다.

그것은 PR이 변경하기로 되어 있던 파일들을 변경했는가 하는 것입니다.

사람이 올린 PR의 경우, 관련 없는 수정 사항은 리뷰 과정에서 설명하기 쉬울 수 있습니다. 하지만 에이전트의 PR에서 관련 없는 수정은 더 의심스럽습니다. 왜냐하면 그것이 지시 사항의 이탈(instruction drift), 도구의 실수, 또는 유지 관리자가 요청하지 않은 광범위한 리팩터링(refactor)을 반영할 수 있기 때문입니다.

간단한 계약(contract)이 도움이 될 수 있습니다:

이 PR은 다음 항목을 수정할 수 있습니다:
- src/auth/**
- tests/auth/**

그러면 리뷰는 결정론적인 질문을 던질 수 있습니다:

PR이 해당 경로 이외의 항목을 건드렸는가?

이것이 코드가 올바르다는 것을 증명하지는 않습니다. 단지 PR이 선언된 경계 내에 머물렀음을 증명할 뿐입니다.

그 경계는 여전히 중요합니다.

2. 워크플로 권한이 상승(escalate)되었는가?

GitHub Actions 워크플로는 에이전트가 수정할 때 가장 위험도가 높은 곳 중 하나입니다.

작은 소스 코드 변경과 워크플로 권한 변경은 동일한 위험 프로필(risk profile)을 갖지 않습니다.

예를 들어, 다음과 같은 내용을 추가하거나 변경하는 PR이 있다면 매우 눈에 띄는 경고를 받고 싶습니다:

permissions:
  contents: write

또는 새로운 워크플로 경로(workflow path)에서 secrets.*를 사용하기 시작하는 경우입니다.

이것은 의미론적 코드 리뷰(semantic code review)의 문제가 아닙니다. 이것은 정책 경계(policy boundary)의 문제입니다.

질문은 결정론적(deterministic)입니다:

이 PR이 워크플로 권한을 증가시켰거나 위험한 워크플로 패턴을 도입했는가?

그러한 종류의 체크는 LLM이 우연히 댓글에서 이를 알아차렸는지 여부에 의존해서는 안 됩니다.

3. 에이전트 제어 평면(agent-control-plane) 파일이 변경되었는가?

AI 코딩 에이전트(AI coding agents)는 종종 미래의 동작을 형성하는 파일에 의존합니다:

AGENTS.md
CLAUDE.md
.github/copilot-instructions.md
...

이러한 파일에 대한 변경은 향후 에이전트 실행, 도구 액세스(tool access), 또는 저장소별 지침(repo-specific instructions)에 영향을 미칠 수 있습니다.

이 점이 일반적인 문서 변경과 다른 점입니다.

만약 AI가 생성한 PR이 .mcp.json 또는 AGENTS.md를 수정한다면, 소스 코드의 차이(diff)가 무해해 보이더라도 머지(merge) 전에 해당 사실이 명확하게 드러나기를 바랍니다.

결정론적인 질문은 다음과 같습니다:

PR이 향후 에이전트 동작을 제어하는 파일을 변경했는가?

이는 여러 저장소에 걸쳐 코딩 에이전트를 도입하는 팀에게 특히 중요한데, 제어 평면(control plane)이 조용히 표류(drift)할 수 있기 때문입니다.

4. 일치하는 테스트 증거가 있는가?

테스트 증거(test evidence)는 까다롭습니다.

변경 된 테스트 파일이 동작이 올바르다는 것을 증명하지는 않습니다. 테스트가 의미 있다는 것을 증명하지도 않습니다. 커버리지(coverage)를 증명하지도 않습니다.

하지만 위험도가 높은 영역의 경우, 일치하는 테스트 변경 사항이 없다는 사실 자체도 여전히 유용한 증거가 됩니다.

만약 PR이 인증 로직(auth logic), 결제 처리(payment handling), 세션 미들웨어(session middleware), 또는 마이그레이션(migration)을 변경한다면, 해당 PR이 관련 테스트 파일도 변경했는지 알고 싶습니다.

체크 문구는 신중하게 작성되어야 합니다:

일치하는 테스트 파일 증거가 없습니다.

'이 PR은 테스트되지 않았습니다'가 아니라 말입니다:

This PR is untested.

이러한 구분은 중요합니다. 결정론적 체크는 자신이 알고 있는 정확한 사실만을 말해야 하며, 그 이상을 넘어서는 안 됩니다.

5. 패키지 스크립트나 의존성(dependencies)이 표류했는가?

이것이 제가 추가할 첫 번째 규칙은 아닐 수도 있지만, 계속해서 다시 생각하게 되는 규칙 중 하나입니다.

패키지 매니페스트(Package manifests)와 락파일(lockfiles)은 의미 있는 위험을 숨길 수 있습니다:

package.json
pnpm-lock.yaml
yarn.lock
...

어떤 변경 사항은 일반적인 의존성 유지 관리(dependency maintenance)이지만, 다른 변경 사항은 더 많은 주의를 기울여야 합니다:

{
  "scripts": {
    "postinstall": "node scripts/setup.js"
...

AI가 생성한 PR의 경우, 저는 다음 사항을 알고 싶습니다:

라이프사이클 스크립트(lifecycle script)가 나타났는가?
기존 패키지 스크립트가 변경되었는가?
예상된 락파일(lockfile) 변경 없이 의존성(dependencies)이 변경되었는가?

다시 말씀드리지만, 모든 발견 사항이 차단(block)되어야 하는 것은 아닙니다. 하지만 이러한 변경 사항은 쉽게 식별할 수 있어야 합니다.

6. 적절한 인간 리뷰어가 승인했는가?

이 지점은 결정론적 증거(deterministic evidence)가 인간의 소유권(human ownership)과 만나는 곳입니다.

PR이 범위(scope) 내에 머물고, 워크플로우 에스컬레이션(workflow escalation)을 피하며, 테스트 증거를 포함하더라도 여전히 적절한 리뷰어가 필요할 수 있습니다.

예시:

src/auth/** 변경 -> 보안 리뷰어(security reviewer) 필요
.github/workflows/** 변경 -> 플랫폼 리뷰어(platform reviewer) 필요
.mcp.json 변경 -> 유지 관리자/플랫폼(maintainer/platform) 승인 필요

이것이 항상 기본적으로 차단되어야 한다고 생각하지는 않습니다. 특히 1인 유지 관리자의 경우 더욱 그렇습니다. 하지만 팀의 경우, 리뷰어 증거는 가장 유용한 신호 중 하나가 될 수 있습니다.

질문은 다음과 같습니다:

이 PR의 위험한 부분에 대해 적절한 인간이 승인했는가?

이것은 리뷰를 대체하는 것이 아닙니다. 소유권을 가시화하는 방법입니다.

무엇이 인간의 영역으로 남아야 하는가?

매우 많습니다.

저는 결정론적 CI(deterministic CI)가 다음과 같은 질문에 답하기를 원하지 않습니다:

이 설계가 좋은가?
이 추상화(abstraction)가 그만한 가치가 있는가?
사용자들이 이 동작을 이해할 수 있을 것인가?
...

이것들은 판단(judgment)의 문제입니다.

LLM 리뷰어는 판단을 도울 수 있습니다. 하지만 판단의 주인은 인간 리뷰어입니다. 결정론적 게이트(deterministic gates)는 매번 동일한 방식으로 확인할 수 있는 증거에 집중해야 합니다.

무엇이 결정론적이어야 하는가?

가장 적합한 후보는 다음과 같은 체크 항목들입니다:

• 설명 가능함 (explainable)
• 반복 가능함 (repeatable)
• 놓치기 어려움 (hard to miss)
• 머지 위험(merge risk)과 연결됨
• PR 코드를 실행하는 것에 의존하지 않음

저의 경우, 현재 다음과 같은 것들이 포함됩니다:

• PR 범위 경계 (PR scope boundaries)
• 워크플로우 권한 상승 (workflow permission escalation)
• 위험한 워크플로우 패턴 (dangerous workflow patterns)
• 에이전트 제어 평면 드리프트 (agent-control-plane drift)
• 고위험 경로에 대한 테스트 파일 증거 누락 (missing test-file evidence for high-risk paths)
• 패키지 스크립트 및 의존성 드리프트 (package script and dependency drift)
• 민감한 경로에 대한 리뷰어 증거 (reviewer evidence for sensitive paths)

이러한 체크들이 AI가 생성한 PR을 안전하게 만드는 것은 아닙니다.

이것들은 머지(merge) 전에 위험 요소를 더 쉽게 검사할 수 있게 해줄 뿐입니다.

경고 모드(warn mode)로 시작하기

가장 안전한 도입 경로는 첫날부터 모든 것을 차단하는 것이 아닙니다.

저는 다음과 같이 경고(warnings)부터 시작할 것입니다:

mode: warn
fail-on-block: false

그 다음 실제 PR들을 관찰합니다.

어떤 결과가 유용한가?
어떤 것이 노이즈(noisy)인가?
어떤 것을 머지 게이트(merge gates)로서 신뢰할 수 있는가?

그 이후에야 노이즈가 적은 결과들을 차단형 체크(blocking checks)로 격상시킬 것입니다.

마치며

저는 AI가 생성한 PR 리뷰에는 판단(judgment)과 증거(evidence)가 모두 필요하다고 생각합니다.

LLM 리뷰어는 판단을 돕는 데 기여할 수 있습니다.

결정론적(Deterministic) CI 체크는 머지 증거를 검증해야 합니다.

저는 AI 생성 PR에서 결정론적 머지 증거를 확인하기 위한 작은 GitHub Action인 Agent Gate에서 이 아이디어를 탐구하고 있습니다.

공개 사항: 저는 이 글의 초안 작성 및 편집을 위해 AI의 도움을 받았으며, 게시 전 기술적 주장들을 직접 검토했습니다.