마이크로소프트, 코파일럿 에이전트 분석 논문 공개

핵심 발견은 코딩 에이전트가 챗봇과 다른 종류의 부하라는 거예요. 저자들에 따르면 사용자가 메시지 하나를 보내면 에이전트는 평균 6.6번의 LLM 호출을 스스로 이어 가고, 전체 LLM 호출의 87%가 사용자가 아니라 에이전트가 시작한 것이었어요. LLM 호출과 도구 실행의 비율은 세션당 평균 40.6 대 43.6으로 거의 1 대 1이에요. 논문은 "에이전트 루프는 LLM과 도구의 엄격한 1 대 1 결합을 강제한다. 서빙 시스템은 LLM 호출과 그에 대응하는 도구 호출을 독립된 요청이 아니라 서로 의존하는 쌍으로 다뤄야 한다" 라고 적었어요.

세션의 크기는 극단적으로 치우쳐 있어요. 중앙값 세션은 사용자 턴 3개, LLM 호출 15번, 4.2분이지만 평균은 턴 6.1개, 호출 40.6번, 62.6분이고, 상위 10% 세션은 사용자 턴 15개와 LLM 호출 100번을 넘기며 세 시간 넘게 이어져요. 토큰 비대칭은 더 심해서 LLM 호출 한 번의 프롬프트 토큰 중앙값은 6만8천 개인데 출력 토큰 중앙값은 247개라 입력 대 출력 비율이 275 대 1을 넘어요. 프롬프트의 48%는 대화 이력이고 28%는 도구 호출 결과이며 시스템 프롬프트는 14%에 그쳐요. 맥락이 커지는 이유는 지시문이 아니라 에이전트 자신의 지난 추론과 행동이에요.

엔지니어 눈에 가장 실용적인 대목은 KV 캐시의 생애주기예요. 한 턴 안에서 프리픽스 캐시 적중률은 첫 호출 45%에서 두 번째 호출 86%로 뛰고 세 번째부터 92~94%에 안착해요. 그런데 사용자가 다음 메시지를 보내는 턴 경계에서는 평균 26%포인트가 빠져 55%까지 내려가고, 턴 사이 유휴 시간이 10분을 넘으면 적중률 중앙값이 0~5%로 무너져요. 모델을 바꾸면 더 심해서 전환 직후 적중률은 8%예요. 모델 전환은 세션의 약 6.4%에서 일어나는데 대부분 오류나 속도 제한에 반응한 것이었고, 사용자가 수동 선택을 자동 모드로 넘길 때는 52%가 더 싼 모델로 내려가는 전환이었어요.

맥락 압축은 숨은 비용이에요. 맥락 창이 차면 에이전트가 이력을 요약해 프롬프트를 다시 쓰는데, 이 일은 전체 세션의 7.8%에서만 일어나지만 그 세션들이 전체 토큰의 44.2%와 LLM 호출의 37.1%를 차지해요. 압축 한 번에 프롬프트 토큰의 중앙값 72.8%가 사라지고 캐시 적중률은 중앙값 66.1%포인트 떨어지며, 압축 호출 자체가 턴 실행 시간의 중앙값 22%를 먹어요. 저자들은 압축을 모델 전환과 같은 급의 캐시 초기화 사건으로 분류했어요. 가장 극단적인 세션은 압축이 40번 일어났어요.

도구 실패는 비용을 곱해요. 논문에 따르면 턴의 9%에서 도구 실패가 일어나고, 그러면 에이전트가 맥락을 키워 가며 스스로 재시도 루프를 돌아 연산량이 최대 4배로 불어나요. 실패가 낀 깊은 루프 턴은 전체의 9.1%인데 LLM 호출이 36번으로 중앙값의 네 배예요. run_command와 run_build, edit_file은 성공률이 73% 안팎까지 떨어지고, 터미널 명령은 실패했을 때 상위 5% 기준으로 성공했을 때보다 48배 오래 걸려요. 빌드가 실패하면 성공했을 때보다 7~8배 많은 토큰이 컴파일러 진단으로 맥락에 들어와요. 도구 하나인 get_file이 전체 도구 호출의 35%를 차지한다는 사실도 같은 표에 있어요.

사용자도 한 종류가 아니에요. 저자들은 사용자를 다섯 유형으로 나눴는데 읽기 위주 41.7%, 코더 30.4%, 터미널 사용자 11.0%, 깊은 루프 사용자 9.2%, 채팅 전용 7.6%예요. 턴당 토큰은 채팅 전용의 2만3천 개에서 깊은 루프 사용자의 110만 개까지 50배 차이가 나요. 캐시가 한 번 비워지면 깊은 루프 사용자는 110만 토큰을 다시 채워야 하고 채팅 전용 사용자는 2만3천 개면 돼요. 같은 캐시 만료 시간을 모두에게 적용하면 가장 무거운 사용자가 가장 큰 지연 세금을 낸다는 게 저자들의 계산이에요. 주말 세션은 수는 적지만 더 길고 호출이 많아서, 저자들은 개발자들이 방해받지 않을 때 더 야심 찬 작업을 맡기는 것 같다고 해석했어요.

이 구조에서 자원을 되찾을 신호는 턴 경계예요. 턴 안에서 컨테이너와 KV 캐시의 유휴 시간 중앙값은 각각 5.8초와 1.2초라 회수할 틈이 없지만, 턴 사이에서는 243초와 172초로 수십 배에서 백 배 넘게 길어지고 사용자가 다음 메시지를 보내기까지의 유휴 시간 중앙값은 25.2분이에요. 저자들은 턴이 끝날 때마다 세션이 얼마나 오래 쉴지 생존 곡선으로 예측하는 LightGBM 모델을 만들었어요. 모델 전체 크기는 2MB 안팎이고 예측에 3밀리초가 안 걸리며, 유휴 시간이 60초를 넘길지 맞히는 ROC-AUC는 0.73이고 전체 유휴 시간의 86~90%를 잡아내요. arXiv 제출자인 에샤 초크세 마이크로소프트 애저 리서치 연구원과 공저자들은 "모델이 세션이 정확히 얼마나 쉴지 짚어 내지 못할 때조차, 회수할 가치가 있을 만큼 오래 쉴 것이라는 사실은 믿을 만하게 알아낸다" 라고 적었어요.

TPM의 언어로 옮기면 이 논문은 요청 단위로 짜인 서빙 인프라를 세션 단위로 다시 짜라는 요구예요. 챗봇이 창구에 온 손님 한 명이 서류 한 장을 내고 나가는 일이라면, 코딩 에이전트는 한 손님이 창구에 앉아 서류를 열다섯 번 주고받다가 25분 자리를 비우고 다시 돌아오는 일이에요. 그래서 논문은 세션을 한 모델에 고정하고, 전환이 불가피하면 새 모델의 캐시를 미리 데워 두고, 압축은 프리픽스를 보존하는 방식으로 점진적으로 하고, 사용자 유형별로 캐시 보존 우선순위를 달리하는 계층형 SLO를 제안해요. 캐시 보존 시간이 정해져 있는 API에서는 예측된 유휴 시간이 그 한도에 걸칠 때 만료 직전에 값싼 연명 요청을 보내 재계산을 피할 수 있다는 제안도 들어 있어요.

데이터의 경계는 논문에 그대로 적혀 있어요. 트레이스는 Visual Studio와 VS Code의 클라이언트 쪽 기록이라 GPU 사용률 같은 서버 쪽 지표가 없고, 프롬프트 본문과 코드는 수집하지 않아 작업이 잘 끝났는지는 알 수 없으며, 표본은 전부 미국 지역이라 시간대가 세 개를 넘지 않아요. 저자들은 1월부터 6월까지 같은 특성이 유지됐다고 밝히면서도 도구와 모델이 매주 바뀌는 워크로드라 장기 추적이 필요하다고 적었고, 정제한 트레이스를 곧 공개하겠다고 밝혔어요. 메탈은 깃허브가 코파일럿 API에서 에이전트별 사용량을 따로 집계하기 시작했다고 보도한 바 있는데, 이 논문은 그 집계 뒤에서 에이전트가 실제로 어떻게 움직이는지를 처음 숫자로 보여 줬어요.

코딩 에이전트의 비용은 모델이 아니라 구조에서 나와요. 사용자가 보낸 메시지 한 개가 에이전트 안에서 호출 여섯 번과 도구 여섯 번으로 불어나고, 그 사이 캐시가 살아 있느냐가 지연과 비용을 가르며, 도구 하나가 실패하면 연산이 네 배로 뛰어요. 에이전트를 위한 인프라는 챗봇 인프라를 고쳐 쓰는 게 아니라 세션이라는 단위에서 처음부터 다시 설계해야 해요.