이중화 (Dual Redundancy)

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

본질: 서버, 네트워크 스위치, 전원 장치, 데이터베이스 등 시스템을 구성하는 핵심 자원(컴포넌트)을 물리적/논리적으로 무조건 2개씩 쌍(Pair)으로 배치하여, 하나의 부품이나 서버가 폭파되더라도 나머지 하나가 즉시 임무를 이어받게 만드는(Fail-over) 생존 아키텍처다.

가치: 시스템 설계 최악의 아킬레스건인 '단일 장애점(SPOF)'을 찢어 타파함으로써, 하드웨어의 피할 수 없는 물리적 죽음(고장) 앞에서도 유저가 느끼는 서비스의 가용성(Availability, Uptime)을 99.99% (Four Nines) 이상으로 기하급수적으로 끌어올리는 가장 가성비 좋고 대중적인 IT 인프라 설계의 1원칙이다.

융합: 단순히 장비 두 대를 옆에 둔다고 끝나는 것이 아니라, 살아있는 두 장비가 1초마다 서로 "너 살아있니?"라고 생사를 확인하는 하트비트(Heartbeat) 통신망과, 죽었을 때 IP 주소나 트래픽을 찰나의 순간에 꺾어버리는 **L4 로드밸런서/OS 스위칭 소프트웨어 기술이 한 몸처럼 융합(Co-design)**되어야만 진정한 무중단 이중화가 완성된다.

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

이중화 (Dual Redundancy)는 IT 인프라 아키텍트들이 "신(God)이 아닌 이상 완벽하게 고장 안 나는 기계는 만들 수 없다"는 현실을 뼈저리게 인정하고 받아들인 처절한 방어 본능의 결과물이다.

1대의 완벽하고 비싼 서버(1억 원짜리)를 샀다. 그런데 이 서버의 파워 코드를 청소기 돌리던 아주머니가 실수로 툭 뽑아버렸다. 1억 원짜리 장비고 뭐고, 그 순간 회사 쇼핑몰이 다운되고 1시간 동안 매출 수천만 원이 허공으로 날아갔다.

엔지니어들은 깨달았다. "기계 하나를 아무리 티타늄으로 단단하게(MTBF 상승) 만들어봐야, 외부 요인 한 방에 죽는 건 똑같다. 차라리 1,000만 원짜리 싸구려 서버 2대를 사자! 그리고 두 대를 나란히 두고, 1번 서버가 죽는 그 0.1초의 찰나에 2번 서버가 똑같은 얼굴을 하고 손님(트래픽)을 맞이하게 속이자!"

[비싼 단일 서버(SPOF) vs 값싼 이중화(Redundancy) 아키텍처의 생존율 퀀텀 점프]

* 상황: 각 서버의 고장(다운) 확률이 1년에 10% 라고 가정.

(A) 단일 서버 구축 (SPOF 존재)
- 서비스가 죽을 확률: 10% (10일에 한 번꼴로 불안에 떨어야 함)
- 가용성: 90% (최악의 시스템)

(B) 이중화 구축 (Dual Redundancy)
- 두 대의 서버가 "동시에" 고장 날 확률: 10% x 10% = 1% !!
- 가용성: 99% (갑자기 훌륭한 시스템으로 탈바꿈)

=> 만약 서버를 3대(삼중화)로 묶으면? 10% x 10% x 10% = 0.1% 고장률. 
   즉, **이중화는 부품의 질을 올리지 않고도 시스템 전체의 생존율을 지수 함수(Exponential)로 
   뻥튀기시키는 가장 마법 같은, 그러나 가장 확실한 아키텍처 토목 공사다.**

📢 섹션 요약 비유: 이중화는 비행기의 엔진을 설계하는 방식입니다. 비행기 엔진 1개를 절대 고장 안 나게 다이아몬드로 깎아 만들어도, 새가 날아와서 부딪히면(버드 스트라이크) 엔진이 깨지고 수백 명이 추락해 죽습니다. 그래서 현대 여객기는 약간 싼 엔진을 굳이 양쪽 날개에 2개씩 달아놓습니다. 엔진 1개가 불타더라도, 나머지 1개의 엔진만으로 무조건 가장 가까운 공항까지 날아가서 수백 명의 목숨을 100% 살려낼 수 있기 때문입니다.

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

이중화 아키텍처가 "실제로 어떻게 작동하는가"를 결정짓는 것은 두 대의 장비가 평소에 서로 어떤 눈치 게임을 하고 있느냐(Active 상태 여부)에 따라 크게 두 가지 철학으로 갈라진다.

이중화 모드 (Redundancy Mode)	아키텍처적 동작 메커니즘	극복 과제 및 하드웨어 융합 트레이드오프	비유
Active-Standby (수동적 대기)	메인(A)이 평소 100% 일하고, 예비(S)는 전기만 먹으며 멍때림. 메인이 죽으면(Fail), 헬스체크가 끊김을 인지한 예비가 "내가 대장이다!"며 수 초의 딜레이를 거쳐 IP를 뺏고(Take-over) 깨어남.	대기가 깨어나는 시간 동안 수 초~분 단위의 서비스 지연(Downtime 렉) 허용됨. 데이터 꼬일 일은 없어서 DB 마스터/스위치에 주로 융합 사용.	주간 알바가 일할 때, 야간 알바는 뒤에서 스마트폰 보며 놀고 있다가 주간 알바가 쓰러지면 허둥지둥 옷 갈아입고 계산대 투입됨.
Active-Active (양방향 돌격)	두 대(A1, A2)가 평소에 50:50으로 일을 나눠서 100% 풀가동 뜀. 한 대가 죽으면 남은 한 대가 즉시 100%의 트래픽을 혼자 다 받아서 처리함.	죽었을 때 전환 지연시간(0초)이 아예 없음. 단, 평소 두 서버 간의 완벽한 데이터 동기화(Sync) 코딩과 무상태(Stateless) 세팅이 안 돼 있으면 시스템 붕괴됨.	두 명의 알바가 동시에 계산대 2곳에서 손님을 쳐내다가, 한 명이 화장실 가면 남은 한 명이 미친 듯이 손님 2줄을 다 쳐냄. 렉 0초.

이 이중화 아키텍처가 찰나의 순간에 마법처럼 작동하려면, 하드웨어 밑바닥에서 심장 박동을 체크하는 '하트비트 (Heartbeat)' 통신망 융합이 필수다.

[소프트웨어와 하드웨어가 융합된 L4/L7 로드밸런서의 페일오버(Fail-over) 프랙탈]

[ 로드 밸런서 (VIP: 10.0.0.1) ]  <--- 유저는 이 주소 1개만 알고 접속함.
     │ (1초마다 "너 살아있니?" 하트비트 핑 발사!)
     ├─> [ Active 웹서버 1 ] "네 저 살아있어요! (200 OK)"
     └─> [ Standby 웹서버 2 ] "저 놀고 있어요!"

(재앙 발생: 웹서버 1의 CPU 쿨러가 타서 보드가 녹아버림)
1. 로드 밸런서: "어? 웹서버 1번아? 핑 대답이 3번 연속 없네?" (장애 인지, Time To Detect)
2. 로드 밸런서: "웹서버 1번 넌 즉시 격리(Isolation)! 버린다!"
3. 로드 밸런서: "웹서버 2번아! 지금부터 네가 Active다. 모든 유저 트래픽 너한테 쏜다!" (라우팅 스위칭 완료)

=> 아키텍처 결과: 하드웨어 1대가 통째로 숯덩이가 되었지만, 유저는 잠깐 1초 모래시계(로딩)가 돈 뒤에 
   평소처럼 똑같은 웹페이지(서버 2번이 제공)를 보게 된다. 물리적 죽음을 S/W 라우팅으로 완벽히 은닉(Hiding)했다.

📢 섹션 요약 비유: 이중화의 하트비트(Heartbeat)는 잠수부(서버) 2명을 물속에 넣고, 밖에서 줄(네트워크 핑)을 1초마다 당겨서 "살아있냐?"고 묻는 겁니다. 1번 잠수부가 줄을 당겨주지 않으면, 밖의 대장(로드밸런서)은 가차 없이 1번 줄을 잘라버리고, 모든 구조 작업 지시(트래픽)를 살아있는 2번 잠수부에게만 몰아주는 피도 눈물도 없는 생존 시스템입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

진정한 이중화는 단순히 서버 컴퓨터 2대를 사는 것으로 끝나지 않는다. 폰 노이만 아키텍처를 이루는 모든 물리적 골격(전원, 네트워크, 디스크)을 계층별로 갈기갈기 찢어놔야 비로소 가용성(Availability)이 달성된다.

인프라 전 계층(Full-Stack)의 물리/논리적 이중화 융합 해부

인프라 계층	단일 장애점(SPOF) 지뢰	물리적 / 소프트웨어적 이중화(Redundancy) 융합 처방	생존의 댓가 (CAPEX)
전력망 (Power)	서버 전원 코드를 1개만 꽂아둠 (멀티탭 터지면 끝)	서버 섀시에 듀얼 파워 서플라이 탑재 + 한쪽은 한전(A-feed), 한쪽은 UPS/발전기(B-feed) 물리적 콘센트 분리	가장 싸지만 가장 확실한 서버 생명 보험
네트워크 (Network)	서버에 랜선(NIC) 1개만 꽂아둠 (스위치 1개 죽으면 끝)	랜카드 2개 포트에 각각 다른 L2 스위치를 물리고, 리눅스 OS 레벨에서 본딩(Bonding/Teaming) S/W 묶음 처리	케이블 절단 및 스위치 재부팅 100% 내성
스토리지 (Disk)	HDD 1개에 OS와 DB를 다 깔아둠	RAID 1 (미러링) 하드웨어 컨트롤러 탑재로 두 디스크에 똑같은 데이터 동시 쓰기 강제	디스크가 물리적으로 박살 나도 데이터 0% 유실 보장
데이터센터 (Facility)	이중화 다 해놨는데 그 서버들이 다 한 건물(IDC)에 있음	Multi-AZ (가용 영역 분산). 서울과 일산 등 지진 단층이 다른 두 건물에 서버를 찢어놓고 GSLB(DNS)로 묶음	비용 수 배 폭발. 최상위 엔터프라이즈의 종착역

타 과목 관점의 융합 시너지

데이터베이스 아키텍처 (Replication과 Split-Brain 딜레마): 데이터베이스 마스터 서버를 Active-Standby로 이중화했다. 1번 마스터에 데이터를 쓰고 2번 마스터에 실시간 복제(Replication)를 한다. 그런데 두 DB를 연결하는 랜선이 툭 끊겼다. 1번 DB는 살아있는데 2번 DB가 보기엔 1번이 죽은 줄 알고 "내가 새 마스터다(Take-over)!"라고 선언한다. 한 네트워크 안에 데이터를 쓰는 마스터가 2명이 되어 데이터가 개박살 나는 이 현상을 **'스플릿 브레인(Split-Brain)'**이라 한다. 이를 막기 위해 데이터베이스 이중화를 할 때는 무조건 2대가 아니라, 감시자(Arbiter/Sentinel)를 추가한 3대(홀수)를 두어 다수결 투표(Quorum)로 마스터를 정하는 분산 합의 알고리즘(Raft 융합)이 절대 법칙으로 굳어졌다.
클라우드와 MSA (Stateless 무상태성 융합): Active-Active로 서버 2대를 띄웠는데, 유저가 1번 서버에 로그인(Session 저장)했다. 다음 클릭 때 로드밸런서가 2번 서버로 트래픽을 던지면, 2번 서버는 "너 누구야?"라며 로그아웃시켜 버린다(이중화의 역효과). 이중화 아키텍처가 빛을 발하려면, 백엔드 애플리케이션 코드를 무조건 서버 로컬에 상태를 저장하지 않는 무상태(Stateless) 로 짜야 한다. 로그인 상태는 서버 밖의 외부 Redis(공용 캐시)에 던져(오프로딩) 두고, 서버 1, 2번은 뇌가 텅 빈 깡통으로 만들어 놔야 로드밸런서가 트래픽을 아무 데나 미친 듯이 섞어 던져도 완벽하게 융합 작동한다.

[이중화 아키텍처의 배신: 스플릿 브레인(Split-Brain) 재앙 융합 도식]

[ 마스터 DB (Active) ] <---- (하트비트 랜선 끊어짐!) ----> [ 대기 DB (Standby) ]
        │                                                     │
유저 A "1만원 입금해!"                                    유저 B "아니야, 5만원 입금해!"

* 끔찍한 사태:
대기 DB는 하트비트가 끊기자 마스터가 죽은 줄 알고 스스로 마스터(Active)로 승격함!
이제 한 시스템에 마스터가 2명이 됨.
유저 A의 데이터는 왼쪽 DB에, 유저 B의 데이터는 오른쪽 DB에 각각 다르게 쓰임.
나중에 랜선을 다시 연결해도 이 찢어진 데이터는 수학적으로 복구 불가능함. (DB 엔지니어 퇴사 사유 1순위)

=> 융합적 파훼법: 이중화(2대)의 역설. DB는 절대 짝수로(2대) 이중화하지 마라. 
   반드시 투표할 수 있는 홀수(3대) 쿼럼(Quorum) 클러스터를 만들어야 살 수 있다.

📢 섹션 요약 비유: 이중화(Active-Standby)는 여객기 조종석에 기장과 부기장 2명이 앉아있는 겁니다. 기장(마스터)이 심장마비로 쓰러지면 부기장이 조종간을 잡으면 완벽하죠. 그런데 만약 둘 사이의 무전기(하트비트 랜선)가 끊어졌을 때, 조수석의 부기장이 '기장이 죽었나?' 착각하고 자기도 조종간(마스터 권한)을 잡고 왼쪽으로 꺾고, 살아있는 기장은 오른쪽으로 꺾으면 비행기는 반으로 찢어집니다(스플릿 브레인). 완벽한 이중화는 장비를 두 대 두는 게 아니라, 두 장비가 미치지 않게 통제하는 중재자(소프트웨어)를 두는 것입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 신입 인프라 엔지니어들이 가장 많이 하는 멍청한 짓은 "서버 2대 사서 로드밸런서 밑에 묶어 놨으니 가용성 100%야!"라며 안심하다가, 똑같은 패치 스크립트를 두 대에 동시에 날려서 두 대가 사이좋게 한 번에 죽는 대형 사고를 치는 것이다.

실무 무중단 인프라 설계 및 SPOF 척결 시나리오

배포 시 이중화 장비 동시 사망 방어 (Canary / Rolling Update)
- 상황: Active-Active로 돌아가는 웹서버 2대에, 개발팀이 짜준 신규 소스 코드를 새벽에 동시에 배포(Restart)함. 그런데 코드에 메모리 누수(Memory Leak) 치명적 버그가 있어서 서버 2대가 부팅되자마자 1분 만에 동시 사망(OOM)함.
- 의사결정: 아무리 물리적 서버를 2대 100대로 이중화해 놔도, '똑같은 버그가 있는 소프트웨어'를 동시에 깔면 논리적 단일 장애점(SPOF)이 터져 다 같이 죽는다. 배포 파이프라인을 뜯어고쳐, 서버 1대(카나리, Canary)에만 먼저 코드를 배포하고 10분간 에러율(500 Error)을 지켜본 뒤, 살아서 멀쩡할 때만 나머지 서버(B)에 배포하는 롤링 업데이트 아키텍처를 시스템화한다.
- 이유: 하드웨어 이중화는 번개나 단전 같은 '물리적 공격'은 막아주지만, 관리자가 던지는 '논리적 자폭 버튼(버그)'은 절대 막아주지 못한다. 진정한 이중화는 쇳덩어리(H/W)를 나누는 것을 넘어, 시간과 버전(S/W)의 축까지 찢어놓는 철저한 편집증이어야 한다.
클라우드 데이터베이스 이중화 비용 최적화 (Read Replica 융합)
- 상황: 회사 트래픽이 늘어 DB 마스터 1대가 CPU 100%를 치고 허덕임. 사장님이 "DB도 웹서버처럼 이중화(Active-Active)해서 트래픽 반반 쪼개 쓰게 해!"라고 무식한 지시를 내림.
- 의사결정: RDBMS(관계형 DB)에서 쓰기(Write) 마스터를 2대 두는 멀티 마스터(Active-Active) 구성은 극강의 동기화 락(Lock) 병목 때문에 불가능하다고 거절한다. 대신 기존 마스터는 쓰기(Write/Active)만 전담하게 두고, 데이터를 실시간 동기화받는 읽기 전용 복제본(Read Replica / Standby) 서버 2대를 옆에 증설하여 읽기 트래픽만 70% 떼어내어 분산(Off-loading)시킨다.
- 이유: 실무 백엔드 트래픽의 90%는 단순 읽기(Read)다. 마스터 1대에 모든 짐을 지우지 않고 읽기 부하를 Standby 장비로 돌려버리면, 평소에 놀고먹던 Standby 장비의 낭비(CAPEX)를 극한으로 뽑아먹으면서도 트래픽을 방어할 수 있다. 만약 마스터가 죽어도 읽기 서버 중 하나를 1초 만에 마스터로 승격(Fail-over)시키면 되므로, 성능과 가용성(A) 두 마리 토끼를 다 잡는 DB 튜닝의 황금률이다.

[실무 클라우드 인프라 아키텍처 이중화(Redundancy) 자체 감사 트리]

[현상] 서버 아키텍처 도면을 펼쳐놓고 "여기에 폭탄이 떨어지면 서비스가 죽나?" 검사 시작.
 ├─ EC2(서버) 2대가 똑같이 [가용영역(AZ) A] 라는 1개의 건물 안에 몰려 있는가?
 │   ├─ Yes ──> (가짜 이중화) 가용영역 A 건물이 정전되면 서버 2대가 사이좋게 같이 죽는다! 
 │   │          당장 1대를 [가용영역 B] (수십 km 떨어진 다른 건물) 로 이사 시켜라 (Multi-AZ 강제).
 │   │
 │   └─ No ───> [질문 2] 앞단 로드밸런서(ALB)는 2개 존에 잘 뿌려주는데, 
 │                       정작 2대의 서버가 1개의 멍청한 [단일 공유 EFS(디스크)] 물고 있는가?
 │               ├─ Yes ──> 디스크가 죽으면 서버 2대가 같이 커널 패닉에 빠짐 (SPOF 지뢰).
 │               │          스토리지를 S3 같은 분산 객체 저장소로 찢어발기거나 DB로 짬처리해라.
 │               └─ No ───> 완벽하다. 진정한 의미의 Full-Stack 무중단 이중화 완성.

운영 및 아키텍처 도입 체크리스트

스위치 장비 2대를 이중화(Active-Standby) 구성할 때, 1번 장비에 꽂힌 랜선이 실수로 뽑혔을 때 2번 스위치가 즉각 자기가 대장 IP(VIP)를 가로채는 ARP/VRRP 절체 스크립트 모의훈련(Chaos Test)을 새벽 점검 시간에 전원 플러그를 뽑아보며 실전 증명했는가?

안티패턴: "우와 이 서버는 디스크를 RAID 1로 이중화(미러링)해 놨으니까 데이터 절대 안 날아가! 백업 안 해도 돼!"라고 맹신하는 멍청한 신입. RAID 미러링 하드웨어 이중화는 "디스크 1개가 물리적으로 불탔을 때" 막아주는 방패다. 만약 개발자가 실수로 DROP TABLE (데이터 통째로 삭제) 쿼리를 날리면, RAID 컨트롤러는 너무나 성실하게 0.1초 만에 1번 디스크와 2번 이중화 디스크 양쪽에 있는 데이터를 '동시에 똑같이 완벽하게 삭제'해 버린다. 하드웨어 이중화는 사람의 실수(논리적 삭제)를 막아주지 못하므로 오프라인 백업(Snapshot)은 무조건 따로 가야 한다.

📢 섹션 요약 비유: 이중화(Redundancy) 장비는 나를 지켜주는 쌍둥이 보디가드입니다. 내가 총을 맞을 때 1명이 방패가 되어주면 다른 1명이 나를 호위하죠(물리적 방어). 하지만 내가 독약이 든 물(소프트웨어 악성 쿼리나 버그 패치)을 마시려고 할 때, 두 보디가드는 내가 마시는 걸 멍하니 구경하며 자기들도 같이 독약을 마시고 쓰러집니다. 진정한 생존은 쌍둥이 보디가드 옆에 1시간 전 내 건강한 상태로 시간을 되돌리는 타임머신(오프라인 백업)을 같이 두는 것입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

이중화(Dual Redundancy) 아키텍처는 "단일 거인의 무결점"을 포기하고 "수많은 평범한 자들의 협력과 교대"를 선택함으로써, 클라우드라는 광활한 싸구려 인프라 위에서 절대 멈추지 않는 글로벌 IT 제국을 건설한 철학적 뼈대다.

패러다임 극복 과제	단일 메인프레임 맹신 (SPOF 방치) 시대	클라우드 분산 이중화/다중화 융합 시대	현대 디지털 생태계 파급 효과
장비 도입 원가(CAPEX)	죽지 않는 슈퍼컴 1대 구입에 수십억 탕진	100만 원짜리 상용 PC 2대 묶어서 퉁침	스타트업도 대기업급의 99.99% 무중단 서비스 인프라 구축 가능 (민주화)
재해 복구 (DR) 속도	서버 터지면 부품 가져올 때까지 12시간 셧다운	액티브-스탠바이 핑퐁으로 1초 만에 유저 몰래 복구 완료	쿠팡, 넷플릭스가 지구 반대편 데이터센터가 타도 1분 안에 서비스를 살려내는 기적

미래 전망: 장비 두 대를 놓고 하나가 죽으면 넘겨받는 전통적인 이중화(Active-Standby) 시대는 점차 막을 내리고 있다. 마이크로서비스(MSA)와 쿠버네티스의 지배력이 커짐에 따라, 미래의 아키텍처는 2개로 쪼개는 이중화가 아니라 수백 개의 아주 작은 컨테이너(Pod)가 벌떼처럼 얽혀 일하는 극단적 다중화(Massive Active-Active Micro-Redundancy) 로 융합 진화하고 있다. 1,000개의 뇌세포 중 10개가 무작위로 죽고 새로 태어나기를 1초 단위로 반복하며, 시스템의 죽음과 탄생이 하나의 유기체처럼 멈춤 없이 순환하는 진정한 소프트웨어 정의 자가 치유(Software-Defined Self-Healing) 면역계가 다가올 컴퓨팅의 완성형이다.

📢 섹션 요약 비유: 이중화의 역사는 진화론과 같습니다. 옛날 공룡(단일 메인프레임)은 몸집 하나를 엄청나게 키웠지만 운석(장애) 한 방에 멸종했습니다. 그래서 인류는 조종사 2명이 모는 비행기(이중화)를 만들었죠. 이제 미래의 컴퓨터는 거대한 벌떼(컨테이너 다중화)로 진화했습니다. 빗자루(장애)를 휘둘러 벌 10마리를 쳐 죽여도, 남은 990마리의 벌떼가 아무 일 없다는 듯 대열을 유지하며 목적지로 끊임없이 날아가는 완벽한 군집 지능의 시대가 도래했습니다.

📌 관련 개념 맵 (Knowledge Graph)

단일 장애점 (SPOF) | 이중화(Redundancy) 아키텍처가 목숨을 걸고 찾아내서 찢어 발겨 죽여야 할 단 하나의 공공의 적. 이 1개가 죽으면 100만 대의 이중화 서버가 다 같이 멈추는 급소
가용성 (Availability) | 이중화 기술을 서버에 도배하는 궁극적인 목적. 유저가 사이트를 접속했을 때 에러 창을 보지 않고 정상적인 화면을 볼 확률(Five Nines 등)
로드밸런싱 (Load Balancing) / 페일오버(Fail-over) | 이중화의 꽃. 물리적으로 서버 두 대를 샀다고 이중화가 아니라, 1대가 죽었을 때 0.1초 만에 앞단의 라우터가 트래픽 물길을 강제로 살아있는 서버로 꺾어주는 이 소프트웨어 마법이 이중화의 진짜 본체임
스플릿 브레인 (Split-Brain) | 두 대의 데이터베이스를 이중화해 놨더니, 둘 사이의 랜선이 끊기자 서로 자기가 왕(Active)이라며 다른 데이터를 덮어써서 DB가 영원히 복구 불가능하게 파괴되는 최악의 부작용
Active-Active vs Active-Standby | 이중화된 2대의 서버를 평소에 둘 다 일하게 시킬지(돈 낭비 0, 렉 0초, 세팅 지옥), 한 명은 멍때리고 쉬다가 터지면 깨울지(돈 낭비 50%, 렉 발생, 세팅 쉬움) 결정하는 아키텍트의 영원한 가성비 딜레마

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

개념: 이중화는 정말 중요한 연극 공연을 할 때, 주인공 역할을 맡은 배우(서버)가 혹시 배탈이 나서 쓰러질까 봐 완벽하게 대사를 똑같이 외운 '쌍둥이 대역 배우'를 항상 커튼 뒤에 서 있게 하는 작전이에요.
원리: 주인공 배우가 무대에서 갑자기 쓰러지는 순간(고장), 감독님(소프트웨어)이 1초 만에 조명을 끄고 커튼 뒤에 있던 쌍둥이 대역 배우를 무대 위로 팍 밀어 넣어서 연기를 그대로 이어가게 만들죠.
효과: 관객(사용자)들은 눈 깜짝할 새 일어난 일이라 주인공이 바뀐 줄도 전혀 모르고 재밌게 연극을 끝까지 볼 수 있기 때문에, 어떠한 사고가 나도 연극(인터넷 서비스)이 절대 멈추지 않는 마법을 부린답니다.