좋은 스킬의 해부도

문제 상황: 스킬은 저장된 프롬프트가 아니다

많은 사람이 처음 스킬을 만들 때 자주 하는 실수는 긴 프롬프트를 하나 저장해 두고 그것을 스킬이라고 부르는 것이다. 물론 반복해서 쓰는 지시문을 저장하는 것만으로도 어느 정도 효과는 있다. 하지만 그것만으로는 에이전트가 언제 이 스킬을 써야 하는지, 무엇을 입력으로 받아야 하는지, 어디까지 처리해야 하는지 판단하기 어렵다.

좋은 스킬은 "무엇을 하라"는 문장이 아니라 "이런 상황에서는 이렇게 판단하고, 이런 절차로 처리하며, 이런 형태의 결과물을 내라"는 실행 단위다. 사람이 매번 설명하던 업무 기준을 에이전트가 재사용할 수 있는 형태로 압축한 것이다.

예를 들어 "자료를 조사해 줘"라는 프롬프트는 스킬이 되기 어렵다. 반면 "신규 시장 진입 여부를 판단하기 위해 5개 이하의 신뢰 가능한 자료를 찾고, 시장 규모·경쟁자·진입 장벽·불확실성을 1쪽 브리핑으로 정리하라"는 지시는 스킬에 가깝다. 목적, 입력, 절차, 출력, 판단 기준이 들어 있기 때문이다.

좋은 스킬을 만들려면 먼저 좋은 스킬을 같은 기준으로 읽을 수 있어야 한다. 이 장에서는 모든 스킬을 해부할 때 사용할 공통 설계 카드를 만든다.

AI 생성 이미지

스킬 설계 카드의 9가지 구성 요소

스킬은 다음 9가지 요소로 정리할 수 있다. 모든 항목을 길게 쓸 필요는 없다. 중요한 것은 에이전트가 실행 중에 헷갈리지 않을 만큼 구체적이어야 한다는 점이다.

이 카드는 Claude Code, Codex, Gemini CLI, Manus 같은 도구에서 모두 적용할 수 있다. 플랫폼마다 스킬을 저장하는 방식은 다르지만, 좋은 실행 단위가 가져야 할 정보는 크게 다르지 않다.

중요한 점은 스킬 카드가 에이전트를 통제하기 위한 문서라는 것이다. 사람이 원하는 결과를 머릿속에만 갖고 있으면 에이전트는 매번 추측한다. 반대로 목적과 조건, 출력 형식과 검증 기준이 명확하면 에이전트는 반복 작업을 더 안정적으로 수행한다.

트리거: 너무 넓어도, 너무 좁아도 실패한다

트리거는 에이전트가 "지금 이 스킬을 써야 한다"고 판단하는 조건이다. 트리거가 넓으면 엉뚱한 순간에 스킬이 실행된다. 트리거가 좁으면 필요한 순간에도 스킬이 사용되지 않는다.

예를 들어 "문서를 작성할 때 사용한다"는 트리거는 너무 넓다. 이메일, 보고서, 블로그 글, 계약서 초안, 회의록까지 모두 문서다. 이 트리거를 가진 스킬은 거의 모든 글쓰기 상황에 끼어들 수 있다. 결과적으로 사용자가 간단한 메모를 원했는데 긴 보고서 구조를 제안하거나, 창의적인 초안을 원했는데 검토 체크리스트부터 실행할 수 있다.

반대로 "B2B SaaS 기업의 2026년 2분기 한국어 투자자 대상 월간 성과 보고서를 작성할 때만 사용한다"는 트리거는 너무 좁다. 품질은 좋아 보이지만 재사용성이 떨어진다. 조건이 조금만 달라져도 에이전트는 이 스킬을 쓰지 못한다.

좋은 트리거는 상황을 충분히 구분하되, 재사용 가능한 범위를 남긴다.

트리거를 쓸 때는 키워드만 나열하지 말고 의도를 함께 적는 편이 좋다. "보고서"라는 단어보다 "의사결정자가 현재 상태와 다음 행동을 판단해야 하는 상황"이 더 정확한 조건이 될 수 있다. 여기에 필요한 산출물까지 붙이면 더 안정적이다. 예를 들어 "정량 지표를 근거로 결론, 리스크, 다음 행동을 포함한 브리핑이 필요할 때"처럼 쓰면 에이전트가 단순한 글쓰기 요청과 의사결정용 보고 요청을 구분하기 쉬워진다.

입력값: 에이전트가 물어봐야 할 것과 추론해도 되는 것

스킬의 입력값은 에이전트가 작업 전에 반드시 알아야 하는 정보다. 입력값이 부족하면 에이전트는 두 가지 중 하나를 선택한다. 사용자의 의도를 추측하거나, 계속 질문한다. 둘 다 과하면 좋지 않다.

입력값은 세 가지로 나누어 정리하면 쉽다.

첫째, 필수 입력값이다. 이것이 없으면 작업을 시작하면 안 된다. 예를 들어 "경쟁사 가격 비교 브리핑" 스킬에서는 기준 제품, 비교 대상, 지역이 필수 입력값이다.

둘째, 선택 입력값이다. 있으면 품질이 좋아지지만 없어도 진행 가능한 정보다. 예를 들어 기간, 선호하는 출처, 제외할 브랜드, 보고서 분량이 여기에 해당한다.

셋째, 에이전트가 합리적으로 추론해도 되는 값이다. 예를 들어 사용자가 한국어로 요청했고 대상 시장을 따로 말하지 않았다면, 기본 시장을 한국으로 가정할 수 있다. 다만 추론한 값은 결과물에 표시해야 한다. "지역 정보가 없어 한국 시장 기준으로 정리했습니다"처럼 밝혀야 한다.

좋은 스킬은 입력값을 무조건 많이 요구하지 않는다. 대신 "없으면 위험한 정보"와 "없어도 임시 가정이 가능한 정보"를 구분한다. 이 구분이 있어야 에이전트가 작업을 멈출지, 질문할지, 가정하고 진행할지 판단할 수 있다.

스킬 안에 넣을 지식과 밖에 둘 지식

스킬을 만들다 보면 모든 배경지식을 스킬 안에 넣고 싶어진다. 하지만 스킬에 지식이 너무 많이 들어가면 관리가 어려워진다. 오래된 기준이 남고, 수정해야 할 곳이 늘어나며, 특정 상황에만 맞는 스킬이 된다.

스킬 안에 넣을 지식은 자주 바뀌지 않고, 판단 방식에 직접 영향을 주는 기준이어야 한다. 예를 들어 "고객 인터뷰 요약 스킬"이라면 다음 지식은 스킬 안에 넣을 수 있다.

• 발화는 사실과 해석을 구분한다.

• 고객의 불만은 기능 요청, 사용 맥락, 감정 표현으로 나눈다.

• 한 명의 의견을 전체 고객의 의견처럼 일반화하지 않는다.

이런 기준은 시간이 지나도 크게 바뀌지 않고, 결과 품질에 직접 영향을 준다.

반대로 자주 바뀌는 정보는 외부 문서, 데이터베이스, 검색, 툴 호출로 남기는 편이 좋다. 가격, 최신 정책, 법률, 제품 사양, 경쟁사 기능, 조직도, 캠페인 일정이 대표적이다. 이런 정보는 스킬 안에 고정하면 금방 낡는다.

간단한 기준은 다음과 같다.

스킬은 모든 지식을 담는 창고가 아니다. 에이전트가 어떤 지식을 찾아야 하고, 찾은 지식을 어떻게 판단해야 하는지 알려 주는 실행 기준에 가깝다.

완료 조건: "좋은 결과"가 아니라 확인 가능한 목록으로 쓴다

스킬의 마지막에는 완료 조건이 있어야 한다. 완료 조건은 작업이 언제 끝났는지를 판단하는 기준이다. 많은 사람이 "좋은 품질로 작성한다", "명확하게 정리한다", "실무에 바로 쓸 수 있게 만든다"처럼 쓴다. 하지만 이런 문장은 검토하기 어렵다.

완료 조건은 체크리스트와 산출물 형식으로 써야 한다.

나쁜 완료 조건:

• 좋은 보고서를 작성한다.

• 사용자가 이해하기 쉽게 정리한다.

• 필요한 내용을 빠짐없이 포함한다.

좋은 완료 조건:

• 첫 문단에 결론을 2문장 이내로 제시한다.

• 비교표에는 대상, 가격, 기준일, 출처, 확인 불가 항목을 포함한다.

• 추정한 내용은 "추정"으로 표시한다.

• 출처가 없는 핵심 수치는 단정하지 않는다.

• 마지막에 추가 확인이 필요한 질문을 최대 3개 제시한다.

완료 조건이 구체적이면 사람도 검토하기 쉽고, 에이전트도 자기 점검을 하기 쉽다. 특히 여러 사람이 같은 스킬을 사용할 때 효과가 크다. 결과물이 마음에 드는지 아닌지를 감각으로 판단하는 대신, 체크리스트로 개선할 수 있기 때문이다.

좋은 예: 경쟁사 가격 비교 브리핑 스킬

아래는 하나의 스킬을 설계 카드로 정리한 예다. 실제 운영에서는 더 짧게 써도 되지만, 처음에는 이 정도로 분해해 보는 것이 좋다.

이 스킬의 핵심은 가격 정보를 찾는 능력이 아니라 비교 가능한 상태로 정리하는 능력이다. 가격은 검색이나 외부 문서에서 가져올 수 있다. 하지만 서로 다른 요금제, 할인 조건, 사용량 기준을 어떻게 비교할지는 스킬 안에 기준으로 들어가야 한다.

변형 아이디어: 같은 구조, 다른 업무

하나의 잘 만든 스킬 구조는 여러 업무로 변형할 수 있다. "경쟁사 가격 비교 브리핑"의 구조를 바꾸면 다음과 같은 스킬이 된다.

• 채용 후보자 비교 브리핑: 후보자의 경험, 강점, 우려점, 확인 질문을 표로 정리한다.

• SaaS 기능 비교 브리핑: 기능 지원 여부, 제한 조건, 가격 플랜, 도입 리스크를 비교한다.

• 교육 과정 비교 브리핑: 커리큘럼, 대상자, 기간, 비용, 실습 비중을 비교한다.

• 툴 도입 검토 브리핑: 기능, 보안, 연동성, 비용, 운영 부담을 비교한다.

변형할 때 바뀌는 것은 도메인 지식과 출력 항목이다. 유지되는 것은 구조다. 비교 대상이 있고, 판단 목적이 있으며, 자료의 신뢰도를 확인하고, 비교 기준을 맞춘 뒤, 결정에 필요한 해석을 붙인다. 좋은 스킬은 이렇게 다른 업무로 옮겨도 뼈대가 살아 있다.

실패 패턴: 스킬을 망치는 네 가지 방식

첫째, 이름만 멋지고 실행 기준이 없는 스킬이다. "전략 분석가", "문서 마스터", "리서치 전문가" 같은 이름은 역할을 상상하게 만들지만 실제 실행 조건을 알려 주지는 않는다. 이름은 짧아도 되지만, 목적과 출력 형식은 구체적이어야 한다.

둘째, 트리거가 업무 범위를 삼켜 버리는 스킬이다. "분석이 필요할 때 사용" 같은 조건은 너무 넓다. 이 경우 에이전트는 거의 모든 상황을 분석 문제로 해석할 수 있다. 트리거에는 작업 유형뿐 아니라 사용자의 의도와 필요한 산출물을 함께 넣어야 한다.

셋째, 스킬 안에 최신 정보를 고정해 두는 방식이다. 가격표, 정책, 법률, 제품 기능처럼 자주 바뀌는 내용은 스킬에 박아 두면 곧 오류가 된다. 스킬에는 "어디서 확인하고, 어떻게 표시하고, 무엇을 단정하지 말아야 하는가"를 넣는 편이 안전하다.

넷째, 완료 조건을 감상적인 표현으로 쓰는 것이다. "전문적으로 작성", "인사이트 있게 정리", "완성도 높게 제출"은 듣기에는 좋지만 검토할 수 없다. 좋은 스킬은 마지막에 결과물을 대조할 수 있는 체크리스트를 남긴다.

스킬 설계의 목표는 에이전트에게 모든 것을 맡기는 것이 아니다. 사람이 반복해서 판단하던 기준을 명시해, 에이전트가 더 적은 추측으로 일하게 만드는 것이다. 이름, 목적, 사용 조건, 입력값, 출력 형식, 절차, 금지 행동, 예외 처리, 완료 조건을 같은 방식으로 읽을 수 있으면 어떤 스킬이 좋은지 빠르게 판단할 수 있다. 그리고 그 기준이 있어야 나만의 스킬도 안정적으로 만들 수 있다.