이 영상은 AWS의 데이터 및 분석 부사장인 마이랜 톰슨 부코벡(Mai-Lan Tomsen Bukovec)과의 대화를 통해 세계 최대 클라우드 스토리지 서비스인 AWS S3의 엄청난 규모, 설계 원칙, 그리고 끊임없이 진화하는 기술에 대해 깊이 있게 다룹니다. S3가 500조 개 이상의 객체와 수백 엑사바이트의 데이터를 저장하며 매년 1천조 건 이상의 요청을 처리하는 경이로운 스케일부터, 과거의 '최종 일관성(Eventual Consistency)'에서 '강력한 일관성(Strong Consistency)'으로 전환하며 겪었던 엔지니어링 도전, 그리고 형식 검증(Formal Methods)과 실패 허용치(Failure Allowances) 같은 고급 개념들을 소개합니다. 또한, S3가 고객의 요구에 맞춰 테이블(Tables)과 벡터(Vectors) 같은 새로운 데이터 프리미티브를 도입하며 어떻게 진화하고 있는지, 그리고 이러한 복잡한 시스템을 단순함(Simplicity)이라는 핵심 원칙으로 어떻게 관리하는지에 대한 흥미로운 통찰을 제공합니다.

1. S3의 압도적인 규모와 시작 🚀

마이랜은 S3의 현재 규모를 설명하며 대화를 시작했습니다. S3는 현재 500조 개 이상의 객체와 수백 엑사바이트(exabytes)의 데이터를 보유하고 있으며, 초당 수억 건의 트랜잭션을 처리합니다. 특히 매년 1천조 건(quadrillion) 이상의 요청을 처리하며, 이는 상상을 초월하는 규모입니다. S3의 기반에는 수천만 개의 하드 드라이브와 수백만 개의 서버가 38개 리전의 120개 가용 영역(Availability Zones)에 분산되어 있습니다. 마이랜은 모든 드라이브를 쌓으면 국제 우주 정거장까지 닿았다가 거의 돌아올 정도라고 비유하며 그 규모를 실감 나게 설명합니다.

"S3는 500조 개 이상의 객체를 보유하고 있습니다. 수백 엑사바이트의 데이터를 가지고 있으며, 전 세계적으로 초당 수억 건의 트랜잭션을 처리합니다. 그리고 매년 1천조 건 이상의 요청을 처리합니다." "모든 드라이브를 하나씩 쌓는다고 상상해보세요. 국제 우주 정거장까지 갔다가 거의 돌아올 것입니다."

S3는 2005년 개발을 시작하여 2006년 첫 AWS 서비스로 출시되었습니다. 당시 아마존 엔지니어들은 PDF, 이미지, 백업과 같은 비정형 데이터(unstructured data)를 경제적인 비용으로 저장하고 스토리지 성장에 대한 걱정을 덜어줄 공간이 필요했습니다. 그래서 S3는 초기부터 최종 일관성(eventual consistency)을 기반으로 설계되었습니다. 데이터를 저장하면 시스템이 데이터를 가지고 있음을 확인하지만, 바로 목록에 나타나지 않을 수도 있는 방식이었습니다. 이는 당시 이커머스 웹사이트와 같이 사람이 새로고침을 할 수 있는 환경에서는 적합했습니다.

2. 데이터 웨어하우스의 등장과 S3의 진화 📊

2006년 아파치 하둡(Apache Hadoop) 커뮤니티가 시작되면서 넷플릭스, 핀터레스트와 같은 프론티어 데이터 고객(frontier data customers)들이 하둡과 S3의 경제성 및 무제한 스토리지, 우수한 성능을 결합하여 데이터 레이크(data lakes)를 구축하기 시작했습니다. 이들은 비정형 데이터 외에 테이블 형식 데이터(tabular data)까지 S3에 저장하며 S3의 활용 범위를 넓혔습니다. 마이랜은 특히 2020년경 파케이(Parquet) 파일의 증가를 언급하며, 고객들이 S3의 장점을 테이블에 적용하기 위해 직접 파케이 데이터를 관리하기 시작했다고 설명했습니다.

"넷플릭스와 핀터레스트와 같은 프론티어 데이터 고객들은 하둡과 S3의 경제성 및 특성, 즉 무제한 스토리지와 꽤 좋은 성능을 훌륭한 가격에 결합하여 당시 우리가 데이터 레이크라고 부르기 시작한 것을 구축하기로 결정했습니다."

2019~2020년에는 아이스버그(Iceberg)의 부상이 두드러졌습니다. 아이스버그는 대규모 분석 워크플로우를 위한 오픈소스 데이터 포맷으로, 밑단의 파케이 데이터에 테이블 속성을 부여하여 고객들이 분산 분석 아키텍처(decentralized analytics architecture)를 구축할 수 있게 했습니다. 이를 통해 다양한 비즈니스 부서나 팀이 Iceberg를 준수하는 한 원하는 분석 엔진을 자유롭게 선택할 수 있게 되었습니다. AWS는 2024년 12월, 이러한 고객의 요구에 부응하여 S3 테이블(S3 Tables)을 출시했습니다. 그리고 2025년 7월에는 S3 벡터(S3 Vectors)의 프리뷰를 출시하고, 지난주(2026년 1월 기준) 정식 출시하며 S3의 데이터 스토리지 범위를 더욱 확장했습니다.

3. S3의 기본 아키텍처와 저렴한 가격의 비결 💰

S3의 개발자 경험은 처음부터 단순함(simplicity)을 핵심 목표로 삼았습니다. S3의 기본적인 기능은 데이터를 넣고(put), 데이터를 가져오는(get) 것이며, 이 두 가지 작업을 대규모로 효율적으로 수행하는 것이 S3의 본질입니다. 물론 시간이 지남에 따라 삭제(delete), 목록(list), 복사(copy) 등 다양한 API가 추가되었고, 최근에는 조건부 put(put if absent, put if match)과 조건부 delete(delete if match) 같은 기능도 추가되어 개발자들이 애플리케이션의 동작에 따라 데이터를 처리할 수 있게 되었습니다. S3의 기본 용어는 버킷(buckets), 객체(objects), 키(keys)이지만, 이제는 S3 테이블과 벡터와 같은 새로운 데이터 구조도 포함됩니다.

S3는 2006년 출시 당시 기가바이트당 월 15센트라는 파격적인 가격으로 시장에 충격을 주었으며, 현재는 2~3센트 수준으로 지속적으로 가격을 인하해 왔습니다. 이러한 저렴한 가격의 비결은 S3의 목표와 설계 철학에 있습니다. S3의 미션은 "지구상 최고의 스토리지 서비스 제공"이며, IDC 보고서에 따르면 데이터는 연간 27%씩 성장하고 있지만, 실제 S3 고객들은 이보다 훨씬 빠르게 데이터를 늘려가고 있습니다. 이처럼 폭발적으로 증가하는 데이터를 경제적으로 저장할 수 있도록 AWS는 다음과 같은 노력을 기울입니다:

• 지속적인 가격 인하: 스토리지 비용뿐만 아니라 S3 테이블의 압축 비용처럼 기능 비용도 대폭 인하합니다.
• 총 소유 비용(Total Cost of Ownership, TCO) 관리: 단순히 스토리지 가격뿐 아니라 계층화(tiering) 및 아카이브(archive) 기능을 제공하여 데이터의 전체 수명 주기에 걸친 비용을 최적화합니다.
• 지능형 티어링(Intelligent-Tiering): 2018년에 출시된 이 기능은 데이터가 한 달 동안 액세스되지 않으면 자동으로 할인(최대 40%)을 적용하여 고객이 직접 티어링을 관리할 필요 없이 동적으로 비용을 절감합니다.

AWS는 하드웨어부터 소프트웨어 스택의 최하단까지 모든 부분에서 효율성을 극대화하여 비용을 절감합니다. Amazon Glacier는 즉각적인 액세스가 필요 없는 데이터를 월 기가바이트당 1센트라는 파격적인 가격으로 저장할 수 있게 해줍니다. 이는 데이터 접근 속도에 대한 제약(예: 몇 시간 대기)을 통해 얻는 비용 절감 효과입니다. 엔지니어들은 가용성, 내구성, 비용 등 다양한 제약을 고려하여 혁신적인 아키텍처를 설계하고, 데이터센터 운영 방식까지도 비용 효율성을 극대화하는 방향으로 고민합니다.

4. 최종 일관성에서 강력한 일관성으로의 전환과 형식 검증 🛡️

S3는 초기에는 최종 일관성을 제공하여 높은 가용성(availability)을 우선시했습니다. 최종 일관성 시스템에서는 분산된 노드에 데이터를 기록할 때 모든 노드가 동시에 일관된 상태가 될 필요가 없으므로, 개별 노드 장애에 유연하게 대응하여 높은 가용성을 유지할 수 있습니다.

하지만 고객들이 S3를 데이터 레이크로 활용하면서 강력한 일관성(strong consistency)에 대한 요구가 커졌습니다. 강력한 일관성은 객체 조회 시 항상 가장 최근에 기록된 객체 상태를 반영하는 속성입니다. 이를 구현하기 위해 S3는 근본적인 변화를 겪었습니다. S3의 인덱싱 하위 시스템(indexing subsystem)은 모든 객체 메타데이터(이름, 태그, 생성 시간 등)를 저장하며, 모든 get, put, list, head, delete와 같은 API 호출 시 액세스됩니다.

S3는 강력한 일관성을 제공하면서도 가용성을 희생하지 않기 위해 복제 저널(replicated journal)이라는 새로운 분산 데이터 구조를 개발했습니다. 이 저널은 노드들을 순차적으로 연결하여 쓰기 작업이 노드를 통해 순차적으로 흐르도록 합니다. 각 노드는 값과 함께 시퀀스 번호를 학습하여 이후 읽기 작업 시 캐시를 통해 시퀀스 번호를 검색하고 일관된 상태를 제공할 수 있게 합니다.

"엔지니어들은 가용성을 희생하지 않으면서 S3 규모에서 강력한 일관성을 위해 무엇을 발명해야 할까를 고민했습니다. 우리는 복제 저널을 구축해야 했습니다."

놀랍게도 AWS는 이 강력한 일관성 기능을 추가 비용 없이 모든 S3 요청에 적용했습니다. 이는 시스템의 복잡성을 증가시키고 하드웨어 비용을 발생시켰지만, AWS는 이를 고객에게 전가하지 않기로 결정했습니다. 마이랜은 "엔지니어링에는 공짜가 없다"는 말에 동의하면서도, S3의 핵심 빌딩 블록으로서 고객이 비용 걱정 없이 사용할 수 있도록 하는 것이 중요했다고 강조했습니다.

강력한 일관성을 확보한 것만큼 중요한 것은 그것이 정확하다(correctness)는 것을 아는 것입니다. S3 규모에서는 수많은 엣지 케이스를 모두 수동으로 검증할 수 없으므로, S3는 자동화된 추론(automated reasoning), 즉 형식 검증(formal methods)을 사용합니다. 형식 검증은 컴퓨터 과학과 수학의 교차점에 있는 전문 분야로, S3는 이를 다양한 곳에 적용합니다.

• 일관성 검증: 강력한 일관성 모델이 정확하다는 것을 증명하기 위해 모든 조합을 고려한 증명(proof)을 구축하고, 인덱스 서브시스템에 코드를 체크인할 때마다 이 증명을 적용하여 일관성 모델이 퇴보하지 않았음을 확인합니다.
• 교차 리전 복제(Cross Region Replication) 검증: 한 리전에서 다른 리전으로 데이터 복제가 성공적으로 이루어졌는지 증명합니다.
• API 정확성 검증: API의 올바른 동작을 증명합니다.

"S3 규모에서는 우리가 강력한 일관성을 제공한다고 말할 수 없었습니다. 실제로 강력한 일관성을 제공한다는 것을 알지 못했기 때문입니다. 바로 그래서 우리는 자동화된 추론을 사용했습니다." "우리는 그것을 증명했습니다. 우리는 기본적으로 그것에 대한 증명을 구축했고, 우리가 이야기했던 인덱스 영역으로 체크인할 때마다 증명을 통합했습니다. 즉, 캐싱과 인덱스 기능의 스토리지 하위 계층이 있는 곳입니다."

S3에게 정확성은 내구성, 가용성, 비용만큼이나 중요한 설계 원칙입니다.

5. 대규모 시스템에서의 내구성, 가용성, 실패 관리 🛠️

S3는 11개의 9(99.999999999%)라는 경이로운 내구성(durability)을 약속합니다. 이는 1천만 개의 객체 중 1개가 1만 년에 한 번 손실될 수 있다는 의미입니다. 이러한 높은 내구성을 어떻게 검증하고 유지할까요? S3는 인덱싱 시스템 외에 스토리지 계층(storage layer)에서 내구성을 집중적으로 관리합니다.

S3는 수많은 마이크로서비스와 감사 시스템(auditor systems)을 통해 모든 바이트를 지속적으로 검사하고, 필요한 경우 수리 시스템(repair systems)이 자동으로 작동하도록 합니다. 이러한 시스템들은 분산 시스템 환경에서 느슨하게 결합되어 잘 정의된 인터페이스를 통해 통신하며 S3 리전 엔드포인트 뒤에서 함께 작동합니다. 200개가 넘는 마이크로서비스 중 상당수가 내구성 유지를 전담합니다. 이를 통해 S3는 언제든지 지난주, 지난달, 지난년도의 내구성 약속을 지켰는지 확인할 수 있습니다.

S3는 서버 장애를 일상적인 이벤트로 간주하고 설계되었습니다. 마이랜은 인터뷰 도중에도 수많은 서버가 장애를 겪고 있을 것이라고 말하며, "언제 실패할 것인가"가 아니라 "얼마나 자주 실패할 것인가"가 질문의 핵심이라고 설명했습니다.

"당신과 제가 오늘 나눈 이 대화 동안에도 서버들은 계속해서 실패하고 있습니다. 서버는 실패하기 때문입니다."

특히 중요한 것은 상관 실패(correlated failure)입니다. 이는 여러 노드가 동시에 같은 원인으로 실패하는 경우를 의미하며, 이는 시스템의 가용성을 심각하게 위협할 수 있습니다. S3는 이러한 상관 실패에 대비하기 위해 다음을 수행합니다.

• 데이터 복제: S3에 객체를 업로드하면 여러 번 복제하여 저장합니다. 이는 내구성뿐만 아니라 가용성에도 중요합니다. 가용 영역 전체가 실패하더라도 다른 곳에 데이터 사본이 남아 있어 데이터에 액세스할 수 있습니다.
• 물리적 인프라 분산: 서버, 랙, 가용 영역 등 물리적 인프라를 넓게 분산하여 단일 장애 도메인의 상관 실패를 방지합니다.

또한, S3는 크래시 일관성(crash consistency) 개념을 중요하게 생각합니다. 이는 시스템이 장애 발생 후에도 항상 일관된 상태로 복구되어야 한다는 원칙입니다. S3 엔지니어들은 시스템이 도달할 수 있는 모든 상태를 고려하고, 항상 장애의 존재를 가정하며, 일관성과 가용성을 유지하도록 마이크로서비스를 설계합니다.

S3는 실패 허용치(failure allowances)를 설정하고 관리합니다. 캐시의 실패 허용치 관리가 좋은 예시인데, S3는 캐시 크기와 하드웨어 역량을 지속적으로 모니터링하고 추적하여 고객이 장애를 경험하지 않도록 합니다. S3의 거대한 규모는 오히려 시스템에 이점으로 작용하여, "규모가 당신에게 유리하다(scale is to your advantage)"는 S3 서비스 원칙처럼, 시스템이 커질수록 워크로드가 더욱 분산되고 성능이 향상되는 효과를 가져옵니다.

6. S3의 진화와 새로운 데이터 프리미티브: S3 벡터 🧠

S3는 지속적으로 진화하는 "살아 숨 쉬는 유기체(living breathing organism)"와 같습니다. 고객의 명시적인 요구사항(로드맵의 90%)과 더불어, 고객이 데이터를 사용하는 방식을 관찰하고 미래를 예측하여 새로운 기능을 개발합니다. S3 테이블과 S3 벡터는 이러한 진화의 결과입니다.

S3 테이블은 파케이 파일과 같은 테이블 형식 데이터를 S3에 네이티브하게 저장하고 관리할 수 있게 하여, SQL과 같은 익숙한 도구로 S3 데이터를 쿼리할 수 있게 합니다.

"SQL은 데이터의 링구아 프랑카(lingua franca)이며, 전 세계 LLM은 수십 년간의 SQL을 기반으로 훈련되었습니다. 따라서 이제 S3에서 SQL을 통해 데이터와 상호작용할 수 있습니다."

S3 벡터는 S3의 최신 데이터 프리미티브로, AI 시대에 폭발적으로 증가하는 임베딩(embeddings) 데이터를 저장하고 검색하기 위해 설계되었습니다. 임베딩은 텍스트, 이미지 등 원본 데이터를 숫자의 긴 목록(벡터)으로 표현하여 데이터의 의미론적 이해를 가능하게 합니다.

• 도전 과제: 고차원 벡터 공간에서 가장 가까운 벡터(nearest neighbor)를 찾는 것은 매우 비쌉니다. 기존 벡터 데이터베이스는 모든 벡터를 비교해야 할 수 있습니다.
• S3 벡터의 해결책: S3는 벡터를 메모리가 아닌 대규모 S3 플릿에 저장하면서도 낮은 지연 시간을 제공하기 위해 벡터 이웃(vector neighborhoods)이라는 개념을 도입했습니다. 이는 유사한 벡터들을 미리 오프라인에서 비동기적으로 클러스터링하여 준비하는 방식입니다. 새로운 벡터가 삽입되면 하나 이상의 벡터 이웃에 추가됩니다.
• 성능: 쿼리 실행 시에는 더 작은 검색 공간만 탐색하고, 필요한 벡터와 벡터 이웃만 S3에서 빠른 메모리로 로드하여 100밀리초 미만의 쿼리 시간을 달성합니다.

S3 벡터는 인덱스당 최대 20억 개의 벡터, S3 벡터 버킷당 최대 20조 개의 벡터를 지원하며, 이러한 규모와 성능은 데이터에 대한 의미론적 이해를 획기적으로 확장시킬 것으로 기대됩니다.

7. 설계 원칙: 단순함과 기술적 두려움 없음 🚀

S3 엔지니어들은 "존재하는 것(what came before)을 존중하라"는 아마존의 엔지니어링 신조와 "기술적으로 두려움이 없으라(be technically fearless)"는 또 다른 신조 사이의 긴장 속에서 일합니다. 기존 S3의 내구성, 가용성, 일관성이라는 특성을 유지하면서도, 조건부 API, S3 테이블, S3 벡터와 같은 새로운 기능을 통해 스토리지의 기반을 끊임없이 확장합니다.

이러한 복잡한 시스템을 관리하는 핵심 원칙은 단순함(simplicity)입니다.

• 사용자 모델의 단순함: S3 API의 단순성, SQL을 통한 S3 데이터 접근, AI 임베딩 모델을 통한 데이터 이해의 단순함 등 사용자 관점에서 복잡성을 최소화합니다.
• 내부 구현의 단순함: 수많은 마이크로서비스가 각각 한두 가지 기능을 매우 잘 수행하도록 설계하고, 모든 엔지니어링 회의에서 "이 기능을 가능한 한 가장 단순하게 구현하는 방법은 무엇인가?"를 끊임없이 논의합니다.

마이랜은 S3 엔지니어들이 "데이터에 대한 깊은 소유감과 헌신(deep sense of ownership and commitment to your byte)"을 가지고 있으며, 이는 모든 현대 비즈니스가 데이터 비즈니스이기 때문에 데이터를 보존하고 활용 가능하게 하는 것이 그들의 책임이라고 느끼기 때문이라고 강조했습니다.

마이랜은 중견 소프트웨어 엔지니어들에게 "끊임없는 호기심(relentless curiosity)"을 가질 것을 조언했습니다. S3와 같은 대규모 분산 시스템에서 일하는 것은 정해진 선 안에서 작업하는 것이 아니라, 필요에 따라 선을 다시 그리는 것과 같기 때문입니다. 최신 연구를 탐색하고, 형식 검증이나 실패 관리에 대한 새로운 방식을 고민하는 등 엔지니어링 정신의 창의성을 발휘하는 것이 중요하다고 말했습니다.

8. 결론 💡

AWS S3는 단순한 클라우드 스토리지를 넘어, 500조 개 이상의 객체와 수백 엑사바이트의 데이터를 저장하며 끊임없이 진화하는 살아있는 시스템입니다. "규모가 당신에게 유리하다"는 원칙 아래, S3는 하드웨어부터 소프트웨어 스택 최하단까지 모든 계층에서 효율성을 극대화하여 저렴한 가격을 유지하고, 최종 일관성에서 강력한 일관성으로의 전환과 같은 엔지니어링 난제를 극복했습니다.

형식 검증(formal methods)을 통한 정확성(correctness) 보장, 상관 실패(correlated failure)와 크래시 일관성(crash consistency)을 고려한 내구성 및 가용성 설계, 그리고 S3 테이블과 S3 벡터와 같은 새로운 데이터 프리미티브 도입은 S3가 단순한 객체 스토리지를 넘어 데이터의 의미론적 이해와 활용을 가능하게 하는 혁신적인 플랫폼으로 자리매김하고 있음을 보여줍니다. 이러한 복잡성 속에서도 단순함(simplicity)을 핵심 가치로 삼고, 고객의 데이터를 보존하고 가치 있게 활용할 수 있도록 깊은 소유 의식을 가진 엔지니어들이 S3의 지속적인 발전을 이끌고 있습니다.