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

  1. 본질: 고장 허용 시스템 (Fault Tolerance)은 부품이나 노드 일부가 고장 나도 서비스를 멈추지 않도록, 오류를 내부에서 흡수·우회·은닉하는 설계 철학이다.
  2. 가치: 단순히 "빨리 복구"하는 수준을 넘어, 계산 중단·데이터 손실·제어 공백을 최소화해 항공, 금융, 제어 시스템처럼 실패 비용이 큰 환경을 지킨다.
  3. 판단 포인트: 고장 허용은 중복 자원과 동기화 비용이 매우 크므로, 모든 시스템에 적용할 정답이 아니라 장애 허용 한계와 비용 구조를 보고 선택해야 한다.

Ⅰ. 개요 및 필요성

고장 허용 시스템 (Fault Tolerance)은 일부 구성 요소의 장애가 발생해도 전체 시스템이 정의된 서비스를 계속 수행하도록 만드는 구조다. 여기서 핵심은 "고장이 없어야 한다"가 아니라 "고장이 생겨도 멈추지 않아야 한다"는 점이다. 실제 시스템은 전원 공급 장치, 메모리 셀, 통신 링크, 소프트웨어 프로세스 중 어느 하나라도 언젠가는 실패하므로, 설계 단계부터 장애를 정상 시나리오로 받아들여야 한다.

이 개념이 필요한 이유는 장애가 단순한 불편을 넘어 즉시 손실로 이어지는 영역이 있기 때문이다. 원자력 제어, 항공 전자 장비, 증권 거래 원장, 병원 생명 유지 장비는 몇 초의 공백도 허용하기 어렵다. 이런 환경에서는 "장애 후 재시작"보다 "장애 중에도 계속 동작"이 더 중요하며, 그 차이가 곧 안전성과 신뢰성의 차이를 만든다.

또한 고장 허용은 단일 장애점 (SPOF, Single Point of Failure)을 없애는 문제와 직결된다. CPU는 멀쩡해도 전원 하나가 끊기면 멈추고, 서버 두 대가 있어도 공유 스토리지 하나가 고장 나면 전체 서비스가 멈춘다. 따라서 고장 허용은 부품 개수보다도, "어디가 끊기면 전체가 쓰러지는가"를 먼저 찾는 사고방식에서 출발한다.

  • 📢 섹션 요약 비유: 고장 허용 시스템은 외줄 사다리가 아니라 여러 줄 안전망을 친 곡예장과 같다. 한 줄이 끊어져도 공연이 바로 중단되지 않도록, 처음부터 추락을 버티는 구조로 준비해 두는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

고장 허용 시스템은 보통 중복 (Redundancy), 오류 검출, 격리, 대체 수행, 상태 일관성 유지라는 다섯 축으로 구성된다. 중복만 있다고 고장 허용이 완성되지는 않는다. 장애를 알아채지 못하면 전환할 수 없고, 전환은 했더라도 상태가 어긋나면 같은 결과를 계속 제공할 수 없기 때문이다.

구성 원리무엇을 중복/제어하는가대표 기술설계 핵심
하드웨어 중복전원, CPU, 네트워크, 저장장치이중 전원, TMR (Triple Modular Redundancy), RAID (Redundant Array of Independent Disks)동일 고장이 동시에 나지 않게 물리 경로도 분리
정보 중복데이터 자체ECC (Error Correcting Code), 패리티 (Parity), 체크섬 (Checksum)비트 오류를 검출만 할지, 즉시 복구까지 할지 결정
시간 중복동일 연산 재수행Retry, Rollback, 재전송일시 장애에는 강하지만 지연 증가를 감수
소프트웨어 중복프로세스/서비스 복제Active-Active, N-Version Programming버전 다양성과 상태 동기화 비용 균형
장애 제어탐지·격리·우회Watchdog, Heartbeat, Voter장애 전파를 막고 정상 경로를 유지

다음 그림은 고장 허용이 단순 백업이 아니라, 장애를 발견하고 즉시 우회해 서비스 연속성을 유지하는 흐름이라는 점을 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│            고장 허용의 동작 흐름: 장애를 감추며 계속 서비스         │
├──────────────────────────────────────────────────────────────────────┤
│ 정상 요청                                                            │
│    │                                                                 │
│    ▼                                                                 │
│ [주 경로 수행] ── 장애 발생 ──▶ [검출기: Heartbeat / ECC / Timeout]  │
│                                      │                               │
│                                      ▼                               │
│                           [격리: 고장 부품 차단]                     │
│                                      │                               │
│                                      ▼                               │
│                  [대체 경로: 복제본·예비 전원·다수결 결과 사용]      │
│                                      │                               │
│                                      ▼                               │
│                           [서비스 지속 / 상태 보존]                 │
└──────────────────────────────────────────────────────────────────────┘

대표 사례로 TMR은 세 개의 동일 모듈이 같은 입력을 처리하고, 보터 (Voter)가 다수결로 결과를 선택한다. 한 모듈이 방사선이나 열화로 오동작해도 나머지 둘이 같은 값을 내면 출력은 유지된다. 메모리에서는 ECC가 1비트 오류를 즉시 교정하고, 저장장치에서는 RAID 1이나 RAID 6이 디스크 손실 중에도 데이터를 계속 제공한다. 결국 고장 허용의 핵심은 "고장을 없애는 것"이 아니라 "고장이 결과로 드러나지 않게 만드는 것"이다.

  • 📢 섹션 요약 비유: 고장 허용 구조는 세 명이 동시에 같은 계산을 하고 정답이 둘 이상 일치하면 그 답을 채택하는 시험 감독 방식과 같다. 한 명이 실수해도 전체 점수가 틀어지지 않게 만드는 장치다.

Ⅲ. 비교 및 연결

고장 허용은 자주 고가용성 (High Availability, HA)과 함께 언급되지만, 둘은 목표와 허용 범위가 다르다. 고가용성은 장애가 나도 빠르게 복구해 서비스 중단 시간을 짧게 만드는 데 초점을 둔다. 반면 고장 허용은 장애가 발생한 순간에도 처리 연속성과 결과 일관성을 가능한 한 유지하려 한다. 즉 HA가 "빨리 다시 일어나는 것"이라면, FT는 "쓰러진 티를 최대한 안 내는 것"에 가깝다.

비교 항목고장 허용 시스템 (FT)고가용성 (HA)
장애 시 목표서비스 지속, 결과 은닉빠른 복구, 중단 최소화
전환 방식동시 중복, 다수결, 즉시 우회Failover, 재시작, 승격
허용 중단거의 0에 가깝게 설계수 초~수 분도 상황에 따라 허용
대표 예시항공 제어, 미션 크리티컬 제어웹 서비스 이중화, DB 스탠바이
비용 구조매우 높음상대적으로 낮음

이 차이는 분산 시스템에서도 그대로 이어진다. 예를 들어 합의 알고리즘인 Raft나 Paxos는 일부 노드 장애 속에서도 다수 노드 기준으로 서비스를 이어 가며, 저장소 복제와 쿼럼 읽기/쓰기를 통해 장애를 흡수한다. 반대로 배치 시스템이나 일반 사내 서비스는 반드시 FT까지 갈 필요가 없고, 충분한 HA만으로도 비용 대비 효과가 더 좋을 수 있다.

따라서 FT를 이해할 때는 "중복이 많다"보다 "얼마나 즉시 결과를 유지해야 하는가"를 기준으로 봐야 한다. 같은 이중화라도 Active-Standby는 HA에 가깝고, Lockstep이나 Active-Active 동기 실행은 FT에 가깝다. 경계는 장비 개수보다 장애를 사용자에게 얼마나 노출하느냐에서 갈린다.

  • 📢 섹션 요약 비유: HA는 예비 선수가 벤치에서 대기하다가 교체 투입되는 팀이고, FT는 주전 둘이 같은 동작을 동시에 따라 하며 한 명이 넘어져도 장면이 끊기지 않게 만드는 스턴트 팀과 같다.

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

실무에서는 "무조건 FT"가 아니라 장애 비용과 복구 목표를 수치로 본 뒤 설계를 정해야 한다. 거래 한 건의 손실이 치명적이면 ECC 메모리, 이중 전원, 다중 네트워크 경로, 저장소 복제, 애플리케이션 다중 실행을 함께 고려해야 한다. 반대로 몇 분 내 복구가 허용되는 내부 업무 시스템이라면, 과도한 FT 설계는 비용·복잡도·운영 난이도만 높일 수 있다.

특히 FT 도입 시에는 장애 독립성을 반드시 확인해야 한다. 예비 서버를 두 대 두었더라도 같은 랙, 같은 전원, 같은 스위치, 같은 버그를 공유하면 실제로는 동시에 무너질 수 있다. 그래서 전원 이중화는 서로 다른 전원 회로에 연결하고, 복제본은 다른 가용 영역 (Availability Zone)에 두며, 소프트웨어 복제도 동일 결함이 한 번에 전파되지 않도록 배포 전략을 분리해야 한다.

다음 판단 흐름은 실무에서 FT와 HA의 경계를 가를 때 자주 쓰는 질문들이다.

┌──────────────────────────────────────────────────────────────┐
│           FT 도입 판단: 중단 불가인가, 빠른 복구면 되는가    │
├──────────────────────────────────────────────────────────────┤
│ 1. 장애 시 데이터 손실 0건이 필요한가?                      │
│ 2. 재시작/Failover 중 수 초 공백도 허용 불가인가?           │
│ 3. 단일 장애점 제거 비용보다 장애 비용이 더 큰가?           │
│ 4. 중복 상태를 지속적으로 동기화할 운영 역량이 있는가?      │
├──────────────────────────────────────────────────────────────┤
│ 대부분 Yes  ─▶ FT 중심 설계                                 │
│ 일부만 Yes  ─▶ HA + 선택적 FT(ECC, RAID, 이중 전원 등)      │
│ 대부분 No   ─▶ 단순화된 HA 또는 백업/복구 중심 설계         │
└──────────────────────────────────────────────────────────────┘

체크리스트

  1. 단일 장애점 (SPOF, Single Point of Failure)이 남아 있지 않은가?
  2. 장애 탐지 시간이 서비스 수준 목표 (SLO, Service Level Objective) 안에 들어오는가?
  3. 중복 경로가 같은 전원, 네트워크, 펌웨어 결함을 공유하지 않는가?
  4. 장애 중에도 상태 일관성, 순서 보장, 중복 처리 문제가 통제되는가?

안티패턴

  • 예비 장비는 두되 상태 복제를 하지 않아 전환 순간 데이터가 달라지는 설계

  • Active-Active라고 해 놓고 실제로는 같은 스토리지 하나에만 의존하는 설계

  • 장애 은닉보다 운영 복잡도가 더 큰데도, 유행처럼 FT를 전면 도입하는 판단

  • 📢 섹션 요약 비유: 고장 허용 설계는 우산을 하나 더 사는 일이 아니라, 비가 와도 행사가 끊기지 않게 실내 대체 장소·예비 발전기·보조 음향까지 미리 준비하는 행사 운영과 같다.


Ⅴ. 기대효과 및 결론

고장 허용 시스템의 가장 큰 효과는 장애를 "사건"이 아니라 "흡수 가능한 조건"으로 바꾼다는 점이다. 사용자는 일부 부품이 고장 났다는 사실을 모른 채 서비스를 계속 이용하고, 운영자는 중단 복구보다 계획된 교체와 예방 정비에 더 집중할 수 있다. 이 특성은 안전성, 신뢰성, 서비스 연속성이 핵심인 시스템에서 결정적 가치를 만든다.

다만 FT는 공짜가 아니다. 하드웨어 수량이 늘고, 동기화 지연이 생기며, 테스트해야 할 장애 조합도 폭발적으로 증가한다. 특히 동일 원인에 의해 중복 장치가 함께 실패하는 공통 모드 고장 (Common-Mode Failure)을 막지 못하면, 비싼 중복도 실제 장애 앞에서는 무력해질 수 있다.

앞으로의 방향은 단순한 물리 중복을 넘어, 예지 정비와 자동 복구를 결합하는 쪽으로 간다. 하지만 어떤 시대에도 기억해야 할 관점은 같다. 고장 허용의 본질은 "절대 안 고장 나는 장비"를 만드는 것이 아니라, "고장 나도 임무를 계속 수행하는 시스템"을 만드는 것이다.

  • 📢 섹션 요약 비유: 좋은 고장 허용 시스템은 절대 깨지지 않는 유리컵이 아니라, 금이 가도 물을 계속 담을 수 있게 겹겹이 보호막을 둔 보온병과 같다.

📌 관련 개념 맵

개념연결 포인트
단일 장애점 (SPOF, Single Point of Failure)고장 허용 설계가 가장 먼저 제거해야 하는 취약 지점
TMR (Triple Modular Redundancy)다수결로 모듈 오동작을 출력 단계에서 은닉하는 대표 기법
ECC (Error Correcting Code) 메모리비트 오류를 검출·교정해 메모리 계층의 FT를 강화
RAID (Redundant Array of Independent Disks)저장장치 장애 중에도 데이터 접근을 지속하게 하는 중복 구조
고가용성 (High Availability)FT와 비슷해 보이지만 복구 중심이라는 점에서 경계가 다른 개념
쿼럼 (Quorum) 기반 복제분산 시스템에서 일부 노드 장애를 다수결로 흡수하는 확장 형태

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

신뢰성 요구 증가
    │
    ▼
단일 장애점 (SPOF, Single Point of Failure) 제거
    │
    ▼
이중화 · 패리티 · ECC (Error Correcting Code)
    │
    ▼
TMR (Triple Modular Redundancy) · RAID · Lockstep
    │
    ▼
클러스터 복제 · 쿼럼 (Quorum) · 합의 알고리즘
    │
    ▼
자가 복구 · 예지 정비 기반 고장 허용 아키텍처

이 흐름은 부품 단위 보호에서 시작해, 시스템·클러스터·운영 자동화 수준으로 고장 허용의 범위가 확장되는 과정을 보여준다.

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

  1. 고장 허용 시스템은 자전거 바퀴 하나가 펑크 나도 바로 넘어지지 않게 예비 바퀴를 달아 둔 것과 비슷해요.
  2. 그래서 한 부분이 망가져도 나머지 장치들이 바로 대신 움직여서 계속 앞으로 갈 수 있어요.
  3. 중요한 일을 하는 컴퓨터는 이렇게 "고장 나도 멈추지 않기"를 미리 연습해 두는 거예요.