챗봇에서 에이전시 시스템으로: AI 에이전트 베이크오프에서 얻은 교훈

Source: Dev.to

소개: 도전 과제

최근 Google Cloud AI Agent Bake‑off episode 2에서 개발자들은 레거시 현대화에서 너무 흔한 시나리오에 직면했습니다: Cymbal Bank의 기본적인 거래 챗봇을 신뢰할 수 있는, 능동적인 재무 플래너로 전환하는 것이었습니다.

목표는 단순히 더 좋은 프롬프트를 작성하는 것이 아니라, AI 에이전트가 기존 인프라와 함께 작동할 수 있는 정교한 시스템을 설계하는 것이었습니다(리플레이스 전략 없이). 이를 통해 안전하고 개인화된 재무 조언을 제공할 수 있었습니다.

이 글에서는 이러한 솔루션을 가능하게 한 Agent‑to‑Agent (A2A) Protocol과 **Agent Development Kit (ADK)**에 초점을 맞춰, 아키텍처 패턴과 기술을 자세히 살펴보겠습니다.

핵심 문제: “단순한” 챗봇 한계

대부분의 은행 봇은 여기서 정체됩니다. 잔액을 조회하거나 거래 내역을 나열할 수는 있지만, 진정한 재무 파트너가 될 만큼의 컨텍스트가 부족합니다. Bake‑off 챌린지는 이 한계를 깨고, **“예산에 맞춰 파리 여행을 계획해 주세요.”**와 같은 복잡한 사용자 목표를 해결할 수 있는 AI 에이전트를 구축하는 것이었습니다.

비밀 무기: Agent‑to‑Agent (A2A) Protocol

우승 아키텍처의 핵심은 Agent‑to‑Agent (A2A) Protocol이었습니다. A2A는 서로 다른 AI 에이전트가 안전하게 협업할 수 있도록 하는 표준화된 통신 레이어입니다.

복잡한 시스템을 구축하는 개발자들에게 A2A는 세 가지 큰 문제를 해결합니다:

• 상호 운용성: LangGraph, CrewAI, Semantic Kernel 등 어떤 스택이든 에이전트를 연결해 복합 시스템을 만들 수 있습니다.
• 분산 문제 해결: 오케스트레이터가 하위 작업을 도메인 전문가에게 위임함으로써, 단일 컨텍스트 윈도우로는 감당하기 어려운 복잡한 워크플로를 처리합니다.
• 캡슐화 및 보안: 에이전트는 불투명한 서비스로 상호 작용하며, 구조화된 입력/출력만 공유하고 내부 메모리, 프롬프트, 도구는 비공개로 유지합니다.

아키텍처: 다중 에이전트 계층 구조

가장 성공적인 팀들은 “Monolithic Agent” 안티패턴을 버렸습니다. 대신, 마이크로서비스 아키텍처와 유사하게 인지 작업을 담당하는 전문화된 에이전트 계층을 구축했습니다.

Orchestrator Agent는 사용자 의도를 파악하고, Sub‑Agents에게 A2A를 통해 작업을 위임하는 인터페이스 레이어 역할을 합니다.

A2A가 이 흐름을 가능하게 하는 방법

• Capability Discovery(능력 탐색): 핸드쉐이크 과정을 통해 오케스트레이터는 어떤 에이전트가 등록돼 있는지, 어떤 도구를 제공하는지 소스 코드를 보지 않고도 파악합니다.
• 표준화된 전송: 작업을 위임할 때 A2A는 요청과 응답이 구조화되고 안전하게 전달되도록 보장합니다. 이는 핀테크에서 매우 중요합니다; 오케스트레이터는 서브‑에이전트가 사용하는 원시 SQL 쿼리를 볼 필요 없이 정제된 결과만 받습니다.

실제 적용된 아키텍처

팀 Adrian과 Ayo는 Router Agent를 구축해 사용자 의도를 분류했습니다. 사용자가 모기지에 대해 물으면 Big Purchases Agent로, 커피에 대해 물으면 Daily Spending Agent로 라우팅합니다.

예시 사용자 요청을 따라가 보겠습니다: “여행을 계획하고 싶어요. 예산을 설계해 줄 수 있나요?”

1. Ingest(수신): 오케스트레이터가 질의를 받습니다.
2. Route(라우팅): “Big Purchase” 의도로 판단하고 로컬 Big Purchases Agent에 위임합니다.
3. Bridge(브리지): A2A를 사용해 로컬 에이전트가 원격 Cymbal Bank Agent를 호출합니다.
4. Execution(실행): 은행 백엔드 내부에 안전하게 배치된 원격 에이전트가 내부 도구와 데이터베이스에 접근해 재무 이력을 조회합니다.
5. Return(반환): 데이터가 A2A를 통해 Big Purchases Agent에 전달됩니다.
6. Synthesize(합성): 에이전트가 구매 가능성을 계산하고, 필요 시 Visualization Agent를 호출해 순자산 예측 차트를 생성합니다.
7. Response(응답): 오케스트레이터가 최종 멀티모달 플랜을 사용자에게 제시합니다.

도구: Agent Development Kit (ADK) & Gemini

팀들은 Google의 Agent Development Kit (ADK)를 활용해 에이전트를 소프트웨어 아티팩트처럼 다루었습니다—구조, 상태 관리, 배포 파이프라인을 제공하죠. 이를 통해 Gemini 2.5 Pro, Gemini Flash(추론용) 및 Veo(비디오 생성) 모델을 오케스트레이션했습니다.

순차적 흐름을 넘어: 고급 패턴

선형(순차) 워크플로는 간단한 작업에 적합하지만, ADK는 더 높은 지능과 낮은 지연 시간을 위한 고급 패턴을 지원합니다.

1. 병렬 에이전트

• 패턴: 서로 독립적인 여러 에이전트를 동시에 실행하고 결과를 집계합니다.
• 사용 사례: “Financial Health” 대시보드 로드. 계좌 잔액 → 투자 성과 → 리워드를 순차적으로 가져오는 대신, 세 에이전트를 동시에 호출해 Time‑To‑First‑Byte(TTFB)와 인지된 지연을 크게 감소시킵니다.

2. 루프 에이전트 (Generator‑Critic)

• 패턴: 한 에이전트가 출력을 생성하고, 다른 에이전트가 이를 비판·검증하며, 기준에 도달할 때까지 반복합니다.

• 사용 사례: 복잡한 예산 편성.

  1. Generate(생성): Strategy Agent가 “대출 상환을 $500 늘리세요.” 제안.
  2. Critique(비판): Feasibility Agent가 현금 흐름을 확인: “거부 – 식료품 예산에 적자 발생.”
  3. Refine(정제): Strategy Agent가 “$200 늘리고 Netflix를 취소하세요.”로 수정.
  4. Finalize(최종화): 계획이 검증을 통과하고 사용자에게 표시됩니다.

BigQuery ML (BQML)로 기반 다지기

환각 현상—재무 AI의 크리프톤—을 완화하기 위해 팀 Adrian과 Ayo는 BigQuery ML을 통합했습니다.

장점

• 데이터 중력: 민감한 거래 로그를 외부 추론 엔드포인트로 옮길 필요가 없습니다.
• 정확도: 사용자의 실제 이력 데이터를 기반으로 예측 모델을 학습해 “순자산 전망”이 수학적으로 타당해집니다(단순 LLM 추측이 아님).

현실 세계와 연결하기

고립된 에이전트는 장난감에 불과합니다. 서비스와 연결된 에이전트는 도구가 됩니다.

Identity‑Aware Agents (Firebase)

개인화에는 정체성이 필요합니다. Firebase Authentication을 통합해 팀들은 안전한 세션 컨텍스트를 만들었습니다. 이 user_id는 ADK 상태 관리에 전달돼 모든 서브‑에이전트가 해당 사용자 데이터만 조회하도록 보장합니다.

Community Grounding (Reddit API)

BQML이 정량 데이터를 담당하는 동안, 팀은 Reddit API를 활용해 정성적 인사이트를 얻었습니다. 파리 여행을 계획할 때, 에이전트는 r/travel 서브레딧을 조회해 실제 커뮤니티 추천을 가져옵니다. 이 “사회적 증거” 레이어가 제안에 더 풍부하고 현실적인 기반을 제공합니다.