Claude가 측정할 수 있는 것은 더 빠르게 만들 수 있습니다

AI 요약

Anthropic은 지난 8월 2주간 claude.ai와 Claude 데스크톱 앱의 주요 사용자 경험을 개선했습니다. 사용량의 95%를 차지하는 네 가지 여정을 우선 대상으로 삼았고, 새로고침 뒤 입력 가능한 페이지가 나타나는 시간, 새 Claude Code 세션 시작 시간, Claude Cowork 클라우드 세션 로딩 시간 등을 측정했습니다. 75백분위 기준으로 각각 3.1초에서 0.55초, 0.8초에서 0.3초, 2.6초에서 0.73초로 줄었습니다. Anthropic은 이 개선으로 매일 수만 시간의 대기 시간을 아낀다고 추산합니다.

측정 가능한 목표를 먼저 만들었습니다

팀은 Datadog MCP 서버로 사용 데이터를 살펴본 Claude의 제안을 바탕으로 앱 실행, 대화 시작, 기존 대화 불러오기, 메시지 전송을 주요 여정으로 정했습니다. 웹과 데스크톱, 제품별로 나뉜 13개 측정 항목을 만들고, 사용자 동작부터 결과 렌더링까지 걸리는 시간을 비교할 수 있도록 계측을 보완했습니다. 처음에는 약 20개 프로젝트를 골라 목표를 세웠지만, 사흘 만에 13개 목표 중 12개를 달성했습니다.

빠른 첫 화면을 위해 HTML에 정적 입력창을 넣어 React 초기화 중에도 입력할 수 있게 했습니다. 데스크톱 셸은 V8 코드 캐시를 미리 만들어 메인 프로세스의 재컴파일을 줄였습니다. 화면 이동 때 입력창을 유지하고, 사용자가 대화 목록에 마우스를 올리면 세션을 미리 가져왔습니다. 사이드바 재렌더링 횟수도 90% 줄였습니다.

실험실 지표를 CI 회귀 방지로 연결했습니다

실사용 환경의 시간 측정은 노이즈가 있어 CI 기준으로 삼기 어렵습니다. 팀은 명령어 수, V8 호출 수, React 커밋, 스타일 재계산, DOM 변경처럼 실험실에서 반복 측정할 수 있는 지표를 살폈습니다. 새 벤치마크는 두 조건을 충족해야 했습니다. Claude가 실험실에서 개선할 수 있어야 하고, 실제 사용자 대기 시간 개선과 연결된다는 점도 입증해야 했습니다. 그렇지 않은 벤치마크는 버렸습니다.

대화 메시지 트리를 만드는 경로와 Claude Code 출력의 상태 줄을 찾는 경로를 Valgrind로 분석한 결과, 첫 경로에서 명령어의 4분의 1이 같은 메시지 ID를 세 번 조회하는 다형성 사전 검색에 쓰였습니다. Claude는 두 경로의 명령어 수를 각각 48%, 31% 줄였고, 벽시계 시간은 78%, 44% 줄었습니다. 팀은 이 수치를 CI의 회귀 방지 기준으로 추가했습니다. 측정값이 낮아지면 일일 작업이 기준을 더 엄격하게 조정하고, 이후 PR이 수치를 올리면 CI가 실패합니다.

사용자가 느끼는 문제도 새로 측정했습니다

기존 지표로 잡히지 않던 화면 흔들림을 찾은 사례도 있습니다. 사이드바 항목이 페이지 사용 가능 시점 뒤에 늦게 나타났지만, 각 화면 이동은 누적 레이아웃 이동(CLS) 기준에서 작은 값에 그쳤습니다. Claude는 Layout Instability API를 활용해 이동 원인을 사이드바나 대화 기록 같은 영역, 첫 페인트 전후 같은 시점으로 분류하는 이벤트와 통합 테스트를 만들었습니다. 테스트는 메인 브랜치에서 20회 모두 실패하고 수정 브랜치에서 20회 모두 통과했습니다. 배포 후 실제 페이지 로드의 31%에서 사용 가능 시점 이후 사용자 동작 없이 화면 요소가 이동한다는 사실도 확인했습니다. 팀은 늦게 뜨는 헤더, 사용자 이름이 로드된 뒤 움직이는 커서, 스크롤바가 나타날 때 밀리는 목록 등을 차례로 고쳤습니다.

성능 개선은 하루 150개가 넘는 스레드에서 진행됐고, 개별 스레드가 최적화 PR을 50~100개 만들기도 했습니다. 긴 답변을 스트리밍할 때는 프레임별 시간을 측정해 완료된 코드 블록을 메모이제이션하고, 커지는 코드 블록의 토큰화를 워커로 옮겼습니다. 표는 셀 단위로 표시했습니다. 해당 스레드에서는 PR을 약 60개 병합했고, 긴 답변이 메인 스레드를 막는 시간을 약 750ms에서 200ms로 줄였습니다. CPU 사용량은 약 3분의 1로 낮아졌고, 120Hz MacBook에서 스트리밍 내내 초당 120프레임을 유지했습니다.

사람은 방향과 안전을 맡았습니다

이 작업은 자율적으로 진행되지 않았습니다. 모든 PR에는 자동 리뷰와 최소 한 명의 사람 승인이 필요했고, 최적화 전에 단위 테스트를 작성했습니다. 사용자에게 보이는 변화는 전후 스크린샷이나 녹화 영상으로 담당자가 확인했습니다. 위험한 변경은 짧게 유지하는 기능 플래그 뒤에 넣고, 직원 대상 배포와 1% 사용자 배포를 거쳐 전체에 적용했습니다. 2주 동안 기능 플래그를 약 200개 만들었고, 절반 이상은 종료 시점 전에 정리했습니다.

팀은 목표를 달성해도 최적화를 멈추지 않도록 Claude를 독려했고, 작업 범위를 한 벤치마크나 사용자 여정으로 좁혔습니다. 다만 속도와 복잡성 사이의 선택, 사용자에게 보이는 변화의 적절성, 작업 우선순위는 사람이 결정했습니다. 900줄짜리 PR이 전송 한 번당 2ms를 줄이지만 유지보수 복잡도를 높인다고 판단해 거절한 사례도 들었습니다. Anthropic은 전체 작업에서 고객 대상 장애나 롤백 없이 3천 건이 넘는 변경을 병합했다고 밝혔습니다.

Hacker News 반응

• @sonar_un — 정말 훌륭한 글입니다. 자기 프로젝트에도 쓸 만한 정보가 많이 들어 있습니다.
• @minimaxir — 이 글은 제가 월요일에 올린 ‘에이전트에게 제약을 둬 코드를 빠르게 만들고 에이전트가 망가뜨리지 않게 하는 법’ 글과 우연히 내용이 맞아떨어집니다. 프런트엔드 UI 최적화는 엄격한 알고리즘 최적화보다 까다롭지만, 시각적 회귀를 추적하는 도구를 에이전트에게 만들게 하는 프롬프트면 충분하다는 걸 알았습니다. 적어도 GPT 모델은 패딩, 여백, 음수 공간을 명확히 지시해야 합니다. 다만 이제 에이전트가 잘 다루게 된 만큼, 새 프런트엔드 프로젝트에서는 프런트엔드 JS 프레임워크 대신 HTML/CSS/순수 JS만으로 어디까지 빠르게 할 수 있는지 시험하고 있습니다.
• @applfanboysbgon — 느린 쓰레기 소프트웨어를 만들어 첫 화면이 안정될 때까지 4.38초 걸리게 한 다음, 나중에 ‘최적화’해 좋은 성과처럼 내세우면 된다는 요약이군요.
  • @Daishiman — 대부분의 업무용 소프트웨어에는 최적화할 부분이 많습니다. 성능 개선에 쓸 시간을 기능 개발에서 빼지 않고도 빠르게 만들 수 있다는 점은 정말 괜찮습니다.
  • @applfanboysbgon — 텍스트를 표시하는 데 5초씩 걸리지 않게 만드는 것도 기능입니다. 당신이 추가하려는 다른 형편없는 기능보다 열 배는 더 가치 있습니다. 사용자와 사업에 실제로 가치가 있습니다. Google은 지연이 100ms 늘 때마다 사용량과 유지율이 달라진다는 사실을 대규모 연구로 이미 보여줬습니다.
• @smy20011 — Claude가 한 방식은 엔트로피로 엔트로피와 싸우는 것 같습니다. “HTML에 정적 입력창을 넣었다”는 건 SSR로 해결할 수 있어 보입니다. “대화 사이에 입력창을 유지했다”는 건 SPA가 페이지 사이에서 입력창을 캐시해야 하는 일입니다. 아니면 React 컴포넌트 라우팅을 개선해야 합니다. 개별 벤치마크에 집중하면 더 큰 기회를 놓칠 수 있습니다. SSR이나 청크 단위 렌더링처럼 기본 구조를 다시 볼 필요가 있습니다.
• @rustystump — 성능 향상에 비해 복잡성이 늘어난 점이 우울합니다. Chrome 디버거로 5분쯤 살펴보면 사람이 더 나은 결과를 내고, 복잡성도 비용도 Claude를 돌보는 시간도 훨씬 줄일 거라고 확신합니다. 글을 읽으면 작성자들이 웹 성능을 제대로 최적화하는 기본 지식이 부족하다는 인상을 받습니다.
  • @theolivenbaum — 복잡한 시스템에서는 코드를 최적화하는 데 큰 노력이 들고, 결과가 없을 수도 있습니다. 이런 작업을 수백 번 해 본 입장에서, 며칠 일한 결과를 전부 버려야 할까 봐 두려워하지 않고 아이디어를 시험할 수 있다는 점은 해방감을 줍니다. 다만 제대로 된 방향을 제시하는 일은 여전히 중요합니다.
• @RomanKornev — 벤치마크 기준을 계속 낮춘 뒤 코드가 얼마나 읽기 어려워졌는지가 가장 궁금합니다. 루프를 풀어 쓰면 빨라질 수 있지만, 그런 코드를 바꾸기는 지저분합니다. 이 때문에 전체 배포 속도가 느려지지는 않을까요? 측정하지 않는 것은 희생될 수 있으니, 모델 학습의 과적합과 같은 문제일 수도 있습니다.
• @augment_me — GPU 커널 커뮤니티는 이런 방식을 약 1년 전부터 효율적으로 써 왔습니다. 문제는 손쉬운 개선이 사라지면 Claude가 보상 해킹을 한다는 점입니다. 측정 도구를 바꾸고, 라이브러리 함수를 덮어쓰고, 실제 환경에서는 통하지 않을 캐시를 쓰거나 측정되지 않는 별도 경로로 계산할 수 있습니다. 그래서 “측정할 수 있으면 빨라진다”기보다는 목표를 자세히 정의하고, 측정 도구를 속이는 행동을 금지해야 빨라진다고 봅니다.
• @simonw — 얼마 전 노트북을 모바일 테더링에 연결해 claude.ai에 접속했는데, 생각보다 빨리 로드돼서 기분이 좋았습니다. 다만 Firefox에서 확인해 보니 JavaScript가 20.78MB였고 압축하면 6.84MB였습니다. 계속 다듬으면 훨씬 가벼워질 것 같습니다.
• @geroge_kyaw — 죄송하지만 큰 차이를 모르겠습니다. TTFT와 ITL을 더 빠르게 만들면 더 인상적일 것 같습니다.
• @tecoholic — 좋습니다. 이제 메모리 사용량도 최적화해 주시겠어요? 이미지와 애니메이션, 임베드를 넣은 이 블로그 글은 Firefox 탭에서 167MB를 쓰고, 대화가 없는 claude.ai 페이지는 297MB를 씁니다. 아이콘 몇 개와 글자가 있는 입력창치고는 정말 큰 사용량입니다. Threads를 연 Slack 탭은 239MB입니다. 네, 대화도 없는 Claude 페이지보다 Slack이 메모리를 덜 씁니다.
• @felineflock — Claudehart의 법칙입니다. 측정값을 지표로 정하면 Claude가 그 지표를 공략하기 시작합니다.
• @mentalgear — 그러면 소프트웨어를 최적화해서 구형 하드웨어에서도 다시 실행할 수 있겠네요?

원문: Anthropic / 번역·요약: Trawling