사용자 발화에서 응답까지: 그래프 기반 에이전트로 동작하는 AI 서비스

명확한 흐름 제어, 노드 재사용, 모델별 비용 최적화, 빠른 A/B 테스트를 위해 그래프 방식을 선택했다. 쇼핑은 결과 UI를 제어하기 쉬운 DAG로 시작했고, 로컬은 복합 조건과 반복 검색을 위해 일부 순환을 허용했다. 카카오톡에서는 도메인별 에이전트를 분리해 독립적으로 확장하고, 검색에서는 정보 탐색을 담당하는 Think 단계와 화면 콘텐츠를 만드는 Generation 단계를 나눴다. 서비스 요구가 복잡해질수록 그래프의 자율성과 관심사 분리가 커지는 과정을 비교한다.

공통 실행 계층은 Kotlin과 Spring WebFlux로 만든 Agent Executor가 사용자 발화를 받아 그래프를 실행하고 응답을 스트리밍한다. LLM, reasoning, generation, API tool, MCP, UI rendering 등 노드 유형을 목적에 맞게 나눴다. Tool Executor는 실제 API를 호출할 뿐 아니라 쿼리 재작성, 추천 사유 생성, 리랭킹 같은 세부 작업을 작은 서브 LLM에 위임해 메인 모델의 지연과 토큰 비용을 줄인다. 모델에 전달할 최소·마스킹 데이터와 화면에 필요한 풍부한 데이터를 분리해 보안과 UI 요구도 함께 만족시킨다.

내부 모델과 Claude, GPT, Gemini처럼 제공자마다 다른 요청·응답 형식을 Model Gateway가 하나의 계약으로 변환한다. reasoning 모델 등장 이후 커진 포맷 차이를 실행 계층에서 분리해 새 모델을 교체하거나 비교하기 쉽게 만들었다. Kafka와 Druid 파이프라인으로 그래프·노드별 입력과 출력 토큰, 지연 시간, 비용을 수집해 어떤 모델과 단계가 병목인지 정량적으로 확인한다.

스프레드시트의 프롬프트를 코드로 옮기고 매번 PR과 배포를 거치던 느린 과정을 없애기 위해 그래프를 플랫폼화했다. 비개발자용 편집, 버전 관리와 즉시 롤백, 워크스페이스별 권한·API 키 격리, 장애 시 폴백 모델, 시뮬레이션, MCP 연결을 핵심 원칙으로 삼았다. 노드와 엣지를 시각적으로 편집하고 실제 툴 호출을 시험할 수 있게 되면서 로컬 서비스의 릴리스 횟수가 쇼핑 대비 다섯 배 이상 늘었고, 내부에서는 약 290개 그래프와 2천 회 가까운 릴리스가 이뤄졌다.