두 Markdown 문서를 붙여넣고 줄 단위로 무엇이 바뀌었는지 확인하세요. README 파일, 릴리스 노트, MDX, frontmatter가 있는 문서 모두에 사용할 수 있습니다. 비교는 브라우저에서 실행됩니다.
두 Markdown 문서를 소스 텍스트 수준에서 비교하는, 브라우저에서 동작하는 무료 도구입니다. 왼쪽에 이전 README.md를, 오른쪽에 갱신본을 붙여넣으면 바뀐 제목, 목록 항목, 링크, 코드 블록, 표 셀이 모두 표시됩니다. 어떤 데이터도 사용자의 기기를 떠나지 않습니다.
비교는 문자 단위로 이루어집니다. Markdown은 일반 텍스트이므로 이 방식이 올바른 기본 단위입니다. 렌더러가 어떻게 해석할지에 대한 추측이 아니라, 문서 소스의 실제 변경을 그대로 봅니다.
일반 산문 비교에 우리의 텍스트 비교를 이미 쓰고 있다면, Markdown 페이지는 같은 엔진에 문서를 실제로 작성할 때 마주치는 사례에 맞춘 설명을 담았습니다. Jekyll, Hugo, MkDocs 파일 상단의 YAML frontmatter 블록을 비교한다면, 들여쓰기에 민감한 구조는 YAML 페이지가 더 잘 다룹니다. 키/값 조회가 필요한 엄격한 구조화 데이터는 JSON 비교가 적합합니다.
비교는 문자 수준에서 이루어집니다. 원시 비교 후, 의미 정리 단계가 하이라이트를 단어 전체, 목록 항목, 링크 대상 등에 맞도록 옮겨, 인라인 `code span`을 한가운데서 자르거나 제목 앞의 ##를 본문에서 분리하지 않게 합니다. 추가는 오른쪽에 초록, 삭제는 왼쪽에 빨강으로 표시됩니다.
이는 렌더링된 출력이 아니라 소스 텍스트의 비교입니다. Markdown 작업에는 이게 올바른 기본 단위이며, 보이는 것보다 더 중요합니다. 같은 HTML로 렌더링되는 두 문서가 매우 다른 소스를 가질 수 있습니다. **bold**와 __bold__, * 글머리표와 - 글머리표, 중첩 목록의 4-스페이스 들여쓰기와 탭 등입니다. 렌더러는 이를 같은 출력으로 평탄화해서 신호를 잃게 만듭니다. 기여자가 정말 오타만 고쳤는지 알고 싶을 때 답을 주는 것이 소스 비교입니다.
Markdown은 또한 방언의 가족입니다. John Gruber의 원 명세(daringfireball.net)는 의도적으로 느슨했고, 시간이 지나면서 CommonMark, GitHub Flavored Markdown, Pandoc, MultiMarkdown이 각자 다른 방향으로 발전했습니다. 표는 GFM과 Pandoc에는 있지만 CommonMark에는 없습니다. ~~로 쓰는 취소선과 - [ ]로 쓰는 작업 목록은 GFM 확장입니다. 비교 도구는 어떤 방언을 쓰든 신경 쓰지 않고 원시 텍스트를 보여줍니다. 방언이 문제가 되는 시점은 새 문서 테마에서 단락이 여전히 잘 렌더링되는지를 묻기 시작할 때이며, 그것은 비교가 아니라 렌더러의 영역입니다.
텍스트 패널 두 개, 비교 하나. 가입 없음, 업로드 없음, 서버 왕복 없음.
왼쪽에 이전 버전, 오른쪽에 새 버전을 붙여넣으세요. 또는 어느 패널이든 업로드를 눌러 .md, .markdown, .mdx 파일을 불러옵니다. 예시 버튼을 누르면 양쪽에 작은 README 예제가 채워져 자신의 콘텐츠를 붙여넣기 전에 비교 동작을 확인할 수 있습니다.
Windows에서 편집한 파일은 보통 CRLF 줄 끝을, Linux 서버에서 온 파일은 LF를 사용합니다. 문자 비교는 이를 다른 것으로 처리해 모든 줄이 바뀐 것처럼 칠해질 수 있습니다. 비교 결과가 의심스러울 정도로 빨강과 초록으로 가득하면, 먼저 에디터에서 두 파일을 같은 줄 끝 문자로 통일하세요. VS Code는 하단 상태표시줄에 현재 줄 끝을 표시합니다.
삭제는 왼쪽에 빨강, 추가는 오른쪽에 초록으로 표시됩니다. 두 패널은 함께 스크롤됩니다. frontmatter 블록, 코드 펜스, 표의 행, 목록 항목 모두 비교 엔진에는 그저 텍스트이므로 그 안의 변경도 본문 변경과 동일한 방식으로 드러납니다. 각 헤더의 변경 개수로 편집의 무게를 빠르게 가늠할 수 있습니다.
PR 브랜치의 README.md가 main과 비교해 무엇이 바뀌었는지 빠르게 보고 싶습니다. 그렇다고 GitHub를 열고 렌더링 미리보기를 지나 메뉴 세 단계 깊은 곳의 "Display the source diff"를 누르고 싶지는 않습니다. 그럴 때는 두 원본 파일을 이 도구에 붙여넣으세요. 제목, 코드 펜스, 링크 대상이 모두 명확히 드러납니다. PR이 백 개의 소스 파일도 함께 건드려 문서 변경이 잡음에 묻혔을 때 특히 유용합니다.
릴리스 노트는 출시까지 여러 차례 수정됩니다. 초안이 재배열되고, 항목이 합쳐지고, 버전 번호가 바뀝니다. 이전에 게시된 RELEASE_NOTES.md와 새 초안을 비교하면 빠진 항목과 우연한 중복을 잡을 수 있고, 비슷한 줄 위로 시선이 미끄러지는 렌더링 미리보기는 이런 일에 약합니다. ## Breaking changes 섹션이 버전 사이에 정말 늘었는지 확인하기에도 좋습니다.
팀은 Git 저장소에 Markdown으로 문서를 작성하지만, 공개 사이트는 MkDocs, Hugo, Docusaurus 같은 CMS나 정적 사이트 생성기로 만듭니다. 가끔 게시된 페이지가 소스에서 어긋납니다. 누군가 CMS UI에서 라이브 페이지를 직접 수정하고 다시 푸시하지 않았거나, CI 단계가 파일을 다시 썼을 수 있습니다. 게시된 페이지를 Markdown으로 내보내 한 패널에, 저장소의 .md를 다른 패널에 두면 어긋남이 몇 초 만에 눈앞에 드러납니다.
Markdown으로 블로그 글을 편집자에게 보냈고, 편집자가 표시가 들어간 버전을 돌려줬습니다. 두 버전을 비교하는 편이 단락별로 다시 읽는 것보다 피드백을 훨씬 빠르게 흡수합니다. 편집자가 섹션 순서를 바꾸거나 도입부를 다시 썼을 때 더 그렇습니다. 작가가 편집 과정을 거쳐 자기 목소리의 어떤 손질이 살아남았는지 확인해야 하는 대필 작업에서도 똑같이 잘 동작합니다.
Docusaurus나 Astro 사이트를 .md에서 .mdx로 옮기는 일은 무해해 보일 수 있지만, 일부 import가 옮겨졌고, 평범한 Markdown 표를 JSX 컴포넌트가 대체했으며, 몇몇 코드 펜스가 사용자 정의 컴포넌트로 감싸졌다는 사실을 발견하게 됩니다. 옛 page.md와 새 page.mdx를 파일 단위로 비교하면 마이그레이션의 선택을 검토할 수 있습니다. MDX가 잘못된 선택이라 결정해 일반 Markdown으로 돌아갈 때도 같은 흐름이 반대로 작동합니다.
이 도구가 가장 자주 드러내는 문법 경계 사례를 짧게 정리한 표입니다. 방언 열은 해당 기능을 실제로 지원하는 방언을 알려줍니다. 렌더러 간의 놀라움은 대부분 여기에서 비롯되기 때문입니다.
| Topic | What this tool does |
|---|---|
| 방언 간 차이 | Markdown은 가족입니다. CommonMark가 사실상의 기준선입니다. GFM은 표, 작업 목록, 취소선, 자동 링크를 더합니다. Pandoc과 MultiMarkdown은 각주, 정의 목록 등을 더합니다. 같은 소스라도 이들 사이에서 매우 다르게 렌더링될 수 있습니다. |
| 표 | 파이프 구분 표는 GFM과 Pandoc에 존재합니다. CommonMark나 원래 Markdown의 일부는 아닙니다. 렌더러가 셀이 아니라 | 문자를 그대로 출력한다면, 파서가 CommonMark 엄격 모드이며 GFM 호환 파서가 필요합니다. |
| 취소선 | ~~text~~는 GFM 확장입니다. 원래 Markdown과 CommonMark는 지원하지 않습니다. Pandoc은 strikeout 확장을 켜면 지원합니다. 텍스트가 물결표 그대로 렌더링된다면 렌더러가 GFM을 인식하지 못하는 것입니다. |
| 작업 목록 | - [ ] todo와 - [x] done은 GFM 확장입니다. CommonMark에서는 그저 글머리표로 대괄호가 그대로 보입니다. GitHub, GitLab, 그리고 대부분의 현대 문서 사이트는 지원하지만, 일반 Markdown 처리기는 보통 지원하지 않습니다. |
| 코드 블록: 펜스 vs 들여쓰기 | 펜스 코드 블록(삼중 백틱이나 물결표, 선택적 언어 태그 포함)은 CommonMark이며 어디서나 지원됩니다. 원래 Markdown 명세에는 4-스페이스 들여쓰기 코드 블록만 있었고 여전히 동작하지만 언어 힌트를 담을 수 없습니다. 한 파일에서 둘을 섞는 것은 합법이지만 지저분합니다. |
| 강제 줄바꿈 | 세 가지 선택지가 있습니다. 줄 끝에 두 개의 끝 공백을 넣기, 줄 끝에 백슬래시 \를 넣기(CommonMark와 GFM, 원래 명세는 아님), 단락 구분을 위한 빈 줄 넣기입니다. 끝 공백은 대부분의 에디터에서 보이지 않으므로, 강제 줄바꿈은 사람이 못 잡는 차이로 종종 살아남습니다. |
| frontmatter | 파일 맨 위의 --- 사이의 YAML, +++ 사이의 TOML, { } 사이의 JSON입니다. Markdown 명세에는 전혀 들어있지 않지만 Jekyll, Hugo, MkDocs, Docusaurus, Astro에서 어디서나 쓰입니다. 렌더러는 본문을 파싱하기 전에 이를 제거합니다. |
| 인라인 HTML | CommonMark는 Markdown 안에 원시 HTML 태그를 허용합니다. GFM도 허용하지만 github.com에서 렌더링할 때 HTML 새니타이저를 적용합니다. 어떤 정적 사이트 생성기는 정화하고, 어떤 것은 HTML을 그대로 통과시키며, 일부는 이스케이프합니다. <div>나 <iframe> 블록이 들어간 페이지 비교는 마이그레이션 감사에서 흔합니다. |
아니요. 이 도구는 Markdown 소스 텍스트를 비교하며, 렌더러가 만들어 낼 HTML을 다루지 않습니다. 의도된 동작입니다. 두 문서가 같은 HTML로 렌더링되더라도 의미 있는 차이가 소스에 남을 수 있습니다. 예를 들어 *와 -의 글머리표나 **와 __의 굵게 표시 같은 차이입니다. 소스 수준 비교는 이 신호를 보존합니다. 렌더링 결과가 보고 싶다면 평소 쓰는 미리보기 도구(GitHub 웹 UI, VS Code, 정적 사이트 생성기)에 붙여넣으세요.
렌더링된 HTML 비교는 독자가 보게 될 화면을 알려줍니다. 소스 비교는 파일에서 실제로 바뀐 부분을 알려줍니다. 답하는 질문이 다릅니다. Markdown에서는 소스 비교가 거의 항상 더 유용합니다. 작성자의 편집을 충실히 보여주기 때문입니다. 제목 수준이 ##에서 ###로 바뀌었거나, 코드 펜스의 언어 태그가 변경되었거나, 상대 링크가 절대 링크가 되었거나 같은 차이가 그대로 보입니다. HTML 수준 비교가 필요하다면 두 파일을 먼저 렌더러에 통과시키고 출력을 비교하세요.
비교 자체는 Markdown을 파싱하지 않으므로 어떤 방언인지 신경 쓰지 않습니다. 표, 작업 목록, 취소선, 자동 링크 같은 확장도 그저 텍스트로 보일 뿐입니다. 방언이 문제가 되는 시점은 문서가 여전히 올바르게 렌더링되는지를 물을 때입니다. CommonMark가 사실상 표준 기준에 가장 가깝고, GitHub Flavored Markdown은 CommonMark에 표, 작업 목록, 취소선, 자동 링크를 더한 것입니다. 대상 렌더러가 지원하는 쪽을 고르세요.
frontmatter는 파일 맨 위의 텍스트일 뿐이며, YAML은 ---, TOML은 +++로 둘러쌉니다. Hugo, Jekyll, MkDocs 같은 정적 사이트 생성기는 이를 페이지 메타데이터로 사용합니다. 비교 도구는 이 블록을 일반 텍스트로 보므로 title:, date:, tags:의 변경도 다른 줄과 같은 방식으로 표시됩니다. frontmatter가 크고 들여쓰기에 민감하다면 그 블록만 따로는 YAML 비교 페이지가 더 적합합니다.
네. MDX는 JSX 컴포넌트가 들어간 Markdown이며, JSX는 비교의 관점에서는 그저 추가된 텍스트일 뿐입니다. .mdx 파일을 어느 패널에든 붙여넣으면 import의 변경, 컴포넌트 prop의 변경, 주변 Markdown의 변경을 .md와 같은 방식으로 비교가 드러내 줍니다. 도구가 하지 않는 것은 JSX가 컴파일되는지 검증하는 일이며, 그것은 MDX 컴파일러의 몫입니다. JSX 부분만 코드로 검토하고 싶다면 텍스트 비교에 붙여넣으세요.
줄 끝 문자는 문자이므로 Windows 스타일 CRLF로 저장된 파일과 Unix 스타일 LF로 저장된 파일은 모든 줄에서 다르게 비교됩니다. 패널이 유령 같은 변경으로 가득 차 보인다면 거의 항상 이 때문입니다. 해결 방법은 붙여넣기 전에 두 파일을 같은 줄 끝 문자로 통일하는 것입니다. VS Code에서는 하단 상태표시줄에 현재 줄 끝이 표시되며 클릭 한 번으로 바꿀 수 있습니다. Git의 core.autocrlf 설정도 머신마다 예기치 않은 CRLF 차이를 만들 수 있습니다.
당신의 Markdown은 브라우저를 떠나지 않습니다. 에디터, 비교, 포매터 모두 사용자의 기기에서 동작합니다. 입력에 대한 분석도, 로그도, 서버 왕복도 없습니다. 형식 자체에 대한 배경 자료는 Wikipedia에 있고, 최신 CommonMark 명세는 spec.commonmark.org/0.31.2, GitHub 방언은 github.github.com/gfm에 있습니다.