backup 정책 — 우리는 매일 새벽 4시

결제·정산 팀에서 백업은 '보험'이 아니라 '운영의 일부'다

일반적인 서비스에서 백업 실패는 불편함을 낳는다. 결제와 정산을 직접 운영하는 팀에서 백업 실패는 다른 차원의 문제다. 거래 내역, 정산 집계, 자동화 파이프라인의 상태값이 유실되면 단순한 데이터 복구 문제를 넘어 고객 환불 처리, 세무 신고 기준 데이터 재구성, 외부 PG사와의 대조 정산이 동시에 불가능해진다. 규제 환경에 따라서는 거래 기록 보관 의무(국내 전자금융거래법 기준 5년)를 충족하지 못하는 법적 리스크로 이어질 수도 있다.

HEDVION은 결제 처리, 자동 정산, 반복 청구 자동화를 소수 인원으로 직접 운영한다. 이 구조에서 장애 대응은 "누군가가 알아서 해주는 것"이 없다. 백업이 제대로 돌아가고 있는지, 복원이 실제로 되는지를 확인하는 프로세스 자체가 팀의 생존 인프라다. 처음에는 우리도 "cron에 등록해뒀으니 되겠지"라는 막연한 믿음으로 운영했다. 그 믿음이 깨진 것은 실제 복원을 시도해본 날이었다.

백업 파일이 존재하는 것과 복원이 되는 것은 완전히 다른 명제다

스크립트는 매일 실행되고 있었다. 파일도 날짜별로 쌓이고 있었다. 문제는 그 파일을 한 번도 실제로 적재해보지 않았다는 것이다. 스테이징 환경에서 복원을 시도했을 때, 덤프 파일 자체는 정상이었지만 파일 소유자 권한 불일치로 DB 적재가 중단됐다. 백업 스크립트를 실행하는 사용자와 복원 대상 서버의 DB 사용자가 달랐고, 그 차이를 한 번도 점검하지 않았던 탓이다.

이 사례가 보여주는 트레이드오프는 명확하다. 백업 설정에 들어간 초기 투자(1회, 수 시간)와 복원 테스트에 드는 반복 비용(분기 1회, 약 1~2시간) 사이에서 많은 팀이 후자를 생략한다. 하지만 실제 장애 상황에서 복원 실패를 처음 발견하면 그 비용은 몇 배로 돌아온다. 정산 데이터가 없는 상태에서 고객 대응, PG 대조, 내부 회계 재구성을 동시에 처리해야 하는 상황을 가정해보면 — 분기당 2시간짜리 복원 테스트는 매우 저렴한 보험이다.

새벽 4시라는 시간, 그 선택의 근거

백업 실행 시간은 임의로 정한 것이 아니다. 우리 서비스의 트래픽 패턴을 분석했을 때, 새벽 3시5시 구간이 DAU 기준 결제 요청량이 가장 낮다. DB 덤프는 일시적으로 I/O와 CPU를 점유하기 때문에 트래픽이 있는 시간대에 실행하면 응답 지연이 발생할 수 있다. 특히 정산 자동화처럼 배치 잡이 새벽 2시3시에 집중돼 있는 구조라면, 배치가 끝난 직후 백업을 가져가는 것이 가장 일관된 상태의 스냅샷을 확보하는 방법이기도 하다.

4시를 선택한 또 다른 이유는 알람 대응 가능성이다. 백업이 실패하면 슬랙 알림이 오는데, 새벽 4시의 실패 알림은 오전 7시~8시 출근 전에 수신된다. 담당자가 출근 전에 인지하고 오전 업무 시작 전 1차 대응을 마칠 수 있다. 오전 10시에 실패 알림이 온다면 이미 정산 리포트 요청이나 고객 CS가 쌓이기 시작한 이후다. 장애 대응 타이밍의 마진을 확보하는 것 자체가 정책 설계의 일부다.

7일 일간 + 4주 주간: 보존 정책의 비용과 복구력 균형

현재 보존 정책은 일간 7일 + 주간 4주다. 일간 백업은 최근 7일치를 롤링으로 유지하고, 매주 일요일 백업은 별도 보관해 4주치를 유지한다. 이 조합이 나온 배경에는 실제 장애 유형 분석이 있다.

우리가 경험하거나 가정하는 장애는 크게 두 가지다. 첫째는 즉각 인지되는 장애(서버 다운, 데이터 손상)로, 이 경우 보통 당일2일 이내 복구 시도가 이루어진다. 일간 7일치면 충분하다. 둘째는 조용히 쌓이는 오염(잘못된 자동화 스크립트가 특정 컬럼을 덮어쓰거나, 정산 집계 로직 버그가 23주 누적되는 경우)으로, 이때는 2~4주 전 상태를 기준점으로 삼아야 한다. 주간 백업 4주치가 이 케이스를 커버한다.

스토리지 비용 측면에서는, DB 덤프 압축 기준으로 우리 현재 규모(수십 GB)에서 월 스토리지 비용은 AWS S3 기준 약 1~2달러 수준이다. 이 비용으로 최대 31일치 복구 가능성을 확보하는 것은 어떤 기준으로도 합리적이다. 단, 데이터 규모가 수백 GB 이상으로 커지면 주간 보존 주기와 압축 전략을 다시 검토해야 한다. 정책은 규모에 따라 재보정되어야 한다는 점도 명시해둔다.

복원 테스트를 분기 루틴으로 만든 이유

분기 1회 복원 테스트는 지금 팀에서 공식 루틴으로 운영된다. 절차는 단순하다: 가장 최근 일간 백업 파일과 4주 전 주간 백업 파일을 각각 스테이징 DB에 적재하고, 핵심 테이블의 레코드 수와 정산 합계 금액이 예상 범위에 있는지 확인한다. 완전 복원 후 애플리케이션 레벨에서 로그인-결제조회-정산집계 3단계를 순서대로 확인하고, 결과를 팀 내부 문서에 날짜·담당자·결과 3가지로 기록한다.

이 테스트의 진짜 가치는 복원 자체가 아니라, 복원을 시도하는 과정에서 드러나는 환경 변화 감지에 있다. DB 스키마가 바뀌었는데 백업 스크립트가 갱신되지 않은 경우, 스토리지 접근 권한 정책이 변경된 경우, 신규 테이블이 백업 대상에서 빠진 경우 — 이런 문제들은 백업 성공 로그만 보면 절대 알 수 없다. 복원을 시도해야 비로소 보인다.

알림 설계: '조용한 성공'은 실패와 구분되지 않는다

백업 성공 알림도 슬랙으로 보낸다. 많은 팀이 실패 알림만 설정하는데, 이 설계에는 맹점이 있다. 스크립트 자체가 죽거나 cron 등록이 깨진 경우, 실패 알림도 오지 않는다. 알림이 없으면 성공인지 아무것도 안 일어난 건지 알 방법이 없다.

우리가 사용하는 패턴은 간단하다: 백업 스크립트 마지막 줄에서 성공/실패 모두 슬랙 웹훅을 호출하고, 메시지에는 실행 시간, 백업 파일 크기(전일 대비 증감률 포함), 대상 스토리지 경로를 담는다. 파일 크기가 전일 대비 50% 이상 감소하면 경고 이모지를 붙인다. 이것 하나만으로 "백업 파일이 쌓이고는 있는데 왜 이렇게 작지?"라는 의문을 조기에 포착할 수 있다. 실제로 한 번은 업로드 디렉터리 경로 변경으로 파일 백업이 빈 디렉터리를 대상으로 돌고 있었던 것을 크기 이상으로 발견한 적이 있다.

지금 당장 적용할 수 있는 실행 기준 4가지

막연하게 "백업을 잘 해야 한다"가 아니라, 내일 바로 점검할 수 있는 항목으로 정리한다.

1. 복원을 한 번도 안 해봤다면 이번 주 안에 시도하라. 스테이징이 없으면 로컬 Docker 환경에서라도 덤프를 적재해보는 것으로 시작한다. 파일이 있다는 것과 복원이 된다는 것은 별개다.

2. 알림이 실패에만 붙어 있다면 성공 알림을 추가하라. 슬랙 웹훅 한 줄이면 된다. 알림이 안 오는 것이 성공인지 스크립트 사망인지 구분되어야 한다.

3. 백업 대상 목록을 지금 확인하라. 최근 3개월 안에 추가된 테이블이나 디렉터리가 백업 스크립트에 반영되어 있는지 점검한다. 스키마 변경 이슈 체크리스트에 "백업 대상 갱신 확인"을 한 줄 추가하는 것만으로 이 문제의 90%는 막힌다.

4. 분기 1회 복원 테스트를 캘린더에 지금 등록하라. 결심이 아니라 일정이어야 실행된다. 테스트 결과는 날짜·담당자·성공여부 3가지만 기록해도 충분하다. 이 기록이 쌓이면 팀의 백업 신뢰도를 숫자로 증명할 수 있다.

백업은 한 번 설정하는 것이 아니라 지속적으로 유지하고 검증하는 운영 루틴이다. 설정해두고 잊는 순간, 그것은 없는 것과 같다.

— by slecs