MCPs are Boring (or: Why we are losing the Sparkle of LLMs) - Manuel Odendahl

영상 링크: MCPs are Boring (or: Why we are losing the Sparkle of LLMs) - Manuel Odendahl
채널명: AI Engineer

MCPs는 지루하다(혹은: 왜 우리는 LLM의 반짝임을 잃어가고 있는가) 핵심 요약

• 진행자 Manuel Odendahl는 25년 경력의 소프트웨어 엔지니어로, 2022년부터 LLM을 이용한 코딩에 집중 중임을 소개
• LLM은 자연어로 툴을 호출하는 구조화된 코드(펑션, API 등)를 매우 쉽게 생성할 수 있어, 개발자가 일일이 스키마를 작성·검증할 필요 없이 대화로 시스템과 상호작용 가능
• MCP(Multi-Component Protocol)는 다양한 외부 툴(GitHub, Blender, 파일, IoT 등)에 LLM 앱이 손쉽게 접속할 수 있게 해주지만, 툴 개수가 많아질수록 LLM이 최적의 툴과 파라미터를 잘못 선택하는 등의 난점이 커짐
• 툴 호출 결과로 전체 JSON 등 대용량 응답을 모두 LLM에 입력해야 해, 쓸데없는 토큰 사용 및 응답 지연, 비용 증가 등의 문제가 발생(예: 필요한 데이터가 1개뿐이어도 만 개의 정보를 로딩)
• 툴 콜 시 챗 히스토리, 메모리, 첨부 파일 등 애플리케이션 컨텍스트 전체를 LLM/툴에 전달하면 반복 처리·최적화가 가능하지만, 복잡한 프로토콜 설계와 보안상 제약 등으로 실현이 제한적
• MCP의 현재 인터페이스는 “허용” 여부만 묻는 단조로운 방식이며, 입력/출력값 편집이나 파일 첨부 등 상호작용적·유연한 UI를 지원하지 않아 UX가 제한됨
• LLM은 실제로 코드를 생성하는 데 매우 뛰어나며, 복잡하고 다양한 API/라이브러리 호출, 쿼리 생성을 쉽고 효과적으로 할 수 있음
• 단일 MCP 예시로 ‘eval’(평가)만 제공해도, SQL 등 실제 코드 실행으로 필요한 결과를 반복적·효율적으로 구할 수 있으며, 이를 재사용 가능한 뷰/함수로 확장 가능
• 코드 및 함수 집합(=라이브러리)을 그대로 불러와, 반복적 도구 호출 없이 자유롭게 기능 조합·확장·재사용 가능, LLM이 함수목록을 보다 잘 활용함이 실험으로 확인됨
• UI 생성 또한 LLM이 DSL(도메인 특화 언어)로 출력해 편집, 필터링, 호출입력 등을 시각적으로 지원할 수 있고, 이로써 Tool-Calling에서 벗어나 ‘코드로 모든 것을 푸는’ 무궁무진한 활용 가능성을 제안함

세부 요약 - 주제별 정리

Manuel Odendahl는 LLM 코딩 경험을 바탕으로 MCP 구조의 한계를 체감함

• Manuel Odendahl는 25년 차 소프트웨어 엔지니어로, 임베디드, 백엔드, 데이터베이스, 검색엔진 등 다양한 도메인에서 개발 경험을 쌓음
• Alpha Copilot 시절부터 LLM을 적극적으로 활용해왔으며, ChatGPT 공개 후 LLM 중심 코딩에 몰두
• Twitter ‘program with AI’ 계정, GitHub ‘Vasin’ 활동 등으로 LLM 코딩 팁 공유
• LLM과 툴 콜링(tool calling) 체계의 초기 실험자로, 실제 서비스에 어떻게 적용되는지 직접 경험

LLM 툴 콜링의 기본 구조와 혁신성은 매우 크지만 한계도 분명함

• LLM은 자연어로 도구 호출을 구조화(특수 토큰 및 스키마로 도구 목록 제공)해서 API, 펑션, MCP 서버 등을 자유자재로 요청/응답 가능
• 사용자의 대화형 요청(예: “샌프란시스코 날씨 알려줘”) → LLM은 도구 목록/스키마를 Context로 받아 도구를 판단하여 호출 → JSON 등 구조화된 응답 → LLM이 최종 사용자 답변 출력
• 직접 스키마 설계/검증/파싱 하지 않고, LLM에 “API를 호출해서 결과를 알려줘”라는 식으로 대화, 개발 생산성 향상
• 자신만의 도구뿐 아니라, MCP로 외부 서비스(GitHub, Blender, 집의 온습도 등)와 연결되는 무한한 확장성 제공
• 초기에 도구 연동의 마법처럼 느껴질 수 있으나, 실제 사용 시 여러 실무적 난점 드러남

MCP와 툴 콜이 실사용에서 점점 ‘지루해지는’ 주요 원인들은 실질적 비효율에 있음

• LLM에 너무 많은 도구(100개 이상 등)를 제공하면 각 요청에 대해 어떤 도구를 사용할지 결정이 어려워짐
• 비슷한 기능의 여러 도구 중, LLM이 틀린 도구를 고르거나 파라미터를 잘못 입력하는 경우 빈번
• 예시: CRM에서 “OpenAI 연락처 알려줘”라고 할 때 get_crm_companies(회사 전체 정보 반환, 36개 회사 JSON 대용량)와 get_crm_company(1개만 반환) 중 선택 애매, 오탈자 등 예외 처리도 복잡
• 파라미터 세분화를 위해 GraphQL처럼 플래그, 옵션, 여러 스키마를 도입하면 복잡도 급증 및 모델이 결국 잘못된 요청을 생성

대량 JSON 응답 및 반복되는 데이터 전달 구조로 인해 토큰과 비용이 과도하게 소모됨

• LLM은 모든 툴 콜의 입력/출력 데이터(예: “wind_speed” 하나만 필요한데 전체 JSON 반환)를 모두 토큰화해서 받아야 함
• 실세계 케이스: 회사 목록 36개 전체 정보 중 1개 이메일만 원할 때, 20,000토큰/50센트/5분씩 소모
• 반복되는 정보(문서 일부, 위치 등)가 대화 내역에 이미 있을 경우에도 반드시 입력 데이터로 중복 전달 필요
• 예: “샌프란시스코 날씨”에 대해 매번 “San Francisco”를 반복해 전달하며 비효율
• 데이터가 클수록, 필요없는 정보까지 불필요하게 LLM 컨텍스트에 포함되어 대기시간, 비용, 정확성 저하

기존 툴 호출 구조는 애플리케이션 컨텍스트를 충분히 활용하지 못하고 있음

• 툴 콜 시 챗 히스토리, LLM 애플리케이션 ‘메모리’, 첨부 파일의 경로/메타데이터 등 현재 컨텍스트를 함께 넘겨주면, 이전과 동일한 인자 재사용, 검색 쿼리 활용 등 다채로운 기능 가능
• 예: 15번 동일 도구를 호출했다면, 히스토리를 기반으로 파라미터 최적화 및 재사용 채택 가능
• 실제 애플리케이션의 데이터/컨텍스트를 MCP/툴 콜에 넘기는 건 프로토콜 추가, 보안 이슈, Modalities 연동(텍스트, 그림, 그래프 등) 등 엔지니어링 난이도가 높음
• 90~00년대 온톨로지, 시맨틱 웹, XML 스키마 등 복잡한 표준화 문제 재현

현재 툴 호출 UI 및 상호작용은 지나치게 단순·비효율적이어서 개선이 필요함

• MCP와 LLM 툴 콜의 현재 UI 옵션: “허용/거부(allow/reject)”만 가능, 파라미터 즉시 편집 불가
• 예: OpenAI 오타, 엉뚱한 회사 검색, 기타 파라미터 실수를 사용자가 즉각 수정하거나 편집 불가능
• 도구 입력을 보내기 전에 인자/파라미터를 손쉽게 편집할 수 있는 UI, 파일 첨부(경로/메타데이터 등) 등 확장 필요
• 출력값(결과)도 LLM에 모두 넘겨주기보다, 사용자가 직관적으로 필요 정보만 남기거나 수정 후 전송 기능도 요구됨

LLM의 강점은 사실 ‘코드를 쓰는 불완전한 엔지니어’임을 인정해야 함

• LLM들은 시, 랩 가사 등 모든 언어를 만들 수 있지만, 특히 코드 생성(함수, API, SQL 쿼리 등)에 정교함을 보임
• Sonnet 4, GPT-4.1 등 최신 LLM은 최신 API, SDK 사용법, 함수 구조 학습 등 업계 변화 반영
• 원하는 도구가 없으면 LLM에 “이런 기능을 갖춘 코드를 만들어줘”라고 하면 파라미터, 반복처리 등 복잡 동작도 쉽게 생성
• Voyager, ‘code elicits better tool actions’ 논문 등에서도 ‘코드로 도구 호출을 작성하라’는 아이디어 입증
• Shell script, 미니 앱, SQL 쿼리 등 생성 → 직접 실행 → 결과를 다시 LLM에 입력하는 과정을 반복하여, 이미 ‘eval’ 형태 고급 인터페이스 경험

‘eval(실행)’ 중심의 단순 MCP로도 모든 요구를 더 잘, 더 확장성 있게 처리할 수 있음

• LLM이 직접 코드를 생성하고 SQL, bash, JS 등으로 실행 결과를 받아 재사용하는 ‘eval MCP’만 있으면 기존 툴/펑션 콜의 한계를 넘어설 수 있음
• 예: “John Smith가 지난달 주문한 건수?”에 대해 SQL eval로 스키마 추론-조인-쿼리 반복, LLM이 직접 SQL 재작성 및 결과 집계 함수 등을 반복 생성
• 툴 콜에서는 파라미터 오류, 포맷 오류, 의도 오해 등으로 쓸데없이 많은 호출과 토큰 소모, 실패 응답 초래
• eval MCP는 코드를 한 번 작성한 뒤, 쿼리, 뷰, 함수로 바로 저장/재사용해 ‘라이브러리’를 구축할 수 있고, 향후 모든 복합 기능에 활용 가능

단일 eval 기반 MCP로 복잡한 웹/데이터/서비스 통합까지 Automation 가능함

• JS sandbox MCP 프로토타입: Go로 제작, SQLite/간이 웹서버 라이브러리만 연결, eval 한 번으로 JS 핸들러/SQL 쿼리 모두 자동 등록
• REST 핸들러, 웹사이트, CSS/HTML 파일, CRUD 기능 등도 LLM이 코드를 직접 생성해 단일 호출로 통합 가능
• 실시간 입력/결과값 편집, REST API 연결 등 기존 MCP 구조로는 불가능한 복잡한 오케스트레이션 가능
• 회사 정보 편집, 신규 회사 추가 등 DB 조작 역시 모두 자동화/반복 가능

LLM이 DSL UI, 인터랙션 등도 모두 코드로 생성해 진정한 ‘마법적 확장성’을 제공함

• 툴 컬에 input/output 편집 UI를 LLM의 도메인 특화 언어(DSL)로 출력하면, 사용자는 슬라이더, 드롭다운, 첨부파일, 메모리노출여부 등까지 시각적으로 직관 조작 가능
• 출력값(결과)도 시각적으로 필터/편집/부분 전송하여, 대기시간, 토큰, 비용 등 최소화, 반복 실행 없이 효율적 결과 획득
• LLM 호스트 서버에서 UI DSL을 그대로 렌더링하면, 사용자 편의성과 완성도 모두 대폭 향상
• 기존 JSON 창만 노출되는 MCP UI 한계를 넘어, 실제 업무 프로세스 전체를 코드/DSL 기반 인터랙션으로 확장

LLM 및 MCP 활용은 ‘코드가 모든 것을 만든다’는 순환적 사고로 혁신적 잠재력을 열어줌

• 코드를 쓰는 코드, 다시 그 코드를 생성하는 코드… 무한 재귀 구조가 LLM-코딩 프레임워크의 진정한 강점
• JS sandbox 등 실제 활용 예시: 라이브러리·함수·API를 즉석에서 만들고, 재사용, 오케스트레이션, 시스템 통합까지 실질적 자동화 가능
• LLM과 개발자 모두 ‘엔지니어’로서 무한한 루프를 생성, 단순한 툴-에이전트 콜 모델에서 벗어나야 함
• LLM의 본질은 “도구 호출” 그 자체가 아니라, “코드로 모든 것을 푼다”는 무한 확장성에 있음
• 기존 MCP, 에이전트 패러다임에 얽매이지 말고, 개발자 스스로 “코드로 문제 해결”하는 접근을 권장하며, LLM의 ‘반짝임’을 최대한 발휘할 것을 제안