에이전트 스킬: 새롭게 부상하는 개방형 표준

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

AI 에이전트가 코파일럿에서 자율적으로 행동하는 주체로 발전함에 따라, 업계는 하나의 공통된 추상화 개념으로 수렴하고 있습니다. 바로 에이전트 스킬입니다.

에이전트 스킬은 에이전트가 수행할 수 있는 작업을 체계적으로 정의합니다. 지침, 예상 동작, 명시된 도구 사용 방식을 에이전트와 플랫폼 전반에서 공유하고 버전을 관리하며 재사용할 수 있는 이식 가능한 아티팩트로 패키징합니다. 개념적으로는 과거 IDE의 플러그인이나 브라우저의 확장 프로그램과 같은 역할을 합니다.

이 모델에 실질적인 무게를 더하는 것은 더 이상 실험적이거나 독점적인 모델이 아니라는 점입니다. Anthropic은 개방형 Agent Skills 표준을 공개하여 스킬을 특정 프레임워크에 종속된 구성 요소가 아닌, 이식 가능하고 상호 운용 가능한 계층으로 자리매김했습니다. MCP가 에이전트와 도구 간의 통신 방식을 표준화했듯이, Agent Skills는 에이전트가 역량을 습득하는 방식을 표준화하고 있습니다.

이는 중요합니다. 개방형 표준에는 강력한 구심력이 있습니다. 생태계와 도구, 레지스트리를 끌어들이고, 궁극적으로는 기업의 도입을 이끌어냅니다. 공급업체들이 공통된 추상화 방식에 뜻을 모으면, 이는 더 이상 단순한 호기심의 대상이 아니라 인프라로 자리 잡게 됩니다. 2025년 12월 출시에는 다양한 공급업체(Atlassian, Figma, Canva, Stripe, Notion, Zapier)의 파트너 스킬이 포함되었으며, 이는 이 표준이 이미 추진력을 얻고 있음을 보여줍니다.

이는 보안에 미치는 영향이 더 이상 가정에 불과하지 않다는 뜻입니다.

에이전트 스킬이 보안 모델을 바꾸는 이유

에이전트 스킬은 의도적으로 가볍게 설계되었습니다. 사람이 쉽게 읽고 작성할 수 있으며 간편하게 배포할 수 있도록 만들어졌습니다. 원활한 공유를 목표로 하기 때문에 대부분의 구현에서는 동작을 정의하는 데 Markdown을, 메타데이터를 작성하는 데 YAML을 사용합니다.

개발자 생산성 측면에서는 분명 이점입니다.

보안 관점에서 보면, 이는 익숙하지만 위험한 패턴을 만들어 냅니다. 즉, 콘텐츠로 전달되는 실행 가능한 의도입니다.

스킬은 런타임에 로드됩니다. 스킬은 에이전트의 추론 루프 내에서 작동하며, 계획 수립, 도구 선택, 실행 순서에 영향을 미칠 수 있습니다. 또한 동적으로 가져와 다른 스킬을 통해 연쇄적으로 구성되는 경우가 많습니다. 즉, 구성 파일보다는 공급망을 통해 유입되는 요소에 더 가깝게 작동합니다.

중요한 점은 스킬 자체에는 어떠한 강제력도 없다는 것입니다. 스킬은 에이전트가 무엇을 하고자 하는지를 명시할 뿐, 에이전트가 실제로 할 수 있는 일을 제한하지는 않습니다.

그 차이가 핵심입니다.

스킬이 활성화되고 나면 개발자가 의존해 온 기존의 ‘시프트 레프트’ 통제 방식은 대부분 무의미해집니다. 에이전트의 내부 계획에는 풀 리퀘스트가 없습니다. 도구 호출이 실행되기 전에 사람이 코드를 검토하는 절차도 없습니다. 추론과 실행 사이에 멈추는 단계도 없습니다.

에이전트의 개발은 런타임에 이루어집니다.

스킬로는 메울 수 없는 집행의 공백

에이전트 스킬을 보안 통제 지점으로 간주하고 싶을 수 있습니다. 결국 스킬에는 필요한 도구와 예상되는 동작이 명시되어 있으므로, 안전장치를 추가하기에 적합한 곳처럼 보입니다.

하지만 스킬은 스택에서 잘못된 위치에 있습니다.

스킬은 에이전트 내부에 존재합니다. 작업 완료와 진척을 최적화하는 바로 그 모델이 스킬을 해석합니다. 스킬에 보안을 강제하도록 요구하는 것은 에이전트에 스스로를 통제하라고 요구하는 것과 같습니다. 그런 방식은 지금까지 한 번도 안정적으로 작동한 적이 없으며, 앞으로도 그럴 것입니다.

더 중요한 점은 스킬에는 아무런 권한이 없다는 것입니다. 스킬은 접근 권한을 철회하거나, 실행을 제한하거나, 부작용을 검사하거나, 데이터 유출을 방지할 수 없습니다. 기껏해야 힌트를 제공할 뿐이며, 최악의 경우에는 통제하고 있다는 잘못된 인식을 심어 줍니다.

보안은 의도를 설명하는 수준에 머물러서는 안 됩니다. 보안은 기능 실행 수준에서 구현되어야 합니다. 익숙한 용어로 표현하면, 자율 시스템에 접근 제어와 ID 관리를 적용하는 것입니다. 고객들은 이를 에이전틱 AI와 관련된 중대한 과제로 인식하고 있습니다.

F5의 애플리케이션 전략 현황 설문조사에서 ID 및 액세스 제어가 에이전틱 AI의 예상 과제 중 가장 큰 과제로 꼽혔습니다.

도구 계층이 실질적으로 강제할 수 있는 유일한 경계인 이유

에이전트는 잘못된 생각만으로 해를 끼치지 않습니다. 생각이 도구 경계에서 행동으로 이어질 때 비로소 해를 끼칩니다.

API 호출부터 코드 작성, 인프라 배포부터 데이터베이스 쿼리 또는 다른 시스템으로의 데이터 전송에 이르기까지, 에이전트의 모든 유의미한 작업은 도구 인터페이스를 거칩니다. 이 인터페이스는 자율성이 현실과 맞닿는 지점입니다. 또한 시스템이 올바르게 설계되었다면 에이전트가 우회할 수 없는 최후의 지점이기도 합니다.

이러한 이유로 ‘도구 방화벽’이 에이전트 보안을 위한 최적의 제어 계층으로 부상합니다.

도구 방화벽은 모든 도구 호출을 중개합니다. 에이전트와 에이전트가 접근하는 시스템 사이에서 정책을 실행 전에 적용하므로, 피해가 발생한 후에 감사하는 방식과는 다릅니다. 프롬프트 수준의 제어나 스킬 메타데이터와 달리 에이전트의 추론 루프 외부에서 작동하기 때문에 모델의 준수 여부에 좌우되지 않습니다.

이 계층은 ‘MCP 보안’과 ‘AI 가드레일’이 만나는 지점입니다. MCP는 에이전트가 도구와 어떻게 통신하는지를 정의합니다. 도구 방화벽은 에이전트의 도구 사용이 허용되는지 여부와 어떤 제약 조건이 적용되는지를 결정합니다. 도구가 에이전트로 하여금 ‘새로운 기술’을 익히게 해 준다면, 도구 방화벽은 그 기술이 큰 사고를 일으키지 않도록 막는 통제 장치입니다.

개념적으로 새로운 아이디어는 아닙니다. API 게이트웨이, 서비스 메시, 제로 트러스트 아키텍처의 기반이 되는 것과 동일한 패턴입니다. 새로운 점은 인터페이스 반대편의 주체입니다.

실제로 도구 방화벽은 중개자 역할을 합니다. 에이전트는 외부 시스템에 직접 접근할 수 있는 자격 증명을 보유하지 않습니다. 대신 작업을 요청하면, 방화벽이 해당 작업의 허용 여부와 허용 조건 및 제약 사항을 결정합니다.

도구 방화벽은 ID 컨텍스트(어떤 에이전트인지, 어떤 스킬인지, 어떤 환경인지)를 평가하고, 매개변수와 페이로드를 검사하며, 코드형 정책을 적용하고, 적절한 경우에만 수명이 짧은 최소 권한 자격 증명을 발급합니다. 또한 결과를 관찰하고 출처를 기록하며, 자율적 동작에 대해 검증 가능한 감사 추적 기록을 제공합니다.

이를 통해 스킬은 본래의 역할, 즉 기능 사용 요청이 되며, 권한 부여가 되지는 않습니다.

이제 남은 것은 도구 방화벽이 어떤 형태로 자리 잡을지를 시장이 결정하는 일입니다. 하지만 에이전트 아키텍처를 위한 보안 도구 체계의 일부로 도구 방화벽이 등장하는 것은 필연적입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물