화면과 종이는 다른 매체입니다
마크다운으로 잘 정리한 문서를 워드나 PDF로 내보내면 예상과 다른 결과가 나오는 일이 잦습니다. 표가 오른쪽에서 잘리고, 코드 한 줄이 페이지 밖으로 나가고, 제목이 페이지 맨 아래에 혼자 남습니다.
원인은 하나입니다. 마크다운은 "이건 제목이다, 이건 목록이다"라는 구조만 말하고, 그걸 어떻게 배치할지는 정하지 않습니다. 화면에서는 브라우저가 폭에 맞춰 알아서 흘려주지만, 워드와 PDF에는 고정된 종이 크기와 페이지 경계가 있습니다. 흘려보낼 곳이 없으니 잘리거나 넘칩니다.
무엇이 어떻게 깨지는지 미리 알면 대부분 피할 수 있습니다.
1. 표 — 가장 자주 잘립니다
마크다운 표는 열 개수에 제한이 없습니다. 화면에서는 가로 스크롤이 생기거나 글자가 줄어들며 어떻게든 보이지만, A4 폭은 늘어나지 않습니다.
열이 5개를 넘으면 위험하다고 생각하시면 됩니다. 특히 URL이나 긴 영문 식별자가 든 칸은 줄바꿈이 안 되어 열 하나가 폭을 독차지합니다.
대응은 이렇습니다.
- 열 수를 줄이거나 표를 둘로 나눕니다
- 긴 주소는 표 안에 넣지 말고 각주나 본문으로 뺍니다
- 정말 넓어야 한다면 가로 방향(가로 용지)으로 설정합니다
- 내보낸 뒤 워드에서 표를 선택해 "창에 자동 맞춤"을 한 번 실행합니다
표 자체를 언제 쓰고 언제 다른 구조로 바꿀지는 표 작성 가이드에 정리해두었습니다.
2. 코드 블록 — 긴 줄이 사라집니다
코드 블록은 줄바꿈을 하지 않는 것이 원칙입니다. 코드에서 줄바꿈은 의미를 바꿀 수 있기 때문입니다. 화면에서는 가로 스크롤로 처리되지만, 종이에는 스크롤이 없어서 오른쪽이 그냥 잘립니다.
명령어 한 줄이 긴 경우가 특히 위험합니다. 옵션이 잔뜩 붙은 명령을 그대로 넣으면 절반만 인쇄되고, 받아 본 사람은 잘렸다는 사실조차 모릅니다.
- 한 줄을 80자 안쪽으로 유지하세요
- 긴 명령은 백슬래시(
\)로 줄을 나눠 적습니다 - 들여쓰기가 깊은 코드는 앞부분을 덜어냅니다
문법 강조 색은 대체로 사라집니다. 워드로 변환할 때 색까지 옮기는 도구는 드물고, PDF는 브라우저 인쇄 설정에서 배경 그래픽을 켜야 코드 블록의 회색 배경이라도 남습니다. 색이 없어도 읽히도록 언어를 명시하고 주석을 충분히 달아두는 편이 안전합니다.
3. 접기(details) — 통째로 빠집니다
가장 조용하고 가장 위험한 문제입니다. 접기/펼치기로 감싼 내용은 접힌 상태에서는 화면에 그려지지 않습니다. 그리고 인쇄와 PDF는 화면에 그려진 것만 가져갑니다.
즉 접어둔 내용은 결과물에서 사라집니다. 오류도 경고도 없이 그냥 없어집니다. 문서를 제출했는데 절반이 비어 있는 사고가 여기서 나옵니다.
PDF로 만들 문서에는 접기를 쓰지 마세요. 꼭 써야 한다면 <details open>으로 펼친 상태를 기본값으로 두고, 내보내기 전에 모두 펼쳐졌는지 눈으로 확인하세요.
4. 이미지 — 페이지를 넘어갑니다
마크다운의 기본 이미지 문법에는 크기 지정이 없어 원본 크기가 그대로 들어갑니다. 요즘 스크린샷은 가로 2000~3000px이 예사라, 그대로 내보내면 이미지 하나가 페이지를 통째로 차지하거나 잘립니다.
- 내보내기 전에 이미지 크기를 지정하세요
- 세로로 긴 이미지는 페이지 경계에서 잘리기 쉬우니 나눠 넣습니다
- 이미지 아래에 짧은 설명을 달아두면, 잘리거나 흐려져도 무슨 그림이었는지 전달됩니다
상대 경로로 넣은 이미지()는 변환 도구가 파일을 찾지 못하면 빈 칸이나 깨진 아이콘으로 나옵니다. 내보낸 파일을 열어 이미지가 다 들어갔는지 반드시 확인하세요.
5. 링크 — 주소를 알 수 없게 됩니다
[사용 설명서](https://example.com/docs)는 화면에서는 클릭하면 되지만, 종이에 인쇄되면 "사용 설명서"라는 파란 글자만 남습니다. 읽는 사람은 그 주소를 알 방법이 없습니다.
PDF로 남길 문서라면 링크가 클릭 가능한 상태로 유지되는 경우가 많지만, 인쇄해서 돌려볼 문서라면 중요한 주소는 본문에 그대로 적어두는 편이 낫습니다.
자세한 내용은 사용 설명서(https://example.com/docs)를 참고하세요.
6. 체크리스트
- [ ] 문법은 GitHub 계열의 확장이라, 변환 도구가 이해하지 못하면 대괄호가 그대로 나옵니다. 회의록의 액션 아이템을 체크리스트로 정리해 워드로 제출할 때 자주 걸립니다.
제출용 문서라면 애초에 체크박스 대신 담당자와 기한을 적은 표나 목록으로 정리하는 편이 낫습니다. 종이 위의 체크박스는 어차피 클릭할 수 없습니다.
PDF는 사실 '인쇄'입니다
여기서 한 가지 짚고 갈 것이 있습니다. 웹 도구에서 PDF로 내보내는 기능은 대부분 브라우저의 인쇄 기능을 거칩니다. 이지 마크다운의 PDF 내보내기도 인쇄 창을 열고, 거기서 "PDF로 저장"을 고르는 방식입니다.
그래서 인쇄에서 생기는 문제가 그대로 따라옵니다.
페이지 나눔이 아무 데서나 일어납니다. 제목이 페이지 맨 아래에 혼자 남고 내용은 다음 장에서 시작하거나, 표가 두 장에 걸쳐 잘리거나, 코드 블록이 중간에서 끊깁니다. 마크다운에는 "여기서 페이지를 넘겨라"라고 지시하는 문법이 없어서 미리 제어할 수가 없습니다.
배경색이 기본적으로 빠집니다. 인쇄 설정에 "배경 그래픽" 옵션이 따로 있고, 켜지 않으면 코드 블록과 인용구의 배경이 흰색으로 나옵니다. 켜는 걸 권합니다.
여백과 배율을 조절할 수 있습니다. 표가 살짝 넘칠 때는 인쇄 창에서 배율을 90%로 낮추거나 여백을 좁히면 한 장에 들어가는 경우가 많습니다. 문서를 고치기 전에 여기부터 시도해보세요.
워드와 PDF, 어느 쪽으로 낼까
| 워드(.docx) | ||
|---|---|---|
| 받는 사람이 고칠 수 있나 | 고칠 수 있음 | 사실상 못 고침 |
| 보이는 모양이 유지되나 | 환경에 따라 달라짐 | 그대로 유지됨 |
| 표·이미지 위치 조정 | 받은 뒤 직접 가능 | 불가 |
| 적합한 경우 | 함께 편집할 초안, 사내 양식 | 최종본, 대외 제출, 보관 |
함께 고쳐야 하면 워드, 최종본이면 PDF가 기본입니다. 워드는 열어본 사람의 글꼴 설정에 따라 줄 수가 달라질 수 있어 "몇 페이지짜리"가 보장되지 않습니다. 분량이 정해진 제출물이라면 PDF가 안전합니다.
내보내기 전 확인 목록
문서를 내보내기 직전에 이것만 훑어도 대부분의 사고가 걸러집니다.
- 접어둔 내용이 있는가 — 있다면 모두 펼칩니다
- 표의 열이 5개를 넘는가 — 나누거나 가로 용지를 검토합니다
- 코드 블록에 80자 넘는 줄이 있는가 — 나눕니다
- 이미지 크기를 지정했는가 — 안 했다면 지정합니다
- 중요한 링크의 주소가 본문에 있는가 — 인쇄용이라면 적어둡니다
- 내보낸 파일을 실제로 열어봤는가 — 이게 가장 중요합니다
마지막 항목을 건너뛰는 경우가 정말 많습니다. 변환은 조용히 실패하기 때문에, 결과 파일을 처음부터 끝까지 한 번 넘겨보는 것이 유일하게 확실한 확인 방법입니다.
마무리
마크다운으로 쓰고 워드·PDF로 내는 흐름은 편리하지만, 두 매체의 전제가 다르다는 걸 잊으면 마지막 단계에서 사고가 납니다. 화면에는 무한한 폭과 스크롤이 있고 종이에는 없습니다.
작성 단계에서 "이 문서는 결국 종이로 나간다"를 염두에 두면 표를 좁게 잡고 코드 줄을 짧게 쓰게 됩니다. 그것만으로도 대부분 해결됩니다. 업무 문서를 마크다운으로 쓰는 전반적인 방법은 업무 문서 작성 글에, 회의록·README 같은 구체적인 작업 순서는 활용 사례에 정리해두었습니다.