Universal Document Converter는 이번 달 모든 사람이 스크린샷을 찍게 될 기술입니다. 하지만 이것은 잘못된 헤드라인입니다.

네, 이제 CAT Agent Skills gallery에는 Markdown, HTML, PDF, Word, PowerPoint, Excel, CSV 및 일반 텍스트를 Copilot Studio 에이전트 런타임(agent runtime)에 이미 포함된 라이브러리만을 사용하여 완전히 오프라인으로 변환하는 기술이 있습니다. 유용합니다. 솔직히 말해서, 기업용 문서를 처리하고자 하는 플랫폼이라면 당연히 갖춰야 할 기본 요건(Table stakes)입니다.

진짜 뉴스는 이것이 어떻게 존재하게 되었는가 하는 점입니다. 이 기능은 사양(spec)에 맞춰 구축된 것이 아니라 발견된 것입니다. 누군가가 샌드박스형 런타임(sandboxed runtime)이 이미 무엇을 포함하고 있는지 목록을 만들었고, 조각들을 찾아내어 조립한 뒤, 그 결과를 공개적인 Copilot Studio 기술 갤러리에 다시 기여했습니다. 이 루프(loop)는 전체 워크로드 클래스에 대해 Microsoft의 에이전트 대 플로우(agent vs flow) 계산법을 변화시키며, 만약 "문서 변환이 필요하다"는 질문에 대한 당신의 기본 답변이 여전히 "그것을 위한 플로우(flow)를 구축하자"라면, 그 기본 설정을 재검토해야 합니다.

Copilot Studio 에이전트 하네스(agent harness)의 실체

Copilot Studio 에이전트 하네스(agent harness)는 오케스트레이터(orchestrator)가 실행 시점에 기술(skills)에 부여하는 샌드박스형 런타임에 대해 커뮤니티가 붙인 이름입니다. 즉, 테넌트 경계(tenant boundary) 외부로 나가지 않고도 실제 계산 작업을 수행할 수 있는, 이미 설치된 라이브러리 세트를 갖춘 사전 프로비저닝된 환경(pre-provisioned environment)을 의미합니다.

아키텍처 리뷰에서 이를 인용하기 전에 주의할 점이 하나 있습니다. "에이전트 하네스(agent harness)"는 Microsoft의 공식 명칭이 아닙니다. Microsoft Learn에 문서화된 어휘는 에이전트(agents), 토픽(topics), 액션(actions), 지식(knowledge), 그리고 오케스트레이션(orchestration)입니다. 하네스(harness)라는 프레임워크는 커뮤니티 도구, 구체적으로는 런타임에서 실제로 사용 가능한 라이브러리와 기능이 무엇인지 목록화하는 Agent Harness Explorer라는 갤러리 기술에서 유래되었습니다. 이것은 일회성 해킹이 아니라 반복 가능한 플레이북(playbook)입니다. 이를 실행하여 목록을 얻고, 단 하나의 외부 종속성(external dependency) 없이 무엇을 구축할 수 있는지 파악하십시오.

두 번째 주의 사항이며, 이 점이 더 중요합니다. 라이브러리 인벤토리(library inventory)는 문서화된 계약(documented contract)이 아닙니다. 탐색기(explorer)가 스킬 작성자의 환경에서 드러낸 것은 해당 테넌트(tenant)의 해당 플랫폼 버전과 함께 배포된 내용일 뿐입니다. 이는 플랫폼 업데이트 사이에 변경될 수 있으며, Microsoft는 그 안정성에 대해 어떠한 보장도 하지 않습니다. 라이브러리에 의존하기 전에 인벤토리를 다시 실행하고, 매 단계(wave)가 끝날 때마다 다시 실행하십시오.

하네스(harness)를 맹목적으로 구축하는 안정적인 API로 취급하지 말고, 고정(pin)하고 검증해야 하는 버전 관리된 종속성(versioned dependency)으로 취급하십시오.

오프라인 전용 방식이 기업용 소구점(enterprise hook)인 이유

converter skill의 공개 페이지는 모든 아키텍트의 주의를 끌 만한 한 가지 주장을 하고 있습니다. 바로 변환 작업이 외부 네트워크 호출(external network calls) 없이 실행된다는 점입니다. 제3자 API가 없습니다. 보안 검토(security review)를 위한 새로운 벤더(vendor)도 필요 없습니다. 프로비저닝(provision), 순환(rotate) 또는 유출될 위험이 있는 API 키도 없습니다.

이를 일반적인 커넥터 기반 플로우(connector-based flow)와 비교해 보십시오. 모든 커넥터는 컴플라이언스(compliance) 담당자가 추적하고 승인해야 하는 데이터 경로입니다. 모든 프리미엄 커넥터는 라이선스 항목입니다. 모든 외부 서비스는 벤더 평가(vendor assessment) 대상입니다. CISO(정보보호최고책임자)에게 제안할 때는 "빠르다"는 말보다 "이미 샌드박스(sandboxed) 처리된 것만 사용한다"는 말이 더 효과적입니다. 이는 문자 그대로의 의미입니다. 거버넌스(governance) 논의를 할 때 성능(performance) 이야기가 아닌 데이터 유출(egress) 이야기로 시작하십시오.

하지만 오프라인 방식이 무엇을 제공하는지에 대해 정확히 파악해야 합니다. 왜냐하면 "외부 호출 제로"와 "테넌트 안전(tenant-safe)"은 같은 의미가 아니기 때문입니다.

데이터 유출 제로가 리스크 제로를 의미하지는 않습니다

오프라인 실행은 데이터 유출(data egress) 및 제3자 벤더 리스크를 제거합니다. 하지만 신원 리스크(identity risk, 에이전트가 어떤 권한으로 실행되는지), 스토리지 및 보존 문제(converted output이 어디에 저장되는지), 또는 악성 파일 리스크(테넌트 내에서 실행되는 PDF 파서(parser)는 여전히 PDF 파서입니다)를 제거하지는 않습니다. 또한 관측성(observability) 측면의 트레이드오프(trade-off)가 존재합니다. 샌드박스 내부에서 수행되는 작업은 커넥터 수준의 DLP(데이터 유출 방지) 검사를 우회하며, 이는 Purview 팀에게 섀도 프로세싱(shadow-processing) 사각지대를 만들 수 있습니다. 거버넌스가 가능하다는 것이 '기본적으로 보이지 않는 상태'가 괜찮다는 의미는 아닙니다.

규제 대상 문서를 처리할 때, 네이티브 방식의 기술(harness-native skills)은 플로우(flows)가 획득해야만 하는 거버넌스 우위를 기본적으로 갖추고 시작합니다. 이들은 거버넌스 면제(governance exemption) 상태에서 시작하는 것이 아닙니다.

Microsoft agent vs flow vs custom Azure build: 실제적인 결정 사항

현재의 입장은 다음과 같습니다: 독립적인 문서 변환(document transforms) 및 이와 유사한 샌드박스 완결형(sandbox-complete) 작업은 이제 에이전트 기술(agent skills)의 영역에 속합니다. 플로우(Flows)는 시스템 간 오케스트레이션(orchestration), 커넥터(connectors), 승인(approvals), 그리고 예약된 트리거(scheduled triggers) 측면에서 우위를 유지합니다. 커스텀 Azure 빌드(Custom Azure build)는 확장성(scale), SLA, 그리고 자체 모델이 필요한 모든 작업에서 우위를 유지합니다. 이것은 대체가 아니라 재세분화(re-segmentation)입니다. 저는 agent vs flow decision guide에서

• 트리거 모델 (Trigger model). 스킬은 오케스트레이터 (orchestrator)가 대화 또는 에이전트 실행 중에 이를 호출할 때 실행됩니다. 예약된 작업 (Scheduled jobs), 이벤트 트리거 (event triggers), 인바운드 웹훅 (inbound webhooks)은 여전히 플로우 (flow) 또는 Azure의 영역입니다.
• 승인 및 인간 참여 (Approvals and human-in-the-loop). 플로우 (Flows)가 이 패턴을 소유합니다. 에이전트 내부에서 승인 프로세스를 다시 구축하지 마세요.
• 감사 가능성 (Auditability). 감사인이 입력 및 출력값이 포함된 실행 이력이 필요하다면, 플로우 (flows)와 Azure가 현재 이를 제공합니다. 샌드박스 (Sandbox) 실행 로깅은 이보다 미흡합니다.
• 결정론 (Determinism). 오케스트레이터에 의해 호출된 변환 (conversion)은 오케스트레이터의 라우팅 (routing) 동작을 상속받습니다. 비즈니스 프로세스가 매번 동일한 경로를 요구한다면, 그것은 플로우 (flow)의 속성입니다.
• 볼륨 및 런타임 (Volume and runtime). 장시간 실행되거나 대량의 변환 작업은 에이전트 외부에서 처리해야 합니다. 스킬 (Skills)은 이번 분기에 설정된 하네스 (harness)의 실행 제한 사항을 상속받습니다.
• 교차 시스템 도달 범위 (Cross-system reach). 작업이 Dataverse, SAP 또는 외부 API에 닿는 순간, 오프라인의 이점은 사라지고 커넥터 계산 (connector calculus) 문제가 다시 발생합니다.

만약 작업이 승인 게이트 없이, 대화형 볼륨으로, 대화 중에 호출되는 독립적인 변환 (transform)이라면: 스킬 (skill)을 우선시하세요. 그 외의 모든 것은 기존의 플레이북 (playbook)을 유지하세요.

Copilot Studio 스킬 갤러리는 사이드바가 아니라 전략입니다

Copilot Studio, Cowork, 그리고 Scout 스킬을 아우르는 GitHub 호스팅 기반의 공개 Copilot Studio 스킬 갤러리는 특정한 신호를 보냅니다. Microsoft의 CAT 팀은 파트너가 통제하는 카탈로그가 아니라, 개방적인 기여 스트림 (contribution stream)을 원한다는 것입니다. 컨버터 (converter)가 커뮤니티 발견 단계에서 리스팅된 갤러리 스킬로 발전했다는 것은, "샌드박스에서 기능을 발견"하는 것부터 "모두를 위해 패키징"하는 단계까지의 루프가 이미 공개적으로 작동하고 있음을 의미합니다.

이는 또한 신뢰 모델(trust model)에 대해서도 알려줍니다. 커뮤니티 갤러리에는 커뮤니티 리뷰 기준이 존재합니다. 특정 기술(skill)이 프로덕션 테넌트(production tenant)에 적용되기 전에 해당 기술의 소스를 감사(audit)하십시오. 이는 npm 패키지에 적용하는 규율과 정확히 일치합니다. 무엇을 임포트(import)하는지, 무엇을 쓰는지, 그리고 출력이 어디에 도달하는지를 읽어보십시오. 갤러리가 Microsoft GitHub 조직(org) 아래에서 호스팅된다는 것은 리포지토리(repo)의 출처(provenance)를 증명하는 것이지, 모든 기여분에 대한 보안 검토를 의미하는 것은 아닙니다.

갤러리를 업스트림 오픈 소스(upstream open source)로 취급하십시오. 가치 있고, 빠르게 움직이며, 검증은 여러분의 몫입니다.

이번 주에 해야 할 일

"하네스(harness) 안에 놓인 라이브러리"와 "갤러리에 나열된 기술(skills)" 사이의 간극이 바로 단기적인 기여 및 컨설팅 가치가 존재하는 지점입니다. 먼저 여러분의 테넌트에서 이 간극을 메우십시오.

1. 갤러리에서 Agent Harness Explorer 가져오기: CAT Agent Skills 갤러리에서 explorer 기술을 가져오고, 다른 커뮤니티 패키지와 마찬가지로 실행하기 전에 소스를 검토하십시오.
2. 개발 테넌트에서 인벤토리(inventory) 실행하기: 기술 작성자의 라이브러리 목록을 여러분의 목록으로 신뢰하지 마십시오. 그들의 실행에서 나타난 것은 시작 단계의 가설일 뿐이며, 여러분의 테넌트와 플랫폼 웨이브(platform wave)가 실제 사실입니다.
3. 현재 워크로드와 차이점 비교(Diff)하기: 라이브러리 인벤토리를 여러분의 플로우(flow) 및 Azure Functions 자산과 대조하십시오. 커넥터(connector) 도달 범위가 없는 독립형 변환(self-contained transform)인 항목은 모두 표시하십시오.
4. 기술 후보군 선정하기: 문서 변환(document conversion)은 이미 검증된 카테고리입니다. 다음으로는 이미지 처리, 데이터 재구성(data reshaping), 그리고 아직 아무도 패키징하지 않은 파싱(parsing) 라이브러리를 살펴보십시오.
5. 거버넌스(governance)에 패턴 등록하기: 샌드박스 네이티브 기술(sandbox-native skills)은 커넥터 수준의 검사를 우회하므로, 비공식적으로 확산되기 전에 여러분의 탐색 및 제어 프로세스에 포함시키십시오.

마지막 단계는 선택 사항이 아닙니다. 커넥터에 닿지 않고 실제로 작업을 수행하는 기능들은 조용히 성장하는 바로 그런 종류의 것들이며, 여러분의 섀도 AI 거버넌스(shadow AI governance) 프로세스는 감사인이 발견하기 전에 이들을 먼저 파악해야 합니다.

다음에 주목할 사항

이것이 플랫폼의 결정적 순간(platform moment)이 될지, 아니면 단순한 각주로 남을지는 두 가지 요소에 달려 있습니다.

첫째, 갤러리에 버전 관리(versioning)와 보안 인증(security attestation)을 포함한 공식적인 제출 및 검토 프로세스가 도입될 것인지, 아니면 느슨한 기여 스트림(contribution stream) 상태로 남을 것인지 여부입니다. 둘째, Microsoft가 harness library 인벤토리를 공식적으로 문서화할 것인지 여부입니다. 해당 목록이 Microsoft Learn에 지원 성명과 함께 등장하는 날, 탐험가(explorer)가 열었던 역공학(reverse-engineering)의 시대는 끝나고, 스킬(skills)은 고고학 프로젝트가 아닌 일급 빌드 대상(first-class build target)이 될 것입니다.

분명히 의견임을 밝히며 제 견해를 말씀드리자면: 만약 Microsoft가 이 두 가지를 모두 공식화한다면, 이는 Copilot Studio의 앱 스토어 모먼트(app store moment)가 될 것입니다. 만약 그렇지 않다면, 커뮤니티 리포지토리(community repos)를 읽는 사람들을 위한 영리한 호기심 정도로 남을 것입니다. 어느 쪽이든, Microsoft의 에이전트 대 플로우(agent vs flow) 결정에는 이제 탐험가를 한 번 실행하는 비용만으로 확인할 수 있는 세 번째 입력값이 생겼습니다. 바로 '이미 무엇이 설치되어 있는가'입니다. 다음 자동화 빌드를 시작하기 전에 실행해 보십시오. 가장 저렴하고 통제 가능한(governable) 옵션은 종종 테넌트(tenant)를 떠날 필요가 없었던 바로 그 옵션입니다.

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