TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 29 READS

AI가 벤치마크를 만들고 최적화까지: claude.ai를 2주 만에 3배 빠르게 한 방법

AI가 벤치마크를 만들고 최적화까지: claude.ai를 2주 만에 3배 빠르게 한 방법
SOURCE IMAGE · HACKER NEWS

소프트웨어 성능 개선의 오랜 병목은 코드가 아니라 측정이었다. 문제를 이해하려면 먼저 계측을 심고, 데이터가 쌓일 때까지 기다린 뒤에야 원인 분석을 시작할 수 있었기 때문이다. Anthropic이 공개한 사례는 이 순서를 뒤집는다. 이 회사는 지난 8월 두 주 동안 claude.ai 웹과 데스크톱 앱의 핵심 사용자 경험을 약 3배 빠르게 만들었고, 그 과정의 상당 부분을 Claude가 스스로 측정 지표를 만들고 개선하는 방식으로 진행했다고 밝혔다. 이들은 단일 슬랙 채널에서 모든 작업을 운영했고, 3,000건이 넘는 변경을 병합하는 동안 고객이 겪은 장애나 롤백이 한 건도 없었다고 설명한다.

무엇을 얼마나 빠르게 했나

작업은 전체 사용자 활동의 95%를 차지하는 네 가지 여정, 즉 앱 실행, 대화 시작, 기존 대화 불러오기, 메시지 전송에 집중했다. 75백분위 기준으로 claude.ai를 새로 열었을 때 입력 가능한 화면이 뜨기까지 걸리는 시간은 3.1초에서 0.55초로, 새 Claude Code 세션 시작은 0.8초에서 0.3초로, Claude Cowork 클라우드 세션 로딩은 2.6초에서 0.73초로 줄었다. 회사는 이 개선이 하루 수만 시간의 대기 시간을 절약하는 수준이라고 추산한다. 웹과 데스크톱, 여러 제품을 합치면 이들 여정은 13개의 개별 측정으로 나뉘었는데, 각 측정은 사용자 조작에서 시작해 결과가 화면에 그려질 때 끝나도록, 그리고 클라이언트 작업과 서버 작업을 구분하도록 계측을 손봤다.

실제로 적용한 기법은 낯설지 않다. 실행 속도를 위해 HTML에 정적 입력창을 미리 심어 React가 초기화되는 동안에도 사용자가 타이핑할 수 있게 했고, 데스크톱 셸의 메인 프로세스가 매번 재컴파일하지 않도록 V8 코드 캐시를 미리 만들어 두었다. 화면 전환을 위해서는 대화 사이에도 입력창을 마운트된 상태로 유지하고, 사용자가 항목 위에 마우스를 올리면 세션을 미리 가져왔으며, 사이드바 리렌더링을 90% 줄였다. 처음 손으로 고른 약 20개 프로젝트 중 대부분의 목표를 사흘째에 달성했다고 한다.

측정을 만들면 개선이 가능해진다

이 사례의 핵심 통찰은 측정 방식 자체에 있다. 벽시계 시간은 사용자가 실제로 체감하는 값이지만 잡음이 많고 밀리초 단위는 CI 게이트로 쓰기엔 너무 불안정하다. 그래서 실험실에서 결정론적으로 잴 수 있는 대체 지표를 찾았다. 순수 JS 핫패스는 Valgrind와 node --predictable 옵션으로 명령어 실행 횟수를 세어 체크인된 기준값과 비교했고, 브라우저 경로에서는 상호작용당 React 커밋 수, V8 정밀 커버리지의 함수 호출 수, 레이아웃·스타일 재계산 횟수, DOM 변경 수 같은 결정론적 카운트를 사용했다. 명령어를 48%, 31% 줄인 두 핫패스에서 실제 벽시계 시간이 각각 78%, 44% 감소하는 것을 확인한 뒤, 이 카운트를 CI의 상한선으로 고정했다.

다만 이들은 새 벤치마크를 무조건 신뢰하지 않았다. 각 지표는 두 가지 역할을 해야 했다. 하나는 실험실에서 Claude가 움직일 수 있는 수치여야 하고, 다른 하나는 값이 나빠지는 방향의 변경을 막는 CI 가드레일이어야 했다. 벤치마크가 불안정하거나 실제 사용자 지연과 상관관계가 없으면 그대로 폐기했다. 잘못된 언덕을 오르는 것을 막기 위해서다. 측정이 데이터를 기다리는 '0단계'가 아니라 최적화가 시작되는 '1단계'가 되자, 가장 큰 지렛대는 더 많은 측정 대상을 찾아내는 일이 되었다.

그렇게 파고든 결과 평소 감지되지 않던 문제들이 드러났다. 페이지가 사용 가능해진 뒤에도 웹 로드의 31%에서 무언가가 움직였는데, 기존의 누적 레이아웃 이동 지표로는 각 이동 점수가 0.008에 불과해 양호 기준인 0.1을 한참 밑돌아 잡히지 않았다. 이를 잡기 위해 Layout Instability API를 직접 참조해 이동의 출처를 영역과 단계별로 이름 붙인 계측을 만들었다. 그 밖에도 입력 경로에서 키 입력마다 리렌더링되던 6,900개의 훅과 900개의 스토어 구독, DOM 변경마다 24밀리초를 더하던 :root:has() 선택자 하나, 하루 50만 건의 숨은 새로고침을 일으키던 잔존 location.reload() 호출 등이 발견됐다. 코드 블록에 em 대시나 둥근 따옴표 같은 비Latin-1 문자가 하나라도 있으면 V8이 문자열 전체를 UTF-16로 저장해 구문 강조 정규식이 느린 경로를 타던 문제는 코드 블록을 1바이트 문자열로 복사하는 20줄 변경으로 해결했다.

한국 실무자가 새겨둘 지점

이 사례는 화려한 결과만큼이나 안전장치가 인상적이다. 거의 모든 작업이 첫 페인트, 입력창, 대화 화면 같은 핫패스였던 만큼 사전에 방어선을 세웠다. 모든 PR은 자동 리뷰와 최소 한 명의 사람 승인을 거쳤고, 최적화보다 단위 테스트가 먼저 들어갔으며, 사용자에게 영향을 줄 수 있는 변경은 수명이 짧은 기능 플래그 뒤에서 배포됐다. 2주간 약 200개의 플래그를 도입했고 그중 절반 이상은 기간이 끝나기 전에 정리했다. 고위험 변경은 사내, 사용자 1%, 전체 순으로 점진 배포했다.

동시에 이 사례를 그대로 일반화하기는 어렵다는 점도 분명하다. Anthropic은 자사 제품에, Opus 5.5에 견줄 만한 내부 연구 모델과 Datadog MCP 같은 성숙한 관측 인프라, 그리고 채널에서 실시간으로 판단을 내리는 다수의 엔지니어를 갖춘 상태에서 이 실험을 돌렸다. 사람이 목표를 정하고 트레이드오프를 조율하며 모든 변경을 승인했다는 점, 그리고 회사 스스로 '완전한 자율은 아직 불가능하다'고 못 박은 점도 눈여겨볼 만하다. 그럼에도 실무에 옮길 교훈은 명확하다. 자동화된 최적화의 성패는 모델의 영리함보다 신뢰할 수 있는 결정론적 지표와 촘촘한 가드레일에 달려 있으며, 무엇을 측정할 수 있게 만드느냐가 곧 무엇을 개선할 수 있느냐를 결정한다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://claude.dev/blog/how-we-made-claude-ai-faster/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...