10월 6일 화요일

에이전트에게 성능 개선을 맡길 때 어떤 측정과 배포 루프가 있어야 실제 사용자 속도가 좋아지는가?

Anthropic의 성능 스프린트는 에이전트에게 막연히 빠르게 만들라고 요청한 사례가 아니다. 앱 실행, 새 대화, 기존 대화 로딩, 제품 간 메시지 전송처럼 사용자 활동의 대부분을 차지하는 여정을 정하고 시작과 종료를 실제 상호작용에 맞춰 계측했다. Claude는 Datadog MCP로 병목을 찾고, 재현 가능한 벤치마크와 PR을 만들고, 기능 플래그 뒤에 배포한 뒤 현장 데이터를 다시 읽었다. 실험실에서 수치가 좋아져도 사용자 지연과 상관하지 않으면 지표를 버렸고, 좋아진 기준선은 CI의 ratchet으로 낮췄다. 이 구조가 있었기 때문에 여러 스레드와 가설을 병렬화하면서도 숫자만 좋아 보이는 변경을 거를 수 있었다.

1. 01

   계측 경계가 틀리면 에이전트는 자신 있게 잘못 최적화한다

   컴포넌트가 렌더된 뒤부터 로딩 완료까지만 재면 사용자가 페이지를 연 순간부터 기다린 시간은 사라진다. 네트워크 요청 수나 React 커밋 수처럼 줄이기 쉬운 값도 최신 데이터 재검증을 없애거나 유용한 작업을 끌 수 있다. 각 벤치마크는 실험실에서 움직일 목표이면서 실제 벽시계 지연과 상관하는지 증명된 가드레일이어야 한다.

2. 02

   결정론적 내부 지표와 현장 데이터를 함께 쓴다

   벽시계 시간은 네트워크와 실행 환경에 흔들리므로 엄격한 CI 게이트로 쓰기 어렵다. 순수 자바스크립트 핫 패스에서는 CPU 명령어 수를 세고, 브라우저에서는 React 커밋, 함수 호출, 레이아웃 재계산, DOM 변경 같은 대체 지표를 사용할 수 있다. 다만 이 수치가 실제 사용자 지연을 줄이는지 확인하고, 불안정하거나 상관이 없는 벤치마크는 폐기해야 한다.

3. 03

   빠른 탐색은 되돌릴 수 있는 배포 경계 안에서만 안전하다

   PR은 자동 리뷰와 사람 승인을 거치고, 고위험 변경은 기능 플래그와 kill switch를 갖춘 뒤 임직원, 1% 사용자, 전체 사용자 순으로 확대됐다. 정적 컴포저는 여러 뷰포트에서 실제 렌더와 픽셀 차이를 확인하고 키 입력 유실도 검사했다. 에이전트의 야망을 키운 것은 과감한 프롬프트 자체가 아니라 단위 테스트, 짧게 사는 플래그, 현장 데이터, 즉시 되돌릴 수 있는 경계였다.

4. 04

   캐시의 속도 이득과 상태 신뢰성을 분리해 검증한다

   로컬 캐시는 사이드바와 선택기를 즉시 보여 주지만 무효화가 늦으면 다른 브라우저에서 삭제한 대화가 남거나 새 스레드가 새로고침 뒤 사라질 수 있다. 초기 체감 속도와 영속화 완료 시점, 서버 재검증, 오래된 데이터 표시 방식을 별도 지표로 가져가야 한다. 한 숫자를 줄인 대가로 사용자가 현재 상태를 오해하게 만들면 성능 개선이 아니다.

에이전트 성능 엔지니어링의 최소 루프는 사용자 여정 정의, 올바른 계측, 재현 가능한 벤치마크, CI 기준선, 점진 배포, 현장 검증, 되돌리기다. 사람은 어떤 경험이 중요한지와 2밀리초 개선이 구조 복잡성을 감수할 가치가 있는지를 결정한다. 에이전트는 그 경계 안에서 병목 탐색과 실험을 확장한다. 이 분업이 없으면 병렬화는 최적화 속도가 아니라 회귀 생산 속도만 높인다.

에이전트가 도구와 코드를 스스로 만들고 장기 작업을 이어 갈 때 어디에 결정론과 통제 지점을 두어야 하는가?

런타임 도구 생성은 고정된 capability가 없는 에이전트가 editor, shell, load_tool을 사용해 필요한 기능을 만들고 같은 실행에서 불러오는 방식이다. 문제는 도구를 만들 수 있느냐보다 운영 중인 코드와 데이터를 어디까지 바꿀 수 있게 할 것인가다. 저장소가 수만 개로 늘면 국소적인 성공만으로 전체 패치가 끝났다고 말할 수 없고, 사람의 승인이나 장애를 기다리는 작업은 프로세스 메모리에만 둘 수 없다. 따라서 자기수정 에이전트의 실행 계층은 최소 권한의 샌드박스, 전체 변경 범위를 보는 코드 그래프와 감사 기록, 외부 호출과 대기를 보존하는 내구성 있는 워크플로로 나뉘어야 한다. 자율성은 이 세 경계가 관찰 가능하고 복구 가능할 때만 확장할 수 있다.

1. 01

   도구 생성은 자유로운 파일 쓰기가 아니라 제한된 capability 확장이다

   Strands 사례는 도구 템플릿과 저장 위치를 system prompt에 명시하고 기존 파일과 기능을 확인한 뒤 새 도구를 만들게 한다. 하지만 에이전트가 파일을 수정하고 삭제할 수 있다는 사실은 실행 환경 샌드박싱, 제한된 도구 목록, 최소 권한, 접근 주체 통제를 요구한다. 최종 답뿐 아니라 목표 달성, 도구 선택, 파라미터, 하위 에이전트 호출 순서와 메시지까지 평가해야 한다.

2. 02

   대규모 변경은 컨텍스트 크기가 아니라 전역 가시성 문제다

   수백만 줄과 수만 개 저장소는 한 번에 복제하거나 컨텍스트 창에 넣을 수 없다. 에이전트는 보이는 코드만 검색하므로 포크, 복사본, 서비스 의존성, 실제 배포 상태를 연결하는 코드 그래프가 필요하다. 비정형 판단이 필요한 곳에는 에이전트를 쓰고 동일한 설정 패치에는 결정론적 스크립트를 사용하며, 저장소별 CI와 PR 결과, 실패와 재시도 기록으로 필요한 위치를 모두 덮었는지 증명해야 한다.

3. 03

   사람의 응답은 블로킹 함수가 아니라 내구성 있는 사건이다

   사람은 수분에서 수주 뒤에 답할 수 있다. 승인 대기를 일반 함수 호출로 두면 재배포나 장애 때 질문과 이전 결과를 잃고 작업을 중복 실행할 수 있다. Temporal은 결정적 단계와 상태를 Workflow에, 모델과 도구 같은 외부 호출을 Activity에 두고, wait condition과 Signal로 늦게 도착한 사람의 답을 기록한다. Worker가 사라져도 Event History를 재생해 마지막 상태에서 이어 간다.

4. 04

   사람 승인도 무조건 많을수록 안전하지 않다

   고가 주문처럼 오판 비용이 큰 단계에는 사람을 넣을 가치가 있지만 모든 동작을 승인하게 하면 경보 피로 때문에 내용 확인 없이 동의하는 흐름이 생긴다. 개입 임계값은 실패 비용과 보안 위험, 사람의 피로를 함께 기준으로 정해야 한다. 승인 대기 중에는 해당 워크플로만 멈추고 다른 작업은 계속 진행되어야 하며, 응답이 없을 때의 시간 제한과 복구 경로도 명시해야 한다.

자기수정과 장기 실행을 허용하는 시스템은 모델 하나로 완성되지 않는다. 생성 가능한 도구의 형식과 권한을 좁히고, 변경할 전체 코드와 배포 상태를 보이게 만들고, 외부 호출·사람의 대기·장애 복구를 워크플로 상태로 남겨야 한다. 그 위에서만 런타임 적응과 대규모 패치를 확대할 수 있다. 구현 검토의 핵심 질문은 에이전트가 무엇을 할 수 있는가가 아니라 어떤 실패를 어디에서 멈추고, 누가 전체 적용과 복구를 증명하는가다.