3부작 중 제1부 — MCP 에이전트 구축 및 테스트

"에이전트 (Agent)"는 모든 것을 의미하면서도 동시에 아무것도 의미하지 않는 단어 중 하나가 되었습니다. 그러니 이제 개념을 확실히 잡아봅시다.

그 자체로 거대 언어 모델 (Large Language Model, LLM)은 한 가지 일만 수행합니다. 바로 텍스트를 텍스트로 변환하는 것입니다. 질문을 던지면 답변을 예측합니다. 모델은 무언가를 찾아보거나, 실시간 시스템을 통해 사실 여부를 확인하거나, 세상 속에서 어떤 행동을 취할 수 없습니다. 모델이 "아는" 모든 것은 학습 (Training) 시점에 고정되어 있습니다.

에이전트는 모델을 도구 (Tools)와 함께 루프 (Loop)로 연결함으로써 이를 변화시킵니다. 모델이 호출할 수 있는 함수 세트(파일 읽기, API 호출, 데이터베이스 쿼리 등)를 제공하고, 각 도구의 결과값을 다시 모델에게 전달하는 루프를 구성하면 다른 일이 일어납니다. 이제 모델은 정보가 필요하다고 판단하면 도구를 요청하고, 돌아온 결과를 읽고, 그것으로 충분한지 아니면 다른 도구가 더 필요한지 결정한 뒤에야 답변을 내놓을 수 있습니다.

이 루프 — 도구 호출 또는 답변, 완료될 때까지 반복 — 가 바로 사람들이 에이전트라고 부르는 모든 시스템의 핵심이며, 다양한 프레임워크 (Framework)로 포장되어 있을 뿐입니다. 하지만 제가 보기에는 루프 그 자체만으로는 정의의 전부가 아닌 것 같습니다. 중단 조건 (Stop condition)이 없는 루프는 통제 불능의 프로세스이며, 도구 정책 (Tool policy)이 없는 루프는 발생하기만을 기다리는 보안 사고입니다. 제가 에이전트를 설정할 때 실제로 무엇을 구성하는지 명확히 정의하려고 했을 때, 결국 두 가지 별개의 요소로 결론을 내렸습니다.

에이전트 정의 (Agent definition)와 에이전트 인스턴스 (Agent instance)

저는 이 개념을 클래스 (Class)와 그 인스턴스 (Instance)처럼 두 부분으로 나누었습니다. **에이전트 정의 (Agent definition)**는 템플릿이며, **에이전트 인스턴스 (Agent instance)**는 그것이 실행되는 하나의 사례입니다. (이 정의에 대해 더 깊이 파고들고 최신 MCP 사양이 이를 어떻게 스트레스 테스트하는지에 대해 별도의 글을 작성했습니다 — 링크는 하단에 있습니다.)

에이전트 정의는 다음으로 구성됩니다:

• 호스트 루프 (the host loop) — 위에서 언급한 것과 같은 핵심 요소
• 시스템 컨텍스트 (system context) — 페르소나 (persona), 지침 (instructions). 정적이며 작성된 내용임.
• MCP 서버 세트 (MCP server set) — 이 에이전트를 위해 어떤 도구 소스 (tool sources)가 존재하는가
• 역량 경계 / 도구 정책 (capability boundary / tool policy) — 이 에이전트가 사용할 수 있는 서버와 도구는 무엇이며, 무엇에 승인이 필요한가. 이는 로그인 정보가 아니라 역할 (role)임.
• LLM — 우리가 실제로 사용하고 있는 모델
• 종료 제한 (termination limits) — 최대 반복 횟수 (max iterations), 토큰 예산 (token budget), 중단 조건 (stop conditions)
• 작업 계약 (task contract) — 이 에이전트가 무엇을 수락하고 무엇을 반환해야 하는가
• 컨텍스트 크기 전략 (context-size strategy) — 대화 내용을 모델의 컨텍스트 윈도우 (context window) 내에 어떻게 유지하는가

에이전트 인스턴스 (agent instance)는 정의 (definition)가 실제 작업을 수행할 때 생성되는 것입니다:

• 목표 (a goal) — 사용자가 실제로 요청한 것
• 작업 컨텍스트 윈도우 (a working context window) — 대화 기록, 도구 결과
• 자격 증명 (credentials) — 누구의 토큰이며, 누구를 대신하여 수행하는가
• 소비된 예산 (consumed budget) — 경과된 반복 횟수, 사용된 토큰

이 대칭성에 주목하십시오: 정의는 제한 (limits), 계약 (contracts), _역량 (capabilities)_을 보유하며, 인스턴스는 카운터 (counters), 목표 (goals), _자격 증명 (credentials)_을 보유합니다. 클래스(class)에서는 정적이고, 인스턴스(instance)에서는 동적입니다. 이 분리를 명심하십시오. 이 시리즈의 나머지 부분은 이 개념에 기반합니다.

MCP가 위치하는 곳

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 그림의 절반, 즉 호스트가 애초에 도구를 어떻게 발견하고 호출하는지를 표준화합니다. MCP 이전에는 모든 "에이전트 + 데이터 소스" 쌍마다 각각의 맞춤형 통합 (bespoke integration)이 필요했습니다. Slack 에이전트, GitHub 에이전트, 데이터베이스 에이전트가 각각 수동으로 연결되어야 했습니다. MCP는 이를 프로토콜로 전환합니다. 모든 MCP 서버는 표준 인터페이스를 통해 타입이 지정되고 발견 가능한 도구 (typed, discoverable tools)를 노출하며, MCP를 인식하는 모든 호스트는 별도의 커스텀 글루 코드 (custom glue code) 없이도 어떤 MCP 서버와도 연결할 수 있습니다.

이를 가전제품이 아니라 플러그를 표준화하는 것으로 생각하십시오. 에이전트 — 정의, 인스턴스, 그리고 그 사이의 루프 — 는 여전히 호스트 측에 존재해야 합니다. MCP는 단지 호스트가 매번 "이 특정 도구와 어떻게 대화할 것인가"를 새로 발명할 필요가 없음을 의미합니다.

실제 사례에서는 어떤 모습인가

저는 정확히 이 작업을 수행하는 작은 MCP 호스트를 구축해 왔습니다. 이 호스트는 하나 이상의 MCP 서버에 연결하고, 서버들이 노출하는 도구(tools)들을 집계하며, LLM을 대신하여 '도구 호출 또는 답변' 루프(call-a-tool-or-answer loop)를 구동합니다. 흥งาน로운 설계 결정은 순탄한 경로(happy path)에 관한 것이 아니었습니다. 그것은 SDK가 도구를 보이지 않게 자동으로 실행하도록 내버려 두고 싶은 유혹을 뿌리치는 것이었습니다. 대부분의 에이전트 프레임워크(agent frameworks)는 모델에 도구 목록을 전달하면 나머지 과정을 단 한 번의 호출로 불투명하게 처리하는 모드를 제공합니다.

저는 의도적으로 그렇게 하지 않습니다. 호스트가 수동으로 루프를 구동합니다. 대화를 보내고, 응답을 검사하여 도구 호출 요청을 확인하고, 각 요청을 배정(dispatch)하고, 결과를 다시 입력하며, 이를 반복합니다. 이때 에이전트 정의(agent definition)에 명시된 종료 제한(termination limits)을 적용하여 아무것도 통제 불능 상태로 치닫지 않게 합니다. 이는 "그냥 SDK가 하게 두는" 버전보다 수십 줄의 코드가 더 필요합니다. 하지만 이를 통해 얻는 것은 가시성(visibility)입니다. 모든 도구 호출, 모든 왕복 과정(round trip), 모든 토큰(token)이 "질문 여기 있습니다"와 "답변 여기 있습니다" 사이의 블랙박스가 아닌, 실제로 보고 측정할 수 있는 대상이 됩니다.

더 어려운 질문들을 던지기 시작하면 이 가시성이 매우 중요하다는 것을 알게 됩니다. 단순히 "에이전트가 작동하는가"가 아니라, "이 시스템 프롬프트(system prompt)가 저것보다 실제로 더 나은가", "더 저렴한 모델이 충분히 괜찮은가", "규모가 커졌을 때 비용이 얼마나 들 것인가"와 같은 질문들 말입니다. 이것들은 구축(build)에 관한 질문이 아니라 측정(measurement)에 관한 질문이며, 이 시리즈의 나머지 내용이 다루고자 하는 핵심입니다.

다음 단계: 에이전트를 구성할 때 사용할 수 있는 레버(levers)들 — 우연도 아니게, 이는 바로 위의 에이전트 정의(agent definition) 필드들과 정확히 일치합니다 — 그리고 특정 레버를 조절했을 때 상황이 좋아졌는지 나빠졌는지를 알려주는 지표(metrics)들에 대해 알아봅.

정의 자체에 대한 더 깊은 탐구: https://dev.to/langensjonathan/what-is-an-agent-a-classinstance-definition-stress-tested-against-the-2026-07-28-mcp-spec-5akp