제 경력의 대부분 동안, 저는 한 번도 복구해 본 적 없는 백업들을 가지고 있었습니다. 백업 작업은 매일 밤 실행되었습니다. 매일 아침 초록색 체크 표시가 나타났습니다. 스토리지 버킷(storage bucket)은 올바른 이름과 대략적으로 적절한 크기를 가진 파일들로 채워졌습니다. 저는 그 모든 것을 보고 데이터가 안전하다고 스스로에게 말했습니다. 제가 결코 하지 않았던 일은, 그 파일 중 하나를 가져와 깨끗한 데이터베이스(database)에 복구하고, 그 결과가 프로덕션(production)의 작동하는 복사본인지 확인하는 것이었습니다. 저는 체크 표시를 신뢰했지만, 그 체크 표시는 잘못된 것을 측정하고 있었습니다.

체크 표시는 백업 작업이 실행되었는지를 측정하는 것이지, 백업이 복구될 수 있는지를 측정하는 것이 아니었습니다. 이 둘은 완전히 다른 질문이며, 그 사이의 간극에 재앙이 존재합니다. 백업 작업은 미묘한 형식 변경, 누락된 테이블, 복구 경로의 권한 문제, 또는 더 이상 존재하지 않는 암호화 키(encryption key) 때문에 1년 내내 매일 밤 완벽하게 실행되면서도 복구할 수 없는 1년 치의 파일들을 만들어낼 수 있습니다. 백업이 작동하는지 알 수 있는 유일한 방법은 그것을 복구해 보는 것이지만, 선택의 여지가 없는 날이 오기 전까지 백업을 복구하는 사람은 거의 없습니다.

Claude Code는 복구 검증을 재난 복구(disaster recovery) 훈련 중에 일 년에 한 번 있을 법한 영웅적인 노력(혹은 아예 일어나지 않는 일)이 아니라, 백업 워크플로(workflow)의 일상적이고 자동화된 부분으로 만듦으로써 그 간극을 메울 수 있게 해주었습니다. 백업은 여전히 기존 도구들에 의해 수행됩니다. 바뀐 점은 이제 모든 백업이 생성된 직후에 복구 가능함이 증명되며, 그 증거가 가정되는 것이 아니라 증거로서 캡처된다는 것입니다. 워크플로는 다음과 같습니다.

왜 초록색 체크 표시가 거짓말을 하는가

백업 작업의 초록색 체크 표시는 운영(operations)에서 가장 위험한 신호 중 하나입니다. 왜냐하면 안전을 보장하지 않으면서 확신만을 주기 때문입니다. 그것은 작업이 완료되었다고 알려줍니다. 하지만 출력물이 사용 가능한지에 대해서는 아무것도 알려주지 않습니다. 그리고 이 두 가지 사이의 차이점은 최악의 순간이 오기 전까지는 보이지 않습니다.

체크표시(checkmark)가 거짓말을 하는 이유는 백업이 시스템의 절반에 불과하기 때문입니다. 나머지 절반은 복구 (restore)이며, 복구는 거의 실행되지 않는 절반입니다. 팀들은 보존 정책 (retention policies), 오프사이트 복제 (offsite replication), 암호화 (encryption)를 갖춘 정교한 백업 파이프라인을 구축하지만, 복구 경로를 처음부터 끝까지 단 한 번도 실행해 보지 않습니다. 복구 경로는 작성 당시에는 유효했지만 더 이상 유효하지 않을 수 있는 가정들로 가득 차 있으며, 실제 복구가 필요할 때까지 그 어떤 가정도 테스트되지 않습니다.

사후 분석 (postmortems) 보고서에는 백업이 있음에도 불구하고 데이터를 유실하는 회사의 암울한 패턴이 존재합니다. 백업은 존재했습니다. 다만 누군가 처음 시도했을 때 바로 알 수 있었을 법한 이유로 복구할 수 없었을 뿐입니다. 복구를 전혀 테스트하지 않는 비용은 평범한 날에는 0원이지만, 그것이 중요한 단 하루에는 재앙이 됩니다.

복구해 보지 않은 백업은 백업이 아닙니다. 그것은 백업을 닮은 파일일 뿐입니다. 의미 있는 유일한 백업은 작동하는 시스템으로 복구하여 검증한 백업뿐이며, 그 검증은 감사가 있을 때 한 번 하는 것이 아니라 정기적인 일정에 따라 이루어져야 합니다.

아래의 워크플로우는 복구 검증을 드물게 일어나는 영웅적인 훈련에서 지루하지만 정기적인 루틴으로 바꿉니다. Claude Code 기술은 복구와 검증이라는 기계적인 작업을 처리하는데, 이는 너무 지루해서 중요할 정도로 자주 수동으로 수행하기 어려운 바로 그 작업입니다.

더 넓은 의미에서 운영 안정성 (production safety)에 관심이 있다면, 여기서의 사고방식은 Claude Code를 활용한 카오스 엔지니어링 (Chaos Engineering) 워크플로우의 원리와 같습니다. 이는 운영의 다른 영역에서 '희망'을 '측정'으로 대체합니다.

인벤토리 기술 (The Inventory Skill)

첫 번째 기술은 대부분의 팀이 정확하게 대답하지 못하는 질문에 답합니다: 우리가 어떤 데이터를 가지고 있으며, 각 데이터에 대한 백업 상황은 어떠한가? 이 기술은 모든 데이터 저장소 (data store)와 그 백업 상태 (backup posture)에 대한 인벤토리를 구축하고 유지 관리합니다.

각 데이터 저장소 (data store)에 대해, 인벤토리는 그것이 무엇인지, 얼마나 중요한지, 어떻게 백업되는지, 얼마나 자주 백업되는지, 백업이 어디에 저장되는지, 얼마나 오래 보관되는지, 그리고 마지막으로 복구 (restore)가 언제 검증되었는지를 기록합니다. 마지막 필드가 보통 문제를 드러내는 부분입니다. 대부분의 저장소는 검증된 복구 과정을 거친 적이 없으며, 인벤토리는 이러한 부재를 숨겨두는 대신 가시화합니다.

인벤토리는 백업이 전혀 없는 저장소도 드러냅니다. 모든 시스템은 빠르게 추가되었으나 백업 파이프라인 (backup pipeline)에 연결되지 않은 데이터 저장소들을 쌓아가게 됩니다. 조용히 신뢰할 수 있는 원천 (source of truth)이 되어버린 캐시 (cache), 아무도 야간 작업 (nightly job)에 추가하지 않은 자체 데이터베이스를 가진 새로운 서비스 등이 그 예입니다. 인벤토리는 실제 운영 중인 데이터 저장소 목록과 백업 범위 (backup coverage)가 적용된 저장소 목록을 대조함으로써 이러한 격차를 찾아냅니다.

그 결과물은 전체 시스템에 걸친 백업 상황에 대한 단 하나의 정직한 그림입니다. 처음에는 이를 보는 것이 불편할 수 있는데, 대개 팀이 예상했던 것보다 더 많은 격차를 보여주기 때문입니다. 하지만 그 불편함이 바로 핵심입니다. 보이지 않는 커버리지 격차는 수정할 수 없습니다.

복구 기술 (The Restore Skill)

두 번째 기술은 워크플로 (workflow)의 핵심입니다. 정해진 일정에 따라, 최근 백업을 가져와 격리된 환경 (isolated environment)에 복구하고, 복구가 성공했는지 확인합니다.

복구는 운영 환경 (production)과 연결되지 않은 깨끗하고 일회성인 환경에서 수행됩니다. 이 기술은 환경을 프로비저닝 (provision)하고, 실제 백업 파일에 대해 실제 복구 절차를 실행하며, 작업이 완료되면 환경을 제거합니다. 이는 실제 재난 상황에서 실행될 경로와 정확히 일치하며, 실제 백업을 대상으로 정기적인 일정에 따라 연습됩니다.

실제 복구 경로를 실행하는 것이 바로 이 작업의 가치를 만듭니다. 이는 체크 표시(checkmark)만으로는 절대 잡아낼 수 없는 실패 사례들을 포착합니다. 잘못 압축 해제되는 백업, 더 이상 설치되어 있지 않은 도구 버전이 필요한 복구, 복구 경로를 업데이트하지 않고 교체된 암호화 키 (Encryption key), 복구가 재구성할 수 없는 스키마 (Schema) 등이 그 예입니다. 이 모든 것들은 복구를 시도하기 전까지는 보이지 않으며, 스킬 (Skill)이 정기적인 일정에 따라 복구를 시도함으로써, 이러한 보이지 않는 실패들이 수정 비용이 저렴한 시점에 가시화되도록 합니다.

이 스킬은 복구 시간도 측정합니다. 백업을 복구할 수 있다는 것을 아는 것도 필요하지만, 그것만으로는 충분하지 않습니다. 복구에 시간이 얼마나 걸리는지도 알아야 합니다. 왜냐하면 복구 시간은 실제 장애 발생 시 복구 시간 (Recovery time)의 하한선이 되기 때문입니다. 작동은 하지만 11시간이 걸리는 복구는 재난이 닥친 도중이 아니라, 재난이 발생하기 전에 반드시 알고 있어야 하는 중요한 정보입니다.

만약 복구에 실패하면, 스킬은 정확히 어디서 왜 실패했는지에 대한 상세한 보고서를 생성합니다. 그 보고서는 정적인 백업 파이프라인 (Backup pipeline)이 결코 제공할 수 없는 조기 경보 역할을 합니다. 실패는 대재앙 중에 발견되는 대신, 일상적인 업무로서 수정됩니다.

검증 스킬 (The Verification Skill)

오류 없이 복구하는 것이 올바른 데이터를 복구하는 것과 같지는 않습니다. 세 번째 스킬은 복구된 데이터가 단순히 성공적으로 시작된 데이터베이스인지를 넘어, 실제로 있어야 할 데이터의 충실한 복사본인지 확인합니다.

이 스킬은 복구된 데이터에 대해 일련의 무결성 검사 (Integrity checks)를 실행합니다. 예상된 테이블 (Tables)과 컬렉션 (Collections)이 존재하는지, 행 수 (Row counts)가 원본과 비교해 합리적인 범위 내에 있는지, 참조 무결성 (Referential integrity)이 유지되는지, 중요한 레코드 (Records)가 존재하고 형식이 올바른지, 그리고 백업에 포함된 가장 최근의 데이터가 백업 일정에 따라 기대되는 만큼 최신인지 확인합니다. 빈 데이터베이스를 생성하거나 가장 중요한 테이블이 누락된 데이터베이스를 생성하는 복구는, 단순한 "시작 여부" 확인은 통과할지 몰라도 이 검증 단계에서는 실패하게 됩니다.

검증은 데이터 저장소(data store)별로 조정됩니다. 무엇이 '정확함'으로 간주되는지는 저장소마다 다르기 때문입니다. 마지막 한 시간 동안의 쓰기(write) 데이터가 유실되는 것이 치명적인 저장소의 경우, 스킬(skill)은 가장 최신 레코드의 최신성(recency)을 엄격하게 확인합니다. 대략적인 수치만으로도 충분한 저장소의 경우, 더 느슨하게 확인합니다. 인벤토리(inventory)가 이러한 기대치를 결정하므로, 검증은 각 저장소의 중요도가 요구하는 만큼 엄격하게 이루어집니다.

검증 출력값은 저장소별 판결(verdict)로 나타나며, 단순히 "복구됨"이라고 말하는 것이 아니라 "복구되었으며, 이러한 특정 기준에 따라 정확함이 검증됨"이라고 명시합니다. 그 판결이야말로 제가 수년 동안 초록색 체크 표시를 바라보며 진정으로 원했던 것입니다. 그것은 대리 지표(proxy) 대신 실제 질문에 대한 답을 제공합니다.

이 접근 방식은 Claude Code를 이용한 로그 분석 (Claude Code for Log Analysis)에서 제시된 지속적 검증(continuous verification) 개념을 반영합니다. 여기서 가치는 압박 속에서 해석해야 하는 데이터 더미를 만드는 것이 아니라, 가공되지 않은 신호(raw signals)를 신뢰할 수 있는 판결로 전환하는 데서 옵니다.

리포팅 스킬 (The Reporting Skill)

네 번째 스킬은 이 모든 것을 팀이 한눈에 볼 수 있는 태세(posture)로 전환합니다. 이는 인벤토리, 복구 결과, 그리고 검증 판결을 통합하여 전체 시스템에 걸친 백업 상태에 대한 단일한 지속적 보고서(ongoing report)를 생성합니다.

이 보고서는 중요한 질문들에 답합니다. 어떤 데이터 저장소가 요구되는 시간 범위 내에서 검증된 복구를 완료했는가? 어떤 저장소가 마지막 복구에 실패했는가? 어떤 저장소가 백업 커버리지가 전혀 없는가? 현재 복구 시간은 얼마이며, 그중 복구 목표(recovery targets)를 초과하는 것이 있는가? 이 보고서는 백업 작업이 성공하는 것과 백업이 제대로 작동하는 것이 같지 않다는 것을 고통스러운 경험을 통해 배우기 전에, 제가 가졌기를 바랐던 대시보드입니다.

이 보고서는 또한 추세를 추적합니다. 몇 주에 걸쳐 증가하는 복구 시간이란 복구 창(recovery window)이 조용히 닫히고 있다는 경고이며, 이 추세는 예상치 못한 일이 되기 전에 이를 드러냅니다. 검증 기준이 무너지기 시작한 스토어는 그 무너짐이 격차(gap)가 되기 전에 플래그가 지정됩니다.

결정적으로, 이 보고서는 체크 표시 하나로 뭉개지기 쉬운 두 가지 실패 모드를 구별합니다. '백업 실행 실패'와 '백업은 실행되었으나 복구할 수 없음'을 분리하는 것입니다. 이 둘은 완전히 다른 대응이 필요하며, 이를 같은 것으로 취급하는 시스템은 잘못된 것을 고치게 됩니다.

워크플로우가 실제 작동하는 방식

인벤토리 스킬(inventory skill)이 먼저 그림을 만듭니다. 이는 실시간 데이터 저장소와 백업 커버리지를 조정하고, 격차를 포함한 정직한 지도를 생성합니다. 팀은 첫 번째 단계로 커버리지 격차를 메우고, 따라서 중요한 모든 스토어는 최소한 백업되고 있도록 합니다.

거기서부터 복원 스킬(restore skill)이 스토어별로 일정을 잡아 실행됩니다. 이는 최근 백업을 가져와 깨끗한 환경에 복원하고, 복원 시간을 측정하며, 그 환경을 해체합니다. 검증 스킬(verification skill)은 복원된 데이터가 스토어의 기준과 일치하는지 확인합니다. 결과는 보고 스킬(reporting skill)로 흘러 들어갑니다.

복원이 실패하거나 검증이 잘못되면, 이는 상세한 보고서가 첨부된 일반적인 유지보수 작업으로 기록됩니다. 팀은 문제가 생겼을 때 발견하는 대신, 수리가 저렴할 때 복원 경로를 수정합니다. 예전에 1년 동안 숨어있던 실패들이 이제는 스케줄링 주기 내에서 나타납니다.

시간이 지나면서 이 보고서는 복구 가능성에 대한 지속적인 진실의 원천이 됩니다. 누군가 데이터가 안전한지 물을 때, 더 이상 희망에 찬

첫 번째 변화는 제가 미처 몰랐던 문제들을 발견하게 되었다는 점입니다. 첫 번째로 예약된 복구 실행 (restore run) 과정에서, 기술적으로는 수개월 동안 백업이 성공하고 있었지만 실제로는 완전히 복구할 수 없는 파일을 생성하고 있었던 스토어(store)가 드러났습니다. 이것이 바로 기업을 파멸로 몰아넣는 실패의 전형이며, 재난 상황이 아닌 평범한 오후에 발견된 것입니다.

두 번째 변화는 복구 시간 (recovery time)에 대해 생각하는 방식의 변화였습니다. 워크플로 (workflow)를 도입하기 전, 저의 복구 시간은 추측에 불과했습니다. 워크플로 도입 후, 복구 시간은 각 스토어별로 측정된 수치가 되었으며, 매 복구 실행 시마다 업데이트됩니다. 측정된 수치를 바탕으로 계획을 세우는 것은 추측을 바탕으로 계획을 세우는 것과는 근본적으로 다른 활동입니다. 특히 상급자가 복구에 얼마나 걸릴지 묻고 실제적인 답변을 기대할 때는 더욱 그렇습니다.

세 번째 변화는 백업 범위 (backup coverage)가 표류하는 것을 멈췄다는 점입니다. 새로운 데이터 스토어(data store)들이 백업 없이 방치되어 유실될 때까지 조용히 남아있는 대신, 인벤토리 조정 (inventory reconciliation) 과정을 통해 포착됩니다. "데이터베이스를 추가했다"는 시점과 "데이터베이스가 백업되고 검증되었다"는 시점 사이의 간극이 수개월에서 하나의 스케줄링 주기 (scheduling cycle)로 단축되었습니다.

네 번째 변화는 더 미묘하면서도 가치 있는 것이었습니다. 저는 초록색 체크 표시를 신뢰하는 것을 멈췄고, 팀원들에게도 그것을 신뢰하지 않도록 가르쳤습니다. 이제 체크 표시는 항상 의미했어야 할 대로 "작업이 실행되었다"는 것을 의미하며, 진짜 안전 신호는 검증된 복구 (verified restore)로부터 나옵니다. 거짓된 확신을 실제적인 확신으로 대체하는 것은 이 워크플로가 잡아낸 그 어떤 단일 문제보다 더 큰 가치가 있습니다.