에이전트 지연의 진짜 단위는 턴이다
에이전트의 응답 속도를 초당 토큰만으로 비교하면 실제 병목을 놓치기 쉽다. 체감 지연은 대략 다음처럼 나뉜다.
전체 지연 ≈ 모델 왕복 시간의 합 + 도구 실행 시간의 합 + 최종 답변 스트리밍
모델 호출이 일곱 번이면 모델을 20% 빠르게 해도 일곱 번의 왕복 비용은 남는다. 반대로 같은 작업을 세 턴에 끝내면 모델을 바꾸지 않아도 대기 시간이 크게 줄어든다. 달라진 것은 턴 수뿐이다.
그렇다면 실제 운영에서는 어떨까? 규제 산업용 문서 검색 서비스를 운영하는 Egnyte도 답변 하나에 도구 호출이 보통 5~7회 발생 한다는 사실을 운영 기록에서 확인했다. 검색 절차와 프롬프트를 고친 뒤 중간 난이도 질의는 2~3회, 복잡한 질의는 5회 이내로 줄었다. 환경마다 달라지는 벽시계 시간보다 설계에 직접 좌우되는 호출 수를 주요 지표로 삼았다.
성능을 검토할 때는 다음을 나눠서 본다.
- 불필요한 모델 턴이 있는지
- 매 턴 다시 읽는 프롬프트와 기록이 얼마나 큰지
- 도구가 느리거나 후속 호출을 강제하는지
위임할수록 느려진다, 다중 에이전트의 역설
Egnyte의 초기 구조에서는 상위 에이전트가 검색 에이전트를 호출했다. 검색 에이전트가 자료를 추려 요약하면 상위 에이전트가 이를 읽고 다음 행동을 다시 판단했다. 위임할 때마다 상태 전달과 요약, 추가 모델 턴이 필요했다. 검색 근거는 요약을 거치며 줄어드는데도 판단 절차는 그대로 되풀이됐다.
검색 도구를 상위 에이전트에 직접 연결하자 이 단계들이 사라졌다. 에이전트 사이에서 검색 결과만 옮기던 관리용 도구도 삭제했다. 사용자나 외부 시스템에 작용하지 않고 내부 상태만 전달하는 도구가 있다면, 계층 구조가 불필요한 턴을 만들고 있는지 의심해야 한다.
그런데 작업 단위를 가르는 기준은 남는다. 서로 독립적인 읽기와 분석은 한 번에 병렬로 처리된다. 반면 하나의 결과물을 함께 수정하면 에이전트마다 스타일과 예외 처리 기준이 달라지고, 결과를 합치는 과정에서 다시 작업이 생긴다. Cognition은 맥락과 에이전트 실행 기록 전체를 공유하고, 서로 다른 결정을 내리는 에이전트를 나란히 두지 말라 고 권한다.
이 원칙은 단일 에이전트에도 같다. 독립적인 검색은 한 턴에 병렬로 실행한다. Egnyte는 메타데이터 검색이 필요한지 별도 턴에서 먼저 판단하지 않고, 적용 가능한 검색과 스키마 탐색을 함께 실행했다. 중복 도구를 없애고 외부 조회에 시간 제한도 뒀다.
검색 도구가 무엇을 반환하느냐에 따라 다음 턴이 필요한지가 갈린다. 검색 결과가 문서 ID만 담으면 모델은 본문을 읽기 위해 다시 호출해야 한다. 관련 본문과 스니펫까지 돌려주면 답이 있는 경우 그 자리에서 처리가 끝난다. 반환값이 곧 다음 턴을 정한다는 말이다. 같은 축의 검색어는 불리언 연산자로 합치고, 독립적인 검색 축은 병렬로 실행하는 편이 낫다. 결과 수에 상한을 두고 불필요한 페이지네이션을 막는 것도 끝없는 탐색을 예방한다.
‘빠짐없이 찾아라’처럼 끝을 정하지 않은 지시는 평범한 질문까지 장시간 조사로 바꾼다. 답을 뒷받침할 자료를 충분히 확보하면 멈추도록 명시하는 편이 낫다. Egnyte는 도구별 지침을 시스템 프롬프트에서 각 도구의 설명으로 옮기고 상시 지침을 줄여 프롬프트 토큰을 약 30% 절감 했다.
모든 맥락을 기억해야 더 잘한다는 착각
시스템 프롬프트의 앞부분이 일정하면 프롬프트 캐시를 그대로 재사용한다. 반대로 반복할 때마다 동적 변수를 끼우면 접두부가 달라져 캐시가 빗나간다. Egnyte는 동적 값을 안정된 플레이스홀더로 바꾸고 후속 질문에는 이전 사용자 메시지와 최종 답변만 남겼다. 10~30KB에 이르는 중간 도구 기록은 대화 문맥에서 제외했다.
캐싱 범위에 따라 효과가 갈렸다. 500회가 넘는 세션을 분석한 연구에서 선택적 캐싱은 비용을 41~80% 줄이고 첫 토큰 시간을 13~31% 개선 했지만, 전체 컨텍스트 캐싱은 오히려 지연을 늘리기도 했다. 대화에 필요한 결론은 유지하되 실행 원문까지 매번 모델에 돌려주지는 말아야 한다.
같은 이유로 도메인 지식과 도구 정의도 필요할 때만 불러오는 편이 낫다. Egnyte는 모든 고객의 메타데이터 스키마를 시스템 프롬프트에 넣지 않고, 관련 스키마와 검색법만 한 번의 호출로 가져오게 했다.
Agent Skills도 같은 점진 공개 방식을 쓴다. 시작할 때는 이름과 설명만 보여주고, 과제와 관련 있을 때만 SKILL.md와 부속 자료를 읽는다. 지침과 자원을 필요할 때 로드하는 구조 는 상시 컨텍스트를 작게 유지한다. 대량의 도구 결과를 모델 밖에서 처리해 15만 토큰을 2천 토큰으로 줄인 사례 도 원리는 같다.
도구 이름과 입력 형식도 용도를 바로 추론할 수 있게 짓는다. Egnyte는 find, grep, cat처럼 널리 알려진 셸 명령의 관습을 활용했다. Anthropic도 user보다 user_id처럼 뜻이 분명한 필드명을 쓰고, 전제와 출력 형식을 새 동료에게 설명하듯 명시하라 고 권한다. 익숙하고 구체적인 계약은 설명용 토큰과 잘못된 호출을 함께 줄인다.
에이전트 병목은 숫자로 드러난다
시스템마다 최적화 순서가 다르므로 캐시 미스를 고치면 중첩 위임이, 위임을 없애면 도구 반환값이나 종료 규칙이 다음 병목으로 드러날 수 있다. 추측으로 한꺼번에 고치는 대신 다음 값을 변경 전후로 비교한다.
- 질의당 모델 턴 수와 도구 호출 수
- 입력, 출력 토큰과 첫 토큰 시간
- 도구별 실행 시간과 실패 횟수
- 전체 응답 시간과 비용
이때 OpenTelemetry의 생성형 AI 규약은 모델 호출과 도구 실행을 따로 기록하며, 주요 코딩 에이전트도 API 요청, 도구 호출, 세션 단위의 측정 자료를 제공 한다.
ReAct형 에이전트(추론과 행동을 번갈아 수행하는 패턴)의 속도는 모델 하나로 설명되지 않는다. 중첩 위임과 빈약한 도구 반환값은 턴 수를 늘리고, 변하는 프롬프트와 긴 실행 기록은 매 턴의 비용을 키운다. 설계가 비용을 한 번만 더하는지, 아니면 모든 턴에 곱하는지에 따라 개선 폭이 갈린다. 턴마다 곱해지는 비용을 줄일 때 개선 폭이 가장 컸다. 모델을 바꿔도, 매 턴에 곱해지는 설계 비용은 사라지지 않는다.