금융 서비스 회사의 한 팀을 상상해 보겠습니다.

매주 고객용 발표자료를 만든다
  ← 분기 보고서, 컴플라이언스 문서, 시장 분석을 읽는다
  ← 수백 페이지에서 핵심 수치를 뽑는다
  ← 슬라이드 구조를 짜고, 본문을 쓰고, 시각 자료를 만든다
  ← 이 반복이 매주 돌아온다

10월 14일 AWS가 공개한 글은 이 작업을 에이전트 시스템으로 자동화한 사례를 다룹니다. 숫자가 먼저 눈에 들어옵니다.

입력: 90페이지 PDF (Amazon 2024 연차 보고서)
출력: 6장 슬라이드 (타이틀·불릿·이미지+텍스트·이미지·테이크어웨이 구성)
시간: 70~90초 (검색 → 생성 → 이미지 → 파일 조립까지 전체)
비용: 모델 호출 기준 약 $0.04 (이미지 생성이 대부분)
지식베이스 인제스트: 1.3MB PDF 2분 이내

물론 "내부 테스트 기준"이라는 단서가 붙습니다. 인프라 운영 비용이나 일반적인 생성 속도를 뜻하지 않습니다. 그런데 이 사례의 진짜 배울 점은 속도가 아니라 구조와, 그 구조가 근거(grounding)를 어떻게 다루는가입니다.

구조: 슈퍼바이저 하나와 두 개의 도구

[사용자 요청] → API Gateway → Chat API(.NET 8, Lambda)
                    │
                    ▼
        Supervisor Agent (AgentCore runtime, Strands)
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
  generate_pptx            generate_summary
  (PPTX Generator Lambda)  (Summary Generator Lambda)
        │                       │
        ▼                       ▼
  지식베이스 검색(RAG) ─→ Claude Sonnet 4.6이 근거 기반으로 생성
        │
        ├─ Titan Text Embeddings v2로 임베딩
        ├─ OpenSearch Serverless 벡터 검색
        ├─ Stability AI 이미지 생성 (슬라이드 이미지 2장)
        └─ Bedrock Guardrails (입력·출력·PII)

핵심 구성 요소를 하나씩 보면 이렇습니다.

- RAG 파이프라인: S3 문서 → 청킹·파싱(표·차트·이미지 특별 처리)
  → Titan Text Embeddings v2 → OpenSearch Serverless 벡터 저장
  → 질문 시 유사 청크 검색 → 컨텍스트와 함께 Claude Sonnet 4.6 생성
- 이미지: Stability AI Stable Image Inpaint로 슬라이드당 필요한 시각 자료 생성
- Guardrails: 입력(인젝션·부적절 콘텐츠), 출력(정책 준수), PII 마스킹
- 저장·배포: 결과 PPTX를 S3에 저장, 5분 만료 presigned URL로 다운로드
- 템플릿: 타이틀 슬라이드 브랜딩, 불릿, 발표자 노트까지 포함

프롬프트 한 방으로 슬라이드를 만드는 게 아니라, 검색 → 구조 설계 → 본문 생성 → 이미지 생성 → 파일 조립을 역할별 도구로 나눠 조율합니다. "할루시네이션을 줄이기 위해 생성된 문서를 사내 지식베이스에 근거시키는 것"이 설계의 명시적 목표입니다.

실무에서 걸리는 지점: 90초는 비동기다

재미있는 기술적 세부가 하나 있습니다. API Gateway의 기본 통합 타임아웃은 29초입니다. 그런데 이 작업은 70~90초가 걸립니다.

해결 패턴
  - API Gateway 타임아웃을 300초로 올린다 (문서화된 설정)
  - 그래도 동기 호출로 기다리게 하지 않는다
    → 스트리밍 또는 폴링 방식으로 최종 결과를 받는다

교훈
  에이전트 작업 시간이 웹 요청 예산을 넘으면
  UX를 "요청-응답"에서 "작업-알림"으로 바꿔야 한다

에이전트 자동화를 붙일 때 흔히 빠지는 함정입니다. 파이프라인은 잘 만들어 놓고 사용자는 30초마다 새로고침을 누르게 되는 구조. 작업이 길어지는 순간 제품 경험도 같이 설계해야 합니다.

빠른 생성보다 어려운 것: 수치 일치

발표자료 자동화에서 진짜 리스크는 생성 속도가 아닙니다.

잘 나오는 것: 그럴듯한 문장, 깔끔한 구성
위험한 것   : 원문과 다른 숫자, 출처 없는 주장, 과장된 요약

분기 보고서의 매출 수치가 슬라이드에서 하나 틀리면, 그 발표자료 전체의 신뢰가 무너집니다. 그래서 이 아키텍처에서 가져가야 할 부분은 생성 파트가 아니라 근거 파트입니다.

- 요약 출력에 원문 출처(인용 추적)를 함께 남기도록 설계
- 숫자가 나오는 슬라이드는 원문 대조 검증 단계를 별도로 둘 것
- PII가 섞인 문서라면 Guardrails 마스킹이 필수
- 템플릿·브랜딩은 고정, 내용만 생성 (일관성)

AWS가 공개한 샘플은 여기서 한 걸음 더 나아가, 생성된 콘텐츠가 콘텐츠 정책을 지키는지 Guardrails가 다시 확인하는 구조입니다. "생성은 모델, 검증은 파이프라인"이라는 이중 구조는 9단계 파이프라인 사례와도 같은 원리입니다.

CodeBridge Mini Lab: 발표자료 자동화 점검표

이 파이프라인을 사내에 들일 계획이라면 다음을 확인하세요.

[ ] 생성된 슬라이드의 각 주장이 원문 어디에서 왔는지 추적되는가
[ ] 숫자·날짜·고유명사를 원문과 대조하는 검증 단계가 있는가
[ ] PII·민감 정보가 슬라이드에 그대로 실리지 않는가
[ ] 70~90초 작업에 맞는 비동기 UX(진행 표시·알림)가 있는가
[ ] 모델 호출 비용($0.04)을 인프라 비용과 분리해 재고 있는가
[ ] 브랜드 템플릿과 서식이 자동 생성 후에도 유지되는가
[ ] OpenSearch 데이터 플레인 접근 제약 같은 인프라 주의점을 확인했는가

마지막 항목은 AWS 글의 숨은 기술 포인트입니다. Bedrock Knowledge Bases가 AWS 관리형 인프라에서 접근하기 때문에 OpenSearch Serverless 컬렉션의 데이터 플레인이 퍼블릭으로 유지되어야 하고, 대신 IAM 정책과 VPC 제한으로 보호하는 구조입니다. "편의와 보안의 트레이드오프"가 어디서 일어나는지 보여주는 좋은 예입니다.

결론: 90초의 가치는 슬라이드가 아니라 근거에서 나온다

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

발표자료 자동화의 경쟁력은 생성 속도가 아니라,
"이 숫자가 어디서 왔는가"에 답할 수 있는 구조에서 나온다.

90초와 $0.04는 인상적이지만, 그 숫자가 원문과 어긋나면 아무 의미가 없습니다. 검색으로 근거를 찾고, 생성하고, 다시 정책으로 검증하는 3단 파이프라인. 우리 팀에서 시작한다면 문서 하나(연차 보고서나 분기 리포트)를 지식베이스에 넣고, 슬라이드 6장을 만들어 그 숫자를 원문과 대조하는 것부터 해보세요. 대조가 통과하는 순간 자동화가 시작됩니다.

함께 읽으면 좋은 글

참고 자료

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

문서를 근거로 글과 이미지, 완성된 결과물을 만드는 흐름은 생성형 AI 콘텐츠의 핵심 작업과 그대로 겹칩니다. 글쓰기·이미지·영상 생성을 한 흐름으로 연습하며 "무엇을 만들고, 무엇을 검증할지"를 익혀보세요.