일본어 계약서 OCR 벤치마크 — API vs 오픈소스, 어느 쪽이 나은가

테스트 조건

입력: 일본어 부동산 계약서 (賃貸借契約書)

• 세로쓰기 항목 + 가로쓰기 본문 혼재

• 전문 용어: 甲, 乙, 賃貸借, 敷金, 礼金, 重要事項説明

• 특수 문자: ㎡, 〒, ①②③

• 인쇄 품질: 일반 프린터 출력 스캔

비교 대상

API (모델 관리 불필요):

서비스	비용 (1,000p)	설치
Google Cloud Vision	~$1.50	API 키만
Azure Document Intelligence	~$1.50	API 키만
NTT DATA AI OCR	별도 견적	API 키만

오픈소스 (무료, 직접 실행):

도구	모델 크기	GPU 필요
PaddleOCR	10~150MB	불필요
Sarashina2.2-OCR	3B (~6GB)	필수
manga-ocr	400MB	권장
EasyOCR	100MB	불필요
Tesseract	15MB	불필요

예상 성능 비교

도구	타입	일본어 CER	세로쓰기	전문용어	특수문자	속도 (1p)
Google Vision	API	~1-2%	✅	✅	✅	~1초
Sarashina2.2	모델	~1-3%	✅	✅	✅	~5초 (GPU)
PaddleOCR	모델	~3-5%	✅	✅	△	~2초
Azure Document Intelligence	API	~3-5%	△	✅	△	~2초
manga-ocr	모델	~2-4%	✅	△	△	~3초 (GPU)
EasyOCR	모델	~5-10%	△	△	❌	~3초
Tesseract	모델	~8-15%	△	△	❌	~1초

CER(Character Error Rate): 낮을수록 좋다. 1%면 100글자 중 1글자 틀림.

약점 분석

Google Vision:

• 정확도 최고지만 데이터가 Google 서버로 전송됨. 계약서 같은 기밀 문서는 문제

• 인터넷 필수. 오프라인 불가

Sarashina2.2-OCR:

• Google과 비슷한 정확도인데 로컬 실행 가능 (데이터 외부 전송 없음)

• 근데 GPU 필수 (3B 모델). CPU만으로는 너무 느림

PaddleOCR:

• GPU 없이도 괜찮은 정확도. 속도도 빠름

• 근데 특수 문자(㎡, 〒)에 약함. 부동산 계약서에서 치명적

manga-ocr:

• 세로쓰기에 강하지만 만화용으로 훈련되어서 법률 용어 인식이 약함

• 파인튜닝하면 개선 가능

EasyOCR / Tesseract:

• 가장 쉽지만 일본어 계약서에서는 오류가 많다. 프로토타입용

비용 비교 (월 10,000페이지 기준)

방식	타입	월 비용	비고
Google Vision	API	~$15	API 과금
Azure Document Intelligence	API	~$15 (Read) / ~$100 (Contract)	특화 모델은 비쌈
PaddleOCR	모델	$0	서버 비용만 (CPU OK)
Sarashina2.2	모델	$0	서버 비용 (GPU 필요 ~$50/월)
manga-ocr	모델	$0	서버 비용 (GPU 권장)

오픈소스는 모델 비용이 0이지만 서버 비용이 발생한다. GPU 서버면 월 $50~100. CPU만이면 $10~30.

선택 기준

상황	추천
기밀 문서 (계약서, 의료)	Sarashina2.2 (로컬 실행, 외부 전송 없음)
정확도 최우선 + 기밀 무관	Google Vision
GPU 없음 + 무료	PaddleOCR
빠른 프로토타입	EasyOCR (3줄, 설치 간단)
파인튜닝으로 특화	manga-ocr + 계약서 데이터

실측 데이터: Azure Document Intelligence 모델 비교 (일본어 리스 계약서)

실제 프로덕션에서 일본어 리스 판정 OCR을 테스트한 결과다. 같은 Azure Document Intelligence 안에서 출력 포맷을 바꿔가며 측정.

테스트 조건: 일본어 리스 계약서 126개 항목, 정답 데이터와 비교

패턴	모델/포맷	정답 수	정답률
A	prebuilt-layout (Markdown 출력)	111/126	88.1%
B	prebuilt-read (Plain fulltext)	113/126	89.7% ← 최고
C	prebuilt-layout + Markdown 정형	108/126	85.7%

놀라운 결과: prebuilt-read (단순 텍스트 추출)가 prebuilt-layout (Markdown 구조화)보다 정확도가 더 높았다.

왜 단순 OCR이 더 정확한가?

상식적으로는 layout(구조 분석)이 read(단순 텍스트)보다 똑똑할 것 같지만, 실측에서는 반대였다. 추정 원인:

1. Markdown 변환 과정에서 정보 손실 — 표를 Markdown 표로 변환하면서 일부 셀이 잘못 분할되거나 머리글/본문 경계가 잘못 잡힘

2. 레이아웃 분석의 오버피팅 — layout 모델이 "이건 표", "이건 제목"이라고 잘못 판단해서 텍스트를 잘못 그룹화

3. 읽기 순서 오류 — Markdown으로 정형하면서 원본 순서가 바뀜

4. fulltext는 단순함의 승리 — 그냥 "보이는 텍스트를 그대로" 출력하는 게 가공보다 안전

시사점

잘못된 가정: "비싼 모델일수록 정확하다"
실제:        "용도에 맞는 모델일수록 정확하다"

리스 판정처럼 "텍스트를 정확히 읽는 것이 핵심"인 작업에서는:

• prebuilt-layout ($10/1K): 비싼데 정확도 88.1%

• prebuilt-read ($1.50/1K): 싸면서 정확도 89.7%

6배 싼 모델이 더 정확한 결과를 냈다. 비용도 줄이고 정확도도 올라간다.

표 추출이나 복잡한 레이아웃이 핵심이면 prebuilt-layout이 맞지만, "텍스트만 정확히 뽑으면 되는" 경우에는 prebuilt-read를 먼저 시도해봐야 한다.

모델 선택 시 체크리스트

• 내 작업이 정말 "구조화"가 필요한가, 아니면 "텍스트 추출"이 핵심인가?

• 같은 데이터로 prebuilt-read와 prebuilt-layout을 둘 다 돌려봤나?

• 정답 데이터(평가셋)로 정확도를 측정했나?

• "비싼 모델 = 정확함"이라고 가정하지 않았나?

실측 없이 모델을 고르면 안 된다. 항상 자기 데이터로 둘 다 돌려보고 비교해야 한다.