서비스 장애 발생 시 개발팀이 하는 일 - 대응 순서와 역할 정리

서비스가 멈추면 사용자도 불편하지만, 내부는 더 빠르게 긴장합니다. “결제 안 돼요”, “로그인이 안 됩니다”, “앱이 하얗게 떠요” 같은 제보가 들어오는 순간부터 분위기가 달라집니다. 특히 실시간 서비스라면요. 누군가는 바로 묻습니다. “지금 장애 맞나요?” 그리고 그 다음 질문은 거의 정해져 있습니다. “어디서부터 봐야 하죠?”

장애 대응은 ‘천재 한 명이 해결’ 같은 이야기로 흐르기 쉽지만, 실제 현장에서는 순서와 역할이 더 중요합니다. 누가 먼저 확인하고, 어떤 기준으로 심각도를 잡고, 어떤 방법으로 복구할지 흐름이 잡혀 있어야 시간이 줄어듭니다.

 

 

 

 

알림이 울리면, 먼저 “장애인지 아닌지”부터 가릅니다

서비스 장애는 종종 ‘느낌’으로 시작합니다. 고객센터 문의가 늘고, 모니터링 알람이 연달아 울리고, 트래픽 그래프가 이상하게 꺾입니다. 하지만 모든 알람이 진짜 장애는 아닙니다. 일시적인 외부 네트워크 문제일 수도 있고, 특정 통신사 구간 이슈일 수도 있고, 한 지역에서만 발생하는 현상일 수도 있습니다.

그래서 초기에는 진단보다 확인이 먼저입니다. “전체 사용자에게 발생하나?”, “특정 기능만 안 되나?”, “지금도 재현되나?”를 짧게 확인합니다. 이때 가장 도움이 되는 건 재현입니다. 실제로 로그인, 결제, 검색 같은 주요 기능을 직접 눌러보고, 동일 현상이 반복되는지 확인합니다. 단문으로 말하면 이렇습니다. 상황을 먼저 붙잡습니다.

현장에서 자주 하는 빠른 확인

• 특정 기능만 문제인지(로그인/결제/검색 등) 또는 전체 다운인지
• 모든 사용자에게 발생하는지, 일부 환경(기기/OS/통신사)인지
• 최근 배포가 있었는지(방금 올린 변경이 있는지)

 

심각도를 정하고, “한 명이 지휘”하게 만듭니다

장애가 맞다고 판단되면 곧바로 심각도를 잡습니다. 심각도는 감정이 아니라 기준으로 정하는 편이 낫습니다. 결제가 멈춘 장애와, 특정 페이지 레이아웃이 깨진 이슈는 대응 방식이 달라야 하기 때문입니다. 여기서 흔히 나오는 말이 있습니다. “지금 영향 범위가 어느 정도죠?” 영향 범위가 정리되면 의사결정이 빨라집니다.

그리고 바로 역할을 나눕니다. 현장에서는 워룸(장애 대응 채널)을 만들고, 한 명이 사건 대응을 리드합니다(Incident Commander처럼 운영하는 팀도 많습니다). 리더가 있어야 “누가 뭘 하는지”가 흩어지지 않습니다. 모두가 동시에 똑같은 로그를 보고 있으면 시간이 새기 쉽습니다. 사람을 먼저 배치합니다.

보통 이렇게 나뉩니다

• 리드(조율): 지금 우선순위, 다음 행동, 시간 기록
• 조사(기술): 로그/지표/배포 이력 확인
• 커뮤니케이션: 고객센터/운영팀/내부 공지 공유

 

로그와 지표로 “어디가 아픈지” 범위를 좁힙니다

장애 대응의 절반은 원인을 ‘맞히는’ 게 아니라 ‘좁히는’ 일입니다. 전체가 멈춘 건지, 특정 API만 터진 건지, DB가 병목인지, 캐시가 죽었는지, 외부 연동(결제사/인증/지도 등)이 막혔는지 범위를 줄여야 합니다.

그래서 개발팀은 모니터링 지표를 먼저 봅니다. 에러율(5xx), 응답 시간, 트래픽 변화, CPU/메모리, DB 커넥션 수, 큐 적체 같은 값입니다. 동시에 로그를 봅니다. “에러가 어떤 경로에서 터지는지”를 알면 다음 행동이 바로 나옵니다. 범위가 좁아지면 해결이 보입니다.

이때 자주 나오는 질문들(자연스럽게 이런 흐름으로 이어집니다)

• “5xx가 늘었는데, 특정 엔드포인트만 그런가요?”
• “DB 커넥션이 꽉 찼나요, 쿼리 지연이 늘었나요?”
• “최근 배포 이후부터 시작된 건가요?”

 

최근 변경(배포)을 의심하는 이유가 있습니다

장애가 나면 사람들은 본능적으로 “서버가 터졌나?”부터 떠올립니다. 하지만 현장에서는 상당히 자주 “방금 바뀐 것”이 원인인 경우가 있습니다. 코드 변경, 설정 변경, 인프라 변경, 외부 키 만료, 인증서 만료처럼요. 그래서 대응팀이 가장 먼저 확인하는 것 중 하나가 배포 이력입니다.

여기서 판단이 갈립니다. “되돌리면 빨리 살 수 있나?” 만약 최근 배포가 원인 가능성이 높고, 롤백이 안전하다면 빠르게 되돌리는 선택을 합니다. 완벽한 원인 분석은 복구 후에 해도 됩니다. 서비스 장애 대응에서는 ‘복구’가 1순위인 순간이 많습니다. 우선 살리고, 그다음 따집니다.

현장에서 자주 쓰는 선택지

• 롤백: 마지막 정상 버전으로 되돌리기
• 핫픽스: 문제 지점만 빠르게 수정해 재배포
• 기능 차단: 문제 기능을 잠시 꺼서 전체를 살리기(플래그/스위치 활용)

 

복구는 “완벽하게”보다 “안전하게”가 먼저입니다

서비스 장애 상황에서 모두가 원하는 건 “완벽한 해결”이지만, 실제로는 “안전한 복구”가 더 먼저 나옵니다. 결제가 멈췄다면 결제 기능만이라도 먼저 정상화하고, 나머지 부가 기능은 나중에 고칠 수 있습니다. 로그인 장애라면 일단 로그인 경로를 살리고, 부가 로깅이나 추천 기능은 잠시 내려둘 수도 있습니다.

이때 중요한 게 재발 방지보다 “2차 사고 방지”입니다. 복구 과정에서 트래픽이 한꺼번에 몰리거나, 재시도 요청이 폭주하거나, 배치 작업이 쌓여서 또 다른 병목을 만들 수 있습니다. 그래서 단계적으로 올립니다. 일부 서버부터, 일부 트래픽부터. 천천히 살립니다.

복구 단계에서 자주 하는 조치

• 트래픽 분산/제한(레이트 리밋, 임시 차단)
• 캐시 활용으로 DB 부담 줄이기
• 타임아웃/재시도 정책 조정(폭주 방지)

 

커뮤니케이션은 ‘정확한 한 줄’이 가장 도움이 됩니다

장애가 길어질수록 내부 문의는 폭발합니다. 운영팀은 사용자 문의를 받고 있고, CS는 답변 문구를 요청하고, 경영진은 “언제 복구되냐”를 묻습니다. 이때 개발팀이 기술 설명을 길게 하면 오히려 혼란이 커집니다.

현장에서는 보통 세 가지를 짧게 공유합니다. “현재 영향”, “현재 조치”, “다음 업데이트 시간”입니다. 예를 들어 “로그인 일부 실패율 증가 확인, 원인 추적 중이며 롤백 검토, 15분 뒤 다음 상황 공유” 같은 식입니다. 

 

 

 

복구가 되면 끝이 아니라, “정상 확인”을 합니다

서비스가 다시 열렸다고 해서 바로 끝내면 위험합니다. 일부 사용자만 정상일 수도 있고, 특정 기능만 살아있을 수도 있습니다. 그래서 복구 직후에는 정상 확인을 합니다. 알람이 내려갔는지, 에러율이 안정됐는지, 지표가 원래 수준으로 돌아왔는지, 그리고 실제 사용자 시나리오가 되는지 다시 눌러봅니다.

여기서 자주 나오는 말이 있습니다. “지금은 정상인데, 뒤에 쌓인 게 터질 수 있어요.” 장애 중에 적체된 작업(큐, 배치, 재시도 요청)이 복구 후에 몰려 또 다른 문제를 만들 수 있습니다. 그래서 일정 시간은 관찰 모드로 둡니다. 복구 후가 더 조용해야 진짜 복구입니다.

 

 

마지막은 사후 정리입니다, 그리고 이게 다음 장애를 줄입니다

장애가 지나가면 팀은 바로 회고(포스트모템)를 합니다. 여기서 분위기가 중요합니다. 누굴 탓하는 자리가 아니라, 다음에 같은 상황이 왔을 때 시간을 줄이는 자리입니다. 어떤 신호가 먼저 왔는지, 왜 늦게 발견했는지, 복구를 더 빨리 할 수는 없었는지, 문서와 알람은 충분했는지 정리합니다.

사후 정리에서 흔히 나오는 산출물도 있습니다. 재발 방지 티켓, 알람 임계치 조정, 런북(대응 매뉴얼) 업데이트, 배포 프로세스 보완 같은 것들입니다. 그리고 다음 장애에서 가장 큰 차이를 만드는 건 거창한 기술이 아니라 이런 “작은 정리”인 경우가 많습니다. 기록이 남으면 다음엔 더 빠릅니다.

현장에서 자주 남기는 항목

• 타임라인: 언제 무엇이 발생했고, 누가 무엇을 했는지
• 영향 범위: 어떤 사용자/기능에 얼마나 영향이 있었는지
• 원인과 촉발 요인: 직접 원인 + 왜 그때 터졌는지
• 개선 작업: 알람/배포/테스트/운영 프로세스 보완

 

---

 

 

서비스 장애는 “갑자기 터진 사건”처럼 보이지만, 대응은 순서가 있습니다. 확인 → 범위 좁히기 → 복구 → 공유 → 정상 확인 → 사후 정리. 이 흐름만 잡혀 있어도, 실제 현장에서는 시간이 크게 줄어듭니다. 다음에 비슷한 상황이 오더라도 덜 흔들립니다.