Tech Dive

DocuSee 릴리즈에서 금융권 현장 제약을 이기는 방법

안녕하세요, Frontier AI Lab 유혜원입니다.

저희 랩은 다양한 문서를 AI가 이해하고 활용할 수 있는 형태로 변환하기 위한 AI Document Parser인 DocuSee를 개발하고 있습니다. DocuSee는 OCR, 표 검출 및 구조 인식, 레이아웃 분석, 차트 및 다이어그램 인식 등 여러 문서 AI기술을 하나의 파이프라인으로 연결해 PDF, PPT, HWPX, DOCX, 이미지 등 다양한 문서 형식에서도 의미있는 정보를 추출하고 구조화하는 것을 목표로 합니다.

01.jpg

그림1. DocuSee 파이프라인


지난 글 에서는 DocuSee를 금융권 RAG 환경에 적용하면서 문서의 의미적 흐름뿐 아니라 금융권 운영환경에서 요구되는 구조적 일관성과 검색 재현성을 함께 고려하게 된 과정을 소개했습니다.

이번 글에서는 실제 금융권 환경에 DocuSee를 적용 하면서 마주했던 어려움과 이를 해결한 과정을 소개하고자 합니다.


레이아웃 분석 모델을 VLM 기반으로 전환

DocuSee 파이프라인에서 레이아웃 분석은 문서 내 요소를 구분하고, 각 요소를 어떤 후속 모델로 전달할지 결정하는 중요한 역할을 합니다.

특히 차트나 다이어그램처럼 이미지 기반으로 해석해야 하는 요소는 레이아웃 분석 단계에서 정확히 검출되어야 검출된 이미지를 모델로 전달할 수 있습니다.  또한 레이아웃 분석은 문서의 읽기 순서에도 영향을 줍니다. 금융권 문서처럼 본문, 표, 이미지, 주석, 캡션이 복잡하게 배치된 경우에는 요소를 어떻게 구분하느냐에 따라 읽기 순서가 달라집니다.

기존 DocuSee는 컴퓨터 비전(computer vision) 기반 레이아웃 모델을 사용하고 있었습니다. 일반적인 문서에서는 문단의 위치, 크기, 시각적 패턴만으로도 본문, 표, 이미지 영역을 어느 정도 안정적으로 구분할 수 있었습니다. 하지만 실제 금융권 문서는 구조가 매우 다양했습니다. 상품 설명서, 약관, 업무 매뉴얼, 내부 규정처럼 문서 유형마다 형식이 달랐고, 같은 문서 안에서도 페이지별 구성이 일정하지 않은 경우가 많았습니다.

이처럼 문서 구조가 다양하다 보니 단순히 문단의 크기나 위치만으로 각 영역이 어떤 요소인지 판단하기 어려웠습니다. 예를 들어 비슷한 크기의 영역이라도 어떤 문서에서는 본문 문단이고, 다른 문서에서는 이미지 설명일 수 있습니다. 

결국 금융권 문서에서는 문서 요소의 크기나 위치뿐 아니라, 페이지 안에서 해당 요소가 어떤 문맥에 놓여 있는지 함께 고려할 필요가 있었습니다. VLM 기반 모델은 페이지의 시각적 배치뿐 아니라 주변 텍스트와 문서 흐름을 함께 고려할 수 있기 때문에, 금융권 문서처럼 레이아웃이 일정하지 않은 문서에서 더 적합하다고 판단했습니다. 이에 저희 팀은 레이아웃 분석 모델을 컴퓨터 비전 기반에서 VLM 기반으로 전환하는 방향을 선택했습니다.

그 결과 문서 요소를 더 안정적으로 구분할 수 있었고, 차트·다이어그램 인식 모델로 전달해야 할 이미지 영역과 문서의 읽기 순서를 보다 일관되게 처리할 수 있었습니다.


인터넷이 되지 않는 내부망 개발 환경

두 번째 어려움은 금융권 보안 특성상의 폐쇄망 환경입니다.

일반적인 개발 환경에서는 원격 접속을 통해 서버에 접근하고 필요한 라이브러리를 인터넷에서 설치하며 문제가 발생하면 로그를 확인해 바로 수정할 수 있습니다. 하지만 금융권 내부망에서는 이러한 방식이 대부분 제한되었습니다.

외부 인터넷과 분리된 환경이었기 때문에 원격 구축이 어려웠고, 배포와 업데이트를 하기 위해서는 현장 방문이 필수적이었습니다. 운영 서버는 업무 영향도를 고려해 정해진 시간에만 업데이트할 수 있어 야간 현장 대응을 해야하는 상황도 있었습니다.

이 환경에서 가장 큰 제약은 인터넷을 통한 라이브러리 설치가 불가능하다는 점이었습니다. 누락된 패키지가 있으면 현장에서 바로 설치할 수 없고, 외부 환경에서 이미지를 다시 만든 뒤 내부망으로 반입해야 했습니다.

이를 해결하기 위해 먼저 DocuSee 실행에 필요한 라이브러리, 모델 파일, 전처리·후처리 코드, 실행 스크립트를 모두 Docker 이미지에 포함해 패키징해서 내부망에서는 추가 다운로드 없이 이미지 실행만으로 서비스가 구동될 수 있게 했습니다.

하지만 모든 의존성을 포함하다 보니 Docker 이미지 용량이 커졌고, 폐쇄망 환경에서는 이미지 반입과 업로드에도 많은 시간이 소요되었습니다. 따라서 불필요한 라이브러리, 캐시, 중복 파일을 정리하고 실행에 필요한 구성만 남기는 최적화 작업을 진행했습니다.

그 결과 폐쇄망에서도 추가 다운로드 없이 구동 가능한 구조를 유지하면서, 이미지 업로드와 배포에 걸리는 시간을 줄일 수 있었습니다.

02.jpg



사전 테스트가 어려운 운영 플랫폼

세 번째 어려움은 고객사 내부의 AI 운영 플랫폼과의 호환성이었습니다.

DocuSee는 단일 모델 서버가 아니라 OCR, 레이아웃, 표 인식, 차트 및 다이어그램 인식, 전처리, 후처리가 결합된 복합 추론 서버입니다. 여러 모델과 로직이 함께 동작하기 때문에 파일 접근 권한, 실행 권한, 파일 경로, GPU 사용 방식, 컨테이너 내부 사용자 권한, 마운트 경로 등의 영향을 많이 받습니다.

문제는 고객사 운영 플랫폼을 사전에 완전히 동일하게 재현하기 어렵다는 점이었습니다. 내부 유사 환경에서 테스트를 통과한 Docker 이미지도 고객사 플랫폼에 배포하면 오류가 발생하는 경우가 있었습니다.

대부분은 권한 관련 문제였습니다. 특정 파일을 읽지 못하거나, 실행 스크립트 권한이 없거나, 모델 캐시 경로와 임시 파일 경로에 접근하지 못하는 문제가 반복되었습니다.

이를 해결하기 위해 Docker 이미지 생성 방식을 다시 정리했습니다. 모델 파일, 실행 스크립트, 로그 경로, 임시 저장 경로 등 추론 과정에서 접근하는 리소스의 권한을 빌드 단계에서 명확히 설정했습니다.

또한 실행 명령어를 단순화하고, entrypoint와 실행 스크립트를 고객사 플랫폼에서 바로 동작할 수 있는 형태로 정리했습니다. 환경 변수나 경로 설정도 최대한 이미지 내부에서 처리하도록 구성했습니다.

디버깅이 제한된 환경을 고려해 로그도 개선했습니다. 어떤 단계에서 어떤 파일이나 경로 접근에 실패했는지 확인할 수 있도록 로그 메시지를 정리해, 현장에서 문제 원인을 빠르게 파악할 수 있도록 했습니다.

이후 여러 차례 테스트와 수정 과정을 거쳐 고객사 내부 플랫폼에서도 안정적으로 실행 가능한 이미지를 만들 수 있었습니다.


마무리하며

DocuSee 금융권 납품 프로젝트는 모델 개발뿐 아니라 실제 고객 환경에 AI 서비스를 안정적으로 구축하는 과정의 중요성을 확인한 경험이었습니다.

이를 통해 DocuSee는 문서를 더 잘 이해하는 모델을 넘어 보안 요구사항이 높은 산업 환경에서도 운영 가능한 Document AI 솔루션으로 발전할 수 있었습니다.

앞으로도 저희 랩은 다양한 고객 환경에서 DocuSee가 안정적으로 활용될 수 있도록 모델 품질과 운영 안정성을 함께 개선해 나가겠습니다.

유혜원

Frontier AI Lab에서 모델 경량화 및 추론 최적화를 맡고 있습니다.

이전 글