이 글은 제가 운영 DB를 통째로 날려본 이야기입니다. DAU 200만 게임 서비스였고, 복구에 하루가 걸렸습니다. 이 글에서 세 가지를 가져가실 수 있습니다. 첫째, 사고가 실제로 어떤 순서로 일어나는지. 둘째, 그때 제가 몰라서 못 했던 DB 복구 방법이 무엇이었는지. 셋째, 그 사고 이후 제가 지금까지 지키고 있는 삭제 원칙 하나입니다.
서버 점검 시간에 벌어진 일
당시 저는 DB를 자주 다루지 않던 초보였습니다. SQL을 직접 쓸 때도 있었지만, 간단한 작업은 대부분 GUI 툴로 처리했습니다. 클릭 몇 번이면 끝나니까요.
그날은 서버 점검 시간이었습니다. DB 백업을 하고, 필요 없는 것들을 정리하는 작업이었습니다. 그러다 실 서비스 DB를 통째로 날렸습니다.
등골이 서늘해지고 땀이 났습니다. 온 세상이 무너지는 기분이었습니다. 문제는 그다음이었습니다. 저는 복구하는 방법을 몰랐습니다. 서비스는 계속 셧다운 상태였고, 저는 할 수 있는 게 없었습니다.
결국 CTO님을 호출했습니다. 회사 DB 전문가들이 붙어서 하루에 걸쳐 복구를 진행했고, 다음 날 서비스를 재개했습니다.
GUI 툴이 위험한 진짜 이유
사고 이후에 제가 내린 결론은 “GUI를 쓰지 말자"가 아닙니다. GUI 툴 자체는 죄가 없습니다. 문제는 GUI가 작업의 무게를 감춘다는 데 있습니다.
SQL을 직접 쓰면 손이 한 번 멈춥니다. DROP DATABASE 같은 문장은 타이핑하는 동안 스스로 검열하게 됩니다. WHERE 절이 빠졌는지도 눈에 들어옵니다. 그런데 GUI에서는 우클릭과 확인 버튼 한 번의 무게가, 행 하나 지우는 것과 DB 전체를 지우는 것이 동일합니다. 손가락이 기억하는 동작에 위험도가 반영되지 않습니다.
제가 그날 한 실수도 정확히 그것이었습니다. “정리 작업” 모드로 손이 굴러가고 있었고, 대상이 무엇인지 눈으로 다시 확인하지 않았습니다.
지금 당장 점검할 수 있는 것들입니다.
- GUI 툴의 접속 프로필에서 운영 DB에 눈에 띄는 색(빨강)을 지정했는가
- 운영 계정과 개발 계정을 같은 창에 동시에 띄워두고 있지 않은가
- 파괴적 작업(DROP, TRUNCATE, 대량 DELETE)만은 SQL로 직접 쓰기로 정해두었는가
- 그 SQL을 실행하기 전에 대상 이름을 소리 내어 읽는 습관이 있는가
마지막 항목이 유치해 보이지만, 저는 이걸 아직도 합니다.
제가 그때 몰랐던 것: 커밋해도 복구는 가능하다
당시 제가 가장 절망했던 지점은 “이미 반영됐다"는 사실이었습니다. 되돌릴 수 있다는 생각 자체를 못 했습니다.
SQL전문가 정미나 채널의 실수로 데이터를 날려버렸다면?! 데이터 복구 방법, UNDO, TIMESTAMP 영상은 바로 그 지점을 다룹니다. 영상에서는 이미 커밋을 한 뒤에도 복구할 방법이 있으니 당황하지 말라고 설명합니다. 오라클의 UNDO 영역을 이용하는 방법입니다.
영상의 설명을 제 식으로 정리하면 이렇습니다.
- UNDO는 DML 작업을 할 때 변경 이전의 데이터를 담아두는 로그 영역이다.
- 그래서 특정 시점(TIMESTAMP)의 데이터를 조회해 다시 넣을 수 있다.
- 다만 UNDO는 영원히 보관되지 않는다. 보관 시간 설정값이 있다.
영상에서는 실습 환경의 UNDO 보관 설정값이 900, 즉 900초로 나옵니다. 최근 15분간의 작업 내역만 UNDO에 남아 있다는 뜻입니다. 그래서 영상은 그 시간이 지나기 전에 빨리 복구해야 한다고 강조합니다.
실습 흐름도 단순합니다. 특정 날짜의 데이터를 삭제하고 커밋한 뒤, 그 이전 시점의 상태를 조회해서 사라진 행들을 확인하고, 그대로 다시 INSERT하면 데이터가 돌아옵니다.
이 값은 DB마다 다르게 설정되어 있으니, 남의 환경 숫자를 그대로 믿지 마시고 본인 DB에서 직접 확인해보시기 바랍니다.
그런데 제 사고에는 UNDO가 답이 아니었습니다
솔직하게 말씀드려야 할 부분이 있습니다. UNDO 복구는 제 사고를 구해주지 못했을 가능성이 큽니다.
제 상황과 영상의 상황은 결이 다릅니다. 영상은 “행을 잘못 지우고 커밋했다"는 사례입니다. 제 사고는 DB 자체를 날린 사례입니다. UNDO는 데이터 변경 이력을 다루는 장치이지, 사라진 DB 구조를 되살리는 장치가 아닙니다.
| 구분 | 영상의 사례 | 제 사고 |
|---|---|---|
| 사고 내용 | 특정 날짜 행 삭제 후 커밋 | 실 서비스 DB 전체 소실 |
| 되살릴 대상 | 데이터 몇 건 | DB 구조 + 전체 데이터 |
| 시간 압박 | UNDO 보관 시간(예: 15분) 내 | 서비스 셧다운 중, 매 분이 압박 |
| 실제 해법 | UNDO 시점 조회 후 INSERT | 백업 기반 복구, 전문가 투입, 1일 소요 |
그렇다면 영상이 제게 쓸모없었느냐. 아닙니다. 제가 그때 배웠어야 할 것은 UNDO 문법 자체가 아니라 “복구 경로가 존재한다"는 감각이었습니다.
복구 방법을 하나라도 알고 있었다면, 저는 화면 앞에서 얼어붙는 대신 사고 규모를 먼저 판단했을 겁니다. “이건 내가 되돌릴 수 있는 급인가, 아니면 즉시 CTO를 불러야 하는 급인가.” 그 판단을 30초 만에 했느냐 30분 만에 했느냐가, 셧다운 시간을 좌우합니다.
DAU 200만 서비스에서 셧다운 1분은 그냥 1분이 아닙니다.
그날 이후 저는 아무것도 바로 지우지 않습니다
이 사고 하나로 제 작업 방식이 바뀌었습니다. 지금도 지키는 원칙입니다.
필요 없어 보이는 DB나 테이블이라도 바로 삭제하지 않습니다. 무조건 rename으로 백업해두고, 일정 기간 지켜본 뒤에 삭제합니다.
제가 이 방식을 고집하는 이유는 세 가지입니다.
첫째, rename은 되돌리기가 쉽습니다. 이름만 다시 바꾸면 끝입니다. 백업 파일을 찾아 복원하는 것과는 비교가 안 됩니다.
둘째, “필요 없다"는 판단은 자주 틀립니다. 아무도 안 쓴다고 생각한 테이블을 배치 잡 하나가 새벽에 조용히 참조하고 있는 경우, 겪어보신 분은 아실 겁니다. rename을 해두면 그 참조가 에러로 드러납니다. 삭제해버리면 그 에러의 원인을 추적하는 데 훨씬 오래 걸립니다.
셋째, 지켜보는 기간 자체가 안전장치입니다. 삭제라는 행위를 한 번에 끝내지 않고 두 단계로 쪼개면, 그 사이에 제정신이 돌아옵니다.
실무에서 쓰는 절차는 이렇습니다.
- 대상 이름 뒤에 접미사를 붙여 rename합니다. (예:
user_log→user_log_deprecated_20260805) - 이름에 날짜를 반드시 넣습니다. 언제부터 지켜봤는지 알아야 하니까요.
- 관찰 기간을 정합니다. 저는 최소 한 달을 봅니다. 월 단위 배치가 있는 시스템이라면 그보다 길게 잡습니다.
- 기간 동안 에러 로그와 문의를 확인합니다.
- 조용하면 그때 삭제합니다.
번거롭습니다. 그런데 제가 잃은 하루와 비교하면 아무것도 아닙니다.
사고가 나기 전에 확인해두어야 할 것들
제 경험을 일반화하면, 사고의 크기를 결정하는 건 실수 자체가 아니라 실수 이후에 쓸 수 있는 수단이 몇 개인가였습니다. 저는 그 수단이 0개였습니다.
지금 본인 환경에서 답할 수 있는지 확인해보시기 바랍니다.
- 마지막 백업이 언제 것인지 지금 바로 답할 수 있는가
- 그 백업으로 복구를 실제로 해본 적이 있는가 (백업이 있다는 것과 복구가 된다는 것은 다른 얘기입니다)
- 복구에 걸리는 시간을 대략이라도 알고 있는가
- 내 DB의 UNDO 보관 시간 설정값을 알고 있는가
- 사고가 났을 때 누구에게 몇 분 안에 알려야 하는지 정해져 있는가
마지막 항목을 강조하고 싶습니다. 저는 CTO님을 부르기까지 시간을 썼습니다. 혼자 어떻게든 해보려는 마음, 사고 친 걸 알리기 싫은 마음 때문입니다. 그 마음이 셧다운 시간을 늘렸습니다.
사고를 친 사람에게
혹시 지금 이 글을 사고 직후에 검색해서 들어오셨다면.
먼저 손을 키보드에서 떼시기 바랍니다. 당황한 상태에서 추가로 치는 명령이 상황을 더 망칩니다. 그리고 시간이 흐를수록 복구 가능성이 줄어드는 수단이 있다는 걸 기억하시기 바랍니다. 앞서 본 영상에서도 UNDO 보관 시간이 지나기 전에 빨리 복구해야 한다고 설명합니다. 혼자 붙잡고 있는 시간이 가장 비싼 시간입니다.
그리고 이 말은 진심입니다. 저도 날려봤습니다. 회사는 안 망했습니다.
마치며
- DAU 200만 서비스의 운영 DB를 GUI 작업 중 통째로 날렸고, 전문가들이 하루에 걸쳐 복구했습니다.
- GUI 툴의 위험은 기능이 아니라 파괴적 작업과 사소한 작업의 손동작 무게가 같다는 데 있습니다.
- 커밋 이후에도 복구 경로는 존재합니다. 오라클이라면 UNDO 영역과 시점 조회가 그중 하나입니다. 다만 보관 시간 제한이 있습니다.
- 제 사고처럼 DB 전체가 날아간 경우는 UNDO로 해결되지 않습니다. 사고 유형에 맞는 수단을 미리 구분해두어야 합니다.
- 지금 제 원칙은 하나입니다. 지우지 말고 rename하고, 날짜를 붙이고, 한 달 지켜본 뒤에 지웁니다.
자주 묻는 질문
Q. 커밋까지 했는데 삭제한 데이터를 되살릴 수 있나요?
가능한 경우가 있습니다. 정미나 채널의 영상에서는 오라클의 UNDO 영역을 이용해 삭제 이전 시점의 데이터를 조회한 뒤 다시 INSERT하는 방법을 보여줍니다. 다만 UNDO에는 보관 시간 설정이 있어서 그 시간이 지나면 쓸 수 없습니다.
Q. UNDO 보관 시간은 얼마나 되나요?
환경마다 다릅니다. 영상의 실습 환경에서는 설정값이 900, 즉 900초(15분)로 나옵니다. 이건 그 환경의 값이므로 본인 DB에서 직접 확인하셔야 합니다. 중요한 건 숫자 자체가 아니라 “시간이 지나면 못 쓴다"는 성질입니다.
Q. DB를 통째로 날렸을 때도 UNDO로 복구되나요?
제 경험상 그 상황의 답은 UNDO가 아니었습니다. UNDO는 데이터 변경 이력을 다루는 장치입니다. DB나 테이블 구조 자체가 사라진 경우는 백업 기반 복구로 가야 하고, 그래서 저는 전문가 도움을 받아 하루가 걸렸습니다.
Q. 운영 DB 작업할 때 GUI 툴을 쓰면 안 되나요?
쓰지 말라는 뜻은 아닙니다. 다만 DROP, TRUNCATE, 대량 DELETE 같은 파괴적 작업만큼은 SQL로 직접 쓰기를 권합니다. 타이핑하는 동안 대상을 한 번 더 확인하게 되기 때문입니다.
Q. 안 쓰는 테이블은 어떻게 정리하는 게 안전한가요?
저는 바로 지우지 않습니다. 테이블명_deprecated_날짜 형태로 rename해두고 최소 한 달을 지켜봅니다. 그 기간에 에러나 문의가 없으면 그때 삭제합니다. 되돌리기가 이름 변경 한 번으로 끝나는 게 이 방식의 핵심입니다.