Agent Skills 생태계 지도

어떤 사람은 Claude에서 Skill을 이야기하고, 어떤 사람은 ChatGPT에서 GPT나 Actions를 이야기하고, 또 어떤 사람은 Cursor나 Codex에서 Agent Skills를 말한다. 처음 보면 전부 비슷해 보인다. 하지만 조금만 가까이 가서 보면, 이들은 같은 층위의 개념이 아니다. 어떤 것은 업무 절차를 담는 포맷이고, 어떤 것은 외부 시스템과 연결하는 통로이며, 어떤 것은 특정 제품 안에서 배포되는 사용 경험이다.

이 장의 목표는 단순 비교가 아니다. 더 중요한 것은 Skill을 어느 한 회사의 기능 이름으로 보지 않고, 여러 에이전트 환경을 가로지르는 공통 실행 포맷으로 보는 눈을 갖는 것이다. 그래야 제품이 바뀌어도 설계 원칙이 남고, 팀이 도구를 바꿔도 자산이 사라지지 않는다.

이제는 모델 비교보다 실행 포맷 비교가 중요하다

AI 도구를 고를 때 많은 사람은 먼저 모델 성능부터 본다. 물론 중요하다. 하지만 실무 자동화에서는 모델 점수만큼이나 중요한 것이 있다. 바로 그 도구가 업무 절차를 어디에 담게 만드는가다.

같은 보고서 작성 업무라도 어떤 환경에서는 긴 프롬프트로 매번 붙여 넣어야 하고, 어떤 환경에서는 프로젝트 지침에 묶어 둘 수 있고, 어떤 환경에서는 아예 Skill 패키지로 설치해 재사용할 수 있다. 겉으로는 비슷한 결과가 나와도, 운영성은 완전히 달라진다.

그래서 생태계를 볼 때는 이런 질문을 던져야 한다. 이 도구는 업무 지침을 어디에 저장하는가. 스크립트나 참고자료를 함께 묶을 수 있는가. 외부 시스템 연결은 어떤 방식으로 하는가. 그리고 그 자산을 다른 도구로 옮길 수 있는가.

이 질문으로 보면 전체 지도가 조금 선명해진다. Skill은 절차 패키지이고, Actions나 MCP는 실행 통로이며, Custom GPT나 프로젝트 설정은 그것을 특정 제품 경험 안에 담아내는 컨테이너다.

Claude 생태계는 Skill의 원형을 가장 분명하게 보여 준다

여러 환경 가운데 Claude 진영은 Skill이라는 개념을 가장 직관적으로 보여 준다. 특히 Claude Code 계열에서는 Skill을 폴더 기반 패키지로 다루는 감각이 강하다. 지침은 문서로, 긴 자료는 리소스로, 반복 계산은 스크립트로 분리해 묶는 방식이 자연스럽다. 이런 구조는 나중에 다른 도구로 옮길 때도 이해하기 쉽다.¹²

중요한 것은 Claude에서 Skill이 단순한 "추가 프롬프트"가 아니라는 점이다. 공식 Codex 문서와 Cursor 문서가 공통으로 설명하듯, Agent Skill은 지침, 리소스, 선택적 스크립트를 함께 담는 재사용 패키지다. 즉, 좋은 Skill은 말솜씨를 저장하는 파일이 아니라 작업 흐름을 설치하는 번들에 가깝다.¹²

Claude 쪽이 특히 강하게 느껴지는 이유는 로컬 작업과의 결합 때문이다. 예를 들어 로컬 저장소 안에 코딩 규칙, 테스트 절차, 문서 템플릿, 검증 스크립트를 함께 두면 에이전트는 코드와 업무 규칙을 같은 작업 공간에서 다룰 수 있다. 개발자 입장에서는 이 감각이 매우 중요하다. "AI에게 부탁한다"기보다 "프로젝트에 작업 규칙을 설치한다"는 느낌이 생기기 때문이다.

또한 Anthropic을 포함한 여러 팀이 실제로 배포하는 Skill들을 보면, 문서 작성, 프론트엔드 디자인, 웹앱 테스트, 브랜드 가이드 적용, MCP 서버 작성 같은 실무형 패턴이 이미 쌓여 있다. 이는 Skill이 실험적 아이디어에 그치지 않고, 실제 작업 단위로 축적되고 있음을 보여 준다.³

이 점에서 Claude 생태계는 Skill의 본질을 가르쳐 준다. Skill은 모델을 더 똑똑하게 만드는 비밀 주문이 아니라, 일하는 방식을 파일 단위로 고정하는 장치다.

ChatGPT 생태계에서는 같은 문제를 다른 이름으로 푼다

반면 OpenAI 생태계는 같은 문제를 조금 다른 레이어로 풀어 왔다. ChatGPT 쪽에서 오래된 용어인 플러그인은 이제 중심이 아니다. 플러그인 시대는 끝났고, 그 자리를 Custom GPT와 GPT Actions가 대신했다.⁴

이 변화는 꽤 중요하다. 플러그인 시절에는 사용자가 도구를 따로 고르고 붙이는 느낌이 강했다면, 지금은 하나의 GPT 안에 지침, 지식 파일, 액션을 함께 묶어 목적형 에이전트를 만드는 방향으로 바뀌었다. 즉, OpenAI는 Skill이라는 이름을 전면에 내세우기보다, GPT라는 제품 단위 안에 비슷한 역할을 흡수해 온 셈이다.⁴

그래서 ChatGPT 환경을 볼 때는 이렇게 이해하면 편하다. ChatGPT의 기본 대화는 범용 인터페이스이고, Custom GPT는 목적형 작업 공간이며, GPT Actions는 외부 API를 부르는 연결부다. 여기서 절차 자체를 가장 잘 담는 것은 사실 Actions가 아니라 GPT의 지침과 지식 구성이다. Action은 일을 해내는 손이고, 절차는 여전히 따로 설계해야 한다.

이 구조에는 장점도 있다. 사용자 입장에서는 "여행 플래너 GPT", "사내 보고서 GPT", "지원서 평가 GPT"처럼 완성된 제품처럼 느껴진다. 배포도 쉽고, 비개발자도 접근하기 좋다. 반면 단점도 분명하다. 이 방식은 OpenAI 생태계 안에서는 편하지만, 다른 에이전트로 가져갈 때 그대로 이식되기 어렵다. 같은 업무 설계를 Claude나 Cursor에서 쓰려면 다시 구조를 풀어 옮겨야 할 수 있다.⁵

즉, ChatGPT 쪽은 사용 경험 중심이고, Claude 쪽은 패키지 구조 중심이라고 보면 감이 잡힌다. 어느 쪽이 더 낫다기보다, 어디에 자산을 남기고 싶은지가 다르다.

Codex는 OpenAI 안에서 Skill 개념이 가장 직접적으로 드러나는 지점이다

여기서 흥미로운 전환점이 하나 있다. 같은 OpenAI 계열이라도 Codex는 ChatGPT보다 Skill 개념을 더 직접적으로 드러낸다. OpenAI 공식 문서도 Agent Skills를 "작업별 능력을 확장하는 방식"으로 설명하며, 지침, 리소스, 선택적 스크립트를 묶어 신뢰할 수 있는 워크플로를 따르게 한다고 안내한다.¹

이 말은 꽤 상징적이다. OpenAI가 범용 대화 제품인 ChatGPT에서는 GPT와 Actions라는 제품적 추상화를 앞세우지만, 개발 에이전트인 Codex에서는 다시 Skill 패키지라는 더 낮은 수준의 실행 단위를 채택하고 있다는 뜻이기 때문이다.

실무적으로는 이 차이를 이렇게 볼 수 있다. ChatGPT는 완성된 도우미를 배포하는 데 강하고, Codex는 개발 작업 규칙을 설치하는 데 강하다. 예를 들어 사내 코딩 스타일, 테스트 순서, 마이그레이션 절차, PR 요약 포맷처럼 프로젝트 밀착형 규칙은 Codex 스타일의 Skill이 훨씬 잘 맞는다.

그래서 OpenAI를 쓸 때도 질문을 둘로 나눠야 한다. "나는 하나의 목적형 GPT를 배포하려는가?" 아니면 "개발 에이전트가 프로젝트 안에서 반복적으로 따라야 할 절차를 설치하려는가?" 전자라면 ChatGPT와 GPTs가 자연스럽고, 후자라면 Codex식 Skill 사고방식이 더 맞는다.

Custom GPT와 GPT Actions는 무엇을 담당하고, 무엇을 담당하지 않는가

이쯤에서 역할을 더 또렷하게 나눠 보자. 많은 팀이 여기서 개념을 섞는다. 그러면 설계가 복잡해지고, 나중에 유지보수도 어려워진다.

Custom GPT는 대화 경험을 패키징한다. 기본 지침, 대화 톤, 지식 파일, 사용할 Action 세트를 하나의 사용자 경험으로 묶는다. 쉽게 말해 "이 AI를 어떤 성격과 기본 습관을 가진 도우미로 만들 것인가"를 정하는 컨테이너다.

GPT Actions는 외부 API 호출을 담당한다. OpenAPI 스펙으로 정의된 HTTP 엔드포인트를 모델이 호출하게 만들며, 요청은 OpenAI 쪽 인프라를 통해 실행된다. 이 방식은 공개 API나 ChatGPT 내부 앱 경험을 만드는 데 적합하지만, 기본적으로 OpenAI 생태계에 묶인다.⁵⁶

여기서 중요한 경계는 이것이다. Custom GPT는 제품 경험이고, Actions는 API 실행 경로다. 둘 다 "어떻게 일할지"를 충분히 설명해 주지는 않는다. 예를 들어 고객 문의를 분류하고, 정책을 조회하고, 민감 표현을 걸러 내고, 사람이 승인해야 할 경우를 판단하는 절차는 여전히 따로 설계해야 한다. 그 절차를 재사용 가능한 문서와 리소스로 남기는 방식이 바로 Skill 사고방식이다.

그래서 실전에서는 이런 문장이 매우 유용하다. 절차는 Skill에 두고, 실행은 Action에 맡긴다. 이 문장만 기억해도 설계가 훨씬 덜 꼬인다.

MCP는 Skill의 경쟁자가 아니라 바깥세계를 연결하는 표준 포트다

MCP를 처음 접하면 많은 사람이 Skill과 경쟁 관계로 본다. 둘 다 에이전트를 확장하는 것처럼 보이기 때문이다. 하지만 실제로는 담당 레이어가 다르다.

MCP는 외부 도구와 데이터 소스를 연결하는 공개 프로토콜이다. 도구 호출만이 아니라 리소스 읽기와 프롬프트 제공까지 표준화하며, JSON-RPC 기반의 클라이언트-서버 구조로 동작한다. 핵심은 특정 모델 회사에 종속되지 않는 연결 표준이라는 점이다.⁶⁷

반대로 Skill은 연결 표준이 아니다. Skill은 업무 절차와 판단 기준을 담는 실행 지식 패키지다. 쉽게 말해 Skill이 "어떻게 할지"를 가르친다면, MCP는 "무엇에 연결할지"를 제공한다.⁷

이 차이를 요리로 비유하면 이해가 쉽다. Skill은 레시피다. MCP는 오븐, 냉장고, 칼, 계량기 같은 주방 설비다. 레시피만 있으면 실제 요리를 못 하고, 설비만 있으면 무엇을 만들지 모른다. 둘은 경쟁이 아니라 조합 대상이다.

실제로 좋은 에이전트는 둘을 함께 쓴다. 예를 들어 코드 리뷰 Skill이 있다고 해 보자. 이 Skill은 변경 파일 확인 순서, 보안 체크 항목, 성능 검토 기준, 테스트 누락 탐지 규칙, 리뷰 코멘트 톤을 가르친다. 하지만 실제 Pull Request를 읽고, CI 결과를 가져오고, 이슈 트래커 상태를 조회하는 일은 MCP 서버가 맡는 편이 자연스럽다.

이때 경계선을 분명히 그어야 한다. API나 데이터베이스에 접속하는 법을 Skill 안에 장황하게 설명하기 시작하면 절차와 연결이 뒤섞인다. 반대로 MCP만 붙여 두고 절차를 설계하지 않으면, 에이전트는 도구는 많지만 무엇을 먼저 해야 할지 모르는 상태가 된다.

Skill + MCP 조합이 강한 이유는 이식성과 통제가 동시에 생기기 때문이다

조직 관점에서 보면 Skill과 MCP를 분리해 설계하는 방식은 매우 실용적이다. 먼저 Skill은 업무 지식을 문서와 스크립트로 남기기 때문에, 도구가 바뀌어도 비교적 옮기기 쉽다. 반면 MCP는 시스템 연결을 표준화하기 때문에, 같은 GitHub나 Notion, Slack 연결을 여러 클라이언트에서 재활용할 수 있다.⁶

이 둘을 분리하면 운영상의 장점도 생긴다. 업무 규칙이 바뀌면 Skill을 수정하면 되고, 시스템 인증이나 연결 대상이 바뀌면 MCP 쪽을 수정하면 된다. 절차 변경과 인프라 변경이 서로 다른 속도로 움직일 수 있다는 뜻이다.

예를 들어 사내 보고서 작성 프로세스를 생각해 보자. 보고서 구조, 금지 표현, 요약 기준, 승인 필요 조건은 Skill에 둔다. ERP 수치 조회, 캘린더 일정 확인, 문서 저장은 MCP에 둔다. 그러면 내년 ERP를 바꿔도 보고서 작성 원칙은 그대로 남고, 반대로 임원 보고 포맷이 바뀌어도 시스템 연결은 그대로 둘 수 있다.

이 구조가 바로 생태계 지도를 알아야 하는 이유다. 기술을 섞어 쓰는 것이 목적이 아니라, 바뀌기 쉬운 것과 바뀌면 안 되는 것을 분리하는 것이 목적이다.

Cursor와 개발 에이전트는 Skill을 프로젝트 규칙 설치 장치로 쓴다

Cursor는 Agent Skills를 재사용 가능한 지식과 스크립트를 패키징하는 개방형 표준으로 설명한다.² 이 표현이 중요한 이유는, Cursor가 Skill을 단순한 편의 기능이 아니라 개발 워크플로에 이식 가능한 구성 요소로 본다는 뜻이기 때문이다.

개발 에이전트에서 Skill이 가장 빛나는 지점은 프로젝트 고유 규칙을 집어넣을 때다. 예를 들어 React와 Tailwind를 쓰는 팀이라면 컴포넌트 구조, 상태 관리 규칙, 접근성 체크리스트, 테스트 작성 순서, PR 설명 템플릿을 Skill로 묶을 수 있다. 그러면 에이전트는 단순히 코드를 생성하는 것이 아니라, 그 팀의 방식대로 코드를 만든다.

이런 패턴은 Cursor만의 일이 아니다. 이미 많은 Skill 저장소와 디렉터리들이 Claude Code, Codex, Cursor, GitHub Copilot 계열 도구에서 함께 쓰일 수 있는 패키지를 모으고 있다. 즉, 개발 에이전트 세계에서는 Skill이 특정 제품의 비밀 기능이 아니라, 여러 도구를 가로지르는 재사용 자산으로 자리를 잡아 가는 중이다.³

여기서 자주 나타나는 패턴은 세 가지다.

• 프로젝트 컨벤션 Skill: 파일 구조, 네이밍, 린트 규칙, 테스트 요구사항을 묶는다.

• 작업 유형 Skill: 버그 재현, 코드 리뷰, 마이그레이션, 릴리스 노트 작성 같은 절차를 묶는다.

• 도메인 Skill: Stripe 연동, Cloudflare Workers 배포, 특정 디자인 시스템 적용처럼 기술 스택 지식을 묶는다.³

이 세 가지를 보면 개발 에이전트에서 Skill이 왜 강력한지 알 수 있다. 코딩 에이전트의 진짜 문제는 코드를 못 쓰는 것이 아니라, 우리 팀 방식으로는 잘 못 쓴다는 데 있다. Skill은 바로 그 간극을 메운다.

Copilot류 도구를 볼 때도 질문은 같다

Copilot 계열 도구는 제품 경험이 조금씩 다르더라도, 실무자가 던져야 할 질문은 같다. 이 도구는 프로젝트별 규칙을 지속적으로 기억시키는가. 지침과 예시, 스크립트를 함께 묶을 수 있는가. 외부 시스템 연결은 자체 방식인가, MCP 같은 표준을 탈 수 있는가. 그리고 그 자산을 다른 환경으로 옮길 수 있는가.

만약 답이 전부 "제품 내부 설정에만 묶인다"라면, 단기 생산성은 높을 수 있어도 장기 자산화는 약할 수 있다. 반대로 Skill 패키지와 연결 표준을 분리해 가져갈 수 있다면, 도구를 바꿔도 조직의 실행 지식은 남는다.

결국 Copilot류 도구도 같은 기준으로 읽어야 한다. 얼마나 똑똑한가보다, 얼마나 재사용 가능한 절차를 설치할 수 있는가가 중요하다.

한눈에 보는 생태계 지도

아래 표는 지금까지의 차이를 실무 기준으로 압축한 것이다.

표를 보면 결론은 단순하다. Skill은 일하는 법을 담고, MCP와 Actions는 실행 통로를 담고, GPT나 프로젝트 설정은 사용자 경험을 담는다. 설계가 좋아지려면 이 셋을 섞지 말고 나눠 봐야 한다.

그래서 무엇을 선택해야 하는가

도구 선택의 기준은 유행이 아니라 업무 성격이다. 만약 당신이 반복 업무를 팀 자산으로 남기고 싶다면, Skill 패키지 관점이 가장 먼저 와야 한다. 반대로 고객이나 사내 구성원이 바로 써야 하는 완성형 도우미를 배포하고 싶다면, Custom GPT 같은 제품형 컨테이너가 유리하다. 그리고 여러 시스템에 연결해야 한다면, 그 연결은 MCP나 Action 같은 실행 레이어로 분리하는 편이 좋다.

실무에서는 보통 이렇게 정리하면 된다.

• 업무 절차를 표준화하고 재사용하고 싶다 → Skill 중심으로 설계한다.

• ChatGPT 안에서 바로 쓰는 목적형 도우미를 만들고 싶다 → Custom GPT를 중심에 둔다.

• 외부 API를 단순하게 붙이고 싶다 → GPT Actions를 고려한다.

• 여러 클라이언트에서 같은 연결을 재사용하고 싶다 → MCP를 우선 검토한다.

• 개발 팀 규칙을 저장소 수준에서 강하게 적용하고 싶다 → Codex, Cursor, Claude Code 계열 Skill이 잘 맞는다.

중요한 것은 하나만 고집하지 않는 것이다. 실제 현장에서는 대개 Skill 하나, 연결 방식 하나, 배포 컨테이너 하나가 함께 움직인다. 예를 들어 절차는 Skill, 데이터 연결은 MCP, 최종 사용자 경험은 Custom GPT로 조합할 수도 있다.

Skill을 제품 기능이 아니라 공통 실행 포맷으로 보라

이 장의 핵심을 마지막으로 다시 붙잡아 보자. Agent Skills 생태계를 이해한다는 것은 Claude와 ChatGPT 중 누가 더 낫다는 결론을 내리는 일이 아니다. 더 중요한 것은, 각 도구가 같은 문제를 어느 레이어에서 푸는지 구분하는 일이다.

Claude는 Skill의 원형을 또렷하게 보여 준다. ChatGPT는 GPT와 Actions로 목적형 경험을 만든다. Codex와 Cursor 같은 개발 에이전트는 Skill을 프로젝트 규칙 설치 장치로 쓴다. MCP는 이 모든 것 바깥에서 시스템 연결을 표준화한다.

이 지도를 머릿속에 넣고 나면, 더 이상 특정 제품의 기능 이름에 끌려다니지 않게 된다. 대신 이런 질문을 하게 된다. 이 업무의 절차는 어디에 둘 것인가. 외부 연결은 어떤 표준으로 뺄 것인가. 이 자산은 내년에도 다른 도구에서 살아남을 수 있는가.

바로 그 질문을 하기 시작할 때, Skill은 유행어가 아니라 설계 언어가 된다. 그리고 그 순간부터 우리는 AI에게 일을 말로 시키는 사람을 넘어, 일을 반복 가능한 능력으로 설치하는 사람에 가까워진다.

참고

¹Agent Skills - Codex | OpenAI Developers

²Agent Skills | Cursor Docs

⁴ChatGPT Plugins vs MCP: What Changed and Why It Matters

⁵GPT Actions vs MCP: A Technical Comparison

⁶GPT Actions vs MCP: Which Integration Approach to Use?

⁷MCP vs Agent Skills: Why They're Different, Not Competing