들어가며

같은 회사에서 같은 AI를 쓰는데 누구에게 맡겼느냐에 따라 결과가 달라집니다. 한 사람은 바로 쓸 만한 보고서를 받아오고 다른 사람은 처음부터 다시 고칩니다. 잘 쓰는 사람의 프롬프트를 공유해 보지만 얼마 지나지 않아 비슷한 문제가 반복됩니다. 우리 조직에서도 낯설지 않은 풍경일 겁니다.

광고대행사 Brainlabs도 담당자마다 SEO 진단의 품질이 달랐다고 합니다. 웹사이트가 검색에서 잘 발견되는지 살피는 업무인데 그날 담당자가 무엇을 기억했느냐에 따라 확인하는 내용이 달라졌다는 겁니다. 이 회사는 팀이 축적한 진단 기준과 좋은 결과의 예시를 Agent Skills에 담아 함께 쓰기 시작했습니다. 직원들은 브랜드 자료와 고객 보고서 등으로 범위를 넓히며 4주 동안 약 400개의 스킬을 만들었습니다. Brainlabs 고객 인터뷰

그런데 스킬이 늘어나자 회사는 또 다른 문제를 만났습니다. 서로 겹치는 지침은 어떻게 정리하고 바뀐 업무 기준은 누가 고칠까요?

Agent Skills는 확인된 업무 방법을 여러 사람과 에이전트가 꺼내 쓰도록 묶는 방법입니다. 잘 만들면 매번 설명하던 기준을 재사용할 수 있습니다. 잘못 만들면 낡은 규칙과 실수까지 반복해서 적용하게 됩니다.

앞선 암묵지 자산화 글 에서는 사람에게만 남아 있는 노하우를 조직이 활용하는 문제를 다뤘습니다. 이번에는 그중 현장에서 확인하고 설명할 수 있게 된 업무 방법을 스킬로 만드는 과정을 살펴보겠습니다. 어떤 일부터 맡기면 좋을지, 실제 회사들은 어떻게 쓰는지, 만들고도 실패하는 이유는 무엇인지 알면 우리 조직의 도입 범위도 훨씬 구체적으로 잡을 수 있을 겁니다.

그래서 Skill이 뭔데?

새로 온 직원에게 견적 업무를 넘긴다고 해보겠습니다. 견적서를 잘 만들라는 말만으로는 부족하겠죠. 어떤 계약부터 확인하는지 설명하고 회사 양식을 건네주면서 예외 할인을 적용했던 건과 반려된 견적서도 보여줍니다. 합계를 검사하는 도구가 있다면 그것도 같이 줍니다.

스킬은 이런 인수인계 묶음과 비슷합니다. 업무 지침과 참고자료, 예시, 필요하면 실행 코드와 양식까지 한데 묶어 에이전트가 해당 일을 할 때 사용하게 합니다. 그 중심에는 SKILL.md라는 텍스트 파일이 있습니다. Anthropic이 소개한 Agent Skills는 공개 형식으로 발전했습니다. Agent Skills 사양 은 이 파일과 자료를 어떤 구조로 담을지 정합니다.

그럼 긴 프롬프트를 저장해 둔 것 아닌가요?

지침이 AI에게 전달된다는 점에서는 맞는 말입니다. 여기에 언제 꺼내 쓸지 설명하는 정보와 참고자료, 실행 코드를 묶고 반복해서 배포할 수 있는 구조를 더한 겁니다. 스킬을 지원하는 에이전트는 보통 이름과 설명을 보고 필요한 스킬을 고른 뒤 본문을 읽습니다. 참고자료도 필요한 것부터 불러옵니다. 직원이 모든 업무 매뉴얼을 매일 정독할 필요는 없듯이 말입니다. 공식 작동 원리

이때 모델을 새로 훈련시키지는 않습니다. 제목에서 말하는 가르친다는 것은 일할 때 참조할 지침과 자료를 준다는 뜻입니다. 파일 하나를 넣었다고 모델이 영구적으로 배우거나 모든 피드백을 다음 업무에 자동 반영하지는 않습니다. Anthropic 기술 소개

도구와의 관계도 견적 업무로 보면 간단합니다. 고객 계약을 조회하는 기능이 Tool이라면 어떤 계약을 확인하고 어느 조건에서 질문해야 하는지를 안내하는 것이 Skill입니다. 한 에이전트가 견적 작성, 고객 보고, 회의 정리용 스킬을 함께 사용할 수도 있습니다. 스킬마다 별도의 AI 직원을 한 명씩 만드는 구조는 아닙니다.

그림 1. 모든 스킬의 본문을 한꺼번에 읽는 대신 필요한 업무 지침과 자료를 꺼내 씁니다. 설치·선택·업무 성공은 각각 확인할 항목입니다.

HubSpot은 메모를 쓰는 방식을 담았습니다

회사 일을 가르친다고 하니 거창한 업무 시스템부터 떠올릴 수도 있습니다. HubSpot의 제품 리더 Daniel Jacobson은 자신의 문체와 의사결정 틀을 memo-writer라는 스킬에 담았습니다. 짧은 설명을 주면 연결된 Slack이나 회의록의 맥락을 참고해 검토할 수 있는 메모 초안을 만드는 식입니다.

그는 아이디어에서 검토 가능한 초안까지 걸리는 시간이 2시간에서 20분으로 줄었다고 설명합니다. 첫 결과는 최종 형태의 60~70% 정도이고 주장과 논조는 사람이 다듬습니다. 여기서 시간을 잰 구간은 완성 문서까지가 아니라 검토 가능한 초안까지입니다. 스킬과 커넥터, 업무 맥락을 함께 쓴 담당자의 후기이므로 HubSpot 전체의 생산성 수치로 읽어서는 안 됩니다. HubSpot 실무자 Q&A

회의록을 요약하는 일과 우리 팀이 의사결정을 논의하는 문서를 쓰는 일 사이에는 차이가 있습니다. 무엇을 먼저 설명할지, 주장에는 어떤 근거를 붙일지, 누구에게 어떤 결정을 요청할지까지 정해야 하니까요. 매번 사람이 다시 알려주던 내용을 스킬에 담을 수 있습니다. 보고서를 읽고 늘 같은 부분을 지적하는 임원이라면 그 지적부터 모아볼 만합니다.

우리 회사 스킬 하나를 만들어봅시다

이제 만드는 과정을 살펴보겠습니다. 아래는 설명을 위한 가상의 견적 작성 업무입니다. 실제 고객 프로젝트나 복사해서 바로 실행할 수 있는 완제품은 아닙니다.

업무를 어디까지 맡길까?

처음부터 영업을 잘하는 스킬을 만들겠다고 하면 범위를 잡기 어렵습니다. 고객을 찾는 일과 계약을 협상하는 일, 견적서를 발송하는 일은 필요한 정보도 책임도 다릅니다. 여기서는 고객·제품·수량을 받아 회사 양식의 견적 초안을 만드는 데까지만 맡겨보겠습니다. 가격 확정과 외부 발송은 분리합니다.

저는 이 단계에서 숙련자에게 업무 매뉴얼을 써 달라고 하기보다 최근에 처리한 견적서를 같이 펼쳐보는 편이 좋다고 생각합니다. 잘 끝난 건만 보지 말고 되돌아온 건도 봅니다. 왜 이 고객에게는 기본 단가를 쓰지 않았는지 물어보면 계약 갱신 조건이 나옵니다. 왜 이 건은 결재를 다시 올렸는지 살피면 승인 뒤 수량이 바뀌었다는 사실이 나옵니다. 평소에는 설명할 필요가 없었던 기준들이 실제 사례 안에 들어 있습니다.

이 과정을 거치면 에이전트에 줄 자료도 정해집니다. 확인할 순서, 참고할 계약, 좋은 초안의 예시와 보류해야 할 조건입니다. 모든 암묵지가 한 번에 문서로 바뀌지는 않습니다. 우선 확인된 방법부터 담고 실제 사용 중 빠진 기준을 발견하면 검토해서 보완합니다.

그림 2. 잘된 견적과 되돌아온 견적을 함께 살펴보면 스킬에 담아야 할 판단 기준이 드러납니다. 설명을 위해 AI로 제작한 가상 장면이며 실제 고객사의 현장 사진은 아닙니다.

파일 안에 넣는 것과 밖에서 가져오는 것

스킬의 폴더를 열면 이런 모습일 수 있습니다.

prepare-sales-quote/
├── SKILL.md                     언제 쓰고 어떻게 처리할지
├── references/
│   ├── approval-guide.md        예외와 승인 절차
│   └── output-examples.md       좋은 초안과 보류할 사례
├── scripts/
│   └── validate_quote.py        합계·필수 항목 검사
└── assets/
    └── quote-template.xlsx      회사 견적 양식

모든 폴더를 채워야 하는 것은 아닙니다. 공통 사양에서 중심이 되는 파일은 SKILL.md이며 나머지 자료는 업무에 따라 더합니다. 이름과 사용 설명을 적은 파일 머리말 아래에 자연어로 절차를 쓰면 됩니다. 견적 초안용 파일의 뼈대는 다음처럼 만들 수 있습니다. 파일 형식

---
name: prepare-sales-quote
description: >
  고객과 제품, 수량에 맞는 회사 견적 초안을 작성한다.
  신규 견적이나 거래 조건을 반영한 재작성 요청에 사용한다.
  용어 설명이나 발송만을 요청한 경우에는 사용하지 않는다.
---

# 견적 초안 작성

1. 고객·제품·수량·통화 등 필수 입력을 확인한다. 빠진 내용은 질문한다.
2. 연결된 업무 시스템에서 최신 단가와 계약 조건을 확인한다.
   계약의 유효기간과 적용 조건을 확인한다.
   조회에 실패하거나 적용 기준을 확정할 수 없으면 초안 완성을 보류한다.
3. references/approval-guide.md를 참고해 예외와 필요한 승인을 표시한다.
4. assets/quote-template.xlsx에 초안을 작성하고 scripts/validate_quote.py로 검사한다.
5. 적용한 자료의 출처·시점, 미확인 항목, 검토 요청을 함께 반환한다.
   이 스킬에서는 가격을 확정하거나 견적을 발송하지 않는다.

개발자가 아니어도 앞부분의 업무 지침은 현업과 함께 쓸 수 있습니다. AI에게 사례와 양식을 주고 이런 형태로 초안을 정리해 달라고 할 수도 있습니다. 다만 그 결과가 회사의 기준에 맞는지는 담당자가 확인해야 합니다. 말끔하게 정리된 파일에도 틀린 규칙은 들어갈 수 있습니다.

현재 단가와 고객 계약까지 이 파일에 복사해 두면 어떻게 될까요? 처음에는 편해도 가격표가 바뀌는 순간 오래된 견적을 만들 수 있습니다. 어떤 정보를 어떤 순서로 확인하는지는 스킬에 두고 현재 가격은 원천 시스템에서 가져오도록 나누는 편이 좋습니다. 합계나 필수 항목처럼 정확히 검사할 수 있는 부분은 테스트한 코드에 맡길 수 있습니다. 스크립트 작성 가이드

위 예시에는 시스템 조회와 검사 코드 실행이 나오지만 파일에 적는 것만으로 그 기능이 생기지는 않습니다. 실제 조회 도구를 연결하고 인증을 설정해야 합니다. 검사 코드와 양식도 만들어 준비해야 합니다. 지침은 현업이 설명할 수 있어도 이 부분은 기술 담당자와 함께 작업할 이유가 있습니다.

그림 3. 스킬은 업무 방법을 담고 조회 도구는 현재 정보를 가져옵니다. 계산·양식 검사와 사람의 검토도 필요합니다. 가상의 견적 초안 업무를 구성한 예시입니다.

설치보다 중요한 시험

사용할 에이전트가 발견할 수 있는 위치에 폴더를 등록하거나 제품의 관리 기능으로 배포하면 스킬을 사용할 준비가 됩니다. 설치 경로와 배포 방법은 제품마다 다릅니다. 파일 형식이 같더라도 연결 도구와 실행 환경이 달라지면 같은 결과를 보장할 수 없습니다. 지원 구현 가이드

설치를 마쳤다면 실제 요청을 넣어봅니다. 다음은 이 견적 스킬에 적용할 수 있는 시험 예시입니다.

스킬을 골랐는지, 지침대로 일했는지, 결과물이 맞는지를 나눠서 봐야 합니다. 완료했다는 답변을 읽는 데서 멈추면 안 됩니다. 만들어진 파일을 열어 고객명과 통화, 금액을 직접 확인합니다. 처음에는 사람이 처리했던 같은 사례를 스킬 없이도 실행해 보고 차이를 비교하는 것이 좋습니다. 멋진 문서가 나왔더라도 검토와 수정에 더 오래 걸리면 그 업무의 도입 효과를 다시 따져야겠죠. 스킬 평가 가이드

한 번 통과한 사례를 계속 보여주며 수정하면 그 사례에만 맞는 스킬이 될 수 있습니다. 수정할 때 쓰지 않은 검증용 사례를 따로 남겨두고 같은 요청을 반복했을 때도 결과가 안정적인지 살펴봅니다. 호출을 평가할 때는 비슷하지만 맡기면 안 되는 요청도 넣습니다. 사용 설명 평가

Zapier의 파일에는 초안 다음 일도 적혀 있습니다

실제 회사가 만든 파일을 보면 이 구성이 더 와닿습니다. Zapier는 영업·마케팅 등의 조직에서 사용하는 스킬을 공개했습니다. 그중 고객 성공 사례를 쓰는 Customer Story Writer를 보겠습니다. Zapier의 활용 설명

이 스킬은 승인된 인터뷰 녹취나 브리프, CRM 자료에서 고객의 문제와 사용 방식, 성과를 뽑습니다. 검증된 주장과 근거가 더 필요한 주장을 나누고 인용문과 수치의 확인 여부를 점검합니다. 결과물에는 글 초안뿐 아니라 주장 검토표, 해결하지 못한 질문, 필요한 승인 항목이 포함됩니다. 고객과 브랜드, 법무와 게시 승인도 확인 대상으로 적혀 있습니다. 공개된 SKILL.md

고객 성공 사례를 잘 써 달라는 주문이 꽤 구체적인 업무가 됐습니다. 글은 매끄러운데 고객이 공개를 허락하지 않은 성과 수치가 들어갔다면 실무에서는 쓸 수 없으니까요. 무엇을 만들어야 하는지와 함께 무엇을 아직 확정하면 안 되는지도 알려주는 겁니다. 우리 회사의 스킬을 검토할 때도 이런 부분을 찾아보면 좋겠습니다.

스킬을 붙였는데 왜 더 못할까?

여기까지 읽으면 기존 매뉴얼을 전부 스킬로 바꿔 넣고 싶어질 수도 있습니다. 그 전에 Brainlabs의 운영 경험과 소프트웨어 개발 연구를 살펴보겠습니다. 함께 등장하는 견적·보고서 상황은 문제를 이해하기 위한 가상 예시입니다.

너무 많이 만들면 고르는 일부터 어려워집니다

처음 소개한 Brainlabs는 스킬이 수백 개로 늘자 중복과 겹치는 지침, 불필요한 문맥 사용을 검사하는 도구를 만들었고 스킬마다 담당자를 두어 수정사항을 검토·승인하는 절차도 운영합니다. 파일 수가 늘었다는 사실만으로 잘 쓰이고 있다고 판단하기 어려웠던 겁니다. 이 사례가 보여주는 것은 작성·활용 규모와 운영 방식이며 스킬 400개가 매출을 얼마나 높였는지는 공개 자료에서 확인할 수 없습니다. Brainlabs의 운영 설명

우리 회사에 보고서 작성 스킬이 여러 개 있다고 해보겠습니다. 영업팀 스킬은 매출을 먼저 쓰라고 하고 재무팀 스킬은 수익성을 먼저 쓰라고 합니다. 각 부서에서는 맞는 지침일 수 있습니다. 그런데 둘 다 모든 보고서에 사용한다고 설명해 놓으면 요청에 맞지 않는 기준을 꺼내 쓸 수 있습니다. 어느 부서의 어떤 문서를 위한 스킬인지부터 구분해야 합니다. 여기서 고칠 곳은 보고서 양식보다 사용 범위입니다.

스킬 목록을 늘리는 동안 실제 사용 기록도 봐야 합니다. 쓰이지 않는 항목은 이유를 확인하고 비슷한 항목은 합치거나 사용 조건을 나눕니다. 필요한 스킬을 놓치는 경우와 불필요한 스킬을 호출하는 경우를 따로 모으면 설명을 고칠 근거가 생깁니다.

오래된 지침이 없는 것보다 나쁠 때

SWE-Skills-Bench 연구는 공개된 소프트웨어 개발 스킬을 시험했습니다. 일부 지침이 실제 프로젝트의 버전과 요구사항에 맞지 않아 성능이 나빠졌다고 보고합니다. 예제에 있는 설정을 그대로 따라 쓰면서 해당 과제에는 맞지 않는 결과를 만든 경우입니다. 도움을 주려고 넣은 지침이 현재 작업 환경과 충돌한 겁니다. 연구 원문

이 실험에서 49개 중 3개 스킬은 통과율이 떨어졌고 39개는 변화가 없었습니다. 다만 변화가 없던 항목 중 24개는 스킬 없이도 이미 통과율이 100%였습니다. 좋아지지 않았다는 말과 실패했다는 말은 구분해서 읽어야 합니다. 또한 Claude Code와 Haiku 4.5를 사용한 소프트웨어 개발 과제의 사전공개 연구이므로 다른 모델이나 회계·인사 업무에 같은 수치를 적용할 수는 없습니다. 기업의 운영 사고를 조사한 자료도 아닙니다.

견적 업무에 빗대면 이해하기 쉽습니다. 이번 분기부터 할인 정책이 바뀌었는데 스킬에는 지난 분기 규칙이 남아 있다고 해보겠습니다. AI가 지침을 성실하게 따를수록 틀린 견적이 반복됩니다.

그림 4. 정책이 바뀌어도 에이전트가 읽는 지침이 그대로라면 같은 오류를 반복할 수 있습니다. 가상의 정책 변경 상황을 그린 일러스트입니다.

그래서 정책이 바뀌면 관련 스킬과 시험 사례를 함께 검토해야 합니다. 파일에 수정 날짜 하나 적는 것으로는 부족합니다. 어느 정책을 참조하는지와 누가 변경을 확인하는지까지 정해져 있어야 합니다. 모델이나 연결 도구를 바꿀 때도 이전에 통과했던 사례를 다시 실행해 볼 필요가 있습니다.

승인받으라는 문장은 잠금장치가 아닙니다

견적 초안에 할인 예외가 있으면 팀장 승인을 받으라고 적어두었다고 해보겠습니다. 그런데 에이전트가 승인 여부를 검사하지 않는 발송 도구를 쓸 수 있다면 어떨까요? 지침을 놓쳤을 때 메일은 그대로 나갈 수 있습니다.

지침에 승인 절차를 설명하는 일과 실행 시스템에서 미승인 발송을 막는 일을 함께 해야 합니다. 초안 작성 환경에는 발송 권한을 주지 않거나 발송 도구가 승인 상태와 승인된 내용을 확인하도록 구성할 수 있습니다. 회사에서 직원에게 결재 규정을 알려주면서 시스템의 결재 권한도 따로 설정하는 것과 같습니다. Claude Code의 권한 관리

그림 5. 승인 절차를 설명하는 지침과 미승인 실행을 막는 통제는 함께 필요합니다. 발송 도구가 승인 상태와 실제 발송할 내용을 확인하도록 구성하는 예시입니다.

외부 스킬을 가져올 때도 참고자료 정도로만 생각하면 위험합니다. 그 안에는 실행 코드와 외부 링크, 에이전트에게 내리는 지시가 함께 들어갈 수 있습니다. 사내 자료를 어디로 보내는지, 어떤 파일을 바꾸는지 검토할 필요가 있습니다. Cisco가 공개한 Skill Scanner 같은 검사 도구도 있지만 검사에서 문제가 안 나왔다는 이유만으로 안전을 보장하지는 않습니다.

만든 뒤에 누가 고칠까요?

Jamf는 인사팀의 월별 정책 검토 등에 스킬을 사용하며 지역별 준수 기한을 표시하는 업무를 공개했습니다. 운영에서는 일반적인 AI 도구 사용과 부서별 스킬·외부 연결 구성, 별도의 시스템 개발에 서로 다른 검토 경로를 둡니다. 직원들이 스킬을 만들기 시작한 뒤 어떤 변경을 누가 검토할지 정한 사례로 참고할 만합니다. Jamf 고객 사례

우리 조직에서도 현업 담당자와 기술 담당자가 함께 있어야 합니다. 업무 기준은 현업 담당자가 책임지고 연결·배포는 기술 담당자가 맡습니다. 현업은 틀린 판단을 짚고 기술 담당자는 그 교정을 어디에 반영할지 확인합니다. 스킬 지침을 고칠 수도 있지만 조회 도구나 계산 코드의 문제일 수도 있습니다. 앞선 FDE 글 에서 다룬 현업과 엔지니어의 공동 작업이 이 과정에서도 필요합니다.

사용자가 이번 고객은 예외로 처리해 달라고 했다고 해서 그 내용을 전사 공통 규칙으로 바로 저장하면 곤란합니다. 해당 거래만의 예외인지 앞으로 적용할 정책인지 담당자가 판단해야 합니다. 수정한 버전은 시험 사례를 확인하고 제한된 범위에서 먼저 써 본 뒤 배포를 넓히는 편이 좋습니다. 잘못된 변경을 되돌릴 수 있도록 이전 파일과 변경 이유도 남깁니다. 다만 스킬 파일을 되돌려도 이미 발송한 메일이나 확정한 주문이 취소되지는 않으므로 실제 업무의 복구 절차는 따로 준비해야 합니다.

경영진이 이 과정에서 확인할 성과는 스킬 파일 개수보다 업무 결과에 가깝습니다. 같은 실수를 덜 반복하는지, 검토 가능한 초안이 빨리 나오는지, 숙련자에게 매번 물어보던 일이 줄었는지를 보면 됩니다. 물론 검수와 수정에 들어가는 시간도 포함해서요.

나가며

Agent Skills는 회사에서 확인한 업무 방법을 에이전트가 재사용할 수 있게 담는 형식입니다. 숙련자의 모든 노하우를 파일 하나로 옮길 수는 없지만 실제 사례를 함께 살피고 결과를 교정하면서 설명 가능한 부분을 조금씩 남길 수 있습니다. 그렇게 정리한 지침과 예시, 도구를 다른 직원도 사용하고 담당자가 계속 갱신한다면 개인의 경험 중 일부가 조직의 업무 자산으로 남습니다.

시작할 때부터 전 부서의 스킬 목록을 만들 필요는 없습니다. 반복해서 작성하는 문서나 특정 담당자에게 늘 확인받는 업무 하나를 골라보면 좋겠습니다. 잘된 결과와 반려된 결과를 놓고 무엇이 달랐는지 설명하는 데서 출발할 수 있습니다. 그 기준을 에이전트가 적용하게 한 뒤 실제로 도움이 됐는지 확인하는 겁니다.

막상 우리 회사에 적용하려고 하면 할 일이 적지 않습니다. 업무를 어디까지 맡길지 정하고 흩어진 자료를 연결해야 합니다. 예외와 승인 기준을 구현하고 결과를 시험해야 합니다. 범용 에이전트에 파일을 넣는 과정은 짧아도 현업에서 믿고 쓸 수 있도록 구성하고 운영하려면 업무 이해와 기술적인 노하우가 함께 필요합니다.

우리 엡실론델타는 현업의 업무 방식과 암묵지를 살펴보고 이를 스킬과 도구로 구현하는 일부터 평가·배포·운영까지 함께 도와드릴 수 있습니다. 어디서 시작해야 할지 모르겠거나 만들어 본 스킬이 실제 업무에서는 잘 맞지 않는다면 contact@epsilondelta.ai 로 연락 주세요. 우리 조직에서 매번 다시 설명하고 있는 업무 하나를 알려주셔도 좋습니다. 그 일부터 어떤 기준을 남기고 무엇을 연결해야 할지 함께 살펴보겠습니다.