AI 에이전트란 무엇인가? 왜 지금 모든 스타트업이 에이전트를 만들고 있는가? Google의 64페이지 기술 가이드를 바탕으로, 핵심 아키텍처부터 프로덕션 운영까지 완전 해부합니다. 풍부한 사례와 인터랙티브 시뮬레이터로 직접 체험해보세요.
2024년까지 AI의 주역은 챗봇이었습니다. "질문하면 답한다" — 그것이 전부였죠. 하지만 2026년, 게임의 규칙이 완전히 바뀌었습니다.
Google Cloud CEO 토마스 쿠리안의 말을 빌리자면:
"에이전트 워크플로우는 다음 프론티어입니다. 단순히 질문하고 답을 얻는 게 아닙니다. AI에게 복잡한 목표를 주고 — '이 제품 런칭을 기획해줘' 또는 '이 공급망 문제를 해결해줘' — 그 목표를 달성하기 위해 필요한 다단계 작업을 스스로 조율하게 하는 것입니다."
챗봇과 에이전트의 차이를 한 문장으로 정리하면 이렇습니다:
에이전트는 생각하고, 행동하고, 관찰하고, 다시 생각합니다. 단일 응답이 아니라 목표를 향한 자율적 문제 해결을 수행합니다. 그리고 이 글은 이 혁명적 변화의 모든 것을 다룹니다.
이 글은 Google이 2025년 발행한 64페이지 분량의 기술 가이드 "Startup Technical Guide: AI Agents"를 깊이 분석하고, 역사적 맥락과 풍부한 사례를 더해 재구성한 특집 기사입니다.
AI 에이전트의 개념은 사실 새롭지 않습니다. 1950년 앨런 튜링이 "기계가 생각할 수 있는가?"라는 질문을 던진 이래, "스스로 판단하고 행동하는 소프트웨어"는 AI 연구의 궁극적 목표였습니다.
핵심 전환점은 2022년 ReAct 논문입니다. 이 논문이 왜 중요한지, 그리고 이것이 어떻게 오늘날 모든 AI 에이전트의 뼈대가 되었는지 — 지금부터 깊이 파고들어 보겠습니다.
2022년, 프린스턴 대학의 Yao et al.이 발표한 논문 "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)은 AI 에이전트 아키텍처의 판도를 바꿨습니다.
핵심 아이디어는 놀랍도록 단순합니다:
LLM이 "생각"과 "행동"을 번갈아 하게 하면, 둘 다 더 잘하게 된다.
기존 접근법의 한계를 먼저 봅시다:
| 접근법 | 방식 | 한계 |
|---|---|---|
| Chain-of-Thought (CoT) | 추론만 함 (Think, Think, Think...) | 외부 정보 접근 불가, 환각(hallucination) 위험 |
| Act-only | 행동만 함 (Act, Act, Act...) | 계획 없이 행동 → 비효율적, 실패 복구 불가 |
| ReAct | 추론과 행동을 교차 (Think → Act → Observe → Think...) | 추론이 행동을 안내하고, 행동이 추론에 정보를 제공 |
ReAct는 세 가지 단계가 순환하는 루프입니다:
아래 시뮬레이터에서 실제 에이전트가 어떻게 생각하고, 행동하고, 관찰하는지 단계별로 체험할 수 있습니다. "자동 재생"을 누르면 에이전트의 전체 추론 과정을 볼 수 있어요.
위 시뮬레이터의 "환불 처리" 시나리오를 코드로 보면 이렇습니다. Google의 Agent Development Kit(ADK)에서는 ReAct 루프가 LlmAgent 클래스에 내장되어 있어, 개발자가 직접 루프를 구현할 필요가 없습니다:
from google.adk import LlmAgent
refund_agent = LlmAgent(
name="refund_agent",
model="gemini-2.5-flash",
instruction="""
고객의 환불 요청을 처리하는 전문 에이전트입니다.
1. 먼저 환불 정책을 검색하세요.
2. 주문 정보를 조회해 환불 조건을 확인하세요.
3. 조건이 충족되면 환불을 실행하세요.
""",
tools=[semantic_search, get_order_details, process_refund]
)
에이전트가 instruction과 tools만 받으면, 나머지 추론 과정은 LLM이 ReAct 루프를 돌면서 자율적으로 결정합니다. 이것이 규칙 기반 챗봇과의 결정적 차이입니다.
모든 프로덕션급 AI 에이전트는 네 가지 핵심 구성 요소로 이루어집니다. Google의 가이드에서는 이를 모델, 도구, 오케스트레이션, 런타임으로 정리합니다.
에이전트의 모델 선택은 "가장 강력한 모델을 고르는 것"이 아닙니다. 핵심은 능력, 속도, 비용의 최적 균형을 찾는 것입니다.
Google 가이드가 강조하는 핵심 원칙:
강력한 인지 아키텍처는 여러 전문화된 에이전트를 활용하며, 각각이 자신의 서브 태스크에 가장 효율적인 모델을 동적으로 선택합니다. 무거운 모델은 복잡한 추론에, 가벼운 모델은 일상적인 쿼리에 배정하세요.
이 원칙은 2025년 DeepSeek이 600만 달러로 OpenAI o1급 추론 모델을 만든 사건과 맥을 같이 합니다. 비싼 모델을 무조건 쓰는 시대는 끝났습니다.
도구(Tools)는 에이전트가 추론을 넘어 실제 세계에서 행동할 수 있게 해주는 인터페이스입니다.
도구의 종류는 다양합니다:
Google ADK에서 도구를 정의하는 방법은 놀랍도록 직관적입니다:
def check_inventory(product_id: str) -> dict:
"""주어진 상품의 실시간 재고 수량을 반환합니다.
Args:
product_id: 상품 고유 ID (예: "SKU-12345")
Returns:
{"status": "success", "stock": int, "warehouse": str}
"""
# 실제 재고 시스템 API 호출
result = inventory_api.get_stock(product_id)
return {"status": "success", "stock": result.quantity, "warehouse": result.location}
여기서 핵심은 docstring이 모델의 주요 정보원이라는 점입니다. 도구의 이름, 설명, 파라미터 타입 힌트가 곧 "모델과의 API 계약서"가 됩니다. 설명이 모호하면 모델이 도구를 잘못 선택하고, 에이전트가 무한 루프에 빠집니다.
오케스트레이션은 에이전트의 실행 기능(executive function)입니다. 어떤 도구를, 어떤 순서로, 어떻게 조합할지를 결정합니다.
아래 탐색기에서 다양한 에이전트 타입을 클릭해보세요:
에이전트가 완성되었다면, 이제 실제 사용자에게 배포해야 합니다. 런타임은 확장성, 보안, 안정성을 제공합니다.
| 배포 옵션 | 적합한 팀 | 핵심 장점 |
|---|---|---|
| Vertex AI Agent Engine | 시드~시리즈A 스타트업, 소규모 엔지니어링 팀 | 완전 관리형, 자동 스케일링, 수일 내 배포 |
| Cloud Run | 빠른 성장 중인 스타트업, 마이크로서비스 아키텍처 | 서버리스, 요청 시에만 과금, 컨테이너 커스터마이징 |
| GKE (Kubernetes) | 시리즈B+, 플랫폼 엔지니어링 팀 보유 | 세밀한 제어, GPU/TPU 지원, 기존 인프라 활용 |
2024년까지 많은 기업이 "하나의 만능 AI"를 꿈꿨습니다. 하지만 현실은 달랐죠. 하나의 에이전트에 모든 도구를 넣으면:
해법은 인간 조직과 동일한 구조 — 전문화된 에이전트 팀입니다.
Google의 Agent Development Kit(ADK)는 처음부터 멀티 에이전트 설계를 전제합니다. 앞서 에이전트 아키텍처 탐색기에서 본 것처럼, 다양한 에이전트 타입을 레고처럼 조합할 수 있습니다.
실제 예시를 봅시다. 소프트웨어 버그 분류 시스템을 만든다면:
ADK의 강력한 패턴 중 하나가 Agent-as-a-Tool — 한 에이전트가 다른 에이전트를 도구처럼 사용하는 것입니다.
# 전문가 에이전트 정의
code_analyst = LlmAgent(
name="code_analyst",
model="gemini-3-pro", # 복잡한 코드 분석엔 강력한 모델
instruction="코드를 분석하고 버그의 근본 원인을 파악하세요.",
tools=[search_codebase, read_file]
)
# 오케스트레이터가 전문가를 도구로 사용
triage_agent = LlmAgent(
name="bug_triage_agent",
model="gemini-2.5-flash", # 조율 작업엔 가벼운 모델
instruction="버그 리포트를 분석하고 우선순위를 매기세요.",
tools=[get_user_details, code_analyst, create_jira_ticket]
# ↑ 에이전트를 도구로!
)
이 구조의 장점은 모델 비용 최적화입니다. 조율 작업은 저렴한 Flash 모델이, 복잡한 코드 분석은 강력한 Pro 모델이 담당합니다.
AI의 가장 큰 약점은 환각(Hallucination) — 그럴듯하지만 사실이 아닌 내용을 생성하는 것입니다. 에이전트가 잘못된 정보를 기반으로 행동하면 그 결과는 치명적입니다. 잘못된 환불, 틀린 의료 정보, 부정확한 투자 조언...
이 문제의 해답이 그라운딩(Grounding) — 에이전트의 응답을 검증 가능한 사실에 기반시키는 기술입니다.
RAG (Retrieval-Augmented Generation)는 LLM이 답변하기 전에 외부 지식 베이스에서 관련 정보를 검색하는 패턴입니다.
전통적 데이터베이스와 벡터 DB의 차이를 실감할 수 있는 예시입니다:
기본 RAG는 "비슷한 문장 찾기"에 강하지만, 개념 간의 관계는 이해하지 못합니다. 예를 들어 "이 약의 부작용과 관련된 다른 약물은?" 같은 질문은 단순 유사도 검색으로 풀 수 없습니다.
GraphRAG는 데이터를 지식 그래프로 구축해, 개념 간의 관계를 명시적으로 표현합니다.
실제 사례로, BioCorteX는 440억 개 연결의 지식 그래프를 구축하고, Gemini 기반 에이전트와 A2A 프로토콜로 신약 개발 과정을 수년에서 수일로 단축했습니다.
가장 진보된 형태인 Agentic RAG에서는, 에이전트가 수동적으로 검색 결과를 받는 게 아니라 능동적으로 검색 전략을 수립합니다.
ReAct 프레임워크와 결합하면 에이전트는:
사용자: "SolarFlare 러닝화 재고 있어?"
에이전트 추론 과정:
1. 먼저 product_lookup으로 정확한 상품 특정 (시맨틱 검색)
2. check_inventory로 실시간 재고 확인 (API 호출)
3. "네! SolarFlare 러닝화 재고가 82켤레 있습니다." (근거 기반 답변)
웹이 HTTP 없이는 불가능했듯, 에이전트 생태계도 통신 표준 없이는 확장할 수 없습니다.
| 웹의 역사 | AI 에이전트 | 역할 |
|---|---|---|
| HTTP | A2A (Agent-to-Agent) | 에이전트 간 통신 |
| REST API | MCP (Model Context Protocol) | 도구 연결 |
| 브라우저 | 에이전트 런타임 | 실행 환경 |
| DNS | 에이전트 디스커버리 | 서비스 발견 |
Model Context Protocol (MCP)은 Anthropic이 제안한 오픈 표준으로, AI 에이전트가 외부 데이터 소스와 도구에 연결하는 방식을 표준화합니다.
MCP 이전에는 각 도구마다 커스텀 통합을 만들어야 했습니다. MCP 이후에는 — USB-C처럼 — 하나의 표준 인터페이스로 모든 도구에 연결됩니다.
# ADK에서 MCP 서버의 도구를 바로 사용
from google.adk.tools import MCPToolset
github_tools = MCPToolset(
server_url="https://github-mcp-server.example.com"
)
agent = LlmAgent(
name="dev_agent",
model="gemini-2.5-flash",
tools=[github_tools] # GitHub의 모든 MCP 도구를 자동으로 사용 가능
)
Agent2Agent (A2A)는 Google이 2025년 4월 발표하고 Linux Foundation에 기부한 오픈 프로토콜입니다. 에이전트 간의 발견, 통신, 협업을 표준화합니다.
A2A의 핵심 개념:
Box 사례가 인상적입니다. A2A 프로토콜과 ADK, Gemini를 결합해 자연어로 문서를 검색하고 인사이트를 추출하는 에이전트를 구축했습니다. 컨텐츠 중심 워크플로우의 의사결정 속도를 극적으로 향상시켰습니다.
프로토타입 단계에서는 에이전트를 직접 테스트해보고 "잘 되는 것 같은데?"로 넘어가곤 합니다. Google은 이를 "vibe testing"이라 부르며, 프로덕션에서는 절대 충분하지 않다고 경고합니다.
LLM 기반 시스템은 비결정적(non-deterministic)입니다. 같은 입력에 다른 출력이 나올 수 있습니다. 전통적인 단위 테스트만으로는 이 복잡성을 다룰 수 없습니다.
Harrison Chase (LangChain CEO):
"에이전트는 새로운 수준의 생산성을 가져다주지만, 그 성공은 우리의 안내(guidance)에 달려 있습니다."
Google이 제시하는 AgentOps의 핵심은 3계층 평가 체계입니다:
Google의 Agent Starter Pack은 위의 모든 AgentOps 원칙을 한 줄의 명령어로 구현합니다:
ADK와 Agent Starter Pack의 관계를 한 문장으로 정리하면:
ADK는 에이전트의 "무엇을 하는가"(애플리케이션 로직)를 담당하고, Agent Starter Pack은 "어떻게 운영되는가"(인프라 + CI/CD)를 담당합니다.
5단계 워크플로우:
AI 에이전트는 단순히 텍스트를 생성하는 게 아니라 실제 세상에서 행동합니다. API를 호출하고, 데이터를 수정하고, 이메일을 보냅니다. 그래서 보안과 안전은 선택이 아닙니다.
Jia Li (LiveX AI 공동창업자):
"AI 에이전트가 우리 삶에 통합될수록, 신뢰, 프라이버시, 보안에 대한 새로운 과제를 해결하는 것이 중요합니다."
Google이 제시하는 핵심 위험 카테고리:
| 위험 유형 | 예시 | 대응 방법 |
|---|---|---|
| 의도하지 않은 동작 | 안전하지 않은 응답, 부정확한 정보 | Safety attributes, 콘텐츠 필터링, 사용자 피드백 채널 |
| 프롬프트 인젝션 | 악의적 입력으로 에이전트 행동 조작 | 입력 검증 가드레일, CI/CD 보안 테스트 자동화 |
| 과도한 권한 | 에이전트가 불필요한 시스템에 접근 | 최소 권한 원칙 (IAM), Terraform으로 인프라 격리 |
| 사회적 편향 | 특정 집단에 불리한 응답 생성 | 편향 평가 도구, 모델 모니터링, RAI 가이드 |
| 감사 불가 | 에이전트의 결정 과정을 추적할 수 없음 | Cloud Trace 궤적 로깅, BigQuery 감사 추적 |
ADK와 Agent Starter Pack의 심층 방어(defense-in-depth) 전략:
Gartner가 "2026년 말 기업 앱 40%에 AI 에이전트가 내장될 것"이라 전망했지만, 현실은 좀 더 복잡합니다:
탐색+파일럿은 68%인데, 실제 프로덕션은 11%. 이 격차가 의미하는 바는 명확합니다:
AI 에이전트의 병목은 모델 성능이 아니라 엔지니어링과 운영입니다. 안정적인 오케스트레이션, 실패 복구, 모니터링, 비용 관리 — 이것들이 2026년 에이전트 경쟁의 진짜 전장입니다.
이 가이드의 핵심 메시지를 정리하면:
이 글을 한 문장으로 요약하면 이것입니다:
AI 에이전트는 소프트웨어 엔지니어링의 패러다임 전환이다.
챗봇이 "대화"의 혁명이었다면, 에이전트는 "자동화"의 혁명입니다. 복잡한 워크플로우를 자율적으로 수행하고, 새로운 사용자 경험을 창조하고, 이전에는 기술적으로 불가능했던 비즈니스 문제를 해결합니다.
프로토타입에서 프로덕션으로 가는 여정은 규율 있는 엔지니어링의 문제입니다. ReAct 루프로 추론의 뼈대를 세우고, RAG로 사실에 기반한 답변을 보장하고, MCP/A2A로 생태계를 연결하고, AgentOps로 안전하게 운영하세요.
Google Cloud CEO 순다르 피차이의 말로 마무리합니다:
"AI 에이전트는 진보된 AI 모델의 지능에 도구 접근성을 결합한 시스템이며, 사용자의 통제 아래 사용자를 대신해 행동합니다."
핵심은 "사용자의 통제 아래"입니다. 에이전트가 강력할수록, 그 힘을 제어하는 엔지니어링이 더 중요해집니다. 이 균형을 잡는 팀이 2026년 AI 에이전트 시대의 승자가 될 것입니다.