S3 annotations로 변화하는 메타데이터를 "어디에 둘 것인가"에 대한 판단

2026년 6월 17일 AWS Summit New York에서는 에이전트를 실무 환경에서 구동하기 위한 인프라를 갖추기 위한 발표가 여럿 이어졌습니다. 발표의 전체적인 모습은 공식 블로그에 정리되어 있습니다.

그중에는 제목만 읽으면 수수한 것이 있습니다. S3 annotations입니다. 오브젝트에 최대 1GB의 정보를 직접 매달 수 있는 기능이기에, 처음에는 "태그 용량이 늘어난 것뿐"으로 보일지도 모릅니다.

하지만 이를 용량의 문제로 받아들인다면 본질을 놓치게 됩니다. 이것은 S3 오브젝트에 부수되는 정보를 "어디에 둘 것인가"라는 판단을 바꾸는 기능입니다. 지금까지 많은 경우, 답은 "오브젝트 외부"였습니다. 외부 데이터베이스나 사이드카 파일(sidecar file)에 두고 동기화를 통해 일관성을 맞춰왔습니다. S3 annotations는 그 답에 "외부로 내보내지 않는다"라는 선택지를 추가합니다. S3에 데이터를 두면서 그 옆에서 메타데이터를 별도로 관리해 온 사람이라면, 그 동기화 작업의 번거로움을 기억하고 있을 것입니다.

공식 발표는 이곳입니다.

가장 큰 차이점은 "용량보다 성질"

annotations를 기존의 메타데이터 수단과 비교해 보면, 중요한 것은 숫자가 아니라 성질의 차이라고 할 수 있습니다.

수단	쓸 수 있는 양	변경	성질
시스템 정의 메타데이터 (System-defined metadata)	고정 항목	불가	오브젝트의 내재적 속성
...

수량 및 사이즈 사양값은 공식 블로그에 기반한 것입니다. 차이가 명확하게 드러나는 것은 아래 두 줄입니다. 태그(Tag)는 키(Key)와 값(Value)만으로 이루어진 라벨로, 액세스 제어나 비용 배분을 위한 것입니다. annotations는 JSON이나 YAML로 구조를 가질 수 있으며, 오브젝트를 다시 쓰지 않고도 몇 번이고 다시 쓸 수 있습니다. 복사나 레플리케이션(Replication) 시 오브젝트와 함께 운반되며, 삭제하면 함께 삭제됩니다.

이러한 성질의 차이는 그대로 용도의 차이로 이어집니다. 태그는 "이 오브젝트를 어떻게 다룰 것인가"를 나타내는 라벨입니다. annotations가 담당하는 것은 "이 오브젝트가 무엇이며, 무엇을 알고 있는가"라는, 나중에 늘어나는 지식입니다. AI가 생성한 요약이나 전사(Transcription), 추론의 신뢰도, 처리 이력. 이러한 정보는 2KB에 담기지 않으며, 데이터가 변함에 따라 업데이트하고 싶어집니다. 지금까지 이 요구사항을 충족하려면 오브젝트 외부로 내보낼 수밖에 없었습니다.

AWS의 설명과 그 한 발 앞선 생각

공식 블로그는 annotations를 "별도의 메타데이터 관리 시스템을 불필요하게 만드는 것"이라고 설명합니다. 확실히 횡단 검색을 위해 DynamoDB에 이중으로 쓰고, Lambda로 동기화하며, 정합성을 감시하는 구성은 유스케이스에 따라 생략할 수 있습니다. 부여된 annotation은 S3 Metadata를 통해 Apache Iceberg 형식의 테이블로 흘러 들어가며, Amazon Athena를 통해 횡단 검색할 수 있습니다.

다만, "외부 DB가 필요 없어진다"라는 이해에서 멈춘다면 공식이 이미 말하고 있는 내용을 읊는 것에 불과하게 됩니다. 장소를 바꾸면 다른 것들도 옮겨갑니다. 문맥(Context)을 오브젝트 외부에 두었을 때는 외부 DB의 액세스 제어가 그 문맥에 누가 접근할 수 있는지를 결정했습니다. 이것이 오브젝트 측으로 옮겨오면, 누가 어떤 문맥을 다시 쓸 수 있는지를 재설계해야 합니다. annotations의 부여와 취득에는 s3:PutObjectAnnotation / s3:GetObjectAnnotation이라는 IAM 액션이 필요합니다. 문맥과 데이터가 밀결합(Tight coupling)되는 것은 장점입니다. 하지만 문맥의 변조가 곧바로 데이터의 오독으로 이어진다는 의미이기도 합니다.

또 하나 옮겨가는 것은 구조를 결정하는 책임입니다. 키와 값만 있는 태그에는 설계의 여지가 거의 없었지만, 구조를 가질 수 있다는 것은 어떤 키로 무엇을 나타내고 어떤 입도(Granularity)로 나눌지를 결정해야 한다는 뜻입니다. 에이전트에게 읽히는 것을 전제로 한다면, 이 부분이 검색 정확도를 좌우합니다. "일단 전부 넣자"라고 하면 나중에 횡단 쿼리에서 쓸모없게 되는 사태가 발생할 수 있습니다. 용량의 자유는 설계의 책임과 세트로 찾아옵니다.

자체 동기화 메커니즘을 어디까지 정리할 수 있는가

"그렇다면 전부 annotations로 몰아넣으면 된다"라고 할 수는 없습니다. 무엇을 몰아넣을 수 있는지에는 경계가 있습니다.

클래스 메서드 검증에서는 Annotation Table이 활성화될 때까지 소규모 환경에서도 약 25분이 걸렸다고 보고되었습니다. 이는 타인의 검증값이지만, 테이블로의 반영이 비동기(Asynchronous)라는 사양과 일치합니다. 부여한 즉시 횡단 검색에 반영되는 것은 아니라는 뜻입니다.

여기서 솔직하게 도출할 수 있는 결론은 저지연(Low Latency)이 요구되는 상황과의 상성입니다. 화면 표시를 할 때마다 밀리초(ms) 단위로 가져와야 하는 정보나, 보조 인덱스(Secondary Index)를 사용한 검색이 필요한 정보는 기존의 DynamoDB 구성이 더 적합할 것입니다. 반대로 컴플라이언스 상태나 이력, 요약과 같이 "나중에 업데이트되지만 즉시성은 필요 없는" 맥락은 annotations 쪽으로 기울이는 것이 좋아 보입니다. 줄일 수 있는 것은 동기화 메커니즘의 일부이지, 전부가 아닙니다.

비용 또한 한 방향으로만 내려가는 것은 아닙니다. 정합성을 감시하는 동기화 메커니즘을 내려놓을 수 있는 반면, annotation의 저장과 읽기/쓰기는 S3 Standard와 동일한 요금으로 과금되며, 횡단 검색을 지원하는 S3 Metadata나 Annotation Table에도 처리 및 보관 비용이 발생합니다. 줄일 수 있는 비용과 늘어나는 비용을 비교하게 될 것입니다. 요금 내역은 공식 요금 페이지에 정리되어 있습니다.

리전 지원에도 차이가 있습니다. 공식 블로그에 따르면, annotation 부여 자체는 거의 모든 리전에서 사용할 수 있는 반면, 횡단 검색을 위한 Annotation Table은 S3 Metadata를 이용할 수 있는 리전으로 제한됩니다. S3 Metadata 지원은 순차적으로 확대되고 있으며, 도쿄(ap-northeast-1)와 오사카(ap-northeast-3)도 이미 지원됩니다. 일본 국내에서 운영하는 데 있어서는 이 부분이 지장이 되지는 않을 것입니다.

지원 리전이나 기능별 가능 여부는 변경될 수 있으므로, 최신 정보는 공식 문서에서 확인하는 것이 확실합니다.

에이전트(Agent)는 전제 조건인가

annotations는 에이전트(Agent)를 위해 설계되었으며, 공식 설명도 이를 전제로 작성되어 있습니다. 여기서 "나는 AI 에이전트를 운영하지 않으니 상관없다"며 그냥 지나치고 싶어질 수도 있지만, 일단은 참아야 합니다.

에이전트의 유무와 관계없이, 현재 사이드카 파일(Sidecar file)이나 외부 메타데이터 DB를 운영하고 있다면, 저장 위치가 바뀐다는 점은 이점이 됩니다. annotations의 실체는 "객체에 구조화된 맥락을 밀착시켜 횡단 검색할 수 있다"는, 메타데이터 관리 그 자체의 개선입니다. 자연어 검색은 S3 Tables MCP 서버를 통해 나중에 추가할 수 있으므로, 우선 동기화 메커니즘을 줄이는 방식부터 접근해도 충분합니다. 에이전트는 배치한 맥락의 첫 번째 독자가 될 수 있는 존재이지, 전제 조건은 아닙니다.

객체 단위에서 조직 단위의 맥락으로

시야를 한 단계 넓히면, annotations는 단일 기능이라기보다 어떤 흐름의 일부로 보입니다. 동일한 Summit에서, 조직 전체의 데이터 관계를 지식 그래프(Knowledge Graph)로 옮기는 AWS Context라는 메커니즘이 예고되었습니다. 참고로 제공은 향후 예정되어 있다고 합니다.

S3 annotations가 객체 단위의 맥락이라면, AWS Context는 조직 단위의 맥락입니다. 양쪽 모두 Apache Iceberg 형식으로 S3에 생성되도록 설계되어 있어, 하나의 연속된 흐름으로 보입니다. 각 팀이 RAG를 위한 맥락을 개별적으로 보유하고 있던 상태에서, 조직 공통의 관리된 맥락 계층으로 모아가는 과정입니다. annotations는 그 최하층, 즉 객체에 맥락을 밀착시키는 역할을 담당한다고 이해하는 것이 좋아 보입니다.

어디서부터 시작할 것인가

첫걸음은 현재 외부 DB나 사이드카로 가지고 있는 맥락을 정리(Inventory)하는 것이라고 할 수 있습니다. 앞서 언급한 "나중에 업데이트되지만 즉시성은 필요 없는" 맥락을 추출하여 annotations의 후보로 삼습니다. 스키마 또한 하나의 버킷에서 AI에게 읽히고 싶은 키(Key)를 몇 개 정하는 것부터 시작해도 충분합니다. 구조를 결정해야 하는 책임이 새롭게 생겨났다는 전제만 가지고 있다면, 나중에 횡단 쿼리(Cross-query)로 인해 곤란을 겪을 확률은 낮아질 것입니다.

객체 외부에 맥락을 두는 것을 오랫동안 전제로 해왔습니다. 그것을 다시 질문할 수 있게 되었다는 사실 자체에 의미가 있습니다. 이것은 용량이 늘어났다는 이야기가 아니라, 맥락에 대해 누가 책임을 질 것인가에 대한 답이 객체 측으로 돌아왔다는 뜻이라고 생각합니다.