나만의 스킬 제작 워크플로

문제 상황: 자동화 아이디어는 많은데 쓸 만한 스킬은 적다

많은 사람이 에이전트를 만들 때 이렇게 시작한다.

• 매주 하는 리서치를 자동화하고 싶다.

• 회의록 정리를 맡기고 싶다.

• 고객 문의 답변 초안을 만들고 싶다.

• 코드 리뷰를 더 빠르게 하고 싶다.

아이디어 자체는 좋다. 문제는 이 문장만으로는 아직 스킬이 되지 않는다는 점이다. 에이전트는 무엇을 입력받아야 하는지, 어떤 기준으로 판단해야 하는지, 어떤 도구를 써야 하는지, 결과가 맞는지 어떻게 확인해야 하는지 모르면 매번 다르게 행동한다.

스킬 제작은 막연한 자동화 아이디어를 실행 가능한 명세서로 바꾸는 과정이다. 이 장의 목표는 하나다. 머릿속에 있는 '이거 AI가 해 주면 좋겠다'를 실제로 테스트하고 고칠 수 있는 커스텀 스킬로 바꾸는 절차를 익히는 것이다.

여러 에이전트 플랫폼은 스킬을 단순한 프롬프트가 아니라 지시문, 스크립트, 참고 자료, 템플릿을 포함할 수 있는 패키지로 본다. 보통 핵심 설명 파일과 필요할 때 불러오는 자료, 실행 스크립트, 정적 자산을 나누어 관리한다.¹ 특정 형식은 도구마다 다르지만, 원칙은 같다. 에이전트가 필요한 순간에 정확히 이해하고 실행할 수 있도록 업무 능력을 작게 포장하는 것이다.

AI 생성 이미지

1단계: 반복 업무를 기록한다

스킬은 상상에서 잘 나오지 않는다. 실제로 반복한 업무에서 나온다. 그래서 첫 단계는 자동화가 아니라 관찰이다.

일주일만 다음 형식으로 기록해 보자.

중요한 것은 '내가 실제로 고친 부분'을 적는 것이다. 에이전트가 자주 틀리는 지점은 대개 사람이 무의식적으로 처리하던 기준이다. 예를 들어 '좋은 자료만 골라 줘'는 스킬이 아니다. 하지만 '공식 발표, 주요 언론, 투자자 자료를 우선하고 출처가 불분명한 블로그 글은 제외한다'는 스킬의 판단 기준이 된다.

좋은 스킬은 일반론보다 실제 사례에서 강해진다. 실제 업무 로그, 내부 문서, 실패 사례, 검토 코멘트에서 절차와 예외를 추출해야 한다. 범용적인 모범 사례만 넣으면 결과도 범용적인 수준에 머문다.²

2단계: 스킬화할 후보를 고른다

기록한 모든 업무를 스킬로 만들 필요는 없다. 스킬화할 가치가 있는 후보를 먼저 선별해야 한다. 기준은 세 가지다.

첫째, 빈도다. 자주 반복할수록 스킬화 가치가 높다. 매일 10분씩 쓰는 업무는 한 달에 한 번 2시간 쓰는 업무보다 먼저 스킬화할 수 있다.

둘째, 난이도다. 너무 쉬운 업무는 체크리스트로 충분할 수 있다. 반대로 너무 어려운 업무는 한 번에 스킬로 만들기 어렵다. 처음에는 '사람이 기준을 알려 주면 에이전트가 보조할 수 있는 업무'가 좋다.

셋째, 위험도다. 잘못되었을 때 비용이 큰 업무는 바로 자동 실행하면 안 된다. 계약서 발송, 결제 처리, 대량 이메일 전송, 운영 서버 변경처럼 되돌리기 어려운 일은 승인 단계를 넣거나 초안 생성까지만 맡겨야 한다.

간단히 점수를 매겨 보자.

처음 만들 스킬은 빈도가 높고, 난이도가 중간이며, 위험도가 낮거나 통제 가능한 업무가 좋다. 성공 경험을 쌓은 뒤에 위험도가 높은 업무로 확장한다.

3단계: 업무를 네 구간으로 재구성한다

스킬 명세서는 업무 절차를 그대로 받아 적는 문서가 아니다. 에이전트가 실행할 수 있는 흐름으로 다시 짜야 한다. 기본 구조는 다음 네 구간이다.

1. 사용자 입력

2. 에이전트 판단

3. 도구 사용

4. 결과 검증

예를 들어 '주간 경쟁사 뉴스 요약' 스킬은 이렇게 재구성할 수 있다.

이 구조를 만들면 빠진 부분이 보인다. 경쟁사 목록이 없으면 시작할 수 있는가? 기간을 안 주면 기본값은 최근 7일인가? 블로그 글도 포함할 것인가? 출처가 하나뿐인 소식은 어떻게 표시할 것인가?

스킬은 이런 질문에 미리 답해 두는 장치다. 에이전트가 추측해도 되는 부분과 반드시 사용자에게 물어야 하는 부분을 나누어야 한다. 이 구분이 없으면 에이전트는 친절해 보이려고 추측을 하고, 그 추측이 결과 전체를 흔들 수 있다.

4단계: 스킬 초안을 쓴다

이제 초안을 만든다. 처음부터 완벽하게 쓰려고 하지 말고, 실행 가능한 최소 명세서를 목표로 한다. 이름, 목적, 트리거, 입력값, 절차, 출력 형식, 제약조건, 검증 기준만 있으면 된다.

예시는 다음과 같다.

스킬 초안: 경쟁사 주간 브리프

이름
competitor-weekly-brief

목적
지정한 경쟁사와 기간에 대해 중요한 뉴스, 제품 변화, 가격 변화, 파트너십, 채용 신호를 수집하고 1페이지 브리프로 정리한다.

트리거/사용 조건
사용자가 경쟁사 동향, 시장 모니터링, 주간 뉴스 요약, 회의 전 브리프를 요청할 때 사용한다. 단순한 회사 소개나 장기 산업 분석 요청에는 사용하지 않는다.

스킬 설명은 홍보 문구가 아니라 라우팅 계약에 가깝다. 어떤 요청에서 켜지고, 어떤 요청에서는 켜지지 않아야 하는지 구분할 수 있어야 한다.³

필수 입력값

• 경쟁사 이름 또는 도메인

• 조사 기간

• 결과를 받을 언어

선택 입력값

• 포함할 주제: 제품, 가격, 투자, 채용, 파트너십 등

• 제외할 출처

• 출력 분량

• 내부 관점: 영업, 제품, 마케팅, 투자 등

입력이 부족할 때

• 경쟁사 목록이 없으면 작업을 시작하지 말고 목록을 요청한다.

• 기간이 없으면 최근 7일로 가정하고 결과 상단에 명시한다.

• 출처 기준이 없으면 공식 발표, 주요 언론, 업계 전문 매체를 우선한다.

절차

1. 경쟁사 이름과 도메인을 확인한다.

2. 기간 조건에 맞는 자료만 수집한다.

3. 같은 소식은 하나로 묶고 가장 신뢰도 높은 원문 링크를 남긴다.

4. 제품, 가격, 파트너십, 채용, 투자, 기타로 분류한다.

5. 각 항목마다 우리 팀에 중요한 이유를 한 문장으로 쓴다.

6. 출처와 날짜가 없는 항목은 본문에 넣지 않고 '확인 필요'로 분리한다.

출력 형식

• 요약: 이번 주 핵심 변화 3줄

• 상세 표: 회사, 날짜, 사건, 분류, 중요도, 출처

• 시사점: 우리 팀이 확인할 질문 3개

• 제외한 항목: 제외 이유와 함께 간단히 기록

제약조건

• 출처 없는 주장은 단정하지 않는다.

• 같은 이름의 회사가 여러 개일 때는 도메인이나 산업 맥락으로 확인한다.

• 오래된 기사를 최신 소식처럼 쓰지 않는다.

• 사용자가 승인하지 않은 내부 문서는 외부 도구에 입력하지 않는다.

검증 기준

• 모든 본문 항목에 날짜와 링크가 있는가?

• 조사 기간 밖의 자료가 섞이지 않았는가?

• 회사명 혼동이 없는가?

• 중요도 판단의 이유가 한 문장으로 설명되었는가?

• 결과가 1페이지 안에 들어오는가?

이 정도면 첫 테스트를 실행할 수 있다. 아직 완성품은 아니다. 하지만 이제 실패를 관찰하고 고칠 수 있는 형태가 되었다.

5단계: 작은 테스트 데이터로 실행한다

스킬은 실제 업무 전체에 바로 적용하지 않는다. 작은 테스트 데이터로 먼저 실행한다.

테스트 입력은 작을수록 좋다.

• 경쟁사: 2개

• 기간: 최근 7일

• 출처: 공식 블로그와 주요 언론만

• 출력: 표 5행 이하

• 목적: 다음 제품 회의에서 참고

이렇게 제한하면 실패 원인을 찾기 쉽다. 결과가 이상할 때 그것이 검색 범위 문제인지, 트리거 문제인지, 출력 형식 문제인지 구분할 수 있다.

테스트할 때는 성공 사례만 보지 않는다. 반드시 반대 사례도 넣어야 한다. 여기서 반대 사례란 스킬이 켜지면 안 되는 요청, 또는 사람의 확인 없이는 진행하면 안 되는 요청이다.

좋은 스킬은 필요한 순간에만 켜진다. 너무 쉽게 켜지는 스킬은 다른 업무를 방해하고, 너무 늦게 켜지는 스킬은 재사용성이 떨어진다. 그래서 긍정 테스트와 부정 테스트를 함께 해야 한다.

6단계: 실패를 지시문으로 되돌린다

첫 실행에서 나온 실패는 실망할 일이 아니다. 스킬 명세서를 고칠 재료다. 중요한 것은 실패를 감상으로 남기지 않고 문장으로 바꾸는 것이다.

스킬 개선은 보통 세 군데를 고치는 일이다.

첫째, 트리거를 고친다. 언제 실행할지, 언제 실행하지 않을지 더 분명히 쓴다.

둘째, 제약조건을 고친다. 하면 안 되는 행동, 승인 없이는 진행하면 안 되는 행동을 앞쪽에 둔다.

셋째, 검증 기준을 고친다. 결과를 제출하기 전에 스스로 확인할 체크리스트를 넣는다.

절차를 계속 길게 만드는 것은 답이 아니다. 지시가 길어질수록 핵심이 묻힌다. 에이전트가 틀릴 가능성이 높은 판단 기준, 빠지면 위험한 제약조건, 반복해서 필요한 출력 형식만 남긴다.

7단계: 문서화 수준을 배포 범위에 맞춘다

같은 스킬이라도 개인용, 팀 공유용, 공개 배포용은 문서화 수준이 달라야 한다.

개인용 스킬

개인용은 빠르게 만들고 자주 고치면 된다. 내가 쓰는 약어, 선호하는 문체, 자주 보는 자료 위치를 넣어도 괜찮다. 다만 비밀번호, API 키, 고객 개인정보를 스킬 본문에 적어서는 안 된다. 민감한 정보는 별도 보안 저장소나 승인된 도구를 통해 다루어야 한다.

개인용 스킬의 핵심은 속도다. 완벽한 문서보다 반복 사용하면서 고칠 수 있는 구조가 중요하다.

팀 공유 스킬

팀 공유 스킬은 다른 사람이 읽어도 같은 결과를 낼 수 있어야 한다. 그래서 다음 항목이 필요하다.

• 스킬 소유자

• 사용 목적과 비목적

• 입력 예시와 출력 예시

• 승인해야 하는 상황

• 사용 가능한 도구와 금지된 도구

• 변경 이력

• 실패 사례와 수정 내역

팀 스킬은 표준을 만드는 도구다. 개인의 감각을 팀의 실행 기준으로 바꾸는 것이 목적이다. 따라서 '적당히', '중요하면', '깔끔하게' 같은 표현을 줄이고 검증 가능한 기준으로 바꿔야 한다.

공개 배포용 스킬

공개 배포용은 보안과 오용 가능성을 더 넓게 봐야 한다. 내부 URL, 고객명, 실제 장애 사례, 비공개 전략, 라이선스가 불명확한 템플릿은 제거해야 한다. 실행 스크립트가 있다면 필요한 권한, 의존성, 실행 환경, 실패 시 동작을 명시해야 한다.

또한 공개 스킬은 사용자 환경을 알 수 없으므로 기본값을 조심해야 한다. 파일 삭제, 대량 발송, 외부 업로드, 결제, 권한 변경 같은 동작은 기본적으로 계획안만 만들고 사람의 승인을 받게 해야 한다.

좋은 제작 워크플로의 완성 형태

나만의 스킬 제작 워크플로는 다음 순서로 정리할 수 있다.

1. 반복 업무를 관찰 로그로 기록한다.

2. 빈도, 난이도, 위험도로 후보를 고른다.

3. 업무를 사용자 입력, 에이전트 판단, 도구 사용, 결과 검증으로 재구성한다.

4. 실행 가능한 최소 스킬 명세서를 쓴다.

5. 작은 테스트 데이터로 실행한다.

6. 실패 사례를 트리거, 제약조건, 검증 기준에 반영한다.

7. 배포 범위에 맞게 문서화와 보안 검토 수준을 조정한다.

이 과정을 거치면 스킬은 단순한 프롬프트 저장소가 아니라 반복 가능한 업무 능력이 된다. 핵심은 한 번에 거대한 자동화를 만드는 것이 아니다. 작은 업무를 정확히 정의하고, 실제 실행 결과로 고치고, 안전하게 넓혀 가는 것이다.

사람의 역할은 사라지지 않는다. 사람은 무엇을 맡길지, 어디까지 허용할지, 어떤 결과를 통과시킬지 정해야 한다. 에이전트는 그 기준 안에서 반복 실행을 돕는다. 좋은 스킬은 이 경계를 분명하게 만든다.

실패 패턴

마지막으로 처음 스킬을 만들 때 자주 생기는 실패를 정리하자.

• 아이디어만 있고 입력값이 없다. '시장 조사 자동화'라고만 쓰면 실행할 수 없다. 조사 대상, 기간, 출처, 출력 형식이 필요하다.

• 절차는 긴데 판단 기준이 없다. 많이 검색하라고 해도 무엇을 포함하고 제외할지 모르면 결과가 흔들린다.

• 트리거가 너무 넓다. '리서치가 필요할 때 사용'처럼 쓰면 거의 모든 정보 요청에 켜진다.

• 위험한 행동에 승인 단계가 없다. 발송, 삭제, 결제, 권한 변경은 초안 또는 계획안 단계에서 멈춰야 한다.

• 테스트 없이 바로 공유한다. 작은 입력으로 실패를 확인하지 않은 스킬은 팀 전체에 불안정한 기준을 퍼뜨린다.

• 문서화 수준을 구분하지 않는다. 개인 메모 수준의 스킬을 팀에 공유하거나, 내부 정보가 담긴 스킬을 공개하면 품질과 보안 문제가 동시에 생긴다.

스킬 제작은 문장을 잘 쓰는 작업이 아니라 업무 기준을 설계하는 작업이다. 기준이 선명할수록 에이전트의 실행도 안정된다.

참고

¹Agent Skills | Microsoft Learn

²Best practices for skill creators

³Skill Design Best Practices for AI Coding Agents