에이전트에도 Skill이 생겼어요 — Copilot Studio에서는 이렇게 동작해요

원문: Agents Have Skills Now — Here’s How They Work in Copilot Studio 게시일: 2026-06-15 · 저자: Roel Schenk

LLM은 일반적인 일은 잘합니다. 못하는 건 “우리 조직”에 대한 것들이에요. 우리 회사의 맥락, 관례, 데이터, 일하는 순서 같은 건 모델이 스스로 알아낼 수 없죠. 그렇다고 이걸 전부 에이전트의 지침에 쌓아 넣으면 에이전트가 무거워지고 예측하기 어려워져요.

이럴 때 필요한 만큼만 담아두는 자리가 Skill이에요.

Skill이 뭐예요?

특정 작업이 들어왔을 때만 에이전트가 필요할 때(on demand) 불러오는 지침 묶음이에요.
SKILL.md 파일에 이름, 설명, 지침을 적어요. 예시·템플릿·스크립트 같은 자료를 함께 넣을 수도 있어요.
에이전트는 이름과 설명을 보고 “지금 이 Skill이 필요한가”를 판단해요.

이 아이디어가 GitHub Copilot 하네스¹로 구동되는 Copilot Studio 에이전트에도 들어왔어요.

왜 쓰나요? — 이유는 4가지

관리가 쉬워요. 지침을 끝없이 길게 쓰는 대신, Skill은 하나씩 따로 검토하고 버전 관리할 수 있어요.
컨텍스트가 가벼워져요. 평소에는 이름과 설명만 올라가 있고, 작업이 맞을 때만 전체 지침을 불러와요. Skill 10개를 달아도 평소 비용은 짧은 설명 10줄뿐이에요.
더 정확해질 수 있어요. 어떤 도구를 쓰는지, 어떤 매개변수가 중요한지, 실패하면 어떻게 하는지 같은 도구 사용법을 담아두면 도구 호출이 안정적으로 돼요.
더 빠르고 싸질 수 있어요. 에이전트가 처음부터 알아내는 대신 정답 경로로 바로 가니까, 검색·도구 호출·추론 반복이 줄어요.

앞의 두 가지(관리, 컨텍스트)는 구조적인 이점이라 거의 항상 유효해요. 뒤의 두 가지(정확도, 속도)는 에이전트마다 달라요. 가정하지 말고 직접 검증해 보세요.

Copilot Studio에서 쓰는 법

추가하기

에이전트의 Skills 탭에서 새로 만들거나, 만들어 둔 Skill을 업로드해요.
업로드는 SKILL.md 파일 하나만도 되고, 스크립트 등을 함께 묶은 .zip도 돼요.
추가한 Skill은 그 에이전트 소속이에요. 에이전트를 Power Platform 솔루션²에 넣으면 Skill도 함께 배포돼요.

새로 만들 때는 세 가지를 물어요: 이름, 설명, 지침.

호출하기

Skill은 직접 호출하지 않아요. 대화 내용이 이름·설명과 맞으면 에이전트가 알아서 선택해요. 이 과정은 추론(reasoning) 뷰에서 볼 수 있어요.

에이전트가 매칭되는 Skill을 불러온 뒤, 지침대로 올바른 도구를 호출하는 모습이에요.

추론 뷰는 디버깅 수단이기도 해요.

Skill이 너무 자주 발동한다 → 설명이 너무 넓은 거예요.
전혀 발동하지 않는다 → 설명이 너무 좁거나, 사용자들이 실제로 쓰는 단어와 다른 거예요.

설명은 “발동 조건”으로 쓰세요

만드는 사람들이 가장 자주 틀리는 부분이에요. 이름과 설명은 사람이 읽는 문서가 아니라, 에이전트가 언제 이 Skill을 쓸지 결정하는 발동 조건이에요.

이름은 구체적으로: HR Help ❌ → HR Leave Eligibility Triage ⭕
언제 쓰는지 그리고 언제 쓰면 안 되는지 함께 적기: “휴가 자격과 필수 서류에 사용. 급여나 복리후생 등록에는 사용하지 말 것.”

두 사람이 설명을 읽고 “이 Skill이 언제 켜지는지” 의견이 갈리면, 아직 덜 구체적인 거예요.

형태는 열려 있어요

Copilot Studio Skill은 Anthropic이 시작한 개방형 표준인 Agent Skills 오픈 포맷을 그대로 따라요. 코딩 에이전트에서 쓰던 Skill과 같은 형식이에요.

my-skill/
├── SKILL.md          # 메타데이터 + 지침
├── scripts/          # 실행 코드 (선택)
├── references/       # 참고 문서 (선택)
└── assets/           # 템플릿, 자료 (선택)

두 가지만 알아두세요.

지금은 에이전트 단위로만 배포돼요. 테넌트 전체에서 공유하는 크로스 프로덕트 카탈로그³는 아직 없고, 개발 중이에요. 제품 밖에서는 커뮤니티가 운영하는 CAT Agent Skills 갤러리에서 기성 Skill을 받아 업로드할 수 있어요.
Skill은 도구를 “가리킬” 수만 있어요. “주문 조회 액션을 사용하라”고 적을 수는 있지만, 그 도구를 연결해 주거나 권한을 주지는 않아요. 에이전트에 그 도구가 없으면 지침을 지킬 수 없어요.

어디에 넣을지 판단하는 기준

무언가를 에이전트에게 가르치고 싶을 때, 순서대로 물어보세요.

도구·지식의 설명만 보고 에이전트가 알아낼 수 있나? → 아예 적지 마세요. 뻔한 건 쓸 필요 없어요.
모든 대화에서 항상 맞는 말인가? → 지침(instructions)에 넣으세요. 어조, 역할, 항상 켜져 있어야 하는 가드레일이 여기에 해당해요.
특정 상황에서만 필요한가? → Skill로 만드세요. 평소엔 밖에 두고 그 상황에만 불러오는 것, 그게 Skill이 존재하는 이유예요.

Skill의 내용물은 작업이 요구하는 어떤 형태든 될 수 있어요. 참조 매뉴얼, 플레이북, 표준 운영 절차(SOP), 체크리스트, 런북⁴, 보고서 템플릿 — 공통점은 하나예요. LLM이 스스로 알 수 없는 노하우를 한 번 정리해 두고, 관련 있을 때만 불러온다. 그리고 Skill은 에이전트를 안내할 뿐 옥죄지는 않아요. 따를지 조정할지는 여전히 모델이 상황을 보고 판단해요.

Skill이냐, 새 에이전트냐

전에는 작업마다 에이전트를 새로 만드는 게 자연스러웠어요. 비밀번호 재설정용 하나, 소프트웨어 요청용 하나, 장애 접수용 하나. 하지만 이건 에이전트 셋이 아니라, Skill 셋을 가진 IT 지원 에이전트 하나인 경우가 많아요. 같은 사용자를 상대하고 같은 지식 범위를 쓴다면 Skill로 나누는 쪽이 관리하기 나아요.

별도 에이전트가 맞는 경우는 두 가지예요.

혼자서도 성립할 때. HR 어시스턴트와 IT 지원 에이전트는 대상도 다르고 보안 경계도 달라요. 이렇게 독립적이면 에이전트를 나누세요.
에이전트 하나가 도구를 너무 많이 떠안았을 때. 컨텍스트에 많이 실을수록 정확도가 떨어질 수 있어요. 이 벽에 부딪히면 작업을 별도 에이전트로 분리해 위임하는 게 해법일 수 있어요.

보안: 남이 만든 Skill은 검토하고 쓰세요

주의: Skill은 에이전트의 행동을 결정하고 스크립트까지 담을 수 있어요. 커뮤니티에서 받았거나 AI가 생성한 Skill은 신뢰할 수 없는 코드처럼 다루세요. 추가하기 전에 프롬프트 인젝션⁵, 도구를 오용하라는 지시, 설명과 다른 동작이 없는지 확인하세요.

정리

항상 맞는 말은 지침에, 특정 상황에서만 필요한 건 Skill에. 매뉴얼이든 체크리스트든 런북이든, 상황별 노하우는 Skill로 옮겨두고 에이전트가 필요할 때 꺼내 쓰게 하세요.

어휘 주석

하네스(harness): 에이전트를 실제로 구동하는 실행 엔진. 모델 호출, 도구 실행, 추론 반복을 관리하는 틀을 말해요.
솔루션(solution): Power Platform에서 앱·에이전트·플로우 등을 하나로 묶어 다른 환경(개발→운영)으로 옮기는 배포 패키지.
크로스 프로덕트 카탈로그(cross-product catalog): 하나의 제품·에이전트에 묶이지 않고, 여러 제품과 조직 전체에서 공유해 꺼내 쓸 수 있는 공용 목록.
런북(runbook): 운영 작업의 실행 순서와 실패 시 대처를 단계별로 적은 문서.
프롬프트 인젝션(prompt injection): 문서나 입력 안에 몰래 심어둔 지시문으로 AI가 원래 지침을 어기고 다른 행동을 하게 만드는 공격.