같은 결제 장애, 두 번째 보고.
지난주 결제 서비스가 22분간 중단됐습니다. 운영자 A는 그날 저녁 장애보고서를 올렸습니다 — "21:05 결제 실패 급증, DB 커넥션 풀 고갈 확인, 21:27 인스턴스 재시작 후 정상화." 깔끔합니다. 무슨 일이 났고, 어떻게 복구했는지가 다 담겼습니다.
그런데 고객사 IT 담당자가 회신합니다. "복구는 알겠습니다. 왜 커넥션 풀이 고갈됐고, 다음 달에 또 안 난다는 보장은 무엇입니까? 재발방지대책을 정식 문서로 주세요."
A의 장애보고서는 사건을 정확히 적었지만, 여기서 멈췄습니다. 고객이 요구하는 건 한 단계 위의 문서 — RCA 보고서입니다. '무슨 일이 났나'가 아니라 '왜 일어났고, 누가, 언제까지, 어떻게 막는가'를 증명하는 문서. 이 모듈은 그 문서를 쓰는 법을 다룹니다.
- 1장애보고서와 RCA 보고서의 목적·범위 차이를 설명하고, 언제 RCA 보고서가 요구되는지 판단할 수 있다
- 2RCA 보고서의 표준 구성(문제 정의·영향·타임라인·분석·근본 원인·기여 요인·재발방지대책·검증)을 갖춰 쓸 수 있다
- 35 Whys와 피시본을 함께 사용해 단일 원인 단정을 피하고 여러 기여 요인을 드러낼 수 있다
- 4재발방지대책을 담당·기한·검증이 붙은 액션아이템 표로 만들고 추적할 수 있다
- 5사람이 아니라 시스템·절차의 빈틈을 보는(blameless) RCA 보고서를 작성할 수 있다
장애보고서에서 RCA 보고서로 — 무엇이 더해지나
복구를 기록하는 문서와, 재발방지를 증명하는 문서
장애보고서와 RCA 보고서는 같은 사건을 다루지만 묻는 질문이 다릅니다. 둘을 섞으면 둘 다 약해집니다.
장애보고서(인시던트 리포트)는 사건 직후에 빠르게 나오는 사실 기록입니다. 무엇이 언제 발생했고, 영향은 어디까지였으며, 어떤 조치로 정상화됐는지를 시간순으로 적습니다. 목적은 "지금 무슨 일이 있었는지 모두가 같은 그림을 보게 하는 것"입니다.
RCA 보고서는 그 위에서 며칠에 걸쳐 작성하는 분석·약속 문서입니다. 복구는 이미 끝났다고 보고, '왜 이 장애가 애초에 가능했는가'를 파고들어 근본 원인과 기여 요인을 밝히고, '어떻게 다시는 안 나게 하는가'를 담당·기한이 붙은 대책으로 약속합니다.
| 항목 | 장애보고서 | RCA 보고서 |
|---|---|---|
| 핵심 질문 | 무슨 일이 났나 / 어떻게 복구했나 | 왜 일어났나 / 어떻게 다시 막나 |
| 작성 시점 | 사건 직후(당일) | 복구 후(보통 수일 내) |
| 끝맺음 | 정상화 확인으로 끝 | 재발방지대책과 검증으로 끝 |
| 강조 | 사실·타임라인·복구 조치 | 근본 원인·기여 요인·액션아이템 |
| 대상 독자 | 운영·관련팀(상황 공유) | 고객·경영진·관련팀(약속·승인) |
핵심은 RCA 보고서가 장애보고서를 대체하지 않는다는 점입니다. RCA 보고서는 장애보고서의 타임라인을 토대(입력)로 삼아, 그 위에 분석과 약속을 얹습니다. 그래서 이 모듈의 선수 모듈이 장애보고서 작성입니다.
두 문서는 같은 장애, 다른 질문입니다. 장애보고서는 모든 장애에 빠르게 나오는 증거이고, RCA는 반복·중대 장애에 한해 며칠을 들여 근본 원인까지 내려갑니다. 그래서 RCA가 빠진 반복 장애는 같은 부류로 또 발생합니다.
RCA 보고서의 구성 — 8개 블록
문제 정의에서 검증 계획까지
좋은 RCA 보고서는 정해진 흐름을 따릅니다. 각 블록은 다음 블록의 근거가 되므로 순서가 곧 논리입니다.
| 블록 | 무엇을 적나 | 흔한 실수 |
|---|---|---|
| 1. 문제 정의 | 무엇이 잘못됐는지 한두 문장으로 명확히. 증상과 범위 | 원인을 미리 단정해 정의에 섞음 |
| 2. 영향 | 영향받은 서비스·고객 수·지속 시간·정량 손실(매출·SLA) | "영향 있었음"처럼 정성적으로만 |
| 3. 타임라인 | 탐지·에스컬레이션·조치·정상화를 시각과 함께 시간순으로 | 분석 결과를 타임라인에 섞음 |
| 4. 분석 과정 | 어떻게 원인에 도달했나(5 Whys·피시본) | 결론만 적고 도달 과정을 생략 |
| 5. 근본 원인 | 제거하면 이 부류의 장애가 안 나는 지점 | 표면 증상을 근본 원인으로 적음 |
| 6. 기여 요인 | 근본 원인이 장애로 번지게 한 다른 요인들 | 단일 원인으로 단정하고 생략 |
| 7. 재발방지대책 | 무엇을·누가·언제까지·어떻게 검증 | 담당·기한 없는 소망 목록 |
| 8. 검증 계획 | 대책이 효과 있었는지 확인하는 방법·시점 | 대책으로 끝내고 검증을 안 적음 |
이 중 57번이 RCA 보고서의 심장입니다. 14번은 "왜"를 향한 준비, 8번은 "정말 막혔나"의 확인입니다.
그림: 5 Whys는 한 줄기 인과를 깊게(수직) 파고, 피시본은 여러 범주의 기여 요인을 넓게(수평) 펼쳐 단일 원인 단정을 막는다.
RCA 보고서 — 빈 양식·작성 예시 다운로드
근본 원인 하나로 단정하지 않기 — 기여 요인이라는 안전장치
신입이 가장 흔히 빠지는 함정은 근본 원인을 하나로 단정하고 거기서 멈추는 것입니다. "원인: DB 커넥션 풀 고갈" 한 줄로 끝내면, 다음 질문이 막힙니다 — 풀이 왜 고갈됐나? 왜 고갈 전에 경보가 없었나? 왜 자동 확장이 없었나?
거의 모든 장애는 여러 기여 요인이 겹쳐 발생합니다. 그래서 RCA 보고서는 근본 원인 한 줄 옆에 항상 기여 요인 목록을 둡니다.
예를 들어 결제 장애의 분석 결과:
- 근본 원인: 특정 쿼리가 커넥션을 반환하지 않는 코드 경로(누수)
- 기여 요인 1: 커넥션 풀 사용률에 대한 임계 경보가 없었다(탐지 지연)
- 기여 요인 2: 풀 크기가 트래픽 증가에 비해 작게 고정돼 있었다(여유 부족)
- 기여 요인 3: 배포 전 부하 테스트에 해당 경로가 포함되지 않았다(검증 누락)
근본 원인만 고치면 그 누수는 막히지만, 경보·여유·테스트의 빈틈은 그대로라 다른 누수가 같은 장애를 다시 만듭니다. 기여 요인까지 대책으로 연결해야 '이 부류'의 재발이 막힙니다.
또 하나, 기여 요인을 사람의 실수로 적지 않습니다. "담당자가 경보 설정을 깜빡함"이 아니라 "경보 설정이 배포 체크리스트에 없어 누락될 수 있는 구조"로 적습니다. 사람은 바뀌어도 구조의 빈틈은 남기 때문입니다.
직접 해보기 — RCA 보고서 한 건 작성
아래 장애보고서(입력)를 토대로 RCA 보고서를 작성합니다. 먼저 5 Whys로 근본 원인까지 내려가고, 피시본으로 기여 요인을 펼친 뒤, 재발방지대책 표를 채우세요.
[장애보고서 발췌]
- 서비스: 결제(Payment)
- 발생: 2026-06-18 21:05, 정상화: 21:27 (22분)
- 증상: 결제 요청 90% 이상 실패(타임아웃)
- 복구: 결제 인스턴스 재시작으로 커넥션 풀 초기화
- 영향: 약 1,400건 결제 실패, 추정 매출 영향 + SLA 가용성 위반
5 Whys 예시 흐름을 직접 채워 봅니다.
[5 Whys]
Q1. 왜 결제가 실패했나? → 커넥션 풀이 고갈돼 신규 요청이 대기·타임아웃
Q2. 왜 풀이 고갈됐나? → 특정 조회 경로가 커넥션을 반환하지 않고 누수
Q3. 왜 누수가 운영까지 갔나? → 배포 전 부하 테스트에 그 경로가 빠져 있었다
Q4. 왜 고갈 전에 못 막았나? → 풀 사용률 임계 경보가 설정돼 있지 않았다
Q5. 왜 경보가 없었나? → 신규 서비스 배포 체크리스트에 경보 항목이 없다
→ (근본 원인: 누수 코드 + 검증/관측 체계의 구조적 누락)
그다음 RCA 보고서 본문을 아래 템플릿으로 작성합니다.
# RCA 보고서 — 결제 서비스 장애 (2026-06-18)
## 1. 문제 정의
21:05부터 22분간 결제 요청의 90% 이상이 타임아웃으로 실패함.
## 2. 영향
- 영향 서비스: 결제(Payment), 연계 주문 일부 지연
- 실패 건수: 약 1,400건 / 영향 고객: 결제 시도 전 고객
- 지속 시간: 22분 (21:05~21:27)
- 정량 손실: 추정 매출 영향 + 월 가용성 SLA 임계 위반
## 3. 타임라인
- 21:05 결제 실패율 급증(경보는 실패 후 수동 인지)
- 21:12 운영 인지 및 1차 조사 시작
- 21:20 커넥션 풀 고갈 확인, 재시작 결정
- 21:27 인스턴스 재시작 → 정상화 확인
## 4. 분석 과정
- 5 Whys: 실패 → 풀 고갈 → 커넥션 누수 경로 → 부하 테스트 누락 → 경보 부재
- 피시본(사람/프로세스/시스템/환경)으로 기여 요인 점검(아래 5,6 참조)
## 5. 근본 원인
특정 조회 경로에서 커넥션을 반환하지 않는 누수가 존재하며,
이를 운영 전에 걸러낼 검증·관측 체계가 구조적으로 누락됨.
## 6. 기여 요인
- 풀 사용률 임계 경보 미설정(탐지 지연)
- 풀 크기가 트래픽 대비 작게 고정(여유 부족)
- 배포 전 부하 테스트에 해당 경로 미포함(검증 누락)
## 7. 재발방지대책 (표는 아래 ObserveBlock 참조)
## 8. 검증 계획
- 대책 적용 후 2주간 풀 사용률·실패율 모니터링, 임계 경보 발화 테스트로 동작 확인
- 다음 정기 부하 테스트 리포트에 해당 경로 포함 여부 확인
구성: 문제정의 → 영향 → 타임라인 → 분석 → 근본원인 → 기여요인 → 재발방지대책 → 검증- 재발방지대책 표는 반드시 4개 축을 갖춘다 — 대책 / 유형 / 담당 / 기한 / 검증방법
- 대책 1: 커넥션 누수 경로 수정 및 반환 보장 / 유형: 시정(코드) / 담당: 결제개발 김OO / 기한: 6/25 / 검증: 누수 단위테스트 추가·통과
- 대책 2: 풀 사용률 임계 경보 추가(80% 경고) / 유형: 예방(관측) / 담당: 운영 박OO / 기한: 6/23 / 검증: 임계 초과 시 알림 발화 테스트
- 대책 3: 배포 체크리스트에 경보·부하테스트 항목 추가 / 유형: 예방(프로세스) / 담당: SM리드 이OO / 기한: 6/27 / 검증: 다음 배포에서 체크리스트 적용 확인
- 대책 4: 결제 부하 테스트에 조회 경로 포함 / 유형: 예방(검증) / 담당: QA 정OO / 기한: 6/30 / 검증: 부하 리포트에 해당 경로 결과 존재
- 핵심 점검: 근본 원인(누수)뿐 아니라 기여 요인(경보·여유·테스트)까지 각각 대책으로 연결됐는가 — 하나라도 비면 같은 부류가 재발한다
현장에서 자주 보는 함정
증상: RCA 보고서는 잘 썼는데, 마지막 재발방지대책이 "모니터링 강화", "코드 리뷰 철저", "재발방지에 만전을 기하겠음" 같은 추상적 다짐으로 채워져 있습니다. 보고는 통과됐지만 한 분기 뒤 비슷한 장애가 또 납니다.
원인: 대책이 추적 가능한 액션아이템이 아니라 선언이기 때문입니다. "강화한다"는 누가·언제까지·무엇을 했을 때 완료인지가 없어 아무도 추적하지 않습니다. 또 근본 원인만 고치고 기여 요인(탐지·여유·검증의 빈틈)은 대책 없이 넘어가, 다른 경로로 같은 장애가 들어옵니다.
해결 방향:
- 모든 대책을 검증 가능한 동사로 — "강화"가 아니라 "임계 경보를 80%에 추가하고 발화 테스트로 확인".
- 한 행마다 담당·기한·검증 방법을 채워 액션아이템으로 등록하고, 다음 회의·문제관리 보드에서 완료까지 추적.
- 근본 원인과 기여 요인을 각각 대책에 연결 — 빈 칸이 있으면 그 축으로 재발한다고 본다.
- 대책 유형을 시정(이미 난 것 고침) 과 예방(다시 안 나게 함) 으로 구분해, 예방이 비어 있지 않은지 점검.
RCA 보고서의 가치는 분석의 화려함이 아니라, 추적되어 끝까지 닫히는 대책에 있습니다. 닫히지 않는 액션아이템은 다음 RCA 보고서의 첫 줄로 돌아옵니다.
한국의 운영(SM)·SI 현장에서 RCA 보고서는 고객사·원청이 정식으로 요구하는 산출물입니다. 특히 (1)같은 장애가 반복되거나, (2)SLA를 위반했거나, (3)영향이 큰 메이저 장애였을 때, 고객사 IT 담당이나 정보화 부서는 "장애보고서 말고 근본원인분석 보고서를 제출하라"고 요청합니다. 이때 복구 경위만 적힌 장애보고서를 다시 내면 "복구는 알겠고 왜·어떻게 막을지를 달라"는 반려가 돌아옵니다.
이 자리에서 당신의 역할은 직접 코드를 고치는 것이 아니라, 협력사 엔지니어의 분석을 RCA 보고서의 논리로 끌어내고, 담당·기한이 붙은 재발방지대책으로 정리해 고객에게 약속하고 추적하는 것입니다. 협력사가 "원인은 DB였습니다" 한 줄로 끝내려 하면, 5 Whys로 더 내려가게 하고 기여 요인을 피시본으로 펼치게 만드는 것이 관리자의 일입니다.
또 RCA 보고서는 한 번 내고 끝이 아닙니다. 다음 운영 회의·문제관리(Problem) 보드에서 액션아이템의 완료 여부와 검증 결과를 추적하고, 닫히지 않은 대책을 다음 장애의 기여 요인으로 보지 않도록 관리합니다. 잘 쓰인 RCA 보고서 한 건은 고객 신뢰를 회복시키지만, 닫히지 않는 대책이 쌓인 RCA 보고서는 오히려 관리 부실의 증거가 됩니다.
관련 모듈로 더 깊이:
- 근본원인분석(RCA) 기법 — 5 Whys·피시본으로 진짜 원인을 규명하는 기법의 원리
- 문제 관리 — RCA의 재발방지 액션아이템을 끝까지 추적해 닫는 프로세스
- 장애보고서 작성 — RCA가 이어받는 장애보고서의 "조사중" 항목
다음 모듈에서는 의도된 변경이 안전하게 반영되도록 미리 설계하는 문서 — 변경계획서와 롤백계획서의 작성법을 다룹니다.