에이전트 스킬은 소프트웨어 공급망의 공격 표면이다 | Focused Labs

에이전트 스킬 (Agent skills)은 에이전트 기반 AI (agentic AI)를 사용하여 애플리케이션을 구축하는 개발자들을 위한 지침 기능 역할을 하도록 설계되었으나, 점차 개발자가 다운로드하여 실행할 수 있는 공급망 기능 (supply-chain features)으로 변모하고 있습니다. 코드로 패키징되어 마켓플레이스를 통해 배포되는 에이전트 스킬은 제가 "실행 가능한 공급망 아티팩트 (executable supply-chain artifacts)"라고 부르는 것이 되어가고 있습니다. 다른 소프트웨어 기능과 마찬가지로, 이러한 아티팩트들은 친근해 보이는 마크다운 (markdown) 재킷 속에 숨겨진 코드 형태의 권한을 가질 수 있습니다.

AI 에이전트 스킬이 마켓플레이스와 기업용 도구를 통해 배포됨에 따라, 보안 업계는 이를 실행 가능한 아티팩트로 검토해야 합니다. 새로운 논문인 “마켓플레이스 내 악성 AI 에이전트 스킬에 관한 실증적 연구 (An Empirical Study on Malicious AI Agent Skills in Marketplaces)”에 따르면, 마켓플레이스에 있는 총 3,984개의 AI 에이전트 스킬 중 76개가 자격 증명 탈취 (credential theft), 백도어 설치 (backdoor installation), 데이터 유출 (data exfiltration)을 위한 악성 페이로드 (malicious payloads)를 포함하고 있는 것으로 나타났습니다. 저자들은 또한 수동 검토 결과 13.4%가 최소 하나 이상의 심각한 문제를 포함하고 있음을 발견했습니다. 그들은 논문 발표 시점에 연구 대상 마켓플레이스 중 한 곳에서 8개의 악성 스킬이 여전히 사용 가능함을 확인했습니다 (arXiv, 2026).

이는 에이전트 기반 AI 보안에 관한 논의를 변화시킵니다.

스킬 파일이 패키지 경계 (package boundary)가 되었습니다.

스킬은 패키지가 되어가고 있다

약 1년 전만 해도 우리는 Claude Code, Cursor, 에이전트 또는 워크플로 어시스턴트 (workflow assistant)와 같은 모델을 위해 개발자가 작성한 일련의 규칙 옆에, 본질적으로 애플리케이션의 저장소 (repository) 역할을 하는 스킬 파일을 보여주곤 했습니다. 그 규칙 저장소는 복잡한 표에서 정보를 추출하거나 주어진 프롬프트 (prompt)에 대한 보조 텍스트를 생성하는 것과 같이, 쿼리 (query) 또는 워크플로를 처리하는 방법에 대한 추가적인 컨텍스트 (context)나 습관을 모델에 제공했습니다.

이제 그 패턴은 날카로운 이빨을 갖게 되었습니다.

문제는 지름길이 신뢰 경계 (trust boundaries)를 가로지른다는 점입니다.

스킬 패키지(skill package)는 다음과 같은 명확한 질문들에 답할 수 있어야 합니다: 스킬의 소유자는 누구인가, 무엇을 수행했는가, 어디에서 실행되었는가, 어떤 자격 증명(credentials)이 사용되었는가, 어떤 도구(tools)가 사용되었는가, 도구의 샌드박스(sandbox) 설정은 어떠했는가, 스킬에 대한 평가(evaluations) 결과는 무엇인가, 스킬에 의해 생성된 트레이스(traces)는 무엇인가, 어떤 사용자 작업이 이를 시작했는가, 해당 사용자에 대한 롤백(rollback)은 어떻게 작동하는가.

Honeycomb는 OpenTelemetry가 활성화된 프로덕션 서비스(production services)를 계측(instrument), 관찰(observe), 디버깅(debug)하고, 분산 트레이싱(distributed tracing) 시스템에서 관찰성 스택(observability stacks)으로 마이그레이션하는 데 필요한 관찰성 전문 지식을 인코딩한 8개의 스킬, 2개의 에이전트, 그리고 워크플로(workflows) 형태로 '에이전트 스킬(Agent Skills)'을 발표했습니다 (Honeycomb, 2026). Lyft는 도메인 전문가들이 커스텀 에이전트를 정의할 수 있도록 LangGraph와 LangSmith를 사용하여 셀프 서비스 플랫폼을 구축했으며, 이 플랫폼은 기반이 되는 그래프(graph), 도구(tools), 안전성(safety), 상태(state), 트레이싱(tracing), 대시보드(dashboards), 그리고 LLM-as-a-judge 평가를 관리합니다 (LangChain, 2026).

이것이 채택을 위한 올바른 방향입니다.

거버넌스(Governance) 또한 그 권한과 함께 움직여야 합니다.

이는 인프라 워크로드로서의 에이전트 모니터링(agent monitoring as an infrastructure workload)과 직접적으로 관련이 있습니다. 해당 노트에서는 개별 모델 호출을 모니터링하는 것에 대해 경고한 바 있습니다. 스킬의 경우, 모니터링은 설치된 아티팩트(artifact), 런타임 권한(runtime permissions), 트레이스(traces), 사용자 작업(user actions), 그리고 복구 프로세스(recovery process)를 추적해야 합니다.

스킬 패키지는 신뢰할 수 없는 명령(untrusted instructions)이 실행 가능한 프로덕션 동작(executable production behavior)으로 변하는 지점입니다.

그렇게 되면 사고 검토(Incident review)는 사고의 사실 관계를 조사하는 대신 '우리가 어떻게 느꼈는가'에서 시작하게 됩니다.

옵티마이저(Optimizer)는 경계를 더 견고하게 만듭니다

고정된 에이전트(Frozen agent)에 대해 스킬 파일(Skill file)을 외부 상태(External state)로 취급하고, 점수가 매겨진 롤아웃(Scored rollouts)을 사용하여 스킬 문서에 대한 제한된 편집(Bounded edits)을 수행하는 기술들도 존재합니다. SkillOpt는 직접 채팅, Codex 기반 채팅, Claude Code 기반 채팅을 포함한 52개의 모델, 벤치마크 또는 하네스(Harness) 비교에서 52번 모두 승리하거나 무승부를 기록했습니다 (SkillOpt, 2026). SkillGrad는 스킬 패키지를 파라미터(Parameter)로 취급하며, 시간이 지남에 따라 패키지를 패치하기 위해 궤적 수준의 손실(Trajectory-level loss)을 사용합니다 (SkillGrad, 2026).

정교한 스킬 시스템에서 스킬의 매니페스트(Manifest)에는 스킬이 호출하는 도구(Tools) 목록, 스킬이 읽거나 쓰는 파일 목록, 스킬이 연결하는 네트워크 위치 목록, 스킬이 요청할 수 있는 비밀 정보(Secrets) 목록, 스킬이 읽을 수 있는 데이터 클래스(Data classes) 목록, 그리고 스킬 외부의 데이터에 영향을 미칠 수 있는 동작을 수행하기 위해 필요한 인간의 승인(Human approvals) 목록이 포함됩니다.

검토(Reviews)가 스킬을 영원히 안전하게 만들어주지는 않습니다. 검토를 마친 스킬은 깨끗한 상태로 프로덕션(Production)에 투입된 후, 평가(Evals), 프로덕션 트레이스(Production traces), 실패한 작업, 그리고 대규모 테스트를 거칠 수 있습니다. 이때 스킬이 습득하는 습관들은 유용할 수도 있습니다. 하지만 검토를 통과하고 높은 점수를 받았기 때문에 안전해 보이는 단 한 번의 텍스트 편집을 통해, 권한을 추가하거나, 가정을 완화하거나, 데이터 처리 방식을 변경할 수도 있습니다.

Agyn은 이 문맥에서 "에이전트의 정의"를 "Terraform 프로바이더를 통한 코드(예: 함수 프로비저닝), Kubernetes 상의 시그널 기반 상태 저장 서버리스 런타임(예: 이벤트를 처리하는 Python 루프), 그리고 상태를 유지하고 내부 서비스에 접근하는 에이전트를 위한 제로 트러스트(Zero-trust) 및 최소 권한(Least-privilege) 보안 모델"로 정의합니다 (Agyn, 2026). 요약하자면, 관리되어야 할 인프라로서의 에이전트 형태는 그 정의(코드로서), 런타임(서버리스 프로세스로서), 그리고 상태를 보유하고 서비스에 접근하는 에이전트로서 반드시 작동해야 하는 권한의 경계가 교차하는 지점입니다.

스킬(Skills)이 읽기 가능한 파일로 패키징되어 워크플로에 빠르게 투입될 수 있기 때문에 더 많은 문제가 발생합니다. 출처 추적(Provenance tracking) 기능이 없는 패키지 매니저(Package managers)는 악성코드 유포 채널이 됩니다. 범위가 제한된 자격 증명(Scoped credentials)이 없는 CI/CD 파이프라인은 비밀 정보 유출 엔진이 됩니다. 제한된 재현성이나 변경 이력의 부재로 인해 생성된 프롬프트(Prompts)에 관한 구전 지식(Folklore)은, 최적화되지 않은 에이전트가 셀프 서비스 플랫폼을 통해 구축되고 배포되는 것을 가능하게 합니다.

만약 릴리스 노트를 작성하는 스킬을 할당한다면, 이는 작은 샌드박스(Sandbox) 내에 있을 것입니다. 고객 결제/환불 정보, 운영 데이터, 소스 코드, 또는 사용자 신원을 업데이트하는 스킬은 완전히 다른 영역에 있어야 하며, 이전에 에이전트 결제(Agentic payments)에서 논의한 것과 동일한 지출 규율을 상속받아야 합니다.

신뢰할 수 있는 런타임 동작 vs. 선언된 런타임 동작.

셀프 서비스 에이전트는 거버넌스를 에지(Edge)로 이동시킨다

Lyft의 고객 지원 업무에 대한 설명은 도입 압박을 보여줍니다. 계정 액세스, 손해 배상 청구, 요금 검토, 수익 분쟁, 자율 주행 차량 지원 등은 중앙의 MLE (Machine Learning Engineer) 대기열보다는 지원 도메인 전문가에 더 가깝습니다. 기존의 루프는 몇 달이 걸렸습니다. 셀프 서비스 계층은 플랫폼이 상태(state), 도구(tools), 안전성(safety) 및 평가(evaluation)를 관리하는 동안 이 루프를 몇 주 단위로 단축했습니다 (LangChain, 2026).

프롬프트 라이브러리(prompt libraries)의 경우, 레지스트리(registry)는 프롬프트의 텍스트만 저장하면 됩니다. 스킬 레지스트리(skill registries)의 경우, 레지스트리는 서명된 아티팩트(artifacts)를 해당 아티팩트의 메타데이터와 함께 저장합니다. 이 메타데이터에는 소유자, 차이점(diffs, 아티팩트가 점진적으로 생성된 경우), 아티팩트에 대한 검증 결과(validation results), 아티팩트에서 발생하는 것으로 알려진 실패 모드(failure modes), 아티팩트에 대한 권한 매니페스트(permission manifests), 아티팩트에 대한 샌드박스 프로필(sandbox profiles), 아티팩트에 대한 텔레메트리 정의(telemetry definitions), 그리고 아티팩트의 폐기 상태(deprecation state)가 포함됩니다. 레지스트리는 콘텐츠 라이브러리 사용량에 대한 질문이 아니라, 인시던트(incidents)에 관한 질문에 시스템이 답할 수 있도록 해야 합니다.

어젯밤에 무엇이 바뀌었는가? 어떤 에이전트가 어젯밤에 어떤 스킬 버전을 실행했는가? 이 스킬들은 어떤 도구(tools)를 호출했는가? 어떤 평가 게이트(eval gate)가 이 스킬들의 업데이트를 평가했는가? 이 에이전트들에게 어떤 자격 증명 범위(credential scopes)가 활성화되어 있었는가? 이 에이전트들에 의해 어떤 고객 데이터가 읽히거나 쓰였는가? 에이전트를 이전 스킬 버전으로 롤백(roll back)하는 프로세스는 무엇인가? (에이전트를 재설치(re-installing)하는 것만으로는 에이전트를 "롤백"하기에 충분하지 않을 것으로 추정됩니다.)

에이전트 플랫폼은 에이전트의 모든 스킬을 실행하거나 설치할 수 있는 패키지(packages)로 취급하는 방향으로 진화하고 있으며, 사실상 운영 지식(operating knowledge)을 에이전트 플랫폼이 배포하기 위해 새로운 제품이나 기능을 패키징하는 것과 동일한 방식으로 취급하고 있습니다.

무언가가 패키징되는 순간, 배포 속도는 검사(inspection) 속도를 앞지르게 됩니다.

물론 수동 검토(manual review)가 필요한 영역도 있지만, 그 범위는 제한되어야 합니다. 스킬(Skills)은 설치되기 전에 정적 검사(static checks)를 통과해야 합니다. 스킬은 설치되기 전에 자신이 요구하는 권한(permissions)을 선언해야 합니다. 스킬은 본격적인 작업 실행(full-scale task execution) 단계로 승격되기 전에 샌드박스(sandbox) 내에서 실행되어야 합니다. 스킬의 평가(evals)가 완료되어야 스킬이 본격적인 작업 실행 단계로 승격될 수 있습니다. 스킬은 실행 중에 추적 영수증(trace receipts)을 방출해야 합니다. 스킬은 오작동 시 롤백(rollback) 형태를 지원해야 합니다.

스킬에 대한 거버넌스 모델(governance model)은 단순한 문서나 회의 그 이상이어야 합니다. 배포 기록에는 소유자 명시, 버전 추적, 각 변경 사항에 대한 차이(diff) 표시, 권한 정의, 범위 내 자격 증명(credentials) 목록, 승인된 도구 목록, 샌드박스 구성 정의, 필수 평가 항목 목록, 런타임 추적(runtime traces) 표시, 스킬을 배포한 사용자 작업 기록, 그리고 롤백 계획 정의가 포함되어야 합니다.

에이전트와 관련된 다음 차례의 사고들은 에이전트에서 실행되는 스킬들로 인해 발생할 것입니다.

이는 앞서 언급한 인프라 워크로드로서의 에이전트 모니터링(agent monitoring as an infrastructure workload)에 대한 노트와 직접적으로 연관됩니다. 개별 모델 호출을 모니터링하는 것은 너무 좁은 시각입니다. 스킬의 경우, 시스템은 설치된 아티팩트(artifact), 런타임 권한, 추적(traces), 사용자 작업, 그리고 복구 프로세스를 모니터링해야 합니다.

그러면 모두가 에이전트를 누가 승인했느냐고 묻게 될 것입니다.

이것은 또한 MCP 경계를 가로지르는 추적 증거(trace evidence across the MCP boundary)에 관한 우리의 이전 관찰과도 일치합니다. 스킬의 추적은 단순히 모델 대화의 기록(transcript)이어서는 안 됩니다. 스킬의 행동을 보여주어야 합니다. 즉, 어떤 역량(capability)을 요청했는지, 어떤 자격 증명(credential)을 사용했는지, 어떤 도구 호출(tool calls)을 수행했는지, 그리고 어떤 결과가 돌아왔는지를 보여주어야 합니다.

스킬 경계(skill boundary)를 누가 승인했는지 물으십시오.

그렇지 않으면 사고 검토(incident review)는 막연한 느낌(vibes)에서 시작될 것입니다. 좋지 않은 시작입니다.

우리는 마치 에이전시(agency)가 모델 내부에 존재하는 것처럼 AI 에이전시 개발에 실제 시간을 할애해 왔습니다. 하지만 에이전시(agency)는 시스템, 즉 모델(model), 도구(tools), 런타임(runtime), 메모리(memory), 스킬(skills), 그리고 권한(permission) 안에 존재합니다. 스킬(skills)은 인간의 전문 지식과 런타임(runtime)의 권한에 밀접하게 맞닿아 있습니다. 그 결합은 유용하면서도 위험합니다.

스킬 거버넌스(Skill governance)는 제어(control)가 스킬의 생애주기(lifecycle) 전반에 걸쳐 스킬을 따라갈 때에만 작동합니다.

스킬 마켓플레이스(skill marketplace)가 다가오고 있습니다. 거버넌스 경계(governance boundary)가 그곳에 먼저 도달해야 합니다.