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

S3의 오래된 아킬레스건

객체 스토리지를 써본 사람이라면 누구나 느꼈을 답답함이 하나 있습니다. 파일처럼 보이지만 파일이 아니라는 점이죠.

S3는 저렴하고 안정적이며 API도 잘 되어 있지만, 정작 파일 시스템처럼 쓸 수는 없었습니다. 마운트도 안 되고, 파일 일부만 수정하는 것도 불가능했죠. 2GB 파일에서 한 줄만 바꾸려면 전체를 다운받아서 수정하고 다시 올려야 했습니다.

그래서 팀마다 고민이 똑같았어요. 저렴한 S3를 쓸 것인가, 아니면 5배 비싸지만 마운트되는 EFS를 쓸 것인가.

S3 Files가 바꾼 게임의 룰

아마존이 2026년에 내놓은 S3 Files는 이 딜레마를 정면으로 해결합니다. 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새 로그 한 줄")

실제로 어디에 쓸까

이론적으로는 좋은데, 실제로는 어떤 상황에서 유용할까요? 몇 가지 케이스를 정리해봤습니다.

로그 수집 파이프라인
서비스에서 로그를 직접 S3 Files에 append로 쌓고, 분석 도구는 S3 API로 읽어가는 구조. 별도 로그 포워더나 EFS 없이도 깔끔하게 처리됩니다.

머신러닝 데이터셋
학습 데이터를 S3 Files에 두고 새 샘플이 들어올 때마다 파일에 추가. 학습 작업은 익숙한 S3 SDK로 데이터를 읽어가면 됩니다.

레거시 앱 마이그레이션
파일 시스템을 가정하고 만들어진 기존 애플리케이션을 코드 수정 없이 클라우드로 옮기는 용도.

여전히 주의할 점들

물론 만능은 아닙니다. 몇 가지 한계는 분명해요.

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

지연시간에 민감한 워크로드는 여전히 EBS가 맞습니다. 데이터베이스나 실시간 트랜잭션 처리 같은 경우죠.

멀티 라이터 시나리오도 조심해야 합니다. 여러 인스턴스가 동시에 같은 파일을 수정하면 일관성 문제가 생길 수 있어요. S3의 강한 일관성은 개별 작업에만 적용되거든요.

비용 계산이 바뀐다

개인적으로 가장 흥미로운 부분은 비용 모델의 변화입니다.

기존에는 "파일 시스템이 필요하면 EFS 쓰자. 비싸지만 어쩔 수 없지"였다면, 이제는 "S3 Files로 충분한지 먼저 검토해보자"가 됩니다.

특히 로그나 백업, 아카이브 성격의 워크로드에서는 상당한 비용 절감이 예상됩니다. TB 단위 데이터를 다루는 팀이라면 월 단위로 수백 달러 차이가 날 수도 있어요.

조용하지만 중요한 변화

S3 Files는 화려한 신기술은 아닙니다. 그냥 기존 기술 두 개를 잘 붙여놓은 것뿐이죠.

하지만 이런 "당연한" 개선이 실무에서는 더 임팩트가 큽니다. 아키텍처 설계할 때 하나의 제약이 사라진 거니까요. 스토리지 선택지가 늘어난다는 건 그만큼 최적화 여지가 많아진다는 뜻입니다.

내년 이맘때쯤 EFS 사용량이 얼마나 줄어들지 궁금하네요.