S3 Annotations가 공개되었습니다

2026년 6월, S3 Annotations가 GA(General Availability) 되었습니다.

S3 Annotations는 S3 오브젝트에 대해 풍부한 메타데이터(JSON, XML, YAML 등, 임의의 UTF-8 텍스트)를 직접 부여할 수 있는 신기능입니다. 1개 오브젝트 버전당 최대 1,000개의 어노테이션을 가질 수 있으며, 각 어노테이션은 최대 1 MiB의 페이로드(Payload)를 가질 수 있습니다. 1개 오브젝트당 합계 최대 1 GiB(1,000개 × 1 MiB)의 메타데이터를 저장할 수 있습니다.

기존의 S3 메타데이터 수단과 대비하여 위치를 정하면 다음과 같습니다.

기존 S3 메타데이터와의 차이점

항목	Object Metadata (x-amz-meta-)	Object Tags	S3 Annotations
최대 수	제한 없음 (헤더 크기 제한 내)	10개	1,000개/오브젝트 버전
...	최대 1 GiB (1,000개 × 1 MiB)
데이터 형식	키-값(Key-Value) 문자열	키-값(Key-Value) 문자열	임의의 UTF-8 텍스트 (JSON / XML / YAML 등)
변경 방법	오브젝트 재업로드 필수	PutObjectTagging	PutObjectAnnotation (오브젝트 불변)
복사 시 동작	CopyObject로 유지	CopyObject로 유지	CopyObject로 유지 (x-amz-annotation-directive로 제어 가능)
쿼리	불가	S3 Inventory + Athena (간접)	S3 Metadata Tables로 직접 쿼리 가능

즉, S3 Annotations는 기존의 2KB 제한이 있는 사용자 메타데이터나 10개 제한이 있는 태그로는 표현할 수 없었던 **구조화된 업무 컨텍스트(Business Context)**를 오브젝트에 연결할 수 있습니다. 예를 들어, AI 에이전트가 "이 파일은 어떤 문서이며, 어떤 목차로 구성되어 있고, 몇 페이지인지"를 오브젝트 본체를 열지 않고도 전달하는 것이 가능합니다.

S3 Annotations의 사양을 실제로 확인하기

문서만으로는 실감이 잘 나지 않기 때문에, AWS CLI (v2.35.11)와 boto3를 사용하여 실제 동작을 확인해 보았습니다.

어노테이션 부여 (PutObjectAnnotation)

# 어노테이션 내용을 JSON 파일로 준비
$ echo '{"service": "Amazon Bedrock", "category": "user-guide", "pages": 5453}' > annotation.json
# 부여 (--annotation-payload에 파일 경로를 직접 지정)
...

--annotation-payload에는 파일 경로를 직접 전달합니다. file://나 fileb:// 프리픽스(Prefix)가 아니라, s3api get-object의 출력 대상 파일과 동일한 형식입니다.

어노테이션 목록 가져오기 (ListObjectAnnotations)

$ aws s3api list-object-annotations \
--bucket my-bucket \
--key docs/bedrock-ug.pdf \
...

페이로드 본체는 반환하지 않고 이름, 크기, ETag, 최종 수정일만 반환합니다. 내용을 확인하려면 다음의 GetObjectAnnotation이 필요합니다.

어노테이션 가져오기 (GetObjectAnnotation)

# 페이로드는 파일로 출력됨 (get-object와 동일한 패턴)
$ aws s3api get-object-annotation \
--bucket my-bucket \
...

get-object와 동일한 설계로, 마지막 위치 인자가 페이로드의 출력 대상입니다. 응답에 Content-Type 헤더는 포함되지 않습니다. S3는 어노테이션의 포맷(JSON/YAML/XML 등)을 구분하지 않고, 순수하게 바이트 열(Byte stream)로서 유지합니다.

실험: 페이로드의 제약

boto3로 각종 포맷을 시도한 결과를 정리합니다.

테스트	결과
JSON (일본어·이모지 포함)	✓ 수용
바이너리 (비 UTF-8)	✗ UnsupportedMediaType
Base64 인코딩된 바이너리	✓ 수용 (UTF-8로서 유효하기 때문)
정확히 1 MiB	✓ 수용
1 MiB + 1 byte	✗ EntityTooLarge

결론: 페이로드(Payload)가 유효한 UTF-8이어야 한다는 것이 유일한 제약입니다. JSON이든 YAML이든 일반 텍스트(Plain text)든 S3 측에서는 구분하지 않습니다. 포맷의 의미 부여는 이용자의 책임입니다.

실험: 어노테이션(Annotation) 이름의 제약

테스트	결과
aws_reserved (aws 접두사)	✗ InvalidAnnotation
s3_reserved (s3 접두사)	✗ InvalidAnnotation
test/slash (슬래시 포함)	✗ InvalidAnnotation
테스트이름 (일본어)	✓ 수용
영문·숫자·_・.・-	✓ 수용

실험: 덮어쓰기와 ETag

• 동일한 이름으로 PutObjectAnnotation 수행

→ 페이로드가 즉시 교체됨 (새로운 오브젝트 버전은 생성되지 않음) - 어노테이션 자체의 ETag는 변경됨
오브젝트 본체의 ETag는 변경되지 않음

매니지먼트 콘솔(Management Console)에서의 조작

S3 Annotations는 매니지먼트 콘솔에서도 조작할 수 있습니다.

오브젝트 상세 화면을 열면, 「태그(Tag)」 섹션 아래에 「주석(Annotation)」 섹션이 표시됩니다. 여기서 어노테이션 목록 확인, 추가, 삭제, 다운로드가 가능합니다.

오브젝트 상세 화면. metadata(121B)와 toc(4.1KB) 두 개의 어노테이션이 부여되어 있음

「어노테이션 추가」 버튼을 통해 새로운 어노테이션을 생성할 수 있습니다. 이름(1~512바이트, 영숫자·_・.・-·비ASCII UTF-8 문자)과 UTF-8 텍스트 파일(최대 1 MiB)을 업로드하는 형식입니다.

어노테이션 추가 화면. 기존 이름으로 추가하면 덮어쓰게 된다는 주의 문구가 표시됨

CLI / SDK가 수중에 없더라도, 콘솔에서 어노테이션 내용을 확인·다운로드할 수 있는 것은 운영상 편리합니다 (Annotations는 어디까지나 다운로드만 가능하며, 내용을 콘솔상에서 직접 확인하는 것은 불가능하다는 점에 주의하세요).

하고 싶은 것

과거 기사에서 S3 Files와 Strands Agents를 이용한 에이전틱 파일 서치(Agentic File Search) 기반을 검증했습니다.

당시 검증에서는 3권의 AWS 문서 PDF를 S3 Files 상에 마운트하고, 에이전트가 파일 시스템 조작(ls, grep, cat 등에 해당)만으로 정보를 찾는 구성을 시도했습니다. 결론적으로, 에이전틱 서치는 RAG와 비교하여 벡터 DB(Vector DB)가 필요 없이 파일을 직접 다룰 수 있는 유연성이 있는 반면, 문서가 대규모화되면 에이전트가 어떤 파일의 어느 부분을 읽어야 할지 알지 못해 탐색에 시간과 토큰을 낭비한다는 과제가 남았습니다.

이번 테마는 29권·합계 1.1GB·약 80,000페이지의 AWS 문서군에 대해, S3 Annotations를 통한 사전 메타데이터 부여가 에이전틱 서치의 효율을 어디까지 개선하는지에 대한 실증 실험입니다.

이곳의 리포지토리(Repository)에 소스 코드를 공개하고 있습니다 (사용은 자유이지만, 자기 책임하에 사용하시기 바랍니다).

과제

대규모 문서군에 대한 에이전틱 서치에는 본질적인 문제가 있습니다.

에이전트는 인간처럼 "일단 목차를 본다"라거나 "파일명으로 짐작한다"와 같은 사전 지식을 가지고 있지 않습니다. 29권의 PDF가 나열되어 있을 때, 질문에 대해 어떤 PDF의 어느 장을 읽어야 할지 판단하려면 어떠한 사전 정보가 필요합니다.

사전 정보가 없으면 에이전트는 다음과 같은 비효율적인 행동을 취합니다.

• 파일명만으로 추측하여 무작정 페이지를 읽기 시작함
• grep

로 전체 텍스트를 검색하지만, 5,000페이지의 PDF에서 모든 텍스트를 추출하는 것은 비현실적입니다. 여러 번의 시행착오를 반복하며 토큰과 시간을 소비하게 됩니다.

• 최악의 경우, 타임아웃이 발생합니다.

과제에 대한 접근 방식

일반적으로 에이전트에게 업무 컨텍스트("어느 파일에 무엇이 적혀 있는가")를 전달하는 전략은 주로 4가지가 있습니다.

• 시스템 프롬프트(System Prompt)에 인덱스를 저장 — 파일 목록이나 요약을 프롬프트에 포함시킴
• 도구 설명(Tool Description)에 인덱스를 저장 — 도구의 설명문에 파일 정보를 포함시킴
• S3 내부에 인덱스 파일을 넣음 — index.json과 같은 파일을 에이전트가 읽도록 함
• 메타데이터 관리용 DB 구축 — DynamoDB 등에 구조화된 메타데이터를 유지하고, 도구를 통해 쿼리하게 함

하지만 이러한 방법에는 다음과 같은 과제가 있습니다.

• 1과 2: 문서 수가 증가하면 컨텍스트 윈도우(Context Window)를 압박합니다. 29권의 목차를 프롬프트에 넣으면 수만 토큰을 소비하며, 매 요청마다 비용이 증가합니다.
• 3: 인덱스 파일 자체가 거대해지면 읽어오는 데 시간이 걸립니다. 또한, 문서 추가 시 인덱스의 동기화 관리가 필요합니다.
• 4: 추가 인프라(DynamoDB, Lambda 등)가 필요하여 운영 비용과 구현 복잡성이 증가합니다. S3만으로 완결된다는 에이전틱 서치(Agentic Search)의 장점을 잃게 됩니다.

S3 Annotations를 통한 해결

S3 Annotations를 사용하면 이러한 과제들을 심플하게 해결할 수 있습니다.

• 각 문서에 직접 메타데이터 부여 — 서비스 이름, 페이지 수, 카테고리 등의 metadata 어노테이션과 목차(장 제목 + 페이지 번호)의 toc 어노테이션을 부여합니다.
• 에이전트는 필요할 때 필요한 정보만 취득 — 전체 29권의 메타데이터를 프롬프트에 넣을 필요가 없습니다. 에이전트가 get_annotation 도구로 개별적으로 취득합니다.
• 추가 인프라 불필요 — S3 API만으로 완결됩니다. DynamoDB나 인덱스 파일 관리도 필요 없습니다.
• 메타데이터 업데이트가 오브젝트에 영향을 주지 않음 — 문서를 재업로드할 필요 없이 어노테이션만 업데이트할 수 있습니다.

즉, S3 Annotations는 에이전틱 서치에서 "에이전트의 사전 지식"을 오브젝트에 직접 연결하기 위한 가장 자연스러운 수단입니다.

아키텍처

전체 아키텍처: AgentCore Runtime이 VPC 내에 배치되어, 3가지 서로 다른 경로로 AWS 서비스와 통신함

구성의 핵심 포인트는 다음과 같습니다.

• S3 Files를 AgentCore Runtime의 microVM에 NFS로 마운트하여, 에이전트가 /mnt/docs 하위의 파일을 로컬 파일 시스템처럼 조작할 수 있습니다.
• S3 Annotations는 파일 시스템이 아니라 S3 API를 통해 취득합니다. get_annotation 도구가 boto3를 사용하여 GetObjectAnnotation을 호출합니다.
• 2가지 검색 모드를 동일한 에이전트에서 전환할 수 있습니다. mode=annotation에서는 어노테이션 도구를 추가하고, mode=naive에서는 기존의 파일 시스템 조작만 수행합니다.

이번 검증에서 AgentCore Runtime의 microVM은 프라이빗 서브넷(Private Subnet)에 배치되어 있으며, 외부 서비스로의 액세스는 VPC 엔드포인트(VPC Endpoint)를 통해 완결됩니다.

AgentCore microVM (Private Subnet)
├── → Interface Endpoint → Amazon Bedrock (모델 추론)
├── → Gateway Endpoint → S3 API (어노테이션 취득)
...

모든 통신을 VPC 내부로 제한하여 보안을 의식한 설정으로 구성했습니다.

에이전트 구현

에이전트 본체

Strands Agents SDK로 에이전트를 구현하여 AgentCore Runtime에 배포했습니다.

SYSTEM_PROMPT_BASE = """\
당신은 파일 검색 어시스턴트입니다.
마운트된 S3 Files 파일 시스템 내의 파일을 검색하여 사용자의 질문에 답변합니다.
...

Agent 생성 부분에서는 모드에 따라 도구 목록(Tool list)과 프롬프트(Prompt)를 전환하고 있습니다.

@app.entrypoint
async def invoke(payload):
user_message = payload.get("prompt", "Hello")
...

SSE 스트리밍을 통해 브라우저 측에서 도구 호출(Tool call) 진행 상황을 실시간으로 표시할 수 있습니다. agent.stream_async()가 반환하는 이벤트를 text_delta, tool_start, tool_end, done의 4가지 유형으로 포맷하여 yield 합니다.

도구군 (Toolsets)

도구	기능	취득처
list_tree	디렉토리 목록	S3 Files (NFS)
grep_tree	정규 표현식 검색	S3 Files (NFS)
read_pdf	PDF 텍스트 추출 (페이지 범위 지정)	S3 Files (NFS)
stat_path	파일 메타데이터	S3 Files (NFS)
get_annotation	S3 Annotation 취득	S3 API
list_annotations	Annotation 목록	S3 API

get_annotation의 구현은 매우 간단합니다.

@tool
def get_annotation(key: str, annotation_name: str = "metadata") -> str:
"""Get an S3 Annotation attached to a document."""
...

GetObjectAnnotation API를 한 번 호출하는 것만으로 수백 바이트에서 수 KB의 메타데이터가 반환됩니다. 5,000페이지 분량의 PDF를 열어보지 않고도, 해당 문서가 어떤 서비스에 대해 작성되었는지, 어떤 목차 구성을 가지고 있는지 즉시 알 수 있습니다.

Annotations의 내용

각 PDF에 두 개의 어노테이션(Annotation)을 부여하고 있습니다.

metadata 어노테이션 (~150바이트):

{
"service": "Amazon Bedrock",
"filename": "bedrock-ug.pdf",
...

toc 어노테이션 (~2-15KB, 장(Chapter)의 수에 따라 다름):

{
"chapters": [
{"title": "Overview", "level": 1, "page": 22},
...

에이전트는 toc 어노테이션을 읽는 것만으로 "Guardrails는 p.1745부터 시작한다"는 것을 알 수 있습니다. 5,453페이지의 PDF를 grep 할 필요가 없습니다.

데모

Annotation 방식의 동작: 어노테이션에서 목차를 가져와 해당 페이지를 정확히 특정하여 답변하는 모습

실제 동작을 살펴보겠습니다. 사용자가 "Amazon Bedrock Guardrails의 필터 종류를 알려줘"라고 질문했을 때, Annotation 방식과 Naive 방식의 비교입니다.

Annotation 방식의 동작 흐름:

1. list_tree() → docs/ 하위에 29개의 PDF 확인
2. get_annotation("docs/bedrock-ug.pdf", "metadata") → service: "Amazon Bedrock" 확인
3. get_annotation("docs/bedrock-ug.pdf", "toc") → "Guardrails"가 p.1745에 있음
...

Naive 방식의 동작 흐름:

1. list_tree() → 파일 목록 취득
2. grep_tree("guardrails", "docs") → 파일명 매칭으로 bedrock-ug.pdf 발견
3. grep_tree("guardrails", "docs/bedrock-ug.pdf") → 200페이지 제한으로 인해 부분적으로 히트
...

결정적인 차이는 Annotation 방식에서는 처음부터 목적 페이지 번호를 알고 있다는 점입니다.

실증 실험

실제로 제작한 S3 Annotations를 통한 에이전틱 서치(Agentic Search)가 실제로 정밀도와 속도를 개선하는지 실험을 진행합니다.

실험 조건

항목	값
문서 수	29권 (AWS AI/ML 계열 서비스 사용자 가이드)
...

질문 세트는 S3 Annotations의 사양에 관한 문제(12문항), Bedrock Guardrails / Knowledge Bases / AgentCore에 관한 문제(14문항), OpenSearch · SageMaker · Step Functions · Textract · Comprehend 등 각 서비스 고유 문제(24문항), 여러 문서를 가로지르는 통합 문제(5문항)로 구성되어 있습니다.

실험 방법

동일한 에이전트, 동일한 도구군, 동일한 모델을 사용하며, mode 파라미터의 전환만으로 비교를 수행합니다.

• Annotation 방식: get_annotation 및 list_annotations 도구 사용 가능. 시스템 프롬프트에 어노테이션 활용 절차를 추가
• Naive 방식: 어노테이션 도구 없음. 파일 시스템 조작(list_tree, grep_tree, read_pdf, stat_path)만 사용

평가 프레임워크: Strands Evals

정확성 평가에는 Strands Evals를 사용했습니다. Strands Evals는 Strands Agents SDK에 부속된 평가 프레임워크로, 에이전트의 출력 품질을 자동으로 채점할 수 있습니다.

평가 메커니즘은 다음과 같습니다.

• 테스트 케이스 정의: 각 질문에 대해 기대 답변(ground truth)을 설정
• 에이전트 실행: 동일한 질문을 두 모드 모두에서 실행하여 답변 텍스트를 획득
• LLM-as-a-Judge: OutputEvaluator가 별도의 LLM을 통해 답변을 채점. 기대 답변과의 일치도를 0.0~1.0 사이로 반환

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator
# 루브릭(채점 기준)을 정의
...

이 방식의 장점은 수작업 채점 비용 없이 대량의 테스트 케이스를 돌릴 수 있다는 점입니다. 반면, LLM을 통한 채점은 완벽하지 않으며, 특히 부분 정답 판정에서 편차가 발생할 가능성이 있습니다. 이번에는 5단계 루브릭을 정의하여 이러한 편차를 완화했습니다.

자세한 구현은 여기를 참조하십시오.

메트릭(Metrics) 획득

응답 시간과 토큰 소비량은 Strands Agents의 AgentResult.metrics에서 직접 가져옵니다.

if "result" in event:
r = event["result"]
usage = r.metrics.accumulated_usage
...

이는 Bedrock의 Invoke API가 반환하는 실측값이며, tokenizer에 의한 추정치가 아닙니다.

실험 결과

지표	Annotation 방식	Naive 방식	개선
정확성 스코어	0.95	0.75	+27%
평균 응답 시간	42.3초	340.9초	8배 속도
평균 도구 호출 수	3.7회	7.0회	47% 감소
1쿼리 추정 비용	~ $0.08	~ $0.18+	~ 55% 감소

데이터 전송량 비교:

지표	Annotation 방식	Naive 방식	개선
평균 읽기 바이트 수	51,801 B	429,013 B	87.9% 감소
평균 입력 토큰	~ 25,000	~ 50,000+	50% 이상 감소

고찰

왜 정확성에 차이가 발생하는가

Naive 방식의 스코어 0.75(55문항 중 약 14문항이 부정확하거나 실패)의 주요 원인은 대규모 PDF 탐색이 비효율적이었기 때문입니다.

5,000페이지의 PDF에 대해 grep_tree

는 200페이지 제한으로 중단됩니다. 목적 정보가 그보다 뒤쪽 페이지에 있는 경우, 에이전트(Agent)는 무작위로 페이지를 읽기 시작하거나 다른 키워드로 다시 grep을 시도합니다. 이러한 시행착오가 토큰(Token)을 소비하고, 세션 타임아웃(5분)에 도달하여 답변에 실패하는 케이스가 발생했습니다(이는 grep_tree의 구현 방식과 관계없이 발생합니다. 무의미하게 소비되는 토큰의 양과 도구의 효율적인 구현은 트레이드오프(Trade-off) 관계이며, 어떤 경우든 5,000페이지를 초과하는 PDF를 컨텍스트(Context) 안에 통째로 집어넣는 것은 비현실적입니다).

반면, Annotation 방식은 toc

어노테이션(Annotation)을 통해 페이지 번호를 사전에 파악할 수 있으므로, "Guardrails는 p.1745", "Knowledge Bases는 p.2627"과 같이 즉시 범위를 좁힐 수 있습니다. 탐색의 낭비가 구조적으로 배제되어 있다는 점이 가장 큰 요인입니다.

비용 내역

Annotation 방식의 비용 우위는 입력 토큰(Input Token) 수의 절감에서 비롯됩니다.

Annotation 방식 (1 쿼리):
- 시스템 프롬프트 (System Prompt): ~600 tokens
- list_tree 결과: ~200 tokens
...

S3 Annotations 자체의 비용은 사실상 제로입니다. 29권 × 2 어노테이션 = 58건, 합계 약 200KB의 저장 비용과 GET 상당의 요청 비용은 월 수 센트(Cent) 이하입니다.

고찰

왜 정확도에 차이가 발생하는가

Naive 방식으로 잘 되지 않는 케이스가 있는 이유는 대규모 PDF에 대한 탐색이 비효율적이기 때문입니다.

5,000페이지 분량의 AWS 서비스 문서 PDF에 대해 grep_tree는 200페이지 제한으로 중단됩니다. 목적 정보가 그보다 뒤쪽 페이지에 있는 경우, 에이전트(Agent)는 무작위로 페이지를 읽기 시작하거나 다른 키워드로 다시 grep을 시도합니다. 이러한 시행착오가 토큰(Token)을 소비하고, 세션 타임아웃(5분)에 도달하여 답변에 실패하는 케이스가 발생했습니다.

반면, Annotation 방식은 toc

어노테이션을 통해 페이지 번호를 사전에 파악할 수 있으므로, 당연하게도 "Guardrails는 p.1745", "Knowledge Bases는 p.2627"과 같이 즉시 범위를 좁힐 수 있습니다. 탐색의 낭비가 구조적으로 배제되어 있습니다.

비용 내역

Annotation 방식의 비용 우위는 입력 토큰(Input Token) 수의 절감에서 비롯됩니다.

Annotation 방식 (1 쿼리):
- 시스템 프롬프트 (System Prompt): ~600 tokens
- list_tree 결과: ~200 tokens
...

S3 Annotations는 항상 최적인가

항상 에이전틱 서치(Agentic Search)를 S3 Annotations로 구현하는 것이 효율적이라고 할 수는 없습니다. 예를 들어,

• 대상 문서가 수십 페이지 정도의 소규모인 경우, 전체를 그대로 읽어도 토큰 비용은 충분히 허용 범위 내에 있으며, 어노테이션을 사전에 부여하는 수고가 맞지 않음
• 목차나 장 구분이 없는 비구조화 문서(회의록, 채팅 로그, 코드 등)에서는 구조 기반의 네비게이션(Navigation) 자체가 작동하지 않음
• 문서의 업데이트 빈도가 높은 경우, 어노테이션 동기화가 운영 부담이 됨 (S3 Annotations는 PutObject로 오브젝트를 교체했을 때 자동으로 업데이트되지 않습니다. 버저닝(Versioning)이 활성화된 경우 구버전에는 어노테이션이 남아있지만, 신버전에는 어노테이션이 없는 상태가 됩니다.)

등의 케이스를 들 수 있습니다 (애초에 S3 Annotations가 이러한 업무 컨텍스트의 저장소로서 최적인지에 대해서도 논의의 여지가 있습니다. 소규모 파일 서치이거나 간이 PoC를 수행하는 케이스라면, 시스템 프롬프트에 파일 목록과 개요를 그대로 적는 것이 더 나을 수도 있습니다. 프롬프트에 들어갈 양이라면 API 호출 없이 첫 번째 턴부터 전체 모습을 파악할 수 있기 때문입니다.)

반면,

• 수십~수백 개의 오브젝트가 지속적으로 추가/삭제되며, 메타데이터를 오브젝트 본체와 동일한 라이프사이클(Lifecycle)로 관리하고 싶은 경우
• 메타데이터 기반(DynamoDB 테이블 설계, 동기화 Lambda, 정합성 체크 등)을 직접 운영하고 싶지 않은 경우
• S3에 이미 대량의 오브젝트가 존재하며, 사후에 구조 정보를 부여하고 싶은 경우
• CopyObject나 Replication을 통해 메타데이터도 자동으로 추종되기를 원하는 경우

등의 유스케이스(Use Case)에서는 S3 Annotations가 최적의 선택지가 됩니다.

S3 Annotations를 이용하면 데이터 본체와 동기화된 라이프사이클(Lifecycle)로 메타데이터를 관리할 수 있으며, S3 프레임워크 내에서 구현되어 있기 때문에 사용자 측에서 인프라를 고민할 필요도 없습니다. 오브젝트를 삭제하면 어노테이션(Annotation)도 삭제되고, 복사하면 함께 따라옵니다. 이러한 "본체에 종속된 메타데이터"라는 설계 사상이 외부 DB에 인덱스를 가지는 방식과의 본질적인 차이점입니다.

요약

S3 Annotations를 활용한 에이전틱 서치(Agentic Search)에서는 29권, 80,000페이지 규모의 대규모 문서군을 대상으로 기존의 전체 텍스트 검색(Full-text Search) 방식과 비교하여 다음과 같은 개선 사항을 확인했습니다.

• 정확도 +27% (0.75 → 0.95)
• 응답 시간 8배 가속화 (340초 → 42초)
• 비용 55% 절감 ($0.18 → $0.08/쿼리)
• 데이터 전송량 88% 절감