2026년 4월 7일 Werner Vogels는 AWS의 새 storage 기능인 S3 Files를 소개하며, S3가 object API를 넘어 file system 접근까지 흡수하는 방향으로 진화하고 있다고 설명했다. 글은 기능 발표 자체보다 왜 이런 계층이 필요한지에 더 많은 지면을 쓴다. 출발점은 genomics 연구실이었다. 대규모 sequencing data를 다루는 연구자들이 분석보다 복사, 동기화, 중복본 관리에 더 많은 시간을 쓰는 장면이 반복됐고, 그 경험이 storage boundary 문제를 다시 보게 만들었다는 이야기다.

핵심 문제는 data friction이다. S3는 durability, scale, cost 측면에서 강하지만, 많은 분석 도구와 training pipeline은 여전히 local Linux file system을 전제로 한다. 그래서 object store에 있는 데이터를 작업 직전에 다시 복사하고, 처리 후 다시 올리고, 여러 inconsistent copy를 만드는 흐름이 생긴다. 글은 이 마찰이 genomics뿐 아니라 media, semiconductor, scientific computing, machine learning pretraining까지 폭넓게 반복된다고 짚는다.

AWS는 이미 S3 Tables와 S3 Vectors를 통해 object보다 높은 수준의 data primitive를 만들기 시작했다. S3 Files는 그 연장선에 있다. Vogels의 설명에 따르면 이제 EC2 VM, container, Lambda function 안에서 S3 bucket이나 prefix를 mount해 file처럼 다루고, 변경 사항을 다시 S3에 반영할 수 있다. pandas, Unix toolchain, training job, design tool, agentic workflow가 object storage를 쓰기 위해 별도 복사 파이프라인을 만들지 않아도 되는 방향을 노린 셈이다.

흥미로운 점은 AWS가 이 기능을 단순 편의 기능으로 포장하지 않는다는 점이다. 글은 file semantics와 object semantics를 억지로 합치려 할 때 어떤 쪽도 손해를 보지 않게 만드는 일이 얼마나 어려운지 길게 설명한다. 실제로 EFS와 S3 팀이 함께 설계를 밀어붙였지만, 수많은 trade-off와 “unpalatable compromises”를 거쳐야 했다고 털어놓는다. 그래서 S3 Files의 의미는 단순한 mount 기능보다, storage abstraction을 어디까지 끌어올릴 수 있는지에 대한 AWS의 방향 선언에 가깝다.

Hacker News가 이 글을 주목하는 이유도 여기에 있다. agent가 코드를 더 빨리 만들수록, 애플리케이션은 더 짧은 주기로 생기고 사라지지만 data는 남는다. 이런 환경에서는 compute보다 data attachment cost를 낮추는 storage layer가 훨씬 중요해진다. S3 Files가 실제로 얼마나 매끄러운 semantics와 performance를 제공할지는 더 지켜봐야 하지만, 적어도 object storage와 file system 사이의 오랜 복사 노동을 줄이려는 시도라는 점은 분명하다.

#s3

Hacker News가 주목한 S3 Files, object storage와 file system의 마찰을 줄이다