에이전트 스킬(Agent Skills)은 이제 의존성(Dependencies)이다

에이전트 스킬(Agent Skills)의 흥미로운 점은 그것이 프롬프트(Prompt)를 더 보기 좋게 만든다는 것이 아닙니다.

그것은 데모 버전일 뿐입니다.

진정한 변화는 에이전트의 행동이 채팅 기록(Chat history)에서 벗어나 폴더(Folders)로 이동하기 시작했다는 점입니다. 지침(Instructions), 스크립트(Scripts), 참조 파일(Reference files), 예시(Examples), 에셋(Assets), 그리고 도구에 대한 가정(Tool assumptions)들이 이제 재사용 가능한 하나의 단위로서 함께 이동할 수 있습니다. 이것은 유용합니다. 또한 이것은 '프롬프팅 기술(Prompting trick)'이 운영상의 의존성(Operational dependency)이 되는 바로 그 순간이기도 합니다.

팀이 한 번 스킬을 설치하거나 작성하고 나면, 올바른 질문은 더 이상 "이것이 모델을 더 똑똑하게 만드는가?"가 아닙니다.

더 나은 질문은 다음과 같습니다: "이 의존성(Dependency)을 읽어보지도 않고 내 워크플로(Workflow) 내부에서 실행하도록 허용하겠는가?"

만약 그 의존성이 패키지(Package)라면 대부분의 팀은 아니라고 답할 것입니다. 이 경우에도 똑같이 답해야 합니다.

스킬은 긴 프롬프트 그 이상이다

스킬에 대한 깔끔한 멘탈 모델(Mental model)은 간단합니다. 작업의 반복 가능한 부분들을 패키지화하여 에이전트가 필요할 때 이를 발견할 수 있도록 하는 것입니다.

Anthropic의 엔지니어링 기술 문서(Engineering writeup)는 스킬을 지침, 스크립트 및 리소스를 포함할 수 있는 폴더로 설명합니다. 문서에는 에이전트가 먼저 압축된 메타데이터(Metadata)를 보고, 나중에 관련 스킬 콘텐츠를 로드하는 발견 흐름(Discovery flow)이 설명되어 있습니다. 공개된 anthropics/skills 리포지토리(Repo)는 그 형태를 더욱 구체적으로 보여줍니다: 각 스킬은 SKILL.md 엔트리 포인트(Entry point)를 가지며 지원 파일들을 함께 가져올 수 있습니다.

이는 모든 것을 거대한 시스템 프롬프트(System prompt)에 쑤셔 넣는 것보다 훨씬 더 나은 프리미티브(Primitive)입니다.

거대한 프롬프트는 부패합니다. 지금 일어나고 있지 않은 작업들을 위한 규칙들로 과부하가 걸립니다. 모든 실행을 컨텍스트 비용(Context-tax) 문제로 만듭니다. 또한 유용한 프롬프트 블록을 다른 워크플로로 복사하는 것은 보통 그곳에 있었는지조차 잊어버린 가정들을 함께 복사하는 것을 의미하기 때문에 재사용을 어색하게 만듭니다.

스킬은 절차를 휴대 가능하게(Portable) 만듦으로써 실제 문제를 해결합니다.

하지만 휴대 가능성(Portability)은 양날의 검입니다.

만약 그 스킬이 단지 "이 문서를 이런 방식으로 서식화해줘"라고만 말한다면 괜찮습니다. 그것은 작고 검토 가능한 수준입니다. 하지만 만약 그 스킬에 스크립트(Scripts), 로컬 파일 가정(Local file assumptions), 도구 지침(Tool instructions), 인증 기대치(Authentication expectations), 그리고 특정 디렉토리를 읽는 습관이 포함되어 있다면, 당신은 더 이상 귀여운 프롬프트 조각(Prompt snippet)을 다루고 있는 것이 아닙니다. 당신은 업무가 수행되는 방식을 바꾸는 패키지(Package)에 더 가까운 무언가를 다루고 있는 것입니다.

그것은 지루한 요소들이 필요하다는 것을 의미합니다.

소유권(Ownership). 검토(Review). 버전 이력(Version history). 범위(Scope). 삭제(Removal).

점진적 공개(Progressive disclosure)는 검토 비용이 아니라 컨텍스트 비용을 줄인다

점진적 공개(Progressive disclosure)는 이 분야에서 가장 좋은 아이디어 중 하나입니다. 에이전트(Agent)가 모든 긴 지침 파일(Instruction file)을 처음에 미리 로드할 필요는 없습니다. 메타데이터(Metadata)에서 시작하여, 작업이 일치할 때만 더 깊은 절차(Procedure)를 가져올 수 있습니다.

좋습니다. 그것은 컨텍스트(Context)를 절약해 줍니다.

하지만 그것이 에이전트가 나중에 무엇을 로드할지에 대해 당신이 이해해야 하는 부담까지 없애주지는 않습니다.

이 부분이 팀들이 과소평가할 것이라고 생각하는 지점입니다. 검토자(Reviewer)는 최상위 스킬 설명(Top-level skill description)을 보고 동작을 이해했다고 생각할 수 있습니다. 그러다 실제 실행 시 더 깊은 파일을 로드하거나, 헬퍼 스크립트(Helper script)를 호출하거나, 로컬 컨벤션(Local convention)을 따르거나, 짧은 설명에서는 명확하지 않았던 리소스(Resource)를 가져올 수 있습니다.

그것이 자동으로 나쁜 것은 아닙니다. 그것이 바로 이 메커니즘의 핵심입니다.

하지만 그것은 검토 작업(Review job)을 변화시킵니다. 당신은 더 이상 하나의 프롬프트(Prompt)를 검토하는 것이 아닙니다. 당신은 작은 역량 트리(Capability tree)를 검토하고 있는 것입니다. 짧은 설명은 패키지 요약(Package summary)이지, 전체 의존성(Dependency)이 아닙니다.

개발자 워크플로(Developer workflows)의 경우, 이것은 매우 중요합니다. 왜냐하면 에이전트는 단순히 텍스트만 생성하는 것이 아니기 때문입니다. 그들은 리포지토리(Repositories)를 조사하고, 파일을 편집하며, 도구(Tools)를 호출하고, 테스트(Tests)를 실행합니다. 이슈 트래커(Issue trackers), 브라우저(Browsers), 문서(Docs), 디자인 자산(Design assets), 배포 스크립트(Deployment scripts), 또는 프라이빗 컨텍스트(Private context)를 건드릴 수도 있습니다.

글쓰기 스킬에 숨겨진 가정(Assumption)이 있는 것은 짜증스러운 일입니다.

코드 수정 스킬에 숨겨진 가정이 있는 것은 프로덕션 리스크(Production risk)입니다.

유용한 스킬은 지루할 것이다

나는 마법 같은 스킬보다 좁은 범위의 스킬을 더 신뢰합니다.

"다듬어진 스프레드시트를 생성하고 수식을 검증하라"는 검토 가능합니다.

"모든 비즈니스 분석 작업을 처리하라"는 바닥이 미끄러워지기 시작하는 지점입니다.

최고의 에이전트 스킬(Agent Skills)은 거의 실망스러울 정도로 구체적이어야 합니다. 스킬은 무엇을 위한 것인지, 어떤 입력값(Inputs)을 기대하는지, 어떤 파일을 읽는지, 어떤 스크립트(Scripts)를 실행할 수 있는지, 그리고 권한이 어디서 멈추는지 명시해야 합니다.

이것은 에이전트 방식에 반대하는 것이 아닙니다. 이것이 에이전트 워크플로(Workflows)가 반복 가능해지는 방식입니다.

예를 들어, 어떤 스킬이 크리에이터 워크플로를 패키징한다면, 단순히 "이미지를 정리하라"라고 모호하게 말해서는 안 됩니다. 정확한 단계를 명시해야 합니다. 좁은 범위의 이미지 에셋(Asset) 스킬이라면, Gemini 출력물 정리 작업이 Gemini가 생성한 파일에만 적용된다고 명시하고, Gemini Watermark Cleaner와 같은 브라우저 로컬 옵션을 리소스로 지정하는 동시에, 나머지 워크플로는 에셋 명명, 권리 확인, 내보내기 형식 및 검토에 집중하도록 유지할 수 있습니다. 이러한 범위가 지정된 언급은 에이전트에게 모호한 지침 대신 경계(Boundary)를 제공하기 때문에 유용합니다.

이것이 제가 이러한 것들에 기대하는 표준입니다.

"에이전트가 무엇을 해야 할지 알고 있다"가 아니라,

"에이전트가 인간이 검사할 수 있는 경계가 정해진 절차(Bounded Procedure)를 가지고 있다"여야 합니다.

의존성(Dependencies)을 검토하듯 스킬을 검토하라

소규모 팀은 이를 위해 거버넌스(Governance) 부서까지 필요하지는 않습니다. 스킬 폴더 세 개를 6페이지짜리 프로세스 문서로 만들지 마십시오.

하지만 습관은 필요합니다.

스킬을 설치하거나 작성하기 전에 다음을 질문하십시오:

누가 소유하는가?
어떤 작업을 처리하도록 허용되는가?
어떤 도구, 스크립트 또는 명령어를 트리거(Trigger)할 수 있는가?
어떤 파일이나 리소스를 읽을 것으로 기대하는가?
상태를 변경(Mutate)하는가, 아니면 초안만 생성하는가?
어떤 환경(Environment)을 가정하는가?
소스가 진입할 워크플로에 충분히 신뢰할 수 있는가?
어떻게 업데이트하는가?
더 이상 유용하지 않을 때 어떻게 제거하는가?

의존성 위생(Dependency Hygiene)이 일상적인 일이기 때문에 이 체크리스트는 지루하게 들릴 수 있습니다. 바로 그것이 핵심입니다.

스킬의 실패 모드(Failure Mode)는 처음에는 극적이지 않을 것입니다. 그것은 지루한 표류(Drift)가 될 것입니다.

도움말 스크립트(Helper script)가 오래된 파일 경로를 가정합니다. 팀이 톤(Tone)을 변경한 후에도 스타일 규칙(Style rule)이 남아 있습니다. 권한 경계(Permission boundary)가 더 이상 의미가 없는 새로운 컨텍스트(Context)로 복사됩니다. 하나의 리포지토리(Repo)를 위해 작성된 스킬이 이름이 비슷하다는 이유로 다른 리포지토리에서 재사용됩니다. 리소스 파일(Resource file)이 오래되었지만, 에이전트(Agent)는 여전히 이를 최신 상태로 취급합니다.

이 중 그 어떤 것도 악의적인 스킬을 필요로 하지 않습니다. 일반적인 엔트로피(Entropy)만으로도 충분합니다.

스킬이 작동하기 시작하면 버전 관리(Versioning)가 더 중요해진다

나쁜 스킬은 무시하기 쉽습니다. 하지만 좋은 스킬은 인프라(Infrastructure)가 됩니다.

바로 그때 버전 관리(Versioning)가 중요해지기 시작합니다.

만약 스킬이 에이전트가 풀 리퀘스트(Pull request)를 검토하거나, 문서를 작성하거나, 보고서를 생성하거나, 브라우저 체크(Browser checks)를 실행하는 방식을 변경한다면, 당신은 그 동작이 언제 변했는지 알아야 합니다. 차이점(Diff)은 읽을 수 있어야 합니다. 롤백(Rollback)이 가능해야 합니다. 릴리스 노트(Release note)는 단순히 "지침 업데이트(Updated instructions)"라고 말하는 것이 아니라, 동작의 변화를 설명해야 합니다.

이는 스킬에 실행 가능한 헬퍼(Executable helpers)가 포함될 때 특히 사실입니다. 산문(Prose)을 검토하는 것과 스크립트(Scripts)가 포함된 폴더를 검토하는 것은 별개의 문제입니다. 스킬이 모델에게 무엇을 쓸지 알려주는 것 이상의 일을 할 수 있게 되는 순간, 신뢰의 기준(Trust bar)이 바뀝니다.

스킬을 의존성(Dependencies)으로 취급하는 것은 책임 소재(Blame)를 파악하는 데도 도움이 됩니다.

에이전트가 이상한 행동을 할 때, 그 답이 항상 "모델이 실수했다"일 수는 없습니다. 때로는 모델이 로컬 절차(Local procedure)를 너무 잘 따랐을 수도 있습니다. 때로는 스킬이 너무 광범위했을 수도 있습니다. 때로는 메타데이터(Metadata) 때문에 잘못된 스킬이 선택되었을 수도 있습니다. 때로는 리소스 파일이 오래되었을 수도 있습니다.

만약 스킬에 버전이 매겨져 있고 소유권(Owned)이 명확하다면, 당신은 살펴볼 곳이 생깁니다.

만약 그것이 그저 복사된 프롬프트(Prompt) 텍스트의 더미일 뿐이라면, 행운을 빕니다.

에이전트 스택(Agent stack)은 검사 가능한 형태가 되고 있다

저는 이 방향이 마음에 듭니다. 보이지 않는 프롬프트 이력(Prompt history) 덩어리와 논쟁하는 것보다, 지침(Instructions), 스크립트(Scripts), 리소스(Resources)가 담긴 폴더를 디버깅(Debug)하는 것이 훨씬 낫습니다.

하지만 이는 팀이 해당 폴더들을 검사 가능한(Inspectable) 상태로 유지할 때만 가능합니다.

스킬을 더 크고 인상적으로 만들고 싶은 유혹이 생길 것입니다. 더 많은 규칙, 더 많은 예시, 더 많은 헬퍼(Helpers), 더 많은 예외 케이스(Edge cases), 더 많은 자동화된 동작들 말입니다. 그것이 가치 있을 수도 있지만, 추가되는 모든 기능은 검토 범위(Review surface)를 확장시킵니다.

더 나은 선택은 대개 더 작게 만드는 것입니다:

지속 가능한 워크플로우(Durable workflow)당 하나의 스킬
명확한 메타데이터 (Metadata)
최소한의 권한 (Permissions)
지루한 헬퍼 스크립트 (Helper scripts)
명확한 입력(Inputs)과 출력(Outputs)
검토자가 실제로 읽을 수 있는 소스 파일

에이전트 스킬(Agent skills)은 마법처럼 느껴져서는 안 됩니다. 마법은 운영하기 어렵습니다.

대신, 당신이 벤더링(Vendor)하고, 버전을 고정(Pin)하며, 업데이트하고, 삭제할 의사가 있는 의존성(Dependencies)처럼 느껴져야 합니다.

이것이 기준입니다. 스킬이 기본적으로 위험하기 때문이 아니라, 인간을 둘러싼 빌드 시스템(Build system)의 일부가 될 만큼 충분히 유용하기 때문입니다.

이 패턴의 미래는 "프롬프트 엔지니어링(Prompt engineering)의 종말"이 아닙니다.

그것보다 훨씬 더 단순합니다.

에이전트 작업의 재사용 가능한 부분들은 소프트웨어 아티팩트(Software artifacts)가 되어가고 있습니다. 그것을 아티팩트로서 다루십시오.

출처 노트 (Source notes)