문서구조화

손글씨 문서의 구조 복원: 중간 표현으로 HTML을 채택한 근거

2026. 05. 13

손글씨를 재사용 가능한 문서로 복원하는 개인 프로젝트입니다. 문자만 추출하고 계층을 잃는 기존 OCR의 한계를 구조 복원 문제로 재정의하고, 중간 표현으로 HTML을 택한 근거를 정리했습니다.

프로젝트 배경

소속
개인 프로젝트 (MVP 사용자 검증 완료)
프로젝트
Handwriting-to-Document · 손글씨 문서 구조 복원
기간
2025 · 71명 대상 MVP 테스트 수행
담당
단독 · 파이프라인 설계-구현-사용자 검증

회의록·아이디어 메모 같은 손글씨 기록을 재사용 가능한 디지털 문서로 변환하는 파이프라인을 만든 개인 프로젝트입니다. 기존 OCR이 문자만 추출하고 문서의 논리적 계층을 잃어버린다는 문제에서 출발했으며, 기술 검증에 그치지 않고 71명 규모 MVP 테스트로 실제 재사용되는지까지 확인했습니다.

문서구조화VisionLLMOCR파이프라인설계사용자검증

1. 문제 정의: 텍스트 추출과 문서 복원의 간극

손글씨 기록을 재사용 가능한 디지털 문서로 바꾸는 개인 프로젝트입니다. 71명 규모의 MVP 테스트까지 진행했습니다.

회의록, 아이디어 메모와 같은 손글씨 기록은 가치가 높은 지식 자산이지만, 비정형성과 낮은 가독성으로 인해 디지털 재사용이 차단됩니다.

기존 OCR은 이 문제를 부분적으로만 해결합니다. 문자 인식에서 처리가 종료되며, 문서가 본래 갖고 있던 논리적 계층이 소실되기 때문입니다. 제목이 제목인 것을, 목록이 목록인 것을, 중첩 관계가 중첩인 것을 인식 결과가 보존하지 못합니다.

그 결과 산출물은 평평한(flat) 텍스트 덩어리가 되며, 이는 검색·재편집·재사용 어느 관점에서도 원본보다 나은 자산이 되지 못합니다. 본 프로젝트의 목표는 문자 전사가 아니라 구조 복원으로 문제를 재정의하는 데 있습니다.

2. 핵심 설계 결정: 중간 표현의 선택

2.1 왜 중간 표현이 필요한가

손글씨 이미지에서 PDF로 직행하는 경로를 택할 경우, 모델의 출력이 곧 최종 산출물이 되어 구조 검증의 여지가 사라집니다. 모델이 계층을 잘못 판단해도 이를 확인하거나 교정할 지점이 없습니다.

따라서 이미지와 최종 문서 사이에 검증 가능한 중간 표현(intermediate representation) 을 두는 것이 설계의 출발점이 됐습니다.

2.2 중간 표현으로 HTML을 선택한 근거

세 가지 후보를 검토했습니다.

1안. 평문(plain text) + 마커 · 구현이 단순하나 중첩 구조 표현에 한계가 있고, 파서를 자체 정의해야 합니다.

2안. JSON 스키마 · 구조 표현은 명확하나, 렌더링 단계에서 다시 변환 계층이 필요하며 스키마 설계·유지 비용이 발생합니다.

3안. HTML · 웹 표준이며 계층 구조를 본래적으로 표현합니다. 화면과 인쇄 양쪽으로 손실 없이 렌더링되고, 정규식 기반 후처리로 구조 정합성을 검사할 수 있습니다.

3안을 채택했습니다. 결정적 근거는 HTML이 표현 형식이자 동시에 검증 대상이 된다는 점이었습니다. <h1> 다음에 <h3>가 오는 등의 계층 위반을 후처리 단계에서 기계적으로 탐지·교정할 수 있으며, 별도의 스키마를 정의하지 않고도 이것이 가능합니다.

3. 파이프라인 구성

 손글씨 이미지 ─▶ 멀티모달 입력 처리 ─▶ 생성형 구조 복원 ─▶ 후처리 검증 ─▶ 수식 대응 PDF
  (다중 업로드)     multipart →          Gemini 2.5 Flash     정규식 구조     KaTeX 렌더 +
                    GenerativePart       → HTML 계층 생성      정합성 검사     Puppeteer A4

① 멀티모달 입력 처리 · multipart 업로드를 GenerativePart 배열로 변환하여 다중 이미지를 단일 문서 맥락으로 전달합니다. 페이지 단위로 분리 처리할 경우 문서 전체의 계층이 페이지 경계에서 끊기기 때문입니다.

② 생성형 구조 복원 · Gemini 2.5 Flash가 제목·목록·문단의 논리적 계층을 포함한 HTML을 생성합니다. 문자 전사가 아니라 레이아웃과 맥락을 함께 해석하도록 프롬프트를 구성했습니다.

③ 맥락 인지형 후처리 · enhanceDocumentStructure 함수가 정규식 기반으로 구조 일관성을 강제하고 무결성을 검증합니다. 모델 출력을 신뢰하지 않고 기계적으로 재검사하는 계층입니다.

④ 수식 대응 PDF 생성 · 수식 영역을 탐지하여 KaTeX로 렌더링한 뒤, Puppeteer(headless Chrome)를 통해 A4 고정 레이아웃 PDF로 변환합니다.

3.1 서버 사이드 PDF 생성을 선택한 이유

클라이언트 렌더링 대신 서버 측 Puppeteer를 사용했습니다. A4 고정 레이아웃의 재현성이 판단 기준이었습니다. 클라이언트 환경은 폰트 가용성과 렌더링 엔진이 상이하여 동일 문서가 사용자마다 다르게 출력될 수 있으며, 인쇄를 전제로 하는 산출물에서 이는 허용하기 어려운 편차입니다.

대량 변환 시의 블로킹을 방지하기 위해 비동기 API와 Node 작업 큐를 결합했습니다.

4. 사용자 검증 결과

기술적 완성도와 별개로, 이 산출물이 실제로 재사용되는가를 확인할 필요가 있었습니다. 71명 규모의 MVP 테스트를 수행했습니다.

지표결과
표본71명
만족도73.2%
NPS30 이상

NPS 30 이상은 도구(tool)가 아니라 지식 관리 제품(knowledge-management product) 으로서의 수용 가능성을 시사하는 수준으로 해석했습니다. 다만 표본이 71명으로 제한적이며 초기 사용자 편향이 존재할 수 있으므로, 이 수치를 일반화된 시장 검증으로 확대 해석하지는 않습니다.

5. 결론

본 프로젝트가 도출한 시사점은 다음과 같습니다.

첫째, 비정형 데이터의 구조화는 인식 정확도가 아니라 표현 설계의 문제입니다. 문자 인식률을 높이는 것만으로는 재사용 가능한 자산이 생성되지 않으며, 어떤 구조로 복원할 것인가를 먼저 정의해야 합니다.

둘째, 생성형 모델의 출력에는 기계적 검증 계층이 병행되어야 합니다. 모델이 계층을 잘못 판단하는 사례는 반드시 발생하며, 이를 후처리에서 탐지·교정할 수 있는 중간 표현을 선택하는 것이 파이프라인 신뢰도를 결정합니다.

셋째, 중간 표현의 선택이 이후 모든 단계의 비용을 규정합니다. HTML을 택했기 때문에 검증은 정규식으로, 렌더링은 브라우저 엔진으로 해결됐습니다. 자체 스키마를 정의했다면 검증기와 렌더러를 모두 직접 구현해야 했을 것입니다.

코드는 GitHub 저장소에 공개되어 있습니다.