Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Copilot Studio vs Teams Toolkit: Copilot 에이전트에는 어떤 도구를 선택해야 할까? (AI 더빙)

Transcript

Copilot Studio vs Teams Toolkit: Copilot 에이전트에는 어떤 도구를 선택해야 할까? (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365 코파일럿을 도입하는 것은 마치 전설적인 아이템을 얻은 기분이지만 사실 그건 시작에 불과하다는 것을 곧 깨닫게 됩니다.
0:06
기본 상태에서는 모델의 기초 지식과 테넌트 내부의 콘텐츠를 기반으로 작동합니다.
0:10
유용하긴 하지만 먼지가 쌓인 SOP, 인사 매뉴얼, 구석에 숨겨진 거대한 ERP 시스템은 어떻게 할까요?
0:16
커넥터, 그라운딩, 사용자 지정 에이전트 없이는 코파일럿 이 그것들을 활용할 수 없습니다.
0:19
다행인 점은 그것들을 학습시킬 수 있다는 것입니다.
0:22
관건은 언제 코파일럿 스튜디오를 사용하고 언제 팀즈 툴키드로 전환할지 그리고 거버넌스, 모니터링, 나이선싱을 어떻게 운영할지 아는 것입니다.
0:28
진짜 반전은 이제부터입니다.
0:29
첫 번째 에이전트를 구축하는 것이 최종 보스전은 아닙니다.
0:32
그저 튜토리얼이 끝난 것 뿐입니다.
0:34
빌드 자체가 보스전은 아닙니다.
0:36
첫 에이전트를 테스트하고 프롬프트가 작동하며 데모 데이터가 깔끔해 보이면 잠시 게임을 클리어했다는 기분이 듭니다.
0:41
그게 바로 함정입니다.
0:42
진짜 작업은 그 빌드를 프로덕션 환경에 적용할 때 시작되며 그곳은 완전히 다른 규칙으로 돌아갑니다.
0:46
너무 많은 제작자가 테스트해서 깔끔한 답변이 나오면 임무 환수라고 착각합니다.
0:50
사실 그건 쉬움 난이도의 스토리 모드일 뿐입니다.
0:52
프로덕션 환경은 여러분의 개발 노트북에서 개념 증명이 잘 작동했는지 따지지 않습니다.
0:57
프로덕션이 요구하는 것은 스트레스 상황에서의 안정성이며 컴플라이언스 검사, 아이디 가드레일, 가동시간 표준이 늘 뒤따릅니다.
1:04
이제 여기서 첫 번째 보스 몬스터들이 등장합니다.
1:07
확장성, 에이전트가 엔터프라이즈 부하를 문제없이 처리할 수 있을까요?
1:11
거기서 코파일럿 제어 시스템의 모니터링 및 진단 로그가 중요해집니다.
1:14
오래된 그라운딩, 시어포인트나 데이터버스 위 데이터가 변경될 때 에이전트가 올바른 스냅샷을 계속 유지할까요?
1:20
커넥터와 그래프 그라운딩이 그 안전장치입니다.
1:23
컴플라이언스와 감사 가능성입니다.
1:25
규제기관이나 내부 감사자가 확인을 요청할 때 완벽한 로그와 민감도 레이블을 갖춘 에이전트 기록을 검토할 수 있을까요?
1:32
이 중 하나라도 실패하면 승리의 화면은 순식간에 사라집니다.
1:35
코파일럿 스튜디오에서 테스트를 실행하는 것은 무한 체력 포션이 있는 훈련장에서 대련하는 것과 같습니다.
1:40
주문을 외우고 프롬프트를 바꿔도 모든 게 화려해 보이지만 실제 사용 시에는 방화벽 차단으로 주문이 실패하고 외부 데이터 소스 과부하로 응답이 거북이 걸음이 됩니다.
1:50
바로 그 순간 사용자는 이를 스마트하다고 부르는 대신 티켓을 발행하기 시작합니다.
1:54
가장 흔한 실패 사례는 거버넌스를 미루는 팀들에서 나옵니다.
1:58
나중에 챙기면 된다고 생각하지만 거버넌스를 미루는 것은 거의 항상 불쾌한 놀라움으로 돌아옵니다.
2:03
확장성 문제, 데이터 불일치, 컴플라이언스 공백은 꼭 필요한 순간에 나타납니다.
2:08
보안과 컴플라이언스는 선택적인 사이드 퀘스트가 아닙니다.
2:11
캠페인 맵의 필수적인 부분입니다.
2:12
이제 아키텍처에 대해 이야기해봅시다.
2:14
코파일럿 위 두뇌는 단일 블록이 아니기 때문입니다.
2:16
기반 모델인 원시 언어 엔진이 있고, 그 위에는 어떤 함수가 언제 호출될지 정렬하는 오케스트레이터가 있습니다.
2:22
마이크로소프트 365 코파일럿은 기본적으로 이러한 오케스트레이션을 제공함으로 모든 요청에 구조가 갖춰집니다.
2:27
다음은 적지, 그라운딩인데, 이는 답변이 조작되지 않도록 엔터프라이즈 콘텐츠와 연결하는 역할을 합니다.
2:31
마지막으로 실제 작업을 수행하는 맞춤형 플러그인 이나 커넥터인 기술, 스킬즈, 이 있습니다.
2:36
이 4가지 요소를 분리된 사일로로 취급하면 전체 타워가 흔들리게 됩니다.
2:40
적지가 없는 견고한 기술은 그저 화려한 환각에 불과합니다.
2:43
규정 준수 제어가 없는 기반은 부채가 됩니다.
2:46
이 계층들이 하나의 스택으로 처리될 때만 에이전트는 견고하게 유지됩니다.
2:49
그렇다면 실제 환경에서의 성공이란 어떤 모습일까요?
2:52
데모 프롬프트에 깔끔하게 답하는 것과는 다릅니다.
2:54
그건 연습 모드일 뿐입니다.
2:55
성공의 증표는 급여 처리 중, 데이터 마이그레이션 진행 중, 규정 준수 담당자의 감시 하에 높은 요청 부하를 견뎌내는 것입니다.
3:02
그때 비로소 에이전트가 실행될 자격이 있음을 입증하는 것입니다.
3:05
그리고 많은 빌드가 실패하는 또 다른 이유가 있습니다.
3:08
조직들이 이를 운영체제가 아닌 일회성 프로젝트로 생각하기 때문입니다.
3:11
누군가 프로토타입을 만들고 화려한 데모를 선보인 후 모니터링 없이 방치합니다.
3:15
곧 여러 부서가 각자의 것을 만들지만 문서화는 안 되어 있고 모두가 제어 없이 토큰만 소모하게 됩니다.
3:19
간단한 운영 매뉴얼 없이는 커넥터 소유자, 접지 감사자, 크레딧 사용량 확인자가 누구인지 알 수 없어 상황이 엉망진창이 됩니다.
3:28
관점을 바꾸면 훨씬 쉬워집니다.
3:30
운영 마인드 셋으로 시작하면 설계가 바뀝니다.
3:33
첫 번째 테스트가 깔끔했는지 애만 신경 쓰지 않게 됩니다.
3:35
일상적인 캠페인을 위해 시스템을 강화하게 됩니다.
3:38
감사 로그, 관리자 게이트, 백업, 상태 확인은 압박 속에서도 신뢰를 구축하고 시스템을 유지합니다.
3:43
관리자는 이미 마이크로소프트 365 관리센터에서 사용 가능한 제어 기능을 통해 시나리오를 관리하고 진단 피드백을 조기에 확인할 수 있습니다.
3:50
이러한 도구에 의존하는 것이 일회성 에이전트와 신뢰할 수 있는 운영자를 구분지는 기준입니다.
3:54
그렇기에 에이전트를 빌드했다고 해서 승자가 되는 것은 아닙니다.
3:57
테스트 환경은 1단계에 불과합니다.
3:59
거버넌스와 모니터링이 갖춰진 실제 배포가 진정한 생존의 시작입니다.
4:03
그 길로 너무 깊이 들어가기 전에 싸움에 필요한 올바른 무기가 있어야 합니다.
4:07
마이크로소프트는 서로 다른 규칙을 가진 두 가지 키트를 제공합니다.
4:10
잘못 선택하면 레이드의 플라스틱 검을 들고 가는 기분이 될 것입니다.
4:14
코파일럿 스튜디오와 팀즈 툴킷 중에서 무기를 선택해야 합니다.
4:17
거기서 진짜 질문이 시작됩니다.
4:19
어떤 도구를 선택하시겠습니까?
4:21
코파일럿 스튜디오일까요?
4:22
아니면 마이크로소프트 365 에이전트 툴킷이라고도 불리는 팀즈 툴킷일까요?
4:26
둘 다 코파일럿을 확장한다고 해서 비슷해 보이지만 서로 다른 유형의 개발자와 요구사항을 대상으로 합니다.
4:30
잘못된 선택은 시간과 예산을 낭비하게 만들며 실전에서 데모가 제대로 작동하지 않을 경우 신뢰도 마저 잃을 수 있습니다.
4:34
코파일럿 스튜디오는 제작자를 위한 공간입니다.
4:37
속도와 명확성을 위해 설계된 로우 코드 시각적 빌더입니다.
4:40
드래그 앤 드롭 방식의 흐름, 템플릿, 안내형 대화, 내장된 분석 기능을 제공합니다.
4:44
스튜디오에는 마이크로소프트 365 데이터 소스에 연결하는 다양한 커넥터가 포함되어 있어 파워 유저는 코드를 한 줄도 작성하지 않고 시어포인트 콘텐츠를 가져오거나 팀즈 메시지를 모니터링하거나 인사 정책 문서를 제공할 수 있습니다.
4:55
마이크로소프트 365 코파일럿에 직접 테스트하고 수정하여 개시하거나 최소한의 단계로 독립형 에이전트로 출시할 수도 있습니다.
5:03
내년 회계 연도가 아닌 이번 분기에 작동하는 워크플로우가 필요한 부서에게 스튜디오는 가장 빠른 길입니다.
5:09
이미 16만 개 이상의 고객사가 재무 데이터 조정, 직원 온 보딩, 소매업 제품 문외응대 등 바로 이 목적으로 스튜디오를 사용하고 있습니다.
5:17
그 이유는 복잡하지 않습니다.
5:18
진입장벽을 낮춰주기 때문입니다.
5:20
팀이 이미 파워 앱스를 다루거나 파워 오토메이트로 일상적인 보고서를 자동화하고 있다면 스튜디오는 아주 익숙한 환경이 될 것입니다.
5:26
소프트웨어 엔지니어가 아니어도 명확한 목표와 기본적인 로우코드 능력만 있다면 클릭과 구성, 배포가 가능합니다.
5:32
이제 팀즈 툴키드로 넘어가 보겠습니다.
5:34
이곳은 풀스택 개발자가 역량을 발휘하는 곳입니다.
5:36
툴키드는 드래그 앤 드롭 캔버스가 아닌 데코드에 통합됩니다.
5:39
여기서는 구조화된 규칙을 가진 선언적 에이전트를 설계하거나 한 걸음 더 나아가 오케스트레이션 모델 호출과 API 처리를 처음부터 직접 정의하는 커스텀 엔진 에이전트를 만들 수 있습니다.
5:48
코파일럿 내부뿐만 아니라 팀즈, 마이크로소프트 365 앱, 웹, 외부 채널 전반에 걸쳐 스케폴딩, 디버깅, 구성, 개시 경로를 확보할 수 있습니다.
5:57
코파일럿 스튜디오가 카탈로그에서 고른 조립식 가구라면 툴키드는 직접 한 자를 자르고 배선을 설계하여 집을 지는 것과 같습니다.
6:03
자유도는 엄청나지만 그만큼 모든 못 하나와 퓨즈 하나까지 직접 책임져야 합니다.
6:06
진정한 혼란은 둘 다 코파일럿을 확장한다고 말한다는 점입니다.
6:09
실제로 스튜디오는 마이크로소프트가 정의한 가드레일, 안전한 커넥터, 관리자 제어 및 가벼운 거버넌스 범위 내에서 확장하는 것을 의미합니다.
6:17
툴키드는 가드레일을 다시 작성하고 직접 오케스트레이션을 구현하고 외부 LLM을 호출하거나 마이크로소프트가 기본적으로 제공하지 않는 에이전트 동작을 구축하는 것을 의미합니다.
6:25
하나는 템플릿으로 안전함을 보장하고 다른 하나는 강력한 권한을 부여하며 이를 책임감 있게 다룰 것을 요구합니다.
6:30
많은 사람이 도구 선택이 UI 위 차이로 이어진다고 생각합니다.
6:33
아닙니다. 최종 사용자는 에이전트를 스튜디오로 만들었든 툴키드로 만들었든 동일한 프롬프트 창과 답변 카드를 보게 됩니다.
6:38
이는 의도된 것으로 UX계층은 통일되어 있습니다. 실제로 바뀌는 것은 보이지 않는 뒷단입니다.
6:43
그라운딩 옵션, 확장성, 그리고 관리 제어 방식입니다.
6:46
그렇기 때문에 이 결정은 거칠애가 아닌 운영상의 문제입니다.
6:49
실질적인 규칙을 하나 알려드리겠습니다.
6:51
셰어포인트 콘텐츠, 팀제 채팅 및 회의, 내장 파일, 데이터버스 데이터, 이메일 및 인물 검색 커넥터와 같은 일부 접지, 그라운딩.
6:58
기능은 테넌트에서 마이크로소프트 365 코파일럿 라이선스를 보유하거나 코파일럿 스튜디오 미터링이 활성화된 경우에만 작동합니다.
7:04
해당 권한이 없다면 스튜디오를 선택해도 그런 기능을 사용할 수 없습니다.
7:08
이 라이선스 확인 여부 하나가 어떤 경로를 선택할지 결정하는 핵심 요소가 될 수 있습니다.
7:11
그렇다면 어떻게 선택을 단순화할 수 있을까요?
7:13
간단한 체크리스트를 만들어보세요.
7:15
첫째, IT 부서에 위존하지 않고 파워 유저가 직접 구축할 수 있는 빠르고 감사 가능하며 관리자가 제어하는 에이전트가 필요하신가요?
7:20
그렇다면 코파일럿 스튜디오를 선택하세요.
7:21
둘째, 사용자 지정 오케스트레이션, 외부 AI 모델 또는 기업의 핵심 시스템과 직결되는 신층적 인통합 작업이 필요하신가요?
7:27
그렇다면 에이전트 툴킷을 선택하세요.
7:28
셋째, 이름에 현혹되지 말고 팀의 실제 기술 역량과 목표를 믿으세요.
7:32
저는 주택건설에 비유하곤 합니다.
7:33
스튜디오는 조립식 주택과 같아서 색상과 캐비닛은 직접 고르지만 배관과 배선은 이미 안전하게 갖춰져 있습니다.
7:38
툴킷은 빈 땅과 같아서 모든 것을 직접 설계해야 하지만 설계가 잘못될 경우 발생하는 모든 위험도 직접 감수해야 합니다.
7:43
둘 다 멋진 집을 완성할 수 있습니다.
7:44
하나는 더 빠르고 덜 복잡하며 다른 하나는 한계가 없지만 제대로 관리하지 않으면 취약할 수 있습니다.
7:48
둘 다 접지, 그라운딩 없이는 무너집니다.
7:50
어떤 도구를 선택하든 구축은 가능하지만 올바른 데이터를 입력하지 않으면 자신있게 헛소리만 더 빨리 생성할 뿐입니다.
7:55
커넥터가 없는 스튜디오 에이전트는 앵무새일 뿐입니다.
7:57
접지되지 않은 툴킷 에이전트는 코드로 작성된 앵무새일 뿐입니다.
8:00
어느 쪽이든 사용자에게 추측성 답변만 늘어놓는 새와 함께하는 셈입니다.
8:03
이것이 바로 모든 에이전트의 생명줄, 즉 에이전트가 불안전한 정보로 점쟁이 노릇을 하지 않도록 붙잡아주는 데이터 연결의 중요성입니다.
8:10
에이전트를 접지하고 공허함이 아닌 지식으로 두뇌를 채워야 합니다.
8:14
접지는 에이전트가 가짜 지혜를 멈추고 실제 지식을 활용하기 시작하는 지점입니다.
8:18
올바른 소스를 제공하면 에이전트는 허풍에서 벗어나 검증 가능한 답변을 내놓기 시작합니다.
8:22
이를 생략하면 겉으로는 완벽해 보이던 답변도 도대체 그 답이 어디서 나온 거죠? 라는 질문 하나에 금방 무너지고 맙니다.
8:28
마이크로소프트 365코파일럿은 이미 마이크로소프트 그래프를 통해 볼 수 있는 데이터를 기반으로 작동합니다.
8:32
파일, 채팅, 회의, 심지어 일정 이벤트까지 포함됩니다.
8:35
그것은 좋은 시작이지만 가장 가치 있는 콘텐츠는 그 핵심 범위를 넘어선 곳에 있습니다.
8:40
ERP는 재고를 CRM은 고객 수명 주기를 관리하며 HR은 셰어포인트 깊숙한 곳의 플레이북을 법무팀은 보안 폴더에 정책 문서를 보관합니다.
8:48
이러한 소스에 에이전트를 접지하지 않으면 검증 가능한 정보 대신 일반 모델의 지식만으로 자신있게 추측할 것입니다.
8:55
이들을 연결하는 것은 단순한 드래그 앤 드롭이 아니라 세심한 배관 공사와 같습니다.
8:59
코파일럿 스튜디오와 마이크로소프트 그래프 커넥터를 사용하면 셰어포인트 위 저장된 문서, 데이터버스 위 구조화된 테이블, 익스체인지 위 메일 기록, 팀즈 위 채팅 내용까지 접근할 수 있습니다.
9:08
마이크로소프트 위 핵심 서비스를 넘어 파워 플랫폼을 통한 1200개 이상의 커넥터가 외부 시스템으로 연결되는 통로를 열어줍니다.
9:14
재무, 인사, 티켓팅 등 무엇이든 가능합니다.
9:16
기성 제품이 맞지 않는다면 미리 구축된 커넥터가 없는 업무용 앱도 api를 통해 연결할 수 있습니다.
9:22
올바르게 구축된 에이전트는 해당 저장소에서 최신 정보를 가져와 문맥과 함께 제시합니다.
9:26
마법처럼 보이는 것은 그저 잘 설계된 파이프라인 덕분입니다.
9:29
한 가지 주의할 점이 있습니다.
9:30
일부 그라운딩, 그라운딩 옵션을 기본적으로 무료로 제공되지 않습니다.
9:33
셰어포인트 콘텐츠, 팀즈 미팅, 이메일, 데이터버스와 같은 소스에 접근하려면 종종 테넌트에서 코파일럿 나이선스 나미터링 활성화가 필요합니다.
9:40
이 권한이 없으면 커넥터가 작동하지 않으며 AI 비서가 가장 중요한 데이터 중 일부를 인식하지 못하게 됩니다.
9:46
단순한 스위치 조작만으로 모든 것이 해결될 것이라 생각하지 마십시오.
9:49
먼저 라이선스 맵을 확인하세요.
9:50
인사, HR, 헬프 데스크 예시를 생각해봅시다.
9:52
누군가가 육아 휴직 정책이 무엇인가요? 라고 묻습니다.
9:55
그라운딩이 없으면 에이전트는 일반적인 모델 지식을 바탕으로 그럴듯한 답변을 조립합니다.
9:59
도움이 되는 것처럼 들리지만 출처 링크나 증거가 없습니다.
10:02
그라운딩이 적용되면 에이전트는 시어포인트에서 실제 정책을 찾아 문서 제목을 참조하고 핸드북으로 연결되는 인용 링크를 제공할 수 있습니다.
10:08
이런 작은 차이가 검증되지 않은 진술을 감사관과 인사팀이 승인할 수 있는 신뢰할 만한 답변으로 바꿉니다.
10:13
이러한 감사추적이야말로 진정한 성능 형상 요소입니다.
10:15
그라운딩된 답변에는 사용자와 규제기관을 원본소스로 안내하는 인용구가 포함될 수 있습니다.
10:20
컴플라이언스 팀에서 보시 왜 그런 답변을 했는지 물을 때 길게 설명할 필요가 없습니다.
10:23
로그가 그 과정을 보여줍니다.
10:25
여기에 프롬프트가 있습니다.
10:26
여기에 가져온 문서가 있습니다.
10:28
여기에 생성된 답변이 있습니다.
10:29
운에 맡길 필요는 없지만 모든 연결은 곧 위험요소이기도 합니다.
10:32
인사 데이터에 허술하게 연결하면 공개된 FAQ와 함께 비공개 직원 기록이 노출될 수 있습니다.
10:37
ERP 접근 권한을 잘못 설정하면 어느 순간 영업사원이 급여 정보를 보게 될 수도 있습니다.
10:42
이러한 실수들은 운영상 치명적인 오류입니다.
10:44
더 안전한 방법은 그라운딩 계획에 민감도 레이블과 퍼뷰 분류 체계를 계층화하는 것입니다.
10:49
그렇게 하면 에이전트는 데이터 분류를 무시하는 대신 권한 규칙에 맞는 콘텐츠만 검색하여 데이터 보완을 준수하게 됩니다.
10:55
경고는 간단합니다.
10:56
그라운딩 되지 않은 에이전트는 권위있게 거짓을 만들어내고 잘못 그라운딩된 에이전트는 외부로 유출되어서는 안 될 정보를 노출합니다.
11:02
어느 쪽이든 회사에 로고를 걸고 오류를 퍼뜨리거나 민감한 세부 정보를 유출하는 결과를 낳게 됩니다.
11:06
퍼뷰와 같은 거버넌스 도구가 존재하는 데에는 이유가 있습니다.
11:09
데이터 커넥터와 분류 체계를 첫날부터 함께 구성하세요.
11:11
그렇지 않으면 나중에 인식 문제와 컴플라이언스 문제로 골머리를 앓게 될 것입니다.
11:15
그러니 교훈은 분명합니다.
11:16
그라운딩, 그라운딩은 고급 부가 기능이 아닙니다.
11:25
이를 뒷받침하는 로그로 근거를 확보할 수 있습니다.
11:27
잘못 수행하면 티켓을 생성하기도 전에 조직 전반의 환각현상과 데이터 유출이 확산될 수 있습니다.
11:32
그렇기에 다음 과제 또한 매우 중요합니다.
11:34
그라운딩된 에이전트 하나는 관리할 수 있기 때문입니다.
11:36
감독 없이 수십 개의 에이전트가 방치되면 진짜 문제가 시작됩니다.
11:39
거버넌스는 에이전트가 통제불능 상태가 되기 전에 확산을 막는 것입니다.
11:43
여기서 거버넌스란 코파일럿 에이전트가 무질서하게 변하는 것을 방지하는 규칙 세트입니다.
11:48
누가 에이전트를 만들 수 있는지, 어디서 실행되는지, 어떤 데이터에 접근할 수 있는지를 우연에 맡기지 않고 결정하는 방법입니다.
11:53
마이크로소프트는 이미 이를 강제할 도구를 제공하고 있습니다.
11:56
마이크로소프트 365관리센터의 코파일럿 제어 시스템, 파워 플랫폼 관리센터의 수명주기 관리, 민감도 레이블링 및 DLP를 위한 마이크로소프트 퍼뷰, 그리고 감사를 위한 코파일럿 진단 로그가 있습니다.
12:08
이들을 모래성이 무너지지 않게 지탱하는 4개의 기둥이라고 생각하십시오.
12:12
먼저 알아두어야 할 점은 코파일럿 시나리오 관리는 관리자 권한이 있다고 누구나 할 수 있는 일이 아니라는 것입니다.
12:17
전역관리자나 AI 관리자와 같은 특정 역할이 필요합니다.
12:20
최소 권한 원칙을 준수하여 본인도 모르는 사이에 큰 위험을 초래할 수 있는 권한을 함부로 부여하지 마십시오.
12:25
누가 스위치를 조작할 수 있는지 제안하는 것 자체가 하나의 거버넌스입니다.
12:28
그 다음, 사후 조치가 아닌 설계 단계부터 수명주기 규칙을 적용하십시오.
12:32
첫 번째 규칙, 누가 에이전트를 생성할 수 있는지 정의하고 이를 파워 플랫폼 관리센터의 환경과 연결하십시오.
12:37
두 번째 규칙, 365관리센터의 코파일럿 설정을 사용하여 누가 에이전트를 개시하고 릴리스를 승인하거나 차단할 수 있는지 정의하십시오.
12:44
세 번째 규칙, 에이전트가 실행될 수 있는 위치를 격리된 환경으로 할당하여 프로덕션 환경이 무방비로 노출되지 않게 하십시오.
12:50
네 번째 규칙, 크레딧 할당 방법을 정의하십시오.
12:53
이때 코파일럿 에이전트 사용량 측정기가 필요합니다.
12:56
이 측정기는 리소스가 너무 빨리 소진될 때 그 수치를 명확히 보여주고 누가 이를 사용하는지 알려줍니다.
13:00
퍼뷰는 문서와 메일 관리에 이미 사용 중인 규정 준수망이며 여기에서도 동일하게 작동합니다.
13:06
데이터의 민감도 레이블을 적용하면 에이전트가 소스에 연결되더라도 레이블이 응답까지 따라갑니다.
13:11
DLP 정책을 사용하여 에이전트가 응답 과정에서 기밀 필드를 노출하지 못하도록 차단하십시오.
13:16
보존 정책은 오래된 콘텐츠가 남지 않게 하여 에이전트가 몇 주 전에 만료되어 넣어야 할 데이터에 근거하지 않도록 합니다.
13:23
일단 안전장치를 설정하면 모든 에이전트가 자동으로 관리 체계를 상속받습니다.
13:27
대부분의 팀이 간과하는 또 다른 단계는 진단 로그 활성화입니다.
13:30
스위치를 켜면 모든 상호작용을 명확하게 파악할 수 있습니다.
13:34
프론프트, 응답, 콘텐츠 참조, 시스템 로그는 모두 나중에 사용할 수 있는 기록으로 남습니다.
13:39
관리자가 에이전트가 잘못된 지침을 내린 이유를 물으면 어깨를 으쓱하는 대신 기록을 다시 재생해볼 수 있습니다.
13:44
더 좋은 점은 최종 사용자가 직접 피드백을 보내지 않아도 관리자가 대신 로그를 제출할 수 있다는 것입니다.
13:49
그 덕분에 문제 해결이 사후 대응이 아닌 선제적 조치가 됩니다.
13:52
이는 혁신을 늦추려는 것이 아니라 혁신의 방향을 잡기 위한 것입니다.
13:54
스튜디오를 사용하면 파워 유저가 오후까지 쉽게 플로우를 만들 수 있고,
13:58
툴킷을 사용하면 개발자가 무거운 빌드를 프로덕션 환경으로 빠르게 배포할 수 있습니다.
14:01
제어 장치가 없으면 그런 속도는 중복과 모순을 야기합니다.
14:04
거버넌스가 갖춰지면 같은 속도로도 규정을 준수하고 모니터링되는 재사용 가능한 자산을 확보할 수 있습니다.
14:10
차이는 직원의 창의성이 아니라 직원을 둘러싼 프레임워크가 얼마나 체계적 인지에 달려있습니다.
14:15
비용 추적 또한 거버넌스의 일부입니다.
14:17
관리센터의 소비 측정기는 단순한 회계보기가 아니라 균형을 맞추는 다이얼입니다.
14:21
크레딧팩을 할당하고, 종량제 모델로 초과 사용량을 모니터링하며, 예산 범위 내에서 사용량을 유지할 수 있습니다.
14:26
이를 무시하면 크레딧이 소진되어 에이전트가 워크플로우 도중 갑자기 멈출 때 제한사항을 처음으로 실감하게 될 것입니다.
14:31
연료가 바닥난 상태에서 프로덕션 문제를 디버깅하고 싶지는 않을 것입니다.
14:34
거버넌스가 성공적으로 작동하면 마치 갑옷을 입은 것과 같습니다.
14:37
빌더들이 빠르게 움직일 수 있을 만큼 유연하면서도, 한 번이 실수로 전체 팀이 무너지지 않도록 보호해줍니다.
14:42
관리를 소홀히 하여 승인 없이 에이전트가 생성되도록 방치하면,
14:51
그리고 생존은 던전의 숨겨진 다음 함정으로 이어집니다.
14:56
거버넌스를 통제하더라도 다음 놀라운 일은 기술적인 문제가 아니라 재정적인 문제이기 때문입니다.
15:00
재무팀이 사용량을 확인할 때 관리자들이 식은땀을 흘리며 깨어나는 데는 다 이유가 있습니다.
15:04
잘 작동하는 빌드라도 청구서를 보는 순간 그 가치는 순식간에 퇴색됩니다.
15:07
라이선스와 비용, 그것은 미쳐보지 못한 함정카드입니다.
15:10
라이선스와 비용은 대부분의 팀이 이미 상황이 벌어진 후에야 깨닫게 되는 함정카드입니다.
15:15
마이크로소프트는 빠른 빌드와 화려한 데모라는 환상을 팔지만,
15:17
크레딧이 월중에 사라지거나 커넥터가 조용히 새로운 라이선스 요구사항을 추가하면 아무 소용이 없습니다.
15:22
이는 부수적 인사항이 아니라 관리해야 할 핵심 요소이며,
15:25
그렇지 않으면 사람들이 의존하기 시작하는 바로 그 순간 에이전트가 멈춰버릴 것입니다.
15:29
코파일럿 스튜디오는 코파일럿 크레딧으로 작동합니다.
15:32
크레딧팩을 구매하거나 페넌트 당월 약 200달러에 2만 5천 크레딧,
15:36
조직의 소비량에 따라 기간 종료 시 청구되는 종량제 측정 방식을 사용할 수 있습니다.
15:41
관대하게 들리지만 문서를 확인해보면 소비량이 일정하지 않다는 사실을 알 수 있습니다.
15:45
계층화된 요금제를 사용하는데, 표준비 생성형 작업은 비용이 적게 드는 반면 생성형 답변은 더 많은 비용이 소모됩니다.
15:51
정확한 수치는 마이크로소프트 위 라이선스 가이드에 따라 변경되므로,
15:55
청구 관련 문서를 빌드키트의 일부처럼 다루세요.
15:58
핵심은 테스트 프롬프트와 운영응답 모두 동일한 풀에서 차감된다는 점입니다.
16:02
시스템 어디에도 숨겨진 무료 샌드박스는 없으며, 아무리 간절히 원해도 마찬가지입니다.
16:06
크레딧은 테넌트 전체에 적용되므로,
16:08
인사팀에 온 보딩보디든, 영업팀의 거래지원보디든,
16:10
재무팀의 보고 어시스턴트 등 모든 에이전트가 동일한 풀을 사용합니다.
16:14
이러한 설계는 유연성을 제공하지만,
16:16
한 부서의 집중적인 테스트 작업이 다른 팀의 운영 리소스를 소진시킬 수 있음을 의미하기도 합니다.
16:20
풀이 비워지면 코파일럿 스튜디오는 속도를 제한하거나 부드럽게 경고하지 않습니다.
16:24
단순히 크레딧이 충전될 때까지 해당 에이전트를 일시 중지합니다.
16:28
다른 그룹이 밤새 테스트 루프를 돌려놓은 탓의 실시간 지원 보시 거래 도중,
16:32
멈춘 이유를 설명해야 하는 상황은 피하고 싶을 것입니다.
16:35
종량제 방식은 성결제를 피하고 싶을 때 유용하며, 해당 월에 실제로 소모한 만큼만 지불하면 됩니다.
16:40
하지만 측정기는 냉혹할 정도로 공정합니다.
16:43
간단한 프로토타입 테스트도 운영 워크플로와 동일한 방식으로 크레딧을 소모함으로,
16:47
예산 알림이 없으면 과도한 지출이 발생하기 매우 쉽습니다.
16:50
안전한 접근 방식은 테스트 빌드조차 크레딧 계획의 일부로 간주하여 일찍 한도를 설정하는 것입니다.
16:55
팀즈 툴킷 인하되 코드 위 에이전트 툴킷은 다른 관점을 취합니다.
16:59
제품군에 개시하면 사용자의 마이크로소프트 365 코파일럿 나이선스 하에서 작업이 실행됨으로 프롬프트당 크레딧이 보이지 않습니다.
17:06
스튜디오에 비하면 자유로워 보이지만 기본사항만 다룰 뿐입니다.
17:09
맞춤형 엔진 에이전트를 구축하거나 외부 서비스에 연결하는 순간 비용이 쌓이기 시작합니다.
17:14
api는 자체 측정기가 있고, 엔터프라이즈 커넥터는 별도의 나이선스가 필요한 경우가 많으며,
17:18
관리자 동의에 따라 예상치 못한 요금계층이 적용될 수도 있습니다.
17:21
스튜디오는 작업당 요금을 청구하고, 툴킷은 크레딧 모델을 우회하게 해줍니다.
17:25
하지만 두 경우 모두 비용은 어딘가로 정가됩니다.
17:27
이를 공짜가 아닌 상충관계라고 부릅니다.
17:29
실질적인 규칙은 팀즈 툴킷은 통합 및 서비스 계층에 비용을 숨기는 반면,
17:32
스튜디오는 크레딧으로 미리 지불하게 만든다는 것입니다.
17:35
어느 쪽도 모든 상황에서 더 저렴하지는 않습니다.
17:37
경로를 선택하기 전에 예상 워크플로우를 문서화된 가격 정책에 맞춰 맵핑해야 합니다.
17:41
쉐어포인트를 기반으로 한 가벼운 승인보순 스튜디오에서 크레딧을 적게 쓰며 효율적으로 운영될 수 있습니다.
17:46
외부 CRM과 크게 통합하는 경우,
17:48
N은 코파일럿 크레딧을 소모하는 대신 CRM 위 API 요금을 지불하더라도,
17:52
툴킷을 사용하는 것이 더 합리적일 수 있습니다.
17:54
중요한 것은 비용이 어디로 이동하느냐이지,
17:56
이를 완전히 피하는 방법이 아닙니다.
17:57
그렇다면 예상치 못한 비용 함정을 피하려면 어떻게 해야 할까요?
18:00
첫째, 코파일럿 에이전트 사용량 측정기나 종량제 보고서를 통해
18:03
테넌트 수준의 사용량 모니터링을 활성화하세요.
18:05
둘째, 예산이 소진되기 전에 재무 및 IT 부서의 알림이 가도록 경고 임계값을 설정하세요.
18:11
셋째, 지정된 크레딧팩이나 명확한 내부 정책을 통해 사업부별로 예산을 할당하여,
18:15
한 팀이 단일 스프린트에서 예산을 전부 소진하지 않도록 하세요.
18:18
이 세 가지 제어장치만으로도 대부분의 당혹스러운 상황을 줄일 수 있습니다.
18:21
확장 개발은 또 다른 계층을 추가합니다.
18:23
통합에는 종종 명시적인 관리자 동의가 필요하며,
18:26
각 동의는 기본적으로 새로운 비용을 발생시킬 수 있습니다.
18:28
테스트 중에 연결한 외부 API는 마이크로소프트가 아닌 여러분에게 비용을 청구합니다.
18:33
설계 단계에서 라이선스와 커넥터를 목록화하고,
18:36
배포 전에 각각의 비용 지불 주체를 확인하는 것이 현명한 방법입니다.
18:38
이를 단순히 기능적인 관점이 아닌 비용 측면의 변경 관리로 다루십시오.
18:42
라이선스는 약관의 세부 사항이 아니라 아키텍처의 일부입니다.
18:44
레이드에서 토큰을 사용하듯 신중하게 크레딧을 소비하세요.
18:47
무분별하게 사용해서는 안 됩니다.
18:49
시작부터 적절한 라이선스를 갖추고 사용량을 모니터링하며,
18:52
새로운 커넥터마다 통합 비용이 발생할 것임을 예상하세요.
18:54
사람들이 에이전트에 의존할 때 항상 이용 가능하게 만들 여면이 중 어느 하나도 선택사항이 아니면,
18:59
이것이 마지막 단계로 이어집니다.
19:01
에이전트 구축, 기반 마련, 거버넌스 및 자금 조달은 필수적인 점검 사항이지만,
19:05
진정한 성공은 운영이 아니라 장기적인 캠페인 유지에 있습니다.
19:08
바로 그 지점에서 최종적인 관점이 가장 중요해집니다.
19:10
결론은 이렇습니다.
19:12
성공은 화려한 데모가 아니라,
19:13
에이전트가 무분별하지 않고 유용하게 작동하도록 규칙을 따르는 데 있습니다.
19:16
첫째, 빌드 경로를 혁명하게 선택하세요.
19:18
로우코드 속도를 위한 코파일러 스튜디오,
19:20
완전한 사용자 지정 엔진과 더 깊은 제어를 위한 팀즈 툴킷이 있습니다.
19:23
둘째, 출시 시점부터 거버넌스를 확립하세요.
19:25
개시하기 전에 퍼뷰 레이블, 관리자 역할, 진단로그 및 사용량 모니터링을 모두 활성화해야 합니다.
19:30
셋째, 지출을 계획하세요.
19:31
스튜디오는 페넌트 전체 크레딧팩이나 종량제 측정기를 사용하지만,
19:35
툴킷은 외부 API 및 서비스로 비용을 전환합니다.
19:37
이상입니다.
19:38
구독과 알림 설정을 누르고 댓글을 남겨주세요.
19:40
다음 퀘스트를 위해 스튜디오와 툴킷 중 무엇을 선택하시겠습니까?