같은 결제 장애, 두 번째 보고.
지난주 결제 서비스가 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 보고서의 첫 줄로 돌아옵니다.
심화 — 재발방지대책은 자산이 아니라 부채다
심화: RCA 아카이브 — 다음 장애 때 가장 먼저 열리는 문서
RCA 보고서는 제출로 끝나지 않습니다. 고객사·원청의 문서함에 들어간 순간부터, 그 보고서는 다음 장애 때 가장 먼저 다시 열리는 문서가 됩니다. 이 사실이 대책 작성의 경제학을 바꿉니다.
- 대책 한 줄은 약속 한 건입니다: 고객 앞 RCA 보고 자리에는 묘한 압력이 있습니다 — 대책이 많을수록 성의 있어 보인다는 압력입니다. 그래서 정말 할 것 3건에 '하면 좋은 것' 5건을 얹어 8건짜리 표를 만드는 유혹이 생깁니다. 그런데 제출된 대책은 전부 이행 추적의 대상이고, 유사 장애가 재발하면 고객은 새 장애의 원인보다 지난 보고서의 미이행 대책부터 셉니다. 이행률 40%의 8건보다 이행률 100%의 3건이 조직을 지킵니다.
- 원인 문장에는 협상이 붙습니다: 원청·협력사·발주사가 함께 보는 RCA에서는 근본 원인 문장을 두고 표현 조율이 벌어지곤 합니다 — 원인이 특정사 귀책으로 읽히면 페널티·재계약에 닿기 때문입니다. 위험한 것은 조율 자체가 아니라, 원인이 정치적으로 타협되면 대책도 함께 타협된다는 점입니다. 원인을 "복합적 요인"으로 뭉개면 대책도 "협업 강화"로 뭉개지고, 그 장애는 다시 납니다. 귀책 정리는 계약의 언어로 별도 테이블에서 하되, 원인과 대책은 기술의 언어로 정확하게 남기는 분리가 필요합니다.
- 이행률은 스스로 보고하는 쪽이 유리합니다: 성숙한 운영 조직은 분기마다 미결 대책 목록과 이행률을 먼저 보고합니다. 고객이 캐물어서 드러나는 미이행과, 스스로 드러내고 일정을 재합의한 미이행은 같은 사실이라도 신뢰의 부호가 반대입니다. 문제 관리 보드에 대책을 등록하고 완료까지 모는 것은 그 자기 보고의 원천 데이터를 만드는 일입니다.
상황: 2월 결제 장애 RCA 보고회에서 고객 반응이 좋지 않자, 운영 PM은 대책 표를 보강했습니다 — 실제 계획된 3건에 "전 구간 부하테스트 자동화", "아키텍처 전면 재점검" 같은 대형 과제 5건을 더해 8건으로 제출했고, 고객은 "이 정도면 됐다"며 수용했습니다. 5월, 같은 커넥션 계열의 장애가 다시 났습니다. 긴급 보고회에서 고객 IT 팀장은 새 장애보고서가 아니라 2월 RCA를 화면에 띄웠습니다. "대책 3번 부하테스트 자동화, 하셨습니까? 5번 아키텍처 재점검 결과 보고서는 어디 있습니까?" 8건 중 이행 완료는 3건. 회의는 장애 원인 논의가 아니라 미이행 추궁으로 흘렀고, 회의록에는 "수행사 재발방지 이행 관리 부실"이 명기되어 연말 SM 재계약 평가 자료로 넘어갔습니다.
원인: 대책이 두 종류로 오염됐습니다 — 이행 계획이 있는 약속 3건과, 그 자리의 분위기를 넘기기 위한 장식 5건. 장식 대책에도 담당·기한이 형식적으로 붙어 있었지만 예산도 인력 계획도 없었고, 보고서 제출과 함께 잊혔습니다. 문제관리 보드에 등록되지 않았으니 추적도 없었습니다. 그런데 고객의 문서함에서 8건은 전부 같은 무게의 약속이었습니다. 조직은 3건을 지켰다고 기억했고, 고객은 5건이 깨졌다고 기억한 것입니다.
진단: 재발 장애의 수습과 별개로, 조직의 RCA 아카이브 전체를 감사합니다 — 최근 2년간 제출한 RCA 보고서의 대책을 전부 모아 이행/미이행/추적불명으로 분류합니다. 이 사례에서는 누적 대책 31건 중 이행이 증빙되는 것이 14건, 문제관리 보드에 등록조차 안 된 것이 11건으로 드러났습니다. 재발 장애 한 건의 문제가 아니라, 대책이 보고서에서 보드로 넘어가는 연결 자체가 끊어져 있었던 것입니다.
해결: 감춰서 될 국면이 아니므로, 누적 대책 감사 결과를 고객에게 먼저 공개하고 재합의를 제안합니다 — 이행 완료 14건의 증빙, 미이행 중 유효한 대책의 일정 재약속, 그리고 현실성 없는 장식 대책의 공식 철회(사유 명기)까지. 내부적으로는 두 개의 규칙을 세웁니다. (1) RCA 대책은 제출 전에 문제관리 보드 등록을 마쳐야 제출할 수 있다 — 보드에 못 올릴 대책은 보고서에도 못 올립니다. (2) 분기마다 대책 이행률을 고객 정기 보고에 선제 포함합니다. 다음 분기 보고에서 고객 팀장이 남긴 말이 이 규칙의 효과를 요약합니다 — "숫자가 나빠도, 먼저 가져오는 쪽은 믿게 됩니다."
한국의 운영(SM)·SI 현장에서 RCA 보고서는 고객사·원청이 정식으로 요구하는 산출물입니다. 특히 (1)같은 장애가 반복되거나, (2)SLA를 위반했거나, (3)영향이 큰 메이저 장애였을 때, 고객사 IT 담당이나 정보화 부서는 "장애보고서 말고 근본원인분석 보고서를 제출하라"고 요청합니다. 이때 복구 경위만 적힌 장애보고서를 다시 내면 "복구는 알겠고 왜·어떻게 막을지를 달라"는 반려가 돌아옵니다.
이 자리에서 당신의 역할은 직접 코드를 고치는 것이 아니라, 협력사 엔지니어의 분석을 RCA 보고서의 논리로 끌어내고, 담당·기한이 붙은 재발방지대책으로 정리해 고객에게 약속하고 추적하는 것입니다. 협력사가 "원인은 DB였습니다" 한 줄로 끝내려 하면, 5 Whys로 더 내려가게 하고 기여 요인을 피시본으로 펼치게 만드는 것이 관리자의 일입니다.
또 RCA 보고서는 한 번 내고 끝이 아닙니다. 다음 운영 회의·문제관리(Problem) 보드에서 액션아이템의 완료 여부와 검증 결과를 추적하고, 닫히지 않은 대책을 다음 장애의 기여 요인으로 보지 않도록 관리합니다. 잘 쓰인 RCA 보고서 한 건은 고객 신뢰를 회복시키지만, 닫히지 않는 대책이 쌓인 RCA 보고서는 오히려 관리 부실의 증거가 됩니다.
실전 랩으로 손에 익히기: RCA 보고서 작성 실습 — 사실·근본원인·재발방지를 증명하는 RCA 보고서를 직접 작성합니다.
관련 모듈로 더 깊이:
- 근본원인분석(RCA) 기법 — 5 Whys·피시본으로 진짜 원인을 규명하는 기법의 원리
- 문제 관리 — RCA의 재발방지 액션아이템을 끝까지 추적해 닫는 프로세스
- 장애보고서 작성 — RCA가 이어받는 장애보고서의 "조사중" 항목
다음 모듈에서는 의도된 변경이 안전하게 반영되도록 미리 설계하는 문서 — 변경계획서와 롤백계획서의 작성법을 다룹니다.