MCP is dead. Long live the CLI, 정말?

지나가다 발견한 글에 오잉? 하고 의문이 들어 간단하게 GPT를 통해 확인해 본 뻘글.

 

원문은,

 

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

MCP is dead. Long live the CLI

 

요약문은,

 

https://news.hada.io/topic?id=27129

MCP는 죽었다. CLI 만세 | GeekNews

 

비전공자 분들을 위해 좀 풀어서 설명하자면,

펼쳐보시라.

CLI 는 간단하게 말하면 윈도우의 CMD, PowerShell 과 같은 콘솔 입력 환경, 더 쉽게 말하면 옛날 DOS 창 같은 명령어 환경이다. 그래도 모르겠다면, 대충 이런 거...

 

 

또는 이런 거

 

당연하게 생각하는 GUI 환경은 원래 프로그램이란 개념에 있어 평범한 게 아니었다. 사람이 쓰기 편하게 하려고 이것저것 붙인거고, 그걸 위해 생각보다 많은 번잡한 작업들이 들어간다. 그런데 그건 사람이 필요한거고, AI에게 필요한 게 아니다. 오히려 언어 모델 (LLM) 에 기반한 AI 입장에선 글씨만 나오는 저게 더 편하다. 하지만.

 

왠지 Agentic AI 기술을 위해 사람들은 MCP라는 기술을 만들었다. 대략

이런 거...

 

저거만 봐선 저게 어떻게 구현되는지 알 길이 없지. 간단히 말하면 저렇게 AI에 도구들을 연결하게 위해 웹의 URL 같은 형식의 통신 규정을 만들었다고 보면 된다. 그리고 그 규정의 기반이 되는 것이 REST API 라는 것이 있다.

 

간단히 말하면 AI 시스템이 메일이나 클라우드 드라이브 등의 디지털 도구들을 사용하는데, 웹 URL로 날리는 게 편하냐, 콘솔 창 열어 명령어 치는 게 편하냐는 것...

 

...

 

간단히 말한 게 맞나? 쿨럭.

 

 

관심 있다면 관련 용어를 함 찾아보시고 귀찮다면 이 글은 스킵하시라. 어차피 일반인들은 알 필요도 없는 개발자들만의 뻘소리다.

 

 

여기서부터는 다 안다는 가정하에,

 

개인적인 생각으론, MCP? 그거 걍 REST API 잖아? 뭐 그리 대단한 거라고 복잡하니 뭐니 그래? 라는 생각이 들어서 저 글을 보고 오잉? 하고 지나치지 못한 것.

 

그래서 간단히 GPT에 물어봤다, 만, GPT는 링크를 못 읽던데.

 

나 : 인터넷에 MCP보다 CLI가 AI를 위한 더 좋은 도구임이 밝혀졌다고 주장하는 글이 있던데, 맞는 거 같아?

간단히 말하면, “CLI가 MCP보다 무조건 더 좋은 도구다”라는 주장은 과장된 면이 있습니다. 서로 역할과 장점이 다르기 때문입니다. (OneUptime)

핵심 정리

• MCP (Model Context Protocol): AI 에이전트가 다양한 도구, 데이터, 서비스와 표준화된 방식으로 연결하고 상호작용하도록 설계된 프로토콜입니다. AI 에이전트 생태계에서 표준 인터페이스 역할을 하는 것이 목적입니다. (위키백과)
• CLI (Command-Line Interface): 텍스트 명령으로 도구를 직접 제어하는 전통적인 인터페이스입니다. 단순하고 기존 도구를 바로 활용하기 좋으며, 토큰 효율 면에서 유리하다는 의견도 있습니다. (위키백과)

둘의 비교
✔ CLI 장점

• 기존 수많은 도구를 바로 활용 가능
• 간단한 작업이나 스크립트 자동화에 효율적
• 일부 주장처럼 토큰 사용량을 아낄 수도 있음(단 몇몇 실험 기준) (서버포럼)

✔ MCP 장점

• AI가 외부 시스템·데이터와 안전하고 구조적으로 상호작용할 수 있도록 설계됨
• 도구들 간의 상호 운용성을 높여 에이전트 작업을 더 체계적으로 구성
• 업계 표준으로 성장 중이며, 많은 AI 플랫폼에서 지원됨 (위키백과)

정리하면
CLI는 간단한 작업이나 토큰 절약이 중요한 상황에서 유리한 경우가 있고, MCP는 표준적이고 구조적인 통합이 필요할 때 더 적합합니다. 어느 쪽이 “AI에 더 좋다”고 결론 내리기는 어렵고, 목적과 사용 환경에 따라 선택해야 합니다. (OneUptime)

필요하시다면 MCP와 CLI의 실제 사용 사례(언제 어떤 걸 쓰는 게 좋은지) 더 구체적으로 설명드릴까요?

 - 아니, 당연히 장단점이 있겠지. 누가 그걸 몰라서 묻냐...

 

나 : MCP라고 해봐야 결국 이전부터 많이 쓰던 REST API랑 그걸 호출하는 LLM 생성 양식을 규정한거 아닌가?

짧게 말씀드리면, **“MCP = REST API + LLM이 호출할 JSON 포맷을 정한 것”**이라고 보기에는 조금 부족합니다. 겉모습은 비슷하지만, 지향점이 다릅니다.

---

1️⃣ REST API와의 공통점

맞는 부분도 있습니다.

• HTTP 기반 요청/응답 구조
• JSON 스키마로 입력/출력 정의
• 외부 시스템 호출

이 관점만 보면

“기존 REST를 LLM이 잘 쓰게 포장한 것 아닌가?”
라는 인상이 드는 것도 자연스럽습니다.

---

2️⃣ 하지만 핵심 차이

✅ 1. LLM을 1급 주체로 전제

REST는 사람/서비스 → 서버 구조입니다.
MCP는 처음부터 **“LLM이 호출자”**라는 전제를 둡니다.

즉:

• 자연어 → 구조화된 tool call
• tool result → 다시 모델 컨텍스트로 편입
• 세션 단위 상태 유지

이 흐름 전체를 프로토콜 차원에서 정의합니다.

---

✅ 2. Tool Registry + Capability 모델

REST는 “엔드포인트 집합”입니다.
MCP는:

• 어떤 tool이 있는지
• 각 tool의 입력 스키마
• 호출 가능 범위
• 권한 모델

까지 구조적으로 노출합니다.

즉 단순 API가 아니라 **“에이전트가 탐색 가능한 능력 그래프”**에 가깝습니다.

---

✅ 3. 보안·격리 모델

에이전트가 임의 API를 막 호출하면 위험합니다.
MCP는:

• 툴 실행 샌드박싱
• 명시적 허용 범위
• 컨텍스트 분리

같은 개념을 프로토콜 수준에서 전제합니다.

REST는 이런 걸 애플리케이션이 직접 구현해야 합니다.

---

✅ 4. 대화 루프에 최적화된 구조

MCP는 다음을 기본 루프로 설계합니다:

User → LLM → Tool Call → Tool Result → LLM → Response

REST는 이런 루프를 고려하지 않습니다.

---

🔎 그래서 질문에 대한 제 결론

“결국 REST 포장 아닌가?”

👉 기술적으로는 REST 위에 얹힌 추상화가 맞습니다.
👉 하지만 설계 목적은 “API 제공”이 아니라 **“LLM 에이전트 운영 표준화”**입니다.

즉:

• REST = 네트워크 인터페이스 표준
• MCP = 에이전트-도구 상호작용 표준

계층이 다릅니다.

---

💡 CLI vs MCP 논쟁과 연결해보면

CLI를 선호하는 쪽은 보통 이렇게 말합니다:

• LLM이 굳이 JSON tool call 할 필요 없다
• 그냥 bash 명령 생성 → 실행 → 결과 반환이 더 단순하다

이건 “LLM을 도구 생성기”로 보는 관점입니다.

반면 MCP는:

• LLM을 시스템 내부 에이전트로 보고
• 권한/능력/상태를 구조적으로 관리하려는 방향입니다.

---

🎯 사용자님의 관점에서 보면

Physical AI / 멀티로봇 / RFM 플랫폼을 고민하시는 입장이라면:

• 단기 PoC → CLI 기반이 빠름
• 장기 플랫폼화 → MCP 같은 capability 기반 추상화가 필요

로봇 제어 쪽에서도:

• ROS2 topic을 그냥 CLI로 때릴 수도 있지만
• capability graph 기반 orchestration 계층을 따로 두는 게 스케일에는 유리

와 비슷한 문제입니다.

---

원하시면
“로봇 제어 플랫폼 관점에서 MCP가 왜 의미가 있을 수 있는지”
조금 더 구조적으로 풀어드릴까요?

 - 뜬금없이 Physical AI 나 로봇 타령하는건 내가 평소에 물어보던 게 있어서 그렇다. 이럴 땐 성가시다... 주제가 바뀐 걸 좀 알아서 파악하라고.

 - MCP와 REST API 가 뭔가 졸라 다른 것처럼 말하지만 내용을 보면 대체 뭐가 다르다는 건지 모르겠다. 똑같은 문이 사람이 들어가면 문이고 로봇이 들어가면 곰이냐? 물론 로봇이 들어가야 하니 손잡이를 로봇 편하게 쓰라고 만든 정도는 있겠지...

 - 역시 해당 글을 직접 분석하는 게 아니다보니 자꾸 곁다리만 짚는다.

 

나 : MCP is dead. Long live the CLI 이 글에 대해서 분석해봐

해당 글 “MCP is dead. Long live the CLI”는 몇 가지 강한 주장을 담은 개인/커뮤니티 의견글입니다. 하나의 관점으로는 흥미롭지만, 업계 전체 결론이라고 보기에는 근거가 제한적입니다. 대표적인 핵심 논점들을 분석해 보면 다음과 같습니다:

---

🧠 1) 글의 핵심 주장

• MCP는 복잡하고 실용성이 낮으며, LLM은 CLI(Command-Line Interface) 툴만으로 충분히 도구를 사용할 수 있기 때문에 MCP는 “죽어가고 있다”는 주장입니다. (ejholmes.github.io)
• MCP 도입을 위해 추가된 서버, 인증, 스키마 등이 오히려 불필요한 오버헤드를 만든다는 비판이 중심입니다. (ejholmes.github.io)
• LLM은 이미 man page, 스택오버플로우, 깃허브 코드 등으로 CLI 사용법을 학습했기 때문에 별도의 프로토콜이 필요 없다는 논리입니다. (Reddit)

즉 글은 본질적으로 “MCP가 필요하지 않을 수도 있다”는 효율/단순성 관점의 의견입니다.

---

⚖️ 2) 이런 주장에 대한 현실적 맥락

📌 MCP는 실제로 존재하고 일부에서는 도입되고 있음

Anthropic이 발표한 Model Context Protocol은 LLM과 외부 도구/데이터 통신을 표준화하기 위한 오픈 프로토콜입니다. 이는 다양한 SDK, JSON-RPC 포맷, 외부 데이터 접근 등의 구조를 미리 정의하며, 단순 CLI와는 다른 표준 레이어 역할을 의도합니다. (위키백과)

MCP는 이미 OpenAI, Google DeepMind 등에서 표준 선택지로 채택 또는 활용 사례가 발표된 바 있고, 연구에서도 그 표준 특성과 위험/보안 측면에 대한 분석이 진행되고 있습니다. (arXiv)

---

🆚 3) 왜 이런 글이 나오는가

커뮤니티에서 MCP vs CLI 논쟁이 발생하는 이유는 크게 다음과 같습니다:

👍 CLI가 가진 장점

• 단순하고 직관적: 쉘, 스크립트 형태로 정리 가능하며 LLM이 직접 명령 실행 결과를 해석 가능. (Hacker News)
• 복잡한 서버/프로토콜 없이 바로 로컬 환경에서 테스트, 디버깅이 쉬움. (GeekNews)
• LLM이 이미 CLI 사용 습득 데이터가 많음(예: man page 기반). (Reddit)

→ 이런 장점 때문에 일부 개발자는 MCP보다 CLI 중심 접근을 선호하게 됩니다.

👎 MCP가 갖는 현실적인 어려움

• 도입 환경이 서버/인증/관리 요소가 필요해 초기 진입 장벽이 존재함. (ejholmes.github.io)
• 빠르게 표준화가 진행되지 않으면 “과잉 설계”라는 비판에 노출될 수 있음.

하지만 이건 “죽었다”는 수준의 결론이라기보다는 초기 기술 경쟁/과도기 논쟁에 가깝습니다.

---

📊 4) 실제로 MCP가 완전히 사라졌나?

현황은 그렇게 단정적으로 말할 수 없습니다:

• MCP는 여전히 표준으로 개발 및 채택되는 맥락이 존재합니다. (위키백과)
• CLI-first 접근도 확산되고 있고, 각 툴/에이전트 환경에서는 CLS(클라이언트 도구) 중심이 더 편리하다는 의견이 많은 것도 사실입니다. (GeekNews)
• 또한 MCP 자체를 CLI로 쓰거나 CLI-like 도구로 매핑하는 프로젝트도 존재합니다(예: mcpc CLI 클라이언트). (GitHub)

즉 지금 중요한 건 MCP가 더 이상 쓰이지 않아서 사라졌다가 아니라,
“목적과 상황에 따라 CLI가 더 편리한 선택이 될 수 있다”는 현실적인 개발자 논쟁입니다.

---

🧩 정리

관점현실

“MCP는 죽었다”	과장된 표현 — 일부 도구/커뮤니티에서 그런 주장
CLI가 MCP보다 효과적	간단한 워크플로우에서는 그렇기도 함
MCP가 완전히 사라짐	아님 — 표준으로 유지/사용되고 있음
결국 둘 중 하나만 살아남음	아님 — 용도에 따라 병존 가능

---

💡 결론

해당 글은 자극적인 제목의 개인 의견이며, 현실 전체를 대표하지 않습니다. MCP는 여전히 개발 생태계에서 표준 역할을 시도/유지 중이고, CLI 기반 접근도 확산되는 현재진행형 논쟁입니다.

원하시면 MCP와 CLI가 각각 어떤 경우에 유리한지 비교표로 정리해 드릴까요? (실전 사례 위주로)

 - 왠지 타겟 글을 고려했는데 첫번째와 비슷한 결론...

 - 실제는 모르겠지만 ChatGPT의 결론은 어그로성 글일 뿐. 나도 그냥 눈에 밟혀서 찾아봤을 뿐이지 저런 의견이 딱히 자주 보였던 건 아니다. 그냥 MCP 만든 게 정말 뻘짓이야? 라는 의문이 들었을 뿐...

 - 사실 CLI이든 MCP든 만들어지는 명령어는 그냥 문자열일 뿐이다. 그 문자열의 형식을 사전 정의해야 하는 것도 마찬가지다. 그게 좀 더 길고 짧은 건 뭐 어마어마하게 대단한 비용을 유발하는 문제도 아니다.

 - 다만 문득 든 생각은, 응? REST API 에는 보통 보안을 위한 권한 설정을 하는 걸 못 봤는데, CLI 이라면 그걸 쓰려면 기본적으로 SSH를 접속해야 하고 보안을 통과해야 하잖아? 그럼 보안을 구현하는 성가심이 핵심인가?

 

나 : CLI를 그대로 쓸 수 있는 원격 환경은 이미 ssh 인증 프로토콜이 있으니 별도 인증 구현이 필요 없다는건가?

네, 그 글의 논지는 거의 그 방향이 맞습니다.

요지는 대략 이렇습니다:

이미 SSH라는 성숙한 원격 실행 + 인증 + 암호화 프로토콜이 있는데
왜 굳이 MCP 서버 + 별도 인증 + 별도 권한 모델을 또 만드느냐

---

🔐 SSH가 이미 제공하는 것

CLI 기반 원격 환경에서 SSH가 제공하는 기능은 매우 강력합니다:

• 공개키 기반 인증
• 세션 암호화
• 사용자 단위 권한 분리
• sudo / 그룹 기반 접근 제어
• 감사 로그
• 포트포워딩 / 터널링
• 에이전트 포워딩

즉, “원격에서 안전하게 명령 실행”이라는 목적만 보면
이미 완성형 인프라입니다.

그래서 CLI 옹호자들은:

• LLM → ssh 접속 → 명령 실행
• 굳이 MCP 서버를 둘 필요 없음
• 이미 운영 환경에 SSH는 다 깔려 있음

이라고 주장합니다.

---

🤔 그런데 여기서 빠지는 전제

SSH는 “사용자”를 전제로 합니다.
MCP는 “LLM 에이전트”를 전제로 합니다.

이 차이가 꽤 큽니다.

1️⃣ 권한 모델 차이

SSH는 OS 계정 권한 모델입니다.

MCP는:

• 이 tool만 호출 가능
• 이 스키마만 허용
• 이 파라미터 범위만 허용

같이 능력(capability) 단위 제한을 설계합니다.

LLM에게 bash 전체 권한을 주는 것과
“파일 읽기만 허용”을 주는 것은 보안 레벨이 다릅니다.

---

2️⃣ 인터페이스 구조

SSH는 “문자열 명령 실행”입니다.

LLM이 이런 걸 생성합니다:

rm -rf /tmp/*

문제는:

• 파싱 구조 없음
• 파라미터 검증 없음
• 의도 분석 어려움

반면 MCP는:

{
  "tool": "delete_temp_files",
  "args": {
    "path": "/tmp",
    "recursive": true
  }
}

이건 구조적으로 제어 가능합니다.

---

3️⃣ 로봇/인프라 관점에서 보면

예를 들어 사용자님이 생각 중인:

• 멀티 로봇 제어
• 데이터센터 자동화
• 전원 모듈 제어

이런 환경에서 LLM에게 SSH로 root shell을 열어주는 건
운영팀이 절대 허용하지 않을 가능성이 높습니다.

SSH는 인간 운영자 모델입니다.
MCP는 제한된 자동화 에이전트 모델입니다.

---

🎯 그래서 질문에 대한 정확한 답

"별도 인증이 필요 없다는 주장인가?"

✔ 네, 그 글은 이미 SSH가 인증·암호화를 해결한다는 전제를 깔고 있습니다.
✔ 하지만 그건 “원격 명령 실행” 관점에서만 맞는 말입니다.
❗ “에이전트 능력 통제” 관점에서는 충분하지 않습니다.

---

💡 핵심은 이겁니다

CLI + SSH는:

강력하지만 너무 넓은 권한 모델

MCP는:

복잡하지만 세밀한 capability 모델

---

🔎 실제 산업에서 어느 쪽이 살아남을까?

• 개인 개발자 / 스타트업 / PoC → CLI 우세
• 대기업 / 보안 환경 / SaaS 플랫폼 → MCP류 구조 필요

사용자님처럼 플랫폼 레벨 Physical AI 시스템을 고민한다면
결국 capability abstraction 레이어가 필요해질 가능성이 큽니다.

---

원하시면
CLI + SSH 기반 에이전트 구조가 어디서 깨지는지
실제 아키텍처 레벨에서 한번 해부해볼까요?

 - 대충 내 가설이 맞았...

 - 근데 REST API도 웹 서비스에서 흔히 쓰이는 표준이고, 사람들이 바보가 아닌 이상 여기에서 권한 인증을 위한 무언가를 만들어놨을 텐데? 걍 가져다 쓰면 끝 아니야?

 

나 : 반대로 사람을 주체로 봐도 REST API에도 권한인증이 필요한 경우 많잖아? REST API에는 간단히 구현되는 표준 인증이 없나?

맞습니다.
REST API도 대부분 권한·인증이 필수이고, 이미 잘 정립된 표준들이 있습니다. MCP가 “인증을 새로 발명했다”고 보기는 어렵습니다.

---

✅ REST에서 널리 쓰이는 표준 인증 방식

1️⃣ OAuth 2.0

• 현재 가장 널리 쓰이는 표준
• 액세스 토큰 기반 권한 위임
• Google, GitHub, Slack 등 대부분 채택

2️⃣ OpenID Connect (OIDC)

• OAuth 2.0 위에 사용자 인증 계층 추가
• SSO에 자주 사용

3️⃣ JWT (JSON Web Token)

• 토큰 자체에 서명된 권한 정보 포함
• 서버 간 통신에 자주 사용

4️⃣ API Key / HMAC 서명

• 서버-서버 통신
• AWS Signature 같은 방식

5️⃣ mTLS

• 클라이언트 인증서 기반 상호 인증
• 금융·엔터프라이즈 환경

즉,

REST에 “간단한 표준 인증이 없다”는 건 사실이 아닙니다.

이미 충분히 표준화되어 있고 산업 전반에서 쓰이고 있습니다.

---

🔎 그렇다면 MCP는 뭐가 다른가?

MCP가 차별화하려는 건 **전송 인증(authentication)**이 아니라
도구 호출 단위의 capability 통제 모델입니다.

REST에서의 권한은 보통:

• 이 API에 접근 가능
• 이 리소스 읽기/쓰기 가능

같은 리소스 중심 모델입니다.

반면 MCP는:

• 이 tool만 호출 가능
• 이 파라미터 범위만 허용
• 이 세션에서만 허용

처럼 행동 단위 제어를 강조합니다.

하지만 솔직히 말하면:

👉 이 capability 모델도 REST 위에서 충분히 구현 가능합니다.
👉 MCP가 “기술적으로 불가능한 걸 새로 만든 것”은 아닙니다.

---

🎯 핵심 정리

항목RESTMCP

인증 표준	이미 충분히 존재 (OAuth, JWT 등)	자체 프로토콜 안에서 정의
보안 모델	리소스 중심	Tool/행동 중심
구현 난이도	이미 생태계 성숙	아직 초기
기술적 필수성	매우 높음	상황 의존

---

🔥 그래서 현실 결론

“MCP가 없으면 인증을 못 한다” → ❌ 아님
“REST는 인증이 빈약하다” → ❌ 사실과 다름
“MCP는 REST 위의 에이전트 지향 추상화다” → ⭕ 더 정확

---

사용자님 관점(플랫폼·로봇·RFM 스택)에서 보면
진짜 중요한 질문은 이겁니다:

우리는 API를 노출하려는가?
아니면 LLM 에이전트를 운영하려는가?

이 두 목적은 미묘하게 다릅니다.

원하시면
REST 기반 capability 설계와 MCP 기반 설계를
아키텍처 레벨에서 비교해 드리겠습니다.

 - 어이! 있으면 대체 뭐가 다른건데!

 

나 : 그럼 MCP가 나오기 전에 REST API랑만 비교해도, CLI가 있느니 REST API는 필요없다는 그런 주장따윈 없지 않았어?

짧게 말씀드리면, 그런 주장은 예전에도 있었습니다.
다만 주류가 아니었을 뿐입니다.

---

1️⃣ CLI vs REST 논쟁은 오래된 이야기입니다

예전에도 이런 주장들은 있었습니다:

• “curl로 다 되는데 왜 REST 서버 따로 두냐”
• “내부 시스템이면 SSH + 스크립트면 충분하다”
• “API 만들 시간에 CLI 툴 잘 만들자”

특히 DevOps 초창기, 내부 자동화 영역에서는
CLI + SSH + cron 조합이 굉장히 강력했고,
굳이 REST 레이어를 만들 필요 없다는 주장도 많았습니다.

---

2️⃣ 그런데 왜 REST가 살아남았나?

📌 이유는 명확합니다

1. 구조화
   • CLI는 문자열 인터페이스
   • REST는 명세화된 계약(interface contract)
2. 확장성
   • 여러 클라이언트 (웹, 모바일, 외부 파트너)
   • 언어/환경 독립성
3. 보안·감사
   • 중앙화된 인증/인가
   • 요청 단위 로깅
4. 서비스화
   • CLI는 “호스트에 종속”
   • REST는 “네트워크 서비스”

결국 **서비스화(서비스 지향 아키텍처)**가 등장하면서
CLI만으로는 한계가 명확해졌습니다.

---

3️⃣ 지금 MCP vs CLI 논쟁은 무엇과 닮았나?

지금 벌어지는 논쟁은 사실:

2008~2015년의 CLI vs REST 논쟁을
2026년 AI 에이전트 문맥에서 다시 보는 것

과 매우 유사합니다.

CLI 옹호자들은:

• LLM이 이미 CLI 잘 쓴다
• 굳이 MCP라는 또 다른 레이어 필요 없다

라고 말합니다.

하지만 이건 주로 단일 머신 / 로컬 자동화 / PoC 관점입니다.

---

4️⃣ 왜 이번엔 논쟁이 더 커졌을까?

LLM이 등장하면서:

• 자연어 → 명령 생성이 쉬워졌고
• CLI가 다시 “범용 인터페이스”처럼 보이기 시작했기 때문입니다.

과거엔 사람이 명령을 쳤지만
지금은 LLM이 대신 칩니다.

그래서 CLI가 다시 부활한 느낌을 주는 겁니다.

---

🎯 핵심 결론

“CLI가 있으니 REST는 필요 없다”는 주장은 과거에도 있었고,
결국 REST는 사라지지 않았습니다.

왜냐하면:

CLI는 실행 인터페이스이고
REST는 서비스 계약 인터페이스이기 때문입니다.

MCP도 같은 운명을 겪을 가능성이 높습니다.

• 단기: CLI가 더 편해 보임
• 장기: 구조화된 계약 계층이 다시 필요해짐

---

사용자님처럼 플랫폼/로봇/멀티 시스템을 고민하는 입장에서는
아마 이 질문이 더 중요할 겁니다:

AI 에이전트는 “운영자 대체자”인가?
아니면 “서비스 내부 컴포넌트”인가?

이 관점에 따라 CLI vs MCP의 답이 완전히 달라집니다.

원하시면 이걸 로봇 플랫폼 아키텍처에 비유해서 설명해 드릴까요?

...

 

결론

내가 의문을 가졌던 부분은 이거다.

 

1. MCP는 걍 REST API 아니야? → TRUE

2. 그럼, REST API 잘만 써왔는데 왜 이제와서?

 

이었는데, 결론은... 응. 그거 REST API 때부터 하던 소리야.

 

헐...

 

그렇다면 답은 간단하다. 그때도 REST API 가 더 편리한 사용 씬이 있었고, CLI가 더 편리한 경우들이 있었다. 그리고 지금도 마찬가지다.