이미지 워터마크는 한글이 안 깨지는데 PDF 워터마크는 왜 깨지나
같은 "워터마크 추가"라는 이름의 도구인데 결과는 정반대입니다. 이미지 워터마크에 "저작권 © 홍길동"이라고 입력하면 한글이 그대로 찍히지만, PDF 워터마크에 똑같은 문구를 넣으면 빈 사각형(□) 몇 개만 남습니다. 두 도구 다 브라우저 안에서 즉석으로 처리되는데 왜 결과가 다를까요. 원인은 텍스트를 "그리는 방식" 자체가 완전히 다르기 때문입니다.
1. 이미지 워터마크: 브라우저가 이미 알고 있는 글자를 그대로 그린다
이미지 워터마크 도구는 Canvas 2D API의 fillText() 메서드로 이미지 위에 텍스트를 직접 그립니다. 실제 코드를 보면 ctx.font = size + 'px "Noto Sans KR", sans-serif' 형태로 폰트를 지정하는데, 이 'Noto Sans KR'은 페이지 상단에서 Google Fonts로 이미 불러온 웹폰트입니다. 즉 브라우저는 이 폰트 파일 안에 한글 11,172개 음절 글리프가 전부 들어있다는 것을 이미 알고 있는 상태이고, fillText는 그 글리프를 화면 좌표에 그대로 찍기만 하면 됩니다. 브라우저 렌더링 엔진 입장에서 한글이든 영문이든 이모지든 특별할 게 없는 동일한 처리입니다.
2. PDF 워터마크: 파일 안에 폰트를 아예 담지 않는 게 원칙
반면 PDF는 완전히 다른 규칙으로 동작합니다. PDF 규격(ISO 32000)은 Helvetica, Times-Roman, Courier 등 14종의 "표준 14개 폰트(Standard 14 Fonts)"를 정의하는데, 이 폰트들의 핵심은 PDF 파일 안에 폰트 데이터를 아예 넣지 않아도 된다는 점입니다. Acrobat이든 브라우저 내장 뷰어든 프린터 드라이버든, PDF를 여는 모든 프로그램이 이 14개 폰트를 자체적으로 갖고 있다고 규격 자체가 못박아 놨기 때문입니다. 그래서 이 도구는 pdfDoc.embedFont(StandardFonts.HelveticaBold) 한 줄로 폰트 파일 로드 없이 바로 텍스트를 그립니다.
3. 문제는 그 14개 폰트가 전부 라틴 문자 전용이라는 것
표준 14개 폰트는 WinAnsiEncoding 기반 인코딩표를 쓰는데, 여기 담긴 글리프는 서유럽 라틴 알파벳·숫자·기호뿐입니다. 한글 음절(11,172자), 한자, 가나 글리프는 이 14개 폰트 안에 애초에 존재하지 않습니다. 이미지 워터마크가 "이미 로드된 웹폰트에서 글자를 찾아 그리는" 방식이라면, PDF 워터마크는 "파일 안에 없는 글자를 그려달라고 요청받은" 상태가 되는 겁니다. 렌더러가 대응하는 글리프를 못 찾으면 빈 사각형이나 깨진 문자로 대체되는데, 이건 폰트가 손상된 게 아니라 애초에 그릴 방법이 없어서 생기는 현상입니다.
| 항목 | 이미지 워터마크 | PDF 워터마크 |
|---|---|---|
| 텍스트 렌더링 API | Canvas 2D fillText() | pdf-lib drawText() |
| 사용 폰트 | Noto Sans KR (웹폰트, 이미 로드됨) | Helvetica Bold (PDF 표준 14폰트) |
| 한글 글리프 포함 여부 | 포함 (11,172자 전체) | 미포함 (라틴 문자만) |
| 한글 입력 시 결과 | 정상 표시 | 빈 사각형(□) |
| 추가 조치 필요 여부 | 불필요 | 필요 (폰트 임베딩) |
4. PDF에서 한글을 살리려면: 폰트를 통째로 파일에 심어야 한다
PDF에서 한글을 실제로 렌더링하려면 Noto Sans KR 같은 한글 글리프가 포함된 TTF/OTF 폰트 파일 자체를 PDF 안에 임베딩해야 합니다. pdf-lib 생태계에서는 @pdf-lib/fontkit이라는 별도 라이브러리로 pdfDoc.registerFontkit(fontkit)을 등록한 뒤, pdfDoc.embedFont(fontBytes)로 실제 폰트 파일 바이트를 통째로 심습니다. 이렇게 만든 PDF는 어떤 기기에서 열어도 한글 글리프를 자체 보유한 자기완결적 파일이 되지만, 표준 폰트만 쓸 때보다 코드도 복잡해지고 파일 용량도 늘어나는 트레이드오프가 생깁니다. 이 사이트의 PDF 워터마크 도구는 가볍고 빠른 동작을 위해 이 임베딩 과정을 구현하지 않은 상태이며, 자세한 배경은 PDF 워터마크 한글 폰트 가이드에서 다룹니다.
5. 그래서 실무에서는 어떻게 써야 하나
- 이미지에 저작권 표시·SNS 출처 표기를 남길 때: 이미지 워터마크는 한글·이모지 모두 문제없이 지원되므로 그대로 사용하면 됩니다.
- PDF에 한글 워터마크가 꼭 필요할 때: 현재 이 도구에서는 CONFIDENTIAL, DRAFT, SAMPLE처럼 영문 단어로 대체하는 게 가장 확실합니다. 표준 폰트로도 완벽하게 표시됩니다.
- PDF 원본이 이미지라면: 페이지를 이미지로 캡처·변환한 뒤 이미지 워터마크 도구로 한글을 넣는 우회 방법도 있습니다.
자주 묻는 질문
Q. 이미지 워터마크 도구는 왜 한글·이모지까지 다 되나요?
A. Canvas의 fillText가 이미 브라우저에 로드된 'Noto Sans KR' 웹폰트를 그대로 참조해서 그리기 때문입니다. 이 폰트에는 한글 음절 11,172자와 대부분의 이모지 글리프가 포함돼 있어 별도 처리 없이 표시됩니다.
Q. PDF 표준 14개 폰트는 왜 하필 라틴 문자만 담았나요?
A. PDF 규격이 1990년대 초 제정될 당시 국제 CJK(중일한) 문자셋까지 기본 내장 규격에 넣기엔 폰트 용량·라이선스 부담이 컸기 때문입니다. 그래서 라틴 문자만 뷰어에 기본 내장을 보장하고, 그 외 문자는 파일 작성자가 직접 폰트를 임베딩하도록 설계됐습니다.
Q. 폰트를 임베딩하면 PDF 용량이 얼마나 늘어나나요?
A. 폰트 파일 전체가 아니라 실제 사용한 글자만 골라내는 서브셋(subset) 임베딩을 하더라도, 표준 폰트(0바이트 추가)에 비해서는 수십KB~수백KB가 늘어날 수 있습니다. 워터마크처럼 짧은 문구라면 서브셋 임베딩으로 부담을 크게 줄일 수 있습니다.
Q. 중국어·일본어 워터마크도 PDF에서 같은 문제가 생기나요?
A. 네. 표준 14개 폰트는 한글뿐 아니라 한자, 가나를 포함한 CJK 문자 전반에 대해 동일한 한계를 가지므로 원리는 똑같습니다.