외주 인계에서 무게중심은 코드보다 데이터 쪽에 있어요. 코드는 저장소를 넘겨받으면 그대로 남지만, 데이터는 백업·키·복원 절차가 함께 넘어오지 않으면 넘겨받은 시점에 이미 손상돼 있어도 알아챌 방법이 없거든요. 인계 현장에서 반복적으로 관찰되는 실패 모드는 두 가지입니다. "백업이 있는 줄 알았는데 없었다", 그리고 "백업은 있는데 복원이 안 됐다". 둘 다 인계가 끝난 뒤 첫 장애가 났을 때에야 드러나요. 백업·복원이 준비되지 않은 채로 인계가 종료되면 복구가 시간 단위가 아니라 며칠 단위로 길어질 수 있습니다.
이 문제가 커지고 있는 이유는 3가지예요. (1) AI 코딩으로 PR과 마이그레이션이 잦아지면서 백업·롤백을 걸어야 할 시나리오가 늘었고, (2) Supabase/Firebase/Neon 같은 서드파티 DB가 표준이 되면서 "관리형이니까 안전하다"는 착각이 퍼졌고, (3) CI·배포·호스팅을 단일 벤더에 전량 의존하면 그 벤더가 흔들리는 순간 대체 경로가 아예 없어요. 관리형 서비스는 하드웨어·인프라 장애로부터는 지켜주지만, 잘못된 DELETE나 down 없이 머지된 마이그레이션으로부터는 지켜주지 않습니다. 백업·복구는 "당연한 줄 알았던 것"에서 "계약서에 박아두는 것"으로 이동해야 해요.
RPO(데이터 손실 허용 시간)와 RTO(복구 목표 시간)를 계약서에 숫자로 적으세요. 일반 SaaS는 RPO 1시간·RTO 4시간이 흔한 기준이고, 결제·인증·예약처럼 손실이 즉시 매출 손실로 이어지는 서비스는 RPO 5분·RTO 1시간 수준으로 잡습니다. 여기서 정한 숫자가 이후 백업 주기·복제 방식·드릴 빈도를 전부 결정해요. "백업합니다"는 합의가 아니라 의지 표현입니다.
3개 복사본·2개 다른 매체·1개 오프사이트의 3-2-1 규칙은 30년 된 표준이지만 여전히 안 지켜져요. 다음 3가지를 외주사 산출물에 강제하세요.
pg_dump·mongodump) 복제핵심은 "다른 계정"이에요. 같은 계정 안에만 사본이 있으면 계정 자체가 잠기거나 권한이 회수되는 순간 사본 세 개가 동시에 사라집니다.
백업이 돌고 있다는 사실과 그 백업으로 실제 복원이 된다는 사실은 별개예요. 스냅샷 잡이 성공했다는 로그는 파일이 만들어졌다는 뜻이지, 그 파일로 서비스가 다시 선다는 뜻이 아닙니다. 복원 드릴을 한 번도 해보지 않았다면 복원 가능 여부는 아직 확인된 게 아니에요. 인계 30일째와 90일째에 스테이징 환경에 실제 복원 1회씩 의무로 잡으세요. 복원 시간·데이터 정합성·시퀀스/인덱스 회복까지 보고서 1장으로 받으세요. 안 받으면 잔금 보류가 표준이에요.
백업이 암호화되어 있는데 KMS 키가 외주사 계정에 있으면, 백업이 있어도 못 풉니다. AWS KMS·GCP KMS·Supabase Vault·1Password 4종 키 매트릭스를 작성하세요. 컬럼명·테이블명·KMS key ARN·키 소유자·접근 권한자·rotation 주기까지 1장으로 정리합니다. 결제·주민번호·의료기록은 추가로 PIPA 23·24·28조 준수 항목을 묶으세요.
Supabase Migrations·Prisma Migrate·Alembic·Flyway 등 어떤 도구를 쓰든 up.sql과 down.sql(또는 동치)이 같이 있어야 합니다. down 스크립트 없이 머지된 마이그레이션은 롤백 경로 자체를 지워버려요. AI 코딩으로 마이그레이션 작성이 쉬워질수록 down 을 빼먹은 건이 섞여 들어오기 쉬운데, 이건 인계받자마자 사고의 도화선이 됩니다. 사람 눈으로 세지 말고 git ls-files migrations/ 한 줄로 모든 마이그레이션에 down 파일이 짝지어 있는지 기계적으로 검증하세요. 짝이 없는 파일이 하나라도 나오면 그 목록 자체를 인계 조건에 넣습니다.
외주사가 떠난 뒤 1주 안에 회전해야 할 자산을 명시하세요. Supabase service_role, AWS access keys, Toss/Stripe secret, OpenAI/Anthropic API keys, Slack/Sentry/Datadog 토큰, GitHub Personal Access Token, SSL 인증서, OAuth client secret 등이 표준 8종이에요. 회전 우선순위·다운타임 윈도우·롤백 절차까지 SOP 1장으로 합의합니다.
인계 후 30일 안에 다음 4가지 시나리오에 대한 런북을 받으세요. (가) DB 단일 리전 장애 → 다른 리전 PITR 복구 절차, (나) 데이터 손실(잘못된 마이그레이션·실수 DELETE) → 시점 복구 절차, (다) 인프라 벤더 장애(Supabase/Vercel/AWS) → 우회 또는 트래픽 전환 절차, (라) 보안 사고(키 유출·계정 침해) → 격리+회전+포렌식 절차. 각 런북은 30분 안에 1차 대응 가능한 수준으로 작성되어야 해요.
잔금 지급 조건에 다음 12자산 100% 인계를 명시합니다. ① RPO/RTO 합의서, ② 3-2-1 백업 구조도, ③ KMS 키 매트릭스, ④ 마이그레이션 + 롤백 스크립트 git 일치, ⑤ 시크릿 회전 SOP, ⑥ 4종 재해 런북, ⑦ 30일/90일 복원 드릴 보고서, ⑧ 데이터 ERD + 백업 대상 테이블 리스트, ⑨ 콜드 아카이브 위치·접근 권한, ⑩ 백업 모니터링/실패 알림 채널, ⑪ 30일 hot-patch SLA, ⑫ 외주사 떠난 뒤 60일 비상 컨택 3인. 운영 SLO·온콜 인수 가이드와 짝으로 보세요.
아래는 특정 사건 기록이 아니라, 위 8항목 중 어떤 것을 빼먹었을 때 어떤 결과로 이어지는지를 유형별로 정리한 것이에요. 서비스 종류마다 먼저 터지는 자리가 다릅니다.
백업·DR 을 인계 시점에 실제로 검증되게 만드는 장치는 결국 한 줄이에요. 잔금 지급 조건을 백업·복원·키 인계와 묶어두는 것입니다. 문서로만 요구하면 문서만 오고, 잔금과 묶으면 그 시점에 실물이 확인돼요. 포텐랩은 이 조건을 계약서에 넣은 상태로 프로젝트를 인수하고 있고, 수행완수율 97%를 유지하고 있어요. 외주 견적·계약 단계부터 백업·DR을 같이 점검하고 싶으시면 포텐랩 상담으로 30분이면 8항목 체크리스트 점검해드려요. 포텐랩 포트폴리오에서 실제 인계 사례 보실 수 있어요.