코드 리뷰도 '연습하면 늘어나는 기술'입니다

출처: typesanitizer (Varun Gandhi)
원문: https://typesanitizer.com/blog/code-review.html

작성자: 팔복소프트-김팔복

한눈에 보기

• 코드 리뷰는 버그 발견뿐 아니라 교육, 팀 규범 유지, 게이트키핑, 지식 공유 등 여러 목적을 가진 활동이라는 것이 Google·Microsoft 연구에서도 확인됐습니다.
• 글쓴이는 최신 고성능 LLM 리뷰가 놓친 버그 3건을 사람이 리뷰로 잡아낸 실제 사례를 소개합니다.
• 핵심 주장은 "코드 리뷰는 타고나는 능력이 아니라 배우고 가르칠 수 있는 기술"이라는 것입니다.
• 소크라테스식 대화, 니어미스(near-miss) 회고, 코드와 분리된 모델링 등 리뷰 문화를 실험해볼 수 있는 아이디어도 제안합니다.
• "LLM이 리뷰를 더 잘하니 사람은 그만둬도 된다"는 최근 분위기에 대해, 사람이 코드에 책임을 지는 한 리뷰 실력은 여전히 투자할 가치가 있다고 반박합니다.

주요 내용

코드 리뷰를 둘러싼 논쟁

2025~2026년 사이 개발자 커뮤니티에서는 "코드 리뷰가 병목이다", "머지 전 필수 리뷰는 저신뢰 조직의 문화다", "LLM이 사람보다 리뷰를 잘한다" 같은 주장이 자주 등장했습니다.

글쓴이는 먼저 연구 결과를 근거로 코드 리뷰가 단일 목적의 활동이 아니라는 점을 짚습니다. Google 사례 연구(2018)에서는 개발자들이 리뷰에 기대하는 것을 교육(education), 규범 유지(maintaining norms), 게이트키핑(gatekeeping), 사고 예방(accident prevention) 네 가지로 정리했고, Microsoft 연구(2013)에서도 결함 발견 외에 지식 전파, 팀 인지도 향상, 대안 탐색 같은 효과가 크다는 점을 확인했습니다.

LLM 리뷰가 놓친 버그 3건

글쓴이는 최근 몇 주간 직접 리뷰에서 잡아낸 버그 세 가지를 소개합니다. 세 PR 모두 고성능 코딩 모델 여러 개로 LLM 리뷰를 돌렸지만, 아래 문제들은 LLM이 잡아내지 못했습니다.

1. Git 설정의 동시 쓰기 문제

개발용 VM(devbox) 시작 시간을 줄이기 위해 ~/.gitconfig 수정 작업을 포그라운드에서 백그라운드 프로세스로 옮기는 PR이었습니다. 글쓴이는 과거 lock 획득 실패로 인한 비결정적 시작 실패를 겪었던 경험을 떠올려 문제를 지적했고, 동료가 제시한 대안(프로세스 간 의존성 추가)도 이전에 시도했다가 지연 시간 증가로 폐기했던 방식이라는 것을 알려줬습니다. 결국 별도의 flock 기반 락을 도입해 재시도, 일괄 수정, 직접 쓰기를 모두 안전하게 처리하는 방향으로 정리됐습니다.

2. aws CLI 플래그의 버전 호환성

S3 업로드 진행 로그가 너무 많아 CI 로그 용량 제한(10MB)을 초과하자, 동료가 --no-progress로 로그를 끄는 PR을 올렸습니다. 글쓴이는 진행 정보를 아예 없애기보다 업데이트 주기를 조절하는 --progress-seconds 플래그를 제안했는데, 이후 문득 예전에 "CI 환경의 CLI 버전이 낮아 새 플래그가 동작하지 않았던" 사고가 떠올랐습니다. 확인해 보니 실제로 CI의 aws CLI 버전이 해당 플래그를 지원하지 않아 그대로 머지됐다면 잡이 깨질 상황이었습니다. 최종적으로 저장소의 다른 곳에서 이미 패키징하던 최신 CLI를 설치하는 것으로 해결됐습니다.

3. 체크섬 사이드카 파일이 만들 수 있었던 장애

기존 CI 잡과 별도로 만든 새 업로드 잡이 체크섬 사이드카 파일을 함께 올리는 구조였습니다. 문제는 tarball을 먼저 업로드하고 체크섬을 나중에 올린다는 점이었습니다. S3는 단일 객체 쓰기에는 all-or-nothing을 보장하지만 객체 두 개를 묶는 트랜잭션은 없기 때문에, 체크섬 업로드 전에 잡이 중단되면 fail-closed 방식으로 무결성을 검사하는 리더가 전부 실패해 해당 기능이 장애 상태에 빠질 수 있었습니다. 글쓴이는 예전에 본 DuckLake 발표에서 다뤘던 Apache Iceberg의 메타데이터 설계(다중 객체 트랜잭션 부재로 인한 복잡성)를 떠올려 이 문제를 발견했고, 결국 읽기 경로의 사이드카 검증은 도입되지 않았습니다.

리뷰 실력은 배울 수 있다

글쓴이는 물리학 대학원생 시절 코드 리뷰라는 개념 자체를 처음 접했고, 2019년 개발자로 전직한 이후 리뷰 실력을 하나씩 익혀왔다고 말합니다. 동료들에게 "리뷰가 평균보다 도움이 된다"는 평가를 받게 된 것도 타고난 능력이 아니라 학습의 결과라는 것입니다.

본인에게 도움이 됐다고 생각하는 습관으로는 자신이 만든 버그를 무겁게 받아들이는 태도, 프로그램을 불변식(invariant)과 작은 증명의 관점으로 생각하는 습관, 디버깅·성능 분석 이야기가 담긴 기술 블로그와 발표를 즐겨 보는 것을 꼽습니다. 특히 불변식 중심의 사고는 충분히 배우고 가르칠 수 있는 부분이라고 강조합니다.

리뷰 문화를 실험해볼 아이디어

글쓴이는 검증된 방법이 아니라 시도해볼 만한 아이디어라는 전제를 달고, 심리적 안전감이 확보된 팀을 전제로 몇 가지를 제안합니다.

• 소크라테스식 대화: 시니어가 지적하는 대신, 주니어에게 "왜 이렇게 했는지", "어떤 가정을 했는지"를 먼저 묻는 리뷰 미팅. "왜 이렇게 안 했느냐" 같은 반사실적(counterfactual) 질문은 피하는 것이 핵심입니다.
• 니어미스 회고: 리뷰에서 잡힌 버그를 작성자가 짧은 클립으로 설명하고, 스프린트 회고에서 팀이 함께 보며 아슬아슬하게 걸러진 버그를 공유하는 방식.
• 코드와 분리된 모델링: 한 사람은 코드를 보지 않고 Alloy 같은 도구로 시스템 모델을 만들고, 다른 사람은 코드를 작성한 뒤 중간에서 테스트 케이스를 함께 만드는 방식. 락, 취소, 접근 제어처럼 프로세스 의미론이 복잡한 영역에서 유용할 수 있습니다.
• 전문성 연구: 팀 내에서 유독 통찰력 있는 리뷰를 하는 사람을 찾아, Applied Cognitive Task Analysis 같은 기법으로 암묵지를 추출해보자는 제안.

"LLM이 다 할 텐데"라는 반론에 대해

글쓴이의 주장은 조건부입니다. "사람이 앞으로도 프로그램의 개발과 유지보수에 관여할 것이라고 믿는다면, 리뷰 실력을 키우는 것은 가치가 있다"는 것입니다. 전제에 대한 확률 판단은 각자 다를 수 있지만, 전제를 받아들인다면 결론은 성립한다는 논리입니다.

추가로 세 가지 근거를 듭니다. 첫째, 남들보다 낮은 추상화 수준(SQL 쿼리 플랜, 메모리 할당, 어셈블리 등)을 다룰 수 있는 사람은 언제나 더 넓은 문제를 해결할 수 있습니다. 둘째, 소프트웨어 개발은 다른 분야에 비해 아직 초기 단계라, 코드 리뷰에서 인간 실력의 상한이 어디인지조차 모릅니다. 셋째, 소셜 미디어의 "썰"보다는 경험 보고서, 사례 연구, 자신의 관찰에 근거해 판단하라는 것입니다.

정리

이 글의 핵심은 코드 리뷰를 "귀찮은 절차"나 "LLM으로 대체될 작업"이 아니라, 의식적으로 연습하고 발전시킬 수 있는 기술로 보자는 것입니다. 글쓴이가 소개한 세 가지 버그 사례는 도메인 맥락, 과거 사고의 기억, 시스템 설계 원리에 대한 이해가 결합될 때 리뷰가 얼마나 강력해지는지 보여줍니다. 자신이 배포하는 코드에 책임을 지는 개발자라면, 리뷰 실력에 투자하는 것이 여전히 좋은 선택이라는 메시지를 기억할 만합니다.

• 코드리뷰
• 소프트웨어엔지니어링
• 개발문화
• LLM
• 버그