OCR API란 무엇인가: 문서 인식을 시스템에 연동하는 방법 완전 정리

OCR API란, 개발자가 문서 이미지나 파일을 정해진 규격으로 전송하면 인식된 텍스트와 각 값의 위치, 신뢰도를 구조화된 응답으로 돌려받아 자사 시스템에 바로 연결할 수 있게 만든 인터페이스입니다.

OCR API가 필요한 이유

화면에 결과를 띄우는 것으로는 업무가 줄지 않습니다.

문서 인식 도구를 도입했는데 담당자의 일이 그대로인 경우가 있습니다. 인식 결과가 별도 화면에 표시되고, 담당자는 그 화면과 업무 시스템을 번갈아 보며 값을 다시 옮겨 적습니다. 창을 두 개 띄워 두고 한쪽에서 읽어 다른 쪽에 입력하던 원래 작업이 그대로 남은 것입니다. 자동화가 아니라 확인 단계가 하나 늘어난 상태에 가깝습니다.

인식 결과가 기존 시스템으로 흘러 들어가려면 사람이 아니라 프로그램이 받을 수 있는 형태여야 합니다. OCR API는 그 통로입니다. 문서를 보내면 값과 위치와 신뢰도가 구조화된 데이터로 돌아오고, 그 데이터가 심사 시스템이나 문서관리시스템으로 곧장 넘어갑니다.

OCR API의 정확한 정의: 구축형과 무엇이 다른가

API 연동과 구축형 도입, 세 가지 축의 차이

첫째, 대상이 다릅니다. API 연동은 인식 기능만을 대상으로 삼습니다. 요청과 응답의 규격을 맞추면 되고 모델이 어디에서 어떻게 도는지는 관여하지 않습니다. 구축형은 모델과 추론 환경, 저장소, 운영 도구까지를 대상으로 삼습니다. 고객사 내부에 하나의 시스템을 세우는 일에 가깝습니다.

둘째, 목표가 다릅니다. API 연동의 목표는 빠르게 붙여 보고 성능과 적합성을 확인하는 것입니다. 초기 검증 단계에서 문서 몇 종을 던져 결과를 받아 보는 데 며칠이면 충분합니다. 구축형의 목표는 원본 문서를 외부로 내보내지 않으면서 운영 규모의 처리량을 감당하는 것입니다.

셋째, 성과지표가 다릅니다. API 연동에서는 응답 정확도와 지연 시간, 처리량 한도를 봅니다. 구축형에서는 여기에 더해 필요한 GPU 사양과 폐쇄망 설치 가능 여부, 모델 갱신 절차, 감사 로그 요건을 함께 봅니다. 실제 운영에서 확인된 수치를 들면, API 방식의 인식 정확도가 99.3% 수준으로 확인된 사례가 있고, 처리 성능은 100장에 3.5분, 500장에 17분, 시간당 약 1,800장 규모가 측정되었습니다.

두 방식은 대체 관계가 아닙니다. 초기 검증은 API로 빠르게 진행하고 운영 단계에서 구축형으로 옮기는 경로가 일반적입니다. 그래서 검토 단계에서 확인해야 할 것은 API의 성능만이 아니라 같은 엔진을 구축형으로도 제공하는지 여부입니다.

업무에 투입할 수 있는 OCR API의 6가지 조건

실제 연동에 들어가는 OCR API의 6가지 조건

첫째, 응답 스키마가 업무 기준으로 정의되어야 합니다. 문자열 한 덩어리를 돌려주는 응답으로는 시스템 입력을 자동화할 수 없습니다. 문서 유형별로 어떤 키에 어떤 값이 담겨 오는지가 사전에 정의되어 있어야 수신 측 개발이 가능합니다.

둘째, 값의 위치와 신뢰도가 함께 와야 합니다. 각 값에 대해 원문의 좌표와 확신 정도가 따라오면 낮은 신뢰도 항목만 검수 화면에 띄우는 구성이 가능해집니다. 이 두 필드가 없으면 결국 전수 검수로 돌아갑니다.

셋째, 지원 포맷이 실제 접수 파일을 덮어야 합니다. 업무 현장에는 PDF와 이미지만 들어오지 않습니다. 한글 워드프로세서 문서와 오피스 문서, 스프레드시트, 스캔 이미지가 함께 접수됩니다. 지원 목록에 이 형식들이 포함되어 있는지 확인이 필요합니다.

넷째, 대량 처리 경로가 있어야 합니다. 건별 동기 호출만 제공되면 월말이나 특정 시간대에 몰리는 물량을 감당할 수 없습니다. 배치 처리와 작업 상태 조회, 완료 알림을 위한 콜백이 함께 제공되는지 확인하십시오.

다섯째, 인증과 권한 관리가 갖추어져야 합니다. 문서에는 개인정보가 담기므로 키 발급과 회수, 호출 이력 기록, 역할별 접근 제어가 필요합니다. 금융과 공공에서는 감사 대응을 위해 이 로그가 요구됩니다.

여섯째, 구축형 병행 제공 여부를 확인해야 합니다. 지금은 API로 충분해도 보안 요건이 강화되거나 처리량이 늘면 내부 설치가 필요해집니다. 그때 엔진을 통째로 바꾸지 않아도 되는지가 도입 판단의 중요한 기준입니다.

OCR API의 실제 적용 방법

연동 지점을 먼저 정합니다

설계의 첫 결정은 인식 결과를 어디에 꽂을지입니다. 문서관리시스템에 원본과 함께 적재할지, 심사 시스템의 입력 항목으로 바로 넣을지, 자동화 도구를 거쳐 기간계로 보낼지에 따라 필요한 응답 형태가 달라집니다.

실제 운영 구성을 보면 인식 결과가 문서관리시스템에 적재되고, 그다음 자동화 도구를 거쳐 기간계 시스템에 등록되는 흐름이 흔합니다. 이 연결이 설계되어 있지 않으면 담당자가 결과를 다시 입력하게 되므로, 연동 지점 정의를 인식 성능 검증보다 앞에 두는 편이 낫습니다.

요청과 응답의 규격을 맞춥니다

전형적인 구성은 파일 업로드 방식의 요청과 구조화된 응답의 조합입니다. 문서를 전송하면 형식 변환과 레이아웃 분석, 문자 인식, 후처리를 거쳐 결과가 생성되고, 텍스트와 위치 정보, 신뢰도가 함께 반환됩니다. 결과 형식은 용도에 따라 나누어 받는 편이 좋습니다. 시스템 입력이 목적이면 항목 경로를 키로 갖는 구조화 데이터로, 검색과 생성에 쓸 문서라면 구조가 보존된 마크업 형태로 받습니다.

대량 처리에서는 작업 단위로 요청을 등록하고 상태를 조회하는 방식이 안정적입니다. 완료 시점을 알리는 콜백을 함께 쓰면 수신 측에서 폴링 부담을 덜 수 있습니다.

국내 환경에서의 OCR API

국내 금융과 공공 조직의 상당수는 망분리 규정을 적용받습니다. 업무망에서 외부 API를 호출할 수 없으므로, 공개된 클라우드 API만 제공하는 솔루션은 검토 초기에 제외되는 경우가 많습니다. 내부망에 API 서버를 세우는 구성이 가능한지를 먼저 확인하셔야 합니다.

문서 형식도 국내 조건이 있습니다. 한글 워드프로세서 문서가 실제 처리 대상에 포함되는지, 팩스로 접수된 저화질 스캔본에서도 응답 품질이 유지되는지를 실제 파일로 확인하는 편이 좋습니다. 공개된 예시 문서로 측정한 값과 자사 접수함의 문서로 측정한 값은 다르게 나옵니다.

오류 응답과 재시도 규칙을 정합니다

연동에서 성공 경로보다 손이 많이 가는 쪽은 실패 경로입니다. 파일이 열리지 않는 경우, 형식이 지원되지 않는 경우, 페이지가 비어 있는 경우, 처리 중 시간이 초과된 경우가 각각 다른 대응을 요구하기 때문입니다.

설계할 때 정해야 할 것은 세 가지입니다. 먼저 어떤 오류가 재시도로 해결되는지 구분합니다. 일시적인 자원 부족은 다시 보내면 되지만 지원하지 않는 형식은 몇 번을 보내도 같은 결과가 나옵니다. 다음으로 재시도 간격과 횟수를 정합니다. 마지막으로 재시도로도 해결되지 않은 건을 어디에 쌓아 둘지 정합니다. 이 대기열이 없으면 실패한 문서가 조용히 사라집니다.

오류 코드가 원인별로 구분되어 오는지도 확인 항목입니다. 모든 실패가 같은 코드로 돌아오면 수신 측에서 대응을 나눌 방법이 없습니다.

검증 환경과 운영 환경을 나눕니다

인증 키를 하나만 발급받아 검증과 운영에 함께 쓰면 문제가 생깁니다. 검증 중에 보낸 시험 문서가 운영 통계에 섞이고, 연동을 손보다가 운영 호출이 끊기는 일이 발생하기 때문입니다.

키를 분리하고 호출 대상 주소도 나누어 두면 이런 사고를 막을 수 있습니다. 여기에 더해 검증 환경에서는 실제 개인정보가 담긴 문서 대신 마스킹된 표본을 쓰는 규칙을 함께 두시기 바랍니다. 검증 단계의 로그는 운영보다 접근 통제가 느슨한 경우가 많습니다.

배포 시점도 나눕니다. 추출 기준이나 응답 스키마가 바뀌면 검증 환경에서 먼저 확인하고 승인 절차를 거쳐 운영에 반영하는 흐름을 만들어 두면 변경이 사고로 이어지지 않습니다.

처리량 한도와 과금 단위를 확인합니다

도입 검토에서 자주 빠뜨리는 항목이 한도입니다. 초당 호출 수와 동시 처리 건수, 한 요청에 담을 수 있는 페이지 수에 제한이 있는지 확인하십시오. 월말이나 특정 시간대에 물량이 몰리는 업무라면 이 한도가 실제 처리 속도를 결정합니다.

과금 단위도 함께 봅니다. 요청 건수 기준인지 페이지 수 기준인지에 따라 비용 예측이 크게 달라집니다. 한 건에 열다섯 페이지가 들어오는 심사 업무라면 두 방식의 차이가 열 배 이상으로 벌어질 수 있습니다.

내부 설치 방식에서는 한도가 계약이 아니라 하드웨어로 정해집니다. 이 경우에는 필요한 가속기 규모와 증설 경로를 미리 확인해 두는 편이 낫습니다.

자주 묻는 질문