같은 결제 지연이 한 달에 세 번째.
매번 운영팀은 결제 서버를 재시작해 복구합니다. 빠릅니다 — 15분이면 정상. 보고서에는 "재시작으로 조치 완료"가 세 번 찍혔습니다. 그런데 다음 달에도, 그 다음 달에도 같은 지연이 납니다.
팀장이 묻습니다. "그래서, 왜 자꾸 느려지는데?" 아무도 답을 못 합니다. 매번 끄기만 했지, 누구도 "왜 났는가"를 끝까지 따라가 보지 않았습니다. 재시작은 증상을 지웠을 뿐, 원인은 그대로 살아 있었던 겁니다.
근본원인분석(RCA)은 바로 이 질문 — "왜?" — 을 추측이 아니라 절차와 데이터로 답하는 일입니다. "아마 트래픽 때문일 거야" 같은 직감을 "커넥션 풀이 200으로 고정돼 있고, 피크 시간 동시 접속이 그걸 넘어선다"는 검증된 사실로 바꾸는 도구들이 있습니다. 이 모듈은 그 도구함을 엽니다.
- 1RCA의 목적이 "복구"가 아니라 "증상 너머의 진짜 원인을 찾아 재발을 막는 것"임을 설명할 수 있다
- 25 Whys로 연쇄 질문을 따라가 표면 증상에서 근본 원인으로 좁혀가고, 그 함정(한 줄기·성급한 단정)을 피할 수 있다
- 3피시본(이시카와) 다이어그램의 6M 카테고리로 원인 후보를 빠짐없이 펼쳐 볼 수 있다
- 4결함수분석(FTA)과 파레토의 개념과 쓰임을 구분하고, 상황에 맞는 기법을 고를 수 있다
- 5실제 인시던트를 5 Whys 분석표와 피시본 카테고리 표로 정리하는 산출물을 만들 수 있다
RCA는 무엇을 하는 일인가
증상이 아니라 원인을 끈다
인시던트 대응과 RCA를 섞으면 둘 다 못 합니다. 시간 축이 다르기 때문입니다.
- 인시던트 대응: 지금 멈춘 서비스를 빨리 정상화(불 끄기). 목표는 복구 시간 단축.
- RCA(문제관리의 핵심 활동): 복구 후, "왜 났는가"를 끝까지 따라가 같은 불이 다시 나지 않게. 목표는 재발 방지.
재시작·롤백 같은 임시 조치는 증상을 지웁니다. 하지만 원인이 살아 있으면 증상은 다시 돌아옵니다. RCA는 그 살아 있는 원인을 찾아 제거(또는 영구 통제)하는 활동입니다.
| 구분 | 인시던트 대응 | RCA(근본원인분석) |
|---|---|---|
| 언제 | 장애가 난 그 순간 | 복구가 끝난 뒤 |
| 질문 | "어떻게 빨리 살리나" | "왜 죽었나, 어떻게 다시 안 죽게 하나" |
| 산출물 | 복구된 서비스 | 검증된 근본 원인 + 재발방지 조치 |
| 성공 기준 | 짧은 복구 시간 | 같은 인시던트가 다시 안 남 |
RCA에서 가장 중요한 태도는 **비난하지 않기(blameless)**입니다. "누가 잘못했나"가 아니라 "왜 그 잘못이 막히지 않았나"를 묻습니다. 사람을 탓하면 사람들은 사실을 숨기고, 사실이 숨으면 원인을 못 찾습니다. RCA의 적은 사람이 아니라 숨은 원인입니다.
표면 증상 · 직접 원인 · 근본 원인
원인에는 층이 있습니다. 이 층을 구분 못 하면 중간에서 멈춥니다.
| 층 | 뜻 | 예("결제 지연") |
|---|---|---|
| 표면 증상(symptom) | 사용자·모니터링이 보는 현상 | "결제가 10초 넘게 걸린다" |
| 직접 원인(direct cause) | 증상을 바로 일으킨 것 | "DB 커넥션이 고갈됐다" |
| 근본 원인(root cause) | 그 직접 원인을 가능하게 한 구조적 원인 | "커넥션 풀이 200 고정 + 트래픽 증가를 감지·경보하는 모니터링이 없었다" |
재시작은 표면 증상을 지웁니다. "커넥션을 늘려라"는 직접 원인을 건드립니다. 하지만 "왜 한계에 닿을 때까지 아무도 몰랐나"(모니터링·용량계획 부재)까지 가야 근본 원인이고, 거기까지 가야 다음 트래픽 증가 때 또 안 터집니다. RCA는 "더 이상 '왜'가 의미 있게 나오지 않고, 그것을 고치면 재발이 막히는 지점"까지 내려가는 일입니다.
그림: 원인의 세 층(표면 증상→직접 원인→근본 원인)과 5 Whys 줄기 — "왜 막지 못했나"까지 내려가야 근본 원인이다.
5 Whys — 연쇄 질문으로 줄기를 판다
다섯 번이 아니라, 충분히 깊게
5 Whys는 가장 단순한 RCA 기법입니다. 증상에서 시작해 "왜?"를 반복하며 한 단계씩 더 깊은 원인으로 내려갑니다. '5'는 정확한 횟수가 아니라 **"표면에서 멈추지 말고 충분히 깊게 파라"**는 경험칙입니다. 3번에 닿을 수도, 7번이 필요할 수도 있습니다.
핵심 규칙:
- 각 "왜"의 답은 **사실(검증 가능한 것)**이어야 합니다. "아마 ~일 것"은 답이 아니라 다음 조사 항목입니다.
- "사람이 실수했다"가 나오면 거기서 멈추지 말고 **"왜 그 실수가 막히지 않았나"**를 한 번 더 묻습니다(시스템·절차로 내려가기).
- 고친 뒤 위로 거슬러 검증합니다 — "이 근본 원인을 없애면 위의 모든 '왜'가 끊기는가?"
함정 — 한 줄기만 판다: 5 Whys는 한 갈래를 깊게 파는 데는 좋지만, 원인이 여러 갈래(설정 + 모니터링 부재 + 절차 미흡)일 때 다른 갈래를 놓치기 쉽습니다. 그래서 "이게 유일한 원인인가?"를 의심하고, 갈래가 의심되면 다음에 나올 피시본으로 펼쳐 봅니다.
산출물 예시 — 위 시나리오(결제 지연)를 5 Whys로 정리하면:
| 단계 | 질문(왜?) | 답(사실) |
|---|---|---|
| 증상 | — | 피크 시간 결제 응답이 10초를 넘는다 |
| 1차 왜 | 왜 응답이 느린가? | 애플리케이션이 DB 커넥션을 얻지 못해 대기한다 |
| 2차 왜 | 왜 커넥션을 못 얻나? | 커넥션 풀이 고갈됐다(사용 200 / 최대 200) |
| 3차 왜 | 왜 풀이 고갈됐나? | 동시 접속이 늘었는데 풀 최대치가 200으로 고정돼 있다 |
| 4차 왜 | 왜 한계에 닿을 때까지 몰랐나? | 커넥션 사용률에 대한 경보가 없어 임계 도달을 감지하지 못했다 |
| 5차 왜 | 왜 경보가 없었나? | 용량계획·모니터링 항목 정의 시 DB 커넥션이 지표에서 빠졌다 |
| 근본 원인 | — | 용량계획에 커넥션 풀 지표가 누락돼, 트래픽 증가를 감지·대응할 수단이 없었다 |
위 표의 마지막 행을 고치면(커넥션 지표 경보 추가 + 풀 산정 기준 마련) 위의 모든 "왜"가 끊깁니다. 단순히 "풀을 400으로 늘려라"(3차 왜)에서 멈췄다면, 트래픽이 또 늘 때 같은 인시던트가 반복됐을 것입니다.
피시본(이시카와) — 원인 후보를 갈래로 펼친다
6M으로 빠짐없이 펼쳐 보기
5 Whys가 한 줄기를 깊게 판다면, 피시본 다이어그램(이시카와 다이어그램, 일명 생선뼈 그림)은 여러 갈래를 넓게 펼칩니다. 원래는 생선뼈 모양 도식이지만, 도식 없이도 카테고리별 원인 후보 목록으로 똑같이 쓸 수 있습니다(이 모듈은 표·리스트로 다룹니다).
핵심은 원인을 6M 카테고리로 나눠, 한쪽으로 쏠리지 않고 빠짐없이 후보를 떠올리는 것입니다(제조업에서 온 분류라 IT엔 일부를 변형해 씁니다).
| 카테고리(6M) | 뜻 | IT 인시던트에서의 예 |
|---|---|---|
| 사람(Man / People) | 사람의 역량·소통·인지 | 담당자 부재, 인수인계 누락, 알람 피로로 경보 무시 |
| 방법(Method / Process) | 절차·정책·기준 | 배포 절차 미흡, 롤백 계획 부재, 점검 체크리스트 없음 |
| 장비(Machine) | 인프라·하드웨어·도구 | 서버 노후, 모니터링 도구 미설치, 자동화 파이프라인 결함 |
| 자재(Material) | 입력 데이터·코드·설정 | 잘못된 설정값, 결함 있는 배포 아티팩트, 깨진 입력 데이터 |
| 측정(Measurement) | 지표·모니터링·경보 | 핵심 지표 미수집, 임계 경보 부재, 잘못된 대시보드 |
| 환경(Environment) | 외부·인프라 환경 | 트래픽 급증, 네트워크 단절, 의존 외부 API 장애, 클라우드 리전 이슈 |
쓰는 법은 단순합니다 — 문제 하나를 가운데 두고, 6개 카테고리마다 "여기서 비롯됐을 만한 원인이 있나?"를 팀이 함께 묻습니다. 이렇게 하면 한 사람이 "트래픽 때문"이라고 단정해도, "측정(경보가 없었다)"·"방법(용량계획 절차가 없었다)" 갈래가 드러나 단일 원인 단정을 막습니다.
표로 정리하기 전에 팀이 함께 채우는 워크시트는 보통 이렇게 생긴 생선뼈 도식입니다. 가운데 척추 끝(머리)에 문제 현상을 두고, 6M 카테고리마다 뻗은 뼈대에 원인 후보를 적어 넣습니다. 6갈래로 넓게 펼친 다음, 그중 유력한 후보 하나에 앞의 5 Whys를 이어 붙여 깊이 파고들면 — 넓게 펼치고(피시본) 좁게 파는(5 Whys) 두 기법이 자연스럽게 맞물립니다.
산출물 예시 — 같은 결제 지연을 피시본 6M으로 펼치면:
| 카테고리 | 이번 인시던트의 원인 후보 | 검증 결과 |
|---|---|---|
| 사람(People) | 야간 당직자가 경보를 놓쳤나? | 해당 없음(애초에 경보가 없었음) |
| 방법(Process) | 용량계획·커넥션 산정 절차가 있었나? | 기여 — 절차에 DB 커넥션 항목 누락 |
| 장비(Machine) | 모니터링 도구가 커넥션 지표를 지원하나? | 도구는 지원하나 미설정 |
| 자재(Material) | 커넥션 풀 설정값(200)이 적절했나? | 기여 — 트래픽 대비 과소 산정 |
| 측정(Measurement) | 커넥션 사용률 경보가 있었나? | 핵심 기여 — 경보 자체가 없음 |
| 환경(Environment) | 트래픽이 평소보다 늘었나? | 방아쇠 — 프로모션으로 피크 1.8배 증가 |
이렇게 펼치면 보입니다 — 방아쇠(환경: 트래픽 증가)는 통제하기 어렵지만, 기여 원인(자재·방법·측정)은 우리가 고칠 수 있습니다. 5 Whys가 찾은 "용량계획 누락"이 여기서 '방법·측정' 갈래로 재확인되며, 동시에 '자재(설정값 과소)'라는 두 번째 갈래도 드러납니다. 한 줄기만 봤다면 놓쳤을 부분입니다.
결함수분석(FTA)과 파레토 — 더 큰 그림
FTA: 위에서 아래로, 논리로 분해한다
**결함수분석(FTA, Fault Tree Analysis)**은 "이 최상위 장애가 일어나려면 어떤 하위 조건들이 어떻게 결합돼야 하는가"를 위에서 아래로 분해하는 기법입니다. 5 Whys/피시본이 "원인 후보를 떠올리는" 발산적 도구라면, FTA는 논리 관계(그리고·또는)로 구조화하는 분석적 도구입니다.
핵심은 하위 원인들이 **AND(모두 충족돼야 장애)**로 묶이는지, **OR(하나만 충족돼도 장애)**로 묶이는지를 따지는 것입니다.
- 예: "결제 전면 중단"이 일어나려면 → ("주 DB 다운" OR "결제 API 다운")인데, 둘 다 단독으로 전면 중단을 일으킨다면 OR 관계 — 단일 장애점(SPOF)이 둘이라는 뜻.
- 반대로 "이중화된 두 노드가 모두 죽어야 중단"이면 AND 관계 — 한 노드 장애로는 안 죽으니 더 안전.
FTA는 복잡한 시스템에서 어떤 조합이 치명적인지, 어디가 단일 장애점인지를 드러낼 때 강합니다. 안전이 중요한 시스템(금융 결제, 의료, 항공)이나, 여러 컴포넌트가 얽힌 대형 장애의 사후 분석에서 특히 쓸모가 큽니다. 다만 도식과 논리 분해에 손이 많이 가므로, 간단한 인시던트에는 과합니다.
파레토: 데이터로 '어디부터'를 정한다
파레토(Pareto) 원칙은 "소수의 원인이 다수의 결과를 만든다"는 경험칙입니다 — 흔히 상위 약 20%의 원인이 약 80%의 인시던트를 일으킨다고 말합니다(정확히 8대2일 필요는 없고, '쏠려 있다'는 뜻).
RCA에서 파레토는 개별 인시던트가 아니라 인시던트 '무더기'를 볼 때 씁니다. 한 달치 인시던트를 원인 유형별로 집계해 빈도(또는 영향 시간)가 큰 순으로 정렬하면, "무엇부터 고치면 가장 많은 재발을 막는가"가 데이터로 보입니다.
예 — 분기 인시던트 80건을 원인 유형으로 집계:
| 원인 유형 | 건수 | 비중 | 누적 비중 |
|---|---|---|---|
| 배포 후 설정 오류 | 34 | 42.5% | 42.5% |
| 용량/리소스 부족 | 22 | 27.5% | 70.0% |
| 외부 API 장애 | 12 | 15.0% | 85.0% |
| 네트워크 일시 단절 | 7 | 8.75% | 93.75% |
| 기타 | 5 | 6.25% | 100% |
상위 2개 유형(설정 오류 + 용량 부족)이 전체의 70%입니다. 자원이 한정돼 있다면, 흩어진 5개를 다 손대기보다 이 상위 2개를 먼저 제거하는 것이 같은 노력으로 가장 많은 인시던트를 줄이는 길입니다. 파레토는 "어디부터"를 직감이 아니라 데이터로 정해 줍니다.
직접 해보기 — 한 인시던트를 두 기법으로 분석
아래 인시던트를 5 Whys로 분석해 표를 채워 보세요. 각 답은 검증 가능한 사실이어야 하고, "사람이 실수했다"가 나오면 한 단계 더(왜 막히지 않았나) 내려갑니다.
인시던트: 자정 배치 작업이 실패해, 다음 날 아침 매출 리포트가 비어 있었다.
복구: 배치를 수동 재실행해 리포트를 다시 생성(오전 10시 완료).
이제 "왜 실패했고, 왜 아침까지 아무도 몰랐나"를 끝까지 따라가 보세요.
표 형식(직접 채우기):
증상 : 아침 매출 리포트가 비어 있었다
1차 왜 : 왜 비었나? → (답)
2차 왜 : 왜 ...? → (답)
3차 왜 : 왜 ...? → (답)
4차 왜 : 왜 아침까지 몰랐나? → (답)
근본 원인: (한 문장으로)
증상에서 시작해 '왜?'를 검증 가능한 사실로 답하며 내려가기이번엔 같은 배치 실패를 6M 카테고리로 펼쳐, 5 Whys로는 안 보였던 갈래가 있는지 확인하세요. 각 카테고리에 "여기서 비롯됐을 원인이 있나?"를 묻고, 있으면 후보를 적습니다.
사람(People) : (예: 배치 담당 부재? 실패 알림 수신자 미지정?)
방법(Process) : (예: 배치 실패 시 재시도/에스컬레이션 절차 없음?)
장비(Machine) : (예: 배치 서버 디스크 풀? 스케줄러 결함?)
자재(Material) : (예: 입력 데이터 누락/형식 오류? 잘못된 설정?)
측정(Measurement) : (예: 배치 성공/실패 경보 없음?)
환경(Environment) : (예: 의존 DB가 그 시간에 점검 중이었나?)
6개 카테고리마다 원인 후보가 있는지 묻기- 5 Whys 표: 모든 "왜"의 답이 추측이 아니라 검증 가능한 사실로 적혔는가 — "아마"가 남아 있으면 그건 답이 아니라 다음 조사 항목이다
- 5 Whys 표: 마지막 근본 원인을 고치면 위의 모든 "왜"가 끊기는가(거슬러 검증) — 안 끊기면 아직 덜 내려간 것
- 5 Whys 표: "사람이 실수했다"에서 멈추지 않고 "왜 그 실수가 막히지 않았나"(절차·경보)까지 갔는가
- 피시본 6M: 6개 카테고리 중 비어 있는 칸이 있다면, 정말 원인이 없는지 vs 안 떠올린 건지 한 번 더 확인했는가
- 두 기법 비교: 피시본에서 5 Whys로는 안 보였던 갈래(예: 측정-경보 부재, 방법-에스컬레이션 절차 부재)가 드러났는가 — 드러났다면 단일 원인 단정을 피한 것
- 핵심 감각: 5 Whys는 깊이(한 줄기), 피시본은 너비(여러 갈래) — 둘을 함께 쓰면 깊고 빠짐없는 분석이 된다
현장에서 자주 보는 함정
증상: RCA 보고서의 근본 원인 칸에 "담당자 부주의", "예상치 못한 트래픽 증가", "일시적 네트워크 이슈"가 적혀 있습니다. 재발방지 조치는 "담당자 교육 강화", "모니터링 강화", "주의 요망" 같은 측정 불가능한 문장입니다. 그리고 같은 인시던트가 또 납니다.
원인: 두 가지가 겹쳤습니다.
- 표면에서 멈춤: "트래픽 증가"는 대개 방아쇠이지 근본 원인이 아닙니다. 트래픽은 늘 변합니다 — 진짜 원인은 "트래픽 증가를 감지·흡수할 수단(경보·오토스케일·용량계획)이 없었다"는 쪽입니다. "사람 부주의"도 마찬가지로, "왜 그 실수가 시스템에서 막히지 않았나"까지 안 간 것입니다.
- 성급한 단일 원인 단정: 처음 떠오른 한 갈래를 원인으로 확정하고 다른 갈래(피시본의 나머지 5M)를 확인하지 않았습니다.
해결 방향:
- 근본 원인 후보가 "사람"·"외부 환경"으로 나오면 자동으로 한 단계 더 묻는다 — "왜 그게 막히지 않았나?"(시스템·절차로 내려가기).
- 한 갈래를 찾았어도 피시본 6M으로 나머지 갈래를 한 번 훑어 단일 원인 단정을 점검한다.
- 재발방지 조치는 검증 가능한 형태로 적는다 — "모니터링 강화"(X) → "커넥션 사용률 80% 경보 추가, 다음 점검 때 동작 확인"(O).
- 조치에 담당자·기한·검증 방법을 붙인다. 검증 방법이 없는 조치는 "했다고 치는" 조치가 되기 쉽다.
RCA의 품질은 "원인을 얼마나 그럴듯하게 적었나"가 아니라 **"그 조치를 하면 정말 재발이 막히는가, 그리고 그걸 어떻게 확인할 것인가"**로 판가름 납니다.
국내 SI/SM 현장에서 RCA는 보통 문제관리 보고서나 **장애 사후보고서(포스트모템)**의 핵심 섹션으로 들어갑니다. 발주사·원청은 장애가 났을 때 "복구했습니다" 한 줄이 아니라, **"근본 원인이 무엇이고, 재발을 막기 위해 무엇을, 언제까지, 누가 한다"**를 문서로 요구합니다. SLA에 "중대 장애 발생 시 N일 내 RCA 보고서 제출"이 명시된 계약도 흔합니다.
이런 자리에서 관리자(PM/PMO·SM 담당)는 직접 원인을 파기보다, 협력사가 제출한 RCA가 표면에서 멈추지 않았는지를 검증하는 역할을 합니다 — "근본 원인이 '트래픽 증가'로만 적혀 있는데, 그걸 감지할 경보는 왜 없었습니까?", "재발방지 조치 '모니터링 강화'는 구체적으로 무엇을 어떻게 합니까?"를 물을 수 있어야 합니다. 기법(5 Whys·피시본·파레토)을 알면, 협력사 엔지니어와 대등하게 대화하고 부실한 분석에 속지 않습니다.
또한 파레토는 운영 보고·개선 과제 도출에 직접 쓰입니다. 월간/분기 운영 보고에서 인시던트를 원인 유형별로 집계해 "상위 2개 원인이 70%이니 이번 분기 개선 과제는 이 둘"이라고 데이터로 우선순위를 제시하는 것은, 감으로 일하는 운영과 관리하는 운영을 가르는 지점입니다.
관련 모듈로 더 깊이:
- 포스트모템 — RCA 결과를 비난 없는 사후분석 보고서로 묶어 학습 자산으로
- 문제 관리 — RCA가 핵심 절차로 들어가는 문제관리의 전체 흐름
- RCA 보고서 작성 — RCA 분석을 발주사가 요구하는 보고서 형식으로 쓰는 법
다음 모듈에서는 이 RCA 결과를 하나의 문서로 묶어 조직의 자산으로 만드는 절차 — 비난 없는 포스트모템(사후분석) 보고서를 어떻게 쓰고, 어떻게 회고 회의로 이어가는지를 다룹니다.