AI가 코드를 만든다. 또 다른 AI가 그 코드를 리뷰한다.

이제는 낯선 풍경이 아니다. 큰 PR이 올라오고, AI 리뷰어가 수십 개의 코멘트를 남긴다. 작성자는 코드를 직접 한 줄씩 작성하지 않았고, 리뷰어도 전체 변경을 끝까지 읽기 어렵다. AI는 그럴듯한 요약과 수정 제안을 남긴다.

그런데 누군가 묻는다.

왜 이 구조를 선택했나요?

이 변경으로 기존 동작 중 무엇이 달라지나요?

운영에서 실패하면 어떤 데이터와 사용자가 영향을 받나요?

이 테스트가 통과했다는 것이 왜 안전하다는 뜻인가요?

그 질문에 제대로 답할 수 있는 사람이 없다면, 우리는 코드리뷰를 한 것이 아니다. AI의 출력을 서로 확인하는 의식을 치른 것이다.

문제가 생겼을 때 가장 위험한 말은 “AI가 작성한 코드입니다”가 아니다. “내가 작성한 코드가 아닙니다”라는 말이다.

코드리뷰의 병목은 사람이 느려서만 생기지 않는다#

반론은 분명하다. AI가 만드는 코드의 양을 사람이 전부 줄 단위로 읽는 방식은 오래가지 못한다.

실제로 기존 코드리뷰 연구도 사람이 모든 심각한 버그를 찾아낸다고 말하지 않는다. 실제 리뷰 변경의 다수는 큰 기능 결함보다 유지보수성, 가독성, 구조, 문서화 같은 진화 가능성에 관한 것이었다.[8] 변경량이 커질수록 코멘트 밀도는 낮아졌고, 코드리뷰의 효율은 리뷰 크기와 밀접하게 연결됐다.[7]

AI는 이 병목에 분명한 도움을 준다. 반복되는 규칙 위반, 타입 오류, 취약한 의존성, 테스트 누락 후보, 변경 파일의 영향 범위, 코드베이스 규칙 위반 후보를 사람보다 빠르게 찾아낼 수 있다. 실제 AI 코드리뷰 연구도 기능 오류 탐지에는 상대적으로 가능성을 보였고, 여러 독립 리뷰를 취합해 잡음을 거르는 방식은 성능을 개선했다.[4]

그러니 이 글은 “AI 리뷰를 쓰지 말자”는 글이 아니다. 인간이 모든 diff를 읽고 승인해야 한다는 주장도 아니다.

문제는 AI가 생성 속도를 올리는 만큼, 팀의 이해와 검증과 책임까지 자동으로 늘어난다고 믿는 데 있다.

AI 리뷰가 남기는 것은 코멘트이고, 코드리뷰가 남겨야 하는 것은 책임이다#

AI 리뷰만으로 운영되는 구조가 아직 사람 리뷰를 대체했다고 보기 어려운 근거는 있다.

2026년 코드리뷰 에이전트 연구는 AIDev 데이터셋의 3,109개 PR을 분석했다. AI 리뷰어만 참여한 PR의 병합률은 45.20%였고, 사람 리뷰어만 참여한 PR의 병합률은 68.37%였다. AI 리뷰 전용 PR은 더 높은 폐기율도 보였다.[1]

이 수치만으로 AI가 병합 실패를 일으킨다고 말할 수는 없다. 더 어려운 변경에 AI 리뷰만 달렸을 가능성도 있다. 하지만 적어도 “AI가 리뷰했으니 사람 리뷰를 뺄 수 있다”는 결론을 지지하지는 않는다.

더 중요한 건 피드백의 질이다. 이 연구에서 폐기된 AI 리뷰 전용 PR의 60.2%는 유의미한 피드백 비율이 30% 이하였고, 조사한 13개 AI 리뷰어 중 12개가 평균 신호 비율 60% 미만이었다.[1]

AI가 코멘트를 많이 남기는 것과, 팀이 더 안전한 판단을 하는 것은 다른 일이다.

LLM 기반 코드리뷰의 어려움은 단지 모델이 코드를 못 읽어서가 아니다. 실제 PR 리뷰에는 diff 바깥의 정보가 필요하다. 전체 저장소의 구조, 과거의 설계 결정, 테스트가 표현하지 못한 운영 제약, 팀이 지키기로 합의한 원칙, 고객에게 약속한 동작 같은 정보다.

실제 PR 1,000개와 전체 프로젝트 맥락을 활용한 SWR-Bench 연구는 현재의 AI 리뷰 도구가 현실적인 코드리뷰 환경에서 충분한 성능에 이르지 못했다고 평가했다. 상위 조합도 낮은 정밀도, 즉 많은 false positive가 문제였고, 그 검증 비용은 결국 사람에게 돌아간다.[4]

AI가 “이 코드는 null 가능성이 있습니다”라고 말할 수는 있다. 하지만 “이 값이 null이어도 되는 이유가 이전 버전 앱과의 호환성 때문인가”, “이 변경이 다음 주 프로모션 트래픽에서 어떤 비용을 만들 것인가”는 코드 조각만 보고 판단하기 어렵다.

더 위험한 것은 AI가 놓치는 문제보다, 사람이 더 이상 찾지 않는 문제다#

AI 리뷰를 먼저 보여주면 사람은 그것을 참고해서 더 잘 리뷰할 것처럼 보인다. 그러나 자동 리뷰가 리뷰어의 시선을 좁힐 위험도 있다.

전문 개발자 29명을 대상으로 한 통제 실험에서, 자동 코드리뷰를 먼저 받은 리뷰어는 AI가 지목한 코드 위치에 집중하는 경향을 보였다. 자동 리뷰는 저심각도 문제를 더 많이 발견하게 했지만, 고심각도 문제를 더 많이 찾게 하지는 못했다. 리뷰 시간도 절약되지 않았다.[14]

이 결과가 말하는 것은 AI 리뷰가 쓸모없다는 뜻이 아니다. AI가 리뷰의 출발점이 될 때, 사람의 리뷰가 AI가 정한 범위 안으로 줄어들 수 있다는 뜻이다.

이 변화는 조용히 일어난다.

  • 작성자는 AI가 만든 코드를 충분히 이해하지 못한다.
  • 리뷰어는 AI가 남긴 코멘트를 처리하는 데 시간을 쓴다.
  • AI가 언급하지 않은 설계, 데이터, 운영, 고객 영향 문제는 검토 대상에서 밀린다.
  • 결과적으로 아무도 전체 변경의 의미를 소유하지 않는다.

그래서 AI 시대의 코드리뷰에서 더 중요한 질문은 “AI가 버그를 몇 개 잡았는가”가 아니다.

이 변경을 왜 하는지, 무엇이 달라지는지, 실패하면 누가 어떻게 복구할지를 아는 사람이 있는가?

이다.

동료 리뷰가 만들던 것은 버그 탐지보다 공동 소유권이었다#

코드리뷰는 기술적 절차이면서 동시에 사회적 절차다.

코드 품질에 대한 책임성을 연구한 논문은 전통적 동료 리뷰에서 개인의 책임이 집단적 책임으로 확장된다고 설명한다. 작성자는 동료에게 자신의 결정을 설명해야 하고, 리뷰어는 그 판단에 질문하고 참여한다. 개인의 품질 기준, 프로로서의 성실성, 좋은 코드를 만들고자 하는 자부심, 팀 안에서의 평판이 이 책임을 떠받친다.[2]

그 연구는 LLM 기반 리뷰가 이 상호 책임 구조를 약화시킬 수 있다고 지적한다. 사람 동료에게는 나중에 설명해야 하지만, LLM에게는 설명을 요구받지 않는다. LLM은 장애가 났을 때 호출되지 않고, 운영 중인 고객을 위해 복구를 결정하지도 않는다.[2]

그래서 “AI가 리뷰했다”는 문장은 품질 보증의 문장이 아니다. 책임의 주체가 없는 경우에는 오히려 책임을 흐리는 문장이 될 수 있다.

이 문제는 AI가 나쁘기 때문이 아니다. 팀이 AI를 추가하면서 기존의 책임 구조를 대체할 설계를 하지 않았기 때문이다.

프로라면 미래의 모델을 믿기 전에 현재의 회사를 지켜야 한다#

AI가 더 좋아질 가능성은 높다. 언젠가 인간이 모든 구현 코드를 읽지 않아도 되는 범위는 분명히 넓어질 것이다.

실제로 인간 코드리뷰의 종말을 주장하는 견해도 있다. AI 에이전트가 결함 탐지, 스타일, 지식 전달, 팀 인식이라는 코드리뷰의 목표를 더 싸고 빠르게 수행할 수 있으며, AI가 작성한 코드를 다시 인간이 필수적으로 읽는 구조는 확장 불가능하다는 주장이다.[10]

이 주장을 가볍게 넘길 필요는 없다. 사람 리뷰도 완벽하지 않고, AI가 생성하는 코드량을 과거 방식 그대로 감당할 수는 없다.

하지만 아직 오지 않은 완전 자동화의 미래를 전제로, 오늘의 품질과 책임을 포기하는 것은 다른 문제다.

METR이 2025년 숙련 오픈소스 개발자 16명에게 실제 작업 246개를 수행하게 한 무작위 통제 실험에서는, AI 사용 허용 조건의 작업이 평균 19% 더 오래 걸렸다. 참가자들은 AI가 자신을 더 빠르게 만들었다고 믿었지만, 실제 측정은 달랐다.[5]

이 결과가 AI가 개발자를 항상 느리게 만든다는 뜻은 아니다. METR도 모든 업무와 모든 팀에 일반화할 수 없다고 명시한다.[5] 다른 연구에서는 AI 지원으로 초기 구현 시간을 줄였고, 후속 개발자가 해당 코드를 발전시킬 때 품질이나 시간의 뚜렷한 불이익을 찾지 못하기도 했다.[6]

그러므로 결론은 “AI는 아직 못 믿는다”가 아니다.

AI가 이미 충분히 믿을 만한 영역과, 아직 사람이 책임져야 하는 영역을 구분하지 않는 팀이 위험하다.

돈을 받고 일하는 프로라면, 언젠가 저렴하고 완벽한 모델이 올 수 있다는 기대만으로 회사의 현재 품질 프로세스를 비울 수 없다. 프로의 책임은 모델의 미래 성능을 예측하는 데 있지 않다. 지금의 시스템이 장애가 나도 설명되고, 복구되고, 다시 개선될 수 있게 만드는 데 있다.

AI 시대에 리뷰어가 봐야 할 것은 모든 줄이 아니다#

AI 시대의 해답은 사람에게 더 많은 diff를 읽게 하는 것이 아니다.

반복 가능하고 기계적으로 검증할 수 있는 일은 최대한 코드와 자동화에 맡겨야 한다.

  • lint, format, 타입 검사
  • 빌드와 테스트
  • 취약한 의존성, 시크릿, 라이선스 검사
  • 정적 분석
  • 변경 파일과 의존성 영향 범위 탐색
  • 코드베이스 규칙 위반 후보 탐지
  • 대규모 diff의 기능 단위 분해와 요약

이런 작업에서 AI는 사람이 놓치기 쉬운 후보를 빠르게 넓혀주는 좋은 도구가 될 수 있다.

그러나 다음은 누군가가 자기 이름으로 책임져야 한다.

  • 왜 지금 이 변경이 필요한가
  • 기존 동작 중 무엇이 달라지는가
  • 사용자, 데이터, 운영, 비용에는 어떤 영향이 있는가
  • 테스트가 통과해도 남는 위험은 무엇인가
  • 실패하면 어떻게 감지하고 되돌릴 것인가
  • 누가 이 위험을 이해하고 승인했는가

그래서 AI 시대의 PR에는 코드 diff보다 먼저 변경 책임 패킷이 있어야 한다.

  1. 변경 이유 — 해결하려는 문제는 무엇인가
  2. 정확한 변경 내용 — 무엇을 추가·수정·삭제하는가
  3. 영향 범위 — 사용자, 데이터, API, 운영, 비용에 미치는 영향은 무엇인가
  4. 기존 동작과의 차이 — 무엇이 달라지고, 호환성은 어떻게 달라지는가
  5. 검증 근거 — 어떤 테스트, 로그, 실행 결과, 실행계획으로 확인했는가
  6. 위험과 롤백 계획 — 실패하면 어떻게 감지하고 되돌리는가
  7. 승인 주체 — 누가 이 판단을 이해하고 승인했는가

이 문서는 형식적인 PR 템플릿이 아니다. AI가 코드 생산량을 늘릴수록 팀이 잃기 쉬운 이해와 책임을 되돌려놓는 장치다.

마치며#

AI가 코드를 쓰고 AI가 리뷰할 수 있다. 앞으로 그 비중은 더 커질 것이다.

하지만 장애가 난 뒤에 “AI가 그렇게 제안했습니다”라고 말하는 것으로는 고객도, 동료도, 회사도 복구할 수 없다.

AI 시대의 코드리뷰는 인간이 모든 줄을 읽는 절차로 남을 수 없다. 대신 더 분명해져야 한다. AI는 탐색하고, 검사하고, 요약하고, 제안할 수 있다. 사람은 변경의 의도와 영향, 위험과 복구, 최종 책임을 가진다.

프로는 AI가 만든 코드를 무조건 의심하는 사람이 아니다.

AI가 더 좋아져도 회사가 지속 가능한 품질을 유지하도록, 무엇을 자동화하고 무엇을 사람이 책임질지 설계하는 사람이다.

Sources#

[1] https://dl.acm.org/doi/full/10.1145/3793302.3793614 [2] https://arxiv.org/html/2502.15963v1 [4] https://arxiv.org/html/2509.01494v1 [5] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study [6] https://arxiv.org/abs/2507.00788v2 [7] https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/iet-sen.2020.0134 [8] https://pmc.ncbi.nlm.nih.gov/articles/PMC9489594 [10] https://arxiv.org/html/2606.13175v1 [14] https://arxiv.org/html/2411.11401v1