WEBVTT

00:00:00.000 --> 00:00:04.300
똑똑한 에이전트가 어리석은 짓을 하지 않도록 막는 유일한 검증 절차가 있습니다.

00:00:04.940 --> 00:00:06.800
바로 실행 전 계약 검사입니다.

00:00:07.300 --> 00:00:11.040
어떤 도구든 실행되기 전에 검증기는 3가지를 순서대로 확인합니다.

00:00:11.220 --> 00:00:14.540
위도가 실제 기능과 일치하는지, 호출자에게 현재 권한이 있는지,

00:00:14.860 --> 00:00:18.140
그리고 요청된 결과가 선언된 데이터 범위 내에서 실행 가능한지 확인합니다.

00:00:18.340 --> 00:00:20.840
어느 한 부분이라도 실패하면 아무것도 실행되지 않습니다.

00:00:21.060 --> 00:00:24.220
단순히 조심하거나 시도하는 것이 아니라 이유와 대안을 제시하며 거부합니다.

00:00:24.420 --> 00:00:25.860
먼저 기능 일치부터 확인합니다.

00:00:26.060 --> 00:00:28.460
계획이 쉐어포인트 목록 항목을 업데이트하는 것이라고 가정해보겠습니다.

00:00:28.460 --> 00:00:32.080
검증기는 어떤 도구, 어떤 방법, 어떤 스키마 버전을 사용할지 묻습니다.

00:00:32.240 --> 00:00:34.280
인수는 레지스트리와 비교하여 검사합니다.

00:00:34.460 --> 00:00:37.680
필수 필드가 있는지, 유형이 올바른지, 값 범위가 적절한지,

00:00:37.960 --> 00:00:41.200
그리고 누군가 무시할 것을 기대하며 추가 필드가 숨겨져 있지 않은지 확인합니다.

00:00:41.360 --> 00:00:43.060
도구 별칭 사용은 금지되어 있습니다.

00:00:43.400 --> 00:00:45.280
정식 이름을 사용하거나 거부됩니다.

00:00:45.500 --> 00:00:49.080
이를 통해 잘못된 도구 나추측성 매개변수가 오작동하기 전에 차단합니다.

00:00:49.300 --> 00:00:51.360
다음으로 정책 준수 여부를 확인합니다.

00:00:51.580 --> 00:00:54.900
정책 엔진은 제한된 호출을 활성 정책과 비교하여 평가합니다.

00:00:54.900 --> 00:00:57.340
도구 및 도메인에 대한 허용 목록을 확인합니다.

00:00:57.340 --> 00:01:01.340
RBAC 또는 ABC 검사는 아이디 클레임 및 범위 입력과 연계됩니다.

00:01:01.500 --> 00:01:04.420
환경계층 규칙, 데이터 분류 경계도 고려됩니다.

00:01:04.640 --> 00:01:07.040
에이전트의 범위가 특정 사이트의 파일 읽기로 제한된 경우,

00:01:07.460 --> 00:01:10.240
업데이트 호출이나 다른 사이트로의 접근은 절대 허용되지 않습니다.

00:01:10.400 --> 00:01:14.400
페이로드가 사람의 검토 없이 제한된 분류 영역에 접근하는 경우에도 마찬가지입니다.

00:01:14.600 --> 00:01:17.840
토큰은 최신 상태로 검증되고, 범위는 정확하게 검증됩니다.

00:01:18.360 --> 00:01:22.660
권한 상승 시도는 단 한 번이라도 명백한 침해 시도로 간주됩니다.

00:01:22.660 --> 00:01:24.960
그 다음 사후 실행 가능성을 검토합니다.

00:01:24.960 --> 00:01:27.460
단순히 원하는 결과만으로는 충분하지 않습니다.

00:01:27.620 --> 00:01:29.840
발성 가능하고 검증 가능한 결과여야 합니다.

00:01:30.040 --> 00:01:32.080
검증자는 대상이 항목 유효성 키를 지원하는지,

00:01:32.460 --> 00:01:35.660
시스템에서 사후 확인이 가능한 연구식 별자 또는 이 태그를 생성하는지,

00:01:36.020 --> 00:01:38.960
하위 시스템에서 오류가 발생할 경우 보상 조치가 있는지 등을 확인합니다.

00:01:39.140 --> 00:01:42.840
검증 가능한 사후 조건을 제시할 수 없다면 계획은 거부되거나 재작성됩니다.

00:01:43.040 --> 00:01:43.780
나중에 기록할게요.

00:01:43.900 --> 00:01:45.540
라는 식의 접근 방식은 용납되지 않습니다.

00:01:45.760 --> 00:01:47.700
나중에 기록하는 순간 사고가 발생하기 때문입니다.

00:01:47.900 --> 00:01:50.140
이러한 요소들을 종합하면 영향일치, 정책 준수,

00:01:50.140 --> 00:01:52.060
사후 실행 가능성이라는 세 가지 핵심 요소가 됩니다.

00:01:52.060 --> 00:01:54.640
세 가지 조건을 모두 통과하면 실행자가 진행합니다.

00:01:54.800 --> 00:01:57.400
하나라도 실패하면 이후 설명 경로가 활성화됩니다.

00:01:57.600 --> 00:02:00.460
이 경로는 정중하고 철저하며 모호하지 않습니다.

00:02:00.660 --> 00:02:03.480
시도한 내용, 위반한 정확한 정책 또는 스키마,

00:02:03.780 --> 00:02:05.220
그리고 안전한 대안을 제시합니다.

00:02:05.460 --> 00:02:06.900
사용자 의도를 수정할 수 있다면

00:02:06.900 --> 00:02:10.880
범위를 좁히고 읽기 전용 요약으로 전환하거나 허용된 사이트로 연결합니다.

00:02:11.120 --> 00:02:14.440
검증자는 규정을 준수하는 계획을 제안하고 수인을 요청합니다.

00:02:14.640 --> 00:02:16.440
수정할 수 없다면 전체 컨텍스트와 함께

00:02:16.440 --> 00:02:19.180
담당자 검토 단계로 넘어가 권하 작업을 즉시 중단합니다.

00:02:19.380 --> 00:02:21.680
알 수 없는 지연이나 조용한 성공은 없습니다.

00:02:21.680 --> 00:02:24.940
비록 몰라 더라도 경험했을 법한 간단한 예시입니다.

00:02:25.100 --> 00:02:27.500
담당자에게 지난 분기에 모든 인사 문서를 요약하여

00:02:27.500 --> 00:02:29.520
법무팀에 이메일로 보내라는 요청이 들어왔습니다.

00:02:29.700 --> 00:02:32.700
검색은 인사 및 법무 사이트 전반에 걸친 그래프 커리를 제안합니다.

00:02:32.900 --> 00:02:34.680
검증자는 경계 침범을 감지합니다.

00:02:34.880 --> 00:02:37.680
인사팀은 접근이 제한되어 있고 법무팀은 내부 사용자입니다.

00:02:37.880 --> 00:02:40.540
트리오 게이트는 규차 읽기와 외부 이메일을 차단합니다.

00:02:40.760 --> 00:02:42.120
거부 경로가 반환됩니다.

00:02:42.360 --> 00:02:44.080
제한된 콘텐츠가 감지되었습니다.

00:02:44.440 --> 00:02:46.580
제한된 대안은 내부 정책 세균을 요약하고

00:02:46.580 --> 00:02:50.000
승인된 검토자에게 인사 요약 요청 링크를 제공하는 것입니다.

00:02:50.240 --> 00:02:52.480
사용자는 규정을 준수하는 계획을 승인합니다.

00:02:52.720 --> 00:02:55.000
실행기는 이를 실행하고 내부 콘텐츠를 참조하며

00:02:55.000 --> 00:02:56.780
인사 자료에 대한 권한 요청을 첨부합니다.

00:02:57.020 --> 00:02:59.080
정보 유출이나 문제 발생 없이 여전히 유용합니다.

00:02:59.280 --> 00:03:01.040
구현은 위도적으로 단순하게 설계되었습니다.

00:03:01.320 --> 00:03:04.800
정책 DSL은 누가 무엇을 어디서 어떤 부작용과 함께 수행할 수 있는지 정의합니다.

00:03:05.020 --> 00:03:07.700
스키마 레지스트리는 도구 계약, 이름, 버전,

00:03:08.080 --> 00:03:09.760
인수 형태 및 사후 조건을 저장합니다.

00:03:09.760 --> 00:03:14.020
허용 목록 확인자는 도메인, 사이트 및 범위를 환경계층에 맵핑합니다.

00:03:14.180 --> 00:03:16.040
검증자는 이러한 요소들을 조합하고

00:03:16.040 --> 00:03:19.100
모든 결정에 감사 기록, 입력, 정책 평가,

00:03:19.460 --> 00:03:22.580
결과를 기록한 후 실행기에게 승인 또는 수정 계획을 전달합니다.

00:03:22.800 --> 00:03:25.200
실행기는 절대 독단적으로 행동하지 않습니다.

00:03:25.420 --> 00:03:27.080
결정을 시행하거나 중단합니다.

00:03:27.320 --> 00:03:29.100
이 개념 모델은 아키텍처 다이어그램에

00:03:29.100 --> 00:03:31.100
명확하게 새겨 넣을 수 있을 만큼 간단합니다.

00:03:31.320 --> 00:03:33.520
실행기는 시행하고 그래프는 제약을 설정하고

00:03:33.520 --> 00:03:34.680
검증자는 결정합니다.

00:03:34.880 --> 00:03:36.160
이 순서대로 진행됩니다.

00:03:36.160 --> 00:03:39.800
이 모델은 울타리 안에서만 작동하며 울타리를 넘으려는 순간

00:03:39.800 --> 00:03:43.600
검증자가 모델을 되돌려놓고 이유를 설명하며 문을 가리킵니다.

00:03:43.760 --> 00:03:45.720
질서가 유지되고 안전이 확보되며

00:03:45.720 --> 00:03:48.040
진행이 막히지 않고 정책이 준수됩니다.

00:03:48.240 --> 00:03:50.420
똑똑한 에이전트가 어리석은 행동을 하지 않도록

00:03:50.420 --> 00:03:52.220
막아주는 단 한 가지가 필요하셨죠.

00:03:52.360 --> 00:03:53.180
바로 이것입니다.

00:03:53.460 --> 00:03:55.840
실제 변경이 발생하기 전에 역량, 권한,

00:03:56.180 --> 00:03:58.940
검증 가능한 결과를 증명하는 사전 실행 계약 검사입니다.

00:03:59.160 --> 00:04:01.120
할 수 있을 것 같다는 생각을 허용되고

00:04:01.120 --> 00:04:02.080
방법을 알고 있으며

00:04:02.080 --> 00:04:04.040
실행했음을 증명할 수 있다로 바꿔줍니다.

00:04:04.040 --> 00:04:06.000
어둠은 우리에게 닥치지 않습니다.

00:04:06.200 --> 00:04:08.620
이제 아키텍처가 완성되었으니 활용해보세요.

00:04:08.840 --> 00:04:10.960
핵심 요점과 CT 분석을 함께 살펴보겠습니다.

00:04:11.360 --> 00:04:13.060
핵심 요점은 프롬프트는 의견이고

00:04:13.060 --> 00:04:15.300
실행기와 검증된 그래프는 작업이며

00:04:15.300 --> 00:04:16.840
사전 실행 계약 검사느니

00:04:16.840 --> 00:04:19.380
둘 모두를 정직하게 유지하는 안전장치라는 것입니다.

00:04:19.560 --> 00:04:21.440
이 자료가 시간을 절약해 주었다면

00:04:21.440 --> 00:04:23.020
구독으로 보답해 주세요.

00:04:23.260 --> 00:04:26.320
다음으로는 랭그라프와 마이크로소프트 에이전트 프레임워크 위

00:04:26.320 --> 00:04:29.260
성능 및 관찰 가능성 분석, 실제 추적, 비용,

00:04:29.520 --> 00:04:31.040
P95 분석 영상을 시청하세요.

00:04:31.040 --> 00:04:33.520
업그레이드 경로를 확정하고 알림을 활성화하고

00:04:33.520 --> 00:04:35.260
다음 에피소드를 예정대로 받으세요.

00:04:35.400 --> 00:04:36.240
계속 진행하세요.

00:04:36.460 --> 00:04:38.980
많은 사람들이 더 나은 프롬프트가 불안정한 에이전트를 고친다고 생각합니다.

00:04:39.140 --> 00:04:40.080
그럴듯한 생각이죠.

00:04:40.280 --> 00:04:42.900
프롬프트는 생각을 안내할 뿐 작업을 실행하지는 않습니다.

00:04:43.120 --> 00:04:44.680
진실은 에이전트의 안정성이 실행기와

00:04:44.680 --> 00:04:46.560
그래프 유효성 검사에서 비롯된다는 것입니다.

00:04:46.760 --> 00:04:48.020
이것이 바로 현실에 직면했을 때

00:04:48.020 --> 00:04:49.960
에이전트가 실패하지 않도록 지탱하는 핵심입니다.

00:04:50.160 --> 00:04:51.620
우리는 이것을 마이크로소프트 시나리오,

00:04:51.900 --> 00:04:53.520
마이크로소프트 365 그래프 검색,

00:04:53.860 --> 00:04:54.800
에이저 오픈 AI 추론,

00:04:54.800 --> 00:04:57.600
그리고 폭주하지 않는 코파일럿 스튜디오 에이전트와 연결할 것입니다.

00:04:57.760 --> 00:04:58.820
핵심은 간단합니다.

00:04:59.060 --> 00:05:02.520
정확성, 지연시간, 비용, 그리고 감사 가능성입니다.

00:05:02.740 --> 00:05:04.860
막연한 느낌이 아니라 측정 가능한 것입니다.

00:05:05.080 --> 00:05:06.360
머릿속으로 실행할 수 있는 모델,

00:05:06.600 --> 00:05:07.960
잊지 않을 설명이 담긴 다이어그램,

00:05:08.320 --> 00:05:10.580
그리고 똑똑한 에이전트가 어리석은 행동을 하지 않도록 하는

00:05:10.580 --> 00:05:12.240
한 가지 유효성 검사 단계를 제공하겠습니다.

00:05:12.580 --> 00:05:14.680
처음부터 사용했어야 할 아키텍처입니다.

00:05:14.940 --> 00:05:16.720
프롬프트가 작업 실행에서 실패하는 이유,

00:05:17.060 --> 00:05:18.100
실행기는 성공하는 이유.

00:05:18.300 --> 00:05:19.660
자, 핵심은 이렇습니다.

00:05:19.920 --> 00:05:21.660
LLM은 인지를 처리하고,

00:05:22.060 --> 00:05:23.480
실행기는 작업을 처리합니다.

00:05:23.480 --> 00:05:25.620
이 둘을 섞으면 혼란이 생깁니다.

00:05:25.800 --> 00:05:27.380
모델은 계획을 제한할 수는 있지만,

00:05:27.820 --> 00:05:30.280
이메일이 전송되었는지, 파일이 저장되었는지,

00:05:30.620 --> 00:05:32.200
권한이 있는지를 보장할 수는 없습니다.

00:05:32.500 --> 00:05:33.620
모델은 확률로 말하지만,

00:05:34.020 --> 00:05:35.560
실제 작업에는 보장이 필요합니다.

00:05:35.740 --> 00:05:37.320
바로 이때 실행기가 등장합니다.

00:05:37.600 --> 00:05:39.120
실행기는 마치 방안의 어른처럼,

00:05:39.540 --> 00:05:41.440
상태 제약 조건과 항목의 유효성을 가진

00:05:41.440 --> 00:05:42.900
정책기반 함수 실행기입니다.

00:05:43.120 --> 00:05:45.420
실행기는 작업이 성공했다고 확신하지 않고,

00:05:45.840 --> 00:05:46.420
검증합니다.

00:05:46.620 --> 00:05:48.780
도구가 존재한다고 가정하지도 않습니다.

00:05:49.060 --> 00:05:50.180
시도하기 전에 기능,

00:05:50.180 --> 00:05:52.640
맥의 변수, 권한을 검증합니다.

00:05:52.640 --> 00:05:54.960
그리고 실패하면 큰 소리로 실패를 알리고,

00:05:55.360 --> 00:05:56.140
오류를 분류하고,

00:05:56.500 --> 00:05:57.880
정해진 복구 경로를 따릅니다.

00:05:58.060 --> 00:05:59.820
대부분의 프롬프트 전용 에이전트는

00:05:59.820 --> 00:06:01.360
세 가지 실패 유형에 속합니다.

00:06:01.580 --> 00:06:03.600
첫째, 잘못된 도구 요청입니다.

00:06:03.840 --> 00:06:05.720
모델이 등록되지 않은 함수를 요청하거나,

00:06:05.900 --> 00:06:07.340
존재하지 않는 필드를 사용하여

00:06:07.340 --> 00:06:08.640
함수를 호출하는 경우입니다.

00:06:08.800 --> 00:06:10.540
둘째, 사전 조건 누락입니다.

00:06:10.800 --> 00:06:13.080
사이트, 목록 또는 항목 버전에 액세스할 수 있는지

00:06:13.080 --> 00:06:13.700
확인하지 않고,

00:06:13.840 --> 00:06:15.780
셰어포인트 파일을 편집하려고 시도하는 경우입니다.

00:06:15.940 --> 00:06:17.200
셋째, 부분 오류입니다.

00:06:17.200 --> 00:06:18.060
1단계가 실패했지만,

00:06:18.060 --> 00:06:19.360
텍스트가 확신에 차 보인다는 이유로

00:06:19.360 --> 00:06:21.180
에이전트가 계속 진행하여 성공을 선언하는 경우입니다.

00:06:21.300 --> 00:06:22.440
이러한 오류를 본 적이 있을 것입니다.

00:06:22.620 --> 00:06:23.580
방금 불안정하다고 하셨는데,

00:06:23.880 --> 00:06:25.100
실행기는 지루해 보이는 루프를 실행합니다.

00:06:25.240 --> 00:06:26.920
바로 그 때문에 제대로 작동하는 겁니다.

00:06:27.160 --> 00:06:27.660
사전 조건,

00:06:27.880 --> 00:06:29.980
입력, 권한 및 불변 조건을 확인합니다.

00:06:30.200 --> 00:06:31.720
실행, 항목 효능키를 사용하여

00:06:31.720 --> 00:06:32.640
도구를 호출하여

00:06:32.640 --> 00:06:35.440
제시도 시 중복 청구나 중복 게시가 발생하지 않도록 합니다.

00:06:35.680 --> 00:06:36.220
사후 조건,

00:06:36.480 --> 00:06:38.840
원본 데이터와 비교하여 효과를 확인합니다.

00:06:39.060 --> 00:06:39.480
오류 분류,

00:06:39.700 --> 00:06:40.340
유효성 검사,

00:06:40.340 --> 00:06:41.180
일시적 오류,

00:06:41.460 --> 00:06:41.980
속도 제한,

00:06:42.240 --> 00:06:44.960
초기 상태 오류 또는 정책 위반 중 어떤 오류인지 파악합니다.

00:06:45.140 --> 00:06:45.400
복구,

00:06:45.540 --> 00:06:47.100
일시적 오류의 경우 배고프 후 제시도,

00:06:47.400 --> 00:06:49.060
인증 오류의 경우 재인증 또는 제동해,

00:06:49.320 --> 00:06:50.600
알려진 대체 방법의 경우 풀백,

00:06:50.840 --> 00:06:53.140
정책 위반의 경우 사유와 함께 강제 종료를 수행합니다.

00:06:53.300 --> 00:06:54.800
멱등성은 필수 조건입니다.

00:06:55.020 --> 00:06:55.960
제시도 가능한 작업에는

00:06:55.960 --> 00:06:58.060
두 번째 시도를 아무 작업도 수행하지 않거나

00:06:58.060 --> 00:06:59.920
일관된 재정의로 만드는 키가 필요합니다.

00:07:00.140 --> 00:07:02.000
타임아웃은 좀비 호출을 방지합니다.

00:07:02.220 --> 00:07:03.960
배고프는 속도 제한을 준수합니다.

00:07:03.960 --> 00:07:07.260
이는 본질적으로 확률적인 텍스트 생성을 제어하는

00:07:07.260 --> 00:07:08.760
결정론적 동작입니다.

00:07:09.000 --> 00:07:10.260
실행기는 변속기이고,

00:07:10.640 --> 00:07:11.600
LLM은 엔진입니다.

00:07:11.840 --> 00:07:15.080
엔진을 풀악셀로 바꿔 바퀴가 알아서 작동하기를 바라는 건 잘못된 방식입니다.

00:07:15.260 --> 00:07:18.020
계약 우선 출력 방식은 장황한 설명에 대한 해결책입니다.

00:07:18.240 --> 00:07:20.380
추론 모델은 장황하게 설명할 필요가 없습니다.

00:07:20.660 --> 00:07:21.060
도구 이름,

00:07:21.340 --> 00:07:21.640
인수,

00:07:21.900 --> 00:07:24.720
예상 사후 조건 등 스키마와 일치하는 JSON을 출력합니다.

00:07:24.960 --> 00:07:27.540
유효성 검사기는 실행 전에 스키마 준수 여부를 확인합니다.

00:07:27.740 --> 00:07:29.940
형식이 올바르지 않으면 실행기는 이유를 명시하여 실행을 거부하거나

00:07:29.940 --> 00:07:32.080
수정된 계획을 요청하거나 문제를 상의 부서로 보고합니다.

00:07:32.080 --> 00:07:35.340
이렇게 하면 장황한 설명이 실제 운영 환경에서 문제를 일으키는 것을 방지할 수 있습니다.

00:07:35.520 --> 00:07:37.380
모델에 직접 검증을 요청할 수는 없나요?

00:07:37.480 --> 00:07:38.620
라고 생각할 수도 있습니다.

00:07:38.820 --> 00:07:39.780
물론 요청할 수 있습니다.

00:07:40.000 --> 00:07:41.360
모델은 항상 그렇다고 대답할 것입니다.

00:07:41.540 --> 00:07:43.040
일반 사용자는 이를 당연하게 여깁니다.

00:07:43.200 --> 00:07:44.840
하지만 전문가에게는 증명이 필요합니다.

00:07:45.020 --> 00:07:46.140
증명은 마이크로소프트 그래프,

00:07:46.360 --> 00:07:46.800
시어포인트,

00:07:47.020 --> 00:07:49.160
익스체인지와 같은 시스템을 통해 검증된 사후 조건에 존재합니다.

00:07:49.320 --> 00:07:51.460
모델의 메모리가 아닌 실제 진실의 원천입니다.

00:07:51.660 --> 00:07:53.180
하지만 여기서 흥미로운 점이 있습니다.

00:07:53.440 --> 00:07:54.660
반일 단계는 괜찮습니다.

00:07:54.940 --> 00:07:55.920
실제 워크플로는 분기,

00:07:55.920 --> 00:07:56.640
병렬처리,

00:07:56.840 --> 00:07:57.080
보상,

00:07:57.300 --> 00:07:58.680
그리고 사람의 검토 지점을 포함합니다.

00:07:59.060 --> 00:08:00.080
실행기만으로는 부족합니다.

00:08:00.320 --> 00:08:01.980
실행기가 읽을 수 있는 지도가 필요합니다.

00:08:02.180 --> 00:08:03.400
바로 워크플로 그래프입니다.

00:08:03.600 --> 00:08:06.020
그래프에서 노드는 명시적인 계약을 가진 작업 또는 하위 에이전트입니다.

00:08:06.200 --> 00:08:07.820
엣지는 제어 흐름과 데이터 흐름을 정의합니다.

00:08:08.020 --> 00:08:09.080
상태는 최우선 순위입니다.

00:08:09.280 --> 00:08:10.160
무엇이 연구적인가요?

00:08:10.360 --> 00:08:11.540
무엇이 체크포인트로 저장되나요?

00:08:11.740 --> 00:08:12.700
무엇이 일시적인가요?

00:08:12.900 --> 00:08:15.100
실행기는 가게지의 허용 목록과 스키마를 준수하며

00:08:15.100 --> 00:08:16.540
그래프를 결정론적으로 탐색합니다.

00:08:16.760 --> 00:08:18.740
노드에 오류가 발생하면 그래프는 보상,

00:08:18.740 --> 00:08:21.820
실행, 취소, 복구 또는 에스컬레이션을 지정합니다.

00:08:21.980 --> 00:08:23.520
알 수 없는 파이프라인은 없습니다.

00:08:23.940 --> 00:08:25.220
그리고 마법이 일어납니다.

00:08:25.500 --> 00:08:27.500
바로 이 순간 신뢰성이 반전됩니다.

00:08:27.720 --> 00:08:29.740
LLM 이 제안하고 실행기가 실행하며

00:08:29.740 --> 00:08:32.040
그래프 제약 조건 유효성 검사가 결정합니다.

00:08:32.260 --> 00:08:33.300
질서가 복원됩니다.

00:08:33.540 --> 00:08:34.700
인지와 운영을 분리하면

00:08:34.700 --> 00:08:38.120
에이전트는 즉흥적인 행동을 멈추고 제대로 작동하기 시작합니다.

00:08:38.340 --> 00:08:40.060
물론 에이전트는 여전히 똑똑하지만

00:08:40.060 --> 00:08:41.400
이제는 감독을 받습니다.

00:08:41.600 --> 00:08:43.080
청사진 준비가 완료되었습니다.

00:08:43.380 --> 00:08:44.800
테넌트를 무능하게 만들지 않고

00:08:44.800 --> 00:08:46.880
마이크로소프트 365에 연결해보겠습니다.

00:08:46.880 --> 00:08:48.840
그래프 워크플로우의 기본입니다.

00:08:49.020 --> 00:08:51.320
노드, 엣지, 그리고 누출되지 않는 상태.

00:08:51.520 --> 00:08:52.240
상상해보세요.

00:08:52.520 --> 00:08:54.500
신뢰할 수 있는 실행기는 있지만 지도가 없습니다.

00:08:54.800 --> 00:08:56.680
명령은 따르겠지만 어디로 향할까요?

00:08:56.840 --> 00:08:59.220
워크플로우 그래프, 즉 운영 매뉴얼이 필요합니다.

00:08:59.420 --> 00:09:02.180
노드는 명확한 계약을 가진 작업 또는 하위 에이전트입니다.

00:09:02.420 --> 00:09:04.440
엣지는 제어 흐름과 데이터 흐름을 정의합니다.

00:09:04.680 --> 00:09:05.960
그래프는 무엇이 언제 실행되는지

00:09:05.960 --> 00:09:08.580
그리고 어떤 데이터가 경계를 넘나들 수 있는지를 인코딩합니다.

00:09:08.780 --> 00:09:10.040
즉흥 연주나 재즈는 없습니다.

00:09:10.360 --> 00:09:11.760
악보처럼 정확하게 그려야 합니다.

00:09:12.000 --> 00:09:13.320
먼저 모양부터 정해야 합니다.

00:09:13.320 --> 00:09:16.780
대부분의 실제 운영 환경에서 그래프는 대그, 방향 비순환 그래프입니다.

00:09:16.940 --> 00:09:19.780
순환은 무한 루프와 상태 손상을 초래하기 때문입니다.

00:09:19.960 --> 00:09:21.180
물론 루프가 발생할 수는 있지만

00:09:21.180 --> 00:09:25.080
카운터와 가드, 최대 반복 횟수, 종료 조건, 타임 아웃 등을 사용하여

00:09:25.080 --> 00:09:26.200
위도적으로 표시해야 합니다.

00:09:26.340 --> 00:09:28.120
이렇게 해야 더 열심히 생각하라, 늦말이

00:09:28.120 --> 00:09:30.320
끝없이 생각하라, 늦말로 이어지지 않도록 할 수 있습니다.

00:09:30.520 --> 00:09:32.880
조건부 라우팅은 명시적으로 정의해야 합니다.

00:09:33.080 --> 00:09:35.900
검색 신뢰도가 인계값 이상 이면 합성 단계로 분기하고

00:09:35.900 --> 00:09:38.260
그렇지 않으면 재조회 단계로 분기합니다.

00:09:38.440 --> 00:09:40.260
병렬 처리는 최우선 사항입니다.

00:09:40.260 --> 00:09:42.560
요약과 인용 추출을 나란히 실행한 다음

00:09:42.560 --> 00:09:45.440
두 작업 모두 사후 조건을 충족했는지 확인하는

00:09:45.440 --> 00:09:46.880
장벽 노드에서 결합합니다.

00:09:47.120 --> 00:09:49.060
상태는 단순한 느낌이 아니라 기록입니다.

00:09:49.260 --> 00:09:50.920
세 가지 유형의 상태를 유지해야 합니다.

00:09:51.100 --> 00:09:52.960
첫째, 연구 상태는 충돌 후 복구할 수 있는

00:09:52.960 --> 00:09:55.920
내구성 있는 체크 포인트, 입력, 결정, 서명된 액션입니다.

00:09:56.060 --> 00:09:58.600
둘째, 임시 상태는 장기 메모리를 오염시키고 싶지 않은

00:09:58.600 --> 00:10:00.560
중간 모델 출력과 같은 수명이 짧은 버퍼입니다.

00:10:00.760 --> 00:10:03.080
셋째, 파생 상태는 인베딩이나 필터링된 결과와

00:10:03.080 --> 00:10:05.660
같이 결정론적으로 생성할 수 있는 재계산 가능한 아티팩트입니다.

00:10:05.820 --> 00:10:06.840
규칙은 간단합니다.

00:10:06.840 --> 00:10:09.220
감사해서 방어할 수 있는 것만 연구적으로 저장해야 합니다.

00:10:09.360 --> 00:10:11.160
나머지는 모두 의도적으로 폐기해야 합니다.

00:10:11.340 --> 00:10:12.620
롤백 전략은 중요합니다.

00:10:13.220 --> 00:10:15.340
노드가 외부 세계를 변경하거나 캘린더 이벤트를 생성하거나

00:10:15.340 --> 00:10:16.460
목록 항목을 업데이트할 때

00:10:16.460 --> 00:10:18.000
존재하는 경우 역방향 액션을 기록하고

00:10:18.000 --> 00:10:19.780
존재하지 않는 경우 보상 계획을 기록해야 합니다.

00:10:22.760 --> 00:10:24.200
하위 노드에 치명적인 오류가 발생하면

00:10:24.200 --> 00:10:26.380
그래프는 역순으로 이러한 보상 계획을 실행할 수 있습니다.

00:10:26.580 --> 00:10:27.800
이는 과도한 조치가 아니라

00:10:27.800 --> 00:10:31.220
CEO 위 일정이 겹치는 등의 오류를 방지하는 방법입니다.

00:10:31.460 --> 00:10:32.880
엣지는 계약을 전달합니다.

00:10:33.160 --> 00:10:34.720
엣지는 알 수 없는 파이프가 아니라

00:10:34.720 --> 00:10:36.200
노드 간의 api입니다.

00:10:36.420 --> 00:10:40.120
io 스키마, 유형, 필수 필드, 허용 값을 정의해야 합니다.

00:10:40.280 --> 00:10:41.340
허용 목록을 정의하여

00:10:41.340 --> 00:10:43.760
다음 노드가 호출할 수 있는 도구나 도메인을 지정합니다.

00:10:43.980 --> 00:10:45.060
기능 태그를 정의하여

00:10:45.060 --> 00:10:47.800
수신 노드가 수행할 작업과 거부할 작업을 지정합니다.

00:10:48.040 --> 00:10:50.300
실행기는 런타임에 이러한 사항을 적용합니다.

00:10:50.540 --> 00:10:51.660
노드는 요약 에즈를 통해

00:10:51.660 --> 00:10:53.760
시어포인트 토큰을 몰래 전송할 수 없습니다.

00:10:54.040 --> 00:10:55.440
이는 보여주기식 보안이 아니라

00:10:55.440 --> 00:10:57.920
에이전트의 측면 이동을 방지하는 방법입니다.

00:10:58.180 --> 00:11:00.040
오류 처리는 그래프 내에서 이루어지며

00:11:00.040 --> 00:11:01.800
분위기에 좌우되지 않습니다.

00:11:01.800 --> 00:11:07.980
모든 노드는 유효성 검사 오류, 임시 인프라, 속도 제한, 인증, 권한 부여,

00:11:08.400 --> 00:11:11.820
정책 위반 및 알 수 없음과 같은 오류 분류 체계를 선언합니다.

00:11:12.040 --> 00:11:14.620
그래프는 각 클래스에 대한 처리 경로를 제공합니다.

00:11:14.840 --> 00:11:16.500
임시 오류의 경우 지수 배고프를 사용한 제시도,

00:11:16.740 --> 00:11:19.540
인증 오류의 경우 토큰 갱신, 속도 제한 오류의 경우 대체도구 사용,

00:11:19.820 --> 00:11:22.000
정책 위반 오류의 경우 사유와 함께 거부 등의 방법을 사용합니다.

00:11:22.160 --> 00:11:24.580
알 수 없음 오류를 위한 데드레터큐도 존재합니다.

00:11:24.820 --> 00:11:27.220
실패한 페이로드는 전체 컨텍스트와 함께 격리되어

00:11:27.220 --> 00:11:30.300
사람이 프로덕션 환경에 혼란을 야기하지 않고 검사할 수 있습니다.

00:11:30.500 --> 00:11:34.280
사람이 직접 참여하는 체크 포인트는 임시방편적인 슬랙 메시지가 아닙니다.

00:11:34.500 --> 00:11:37.300
실행을 일시 중지하고 제한된 조치와 증거를 제시하며

00:11:37.300 --> 00:11:39.960
로그에 기록되고 서명된 승인 또는 수정을 요구합니다.

00:11:40.180 --> 00:11:41.620
승인되면 실행이 재개됩니다.

00:11:41.820 --> 00:11:44.580
거부될 경우 그래프는 안전한 대체 경로로 이동합니다.

00:11:44.780 --> 00:11:45.320
축하합니다.

00:11:45.580 --> 00:11:50.160
개발자들이 이메일보다 빠르기 때문에 실제로 따를 만한 변경 관리 시스템을 구현하셨습니다.

00:11:50.160 --> 00:11:51.940
메모리 격리는 필수적입니다.

00:11:52.180 --> 00:11:57.320
각 세션은 필요한 문서, 토큰, 중간 결과만 접근할 수 있는 범위가 제한된 컨텍스트를 갖습니다.

00:11:57.520 --> 00:12:03.180
세션 간 오염, 즉 한 대화의 프롬프트 주입이 다른 대화로 스며드는 것을 방지하여 데이터 유출을 막습니다.

00:12:03.480 --> 00:12:05.400
그래프는 경계를 염격하게 적용합니다.

00:12:05.620 --> 00:12:10.840
공유되는 가변 메모리는 없으며 콘텐츠 필터와 스키마 유효성 검사기가 있는 검증된 저장소에서 승인된 읽기만 허용합니다.

00:12:11.020 --> 00:12:15.720
인베딩과 요약을 캐시할 수 있지만 출처와 권한으로 태그를 지정하고 정책 변경 시 삭제해야 합니다.

00:12:15.720 --> 00:12:18.640
관찰 가능성은 기본적으로 내장되어 있으며 추가되는 것이 아닙니다.

00:12:18.780 --> 00:12:23.140
노드 수준 추적을 통해 입력, 출력, 지속시간, 제시도 횟수, 하위 시스템에 미치는 영향을 확인할 수 있습니다.

00:12:23.300 --> 00:12:27.740
그래프 실행 아이디로 추적 기록을 연결하면 재연, 진단 및 규정 준수 입증이 가능합니다.

00:12:27.940 --> 00:12:30.180
누가 무엇을 언제 외했는지 파악할 수 있습니다.

00:12:30.420 --> 00:12:35.580
이상 탐지 기능은 이상한 패턴, 도구 호출에 갑작스러운 급증, 비정상적인 도메인, 토큰 폭주 등을 감지합니다.

00:12:35.740 --> 00:12:38.880
이는 흥미로운 일이 사고로 발전하기 전에 미리 경고하는 시스템입니다.

00:12:39.100 --> 00:12:40.920
기본적으로 그래프는 헌법과 같습니다.

00:12:40.920 --> 00:12:44.640
집행자는 법 집행기관이고 LLM은 판사가 아닌 변호사입니다.

00:12:44.800 --> 00:12:49.860
이처럼 노드, 엣지, 상태를 인코딩하면 단순히 워크플로우가 성공하는 것뿐만 아니라 안전하게 실패하고

00:12:49.860 --> 00:12:53.560
자체적으로 설명하며 예측 가능하게 복구되는 워크플로우를 얻을 수 있습니다.

00:12:53.780 --> 00:12:58.760
이제 청사진을 바탕으로 테넌트를 무분별하게 사용하지 않고도 마이크로소프트 365에 연결할 수 있습니다.

00:12:58.980 --> 00:13:00.680
설계 단계부터 보안을 고려한 것입니다.

00:13:00.880 --> 00:13:03.320
그래프 유효성 검사는 카오스 엔지니어링보다 효과적입니다.

00:13:03.320 --> 00:13:07.800
프로덕션 환경에 혼란을 야기하고 살아남은 시스템이 보권력을 갖추기를 바라는 방식으로 신뢰성을 입증할 수는 없습니다.

00:13:08.060 --> 00:13:11.060
실행되기 전에 안전하지 않은 워크플로우를 거부함으로써 신뢰성을 입증해야 합니다.

00:13:11.240 --> 00:13:12.800
이것이 바로 그래프 유효성 검사입니다.

00:13:13.000 --> 00:13:16.280
정적 검사를 통해 불필요한 요소를 차단하고 넌타임 가드레일을 통해 위험을 방지합니다.

00:13:16.460 --> 00:13:18.240
정적 유효성 검사는 사전 검사와 같습니다.

00:13:18.580 --> 00:13:20.180
실행 전에 구조를 점검해야 합니다.

00:13:20.420 --> 00:13:24.080
무한 루프를 생성하는 사이클은 거부되거나 반복 방지 기능을 선언해야 합니다.

00:13:24.080 --> 00:13:27.560
도달할 수 없는 노드, 사용되지 않는 코드는 삭제하거나 정당화해야 합니다.

00:13:27.700 --> 00:13:29.460
누락된 계약이 있는지 확인해야 합니다.

00:13:29.660 --> 00:13:33.540
모든 노드는 입력 및 출력 스키마, 필수 기능, 부작용을 명시해야 합니다.

00:13:33.720 --> 00:13:35.420
권한 경계를 명확히 해야 합니다.

00:13:35.640 --> 00:13:41.320
외부 시스템을 변경하는 노드는 최소 권한 자격 증명과 명시적인 허용 목록을 사용하는 세그먼트에서 실행되어야 합니다.

00:13:41.500 --> 00:13:46.480
그리고 요약 노드가 갑자기 셰어포인트에 대한 쓰기 권한을 요청하면 검증기는 즉시 거부합니다.

00:13:46.720 --> 00:13:47.900
이제 런타임 단계입니다.

00:13:48.160 --> 00:13:50.040
여기서 많은 사람들이 실수를 저지릅니다.

00:13:50.300 --> 00:13:53.080
정책 엔진은 실행기 뒤에 있는 것이 아니라 실행기 옆에 있습니다.

00:13:53.080 --> 00:13:57.080
도구 및 도메인 허용 목록은 문서가 아니라 강제적인 결정사항입니다.

00:13:57.220 --> 00:14:04.700
호출 시 엔진은 활성 주체, 내부 아이디 토큰, 범위, 클레임을 기준으로 모든 사항을 확인하고 체인 아래로 정확하게 전파합니다.

00:14:04.920 --> 00:14:06.520
외부에서 부여되는 권한은 없습니다.

00:14:06.860 --> 00:14:10.720
토큰은 범위가 지정되고 허용될 때 갱신되며 우호적인 경계를 통해 몰래 전달되지 않습니다.

00:14:10.900 --> 00:14:13.940
에이전트는 모든 호출에서 액세스 권한을 획득하거나 그렇지 않으면 호출하지 않습니다.

00:14:14.100 --> 00:14:16.820
입력 및 출력 검증은 필수 사항이며 선택 사항이 아닙니다.

00:14:16.980 --> 00:14:19.940
프롬프트 주입은 영리한 방법이 아니라 예측 가능한 방법입니다.

00:14:19.940 --> 00:14:27.400
모든 인바운드 콘텐츠 소스는 콘텐츠 필터, html, 마크 다운 스크러버, 그리고 불필요한 내용을 제거하는 명령어 방화벽을 거칩니다.

00:14:27.600 --> 00:14:29.880
출력은 스키마 유효성 검사기를 통과합니다.

00:14:30.140 --> 00:14:34.640
노드가 json 형식을 약속했다면 실행기는 일반 텍스트를 거부하고 수정을 요청합니다.

00:14:34.840 --> 00:14:37.660
모델은 논쟁할 수 있지만 유효성 검사기는 협상하지 않습니다.

00:14:37.840 --> 00:14:40.740
유효성 검사기는 유형, 범위, 그리고 불변 조건을 강제합니다.

00:14:40.940 --> 00:14:43.460
샌드박싱과 세분화는 공격 반경을 제한합니다.

00:14:43.700 --> 00:14:48.060
외부 코드나 신뢰할 수 없는 커넥터를 호출하는 노드는 제한된 환경에서 실행됩니다.

00:14:48.060 --> 00:14:52.620
api 게이트웨이는 속도 제한 및 네트워크 정책을 통해 측면 이동을 방지하고

00:14:52.620 --> 00:14:56.360
검증된 도메인으로만 트래픽을 허용하는 송신 제어를 제공합니다.

00:14:56.560 --> 00:15:00.640
프로덕션 환경에서 검색 노드가 새로운 데이터 소스를 발견하도록 허용해서는 안 됩니다.

00:15:00.940 --> 00:15:05.140
데이터 발견은 테스트 환경 뒤에서 개발 환경에서 이루어지며 허용 목록에 대한 서명된 업데이트가 적용됩니다.

00:15:05.320 --> 00:15:08.080
관찰 가능성은 어딘가에 기록되는 것이 아니라 정밀하게 관리됩니다.

00:15:08.260 --> 00:15:12.840
노드 수준 추적은 입력, 출력, 지속시간, 제시도 횟수, 그리고 정책 엔진의 결정사항을 기록합니다.

00:15:13.040 --> 00:15:15.080
모든 것을 실행 아이디로 연관시킵니다.

00:15:15.080 --> 00:15:19.380
감사 로그는 변경 불가능하며 어떤 주체가 어떤 범위로 어떤 시점에 어떤 작업을 승인했는지

00:15:19.380 --> 00:15:22.160
그리고 정책이 왜 이를 허용했는지에 대한 정보가 기록됩니다.

00:15:22.320 --> 00:15:25.720
규제 기관에서 누가 무엇을 했는지 물으면 어깨를 으쓱하는 대신 철저히 조사해야 합니다.

00:15:25.860 --> 00:15:28.800
규정 준수 준비 완료란 증거가 완벽하고 명확하다는 것을 의미합니다.

00:15:28.960 --> 00:15:32.040
패치 및 타사 위험은 공급망 문제이므로 그에 맞게 처리해야 합니다.

00:15:32.240 --> 00:15:34.260
모든 빌드에서 중속성 검사를 실행합니다.

00:15:34.460 --> 00:15:38.380
커넥터와 플러그인은 감사를 거치고 버전을 고정하고 권한 확장 여부를 검토합니다.

00:15:38.380 --> 00:15:45.500
mcp 또는 오픈 api 사양을 가져오는 경우 선언된 메서드가 예상하는 최소 권한 정책과 일치하는지 검증합니다.

00:15:45.720 --> 00:15:49.960
와일드카드 엔드포인트 나 읽기 전용으로 의장한 숨겨진 쓰기 경로는 허용되지 않습니다.

00:15:50.140 --> 00:15:53.400
위생관리는 화려하지 않지만 여러분이 잠을 잘 수 있는 이유입니다.

00:15:53.600 --> 00:15:56.300
진실 그래프 검증은 하우스 엔지니어링보다 효과적입니다.

00:15:56.520 --> 00:16:00.380
왜냐하면 하우스 엔지니어링은 그 여파를 문서화하는 것이 아니라 특정 유형의 사고를 예방하기 때문입니다.

00:16:00.580 --> 00:16:04.900
여전히 장애모드를 테스트하지만 이는 가드레이를 설치하는 것을 잊었는지 확인하기 위한 것이 아니라 가드레이를 확인하기 위한 것입니다.

00:16:04.900 --> 00:16:07.100
이제 이 모든 것을 사고 모델에 적용해보겠습니다.

00:16:07.420 --> 00:16:09.720
정적검사는 설계도를 건전하게 유지합니다.

00:16:09.900 --> 00:16:13.500
불가능한 경로도 없고 버려진 작업도 없고 권한 유출도 없습니다.

00:16:13.800 --> 00:16:16.320
런타임 가드레일은 동작을 건전하게 유지합니다.

00:16:16.560 --> 00:16:19.980
모든 호출은 인증, 권한 부여, 검증 및 관찰됩니다.

00:16:20.220 --> 00:16:23.400
실행기는 검증기가 결정한 그래프 제약 조건을 적용합니다.

00:16:23.660 --> 00:16:26.820
모델은 경계 내에서 제한하고 벗어나 면 수정됩니다.

00:16:27.040 --> 00:16:28.340
이게 부담스럽지 않을까요?

00:16:28.520 --> 00:16:30.600
위반을 즐기는 사람이 아니라면 부담스럽지 않습니다.

00:16:30.800 --> 00:16:32.620
오버헤드는 기계적이고 자동화되어 있습니다.

00:16:32.620 --> 00:16:35.540
정적 유효성 검사는 빌드 시간과 배포 시간에 실행됩니다.

00:16:35.700 --> 00:16:38.260
런타임 정책은 사이드카처럼 빠르고 로컬에서 실행됩니다.

00:16:38.460 --> 00:16:40.380
스키마 검사는 밀리초 단위로 처리됩니다.

00:16:40.560 --> 00:16:45.620
제거되는 비용, 사고, 수동 검토, 수정은 추가되는 미세한 지연 시간에 비해 훨씬 적습니다.

00:16:45.840 --> 00:16:47.720
그리고 그 효과는 측정 가능합니다.

00:16:47.920 --> 00:16:54.080
무단 호출 감소, 토큰 폭발 감소, 사후 분석 횟수 감소 등이 그 예입니다.

00:16:54.400 --> 00:16:58.980
일반 사용자가 간과하는 또 다른 중요한 점은 유효성 검사가 구성 가능하다는 것입니다.

00:16:58.980 --> 00:17:04.620
타사 도구를 프록시 노드로 감싸서 도구 자체를 신뢰하지 않고도 계약과 정책을 적용할 수 있습니다.

00:17:04.860 --> 00:17:12.700
민감도, 공개, 내부, 제한됨별로 그래프를 분할하고 새 경계에 대한 유효성 검사를 통과한 후에만 계층 간 워크플로우를 승격시킬 수 있습니다.

00:17:12.940 --> 00:17:14.960
이것이 바로 안전한 확장을 위한 핵심입니다.

00:17:15.120 --> 00:17:18.420
설계 단계부터 보완을 고려하는 것은 단순한 슬로건이 아니라 워크플로우의 핵심 속성입니다.

00:17:18.620 --> 00:17:23.480
에이전트가 제대로 작동하기를 바라는 것이 아니라 오작동을 구조적으로 어렵게 만들고 운영상 가시화해야 합니다.

00:17:23.480 --> 00:17:28.340
이러한 기반이 마련되면 마이크로소프트 365 그래프와 에이저 오픈하이를 연결하는 것은 더 이상 복불복이 아닙니다.

00:17:28.500 --> 00:17:30.580
원하는 방식으로 제어된 권한을 행사할 수 있습니다.

00:17:30.820 --> 00:17:33.300
이제 문제 해결이 아닌 연결 작업에 대해 이야기할 수 있습니다.

00:17:33.540 --> 00:17:38.740
마이크로소프트 시나리오, 즉 M365 그래프, 에이저 오픈하이, 코파일러 스튜디오를 사용하는 경우를 살펴보겠습니다.

00:17:39.040 --> 00:17:40.560
각 구성 요소를 구성해보겠습니다.

00:17:40.960 --> 00:17:45.820
검색 에이전트는 최소 권한으로 마이크로소프트 그래프에서만 데이터를 가져오는 신중한 관리자입니다.

00:17:45.820 --> 00:17:52.240
추론 에이전트는 에이저 오픈하이 모델로서 계획, 위치 선정 등을 수행하며 주어진 범위를 벗어나 임의로 행동하지 않습니다.

00:17:52.420 --> 00:17:57.500
실행기는 정책에 따라 도구를 실행하고 멱등성과 사후 조건 검사를 수행합니다.

00:17:57.800 --> 00:18:02.180
유효성 검사기는 스키마, 정책 및 경계를 염격하게 적용하는 역할을 합니다.

00:18:02.440 --> 00:18:06.880
정책가드는 모든 것을 엔트라 아이디 범위 및 RBAC에 연결하는 런타임 사이드카입니다.

00:18:07.100 --> 00:18:10.360
이들은 마치 유능한 팀처럼 작동하며 위원회 회의처럼 단순하게 처리되지 않습니다.

00:18:10.540 --> 00:18:12.840
데이터 접근은 추측이 아닌 그래프 기반으로 시작됩니다.

00:18:12.840 --> 00:18:15.900
검색 에이전트는 세분화된 범위를 가진 앱 등록 정보를 보유합니다.

00:18:16.060 --> 00:18:19.500
파일은 특정 사이트에서만 읽을 수 있고, 메일은 제한된 사서함에서 기본 읽기 권한을 가지며,

00:18:19.820 --> 00:18:21.680
캘린더는 특정 리소스 캘린더에서만 읽을 수 있습니다.

00:18:21.860 --> 00:18:24.240
그래프를 이용한 모든 읽기, 쓰기 권한 부여는 없습니다.

00:18:24.560 --> 00:18:27.500
커리는 델타 및 선택적 필드를 사용하여 페이로드를 최소화합니다.

00:18:27.720 --> 00:18:29.420
페이징은 최우선 순위로 제공됩니다.

00:18:29.660 --> 00:18:33.600
실행기는 타임아웃을 준수하며 서비스 스로틀링을 고려하여 다음 링크를 결정적으로 따라갑니다.

00:18:33.600 --> 00:18:36.460
429 오류가 발생하면 배고프는 수학적으로 계산됩니다.

00:18:36.620 --> 00:18:38.760
짜증 없이 기하급수적인 인내심으로 처리합니다.

00:18:38.960 --> 00:18:41.280
안정성은 단순한 분위기가 아니라 체계적인 파이프라인입니다.

00:18:41.460 --> 00:18:44.240
그래프 검색 또는 목록 커리를 통해 후보 문서를 검색할 수 있습니다.

00:18:44.480 --> 00:18:48.740
항목 아이디와 버전 에태그를 사용하여 중복을 제거함으로써 오래된 데이터와 최신 데이터가 혼합되지 않도록 합니다.

00:18:48.900 --> 00:18:52.460
의미 경계, 섹션 헤더, 슬라이드 구분선을 기준으로 데이터를 청크로 분할한 다음,

00:18:52.760 --> 00:18:57.640
출처, 드라이브, 사이트, 경로, 항목 아이디, 최종 수정일, 할당된 해시값을 첨부합니다.

00:18:57.640 --> 00:19:02.960
추론 에이전트는 청크와 메타 데이터만 인식하며 해당 아이디에 맵핑된 인용 정보를 출력해야 합니다.

00:19:03.100 --> 00:19:05.340
인용 정보가 없으면 클레임도 발생하지 않습니다.

00:19:05.560 --> 00:19:08.500
실행기는 모든 외부 작업 전에 이를 사후 조건으로 적용합니다.

00:19:08.700 --> 00:19:10.940
코칭을 위해 코파일러 스튜디오를 활용합니다.

00:19:11.140 --> 00:19:15.240
명시적인 스키마와 허용 목록이 있는 프록시 뒤에서 선언적 도구, 그래프 커리 팩,

00:19:15.560 --> 00:19:19.240
시어포인트 쓰기 작업, 팀제 게시물, 아울룩 전송 등을 정의할 수 있습니다.

00:19:19.480 --> 00:19:21.380
에이전트 간 조정은 구조화 되어 있습니다.

00:19:21.720 --> 00:19:23.600
검색 에이전트는 기본 도구를 제공하고,

00:19:23.600 --> 00:19:26.700
추론 에이전트는 매개 변수와 함께 해당 도구를 요청합니다.

00:19:26.900 --> 00:19:30.680
실행기는 중재, 유효성 검사를 거쳐 기본 컨텍스트를 반환합니다.

00:19:30.900 --> 00:19:33.600
사람이 검토할 수 있는 검토 지점이 기본적으로 제공됩니다.

00:19:33.820 --> 00:19:36.020
제한된 작업 노드는 실행을 일시 중지하고,

00:19:36.240 --> 00:19:38.600
계획과 인용 정보를 표시하며 수인을 요구합니다.

00:19:38.820 --> 00:19:40.520
승인은 서명 후 로그에 기록됩니다.

00:19:40.740 --> 00:19:43.360
거부 시에는 안전한 대안 또는 에스컬레이션으로 연결됩니다.

00:19:43.560 --> 00:19:46.280
토큰과 지연 시간은 관리되며 단순히 무시할 필요가 없습니다.

00:19:46.600 --> 00:19:50.600
선택적 컨텍스트란 전체 테넌트가 아닌 관련 데이터 조각만 제공하는 것을 의미합니다.

00:19:50.600 --> 00:19:55.120
요약 정보는 콘텐츠 해시와 권한을 키로 사용하는 인베딩과 함께 미리 계산되어 캐시됩니다.

00:19:55.280 --> 00:19:58.820
문서가 변경되면 키가 변경되고, 캐시가 누락되면 다시 계산됩니다.

00:19:59.040 --> 00:20:04.780
스트리밍 응답은 실행기가 전체 스키마 유효계획이 도착한 후에만 부작용을 처리하는 동안 UI를 계속 활성화합니다.

00:20:04.980 --> 00:20:09.340
신뢰도와 적용 범위가 인계값에 도달하면 조기 종료 조건이 추론 루프를 중지합니다.

00:20:09.560 --> 00:20:12.340
모델이 시적이라고 해서 불필요한 고민을 할 필요가 없습니다.

00:20:12.640 --> 00:20:14.140
감사 기능이 내장되어 있습니다.

00:20:14.140 --> 00:20:23.440
모든 작업은 서비스 주체 또는 위임된 사용자가 서명하고 실행 아이디, 도구, 렉의 변수, 필요한 경우 수정됨, 범위 및 결과가 기록됩니다.

00:20:23.640 --> 00:20:26.380
변경 불가능한 로그는 관찰 가능성 스택에 저장됩니다.

00:20:26.580 --> 00:20:27.800
원하는 방식을 선택하세요.

00:20:28.000 --> 00:20:30.760
따라서 부작용을 다시 실행하지 않고도 실행을 다시 재생할 수 있습니다.

00:20:31.000 --> 00:20:33.960
누가 무엇을 언제 왜 했는지 파악하는 것은 마녀사냥이 아닌 커리가 됩니다.

00:20:34.200 --> 00:20:39.440
또한 인용 정보는 그대로 유지됨으로 답변이 모델 법칙이 아닌 실제 테넌트 콘텐츠에서 비롯되었는지 확인할 수 있습니다.

00:20:39.720 --> 00:20:41.600
실패는 일상화되어 지루하게 느껴집니다.

00:20:41.600 --> 00:20:47.700
429초가 지나면 실행기는 짙어, 짙어, 를 적용하여 제시도 하고, 그래도 문제가 해결되지 않으면 비용이 낮은 커리를 사용하거나 페이지 크기를 줄여서 처리합니다.

00:20:47.840 --> 00:20:51.780
캐시가 만료되면 유효성 검사기가 에테그 불일치를 감지하고 새로 고침을 강제합니다.

00:20:51.960 --> 00:20:58.400
권한이 거부되면 정책관리자는 사유와 함께 거부하거나 동의 요청 경로를 제한하거나 정보가 유출되지 않도록 수정된 요약으로 연결합니다.

00:20:58.580 --> 00:21:04.900
도구에 장애가 발생하면 그래프는 대체 방법을 제시하거나 전체 컨텍스트와 함께 실행을 대기열에 넣어 사람이 직접 수정할 수 있도록 합니다.

00:21:04.900 --> 00:21:07.860
확정적 대체 방법은 인시던트를 티켓으로 전환합니다.

00:21:08.020 --> 00:21:09.540
이제 간단한 예시를 살펴보겠습니다.

00:21:09.960 --> 00:21:13.300
사용자가 지난 둥기 로드맵 결정사항 요약본을 링크와 함께 작성해주세요.

00:21:13.440 --> 00:21:14.300
라고 요청합니다.

00:21:14.500 --> 00:21:20.360
추론 에이전트는 특정 시어포인트 사이트와 팀즈 채널에서 그래프 검색을 사용하고, 지난 둥기로 필터링한 다음 결과를 종합하세요.

00:21:20.500 --> 00:21:21.080
라고 제안합니다.

00:21:21.260 --> 00:21:24.780
유효성 검사기는 요청된 범위가 에이전트의 역할과 일치하는지 확인합니다.

00:21:24.940 --> 00:21:25.460
일치합니다.

00:21:25.780 --> 00:21:28.100
실행기는 페이직 및 필드 선택 기능을 사용하여 그래프 검색을 실행하고,

00:21:28.100 --> 00:21:32.040
항목 아이디로 중복을 제거하고, 데이터를 청크로 분할한 후, 출처 정보가 포함된 컨텍스트를 반환합니다.

00:21:32.160 --> 00:21:36.000
추론 과정에서 항목 아이디에 맵핑된 인라인 인용문이 포함된 요약이 생성됩니다.

00:21:36.200 --> 00:21:38.800
검증자는 스키마와 인용문을 확인하고 통과합니다.

00:21:39.100 --> 00:21:41.540
사람이 직접 검토하여 요약과 증거를 제시합니다.

00:21:41.780 --> 00:21:43.180
승인자는 확인을 클릭합니다.

00:21:43.420 --> 00:21:46.300
실행자는 결과를 팀즈에 게시하고, 이해 관계자에게 이메일을 보냅니다.

00:21:46.500 --> 00:21:49.320
각 작업은 항목 유효성 키를 사용하여 제시도시 중복 게시를 방지합니다.

00:21:49.500 --> 00:21:50.900
엄격한 규칙을 준수해야 합니다.

00:21:50.900 --> 00:21:55.020
어떤 에이전트도 자체 도구를 만들지 않으며, 어떤 노드도 허용 목록 외위 도메인을 넘나들지 않습니다.

00:21:55.180 --> 00:22:00.200
토큰은 엔트라 아이디를 통해 정확하게 범위가 지정되고 전파되며, 노드 간에 복사하여 붙여넣지 않습니다.

00:22:00.420 --> 00:22:02.220
모델은 성공을 결론 짓지 않습니다.

00:22:02.480 --> 00:22:05.100
실행자가 그래프 게시 조건을 통해 성공을 입증합니다.

00:22:05.300 --> 00:22:09.880
생성된 메시지 아이디, 업데이트된 항목의 태그, 캘린더 이벤트 아이디를 기록한 후 실행 완료를 표시합니다.

00:22:10.040 --> 00:22:14.860
물론, MCP 또는 오픈 API를 통해 플래너, 비바 또는 타사 서비스를 안전하게 확장할 수 있지만,

00:22:14.860 --> 00:22:18.540
엄격한 스키마와 네트워크 송신 제어를 갖춘 프록시 도구 뒤에서만 가능합니다.

00:22:18.680 --> 00:22:21.940
모든 커넥터를 동일한 검증 로직과 정책 가드로 감싸야 합니다.

00:22:22.120 --> 00:22:25.360
환경 간 승격에는 새로운 경계에 맞는 검증 통과가 필요합니다.

00:22:25.560 --> 00:22:29.320
개발에서 테스트, 그리고 프로덕션까지 범위 확장을 검토하고, 가정하지 않고 체계적으로 진행하는 것.

00:22:29.420 --> 00:22:31.720
이것이 마이크로소프트의 제대로 된 아키텍처입니다.

00:22:31.960 --> 00:22:37.780
그래프는 진실을 담고, 에이저 오픈아이는 사고를, 코파일럿 스튜디오는 오케스트레이션을, 실행기는 운영을,

00:22:38.120 --> 00:22:41.580
검증기와 정책은 안전성을, 그리고 관찰 가능성은 증명을 담당합니다.

00:22:41.580 --> 00:22:47.980
이제 감정이 아니라 수치를 보여줘야 합니다. 전후 비교 지표, 정확도, 지연 시간, 비용, 관리 오버헤드를 분석해야 합니다.

00:22:48.140 --> 00:22:53.020
훌륭한 아키텍처, 이제 증명해 보이세요. 감정이 아니라 수치가 중요합니다. 기준선부터 시작해야 합니다.

00:22:53.220 --> 00:22:55.260
프롬프트만 사용하는 에이전트는 과장된 반응을 보입니다.

00:22:55.420 --> 00:22:58.740
출처를 임의로 만들고 인용을 잊어버리기 때문에 정확도가 일정하지 않습니다.

00:22:58.940 --> 00:23:02.280
근거가 없으면 아무 의미 없는 자신감 넘치는 문장만 늘어놓게 됩니다.

00:23:02.540 --> 00:23:04.180
꼬리 지연 시간은 엄청납니다.

00:23:04.500 --> 00:23:08.940
불필요한 컨텍스트로 가득 찬 일련의 반복적인, 더 깊이 생각하기 호출이 이어집니다.

00:23:08.940 --> 00:23:15.160
매 단계마다 전체 녹취록과 원본 문서를 마치 비싼 택배처럼 모델에 전송하기 때문에 비용이 눈덩이처럼 불어납니다.

00:23:15.320 --> 00:23:17.580
관리 오버헤드는 어떻습니까? 높습니다.

00:23:17.820 --> 00:23:22.600
사고, 핫픽스, 원인을 알 수 없는 오류, 그리고 눈가리개를 하고 하는 고고와 발굴처럼 느껴지는 감사까지.

00:23:22.800 --> 00:23:25.680
이제 실행기와 검증된 그래프를 갖춘 개선 후 상태를 살펴봐야 합니다.

00:23:25.880 --> 00:23:28.700
주장에 대한 근거가 필요하기 때문에 정확도가 크게 향상됩니다.

00:23:28.900 --> 00:23:30.520
그래프 항목 아이디, 이 태그.

00:23:30.860 --> 00:23:35.360
서명된 해시와 연결된 검증된 인용 정보 덕분에 출처가 불분명한 답변은 검증을 통과하지 못합니다.

00:23:35.360 --> 00:23:42.220
그 효과는 즉각적입니다. 잘못된 답변이 줄어들고 재작업 횟수가 감소하며 평가 세트에서 작업 성공률이 눈에 띄게 향상됩니다.

00:23:42.400 --> 00:23:46.820
주장을 뒷받침할 수 없는 경우 에이전트는 이유를 명시하여 거부하거나 사람의 쓰인을 요청합니다.

00:23:46.980 --> 00:23:49.380
예측 가능하고 검토 가능하며 안전합니다.

00:23:49.600 --> 00:23:51.580
지연 시간은 세 가지 이유로 단축됩니다.

00:23:51.760 --> 00:23:57.280
첫째, 병렬 처리, 검색, 재순위 지점, 인용 정보 추출이 동시에 실행된 후 장벽 노드에서 동기화됩니다.

00:23:57.280 --> 00:24:02.980
둘째, 콘텐츠 해시와 권한 범위를 기준으로 캐싱, 인베딩, 요약을 수행하여 변경되지 않은 부분을 다시 계산하지 않습니다.

00:24:03.120 --> 00:24:04.900
셋째, 조기 종료가 가능합니다.

00:24:05.080 --> 00:24:08.360
적용 범위와 신뢰도가 인계값에 도달하면 그래프는 루프를 중지합니다.

00:24:08.560 --> 00:24:13.220
모델이 단락을 제시하고 사용자가 종료 시점을 고민하는 직렬 프롬프트 방식과 비교해보세요.

00:24:13.480 --> 00:24:16.060
토큰 사용이 의무화됨으로 비용이 절감됩니다.

00:24:16.320 --> 00:24:18.780
스키마 제약 출력은 장황한 설명을 방지합니다.

00:24:19.060 --> 00:24:23.400
선택적 컨텍스트는 전체 사이트가 아닌 관련 메타데이터 덩어리에만 정보를 제공합니다.

00:24:23.400 --> 00:24:26.880
프롬프트가 짧아지고 응답이 간결해지며 제시도 횟수가 줄어듭니다.

00:24:27.040 --> 00:24:31.120
실행기의 항목 효능 및 105 프로직은 중복 호출과 낭비되는 사이클을 방지합니다.

00:24:31.320 --> 00:24:35.100
결과적으로 성공적인 결과 당 토큰 수가 줄어들고 변동성이 크게 감소합니다.

00:24:35.300 --> 00:24:37.300
재무부서는 변동성 감소를 선호합니다.

00:24:37.540 --> 00:24:40.760
관찰 가능성이 설계에 기반함으로 관리 오버헤드가 줄어듭니다.

00:24:40.980 --> 00:24:44.360
노드 수준 추적 및 변경 불가능한 로그는 문제 진단 시간을 단축합니다.

00:24:44.620 --> 00:24:49.560
어떤 노드가 실패했는지, 정책 엔진이 왜 거부했는지, 실행기가 다음에 무엇을 시도했는지 확인할 수 있습니다.

00:24:49.560 --> 00:24:52.520
반복 가능한 배포는 머신 테스트 환경을 없애줍니다.

00:24:52.700 --> 00:24:58.840
모든 실행에 누가, 무엇을, 언제, 왜 했는지에 대한 정보가 이미 포함되어 있으므로 규정 준수는 더 이상 계절적인 위기가 아닙니다.

00:24:59.000 --> 00:25:01.800
실제로 실행 가능한 측정 시스템을 통해 이를 구체화해보겠습니다.

00:25:02.140 --> 00:25:07.940
대표적인 작업, 인용이 포함된 질의 응답, 링크가 포함된 요약, 승인이 포함된 실행 제한으로 구성된 평가 세트를 구축합니다.

00:25:08.100 --> 00:25:11.160
각 작업에 대해 정의된 정답 또는 승인 기준을 설정합니다.

00:25:11.400 --> 00:25:15.840
맵핑된 항목 아이디, 인용 범위 및 허용된 변동성을 통해 사실을 정확하게 파악합니다.

00:25:15.840 --> 00:25:21.660
SLO P50 및 P95의 엔드투 엔드 지연 시간, 성공적인 작업당 토큰 사용량, 정책 거부율을 측정합니다.

00:25:21.800 --> 00:25:25.280
모든 지표를 추적에 연결하여 회귀분석 시 추적 가능한 경로를 제공합니다.

00:25:25.480 --> 00:25:29.140
아키텍처를 준수할 경우 기대할 수 있는 결과이며, 임의로 변경해서는 안 됩니다.

00:25:29.420 --> 00:25:33.460
지원되지 않는 클레임은 스테이징 환경을 벗어나지 않으므로 답변 유효성이 향상됩니다.

00:25:33.640 --> 00:25:38.840
병렬로드와 조기 종료를 통해 긴 꼬리 부분이 잘려나가 무로 P95 지연 시간이 단축됩니다.

00:25:38.840 --> 00:25:43.760
방대한 내용을 배포하는 대신 관련성 있는 스니펫을 배포함으로 토큰 사용량이 줄어듭니다.

00:25:43.880 --> 00:25:48.600
대부분의 오류가 예측 가능한 대체 기능으로 처리되므로 관리자에게 표시되는 페이지 수가 줄어듭니다.

00:25:48.780 --> 00:25:51.040
그리고 모두가 잊어버리는 지루한 지표도 있습니다.

00:25:51.360 --> 00:25:54.940
첫 번째 시도 성공률이 높아져 사람의 개입 없이 더 많은 작업이 완료됩니다.

00:25:55.140 --> 00:25:58.820
비즈니스 영향 측면에서 문제 해결 속도가 빨라지면 사용자가 중복 티켓을 열지 않게 됩니다.

00:25:59.040 --> 00:26:02.120
예측 가능한 지출로 예상치 못한 토큰 초과 없이 예산을 측정할 수 있습니다.

00:26:02.120 --> 00:26:06.080
규정 준수에 대한 확신이 높아져 감사 주기가 줄어들어 로드맵의 차질이 생깁니다.

00:26:06.240 --> 00:26:08.420
눈에 띄지 않는 이점은 평판 향상입니다.

00:26:08.660 --> 00:26:13.920
상담원의 답변이 테넌트 콘텐츠를 참조하고 링크가 제대로 작동하면 사람들은 이를 신뢰하고 사용하며

00:26:13.920 --> 00:26:17.920
왜 이렇게 나왔죠? 라는 질문으로 시작하는 스크린샷을 더 이상 공유하지 않습니다.

00:26:18.120 --> 00:26:21.240
직접적이고 필수적인 조언을 제공하고 추적 데이터와 매트릭 간의 연관성을 측정하거나

00:26:21.240 --> 00:26:23.280
그렇지 않으면 단순히 주관적인 의견에 의존하는 것입니다.

00:26:23.440 --> 00:26:27.620
실행 결과를 열어 어떤 노드에서 토큰이 부풀려졌는지 지연 시간이 증가했는지 정확히 확인할 수 없다면

00:26:27.620 --> 00:26:30.500
관찰 가능성이 아니라 타임 스탬프만으로 짐작하는 것에 불과합니다.

00:26:30.660 --> 00:26:34.520
검증자가 훌륭한 계획과 실제 실행 사이에 위치할 때 모든 것이 바뀝니다.

00:26:34.720 --> 00:26:39.680
정확도가 안정화되고 지연 시간이 단축되고 비용이 안정화되고 관리자는 편안하게 잠을 잘 수 있습니다.

00:26:39.860 --> 00:26:46.040
이는 마법이 아니라 실행기, 그래프, 그리고 검증이 프롬프트에 잘못 할당했던 작업을 대신 수행해주는 결과입니다.