개발기초 새벽에 장애 콜을 받고 대응했던 경험 (그날 배운 것들)

삼성 제조라인에 서비스 운영 담당을 맡고 있던 시절, 새벽 2시경 에 장애 알림 문자를 받고 급하게 대응했던 적이 있습니다. 메뉴얼로 배운 것과 실제 새벽에 혼자 판단해야 하는 상황은 완전히 다르다는 걸 그때 깨달았습니다.

상황: 알림이 울린 순간

모니터링 알림 과고객사 연락으로 특정 배치 작업이 멈춰 서비스 응답이 없다는 것을 알게 됐습니다. 잠결에 확인했는데도 심각한 상황이라는 게 바로 느껴졌습니다.

문제 1: 원인 파악까지 시간이 오래 걸렸다

로그를 확인해봤지만 새벽이라 정신이 온전하지 않았고, 어디서부터 봐야 할지 판단이 잘 서지 않았습니다.

시도했던 것: 평소 순서대로 [서버 상태 → 애플리케이션 로그 → DB 상태] 순으로 확인했는데, 익숙하지 않은 상황이라 평소보다 훨씬 오래 걸렸습니다.

깨달은 점: 이 사건 이후로 장애 대응 순서를 문서화해서 팀 공유 위키에 올려뒀습니다. 새벽에 정신이 없는 상태에서도 순서만 보고 따라갈 수 있게 만드는 게 훨씬 중요하다는 걸 느꼈습니다.

문제 2: 혼자 판단해서 조치해도 되는지 확신이 없었다

원인은 어느 정도 파악했는데, 이 조치를 지금 당장 혼자 판단해서 진행해도 되는지 망설여졌습니다. [잘못 건드렸다가 상황이 더 나빠질까 봐] 걱정이 컸습니다.

대응: 일단 서비스에 미치는 영향을 최소화하는 선에서 임시 조치( 문제가 된 프로세스만 재시작)를 먼저 취하고, 팀 리더에게 상황을 공유했습니다. 완전한 원인 해결은 날이 밝은 뒤 관련 담당자들과 함께 진행했습니다.

깨달은 점: 장애 상황에서는 "완벽한 해결"보다 "더 나빠지지 않게 막는 것"이 먼저라는 걸 배웠습니다. 혼자 모든 걸 해결하려 하지 않고, 일단 상황을 공유하는 게 중요했습니다.

문제 3: 장애 이후 보고서 작성이 막막했다

다음 날 장애 보고서를 작성해야 했는데, 새벽에 급하게 대응하느라 시간대별 조치 내용을 제대로 기록해두지 못했습니다.

해결: 이후로는 장애 상황이 발생하면 조치와 동시에 시간, 확인한 내용, 취한 조치를 짧게라도 메모하는 습관을 들였습니다. 나중에 정리할 때 훨씬 수월해졌습니다.

마무리하며

이 경험을 통해 느낀 건, 장애 대응 능력은 평소에 얼마나 준비해뒀는지에 달려 있다는 것이었습니다. 매뉴얼이 있다고 안심할 게 아니라, 실제로 새벽에 혼자 봐도 이해할 수 있는 수준으로 문서를 다듬어두는 게 진짜 중요하다는 걸 그날 확실히 느꼈습니다.

운영 담당을 맡고 계신 분들이라면, 장애가 나기 전에 "새벽 3시의 나"가 봐도 이해할 수 있는 대응 문서를 미리 준비해두시는 걸 추천합니다.