데이터 백업·복구, 외주 견적에 어디까지 넣을까요 | 7가지 기준

핵심 요약

• 백업 파일이 있는 것과 서비스를 실제로 되살릴 수 있는 것은 달라요. 확인은 복구 테스트로만 돼요.
• RPO(얼마나 전 데이터까지 잃어도 되나)·RTO(몇 시간 안에 다시 열어야 하나) 두 숫자를 먼저 정하면 백업 주기와 비용 범위가 따라 정해져요.
• 개인정보 안전성 확보조치 기준 제11조는 일정 규모 이상 사업자에게 백업·복구 계획 마련을 요구해요.
• 2017년 국내 호스팅 업체 사고에선 백업 서버를 포함한 서버 153대가 랜섬웨어에 감염됐어요. 같은 곳에 둔 백업은 같이 잠길 수 있어요.

“서버는 클라우드니까 백업은 알아서 되는 거 아니에요?”

유지보수 견적을 이야기할 때 자주 듣는 질문이에요. 견적서에도 “백업 포함” 한 줄로만 적혀 있는 경우가 많고요. 그런데 사고가 난 날 필요한 건 백업 파일이 아니라 몇 시간 안에 어느 시점으로 돌아갈 수 있느냐예요. 이 글은 백업·복구를 외주 견적과 계약에 어디까지 넣어야 하는지 발주 전에 정리할 수 있게 적었어요.

---

1. 백업이 있는데 왜 복구가 안 될까요

현장에서 복구가 막히는 이유는 대개 셋이에요.

• 백업이 같은 곳에 있어요. 운영 서버와 같은 계정, 같은 권한으로 접근되는 백업은 랜섬웨어나 권한 탈취가 한 번에 같이 가져가요.
• 데이터베이스만 백업했어요. 사용자가 올린 이미지·첨부파일, 설정 파일, 암호화 키가 빠져 있으면 데이터는 돌아와도 서비스가 안 열려요.
• 한 번도 되살려 본 적이 없어요. 백업 작업은 매일 “성공”인데 막상 복원하면 버전이 안 맞거나 몇 시간이 걸리는지 아무도 몰라요.

실제 사례도 있어요. 2017년 6월 국내 웹호스팅 업체 인터넷나야나는 웹 서버와 백업 서버 153대가 리눅스용 랜섬웨어에 함께 감염됐고, 당시 보도 기준 연결된 홈페이지 3,348개가 피해를 입었어요. 정부 중간조사는 지능형 지속 공격(APT)과 랜섬웨어가 결합된 공격으로 발표했고요.

공식 외부 기준 — 정부 브리핑(대한민국 정책브리핑) 중간조사 발표와 당시 IT 전문지 보도를 기준으로 했어요. 피해 규모는 보도 시점 수치예요.

2. RPO·RTO, 무엇부터 정해야 할까요

백업 이야기는 기술보다 숫자 두 개에서 시작해요.

용어 박스 — RPO와 RTO RPO(Recovery Point Objective, 복구 시점 목표) 는 사고가 났을 때 최대 얼마 전 데이터까지 잃어도 되는지예요. RPO가 24시간이면 하루치 주문이 사라져도 감수한다는 뜻이에요. RTO(Recovery Time Objective, 복구 시간 목표) 는 사고 뒤 몇 시간 안에 서비스를 다시 열어야 하는지예요. 연락받는 시간이 아니라 다시 쓸 수 있게 되는 시간이에요.

두 숫자가 짧아질수록 방식이 바뀌어요. 하루 한 번 백업이면 되던 게 수시 로그 백업이 되고, 백업을 되살리는 방식에서 대기 서버를 미리 띄워 두는 방식으로 넘어가요. 비용이 가장 크게 갈리는 지점이 여기예요.

기능별로 따로 정하는 게 요령이에요. 결제·주문 데이터는 짧게, 공지사항이나 통계 화면은 길게 잡으면 전체를 짧게 맞출 때보다 부담이 줄어요. 장애 등급과 복구 시간을 나누는 법은 장애 대응·모니터링, 발주 전에 숫자로 정할 6가지에 따로 정리해 뒀어요.

3. 백업 주기와 보관 기간은 어떻게 정할까요

외부 기준과 실무 기준을 나눠서 보면 정하기 쉬워요.

구분	내용	출처 유형
법적 요구	이용자 10만 명 이상 개인정보를 처리하는 대기업·중견기업·공공기관, 100만 명 이상을 처리하는 중소기업 등은 화재·홍수·정전 같은 재해에 대비해 위기 대응 매뉴얼과 백업·복구 계획을 마련해야 해요	개인정보의 안전성 확보조치 기준 제11조
보관 원칙	중요 백업본은 오프라인 보관 또는 떨어진 장소에 소산 보관을 권고해요	KISA 랜섬웨어 대응·백업 가이드
클라우드 기본값	AWS RDS 자동 백업 보관 기간은 콘솔 기본 7일, 설정 가능한 최대 35일	AWS 공식 문서

설계 출발점 예시	일반 기업 사이트	회원·주문이 있는 서비스
RPO 출발점	24시간	수 분~1시간 (로그 백업)
RTO 출발점	1영업일	수 시간
보관	일간 7일 + 월간 몇 개월	일간 + 주간 + 월간 단계 보관
복구 테스트	반기 1회	분기 1회

두 번째 표는 논의를 시작하기 위한 출발점 예시예요. 통계나 정해진 기준이 아니라서 업종 규제, 데이터 양, 예산에 따라 달라져요.

보관 기간은 “오래 둘수록 안전”이 아니에요. 개인정보는 목적이 끝나면 파기해야 해서 백업본에도 파기 기준이 있어야 해요. 탈퇴한 회원 정보가 1년짜리 백업에 그대로 남는 구조라면 보관 기간부터 다시 봐야 해요.

4. 클라우드 기본 백업만으로 충분할까요

기본 백업은 좋은 출발점이지만 발주사가 기대하는 범위와 다를 때가 많아요.

• 보관 기간 한계 — 자동 백업은 설정한 기간이 지나면 지워져요. 몇 달 전 시점이 필요하면 수동 스냅샷이나 별도 백업 정책이 있어야 해요.
• 같은 계정 안 — 기본 백업은 대개 운영 계정 안에 있어요. 계정이 탈취되거나 실수로 인스턴스를 지우면 함께 영향을 받을 수 있어서, 다른 계정·다른 지역에 복사본을 두는 설정을 따로 해야 해요.
• 데이터베이스만 — 파일 저장소, 검색 인덱스, 서버 설정은 각각 따로 챙겨야 해요.
• 요금 — 보관 용량과 기간, 지역 간 복사에 비례해 요금이 붙어요. 서버비와 섞이면 안 보이니 따로 적어 두세요.

계정 명의와 클라우드 요금 구조는 개발 외주 서버·인프라 비용, 누가 얼마나 낼까요에서 함께 보면 좋아요.

우리 서비스의 RPO·RTO를 아직 못 정했다면 기능 목록부터 같이 나눠 볼 수 있어요. 어느 데이터를 짧게 지켜야 하는지 정하면 백업 비용 범위가 보여요. 우리 서비스 백업·복구 범위 상담받기 →

5. 랜섬웨어와 실수 삭제, 대비가 어떻게 다를까요

둘 다 “데이터가 사라진다”는 결과는 같지만 막는 방법이 달라요.

구분	실수 삭제·잘못된 배포	랜섬웨어·계정 탈취
흔한 모습	조건 없는 삭제 쿼리, 잘못된 데이터 일괄 수정	운영 서버와 백업이 함께 암호화
필요한 것	짧은 간격의 시점 복구, 배포 전 백업	운영 권한으로 지울 수 없는 분리 보관
권한 설계	운영 DB 쓰기 권한 최소화	백업 삭제 권한을 별도 계정·다른 사람에게
확인 질문	”오늘 오후 2시 상태로 되돌릴 수 있나요?"	"운영 관리자 계정이 털려도 백업은 남나요?”

KISA도 랜섬웨어 대응 자료에서 백업을 오프라인이나 떨어진 장소에 따로 보관하라고 권고해요. 흔히 쓰는 원칙이 3-2-1이에요. 복사본 3개, 서로 다른 저장 매체 2곳, 그중 1개는 다른 장소에 두는 방식이에요.

운영사 Tip — 자체 SaaS를 운영해 보면 큰 사고는 해킹보다 사람 손에서 더 자주 시작돼요. 급한 데이터 수정을 운영 DB에 바로 치는 순간이 가장 위험하죠. 그래서 운영 데이터를 고치기 전에 그 범위를 먼저 백업해 두고, 백업 삭제 권한은 평소 쓰는 계정과 분리해 두는 편이 좋아요. 비용은 거의 안 드는데 복구할 수 있는 선택지가 크게 늘어요.

6. 복구 테스트는 누가, 얼마나 자주 해야 할까요

복구 테스트는 운영과 분리된 환경에 백업을 되살려 서비스가 열리는지 확인하는 일이에요. 적어도 세 가지는 기록으로 남겨야 해요.

1. 어느 시점 백업을 썼나요
2. 서비스가 열리기까지 실제로 몇 시간 걸렸나요 — 이 값이 RTO를 지킬 수 있는지 알려줘요
3. 빠진 데이터나 깨진 기능이 있었나요

비용 감도 잡아 볼게요. 한국소프트웨어산업협회가 공표한 2026년 응용SW 개발자 일평균임금은 37만 8,250원이에요. 개발자 한 명이 반기마다 하루씩 복구 테스트를 하면 1년에 임금 기준 약 76만 원이에요(계산 예시, 경비·이윤과 테스트 환경 요금 별도). 서비스 규모에 따라 이틀이 걸릴 수도 있으니, 이 숫자는 견적 기준보다 “복구 테스트 공수를 며칠로 잡았나요?”를 묻는 근거로 쓰세요.

테스트용 환경을 따로 두는 이유는 개발·스테이징·운영 서버, 왜 여러 개가 필요할까요에 정리해 뒀어요.

7. 견적서·유지보수 계약에 어떤 문장을 적어야 할까요

“백업 포함” 한 줄 대신 아래 7줄에 답이 있는지 확인해 보세요.

1. 목표 — 기능별 RPO·RTO가 숫자로 적혀 있나요?
2. 대상 — 데이터베이스 말고 파일 저장소·설정·암호화 키도 들어가나요?
3. 주기·보관 — 백업 간격과 보관 기간, 파기 기준이 있나요?
4. 분리 보관 — 운영 계정 권한으로 지울 수 없는 복사본이 어디에 있나요?
5. 복구 테스트 — 몇 달에 한 번, 누가 하고, 결과를 어떻게 보고하나요?
6. 명의·요금 — 백업 저장소 계정과 요금은 누구 이름으로 나가나요?
7. 구축과 유지보수의 경계 — 오픈 전 백업 설계는 구축 견적, 오픈 뒤 점검·테스트는 유지보수 계약 중 어디에 들어가나요?

7번이 빠지면 오픈 직후부터 유지보수 계약 전까지 아무도 백업을 책임지지 않는 공백이 생겨요. 유지보수 범위를 나누는 기준은 유지보수 계약(SLA), 어디까지 넣어야 할까요에서 이어서 보세요.

백업·복구는 사고가 난 날 처음 꺼내 보면 늦어요. 지금 서비스에서 어떤 데이터가 가장 아픈지만 알려주시면 RPO·RTO 출발점과 견적에 넣을 문장을 같이 정리해 드릴게요. 백업·복구 범위를 견적 전에 함께 정해볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 맡아 왔고 자체 SaaS 4종을 직접 운영하고 있어요. 롯데·캐논 같은 곳과도 함께했고요. 오픈 뒤에도 서비스를 계속 운영하는 입장이라, 백업이 “있는지”보다 “되살아나는지”가 더 중요하다는 걸 알아요.

8. 자주 묻는 질문

클라우드를 쓰면 백업은 따로 신경 안 써도 되나요?

신경 써야 해요. 예를 들어 AWS의 관리형 데이터베이스(RDS) 자동 백업은 보관 기간을 정해 쓰는 구조이고 최대 35일까지만 설정돼요. 그보다 오래 보관하거나 다른 계정·다른 지역에 복사본을 두는 일, 파일 저장소 백업, 복구 연습은 서비스를 만드는 쪽이 따로 설계해야 해요.

RPO와 RTO는 무엇이고 왜 먼저 정해야 하나요?

RPO(복구 시점 목표)는 사고가 났을 때 최대 몇 시간 전 데이터까지 잃어도 되는지, RTO(복구 시간 목표)는 몇 시간 안에 서비스를 다시 열어야 하는지예요. 이 두 숫자가 백업 주기, 보관 방식, 대기 서버 여부를 정하기 때문에 비용 범위도 여기서 갈려요.

백업이 제대로 되는지는 어떻게 확인하나요?

백업이 성공했다는 알림만으로는 알 수 없어요. 실제로 별도 환경에 백업을 되살려 서비스가 열리는지, 데이터가 맞는지, 몇 시간이 걸렸는지 확인하는 복구 테스트를 주기적으로 해야 해요. 누가, 얼마나 자주, 결과를 어떻게 보고할지 유지보수 계약에 적어 두세요.

9. 마무리

백업 비용은 저장 용량보다 RPO·RTO를 얼마나 짧게 잡느냐에서 갈려요. 기능별로 숫자를 나누고, 운영 권한으로 못 지우는 곳에 복사본을 두고, 반기에 한 번이라도 실제로 되살려 보면 “백업 포함” 한 줄보다 훨씬 믿을 수 있는 계약이 돼요.

다음 견적서를 받으면 위 7줄부터 확인해 보세요. 비어 있는 줄이 사고 난 날 가장 오래 걸리는 부분이에요.

함께 보면 좋은 글

• 지금 개발사와 헤어져도 서비스가 돌까요 | 계약 전 확인할 6가지
• 데이터 이관은 왜 따로 견적을 받아야 할까요
• 개발 외주 보안·개인정보 요건