S3 annotations와 객체 메타데이터를 어디에 저장해야 하는가에 대한 문제

2026년 6월 17일, AWS Summit New York에서는 프로덕션 환경에서 에이전트(agents)를 실행하기 위한 인프라를 채워주는 일련의 발표가 이어졌습니다. 공식 블로그에 전체 요약 내용이 게시되어 있습니다.

https://aws.amazon.com/blogs/aws/top-announcements-of-the-aws-summit-in-new-york-2026/

그중 하나는 헤드라인만 봐도 명확하게 드러납니다: S3 annotations입니다. 객체에 직접 최대 1GB의 정보를 첨부할 수 있으므로, 첫인상은 "태그(tags)가 더 커졌다"는 것입니다.

이를 단순히 용량의 문제로 읽는 것은 핵심을 놓치는 것입니다. 이것은 하나의 결정 사항을 바꿉니다: S3 객체에 첨부된 정보가 어디에 위치해야 하는가 하는 점입니다. 오랫동안 그 답은 대개 "객체 외부"였습니다. 정보를 외부 데이터베이스(external database)나 사이드카 파일(sidecar file)에 보관하고 동기화 프로세스(sync process)를 통해 두 가지를 일치시켰습니다. S3 annotations는 그 답에 또 다른 옵션을 추가합니다: 밖으로 옮기지 마세요. 만약 메타데이터(metadata)를 별도로 관리하면서 데이터는 S3에 보관해 왔다면, 두 가지를 동기화 상태로 유지하는 데 드는 비용을 잘 알고 있을 것입니다.

공식 발표 내용은 여기에서 확인할 수 있습니다:
https://aws.amazon.com/blogs/aws/amazon-s3-annotations-attach-rich-queryable-context-directly-to-your-objects/

차이점은 용량이 아니라 성격입니다

객체를 설명하는 기존 방식들과 annotations를 비교해 보면, 중요한 것은 수치가 아니라 성격(character)의 차이입니다.

메커니즘 (Mechanism)	양 (How much)	가변성 (Mutable)	성격 (Character)
시스템 정의 메타데이터 (System-defined metadata)	고정된 필드 (Fixed fields)	아니오 (No)	객체의 본질적 속성 (Intrinsic properties of the object)
...

수치와 크기는 공식 블로그에서 가져왔습니다. 명확한 차이는 하단 두 행에 있습니다. 태그 (Tags)는 키-값 (key-and-value) 라벨로, 액세스 제어 (access control) 및 비용 할당 (cost allocation)을 목적으로 합니다. annotations는 JSON 또는 YAML 형식을 통해 구조를 가지며, 객체를 다시 쓰지 않고도 원하는 만큼 자주 다시 작성할 수 있습니다. 이들은 복사 및 복제 시 객체와 함께 이동하며, 객체가 삭제될 때 함께 제거됩니다.

성격이 다르다는 것은 역할이 다르다는 것을 의미합니다. 태그는 객체를 어떻게 처리할지를 설명합니다. annotations는 객체가 무엇인지, 그리고 객체에 대해 알려진 정보, 즉 사후에 축적되는 지식의 종류를 담습니다: AI가 생성한 요약 (AI-generated summary), 추론 신뢰도 점수 (inference confidence score), 처리 이력 (processing history) 등이 이에 해당합니다. 이러한 정보는 2 KB 용량에 맞지 않으며, 데이터가 변경됨에 따라 업데이트하기를 원하게 됩니다. 지금까지 이러한 요구 사항을 충족하려면 컨텍스트 (context)를 객체 외부로 이동시켜야만 했습니다.

AWS의 입장, 그리고 그 너머

공식 블로그는 annotations가 별도의 메타데이터 시스템을 사용할 필요성을 제거한다고 설명합니다. 객체 간 검색을 위해 DynamoDB에 이중 기록 (double-writing)을 하거나, Lambda와 동기화하고, 드리프트 (drift)를 감시하던 패턴을 일부 사용 사례에서는 더 이상 사용할 필요가 없다는 것은 사실입니다. 여러분이 부착한 annotations는 S3 메타데이터를 통해 Apache Iceberg 테이블로 흘러 들어가 Amazon Athena에서 쿼리할 수 있게 됩니다.

하지만 "더 이상 외부 데이터베이스가 필요하지 않다"는 말에서 멈추는 것은 AWS가 이미 언급한 내용을 반복하는 것에 불과합니다. 정말로 파고들 가치가 있는 부분은 위치(location)와 함께 무엇이 함께 이동하느냐 하는 점입니다. 컨텍스트(context)가 객체 외부에 존재할 때는, 누가 그 컨텍스트에 접근할 수 있는지가 해당 외부 데이터베이스의 액세스 제어(access control)에 의해 직접 결정되었습니다. 일단 컨텍스트가 객체 내부에 위치하게 되면, 어떤 컨텍스트를 누가 변경할 수 있는지에 대한 설계를 다시 해야 합니다. 어노테이션(annotations)을 추가하고 읽으려면 s3:PutObjectAnnotation 및 s3:GetObjectAnnotation IAM 액션(actions)이 필요합니다. 컨텍스트를 데이터와 밀접하게 결합하는 것이 이점이지만, 이는 곧 컨텍스트를 조작하는 것이 데이터의 오독(misreading)으로 직결됨을 의미하기도 합니다.

함께 이동하는 또 다른 요소는 구조(structure)에 대한 책임입니다. 키-값(Key-and-value) 태그는 설계의 여지가 거의 없었지만, 구조를 가질 수 있다는 것은 어떤 키가 무엇을 나타낼지, 그리고 어느 정도의 세분성(granularity)으로 나눌지를 결정해야 함을 의미합니다. 만약 에이전트(agent)가 이를 읽도록 설계되었다면, 그 결정이 검색 품질을 좌우합니다. 모든 것을 무분별하게 쏟아부으면, 나중에 객체 간 쿼리(cross-object query)를 수행할 때 쓸모없는 어노테이션이 되어버립니다. 용량의 자유는 설계의 책임과 함께 찾아옵니다.

동기화 계층(sync layer)을 실제로 얼마나 폐기할 수 있는가

"그렇다면 모든 것을 어노테이션으로 옮겨라"라는 결론은 타당하지 않습니다. 옮길 수 있는 것에는 한계선이 존재합니다.

Classmethod의 검증에 따르면, Annotation Table은 작은 환경에서도 활성화되는 데 약 25분이 소요되었습니다. 이는 제3자의 측정 결과이지만, 사양(spec)과 일치합니다. 즉, 테이블로의 반영(reflection)은 비동기적(asynchronous)으로 이루어집니다. 여러분이 부착한 정보는 작성하는 즉시 객체 간 검색(cross-object search)에 반영되지 않습니다.
https://dev.classmethod.jp/articles/s3-annotations-crud-athena-search/

명확한 결론은 저지연 읽기 (low-latency reads)에 적합한지가 관건이라는 점입니다. 모든 화면 렌더링 시 밀리초(ms) 단위로 가져와야 하거나 보조 인덱스 조회 (secondary-index lookup)가 필요한 정보는 여전히 기존의 DynamoDB 설계에 더 적합합니다. 반면, 규정 준수 상태 (compliance status), 이력 (history), 또는 요약 (summaries)과 같이 나중에 업데이트되어도 되며 즉각성이 필요하지 않은 컨텍스트는 어노테이션 (annotations)에 더 가깝습니다. 여러분이 폐기하는 것은 동기화 계층 (sync layer)의 일부이지, 전체가 아닙니다.

비용 또한 한 방향으로만 움직이지는 않습니다. 드리프트 (drift)를 감시하는 동기화 계층을 없앨 수는 있지만, 어노테이션을 저장하고 읽는 비용은 S3 Standard 스토리지 및 요청과 동일한 요율로 청구되며, 객체 간 검색 (cross-object search)을 지원하는 S3 메타데이터 (S3 Metadata) 및 어노테이션 테이블 (Annotation Tables)은 자체적인 처리 및 스토리지 비용이 발생합니다. 제거되는 비용과 추가되는 비용을 저울질해야 합니다. 상세 내역은 가격 페이지에서 확인할 수 있습니다.
https://aws.amazon.com/s3/pricing/

리전 (Region) 지원 범위도 다릅니다. 공식 블로그에 따르면, 어노테이션을 부착하는 것은 거의 모든 리전에서 작동하지만, 객체 간 검색에 사용되는 어노테이션 테이블은 S3 메타데이터를 사용할 수 있는 리전으로 제한됩니다. S3 메타데이터의 지원 범위는 단계적으로 확장되어 왔습니다.
https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-metadata-expands-22-regions/

지원 범위와 기능별 가용성은 변할 수 있으므로, 현재 상태를 확인하기에는 문서 (documentation)가 가장 신뢰할 수 있는 곳입니다.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/annotations-overview.html

에이전트 (agent)가 전제 조건인가

어노테이션은 에이전트를 위해 설계되었으며, 공식 설명도 이를 염두에 두고 작성되었습니다.

에이전트 여부와 상관없이, 현재 사이드카 파일 (sidecar files)이나 외부 메타데이터 데이터베이스 (external metadata database)를 운영하고 있다면, 저장 위치의 전환에서 이점이 나타납니다. 어노테이션 (annotations)의 실체는 메타데이터 관리 (metadata management) 자체의 개선입니다. 즉, 객체 (object)에 가깝게 부착되어 객체 전반에 걸쳐 쿼리 (query) 가능한 구조화된 컨텍스트 (structured context)입니다. S3 Tables MCP 서버를 통해 자연어 검색 (Natural-language search)을 나중에 추가할 수 있으므로, 동기화 계층 (sync layer)을 먼저 폐기하는 것이 좋은 시작 방법입니다. 에이전트는 당신이 배치한 컨텍스트를 읽는 첫 번째 독자가 될 가능성이 있는 것이지, 전제 조건은 아닙니다.

객체 수준에서 조직 수준의 컨텍스트로

시야를 넓혀보면, 어노테이션은 독립적인 기능이라기보다 하나의 흐름 (movement)의 일부처럼 보입니다. 동일한 Summit에서 AWS는 조직 전체의 데이터 관계를 지식 그래프 (knowledge graph)로 매핑하는 AWS Context를 프리뷰 (preview)했습니다. 이는 향후 출시될 예정이라고 명시되어 있습니다.
https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/

S3 어노테이션이 객체 수준 (object level)의 컨텍스트라면, AWS Context는 조직 수준 (organization level)의 컨텍스트입니다. 두 기능 모두 S3에서 Apache Iceberg 형식으로 나타나도록 설계되었으므로 연속적으로 읽힙니다. 이러한 흐름은 각 팀이 RAG를 위해 자체적인 컨텍스트를 보유하던 방식에서, 조직 전체를 위해 관리된 액세스 (managed access)를 갖춘 공유 컨텍스트 계층 (shared context layer)으로 이동하는 것입니다. 어노테이션은 그중 가장 낮은 계층, 즉 컨텍스트가 객체에 가깝게 부착되는 부분을 담당합니다.

시작하는 방법

첫 번째 단계는 현재 외부 데이터베이스나 사이드카에 보유하고 있는 컨텍스트의 인벤토리 (inventory)를 작성하는 것입니다. 위에서 설명한 컨텍스트 중, 나중에 업데이트되어도 되지만 즉시성이 필요하지 않은 종류를 추출하여 어노테이션의 후보로 만드세요. 스키마 (schema)의 경우, 단일 버킷 (bucket)에서 에이전트가 읽기를 원하는 몇 가지 키 (keys)를 결정하는 것만으로도 시작하기에 충분합니다. 구조에 대한 책임이 이제 당신에게 있다는 전제를 유지하는 한, 나중에 객체 간 쿼리 (cross-object query) 문제로 막힐 가능성을 낮출 수 있습니다.

오랫동안, 객체 외부에서 컨텍스트 (context)를 유지하는 것은 단순히 전제 조건이었습니다. 그 전제에 의문을 제기할 수 있다는 것 자체에 의미가 있습니다. 이것은 더 많은 용량 (capacity)에 관한 이야기가 아닙니다. 이것은 컨텍스트 (context)에 대한 책임이 누구에게 있는가에 대한 이야기이며, 그 답은 다시 객체 (object)의 측면으로 돌아왔습니다.