소상공인을 위한 AI 에이전트는 데모를 보여주기는 쉽지만, 신뢰를 얻기는 놀라울 정도로 어렵습니다.

데모는 깔끔해 보입니다. 에이전트를 이메일, 인보이스(invoices), CRM, 그리고 몇 개의 n8n 워크플로우(workflows)에 연결한 다음, 미납된 인보이스를 추적하거나 고객 메시지를 분류하도록 요청합니다. 에이전트는 적절한 도구(tools)를 호출합니다. 깔끔한 요약본을 작성합니다. 모두가 고개를 끄덕입니다.

하지만 월요일이 되면 상황이 달라집니다.

한 고객이 왜 잘못된 후속 조치를 받았는지 묻습니다. 사업주는 에이전트가 이메일을 보내기 전에 실제로 CRM을 확인했는지 알고 싶어 합니다. 개발자는 로그 파일(log file)을 열어보지만, 모델 프롬프트(model prompts), HTTP 요청(HTTP requests), 반쯤 유용한 타임스탬프(timestamps)의 더미만 발견할 뿐, 명확한 맥락은 찾지 못합니다.

이것이 바로 AI 자동화 장난감과 AI 자동화 시스템 사이의 경계입니다. 에이전트가 실제로 무언가를 수행한 후, 무슨 일이 일어났는지 재구성할 수 있는가?

HappyMonkey 스타일의 소상공인 자동화에서, 이는 "에이전트가 도구를 호출할 수 있는가?"라는 질문 다음으로 마주하게 될 실질적인 문제입니다. MCP는 에이전트가 외부 시스템에 연결할 수 있는 표준화된 방법을 제공합니다. n8n 및 유사한 워크플로우 도구들은 팀이 반복 가능한 비즈니스 프로세스를 실행할 수 있는 공간을 제공합니다. OpenTelemetry와 에이전트 관측성(observability) 패턴은 당신에게 부족했던 증거(receipts)를 제공합니다.

MCP는 에이전트에게 손을 제공합니다

Model Context Protocol (MCP)은 AI 애플리케이션을 로컬 파일, 데이터베이스, 도구, 검색 엔진, 워크플로우, 프롬프트 등 외부 시스템에 연결하기 위한 개방형 표준이라고 스스로를 정의합니다. 공식 문서에서는 이를 USB-C 비유를 들어 설명하는데, 이는 꽤 적절한 비유입니다. 하지만 정말 유용한 부분은 비유가 아니라 '분리(separation)'에 있습니다.

모든 통합(integration) 기능을 에이전트에 직접 하드코딩하는 대신, MCP 서버를 통해 기능을 노출합니다. 에이전트는 도구를 발견하고, 구조화된 입력값(structured inputs)으로 이를 호출하며, 구조화된 결과값(structured results)을 돌려받을 수 있습니다.

이것은 소상공인들에게 매우 중요한데, 그들의 소프트웨어 스택(software stack)은 대개 복잡하기 때문입니다. 회계사는 한 시스템에서 작업하고, 잠재 고객(leads)은 웹사이트 양식을 통해 들어오며, 예약은 캘린더에 기록됩니다. 사업주는 여전히 중요한 이메일을 수동으로 전달합니다. 만약 모든 통합마다 맞춤형 에이전트 코드가 필요하다면, 그 프로젝트는 유지보수 과정에서 결국 무너지고 말 것입니다.

MCP는 도구 접근(tool access)을 더 규칙적으로 만들어줌으로써 도움을 줍니다. 하지만 MCP가 마법처럼 작업을 안전하게 만들어주는 것은 아닙니다. 에이전트가 실제 시스템에 접근할 수 있게 되면, 에이전트가 무엇을 건드렸는지, 왜 건드렸는지, 얼마나 걸렸는지, 비용은 얼마였는지, 그리고 어떤 결과가 돌아왔는지를 반드시 알아야 합니다.

관찰 가능성 (observability) 없는 도구 접근은 그저 더 자신감 넘치는 블랙박스 (black box)일 뿐입니다.

여기서 하나의 실용적인 패턴은 정적인 MCP 서버 더미가 아닌 동적 MCP 게이트웨이 (dynamic MCP gateway)를 사용하는 것입니다. 우리는 이를 위해 로컬에서 DynamicMCPProxy를 사용합니다. IDE는 하나의 프록시(proxy)에 연결하여 프로젝트/태스크 컨텍스트 (context)를 보내고, 프록시는 활성화된 도구 수를 제어하면서 관련 MCP 서버들을 지연 활성화 (lazily activates)합니다. 이는 "도구 수프 (tool soup)" 문제를 해결할 뿐만 아니라, 증거 (receipts)를 위한 유용한 제어 지점 (control point)을 생성합니다. 즉, 모든 서버 활성화, 도구 호출 (tool call), 지연 시간 (latency), 그리고 결과가 에이전트에 도달하기 전에 한 곳을 거치게 됩니다.

워크플로우 (Workflows)는 에이전트에게 레일을 제공합니다

이 지점에서 n8n과 같은 도구들이 적합합니다. n8n의 자체 2026 가이드에서는 AI 워크플로우 자동화 (AI workflow automation)를 전통적인 앱 간 자동화 (app-to-app automation)와는 다른 것으로 정의합니다. 워크플로우 레이어 (layer)가 구조를 제공하는 동안, AI 레이어는 실행 과정에서 해석하고, 결정하고, 생성하고, 적응할 수 있습니다.

이러한 분리는 매우 유용합니다. 어떤 비즈니스 액션이 필요한지는 에이전트가 결정하게 하되, 실제 액션은 재시도 (retries), 검증 (validation), 자격 증명 (credentials), 그리고 예측 가능한 부작용 (side effects)을 갖춘 워크플로우 뒤에 배치하십시오.

예를 들어:

• lookup_customer_balance (고객 잔액 조회)
• send_payment_reminder_for_invoice (송장 결제 알림 전송)
• create_follow_up_task (후속 작업 생성)
• summarize_new_leads_from_website (웹사이트의 새로운 리드 요약)
• draft_wordpress_post_from_source_notes (출처 노트를 바탕으로 워드프레스 포스트 초안 작성)

이 각각은 MCP로 노출된 도구(tool)가 될 수도 있고, MCP 서버 뒤에 있는 워크플로우가 될 수도 있습니다. 에이전트는 선택하고, 워크플로우는 실행합니다.

하지만 다시 말하지만, 실패 후 던져야 할 질문은 "우리가 MCP를 사용했는가?"가 아닙니다. "정확히 무슨 일이 일어났는가?"입니다.

만약 송장 알림이 잘못된 사람에게 전송되었다면, 지루한 질문들에 빠르게 답할 수 있는 추적 (trace)이 필요합니다:

• 어떤 사용자 요청이 이 실행(run)을 시작했는가?
• 어떤 모델이 답변했는가?
• 어떤 도구(tools)를 호출했는가?
• 어떤 인자(arguments)를 전달했는가?
• 어떤 워크플로우(workflow)가 실행되었는가?
• 워크플로우가 재시도(retry)되었는가?
• 외부 API가 무엇을 반환했는가?
• 사람이 최종 동작을 승인했는가?

이 지루한 질문들이 바로 비즈니스에 결정적인 질문들입니다.

추적(Traces)은 거대한 로그(logs)보다 낫습니다

일반적인 애플리케이션 로그는 "이 일이 이 시간에 발생했다"라고 말합니다. 이는 유용하지만, 에이전트 실행(agent runs)은 중첩되어 있습니다. 단일 요청에는 계획(planning), 검색(retrieval), 모델 호출(model calls), 도구 호출(tool calls), 워크플로우 호출(workflow calls), 재시도(retries), 그리고 최종 응답이 포함될 수 있습니다.

추적(trace)은 당신에게 트리(tree) 구조를 제공합니다.

OpenTelemetry는 이미 일반적인 분산 시스템(distributed systems)을 추적하기 위한 공통 언어입니다. OpenTelemetry의 GenAI 시맨틱 컨벤션(semantic conventions)에는 이제 모델 요청, 토큰 사용량 및 관련 AI 작업에 대한 개념이 포함되어 있습니다. OpenTelemetry 문서는 다른 표준 계측(instrumentation) 영역과 함께 Gen AI 시맨틱 컨벤션을 나열하고 있으며, 생태계는 모델 호출과 에이전트 단계를 무작위 로그 라인이 아닌 일급 스팬(first-class spans)으로 취급하는 방향으로 움직이고 있습니다.

CNCF 또한 OpenTelemetry를 통해 Jaeger가 AI 에이전트 추적(agent traces)을 위해 진화하는 것에 대해 논의해 왔습니다. 이는 강력한 신호입니다. 에이전트 관측성(observability)은 단순히 LLM 툴링의 틈새 시장이 아닙니다. 이는 서비스, 큐(queues), 데이터베이스, API와 동일한 운영 세계로 끌려 들어가고 있습니다.

소상공인 자동화의 경우, 첫날부터 거대한 관측성 플랫폼이 필요하지는 않을 것입니다. 하지만 데이터의 형태(shape)는 올바르게 잡혀 있어야 합니다.

실질적인 추적(trace)은 다음과 같은 모습일 수 있습니다:

customer_email_triage run
  model.plan
  mcp.tool.search_customer_by_email
...

각 스팬(span)은 딱 필요한 만큼의 메타데이터(metadata)만 담아야 합니다:

span name: mcp.tool.get_recent_orders
customer_id: cust_123
workflow_run_id: n8n_456
...

기본적으로 고객의 개인적인 콘텐츠를 로그로 남기지 마세요. ID, 횟수, 상태, 지연 시간(latency), 비용, 도구 이름, 모델 이름, 그리고 승인 상태를 기록하세요. 민감한 페이로드(payload)를 보관해야 한다면, 통제된 어딘가에 보관하십시오.

그러한 설계 선택 하나가 매우 중요합니다. 소상공인들은 개인정보 보호, 비용, 또는 통제권을 중요하게 생각하기 때문에 종종 로컬 AI (local AI)나 자체 호스팅 워크플로우 (self-hosted workflows)를 원합니다. 관찰성 (Observability)이 고객의 이메일을 제3자 로깅 계정으로 뿌려버림으로써 이러한 이점을 무너뜨려서는 안 됩니다.

최소 기능 에이전트 영수증 (The minimum viable agent receipt)

만약 고객을 위해 이 스택을 구축하고 있다면, 생각보다 더 작게 시작하십시오.

모든 에이전트 실행(agent run)에 대해 다음 항목이 포함된 영수증을 저장하세요:

1. 트리거 (Trigger): 사용자 메시지, 크론 잡 (cron job), 웹훅 (webhook), 또는 수신된 이메일.
2. 결정 (Decision): 에이전트가 특정 도구(tool)나 워크플로우를 선택한 짧은 이유.
3. 도구 호출 (Tool calls): 도구 이름, 민감한 필드가 삭제된 인자 (arguments), 상태, 소요 시간.
4. 워크플로우 호출 (Workflow calls): 워크플로우 ID, 실행 ID (run ID), 상태, 재시도 횟수.
5. 모델 사용 (Model usage): 모델 이름, 지연 시간 (latency), 토큰 수 또는 로컬 런타임 추정치.
6. 인간 승인 (Human gate): 사람이 해당 동작을 승인, 편집, 또는 차단했는지 여부.
7. 결과 (Outcome): 현실 세계에서 무엇이 변했는지.

그 영수증은 처음에는 JSON 파일일 수 있습니다. 시스템이 성장하면 OpenTelemetry 스팬 (spans)이 될 수도 있습니다. 중요한 것은 누군가가 "에이전트가 왜 그렇게 행동했나요?"라고 물을 것처럼 설계하는 것입니다. 왜냐하면 실제로 누군가가 물어볼 것이기 때문입니다.

다음은 간단한 JSON 구조입니다:

{
  "run_id": "run_2026_07_04_001",
  "trigger": "inbound_customer_email",
...

이것은 화려하지 않습니다. 하지만 워크플로우가 처음으로 이상하게 작동했을 때, 운영자가 신뢰를 잃지 않도록 지켜주는 핵심적인 요소입니다.

구체적인 게이트웨이 예시

저희의 자체 스택에서, 이것은 DynamicMCPProxy를 통해 우리가 나아간 방향입니다. 이는 MCP "도구 수프 (tool soup)" 현상을 막기 위한 방법으로 시작되었습니다. 즉, IDE를 하나의 프록시 (proxy)에 연결하고, 프록시가 현재 프로젝트에 적합한 MCP 서버들을 선택하게 하며, 활성화된 도구 목록을 합리적인 예산 범위 내로 유지하는 방식입니다.

동일한 게이트웨이는 영수증을 추가하기에도 적절한 장소입니다. 최신 버전은 핸드셰이크 (handshakes), 서버 활성화, 레이지 매터리얼라이제이션 (lazy materialisation), 그리고 자식 MCP 도구 호출에 대한 JSONL 영수증 이벤트를 기록합니다. 해당 기록에는 run_id, span_id, 이벤트 유형, 호출자 신원, 상태, 지연 시간, 서버 이름, 런타임, 그리고 인자 키 (argument keys)가 포함됩니다.

중요한 보안 세부 사항은 시스템이 무엇을 기록하지 않느냐에 있습니다. HMAC 인증을 거친 사이드카(sidecar) 호출은 service:hmac와 같은 호출자로 기록되지만, HMAC 키 자체는 절대 기록되지 않습니다. 도구 인자(Tool arguments)는 가공되지 않은 고객 콘텐츠 대신 키(keys), 유형(types), 길이(lengths), 그리고 해시(hashes)로 요약되어 기록됩니다. 선택 사항인 OpenTelemetry 내보내기(export)를 통해 나중에 트레이스 형태(trace shape)를 미러링할 수 있지만, 로컬 JSONL 영수증(receipt)은 민감한 페이로드를 관측성(observability) 벤더로 전송하지 않고도 여전히 작동합니다.

이것이 제가 대부분의 소상공인용 에이전트 시스템에 사용할 패턴입니다. 우선 로컬 영수증(local receipts)을 먼저 구축하고, 워크플로우의 트래픽이 충분히 많아지거나 분산 트레이싱(distributed tracing)을 정당화할 만큼의 리스크가 발생할 때 OpenTelemetry를 도입하는 것입니다.

무엇을 가장 먼저 계측(instrument)할 것인가

소상공인과 함께 작업하고 있다면, 모든 프롬프트 토큰(prompt token)과 예외 케이스(edge case)를 계측하는 것부터 시작하지 마세요. 지원(support)의 고통이나 재무적 리스크를 유발하는 지점부터 시작하십시오.

송장(invoice) 워크플로우의 경우, 고객 조회, 송장 조회, 결제 상태, 리마인더 생성, 승인, 그리고 발송 과정을 트레이스(trace)하십시오.

리드(lead) 워크플로우의 경우, 출처, 중복 제거, 정보 보강(enrichment), CRM 쓰기, 알림, 그리고 후속 작업 생성을 트레이스하십시오.

WordPress/콘텐츠 워크플로우의 경우, 소스 URL, 요약, 초안 생성, 이미지 생성, 사람의 검토(human review), 그리고 게시 상태(publish state)를 트레이스하십시오. 특히 게시 상태가 중요합니다. 불리언(boolean) 기본값이 잘못되었다는 이유로 에이전트가 실수로 초안을 게시하는 상황을 원하는 사람은 아무도 없습니다.

Ollama를 사용하는 로컬 AI 설정의 경우, 런타임(runtime)과 폴백(fallback) 동작을 트레이스하십시오. 로컬 모델이 실패하여 시스템이 클라우드 모델로 폴백되는 경우, 이는 가시적으로 확인되어야 합니다. 만약 워크플로우가 조용히 모델을 전환한다면, 귀하의 개인정보 보호 스토리에는 구멍이 있는 것입니다.

영업의 관점은 마법이 아니라 신뢰성입니다

많은 소상공인 대상 AI 피칭(pitch)은 여전히 마법처럼 들립니다: "에이전트로 운영을 자동화해 드리겠습니다." 사업주들은 그런 말을 충분히 들었습니다.

더 나은 피칭은 훨씬 더 구체적입니다:

"우리는 반복적인 워크플로우(workflow) 하나를 자동화할 것입니다. 여러분은 에이전트가 사용한 모든 도구, 실행한 모든 워크플로우, 사람이 승인했는지 여부, 그리고 무엇이 변경되었는지를 확인할 수 있습니다. 만약 문제가 발생하면, 우리는 그 증거(receipt)를 다시 재생(replay)할 수 있습니다."

이것은 덜 화려하지만, 훨씬 더 믿음직스럽습니다.

MCP는 통합(integration)을 덜 취약하게 만듭니다. 워크플로우 도구는 동작을 반복 가능하게 만듭니다. 관찰 가능성(Observability)은 전체 과정을 책임감 있게 만듭니다.

이러한 조합이 영리한 프로토타입(prototype)과 매달 비용을 청구할 수 있는 서비스 사이의 차이를 만듭니다.

출처 노트

• Model Context Protocol 문서: MCP는 AI 애플리케이션을 데이터 소스, 도구, 워크플로우와 같은 외부 시스템에 연결하기 위한 오픈 소스 표준입니다. https://modelcontextprotocol.io/docs/getting-started/intro
• OpenTelemetry GenAI 시맨틱 컨벤션 (semantic conventions): OpenTelemetry는 GenAI 스팬(span) 및 시맨틱 컨벤션 레지스트리의 MCP 관련 영역을 포함하여, 표준 트레이싱(tracing) 컨벤션과 함께 GenAI 컨벤션을 유지 관리합니다. https://opentelemetry.io/docs/specs/semconv/gen-ai/
• CNCF / Jaeger: Jaeger는 OpenTelemetry를 통해 AI 에이전트를 추적하도록 진화하고 있습니다. https://www.cncf.io/blog/2026/05/26/how-jaeger-is-evolving-to-trace-ai-agents-with-opentelemetry/
• n8n: AI 워크플로우 자동화는 AI의 의사결정/생성과 표준화된 워크플로우를 결합하며, n8n과 같은 도구는 유연한 자동화를 위해 배치되어 있습니다. https://blog.n8n.io/best-ai-workflow-automation-tools/
• DynamicMCPProxy: 보안 우선의 JSONL 증거(receipts)와 선택적인 OpenTelemetry 내보내기(export) 기능을 포함하는 동적 MCP 게이트웨이입니다.

https://github.com/HappyMonkeyAI/DynamicMCPProxy

• 사회적 트렌드 신호 (Social trend signal): 2026-07-04 기준 X(구 트위터) 검색 결과, 실질적인 소상공인 자동화를 위한 MCP, n8n, Ollama 및 도구 라우팅 (tool routing)에 관한 실시간 논의가 확인되었습니다.