Perplexity에서 에이전트 스킬 설계, 정제 및 유지 관리

Perplexity의 프론티어 에이전트 제품은 모듈식 스킬(Agent Skills)로 패키징된 노하우와 도메인 전문 지식을 기반으로 합니다. 당사는 기술 환경 전반에 걸쳐 엄선된 스킬 라이브러리를 유지 관리합니다. 이러한 스킬에는 Perplexity Computer를 구동하는 다양한 범용 유틸리티, 금융·법률·건강과 같은 분야별 역량, 그리고 사용자 요구를 해결하기 위한 매우 방대한 모듈이 포함됩니다. 일부 스킬은 자주 호출되지는 않지만, 호출될 때 매우 중요합니다. 일관되게 뛰어난 사용자 경험을 보장하기 위해 Perplexity 에이전트 팀은 코드 품질만큼이나 스킬 품질을 중요하게 생각합니다.

고품질 스킬을 개발하는 데 필요한 직관과 모범 사례는 기존 소프트웨어를 구축하는 데 필요한 것과 크게 다릅니다. 에이전트 팀은 업무 과정에서 스킬을 개발하는 우수한 엔지니어들이 작성한 다수의 풀 리퀘스트를 검토합니다. 그 결과는 거의 항상 수많은 의견과 수정 제안으로 이어집니다. 이는 코드를 작성하기 위한 많은 유용한 패턴이 스킬 생성 과정에서는 안티 패턴(antipattern)이 되기 때문입니다.

예를 들어, PEP20 – Python의 선(The Zen of Python)에 나오는 격언 중 일부를 살펴보면, 좋은 Python 코드를 작성하는 것과 좋은 스킬을 작성하는 것은 다르다는 점이 금방 명확해집니다. 20가지 지혜의 문구 중 적어도 절반은 스킬을 작성할 때 완전히 잘못되었거나 적극적으로 오해를 불러일으킬 수 있습니다. 그중 다섯 가지를 소개합니다:

Python의 Zen과 Skills 작성에 대한 문서의 지침 사이의 다섯 가지 대조.

이 가이드는 Perplexity 전반의 엔지니어들이 스킬을 개발하고 검토할 때 사용하는 문서입니다. 당사는 우리의 발견과 학습 내용이 더 넓은 커뮤니티에 도움이 될 수 있도록 이 가이드를 공개합니다. 일상 업무에서 프로덕션 스킬을 설계하는 엔지니어이든, 자신이 가장 잘 아는 분야에서 직접 스킬을 개발하려는 Computer 사용자이든, 혹은 둘 다이든, 이 가이드는 여러분을 위한 것입니다.

스킬이란 무엇인가요?

스킬을 작성할 때는 단순히 평범한 소프트웨어를 작성하는 것이 아닙니다(물론 스킬이 이제 에이전트 시스템을 위한 주요 논리 엔진의 일부이긴 하지만요). 오히려 모델과 그 환경을 위한 컨텍스트를 구축하는 것입니다. 스킬에는 다른 제약 조건과 설계 원칙이 적용됩니다. 코드를 작성하듯이 스킬을 작성하면 실패하게 될 것입니다.

스킬은 최소한 네 가지 요소로 구성되며, 특히 Perplexity에서 이를 구축하는 방식의 맥락에서 더욱 그렇습니다.

스킬은 디렉토리입니다

스킬은 단순히 단일 SKILL.md 파일이 아닙니다. 많은 경우 스킬에는 여러 파일이 포함됩니다. 스킬 이름으로 된 디렉토리 아래에는 다음과 같은 항목이 있을 수 있습니다:

SKILL.md: 프런트매터(frontmatter) 및 지침

scripts/: 에이전트가 실행하는 코드(재구현하지 않음)

references/: 무거운 문서, 조건부 로드

assets/: 템플릿, 스키마 및 데이터

config.json: 초기 사용자 설정

이러한 허브 앤 스포크(hub-and-spoke) 패턴을 사용하면 스킬을 매우 집중적이고 긴밀하게 유지할 수 있으며, 폴더 구조를 매우 창의적인 방식으로 활용할 수 있습니다. 때로는 특히 복잡한 스킬의 경우 모델이 더 잘 탐색할 수 있도록 계층 구조의 여러 레벨을 활용하는 것이 유리합니다. 예를 들어 스킬이 300개의 주제에 걸친 지식을 필요로 하고 이를 20개의 주제 영역으로 그룹화할 수 있다고 가정해 봅시다. 300개 중에서 올바른 주제를 안정적으로 선택하는 것은 오늘날 최고의 프론티어 모델에게도 미해결 과제입니다. 모델 입장에서는 300개 중 하나를 선택하는 것보다 20개 영역 중 하나로 좁힌 다음 해당 영역 내의 15개 주제 중에서 선택하는 것이 훨씬 더 쉬운 선택 문제입니다.

다단계 계층 구조가 어떻게 가치를 제공하는지에 대한 한 예로, 우리 팀은 지난 세금 시즌 동안 Computer의 미국 소득세 기능을 구동하는 스킬 내에 3단계의 주제별 중첩 구조를 적용했습니다. 세법의 복잡성을 고려할 때 이 계층 구조는 절대적으로 필수적이었습니다. 초기 테스트에서 미국 연방 세법(U.S. Internal Revenue Code)의 1,945개 조항 전체가 포함된 단일 폴더를 모델에 제공했을 때는 스킬을 전혀 로드하지 않았을 때보다 성능이 더 낮게 나왔습니다. 정보를 논리적인 하위 부서로 구성하는 것은 고정밀 읽기 작업을 보장하는 데 필수적이었습니다.

하지만 이 계층 구조가 무료로 얻어지는 것은 아니었습니다. 계층 수준이 높아질수록 결과적으로 발생하는 간접 참조를 관리하기 위해 정보 아키텍처 전반에서 더 많은 큐레이션 작업이 필요했습니다. 우리는 모델이 최소한의 간접 참조로 정보를 찾을 수 있도록 지원하기 위해 빠른 참조 가이드, 맞춤형 검색 유틸리티 및 기타 도구를 고안했습니다. 이 경우 큐레이션이라는 힘든 작업을 수행한 결과, 모델이 일반 도구만 사용할 때보다 세금 관련 작업을 훨씬 더 유능하게 수행할 수 있는 스킬이라는 긍정적인 성과를 얻었습니다.

확대

스킬은 포맷입니다

스킬은 포맷입니다. 핵심 루트 파일인 SKILL.md에는 이름과 설명이 모두 있어야 합니다. 또한, 스킬은 스킬이 위치한 디렉토리 이름과 정확히 매핑되어야 합니다. 이름은 모두 소문자여야 하며, 스페이스(공백)를 포함할 수 없고 하이픈은 사용할 수 있습니다. 설명은 라우팅 트리거입니다. 이것은 흔히 발생하는 실패 지점인데, 설명은 스킬이 무엇을 하는지에 대한 내부 문서가 아닙니다. 이는 모델에게 언제 스킬을 로드해야 하는지에 대한 지침을 제공하는 것입니다. 따라서 “이 스킬은 ~을 합니다”가 아닌 “~할 때 로드”라는 표현을 자주 볼 수 있습니다. 이는 대부분의 구현 방식이 설명을 모델 컨텍스트에 주입하는 방식 때문에 중요합니다.

프런트매터 내에는 계층적 스킬 의존성을 생성할 수 있는 “depends:”와 리뷰 및 평가에 사용되는 “metadata:”도 있습니다. 서로 다른 에이전트 시스템은 해당 시스템에 특화된 방식으로 사용할 자신만의 프런트매터 필드를 정의할 수도 있습니다. 대안으로, 스킬별 메타데이터를 보조 JSON 또는 YAML 구성 파일에 패키징할 수 있습니다. 이는 사소한 세부 정보로 모델의 컨텍스트를 오염시키지 않으면서 스킬별로 다양한 유형의 런타임 동작을 지원해야 하는 에이전트 시스템을 구축할 때 바람직합니다. 마지막으로, 읽기 시 스킬 프런트매터를 제거함으로써 유사한 동작을 얻을 수 있습니다. Computer는 이 방법을 사용하며, 이를 통해 루트 SKILL.md 파일에 구성을 보존할 수 있습니다. 파싱 로직에 세심한 주의가 필요하며, 모델 컨텍스트 내에서 유용한 특정 필드가 있는 경우 조건부 제거를 구현하는 것이 좋습니다.

스킬은 호출 가능합니다

스킬은 호출 가능합니다. 에이전트는 런타임에 스킬을 로드합니다. 중요한 점은 스킬이 항상 컨텍스트에 번들로 포함되지는 않는다는 것입니다. 기본적으로 대부분의 에이전트 시스템은 필요에 따라 스킬을 점진적으로 펼칩니다.

Computer에서 스킬을 구현한 방식에는 최소 3단계의 컨텍스트 비용이 있습니다. 과정은 다음과 같습니다:

Computer가 load_skill(name="...")을 호출합니다

Computer가 스킬 디렉토리를 격리된 실행 샌드박스로 복사합니다

Computer가 “depends:” 태그에 있는 의존성을 재귀적으로 자동 로드합니다

Computer가 프런트매터를 제거하고, 에이전트는 본문과 추가 파일만 보게 됩니다

서로 다른 에이전트 시스템은 스킬 콘텐츠를 노출하는 방식을 다르게 선택할 수 있습니다. 예를 들어, 일부 시스템은 파일 계층 구조를 전혀 노출하지 않고 모델이 파일 시스템 작업을 통해 계층 구조를 발견하도록 할 수 있습니다. 다른 시스템은 특정 자르기(truncation) 및/또는 깊이 제한까지 전체 파일 트리의 매핑을 모델에 제공하도록 선택할 수 있습니다. 컨텍스트를 깔끔하게 유지하기 위해 Computer는 호출 컨텍스트에서 전체 파일 계층 구조를 생략하지만, 이는 스킬별로 재정의할 수 있습니다.

스킬은 점진적입니다

스킬은 점진적입니다. Computer에는 3가지 서로 다른 단계의 컨텍스트 비용이 있으며, 다양한 단계에서 이 세 가지 비용이 모두 발생합니다:

Skill 컨텍스트의 세 가지 계층: 인덱스, 전체 Skill 로드, 그리고 런타임 참조 파일.

Computer는 사용 가능한 모든 스킬의 이름과 설명이 포함된 스킬 인덱스를 구축합니다. 이에 대한 예산은 스킬당 약 100 토큰입니다(짧을수록 더 좋습니다). 모든 세션에서 모든 사용자에 대해 이 비용을 지불하기 때문에 매우 엄격합니다. 이것은 대화 시작 시 시스템 프롬프트에 주입됩니다. 모델은 “load_skill()”을 호출할지 결정할 수 있도록 여러 이름 지정된 스킬과 설명에 액세스할 수 있습니다. 이 인덱스에 들어가기 위한 문턱은 매우 높습니다. 스킬은 매우 유용해야 하며, 모두가 항상 비용을 지불해야 하므로 설명은 매우 간결하고 핵심적이어야 합니다.

에이전트 시스템이 스킬을 로드한 후에는 전체 SKILL.md 본문이 있습니다. 이상적으로 본문 텍스트는 5,000 토큰을 초과하지 않아야 합니다. 그렇다 하더라도, 스킬을 로드하면 압축 경계(compaction boundary)에 도달할 때까지 남은 대화가 그 비용을 지불해야 하므로 모든 문장이 중요하게 여겨지길 원할 것입니다. 많은 스레드가 3개에서 5개의 서로 다른 스킬을 로드하며 이 비용을 곱합니다. 불필요한 내용이 많은 스킬은 다른 스킬은 물론 전반적인 에이전트 기능을 확실히 저하시킬 것입니다. 요컨대, 스킬이 로드되었는데 올바른 작업을 수행하지 않는다면, 그것은 낭비된 컨텍스트입니다.

진화의 마지막 단계는 서브스킬이나 서스메팅과 같은 스크립트 또는 특수 사례입니다. 이곳은 무제한 조건부 분기 로직을 넣고 싶은 곳입니다. 에이전트는 필요할 때만 이를 사용하므로, 여기에 넣을 내용에 대한 기준은 훨씬 낮습니다.

인덱스에서는 모든 토큰이 중요합니다. 로드된 스킬 본문은 좀 더 여유가 있으며, 런타임은 가장 여유가 있습니다. 여기에는 20,000 토큰이 될 수도, 0 토큰이 될 수도 있습니다. 이것은 모델의 컨텍스트를 점진적인 방식으로 확장하는 것을 고려할 수 있는 단계입니다.

스킬이 언제 필요한가요?

에이전트 팀은 특정 도메인이나 사용 사례에 스킬이 정말 필요한지에 대한 의견을 자주 요청받습니다. 첫 번째 원칙만으로 명확한 답을 얻는 경우는 거의 없습니다. 이를 확실히 파악하는 유일한 방법은 스킬 없이 에이전트를 시작하고, 몇 가지 주요 쿼리를 실행한 다음, 에이전트가 작업을 잘 수행하고 있는지 파악하는 것입니다.

스킬이 필요할 때

학습된 모델의 배포(distribution) 내에 있는 작업은 많습니다. 스킬을 적용해야 하는 경우는, 프롬프트에서 한 문장으로는 할 수 없는 특정 방식으로 해당 동작을 변경하려는 경우뿐입니다. 따라서 에이전트가 특수한 컨텍스트 없이는 잘못 수행할 가능성이 있거나, 실행 전반에 걸쳐 극도로 일관성을 유지해야 하는 불일치 또는 비결정성이 있는 경우 스킬이 필요합니다.

지식은 내구성이 있지만 학습 데이터에는 포함되어 있지 않을 수 있습니다. 컷오프(cutoffs)나 기업별 워크플로우가 있을 수도 있고, 취향 문제일 수도 있습니다. 예를 들어, Computer에는 Henry Modisett(디자인 총괄)가 작성한 디자인 관련 스킬이 여러 개 있습니다. 해당 스킬의 모든 토큰이 존재하는 이유는 웹사이트와 PDF를 디자인할 때 Henry가 매우 좋은 안목을 가지고 있기 때문입니다. Henry는 어떤 폰트를 사용하고 어떤 폰트를 사용하지 말아야 할지, 그 폰트들이 어떤 느낌을 주는지, 그리고 학습 데이터만으로는 모델이 배울 수 없는 다른 판단 문제들을 지정합니다.

스킬이 필요하지 않을 때

우리는 엔지니어가 순서대로 실행되어야 하는 일련의 git 명령어를 작성한 스킬을 많이 봅니다. 모델은 이미 그 방법을 알고 있기 때문에 불필요한 일이며, 이는 훌륭한 문서는 될 수 있지만 형편없는 스킬이 됩니다.

우리는 스킬이 시스템 프롬프트의 지침을 되풀이하는 사례를 봅니다. 그런 경우 스킬은 필요하지 않습니다. 대부분의 요청과 관련된 지식은 조건부로 로드되는 스킬이 아니라 전역 컨텍스트에 포함되어야 합니다.

유지 관리할 수 있는 것보다 더 빨리 변하는 것이 있다면 스킬이 필요하지 않습니다. 예를 들어, 원격 MCP 엔드포인트를 호출하는데 해당 도구나 도구 버전이 자주 변경된다면, 그것들을 스킬에 주입해서는 안 됩니다. 그렇게 하면 결국 드리프트(drift)가 발생하고 모델은 실수를 하게 될 것입니다.

모든 스킬은 비용입니다

스킬의 모든 문장에 적용할 수 있는 유용한 테스트가 있습니다: “이 지침 없이는 에이전트가 잘못 수행할 것인가?” 문장이 꼭 필요하지 않다면, 매번 모든 사람이 비용을 지불하고 있으므로 그 비용을 감당할 수 없습니다. 스킬 추가 여부를 결정할 때, 모든 세션과 모든 사용자가 토큰 비용을 지불한다는 이 비용을 기억하십시오.

다음의 유명한 인용문은 프랑스어로는 훨씬 더 잘 들리는데, 대략 “내가 이 편지를 길게 쓴 이유는 짧게 쓸 시간이 없었기 때문이다”로 번역됩니다.

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Pascal과 마찬가지로 여러분도 모든 스킬에 시간을 투자해야 합니다. 짧은 스킬을 쓰는 것은 어렵습니다. 스킬을 쓰기 쉽다면 아마 너무 길거나 애초에 존재하지 말아야 할 것입니다. 좋은 스킬은 가능한 한 짧습니다.

만약 스킬 생성을 한 번에 끝내려고 하거나 5분 만에 PR(풀 리퀘스트)을 올리려 한다면, 결과는 거의 확실히 미흡할 것입니다. 사실, 초기 연구에 따르면 결과적으로 LLM을 사용하여 스킬을 작성하면 LLM은 아마도 그로부터 혜택을 받지 못할 것입니다: “스스로 생성한 스킬은 평균적으로 아무런 이점을 제공하지 않으며, 이는 모델이 자신이 소비하여 얻는 절차적 지식을 안정적으로 작성할 수 없음을 보여줍니다.”

스킬 구축 방법

다른 말로 하면, 여러분이 작성하는 모든 스킬에 여러분의 의견을 주입해야 합니다. 다음 단계를 따르십시오.

0단계: 평가(Evals) 작성

평가를 먼저 작성하십시오. 평가 사례는 다음에서 가져올 수 있습니다:

실제 사용자 쿼리: 프로덕션 또는 신뢰할 수 있는 소스에서 샘플링

알려진 실패: 스킬이 존재하지 않아 에이전트가 실패한 경우

인접 혼동: 도메인 경계 근처에 있지만 다른 스킬로 라우팅되는 경우

최소한 스킬이 필요할 때 로드되는지 테스트하고 있는지 확인해야 합니다. 이상적으로는 프로덕션 환경 등에서 일부 샘플을 가져옵니다. 또한 알려진 오류 사례를 고려할 수도 있습니다. 스킬 작성을 시작한 전체 이유가 발견한 특정 실패 때문일 수도 있고, 리팩토링 중인데 하나의 스킬로 다루어지는 두 개의 가까운 도메인 간에 혼동이 있을 수도 있습니다.

유사한 부정적 예시와 긍정적 예시로 시작하십시오. 부정적 예시는 매우 강력하며 긍정적 예시보다 더 중요할 수 있습니다.

1단계: 설명(Description)

이것은 스킬에서 가장 어려운 문장입니다. 이것은 문서가 아니라 라우팅 트리거입니다. 이름과 설명을 올바르게 작성하려면 스킬의 콘텐츠는 신경 쓰지 마십시오. 오직 스킬이 올바른 지점에서 로드되고 주입되는지, 그리고 가장 큰 실패 모드인 타겟 이외의 부작용이 없는지만 신경 쓰십시오. 스킬을 추가할 때마다 다른 모든 스킬을 조금 더 나쁘게 만들 위험이 있으므로, 회귀(regression)를 최소화해야 합니다.

다시 말하지만, 나쁜 설명은 스킬이 무엇을 하는지 또는 왜 유용한지를 설명합니다. 좋은 설명은 에이전트가 언제 스킬을 로드해야 하는지를 말합니다. 예를 들어, 풀 리퀘스트를 모니터링하는 것이 있다고 가정해 봅시다. 스킬이 무엇을 하는지 쓰지 마십시오. 엔지니어가 좌절감을 느낄 때 하는 말, 즉 “babysit”, “watch CI”, “make sure this lands”처럼 PR이 작동하도록 확실히 하고 싶을 때 사용하는 말을 쓰십시오.

간단한 체크리스트입니다:

"Load when..."으로 시작

50단어 이하 목표

사용자의 의도를 설명(이상적으로는 실제 쿼리에서)

워크플로우를 요약하지 않음

실제 쿼리는 80-20 규칙으로 커버할 수 있는 것입니다. 보통 두세 개의 예시가 잘 작동합니다. 필요한 만큼만 정확하게 추가하는 것은 쉽지 않습니다.

2단계: 본문(Body) 작성

다음으로 스킬 자체의 콘텐츠를 작성하십시오. 이것은 0단계나 1단계가 아니라는 점에 유의하십시오.

워크플로우를 LLM에 전달하는 것은 동료나 런타임 시스템에 전달하는 것과는 완전히 다릅니다. 새로운 소프트웨어 도구를 배울 때 엔지니어는 문서를 읽고, 경험자로부터 연습을 받고, 도구 사용법을 배워야 할 수도 있습니다. 반면, 적어도 1년 정도 된 거의 모든 소프트웨어 도구의 경우, 이름만 언급하면 LLM은 필요한 모든 정보를 갖게 됩니다.

본문을 작성할 때는 명백한 것은 생략하십시오. 많은 엔지니어가 누군가 실행해야 할 모든 명령어를 나열하는 readme.md 파일을 작성한 경험이 많습니다. 스킬을 작성할 때 문서 작성을 하는 것처럼 느껴지기 때문에 그 습관으로 돌아가기 쉽지만, 그렇게 하면 스킬은 쓰레기가 될 것입니다. 그러니 일련의 명령어를 나열하지 마십시오.

예를 들어, “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”이라고 작성할 필요는 없습니다.

대신, “Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.”라고 작성하십시오.

모델은 너무 규범적인 명령어 나열보다는 후자의 경우 훨씬 더 잘 수행할 것이며, 특히 문제가 발생했을 때 그렇습니다. 취약한 규범을 강요하거나 지나치게 규범적이지 말고, 여러 접근 방식이 작동할 수 있도록 유연성을 가지십시오. 다시 말하지만, 인간을 위한 좋은 문서는 모델에게는 대부분 나쁜 문서입니다.

다음으로, 잠재적 문제(gotchas)나 부정적 예시에 집중하십시오. 이것들은 모델에게 하지 말아야 할 일을 안내하는 경우가 많으므로 매우 높은 신호를 담은 콘텐츠입니다. 에이전트가 실수할 때마다 한 줄씩 추가하면 실행하면서 배우게 되고 잠재적 문제는 유기적으로 성장할 것입니다.

마지막으로, 조건부이거나 콘텐츠가 매우 무거운 부분이 있다면 허브인 SKILL.md에서 빼내어 스포크 중 하나에 넣으십시오. 점진적으로 로드될 수 있는 액세서리 파일에 넣으십시오. 이에 대해서는 다음에 자세히 다루겠습니다.

3단계: 계층 구조(Hierarchy) 사용

스크립트, 참조 문서가 있거나 특정 도구를 사용할 때는 스킬 계층 구조를 활용하십시오:

Skill 내에서 스크립트, 참조 자료, 자산, 구성의 권장 용도.

주 스킬에서 조건부이거나 분기되는 모든 것은 폴더로 분리하십시오. 또한, 다단계 계층 구조는 특히 복잡한 스킬에 사용될 수 있다는 점을 기억하십시오. 이러한 경우, 기능을 모놀리식으로 구현할지 아니면 스킬 컬렉션으로 구현할지(아마도 depends: 기반 로딩 관계를 통해) 신중하게 고려해야 합니다.

4단계: 반복(Iterate)

다음으로 브랜치에서 여러 번 반복하십시오. 메인 브랜치에서 스킬 없이 시작하고, 몇 번 반복하고, 히어로 쿼리 세트를 구축하고, 평가 세트를 실행하십시오. 스킬 코드를 검토하는 사람은 평가 세트가 포함된 단일 변경 사항을 제출해 준 것에 대해 감사할 것입니다. 연속적인 점진적 변경(새로운 잠재적 문제를 제외하고)을 검토하는 것은 매우 어려우므로 최소화하도록 노력하십시오.

아마도 많은 작은 단어 변경을 하게 될 것입니다. 설명에서 작은 단어 변경은 라우팅(다른 스킬에 미치는 영향 포함)에 엄청난 영향을 미칠 수 있으므로 5단계 이전에 모든 작업을 수행하십시오.

5단계: 배포(Ship)

배포하십시오.

스킬 유지 관리 방법

스킬을 작성했으니 이제 유지 관리해야 합니다.

잠재적 문제(Gotchas) 플라이휠

이 시점부터 잠재적 문제 목록은 크게 늘어나거나 변하는 경향이 있습니다. 예를 들어, 평가되지 않은 PR을 만들고 설명을 변경하는 엔지니어를 종종 봅니다. 스킬이 병합된 후 설명을 변경하고 있다면 잘못된 길로 가고 있는 것입니다. 스킬 라우팅 여부를 결정하는 것을 변경하려면 해당 변경을 지원하는 평가를 작성해야 합니다.

스킬은 추가 위주(append-mostly)입니다. 잠재적 문제 섹션이 시간이 지남에 따라 가장 많은 가치를 축적합니다:

에이전트가 어떤 작업에서 실패함 → 잠재적 문제 추가

에이전트가 타겟이 아닌 스킬을 로드함 → 설명을 강화하고 부정적 평가 추가

에이전트가 필요할 때 스킬을 로드하지 않음 → 키워드 및 긍정적 평가 추가

시스템 프롬프트 변경 → 충돌이나 중복 확인

내부 테스트나 프로덕션에서 단일 실패 사례를 발견하고 잠재적 문제를 추가하는 것은 쉽습니다. 이것은 부정적 예시이므로 명시적 지침을 실제로 바꾸는 것은 아니지만, 모델에게 “헤이, 이런 알려진 실패가 있어”라고 알려줍니다.

80-20에서 99.9% 또는 99.99% 성공률로 이동함에 따라 이 잠재적 문제 목록을 늘리는 것은 쉽습니다. 이러한 부정적 예시를 보면 잠재적 문제 섹션에 주로 추가해야 합니다. 더 긴 지침을 추가하거나 설명을 변경해서는 안 됩니다.

평가 제품군(Eval Suites)

Perplexity에서는 서로 다른 것을 확인하기 위해 많은 평가 제품군을 실행합니다. 스킬 로딩 및 스킬 파일 읽기가 있는데, 이는 스킬 로딩 자체의 정밀도, 재현율, 금지 확인을 검사합니다. 에이전트가 필요할 때 스킬을 라우팅할까요? 이것들은 새 스킬이 기존 경계를 깨뜨리지 않도록 보장합니다.

적절한 점진적 로딩을 확인할 수 있는 평가도 있습니다. 에이전트가 스킬을 로드할 수 있지만, 액세서리 파일이나 파일들을 읽을까요? 예를 들어, 금융 쿼리를 위한 금융 스킬이 있는 경우, 특별한 FORMATTING.md 파일을 읽을까요?

도메인 내 엔드 투 엔드 작업 완료를 테스트하는 스킬에 대한 평가도 있습니다. 우리는 전체 에이전트 루프를 실행하고 LLM 심사위원을 사용하여 잘 정의된 기준 루브릭을 기반으로 결과를 평가합니다.

마지막으로, 이러한 평가를 다양한 모델에 대해 실행하는 것이 중요합니다. Computer는 GPT, Claude Opus, Claude Sonnet 등 최소 세 가지 오케스트레이션 모델 제품군을 지원합니다. 다른 동작이 발생하지 않도록 이러한 다양한 에이전트 오케스트레이터에 대해 스킬 로딩과 도메인 스킬을 실행해야 합니다. Sonnet과 GPT는 스킬과 관련하여 상당히 다르게 동작합니다.

최종 생각 및 요약

스킬을 더 많이 구축할수록 스킬 구축에 능숙해질 것입니다. 스킬을 사용하여 일상적으로 수행하는 작업을 자동화하거나 더 재현 가능하게 만들려고 노력하지 않는다면 즉시 시작하십시오.

스킬을 구축하는 행위는 더 많은 스킬을 구축하는 능력을 향상시키지만, 또한 비즈니스 프로세스를 자동화하는 데 매우 유용합니다. 매주 스탠드업 전, 스프린트 종료 시, 또는 엔지니어로서 일간, 주간, 심지어 분기별로 수행하는 모든 작업을 설명할 수 있다면, 시간을 벌기 위해 스킬을 작성해야 합니다.

포스트모템(postmortems)을 자동화할 수 있나요? 풀 리퀘스트를 검토할 수 있나요? 여러분이 할 수 있는 어떤 작업이든, 적어도 첫 번째 패스는 에이전트 스킬로 만들 수 있습니다. 상당한 시간을 절약해 줄 것입니다.

그렇긴 하지만 스킬이 쉽거나 항상 필요한 것은 아니라는 점을 기억하십시오. 적은 것이 더 많습니다(Less is more). 몇 가지 다른 요약입니다:

스킬 전에 평가를 작성하십시오. 인접하지만 구별되는 스킬에 대한 부정적 예시와 금지된 로드를 포함하십시오.

설명이 어려운 부분입니다. "Load when..." (모든 단어가 주의를 요합니다).

잠재적 문제는 매우 가치가 높은 콘텐츠입니다. 얇게 시작하고 에이전트가 실패함에 따라 성장시키십시오.

건드리지 않았더라도 새 스킬을 추가함으로써 기존의 다른 스킬을 깨뜨리기 쉽다는 점을 기억하십시오(원격 작동에 주의하십시오).

스킬을 작성하고 유지 관리할 때마다 모든 가용 도구를 사용하십시오. 더 배우고 싶다면 Agent Skills 웹사이트에 좋은 예시가 많이 있으며, 내부 리포지토리와 공개 생태계 모두 잘 설계된 스킬의 예시를 많이 포함하고 있습니다.

인용

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}