💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

2026년 6월, 테스트 라이브러리 jqwik의 메인테이너 Johannes Link가 쓴 "The jqwik Anti-AI Affair"라는 글이 GeekNews와 Hacker News를 달궜습니다. AI 기여를 둘러싸고 OSS 프로젝트에서 벌어진 갈등을 메인테이너 본인의 시점에서 기록한 이 글은, 많은 개발자가 막연히 느끼던 불안을 정면으로 건드렸습니다. AI가 코드를 쏟아내는 속도와, 사람이 그것을 검토할 수 있는 속도 사이의 간극 말입니다.

숫자로 보면 상황은 명확합니다. 코딩 에이전트가 보편화된 2026년 현재, 많은 팀에서 새로 작성되는 코드의 절반 이상이 AI의 손을 거칩니다. 코드를 쓰는 비용은 10분의 1로 떨어졌는데, 코드를 검토하는 비용은 거의 그대로입니다. 병목은 이제 작성이 아니라 리뷰입니다. 그리고 기존의 코드리뷰 관행 — 사람이 쓴 코드를 사람이 줄 단위로 읽는 방식 — 은 이 부하를 감당하도록 설계되지 않았습니다.

이 글에서는 AI 생성 코드의 결함 패턴이 사람 코드와 어떻게 다른지, 그 차이에 맞춰 리뷰 전략을 어떻게 재설계해야 하는지, AI로 AI 코드를 리뷰하는 파이프라인, OSS와 팀 차원의 정책, 그리고 측정 지표까지 차례로 다룹니다.

왜 리뷰가 병목이 되었나

작성과 검토의 비대칭을 그림으로 보면 이렇습니다.

2023년: 사람 작성 + 사람 리뷰

작성 ████████████████ (느림)

리뷰 ████ (작성 대비 작은 비중)

2026년: AI 작성 + 사람 리뷰

작성 ██ (빠름, 대량)

리뷰 ████████████████████████ (병목!)

PR 수 3배, PR당 디프 크기 2배,

리뷰어의 시간은 그대로

문제를 악화시키는 요인이 두 가지 더 있습니다.

첫째, 리뷰 피로의 질이 달라졌습니다. 사람 코드의 결함은 대개 "어딘가 어설픈" 신호를 동반합니다. 일관성 없는 네이밍, 어색한 구조 같은 것들이 리뷰어의 주의를 끕니다. AI 코드는 정반대입니다. 표면적으로 깔끔하고 자신감 있게 틀립니다. 리뷰어가 의심의 단서를 잡기 어렵습니다.

둘째, 작성자가 자기 코드를 설명하지 못하는 경우가 늘었습니다. "왜 이렇게 구현했나요"라는 질문에 "에이전트가 그렇게 했습니다"라는 답이 돌아오는 PR은, 리뷰의 전제(작성자가 코드를 이해하고 있다)를 무너뜨립니다.

사람 코드와 AI 코드 — 결함 패턴이 다르다

리뷰 전략을 다시 짜려면 먼저 적을 알아야 합니다. AI 생성 코드의 결함은 사람의 결함과 분포가 다릅니다.

| 결함 유형 | 사람 코드 | AI 코드 |

| --- | --- | --- |

| 오타, 문법 실수 | 흔함 | 드묾 |

| 그럴듯한 로직 오류 | 가끔 | 흔함 (자신감 있게 틀림) |

| 환각된 API | 거의 없음 | 흔함 (존재하지 않는 메서드, 패키지) |

| 과도한 방어 코드 | 드묾 | 흔함 (불필요한 try-catch, null 체크 중첩) |

| 요구사항 오해 | 질문으로 해소 | 침묵 속에 잘못 구현 |

| 컨벤션 위반 | 드묾 (팀 학습) | 가이드 없으면 흔함 |

| 죽은 코드, 중복 구현 | 가끔 | 흔함 (기존 유틸 미탐색) |

| 보안 취약점 | 패턴 다양 | 학습 데이터의 낡은 패턴 재생산 |

특히 주의할 세 가지를 짚어보겠습니다.

그럴듯한 오류 (plausible-but-wrong)

AI 코드의 대표 결함입니다. 타입도 맞고, 테스트 일부도 통과하고, 변수명도 그럴듯한데, 비즈니스 로직의 경계 조건이 미묘하게 틀린 경우입니다. 예를 들어 날짜 범위 비교에서 경계 포함 여부, 통화 계산에서 반올림 시점, 페이지네이션의 off-by-one 같은 것들. 사람이라면 "확신이 없어서" 주석이나 질문을 남길 지점에서, AI는 매끄럽게 틀린 코드를 생성합니다.

전형적인 예를 코드로 보겠습니다.

스펙: "구독은 만료일 당일까지 유효하다"

def is_active(sub, today) -> bool:

AI 생성 — 매끄럽지만 틀림: 만료일 당일이 제외된다

return sub.start_date <= today < sub.expires_on

def is_active_correct(sub, today) -> bool:

올바른 구현: 경계 포함

return sub.start_date <= today <= sub.expires_on

이 디프는 타입체크와 해피패스 테스트를 모두 통과합니다. 잡아내는 방법은 구현 독해가 아니라, 만료일 당일을 검증하는 경계 테스트가 존재하는지 확인하는 것입니다.

from datetime import date

def test_active_on_expiry_day():

sub = make_sub(start="2026-06-01", expires="2026-06-30")

assert is_active(sub, date(2026, 6, 30)) # 경계 케이스

환각된 API와 패키지

존재하지 않는 라이브러리 메서드를 호출하거나, 존재하지 않는 패키지를 의존성에 추가하는 결함입니다. 후자는 보안 문제로 직결됩니다. 공격자가 AI가 자주 환각하는 패키지 이름을 미리 등록해두는 슬롭스쿼팅(slopsquatting) 공격이 실제로 관찰되고 있고, 2026년 6월의 npm 공급망 공격 사태는 의존성 추가가 곧 보안 결정임을 다시 일깨웠습니다. arXiv에 공개된 "We Have a Package for You!" 연구는 상용 모델조차 상당 비율로 존재하지 않는 패키지를 추천한다는 것을 정량적으로 보여줬습니다.

과도한 방어 코드

AI는 비판을 회피하는 방향으로 학습된 경향이 있어, 필요 없는 곳에 try-catch를 두르고, 도달 불가능한 null 체크를 중첩하고, 모든 함수에 방어 로직을 복제합니다. 이것은 단순한 스타일 문제가 아닙니다. 오류를 삼키는 catch 블록은 장애를 침묵시키고, 중복 방어는 "이 값이 실제로 null일 수 있는가"라는 설계 정보를 파괴합니다.

리뷰 전략의 재설계

결함 분포가 다르면 리뷰의 주의 배분도 달라져야 합니다. 세 가지 원칙을 제안합니다.

원칙 1 — 줄이 아니라 스펙과 대조하라

사람 코드 리뷰는 "코드를 읽으며 결함을 찾는" 상향식이 통했습니다. AI 코드는 표면이 깨끗하므로 상향식 독해의 효율이 낮습니다. 대신 하향식으로 갑니다. 먼저 요구사항(이슈, 스펙, 인수 조건)을 읽고, "이 요구가 코드 어디에서 충족되는가"를 추적합니다. 스펙에 없는 코드(스코프 폭발)와 코드에 없는 스펙(누락)을 찾는 것이 1차 목표입니다.

상향식 (기존): 코드 --> 읽기 --> 결함 발견 --> 스펙 확인

하향식 (재설계): 스펙 --> 인수 조건 목록화 --> 코드에서 충족 지점 추적

--> 남는 코드 = 의심 대상

원칙 2 — 테스트를 먼저 리뷰하라

구현보다 테스트를 먼저 읽습니다. 확인할 것은 두 가지입니다. 첫째, 테스트가 스펙의 인수 조건을 실제로 검증하는가(테스트가 구현을 베껴 쓴 동어반복이 아닌가). 둘째, 경계 조건 케이스가 있는가. AI의 그럴듯한 오류는 대부분 경계에 숨으므로, "빈 입력, 최대값, 동시성, 시간대"를 다루는 테스트의 존재 여부가 강력한 품질 신호입니다. 테스트가 신뢰할 만하면 구현 독해의 부담을 크게 줄일 수 있습니다.

원칙 3 — 디프 크기를 강제하라

리뷰 품질은 디프 크기에 반비례합니다. 연구로도 실무로도 반복 확인된 사실이지만, AI 시대에는 강제 장치가 필요합니다. 에이전트는 시키면 3,000줄짜리 PR도 한 번에 만들어내기 때문입니다. 실용적인 상한은 PR당 400줄 내외이며, CI에서 기계적으로 검사하는 것이 좋습니다.

세 원칙을 종합하면 리뷰어의 시간 배분도 달라집니다. 60분 리뷰 기준의 권장 배분입니다.

리뷰 시간 배분 가이드 (60분 기준, AI 관여 PR)

스펙 대조 ████████████████ 20분

테스트 리뷰 ████████████ 15분

보안/의존성 점검 ██████████ 12분

구현 독해 (샘플링) ██████ 8분

설계 피드백 작성 ████ 5분

.github/workflows/pr-size-gate.yml

name: pr-size-gate

on: [pull_request]

jobs:

check-size:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

with:

fetch-depth: 0

- name: Fail if diff exceeds limit

run: |

LINES=$(git diff --shortstat origin/${{ github.base_ref }}... \

| awk '{print $4 + $6}')

echo "changed lines: $LINES"

if [ "$LINES" -gt 400 ]; then

echo "PR too large. Split it."

exit 1

AI로 AI 코드를 리뷰하기 — 자동 1차 리뷰 + 인간 최종

AI가 만든 부하를 사람만으로 처리할 수 없다면, 리뷰에도 AI를 투입하는 것이 자연스러운 귀결입니다. 다만 역할 분담이 핵심입니다.

PR 생성

[게이트 0] CI: 빌드, 테스트, 린트, 디프 크기, 시크릿 스캔

[게이트 1] AI 1차 리뷰 (기계가 잘하는 것)

- 환각 API 검증: 모든 import와 호출이 실제 존재하는가

- 새 의존성 검증: 레지스트리 존재, 다운로드 수, 라이선스

- 스펙 대조: 이슈의 인수 조건별 충족 여부 표 생성

- 과도한 방어 코드, 죽은 코드, 중복 구현 플래그

- 테스트 약화 감지 (assert 제거, skip 추가)

[게이트 2] 인간 최종 리뷰 (사람이 잘하는 것)

- 설계 적절성: 이 접근 자체가 맞는가

- 제품 판단: 엣지 케이스의 우선순위

- 보안 설계: 신뢰 경계, 권한 모델

- AI 1차 리뷰 결과의 샘플 검증

AI 1차 리뷰어에게 주는 지시의 예시입니다.

리뷰어 에이전트 지시 (발췌)

너는 1차 리뷰어다. 머지 권한은 없다. 출력은 아래 형식의 표로만.

검사 항목:

1. 디프의 모든 외부 API 호출을 나열하고, 해당 버전의 공식 문서에

존재하는지 각각 확인하라. 확인 불가면 UNVERIFIED로 표기.

2. 새로 추가된 의존성마다: 레지스트리 등록일, 주간 다운로드,

라이선스를 조회해 표로 정리하라.

3. 이슈의 인수 조건을 행으로, 충족 근거(파일:줄)를 열로 표를 만들어라.

근거를 찾지 못한 조건은 MISSING으로 표기하라.

4. 테스트 디프에서 제거되거나 약화된 assert가 있으면 모두 나열하라.

금지: 칭찬, 사소한 스타일 지적, 추측에 근거한 승인 의견.

중요한 운영 원칙이 하나 있습니다. AI 리뷰어의 출력은 "판정"이 아니라 "증거 수집"이어야 합니다. 승인/반려를 AI에게 맡기면, 작성 에이전트와 리뷰 에이전트가 같은 사각지대를 공유할 때 결함이 그대로 통과합니다. AI는 표를 만들고, 사람이 판단합니다.

환각 의존성의 자동 검증

게이트 1의 검사 중 "의존성 실재 검증"은 LLM 없이도 스크립트로 결정적으로 만들 수 있습니다.

#!/usr/bin/env bash

check-new-deps.sh — 새 의존성의 실재와 위생을 검사

set -euo pipefail

BASE_REF="origin/main"

NEW_DEPS=$(git diff "$BASE_REF"...HEAD -- package.json \

| grep '^+ ' | grep -oE '"[@a-z0-9/._-]+"\s*:' \

| tr -d '": ' | sort -u)

for dep in $NEW_DEPS; do

created=$(npm view "$dep" time.created 2>/dev/null) || {

echo "FAIL: $dep — 레지스트리에 없음 (환각/오타 의심)"

exit 1

}

license=$(npm view "$dep" license 2>/dev/null || echo "UNKNOWN")

echo "OK: $dep (created: $created, license: $license)"

done

echo "dependency check passed"

존재하지 않는 패키지는 여기서 결정적으로 차단되고, 등록일과 라이선스 정보는 인간 리뷰의 입력으로 전달됩니다. 결정적으로 검사할 수 있는 것은 LLM에게 맡기지 않는다 — 게이트 1 설계의 기본 원칙입니다.

구현 선택지 비교

자동 1차 리뷰를 구성하는 선택지는 크게 세 가지입니다.

| 선택지 | 장점 | 단점 |

| --- | --- | --- |

| 상용 리뷰 봇 | 도입 즉시, 관리 불필요 | 커스텀 검사 제한, 코드 외부 전송 |

| CI에서 에이전트 직접 호출 | 검사 항목 완전 통제 | 프롬프트와 비용 관리 부담 |

| 자체 파이프라인 | 결정적 검사와 LLM의 혼합 최적화 | 구축과 유지보수 비용 |

어느 쪽을 택하든 핵심 요건은 같습니다. 검사 결과가 구조화된 형식으로 PR에 남아야 하고, 인간 리뷰어가 그것을 입력으로 쓸 수 있어야 합니다.

리뷰 체크리스트 — 보안, 라이선스, 성능

AI 생성 코드에 특화된 체크리스트입니다. 팀 위키에 그대로 옮겨도 되도록 작성했습니다.

보안

- 새 의존성: 패키지가 레지스트리에 실존하는가, 등록일이 최근 수 주 이내로 수상하지 않은가, 메인테이너가 신뢰할 만한가

- 입력 검증: AI가 만든 정규식에 ReDoS 가능성은 없는가

- 인증/인가: 학습 데이터의 낡은 패턴(약한 해시, 하드코딩된 시크릿, 구식 TLS 설정)이 재생산되지 않았는가

- 오류 처리: catch 블록이 보안 관련 오류를 삼키고 있지 않은가

- 프롬프트 유래 검증: 외부 콘텐츠를 읽는 에이전트가 만든 코드라면, 인젝션으로 유도된 변경이 아닌지 디프의 의도를 이슈와 대조

라이선스

- 생성된 코드가 특정 OSS 구현과 사실상 동일하지 않은가 (대형 함수 단위 유사도 검사)

- 새 의존성의 라이선스가 조직 정책(예: GPL 계열 금지)과 충돌하지 않는가

- 코드 출처 표기가 필요한 사내 정책이 있다면 AI 생성 여부가 기록되었는가

성능

- 루프 안의 N+1 쿼리, 반복 정렬, 불필요한 deep copy — AI가 자주 만드는 패턴

- 과도한 방어 코드로 인한 핫패스의 불필요한 검사

- 동시성: AI는 락 범위를 보수적으로 크게 잡는 경향 — 병목 가능성 확인

PR 단위의 재설계와 커밋 위생

리뷰 가능한 PR은 작성 단계에서 만들어집니다. 에이전트에게 다음을 가이드 파일로 강제합니다.

- 1 PR = 1 의도: 기능 추가와 리팩터링을 한 PR에 섞지 않습니다. 에이전트는 "겸사겸사" 수정을 좋아하므로 명시적으로 금지해야 합니다.

- 커밋은 이야기 순서로: "테스트 추가 → 구현 → 리팩터"처럼 리뷰어가 따라갈 수 있는 순서로 커밋을 구성하게 합니다.

- PR 설명 템플릿: 무엇을(스펙 링크), 어떻게(접근 요약), 검증(실행한 테스트), AI 관여도(전부/부분/없음)를 필수 항목으로.

- 기계 변경과 의미 변경의 분리: 포매팅, 임포트 정리 같은 기계적 변경은 별도 커밋으로 분리해 리뷰 노이즈를 제거합니다.

PR 설명 템플릿의 예시입니다.

무엇을 (스펙)

- 이슈 142 — 결제 웹훅 재시도 로직

어떻게 (접근 요약)

- 멱등성 키 검증 + 지수 백오프 재시도 큐

검증

- ./verify.sh 통과

- 신규 테스트 8건 (경계 케이스 4건 포함)

- 스테이징에서 웹훅 재전송 수동 확인

AI 관여도

- partial (구현: 에이전트, 테스트 설계와 검토: 사람)

리뷰어를 위한 안내

- 핵심 판단 지점: 최대 재시도 5회로 가정 (스펙 공백, 확인 요청)

- 의도적으로 제외한 것: 데드레터 처리 (후속 PR 예정)

특히 마지막 "리뷰어를 위한 안내" 항목이 중요합니다. 작성자가 스스로 불확실하다고 느낀 지점을 표면화하면, 리뷰어의 주의를 가장 위험한 곳에 집중시킬 수 있습니다. AI가 작성한 코드일수록 이 항목을 사람이 직접 쓰게 해야 합니다.

OSS 메인테이너의 관점 — jqwik 사건이 남긴 것

jqwik 사건의 전말은 이렇습니다. 메인테이너가 AI 기여에 대한 보수적 정책을 밝히자 격렬한 반발과 논쟁이 이어졌고, 그 과정에서 메인테이너 개인에 대한 공격까지 벌어졌습니다. 이 사건이 보여주는 것은 기술 문제가 아니라 거버넌스 문제입니다.

OSS 메인테이너에게 AI 기여는 비대칭 비용 문제입니다. 기여자는 에이전트로 10분 만에 PR을 만들지만, 메인테이너는 그것을 검토하는 데 한 시간을 씁니다. curl의 Daniel Stenberg가 AI가 양산한 가짜 보안 리포트("AI slop")에 대해 공개적으로 경고한 것도 같은 맥락입니다. 검토 비용을 지불하는 쪽과 생성 비용을 절약하는 쪽이 다른 사람이라는 것 — 이것이 갈등의 경제학입니다.

건강한 프로젝트들이 수렴하고 있는 정책 방향은 다음과 같습니다.

- 금지가 아니라 공개: AI 사용 자체를 막기보다, PR에 AI 관여도를 명시하게 합니다. 숨기는 것이 적발되면 그때 제재합니다.

- 기여자 책임 원칙: "당신이 제출한 코드는 당신이 설명할 수 있어야 한다." 도구가 무엇이었든 책임은 제출자에게 있습니다.

- 신뢰 단계제: 첫 기여자의 대형 PR은 받지 않고, 작은 기여로 신뢰를 쌓은 뒤 범위를 넓히게 합니다.

- 메인테이너 보호: 리뷰 거부는 정당한 권리입니다. "리뷰받을 권리"는 존재하지 않습니다.

팀 정책 템플릿

사내 팀용 정책의 출발점으로 쓸 수 있는 템플릿입니다.

AI 생성 코드 정책 (팀 표준 v1)

허용

- 모든 업무 코드에 AI 도구 사용 가능

- 단, 제출자는 디프의 모든 줄을 설명할 수 있어야 한다

의무

- PR 설명에 AI 관여도 표기: full / partial / none

- AI 관여 PR은 자동 1차 리뷰(게이트 1) 통과 필수

- 새 의존성 추가는 별도 커밋 + 의존성 검증 체크 통과

금지

- 테스트 파일과 CI 설정의 에이전트 수정

- 리뷰 코멘트에 대한 AI 자동 응답 (사람이 읽고 답할 것)

- 400줄 초과 PR (분할 필수, 예외는 리드 승인)

리뷰어 보호

- AI 관여 PR의 리뷰 SLA는 일반 PR의 1.5배

- 리뷰어는 "설명 불가 코드"를 사유로 반려할 수 있다

도입 로드맵

전체 재설계를 한 번에 도입할 필요는 없습니다. 효과 대비 마찰이 작은 순서로 권장합니다.

1. 1주차 — 디프 크기 게이트와 AI 관여도 표기: CI 한 개와 PR 템플릿 한 줄로 시작합니다. 마찰이 가장 적고 효과가 즉각적입니다.

2. 2주차 — 의존성 검증 스크립트: check-new-deps.sh를 CI에 추가합니다. 환각 패키지와 슬롭스쿼팅을 결정적으로 차단합니다.

3. 3에서 4주차 — AI 1차 리뷰(게이트 1) 도입: 처음에는 코멘트만 달고 차단하지 않는 관찰 모드로 운영하며 적중률을 측정합니다.

4. 2개월차 — 정책 문서화와 지표 대시보드: 팀 정책 템플릿을 자기 팀에 맞게 수정해 공식화하고, 다음 절의 지표를 주간 단위로 봅니다.

5. 분기마다 — 정책 회고: 적중률이 낮은 검사는 제거하고, 머지 후 결함에서 새 검사 항목을 역산합니다.

자주 묻는 질문

- AI 1차 리뷰의 비용이 부담된다 — 게이트 0(CI)을 통과한 PR에만 게이트 1을 돌리고, 디프가 작으면 검사 항목을 줄이는 조건부 실행으로 시작하세요.

- 작성자가 AI를 썼는지 어떻게 확인하나 — 확인하려 들지 마세요. 신고 기반 정책(표기 의무 + 허위 표기 시 제재)이 탐지 기반 정책보다 운영 비용이 훨씬 낮고 분쟁도 적습니다.

- 리뷰어가 절대적으로 부족하다 — 리뷰어 추가보다 디프 크기 상한 강화가 먼저입니다. 400줄 PR 1건보다 100줄 PR 4건이 같은 리뷰 시간으로 더 높은 품질을 냅니다.

- 긴급 수정은 예외로 해야 하나 — 예외 경로를 만들되, 사후 리뷰를 의무화하고 예외 사용 빈도를 지표로 추적하세요. 예외가 상시화되면 정책이 죽습니다.

측정 지표 — 리뷰 재설계가 효과 있는지 어떻게 아는가

정책은 측정 없이는 개선되지 않습니다. 추천 지표는 다음과 같습니다.

| 지표 | 정의 | 보고 싶은 방향 |

| --- | --- | --- |

| 리뷰 리드타임 | PR 생성에서 첫 리뷰까지 | 감소 |

| 머지 후 결함률 | 머지 후 N일 내 revert, hotfix 비율 | 감소 |

| 디프 크기 중앙값 | PR당 변경 줄 수 | 400줄 이하 유지 |

| AI 1차 리뷰 적중률 | AI 플래그 중 사람이 유효하다고 판정한 비율 | 60% 이상 |

| 리뷰어 부하 분산 | 리뷰어별 주간 리뷰 줄 수 편차 | 감소 |

| 환각 API 유출 수 | 머지 후 발견된 존재하지 않는 API 호출 | 0 유지 |

특히 "머지 후 결함률"을 AI 관여도별로 나눠 보면, 정책이 실제로 작동하는지가 드러납니다. AI 관여 PR의 결함률이 유의하게 높다면 게이트 1을 강화해야 하고, 차이가 없다면 과도한 절차를 줄일 수 있습니다.

지표 수집을 처음부터 자동화할 필요는 없습니다. 주간 단위로 다음 세 가지만 손으로 세어도 방향은 잡힙니다.

- 이번 주 머지된 PR 중 400줄 초과 비율

- AI 1차 리뷰 플래그 중 사람이 채택한 비율

- revert 또는 hotfix로 이어진 머지 건수

함정과 비판적 시각

이 재설계 자체에도 함정이 있습니다.

첫째, 자동화 편향입니다. AI 1차 리뷰가 "통과"를 주면 사람이 검토를 건너뛰는 경향이 생깁니다. AI 리뷰는 증거 수집이지 면죄부가 아니라는 원칙을 프로세스로 강제해야 합니다(예: 인간 리뷰어가 AI 리포트의 항목 중 최소 2개를 직접 검증).

둘째, 형식주의의 위험입니다. AI 관여도 표기, 체크리스트, 디프 상한이 늘어날수록 "절차는 지켰지만 아무도 생각하지 않는" 리뷰가 될 수 있습니다. 지표가 좋아지는데 장애가 늘어난다면 형식주의를 의심해야 합니다.

셋째, 기여 문화의 위축입니다. jqwik 사건의 이면에는 선의의 기여자들이 위축되는 부작용도 있었습니다. 정책의 목적은 AI 배제가 아니라 검토 가능성의 회복임을, 정책 문서 자체에 명시하는 것이 좋습니다.

마지막으로 근본적인 질문이 남습니다. 코드 작성이 거의 공짜가 된 세계에서, 줄 단위 리뷰라는 행위 자체가 유효한가? 장기적으로는 "코드를 읽는 리뷰"에서 "스펙, 테스트, 속성을 검증하는 리뷰"로, 검토의 대상 자체가 이동할 가능성이 큽니다. 이 글의 재설계는 그 과도기의 전략입니다.

마치며

코드리뷰는 원래 두 가지 일을 동시에 했습니다. 결함을 잡는 일과, 팀이 코드베이스에 대한 공유된 이해를 유지하는 일. AI는 첫 번째 일의 부하를 폭증시켰고, 두 번째 일의 전제(작성자가 이해하고 있다)를 흔들었습니다.

그래서 재설계의 본질은 도구가 아니라 책임의 재배치입니다. 기계가 검증할 수 있는 것은 기계에게(환각 API, 의존성, 디프 크기, 테스트 약화), 사람만 할 수 있는 것은 사람에게(설계 판단, 제품 감각, 최종 책임). 그리고 누가 만들었든 "제출자가 설명할 수 없는 코드는 머지되지 않는다"는 원칙을 지키는 것. 그것이 AI 시대에도 코드리뷰가 의미를 유지하는 길이라고 생각합니다.

참고 자료

- Johannes Link — The jqwik Anti-AI Affair: https://blog.johanneslink.net/2026/06/09/the-jqwik-anti-ai-affair/

- GeekNews — jqwik 반-AI 사건 토픽: https://news.hada.io/topic?id=30373

- jqwik — Property-Based Testing for Java: https://jqwik.net/

- Google Engineering Practices — Code Review Guide: https://google.github.io/eng-practices/review/

- We Have a Package for You! (패키지 환각 연구): https://arxiv.org/abs/2406.10279

- Do Users Write More Insecure Code with AI Assistants?: https://arxiv.org/abs/2211.03622

- Daniel Stenberg — The I in LLM stands for intelligence: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

- GitHub Octoverse — AI와 개발 생태계 통계: https://github.blog/news-insights/octoverse/

- SmartBear — Best Practices for Peer Code Review: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

- Hacker News: https://news.ycombinator.com/