시스템 프롬프트(system prompt)에 집어넣는 모든 지침, 참조 문서, 그리고 실행 예제는 매 호출마다 비용이 발생합니다. 단 세 줄의 가이드만 필요한 작업이라 할지라도, 결국 프롬프트 전체를 다 사용하게 됩니다. 이것이 수많은 에이전트(agent) 파일럿 프로젝트들이 정체되는 조용한 이유입니다. 비용은 작업이 얼마나 많은 지식을 사용했느냐가 아니라, 얼마나 많은 전문 지식을 프롬프트에 담았느냐에 따라 확장되기 때문입니다.

Microsoft Agent Framework에서 실험적 프리뷰(experimental preview)를 벗어나는 .NET용 Agent Skills는 이러한 문제에 대한 Microsoft의 프로덕션(production)급 해답입니다. 그리고 이는 현재 기업 플랫폼 팀들이 아키텍처 리뷰에서 논쟁하고 있는 'Microsoft Agent vs Flow' 질문의 조건을 변화시킵니다. 다만, 발표 당시의 과장된 홍보 내용과는 조금 다릅니다. 이번 릴리스는 에이전트에 대한 가장 강력한 반대 의견을 제거하지만, Flow가 존재하는 이유 자체를 제거하지는 않습니다.

핵심은 [Experimental] 속성 제거가 아닌 레이지 로딩(lazy-loading)입니다

레이지 로딩(lazy-loading)은 Azure의 다른 모든 비용 거버넌스(cost governance)와 마찬가지로 할당(attribution), 할당량(quotas), 그리고 실제로 강제할 수 있는 경계(boundaries)를 갖출 자격이 있습니다. [Experimental] 속성의 제거는 CI/CD 파이프라인의 차단을 해제하는 역할을 할 뿐입니다. 여러분의 토큰 비용(token bill)을 변화시키는 것은 바로 레이지 로딩(lazy-loading) 모델입니다.

릴리스 포스트에서는 스킬(skills)을 에이전트가 "작업에 필요할 때만" 로드하는 "지침, 참조 문서, 스크립트"의 패키지로 설명합니다. 이것이 중요한 역전(inversion)입니다. 모든 것을 항상 포함하고 있는 하나의 거대한 단일 프롬프트(monolithic prompt) 대신, 작은 베이스 프롬프트(base prompt)와 필요할 때 전달되는 전문 지식을 갖게 되는 것입니다.

구체적인 결과는 다음과 같습니다:

• 더 작은 베이스라인 프롬프트 (Smaller baseline prompts). 송장 정산(invoice-reconciliation) 도메인을 전혀 건드리지 않는 작업은 송장 정산 지침에 대한 비용을 지불하지 않습니다.
• 컨텍스트 오염 감소 (Less context poisoning). 한 도메인에 대한 지침이 관련 없는 작업으로 흘러 들어가는 것을 방지하며, 이는 단순한 비용 절감을 넘어 정확성(correctness) 측면에서의 승리입니다.
• 거버넌스 경계 (A governance seam). 스킬 경계(skill boundary)는 할당, 할당량 설정 및 라우팅(route)을 할 수 있는 지점을 제공합니다. 시스템 프롬프트 내부의 한 단락은 이를 제공하지 못합니다.

지연 로딩 (lazy-loading)이 제공하는 것과 제공하지 않는 것을 정확히 파악해야 합니다. 지연 로딩은 해당 스킬을 건너뛰는 호출에서 입력 토큰 (input tokens)을 줄여줍니다. 하지만 그 자체만으로는 작업별 비용 귀속 (per-task cost attribution)이나 보장된 비용 절감을 제공하지는 않습니다. 경계 (boundary) 설정은 직접 수행해야 하며, 에이전트는 전체 지출 측면에서 여전히 가장 예측 불가능한 패턴으로 남습니다. 왜냐하면 작업에 필요한 도구 호출 (tool calls) 횟수와 추론 단계 (reasoning turns)를 결정하는 것은 사용자가 아니라 모델이기 때문입니다.

릴리스 게시물은 로딩이 자동인 것처럼 설명하지만, 경계는 그렇지 않습니다.

게시물에서는 작업이 필요할 때만 스킬이 로드된다고 말하지만, 스킬 경계 설계의 책임은 사용자에게 있습니다. 범위가 잘못 설정된 스킬 — 즉, 모든 작업 설명과 그럴듯하게 매칭되는 스킬 — 은 모든 곳에서 로드되며, 결국 추가적인 간접성 (indirection)만 더해진 프롬프트 스터핑 (prompt stuffing) 상태로 되돌아가게 됩니다. 마이크로서비스 (microservices)를 설계하듯 스킬의 범위를 설정하십시오. 작성한 팀이 아니라, 그 스킬이 어떤 질문에 답하는지를 기준으로 범위를 정해야 합니다.

핵심 요약: 스킬 범위 설정 (skill scoping)은 Azure 에이전트가 실제로 필요로 하는 AI 비용 거버넌스 (cost governance)입니다. 단 하나의 프롬프트를 마이그레이션하기 전에 경계를 먼저 설계하십시오.

프롬프트 엔지니어링이 결코 해결할 수 없는 스킬의 해결책

기존의 패턴은 익숙합니다. 시스템 프롬프트 (system prompt)에 섹션 헤더가 늘어납니다. "형식 규칙 (Formatting rules)", "에스컬레이션 정책 (Escalation policy)", "도메인 용어집 (Domain glossary)". 그러다 두 번째 에이전트에게 용어집이 필요해지면 누군가 그것을 복사하여 붙여넣게 되고, 이제 버전 관리도 테스트도 없는 동일한 전문 지식의 서로 다른 두 복사본을 유지 관리하게 됩니다.

수천 토큰에 달하는 시스템 프롬프트는 단위 테스트 (unit test)가 불가능합니다. 버전 자체가 없기 때문에 버전 간의 동작 차이 (diff)를 확인할 수도 없습니다. 반면 스킬 패키지 (skill package)는 테스트가 가능하고, 버전 관리가 가능하며, 교체가 가능합니다. 그리고 이러한 차이는 토큰 계산보다 훨씬 더 중요합니다.

다음은 전후 비교이며, 업계 표준 입력을 사용한 예시적인 수학적 계산입니다. 실제 수치는 다를 수 있으므로 귀하의 데이터에 맞춰 조정하십시오. 5개의 도메인을 처리하는 4,000토큰 시스템 프롬프트는 600토큰의 기본 프롬프트와 각각 약 700토큰인 5개의 스킬로 변합니다. 이제 하나의 도메인을 다루는 작업은 4,000개의 인스트럭션(instruction) 대신 약 1,300개의 입력 토큰을 사용합니다. 귀하의 모델과 볼륨에 대해 Azure OpenAI 가격 페이지를 참조하여 직접 수치를 계산해 보십시오. 핵심은 특정 백분율이 아니라 곡선의 형태이며, 저는 임의로 만들어낸 수치를 제공하지 않을 것입니다.

결론: 만약 시스템 프롬프트에 섹션 헤더(section headers)가 있다면, 당신은 이미 Skills가 필요했던 것입니다.

Microsoft Agent vs Flow: 이번 릴리스가 경계선을 옮기는 지점

입장을 정하십시오. 귀하의 아키텍처 리뷰(architecture review)는 결정을 요구할 것이기 때문입니다. 프로세스가 고정되어 있고 단계가 알려져 있다면 흐름(Flows)이 승리합니다. 전문 지식이 자산 이면서 작업 경로가 진정으로 가변적일 때는 Skills를 갖춘 에이전트(Agents)가 승리합니다. 하나가 아닌 두 조건 모두를 충족해야 합니다.

팀들이 스스로를 속이는 지점은 바로 그 두 번째 조건입니다. 만약 도메인 지식은 매달 바뀌지만 프로세스가 안정적인 5단계 체인이라면, 당신에게는 에이전트가 필요하지 않습니다. 당신에게 필요한 것은 지식을 외부화하여 업데이트할 수 있는 흐름(flow)입니다. 전문 지식의 변화만으로는 제어 흐름(control flow)을 모델에 넘기는 것을 정당화할 수 없습니다. Power Automate 및 Copilot Studio의 세계에서, 그러한 절제력이 자동화를 감사 가능(auditable)하게 유지하며, 이는 여전히 유효한 원칙입니다. 저는 에이전트를 아예 구축하지 말아야 할 때라는 글에서 이 논거를 더 길게 설명했으며, 이번 릴리스는 그 내용 중 단 한 마디도 뒤집지 않습니다.

이번 릴리스가 변화시킨 점은 다음과 같습니다. .NET 환경에서 Flow(플로우) 방식을 지지하던 가장 강력한 논거였던 "에이전트(agents)는 아직 프로덕션 수준에서 안정적이지 않다"라는 주장을 제거했다는 것입니다. Agent Framework 내의 모든 Skill(스킬) 형태의 추상화가 Experimental 속성을 가지고 컴파일러 경고를 발생시키던 시절에는 그 반론이 타당했습니다. 하지만 이제 그 문제는 사라졌습니다.

리뷰 과정에서 제가 옹호할 패턴은 경계가 지정된 에이전트(bounded agent)입니다. 결정론적인 Flow를 에이전트가 호출할 수 있는 Skill로 래핑(wrap)하십시오. Skill 경계에서 권한 부여(authorization)를 강제하십시오. 도구 호출(tool-call) 반복 횟수를 제한하십시오. 컴플라이언스(compliance)가 중요한 경로는 반드시 Flow 내에 유지하십시오. Skill의 프리뷰 종료가 에이전트가 Flow를 이겼음을 의미하는 것은 아닙니다. 이는 에이전트의 예측 불가능성이 규제 대상 프로세스로 유출되지 않도록, 두 방식이 공존할 수 있는 거버넌스 경계(governance seam)를 제공한 것입니다.

핵심 요약(Takeaway): 변화율(rate of change)과 경로 가변성(path variability)을 함께 고려하여 결정하십시오. 지식(knowledge)은 매달 변하고 경로도 가변적이라면: 지식을 에이전트 내부의 Skill로 패키징하십시오. 지식은 변하지만 경로는 고정되어 있다면: Flow를 유지하고 지식을 외부화하십시오.

프로덕션 준비 완료(Production-ready)란 아키텍처 리뷰에서 승인을 받을 수 있음을 의미합니다

설계 문서(design doc)에 반영하기 전에 릴리스 문구를 주의 깊게 읽으십시오. 해당 포스트의 문구 그대로를 인용하자면, Skill은 "안정적이고 프로덕션 준비가 된 API를 통해" 제공되며 "[Experimental] 속성이 제거되었습니다." 이것이 명시된 주장입니다. 귀하의 거버넌스 위원회가 이를 Microsoft의 공식 지원 관점에서의 일반 가용성(GA, General Availability)으로 승인할지 여부는 블로그 헤드라인이 아니라 microsoft/agent-framework repo의 릴리스 노트를 통해 확인해야 할 사항입니다. 또한 현재의 API 표면(API surface)도 그곳에서 검증하십시오. 이전 포스트에 떠도는 프리뷰 시대의 시그니처(signatures)는 실제 출시된 것과 일치하지 않을 것이기 때문입니다.

어느 쪽이든 실질적인 장애물 제거(unblock) 효과는 확실합니다. CI/CD에서 억제된 컴파일러 경고가 발생하지 않습니다. 설계 문서에 "변경될 수 있음"과 같은 유보적인 문구를 넣을 필요도 없습니다. 이 두 가지 모두 기업 아키텍처 리뷰에서 지적 사항으로 등장하곤 했으나, 이제는 고려 대상에서 제외되었습니다.

이것이 Azure AI 참조 아키텍처 (Azure AI reference architecture)에서 차지하는 위치는 다음과 같습니다. 스킬 (skills)은 도메인 계층 (domain layer)이고, 에이전트 프레임워크 (Agent Framework)는 오케스트레이션 계층 (orchestration layer)이며, Azure OpenAI 또는 Foundry에서 호스팅되는 모델 (models)이 그 아래에 위치합니다. 설계 문서 (design doc)에 명시적으로 기록할 만한 세부 사항 하나는, 모델이 스킬을 호스팅하거나 실행하지 않는다는 점입니다. 모델은 도구 호출 (tool-calling)을 통해 스킬을 선택하고 매개변수화 (parameterize)하며, 나머지 작업은 사용자의 코드가 실행합니다. 보안 검토자 (security reviewers)들이 질문하기 전에 이 문장을 먼저 제시하십시오.

핵심 요약 (Takeaway): 안정성 마일스톤 (stability milestone)은 차단 요소의 해소이며, 지연 로딩 (lazy-loading) 모델은 이동해야 할 이유입니다.

패키징 모델 (packaging model)은 숨겨진 핵심 기능입니다

버전이 지정된 스킬 (versioned skills)은 팀 간에 전문 지식이 이동하는 방식을 변화시킵니다. 현재 에이전트의 전문 지식은 누군가가 Teams에 프롬프트 (prompt)를 복사하여 붙여넣는 방식으로 전달됩니다. 버전이 지정된 스킬 패키지 (skill package)는 NuGet 패키지가 작동하는 방식과 동일하게 전달됩니다. 즉, 고정(pinned) 가능하고, 차이점 비교 (diffable)가 가능하며, 사용자의 일정에 맞춰 업그레이드할 수 있습니다. 송장 팀 (invoicing team)이 특정 버전으로 invoice-rules를 게시하면, 다른 세 팀이 이를 소비하며, 업데이트는 복사-붙여넣기 캠페인 대신 버전 업 (version bump)을 통해 배포됩니다.

설계 문서에 이를 약속하기 전에 확인해야 할 한 가지 검증 사항이 있습니다. 버전 고정 (version pinning)이 프레임워크의 기능인지, 아니면 자체 패키지 피드 (package feed)를 통해 강제하는 규율 (discipline)인지 저장소 (repo)에서 확인하십시오. 릴리스 게시물에는 패키징 메커니즘 (packaging mechanics)이 명시되어 있지 않으며, 두 가지 답변 모두 실행 가능합니다. 규율을 부과하는 것은 무엇이든 귀하의 몫입니다.

정보에 기반한 추측 (Informed speculation, 명시됨)

Microsoft는 스킬 마켓플레이스 (skills marketplace)를 발표하지 않았으며, 릴리스 내용 중 무엇도 그것이 임박했음을 암시하지 않습니다. 하지만 패키징 모델은 NuGet이 패키지 갤러리 (package gallery)를 필연적으로 만들었듯이, 마켓플레이스의 가능성을 열어둡니다. 만약 스킬 레지스트리 (skills registry)가 출시된다면, 첫날부터 버전을 관리해 온 팀은 이미 게시 가능한 아티팩트 (artifacts)를 보유하게 될 것입니다. 프롬프트 블롭 (prompt blobs)을 가지고 있는 팀은 처음부터 다시 시작해야 할 것입니다.

핵심 요약 (Takeaway): 첫 번째 스킬을 만들 때부터, 설령 팀 외부로 나가지 않더라도 첫날부터 버전을 관리하십시오.

이것이 Semantic Kernel 플러그인 (plugins)을 어떤 상태로 두는가

나쁜 점은 없으며, Microsoft의 그 누구도 달리 말하지 않았습니다. 포지셔닝은 명확합니다. 플러그인 (plugins)과 함수 (functions)는 무언가를 수행하는 타입화된 도구 호출 (typed tool calls)인 **역량 (capabilities)**을 담고 있습니다. 스킬 (skills)은 에이전트가 이러한 역량을 잘 사용할 수 있도록 알려주는 지침과 참조 자료인 **전문 지식 (expertise)**을 담고 있습니다. 스킬은 플러그인을 래핑(wrap)하거나 노출할 수 있습니다. 이들은 경쟁 관계가 아니라 상호 보완적인 계층입니다.

Semantic Kernel 플러그인에 대규모 투자를 한 팀은 마이그레이션 프로젝트를 수행할 필요가 없습니다. 다만 한 가지 특정한 행동을 멈춰야 합니다. 바로 더 적절한 위치를 찾지 못했다는 이유로 참조 문서와 여러 문단으로 된 정책 텍스트를 플러그인 설명에 억지로 밀어 넣는 것입니다. 그러한 콘텐츠는 역량의 탈을 쓴 전문 지식이며, 스킬에 속해야 합니다. 이는 기업용 AI의 세 가지 컨텍스트 계층 (three context layers of enterprise AI) 뒤에 있는 계층화 논리와 동일합니다. 실행 (execution), 지식 (knowledge), 지침 (instructions)은 변경 속도가 서로 다른 별개의 자산이며, 이들을 혼합하는 것이 시스템을 유지 관리하기 어렵게 만드는 원인입니다.

핵심 요약: 플러그인에는 역량을, 스킬에는 전문 지식을 담으십시오. 이것이 Microsoft가 신호를 보내고 있는 수렴 지점입니다.

다음 단계로 진행할 사항

이번 주에 스킬 하나를 마이그레이션하는 것이 한 분기 동안의 평가를 수행하는 것보다 낫습니다. 이 연습은 다음 아키텍처 검토 (architecture review) 전까지 끝낼 수 있을 만큼 규모가 작으며, 검토자들이 존중하는 단 하나의 결과물인 '직접 측정한 수치'를 만들어낼 것입니다.

1. 비대해진 에이전트 하나를 선택하세요 (Pick one bloated agent) 시스템 프롬프트가 약 1,500 토큰을 넘고, 그 안에 최소 두 개의 구별 가능한 도메인 (domain)이 포함된 에이전트를 찾으세요. 프롬프트 내의 섹션 헤더가 여러분의 지도 역할을 할 것입니다.
2. 하나의 도메인을 스킬로 추출하세요 (Extract one domain into a skill) 하나의 도메인에 해당하는 지침과 참조 자료를 스킬 패키지 (skill package)로 이동시키세요. 이때 현재의 Skills API 형태를 프리뷰 시대의 블로그 샘플이 아닌, microsoft/agent-framework 리포지토리 (repo)를 기준으로 먼저 확인하십시오.
3. 전후를 측정하세요 (Measure before and after) 동일한 고정 테스트 프롬프트 세트를 두 버전 모두에 실행하여 작업당 입력 토큰 수를 비교하세요. 검토자가 확인할 수 있는 곳에 결과를 기록하십시오. 작업별 귀속 (per-task attribution)은 매달 발생하는 예산 경고보다 언제나 더 효과적입니다.
4. 버전 관리를 하세요 (Version it) 아직 아무도 사용하지 않더라도, 첫날부터 해당 스킬에 버전 번호와 변경 로그 (changelog) 항목을 부여하십시오.
5. 다른 한 팀과 공유하세요 (Share it with one other team) 버전이 지정된 패키지를 인접한 한 팀에 전달하고 무엇이 깨지는지 관찰하십시오. 그들이 겪는 통합 마찰 (integration friction)이 바로 여러분의 스킬 경계 검토 (skill-boundary review)이며, 이는 다섯 팀이 의존하게 된 이후보다 지금 하는 것이 훨씬 저렴합니다.

3단계의 경우, 작업별 토큰 지출 거버넌스 (per-task token spend governance)는 "스킬이 비용을 절감할 것이라고 생각한다"라는 막연한 추측을 차트 위의 실질적인 수치로 바꿔줍니다. 이번 주에 비대해진 프롬프트 하나를 버전 관리되는 스킬로 마이그레이션(migrate)하고, 토큰 차이 (token delta)가 스스로 논거를 증명하게 만드십시오.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 벤더 중립적인 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하실 수 있습니다.