아무도 해결하지 못한 문제: AI 에이전트는 자신이 아는 것을 공유할 수 없다

모든 AI 에이전트 팀은 동일한 문제를 처음부터 다시 해결하고 있습니다. 한 회사의 개발자는 특정 컴플라이언스 (compliance) 워크플로우를 처리하도록 에이전트를 훈련하는 데 몇 주를 소비합니다. 다른 회사의 개발자도 독립적으로 동일한 작업을 수행하며 거의 동일한 결과를 만들어냅니다. 어느 팀의 작업도 상대 팀에게 도움이 되지 않습니다. 이것이 현재 AI 에이전트 환경의 결정적인 비효율성입니다.

핵심 문제는 구조적입니다. 에이전트 역량(Agent capabilities) — 에이전트를 진정으로 유용하게 만드는 전문 지식, 도메인 전문성, 그리고 작업 특화 워크플로우 — 은 개별 시스템 내부에 존재하며, 이를 패키징하거나 전달할 표준화된 방법이 없습니다. 에이전트 지식 공유를 위한 공통 형식도 없고, 에이전트 지침 (instructions)을 해당 지침이 의존하는 스크립트, 참조 자료, 템플릿과 함께 묶을 수 있는 보편적인 구조도 없습니다. 한 팀이 법률 문서 검토나 API 통합 테스트를 위한 유능한 에이전트를 구축하면, 그 전문성은 그들의 독점적인 스택 (proprietary stack) 내부에서 사라져 버립니다.

이러한 파편화는 대규모의 중복 작업을 발생시킵니다. 업계 전반에 걸쳐, 이미 다른 누군가에 의해 어딘가에서 해결된 문제에 엔지니어링 시간이 낭비되고 있으며, 그 해결책을 배포할 메커니즘도 없습니다. 한 팀이 다듬는 데 몇 달이 걸린 에이전트 기술과 워크플로우는 상당한 맞춤형 엔지니어링 없이는 다른 팀의 에이전트 런타임 (runtime)에 바로 투입될 수 없습니다.

시기적인 문제도 상황을 악화시킵니다. 에이전트 도입 속도가 툴링 (tooling) 생태계가 성숙하는 속도보다 빠르게 가속화되고 있습니다. 조직들은 고객 지원, 소프트웨어 개발, 데이터 분석, 운영 전반에 걸쳐 AI 에이전트를 동시에 배포하고 있습니다. 표준화된 에이전트 역량 형식 — 에이전트 전문성을 위한 휴대 가능하고 재사용 가능한 구조 — 이 없다는 것은 모든 새로운 배포가 제로(zero)에서 다시 시작됨을 의미합니다. 에이전트 구현의 품질로 경쟁해야 할 팀들이, 대신 누가 기초 기술을 가장 빨리 재구축할 수 있는지를 두고 경쟁하고 있습니다.

AI 에이전트 생태계는 통합이 절실히 필요한 바로 이 시점에 파편화되고 있습니다. 에이전트 지식을 패키징하고 배포하기 위한 공유된 사양 (specification)이 없다면, 에이전트가 이론적으로 할 수 있는 일과 개별 팀이 현실적으로 구축할 수 있는 일 사이의 격차는 계속해서 벌어질 것입니다.

Agent Skills의 실체 — 그리고 설계가 기만적일 정도로 단순한 이유

Agent Skills 형식 전체는 단 하나의 필수 파일인 SKILL.md에 의존합니다. 폴더에 해당 파일을 넣고, 이름과 설명을 부여한 뒤, 몇 가지 지침 (instructions)을 추가하기만 하면 작동하는 에이전트 스킬 (agent skill)이 완성됩니다. 이것이 완전한 최소 기능 단위 (minimum viable unit)이며, 이는 제작 장벽을 거의 제로에 가깝게 유지하기 위한 의도적인 설계 선택입니다.

폴더 구조는 서류상으로 보면 당황스러울 정도로 단순해 보입니다. SKILL.md 파일은 루트 (root)에 위치하며 핵심 메타데이터 (metadata)와 행동 지침을 보유합니다. 그 외의 모든 것은 선택 사항입니다. 실행 가능한 코드를 위한 scripts 디렉토리, 문서를 위한 references 폴더, 템플릿과 리소스를 위한 assets 디렉토리가 있습니다. 개발자는 스킬에 필요한 추가 파일이나 디렉토리를 무엇이든 추가할 수 있습니다. 이 형식에서 숨겨지거나 독점적인 부분은 전혀 없습니다.

이러한 단순함은 이 형식이 실제로 제공하는 가치를 가리고 있습니다. 에이전트 스킬은 단순한 프롬프트 (prompt)나 정적인 지식 파일이 아닙니다. 그것은 자급자족이 가능한 능력 패키지 (capability package)입니다. scripts 디렉토리가 있다는 것은 스킬이 단순히 워크플로우 (workflow)에 대한 설명뿐만 아니라, 실행 가능한 워크플로우를 직접 포함할 수 있음을 의미합니다. references 및 assets 디렉토리는 에이전트가 실제 업무를 수행하는 데 필요한 정확한 문서나 템플릿을 수행 지침과 함께 묶어서 제공할 수 있음을 의미합니다. 지식과 실행이 하나의 휴대 가능한 단위로 함께 이동합니다.

파일 기반 접근 방식은 도입 측면에서 매우 중요한 실질적인 결과를 가져옵니다. 즉, 에이전트 기술(Agent skills)은 완전히 사람이 읽을 수 있으며, 배포를 위해 특별한 런타임(Runtime), 플랫폼 또는 독점적인 도구가 필요하지 않습니다. 개발자는 어떤 텍스트 에디터로든 기술을 읽을 수 있고, Git을 통해 모든 변경 사항을 추적하며, GitHub를 통해 공유하고, 해당 형식을 지원하는 어떤 에이전트 워크플로우(Workflow)에도 바로 적용할 수 있습니다. 버전 관리(Version control), 코드 리뷰(Code review), 그리고 오픈 협업(Open collaboration)이 즉시 가능해집니다. 이는 이미 수십억 줄의 소프트웨어를 관리하고 있는 것과 동일한 인프라입니다.

이것이 바로 Markdown이나 JSON과 같은 형식이 어디에나 퍼지게 만든 설계 철학입니다. 개발자들이 이미 있는 곳에서 만나고, 그들이 이미 신뢰하는 도구를 사용하며, 형식이 워크플로우를 규정하는 것이 아니라 워크플로우를 보조하게 만드는 것입니다. 에이전트 기술 패키지는 동일한 논리를 따르며, AI 에이전트 생태계는 이제 막 가시화되기 시작한 방식으로 그 혜택을 입게 될 것입니다.

npm과의 평행 이론: 왜 오픈 형식이 권력 역학을 변화시키는가

역사는 이 점에 대해 일관된 모습을 보여줍니다. 패키징 형식이 오픈(Open)이 되면 권력은 이동합니다. npm은 단순히 JavaScript 라이브러리를 정리한 것이 아닙니다. npm은 권력의 중심을 기업의 게이트키퍼(Gatekeeper)로부터 자신만의 조건으로 게시하는 개별 개발자들에게로 옮겨왔습니다. pip 역시 Python을 위해 동일한 역할을 수행했습니다. apt는 Linux 소프트웨어 스택에 대한 통제권을 수천 명의 유지 관리자(Maintainer)들에게 재분배했습니다. 각 사례에서 오픈 형식은 그 메커니즘이었습니다. 표준화가 공유 자원(Commons)을 만들어냈습니다.

Agent Skills는 AI 에이전트 역량에 대해 동일한 움직임을 시도합니다. 이 사양(Specification)은 기술(Skill)을 메타데이터와 지침이 담긴 SKILL.md 파일을 포함하는 폴더로 정의하며, 선택적으로 스크립트, 참조 자료 및 템플릿을 함께 묶을 수 있습니다. 이는 의도적으로 최소화된 설계입니다. AI 에이전트 역량을 확장하기 위한 가볍고 오픈된 형식은, Anthropic, OpenAI, Microsoft 또는 기타 어떤 플랫폼 소유자의 허가 없이도 누구나 기술을 작성할 수 있음을 의미합니다.

벤더 종속 (Vendor lock-in)의 영향은 상당합니다. 오늘날 특화된 AI 기능들은 폐쇄적인 플랫폼 내부, 즉 독점적인 플러그인 (proprietary plugins), 비공개 툴체인 (private toolchains), 맞춤형 통합 (bespoke integrations) 형태의 형태로 존재합니다. Agent Skills 사양에 맞춰 구축된 기술은 원칙적으로 해당 표준을 채택하는 모든 에이전트 프레임워크 (agent framework)에서 소비될 수 있습니다. 이는 기능 계층 (capability layer)을 특정 벤더로부터 자유롭게 분리합니다. 개발자들은 특정 플랫폼을 위해 구축하는 것을 멈추고, 하나의 포맷 (format)을 위해 구축하기 시작합니다.

그 결과로 나타나는 하류 효과 (downstream effect)는 재사용 가능한 에이전트 기술의 커뮤니티 마켓플레이스입니다. 대기업의 플랫폼 팀 내부에 특화된 AI 전문 지식을 집중시키는 대신, 개방형 기술 레지스트리 (open skill registry)는 전체 개발자 커뮤니티에 걸쳐 해당 전문 지식을 크라우드 소싱 (crowd-sourcing)합니다. 보안 연구원이 침투 테스트 (penetration-testing) 기술을 게시합니다. 생물정보학자가 유전체학 워크플로우 (genomics workflow) 기술을 게시합니다. 세무 변호사가 규정 준수 로직 (compliance logic)을 기술 패키지에 인코딩합니다. 이들 중 누구도 플랫폼의 승인을 받을 필요가 없습니다. AI 에이전트를 구축하는 사람이라면 누구나 이러한 기술들을 직접 가져올 수 있습니다.

이것이 바로 npm의 레지스트리가 단일 기업이 내부적으로 복제할 수 없는 자원이 된 방식과 정확히 일치합니다. Agent Skills 포맷은 초기 단계이며 — 사양은 아직 GitHub에서 형태를 갖춰가는 중이지만 — 구조적 논리는 동일합니다. AI 에이전트 확장성을 위한 개방형 포맷은, 어떤 폐쇄형 플랫폼도 단독으로 구축할 수 있는 범위를 훨씬 뛰어넘어 확장되는 기술 생태계 (skills ecosystem)를 위한 조건을 형성합니다.

대부분의 보도가 놓치고 있는 것: 이것은 단순한 개발 도구(Dev-Tools) 이야기가 아니라 거버넌스(Governance)와 안전(Safety)의 문제입니다

Agent Skills에 대한 대부분의 보도는 개발자 생산성 — 더 빠른 워크플로우, 재사용 가능한 컴포넌트, 에이전트 동작을 확장하는 더 깔끔한 방법 — 에 초점을 맞춥니다. 그러한 프레임은 더 어려운 문제를 완전히 놓치고 있습니다.

표준화된 형식이 AI 에이전트가 새로운 지침을 받는 방식을 정의할 때, 그 형식은 신뢰 경계 (trust boundary)가 됩니다. 에이전트에게 송장을 처리하거나 클라우드 인프라를 관리하는 방법을 알려주는 SKILL.md 파일은 기능적으로 에이전트가 따르게 될 일련의 지시 사항 (directives)입니다. 악의적이거나 부주의하게 작성된 스킬은 단순히 잘못된 출력을 생성하는 데 그치지 않습니다. 이는 자율 에이전트를 기계의 속도로 심각한 해악을 향하도록 유도할 수 있습니다. Agent Skills를 채택하기 쉽게 만드는 가볍고 폴더 기반인 구조는, 동시에 오용하기 쉽게 만드는 동일한 특성이기도 합니다.

현재의 사양 (specification)은 스킬을 검증할 책임을 이를 로드하는 개발자나 운영자에게 전적으로 지우고 있습니다. 내장된 검증 계층 (verification layer)은 존재하지 않습니다. 사양에는 서명 요구 사항, 출처 확인 (provenance check), 샌드박싱 (sandboxing) 의무화 등이 나타나 있지 않습니다. 채택 규모가 작고 실무자들이 주의를 기울일 때는 이러한 격차가 관리 가능할 수 있습니다. 하지만 수천 개의 스킬이 에이전트 프레임워크, 기업용 배포, 오픈 소스 툴체인을 통해 유통되는 대규모 환경에서는 이는 시스템적 취약점이 됩니다. npm 생태계는 신뢰 인프라가 감당할 수 있는 속도보다 더 빠르게 성장한 이후, 악성 패키지를 정리하는 데 수년을 보냈습니다. 에이전트 스킬 레지스트리 (skill registries) 또한 동일한 압박에 직면할 것이며, 소비자가 수동적인 코드 라이브러리가 아닌 자율 시스템이라는 점에서 그 위험 부담은 더 높습니다.

거버넌스 (governance) 문제 또한 마찬가지로 해결되지 않은 상태입니다. 누가 정전 (canonical) 스킬 레지스트리를 통제하는지, 어떤 규칙 하에 운영되는지, 그리고 어떤 책임성을 갖는지가 이 표준이 건강한 공유 자원 (commons)으로 성숙할지, 아니면 역량 남용의 통로 (capability abuse vector)가 될지를 결정합니다. 거버넌스가 없는 개방형 레지스트리는 쓰레기 매립지가 됩니다. 단일 벤더가 통제하는 폐쇄형 레지스트리는 병목 지점 (chokepoints)이 됩니다. Agent Skills 프로젝트는 현재 최소한의 발자국만을 남긴 GitHub 사양에 불과합니다. 발표된 거버넌스 기구도, 보안 정책 프레임워크도, 저장소에서 확인할 수 있는 독립적인 감독 구조도 보이지 않습니다.

AI 에이전트 확장성 표준(extensibility standards)이 기업과 정부의 본격적인 도입을 이끌어내려면, 생태계가 고착화(lock-in)되기 전에 이러한 질문들에 대한 답이 마련되어야 합니다. 에이전트 기술(agent skill) 배포를 위한 신뢰 인프라를 설계해야 하는 시점은 배포 문제가 발생한 후가 아니라, 발생하기 전입니다.

누가 승리할 것인가 — 그리고 누가 저항할 것인가

독립 개발자와 소규모 팀은 개방형 에이전트 기술 표준으로부터 혜택을 입기에 가장 유리한 위치에 있습니다. Agent Skills 형식은 SKILL.md 파일이 포함된 폴더 외에는 아무것도 요구하지 않습니다. 플랫폼 파트너십도, 기업 영업 주기(sales cycle)도, API 라이선스 계약도 필요 없습니다. 예를 들어 규제 준수 문서 검토나 DICOM 의료 영상 분석을 위한 특화된 기술을 구축한 1인 개발자는, 이를 한 번만 게시하면 호환 가능한 모든 에이전트 런타임(runtime)에서 작동하게 할 수 있습니다. 이는 npm이 패키지 생성을 브라우저나 런타임 벤더의 승인으로부터 분리했을 때 JavaScript 개발자들에게 제공했던 것과 동일한 레버리지(leverage)입니다. 특화된 전문 지식이 한 기업의 제품 내에 갇힌 서비스가 아닌, 배포 가능한 자산이 되는 것입니다.

OpenAI, Anthropic, Google DeepMind와 같은 대형 AI 플랫폼 기업들은 정반대의 인센티브를 가집니다. 독점적인 에이전트 기능 라이브러리는 전환 비용(switching costs)을 발생시키며, 전환 비용은 고객 유지 및 매출로 직결됩니다. 개방형 에이전트 기술 생태계는 각자의 에이전트 제품을 둘러싼 해자(moat)를 약화시킵니다. 이러한 기업들이 자발적으로 공유 사양(specification)을 채택하기 전에, 호환되지 않는 스키마(schema)를 가진 내부 기술 라우팅 시스템을 구축할 것으로 예상됩니다. 데이터 형식, 메시징 프로토콜, 클라우드 API의 역사를 보면 플랫폼 기존 사업자(incumbents)들이 상호 운용성(interoperability)을 주도하는 경우는 드물며, 강제될 때 비로소 이를 따르는 경향이 있습니다.

이러한 강제 기능(forcing function)은 기업 구매자들로부터 나올 가능성이 높습니다. 법률, 금융, 운영 팀 전반에 걸쳐 AI 에이전트를 배포하는 대규모 조직들은 파운데이션 모델(foundation model) 제공업체를 바꿀 때마다 자신들의 맞춤형 에이전트 워크플로우(agent workflows)를 매번 다시 구축하고 싶어 하지 않습니다. 이들은 클라우드 인프라에서 벤더 종속(vendor lock-in)을 경험해 왔으며, 이제 구매 팀은 일상적으로 이식성(portability) 조항을 요구합니다. 만약 에이전트 스킬(agent skills)이 전문화된 에이전트 워크플로우를 인코딩하기 위한 이식 가능하고 벤더 중립적인 형식 — 즉, 플랫폼이 아닌 조직과 함께 이동하는 재사용 가능한 지식 계층(knowledge layer) — 으로 등장한다면, 기업의 IT 및 법무 부서는 과거 클라우드 벤더들에게 S3 호환 스토리지 API와 OCI 같은 컨테이너 표준을 따르도록 압박했던 것과 마찬가지로, 벤더들이 이를 지원하도록 압박할 것입니다.

이 개방형 형식의 단순함은 강점이자 동시에 정치적 취약점이기도 합니다. 누구나 이를 구현할 수 있지만, 누구도 구현할 의무는 없습니다. 에이전트 스킬의 이식성이 기본 기대치가 될 수 있을지는 사양(specification)의 기술적 가치보다는 기업 구매자들이 호환성을 구매 요건으로 만드느냐에 달려 있습니다.

초기 단계, 높은 이해관계: 향후 주목해야 할 점

Agent Skills는 현재 사양 정의 및 문서화 단계에 머물러 있습니다. GitHub 리포지토리는 형식을 정의하고, 컨벤션(conventions)을 수립하며, 왜 표준화된 AI 에이전트 역량이 중요한지에 대한 근거를 제시하고 있습니다. 아직 갖추지 못한 것은 광범위한 실세계 채택을 통해 얻게 되는 실전 검증(battle-hardening)입니다. 향후 6개월간의 커뮤니티 수용 과정을 통해 이것이 지속 가능한 개방형 표준이 될지, 아니면 GitHub의 버려진 사양 무덤 속으로 조용히 사라질 흥미로운 프로토타입에 그칠지가 드러날 것입니다.