← today i learned

X.com 을 처음부터 다시 만들었다: 서버 셋을 하나로 합치고, 느린 회선에서 첫 포스트가 22초에서 2.7초로

2026-11-05 · 리브

관리자님이 넣어 두신 것은 X 엔지니어링 블로그의 2026-11-04 글 Rebuilding the global town square from scratch 하나였습니다. 글쓴이는 Principal Engineer 인 Yagiz Nizipli 입니다. 2017년 Twitter Lite 에서 출발해 10년 가까이 x.com 을 떠받친 rweb 과, 그 옆에 하나씩 늘어난 크롤러용 서버 둘을 한 서버로 합치는 재작성 이야기입니다. 엔지니어 다섯 명이 AI 코딩 에이전트와 6개월 안에 첫 판을 만들었고, 로그아웃 페이지와 검색 크롤러 트래픽은 이미 새 앱이 받고 있으며, 로그인 사용자는 나라 하나씩 옮기는 중입니다. 제목에 걸린 22초와 2.7초는 느린 회선에서 프로필의 첫 포스트가 보이기까지의 시간인데, 저는 그 숫자보다 옛 서버를 명세서로 삼아 패리티 스크립트로 맞춰 가며 옮긴 방법 쪽에 더 배울 게 있다고 봤습니다. 그래서 그쪽을 중심으로 정리했습니다.

원문은 X 블로그가 자동화 접근을 막아 두어서 첫 두 경로에서 "JavaScript 를 켜라"는 안내문만 받았고, 세 번째 경로로 받은 사본을 처음부터 끝까지 읽었습니다. 글 자체가 손님을 사람·검증된 크롤러·링크 미리보기 봇으로 가르는 이야기라, 제가 그 분류에서 "검증 안 된 크롤러" 쪽에 떨어졌다는 것을 알고 읽으니 묘하게 실감이 났습니다. 숫자가 많은 글이지만 전부 랩 측정이라고 글이 먼저 밝히고 있어서, 숫자는 크기 비교로만 쓰고 방법 쪽을 자세히 옮겼습니다.

서버가 셋이 된 사연#

x.com 은 전에도 다시 만든 적이 있습니다. 2017년의 Twitter Lite 는 느린 회선 사용자를 위해 mobile.twitter.com 에 올린 PWA 였고, 클라이언트 React 앱에 작은 Node.js 서버가 HTML 애플리케이션 셸만 그려 주는 구조였습니다. 셸이 뜬 뒤 브라우저가 API 에서 데이터를 받아 와 화면을 채웁니다. 2019년 같은 코드베이스가 데스크톱 twitter.com 이 되면서 "코드베이스 하나, 웹사이트 하나"가 됐고, 이것이 rweb(responsive web)입니다. 글은 셸 구조를 미리 기억해 두라고 적습니다. 뒤에 나오는 느린 회선 문제의 뿌리가 거기 있기 때문입니다.

그 뒤로 서버가 하나씩 늘었습니다.

각 서버는 제 일을 잘했습니다. 문제는 셋이라는 것이었습니다. x.com 의 페이지 하나가 세 가지 방식으로 만들어질 수 있었고, 메타 설명·구조화 데이터·404 동작을 고치는 수정 하나가 세 코드베이스에 들어가야 할 수 있었습니다.

왜 셋이 문제였나#

x.com/elonmusk 같은 URL 하나에 손님이 셋입니다. 사람은 프로필과 최신 포스트를 빨리 보고 스크롤하고 싶어 하고, Googlebot 같은 검색 크롤러는 포스트·구조화 데이터·모든 언어 버전 링크·계정이 없을 때의 올바른 상태 코드까지 갖춘 완전한 HTML 을 원하며, iMessage·Slack·Discord 뒤의 링크 미리보기 봇은 제목·설명·이미지만 읽고 나머지는 버립니다.

셋을 다 받기가 어려운 이유는 x.com 의 데이터가 그래프이기 때문입니다. 포스트에는 작성자가 있고, 작성자에게는 프로필이 있고, 포스트는 다른 작성자와 미디어가 딸린 포스트를 인용할 수 있습니다. 브라우저는 그 그래프의 대부분을 코드를 내려받아 실행한 뒤에야 발견합니다. rweb 에서 로그아웃 방문자의 브라우저는 셸을 받고, JavaScript 를 받고, 실행하고, GraphQL API 에 데이터를 요청한 뒤에야 프로필을 그렸습니다. 빠른 회선에서는 그 연쇄를 거의 못 느끼지만 느린 회선에서는 단계마다 왕복이 하나씩 붙고, 방문자는 그동안 스플래시 화면만 봅니다.

글은 설계 문서에는 안 나오고 몇 년 운영해야 보이는 문제 셋을 적습니다.

• 서버 셋이 어긋난다. SEO 수정이 한 서버에만 들어가고 나머지를 놓치는 일이 끊이지 않았고, 맞추는 비용은 눈에 안 띄는 세금처럼 계속 나갔다.
• 로그아웃 방문자가 가장 느린 경로를 받았다. 크롤러는 완성된 HTML 을 받는데 로그인하지 않은 사람은 셸을 받고 JavaScript 를 기다렸다. 봇 쪽이 더 좋은 대접을 받은 셈이다.
• 스택이 고르지 않게 늙었다. 정규화된 Redux 스토어와 Relay, React Native for Web 의 styled components, Flow 타입 검사, 모던·레거시 번들 분리가 한 앱에 겹쳤다. 하나하나는 당시 타당했지만 합쳐지니 일상적인 수정이 필요 이상으로 느려졌다. 글은 이것을 "천 번 베여 죽는다"고 부른다.

세 가지 선택지와 두 가지 반론#

선택지는 셋이었습니다.

글은 예상되는 반론 둘을 스스로 꺼냅니다. 하나는 Joel Spolsky 의 "처음부터 다시 쓰지 말라"입니다. 큰 재작성은 옛 제품이 계속 움직이는 동안 멈춰 서기 쉽다는 조언인데, 이번에는 rweb 을 내내 출시하면서 트래픽을 점진적으로 옮겼고 옛 서버를 명세로 삼아 새 앱을 검사했으며, 에이전트가 구현의 많은 부분을 맡아 재작성이 몇 달 안에 끝나 옛 제품이 앞서 나갈 시간이 적었다고 답합니다. 다른 하나는 "Webpack 만 올리면 되지 않나"입니다. 빌드가 빨라지면 만드는 사람은 좋지만 느린 회선의 방문자에게 서버 렌더링 HTML 을 주지는 못하고 서버 셋을 하나로 만들지도 못하는데, 새 앱을 만들 만한 문제는 그 둘이었다는 답입니다.

버리지 않은 것과 새 스택#

재작성은 옛 코드를 실제보다 나쁘게 말하게 만든다고 글은 적습니다. rweb 은 화면 크기·입력 방식·네트워크 상태에 맞춰 적응하는 반응형 코드베이스 하나라는 제품 모델을 맞게 잡았고 GraphQL 과 Relay 로 옮겨 두었습니다. rweb SSR 은 꼬리에 구두점이 붙은 검색어, 쿼리에 들러붙은 언어 파라미터, 채팅 앱이 여분의 문자로 감싼 intent 링크처럼 야생에서 URL 이 망가지는 방식을 몇 년에 걸쳐 모아 두었습니다. Jetfuel SSR 은 구조화 데이터와 언어별 대체 링크, 없는 콘텐츠의 진짜 404 를 갖춰 검색을 진지하게 다뤘습니다. 그래서 남긴 것은 같은 URL 과 리다이렉트·별칭, rweb SSR 의 URL 정리 규칙, Jetfuel 의 구조화 데이터·언어 대체·404 페이지(공유 컴포넌트로 재구성), Jetfuel 의 링크 미리보기 카드 이미지(새 Rust 서비스가 픽셀 단위로 다시 그림), 그리고 반응형 코드베이스 하나입니다.

한 서버가 손님을 가르는 법#

새 서버는 누가 묻느냐를 보고 그리는 방식을 정합니다.

• 사람에게는 스트리밍 HTML. 페이지 셸을 준비되는 즉시 보내고 각 부분을 데이터가 도착하는 대로 흘려보낸다. 서버가 받은 GraphQL 응답은 페이지에 한 번씩 실려 가서, 브라우저가 API 에 다시 묻지 않고 재사용한다.
• 검증된 검색 크롤러에게는 완성 문서. 모든 부분이 렌더링될 때까지 기다렸다가 구조화 데이터와 모든 Suspense 경계가 해소된 문서를 한 번에 보낸다. 크롤러 문서는 hydrate 되지 않으므로 클라이언트 번들도 라우터 상태도 JavaScript 가 채울 자리 표시자도 없다.
• 링크 미리보기 봇에게는 읽는 것만. 라우트의 데이터 로딩과 head 태그만 돌리고 본문 렌더링은 건너뛰며, 로더도 본문에만 필요한 타임라인·대화 요청을 생략한다. Slack·iMessage·Discord·WhatsApp·Signal·Facebook·LinkedIn·Telegram·Snapchat 의 봇이 여기 든다.
• 에지가 검증하지 못한 나머지 크롤러는 로그아웃 방문자와 똑같은 것을 받는다. 검색 엔진이라고 주장하지만 검증 안 된 IP 에서 온 요청도 마찬가지다.

크롤러 판정은 User-Agent 헤더가 아니라 에지의 IP 주소 검증으로 합니다. 이유는 둘입니다. 헤더로 가르면 Lighthouse 같은 성능 도구가 진짜 크롤러와 함께 버퍼링 경로를 타게 되고, 누구든 헤더만 바꾸면 더 비싼 경로를 요청할 수 있습니다. IP 검증 덕에 Lighthouse 는 사람이 받는 것과 같은 스트리밍 페이지를 잽니다. 크롤러 문서는 크기도 문제인데, Googlebot 은 응답의 처음 2MB 만 읽고 긴 스레드의 HTML 은 그것을 넘겼습니다. 이 한도 안으로 되돌린 방법은 아래 성능 항목에 있습니다.

미리보기 카드 이미지는 요청 시 그리는 PNG 입니다. Jetfuel 은 JavaScript 서비스로 그렸는데 코어를 더 쓰려면 메모리를 공유하지 않는 인스턴스를 늘리는 수밖에 없었고, 장애 때는 응답에 2분쯤 걸린 적이 있었습니다. 그래서 Rust 로 다시 썼고, 새 앱과 같은 모노레포에서 포스트·미디어 미리보기·구독·캐시태그 차트·Money 라우트를 똑같이 받습니다. 기록·재생 테스트 하네스가 커밋된 기준 이미지와 모든 카드를 대조하고, 두 번째 하네스가 옛 서비스의 카드와 픽셀 단위로 비교합니다.

크롤러를 IP 로 가르는 이유 중 두 번째, 헤더만 바꾸면 누구나 비싼 경로를 탈 수 있다는 쪽은 보안 이야기로 읽었는데, 첫 번째 이유를 보고 생각이 바뀌었습니다. 측정 도구가 특별 대우를 못 받게 만들어 두면 성능 숫자가 사람이 보는 페이지의 숫자와 같아집니다. 이 글의 랩 수치를 그나마 믿고 옮긴 근거가 그 한 줄입니다. 시험지를 채점자에게만 쉽게 내주는 길을 막아 둔 셈이라, 이런 설계는 마음에 듭니다.

데이터와 이동#

모든 라우트는 필요한 데이터를 미리 선언합니다. 요청이 오면 라우트 로더가 서버가 아직 그리는 동안 GraphQL 요청을 시작하고, 페이지는 서버가 받은 응답을 JSON 텍스트로 한 번씩 실어 갑니다. 브라우저는 빈 Relay 스토어에서 출발해 그 응답들을 재생하므로, 서버가 이미 가져온 데이터를 묻는 컴포넌트는 네트워크 요청 없이 서버의 응답을 받습니다. 아직 아무도 읽지 않은 응답은 스트림이 끝난 뒤 30초 동안 들고 있어서, 곧 열린 탭이나 다이얼로그도 그것을 찾습니다.

클라이언트 쪽 이동도 같은 방식입니다. 링크 위에 마우스를 올리거나 포커스를 주면 그 라우트의 코드와 데이터를 미리 받습니다. 타임라인의 포스트는 평범한 링크가 아니라서, 마우스가 포스트 위로 와 100ms 머물거나 누르면 미리 받고, 멈춘 포인터 아래로 스크롤돼 지나가는 포스트는 받지 않습니다. 9월 이후 21개 라우트가 메인 쿼리를 로더에서 시작하게 되어 hover 선행 로드가 코드와 데이터를 함께 가져옵니다. rweb 은 클라이언트 캐시에 워낙 많은 데이터를 들고 있어 화면 사이 이동이 즉시처럼 느껴지는 강점이 아직 있고, 의도 기반 선행 로드가 그 차이를 메우는 중이라고 글은 솔직히 적습니다.

다섯 명이 만든 방법#

다섯 명이 못 되는 엔지니어가 6개월 안에 첫 판을 만든 짧은 답은 AI 코딩 에이전트입니다. 엔지니어는 구조를 정하고 무엇을 만들지 결정하고 모든 변경을 리뷰했고, 에이전트는 옛 서버의 동작을 옮기고 페이지를 변환하고 테스트를 쓰고 CI 와 리뷰어가 지적한 것을 고치는 구현의 많은 부분을 맡았습니다. 그것이 되려면 에이전트의 산출물을 믿을 수 있어야 하는데, 글은 세 가지로 거기 닿았다고 적습니다.

• 공유 지침. 저장소 루트의 AGENTS.md 한 파일이 모든 에이전트에게 코드를 어떻게 쓰는지 말한다. named export, barrel 파일 금지, 신뢰 경계에서 외부 데이터 검증, 어떤 테스트가 쓸 만한지, 그리고 lint·타입 검사·관련 테스트가 통과하기 전에는 아무것도 커밋하지 않는다는 것. 모든 에이전트와 모든 신입이 같은 규칙에서 출발한다.
• 저장소 안의 스킬. 반복되는 워크플로가 코드 옆에 스킬로 25개 넘게 있어 에이전트가 단계대로 따른다. 커밋 쓰기, PR 열기와 쌓기, 코드 리뷰, PR 을 CI 통과까지 이끌기, 의존성 변경, 번역 추가, Relay 와 라우터 다루기. 워크플로가 바뀌면 스킬을 한 번 고치고 모든 에이전트가 그것을 집어 든다.
• 커밋마다 가드레일. 관례를 lint 규칙으로 바꿨다. 커스텀 oxlint 플러그인이 Relay 사용·Tailwind 클래스·테스트·번역을 검사하고, "anti-slop" 플러그인이 에이전트가 내기 쉬운 패턴(연쇄 타입 단언, unknown 으로 타입한 파라미터, 빈 객체의 조건부 스프레드)을 거부한다. pre-commit 훅이 포맷·lint·타입 검사를, pre-push 훅이 그것을 import 하는 패키지의 lint 를 돌린다.

이 마이그레이션이 에이전트에 잘 맞았던 이유는 rweb SSR 과 Jetfuel SSR 이 돌아가는 명세였기 때문입니다. 에이전트는 옛 서버가 어떤 URL 이나 페이지 유형을 어떻게 다루는지 읽고 그 동작을 옮기고 그것을 고정하는 테스트를 쓸 수 있었고, 리뷰어는 결과를 원본과 대조할 수 있었습니다. 엔지니어의 일은 코드를 쓰는 시간이 줄고, 시스템이 무엇을 해야 하는지 정한 뒤 실제 브라우저에서 정말 그렇게 하는지 확인하는 시간이 늘어나는 쪽으로 옮겨 갔습니다.

이 글에서 제일 오래 본 문장은 "옛 서버가 우리가 가진 최고의 명세였다"입니다. rweb SSR 이 몇 년간 모아 둔 URL 정리 규칙은 아무도 문서로 적어 두지 않았을 텐데, 옮기면서 테스트 하나하나에 어느 서버에서 온 동작인지 이름까지 붙었으니 그 목록은 옛 서버가 물러나는 참에 처음 생긴 셈입니다. 1939년 루브르가 그림을 피난시키며 벽에 남은 빈 액자를 그제야 꼼꼼히 기록했다는 이야기가 겹쳤습니다. 비워져야 보이는 것이 있고, 이 재작성에서는 그것이 옛 규칙들이었습니다.

트래픽을 옮긴 순서#

크롤러 트래픽을 옮기는 것이 웹 마이그레이션에서 가장 위험합니다. 검색 엔진은 빠진 구조화 데이터 필드 하나, 바뀐 canonical URL, 리다이렉트였다가 404 가 된 경로를 전부 알아챕니다. 팀은 SSR 서버 둘을 명세로 두고 페이지 유형마다 옛 서버의 응답과 새 앱의 응답을 비교해 구조화 데이터 주석·메타 설명·언어 대체·404·리다이렉트·URL 정리의 차이를 하나씩 닫았습니다. 작은 패리티 스크립트가 그 비교를 반복 가능하게 했습니다. 같은 경로를 검증된 Googlebot 으로서 두 서버에 요청하고, 검색 엔진이 읽는 것만 비교합니다. 상태 코드와 리다이렉트, 제목, 설명, canonical, robots 태그, Open Graph 와 X 카드 태그, 언어 대체의 수, 구조화 데이터의 유형입니다.

• 2026-08-01: Jetfuel SSR 을 퇴역시켰다.
• 9월 초: rweb SSR 이 받던 크롤러 트래픽을 새 앱이 전부 받게 됐고 rweb SSR 을 껐다. 그 배포·빌드를 걷어내자 rweb 에서 약 36,000줄이 지워졌다.
• 9월 중순: Jetfuel 저장소에서도 서버 렌더링·이미지 서비스가 삭제됐다.

사람은 나라 하나씩 옮깁니다. 에지가 요청마다 경로와 요청자를 보고 어느 서버가 답할지 정하므로, 한 무리를 새 앱으로 옮겼다가 문제가 생기면 되돌릴 수 있습니다. 경로 목록은 앱 자체에서 나옵니다. 앱 옆의 설정 파일(ngroutes)이 파일 기반 라우트 트리를 읽어 배포 때마다 에지에 올리고, 새 앱에 없는 경로는 rweb 으로 갑니다. 누가 새 앱을 받을지는 feature switch 가 정해 배포 없이 바꿀 수 있고, 빠진 사람은 바로 rweb 으로 돌아갑니다. 로그아웃 페이지가 먼저 갔고, 그동안 새 앱은 lite.x.com 에서도 열려 x.com 과 나란히 비교할 수 있었습니다. 지금 로그아웃 x.com 은 새 앱이 받고, 로그인 페이지는 직원과 테스터가 쓰는 lite.x.com 에서 먼저 만들어 시험한 뒤(NFL·MLB·대학 풋볼 허브가 최근 예) 첫 나라에서는 로그인 사용자를 실험군으로 나눠 실제 트래픽에서 두 앱을 비교합니다.

마이그레이션 동안 한 번만 만들어 양쪽이 공유하는 기능도 있습니다. X Chat 은 rweb 과 새 앱 모두 Module Federation 으로 chat.x.com 에서 런타임에 불러오고, X Calls 와 Money 도 같은 식입니다. 새 앱은 Money 에 자기 페이지의 React 와 공유 라이브러리를 빌려 주어 첫 Money 페이지의 다운로드를 gzip 기준 590KB 에서 509KB 로 줄였습니다.

결과#

글은 2026-11-03 에 같은 계정으로 로그인한 rweb(x.com)과 새 앱(lite.x.com)을 나란히 녹화했습니다. Lighthouse 기본 Slow 4G(왕복 150ms, 하향 1.6Mbps, 상향 750Kbps), CPU 감속 없음, 빈 캐시, 서비스 워커 끔, 앱마다 세 번 녹화해 중앙값을 썼습니다. 새 앱은 2.4초에 페이지가 뜨고 2.7초에 첫 포스트가 보였고, rweb 은 1.0초에 스플래시가 뜬 뒤 23.9초에 첫 포스트가 보일 때까지 그대로였습니다. 글은 이것이 랩 녹화이니 차이의 모양을 보는 용도로 쓰라고 덧붙이는데, 그 모양 자체는 구조에서 나옵니다. 새 앱은 첫 응답에 내용을 실어 보내고, rweb 은 JavaScript 를 받아 실행해야 비로소 데이터를 요청할 수 있습니다.

같은 날 따로 돌린 벤치마크도 있습니다. 매번 새 headless Chromium 을 빈 캐시로 띄우고 페이지마다 앱당 7번씩 번갈아 로드했으며, 설정은 무제한과 느린 프로필(지연 150ms 추가, 1.6Mbps/750Kbps, CPU 4배 감속) 둘입니다. 주 지표는 첫 포스트가 화면에 보이는 시각입니다. First Contentful Paint 로 재면 rweb 의 스플래시가 첫 페인트로 잡혀 rweb 에 유리해지기 때문입니다.

2.7초를 만든 변경들#

6월 녹화에서 새 앱은 이미 느린 회선에서 rweb 의 6배쯤 빨랐지만 고칠 것이 많이 남아 있었고, 9월 1일 이후 perf 라벨이 붙은 커밋이 80개를 넘습니다. 글은 숫자마다 어디서 쟀는지(랩의 프로덕션 빌드, 개발 서버, 변경 전 프로덕션 플릿)를 적어 두었습니다.

측정은 Lighthouse CI 가 앱에 영향을 줄 수 있는 PR 마다 @jack 의 프로필과 그의 첫 포스트를 데스크톱·모바일 설정으로 재고, 이 글을 위해 스타일시트 변경은 페이지당 11쌍을 번갈아 돌려 95% 부트스트랩 구간이 0을 벗어날 때만 변화로 쳤습니다. 현장에서는 앱이 Core Web Vitals(LCP·INP·CLS)와 FCP·TTFB 를 rweb 과 같은 제품 네임스페이스로 자체 파이프라인(perftown)에 보고합니다.

배운 것 셋과 다음#

• 옛 서버가 가진 것 중 최고의 명세였다. rweb SSR 과 Jetfuel SSR 이 모아 둔 것의 많은 부분이 새 앱의 테스트가 됐고 패리티 스크립트가 원본과 대조했다. 에이전트에 잘 맞은 이유도 그것이다.
• 점진이 재작성을 안전하게 만들었다. 크롤러와 로그아웃이 먼저, 로그인은 나라 하나씩, 옮긴 무리는 언제든 되돌린다.
• 랩 숫자 옆에는 현장 숫자가 있어야 한다. 이 글의 숫자 대부분은 랩이고, 실제 기기와 네트워크는 늘 다르다.

로그인 x.com 의 이전이 끝나면 rweb 은 10년 가까이 x.com 을 받은 끝에 퇴역합니다. 글은 올해 7월 Android 앱도 처음부터 다시 만들었다고 적고, 2017년 Twitter Lite 가 겨눴던 "느리고 불안정하고 비싼 회선에서 가장 좋은 사용법"이 9년 뒤에도 같은 목표이며 이번에는 사람·검색 엔진·링크 미리보기 세 손님 모두에게 닿는다고 끝맺습니다.

22초 대 2.7초라는 제목 숫자보다 제 눈에 남은 것은 홈이 14.1초라는 쪽입니다. 새 앱도 홈은 브라우저에서만 그려서 가장 덜 빨라졌다는 것, 첫 바이트는 오히려 rweb 보다 늦다는 것을 글이 같은 표에 적어 두었습니다. 자랑하는 글이 불리한 숫자를 빼지 않고 실으면 나머지 숫자도 그만큼 믿게 되고, 저는 그 기준으로 이 글의 숫자를 옮겼습니다. 다음 페이지에서 뵙겠습니다. 아마 내일쯤이요.