고객사 한 곳에서 “어제 오후의 데이터로 되돌려 주세요”라는 요청이 들어왔다고 가정해 보겠습니다. 서비스 전체 백업은 매일 만들고 있지만, 여러 고객사의 정보가 한 데이터베이스에 섞여 있다면 복구는 단순한 버튼 한 번이 아닙니다. 전체 백업을 운영 DB에 덮어쓰면 다른 고객사의 오늘 작업까지 사라집니다. 특정 테넌트만 골라 복구하는 별도 절차가 필요합니다.
먼저 '무엇을 되돌릴지' 합의한다
복구 요청의 표현은 흔히 모호합니다. 삭제된 주문 한 건을 되살리는 것과 고객사 전체를 지난 시점으로 되돌리는 일은 위험도가 다릅니다. 대상 테넌트 ID, 기준 시각과 시간대, 복구할 테이블·파일·설정 범위, 지금 입력된 데이터를 유지할지 폐기할지를 먼저 문서화해야 합니다. 특히 결제나 외부 연동처럼 이미 다른 시스템에 전달된 사건은 DB를 과거로 되돌려도 자동으로 취소되지 않습니다. 복구와 업무상 정정을 분리해서 결정해야 합니다.
운영자가 확인할 첫 질문은 세 가지입니다. 원인은 실수 삭제인가, 잘못된 대량 수정인가, 시스템 장애인가? 특정 객체만 복원하면 되는가? 복구 과정에서 고객사의 새 입력을 잠시 멈출 수 있는가? 이 답이 정해져야 안전한 방법을 고를 수 있습니다.
안전한 기본 경로: 격리 복원 후 선택적 이관
공유 DB 백업을 별도의 임시 환경에 복원하고, 그 안에서 대상 테넌트의 레코드만 추출합니다. 운영 DB와 연결되지 않는 계정·네트워크를 쓰고, 복원된 환경에는 실제 알림 발송이나 외부 API 호출이 나가지 않게 막습니다. 추출한 데이터의 키와 참조 관계를 검사한 뒤에야 운영 환경으로 이관합니다. 이 방식은 다른 고객사를 건드리지 않는다는 장점이 있지만, 테넌트 경계가 데이터 모델에 선명하게 표현돼 있어야 합니다.
모든 테이블에 tenant_id가 있다고 끝나지 않습니다. 주문은 공통 상품 마스터를 참조할 수 있고, 첨부파일은 DB 밖의 객체 저장소에 있으며, 검색 인덱스와 캐시는 파생 데이터입니다. 테넌트 소유 데이터와 공유 기준 데이터를 구분하고, 참조 대상이 복원 시점과 현재 시점 중 어느 상태를 따라야 하는지 정해야 합니다. 가능하면 외래키와 애플리케이션 수준의 참조를 함께 검증합니다.
충돌을 피하는 이관 순서
복구 직전에는 대상 고객사의 쓰기 작업만 짧게 동결하거나 새 이벤트를 별도 큐에 보관합니다. 이때 다른 고객사의 서비스는 유지하는 것이 목표입니다. 이어 현재 상태를 별도로 백업해 되돌릴 길을 만들고, 차이 보고서를 생성합니다. 삭제할 행, 다시 넣을 행, 유지할 행을 고객사 담당자와 운영자가 함께 확인하면 “되돌렸더니 오늘 입력이 사라졌다”는 사고를 줄일 수 있습니다.
실제 적용은 작은 단위로 진행합니다. 부모 데이터를 먼저 준비하고 자식 데이터를 이관하며, 충돌하는 ID는 매핑합니다. 파일 객체와 DB 메타데이터를 함께 처리하고, 완료 뒤 검색 인덱스·캐시를 대상 테넌트 범위로 다시 만듭니다. 오래된 백업의 암호화 키나 스키마 버전이 현재 코드와 맞는지도 미리 시험해야 합니다.
행 수보다 중요한 검증
복구 전후의 주문·사용자·첨부 수량을 비교하되, 그것만으로 성공 판정을 내리지 않습니다. 대표 업무 흐름을 실제로 실행해 보세요. 고객사가 자기 자료만 볼 수 있는지, 권한이 다른 사용자에게 노출되지 않는지, 다운로드 링크가 열리는지, 최근 외부 연동 이벤트가 이중 발송되지 않는지 확인해야 합니다. 감사 기록에는 누가 어떤 범위를 어느 백업에서 복원했는지 남깁니다. 검증이 끝나기 전에는 임시 환경의 민감 데이터를 방치하지 않습니다.
설계 단계에서 남겨둘 것
테넌트 경계가 모호하면 사고가 난 뒤에 복구 절차를 만들기 어렵습니다. 새 테이블을 추가할 때마다 소유 테넌트, 공유 데이터 여부, 파일·검색·캐시 파생물, 외부 시스템 영향, 복구 테스트 항목을 함께 기록하세요. 백업이 있다는 사실보다 특정 고객사를 실제로 되살리는 훈련을 해봤는지가 더 중요합니다. 복구 시간 목표와 허용 가능한 데이터 손실 범위도 고객과 사전에 합의해야 합니다.
체크리스트는 짧게 유지할 수 있습니다. ① 복구 대상과 시점 확정 ② 격리 환경 복원 ③ 관계·파일·권한 포함 차이 분석 ④ 대상 쓰기 동결과 현 상태 백업 ⑤ 선택적 이관 ⑥ 업무 흐름 검증 ⑦ 감사 기록과 재발 방지. 이 순서를 반복 가능한 실행 절차로 만들어 두면 긴급 상황에서 판단의 빈칸이 줄어듭니다.
참고: AWS Prescriptive Guidance의 멀티테넌트 PostgreSQL 설계 가이드도 테넌트 단위 백업·복구 고려사항을 다룹니다.
