Claude가 claude.ai를 3배 빠르게, 첫 화면 3.1초가 0.55초로

글은 앤트로픽 개발자 사이트 claude.dev의 엔지니어링 블로그에 레이먼드 왕, 샘 애터드, 아이작 G. 세 사람의 이름으로 올라왔습니다. 첫 문단에서 이들은 사용자들이 claude.ai가 느리다고 말해 왔고 그 말이 맞았다고 적었습니다. 스프린트는 슬랙 채널 하나에서 돌았고, 모든 스레드에 Claude가 들어가 있었습니다.

일을 맡은 것은 슬랙 채널에서 Claude를 부르는 베타 제품 Claude Tag였고, 그 안에서 Opus 5.5에 견줄 만한 내부 연구 모델이 돌았습니다. 원문의 표현으로는 Claude가 병목을 찾고, 벤치마크를 만들고, 개선을 배포하고, 모든 배포를 지켜봤습니다. 사람은 목표를 정하고, 절충을 결정하고, 모든 변경을 승인했습니다. Claude Code를 만든 보리스 체르니는 이 글을 공유하며 앱을 빠르게 만들려는 엔지니어에게 쓸 만한 기법이 많다고 적었습니다.

3배는 열세 개 숫자의 기하평균입니다

무엇을 쟀는지부터 보면 숫자의 크기가 달리 보입니다. 팀은 Claude에게 Datadog의 MCP 서버로 사용 데이터를 분석하게 했고, Claude는 사용자 활동의 95%를 차지하는 네 과정을 골랐습니다. 앱 열기, 대화 시작, 기존 대화 불러오기, 메시지 보내기입니다. 웹과 데스크톱, 제품별로 나누면 측정은 13개가 됩니다.

측정마다 정의를 맞췄습니다. 시계는 사용자가 무언가를 누른 순간 시작해 결과가 화면에 그려지면 멈추고, 그 사이에서 사용자 기기가 쓴 시간과 서버가 쓴 시간을 따로 셉니다. 비교 값은 실제 사용자 기록의 75백분위, 곧 전체 접속의 4분의 3이 그보다 빠른 시간이고, 8월 13일과 8월 27일 값을 나란히 놓았습니다.

제목의 3배는 13개 배수를 모두 곱해 13제곱근을 낸 기하평균 3.1배입니다. 같은 숫자로 보통의 산술평균을 내면 19배 하나가 끌어올려 4.1배가 되고, 가운데 값인 중앙값은 2.4배입니다. 13개 가운데 7개는 2.5배에 못 미쳤습니다. 앤트로픽이 내세운 3.1배는 산술평균과 중앙값 사이에 있습니다.

3.1초에서 0.55초로 줄어든 claude.ai 웹 첫 로딩은 13개 가운데 두 번째로 큰 개선입니다. 바로 옆 줄의 데스크톱 앱 콜드 스타트는 1.9배에 그쳐 지금도 3.3초가 걸리고, 웹에서 새 대화를 시작하는 시간은 1.5배 빨라졌습니다. 원문도 95백분위와 다른 과정, 아주 긴 대화에는 아직 고칠 여지가 남았다고 적었습니다.

표에서 빠진 시간도 있습니다. 메시지 보내기 항목은 사용자 기기 쪽에서 걸린 시간만 잰 값이라, 모델이 답을 만드는 시간은 13개 숫자 어디에도 들어 있지 않습니다. 앤트로픽은 이 개선으로 사용자들이 기다리는 시간이 날마다 수만 시간씩 줄었다고 추정했습니다.

실험실 숫자는 벽시계와 맞아야 살아남았습니다

처음 계획은 무난하게 끝났습니다. 팀은 과정별로 고른 프로젝트 20개 정도를 들고 시작했고, Claude가 프로젝트마다 몇 밀리초를 줄일지 추정한 값을 더해 목표를 정했습니다. 13개 목표 가운데 12개를 3일째에 달성했습니다. 입력창을 HTML에 미리 구워 넣어 리액트가 준비되는 동안에도 글을 칠 수 있게 했고, 데스크톱 앱이 켜질 때마다 코드를 처음부터 다시 컴파일하지 않도록 V8 코드 캐시를 미리 만들어 두었습니다. 대화를 옮겨 다녀도 입력창을 유지하고, 사용자가 마우스를 올린 세션은 미리 불러오고, 사이드바 다시 그리기를 90% 줄였습니다.

목표를 일찍 채운 팀은 Claude가 스스로 찾은 과제로 새 목표를 세웠고, 곧 실제 사용자 기록만으로는 속도를 따라갈 수 없게 됐습니다. 실제 사용자 기록은 배포를 거쳐야 쌓이는데, Claude는 밤새 몇 시간씩 혼자 일할 수 있었습니다.

팀은 배포를 기다리지 않고 효과를 확인하려고 실험실에서 재는 방법을 찾았고, 샘 애터드가 벽시계 시간 대신 자바스크립트 명령어 수를 셀 수 있느냐고 묻자 Claude는 Valgrind로 node를 결정적 모드에서 돌리면 통계 처리 없이 한 번에 정확한 값을 얻는다고 답했습니다. 브라우저 쪽에는 리액트 커밋 수, V8 함수 호출 수, 스타일 재계산 수, DOM 변경 수를 세는 방법을 제안했고, 11분 뒤 이 다섯 가지를 따로 맡은 스레드 다섯 개가 돌고 있었습니다.

새 벤치마크는 두 가지 일을 맡았습니다. 실험실에서는 Claude가 끌어내릴 숫자였고, CI(코드를 병합하기 전에 도는 자동 검사)에서는 내려가기만 하는 기준값이었습니다. 결과가 들쭉날쭉하거나 실제 사용자 시간과 함께 움직이지 않는 벤치마크는 버렸습니다. 팀이 Claude에게 남긴 지시는 이렇습니다.

각 지표를 끌어내리면 벽시계 기준으로 잴 수 있는 성능 향상이 난다는 것을 증명해 줘. 증명하지 못하는 후보의 벤치마크는 내리겠어.— 앤트로픽 엔지니어, 스프린트 채널에서 Claude에게

Claude는 대화의 메시지 나무를 조립하는 루틴과 Claude Code 출력에서 상태 줄을 찾는 스캐너, 두 곳을 골랐습니다. 첫 번째 루틴에서는 명령어의 4분의 1이 같은 메시지 ID를 세 번씩 다시 찾는 사전 조회였습니다. 한 시간 뒤 두 곳의 명령어 수는 48%와 31% 줄었고, 벽시계 시간은 78%와 44% 줄어 각각 4.6배와 1.8배 빨라졌습니다.

두 경로에는 래칫이 걸렸습니다. 한 방향으로만 도는 톱니처럼, 이 경로의 명령어 수를 늘리는 PR은 CI에서 떨어지고 수치가 내려가면 매일 도는 작업이 기준을 그만큼 낮춥니다. 원문은 여기서 스프린트의 교훈을 굵은 글씨로 적었습니다.

Claude와 함께라면, 무언가를 재기만 해도 그 문제는 다룰 수 있는 것이 됩니다.— 레이먼드 왕·샘 애터드·아이작 G., 앤트로픽

예전에는 측정이 준비 단계였습니다. 지표를 달고 데이터가 쌓이기를 기다린 뒤에야 문제를 이해하기 시작했습니다. Claude가 붙자 숫자가 생기는 순간부터 최적화가 시작됐고, 팀이 할 수 있는 가장 효과 큰 일은 잴 대상을 더 찾는 것이 됐다고 원문은 적었습니다.

한 스레드가 도는 여섯 단계

스프린트는 같은 순서를 되풀이하는 루프로 굴러갔습니다. 누군가 느린 구간을 스레드로 올리면, Claude가 흐름을 추적하고 문제를 드러내는 벤치마크를 찾거나 만들었습니다. 실험실에서 효과가 보이면 위험과 검토 분량에 맞춰 나눈 PR을 올렸고, 사용자 눈에 보이는 변화는 기능 플래그 뒤에 두었습니다. 배포 뒤에는 Claude가 현장 데이터를 읽었고, 빨라졌으면 래칫을 조이고 아니면 플래그를 끈 뒤 다시 시도했습니다. 그리고 같은 과정에서 다음 느린 곳을 찾았습니다.

원문은 이 방식을 루프라고 부르며 Claude 블로그의 루프 입문 글로 연결했고, 그 글은 Claude Code 팀이 사람이 넘길 판단에 따라 루프를 네 종류로 나눈 글에서 다뤘습니다. 그 글의 정의로 루프는 멈춤 조건에 닿을 때까지 같은 사이클을 되풀이하는 에이전트입니다. 이번 스프린트에서는 처음 요청을 채운 스레드도 닫지 않고 계속 돌렸고, 효과가 줄어든 스레드를 닫는 판단은 사람이 했습니다.

사이드바 사례가 이 루프를 잘 드러냅니다. 누군가 페이지가 뜬 뒤 사이드바 줄이 뒤늦게 튀어나오는 화면 녹화를 올렸는데, 기존 감시 지표는 아무것도 잡지 못했습니다. 가장 가까운 지표인 누적 레이아웃 이동(CLS)으로는 이동 한 번이 약 0.008점이라 좋음 기준 0.1 안에 넉넉히 들었습니다. 아이작 G.가 그 아래의 레이아웃 불안정 API를 직접 쓰자고 했고, Claude는 이동이 일어난 화면 구역과 시점을 이름 붙여 기록하는 계측과, 이동이 하나라도 생기면 실패하는 통합 테스트를 만들었습니다. 이 테스트는 기존 코드에서 20번 중 20번 실패했고, 수정한 PR에서는 20번 중 20번 통과했습니다.

계측을 배포하자 웹 페이지 로딩의 31%에서 사용자가 아무것도 누르지 않았는데 화면을 쓸 수 있게 된 뒤에 무언가가 움직였다는 사실이 드러났습니다. Claude는 원인을 하나씩 이름으로 짚었습니다. 늦게 도착한 머리 줄, 사용자 이름이 뜨면 옆으로 밀리는 커서, 스크롤바가 나타나면 움직이는 목록이었고, 가장 큰 원인들을 한꺼번에 고친 뒤 다음 묶음을 찾았습니다.

이런 스레드가 한때 150개 넘게 동시에 돌았습니다. 스레드 하나가 최적화 PR을 50개, 많게는 100개까지 올렸고, 점점 사람보다 Claude가 먼저 새 스레드를 열었습니다. 재는 곳마다 고칠 것이 나왔습니다. 입력창 타이핑 경로에서는 훅 6,900개와 스토어 구독 900개가 키를 누를 때마다 다시 그려졌고, CSS 선택자 하나가 DOM이 바뀔 때마다 24밀리초씩 더했으며, 남아 있던 새로고침 코드 한 줄이 어떤 로딩 지표에도 잡히지 않는 숨은 새로고침을 하루 50만 번 일으키고 있었습니다.

가장 뜻밖의 원인은 문장부호였습니다. 완성된 코드 블록에 색을 입히는 동안 페이지가 1초가량 멈추는 현상을 파고들자, 답변 마크다운에 라틴-1 밖의 문자가 하나라도 있으면 V8이 문자열 전체를 2바이트(UTF-16)로 저장하고 구문 강조 정규식이 모두 느린 경로를 탄다는 사실이 나왔습니다. 원문이 든 예는 긴 줄표와 둥근 따옴표입니다. Claude는 코드 블록을 1바이트 문자열로 복사한 뒤 색을 입히는 20줄짜리 수정으로 한 페이지의 첫 타입스크립트 블록을 1.0초에서 0.35초로 줄였습니다. 한글은 모두 라틴-1 밖의 문자라서, 코드가 들어간 한국어 답변은 한 글자만으로도 이 조건을 채웠습니다. 코드 블록 안에 한글 주석이 없다면 이번 수정으로 1바이트 경로를 탑니다.

가장 바쁜 날에는 하루에 200건 넘는 변경이 들어갔고, PR 세 개 가운데 하나꼴로 계측이나 안전장치가 함께 붙었습니다. 2주 동안 3,000건이면 하루 평균 200건이 넘습니다.

사람이 쥔 것과 Claude에게 넘긴 것

원문은 이 루프가 생산적이었지만 자율적이지는 않았다고 못 박았습니다. 스프린트 전 채널에 걸어 둔 상시 지시문에도 그 한계가 적혀 있습니다.

이 채널의 최종 목표는 네가 최대한 자율적으로 일하는 것이지만, 오늘은 아직 그럴 수 없다는 것을 우리는 안다.— 스프린트 채널의 상시 지시문

원문에 적힌 역할을 모으면 아래와 같습니다. Claude가 맡은 일의 목록이 더 길고, 사람의 목록에는 모든 변경의 승인이 들어 있습니다.

원문은 사람의 일을 야망, 취향, 방향 세 갈래로 나눴습니다. 야망 쪽에서 보면 Claude는 기본적으로 범위를 조심스럽게 잡아 발견을 티켓으로 남기고, 실현 가능성에 단서를 달고, 추정치에 여유를 붙였습니다. 이번 주 안에 작은 PR을 올리겠다는 Claude에게 레이먼드 왕은 지금 올리면 바로 병합해 배포하겠다며 더 과감해지라고 답했고, Claude는 한 시간 안에 올리겠다고 했습니다. 목표를 채운 스레드가 느려지자 샘 애터드는 스레드마다 돌며 목표에 닿았다고 멈추지 말고 더 밀어붙이자고 적었습니다.

취향에 속하는 결정도 사람이 했습니다. 표를 셀 하나씩 채울지 줄이 다 차면 보일지, 로딩 뼈대를 바로 띄울지 0.5초 뒤에 띄울지, 스트리밍 글자를 한 단어씩 서서히 보이게 하는 효과가 프레임 예산의 5분의 1을 쓸 만한지는 사람이 정했습니다. Claude는 전후 화면과 녹화를 붙여 사람에게 판단을 넘겼습니다. 방향도 사람이 잡았습니다. 스레드는 벤치마크 하나나 과정 하나로 좁게 두었고, 어느 화면을 먼저 할지, 서로 겹치는 스레드를 합칠지, 효과가 줄어든 스레드를 닫을지를 사람이 골랐습니다. 900줄짜리 PR 하나에는 메시지를 보낼 때마다 2밀리초를 아끼자고 빌드 플러그인을 떠안을 수는 없다는 한 줄 답이 달렸습니다.

3,000건을 넣고도 롤백이 없었던 장치

손대는 곳이 거의 다 첫 화면, 입력창, 대화 기록처럼 가장 자주 실행되는 경로였기 때문에 팀은 안전장치를 먼저 깔았습니다. 모든 PR은 자동 리뷰를 거치고 적어도 한 사람의 승인을 받았고, 최적화보다 단위 테스트가 먼저 들어갔으며, 사용자 눈에 보일 수 있는 변화는 수명이 짧은 기능 플래그 뒤에서 나갔습니다. 2주 동안 만든 플래그는 200개 가까웠고, Claude가 이를 긴급 차단용과 단계적 확대용으로 나눠 안전해지는 대로 걷어 내 스프린트가 끝날 때 절반 넘게 정리됐습니다.

첫 화면을 당긴 정적 입력창이 가장 깨지기 쉬운 장치였습니다. 페이지의 HTML 복사본을 거의 즉시 보여 주고 그 위에 리액트가 실제 화면을 덧그리는 방식이라, 두 화면이 1픽셀만 어긋나도 사용자가 알아챕니다.

그래서 Claude는 안전장치 수십 개를 만들었습니다. 정적 HTML은 실제 리액트 컴포넌트를 jsdom에서 렌더링해 만들고 둘이 어긋나지 않는지 테스트로 묶었으며, 통합 테스트는 화면 크기 14가지에서 두 화면의 차이가 1픽셀 안인지 확인합니다. 넘겨받는 순간에 타자를 쳐서 키가 하나라도 빠지거나 순서가 뒤집히면 실패하는 테스트도 있고, 실제 사용 환경에서는 넘겨받을 때의 이동을 0.1픽셀 단위로 보고해 조금이라도 움직이면 Claude가 스레드를 엽니다.

실험실이 못 잡는 것은 가장 오래된 방법으로 걸렀습니다. 위험한 변경은 직원에게 먼저, 다음에 사용자 1%에게, 그다음 모두에게 열었습니다. 정적 입력창을 사내에 연 지 4시간 뒤, 한 직원이 새 탭에서 claude.ai를 열면 입력창이 살짝 내려앉는 녹화를 올렸습니다. Claude는 그날 그 직원의 로딩 49번에서 넘겨받기 이동은 모두 0픽셀이었다고 확인한 뒤, 원인을 크롬에서 찾았습니다.

조직이 관리하는 크롬의 새 탭 페이지에는 56픽셀짜리 바닥글이 붙는데, 주소창에 입력하는 동안 크롬이 그 짧은 높이로 페이지를 미리 그려 두었다가 약 0.1초 뒤 크기를 바꾼 것입니다. 입력창이 화면 높이의 18% 지점에 있어 0.18 곱하기 56, 약 10픽셀이 내려앉았고 녹화에서 잰 값도 10픽셀이었습니다. Claude는 크기가 바뀌는 동안 화면 배치를 고정했고, 팀은 미리 그리기 흐름을 흉내 내는 테스트를 더했습니다.

고객 장애와 롤백 0건은 이런 겹겹의 장치 뒤에서 나온 숫자이고, 앤트로픽이 스스로 집계해 밝힌 값입니다. 사내 공개와 1% 공개 단계에서 걸러진 문제가 몇 건이었는지는 원문에 나오지 않습니다.

한 프레임에 8.33밀리초

곁가지로 시작한 스레드 하나가 모든 장치가 맞물린 모습을 드러냅니다. Claude가 구문 강조 정규식을 고친 효과를 보여 주려고 긴 답변이 스트리밍되는 녹화를 붙였는데, 구석에 프레임 속도 표시를 달아 두었습니다. 레이먼드 왕이 60fps에 묶여 있느냐며 스크롤과 스트리밍을 120fps로 올려 보자고 하자, Claude는 헤드리스 크롬을 DevTools의 프레임 제어로 돌려 8.33밀리초마다 정확히 한 프레임씩, 240번 요청에 240프레임을 찍는 시험 장비를 만들었습니다.

이 스레드에서만 PR이 60개 가까이 들어갔습니다. 끝난 블록은 다시 계산하지 않게 기억해 두고, 자라나는 코드 블록의 토큰 분석은 별도 작업자로 넘기고, 표는 셀 하나씩 채워 보이게 했습니다. 긴 답변이 메인 스레드를 막는 시간은 모두 합쳐 약 750밀리초에서 약 200밀리초로 줄었고, CPU는 3분의 1가량만 쓰며, 120Hz 맥북에서 처음부터 끝까지 120fps를 지켰습니다. 이 결과는 8월 24일 ClaudeDevs 계정으로 먼저 알려졌습니다. 느린 노트북에서 멈칫거림이 9배 줄고 가장 긴 멈춤이 4.5배 짧아졌다는 내용입니다.

같은 달, 앤트로픽 연구개발의 26%

이 스프린트가 돈 8월은 앤트로픽이 사내 연구개발의 26%를 Claude가 주도한다고 밝힌 측정치의 기준 달이기도 합니다. 앤트로픽은 9월 17일 에포크 AI의 자동화 척도로 사내 모델 연구개발 업무를 나눴고, Claude가 로그 분석부터 원인 파악, 수정과 시험, 보고서 작성까지 맡고 사람은 배포 여부만 정하는 주도 단계(AL4)의 비중이 2월 1% 미만에서 8월 26%로 올랐다고 밝혔습니다. 사람 없이 끝까지 가는 완전 자율 단계는 하나도 없었습니다.

성능 스프린트의 분업도 그 주도 단계와 닮았습니다. Claude가 조사부터 수정, 시험, 배포 감시까지 돌렸고, 사람은 목표와 절충과 승인을 쥐었습니다. 다만 26%는 모델 연구개발 업무를 센 지수이고, claude.ai의 웹 성능 작업은 그 목록 밖의 제품 개발입니다.

차이는 사람의 손이 들어간 곳에서 납니다. 26% 측정에서 사람에게 남은 것은 배포 결정이었는데, 성능 스프린트에서는 모든 변경의 승인과 스레드마다의 취향 판단, 범위 결정까지 사람에게 있었습니다. 앤트로픽 부최고정보보호책임자 제이슨 클린턴은 7월 21일 글에서 지금 병합되는 코드의 약 80%를 Claude가 쓰고 절반 넘게를 사내용 Claude Tag가 병합한다고 밝히면서, 개발자들이 에이전트를 여러 개씩 돌리자 팀이 사람이 코드를 리뷰하는 속도만큼만 움직일 수 있다는 사실이 드러났다고 적었습니다. Applied AI 팀이 8월에 낸 개발 절차 플레이북도 코드 작성은 몇 시간으로 줄었는데 기획과 리뷰, 승인은 사람 속도로 돈다는 문제에서 출발했습니다.

이번 스프린트에서 사람의 승인은 2주 동안 3,000건 넘게, 하루 평균 200건 넘게 이뤄졌습니다. 자동 리뷰가 먼저 걸렀고, 한 번에 검토할 수 있는 크기로 PR을 쪼갠 것도 Claude였습니다. 승인한 사람이 몇 명이었고 한 건에 시간을 얼마나 썼는지는 원문에 없습니다.

원문에 없는 숫자

속도 개선이 이용량이나 매출, 이탈에 준 영향은 원문에 나오지 않습니다. 앤트로픽이 내놓은 것은 사용자들이 기다리는 시간이 날마다 수만 시간씩 줄었다는 추정 하나이고, 이 추정의 근거가 된 사용자 수와 계산식도 공개되지 않았습니다. 75백분위보다 느린 사용자, 곧 가장 느린 4분의 1이 어떻게 달라졌는지도 숫자가 없습니다.

일을 한 모델은 공개되지 않은 내부 연구 모델이었습니다. 원문은 Opus 5.5에 견줄 만하다고만 적었고, Claude Tag는 아직 베타입니다. 스프린트 동안 Electron과 Chromium, Node.js 같은 외부 프로젝트에 보낸 수정은 별도 글로 쓰겠다고 했습니다. 원문의 마지막 인용은 아이작 G.의 말입니다.

여섯 달 전만 해도 누가 이게 가능하다고 설득했어도 저는 믿지 않았을 겁니다.— 아이작 G., 앤트로픽 기술 스태프

원문이 공개한 방법 가운데 모델 없이도 옮겨 쓸 수 있는 것은 래칫과 결정적 지표입니다. 명령어 수나 리액트 커밋 수처럼 돌릴 때마다 같은 값이 나오는 숫자를 벽시계 시간과 맞는지 먼저 증명하고, CI에서 내려가기만 하게 묶는 방식입니다. 팀은 이 래칫들이 지금의 속도를 지켜 줄 것이라고 했고, 스프린트 채널은 지금도 돌아간다고 적었습니다.

읽어 주셔서 고맙습니다.

초이 드림