백업 작업이 매주 "성공"을 찍고 있었습니다. 그 사본으로 실제로 돌아갈 수 있는지는, 그날까지 한 번도 확인해 본 적이 없었습니다.
이 글 3줄 요약
- 백업 사본은 다른 곳에 복원해서 합격선을 통과해야 비로소 백업입니다.
- 복원 전에 "회원이 생기면 자동으로 따라 일어나는 장치"를 끄지 않으면 돈 장부가 오염됩니다.
- PASS 옆에는 검증한 범위와 숫자의 정의를 같이 적어야 다음 달의 내가 속지 않습니다.
무엇을 하다가 이 리허설을 돌렸나
제가 만들고 있는 서비스에는 선불 포인트가 오갑니다. 손님이 충전하고, 쓰고, 가입 보너스를 받는 기록이 전부 원장(돈이 들어오고 나간 순서를 줄줄이 적은 장부)에 쌓입니다. 이 원장은 매주 백업(사본을 따로 떠 두는 일)을 돌리고 있었고, 작업 결과는 늘 성공이었습니다.
그런데 어느 날 스스로 물었습니다. 운영 DB(실제 서비스가 쓰는 데이터 창고)가 통째로 날아가면 이 사본으로 정말 돌아갈 수 있나. 답을 못 했습니다. 사본을 열어 본 적도, 복원 절차를 끝까지 밟아 본 적도 없었기 때문입니다. 그래서 복원 리허설을 짰습니다.
조건을 먼저 못 박았습니다. 운영 DB 접속 0, 코드 저장소 커밋 0, 끝난 뒤 임시 파일 잔재 0입니다. 새벽 예약작업으로 코딩 AI 도구의 무인 세션이 지시서 파일을 읽고 돌며, 90분 상한을 넘기면 스스로 멈춥니다. 사람이 자는 동안 실수로 운영을 건드리는 일만은 막고 싶었습니다.
순서와 합격선을 먼저 적었습니다
순서는 이렇게 잡았습니다. 사본 신선도 게이트(백업 작업의 마지막 실행 결과가 정상인지, 표 명부 파일이 있는지, 잔액 불변식이 통과하는지) 확인. 빈 임시 DB 생성. 구조 변경 이력(마이그레이션, DB 표와 규칙을 바꿔 온 기록)을 처음부터 전량 재생. 부모 표(다른 표가 참조하는 상위 표)부터 적재. 런북(사고 때 그대로 따라 하는 절차서)에 적힌 복원 SQL 실행. 검증. 임시 DB 삭제.
핵심은 검증 기준을 돌리기 전에 정해 둔 것입니다. 합격선은 네 가지였습니다.
- 표별 건수가 사본 명부와 같을 것
- 전행 해시(모든 행을 정렬해 이어 붙인 뒤 뽑은 지문)가 원본 적재본과 복원본에서 같을 것
- 지갑별로 원장 합계와 잔액이 맞아야 하는 불변식(항상 참이어야 하는 규칙) 위반이 0건일 것
- 제약과 인덱스(DB가 데이터를 지키고 찾는 장치) 개수가 원본과 같을 것
한 가지 규칙을 더 걸었습니다. 계속 늘어나는 표에 고정 숫자 기준선을 쓰지 않습니다. 이번 리허설의 건수는 다음 리허설의 합격 기준이 아닙니다. 기준은 늘 "그날 사본의 명부"입니다.
보고서 양식에도 장치를 넣었습니다. 요약, 수치 표, 그리고 "실패 / 의심 항목" 칸을 반드시 채우게 했습니다. 이 칸이 없으면 AI는 PASS 한 줄만 쓰고 끝냅니다. 칸이 있으니 아래에 적을 함정들을 스스로 적어 왔습니다.
틀어진 것 하나, 복원 전에 끄지 않은 자동 장치
첫 함정은 트리거(DB에 어떤 행이 들어오면 자동으로 다른 일을 따라 일으키는 장치)였습니다. 이 서비스는 회원이 생기면 지갑을 만들고, 가입 보너스를 넣고, 거래 행을 적는 일이 자동으로 따라 일어납니다. 운영에서는 고마운 기능입니다. 복원할 때는 독입니다.
복원은 회원 표에 계정 스텁(뼈대 행)부터 넣고, 그다음에 지갑과 거래를 사본대로 채우는 순서입니다. 트리거가 켜진 채로 스텁을 넣으면 사본을 채우기도 전에 지갑과 보너스와 거래가 새로 생깁니다. 원장이 오염됩니다. 건수도 해시도 맞을 리 없습니다.
그래서 트리거를 끄는 단계를 넣었고, 껐다는 사실을 말이 아니라 숫자로 증명하게 했습니다. 스텁을 넣은 직후 하위 표를 세어 0/0/0/0이 찍히면 꺼진 것입니다. 이 한 줄이 로그에 없으면 그 뒤의 PASS는 믿을 수 없습니다.
틀어진 것 둘, 리허설 도구가 먼저 멈췄습니다
1차 실행은 STOP으로 끝났습니다. 데이터가 아니라 리허설 스크립트 자체의 버그였습니다. 문자형 컬럼을 다른 문자열과 이어 붙이는 자리에서 자료형이 애매하다며 DB 엔진이 거부했습니다. 형변환 하나를 더해 2차 실행에서 PASS가 났습니다. 그 수정은 자동 검사를 전부 돌려 실패 0을 확인한 뒤에도 커밋하지 않고, 사람이 보는 다음 세션으로 넘겼습니다.
여기서 배운 게 있습니다. 리허설은 데이터만 시험하는 게 아니라 복구 도구도 시험합니다. 사고 당일에 처음 돌리는 도구는 거의 반드시 어딘가에서 멈춥니다. 평소에 멈춰 봐야 사고 날에 안 멈춥니다. 1차 STOP 때도 임시 DB는 정상적으로 정리돼 잔재 0이었습니다. 멈추더라도 뒤처리는 되는 구조였다는 점이 그나마 위안이었습니다.
틀어진 것 셋, "RTO 78분"이라는 숫자
지시서에 RTO(복구 목표 시간, 사고 뒤 서비스를 다시 세우기까지 걸리는 시간)를 재라고 적어 두었습니다. 정의는 "사본 시각에서 복원 완료까지"였습니다. 결과는 78분이었고 그대로 보고서에 적혔습니다.
그런데 절차 자체는 19초 남짓이었습니다. 78분 대부분은 백업이 끝난 뒤 예약작업이 돌 때까지 기다린 70분과 준비 7분입니다. 정의를 기계적으로 적용한 숫자라 틀린 건 아닙니다. 그래도 이 숫자만 보면 "복구에 78분이나 걸리는구나"라고 오해합니다. 사고 당일이라면 사본을 확보한 직후 분 단위로 끝날 일입니다.
그래서 보고서에 두 줄을 나란히 적었습니다. 정의대로 잰 숫자, 그리고 그 숫자가 무엇으로 이루어졌는지. 정작 중요한 "목표 복구 시간을 몇 분으로 할지"는 제가 아직 정하지 않았다는 것도 숙제로 남겼습니다. 숫자를 재는 일은 AI가 하지만, 목표를 정하는 일은 대표의 몫이라는 걸 그때 알았습니다.
PASS가 말해 주지 않는 것
이번 PASS의 범위는 돈 원장 표와 그 부모 표까지입니다. 알림·이벤트 같은 운영 표, 파일 저장소, 로그인 실물, 서버 쪽 함수는 검증하지 않았습니다. 그래서 보고서 끝에 "이 PASS는 복원 절차가 실제로 돈다는 것과 제약 복사가 실증됐다는 것까지"라고 범위를 적었습니다.
PASS 옆에 범위를 적지 않으면 다음 달의 제가 속습니다. 초록불 하나가 전체를 보증한다고 믿게 됩니다. 조용한 실패를 다룬 이전 글과 같은 맥락입니다. 성공 표시는 "무엇을" 성공했는지와 붙어 있어야 의미가 있습니다.
현장 인사이트
백업은 파일이 아니라 절차입니다. 다른 곳에 복원해서 합격선을 넘긴 날이 진짜 백업이 생긴 날입니다.
오늘 바로 해 볼 것
꼭 DB가 아니어도 됩니다. 매출 엑셀, 고객 명단 시트, 발주 장부 전부 같습니다.
- 사본이 어디에 있고 마지막으로 언제 만들어졌는지 한 줄로 말해 봅니다. 못 하면 거기서부터입니다.
- 운영 중인 파일 말고 빈 컴퓨터나 새 시트에 그 사본을 열어 봅니다.
- 열기 전에 "맞다"의 기준을 적습니다. 행 수, 합계, 마지막 행의 날짜 정도면 시작으로 충분합니다.
- 복원하면 자동으로 따라 일어나는 일(알림 발송, 자동 메일, 포인트 적립)을 먼저 끄거나 끊습니다.
- 결과 옆에 "확인한 범위"와 "숫자의 정의"를 적습니다.
코딩 AI 도구에 리허설을 맡기려면 아래를 붙여 넣고 시작하면 됩니다.
백업 복원 리허설 스크립트를 만들어 주세요. 조건은 다음과 같습니다.
- 운영 DB에는 절대 접속하지 않습니다. 임시 로컬 DB를 새로 만들고 끝나면 삭제합니다.
- 순서: 사본 신선도 확인(마지막 백업 결과·명부 파일 존재·잔액 규칙 통과) → 빈 DB 생성 → 구조 변경 이력 전량 재생 → 부모 표부터 적재 → 런북의 복원 SQL 실행 → 검증 → 임시 DB 삭제
- 회원 생성 시 자동으로 지갑·보너스를 만드는 트리거는 적재 전에 끄고, 껐다는 증거(하위 표 0건)를 로그에 남깁니다.
- 합격선: 표별 건수 = 명부, 원본 적재본과 복원본의 전행 해시 동일, 지갑별 잔액 규칙 위반 0, 제약·인덱스 개수 동일
- 하나라도 어긋나면 STOP으로 끝내고 이유를 한 줄로 적습니다. 보고서에 "실패 / 의심 항목" 칸을 반드시 둡니다.
- 로그의 개인정보는 가립니다.
프롬프트 한 장으로 끝나지는 않습니다. 저도 첫 판은 도구 버그로 멈췄습니다. 그래도 멈춘 자리가 보이면 고칠 수 있습니다. 백업이 "성공"만 찍는 동안에는 고칠 자리조차 보이지 않습니다. 다음 리허설 날짜를 달력에 넣는 것까지가 제 숙제로 남아 있습니다.