Agent에게 CRM 조회 도구와 사내 검색 도구를 연결했다고 하자. 이제 고객의 요구에 맞는 제품을 골라 달라고 하면 꽤 그럴듯한 답을 만든다. 그런데 같은 업무를 반복하다 보면 사람이 매번 덧붙이는 말이 생긴다. “먼저 제품 버전을 확인해.” “호환성 표가 빠져 있으면 추측하지 마.” “영업 자료와 기술 사양서가 충돌하면 무엇이 최신 승인본인지 먼저 확인해.”
도구가 없어서 생긴 문제가 아니다. 도구로 무엇을 할 수 있는지와 그 도구를 어떤 업무 순서로 써야 하는지는 서로 다른 문제다. Agent Skills는 이 반복 설명을 하나의 재사용 가능한 작업 방법으로 묶는 접근이다. 최근 관심이 높아진 SKILL.md는 그 방법을 기술하는 대표적인 파일 형식이다.
이 글은 Agent Skills가 무엇인지, MCP와 어떻게 다르고 어떻게 함께 쓰는지부터 설명한다. 마지막에는 기업의 현업 전문가(SME)가 자신의 경험을 Skills에 반영할 수 있는지 살펴본다.
Agent Skills는 무엇인가
Agent Skill은 특정 업무를 수행할 때 필요한 지침과 참조 자료를 묶은 폴더다. 사람이 매번 긴 프롬프트를 붙여 넣는 대신, 에이전트가 필요할 때 작업 방법을 읽어 활용하도록 만든다. Anthropic이 2025년에 소개한 Agent Skills는 이후 공개된 Agent Skills 사양과 여러 도구의 구현으로 확장됐다. OpenAI 역시 Skills 공식 문서에서 MCP 도구를 활용하는 반복 업무를 Skills로 정의하는 방식을 설명한다.
Skill은 별도의 LLM 모델도, 비즈니스 로직을 실행하는 서버도 아니다. 모델이 특정 상황에서 참고할 수 있는 절차와 자료에 가깝다. 예를 들어 법률 문서 검토, 코드 리뷰, 고객 브리핑, 문서 템플릿 적용처럼 “매번 비슷한 방식으로 접근해야 하는 일”과 잘 맞는다.
여기서 ‘재사용’은 단순히 프롬프트 문자열을 저장한다는 뜻보다 넓다. 필요한 참고 문서, 템플릿, 검사 스크립트를 함께 묶을 수 있고, 작업 조건과 예상 산출물도 명시할 수 있다.
SKILL.md 안에는 무엇이 들어갈까
가장 작은 Skill은 폴더 하나와 SKILL.md 하나로 시작한다. 파일의 맨 앞은 YAML frontmatter이고, 그 아래는 Markdown 지침이다. 사양에 따라 name과 description은 필수이며, 설명은 모델이 어떤 요청에서 이 Skill을 고려해야 할지 판단하는 단서가 된다.
아래는 제품 기술 적합성 검토를 위한 설명용 예시다. 실제 고객 시스템에서 운영·검증된 배포 자산이라는 뜻은 아니다.
---
name: b2b-solution-fit-review
description: Review B2B product fit using approved specifications and compatibility evidence; escalate unresolved claims for human review.
---본문에는 예를 들어 이런 지침을 둘 수 있다.
- 승인된 제품 사양서에서 모델명과 버전을 확인한다.
- 호환성 매트릭스를 조회한 뒤 가능한 구성을 좁힌다.
- 근거가 없거나 서로 충돌하면
UNRESOLVED로 표시한다. - 추가 SME 체크포인트는 질문으로 활용하되 승인된 사실을 덮어쓰지 않는다.
- CRM 변경은 직접 수행하지 않고 검토안을 만든다.
규모가 커지면 references/에 상세 기준을, assets/에 출력 템플릿을, scripts/에 필요한 검증 코드를 둘 수 있다. 이 디렉터리들은 선택 사항이다. 스크립트가 폴더 안에 있다는 사실만으로 어떤 실행 환경에서도 자동 실행되거나 권한이 부여되는 것은 아니다.
중요한 것은 설명의 정확성이다. “여러 일을 잘한다”보다 “어떤 요청에, 어떤 데이터와 검사 기준으로, 어떤 결과를 만든다”가 실제 선택과 재사용에 도움이 된다.
Agent는 Skill을 어떻게 선택할까
Skills의 자주 언급되는 설계가 Progressive Disclosure다. 처음부터 모든 업무 매뉴얼을 컨텍스트에 넣는 대신, 에이전트가 Skill의 이름과 설명을 먼저 보고 관련성이 있을 때 SKILL.md의 자세한 지침을 읽는다. 이후 필요하다면 참조 파일을 추가로 연다. 사용자가 Skill을 명시적으로 지정하는 방법도 있다.
이 구조는 수십 개의 업무 지침을 무조건 한 프롬프트에 우겨 넣는 방식과 다르다. 다만 Skill이 언제 선택되고, 어떤 파일을 어떤 도구로 읽는지는 사용하는 Agent 제품·호스트 환경에 따라 다를 수 있다. SKILL.md는 모든 제품에 동일한 실행 순서와 성공을 보장하는 엔진이 아니다.
또 하나 오해하기 쉬운 점이 있다. Skill에 “CRM을 조회하라”고 적었다고 해서 조회 권한이 생기는 것은 아니다. 에이전트가 해당 도구를 실제로 사용할 수 있어야 하고, 그 도구의 인증·권한과 데이터 접근 정책이 별도로 허용해야 한다.
MCP와 Agent Skills는 무엇이 다른가
MCP(Model Context Protocol)는 모델 기반 애플리케이션이 외부 서비스의 Tools·Resources·Prompts를 활용하도록 연결하는 프로토콜이다. Tools는 작업을 수행하는 함수, Resources는 읽을 수 있는 정보, Prompts는 재사용 가능한 템플릿을 제공한다. Skill의 절차 설명과 MCP Prompt가 일부 겹쳐 보일 수 있지만, 두 개념의 패키징과 사용 범위는 같지 않다.
간단한 예로 구분해 보자.
- MCP: 제품 조회 도구
get_product_spec, 호환성 확인 도구check_compatibility, 고객 조회 도구get_account를 제공한다. - Skill: 어떤 요청에서 제품 버전을 먼저 확인하고, 호환성 충돌을 어떻게 기록하며, 언제 추가 근거를 요구할지 안내한다.
- API 및 Runtime: 실제 서비스의 계약, 호출자의 권한, 데이터 변경·검증·저장을 책임진다.
Skills는 MCP 없이 파일·기존 도구만으로도 작동할 수 있고, MCP는 특정 Skill 없이도 쓰일 수 있다. 가장 흥미로운 활용은 둘을 결합할 때다. 이미 연결된 capability를 더 목적에 맞게 사용하는 지침이 생긴다.
이전에 MCP가 기존 REST API를 대체해야 하는지를 다뤘다면, 이번 질문은 그 한 단계 위다. 연결된 기능을 업무 목적에 맞게 어떻게 사용하는가? 기존 API를 모두 MCP로 교체할 필요가 없었던 것처럼, 모든 업무 지침을 새로운 서버로 만들 필요도 없다.
기업에서는 SME의 노하우가 Skill이 될 수 있을까
기업에서는 같은 대시보드를 보면서도 숙련된 담당자와 처음 업무를 맡은 사람의 질문이 다르다. 기술 적합성을 검토하는 SME라면 공식 사양서에 없는 사실을 지어내지는 않으면서도, 고객이 실제 설치 환경에서 놓치기 쉬운 버전 의존성, 통합 비용, 승인 절차를 먼저 물을 수 있다.
여기서 구분할 것이 세 가지 있다. 검증된 데이터는 제품 사양서와 호환성 표처럼 출처·버전·승인 상태가 있는 근거다. SME의 암묵지는 “어떤 상황에서 무엇을 추가로 확인해야 하는가”에 대한 경험적 관점이다. Runtime 정책은 누가 어떤 고객 데이터를 조회하고 실제 기록을 수정할 수 있는가를 결정한다.
예를 들어 SME가 “특정 제조업 환경에서는 네트워크 격리 조건을 먼저 확인해야 문제가 줄었다”고 제안한다면, Skill에는 이를 단정적인 결론이 아니라 추가 확인 질문으로 담는 편이 안전하다. 그런 조건이 언제 적용되지 않는지도 함께 적는다. 이후 검토자 승인, 버전 관리, 대표 질문 집합에서의 전후 평가를 거쳐 적용할 수 있다.
이것은 아직 “전문가의 암묵지를 Skill에 넣으면 반드시 정확도가 오른다”는 실증 결과가 아니다. 검증 가능한 설계 가설이다. 개선 여부는 올바른 Skill 선택률, 필요한 도구 선택, 근거 충실도, 반대 증거 검토, 검토자의 수정량으로 확인해야 한다.
Skill을 잘 만들었다고 운영까지 안전해지지는 않는다
Skill은 자주 쓰는 일의 방법을 정리하기에 유용하다. 하지만 지침이 모델 입력으로 들어간다는 점을 잊으면 안 된다. Skill의 문구만으로 실행 순서가 언제나 강제되거나, 자격증명·테넌트 경계·승인·중복 실행 같은 제약이 자동 해결되지는 않는다. 특히 scripts/에 배포한 코드를 실행할 때는 출처와 권한을 더 엄격히 확인해야 한다.
SME의 경험을 그대로 고정하면 편향도 재사용될 수 있다. 특정 경쟁사의 사례만 보도록 만들면 검색은 빨라지겠지만 판단이 더 좋아졌다고 말하기 어렵다. 좋은 Skill은 정답을 미리 쓰는 대신 무엇을 확인하고, 무엇이 부족하면 멈추고, 어떤 반증을 찾아야 하는가를 가르쳐야 한다.
도구의 연결 다음에는 일하는 방법이 남는다
Agent Skills를 새로운 Agent Framework처럼 소개하면 핵심을 놓친다. MCP가 Agent에게 연결 가능한 기능을 제공한다면, Skill은 그 기능을 업무에 맞게 사용하는 방법을 반복해서 전달할 수 있게 한다.
기업에서는 이 지점이 흥미롭다. 같은 모델, 같은 검색 도구, 같은 승인된 데이터를 갖고도 결과가 달라지는 이유는 종종 어떤 질문을 먼저 던지는가에 있기 때문이다. 그 차이를 사람이 설명 가능한 절차로 정리하고, 검증하며, 필요할 때 수정할 수 있다면 Skill은 단순한 프롬프트 파일 이상의 운영 자산이 된다. 단, 최종 실행 권한과 사실의 소유권까지 Skill에 넘길 필요는 없다.
공식 참고: Agent Skills Specification, OpenAI Skills, OpenAI Build Skills, MCP Overview.