기업은 MCP가 아니라 CLI를 제공해야 한다

핵심 주장: 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의 문제는 이 얇은 발견/인증 계층에 호출, 데이터 전달, 오케스트레이션이라는 불필요한 두꺼운 인프라를 묶어놓은 것이며, 올바른 접근은 이 둘을 분리하는 것임