[중급] AWS 백업 설계, 이 5가지 실수하면 요금 폭탄 맞고 데이터 날린다

이게 결론! 백업은 보험이다.

평소에 돈 아깝다고 설계 대충하면, 사고 터졌을 때 시스템 전체가 날아간다. 지난달에 맡은 프로젝트에서 백업 비용만 월 수백만 원씩 더 나오는 걸 잡았다. 원인은 딱 하나. 아무 생각 없이 ‘기본값’으로 설정한 백업 정책 때문이었다. 이건 아마추어나 하는 짓이다.

백업은 단순히 데이터를 저장하는 행위가 아님. 비용(Cost), 복구 시간(RTO), 데이터 손실 허용치(RPO) 사이의 줄타기다. 이 세 가지를 이해 못 하면 영원히 요금 폭탄과 복구 실패의 늪에서 허우적댈 뿐이다. 대부분 실무자가 저지르는 치명적인 실수 5가지를 정리했다.

실수 1: ‘하나의 정책’으로 모든 걸 해결하려는 만능주의

가장 흔하고 가장 멍청한 실수. 개발 서버의 로그 파일과 운영 DB의 데이터를 똑같은 주기로 백업한다? 이건 성냥갑이랑 국보 1호에 똑같은 화재 보험을 드는 격이다. 리소스의 중요도, 변경 빈도를 전혀 고려하지 않은 접근 방식이다.

🤔 그럼 어떻게?
리소스에 태그(Tag)부터 박아야 한다. ‘critical’, ‘staging’, ‘dev’ 같은 식으로. 그리고 태그별로 백업 플랜을 따로 만들어야 함. 핵심 DB는 1시간마다, 웹서버는 하루 한 번, 개발 서버는 주 1회. 이게 기본이다.

실수 2: 스냅샷 데이터의 수명 주기(Lifecycle) 방치

EBS 스냅샷, RDS 스냅샷… 일단 만들어두면 마음은 편하다. 문제는 이게 계속 쌓인다는 것. 3년 전 개발 서버 스냅샷을 아직도 원본 스토리지 비용 그대로 내고 있는 경우가 태반이다. 명백한 돈 낭비다.

🤔 해결책은?
AWS Backup의 수명 주기 설정을 활용해야 한다. 예를 들어, 30일이 지난 스냅샷은 자동으로 저렴한 콜드 스토리지로 이동시키고, 180일이 지나면 삭제하는 식이다. 옷장 정리랑 똑같다. 안 입는 겨울옷은 창고에 넣고, 10년째 안 입는 옷은 버리는 것.

실수 3: 복구 테스트는 ‘언젠가’ 하겠다는 착각

백업 파일이 있다고 해서 복구가 100% 된다는 보장은 어디에도 없다. 백업 과정에서 파일이 깨졌을 수도 있고, 의존성 있는 다른 리소스가 누락됐을 수도 있다. ‘백업 = 성공’이라는 공식은 세상에 없다.

🤔 이건 어떻게 증명하나?
답은 하나, 직접 해보는 거다. 분기별로 한 번씩 실제 상황을 가정하고 복구 훈련(Drill)을 해야 한다. 특정 시점의 DB를 복원해서 데이터 정합성이 맞는지, 웹서버 이미지를 다른 인스턴스에 올려서 정상 부팅되는지 직접 눈으로 확인해야 함. 소화기 사용법을 글로만 배우면 불났을 때 아무것도 못 하는 것과 같다.

실수 4: S3는 무적이라는 맹신

S3의 내구성이 99.999999999%라고 하니, 다들 S3에 파일만 올려두면 안전할 거라 믿는다. 하지만 이건 물리적 유실에 대한 얘기일 뿐, 사람의 실수(Human Error)는 막아주지 않는다. 누군가 `rm -rf` 명령어를 잘못 날리거나, 랜섬웨어에 감염되면? 데이터는 그냥 증발한다.

🤔 S3는 어떻게 지키나?
두 가지가 필수다. 버저닝(Versioning)과 객체 잠금(Object Lock). 버저닝은 파일을 덮어쓰거나 삭제해도 이전 버전을 모두 보관하는 기능이다. 일종의 ‘되돌리기’ 버튼. 객체 잠금은 특정 기간 동안은 수정이나 삭제를 아예 못 하게 막아버린다. 랜섬웨어도 뚫지 못하는 최후의 보루다.

실수 5: 리전(Region) 장애에 대한 무지

서울 리전에만 백업 데이터를 쌓아두고 안심하는가? 만약 서울 리전 전체에 문제가 생기면 어떻게 할 건가. 원본과 백업본이 같은 건물에 불타는 꼴이다. 이건 재해 복구(DR)의 기본 원칙을 무시하는 행위다.

🤔 이건 스케일이 너무 큰데?
모든 데이터를 옮길 필요는 없다. 정말 중요한, 비즈니스의 명운이 걸린 데이터만이라도 교차 리전 복제(Cross-Region Replication)를 설정해야 한다. 비용은 좀 더 들지만, 회사 전체가 마비되는 최악의 시나리오를 막을 수 있다. 집 열쇠와 예비 열쇠를 같은 주머니에 넣고 다니지 않는 것과 같은 이치다.

그래서 리소스별 최적의 전략은?

Q. EBS 볼륨 백업은 어떻게?

A. AWS Backup을 써서 중앙 관리하는 게 정답. 인스턴스에 붙은 태그 기반으로 백업 플랜을 적용하고, 수명 주기 관리로 비용을 잡아야 함. 운영 DB용 EBS는 최소 하루 1회 이상 스냅샷, 로그나 임시 데이터용 EBS는 주 1회 정도로 차등 적용.

Q. RDS 데이터베이스는 뭐가 다른가?

A. RDS의 핵심은 특정 시점 복구(Point-in-Time Recovery, PITR)다. 이걸 활성화하면 최대 35일 이내 원하는 ‘초’ 단위로 DB를 되돌릴 수 있다. 어제 오후 2시 5분 30초의 상태로. 이건 자동 백업 기능과 트랜잭션 로그를 활용하는 방식. 수동 스냅샷만 믿고 있다간 큰코다친다.

Q. S3 백업은 버저닝만 켜면 끝?

A. 아니다. 버저닝은 기본이고, 정말 중요한 데이터는 교차 리전 복제(CRR)를 걸어야 한다. 서울 리전 버킷의 파일이 변경되면, 거의 실시간으로 도쿄나 싱가포르 리전의 버킷에 복사본을 만드는 것. 한쪽 리전이 마비돼도 즉시 다른 쪽에서 서비스를 이어갈 수 있다.

PipeMaster-Lab 운영정책 및 제보 안내