버그를 찾겠다는 착각: 코드 리뷰의 진짜 목적, 1976에서 2026까지

한 줄에서 시작된 논쟁

2025년 8월 26일, 수학자이자 오래된 개발자인 마크 도미너스(Mark Dominus) 가 마스토돈에 짧은 글을 올렸다. 며칠 뒤 이 글은 해커뉴스로 옮겨가 375점을 받으며 그 주 가장 뜨거운 개발 논쟁이 됐다. 문장은 도발적이었다.

"많은 사람들이 코드 리뷰의 목적을 오해한다. 코드 리뷰의 목적은 리뷰어가 버그를 찾는 것이 아니며, 코드에 버그가 없음을 보장하는 것은 더더욱 아니다. 코드 리뷰에 기대어 버그를 잡겠다는 사람은 바보의 낙원(fool's paradise) 에 살고 있는 것이다. 이제쯤은 모두가 알아야 한다 — 코드를 들여다보는 것만으로 버그를 찾는 것은 일반적으로 불가능하다."

"코드 리뷰의 진짜 목적은 유지보수하기 어려운 코드 를 찾아내는 것이다. 리뷰어는 코드를 보며 그것이 무엇을, 어떻게 하는지 이해하려 애쓴다. 만약 이해할 수 없다면, 그 코드는 앞으로도 유지보수하기 어렵다는 뜻이고, 원저자가 아직 그 코드를 기억하고 있는 지금 고쳐야 한다."

우리는 코드 리뷰가 "좋은 것"이라는 데 아무도 이의를 달지 않는다. 그런데 막상 왜 좋은지 물으면 대답이 제각각이다. 해커뉴스의 한 댓글은 이 상황을 절묘하게 꼬집었다.

"우리 모두가 코드 리뷰가 중요하다는 데는 동의하면서, 정확히 왜 중요한지에 대해선 합의하지 못한다는 게 웃기다. 마치 고대 주술사들이 화산에 매년 처녀 한 명을 바쳐야 하는 이유를 두고 다투면서도, 바쳐야 한다는 것에는 모두 동의하는 것처럼." — 해커뉴스 사용자 anal_reactor

이 글은 그 "왜"를 처음부터 끝까지 따라간다. 1971년 심리학에서 출발해 1976년 IBM의 첫 공식 인스펙션을 지나, 2013년 마이크로소프트가 리뷰 코멘트를 하나하나 세어 밝혀낸 반전, 그리고 2026년 AI가 버그를 잡기 시작한 지금까지. 용어가 낯설어도 괜찮다. 하나씩, 천천히.

---

제1장: 바보의 낙원 — 왜 읽어서는 버그를 못 잡나

도미너스의 첫 문장이 거칠게 들린다면, 그 뿌리에는 컴퓨터 과학에서 가장 유명한 두 개의 경구가 있다.

첫 번째는 에츠허르 데이크스트라(Edsger Dijkstra) 의 1970년 문장이다.

"테스트는 버그의 존재 는 보여줄 수 있어도, 버그의 부재 는 결코 보여줄 수 없다." (Program testing can be used to show the presence of bugs, but never to show their absence!) — EWD249, 1970

두 번째는 도널드 크누스(Donald Knuth) 가 1977년 동료에게 보낸 메모의 마지막 줄이다.

"위 코드에 버그가 있을 수 있으니 조심하시라. 나는 그것이 옳다는 것을 증명 했을 뿐, 실행 해본 것은 아니다." (Beware of bugs in the above code; I have only proved it correct, not tried it.)

두 사람의 말을 겹치면 도미너스의 주장이 선명해진다. 테스트로도 버그의 부재를 증명할 수 없고, 심지어 수학적 증명 조차 실제 동작을 보장하지 못한다. 그렇다면 사람이 코드를 그저 눈으로 읽어서 모든 버그를 잡겠다는 것은 더더욱 무리한 기대다.

여기서 중요한 오해 하나를 미리 풀고 가자. 도미너스는 "리뷰가 버그를 못 잡는다"고 말한 게 아니다. 논쟁이 커지자 그는 직접 부연했다.

"물론 리뷰는 버그를 잡을 수 있고, 실제로 자주 잡는다. 다만 모든 버그를, 혹은 대부분의 버그를 잡지는 못한다는 뜻이다. 나는 '불가능하다'고 말하지 않았다. '일반적으로(in general) 가능하지는 않다'고 말했다. 이건 수학 용어다 — 짝수가 '일반적으로 4로 나누어떨어지지는 않는다'고 말하는 것과 같다. 물론 많은 짝수는 4로 나누어떨어지지만."

즉 핵심은 "버그 잡기를 리뷰의 주된 목적 으로 삼지 말라" 는 것이다. 버그는 리뷰의 부산물일 수는 있어도, 그것에 품질을 통째로 의존하면 위험하다. 왜 위험한지는, 리뷰어에게 실제로 주어지는 "과제"의 모양을 뜯어보면 드러난다.

---

제2장: 무한한 과제 vs 유한한 과제 — 도미너스의 재구성

논쟁이 뜨거워진 진짜 이유는 도미너스의 두 번째 글 때문이었다. 그는 리뷰어에게 주어지는 임무를 두 가지 버전으로 상상해 보라고 한다.

"누군가 남이 짠 코드 뭉치를 내밀며 '여기서 버그를 찾아봐'라고 한다고 상상해 보자. 정말 어려운 일이다! 찾을 수도, 못 찾을 수도 있다. 성공은 전혀 보장되지 않는다. 게다가 설령 찾는다 해도 — 얼마나 열심히, 얼마나 오래 봐야 하나? 언제 멈춰야 하는지 어떻게 아나? 성공할 방법은 없고, 실패할 방법만 있다. 지쳐 쓰러질 때까지 봐서 버그 셋을 찾아도, 나중에 누군가 '네 번째를 놓쳤잖아, 더 열심히 봤어야지'라고 탓할 수 있다."

"하지만 같은 코드 뭉치를 주면서 이렇게 말한다면 — '이걸 이해할 수 있는지 봐줘. 이해가 안 되면 그렇다고 말해줘.' 이건 훨씬 쉽다! 컨디션이 나쁜 날에도 할 수 있다. 성공은 거의 보장된다 — 전부 이해할 필요조차 없다. 이해 안 되는 부분에 메모만 남기면 된다. 언제 끝나는지도 명확하다 — 전부 이해하려 시도했고, 이해 못 한 곳마다 메모를 남긴 순간, 끝이다."

같은 코드, 같은 리뷰어인데 과제의 '모양'이 완전히 다르다. 하나는 끝이 없고 실패만 존재하는 과제, 다른 하나는 끝이 명확하고 성공이 거의 보장된 과제다.

여기서 가장 반직관적인 통찰이 나온다. "이 코드가 이해가 안 됩니다"라는 리뷰 코멘트는 실패가 아니라 발견이다. 리뷰어가 이해하지 못했다는 것은, 6개월 뒤 이 코드를 고쳐야 할 다음 사람도 이해하지 못하리라는 신호다. 그리고 그 신호는 지금, 원저자의 머릿속에 맥락이 아직 살아 있을 때 잡아야 가장 싸게 고칠 수 있다.

해커뉴스의 한 시니어 개발자는 이 지점을 이렇게 압축했다.

"리뷰어는 마법사가 아니다. 저자가 못 본 무언가가 코드에 있었다면, 리뷰어도 아마 못 본다. 코드에 버그가 없음을 확인하는 방법은 테스트 다. 그러니 리뷰어는 코드를 보며 '이건 잘 돌아갈 거야'라고 말하는 게 아니라, '나는 이게 어떻게 돌아가는지 이해했고, 말이 된다'고 말하는 것이다." — 해커뉴스 사용자 Pxtl

또 다른 댓글은 리뷰의 본질을 '소유권 이전'으로 정의했다.

"코드 리뷰는 코드가 저자의 것 에서 팀의 것 으로 넘어가는 관문이다. 내가 리뷰하는 코드는 당신의 코드가 아니라, 곧 우리 의 코드가 될 코드다." — 해커뉴스 사용자 sjburt

이 '팀의 것으로 넘어간다'는 감각은 어디서 왔을까? 놀랍게도 55년 전, 컴퓨터가 방 하나를 가득 채우던 시절로 거슬러 올라간다.

---

제3장: 뿌리 — 와인버그(1971)와 Fagan 인스펙션(1976)

에고 없는 프로그래밍 (1971)

코드 리뷰 문화의 정신적 조상은 제럴드 와인버그(Gerald Weinberg) 가 1971년 책 《프로그래밍의 심리학》에서 제시한 '에고 없는 프로그래밍(egoless programming)' 이다. 발상은 단순하지만 혁명적이었다 — 코드에 대한 비판을 '나'에 대한 공격으로 받아들이지 말라. 코드와 자아를 분리하면, 동료가 내 코드의 결함을 지적하는 것이 상처가 아니라 협력이 된다.

50년 뒤, 마이크로소프트의 한 30년차 개발자가 남긴 말은 와인버그의 예언이 실현됐음을 보여준다. "예전엔 사람들이 코드 리뷰를 하지 않았고, 남이 자기 코드를 비평하는 상황에 자신을 두기를 극도로 꺼렸다. 코드 리뷰가 '당연한 것'이 되면서 사람들이 자기 코드에 대해 덜 방어적이 되는 데 엄청나게 도움이 됐다."

Fagan 인스펙션 (1976) — 그리고 그 역설

와인버그의 '태도'를 처음으로 엄격한 공정(process) 으로 만든 사람이 IBM의 마이클 페이건(Michael Fagan) 이다. 그가 1976년 《IBM Systems Journal》에 발표한 논문 〈Design and Code Inspections to Reduce Errors in Program Development〉은 오늘날 우리가 아는 모든 코드 리뷰의 시조새다.

여기에 이 글 전체를 관통하는 역설 이 있다. 최초로 공식화된 코드 리뷰는 오직 하나의 목적 — 결함(버그) 검출 — 을 위해 설계되었다. 논문 초록부터 "체계적이고 효율적인 설계·코드 검증 공정"이라고 못박는다. 이후 40년의 역사는, 바로 이 원래 목적이 조용히 다른 것으로 대체되어 가는 이야기다.

Fagan 인스펙션은 6단계로 이뤄진 무거운 공정이었다.

회의에는 명확한 역할이 있었다. 저자(코드 작성자), 리더(코드를 한 줄씩 소리 내어 풀어 설명하는 사람), 테스터/인스펙터(테스트 관점에서 검토), 진행자(회의를 이끌고 궤도를 유지). 결함은 회의실에서 사람들이 둘러앉아 출력물을 한 줄씩 짚어가며 잡아냈다.

이 방식은 실제로 강력했다. 널리 인용되는 수치에 따르면 인스펙션은 결함의 80~90% 를 잡아낼 수 있었고, 결함을 초기에 잡으면 유지보수 단계에서 잡는 것보다 수정 비용이 10~100배 저렴했다.

📌 정확성 메모. "생산성 23% 향상", "82% 검출 효율" 같은 세부 수치가 Fagan 1976에 종종 인용되지만, 원문에서 정확히 확인되지 않는 것들이 있어 이 글에서는 신뢰할 수 있는 80~90% 검출 범위 와 10~100배 비용 배수 만 인용했다.

문제는, 이 무거운 공정이 21세기의 개발 속도를 감당하지 못했다는 점이다. 하루에도 수천 번 코드가 바뀌는 시대에, 매번 회의실을 잡아 넉 명이 출력물을 소리 내어 읽을 수는 없었다. 그래서 리뷰는 가벼워졌다 — 이메일로, 그리고 풀 리퀘스트(Pull Request)로. 이 '현대적 코드 리뷰(Modern Code Review)' 시대에 이르러, 학자들은 처음으로 근본적인 질문을 던지기 시작했다. "우리는 리뷰로 대체 무엇을 얻고 있는가?"

---

제4장: 반전 — 마이크로소프트가 코멘트를 세어보니

2013년, 알베르토 바첼리(Alberto Bacchelli) 와 크리스티안 버드(Christian Bird) 는 소프트웨어 공학 역사에 남을 연구를 발표했다. 논문 제목은 〈Expectations, Outcomes, and Challenges of Modern Code Review〉 — 기대, 결과, 그리고 현대적 코드 리뷰의 도전. 마이크로소프트의 4만 명 넘는 개발자가 쓰던 리뷰 도구 CodeFlow를 무대로, 그들은 두 가지를 나란히 측정했다. 개발자들이 리뷰에서 무엇을 기대 하는가, 그리고 실제 리뷰가 무엇을 산출 하는가.

연구 규모부터 묵직하다. 개발자 873명 설문, 관리자 165명 설문, 그리고 결정적으로 — 200개 리뷰 스레드에서 나온 570개의 실제 코멘트를 사람이 하나하나 손으로 분류 했다.

기대: "당연히 버그 찾기가 1위"

개발자들에게 코드 리뷰를 하는 이유의 우선순위를 물었다. 결과는 예상대로였다. 버그(결함) 찾기가 압도적 1위.

개발자 873명이 "코드 리뷰를 하는 가장 중요한 이유(1순위)"로 꼽은 비율 · Bacchelli & Bird 2013

결과: 실제 코멘트를 세어보니 순위가 뒤집혔다

이제 진짜 데이터다. 실제로 오간 570개의 코멘트를 9개 범주로 분류하자, 순위가 거꾸로 뒤집혔다.

실제 리뷰 코멘트 570개를 손으로 분류한 결과 · 결함은 9개 범주 중 4위 · Bacchelli & Bird 2013

숫자가 말하는 이야기는 명확하다. 개발자의 44% 가 "버그 찾기"를 1순위로 꼽았지만, 실제 코멘트에서 버그를 지적한 것은 14%뿐 — 9개 범주 중 4위였다. 그마저도 대부분 '미시적'이었다. 논문의 문장을 직접 인용하면:

"결함에 관한 리뷰 코멘트는 우리 표본 전체의 8분의 1 에 불과했고, 대부분 '미시적'이고 표면적인 사안(예: if 조건문의 잘못된 표현식)을 다뤘다. 반면 프로그래머와 관리자는 개념적·설계 수준의 더 통찰력 있는 지적을 기대 했다."

한 시니어 개발자의 자조 섞인 증언은 이 간극을 생생하게 보여준다.

"형식(포매팅)에 대해 코멘트하면서, 정작 보안 문제나 데이터 모델 문제가 있다는 사실은 놓친 코드 리뷰를 꽤 많이 봤다."

그렇다면 리뷰가 진짜로 만들어낸 가치는 무엇이었나? 논문은 이렇게 결론짓는다 — "코드와 변경을 이해 하는 것이야말로 코드 리뷰의 핵심" 이라고. 그리고 이 이해는 코드에 익숙한 사람일수록 깊어진다. 응답자의 91% 가 익숙하지 않은 파일은 리뷰에 더 오래 걸린다고 답했고, 82% 는 코드에 익숙한 리뷰어가 더 깊고 통찰력 있는 피드백을 준다고 답했다.

이것이 바로 도미너스가 2025년에 한 말을, 마이크로소프트가 2013년에 이미 데이터로 증명해 둔 셈이다.

그런데 — 리뷰를 대충 하면 어떻게 될까? (반드시 짚어야 할 반례)

여기서 "그럼 버그 찾기가 14%밖에 안 되니 리뷰는 대충 해도 되나?"라고 오해하면 곤란하다. 정반대다. 2014년 맥킨토시(McIntosh) 등 이 Qt·VTK·ITK 세 대형 프로젝트를 분석한 연구(MSR 2014 최우수 논문)는 냉정한 숫자를 남겼다.

핵심은 참여도(participation) 다. 리뷰를 형식적으로 승인 도장만 찍고 넘어가면(=얕은 참여), 커버리지가 낮은 것보다도 품질에 더 나쁘다. 즉 버그를 '직접 겨냥'하지 않더라도, 코드를 진지하게 이해하려 애쓰는 행위 자체가 품질을 지킨다. 도미너스의 주장과 완벽하게 맞물린다 — 이해하려는 노력이 곧 품질 방어다.

---

제5장: 구글의 종착점 — 리뷰어 1명, 24줄, 4시간

Fagan의 무거운 회의실에서 출발한 리뷰가 40년 뒤 어디에 도달했는지 보고 싶다면, 구글을 보면 된다. 2018년 사도스키(Sadowski) 등 이 발표한 〈Modern Code Review: A Case Study at Google〉은 약 900만 건의 리뷰된 변경 로그를 분석했다. 결과는 Fagan 시대와는 딴 세상이다.

리뷰어는 보통 한 명, 변경은 24줄 남짓, 대부분 4시간 안에 끝난다. 무겁고 동기적인 회의는 사라지고, 가볍고 비동기적인 흐름만 남았다. 그렇다면 구글은 왜 리뷰를 하는가? 논문의 답이 이 글의 핵심을 그대로 반복한다.

"구글에서 코드 리뷰에 대한 기대는 문제 해결(버그 잡기)을 중심에 두지 않는다. 리뷰는 애초에 코드의 가독성과 유지보수성 을 보장하기 위해 도입됐다. 오늘날 개발자들은 여기에 더해 교육적 측면, 규범 유지, 이력 추적, 관문(gatekeeping), 사고 예방을 인식하고 있다. 결함 발견은 환영받지만, 유일한 초점은 아니다."

구글의 첫 세대 개발자는 리뷰 도입 이유를 이렇게 회고했다 — "리뷰어가 버그를 찾으면 좋은 일이지만, 구글에 코드 리뷰를 도입한 가장 중요한 이유는 코드의 이해가능성과 유지보수성을 높이기 위해서였다." 코드가 미래의 개발자를 가르치는 교사 역할을 해야 한다는 것이다.

이 철학은 구글의 유명한 'readability(가독성) 인증' 제도로 제도화됐다. 특정 언어에 대해 스타일과 모범 사례를 충분히 이해했다고 인증받은 개발자만이 가독성 자격을 얻고, 모든 변경은 해당 언어의 가독성 인증자가 작성했거나 리뷰해야 한다. 버그가 아니라 읽힘 을 제도의 중심에 놓은 것이다.

리그비(Rigby)와 버드(Bird)는 이 모든 흐름을 한 문장으로 요약했다 — 현대적 코드 리뷰는 "결함 발견 활동에서 그룹 문제 해결 활동으로 바뀌었다(from a defect finding activity to a group problem solving activity)."

---

제6장: 사례 — "이 코드가 이해되나?"가 실제로 잡아내는 것들

추상적인 이야기를 실무의 장면으로 바꿔보자. "버그를 찾아라" 대신 "이해가 되는지 보라"로 렌즈를 바꾸면, 리뷰어는 어떤 것들을 잡아내게 될까?

네 경우 모두, 버그는 없다. "버그 찾기" 렌즈로는 전부 통과다. 하지만 6개월 뒤 이 코드를 고쳐야 할 사람에게는 전부 지뢰다. "이해되나?" 렌즈만이 이것들을 지금 잡아낸다 — 원저자가 "아, 그 7은 API 타임아웃이 60초라서요"라고 즉답할 수 있는, 바로 지금.

해커뉴스의 한 개발자는 이 통찰을 시니어로 성장하는 순간과 연결했다.

"코드가 너무 영리해서 쉽게 이해되지 않는다면, 그 코드는 쉽게 고칠 수도 없다. 주니어에서 시니어로 넘어가던 시기, 나는 더 단순한 것이 거의 항상 더 낫다 는 걸 깨달았다." — 해커뉴스 사용자 SketchySeaBeast

물론, 모두가 도미너스에 동의한 것은 아니다. 이 논쟁이 375점을 받은 이유는 반론도 그만큼 날카로웠기 때문이다. 공정하게 짚어보자.

이 반론들은 옳다. 그리고 도미너스도 반박하지 않았다 — 그는 "버그를 못 잡는다"가 아니라 "버그 잡기를 유일한 안전망 으로 삼지 말라"고 했으니까. 진실은 아마 그 사이 어딘가에 있다. 리뷰는 버그도 잡는다. 다만 그것이 품질의 최후 방어선이어서는 안 되고, 리뷰의 가장 큰 가치는 이해·유지보수·지식 전파에 있다. 그리고 2026년, 이 균형점은 다시 한번 크게 움직이고 있다.

---

제7장: 2026 — AI가 버그를 잡고, 사람은 이해를 지킨다

도미너스의 논리에는 숨은 전제가 하나 있었다. "사람은 코드를 읽어서 버그를 잘 못 잡는다." 그런데 2026년, 이 전제에 균열을 내는 존재가 등장했다. 버그 잡기만큼은 지치지 않고, 밤새, 모든 줄을 읽는 AI 리뷰어다.

AI 코드 리뷰, 어디까지 왔나

2025~2026년 사이 AI 코드 리뷰 도구는 폭발적으로 늘었다.

성능도 진짜다. 전통적 정적 분석기가 실제 런타임 버그의 20% 미만 을 잡던 것에 비해, 오늘날 앞선 AI 리뷰어는 42~48% 를 잡는다. 세대가 바뀐 것이다. 앤트로픽도 공식 GitHub Action(claude-code-action, claude-code-security-review)을 제공한다 — 인젝션·인증 우회·하드코딩된 비밀·취약한 암호화 등을 패턴 매칭이 아니라 의미 기반 으로 잡고, Claude 자신이 결과를 한 번 더 걸러 오탐을 줄이는 설계다. (코어닷투데이 역시 Claude의 /code-review를 개발 흐름에 쓰고 있다.)

그런데 — AI 리뷰의 그림자

장밋빛만은 아니다. AI 리뷰의 가장 큰 적은 오탐(false positive) 과 소음 이다.

깊이 중첩된 로직, 여러 단계의 상태 변화, 드물게 실행되는 경로 — 정작 치명적 버그가 숨는 곳 에서 AI는 여전히 약하다. 한 벤치마크에서 Claude Code는 검증된 이슈 41건을 찾았지만 오탐도 24건을 냈다. AI는 버그 잡기의 속도와 커버리지 를 극적으로 끌어올렸지만, 판단 을 대체하진 못했다.

그래서, 노동 분업

여기서 2026년의 그림이 완성된다. AI가 도미너스가 말한 그 '사람이 원래 잘 못하던 일 — 기계적 버그 찾기'를 떠맡기 시작했다. 그렇다면 사람에게 남는, 사람만이 할 수 있는 일은 무엇인가? 바로 도미너스가 11년 전(그리고 마이크로소프트가 13년 전) 가리킨 그것 — 이해가능성, 유지보수성, 설계 의도, 지식 전파 다.

2026년 2월, 데이비드 폴(David Poll)은 〈코드 리뷰는 버그 잡기가 아니다〉라는 글에서 이 분업을 명료하게 정리했다 — 자동화가 기계적 검사(스타일·보안 패턴)를 흡수할수록, 사람의 판단은 더 위로 — 아키텍처의 일관성과 제품적 안목으로 — 이동한다. LeadDev의 표현을 빌리면, 개발자는 코드의 저자 에서 의도의 큐레이터이자 관문지기(curators and gatekeepers) 로 변한다. 병목은 '코드를 쓰는 일'에서 '코드를 리뷰하는 일'로 옮겨갔고, 그 리뷰의 가장 인간적인 부분이 사람에게 남은 것이다.

CodeRabbit은 이를 한 문장으로 요약했다 — "2025년이 AI 속도 의 해였다면, 2026년은 AI 품질 의 해가 될 것이다."

---

마무리: 이해가 안 되면, 그게 신호다

한 수학자의 짧은 마스토돈 글에서 출발해, 우리는 55년의 시간을 거슬러 올라갔다 왔다.

이 긴 역사가 한 지점으로 수렴한다. 코드 리뷰의 가치는 리뷰어가 몇 개의 버그를 잡았는지로 측정되지 않는다. 그것은 리뷰어가 그 코드를 이해 했는지, 그래서 그 코드가 이제 한 사람의 머릿속이 아니라 팀의 자산 이 되었는지로 측정된다.

그러니 다음번에 코드를 리뷰할 때, 스스로에게 "버그가 있나?"라고 묻는 대신 이렇게 물어보자.

"나는 이 코드가 무엇을, 왜, 어떻게 하는지 이해했는가?"

이해가 안 되는 곳이 있다면 — 그건 당신의 부족함이 아니다. 그건 발견이다. 그게 바로 지금 고쳐야 할 신호다.

버그를 잡는 일은 점점 더 기계에게 넘어간다. 하지만 "이해되는 코드를 만든다"는 것 — 미래의 동료(그리고 미래의 AI)가 읽고 고칠 수 있는 코드를 남긴다는 것 — 은, 2026년에도, 그 이후에도, 여전히 가장 인간적인 엔지니어링의 기술이다.

---