수억 건의 스캔 PDF를 처리하는 Amazon Bedrock 파이프라인

스캔된 PDF 파일에서 필요한 정보를 찾기 위해 사람이 일일이 화면을 보고 텍스트를 옮겨 적거나 오타를 수정하는 작업은 단순 반복 노동의 전형이다. 특히 텍스트 편집이 불가능한 이미지 기반의 스캔 PDF가 수억 건 규모로 쌓여 있고 매일 새로운 문서가 추가되는 환경에서는 사람이 직접 처리하는 방식으로는 데이터 적체를 해결할 수 없다. Amazon Bedrock은 이러한 대규모 문서 데이터에서 정보를 자동으로 추출하는 온디맨드 및 배치 추론 파이프라인를 구축해 수작업 없이 데이터를 표준화한다.

처리 대상 데이터는 텍스트 편집이 불가능한 이미지 기반의 스캔 PDF와 일반 텍스트 파일이다. 실제 사례로 수억 건의 토지 임대차 계약서가 스캔 PDF 형태로 적체된 상황에서 이 파이프라인을 적용한다. 시스템의 핵심 도구는 생성형 AI 애플리케이션 구축을 위한 완전 관리형 서비스인 Amazon Bedrock과 프롬프트의 생성 및 버전 관리를 수행하는 Amazon Bedrock Prompt Management다. 이 도구들을 통해 문서마다 서로 다른 형식과 표기 관례를 가진 데이터들을 정밀하게 분석하고 추출한다.

추론 경로는 처리 시급성과 비용 효율성에 따라 두 가지 옵션으로 나뉜다. 실시간 응답이 필요한 시급한 요청에는 온디맨드(On-demand) 추론을 사용한다. 온디맨드 방식은 문서를 하나씩 개별적으로 처리하며 호출 후 수 초 내에 결과를 반환하는 특성을 가진다. 반면 수많은 문서를 한꺼번에 처리해야 하는 대규모 작업에는 비용 최적화에 유리한 배치(Batch) 추론을 선택한다. 배치 방식은 모델 호출을 비동기적으로 처리하여 대량의 데이터를 효율적으로 처리하며 운영 비용을 낮춘다.

추출된 데이터는 정형화되지 않은 문서의 특성을 극복하기 위해 표준화된 JSON 문자열 형태로 변환된다. JSON은 데이터를 효율적으로 교환하기 위한 경량의 텍스트 기반 데이터 포맷이다. 토지 임대차 계약서처럼 문서마다 리스트, 표, 도면 등 형식이 제각각인 경우에도 LLM을 통해 동일한 구조의 JSON으로 변환하여 데이터 일관성을 확보한다. 최종 결과물은 키-값 및 문서 데이터 모델을 지원하는 NoSQL 데이터베이스인 Amazon DynamoDB에 저장된다. 사용자는 처리 속도가 중요한 개별 요청과 비용 절감이 핵심인 대규모 작업 사이에서 파이프라인을 선택해 운영 비용과 응답 속도를 최적화한다.

초 단위 응답을 위한 온디맨드 파이프라인의 작동 구조

단 한 장의 서류를 확인하기 위해 수백 장의 뭉치가 처리될 때까지 기다리는 것은 실무자에게 큰 손실이다. 즉각적인 데이터 확인이 필요한 요청은 온디맨드 파이프라인이 담당한다. 이 구조는 SQS FIFO(First-In, First-Out, 선입선출) 큐에서 시작해 결과 반환까지 수 초 내에 완료한다. 메시지가 도착하면 AWS Lambda(서버리스 컴퓨팅 서비스)가 트리거되어 Amazon S3에서 PDF를 다운로드한다. 스캔된 PDF는 텍스트 수정이 불가능하므로 모델이 이해할 수 있도록 PNG 이미지로 변환하는 과정을 거친다. 이후 Bedrock Prompt Management에서 프롬프트를 가져와 LLM 추론을 수행하고 최종 결과를 Amazon DynamoDB(NoSQL 데이터베이스)에 저장한다.

순서 보장과 정확히 한 번의 전달을 위해 SQS FIFO 큐를 사용한다. 외부 시스템에서 AWS CLI(명령줄 인터페이스)나 SDK API를 통해 메시지를 생성해 요청을 보낼 수 있다.

aws sqs send-message --queue-url <QUEUE_URL> --message-body file://message_txt.txt

전송되는 메시지 파일에는 문서 ID, LLM 모델 ID, 프롬프트 ID와 버전, 시스템 프롬프트 ID와 버전 정보가 JSON 형태로 포함된다. Lambda 함수는 Bedrock이 데이터 추출 결과를 반환한 직후에만 해당 큐 메시지를 삭제하도록 설계되어 처리의 완결성을 확보한다.

멀티모달 모델의 입력 제한은 처리 단위의 물리적 기준이 된다. Claude 4 Sonnet 모델은 한 번의 멀티모달 호출당 최대 20장의 이미지만 입력받을 수 있다. 20페이지를 초과하는 문서는 20페이지 단위의 청크(Chunk, 덩어리)로 분할해 처리하는 전략을 쓴다. 분할된 각 데이터는 `doc_id`와 `chunk_count`, 그리고 chunk_id 식별자와 함께 DynamoDB에 기록된다. 모델 성능 지표와 추출 결과가 이 식별자들과 함께 저장되므로, 나중에 분할된 데이터를 다시 하나의 문서로 통합해 분석할 수 있다.

문서 형식에 따른 추출 정확도를 높이기 위해 Amazon Bedrock Prompt Management를 활용한다. 이 서비스는 리전당 최대 50개의 프롬프트를 생성할 수 있으며, 개별 프롬프트당 최대 10개의 버전을 관리하는 제약이 있다. SQS 메시지에 명시된 프롬프트 ID와 버전 정보를 기반으로 Lambda가 실행 시점에 해당 프롬프트 본문을 호출한다. 이는 토지 임대 문서처럼 형식이 제각각인 데이터셋에서 각 문서의 특성에 맞는 최적의 프롬프트를 동적으로 할당해 추출 성능을 극대화하는 장치가 된다.

비용 최적화를 위한 배치 추론 파이프라인의 구현

운영자는 처리 속도보다 비용 절감이 절실한 시점에 배치 처리를 선택한다. Amazon EventBridge Scheduler(정기적 작업 예약 서비스)가 정해진 시간에 AWS Lambda(서버리스 함수)를 실행하며 파이프라인이 시작된다. 이 함수는 SQS Standard(고처리량 표준 큐)에 쌓인 메시지를 확인한다. SQS Standard는 메시지 순서를 엄격하게 보장하지 않는 대신 처리량이 매우 높아 수억 건의 대량 데이터를 처리하는 데 적합하다. Lambda는 큐에서 문서 ID와 LLM 모델 ID, 프롬프트 및 시스템 프롬프트의 ID와 버전 정보를 추출한다.

Amazon Bedrock 배치 추론 작업은 최소 100건의 레코드가 확보되어야 실행 가능하다는 제약이 있다. Lambda 함수는 작업을 시작하기 전 큐에 쌓인 메시지 수가 이 기준을 충족하는지 먼저 확인한다. SQS Standard의 특성상 동일한 메시지가 중복으로 전달될 가능성이 존재한다. 이를 방지하기 위해 Lambda 함수 내부에서 이미 처리된 메시지를 식별하고 중복된 요청은 무시하도록 구현했다. 검증된 데이터는 JSONL(각 줄이 독립적인 JSON 객체인 파일 형식) 아티팩트로 변환되어 S3에 저장된다.

단일 배치 작업은 하나의 모델만 처리할 수 있다는 제약이 있다. SQS 메시지에 서로 다른 모델 ID가 혼재되어 있을 경우 폴링(특정 조건의 데이터를 선택하는 방식) 메커니즘을 적용한다. Lambda 함수는 큐 내의 메시지들을 분석해 가장 빈번하게 지정된 모델 ID를 선택하고 이를 해당 배치 작업의 기준 모델로 설정한다. 이후 Amazon Bedrock Batch Inference Job이 S3에 저장된 JSONL 아티팩트를 읽어 비동기적으로 추론을 수행하며 결과물을 다시 S3 출력 버킷에 저장한다.

추론 작업이 완료되면 Amazon Bedrock은 Amazon EventBridge에 작업 상태 변경 이벤트를 전송한다. 설정된 EventBridge 규칙이 이 이벤트를 포착해 후처리 Lambda를 즉시 실행한다. 후처리 Lambda는 S3 출력 버킷에서 추론 결과가 기록된 JSONL 파일을 가져와 데이터를 파싱한다. 최종적으로 추출된 토지 임대 관련 속성값들은 Amazon DynamoDB(키-값 기반 NoSQL 데이터베이스)에 저장되며 전체 공정이 마무리된다.

온디맨드 vs 배치: 처리 방식 및 인프라 비교

현장에서 개발자가 가장 먼저 고민하는 지점은 지금 당장 결과가 필요한지 아니면 밤새 수백만 건을 처리해도 되는지 결정하는 순간이다. 실시간성이 중요한 요청에는 온디맨드 추론 방식을 사용한다. 이 방식은 문서를 하나씩 처리하며 수 초 내에 결과를 반환하는 구조다. 사용자는 요청 후 즉시 결과물을 확인할 수 있어 인터랙티브한 작업에 유리하다.

온디맨드 파이프라인은 SQS FIFO(First-In First-Out, 먼저 들어온 데이터를 먼저 처리하는 큐)를 통해 메시지를 전달한다. 메시지가 도착하는 즉시 Lambda(서버리스 컴퓨팅 서비스) 함수가 실행되어 추론을 시작한다. FIFO 큐를 선택한 이유는 메시지의 순서를 엄격하게 보장하고 정확히 한 번만 전달하는 특성이 필요했기 때문이다. 이 과정에서 PDF 다운로드와 이미지 변환이 실시간으로 이루어지며 최종 결과가 DynamoDB에 저장된다. 개별 호출마다 비용이 발생하지만 응답 속도가 매우 빨라 시간 제약이 있는 작업에 적합하다.

대량의 데이터를 처리할 때는 배치 추론 파이프라인을 사용한다. 여기서는 고처리량을 위해 SQS Standard(순서 보장보다 처리 속도에 집중한 표준 큐)를 채택했다. 트리거 방식도 다르다. 메시지가 오자마자 실행되는 대신 EventBridge Scheduler(정해진 시간에 작업을 실행하는 스케줄러)가 정기적으로 Lambda 함수를 호출한다. 호출된 함수는 큐에 쌓인 메시지를 확인하고 JSONL(한 줄에 하나의 JSON 객체가 있는 파일 형식) 아티팩트를 생성해 Bedrock 배치 작업으로 넘긴다. 결과는 즉시 반환되지 않고 비동기 방식으로 처리되어 S3(클라우드 저장소)에 저장된다.

두 방식의 인프라 차이는 운영 비용과 메시지 전달 보장 수준에서 갈린다. SQS Standard는 FIFO와 달리 메시지가 중복 전달될 가능성이 있다. 이를 해결하기 위해 배치 파이프라인의 Lambda 함수 내부에서 중복 메시지를 무시하는 로직을 구현했다. 반면 온디맨드는 개별 호출 비용을 감수하는 대신 정확한 전달과 빠른 응답을 얻는다. 처리해야 할 문서가 수억 건에 달하는 환경에서는 개별 호출보다 배치 방식을 통해 전체 비용을 최적화하는 것이 효율적이다. 응답 속도와 비용, 그리고 메시지 전달의 엄격함이라는 세 가지 기준에 따라 큐와 트리거 구조를 다르게 설계했다.

레거시 문서 디지털 전환(DX)을 위한 실무적 시사점

수억 건의 토지 임대 문서가 쌓여 있는 환경에서 가장 큰 걸림돌은 동일한 추출 규칙을 모든 문서에 적용할 수 없다는 점이다. 어떤 문서는 핵심 정보를 번호 매기기 목록으로 나열하고, 어떤 문서는 복잡한 표나 도면 형태로 정보를 제공한다. 이러한 형식의 다양성을 해결하기 위해 문서 유형에 최적화된 프롬프트를 동적으로 할당하는 방식을 도입한다. 정해진 하나의 프롬프트가 아니라 문서의 시각적 특성에 맞는 최적의 지시문을 매칭해 정형 데이터 추출의 정확도를 높이는 구조다. 이는 단순히 텍스트를 읽어내는 수준을 넘어 문서의 맥락에 맞는 데이터를 정확히 짚어내는 실무적 정확도를 확보하는 장치가 된다.

실무 운영 단계에서는 단일 파이프라인 내에서 문서별로 모델 ID와 프롬프트 ID 및 버전을 다르게 지정해 다종 문서를 동시에 처리한다. 각 문서가 어떤 모델을 사용할지, 그리고 Amazon Bedrock Prompt Management(리전당 최대 50개 프롬프트, 프롬프트당 최대 10개 버전 관리 도구)의 어떤 버전 프롬프트를 호출할지 메시지 수준에서 결정한다. 이를 통해 문서 종류가 늘어날 때마다 새로운 파이프라인을 구축할 필요 없이, 프롬프트 ID만 추가하거나 버전을 업데이트하는 방식으로 대응할 수 있다. 특히 프롬프트 버전 관리를 통해 특정 문서 형식에서 추출 오류가 발생했을 때 전체 시스템을 중단하지 않고 해당 버전의 프롬프트만 수정해 즉시 반영하는 운영이 가능하다.

인프라 배포와 확장 단계에서는 CloudFormation(AWS 리소스를 템플릿으로 정의하고 배포하는 서비스) 스택을 활용해 온디맨드 및 배치 추론 파이프라인을 신속하게 구축한다. 수억 건의 문서를 처리해야 하는 대규모 환경에서는 개별 리소스를 수동으로 설정하는 것이 불가능하며, 코드 기반의 인프라 관리가 필수적이다. 스택을 통해 검증된 아키텍처를 동일하게 복제함으로써 배포 시간을 단축하고 환경 간 설정 오류를 방지한다. 처리 시급성에 따라 온디맨드와 배치 파이프라인 중 적합한 경로를 선택해 배포하는 구조는 운영 비용과 응답 속도를 최적화하는 기준이 된다. 결과적으로 인프라 구축에 드는 공수를 줄이고 데이터 추출의 정밀도를 높이는 데 자원을 집중할 수 있다.

스캔된 PDF의 오타를 수정하며 텍스트를 옮겨 적던 단순 반복 노동은 이제 어떤 파이프라인을 설계하느냐의 문제로 바뀐다. Claude 3.5 Sonnet의 이미지 입력 제한을 해결하는 청킹 구조를 적용해 수억 건의 문서를 자동 추출할 수 있는 인프라가 증명되었기 때문이다.

결국 실무자에게 남은 과제는 추출 가능 여부가 아니라 처리 시급성에 따른 비용과 응답 속도의 최적화 지점을 찾는 일이다. 온디맨드와 배치 추론 파이프라인 중 무엇을 선택하느냐가 전체 운영 효율을 결정하는 최종 기준이 된다.