# S3 Files와 변화하는 S3의 모습 > Clean Markdown view of GeekNews topic #28305. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28305](https://news.hada.io/topic?id=28305) - GeekNews Markdown: [https://news.hada.io/topic/28305.md](https://news.hada.io/topic/28305.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-08T10:30:01+09:00 - Updated: 2026-04-08T10:30:01+09:00 - Original source: [allthingsdistributed.com](https://www.allthingsdistributed.com/2026/04/s3-files-and-the-changing-face-of-s3.html) - Points: 11 - Comments: 4 ## Summary AWS CTO **Werner Vogels**가 직접 소개한 **S3 Files**입니다. S3 버킷을 **NFS로 마운트**해서 EC2, 컨테이너, Lambda에서 파일 시스템처럼 읽고 쓸 수 있게 해줍니다. 내부적으로 stage-commit 구조로 변경을 S3에 반영하고, 파일과 객체 간 양방향 동기화를 지원합니다. S3 Tables(구조화 데이터), S3 Vectors(벡터 검색)와 함께 S3가 단순 저장소에서 **통합 데이터 플랫폼**으로 확장되고 있는 흐름인데요. 현대적 클라우드 인프라의 출발점이었던 S3가 20년 만에 다시 정의되는 느낌이네요. ## Topic Body - 대규모 데이터 이동의 비효율을 줄이기 위해, **S3 데이터를 파일 시스템처럼 직접 접근**할 수 있게 하는 **S3 Files**가 도입됨 - 이 기능은 **Amazon EFS와 S3를 통합**하여 EC2, 컨테이너, Lambda 등에서 **S3 버킷을 NFS로 마운트**해 읽기·쓰기 가능하게 함 - 내부적으로 **stage와 commit 구조**를 사용해 변경을 주기적으로 S3에 반영하며, **파일과 객체 간 양방향 동기화**를 지원 - S3 Files는 **S3 Tables, S3 Vectors**와 함께 S3를 **통합 데이터 플랫폼**으로 확장시키는 핵심 구성요소로 작동 - S3는 이제 단순 저장소를 넘어, **데이터 중심의 통합 작업 공간**으로 진화하며 개발자가 데이터를 직접 활용할 수 있는 기반을 제공함 --- ### S3의 변화와 S3 Files의 설계 - ## 데이터 이동의 어려움과 S3 Files의 출발점 - 대규모 데이터를 옮기는 과정은 과학 연구부터 머신러닝까지 다양한 산업에서 **지속적인 비효율의 원인**으로 존재 - UBC의 유전체 연구 사례에서는 연구자들이 **S3와 로컬 파일 시스템 간 복사 작업**에 많은 시간을 소비 - 이러한 **데이터 마찰(data friction)** 은 도구들이 서로 다른 방식으로 데이터를 접근하기 때문에 발생 - S3 Files는 이러한 마찰을 줄이기 위해 **S3 데이터를 직접 파일 시스템처럼 접근**할 수 있도록 설계됨 - ## 에이전트 기반 개발과 데이터의 중요성 - **에이전트형 도구(agentic tooling)** 의 발전으로 애플리케이션 개발 속도와 다양성이 급격히 증가 - 코드 작성의 장벽이 낮아지면서, **도메인 전문가들이 직접 애플리케이션을 구축**할 수 있는 환경이 형성 - 애플리케이션의 수명은 짧아지고, **데이터가 장기적으로 남는 핵심 자산**으로 부상 - 스토리지는 단순 저장소가 아니라, **데이터를 애플리케이션과 분리해 지속적으로 활용할 수 있게 하는 추상화 계층**이 되어야 함 ### S3의 새로운 데이터 프리미티브 - ## S3 Tables - S3는 **구조화된 데이터**를 다루기 위해 Apache Iceberg 기반의 **S3 Tables**를 도입 - Iceberg의 기능을 유지하면서 **데이터 무결성 보호, 자동 압축(compaction), 교차 리전 복제** 등을 제공 - 현재 **200만 개 이상의 테이블**이 S3 Tables에 저장되어 있으며, 다양한 애플리케이션이 이를 기반으로 구축됨 - ## S3 Vectors - AI 발전으로 **벡터 인덱스**에 대한 수요가 증가 - 기존 벡터 데이터베이스는 메모리나 SSD에 인덱스를 저장하지만, 이는 **비용과 확장성의 한계**를 가짐 - **S3 Vectors**는 S3 객체와 유사한 **비용·성능·내구성 프로파일**을 가진 완전 탄력적 벡터 인덱스 제공 - 수백 개에서 수십억 개의 레코드까지 확장 가능하며, **유사도 검색(scalar similarity search)** 을 위한 API 엔드포인트 제공 ### S3 Files의 등장 - ## 개요 - **S3 Files**는 Amazon EFS를 S3에 통합하여, **S3 데이터를 네트워크 파일 시스템(NFS)처럼 직접 접근** 가능하게 함 - EC2, 컨테이너, Lambda 등에서 **S3 버킷 또는 프리픽스를 마운트**하여 파일처럼 읽고 쓸 수 있음 - 변경 사항은 자동으로 S3에 반영되어, **파일과 객체 간의 양방향 동기화** 지원 - ## 설계의 난제 - 파일 시스템과 객체 스토리지는 **근본적으로 다른 데이터 모델**을 가짐 - 초기에는 EFS와 S3를 단순히 결합하려 했으나, **“불쾌한 절충(unpalatable compromises)”** 만 남음 - 파일은 **세밀한 변경과 동시 접근**을 지원하지만, 객체는 **불변성과 전체 단위 업데이트**를 전제로 함 - S3의 **이벤트 알림 시스템**은 하루 3천억 건 이상의 알림을 처리하며, 객체 단위의 변경을 기반으로 작동 ### Stage and Commit 설계 원리 - ## 경계를 기능으로 전환 - 파일과 객체의 차이를 숨기지 않고, **명시적 경계로 설계** - 변경은 EFS에서 **stage(임시 저장)** 되고, 일정 주기마다 **commit(커밋)** 되어 S3에 반영 - 이 접근은 Git의 버전 관리 개념에서 영감을 받아, **시간·정책 기반의 데이터 전송 제어**를 가능하게 함 - ## 일관성과 원자성 - 파일 시스템의 **원자적(rename, move) 연산**과 S3의 **전체 객체 단위 업데이트**를 병행 지원 - 두 계층을 분리함으로써 각 시스템의 일관성 모델을 유지하면서 **단일 데이터 뷰** 제공 - ## 권한 관리 - S3의 **IAM 정책**과 파일 시스템의 **inode 기반 권한**은 구조적으로 다름 - S3 Files는 **마운트 단위 권한 부여**를 통해 두 체계를 분리 - S3 IAM 정책은 **최종 백스톱(backstop)** 으로 유지되어, 데이터 경계 변경 시 접근 제어 가능 - ## 네임스페이스 불일치 - S3는 디렉터리 개념이 없고, **경로 구분자(delimiter)** 도 임의 지정 가능 - 파일 시스템과의 불일치를 해결하기 위해 **양쪽의 네이밍 규칙을 그대로 유지** - 호환 불가능한 객체는 이동하지 않고, **이벤트를 발생시켜 개발자가 처리**할 수 있도록 설계 - ## 성능과 지연(latency) - 파일 시스템은 **메타데이터 중심 접근**, S3는 **대규모 병렬 접근**에 최적화 - 대부분의 워크로드는 파일과 객체를 **동시에 접근하지 않기 때문에**, 두 모델의 통합보다는 **동기화 계층 유지**가 현실적 - 파일 뷰는 **NFS 일관성**, 객체 뷰는 **S3 강한 일관성**을 유지하며, **동기화 계층이 연결 역할** 수행 ### S3 Files의 동작 방식 - ## 기본 구조 - S3 Files는 **EFS를 백엔드로 사용**하여 파일 시스템 경험 제공 - 디렉터리 접근 시 S3 메타데이터를 가져와 **동기화된 뷰 생성**, 128KB 이하 파일은 즉시 데이터도 로드 - 대용량 파일은 **지연 로딩(lazy hydration)** 으로 필요 시 데이터 가져오기 - 변경 사항은 약 **60초마다 S3에 단일 PUT으로 커밋**, 양방향 동기화 수행 - ## 충돌 및 관리 - 양쪽에서 동시에 수정 시 **S3가 진실의 원천(source of truth)** 으로 간주 - 충돌된 파일은 **lost+found 디렉터리**로 이동하고, **CloudWatch 메트릭**으로 기록 - 30일간 접근되지 않은 파일은 **파일 시스템 뷰에서 제거**되어 비용 최적화 - ## 성능 최적화 - ### read bypass**기능을 통해 대용량 순차 읽기 시**병렬 GET 요청으로 직접 S3에서 읽기 - 클라이언트당 3GB/s 처리량 달성, 다중 클라이언트에서는 **테라비트급 확장성** 확보 - ## 한계와 개선 예정 - S3는 **네이티브 rename 연산이 없어**, 디렉터리 이름 변경 시 전체 복사·삭제 필요 - 5천만 개 이상의 객체를 포함한 마운트는 경고 표시 - **명시적 커밋 제어**는 초기 버전에 포함되지 않음 - 일부 객체 키는 **POSIX 파일명으로 표현 불가**, 파일 뷰에서 제외됨 ### 데이터 다양성과 S3의 진화 - ## 데이터 접근 방식의 공존 - UBC 연구 사례처럼, 개발자들은 **데이터 이동·캐싱·이름 관리**에 많은 시간을 소비 - S3 팀은 Tables, Vectors, Files를 통해 **다양한 데이터 접근 방식을 통합 지원** - 파일과 객체의 차이를 없애려 하기보다, **각자의 특성을 인정하고 경계를 기능화** - ## S3의 확장된 역할 - S3는 단순 객체 저장소에서 **다양한 데이터 형태를 지원하는 통합 스토리지 플랫폼**으로 진화 - Tables, Vectors, Files를 통해 **데이터를 작업 방식에 맞게 직접 활용** 가능 - 목표는 스토리지가 **작업의 방해물이 아닌, 투명한 기반 인프라**가 되는 것 - 향후 **stage/commit 제어, 파이프라인 통합** 등 기능 확장을 지속 예정 - ## 결론 - S3 Files는 **파일과 객체의 명시적 경계**를 유지하면서도 양쪽의 장점을 결합 - 20년 전 객체 저장소로 시작한 S3는 이제 **데이터 중심의 통합 작업 공간**으로 발전 - “이제, 만들어 보라(Go build!)”는 메시지처럼, **S3는 개발자가 데이터로 더 빠르게 실험하고 구축할 수 있는 기반**으로 자리함 ## Comments ### Comment 54900 - Author: xguru - Created: 2026-04-08T10:41:55+09:00 - Points: 5 아 이제는 함께 보면 좋은 글이 관련 공식 글을 잘 연결해주니 편하네요. 이렇게 소개 글과 공식글이 따로 있는 경우 어떻게 해줘야 하나 항상 고민했는데, 함께 보면 좋은 글이 잘 동작해서 기분이 좋습니다.. ㅎㅎ 이제 S3는 파일·테이블·벡터를 모두 포함한 데이터 플랫폼으로 확장하네요. 현대적 클라우드 인프라의 출발점이었던 S3가 20년 만에 다시 정의되는 느낌 ### Comment 55197 - Author: rtyu1120 - Created: 2026-04-13T14:21:00+09:00 - Points: 2 S3와 transparent하게 파일 구조가 공유되지는 않지만, ZeroFS라고 하는 S3를 데이터베이스 삼아 POSIX-compliant한 파일시스템을 굴리는 오픈 소스도 존재합니다. S3 위에서 PostgreSQL을 굴리는 데모로 꽤 인기있었죠. https://www.zerofs.net/ ### Comment 55196 - Author: rtyu1120 - Created: 2026-04-13T14:18:09+09:00 - Points: 1 이전 S3 엔지니어가 창업한 Archil에서 자사 제품과 비교한 글도 있어서 같이 보면 재미있습니다 ㅎㅎ https://x.com/jhleath/status/2042613823522377933 ### Comment 54896 - Author: neo - Created: 2026-04-08T10:30:01+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47680404) - 이건 사실상 **S3FS**를 쓰되, **EFS**(AWS의 관리형 NFS 서비스)를 활성 데이터와 작은 랜덤 접근을 위한 캐시 계층으로 사용하는 구조임 문제는 EFS의 **비싼 요금 체계**가 그대로 따라온다는 점임 — 모든 쓰기 작업은 GB당 $0.06로, 쓰기 중심 워크로드에는 치명적일 수 있음 — 캐시에서 읽는 경우 GB당 $0.03이 부과되며, 128KB 초과의 큰 읽기는 S3 버킷에서 직접 스트리밍되어 무료임 — 캐시는 GB당 월 $0.30이지만, 주로 128KB 이하의 작은 파일만 지속 저장하므로 비용은 크지 않을 듯함 - 큰 파일 읽기(>128KB)가 항상 캐시를 거치지 않는다는 게 맞는지 궁금함 **S3의 지연 시간(latency)** 이 꽤 나쁜 편이라 걱정됨 - “NFS provides the semantics your applications expect”라는 문구는 지금까지 본 것 중 가장 웃겼음 - 애플리케이션이 네트워크 끊김 하나로 **시스템 콜이 무한 대기** 상태에 빠지고, 파일시스템이 언마운트 불가 상태가 되는 걸 기대하지는 않음 - **Hugging Face Buckets**도 최근에 버킷을 파일시스템처럼 마운트할 수 있는 기능을 추가했음 [hf-mount 변경 로그](https://huggingface.co/changelog/hf-mount) - 동기화 관련 부분이 궁금했음 [AWS 문서](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-fil...)에 따르면, `/mnt/s3files/report.csv`를 수정한 뒤 S3 버킷에 다른 버전이 업로드되면, 충돌 시 내 버전은 `.s3files-lost+found-file-system-id` 디렉터리로 이동되고 버킷 버전으로 교체된다고 함 즉, **충돌 시 자동 복구 디렉터리**가 존재함 - [FiberFS](https://fiberfs.io/)가 거의 첫 공식 릴리스 단계에 있음 **내장 캐시**, CDN 호환, JSON 메타데이터, 동시성 안전성을 갖추고 모든 S3 호환 스토리지를 대상으로 함 - Amazon의 자체 **FUSE 구현체**와 비교하면 어떤지 궁금함. 지금 세 번째 버전까지 나왔음 - AWS가 로컬 **NVMe 스토리지**와의 관리형 브리징을 제공했으면 좋겠음 NVMe는 EBS보다 훨씬 빠르고, EBS는 EFS보다 빠름 NVMe 위에 캐시 계층을 올리면 속도가 꽤 나올 듯하지만, 완전 통합형 옵션이 더 이상적임 - EFS가 단순 NFS 마운트라면, NVMe 볼륨을 붙이고 **cachefilesd**를 설정해서 직접 구현할 수도 있을 듯함 예를 들어 ```bash mkfs.ext4 /dev/nvme0n1 && \ mount /dev/nvme0n1 /var/cache/fscache && \ mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files ``` 이런 식으로 하면 바로 동작할지도 모름 사실상 세 줄짜리 명령어인데, 이걸 **관리형 서비스**로 내놓는 게 AWS다운 행보임 - AWS가 예전엔 S3를 파일시스템으로 쓰지 말라고 했던 걸로 아는데, 왜 이제 와서 바뀐 건지 궁금함 - 이번엔 S3 앞단에 실제 파일시스템(EFS)을 두고 **투명 동기화**를 수행하는 구조로 보임 블로그에서도 **일관성 문제**나 **객체 이름 처리** 같은 주의점을 언급함 S3 팬으로서 이런 설계는 꽤 괜찮은 절충안이라 생각함 - 대형 고객사 아키텍트들이 오래전부터 S3를 파일시스템처럼 써왔음 AWS가 받은 **지원 티켓 압박**과 “왜 안 되냐”는 요구가 누적되어 결국 이런 방향으로 간 듯함 개인적으로는 “본질적으로 다른 걸 포장만 새로 한” 접근이라 마음에 들진 않지만, **$$$의 사회적 압력**이 작용한 사례 같음 - 이건 기술력이 낮은 사용자층까지 끌어들이려는 전략으로 보임 “S3asYourFS.exe” 같은 툴을 쓰는 사람들도 AWS 고객으로 만들 수 있으니까 다만 AWS의 **고객 지원 역량**을 생각하면 이게 현명한 결정인지는 의문임 그래도 매달 요금 내는 사용자가 늘어난다는 유혹은 컸을 것임 - 어차피 사람들은 S3를 파일시스템처럼 쓸 거라면, 차라리 **공식적으로 지원**하는 게 낫다고 봄 - 결국 AWS는 캐시를 앞단에 두고 **수익 모델**을 만든 것임 사용자 입장에선 성능이 좋아지고, AWS는 부하가 줄어듦 돈을 아낄 수도, 아닐 수도 있음 - 이걸로 **SQLite 데이터베이스**를 저장하면 어떻게 될지 궁금함 아마 읽기 전용 복제본 정도만 가능하고, **Litestream**처럼 백업은 안 될 듯함 - SQLite의 **락(lock) 메커니즘**은 NFS에서 안전하지 않아서 작동하지 않음 - NFS의 **락킹 동작**도 이미 복잡한데, 여기에 원격 S3 백엔드를 섞으면 더 혼란스러워질 것 같음 - **Werner Vogels**는 정말 대단한 사람임 예전에 **DynamoDB**를 공부하면서 그의 글을 처음 접했는데, 그때부터 팬이었음