장애 발생 시 대응 체계

Chapter 6. 회사 시스템 파악

"서비스가 다운됐습니다."

Slack 알람이 울린다. 빨간색 메시지가 계속 올라온다.

[CRITICAL] 운영 서버 응답 없음 [CRITICAL] API 전체 다운 [CRITICAL] 사용자 접속 불가

팀 채널이 순식간에 난리가 났다. "확인 중", 누군가 "대시보드 체크", 누군가 "로그 보는 중" 급한 메세지가 쏟아진다. 보는 것만으로도 심장이 쿵쾅거린다. 손에 땀이 난다.

'내가 뭔가 잘못한 건가? 아까 개발 서버에 배포한 게 문제인가? 나 때문에 서비스가 멈춘 건가?' 한 것도 없는데 뭔가 찔린다. 전화벨이 울린다. 팀장이다. 옆자리 시니어 개발자가 재빠르게 노트북을 펴고 타이핑을 시작한다. 나는 그저 멍하니 화면만 바라본다.

'이 순간 나는 뭘 해야 하지?'

장애는 낯설고 무섭다. 하지만 대응 체계를 알면 훨씬 덜 무섭다. 여기서는 장애 등급이 무엇인지, 장애가 났을 때 어디에 보고하는지, 그리고 어떻게 에스컬레이션(Escalation)하는지 정리했다.

그런데 장애가 뭐지?

장애(Incident)란 서비스가 정상적으로 작동하지 않는 상태를 말한다.

사용자가 로그인을 못 하거나, 결제가 안 되거나, 페이지가 안 열리거나, 앱이 계속 튕기는 상황. 이 모든 게 장애다.

장애와 버그의 차이

버그: 기능이 의도대로 작동하지 않는 것. 예를 들어 특정 조건에서만 날짜가 잘못 표시된다.

장애: 서비스 자체가 멈추거나 심각하게 느려지는 것. 사용자가 서비스를 쓸 수 없다.

비유로 설명하자면 버그는 자동차의 에어컨이 안 나오는 것. 불편하지만 운전은 할 수 있다. 천천히 정비소 가면 된다. 장애는 자동차 시동이 아예 안 걸리는 것. 차를 못 쓰는 상태이다. 지금 당장 견인차를 불러야 한다.

버그는 식당 메뉴판에 가격 오타 정도이다.고쳐야 하지만 장사는 된다. 장애는 식당 주방에 불이 난 것. 당장 문 닫고 해결해야 한다. 버그는 나중에 고칠 수 있다. 하지만 장애는 지금 당장 해결해야 하는 문제다.

쉽게 말해 버그는 나중에 고칠 수 있다. 하지만 장애는 지금 당장 해결해야 문제이다.

장애 등급 구분

모든 장애가 똑같이 심각한 건 아니다. 회사는 장애를 등급으로 나눈다.

Critical (크리티컬)

정의: 서비스 전체가 멈췄거나, 핵심 기능이 완전히 작동하지 않는 상태.

예시:

전체 서비스 다운

결제 시스템 완전 중단

로그인 불가

데이터베이스 접근 불가

개인정보 유출

대응 시간: 즉시 (5분 이내)

대응 방법: 모든 개발자 소집, 즉각 대응

Critical 장애를 처음 경험한 순간은 끔직했다. 금요일 저녁이던가 퇴근하려고 가방을 챙기는데 사내메신저 알람이 요란하게 울렸다. "운영 DB 연결 끊김". 팀장은 전화를 걸기 시작했고, 이미 퇴근한 시니어들이 회사로 돌아와 다시 노트북을 켰다. 나는 신입이라 뭘 해야 할지 몰라 그냥 자리에 앉아 있었다. 시니어가 말했다. "일단 웹사이트 켜놔. 내가 조치하는 동안 오류 나는지 확인해 줘" 나는 그저 사이트만 보면서 변화를 실시간으로 공유했다. "여전히 오류가 나요." "지금은 간혈적으로 오류가 나요" 새로고침이 내가 할 수 있는 전부였지만, 도움을 줄 수 있어 마음은 편안했다. 30분 후 복구됐고, 팀장이 "수고했다"고 말했다. 그날 밤 치킨을 먹으며 수고했다는 한마디가 여전히 귓가에 멤돈다.

High (높음)

정의: 주요 기능이 작동하지 않지만, 일부 서비스는 가능한 상태.

예시:

특정 지역 사용자 접속 불가

검색 기능 중단

이미지 업로드 실패

알림 발송 실패

대응 시간: 30분 이내

대응 방법: 담당 팀 즉시 대응, 필요 시 타팀 협조

Medium (중간)

정의: 일부 기능에 문제가 있지만, 핵심 서비스는 정상.

예시:

특정 페이지 로딩 느림

일부 통계 데이터 업데이트 지연

부가 기능 오작동

대응 시간: 2시간 이내

대응 방법: 업무 시간 내 대응, 긴급 패치 준비

Low (낮음)

정의: 사용자 경험에 거의 영향 없는 경미한 문제.

예시:

UI 표시 오류

로그 누락

내부 도구 버그

대응 시간: 다음 업무일

대응 방법: 백로그에 추가, 정기 배포 시 수정

실전 팁

장애 등급은 회사마다 이름이 조금씩 다를 수 있다. 일반적으로는 '긴급','높음','보통','낮음' 이름은 달라도 기본 개념은 같다. 입사 첫 주에 "우리 회사 장애 등급 기준이 어떻게 되나요?" 물어보자.

장애 보고 채널

장애가 발생했을 때 어디에 알려야 할까?

Slack (또는 Discord)

가장 흔한 장애 보고 채널. 보통 이런 채널들이 있다.

#운영 환경 자동 알람

#장애 대응 전용 채널

#온콜 담당자 호출 채널

장애를 발견했다면 해당 채널에 즉시 공유한다.

한번은 오후 2시쯤 QA팀에서 연락이 왔다. "결제가 안 되는데요?" 나는 로컬에서 테스트해봤다. 안 됐다. 운영 환경도 확인했다. 역시 안 됐다.

'이건... 장애 아닌가?'

손이 떨렸다. 장애 채널에 글을 쓰기 시작했다. 그런데 뭐라고 써야 할지 모르겠는 거다. 한참을 고민하다가 옆자리 동료에게 물었다. "결제가 안 되는 것 같은데, 장애 보고 어떻게 해요?" 동료가 봐주고 말했다. "그래, 이거 장애 맞네. 일단 채널에 간략하게 올려주세요."

나는 떨리는 손으로 메시지를 올렸다. "결제 API 응답 안 됨 방금 전부터 확인 중" 30초 만에 시니어 개발자가 대답했다. "확인했어. DB 커넥션 문제네. 내가 처리할게." 그렇다. 장애는 빨리 알리는 게 제일 중요하다.

전화

Critical 장애는 Slack만으로 부족하다. 담당자가 Slack을 안 보고 있을 수 있다. 이럴 땐 전화한다.

누구한테 전화하나?

온콜 담당자

팀장

시니어 개발자

전화 에티켓:

간단명료하게: "지금 운영 서버 다운됐어요"

패닉하지 않기: 침착하게 상황 설명

확인된 사실만 전달

이메일

긴급한 상황이 아니라면 이메일로 보고하기도 한다. 특히 사후 보고는 대부분 이메일로 한다. 그런데 한시가 급한 장애인데

에스컬레이션 프로세스

에스컬레이션(Escalation)이란 문제를 더 높은 레벨의 담당자에게 전달하는 것이다.

언제 에스컬레이션하나?

혼자 해결할 수 없을 때

15분 안에 원인을 못 찾겠다

해결 방법을 모르겠다

권한이 없어서 조치할 수 없다

장애 등급이 높을 때

Critical이나 High 장애는 무조건 에스컬레이션

시간이 지나도 해결 안 될 때

30분 넘게 대응했는데 개선이 없다

에스컬레이션 순서

일반적인 에스컬레이션 흐름은 이렇다.

1단계: 같은 팀 동료

옆자리 개발자에게 도움 요청

"잠깐 봐줄 수 있어? 이 에러 뭔지 모르겠어"

2단계: 시니어 개발자

팀 내 시니어에게 에스컬레이션

Slack DM 또는 전화

3단계: 팀장

시니어도 해결 못 하면 팀장에게

의사결정 필요한 경우 (롤백, 긴급 배포 등)

4단계: 인프라 팀 / 타팀

DB 문제 -> DBA 팀

네트워크 문제 -> 인프라 팀

외부 API 문제 -> 해당 서비스 담당 팀

5단계: 경영진

정말 심각한 상황

고객 대응, 언론 대응 필요 시

에스컬레이션 메시지 작성법

에스컬레이션할 때는 간단명료하게.

나쁜 예:

저기... 혹시 괜찮으시면... 제가 지금 뭔가 문제가 있는 것 같은데... 시간 되실 때 한번 봐주실 수 있으실까요...?

좋은 예:

[긴급] API 응답 없음 - 발생 시간: 14:23 - 증상: 모든 API 500 에러 - 시도한 것: 로그 확인, 서버 재시작 - 상황: 해결 안 됨, 도움 필요

포함할 정보:

무슨 문제인가?

언제 발생했나?

무엇을 시도했나?

왜 에스컬레이션하나?

실전 팁

긴급을 요할 때는 "죄송하지만" "혹시 괜찮으시면" 같은 말은 빼자. 긴급 상황에서는 직접적으로 말하는 게 더 좋다. 시니어들도 이해한다.

신입은 장애 대응 때 뭘 하나?

"나는 아직 신입인데, 장애 대응 때 할 수 있는 게 있을까?" 물론있다. 거창한 일이 아니더라도 도움이 될만한 방법을 정리해보았다.

1. 상황 공유

대시보드 보면서 변화 공유하기.

"에러율 50%로 떨어졌어요" "응답 시간 정상으로 돌아왔어요"

이것만으로도 큰 도움이 된다.

2. 로그 검색

시니어가 원인 찾는 동안 로그 검색 돕기

3. 문서 작성

장애 대응 중 일어난 일들을 빠짐엇이 기록하기. 나중에 장애 보고서 쓸 때 유용하다.

4. 외부 소통

고객센터나 다른 팀에 상황 업데이트 전달하기

"지금 복구 중입니다" "10분 내 해결 예상입니다" 라며 빠르게 전달하자.

5. 배우기

무엇보다 중요한 건 관찰하고 배우는 것. 시니어가 어떻게 대응하는지 지켜보자.

어떤 로그를 보는가?

어떤 명령어를 실행하는가?

누구에게 연락하는가?

어떻게 원인을 찾는가?

다음에 비슷한 장애가 오면 혼자서도 할 수 있다.

체크리스트: 장애 대응 준비

입사 첫 주~2주에 다음 항목들을 확인했는지 체크하자.

장애 등급

우리 회사 장애 등급 기준을 알고 있는가?

각 등급별 대응 시간을 알고 있는가?

보고 채널

장애 보고 Slack 채널을 알고 있는가?

팀장 전화번호를 저장했는가?

시니어 개발자 연락처를 저장했는가?

에스컬레이션

에스컬레이션 순서를 알고 있는가?

어떤 상황에 에스컬레이션하는지 아는가?

에스컬레이션 메시지 템플릿이 있는가?

기타

장애 대응 매뉴얼 위치를 알고 있는가?

모니터링 대시보드 URL을 북마크했는가?

로그 확인 방법을 알고 있는가?

장애는 무섭지만, 혼자가 아니다

첫 장애는 정말 무섭다. 심장이 쿵쾅거리고, 손에 땀이 나고, 머릿속이 하얘진다.

괜찮다. 그건 당연하다. 나도 그랬고, 시니어들도 처음엔 그랬다.

하지만 기억하자. 장애 대응은 혼자 하는 게 아니다. 팀이 함께한다. 시니어가 있고, 동료가 있고, 매뉴얼이 있다. 그리고 무엇보다, 장애는 배움의 기회다. 장애를 겪을 때마다 시스템을 더 깊이 이해하게 된다. 어떤 부분이 취약한지, 어떻게 대응해야 하는지 배운다.

첫 장애를 잘 넘기면, 두 번째는 덜 무섭다. 세 번째는 더 자신 있게 대응한다. 그렇게 성장한다.