Error, Fault, Failure — 헷갈리는 개념 정리와 실무 사례

개발하다 보면 장애가 터졌을 때 이런 질문을 많이 받습니다.

이건 개발자가 실수한 거야?
아니면 시스템이 이상한 건가?
이건 버그야, 아니면 장애야?

이럴 때 필요한 게 바로, 세 가지 개념의 구분입니다:

오류(Error), 결함(Fault), 장애(Failure)

용어	정의	설명
🟥 Error (오류)	사람이 만든 실수	잘못된 코드, 잘못된 입력, 설정 오타 등
🟧 Fault (결함)	오류로 인해 시스템에 잘못된 설정 또는 값이 적용된 상태	오류가 코드나 설정, 인프라에 남아 있는 상태 시스템이 실행되면 장애가 발생될 것으로 예상되는 상태
🟨 Failure (장애)	결함으로 인해 서비스에서 피해가 발생한 상태	사용자 또는 모니터링 관점에서 서비스가 망가진 상태

[사람의 실수]   →   Error  
         ↓  
[시스템 내에 남은 문제] →   Fault  
         ↓  
[실행되어 장애 발생]   →   Failure

예시

🛠 실무 예시 1: 로그 수집기 Fluentd에서 데이터 누락

단계내용

Error	개발자가 Fluentd 설정 파일에서 잘못된 Kafka 플러그인 이름 입력
Fault	이 잘못된 설정이 운영 서버에 반영됨
Failure	Kafka로 로그가 전송되지 않아, 대시보드와 S3에 데이터 누락 발생

🛠 실무 예시 2: 웹 API 응답 지연

단계내용

Error	FastAPI 코드에서 await 키워드 빠뜨림 (비동기 함수 누락)
Fault	블로킹 코드가 운영에 반영되어 I/O 작업 병목 발생
Failure	사용자가 API 호출 시 응답이 늦어지거나 타임아웃 발생 (HTTP 504)

Error는 인간의 실수,

Fault는 그 실수가 시스템에 남은 흔적,

Failure는 그 흔적이 실행되어 실제로 시스템이 고장난 상태입니다.

🎯 왜 이 구분이 중요한가?

🔍 원인 분석 정확도 향상	장애 보고서나 RCA에서 원인을 단계별로 분리 가능
🧰 적절한 대응 전략 수립	Error는 교육/검토로, Fault는 테스트/검증으로, Failure는 복구 시스템으로 대응
🧑‍💻 엔지니어 간 커뮤니케이션 통일	“이건 단순 Error야, Fault로 넘어가기 전에 잡자” 같은 표현 가능

이걸 기반으로 장애발생에 대한 보고서를 작성한다.
RCA보고서 (Root Cause Analysis)

RCA(Root Cause Analysis)

Root Cause Analysis
원인 분석:
- Error: 설정 파일에서 Kafka 플러그인 타입 오타 발생
- Fault: 잘못된 설정이 CI/CD를 통해 운영에 반영됨
- Failure: Kafka로 로그 전송 실패 → S3 적재 누락 → 모니터링 지표 결손

여기에 더해서 실제로 보고서를 작성할 때는 항목이 더 추가 된다.

항목	설명
(1) Incident Summary	언제, 어떤 시스템에서, 어떤 문제가 발생했는지 요약
(2) Error (오류)	사람이 만든 실수 (코드, 설정, 환경변수 등)
(3) Fault (결함)	오류로 인해 시스템에 남은 문제
(4) Failure (장애)	실제 서비스나 기능이 중단된 상태
(5) Detection	장애를 어떻게 인지했는가 (모니터링, 사용자 제보 등)
(6) Impact	사용자나 시스템에 미친 영향
(7) Resolution	장애를 어떻게 해결했는지
(8) Prevention / RCA	같은 일이 재발하지 않기 위해 어떤 조치를 할 것인가

예시

항목	내용
(1) Incident Summary	2025-07-13 오전 10:15~10:40, Kafka 로그 수집 파이프라인에서 일부 로그 유실 발생
(2) Error (오류)	신입 엔지니어가 Fluentd 설정에서 @type kafka_buffered 대신 @type kafka로 잘못 설정
(3) Fault (결함)	설정 파일은 CI/CD 파이프라인을 통해 배포됨 → 잘못된 설정이 실제 시스템에 반영됨
(4) Failure (장애)	Kafka에 로그가 전송되지 않음 → S3 저장 누락 발생 (15분간 약 1만 건 유실)
(5) Detection	Prometheus에서 로그 수집량 급감 경고 발생 → SRE팀이 Slack으로 인지
(6) Impact	실시간 대시보드 누락, 일부 보안 감사 로그 누락 가능성 있음
(7) Resolution	올바른 설정으로 Fluentd 재배포, 수동으로 재수집 가능한 로그는 재처리함
(8) Prevention / RCA	- CI 단계에서 Fluentd 설정 정적 검사 추가- Kafka 연동 전 송신 검증 유닛 테스트 추가- 설정 변경 시 두 명 이상 승인 프로세스 적용

🧠 팁: 현업에서 RCA를 잘 쓰는 팁

감정 배제: 누구의 실수든 기록은 중립적으로 써야 함
❌ "개발자가 이상하게 설정함"
✅ "설정이 예상과 다르게 배포됨"
3단 구분 꼭 포함 (Error → Fault → Failure)
→ 원인 추적이 명확해야 개선이 가능
재발 방지 조치(Prevention)는 Actionable 하게
→ "테스트 강화하자" (X)
→ "CI 단계에 config linter 추가하고 PR 승인 체계를 도입" (O)

# 장애 보고서 (RCA)

## 1. 요약
- 발생 일시: 2025-07-13 10:15 ~ 10:40
- 시스템: Fluentd → Kafka 로그 수집 파이프라인
- 영향: 로그 유실 약 1만 건

## 2. 원인 분석
- Error: 설정 파일에 잘못된 Kafka 플러그인 유형 사용
- Fault: 잘못된 설정이 운영 시스템에 반영됨
- Failure: Kafka에 로그 미전송 → S3 적재 실패

## 3. 장애 감지 및 대응
- 감지: Prometheus 알림 + Slack 경고
- 대응: 설정 수정 후 Fluentd 재배포, 일부 로그 수동 재수집

## 4. 재발 방지 대책
- 설정 검사 자동화 (CI config linter 추가)
- 코드 리뷰 승인 절차 강화
- Kafka 연결 상태 테스트 추가

RCA 보고서 양식

# 🧯 장애 보고서 (Root Cause Analysis)

## 1. 장애 개요 (Incident Summary)
- 📅 발생 일시: [YYYY-MM-DD HH:MM ~ HH:MM]
- 📍 발생 위치(시스템/서비스명): [ex. Kafka → S3 데이터 파이프라인]
- 📉 사용자 영향도: [ex. 일부 로그 유실 / 전체 서비스 중단 / 지연 발생 등]
- 📋 장애 요약: [간단한 한 줄 설명]

---

## 2. 원인 분석 (Cause Analysis)

### 🔹 Error (오류)
- [사람 또는 시스템이 만든 실수. ex. 설정 오타, 잘못된 코드 커밋 등]

### 🔸 Fault (결함)
- [위 오류가 시스템에 남긴 문제. ex. 잘못된 설정이 프로덕션에 반영됨 등]

### ❌ Failure (장애)
- [결함이 실행되어 사용자에게 실제 영향을 준 현상]

---

## 3. 감지 및 대응 (Detection & Response)
- 🧪 감지 방식: [모니터링 경고 / 사용자 제보 / 로그 분석 등]
- ⚙️ 1차 대응: [ex. 서버 재시작 / 롤백 / 임시 핫픽스]
- 🛠 최종 해결: [ex. 설정 수정 후 재배포, DB 복구 등]

---

## 4. 영향 분석 (Impact)
- ⏱ 장애 시간: [ex. 총 25분]
- 👥 사용자 수 / 트래픽 영향: [ex. 일 평균 트래픽의 30% 영향]
- 📦 데이터 유실 여부: [ex. Kafka 메시지 15,000건 손실]

---

## 5. 재발 방지 대책 (Prevention)
- ✅ 기술적 조치:
  - [ex. 설정 정적 검사 도구 도입]
  - [ex. 서비스 헬스체크 주기 단축]
- 🧑‍💻 운영 프로세스 개선:
  - [ex. PR 2인 승인제 적용]
  - [ex. 배포 전 체크리스트에 항목 추가]

---

## 6. 첨부 자료
- 🔗 관련 로그/스크린샷/모니터링 그래프
- 🔗 Jira 티켓 / GitHub PR / Slack 캡처 등