---
title: "기업은 MCP가 아니라 CLI를 제공해야 한다"
published: 2026-02-17T23:42:00.000Z
canonical: https://jeff.news/article/934
---
# 기업은 MCP가 아니라 CLI를 제공해야 한다

MCP가 POSIX를 운영체제 위에 다시 구현하고 있다는 주장의 기술 에세이. AI 에이전트에 필요한 5가지 역할(발견, 호출, 데이터 흐름, 접근 제어, 오케스트레이션)을 MCP와 POSIX로 비교하며, POSIX가 이미 모두 해결했음을 논증함. 실제로 필요한 것은 도구 매니페스트와 인증 선언이라는 2개의 얇은 정적 파일 표준뿐이라고 제안함.

## 핵심 주장: MCP는 POSIX를 재발명하고 있음

- MCP는 운영체제 위에 운영체제를 다시 만들고 있으며, MCP가 해결하는 모든 문제는 1988년 POSIX가 이미 해결한 것임
- AI 에이전트가 환경에서 필요한 것은 정확히 5가지: 도구 발견, 도구 호출, 데이터 전달, 접근 제어, 멀티스텝 오케스트레이션이며, MCP와 POSIX 모두 이 다섯 가지를 제공함
- 차이점은 POSIX가 약 40년간 안정적으로 유지되며 수백만 개의 도구 생태계를 갖춘 반면, MCP는 아직 변경이 잦고 대부분의 통합이 기존 CLI 도구의 래퍼에 불과하다는 것임

## 5가지 역할 비교: MCP vs POSIX

- **발견(Discovery)**: MCP는 도구 스키마를 모델 컨텍스트에 로드하는데, Anthropic 자체 보고에 따르면 도구 메타데이터만으로 134,000 토큰을 소비해 대화 시작 전에 약 $0.40의 비용이 발생함. POSIX는 $PATH와 --help로 필요할 때만 바이너리를 실행함
- **호출(Invocation)**: MCP는 JSON-RPC over stdio/HTTP를 사용하고, POSIX는 fork/exec를 사용함. 기능은 동일하지만 POSIX는 40년간 수십억 대의 머신에서 검증됨
- **데이터 흐름(Data Flow)**: MCP는 모든 도구 결과를 모델의 컨텍스트 윈도우로 돌려보내 토큰 비용이 발생함. POSIX의 `curl | jq | grep` 같은 파이프는 컨텍스트 윈도우 없이 데이터를 직접 전달하므로, bash에서 몇 센트도 안 되는 5단계 파이프라인이 MCP에서는 수 달러가 들 수 있음
- **접근 제어(Access Control)**: MCP는 자체 권한 모델을 처음부터 구축 중이지만, POSIX에는 이미 사용자/그룹/파일 모드가 있음
- **오케스트레이션(Orchestration)**: MCP는 매 단계마다 모델 추론을 거치는 루프 방식이라 느리고 오류 발생이 잦음. Anthropic도 이를 인정하고 Programmatic Tool Calling을 도입함. POSIX 셸 스크립트는 추론 없이 결정적으로 실행됨

## MCP 서버 대신 CLI를 제공해야 하는 이유

- 대부분의 MCP 서버는 HTTP API나 기존 CLI를 JSON-RPC로 감싼 번역 계층에 불과하며, 지연 시간과 복잡성만 추가함
- `stripe payments list`, `gh pr create`, `aws s3 cp` 같은 CLI 도구는 이미 파이프, 스크립트, CI/CD, Docker, 셸 접근 가능한 모든 에이전트에서 작동함
- MCP 서버를 추가로 제공하면 같은 기능에 대한 두 번째 인터페이스를 유지해야 하는데, 이 인터페이스는 MCP 호환 호스트에서만 작동하고 파이프나 스크립트가 불가능함

## 인증 문제: 프로토콜이 아닌 런타임이 해결해야 함

- MCP의 마지막 강점은 OAuth 내장 인증이지만, 이는 프로토콜이 아닌 런타임의 기능임
- `gh auth login`이 채팅 UI에서 매끄럽게 작동하지 않는 이유는 아직 누구도 그 브릿지를 만들지 않았기 때문일 뿐임
- 에이전트 런타임이 인증 요청을 가로채서 OAuth 흐름을 UI에 표시하고 토큰을 환경변수로 설정하면 CLI가 그대로 작동함

## 실제로 필요한 것: 2개의 얇은 표준

- POSIX와 AI 에이전트 사이의 실제 간극은 발견(discovery)과 인증(auth) 두 가지뿐임
- **도구 매니페스트(Tool Manifest)**: CLI의 커맨드, 인자 타입, 필수/선택 입력을 기술하는 정적 파일. `package.json`이나 `pyproject.toml`처럼 바이너리 옆에 놓으면 되며, JSON-RPC나 서버 프로세스가 필요 없음
- **인증 선언(Auth Declaration)**: "GitHub 토큰이 repo 스코프로 필요하고 GITHUB_TOKEN 환경변수로 전달해달라"는 식의 정적 파일
- MCP의 문제는 이 얇은 발견/인증 계층에 호출, 데이터 전달, 오케스트레이션이라는 불필요한 두꺼운 인프라를 묶어놓은 것이며, 올바른 접근은 이 둘을 분리하는 것임

## 핵심 포인트

- MCP의 5가지 역할(발견, 호출, 데이터 흐름, 접근 제어, 오케스트레이션)은 POSIX가 이미 해결한 문제
- MCP 도구 메타데이터만으로 134,000 토큰(대화당 ~$0.40)을 소비하는 비용 문제
- 파이프 기반 데이터 흐름이 MCP 대비 수십~수백 배 저렴
- 필요한 것은 도구 매니페스트와 인증 선언이라는 2개의 정적 파일 표준뿐

## 인사이트

MCP 비판의 핵심은 프로토콜 자체가 아니라 얇은 표준(발견+인증)에 두꺼운 인프라(호출+데이터+오케스트레이션)를 묶어놓은 설계에 있음. CLI + 2개 정적 표준이라는 대안이 설득력 있지만, 비개발자 사용자 접근성 문제는 여전히 숙제임.