Google Converse: 이것이 마침내 우리가 약속받았던 에이전트적 도약인가?

Google이 최근 Converse를 출시했습니다. 제 피드는 하이프(hype)로 가득 차 있습니다. 컴퓨터와 상호작용하는 방식을 바꾼다는 마케팅용 쓰레기는 잊어버리고, 이것이 여러분의 아키텍처(architecture)에 실제로 어떤 영향을 미치는지에 대해 이야기해 봅시다. 오늘날 대부분의 AI 어시스턴트들은 그저 미화된 패턴 매처(pattern matchers)에 불과합니다. 프롬프트(prompt)를 보내면 토큰(tokens)을 내뱉고 그것으로 끝입니다. Converse는 서비스 내부에 상태 관리(state management)를 직접 내장함으로써 이 문제를 해결하려고 시도합니다.

상태 비저장(Stateless) 장벽의 파괴

표준 LLM API는 상태 비저장(stateless) 방식입니다 (우리의 노트). 히스토리 배열(history array)을 밀어 넣으면, 그들은 완성된 결과(completion)를 밀어 넣습니다. 만약 다단계 작업(multi-step task)을 실행해야 한다면, 도구 루프(tool loops)와 에러 상태(error states)를 추적하기 위해 Node.js나 Python에서 비대해진 오케스트레이터(orchestrator) 로직을 작성해야만 합니다. Converse는 해당 에이전트 루프(agent loop)를 네이티브하게 처리합니다. 서비스 레이어(service layer) 내부에서 메모리 버퍼(memory buffers)와 실행 사이클(execution cycles)을 관리합니다. 더 이상 메시지 인덱스(message index)를 일일이 관리할 필요가 없습니다.

저는 베타 버전을 테스트하며 도구 체이닝(tool-chaining)의 신뢰성이 실제로 향상된 것을 확인했습니다. 외부 도구의 출력을 추적할 때 이전에 보았던 것보다 환각(hallucinations) 현상이 적었습니다. 저는 BigQuery 조회 작업을 보고서 생성 작업에 체이닝했습니다. 컨텍스트 윈도우(context window)를 완벽하게 관리하더군요. 토큰 예산(token budget) 내에 머물기 위해 수동으로 히스토리를 가지치기(prune)할 필요가 없었습니다. 이것은 단순한 채팅창이 아니라 관리형 실행 환경(managed execution environment)처럼 느껴집니다.

생태계 해자(Ecosystem Moat)

진정한 이점은 모델 그 자체에 있지 않습니다. Google의 그래프(graph)에 연결된다는 점입니다. 만약 여러분의 제품이 Workspace나 BigQuery에서 실행된다면, Converse는 데이터를 연결하기 위해 통상적으로 필요했던 미들웨어(middleware)를 제거해 줍니다. 엔터프라이즈 개발자들에게 이것은 결정적인 기능(killer feature)입니다. 기본적으로 데이터 웨어하우스(data warehouse)를 쿼리 가능한 에이전트(queryable agent)로 전환하는 셈입니다.

성능 지표와 현실

Google은 이 제품이 복잡한 추론(complex reasoning)에서 Claude 3.5와 GPT-4o를 능가한다고 주장합니다. 여러분도 잘 아시겠지만, 벤치마크(benchmarks)는 실제 프로덕션의 엣지 케이스(edge cases)를 마주하기 전까지는 그저 마케팅일 뿐입니다. 제 테스트 결과에 따르면, 세션을 오랫동안 일관되게 유지할 수 있는 넉넉한 토큰 제한(token limits)을 보여주었습니다. 다만 지연 시간(latency)은 주의하십시오. 만약 낡은 레거시 API(legacy APIs)와 통신하도록 강제한다면, 속도 저하를 느끼게 될 것입니다.

마이그레이션(Migrate)해야 할까요?

단순한 RAG(Retrieval-Augmented Generation) 챗봇을 위해서라면 이것을 사용하지 마세요. 불필요한 API 비용과 벤더 종속(vendor lock-in) 문제만 겪게 될 것입니다. 과잉 사양(overkill)입니다. 하지만 문서, 데이터베이스, 그리고 다중 사용자 세션(multi-user sessions)을 처리해야 하는 자율 에이전트(autonomous agents)를 구축하고 있다면, 네이티브 상태 관리(native state handling) 기능이 엄청난 시간을 절약해 줄 것입니다.

저는 현재 이것이 침묵하는 실패(silent failures)를 어떻게 처리하는지 지켜보고 있습니다. 지금까지 살펴본 바로는, 에러 보고(error reporting) 방식이 과거에 보았던 LangChain의 복잡하고 엉망인 방식들보다 훨씬 깔끔합니다. 단순히 멈춰 있거나 무작위 토큰(random tokens)을 쏟아내는 것이 아니라, 실제로 역추적(backtrack)을 시도합니다. 워크플로(workflows)의 복잡도가 높다면, 그 사실 하나만으로도 POC(Proof of Concept, 개념 증명)를 수행할 가치가 있습니다.

Converse는 "에이전트적(agentic)" 시대에 거는 베팅입니다. 모델은 더 이상 수동적인 응답자가 아닙니다. 비즈니스 로직(business logic)의 능동적인 일부입니다. 우리는 단순한 프롬프팅(prompting)을 넘어 실제 시스템 설계(system design) 단계로 나아가고 있습니다. 향후 3개월 동안 API가 어떻게 진화하는지 계속 지켜보십시오. 특히 그들이 이러한 지속성 세션(persistent sessions)에 사용자 인증(user authentication)을 어떻게 통합(bake)할지 매우 궁금합니다.