Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / AI 에이전트 아키텍처: 실행기, 워크플로 그래프, 검증으로 신뢰할 수 있는 에이전트 만들기 (AI 더빙)

Transcript

AI 에이전트 아키텍처: 실행기, 워크플로 그래프, 검증으로 신뢰할 수 있는 에이전트 만들기 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
똑똑한 에이전트가 어리석은 짓을 하지 않도록 막는 유일한 검증 절차가 있습니다.
0:04
바로 실행 전 계약 검사입니다.
0:07
어떤 도구든 실행되기 전에 검증기는 3가지를 순서대로 확인합니다.
0:11
위도가 실제 기능과 일치하는지, 호출자에게 현재 권한이 있는지,
0:14
그리고 요청된 결과가 선언된 데이터 범위 내에서 실행 가능한지 확인합니다.
0:18
어느 한 부분이라도 실패하면 아무것도 실행되지 않습니다.
0:21
단순히 조심하거나 시도하는 것이 아니라 이유와 대안을 제시하며 거부합니다.
0:24
먼저 기능 일치부터 확인합니다.
0:26
계획이 쉐어포인트 목록 항목을 업데이트하는 것이라고 가정해보겠습니다.
0:28
검증기는 어떤 도구, 어떤 방법, 어떤 스키마 버전을 사용할지 묻습니다.
0:32
인수는 레지스트리와 비교하여 검사합니다.
0:34
필수 필드가 있는지, 유형이 올바른지, 값 범위가 적절한지,
0:37
그리고 누군가 무시할 것을 기대하며 추가 필드가 숨겨져 있지 않은지 확인합니다.
0:41
도구 별칭 사용은 금지되어 있습니다.
0:43
정식 이름을 사용하거나 거부됩니다.
0:45
이를 통해 잘못된 도구 나추측성 매개변수가 오작동하기 전에 차단합니다.
0:49
다음으로 정책 준수 여부를 확인합니다.
0:51
정책 엔진은 제한된 호출을 활성 정책과 비교하여 평가합니다.
0:54
도구 및 도메인에 대한 허용 목록을 확인합니다.
0:57
RBAC 또는 ABC 검사는 아이디 클레임 및 범위 입력과 연계됩니다.
1:01
환경계층 규칙, 데이터 분류 경계도 고려됩니다.
1:04
에이전트의 범위가 특정 사이트의 파일 읽기로 제한된 경우,
1:07
업데이트 호출이나 다른 사이트로의 접근은 절대 허용되지 않습니다.
1:10
페이로드가 사람의 검토 없이 제한된 분류 영역에 접근하는 경우에도 마찬가지입니다.
1:14
토큰은 최신 상태로 검증되고, 범위는 정확하게 검증됩니다.
1:18
권한 상승 시도는 단 한 번이라도 명백한 침해 시도로 간주됩니다.
1:22
그 다음 사후 실행 가능성을 검토합니다.
1:24
단순히 원하는 결과만으로는 충분하지 않습니다.
1:27
발성 가능하고 검증 가능한 결과여야 합니다.
1:30
검증자는 대상이 항목 유효성 키를 지원하는지,
1:32
시스템에서 사후 확인이 가능한 연구식 별자 또는 이 태그를 생성하는지,
1:36
하위 시스템에서 오류가 발생할 경우 보상 조치가 있는지 등을 확인합니다.
1:39
검증 가능한 사후 조건을 제시할 수 없다면 계획은 거부되거나 재작성됩니다.
1:43
나중에 기록할게요.
1:43
라는 식의 접근 방식은 용납되지 않습니다.
1:45
나중에 기록하는 순간 사고가 발생하기 때문입니다.
1:47
이러한 요소들을 종합하면 영향일치, 정책 준수,
1:50
사후 실행 가능성이라는 세 가지 핵심 요소가 됩니다.
1:52
세 가지 조건을 모두 통과하면 실행자가 진행합니다.
1:54
하나라도 실패하면 이후 설명 경로가 활성화됩니다.
1:57
이 경로는 정중하고 철저하며 모호하지 않습니다.
2:00
시도한 내용, 위반한 정확한 정책 또는 스키마,
2:03
그리고 안전한 대안을 제시합니다.
2:05
사용자 의도를 수정할 수 있다면
2:06
범위를 좁히고 읽기 전용 요약으로 전환하거나 허용된 사이트로 연결합니다.
2:11
검증자는 규정을 준수하는 계획을 제안하고 수인을 요청합니다.
2:14
수정할 수 없다면 전체 컨텍스트와 함께
2:16
담당자 검토 단계로 넘어가 권하 작업을 즉시 중단합니다.
2:19
알 수 없는 지연이나 조용한 성공은 없습니다.
2:21
비록 몰라 더라도 경험했을 법한 간단한 예시입니다.
2:25
담당자에게 지난 분기에 모든 인사 문서를 요약하여
2:27
법무팀에 이메일로 보내라는 요청이 들어왔습니다.
2:29
검색은 인사 및 법무 사이트 전반에 걸친 그래프 커리를 제안합니다.
2:32
검증자는 경계 침범을 감지합니다.
2:34
인사팀은 접근이 제한되어 있고 법무팀은 내부 사용자입니다.
2:37
트리오 게이트는 규차 읽기와 외부 이메일을 차단합니다.
2:40
거부 경로가 반환됩니다.
2:42
제한된 콘텐츠가 감지되었습니다.
2:44
제한된 대안은 내부 정책 세균을 요약하고
2:46
승인된 검토자에게 인사 요약 요청 링크를 제공하는 것입니다.
2:50
사용자는 규정을 준수하는 계획을 승인합니다.
2:52
실행기는 이를 실행하고 내부 콘텐츠를 참조하며
2:55
인사 자료에 대한 권한 요청을 첨부합니다.
2:57
정보 유출이나 문제 발생 없이 여전히 유용합니다.
2:59
구현은 위도적으로 단순하게 설계되었습니다.
3:01
정책 DSL은 누가 무엇을 어디서 어떤 부작용과 함께 수행할 수 있는지 정의합니다.
3:05
스키마 레지스트리는 도구 계약, 이름, 버전,
3:08
인수 형태 및 사후 조건을 저장합니다.
3:09
허용 목록 확인자는 도메인, 사이트 및 범위를 환경계층에 맵핑합니다.
3:14
검증자는 이러한 요소들을 조합하고
3:16
모든 결정에 감사 기록, 입력, 정책 평가,
3:19
결과를 기록한 후 실행기에게 승인 또는 수정 계획을 전달합니다.
3:22
실행기는 절대 독단적으로 행동하지 않습니다.
3:25
결정을 시행하거나 중단합니다.
3:27
이 개념 모델은 아키텍처 다이어그램에
3:29
명확하게 새겨 넣을 수 있을 만큼 간단합니다.
3:31
실행기는 시행하고 그래프는 제약을 설정하고
3:33
검증자는 결정합니다.
3:34
이 순서대로 진행됩니다.
3:36
이 모델은 울타리 안에서만 작동하며 울타리를 넘으려는 순간
3:39
검증자가 모델을 되돌려놓고 이유를 설명하며 문을 가리킵니다.
3:43
질서가 유지되고 안전이 확보되며
3:45
진행이 막히지 않고 정책이 준수됩니다.
3:48
똑똑한 에이전트가 어리석은 행동을 하지 않도록
3:50
막아주는 단 한 가지가 필요하셨죠.
3:52
바로 이것입니다.
3:53
실제 변경이 발생하기 전에 역량, 권한,
3:56
검증 가능한 결과를 증명하는 사전 실행 계약 검사입니다.
3:59
할 수 있을 것 같다는 생각을 허용되고
4:01
방법을 알고 있으며
4:02
실행했음을 증명할 수 있다로 바꿔줍니다.
4:04
어둠은 우리에게 닥치지 않습니다.
4:06
이제 아키텍처가 완성되었으니 활용해보세요.
4:08
핵심 요점과 CT 분석을 함께 살펴보겠습니다.
4:11
핵심 요점은 프롬프트는 의견이고
4:13
실행기와 검증된 그래프는 작업이며
4:15
사전 실행 계약 검사느니
4:16
둘 모두를 정직하게 유지하는 안전장치라는 것입니다.
4:19
이 자료가 시간을 절약해 주었다면
4:21
구독으로 보답해 주세요.
4:23
다음으로는 랭그라프와 마이크로소프트 에이전트 프레임워크 위
4:26
성능 및 관찰 가능성 분석, 실제 추적, 비용,
4:29
P95 분석 영상을 시청하세요.
4:31
업그레이드 경로를 확정하고 알림을 활성화하고
4:33
다음 에피소드를 예정대로 받으세요.
4:35
계속 진행하세요.
4:36
많은 사람들이 더 나은 프롬프트가 불안정한 에이전트를 고친다고 생각합니다.
4:39
그럴듯한 생각이죠.
4:40
프롬프트는 생각을 안내할 뿐 작업을 실행하지는 않습니다.
4:43
진실은 에이전트의 안정성이 실행기와
4:44
그래프 유효성 검사에서 비롯된다는 것입니다.
4:46
이것이 바로 현실에 직면했을 때
4:48
에이전트가 실패하지 않도록 지탱하는 핵심입니다.
4:50
우리는 이것을 마이크로소프트 시나리오,
4:51
마이크로소프트 365 그래프 검색,
4:53
에이저 오픈 AI 추론,
4:54
그리고 폭주하지 않는 코파일럿 스튜디오 에이전트와 연결할 것입니다.
4:57
핵심은 간단합니다.
4:59
정확성, 지연시간, 비용, 그리고 감사 가능성입니다.
5:02
막연한 느낌이 아니라 측정 가능한 것입니다.
5:05
머릿속으로 실행할 수 있는 모델,
5:06
잊지 않을 설명이 담긴 다이어그램,
5:08
그리고 똑똑한 에이전트가 어리석은 행동을 하지 않도록 하는
5:10
한 가지 유효성 검사 단계를 제공하겠습니다.
5:12
처음부터 사용했어야 할 아키텍처입니다.
5:14
프롬프트가 작업 실행에서 실패하는 이유,
5:17
실행기는 성공하는 이유.
5:18
자, 핵심은 이렇습니다.
5:19
LLM은 인지를 처리하고,
5:22
실행기는 작업을 처리합니다.
5:23
이 둘을 섞으면 혼란이 생깁니다.
5:25
모델은 계획을 제한할 수는 있지만,
5:27
이메일이 전송되었는지, 파일이 저장되었는지,
5:30
권한이 있는지를 보장할 수는 없습니다.
5:32
모델은 확률로 말하지만,
5:34
실제 작업에는 보장이 필요합니다.
5:35
바로 이때 실행기가 등장합니다.
5:37
실행기는 마치 방안의 어른처럼,
5:39
상태 제약 조건과 항목의 유효성을 가진
5:41
정책기반 함수 실행기입니다.
5:43
실행기는 작업이 성공했다고 확신하지 않고,
5:45
검증합니다.
5:46
도구가 존재한다고 가정하지도 않습니다.
5:49
시도하기 전에 기능,
5:50
맥의 변수, 권한을 검증합니다.
5:52
그리고 실패하면 큰 소리로 실패를 알리고,
5:55
오류를 분류하고,
5:56
정해진 복구 경로를 따릅니다.
5:58
대부분의 프롬프트 전용 에이전트는
5:59
세 가지 실패 유형에 속합니다.
6:01
첫째, 잘못된 도구 요청입니다.
6:03
모델이 등록되지 않은 함수를 요청하거나,
6:05
존재하지 않는 필드를 사용하여
6:07
함수를 호출하는 경우입니다.
6:08
둘째, 사전 조건 누락입니다.
6:10
사이트, 목록 또는 항목 버전에 액세스할 수 있는지
6:13
확인하지 않고,
6:13
셰어포인트 파일을 편집하려고 시도하는 경우입니다.
6:15
셋째, 부분 오류입니다.
6:17
1단계가 실패했지만,
6:18
텍스트가 확신에 차 보인다는 이유로
6:19
에이전트가 계속 진행하여 성공을 선언하는 경우입니다.
6:21
이러한 오류를 본 적이 있을 것입니다.
6:22
방금 불안정하다고 하셨는데,
6:23
실행기는 지루해 보이는 루프를 실행합니다.
6:25
바로 그 때문에 제대로 작동하는 겁니다.
6:27
사전 조건,
6:27
입력, 권한 및 불변 조건을 확인합니다.
6:30
실행, 항목 효능키를 사용하여
6:31
도구를 호출하여
6:32
제시도 시 중복 청구나 중복 게시가 발생하지 않도록 합니다.
6:35
사후 조건,
6:36
원본 데이터와 비교하여 효과를 확인합니다.
6:39
오류 분류,
6:39
유효성 검사,
6:40
일시적 오류,
6:41
속도 제한,
6:42
초기 상태 오류 또는 정책 위반 중 어떤 오류인지 파악합니다.
6:45
복구,
6:45
일시적 오류의 경우 배고프 후 제시도,
6:47
인증 오류의 경우 재인증 또는 제동해,
6:49
알려진 대체 방법의 경우 풀백,
6:50
정책 위반의 경우 사유와 함께 강제 종료를 수행합니다.
6:53
멱등성은 필수 조건입니다.
6:55
제시도 가능한 작업에는
6:55
두 번째 시도를 아무 작업도 수행하지 않거나
6:58
일관된 재정의로 만드는 키가 필요합니다.
7:00
타임아웃은 좀비 호출을 방지합니다.
7:02
배고프는 속도 제한을 준수합니다.
7:03
이는 본질적으로 확률적인 텍스트 생성을 제어하는
7:07
결정론적 동작입니다.
7:09
실행기는 변속기이고,
7:10
LLM은 엔진입니다.
7:11
엔진을 풀악셀로 바꿔 바퀴가 알아서 작동하기를 바라는 건 잘못된 방식입니다.
7:15
계약 우선 출력 방식은 장황한 설명에 대한 해결책입니다.
7:18
추론 모델은 장황하게 설명할 필요가 없습니다.
7:20
도구 이름,
7:21
인수,
7:21
예상 사후 조건 등 스키마와 일치하는 JSON을 출력합니다.
7:24
유효성 검사기는 실행 전에 스키마 준수 여부를 확인합니다.
7:27
형식이 올바르지 않으면 실행기는 이유를 명시하여 실행을 거부하거나
7:29
수정된 계획을 요청하거나 문제를 상의 부서로 보고합니다.
7:32
이렇게 하면 장황한 설명이 실제 운영 환경에서 문제를 일으키는 것을 방지할 수 있습니다.
7:35
모델에 직접 검증을 요청할 수는 없나요?
7:37
라고 생각할 수도 있습니다.
7:38
물론 요청할 수 있습니다.
7:40
모델은 항상 그렇다고 대답할 것입니다.
7:41
일반 사용자는 이를 당연하게 여깁니다.
7:43
하지만 전문가에게는 증명이 필요합니다.
7:45
증명은 마이크로소프트 그래프,
7:46
시어포인트,
7:47
익스체인지와 같은 시스템을 통해 검증된 사후 조건에 존재합니다.
7:49
모델의 메모리가 아닌 실제 진실의 원천입니다.
7:51
하지만 여기서 흥미로운 점이 있습니다.
7:53
반일 단계는 괜찮습니다.
7:54
실제 워크플로는 분기,
7:55
병렬처리,
7:56
보상,
7:57
그리고 사람의 검토 지점을 포함합니다.
7:59
실행기만으로는 부족합니다.
8:00
실행기가 읽을 수 있는 지도가 필요합니다.
8:02
바로 워크플로 그래프입니다.
8:03
그래프에서 노드는 명시적인 계약을 가진 작업 또는 하위 에이전트입니다.
8:06
엣지는 제어 흐름과 데이터 흐름을 정의합니다.
8:08
상태는 최우선 순위입니다.
8:09
무엇이 연구적인가요?
8:10
무엇이 체크포인트로 저장되나요?
8:11
무엇이 일시적인가요?
8:12
실행기는 가게지의 허용 목록과 스키마를 준수하며
8:15
그래프를 결정론적으로 탐색합니다.
8:16
노드에 오류가 발생하면 그래프는 보상,
8:18
실행, 취소, 복구 또는 에스컬레이션을 지정합니다.
8:21
알 수 없는 파이프라인은 없습니다.
8:23
그리고 마법이 일어납니다.
8:25
바로 이 순간 신뢰성이 반전됩니다.
8:27
LLM 이 제안하고 실행기가 실행하며
8:29
그래프 제약 조건 유효성 검사가 결정합니다.
8:32
질서가 복원됩니다.
8:33
인지와 운영을 분리하면
8:34
에이전트는 즉흥적인 행동을 멈추고 제대로 작동하기 시작합니다.
8:38
물론 에이전트는 여전히 똑똑하지만
8:40
이제는 감독을 받습니다.
8:41
청사진 준비가 완료되었습니다.
8:43
테넌트를 무능하게 만들지 않고
8:44
마이크로소프트 365에 연결해보겠습니다.
8:46
그래프 워크플로우의 기본입니다.
8:49
노드, 엣지, 그리고 누출되지 않는 상태.
8:51
상상해보세요.
8:52
신뢰할 수 있는 실행기는 있지만 지도가 없습니다.
8:54
명령은 따르겠지만 어디로 향할까요?
8:56
워크플로우 그래프, 즉 운영 매뉴얼이 필요합니다.
8:59
노드는 명확한 계약을 가진 작업 또는 하위 에이전트입니다.
9:02
엣지는 제어 흐름과 데이터 흐름을 정의합니다.
9:04
그래프는 무엇이 언제 실행되는지
9:05
그리고 어떤 데이터가 경계를 넘나들 수 있는지를 인코딩합니다.
9:08
즉흥 연주나 재즈는 없습니다.
9:10
악보처럼 정확하게 그려야 합니다.
9:12
먼저 모양부터 정해야 합니다.
9:13
대부분의 실제 운영 환경에서 그래프는 대그, 방향 비순환 그래프입니다.
9:16
순환은 무한 루프와 상태 손상을 초래하기 때문입니다.
9:19
물론 루프가 발생할 수는 있지만
9:21
카운터와 가드, 최대 반복 횟수, 종료 조건, 타임 아웃 등을 사용하여
9:25
위도적으로 표시해야 합니다.
9:26
이렇게 해야 더 열심히 생각하라, 늦말이
9:28
끝없이 생각하라, 늦말로 이어지지 않도록 할 수 있습니다.
9:30
조건부 라우팅은 명시적으로 정의해야 합니다.
9:33
검색 신뢰도가 인계값 이상 이면 합성 단계로 분기하고
9:35
그렇지 않으면 재조회 단계로 분기합니다.
9:38
병렬 처리는 최우선 사항입니다.
9:40
요약과 인용 추출을 나란히 실행한 다음
9:42
두 작업 모두 사후 조건을 충족했는지 확인하는
9:45
장벽 노드에서 결합합니다.
9:47
상태는 단순한 느낌이 아니라 기록입니다.
9:49
세 가지 유형의 상태를 유지해야 합니다.
9:51
첫째, 연구 상태는 충돌 후 복구할 수 있는
9:52
내구성 있는 체크 포인트, 입력, 결정, 서명된 액션입니다.
9:56
둘째, 임시 상태는 장기 메모리를 오염시키고 싶지 않은
9:58
중간 모델 출력과 같은 수명이 짧은 버퍼입니다.
10:00
셋째, 파생 상태는 인베딩이나 필터링된 결과와
10:03
같이 결정론적으로 생성할 수 있는 재계산 가능한 아티팩트입니다.
10:05
규칙은 간단합니다.
10:06
감사해서 방어할 수 있는 것만 연구적으로 저장해야 합니다.
10:09
나머지는 모두 의도적으로 폐기해야 합니다.
10:11
롤백 전략은 중요합니다.
10:13
노드가 외부 세계를 변경하거나 캘린더 이벤트를 생성하거나
10:15
목록 항목을 업데이트할 때
10:16
존재하는 경우 역방향 액션을 기록하고
10:18
존재하지 않는 경우 보상 계획을 기록해야 합니다.
10:22
하위 노드에 치명적인 오류가 발생하면
10:24
그래프는 역순으로 이러한 보상 계획을 실행할 수 있습니다.
10:26
이는 과도한 조치가 아니라
10:27
CEO 위 일정이 겹치는 등의 오류를 방지하는 방법입니다.
10:31
엣지는 계약을 전달합니다.
10:33
엣지는 알 수 없는 파이프가 아니라
10:34
노드 간의 api입니다.
10:36
io 스키마, 유형, 필수 필드, 허용 값을 정의해야 합니다.
10:40
허용 목록을 정의하여
10:41
다음 노드가 호출할 수 있는 도구나 도메인을 지정합니다.
10:43
기능 태그를 정의하여
10:45
수신 노드가 수행할 작업과 거부할 작업을 지정합니다.
10:48
실행기는 런타임에 이러한 사항을 적용합니다.
10:50
노드는 요약 에즈를 통해
10:51
시어포인트 토큰을 몰래 전송할 수 없습니다.
10:54
이는 보여주기식 보안이 아니라
10:55
에이전트의 측면 이동을 방지하는 방법입니다.
10:58
오류 처리는 그래프 내에서 이루어지며
11:00
분위기에 좌우되지 않습니다.
11:01
모든 노드는 유효성 검사 오류, 임시 인프라, 속도 제한, 인증, 권한 부여,
11:08
정책 위반 및 알 수 없음과 같은 오류 분류 체계를 선언합니다.
11:12
그래프는 각 클래스에 대한 처리 경로를 제공합니다.
11:14
임시 오류의 경우 지수 배고프를 사용한 제시도,
11:16
인증 오류의 경우 토큰 갱신, 속도 제한 오류의 경우 대체도구 사용,
11:19
정책 위반 오류의 경우 사유와 함께 거부 등의 방법을 사용합니다.
11:22
알 수 없음 오류를 위한 데드레터큐도 존재합니다.
11:24
실패한 페이로드는 전체 컨텍스트와 함께 격리되어
11:27
사람이 프로덕션 환경에 혼란을 야기하지 않고 검사할 수 있습니다.
11:30
사람이 직접 참여하는 체크 포인트는 임시방편적인 슬랙 메시지가 아닙니다.
11:34
실행을 일시 중지하고 제한된 조치와 증거를 제시하며
11:37
로그에 기록되고 서명된 승인 또는 수정을 요구합니다.
11:40
승인되면 실행이 재개됩니다.
11:41
거부될 경우 그래프는 안전한 대체 경로로 이동합니다.
11:44
축하합니다.
11:45
개발자들이 이메일보다 빠르기 때문에 실제로 따를 만한 변경 관리 시스템을 구현하셨습니다.
11:50
메모리 격리는 필수적입니다.
11:52
각 세션은 필요한 문서, 토큰, 중간 결과만 접근할 수 있는 범위가 제한된 컨텍스트를 갖습니다.
11:57
세션 간 오염, 즉 한 대화의 프롬프트 주입이 다른 대화로 스며드는 것을 방지하여 데이터 유출을 막습니다.
12:03
그래프는 경계를 염격하게 적용합니다.
12:05
공유되는 가변 메모리는 없으며 콘텐츠 필터와 스키마 유효성 검사기가 있는 검증된 저장소에서 승인된 읽기만 허용합니다.
12:11
인베딩과 요약을 캐시할 수 있지만 출처와 권한으로 태그를 지정하고 정책 변경 시 삭제해야 합니다.
12:15
관찰 가능성은 기본적으로 내장되어 있으며 추가되는 것이 아닙니다.
12:18
노드 수준 추적을 통해 입력, 출력, 지속시간, 제시도 횟수, 하위 시스템에 미치는 영향을 확인할 수 있습니다.
12:23
그래프 실행 아이디로 추적 기록을 연결하면 재연, 진단 및 규정 준수 입증이 가능합니다.
12:27
누가 무엇을 언제 외했는지 파악할 수 있습니다.
12:30
이상 탐지 기능은 이상한 패턴, 도구 호출에 갑작스러운 급증, 비정상적인 도메인, 토큰 폭주 등을 감지합니다.
12:35
이는 흥미로운 일이 사고로 발전하기 전에 미리 경고하는 시스템입니다.
12:39
기본적으로 그래프는 헌법과 같습니다.
12:40
집행자는 법 집행기관이고 LLM은 판사가 아닌 변호사입니다.
12:44
이처럼 노드, 엣지, 상태를 인코딩하면 단순히 워크플로우가 성공하는 것뿐만 아니라 안전하게 실패하고
12:49
자체적으로 설명하며 예측 가능하게 복구되는 워크플로우를 얻을 수 있습니다.
12:53
이제 청사진을 바탕으로 테넌트를 무분별하게 사용하지 않고도 마이크로소프트 365에 연결할 수 있습니다.
12:58
설계 단계부터 보안을 고려한 것입니다.
13:00
그래프 유효성 검사는 카오스 엔지니어링보다 효과적입니다.
13:03
프로덕션 환경에 혼란을 야기하고 살아남은 시스템이 보권력을 갖추기를 바라는 방식으로 신뢰성을 입증할 수는 없습니다.
13:08
실행되기 전에 안전하지 않은 워크플로우를 거부함으로써 신뢰성을 입증해야 합니다.
13:11
이것이 바로 그래프 유효성 검사입니다.
13:13
정적 검사를 통해 불필요한 요소를 차단하고 넌타임 가드레일을 통해 위험을 방지합니다.
13:16
정적 유효성 검사는 사전 검사와 같습니다.
13:18
실행 전에 구조를 점검해야 합니다.
13:20
무한 루프를 생성하는 사이클은 거부되거나 반복 방지 기능을 선언해야 합니다.
13:24
도달할 수 없는 노드, 사용되지 않는 코드는 삭제하거나 정당화해야 합니다.
13:27
누락된 계약이 있는지 확인해야 합니다.
13:29
모든 노드는 입력 및 출력 스키마, 필수 기능, 부작용을 명시해야 합니다.
13:33
권한 경계를 명확히 해야 합니다.
13:35
외부 시스템을 변경하는 노드는 최소 권한 자격 증명과 명시적인 허용 목록을 사용하는 세그먼트에서 실행되어야 합니다.
13:41
그리고 요약 노드가 갑자기 셰어포인트에 대한 쓰기 권한을 요청하면 검증기는 즉시 거부합니다.
13:46
이제 런타임 단계입니다.
13:48
여기서 많은 사람들이 실수를 저지릅니다.
13:50
정책 엔진은 실행기 뒤에 있는 것이 아니라 실행기 옆에 있습니다.
13:53
도구 및 도메인 허용 목록은 문서가 아니라 강제적인 결정사항입니다.
13:57
호출 시 엔진은 활성 주체, 내부 아이디 토큰, 범위, 클레임을 기준으로 모든 사항을 확인하고 체인 아래로 정확하게 전파합니다.
14:04
외부에서 부여되는 권한은 없습니다.
14:06
토큰은 범위가 지정되고 허용될 때 갱신되며 우호적인 경계를 통해 몰래 전달되지 않습니다.
14:10
에이전트는 모든 호출에서 액세스 권한을 획득하거나 그렇지 않으면 호출하지 않습니다.
14:14
입력 및 출력 검증은 필수 사항이며 선택 사항이 아닙니다.
14:16
프롬프트 주입은 영리한 방법이 아니라 예측 가능한 방법입니다.
14:19
모든 인바운드 콘텐츠 소스는 콘텐츠 필터, html, 마크 다운 스크러버, 그리고 불필요한 내용을 제거하는 명령어 방화벽을 거칩니다.
14:27
출력은 스키마 유효성 검사기를 통과합니다.
14:30
노드가 json 형식을 약속했다면 실행기는 일반 텍스트를 거부하고 수정을 요청합니다.
14:34
모델은 논쟁할 수 있지만 유효성 검사기는 협상하지 않습니다.
14:37
유효성 검사기는 유형, 범위, 그리고 불변 조건을 강제합니다.
14:40
샌드박싱과 세분화는 공격 반경을 제한합니다.
14:43
외부 코드나 신뢰할 수 없는 커넥터를 호출하는 노드는 제한된 환경에서 실행됩니다.
14:48
api 게이트웨이는 속도 제한 및 네트워크 정책을 통해 측면 이동을 방지하고
14:52
검증된 도메인으로만 트래픽을 허용하는 송신 제어를 제공합니다.
14:56
프로덕션 환경에서 검색 노드가 새로운 데이터 소스를 발견하도록 허용해서는 안 됩니다.
15:00
데이터 발견은 테스트 환경 뒤에서 개발 환경에서 이루어지며 허용 목록에 대한 서명된 업데이트가 적용됩니다.
15:05
관찰 가능성은 어딘가에 기록되는 것이 아니라 정밀하게 관리됩니다.
15:08
노드 수준 추적은 입력, 출력, 지속시간, 제시도 횟수, 그리고 정책 엔진의 결정사항을 기록합니다.
15:13
모든 것을 실행 아이디로 연관시킵니다.
15:15
감사 로그는 변경 불가능하며 어떤 주체가 어떤 범위로 어떤 시점에 어떤 작업을 승인했는지
15:19
그리고 정책이 왜 이를 허용했는지에 대한 정보가 기록됩니다.
15:22
규제 기관에서 누가 무엇을 했는지 물으면 어깨를 으쓱하는 대신 철저히 조사해야 합니다.
15:25
규정 준수 준비 완료란 증거가 완벽하고 명확하다는 것을 의미합니다.
15:28
패치 및 타사 위험은 공급망 문제이므로 그에 맞게 처리해야 합니다.
15:32
모든 빌드에서 중속성 검사를 실행합니다.
15:34
커넥터와 플러그인은 감사를 거치고 버전을 고정하고 권한 확장 여부를 검토합니다.
15:38
mcp 또는 오픈 api 사양을 가져오는 경우 선언된 메서드가 예상하는 최소 권한 정책과 일치하는지 검증합니다.
15:45
와일드카드 엔드포인트 나 읽기 전용으로 의장한 숨겨진 쓰기 경로는 허용되지 않습니다.
15:50
위생관리는 화려하지 않지만 여러분이 잠을 잘 수 있는 이유입니다.
15:53
진실 그래프 검증은 하우스 엔지니어링보다 효과적입니다.
15:56
왜냐하면 하우스 엔지니어링은 그 여파를 문서화하는 것이 아니라 특정 유형의 사고를 예방하기 때문입니다.
16:00
여전히 장애모드를 테스트하지만 이는 가드레이를 설치하는 것을 잊었는지 확인하기 위한 것이 아니라 가드레이를 확인하기 위한 것입니다.
16:04
이제 이 모든 것을 사고 모델에 적용해보겠습니다.
16:07
정적검사는 설계도를 건전하게 유지합니다.
16:09
불가능한 경로도 없고 버려진 작업도 없고 권한 유출도 없습니다.
16:13
런타임 가드레일은 동작을 건전하게 유지합니다.
16:16
모든 호출은 인증, 권한 부여, 검증 및 관찰됩니다.
16:20
실행기는 검증기가 결정한 그래프 제약 조건을 적용합니다.
16:23
모델은 경계 내에서 제한하고 벗어나 면 수정됩니다.
16:27
이게 부담스럽지 않을까요?
16:28
위반을 즐기는 사람이 아니라면 부담스럽지 않습니다.
16:30
오버헤드는 기계적이고 자동화되어 있습니다.
16:32
정적 유효성 검사는 빌드 시간과 배포 시간에 실행됩니다.
16:35
런타임 정책은 사이드카처럼 빠르고 로컬에서 실행됩니다.
16:38
스키마 검사는 밀리초 단위로 처리됩니다.
16:40
제거되는 비용, 사고, 수동 검토, 수정은 추가되는 미세한 지연 시간에 비해 훨씬 적습니다.
16:45
그리고 그 효과는 측정 가능합니다.
16:47
무단 호출 감소, 토큰 폭발 감소, 사후 분석 횟수 감소 등이 그 예입니다.
16:54
일반 사용자가 간과하는 또 다른 중요한 점은 유효성 검사가 구성 가능하다는 것입니다.
16:58
타사 도구를 프록시 노드로 감싸서 도구 자체를 신뢰하지 않고도 계약과 정책을 적용할 수 있습니다.
17:04
민감도, 공개, 내부, 제한됨별로 그래프를 분할하고 새 경계에 대한 유효성 검사를 통과한 후에만 계층 간 워크플로우를 승격시킬 수 있습니다.
17:12
이것이 바로 안전한 확장을 위한 핵심입니다.
17:15
설계 단계부터 보완을 고려하는 것은 단순한 슬로건이 아니라 워크플로우의 핵심 속성입니다.
17:18
에이전트가 제대로 작동하기를 바라는 것이 아니라 오작동을 구조적으로 어렵게 만들고 운영상 가시화해야 합니다.
17:23
이러한 기반이 마련되면 마이크로소프트 365 그래프와 에이저 오픈하이를 연결하는 것은 더 이상 복불복이 아닙니다.
17:28
원하는 방식으로 제어된 권한을 행사할 수 있습니다.
17:30
이제 문제 해결이 아닌 연결 작업에 대해 이야기할 수 있습니다.
17:33
마이크로소프트 시나리오, 즉 M365 그래프, 에이저 오픈하이, 코파일러 스튜디오를 사용하는 경우를 살펴보겠습니다.
17:39
각 구성 요소를 구성해보겠습니다.
17:40
검색 에이전트는 최소 권한으로 마이크로소프트 그래프에서만 데이터를 가져오는 신중한 관리자입니다.
17:45
추론 에이전트는 에이저 오픈하이 모델로서 계획, 위치 선정 등을 수행하며 주어진 범위를 벗어나 임의로 행동하지 않습니다.
17:52
실행기는 정책에 따라 도구를 실행하고 멱등성과 사후 조건 검사를 수행합니다.
17:57
유효성 검사기는 스키마, 정책 및 경계를 염격하게 적용하는 역할을 합니다.
18:02
정책가드는 모든 것을 엔트라 아이디 범위 및 RBAC에 연결하는 런타임 사이드카입니다.
18:07
이들은 마치 유능한 팀처럼 작동하며 위원회 회의처럼 단순하게 처리되지 않습니다.
18:10
데이터 접근은 추측이 아닌 그래프 기반으로 시작됩니다.
18:12
검색 에이전트는 세분화된 범위를 가진 앱 등록 정보를 보유합니다.
18:16
파일은 특정 사이트에서만 읽을 수 있고, 메일은 제한된 사서함에서 기본 읽기 권한을 가지며,
18:19
캘린더는 특정 리소스 캘린더에서만 읽을 수 있습니다.
18:21
그래프를 이용한 모든 읽기, 쓰기 권한 부여는 없습니다.
18:24
커리는 델타 및 선택적 필드를 사용하여 페이로드를 최소화합니다.
18:27
페이징은 최우선 순위로 제공됩니다.
18:29
실행기는 타임아웃을 준수하며 서비스 스로틀링을 고려하여 다음 링크를 결정적으로 따라갑니다.
18:33
429 오류가 발생하면 배고프는 수학적으로 계산됩니다.
18:36
짜증 없이 기하급수적인 인내심으로 처리합니다.
18:38
안정성은 단순한 분위기가 아니라 체계적인 파이프라인입니다.
18:41
그래프 검색 또는 목록 커리를 통해 후보 문서를 검색할 수 있습니다.
18:44
항목 아이디와 버전 에태그를 사용하여 중복을 제거함으로써 오래된 데이터와 최신 데이터가 혼합되지 않도록 합니다.
18:48
의미 경계, 섹션 헤더, 슬라이드 구분선을 기준으로 데이터를 청크로 분할한 다음,
18:52
출처, 드라이브, 사이트, 경로, 항목 아이디, 최종 수정일, 할당된 해시값을 첨부합니다.
18:57
추론 에이전트는 청크와 메타 데이터만 인식하며 해당 아이디에 맵핑된 인용 정보를 출력해야 합니다.
19:03
인용 정보가 없으면 클레임도 발생하지 않습니다.
19:05
실행기는 모든 외부 작업 전에 이를 사후 조건으로 적용합니다.
19:08
코칭을 위해 코파일러 스튜디오를 활용합니다.
19:11
명시적인 스키마와 허용 목록이 있는 프록시 뒤에서 선언적 도구, 그래프 커리 팩,
19:15
시어포인트 쓰기 작업, 팀제 게시물, 아울룩 전송 등을 정의할 수 있습니다.
19:19
에이전트 간 조정은 구조화 되어 있습니다.
19:21
검색 에이전트는 기본 도구를 제공하고,
19:23
추론 에이전트는 매개 변수와 함께 해당 도구를 요청합니다.
19:26
실행기는 중재, 유효성 검사를 거쳐 기본 컨텍스트를 반환합니다.
19:30
사람이 검토할 수 있는 검토 지점이 기본적으로 제공됩니다.
19:33
제한된 작업 노드는 실행을 일시 중지하고,
19:36
계획과 인용 정보를 표시하며 수인을 요구합니다.
19:38
승인은 서명 후 로그에 기록됩니다.
19:40
거부 시에는 안전한 대안 또는 에스컬레이션으로 연결됩니다.
19:43
토큰과 지연 시간은 관리되며 단순히 무시할 필요가 없습니다.
19:46
선택적 컨텍스트란 전체 테넌트가 아닌 관련 데이터 조각만 제공하는 것을 의미합니다.
19:50
요약 정보는 콘텐츠 해시와 권한을 키로 사용하는 인베딩과 함께 미리 계산되어 캐시됩니다.
19:55
문서가 변경되면 키가 변경되고, 캐시가 누락되면 다시 계산됩니다.
19:59
스트리밍 응답은 실행기가 전체 스키마 유효계획이 도착한 후에만 부작용을 처리하는 동안 UI를 계속 활성화합니다.
20:04
신뢰도와 적용 범위가 인계값에 도달하면 조기 종료 조건이 추론 루프를 중지합니다.
20:09
모델이 시적이라고 해서 불필요한 고민을 할 필요가 없습니다.
20:12
감사 기능이 내장되어 있습니다.
20:14
모든 작업은 서비스 주체 또는 위임된 사용자가 서명하고 실행 아이디, 도구, 렉의 변수, 필요한 경우 수정됨, 범위 및 결과가 기록됩니다.
20:23
변경 불가능한 로그는 관찰 가능성 스택에 저장됩니다.
20:26
원하는 방식을 선택하세요.
20:28
따라서 부작용을 다시 실행하지 않고도 실행을 다시 재생할 수 있습니다.
20:31
누가 무엇을 언제 왜 했는지 파악하는 것은 마녀사냥이 아닌 커리가 됩니다.
20:34
또한 인용 정보는 그대로 유지됨으로 답변이 모델 법칙이 아닌 실제 테넌트 콘텐츠에서 비롯되었는지 확인할 수 있습니다.
20:39
실패는 일상화되어 지루하게 느껴집니다.
20:41
429초가 지나면 실행기는 짙어, 짙어, 를 적용하여 제시도 하고, 그래도 문제가 해결되지 않으면 비용이 낮은 커리를 사용하거나 페이지 크기를 줄여서 처리합니다.
20:47
캐시가 만료되면 유효성 검사기가 에테그 불일치를 감지하고 새로 고침을 강제합니다.
20:51
권한이 거부되면 정책관리자는 사유와 함께 거부하거나 동의 요청 경로를 제한하거나 정보가 유출되지 않도록 수정된 요약으로 연결합니다.
20:58
도구에 장애가 발생하면 그래프는 대체 방법을 제시하거나 전체 컨텍스트와 함께 실행을 대기열에 넣어 사람이 직접 수정할 수 있도록 합니다.
21:04
확정적 대체 방법은 인시던트를 티켓으로 전환합니다.
21:08
이제 간단한 예시를 살펴보겠습니다.
21:09
사용자가 지난 둥기 로드맵 결정사항 요약본을 링크와 함께 작성해주세요.
21:13
라고 요청합니다.
21:14
추론 에이전트는 특정 시어포인트 사이트와 팀즈 채널에서 그래프 검색을 사용하고, 지난 둥기로 필터링한 다음 결과를 종합하세요.
21:20
라고 제안합니다.
21:21
유효성 검사기는 요청된 범위가 에이전트의 역할과 일치하는지 확인합니다.
21:24
일치합니다.
21:25
실행기는 페이직 및 필드 선택 기능을 사용하여 그래프 검색을 실행하고,
21:28
항목 아이디로 중복을 제거하고, 데이터를 청크로 분할한 후, 출처 정보가 포함된 컨텍스트를 반환합니다.
21:32
추론 과정에서 항목 아이디에 맵핑된 인라인 인용문이 포함된 요약이 생성됩니다.
21:36
검증자는 스키마와 인용문을 확인하고 통과합니다.
21:39
사람이 직접 검토하여 요약과 증거를 제시합니다.
21:41
승인자는 확인을 클릭합니다.
21:43
실행자는 결과를 팀즈에 게시하고, 이해 관계자에게 이메일을 보냅니다.
21:46
각 작업은 항목 유효성 키를 사용하여 제시도시 중복 게시를 방지합니다.
21:49
엄격한 규칙을 준수해야 합니다.
21:50
어떤 에이전트도 자체 도구를 만들지 않으며, 어떤 노드도 허용 목록 외위 도메인을 넘나들지 않습니다.
21:55
토큰은 엔트라 아이디를 통해 정확하게 범위가 지정되고 전파되며, 노드 간에 복사하여 붙여넣지 않습니다.
22:00
모델은 성공을 결론 짓지 않습니다.
22:02
실행자가 그래프 게시 조건을 통해 성공을 입증합니다.
22:05
생성된 메시지 아이디, 업데이트된 항목의 태그, 캘린더 이벤트 아이디를 기록한 후 실행 완료를 표시합니다.
22:10
물론, MCP 또는 오픈 API를 통해 플래너, 비바 또는 타사 서비스를 안전하게 확장할 수 있지만,
22:14
엄격한 스키마와 네트워크 송신 제어를 갖춘 프록시 도구 뒤에서만 가능합니다.
22:18
모든 커넥터를 동일한 검증 로직과 정책 가드로 감싸야 합니다.
22:22
환경 간 승격에는 새로운 경계에 맞는 검증 통과가 필요합니다.
22:25
개발에서 테스트, 그리고 프로덕션까지 범위 확장을 검토하고, 가정하지 않고 체계적으로 진행하는 것.
22:29
이것이 마이크로소프트의 제대로 된 아키텍처입니다.
22:31
그래프는 진실을 담고, 에이저 오픈아이는 사고를, 코파일럿 스튜디오는 오케스트레이션을, 실행기는 운영을,
22:38
검증기와 정책은 안전성을, 그리고 관찰 가능성은 증명을 담당합니다.
22:41
이제 감정이 아니라 수치를 보여줘야 합니다. 전후 비교 지표, 정확도, 지연 시간, 비용, 관리 오버헤드를 분석해야 합니다.
22:48
훌륭한 아키텍처, 이제 증명해 보이세요. 감정이 아니라 수치가 중요합니다. 기준선부터 시작해야 합니다.
22:53
프롬프트만 사용하는 에이전트는 과장된 반응을 보입니다.
22:55
출처를 임의로 만들고 인용을 잊어버리기 때문에 정확도가 일정하지 않습니다.
22:58
근거가 없으면 아무 의미 없는 자신감 넘치는 문장만 늘어놓게 됩니다.
23:02
꼬리 지연 시간은 엄청납니다.
23:04
불필요한 컨텍스트로 가득 찬 일련의 반복적인, 더 깊이 생각하기 호출이 이어집니다.
23:08
매 단계마다 전체 녹취록과 원본 문서를 마치 비싼 택배처럼 모델에 전송하기 때문에 비용이 눈덩이처럼 불어납니다.
23:15
관리 오버헤드는 어떻습니까? 높습니다.
23:17
사고, 핫픽스, 원인을 알 수 없는 오류, 그리고 눈가리개를 하고 하는 고고와 발굴처럼 느껴지는 감사까지.
23:22
이제 실행기와 검증된 그래프를 갖춘 개선 후 상태를 살펴봐야 합니다.
23:25
주장에 대한 근거가 필요하기 때문에 정확도가 크게 향상됩니다.
23:28
그래프 항목 아이디, 이 태그.
23:30
서명된 해시와 연결된 검증된 인용 정보 덕분에 출처가 불분명한 답변은 검증을 통과하지 못합니다.
23:35
그 효과는 즉각적입니다. 잘못된 답변이 줄어들고 재작업 횟수가 감소하며 평가 세트에서 작업 성공률이 눈에 띄게 향상됩니다.
23:42
주장을 뒷받침할 수 없는 경우 에이전트는 이유를 명시하여 거부하거나 사람의 쓰인을 요청합니다.
23:46
예측 가능하고 검토 가능하며 안전합니다.
23:49
지연 시간은 세 가지 이유로 단축됩니다.
23:51
첫째, 병렬 처리, 검색, 재순위 지점, 인용 정보 추출이 동시에 실행된 후 장벽 노드에서 동기화됩니다.
23:57
둘째, 콘텐츠 해시와 권한 범위를 기준으로 캐싱, 인베딩, 요약을 수행하여 변경되지 않은 부분을 다시 계산하지 않습니다.
24:03
셋째, 조기 종료가 가능합니다.
24:05
적용 범위와 신뢰도가 인계값에 도달하면 그래프는 루프를 중지합니다.
24:08
모델이 단락을 제시하고 사용자가 종료 시점을 고민하는 직렬 프롬프트 방식과 비교해보세요.
24:13
토큰 사용이 의무화됨으로 비용이 절감됩니다.
24:16
스키마 제약 출력은 장황한 설명을 방지합니다.
24:19
선택적 컨텍스트는 전체 사이트가 아닌 관련 메타데이터 덩어리에만 정보를 제공합니다.
24:23
프롬프트가 짧아지고 응답이 간결해지며 제시도 횟수가 줄어듭니다.
24:27
실행기의 항목 효능 및 105 프로직은 중복 호출과 낭비되는 사이클을 방지합니다.
24:31
결과적으로 성공적인 결과 당 토큰 수가 줄어들고 변동성이 크게 감소합니다.
24:35
재무부서는 변동성 감소를 선호합니다.
24:37
관찰 가능성이 설계에 기반함으로 관리 오버헤드가 줄어듭니다.
24:40
노드 수준 추적 및 변경 불가능한 로그는 문제 진단 시간을 단축합니다.
24:44
어떤 노드가 실패했는지, 정책 엔진이 왜 거부했는지, 실행기가 다음에 무엇을 시도했는지 확인할 수 있습니다.
24:49
반복 가능한 배포는 머신 테스트 환경을 없애줍니다.
24:52
모든 실행에 누가, 무엇을, 언제, 왜 했는지에 대한 정보가 이미 포함되어 있으므로 규정 준수는 더 이상 계절적인 위기가 아닙니다.
24:59
실제로 실행 가능한 측정 시스템을 통해 이를 구체화해보겠습니다.
25:02
대표적인 작업, 인용이 포함된 질의 응답, 링크가 포함된 요약, 승인이 포함된 실행 제한으로 구성된 평가 세트를 구축합니다.
25:08
각 작업에 대해 정의된 정답 또는 승인 기준을 설정합니다.
25:11
맵핑된 항목 아이디, 인용 범위 및 허용된 변동성을 통해 사실을 정확하게 파악합니다.
25:15
SLO P50 및 P95의 엔드투 엔드 지연 시간, 성공적인 작업당 토큰 사용량, 정책 거부율을 측정합니다.
25:21
모든 지표를 추적에 연결하여 회귀분석 시 추적 가능한 경로를 제공합니다.
25:25
아키텍처를 준수할 경우 기대할 수 있는 결과이며, 임의로 변경해서는 안 됩니다.
25:29
지원되지 않는 클레임은 스테이징 환경을 벗어나지 않으므로 답변 유효성이 향상됩니다.
25:33
병렬로드와 조기 종료를 통해 긴 꼬리 부분이 잘려나가 무로 P95 지연 시간이 단축됩니다.
25:38
방대한 내용을 배포하는 대신 관련성 있는 스니펫을 배포함으로 토큰 사용량이 줄어듭니다.
25:43
대부분의 오류가 예측 가능한 대체 기능으로 처리되므로 관리자에게 표시되는 페이지 수가 줄어듭니다.
25:48
그리고 모두가 잊어버리는 지루한 지표도 있습니다.
25:51
첫 번째 시도 성공률이 높아져 사람의 개입 없이 더 많은 작업이 완료됩니다.
25:55
비즈니스 영향 측면에서 문제 해결 속도가 빨라지면 사용자가 중복 티켓을 열지 않게 됩니다.
25:59
예측 가능한 지출로 예상치 못한 토큰 초과 없이 예산을 측정할 수 있습니다.
26:02
규정 준수에 대한 확신이 높아져 감사 주기가 줄어들어 로드맵의 차질이 생깁니다.
26:06
눈에 띄지 않는 이점은 평판 향상입니다.
26:08
상담원의 답변이 테넌트 콘텐츠를 참조하고 링크가 제대로 작동하면 사람들은 이를 신뢰하고 사용하며
26:13
왜 이렇게 나왔죠? 라는 질문으로 시작하는 스크린샷을 더 이상 공유하지 않습니다.
26:18
직접적이고 필수적인 조언을 제공하고 추적 데이터와 매트릭 간의 연관성을 측정하거나
26:21
그렇지 않으면 단순히 주관적인 의견에 의존하는 것입니다.
26:23
실행 결과를 열어 어떤 노드에서 토큰이 부풀려졌는지 지연 시간이 증가했는지 정확히 확인할 수 없다면
26:27
관찰 가능성이 아니라 타임 스탬프만으로 짐작하는 것에 불과합니다.
26:30
검증자가 훌륭한 계획과 실제 실행 사이에 위치할 때 모든 것이 바뀝니다.
26:34
정확도가 안정화되고 지연 시간이 단축되고 비용이 안정화되고 관리자는 편안하게 잠을 잘 수 있습니다.
26:39
이는 마법이 아니라 실행기, 그래프, 그리고 검증이 프롬프트에 잘못 할당했던 작업을 대신 수행해주는 결과입니다.