실험에서 실무로
이동하는 Agentic AI

나중에 돌아보면 2025년은 Agentic AI의 부흥이 시작된 시기로 비춰질 것입니다. OpenAI, Gemini, Claude, AWS의 Strands agent 등 이름만 들어도 굵직한 회사들이 앞다투어 Agentic AI를 위한 프레임워크와 새로운 프로토콜을 발표하고 있고, Agentic AI와 RAG에 대한 논문과 솔루션들이 쏟아지고 있습니다. 그럼에도 불구하고 누가 어떻게 실무에 적용했고, 어떤 효과를 보고 있는지에 대한 것들은 찾아보기 쉽지 않습니다.

저희는 이번 기회를 통해 뤼튼AX에서는 어떻게 실제로 Agent framework들을 실무에 적용하고 있는지 얘기해보려 합니다.

상용 환경에서 작동하는 Agentic AI는 K8S 혹은 EC2 같은 인스턴스형의 현대 클라우드 인프라와 통합되어야 합니다. Stateless를 지향하는 현대적 인프라 구조는 긴 대화와 Agentic workflow라는 긴 작업 특성과 상충됩니다. API에서 흔히 쓰이는 Liveness probe 패턴 또한 유효하지 않습니다. 왜냐하면 기존 API의 정상동작을 보장했던 Healthcheck router는 Agentic AI에게는 아무런 동작도 보장하지 않기 때문입니다. 심지어 동일한 요청 간 멱등성 또한 보장되지 않습니다. Agentic AI는 맥락을 읽고 다음 행동을 판단하는 주체이기 때문입니다.

Healthcheck를 위해 지속해서 간단한 Task를 수행시켜 Liveness를 보장받아야 할까요? 60초에 한 번 간단한 요청을 보낸다고 하더라도 Agent가 동작하는 한 개의 pod당 하루에 1,440번의 요청이 발생합니다. 활동하는 Agent가 한 개에서 두 개, 또 늘어날 때마다 단순 Healthcheck만을 위한 비용도 급증하게 됩니다. 이는 Agent framework provider들이 풀어야 할 과제 중 하나입니다.

어떤 Agent framework를 선택할 것인지도 깊은 탐구가 필요합니다. 저희는 특정 Agent가 수행해야 할 Task를 사전에 정의해놓고, LLM Model 리스트와 Agent Framework 리스트들로 이뤄진 매트릭스를 만들었습니다. 이렇게 만들어진 조합에서 사전 정의한 벤치마크용 Task를 수행하게 한 뒤에 정확도와 속도, 토큰 소모량, 수행시간 등을 고려한 최선의 조합을 선택하고 있습니다. 다행히도 대부분의 Framework들은 Vendor종속적이지 않게 다른 회사의 LLM Model을 쉽게 호출할 수 있었기 때문에 유연한 실험이 가능했습니다. 그리고, 여기에서 주목할 점은 다음과 같습니다.