PDF를 HTML로 변환하는 방법 (깔끔한 웹 페이지 만들기)

PDF 파일을 HTML로 변환하려는 분께 솔직한 소식부터: 임의의 PDF를 깔끔하고 반응형인 HTML로 자동 변환해 주는 도구는 없습니다. PDF는 인쇄 형식입니다 — «이 글리프를 x=142, y=380에 놓아라»를 저장하지, «이건 제목이다»를 저장하지 않죠. HTML은 정반대입니다. 모든 변환은 두 철학 사이의 번역이고, 무언가는 항상 잃습니다.

그렇다고 어렵다는 뜻은 아닙니다. 실제로 필요한 게 무엇이냐 — 깨끗한 마크업인지, 빠른 일회성 결과물인지, 그냥 문서를 웹 페이지에 올리는 것인지 — 에 따라 방법을 골라야 한다는 뜻입니다. 세 가지 방법 모두와, 변환하지 말아야 할 경우까지 정리했습니다.

애초에 PDF를 웹 페이지로 왜 바꾸나요?

끊임없이 등장하는 세 가지 이유:

• SEO. 검색 엔진은 PDF도 색인하지만 진짜 HTML 페이지를 훨씬 높게 랭킹합니다: HTML에는 구조(제목, 링크, 대체 텍스트)가 있고, 더 빨리 로드되고, 모바일에서 동작합니다. PDF에 묻힌 콘텐츠는 대부분의 검색자가 결코 찾지 못하는 콘텐츠입니다.
• 접근성. 스크린 리더는 평균적인 태그 없는 PDF보다 시맨틱 HTML을 훨씬 잘 다룹니다. 모두에게 중요한 문서라면 HTML이 접근 가능한 형식입니다.
• 사용자 경험. 모바일에서 PDF 링크는 다운로드 → 다른 앱에서 열기 → 고정된 A4 레이아웃을 핀치 줌으로 확대. HTML 페이지는 그냥 읽힙니다.

방법 1 — 추출 후 재조립 (가장 깨끗한 마크업)

정말 아끼는 콘텐츠 — 사이트에 올릴 보고서, 가이드, 문서 — 라면 이 방법이 모든 자동 변환기를 이깁니다. PDF에서 원재료를 꺼내고 단순한 HTML을 직접 두르는 겁니다.

네, 수작업입니다. 하지만 결과물은 실제로 유지보수하고 싶은 HTML이고, 진짜 독자에게 갈 콘텐츠라면 그 정도 대가는 충분히 가치가 있습니다.

방법 2 — pdftohtml과 Calibre (커맨드라인파를 위해)

자동화를 원하고 지저분한 결과물을 감수할 수 있다면:

pdftohtml (Poppler 유틸리티의 일부, Linux/Mac에서 기본 설치돼 있거나 패키지 하나면 설치됩니다):

pdftohtml -s -noframes document.pdf output.html

-s 플래그는 페이지당 파일 하나 대신 연속된 HTML 문서 하나를 만듭니다. -c 플래그는 '복잡 모드'를 켜서 절대 위치 div로 레이아웃을 재현합니다 — 눈으로는 PDF에 더 가깝지만, 마크업은 표시용 외에는 쓸 수 없고 모바일에서 완전히 무너집니다.

Calibre (무료, 크로스플랫폼)는 PDF를 전자책처럼 다룹니다: Calibre 열기 → PDF 추가 → 변환 → HTMLZ 출력 선택. 단일 단의 텍스트 위주 PDF에서 가장 잘 동작하고, 다단 레이아웃에서는 자주 읽기 순서를 틀립니다.

유료 변환기(Adobe Acrobat Pro의 HTML 내보내기, 월 $6-20짜리 각종 온라인 서비스)는 표를 더 잘 다루고 서식을 더 많이 보존하지만, 출력물은 여전히 기계가 생성한 마크업입니다 — 수백 개의 인라인 스타일과 중첩된 span. 오늘 당장 콘텐츠를 온라인에 올리면 그만이라면 괜찮고, 언젠가 편집해야 한다면 고통입니다.

방법 3 — 변환하지 않기: PDF를 임베드하거나 링크하기

«이 PDF를 내 웹사이트에 어떻게 올리죠?»의 정답이 그냥 PDF를 웹사이트에 올리는 것일 때도 있습니다:

<embed src="/files/report.pdf" type="application/pdf" width="100%" height="800px" />

아니면 용량 안내가 붙은 단순 링크: <a href="/files/report.pdf">연차 보고서 (PDF, 2.4 MB)</a>.

단점: 임베드된 PDF는 여전히 SEO에 약하고 휴대폰에서 불편합니다. 흔한 절충안은 둘 다 하는 것 — 핵심 내용의 HTML 요약을 페이지에 싣고, 그 아래에 전체 PDF 링크를 두는 방식입니다.

내 경우엔 어떤 방법이 맞을까?

솔직한 기대치: 살아남는 것과 죽는 것

어떤 방법을 고르든 기대치를 맞춰 두세요:

• 일반 텍스트: 어디서나 살아남습니다. 이게 쉬운 90%입니다.
• 글꼴: 웹폰트를 직접 추가하지 않는 한 보통 웹 안전 글꼴이나 시스템 글꼴로 대체됩니다.
• 다단 레이아웃: 고전적인 실패 지점. 변환기는 단을 하나의 혼란스러운 흐름으로 뭉개거나 절대 위치로 얼려 버립니다.
• 표: 복불복. 단순한 격자는 자주 변환되지만 병합된 셀과 중첩 표는 거의 안 됩니다.
• 머리글, 바닥글, 페이지 번호: '페이지'마다 반복되는 쓰레기 텍스트로 따라옵니다 — 손으로 지우게 될 겁니다.
• 인터랙티브 양식 필드: 어떤 변환기에서도 살아남지 못합니다. HTML 폼으로 다시 만드세요.

반대 방향이라면 — 웹 페이지가 있고 그것의 PDF가 필요하다면 — 그건 훨씬 잘 풀린 문제입니다. HTML을 PDF로 변환하는 방법을 찾아보세요.

자주 묻는 질문

진짜 무료인 온라인 PDF→HTML 변환기가 있나요?

무료 자동 변환기는 있지만 결과물은 기계 생성 마크업 — 위치 지정 div와 인라인 스타일입니다. 깨끗한 HTML로 가는 진짜 무료 경로는 pdfty로 텍스트와 이미지를 추출하고(20 MB까지 무료, 하루 10회, 가입 없음) 마크업을 직접 쓰는 것입니다.

제 PDF는 스캔본이라 추출 결과가 비어 있어요. 왜죠?

스캔된 PDF는 페이지 사진일 뿐 안에 텍스트 레이어가 없습니다. 먼저 OCR을 돌리세요. 그 후에는 텍스트 추출이 정상 동작합니다. OCR 없이는 세상 어떤 변환기도 존재하지 않는 텍스트를 찾을 수 없습니다.

PDF 안의 하이퍼링크는 변환에서 살아남나요?

pdftohtml은 대부분의 링크 주석을 a 태그로 보존합니다. 추출·재조립 워크플로에서는 일반 텍스트 추출이 링크를 떨어뜨립니다 — 중요한 URL은 마크업하면서 PDF에서 직접 복사하세요.

이미지를 최대 품질로 꺼내려면?

**이미지 추출**을 쓰세요 — 페이지를 스크린샷하는 게 아니라 임베드된 원본을 꺼내므로, PDF에 실제로 저장된 해상도를 얻습니다. 게시 전에 웹용으로 압축하세요.

구글이 PDF도 색인하긴 하나요?

네 — 구글은 PDF를 색인하고 랭킹합니다. 하지만 같은 콘텐츠의 HTML 페이지가 일관되게 더 좋은 성과를 냅니다: 더 나은 모바일 경험, 더 빠른 로드, 진짜 제목 구조, 내부 링크가 모두 랭킹에 기여하죠. 검색에 중요한 콘텐츠라면 HTML로 게시하세요.

Word로 PDF→HTML이 되나요?

어느 정도는. Word는 많은 PDF를 열고(파일 → 열기) 편집 가능한 문서로 리플로한 뒤 '웹 페이지로 저장'할 수 있습니다. Word가 내뱉는 HTML은 악명 높게 비대합니다 — 출발점으로는 쓸 만하지만 프로덕션 마크업으로는 아닙니다.

HTML 대신 PDF→Markdown은 어때요?

종종 더 똑똑한 선택입니다. 텍스트를 추출하고 Markdown 제목·목록 문법을 추가한 뒤(태그보다 타이핑이 빠릅니다) 사이트 생성기가 HTML을 만들게 하세요. 방법 1과 같은 워크플로인데 타이핑이 줄어듭니다.

임베드된 PDF는 접근성에 나쁜가요?

대개 네. 브라우저 PDF 뷰어 안의 스크린 리더 지원은 일관성이 없고, 태그 없는 PDF는 어디서나 읽기 나쁩니다. 접근성이 중요하다면 콘텐츠를 진짜 HTML로 — 임베드 옆에 간소화 버전이라도 — 제공하세요.