공급사가 수백 곳인 회사에서 구매 발주서를 자동 처리한다고 해보겠습니다.

문제의 구조
  공급사마다 양식이 다름
  → 양식마다 템플릿·추출 규칙·검증 로직을 만들어야 함
  → 어느 공급사가 양식을 살짝 바꾸면 그 템플릿이 깨짐
  → 오류는 반복되는데 시스템은 배우지 않음

IDC 자료를 인용한 AWS 글의 숫자는 이 부담이 얼마나 큰지를 보여줍니다. 문서 관련 문제로 정보 근로자 한 명당 연간 약 19,732달러의 비용이 발생하고, 생산성이 21.3% 줄어든다는 추정입니다. 직원 시간의 최대 30%가 문서 작업에 쓰이고, 수기 입력 오류율은 1~4% 수준입니다.

10월 14일 AWS가 공개한 글은 이 문제를 템플릿 대신 학습 루프로 푸는 구조를 다룹니다. Amazon Bedrock AgentCore 위에서 돌아가는 자가 개선 지능형 문서 처리(agentic IDP) 시스템입니다.

구조: 8개 에이전트, 세 갈래 흐름

전체 그림은 이렇습니다.

[문서 도착] 이메일(SES) 또는 S3 업로드
      │
      ▼
EventBridge → Lambda → AgentCore runtime (Strands Agents 그래프)
      │
      ├─ ① 식별
      │    Analyzer: Textract로 텍스트 추출, 문서 유형·발신자 식별
      │    Matcher : S3 Vectors에서 유사 문서 검색
      │
      ├─ ② 학습 (처음 보는 양식일 때)
      │    Instructions  : 추출 지시문(프롬프트) 생성
      │    Extractor     : 스키마에 맞춰 구조화 데이터 추출
      │    Validator     : Aurora DSQL의 스키마·비즈니스 규칙으로 검증
      │    Instructions Fixer: 검증 실패 시 지시문 수정 → 재시도
      │    Save Instructions : 성공한 지시문을 저장 (다음부터 재사용)
      │
      └─ ③ 자동화 (아는 양식일 때)
           Extractor가 저장된 지시문을 그대로 사용
           Troubleshooter가 추출 오류를 직접 수정 (지시문은 건드리지 않음)

포인트는 ②와 ③의 역할 분담입니다. 처음 보는 양식은 규칙을 만드는 과정을 거치고, 아는 양식은 만든 규칙을 재사용합니다. 규칙이 틀렸을 때(②)는 규칙 자체를 고치고, 데이터가 틀렸을 때(③)는 규칙은 그대로 두고 데이터만 고칩니다.

실제 예시: SKU 형식이 다른 발주서

AWS 글에 나오는 예시를 따라가 보겠습니다. 새 공급사 "Two Wheel Store"의 첫 발주서가 도착합니다.

1단계 — Analyzer가 Textract로 텍스트 추출
  PURCHASE ORDER
  FROM: Two Wheel Store
  Order #: PO-2026-0102-2584
  AC-021 Advanced Computer  Qty: 1  $75.61
  SB-004 Folding Classic    Qty: 8  $9634.32
  ...

2단계 — Matcher가 유사 문서를 못 찾음 → 학습 워크플로 진입
3단계 — Instructions가 추출 지시문 생성, Extractor가 JSON 추출
4단계 — Validator가 검증 → 실패

실패 이유가 재미있습니다. 공급사의 SKU 형식(SB-004)이 자사 내부 형식 정규식(^AB-[A-Z]{2}-\d{3}$)과 맞지 않았습니다.

validation_status: INVALID
error: 'SB-004' does not match '^AB-[A-Z]{2}-\d{3}$'

여기서 Instructions Fixer가 진단합니다. "이 공급사 SKU에는 AB- 접두어를 붙여야 한다"는 변환 규칙을 지시문에 추가하고 재시도합니다. 두 번째 실행에서 7개 라인 아이템이 모두 통과하고, Save Instructions가 개선된 지시문을 벡터 저장소에 저장합니다.

첫 실행 (학습): 3분 49초
두 번째 발주서 (자동화): 1분 30초
  — 유사도 점수 3.946 (임계값 3.7)으로 저장된 지시문을 찾아
    접두어 변환 규칙(EL-002 → AB-EL-002 등)을 자동 적용

같은 양식이 다시 오면 사람이 한 일이 하나도 없습니다. 이게 이 구조의 핵심 가치입니다.

비용: 월 1,000건에 약 $58

AWS가 제시한 비용 추정도 구체적입니다.

기준: 학습 문서 10건 + 처리 문서 1,000건 / 월 (미국 동부 버지니아)
총액: 약 $58 / 월
  └ 파운데이션 모델 추론이 약 85%
  └ 문서당 약 $0.055
서버리스·온디맨드라 유휴 비용 없음
모델 선택은 config.py에 집중되어 있어 에이전트별로 바꿀 수 있음

문서당 5센트 남짓이면, 수기 입력 1~4%의 오류율과 사람 시간을 비교했을 때 계산이 나오는 규모입니다. 물론 이 숫자는 특정 리전·모델 조합의 예시이므로 자기 환경에서 다시 재야 합니다.

개선이 쌓이는 두 개의 루프

학습 루프  — 검증 실패 → 지시문 수정 → 저장 → 비슷한 문서에 재사용
처리 루프  — 오류 수정(Troubleshooter)의 분석 기록이
            양식 변형 패턴을 드러냄

두 루프가 있는 덕분에 시스템은 같은 실수를 반복하지 않습니다. 모델을 바꿀 때는 AgentCore Evaluations로 추출 품질이 유지되는지 확인하라고 AWS는 권합니다. 이미 Observability가 붙어 있으니 계측은 준비되어 있다는 뜻입니다.

도입 전에 알아야 할 한계

- 스키마(JSON)와 검증 Lambda는 직접 준비해야 함 (샘플은 구매발주서 데모)
- "완전 무인"이 아님 — 예외·민감 문서는 가드레일과 사람 리뷰가 필요
- 새 문서 유형은 스키마 + 검증 함수를 하나씩 추가하는 증분 방식
- 비용·정확도 수치는 특정 리전·모델·워크로드 기준의 예시

AWS가 권하는 시작 방법도 현실적입니다. 유형당 대표 샘플 5~10건(변형·예외 포함)으로 학습을 시작하고, 검증을 기준 데이터(공급사 목록·제품 카탈로그)에 연결하세요. 추출 정확도보다 "새 양식에 적응하는 데 드는 수정 횟수"를 함께 재는 게 도입 판단에 더 도움이 됩니다.

CodeBridge Mini Lab: 문서 자동화 도입 점검

[ ] 처리할 문서 유형별로 JSON 스키마가 정의되어 있는가
[ ] 검증을 사내 기준 데이터(ERP·공급사 목록)와 연결했는가
[ ] 새 양식이 왔을 때 사람이 하는 일이 "샘플 제공"뿐인가, 아니면 규칙 수정인가
[ ] 문서당 비용과 지연을 재고 있는가 (예: $0.055, 1~3분)
[ ] 민감 문서에 가드레일(PII·그라운딩)을 붙였는가

세 번째 항목이 이 아키텍처를 도입할지 결정하는 질문입니다. 규칙 수정이 사람의 일로 남아 있다면, 학습 루프를 붙일 여지가 가장 큰 지점입니다.

결론: 양식을 고치는 사람 대신, 양식을 배우는 루프

한 문장으로 정리하면 이렇습니다.

문서 자동화의 다음 단계는 더 똑똑한 템플릿이 아니라,
템플릿을 스스로 만드는 루프다.

검증 실패를 버리지 않고 지시문 개선에 쓰는 것, 성공한 결과를 재사용 가능한 자산으로 저장하는 것. 이 두 가지가 월 $58 사례의 본질입니다. 우리 팀에 문서 유형 하나를 골라 대표 샘플 5건과 스키마 하나로 시작해 보세요. 문서당 비용과 새 양식 적응 횟수, 그 두 개의 숫자가 도입의 답을 만들어 줍니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

문서에서 데이터를 뽑고, 검증하고, 재사용 가능한 자산으로 만드는 흐름은 사내 문서 AI를 직접 만들어 볼 때 가장 빨리 늘어납니다. 문서 수집부터 검색·응답까지 한 바퀴 돌려보는 연습으로 이어가 보세요.