LLM 확장의 씁쓸한 교훈

• 최근 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)보다 자연어 기반 확장이 다시 중심으로 돌아올 가능성이 있음

[GN⁺]

Hacker News 의견

• 나는 자연어가 너무 모호해서 프로그래밍 언어로 확장하는 건 비효율적이라 생각함
  수학이 자체 도메인 특화 언어를 가진 이유가 바로 명확성을 확보하기 위함임

  • 예전에 기술 커뮤니케이션 일을 했는데, 자연어도 반복적인 읽기–수정–재검토 루프를 거치면 꽤 정밀하게 다듬을 수 있음
    영어로는 귀찮지만 익숙해지면 모호함을 줄일 수 있음
  • 그래서 점진적으로 명세를 강화하는 progressive hardening이 필요하다고 봄
    관련 개념은 이 문서에 잘 정리되어 있음

• Skills는 ChatGPT Plugins의 꿈을 현실화한 개념이라 생각함
  이제 모델이 충분히 똑똑해져서 실제로 작동할 수 있을 것 같음
  Simon Willison도 이 글에서 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 에이전트를 하나의 중심 허브로 두는 게 꽤 가치 있었음
  관련 구현은 이 블로그에 정리되어 있음

• 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) 를 쓰는 게 더 낫다고 생각함