나는 왜 이중화에 집착하는가 — 데이터와 가용성에 대한 인프라 구성 철학

Posted Apr 8, 2026

By noah 18 min read

들어가며 — 어떤 인프라 엔지니어의 직업병

인프라를 오래 다루다 보면 각자 유난히 신경 쓰는 지점이 생긴다. 누군가는 비용, 누군가는 보안, 누군가는 배포 속도. 나에게 그건 이중화(redundancy)다. 구성도를 그릴 때 나도 모르게 가장 먼저 던지는 질문은 늘 같다.

“이 컴포넌트 하나가 지금 죽으면, 서비스는 계속 살아있는가?”

이건 취향이 아니라 일종의 직업병에 가깝다. 그리고 이 직업병에는 나름의 내력이 있다. 이 글에서는 내가 왜 이중화에 이렇게까지 집착하게 됐는지를 먼저 이야기하고, 그 철학이 실제 아키텍처 설계에 어떻게 녹아드는지를 최근 작성했던 AWS 구성안을 예로 풀어보려 한다.

1. 데이터의 무게를 배운 시간 — AI 석사 시절

내 커리어의 출발점은 인프라가 아니라 데이터였다. AI 대학원에서 NLP를 전공하며, 나는 데이터라는 것이 얼마나 예민하고 또 얼마나 값진 자산인지를 몸으로 배웠다.

모델은 다시 학습시키면 된다. 코드는 다시 짜면 된다. 그러나 데이터는 한 번 잃으면 되돌아오지 않는다. 몇 주에 걸쳐 정제한 코퍼스가 한순간에 날아가는 경험, 전처리 파이프라인의 사소한 실수로 원본이 오염되는 경험 — 이런 것들이 쌓이면서 나에게는 한 가지 원칙이 새겨졌다.

“복원 불가능한 것은, 반드시 여러 벌 존재해야 한다.”

이게 훗날 내가 인프라를 바라보는 렌즈의 원형이 됐다. 이중화란 결국 “복원 불가능한 상태를 만들지 않겠다”는 태도의 기술적 구현이니까.

2. 데이터를 직접 다룬 현장 — 가이온

대학원에서 배운 원칙은 가이온에서 실무가 됐다. 무역 데이터 플랫폼의 인프라를 담당하며, 나는 처음으로 “남의 데이터”가 아니라 “서비스의 데이터”를 책임지는 자리에 섰다.

데이터를 직접 관리하는 위치에 서보면, 대학원 때의 원칙이 훨씬 더 무겁게 다가온다. 내 실수 하나가 곧 서비스의 데이터 정합성 문제로 직결되기 때문이다. 이 시기에 나는 자연스럽게 습관 하나를 들이게 됐다. 무엇을 구성하든 “이게 죽으면?”을 먼저 떠올리는 것. 스토리지도, DB도, 파이프라인도 — 단일 지점(Single Point of Failure)을 남겨두면 마음이 불편해지는, 그런 감각이 이때 자리 잡았다.

3. 이중화의 대가를 목격하다 — 키즈노트, 그리고 2022년 10월

이 철학이 “신념” 수준으로 굳어진 건 키즈노트 입사 무렵이었다. 키즈노트는 카카오 계열의 SaaS 서비스였고, 카카오의 IDC 환경 위에서 운영됐다.

그리고 내가 입사하던 시점은, 하필 2022년 10월 판교 SK C&C 데이터센터 화재 직후였다.

기억하는 분들이 많을 것이다. 2022년 10월 15일 오후, 판교 SK C&C 데이터센터 지하에서 불이 났고, 그 여파로 카카오톡을 비롯한 카카오의 거의 모든 서비스가 멈췄다. 전 국민이 메신저 없이 주말을 보내야 했던, 그 사건이다.

당시 나에게 이 사건은 뉴스 속 남의 일이 아니었다. 막 몸담게 된 조직이 발 딛고 선 인프라 환경에서 벌어진 일이었기 때문이다. 입사 직후의 회사 분위기는, 서버 이중화와 재해 복구(DR)의 중요성을 조직 전체가 뼈저리게 되새기는 시기였다. 신입에게 이보다 강렬한 교육 자료는 없었다.

무엇보다 인상 깊었던 건, 이후 정부 합동조사에서 밝혀진 복구 지연의 원인이었다. 화재 자체는 SK C&C의 설비 문제였지만, 복구가 그토록 오래 걸린 데에는 “이중화가 미완성 상태였다”는 점이 크게 작용했다. 핵심 기능이 한 곳에 밀집돼 있었고, 다른 센터로 넘어가는 전환이 매끄럽지 못했다.

이중화는 “만들어 두는 것”이 아니라 “실제로 넘어가는지 검증해 두는 것”이다. 종이 위의 이중화는 이중화가 아니다.

이 사건은 내 안의 원칙을 하나 더 정교하게 다듬어줬다. 단순히 “여러 벌 존재하게” 하는 걸 넘어서, “장애 시 실제로, 자동으로, 빠르게 전환되는가”까지가 이중화의 완성이라는 것.

4. 철학을 아키텍처로 — AWS 구성 예시

이 세 시기를 거치며 벼려진 원칙을, 나는 최근 한 AWS 아키텍처 구성안에 그대로 담아봤다. 서비스의 정확한 성격이 명확하지 않은 상황을 가정하고, 범용적인 VM 기반 WEB/WAS/DB 3-tier 구조를 안정성 중심으로 설계한 것이다.

핵심 설계 의도는 하나다. “어느 한 층에서도 단일 지점 장애를 남기지 않는다.”

4-1. 전체 트래픽 흐름

그림 1. 모든 계층을 Multi-AZ로 이중화한 WEB/WAS/DB 3-tier 구성

4-2. 계층별 이중화 설계

각 계층을 “이게 죽으면?”의 관점에서 뜯어보면 이렇다.

계층	구성	“이게 죽으면?”에 대한 답
진입점	Route53 → CloudFront + WAF	CDN이 오리진 부하를 흡수, WAF가 공격 트래픽 사전 차단
부하 분산	ALB (Public / Internal) 모두 Multi-AZ	LB 자체가 여러 AZ에 걸쳐 있어 단일 AZ 장애에도 분산 지속
WEB	Auto Scaling Group, AZ-A/B 분산	한 AZ의 WEB이 전멸해도 다른 AZ가 트래픽 수용, ASG가 자동 재생성
WAS	Auto Scaling Group, AZ-A/B 분산	내부 ALB가 살아있는 AZ로만 라우팅, 부하 증가 시 자동 확장
캐시	Redis Multi-AZ	캐시 노드 장애 시에도 페일오버, DB 부하 급증 방지
DB	RDS Multi-AZ (Primary/Standby)	Primary 장애 시 Standby로 자동 페일오버

여기서 내가 특히 신경 쓴 지점은 두 가지다.

첫째, 외부 트래픽과 내부 트래픽의 분리. WEB과 WAS 사이에 Internal ALB를 한 번 더 두어, WAS 계층이 외부에 직접 노출되지 않도록 했다. 이건 보안이자 동시에 이중화다. WAS를 Private Subnet 안쪽에 두면, 외부 공격면(attack surface)이 줄어드는 동시에 내부 부하 분산 지점이 하나 더 생긴다.

둘째, DB 계층의 자동 페일오버. 앞서 키즈노트에서 배운 교훈 — “종이 위의 이중화는 이중화가 아니다” — 이 그대로 반영된 부분이다. RDS Multi-AZ는 단순히 Standby를 하나 더 두는 게 아니라, Primary가 죽으면 자동으로 Standby가 승격된다. 사람이 개입해서 수동 전환하는 구조였다면, 판교 화재 때처럼 “전환이 매끄럽지 못한” 상황을 반복할 수 있다.

4-3. VPC 네트워크 분리

VPC
├── Public Subnet
│   ├── ALB (Public)
│   ├── NAT Gateway
│   └── Bastion Host
└── Private Subnet
    ├── WEB EC2
    ├── Internal ALB
    ├── WAS EC2
    ├── Redis
    └── RDS

Public에는 외부와 직접 맞닿아야 하는 것들(진입 LB, NAT, 접속 관문)만 두고, 실제 애플리케이션과 데이터는 전부 Private Subnet 안쪽으로 넣었다. 서버 접근도 직접 SSH를 막고 Bastion Host나 SSM Session Manager를 통해서만 들어가도록 통제한다.

5. 한계를 인정하는 것도 설계의 일부 — Multi-Region

정직하게 짚고 넘어갈 부분이 있다. 위 구성은 동일 리전 내 Multi-AZ다. 즉 AZ 하나가 통째로 죽어도 버티지만, 리전 전체가 내려가면 답이 없다.

아이러니하게도, 판교 화재가 나에게 가르쳐준 게 바로 이 지점이다. AZ 이중화만으로는 “데이터센터 단위 재해”를 온전히 막지 못할 수 있다. 그래서 더 높은 가용성이 필요하다면 Multi-Region 구성 + DNS 기반 Failover를 추가로 고려해야 한다.

다만 여기엔 반드시 따라오는 숙제가 있다. 데이터 정합성이다.

Multi-AZ 환경은 같은 리전 내라 동기 복제가 가능하다. 데이터가 항상 동일하게 유지된다.
반면 Multi-Region은 리전 간 물리적 거리 때문에 비동기 복제가 되는 경우가 많다. 복제 지연으로 리전 간 데이터가 순간적으로 어긋날 수 있다.

그래서 현실적인 절충안은 이렇다. 특정 리전을 Primary로 두어 쓰기는 한 곳에서만 하고, 나머지 리전은 읽기 위주로 운영하는 것. 그리고 Failover 시 일부 데이터 유실 가능성을 인정하고, 그에 대한 대응(복구 지점 목표, RPO 설정 등)을 미리 정해두는 것.

완벽한 이중화는 없다. 중요한 건 “어디까지 감당할 수 있는 장애인가”를 명시적으로 정하고, 그 경계를 스스로 아는 것이다. 데이터의 무게를 아는 사람만이 이 트레이드오프를 정직하게 마주할 수 있다고 믿는다.

6. NCP 경험자가 본 AWS

내 주 무대는 사실 NCP였다. 그래서 이 구성안을 짜면서 자연스럽게 두 클라우드를 비교하게 됐다.

기본적인 인프라 구성의 결은 NCP나 AWS나 크게 다르지 않다. VPC, 서브넷, LB, Auto Scaling, 관리형 DB — 개념은 상통한다. 다만 이중화·가용성 관점에서 AWS가 주는 이점은 분명히 있다.

글로벌 리전·AZ의 폭. 전 세계에 촘촘한 리전과 AZ가 있어, 글로벌 서비스 확장이나 Multi-Region DR을 그릴 때 선택지가 넓다.
관리형 서비스의 성숙도. RDS Multi-AZ 자동 페일오버, S3의 내구성처럼, 이중화를 “직접 구축”하지 않고 “가져다 쓰는” 폭이 넓다. 인프라 엔지니어가 신경 쓸 단일 지점이 그만큼 줄어든다.
생태계의 다양성. 요구사항에 맞춰 조립할 수 있는 블록이 많다.

물론 국내 중심 서비스라면 NCP도 충분히 훌륭한 선택이다. 데이터 주권, 국내 망 지연, 지원 체계 측면에서 오히려 유리한 지점도 있다. 결국 “글로벌 확장성과 서비스 다양성이 중요한가, 국내 최적화가 중요한가”의 문제라고 본다.

마치며

돌아보면 나의 이중화 집착은 세 개의 장면으로 이뤄져 있다.

AI 석사 — 데이터는 잃으면 끝이라는 걸 배운 곳
가이온 — 그 데이터를 직접 책임지며 SPOF 감각을 체화한 곳
키즈노트 & 판교 화재 — 이중화의 부재가 어떤 대가를 치르는지 목격한 곳

그래서 나는 지금도 구성도를 그릴 때마다 같은 질문을 던진다. “이게 죽으면, 서비스는 살아있는가?” 그리고 그 질문에 자신 있게 “네”라고 답할 수 있을 때까지, 계층 하나하나에 두 번째 벌을 마련한다.

인프라 엔지니어의 일이란, 어쩌면 “최악의 순간에 아무 일도 일어나지 않게 하는 것”인지도 모른다. 잘 만든 이중화는 티가 안 난다. 티가 안 나도록 만드는 것, 그게 내가 이 일에서 지키고 싶은 원칙이다.

이 글의 AWS 구성안은 한 기술 과제로 작성했던 아키텍처를 기반으로, 개인적인 인프라 철학을 덧붙여 재구성한 것이다. 특정 회사의 실제 운영 구성과는 무관하다.

운영 이모저모, 인프라

This post is licensed under CC BY 4.0 by the author.