더 나은 AI 에이전트를 만드는 법: 에이전트 베이크오프에서 얻은 개발자 팁 5가지
요약
구글 클라우드 AI 에이전트 베이크오프 경험을 통해 배우게 된 5가지 실용적인 팁으로, 단일 LLM을 넘어 멀티 에이전트 아키텍처와 결정적 코드 활용으로 견고한 프로덕션급 AI 에이전트를 구축하는 방법을 알려드려요.
인사이트
- 단일 LLM만으로는 복잡한 문제를 해결하기 어려우니, 여러 전문 에이전트(마이크로서비스처럼)로 구성된 멀티 에이전트 워크플로를 구축해야 해요.
- AI 모델은 빠르게 발전하므로, 오늘 만든 에이전트 설계(Agent Harness)가 곧 구식이 될 수 있다는 마음으로 모듈식으로 설계해서 유연하게 대응해야 해요.
- LLM은 추론과 의도 추출에 집중하고, 복잡한 계산이나 데이터베이스 작업처럼 정확성이 중요한 부분은 파이썬 함수나 SQL 쿼리 같은 결정적인 코드에 맡겨야 해요.
왜 중요한가
단순한 LLM과의 대화를 넘어서, 실제 산업 문제에 적용 가능한 안정적이고 안전하며 유용한 프로덕션급 AI 에이전트를 구축하려면 견고한 소프트웨어 아키텍처 원칙을 적용한 엄격한 에이전틱 엔지니어링이 필수적이기 때문이에요.
2026년 4월 14일
작년에 구글 클라우드 팀은 최고의 개발자들을 한자리에 모아서 제한된 시간 안에 실제 산업의 거대한 문제들을 해결할 수 있는 완전 자율 AI 에이전트를 만들라고 도전장을 던졌어요.
그것이 바로 Google Cloud AI Agent Bake-Off의 전제였어요. 압박 속에서 에이전틱 애플리케이션을 구축하는 생생하고 필터링되지 않은 현실을 보여주는 자리였죠. 팀들은 전자상거래 반품 처리, 오래된 은행 시스템 현대화, 스타트업의 전체 Go-To-Market 전략 자동화 같은 문제들을 해결하는 모습을 보여줬어요.
팀들이 승리하는 모습, 그리고 가끔은 시간 제한 앞에서 실시간으로 실패하고 좌절하는 모습을 보면서 구글 클라우드 팀의 생각이 근본적으로 바뀌었어요. 가장 큰 깨달음이요? 단순히 LLM과 대화만 하는 '꿀 같은 시기'는 이제 끝났다는 거예요. 멋진 데모에서 프로덕션 준비가 된 애플리케이션으로 넘어가는 건 더 이상 프롬프트 엔지니어링을 잘하는 것만으로는 안 되고요. 바로 엄격한 에이전틱 엔지니어링이 필요하다는 걸 알게 됐죠. 멀티 에이전트 아키텍처, 상태 관리, 그리고 결정적 가드레일이 중요하다는 뜻이에요.
스타트업을 확장하든, 엔터프라이즈 인프라를 현대화하든 상관없이, 이 블로그에서는 그동안의 혼란과 밤샘 작업, 빛나는 혁신들을 전부 모아서 실제로 효과가 있었던 5가지 패턴으로 정리했어요.
여기 여러분의 다음 세대 AI 에이전트를 위한 아키텍처 청사진이 있어요.
1. 모놀리스를 깨뜨려요: 멀티 에이전트 워크플로로 아키텍처를 설계하세요.
단일의 거대한 LLM 하나만 가지고 의도 추출, 데이터베이스 검색, 그리고 문체 추론을 한꺼번에 처리하려고 하면 환각(Hallucination) 현상과 레이턴시 급증으로 직행하는 지름길이 될 거예요. 확장하려면 에이전트를 마이크로서비스처럼 다뤄야 해요. 복잡한 문제를 전문화된 하위 에이전트로 분해하고, 각각의 하위 에이전트에는 엄격하게 범위가 지정된 프롬프트를 부여하고, 트래픽을 라우팅하는 감독(supervisor) 에이전트가 이들을 관리하는 방식이죠. 에피소드 3에서 이 방식이 엄청난 효과를 발휘하는 것을 보았어요. Daniel과 Luis 팀은 엄격하게 범위가 지정된 에이전트들을 병렬로 실행해서 처리 시간을 1시간에서 단 10분으로 줄였거든요. 추가적으로, 이 모듈식 접근 방식은 유지보수도 쉽게 만들어줘요. 새로운 모델을 도입하거나 데이터베이스 스키마를 변경해야 할 때, 전체 워크플로를 건드리지 않고 단 하나의 하위 에이전트만 수정하면 되니까요.
- ADK를 활용한 멀티 에이전트 시스템:멀티 에이전트 시스템 - 에이전트 개발 키트 (ADK)
멀티 에이전트 워크플로 아키텍처:
2. 오늘 만든 에이전트 하네스는 내일 교체될 수도 있어요.
전자상거래 챌린지에서 목표는 Gemini 2.0을 사용해서 가상 피팅 경험을 구축함으로써 소매업체들의 '상상력 격차'를 해소하는 것이었어요. 참가자들은 잔혹한 3시간 스프린트 내에 놀랍도록 매력적이고 여러 단계로 이루어진 솔루션을 만들었죠. 하지만 AI 엔지니어링의 현실은 이래요. 당시엔 몰랐지만, Nano Banana의 첫 버전이 몇 주밖에 남지 않았던 때였어요. 오늘날에는 그 복잡했던 가상 피팅 경험을 단일 프롬프트로도 달성할 수 있답니다. 개발자들은 영속적이지 않다는 마음가짐으로 아키텍처를 설계해야 해요. 오늘 작성한 복잡한 에이전트 하네스가 몇 달 후, 아니 몇 주 후에는 최신 모델의 발전으로 대체될 수 있다는 사실을 받아들여야 하죠. 모듈식으로 구축해서 네이티브 모델이 따라잡는 순간 오래된 코드를 과감히 폐기할 수 있도록 준비하세요.
- 2026년 에이전트 하네스:https://www.philschmid.de/agent-harness-2026
에이전트 하네스 다이어그램:
3. 멀티모달 기능은 핵심 요구사항이지, 추가 기능이 아니에요.
에피소드 3에서 팀은 개발자들에게 예상치 못한 과제를 던졌어요. 기존 에이전트에 멀티모달 경험을 주입해야 했던 거죠. 곧 '파란 청바지를 입으세요' 같은 텍스트 추천만으로는 실제 소매 문제를 해결하는 데 근본적으로 실패한다는 것을 깨달았어요. '그림 한 장이 천 마디 말보다 낫다'는 오래된 격언은 AI 세계에서도 마찬가지예요. 훨씬 더 정확한 프롬프트라는 뜻이죠. 최고의 아키텍처들은 사용자의 사진을 수집하고 시각적 맥락을 추출하며 이미지 생성 도구를 동적으로 트리거해서 복합적인 시각 자료를 렌더링하도록 멀티모달 모델을 기본적으로 통합해서 텍스트를 넘어섰어요. 멀티모달을 나중에 덧붙이는 기능이 아니라 기본 기능으로 취급하면 정확성이 극적으로 향상되고 훨씬 더 자연스러운 사용자 경험을 만들 수 있어요.
- 멀티모달 라이브 API:Get_started_LiveAPI.ipynb - google-gemini/cookbook
멀티모달 프롬프트 vs 이미지 입력
4. 적절한 오픈소스 프로토콜(MCP, A2A, UCP, AP2, A2UI, AG-UI)을 언제 사용해야 할지 아는 것이 중요해요.
모든 내부 에이전트마다 맞춤형 API 래퍼를 작성해서 오래된 은행 시스템이나 엔터프라이즈 도구에 연결하는 것은 엄청난 시간 낭비예요. AI 개발 환경은 MCP, A2A, UCP, AP2, A2UI, AG-UI 같은 '알파벳 수프'로 넘쳐나고 있어서 서로 경쟁하는 표준들의 벽을 마주하는 기분이 들 수도 있어요. 하지만 이 '알파벳 수프'를 마스터하는 것이 취약한 프로토타입과 확장 가능한 프로덕션 시스템을 구분하는 기준이 돼요. Model Context Protocol (MCP)과 같은 개방형 표준을 채택하면, 에이전트들은 표준화된 '에이전트 카드'를 통해 자원을 동적으로 발견하고 견고한 JSON 페이로드를 사용해서 통신할 수 있어서, 에이전트가 사용하는 모든 도구에 대해 취약한 통합 코드를 작성하고 유지 관리하는 수고를 덜 수 있어요.
오늘 당장 이것을 실천에 옮기려면, 에이전트 개발 키트(ADK)를 사용해서 레스토랑을 위한 다단계 공급망 에이전트를 구축해보세요. 단순한 LLM은 환각을 일으키겠지만, 이러한 개방형 프로토콜들을 하나씩 추가해 나가면 에이전트가 갑자기 실제 재고 데이터베이스를 확인하고, 원격 공급업체 에이전트와 통신하며, 안전한 거래를 실행하고, 대화형 스트리밍 대시보드를 렌더링할 수 있게 될 거예요. 맞춤형 '접착제 코드(glue code)'를 작성하는 것을 멈추고 개방형 프로토콜을 활용해서 멀티 에이전트 아키텍처의 미래를 대비하세요.
- AI 에이전트 프로토콜 최종 가이드:https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/
AI 에이전트 프로토콜 개발자 가이드
5. LLM은 추론하고, 결정적인 코드는 실행해요 (엄격한 스키마를 사용하세요).
LLM에게 직접 복리 이자를 계산하라고 요청하는 것은 거의 해고당할 만한 일이에요. LLM은 본질적으로 확률적이라서 결국에는 수학 계산에서 환각을 일으킬 거거든요. 오래된 은행 시스템 챌린지에서, 구글 클라우드 팀은 여러 팀이 AI에게 금융 거래에 대한 수학적 계산 같은 중요한 부분을 맡기려 하는 것을 봤어요. 이는 즉시 대규모 유효성 검사 오류를 일으켰죠. 성공적인 패턴은 간단해요. LLM은 추론과 의도 추출에만 엄격하게 사용하세요. 모델의 출력 변수를 캡처하기 위해 Pydantic과 같은 엄격한 JSON 유효성 검사 스키마를 사용하세요. 변수가 엄격한 유효성 검사를 통과하면, 전통적인 100% 결정적인 파이썬 함수나 SQL 쿼리에 넘겨서 실제 계산이나 데이터베이스 쓰기 작업을 실행하게 하는 거죠. AI가 생각하게 하되, 전통적인 코드가 실행하게 하세요.
제미나이 API를 활용한 제어형 생성 입문:구조화된 출력 Google Collab
마지막 생각: 행동 촉구
신뢰할 수 있고, 안전하며, 유용한 프로덕션급 에이전트를 구축하는 것은 진지한 엔지니어링 도전 과제예요. AI 에이전트 베이크오프에서 증명되었듯이, 성공한 팀들은 가장 복잡한 '갓 프롬프트'나 가장 화려한 단일샷 데모를 선보인 팀이 아니었어요. 그들은 엄격한 소프트웨어 아키텍처의 기본 원칙을 존중했던 팀들이었죠.
만약 오늘 개발을 시작한다면, 바퀴를 재발명하거나 맞춤형 통합 코드를 처음부터 작성하지 마세요. 기초 아키텍처를 잡고, 모델들을 로드하고, 여러분의 모놀리스 애플리케이션들을 전문화되고, 결정적이며, 매우 유능한 마이크로 에이전트들로 분리하기 시작하세요.
지금 바로 퀵스타트 리소스를 활용해서 개발을 시작하세요:
- 에이전트 개발 키트 (ADK):프레임워크 살펴보기
- 에이전트 스타터 팩:프로덕션급 에이전트 배포하기
다음