MCP는 죽었나?

(quandri.io)

1P by GN⁺ 4시간전 | ★ favorite | 댓글 2개

MCP는 LLM을 외부 도구에 연결하지만, 개발 워크플로에서는 컨텍스트 비용·운영 안정성·CLI/API 중복이 큰 부담으로 드러남
Quandri 측정에서 Linear·Notion·Slack·Postgres의 도구 정의 77개는 약 21,077토큰으로 Claude 200K 컨텍스트의 10.5%를 차지함
Linear 이슈 조회는 MCP 방식이 42개 도구 정의를 항상 싣기 때문에 CLI 방식 약 200토큰보다 훨씬 큰 약 12,957토큰을 소비함
MCP는 별도 서버 프로세스와 인증·초기화·충돌·외부 왕복 지연이 붙지만, CLI/API는 터미널에서 재현·디버깅·조합하기 쉬움
Quandri는 기존 CLI를 Skills로 감싸 약 21K 토큰을 확보했고, CLI가 없거나 팀 단위 권한 제어가 필요한 경우에만 MCP를 사용함

MCP가 드러낸 핵심 비용

MCP(Model Context Protocol) 는 LLM을 GitHub, Linear, Notion, Slack 같은 외부 도구에 연결하지만, 실제 개발 워크플로에서는 컨텍스트 사용량, 운영 안정성, 기존 CLI/API와의 중복이 주요 문제가 됨
2024년 말 출시 이후 “AI 생태계의 USB-C”로 불렸지만, 일상적으로 쓰는 개발자에게는 다른 비용이 먼저 드러남
Claude Code에는 측정 이후 Tool Search with Deferred Loading이 도입되어 MCP 도구 스키마를 필요할 때 로드하고 컨텍스트 사용량을 85% 이상 줄임
현재 Claude Code에서는 컨텍스트 팽창 문제가 상당 부분 완화됐지만, 성능, 디버깅, 아키텍처 문제는 여전히 남아 있음

컨텍스트 창을 크게 소모함

컨텍스트 창은 LLM이 작업에 쓰는 공간이며, MCP 서버를 연결하면 실제 작업 내용이 아니라 도구 정의만으로도 큰 부분이 차지됨
Quandri 환경에서 연결된 MCP 서버의 실제 도구 정의를 추출해 측정한 결과, 4개 서버를 모두 연결하면 도구 정의만으로 컨텍스트 창의 10.5% 가 사용됨
도구 정의 크기:
- Linear: 42개 도구, 약 51,229자, 약 12,807토큰
- Notion: 14개 도구, 약 16,156자, 약 4,039토큰
- Slack: 12개 도구, 약 15,168자, 약 3,792토큰
- Postgres: 9개 도구, 약 1,755자, 약 438토큰
- 전체: 77개 도구, 약 84,308자, 약 21,077토큰
모델별 컨텍스트 사용량:
- Claude 200K 컨텍스트에서는 도구 정의가 10.5%를 차지함
- GPT-4o 128K 컨텍스트에서는 도구 정의가 16.5%를 차지함
Linear 단독으로도 42개 도구 정의가 항상 로드되어 약 12,800토큰 이상을 차지하며, 실제로 get_issue와 save_issue만 쓰는 경우에도 전체 정의가 함께 실림
큰 도구 정의 예시:
- linear/save_issue: 2,479자, 약 619토큰
- slack/search_public: 1,614자, 약 403토큰
- linear/list_issues: 1,588자, 약 397토큰
- notion/fetch: 1,379자, 약 344토큰
- slack/send_message: 1,248자, 약 312토큰

운영 안정성과 성능 부담

MCP는 별도 프로세스를 시작하고 유지해야 하므로 초기화 실패와 반복 인증 문제가 생길 수 있음
도구 호출마다 외부 서버 왕복이 필요해 AI 응답 속도가 느려짐
MCP 서버 프로세스가 충돌하면 세션 중간에 도구가 사라질 수 있음
각 도구가 실제로 어떤 권한을 갖는지 불분명해 권한 가시성이 낮음
MCP is dead. Long live the CLI의 Jira MCP 벤치마크에서는 REST API 직접 호출 대비 MCP가 호출당 3배 느렸고, 초기화를 포함한 첫 호출은 9.4배 느렸음
이 성능 차이는 Jira에만 한정되지 않고, LLM과 기본 API 사이에 MCP 서버라는 프로세스 계층이 추가되는 구조에서 비롯됨
같은 오버헤드는 Quandri 스택의 Linear, Notion, Slack 서버에도 적용됨

기존 CLI/API와 중복됨

CLI/API는 사람과 LLM이 같은 명령을 사용할 수 있지만, MCP는 LLM 대화 내부에서만 존재함
CLI/API는 파이프, jq, grep과 자유롭게 조합할 수 있지만, MCP는 서버가 반환하는 형식에 묶임
CLI/API는 터미널에서 즉시 재현하고 디버깅할 수 있지만, MCP는 대화 컨텍스트 안에서만 재현 가능함
LLM은 이미 man page와 StackOverflow를 통해 CLI/API 사용법을 학습했지만, MCP는 별도 도구 정의가 필요함
CLI/API는 대부분 이미 설치되어 있는 반면, MCP는 서버 설정, 인증, 프로세스 관리가 추가로 필요함

Linear 이슈 조회의 토큰 비용

같은 Linear 이슈를 조회할 때 MCP 방식은 CLI 방식보다 약 65배 많은 토큰을 소비함
CLI 방식은 약 200토큰을 사용함:
- curl 명령 프롬프트: 약 50토큰
- 응답: 약 150토큰
MCP 방식은 약 12,957토큰을 사용함:
- 항상 로드되는 Linear 도구 정의 42개: 약 12,807토큰
- 도구 호출과 응답: 약 150토큰
CLI 예시는 Linear GraphQL API를 직접 호출함:

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

대안: CLI 우선 전략과 Skills

CLI → API → 문서 순서로 제공하는 방식이 더 가볍고 직접적임
LLM은 이미 man page와 StackOverflow에서 CLI 사용법을 학습했기 때문에 별도 도구 정의를 항상 싣지 않아도 됨
기존 CLI를 직접 사용하면 도구 정의로 컨텍스트를 낭비하지 않고, 사람과 AI가 같은 인터페이스를 사용하므로 디버깅이 쉬움
파이프라인을 통해 다른 명령과 자유롭게 조합 가능함
MCP가 “식탁에 모든 메뉴를 미리 펼쳐놓는” 방식이라면, Skills는 “필요한 책만 사서에게 요청하는” 방식에 가까움
MCP는 연결 시 모든 도구 정의를 로드하고 항상 컨텍스트를 점유하지만, Skills는 필요할 때만 로드되고 사용 중일 때만 컨텍스트를 차지함
서버가 늘어날수록 MCP의 컨텍스트 압박은 커지지만, Skills는 스킬 수에 비례해 항상 컨텍스트를 차지하지 않음
핵심은 CLI 사용 지침을 Skills 안에 넣는 방식이며, CLI 우선 전략과 결합하면 가장 효율적임
Linear Skill 예시는 API URL, 인증 방식, 이슈 조회용 curl 명령, GraphQL 검색 방식, jq로 JSON을 파싱한다는 지침만 포함함:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

이 방식에서는 LLM이 해당 스킬을 호출할 때만 위 내용을 컨텍스트에 로드함
42개 Linear 도구 정의를 항상 들고 다니지 않고, 필요한 CLI 명령만 로드하면 됨

MCP가 여전히 유효한 경우

서비스에 CLI가 없을 때 MCP가 유일한 연결 방식일 수 있음
터미널을 쓰지 않는 비개발자 사용자에게는 MCP가 더 접근하기 쉬움
단순 요청-응답을 넘어서는 실시간 양방향 통신에서는 MCP가 적합할 수 있음

데이터베이스 접근의 선택 기준

데이터베이스는 결국 쿼리 실행이며, LLM은 SQL과 MongoDB 쿼리를 이미 잘 알고 있음
DB 정보와 CLI 사용법을 Skill에 넣고 스키마를 제공하면 MCP 없이도 LLM이 쿼리를 작성할 수 있음
Postgres Skill 예시는 호스트, 테이블 스키마, psql CLI 사용법만 포함함:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

데이터베이스에서는 MCP의 장점도 있음:
- 쿼리 안전성: MCP 서버가 읽기 전용 모드를 강제하고 위험한 쿼리를 서버 레벨에서 차단할 수 있음
- 자격 증명 보호: CLI 방식은 프롬프트에 연결 문자열이 노출될 수 있지만, MCP 서버는 내부에서 자격 증명을 관리함
로컬 개발 또는 개인 DB에는 Skills + CLI가 가볍고 빠르며 실수에서 복구하기 쉬움
프로덕션 DB 또는 공유 팀 환경에는 MCP가 적합하며, 서버 레벨의 쿼리 검증과 접근 제어 같은 안전장치가 중요함
대부분의 개발자 워크플로에서는 MCP가 과도한 설계가 되기 쉬움

Quandri의 사용 방식

Quandri는 서비스에 맞춰 Bash + CLI, Skills, MCP를 함께 사용함
gh, psql, aws처럼 매일 쓰는 도구에는 Bash + CLI를 사용함:
- 컨텍스트 비용이 없음
- 유연성이 높음
- 터미널에서 바로 디버깅 가능함
커밋 작성과 PR 리뷰처럼 반복적인 다단계 워크플로에는 Skills를 사용함:
- 호출될 때만 로드됨
강한 CLI가 없는 Slack, Linear, Notion 같은 서비스에는 MCP를 사용함
프로덕션 데이터베이스 접근처럼 팀 단위 인증이나 권한 범위 지정이 중요한 경우에도 MCP를 사용함
이미 CLI가 있고 로컬 인증이 가능하면 보통 그 방식이 가장 가벼움
서비스에 CLI가 없거나 팀 전체에 일관된 인증이 필요하면 MCP가 가치를 가짐

결론과 측정 방식

모든 것을 연결하는 것보다 잘 가르치는 것이 더 중요함
Quandri에서는 기존 CLI를 감싸는 Skills로 MCP 서버를 대체해 약 21K 토큰의 컨텍스트를 확보함
일상 워크플로에서 초기화 실패가 사라졌고, 디버깅은 터미널에서 유지됨
필요한 도구만, 필요한 때에, CLI 지침과 함께 로드하는 방식이 더 효율적임
MCP가 앞으로 이런 문제를 해결하도록 진화할 수는 있지만, 현재 기준으로는 Skills가 더 나은 선택임
측정 방법:
- Claude Code 환경에서 실제 로드된 MCP 서버의 각 도구 JSON 스키마를 추출함
- 도구 이름, 설명, 매개변수를 기준으로 크기를 측정함
- 토큰 추정은 약 4자당 1토큰 휴리스틱을 사용함
- 전체 서버 추정치는 샘플 도구 평균에서 외삽함

▲

aer0700 2시간전 [-]

그냥 본인 상황에 맞는 기술을 택하면 되지 않을지 싶은데요. 죽었다기엔 이미 너무 많이 쓰고 있는데, 싶습니다.

답변달기

▲

GN⁺ 4시간전 [-]

Hacker News 의견들

OpenAI에서 ChatGPT App Store, Codex 플러그인, MCP 전반을 맡는 팀을 이끌고 있는데, “MCP는 죽었다”는 글들이 놓치는 점은 MCP가 전송 프로토콜로 쓰이느냐는 사실상 중요하지 않다는 것임
MCP가 죽지 않은 이유는 지구상의 거의 모든 회사가 MCP 서버를 만들고 있기 때문이고, 우리는 그들과 직접 접촉하니 알 수 있음
이 회사들 다수는 CLI가 없고, 심지어 외부 API도 없는데 MCP 서버는 만들고 있음
내부적으로 모든 MCP 서버를 CLI로 바꾸거나, 코드 모드를 쓰거나, 도구 검색을 구현할 수도 있지만 그건 구현 세부사항일 뿐이고, 핵심은 AI 에이전트가 원래는 접근할 수 없던 서비스에 접근하게 된다는 점임
모델이 직접 대화하는 통신 계층으로서 MCP가 죽었는지는 애매할 수 있지만, 프로토콜로서 MCP가 죽었다는 건 전혀 아님
Codex 앱의 컴퓨터/브라우저 사용 기능 때문에 이 주장은 예전보다 약해졌고, 아직 안 써봤다면 정말 놀라운 수준임
- MCP는 죽을 가능성이 크다고 봄
  가장 큰 이유는 실제 구현이 API든 웹이든 CLI든, 그 위에 동기화가 깨질 수 있는 또 하나의 계층과 사람을 추가하기 때문임
  AI가 사람이 접근하고 알고 쓰는 것과 다른 프로토콜이나 지시 집합을 써서는 안 됨
  지금은 회사들이 유행이라 MCP 서버를 노출하고 싶어 하지만, 현실은 Claude로 기존 API 위에 MCP 서버를 만들고, 가끔 공개 문서에 맞게 업데이트하라고 다시 시키는 식임
  API 문서가 이미 공개돼 있고 Claude Code도 인터넷의 공개 문서만 읽고 MCP 서버를 만들었으니, MCP는 현재 모델 한계에 대한 임시 우회책처럼 느껴짐
- MCP는 결국 “대규모 언어 모델이 쓸 수 있는 API”라는 브랜드명에 가까움
  그 결과 기술 지향적이지 않던 회사들도 에이전트 시대에 도구가 낡아 보이지 않도록 API를 만들고 있음
  목표 자체는 찬성하지만, 이를 위한 프로토콜로 이걸 고르겠느냐는 별개이고, 어쨌든 사람들이 들어봤고 실제로 쓰는 프로토콜이 됨
- “지구상의 거의 모든 회사가 MCP 서버를 만든다”는 말이야말로 에코 체임버처럼 들림
- MCP는 실제로는 존재하지 않는 문제를 풀면서 여전히 귀한 문맥 창을 소비함
  MCP가 없으면 서비스에 에이전트가 접근하지 못한다는 주장은 좋게 봐도 오해를 부르고, 기사에서 말하듯 명령줄 도구와 그 입출력만으로도 접근 가능함
  순수 기술 관점에서도 MCP는 명령줄 도구에 비해 합성 가능성이 낮고, 합성 가능성을 중시하지 않는 쪽은 결국 그 대가를 치르게 된다고 봄
  직설적으로 말하면 투자 편향이 있고, 수많은 회사에 MCP를 팔고 있다는 사실이 그 편향을 반박해주지는 않음
  Microsoft만 봐도 유용성과 기술이 얼마나 깊이 묻히는지는 별 상관이 없고, 오히려 반대라고 보는 사람도 있음
  지금 OpenAI가 MCP를 밀어붙이는 것도 조직적 요인이 크다고 의심되며, 내부에서는 보기 어려울 수 있음
- CLI가 없는 곳에서 MCP를 만들고 있다는 얘기는 꽤 불안함
  기존 CLI 기능을 더 나은 에이전트 통합용으로 복제하는 것과, 나중에 더 낫다고 판단할 수도 있는 명세에 모두를 묶는 유일한 인터페이스로 만드는 건 다름
  그렇게 되면 나중에 MCP 부채를 갚아야 하고, 결국 안 하는 편이 더 싸게 먹힐 수 있음
이 글은 AI가 쓴 건가 싶음
MCP는 본질적으로 몇 가지 특수 필드를 포함해야 하는 JSON-RPC에 가까움
JSON-RPC에 대한 우려는 있지만, 대규모 언어 모델이 연동할 수 있는 서비스 발견 계층은 필요함
웹사이트, 데스크톱 애플리케이션, 백엔드 서비스 등 여러 곳에서 가능해야 하고 CLI는 이런 시스템과 만나는 지점 중 하나일 뿐임
MCP를 무엇으로 대체하든 통신 프로토콜이나 도구 발견 필드를 다르게 지정하더라도 비슷한 형태가 될 가능성이 큼
- MCP 관련 글을 읽을 때마다 인터넷이나 HN 전체가 집단 발작을 하는 느낌임
  API가 MCP보다 낫다고 하지만 MCP는 그냥 AI가 사용법을 발견할 수 있도록 약간의 지침이 붙은 API일 뿐임
  CLI를 쓰자고도 하는데, 그게 정확히 무슨 뜻인지 모르겠음
  대규모 언어 모델이 ffmpeg 같은 흔한 CLI 도구를 잘 쓰는 건 그 지식이 가중치 안에 굳어져 있기 때문임
  새 CLI 도구를 만들면 여전히 AI에게 사용법을 가르쳐야 하고, 그 “가르치는” 부분을 서버에서 제공하고 싶으면 MCP, 로컬의 정적 형태로 두고 싶으면 스킬임
  이렇게 단순한 개념을 두고 왜 논쟁이 이렇게 많은지 모르겠음
- 문제는 MCP가 문맥을 비교적 영구적으로 차지하고, 깔끔한 설치/제거 및 발견 체계가 함께 오지 않는다는 점임
  스킬은 전부 MCP 기반이어야 하고, 필요할 때만 불러오며, 사람과 AI가 쉽게 관리하고 발견할 수 있어야 제대로 작동할 것임
  실제 적용 범위를 보면 초기 범위가 너무 좁았고, 그 위에 무언가를 얹는다면 아직 되살아날 수 있음
“문제 1: 문맥 창을 집어삼킨다”는 주장에 대해, linearcli --help, notioncli --help, slackcli --help를 차례로 실행하는 것과 뭐가 다른지 모르겠음
오히려 MCP에서는 실행 환경이 각 도구의 제목만 문맥에 넣고, 전체 문서는 필요할 때 MCP 서버별·도구별로 추가할 수 있음
CLI로 같은 효과를 내려면 모든 CLI가 --short-descr 같은 명령을 제공해야 함
“문제 2: 낮은 운영 신뢰성”도 도구가 REST API를 쓴다면 프로토콜이 비슷하니 MCP가 더 느릴 이유가 없음
느리다면 API 위에 MCP가 덧붙고, 멀리 있는 데이터센터의 하청 서버에 올라간 식의 구현 문제일 가능성이 큼
대부분의 MCP 서버가 엉망일 수는 있지만 그건 프로토콜이 아니라 업계 문제임
“문제 3: 기존 CLI/API와 겹친다”는 이미 CLI 도구가 있을 때는 맞고, SQL MCP 서버나 curl MCP는 토큰 낭비처럼 보임
하지만 대부분의 조직에는 CLI가 없고, 있어 봐야 대규모 언어 모델이 아니라 프로그램이 쓰도록 설계된 API뿐임
“CLI → API → 문서 순으로 제공하라”는 말은, 느리고 낭비적인 웹사이트 대신 회사가 먼저 데스크톱 네이티브 클라이언트와 모바일 네이티브 클라이언트를 제공하라는 말처럼 들림
- 이 분야를 깊게 파본 건 아니지만, 최신 Claude Code 릴리스를 제외하면 MCP는 문맥에 선적재되는 것으로 알고 있음
  자주 필요하지 않으면 껐다가 필요할 때 다시 켜야 함
  스킬 파일에 사용 예시를 넣으면 첫 --help 호출을 줄일 수도 있고, CLI라면 별도 문맥을 가진 하위 에이전트를 띄워 결과만 돌려받기도 쉬워 보임
글에는 날짜가 없지만, 지연 도구 로딩이 글 작성 뒤에 나온 최근 업데이트라고 말함
그런데 지연 도구 로딩은 2025년 11월에 추가됐음: https://www.anthropic.com/engineering/advanced-tool-use
따라서 이 숫자들은 최소 7개월은 지난 것이고, 왜 지금 올라왔는지 모르겠음
- 아직도 이걸 논의한다는 게 이상함
  지연 도구 로딩, 큰 문맥, 프롬프트 캐싱 때문에 2026년은 2025년과 완전히 달라졌음
  CLI가 토큰을 아낀다는 논쟁도 첫 단계가 --help 실행이라면 무너짐
  호출 방법이 매개변수 기억에 없다면 결국 문맥 안에 있어야 한다는 문제는 그대로임
- 그보다도 더 오래된 글로 보이고, GPT-4o가 최신인 것처럼 암시함
- 지연 도구 로딩은 MCP의 일부가 아님
  대부분의 다른 대규모 언어 모델 API가 지원하지 않는 Claude API 전용 매개변수임
- 글은 2026년 5월 29일 글이고, 그 업데이트가 글 이후의 “최근” 변화였다고 말하는 건 본인들이 더 좋아 보이게 하려는 거짓말임
MCP는 조직 수준에서, 내부 에이전트 도구를 쓰는 비기술 직원에게 내부 유틸리티 API에 대한 통합되고 안전한 접근을 제공해야 할 때 잘 맞는다는 훌륭한 글이 있었던 것 같음
워크플로는 스킬로 코드화해 인스턴스 간에 공유하고, 문맥 인식 API 접근이 필요한 것은 MCP가 맡는 식임
- 이 글인가? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- 그렇다면 에이전트가 API에 직접 접근하는 것과 비교해 MCP의 장점이 무엇인지 궁금함
- 이게 API를 보호하는 권한 체계를 대신하는 건가 싶음
  API에는 어쨌든 어떤 형태로든 권한 메커니즘이 있어야 할 것 같음
- 맞는 말임
  Runlayer 같은 회사가 빠르게 성장하는 것도 바로 이 이유 때문이고, 중앙 제어 평면이 없으면 MCP는 지뢰밭이 됨
이미 나온 점들 외에도, 원격 MCP는 서버 주도라서 생산자가 모든 클라이언트의 스킬과 CLI를 업데이트하지 않아도 새 기능을 추가할 수 있음
또 원격 MCP는 로컬 시스템에서 실제 코드 실행 권한을 요구하지 않으므로 안전함
스킬은 종종 npx/uvx로 스크립트를 묶는데, 이건 사실상 curl npm.com | bash 수준으로 위험함
팀들을 사내 관리 시스템에 연결하는 스킬을 구현해봤고, 결국 그것을 MCP로 등록하게 됐음
MCP는 문서 grep과 API 호출만 노출해서 그 자체로는 완전히 쓸모없지만, 이 경로를 택한 주된 이유는 배포였음
비기술 팀은 URL을 추가하면 모든 것이 작동하고 OAuth가 안내되는 UI를 원하며, MCP는 Claude나 ChatGPT에서 그걸 가능하게 해줌
채팅 UI에서 MCP 호출이 보이는 방식도 더 좋고, 사용자에게 더 명확함
MCP 서버를 다루고 모든 플랫폼용 CLI를 배포하는 대신, API를 SSH로 노출하면 어떨까 싶음
SSH는 대규모 언어 모델에 완벽한 프로토콜임
코딩 에이전트는 이미 쓸 수 있고, ssh api@example.com list-users면 충분함
사용자의 90%는 이미 ssh가 설치돼 있을 가능성이 크고, 입력도 출력도 텍스트라 대규모 언어 모델에 딱 맞음
공개키 인증, 스트리밍 출력, 대화형 입출력, 원한다면 scp/rsync를 통한 파일 전송까지 처리함
사용자가 계정을 Github나 GitLab에 연결했다면 ssh 키를 긁어와 인증을 미리 설정할 수도 있어, 그냥 접속하면 바로 들어가게 만들 수 있음
- 이걸 조직 전체 규모로 확장해보면 됨
식당 비유는 좋지 않음
“10개의 메뉴판이 테이블에 펼쳐져 음식 놓을 자리가 없고, 주문할 때마다 메뉴판을 다시 꺼내야 한다”는 식인데, 반복 주문은 타파스 식당이 아니면 흔하지 않음
음식은 메뉴판 위에 올릴 수도 있고, 보통은 주문 후 메뉴판을 치워서 테이블, 즉 문맥을 비움
비유로 설명하려면 더 관련성 있게 만들려는 노력이 필요함

답변달기

MCP는 죽었나?

MCP가 드러낸 핵심 비용

컨텍스트 창을 크게 소모함

운영 안정성과 성능 부담

기존 CLI/API와 중복됨

Linear 이슈 조회의 토큰 비용

대안: CLI 우선 전략과 Skills

MCP가 여전히 유효한 경우

데이터베이스 접근의 선택 기준

Quandri의 사용 방식

결론과 측정 방식

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들