AI가 만든 PR, 코드부터 읽지 마세요: 큰 변경을 검토하는 6단계

월요일 아침, 리뷰 요청 하나가 도착했습니다.

로그인 오류를 수정했습니다. AI로 빠르게 정리했고 테스트 243개가 모두 통과합니다.

그런데 PR을 열어 보니 변경된 파일이 47개였습니다. 인증 코드뿐 아니라 사용자 삭제 API, 데이터베이스 마이그레이션, 새 패키지 세 개까지 함께 들어 있었습니다.

“테스트가 모두 통과했다”는 문장은 안심을 줬지만, 정작 무엇을 바꾸려는 PR인지 한 문장으로 설명하기 어려웠습니다.

AI가 만든 큰 변경을 만났을 때 코드 첫 줄부터 읽으면 금방 지칩니다. 변경량이 많다는 이유로 대충 승인하거나, 반대로 모든 줄을 완벽히 이해할 때까지 리뷰를 붙잡게 됩니다.

좋은 리뷰는 모든 코드를 같은 무게로 읽는 일이 아닙니다. 목적을 먼저 고정하고, 실패 비용이 큰 곳에 집중한 뒤, 주장과 증거가 연결되는지 확인하는 일입니다.

1단계. 목적과 비목표를 한 문장씩 고정하기

PR 설명에서 가장 먼저 찾아야 할 것은 파일 목록이 아니라 사용자에게 일어날 변화입니다.

• 목적: 만료된 세션으로 로그인할 때 사용자가 반복적으로 로그인 화면으로 돌아가는 문제를 해결한다.
• 비목표: 회원 탈퇴 흐름, 데이터 스키마, UI 디자인은 변경하지 않는다.

이 두 문장이 있으면 47개 파일을 전부 같은 눈으로 볼 필요가 없습니다. 사용자 삭제 API와 마이그레이션 파일은 즉시 “왜 비목표 영역이 바뀌었지?”라는 검토 대상이 됩니다.

비목표는 일을 덜 하겠다는 핑계가 아닙니다. 이번 변경의 경계선을 그어 범위 밖 변경을 발견하는 기준입니다.

2단계. 작성자에게 변경 흐름을 자기 말로 설명하게 하기

“AI가 만들어서 자세히는 모릅니다”는 설명이 될 수 없습니다. AI를 사용했더라도 PR의 책임은 제출한 사람에게 있습니다.

작성자는 최소한 다음 흐름을 설명할 수 있어야 합니다.

1. 사용자의 요청이 어디로 들어오는가?
2. 어떤 조건에서 문제가 발생했는가?
3. 상태와 데이터가 어느 경로로 바뀌는가?
4. 수정은 그 흐름의 어느 지점에 들어갔는가?
5. 실패하면 사용자가 무엇을 보게 되는가?

설명하다 막히는 부분은 비난할 지점이 아니라 사람이 먼저 읽어야 할 위치입니다. 말로 연결되지 않는 코드는 아직 팀이 소유하지 못한 코드입니다.

3단계. 파일 순서가 아니라 실패 비용 순서로 읽기

diff 상단부터 차례대로 읽지 않습니다. 문제가 생겼을 때 복구 비용이 큰 영역부터 봅니다.

우선순위먼저 볼 영역확인할 질문

1	인증·권한	권한이 없는 사용자가 통과할 수 있는가?
2	결제·데이터 삭제	중복 실행이나 부분 실패로 돈·데이터가 잘못 바뀌는가?
3	데이터베이스 마이그레이션	기존 데이터와 롤백 경로가 안전한가?
4	외부 API·비동기 작업	타임아웃과 재시도 때 부작용이 반복되는가?
5	화면·문구	사용자가 상태와 실패 이유를 이해할 수 있는가?

위험은 코드 줄 수와 비례하지 않습니다. 권한 조건 한 줄이 CSS 파일 수십 개보다 더 오래 검토할 가치가 있습니다.

4단계. 새 의존성과 낯선 코드의 출처 확인하기

AI가 코드를 생성했다는 사실만으로 자유롭게 사용할 권리가 생기지는 않습니다. 새 패키지가 보이면 manifest와 lockfile을 함께 확인합니다.

• 어떤 패키지와 버전이 추가됐는가?
• 직접 의존성뿐 아니라 전이 의존성은 무엇인가?
• 저장소의 LICENSE, 파일 헤더, 패키지 메타데이터는 무엇을 말하는가?
• 조직에서 허용한 라이선스와 배포 방식에 맞는가?
• 승인된 기존 도구나 작은 독립 구현으로 대체할 수 있는가?

출처를 확인할 수 없다면 AI에게 추측하게 하지 않고 미확인으로 표시합니다. 법률 판단이 필요한 항목은 개발자가 혼자 결론 내리지 않고 담당자에게 넘깁니다.

낯설게 구체적인 함수명, 주석, 오류 문구가 보이면 저장소 검색으로 유사성을 확인하는 습관도 필요합니다.

5단계. 테스트 개수가 아니라 요구사항을 증명하는지 보기

테스트 243개가 통과해도 이번 버그를 재현하는 테스트가 없을 수 있습니다.

다음 세 질문을 던집니다.

1. 수정 전 코드에서는 실패하고 수정 후에는 통과하는 테스트가 있는가?
2. 정상 사례뿐 아니라 만료·권한 없음·외부 실패 같은 경계를 다루는가?
3. 구현 내부 호출 횟수가 아니라 사용자에게 보이는 동작을 검사하는가?

로그인 오류라면 “함수가 호출됐다”보다 아래 계약이 중요합니다.

def test_expired_session_redirects_once_and_shows_login():
    response = client.get("/dashboard", session=expired_session)

    assert response.redirect_count == 1
    assert response.location == "/login"
    assert response.data_was_not_deleted

테스트는 녹색 배지가 아니라 PR의 주장을 입증하는 증거여야 합니다.

6단계. 확신이 낮은 지적에는 재현 방법 붙이기

리뷰어도 틀릴 수 있습니다. “이 코드는 동시성 버그가 있습니다”라고 단정하기 전에 관찰 가능한 확인 방법을 붙입니다.

세션 갱신 요청 두 개가 동시에 들어오면 토큰이 두 번 발급될 가능성이 있어 보입니다. 동일한 사용자로 갱신 API를 병렬 호출한 뒤 발급된 활성 토큰 수가 1개인지 확인해 볼 수 있을까요?

이 문장은 우려의 근거, 재현 조건, 기대 결과를 함께 전달합니다. 작성자는 방어적으로 반응하는 대신 실험으로 답할 수 있습니다.

좋은 리뷰 댓글의 목적은 누가 맞는지 가리는 것이 아니라 불확실성을 줄이는 것입니다.

큰 PR을 빠르게 파악하는 리뷰 카드

PR을 열었을 때 다음 여섯 칸을 먼저 채워 보세요.

항목한 줄 기록

목적	사용자의 어떤 결과가 바뀌는가?
비목표	이번에 바꾸지 않기로 한 것은 무엇인가?
고위험 파일	실패 비용이 큰 파일은 어디인가?
범위 밖 변경	목적과 연결되지 않는 diff는 무엇인가?
증거	요구사항을 입증하는 테스트·로그는 무엇인가?
남은 위험	아직 확인하지 못한 것은 무엇인가?

이 카드가 채워지지 않으면 코드를 더 오래 읽기 전에 PR 설명과 변경 범위를 먼저 보완해야 합니다.

AI에게는 코드 재작성보다 리뷰 지도를 요청하기

다음 프롬프트를 PR 설명과 diff 앞에 붙여 사용해 보세요.

아래 PR은 AI를 활용해 작성됐다. 코드를 다시 작성하지 말고 리뷰 준비를 도와줘.
1. 변경 목적과 비목표를 한 문장씩 요약해 줘.
2. 사람이 먼저 읽어야 할 고위험 파일 5개와 이유를 적어 줘.
3. 범위 밖 변경과 새 의존성을 찾아 줘.
4. 요구사항을 증명하지 못하는 테스트를 표시해 줘.
5. 보안·성능·데이터·라이선스 위험을 분리해 줘.
6. 작성자에게 물을 확인 질문을 만들어 줘.
확신이 낮은 지적에는 확인 명령이나 재현 방법을 붙이고, 확인되지 않은 사실은 단정하지 마.

AI의 요약도 원본 diff를 대신하지 않습니다. 존재하지 않는 호출 관계를 만들거나 위험도를 잘못 판단할 수 있으므로, 리뷰 지도는 사람이 읽을 순서를 정하는 보조 자료로 사용합니다.

오늘 바로 해 보는 20분 연습

최근 리뷰했거나 직접 만든 PR 하나를 고릅니다.

1. 목적과 비목표를 각각 한 문장으로 씁니다.
2. 변경 파일을 고위험·중위험·저위험으로 나눕니다.
3. 목적과 연결되지 않는 파일을 표시합니다.
4. 새 의존성의 버전과 출처 확인 위치를 적습니다.
5. 이번 요구사항을 직접 증명하는 테스트 하나를 찾습니다.
6. 확신이 낮은 우려 하나를 재현 가능한 질문으로 바꿉니다.

20분 뒤 남아야 할 것은 “코드를 많이 읽었다”는 느낌이 아닙니다. 무엇을 바꾸는 PR인지, 어디가 위험한지, 어떤 증거가 부족한지 설명할 수 있는 리뷰 지도입니다.

다음 글에서는 복잡한 문제를 팀 리더에게 보고할 때 긴 AI 대화 기록 대신, 관찰·가설·증거·위험·요청의 다섯 문장으로 압축하는 방법을 다루겠습니다.

이번 글의 한 문장
AI가 만든 큰 PR은 줄 수대로 읽는 것이 아니라, 목적과 비목표를 고정하고 실패 비용이 큰 변경부터 증거와 함께 검토해야 한다.