아마존 S3에 파일 시스템이 생겼다 - S3 Files로 달라진 것들

S3의 오래된 아킬레스건

S3를 오래 써본 사람이라면 한 번쯤 느꼈을 답답함이 있습니다. 파일처럼 보이는데, 정작 파일이 아니라는 점이죠.

S3는 저렴하고 안정적이고 API도 잘 정리되어 있습니다. 그런데 파일 시스템처럼 쓰려고 하면 벽에 부딪힙니다. 마운트도 안 되고, 파일 일부만 고치는 것도 불가능했어요. 2GB짜리 파일에서 한 줄만 바꾸려면 전체를 내려받아 수정한 뒤 다시 통째로 올려야 했습니다.

저도 예전에 로그 아카이빙 구조를 짤 때 이 지점에서 한참 고민했던 기억이 납니다. 결국 팀마다 똑같은 갈림길에 섭니다. 저렴한 S3를 쓸 것인가, 아니면 몇 배 비싸지만 그냥 마운트되는 EFS를 쓸 것인가. 객체 스토리지냐 파일 시스템이냐, 이건 거의 종교 같은 선택이었죠.

S3 Files가 바꾼 게임의 룰

아마존이 2026년에 내놓은 S3 Files는 이 딜레마를 정면으로 건드립니다. 한 줄로 요약하면 S3 가격에 파일 시스템 인터페이스를 얹은 것이죠.

구조를 보면 단순합니다. 기존 S3 위에 파일 시스템 레이어를 얇게 올린 형태예요. 데이터는 여전히 S3 객체로 사는데, 그 위에 파일처럼 보이게 하는 접근 계층이 하나 더 생긴 셈입니다. 그래서 이런 일들이 가능해졌습니다.

• NFS로 마운트 가능: EC2에서 일반 드라이브처럼 마운트
• 부분 업데이트: 파일 끝에 내용 추가하거나 중간 부분만 수정
• 이중 접근: 마운트된 파일 시스템과 S3 API로 동시 접근

기존에는 이렇게 일해야 했습니다.

# 기존 S3: 20바이트 추가하려고 1GB 전체를 다운/업로드
response = s3.get_object(Bucket=BUCKET, Key=KEY)
existing_data = response["Body"].read()
updated_data = existing_data + b"\n새 로그 한 줄"
s3.put_object(Bucket=BUCKET, Key=KEY, Body=updated_data)

이제는 이렇게 끝납니다.

# S3 Files: 일반 파일처럼
with open("/mnt/s3/logs/app.log", "a") as f:
    f.write("\n새 로그 한 줄")

코드만 보면 별것 아닌 것 같은데, 운영 관점에서 보면 차이가 큽니다. 20바이트 추가하려고 1GB를 왕복시키던 게 사라지면, 그만큼 네트워크 비용도 줄고 실패 지점도 줄어드니까요.

실제로 어디에 쓸까

이론은 좋습니다. 문제는 실제로 어떤 자리에 끼워 넣을 수 있느냐죠. 머릿속에서 바로 그려지는 케이스 몇 개를 정리해봤습니다.

로그 수집 파이프라인
서비스에서 로그를 S3 Files에 직접 append로 쌓고, 분석 도구는 S3 API로 읽어가는 구조. 별도 로그 포워더나 EFS 없이도 흐름이 깔끔하게 떨어집니다. 로그 적재는 결국 "끝에 계속 붙이는" 작업인데, append가 가능해졌다는 건 이 워크로드와 궁합이 좋다는 뜻이죠.

머신러닝 데이터셋
학습 데이터를 S3 Files에 두고, 새 샘플이 들어올 때마다 파일에 추가합니다. 학습 작업은 익숙한 S3 SDK로 그대로 읽어가면 되고요. 데이터를 한 곳에 두면서 적재 경로와 읽기 경로를 분리할 수 있다는 게 핵심입니다.

레거시 앱 마이그레이션
개인적으로는 이게 제일 현실적인 용도라고 봅니다. 파일 시스템을 당연히 전제하고 만들어진 오래된 애플리케이션을, 코드를 거의 손대지 않고 클라우드로 옮기는 거죠. "파일 경로"를 가정하는 코드는 생각보다 깊숙이 박혀 있어서, 그걸 S3 API 호출로 다 바꾸는 작업이 마이그레이션의 발목을 잡는 경우가 많거든요. 그 단계를 통째로 건너뛸 수 있다면 의미가 작지 않습니다.

여전히 주의할 점들

물론 만능은 아닙니다. 새 도구가 나오면 "이걸로 다 되겠네" 하고 덤비기 쉬운데, 한계는 분명합니다.

항목	S3 Files	EBS	EFS
지연시간	높음	낮음	중간
가격	낮음	중간	높음
POSIX 호환	부분적	완전	완전
동시 마운트	가능	불가	가능

지연시간에 민감한 워크로드는 여전히 EBS가 답입니다. 데이터베이스나 실시간 트랜잭션처럼 한 번의 I/O가 응답 시간을 좌우하는 경우죠. 밑단이 결국 객체 스토리지라는 사실은 변하지 않습니다. 파일처럼 보인다고 해서 블록 스토리지의 응답 속도까지 따라오는 건 아니에요.

멀티 라이터 시나리오도 조심해야 합니다. 여러 인스턴스가 동시에 같은 파일을 수정하면 일관성이 깨질 수 있어요. S3의 강한 일관성은 개별 객체 작업 단위에 적용되는 거지, "여러 주체가 같은 파일을 동시에 append하는" 상황까지 보장해주지는 않거든요. 이 부분을 EFS의 파일 락처럼 기대하고 설계하면 나중에 디버깅하기 까다로운 데이터 꼬임을 만나게 됩니다.

POSIX 호환이 "부분적"이라는 표도 가볍게 넘기면 안 됩니다. 기존 앱을 옮길 때 "마운트는 되는데 특정 시스템 콜에서 막힌다"는 식의 문제는 보통 막판에 터지거든요.

비용 계산이 바뀐다

개인적으로 가장 흥미로운 부분은 비용 모델이 바뀐다는 점입니다.

기존 의사결정은 단순했어요. "파일 시스템이 필요하면 EFS 쓰자. 비싸지만 어쩔 수 없지." 선택지가 둘뿐이니 고민할 것도 별로 없었습니다. 이제는 그 앞에 한 단계가 더 생깁니다. "S3 Files로 충분한지 먼저 따져보자."

특히 로그나 백업, 아카이브처럼 "쓰는 빈도는 높지만 지연시간엔 둔감한" 워크로드에서 차이가 크게 벌어집니다. 이런 데이터를 그동안 EFS에 올려두고 있었다면, 사실 비싼 자리에 굳이 비싼 값을 치르고 있던 셈이거든요. TB 단위 데이터를 다루는 팀이라면 월 단위로 적지 않은 차이가 날 여지가 있습니다.

비용은 결국 아키텍처 결정의 누적이라, 이런 선택지 하나가 추가되는 게 장기적으로는 꽤 큰 변수입니다.

조용하지만 중요한 변화

S3 Files는 화려한 신기술은 아닙니다. 냉정하게 보면 기존 기술 두 개를 잘 붙여놓은 것뿐이죠. 새로운 패러다임도, 거창한 아키텍처 혁신도 아닙니다.

그런데 이런 "당연해 보이는" 개선이 실무에서는 오히려 임팩트가 큽니다. 아키텍처를 설계할 때 늘 따라붙던 제약 하나가 사라진 거니까요. 스토리지 선택지가 늘어난다는 건, 그만큼 최적화할 여지가 넓어진다는 뜻입니다. 컨설팅 자리에서 보면, 의사결정을 옥죄던 트레이드오프가 하나 풀릴 때 설계 전체가 훨씬 유연해지는 경우를 자주 봤습니다.

내년 이맘때쯤 EFS 사용량이 얼마나 줄어 있을지, 그게 진짜 궁금합니다.