백업 설계 갈등 해결: 개발팀 vs 운영팀 기준 맞추기

백업 갈등은 기술 문제가 아니라 복구 목표 합의 문제다

백업 설계 갈등은 저장 방식 논쟁이 아니라 장애 뒤 몇 분치 데이터까지 잃어도 되는지, 몇 분 안에 서비스를 다시 열어야 하는지를 정하는 운영 의사결정이다.

실무에서 회의가 길어지는 이유는 도구가 많아서가 아니다.
개발팀은 배포 속도와 기능 연속성을 먼저 보고, 운영팀은 복구 검증과 책임 통제를 먼저 본다.
같은 장애를 두고도 한쪽은 스냅샷 주기를 말하고, 다른 쪽은 복구 승인 절차를 말한다.
숫자가 없으면 회의는 의견 경쟁으로 끝나고, 다음 장애 때 같은 논쟁이 반복된다.

– 회의가 길어질 때 공통으로 보이는 장면

가장 흔한 장면은 개발팀이 “10분 단위 백업이면 충분하다”고 말하고, 운영팀이 “복구 테스트 없이 그 숫자를 믿을 수 없다”고 받아치는 상황이다. 문제는 둘 다 틀린 말이 아니라는 점이다. 서비스 성격이 다른데도 같은 기준으로 이야기하니 충돌이 생긴다.

주문·결제처럼 데이터 정합성이 중요한 서비스와 사내 문서처럼 일시 중단 허용이 가능한 서비스를 같은 기준으로 묶으면 설계가 왜곡된다. 또 인프라 백업은 운영팀, 애플리케이션 일관성은 개발팀, 최종 승인자는 서비스 오너로 나뉘어 있으면 장애 순간에 소유권 공백이 생긴다.

– 왜 이런 문제가 생기는가

① 개발팀은 출시 지연 1일이 일정과 매출에 직접 연결되기 때문에 백업 설계를 가볍고 자동화하기 쉬운 방식으로 보려는 경향이 있다.
② 운영팀은 장애 1건이 야간 대응 3시간, 보고 2회, 사후 점검 1주로 이어질 수 있어서 복구 검증과 승인 경계를 더 엄격하게 요구한다.
③ 두 팀이 같은 단어를 써도 의미가 다르다. 개발팀이 말하는 “복구 가능”은 재기동 성공이고, 운영팀이 말하는 “복구 가능”은 데이터 검증 완료까지다.
④ 백업 주기, 보관 기간, 복구 절차, 승인 체계가 한 문서에 연결되지 않으면 각 팀은 자기 영역만 최적화한다.
⑤ 특히 RPO와 RTO가 비어 있으면 비용 논의가 감정 논쟁으로 바뀐다. 더 자주 백업할수록 저장 비용과 운영 복잡도는 올라가고, 더 짧게 복구할수록 대기 자원과 훈련 비용도 증가한다.
⑥ 테스트 기준이 없으면 “된다”와 “안 된다”가 개인 경험에 의존한다. 결국 숫자 없는 회의는 주장만 남기고 책임 공방으로 끝난다.

결국 백업 갈등은 기술 선택 문제가 아니라 손실 허용치, 복구 시간, 소유권을 문서로 못 박지 못한 운영 설계 문제다.

– RPO·RTO 숫자로 기준을 통일한다

합의는 선호 도구가 아니라 업무 영향 숫자부터 시작해야 한다. RPO는 허용 가능한 데이터 손실 시점이고, RTO는 허용 가능한 서비스 중단 시간이다. 회의는 “무조건 자주 백업하자”가 아니라 “이 서비스는 몇 분 손실까지 허용되는가”로 바뀌어야 빨라진다.

구분	개발팀 질문	운영팀 질문	합의 숫자 예시	판단 기준
주문/결제	몇 분 손실까지 허용 가능한가	검증 완료까지 몇 분 필요한가	RPO 5분 / RTO 30분	손실 허용이 작고 복구 우선순위 최상
협업 문서	최근 수정분 일부 손실이 허용되는가	업무 재개까지 몇 분이 적정한가	RPO 30분 / RTO 60분	최신성보다 가용성 우선
로그/분석	지연 수집이 가능한가	재처리로 복원 가능한가	RPO 60분 / RTO 120분	재생성 가능 데이터는 완화 가능

핵심은 모든 시스템을 같은 수치로 묶지 않는 것이다. 매출 직결, 고객 신뢰, 내부 생산성처럼 영향도를 분리해야 설계가 과하지도 약하지도 않다.

– 요구사항 수집부터 정책 1장까지

1. 서비스별 요구사항을 30분 안에 수집한다. 시스템 이름, 데이터 유형, 허용 손실 시간, 허용 중단 시간, 복구 승인자, 테스트 주기를 한 시트에 적는다.

2. 수집한 내용을 기준으로 RPO와 RTO를 숫자로 확정한다. 숫자는 5분, 15분, 30분, 60분처럼 실제 운영 가능한 단위로 정하고 “가능한 한 짧게” 같은 표현은 쓰지 않는다.

3. 책임과 소유권을 나눈다. 백업 실행은 운영팀, 애플리케이션 일관성 확인은 개발팀, 최종 복구 승인과 대외 보고는 서비스 오너로 적는다.

4. 정책 1장으로 고정한다. 대상 시스템, RPO, RTO, 백업 방식, 보관 기간, 테스트 주기, 승인자, 예외 조건만 남긴다.

5. 분기 1회 복구 리허설을 일정에 넣는다. 회의에서 합의한 숫자는 테스트에서 지켜질 때만 의미가 있다.

실제 현장에서는 이런 식으로 정리된다.
월요일 장애 회의에서 개발팀은 스냅샷 10분 주기를 주장했다.
운영팀은 정합성 검증까지 40분이 필요하다고 말했다.
주문 시스템은 RPO 5분, RTO 30분으로 다시 잡았다.
대신 협업 문서는 RPO 30분, RTO 60분으로 완화해 전체 비용을 맞췄다.

– 말이 아니라 수치로 재확인한다

테스트는 최소 분기 1회, 핵심 시스템은 월 1회 샘플 복구로 운영한다. 검증 항목은 4개면 충분하다. 첫째, 최근 백업본이 목표 RPO 이내 시점인지 확인한다. 예를 들어 RPO 15분이면 장애 시각 기준 백업 시점 차이가 15분 이하인지 본다.

둘째, 복구 시작부터 정상 응답까지 걸린 시간이 목표 RTO 이내인지 측정한다. 목표가 30분이면 1,800초 안에 핵심 화면과 API 3개가 정상 응답해야 한다. 셋째, 데이터 정합성 샘플 20건을 대조한다. 주문 수량, 결제 상태, 사용자 권한처럼 중요한 필드를 비교해 불일치 0건을 기준으로 삼는다. 넷째, 알림 발송 5분 이내, 복구 승인 10분 이내, 검증 완료 보고 15분 이내처럼 사람 대응 시간도 숫자로 관리한다.

– 재발을 막는 운영 방식

가장 효과적인 예방책은 백업 설계를 인프라 문서가 아니라 서비스 정책으로 운영하는 것이다. 새 시스템이 생기면 아키텍처 리뷰 전에 RPO·RTO를 먼저 적고, 변경 요청서에는 기존 수치 변화 여부를 넣는다.

예외도 방치하지 말아야 한다. 특정 배치 시스템만 주 1회 백업처럼 다른 정책을 쓰면 그 이유와 종료 시점을 같이 적는다. 최근 백업 시각, 최근 복구 테스트 일자, 최근 30일 실패 횟수, 담당자 이름 1명을 한 화면에 보이게 하면 책임이 흐려지지 않는다.

– 30초 체크리스트

– 자주 하는 실수 / 주의할 점

가장 큰 실수는 전체 시스템에 같은 백업 정책을 적용하는 것이다. 이렇게 하면 중요한 서비스는 약해지고 덜 중요한 서비스는 과설계된다. 두 번째 실수는 백업 성공 로그만 보고 안심하는 것이다. 복구 테스트가 없으면 백업 파일은 있어도 서비스를 못 살릴 수 있다.

세 번째 실수는 책임자를 팀 단위로만 적는 것이다. 장애 상황에서는 “운영팀 확인”보다 “김OO 승인”처럼 1명 기준이 훨씬 빠르다. 비용 절감을 이유로 RPO를 늘릴 때는 비즈니스 손실 추정도 함께 다시 계산해야 한다.

– 마무리 : 상황별 적용 우선순위

매출 직결 시스템은 짧은 RPO와 짧은 RTO를 우선하고, 내부 지원 시스템은 복구 시간 완화로 비용을 조정한다. 데이터 재생성이 가능한 로그성 시스템은 보관 기간과 재처리 절차를 중심으로 설계하고, 정합성이 중요한 시스템은 검증 시간을 포함한 RTO로 합의한다.

팀 갈등을 줄이는 가장 빠른 방법은 회의 끝에 숫자 2개와 책임자 1명을 남기는 것이다.
오늘은 서비스 3개만 골라 RPO, RTO, 복구 승인자를 정책 1장으로 먼저 적는다.

– 요약

– FAQ

Q1. RPO와 RTO 중 무엇부터 정해야 하나요?
A1. 먼저 RPO를 정하면 데이터 손실 허용치가 확정되고, 그다음 RTO를 정하면서 복구 절차와 자원 규모를 현실적으로 맞출 수 있다.

Q2. 모든 시스템에 같은 기준을 적용하면 관리가 쉬운 것 아닌가요?
A2. 관리 문서는 단순해지지만 실제 운영 품질은 나빠진다. 주문 시스템과 사내 문서를 같은 수치로 묶으면 한쪽은 과소 보호, 다른 한쪽은 과잉 비용이 된다.

Q3. 백업 성공률이 높으면 복구 테스트를 줄여도 되나요?
A3. 안 된다. 백업 성공은 저장 성공일 뿐이고, 복구 테스트는 실행 시간과 데이터 정합성까지 확인하는 별도 검증이다.