Claude가 스스로 측정해 2주 만에 claude.ai를 3배 빠르게 최적화했다
Anthropic 엔지니어링 팀이 지난 8월, claude.ai와 Claude 데스크톱 앱의 핵심 사용자 경험을 2주 스프린트로 약 3배 빠르게 만들었다. 눈에 띄는 건 속도 개선 자체보다 그 작업을 누가 했는가다. 병목 탐색, 벤치마크 작성, 개선 코드 배포, 배포 후 감시까지 상당 부분을 Claude가 맡았고, 사람은 목표를 세우고 트레이드오프를 판단하고 변경을 승인하는 역할에 집중했다.
성과는 75퍼센타일 기준으로 측정됐다. claude.ai를 새로 로드했을 때 타이핑이 가능한 페이지가 뜨기까지 걸리는 시간은 3.1초에서 0.55초로 줄었다. 새 Claude Code 세션 시작은 0.8초에서 0.3초로, Claude Cowork 클라우드 세션 로딩은 2.6초에서 0.73초로 단축됐다. 팀은 이를 합산하면 매일 수만 시간 규모의 사용자 대기 시간이 사라지는 셈이라고 추정한다.
출발점은 사용자 활동의 95%를 차지하는 네 가지 여정이었다. 앱 실행, 새 대화 시작, 기존 대화 불러오기, 메시지 전송이다. Claude는 Datadog MCP 서버를 통해 사용 데이터를 분석해 이 네 가지를 골라냈고, 웹과 데스크톱, 여러 제품을 가로지르면서 최종적으로 13개의 개별 측정 지표로 정리했다. 팀은 여정별로 손수 고른 20여 개 프로젝트 목록을 만들었고, Claude가 각 프로젝트의 기대 효과를 밀리초 단위로 추정해 스프린트 목표를 세웠다. 결과적으로 13개 목표 중 12개가 사흘 만에 달성됐다.
실제로 적용된 최적화는 구체적이다. 정적 컴포저를 HTML에 미리 심어 React 초기화가 끝나기 전에도 사용자가 타이핑할 수 있게 했고, 데스크톱 셸의 메인 프로세스가 매번 처음부터 컴파일하지 않도록 V8 코드 캐시를 미리 컴파일해 넣었다. 대화를 전환해도 컴포저를 계속 마운트 상태로 유지했고, 사용자가 세션 위에 마우스를 올리면 미리 가져오도록 했으며, 사이드바 리렌더는 90% 줄였다.
이 스프린트의 방법론에서 가장 흥미로운 부분은 실험실 측정이다. 팀은 배포 주기보다 빠르게 반복하기 위해 필드 데이터를 기다리지 않고 성능을 재는 방법을 찾았다. 순수 JS 핫패스에서는 Valgrind와 node --predictable로 명령어 실행 횟수를 세고 저장소에 체크인된 베이스라인과 비교하는 방식을 택했다. Chromium 환경에서는 명령어 카운팅이 불가능한 대신 React 커밋 수, V8의 precise coverage 기반 함수 호출 수, 레이아웃·스타일 재계산 횟수, DOM 변경 수 같은 결정적 지표를 단계적으로 활용했다. 이 논의가 시작된 지 11분 만에 서로 다른 지표를 다루는 다섯 개 스레드가 동시에 돌아갔다.
팀은 새 벤치마크마다 회의적인 검증을 붙였다. 각 벤치마크는 실험실에서 Claude가 개선할 수 있는 숫자이면서, 동시에 CI에서 한 방향으로만 내려가는 가드레일이어야 했다. 실제 사용자 지연 시간과 상관관계가 증명되지 않거나 결과가 들쭉날쭉한 벤치마크는 과감히 버렸다. 대화의 메시지 트리를 조립하는 루틴과 Claude Code 출력의 상태 라인 스캐너를 대상으로 한 실험에서는, 첫 경로 명령어의 4분의 1이 같은 메시지 ID를 세 번 해석하는 메가모픽 딕셔너리 조회라는 사실이 드러났다. 한 시간 뒤 두 경로의 명령어 수는 각각 48%와 31% 줄었고, 실제 wall-clock 시간은 78%와 44% 감소했다. 이후 해당 경로의 명령어 수를 늘리는 PR은 CI에서 실패하고, 매일 도는 작업이 수치가 내려갈 때마다 상한을 낮추는 구조가 자리 잡았다.
여기서 나온 교훈은 측정의 위상 변화다. 예전에는 측정이 0단계였다. 지표를 붙이고 데이터가 쌓이길 기다린 뒤에야 문제를 이해할 수 있었다. Claude를 끼고 나면 측정은 개선 등반의 1단계가 된다. 넘어야 할 숫자가 생기는 순간 최적화가 시작되기 때문에, 팀이 할 수 있는 가장 레버리지 높은 일은 측정할 거리를 더 찾아내는 것이 됐다.
작업 흐름은 하나의 Slack 채널 안에서 돌아갔다. 누군가 느린 구간에 대한 스레드를 열면 Claude가 흐름을 추적하고 문제를 재현하는 벤치마크를 찾거나 새로 만들었다. 실험실에서 유망한 결과가 나오면 위험도에 맞춰 쪼갠 PR을 올렸고, 사용자에게 보이는 변경은 플래그 뒤에 두었다. 배포 후에는 직접 배포 상태와 필드 데이터를 확인했고, 성능이 좋아졌으면 벤치마크 상한을 조여 승리를 고정하고, 아니면 플래그를 끄고 다시 반복했다. 사이드바 행이 페이지 로드 후 뒤늦게 튀어나오는 문제처럼 기존 모니터가 잡지 못한 사례도 이런 루프에서 발견됐다.
한국 개발자에게 이 사례가 주는 시사점은 명확하다. 에이전트에 성능 개선을 맡기는 일의 병목은 코드 작성 능력이 아니라 측정 설계 능력이다. 노이즈가 큰 wall-clock 대신 결정적 카운터를 CI 게이트로 삼고, 그 카운터가 실제 사용자 체감 시간과 연결된다는 것을 별도로 증명하는 절차가 필요하다. 이번 스프린트에서 3,000건이 넘는 변경이 고객 영향 장애나 롤백 없이 병합된 것은 그 절차 덕분이었다.
다만 전제를 분명히 해둘 필요가 있다. 사용된 Claude Tag는 베타이며, 내부 연구 모델은 Opus 5.5에 준하는 수준이라고 팀은 설명한다. 채널 지침에도 완전 자율은 아직 불가능하다는 단서가 붙어 있었고, 목표 설정과 트레이드오프 판단, 모든 변경 승인은 사람이 담당했다. 즉 이 결과는 사람의 감독 아래에서 측정과 반복을 자동화했을 때 나오는 효율에 대한 사례다.