AI 에이전트 지연 시간(Latency) 101: AI 에이전트를 어떻게 속도 높일까요?

개발자들로부터 이 질문을 자주 받습니다. 개발자들은 일반적으로 먼저 에이전트를 작동시키는 데 시간을 할애하지만, 이후에는 속도와 비용에 관심을 기울입니다. 저희가 개발자들이 하는 몇 가지 행동은 다음과 같습니다:

• 지연 시간(latency)이 어디서 발생하는지 파악하기
• 사용자 경험(UX)을 변경하여 '인지되는' 지연 시간을 줄이기
• LLM 호출 횟수를 줄이기
• LLM 호출 속도 높이기
• LLM 호출을 병렬로 처리하기

지연 시간이 어디서 발생하는지 파악하기

이것은 기본적으로 들릴 수 있지만, 지연 시간을 줄이는 접근 방식은 전적으로 특정 병목 현상(bottleneck)에 달려 있습니다. 지연 시간은 하나의 큰 LLM 호출에서 오는 것인가요, 아니면 단순히 합쳐져서 문제가 되는 여러 개의 작은 호출에서 오는 것인가요? 속도를 높이려고 시도하기 전에 이러한 문제들을 진단해야 합니다.

LangSmith는 이를 위한 매우 유용한 도구로, 에이전트 상호 작용에 대한 완전한 가시성을 제공합니다. 에이전트의 각 단계별 지연 시간을 추적할 수 있으며, 전반적인 지연 시간에 가장 많이 기여하는 단계를 쉽게 식별할 수 있도록 최근 '워터폴(waterfall)' 뷰도 도입했습니다.

'인지되는' 지연 시간을 줄이기 위해 UX 변경하기

때로는 지연 시간을 줄이는 가장 쉬운 방법은 아예 지연 시간을 줄이지 않는 것입니다.

처음에는 직관에 반하는 것처럼 들릴 수 있지만, 왜 지연 시간이 중요한지 생각해 보면 — 이는 종종 에이전트가 실행되는 데 너무 오래 걸리면 사용자가 사용하기 싫어할 것이라는 사용자들의 우려 때문에 중요합니다. 이는 종종 에이전트의 UX를 업데이트함으로써 해결될 수 있습니다. 저희는 사람들이 이를 수행하는 두 가지 주요 방법을 확인했습니다.

결과를 스트리밍합니다. LLM 애플리케이션 대부분에서 스트리밍은 매우 흔한 방식이지만, 아직 사용하고 있지 않다면 반드시 도입해야 합니다. 이는 사용자에게 LLM이 작동 중임을 전달하여 페이지를 이탈할 가능성을 줄여줍니다. 응답 토큰을 스트리밍하는 것 외에도 최종 응답 그 이상을 스트리밍할 수 있습니다. 예를 들어, 에이전트가 수행하는 계획 단계, 검색 결과(retrieval results), 또는 사고 과정의 토큰(thinking tokens) 등을 스트리밍할 수 있습니다. Perplexity는 자체 검색 인터페이스에서 이 기능을 훌륭하게 구현했습니다. 그들은 이러한 중간 단계를 보여주기 위해 UI를 변경함으로써 사용자 만족도가 향상되었음을 발견했으며, 이는 전체 완료 시간이 변하지 않았음에도 불구하고 달성된 성과입니다.백그라운드에서 에이전트를 실행합니다. 에이전트가 백그라운드에서 실행되도록 하세요. 저의 이메일 비서의 경우, 이메일 에이전트가 얼마나 오래 걸리는지 저는 알 수 없습니다. 왜냐하면 특정 이벤트(이메일)에 의해 트리거되며, 문제가 생겼을 때만 알림을 받기 때문입니다. 저는 사용자로부터 모든 지연 시간을 숨기고, 에이전트는 백그라운드에서 작동합니다.## LLM 호출 횟수를 줄이기** 모든 것이 LLM 호출일 필요는 없습니다. LLM 호출 외의 방식으로 작업을 수행할 수 있다면—최고입니다! 현재 구축되고 있는 에이전트들은 LLM 호출과 코드가 결합된 형태입니다. 코드와 LLM 호출을 결합하는 이러한 하이브리드 접근 방식은 LangGraph의 핵심 원칙 중 하나이며, Replit, Uber, LinkedIn, Klarna 같은 기업들이 이를 채택하는 주요 이유가 됩니다.우리가 흔히 보는 경로는

이러한 구조의 문제는 여러 개의 LLM 호출을 사용한다는 점입니다. 이들은 서로 다른 에이전트들이 어떻게 통신해야 하는지에 대해 효율적이지 않습니다. 이것은 설계상 그렇습니다. 일반적인 목적의 아키텍처이기 때문에 특정 사용 사례에 최적화되어 있지 않기 때문입니다.

바로 이때 LangGraph를 사용하는 사람들을 볼 수 있습니다. LangGraph는 낮은 수준(low level)에서 작동하며, 에이전트들이 서로 어떻게 통신해야 하는지(또는 단순히 LLM 호출만 필요한 경우)를 정확하게 지정할 수 있게 해줍니다. 종종 이는 LLM 호출 횟수를 상당히 줄여주어 에이전트를 더 빠르고 저렴하게 만들고 (그리고 종종 더 안정적으로 만듭니다).

LLM 호출 속도 높이기

개발자들이 LLM 호출의 속도를 높이는 방법은 일반적으로 두 가지가 있습니다.

더 빠른 모델. 일부 모델은 다른 모델보다 빠릅니다. Google은 매우 빠른 Gemini Flash를 제공합니다. OpenAI와 Anthropic 역시 더 작고 빠른 모델을 가지고 있습니다. Groq나 Fireworks 같은 오픈 소스 모델 호스팅 플랫폼들은 최고의 오픈 소스 모델들을 끊임없이 더 빠르게 만들려고 노력하고 있습니다. 참고: 이는 종종 더 낮은 성능의 모델을 사용해야 하는 트레이드오프를 동반하는데, 이러한 빠른 모델들은 보통 작기 때문에 정확도가 떨어지기 때문입니다.

적은 컨텍스트. LLM이 응답하는 데 걸리는 시간은 입력 길이와 비례합니다. 더 빠른 결과를 얻으려면 적은 입력을 전달할 수 있습니다! 이것이 바로 각 LLM 호출에 정확히 무엇이 들어가는지에 대해 **완벽한 제어와 가시성(visibility)**을 확보해야 하는 이유입니다. 이를 모호하게 하거나 (또는 제어하기 쉽게 만들지 않는) 프레임워크는 좋지 않습니다. 이것이 바로 LangGraph가 숨겨진 프롬프트 없이 제공되어 사용자가 완벽한 통제권을 갖게 되는 이유입니다. LLM 호출에 무엇이 들어가는지에 대해 더 나은 가시성을 확보하는 방법을 찾고 있다면 LangSmith를 확인해 보세요.

LLM 호출 병렬화하기

모든 사용 사례에 적용되는 것은 아니지만, 만약 귀하의 사용 사례라면 이 방식을 사용해야 합니다. LangGraph는 기본적으로 병렬 처리(parallelism)를 지원합니다. 고려해 볼 수 있는 예시는 다음과 같습니다:

결론

AI 에이전트의 속도를 높이는 것은 궁극적으로 성능(performance), 비용(cost), 그리고 기능성(capability) 사이에서 전략적인 트레이드오프를 만드는 것에 달려 있습니다. 먼저 특정 성능 병목 현상(bottleneck)을 이해하는 것부터 시작하여, 사용 사례에 따라 이러한 기술들을 선택적으로 적용해 보세요. 때로는 가장 효과적인 방법이 기술적이지 않을 수도 있습니다—라기보다는 사용자 경험 측면에서 에이전트와의 상호작용 방식을 재고하는 것이 더 나을 수 있습니다.

새로운 전략들을 시도하면서, 어떤 기법들이 여러분의 에이전트를 속도 높이는 데 가장 효과적이었는지 저희에게 알려주시면 감사하겠습니다. X나 LinkedIn으로 메시지를 보내주세요.