본문으로 건너뛰기

© 2026 Molayo

Qiita헤드라인2026. 06. 28. 22:02

AI의 셀프 리뷰가 위험한 이유와 역할 분리의 구현

요약

AI가 코드를 작성하는 시대에 구현자와 심사자의 역할 분리가 왜 중요한지 분석합니다. 동일 모델이 구현과 리뷰를 모두 수행할 때 발생하는 편향성과 에러 상관관계 문제를 지적하며, 독립적인 리뷰 체계 구축의 필요성을 강조합니다.

핵심 포인트

  • AI 구현자와 심사자의 역할 분리는 코드 리뷰의 독립성을 위해 필수적임
  • 동일 모델 사용 시 훈련 데이터 편향 및 문맥 공유로 인한 리스크 발생
  • 독립된 리뷰 에이전트 활용 시 코드 리뷰 커버리지 향상 가능
  • Devin, Copilot 등 주요 도구의 셀프 머지 방지 설계 사례 제시

AI가 코드를 작성할 수 있는 시대에, 「누가 그 코드를 운영 환경(Production)에 반영할 것인가」라는 질문에는 아직 답이 나오지 않았다. 기술적으로는 AI 스스로 PR(Pull Request)을 머지(Merge)할 수 있는 도구가 존재하지만, 이는 코드 리뷰의 독립성을 근본적으로 파괴한다. 「Human이 최종 머지한다」라는 개념은 확산되고 있지만, 「구현자와 심사자를 서로 다른 모델로 나누고, 그 역할 분리를 정책으로서 명문화한다」라는 한 단계 앞선 실천은 2026년 시점에서도 공개 사례가 거의 없다. 이 기사는 그 질문을 정리하고, 우리가 어떻게 답을 구현했는지를 기록한다.

AI가 코드를 작성하는 시대가 되었다. GitHub Copilot은 보완(Completion)부터 구현까지 담당하게 되었고, Devin은 「AI 소프트웨어 엔지니어」를 자처하며, Claude Code는 터미널(Terminal)에서 리포지토리(Repository)를 조작한다. PR을 만드는 것은 이제 인간만이 아니다.

하지만, 거기서 하나의 질문이 조용히 떠오른다.

누가, 그 PR을 운영 환경에 넣을지 판단하는가.

이 질문에 대한 답은 도구의 진화 속도에 비해 놀라울 정도로 뒤처져 있다.

코드 리뷰의 목적을 한마디로 말하자면, 구현자의 시야 밖에 있는 리스크를 포착하는 것이다.

구현자는 코드의 의도를 알고 있다. 그렇기에 의도에 부합하지 않는 동작을 알아차리기 어렵다. 버그는 많은 경우, 「이렇게 동작할 것이다」라는 전제의 그늘에 숨어 있다.

리뷰어는 의도를 모르는 만큼, 코드를 코드로서 읽는다. 거기에 독립성의 가치가 있다.

이 전제가 무너지는 상황이 있다. 구현자가 심사자를 겸할 때다.

재무의 세계에서는 이것이 이해상충(Conflict of Interest)으로서 제도적으로 금지되어 있다. 논문 심사에서는 저자가 자신의 논문을 심사하지 않는다. 의료 윤리 심사에서는 당사자가 자신의 연구 계획을 승인하지 않는다.

코드 리뷰도 같은 구조를 가지고 있다. 변경을 가한 인물이 그 변경의 안전성을 판단하는 유일한 인물이어서는 안 된다.

그리고 지금, 이 이해상충이 AI 문맥에서 발생할 수 있는 상황이 생겨나고 있다.

AI 모델이 구현한 PR을 동일한 모델(또는 동일한 계열의 모델)이 리뷰하면, 다음 세 가지 문제가 발생한다.

① 훈련 데이터의 편향(Bias)이 공유된다. 동일한 모델 계열은 같은 데이터로 훈련된다. 어떤 패턴을 「옳다」고 학습했다면, 구현에서도 채택하고 리뷰에서도 문제 삼지 않을 가능성이 높다.

② 구현 시의 문맥(Context)이 리뷰로 이어진다. 구현 시의 판단이 그대로 리뷰 시의 전제가 된다. 인간도 「쓴 사람이 직접 리뷰한다」고 하면 느슨해지는 것과 같은 경향이다.

③ 에러가 상관(Correlation)된다. 독립된 두 개체가 같은 실수를 저지를 확률은, 동일한 한 개체가 두 번 확인하는 경우보다 낮다. Anthropic의 Claude Code Review는 여러 서브 에이전트(Sub-agent)가 병렬로 리뷰하는 구성으로 커버리지(Coverage)가 16%에서 54%로 향상되었다고 보고되었다 (출처). 독립성에는 측정 가능한 가치가 있다.

「Human이 최종 머지를 승인한다」는 운용은 주요 도구의 설계에 서서히 포함되어 왔다. 하지만 「확산되고 있다」와 「규칙으로서 문서화되어 있다」는 다르다.

업계의 사례는 세 가지 카테고리로 나눌 수 있다.

① 설계상 셀프 머지(Self-merge)를 금지하고 있는 도구

Devin은 설계상 스스로 PR을 self-merge 할 수 없는 사양으로 되어 있다 (출처). Copilot Coding Agent는 PR을 만들지만, 머지는 인간이 승인한다 (출처).

② Human 브랜치 보호 규칙(Branch Protection Rule)을 추가한 팀

newmo는 Devin이 만든 PR에 대해 「Human 2명의 승인이 필수」라는 branch protection을 설정했다 (2025년 4월) (출처). 이 블로그 기사의 문체는 시사적이다. —— 「당연히 하고 있는 일」로서 쓰인 것이 아니라, 「이렇게 설정하지 않으면 위험했다」는 경험으로서 기록되어 있다. Variant Systems는 7개의 가드레일(Guardrail)을 문서화했다 (2026년 1월) (출처).

③ AI가 AI를 리뷰하지만 독립성이 불충분한 케이스

CyberAgent는 Devin이 자신의 PR을 /devin-review 명령어로 재심사하는 워크플로우를 본업에 도입했다 (2025년 7월) (출처). 「AI에 의한 리뷰」의 공개 사례로서 가장 가까운 구성 중 하나이지만, 구현한 Devin이 리뷰도 하고 있다 —— 독립성은 확보되지 않았다.

합리적인 반론이 있을 수 있다: 모든 PR(Pull Request)에 이 정도 수준의 거버넌스 (Governance)가 필요할까? 당연히 아니다. 의존성 자동 업데이트나 오타(typo) 수정에는 파이프라인이 필요 없다. 여기서 논하는 것은 기본값(Default) —— 즉, 아무도 예외를 명시하지 않은 변경 사항에 대한 규칙이다.

"Human(인간)이 최종 머지(Merge)한다"는 거버넌스의 입구다. 하지만 질문은 하나 더 있다. 머지 전의 AI 리뷰를, 누가 담당할 것인가.

크로스 벤더(Cross-vendor) AI 리뷰는 이미 실천되고 있다. OpenAI Codex의 Claude Code용 플러그인(2026년 3월 출시)은 한쪽 에이전트가 구현하고 다른 벤더가 리뷰하는 패턴을 공식적으로 지원한다.

반면, 2026년 시점의 조사에 따르면, 크로스 벤더 리뷰를 조직 정책(Organization Policy)으로 명문화한 공개 사례는 거의 확인되지 않았다. 실천은 퍼지고 있지만, 정책화는 거의 이루어지지 않았다.

이것이 메워야 할 격차(Gap)다.

TheGateBreaker는 여러 AI 워커(Worker)를 GitHub Issues와 Pull Request를 통해 조정하는 워크플로우의 실험 리포지토리(Repository)다. Human이 최종 의사 결정자로서 기능한다. 이 글에서 논하는 거버넌스 패턴의 동작 중인 테스트베드(Testbed)로서 위치하고 있다.

우리의 리포지토리에서는 이 운영 정책을 버전 관리되는 문서로서 유지하고 있다.

구현: ClaudeCode (Anthropic) -
독립 리뷰: Codex (OpenAI의 클라우드 코딩 에이전트) -
최종 클로즈 판단: Human

중요한 것은 이것이 구두 관습이 아니라는 점이다. 리포지토리의 설정 파일(AGENTS.mdCLAUDE.md)에 명문화된 정책으로서 존재한다. ClaudeCode가 자신의 구현을 스스로 리뷰하는 일은 없다. Codex가 구현하는 일도 없다. 역할은 의도적으로, 그리고 기록으로서 분리되어 있다.

이것이 유일하게 올바른 아키텍처(Architecture)라고 주장하는 것은 아니다. ClaudeCode와 Codex만이 담당할 수 있는 것도 아니다. 중요한 것은 구현, 리뷰, 최종 승인이 별개의 역할로서, 예외가 발생하기 전에 기록되어 있다는 점이다.

"AI가 구현한 것을 AI가 리뷰하고 AI가 머지하는 것은 위험하다" —— 현재 많은 개발자는 직관적으로 이를 알고 있다. 그렇기에 많은 팀이 자연스럽게 그러한 운용을 피하고 있다.

문제는 "피하고 있는 것"과 "정책으로서 결정한 것"의 차이다.

팀원이 바뀌었을 때, 새로운 도구를 도입했을 때, 급할 때 —— 예외가 발생한다. 예외가 관습이 된다. 관습이 문제가 될 때까지는 보이지 않는다.

규칙을 쓰는 것은 제약이 아니다. 압박 속에서도 누구나 "당연한 것"을 기억하고 있을 것이라 기대하지 않고, 팀이 빠르게 움직일 수 있는 구조를 만드는 것이다.

Human final merge는 확산되고 있다. 하지만 다음 사항들에 대해서는 아직 많은 팀의 답이 통일되지 않았다.

  • 구현자와 심사자를 다른 모델로 분리한다는 판단을 어디에 기록할 것인가
  • 어떤 모델이 어떤 역할을 맡을지를 관습이 아닌 정책으로서 작성하고 있는가
  • AI 리뷰를 통과하면 Human은 실질적으로 러버 스탬프(Rubber-stamp, 형식적인 승인)가 되어버리는 것 아닌가
  • 리뷰의 독립성을 위해 벤더의 다양성이 필요한가

"당연한 것"에는 기록이 남지 않는다. 기록이 남지 않는다는 것은, 다음 사람이 동일한 질문을 처음부터 다시 고민해야 함을 의미한다.

그래서 기록한다.

AI 코딩 에이전트를 인간의 책임 레이어(Accountability layer)를 우회하지 않고 활용하기 위한 실천적인 노트를 계속 이어갑니다. 팔로우와 구독을 기다립니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0