코드 리뷰에는 읽기가 필요하다

• 코드 리뷰는 배포 전 형식 절차가 아니라 장애·보안 문제·데이터 삭제 책임을 한 개인에서 팀 책임으로 옮기는 과정임
• 더 나은 평가·테스트·기능 플래그·가드레일·관측 가능성은 읽지 않은 코드 배포의 불안을 줄이려는 답변일 수 있지만, 리뷰의 책임 분산 목적을 놓친 접근이라는 비판임
• 읽지 않고 승인하라는 요구는 사람에게 생각 없이 버튼을 누르게 하는 것과 같으며, CI가 모두 green인 무작위 PR을 병합하는 button roulette 풍자로 이어짐
• 코드 리뷰는 큰 코드베이스의 여러 부분을 팀원이 보게 만들어 bus factor를 낮추고, 새 팀원이 코드와 코드 문화를 익히는 학습 장치로 기능함
• 읽지 않은 코드 배포를 강요하려면 버그·보안 문제·다운타임 등에 대한 서면 책임 면제가 필요하며, 그런 면제를 받기는 어렵다는 결론임

---

리뷰의 목적은 승인보다 책임 분산

• Charity Majors의 글 “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy”에 나온 “읽지 않은 코드를 프로덕션에 배포해도 편안해지려면 무엇이 필요한가”라는 질문이 출발점임
• 더 나은 evals, 테스트, 기능 플래그, 가드레일, 관측 가능성, 의존성 분리, 폭발 반경 축소, 중요 경로 밖의 작은 변경부터 시작하기 같은 답변은 리뷰의 핵심을 비껴간 것으로 다뤄짐
• 리뷰의 목적은 장애, 보안 문제, 우발적 데이터 삭제에 대한 부담을 한 개인에게 두지 않고 작성자와 리뷰어 전체의 팀 책임으로 나누는 데 있음
• “읽지 않고 승인”을 요구한다면 사람에게 수동으로 버튼을 누르게 할 이유가 약해지며, 모든 CI가 green인 할당 PR 중 하나를 무작위로 병합하는 button roulette이라는 풍자가 등장함

읽지 않는 리뷰가 잃는 것

• 코드 리뷰는 팀원이 코드베이스의 다른 부분을 보도록 강제해, 너무 큰 시스템에서 모든 부분을 항상 알고 있을 수 없는 한계를 보완함
• 리뷰 과정은 bus factor를 낮추고, 팀의 여러 구성원이 코드베이스와 코드 문화에 더 익숙해지도록 돕는 역할을 함
• 모두가 읽지 않고 승인하게 되면 이런 학습 효과를 잃고, bus factor가 1로 올라갈 뿐 아니라 제3자에게 외부화되는 문제가 생김
• 읽지 않은 코드를 프로덕션에 배포하라는 요구를 받아들이려면, 그 지시를 내린 사람이 버그·보안 문제·다운타임 등에 대한 서면 책임 면제를 제공해야 한다는 답변으로 정리됨

[GN⁺]

Lobste.rs 의견들

• 리뷰의 목적이 책임 분산이라는 주장에 강하게 거부감이 듦
  main에 머지한 코드가 프로덕션을 깨뜨리면 그건 작성자 책임이지, 나나 팀 전체의 책임이 아님
  전문직으로서 자기 서명이 들어간 작업이고, 토목공학 P.E. 면허로 도장 찍은 교량 설계가 사람을 죽였다면 그 역시 본인 작업과 책임
  팀의 책임은 개발자이자 코드베이스의 관리자로서, 누구의 코드든 프로덕션을 깨뜨릴 수 없게 만드는 것에 있음

  • main에 머지한 코드가 프로덕션을 깨뜨리면 개인 책임이라는 사고방식은 건강한 문화가 아니라고 봄
    main 머지는 누군가가 리뷰하고, 변경을 따져 보고, 설계 논의를 하고, 여러 번 수정한 뒤 승인했다는 뜻임
    에펠탑을 혼자 짓는 사람은 없고, 직장에서 개인을 탓하면 원망과 유해한 문화만 생김
    반복적인 행동 패턴이라면 그건 HR이 다룰 문제임
  • 리뷰어가 책임을 전혀 지지 않는다면 리뷰가 없는 것과 같음
    책임이 0이라면 리뷰어는 쓸모없고, 굳이 리뷰를 할 이유가 없음
    책임 분산은 결과에 가깝고, 핵심 목적은 혼자서는 하기 쉽지만 둘 이상이면 놓치기 어려운 오류를 잡는 것임
    다만 소프트웨어에서 리뷰가 과도하게 쓰이고 있으며, 리뷰가 엔지니어링의 대체재가 될 수는 없다고 봄

• “코드를 읽지 않고 승인”을 “생각 없이 승인”과 동일시하는 건 정확하지 않다고 봄
  예를 들어 프로그램에 정확성 증명이 붙어 있고, PR에서 정의와 정리를 읽을 수 있으며, CI가 결정적 도구로 프로그램과 증명이 맞는지 확인하고, 대비 비율·성능 벤치마크·꼬리 지연 같은 비기능 요구사항도 검사하며, UI 변경은 프로토타입을 쉽게 만져볼 수 있다면 어떨까
  그런 세계에서도 코드를 한 줄씩 읽는 데 지금만큼 집착할 필요가 있을지는 의문임
  오늘날에도 대부분은 SQL을 작성하면서 쿼리 계획이 정확히 원하는 것과 일치하는지 일일이 검증하지 않음
  원글은 “문자 그대로 코드를 읽지 않고도 배포해도 된다고 느끼는 이상적인 세계를 정의해 보자”에 가깝고, 그다음 “현재에서 그 세계로 어떻게 부드럽게 이동할 수 있을까”를 묻는 글로 읽힘
  업계나 특정 회사·코드베이스가 그 지점에서 얼마나 멀리 있는지는 다툴 수 있지만, 그 이상적인 세계를 진지하게 상상하면 대부분 몇 가지 기준을 떠올릴 수 있을 것임
  현재 업계 흐름 때문에 “생각 없이”로 받아들이는 심정은 이해하지만, Charity의 글이 말하는 바는 그게 아니라고 봄

  • 원글의 핵심은 PR에서 문제를 잡는 게 아니라, 코드베이스에 익숙해지는 것과 책임감을 만드는 것임
    이는 테스트가 아무리 좋아도 코드를 읽어야 가능함
    Alice가 코드를 넣고 Bob이 리뷰한 뒤 Alice가 휴가를 가면, Bob이 그 부분을 충분히 알고 책임감을 느껴 수정이나 새 기능 추가를 할 수 있어야 함
    Bob이 정확성 증명에 도장만 찍는다면 이후 그 코드베이스를 다룰 준비가 되지 않음
    커밋 과정에 참여했어도 지식이나 소유감이 늘지 않았다면 사실상 참여하지 않은 것과 다름
  • 이 설명은 전형적인 컴파일러와 비슷해 보임
    다만 컴파일러는 결정적인 반면, LLM은 잠재적으로 의심스러운 테스트를 생성하는 비결정적 도구임
    우리는 이미 사람이 쓴 지시나 코드를 기계가 읽을 수 있는 코드 또는 중간 표현으로 바꾸는 프로그램을 갖고 있고, 생성 결과가 입력과 어떤 관계인지 보장하므로 출력물을 굳이 검사하지 않고도 신뢰할 수 있음
    최적화를 위해 Godbolt 같은 도구로 컴파일러 출력을 읽는 경우는 있지만, 그 외에는 대체로 필요하지 않음
    비결정적인 다른 추상화 수준에서 이를 시도하면 그럴듯해 보일 수 있지만, 컴파일러가 제공하는 정확성 보장을 흉내 내는 것에 불과하고 결국 문제가 생길 것임
    LLM 논쟁은 더 근본적으로 기존의 결정적 프로그래밍 언어가 충분히 표현적이지 않고 도구도 충분히 효과적이지 못하다는 문제의 증상이라고 봄
    LLM이 그 문제를 해결한다고 느껴질 수는 있어도 실제 해법은 아니며, 너무 제한적인 기반 위에 또 하나의 간접 계층과 성능 비용을 얹는 셈임
    해석기 위에서, 다시 컴파일된 기계어 위에서 돌아가는 비싸고 버그 많은 의사 컴파일러에 가깝다고 봄
    그래서 기술적 막다른 길이라고 생각함
    기업에는 단기 수익의 길이 될 수 있지만, 소프트웨어나 인간이 소프트웨어를 쓰고 만드는 관계를 개선하리라고 믿지 않음
    소프트웨어는 제품을 출시하기 위한 기술 그 이상임

• 용도별로 나눠 생각하면 도움이 됨
  내부 애플리케이션 UI용으로 새 JavaScript를 올리는 정도라면 CSS까지 꼭 들여다보지 않아도 괜찮다고 봄