0github - 코드 리뷰를 위한 히트맵 기반 Diff 뷰어

 (0github.com)
6P by GN⁺ | ★ favorite | 댓글 1개
  • 코드 변경(diff) 내 각 라인과 토큰을 색상으로 구분해 검토가 필요한 정도를 시각화하는 도구
  • 단순한 버그 탐지 대신, ‘다시 살펴볼 가치가 있는 부분’ 을 강조하도록 설계
  • GitHub Pull Request URL의 github.com을 0github.com으로 바꾸면 바로 사용 가능
  • 내부적으로 저장소를 VM에 복제하고 gpt-5-codex를 실행해 JSON 구조의 분석 결과를 생성

개요

  • 이 도구는 코드 리뷰 과정에서 변경된 코드의 각 부분이 얼마나 주의 깊게 검토되어야 하는지를 히트맵 형태로 표시
  • 색상은 인간의 주의 필요도를 기준으로 지정되며, 단순 오류 탐지와는 다른 접근을 취함

작동 방식

  • 사용자는 GitHub Pull Request URL의 도메인을 github.com에서 0github.com으로 변경해 접근
  • 시스템은 해당 저장소를 가상 머신(VM) 에 복제하고, 각 diff에 대해 gpt-5-codex 모델을 실행
  • 모델이 생성한 JSON 데이터 구조를 파싱해 색상 히트맵으로 변환

분석 기준

  • 단순히 “버그 여부”가 아니라, 하드코딩된 비밀값, 비정상적인 암호화 모드, 복잡한 로직 등
    사람이 다시 확인할 필요가 있는 부분을 강조

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 익숙한 코드베이스에서는 “LLM 고마워, 하지만 내가 더 잘 알아서 필요 없음”이라 생각함
    반대로 익숙하지 않은 코드라면 애초에 내가 리뷰를 승인하거나 머지하지 않음
    그래도 이런 창의적인 LLM 활용은 흥미로운 시도임

    • 직접 테스트해봤음. Laravel PR #57499를 무작위로 선택했는데, 60% 설정에서는 테스트 코드만 강조되고 중요한 변경은 놓침
      삭제된 코드도 전혀 표시되지 않았고, 변경되지 않은 줄만 하이라이트됨
      정직한 시도였지만 결과는 실망스러움

  • 왜 GitHub에서 나를 대신해 행동할 권한까지 요구하는지 의문이었음
    cmux-agent가 GitHub 계정 전체 접근 권한을 요청함
    이슈를 등록하려 했지만 저장소에서 이슈 기능이 비활성화되어 있었음. 조금 수상한 느낌이었음

    • 공개 저장소라면 로그인 없이 접근 가능해야 함
      시크릿 모드로 예시 PR들, stack-auth, tinygrad, datasette 테스트했는데 잘 작동했음
      이슈 비활성화는 몰랐고 지금은 이슈 페이지가 정상임
    • GitHub의 구조적 문제임. 관련 토론을 보면, OAuth App과 GitHub App의 권한 모델이 다름
      GitHub App은 특정 리포에만 설치할 수 있지만 여전히 “사용자 대신 행동” 권한을 포함함
      그래서 무섭게 보이는 팝업이 뜨는 것임
      내 앱 codeinput.com은 OAuth App이라 이메일만 요청하지만, 로그인 후 다시 설치 과정을 거쳐야 하는 복잡한 인증 흐름이 생김
    • 앱을 처음 실행할 때 GitHub 로그인을 요구함. 그 전엔 아무 것도 볼 수 없음

  • 방향성은 흥미롭지만 비용 대비 효용이 애매함
    LLM이 단일 PR diff만으로 프로젝트 맥락을 이해하기는 아직 어려움
    오히려 과거 버그나 변경 빈도를 기반으로 한 데이터 기반 히트맵이 더 신뢰도 높을 것 같음

    • Gemini 무료 키를 쓰면 하루 요청량이 충분해서, 소규모 팀(10~20 PR/일)에는 큰 비용이 아님
      개인 키로 실행할 수 있다면 더 좋을 듯함
    • diff의 엔트로피를 분석하는 비슷한 도구가 있을지 궁금함
    • 우리도 예전에 리포를 VM에 복제해 Codex로 탐색시키는 실험을 했지만, 지연 시간과 비용 문제로 중단했음
      Distillation으로 비용을 줄일 수 있을 것 같지만 아직 실험 중임
      과거 버그와의 상관관계를 LLM 없이 계산할 방법이 있을지도 고민 중임
    • 코드 리뷰할 때 diff에 없는 줄을 자주 언급하게 됨
      이런 도구들은 결국 문제의 일부분만 해결할 수 있음
    • 코드 변경이 잦은 부분이 꼭 버그가 많은 건 아닐 수도 있음
      오히려 사람들이 더 주의 깊게 보는 영역일 가능성도 있음
      오픈소스 데이터를 기반으로 검증해보면 흥미로울 것 같음

  • 내 PR이 HN에 올라와서 반가웠음
    0% 임계값으로 두고 색상 그라데이션을 다양하게 조정할 수 있으면 좋겠음
    PR 생성 전에 AI가 만든 코드를 이 도구로 미리 리뷰할 수 있을지도 궁금함

    • 색상과 그라데이션은 설정 가능하게 할 예정임
      CLI나 HTML로 diff를 렌더링하는 명령어 형태가 괜찮을지 의견을 묻고 싶음
    • 이런 도구를 쓰느라 결국 직접 코딩하는 시간보다 더 오래 걸릴 수도 있음

  • 도메인 이름 0github.com은 오래 유지하기 어려울 듯함. 빨리 다른 도메인을 찾는 게 좋겠음

    • 왜 그런지 궁금함

  • 거대한 PR에서 특히 유용할 것 같음
    슬라이더 대신 색상별로 클릭해 의미를 바로 볼 수 있으면 좋겠음
    지금은 한눈에 파악하기 어렵지만 자주 쓰면 익숙해질 듯함

    • 현재는 하이라이트된 단어에 마우스를 올리면 툴팁이 표시됨
      모바일에서도 보이게 개선할 예정임. 혹시 다른 표시 방식이 나을지 궁금함

  • 간단한 Rust PR에 적용해봤는데 꽤 잘 작동했음
    다만 하이라이트 위치를 좀 더 세밀하게 조정할 수 있으면 좋겠음
    동료 PR에서 거의 안 보이는 오타를 잡아낸 건 인상적이었음
    테스트한 PR 링크
    삭제된 코드 일부는 표시되지만 많은 부분이 무시됨
    혹시 토큰 간 거리를 계산하는 방식인지 궁금했음

    • 구현은 이 파일에 있음
      지금은 단순한 LLM 프롬프트 기반임
      향후 환각 토큰 감지 방식으로 발전시킬 수 있을 듯함. 관련 논문을 찾아볼 예정임

  • 요즘 AI가 만든 대형 PR이 많아지면서 이런 도구의 필요성을 느꼈음
    리뷰어의 스타일을 학습해 맞춤 리뷰를 제공하면 좋겠음
    이 커밋이 맞는지 확인 중임

    • 주요 로직은 이 파일에 있음
      DSPy 시스템으로 리뷰어의 선호도에 맞춘 자동화 리뷰를 실험 중임

  • 사실 이런 도구가 필요 없을 정도로 적당한 크기의 PR을 만드는 게 더 중요함
    요즘은 AI로 작성된 PR을 리뷰하고, 심지어 내 코멘트에 AI가 답변함
    결국 리뷰어도 AI로 대체되는 시대가 올 것 같음

  • 예시 PR을 클릭했는데 계속 로딩만 됨. 캐싱이 필요해 보임

    • 이미 캐싱이 있어야 하는데 확인 중임
    • 수정 완료함. 이제 정상 작동함
답변달기