MCP vs CLI 2편: 개인은 CLI, 조직은 MCP — 엔터프라이즈 관점의 반론

안녕하세요! 갓대희 입니다.

 

2026년 3월 14일, Charles Chen(@chrlschn, Motion 엔지니어)이 Eric Holmes의 "MCP is dead. Long live the CLI"에 대한 반론을 올렸다. "MCP is Dead; Long Live MCP!"

이전 글 "MCP는 죽었다, CLI 만세" — CLI vs MCP 논쟁 분석에서 Holmes의 주장을 정리했다.

이번에는 다른 관점에서의 이야기를 살펴보자.

Chen은 "CLI vs MCP" 논쟁에서 빠진 부분을 짚으며, 특히 엔터프라이즈 맥락에서 MCP가 왜 유효한지를 설명하려 한다.

목차

1. 들어가며 — "MCP 만세?"
   • 기존 글 리마인드
   • Charles Chen의 반론 등장
2. 인플루언서 주도 하이프 사이클
   • 6개월 전 MCP 열풍, 지금은 CLI 열풍
   • 맹목적 추종의 위험
3. 토큰 절약의 진실
   • 잘 알려진 CLI만 토큰 절약 가능
   • 커스텀 CLI의 함정
   • 점진적 컨텍스트 소비 비교
4. MCP의 이중성 — stdio vs Streamable HTTP
   • 로컬(stdio)은 CLI로 대체 가능
   • 원격(HTTP)은 게임 체인저
5. 엔터프라이즈가 MCP를 선택하는 5가지 이유
6. 간과된 무기 — MCP Prompts & Resources
7. MCP 2026 공식 로드맵 분석
8. 커뮤니티 반응 심층 분석
   • Hacker News (263포인트, 190댓글 — 작성 시점 기준)
   • GeekNews 한국 반응
9. 실전 의사결정 가이드
10. 결론 — 바이브 코딩을 넘어 에이전틱 엔지니어링으로
11. 참고 자료

핵심 요약

• Charles Chen(2026.03.14)은 "CLI vs MCP" 논쟁에서 누락된 엔터프라이즈 관점을 지적 (출처: chrlschn.dev)
• CLI 토큰 절약은 gh, aws, kubectl 같은 훈련 데이터에 있는 CLI에만 해당. 커스텀 CLI도 결국 문서화 필요
• MCP over stdio(로컬)는 대부분 불필요하지만, MCP over Streamable HTTP(원격)는 게임 체인저
• 엔터프라이즈 5대 강점: 리치 백엔드, 임시 런타임, 인증 중앙화, 텔레메트리, 표준화된 콘텐츠 전달
• MCP Prompts = 클라이언트 요청 시 받는 SKILL.md, MCP Resources = 클라이언트 요청 시 받는 /docs — 대부분의 클라이언트가 아직 미지원
• 결론: "조직은 카우보이 바이브 코딩을 넘어 조직적으로 정렬된 에이전틱 엔지니어링으로 이동해야 한다" (출처: 원문)

 

1. 들어가며 — "MCP 만세?"

2주 전 이 블로그에서 Eric Holmes의 "MCP is dead. Long live the CLI."를 분석했다. Holmes의 핵심 주장은 명쾌했다. "LLM은 이미 CLI를 잘 사용할 줄 안다. MCP라는 별도의 추상 계층은 불필요하다."

이전 글을 읽지 않았다면 — Holmes 주장 핵심 요약

• CLI의 5대 강점: LLM 친숙도(훈련 데이터에 풍부), 디버깅 투명성(직접 재현 가능), 조합 가능성(Unix 파이프), 기존 인증 체계 재활용, 운영 단순성(바이너리 하나)
• MCP의 3대 문제: 초기화 불안정(stdio 프로세스 관리), 반복 재인증(세션 끊김마다), 권한 제어 부재(도구 수준 ACL 미지원)
• 결론: "좋은 API를 만들고, 좋은 CLI를 만들어라. MCP는 불필요한 추상 계층이다."

2026년 3월 14일 Charles Chen이 같은 제목의 변주로 반론을 올렸다. "MCP is Dead; Long Live MCP!" (출처: chrlschn.dev, 2026.03.14)

Chen은 Motion의 엔지니어로, MCP를 실제 프로덕션 환경에서 사용해온 경험을 바탕으로 쓴다. Chen은 처음부터 MCP 지지자가 아니었다. Motion에서 MCP 벤더들의 제안을 모두 거절하고 직접 REST API 래퍼를 작성했을 정도였다. 그 사람이 실무를 거쳐 생각을 바꿨다는 점이 이 글을 단순한 MCP 옹호론과 다르게 만든다.

그의 핵심 메시지는 이렇다.

Chen의 핵심 주장 (원문 의역 요약)

• "MCP over stdio(로컬)는 대부분의 유즈케이스에서 불필요하다 — 여기서는 Holmes가 맞다"
• "하지만 MCP over Streamable HTTP(원격)는 완전히 다른 이야기다 — 이것은 게임 체인저"
• "엔터프라이즈와 조직 수준의 유즈케이스에서 MCP는 현재이자 미래다"

※ 위 내용은 원문의 직접 인용이 아닌 의역 요약입니다. 원문: chrlschn.dev

Chen은 Holmes를 전면으로 반박하지 않는다. 로컬 stdio MCP의 한계는 인정한다. 그러면서 Holmes가 다루지 않은 부분을 짚는다.

 

2. 인플루언서 주도 하이프 사이클

Chen이 먼저 꺼내는 건 기술 자체가 아니라 커뮤니티의 반응 패턴이다.

6개월 전과 지금의 풍경

시기	트렌드	인플루언서 메시지
2025 하반기	MCP 열풍	"MCP가 모든 것을 바꾼다! 모든 서비스에 MCP를 달아라!"
2026 초	CLI 열풍	"MCP는 죽었다! CLI면 충분하다!"
2026 3월~	???	"그때 MCP가 죽었다고 했던 거 기억나?"

Chen은 이 진자 운동(pendulum swing)을 경계한다. 기술의 가치는 유즈케이스에 따라 판단해야 하는데, 인플루언서 주도의 트렌드는 "전부 맞다" 아니면 "전부 틀리다"로 흐르기 쉽다.

GeekNews의 @sonnet도 비슷한 관찰을 했다. "MCP의 이점이 없는 용도에 무차별 사용하던 환상에서 깬 것"이라는 표현은 정확히 이 하이프 사이클의 "깨어남" 단계를 묘사한다. (출처: GeekNews)

Chen의 경고

문제는 "MCP가 죽었다"는 반동도 역시 맹목적이라는 것이다. 로컬 stdio MCP가 불필요한 상황과 원격 HTTP MCP가 필수인 상황을 구분하지 않고 "MCP 전체가 죽었다"고 선언하면, 정작 MCP가 진정한 가치를 발휘하는 영역까지 놓치게 된다.

 

3. 토큰 절약의 진실

Holmes의 근거 중 하나는 토큰 효율성이었다. "MCP는 스키마 정의, JSON-RPC 통신으로 토큰을 낭비한다. CLI는 이미 LLM이 알고 있으므로 추가 문서화가 불필요하다." Chen은 이 주장이 전제하는 것을 꼬집는다.

 

3-1. 잘 알려진 CLI만 토큰 절약 가능

gh, aws, kubectl, git — 이들은 LLM의 훈련 데이터에 풍부하게 포함되어 있다. StackOverflow에만 수만 건의 관련 질답이 있다. 이런 CLI는 확실히 MCP보다 토큰 효율적이다.

하지만 현실의 엔터프라이즈 환경에서는 어떨까?

커스텀 CLI의 현실

• 사내 배포 도구: deploy-service --env prod --version v2.3.1
• 내부 데이터 파이프라인: etl-runner --source warehouse --target analytics
• 커스텀 인프라 관리: infra-ctl scale --service api --replicas 5

이런 CLI는 LLM의 훈련 데이터에 전혀 없다. LLM이 이 도구를 사용하려면 결국 문서화가 필요하다 — AGENTS.md든, MCP 스키마든.

 

3-2. 커스텀 CLI의 함정 — AGENTS.md 문서화

Chen의 핵심 반박은 여기 있다. 커스텀 CLI를 AI 에이전트가 사용하게 하려면, 결국 AGENTS.md나 SKILL.md에 사용법을 문서화해야 한다. 이 문서화의 내용은 본질적으로 MCP 도구 스키마와 동일한 정보를 담는다.

// MCP 도구 스키마 예시 (출처: Chen 원문 의역)

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin":      { "type": "string", "description": "Departure airport code (IATA)" },
      "destination": { "type": "string", "description": "Arrival airport code (IATA)" },
      "departDate":  { "type": "string", "description": "Departure date (YYYY-MM-DD)" },
      "returnDate":  { "type": "string", "description": "Return date (YYYY-MM-DD)" },
      "passengers":  { "type": "integer", "description": "Number of passengers" },
      "cabinClass":  { "type": "string", "enum": ["economy","business","first"] }
    },
    "required": ["origin", "destination", "departDate"]
  }
}

// 동일한 기능의 CLI --help 출력 (출처: Chen 원문 참고)

$ flights search --help

Usage: flights search [OPTIONS]

Search for available flights

Options:
  --origin TEXT        Departure airport code (IATA)  [required]
  --destination TEXT   Arrival airport code (IATA)    [required]
  --depart-date TEXT   Departure date (YYYY-MM-DD)    [required]
  --return-date TEXT   Return date (YYYY-MM-DD)
  --passengers INT     Number of passengers           [default: 1]
  --cabin-class TEXT   Cabin class (economy|business|first)

위 두 가지는 형식만 다를 뿐 동일한 정보를 담고 있다. CLI의 --help 출력이 토큰을 아껴준다는 주장은, 그 CLI가 이미 LLM의 훈련 데이터에 있을 때만 성립한다.

 

3-3. 점진적 컨텍스트 소비 비교

Holmes의 또 다른 주장은 CLI의 점진적 컨텍스트 로딩이었다. 필요할 때만 --help를 호출하면 된다는 것이다. Chen은 이것도 MCP 스키마 선언과 본질적으로 같다고 지적한다.

단계	CLI 접근	MCP 접근
1. 도구 발견	AGENTS.md에서 CLI 이름 확인	tools/list로 도구 목록 조회
2. 스키마 확인	command --help 실행	도구 스키마(inputSchema) 참조
3. 실행	command --arg value	tools/call로 실행
토큰 소비	AGENTS.md + --help 출력	도구 목록 + inputSchema
차이	커스텀 도구에서는 본질적으로 동일한 양의 정보가 소비됨

핵심 통찰

"CLI가 토큰을 아낀다"는 주장은 gh, aws, kubectl처럼 LLM이 이미 알고 있는 CLI에만 해당한다. 커스텀 CLI에서는 CLI든 MCP든 동일한 양의 문서화(= 토큰 소비)가 필요하다. (출처: Chen 원문 분석)

 

4. MCP의 이중성 — stdio vs Streamable HTTP

여기가 Chen 반론의 핵심이다. "MCP"를 하나의 덩어리로 보지 말라는 것이다.

 

4-1. MCP over stdio (로컬)

stdio 전송 방식은 MCP 서버를 로컬에서 자식 프로세스로 실행하는 방식이다. Claude Desktop의 claude_desktop_config.json이나 Claude Code의 .mcp.json에서 "command": "npx"로 실행하는 것이 이 방식이다.

// stdio MCP: 로컬 프로세스로 실행

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

Chen은 이 방식에 대해서는 Holmes에 동의한다. 로컬에서 실행되는 stdio MCP는 대부분의 경우 CLI로 대체 가능하고, 프로세스 관리 오버헤드만 추가한다.

 

4-2. MCP over Streamable HTTP (원격)

Streamable HTTP 전송 방식은 MCP 서버를 원격 서비스로 운영하는 방식이다. 이것은 CLI와는 완전히 다른 차원의 이야기다.

// Streamable HTTP MCP: 원격 서비스에 연결

{
  "mcpServers": {
    "company-tools": {
      "url": "https://mcp.internal.company.com/mcp",
      "headers": {
        "Authorization": "Bearer ${COMPANY_TOKEN}"
      }
    }
  }
}

※ 위 형식은 Claude Code의 .mcp.json 클라이언트 설정 형식이다. url, headers 필드는 Claude Code가 MCP 서버에 연결할 때 사용하는 설정이며, MCP 프로토콜 스펙 자체의 필드가 아니다. (출처: Claude Code 공식 문서 - MCP)

원격 MCP가 CLI와 근본적으로 다른 이유

• CLI 바이너리 배포 불필요: 클라이언트에 아무것도 설치할 필요 없음
• 서버 측 업데이트: 도구가 바뀌면 서버만 업데이트, 클라이언트는 자동 반영
• 백엔드 직접 접근: Postgres, Redis, Apache AGE 같은 서버 백엔드에 직접 연결 가능 — CLI로는 불가능하거나 매우 복잡
• 인증 중앙화: OAuth, API 키가 서버에서 관리됨 — 개발자 로컬에 키를 배포할 필요 없음
• 텔레메트리 일원화: 모든 에이전트 호출을 한 곳에서 모니터링

GeekNews의 @m00nlygreat의 표현이 이를 깔끔하게 정리한다: "원격 실행은 MCP, 로컬 실행은 Skills" (출처: GeekNews)

stdio vs HTTP — 같은 이름, 다른 세계

"MCP가 죽었다"는 논쟁의 혼란은 이 두 가지를 구분하지 않는 데서 온다. stdio MCP의 한계를 근거로 HTTP MCP까지 부정하는 것은 "로컬 SQLite가 느리니까 PostgreSQL도 쓸모없다"고 말하는 것과 같다.

 

5. 엔터프라이즈가 MCP를 선택하는 5가지 이유

개인 개발자의 로컬 작업에서는 CLI가 더 편할 수 있다. 하지만 조직 수준에서는 다른 계산이 필요하다.

 

5-1. 리치 백엔드 (Richer Underlying Capabilities)

원격 MCP 서버는 서버 측 리소스에 직접 연결할 수 있다. 예를 들어:

• PostgreSQL: 복잡한 쿼리를 서버에서 실행하고 결과만 반환
• Apache AGE (그래프 DB): 그래프 탐색 쿼리를 CLI로 노출하기는 매우 어려움
• 내부 마이크로서비스: gRPC 엔드포인트를 MCP 도구로 래핑

CLI는 기본적으로 로컬에서 실행되는 단일 바이너리다. 서버 측 데이터베이스에 직접 접근하려면 CLI에 커넥션 스트링, 인증 정보를 넘겨야 하고, 이는 보안 문제를 야기한다.

반론/한계

다만, SSH 터널 + Bastion Host 패턴은 이미 엔터프라이즈에서 오래 사용되어 왔다. CLI + SSH 터널 조합으로 서버 측 백엔드에 안전하게 접근하는 것은 검증된 방법이다. MCP가 이를 대체할 때의 실질적 이점이 "편의성 향상"인지, "보안 수준 향상"인지는 조직 상황에 따라 판단이 달라질 수 있다.

// CLI 방식: DB 접속 정보가 로컬에 노출됨

$ psql "postgresql://user:password@prod-db:5432/main" \
  -c "SELECT * FROM orders WHERE status = 'pending'"
# 개발자 로컬에 프로덕션 DB 비밀번호가 있어야 함

// MCP 방식: DB 접속은 서버 측에서만 관리

// MCP 클라이언트가 호출:
{ "method": "tools/call",
  "params": {
    "name": "query_orders",
    "arguments": { "status": "pending" }
  }
}
// DB 비밀번호는 MCP 서버에만 존재, 개발자 로컬에 노출 안 됨

 

5-2. 임시 에이전트 런타임 (Ephemeral Agent Runtimes)

GitHub Actions, CI/CD 파이프라인, 서버리스 함수 같은 임시 실행 환경에서는 CLI 설치가 번거롭다.

임시 런타임에서의 CLI vs MCP

• CLI: 매번 바이너리 다운로드 → 설치 → 인증 → 실행. 런타임마다 반복
• MCP (HTTP): URL에 연결하면 끝. 바이너리 설치 불필요, 인증은 토큰 하나로

Hacker News의 kasey_junk도 이 점을 지적한다: "CLI가 최선이라는 주장은 코딩 에이전트가 빙산의 일각이라는 걸 간과한다." 코딩 에이전트 외에도 분석 에이전트, 고객 지원 에이전트, 모니터링 에이전트 등이 다양한 환경에서 실행된다. (출처: Hacker News)

 

5-3. 인증과 보안 (Auth and Security)

Holmes는 "CLI의 기존 인증 체계 재활용"을 장점으로 꼽았다. Chen의 반론: "그건 개인 개발자 관점이다."

관점	CLI 인증	MCP (HTTP) 인증
키 위치	개발자 로컬 (~/.aws/credentials)	서버 측 (Vault, Secrets Manager)
키 노출 범위	개발자 수 x 서비스 수	MCP 서버 1곳
키 회전	모든 개발자에게 통보 필요	서버에서 자동 회전
감사 추적	개발자별 로컬 로그 (수집 어려움)	중앙 서버에서 전체 감사 로그
OAuth 통합	각 CLI별 개별 구현	MCP 표준 OAuth 플로우

100명의 개발자가 10개의 서비스를 사용하면, CLI 방식에서는 1,000개의 인증 정보가 각 로컬에 분산된다. MCP 방식에서는 10개의 인증 정보가 서버 1곳에 집중된다.

반론/한계

다만, MCP 게이트웨이가 새로운 단일 장애점(SPOF)이 될 수 있다. 모든 에이전트 인증이 MCP 서버 한 곳을 통과한다면, 해당 서버가 다운되거나 침해될 경우 전체 시스템이 영향을 받는다. 기존 CLI 분산 인증은 "하나가 뚫려도 전체가 뚫리지 않는다"는 장점이 있었다. MCP 중앙화의 이점을 취하려면, 게이트웨이의 가용성과 보안에 그만큼 투자해야 한다.

 

5-4. 텔레메트리와 관측 가능성 (Telemetry and Observability)

에이전트가 어떤 도구를 얼마나 자주 호출하는지, 어떤 요청이 실패하는지, 평균 응답 시간은 어떤지 — 이런 데이터는 조직 수준에서 매우 중요하다.

텔레메트리 수집 비교

• CLI: 각 개발자의 로컬에서 실행됨. 호출 로그를 중앙 수집하려면 별도 래퍼(wrapper)나 에이전트 레벨 로깅 필요
• MCP (HTTP): 서버 한 곳을 지나가므로 OpenTelemetry 등으로 자연스럽게 중앙 수집 가능

Hacker News의 CuriouslyC는 자신의 자율 에이전트 Smith에 서비스 메시 + MCP를 적용한 사례를 공유했다: "정책(OPA)과 모니터링을 한 곳에서" 관리한다고 한다. (출처: Hacker News)

반론/한계

다만, CLI에서도 래퍼 스크립트(wrapper script)나 에이전트 레벨 로깅으로 유사한 텔레메트리 효과를 낼 수 있다. 예를 들어, 모든 CLI 호출을 감싸는 셸 함수를 정의하고 OpenTelemetry로 전송하는 패턴은 이미 일부 조직에서 사용 중이다. MCP의 텔레메트리가 "자연스럽게 되는" 것은 사실이지만, CLI에서 "불가능한" 것은 아니다 — 다만 추가 구현이 필요하다.

 

5-5. 표준화된 콘텐츠 전달 (Standardized Delivery)

이 부분은 다음 섹션(MCP Prompts & Resources)에서 자세히 다루겠지만, 핵심만 요약하면 이렇다.

MCP의 콘텐츠 전달 프리미티브

• MCP Prompts = 클라이언트가 요청하면 받는 SKILL.md (사용 방법 가이드)
• MCP Resources = 클라이언트가 요청하면 받는 /docs (참고 문서)
• CLI에는 이에 대응하는 표준화된 메커니즘이 없음

 

5가지 이유 요약 (출처: Chen 원문 분석 기반)

#	이유	CLI로 대체 가능?
1	서버 측 리치 백엔드 연결	어렵거나 보안 위험
2	임시 런타임 지원	매번 설치 필요
3	중앙화 인증/보안	키 분산 문제
4	중앙 텔레메트리	별도 래퍼 필요
5	표준화된 콘텐츠 전달	대응 메커니즘 없음

 

6. 간과된 무기 — MCP Prompts & Resources

Chen이 가장 아쉽다고 직접 밝힌 부분이다. MCP 프로토콜에는 Tools 외에도 Prompts와 Resources라는 두 가지 프리미티브가 있다. 하지만 대부분의 MCP 클라이언트(Claude Code, Cursor 등)가 이를 제대로 지원하지 않고 있다.

 

6-1. MCP Prompts = 클라이언트 요청 시 받는 SKILL.md

MCP Prompts는 클라이언트가 서버에 요청하면 "이 도구를 이렇게 사용하라"는 가이드를 받을 수 있는 메커니즘이다.

// MCP Prompts 예시: 클라이언트가 요청(prompts/list → prompts/get)하면 받는 사용 가이드

// prompts/list 응답
{
  "prompts": [
    {
      "name": "flight-booking-workflow",
      "description": "항공편 예약 워크플로우 가이드",
      "arguments": [
        { "name": "trip_type", "description": "편도/왕복", "required": true }
      ]
    }
  ]
}

// prompts/get 호출 시 반환되는 메시지
{
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "항공편 예약 시 다음 순서를 따르세요:\n1. searchFlights로 검색\n2. 결과를 사용자에게 보여주기\n3. 사용자 선택 후 bookFlight 호출\n주의: 왕복의 경우 반드시 returnDate를 포함하세요."
      }
    }
  ]
}

현재 개발자가 하는 일을 생각해보자. Claude Code에서 사내 도구를 쓰려면 SKILL.md나 AGENTS.md를 수동으로 작성해야 한다. MCP Prompts가 제대로 지원되면, 클라이언트가 서버에 목록을 조회하고 선택해 요청하는 방식으로 이 가이드를 받아올 수 있다. (공식 문서: Prompts는 "user-controlled" 방식 — 즉, LLM이 자동으로 호출하는 것이 아니라 사용자가 명시적으로 선택해 사용하는 구조다. 출처: modelcontextprotocol.io/docs/concepts/prompts)

 

6-2. MCP Resources = 클라이언트 요청 시 받는 /docs

MCP Resources는 클라이언트가 서버에 요청하면 참고 문서를 받을 수 있는 메커니즘이다. API 문서, 데이터 스키마, 사용 예시 등을 클라이언트가 요청해서 가져올 수 있다.

// MCP Resources 예시: 클라이언트가 요청(resources/list → resources/read)하면 받는 참고 문서

// resources/list 응답
{
  "resources": [
    {
      "uri": "docs://api/flights",
      "name": "Flights API Documentation",
      "mimeType": "text/markdown"
    },
    {
      "uri": "schema://database/orders",
      "name": "Orders Table Schema",
      "mimeType": "application/json"
    }
  ]
}

Chen의 가장 큰 실망

Chen은 Hacker News 댓글에서 직접 이렇게 밝혔다: "MCP 클라이언트들이 Prompts와 Resources를 제대로 지원하지 않는 것이 가장 실망스럽다." 현재 대부분의 클라이언트는 Tools만 지원하며, Prompts와 Resources는 사실상 무시되고 있다. (출처: Hacker News 댓글)

 

6-3. 왜 이게 중요한가

Prompts와 Resources가 제대로 지원되면, MCP 서버는 단순한 "도구 제공자"를 넘어 "지식 + 기술 + 도구"를 한 번에 전달하는 패키지가 된다.

MCP 프리미티브	CLI/에이전트 세계의 대응	전달 방식
Tools	CLI 명령어, 함수 호출	수동 설치 또는 자동 제공
Prompts	SKILL.md, AGENTS.md (사용 가이드)	클라이언트 요청 시 서버 전달
Resources	/docs, API 문서, 스키마 파일	클라이언트 요청 시 서버 전달

CLI는 --help와 man page를 제공하지만, 이것은 "도구 사용법"에 국한된다. "이 도구들을 어떤 순서로 조합해야 하는가"(Prompts)와 "관련 배경 지식은 무엇인가"(Resources)는 CLI의 범위 밖이다.

 

7. MCP 2026 공식 로드맵 분석

Chen의 주장에 무게를 더하는 게 하나 있다. MCP가 현재 진행형이라는 점이다.

2026년 3월 9일, MCP Lead Maintainer David Soria Parra가 2026년 공식 로드맵을 발표했다. (출처: modelcontextprotocol.io, 2026.03.09)

 

7-1. 4대 우선순위

#	우선순위	핵심 내용
1	Transport Evolution & Scalability	수평 확장, 세션 관리, .well-known 메타데이터 검색
2	Agent Communication	Tasks primitive(SEP-1686) 안정화, 재시도/만료 정책
3	Governance Maturation	기여자 래더, Working Group 위임 모델
4	Enterprise Readiness	감사 추적, SSO 통합, 게이트웨이, 설정 이식성

 

7-2. Transport Evolution — 수평 확장과 검색

현재 MCP 서버는 단일 인스턴스로 운영되는 경우가 많다. 로드맵은 수평 확장(horizontal scaling)과 세션 관리를 핵심 과제로 삼는다. 또한 .well-known 메타데이터를 통해 MCP 서버를 자동 발견(auto-discovery)하는 메커니즘도 포함된다.

이는 마치 웹 서비스가 단일 서버에서 로드 밸런서 뒤의 클러스터로 진화한 과정과 유사하다.

 

7-3. Agent Communication — 에이전트 간 협업

Tasks primitive(SEP-1686)는 에이전트가 다른 에이전트에게 작업을 위임하고, 그 결과를 받아오는 메커니즘이다. 재시도 정책, 만료 시간 설정 등이 포함된다.

CLI에는 이에 대응하는 표준이 없다. 셸 스크립트로 비슷한 것을 만들 수는 있지만, 표준화된 에이전트 간 통신 프로토콜과는 차원이 다르다.

 

7-4. Enterprise Readiness — 확장으로 제공

엔터프라이즈 기능이 코어 스펙 변경이 아닌 확장(extension)으로 제공된다는 점도 눈에 띈다. MCP 코어 프로토콜은 가볍게 두고, 기업 요구사항은 선택적으로 얹는 방식이다.

로드맵이 말해주는 것

• MCP는 로컬 stdio의 한계를 인식하고 있으며, 적극적으로 개선 중
• 수평 확장, 에이전트 간 통신, 엔터프라이즈 보안 — 이 세 가지는 CLI로는 표준화하기 어려운 영역
• Working Group 기반 거버넌스로 오픈 표준의 투명성 확보

출처: MCP Vision 2026, modelcontextprotocol.io

 

7-5. On the Horizon — 미래 기능

로드맵에는 "지평선 위의" 미래 기능도 언급되어 있다.

• 트리거/이벤트: 서버가 클라이언트에게 이벤트를 보내는 푸시 메커니즘
• 스트리밍 결과: 대용량 결과를 실시간 스트리밍
• DPoP (SEP-1932): Demonstration of Proof-of-Possession — 토큰 도난 방지
• Workload Identity (SEP-1933): 에이전트 자체의 정체성 관리

 

8. 커뮤니티 반응 심층 분석

 

8-1. Hacker News — MCP 옹호 측

• gbro3n "MCP over HTTP가 결정론적 게이트 역할. AI 에이전트에게 자유보다 제약이 더 중요" — 에이전트의 행동을 제어 가능한 범위 안에 두는 것이 핵심이라는 관점
• nvardakas "가장 좋은 AI 도구는 에이전트를 제약하는 것. MCP가 깔끔한 경계 제공" — "자유로운 CLI 접근"보다 "제한된 MCP 도구 세트"가 안전하다는 주장
• 0xbadcafebee "MCP는 HTTP나 SMTP처럼 표준 통신 프로토콜. 만개의 앱과 호환성" — MCP를 특정 기술이 아닌 표준 프로토콜로 보는 관점
• jabber86 "MCP는 CLI도 셸도 없는 iPad/Android 태블릿 사용자에게 필수" — 터미널 환경이 없는 디바이스에서의 MCP 가치

 

8-2. Hacker News — CLI 옹호 및 MCP 비판 측

• tptacek "왜 CLI로 안 되나? 초기 에이전트가 임의 CLI를 실행 못 했기 때문. 이제는 가능" — MCP의 존재 이유가 "초기 에이전트의 한계" 때문이었다면, 그 한계가 사라진 지금 MCP도 사라져야 한다는 논리
• tptacek (보안 비판 강화) "MCP를 쓰는 가장 큰 이유가 보안이라면, 난 확신한다: 이건 이미 끝난 기술이다(it's a dead letter). MCP 서버가 새로운 공격 표면을 만든다" — 보안 전문가 관점에서 MCP 서버 자체가 공격 벡터가 된다는 지적
• arnitdo "LLM은 순수하게 텍스트 기반이지만, 네트워크 프로토콜은 본질적으로 더 복잡하다. 텍스트 기반 엔지니어링은 결국 핵심 위에 추상화를 쌓게 되고, LLM 모델이 인코딩을 바꾸는 순간 피라미드가 무너진다" — MCP가 LLM의 텍스트 본질과 맞지 않는 복잡성을 도입한다는 근본적 회의론
• troupo "MCP는 바이브 코딩된 프로토콜이다. AI 하이프 웨이브를 타고 나왔고, 처음에 보안이 전혀 없었으며 나중에야 OAuth를 급히 볼트온했다" — MCP의 출발점 자체가 급조되었다는 비판 (※ 한국어 의역. 원문: "vibe-coded protocol that rode one of the many AI hype waves")

Chen/MCP 측 응답

• 보안 비판(tptacek)에 대해: MCP 2026 로드맵에 DPoP(SEP-1932, Demonstration of Proof-of-Possession)과 Workload Identity(SEP-1933)가 포함되어 있다. 토큰 도난 방지와 에이전트 정체성 관리가 스펙 수준에서 해결될 예정이다. (출처: MCP 2026 로드맵)
• OAuth 급조 비판(troupo)에 대해: HN의 brabel이 반론 — "이것이 올바른 순서였다. 패턴이 나타날 때까지 보안을 열어두고, 이후 스펙에 정리한 것. 처음부터 과도한 보안 설계를 하면 아무도 쓰지 않는 프로토콜이 된다." (출처: Hacker News)
• 추상화 피라미드 비판(arnitdo)에 대해: MCP의 JSON-RPC 계층이 추가 복잡성을 도입하는 것은 사실이나, HTTP/REST도 같은 비판을 받았다. 표준화의 이점이 추상화 비용을 넘어서는지는 생태계 규모에 달려 있다. 🔍 이 부분은 아직 결론이 나지 않은 진행 중인 논쟁이다.

 

8-3. Hacker News — 절충 의견

• kasey_junk "CLI가 최선이라는 주장은 코딩 에이전트가 빙산의 일각이라는 걸 간과" — 코딩 외의 에이전트 유즈케이스에서는 CLI가 답이 아닐 수 있음
• CuriouslyC "내 자율 에이전트 Smith에 서비스 메시 + MCP. 정책(OPA)과 모니터링을 한 곳에서" — 실제 프로덕션에서 MCP를 사용하는 구체적 사례

출처: Hacker News, 263 points, 190 comments (작성 시점 기준)

 

8-4. GeekNews 한국 커뮤니티

한국 GeekNews에서도 이 논쟁은 활발히 다뤄지고 있다. 이전 글에서 정리한 의견에 더해, 새로운 관점들이 추가되었다.

• @sonnet "MCP의 이점이 없는 용도에 무차별 사용하던 환상에서 깬 것" — 하이프 사이클의 "깨어남" 단계를 정확히 묘사
• @brainer "MCP를 쓴 이유가 long context 한계 때문. 이제 극복됨" — LLM 성능 향상이 MCP 의존도를 낮추는 방향으로 작용
• @jamsya "aws mcp 안 깔아도 claude code가 aws cli로 알아서 가져다 씀" — 훈련 데이터에 있는 CLI는 MCP 없이도 자연스럽게 활용됨
• @develosopher "SaaS 개발자는 CLI vs MCP 중 MCP를 먼저 선택. CLI 지원은 관리 포인트 증가" — 서비스 제공자 관점에서는 MCP가 더 효율적
• @hanje3765 "LLM 지능이 높아지면서 MCP 필요성이 모호해짐" — 모델 발전이 도구 추상화의 필요성 자체를 줄이고 있음
• @hulryung "MCP보다 CLI로 툴을 직접 만들어쓰기 시작" — 개인 개발자 수준에서는 CLI 전환이 이미 시작됨

출처: GeekNews

커뮤니티 반응에서 읽히는 패턴

개인 개발자는 CLI로 전환하는 추세, SaaS 제공자와 엔터프라이즈는 MCP(특히 HTTP)를 유지하는 추세. 이는 정확히 Chen의 주장과 일치한다 — "CLI vs MCP"는 이분법이 아니라 유즈케이스에 따른 선택이다.

 

9. 의사결정 가이드

Holmes의 글과 Chen의 반론, 커뮤니티 논의를 종합하면 하나의 의사결정 프레임워크가 그려진다.

 

9-1. 개인 개발자

권장: CLI 우선

• gh, aws, kubectl, gcloud 같은 공식 CLI가 있으면 CLI를 사용
• Claude Code, Cursor 같은 에이전트는 이미 이들을 자연스럽게 활용
• Notion, Linear 같은 CLI 없는 서비스에만 MCP 서버 사용
• 로컬 MCP(stdio) 대신 Skills 파일로 에이전트를 안내하는 것도 좋은 대안

 

9-2. 팀 (5~50명)

권장: 하이브리드 — CLI + HTTP MCP

• 외부 서비스 연동: 공식 CLI 우선
• 내부 도구 공유: HTTP MCP 서버 구축 고려
  • DB 접근 권한을 서버에서 관리
  • 팀 전체의 에이전트 사용 패턴을 모니터링
• CI/CD 파이프라인의 에이전트: HTTP MCP가 CLI보다 편리

 

9-3. 엔터프라이즈 (50명 이상)

권장: HTTP MCP 중심 아키텍처

• MCP 게이트웨이: 모든 에이전트 트래픽이 통과하는 중앙 지점
  • 인증: OAuth/SSO 통합
  • 권한: 역할 기반 도구 접근 제어
  • 감사: 전체 호출 로그
  • 관측: OpenTelemetry 메트릭
• CLI도 병행: 개별 개발자의 로컬 작업에서는 CLI가 여전히 효율적
• MCP Prompts/Resources 활용 준비: 클라이언트 지원이 확대되면 즉시 적용

 

9-4. SaaS 서비스 제공자

권장: API → MCP → CLI 순서

1. 좋은 REST API를 먼저 — 모든 것의 기반
2. MCP 서버를 제공 — 에이전트 생태계에 자연스럽게 편입 (GeekNews @develosopher 의견과 일치)
3. CLI는 파워 유저를 위한 보너스로 — 관리 포인트가 증가하므로 우선순위 판단 필요

 

9-5. 의사결정 플로우차트

해당 서비스에 공식 CLI가 있는가?
  |
  +-- Yes --> LLM 훈련 데이터에 있는가? (gh, aws, kubectl 등)
  |             |
  |             +-- Yes --> CLI 사용 (토큰 효율 우수)
  |             +-- No  --> CLI + AGENTS.md 문서화
  |
  +-- No  --> 로컬에서만 쓰는가?
                |
                +-- Yes --> MCP (stdio) 또는 API 래퍼
                +-- No  --> 팀/조직 공유인가?
                              |
                              +-- Yes --> MCP (HTTP) 권장
                              |           - 중앙 인증
                              |           - 텔레메트리
                              |           - 자동 배포
                              +-- No  --> MCP (stdio) 가능

 

9-6. 당장 해볼 수 있는 3가지

Quick Start — 오늘 퇴근 전에 할 수 있는 것

1. 현재 사용 중인 MCP 서버 목록을 뽑고, CLI로 대체 가능한 것을 식별하라 — claude mcp list로 설치된 MCP 서버를 확인하고, 그 중 gh, aws, kubectl 등 공식 CLI가 있는 서비스는 MCP를 제거해도 되는지 검토
2. 팀 내부 도구 하나를 HTTP MCP로 래핑하는 PoC를 해보라 — FastMCP 등을 사용하면 Python 함수 몇 개로 MCP 서버를 띄울 수 있다. 내부 API 하나를 래핑해서 실제 에이전트가 호출하는 것까지 테스트
3. claude mcp list 또는 MCP Inspector로 현재 서버의 도구 수/토큰 소비를 측정하라 — 도구가 50개 이상 등록되어 있다면, 초기 컨텍스트에 스키마만으로 수천 토큰이 소비되고 있을 수 있다. 실제 사용 빈도가 낮은 도구는 정리 대상

 

10. 결론 — 바이브 코딩을 넘어 에이전틱 엔지니어링으로

두 주장을 나란히 놓고 보면 이런 그림이 나온다.

 

Holmes가 맞는 부분

• LLM은 이미 유명 CLI를 잘 사용한다 — 이 CLI들에 MCP를 추가하는 것은 비효율적
• 로컬 stdio MCP는 프로세스 관리 오버헤드를 추가한다
• 디버깅 투명성과 파이프라인 조합성에서 CLI가 우위
• "좋은 API를 만들고, 좋은 CLI를 만들어라" — 이 원칙은 여전히 유효

 

Chen이 맞는 부분

• 커스텀 CLI도 결국 문서화가 필요하다 — 토큰 절약은 유명 CLI에만 해당
• stdio와 HTTP를 구분하지 않고 "MCP가 죽었다"고 하는 것은 오류
• 엔터프라이즈 인증, 텔레메트리, 감사 추적에서 HTTP MCP는 대안이 없다
• MCP Prompts/Resources는 클라이언트 지원만 따라오면 쓸 수 있는 기능인데, 아직 대기 중

 

최종 정리

"MCP는 죽었다"도, "MCP 만세"도 전체 그림이 아니다.

더 정확한 표현은 이렇다:

• 개인 바이브 코딩에서는 CLI가 더 효율적인 경우가 많다
• 조직 수준의 에이전틱 엔지니어링에서는 HTTP MCP가 현재이자 미래

Chen의 마지막 문장을 그대로 옮긴다.

"조직은 카우보이 바이브 코딩을 넘어, 조직적으로 정렬된 에이전틱 엔지니어링으로 이동해야 한다."

원문: "Organizations need architectures and processes that start to move beyond cowboy, vibe-coding culture to organizationally aligned agentic engineering practices." (출처: chrlschn.dev)

저자 관점 — 한국 엔터프라이즈에 시사하는 바

이 논쟁이 한국 독자에게 특히 중요한 이유가 있다. 한국 엔터프라이즈는 이제 막 AI 에이전트 도입을 본격화하고 있고, "MCP를 도입할 것인가, CLI로 갈 것인가"는 지금 당장의 아키텍처 결정이다. CLI가 개인 개발자의 생산성 도구라면, MCP(HTTP)는 조직의 거버넌스 인프라다. 둘 다 필요하고, 순서와 비중이 중요하다.

6개월 후 이 글을 다시 읽었을 때, MCP의 DPoP/Workload Identity가 실제 스펙에 반영되었는지, Prompts/Resources를 지원하는 클라이언트가 늘었는지, 그리고 CLI 생태계가 에이전트 네이티브로 얼마나 변했는지를 확인해보자. 이 세 가지가 이 논쟁의 실질적인 답이 될 것이다.

 

이 글을 읽은 후, 당신의 환경에 맞는 질문을 던져보자.

• 지금 사용 중인 MCP 서버 중, CLI로 대체 가능한 것은 무엇인가?
• 팀의 에이전트 사용 패턴을 중앙에서 모니터링하고 있는가?
• 내부 도구의 인증 정보가 몇 곳에 분산되어 있는가?
• CI/CD 파이프라인에서 에이전트가 매번 CLI를 설치하고 있지는 않은가?

이 질문들에 대한 답이 "CLI vs MCP" 논쟁에서 당신의 조직에 맞는 답을 알려줄 것이다.

 

11. 참고 자료

자료	링크	비고
Charles Chen 반론 원문	chrlschn.dev	Charles Chen (@chrlschn), 2026.03.14
Charles Chen 반론 (ITNEXT 교차 게시)	itnext.io	ITNEXT 교차 게시, 동일 내용
Eric Holmes 원문	ejholmes.github.io	Eric Holmes, 2026.02.28
이전 글 (CLI vs MCP 분석)	mcp_vs_cli.html	이 블로그 전편
Hacker News 토론	news.ycombinator.com	263 points, 190 comments (작성 시점 기준)
GeekNews 한국 토론	news.hada.io	한국 커뮤니티 반응
MCP 2026 공식 로드맵	modelcontextprotocol.io	David Soria Parra, 2026.03.09
MCP 공식 문서	modelcontextprotocol.io	Anthropic 공식
MCP Prompts 공식 문서	modelcontextprotocol.io/docs/concepts/prompts	MCP Prompts 프리미티브
MCP Resources 공식 문서	modelcontextprotocol.io/docs/concepts/resources	MCP Resources 프리미티브