코드 리뷰는 자동화 가능한 결함 탐지만을 위한 절차가 아닙니다

AI 요약

이 글은 코딩 에이전트가 사람의 코드 리뷰를 대체할 수 있다고 주장한 논문 초록을 검토합니다. 논문은 코드 리뷰의 목적을 결함 탐지, 스타일 준수, 지식 전달, 변경 사항 인지로 나누고 에이전트가 각 기능을 수행할 수 있다고 봅니다. 글쓴이는 이런 분류가 리뷰의 목적을 자동화 가능한 작업으로만 한정한다고 반박합니다. 기능을 각각 흉내 내는 것과 동료 리뷰어를 대체하는 것은 같은 문제가 아닙니다.

코드에 대한 혼란도 리뷰 결과입니다

경험 많은 동료가 변경 사항을 읽고 “이해가 안 됩니다”라고 말하면, 코드가 지나치게 복잡하거나 추상화가 잘못됐거나 의도가 불분명하다는 신호일 수 있습니다. 글쓴이는 사람이 실제로 이해에 실패하는 경험 자체가 코드의 이해 가능성을 드러낸다고 봅니다. 반면 LLM은 코드를 처리하고 설명할 수 있다는 이유로 이해한 것처럼 답할 수 있습니다. 그러면 독자가 느끼는 정당한 혼란을 리뷰 신호로 포착하기 어렵습니다.

변경의 필요성과 범위를 먼저 따집니다

리뷰어는 코드가 요구사항에 맞는지 확인하기 전에 “이 변경이 정말 필요한가”, “하나의 PR로 묶을 일인가”, “근본 원인이 아니라 증상만 고치는 것은 아닌가”를 물을 수 있습니다. 이런 질문은 의도와 범위, 해결책의 적절성을 검토합니다. 글쓴이는 코드가 필요하다는 전제를 두고 정확성만 확인하는 방식으로는 이 역할을 설명하기 어렵다고 지적합니다. 실제 운영 환경에서는 리뷰가 변경을 다시 생각하게 만드는 마지막 기회일 때도 있습니다.

빠진 것과 코드 밖의 맥락을 살핍니다

리뷰어는 API 계약이 달라졌는데 오류 처리가 그대로인 경우처럼, 코드에 있어야 하지만 없는 요소를 알아차릴 수 있습니다. 글쓴이는 이 부재를 인식하는 능력이 LLM이 약한 영역이라고 봅니다. 또 코드 저장소에는 최근 장애, 하위 시스템 담당 팀의 계획, 로그 수집에 관한 법무팀 지침처럼 조직 안에서 공유되는 정보가 모두 담기지 않습니다. 사람은 이런 운영 맥락과 비공식 합의를 현재 변경에 연결할 수 있지만, 논문은 코드베이스가 완전한 맥락인 것처럼 다룬다고 비판합니다.

리뷰는 위험도에 따라 달라집니다

리뷰어는 변경 내용뿐 아니라 작성자의 경험과 과거 작업도 고려합니다. 결제 모듈을 처음 수정하는 주니어 엔지니어의 변경과 숙련된 엔지니어의 일상적인 리팩터링에 같은 주의를 기울이지 않을 수 있습니다. 글쓴이는 사람의 리뷰가 작성자, 변경 시점, 영향 범위와 리뷰어 자신의 경험을 함께 고려한다고 설명합니다. 모든 diff를 같은 입력으로 취급하면 이런 맥락별 판단을 놓칩니다.

설명 전달이 아니라 함께 이해를 만듭니다

코드 리뷰에서 작성자는 질문에 답하며 자신의 접근을 다시 살피고, 리뷰어는 시스템과 변경 의도를 배웁니다. 대화가 끝나면 양쪽 모두 처음과 다른 이해를 갖게 될 수 있습니다. 글쓴이는 이를 에이전트가 설명을 만들어 전달하는 지식 전달과 구분합니다. 리뷰는 양방향의 공동 사고 과정이며, 요약문만으로는 두 사람의 관점을 함께 바꾸는 대화를 대신하기 어렵습니다.

책임과 협업도 리뷰의 일부입니다

변경을 승인한 사람이 결과에 책임진다는 인식은 검토에 영향을 줍니다. 글쓴이는 책임을 법적 규정에 맞춰 사람 이름을 남기는 절차로만 보면 실제로 신중하게 살펴보게 하는 동기를 놓친다고 주장합니다. 리뷰는 결함 탐지뿐 아니라 팀의 조율, 판단과 책임을 함께 다루는 과정입니다. 사람의 기여를 측정 가능한 기능으로 나눈 뒤 기계가 각 기능을 수행한다고 해서, 그 기능을 통합하고 예기치 않은 상황에 대응하는 사람의 역할까지 사라지는 것은 아니라고 글을 맺습니다.

Hacker News 반응

• @n4r9 — 리뷰 체크리스트에는 요구사항 달성 여부, 불필요한 코드나 디버그 출력, 결함과 보안 문제, 가독성, 스타일, 성능, 테스트 충분성이 들어갑니다. LLM은 대부분을 꽤 잘하지만, 첫 번째 항목에는 가장 약하다고 생각합니다.
  • @anarazel — “이걸 원하는가? 비용 대비 편익은 어떤가?”도 물어야 합니다. 특히 아키텍처에 맞는 변경인지 판단하는 일은 LLM이 여전히 꽤 못합니다.
• @Boxxed — 코드 리뷰는 리뷰어에게도 지식을 전달합니다.
• @refactor_master — 제 경험으로는 자동화 코드 리뷰가 어느 때보다 쓸모없습니다. 린터와 테스트가 있고 AI가 코드를 작성합니다. 코드가 잘 돌아간다는 말은 듣고 싶지 않습니다. 필요한 건 아키텍처와 장기적인 관점, 비즈니스 관점입니다.
  • @jeremyjh — 그렇지 않습니다. AI를 많이 쓰고 도움도 받지만, 기존 코드베이스에서 기능이 들어갈 자리를 찾는 ‘큰 규모의 프로그래밍’에는 여전히 형편없습니다. 코드를 작성할 때도 리뷰할 때도 시야가 너무 좁습니다. 정확성, 성능, 보안, 스타일은 살펴도 아키텍처와의 일관성이나 빠진 비즈니스 수용 기준은 잘 찾아내지 못합니다.
• @skybrian — 코드에 없는 맥락을 파악하려면 프롬프트를 리뷰하는 편이 나을까요?
  • @clintonb — 동의하지 않습니다. 제 프롬프트 대부분은 “이 이슈를 구현해 주세요”입니다. 이슈에는 사용자 스토리와 수용 기준이 있고, LLM은 그걸 바탕으로 계획을 세워 코드를 만듭니다. 하지만 저장소에 들어가는 것은 코드 산출물이므로 리뷰 대상도 코드여야 합니다.
• @jimbobimbo — 잘 정리해 주셔서 감사합니다. 봇이 봇이 쓴 코드를 리뷰하는 건 자기 혀로 자기 아이스크림을 핥는 일입니다.
  • @asp_hornet — 코드 리뷰가 중요하다고 생각합니다. 글이 그 이유를 잘 설명합니다. 다만 사람에게 넘기기 전에 서로 다른 모델로 PR을 리뷰하는 방식도 실제로 도움이 됐습니다.
• @dimbletimbers — 사람이 리뷰할 때 얻는 이점으로 ‘이해의 중복’을 더 많이 이야기했으면 합니다. 진지하게 리뷰한다면 적어도 두 명이 기능이 어떻게 동작하는지 알게 됩니다. 그중 한 명은 기능이 더 넓은 시스템 안에서 어떻게 맞물리는지도 이해하게 될 수 있습니다.
  • @atomicnumber3 — 한 사람만 코드에 대해 안다면 PR 시간이 문제를 해결해 주지는 않습니다. 저는 테크 리드지만 보통 PR을 리뷰하지 않는다고 팀에 말합니다. 대신 “경쟁 상태를 봐 주세요”처럼 무엇을 어떤 목적으로 봐야 하는지 구체적으로 요청하면 기꺼이 봅니다. 버그를 그냥 찾아내는 일은 사람이 잘하지 못했고, 이제는 LLM이 더 잘합니다. 시스템을 이해하려면 PR 리뷰보다 서로 대화하는 편이 낫습니다.
• @bhouston — 중요 시스템을 제외하면 AI가 만든 코드의 90% 이상에서 사람의 코드 리뷰가 이미 사라지는 중이라고 봅니다.
  • @binary0010 — 왜 그렇게 생각하시나요? 제 경험과는 다릅니다. 어떤 소프트웨어와 팀을 기준으로 그렇게 판단하셨는지 듣고 싶습니다.
• @clintonb — 제 조직에서 코드 리뷰를 어떻게 할지 고민 중입니다. 제가 계속 돌아오는 질문은 “이 조직은 사람의 학습을 우선시하는가?”입니다. 리뷰를 통해 서로 가르치고 배우고 싶지만, 피드백이 곧바로 에이전트에 들어갑니다. 사람이 반응하는 건 10% 정도라서, 팀원 역량을 더 약하게 만들고 제 일을 로봇에게 가르치는 것 외에 실제 리뷰에 무슨 가치가 있는지 고민됩니다.
• @metalspot — 코드 리뷰가 널리 쓰이는 진짜 이유는 과실에 대한 책임을 피할 방패가 되기 때문입니다. 다만 코드 리뷰는 팀 협업과 조율, 관리에도 유용했습니다. AI가 사람보다 훨씬 빠르게 코드를 만들고 시스템 이해가 코드 리뷰에만 달려 있다면 생산성은 거의 늘지 않습니다. 사람 리뷰를 없애려면 무엇이 대신할지가 문제입니다. 테스트가 통과하는지, 테스트가 기능을 충분히 입증하는지, 변경의 범위와 영향은 무엇인지, 배포와 롤백 계획 및 배포 후 모니터링은 어떤지 확인해야 합니다. 코드 리뷰는 코드 자체를 위한 절차만은 아니었습니다.
  • @geraneum — “AI 코드 생성 시대에 경쟁하려면 사람의 코드 리뷰를 없애야 한다”는 주장은 홍보하려는 방향에 맞게 용어를 다시 정의하는 것처럼 보입니다.

원문: Adaptive Capacity Labs / 번역·요약: Trawling