# DiffsHub

> Clean Markdown view of GeekNews topic #30676. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30676](https://news.hada.io/topic?id=30676)
- GeekNews Markdown: [https://news.hada.io/topic/30676.md](https://news.hada.io/topic/30676.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-21T09:05:56+09:00
- Updated: 2026-06-21T09:05:56+09:00
- Original source: [diffshub.com](https://diffshub.com/)
- Points: 1
- Comments: 1

## Topic Body

- **대형 GitHub diff**를 브라우저에서 빠르게 훑어봐야 할 때, DiffsHub는 공개 diff를 **가상화 인터페이스**로 보여주는 도구임
- GitHub URL의 `github.com`을 `diffshub.com`으로 바꾸면 PR, 비교, 커밋, diff, patch 변경 내용을 바로 볼 수 있음
- 별도 변환 절차 없이 기존 URL 구조를 유지해, `github.com/org/repo/pull/number`를 `diffshub.com/org/repo/pull/number`처럼 바꿔 접근함
- Linux `v6.0...v7.0` 같은 **수백만 줄 비교**도 다룰 수 있지만, 모바일 브라우저에서는 가끔 크래시될 수 있음
- GitHub는 **100k 줄 초과 diff**에서 첫 바이트 응답이 지연되고 안정적으로 제공되지 않을 수 있어, 큰 변경 검토 시 대안으로 볼 수 있음

---

### GitHub URL 그대로 쓰는 diff 뷰어
- **DiffsHub**는 공개 GitHub diff를 빠르고 보기 좋은 가상화 인터페이스로 확인하는 도구임
- 지원 대상은 **PR, 비교, 커밋, diff, patch**임
- 사용자는 GitHub URL에서 도메인만 바꿔 접근함
  - `github.com/org/repo/pull/number`
  - `diffshub.com/org/repo/pull/number`

### 수백만 줄 diff와 제약
- DiffsHub는 수백만 줄 규모의 비교도 다룰 수 있음
- 예시로 [Linux v6.0...v7.0 비교](https://diffshub.com/torvalds/linux/compare/v6.0...v7.0)를 볼 수 있음
- 이런 대형 비교는 **모바일 브라우저**에서 가끔 크래시될 수 있음
- GitHub는 **100k 줄 초과 diff**를 지연된 첫 바이트와 함께 불안정하게 제공할 수 있음

## Comments



### Comment 60047

- Author: neo
- Created: 2026-06-21T09:05:57+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/u0nv8q/diffshub) 
- diff 보기와 **vibecoding 태그**가 무슨 관련인지 이해하려고 했음  
  이후 맥락과 드라마를 따라잡고 왜 이렇게 됐는지 이해함. 소음 만들어서 @quad에게 미안하고, 이제 태그도 제거된 걸 봄
  - Lobsters가 좀 이상한 국면에 들어가서, 프로젝트가 “vibecoded처럼 보이는지”를 사람들이 마음대로 판단하고 있음  
    예를 들면 낮은 코드 품질, 적은 커밋 수, 심지어 저장소에 CLAUDE.md가 있다는 이유만으로도 **vibecoding** 태그를 붙이는데, 별 의미가 없어 보임
  - 저장소에 **CLAUDE.md**가 있었음. 여기서는 잘못 제거됐고, 이 글에는 적절한 태그였다고 봄
  - 다행히 그 태그는 이제 사라진 것 같음

- 추가 맥락으로는 이 글이 관련 있어 보임: [On Rendering Diffs](https://pierre.computer/writing/on-rendering-diffs)  
  홈페이지에 링크된 Linux diff를 둘러볼 때도 꽤 부드러워서 인상적임. 스크롤바를 직접 드래그해 보면 알 수 있음. Github나 다른 브라우저 기반 diff 편집기, 직장에서 쓰는 Graphite도 이 정도로 부드러웠으면 좋겠음  
  한편으로는 이런 데 감탄한다는 사실 자체가 이상함. 원래 이게 표준이어야 하는 거 아닌가 싶음
  - diff 렌더링 작업 대부분을 한 사람과 그 글의 저자를 알고 있음. 진행 중에 문자로 실시간 업데이트를 받았는데, 얼마나 많은 조사와 작업을 쏟아부었는지 정말 대단했음  
    말 그대로 몇 달 동안의 풀타임 업무가 **diff를 빠르게 렌더링**하게 만드는 일이었음  
    참고로 “vibecoding” 태그가 붙었지만, 여전히 이해가 안 가고, 이 작업은 전혀 그런 류가 아니었음. 대부분은 어려운 조사, 브라우저 구현 코드 읽기, 시행착오, 문제를 정석적으로 파고드는 일이었음  
    아주 좁고 보상이 명확한 탐색 작업에는 에이전트 루프가 쓰였지만, 내가 알기로는 사람의 통찰과 검토 없이 들어간 건 없었음. 블로그 글에서도 이 부분을 다루는 것 같고, 전체 작업에서 정말 작은 비중이었음. 그 이유만으로 **공학적 노력**을 폄하하는 건 말이 안 됨  
    블로그 글을 읽거나 코드를 보는 걸 강력히 추천함. 놀라운 작업이고 배울 게 많음
  - 정말로 이 정도가 표준이어야 함. Gitlab과 Forgejo도 이걸 받아들였으면 좋겠음  
    직접 테스트해 보려고 북마클릿을 만들었음:  
    ```js  
    javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();  
    ```  
    아쉽게도 많은 PR, 특히 큰 PR은 댓글 기능이 필요함. Pierre가 언제 이 영역까지 가져가서 예를 들면 https://www.reviewable.io/ 같은 걸 만들지 지켜봐야겠음

- npmjs는 Apache 2라고 하는데 저장소에는 라이선스가 없고 package.json에는 `"private":true`까지 있어서 이유를 찾기 어려웠음  
  답은 각 디렉터리가 개별적으로 라이선스되는 구조인 것 같음: https://github.com/pierrecomputer/pierre/blob/diffs-v1.2.11/packages/diffs/LICENSE.md  
  그리고 diffshub 자체는 오픈소스 부분에 포함되지 않는 듯함: https://github.com/pierrecomputer/pierre/blob/diffs-v1.2.11/apps/diffshub/package.json#L4  
  이런 **수술식 라이선스** 방식은 https://github.com/pierrecomputer/pierre/tree/diffs-v1.2.11/packages/theming#:~:text=The%20theming%20toolkit%20for%20Pierre%27s%20open%2Dsource%20UI%20packages 같은 디렉터리를 애매한 상태에 둠. 그 디렉터리에는 Apache 2 LICENCE.md가 없기 때문이고, [package.json 필드가 권위 있다고 본다면](https://github.com/pierrecomputer/pierre/blob/diffs-v1.2.11/packages/theming/package.json#L4) 얘기가 달라질 수는 있음

- UI는 **대비**만 빼면 Github보다 나아 보임. 접근성은 잘 모르겠음

- 참고로 Github의 모든 pull request는 뒤에 `.diff`를 붙이면 diff를 받을 수 있음  
  예: https://github.com/oven-sh/bun/pull/30412.diff  
  `.patch`를 붙이면 `git am`에 넘길 수 있는 형태도 받을 수 있음: https://github.com/oven-sh/bun/pull/30412.patch
  - `error: too big or took too long to generate`  
    이 이유 때문에 일부러 이 PR을 고른 건가? :D

- 도구에 대한 기대치가 다른 사람들보다 낮은 건지도 모르겠지만, 이걸 Github 자체 기능과 비교했을 때 **실용적인 차이**를 잘 모르겠음  
  모두 Github가 얼마나 나쁜지 한탄하는데, 나는 같은 경험을 해보지 못했음. 왜 Github 대신 이걸 써야 하는지 모르겠음
  - 왜 이게 내게 중요한지 보여주는 영상을 녹화했음. 영상이 X에 있어서 미안하지만 거기에 올려둠  
    역사적으로 이게 내 일반적인 경험이었고, 왜 속도가 중요한지도 설명함. 어떤 작업이 충분히 오래 느리면 내 생각이 다른 데로 흘러가고, 그게 **몰입 상태**를 크게 망침  
    영상은 PR을 열고 특정 파일로 이동하는 데 걸리는 시간을 나란히 비교함. 나에게는 꽤 흔한 일상 작업임  
    https://x.com/mitchellh/status/2057229385963618787

- [pulldash](https://pulldash.com/)(coder.com 제작)나 [difit](https://yoshiko-pg.github.io/difit/)(로컬호스트 페이지를 띄우는 CLI)과 꽤 비슷해 보임  
  둘 다 별로 좋아하진 않음. pulldash는 좀 버벅였고 difit은 추가 노력이 필요했음. 셀프 리뷰에는 지금 [git tree compare](https://marketplace.visualstudio.com/items?itemName=letmaik.git-tree-compare) VSCode 확장을 씀  
  이건 빠르고 전체적인 시각 디자인도 마음에 듦. 내 PR 하나로 시험해 봤는데 충분히 괜찮아 보였고, PC에서 북마크해 둘 수도 있겠음