296. 결함 허용 (Fault Tolerance) 시스템 설계

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

본질: 결함 허용(Fault Tolerance) 시스템은 하드웨어나 소프트웨어의 일부 부품에 고장(Fault)이 발생하더라도, 시스템 전체가 멈추거나 중대한 성능 저하 없이 지속적으로 정상 서비스를 제공할 수 있도록 하는 아키텍처 설계 사상이다.

가치: "결함은 발생할 수밖에 없다"는 현실을 인정하고, 단일 장애점(SPOF)을 제거하여 시스템의 연속성(Availability)과 신뢰성(Reliability)을 극대화한다. 항공기, 우주선, 금융, 원자력 발전 등 단 1초의 멈춤이 대형 참사로 이어지는 미션 크리티컬(Mission-Critical) 환경의 필수 요건이다.

융합: 결함 허용을 달성하기 위해 가장 보편적으로 사용되는 기술이 '이중화(Redundancy, 병렬 모델)'이며, 이는 클라우드 네이티브의 오토스케일링, MSA의 서킷 브레이커, 분산 데이터베이스의 복제(Replication) 아키텍처와 완벽하게 융합된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 결함 허용(Fault Tolerance)은 결함(Fault)이 에러(Error)를 거쳐 최종적인 장애(Failure)로 전파되는 것을 시스템 내부에서 스스로 흡수하고 차단하는 능력이다. 즉, "부분이 죽어도 전체는 산다"는 철학이다.
필요성: 은행의 코어 뱅킹 서버를 단 1대의 슈퍼컴퓨터(메인프레임)로 구성했다 치자. 아무리 비싸고 좋은 컴퓨터라도 벼락이 떨어지거나 디스크 수명이 다하면 죽는다. 서버가 죽는 순간, 전국 수백만 명의 카드 결제가 멈추고 현금 인출이 불가능해진다. 절대 고장 나지 않는 완벽한 기계를 만드는 것(Fault Avoidance)은 물리적으로 불가능하므로, 고장이 나더라도 옆의 기계가 즉시 업무를 이어받아 멈춤 없이 돌아가게 만드는 구조(Fault Tolerance)가 필요했다.
💡 비유: 스페어타이어(예비 타이어)를 싣고 다니는 자동차와 비슷합니다. 다만, 타이어가 펑크 났을 때 운전자가 내려서 타이어를 직접 교체하는 것은 '결함 복구(Recovery)'이고, 바퀴가 8개 달린 장갑차가 바퀴 1~2개가 터져도 속도를 늦추지 않고 계속 달릴 수 있는 것이 진정한 **'결함 허용(Fault Tolerance)'**입니다.
등장 배경 및 발전 과정:
1. 군사/우주 공학 (1960년대): 아폴로 우주선 프로젝트 등에서 우주 한가운데서 컴퓨터가 고장 날 때를 대비해 컴퓨터 3대를 싣고 다수결로 결정을 내리는 하드웨어 결함 허용 구조가 탄생했다.
2. 상용 엔터프라이즈 시스템 (1980년대): Tandem, Stratus 같은 기업들이 CPU, 메모리, 버스를 모두 2개씩 쌍으로 장착해 하드웨어 레벨에서 고장을 완벽히 흡수하는 결함 허용 서버(FT Server)를 상용화했다.
3. 소프트웨어 및 클라우드 결함 허용: 현대에는 비싼 전용 하드웨어 대신, 저렴한 일반 서버(Commodity Server) 수만 대를 묶고 소프트웨어(쿠버네티스, 하둡, 넷플릭스 OSS)가 서버의 죽음을 감지해 트래픽을 돌리고 복구하는 방식으로 진화했다.
📢 섹션 요약 비유: 결함 허용 시스템은 머리가 3개 달린 드래곤과 같습니다. 용사가 칼로 머리 하나를 베어도(결함), 남은 2개의 머리로 계속 불을 뿜으며 싸울 수 있는(정상 서비스) 무적의 생명력입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

결함 허용(Fault Tolerance) vs 결함 회피(Fault Avoidance)

이 둘은 신뢰성(Reliability)을 높이기 위한 두 가지 상반된 접근법이다.

비교 항목	결함 회피 (Fault Avoidance)	결함 허용 (Fault Tolerance)
설계 철학	"고장 날 일을 아예 만들지 말자"	"고장 날 것을 인정하고, 멈추지 않게 하자"
적용 기법	최고급 부품 사용, 혹독한 QA 테스트, 보수적인 코딩 룰 강제	이중화(Redundancy), 다양성(Diversity), 롤백
한계점	100% 버그나 마모가 없는 완벽한 부품은 세상에 없음	스페어(예비) 장비 구축 비용이 많이 듦
비유	아프지 않으려고 매일 홍삼 먹고 운동하기	아플 것에 대비해 암보험과 실비보험 여러 개 들어두기

결함 허용을 구현하는 4대 다중화(Redundancy) 전술

결함 허용의 가장 핵심적인 무기는 다중화(이중화)다. 무언가를 여러 개 복제해 두는 방식은 크게 4가지로 나뉜다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 결함 허용을 위한 4대 다중화(Redundancy) 기법        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  1. 하드웨어 다중화 (Hardware Redundancy)                       │
  │     - 서버, CPU, 네트워크 카드, 전원 공급 장치 등을 2개 이상 배치.      │
  │     - Active/Standby 클러스터링, RAID(디스크 이중화).              │
  │                                                             │
  │  2. 소프트웨어 다중화 (Software Redundancy)                      │
  │     - 동일한 로직을 처리하는 소프트웨어 모듈을 여러 개 띄워둠.          │
  │     - N-Version Programming (297번에서 상세 설명).                 │
  │                                                             │
  │  3. 정보 다중화 (Information Redundancy)                        │
  │     - 데이터가 깨졌을 때를 대비해 여분의 검증 데이터를 추가로 전송/저장. │
  │     - 패리티 비트(Parity Bit), 체크섬(Checksum), ECC 메모리.        │
  │                                                             │
  │  4. 시간 다중화 (Time Redundancy)                              │
  │     - 일시적인 네트워크 오류를 대비해, 시간을 두고 똑같은 작업을 재시도. │
  │     - 타임아웃 & 재시도 (Retry), 데드 레터 큐(DLQ).                  │
  └─────────────────────────────────────────────────────────────┘

능동형(Active) vs 수동형(Passive/Standby) 결함 허용

Active 결함 허용: 동일한 요청을 여러 대의 서버가 동시에 처리한다. 만약 3대의 서버가 계산을 해서 [A, A, B]라는 결과가 나오면, 2대의 서버가 낸 'A'를 다수결(Voting)로 채택한다. (항공기 비행 제어 등 우주/군사용)
Passive 결함 허용: 메인 서버(Active)만 일하고 대기 서버(Standby)는 심장박동(Heartbeat)만 주고받으며 쉰다. 메인이 죽으면 대기 서버가 그제야 깨어나서 업무를 이어받는다. (대부분의 웹 서비스, DB 이중화)
📢 섹션 요약 비유: 능동형은 중요한 문서를 보낼 때 우체국, 퀵서비스, 택배 3곳을 동시에 써서 하나라도 도착하게 만드는 사치스러운 방법이고, 수동형은 택배가 중간에 분실됐다는 연락을 받으면 그때야 새 물건을 다시 보내는 경제적인 방법입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 결함 허용(Fault Tolerance) vs 고가용성(High Availability, HA)

현업에서 가장 혼용되는 용어지만, 기술사적 아키텍처 관점에서 둘은 비용과 서비스 중단(Downtime) 허용치에서 급이 다르다.

비교 항목	고가용성 (High Availability, HA)	결함 허용 (Fault Tolerance, FT)
목표 가동률	99.9% ~ 99.99%	99.999% ~ 99.9999% (무중단)
장애 발생 시	장애를 감지하고 스위칭하는 동안 몇 초~몇 분의 멈춤(단절) 발생	0초 (무결절). 사용자는 장애를 전혀 느끼지 못함
적용 비용	서버 2대로 구축 가능 (비교적 저렴)	메모리 실시간 동기화 등 특수 하드웨어/아키텍처 필요 (매우 비쌈)
비유	예비 타이어. (갈아 끼우는 동안 차를 멈춰야 함)	런플랫 타이어. (펑크 나도 80km/h로 계속 달릴 수 있음)

과목 융합 관점

운영체제 (OS): RAID 1(미러링), RAID 5(패리티)는 하드디스크 고장이라는 물리적 결함을 허용하여 데이터 유실과 서비스 멈춤을 방어하는 OS/인프라 레벨의 정보 다중화 전술이다.
클라우드 / MSA: 넷플릭스가 만든 서킷 브레이커(Circuit Breaker, 예: Resilience4j) 패턴. 뒷단 서버에 결함이 생기면 앞단 서버가 계속 요청을 보내다 같이 죽는 연쇄 장애를 막기 위해, 연결을 툭 끊어버리고 "서버 점검 중입니다"라는 미리 준비된 캐시 화면(Fallback)을 띄우는 현대 소프트웨어의 우아한 결함 허용 기법이다.
📢 섹션 요약 비유: 고가용성(HA)은 메인 보컬이 목이 쉬면 무대를 5분 멈추고 대타 가수가 올라오는 것이고, 결함 허용(FT)은 무대에 똑같은 노래를 부르는 3명의 가수가 미리 서 있어서 한 명이 기절해도 관객은 노래가 멈추는 걸 절대 눈치챌 수 없는 완벽한 쇼입니다.

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

실무 시나리오

시나리오 — AWS 리전 전체 장애와 다중 리전(Multi-Region) 결함 허용: 한 스타트업이 AWS 서울 리전(ap-northeast-2)의 단일 존에 서버와 DB를 모두 구성했다. 어느 날 폭우로 데이터센터 전력이 차단되는 사상 초유의 사태가 발생했고, 회사의 서비스는 24시간 동안 전면 마비되었다.
- 아키텍트의 해결책: 물리적 랙(Rack)이나 데이터센터 전체의 고장을 고려하지 않은 **단일 장애점(SPOF)**의 방치다. 완벽한 결함 허용을 위해서는 **지리적 다중화(Geographical Redundancy)**가 필수적이다. 서울 리전뿐만 아니라 도쿄 리전에도 Active-Standby로 DB를 비동기 복제해 두고, Route 53(글로벌 DNS)를 통해 서울 리전 헬스체크 실패 시 트래픽을 10초 만에 도쿄 리전으로 넘기는 글로벌 장애 조치(Disaster Recovery) 아키텍처를 세워야 했다.
시나리오 — 시간 다중화(재시도)의 함정, 백오프(Backoff) 부재: 외부 통신 API를 호출하는데 결함 허용을 위해 try-catch 안에 while(retry < 5) 반복문을 넣어 실패 시 무조건 재시도하게 만들었다. 이벤트 날 외부 서버가 잠깐 1초 멈칫했는데, 우리 서버의 1만 개 스레드가 동시에 5번씩 재시도 폭격(5만 번의 트래픽)을 날렸고, 결국 외부 서버는 우리 회사의 공격(DDoS)을 받아 완전히 터져버렸다.
- 아키텍트의 해결책: 시간 다중화(재시도) 전술을 설계할 때는 상대방 서버를 죽이지 않기 위한 보호 장치가 필수다. 실패 직후 바로 재시도하는 것이 아니라, **지수적 백오프(Exponential Backoff: 1초, 2초, 4초, 8초 쉬고 재시도)**와 랜덤한 지연 시간(Jitter)을 섞어 주어야 한다. 그래야 좀비처럼 몰려드는 재시도 트래픽의 파도를 분산시켜 결함 허용 시스템이 오히려 시스템 전체를 부수는 부작용을 막을 수 있다.

도입 체크리스트

비즈니스적 (ROI): 0초의 단절을 보장하는 Fault Tolerance를 구현하려면 모든 하드웨어와 인프라 비용이 최소 2~3배로 폭증한다. 이 시스템이 심장 수술 기기나 원자력 제어 시스템인가? 일반 쇼핑몰이라면 수 초의 단절을 허용하는 저렴한 고가용성(HA, Active-Standby)으로 타협하는 것이 아키텍트의 재무적 미덕이다.
기술적: 결함 허용을 위해 DB를 2대로 복제(Replication)했다 치자. 마스터가 죽어 슬레이브가 마스터로 승격(Failover)될 때, 아직 동기화되지 않은 0.1초 사이의 데이터(결제 내역)는 유실된다. 이 데이터 정합성(Consistency) 유실을 허용할 것인가, 아니면 동기식 복제로 성능을 깎아먹을 것인가?

안티패턴

스플릿 브레인 (Split-Brain) 현상: 결함 허용을 위해 Active 서버를 2대 묶어두었는데, 둘 사이의 심장박동(Heartbeat) 네트워크 선만 고장 났다. 둘 다 상대방이 죽은 줄 알고 "내가 마스터다!"라며 양쪽에서 데이터를 쓰기 시작해 DB가 완전히 박살 나는 현상. 다중화를 구성할 때는 반드시 3대(홀수)의 투표(Quorum) 시스템으로 설계하여 스플릿 브레인을 억제해야 한다.
📢 섹션 요약 비유: 결함 허용을 위해 경호원을 2명 고용했는데(이중화), 두 경호원끼리 "누가 대장이야?" 하고 싸우다가(스플릿 브레인) 정작 도둑(장애)을 못 막으면 아무 소용이 없습니다. 다수결을 정할 수 있게 경호원은 무조건 홀수(3명)로 고용해야 안전합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	단일 서버/비결함 허용 (AS-IS)	결함 허용 아키텍처 도입 (TO-BE)	개선 효과
정량	서버 고장 시 복구까지 시스템 다운타임 30분	이중화 및 서킷 브레이커로 즉시 우회 (0초)	시스템 다운타임 99.99% 소멸 (무중단 서비스)
정량	연쇄 장애(Cascading Failure) 발생률 연 5회	서킷 브레이커 격리로 연쇄 장애 0회	치명적 전면 장애 건수 제로화
정성	언제 터질지 몰라 휴일에도 전전긍긍하는 운영팀	결함을 스스로 치유하는(Self-healing) 시스템의 안정감	워라밸 향상 및 시스템 신뢰도에 대한 비즈니스 자부심

미래 전망

마이크로서비스와 Service Mesh: 과거에는 애플리케이션 개발자가 try-catch와 retry 로직을 코드에 일일이 짰다. 이제는 Istio나 Linkerd 같은 인프라(Service Mesh)가 사이드카(Sidecar) 형태로 붙어서, 타임아웃, 재시도, 서킷 브레이커, 트래픽 라우팅 등 모든 결함 허용 전술을 소스 코드의 수정 없이 인프라 레벨에서 투명하게 통제해 주는 시대로 진입했다.
카오스 엔지니어링 (Chaos Engineering): "우리 시스템의 결함 허용 설계가 진짜 작동할까?"를 검증하기 위해, 넷플릭스의 Chaos Monkey처럼 운영 중인 라이브 서버의 코드를 무작위로 뽑아버리거나 네트워크를 끊는(의도적 결함 주입) 자동화 도구를 사용하여 회복 탄력성(Resiliency)을 일상적으로 훈련하는 문화가 DevOps의 핵심으로 자리 잡았다.

참고 표준

Byzantine Fault Tolerance (비잔틴 결함 허용): 시스템 부품이 단순히 죽는 것(Fail-stop)이 아니라, 악의적으로 잘못된 정보(해킹, 노이즈)를 퍼뜨리는 상황에서도 전체 시스템의 올바른 합의를 이끌어내는 결함 허용의 궁극적 수학 이론 (블록체인의 기반).
ISO/IEC 25010: 소프트웨어 품질 모델 중 '신뢰성(Reliability)'의 세부 특성으로 '결함 허용성(Fault Tolerance)'을 명시.

결함 허용은 **"엔지니어의 거만함(내 코드는 완벽해)을 버리는 데서 출발하는 철학"**이다. 아키텍트는 하드웨어는 마모되고, 네트워크는 끊어지며, 디스크는 타버린다는 엔트로피의 법칙(무질서도 증가)을 겸허히 수용해야 한다. 기술사는 하나가 죽으면 다 같이 죽는 위태로운 도미노를 설계하는 대신, 부분이 무너지더라도 주변의 부품들이 그 짐을 기꺼이 나눠지며 시스템이라는 거대한 생명체를 끝끝내 살려내는 '회복 탄력성의 연금술사'가 되어야 한다.

📢 섹션 요약 비유: 결함 허용은 바다 위를 항해하는 거대한 유람선 설계와 같습니다. 배 바닥에 구멍이 나서 물(결함)이 들어오는 것을 아예 안 나게 막을 수는 없지만, 배 밑바닥을 16개의 독립된 격벽(이중화와 격리)으로 나누어 한 칸에 물이 차도 배가 침몰(장애)하지 않고 무사히 항구에 도착하게 만드는 위대한 설계의 승리입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
고가용성 (HA) vs 결함 허용 (FT)	HA는 장애 발생 후 짧은 시간 내에 복구하는 것이고, FT는 장애 자체를 느끼지 못하게 무중단으로 은폐하는 더 상위의 철학.
SPOF (단일 장애점)	결함 허용 설계에서 1순위로 박살 내야 하는 타겟. 시스템을 이중화할 때 놓친 마지막 하나의 공유 자원(예: 전원 공유, L4 장비 1대).
서킷 브레이커 패턴 (Circuit Breaker)	MSA 환경에서 통신 결함을 허용하고 전체 서비스의 연쇄 다운을 막기 위해 차단기를 내리는 우아한 결합 끊기 패턴.
비잔틴 결함 허용 (BFT)	노드가 단순히 꺼지는 게 아니라 미쳐서 가짜 데이터를 뿌리는 최악의 상황에서도, 다수결과 암호학으로 올바른 결과를 도출하는 분산 합의 알고리즘.
카오스 엔지니어링 (Chaos Engineering)	구축해 둔 결함 허용 아키텍처가 실제로 잘 동작하는지, 운영 환경에 일부러 장애를 주입해 면역력을 테스트하는 데브옵스 기법.

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

서커스단에서 외발자전거를 타며 저글링을 하는 광대가 있어요. 갑자기 공 하나를 떨어뜨렸어요!(결함 발생)
만약 광대가 당황해서 외발자전거에서 넘어져 버리면 공연은 실패(장애)예요. 하지만 광대가 웃으면서 남은 공들로 계속 저글링을 이어가면 관객들은 박수를 치죠.
이렇게 중간에 실수가 생기거나 부품이 망가져도, 티 안 나게 스윽 넘어가고 전체 프로그램은 문제없이 계속 돌아가게 만드는 튼튼한 기술을 **'결함 허용 시스템'**이라고 부른답니다!