AI가 놓친 버그를 사람은 왜 찾았을까요: 코드 리뷰도 훈련이 필요해요

AI가 놓친 버그를 사람은 왜 찾았을까요: 코드 리뷰도 훈련이 필요해요

IT & AI 뉴스 썸네일

코드 리뷰를 병합 전 승인 절차로만 다루면 리뷰어의 역할도 좁아져요. 실제 리뷰는 버그를 막는 동시에 팀이 코드와 운영 맥락을 함께 이해하는 시간이 될 수 있어요. 최근 한 개발자는 고성능 코딩 모델을 섞은 LLM 리뷰가 놓친 문제 세 가지를 사람이 찾아낸 경험을 공개했어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
코드 리뷰	리뷰는 교육, 규범 유지, 설계 경계 관리, 사고 예방을 함께 맡아요	승인 속도만 재면 지식 공유와 운영 안전이라는 효과를 놓칠 수 있어요
사람과 AI	LLM 리뷰는 세 PR의 문제를 모두 찾지 못했어요	코드 밖에 있는 장애 경험과 도구 버전 지식이 판단을 바꿨어요
팀 학습	좋은 리뷰는 연습하고 가르칠 수 있어요	질문 방식, 아차 사고 회고, 작은 모델링으로 리뷰 과정을 훈련할 수 있어요

1. 좋은 코드 리뷰는 맥락을 읽는 기술이에요

원문은 코드 리뷰가 결함 탐지보다 넓은 일을 맡는다고 설명해요. Google의 코드 리뷰 사례 연구가 정리한 역할에는 교육, 조직 규범 유지, 설계 경계 관리, 사고 예방이 포함돼요. 다른 연구에서도 리뷰 과정이 지식 전달과 팀의 상황 인식, 대안 발견에 도움을 준다고 봤어요. 리뷰어는 diff에서 틀린 줄만 찾는 사람이 아니라 변경 이유와 주변 시스템을 이해하는 사람이에요. 2

이 차이는 실제 사례에서 더 선명해요. 한 PR은 개발용 EC2 가상 머신의 시작 소요 시간을 줄이려고 일부 초기화 작업을 백그라운드로 옮겼어요. 여러 프로세스가 같은 Git 설정 파일을 건드리면 잠금 충돌이 생길 수 있었어요. 단순히 작업 순서를 묶으면 충돌은 줄지만 전체 시작 시간이 다시 늘어나는 문제가 있었어요. 리뷰어는 과거에 같은 접근을 썼다가 성능 때문에 되돌린 경험을 떠올렸고, 별도 잠금 파일을 쓰는 방향으로 수정했어요. 2

또 다른 PR은 10GB가 넘는 파일을 S3 버킷 네 곳에 올리면서 CI 로그가 10MB 제한을 넘는 문제를 다뤘어요. 진행 표시 빈도를 낮추는 AWS CLI 옵션이 대안으로 나왔지만, 실제 CI에 설치된 버전은 그 옵션을 지원하지 않았어요. 문서에 적힌 최신 사용법만 확인했다면 배포 환경에서 다시 실패할 수 있었어요. 리뷰어가 과거의 버전 호환성 장애를 기억했기 때문에 설치 버전까지 확인했어요. 2

세 번째 사례는 tarball과 checksum 파일을 차례로 갱신하는 구조였어요. S3 객체 하나의 쓰기는 원자적이지만 두 객체를 묶은 갱신은 하나의 트랜잭션이 아니에요. 첫 파일만 새 버전으로 바뀐 순간 작업이 취소되면 새 tarball과 이전 checksum이 함께 남아요. 각 코드 조각이 정상이어도 시스템 전체에서는 장애 조건이 생겨요. 분산 시스템의 상태 전이를 머릿속에 그린 사람이 이 틈을 발견했어요. 2

원문 작성자는 세 PR 모두에 2026년 6월 무렵의 고성능 코딩 모델을 섞은 리뷰를 적용했지만, 이 문제들을 찾지 못했다고 밝혔어요. 이 사례만으로 사람 리뷰가 언제나 AI보다 낫다고 일반화할 수는 없어요. 다만 모델이 코드와 문서를 빠르게 훑어도 과거 장애, 오래된 실행 환경, 여러 객체 사이의 갱신 순서처럼 저장소 밖의 맥락은 빠질 수 있다는 점은 분명해요. 2

팀에서 연습할 수 있는 방법

리뷰 코멘트 수를 늘리는 것보다 어떤 생각을 거쳤는지 드러내는 연습이 유용해요. 시니어가 바로 답을 주기보다 구현자가 둔 가정과 실패 조건을 질문하면 이해의 빈틈을 함께 찾을 수 있어요. "왜 다른 방법을 안 썼나요"처럼 결론을 유도하기보다 "이 구현에서 지켜져야 하는 조건은 무엇인가요"처럼 현재 판단의 근거를 묻는 편이 좋아요.

728x90

병합 직전에 막은 버그도 짧게 기록해 두면 좋아요. 실제로 어떤 조건에서 문제가 생겼는지, 과거에 비슷한 장애가 있었는지 남기면 팀원이 같은 실패 모드를 배울 수 있어요. 개인의 감각으로 끝났던 경험이 다음 리뷰의 검색 기준으로 바뀌어요.

동시성, 접근 제어, 취소 처리처럼 상태 조합이 많은 변경은 코드와 별도로 작은 모델을 그려볼 수 있어요. 입력과 상태, 지켜야 할 불변 조건을 적으면 diff 화면에서 잘 보이지 않던 조합을 찾기 쉬워요. 모든 PR에 형식 기법을 적용할 필요는 없어요. 장애 비용이 크거나 재현하기 어려운 부분부터 좁게 써 보는 편이 현실적이에요. 2

왜 중요한가요

AI 코딩 도구가 코드를 더 많이 만들수록 팀이 검토해야 할 변경량도 늘 수 있어요. 이때 리뷰를 모델의 자동 코멘트와 승인 버튼으로 줄이면 코드가 운영 환경에서 만나는 조건을 확인할 사람이 없어져요. 반대로 사람 리뷰어가 문법이나 사소한 스타일만 반복해서 지적하면 자동화보다 느린 병목이 돼요.

역할을 나누는 편이 실용적이에요. AI는 반복 패턴, 누락된 검사, 익숙한 API 오용을 먼저 훑을 수 있어요. 사람은 배포 환경의 제약, 이전 장애, 팀이 암묵적으로 지키는 설계 경계, 여러 서비스 사이의 상태 변화를 확인해요. 리뷰 결과만 보지 말고 어떤 질문과 관찰이 문제를 찾았는지 남겨야 다음 리뷰어도 같은 관점을 배울 수 있어요. 2

좋은 리뷰어는 타고나는 사람이 아니에요. 전체 파일과 호출 경로를 읽고, 변경 전후의 불변 조건을 비교하고, 막아낸 문제를 다시 살펴보는 과정에서 실력이 쌓여요. LLM 리뷰가 발전해도 실제 배포 결과에 책임지는 팀이라면 이 훈련을 없애기보다 AI가 다루기 어려운 맥락 판단에 집중하는 편이 나아요.

참고 자료

1. 코드 리뷰도 배워야 하는 기술이다 — GeekNews
2. Reviewing code is a skill — TypeSanitizer