반복되는 장애, 우리는 어떻게 대응하고 있을까?

1. 장애 대응 과정에서 보였던 한계들

우리 팀은 주로 고객센터(CS) 인입을 통해 장애를 인지하곤 했다. CS 인입이 없으면 문제를 모르는 경우도 많았고, 문제가 확인된 이후에는 개발팀이 임시 조치를 한 뒤 사용자에게 안내하는 방식이 반복되었다.

 

처음에는, 이 방식이 자연스럽다고 여겼지만 반복될수록 여러 문제점이 보이기 시작했다.

 

💢 CS 인입 정보 공유 지연
예를 들어 5월 19일에 들어온 고객 문의가 4~5일 뒤에야 저에게 전달되었고, 그사이 대응이 늦어질 수밖에 없었다.

 

💢 상황 공유의 부재
개발팀에서 조치하고 있는지, 근본 원인이 무엇인지 등 중요한 정보가 CS팀과 공유되지 않았다. 이에 따라 CS팀은 사용자에게 명확한 설명을 할 수 없어 불완전한 대응으로 이어졌다.

 

💢 임시 조치 후 회고 없음
대부분의 장애는 임시 조치에 그치고 근본 원인에 대한 회고가 없었다. 결국 같은 유형의 CS가 반복해서 발생하게 되었다.

2. 개선을 위해 내가 시도한 것들

위와 같은 개선했으면 하는 부분들이 있었기에 내가 해볼 수 있는 것들을 진행했다.

 

✅ CS별 타임라인 작성 및 공유

CS가 들어왔을 때 개발팀에서 처리하고 있는 상황들을 기록해서 CS팀에게 공유하기 시작했다. 간단하게 구글 스프레드 시트를 사용해서 각 CS에서 대해서 타임라인 작성했다.

[2025-05-11 14:25:00] 미지급 보상 건에 대한 원인 분석 중
[2025-05-11 14:29:00] 캐시 데이터 정합성 이슈로 일부 보상 미지급 확인
[2025-05-11 14:30:00] 미지급된 보상 유저에게 지급 완료

 

✅ 근본 원인 분석 및 구조적 해결안 제시

임시 조치로 해결된 이슈에 대해서 구조적인 문제와 해결 방안을 공유를 했다. 미지급된 유저 보상의 경우 동시성 이슈로 인해서 발생했던 건이었는데, 조사를 해보고 해결 방안으로 분산 시스템에서 락 기능 개발 및 적용을 제시했다. 하지만 다른 일을 진행 해야 하거나 공수 산정을 했을 때 비용이 많이 든다는 등의 이유로 무산되었다. 이런 경우가 여러 번 반복이 되었다. 아쉬운 상황이다.

동시성 이슈로 인해 발생하는 문제 ➔ Lock을 통해 분산 시스템에서 동시성 제어
로그 기반 포인트 획득/차감으로 인한 타임아웃 문제 ➔ 정산 시스템 구성을 통한 처리 데이터 축소

 

✅ 사내 세미나 발표
장애 대응에 대한 설명과 프로세스를 사내 세미나에서 발표했다. 사용자와 기업 모두의 이익을 위해 꼭 필요한 부분이라고 생각이 들었기 때문이다. 세미나 당시에는 잘 들어주시는 것 같았지만 이것 또한 개발팀에서 받아들여지지 않았다.

 

그 당시에 했던 세미나를 간단하게 정리한 블로그 : [장애 대응에 대한 각 단계에 대한 설명] 

3. 돌아보며 – 개인 개발자의 한계

이 과정에서, 혼자 고민하고 바꾸려는 노력의 한계를 느꼈다. 개선안이 아무리 좋아도 팀이 함께 움직이지 않으면 실현되기 어렵다. 사용자와 회사를 위한 '좋은 개발 문화'는 반드시 필요하지만, 눈앞의 일에 치이다 보면 장기적인 중요성을 놓치게 된다. 그 결과, 반복되는 장애로 인해 사용자의 신뢰가 무너질 수도 있다.

마무리하며

신뢰는 하루아침에 쌓이지 않지만, 한순간에 무너질 수 있다. 장애 대응은 단순한 버그 픽스가 아닌, 사용자와 회사를 지키는 과정이라고 생각한다. 조금씩이라도 개선하려는 시도가 이어지고, 언젠가는 문화로 정착되길 바라며 이 글을 마친다.