복구, 그리고 0.001%

11:47 KST — 그레이노드 사무실

클라이언트 미팅 중에 세진의 폰이 진동했다. 회의실 테이블 위에서 살짝 밀려났다. 화면을 힐끗 봤다. @TeamYouTube.

미팅이 끝나고 세진은 자리로 돌아와서 트윗을 열었다.

두 문장. "문제를 찾아 수정했습니다. 앱이나 브라우저를 재시작하면 정상화될 수 있습니다."

첫 번째 트윗에는 원인에 대한 언급이 없다. "뭐가 고장났는지"에 대해 한 마디도 없다. 찾았고, 고쳤다. 그것뿐이다. 하지만 세진은 알고 있다 — 구글은 대형 장애 후에 추가 성명을 내는 경우가 많다.

세진은 유튜브를 새로고침했다.

전부 200. 피드가 돌아왔다. 홈 화면에 영상 썸네일이 늘어선다. 구독 채널의 새 영상이 보인다. Shorts가 스크롤된다. 아침에 보려던 Computerphile 영상이 구독 피드 상단에 올라와 있다.

"문제가 발생했습니다"가 사라졌다.

장애 발생 09:45. 복구 확인 11:47. 약 2시간. DownDetector의 그래프는 가파르게 떨어지기 시작했다. 28만의 봉우리가 수천 단위로 낮아지고 있다.

복구는 됐다. 하지만 원인은? 추가 성명을 기다려보자.

세진은 아침부터 정리해온 인시던트 노트를 열었다. 마지막 섹션을 쓸 시간이다.

12:15 KST — 점심시간

점심을 건너뛰고 세진은 분석 노트의 결론을 정리하려다가, 유튜브의 추가 성명을 발견했다.

추천 시스템. Recommendations system.

세진은 아침에 적은 가설을 다시 열었다. 1순위: "추천 시스템의 장애." 그 가설이 공식 확인된 것이다.

맞았다. 방향은 맞았다. YouTube, Music, Kids, TV가 동시에 죽은 이유 — 전부 같은 추천 시스템에 의존했기 때문이었다. CDN과 검색이 살아있었던 이유 — 추천이 필요 없었기 때문이었다. 밖에서 증상만 보고 그린 지도가 안에서 본 지도와 같은 방향을 가리키고 있었다.

세진은 분석 노트를 최종 정리했다. 이제 가설이 아니라 확인된 사실이다.

세진은 정리를 마치고 의자에 기대앉았다. 밖에서 증상만 보고 그린 가설이 맞았다. 추천 시스템. 죽은 것과 산 것의 경계선을 따라가면 원인에 도달한다는 것을 다시 한번 확인했다.

물론 "추천 시스템의 문제"라는 한 줄이 전부를 설명하지는 않는다. 추천 모델의 배포가 잘못된 건지, 서빙 인프라에 과부하가 걸린 건지, 인덱싱 오류가 난 건지 — 그 구체적인 메커니즘은 구글 내부의 포스트모템을 기다려야 한다. 하지만 방향은 확인됐다.

인시던트 분석이란 원래 이런 것이다. 외부 관찰자는 증상밖에 모른다. 증상에서 원인을 역추적한다. 역추적에는 한계가 있다. 하지만 증상이 충분하면, 방향은 추론할 수 있다. 그리고 오늘, 그 방향이 맞았다.

13:40 KST

오후 미팅 전에 세진은 블로그 글을 쓰기 시작했다. 분석 노트를 정리해서 올리는 것이 루틴이다. 오전의 인시던트 노트를 블로그 형식으로 다듬으면서, 마지막에 항상 쓰는 섹션에 도달했다.

"이 장애가 의미하는 것."

세진은 숫자를 꺼냈다. 유튜브의 규모를 나타내는 공개된 수치들.

하루 10억 시간. 이 숫자를 1시간 장애에 대입하면 이렇게 된다.

4,170만 시간. 한 사람이 4,757년 동안 쉬지 않고 유튜브를 봐야 채울 수 있는 시간. 오늘 아침 약 2시간의 장애 동안 8,300만 시간의 시청이 사라졌다. 물론 전체 사용자가 영향을 받은 것은 아니고, 피드만 죽었기에 직접 URL로 우회한 사용자도 있었을 것이다. 하지만 순서대로.

99.999%의 가용성. 파이브 나인. 대규모 인터넷 서비스가 목표로 하는 가용성 수준. 이 숫자가 의미하는 것을 계산해보면.

한 달에 26초. 오늘의 장애는 약 105분이었다. 만약 이 장애가 파이브 나인을 깨뜨렸다면, 이 한 번의 장애로 연간 허용 다운타임의 20배를 소진한 것이다.

유튜브 전체가 파이브 나인이라고는 할 수 없다. 추천 시스템, 비디오 서빙, 검색 인덱스 — 각 서브시스템의 가용성이 다르고, 전체는 가장 약한 고리에 의해 결정된다. 체인에서 가장 약한 링크가 체인 전체의 강도를 결정하는 것처럼.

세진은 이 숫자들이 가리키는 근본적인 질문에 도달했다.

답은 간단하다. 복잡하니까.

유튜브는 하나의 서비스가 아니다. 수백 개의 마이크로서비스가 서로를 호출하는 거대한 그래프다. 피드 서비스는 추천 시스템을 호출하고, 추천 시스템은 사용자 임베딩과 ML 모델을 호출하고, 그 아래에는 Spanner와 ML 서빙 인프라가 깔려 있다. 이 그래프의 어떤 노드에서든 지연이 생기면, 그 지연은 상류로 전파된다. 하나의 느린 응답이 수십 개의 타임아웃을 만들고, 수십 개의 타임아웃이 수만 개의 에러가 된다.

이것이 분산 시스템의 역설이다. 단일 장애점(Single Point of Failure)을 제거하기 위해 시스템을 분산시키면, 장애가 발생할 수 있는 지점이 늘어난다. 각 지점의 신뢰성이 99.999%여도, 100개의 지점이 직렬로 의존하면 전체 신뢰성은 99.999%의 100제곱 = 99.9%가 된다. 연간 8.7시간의 다운타임. 파이브 나인이 쓰리 나인이 되는 것이다.

물론 구글의 엔지니어들은 이 역설을 알고 있다. 그래서 서킷 브레이커, 폴백, 그레이스풀 디그레이데이션, 벌크헤드 패턴 같은 방어 메커니즘을 겹겹이 쌓는다. 하나가 죽으면 대안 경로로 우회하고, 대안도 죽으면 캐시된 데이터를 보여주고, 캐시도 없으면 "부분적으로라도" 작동하게 만든다.

오늘 CDN이 살아있었던 것, 검색이 되었던 것, 개별 영상 재생이 가능했던 것 — 이것들은 모두 방어 메커니즘이 작동한 증거다. 전체가 죽지 않았다. 죽은 것만 죽었다. 그것 자체가 엔지니어링의 결과다.

완벽한 시스템은 없다. 있을 수도 없다. 복잡성이 증가하면 예측 불가능한 상호작용이 생긴다. 2020년에 쿼터 시스템이 인증을 죽인 것도, 2025년에 LB 마이그레이션이 DNS를 풀어버린 것도, 개별 컴포넌트는 정상이었지만 조합이 재앙이었다. 찰스 페로가 "정상 사고(Normal Accident)"라고 부른 현상이다. 복잡한 시스템에서 사고는 예외가 아니라 시스템의 속성이다.

0.001%의 틈새. 연간 5분 15초. 그 짧은 시간 동안 4,170만 시간의 시청이 흔들린다. 그 짧은 시간이 DownDetector에 30만 건의 봉우리를 만든다. 뉴스 속보가 나가고, 소셜 미디어가 들끓고, 수천 명의 크리에이터가 수익을 잃는다.

그리고 그 0.001%가 발생하지 않도록, 전 세계의 인프라 엔지니어들이 새벽 3시에 페이저 알림에 잠을 깬다.

18:30 KST

퇴근 전에 세진은 블로그 글을 마무리했다.

글을 발행하고 에디터를 닫았다. 누가 읽을지 모르겠지만, 읽든 안 읽든 상관없다. 세진이 인시던트 분석을 쓰는 이유는 독자를 위해서가 아니다. 정리하면서 배우기 때문이다. 증상을 나열하고, 가설을 세우고, 과거와 비교하고, 구조를 그리는 과정 자체가 공부다. 그리고 오늘은 가설이 맞았다는 보너스까지.

화이트보드를 봤다. 아침에 그린 비교표와 아키텍처 다이어그램이 그대로 남아있다. 지우지 않기로 했다. 다음 장애 때 참고할 수 있으니까.

다음 장애. 반드시 온다.

유튜브뿐이 아니다. AWS, Cloudflare, GitHub, Slack — 인터넷의 근간을 이루는 모든 대형 서비스는 장애를 겪었고, 겪고 있고, 겪을 것이다. 2023년 Cloudflare가 BGP 설정 오류로 멈췄다. 2024년 AWS에서 쿼터 에러가 났다. 2025년 GitHub이 데이터베이스 마이그레이션 중에 7시간 동안 비틀거렸다.

패턴은 비슷하다. 설정 변경, 마이그레이션, 배포 — 시스템을 바꾸는 순간에 사고가 난다. 멈춰 있는 시스템은 안정적이다. 움직이는 시스템이 부서진다. 하지만 멈추면 안 된다. 업데이트하지 않는 시스템은 더 큰 재앙의 씨앗이 된다. 보안 패치를 안 하면 뚫리고, 스케일링을 안 하면 터지고, 마이그레이션을 안 하면 기술 부채가 쌓여서 결국 더 크게 부서진다.

움직여야 하고, 움직이면 부서진다. 그래서 잘 부서지도록 설계해야 한다. 부서져도 전체가 죽지 않도록. 부서진 부분을 빠르게 찾아서 고칠 수 있도록. 부서진 후에 왜 부서졌는지 기록하도록. 그것이 SRE다. 그것이 인프라 엔지니어링이다.

세진은 가방을 챙기고 사무실을 나섰다. 엘리베이터를 기다리면서 유튜브를 열었다. 아침에 못 본 Computerphile 영상 — DNS 캐시 포이즈닝. 이어폰을 끼고 재생 버튼을 눌렀다.

재생된다.

CDN의 3,000개 엣지 서버 중 하나가 서울에서 가장 가까운 곳에서 영상 데이터를 보내주고 있다. 그 서버는 오늘 아침에도 멈추지 않았다. 피드가 죽는 동안에도, 30만 명이 "문제가 발생했습니다"를 보는 동안에도, CDN은 묵묵히 비트를 날랐다.

500,000대의 서버. 3,000개의 엣지. 초당 수십만 건의 추천 요청. 수십억 개의 영상에서 당신에게 맞는 것을 골라내는 ML 파이프라인. 이 거대한 기계가 99.999%의 시간 동안 작동한다.

나머지 0.001%에 대해서는, 누군가가 새벽에 일어나서, 로그를 뒤지고, 원인을 찾고, 고치고, 포스트모템을 쓰고, 같은 장애가 반복되지 않도록 시스템을 고치고, 그러고도 다음 장애를 기다린다.

그것이 인프라 엔지니어의 일이다. 0.001%와 싸우는 일.

전철에서 DNS 캐시 포이즈닝 영상을 보면서, 세진은 생각했다. 오늘 유튜브가 멈추지 않았다면 이 영상을 아침에 봤을 것이다. 장애 때문에 못 봤고, 대신 유튜브의 아키텍처를 2시간 동안 분석했다. DNS 캐시 포이즈닝보다 더 재미있는 공부였다.

구독 피드가 다시 돌아온 화면을 보며, 세진은 커피 대신 물을 한 모금 마셨다.

다음 장애는 언제 올까.

반드시 온다.