2026년 11월 2일, AWS의 Amazon Textract(OCR 기능을 제공하는 서비스)가 일본어를 지원하게 되었으며 도쿄 리전에서도 사용 가능해졌습니다. 아래 기사가 매우 이해하기 쉬우니 꼭 참고하시기 바랍니다.
이 글에서는 다양한 이미지를 Textract에 넣어보고 그 정확도를 가볍게 측정해본 결과를 중심으로 정리했습니다.
RAG(검색 증강 생성) 등에서 PDF나 이미지로부터 스캔된 문서를 가져오려면, 어딘가에서 OCR(이미지에서 문자열을 읽어내는 처리)이 필요합니다. 그런데 Textract는 이전까지 일본어를 읽을 수 없었습니다.
Azure AI Document Intelligence와 같은 외부 벤더를 사용하면 별도의 계약과 인증 정보가 늘어나고 문서가 AWS 외부로 나가는 문제가 있습니다. RapidOCR과 같은 오픈소스(OSS)를 EC2나 ECS에 직접 호스팅하면 외부에 나가지 않지만, 서버 운영이나 모델 업데이트 관리를 모두 자체적으로 감당해야 합니다.
happy-pipeline.gif
참고로 Bedrock Knowledge Bases 분석 기능이나, Bedrock의 모델에 이미지를 넣는 방법은 이전부터 있었습니다. Textract는 단어별 또는 줄별 위치와 신뢰도(confidence)를 반환하기 때문에 용도에 따라 다르게 사용하는 것이 좋을 것 같습니다.
성능 면에서는 역시 Azure가 강하다는 느낌을 받습니다. 하지만 이미 AWS로 구축하고 있다면 Textract를 사용하는 것이 메리트가 상당히 큽니다.
직접 만든 문서나 Wikimedia Commons에서 가져온 사진들을 Textract에 넣어 테스트해봤습니다. 채점은 준비된 정답과 출력 결과를 글자 단위로 비교하여 정확도를 산출했습니다.
세로쓰기 인쇄 문자는 거의 만점에 가까웠고, 저대비(low contrast) 또는 9px 크기의 작은 문자, 심지어 영수증에서도 100%였습니다. 솔직히 이 정도까지 읽을 수 있을 줄은 몰랐기에 조금 놀라웠습니다.
참고로 투명 텍스트가 들어간 PDF도 테스트해봤지만, Textract는 눈에 보이는 청구서의 문자만 반환하고 숨겨진 문자는 출력되지 않았습니다. 이는 PDF 내부의 문자 데이터가 아니라 페이지 자체를 이미지로 읽어들이는 것 같습니다.
공식적으로는 필기체(handwriting)는 영어만 지원하지만 궁금해서 Wikimedia Commons 사진을 넣어봤습니다.
아직 실전에서는 사용하기 어려워 보였습니다. (공식적으로도 미지원이라 당연한 결과입니다.)
채점은 제가 주관적인 '꽤 관대한' 점수를 매겼습니다.
이미지도 읽는 LLM(VLM)에 OCR을 맡기는 방법도 있으므로, Bedrock의 Claude Sonnet 5.5와 비용을 비교해봤습니다. A4 청구서 1페이지(200dpi, 1654×2339)를 넣었을 때의 예상 비용입니다.
| 방법 | 1페이지 | 1,000페이지 |
|---|
| Textract 문자 감지 | $0.0015 | $1.5 |
| ... | | |
문자만 읽는 것이 목적이라면 Textract가 약 10배 정도 저렴하며, 표까지 추출하는 경우라면 대략 비슷한 가격대입니다. Sonnet은 이미지 토큰이 비용의 대부분을 차지하기 때문에 이미지를 작게 처리해서 전달하면 비용을 절감할 수 있습니다. 대신 위치 정보나 신뢰도는 반환되지 않으므로, 이 정보가 필요하다면 Textract가 더 좋을 것 같습니다.
pipeline-architecture.gif
| 파일 | S3 → Lambda 실행 | Textract | DynamoDB | 합계 |
|---|---|---|---|
| 이미지 | 0.9초 | 0.6초 | 0.01초 | 약 1.5초 |
| ... |
1페이지의 경우 2초 정도 만에 DynamoDB까지 도달했습니다. 비동기 API는 페이지당 약 1.4초씩 시간이 늘어납니다.
페이지 단위로 병렬 처리하면 더 높은 속도 향상을 기대할 수 있습니다.
동기(Synchronous) API를 한 번에 전달할 수 있는 것은 이미지 1장 또는 PDF 1페이지(최대 10MB)입니다. 하지만 2페이지 이상의 PDF라도 페이지별로 나누어 동기 API를 병렬 호출할 수 있습니다. 분할하는 과정이 번거롭거나, 페이지 수가 많아 호출 횟수 제한이 걱정되는 경우에는 비동기(Asynchronous) API를 사용하는 것이 좋습니다.
| 동기 | 비동기 |
|---|
| 전달 방식 | 파일을 직접, 또는 S3에 업로드하여 경로 전달 |
| 결과 | 즉시 반환됨 |
비동기 API는 Start를 통해 작업을 요청하면 Lambda는 그 자리에서 종료됩니다. Textract 처리가 끝나면 SNS로 완료 알림이 오므로, 이를 이용해 결과 획득용 Lambda를 실행하고 Get으로 결과를 받습니다. Lambda가 계속 대기할 필요가 없으므로, 900초 제한도 신경 쓸 필요가 없습니다. (이번에는 이 구성에 대한 검증은 아직 진행하지 않았습니다.)
이번에는 일본어 지원 Textract에 다양한 이미지를 넣어 테스트해 보았습니다. 가로쓰기로 된 인쇄 문자의 경우 상당히 신뢰할 수 있다는 것을 알게 되었습니다. 또한 Textract의 TABLES나 FORMS는 비용이 비싸지만, 최근 유행하는 '판단 모델(judgment model)을 통한 판별'을 거친 후 필요한 이미지에만 포인트적으로 사용하는 방식도 가능할 것 같습니다. 개인적으로는 OCR의 RAG 파이프라인이 AWS만으로 완결되는 것이 정말 기쁩니다:relaxed: :relaxed:
아쉬운 점을 꼽자면... API의 편의성(PDF 페이지 지정 등)은 아직 Azure 쪽이 더 편리합니다. 이 부분이 개선된다면 매우 사용하기 좋은 제품이 될 것이라고 생각합니다.