하나의 스킬, 모든 에이전트

블로그 · 5분 분량

이제 AI 에이전트를 정확히 하나만 쓰는 사람은 없습니다. 어떤 도구로 코드를 쓰고, 다른 도구로 리뷰하며, 팀의 누군가가 극찬한다는 이유로 세 번째를 시도하기까지는 아마 안 좋은 오후 하루 정도밖에 남지 않았을 것입니다. 그건 괜찮습니다. 건강한 시장이라는 뜻이니까요. 괜찮지 않은 것은, 그중 어느 하나를 위해 공들여 쓴 지침에 이 상황이 무슨 짓을 하는가입니다.

정말 잘 만든 스킬을 하나 썼다고 해봅시다. 코드 리뷰 체크리스트, 장애 대응 런북, 팀이 커밋 메시지를 어떻게 쓰길 원하는지 담은 사내 스타일 가이드 같은 것들이죠. 그 스킬이 어떤 도구의 설정에 붙여넣은 텍스트 덩어리로만 존재한다면, 실질적으로 그것은 이미 that tool's 스킬입니다. 다른 곳에서 쓰려면 다시 옮겨 적어야 하고, 다시 적는다는 건 반드시 갈라진다는 뜻입니다. 한쪽에서 고치고 다른 쪽에서 손보다 보면, 어느새 「그 스킬」은 출발점만 같은 조금씩 다른 세 개의 스킬이 됩니다.

지침은 누가 읽는지 신경 쓸 필요가 없어야 합니다

소프트웨어의 다른 모든 계층에서는 이미 해결된 문제입니다. 잘 작성된 함수는 누가 호출하는지 신경 쓰지 않습니다. 잘 설계된 API는 클라이언트가 브라우저인지 스크립트인지 신경 쓰지 않습니다. AI 에이전트에게 주는 지침은 기능적으로 행동에 대한 API입니다. REST 엔드포인트가 특정 브라우저에 묶이지 않듯, 그 지침이 Claude나 ChatGPT, Codex에 더 강하게 묶일 이유는 없습니다.

지금 이것이 가능해진 이유는 클라이언트들 스스로가 도구와 컨텍스트를 가져오는 공통된 방식으로 수렴했기 때문입니다. 바로 MCP입니다. 이를 지원하는 클라이언트라면 서버에 「어떤 스킬이 있는지」와 「이것을 달라」고 물을 수 있고, 서버는 어떤 에이전트가 묻는지 알 필요도, 신경 쓸 필요도 없습니다. 이식 가능한 스킬은 바로 그 이음매 위에 존재합니다. 한 도구를 위해 만든 플러그인이 아니라, 여러 도구가 이미 말하는 프로토콜 위에서 제공되는 콘텐츠로서요.

스킬이 단일 진실 공급원이 되면 무엇이 달라지는가

스킬을 한곳에 두면 모든 클라이언트가 사본이 아니라 독자가 됩니다. 리뷰 체크리스트의 문제를 한 번 고치면, 다음에 그것을 불러오는 에이전트는 — 어느 것이든 — 그 수정을 받습니다. 붙여넣은 사본 셋 중 어느 것이 최신인지 아무도 기억할 필요가 없습니다. 사본은 하나뿐이니까요.

스킬에서 이식성은 있으면 좋은 요소가 아닙니다. 관리해 나가는 지침과 계속 다시 쓰게 되는 지침을 가르는 차이입니다.

이것이 Skilnu의 전부입니다. 스킬은 레지스트리에 놓이고 MCP를 통해 제공되므로, Claude도 ChatGPT도 Codex도 — 내년에 쓰게 될 무엇이든 — 모두 같은 스킬을 불러옵니다. 그것도 누군가 업데이트를 기억해 낸 버전이 아니라, 오늘의 버전을요.

사용해 보기

논의보다 방법이 궁금하다면, 튜토리얼 Use one skill in Claude, ChatGPT, and Codex이(가) 스킬 하나를 세 가지 모두에 연결하는 과정을 몇 분 만에 안내합니다.