코드 리뷰는 더 나아질 수 있음

 (tigerbeetle.com)
26P by GN⁺ | ★ favorite | 댓글 2개
  • 개발자들은 GitHub의 코드 리뷰 경험에 불만을 많이 느끼고 있으며, 이를 개선하기 위해 새로운 시도중
  • git-review라는 실험적 도구는 코드 리뷰를 브라우저 웹 인터페이스가 아닌, 로컬에서 직접 코드와 함께 다루도록 설계됨
  • 리뷰는 단일 커밋으로 관리되며, 코드 안에 주석처럼 리뷰 코멘트를 남기고, 리뷰어와 작성자가 이 커밋을 함께 수정해 나가는 방식
  • 그러나 리뷰 중간에 코드가 수정되거나 리베이스될 경우, 충돌 처리와 --force-with-lease 사용 등에서 불편함이 발생해 큰 성공을 거두지 못함
  • 결국 웹 기반 리뷰로 복귀했지만, 리뷰 상태를 Git 저장소에 직접 포함시키는 발상은 여전히 매력적이며, Gerrit-style Change-Id 도입 등 향후 Git 개선과 함께 더 나은 대안이 나올 가능성이 있음

코드 리뷰 시스템에 대한 문제 인식

  • 현재 많은 사람들이 GitHub의 코드 리뷰 프로세스에 대해 불만을 가지는 상황임
  • 주요 문제는 스택된 풀 리퀘스트 및 인터디프 리뷰에 대한 지원 부족과 더불어,
    • 리뷰 상태가 저장소 내부에 저장되지 않음
    • 원격 우선 웹 인터페이스를 통한 리뷰가 필수적임
  • 내가 가지고 있는 문제는 리뷰의 탈중앙화 부족과 인터페이스 비효율성임

코드 작성 및 리뷰 워크플로우의 비교

  • 사람들은 코드를 작성할 때 로컬에서 에디터를 사용함
    • 메모리 및 NVMe 지연이 적고, 사용자의 특이한 워크플로우에 최적화된 환경임
  • 코드 리뷰 역시 소스 브랜치를 로컬로 pull 해서 작업하는 방식을 선호함
    • Magit과 같은 도구를 통해 diff 뿐만 아니라 전체 코드 컨텍스트 탐색 가능함
    • 테스트 실행, 코드 정의로의 이동, 리팩토링 시도 등 강력한 개발 환경 이용이 가능함
  • 반면, PR에 피드백을 남기려면 브라우저에서 느린 웹 인터페이스로 이동해야 하며, 큰 diff에서는 입력 지연도 심함

이상적인 코드 리뷰 인터페이스 및 저장 구조

  • 실제로 코드에 인라인으로 코멘트를 남기거나, 직접 코드를 수정하는 것이 가장 자연스러움 
    // CR(matklad): Hm, this check seems imprecise to me.  
// Shouldn't we compare `replica.view` instead of `header.view` here?  
if (header.view != view) return;
  • 데이터가 로컬 git 저장소가 아닌 원격 DB에 저장되면서, 지연과 벤더 락인 문제도 발생함

git-review의 아이디어와 실제 경험

  • git-review의 아이디어는 다음과 같음:
    • 코드 리뷰가 PR 브랜치 최상단의 단일 커밋으로 이루어짐
    • 해당 커밋에 특수 마커가 달린 코드 코멘트가 추가됨
    • 리뷰어와 작성자가 이 커밋을 번갈아 가며 수정하며 push --force-with-lease에 기반한 협업이 이뤄짐
    • 모든 댓글이 해결됨 표시(//? resolved) 되고 리뷰 종료 시 리버트 커밋 추가로 기록이 남음
  • 아이디어는 단순하고 실용적이지만, 실제로는 다음과 같은 문제 발생
    • 리뷰 중 코드 수정 시 하위 커밋이나 신규 커밋에서 코멘트와의 충돌이 잦음
    • force-push 과정에서 협업 마찰과 작업 복잡도 증가
    • 코드의 변경 이력과 리뷰 진행 간의 불일치 및 병합 충돌 관리가 어렵게 됨

새로운 변화와 미래 가능성

  • 앞으로 Git upstream에서 Gerrit 스타일의 Change-Id가 도입될 가능성이 있음
    • 커밋별 수정 이력 추적이 손쉬워져 인터디프 리뷰 지원이 확대될 전망임
    • 하지만 git-review 방식과는 일부 충돌이 예상됨
    • 새로운 Change-Id 구조에서는 커밋 자체에 리뷰 코멘트 추가 등의 색다른 접근이 가능해질 수 있음

결론 및 참고할 만한 시스템 소개

  • 결국 현재는 웹 인터페이스 기반 코드 리뷰로 다시 돌아온 상황임
  • 보다 나은 솔루션에 대한 필요성은 여전히 남아 있음
  • 참고할 만한 관련 시스템 및 도구 소개
    • Fossil: 모든 정보를 저장소 내부에 보관하는 SCM 시스템
    • NoteDb: Gerrit의 리뷰 상태 저장 이력을 git으로 통합
    • git-bug: 이슈 정보를 git에 저장
    • git-appraise: 리뷰 정보를 git 자체에 보관
    • prr: 에디터 내에서 GitHub API와 연동해 리뷰 인터페이스 구현
    • How Jane Street Does Code Review: 더 나은 현실의 예시 소개
    • git-pr: PR 워크플로우 전체를 git의 네이티브 기능으로 대체하는 프로젝트

마무리

  • 아직 완벽한 해결책은 없는 상황이며, 더 나은 개발자 경험을 위한 시도가 계속되고 있음
  • 앞으로의 발전 방향에 많은 기대감이 존재함
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

roxie   [-]

git-review 의 접근이 좋은지는 모르겠으나 깃헙 기반의PR 리뷰가 끔찍하다는 점엔 동의합니다..

답변달기
GN⁺   [-]
Hacker News 의견

  • 코드 리뷰에서 오랫동안 불만이었던 점은, 진짜 유용한 피드백(사소한 취향 지적 외의 것)이 거의 항상 너무 늦게 나온다는 점임. 리뷰의 유일한(혹은 희귀한) 결과물이 "이거 다 다시 새 설계로 시작해야 함" 혹은 "애초에 이 작업은 할 필요 없었음"이라는 상황이 생김. 코드 리뷰만이 모든 이해관계자가 실제로 참여해서 진지하게 변화에 대해 생각하는 유일한 시점인 것 같음. 미팅이나 Jira 티켓에서 뭔가 논의가 있었을 수도 있지만, 종종 조직 다른 팀/부서 누군가가 코드 리뷰 알림을 받고서야 이 변경을 알게 됨. 나 역시 다른 팀이 이상한 걸 구현했을 때, 코드 리뷰 알림으로 처음 알게 되는 경우가 많음. 모든 구성원이 미리 다 팔로우업 한다는 건 비현실적임. 90년대 대학 과정에선 설계 리뷰도 했지만, 실제 현업에선 그런 거 본 적 없음. 설계 리뷰가 모든 이슈를 미리 잡아주리란 보장도 없다고 봄.

    • SW 엔지니어링 세계에는 실질적인 엔지니어링이 별로 없음. 제대로 된 엔지니어링 프로세스의 느림을 업계가 받아들이지 못하는 면도 있음. 대부분 소프트웨어는 치명적이지 않고, 버그나 오류는 나중에 고칠 수 있음. 다리, 공장, 비행기 엔진처럼 실패가 용납되지 않는 다른 분야와 stakes와 패치 기회가 다름.

    • 우리 팀은 4~6명의 소규모 개발자 그룹임. 새로운 기능 만들 때 머릿속 초안이 잡히면 동료들과 바로 상의함. 모두가 이렇게 하다 보니 코드 리뷰는 코드 스멜 등 사소한 것 중심이고, 전체 아키텍처는 보통 2~3명이서 미리 결정함. 팀원들이 코드에 동의하지 않으면 서로 다른 코드에 손대기 싫어해 상황이 안 좋아짐. 규모가 더 커져도 책임을 잘 공유하면 문제없이 가능하다고 믿음.

    • 코드 리뷰 시점에만 모든 이해관계자가 참여하는 것은 Git이나 버전 관리 시스템 문제가 아니라 조직의 문제임. PR 생성의 배경, 티켓 논의, 의사 결정 과정을 공유 못 하는 것임. 이는 dysfunctional 조직의 사례로, 인쇄된 책이 나오는 순간에야 모두 모여 제대로 관여한다고 출판 프로세스를 욕하는 것과 같음.

    • 우리 조직은 근본적 설계 결정에 대해 반드시 RFC를 작성함. 무엇이 근본적 설계 결정인지는 수시로 팀 내 자율적으로 판단함. Jira의 epic 단계에서 세부 구현법이 안 정해지면 일단 RFC 작성부터 할당함. RFC는 우리팀 내부용일 수도, 전체 소프트웨어팀 대상일 수도 있고, 후자일 땐 2주마다 열리는 미팅 전에 모두가 읽고 코멘트 남길 수 있음. 힘들어도 RFC 기반 협업 설계 프로세스가 없는 곳보다 훨씬 나음.

    • 내 경험상 디자인 리뷰에 대해 공감함. 예전엔 포멀한 설계문서와 리뷰를 했지만, 프로토타이핑과 반복 설계로 전환함. 설계 단계에서 중요한 디테일을 종종 빠뜨렸고, 이미 많은 시간을 들였으니 나중엔 대충 넘기게 되었음. 팀 전체가 모여 리뷰하기도 비효율적이라 결국 코드 리뷰 과정에서 이슈가 발견됨. 설계문서 잘 못 쓰거나 동기 없는 사람도 많음. 결과적으로 5명 이상이면 이런 비효율은 피할 수 없음. PO와 주요 사용자, 5명 정도 개발자가 함께하는 환경이 이상적임.

  • HN에서 stacked pull request에 대한 글을 보니 너무 흥미로움. 예전에 graphite.dev를 시작했을 땐 FB나 Google 경험자 아니면 이런 흐름을 모르는 경우가 많았음. 코드 리뷰 트렌드가 3~4년 사이에 엄청 빨리 변하는 것을 보는 게 재밌음.

    • pre-mercurial arcanist 이용자로서, 아직 대형 PR·merge commit 등으로 고생하는 팀에 Graphite를 적극 홍보하고 있음. 특히 PR과의 연동을 가능하게 한 도전정신과 결과에 큰 감명을 받음. Graphite가 하드코어 세팅으로 repo 초기화해 더욱 강한 가정들을 할 수 있는 prescriptive 모드가 있으면 좋겠음.

    • Graphite는 멋진 솔루션임에도 불구하고 가격이 꽤 비싸고, 구매 결정자 설득이 어려움. Graphite처럼 멋진 도구가 오픈소스가 되거나 GitHub에 내장되는 것을 기대함.

    • 나는 fig workflow가 그립기도 함

    • 최근 CodeRabbit에서 발생한 보안사고로 인해 LLM과 코드베이스가 통합된 새 도구 테스트가 꺼려짐. 신기한 새 실험이 보안 문제거리로 뒤바뀌기 쉬움.

    • stacked pull request는 본질적으로 없어도 될 복잡성을 추가함. 자주, 작은 단위의 변경이 훨씬 좋은 개발 관습임. trunk-based development나 continuous integration이 그 목적에 잘 맞음.

  • 점점 더 많은 개발자가 "리뷰툴이 어떤 모습이어야 하는지"에 동의하는 분위기임. 이제 진짜 현실적으로 적용 가능하고, 지속 가능하게 만들 조직과 플레이어가 중요해진 시점임. 최근 git change-id 도입이 좋은 발전임(jj, git butler, gerrit 등에게 감사). Graphite나 GitHub는 자기들 이용자만을 위한 해결책에 집중해, 모두에게 열려 있는 방향은 아님. 수많은 클라이언트 기반 커맨드라인 도구들도 그다지 영향력 없음. 정말 필요한 요소는:

    • 완전히 로컬로 쓸 수 있어야 함
    • vscode를 위한 공식 core팀 지원 필요(vscode 통합만 따로 좋은 UX로)
    • vscode web 등 웹 UI, 다른 에디터와도 최대한 UI 자산을 재사용 가능하게
    • CLI나 라이브러리에서 핵심 기능 제공, 확장용 명확한 경계 갖추기
    • commit/branch/stacked commit/agent snapshot/dev 본인 리뷰 모두 지원
    • 네이티브하게 CI/CD 신호 통합, meta에서 보여준 우수한 UI 작업 기반 강화
    • 상황별로 아주 fine-grained하고 모든 단계에서 수정 가능해야 함(예: cursor에선 한줄 accept 가능, 사람 코드 리뷰도 그런 granular 편집 필요)
    • 완전 incremental해야 하며, PR 수정 시 전체 대신 수정분만 리뷰하는 쉬운 방법 필요함

  • Github의 가장 큰 불만은 앱이 너무 느리다는 점임. 정말 브라우저 탭이 멈출 정도의 느림임. Azure DevOps가 지금까지 사용한 코드 리뷰 툴 중 가장 뛰어났음.

    • Microsoft 환경에서 .NET 개발할 때 Azure DevOps를 사용해봤는데, 진짜 .NET 생태계에 잘 어울리는 도구임

    • GitLab을 열심히 사용해본 적이 있는지 궁금함. 나는 big 4 중에 GitLab이 제일 마음에 듦.

    • DevOps의 어떤 점이 그렇게 마음에 들었는지 궁금함. 매일 쓰지만 github과 비슷하다고 느낌. 오히려 github의 제안 변경 사항 자동 반영 기능이 그립기도 함.

    • 자바스크립트 대규모 사용 + 빠른 릴리즈 압박이 합쳐져 이런 느린 환경을 만듦. 그래도 Atlassian보다는 나음

  • git을 코드 리뷰에 직접 활용하는 아이디어가 매력적임. 변경사항을 로컬에서 직접 만져볼 수 있어 편리함. 리뷰를 반드시 단일 커밋에만 맞추려는 이유를 모르겠음—리뷰어가 자신의 코멘트/수정을 PR 브랜치에 직접 커밋하는 식의 접근도 흥미로움. 이는 전통적인 github flow와 Linux의 메일링리스트·패치 흐름의 하이브리드임.

    • github PR이 읽기 전용인지 궁금함. 팀원이 "suggestion" 코멘트로 바로 수정 제안하고 버튼 클릭 한 번으로 해당 커밋에 반영한 경험 있음

    • 리뷰 커밋이 단일이어야 한다는 건 이상함. 여러 명이 리뷰하면 동시 편집 문제도 생기고, 코드와도 맞지 않음. 리뷰도 각기 별도 브랜치에서 서로 작업하고, 최종적으로 squash & rebase하는 식이 자연스러움. 논의가 길어지면 comment commit도 서로 체인으로 남길 수 있음. 중요한 건 이 데이터가 main branch 바깥 어딘가에 남아야 한다는 점임

  • 코드 리뷰할 때 로컬 브랜치로 당겨와서 soft-reset 한 뒤, 마치 내가 작성한 것처럼 보는 것을 선호함. 커밋이 잘 쪼개지지 않으면 협업자가 각자 쪼개서 리뷰해야 하므로 비효율임. 리뷰 대상이 방대하면, 누가 온전히 이해했다고 말하긴 힘듦. 전체는 단순히 부분의 합이 아님.

    • 쉬운 코드 리뷰용 쉘 함수 예시를 공유함. clean tree 상태에서 review 브랜치를 프리셋으로 체크아웃, nvim에서 diff 확인, 작업 끝나면 브랜치 정리까지 자동화함

    • 좋은 커밋과 그로 만든 PR을 잘 만드는 것도 코드 잘 짜는 것만큼이나 중요한 스킬임. 하지만 실제로는 PR 쪼개기, 커밋 메시지 작성 등에 약한 개발자가 생각보다 많음

    • 데이터 사이언스 병렬 작업 팀에선, 코드 리뷰를 위한 브랜치 2~3개를 체크아웃해서 사용함

    • PR 리뷰용으로 https://github.com/sindrets/diffview.nvim을 네오빔에서 사용함. vscode의 diff와 비슷한 UI이면서 vim의 diff 모드를 활용함. 가벼운 리뷰에는 git log -p --function-context도 유용함

  • 한 명은 첫 draft를 작성하고, 다른 사람이 그걸 다듬고 머지하는 방식에 관심이 있음. 직접 해본 사람 있는지 궁금함.

    • 실제 코딩의 90% 이상은 1인이 맡고, 리뷰어가 직접 최종 반영 및 머지 책임을 지는 스타일에 동의함. 이전 직장에선 리뷰어가 무조건 merge를 담당했고, 큰 변화면 코멘트만 전달함. 누군가에게 일일이 승인 클릭을 부탁하는 방식보다 이 쪽이 훨씬 효율적임

    • 리뷰 코드 작성에 관여하면, 훨씬 깊이 있는 피드백을 줄 수 있다고 느낌. 이런 구조는 '내 코드/네 코드'가 아닌 '우리 코드'로 인식하게 해줌. TDD와 같이 반복적·협업 중심의 문화에 잘 맞음

    • 이 방식은 비동기 페어 프로그래밍과 유사함

    • trunk-based development에서 페어 프로그래밍을 활용하는 사람들을 알고 있음. 둘이서 코드 짠 뒤, OK하면 바로 main에 머지, 테스트 통과하면 즉시 배포. 실제로 잘 동작함

  • Github Pull Request 확장 플러그인을 VSCode에서 써서 로컬로 리뷰하는데 꽤 편리함. 에디터 내에서 바로 코멘트 달고 리뷰 가능함

    • Github 웹에서는 변경파일이 많을 땐 파일을 숨김 처리하지만, VSCode에서는 자유롭게 네비게이션 가능해 훨씬 쾌적함. 이 기능이 VSCode/Github 조합에서 구현된 만큼, 다른 에디터에도 확장될 수 있을 것이라 추측함

    • 좋아지는 건 맞지만, 여전히 Github와 VSCode 쌍방 vendor lock-in이 깊음

    • Github 웹에서 PR 열고 “.” 키 눌러 바로 VSCode 웹에서 리뷰하는 것도 훨씬 나은 경험임

  • Git에 first class change ID가 들어간다는 이야기는 너무 반가움! Facebook의 Phabricator diffs revision tracking과 비슷함. 더 자세히 알아볼 수 있는 링크가 궁금함

    • 근본적 문제는 git이 브랜치 정보를 제대로 관리하지 못하는 데 있음. Fossil은 커밋이 어느 브랜치에서 만들어졌는지 기억함. task branch 자체가 change ID 역할임. 물론 git은 히스토리 조작도 허용해야 해서 해결이 쉽진 않음

  • Sourcehut도 언급하고 싶음. 클래식한 패치/이슈/버그/토론을 메일로 주고받는 흐름을 계승했고, 메일링리스트·CI와 연동됨. Drew Devault의 git-send-email.io, git-am.io에서 패치 송수신 방법 리소스도 제공함

답변달기