운영(Operation)을 소유하라

MCP는 에이전트(Agent)를 도구(Tool)에 연결합니다. 워크플로(Workflow)는 도구들을 조정합니다. 스킬(Skill)은 모델에게 도구 사용법을 가르칩니다.

이 중 어느 것도 자동으로 운영(Operation)을 소유하지는 않습니다.

운영(Operation)은 지속 가능한 작업 단위입니다: 이 비밀을 해결하고, 이 실패한 배포(Deploy)를 설명하며, 이 클라우드 계정을 감사하고, 이 릴리스를 준비하며, 이 영수증들을 대조하고, 이 사고(Incident)를 요약하는 것과 같습니다. 여기에는 인증 경로(Auth path), 재시도(Retries), 로컬 컨벤션(Local conventions), 실패 분류 체계(Failure taxonomy), 출력 계약(Output contract), 안전 정책(Safety policy), 그리고 영수증(Receipt)이 포함됩니다. 만약 그 지식이 프롬프트(Prompt), 노트북 셀(Notebook cell), 워크플로 노드(Workflow node), 또는 얇은 MCP 래퍼(Wrapper) 안에 들어 있다면, 에이전트는 매번 그것을 다시 발견해야만 합니다.

최근에 사람들은 스택의 이 부분을 액션 레이어(Action layer)라고 부릅니다. 에이전트가 단순히 도구에 도달하는 것을 넘어 실제로 무언가를 수행하는 장소 말입니다. 그 명칭은 위치에 대해서는 정확하지만 실체에 대해서는 침묵하고 있습니다. 왜냐하면 액션 레이어에 힘을 실어주는 것은 각 액션 뒤에 숨겨진 운영(Operation)이 실제로 어디에 거주하느냐이기 때문입니다.

유용한 질문은 에이전트가 MCP를 사용해야 하는지 아니면 커맨드 라인(Command line)을 사용해야 하는지가 아닙니다. 답은 당연히 둘 다입니다.

유용한 질문은 다음과 같습니다:

운영(Operation)은 어디에 존재하는가?

나의 주장: 반복적이고, 구성 요소가 많으며(Composition-heavy), 개인적으로 형상화된 작업의 경우, 운영(Operation)은 종종 소유된 커맨드 표면(Command surface) 뒤에 존재해야 합니다. MCP는 그것을 노출할 수 있습니다. 워크플로는 그것을 스케줄링할 수 있습니다. 스킬은 그것을 설명할 수 있습니다. 하지만 운영(Operation) 자체는 결정론적(Deterministic)이고, 검사 가능하며(Inspectable), 재사용 가능하고, 실패에 대해 정직한 무언가로 컴파일되어야 합니다.

그것이 바로 좋은 CLI가 제공하는 것입니다. 스크립트 더미가 아닙니다. 모든 API를 위한 MCP 서버도 아닙니다. 터미널에 대한 향수도 아닙니다. 당신이 실제로 접하는 시스템 위에 구축된, 안정적이고 발견 가능하며 JSON을 사용하는 운영 레이어(Operations layer)입니다.

레이어의 실수

MCP는 실제 문제를 해결했습니다. MCP 이전에는 모든 에이전트 통합이 맞춤형 접착제(Bespoke glue)와 같았습니다. Anthropic은 MCP를 모든 에이전트와 모든 도구 사이의 커스텀 페어링을 대체하여, 에이전트를 외부 시스템에 연결하기 위한 개방형 표준으로 설명합니다.

그 승리는 실재합니다. 하지만 과도하게 확장하기 쉬운 측면도 있으며, 이는 제가 지난주 The MCP Explosion Has a Scaling Problem에서 주장했던 논점입니다. 즉, MCP가 도구 계층 (tool layer)을 점유하는 데는 성공했지만, 프로토콜 경계 (protocol boundary)가 곧 운영 경계 (operational boundary)는 아니라는 점입니다.

계층 (Layer)	소유해야 하는 것 (Owns)	소유해서는 안 되는 것 (Should not own)
기술 및 문서 (Skills and docs)	지침 (Instructions), 예시 (examples), 정책 (policies), 절차적 문맥 (procedural context)	핵심 동작 (critical behavior)의 유일한 복사본
...

MCP는 다음과 같은 질문에 답합니다: 에이전트가 어떻게 역량 (capability)에 도달하는가, 어떤 스키마 (schema)가 호출을 설명하는가, 누가 이를 호출할 수 있는가, 그리고 결과가 어떻게 돌아오는가?

반면, 운영 (operation)은 다음과 같은 질문에 답합니다: 실제로 무엇이 일어나야 하는가, 어떤 로컬 규칙이 적용되는가, 이것은 어떤 실패 유형 (failure class)인가, 재시도 (retryable)가 가능한가, 무엇을 가려야 (redacted) 하는가, 어떤 영수증이 실행을 증명하는가, 그리고 모든 호출자가 신뢰할 수 있는 출력값 (output)은 무엇인가?

이것들은 서로 다른 질문입니다. 이 질문들이 동일한 산출물 (artifact)로 붕괴될 때, 에이전트 시스템은 취약해집니다. 도구 카탈로그 (tool catalogs)는 비대해지고, 오류 모드 (error modes)는 모호해지며, 프롬프트 (prompts)에는 구전 지식 (folklore)이 쌓여갑니다. 이는 The Agent Protocol Stack Has a Runtime Gap에서 다루었던 계층 분리 (separation-of-layers)의 관점을 한 단계 아래인 여러분의 운영 (operations) 영역에 적용한 것과 같습니다.

운영 (operation)은 이를 결정론적 (deterministically)으로 실행할 수 있고 모든 호출자가 재사용할 수 있는 가장 낮은 계층에 존재해야 합니다.

개인용 에이전트의 경우, 그 계층은 종종 CLI (Command Line Interface)입니다.

점진적 발견 (Progressive discovery)의 승리

에이전트 도구화 (agent tooling)에서 발생한 첫 번째 확장성 실패는 모델의 품질이 아니었습니다. 그것은 문맥 압박 (context pressure)이었습니다.

Cloudflare의 Code Mode가 가장 깔끔한 프로덕션 사례입니다. Cloudflare API는 2,500개 이상의 엔드포인트 (endpoints)를 가지고 있습니다. 모든 엔드포인트를 개별적인 MCP 도구로 노출하면 117만 개의 토큰을 소비하게 됩니다. Code Mode는 search()와 execute()라는 두 가지 도구만을 노출하여 사용량 (footprint)을 약 1,000 토큰 내외로 유지하면서도 전체 API 표면 (API surface)에 도달합니다. 중요한 점은 토큰 감소가 아닙니다. 바로 그 형태 (shape)입니다: 먼저 검색하고, 중요한 것만 조사한 다음, 실행하는 방식입니다.

Anthropic은 클라이언트 측에서도 동일한 결론에 도달했습니다. 모든 MCP 도구 정의(tool definition)를 사전에 로드하고 대규모의 중간 결과물을 모델을 통해 라우팅하는 방식은 에이전트(agent)를 더 느리고 비용이 많이 들게 만듭니다. MCP 서버를 코드 API로 제시하면, 에이전트는 필요한 도구 파일만 조사하고 실행 환경(execution environment) 내부에서 중간 데이터를 처리할 수 있습니다. 그들의 예시 워크플로우(workflow)에서는 토큰 사용량이 150,000개에서 2,000개로 줄어들어, 98.7%의 감소율을 보였습니다.

Claude의 도구 검색(Tool Search)은 이 패턴을 명시적으로 보여줍니다: 로딩을 지연하고, 카탈로그(catalog)를 검색하며, 요청에 필요한 소수의 도구만 확장하는 방식입니다. Anthropic의 문서에 따르면, 일반적인 멀티 서버 설정에서는 유용한 작업이 시작되기 전에 도구 정의에만 대략 55,000개의 토큰을 소비할 수 있는데, 도구 검색을 사용하면 보통 이를 85% 이상 절감할 수 있습니다.

솔직한 결론은 "MCP가 실패했다"가 아닙니다. 더 날카로운 결론은 다음과 같습니다:

점진적 발견(Progressive discovery)이 승리했습니다. 세상 전체를 로드하지 마세요. 다음 핸들(handle)을 찾으세요.

훌륭한 CLI는 이미 그런 방식으로 작동합니다.

mycli discover                                          # 최상위 도메인
mycli discover secrets                                  # 하나의 도메인
mycli secrets resolve --help                            # 하나의 동사(verb)
...

에이전트에게는 전체 표면(surface)이 필요하지 않습니다. 에이전트에게 필요한 것은 카탈로그, 상세 탐색 경로(drill-down path), 그리고 곧 실행할 동사를 위한 스키마(schema)입니다.

이것이 바로 평가(evaluations)에서 CLI가 계속 등장하는 이유이기도 합니다. Arize는 MCP, CLI 기술(skills), 그리고 순수 셸(bare shell)에 대해 500개의 GitHub 작업 평가를 수행했습니다. 정확도(Correctness)는 좁은 범위 내에 머물렀습니다: MCP는 0.83, 더 짧은 CLI 기술은 0.83, 순수 셸은 _0.84_를 기록했습니다. 하지만 가장 어려운 작업에서, MCP는 기술(skills) 비용보다 6배 이상 많은 비용이 들었고, 5배 더 오래 걸렸으며, 평균적으로 더 많은 도구 호출(tool calls)을 수행했습니다. MCP 에이전트가 API 표면(API surface)으로 필요한 조합(composition)을 표현할 수 없을 때 bash로 탈출해 버렸기 때문에 도구 충실도(Tool fidelity)는 0.33으로 떨어졌습니다.

동일한 평가 결과는 MCP가 승리하는 지점도 보여줍니다. 브랜치를 생성하고 풀 리퀘스트(pull request)를 여는 작업은 create_branch와 create_pull_request가 엔드포인트 형태의 도구(endpoint-shaped tools)로 존재했기 때문에 MCP를 통해 더 잘 수행되었습니다. 여기서 우리는 다음과 같은 규칙을 얻을 수 있습니다:

엔드포인트 형태의 작업은 엔드포인트 형태의 도구에 유리하다. 조합 형태의 작업은 실행 가능한 표면(executable surfaces)에 유리하다.

작업이 깔끔한 원격 기능(remote capability)일 때는 프로토콜을 사용하십시오. 작업이 지저분한 중간 상태(intermediate state)에 대해 필터링, 조인(joining), 계산, 레드액션(redacting), 재시도(retrying) 또는 로컬 판단을 적용해야 하는 경우에는 실행 가능한 표면을 사용하십시오.

이음새(seam)는 시스템이 실패하는 지점이다

만료된 토큰은 404로 반환됩니다. 누락된 비밀값(secret) 또한 404로 반환됩니다.

따라서 에이전트의 자격 증명 가져오기(credential fetch)가 실패하면, 에이전트는 잘못된 레이어를 디버깅하는 데 10분을 허비하게 됩니다. 9개의 스크립트에 복사된 5줄짜리 인증 절차(auth dance)가 이 두 가지를 구분할 수 없기 때문입니다.

이전:

source .env
TOKEN=$(curl -s -X POST "$AUTH_URL" -d "$AUTH_BODY" | jq -r .access_token)
curl -s "$VAULT_URL/secret/$SECRET_PATH" -H "Authorization: Bearer $TOKEN" | jq -r .data.value

이것은 운영(operation)이 아닙니다. 그것은 의식(ceremony)입니다. 아마도 재시도를 할 수도 있고, 갱신을 할 수도 있으며, 인증 실패와 데이터 누락을 구분할 수도 있을 것입니다. 혹은 다음 스크립트에 수정된 버전이 복사되었을 수도 있습니다. 아마 그렇지 않을 것입니다.

이후:

mycli secrets resolve providers/openai/api-key --json

mycli secrets resolve providers/openai/api-key --json

이제 운영(operation)이 존재합니다. 이 운영이 인증 흐름 (auth flow), 토큰 갱신 (token refresh), 재시도 정책 (retry policy), 에러 분류 체계 (error taxonomy), 출력 형태 (output shape), 그리고 영수증 (receipt)을 소유합니다. 에이전트 (agent)는 만료된 자격 증명 (expired credential)과 누락된 경로 (missing path) 사이의 차이점을 추론할 필요가 없습니다. 명령어가 그것을 알려주기 때문입니다. (해당 비밀 정보 계층 (secrets layer)은 그 자체로 하나의 작은 빌드이며, 이에 대해서는 Building first-class secrets management into an AI agent에서 작성했습니다.)

유용한 명령어는 단순히 바이트 (bytes)를 반환하는 것에 그쳐서는 안 됩니다. 그것은 계약 (contract)을 반환해야 합니다.

{
  "ok": false,
  "error": {
...

이것이 모델이 추측하는 것과 시스템이 보고하는 것의 차이입니다.

승리 지점은 명령어가 더 짧아지는 것이 아닙니다. 승리 지점은 운영 (operation)이 실행 가능하고 (executable), 검사 가능하며 (inspectable), 재사용 가능하고 (reusable), 실패에 대해 정직하다는 것입니다. 인간이 호출할 수 있습니다. 에이전트 (agent)가 호출할 수 있습니다. 크론 잡 (cron job)이 호출할 수 있습니다. 서비스 (service)가 호출할 수 있습니다. 나중에 MCP 래퍼 (wrapper)가 호출할 수도 있습니다. 운영은 더 이상 프롬프트 (prompt), 워크플로 노드 (workflow node), 노트북 셀 (notebook cell), 셸 히스토리 (shell history), 또는 벤더 커넥터 (vendor connector)에 갇혀 있지 않습니다. 그것은 당신의 표면 (surface)의 일부입니다.

워크플로 (workflows)란 무엇인가?

워크플로 (workflow)는 현대 소프트웨어에서 핵심적인 하중을 견디는 아이디어 중 하나입니다. 기업의 전체 카테고리가 워크플로 원칙 위에 구축됩니다. 즉, 프로세스를 일련의 단계 (sequence of steps)로 한 번 정의하면, 엔진이 이를 스케줄링하고, 실행하고, 재시도하며, 실행되었음을 증명하도록 하는 것입니다. 하지만 이 단어는 단 하나의 의미만을 갖지 않습니다. 이 단어는 매우 다른 계층에 존재하는 도구들을 아우릅니다.

그 핵심은 오케스트레이션 (Orchestration)입니다. GitHub Actions는 푸시 (push) 또는 스케줄 (schedule)에 의해 트리거되어 저장소 내부에서 워크플로 (workflows)를 실행합니다. Airflow, Dagster, 그리고 Prefect는 종속성 (dependencies), 재시도 (retries), 백필 (backfills)을 포함하는 태스크 (tasks)의 그래프 형태로 데이터 파이프라인 (data pipelines)을 오케스트레이션합니다. Alteryx는 코드를 작성하지 않고 데이터를 결합하고 변형하는 분석가들을 위해 동일한 개념을 시각적 캔버스 (visual canvas) 위에 구현했습니다. n8n은 SaaS 앱 간의 데이터 이동을 위해 이 역할을 수행합니다. 대상은 다르지만, 형태는 하나입니다. 즉, 사전에 알려진 단계들을 거치는 통제되고 반복 가능한 경로입니다.

2026년에 이 개념은 에이전트 하네스 (agent harnesses) 영역까지 확장되었습니다. Anthropic은 그 경계를 명확히 구분합니다: 워크플로 (workflow)는 미리 정의된 코드 경로를 따라 모델과 도구를 오케스트레이션하는 반면, 에이전트 (agent)는 모델이 스스로의 프로세스를 직접 지시하도록 합니다. Claude Code는 이제 말 그대로 워크플로 프리미티브 (workflow primitive)를 제공합니다. 2026년 5월부터 리서치 프리뷰 (research preview)로 제공되는 동적 워크플로 (dynamic workflow)는 Claude가 사용자의 작업을 위해 작성한 JavaScript 스크립트입니다. 런타임 (runtime)이 이를 백그라운드에서 실행하고 작업을 최대 1,000개의 서브 에이전트 (subagents)로 분산시키며, 모든 단계의 부산물 대신 검증된 결과만을 반환합니다. 그곳에서도 패턴은 유지됩니다. 스크립트가 무엇을 어떤 순서로 실행할지 결정하는 오케스트레이터 (orchestrator) 역할을 하고, 서브 에이전트들이 실제 작업을 수행합니다.

따라서

• 워크플로우 노드(workflow node)가 인증 로직(auth logic)을 포함합니다.
• 프로바이더별 재시도(provider-specific retries) 로직을 포함합니다.
• jq 필터와 로컬 명명 규칙(local naming conventions)을 포함합니다.
• 모두가 신뢰하는 유일한 에러 핸들링(error handling)을 포함합니다.

훌륭한 계층화(layering)는 워크플로우를 가볍게 유지하고 운영(operations)에 대한 소유권을 확보합니다:

workflow trigger
  -> mycli cloud drift --stack payments-prod --json
  -> mycli deploy explain --service api --env prod --since 30m --json
...