--- title: '코드 리뷰는 어렵다. 사람에게도, AI에게도' tags: - code-review - software-engineering - essay - ai - career published: true date: 2026-11-10 19:38:00 description: '코드 리뷰는 여전히 어려워' art: undraw: unread-messages --- ## Table of Contents ## 읽히지 않는 코멘트 6월에 쓴 [글](/2026/06/do-you-need-to-read-code)에서 나는 리뷰 에이전트를 만들고 있다고 적었다. 8주 안에 효과를 수치로 입증하지 못하면 내리겠다는 기준도 함께 적었다. 그 뒤로 8주가 지났지만 나는 수치를 계산하지 않았고, 봇도 내리지 않았다. 봇은 PR에 코멘트를 계속 남겼고, 사람들은 그런가 보다 하고 넘어갔다. 그런 일이 반복되자 코멘트를 읽지 않게 됐다. 봇을 개선하려고 받은 설문에서도 의미 있는 답은 나오지 않았다. 나는 이런 도구를 대여섯 개쯤 만들거나 시도했고, 대부분 성공하지 못했다. 코드 리뷰는 어려운 일이고 그래서 기계에 맡기고 싶었는데, 맡겨 보니 아무도 읽지 않는 코멘트가 늘어났다. ## 코드 리뷰가 어려웠던 이유 처음 코드 리뷰가 어려웠던 이유는 코드가 복잡해서만은 아니었다. 내가 잘 모른다는 사실을 들킬 것 같았고, 적당히 이해하고 넘어간 부분을 누군가 발견할까 봐 불안했다. 코드 리뷰는 코드를 평가받는 일이면서, 내가 얼마나 알고 있는지 드러나는 일이기도 했다. 시니어가 되고 나서는 주니어들에게 다양한 방식으로 코드를 써 보고, 새로운 라이브러리도 써 보라고 권했다. 그런데 리더가 되어 그 코드를 직접 리뷰해야 하는 입장이 되니 다른 어려움이 생겼다. 내가 아는 것만으로는 리뷰할 수 없었다. 새로 나온 라이브러리와 API, 낯선 구현 방식까지 이해해야 했고, 주니어에게 무언가 가르쳐 줘야 한다는 압박도 있었다. 주니어일 때는 모르는 것을 들킬까 봐 어려웠고, 리더가 된 뒤에는 모르는 것까지 이해하고 설명해야 해서 어려웠다. 입장은 바뀌었는데 어렵다는 사실은 변하지 않았다. 나중에 찾아보니 이런 불안이 나만의 것은 아니었다. Microsoft의 Code Reviews Do Not Find Bugs는 코드 리뷰의 사회적인 면을 무시할 수 없다고 적었다[^1]. 팀에서의 역할과 위계가 리뷰 결과에 영향을 주고, 작성자뿐 아니라 리뷰어도 평가받는 입장이 되는 경우가 많다는 것이다. 코멘트를 남기는 사람도 자기 수준을 드러내고 있으니, 리더가 되어서도 리뷰가 편해지지 않은 이유가 조금 설명되는 것 같았다. 낯선 코드를 리뷰하는 어려움은 수치로도 나온다. 같은 글에 따르면 리뷰어가 해당 코드를 처음 볼 때 작성자가 유용하다고 판단한 코멘트는 평균 33%였고, 같은 코드를 세 번째 리뷰할 때는 약 67%로 올라갔다. 변경 파일이 20개 이상이 되면 유용한 피드백의 비율이 눈에 띄게 떨어지기 시작했다[^1]. 낯선 코드를 리뷰하던 때의 감각과 맞는 수치다. 리뷰어의 주의력에는 한계가 있고, 그 한계는 코드가 낯설수록 빨리 온다. ## 주의력을 배분한 네 가지 방법 그래도 코드 리뷰를 포기하지는 않았다. 대신 한정된 주의력을 어디에 쓸지를 고민했고, 크게 네 가지 방법을 썼다. **첫째, 반복되는 검증은 장치로 옮겼다.** 이 글에서 장치는 린트처럼 통과 아니면 실패로 끝나는 자동 검사를 뜻한다. 계층 간 의존성 규칙은 ESLint [`no-restricted-imports`](https://eslint.org/docs/latest/rules/no-restricted-imports)로 막았다. [린트와 계약 테스트로 분기를 관리한 사례](/2026/09/one-web-on-multiple-webviews)와 [라이브러리 추가가 번들에 미치는 영향을 PR에 드러내는 방법](/2026/05/pr-diff-vs-bundle)은 다른 글에 적었다. 모든 코드에 사람의 관심을 똑같이 쏟을 필요는 없다는 판단에서 출발한 일이다. 사람이 지적해서 유지하기 어려운 규칙도 있다. Eclipse 코드 리뷰 요청 16,442건을 분석한 연구에서는 컨벤션 위반이 사라진 리뷰 요청 1,268건을 직접 살펴봤는데, 리뷰 코멘트로 지적돼서 사라진 경우는 소수였다[^2]. 사람이 리뷰에서 같은 말을 반복하고 있다면 그 말은 규칙으로 옮길 후보가 된다. 예전에는 커스텀 규칙을 만드는 비용이 커서 망설였지만, [지금은 AI에게 규칙 작성을 맡길 수 있다](/2026/02/frontend-engineering-in-ai-era). **둘째, 정말 중요한 PR은 직접 알려 달라고 했다.** 확신이 없는 구현이나 설계 동의가 필요한 변경은 미리 설명하고 시간을 내어 봐 달라고 했다. 모든 PR의 중요도가 같지는 않았기 때문이다. **셋째, 핵심 영역에는 필수 리뷰를 요구했다.** 결제처럼 제품에서 중요한 모듈은 그 영역을 잘 아는 사람 한 명 이상의 리뷰와 동의를 받게 했다. 코드에 오류가 없는지만 보려는 것은 아니었다. 제품의 위험을 이해하는 사람이 변경을 보고 동의했는지가 중요했다. **넷째, 테스트 코드도 리뷰했다.** 테스트가 전부 통과해도 테스트 자체가 잘못된 요구사항을 검증하고 있을 수 있다. AI가 구현과 테스트를 함께 쓰는 지금은 자기가 낸 답안으로 자기를 채점하는 [순환 검증](/2026/06/do-you-need-to-read-code)이 되기 쉬워서 더 중요해졌다고 생각한다. 돌아보면 네 가지 모두 무엇을 기계에 맡기고 무엇을 사람에게 남길지를 정하는 일이었다. 장치의 장점은 사람의 주의력을 거의 쓰지 않는다는 데 있다. 린트는 통과하거나 실패할 뿐이고, 통과하면 아무도 들여다볼 필요가 없다. Google의 SRE 책은 온콜 호출의 기준을 "모든 호출은 조치할 수 있어야 한다"고 적었고, 기계적인 대응만 필요한 일이라면 사람을 호출하면 안 된다고 했다[^3]. 코드 리뷰와는 다른 분야의 이야기지만, 사람의 주의력을 쓸 만한 일인지 먼저 따진다는 점은 같다. 그런데 장치에는 분명한 한계가 있다. 통과와 실패로 판정할 수 있는 것만 볼 수 있다. 이 설계가 맞는지, 이 코드가 기획 의도에 맞는지는 린트가 알려 주지 않는다. 사람이 봐야 하는 영역은 그대로 남았고, 코드는 계속 늘어났다. ## 측정하지 않은 8주 Claude Code나 GitHub Copilot 같은 AI 코딩 도구가 나오면서 자동화의 대상은 코드 작성에서 리뷰로 넓어졌다. 코드를 쓰는 속도가 빨라지면 읽어야 할 코드도 늘어난다. Faros AI는 AI 도입률이 높은 팀에서 PR 리뷰 시간이 91% 늘었다고 보고했는데[^4], 리뷰가 쏟아진다는 감각과 맞는 이야기였다. 나도 LLM으로 리뷰하는 도구를 여러 번 시도했다. 처음 만든 것은 결과를 내 개인 대시보드에 모아 보여 주는 방식이었다. 대시보드에 나온 지적은 내가 보고 PR에 다시 달아야 했고, 그게 번거로웠다. 그래서 봇이 PR에 직접 코멘트를 남기게 바꿨다. 처음에는 사람들이 관심을 보였다. 봇이 어떤 문제를 찾았는지 확인하고 코멘트도 읽었다. 앞에서 말한 리뷰 에이전트가 그중 하나다. 6월 글에 쓴 문장은 이랬다. > 내가 만들고 있는 리뷰 에이전트에도 8주짜리 판정 기준을 걸어뒀다. 효과를 수치로 입증하지 못하면 내린다. 같은 글에 인간 리뷰어와의 일치율과 오탐률을 재야 한다고도 적었다. 8주 동안 수치를 계산하지 않은 것은 깜빡했기 때문이다. 남은 것은 일부는 쓸 만했고 일부는 좋지 않았다는 인상이었고, 입증하지 못했는데도 내리지 않았다. 대신 PR 게이트(통과해야 머지할 수 있는 필수 검사)로는 쓰지 않고 보조 도구로만 쓰기로 정했다. 깜빡한 것은 변명의 여지가 없다. 조금 민망한 대목도 있다. 나는 올해 10월에 코딩 모델을 비교하려고 [사내 PR로 문항 36개를 만들고](/2026/10/in-house-swe-bench-from-merged-prs) 모델을 [1,164번 실행했다](/2026/10/model-swap-experiment-retrospective). 그 실험은 무엇을 셀지가 분명했다. 정해 둔 테스트를 통과했는지로 해결 여부를 채점했다. 반면 여러 종류의 문제를 찾는 리뷰봇에서는 무엇을 유용한 지적으로 볼지부터 정해야 했다. ### 서로 다른 것을 재는 지표 당시 내가 적어 둔 일치율은 사람의 리뷰를 정답으로 삼는 지표다. 그런데 사람의 리뷰도 정답이 아니다. 앞에서 본 것처럼 같은 사람도 코드에 익숙해지기 전과 후의 코멘트 품질이 다르다. 오탐률도 마찬가지다. 틀린 지적만 오탐으로 칠지, 맞지만 아무도 신경 쓰지 않는 지적까지 포함할지에 따라 값이 크게 달라진다. 공개된 수치를 모아 보면 다들 다른 것을 재고 있다. | 출처 | 잰 것 | AI 코멘트 | 사람 코멘트 | | -------------------------------------------------- | ---------------------------------- | ------------------------------- | ----------- | | Mozilla와 Ubisoft[^5] (2024) | 리뷰어가 수용한 비율 | 8.1%, 7.2% | 없음 | | GitHub Actions 도구[^6] (16종 조사, 4종 상세 분석) | 코멘트가 코드 변경으로 이어진 비율 | 0.9%에서 19.2% | 60% | | Atlassian[^7] (2026, 자사 평가) | 코멘트가 코드 해결로 이어진 비율 | 38.7% | 44.5% | | Google[^8] (2024, 자사 평가) | 피드백이 달린 코멘트 중 긍정 비율 | 54%, 필터 적용 후 재집계 시 66% | 없음 | 표의 숫자는 서로 비교할 수 없다. 분자도 분모도 다르다. 코드가 바뀌지 않았다고 코멘트가 쓸모없었던 것도 아니고, 바뀌었다고 코멘트 덕분이라는 보장도 없다. 사람 코멘트의 값조차 60%와 44.5%로 다르다. Google도 같은 논문에서 정답 데이터가 불완전해 정밀도와 재현율 측정값에 노이즈가 많다고 적었다. 제품을 만드는 회사들도 대리 지표를 쓴다. Cursor는 지적한 버그가 최종 코드에서 해결됐는지를 AI로 판정하는 해결률을 만든 뒤에야 감이 아니라 신호를 보고 개선할 수 있었다고 적었다[^9]. Anthropic은 지적의 1% 미만이 틀렸다고 표시된다고 밝혔는데[^10], 이것은 개발자가 표시한 비율이고 표시하지 않은 코멘트까지 확인한 정밀도와는 다른 값이다. 내가 공개한 실험에서도 비슷한 일이 있었다. [number-flow의 빌드 여섯 개를 익명으로 리뷰시켰을 때](/2026/11/number-flow-blind-agents) 같은 빌드 하나가 세 평가자에게 50점, 65점, 76점을 받았다. 평가 기준을 미리 적어 줘도 이 정도로 벌어졌다. 그래서 그때는 점수보다 어느 코드에서 같은 문제가 반복해서 나왔는지를 봤다. 사람에게 직접 물어보는 방법도 잘 통하지 않는다. Atlassian은 코멘트마다 좋아요와 싫어요 버튼을 달았는데, 엔지니어들이 버튼을 거의 누르지 않았다고 보고했다. 내 설문에서 의미 있는 답이 나오지 않은 것도 비슷한 이유일 것이다. 이미 읽지 않게 된 코멘트를 어떻게 고치면 좋겠느냐는 질문에는 답할 말이 별로 없다. 평가할 데이터와 절차가 없으면 결국 체감과 불만에 기대어 도구를 고치게 되는데, 내가 그랬다. ## 코멘트가 무시된 이유 보조 도구로 정한 뒤에도 코멘트는 계속 달렸고, 사람들은 그런가 보다 하고 넘어갔다. ### 맞지만 사소한 지적 처음에는 틀린 지적이 쌓여 신뢰를 잃었다고 생각했다. 실제로 봇이 맥락에 맞지 않는 코멘트를 몇 번 남긴 뒤부터 사람들은 코멘트를 보지 않기 시작했다. 리뷰에는 Qwen 같은 저렴한 오픈웨이트 모델을 썼는데 답이 썩 정확하지 않았다. 이런 모델들은 [코딩 모델을 비교한 실험](/2026/10/claude-code-model-swap-results)에서도 한두 파일을 고치는 문항은 비슷하게 풀었지만 그보다 큰 문항에서는 차이가 났다. 이미 처리된 케이스를 문제 삼거나, 어디에나 붙일 수 있는 일반론을 남기는 일이 반복되면 봇을 믿기 어렵다. 그러면 봇이 실제 버그를 짚는 순간에도 아무도 읽지 않을 수 있다. 린트 경고나 모니터링 알림에서 흔히 보는 경고 피로(alert fatigue)와 같은 현상이다. 그런데 틀린 지적만 무시된 것은 아니었다. 봇은 코멘트를 사소한 지적과 주요 지적으로 나눠 달았는데, 사소한 지적은 시간이 없어서 넘어가는 경우가 많았다. "그런가 보다"는 틀린 말에 대한 반응으로는 조금 이상하다. 틀렸다면 짜증을 내거나 반박할 텐데, 맞을 수도 있지만 내가 움직일 이유는 없다는 뜻에 더 가까워 보인다. AI 리뷰 도구를 만드는 Greptile이 자사 코멘트를 분석한 글이 이 감각을 잘 보여 준다[^11]. 좋은 코멘트는 약 19%, 틀린 코멘트는 2%였고, 나머지 79%는 기술적으로 맞지만 개발자가 신경 쓰지 않는 사소한 지적(nit)이었다고 한다. 줄이는 일도 쉽지 않았던 모양이다. 프롬프트로 사소한 지적을 줄이면 중요한 코멘트도 함께 줄었고, LLM에게 심각도를 매기게 한 필터도 실패했다. 팀별로 개발자가 반응한 코멘트를 임베딩으로 모아 비슷한 코멘트를 걸러 내고 나서야, 머지 전에 반영되는 코멘트의 비율이 19%에서 55% 이상으로 올랐다고 적었다. 사소함의 기준이 팀마다 달라서 팀별로 배워야 했던 것이다. 나는 이 대목에서 생각이 바뀌었다. 정확도를 높이면 해결될 줄 알았던 문제가 정확도만의 문제는 아니었다. 맞는 말을 하는 것과 사람이 움직일 만한 문제를 고르는 것은 다른 일이다. ### diff 밖의 맥락 사소한 지적이 많은 데에는 맥락이 부족한 탓도 있을 것이다. 내 봇이 읽은 것은 PR의 diff와 저장소에 적어 둔 지침 파일(`CLAUDE.md`)이었다. diff만으로는 변경된 코드의 역할과 주변 시스템의 동작을 알기 어렵고, 저장소 전체를 넘기면 토큰 비용과 불필요한 정보가 늘어난다. 필요한 맥락만 정확하게 모으는 것 자체가 어려운 엔지니어링 문제다. 프론트엔드에서는 렌더링 결과와 사용자 상호작용, 접근성, 성능을 코드만 봐서는 확인하기 어렵다. 백엔드에서는 동시성과 트랜잭션, 데이터 정합성처럼 실행 맥락이 중요하다. 예를 들어 어떤 값이 호출부에서 이미 검증됐다면 diff에 보이는 함수 안의 null 지적은 맞는 말이면서 쓸모없는 말이 된다. 사람은 그 함수가 어디서 불리는지 알기 때문에 지나치지만, diff만 본 봇은 지적할 수밖에 없다. 더 어려운 것은 문서화되지 않은 규칙이다. 서비스마다 과거의 의사결정과 장애 이력, 암묵적인 제약이 있고, 그런 지식은 코드에도 문서에도 다 남아 있지 않다. 이상해 보이는 코드가 사실은 예전 장애를 막으려고 들어간 것일 수 있다. 이것을 봇에게 알려 주려면 평소에 적지 않던 것을 봇을 위해 적어야 한다. ### 응답하지 않아도 되는 코멘트 정밀도만으로 설명되지 않는 사례는 AI 이전에도 있었다. Facebook의 정적 분석 도구 Infer는 야간 분석 결과를 담당자에게 배정했을 때 수정률이 거의 0이었는데, 같은 오탐률로 코드 리뷰 시점에 봇으로 붙이자 70%를 넘었다[^12]. 다만 내 봇도 PR에 코멘트를 남겼으니 시점은 같았다. 주요 지적으로 분류된 코멘트 가운데에는 맞는 것도 있었다. 그런데 맞는 지적이어도 작성자가 직접 고치는 일은 드물었다. 내가 의심하는 것은 코멘트에 응답할 이유다. Google의 코드 리뷰에서 미해결 코멘트는 작성자가 반드시 처리해야 할 항목이고, 코멘트가 처리된 뒤에 승인이 이뤄진다[^13]. 답을 기다리는 리뷰어가 있는 코멘트에는 대답이 필요하다. 내 봇의 코멘트에는 강제성이 없었다. 게이트가 아니어서 무시해도 머지에 영향이 없었다. 보조 도구로 두는 결정은 안전해 보였지만, 코멘트의 무게도 함께 낮췄을지 모른다. Google의 정적 분석 플랫폼 Tricorder 논문은 사용자가 조치하지 않기로 한 보고를 모두 effective false positive로 센다[^14]. 맞는 지적이어도 아무도 움직이지 않으면 도구의 실패로 보는 정의다. 이 정의로 보면 내 봇의 코멘트는 맞았더라도 실패한 것이다. 응답할 이유가 원인이라는 것은 추측이다. 머지를 막는 코멘트와 막지 않는 코멘트의 조치율을 직접 비교한 연구는 찾지 못했고, 앞의 표에서 보듯 Atlassian처럼 봇의 코멘트가 사람에 가깝게 반영된 곳도 있다. ### 범위와 확인 기준을 정해 의뢰한 경우 범위와 확인 기준을 정해 직접 의뢰한 작업에서는 쓸 만한 결과를 얻었다. [markdownlint를 Rust로 옮긴 프로젝트](/2026/09/porting-markdownlint-cli2-to-rust)에서는 Codex에게 원본 도구를 함께 주고 이렇게 지시했다. 코드를 읽고 위험해 보인다고 말하는 것은 발견이 아니다. 실제로 두 도구를 돌려 출력이 다른 것만 발견이다. 약 1,600회의 대조 실행 끝에 발견 11건이 나왔고, 그중에는 `--fix`가 조용히 파일을 다르게 바꾸는 문제도 있었다. [number-flow](/2026/11/number-flow-blind-agents)에서도 에이전트의 리뷰와 재현을 거쳐 내 포크의 결함을 이슈로 남겼다. 두 경우는 PR에 자동으로 달리는 봇과 여러 조건이 함께 달랐다. 내가 필요해서 의뢰했고, 확인할 범위와 근거를 정했으며, 결과도 내가 받았다. 특히 Rust 포팅에서는 같은 입력에 대한 원본의 동작을 기준으로 삼을 수 있었다. 어느 조건이 얼마나 영향을 줬는지는 구분할 수 없지만, 적어도 나온 지적을 어떻게 확인하고 처리할지는 분명했다. 다만 둘 다 혼자 맡은 일회성 작업이었다. ### 말하지 않을 것을 고르는 일 공개된 제품들을 보면 방향은 비슷하다. GitHub은 침묵이 소음보다 낫다고 적었고, Copilot은 리뷰의 29%에서 아무 말도 하지 않는다고 밝혔다[^15]. 출시 당시 Cursor의 Bugbot은 diff 순서를 바꿔 8번 분석한 뒤 다수결로 걸러 내고, 검증 모델을 한 번 더 돌렸다. 그렇다고 코멘트가 줄어들기만 하는 것은 아니어서, Cursor의 실행당 지적 수는 0.4개에서 0.7개로 늘었다[^9]. 잘 걸러 낼 수 있어야 더 말할 수 있다는 이야기로 보인다. 코멘트를 만드는 일은 이미 쉬워졌고, 무엇을 말하지 않을지 정하는 일에 공이 들어가고 있다. 그래서 하나는 분명해 보인다. 린트는 통과와 실패로 끝나지만, 봇의 코멘트는 사람이 읽고 맞는지 판단해야 끝난다. 코멘트가 맞더라도 그 판단에는 주의력이 필요하다. 한정된 주의력을 아끼려고 장치를 만들어 왔는데, 내 봇은 그 주의력을 PR마다 다시 쓰고 있었다. 사람을 호출할 만한 일인지 먼저 따지는 기준을 내 봇에는 적용하지 않았던 것이다. ## 신뢰를 얻는 비용 이 문제를 풀려고 하면 봇은 점점 복잡해진다. 처음에는 모든 저장소를 보는 범용 봇을 구상한다. 프론트엔드, 백엔드, 데이터는 중요한 검증 지점이 다르니 영역별로 나눈다. 같은 프론트엔드여도 서비스마다 아키텍처와 핵심 로직이 다르니 서비스별로 다시 특화한다. 여기에 모델과 프롬프트 변경, 평가 데이터 유지, 운영 인력이 따라온다. 큰 회사의 공개 사례도 비슷해 보인다. Google은 코딩 규칙 위반을 지적하는 AutoCommenter의 유용 비율이 54%에서 정체되자 개발자 15명을 평가자로 모아 코멘트를 다시 평가했다. 조치하기 어려운 코멘트와 연결된 기준 문서 URL 17개를 찾아 해당 코멘트를 제외하니, 과거 개발자 피드백에서 다시 계산한 유용 비율이 66%가 됐다[^8]. Cursor는 Bugbot을 버전 11까지 올리면서 큰 실험을 40번 돌렸다[^9]. 코멘트를 만드는 일보다 코멘트를 솎아 내고 평가하는 일에 더 공이 드는 것처럼 보인다. 여기서 의문이 든다. 그만한 노력을 들일 바에는 린트와 정적 분석, 테스트, 필수 승인 같은 장치를 잘 갖추는 편이 더 경제적이지 않을까. 여러 도구를 만들면서 도달한 의문이다. 만들 것인가 살 것인가도 같은 비용의 문제다. 범용 리뷰라면 전담 조직이 있는 상용 도구가 유리할 가능성이 높다고 본다. 반면 코드 반출이 제한되거나 특정 서비스에 맞춘 검증이 필요하면 직접 만들 이유가 있다. 상용 도구의 범용 기능을 다시 만드는 일과 내부에서만 풀 수 있는 문제를 푸는 일은 구분해야 한다고 생각한다. 이 비용을 들여다보면 상당 부분이 다른 사람이 믿고 읽게 만드는 데 드는 비용이다. 평가 체계도, 오탐 관리도, 피드백 수집도 봇의 말을 남이 읽어 주기를 바라기 때문에 필요하다. 그 말이 틀렸을 때 잃는 것은 토큰이 아니라 동료의 시간과 봇에 대한 신뢰다. ## 주의력이 남기는 것 여기까지는 사람의 주의력을 얼마나 덜 쓰게 할지의 이야기였다. 그런데 주의력에는 쓰고 나면 남는 것이 없는 경우와 무언가 남는 경우가 있다. 사소한 코멘트가 맞는지 확인하는 데 쓴 시간은 그 판단이 끝나면 사라진다. 동료의 코드를 이해하고 설계 의도를 묻는 데 쓴 시간은 다음에 그 코드를 판단할 수 있는 사람을 만들 가능성이 있다. 이 구분은 사람과 봇을 가르지 않는다. 사람도 사소한 지적으로 동료의 시간을 쓸 수 있고, 봇의 설명이 코드를 이해하는 데 도움이 될 수도 있다. 문제는 한정된 주의력을 어디에 쓰고 무엇을 남기느냐다. 처음에는 모른다는 사실이 드러나는 것이 두려웠지만, 시간이 지나면서 리뷰가 평가 이상의 일이라는 것을 알게 됐다. 리뷰를 받는 사람도 배우고 남기는 사람도 배운다. 리뷰어가 잘못 이해한 부분을 설명해 주는 과정에서 리뷰어에게 지식이 쌓이고, 왜 그렇게 구현했는지 설명하면서 작성자도 자기 판단을 돌아본다. 코드 리뷰에는 장기적인 기대도 있었다. 지금 내 코드를 읽는 동료가 구현을 이해하면 언젠가 그 사람도 이 코드를 고칠 수 있다. 장애가 났을 때 내가 없어도 문제를 해결할 수 있다. 이런 경험이 쌓이면 그 코드를 맡을 수 있는 사람이 한 명 더 생길 가능성이 커진다. 연구에서도 지식 전달은 리뷰의 가치로 다뤄진다. Microsoft를 조사한 Bacchelli와 Bird의 연구에서는 코멘트 570개 중 외부 문서 등을 안내하며 학습을 돕는 코멘트 12개를 찾았고, 이를 지식 전달의 중요성을 뒷받침하는 추가 근거로 제시했다[^16]. 이 수치는 학습이 일어난 리뷰의 비율을 뜻하지 않는다. 코드를 읽고 질문하는 과정에서 무엇을 배웠는지는 코멘트 분류만으로 알기 어렵다. Rigby와 Bird의 연구는 리뷰를 포함하면 개발자가 아는 것으로 집계한 파일 수가 수정 이력만 셌을 때보다 프로젝트에 따라 66%에서 150% 더 많았다고 보고했다. 여기서 안다는 것은 수정했거나 리뷰한 적이 있다는 뜻이다[^17]. 앞에서 본 33%와 67%도 코드에 익숙해질수록 유용한 코멘트가 늘어난다는 간접 증거다. 다만 이런 기록으로 그 코드를 혼자 고치거나 장애를 해결할 수 있게 됐는지까지 확인할 수는 없다. 그러니 리뷰가 코드를 책임질 사람을 늘린다는 말은 측정된 사실이라기보다 내가 경험으로 믿는 것에 가깝다. 그래도 이 믿음을 내려놓기는 어렵다. ### 코드를 책임질 사람 AI가 사람보다 더 잘 설명하거나 더 많은 버그를 찾을 수는 있다. 하지만 AI에게 코드를 설명했다고 해서 조직 안에 그 코드를 책임질 동료가 한 명 더 생기지는 않는다. 사람이 잘못된 리뷰를 남기면 서로 이야기하며 다음 판단을 고칠 수 있지만, AI의 잘못된 리뷰를 고치는 일은 프롬프트나 평가 체계를 손보는 별도의 작업이 된다. 앞서 말한 정밀도 문제는 모델이 좋아지면 줄어들 수 있다. 다만 모델이 지적을 잘하게 되는 것과 이 코드를 아는 사람이 늘어나는 것은 다른 일이라고 생각한다. Atlassian은 RovoDev 코멘트가 달린 PR의 사이클 시간 중앙값이 그렇지 않은 PR보다 30.8% 짧았고, PR당 사람 코멘트는 35.6% 줄었다고 보고했다[^7]. 논문에서는 긍정적인 효과로 다룬 수치다. 리뷰어의 시간이 남았다는 뜻이겠지만, 사람끼리 오가던 설명도 함께 줄었을 수 있어서 나는 마음이 조금 복잡하다. 그렇게 남은 시간이 동료의 코드를 이해하는 데 다시 쓰였는지는 알 수 없다. 코드를 AI가 쓸 때는 사정이 더 어려워진다. 앞에서 적은 배움은 양쪽이 모두 사람이라는 전제에서 나온다. 작성자에게 왜 그렇게 구현했는지 물었을 때 [AI가 이렇게 만들었다는 답](/2026/02/frontend-engineering-in-ai-era)이 돌아오면, 설명하면서 자기 판단을 돌아보는 과정이 사라진다. 코드 리뷰의 가장 근본적인 질문은 이 코드를 실제 서비스에 내보내도 괜찮은가일 것이다. AI가 검토했다는 사실만으로 그 변경의 결과를 누가 책임지는지가 정해지지는 않는다. 배포를 결정하고, 문제가 생기면 해결하고, 이후에도 서비스를 관리할 사람은 여전히 필요하다. 그리고 그런 사람은 어느 날 갑자기 생기지 않는다. 다른 사람의 코드를 읽고, 설계의 배경을 배우고, 판단에 참여하면서 만들어진다. 이 이야기는 [다른 글](/2026/06/learning-what-ai-cant-do)에서 더 길게 다뤘다. ## 개인적인 절충 내 봇은 보조 도구로 두었을 때 잘 읽히지 않았다. 그렇다고 효과를 확인하지 못한 코멘트를 필수 검사로 만들기도 어려웠다. 그래서 동료에게 보내기 전에 내가 한 번 거르기로 했다. 지금 나는 특정 서비스에 맞춰 범위를 좁힌 봇을 내 리뷰에만 쓴다. 봇이 PR에 직접 코멘트를 남기지는 않는다. 동료에게 읽어 달라고 할 말을 내가 먼저 확인하는 개인적인 절충이다. 돌아보면 처음 만든 대시보드와 비슷한 방식으로 돌아온 셈이다. 그때는 내가 보고 다시 다는 과정이 번거로워서 없앴는데, 지금은 그 과정을 일부러 거친다. 순서는 정해 두었다. 내가 먼저 코드를 읽고 리뷰한다. 그다음 봇을 돌려 내 리뷰와 대조한다. 어긋나면 나도 다시 생각하고 봇에게도 다시 보게 한다[^18]. 어느 쪽에서 나온 지적이든 근거를 확인한 뒤 내 이름으로 코멘트를 남긴다. 일치했다는 이유만으로 맞다고 보지는 않는다. 둘이 같은 것을 놓치거나 함께 틀릴 수도 있기 때문이다[^19]. 리뷰어도 평가받는다는 앞의 이야기는 봇을 써도 달라지지 않는다. 동료에게 보낸 말이 틀렸을 때 설명해야 하는 사람은 나다. 근거를 확인하는 일은 앞서 언급한 [number-flow 실험](/2026/11/number-flow-blind-agents)에서도 필요했다. 구형 브라우저를 지원하려고 만든 내 포크 v0.2.1에 에이전트가 호환성 문제를 지적했다. `useCanAnimate` 훅이 일부 구형 브라우저에 없는 `MediaQueryList.addEventListener`를 대체 경로 없이 쓰고 있었다. 소스와 해당 API를 제거한 환경에서의 재현으로 결함을 확인했다. 구형 기기에서 직접 실행한 결과는 아니었지만, 내가 빠뜨린 호출 경로는 확인할 수 있었다. 이처럼 지적이 성립하는 조건과 확인한 범위를 설명할 수 있어야 한다고 생각한다. 이렇게 하면 틀린 지적은 내가 버리면 끝이고, 피드백 설문도 필요 없다. 동료가 받는 것은 사람의 코멘트이니 응답할 이유도 그대로 남고, 설명하고 배우는 대화도 사람끼리 이어진다. 잃는 것도 분명하다. 먼저 읽고, 봇을 돌리고, 대조하고, 어긋나면 다시 보는 일은 시간이 더 든다. 동료의 주의력을 아끼는 대신 내 주의력을 더 쓰는 방식이다. 내가 더 꼼꼼히 읽는다고 동료의 이해도 함께 늘어나는 것은 아니어서, 코드를 이해하는 사람이 나 한 명에게 몰릴 수도 있다. ### 팀에 붙이지 못한 이유 이 봇을 팀에 붙이지 못한 이유도 여기에 있다. 내가 틀린 지적을 얼마나 잘 걸러내는지 재 본 적이 없고, 먼저 읽고 대조하는 절차가 판단을 개선하는지도 확인하지 못했다. 내가 다시 생각한다는 단계가 처음 판단을 지키는 데 그칠 수도 있다[^20]. 혼자 쓰면서 도움이 된다는 인상만으로 다른 사람에게도 같은 절차를 권하기는 어렵다. AI 덕분에 더 많은 코드를 쓰고 더 많은 리뷰를 남길 수 있게 됐고, 나도 매일 그렇게 일한다. 기계로 판정할 수 있는 것은 장치로 옮기고, 남은 영역은 사람이 먼저 읽고 판단한 뒤 봇과 대조하는 편이 맞다고 지금은 생각한다. 다만 그 사이에 코드를 이해하는 사람도 함께 늘고 있는지는 여전히 잘 모르겠다. 주니어 때는 모르는 것을 들킬까 봐, 리더가 되어서는 설명하지 못할까 봐 어려웠는데, 지금은 동료의 주의를 해칠까 봐 망설이고 있다. 코드 리뷰는 여전히 어렵고, 그래서 아직 봇은 나에게만 말한다. [^1]: [Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down](https://microsoft.com/en-us/research/wp-content/uploads/2015/05/PID3556473.pdf) (ICSE 2015). 2쪽 발표 요지라서 방법론까지는 알 수 없다. [^2]: [Does code review really remove coding convention violations?](https://discovery.ucl.ac.uk/10110634/1/scam20.pdf) (SCAM 2020). 위반이 사라진 리뷰 요청만 살펴봤으므로, 지적됐지만 반영되지 않은 비율은 알 수 없다. [^3]: [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/), Site Reliability Engineering. 온콜 호출에 대한 원칙이고, 코드 리뷰에 적용한 것은 내 유추다. [^4]: [AI coding assistants increase developer output, but not company productivity](https://www.faros.ai/blog/ai-software-engineering) (2025). 1,255개 팀, 개발자 1만 명 이상의 데이터다. 분석 도구를 파는 회사의 자료이고 상관관계다. [^5]: [Impact of LLM-based Review Comment Generation in Practice: A Mixed Open-/Closed-source User Study](https://arxiv.org/abs/2411.07091) (2024). 패치 리뷰 587건 이상을 대상으로 했다. [^6]: [Does AI Code Review Lead to Code Changes? A Case Study of GitHub Actions](https://arxiv.org/abs/2508.18771v2) (2025년 공개, 2026년 개정). 도구 16종이 남긴 코멘트 2만 2천 개 이상을 저장소 178개에서 수집했다. 표의 반영률은 4종을 상세 분석한 Table IX의 값이다. 오픈소스 Action이 대상이라 최신 상용 도구에 그대로 적용하기는 어렵다. [^7]: [RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian](https://arxiv.org/abs/2601.01129) (2026). 원문 값은 38.70%와 44.45%이고, 2025년 7월의 일주일 구간 값이다. 관찰 연구라 인과를 말할 수 없고, 코멘트 해소가 머지 조건이었는지는 확인하지 못했다. [^8]: [AI-Assisted Assessment of Coding Practices in Modern Code Review](https://arxiv.org/abs/2405.13565) (2024). 54%와 66%는 개발자 피드백 기준으로, 과거 코멘트에서 특정 URL에 연결된 코멘트를 제외하기 전후의 비율이다. 평가자 기준으로 같은 재집계를 하면 60%와 74%다. 넓은 배포의 목표는 80%였다. [^9]: [Building a better Bugbot](https://cursor.com/blog/building-bugbot), Cursor (2026). 자사 수치이고, 해결률의 판정자는 LLM이다. [^10]: [Bringing Code Review to Claude Code](https://claude.com/blog/code-review), Anthropic (2026년 3월). 자사 수치다. [^11]: [How to Make LLMs Shut Up](https://www.greptile.com/blog/make-llms-shut-up), Greptile (2024년 12월). 자사 수치다. [^12]: [Scaling Static Analyses at Facebook](https://discovery.ucl.ac.uk/10084236/1/O%27Hearn%20AAM%20scaling-static-analysis-at-facebook.pdf) (CACM 2019, 저자 원고). 저자들은 야간 배치의 오탐률을 20% 미만으로 봤다. 통제 실험이 아닌 사례 보고이고, 개발자들이 든 이유는 컨텍스트 전환이었다. [^13]: [Modern Code Review: A Case Study at Google](https://sback.it/publications/icse2018seip.pdf) (ICSE SEIP 2018) [^14]: [Tricorder: Building a Program Analysis Ecosystem](https://www.cs.umd.edu/class/spring2019/cmsc414/papers/tricorder-building-a-program-analysis-ecosystem.pdf) (ICSE 2015) [^15]: [60 million Copilot code reviews and counting](https://github.blog/ai-and-ml/github-copilot/60-million-copilot-code-reviews-and-counting/), GitHub (2026년 3월). 자사 수치다. [^16]: [Expectations, Outcomes, and Challenges of Modern Code Review](https://sback.it/publications/icse2013.pdf) (ICSE 2013). 저자들은 지식 전달이 정량화하기 어려운 영역이라고 적었다. [^17]: [Convergent Contemporary Software Peer Review Practices](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/rigby2013convergent.pdf) (ESEC/FSE 2013). 프로젝트별 중앙값을 비교한 수치이며, 저자들도 예비 측정이라고 적었다. [^18]: 구조가 닮은 관행으로는 유방암 검진의 이중 판독이 있다. 두 판독자가 대체로 따로 읽고, 결과가 갈리면 세 번째 판독자가 중재하거나 둘이 합의한다([유럽 유방암 검진 권고의 이중 판독 근거 문서](https://cancer-screening-and-care.jrc.ec.europa.eu/sites/default/files/Guidelines/EtDs/ECIBC_GLs_EtD_double_reading.pdf)). 내 절차에서는 중재자가 나 자신이라 독립성이 약하고, 놓쳤을 때의 비용도 비교할 수 없다. [^19]: 사람과 LLM의 오류가 얼마나 겹치는지 코드 리뷰에서 잰 연구는 찾지 못했다. LLM 350개 이상을 비교한 [Correlated Errors in Large Language Models](https://proceedings.mlr.press/v267/kim25e.html) (ICML 2025)에서는 한 데이터셋에서 두 모델이 모두 틀렸을 때 같은 답을 낸 비율이 60%였다. 방사선과 의사 27명의 [Automation Bias in Mammography](https://pubmed.ncbi.nlm.nih.gov/37129490/) (Radiology 2023)에서는 매우 숙련된 의사의 정답률도 AI 제안이 맞을 때 82.3%, 틀릴 때 45.5%였다. 두 수치 모두 초록 기준이고 코드 리뷰 실험은 아니다. [^20]: 이 절차를 코드 리뷰에서 검증한 연구는 찾지 못했다. 가까운 사례로 수의 방사선과 의사 19명이 참여한 [Who Goes First? Influences of Human-AI Workflow on Decision Making in Clinical Imaging](https://arxiv.org/abs/2205.09696) (FAccT 2022)이 있다. 최종 진단이 AI와 일치한 비율은 잠정 진단을 먼저 등록한 조건에서 89%, 처음부터 AI를 본 조건에서 91%였다(p=0.04). 먼저 등록한 조건의 참가자들은 AI와 의견이 달라도 잠정 진단을 거의 고치지 않았다. 코드 리뷰에도 같은 효과가 있다는 근거로 볼 수는 없다.