4월 19일 데이터 장애를 돌아보며
4월 19일 저녁 Toonkit에서 데이터 장애가 있었습니다. 자동 백업은 만들어지고 있었지만, 정작 필요한 순간에 독립적으로 복구할 수 없는 구조였습니다. 그날 있었던 일과 이후 바꾼 백업·운영 절차를 정리했습니다.

4월 19일 저녁, Toonkit에서 데이터 장애가 있었습니다.
일부 사용자분들은 로그인을 했지만 이전에 만들었던 컷, 에셋, 시나리오가 보이지 않는 화면을 보셨습니다. 이후 가능한 범위에서 복구를 진행했지만, 계정마다 돌아간 시점이 달랐고 백업 시점 이후에 만든 작업물은 다시 보이지 않는 경우가 있었습니다.
이 글은 그날 어떤 일이 있었는지, 복구하면서 무엇을 확인했는지, 그리고 이후 백업과 운영 절차를 어떻게 바꿨는지 정리한 글입니다.
그 시간에 Toonkit을 열어보고 당황하셨을 모든 분들께 먼저 사과드립니다.
작업물이 보이지 않는다는 것
Toonkit에서 만들어지는 작업물은 단순한 파일 목록처럼 보기 어렵습니다.
컷 하나를 고르기까지 여러 번 생성하고 비교하는 시간이 있습니다. 에셋 하나를 남기기 위해 프롬프트를 조금씩 바꿔보는 과정도 있습니다. 시나리오도 마찬가지입니다. 같은 내용을 다시 입력할 수는 있어도, 그때의 흐름과 선택까지 그대로 되돌리기는 어렵습니다.
이번 장애를 복구하면서 이 부분을 계속 보게 됐습니다.
겉으로는 "몇 개 항목이 보이지 않는 문제"처럼 보일 수 있습니다. 하지만 실제로는 누군가가 시간을 들여 만든 작업의 일부가 비어 있는 상황이었습니다. 특히 장애 직전까지 Toonkit을 자주 쓰고 계셨던 분들일수록 보이지 않는 작업물이 많았습니다.
가장 최근까지 만들고 계셨던 분들이 가장 크게 영향을 받은 셈입니다.
이 부분은 단순히 장애 처리 기록으로만 남기기 어렵다고 생각했습니다.
4월 19일 저녁에 있었던 일
그날 저녁 저희는 클라우드 비용을 정리하는 작업을 하고 있었습니다.
매달 비용이 나가고 있지만 실제로 쓰지 않는 리소스들을 확인하고, 필요 없는 인스턴스와 스토리지, DB를 정리하는 작업이었습니다.
그 과정에서 실제 서비스에 쓰이고 있던 DB를 잘못 삭제했습니다.
문제를 알아챈 뒤 바로 클라우드 긴급 지원에 연락했습니다. 하지만 한 번 반납된 DB 인스턴스는 되돌릴 수 없다는 답변을 받았습니다.
일 단위로 생성되던 백업도 확인했습니다. 다만 그 백업은 DB 인스턴스에 묶여 있었고, 인스턴스가 반납되면서 함께 사라진 상태였습니다.
사전에 백업을 별도 객체 저장소로 분리해두었다면 그 데이터를 기준으로 복구할 수 있었습니다. 하지만 당시에는 그 절차가 없었습니다.
이번 장애에서 가장 크게 봐야 할 부분이 여기에 있었습니다.
백업 파일이 만들어지고 있다는 사실만 보고 있었고, 그 백업이 실제 장애 상황에서도 독립적으로 살아남을 수 있는지는 충분히 확인하지 못했습니다.
복구하면서 확인한 것들
이후 저희는 각 계정에 남아 있던 내용을 개별적으로 확인했습니다. 남아 있는 것을 모으고, 가능한 범위 안에서 다시 맞춰보는 방식으로 복구를 진행했습니다.
다만 계정마다 남아 있던 백업 시점이 달랐습니다.
어떤 분은 며칠 전 상태로 돌아갔고, 어떤 분은 몇 주 전 상태로 돌아갔습니다. 백업 시점 이후에 만드신 작업물은 복구된 화면에 보이지 않는 상태가 되었습니다.
복구를 하면서 계속 확인한 건, 무엇이 돌아왔는지보다 무엇이 돌아오지 못했는지였습니다.
며칠 전까지 만들었던 컷이 보이지 않는 계정이 있었고, 최근에 정리해둔 에셋이 빠진 경우도 있었습니다. 시나리오가 예전 상태로 돌아간 경우도 있었습니다.
처음에는 남아 있는 것들을 최대한 모으는 데 집중했습니다. 그런데 계정별로 하나씩 보다 보니, 빈칸처럼 남은 부분들이 계속 눈에 들어왔습니다.
컷 하나에도 선택이 들어가 있습니다. 여러 번 생성해보고, 비교하고, 마음에 드는 것을 남겨둔 결과입니다. 에셋이나 시나리오도 다르지 않습니다.
같은 내용을 다시 만들 수는 있어도, 그때의 흐름까지 그대로 되돌리기는 어렵습니다.
그래서 이번 일은 "가능한 만큼 복구했다"로 끝낼 수 없었습니다. 복구되지 않은 부분이 사용자분들에게 어떤 의미였을지까지 같이 봐야 했습니다.
보상은 별도로 정리해 안내드리겠습니다.
이후 바꾼 것들
이번 사고 이후 백업 구조를 바꿨습니다.
지금은 백업이 데이터베이스와 완전히 분리된 별도 위치에 자동으로 저장됩니다. DB 인스턴스가 삭제되더라도 백업까지 함께 사라지지 않도록 구조를 나눴습니다.
또 하나 바꾼 점은, 백업 파일이 만들어졌는지만 보지 않는다는 것입니다.
지금은 그 백업으로 실제 복구가 가능한지 정기적으로 자동 검증합니다.
이번 일을 겪으면서 확인한 것은 단순했습니다.
"백업이 있다"와 "그 백업으로 복구할 수 있다"는 같은 말이 아니었습니다.
앞으로는 백업 파일을 만드는 것에서 끝내지 않겠습니다. 실제로 복구가 되는지 확인하는 것까지를 백업 절차로 보고 운영하겠습니다.
운영 작업 절차도 다시 잡았습니다.
데이터에 영향을 줄 수 있는 작업은 실행 전에 영향 범위를 먼저 확인하도록 했습니다. 그리고 두 사람 이상이 확인한 뒤에만 실행되도록 바꿨습니다.
큰 변경 작업에는 명령 자체에 안전장치를 두었습니다. 의도한 범위 밖으로 변경이 퍼지지 않도록 막기 위한 장치입니다.
이번에는 이 장치들이 늦었습니다. 앞으로는 운영 편의보다 데이터 안전을 먼저 두고 작업하겠습니다.
문의와 보상 안내
복구된 백업 시점 이후에 만드신 작업물 중 다시 확인하고 싶으신 것이 있다면 아래 이메일로 문의해 주세요.
문의하실 때는 가입하신 이메일과 대략적인 가입 시점을 함께 보내주시면 확인이 더 빠릅니다. 가능한 범위에서 개별적으로 확인해 안내드리겠습니다.
크레딧과 결제 관련 문의도 같은 메일로 받고 있습니다.
마치며
이번 일을 겪으면서 백업 구조와 운영 절차를 다시 봤습니다. 동시에, 장애가 났을 때 저희가 무엇을 먼저 봐야 하는지도 다시 생각하게 됐습니다.
저희에게는 복구 중인 장애였지만, 사용자분들에게는 작업물이 사라진 화면이었습니다. 내부에서 어떤 조치를 하고 있는지보다, 지금 내 작업이 안전한지 바로 알 수 있는 안내가 먼저 필요했습니다.
앞으로는 장애가 났을 때 내부 복구만 보지 않겠습니다. 사용자분들이 실제로 보고 있는 화면, 그 화면에서 느낄 불안, 그리고 바로 필요한 안내까지 함께 보겠습니다.
4월 19일 저녁 Toonkit을 열어보고 당황하셨던 모든 분들께 다시 한번 사과드립니다.
— Toonkit 팀