Hacker News 의견들

• 리뷰를 아예 안 할 수도 있음
  리뷰를 왼쪽으로 당겨서 코드 디자인 세션으로 바꾸고, 데일리에서 문제를 제기하고, 어려운 부분은 페어 프로그래밍으로 해결하면 대부분의 리뷰 목적이 사라짐
  남은 10%의 변수명, 공백, 패턴 같은 건 linter로 자동화 가능함
  결국 중요한 건 팀이 합의한 코드를 신뢰하고 작성할 수 있는 신뢰 기반의 팀 문화를 만드는 것임

  • “계획에 몇 시간을 쓰면 코딩 몇 분을 아낀다”는 말처럼, 모든 아키텍처를 화이트보드에서 설계할 수는 없음
    실제 구현 중에야 문제를 깨닫게 됨
    완벽히 계획대로 되는 경우는 거의 없었음. 결국 반복적인 아키텍처 미팅이 필요하지만, 그건 또 주간회의의 늪으로 빠짐
  • 존경하던 엔지니어들이 코딩 에이전트로 PR을 자동 생성하면서 이 방식을 버리는 걸 봤음
    스스로 작성한 코드조차 리뷰하지 않게 되면, 쌓아온 신뢰가 순식간에 무너짐
  • 이 글의 핵심도 결국 신뢰의 시스템임
    Toyota Production System처럼 QA 단계를 없애려면, 모든 구성원이 결함을 발견했을 때 즉시 멈출 수 있는 신뢰가 필요함
    리뷰 파이프라인은 문제를 숨기고 속도를 늦출 뿐임
  • “리뷰를 왼쪽으로 당기고, 디자인 세션으로 부르고, 데일리에서 문제를 제기하고, 페어 프로그래밍으로 해결한다”
    이 한 문장 자체가 지옥의 정의 같음
  • “우리는 당신을 신뢰함. 하지만 전화번호는 알고 있음”이라고 새로 합류한 사람들에게 말함
    이게 꽤 잘 통함. 사람들은 스스로 테스트를 작성하고, 수동 검증도 병행함
    잘못된 배포를 10분 만에 되돌릴 수 있는 안전망도 구축함

• 코드 리뷰는 자원봉사자의 딜레마임
  “PR을 많이 리뷰했다”보다 “기능을 많이 출시했다”가 평가에 반영되기 때문임
  결국 리뷰는 자기 일에 직접 영향이 있을 때만 적극적으로 하게 됨
  하지만 코드가 유연하다는 점에서, 빠른 머지와 후속 수정이 오히려 더 빠른 수렴을 가져올 수 있음

  • 리뷰어가 팀 리드처럼 팀의 산출물에 책임을 느끼는 경우도 있음
    특히 버그를 미리 잡아 온콜 스트레스를 줄이려는 동기도 큼
  • 주니어에게는 모든 PR을 리뷰하라고 권장함
    이해가 안 되더라도 질문을 남기는 게 학습에 큰 도움이 됨
    리더가 되고 싶다면 코드와 디자인 문서 리뷰를 많이 해야 함
  • 흥미롭게도, 대부분의 개발자가 가장 중요하다고 생각하는 두 가지 — 코드 리뷰와 코드 삭제 — 는 보상받지 못함

• 이 글은 내 직감과 경험을 명확히 정리해준 글이었음
  Tailscale 제품도 좋아했지만, 이제는 CEO의 팬이 될 듯함
  글쓴이 Avery에게 감사하며, 이 글을 널리 공유할 예정임

• Valve는 커뮤니케이션 대역폭의 한계를 이해하는 몇 안 되는 회사임
  조직이 커질수록 커뮤니케이션 부담이 지수적으로 증가함

  • 이걸 처음 깨달은 사람은 Jeff Bezos였다고 생각함
    다른 회사들도 이제는 깨달았을 법한데, 여전히 그렇지 않음

• 리뷰가 5시간 내에 처리된다는 게 놀라움
  대부분은 며칠 단위로 진행됨
  하지만 모든 개발자가 버그를 발견했을 때 즉시 멈출 수 있는 문화가 있다면 리뷰는 필요 없을 수도 있음
  현실은 릴리스 목표를 못 맞추면 개인이 불이익을 받는 구조임

  • 예전 회사는 리뷰에 며칠이 걸렸지만 코드 품질은 괜찮았음
    지금 회사는 리뷰가 몇 분 만에 끝나지만 기술 부채가 폭증함
  • FAANG 팀에서는 리뷰 SLA가 4시간이었음
    일정 시간 지나면 자동으로 “리뷰 대기 중” 메시지가 옴
    모든 게 측정되고, 성과 압박이 심했음
  • 어느 순간 리뷰가 병목이라는 걸 깨닫고, 팀 코드 리뷰를 즉시 처리하기 시작했음
    팀 규모만 적당하면 이 습관은 학습 가능하고 전파 가능함
  • 글쓴이가 Tailscale의 CEO라는 걸 페이지 하단에서 봤음
  • 지금까지 리뷰가 진지하게 다뤄지는 프로젝트를 본 적이 없음
    비즈니스도, 개발자도 별로 신경 쓰지 않음

• 리뷰의 가치 대비 노력 비율이 종종 무시됨
  리뷰가 실제로 품질을 높이지 못한다면, 그 시간은 낭비임
  세세한 논쟁보다 “작동하는가”만 확인하고 빠르게 머지하는 게 효율적임
  이후 커밋으로 개선하면 됨
  리뷰는 짧고 방향성만 확인하는 체크포인트여야 함

• “리뷰어의 일은 리뷰를 없애는 것”이라는 말에 전적으로 동의함

• 글이 직렬화된 프로세스를 전제로 하지만, 실제로는 병렬로 진행됨
  여러 버그를 동시에 처리하면 리뷰 지연이 큰 문제가 아님
  핵심은 동시 작업 수(N) 를 조절하는 것임

  • 이를 위해 큐잉 이론 계산기를 만들어봄
    링크
    PR 리뷰 속도가 느릴수록 컨텍스트 스위칭 비용이 커짐
    계산 결과, 리뷰 속도를 높이면 생산성이 크게 향상됨

• “리뷰어의 목표는 리뷰를 불필요하게 만드는 것”이라는 말에 공감하지만,
  신뢰의 범위가 회사 외부까지 확장되면 이야기가 달라짐
  예를 들어 npm update로 악성 코드가 배포된다면, 사후 대응은 너무 늦음
  신뢰 기반이라도, 때로는 사람의 검증이 필요한 지점이 존재함

• 매니저들은 생산성을 강조하면서도, 동시에 속도를 늦추는 프로세스를 유지함
  복잡한 문제라 단순히 좋다 나쁘다 말하기 어려움

  • “How complex systems fail”의 Rule 9를 떠올림
    운영자는 생산성과 안전을 동시에 책임져야 함
    사고 전에는 생산성이, 사고 후에는 안전이 강조됨
    외부인은 이 이중 역할의 균형을 잘 이해하지 못함
    관련 링크