외주 개발이 끝나면 코드 저장소·도메인·인프라는 비교적 깔끔하게 인계되는데, 정작 "운영 중인 데이터베이스"는 끝까지 남아 사고를 일으킵니다. 외주 인계에서 반복적으로 관찰되는 패턴을 정리하면 이렇습니다. 외주사가 직접 만든 RDS/Postgres에 운영 데이터가 6개월 동안 쌓여 있고, ALTER TABLE 한 번이 어드민 화면을 깨뜨리는데 그 마이그레이션 스크립트는 외주 개발자 노트북에만 남아 있어요. 1주일 동안 결제 환불이 막히고, 다음 회사 개발자는 "어떻게 운영했는지 모르겠다"고 합니다.
2026년 들어서는 변수가 더 추가됐어요. AI 코딩 도구가 외주 단계에서 자동 생성한 마이그레이션이 운영 DB에 쌓였는데, "그 변경이 왜 들어갔는지" 설명해 줄 사람이 외주사에서 이미 퇴사한 케이스가 분기마다 늘고 있어요. 클라우드 인프라 인계 가이드가 결제·계정·도메인 4 레이어를 다뤘다면, 이 글은 그 위에 운영 데이터를 안전하게 옮기는 7단계를 채웁니다.
제일 먼저 해야 할 건 "우리 서비스에 데이터가 몇 군데에 흩어져 있는지" 한 줄짜리 표로 만드는 거예요. 주 DB(Postgres·MySQL)·읽기 복제본·캐시(Redis)·검색 엔진(Elasticsearch/OpenSearch)·임베딩 벡터 DB(pgvector·Pinecone·Weaviate)·파일 스토리지(S3/GCS)·로그(CloudWatch/Datadog)·외부 SaaS(Stripe·Mixpanel·Amplitude) 8개 카테고리를 표로 정리하세요.
각 항목에 대해 4가지를 채웁니다. ① 데이터 양(GB)·② 일일 쓰기/읽기 비율·③ 보존 기간·④ 개인정보 포함 여부(주민등록번호·핸드폰 번호·이메일·주소 등). 이 표가 없으면 인계 견적이 50%씩 흔들려요. PIPA 23·24조 대상 데이터가 어디에 있는지 모르면 이전 자체가 위법 위험을 안고 시작합니다.
인계 시작 시점부터는 외주사가 운영 DB의 스키마를 못 바꾸게 잠가야 해요. Flyway·Liquibase·Prisma Migrate·Alembic 같은 마이그레이션 도구의 history 테이블을 export해서 발주사 Git 저장소에 백업합니다. 외주 개발자 노트북에만 남은 ad-hoc ALTER TABLE이 있으면 D-14에 다 정리해서 정식 마이그레이션 스크립트로 변환하세요.
여기서 자주 터지는 사고가 두 가지예요. 외주사가 "프로덕션에서 직접 SQL을 돌려버렸다"는 케이스(이게 분쟁 30%의 원인입니다), 그리고 마이그레이션 도구는 있는데 "1년 전 마지막 마이그레이션 이후로는 모두 콘솔에서 직접 변경"한 케이스. 양쪽 다 D-14에 들어내지 않으면 D-Day 이후 영구 부채가 됩니다.
데이터 이전 자체가 PIPA 28조 안전조치 의무·전자상거래법 18조 보존 의무에 걸리기 시작해요. 주민등록번호·운전면허·여권 같은 고유식별정보는 별도 테이블에 분리·암호화되어 있어야 합니다. 외주사가 운영 DB에 평문으로 쌓아 둔 케이스가 분기마다 1건은 나와요. 이전 직전에 발견하면 마이그레이션 스크립트를 추가로 돌려서 KMS/HSM 키로 재암호화한 다음 옮겨야 합니다.
감사 로그도 같이 점검하세요. 로그인·결제·환불·관리자 행위 4종은 최소 3년치 보존이 안전합니다. 외주사가 30일짜리 CloudWatch만 켜둔 경우 이전 시점에 통째로 사라지는 사고가 흔해요. 이전 1주일 전부터 발주사 어카운트의 로그 서비스로 동시 적재(fan-out)를 시작해서 감사 추적성을 끊지 마세요.
본 이전 1주일 전에 반드시 스테이징 환경에서 실제 데이터 양으로 1번 리허설을 합니다. 측정해야 할 항목은 4가지예요.
리허설 없이 D-Day로 직행하면 결제 데이터 0.1% 누락 같은 사고가 발견되는 순간 환불·정산 분쟁으로 직결돼요. 푸드테크 클라이언트 한 곳은 리허설을 건너뛰었다가 사용자 1,200명의 적립금이 0으로 리셋되는 사고로 ₩2,800만 보상을 부담했습니다.
실제 이전은 패턴이 정해져 있어요. (A) 무중단 — Postgres logical replication·AWS DMS·GCP DMS로 새 DB에 실시간 복제, 검증 후 애플리케이션 커넥션 스트링만 갈아끼움. (B) 짧은 다운타임 — read-only 모드 → 마지막 증분 동기화 → 새 DB로 트래픽 전환. (C) 계획 다운타임 — pg_dump/mysqldump 후 restore(가장 단순하지만 다운타임 ≥ 2시간).
한국 서비스는 새벽 1~5시 다운타임이 비교적 안전합니다. 결제 PG·OAuth(카카오·네이버·구글) 콜백 URL이 새 도메인이면 사전 등록도 D-Day 전에 끝내세요. 도메인·DNS·SSL은 클라우드 인프라 인계 가이드의 6단계에서 다룬 절차를 그대로 따르면 됩니다.
이전 직후 24~72시간이 가장 위험해요. 발주사 + 외주사 양쪽 엔지니어가 4-Eyes로 검증 쿼리 결과를 비교하고 사인오프 문서에 둘 다 서명합니다. 누락 0건·오류 0건이 확인되어야 잔금이 풀려요. 검증 항목은 4가지예요. 핵심 카운트(사용자·주문·결제·콘텐츠) 일치 여부, 시계열 합계(최근 30·90·365일 매출) 일치 여부, 외래키 무결성 위반 0건, 무작위 샘플 100건의 전체 필드 일치 여부.
이 사인오프가 끝나기 전에는 외주사가 원본 DB를 삭제하지 못하게 합니다. 30~60일은 read-only 백업으로 살려두고, 발주사가 명시적으로 삭제 사인오프를 한 다음에야 외주사가 인스턴스를 종료해요.
마지막 단계는 명의·접근권 회수예요. 외주사 IAM 사용자/Service Account/IRSA 키를 회수하고, RDS master password·접속 가능 IP·VPC peering을 정리합니다. 외주사 노트북·NAS·Slack 첨부파일에 남은 export 파일도 14일 이내 삭제 인증서를 받으세요.
이 단계에서 자주 빠지는 항목 6가지를 체크리스트로 둡니다. ① RDS 자동 백업 IAM 권한, ② Snowflake/BigQuery 외부 공유 링크, ③ Mongo Atlas Database User, ④ Redis Replication AUTH, ⑤ Stripe/포트원 API 읽기 키, ⑥ Mixpanel/Amplitude API 키. NDA·기밀유지 계약 가이드의 14일 삭제 인증서 조항을 그대로 붙이면 분쟁 시점이 명확해져요.
이전 직후 데이터 사고가 발생하면 외주사가 복귀해야 할 때가 있어요. 계약서에 D+30·D+60·D+90 비상 SLA(₩180,000~220,000/시간 + 24시간 응답·48시간 완료)를 박아두면, "이미 끝난 프로젝트"라는 핑계 없이 복귀시킬 수 있어요. 외주사 입장에서도 단가가 명시되어 있어 분쟁이 없습니다.
외주 개발의 진짜 자산은 코드가 아니라 운영 데이터예요. 코드는 6주에 다시 짤 수 있지만, 6개월치 결제·사용자·로그 데이터는 다시 만들 수 없습니다. 7단계 인계를 D-21부터 시작하지 않으면, 다음 외주사·내부 개발팀이 들어왔을 때 첫 분기를 데이터 부채 회복에만 쓰게 돼요.
포텐랩은 97% 수행완수율을 유지하면서 데이터 인계를 표준 인수인계 단계로 묶어 운영해왔어요. 포텐랩에 외주 데이터 인계 점검을 의뢰하면 D-21 인벤토리부터 D+60 권한 회수까지 7단계 표준 체크리스트와 검증 쿼리 템플릿을 함께 제공합니다. 다음 분기에 외주사를 교체하거나 내부 개발팀으로 운영을 전환할 계획이라면, 인계 견적은 결국 데이터 인계 7단계가 다 들어가 있는지로 갈립니다.