단일 호출로 비정형 문서를 스키마에 맞춰 변환하는 파이프라인은 복잡한 다중 페이지 문서나 조건부 연산이 개입되는 순간 필연적으로 정확도 저하에 직면합니다. 텍스트 추출 자체는 성공하더라도 여러 페이지에 걸쳐 파편화된 표를 병합하거나, 각 행의 배제 조건을 검증하고, 시각적 차트의 문맥을 교차 검증하는 과정에서 단순 1회 추론(One-Pass) 모델은 맥락 유실을 겪게 됩니다.
Azure Content Understanding(현재 프리뷰 단계)에 추가된 Agentic Mode는 이러한 구조적 결함을 극복하기 위해 대규모 언어 모델(LLM)에 문서 탐색 도구, 시각 검증 도구, 연산 도구를 결합한 자율 추론 루프(Document-Native Harness)를 제공합니다. 시스템 아키텍처 관점에서 기존 Standard Mode와 Agentic Mode의 작동 메커니즘을 비교하고, 엔터프라이즈 시스템 구축 시 고려해야 할 지연 시간(Latency) 및 운영 비용(Opex) 트레이드오프를 분석합니다.
1. 아키텍처 메커니즘 비교: Standard Mode vs. Agentic Mode
Azure Content Understanding 파이프라인에서 추출 방식을 결정하는 핵심 요소는 모델이 문서를 해석하는 제어 흐름(Control Flow)입니다.
[Standard Mode]
Document + Schema ─────────► [ Single-Pass Inference ] ─────────► Structured Output
[Agentic Mode]
Document + Schema ─────────► [ Document-Native Harness ] ◄───┐
│ │
├── Text & Table Navigation ┤ (Reasoning Loop)
├── Visual Evidence Tool ┤
└── Calculator Tool ────────┘
│
▼
Structured Output
Standard Mode: 단일 패스(One-Pass) 추출 엔진
기존의 기본 방식인 Standard Mode는 입력 문서와 사용자가 정의한 스키마(Field Schema)를 결합하여 한 번의 효율적인 패스로 필드를 채웁니다.
- 작동 원리: 사전 정의된 필드(인보이스 총액, 계약 번호, 서명 일자 등)를 문서 본문에서 직접 추출(Extraction)하거나 단순 유도(Derived)합니다.
- 특징: 왕복 추론 횟수가 1회로 고정되어 있어 처리 지연이 짧고, 소모되는 토큰량이 일정하여 예측 가능한 비용 구조를 유지합니다. 단일 위치에 답이 존재하는 정형·반정형 문서 처리에 적합합니다.
Agentic Mode: 도구 결합형 추론 루프(Document-Native Harness)
Agentic Mode는 LLM을 단순 추출기가 아닌 오케스트레이션 에이전트로 동작시킵니다.
- 작동 원리: 에이전트는 스키마 요구사항을 충족하기 위해 실행 계획을 수립하고, 문서 전용 도구를 호출하여 본문과 표를 탐색(Navigation)하며, 시각적 증거(Visual Evidence)를 재확인하고, 연산(Calculator)을 수행합니다. 첫 번째 판독 결과가 모호하거나 불완전할 경우 다른 도구로 증거를 재확인(Revisit)한 뒤 최종 스키마를 생성합니다.
- 특징: 단순 텍스트 생성이 아닌 ‘증거 수집 및 검증 루프’를 거치므로, 답이 단일 위치에 존재하지 않고 문서 전반에 파편화되어 있을 때 데이터 무결성을 보장합니다.
2. Agentic Mode가 해결하는 3가지 복합 데이터 패턴
원문 기술 블로그가 제시한 실무 사례를 바탕으로 분석한 Agentic Mode의 세부 작동 방식은 다음과 같습니다.
패턴 1. 2페이지 이상 분산된 테이블의 조건부 행 필터링 및 산술 연산
미국 재무부(U.S. Treasury) 137페이지 회보 분석 사례에서는 2개 페이지에 걸쳐 이어지는 테이블에서 ‘2003년 1월 기관 지출(Outlays)’의 합계를 산출해야 합니다.
- 엔지니어링 난점: 월별 행의 데이터가 여러 열 대역(Column Bands)과 다음 페이지로 연결되어 있어 각 금액이 해당 기관 헤더와 올바르게 매핑되어야 합니다. 또한 스키마 정의에 따라 특정 기관만 포함하고 영수증(Receipts)이나 보고된 소계는 제외해야 합니다. 표기법에서도 개정 표시인 ‘r’ 기호는 제거(Normalization)하고 마이너스(-) 부호는 유지하여 연산해야 합니다.
- 에이전트 해결 방식: 모델이 단일 패스로 모든 조건을 암기하여 연산하는 대신, 에이전트가 표를 순회하며 조건에 부합하는 셀을 식별·정규화하고, 내장된 계산기(Calculator) 도구를 명시적으로 호출하여 정확한 합계(180,681 백만 달러)를 도출합니다.
패턴 2. 시각 차트와 본문 텍스트 간의 교차 검증
20페이지 발췌본 내 4개의 경제 차트를 해석하여 GDP 성장률, 고용 변화, 실업률, 단기 금리 하락 전환 시점 등 7개 필드를 추출하는 사례입니다.
- 엔지니어링 난점: 차트 내 플롯된 데이터 포인트 자체만으로는 수치의 정의나 단위를 확정할 수 없습니다. 차트의 부제목, 축(Axes), 주변 본문 서술(Surrounding Prose)이 결합되어야 해석이 가능합니다.
- 에이전트 해결 방식: 차트 영역을 확대 검사하고, 주변 문맥 텍스트를 읽어 해석 전략을 수립합니다. 해석이 모호할 경우 원본 소스를 다시 확인(Revisit)하여 시각적 지표와 텍스트 문맥을 일치시킨 후 스키마 필드를 채웁니다.
패턴 3. 19페이지 분량의 연속 네트워크 로그 전수 집계
동일한 구조의 테이블이 19페이지에 걸쳐 지속되는 네트워크 이벤트 로그 분석 사례입니다.
- 엔지니어링 난점: 각 페이지마다 반복되는 테이블 헤더를 무시하고 19페이지를 하나의 논리적 테이블로 통합해야 합니다. 전체 이벤트 수 집계 시 첫 번째와 마지막 이벤트 ID를 이용해 개수를 추정하는 지름길을 택하면, ID 시퀀스에 결번(Gaps)이 존재할 경우 오류가 발생합니다.
- 에이전트 해결 방식: 19페이지 전체의 실제 행을 전수 집계(Count)하고, ‘Critical’ 조건 필터링 카운트, ‘Link Down’ 이벤트의 지속 시간(Duration) 누적 합산(Sum) 등 조건별 파이프라인을 순차 실행하여 정확도를 보장합니다.
3. 엔터프라이즈 도입 아키텍처 및 트레이드오프 분석
시스템 설계 시 모든 문서를 무조건 Agentic Mode로 전환하는 것은 적절하지 않습니다. Standard Mode와 Agentic Mode는 기술의 신구 구분이 아닌, 연산 비용-지연 시간 곡선(Price-Performance Curve) 상의 서로 다른 지점입니다.
의사결정 매트릭스
| 평가 기준 | Standard Mode | Agentic Mode |
| 적합 워크로드 | 단일 페이지 인보이스, 기본 양식, 필드 값이 문서 내 특정 위치에 명시된 경우 | 다중 페이지에 분산된 데이터 취합, 복잡한 산술/대사 연산, 시각 차트 해석, 전수 분석 |
| 추론 지연 시간(Latency) | 단일 모델 패스로 빠르고 일정함 | 도구 호출 및 반복 추론 루프로 인해 상대적으로 지연 시간이 증가함 |
| 운영 비용(Opex) | 입력/출력 토큰 소비량이 적어 비용 예측 가능성 높음 | 단계별 도구 사용 및 중간 추론으로 더 많은 토큰을 소비함 |
| 오류 제어 방식 | 프롬프트 수정 및 파인튜닝 의존 | 스키마 지침 기반 검증 및 에이전트 재확인 루프 내재화 |
Microsoft AI MVP 관점에서 엔터프라이즈 시스템을 설계할 때 주목해야 할 지점은 시스템의 회복 탄력성과 비용 최적화입니다. 전체 수집 파이프라인의 기본값(Default)은 항상 Standard Mode로 유지하여 대량의 정형 문서를 신속하고 저비용으로 처리해야 합니다.
이후 추출 신뢰도가 기준치 미만이거나, 다중 페이지 테이블 대사 및 차트 판독과 같이 조건부 연산이 필수적인 고난도 작업군에 한하여 Agentic Mode로 동적 라우팅하는 2단계(Tiered) 아키텍처를 구성하는 것이 운영 비용(Opex) 폭증을 방지하는 안정적인 접근법입니다.
4. 실무 구현 사양 (Configuration)
Agentic Mode는 Azure Content Understanding Studio에서 프로젝트 생성 시 API 버전을 2026-06-01 (Preview)로 지정하고 워크플로 종류를 Agentic Extraction으로 선택하여 구성할 수 있습니다.
REST API 또는 SDK 기반의 인프라 자동화 코드 작성 시에는 다음과 같이 분석기(Analyzer) 정의의 config 블록에 에이전틱 워크플로를 명시합니다.
JSON
{
"baseAnalyzerId": "prebuilt-document",
"models": {
"completion": "{your-completion-model}"
},
"config": {
"workflow": "agentic"
},
"fieldSchema": {
"fields": {
"{your-fields}"
}
}
}
주의: models.completion 속성에는 Azure 배포 이름(Deployment Name)이 아닌 지원되는 모델의 카탈로그 이름(Catalog Name)을 지정해야 합니다.
5. 아키텍처 결론 및 단계적 적용 가이드
단일 패스 모델은 계산과 정규화, 다중 페이지 공간 관계 파악을 단 한 번의 추론 컨텍스트 안에서 동시에 처리해야 한다는 태생적 한계를 지닙니다. Agentic Mode는 이를 분리하여 단계별 탐색, 시각적 검증, 계산기 도구 실행으로 이어지는 명시적 워크플로로 전환함으로써 문서 AI의 신뢰성을 확보합니다.
실무 시스템 구축 시 권장되는 도입 순서는 다음과 같습니다:
- 대표 문서 샘플 세트를 구성하여 Standard Mode 환경에서 기준 정확도 및 비용을 측정합니다.
- 필드 결측률이 높거나 다중 페이지 산술 집계 오류가 발생하는 케이스를 분류합니다.
- 해당 워크로드에 한하여
API 2026-06-01-preview의workflow: "agentic"설정을 적용하고, 추가 소모 토큰 및 지연 시간 대비 정확도 향상 폭을 정량적으로 검증한 후 프로덕션으로 승격합니다.
📚 참고 자료
- Microsoft Foundry Blog: When one pass isn’t enough: agentic mode in Azure Content Understanding (Joe Filcik, Principal Product Manager)
- Azure Content Understanding API Specification (Version: 2026-06-01-preview)