RCA와 FMEA로 시스템 장애 원인을 분석하고 위험을 예방하는 법
RCA와 FMEA의 분석 방식, 5 Whys와 RPN 활용법, 장애 재발 방지와 운영 리스크 관리 체계를 정리합니다.
2026-08-14 · 최초 발행 2026-01-19
장애의 증상보다 재발 조건을 찾는 RCA
Root Cause Analysis(RCA)는 장애에서 드러난 현상만 처리하는 대신, 그 현상을 낳은 근본 원인을 체계적으로 추적하는 방법이다. 질문은 “무엇이 잘못됐는가”에서 멈추지 않고 “왜 이런 상태가 만들어졌는가”까지 이어진다. 목적은 재발 방지와 프로세스 개선이다.
원인을 연속으로 추적하는 5 Whys
장애를 한 단계씩 거슬러 올라가며 “왜?”를 묻는 방식이다. 표면 원인에 머물지 않고 시스템 또는 프로세스 수준의 결함까지 도달해야 한다.
Fishbone Diagram(Ishikawa Diagram)은 원인 후보를 넓게 모아 볼 때 적합하다. 사람(People), 프로세스(Process), 기술(Technology), 환경(Environment)처럼 범주를 나눈 뒤 브레인스토밍으로 문제에 영향을 준 가능성을 정리한다.
RCA는 보통 장애 증상과 영향 범위를 먼저 명확히 하고, 로그·메트릭·타임라인 데이터를 수집하는 데서 시작한다. 이후 5 Whys나 Fishbone 기법으로 원인 가설을 세우고, 실험 또는 추가 데이터로 근본 원인을 검증한다. 검증된 원인을 제거하는 액션 아이템을 만들고, RCA 리포트로 남겨 공유한다.
발생 전 위험을 다루는 FMEA
Failure Mode and Effects Analysis(FMEA)는 시스템, 설계, 프로세스에서 일어날 수 있는 고장 모드를 미리 식별하고 위험도를 평가한다. 장애 후 원인을 분석하는 RCA와 달리, 아직 일어나지 않은 문제를 예방하는 관점의 기법이다. 하드웨어 설계, 소프트웨어 아키텍처, 운영 프로세스에 적용할 수 있다.
고장 모드(Failure Mode)는 디스크 장애나 네트워크 단절처럼 시스템이 실패하는 방식이다. Effect는 그 실패가 시스템에 주는 영향이다. 위험도 평가는 다음 항목으로 구성한다.
- Severity(심각도, S): 영향의 심각성 정도를 1-10 스케일로 평가한다.
- Occurrence(발생도, O): 고장 발생 빈도를 1-10 스케일로 평가한다.
- Detection(검출도, D): 고장을 발견하기 어려운 정도를 1-10 스케일로 평가하며, 값이 높을수록 검출이 어렵다.
RPN으로 대응 순서 정하기
Risk Priority Number(RPN)은 Severity × Occurrence × Detection으로 계산한다. RPN이 클수록 먼저 대응할 필요가 있으며, 예를 들어 RPN > 100 같은 임계값을 정해 리스크를 관리할 수 있다.
| 구성요소 | 고장 모드 | 영향 | S | 원인 | O | 현재 제어 | D | RPN | 개선 조치 |
|---|---|---|---|---|---|---|---|---|---|
| 데이터베이스 | 복제 지연 | 데이터 불일치 | 7 | 네트워크 지연 | 5 | 모니터링 알림 | 4 | 140 | 복제 지연 임계값 자동 감지 |
| 로드밸런서 | 단일 장애점 | 서비스 중단 | 9 | 하드웨어 장애 | 3 | Active-Standby | 5 | 135 | Active-Active 구성 전환 |
| 캐시 서버 | 메모리 고갈 | 성능 저하 | 6 | 캐시 키 무한 증가 | 4 | TTL 설정 | 3 | 72 | LRU 정책 강화 |
사후 분석을 예방 체계로 되돌리는 흐름
RCA에서 확인한 근본 원인은 FMEA의 고장 모드 데이터베이스를 갱신하는 입력이 된다. 반대로 FMEA에서 위험도가 높다고 판단한 항목은 모니터링 대상으로 삼아 조기 경보 체계를 만들 수 있다.
신규 시스템을 도입할 때는 FMEA로 위험 요소를 미리 평가한다. 장애가 발생하면 RCA로 원인과 재발 방지책을 확인하고, 정기 리뷰에서는 FMEA 테이블과 RPN을 다시 평가한다. 아키텍처가 변경될 때도 FMEA를 다시 수행해 새로 생긴 리스크를 점검한다.
장애와 고장 모드를 기록하는 방식
클라우드 서비스에서 특정 리전의 API 응답 시간이 급증한 사례를 생각해 볼 수 있다. 데이터베이스 쿼리 지연에서 시작해 인덱스 미사용, 쿼리 플랜 변경, 오래된 테이블 통계 정보, 자동 통계 업데이트 작업 실패를 차례로 추적했다. 근본 원인은 통계 업데이트 스케줄러의 권한 부족이었고, 권한 수정과 모니터링 추가가 개선 조치가 됐다.
스토리지 시스템에서는 SSD 동시 다발 장애를 고장 모드로 등록할 수 있다. 데이터 손실 가능성 때문에 Severity는 9, 동일 배치 불량 가능성에 대한 Occurrence는 2, SMART 데이터로 예측하기 어렵다는 점에서 Detection은 6으로 평가한다. RPN은 108이며, 다양한 벤더와 배치의 SSD를 혼용하고 SMART 데이터를 주기적으로 분석하는 방식으로 개선할 수 있다.
분석 결과를 운영 도구와 연결하기
RCA에는 Splunk, ELK Stack 같은 로그 집계 및 타임라인 분석 도구, Grafana와 Prometheus 같은 메트릭 시각화 및 이상 탐지 도구를 활용할 수 있다. PagerDuty Postmortem은 장애 리포트 템플릿을 제공하며, Jira와 Confluence는 RCA 문서와 액션 아이템을 추적하는 데 사용된다.
FMEA는 ReliaSoft, IQS FMEA 같은 전용 소프트웨어로 관리할 수 있다. Excel이나 Google Sheets 기반 템플릿으로 RPN 계산을 자동화할 수도 있으며, 조직 차원의 고장 모드 데이터베이스는 리스크 레지스트리로 관리한다.
자동화 대상에는 로그·메트릭 수집과 상관관계 분석, 알려진 패턴에 따른 근본 원인 후보 제시(ML/AI 활용), FMEA RPN 계산과 임계값 알림, 개선 조치 추적 대시보드가 있다.
비난 없는 분석이 지식으로 남으려면
RCA의 초점은 개인을 비난하는 데 있지 않고 시스템과 프로세스에서 학습할 지점을 찾는 데 있다. Blameless Postmortem 문화는 심리적 안전성을 바탕으로 정직한 분석을 가능하게 한다.
주요 장애에 RCA 수행을 요구하고, 분기별로 FMEA 리뷰 미팅을 운영할 수 있다. 경영진 리포트에는 RPN Top 10을 포함하고, 신규 프로젝트 체크리스트에 FMEA 단계를 넣어 분석을 정례화한다. RCA와 FMEA 결과는 Knowledge Base에 등록해 유사 사례를 검색할 수 있게 하고, 과거 RCA 사례는 온보딩 교육에도 활용한다.
RCA는 이미 발생한 장애에서 배우는 방법이고, FMEA는 발생하지 않은 위험에 대비하는 방법이다. 두 분석 결과가 지속적으로 연결될 때, 장애 대응은 일회성 보고가 아니라 조직의 학습 체계가 된다.