동료가 Slack에 붙여 넣은 함수 리뷰
누군가 채팅에 코드 블록 두 개를 던지고 어느 쪽이 맞는지 묻습니다. 20줄짜리 스니펫을 위해 repo를 clone하고 브랜치를 바꾸고 IDE를 여는 건 낭비입니다. 둘 다 diff 도구에 붙여 넣으면 다음 메시지가 도착하기 전에 답이 나옵니다. 사람들이 온라인 diff를 찾는 가장 흔한 이유입니다.
원본 (버전 A)
변경됨 (버전 B)
Git Diff Online: 브라우저에서 두 코드 버전 비교
왼쪽에 버전 A, 오른쪽에 버전 B를 붙여 넣으면 무엇이 바뀌었는지 정확히 보여줍니다. git clone 없음, IDE 없음, 가입 없음. 모든 작업이 브라우저 안에서 이뤄집니다.
이 온라인 git diff 도구가 하는 일
Git, GitHub, IDE를 열지 않고 두 버전의 코드를 비교할 수 있는 무료 브라우저 도구입니다. 이전 버전을 왼쪽에, 새 버전을 오른쪽에 붙여 넣으면 차이가 문자 단위로 강조 표시됩니다. 텍스트는 사용자의 컴퓨터를 떠나지 않으므로, private repo나 머지되지 않은 브랜치의 스니펫일 때도 안심할 수 있습니다.
동료가 Slack에 함수 두 버전을 던지고 "뭐가 바뀐 거야?"라고 묻는 그 순간을 위해 만들어졌습니다. 12줄짜리 diff를 위해 로컬 checkout을 띄우는 건 과합니다. 아직 PR이 없는 상태에서 GitHub PR 뷰를 여는 것도 마찬가지입니다. 텍스트 패널 두 개, diff 하나, 15초면 끝입니다.
실제 working tree 위에서의 git diff를 대체하지 않습니다. hunk 스테이징, patch 적용, blame 실행은 할 수 없습니다. 할 수 있는 것은, 가장 자주 필요한 부분입니다. 임의의 두 텍스트 덩어리를 받아 그 사이의 편집 내용을 보여주는 것. 내부적으로 diff 자체는 compare-text 도구와 동일한 엔진을 사용하며, code review용으로 다듬었습니다.
diff가 실제로 동작하는 방식
diff는 문자 단위로 실행된 뒤 시맨틱 클린업 단계가 변경 사항을 다시 읽기 좋은 덩어리로 묶어줍니다. 그 결과 강조 표시는 이름이 바뀐 식별자 단위로 떨어지고, 그 안의 글자 하나하나에 떨어지지 않습니다. 오른쪽 패널의 삽입은 초록색, 왼쪽 패널의 삭제는 빨간색입니다. 두 패널은 스크롤이 연동되므로, 한쪽에서 80번째 줄의 변경을 찾으면 다른 쪽도 함께 점프합니다.
왜 행 단위가 아니라 문자 단위인가요? 짧은 스니펫에서는 행 단위 뷰가 너무 거칠기 때문입니다. 변수를 id에서 userId로 바꾸는 건 식별자 한 군데의 변경입니다. 행 단위 diff는 그 줄 전체를 삭제하고 새 줄 전체를 삽입한 것으로 표시합니다. 기술적으로는 맞지만 실제 편집 지점은 더 찾기 어려워집니다. 문자 모드에 시맨틱 클린업을 더하면, 이름이 바뀐 토큰만 강조하고 줄의 나머지는 그대로 둡니다. 긴 파일에서는 균형이 뒤집히고, 그래서 Git이 기본으로 고전적인 행 기반 diff를 씁니다. 둘 다 자리가 있습니다. 이 도구는 스니펫에 친화적인 뷰를 제공합니다.
이 도구가 의도적으로 하지 않는 일: 문법을 인식하지 않습니다. JavaScript, Python, Java를 파싱하지 않습니다. 의미가 같은 채로 재포맷된 블록도 diff로 표시됩니다. 텍스트 비교기에는 다른 텍스트이기 때문입니다. 구조화된 페이로드에 대해 포맷 인식 diff가 필요하다면, compare-json 페이지가 JSON을, compare-yaml이 YAML을, compare-xml이 XML과 POM 파일을 처리합니다. 원본 소스 코드는 일회성 스니펫을 위해 문법 인식 도구를 설정하기보다, 텍스트 diff에 자기 눈을 더하는 편이 보통 더 빠릅니다.
코드 diff를 세 단계로
텍스트 패널 두 개, diff 하나. 로그인도, 업로드도, 파싱할 patch 포맷도 없습니다.
- 1
왼쪽에 버전 A 붙여넣기
에디터, 터미널, 어디서든 함수, 파일, 스니펫의 옛 버전을 복사합니다. Ctrl+C 후 왼쪽 패널에 붙여 넣으세요.
git show <commit>에서 가져온다면, patch 헤더가 아니라 파일 본문을 복사해야 diff가 실제 코드 변경만 강조합니다. - 2
오른쪽에 버전 B 붙여넣기
새 버전도 같은 방식으로. 동료가 Slack, Teams, 메일에 붙여 넣었다면 거기서 바로 복사하세요. 공백과 들여쓰기는 붙여 넣을 때 보존되며, Python과 YAML처럼 들여쓰기가 의미를 가지는 언어에서 중요합니다. 두 스니펫에서 탭과 스페이스가 다르면 차이로 표시됩니다.
- 3
강조된 차이 살펴보기
삭제는 왼쪽에 빨간 취소선, 삽입은 오른쪽에 초록색으로 표시됩니다. 각 헤더의 변경 카운터는 감지된 별개 편집의 수를 알려줍니다. 강조 표시를 읽으면서 로직 변경(제어 흐름, 조건문, 오류 처리)을 먼저 확인하고, 단순 이름 변경이나 포맷 변경은 리뷰에서 우선순위를 낮게 두세요.
온라인 코드 diff가 옳은 선택일 때
빌드 스크립트의 두 버전 비교
CI 파이프라인, Dockerfile, package.json, GitHub Actions 워크플로 YAML은 항상 변합니다. 팀원이 브랜치에서 .github/workflows/ci.yml을 수정해 빌드가 깨졌고, 그 사람의 브랜치를 checkout하지 않고 무엇이 바뀌었는지 보고 싶습니다. main 버전과 깨진 브랜치 버전을 나란히 붙여 넣으면, 문제의 step이 보통 몇 초 안에 떠오릅니다. 워크플로 파일 특유의 들여쓰기 엣지 케이스는 저희 YAML diff 페이지가 더 깔끔하게 처리합니다.
비엔지니어에게 PR에서 무엇이 바뀌었는지 보여주기
프로덕트 매니저, 디자이너, 어카운트 매니저는 가끔 Git 인터페이스를 읽지 않고도 코드 변경의 의미를 알아야 합니다. GitHub PR 뷰는 diff 문법, 파일 트리, 리뷰 코멘트에 대한 친숙함을 전제합니다. 깔끔한 두 패널 뷰에 변경 전후를 붙여 넣고 강조 표시를 함께 따라가는 편이 훨씬 친절합니다. 청중에 엔지니어링 외부 인원이 포함된 인시던트 포스트모템에서도 유용합니다.
두 커밋의 git show 출력 비교
어떤 파일에 대해 두 커밋의 git show abc123과 git show def456 출력이 있다고 합시다. CI 로그나 git 명령을 쉽게 실행할 수 없는 원격 샌드박스에서 가져온 것일 수 있습니다. patch 헤더를 떼고 두 파일 내용을 붙여 넣어 diff합니다. 서버에서 디버깅할 때, 빌드 산출물을 읽을 때, 특정 두 커밋의 파일 내용을 인용한 보안 권고를 검토할 때 잘 동작합니다.
메일이나 PDF에 들어 있는 코드 리뷰
벤더가 PDF로 샘플 통합 코드를 보냅니다. 규제 기관이 정책 코드 스니펫을 메일로 보냅니다. 컨설턴트가 패치한 스크립트 버전을 첨부합니다. 어느 것도 clone 가능한 repo가 아닙니다. PDF나 메일에서 텍스트를 복사해 현재 버전 옆에 붙여 넣으면 1분 안에 사용 가능한 리뷰 화면이 됩니다. PDF 복사-붙여넣기는 어느 정도의 포맷 잡음을 동반합니다. 줄바꿈과 따옴표가 흔한 범인입니다.
알아둘 만한 코드 diff 엣지 케이스
평문 텍스트 diff가 Git, IDE, 코드 리뷰 도구가 보여주는 것과 일치하지 않는 경우들. 운영 코드를 붙여 넣고 거짓 양성에 신경 쓰기 전에 한 번 훑어볼 가치가 있습니다.
| Topic | What this tool does |
|---|---|
| 줄 끝(CRLF vs LF) | Windows 스타일 CRLF와 Unix 스타일 LF는 다른 바이트입니다. Windows 에디터에서 붙여 넣은 파일과 Linux 컨테이너에서 붙여 넣은 파일은, 보이는 텍스트가 같아도 줄 끝이 다르면 파일 전체 diff로 표시됩니다. Git은 core.autocrlf로 정규화하지만 이 도구는 그렇지 않습니다. |
| 행 끝 공백 | 행 끝의 스페이스나 탭은 차이로 표시됩니다. Git의 core.whitespace는 커밋 시 경고하거나 자동 수정할 수 있지만, 여기서는 붙여 넣은 그대로가 비교 대상입니다. 코드 리뷰의 잡음 바닥이 행 끝 공백 변경으로 가득하다면, diff 전에 에디터에서 제거하세요. |
| 바이너리 파일 | 이 도구는 텍스트 전용입니다. 바이너리 파일(PNG, 컴파일된 JAR, sqlite DB)의 내용을 붙여 넣으면 의미 없는 결과가 나오거나 탭이 멈춥니다. 바이너리 diff에서 Git은 patch 대신 "Binary files differ"를 표시합니다. 실제 내용에는 형식별 도구가 필요합니다. |
| .gitattributes의 text vs binary 표시 | 저장소의 .gitattributes는 파일 패턴별로 Git의 텍스트/바이너리 판정을 덮어쓸 수 있습니다. 그 설정은 복사-붙여넣기로 따라오지 않습니다. 두 checkout에서 어떤 파일이 다르게 다뤄진다고 의심된다면 그 파일을 봐야 합니다. 이 도구는 어차피 평문 텍스트로 diff합니다. |
| 문자 단위 vs 행 단위 diff | 이 페이지는 시맨틱 클린업이 적용된 문자 수준 diff를 씁니다. Git은 기본 행 단위, 옵션으로 git diff --word-diff가 단어 단위입니다. 문자 단위는 단일 토큰만 바뀐 짧은 스니펫에, 행 단위는 많은 줄이 한꺼번에 바뀐 긴 파일에 가장 잘 맞습니다. |
| git diff --word-diff | Git의 --word-diff 모드는 한 줄 안의 단어 수준 변경을 강조하며, 스니펫에 대한 이 도구의 동작에 더 가깝습니다. 출력 형식은 다릅니다(터미널 친화적 마크업 vs side-by-side 패널). 그러나 의도는 겹칩니다. 터미널에서 산다면 --word-diff가 로컬에서의 같은 역할입니다. |
| 큰 파일 임계값 | 브라우저 기반 diff는 한쪽 수천 줄까지는 반응이 좋습니다. 그 이상이면 시맨틱 클린업이 느려지고 렌더된 DOM이 무거워집니다. 거대한 파일이라면 로컬에서 git diff를 실행해 pager에 흘리거나, 비교를 더 작은 구간으로 쪼개세요. |
| 인코딩(UTF-8 전용) | diff는 UTF-8 입력을 가정하며, 2026년 시점에서 거의 모든 소스 코드가 이에 해당합니다. UTF-16, Windows-1252, Shift-JIS로 저장된 파일은 브라우저에 따라 붙여 넣을 때 깨져 보일 수 있습니다. 스니펫이 깨져 보이면 복사하기 전에 원본 파일을 UTF-8로 다시 저장하세요. |
온라인 git diff: 자주 묻는 질문
로컬에서 git diff를 실행하는 것과 무엇이 다른가요?
로컬 git diff는 실제 저장소 안에서 두 ref(커밋, 브랜치, working tree)를 비교합니다. 인덱스, worktree, 히스토리를 알고 있습니다. 이 온라인 도구는 그런 일을 하지 않습니다. 사용자가 붙여 넣은 임의의 두 텍스트 블록을 비교합니다. checkout한 저장소에서 본격적인 리뷰를 할 때는 git diff를 쓰세요. 두 스니펫이 있고 working tree로 들이기 마땅치 않거나, 컨텍스트 전환 없이 side-by-side 뷰를 원할 때는 이 도구를 쓰세요.
GitHub나 GitLab이 PR에서 보여주는 것과 일치하나요?
정확히는 아닙니다. GitHub와 GitLab은 파일 컨텍스트, hunk 헤더, 파일별 요약을 갖춘 행 기반 unified diff를 사용합니다. 이 도구는 시맨틱 클린업이 더해진 문자 수준 diff를 사용합니다. 짧은 스니펫에는 더 좋고, 변경이 많은 파일 전체에는 덜 적합합니다. 본격적인 풀 리퀘스트 리뷰는 GitHub PR 뷰에서 하세요. PR 외부에서의 빠른 스니펫 비교에는 이 도구가 더 빠르고 올바른 repo로 이동할 필요도 없습니다.
JavaScript, Python 등의 문법을 이해하나요?
아니요. 이것은 평문 텍스트 diff입니다. 언어를 파싱하지 않으므로 이름이 바뀐 변수가 12군데에서 같은 식별자임을 알지 못하고, 문법 인식 diff처럼 재포맷된 공백을 무시할 수도 없습니다. 대부분의 스니펫 리뷰에서는 이 정도로 충분합니다. 강조 표시를 본인의 두뇌로 읽기 때문입니다. 코드에 대한 진짜 시맨틱 diff가 필요하다면 IDE(VS Code, IntelliJ)나 tree-sitter 기반 diff가 적절한 도구입니다. 이 페이지는 속도를 최적화하며, 깊은 파싱이 목표가 아닙니다.
unified 형식 diff -u와 비교하면 어떤가요?
고전적인 Unix 명령어 diff -u는 unified 형식의 patch를 만듭니다(Git이 내부에서 쓰는 것과 같은 형식). 행 기반이고, patch를 다른 곳에 적용할 수 있도록 기계 가독성을 염두에 두고 설계되었습니다. 이 도구는 사람이 읽기 좋게 만들어졌습니다. 더하기와 빼기 줄이 한 열로 늘어선 대신, 인라인 강조가 있는 두 패널을 나란히 보여줍니다. git apply나 patch -p1로 적용할 수 있는 patch 파일은 만들지 않습니다. patch를 만들어야 한다면 명령줄을 쓰세요. diff를 읽어야 한다면 이쪽이 더 친절합니다.
줄 끝 처리와 행 끝 공백을 다루나요?
네, 단 자체적인 방식으로. CRLF(Windows)와 LF(Unix) 줄 끝은 두 스니펫이 일치하지 않으면 차이로 표시됩니다. 기술적으로 다른 바이트이기 때문입니다. 행 끝 공백도 마찬가지. 이는 core.autocrlf가 꺼진 상태에서 Git이 파일을 다루는 방식과 일치합니다. 공백이 아니라 로직 변경에만 관심이 있다면, 붙여 넣기 전에 각 패널을 trim하세요. 현재 "공백 무시" 토글은 제공하지 않지만 로드맵에 있습니다. 로컬에서는 git diff -w가 같은 역할을 합니다.
용량 제한이 있나요?
사실상 있습니다. diff는 브라우저에서 동작하므로, 매우 큰 입력(통째로 vendor된 라이브러리나 50,000행 생성 파일)은 브라우저 메모리에 따라 페이지를 느리게 하거나 탭을 멈추게 합니다. 일반적인 코드 리뷰 작업(함수, 파일, 빌드 스크립트, 한쪽 수천 줄까지의 설정)이라면 diff는 사실상 즉시 끝납니다. 저장소 전체를 비교해야 한다면 진짜 Git 도구나 폴더 비교 도구가 정답입니다. 이 페이지는 스니펫과 단일 파일을 위해 만들어졌습니다.
개인정보와 동작 방식
코드는 브라우저 밖으로 나가지 않습니다. diff, 강조 표시, 렌더링은 모두 사용자의 컴퓨터에서 동작합니다. 텍스트를 업로드하지도, 로깅하지도, 어떤 제3자 서비스에 전달하지도 않습니다. 이는 사내 코드 리뷰에서 특히 중요합니다. 미공개 기능, 보안 패치, private repo 스니펫을 클라우드 서비스에 붙여 넣는 것 자체가 회사의 데이터 처리 정책 위반이 될 수 있기 때문입니다. 검증은 간단합니다. 브라우저 DevTools를 열고 Network 탭으로 전환한 뒤 두 버전을 붙여 넣으면서 지켜보세요. 비교 시 외부로 나가는 요청은 없습니다. 동일한 개인정보 모델은 다른 도구들에도 적용됩니다. compare-text, compare-json, compare-yaml이 그 예입니다. 코드 리뷰는 리뷰 대상이 신뢰할 수 있을 때 가장 잘 동작합니다.