백업은 있는데 복구할 수 있을까? SmartNexus 장애복구 계획 만들기

백업이 있다는 말과 오늘 업무를 복구할 수 있다는 말은 다릅니다. 코드, DB와 외부 연동이 여러 서비스에 나뉘자 “문제가 생기면 어디서부터 되돌릴까”를 기억에 맡길 수 없었습니다. 이번 단계에서는 SmartNexus 장애복구 계획을 실제 운영 순서로 정리했습니다.

SmartNexus 개발일지 ⑭ · 2026년 9월 15일 · 약 6분

장애복구는 서버를 다시 켜는 일이 아니다

웹앱이 열리지 않는 원인은 코드 배포, 환경변수, DB, OAuth 또는 외부 API일 수 있습니다. 무조건 최신 코드를 다시 배포하면 DB와 맞지 않는 버전이 올라가 상황이 더 복잡해질 수 있습니다. 먼저 영향 범위와 마지막 정상 version을 확인하는 절차가 필요했습니다.

SmartNexus의 핵심 업무는 Lead 접수, Client 기록, NDA·OM 상태와 Follow-up입니다. 화면 일부가 느린 것과 신규 기록이 사라지는 것은 우선순위가 다릅니다. 데이터를 더 손상시키지 않도록 쓰기를 멈춰야 하는 상황과 읽기 전용으로 계속 운영할 상황도 구분했습니다.

RPO와 RTO를 숫자로 정해야 판단할 수 있다

RPO는 어느 시점까지의 데이터 손실을 허용할 것인지, RTO는 얼마 안에 서비스를 되살릴 것인지에 대한 기준입니다. 모든 데이터를 0초 손실로 복구하고 즉시 정상화하겠다는 목표는 초기 서비스에서 현실적이지 않습니다. 업무 중요도에 따라 기준을 달리 잡았습니다.

예를 들어 새 Lead와 발송 기록은 가능한 한 손실을 줄여야 하지만, 다시 계산할 수 있는 화면 캐시나 통계는 우선순위가 낮습니다. 복구 과정에서도 Client와 Event 수, 최신 Lead 시각, NDA·OM 상태처럼 확인할 기준을 미리 정했습니다.

코드 롤백과 DB 복구를 같은 버튼으로 생각하지 않기

이전 Railway deployment로 돌아가는 것은 애플리케이션 이미지를 되돌리는 일입니다. 이미 적용된 DB migration까지 자동으로 이전 상태가 되는 것은 아닙니다. 코드와 스키마의 호환 범위를 확인하고, 파괴적인 migration은 별도 승인과 백업 뒤에 실행하도록 했습니다.

DB 복원은 더 신중해야 합니다. 복구 지점 이후 들어온 정상 데이터가 사라질 수 있으므로 먼저 현재 상태를 보존하고 필요한 범위만 비교합니다. 전체 복원, 특정 테이블 보완과 개별 레코드 수정 중 가장 작은 범위를 선택하도록 절차를 나눴습니다.

외부 연동은 재발송보다 상태 대조가 먼저다

DocuSign이나 Gmail 오류 뒤에 작업을 다시 실행하면 같은 NDA나 이메일이 두 번 갈 수 있습니다. SmartNexus 기록만 보고 재시도하지 않고 provider의 envelope ID, message ID와 실제 상태를 먼저 확인해야 합니다. Google Contacts도 중복 식별자를 기준으로 대조합니다.

Telegram 배포 알림이 오지 않았다는 사실만으로 배포가 실패했다고 판단하지 않습니다. Railway 상태와 앱의 version·commit, health endpoint를 함께 확인합니다. 알림은 빠른 발견을 돕지만 복구 판단의 유일한 근거는 아닙니다.

문서는 장애가 났을 때 읽을 수 있는 곳에 둔다

복구 문서가 장애 난 서버 안에만 있으면 사용할 수 없습니다. 프로젝트 외부에서 접근 가능한 사본을 두고, 비밀값 자체가 아니라 어디서 안전하게 확인하고 갱신하는지를 적었습니다. 계정 소유자와 결제 상태도 기술 설정만큼 중요했습니다.

문서에는 이상적인 구조보다 실제 버튼과 확인 순서를 적었습니다. 마지막 정상 commit, Railway deployment 확인, Neon 상태 점검, 핵심 화면 테스트와 사용자 공지를 누가 어떤 순서로 하는지가 분명해야 합니다.

복구 계획은 테스트하지 않으면 가정일 뿐이다

운영 DB를 위험하게 되돌리는 훈련 대신 별도 환경에서 백업을 복원하고 앱이 연결되는지 확인할 수 있습니다. 분기별로 문서 링크, 계정 접근, 복원 소요시간과 변경된 환경변수를 점검하도록 했습니다. 테스트 결과는 다음 계획 수정의 근거로 남깁니다.

혼자 운영하는 서비스에서는 복구 책임자가 한 명이라는 점도 위험입니다. 최소한 계정 목록과 중단 시 연락할 지원 채널, 우선 복구할 기능을 문서화하면 당황한 상태에서 기억에 의존하는 일을 줄일 수 있습니다.

복구가 끝났다는 기준도 “로그인 화면이 열린다”로 두지 않았습니다. 새 Lead 저장, Client 검색, Event 조회와 Follow-up 생성처럼 데이터의 읽기와 쓰기를 모두 포함한 짧은 점검표를 사용했습니다. 이메일과 DocuSign은 실제 고객에게 재전송하지 않고 테스트 대상 또는 provider 상태 조회로 연결을 확인했습니다.

실무 체크리스트

FAQ

자동 백업이 있으면 복구 계획은 필요 없나요?

백업 위치, 복원 방법과 검증 기준을 모르면 실제 장애에서 사용할 수 없습니다. 복구 절차와 테스트가 함께 필요합니다.

문제가 생기면 이전 배포로만 돌아가면 되나요?

코드 롤백은 DB 스키마를 되돌리지 않습니다. 두 버전의 호환성을 먼저 확인해야 합니다.

RPO와 RTO는 한 번 정하면 끝인가요?

데이터량과 업무 중요도가 바뀌면 다시 평가해야 합니다. 복원 테스트 결과도 기준에 반영해야 합니다.

외부 서비스 장애 때 왜 바로 재발송하면 안 되나요?

첫 요청이 실제로 성공했지만 응답만 놓쳤을 수 있습니다. provider ID와 상태를 대조한 뒤 재시도해야 중복을 막을 수 있습니다.

공식 자료

• NIST SP 800-34: Contingency Planning Guide
• Railway Docs: Deployment Actions
• Neon Docs: Database Branching

관련 글

• 배포 버전과 Health Check
• Google Contacts 동기화와 배포 알림
• Lead·Listing 필터와 일괄 처리