클라우드스토리지 선정 기준 | 접근 방식부터 보존·삭제 조건까지
클라우드스토리지는 용량보다 애플리케이션의 접근 방식과 데이터의 삭제 조건부터 정하는 편이 좋습니다. 기존 공유 폴더를 그대로 써야 하는지, 객체 API를 사용할 수 있는지, 보존 중인 데이터를 누가 어떤 조건에서 삭제할 수 있어야 하는지를 먼저 정하면 후보를 좁힐 수 있습니다.
이 글은 업무 저장소를 도입하거나 재설계하는 인프라 담당자와 데이터 플랫폼 엔지니어를 위한 선정 기준입니다. 제품별 가격 순위를 매기는 대신, 파일·객체·블록 저장소의 용도를 구분하고 보존·권한·반출 요구를 평가표로 연결합니다. 보존 기능의 구체적인 동작은 공식 문서가 확인된 Amazon S3를 사례로 설명하며, 다른 서비스에도 같은 동작이 있다고 전제하지 않습니다.
1. 저장할 데이터보다 먼저, 데이터를 쓰는 방식을 적는다
‘문서 파일을 저장한다’는 설명만으로는 유형을 결정하기 어렵습니다. 사람이 공유 폴더에서 편집하는 문서인지, 애플리케이션이 API로 올리고 내려받는 문서인지에 따라 필요한 접근 방식이 달라집니다. 분석 데이터 역시 데이터라는 이름만으로 객체 저장소를 정하기보다, 사용하는 처리 도구의 접근 방식을 먼저 적어야 합니다.
AWS의 블록·파일·객체 저장소 비교 문서는 객체 저장소 접근에 API와 이름 규칙을 고려해야 한다고 설명합니다. 반면 공유 파일 저장소에 맞춰 구성된 애플리케이션은 파일 저장소 통합에 새 코드가 필요하지 않다고 설명합니다. 다만 이것이 모든 파일 저장소 서비스의 프로토콜과 권한 모델이 같다는 뜻은 아닙니다. 아래 구분은 해당 문서를 바탕으로 정리했습니다. 문서 확인일은 2026년 11월 9일입니다.
| 업무 조건 | 먼저 검토할 유형 | 선정 전 대조할 사항 |
|---|---|---|
| 기존 애플리케이션이 공유 파일 저장소를 사용 | 파일 저장소 | 현재 사용하는 파일 프로토콜과 권한 모델을 후보 서비스가 지원하는가 |
| 애플리케이션이 객체 API로 데이터를 처리하거나 그렇게 변경할 수 있음 | 객체 저장소 | API 호출과 객체 이름 규칙을 애플리케이션에 적용할 수 있는가 |
| 가상 머신·데이터베이스처럼 블록 수준 접근이 필요한 업무 | 블록 저장소 | 실제 업무 부하에서 요구하는 읽기·쓰기 조건을 충족하는가 |
AWS는 블록 저장소의 활용 예로 가상 머신과 데이터베이스를 듭니다. 그렇다고 특정 블록 저장소가 항상 더 빠르다고 결론 내릴 수는 없습니다. 유형의 적합성과 개별 서비스의 성능 검증은 별개입니다.
따라서 기존 공유 폴더를 변경 없이 유지해야 하는 업무에 객체 API만을 전제로 한 후보를 곧바로 대입하는 것은 피해야 합니다. 반대로 애플리케이션이 이미 객체 API 중심이라면, 파일 공유 기능의 유무보다 필요한 API 동작과 데이터 관리 조건을 우선 평가할 수 있습니다.
2. 보존 기간보다 중요한 것은 ‘무엇이 잠기는가’다
보존 정책을 비교할 때는 ‘잠금 지원’이라는 기능명만 표시하지 말고, 보호 대상과 우회 가능성을 나눠 적어야 합니다. 데이터가 보이지 않는 상태, 삭제 요청이 처리된 상태, 과거 버전까지 삭제된 상태도 구분해야 합니다.
S3 Object Lock 공식 문서에 따르면 Object Lock은 버전 관리가 활성화된 버킷에서 동작하며, 보존 기간이나 legal hold는 지정한 객체 버전을 보호합니다. 새 버전이나 삭제 마커를 추가하는 것까지 막지는 않습니다. 따라서 현재 목록에서 파일이 사라졌다는 사실만으로 과거 버전까지 삭제됐다고 판단해서는 안 됩니다. 해당 문서는 2026년 11월 9일 확인했습니다.
- Compliance 모드: 보호된 버전은 보존 기간 중 루트 사용자를 포함한 사용자가 덮어쓰거나 삭제할 수 없습니다. 보존 기간 단축과 모드 변경도 불가능합니다.
- Governance 모드: 특별한 우회 권한과 명시적인 우회 요청이 있으면 보존 설정을 변경하거나 삭제할 수 있습니다. ‘관리자도 삭제 불가’라는 요구를 기능명만으로 충족했다고 볼 수 없습니다.
- Legal hold: 보존 기간과 독립적으로 작동하며, 권한 있는 사용자가 해제할 때까지 보호가 유지됩니다. 보존 기간이 끝났어도 hold가 남아 있으면 보호가 계속됩니다.
이 차이를 선정표에 반영하려면 보존 시작 기준, 만료일, 보호할 버전의 범위, 우회 권한 보유자, hold 해제 승인자를 별도 항목으로 두는 것이 좋습니다. 법정 보존 기간은 제품 문서에서 도출할 사항이 아닙니다. 업무·법무가 정한 요구를 먼저 확정하고, 그 요구를 서비스의 동작과 대조해야 합니다.
3. 보존 의무와 삭제 요청이 충돌할 때의 처리도 정한다
‘일정 기간 보관’과 ‘요청 시 삭제’를 각각 적어두는 것만으로는 운영 기준이 완성되지 않습니다. 두 요구가 같은 데이터에 적용될 때 누구에게 판단을 요청하고, 어떤 근거와 승인을 남길지까지 정해야 합니다.
특히 S3 compliance 모드는 보존 기간을 줄일 수 없으므로, 삭제 요청이 들어오면 관리자가 잠금을 풀면 된다는 운영안을 전제로 도입해서는 안 됩니다. Governance 모드라면 우회 권한을 누가 보유하는지가 통제 설계의 일부가 됩니다. Legal hold가 적용된 데이터는 보존 만료일뿐 아니라 hold 해제 여부도 별도로 확인해야 합니다.
자동 정리 정책도 잠금과 분리해서 봐야 합니다. S3 Object Lock 관리 문서는 잠긴 객체 버전을 S3 Lifecycle 만료 정책으로 삭제할 수 없다고 설명합니다. 수명주기 정책을 설정했다는 사실만으로 보호 버전이 예정일에 삭제된다고 판단할 수 없습니다. 문서 확인일은 2026년 11월 9일입니다.
도입 전에 합의할 삭제 처리 기준
- 삭제 요청의 범위가 현재 데이터만인지, 과거 버전까지인지 명시합니다.
- 보존 기간·legal hold와 충돌하는 요청의 판단 책임자를 지정합니다.
- 삭제 불가 상태를 예외 처리로 남길 때 필요한 승인과 기록을 정합니다.
- 삭제 완료 판정에 사용할 증거를 정합니다. 현재 목록의 비노출만으로 완료 처리하지 않습니다.
4. 권한과 키 관리까지 포함해야 ‘보관 가능’한 저장소다
읽기·쓰기 권한만 비교하면 보존 정책을 바꾸거나 보호를 우회하는 권한이 빠질 수 있습니다. 선정 단계에서는 일반 업무 계정, 보존 정책 관리자, 우회 권한 보유자, 감사 담당자의 역할을 나눠 요구사항을 적어두는 편이 좋습니다. 후보 서비스에는 그 구분을 구현할 수 있는 권한 단위와 기록 범위를 요청합니다.
암호화 키도 별도 평가 항목입니다. S3 Object Lock 관리 문서는 Object Lock이 암호화 키 접근 상실이나 키 삭제를 보호하지 않는다고 설명합니다. AWS KMS 서버 측 암호화 키가 삭제되면 객체를 읽지 못할 수 있습니다. 객체가 삭제되지 않는 것과 나중에 읽거나 반출할 수 있는 것은 같은 조건이 아닙니다.
- 누가 데이터를 읽고 쓰며, 누가 보존 설정과 우회 권한을 변경할 수 있어야 하는가?
- 정책 변경·삭제·우회 요청에 대해 어떤 감사 증거를 요구할 것인가?
- 키 관리 책임자와 데이터 운영 책임자가 다를 때, 접근 장애와 반출 승인은 누가 처리할 것인가?
이 요구를 정리한 뒤에는 계정 분리와 감사 기록을 실제 서비스 개시 승인 기준으로 연결해야 합니다. 구체적인 승인 항목은 다음 글에서 이어서 살펴볼 수 있습니다.
5. 평가표는 대표 데이터의 읽기·쓰기·삭제 시험으로 마무리한다
최종 평가표에는 기능 유무뿐 아니라 ‘충족해야 할 업무 조건’과 ‘판정 증거’를 함께 적습니다. 다음 항목은 서비스 기능을 단정하는 표가 아니라, 후보별로 문서와 시험 결과를 채워 넣기 위한 틀입니다.
- 접근 방식: 현재 애플리케이션의 프로토콜 또는 API를 적고, 대표 데이터의 읽기·쓰기가 가능한지 시험합니다. 변경이 필요하면 수정 범위와 담당자를 기록합니다.
- 보존과 삭제: 적용 모드와 보호 대상을 적고, 보존 중 삭제 요청이 어떻게 처리되는지 확인합니다. 현재 데이터와 과거 버전을 나눠 결과를 남깁니다.
- 권한 분리: 업무 계정과 관리 계정을 구분해 시험하고, 보존 설정 변경이나 우회 요청을 누가 할 수 있는지 기록합니다.
- 만료와 hold: 보존 만료, hold 유지, hold 해제를 각각 구분해 판정합니다. 자동 정리 정책의 설정 여부와 실제 삭제 결과를 별도 항목으로 둡니다.
- 반출: 대표 데이터를 목표 환경으로 옮긴 뒤 읽을 수 있는지 시험하고, 필요한 메타데이터와 권한 정보를 어떻게 보존하거나 재구성할지 기록합니다.
시험은 운영 원본과 분리한 대표 데이터로 설계하는 것이 좋습니다. 특히 기간을 줄일 수 없는 잠금을 적용하기 전에는 대상과 기간을 재확인하고, 업무·법무의 보존 기준이 확정되지 않았다면 운영 데이터 적용을 멈추는 기준을 두십시오.
반출은 저장소 선정에서 확인할 항목이지만, 목표 환경에서 업무를 재개할 수 있는지까지 검증하려면 별도의 이전 계획이 필요합니다. 후보를 좁혔다면 다음 글의 데이터 반출·서비스 이전 검증으로 이어갈 수 있습니다.
최종 선택은 필수 조건을 통과한 후보 사이에서 진행하십시오. 기존 접근 방식을 수용하지 못하거나, 보존·삭제 충돌의 처리 책임이 없거나, 필요한 데이터를 다시 읽어낼 방법을 입증하지 못한 후보는 우선 보류하는 기준을 세울 수 있습니다. 이렇게 하면 클라우드 스토리지 비교가 용량과 기능명 나열이 아니라, 실제 업무를 유지할 수 있는지를 판단하는 과정이 됩니다.
댓글
댓글 쓰기