Anthropic은 8월 2주간의 집중 작업으로 claude.ai와 Claude 데스크톱 앱의 핵심 작업이 약 세 배 빨라졌다고 밝혔습니다. 9월 23일 공개한 엔지니어링 보고서에서는 제목의 숫자만 보는 것보다 더 유용한 내용을 확인할 수 있습니다. 어떤 동작이 빨라졌는지, 팀이 측정값을 어떻게 점검했는지, 의사결정과 출시에서 엔지니어가 어떤 책임을 맡았는지를 보여줍니다.

달라진 점

  • 바뀐 점: Anthropic은 웹과 데스크톱에서 자주 쓰는 동작 13개의 대기 시간이 줄었다고 보고합니다. 3.1배라는 수치는 8월 13일과 27일의 75백분위수 측정값을 바탕으로 한 기하평균입니다. 회사가 선택한 사용자 여정에서 나온 결과입니다.
  • 중요한 이유: Claude 사용자는 새 웹 페이지에서 입력할 수 있을 때까지 걸리는 시간이 3,085밀리초에서 550밀리초로 줄면 제품을 반복해서 쓰는 과정에서 차이를 느낄 수 있습니다. 엔지니어링 팀에는 이 사례가 AI 비서로 측정된 성능 문제를 해결하면서도 사람이 우선순위를 정하고 변경 사항을 승인하는 방식을 보여줍니다.
  • 지켜볼 점: Anthropic은 95백분위수와 다른 사용자 여정, 매우 긴 대화는 여전히 개선이 필요하다고 말합니다. 이러한 측정값을 보면 보고된 개선이 선택된 동작과 8월 비교를 넘어 확장되는지 확인할 수 있습니다.

사용자가 얻은 개선

Anthropic은 앱 실행, 대화 시작, 대화 불러오기, 메시지 전송 등 네 가지 사용자 여정이 전체 활동의 95%를 차지한다고 파악했습니다. 이 여정을 웹과 데스크톱, 각 제품에 걸쳐 13개의 측정 항목으로 나눴습니다. 각각 사용자 동작에서 시작해 결과가 화면에 표시될 때 끝났으며, 클라이언트 작업과 서버 작업을 구분했습니다.

새 claude.ai 웹 페이지가 입력 가능한 상태가 될 때까지 걸리는 75백분위수 시간은 3,085밀리초에서 550밀리초로 줄어 5.6배 빨라졌습니다. 데스크톱 앱을 완전히 종료한 상태에서 시작하는 데 걸리는 시간은 6,310밀리초에서 3,328밀리초로 줄어 1.9배 개선됐습니다. 데스크톱에서 Claude Cowork 클라우드 세션을 불러오는 시간은 2,566밀리초에서 728밀리초로 줄어 3.5배 빨라졌습니다. 웹 채팅 메시지 전송 중 클라이언트 측 작업은 180밀리초에서 59밀리초로 줄어 3.1배 개선됐습니다. 서로 다른 동작과 플랫폼을 측정한 값이며, 전체 3.1배는 13개 비율의 기하평균이지 어느 한 작업의 결과가 아닙니다.

비교에는 Anthropic의 실제 사용자 모니터링에서 8월 13일과 27일에 측정한 75백분위수 값이 쓰였습니다. 게시물에는 독립적인 감사 결과, 이 사용자 여정의 95백분위수 값, 개선 중 Claude의 지원이 기여한 정도를 통제해 추정한 결과가 없습니다. Anthropic은 동작이 빨라져 사용자의 대기 시간이 매일 수만 시간 절약된다고 추산하지만, 그 추산의 계산 과정은 공개하지 않았습니다.

변화를 만든 측정 과정

팀은 엔지니어들이 고른 약 20개 프로젝트부터 시작했습니다. Anthropic에 따르면 내부 연구 모델을 사용하는 베타 에이전트 Claude Tag를 활용해 병목 지점을 찾고, 벤치마크를 만들고, 변경안을 제안했습니다. 이 모델은 대략 Opus 5.5에 필적하는 수준이라고 설명했습니다. 팀은 사흘째까지 초기 목표 13개 중 12개를 달성했다고 밝혔습니다. 이후 새 목표를 세우고 기존 모니터가 놓친 문제를 찾았습니다.

한 사례는 페이지가 로드된 뒤 사이드바의 행들이 움직이는 모습을 녹화한 데서 시작했습니다. 기존 Cumulative Layout Shift 지표는 이 문제를 두드러지게 나타내지 못했습니다. 한 엔지니어가 기반이 되는 Layout Instability API를 쓰자고 제안했습니다. 이어 Claude가 영향을 받은 페이지 영역을 식별하는 텔레메트리와 사이드바 데이터 처리를 지연시키는 통합 테스트를 추가했습니다. Anthropic에 따르면 원래 코드에서는 20회 실행 모두 테스트에 실패했고, 제안된 수정안을 적용한 뒤에는 20회 모두 통과했습니다. 텔레메트리를 배포한 뒤 회사는 웹 페이지 로드의 31%에서 사용 가능 상태가 된 후에도 화면 요소가 움직이는 문제를 발견했다고 밝혔습니다. 이는 Anthropic의 집중 작업에서 문서화한 사례이며 BIG CHANGE가 재현해 측정한 결과는 아닙니다.

팀은 출시 사이의 작업 속도를 높이기 위해 실험실 측정값도 사용했습니다. 두 JavaScript 핫 패스에서 동일한 벤치마크를 바탕으로 결정론적 명령어 수와 실제 경과 시간을 비교했습니다. Anthropic은 명령어 수가 48%와 31% 줄어든 동시에 실제 경과 시간도 각각 78%와 44% 감소했다고 보고합니다. 팀은 CI에서 해당 명령어 수를 상한으로 설정하고 성능이 개선될 때마다 상한을 더 낮췄습니다. 신뢰하기 어렵거나 사용자 지연 시간을 제대로 반영하지 못하는 벤치마크는 제외했다고 합니다. 이 구분이 중요합니다. 실험실 측정값은 변경을 이끄는 데 쓰였고, 실제 사용자 측정값으로 배포된 작업이 도움이 됐는지 확인했습니다.

사람이 계속 통제한 부분

Anthropic에 따르면 팀은 각각 특정 사용자 여정이나 벤치마크를 다루는 세분화된 스레드가 많은 Slack 채널을 운영했습니다. Claude는 문제를 추적하고 벤치마크와 풀 리퀘스트를 제안했으며 배포 과정을 살피고 현장 데이터를 읽었습니다. 엔지니어들은 목표를 정하고 사용자에게 보이는 절충안이 허용 가능한지 판단하고 모든 변경을 승인했습니다. 각 스레드에는 이름이 지정된 담당자가 있었습니다. 메시지마다 2밀리초를 절약하는 대가로 유지보수 부담이 너무 커진다고 판단해, 엔지니어들은 900줄짜리 변경안 하나를 거절했습니다.

출시 과정에는 여러 단계의 점검이 있었습니다. Anthropic에 따르면 모든 풀 리퀘스트는 자동 검토와 최소 한 명의 사람 승인, 최적화에 앞선 단위 테스트를 거쳤습니다. 사용자가 볼 수 있는 변경은 수명이 짧은 기능 플래그 뒤에 뒀습니다. 위험이 높은 변경은 먼저 직원에게 배포한 다음 사용자 1%, 이후 전체 사용자에게 확대했습니다. 집중 작업 기간에 플래그를 거의 200개 도입했고, 종료할 때는 절반 넘게 제거했다고 합니다. Anthropic은 고객이 겪는 사고나 롤백 없이 3,000건 넘는 변경 사항을 병합했다고 보고합니다. 이는 이번 집중 작업에 대한 회사의 설명이며, 다른 팀이나 코드베이스에서도 같은 결과가 난다는 점을 입증하지는 않습니다.

정적 작성창 사례는 통제 절차가 중요한 이유를 보여줍니다. Anthropic은 React가 로드되는 동안 입력 가능한 작성창을 초기 HTML에 넣었습니다. 이양 과정이 제대로 되는지 확인하기 위해 테스트에서 화면 크기 14종에 걸쳐 정적 버전과 React 버전을 비교하고, 정렬 오차를 1픽셀 이내로 점검했으며, 전환 중 키 입력이 사라지거나 순서가 바뀌지 않는지 직접 입력해 확인했습니다. 실제 운영 텔레메트리는 이양 중 화면 요소의 움직임을 측정했습니다. 이후 한 직원이 해당 측정에서 놓친 새 탭의 레이아웃 움직임을 발견했습니다. Anthropic은 예상 로딩 중 브라우저 크기가 바뀌는 것이 원인이라고 추적하고 그 경로를 대상으로 테스트를 추가했습니다.

Anthropic의 보고서가 뒷받침하는 결론은 구체적입니다. 엔지니어들은 사람이 주도하는 출시 절차 안에서 Claude를 이용해 측정된 병목을 찾고 개선했으며, 8월 말에는 선택한 사용자 여정의 속도가 빨라졌습니다. 반면 느린 구간의 끝에서 제품이 어떻게 작동하는지, 개선 효과가 얼마나 지속될지, 결과 중 얼마를 팀의 계측·엔지니어링·출시 결정이 아니라 에이전트의 몫으로 볼 수 있을지는 여전히 밝혀지지 않았습니다.