자체 SaaS 4종을 운영하며 정한 백업·복구 기준

핵심 요약 — 백업은 거의 모든 프로젝트 견적에 들어가요. 그런데 실제로 복구를 해본 팀은 많지 않아요. 백업 파일이 있다는 것과 되돌릴 수 있다는 건 다른 이야기예요. 저희는 자체 SaaS 4종을 운영하면서 백업을 “얼마나 자주 받나”가 아니라 “얼마나 잃어도 되고, 얼마 안에 되돌려야 하나”로 정리했어요. 그 기준 네 가지와 발주 시 확인할 항목을 공유할게요.

“백업은 하고 있죠?”라는 질문에 “네, 매일 받고 있어요”라고 답할 수 있는 팀은 많아요. 그런데 “그럼 지금 세 시간 전 상태로 되돌리는 데 얼마나 걸리나요?”라고 물으면 대답이 잠시 멈춰요.

백업은 파일을 만드는 일이고, 복구는 서비스를 되살리는 일이에요. 두 가지는 함께 준비해야 하는데, 견적서에는 앞의 것만 적히는 경우가 많아요.

저희가 자체 서비스를 운영하며 쓰는 기준을 정리했어요. 규모가 크지 않은 서비스에도 그대로 적용할 수 있는 내용이에요.

---

1. 먼저 정할 건 주기가 아니라 “얼마나 잃어도 되는가”예요

백업 이야기는 보통 “하루에 한 번 받을까요, 여섯 시간마다 받을까요”로 시작해요. 그런데 그 질문에 답하려면 앞선 질문이 필요해요.

사고가 났을 때 몇 시간 치를 잃어도 감당되나요?

이 답이 정해지면 주기는 따라 나와요. 여섯 시간 치를 잃어도 된다면 여섯 시간마다 받으면 되고, 한 건도 잃으면 안 된다면 변경이 생길 때마다 기록을 남기는 다른 방식이 필요해요.

그리고 얼마 안에 되돌려야 하나요?

이건 복구에 쓸 수 있는 시간이에요. 30분 안에 되살려야 하는 서비스와 하루가 걸려도 되는 서비스는 준비 방식이 달라요. 앞의 경우엔 평소에 대기 중인 예비 환경이 필요하고, 뒤의 경우엔 백업 파일에서 다시 세우는 것으로 충분해요.

이 두 가지를 정하지 않고 “백업 구축”만 적으면, 업체는 대개 가장 단순한 방식(하루 한 번 파일 저장)으로 견적을 잡아요. 나중에 “세 시간 전으로 돌려주세요”라고 했을 때 그게 안 되는 이유가 여기 있어요.

2. 데이터를 전부 같은 기준으로 다루지 않아요

서비스 안의 데이터가 다 똑같이 중요하지는 않아요. 저희는 크게 세 갈래로 나눠요.

잃으면 안 되는 것. 결제·정산 기록, 계약 정보, 사용자 계정처럼 다시 만들 수 없는 데이터예요. 가장 촘촘하게 보호하고 사본도 다른 위치에 둬요.

잃으면 불편하지만 복구할 수 있는 것. 게시물, 설정값, 통계 원자료처럼 시간이 걸려도 다시 채울 수 있는 데이터예요. 앞의 것보다 주기를 여유 있게 잡아요.

다시 만들면 되는 것. 캐시나 임시 파일, 다시 계산할 수 있는 집계값이에요. 백업 대상에서 빼요. 여기까지 백업하면 용량과 시간만 늘고 복구가 오히려 느려져요.

이렇게 나누는 이유는 비용 때문이에요. 전부 가장 높은 기준으로 보호하면 저장 비용과 처리 시간이 함께 올라가요. 반대로 전부 낮은 기준으로 두면 정작 중요한 데이터가 덜 보호돼요.

발주 단계에서 이 구분을 해두면 견적에서 “무엇을” 백업하는지가 분명해져요. 서비스 규모가 커질 때 비용이 어떻게 늘어나는지는 서비스가 커질 때 비용이 늘어나는 지점들에 정리해뒀어요.

3. 사본은 원본과 다른 곳에 둬요

백업을 같은 서버 안에 두는 경우가 생각보다 많아요. 실수로 지운 데이터를 되살리는 데는 도움이 돼요. 하지만 서버 자체에 문제가 생기면 백업도 함께 사라져요.

그래서 최소한 원본과 다른 위치에 사본 하나를 둬요. 다른 저장소든, 다른 지역이든, 형태는 서비스 상황에 따라 정하면 돼요.

여기서 함께 정할 게 하나 더 있어요. 누가 백업에 접근할 수 있는가 예요. 백업 파일에는 서비스의 데이터가 통째로 들어 있어요. 운영 데이터보다 오히려 접근 관리가 느슨한 경우가 있는데, 보호 수준은 원본과 같아야 해요.

보관 기간도 정해둬요. 무한정 쌓아두면 비용도 늘고, 오래된 개인정보가 백업 안에 남는 문제도 생겨요. “며칠 치를 두고 그 이전은 정리한다”를 정해두면 돼요. 관련 요구사항 정리는 외주 개발 보안·개인정보 요구사항을 참고해보세요.

4. 복구를 실제로 해봐야 백업이라고 말할 수 있어요

가장 중요한 기준이에요. 그리고 가장 자주 빠지는 항목이기도 해요.

백업 파일이 매일 생성되고 있어도, 그 파일이 실제로 열리는지는 열어보기 전엔 몰라요. 저희가 운영하면서 확인한 것들이에요.

• 백업은 도는데 특정 데이터가 대상에서 빠져 있는 경우
• 파일은 만들어지는데 크기가 이상하게 작은 경우
• 복구는 되는데 예상보다 훨씬 오래 걸려서, 정해둔 복구 시간 안에 못 들어오는 경우

세 가지 다 복구를 해보기 전에는 드러나지 않아요. 백업 작업이 오류 없이 끝났다는 기록만으로는 알 수 없거든요.

그래서 정기적으로 복구를 시험해요. 운영 환경이 아닌 별도 환경에 백업을 풀어보고, 데이터가 온전한지와 시간이 얼마나 걸리는지를 확인해요. 자주 할 필요는 없어요. 다만 한 번도 안 해본 상태로 두지는 않아요.

시험할 때 걸린 시간을 적어두면, 1번에서 정한 복구 목표 시간과 비교할 수 있어요. 목표보다 오래 걸리면 그때 방식을 바꾸면 돼요. 사고가 난 뒤에 알게 되는 것보다 훨씬 낫습니다.

장애가 났을 때의 대응 순서는 자체 SaaS를 운영하며 정한 장애 대응 원칙에서 따로 다뤘어요.

5. 발주할 때 적으면 좋은 네 줄

“백업 구축”이라고만 적으면 업체마다 다른 걸 떠올려요. 아래 네 줄을 요구사항에 넣으면 견적을 같은 기준으로 비교할 수 있어요.

항목	적을 내용
복구 목표 시점	사고 시 몇 시간 치까지 잃어도 되는가
복구 목표 시간	얼마 안에 되돌려야 하는가
보관	사본을 어디에 두고 며칠 치를 보관하는가
시험	복구 시험을 얼마 주기로 하고 결과를 어디에 남기는가

네 줄이면 충분해요. 그리고 이 네 줄이 있으면 견적서에서 “백업 1식”으로 뭉뚱그려진 항목을 항목별로 확인할 수 있어요. 운영 단계 비용을 함께 보는 방법은 개발 외주 3년 총비용(TCO), 무엇까지 계산해야 할까요에 정리돼 있어요.

---

마무리

백업은 평소에 아무 일도 하지 않는 것처럼 보이는 항목이에요. 그래서 예산을 줄일 때 먼저 후보에 오르곤 해요. 그런데 필요해지는 순간에는 다른 무엇으로도 대체가 안 돼요.

저희는 자체 SaaS 4종을 직접 운영하면서 이 기준을 조금씩 다듬어왔어요. 개발만 맡고 끝났다면 “백업 매일 1회”로 적고 넘어갔을 항목이에요. 직접 운영해보니 중요한 건 주기가 아니라 되돌릴 수 있는가 였어요. 10년 이상 개발을 맡아오면서, 그리고 저희 서비스를 운영하면서 확인한 방식이에요.

지금 서비스의 백업·복구 기준을 점검하고 싶으시다면 프로젝트 상담에서 편하게 여쭤봐 주세요. 서비스 상황에 맞는 기준을 함께 정리해드릴게요.