Extract Data with On-demand and Batch Pipelines Dynamically

🖼️ 인포그래픽

Extract Data with On-demand and Batch Pipelines Dynamically 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 스캔 PDF 같은 대량 문서에서 데이터를 추출하기 위해 문서별 모델과 프롬프트를 동적으로 지정할 수 있는 온디맨드·배치 추론 파이프라인 구조를 설명합니다.

📌 핵심 요약

많은 기업은 종이 문서나 전자 문서에 담긴 비즈니스 정보를 충분히 활용하지 못하고 있으며, 글은 스캔된 토지 임대 문서를 예로 들어 데이터 추출 문제를 제시합니다.
해결책은 온디맨드 추론 파이프라인과 배치 추론 파이프라인을 함께 구성해, 시간에 민감한 요청은 빠르게 처리하고 대량 요청은 비용 효율적으로 비동기 처리하는 방식입니다.
두 파이프라인 모두 문서 요청에 모델 ID와 프롬프트 ID·버전을 포함시켜, 문서 형식에 맞는 프롬프트를 실행 시점에 가져오고 같은 파이프라인으로 여러 유형의 문서를 처리할 수 있게 합니다.
온디맨드 파이프라인은 FIFO 큐, Lambda, S3, 이미지 변환, 프롬프트 조회, 모델 호출, DynamoDB 저장 흐름으로 단일 문서를 수 초 단위로 처리하는 데 초점을 둡니다.
배치 파이프라인은 표준 큐, EventBridge Scheduler, 전처리 Lambda, JSONL 생성, 배치 추론 작업, EventBridge 규칙, 후처리 Lambda를 통해 많은 문서를 한 번에 처리하도록 설계됩니다.

🧩 주요 포인트

많은 기업은 종이 문서나 전자 문서에 담긴 비즈니스 정보를 충분히 활용하지 못하고 있으며, 글은 스캔된 토지 임대 문서를 예로 들어 데이터 추출 문제를 제시합니다.
해결책은 온디맨드 추론 파이프라인과 배치 추론 파이프라인을 함께 구성해, 시간에 민감한 요청은 빠르게 처리하고 대량 요청은 비용 효율적으로 비동기 처리하는 방식입니다.
두 파이프라인 모두 문서 요청에 모델 ID와 프롬프트 ID·버전을 포함시켜, 문서 형식에 맞는 프롬프트를 실행 시점에 가져오고 같은 파이프라인으로 여러 유형의 문서를 처리할 수 있게 합니다.
온디맨드 파이프라인은 FIFO 큐, Lambda, S3, 이미지 변환, 프롬프트 조회, 모델 호출, DynamoDB 저장 흐름으로 단일 문서를 수 초 단위로 처리하는 데 초점을 둡니다.
배치 파이프라인은 표준 큐, EventBridge Scheduler, 전처리 Lambda, JSONL 생성, 배치 추론 작업, EventBridge 규칙, 후처리 Lambda를 통해 많은 문서를 한 번에 처리하도록 설계됩니다.

🧠 상세 정리

1. 문서 데이터 추출 문제와 글의 목적

글은 많은 기업이 방대한 종이 문서와 전자 문서를 보유하고 있지만, 그 안의 비즈니스 인텔리전스를 충분히 활용하지 못하고 있다는 문제의식에서 출발합니다. 예시로는 편집 가능한 텍스트가 없는 스캔 PDF 형태의 토지 임대 문서가 제시되며, 이미 쌓인 문서가 매우 많고 새로운 문서도 계속 추가되는 상황이 설명됩니다. 이런 문서는 형식이 다양하고 이미지 기반일 수 있기 때문에 단순 텍스트 처리만으로는 필요한 속성을 안정적으로 뽑아내기 어렵습니다. 글의 목적은 이런 문서에서 관련 데이터를 추출하고 표준화하기 위한 지능형 문서 처리 파이프라인을 보여주는 것입니다.

2. 전체 솔루션 구조: 온디맨드와 배치의 병행

솔루션은 크게 두 개의 추론 파이프라인으로 구성됩니다. 왼쪽의 온디맨드 파이프라인은 문서를 하나씩 처리하며 수 초 안에 결과를 돌려주는 구조라 시간에 민감한 요청에 적합합니다. 오른쪽의 배치 파이프라인은 여러 문서 요청을 하나의 배치 추론 작업으로 묶어 비동기적으로 처리하므로 대량 문서 처리와 비용 최적화에 초점을 둡니다. 두 방식은 처리 시간과 비용 요구가 서로 다른 업무를 같은 설계 안에서 다룰 수 있게 하며, 문서 단위로 모델과 프롬프트를 지정할 수 있다는 점이 공통적인 핵심입니다.

3. 문서별 프롬프트와 모델을 동적으로 지정하는 방식

글에서 강조하는 중요한 특징은 문서마다 사용할 대규모 언어 모델 ID와 프롬프트 ID 및 버전을 요청 메시지에 포함할 수 있다는 점입니다. 토지 임대 문서라도 어떤 문서는 번호 목록으로 속성을 제시하고, 어떤 문서는 표를 쓰며, 어떤 문서는 토지 도면을 포함할 수 있습니다. 따라서 모든 문서에 동일한 프롬프트를 쓰는 대신 형식에 맞는 프롬프트를 가져와 적용하면 추출 정확도를 높일 수 있습니다. 프롬프트는 Amazon Bedrock Prompt Management에 저장되며, 실행 중 Lambda 함수가 메시지에 지정된 ID와 버전을 이용해 해당 프롬프트 본문을 조회합니다.

4. 온디맨드 파이프라인의 큐와 단일 문서 처리 흐름

온디맨드 파이프라인에서는 AWS SQS FIFO 큐가 단일 문서 도착을 감지하고 Lambda 함수를 트리거합니다. 큐 메시지는 문서 ID, LLM 모델 ID, 프롬프트 ID와 버전, 시스템 프롬프트 ID와 버전, 문서 위치 같은 속성을 담습니다. FIFO 큐를 쓰는 이유는 메시지가 정확히 한 번 전달되도록 하고, 선입선출 순서를 유지하며, Message Group ID를 통해 관련 메시지의 처리 순서를 보장하기 위해서입니다. 메시지는 AWS CLI나 SDK API로 만들 수 있고, Lambda 함수는 추출 결과가 반환된 뒤 해당 메시지를 큐에서 삭제합니다.

5. 온디맨드 Lambda의 문서 변환, 분할, 추론 호출

온디맨드 Lambda 함수는 먼저 큐 메시지의 s3_location 속성을 이용해 지정된 S3 버킷에서 PDF 문서를 내려받습니다. 문서가 스캔 PDF라면 멀티모달 모델이 이해할 수 있도록 PDF 페이지를 PNG 이미지로 변환합니다. 글 작성 시점 기준 Claude 4 Sonnet 모델은 멀티모달 호출당 최대 20개 이미지까지만 허용하므로, 20페이지를 넘는 문서는 20페이지 단위 청크로 나누어 처리해야 합니다. 이때 doc_id, 전체 청크 수인 chunk_count, 각 청크 식별자인 chunk_id가 추출 결과와 모델 성능 지표와 함께 DynamoDB 테이블에 저장됩니다.

6. 추론 응답 저장과 온디맨드 처리 완료 조건

문서 이미지와 프롬프트가 준비되면 Lambda 함수는 프롬프트 본문과 이미지를 결합해 모델 호출용 메시지를 구성합니다. 이후 Converse API를 통해 요청을 보내고, 모델은 추출된 데이터를 JSON 문자열 형태로 반환합니다. Lambda 함수는 이 JSON을 파싱해 토지 구획 속성 같은 추출 결과를 DynamoDB 테이블에 저장합니다. 문서가 성공적으로 처리되고 결과가 저장된 경우에만 큐 메시지를 삭제하므로, 처리 완료 기준은 단순 호출 성공이 아니라 결과 저장까지 포함합니다. 사용자는 테스트 단계에서 DynamoDB 테이블을 확인해 추출 결과를 검토할 수 있습니다.

7. 배치 파이프라인의 구성 요소와 전처리 흐름

배치 추론 파이프라인은 높은 처리량을 위해 표준 AWS SQS 큐를 사용하며, 온디맨드와 달리 message-group-id 속성이 필요하지 않습니다. 주요 구성 요소로는 Amazon EventBridge Scheduler, 스캔 PDF를 전처리하고 JSONL 파일을 만든 뒤 배치 추론 작업을 제출하는 Lambda 함수, Amazon EventBridge 규칙, 후처리 Lambda 함수가 있습니다. 스케줄러가 배치 추론 Lambda를 주기적으로 시작하면, 이 함수는 큐에 충분한 메시지가 있는지 먼저 확인합니다. 글 작성 시점 기준 Amazon Bedrock 배치 추론 작업에는 최소 100개 레코드가 필요하다는 조건도 제시됩니다.

8. 배치 작업 생성, 출력 저장, 후처리 단계

배치 Lambda 함수는 큐 메시지에서 문서 ID, 모델 ID, 프롬프트 ID와 버전, 시스템 프롬프트 ID와 버전을 읽고 문서를 가져와 이미지로 변환하며 필요한 경우 큰 파일을 분할합니다. 표준 큐는 정확히 한 번 전달을 보장하지 않기 때문에 중복 메시지를 무시하는 처리도 포함됩니다. 이후 metadata.json을 만들어 메시지 속성과 문서·프롬프트 정보를 저장하고, 배치 추론 작업에 필요한 JSONL 파일을 생성해 S3 버킷에 올립니다. 배치 작업은 하나의 모델만 처리할 수 있으므로 여러 모델 ID가 섞이면 가장 자주 지정된 모델 ID를 선택하는 폴링 메커니즘을 사용합니다. 작업 완료 후 출력 JSONL은 S3에 저장되고, EventBridge 이벤트를 통해 후처리 Lambda가 실행되어 결과를 DynamoDB에 저장합니다.

🧾 핵심 주장 / 시사점

이 설계의 핵심은 빠른 응답이 필요한 단건 처리와 비용 효율적인 대량 처리를 분리하되, 문서별 프롬프트와 모델 지정 방식은 공통화했다는 점입니다.
스캔 PDF처럼 텍스트가 없는 문서를 처리하려면 이미지 변환, 페이지 수 제한에 따른 청크 분할, 결과와 성능 지표의 저장까지 파이프라인 단계로 명확히 설계해야 합니다.
배치 처리에서는 처리량만이 아니라 최소 레코드 수, 중복 메시지, 단일 모델 제약, 긴 Visibility Timeout 같은 운영 조건이 전체 파이프라인 안정성에 직접 영향을 줍니다.

✅ 액션 아이템

온디맨드 파이프라인은 초 단위 단건 처리에 맞춰 FIFO 큐, Lambda, S3, 이미지 변환, 프롬프트 조회, 모델 호출, DynamoDB 저장 흐름을 점검한다.
배치 파이프라인은 표준 큐, EventBridge Scheduler, 전처리 Lambda, JSONL 생성, 배치 추론 작업, EventBridge 규칙, 후처리 Lambda로 대량 처리 경로를 설계한다.
문서 요청 메타데이터에 모델 ID·프롬프트 ID·버전을 포함해 형식별 최적 프롬프트를 실행 시점에 동적으로 선택하도록 통합한다.