이 글이 던지는 질문
Christian Perone이 블로그에 The systems that no one will test, 우리말로 아무도 테스트하지 않을 시스템들이라는 글을 올렸어요. 제목만 봐도 찔리는 분이 많을 거예요. 우리가 만든 시스템 중에는 평소에는 한 번도 실행되지 않다가, 정말 큰일이 났을 때만 돌아가는 부분이 있거든요. 그리고 그런 부분일수록 막상 필요할 때 제대로 동작하지 않는 경우가 많아요.
이 글에서는 제목이 던지는 문제의식을 출발점 삼아, 왜 이런 역설이 생기는지와 실무에서 어떻게 대응할 수 있는지를 이야기해 볼게요. 원문의 구체적인 논지는 직접 읽어보시길 추천해요.
평소에는 절대 실행되지 않는 코드
어떤 시스템들이 여기에 해당하는지 떠올려 볼까요?
백업 복구가 대표적이에요. 백업은 매일 돌아가지만 복구는 거의 해보지 않죠. 백업 파일이 쌓이고 있다는 것과 그 파일로 실제로 되살릴 수 있다는 건 전혀 다른 이야기예요.
재해 복구(DR)와 페일오버도 그래요. 메인 데이터센터가 통째로 사라졌을 때 보조 센터로 넘어가는 절차는 설계 문서에만 있고, 실제로 전체를 넘겨본 적은 없는 경우가 많아요.
롤백, 서킷 브레이커, 폴백 로직도 마찬가지예요. 서킷 브레이커가 뭐냐면, 호출하는 외부 서비스가 계속 실패할 때 잠시 호출을 끊어서 장애가 번지지 않게 막는 장치예요. 집의 누전 차단기와 비슷해요. 이런 코드는 정상 상황에서는 절대 실행되지 않아요.
그 밖에도 인증서 만료, 윤초 처리, 디스크 풀, 그리고 알림 시스템 자체가 죽었을 때 같은 드문 상황들이 있어요.
이런 코드가 검증되지 않는 이유는 단순해요. 재현하기 어렵고, 비용이 크고, 무섭기 때문이에요. 운영 DB를 일부러 내려서 페일오버를 확인해 보자고 하면 반기는 사람이 거의 없죠. 그래서 발생 확률은 낮지만 한번 터지면 피해가 가장 큰 경로가 가장 덜 테스트되는 역설이 생겨요.
실제로 무슨 일이 벌어졌나
유명한 사례가 몇 가지 있어요. 2017년 GitLab은 운영자가 실수로 운영 DB 데이터를 지우는 사고를 겪었는데, 복구하려고 보니 준비해 둔 여러 백업 방식 중 제대로 동작하는 게 거의 없었어요. 결국 우연히 떠 둔 스냅샷으로 겨우 복구했고, 몇 시간 치 데이터는 잃었어요.
2012년 윤초 때는 리눅스 커널의 타이머 처리 문제로 여러 서비스가 CPU를 100% 쓰며 멈췄어요. 몇 년에 한 번 오는 이벤트라 제대로 테스트한 곳이 드물었던 거죠.
국내에서는 2022년 10월 판교 데이터센터 화재로 카카오 서비스가 오랫동안 멈췄던 일을 다들 기억하실 거예요. 이중화는 되어 있었지만, 데이터센터 하나가 통째로 사라지는 상황에서 실제로 전환이 되는지 충분히 검증되지 않았다는 점이 이후 크게 지적됐어요.
업계는 어떻게 대응하고 있나
이 문제에 대한 업계의 답은 한 문장으로 정리돼요. 테스트하지 않은 복구 절차는 없는 것과 같다는 거예요.
넷플릭스는 카오스 엔지니어링을 널리 알렸어요. Chaos Monkey라는 도구로 운영 환경의 서버를 무작위로 죽여서, 장애가 일상적으로 일어나게 만든 거예요. 장애를 드문 사건에서 평범한 사건으로 바꾸면 복구 경로도 자연스럽게 매일 검증돼요.
구글은 DiRT(Disaster Recovery Testing)라는 이름으로 대규모 재해 훈련을 정기적으로 해 왔어요. 실제로 시스템이나 인력을 빼 보고 조직이 버티는지 확인하는 거죠. 많은 회사가 하는 게임 데이, 즉 날을 잡아 장애 시나리오를 연습하는 것도 같은 맥락이에요.
코드 수준에서는 장애 주입(fault injection) 이 있어요. 테스트 중에 네트워크 지연, 타임아웃, 에러 응답을 일부러 끼워 넣어서 에러 처리 경로를 실행해 보는 방식이에요. 서비스 메시(Istio 등)나 Toxiproxy 같은 도구로 비교적 쉽게 시도할 수 있어요.
한국 개발자가 당장 해볼 수 있는 것
거창하게 시작할 필요 없어요.
- 이번 달에 백업 복구를 한 번 해보세요. 스테이징 환경에 실제 백업을 복원하고 걸린 시간을 기록하면, 그게 여러분 팀의 진짜 RTO(복구 목표 시간)예요.
- 에러 경로에도 테스트를 쓰세요. 외부 API가 타임아웃 날 때, DB 연결이 끊길 때 코드가 어떻게 동작하는지 단위 테스트로 확인하는 것만으로도 큰 차이가 나요.
- 알림을 테스트하세요. 일부러 경보 조건을 만들어서 담당자에게 실제로 알림이 가는지 확인해 보세요.
- 런북을 실제로 따라 해 보세요. 문서에 적힌 대로 했을 때 정말 되는지, 신입이 읽어도 따라 할 수 있는지요.
마무리
가장 중요한 코드는 평소에 가장 적게 실행되는 코드예요. 그러니 억지로라도 실행해 봐야 해요.
여러분 팀의 마지막 백업 복구 훈련은 언제였나요? 아무도 테스트하지 않아서 불안한 시스템이 있다면, 어떻게 검증을 시작해 볼 수 있을지 같이 이야기해 봐요.
🔗 출처: Hacker News