새벽 4시, PagerDuty가 울리지 않아도 잠에서 깹니다. SRE로 15년을 구르다 보니 이젠 폰 진동이 없어도 환청이 들리거든요. 어제는 Netflix 엔지니어링 슬랙방이 조용하더군요. 트래픽 그래프 한쪽이 뭉텅 잘려 나간 것만 빼면요.
이란(Iran)에서 인터넷이 전면 차단된 지 24시간이 지났습니다.
대부분의 주니어 개발자들은 이걸 '정치 뉴스'로 넘깁니다. 하지만 인프라를 다루는 시니어, 특히 Staff 레벨 이상의 엔지니어라면 등골이 서늘해져야 정상입니다. 이건 단순한 접속 장애가 아닙니다. 우리가 설계한 '가용성(Availability)'이라는 개념의 근본을 흔드는 사건이기 때문입니다.
당신이 자랑하는 99.999% SLA(서비스 수준 협약), 국가 레벨의 셧다운 앞에서도 유효합니까?
1. 라우터 뽑는 것보다 무서운 'BGP 철회'
이란의 인터넷 차단은 누군가 랜선을 가위로 자른 게 아닙니다. 보통 이런 국가 단위 차단은 BGP(Border Gateway Protocol) 경로 철회나 ISP 레벨의 트래픽 블랙홀링(Blackholing)으로 이루어집니다.
쉽게 말해, 인터넷이라는 거대한 지도에서 '이란'이라는 목적지로 가는 길을 지워버린 겁니다. 패킷은 목적지를 잃고 네트워크 어딘가에서 소멸합니다.
넷플릭스나 AWS 같은 글로벌 서비스를 운영하다 보면, 특정 리전(Region)의 트래픽이 0으로 수렴하는 걸 종종 목격합니다. 보통은 해저 케이블 절단이나 데이터센터 전원 이슈죠. 하지만 이번처럼 "국가 단위의 의도적인 고립"은 기술적으로 대응하기 가장 까다로운 시나리오입니다.
왜냐고요? 시스템은 '장애'라고 판단하고 헬스 체크(Health Check)를 실패 처리한 뒤, 트래픽을 다른 리전으로 우회(Failover)시키려 할 겁니다. 하지만 사용자는 물리적으로 접속이 불가능한 상태입니다. 이 과정에서 발생하는 좀비 트래픽과 리소스 낭비, 그리고 엉뚱하게 튀는 알람(Alert)들은 운영팀의 멘탈을 갈아버립니다.
2. 당신의 코드는 '연결 끊김'을 어떻게 처리합니까?
네이버 시절, HDFS 운영할 때 겪었던 일입니다. 네트워크가 불안정할 때 가장 위험한 코드는 '무한 재시도(Retry)' 로직입니다.
이란의 사용자 디바이스에 설치된 당신의 앱을 상상해 보세요. 서버와 연결이 끊겼습니다. 앱은 어떻게 반응합니까?
- 1초마다 재접속을 시도하며 배터리를 광속으로 소모합니까?
- 로컬 캐시에 데이터를 저장하지 않아, 화면이 백지로 나옵니까?
- 타임아웃(Timeout) 설정이 없어서 스레드(Thread)를 다 잡아먹고 먹통이 됩니까?
미국 빅테크들이 '오프라인 퍼스트(Offline-First)' 아키텍처에 집착하는 이유가 여기 있습니다. 연결은 언제든 끊길 수 있다는 전제하에, 끊겨도 최소한의 기능은 작동해야 합니다. 넷플릭스가 오프라인 저장 기능을 그토록 중요하게 여기는 것도 같은 맥락입니다. 인터넷이 없어도, 비행기 안이어도, 혹은 국가가 인터넷을 끊어도, 사용자는 다운로드해 둔 콘텐츠를 볼 수 있어야 하니까요.
그게 사용자 경험(UX)이고, 엔지니어의 실력입니다.
3. 'Availability 0%'의 공포
가용성 99.999%를 'Five Nines'라고 부릅니다. 1년에 허용되는 다운타임이 고작 5분 15초입니다. 이걸 지키기 위해 우리는 수십억을 들여 다중화(Redundancy)를 하고, 카오스 엔지니어링(Chaos Engineering)으로 일부러 서버를 꺼보기도 합니다.
하지만 이란 사례는 'Availability 0%'가 24시간 동안 지속된 겁니다. 이건 기술적 문제가 아니라 불가항력(Force Majeure)의 영역입니다.
문제는 클라이언트(당신의 회사, 혹은 비즈니스 오너)가 이걸 이해하지 못할 때 발생합니다. "왜 접속이 안 돼? 서버 문제 아니야?" 이 질문에 대해 "이란 정부가 막았습니다"라고 증명할 수 있는 모니터링 대시보드가 있습니까? NetBlocks 같은 외부 데이터를 끌어와서라도, 이게 우리 잘못이 아님을 데이터로 보여줘야 합니다.
RCA(Root Cause Analysis) 보고서에 "원인: 국가 검열"이라고 쓸 수 있는 배짱과 근거가 필요하다는 뜻입니다. 억울하게 새벽 3시에 깨서 욕먹지 않으려면요.
4. 엔지니어의 무력감, 그리고 생존
실리콘밸리에서 일하다 보면 가끔 기술만능주의에 빠집니다. 코드로 세상을 바꿀 수 있다는 착각이죠. 하지만 이런 사건을 볼 때마다 무력감을 느낍니다. 물리적인 스위치 하나, 혹은 정치적인 결정 하나에 우리가 쌓아올린 거대한 분산 시스템이 무용지물이 되니까요.
제가 SRE로서 후배들에게 가르치는 건 딱 하나입니다. "시스템은 언제든 죽는다. 중요한 건, 죽었을 때 얼마나 우아하게(Gracefully) 죽느냐다."
당신의 서비스가 네트워크 단절 상황에서 우아하게 죽을 수 있도록 설계하세요. 그리고 당신 자신도 마찬가지입니다. 회사의 시스템을 살리느라 당신의 건강과 삶을 'Fail' 상태로 만들지 마세요. 이란의 인터넷이 끊겨도 지구는 돌고, 넷플릭스 주가는 움직입니다.
지금 당장 퇴근하세요. 그리고 당신의 서버가 아니라, 당신의 저녁 식사 메뉴를 고민하십시오. 그게 진짜 '고가용성' 인생을 사는 방법입니다.
