모던 에이전트에는 이제 스킬이 있다 — Copilot Studio에서의 동작 방식

LLM은 흔한 케이스, 즉 여러분 조직만의 특수한 지식이 필요 없는 상황을 잘 처리합니다. 반대로 잘 못하는 영역은 바로 그 특수한 부분입니다 — 모델이 스스로 추론할 수 없는 맥락, 관례, 데이터, 노하우죠. 특히 절차적 노하우(여러분 조직이 어떤 일을 단계별로 처리하는 고유한 방식)는 LLM이 스스로 알아내기 어려워서, 결국 글로 적어두게 됩니다. 그런데 이 모든 것을 에이전트의 컨텍스트에 항상 쏟아부으면, 바로 그 지점에서 에이전트가 비대해지고 예측 불가능해집니다. 모던 에이전트에는 이 “상황 의존적인 부분”을 담을 더 깔끔한 자리가 있습니다 — 스킬(Skills).

최근 코딩 에이전트를 다뤄본 적이 있다면 이미 만나봤을 겁니다. 본질적으로 스킬은 특정 종류의 작업이 등장할 때만 에이전트가 온디맨드(on demand) 로 불러오는 지침(그리고 선택적으로 예시·템플릿·스크립트 같은 리소스)입니다. SKILL.md 파일이 이름·설명·지침 본문을 담고, 그중 이름과 설명이 에이전트에게 “이 스킬이 언제 유효한지”를 알려줍니다.

그리고 같은 아이디어가 이제 모던 Copilot Studio 에이전트 경험에도 도착했습니다. 이 글은 스킬이 무엇인지, 에이전트 빌더가 왜 관심을 가져야 하는지, 그리고 Copilot Studio에서 구체적으로 어떻게 동작하는지를 다룹니다.

에이전트 빌더가 왜 관심을 가져야 하나

스킬은 Agent Skills 오픈 포맷을 기반으로 합니다. 원래 Anthropic이 개발한 오픈 표준이며, 형태가 의도적으로 단순합니다. 스킬은 그저 지침일 뿐이므로, 진짜 질문은 “왜 지침을 굳이 별도 스킬로 떼어내는가”입니다. 네 가지로 정리됩니다.

• 관리 용이성(Manageability). 끝없이 커지는 하나의 지침 덩어리 대신, 각 스킬은 초점이 명확하고 자기완결적인 단위여서 하나씩 검토하고, 판단하고, 버전 관리할 수 있습니다.
• 컨텍스트 관리(Context management). 스킬은 온디맨드로 로드됩니다. 에이전트는 기본적으로 스킬의 이름과 설명만 시야에 두고, 작업이 매칭될 때만 전체 지침을 컨텍스트로 끌어옵니다. 스킬 10개는 매 턴마다 “짧은 설명 10개”의 비용이지, “전체 지침 10벌”의 비용이 아닙니다. 그래서 컨텍스트 윈도우가 가볍게 유지됩니다.
• 정확도(Accuracy). 케이스에 따라 다르지만 실제로 효과가 있습니다. 스킬은 상세한 도구 사용 가이드를 담을 수 있습니다 — 어떤 도구를 써야 하는지, 어떤 파라미터가 중요한지, 쿼리를 어떻게 구성하는지, 호출 전 무엇을 검증하는지, 도구가 빈 결과를 반환하면 어떻게 하는지. 크거나 서로 겹치는 도구 세트에서, 이 가이드를 “관련 있을 때만” 컨텍스트에 넣으면 에이전트가 도구를 더 안정적으로 호출할 수 있습니다. 보장은 아니므로, 가정하지 말고 평가하세요.
• 속도와 비용(Speed and cost). 스킬은 에이전트가 모든 것을 처음부터 스스로 알아내게 두는 대신 올바른 접근으로 유도합니다. 지식 검색·도구 호출·추론 루프가 줄면, 답변까지의 왕복이 줄어 응답 지연이 감소하고, 부하 상황에서 처리량이 오르며, 대화 비용이 낮아집니다. 정확도와 마찬가지로 케이스 의존적이니, 가정하지 말고 검증하세요.

여기까지가 짧은 버전입니다. 관리 용이성과 컨텍스트 관리는 구조적 이점이라 거의 모든 곳에 적용됩니다. 정확도와 속도는 여러분의 에이전트에 따라 달라집니다.

Copilot Studio에서도 같은 이점이 나타난다

좋은 소식은, 모던 Copilot Studio 오케스트레이터가 동일한 방식으로 동작한다는 점입니다. 사용 가능한 스킬 집합을 두고 추론해서, 관련 있는 스킬을 선택하고, 대화가 그 스킬을 필요로 할 때만 지침을 컨텍스트로 가져옵니다.

[사용자 프롬프트]
      │
      ▼
┌───────────── 에이전트 기본 컨텍스트 ─────────────┐
│  전체 지침(Full instructions)                    │
│  지식 메타데이터(A, B, C)                         │
│  도구 메타데이터(A, B, C)                         │
│  스킬 메타데이터(A, B, C)                         │
└───────────────────────┬──────────────────────────┘
                        ▼
        「컨텍스트 평가: 어떤 스킬이 매칭되는가?」
                        │  (예: 스킬 B 매칭)
                        ▼
   스킬 B의 전체 지침 로드 (+ 선택적 예시·리소스)
                        │
                        ▼
   에이전트 실행: 일반 지침 + 스킬 B + 필요한 지식/도구

이는 스킬만의 특성이 아닙니다 — 지식 소스, 도구, 스킬은 모두 같은 방식으로 등록됩니다. 기본적으로는 메타데이터만 컨텍스트에 있고, 프롬프트가 필요로 할 때만 전체 내용을 끌어옵니다(에이전트 자체의 지침은 예외로, 항상 전부 로드됩니다). Copilot Studio가 스킬을 이렇게 온디맨드로 로드하기 때문에, 앞서 말한 이점 — 관리 용이성, 컨텍스트 관리, 정확도, 속도 — 이 그대로 이어집니다.

Copilot Studio에서 스킬 다루기

스킬 추가

스킬은 에이전트의 Skills 탭에 있습니다. 오늘 기준 진입점은 두 가지입니다. 빈 상태에서 스킬을 새로 만들거나, 기존 스킬을 업로드하는 것. 업로드는 단독 SKILL.md 파일일 수도 있고, SKILL.md와 추가 리소스(예: 스킬이 참조하는 Python 스크립트)를 함께 묶은 .zip일 수도 있습니다.

한 번 추가되면 스킬은 에이전트의 일부가 됩니다. 해당 에이전트에 스코프되어 함께 이동합니다 — 에이전트를 Power Platform 솔루션에 추가하면 스킬도 ALM 라이프사이클을 따라 함께 움직입니다.

스킬 호출

스킬을 직접 “호출”하지는 않습니다. 대화가 매칭될 때, 오케스트레이터가 스킬의 이름과 설명을 근거로 선택합니다. 에이전트의 추론 뷰(reasoning view)에서 이 과정을 관찰할 수 있습니다.

이 추론 뷰는 주요 디버깅 지점이기도 합니다. 스킬이 너무 자주 발동하면 설명이 지나치게 넓은 것이고, 전혀 발동하지 않으면 설명이 너무 좁거나 사용자가 실제로 쓰는 표현과 맞지 않는 것입니다.

설명은 “라우팅 메타데이터”처럼 작성하라

이 부분은 곱씹을 가치가 있습니다. 메이커가 가장 자주 틀리는 지점이기 때문입니다. 이름과 설명은 사람을 위한 문서가 아니라, 오케스트레이터가 “이 스킬이 언제 적용되는지” 판단하는 데 쓰는 라우팅 신호(routing signal) 입니다. 그렇게 다뤄야 합니다.

• 구체적으로 명명하기: HR Help가 아니라 HR Leave Eligibility Triage.
• 언제 쓰는지 그리고 언제 쓰지 않는지를 말하기: “휴가 자격 및 필요 서류에 사용. 급여나 복리후생 가입에는 사용하지 않음.”

정확한 설명은 오케스트레이터에게 명확한 라우팅 목표를 줍니다. 모호한 설명(“HR 질문을 도와줍니다”)은 엉뚱한 스킬이 발동하거나 아무것도 발동하지 않게 만듭니다. 합리적인 메이커 두 명이 “이 스킬이 언제 적용되는가”를 두고 의견이 갈린다면, 그 설명은 아직 충분히 구체적이지 않은 것입니다.

Copilot Studio 스킬과 오픈 포맷

코딩 에이전트 출신이라면 반가운 소식이 있습니다. Copilot Studio 스킬은 동일한 Agent Skills 오픈 포맷을 따릅니다. 스킬 폴더는 지침 이상을 번들할 수 있습니다.

my-skill/
├── SKILL.md          # 메타데이터 + 지침
├── scripts/          # 선택: 실행 가능한 코드
├── references/       # 선택: 문서
└── assets/           # 선택: 템플릿·리소스

Copilot Studio는 오늘 이 전체 형태를 지원합니다. 스킬은 SKILL.md 지침을 담고, 리소스(참조 파일·예시·템플릿)와 실행 스크립트를 번들할 수 있으며, 스킬이 선택될 때 모두 온디맨드로 로드됩니다. 이 리소스와 스크립트를 실제로 활용하는 방법은 별도 글로 다룰 만하며, 후속 글에서 이어집니다. 지금은 Copilot Studio가 번들을 다루는 방식에서 두 가지만 짚겠습니다.

• 배포는 (현재로선) 에이전트 단위. 코딩 에이전트 생태계는 스킬을 제품·테넌트를 넘나드는 플러그인으로 배포하게 해줍니다. 2026년 6월 기준, Copilot Studio의 스킬은 자신의 에이전트에 스코프되어 솔루션·ALM을 통해 에이전트와 함께 이동하며, 제품 간 공유 카탈로그를 통하지는 않습니다. 이는 최종 상태가 아니라 현재 상태이며, 더 카탈로그다운 스킬 공유 방식이 개발 중입니다.
• 스킬은 번들 스크립트뿐 아니라 에이전트의 도구를 “소프트 포인팅”할 수 있다. 스킬은 자체 번들 스크립트를 실행할 수도 있지만, 에이전트의 기존 역량(액션·플로우·커넥터·MCP 서버)을 소프트 포인팅(soft-point) 할 수도 있습니다. 스킬이 그 역량을 참조만 할 뿐 바인딩하거나 권한을 부여하지 않기 때문에 “소프트”입니다. 스킬은 “여기서 order-lookup 액션을 써라”라고 말할 수 있지만 보장은 없습니다. 에이전트가 그 도구를 이미 갖고 있지 않으면 지침은 이행될 수 없고, 갖고 있더라도 오케스트레이터가 그 포인터를 따를지 여전히 스스로 결정합니다.

스킬을 어떻게 바라볼 것인가

스킬은 눈앞의 작업이 필요로 하는 어떤 형태든 될 수 있습니다. 스킬을 다음 중 무엇으로든 생각해 보세요.

공통점은 이것입니다 — 각각은 LLM이 스스로 추론할 수 없는 상황 특화 가이드를, 한 번 패키징해 두고 관련 있을 때만 끌어오는 것입니다. 지식은 사실을, 도구는 도달 범위를 주고, 스킬은 그 둘을 잘 쓰기 위한 상황 노하우를 줍니다. 그리고 결정적으로, 스킬은 에이전트를 유도할 뿐 구속하지 않습니다. 모델은 여전히 상황을 읽고 스킬을 문자 그대로 따를지 조정할지 스스로 결정합니다. 그 판단이야말로 LLM을 쓰는 핵심이며, 스킬은 단지 작업이 등장했을 때 올바른 전문성이 그 자리에 있도록 보장할 뿐입니다.

지침인가, 스킬인가?

지침과 스킬을 저울질하는 시점이면, 한 가지는 이미 정해진 셈입니다. 여기에는 에이전트가 스스로 추론할 수 없는 무언가가 있다는 것. (잘 설명된 도구나 지식 소스를 주면 에이전트는 대개 설명만으로 사용법을 알아내므로, 자명한 것은 아예 적을 필요가 없습니다.) 남는 것 — 여러분 조직의 맥락, 관례, 데이터, 규칙 — 이 바로 말로 옮겨야 하는 부분입니다. 유일한 질문은 “그것을 어디에 두는가”이고, 선택은 단순합니다.

• 모든 대화·모든 시나리오에서 참인가? 에이전트의 지침(instructions) 에 두세요. 톤, 에이전트의 역할, 항상 켜져 있는 가드레일 — 이것들은 100% 유효하므로 늘 컨텍스트에 있어야 합니다.
• 특정 시나리오에만 적용되는가? 스킬로 만드세요. 어떤 가이드가 매 턴 관련되지 않는다면, 기본 컨텍스트에서 빼두고 해당 시나리오가 등장할 때만 로드하는 것 — 그것이 바로 스킬의 존재 이유입니다.

[에이전트가 알거나 하길 원하는 무언가]
      │
      ▼
Q1. 도구·지식 설명만으로 에이전트가 추론할 수 있는가?
   ├─ 예  → 에이전트에 맡긴다(따로 적지 않음)
   └─ 아니오
        │
        ▼
   Q2. 모든 시나리오·대화에서 유효한가?
      ├─ 예, 항상 참 → 지침(instructions)에 둔다
      └─ 아니오, 특정 시나리오만 → 스킬(Skill)로 만든다

두 가지 질문이 결정합니다 — 에이전트가 추론할 수 있는가, 그렇지 않다면 항상 참인가 아니면 상황 의존적인가.

그게 구분의 전부입니다. 지침은 항상 켜진 기준선이고, 스킬은 상황 의존적인 모든 것을 이름·설명과 함께 담아 에이전트가 적절한 순간에 올바른 것을 집어들 수 있게 한 것입니다. 그리고 이렇게 나누는 방식에서 앞서의 이점이 결실을 맺습니다.

• 컨텍스트 관리. 상황 의존적 가이드가 기본 컨텍스트에서 빠져, 컨텍스트 윈도우가 포화될 가능성이 줄어듭니다.
• 관리 용이성. 각 스킬이 자기완결적 단위라, 에이전트를 관리하고 변경하기가 쉬워집니다.
• 정확도. 올바른 가이드가 모든 것을 한꺼번에 헤집는 대신 올바른 순간에 도착하면, 에이전트가 더 나은 판단을 내릴 수 있습니다. 케이스별이니, 가정하지 말고 검증하세요.
• 속도와 크레딧. 검색·도구 호출·추론 루프가 줄어 응답이 짧아지고 크레딧 소비가 감소할 수 있습니다 — 이 역시 케이스별입니다.

스킬인가, 새 에이전트인가?

Copilot Studio에 스킬이 등장하기 전에는, 구별되는 작업마다 또 하나의 특화 에이전트를 만드는 것이 본능이었습니다 — 비밀번호 재설정용 하나, 소프트웨어 요청 승인용 하나, 사고 분류용 하나. 하지만 그것들은 종종 세 개의 에이전트가 아니라, 세 개의 스킬을 가진 하나의 IT 지원 에이전트입니다. 같은 에이전트가 같은 대상에게 서비스하고 같은 지식 경계를 공유한다면, 스킬이 더 나은 모듈화 단위입니다. 유지할 또 다른 에이전트를 만드는 게 아니라, 기존 에이전트에게 또 하나의 일하는 방식을 가르치는 것이니까요.

여전히 별도 에이전트를 가리키는 신호는 두 가지입니다.

• 그 자체로 독립적으로 설 수 있다. HR 어시스턴트와 IT 지원 에이전트는 스킬 두 개짜리 하나의 에이전트가 아닙니다. 서로 다른 대상을 섬기고, 서로 다른 보안 경계 뒤에 있으며, 각자 단독으로 쓰일 만한 독립 에이전트로 성립합니다. 역량이 이렇게 독립적이라면, 에이전트로 만드세요. (독립적이라는 것과 재사용 가능하다는 것은 다릅니다 — 스킬을 여러 에이전트에서 공유하는 것은 별개 문제이며, 제품 내 스킬 카탈로그가 향후 다룰 종류의 일입니다.)
• 한 에이전트가 너무 많은 도구를 떠안았다. 에이전트의 컨텍스트에 더 많은 것이 로드될수록 정확도가 떨어질 수 있다는 데이터가 있고, 커지는 도구 세트가 그 부담의 일부입니다. 어느 지점을 넘어서면 스킬을 더 추가해도 해결되지 않습니다. 늘 그렇듯, 가정하지 말고 여러분의 에이전트에 대해 평가하세요. 그 벽에 부딪히면, 모든 것을 한 에이전트에 쌓는 대신 작업을 별도 에이전트로 분리해 위임하는 것이 방법일 수 있습니다.

신뢰에 관한 한마디

스킬은 에이전트의 행동을 형성하고 이제 스크립트까지 번들할 수 있으므로, 신뢰 표면(trust surface) 입니다. 직접 작성하지 않은 스킬 — 커뮤니티 출처, AI 생성, 다른 환경에서 재사용한 것 — 은 신뢰할 수 없는 코드처럼 다루세요. 추가하기 전에 검토하세요. 프롬프트 인젝션, 도구를 오용하라는 지침, 스킬이 주장하는 바와 맞지 않는 부분이 없는지 확인하세요.

정리하며

더 깊이 들어가고 싶다면 — 맥락적 지침으로 에이전트 계획에 영향 주기는 항상 켜진 지침이 오케스트레이터를 어떻게 이끄는지 다루고, Open the Hood: Copilot Studio 에이전트가 실제로 하는 일은 스킬이 언제 발동하는지를 결정하는 추론을 어떻게 들여다보는지 보여주며, Closing the Loop는 올바른 스킬이 올바른 순간에 발동하는지 평가하는 방법을 다룹니다.

스킬은 Copilot Studio에서 아직 초기 단계이고, 의도적으로 초점을 좁혔습니다. 하지만 핵심 아이디어는 지금 내재화할 가치가 있습니다 — 모든 대화에서 참인 것은 지침에 두고, 상황 의존적인 모든 것은 에이전트가 온디맨드로 끌어올 수 있는 스킬로 옮기라는 것. 그것이 레퍼런스 매뉴얼이든, 체크리스트든, 런북이든, 플레이북이든.

스킬은 Copilot Studio에 새로 등장했고, 여러분이 이를 어떻게 활용하는지 무척 듣고 싶습니다. 여러분이라면 지침에서 가장 먼저 무엇을 꺼내 스킬로 바꾸시겠습니까?