약속할 수 있는 것은 해결 시각이 아니라 다음 보고 시각이다

한 줄 요약

FDE 의 장애 대응은 시스템이 아니라 보고서에서 끝나고, 기술적으로 완벽히 고쳐도 보고가 늦거나 모호하면 고객의 기억에는 불안만 남는다.

왜 이게 필요했나

여덟 개 기술 도메인 중 고객 커뮤니케이션만 기술이 아닙니다. 그런데 나머지 일곱 개를 고객에게 배달하는 통로가 이것이라서, 여기가 막히면 진단이 맞아도 프로젝트가 실패합니다.

가장 흔한 실패는 기대치 관리에서 나옵니다. 그리고 그 실패는 대개 약속의 단위가 잘못되어서 생깁니다.

원인을 모르는 단계에서 "오후까지 해결하겠습니다" 라고 말하는 것은 약속이 아니라 도박입니다. 약속할 수 있는 것은 해결 시각이 아니라 다음 보고 시각입니다. "한 시간 뒤에 아는 것과 모르는 것을 정리해 보고드리겠습니다" 는 언제나 지킬 수 있고, 지켜질 때마다 신뢰가 쌓입니다.

무소식 20분은 고객의 상상 속에서 장애를 두 배로 키웁니다. 그래서 장애 중 첫 메시지에 주기가 들어가야 합니다. "복구까지 30분마다 보고드리겠습니다."

어떻게 동작하나

장애 보고서의 구조는 평시 문서와 순서가 다릅니다. 평시에는 배경부터 쓰지만, 장애 보고서는 영향부터 씁니다.

영향     : 결제 API 5xx 비율 평시 0.1% → 최대 7% (14:10–15:40)현재 상태: 완화 조치 적용 완료, 오류율 평시 범위로 복귀 확인잠정 원인: 14:05 설정 배포에서 DB 커넥션 풀 크기 축소다음 단계: 원복 완료. 재발 방지로 배포 전 설정 diff 점검 절차를 제안 예정

읽는 사람이 가장 먼저 알아야 할 것은 "지금 누가 무엇을 못 하는가" 와 "지금은 괜찮은가" 입니다. 원인 분석은 궁금해도 그다음입니다. 원인부터 쓴 보고서는 세 문단을 읽어야 지금 상태를 알 수 있고, 임원이 읽는 문서에서 그 세 문단은 읽히지 않습니다.

그리고 세 가지 규칙이 더 있습니다.

숫자로 씁니다. "많은 사용자가 영향을 받았습니다" 가 아니라 "500 응답이 평시 33건에서 1분간 70건으로" 입니다. 형용사는 읽는 사람마다 다르게 해석되고, 그 차이가 나중에 분쟁이 됩니다.

사람을 주어로 쓰지 않습니다. "담당자가 설정을 잘못 바꿔서" 가 아니라 "설정 변경 이후" 입니다. 고객사 보고서에 특정 담당자가 지목되면 다음 장애에서 그 사람은 정보를 숨깁니다. 비난 없는 보고서는 도덕이 아니라 다음 진단의 속도를 사는 투자입니다.

전문용어를 번역합니다. "파드가 재시작 루프에 빠졌습니다" 가 아니라 "서버가 반복적으로 꺼졌다 켜지는 상태라 접속이 끊깁니다" 입니다. 상태 코드도 마찬가지입니다. 500 이라는 숫자는 엔지니어에게만 의미가 있고, 고객에게는 "결제가 실패했습니다" 가 필요합니다.

현장에서 만나는 모습

같은 상황에서 신뢰를 깎는 문장과 쌓는 문장이 갈립니다.

원인을 아직 모를 때 "저희 쪽 문제는 아닌 것 같은데요" 는 방어입니다. "지금까지 네트워크와 인증은 정상으로 확인했고, 데이터 계층을 보는 중입니다. 30분 뒤에 중간 결과를 공유드리겠습니다" 는 같은 상태를 말하면서 신뢰를 쌓습니다.

차이는 세 요소입니다. 확인된 사실, 지금 하는 일, 다음 보고 시각. 이 셋이 들어 있으면 원인을 모르는 상태에서도 보고가 성립합니다.

마지막으로 에스컬레이션. 이것은 실패의 자백이 아닙니다. 30분 안에 진전이 없으면 올린다는 자기 규칙을 미리 정해 두면, 올리는 결정이 감정이 아니라 절차가 됩니다. 고객 앞에서 "전문 인력을 붙였습니다" 는 무능의 신호가 아니라 대응의 신호로 읽힙니다.

다음 실습에서 할 것

앞의 세 코스에서 찾아낸 값들을 재료로, 필수 절이 갖춰지고 숫자가 들어가고 사람을 지목하지 않으며 고객용 요약이 기술 용어 없이 쓰인 장애 보고서 한 장을 만듭니다. 채점은 문장의 좋고 나쁨이 아니라 그 조건들의 충족 여부만 봅니다.