Tools: 코드만 있으면 충분해요 - Code Is All You Need

• MCP 방식의 도구 연결이 "미래"라고 주장되지만, 실제로는 조합성 부족과 과도한 컨텍스트 소비라는 한계로 인해, 직접 코드를 작성하는 방식이 여전히 더 효율적임
• LLM 시대에도 자동화·반복 작업에서는 코드를 생성/활용하는 것이 신뢰성과 검증 측면에서 우위에 있음
• LLM은 추론 기반 자동화보다 코드 생성 및 반복 실행에 강점, 코드 기반 프로세스는 문제점 파악과 검증, 확장성이 뛰어남
• Playwright 같은 일부 도구(MCP 방식)는 "추론 기반" 단계마다 불확실성과 디버깅 어려움이 커지고, 코드로 스크립트를 직접 생성/수정하면 반복성, 속도, 신뢰도 모두 향상
• LLM이 코드를 생성하고, 또 다른 LLM이 그 코드를 점검·설명하는 "코드-심사-반복" 루프가 실제로는 가장 강력한 자동화 흐름임

---

코드만 있으면 충분해요

• 만약 트위터에서 나를 팔로우하고 있다면, 최근 Model Context Protocol(MCP)에 대해 별로 긍정적이지 않음을 알 수 있음
• 이유는 아이디어 자체에 대한 거부감이 아니라, MCP가 광고한 대로 효과적이지 않기 때문
• MCP는 두 가지 주요 결함이 있음
  • 진정한 조합성(composable) 을 제공하지 못함
  • 과도한 문맥 제공 요구로 인해, 코드를 직접 작성해 실행하는 것보다 더 많은 문맥 소모가 발생함
• 간단한 실험을 통해 이를 확인할 수 있음
  • 예를 들어, GitHub MCP를 사용해 태스크를 수행한 다음, 동일한 작업을 gh CLI 툴로 해보면, 후자가 훨씬 효과적으로 문맥을 사용하고 더 빠르게 원하는 결과에 도달함

But MCP is the Future! : 하지만 MCP가 미래인데?

• 내가 이 입장(코드가 더 낫다는 주장)에 대해 받은 피드백에 대해 이야기하고 싶음
• 나는 MCP를 에이전트 기반 코딩(agentic coding) 문맥에서 깊이 실험했고, 한계가 가장 뚜렷하게 드러나는 부분에서 평가함
• 한 가지 피드백은, "MCP가 범용 코드 생성에는 굳이 필요하지 않다. 이미 모델이 코드 생성엔 충분히 뛰어나기 때문"이라는 점임. 반면 특정 도메인(예: 금융 기업의 자동화 업무) 같은 엔드유저 지향 애플리케이션에서는 MCP가 의미 있을 수 있다는 의견도 받음
• 또 다른 의견은, 미래에는 모델이 더 다양한 도구에 접근하고 더 복잡한 작업도 처리할 수 있을 테니, 그 가능성에 주목해야 한다는 것임

• 하지만 내 현재 판단은 이러함: 내가 실험한 데이터와 실제 경험에 따르면, 현재의 MCP는 항상 코드 직접 작성보다 사용이 어렵다
  • 가장 큰 이유는 MCP가 추론(inference)에 의존하기 때문임
  • 요즘 "더 많은 툴을 LLM에 연결하려는 모든 시도"를 보면, 결국 LLM이 모든 툴을 받아서 작업에 맞게 필터링하는 계층이 들어감
  • 지금까지 이보다 더 좋은 구조나 접근 방식이 제안된 적이 없음

• 그래서 나는 이렇게 결론내림: 비개발자용 특정 도메인 자동화 같은 특수한 경우에도, 결국 코드 생성이 조합성과 재사용성 면에서 항상 더 나은 선택

Replace Yourself With A Shellscript

• 이 문제를 바라보는 방법: AI가 없을 때, 개발자라면 문제를 해결하는 도구는 코드임
• 비개발자라면 코드가 어렵고, 많은 사람들이 수작업으로 하는 여러 작업도 사실 소프트웨어로 자동화 가능함
• 현실적인 문제는 누가 그 코드를 써주느냐임. 만약 특수한 환경에 있고 직접 프로그래밍을 못한다면, 코딩을 새로 배우기도 어렵고, 누군가가 맞춤형 코드를 써주기를 기대하기도 힘듦
• 물론 일부 작업은 추론(인간의 판단/유연성) 이 꼭 필요할 수 있지만, 사실상 반복적이고 명확한 작업은 대부분 코드로 자동화 가능함

• “나 자신을 셸 스크립트로 대체한다”는 오래된 개발자 관용구가 있는데, 실제로 이런 자동화는 예전부터 지속되어 왔음
• LLM과 프로그래밍의 시대에는, 셸 스크립트 대신 LLM으로 나 자신을 대체하려고 하지만, 여기서 세 가지 문제(비용, 속도, 신뢰성) 가 등장함
• 이 세 가지 문제를 해결하기 전에는, 도구(MCP 등) 사용을 고민할 단계조차 아님
• 즉, 자동화가 실제로 확장 가능한 방식으로 제대로 동작하는지를 먼저 보장하는 것이 핵심임

Automation at Scale : 대규모 자동화의 본질

• 자동화의 핵심은 반복적·재사용 가능한 작업을 코드로 처리하는 것임
• 한 번만 하고 다시는 안 할 작업은 자동화할 필요가 없음. 여러 번 반복할 작업, 기계가 진짜 생산성 이득을 주는 일부터 자동화가 시작됨
• 실제로 1~2번 수동으로 해보고, 동작 방식을 정리한 뒤, 기계가 수천 번 반복 수행하도록 만드는 것이 자동화의 본질임

• 이런 반복적 자동화에는 항상 "코드"를 쓰는 것이 최선임
  • LLM에게 "추론"으로 매번 시키면, 작은 일은 그럭저럭 되지만, 검증에 드는 시간/노력이 결국 자동화 효과를 반감시킴
  • 예: LLM에게 계산을 직접 시키는 것보다는, LLM이 파이썬 코드를 작성하게 하고, 그 코드로 계산하게 하면 신뢰도·확장성 모두 높아짐
    • 코드를 사용하면 공식/로직 자체를 검토 가능하고, 필요시 직접 수정하거나 LLM이 "이 방식이 맞는가"를 심사하도록 할 수도 있음
    • 파이썬이 계산을 잘못한다는 걱정은 할 필요가 없으니, 코드 생성 방식이 검증/신뢰 측면에서 더 낫다는 점이 분명해짐

• 이런 논리는 단순 계산을 넘어서서 실제 개발 실무에도 적용됨
  • 예: 최근 이 블로그의 전체 포맷을 reStructuredText에서 Markdown으로 변환하는 작업을 했음
  • 꽤 오래 미루고 있었는데, 귀찮기도 했지만, LLM에게 직접 변환을 맡기면 어딘가 미묘한 누락/실수나 맥락 왜곡이 생길까봐 신뢰하지 못함
  • 그래서 결국 LLM을 "직접 변환 실행"에 쓰지 않고, 변환용 코드를 생성하게 해서 코드로 처리함

LLM → 코드 → LLM: 반복 검증 자동화의 실제

• 첫 단계로, 나는 LLM에게 reStructuredText를 Markdown으로 변환하는 코어 변환 로직을 생성해 달라고 요청함
  • 단순 변환이 아니라, AST(추상 구문 트리)를 직접 활용해서
    • reStructuredText를 AST로 파싱 → Markdown AST로 변환 → HTML로 렌더링
    • 이렇게 하면 중간 변환 단계를 얻을 수 있고, 결과를 직접 비교·검증하기 쉬워짐

• 두 번째로, LLM에게 기존 HTML과 신규 HTML을 비교하는 스크립트도 작성해 달라고 함
  • 변환 후 HTML의 차이(diff)를 분석하면서, 비교에 앞서 사소한 차이(예: 공백, 푸터노트 처리 방식 등)를 자동으로 보정하도록 설계
  • 변환 과정에서 허용할 수 있는 에러 유형을 LLM이 자체적으로 고려하게끔 함
  • 예: Markdown/ reStructuredText 라이브러리의 HTML 표현이 달라 미세하게 다르더라도, 본질적 손실/오류만 걸러내도록 스크립트에서 반영

• 세 번째로, LLM에게 수백 개 파일의 결과를 일괄 분석하는 배치용 스크립트도 추가로 요청함
  • 이 스크립트로 전체 파일을 돌려가며, 차이가 줄어들 때까지 반복 개선(agentic 루프) 을 진행함

• 전체 과정은 다음과 같음:
  • 처음엔 10개 정도만 샘플로 돌려서 차이가 크게 줄어들 때까지 반복
  • 만족스러운 상태가 되면 전체 포스트에 적용, 30분 내외로 자동 처리
  • 핵심은, LLM이 실제로 변환을 '성공'했기 때문이 아니라, 내가 전체 과정을 "코드"로 검증·리뷰할 수 있었기 때문에 신뢰할 수 있었던 것임

• 여기에 추가로, 다른 LLM에게 생성된 코드와 변경 내용을 점검/해설하게 해 더 높은 신뢰를 얻음
  • 데이터 손실 없이, 기계적으로 올바르게 변환된다는 확신이 있었고, 언제든 샘플 체크·수정이 쉬웠음
  • 최악의 경우에도 마크다운 문법상 사소한 오류만 생길 뿐, 실제 본문 내용이 망가지는 일은 발생하지 않았음

• 또 한 가지 중요한 점은, 이 방식은 추론(inference) 비용이 일정해서 전체 파일 수(15개 vs 150개)에 따른 부담 차이가 크지 않음
  • 최종 분석 단계에서는 이미 사소한 차이는 자동으로 건너뛰기에, 대량 변환에서도 반복 검증 부담이 크지 않음

MCP Cannot Do That

• 이 긴 설명의 요지는 전체 변환·자동화 파이프라인이 "코드"로 돌아간다는 것임
  • 인간 입력 → 코드 생성 → LLM 심사 → 반복 개선, 이런 구조를 일반적인 과제에도 똑같이 적용 가능
• 예를 들어, MCP 방식의 대표 사례인 Playwright가 있음
  • 브라우저를 원격 제어하는 자동화 도구로, 페이지를 읽고 이해하고 버튼을 누르는 등 매 단계마다 추론(inference)이 반복됨
  • 이런 류의 과제는 실제로 "코드 접근"으로 완벽히 대체하기 어렵긴 함

• 하지만, 페이지 구조를 이미 알고 있다면(예: 내가 개발 중인 자체 앱 테스트 등)
  • LLM에게 Playwright 파이썬 스크립트를 생성하게 하고, 그걸 실행하는 방식이 훨씬 빠르고 신뢰성도 높음
  • 이 방식은 한 번 스크립트만 만들면 수십, 수백 번 반복 실행이 가능하고, 추가 추론이 필요 없음
  • 실시간으로 매번 화면을 해석하거나 버튼 위치를 찾지 않아도 되고, 전체 자동화 흐름을 한 번에 실행할 수 있음

• MCP 방식은 매 단계마다 추상화된 도구 호출과 추론이 필요해 LLM이 항상 올바르게 동작하도록 만드는 것이 매우 어렵고, 디버깅도 힘듦
  • 예를 들어 MCP 클라이언트를 셸 스크립트에 임베드해 효율적으로 원격 서비스 호출을 하고 싶어도, 실제로는 이 방식이 매우 비효율적이고 구현도 어렵다는 점을 절감함

• 결국, 나는 인간이지 MCP 클라이언트가 아님.
  • 코드는 실행·디버깅이 쉽지만, MCP 호출은 매번 불확실하고, 신뢰할 수 없음
  • 실제로는 LLM이 코드 생성 중 만들어주는 작은 툴들(예: Claude Code의 스니펫)을 오히려 내 개발 프로세스의 장기적 도구로 활용하고 있음

이 결론은 어디로 이어질까?

• 솔직히 나도 이 흐름이 어디로 이어질지는 모름. 하지만 지금이야말로 "의도적 에이전트 코딩(agentic coding)"을 위한 코드 생성 방식을 어떻게 더 개선할 수 있을지 고민하기 좋은 시점임
• 이상하게 들릴 수 있지만, MCP도 가끔은 정말 잘 동작하는 경우가 있음. 하지만 현재 구조는 너무 "추론"에 의존하고, 확장성 있는 대규모 자동화에는 적합하지 않은 막다른 골목처럼 느껴짐

• 그래서 아마도 MCP가 강점을 발휘할 수 있는 영역과, 코드 생성 방식의 역할을 더 명확하게 분리·추상화하는 방법을 찾아야 할 듯함
  • 이를 위해선 더 나은 샌드박스(안전 실행 환경) 를 만들고, 에이전트가 API를 자유롭게 "팬아웃/팬인(fan out/fan in)" 추론을 할 수 있게 API 설계를 바꾸는 시도도 필요함
  • "코드로 할 수 있는 건 최대한 코드로 처리"하고, 대량 실행 이후엔 LLM이 전체 결과를 판정·리뷰하는 구조가 바람직하다고 생각함

• 그리고 코드 생성 과정에서 충분한 맥락 정보를 추가해서, LLM이 생성된 스크립트가 무슨 일을 하는지 비개발자에게 자연어로 설명할 수 있게 한다면, 향후 이 자동화 흐름을 비개발자들도 손쉽게 활용할 수 있을 것임

• 결론적으로, 나는 MCP 대신 LLM의 코드 생성 능력을 더 과감하게 활용하고, 새로운 가능성을 실험하길 추천함
• LLM이 코드를 직접 쓰게 두면, 우리가 상상하는 것보다 훨씬 더 많은 것을 자동화할 수 있음

참고 자료

• 나의 Agentic Coding Talk (영상)
• Drew Breunig 의 How to fix your context (글)
• Manuel Odendahl 의 MCPs are Boring (영상)

[GN⁺]

Hacker News 의견

• 대체로 이 방향성이 맞음에 공감함. 대규모 LLM 사용은 보통 두 개의 견고한 인터페이스 사이의 빈틈을 채우는 용도로 많이 활용됨. 신뢰성의 핵심은 LLM의 결과물이 아니라, 실제로는 그 인터페이스 자체가 특정한 설정만 허용하는 데서 나옴.
  LLM의 출력은 종종 타입이나 DB의 primary key처럼 좀 더 결정론적인 값으로 강제로 변환됨. LLM의 가치는 기존 코드와 툴이 얼마나 내 도메인의 데이터, 로직, 행동을 잘 모델링하느냐에 따라 크게 달라짐.
  개인적으로 LLM을 요즘은 3D 프린터와 유사하게 느끼고 있음. 둘 다 빠른 프로토타이핑에서 빨리 부품을 이어주지만, 확장성과 견고함을 원한다면 결국 엔지니어나 LLM이 임시 연결부를 금속/코드 같은 결정론적 지원체로 대체해야 함.
  3D 프린터에 대한 과거의 과장된 기대처럼 LLM도 모든 운영 현실을 대체할 수 있을 것처럼 보이나, 진짜로는 기존의 디지털 모델링이 견고한 기반이 될 때만 진짜로 쓸모가 있음

  • 드론이나 VR의 과장된 hype cycle도 비슷했음. 모두가 드론으로 택배 배송하고, VR에서 하루를 보낼 거라고 했지만 실제 적용 사례는 훨씬 좁았음
  • 흥미로운 의견이지만 LLM에 대해 지나치게 보수적 관점인 듯함. 실제로 LLM은 이미 심층 연구나 번역 같은 분야에서 대규모로 쓰이고 있으며, 3D 프린터보다 더 범용적으로 확산된 상태임
  • "방향성은 맞음"이란 표현에 공감함. 우리 회사에선 완전히 맞지 않아도 'directionally accurate'란 용어를 종종 씀. 대략 올바른 방향이라는 의미임

• LLM 툴을 쓸 때 깨달은 점이 있음. 문제를 샌드박스 안에서 반복적으로 툴을 활용해 LLM이 풀 수 있는 형태로 줄이면, 그 문제를 브루트포스로 해결할 수 있음. 이때 핵심은 그런 문제를 식별하고, 맞는 샌드박스와 사용할 툴, 성공 기준을 정하는 것임.
  이 과정도 상당한 기술과 경험이 필요하지만, 손으로 일일이 시행착오를 하는 것보다 훨씬 고차원적임.
  내가 '어셈블리 Mandelbrot 실험'을 하면서 이걸 깨달았음.
  (실험 링크: https://simonwillison.net/2025/Jul/…)

  • "성공 기준 정의"가 마지막에 꼭 필요함. 프랙탈 수학이나 x86 어셈블리를 모르면, "그림이 Mandelbrot처럼 보이나?"란 시각적 확인 밖에 검증이 안 됨.
    이상적으로는 연속 함수 형태의 평가 기준, 최소한 다양한 입력과 그에 대한 기대 출력값을 정량적으로 만들어야 진짜 자동화가 가능함
  • 이 실험 정말 흥미로움. 나도 LLM으로 브루트포스 문제 풀이를 고민 중이었음.
    예시로 LLM이 타입스크립트 제네릭에 약한데, 진짜 TSC를 돌아가게 하면 계속 테스트로 검증하며 맞을 때까지 시도할 수 있음. 코드 유지보수성이 떨어질 수도 있지만 이론상 아주 신기한 구조임.
    게다가 Cursor는 타입스크립트 에러를 볼 수 있어, 유틸리티 타입 테스트만 만들면 Cursor 자체가 테스트를 쓰고 문제를 단순 반복 brute force로 풀 수도 있음
  • 내 경험상 LLM에게 일 맞는 툴 사용하도록 시키는 것이 아직도 큰 도전임. 마치 아이에게 빨래를 가르치는 것처럼, 그냥 내가 직접 하고 싶어질 때가 많음
  • LLM에 올바른 문맥 제공이 중요함. 예시로, 미리 정의된 "인지적 도구"를 활용해서 맥락을 풍부하게 주면 성능이 밝히 개선됨.
    참고할만한 리포: https://github.com/davidkimai/Context-Engineering/…
    아직 전체 못 봤지만 꽤 인상적임
  • 샌드박스에서 도구 루프 돌리기 방식이 클라우드 API를 토큰 많이 써서 하는 걸 요구하는지 궁금함.
    로컬 모델로도 가능한지, 아니면 Claude Code Pro 등 구독으로 할 수 있을지 고민임.
    Mandelbrot 실험도 재밌었지만, 실제 복잡한 상용 코드베이스와는 난이도가 좀 다름

• 이건 MCP 자체의 문제는 아니라 생각함. 현재 AI 수준에선 사람이 중간에 들어가는 구조가 훨씬 우수함.
  LLM은 특정 작업엔 강하지만 종종 로컬 미니마에 갇힘. 그래서 웹 인터페이스에서 왔다 갔다 하며 "프로그램 짜줘 → 확인 & 힌트 제공 → 테스트" 루프를 돌리면 품질이 확실히 좋아짐.
  10,000줄의 엉망 코드를 400줄의 명확한 코드로 바꿀 수 있음. 지금 당장은 이게 현실임.
  물론 많은 기업이나 개발자는 "프로그래머 자체를 LLM으로 대체"하려 하겠지만, 현실에선 아직 불가능함.
  진짜 효과는 프로그래머의 작업 속도를 몇 배로 높이거나, 초심자가 LLM을 통해 빠르게 생산성 있는 작업을 할 수 있게 하는 부분임. 하지만 "agentic coding"은 아직 잘 작동하지 않음.
  현 상황에서 LLM은 동료나 조력자로 쓰는 게 정답임. 지금은 자율적 피드백 없는 "AI 에이전트"가 아니라는 것이 실상임

  • 나도 직접 만든 제품 개발자로, 모든 코드를 혼자 담당하고 claude-code를 도구로 사용함. 언젠가 Claude가 모든 코딩을 대체하길 기대하지만, 아직 거기까지 오진 않았음.
    타입세이프하고 함수형, 컴파일 언어로 작업 중이라 결과물도 항상 직접 읽어야 해서, 덜 엄격한 언어라면 더 걱정될 듯함.
    그럼에도 시간 절약 효과는 큼. 특히 작업을 분할해 큰 목표를 더 쉽게 다룰 수 있게 된 점이 만족스러움

• 실제로 GitHub MCP로 태스크를 해보고, 같은 일을 gh CLI로 하면 gh CLI가 맥락을 훨씬 효율적으로 사용해 속도가 많이 빠름.
  나는 "devops" 폴더에 CLAUDE.md 파일(공통 bash 명령 모음집)이 있음.
  새로운 태스크를 완료하면 Claude에게 예시를 추가하게 하고, 이후 유사 질의엔 Claude가 한 번에 해결함.
  CLAUDE.md 초기 내용 공유:

  • 이 파일은 Claude Code가 코드 작업 시 지침을 제공함
  • 특히 GCP 관련 DevOps 명령(Cloud Composer, Logging, Kubernetes, Cloud Run) 문서화
  • 주요 명령 예시: 환경 세부 정보 보기, DAG 관리, Airflow 로그 확인 등
    (구체적인 명령어는 요약)
  • 가끔 혼란스러움이 있음. 필요한 명령 모음집 파일이 있는데 AI에게 실행시키기만 기다리는 게 비효율적으로 느껴질 때가 있음
  • 참고로, 저 명령들 section을 간단한 stdio MCP 서버로 만들어 Claude Code에 붙이면 각 작업을 툴화하고, 인자 입력 스키마 정의도 가능함. 이미 이런 기능을 지원하는 MCPServer 오픈소스가 있음 (예시: https://github.com/inercia/MCPShell)
  • 나도 비슷한 명령 모음 파일을 Emacs org-mode에서 직접 씀. 접기/펼치기 쉬워서 효율적이며, 코드 스니펫(쉘, 엘리스프 등)을 바로 실행할 수 있음
  • LLM에게 프로덕션/테스트 환경에 특권 API 호출 권한을 그냥 넘기는 것인지, 아니면 sanity check 가능한 예시 명령만 받는지 궁금함. 구체적인 활용 케이스가 궁금함
  • 비슷한 구조로 진행했는데 claude.md가 점점 커져 불편했음. 그래서 커스텀 프롬프트를 앱화해서 상황을 개선했으나, 앱은 결정론적이라 미지의 상황은 대응이 힘듦. 반면, CC는 느려도 미지 상황도 대처가 가능함.
    그래서, 문제 발생 시 커맨드에 앱 테스트&수정 명령을 추가한 셀프 힐링 소프트웨어가 됨

• 지금까지 본 MCP 활용 중에서 가장 인상적이었던 건 Bruce Hauman의 clojure-mcp임.
  LLM에게 (a) bash, (b) persistent Clojure REPL, (c) 구조적 편집 툴을 제공함.
  이로 인해 Clojure 코드를 편집할 때 순수 문자 diff 기반 접근보다 훨씬 효율적으로 작동함.
  제대로 된 테스트 스위트만 있다면 파일 편집, 리로드, 테스트 반복이 사람 작업에 가깝게 진행되어 놀랐음

  • 나도 clojure-mcp가 지금까지 본 MCP 중 가장 멋진 활용이라고 생각함.
    코드 디버그, 개별 식 평가, 함수 반환 타입 문서화 등 주요 기능 지원함.
    강력한 REPL을 가진 언어가 그런 기능에서 훨씬 우수하다고 느꼈고, clojure-mcp 활용 가능성을 보고 AI에 대한 인상이 크게 바뀜
  • 참고로 공식 리포 링크: https://github.com/bhauman/clojure-mcp

• GitHub CLI 예시는 MCP의 강점을 다 보여주진 못함.
  gh CLI처럼 문서 접근성이 좋은 툴은 LLM이 쉽게 코드 생성하니까 당연히 더 잘 활용함.
  하지만 MCP의 진짜 장점은 내부전용 툴이나 온라인 문서가 거의 없는 니치 API에서 드러남.
  모든 문서를 맥락에 넣는 방식도 있지만, 이런 경우는 오히려 MCP가 더 효율적임.
  잘 설계된 MCP 툴을 올바른 인풋과 함께 쓰면, LLM의 API 이해, 인증, 엣지 케이스 관리 등 부담이 대폭 줄어듦.
  GitHub에는 MCP가 굳이 필요 없겠지만, 사내/불완전 API 같은 환경에선 사전에 만들어둔 MCP 툴이 더 강력하게 통함

  • MCP도 결국에는 문서를 LLM 입력 맥락에 주입하는 접근임. LLM이 잘 아는 환경(파이썬, 자바스크립트, bash 등)에선 MCP 툴 호출보다 아는 방식 활용이 낫고, 오히려 툴 정의로 맥락 소모 심함.
    예시로 sonnet4에선 툴 15개만 넘어도 한계점임. 공식 playwright MCP만 써도 툴 용량 소모함
  • MCP 서버가 인증 등 처리를 단순화하긴 하지만, 내부 API 자체를 애초에 그렇게 설계할 수 있지 않았냐는 반론도 있음.
    결국 MCP의 유일한 장점은 API가 너무 어렵게 느껴질 때 "이게 단순히 복잡했다"는 사실만 재확인하는 데 쓰일 수 있음

• Playwright 예시 관련,
  나 역시 이번 주에 Playwright MCP 서버 기반으로 에이전트 만들었다가 느리고, 토큰 비효율적이며 신뢰성이 낮아 다시 직접 Playwright 호출로 바꿨음.
  MCP 서버는 뭐가 가능한지 테스트엔 좋은데, 실제론 API 호출이 더 효율적이고 안정적임.
  내가 만든 개인 LinkedIn 에이전트 예시 및 데모 공유:

  • 프로젝트: https://github.com/pamelafox/personal-linkedin-agent
  • 데모: https://www.youtube.com/live/ue8D7Hi4nGs
  • Playwright MCP 구현도 내겐 지나친 솔루션이었음. 오히려 Playwright API의 일부만 제한적으로 베껴온 참고용 구현이라고 생각함.
    LinkedIn은 자동화가 굉장히 어려운 플랫폼으로 유명한데, 개인용 LinkedIn 에이전트 만들면서 어려움이나 제한을 겪었는지 궁금함

• 사실 터미널만 있으면 충분하다고 느낌.
  수개월간 MCP를 매일 썼지만, 이제는 오직 하나의 iTerm2 기반 MCP 서버(터미널) 만 씀.
  필요시 OpenAPI spec이 있긴 하지만, 실제로는 shell command랑 curl로 거의 모든 걸 수행할 수 있음

  • 나 역시 LLM이 bash shell의 내장 툴을 활용하는 걸 보고, bash로 가능한 한계가 어디까지인지를 처음 깨달았음

• "너무 많은 맥락 필요"란 지적은 사실 초기 프롬프트 기본값 설정만 잘 해두면 됨.
  Claude Code나 Gemini CLI 포함 주요 툴은 모두 지원함
  LLM에 모든 툴 리스트를 넘기고, 스스로 걸러쓰게 하는 방식이 최고의 접근은 아니지만,
  최신 LLM은 계속 발전하며, 실제로 적절한 MCP 함수 선택에 큰 어려움을 겪은 적이 없음.
  비용, 속도, 신뢰성 문제도

  • 비용: 최근엔 점점 저렴해지고 있음. 실제로 놀라운 가성비임.
  • 속도: 여러 작업을 동시에 시킬 수 있어 비효율적이지 않음.
    대화에 직접 시간을 쓰지 않아도 됨
  • 신뢰성: 프롬프트 품질에 많이 좌우됨.
    최근 예시로 Notion, Linear, git, GitHub PR/CI 로그 등 대량 외부 툴을 LLM이 자동으로 처리했고,
    나는 단 한 번 PR 리뷰만 했을 뿐임.
    비용도 1달러 미만이었음
  • MCP 툴이 많아질수록 초기 프롬프트 맥락 소모가 더 심해짐.
    오히려 툴을 추가할수록 초기에 필요한 정보가 더 많아져서 심각한 제약이 발생할 수 있음
  • 비용 문제는 실제로 점점 낮아진다기보다,
    아직 감춰져 있을 뿐이며, 무료·저가 프로모션 구조는 오래 못감.
    예시로 Cursor도 월 $200 요금제가 도입되고, 저가 요금제의 서비스 품질이 악화됨.
    무료 프로모션이 끝나면 원래 수준으로 돌아올 것임

• 나는 Julia로 일하는데, 장기 실행 세션 환경에서 이득을 봄.
  함수 최초 실행 시 컴파일되므로, MCP를 만들어 Claude Code가 영속적 Julia kernel(Jupyter) 로 코드 전송하게 함.
  테스트 코드 실행이 훨씬 빨라지고, CC가 bespoke bash 대신 코드베이스의 기존 함수를 더 잘 활용함.
  CCUsage 기준 토큰 사용량도 50% 가까이 줄었음.
  꼭 MCP일 필요도 없었겠지만, 요지는 '특정 기능'을 코드베이스에 붙이는 게 Claude 대상으로 일일이 custom 코드를 짜는 것보다 쉽다는 점임

  • "Claude가 bespoke bash 대신 바로 코드 함수 실행"을 선택하는 게 오로지 kernel에 직접 코드 전송 가능이어서 그런 건지 궁금함

[bluems]

공감은 하지만, MCP 문제보단 그 제작장.ㅣ 설계 방향의 최적화 같습니다. 같은 기능을 해도 어떤 MCP냐에 따라 내부적으로 코드를 생성하고 명령어를 생성해서 불필요한 작업을 줄이기 때문이죠. Github mcp가 아닌 gh cli mcp나 터미널 mcp를 쓰면 토큰은 쓰긴 하지만 훨씬 덜 사용하고, 같은 효과를 얻을 수 있는데, 이 부분이 간과된 것 같네요.