API, MCP, CLI, Claude Skill: 무엇이 다르고, 언제 써야 하는가?

REST API, MCP server, CLI, Claude Skill. 요즘 AI 도구를 좀 써보려고 하면 꼭 한 번씩 마주치는 단어들입니다. 분명 어디선가 다 들어봤는데, 막상 "그래서 우리 팀이 뭘 써야 하죠?"라는 질문 앞에 서면 명확하게 대답하기 어려운 경우가 많습니다.

조직 내에 AX를 도입하려는 분들의 머릿속엔 대개 비슷한 질문이 맴돕니다.

• "MCP만 연결하면 끝나는 거 아닌가요?"

• "어차피 API가 있으니까 그냥 API 쓰면 되는 것 아닌가요?"

• "Agent-first 시대라던데, 그럼 전부 MCP로 가야 하나요?"

• "Skill은… MCP를 다르게 부르는 건가요?"

AI Agent가 사용할 수 있는 비슷하지만 서로 다른 네 가지의 도구들이 각각 무엇이고 어떻게 다른지 정리해 둔 글은 의외로 찾기 어려운 것 같습니다. 그래서 이번 글에서는 각 도구들의 정의 → 차이점 → 언제 무엇을 써야 하는지를 한 번에 정리합니다.

네 가지 도구

용어부터 맞추지 않으면 비교가 성립하지 않습니다. 이 글에서 다루는 네 가지 도구들은 모두 AI 에이전트가 외부 시스템과 일하게 만드는 인터페이스입니다. 다만 "등장한 시점, 작동 방식, 그리고 누가 부르는가" 이 세 가지가 전부 다릅니다.

API (Application Programming Interface)

가장 익숙한 인터페이스인 API부터 시작합니다. API는 두 시스템이 약속한 방식으로 대화하는 통로입니다. 보통 HTTP 위에서 JSON을 주고받습니다. 1990년대 이후 웹의 뼈대로 자리 잡아 지금도 모든 SaaS의 바닥 레이어를 이루고 있습니다.

# Stripe로 결제를 만드는 API 호출
POST https://api.stripe.com/v1/charges
Authorization: Bearer sk_live_...
Content-Type: application/x-www-form-urlencoded

amount=2000&currency=usd&source=tok_visa

API는 호출자가 누구인지 따지지 않습니다. 사람이 터미널에서 curl로 호출해도, 백엔드 코드가 불러도, AI 에이전트가 호출해도 똑같이 응답합니다. 그래서 API는 나머지 세 도구의 골격, 즉 skeleton입니다—MCP도, CLI도, Skill도 결국 한 꺼풀 벗겨보면 안쪽에서 API를 부르고 있습니다.

MCP (Model Context Protocol)

2024년 11월, Anthropic이 발표한 오픈소스 표준입니다. AI 에이전트가 외부 도구와 데이터에 접근할 때 항상 같은 형식으로 대화할 수 있도록 설계된 프로토콜이며, JSON-RPC 위에서 동작합니다.

예를 들어보겠습니다. Claude Desktop에서 "내 GitHub PR 목록 좀 보여줘"라고 물었습니다. Claude가 이 질문에 답하려면 GitHub에 접근해야 합니다. GitHub의 API 문법을 Claude가 직접 외울 수는 없으니, GitHub이 미리 "내 도구를 이렇게 부르세요"라는 설명서(스키마)를 MCP 서버에 담아둡니다. Claude는 이 설명서를 읽고 적합한 도구를 호출합니다.

// MCP 서버가 Claude에게 자기소개하는 모습 (단순화)
{
  "tools": [
    {
      "name": "list_pull_requests",
      "description": "Lists pull requests in a repository",
      "inputSchema": {
        "type": "object",
        "properties": {
          "owner": { "type": "string" },
          "repo": { "type": "string" },
          "state": { "enum": ["open", "closed", "all"] }
        }
      }
    }
  ]
}

이 구조가 힘을 갖는 건 표준화 덕분입니다. Claude Desktop이든 Cursor든 Claude Code든—MCP만 알아듣는 호스트라면 어떤 회사의 MCP 서버든 같은 방식으로 붙습니다. 실제로 2025년 한 해, GitHub·Notion·Figma·Slack·Stripe·Linear를 비롯한 주요 SaaS들이 앞다투어 공식 MCP 서버를 내놨습니다.

CLI (Command Line Interface)

터미널에서 직접 명령어를 입력하는 도구입니다. git push, gh pr list, aws s3 ls, npm install 같은 것들입니다. 1970년대 Unix 시절부터 있었고, 개발자라면 매일 사용합니다.

# GitHub CLI로 PR 목록 보기
gh pr list --state open --limit 5

# AWS CLI로 S3 버킷의 파일 목록 보기
aws s3 ls s3://my-bucket/data/

# Stripe CLI로 최근 결제 보기
stripe charges list --limit 3

그런데 이 옛날 도구가 갑자기 AI 시대의 주인공으로 돌아왔습니다. 이유는 의외로 단순합니다. AI 비서도 이 도구를 쓸 수 있기 때문입니다. Claude Code, Cursor, Codex 등은 AI에게 컴퓨터 명령어를 직접 입력할 수 있는 권한을 줍니다. 사람이 자판으로 명령어를 치는 대신, AI가 대신 쳐주는 것입니다.

그러면 이런 상황이 생깁니다. 예를 들어 "지금 검토 대기 중인 코드 변경사항 목록 보여줘" 같은 일을 시킨다고 가정해보겠습니다. 원래는 이런 작업을 하려면 중간에 여러 단계를 거치는 별도의 연결 장치(MCP 서버)를 만들어둬야 했습니다. 그런데 AI가 그냥 명령어 한 줄(gh pr list)을 직접 쳐버리면 끝납니다. 굳이 복잡한 중간 다리를 놓을 필요가 없어진 것입니다.

Skill (Claude Skills)

가장 늦게 등장한 개념입니다. Skill은 마크다운 파일에 적힌 절차적 지식입니다. "이 task를 할 때는 이 순서로, 이런 방식으로 하세요"라는 가이드를 마크다운으로 정리한 것이며, 데이터를 가져오거나 행동을 일으키지는 않습니다. 순서와 박자만 명명합니다.

---
name: weekly-meeting-report
description: 주간 미팅에서 결정 사항을 추출하여 리포트로 만들 때 사용
---

## 절차

1. tiro CLI로 이번 주 회의록을 가져온다
   
   tiro notes search "OKR" --since 7d --json > meetings.jsonl

2. 각 회의에서 "결정 사항" 섹션만 추출한다

3. 다음 템플릿에 채워 넣어 마크다운 리포트를 만든다

4. Slack #weekly-report 채널에 게시한다

그래서 Skill은 MCP의 대체재가 아니라 오히려 보완재에 가깝습니다. MCP가 도구 접근을 제공한다면, Skill은 그 도구를 어떻게 효과적으로 쓸지 알려주는 절차입니다.

같은 질문, 32배의 비용 차이

4가지 도구의 정의를 잡았으니, 이제 핵심 질문으로 넘어갑니다. 같은 일을 시키면 결과가 비슷할까요? 결론부터 말하면, 전혀 아닙니다. 데이터가 꽤 놀라운 이야기를 들려줍니다.

Scalekit이 2026년 3월에 발표한 벤치마크는 아주 단순한 질문 하나로 시작합니다. "이 GitHub 레포는 무슨 언어로 짜였나요?" 같은 질문, 같은 모델(Claude Sonnet 4), 75번의 반복.

결과는 이렇습니다.

• gh CLI 에이전트: 1,365 토큰

• GitHub MCP 에이전트: 44,026 토큰

• 32배 차이입니다.

왜 이런 차이가 날까?

이유는 우연이 아니라 구조적입니다. MCP 서버는 세션을 시작할 때 등록된 모든 도구의 스키마를 컨텍스트에 한꺼번에 부어 넣습니다. GitHub MCP의 도구는 43개. 사용자가 "내 PR 보여줘" 한 번 물었을 뿐인데, Claude의 컨텍스트 윈도우에는 webhook 관리, gist 생성, repository 설정처럼 PR과 무관한 스키마까지 매번 같이 따라 들어옵니다.

CLI는 방식이 다릅니다. gh --help는 필요할 때만 부르고, 그 결과만 잠깐 들어왔다가 사라집니다. 게다가 gh, git, curl, aws 같은 Tier 1 CLI는 모델의 학습 데이터에 이미 수백만 번 등장한 "익숙한 얼굴"입니다. 모델이 이미 외우고 있으니, 스키마를 다시 알려줄 필요 자체가 없습니다.

Agent-first는 이미 변했다

이 데이터 이후로 흐름이 바뀌기 시작했습니다. Anthropic은 같은 워크플로의 토큰을 150,000에서 2,000으로 줄이는 code execution 패턴을 공식 발표했습니다. 98.7% 절감입니다. Cloudflare도 Code Mode라는 같은 패턴을 독립적으로 발견했습니다. MCP가 등장한지 얼마 되지 않았지만, "Agent-first면 MCP-first"라는 통념은 이미 조용히 깨지고 있습니다.

그렇다고 CLI가 정답인 것도 아닙니다

이 데이터만 보면 "그럼 다 CLI로 가면 되겠네"라고 결론 내리기 쉽습니다. 하지만 그것도 다른 함정에 빠지는 길입니다.

CLI에도 분명한 한계가 있습니다.

첫째, 인증 분리가 어렵습니다.

회사 슬랙에 50명이 일한다고 해볼게요. 각자 볼 수 있는 채널과 권한이 다 다릅니다. 그런데 AI가 한 사람의 컴퓨터에서 명령어를 대신 쳐주는 방식이라면, 결국 그 한 사람의 권한으로 모든 일을 처리하게 되는 거죠. 누가 무엇을 할 수 있는지 깔끔하게 구분하기가 어렵습니다.

둘째, 결과물이 정돈되지 않은 채로 나옵니다.

명령어를 실행하면 결과가 그냥 글자 덩어리로 쭉 쏟아져 나옵니다. AI가 그걸 매번 다시 읽고 "아, 이 숫자가 가격이고, 저게 날짜구나" 하고 해석해야 해요. 정해진 양식으로 깔끔하게 받는 게 아니다 보니 실수할 여지가 생깁니다.

셋째, 애초에 CLI가 없는 서비스가 많습니다.

Workday, Greenhouse, Lever 같은 엔터프라이즈 HR SaaS는 CLI를 만든 적이 없고, 앞으로 만들 가능성도 낮습니다.

답은 양자택일이 아니다

결국 답은 MCP, CLI 중 양자택일이 아닙니다. 두 도구는 서로 다른 일에 맞게 설계됐다. 이 전제를 잡아야 합니다. 그 "다른 일"을 한 줄로 말할 수 있을 때, 비로소 "이 기능을 어디에 노출할까"의 답이 보입니다.

빠진 축: "결과물이 어디로 가는가"

지금까지 이런 도구들을 비교할 때는 늘 두 가지 기준으로 봤습니다. 누가 사용하느냐(사람이 직접? 아니면 프로그램이?), 그리고 어떻게 연결되느냐(어떤 통신 방식을 쓰는지). 그런데 이 두 기준만으로는 네 가지 도구가 왜 서로 다른 존재인지 설명이 안 됩니다.

빠진 한 축이 있습니다. 결과물이 어디로 가는가.

종착지가 다르면 적합한 task가 다릅니다. 종착지가 같다면 사실상 같은 도구입니다.

한 줄로 압축하면 이렇습니다.

MCP는 컨텍스트로, CLI는 disk(컴퓨터의 작업대)로, Skill은 AI의 다음 행동으로, API는 정답이 필요한 곳으로 결과물을 보냅니다.

보완재이지 대체재가 아니다

4개 도구는 대체재가 아닙니다. 종착지가 다른 보완재입니다.

손과 발이 모두 필요한 이유

사람은 왜 손과 발을 따로 갖고 있을까요? 둘 다 이동하고 조작하는 도구인데 말이죠.

답은 정밀도와 거리입니다. 손은 가까이 있는 작은 걸 정밀하게 다룹니다—컵을 들고, 글씨를 쓰고, 키보드를 칩니다. 대신 멀리 못 갑니다. 발은 큰 거리를 이동하고 무거운 짐을 나릅니다. 대신 바늘에 실은 못 꿰죠.

에이전트의 도구도 똑같습니다.

MCP는 손입니다. AI가 보고 있는 컨텍스트 윈도우 안의 작은 데이터를 schema(정해진 양식)로 정확하게, 여러 번 주고 받으며 정밀하게 다룹니다. 대신 50KB짜리 transcript를 들이미는 순간 AI의 손이 꽉 차며 컨텍스트가 무너집니다.

CLI는 발입니다. 컴퓨터 내에서 큰 파일을 옮기고, 한 작업의 결과를 다음 작업으로 흘려보내고, 자동화된 시스템에도 들어갈 수 있습니다. 대신 결과물이 글자덩어리로 나오다 보니 손만큼 섬세하지는 못합니다.

Skill은 근육 기억입니다. "노트 검색 → transcript 저장 → 요약 → Slack 게시" 같은 순서와 박자를 외웁니다. 데이터 자체는 만지지 않습니다.

API는 골격입니다. 손도 발도 근육도 전부 이 위에 붙습니다. 골격이 흔들리면 나머지가 전부 흔들립니다.

왜 손과 발이 필요한가

이게 단순한 비유로 끝나지 않는 이유가 있습니다. 에이전트는 "컨텍스트 윈도우라는 단기 기억"과 "filesystem이라는 외부 기억"을 동시에 가진 존재라서 그렇습니다. 단기 기억은 용량이 정해져 있어서 너무 많은 것을 한꺼번에 옮기려 하면 터져버립니다. 그래서 큰 짐은 외부 기억(filesystem, 컴퓨터 내부)에 보내두고, 필요할 때만 꺼내보아야 합니다. 그게 손과 발의 분업입니다.

언제 어떤 도구를 써야 하나요

"이 endpoint를 어디에 노출할까?"를 1분 안에 결정할 수 있는 4개 질문입니다.

Q1. 결과물이 큰가요?

KB 단위 이상이거나 파일을 다뤄야 한다면, CLI입니다. 회의록 30건을 한꺼번에 내려받는다, transcript를 마크다운으로 저장한다, 큰 NDJSON을 pipe한다. 모두 CLI의 영역입니다. 이 데이터를 컨텍스트 윈도우에 넣으면 reasoning이 둔해지고 토큰 비용이 폭발합니다.

Q2. 한 번 호출로 끝나는 단순한 task인가요?

에이전트의 reasoning이 굳이 필요하지 않다면, API를 코드에서 직접 부릅니다. "이 webhook을 등록해줘", "이 user를 deactivate해줘" 같은 작업입니다.

Q3. 작은 metadata를 multi-turn으로 reasoning해야 하나요?

데이터는 가볍고 단계가 여러 개라면, MCP입니다. "공유 링크 중 만료 안 된 것만 골라서 기한을 30일로 연장해줘" 같은 작업입니다.

Q4. 이 모든 것의 순서가 반복되나요?

매주, 매 PR마다 같은 단계를 거친다면, Skill로 절차화합니다. 한 번 SKILL.md로 적어두면 다음부터 한 줄로 호출됩니다.

하나의 endpoint가 여러 도구에 노출되는 경우

하나의 endpoint가 두 도구에 노출되어야 하는 경우도 있습니다. "노트 한 건의 metadata"는 MCP로 보고, "같은 노트의 full transcript"는 CLI로 disk에 저장하는 것이 자연스럽습니다. 핵심은 "4개 도구에 다 노출한다"가 아니라, 각 endpoint를 종착지에 맞는 한두 개의 도구에만 노출한다는 것입니다.

종착지를 먼저 물어보세요

2026년의 SaaS는 4가지 도구를 동시에 운영할 수 있습니다. 다만 이 사실이 부담으로 느껴지는 이유는, 4개를 같은 것의 변종으로 보고 있기 때문일지 모릅니다. 같은 것의 변종이 아닙니다. 종착지가 다른 4개의 보완재입니다.

좋은 AX 설계의 출발점은 "어떤 도구가 더 좋은가?"가 아닙니다.

이 task의 결과물이 어디로 가야 하는가?

이 질문 하나만 정확히 던질 수 있어도, 4가지 도구를 운영하는 일이 훨씬 가벼워집니다.

"이 endpoint를 어디에 노출할까?"라고 묻기 전에, 결과물이 어디로 가야 하는지를 먼저 물어보세요.

자주 묻는 질문

Q. MCP가 뭔가요? 한 줄로 설명해주세요.

MCP는 Model Context Protocol의 약자로, AI 에이전트가 외부 도구와 데이터에 접근할 때 항상 같은 형식으로 대화할 수 있게 만든 표준입니다. 2024년 11월 Anthropic이 발표했고, JSON-RPC 위에서 동작합니다. GitHub, Notion, Figma, Slack 등 주요 SaaS가 공식 MCP 서버를 제공하고 있습니다.

Q. MCP와 API는 무엇이 다른가요?

종착지가 다릅니다. API는 호출자가 원하는 곳으로 결과를 보냅니다. MCP는 AI 에이전트의 컨텍스트 윈도우로 결과를 보냅니다. 작은 metadata를 multi-turn으로 추론할 때는 MCP가 적합하고, 큰 데이터를 처리하거나 다른 서비스에서 직접 호출할 때는 API가 적합합니다.

Q. CLI가 MCP보다 토큰을 적게 쓰는 이유가 뭔가요?

두 가지입니다. 첫째, MCP는 세션 시작 시 모든 도구의 스키마를 컨텍스트에 주입하지만, CLI는 필요할 때만 --help를 호출합니다. 둘째, gh, git, aws 같은 주요 CLI는 모델의 학습 데이터에 이미 수백만 번 등장하기 때문에 스키마를 새로 알려줄 필요가 없습니다. Scalekit의 벤치마크에서 같은 task에 CLI가 MCP보다 4배에서 32배 적은 토큰을 사용했습니다.

Q. Skill은 MCP의 대체재인가요?

아닙니다. Skill은 데이터에 직접 접근하지 않습니다. "노트 검색 → 요약 → Slack 전송" 같은 절차를 SKILL.md 파일에 명명한 것입니다. MCP가 도구 접근을 제공한다면, Skill은 그 도구를 어떻게 효과적으로 쓸지 알려주는 가이드입니다. 둘을 함께 쓸 때 가장 강력합니다.

Q. 우리 서비스도 MCP server를 만들어야 할까요?

데이터 특성에 따라 다릅니다. 작은 metadata 작업이 중심이고 multi-turn reasoning이 가치 있다면 MCP가 적합합니다. 결과물이 KB 단위 이상으로 크거나 파일을 다뤄야 한다면 CLI를 먼저 검토하세요. 가장 현실적인 답은 "필요한 도구를 모두 지원하되, 모든 endpoint를 4번 노출하지는 않는다"입니다. 각 endpoint를 종착지에 맞는 도구에만 노출하면 됩니다.

참고 출처

• Scalekit, "MCP vs CLI: Benchmarking AI Agent Cost & Reliability"

• Anthropic Engineering, "Code execution with MCP"

• Anthropic, "What are Skills?"

• Cloudflare Agents, "Code Mode for MCP"

• StackOne, "MCP vs CLI for AI Agents: When Each One Wins"

• Tiro API Documentation

더 읽어볼 글

• 왜 우리의 AX 전환은 10%에서 멈추는가

• AX의 Missing Piece: Conversational Intelligence

• Ontology: 데이터가 아니라 결정을 담는 구조

시작하기