753. FTA (Fault Tree Analysis)

핵심 인사이트 (3줄 요약)

1. 본질: FTA (Fault Tree Analysis)는 "서비스 불가" 같은 최상위 사고에서 출발해, 그 사고를 만드는 하위 고장 조합을 논리 게이트로 역추적하는 연역적 신뢰성 분석이다.
2. 가치: 단일 부품 고장보다 어떤 조합이 재앙을 만드는지 보여 주므로, 공통 원인 장애와 단일 장애점에 예산을 집중하게 만든다.
3. 판단 포인트: 독립성, 공통 원인, 복구 동작을 어떻게 가정하느냐에 따라 결과가 달라지며, 수리·상태 전이가 핵심이면 Markov Model이나 실험 검증을 함께 써야 한다.

Ⅰ. 개요 및 필요성

FTA (Fault Tree Analysis)는 최상위 사고 (Top Event)를 먼저 정한 뒤, "이 사고가 일어나려면 어떤 조건이 성립해야 하는가"를 아래로 내려가며 분해하는 기법이다. 즉 "부품이 고장 날 수 있다"는 막연한 불안에서 출발하는 것이 아니라, "DB 서비스가 멈췄다", "전원 경로가 상실됐다", "데이터가 손상됐다"처럼 사용자나 운영자가 실제로 체감하는 실패를 출발점으로 삼는다.

이 접근이 필요한 이유는 복잡한 시스템에서 위험이 개별 부품이 아니라 조합으로 나타나기 때문이다. 예를 들어 서버에 전원공급장치인 PSU (Power Supply Unit)를 두 개 넣었다고 해도, 두 PSU가 같은 전원분배장치인 PDU (Power Distribution Unit)에 매달려 있으면 공통 원인 장애가 남는다. FTA는 이런 구조를 "둘 중 하나가 죽으면 끝"인지, "둘 다 죽어야 끝"인지 논리식으로 드러낸다.

또한 FTA는 인증, 감사, 아키텍처 리뷰에서 설명력이 높다. 경영진에게 "이 장비가 위험합니다"라고 말하는 것보다, "이 세 사건이 동시에 일어날 때만 재앙이 발생하며, 현재는 이 공통 이벤트가 지배적입니다"라고 말하는 편이 훨씬 설득력이 있다. 그래서 항공우주, 원자력, 자동차뿐 아니라 고가용성 서버, 스토리지, 전원 설계에서도 자주 쓰인다.

• 📢 섹션 요약 비유: FTA는 불이 난 뒤 현장을 보며 "어디서 시작됐고 어떤 길로 번졌는가"를 그리는 화재 조사도와 같다. 연기만 보는 것이 아니라, 불길이 꼭 지나야 했던 경로를 찾아내는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

FTA의 기본 구성은 간단하다. Top Event가 맨 위에 있고, 그 아래에 Intermediate Event와 Basic Event가 논리 게이트로 연결된다. 중요한 것은 트리를 예쁘게 그리는 일이 아니라, 각 사건을 같은 수준의 추상도로 정의하고, 게이트의 의미를 수학적으로 일관되게 유지하는 일이다.

FTA의 정량화는 게이트 의미에서 바로 나온다. 독립 사건 p1, p2, ...가 있을 때 OR 게이트는 P = 1 - ∏(1 - p_i)이고, 희박 사건이면 P ≈ Σp_i로 근사한다. AND 게이트는 P = ∏p_i가 된다. 이때 설계자가 특히 주목하는 것은 최소 컷 집합 (Minimal Cut Set) 으로, Top Event를 발생시키는 데 필요한 최소 Basic Event 조합이다. 결국 FTA는 "무엇이 위험한가"를 넘어 "어떤 조합을 끊으면 재앙 확률이 가장 많이 줄어드는가"를 알려 준다.

아래 그림은 데이터베이스 서비스 중단을 단순화한 예다. 한 가지 경로는 전원 이중화가 모두 무너지는 경우이고, 다른 경로는 클러스터 노드 둘이 모두 상실되는 경우다.

┌──────────────────────────────────────────────────────────────────────┐
│            FTA example: "DB service unavailable" top event          │
├──────────────────────────────────────────────────────────────────────┤
│ DB service unavailable                                               │
│            │                                                         │
│        ┌── OR ───────────────────────┐                               │
│        │                             │                               │
│   power path lost              cluster quorum lost                   │
│        │                             │                               │
│   ┌── AND ───┐                 ┌── AND ───┐                          │
│   │          │                 │          │                          │
│ utility fail UPS fail     node A fail node B fail                    │
└──────────────────────────────────────────────────────────────────────┘

이 그림의 핵심은 "부품 수"가 아니라 "논리 구조"다. 예를 들어 utility fail과 UPS fail이 동시에 일어날 확률이 매우 작더라도, node A fail과 node B fail이 같은 펌웨어 버그를 공유한다면 두 사건은 독립이 아니며 실제 위험은 더 커질 수 있다. 따라서 FTA는 수식 자체보다 가정의 질이 더 중요하다.

• 📢 섹션 요약 비유: FTA는 성벽 방어도를 그리는 전쟁 지도와 같다. 적이 한 문만 뚫어도 끝나는지, 성문과 내성문을 모두 넘어야 하는지에 따라 전체 방어력 계산이 달라진다.

Ⅲ. 비교 및 연결

FTA를 제대로 이해하려면 비슷한 신뢰성 기법과의 경계를 알아야 한다. 같은 장애를 다루더라도 질문이 다르면 도구도 달라진다.

FTA와 RBD는 자주 쌍으로 다뤄진다. FTA가 실패 쪽에서 "왜 멈추는가"를 설명한다면, RBD는 성공 쪽에서 "어떤 경로가 남아 있으면 버티는가"를 보여 준다. 둘은 같은 시스템을 서로 다른 방향에서 본다고 이해하면 쉽다. 반면 Markov Model은 정적인 트리보다 한 단계 더 나아가, 복구와 대기 예비계 같은 동적 행위를 다룬다.

컴퓨터구조 관점에서는 ECC (Error Correcting Code) 메모리, 이중 PSU, RAID, 다중 경로 입출력인 Multipath I/O, 감시 타이머인 Watchdog Timer가 모두 FTA의 하위 사건을 끊기 위한 설계 수단으로 연결된다. 즉 FTA는 분석 기법이지만, 실제로는 중복, 격리, 감지, 자동 전환 같은 아키텍처 결정으로 이어진다.

• 📢 섹션 요약 비유: FMEA가 건강검진표라면, FTA는 응급실에서 쓰러진 이유를 추적하는 사건 보고서이고, RBD는 어느 응급실 문이 열려 있으면 환자를 살릴 수 있는지 보는 동선도다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 FTA는 "보고서용 그림"이 아니라 투자 우선순위 도구다. 예를 들어 듀얼 PSU 서버라도 두 전원이 같은 랙 PDU와 같은 펌웨어를 공유한다면, PSU를 세 개로 늘리는 것보다 전원 도메인 분리와 펌웨어 이원화가 더 큰 효과를 낼 수 있다. FTA는 바로 이런 판단을 정량적으로 뒷받침한다.

또한 FTA는 서비스 가시성 관점으로 작성해야 한다. 부품 수준 사건만 잔뜩 나열하면 트리는 커지지만 의사결정에 도움이 되지 않는다. 반대로 Top Event를 "CPU 오류 발생"처럼 너무 낮게 잡으면 서비스 장애와 연결되지 않는다. 기술사 답안에서는 Top Event의 정의, 최소 컷 집합, 공통 원인 장애, 보완 설계를 한 흐름으로 보여 주는 것이 중요하다.

실무 체크리스트

1. Top Event가 사용자 체감 실패 또는 안전 실패로 명확히 정의되었는가?
2. 이중화된 부품 뒤에 숨어 있는 공통 전원, 공통 펌웨어, 공통 냉각을 별도 Basic Event로 뽑았는가?
3. Basic Event의 확률이 제조사 홍보값이 아니라 현장 데이터나 검증 가능한 근거를 가지는가?
4. 독립 가정이 성립하지 않는 사건은 공통 원인 장애나 상관 사건으로 따로 다루는가?
5. 도출된 컷 집합을 결함 주입 테스트나 장애 복구 훈련으로 실제 검증하는가?

피해야 할 안티패턴

• 독립 가정 남용: 같은 랙, 같은 배치, 같은 펌웨어를 쓰는 노드를 서로 독립이라고 놓는 경우다.
• 트리 과세분화: 해석보다 도면 크기만 커져, 어떤 컷 집합이 중요한지 오히려 보이지 않게 된다.
• 정적 분석의 과신: 재부팅, 자동 복구, 운영 개입이 중요한 시스템을 FTA 하나로 끝내는 경우다.

결국 FTA는 "무엇이 고장 날까?"보다 "어떤 조합이 치명적인가?"를 묻는 도구다. 따라서 설계자가 돈을 써야 할 지점은 발생 확률이 높은 부품만이 아니라, Top Event를 직접 만드는 조합의 교차점이어야 한다.

• 📢 섹션 요약 비유: FTA는 수도관 누수 수리에서 바닥의 물웅덩이만 닦는 일이 아니라, 물이 꼭 지나야 하는 갈라진 관을 찾는 일과 같다. 근본 관을 막아야 물바다가 다시 생기지 않는다.

Ⅴ. 기대효과 및 결론

FTA를 잘 사용하면 설계 초기 단계에서 치명적인 약점을 논리적으로 제거할 수 있다. 그 결과 고가용성 설계는 "막연히 많이 이중화한 구조"가 아니라, 재앙 확률을 실제로 줄이는 구조로 바뀐다. 인증 문서, 안전성 심사, 투자 심의에서도 설명력이 높아지는 이유가 여기에 있다.

하지만 한계도 분명하다. FTA는 본질적으로 정적 모델이므로 순차 의존, 복구 시간, 대기 예비 전환 실패, 성능 저하 상태를 자연스럽게 표현하기 어렵다. 또한 결과는 입력 사건과 독립 가정의 품질에 크게 좌우된다. 그래서 실제 프로젝트에서는 FTA로 구조적 약점을 찾고, RBD로 성공 경로를 계산하고, Markov Model이나 결함 주입 테스트로 동적 복구를 검증하는 식의 조합이 가장 실용적이다.

결론적으로 FTA는 "장애 원인 나무"가 아니라, 최상위 실패를 만드는 논리 구조를 드러내는 설계 도구다. 기억해야 할 핵심은 하나다. 시스템을 안전하게 만드는 것은 부품을 무작정 늘리는 일이 아니라, Top Event에 도달하는 최소 경로를 끊는 일이다.

• 📢 섹션 요약 비유: 미로에서 출구를 막으려면 벽을 아무 데나 높이는 것이 아니라, 적이 반드시 지나야 하는 좁은 목을 찾아 막아야 한다. FTA는 그 좁은 목을 찾아내는 지도다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

hazard definition
    │
    ▼
Top Event definition
    │
    ▼
FTA (Fault Tree Analysis)
: OR gate · AND gate · basic event · cut set
    │
    ├──▶ quantification
    │     : event probability · common cause
    │
    ├──▶ design hardening
    │     : redundancy · isolation · watchdog
    │
    └──▶ follow-up validation
          : RBD · Markov model · fault injection

👶 어린이를 위한 3줄 비유 설명

1. FTA는 "장난감이 왜 완전히 멈췄지?"를 거꾸로 따라가 보는 탐정 놀이예요.
2. 배터리가 없었는지, 스위치가 고장 났는지, 아니면 둘이 같이 문제였는지를 나무처럼 그려 봐요.
3. 그러면 다음에는 어디를 먼저 고쳐야 장난감이 안 멈추는지 알 수 있어요.