ChatGPT Plugin에서 MCP를 거쳐 Agent Skills까지, 확장 방식의 세 번의 지면 전환

에이전트한테 뭘 더 시키려고 하면 매번 같은 벽에 부딪힌다. 모델은 어쨌든 아는 만큼만 안다. 회사에만 있는 도구를 붙이고 싶거나, 팀의 배포 방식을 알려주고 싶거나, 그냥 내 취향대로 코드 짜게 하고 싶다. 그래서 에이전트 주변에는 확장 지점이 필요해졌다. 그 지점이 세 번 갈아타왔다.

1. ChatGPT Plugin 시대 — 확장은 코드였다

2023년 초의 ChatGPT 플러그인은 정확히 정직했다. 플러그인은 프로그램이었다. 외부에 서버를 세우고 인증을 붙이고 API 스펙을 선언하면, ChatGPT가 그 서버를 호출해서 답에 플러그인 응답을 끼워넣었다.

무엇을 확장했냐면 능력이었다. "이 서버에서 날씨를 알려준다", "이 서버에서 숙소를 예약한다". 모델이 못 하는 걸 서버가 대신 해줬다. 웹 검색도, 코드 실행도,그림 그리기도 다 이 구조였다.

이 시대의 설계는 나중에 보면 지쳐 보이지만 일관돼 있었다. 플러그인 매니페스트라는 JSON 스키마가 있었고, 그 안에 함수 시그니처를 선언했다. 타입이 있었다. 이건 사실 지금도 유효한 설계였다.

근데 명확한 벽이 있었다. 확장하려면 프로그래밍을 해야 했다. 날씨 하나 붙이려고 서버를 세우고 HTTPS 인증서를 발급받고 OAuth 승인 화면을 만들어야 했다. 프로그래밍을 할 줄 모르는 사람이 에이전트 도구를 하나 추가하는 데 이틀은 걸렸다. 그리고 가장 어이없던 점은, 그 서버를 왜 세웠는지가 코드에 이미 다 적혀 있다는 거다. 네가 회사의 결재 절차가 세 단계라는 걸 적어놓은 것과, 그걸 HTTP 엔드포인트로 만든 것의 차이는 크지 않았다.

2. MCP 시대 — 확장 지점은 코드였지만 설치는 쉬워졌다

2024년 말 Anthropic이 Model Context Protocol을 내놓으면서 방향이 꺾였다. 방향만. 확장 지점은 여전히 코드였다. MCP 서버는 결국 프로그램이고, 도구(tool)와 리소스(resource), 프롬프트(prompt)를 그대로 노출한다.

바뀐 건 연결 방식이었다. 플러그인마다 인증 화면을 만들고 스펙을 적던 게, 표준 프로토콜 하나로 끝났다. MCP 클라이언트에 서버 주소 한 줄 넣으면 도구가 appear된다. "플러그인 아키텍처"를 "표준 콘센트"로 바꾼 거다. 이건 진짜 큰 개선이었고, 사실상 표준이 자리 잡았다.

여기서 한 가지 재밌는 일이 벌어진다. MCP 덕분에 확장이 쉬워지자, 사람들이 확장해야 할 것의 정체를 의심하기 시작했다. 모델이 충분히 좋아지면서, 이런 요청이 들어오기 시작한 것이다.

"어제 테스트 실패한 거 원인이 뭐였는지 설명해줘"

에이전트가 서버를 못 갈아타게 하는 게 아니다. 읽었다고 답이 오지 않는 거다. 응답 포맷이 이상해서? 아니다. Fail한 테스트를 읽고 스택 트레이스를 올바르게 해석하고 그 실패가 코드 구조의 어느 지점에서 왔는지 말하는 건, 지식이 없다. 패턴을 몰라서 지능이 부족한 게 아니라, 그 프로젝트에서 일어난 일이 무엇이었는지를 아무도 적어놓지 않았을 뿐이다.

3. Agent Skills 시대 — 확장이 지식이 되었다

2025년 하반기부터 Claude Skills가 나오면서 방향이 두 번째로, 진짜 크게 꺾였다.

ChatGPT Plugin:  확장은 능력(capability)을 늘린다
MCP:             표준으로 능력을 연결한다
Agent Skills:    확장은 지식(knowledge)을 늘린다

스킬은 서버도 아니고 코드도 아니다. 마운드다운 파일 하나다. 헤르메스 에이전트의 스킬 98개를 전수 스캔해봤는데 결과가 명확했다. 전부 순수 마운드다운에 YAML frontmatter가 붙은 형식이고, 실행 파일이 파이썬이나 셸뿐이었다. 더 중요한 건 내부에서 모델을 호출하는 코드가 없다는 거다. 모델을 지정하는 필드 자체가 존재하지 않는다.

frontmatter도 이렇다.

---
name: 데이터-전처리
description: CSV나 엑셀 파일을 읽고 결측치를 정리할 때 사용
version: 1.0.0
platforms: [linux, macos, windows]
license: MIT
prerequisites: [pandas, openpyxl]
---

98개 중 85개까지 metadata가 있었고, license가 84개, platforms가 88개였다. 이게 뭐가 중요하냐면, 이건 완전히 이식 가능한 단위라는 뜻이다. 스킬 파일을 복사해서 다른 에이전트에 넣으면 그대로 동작한다. 21개를 골라 범용성을 점검했을 때 헤르메스 전용은 2개뿐이었다. 나머지 19개는 에이전트 이름이 바뀌어도 그대로 쓴다.

description이 진짜 인터페이스다

스킬 메커니즘에서 가장 흥미로운 부분은 이거다. description 필드가 사실상 호출 트리거다. 여기에 "이럴 때 사용"이 들어가면 에이전트가 찾아서 부르고, 모호하면 스킬이 있어도 호출되지 않는다.

즉 인터페이스가 JSON 스키마에서 자연언자 매칭으로 바뀌었다. 플러그인 매니페스트가 name, parameters, type을 강제했던 반면, 스킬은 문장으로 의도를 설명한다. 그리고 그게 작동하는 이유는 모델이 자연어를 해석하니까다. 2023년에 누가 description: "이럴 때 사용"에 의존하는 플러그인을 상상했을까.

스킬의 위력은 이렇게 드러난다

스킬을 읽으면서 제일 재미있었던 건, 작동 방식이 지시문인 경우가 많다는 거다. 예를 들어 TDD 스킬의 한 줄은 이거다.

If you didn't watch the test fail, you don't know if it tests the right thing.

이건 코드가 아니다. 테스트를 먼저 써서 그 테스트가 실제로 실패하는 걸 지켜보라는 지시다. 하지만 그 지시가 프로그램보다 정확하게 동작한다. 왜냐면 실패하는 테스트를 볼 때까지 코드를 짜지 말라고 못 박는 걸, 인터프리터로는 못 하기 때문이다. 포인터 하나 내려놓는 것과 "아직 테스트를 안 봤으면 그 테스트가 맞는지도 모른다"를 설명하는 건 다른 차원의 말이다.

또 하나. code-reference 스킬의 정체는 이거다.

코드·라이브러리·API 참조 시 추측하지 않고 공식 문서 사이트를 우선 검색한다.

코드도 아니고 스크립트도 아니다. "모르면 추측하지 말고 공식 문서를 찾아라"는 15글짜리 원칙이다. 이게 왜 스킬이 됐는지를 보면 이 시대의 전환이 선명해진다. 이 스킬이 필요한 이유는 모델이 검색 기능이 있고, 문제는 검색을 안 한다는 거였다. 문제를 푼 게 코드가 아니라 지시였다.

4. 세 시대는 뭐가 달랐는가

여기서 눈여겨볼 건 인증 열이다. 플러그인과 MCP는 인증에서 끝없이 부딪힌다. OAuth 흐름, 토큰 관리, 스코프 설계. 반면 스킬은 아무것도 필요 없다. 파일을 폴더에 넣는 게 끝이다. 이 차이가 실제 채택률을 갈랐다. 나는 그게 지면 전환의 진짜 동력이라고 본다. 기술적으로 우월해서가 아니라, 되기 어려워서가 아니라 되기 쉬워서 가는 것이다. MCP가 플러그인을 완전히 대체하지 못한 것도 같은 이유다. 표준은 맞았는데 여전히 서버를 세워야 했으니까.

5. 아직 남은 문제

스킬이 최고라는 결론으로 끝내면 흥미로움이 줄어서 싫은데, 솔직히 단점도 분명하다.

타입이 없다. MCP 도구는 파라미터에 타입이 있어서 잘못된 호출이 에러로 드러난다. 스킬은 자연어라서 "뭐라는 뜻인지" 해석 실수가 생길 수 있다. 아무 스킬도 안 불릴 수도 있다.

겹침이 생긴다. 98개가 있으면 비슷한 설명을 가진 스킬이 둘씩 있다. 내장 스킬 하나는 골라야 하는데, 골라지는 게 모델의 판단이다. 사람이 정해놓는 게 아니라.

실행이 지연된다. 스킬은 판단을 바꾸지만 즉시 실행은 못 한다. 코드를 실행해야 하는 일은 여전히 MCP나 스크립트로 해야 한다. 그래서 헤르메스 안에 스킬과 MCP이 공존한다. 역할이 다르다. 스킬이 "어떻게 할지"를 알려주고, MCP가 "무엇을 할 수 있는지"를 제공하면 된다.

마무리

확장 방식이 세 번 바뀐 걸 보면 공통된 게 있다. 모델이 강해질수록 확장에 필요한 코드가 줄었다. 2023년에 날씨 정보를 넣으려면 서버를 세워야 했고, 2024년에 프로세스 규칙을 가르치려면 MCP 서버를 만들어야 했다. 2025년엔 그것 둘 다 마운드다운 한 장이면 된다.

남는 질문이 하나다. 지식이 코드로 표현되지 않는 게 얼마나 될까. TDD는 참/거짓으로 환원할 수 없는 원칙이라 마운드다운이 적당했다. 프로세스 규칙도 그렇다. 그렇다면 다음에는 텍스트로도 안 되는 무언가가 나올 수 있을까. 스킬은 텍스트로 갈 수 있는 한계까지 간 셈이고, 그 다음은 다른 매질이 될 수 있겠다.

아직은 안 나오는 것 같지만.