RCA(Root Cause Analysis) 방법론 — 5 Whys·피쉬본 분석

복구는 했지만 같은 장애가 반복된다면 RCA가 제대로 이루어지지 않은 것입니다. RCA(Root Cause Analysis)는 “왜 이 일이 일어났는가”를 증거 기반으로 추적하는 과정입니다.

RCA의 목적: 비난이 아닌 원인 제거

좋은 RCA는 다음 세 가지를 구분합니다:

구분	예시	조치
직접 원인	잘못된 쿼리가 DB를 잠금	쿼리 수정
기여 요인	코드 리뷰에서 쿼리 성능 검토 없음	리뷰 체크리스트 추가
근본 원인	배포 전 부하테스트 프로세스 없음	릴리스 게이팅 도입

5 Whys 기법

가장 간단하고 강력한 RCA 도구입니다. “왜?”를 최소 5번 반복해서 표면 원인을 파고듭니다.

장애: 결제 서비스 30분 다운

Why 1: 왜 다운됐나?
  → DB 커넥션 풀이 고갈됨

Why 2: 왜 커넥션 풀이 고갈됐나?
  → 특정 쿼리가 테이블 풀 스캔으로 30초씩 잡고 있었음

Why 3: 왜 그 쿼리가 배포됐나?
  → 로컬 데이터(100건)에서는 문제없었고, 프로덕션(100만건)에서만 느렸음

Why 4: 왜 프로덕션 규모에서 테스트 안 했나?
  → 성능 테스트 환경이 없음, 배포 파이프라인에 부하테스트 단계 없음

Why 5: 왜 성능 테스트 환경이 없나?
  → 초기 스타트업 단계에서 "나중에 만들자"로 미뤄진 기술 부채

근본 원인: 배포 파이프라인에 성능 검증 단계가 없는 것
→ 액션: CI/CD에 TestForge 부하테스트 게이팅 추가

인과 관계 다이어그램 (Fishbone / Ishikawa)

복잡한 장애는 단일 원인이 아닌 여러 원인이 얽혀 있습니다. 피쉬본 다이어그램으로 원인을 범주별로 시각화합니다.

                    [장애: 결제 API p99 10초 초과]
                              |
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
    [코드]               [인프라]               [프로세스]
     │                     │                     │
 N+1 쿼리             DB 인스턴스          부하테스트 없음
 인덱스 누락          스펙 부족           릴리스 기준 없음
 동기 블로킹          네트워크 지연        모니터링 임계치 높음

범주 예시: 코드 / 인프라 / 프로세스 / 사람 / 외부 의존성

타임라인 재구성

RCA의 핵심은 정확한 타임라인입니다. 추측이 아닌 로그·배포 기록·지표 스냅샷으로 증거를 채웁니다.

## 인시던트 타임라인 (2026-04-03)

| 시각 | 이벤트 | 출처 |
|------|--------|------|
| 14:15 | payment-api v2.3.1 배포 완료 | ArgoCD 배포 로그 |
| 14:28 | DB CPU 급증 시작 (30% → 85%) | Grafana 스냅샷 |
| 14:32 | 에러율 5% 초과, P1 알림 발생 | PagerDuty |
| 14:38 | 인시던트 채널 개설, 조사 시작 | Slack #incident-p1 |
| 14:52 | 원인 특정: 신규 쿼리 풀 스캔 | DB 슬로우 쿼리 로그 |
| 15:05 | v2.3.0으로 롤백 완료 | kubectl rollout undo |
| 15:12 | 에러율 0.1%로 복구 | Grafana |
| 15:20 | 인시던트 종료 선언 | IL |

기여 요인 분석 체크리스트

탐지 측면
□ 알림이 제때 울렸는가? (탐지 지연이 있었는가?)
□ 알림의 내용이 충분히 명확했는가?
□ 합성 모니터링이 있었다면 더 빨리 탐지했을 것인가?

대응 측면
□ 런북이 있었는가? 최신 상태였는가?
□ 역할 분담이 명확했는가?
□ 의사결정에 불필요한 지연이 있었는가?

예방 측면
□ 이 변경은 사전 리뷰를 거쳤는가?
□ 스테이징 환경에서 재현 가능한 이슈였는가?
□ 유사 장애 이력이 있었는가?

액션 아이템 도출 원칙

RCA의 결과물은 반드시 구체적이고 추적 가능한 액션이어야 합니다.

나쁜 액션	좋은 액션
”모니터링 강화"	"결제 API에 에러율 1% 경보 추가 (담당: @devops, 기한: 04-10)"
"코드 리뷰 철저히"	"PR 체크리스트에 ‘DB 쿼리 실행 계획 첨부’ 항목 추가 (담당: @tech-lead, 기한: 04-07)"
"부하테스트 진행"	"CI/CD 파이프라인에 TestForge 게이팅 추가, 에러율 > 1%면 배포 차단 (담당: @platform, 기한: 04-17)”

모든 액션에는 담당자, 기한, 완료 기준이 있어야 합니다.

다음 단계

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →