Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Business Central에 사용자 지정 Copilot 기능 등록하기: AL, 메타프롬프트, 안전한 Azure OpenAI 키 관리 (AI 더빙)

Transcript

Business Central에 사용자 지정 Copilot 기능 등록하기: AL, 메타프롬프트, 안전한 Azure OpenAI 키 관리 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
비즈니스 센트럴 이 결제 조정이나 제품 문구 작성 같은 지루한 작업을 대신 처리해주기를
0:04
그래서 클릭 한 번이라도 줄이고 밤늦게까지 엑셀과 실음하는 고통에서 벗어나길 바란 적 있으신가요?
0:09
그것이 바로 코파일럿 이 약속하는 가치입니다.
0:11
물어보기 전에 미리 말씀드리자면 추가 비용 없이 비즈니스 센트럴 온라인에 기본 내장되어 있습니다.
0:15
단, 온프레미스 환경에서는 작동하지 않으니 기대하지 마세요.
0:18
한 가지 조건이 있습니다.
0:19
대부분의 관리자는 뻔한 데모 영상만 보고 넘어갑니다.
0:22
오늘은 코파일럿이 핵심을 파헤쳐서 여러분의 비즈니스에 맞게 활용하는 방법을 알려드리겠습니다.
0:25
영상을 끝까지 보시면 샌드박스에서 즉시 테스트해볼 수 있는 운영 체크리스트를 가져가실 수 있습니다.
0:30
모든 것은 마이크로소프트가 거의 언급하지 않는 숨겨진 메뉴에서 시작됩니다.
0:33
코파일럿 위 비밀 메뉴, 코파일럿 위 진정한 힘은 고객 카드에 보이는 화려한 버튼에 있는 것이 아닙니다.
0:38
진짜 핵심은 마이크로소프트가 그 이면에 남겨둔 기능들입니다.
0:42
시스템 AI 네임스페이스 안에서 그 확장 지점들을 찾으실 수 있습니다.
0:45
코파일럿 기능 코드 유닉과 관련 열거형, 이뉴, 을 찾아보세요.
0:48
개발자를 위한 실제 후크, 후크가 그곳에 존재합니다.
0:50
이것들은 코드 베이스에 있는 단순한 부속품이 아닙니다.
0:53
마이크로소프트 가분기마다 새로운 데모를 내놓기를 기다리는 대신
0:56
여러분이 직접 AI 기반 기능을 정의하고 등록할 수 있도록 만들어진 것입니다.
1:00
대부분의 사용자가 접하는 메뉴는 빙산의 일각일 뿐입니다.
1:02
총장 데이터를 입력하고 요약본을 얻거나 제품 설명을 초안으로 작성하는 정도죠.
1:06
물론 좋습니다.
1:07
하지만 그것들은 작동한다는 것을 보여주기 위한 데모 시나리오일 뿐입니다.
1:10
실제로 비즈니스 센트럴 위 내부에는 코파일럿 기능과 코파일럿 가용성 같은 객체들이 들어 있습니다.
1:15
쉽게 말해 기능, 케이퍼빌리티은 여러분이 코파일럿을 위해 만드는 기술 세트입니다.
1:19
가용성, 어베일러빌리티은 그 기술이 최종 사용자에게 언제, 어디서 나타나야 하는지를 시스템에 알려줍니다.
1:24
이 두 가지가 합쳐지면 단순한 AI 위젯 모음 그 이상의 것이 됩니다.
1:28
여러분의 회사에 최적화된 코파일럿을 만들기 위한 프레임워크인 셈이죠.
1:31
여기서 중요한 점이 있습니다.
1:32
대부분의 관리자는 코파일럿 이마치 화려한 블랙박스처럼 완전히 잠겨있다고 생각합니다.
1:35
제공된 기능만 사용하고 대수롭지 않게 넘겨버리죠.
1:38
추가적인 제어 기능이 있는지 찾아보려 하지 않습니다.
1:40
하지만 개발자 수준에서는 조작할 수 있는 네버가 열려있습니다.
1:43
네, 개발자가 등록한 결과를 관리자가 실제로 확인할 방법도 있습니다.
1:46
비즈니스 센트럴 내의 코파일럿 및 에이전트 기능 페이지로 이동해보세요.
1:50
여러분이 등록한 모든 기능이 그곳에 나타납니다.
1:53
관리자는 문제가 발생하면 해당 기능을 하나씩 끌 수 있습니다.
1:56
개발자는 AL로 정의하고 관리자는 UI에서 관리하는 이 연결고리가
2:00
단순한 이론을 실전으로 만들어주는 발의 역할을 합니다.
2:03
이것을 잠긴 애플 기기처럼 생각하지 말고
2:05
숨겨진 디버그 명령어가 있는 콘솔처럼 생각하세요.
2:07
메인 코파일럿 버튼만 클릭하고 있다면
2:09
여러분은 엄청난 잠재력을 낭비하고 있는 것입니다.
2:12
마치 테슬라를 운전하는데 교통체증 때문에 조금씩 앞으로 나아가는 것과 같습니다.
2:16
루디크러스 모드 스위치는 있지만
2:17
켜지 않으면 그냥 공회전하는 것뿐이죠.
2:19
여기서도 마찬가지입니다.
2:21
레임스페이스 개체는 이미 여러분의 테넌트에 있지만
2:23
어디를 봐야 할지 모르면 절대 사용할 수 없습니다.
2:25
그렇다면 어느 정도의 성능을 기대할 수 있을까요?
2:28
비즈니스 센트럴 내의 AI 모듈은 텍스트 완성,
2:31
워크플로우 시나리오를 위한 채팅 방식의 완성,
2:33
시멘틱 검색을 위한 인베딩 기능을 제공합니다.
2:35
즉 예를 들어 마이크로소프트 위 가정 대신
2:38
우리 회사의 패턴에 따라
2:39
구매 주문서를 초안으로 작성하는 기능을 구축할 수 있다는 뜻입니다.
2:42
또한 딱딱한 인사과 메모가 아닌
2:44
우리 회사의 고유한 말투로 말하는 어시스턴트를 만들 수도 있습니다.
2:48
시작하기 전에 간단히 언급할 사항이 있습니다.
2:50
비즈니스 센트럴에서 보셨을지 모를
2:52
코파일럿 미리 보기 채팅 기능은 이 모듈을 통해 확장할 수 없습니다.
2:55
해당 채팅은 별도의 경로를 따릅니다.
2:56
확장 가능한 부분은 여기서 설명하는 기능 모델을 통해 이루어집니다.
3:00
마이크로소프트는 마케팅 측면에서 이를 제대로 알리지 못했습니다.
3:03
문서에는 나와 있지만
3:03
관리자들이 거의 보지 않는 건조한 기술 섹션 깊숙이 숨겨져 있죠.
3:07
하지만 이러한 개체가 존재한다는 것을 알게 되면 상황은 달라집니다.
3:10
모든 재무적 특이사항, 기묘한 사용자 지정 필드,
3:13
복잡한 승인 워크플로우 등 모든 것을
3:14
자신만의 코파일럿 기능으로 해결할 수 있습니다.
3:17
레드몬드에서 기능을 내려주길 기다리는 대신
3:19
자신의 환경에 맞춰 어시스턴트를 조정할 수 있습니다.
3:22
물론 이렇게 강력한 기능에는 항상 경고 문구가 따르기 마련입니다.
3:25
이것들은 날카로운 도구와 같습니다.
3:27
기능을 잘못 등록하면
3:28
특히 마이크로소프트가 업데이트를 배포할 때 충돌이 발생할 수 있습니다.
3:31
잘못 처리하면 갑자기 샌드박스가 망가지거나
3:33
더 나쁘게는 프로덕션 환경의 사용자를 차단할 수도 있습니다.
3:35
그렇기 때문에 코파일럿 및 에이전트 기능 페이지가 중요합니다.
3:38
이 페이지는 관리자에게 가시성을 제공할 뿐만 아니라
3:40
사용자 지정 브레인이 오작동할 경우
3:42
즉시 중단할 수 있는 킬 스위치 역할도 합니다.
3:44
따라서 여기서 얻는 이점은 간단합니다.
3:45
네, 코파일럿 아래에 숨겨진 메뉴가 있습니다.
3:48
네, 이미 모든 테넌트에 포함되어 있죠.
3:50
네, 코파일럿을 단순한 데모용 장난감에서 유용한 도구로 바꿔주지만
3:53
존재를 아는 것은 첫 단계일 뿐입니다.
3:55
진정한 비결은 환경을 망가뜨리지 않으면
3:57
서화력을 추가할 수 있도록 안전하게 기능을 등록하는 것입니다.
4:00
이제 다음 단계로 넘어가겠습니다.
4:02
테넌트를 망가뜨리지 않고 등록하는 방법입니다.
4:05
코파일럿 기능을 등록하는 것은
4:07
모호한 마법 같은 기술이 아닙니다.
4:09
알기 쉬운 AL 용어로 말하면
4:10
코파일럿 기능 이뉴에 대한 이뉴 확장을 만들고
4:13
코파일럿 기능을 호출하는 설치 또는 업그레이드 코드 유닛을 사용하는 것입니다.
4:17
기능을 등록하세요.
4:18
그것은 비즈니스 센트럴에게
4:19
여기 새로운 AI 기능이 있으니 라고 알리는 악수와 같습니다.
4:22
시스템의 일부로 취급하세요.
4:24
그 호출이 없으면 확장 프로그램은 컴파일될지 몰라도
4:26
코파일럿은 해당 기능의 존재조차 알지 못합니다.
4:28
인사과에 서류를 제출하는 과정이라고 생각하세요.
4:31
조직도의 기록이 없으면
4:32
책상도, 이메일도, 직원도 없는 것과 마찬가지입니다.
4:35
기본 정의를 마쳤다면
4:36
다음 단계는 범위와 명명규칙입니다.
4:39
등록하는 모든 기능은
4:40
마이크로소프트가 끊임없이 업데이트하는 동일한 생태계에서 작동합니다.
4:44
일반적인 이름을 재사용하거나 대충 아이디를 지정하면
4:46
충돌을 자초하는 셈입니다.
4:48
예를 들어 세일즈 헬퍼라고 부르고
4:49
흔한 열거형 값을 할당했다고 가정해봅시다.
4:51
그러다 마이크로소프트가 나중에 같은 공간에
4:53
내장 기능을 포함한 업데이트를 배포합니다.
4:55
갑자기 시스템은 무엇을 표시해야 할지 혼란을 겪고
4:57
런타임에 여러분의 코드가 레드몬드와 충돌하게 됩니다.
5:00
이를 방지하는 방법은 지루하지만 필수적입니다.
5:02
고요한 이름을 선택하고
5:03
공통 범위와 겹치지 않는 자체 열거형 값을 할당하며
5:06
확장 프로그램의 버전을 신중하게 관리하세요.
5:08
버전 번호를 추가하면 샌드박스는 1.2 버전인데
5:10
프로덕션은 아직 1.0에 머물러 있는지 추적할 수 있습니다.
5:13
플랫폼의 변화가 생길 경우
5:15
업그레이드 코드 유닛은 기능을 안전하게 이어갈 수 있는 도구입니다.
5:19
그게 없으면 낡은 차단기함에
5:20
새 배선을 테이프로 감아 연결하면서
5:22
불이 나지 않기만을 바라는 꼴입니다.
5:24
이제 많은 개발자가 안일하게 생각하는 부분이 나옵니다.
5:27
단지 기능 하나일 뿐이라며
5:28
확장 프로그램을 바로 프로덕션에 던져넣는 것이죠.
5:30
그때부터 헬프데스크에 문의가 쏟아지기 시작합니다.
5:32
올바른 길은 단순합니다.
5:33
먼저 샌드박스에서만 작업하세요.
5:35
문제를 찾고 리팩토링하고
5:36
다시 테스트한 다음 제대로 작동할 때만 프로덕션으로 옮기세요.
5:38
그렇게 통제된 배포가 예상치 못한 문제를 줄여줍니다.
5:41
이건 단순히 코드를 컴파일하는 문제가 아니라
5:43
거버넌스에 관한 문제입니다.
5:44
비즈니스 센트럴 위 코파일럿 및 에이전트 기능 페이지는
5:47
여러분의 확인 절차 역할을 합니다.
5:48
등록 후 그곳에 기능이 보이지 않는다면
5:50
제대로 등록되지 않은 것입니다.
5:52
그 페이지가 시스템의 진실을 그대로 보여줍니다.
5:55
거기서 확인을 마친 후에야 관리자 검토를 요청해야 합니다.
5:58
관리자 이야기가 나와서 말인데
6:00
코파일럿 기능을 켜거나 끄고
6:02
데이터 이동을 구성하는 작업은
6:04
슈퍼 권한을 가진 관리자나
6:05
비즈니스 센트럴 관리자 역할만 수행할 수 있습니다.
6:08
해당 거버넌스 단계를 미리 계획하세요.
6:10
간단한 팁을 드리자면
6:12
등록할 때 런 모어 URL 옵션 매개변수를 사용하세요.
6:16
그러면 코파일럿 및 에이전트 기능 관리 페이지에 바로 나타납니다.
6:19
단순히 보기 좋은 기능이 아니라
6:21
문서가 내장되는 것입니다.
6:23
관리자가 위키링크를 찾거나
6:24
팀제로 질문하지 않아도
6:26
기능의 목적과 사용방법을
6:28
즉시 클릭해서 확인할 수 있습니다.
6:30
다음 사람이 실수하지 않도록
6:32
스위치에 직접 사용법을 적어두는 것과 같습니다.
6:35
위험을 줄일 수 있는 모범 사례 체크리스트를 소개합니다.
6:37
첫째, 운영 환경 전에 모든 것을 샌드박스에서 실행하세요.
6:40
둘째, 고유한 열거형 값을 선택하고
6:42
일반적인 범위는 피하세요.
6:44
셋째, 향후 깔끔한 경로를 위해
6:46
항상 설치 업그레이드 단위를 사용하세요.
6:47
넷째, 관리자가 나중에 추측하지 않도록
6:50
관련 학습 URL을 첨부하세요.
6:51
이 네 가지를 따르면
6:52
페넌트를 안정적으로 유지할 수 있습니다.
6:54
무시하면 새벽 3시에 데이터베이스를 복구하게 될지도 모릅니다.
6:57
주차 공간 비유는 여전히 유효합니다.
6:59
기능 등록은 새 차를 위해
7:00
공식적으로 자리를 예약하는 것과 같습니다.
7:03
올바른 서류를 작성하면
7:04
자리가 확보되고 모두가 행복합니다.
7:06
절차를 건너 뛰거나 금지 구역에 주차하면
7:08
소방차 통로를 막게 되어
7:09
모두가 화를 낼 것입니다.
7:10
등록은 기능이 비즈니스 센트럴 및
7:12
마이크로소프트 업데이트와
7:13
장기적으로 공존할 수 있도록
7:15
안전한 공간을 마련하는 것입니다.
7:16
결론적으로 등록을 운영 코드처럼 바로 세요.
7:19
그것이 바로 운영 코드이기 때문입니다.
7:21
샌드박스에서 테스트하고
7:22
범위를 고유하게 유지하며
7:23
버전을 추적하고
7:24
업그레이드 코드 단위를 완벽하게 만드세요.
7:26
이상한 일이 발생하면
7:27
관리자는 코파일럿 및 에이전트 기능 페이지와
7:29
학습 URL을 통해 기능을 찾고
7:31
이해하고 필요하다면 중단할 수 있습니다.
7:34
제대로 등록하면 안정적인 기반을 다질 수 있습니다.
7:37
대충 등록하면 혼란을 초래하게 됩니다.
7:39
등록을 마쳤다면 기능 자체는 작동하지만
7:41
다소 일반적이라는 점을 알게 될 것입니다.
7:43
답변은 하지만 개성이 없습니다.
7:45
이는 뛰어난 인재를 채용했는데
7:47
회의 내내 음소거 상태로 있는 것과 같습니다.
7:49
다음 단계는 코파일럿이 어떻게 행동할지 가르치는 것입니다.
7:52
그렇지 않으면 신뢰할 수 있는 비서가 아니라
7:54
질문에 눈을 흘기는 10대처럼 보일 것입니다.
8:06
마이크로소프트 개발자 문서에 따르면
8:07
메타 프롬프트는 모델의 프로필,
8:10
출력 형식,
8:11
가드레일을 정의하는 기본 시스템 메시지입니다.
8:13
쉽게 말해
8:14
AI 위 직무 기술서입니다.
8:16
일회성 사용자 프롬프트는 단일 작업 요청과 같지만
8:18
메타 프롬프트는 모든 응답에 반영되는 상시지침입니다.
8:22
이것이 없으면 코파일럿은 자신이 회계사처럼 들려야 할지
8:24
카피라이터처럼 들려야 할지 알 수 없습니다.
8:26
그저 추측할 뿐입니다.
8:27
이렇게 생각해보세요.
8:28
역할 설명도 없이 사람을 채용하지는 않을 것입니다.
8:31
메타 프롬프트는 AI에게 바로 그런 역할을 합니다.
8:34
코파일럿에게 언제 격식을 갖출지,
8:36
결과를 어떻게 구성할지,
8:37
어떤 어조를 사용할지,
8:38
절대 피해야 할 것이 무엇인지 알려줍니다.
8:40
그 차이가 워크플로우에 딱 맞는 답변과
8:42
의견이 섞인 낡은 클리피 같은 답변을 결정짓습니다.
8:45
관리자는 종종 메타 프롬프트와 프롬프트를 혼동하여 좌절하곤 합니다.
8:50
상황 설명 없이 원장 항목을 알려줘,
8:52
라고만 하면 코파일럿은 자신만의 스타일을 만들어낼 것입니다.
8:55
어쩌면 긴 단락으로 답하거나
8:56
존재하지 않는 필드를 가져올지도 모릅니다.
8:59
동일한 요청을,
8:59
당신은 재무 어시스턴트이며,
9:01
항상 비즈니스 센트럴 필드의 이름을 사용하여
9:02
원장 항목을 글머리 기호 목록으로 출력하라,
9:04
와 같은 메타 프롬프트로 감싸보세요.
9:06
예시 1분입니다.
9:07
그러면 갑자기 답변이 깔끔하고 구조적이며
9:09
정리된 상태로 나옵니다.
9:10
요청이 실행되기도 전에 가드레일이 설정됩니다.
9:13
마이크로소프트는 위도적으로 이러한 구분을 만들었습니다.
9:16
프롬프트는 일시적인 요청인 반면,
9:17
메타 프롬프트는 전체 채팅 컨텍스트 전반에 걸쳐 지속됩니다.
9:20
개발자는 Set Primary System Message를 호출하여
9:23
AOAI 채팅 메시지 코드 유닛을 통해 이를 설정합니다.
9:27
메타 프롬프트 자체를 격리된 스토리지에 저장하면
9:29
AL 파일의 텍스트를 하드코딩하는 대신
9:31
확장해서 이를 안전하게 검색하고 업데이트할 수 있습니다.
9:34
문서를 훑어보셨다면, 아이솔레이티드 스토리지 Set과
9:37
아이솔레이티드 스토리지 겟을 사용하는 예제를 보셨을 겁니다.
9:40
그것이 프로덕션을 위한 올바른 모델입니다.
9:42
메타 프롬프트를 사용 가능하게 유지하면서도
9:44
확장 프로그램의 보안 경계 뒤에 안전하게 잠가둡니다.
9:46
이제 핵심적인 내용을 살펴보겠습니다.
9:48
비즈니스 센트럴 위 AI 모듈을 통해
9:50
에이저 오픈아이 서비스로 사용자 입력을 보낼 때는 좋든 싫든
9:53
토큰 예산과 온도 설정을 다뤄야 합니다.
9:55
토큰 예산은 중요합니다.
9:57
메타 프롬프트와 사용자 프롬프트를 합친 값이
9:59
모델의 토큰 제한에 포함됩니다.
10:00
그러니 소설불량의 시스템 메시지를 쑤셔 넣지 마세요.
10:03
정확하게 유지하세요.
10:04
그리고 온도는 무작위성을 제어합니다.
10:06
결정문적이고 필드가 정확한 출력이 필요한 재무시나리오의 경우
10:09
온도를 0에 가깝게 낮게 설정하세요.
10:11
마케팅 기능을 구축 중이고 더 다채로운 초안을 원한다면
10:13
온도를 높여 AI가 즉흥적으로 생성하게 하세요.
10:16
이건 추측이 아닙니다.
10:17
빌드 가이드에 명시되어 있습니다.
10:19
또 다른 규정 준수 알림입니다.
10:20
감사인은 여러분의 창의성에 관심이 없습니다.
10:22
그들은 숫자가 일치하는지에 관심이 있습니다.
10:25
메타 프롬프트에는 명시적인 형식 규칙, 응답 구조,
10:28
불필요한 해설에 대한 제한사항이 포함되어야 합니다.
10:30
그래야 코파일럿의 출력이 사용자에게 보기 좋을 뿐만 아니라
10:32
다운스트림 시스템과 감사 과정을 통과할 수 있습니다.
10:35
메타 프롬프트를 문서화의 일부이자 리스크 관리의 일부로 대하세요.
10:39
성격불리는 이 작업에 재미있는 부분입니다.
10:41
마케팅 코파일럿 위 메타 프롬프트는
10:42
설득력 있는 언어를 사용하고
10:43
제품 슬로건을 브레인스토밍 하라고 지시할 수 있습니다.
10:50
에이아이는 같지만 성격을 미리 정의했기 때문에
10:53
완전히 다른 결과가 나옵니다.
10:54
그것이 실용적인 자동화와 아무도 사용할 수 없는
10:56
형식적인 출력물 사이의 차이점입니다.
10:58
이 섹션이 매너에 관한 내용이라 할지라도
11:00
기술적인 기반을 무시해서는 안 됩니다.
11:02
메타 프롬프트는 에이저와의 연결이
11:04
올바르게 설정되었을 때만 작동합니다.
11:06
에이아이는 비즈니스 센트럴에서 이를 로컬로 처리하지 않습니다.
11:09
모든 것을 에이저 오픈하이 백엔드를 통해 전달합니다.
11:11
그 파이프라인이 망가지면 규칙을 아무리 잘 작성해도 소용없습니다.
11:14
오류가 발생하거나 더 심하게는 키가 잘못 작동할 수도 있습니다.
11:17
결론적으로 프롬프트는 요청일 뿐입니다.
11:19
메타 프롬프트는 기본 지침입니다.
11:21
정확히 작성하고 안전하게 저장하며
11:22
토큰 계산을 확인하고 작업에 맞게 온도를 설정하세요.
11:25
그렇게 해야 코파일럿을 무작위로 수다 떠는 도구에서
11:27
신뢰할 수 있는 역할별 비서로 바꿀 수 있습니다.
11:29
대충 처리하면 보고서에서 엉터리 내용을 편집하느라
11:32
밤을 지새우게 될 겁니다.
11:33
하지만 자격증명이 완전히 노출되어 있다면
11:35
아무리 잘 작성된 메타 프롬프트도 여러분을 구할 수 없습니다.
11:38
진정한 위험은 어조나 형식이 아니라
11:39
코파일럿 이 에이저 오픈아이와 통신할 수 있게 해주는 키를
11:43
어떻게 저장하고 보호하느냐에 있습니다.
11:45
키 보호하기, 올바른 에이저 보안의 시작입니다.
11:48
키를 보호하는 일은 화려해 보이지 않지만
11:49
테넌트를 안전하게 지키느냐, 사고 보고서를 작성하게 되느냐를
11:53
결정짓는 핵심입니다.
11:54
코파일럿 이 에이저 오픈아이를 호출할 때마다
11:56
세 가지가 항상 필요합니다.
11:58
리소스 엔드포인트, 에이저 오픈아이 리소스 URL, 배포 이름,
12:02
그리고 API 키입니다.
12:03
이 세 가지가 합쳐져야 테넌트가 모델과 대화할 권한이 있음을
12:06
증명하는 핸드쉐이크가 이루어집니다.
12:08
이 중 하나라도 노출되면 AI를 활용하는 것이 아니라
12:10
보안침의 시뮬레이션을 하는 셈입니다.
12:12
반도직입적으로 말해서 어떤 상황에서도
12:14
이 값들을 AL에 하드코딩하지 마십시오.
12:16
편의를 위해 API 키를 코드에 심거나
12:18
기터브에 올리면 사실상 크리덴셜 스캐너에게
12:21
리포지토리를 마음껏 털어가라고 초대하는 것과 같습니다.
12:24
개발자들은 단순히 테스트용이라며
12:25
대수롭지 않게 여길지 모르지만
12:26
리포지토리는 노출된 비밀을 찾기 위해
12:28
끊임없이 검색되고 있습니다.
12:29
그렇게 실제 고객 데이터가 외부 사이트에 유출되는 것입니다.
12:32
이는 패치 화요일, 패치 취지 데이, 업데이트로 해결할 수 있는 문제가 아닙니다.
12:35
안전한 경로에 대해서는 이미 마이크로소프트가 명확히 제시했습니다.
12:38
개발 및 테스트 작업 시에는 AL에 격리된 저장소
12:39
아이솔레이티드 스토리지를 사용해야 합니다.
12:41
확장 프로그램 안에 사물함이라고 생각하세요.
12:43
키를 넣어두면 다른 확장 프로그램은 절대 들여다볼 수 없습니다.
12:47
내용물을 안전하게 격리하며 가볍고 간편합니다.
12:49
샌드박스나 개발 빌드에는 완벽하지만
12:51
격리된 저장소가 프로덕션 수준은 아니라는 점을 잊지 마세요.
12:55
로컬 범위 덕분에 반복 작업에는 편리하지만
12:57
실제 사용자와 데이터가 걸린 상황에서
12:59
금고 역할을 하기에는 부족합니다.
13:01
하지만 프로덕션 환경으로 배포할 때는
13:02
F키 볼트나 대규모 배포 시 에이저키 볼트를 사용하는 것이
13:05
유일하게 책임감 있는 선택입니다.
13:07
이것은 현금을 책상 서랍 밑에 숨기는 대신
13:09
은행 금고를 대여하는 것과 같습니다.
13:11
키볼트는 적절한 로깅 및 교체 정책이 적용된
13:13
안전한 액세스 제어 컨테이너의 API 키를 보관합니다.
13:17
확장 프로그램을 여기에 통합하고
13:18
런타임에 필요한 것만 호출하며
13:20
원본 키는 절대 코드에 노출하지 마세요.
13:22
비밀이 평문으로 돌아다닌 적이 없음을 입증할 수 있기에
13:24
이는 감사관들이 가장 선호하는 패턴입니다.
13:27
지루한 거버넌스지만
13:28
컴플라이언스 팀이 들이닥칠 때는
13:30
바로 그 지루함이 꼭 필요합니다.
13:31
문서에서 바로 확인할 수 있는 차이를 만드는
13:33
세부사항 하나를 소개합니다.
13:35
AL에서는 API 키를 비밀 텍스트, 시크릿 텍스트로 저장할 수 있습니다.
13:39
이렇게 하면 디버깅을 단계별로 수행해도
13:41
키가 평문으로 노출되어 누군가 스크린샷을 찍을 일이 없습니다.
13:43
비밀 텍스트는 말 그대로의 기능을 합니다.
13:46
런타임 시 민감한 값을 숨겨줍니다.
13:48
이 섹션에서 다른 건 몰라도 이 옵션이 존재한다는 점은 꼭 기억하세요.
13:53
가장 어처구니 없는 유출 경로 중 하나인
13:55
디버거에서의 우발적인 개발자 노출을 차단합니다.
13:58
이제 실제 관리자들이 말하는 방식대로
14:00
해야 할 일과 하지 말아야 할 일을 명확히 짚어보겠습니다.
14:02
API 키를 AL 코드에 포함하거나
14:04
저장소, 리포에 붙여 넣지 마세요.
14:06
그건 자격증명을 탈취하라는 믿기나 다름 없습니다.
14:09
개발 및 테스트 시 애는 격리된 저장소를 사용하여
14:11
비밀 정보를 평문으로 전송하지 않고도 팀의 생산성을 유지하세요.
14:14
그 개발 패턴을 운영 환경까지 가져가지 마세요.
14:16
그건 금고가 아니라 서류 보관함일 뿐입니다.
14:18
운영 빌드는 반드시 키 자격 증명 모음, 키볼트에 연결하세요.
14:21
키가 장기적으로 보관되어야 할 유일한 장소입니다.
14:23
상식적인 점을 하나 더 말씀드리면
14:25
비즈니스 센트럴 내부의 사용자 권한이
14:26
API 키를 마법처럼 잠가주지는 않습니다.
14:28
코파일럿 이 비즈니스 데이터에 대한
14:30
액세스 제어를 상속받는 것은 맞지만
14:31
키는 서비스 전체를 인증하는 수단입니다.
14:33
키 하나가 유출되면 외부인이 통합 전체를 가장할 수 있습니다.
14:37
그러니 권한 범위 지정이 여러분을 구해줄 거라는 착각은 그만두세요.
14:40
전혀 그렇지 않습니다.
14:41
설정을 검증하고 싶다면
14:42
네이저 오픈 AI 코드 유닛의 권한 설정 순서를 따르는 것이
14:45
공식적인 방법입니다.
14:46
그곳에서 리소스 URL, 배포, API 키를 입력하여
14:49
모든 것이 일치하는지 확인해야 합니다.
14:51
잘못하면 코파일럿 이하에 로드되지 않을 것입니다.
14:54
어설프게 하면 여러분보다 사용자가 먼저 발견하는
14:56
침묵의 오류를 겪게 될 것입니다.
14:57
해결책은 간단합니다.
14:59
체인을 순서대로 따르고
15:00
개발 환경에서 깔끔하게 테스트한 뒤
15:01
프리 프로덕션과 운영 환경으로 넘기세요.
15:03
3개의 환경, 3개의 키 세트
15:04
그리고 부하 상황에서도 실제로 작동하는 하나의 파이프라인이 필요합니다.
15:07
문제를 피하기 위한 체크리스트는 다음과 같습니다.
15:09
개발 시 격리된 저장소 사용
15:11
운영 시 키 자격 증명 모음 사용
15:12
API 키는 비밀 텍스트로 감싸고
15:14
코드에 값을 포함하지 마세요.
15:16
그리고 작업을 마쳤다고 선언하기 전에
15:18
항상 권한 설정 체인을 끝까지 실행하세요.
15:20
이 패턴을 유지하면
15:21
한방중에 비상 후출을 받을 일 없이
15:23
코파일럿 통합을 안전하고
15:24
규정을 준수하며 운영할 수 있습니다.
15:26
보안 부분이 해결되었다면
15:28
다음 과제는 키를 어디에 숨길 것인가 보다는
15:30
모든 부품을 어떻게 연결하여
15:32
끊임없는 오류 메시지를 방지할 것인가에 대한 것입니다.
15:35
기능, 메타프롬프트
15:36
보안 키가 있어도 그것들이 사일로에 갇혀
15:38
서로 소통하지 못하면 별 소용이 없기 때문입니다.
15:40
바로 그 지점에서 워크플로 연결이 중요해집니다.
15:43
청사진에서 현실로
15:44
워크플로를 구성해보겠습니다.
15:45
이제 흩어진 요소들을
15:47
실제 작동하는 코파일럿 흐름으로 만드는 방법을 이야기하겠습니다.
15:51
기능을 등록하고
15:52
범위를 지정하며
15:53
키를 확보하고 메타프롬프트를 작성했습니다.
15:56
하지만 순서대로 배치하지 않으면
15:57
보기만 좋은 버튼이 되어
15:59
오류를 일으키거나
16:00
사용자가 무늬를 넣을 때까지
16:02
아무런 동작도 하지 않게 됩니다.
16:04
5가지 단계로 정리한 순서는 다음과 같습니다.
16:07
1단계
16:07
기능, 케이버빌리티
16:08
2단계
16:09
가용성, 어베일러빌리티
16:10
3단계
16:11
권한부여, 어서리제이션
16:12
4단계
16:13
메타프롬프트
16:13
메타프롬프트
16:14
5단계
16:14
파일럿, 파일럿
16:15
이 5가지를 기억하면 언제든 머릿속으로 연결구조를 그릴 수 있습니다.
16:19
기능은 기술을 제공하고
16:20
가용성은 대상을 설정하며
16:21
권한부여는 두뇌를 깨우고
16:22
메타프롬프트는 예절을 가르치며
16:24
파일럿은 실제 작동 여부를 확인합니다.
16:25
이것이 전체 루프입니다.
16:27
1단계
16:27
기능
16:28
AL에서 이는 코파일럿 기능 열거형을 확장하고
16:31
설치 또는 업그레이드 코드 유닛에서
16:33
코파일럿 기능을 호출하여 등록하는 것을 의미합니다.
16:36
기능을 등록하세요.
16:38
이는
16:38
여기 새로운 어시스턴트 기술이 있습니다.
16:40
라고 말하는 공식 채용 공고와 같습니다.
16:42
시스템에 자리를 마련해주세요.
16:43
그렇지 않으면 비즈니스 센트럴은
16:45
여러분의 기능이 존재하는지 조차 알지 못합니다.
16:48
2단계
16:48
가용성
16:49
기술이 정의되면
16:50
어디에 표시될지 범위를 지정합니다.
16:52
이는 코파일럿 및 에이전트 기능 관리 페이지를 통해
16:55
제어됩니다.
16:56
미리 보기
16:56
내부 전용 또는 일반 배포 중
16:58
무엇으로 표시할지 결정하세요.
17:00
개발자에게는 메타 데이터이지만
17:01
관리자에게는 배포를 위한 포글 스위치입니다.
17:04
사용하세요.
17:05
2단계를 건너뛰면
17:06
불안정한 기능을 모든 사용자에게
17:08
노출할 위험이 있습니다.
17:10
3단계
17:11
권한부여
17:11
권한부여
17:12
이제 에이저 오픈 AI 코드 유닛을 통해
17:14
에이저 오픈 AI 백엔드에 연결합니다.
17:16
에이저 오픈 AI URL
17:18
배포 이름
17:19
API 키라는 고전적인 3가지 리소스 엔드포인트가 필요합니다.
17:23
에이저 오픈 AI를 호출하세요.
17:25
해당 값으로 권한을 설정하세요.
17:28
기능이 채용 공고
17:29
이고 가용성이 계약이라면
17:30
권한부여는 어시스턴트가 건물에 들어오기 위한 출입증입니다.
17:34
없으면 기능은 유리문 앞에 머물게 됩니다.
17:37
4단계
17:37
메타 프롬프트
17:38
여기서 어조, 구조, 형식을 결정하는 상시지침을 주입합니다.
17:42
에이오 AI 채팅 메시지를 사용하세요.
17:45
기본 시스템 메시지를 설정하여
17:46
격리된 스토리지에 안전하게 저장하거나
17:48
키볼트에서 참조하는 메타 프롬프트를 가져옵니다.
17:51
이곳에서
17:52
당신은 견적지원 도우미입니다.
17:53
라고 말합니다.
17:54
또는
17:54
당신은 재무 도우미입니다.
17:56
라고 설정합니다.
17:57
그리고 출력 형식을 고정하세요.
17:58
없으면 어시스턴트는 그저 어깨를 으쓱하며 지어내기만 할 것입니다.
18:01
5단계
18:01
파일럿
18:02
먼저 소규모 그룹에 배포하세요.
18:03
기능을 제공하고
18:04
피드백을 수집하며
18:05
원격 분석을 확인하세요.
18:07
AI 모듈은 사용 기록을 로그로 남김으로 깔끔한 출력물이 나오는지
18:09
쓸모없는 정보가 생성되는지 확인할 수 있습니다.
18:11
확장하기 전에 롤백 계획이 필요합니다.
18:14
다행히
18:14
코파일럿 및 에이전트 기능
18:16
페이지가 비상정지 버튼 역할을 합니다.
18:18
문제가 발생하면
18:19
관리자가 즉시 개별 기능을 비활성화할 수 있습니다.
18:22
에이저 설정이 여러 지역에 걸쳐 있는 경우
18:24
해당 페이지에서
18:25
지역 간 데이터 이동 허용 토글도 확인할 수 있습니다.
18:28
해당 항목이 보이면
18:29
주의 깊게 살펴보세요.
18:30
규정 준수 담당자는 반드시 확인할 것입니다.
18:32
현장 사례를 통해 이 과정을 확실히 이해해봅시다.
18:34
한 팀이 판매 주문 제한 코파일럿을 구축했습니다.
18:37
코파일럿 기능에 대한 열거형
18:38
인융
18:39
확장을 시작으로 설치된 코드 유닛과 연결했습니다.
18:42
코파일럿 및 에이전트 기능
18:43
페이지에서 이를 미리 보기로 표시하여
18:45
테스트 사용자에게만 보이도록 했습니다.
18:47
그런 다음 에이저 오픈 아이를 호출했습니다.
18:49
모델이 응답할 수 있도록
18:50
엔드포인트
18:51
배포
18:52
키를 사용하여 권한을 설정했습니다.
18:54
다음으로 메타 프롬프트를
18:55
격리된 저장소에 작성하고
18:56
AOAI 채팅 메시지로 설정했습니다.
18:59
기본 시스템 메시지를 설정합니다.
19:01
당신은 견적 지원 도우미입니다.
19:02
번드를 제한하고
19:03
항목 라인 형식으로 구성하세요.
19:05
군더더기 없는 답변만 제공하세요.
19:06
파일럿 단계에서 출력 결과가
19:08
예측 가능해질 때까지
19:09
소규모 그룹이 테스트했습니다.
19:10
그제야 가용성을 GA
19:11
정식 출시로 표시하여
19:12
모든 영업 사용자가 사용할 수 있게 했습니다.
19:14
그 결과
19:15
불필요한 내용 대신
19:16
번드를 추천하는 코파일럿이 완성되었습니다.
19:18
여기서 거버넌스 계층은
19:19
선택사항이 아닙니다.
19:21
문제가 생기면
19:21
사용자의 문의가 들어오기 전에
19:23
관리자가 토그를 꺼버릴 수 있습니다.
19:24
이러한 차단 스위치 사고 방식이
19:26
맞춤형 코파일럿을
19:27
방해 요소가 아닌
19:27
생산적인 도구로 유지해줍니다.
19:29
다른 확장 프로그램과 마찬가지로
19:30
단계적 배포
19:31
제한된 범위
19:32
측정 가능한 테스트를 적용하세요.
19:34
AI라고 예외는 없습니다.
19:36
테스트할 때는
19:36
각 부분을 개별적으로 실행하세요.
19:38
전체 체인을 한꺼번에 연결하고
19:39
유행을 바라지 마세요.
19:41
기능 등록을 검증하고
19:42
가용성이 제대로 표시되는지 확인하고
19:44
권한 설정을 확인한 다음
19:46
메타 프롬프트가 응답에
19:47
잘 반영되는지 확인하세요.
19:51
그것이 바로 설계도를
19:53
현실로 잇는 가교입니다.
19:55
간단히 말해
19:55
기능은 기술을 정의하고
19:56
가용성은 대상을 한정하며
19:58
권한은 문을 열고
19:59
메타 프롬프트는 규칙을 정하며
20:01
파일럿은 시스템이
20:02
곤란한 상황을 만들지 않음을 증명합니다.
20:04
이 단계를 제대로 수행하면
20:05
공식 기능 출시보다 앞서갈 수 있습니다.
20:07
이는 더 큰 의미로 이어집니다.
20:09
즉 이러한 단계를 거쳐야
20:10
마이크로소프트가 무대에서 보여주는
20:12
사전 패키지 데모만 따라가는 것이 아니라
20:14
비즈니스에 맞춰
20:15
코파일럿을 구성할 수 있습니다.
20:16
이제 요약하겠습니다.
20:17
기억해야 할 세 가지가 있습니다.
20:20
첫째, 기능을 등록하여
20:21
시스템 AI를 통해 코파일럿을 확장하세요.
20:24
둘째, 에이저 연결을 보호하세요.
20:26
테스트 중에는 격리된 스토리지를 사용하되
20:28
운영 환경에서는 해당 키를 키볼트로 옮기세요.
20:30
셋째, 코파일럿 및 에이전트 기능 페이지에서
20:33
기능을 시험하고 관리하여
20:34
관리자가 항상 킬 스위치를 제어할 수 있도록 하세요.
20:36
거버넌스 담당자를 위한 짧은 알림으로
20:38
코파일럿은 사용자 권한을 상속받음으로
20:40
사용자가 접근할 수 없는 데이터는 절대 잊지 않습니다.
20:43
또한 마이크로소프트는 사용자가 명시적으로 허용하지 않는
20:45
한테넌트 데이터를 사용하여 모델을 학습시키지 않습니다.
20:48
다음 단계로 이번 주에 샌드박스에서 기능을 하나 테스트하여
20:51
체크리스트 순서대로 올바르게 작동하는지 확인하세요.
20:54
그런 다음 M365 쇼 뉴스레터를 구독하여
20:56
생존 가이드 업데이트를 받고
20:57
M365 쇼 링크딘 페이지를 팔로우하여
20:59
이 기능을 이미 다루어본 MVP들의 실시간 스트리밍을 시청하세요.