PDF를 워드로 변환할 때 서식이 깨지는 이유
대부분이 모르는 심각성
PDF를 워드로 변환할 때 서식이 '깨지는' 문제는 단순한 변환 오류가 아닙니다. 문제는 마이크로소프트 워드가 이해하는 문단 스타일, 표 구조, 제목 계층 같은 서식이 애초에 PDF에 존재하지 않았다는 점입니다. 화면에는 정돈된 문서처럼 보이지만, 그 내부는 정확한 x,y 좌표에 개별 문자가 흩뿌려진 평면적인 산점도에 불과합니다. 이것이 왜 문제이며, 왜 모든 기존 변환 도구가 레이아웃을 망가뜨리는지 이 글에서 설명합니다.
핵심 요약
- 변환 오류가 아니라, 소프트웨어가 개별 문자의 산점도에서 문서를 재구성하려는 과정을 보고 있는 것입니다.
- 변환하는 모든 표는 다섯 단계의 추측 사슬(격자 감지, 열 개수 세기, 셀 할당, 머리글 병합, 행 정렬)을 유발하며, 1단계에서 한 번 잘못 추측하면 이후 모든 과정이 망가집니다.
- Vision AI는 전체 페이지를 시각적 장면(제목, 표, 문단)으로 읽고, 편집 시 재배치되는 네이티브 워드 구조를 출력하여 각 요소를 고정하지 않습니다.
PDF는 생각하는 대로 저장하지 않습니다
Microsoft Word는 문서를 의미 요소의 계층 구조로 저장합니다: 제목, 그 다음 단락, 그 다음 번호 목록, 그 다음 세 개의 열이 있는 표. 각 요소는 자체 서식 규칙과 주변 요소와의 관계를 가지고 있습니다. 단락에 문장을 추가하면 Word는 페이지 레이아웃을 처음부터 다시 계산합니다. 단락이 무엇인지 알기 때문입니다.
PDF는 그런 것을 전혀 저장하지 않습니다.
PDF 사양 — ISO 32000-1:2008, 형식을 정의하는 국제 표준 — 은 페이지를 일련의 그리기 명령어로 설명합니다. PDF의 텍스트 요소는 "단락 3, 문장 2"가 아닙니다. 대신: "좌표 (124.5, 356.2)에 Helvetica 10pt로 문자 'A'를 렌더링하고, 이어서 (131.8, 356.2)에 문자 'c', (137.2, 356.2)에 'c'..." 각 문자는 페이지에 독립적으로 배치됩니다. PDF는 어떤 문자가 어떤 단어에 속하는지, 어떤 단어가 어떤 줄에 속하는지, 어떤 줄이 단락을 이루는지, 또는 어떤 단락이 제목인지에 대한 정보를 저장하지 않습니다.
널리 인용되는 PDF 기술 입문서는 이를 단호히 밝힙니다: "PDF는 단락, 서식, 머리글, 바닥글, 들여쓰기, 줄바꿈을 인식하지 않습니다. 텍스트는 한 줄을 넘지 않는 단일 문자만큼 작은 조각으로 분해됩니다."
선택적 확장 기능인 태그된 PDF(ISO 32000의 14.8절에 정의됨)가 존재하며, PDF 파일에 논리적 구조(제목 수준, 단락 경계, 표 의미)를 포함할 수 있습니다. 그러나 태그된 PDF는 주로 접근성 기능이며, 유통되는 대부분의 PDF는 이 기능 없이 생성되었습니다. Adobe 자체 지원 포럼에서도 전문가들은 변환 품질이 "PDF의 구조 트리가 얼마나 잘 구성되어 있는지"에 달려 있다고 설명하며, 대부분의 PDF에는 구조 트리가 없다는 점을 암시합니다.
대부분의 PDF-to-Word 변환기 공급업체가 알려주지 않는 첫 번째 사실은 이것입니다: 화면에서 보는 문서 구조는 파일에 존재하지 않습니다. 모든 변환 도구는 흩어져 있는 개별 문자의 (x,y) 좌표만을 사용하여 처음부터 이를 재구성해야 합니다. 그리고 그 재구성은 세 단계의 추측 연쇄 과정이며, 각 단계는 이전 단계의 오류를 증폭시킵니다.
모든 변환을 망가뜨리는 3중 오류 사슬
PDF를 편집 가능한 Word 문서로 변환하려면 세 단계의 순차적 재구성 과정을 거칩니다. 각 단계에서 소프트웨어는 불완전한 정보를 바탕으로 결정을 내립니다. 잘못된 결정 하나가 다음 단계로 이어져 원본과 점점 더 멀어지는 결과물을 만들어냅니다.
오류 1: 문자 수준 OCR — 잘못된 문자 인식
스캔 또는 이미지 기반 PDF(텍스트가 선택 가능한 문자가 아닌 픽셀로 존재하는 경우)의 첫 단계는 광학 문자 인식(OCR)입니다. OCR 소프트웨어는 페이지 이미지의 각 미세 영역을 검사하여 어떤 문자가 포함되어 있는지 식별합니다. OCR은 한 번에 한 문자씩 처리합니다. 3,000개의 문자가 있는 페이지는 3,000번의 독립적인 인식 결정을 내립니다.
고품질 OCR 엔진도 오류를 범합니다. 스캐너 유리의 먼지 한 점이 마침표를 쉼표로 바꿉니다. 대비가 낮은 텍스트 부분은 'rn'이 'm'으로 읽힙니다. 특이한 글꼴은 'I'(대문자 i)와 'l'(소문자 L), '1'(숫자 1)을 구분할 수 없게 만듭니다. OCR 엔진이 문자당 99%의 정확도를 달성한다면(이는 우수한 수준으로 간주됨) 3,000자 페이지에서 여전히 30개의 잘못된 문자가 발생합니다.
하지만 문자 오인식은 눈에 보이는 문제일 뿐입니다. 더 깊은 문제는 OCR이 모든 문자를 정확히 인식하더라도 발생합니다. OCR은 각 문자의 페이지 내 위치만 기록할 뿐 그 외의 정보는 저장하지 않습니다. 이 위치 데이터는 다음 재구성 단계로 직접 전달됩니다.
오류 2: 좌표 재구성 — 무엇이 무엇과 연결되는지 추측하기
변환기가 문자와 해당 (x,y) 좌표 목록을 확보하면, 데이터만으로는 확실한 답을 내릴 수 없는 일련의 질문에 답해야 합니다:
- 어떤 문자가 단어를 이루는가? 물리적으로 가까운 문자는 같은 단어에 속할 가능성이 높습니다. 하지만 단어 간 간격이 크게 다른 양쪽 정렬 텍스트는 어떨까요? 소수점이 앞 숫자보다 다음 숫자에 더 가까이 있는 경우는 어떨까요?
- 어떤 단어가 줄을 이루는가? 대략 같은 y좌표에 있는 단어는 같은 줄에 있을 가능성이 높습니다. 하지만 속한 줄 위의 줄과 같은 y 위치에 있는 위첨자 각주 표시는 어떨까요?
- 어떤 줄이 문단을 이루는가? 비슷한 왼쪽 여백과 수직적 근접성을 가진 줄은 같은 문단일 가능성이 높습니다. 하지만 나머지 줄보다 짧은 문단의 마지막 줄은 어떨까요? 1열의 하단이 1열의 다음 줄보다 2열의 상단에 물리적으로 더 가까운 다단 레이아웃은 어떨까요?
이러한 모든 결정은 순전히 공간적 근접성에 기반하여 이루어집니다. 소프트웨어는 텍스트가 의미하는 바를 전혀 이해하지 못합니다. 위첨자 각주 인용문(예: "14")은 공간적으로 가깝다는 이유로 문단 텍스트에 병합됩니다. 큰 글꼴의 사이드바 인용문은 y좌표가 겹친다는 이유로 본문에 끼어듭니다. 변환기는 산점도에서 문서 구조를 구축하고 있는 것입니다. 실수를 하지 않는 것이 오히려 놀라운 일일 것입니다.
오류 3: 레이아웃 추측 — 존재하지 않는 구조를 만들어내다
문자가 단어로, 단어가 줄로 묶이면, 변환기는 이제 가장 어려운 작업에 직면합니다: 문서의 레이아웃이 실제로 무엇인지 결정하는 것입니다. 이 크고 굵은 텍스트는 제목일까요, 아니면 큰 글꼴의 한 줄짜리 단락일까요? 이미지 아래 이 텍스트 블록은 캡션일까요, 아니면 다음 섹션의 시작일까요? 이 숫자 격자는 표일까요, 아니면 우연히 열이 맞춰진 텍스트일까요?
소프트웨어는 추측합니다. 일정한 간격으로 반복되는 줄, 행과 열로 정렬된 텍스트, 본문과 다른 글꼴 크기 같은 패턴을 찾습니다. 하지만 이는 확실성이 아닌 경험적 방법일 뿐입니다. 여백이 넉넉하고 의도적인 타이포그래피가 적용된 잘 디자인된 페이지는 알고리즘에 모호한 레이아웃 신호를 보냅니다. 변환기는 잘못 추측합니다. 반복해서 말이죠.
이 단계에서 대부분의 눈에 보이는 서식이 깨집니다. PDF로는 깔끔해 보이던 문서가 Word 파일로 변환되면 텍스트 상자가 페이지 여기저기에 흩어져 있고, 각각 절대 위치에 고정되어 편집하려는 순간 깨집니다. 이는 변환 실패가 아닙니다. 변환기가 가진 유일한 정보로 설계된 대로 정확히 수행한 결과입니다. 그 정보는 작업에 충분하지 않을 뿐입니다.
표: 전체 시스템이 무너지는 지점
3단계 오류 체인이 텍스트 레이아웃이 깨지는 이유를 설명한다면, 표는 그 치명적인 실패 모드를 보여줍니다. 문제는 근본적입니다: PDF에는 표라는 개념이 없습니다.
PDF가 표처럼 보이는 것(열 머리글과 격자선이 있는 데이터 행)을 표시할 때, 실제로는 독립적인 시각적 요소들의 집합을 그리고 있습니다: 테두리를 위한 수평 및 수직 선분, 그리고 결과 격자 셀 안에 배치된 개별 텍스트 문자들. PDF 파일에는 3행, "금액" 열의 셀이 $1,247.00 값과 연결된다는 정보가 전혀 없습니다. 단지 "'$' 문자를 X 위치에, 그다음 '1'을 X+7 위치에 렌더링하라..."는 명령과 테두리용 선 그리기 명령만 저장합니다.
즉, 변환기는 다음을 수행해야 합니다:
- 선분이 격자를 형성한다는 것을 감지 — 테두리가 얇거나 없을 때는 항상 명확하지 않음
- 해당 격자에 포함된 행과 열의 수를 결정 — 셀 병합이나 다양한 열 너비에 쉽게 혼란
- 각 문자를 올바른 셀에 할당 — 하나의 정렬이 틀린 문자가 전체 격자를 무너뜨림
- 유사한 내용의 셀을 병합해야 하는지 추측 (예: 두 열에 걸친 머리글)
- 열의 읽기 순서 결정 — 왼쪽에서 오른쪽? 오른쪽에서 왼쪽? 줄바꿈이 셀 내에서 발생하는지 새 행을 시작하는지?
추측 위에 쌓인 추측의 연속입니다. PDF 파싱 도구를 개발하는 개발자들의 Hacker News 토론은 이 감정을 정확히 포착했습니다: "PDF는 항상 문자를 순서대로 배치하지 않으며, 때로는 개별 문자를 절대 위치에 배치합니다." 한 개발자는 전체 과정을 "터무니없다"고 표현했습니다.
Reddit에서 사용자 경험은 일관된 불만의 연속입니다. r/MicrosoftWord 게시물에서 한 사용자는 PDF를 DOCX로 변환한 결과를 "이상한 서식"이라며 어떤 수정도 통하지 않는다고 토로했습니다. r/Acrobat의 다른 사용자는 PDF를 Word로 내보낸 후 "문단이 이상한 텍스트 상자로 쪼개지고 모든 것이 어긋난다"며 편집 시도만 해도 문제가 생긴다고 보고했습니다. r/TechnologyProTips의 한 사용자는 수년간의 경험을 요약했습니다: "이 질문을 수없이 받았습니다. [...] 서식은 다 사라지고 어쩌고. 이 문서를 doc으로 변환하려고 며칠째 씨름 중입니다."
이것은 예외적인 사례가 아닙니다. 이는 본래 우리가 요구하는 작업과 근본적으로 다른 목적으로 설계된 변환 과정의 당연한 결과물입니다.
"서식 유지" 버튼은 해결책이 아닌 라벨일 뿐입니다
모든 PDF-Word 변환기는 "서식 유지" 또는 "페이지 레이아웃 유지" 옵션을 제공합니다. Adobe Acrobat에도 있고, Smallpdf에도 있으며, ILovePDF에도 있습니다. 이 옵션을 선택하면 변환된 문서가 원본처럼 보일 것이라는 암시를 줍니다.
이 옵션들이 실제로 하는 일을 이해하는 것은 중요합니다. 그 이유는 결과물이 왜 그렇게 취약하게 느껴지는지 드러내기 때문입니다. Adobe Acrobat 내보내기 설정에서 "페이지 레이아웃 유지"를 선택하면, 변환기가 문서의 논리적 구조를 마법처럼 재구성하지 않습니다. 대신, 모든 텍스트 조각을 Word의 절대 위치 텍스트 상자에 배치합니다. 즉, PDF의 좌표계를 Word 문서 내부에 그대로 재현하는 것입니다.
결과물은 열었을 때는 올바르게 보입니다. 하지만 단어를 추가하거나, 문장을 삭제하거나, 여백을 조정하는 등 편집을 시도하는 순간 전체 레이아웃이 무너집니다. 각 텍스트 상자가 주변 콘텐츠가 아닌 페이지의 고정된 위치에 고정되어 있기 때문입니다. 당신은 편집 가능한 문서를 받은 것이 아닙니다. 텍스트 상자로 만든 스크린샷을 받은 것입니다.
Microsoft의 공식 문서조차 이 점에 대해 이례적으로 솔직합니다. Microsoft Q&A의 공식 답변은 이렇게 말합니다: "PDF를 Word로 변환하면서 Word의 적절한 서식 방법을 사용하도록 하는 방법은 없습니다. 이는 각 방식이 처리되는 방식에 1:1 대응 관계가 없기 때문입니다." 다른 답변은 덧붙입니다: "다른 프로그램의 파일 구조에서 변환된 문서는 항상 서상 이상을 포함하며 편집하기 매우 어려운 경우가 많습니다."
이것은 Adobe나 Microsoft가 소프트웨어 업데이트로 고칠 수 있는 한계가 아닙니다. 이는 범주 수준의 제약입니다. 원본 형식(PDF)과 대상 형식(Word)은 문서를 근본적으로 호환되지 않는 방식으로 표현합니다. 하나는 외형을 저장하고, 다른 하나는 구조를 저장합니다. 원본 구조 데이터 없이 외형을 구조로 변환하는 것은 해결될 수 없는 문제입니다. 단지 다양한 실패 정도로 근사화될 뿐입니다.
저희의 PDF-Word 변환기 종합 리뷰에서는 동일한 문서 세트로 12개 이상의 도구를 테스트했습니다. 모든 도구가 병합된 셀이 있는 표에서 실패했습니다. 모든 도구가 다단 레이아웃을 어느 정도 망가뜨렸습니다. 차이는 얼마나 많은 정리가 필요한지에 있었지, 정리가 필요한지 여부에 있지 않았습니다. 변환과 데이터 추출이 근본적으로 다른 작업인 이유에 대한 자세한 설명은 저희의 문서 변환과 데이터 추출 비교를 참조하십시오.
비전 AI가 오류 체인 전체를 우회하는 방법
지금까지 설명한 모든 것(문자 단위 OCR, 공간 재구성, 휴리스틱 레이아웃 추측)은 모든 기존 PDF 변환기가 사용하는 파이프라인입니다. 이는 "개별 문자와 좌표 목록"에서 시작할 때 사용할 수 있는 유일한 파이프라인입니다.
하지만 근본적으로 다른 접근 방식이 있으며, 소프트웨어가 처음에 보는 대상을 변경함으로써 오류 체인 전체를 우회합니다.
비전 AI — 특히 수백만 개의 문서 이미지로 훈련된 비전-언어 모델(VLM) — 은 문자를 하나씩 읽지 않습니다. 인간이 하는 것처럼 전체 페이지를 하나의 시각적 단위로 봅니다. OCR이 이것을 보는 반면:
문자 'I' 위치 (45.2, 120.8)
문자 'n' 위치 (52.1, 120.8)
문자 'v' 위치 (57.3, 120.8)
문자 'o' 위치 (65.1, 120.8)
문자 'i' 위치 (72.9, 120.8)
문자 'c' 위치 (78.4, 120.8)
문자 'e' 위치 (85.7, 120.8)
[...3000개 이상 항목...]
비전 AI는 이것을 봅니다:
상단 중앙에 "인보이스" 제목이 있는 문서 헤더. 그 아래, 왼쪽에 공급업체 세부 정보(회사명, 주소, 사업자등록번호), 오른쪽에 인보이스 메타데이터(인보이스 번호, 날짜, 마감일)가 있는 2열 레이아웃. 설명, 수량, 단가, 금액의 4개 열이 있는 표에 6개 라인 항목 포함. 소계 라인, 8.5% 세금 라인, 하단에 총 $1,247.00.
차이는 근본적입니다. OCR은 문자 위치를 생성합니다. 비전 AI는 문서 이해를 생성합니다.
비전 AI는 보고 있는 것을 이해하기 때문에 네이티브 Word 문서를 생성할 수 있습니다. 위치가 지정된 텍스트 상자의 모음이 아니라 실제 Word 단락, 실제 Word 제목, 올바른 행과 열 수의 실제 Word 표입니다. 출력은 처음부터 Word에서 작성된 문서처럼 동작합니다. 단락에 텍스트를 추가하면 아래 텍스트가 자연스럽게 흐르고, 표 열 크기를 조정하면 인접 열이 조정되며, 새 제목 스타일을 적용하면 문서 전체에 전파됩니다.
이것이 ImageToTable.ai의 Word로 모드가 하는 일입니다. 기존 PDF-to-Word 변환기와 달리 OCR → 좌표 재구성 → 레이아웃 추측 파이프라인을 전혀 시도하지 않습니다. 대신 비전-언어 모델이 디지털 PDF, 스캔 문서, 스크린샷, 인쇄된 페이지의 휴대폰 사진 등 전체 페이지 이미지를 분석하고 단락, 제목, 표가 그대로 유지된 구조화된 Word 문서를 출력합니다. 템플릿, 훈련, 문서별 구성이 필요 없습니다. AI 비전 모델이 OCR과 다르게 문서를 처리하는 방법에 대한 전체 기술적 내용을 원하신다면, AI가 문서를 읽는 방법에 대한 평이한 영어 가이드에서 메커니즘을 자세히 설명합니다.
파일은 안전하게 처리되며 저장되지 않습니다.
이 접근 방식은 To Word 모드가 스캔 문서와 디지털 PDF를 동일하게 처리함을 의미합니다. 둘 다 비전 모델에게는 단순한 이미지일 뿐입니다. 문자 인식과 레이아웃 이해가 동시에 이루어지기 때문에 별도의 "OCR 후 변환" 단계가 없습니다. 이 과정은 문서가 어떻게 구성되는지에 대한 모델의 이해를 바탕으로 합니다. 지난 3년간 OCR 기술이 어떻게 발전했고 무엇이 바뀌었는지 자세히 알아보려면 OCR 이후의 변화에 대한 분석을 참조하세요.
그 결과는 기존 변환기 공급업체들이 "서식 유지" 버튼이 하는 일이라고 주장했지만 실제로는 제공하지 못했던 것입니다. 즉, 레이아웃을 처음부터 다시 구축하지 않고도 내용을 편집할 수 있는 Word 문서입니다. 레이아웃을 보존하는 문서-Word 변환에 대한 완전한 기술적 개요(기본 메커니즘, 접근 방식 비교, 선택 가이드 포함)는 레이아웃을 보존하는 문서-Word 변환 완벽 가이드를 참조하세요.
자주 묻는 질문
스캔된 PDF에서도 작동하나요, 아니면 디지털 PDF에서만 작동하나요?
Vision AI는 둘을 동일하게 처리합니다. 스캔된 PDF는 페이지의 이미지이고, 화면에 렌더링된 디지털 PDF도 페이지의 이미지입니다. 비전 모델은 시각적 외형을 직접 처리하므로 스캔 문서와 디지털 PDF 간 출력 품질에 차이가 없습니다. 기존 변환기는 스캔 문서의 경우 먼저 OCR을 실행해야 하며, 이는 레이아웃 재구성과 분리되어 수행되므로 위에서 설명한 전체 오류 체인이 다시 발생하여 성능이 크게 저하됩니다.
손으로 쓴 문서나 주석은 어떻게 처리하나요?
Vision AI는 글꼴 라이브러리와 문자 모양을 대조하는 대신 맥락을 이해하기 때문에 OCR보다 필기 처리를 더 강력하게 수행합니다. OCR은 손으로 쓴 메모를 개별적으로 해독해야 하는 일련의 모호한 모양으로 취급합니다. Vision AI는 주변 텍스트를 읽고 문서의 목적을 이해한 후 그 맥락을 사용하여 손으로 쓴 표시를 해석합니다. 이는 사람이 읽는 방식과 동일합니다. 성능은 필기 가독성에 따라 달라지지만, 접근 방식 자체가 OCR과 근본적으로 다릅니다.
Word 출력물이 실제로 편집 가능한가요? 아니면 변경 시 깨지나요?
출력물은 네이티브 Word 형식입니다. 즉, 위치가 고정된 텍스트 상자가 아닌 실제 문단, 제목, 표로 구성됩니다. 문단에 텍스트를 추가하면 아래 내용이 자연스럽게 재배치됩니다. 표에서 열 너비를 조정할 수 있습니다. Word 스타일을 적용할 수 있습니다. 문서는 Word에서 작성된 것처럼 동작합니다. 이것이 Vision AI 출력과 기존 변환기 출력의 구조적 차이점입니다. 후자는 외형을 보존하는 대신 편집 가능성을 희생하는 반면, 전자는 구조를 보존하여 외형이 자연스럽게 따라오도록 합니다.
Vision AI는 다단 보고서나 양식과 같은 복잡한 레이아웃을 얼마나 잘 처리하나요?
Vision AI는 페이지를 좌표 그리드가 아닌 시각적 장면으로 처리합니다. 다단 레이아웃, 레이블이 지정된 필드가 있는 양식, 차트와 이미지가 포함된 문서 등에서 모델은 이를 재구성해야 하는 공간적 인공물이 아닌 의미론적 패턴으로 인식합니다. 출력 품질은 문서의 명확성과 복잡성에 따라 달라지지만, 이 접근 방식은 좌표 재구성 방법에 내재된 체계적인 오류 모드(열 인터리빙, 텍스트 상자 조각화)를 피합니다. 레이아웃 보존 가이드에서 다양한 사례와 한계를 자세히 다루고 있습니다.