AI Agent, 그 본질과 인프라에 대한 단상

요즘 AI 에이전트라는 단어가 참 많이 들린다. 꽤나 강력해 보이고, ‘자율적인 AI’처럼 들리지만, 내가 보기엔 개념이 아직 모호하다. 이 글에선 그 본질에 대해 짚어보고, 실제 동작을 위한 기술적 구조와 인프라까지 정리해본다.
에이전트란 무엇인가?
내가 이해하는 AI 에이전트란, 사람이 직접 요청하지 않아도, 특정 조건이나 이벤트에 의해 자동 트리거되고, 전달받은 데이터를 해석해, 조건에 맞는 외부 액션을 수행하는 일종의 ‘지능화된 자동화 도구’에 가깝다.
기존 자동화 시스템처럼 단순히 입력-출력을 수행하는 것이 아니라, 주어진 데이터를 해석하고 판단을 포함한다는 점에서 차별점이 있다.
LLM이 해석한 뒤 행동하기까지
AI 에이전트는 기본적으로 3단계 구조를 가진다:
- Trigger: 특정 이벤트나 입력(웹훅, 타임 트리거 등)에 의해 실행됨
- Interpret: LLM이 데이터/명령을 해석하고 판단함
- Act: 외부 시스템에 API 요청 등을 통해 액션 수행
여기서 핵심은 2번에서 3번으로 넘어갈 때 발생한다. 해석한 결과가 명확한 구조를 갖지 않으면, 행동이 불가능하기 때문이다.
구조화된 출력(Structured Output)은 필수다
LLM은 기본적으로 자유 텍스트를 생성하는 모델이다. 하지만 API를 호출하거나 외부 시스템과 연동되려면, 정해진 형식의 출력이 필요하다. 이를 가능하게 하는 것이 바로 "Structured Output"이다.
대표적인 예시로는 JSON 형태의 출력이 있다:
{
"action": "send_email",
"recipient": "example@example.com",
"subject": "AI Agent 테스트",
"body": "이메일 본문 내용입니다."
}
이런 구조화된 출력이 있어야만, 다음 단계에서 어떤 도구나 API를 호출할지 명확해지고, 안정적으로 액션을 수행할 수 있다.
함수 호출 인터페이스는 직접 정의한다
에이전트가 외부 시스템과 연결되기 위해서는, 어떤 기능을 호출할 수 있는지 사전에 정의되어 있어야 한다. 이것이 바로 Function Calling Interface다.
예를 들어 OpenAI API에서는 다음과 같은 JSON 스키마로 함수 정의를 제공한다:
{
"name": "get_weather",
"parameters": {
"type": "object",
"properties": {
"location": { "type": "string" }
},
"required": ["location"]
}
}
LangChain, OpenAI, Vertex AI 등 다양한 플랫폼이 이런 방식의 함수 호출을 지원한다. 개발자가 직접 도구를 설계하고, LLM이 호출할 수 있도록 구조화하는 방식이다.
Model Context Protocol(MCP): 상호운용성을 위한 표준
2024년 말, Anthropic이 발표한 **Model Context Protocol (MCP)**은 AI 모델과 외부 시스템 간의 상호작용을 표준화하기 위한 오픈 프로토콜이다.
특징은 다음과 같다:
- Anthropic 주도로 개발되었지만 벤더 종속성이 없다
- OpenAI, Google DeepMind 등 주요 LLM 벤더들도 채택 중
- LLM이 외부 MCP 서버에 요청하여 데이터를 받아오거나 도구를 사용할 수 있음
- 마치 브라우저와 웹서버처럼, 표준화된 클라이언트-서버 구조
MCP의 등장으로 인해, 에이전트들이 다양한 데이터 소스 및 도구들과 더 쉽게 통합될 수 있는 길이 열렸다.
결론: 에이전트는 점점 OS가 되어간다
AI Agent라는 개념은 단순한 챗봇의 확장을 넘어, 점점 운영체제(OS)적인 추상화 계층을 지향한다. LLM은 해석 엔진이고, Function Calling은 시스템 콜이며, Structured Output은 그 인터페이스, MCP는 그 운영 체계 간 프로토콜이다.
이 흐름을 잘 이해하고 따라간다면, 나만의 AI 에이전트를 만들고 실제 업무에 적용하는 것이 더는 먼 이야기가 아니다.