에이전트가 현실 세계에 어떻게 접근하는지 - 그리고 보안 재앙을 초래하지 않고 이를 수행하는 방법

언어 모델(Language Model) 그 자체는 유리병 속의 뇌와 같습니다. 날씨에 대해 아름답게 추론할 수는 있지만, 감각도 손도 없기 때문에 실제로 밖에 비가 오고 있는지에 대해서는 아무것도 말해줄 수 없습니다. **도구(Tools)**는 바로 그 감각이자 손입니다. 도구는 항공권을 예약하는 것에 대해 말할 수 있는 모델을 실제로 예약할 수 있는 에이전트(Agent)로 바꿔주는 단 하나의 기능입니다. 지난 포스트에서는 에이전트 루프(Agent loop)를 살펴보았습니다. 이번 포스트는 그 루프 내부의 실행(Act) 단계에 관한 것입니다.

도구의 실제 정체

전문 용어를 걷어내고 보면 도구는 두 가지로 이루어져 있습니다: 함수(Function), 그리고 모델이 읽을 수 있는 설명(Description)입니다. 함수는 데이터베이스 쿼리, HTTP 호출, 셸 명령과 같은 일반적인 코드입니다. 설명은 도구의 이름, 기능, 그리고 어떤 인자(Arguments)를 받는지 모델에게 알려주는 스키마(Schema)입니다. 모델은 여러분의 코드를 절대 보지 못합니다. 오직 스키마만을 보며, 눈앞의 목표를 달성하기 위해 이 도구가 적절한지 그 순간에 결정합니다.

def get_weather(city: str) -> dict:
    """도시의 현재 상태를 반환합니다."""
    return weather_api.current(city)
...

안전을 지키는 단 하나의 규칙: 결정 vs 실행

이 포스트 전체에서 가장 중요한 문장은 이것입니다. 모델은 결정하고, 여러분의 코드가 실행합니다. 모델이 "도구를 호출(Calls a tool)"할 때, 모델은 아무것도 실행하지 않습니다. 대신 함수의 이름과 인자를 명시한 구조화된 요청(Structured request)을 반환할 뿐입니다. 여러분의 애플리케이션이 그 요청을 수신하여, 허용 여부를 결정하고, 실제 함수를 실행한 뒤, 그 결과를 다시 루프에 전달합니다.

LLM은 무엇을 할지 결정해야 하지만, 결코 직접 실행하는 주체가 되어서는 안 됩니다. 모델의 의도와 실제 세계의 영향 사이에 여러분의 코드 계층을 유지하십시오.

의도와 실행 사이의 그 간극은 검증(validation), 권한 확인(permission checks), 속도 제한(rate limits), 그리고 위험한 작업에 대한 인간의 승인(human approval)을 배치해야 하는 지점입니다. 그 간극을 무너뜨려 모델이 코드를 직접 실행하게 만든다면, 여러분은 예측 불가능한 시스템에 인프라의 열쇠를 넘겨주는 셈이 됩니다.

# 결정(decide) -> 실행(execute) -> 관찰(observe)의 전체 사이클

response = client.chat(messages=history, tools=schemas)
...

모델이 실제로 사용할 수 있는 도구 설계하기

에이전트(Agent)의 역량은 도구가 얼마나 잘 설계되었느냐에 달려 있으며, 대부분의 에이전트 실패는 모델의 성능 부족보다는 도구의 설명이 부실하거나 범위(scope)가 잘못 설정된 데서 기인합니다. 몇 가지 원칙만 지켜도 큰 도움이 됩니다:

• 사용자가 아닌 모델을 위해 이름과 설명을 작성하십시오. 모델이 추측해야 하는 영리한 내부 명칭보다는, 언제 사용해야 하는지에 대한 한 줄 설명이 포함된 cancel_order(order_id) 형식이 훨씬 낫습니다.
• 각 도구의 범위를 좁게 유지하십시오. 하나의 도구에는 하나의 작업만 할당하십시오. 모드 플래그(mode flag)를 가진 단일 do_everything 도구는 모델이 작업 자체가 아닌 여러분의 구현 방식에 대해 추론하도록 강제합니다.
• 입력을 검증하고 유익한 오류를 반환하십시오. 스택 트레이스(stack trace)를 반환하는 대신, *“오류: 도시 ‘Xyz’를 찾을 수 없습니다. 올바른 도시 이름을 입력하셨나요?”*와 같이 반환하십시오. 모델은 해당 오류를 읽고 다음 루프에서 스스로를 수정합니다.
• 멱등성(Idempotency)을 선호하십시오. 에이전트는 재시도(retry)를 합니다. 두 번 호출되었을 때 카드를 두 번 결제하는 도구는 위험 요소입니다. 반복 실행되어도 안전하도록 설계하십시오.

M×N 문제, 그리고 MCP가 존재하는 이유

도구가 제대로 작동하기 시작하면 확장성 문제가 나타납니다. 만약 M개의 에이전트 애플리케이션이 있고 연결하려는 N개의 시스템(Slack, GitHub, 데이터베이스, Google Drive 등)이 있다면, 단순한 방식으로는 M×N개의 맞춤형 통합(custom integrations)이 필요합니다. 즉, 모든 앱이 모든 시스템에 대한 커넥터를 매번 새로 구현해야 합니다. Anthropic이 도입하여 현재 널리 채택되고 있는 **Model Context Protocol (MCP)**는 이를 M+N으로 축소합니다. MCP는 종종 “AI 도구를 위한 USB-C”라고 묘사되는 개방형 표준으로, 모델이 규격을 준수하는 모든 서버에 노출된 도구를 발견하고 호출할 수 있는 공통된 방식을 정의합니다.

2026년 에이전트 스택(agent stack)의 분업은 명확합니다. MCP는 에이전트가 도구 및 데이터와 통신하는 방식을 표준화하며, 에이전트 간(Agent-to-Agent, A2A) 프로토콜은 에이전트들이 서로 통신하는 방식을 표준화합니다. 도구를 MCP 서버로 한 번만 구축하면, LangGraph, CrewAI, ADK, 데스크톱 어시스턴트와 같은 모든 MCP 인식 클라이언트(MCP-aware client)가 별도의 맞춤형 연결 코드(glue code) 없이 이를 사용할 수 있습니다.

# 하나의 도구를 노출하는 최소한의 MCP 서버 (Python SDK)

from mcp.server.fastmcp import FastMCP
...

그 결과로 생기는 보상은 생태계 효과입니다. 기성 MCP 서버 카탈로그가 계속 성장함에 따라, 에이전트를 새로운 시스템에 연결하는 것은 통합 코드를 작성하는 것이 아니라 _기존 서버를 가리키는 것_을 의미하게 됩니다.

도구는 공격 표면(attack surface)입니다

에이전트에게 부여하는 모든 도구는 누군가가 걸어 들어올 수 있는 문이기도 합니다. 셸 명령(shell commands)을 실행하거나 돈을 보내는 도구는 공격자의 손에 있을 때와 마찬가지로 에이전트의 손에 있을 때도 정확히 그만큼 위험합니다. 또한 프롬프트 인젝션(prompt injection) — 에이전트가 읽는 웹 페이지나 문서에 숨겨진 적대적인 지시 사항 — 은 에이전트가 가진 도구를 오용하도록 속일 수 있습니다. 도구 접근을 편의성이 아닌 보안 경계(security boundary)로 취급하십시오:

• 최소 권한 (Least privilege). 각 에이전트에게 업무에 필요한 가장 좁은 범위의 도구 세트만 부여하십시오. 그 이상은 안 됩니다.
• 되돌릴 수 없는 작업은 절대 자동 실행하지 마십시오. 결제, 삭제, 거래 등은 에이전트의 결정이 아닌 명시적인 인간의 확인을 거쳐야 합니다.
• 모든 도구 입력값을 검증하고 정화(sanitize)하십시오. 신뢰할 수 없는 사용자에 대해 수행하는 것과 정확히 동일하게 처리해야 합니다. 왜냐하면 실질적으로 그들은 신뢰할 수 없는 존재이기 때문입니다.

도구는 에이전트를 유용하게 만드는 요소이며, MCP는 전체 생태계에서 도구들을 조합 가능(composable)하게 만들고 있습니다. 하지만 가장 중요한 규율은 모델의 결정과 실제 행동 사이에 유지하는 간극입니다. 그 간극이 바로 여러분의 검증, 권한 부여, 그리고 인간의 감독이 존재하는 곳입니다. 도구 설계와 그 경계를 올바르게 설정한다면, 진정으로 유능하면서도 실제 사용자 앞에 내놓기에 안전한 에이전트를 가질 수 있습니다.