MCP는 죽었나? 개발자 워크플로에선 CLI와 스킬이 더 가볍다는 주장

• MCP(Model Context Protocol)를 실제 개발 워크플로에 붙여보니, Quandri 팀의 결론은 꽤 차가움 — '연결은 되는데 너무 비싸다'는 것
  • MCP는 대규모 언어 모델(LLM)이 GitHub, Linear, Notion, Slack 같은 외부 도구를 호출하게 해주는 프로토콜임
  • 출시 이후 'AI 생태계의 유에스비-C' 같은 표현까지 붙었지만, 매일 쓰는 개발자 입장에선 컨텍스트 비용과 안정성이 더 크게 보였다는 얘기
  • 글 첫머리에서도 업데이트를 덧붙임: Claude Code가 Tool Search와 지연 로딩(Deferred Loading)을 도입하면서 컨텍스트 부풀림 문제는 최신 버전에선 많이 줄었다고 함

• 첫 번째 불만은 컨텍스트 창을 너무 많이 잡아먹는다는 점임

  • 글에서는 컨텍스트 창을 '모델의 책상'에 비유함. MCP 서버를 붙이면 실제 작업 자료를 올리기도 전에 메뉴판이 책상 위를 차지하는 꼴이라는 것
  • Quandri 환경에서 연결된 MCP 서버들의 실제 도구 정의를 추출해 측정했더니, 서버 4개 합산으로 컨텍스트의 10.5%가 도구 설명에 쓰였음
  • 특히 Linear는 42개 도구 정의가 항상 로드됐고, 실제로는 get_issue나 save_issue 정도만 써도 전체 도구 설명을 계속 들고 다니는 구조였음

• 두 번째는 성능과 안정성 문제임

  • 원 글 작성자가 Jira MCP와 Jira REST API 직접 호출을 비교했을 때 MCP는 호출당 3배 느렸고, 초기화까지 포함한 첫 호출은 9.4배 느렸다고 함
  • Quandri는 이게 Jira만의 문제가 아니라 구조적 오버헤드라고 봄. LLM과 실제 API 사이에 MCP 서버 프로세스 레이어가 하나 더 끼기 때문임
  • Linear, Notion, Slack MCP 서버도 같은 구조라 초기화 실패, 중간 세션 크래시, 느린 응답 같은 운영 이슈가 생길 수 있다는 주장

• 세 번째는 '이미 CLI나 API가 있는데 굳이 MCP가 필요한가?'라는 질문임

  • 같은 Linear 이슈 하나를 조회하는 작업에서 CLI 방식은 curl 명령과 응답을 합쳐 약 200토큰이면 됐음
  • MCP 방식은 Linear 도구 정의 1만2807토큰에 호출과 응답 150토큰을 더해 약 1만2957토큰이 들었음
  • 단순 비교로 MCP가 약 65배 많은 토큰을 쓴 셈이라, 이 정도면 편의성 비용이 아니라 구조적 낭비에 가깝다는 뉘앙스임

sequenceDiagram
    participant 개발자
    participant 대규모언어모델
    participant MCP서버
    participant 외부서비스
    개발자->>대규모언어모델: Linear 이슈 조회 요청
    대규모언어모델->>MCP서버: 로드된 도구 정의 기반 호출
    MCP서버->>외부서비스: 실제 API 요청 전달
    외부서비스-->>MCP서버: 이슈 데이터 반환
    MCP서버-->>대규모언어모델: 응답 전달
    대규모언어모델-->>개발자: 결과 정리

• 대안으로 제시하는 건 CLI 우선 전략임

  • 이미 개발자들이 쓰는 gh, psql, aws, curl 같은 명령을 LLM에게 알려주면 별도 도구 정의를 상시 로드할 필요가 없음
  • 사람과 AI가 같은 인터페이스를 쓰니 디버깅도 터미널에서 바로 가능함
  • 파이프라인으로 조합하기도 쉽고, LLM도 man page와 StackOverflow 패턴을 학습해 CLI 사용법을 꽤 잘 다룬다는 전제임

• 두 번째 대안은 Skills 패턴임 — 필요한 지침만 그때그때 로드하는 방식

  • MCP가 '식탁 위에 메뉴판 10개를 한 번에 펼치는 방식'이라면, Skills는 '필요한 책만 사서에게 요청하는 방식'에 가깝다고 설명함
  • 예를 들어 Linear 스킬 안에 GraphQL 엔드포인트, 인증 방식, curl 예시, jq 파싱 지침을 넣어두면 됨
  • 그러면 LLM은 Linear 작업이 필요할 때만 이 지침을 읽고, 평소에는 42개 도구 정의를 계속 끌고 다니지 않아도 됨

• 그렇다고 MCP가 완전히 쓸모없다는 결론은 아님

  • CLI가 없는 웹 전용 서비스라면 MCP가 사실상 유일한 연결 방식일 수 있음
  • 터미널을 쓰지 않는 비개발자에게는 MCP가 훨씬 접근성 좋은 인터페이스가 될 수 있음
  • 단순 요청-응답을 넘어 실시간 양방향 통신이 필요한 경우에도 MCP 쪽이 더 맞을 수 있음

• Quandri는 결국 세 가지를 섞어 쓴다고 함

  • Bash와 CLI는 gh, psql, aws처럼 이미 팀이 매일 쓰는 도구에 사용함. 컨텍스트 비용이 없고 터미널에서 바로 디버깅 가능하기 때문임
  • Skills는 커밋 초안 작성, PR 리뷰처럼 반복되는 다단계 워크플로에 사용함. 필요할 때만 로드되니까 가벼움
  • MCP는 강한 CLI가 없거나, 팀 단위 인증과 권한 범위 제어가 중요한 서비스에 남겨둠. 예로 Slack, Linear, Notion, 프로덕션 DB 접근 같은 케이스를 듦

• 결론은 '무조건 MCP'가 아니라 '도구를 잘 가르치는 게 더 중요하다'는 쪽임

  • Quandri는 MCP 서버를 기존 CLI를 감싼 Skills로 바꾸면서 약 2만1000토큰의 컨텍스트를 아꼈다고 함
  • 일상 워크플로에서 초기화 실패도 줄었고, 디버깅도 터미널이라는 익숙한 장소로 돌아왔다는 설명
  • 요즘 SaaS 랜딩 페이지마다 'MCP 지원' 배지가 붙지만, 실제로는 안정성이나 컨텍스트 비용보다 마케팅 체크박스에 가까운 경우도 있다는 비꼼이 들어감

기술 맥락

• 이 글의 핵심 선택은 MCP를 기본값으로 두지 않고, CLI와 Skills를 먼저 검토하자는 거예요. 이유는 단순해요. 개발자용 도구는 이미 인증, 디버깅, 자동화 흐름이 CLI 중심으로 잘 깔려 있는 경우가 많거든요.

• MCP가 문제 되는 지점은 도구 호출 자체보다 '호출하기 전부터 드는 비용'이에요. Linear 이슈 하나를 읽는 데 실제 응답은 150토큰 정도인데, 도구 정의가 1만2807토큰 붙으면 모델 입장에선 작은 작업을 하려고 큰 매뉴얼을 통째로 들고 다니는 셈이에요.

• Skills 패턴은 이 비용을 늦게 지불하는 방식이에요. Linear 작업이 필요할 때만 GraphQL 예시와 인증 방식을 로드하고, 평소에는 컨텍스트를 비워두는 거죠. 그래서 반복 업무에는 MCP보다 스킬 문서와 CLI 조합이 더 경제적으로 보일 수 있어요.

• 다만 데이터베이스나 권한이 민감한 서비스에서는 얘기가 달라져요. CLI는 모델이 위험한 명령을 실행하지 않도록 구조적으로 막기 어렵지만, MCP 서버는 읽기 전용 정책이나 자격 증명 보호를 서버에서 강제할 수 있거든요. 그래서 이 글의 결론도 MCP 삭제가 아니라, 비용과 안전 요구를 보고 위치를 정하자는 쪽에 가까워요.