PDF 글자 추출 (OCR)

겉보기에 똑같은 PDF 두 개가 있어도 안에 든 것은 전혀 다를 수 있습니다. 워드나 한글에서 "PDF로 저장"을 눌러 만든 파일 안에는 글자 코드와 글꼴 정보가 들어 있습니다. "계약서"라는 단어가 있다면 파일 어딘가에 그 세 글자가 실제로 저장되어 있고, 뷰어는 글꼴을 이용해 그 자리에 모양을 그려 냅니다. 그래서 마우스로 긁으면 선택되고, Ctrl+F로 찾을 수 있고, 복사해서 다른 곳에 붙여넣을 수 있습니다.

반면 복합기로 종이를 스캔하거나 휴대폰 스캐너 앱으로 찍어 만든 PDF 안에는 커다란 사진 한 장이 페이지마다 들어 있을 뿐입니다. 사람 눈에는 "계약서"라고 보이지만 파일 입장에서는 그저 검은 픽셀이 모여 있는 그림입니다. 글자 코드가 없으니 선택도, 검색도, 복사도 되지 않습니다. 팩스로 받은 PDF, 사진을 이어 붙여 만든 PDF, 화면을 캡처해 묶은 PDF도 모두 같은 처지입니다.

내가 가진 파일이 어느 쪽인지 확인하는 방법은 간단합니다. PDF 뷰어에서 본문 글자를 마우스로 드래그해 보세요. 파란 선택 영역이 글자 모양대로 잡히면 텍스트 PDF이고, 아무것도 잡히지 않거나 사진 전체가 한 덩어리로 선택되면 스캔 PDF입니다. Ctrl+F로 본문에 분명히 있는 단어를 찾아 봐도 됩니다. "찾을 수 없음"이 뜨면 스캔본입니다.

한 파일 안에 두 종류가 섞이는 경우도 흔합니다. 워드로 만든 문서를 인쇄해 서명한 뒤 그 장만 스캔해 원본에 끼워 넣으면, 앞쪽 열 장은 텍스트 페이지이고 서명 장만 그림 페이지가 됩니다. 이 도구는 그래서 파일 전체를 한꺼번에 판단하지 않고 페이지마다 따로 확인합니다. 각 페이지에서 글자 정보를 먼저 꺼내 보고, 스무 자가 넘게 나오면 "이미 텍스트 있음"으로 표시하고 그 글자를 그대로 결과에 씁니다. 거의 나오지 않는 페이지만 그림으로 렌더링해 인식합니다. 결과 위에 "스캔 페이지 N / 텍스트 페이지 M"이라고 요약이 뜨는 것이 이 판정 결과입니다.

덕분에 100쪽짜리 보고서 가운데 스캔된 부록 세 장만 인식하면 되는 경우, 세 장만 처리하고 나머지 97장은 원래 있던 글자를 그대로 가져옵니다. 시간이 서른 배 넘게 절약되고, 멀쩡한 원본 글자를 OCR로 다시 읽어 오히려 망가뜨리는 일도 없습니다. 원본 글자층 자체가 깨져 있어(예: 폰트 매핑이 잘못되어 복사하면 이상한 기호가 나오는 PDF) 다시 읽어야 한다면 전부 다시 인식 옵션을 켜면 됩니다.

스캔 PDF를 검색되게 만드는 방법으로 흔히 떠올리는 것은 "글자를 읽어서 새 문서를 만든다"입니다. 하지만 그러면 도장·서명·표 선·손글씨 메모·용지의 질감이 전부 사라지고 서식도 무너집니다. 계약서나 진단서처럼 원본의 모양 자체가 증거인 문서에서는 쓸 수 없는 방법입니다.

그래서 표준적인 해법은 다르게 접근합니다. 원본 그림은 한 픽셀도 건드리지 않고 그대로 둔 채, 그 위에 인식한 글자를 같은 자리에 얹되 보이지 않게 그리는 것입니다. PDF에는 글자를 어떻게 칠할지 정하는 "텍스트 렌더링 모드"라는 설정이 있고, 그 중 3번이 Invisible(칠하지 않음)입니다. 이 모드로 그린 글자는 화면에도 인쇄물에도 전혀 나타나지 않지만, PDF 규격상으로는 엄연히 그 좌표에 존재하는 텍스트입니다.

뷰어의 검색 기능이나 복사 기능은 화면에 칠해진 픽셀이 아니라 이 텍스트 정보를 봅니다. 그래서 Ctrl+F로 "계약"을 찾으면 뷰어는 보이지 않는 글자 층에서 그 단어를 찾아내고, 그 글자가 놓인 사각형에 노란 하이라이트를 그립니다. 사용자 눈에는 스캔 이미지 위의 정확히 그 단어가 노랗게 빛나는 것처럼 보입니다. 원본은 그림 그대로인데 검색은 되는, 두 마리 토끼를 잡는 구조입니다. 이 방식으로 만든 파일을 흔히 "searchable PDF" 또는 "PDF 검색층", "text layer"라고 부릅니다.

이 도구는 단어 하나하나를 따로 얹습니다. 인식 엔진은 각 단어의 네모 영역(bounding box)을 픽셀 좌표로 알려 주는데, 이것을 PDF 좌표계(원점이 왼쪽 아래, 단위는 1/72인치)로 변환한 뒤 그 자리에 글자를 놓습니다. 글자 크기는 네모의 높이에 맞추고, 폭은 수평 장평(Tz)이라는 설정으로 늘리거나 줄여 네모의 폭과 맞춥니다. 그래야 "계약서"라는 단어를 찾았을 때 하이라이트가 이미지 속 그 단어를 정확히 덮습니다. 페이지가 회전되어 저장된 문서라면 회전 행렬까지 반영해 글자 방향을 맞춥니다.

글자 모양을 담을 글꼴도 파일 안에 들어가야 합니다. 한글은 아스키와 달리 PDF 기본 글꼴에 없기 때문입니다. 이 도구는 나눔고딕을 쓰되 실제로 쓰인 글자만 골라낸 서브셋만 넣습니다. 2MB짜리 폰트 전체가 아니라 문서에 등장한 수백~수천 자에 해당하는 수십 KB만 들어가므로, 결과 파일은 원본보다 조금 커지는 정도에 그칩니다. 어차피 보이지 않는 글자라 어떤 글꼴을 쓰든 화면에는 영향이 없고, 검색과 복사를 위한 글자 코드만 정확하면 됩니다.

계약서·부동산 서류 — 몇 해 전 계약서를 스캔해 두었는데 특약 조항 하나를 확인하려면 스무 장을 눈으로 훑어야 하는 상황이 대표적입니다. 검색 가능한 PDF로 바꿔 두면 "위약금", "중도해지", "관리비" 같은 단어로 바로 찾아갈 수 있습니다. 원본 서명과 도장이 그대로 남아 있으니 보관용 파일로도 문제가 없습니다. 다만 이 도구는 문서의 법적 효력이나 내용의 옳고 그름을 판단하지 않으며, 인식 결과의 정확성도 보장하지 않습니다.

의료기록·검사 결과지 — 병원에서 받은 진료기록 사본은 대부분 스캔 PDF입니다. 여러 병원에서 받은 기록을 한 폴더에 모아 두었을 때, 검색층이 있으면 특정 약 이름이나 수치를 파일 여러 개에서 한 번에 찾을 수 있습니다. 민감한 문서이므로 파일을 외부 서버에 올리지 않고 처리한다는 점이 특히 중요합니다.

논문·오래된 자료 — 학술 데이터베이스에 올라온 옛 논문은 종이 저널을 스캔한 것이 많습니다. 인용문을 찾거나 참고문헌을 옮겨 적을 때, 검색층이 있으면 해당 문단을 그대로 복사할 수 있어 타이핑 시간이 크게 줄어듭니다. 인용할 때 출처를 밝히고 정당한 범위를 지키는 것은 이용자의 몫입니다.

행정·회계 문서 — 세금계산서, 지출결의서, 회의록처럼 결재란과 도장이 있는 문서는 스캔본으로 보관되기 마련입니다. 연말 정산이나 감사 대비로 특정 거래처·금액을 찾아야 할 때 검색층이 있으면 폴더 전체를 대상으로 운영체제의 파일 검색까지 활용할 수 있습니다. 윈도우 탐색기와 맥 스포트라이트 모두 PDF 안의 텍스트를 색인합니다.

AI 도구에 넣기 — 요즘은 문서를 요약하거나 질문하기 위해 챗봇에 PDF를 넣는 경우가 많은데, 스캔 PDF는 대부분 "글자를 찾을 수 없다"는 답이 돌아옵니다. 검색층을 얹으면 같은 파일이 그대로 텍스트로 읽히므로 요약·번역·질의응답에 쓸 수 있게 됩니다. 텍스트만 필요하다면 이 도구에서 바로 전체 복사나 .txt 저장을 해서 붙여넣어도 됩니다.

접근성 — 시각장애인이 쓰는 화면 낭독기는 이미지에서 글자를 읽지 못합니다. 스캔 PDF는 낭독기에게 빈 페이지나 다름없습니다. 검색층을 넣으면 낭독기가 순서대로 읽어 줄 수 있게 되므로, 공지문이나 안내문을 스캔본으로 배포해야 한다면 검색층을 함께 넣는 것이 훨씬 친절합니다.

해상도는 200dpi 이상. 이 도구는 PDF 안의 그림을 그대로 꺼내 쓰지 않고, 고른 해상도로 페이지를 다시 그려 인식합니다. 150dpi는 큰 글씨 위주의 문서에서 빠르고, 본문 10~11포인트 문서라면 200dpi가 균형점입니다. 각주나 표 안의 작은 글씨까지 살려야 한다면 300dpi를 쓰세요. 대신 픽셀 수가 200dpi의 2.25배가 되어 시간도 그만큼 걸립니다. 반대로 원본 스캔 자체가 100dpi로 뜬 저품질 파일이라면 300dpi로 렌더링해도 없던 획이 생기지는 않습니다. 화질의 상한은 언제나 원본이 정합니다.

정면·수평이 기본입니다. 복합기 스캔은 대체로 반듯하지만, 휴대폰으로 찍어 만든 PDF는 기울어 있거나 사다리꼴로 찌그러진 경우가 많습니다. 인식 엔진은 글자를 가로줄로 잘라 한 줄씩 읽기 때문에 몇 도만 기울어도 줄 자르기부터 어긋납니다. 3도 정도면 눈에 띄게 나빠지고 10도를 넘으면 급격히 무너집니다. 스캐너 앱의 사각형 보정(원근 보정) 기능을 쓴 뒤 저장하는 것이 가장 확실합니다.

대비를 확보하세요. 흰 바탕에 검은 글자가 가장 잘 읽힙니다. 색지에 인쇄된 문서, 형광펜이 덧칠된 부분, 그림자가 반쯤 진 페이지는 글자와 배경을 나누는 첫 단계에서부터 실패합니다. 이럴 때 흑백 대비 강화 옵션을 켜면 회색조로 바꾼 뒤 가장 어두운 값과 밝은 값을 양 끝으로 늘려 주므로 눈에 띄게 좋아지는 경우가 많습니다. 다만 이미 깨끗한 스캔에서는 켜도 별 차이가 없거나 잡티를 키울 수 있으니, 결과가 나쁠 때만 켜서 비교해 보세요.

잘 안 되는 것들

• 손글씨 — 인식 모델은 인쇄체로 학습되어 있습니다. 또박또박 쓴 정자체가 운 좋게 몇 단어 맞을 수는 있어도 흘림체는 사실상 읽지 못합니다. 서명란과 손글씨 메모는 인식되지 않는다고 보는 편이 맞습니다.
• 세로쓰기 — 세로로 흐르는 글은 읽는 순서 자체가 어긋납니다. 옛 문헌이나 세로쓰기 신문 스캔은 이 도구로 처리하기 어렵습니다.
• 표 — 표의 선이 글자에 닿아 있으면 그 칸이 통째로 깨지거나, 칸 순서가 뒤섞여 나옵니다. 표 구조 자체는 텍스트로 복원되지 않고 줄바꿈만 남습니다.
• 다단 편집·잡지 레이아웃 — 여러 단이 얽힌 지면은 읽는 순서가 섞일 수 있습니다. 검색층으로는 여전히 유용하지만(단어 위치는 맞으니까) 전체 텍스트를 그대로 옮겨 쓰기에는 부적합합니다.
• 저품질 팩스본 — 팩스 해상도(약 200×100dpi)로 들어온 문서는 세로로 눌려 있어 획이 뭉개집니다. 기대치를 낮추는 편이 좋습니다.
• 도장·워터마크가 글자 위에 겹친 경우 — 겹친 부분은 대체로 깨집니다.

결과가 만족스럽지 않다면 순서대로 시도해 보세요. ① 해상도를 300dpi로 올린다 → ② 흑백 대비 강화를 켠다 → ③ 언어를 문서에 맞게(순수 영문이면 영어만) 좁힌다 → ④ 그래도 안 되면 원본을 더 나은 조건으로 다시 스캔한다. 인식 결과는 페이지마다 편집할 수 있으니, 중요한 숫자와 이름은 원본과 대조해 직접 고친 뒤 저장하시는 편이 안전합니다.

글자 위치가 몇 픽셀 어긋날 수 있습니다. 검색층의 좌표는 인식 엔진이 알려 준 단어 네모를 그대로 옮긴 것입니다. 이 네모는 획의 실제 경계에서 조금 넉넉하거나 모자랄 수 있고, 글자 크기를 네모 높이에 맞추는 과정에서도 오차가 생깁니다. 그래서 검색 하이라이트가 단어를 정확히 덮지 않고 한두 픽셀 위아래로 밀리거나, 문장부호를 살짝 넘어가는 경우가 있습니다. 읽고 찾는 데는 지장이 없지만, 픽셀 단위로 정밀한 정렬이 필요한 용도에는 맞지 않습니다.

복사하면 모양이 원본과 다릅니다. 검색층에 넣은 글꼴은 나눔고딕이며, 원본 문서가 어떤 서체로 인쇄되었든 상관없이 이 글꼴의 글자 코드가 들어갑니다. 보이지 않으니 화면에서는 문제가 없지만, 텍스트를 복사해 다른 곳에 붙여넣으면 당연히 나눔고딕이 아니라 붙여넣은 프로그램의 기본 서체로 나타납니다. 검색층은 모양을 재현하기 위한 것이 아니라 찾고 복사하기 위한 것이라고 생각하시면 됩니다.

띄어쓰기와 줄바꿈은 원본 그대로가 아닙니다. 인식 엔진은 글자 사이의 물리적 간격을 보고 띄어쓰기를 추정합니다. 자간이 넓은 서체에서는 한 단어가 둘로 쪼개지고, 좁으면 두 단어가 붙습니다. 줄바꿈도 지면에 보이는 줄 그대로 들어가므로, 한 문단 안에서 줄이 바뀐 곳마다 개행이 생깁니다. 텍스트로 옮겨 쓸 때는 편집기의 찾아 바꾸기로 정리하는 편이 빠릅니다.

이미 글자가 있는 페이지는 손대지 않습니다. 검색 가능한 PDF를 저장할 때, 텍스트 페이지로 판정된 페이지에는 아무것도 얹지 않습니다. 원래 있던 정확한 글자층 위에 인식 결과를 겹치면 검색 결과가 두 번 잡히고 복사할 때 글자가 두 번 나오기 때문입니다.

암호가 걸린 PDF는 열 수 없습니다. 뷰어에서 열 때 비밀번호를 묻는 파일은 건너뛰고 안내만 표시합니다. 먼저 암호를 푼 사본을 만든 뒤 올려 주세요. 파일이 손상되었거나 확장자만 PDF인 경우도 마찬가지로 건너뜁니다.

큰 문서는 시간과 메모리를 씁니다. 모든 계산이 당신의 기기에서 일어납니다. 서버로 보내지 않는 대신 브라우저의 자원을 쓰기 때문에, 200쪽짜리를 300dpi로 한 번에 돌리면 상당한 시간이 걸리고 메모리도 많이 필요합니다. 진행 중에 남은 시간이 표시되니 참고하시고, 너무 오래 걸리면 중단을 눌러 그때까지의 결과만 받거나 문서를 나눠서 처리하세요. 스마트폰에서는 브라우저가 탭을 정리해 버릴 수 있으므로 되도록 데스크톱을 권합니다.

파일이 정말 전송되지 않나요

네. 이 페이지는 PDF를 어디에도 보내지 않습니다. 브라우저 개발자 도구(F12)의 네트워크 탭을 켜고 실행해 보시면, 이 사이트에서 PDF 해석기(pdf.min.mjs), 인식 엔진(tesseract.min.js와 WebAssembly 코어), 언어 데이터(kor.traineddata.gz, eng.traineddata.gz), 그리고 검색 가능한 PDF를 만들 때만 쓰이는 pdf-lib.min.js·fontkit.umd.min.js·나눔고딕 글꼴을 내려받는 요청만 보입니다. 외부 CDN을 쓰지 않으므로 이 도메인 밖으로 나가는 요청 자체가 없고, 파일이 담긴 요청은 존재하지 않습니다. 계약서·의료기록·신분증처럼 민감한 문서를 다룰 때 이 점이 중요합니다.

왜 처음에만 느린가요

첫 실행에서 인식 엔진(약 2.9MB)과 고른 언어의 데이터(한국어 약 1.1MB, 영어 약 1.9MB)를 내려받기 때문입니다. 받은 언어 데이터는 브라우저 저장소에 보관되어 다음부터는 바로 시작합니다. 인식 작업 프로세스도 한 번 띄운 뒤 계속 재사용하므로, 두 번째 페이지부터는 준비 과정 없이 곧바로 인식이 시작됩니다. 검색 가능한 PDF 저장을 처음 누를 때만 PDF 편집 라이브러리와 한글 글꼴(약 2MB)을 추가로 내려받고, 그 동안 진행률이 표시됩니다. 텍스트만 필요하다면 이 추가 다운로드는 아예 일어나지 않습니다.

사진 한 장만 있는데요

PDF가 아니라 이미지 파일이라면 사진 글자 추출 (OCR)을 쓰세요. 같은 인식 엔진과 같은 설정을 쓰지만 JPG·PNG를 바로 받고, 화면 캡처를 Ctrl+V로 붙여넣을 수 있습니다. 반대로 PDF 페이지를 이미지 파일로 뽑아 두고 싶다면 PDF를 이미지로가 맞습니다. 이 도구는 그 둘 사이에 있는 자리 — PDF를 받아 PDF로 돌려주는 흐름을 담당합니다. 검색층이 필요 없고 글자만 필요하다면 여기서도 .txt로 바로 저장할 수 있으니 굳이 이미지로 거칠 필요는 없습니다.

저장한 파일이 원본보다 커졌어요

검색층에 쓰인 글자들과 글꼴 서브셋이 더해지기 때문입니다. 보통 원본에 수십 KB가 붙는 정도이고, 문서에 등장하는 글자 종류가 많을수록 조금 더 커집니다. 이미지 자체는 다시 압축하지 않고 원본 그대로 옮기므로 화질이 떨어지지 않습니다. 파일이 원래부터 너무 크다면 PDF 용량 줄이기를 먼저 거친 뒤 검색층을 얹는 편이 낫습니다.

라이선스

PDF 해석·렌더링은 PDF.js(Mozilla, Apache License 2.0), PDF 저장·편집은 pdf-lib(MIT)와 @pdf-lib/fontkit(MIT), 글자 인식은 tesseract.js와 tesseract.js-core, 언어 데이터 tessdata_fast(모두 Apache License 2.0), 검색층 글꼴은 나눔고딕(SIL Open Font License 1.1)입니다. 모두 상업적 이용이 허용되며, OFL은 글꼴을 문서에 포함해 배포하는 것을 명시적으로 허용합니다(판매 금지 조항은 글꼴 파일 자체를 단독으로 파는 경우에만 해당합니다). 라이선스 전문은 /tools/lib/README.txt가 가리키는 폴더에 원본 그대로 함께 두었습니다.