한 줄 정의

OCR은 이미지나 스캔 문서 안의 글자를 기계가 다룰 수 있는 텍스트와 위치 정보로 바꾸는 기술이야. 영수증 사진, PDF 스캔본, 제품 라벨, 스크린샷처럼 사람 눈에는 글자로 보이지만 컴퓨터에는 픽셀로만 들어오는 자료를 검색하고 저장할 수 있게 바꿔 줘.

여기서 중요한 구분이 있어. OCR은 먼저 “무슨 글자가 어디에 있나”를 뽑는 층이고, 문서 인텔리전스는 그 다음에 표, key-value, 송장 항목, 계약 조항 같은 구조를 해석하는 층에 가까워. 둘을 섞으면 문서 자동화 제품이 실제로 무엇을 해 주는지 금방 흐려져.

어떻게 작동하나

기본 흐름은 단순해. 이미지나 문서 페이지를 넣으면 시스템이 글자 영역을 찾고, 줄과 단어를 나누고, 각 단어의 텍스트와 위치, 때로는 confidence를 돌려줘. Google Cloud Vision 기준으로는 일반 사진의 표지판이나 라벨처럼 넓은 이미지를 처리하는 경로와, 글자가 빽빽한 문서에서 page, block, paragraph, word 정보를 돌려주는 경로가 따로 있어.

Microsoft 쪽도 비슷하게 나눠. 거리 표지판, 포스터, 제품 라벨처럼 일반 이미지에 가까운 입력은 이미지용 OCR 경로가 맞고, 책, 리포트, 송장, 스캔 PDF처럼 문서 자체가 작업 대상이면 Document Intelligence Read OCR 쪽이 맞아. 같은 OCR이라도 실시간 사용자 화면에 넣을지, 2,000페이지짜리 PDF를 비동기로 처리할지에 따라 설계가 달라져.

AI 스택에서는 OCR 결과가 보통 RAG나 검색 인덱스의 원료가 돼. 문서를 글자로 바꾼 뒤 임베딩을 만들고, 질문이 들어오면 관련 문서 조각을 찾아 모델에게 넣는 식이야. 다만 요즘에는 멀티모달 모델과 직접 이미지 임베딩도 같이 봐야 해. Google은 2026년 5월 5일 Gemini API File Search에 멀티모달 지원, custom metadata, page-level citation을 추가했다고 발표했고, DEV 가이드는 gemini-embedding-2를 쓰면 이미지를 OCR에만 기대지 않고 직접 임베딩할 수 있다고 설명해.

왜 중요한가

OCR이 중요한 이유는 문서 자동화의 첫 단추가 여기서 끼워지기 때문이야. 예를 들어 보험 청구 사진에서 손상 설명과 금액을 읽거나, 물류 송장에서 주소와 주문번호를 뽑거나, 오래된 PDF를 검색 가능한 문서로 바꾸려면 먼저 글자가 안정적으로 나와야 해. 글자 추출이 흔들리면 그 뒤의 Vision-Language Model 답변, 표 파싱, RAG 검색도 같이 흔들려.

반대로 OCR이 필요 없는 장면도 생기고 있어. 제품 사진에서 색감이 비슷한 운동화를 찾거나, 차트 이미지의 전반적 모양을 검색하거나, 디자인 시스템에서 버튼 생김새가 비슷한 컴포넌트를 찾는 일은 글자보다 시각 의미가 더 중요해. Gemini Embedding 2 글은 텍스트, 이미지, 영상, 오디오, 문서를 하나의 embedding space에 놓는 모델이라고 설명하고, 한 호출에서 8,192개 text token과 6개 image까지 다룰 수 있다고 적어. 이런 흐름에서는 OCR만으로 이미지를 설명하려고 하면 오히려 중요한 시각 정보를 버릴 수 있어.

그래서 OCR이라는 말이 나오면 먼저 질문을 갈라 보는 게 좋아. 정확한 문자열, 페이지 번호, searchable PDF, 필드 검증이 필요하면 OCR이 중심이야. 이미지의 분위기, 도표 모양, 사진 속 물체, 화면 구성까지 같이 찾고 싶으면 OCR에 멀티모달 검색이나 VLM을 같이 붙이는 쪽이 더 맞아.

주의해서 볼 점

OCR 성능은 입력 품질에 크게 묶여 있어. Microsoft 문서 기준으로 이미지 치수는 50 x 50픽셀부터 10,000 x 10,000픽셀까지이고, 1024 x 768 이미지에서는 추출할 글자 높이가 최소 12픽셀이어야 해. 이 정도 제한만 봐도 작은 캡처, 흔들린 사진, 접힌 영수증, 희미한 도장, 필기체가 왜 자주 실패하는지 감이 와.

또 OCR 결과가 곧 정답은 아니야. 페이지와 단어 위치가 맞아도 표 셀을 잘못 묶거나, “0”과 “O”를 섞거나, 문단 순서를 틀리면 업무 자동화에서는 큰 차이가 나. 그래서 실제 도입 전에는 전체 문서 정확도보다 필드 단위 Eval을 먼저 만들어야 해. 송장 번호, 날짜, 금액, 이름처럼 업무가 깨지는 항목을 따로 재고, 모델 교체나 전처리 변경 뒤 같은 묶음을 다시 돌려야 해.

마지막으로 멀티모달 검색이 OCR을 없애는 건 아니야. 이미지를 직접 임베딩해서 찾는 방식은 시각 검색에 강하지만, 규제 문서나 회계 자료처럼 “원문 어디에 그렇게 쓰여 있나”를 보여줘야 하는 작업에서는 OCR 텍스트와 page citation이 여전히 필요해. OCR은 낡은 우회로라기보다, 문서 기반 AI에서 감사 가능한 텍스트 흔적을 만드는 입력 계층이라고 보는 편이 맞아.