글을 작성하게 된 계기
전사 차원의 장애를 보고 겪으며, 생각을 정리하기 위해 글을 작성하게 되었습니다.
1. 장애에 대한 생각 변화
입사 후 몇 차례 전사적인 장애를 겪으면서, 처음에는 단순한 기술적 결함이나 실수라고만 생각했습니다. 하지만 꽤 큰 비용을 들이고 모니터링을 강화 했음에도 비슷한 문제가 반복 되는 것을 보며, 장애는 단순한 기술적 문제를 넘어, 조직 문화와 관련이 있겠다 는 생각이 들었습니다. 많은 돈을 사용하고 새로운 기술을 도입했지만 문제가 해결되지 않았으니까요. 이렇게 생각이 변하는 과정에서 좋은 장애 대응 문화와 원칙 이 무엇인지에 대해 고민하게 되었습니다.
- 장애는 단순히 기술적인 문제를 넘어, 조직의 문화와 시스템이 어떻게 작동하는지를 보여주는 중요한 지표
- 장애 대응은 기술적인 대응뿐만 아니라, 조직의 문화와 시스템을 개선하는 기회로 삼아야 함
2. 좋은 장애 대응 문화와 원칙
우리 회사와 다른 회사의 장애 대응 문화 비교, 실수나 실패에 대한 포스팅들을 읽으며 다음과 같은 네 가지 절차와 원칙이 좋은 장애 대응 문화 를 만들어가는 데 꼭 필요하다는 생각이 들었습니다.
- 장애 전파
- 빠른 장애 대처
- 재촉하지 않기
- 탓 하지 않고 시스템으로 문제 해결하기
- 회고와 학습
2-1. 장애 전파
장애가 발생했을 때 가장 먼저 필요한 것은 빠르고 정확한 전파 입니다. 장애도 문제지만, 그보다 더 위험한 것은 정보의 지연 이나 왜곡 으로 인해 발생하는 2차 피해입니다. 문제가 즉시 공유되지 않으면, 다른 팀원이나 부서가 여전히 시스템이 정상 작동한다고 판단하고 작업을 계속하게 되고, 그로 인해 추가 문제 발생, 데이터 손상, 심지어는 금전적인 피해까지 이어질 수 있습니다.
저희 팀은 잠수함 패치라고 부르는, 특정 기능을 수정한 후, 혼자만 알고 있는 상황을 가장 위험하게 여기고 있습니다.
예를 들어, 결제 시스템에 문제가 생겼는데 이 사실이 늦게 전파된다면, 사용자는 결제가 실패한 줄 알고 다시 결제를 시도해 이중 결제가 발생할 수 있고, 이는 환불 처리나 정산 등 후속 프로세스에까지 영향을 줄 수 있습니다. 이런 상황은 신뢰 저하 는 물론이고, 직접적인 금전적 손실 을 유발할 수 있습니다. 따라서 장애를 처음 인지한 사람은 즉시 상황을 팀과 관련 부서에 공유해야 합니다. 양식도 중요할 것 같은데요, 사람이 한 눈에 알아볼 수 있어야겠죠?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. 발견자 – 누가 처음 발견했는가
ex) 홍길동 (backend 팀)
2. 발견 시각 – 언제 발견했는가
ex) 2025-06-21 22:17
3. 장애 시스템 – 어떤 시스템에서 문제가 발생했는가
ex) 결제 API / KICC 서브몰 / 메일 발송 서비스
4. 장애 증상 – 무엇이 잘못되었는가 (요약)
ex) 이중 결제 발생 / 메일 발송 안 됨 / 500 에러
4. 영향 범위 – 어떤 서비스나 고객에 영향이 있는가
ex) 전체 결제 실패 / 특정 카드사에서만 발생 / 관리자 전용 기능만 오류
5. 1차 조치 현황 – 임시 조치나 대응 중인 내용
ex) 장애 조치 중 / 임시 SMTP 서버 전환 예정 / 롤백 검토 중
6. 비고 또는 로그 – 재현 방법이나 에러 로그 등 참고
장애 전파에는 메신저, 이메일, 전화 등 다양한 수단을 사용할 수 있으며, 핵심은 정확한 정보를 신속하게 공유하는 것 입니다. 알림을 사용할 경우, 명확한 지표를 세워두고요. 누가 언제 어떤 문제를 발견했는지, 어떤 영향이 있는지, 현재 조치 상황은 어떤지를 함께 전달해 팀원들이 상황을 정확히 파악하고 빠르게 대응할 수 있도록 합니다. 빠를수록 장애 확산을 막고 조기 대응 할 가능성도 높아지고요.
장애 전파는 단순한 보고가 아닌, 조직의 피해를 줄이는 첫걸음 입니다.
2-2. 빠른 장애 대처
장애가 발생했을 때, 가장 중요한 점은 장애를 빠르게 해결하는 것 입니다. 원인이 무엇이든, 누가 장애를 발생시켰든 먼저 해야 할 일은 서비스의 정상화 입니다. 사용자의 불편을 최소화하고, 피해를 줄이기 위해서는 빠른 판단 과 협업 이 중요합니다. 이때, 정해진 장애 대응 프로세스 가 있다면 훨씬 문제를 빠르게 해결할 수 있겠죠?
- 빠른 판단
- 협업
최근 팀원 한 분과 고객에게 메일을 발송하는 기능이 정상적으로 동작하지 않는 이슈 를 발견 했습니다. 이때 프로젝트 마감으로 모두 바쁜 상황이었는데, 팀원은 아무 말 없이 하던 작업을 멈추고, 기능 복구를 위해 최선을 다했습니다. 먼저 사용자들이 메일을 받을 수 있도록 임시 메일 서비스를 사용해 메일 발송을 가능하게 했고, 함께 야근을 하며 안정적인 내부 서비스로 전환했죠.
- 장애 발생 감지
- 고객이 빠르게 사용할 수 있도록 임시 메일 발송 서비스로 대처
- 안정적으로 메일 기능을 사용할 수 있도록 내부 서비스로 전환
추후 티타임을 가지며 이야기를 나누었는데, 그분은 장애를 해결하는 것이 최우선 이라고 판단했다고 하셨습니다. 메일이 제대로 발송되지 않으면, 가맹점이 중요한 안내를 받지 못해 이탈할 수도 있고, 이는 회사 신뢰와 연결되는 문제 라고요. 저는 단순히 기술이나 장애 대응만 생각했는데, 기술을 넘어 고객과의 신뢰까지 고려하셨더라고요.
해당 팀원은 6년차 개발자로, 코드를 넘어 비즈니스와 고객까지 고려할 줄 아는 분인데 매번 정말 많이 배웁니다. 🙇
2-3. 재촉하지 않기
장애가 발생했을 때, 빠른 대응도 중요하지만 재촉하는 것은 오히려 역효과를 낼 수 있습니다. 재촉은 팀원에게 심리적 압박 을 주고, 실수를 유발할 수 있습니다. 이미 장애 상황에 이미 스트레스가 많은데, 여기에 재촉까지 더해지면 오히려 문제가 보이지 않고, 추가적인 실수가 발생할 수도 있죠. 따라서 장애 대응 시에는 차분하게 상황을 파악하고, 필요한 조치를 취하는 것이 중요합니다.
아무리 긴급한 상황이라도, 재촉보다는 차분하게 문제를 해결하는 것이 더 효과적 입니다. 또한 본인의 불안한 감정을 드러내면 오히려 팀원 간의 신뢰를 해칠 수 있습니다. 따라서 장애 대응 시에는 불안하고 힘들더라도 수습 중인 팀원을 믿고 기다리며, 모든 상황이 종료된 후, 이에 대해 이야기하는 것이 좋습니다.
2-4. 탓 하지 않고 시스템으로 문제 해결하기
절대 누구를 특정해 탓하지 않고 시스템으로 문제를 해결 해야 합니다. 문제의 원인이 특정인의 실수였다고 하더라도, 그것을 공개적으로 지적하거나 책임을 묻는 방식은 오히려 조직 전체에 위축 과 방어적인 분위기 를 만듭니다. 실수를 솔직하게 말할 수 없다면 사람들은 실수를 숨기게 되고, 이는 결국 더 큰 문제로 이어질 수 있죠. 따라서 장애가 발생했을 때는 누구의 잘못이 아니라 시스템의 문제로 보고, 구조적으로 개선하는 방향으로 나아가야 합니다.
예를 들어, 복잡한 비즈니스 때문에 검증 조건을 빠트려 장애가 자주 발생한다면 코드 리뷰를 강화 하거나 유사 케이스를 문서화 해서 공유하는 식으로요. 사람이 하는 일은 실수가 발생할 수 밖에 없고, 이를 개선하기 위해서는 비난하지 않는 문화, 시스템이 휴먼 에러를 막는 구조 가 만들어 져야 합니다. 특히 공개적인 채널 에서 상황 탓이나 비난을 하는 것은 정말 위험하다고 생각하는데요, 사람이 위축되고, 자책을 하며 악순환의 고리만 만들더라고요. 안그래도 해야 할 일이 많은데, 서로 위험을 감수하지 않으려고 한다면 문제가 더 커질 수 밖에 없겠죠.
- 남 탓, 시스템 탓. 혹은 짜증
- 공개적으로 비난/비판
- 책임자를 언급하고 교육하겠다고 하는 경우
제 사수는 제가 처음 하는 일이나 위험한 작업을 할 때, 항상 같이 남아서 봐주고, 필요한 경우 야근까지 불사하는데요, 그때마다 실수해도 괜찮다 고 말씀해 주셨습니다. 오히려 실수 안 하면 열심히 안 하는 것 이라고요. 이러다 보니 실수에 대한 두려움이 줄어들고 하나라도 더 팀에 도움이 될 만한 작업을 하고 싶어졌습니다.
이 자리를 빌어 Jay에게 감사하다는 말을 전하고 싶습니다. 🙏🏻
2-5. 회고와 학습
장애 이후에는 반드시 회고를 진행 하여 반성하고 학습합니다. 장애를 없애는 것만큼 중요한 것은, 같은 문제가 반복되지 않도록 조직이 성장하는 것입니다. 다 같이 이야기 하는 과정에서 내가 생각하지 못한 방안이 나오기도 하고요. 이 과정에서 중요한 것은 솔직한 공유 이며, 솔직함을 보장하려면 비난하지 않는다 는 원칙이 반드시 지켜져야 합니다.
회고는 책임을 묻는 자리가 아니라, 신뢰를 쌓고 시스템을 더 견고하게 만드는 시간이어야 합니다.
이러한 문화를 만드는 것은 결코 하루 아침에 만들어 지지는 않는 것 같습니다. 저희도 처음에 없던 문화를 만들어 가는 과정에서 시행착오가 있었고, 때로는 아쉬울 때도 있었습니다. 감정이 상할 때도 있었고요. 하지만 서로 솔직하게 말하고 개선하려다 보니 점차 나아지는 것을 느낄 수 있었네요. 이 외에도 장애를 탐지 해서 예방하거나 모니터링 체계를 개선, 테스트 커버리지를 확장, 피처 플래그(Feature Flag) 등 다양한 방법이 있는데요, 이는 이미 장애가 발생했을 때 와는 조금 다른 관점이라 제외했습니다.
- 장애 탐지
- 모니터링 체계 개선
- 테스트 커버리지 확장
3. 정리
현재 저희 개발자 팀원 들은 적어도 남을 탓하고 책임을 묻지 않습니다. 장애가 나면 당사자는 팀원에게 미안해하고, 모두가 최선을 다해 수습하려 하고요. 그랬기 때문에 이런 글을 편하게 작성할 수 있겠죠? 다만 전사 차원의 장애가 발생하면 생각이 다른 분들도 종종 보이는데요, 이 과정에서 생각이 많아졌습니다. 이 글을 작성하게 된 이유 중 하나기도 하고요. 항상 조심해서 최종 배포를 하지만, 사람이 하는 작업이기 때문에 실수는 발생할 수 밖에 없습니다. 그로 인해 사람이 비난 받고 위축되며, 해야 할 작업도 제대로 못하는 상황이 오지 않기를 바랍니다. 🙏🏻
- LINE의 장애 보고와 후속 절차 문화
- LINE 플랫폼 서버의 장애 대응 프로세스와 문화
- LINE - 효과적인 코드 리뷰를 위해서
- 배달의민족 - 공통시스템개발팀 코드 리뷰 문화 개선 이야기
- 배달의민족 - 결제는 계속된다: 결제 담당자가 장애에 대응하는 방법
- 배달의민족 - 우아~한 장애대응
- 네이버가 검색 서비스 장애율을 0%대로 낮춘 비결
- Kakao - 안정성을 위한 복구 체계
- 토스 서비스를 든든하게 지키는 사람들, 서버 플랫폼 팀을 만나다
- 데브시스터즈의 장애 대응 원칙과 방법
- How Organisations Can Learn from Failures
- Why Failing Is Critical to Your Team’s Success
- Why Failure Is Important in Leadership