오브젝트 스토리지 입문: S3 호환 API·수명주기·비용 구조
🤖 AI Summary
오브젝트 스토리지는 우리가 익숙한 파일 폴더와 다릅니다. 하위 폴더 계층이 없는 평면 구조로, 데이터를 객체(데이터 + 메타데이터)로 만들어 버킷에 담고 키 하나로 식별하며 HTTP API로 다룹니다. 폴더처럼 보이는 것은 키 이름의 프리픽스일 뿐이죠. 많은 서비스가 S3 호환 API를 제공해 같은 방식으로 접근할 수 있지만, 호환이 100% 동일을 뜻하지는 않습니다. 비용을 따질 때 핵심은 두 가지입니다. 자주 안 쓰는 데이터는 저렴한 스토리지 클래스로 내리되 꺼낼 때 검색 비용이 든다는 것, 그리고 비용은 저장 용량만이 아니라 요청 수와 데이터 전송(egress)까지 세 축이라는 것입니다. 이 글은 그 구조를 1차 출처로 정리합니다.
블로그 목차
폴더가 아니라 버킷·객체·키입니다
오브젝트 스토리지를 처음 보면 파일 서버처럼 폴더가 있을 것 같지만, 구조가 다릅니다. AWS S3 공식 문서는 데이터 모델이 평면(flat) 구조이며 하위 폴더 계층이 존재하지 않는다고 분명히 적습니다. 데이터는 객체로 저장되는데, 객체는 파일 그 자체와 그것을 설명하는 메타데이터로 이루어집니다.
객체는 버킷이라는 통에 담기고, 버킷 안에서 키(key) 하나로 고유하게 식별됩니다. 즉 "버킷 + 키"가 객체의 주소인 셈이죠. 그럼 콘솔에서 보이는 폴더는 무엇일까요. 그건 키 이름에 Development/Projects.xls처럼 프리픽스와 구분자(/)를 넣어 계층처럼 보이게 한 가상 표현입니다. 콘솔이 폴더를 만들 때는 그 프리픽스를 키로 갖는 0바이트 객체를 하나 만들 뿐입니다.
이 차이가 중요한 이유는, 접근 방식이 파일시스템이 아니라 HTTP API이기 때문입니다. 객체를 통째로 올리고 내려받는 모델이라, 파일 일부만 고치거나 이어 쓰는 작업은 기본 동작이 아닙니다. 업로드한 객체의 사용자 메타데이터조차 바꾸려면 객체를 다시 복사해야 합니다.
S3 호환 API: 왜 S3가 기준선인가
오브젝트 스토리지를 이야기할 때 S3 호환 API라는 말이 자주 나옵니다. Amazon S3가 HTTP 기반 REST API로 객체를 다루는데, 많은 오브젝트 스토리지가 이 S3 API와 호환되는 인터페이스를 제공해, 기존에 S3용으로 만든 애플리케이션을 설정만 바꿔 그대로 쓸 수 있게 합니다.
예를 들어 NHN Cloud Object Storage는 S3 호환 API를 제공한다고 공식 문서에 명시하며, 사용하려면 EC2 형태의 S3 자격 증명을 발급받아야 합니다. 컨테이너(네임스페이스)와 객체를 HTTP REST API로 다루는 구조죠. MinIO 같은 솔루션도 S3 호환을 표방합니다.
다만 "S3 호환"이 100% 동일을 보장하지는 않습니다. 공급자마다 지원하는 기능 범위가 달라, 기본 동작은 같아도 고급 기능은 부분 호환일 수 있습니다. 그래서 우리가 쓰려는 특정 기능이 그 서비스에서도 실제로 지원되는지는 따로 확인하는 편이 안전합니다.
스토리지 클래스: 안 쓰는 데이터는 더 저렴하게
모든 데이터를 똑같은 곳에 둘 필요는 없습니다. 접근 빈도가 다르기 때문이죠. S3는 용도별로 여러 스토리지 클래스를 제공합니다. 자주 쓰는 데이터는 표준 클래스(Standard)에, 가끔 쓰는 데이터는 Infrequent Access(IA)에, 거의 안 보는 보관용은 Glacier 계열 아카이브에 두는 식입니다.
핵심은 저장이 저렴해질수록 꺼낼 때 대가가 따른다는 점입니다.
그래서 클래스를 고를 때는 저장 단가만 보면 안 됩니다. 얼마나 자주, 얼마나 빨리 꺼내야 하는 데이터인지를 함께 따져야 합니다. 자주 꺼내는 데이터를 아카이브에 넣으면, 저장은 아꼈는데 검색 비용과 지연으로 오히려 손해를 볼 수 있습니다.
수명주기 정책: 전환과 만료를 자동으로
데이터의 가치는 시간이 지나면 보통 떨어집니다. 처음엔 자주 보다가 점점 안 보게 되죠. 이걸 사람이 일일이 옮기는 대신 자동화하는 것이 수명주기(Lifecycle) 정책입니다.
S3 수명주기 규칙은 두 가지 동작으로 이루어집니다.
전환(Transition): 객체를 일정 시점에 더 저렴한 클래스로 옮깁니다. 예를 들어 생성 30일 후 Standard-IA로, 1년 후 Glacier 계열로 내리는 식입니다.만료(Expiration): 일정 기간이 지난 객체를 자동으로 삭제합니다. 로그나 임시 파일처럼 보관 기한이 정해진 데이터에 유용합니다.
이 규칙은 기존 객체와 이후 추가되는 객체 모두에 적용되므로, 한 번 설계해 두면 운영이 한결 단순해집니다. NHN Cloud Object Storage도 컨테이너나 개별 객체 단위로 수명 주기 제어 기능을 제공합니다. 다만 전환 요청 자체에 요청 비용이 따를 수 있으니, 규칙은 자주 바뀌지 않게 설계하는 편이 좋습니다.
진짜 비용은 세 축입니다
오브젝트 스토리지 비용을 "GB당 얼마"로만 비교하면 청구서와 어긋나기 쉽습니다. 과금은 보통 세 축으로 이루어지기 때문입니다.
특히 세 번째 축인 데이터 전송(egress)이 자주 간과됩니다. 저장은 저렴해도, 데이터를 자주 밖으로 내보내는 서비스라면 전송 비용이 전체를 좌우할 수 있습니다. 그래서 도입 전에는 "이 데이터를 얼마나 보관하고, 얼마나 자주 호출하며, 얼마나 밖으로 내보내는가"를 함께 추정해야 실제 비용에 가까워집니다.
참고로 데이터 안전성과 관련해, AWS는 대부분의 클래스에 대해 99.999999999%(이른바 11 9s)의 내구성을 "설계 목표(designed for)"로 표기합니다. 이는 보장된 실측치가 아니라 설계 기준 표기이며, 내구성과 가용성은 다른 개념입니다. 가용성 수치는 클래스마다 다릅니다. 한편 S3는 2020년 12월부터 모든 리전에서 강한 read-after-write 일관성을 제공해, 쓰고 나서 곧바로 읽어도 최신 데이터가 보입니다.
이것만 기억하세요
오브젝트 스토리지는 폴더 없는 평면 구조로, 객체를 버킷에 키로 저장하고 HTTP API로 다룹니다(폴더는 가상 프리픽스). 도입 전 꼭 따질 것은 두 가지입니다. 자주 안 쓰는 데이터는 저렴한 클래스로 내리되 꺼낼 때 검색 비용이 든다는 것, 그리고 비용은 저장 용량만이 아니라 요청 수와 데이터 전송(egress)까지 세 축이라는 것입니다.
자주 묻는 질문 (FAQ)
Q. 오브젝트 스토리지에는 폴더가 없나요?
구조상으로는 없어요. AWS S3 공식 문서는 데이터 모델이 평면(flat) 구조이며 하위 폴더 계층이 없다고 명시합니다. 콘솔에서 폴더처럼 보이는 건 키 이름의 프리픽스와 구분자(/)로 만든 가상 표현이고, 콘솔이 폴더를 만들 때는 프리픽스를 키로 갖는 0바이트 객체를 만들어요. 객체는 버킷 안에서 키 하나로 식별됩니다.
Q. S3 호환 API라면 AWS와 똑같이 동작하나요?
완전히 같다고 보장되진 않아요. 많은 오브젝트 스토리지가 S3 호환 API를 제공해 기존 S3용 애플리케이션을 설정 변경만으로 쓸 수 있게 합니다. 예를 들어 NHN Cloud Object Storage는 S3 호환 API를 제공하고 EC2 형태의 자격 증명을 발급받아 씁니다. 다만 공급자마다 지원 범위가 달라 고급 기능은 부분 호환일 수 있으니, 쓰려는 기능이 실제 지원되는지 확인하는 게 안전해요.
Q. 스토리지 클래스는 왜 나누나요?
데이터마다 접근 빈도가 다르기 때문이에요. 자주 쓰는 데이터는 표준 클래스에, 가끔 쓰거나 보관용은 더 저렴한 클래스(IA, Glacier 계열)에 둡니다. 단 저장이 싼 클래스는 꺼낼 때 검색 비용이 들고, 아카이브 계열은 복원에 분에서 시간 단위가 걸려요. 또 클래스마다 최소 저장 기간이 있어 너무 빨리 지우면 손해일 수 있습니다.
Q. 수명주기 정책은 무엇을 자동화하나요?
객체를 시간에 따라 다른 클래스로 옮기거나 자동 삭제하는 규칙이에요. S3 수명주기는 전환(transition)과 만료(expiration) 두 동작을 정의합니다. 생성 30일 후 저렴한 클래스로 전환하고, 1년 지나면 만료시켜 삭제하도록 둘 수 있어요. NHN Cloud Object Storage도 컨테이너나 개별 객체 단위로 수명 주기 제어를 제공합니다.
Q. 비용은 저장 용량만 보면 되나요?
아니에요. 보통 세 축으로 과금됩니다. 저장 용량(GB·월, 클래스별), 요청 수(PUT·GET 같은 API 호출), 데이터 전송(밖으로 나가는 egress)이에요. 여기에 IA·Glacier 계열은 꺼낼 때 검색 비용이 더해집니다. 그래서 저장 단가만 비교하면 요청과 전송 비용을 빠뜨려 실제 청구서와 어긋날 수 있어요.
