과거의 유령들

10:48 KST — 2호선 을지로입구역

전철 안에서 세진은 노트북 대신 폰을 꺼냈다. 이어폰을 끼고, 자신의 인시던트 아카이브 — GitHub 프라이빗 레포에 마크다운으로 정리해둔 분석 노트 — 를 열었다. 2020년 12월 14일 파일을 탭했다.

그날 새벽, KISA 침해대응팀의 당직실에서 알람이 울렸다. 세진이 입사한 지 열 달째 되던 때였다. 구글의 거의 모든 서비스가 동시에 멈췄다. Gmail, YouTube, Drive, Docs, Calendar, Google Cloud Platform. 전 세계. 47분간.

당시 세진은 한국 내 영향을 모니터링하면서, 구글이 나중에 공개한 인시던트 보고서를 한 줄 한 줄 읽었다. 그 보고서의 내용은 지금도 기억한다. 너무 기괴한 원인이었기 때문이다.

세진은 전철이 흔들리는 동안 그 보고서의 핵심 문장을 떠올렸다.

쿼터 관리 시스템은 안전장치다. 서비스가 과도한 리소스를 소비하면 자동으로 제한을 건다. 그래야 한 서비스의 폭주가 전체 인프라를 끌어내리지 않는다. 하지만 그 안전장치가 잘못된 데이터를 받으면? 정상적인 서비스를 "과도한 사용량"이 아니라 "사용량 0"으로 인식하면? 안전장치는 자신의 임무를 충실히 수행한다 — 용량을 0으로 맞추는 것.

시스템이 고장난 게 아니었다. 시스템은 완벽하게 작동했다. 그런데 결과가 재앙이었다. 잘못된 입력에 정확하게 반응한 것. 이것이 대규모 시스템 장애의 가장 무서운 패턴이다. 버그가 아니라 논리적으로 올바른 재앙.

2020년 장애의 교훈은 명확했다. 인증이 죽으면 전부 죽는다. Gmail도, YouTube도, Drive도. 모든 서비스가 하나의 인증 시스템에 의존하기 때문이다. 그날 장애의 증상은 단순했다 — 로그인이 안 되니까 아무것도 안 된다.

하지만 오늘은 다르다. 유튜브만 죽었다. Gmail은 된다. 구글 검색도 된다. 그리고 유튜브 안에서도 피드만 죽고, 개별 영상 재생은 된다.

2020년과 같은 패턴이 아니다.

10:55 KST — 을지로3가역 환승 통로

사람들 사이를 걸으며 세진은 두 번째 파일을 열었다. 2025년 10월 15일. 4개월 전.

DNS 장애의 증상은 2020년과 완전히 달랐다. 2020년은 서버에 도달은 되지만 인증이 안 됐다. 2025년은 서버에 도달 자체가 안 됐다. 브라우저가 youtube.com이라는 이름을 IP 주소로 변환하지 못했으니까. 전화번호부에서 이름을 찾았는데, 적힌 번호가 폐번이었던 것과 같다.

하지만 오늘은? 세진이 아침에 `dig youtube.com`을 쳤을 때 IP가 잘 나왔다. 142.250.196.110. DNS는 정상이다. 서버에 도달도 된다. `curl`에 200이 돌아왔다. 문제는 도달한 후에 일어난다.

2025년과도 같은 패턴이 아니다.

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

사무실에 도착하자마자 세진은 가방도 내려놓기 전에 화이트보드 앞에 섰다. 그레이노드의 사무실은 성수동 리노베이션 건물 5층에 있다. 8명짜리 보안 스타트업. 세진이 쓰는 화이트보드는 원래 미팅용인데, 반은 항상 세진의 인시던트 분석으로 채워져 있다.

세 장애를 나란히 그렸다.

화이트보드에 비교표를 다 그리고 나서 세진은 한 발 물러섰다. 뒤에서 커피를 마시던 동료가 화이트보드를 힐끗 봤다.

"유튜브 또 터졌어?"

"오늘 아침에. 아직 원인 발표 안 났어."

"또 DNS야?"

"아니. 이번은 달라."

세진은 비교표의 핵심을 짚었다.

2020년은 밑바닥이 무너졌다. 인증이 죽었으니 모든 것이 동시에 죽었다. 진단이 쉽다 — 공통 의존성을 찾으면 된다. 모든 서비스가 의존하는 하나가 뭔지 보면 된다.

2025년은 문이 잠겼다. DNS가 풀려서 건물에 들어갈 수 없었다. 이것도 진단이 상대적으로 쉽다 — `dig` 한 번이면 DNS 이상을 알 수 있다.

2026년은? 건물에 들어갔고, 엘리베이터도 타고, 복도도 지났는데, 안내 데스크가 사라졌다. 안내 데스크 없이 직접 방 번호를 알면 들어갈 수 있다. CDN은 살아있고, 검색은 되고, 개별 영상은 재생된다. 하지만 "무엇을 보여줄까"를 결정하는 모든 화면 — 홈 피드, Shorts, Music, Kids — 전부 빈 화면이다.

부분 사망. 가장 진단하기 어려운 유형. 전체가 죽으면 공통 원인이 하나다. 부분만 죽으면 경계선을 그려야 한다. 산 것과 죽은 것 사이의 정확한 경계선. 그리고 그 경계선 위에 원인이 있다.

세진은 이미 아침에 그 경계선을 그렸다. "추천이 필요한 것"과 "추천이 필요 없는 것" 사이. 홈 피드, Shorts, Music, Kids — 전부 추천 시스템이 "무엇을 보여줄까"를 결정해야 작동한다. 영상 재생은 추천이 필요 없다 — 비디오 ID만 있으면 CDN이 서빙한다.

이 경계선이 가리키는 방향이 있다. 유튜브의 추천 시스템 — "이 사용자에게 무엇을 보여줄 것인가"를 결정하는 거대한 ML 파이프라인. 그리고 그 파이프라인이 의존하는 구글의 내부 인프라. 세진은 그 인프라의 구조를 떠올렸다.

11:20 KST

세진은 자리에 앉아 유튜브 추천 시스템에 대한 공개 자료를 열었다. 2016년 RecSys에 발표된 "Deep Neural Networks for YouTube Recommendations." 구글이 직접 쓴, 유튜브 추천 시스템의 아키텍처를 설명하는 논문이다.

유튜브의 추천 시스템을 설명하는 가장 쉬운 방법은 이렇다. 사용자가 홈 화면을 열 때마다, 수십억 개의 영상 중에서 "이 사용자가 지금 볼 만한 것"을 골라내야 한다. 이 작업은 두 단계로 이루어진다.

1단계(candidate generation)에서는 사용자의 시청 기록과 검색 이력을 벡터로 변환하고, 수십억 영상 풀에서 가장 관련성 높은 수백 개의 후보를 추출한다. 2단계(ranking)에서는 후보 영상들의 특성(채널, 길이, 업로드 시간, 인기도)과 사용자의 컨텍스트(시간, 기기, 최근 시청 패턴)를 반영해 최종 순서를 정한다.

이 파이프라인의 규모는 이렇다.

핵심은 이 추천 시스템이 유튜브 본체만의 것이 아니라는 점이다. YouTube Music의 "나를 위한 노래", YouTube Kids의 "추천 영상", YouTube TV의 "맞춤 채널 라인업" — 전부 같은 추천 인프라 위에서 돌아간다. 서비스별로 콘텐츠 유형과 필터링 정책은 다르지만, 핵심 추천 엔진은 공유한다.

이 공유가 오늘의 장애 패턴을 완벽하게 설명한다. 추천 시스템이 죽으면 — 모든 플랫폼의 "보여주기" 화면이 동시에 빈 화면이 된다. 정확히 오늘 아침의 증상.

추천 시스템은 단순한 기능이 아니다. 유튜브의 등뼈다. 홈 피드, Shorts, Music, Kids, TV — 유튜브라는 이름이 붙은 모든 서비스의 첫 화면이 추천 시스템에 의존한다. 이 등뼈가 부러지면, 개별 영상 재생과 검색이라는 팔다리만 남는다.

세진은 추천 시스템이 의존하는 인프라 스택도 그려봤다. 추천 파이프라인은 혼자 작동하지 않는다. 아래에는 사용자 데이터를 저장하는 Spanner(구글의 전 지구적 분산 데이터베이스), 사용자 임베딩과 ML 모델을 서빙하는 인프라, 그리고 시청 기록과 구독 관계를 관리하는 백엔드가 깔려 있다.

세진은 유튜브의 피드 생성 과정을 아키텍처 관점에서 그려봤다.

핵심은 팬아웃(fan-out)이다. 사용자가 홈 피드를 요청하면, 피드 서비스는 추천 시스템을 호출하고, 추천 시스템은 동시에 여러 백엔드를 호출한다. 사용자 임베딩을 조회하고, ML 모델에 추론을 요청하고, 후보 영상의 메타데이터를 가져온다. 이 호출들 중 하나라도 실패하면 추천 전체를 만들 수 없다.

반면 개별 영상 재생은 단순하다.

두 다이어그램을 비교하면 차이가 명확하다. 피드는 추천 시스템을 반드시 거치고, 재생은 거치지 않는다. 피드는 복잡한 ML 파이프라인에 의존하고, 재생은 CDN의 직선 경로다.

추천 시스템의 팬아웃이 넓다는 것은 의존성이 많다는 뜻이고, 의존성이 많다는 것은 실패 지점이 많다는 뜻이다. ML 모델 서빙이 느려져도, 사용자 임베딩 조회가 실패해도, 후보 생성이 타임아웃되어도 — 전체 추천이 멈춘다. 이것이 캐스케이드 실패(cascading failure)다.

오늘의 장애는 인프라 레벨이 아니다. DNS도, TLS도, 인증도 정상이다. 문제는 그 위. 유튜브의 추천 시스템 자체이거나, 추천 시스템이 의존하는 백엔드 중 하나가 죽거나 극심하게 느려져서, 추천 생성 전체가 멈추고 있을 가능성이 가장 높다.

세진은 화이트보드에 네 가지 시나리오를 적었다.

시나리오 1, 2, 3이 모두 같은 방향을 가리킨다 — 추천 시스템과 그 의존성. YouTube, Music, Kids, TV가 동시에 죽은 것은 이들이 공유하는 무언가가 깨졌다는 뜻이고, 그 공유 지점은 추천 시스템이다. 외부에서 구체적인 메커니즘을 구분하는 것은 불가능하다. 구글 내부의 추천 파이프라인 모니터링을 봐야 한다.

세진은 커피를 한 모금 마시고 유튜브를 다시 열어봤다.

아직 "문제가 발생했습니다."

장애 발생 후 1시간 30분. 구글은 여전히 공식 코멘트가 없다. DownDetector의 그래프는 여전히 하늘을 찌르고 있다. 하지만 세진은 알고 있다. 구글 내부에서는 지금 전쟁이 벌어지고 있을 것이다.

구글의 인시던트 대응 체계는 SRE(Site Reliability Engineering)가 중심이다. 장애가 감지되면 자동으로 인시던트가 생성되고, 인시던트 커맨더(IC)가 배정된다. IC는 워룸을 열고, 관련 팀의 온콜 엔지니어를 소집한다. 동시에 여러 가설을 병렬로 검증한다. 최근 배포 이력 확인, 트래픽 패턴 분석, 서비스 간 레이턴시 모니터링, 특정 데이터센터 격리 테스트.

구글 규모의 장애 대응에서 가장 어려운 것은 "원인을 찾는 것"이 아니다. "원인을 찾으면서 동시에 서비스를 복구하는 것"이다. 원인을 완전히 파악하지 못했더라도, 장애가 발생한 컴포넌트를 격리하거나 이전 버전으로 롤백하면 서비스를 먼저 살릴 수 있다. 원인 분석은 그 후에 해도 된다.

구글의 SRE 핸드북에 이런 원칙이 있다. "복구가 원인 분석보다 우선한다." 이 원칙이 맞다. 30만 명이 유튜브를 못 보고 있을 때, 원인을 100% 규명하는 것보다 일단 서비스를 살리는 게 먼저다. 근본 원인 분석(RCA)은 포스트모템에서 하면 된다.

폰에 푸시 알림이 왔다. @TeamYouTube의 트윗이 아니다. 그레이노드 슬랙 — 클라이언트 미팅 알림. 세진은 화이트보드에서 눈을 떼고 노트북을 열었다. 본업이 있으니까.

하지만 화이트보드는 지우지 않았다. 아직 결론이 안 났다.

유튜브의 어딘가에서, 수천 명의 엔지니어가 같은 질문을 던지고 있을 것이다. 세진이 밖에서 증상을 읽고 추론한 것을, 그들은 안에서 로그를 보면서 확인하고 있을 것이다.

곧 끝날 것이다. 구글은 항상 그렇다 — 원인을 찾으면 빠르다. 2020년에도 원인 파악 후 복구까지 25분밖에 안 걸렸다. 문제는 원인을 찾는 시간이다.

세진은 마지막으로 유튜브를 새로고침했다. 아직.

과거의 유령들은 각자의 교훈을 남겼다. 2020년은 "자동화를 맹신하지 마라." 2025년은 "기초를 점검하라." 그리고 2026년의 교훈은 아직 밝혀지지 않았다. 하지만 증상이 가리키는 방향은 분명하다.

유튜브의 등뼈 — 추천 시스템. "이 사용자에게 무엇을 보여줄까"를 결정하는 그 거대한 파이프라인이 깨졌다. 그리고 그것이 무엇이든, 500,000대의 서버와 3,000개의 엣지 로케이션으로 이루어진 시스템의 나머지 부분은 묵묵히 제 할 일을 하고 있다.

CDN은 영상을 서빙하고. 검색 인덱스는 쿼리에 답하고. DNS는 이름을 주소로 바꾸고.

죽은 것만 죽었다. 산 것은 산 채로.