# LLM 확장의 씁쓸한 교훈 > Clean Markdown view of GeekNews topic #24673. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24673](https://news.hada.io/topic?id=24673) - GeekNews Markdown: [https://news.hada.io/topic/24673.md](https://news.hada.io/topic/24673.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-11-28T08:42:16+09:00 - Updated: 2025-11-28T08:42:16+09:00 - Original source: [sawyerhood.com](https://www.sawyerhood.com/blog/llm-extension) - Points: 23 - Comments: 1 ## Summary 지난 3년간의 **LLM 확장 실험**은 플러그인에서 프로토콜, 그리고 다시 **자연어 중심의 에이전트 구조**로 순환하며 진화해왔습니다. 복잡한 **ChatGPT Plugins**와 **MCP**가 보여준 기술적 가능성은 컸지만, 결국 개발자들이 원하는 건 단순하고 유연한 **“지시 기반 확장성”** 임이 드러났습니다. 최근의 **Agent Skills**는 이 흐름을 집약해, 별도 프로토콜 없이 폴더 단위로 스킬을 정의하고 일반 도구를 활용하는 방향으로 돌아왔습니다. 결국 LLM의 미래는 거대한 플랫폼보다, **컴퓨터와 자연어가 직접 맞닿는 실행 경험**을 얼마나 매끄럽게 설계하느냐에 달려 있는 듯합니다. ## Topic Body - 최근 3년간 **LLM 확장 방식의 진화**는 플러그인, 사용자 지침, 메모리, 프로토콜, 스킬 등 다양한 형태로 발전 - 초기 **ChatGPT Plugins**는 API 호출을 통한 범용 도구 사용을 시도했으나, **모델 한계와 복잡한 UX**로 실패 - 이후 **Custom Instructions**와 **Custom GPTs**가 등장해 단순한 프롬프트 기반 개인화와 공유 가능한 맞춤형 모델 구조 제공 - **Model Context Protocol(MCP)** 과 **Claude Code**는 복잡하지만 강력한 도구 통합을 가능하게 했고, 최근 **Agent Skills**가 이를 단순화한 형태로 부활 - 최종적으로 **일반 목적 도구와 자연어 지시만으로 작업을 수행하는 에이전트 구조**가 LLM 확장의 핵심 방향이 될 것 --- ### LLM 확장의 역사와 변화 - LLM 사용 방식은 단순한 텍스트 입력에서 **코드베이스·브라우저 제어형 에이전트**로 발전 - 사용자 맞춤화(customization)를 어떻게 지원할지가 핵심 과제로 부상 - 단순한 시스템 프롬프트에서 복잡한 클라이언트-서버 프로토콜까지 다양한 접근이 시도됨 ### ChatGPT Plugins (2023년 3월) - OpenAI가 **ChatGPT Plugins**를 발표, OpenAPI 스펙을 통해 LLM이 REST 엔드포인트를 호출하도록 설계 - AGI 수준의 범용 도구 사용을 지향 - 그러나 **GPT-3.5와 초기 GPT-4의 한계**로 인해 대규모 API 스펙 탐색 시 오류와 맥락 손실 발생 - 플러그인 수동 활성화 등 **불편한 UX**도 문제 - 그럼에도 **Code Interpreter(후의 Advanced Data Analysis)** 플러그인은 강력한 샌드박스 실행 환경의 가능성을 보여줌 ### Custom Instructions (2023년 7월) - 플러그인의 복잡성을 줄인 **간단한 사용자 정의 프롬프트 기능** - 모든 대화에 자동으로 추가되어 반복적인 맥락 설정 문제 해결 - 이후 `.cursorrules`, `CLAUDE.md` 등 **개발 환경 내 규칙 파일의 전신** 역할 수행 ### Custom GPTs (2023년 11월) - OpenAI가 **Custom GPTs**를 통해 프롬프트 엔지니어링을 제품화 - 페르소나, 파일, 액션을 묶어 **공유 가능한 맞춤형 GPT 링크** 생성 - 플러그인의 개방형 접근에서 **단일 목적 앱 형태로 후퇴** ### Memory in ChatGPT (2024년 2월) - **자동 개인화 기능**으로 전환된 첫 사례 - 대화 중 언급된 정보를 기억하고 이후 맥락에 자동 반영 - 사용자가 직접 설정하지 않아도 장기 상태를 유지하는 **지속적 에이전트 구조**의 시작 ### Cursor Rules (2024년 4월) - **Cursor IDE**가 `.cursorrules` 파일을 통해 **저장소 단위의 지침 관리**를 도입 - 예: “탭 사용”, “세미콜론 금지”, “TypeScript 사용” 등 - 이후 `.cursor/rules` 폴더 구조로 확장되어 **파일별·디렉터리별 규칙 적용** 가능 - LLM이 **언제 규칙을 적용할지 스스로 판단**하는 기능도 추가됨 ### Model Context Protocol (MCP, 2024년 11월) - **Anthropic**이 도입한 MCP는 모델이 **실제 도구를 안정적으로 사용하는 구조** 제공 - 클라이언트-서버 연결을 유지하며 도구 정의, 리소스, 프롬프트를 교환 - 단순한 컨텍스트 추가가 아닌 **실제 기능 부여(capabilities)** 제공 - 예: 리포지토리 읽기, DB 쿼리, Vercel 배포 - 복잡성과 설정 부담이 크지만, **ChatGPT Apps(2025년 10월 발표)** 의 기반 계층으로 사용됨 ### Claude Code와 확장 메커니즘 (2025년 2월) - **Claude Code**는 다양한 확장 방식을 통합한 에이전트 - `CLAUDE.md`로 저장소 지침 관리 - **MCP**로 도구 통합 - **Slash Commands**, **Hooks**, **Sub-agents**, **Output Styles(폐기 예정)** 등 지원 - 일부 기능은 유지 여부가 불확실하지만, **에이전트 확장의 실험적 통합 모델**로 평가됨 ### Agent Skills (2025년 10월) - **ChatGPT Plugins의 재탄생 형태**로, 복잡한 프로토콜 없이 **폴더 기반 스킬 구조** 사용 - `skills/` 디렉터리 내 `SKILL.md`와 스크립트, 예제 파일로 구성 - 필요 시에만 전체 내용을 읽어 **맥락 창 과부하(context bloat)** 문제 해결 - 예시: Playwright 기반 웹앱 테스트 스킬 - `SKILL.md`에 메타데이터와 사용 지침 포함 - 스크립트는 직접 실행되며, LLM이 코드 내용을 맥락에 불필요하게 로드하지 않음 - **일반 목적 컴퓨터 접근 권한**을 전제로 하며, **특수 도구보다 범용 도구를 신뢰하는 접근**이 핵심 ### 미래 전망 - **Agent Skills**는 초기 플러그인의 이상을 현실화 - 모델이 충분히 똑똑해져 **일반 도구와 지시만으로 작업 수행 가능** - 에이전트는 단순한 LLM 루프가 아니라 **컴퓨터와 결합된 실행 주체**로 재정의 - 예: Claude Code, Zo Computer 등은 LLM과 컴퓨터를 통합한 형태 - 2026년 이후 LLM 애플리케이션은 **컴퓨터 내장형 에이전트 구조**로 확산 예상 - 결론적으로, **복잡한 프로토콜(MCP)보다 자연어 기반 확장**이 다시 중심으로 돌아올 가능성이 있음 ## Comments ### Comment 46902 - Author: neo - Created: 2025-11-28T08:42:16+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46037343) - 나는 **자연어**가 너무 모호해서 프로그래밍 언어로 확장하는 건 비효율적이라 생각함 수학이 자체 **도메인 특화 언어**를 가진 이유가 바로 명확성을 확보하기 위함임 - 예전에 기술 커뮤니케이션 일을 했는데, 자연어도 반복적인 **읽기–수정–재검토 루프**를 거치면 꽤 정밀하게 다듬을 수 있음 영어로는 귀찮지만 익숙해지면 모호함을 줄일 수 있음 - 그래서 점진적으로 명세를 강화하는 **progressive hardening**이 필요하다고 봄 관련 개념은 [이 문서](https://github.com/zby/llm-do/blob/main/docs/concept_spec.md)에 잘 정리되어 있음 - **Skills**는 ChatGPT Plugins의 꿈을 현실화한 개념이라 생각함 이제 모델이 충분히 똑똑해져서 실제로 작동할 수 있을 것 같음 Simon Willison도 [이 글](https://simonwillison.net/2025/Oct/16/claude-skills/)에서 Skills가 MCP보다 더 큰 변화라고 주장했지만, 아직은 MCP 관성 때문에 관심이 덜한 듯함 - Skills가 덜 흥미롭게 느껴지는 이유는 사실상 **선택적으로 로드되는 문서화**에 가깝기 때문임 하지만 MCP가 요구하는 복잡한 스캐폴딩을 제거한다는 점에서는 훨씬 큰 의미가 있음 예를 들어, Fathom 계정의 녹취록을 처리할 때 CLI 스크립트를 만들고 SKILL.md만 작성하면 됐음 클라이언트 API 테스트도 같은 방식으로 해결했음 다만 이런 접근은 덜 화려하고, 대규모 툴링을 만들 여지가 적어서 덜 주목받는 듯함 - 요즘 **LLM 피로감**이 커서 사람들이 Skills에 덜 흥분하는 것 같음 게다가 Skills는 임의 코드 실행이 가능한 에이전트를 전제로 하기에 진입 장벽이 높음 - Skills 디렉터리가 뭐가 특별한지 아직 모르겠음 예전부터 Claude Code에게 “X를 읽고 Y를 해줘”라고 했는데, 그게 Skills와 뭐가 다른지 궁금함 - Claude Skills의 **샌드박스 실행**은 너무 비효율적임 I/O와 print 문에 의존해 작업을 추적해야 해서 답답함 - Skills는 MCP의 **엔드유저 버전** 정도로 보임 MCP는 시스템 구축용이고, Skills는 Claude 전용이라 **락인**이 심함 스킬 간 참조나 조합이 불가능한 것도 큰 제약임 결국 확장성, 재사용성, 원격 사용 등 문제를 풀다 보면 다시 MCP로 돌아오게 될 것 같음 다만 Skills가 MCP의 다른 뷰로 자리 잡는다면, 나중엔 **Skill→MCP 변환기** 같은 게 나올 수도 있을 것 같음 - 모델이 개선됐다는 게 **Bitter Lesson**과 무슨 관련이 있는지 모르겠음 여전히 인간의 전문성을 주입해 모델의 한계를 보완하는 구조임 진짜 Bitter Lesson이라면 인간 개입 없이 **계산 자원만 늘려서** 더 나은 결과를 내는 경우일 것임 - 나도 그게 글의 주제일 줄 알고 클릭했음 - **Custom GPTs**는 오래된 개념이지만, 최근에 실용적인 용도를 찾았음 아내의 회의 기록과 할 일 관리용으로 Notion API를 연결한 Custom GPT를 만들었는데, 몇 시간 만에 꽤 유용하게 작동했음 Reminders 앱과 연동하려 했지만 API 제약과 UI 권한 문제로 결국 **MCP 서버**를 직접 만들어야 했음 오래된 MacBook Pro에 Amphetamine을 켜고 Tailnet과 Cloudflare 터널로 연결해 ChatGPT에서 접근 가능하게 했음 복잡하지만, **AI 에이전트를 하나의 중심 허브로** 두는 게 꽤 가치 있었음 관련 구현은 [이 블로그](https://wiki.roshangeorge.dev/w/Blog/2025-10-17/Custom_GPTs)에 정리되어 있음 - ChatGPT 5.1도 여전히 **존재하지 않는 API를 환각**하지만, 그래도 점점 나아지고 있음 인간이 정보 처리 능력을 개선할 때마다 세상이 바뀌었듯, LLM이 정답 확률만 높여도 세상은 또 변할 것임 - “MCP를 공매도하고 싶다”는 말에 공감함 MCP는 다루기 어렵지만, 세상에는 **안전한 인터페이스**가 필요한 작업이 많음 초기 설계가 복잡했던 이유는 스트리밍 토큰 처리의 현실을 그대로 노출했기 때문임 복잡하지만 여전히 **작동 가능한 단순 시스템의 경계선**에 있다고 봄 완전히 대체될 순 없고, 모델이 에이전트 환경을 제대로 다루려면 MCP 같은 구조는 당분간 필요할 것임 - MCP는 결국 또 하나의 **자기 기술형 API 포맷**임 요즘 모델은 단순한 API 설명만으로도 충분히 상호작용 가능함 이미 API가 있다면 굳이 MCP 서버를 만들 이유가 줄어듦 - MCP가 어렵다는 말이 이해 안 됨 구현은 단순한 **JSON-RPC + API** 수준임 Python FastMCP의 hello-world 예제는 Flask 버전과 거의 동일함 - MCP는 시기상조였던 것 같음 Skills는 그 반작용으로 등장했고, 앞으로는 **LLM 공간과 코드 공간이 자가 조립되는 구조**로 발전할 듯함 - MCP는 또 하나의 **미들웨어 스토리**일 뿐이고, 이런 건 늘 실패해왔음 - Skills.md도 결국 MCP처럼 **컨텍스트 부풀림** 문제를 겪을 것 같음 차라리 설명 없이 스크립트만 두고, LLM이 폴더 내에서 필요한 걸 검색하도록 학습시키면 좋겠음 - 이건 해결 가능한 **엔지니어링 문제**라고 생각함 예를 들어, 스킬을 읽고 선택하는 **경량 서브에이전트**를 두면 됨 - 이번 달 발표된 **ChatGPT Apps**는 3년 전의 ChatGPT Plugin과 거의 동일하게 느껴짐 차이는 플러그인 호출 방식뿐임 — 예전엔 드롭다운에서 선택했지만, 이제는 프롬프트에 이름만 넣으면 됨 사용자 입장에서는 큰 차이가 없어 보임 - 프롬프트를 **확률적 프로그램**으로 보고, 이를 호출하는 전용 셸이 필요하다고 생각함 Claude Code나 Codex 같은 코딩 에이전트가 그 예시임 이런 기능을 IDE에서 분리해 **llm-do** 같은 독립 셸로 발전시키는 걸 연구 중임 - LLM 확장의 진짜 핵심은 **셸 통합**임 셸과 연결된 LLM은 사실상 뭐든 할 수 있음 - 숟가락으로도 수영장을 팔 수는 있지만, 나는 **백호(backhoe)** 를 쓰는 게 더 낫다고 생각함