3,000건 변경, 2주, 사고 0건

메시지 전송 지연이 928ms에서 48ms로 줄었다. 새로 고침 후 첫 화면은 3,085ms에서 550ms다. Anthropic이 9월 23일 공개한 사후 보고서의 숫자다.

이 속도 개선을 만든 주체가 흥미롭다. 엔지니어가 병목을 하나씩 찾은 게 아니라 Claude가 병목을 찾고 고치고 배포 후 데이터까지 확인했다. 2주 스프린트 동안 병합된 변경은 3,000건 이상이고 고객에게 드러난 사고와 롤백은 없었다고 한다.

한 줄 정리

Anthropic이 자사 앱의 속도 개선을 Claude에게 맡겨 2주 만에 평균 3.1배 빠르게 만들었고, 이는 AI에게 일을 넘기는 열쇠가 모델 성능보다 측정 지표라는 사례다.

한눈에 보기

다섯 구간의 기하평균이 3.1배다.

사람이 한 일은 셋뿐이었다

보고서가 밝힌 구조는 이렇다. 슬랙 채널 하나에 상시 지침을 두고 150개 넘는 스레드를 동시에 돌렸다. 엔지니어는 느린 구간의 녹화본이나 증상을 스레드에 올린다. Claude가 흐름을 추적해 벤치마크를 만들고 위험도별로 쪼갠 수정안을 기능 플래그 뒤에 올린다. 배포 뒤에는 현장 텔레메트리를 보고 기준선을 더 조인다.

사람 몫은 야심, 취향, 방향으로 정리된다. 한 엔지니어는 Claude에게 "더 과감해져라"고 주문했다. 눈에 보이는 변경은 이름 붙은 담당자가 스크린샷과 영상으로 직접 확인했다. 스레드마다 범위를 좁게 유지한 것도 사람이 한 일이다.

사용한 모델은 Claude Tag 베타에 붙은 내부 연구용 모델로, Opus 5.5에 견줄 만하다고 소개됐다. 그러니 이 결과를 지금 시판 모델로 그대로 재현할 수 있다고 읽으면 과하다.

안전장치가 속도만큼 무거웠다

변경 3,000건이 사고 없이 들어간 이유는 모델의 신중함이 아니라 절차다. 사용자에게 보이는 변경은 전부 기능 플래그를 달았고 롤아웃은 직원, 사용자 1%, 전체 순으로 갔다. 화면 배치가 흔들리지 않는지 픽셀 단위로 비교하는 테스트와 밤마다 도는 프레임레이트 점검이 붙었다. 스프린트 중 도입한 플래그가 200개에 가까웠고 끝날 즈음 절반 넘게 정리됐다.

가장 눈에 띄는 대목은 측정이다. 보고서는 "측정할 수 있으면 다룰 수 있다"는 취지로 교훈을 적었다. 레이아웃이 튀는 비율(웹 로드의 31%)이나 명령어 수 같은 새 지표가 생기자 Claude가 알아서 그 숫자를 내렸다. 지표가 없던 때는 사람이 감으로 지시했다.

anyAX 관점

이 사례를 개발자 이야기로만 읽으면 반쯤 놓친다. 콘텐츠 팀이 일주일 뒤 같은 일을 하려면 무엇이 필요한지가 진짜 내용이다.

Anthropic은 "빠르게 해 줘"라고 시키지 않았다. 5.6배, 19배 같은 숫자가 나온 건 구간마다 p75 지연이라는 잣대를 먼저 세웠기 때문이다. 팀의 블로그 발행 주기나 뉴스레터 제작 시간, 광고 소재 승인 대기 일수는 아직 숫자로 잡혀 있지 않은 경우가 많다. AI에게 넘기기 전에 이 숫자부터 만드는 게 첫 작업이다.

두 번째는 사람의 자리다. 이 스프린트에서 사람은 손을 뗀 게 아니라 결과물의 취향을 판정하는 쪽으로 옮겨 갔다. 소규모 팀이라면 담당자 한 명을 "이 결과가 우리 기준에 맞는가"를 보는 자리로 지정하는 게 순서다. 실행 100건을 AI가 하더라도 승인 한 줄은 이름 있는 사람에게 남아야 한다.

세 번째는 롤아웃이다. 직원, 1%, 전체로 가는 단계를 마케팅에 옮기면 사내 검수, 소규모 세그먼트 발송, 전체 발송이다. 자동화 속도는 이 세 칸의 통과 속도에 묶인다.

참고

• How we made claude.ai 3x faster in two weeks (Anthropic 엔지니어링 블로그)
• Claude.ai is about 3x faster after 3,000+ changes (Help Net Security)