13.2.5 기존 OCR 솔루션의 한계와 LLM의 보완적 역할

13.2.5 기존 OCR 솔루션의 한계와 LLM의 보완적 역할

본 서적에서 설계하고 있는 파이프라인 아키텍처의 구조도를 살펴보면, 우리는 최전방의 물리적 픽셀을 문자로 치환하는 비전(Vision) 단계에서 여전히 구세대 기술인 광학 문자 인식(OCR, Optical Character Recognition) 레이어(Layer)를 사용하고, 그 뒤를 이어받아 초거대 언어 모델(LLM)이 추출을 수행하는 형태의 **‘하이브리드 병렬(Hybrid) 파이프라인’**을 채택하고 있다. (비전 언어 모델(VLM)을 단일로 사용하는 방법론은 13.11절에서 별도로 다룬다).

어째서 기존의 검증된 OCR 솔루션만으로는 이 이종 재무 문서들을 통제할 수 없었던 것일까? 과거 수십 년간 엔터프라이즈의 백오피스 문서 자동화를 독점해 온 전통적 룰 기반(Rule-based) OCR 파이프라인들은 치명적이고 태생적인 인프라적 한계를 지니고 있었다.

1. 정규 표현식(Regex)과 템플릿 매핑 하드코딩의 파멸

전통적인 OCR 모듈 시스템은 단순히 이미지 공간 내부의 픽셀 조각들을 1차원적인 길고 거친 문자열 배열(String Array)로 긁어 모으는 하급 ‘스크래퍼(Scraper)’ 역할에 불과하다.
따라서 과거의 백엔드 엔지니어들은 이 쏟아지는 무질서한 문자들 사이에서 우리가 원하는 타겟 값(예: 총금액)을 찾기 위해, (?<=Total:\s)\d+(?:,\d{3})*(?:\.\d{2})? 와 같은 우주에서 가장 끔찍하고 유지보수가 불가능한 정규 표현식을 작성하거나, 특정 공급자의 템플릿(Template) 별로 X, Y 픽셀 좌표계를 일일이 수동으로 맵핑하는 가혹한 하드코딩(Hard-coding) 노가다 작업을 수행해야만 했다.

만약 어느 날 벤더사가 영수증의 템플릿 디자인을 임의로 변경하여 Total Amount라는 단어의 위치를 아래로 10픽셀 내리거나, Total이 아닌 합계라는 단어를 쓰기 시작한다면 어떤 일이 벌어질까? 기존의 수십억짜리 템플릿 기반 RPA 시스템은 그 미세한 변화를 방어하지 못한 채 즉시 Parse Error 정규식 파단을 뿜어내며 시스템이 일제히 셧다운(Shutdown) 되는 비극을 맞이했다.

2. 문맥적 의존성(Contextual Dependency) 추론의 완전한 부재

기계적 OCR은 “시각의 척수 반사 신경“일 뿐 종합적으로 판단하는 “두뇌“가 아니다.
청구서 내에 숫자 데이터가 20개 넘게 나타날 때, 어느 숫자가 ’물건의 공급가액’이고 어느 것이 시스템 장부에 ’진짜로 지불(Pay)해야 할 최종 총 결제액’인지 OCR 레이어는 절대 연역적으로 추론할 수 없다. 오직 단방향으로 글자를 뱉어내고 책상에 던져놓은 채 자신의 프로세스를 종료할 뿐이다.

3. LLM의 위대한 보완: 파편화된 위상 복원과 의미론적 대수 추론

바로 이 절망적이고 파괴적인 지점에서, 기계의 ’단기 문맥 사고력’인 거대 언어 모델(LLM)이 붕괴 직전의 파이프라인을 구원하기 위해 구원 등판한다.

LLM 엔진은 2차원 공간이 완전히 붕괴되고 위치가 섞여버린 OCR의 거친 1차원 텍스트 덤프를 프롬프트 컨텍스트(Context)로 쑤셔 넣듯 주입받는다. 그러면 LLM 내부의 거대한 딥러닝 트랜스포머 어텐션(Attention) 메커니즘 층은, 노이즈가 낀 글자들과 위치가 뒤틀린 표 데이터 사이의 **‘숨겨진 의미론적 위상(Semantic Topology)’**을 단어 토큰 간의 확률적 연관 관계를 통해 기계 스스로 기적처럼 완벽하게 역으로 복원해 낸다.

벤더사가 자기들 마음대로 템플릿 레이아웃을 100번 바꾸어도, 폰트나 국가별 언어가 달라도 LLM은 아무런 타격을 받지 않는다. LLM은 유연하게 어텐션을 집중하여 *“이 텍스트 덤프의 문맥상, 결국 가장 높은 확률로 타당한 결론적 금액은 이 숫자일 수밖에 없다”*는 문맥적 대수 추론을 통해, 13.2.2절에서 우리가 정의하고 비워둔 Pydantic 객체의 스키마 구멍에 가장 알맞은 데이터 값들을 스스로 찾아서 끼워 맞춰주는 기적을 행한다.

4. 역할의 분담: 검증 오라클의 궁극적 당위성

그러나 우리는 이 기적에 도취해서는 안 된다. 13.1.2절에서 누차 강조했듯 이 위안을 주는 추론 과정에는 필연적으로 부산물인 파괴적인 ’환각 방사능’이 섞여 나오기 때문이다.
결론적으로 본 13장의 궁극적 아키텍처 설계 사상은 다음과 같이 위대한 삼위일체(Trinity) 구조로 요약된다.

“어리석은 눈을 가진 OCR이 텍스트를 무지성으로 식별하여 넘기면, 천재적이지만 지독한 망상증(Hallucination)에 빠진 LLM이 그 위상 문맥을 추론하여 데이터를 추출해 낸다. 그리고 최종적으로 파이프라인의 백엔드 끝단에서, 피도 눈물도 없는 파이썬(Python) 유효성 검증 오라클 시스템이 융통성 없는 검문소의 총구를 겨누고 환각 데이터를 철저히 요격하며 데이터베이스 원장을 성역으로써 지켜낸다.”

이 완벽하고 처절한 공학적 역할 분담 시나리오의 기초 설계를 끝으로, 이제 다음 장 13.3절에서 우리는 이 삼위일체의 최후의 파수꾼인 **‘1단계 구조적 유효성 검사 오라클’**의 파이썬 코드를 본격적으로 타건하고 시스템 메모리 위에 컴파일 할 것이다.