Copilot이 작성한 PR에 대한 승인은 GitHub에서 인정되지 않습니다. 여러분의 노트북도 마찬가지일 것입니다

• 책: Ship It — the pragmatic startup tech stack
• 저자 소개: Thinking in Go (2부작 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구로 배포하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

You이 Copilot 클라우드 에이전트에게 이슈를 할당합니다. 몇 분 후 풀 리퀘스트(pull request, PR)가 생깁니다. 여러분은 diff를 읽고 괜찮아 보이면 승인(Approve) 버튼을 누릅니다. 하지만 병합 규칙(merge rule)에 따라 이 클릭은 무시됩니다: [GitHub 문서](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/review-copilot-prs]에 따르면,

• 저장소에 쓰기 권한이 있는 사용자만 에이전트를 트리거할 수 있으며, 쓰기 권한이 없는 사용자의 댓글은 절대 그것으로 전달되지 않습니다.
• 새로운 작업의 경우 에이전트는 새로운 copilot/ 브랜치를 얻게 되며, 해당 브랜치로만 푸시할 수 있습니다.
• 에이전트는 자신의 풀 리퀘스트를 '검토 준비 완료(Ready for review)'로 표시할 수 없으며, 풀 리퀘스트를 승인하거나 병합할 수 없습니다.
• 에이전트는 작동하는 저장소에 설정된 모든 브랜치 보호 규칙(branch protections)과 필수 검사(required checks)의 적용을 받습니다.
• 워크플로우는 저장소에 쓰기 권한이 있는 사용자가 워크플로우 승인 및 실행(Approve and run workflows) 버튼을 클릭할 때까지 대기합니다.
• 해당 페이지는 경감 조치로, GitHub가 "Copilot cloud agent에게 풀 리퀘스트 생성을 요청한 사용자가 이를 승인하는 것을 방지한다"고 명시합니다.

마지막 내용은 흥미로운 선택입니다. Copilot이 커밋의 작성자이며, 변경 사항을 요청한 개발자는 공동 작성자로 표시됩니다. GitHub는 당신을 봇 작업에 대한 외부 검토자로 취급할 수도 있었습니다. 하지만 그렇지 않았습니다. 당신을 작성자의 편에 세웠습니다.

이는 GitHub가 이미 인간에게 적용하던 규칙과 일치합니다. 필수 검토 페이지에 따르면, "풀 리퀘스트 작성자는 자신의 풀 리퀘스트를 승인할 수 없습니다." 같은 페이지에서는 사용자가 이슈에 Copilot을 할당한 경우 Copilot이 생성한 풀 리퀘스트도 승인할 수 없다고 명시합니다. 프롬프트를 작성한 사람이 작성자로 간주되는 것입니다.

워크플로우(workflow) 측면에는 옵트아웃(opt-out) 기능이 있습니다. 2026년 3월 13일 변경 로그 항목에 따라, 리포지토리 관리자는 에이전트(agent)에 대해 워크플로우 실행 승인 필요(Require approval for workflow runs) 기능을 끌 수 있습니다. 설정 페이지에는 이 기능 옆에 경고 문구가 표시됩니다: 이렇게 할 경우 "Copilot이 작성한 검토되지 않은 코드가" 리포지토리에 쓰기 접근 권한을 얻거나 Actions 시크릿(secrets)에 도달할 수 있게 될 수 있습니다. 승인 기능은 기본적으로 활성화된 상태를 유지합니다.

노트북에서, 당신은 세 사람 모두입니다

NIST의 용어집에는 직무 분리(separation of duty)를 한 문장으로 정의하고 있습니다: "어떤 사용자도 시스템을 임의로 오용할 수 있는 충분한 권한을 부여받아서는 안 된다." NIST는 두 사람 규칙(two-person rule)을 예시로 제시합니다. GitHub는 이 원칙을 에이전트 풀 리퀘스트에 적용했습니다. 로컬 에이전트 세션에는 이에 상응하는 것이 없습니다.

터미널에서 코딩 에이전트를 실행하면 커밋 기록은 당신의 git 신원(identity) 아래에 남게 됩니다. 심지어 GitHub 에이전트일 수도 있습니다: Copilot CLI는 사용자를 대신하여 파일을 실행하거나 수정하거나 셸 명령어(shell commands)를 실행하는 등의 작업을 수행할 수 있습니다. 같은 공급업체, 같은 종류의 작업입니다. 일단 그 커밋들이 당신의 것이 되고 로컬에서 병합(merge)하면, GitHub의 어떤 규칙도 에이전트가 그것을 작성했다는 사실을 알지 못합니다.

하지만 노트북에게도 공평해야 합니다. 만약 main 브랜치가 보호되어 있고 리뷰가 필요하다면, 직접 푸시(direct push)는 거부됩니다. GitHub의 보호된 브랜치 문서에 따르면, 리뷰가 필수인 경우 “협업자들은 풀 리퀘스트(pull request)를 통해서만 보호된 브랜치에 변경 사항을 푸시할 수 있습니다.” 따라서 여전히 팀원의 승인이 필요합니다. 이 허점은 세 곳에서 발생합니다:

• 로컬 병합(local merge). git merge agent/fix-login을 배포하는 브랜치나, 나중에 하나의 큰 PR에 올라가서 에이전트의 부분이 간과될 수 있는 브랜치에 수행할 때.
• 관리자(admin). 해당 페이지에는 “기본적으로, 브랜치 보호 규칙의 제한 사항은 리포지토리에 대한 관리자 권한을 가진 사람에게는 적용되지 않습니다.”라고 명시되어 있습니다. 소규모 팀에서는 에이전트를 실행하는 사람이 종종 관리자입니다.
• 리뷰처럼 느껴지는 리뷰. 여러분은 에이전트가 수정한 diff를 주의 깊게 읽었습니다. 하지만 Copilot 풀 리퀘스트에 대한 GitHub 자체 규칙상, 여러분의 독해는 카운트되지 않습니다. 왜냐하면 여러분이 그 작업을 요청했기 때문입니다. 노트북은 그것을 유일한 리뷰로 간주합니다.

워크플로우 게이트(workflow gate) 역시 노트북 버전이 없습니다. GitHub에서는 기본적으로 에이전트가 .github/workflows/에 수정한 내용은 누군가 승인하기 전까지 실행되지 않으며, 문서에서는 이러한 변경 사항에 대해 “특히 주의를 기울일 것”이라고 알려줍니다. 로컬 환경에서는 에이전트가 편집한 테스트 명령어가 여러분이나 에이전트가 호출할 때마다, 선택한 권한 모드 내에서 셸(shell)에서 실행됩니다.

두 번째 핵심은 에이전트를 따라야 합니다

규칙: 에이전트 브랜치는 팀원이 승인하는 풀 리퀘스트로 도착하고, 여러분이 작성한 체크가 작업 완료 시점을 알려줍니다.

병합(merging) 대신 GitHub CLI를 사용하여 브랜치를 푸시하고 PR을 여세요:

git push -u origin agent/fix-login
gh pr create --base main --fill

--fill은 커밋에서 제목과 본문을 가져오므로, 에이전트의 커밋 메시지가 리뷰어가 가장 먼저 읽는 PR 설명이 됩니다. 만약 모호하다면 수정하세요.

GitHub 측에서 격차를 메우려면, main 브랜치의 보호 규칙(branch protection rule)을 설정해야 합니다:

• 최소 한 명의 승인을 받도록 풀 리퀘스트 검토(pull request reviews)를 요구합니다.
• 위 설정을 우회할 수 없도록 허용하지 않음(Do not allow bypassing the above settings) 옵션을 켜서 관리자 예외(admin exemption)를 제거합니다.
• **가장 최근에 검토 가능한 푸시 승인 필수(Require approval of the most recent reviewable push)**를 켭니다. 보호 브랜치 문서에 따르면, "가장 최근에 검토 가능한 푸시는 푸시한 사람 이외의 누군가에 의해 승인되어야 합니다."
• 상태 확인(status checks)을 통과하도록 요구하고, 테스트 작업을 그중 하나로 만듭니다.

그리고 위험도가 높은 경로에는 소유자(owner)를 지정해 주세요. Code owners는 "누군가 자신이 소유한 코드를 수정하는 풀 리퀘스트를 열 때 자동으로 검토 요청이 이루어지며," **Code Owners로부터의 검토 필수(Require review from Code Owners)**를 설정하면 그들의 승인이 의무화됩니다:

# .github/CODEOWNERS
*	@acme/backend
.github/workflows/	@acme/platform

순서가 중요합니다: "일치하는 마지막 패턴이 가장 높은 우선순위를 가집니다." 따라서 워크플로우 라인은 모든 것을 포괄하는(catch-all) 패턴 뒤에 위치해야 합니다.

Hermes에서 연결하기 (Wiring this up in Hermes)

저는 Hermes IDE를 구축했으므로 이 섹션을 염두에 두고 읽어주세요. Hermes는 각 에이전트(Claude Code, Codex, Copilot CLI 등)를 자체 터미널에서, 자신의 hermes/<task> 브랜치 및 작업 트리에서 실행합니다. 이는 README를 참고하세요.

리뷰 데스크(Review Desk)(Windows와 Linux에서는 ⌘G, Ctrl+Shift+G)는 에이전트의 작업을 시간별 또는 파일별로 읽어보는 곳입니다. 이러한 검토는 유용하며, GitHub의 논리에 따르면 이것만으로는 당신을 두 번째 사람으로 만들어주지 못합니다.

중요한 부분은 Land입니다. README에 따르면, Land는 "작업이 시작된 브랜치에 커밋하거나, 풀 리퀘스트(pull request)를 열거나, 로컬에서 병합하는 것을 한 단계로 처리하며, 되돌릴 수 있습니다." 풀 리퀘스트를 선택하면 승인은 GitHub에서 이루어지며, 이때 사용자의 브랜치 규칙이 적용됩니다.

같은 README 라인에는 다음과 같은 내용이 추가됩니다: "사용자 자체 검사(checks)가 작업 완료 시점을 결정할 수 있습니다." 따라서 로컬의 "완료됨(done)" 상태와 GitHub의 "병합 가능(mergeable)" 상태가 일치하도록, CI에서 필수 상태 검사가 실행되는 것과 동일한 명령을 그곳에 실행해야 합니다.

Hermes가 하지 않는 것: 아무도 승인하도록 강제할 수 없습니다. 필수 검토(Required reviews)는 GitHub의 역할이며, 만약 그것을 선택하더라도 Hermes는 로컬에서 병합합니다. Hermes는 무료이며 BSL 1.1 하에 소스 코드가 공개되어 있고 macOS, Windows 및 Linux에서 사용할 수 있으며, Nous Research, Anthropic, OpenAI 또는 GitHub와 제휴하지 않았습니다. 다운로드하기를 하거나 GitHub에서 코드를 읽으십시오.

이것이 비용을 발생시키는 지점

솔로 개발자는 두 번째 사람이 없습니다. 그러면 작성한 검사(check)가 두 번째 당사자가 됩니다: 이 검사는 누가 변경을 요청했는지 알지 못하며 에이전트가 얼마나 자신감 있게 들렸는지는 신경 쓰지 않습니다. 필수 검토를 건너뛰고, 해당 검사를 필수 상태 검사(required status check)로 만들고, 심지어 본인도 거치도록 자신의 레포지토리(repo)에서 관리자 우회(admin bypass) 기능을 끄십시오.

팀의 경우, 비용은 지연 시간(latency)입니다: 이제 모든 에이전트 브랜치가 팀 동료를 기다리게 되며, 이는 이미 github.com에서 Copilot 클라우드 에이전트 PR이 하는 방식과 같습니다.

에이전트 브랜치를 로컬에서 병합하도록 허용하시겠습니까, 아니면 에이전트가 작성하는 모든 것이 다른 사람이 승인하는 풀 리퀘스트(PR)를 거치게 해야 할까요? 댓글로 알려주세요.

유용했다면

브랜치 규칙(Branch rules), 필수 검사 항목(required checks), 그리고 누가 병합할 수 있는지에 대한 설정은 작은 팀이 한 번 제대로 구축하고 나서 잊어버리는 종류의 것들입니다. _Ship It_은 소규모 팀을 위해 로컬호스트(localhost)부터 프로덕션까지의 구간을 다룹니다: 호스팅, 배포(deploys), 인증(auth), 결제(payments), CI/CD 및 모니터링. 이 글을 읽고 브랜치 보호 설정(branch protection settings)을 열어보게 되었다면, book에서 나머지 스택에 대해 자세히 알아볼 수 있습니다.