WEBVTT

00:00:00.000 --> 00:00:04.120
아시다시피, 채꽃은 말하고, 에이전트는 행동하고, 멀티 에이전트 시스템은 실제로 작업을 처리합니다.

00:00:04.280 --> 00:00:08.180
인튠 문제를 해결해달라고 보세게 부탁했는데, 시 한 편만 읊어준 경험이 있다면, 이 글이 도움이 될 겁니다.

00:00:08.380 --> 00:00:09.780
넷플릭스를 직접 체험해보세요.

00:00:10.080 --> 00:00:12.020
여러분은 편하게 시청하시고, 간식도 드세요.

00:00:12.200 --> 00:00:15.060
저는 위험 서비스 원칙을 지켜서 아무도 프로덕션 환경을 망치지 않도록 하겠습니다.

00:00:15.340 --> 00:00:20.280
에이저 AI 파운드리와 시멘틱 커널을 사용하여 자체 복구 기능이 있는 소규모 멀티 에이전트 시스템을 구축할 겁니다.

00:00:20.540 --> 00:00:21.780
실제 접점을 활용할 거예요.

00:00:21.780 --> 00:00:26.000
인튠, 엔트라, 그래프, 에이저 오토메이션, 로그 애널리틱스 등을 사용합니다.

00:00:26.160 --> 00:00:29.500
에이전트 하나와 멀티 에이전트 시스템을 직접 비교해보고, 12분과 3분을 비교해보겠습니다.

00:00:29.800 --> 00:00:31.740
유일한 피해자는 제 구동료 크레딧 뿐입니다.

00:00:31.940 --> 00:00:36.000
먼저, 팀즈는 빠르게 작동하는 반면, 에이전트 하나는 왜 멈추는지, 왜 에이전트 하나로는 부족한지 알아보겠습니다.

00:00:36.200 --> 00:00:38.500
단일 에이전트는 주유소에서 파는 맥북 칼과 같습니다.

00:00:38.900 --> 00:00:42.180
기술적으로는 도구가 많지만, 실제로는 첫 번째 나사만 조여도 휘어지죠.

00:00:42.180 --> 00:00:49.820
계획, 추론, 실행, 승인, 보고를 하나의 프롬프트에 모두 담으면 컨텍스트가 부족해지고 속도가 느려지며, 잘못된 부분에 대해 이상할이 많지 확신하게 됩니다.

00:00:49.980 --> 00:00:55.500
대부분의 사람들은 더 큰 모델, 더 큰 두뇌, 그러면 문제가 해결될 거라고 생각하지만, 실제 문제는 역할 혼란에 있습니다.

00:00:55.780 --> 00:01:03.060
한 명이 상담원이 변경 계획, 콜 그래프 작성, 문제 해결 스크립트 작성, 승인 요청, 결과 검증, 문서화까지 모두 처리하려고 합니다.

00:01:03.260 --> 00:01:07.580
마치 지친 인턴 한 명이 헬프 데스크, 변경 관리 게시판, 사후 분석까지 모두 담당하는 것과 같습니다.

00:01:07.840 --> 00:01:09.460
실제로는 다음과 같은 일이 벌어집니다.

00:01:09.460 --> 00:01:11.740
단일 상담원이 너무 많은 상태를 처리하려고 합니다.

00:01:11.900 --> 00:01:13.280
프롬프트는 장황해집니다.

00:01:13.460 --> 00:01:19.460
컨텍스트 창에는 로그, 정책, MDM 용어집의 절반이 채워져 중요한 부분이 잘리거나 누락된 세부 정보가 표시됩니다.

00:01:19.660 --> 00:01:24.040
지연 시간이 급증하고 토큰이 소모되며 제시도는 마치 청구서를 받는데 자비처럼 느껴집니다.

00:01:24.220 --> 00:01:28.300
이러한 문제를 해결하기 위해 다중 상담원, 역할, 경계, 병렬 처리가 필요합니다.

00:01:28.460 --> 00:01:32.980
계획 담당자는 의도와 제약 조건에 집중하고, 운영 담당자는 도구와 실행에 집중합니다.

00:01:33.200 --> 00:01:37.420
검토자는 가이드라인, 승인, 그리고 모든 것이 사실에 근거한 것인지에 집중합니다.

00:01:37.420 --> 00:01:41.720
각 에이전트는 필요한 최소한의 메모리로 간결하고 명료한 명령어 세트를 유지합니다.

00:01:41.880 --> 00:01:45.660
에이전트는 메시지, 도구 결과 또는 간단한 요약만 전달하며 인터넷 전체를 전송하지는 않습니다.

00:01:45.840 --> 00:01:47.660
이것이 기업 환경에서 중요한 이유는 무엇일까요?

00:01:47.840 --> 00:01:52.580
기업에서는 사람이 개입하는 게이트, 아이디 범위 지정작업, 제시도, 감사추적 기능을 갖춘 엔드투엔드 워크플로우가 필요합니다.

00:01:52.720 --> 00:01:54.620
이는 단일 스레드 채팅으로는 해결할 수 없는 문제입니다.

00:01:54.760 --> 00:01:55.860
팀워크가 필수적입니다.

00:01:56.080 --> 00:02:00.120
계획자, 실행자, 검토자 패턴은 모든 단계에 자동화된 검토자가 있어 위험과 재작업을 줄여줍니다.

00:02:00.120 --> 00:02:04.020
이 자동화된 검토자는 간단한 팀지 회의에 참여하는 소수 인원이 아닙니다.

00:02:04.200 --> 00:02:06.220
비용과 지연 시간도 절감할 수 있습니다.

00:02:06.460 --> 00:02:12.020
추출 및 분류에는 간단한 언어 모델을 사용하고, 계획 수립에 실제로 도움이 되는 경우에만 고급 추론 모델을 사용하십시오.

00:02:12.140 --> 00:02:14.120
사용자가 자는 동안 요약 작업을 일괄 처리하십시오.

00:02:14.820 --> 00:02:18.140
그러면 혼란이 줄어들고 결과가 빨라지며 비용도 절감할 수 있습니다.

00:02:18.380 --> 00:02:22.720
작은 일화 하나를 소개하자면, 모든 작업을 수행하는 보다나가 비밀 정보를 조작하려 했던 것을 본 적이 있습니다.

00:02:22.920 --> 00:02:26.880
키를 업데이트하고 앱 설정을 잊어버린 후 리소스를 삭제하여 문제를 해결했습니다.

00:02:26.880 --> 00:02:29.600
바로 그날 검토자 에이전트를 개발하게 되었습니다.

00:02:29.840 --> 00:02:32.440
멀티 에이전트 시스템의 기본 원리, 명확하고 간단하죠.

00:02:32.620 --> 00:02:35.420
자, 그렇다면 실제로 출시할 수 있는 멀티 에이전트 시스템이란 무엇일까요?

00:02:35.600 --> 00:02:37.820
하나의 거대한 두뇌가 아니라 디지털 팀을 생각해보세요.

00:02:38.080 --> 00:02:42.540
각 에이전트는 역할, 엄격한 지침 세트, 그리고 제한된 도구를 가지고 있습니다.

00:02:42.800 --> 00:02:49.780
계획 담당자는 목표, 제약 조건, 환경을 이해하고 운영자가 실행할 수 있는 도구 호출을 포함한 계획을 수립합니다.

00:02:49.780 --> 00:02:57.440
운영자는 도구, 그래프, 로직 앱, 함수, 에이저 오토메이션, 넌북 등을 호출하고 구조화된 결과를 반환합니다.

00:02:57.620 --> 00:03:04.260
검토 담당자는 위험한 상황이 발생하기 전에 근거, 규정 준수 범위, 승인 및 안전 출력을 확인합니다.

00:03:05.020 --> 00:03:09.580
메신저 담당자는 감사 추적을 위한 알림, 승인 및 요약을 처리합니다.

00:03:09.580 --> 00:03:15.480
이들은 어른들이 해야 하는 방식대로 간결하고 명확하며 필요한 정보만 메시지와 공유 컨텍스트를 통해 소통합니다.

00:03:15.680 --> 00:03:21.180
작업이 이전 결과에 따라 달라지는 경우 순차적으로 하위 작업이 안전하게 분산될 수 있는 경우 병렬로 처리합니다.

00:03:21.360 --> 00:03:26.260
50페이지의 짜리 정책 문서를 보내는 대신 관련 코드 조각, 장치 아이디, 그리고 변경 예정 사항만 보내세요.

00:03:26.420 --> 00:03:27.900
도구는 핵심적인 역할을 합니다.

00:03:27.900 --> 00:03:38.480
마이크로소프트 그래프용 네스트 API, 에이저 AI 검색을 통한 선별된 지식 검색 도구, 코드 조각용 코드 인터프리터, 오케스트레이션된 시퀀스용 로직앱, 연결도구 역할을 하는 함수, 반복 가능한 장치 작업을 위한 에이저 오토메이션 등을 활용하세요.

00:03:38.640 --> 00:03:43.100
운영자가 임의로 테넌트를 삭제하지 못하도록 도구 입력 값을 스키마로 구조화하세요.

00:03:43.340 --> 00:03:45.060
메모리는 마법이 아니라 예산입니다.

00:03:45.320 --> 00:03:47.120
에이전트별 메모리 사용량을 최소화하세요.

00:03:47.120 --> 00:03:51.420
외부 상태 저장소, 검색 인덱스, 벡터 저장소 또는 스레드 메타데이터 용 소형 상태 저장소를 사용하세요.

00:03:51.540 --> 00:03:53.200
컨텍스트 창을 간결하게 유지하세요.

00:03:53.380 --> 00:03:55.680
다음 결정에 필요하지 않은 정보는 기록하지 마세요.

00:03:55.900 --> 00:03:58.360
시멘틱 커널은 계획과 실행을 효과적으로 지원합니다.

00:03:58.580 --> 00:04:02.360
계획 담당자는 작업을 위임하고, 운영자는 함수 카탈로그를 통해 적합한 도구를 선택합니다.

00:04:02.560 --> 00:04:06.280
검토자는 평가 프롬프트와 콘텐츠 안전성을 활용하여 결과물을 검토합니다.

00:04:06.520 --> 00:04:09.620
검토자가 범위 위험을 지적하면 계획 담당자가 수정합니다.

00:04:09.620 --> 00:04:14.480
이 루프를 이해하면 800단어짜리 프롬프트를 작성하는 대신 명확한 역할을 구축하기 시작합니다.

00:04:14.660 --> 00:04:16.380
안전경계는 파협할 수 없습니다.

00:04:16.700 --> 00:04:19.660
관리되는 아이디를 사용하는 아이디 범위 도구 호출.

00:04:19.860 --> 00:04:22.180
에이전트 권한은 읽기와 관리로 분할됩니다.

00:04:22.360 --> 00:04:24.880
파괴적인 작업에 대한 권한 상승은 PM에게 부여됩니다.

00:04:25.100 --> 00:04:27.060
모든 도구 호출은 로그 분석에 기록됩니다.

00:04:27.260 --> 00:04:29.520
입력과 출력 모드에 콘텐츠 안전이 보장됩니다.

00:04:29.700 --> 00:04:33.300
탈옥 및 지식소스로부터의 간접 프롬프트 주입으로부터 프롬프트를 보호합니다.

00:04:33.520 --> 00:04:37.180
비유하자면 연구원, 분석가, 운영자, QA 담당자입니다.

00:04:37.180 --> 00:04:39.160
각자 자신의 역할에 대한 책임이 있습니다.

00:04:39.380 --> 00:04:41.320
운영자는 자신의 변경사항을 승인하지 않습니다.

00:04:41.520 --> 00:04:43.260
분석가는 프로덕션 환경을 건드리지 않습니다.

00:04:43.420 --> 00:04:45.500
QA 담당자는 자신이 승인하는 코드를 작성하지 않습니다.

00:04:45.680 --> 00:04:47.540
간단하고 지루하지 않으며 안전합니다.

00:04:47.720 --> 00:04:50.520
에이저 AI 파운드리와 시멘틱 커널을 함께 사용해야 하는 이유는 무엇일까요?

00:04:50.680 --> 00:04:57.860
파운드리는 에이전트 오케스트레이션, 모델 선택, 지식기반 구축, 도구 연결, 콘텐츠 안전, 추적, 평가 및 거버넌스를 한 곳에서 제공합니다.

00:04:58.040 --> 00:05:03.500
시멘틱 커널은 코드 내에서 플래너, 스킬, 파이프, 라인, 제시도 및 취소 기능을 제공합니다.

00:05:03.500 --> 00:05:10.600
각 역할에 맞는 모델들을 조합하고, 데이터 추출에는 SLM을, 계획 수립에는 GPT4 클래스를, 요약에는 배치 처리를 활용하세요.

00:05:10.800 --> 00:05:14.640
프롬프트는 간결하게, 작업 범위는 좁게, 주말은 자유롭게 활용하세요.

00:05:14.820 --> 00:05:16.100
이제 실제로 구현해보겠습니다.

00:05:16.460 --> 00:05:19.980
에이저 AI 파운드리는 어떻게 멀티 에이전트 워크플로우를 지원하는지 알아보겠습니다.

00:05:20.240 --> 00:05:24.220
에이저 AI 파운드리는 단순한 포털을 넘어 실제 운영 환경처럼 작동합니다.

00:05:24.440 --> 00:05:31.180
파운드리를 사용하면 에이전트를 정의하고, 모델을 연결하고, 지식을 추가하고, 액션을 연결하고, 모든 것을 모니터링할 수 있습니다.

00:05:31.180 --> 00:05:34.140
마치 덕트테이프 없이도 완벽한 오케스트레이션을 구현하는 것과 같습니다.

00:05:34.400 --> 00:05:36.220
먼저 에이전트 정의부터 시작해보세요.

00:05:36.480 --> 00:05:41.240
파운드리에서는 각 에이전트에 대한 명확한 역할 지침이 제공되며, 단순한 선언문이 아닙니다.

00:05:41.420 --> 00:05:43.440
데포는 실제 모델을 구축하는 단계입니다.

00:05:43.660 --> 00:05:47.660
계획 수립에는 GPT4 클래스를, 데이터 추출에는 P클래스 SLM을 조합하여 사용할 수 있습니다.

00:05:47.860 --> 00:05:52.700
지식은 에이저 AI 검색 인덱스, 업로드된 파일, 웹컨텍스트가 필요할 때는 빈 검색 결과를 활용할 수 있습니다.

00:05:52.700 --> 00:06:00.640
액션은 오픈 API 도구, 로직 앱, 함수, 그래프, 에이저 오토메이션 넌북, 또는 빠른 연산 및 구문 분석을 위한 코드 인터프리터를 사용할 수 있습니다.

00:06:00.820 --> 00:06:06.340
연결된 에이전트, 네, 에이전트는 역할을 명확하게 유지하는 한 다른 에이전트를 도구처럼 다룰 수 있습니다.

00:06:06.580 --> 00:06:09.880
이는 시멘틱 커널이 동일한 생태계에 연결되기 때문에 중요합니다.

00:06:10.080 --> 00:06:14.640
코드에서는 플래너를 구축하고, 스킬을 정의하고, 함수 카탈로그에 도구를 등록합니다.

00:06:14.840 --> 00:06:20.680
플래너, 운영자, 검토자 루프를 구성하고, 파운드리가 스레드, 기록 및 안전장치를 처리하도록 합니다.

00:06:20.680 --> 00:06:24.420
프롬프트는 간결하게 유지하고, 스키마가 있는 도구의 핵심 작업을 맡기세요.

00:06:24.560 --> 00:06:29.020
번역, 환상 감소, 객체 지향 오류 감소, 주말 시간 증가, 모델 선택은 중요합니다.

00:06:29.180 --> 00:06:33.480
파운드리는 모델 엔드포인트를 통해 추론을 추상화하므로 전체 앱을 다시 작성하지 않고도 모델을 교체할 수 있습니다.

00:06:33.660 --> 00:06:35.040
두 가지 일반적인 방식이 있습니다.

00:06:35.300 --> 00:06:38.140
프리미엄 모델용 서버리스 엔드포인트와 빠른 방법을 위한 엔드포인트입니다.

00:06:38.320 --> 00:06:42.320
토큰 단위로 비용을 지불하고 필요에 따라 확장할 수 있으며, 2018년처럼 GPU를 관리할 필요가 없습니다.

00:06:42.320 --> 00:06:45.860
테넌트 경계에 고정하려는 특정 오픈 모델에 대한 관리형 컴퓨팅도 있습니다.

00:06:46.080 --> 00:06:50.320
가동시간 단위로 비용을 지불하고 형태를 제어할 수 있지만 배포인프라는 마이크로소프트에서 관리합니다.

00:06:50.500 --> 00:06:52.420
역할별로 모델을 혼합하여 사용할 수 있습니다.

00:06:52.660 --> 00:06:58.580
추론에는 gpt4 또는 4.1 미니 기반의 플래너를 사용하고, 추출 및 파라미터 조정에 탁월한 소형 모델 기반의 오퍼레이터를 활용하세요.

00:06:58.780 --> 00:07:02.780
긴 요약 정보를 밤새 일괄 처리하여 아침에 담당자가 보기 좋은 보고서를 받아볼 수 있도록 하세요.

00:07:02.780 --> 00:07:09.860
모델이 더 이상 사용되지 않거나 딥식 또는 남아 변형 모델을 사용해보고 싶을 때, 파운드리 위추론 api를 통해 실험하는 동안에도 코드를 안정적으로 유지할 수 있습니다.

00:07:10.040 --> 00:07:12.660
오퍼레이터의 역량은 도구와 액션에서 빛을 발합니다.

00:07:12.900 --> 00:07:16.480
에이전트에게 모든 권한을 넘겨주지 않고도 실질적인 권한을 부여할 수 있는 곳입니다.

00:07:16.660 --> 00:07:19.680
스웨거를 사용하여 내부 서비스를 위한 개방형 api 도구를 활용하세요.

00:07:19.860 --> 00:07:21.380
계약 내용을 엄격하게 유지하세요.

00:07:21.580 --> 00:07:24.600
스키마에서 장치를 문자열로 지정했다면 반드시 장치 아이디여야 합니다.

00:07:24.800 --> 00:07:27.140
승인 흐름 및 휴먼 게이트에는 로직 앱을 사용하세요.

00:07:27.140 --> 00:07:31.140
검토자가 변경 사항을 승인자에게 전달하고 승인 시 실행을 재개하도록 하세요.

00:07:31.280 --> 00:07:34.500
에이저 펑션스를 사용하여 연결 코드 및 적절한 변환 작업을 처리하세요.

00:07:34.680 --> 00:07:39.900
인튠, 엔트라 및 사용자 장치 조건부 액세스 작업을 위한 작고 테스트 가능한 버전 관리 그래프 api를 활용하세요.

00:07:40.080 --> 00:07:43.920
모니터링 에이전트에게는 읽기 권한을, 복구 담당자에게는 관리 권한을 부여하세요.

00:07:44.120 --> 00:07:47.400
에이저 오토메이션을 사용하여 장치 스크립트 및 실행 설명서를 작성하세요.

00:07:47.620 --> 00:07:49.980
잠긴 서랍 속 날카로운 물건처럼 취급하세요.

00:07:50.240 --> 00:07:51.860
오직 전문가만이 열 수 있습니다.

00:07:52.180 --> 00:07:54.260
접지처럼 엄선된 정보만 관리하세요.

00:07:54.260 --> 00:07:57.780
하이브리드 랭킹 및 시멘틱 재랭킹 기능을 갖춘 네이저 AI 검색을 활용하세요.

00:07:57.940 --> 00:07:59.460
도메인별로 지식을 공유하세요.

00:07:59.660 --> 00:08:02.160
온 보딩 SOP와 별도로 인튠 정책을 관리하세요.

00:08:02.360 --> 00:08:04.280
모든 것을 한꺼번에 배포하지 않도록 하세요.

00:08:04.480 --> 00:08:07.060
운영자는 백과 사전이 아닌 핵심 정보만 전달해야 합니다.

00:08:07.240 --> 00:08:12.400
데이터 청크 크기를 적절히 조정하고, 출처를 저장하고, 프로덕션 환경에 배포하기 전에 검토자가 타당성을 확인하도록 하세요.

00:08:12.580 --> 00:08:14.000
안전은 선택 사항이 아닙니다.

00:08:14.000 --> 00:08:20.620
파운드리는 입력 및 출력에 대한 콘텐츠 안전 필터, 탈옥 및 간접 주입에 대한 프롬프트 보호 기능, 보호자료 검사 기능을 기본적으로 제공합니다.

00:08:20.780 --> 00:08:25.900
잘못된 입력이나 출력으로 인한 PR 재앙에 대한 비용을 지불하지 않도록 모델 전후의 안전검사를 실행하세요.

00:08:26.080 --> 00:08:31.520
에이전트 별 관리 아이디, 최소 권한 복구, 파괴적인 도구에 대한 임시 권한 상승을 위한 PM 기능을 함께 활용하세요.

00:08:31.720 --> 00:08:34.440
모든 도구 호출은 추적되고, 모든 승인은 로그에 기록됩니다.

00:08:34.620 --> 00:08:37.900
누군가, 누가 무엇을 실행했나요? 라고 물으면 아울록을 열 필요가 없습니다.

00:08:38.180 --> 00:08:39.920
로그 분석 기능이 이미 모든 것을 알고 있습니다.

00:08:39.920 --> 00:08:41.880
관찰 가능성은 성숙한 단계입니다.

00:08:42.040 --> 00:08:44.280
실행 기록을 확인하려면 추적 기능을 활성화하세요.

00:08:44.460 --> 00:08:49.600
어떤 에이전트가 어떤 도구를 어떤 매개 변수로 호출했는지, 지연 시간은 얼마였는지, 그리고 어떤 결과가 반환되었는지 확인할 수 있습니다.

00:08:49.800 --> 00:08:58.260
성능 패턴을 파악하기 위해 애플리케이션 인사이트를 연결하고, 감사를 위해 앱 로그를 활용하며, 사용자가 문제를 발견하기 전에 관련성, 타당성, 유창성 저하를 감지하기 위해 CI의 평가를 배포하세요.

00:08:58.420 --> 00:09:03.320
타당성이 떨어지면 검토자가 플래그를 지정하고, 플래너는 검색 커리를 좁히고, 운영자는 다시 시도합니다.

00:09:03.580 --> 00:09:04.900
사람이 당황할 필요가 없습니다.

00:09:04.900 --> 00:09:07.380
배포 기본 요소를 통해 깔끔하게 관리할 수 있습니다.

00:09:07.540 --> 00:09:10.480
팀 범위 할당량 및 정책 기준선에는 파운드리 프로젝트를 사용하세요.

00:09:10.640 --> 00:09:17.440
도구 서비스 앞에 에이저 API 매니지먼트를 배치하여 버전 관리, 스로틀링, 회로 차단기 구현, PTO와 중량제 추론 간의 라우팅을 관리하세요.

00:09:17.620 --> 00:09:21.540
데이터 상주 또는 규정 준수를 통해 보안을 강화하는 경우 비공개 엔드포인트를 사용하세요.

00:09:21.740 --> 00:09:24.820
단순히 목표가 아닌 실제 사용자에게 적합한 리전을 선택하세요.

00:09:25.060 --> 00:09:27.260
그리고 시멘틱 커널이 모든 것을 완성합니다.

00:09:27.260 --> 00:09:33.540
워크플로우를 코드로 정의하면 플래너가 이를 분해하고, 운영자는 기능 카탈로그와 가용성을 기반으로 도구를 선택합니다.

00:09:33.740 --> 00:09:43.840
검토자는 평가 프롬프트와 콘텐츠 안전 결과를 통해 검사를 시행하고, 외부 API 가유지 보수를 위해 다운된 것처럼 가장할 경우 배고프 및 취소 토큰을 사용하여 재시도할 수 있습니다.

00:09:44.120 --> 00:09:47.740
SK는 실행 두뇌를 제공하고, 파운드리는 운영 환경을 제공합니다.

00:09:47.960 --> 00:09:50.440
이 둘을 결합하면 실용적인 패턴이 만들어집니다.

00:09:50.440 --> 00:10:03.160
파운드리에서 엄격한 지침과 아이디를 사용하여 에이전트를 정의하고, SK에서 역할을 오케스트레이션하고, 선별된 검색으로 기반을 다지고, 개방형 API, 로직 앱, 함수, 자동화를 통해 작업을 연결하고, 추론 전후의 안전성을 강화하고 모든 것을 관찰합니다.

00:10:03.280 --> 00:10:05.080
최고의 의미에서 지루할 수 있습니다.

00:10:05.320 --> 00:10:10.680
안전벨트 착용이나 인터넷의 기본 키라는 이름의 전역 관리자 권한을 부여하지 않는 것과 같습니다.

00:10:10.680 --> 00:10:20.440
데모 시나리오 1. 장치 정리. CSI 인튠 유령 장치 부서. 관리됨, 사용 중지됨, 그리고 비활성화됨으로 동시에 표시되는 장치들을 아시나요?

00:10:20.680 --> 00:10:22.780
CSI 인튠 에오신 것을 환영합니다.

00:10:23.000 --> 00:10:29.880
저희의 임무는 오래되었거나, 중복되었거나, 등록되지 않은 하드웨어를 찾아 스인을 통해 안전하게 수정하여 아무도 법적 조치를 취하지 않도록 하는 것입니다.

00:10:30.060 --> 00:10:37.400
에이전트, 모니터링 담당자, 퀄이 담당자, 마이크로소프트 그래프 및 로그 분석 담당자가 장치 상태를 분류하고 이상 징후를 표시합니다.

00:10:37.400 --> 00:10:41.940
복구 담당자는 인튠 및 에이저 자동화를 호출하여 장치를 격리하거나 폐기합니다.

00:10:42.120 --> 00:10:48.000
감사 담당자는 모든 것을 기록하고 담당자에게 알림을 보내고 규정 준수를 위한 사후보고서를 작성합니다.

00:10:48.200 --> 00:10:49.520
전체 흐름은 다음과 같습니다.

00:10:49.880 --> 00:10:56.660
모니터링 담당자는 그래프 장치 기록에서 마지막 체크인, 규정 준수 상태, 등록 유형, 기본 사용자 및 폐기 플래그를 가져옵니다.

00:10:56.820 --> 00:11:02.600
또한 로그 분석 신호, 디펜더 하트비트, 업데이트 규정 준수 및 인튠 관리 확장 이벤트도 수집합니다.

00:11:02.860 --> 00:11:05.880
이러한 정보를 장치별로 간략하고 구조화된 레코드로 통합합니다.

00:11:05.880 --> 00:11:09.880
마지막 접속 시간, UTC, 등록 여부, 규정 준수 여부, 중복 후보, 위험 신호 등이 포함됩니다.

00:11:10.000 --> 00:11:11.560
장황한 설명 없이 필드만으로 구성됩니다.

00:11:11.720 --> 00:11:13.680
이제 분석 담당자가 실제 담당자에게 작업을 인계합니다.

00:11:13.840 --> 00:11:17.680
모니터링 담당자는 제한된 분류, 오래됨, 중복, 하트비트 없음 또는 정상, 를 보냅니다.

00:11:17.840 --> 00:11:19.280
검토자는 근거를 확인합니다.

00:11:19.500 --> 00:11:22.480
이러한 필드가 실제로 그래프 및 로그 분석에서 가져온 것인지 확인합니다.

00:11:22.660 --> 00:11:27.720
콘텐츠 안전 기능은 사전 모델링을 실행하여 업로드된 파일이나 웹링크에서 발생하는 프롬프트 주입을 차단합니다.

00:11:27.940 --> 00:11:31.020
분류가 통과되면 복구 담당자가 조치를 준비합니다.

00:11:31.020 --> 00:11:34.580
1단계는 소프트 복구, 태그 지정 및 격리입니다.

00:11:34.860 --> 00:11:40.500
폐기 대상 장치 범주에 후보를 적용하고 정책 확산을 유발하는 동적 그룹 바인딩을 제거하며

00:11:40.500 --> 00:11:45.040
필요한 경우 액세스를 차단하는 에이저 AD 격리 그룹으로 장치를 이동합니다.

00:11:45.260 --> 00:11:46.960
아직 삭제는 수행하지 않습니다.

00:11:47.380 --> 00:11:49.220
승인은 로직 앱에서 이루어집니다.

00:11:49.420 --> 00:11:54.840
검토자는 간략한 계획, 장치 아이디, 사유, 제한된 조치, 롤백을 포함합니다.

00:11:55.080 --> 00:12:00.300
승인자는 그래프 커리 및 로그 분석 KQL에 대한 참조가 포함된 요약을 팀즈에서 확인합니다.

00:12:00.300 --> 00:12:03.040
센서 토큰이 승인되면 복구 도구가 폐기를 실행하거나

00:12:03.040 --> 00:12:04.980
정당한 경우 데이터를 삭제하거나

00:12:04.980 --> 00:12:07.040
최신 하트비트를 가진 장치를 유지하고

00:12:07.040 --> 00:12:09.600
중복된 데이터를 연결 해제하여 중복을 정리합니다.

00:12:09.780 --> 00:12:12.300
관리형 아이디를 사용하여 모든 작업을 안전하게 처리합니다.

00:12:12.500 --> 00:12:14.940
모니터링 도구는 장치에 대한 모든 읽기 권한으로 실행됩니다.

00:12:15.100 --> 00:12:19.520
복구 도구는 장치에 대한 모든 읽기, 쓰기 권한과 필요한 인튠 권한만 있는 별도의 아이디를 사용합니다.

00:12:19.700 --> 00:12:21.920
삭제는 팀, 프로젝트 관리 모니터링을 통해 이루어집니다.

00:12:21.920 --> 00:12:24.480
복구 도구 에이전트는 자체적으로 권한을 상승시킬 수 없습니다.

00:12:24.700 --> 00:12:27.560
권한 상승이 요청되면 로직 앱은 사람의 쓰인을 필요로 하며

00:12:27.560 --> 00:12:29.180
임시 권한 만료 시간이 시작됩니다.

00:12:29.360 --> 00:12:31.480
관찰 가능성은 본격적인 관리 단계입니다.

00:12:31.700 --> 00:12:33.080
모든 도구 호출은 추적됩니다.

00:12:33.300 --> 00:12:36.340
누가 무엇을 호출했는지, 매개 변수, 지연 시간, 응답 시간 등을 기록합니다.

00:12:36.500 --> 00:12:37.980
감사자는 상관관계 아이디와 함께

00:12:37.980 --> 00:12:39.540
이벤트 기록을 분석 로그에 기록하여

00:12:39.540 --> 00:12:41.100
슬랙에서 데이터를 뒤져보지 않고도

00:12:41.100 --> 00:12:42.600
사건 현장을 재구성할 수 있도록 합니다.

00:12:42.600 --> 00:12:46.680
또한 변경 후 타당성, 관련성, 유창성을 평가하는 단계를 거칩니다.

00:12:46.880 --> 00:12:50.040
타당성이 떨어지면 검토자는 추가적인 파괴적인 작업을 차단하고

00:12:50.040 --> 00:12:53.340
계획을 기획자에게 되돌려 검색 범위를 좁히거나 개선하도록 합니다.

00:12:53.560 --> 00:12:55.460
모델은 위도적으로 혼합하여 사용합니다.

00:12:55.660 --> 00:12:58.820
분류에는 비용과 지연 시간을 낮추기 위해 소규모 모델을 사용합니다.

00:12:59.020 --> 00:13:00.620
오토파일럿 이 한 장치의 이름을 변경했는데

00:13:00.620 --> 00:13:02.920
에이저 AD가 두 장치를 동일한 장치로 인식하는 경우와

00:13:02.920 --> 00:13:05.900
같은 예외적인 상황에서는 GPT-4 미니를 사용하여 추론 경로를 생성합니다.

00:13:06.080 --> 00:13:07.280
요약은 일괄 처리됩니다.

00:13:07.280 --> 00:13:10.740
오후 2시에 쉐익스피어 수준의 장황한 보고서를 작성할 필요는 없으니까요.

00:13:10.880 --> 00:13:14.200
지난주 단일 에이전트 테스트에서 동일한 동적 그룹의 모든 항목을 폐기하여

00:13:14.200 --> 00:13:15.660
오래된 장치를 수정하려고 했습니다.

00:13:15.940 --> 00:13:18.400
다중 에이전트 흐름의 검토자는 범위 불일치를 발견하고

00:13:18.400 --> 00:13:20.560
장치 수준의 확인을 요청한 후 작업을 중단했습니다.

00:13:20.840 --> 00:13:23.520
이것이 바로 계획, 실행, 검토 단계를 분리하는 이유입니다.

00:13:23.700 --> 00:13:26.700
결과적으로 유령 장치로 인한 규정 준수 문제가 해결됩니다.

00:13:26.900 --> 00:13:29.040
라이선스 낭비를 줄이고 오탄을 감소시키며

00:13:29.040 --> 00:13:32.920
실패한 장치를 폐기하는 것이 왜 일상인지 경영진에게 설명할 필요가 없어집니다.

00:13:37.280 --> 00:13:40.800
두번째 데모 시나리오는 제로터치온 보딩입니다.

00:13:40.980 --> 00:13:42.380
말 그대로 제로터치입니다.

00:13:42.600 --> 00:13:44.760
사용자는 아무런 접촉 없이 에이전트가 배정될 때까지

00:13:44.760 --> 00:13:46.520
엔지니어링팀은 500번의 접촉을 거치게 됩니다.

00:13:46.720 --> 00:13:50.440
목표는 인사 담당자의 이벤트부터 사용자가 장치를 바로 사용할 수 있도록 만드는 것입니다.

00:13:50.620 --> 00:13:53.400
인사 담당자가 사용자의 성을 3가지 다른 방식으로 표기하더라도 원활하고

00:13:53.400 --> 00:13:55.080
관리되며 되돌릴 수 있도록 설계합니다.

00:13:55.220 --> 00:13:56.400
팀 구성은 다음과 같습니다.

00:13:56.780 --> 00:14:01.780
접수 담당자는 인사 웹북을 수신하고 페이로드를 표준화하고 필수 필드를 검증합니다.

00:14:01.780 --> 00:14:04.200
프로비저 너는 엔트라의 사용자를 생성하고

00:14:04.200 --> 00:14:07.800
그룹과 라이선스를 할당하고 오토파일럿 프로필을 등록합니다.

00:14:07.960 --> 00:14:12.940
검증자는 새 노트북을 제공하기 전에 정책 준수 및 조건부 액세스 상태를 확인합니다.

00:14:13.140 --> 00:14:17.860
컨시어지는 환영팩, 시어포인트 링크, 그리고 첫날 체크리스트를 전송합니다.

00:14:18.080 --> 00:14:19.180
이제 흐름이 시작됩니다.

00:14:19.400 --> 00:14:24.020
접수 담당자는 인사 담당자의 페이로드, 이름, 시작일, 역할, 부서, 관리자, 지역을 가져옵니다.

00:14:24.180 --> 00:14:26.260
소형 모델은 데이터를 추출하고 정교화합니다.

00:14:26.260 --> 00:14:30.340
표준 필드에 맵핑하고 2099년 시작일과 같은 비정상적인 값을 잡아냅니다.

00:14:30.500 --> 00:14:34.800
필수 필드가 누락된 경우 로직 앱을 통해 구조화된 오류 메시지를 인사팀에 전달합니다.

00:14:34.980 --> 00:14:38.620
프로비저 너는 사용자 권한에 따라 관리되는 아이디를 사용하여 그래프를 호출합니다.

00:14:38.840 --> 00:14:42.480
엔트라 사용자를 생성하고 사용 위치를 설정한 후 기본 그룹을 적용합니다.

00:14:42.680 --> 00:14:45.320
그런 다음 역할과 지역에 따라 라이선스 할당을 구성합니다.

00:14:45.540 --> 00:14:47.160
이 과정에서 논리적 추론이 중요합니다.

00:14:47.360 --> 00:14:48.920
이 사용자는 E5 보안 라이선스가 필요한가요?

00:14:49.140 --> 00:14:50.620
아니면 비즈니스 프리미엄 라이선스가 필요한가요?

00:14:50.620 --> 00:14:53.660
정책을 데이터에 인코딩하고 모델이 허용된 번들 중에서 선택하도록 합니다.

00:14:53.820 --> 00:14:56.660
모델이 임의로 라이선스를 생성할 수 없으며 엄격한 메뉴가 제공됩니다.

00:14:56.820 --> 00:14:58.360
그 다음은 자동 조종 단계입니다.

00:14:58.540 --> 00:15:04.280
프로비저 너는 이미 보유하고 있는 하드웨어 해시를 등록하거나 사용자 그룹에 연결된 적시 프로필을 준비합니다.

00:15:04.500 --> 00:15:08.120
기준 정책에 따라 장치 그룹의 태그를 지정하면 검증기가 작동합니다.

00:15:08.340 --> 00:15:10.740
검증기는 그래프와 디펜더의 규정 준수 신호를 커리하고

00:15:10.740 --> 00:15:13.620
조건부 액세스가 첫 로그인에 영향을 미치지 않는지 확인하고

00:15:13.620 --> 00:15:16.220
올바른 장치 구성 정책이 적용되는지 검사합니다.

00:15:16.420 --> 00:15:19.400
조건부 액세스로 인해 신규 직원이 입사 첫날부터 접근이 차단될 경우

00:15:19.400 --> 00:15:23.100
검증자는 기한이 정해진 예외 사항과 그 이유를 명시하여 승인 요청을 보냅니다.

00:15:23.280 --> 00:15:25.480
컨시어즈는 인적 자원 관련 업무를 처리합니다.

00:15:25.480 --> 00:15:31.920
신규 직원의 UPN, 장치 할당 상태, 시어포인트 시작 키트 링크가 포함된 팀즈 메시지를 관리자에게 전송합니다.

00:15:32.080 --> 00:15:37.640
또한 신규 직원에게 입사 첫날 업무, MFA 설정 안내, IT 포털 위치 등을 이메일로 발송합니다.

00:15:37.840 --> 00:15:40.500
이메일에는 내부 IP 주소 범위를 포함하지 않습니다.

00:15:40.740 --> 00:15:43.500
콘텐츠 안전성 검사는 유출 여부와 어조를 검사합니다.

00:15:43.740 --> 00:15:45.760
거버넌스 역시 동일한 보안 원칙을 따릅니다.

00:15:46.000 --> 00:15:48.900
프로비저 너의 관리 아이디는 라이선스 권한은 있지만 삭제 권한은 없습니다.

00:15:49.200 --> 00:15:51.960
인테이크 담당자는 프로비저닝 권한이 없고 유효성 검사만 수행합니다.

00:15:51.960 --> 00:15:55.540
PM은 사용자를 민감한 그룹에 추가하는 것과 같은 고위험 작업을 승인합니다.

00:15:55.720 --> 00:15:58.320
모든 작업은 앱 인사이트와 로그 분석에 기록됩니다.

00:15:58.540 --> 00:16:03.600
HR에서 수정된 페이로드를 전송하면 플래너가 변경 사항을 재계산하고 운영자는 변경된 내용만 업데이트합니다.

00:16:03.820 --> 00:16:05.640
그룹 멤버십이 자주 변경되는 일은 없습니다.

00:16:05.960 --> 00:16:08.280
관찰 가능성을 통해 주요 마일스톤을 확인할 수 있습니다.

00:16:08.540 --> 00:16:13.960
HR 데이터 수집, 엔트라 생성, 나이선스 할당, 자동 프로필 생성, 규정 준수 판정 알림 전송,

00:16:14.120 --> 00:16:18.280
SLA 지표를 제공하며 일시적인 그래프 오류 발생 시 백오프 기능을 통해 자동 제시도합니다.

00:16:18.280 --> 00:16:24.140
HR 시스템에 오류가 발생하더라도 스레드가 종료되지 않고 일시 중지, 로그 기록 후 오류 수정 후 재개됩니다.

00:16:24.300 --> 00:16:30.680
실제 채용 전에 관련성 및 타당성 관련 문제를 조기에 발견하기 위해 합성운 보딩 페이로드를 사용하여 CI 환경에서 평가를 실행합니다.

00:16:30.840 --> 00:16:32.800
모델 조합을 통해 비용 효율성을 유지합니다.

00:16:33.040 --> 00:16:35.440
SLM을 사용하여 데이터 추출 및 정규화를 수행합니다.

00:16:35.620 --> 00:16:38.020
정책 선택 결정에 대해서만 추론 과정을 거칩니다.

00:16:38.320 --> 00:16:40.780
요약 및 환영 이메일은 가능한 경우 일괄 처리합니다.

00:16:41.040 --> 00:16:45.540
목표는 감사 추적에서 사람이 직접 확인할 수 있는 명확성을 유지하면서 지연 시간을 최소화하는 것입니다.

00:16:45.540 --> 00:16:52.460
간단한 사례, 단일 상담원 온 보딩 시스템에서 사용자가 계약직 직원이라는 제목 때문에 모든 직원 및 계약직 그룹에 추가하려고 했습니다.

00:16:52.460 --> 00:16:59.100
다중 상담원 시스템이 유효성 검사기에서 상호 배타성 규칙을 감지하고 사람의 판단을 요청하여 조건부 액세스 관련 오류를 방지했습니다.

00:16:59.300 --> 00:17:02.080
결과적으로 사용자는 아무런 조작 없이 온 보딩을 경험할 수 있었습니다.

00:17:02.240 --> 00:17:08.520
하나의 스레드, 4명이 에이전트, 깔끔한 승인 절차, 그리고 데모 시연에 대한 부담 없이 CISO에게 보여줄 수 있는 완벽한 문서 기록까지.

00:17:08.680 --> 00:17:14.240
인사팀에서 불가피하게 시작일을 변경하더라도 시스템은 라이선스 예산을 낭비하지 않고 자동으로 재계산합니다.

00:17:14.440 --> 00:17:17.300
세 번째 데모 시나리오는 자동화된 보안 강화입니다.

00:17:17.300 --> 00:17:19.460
비트로커는 활성화되어 있어야 합니다.

00:17:19.680 --> 00:17:21.300
보안 설정 변경은 잡초와 같습니다.

00:17:21.660 --> 00:17:25.440
3개를 뽑으면 5개가 소산하고 그 중 하나는 악의적으로 비트로커를 비활성화합니다.

00:17:25.660 --> 00:17:30.820
우리의 목표는 구성 변경을 지속적으로 감지하고 변호사도 인정할 만한 수준의 보안 조치를 통해 안전하게 해결하는 것입니다.

00:17:31.000 --> 00:17:33.960
캐스트 드리프트 디텍터는 그래프와 디펜더를 커리합니다.

00:17:34.200 --> 00:17:39.000
시큐어 스코어는 인튠 규정 준수 및 장치 구성 기준선을 가져와 변경 차이를 계산합니다.

00:17:39.220 --> 00:17:44.540
픽서는 인튠 정책 변경, 비트로커 설정 및 윈도우즈 업데이트 링을 푸시합니다.

00:17:44.540 --> 00:17:49.780
정책이 충분히 적용되지 않을 경우 에이저 오토메이션을 통해 장치 스크립트를 실행합니다.

00:17:49.940 --> 00:17:56.600
리뷰어는 가이드라인을 준수하고 변경 범위를 지정하고 근거검사를 실행하고 위험한 단계에 대한 사람의 쓰인을 확보합니다.

00:17:56.840 --> 00:18:01.580
메신저는 팀즈 또는 이메일을 통해 담당자에게 간략한 계획과 확인사항을 전달합니다.

00:18:01.800 --> 00:18:05.720
플로우의 드리프트 디텍터는 예약된 일정과 필요에 따라 실행됩니다.

00:18:05.980 --> 00:18:13.540
그래프를 통해 장치 규정 준수, 비트로커 상태, TPM 상태, OS 버전, 업데이트 링 및 정책 할당 정보를 가져옵니다.

00:18:13.540 --> 00:18:19.280
각 장치를 구조화된 데이터, 빕스 문서가 아닌 인 골든 프로파일과 비교합니다.

00:18:19.480 --> 00:18:26.680
비트로커 미적용, 최악한 암호화 방식, 정책 미적용, 보안 부팅 비활성화, 업데이트 링 범위 초과 등의 문제를 태그로 표시합니다.

00:18:26.880 --> 00:18:30.020
플래너 단계에서는 장치 그룹별 최소 계획을 제안합니다.

00:18:30.240 --> 00:18:34.440
비트로커 위 경우 장치가 비트로커를 지원하는 경우 인튠 비트로커 정책을 사용합니다.

00:18:34.660 --> 00:18:40.940
정책이 이미 적용되었지만 상태가 비활성화된 경우 보호 기능을 다시 활성화하고 키를 에이저 AD에 에스크로 하는 자동화 스크립트를 제안합니다.

00:18:40.940 --> 00:18:46.560
업데이트 드리프트의 경우 패치 적용보다는 장치를 단계별 업데이트 링으로 이동하는 것을 제안합니다.

00:18:46.760 --> 00:18:51.760
조건부 액세스 문제의 경우 필요한 근거를 제시하여 기한이 정해진 예외를 제안합니다.

00:18:52.000 --> 00:18:54.180
검토자는 제안의 타당성을 평가합니다.

00:18:54.400 --> 00:18:58.380
드리프트 디텍터가 그래프 및 디펜더 위 필드를 실제로 인용했는지 확인합니다.

00:18:58.580 --> 00:19:02.340
범위, 장치 ID, 정책 ID, 변경 유형을 검사합니다.

00:19:02.600 --> 00:19:05.680
모든 기기에서 공통적으로 문제가 발견되면 무조건 차단됩니다.

00:19:05.680 --> 00:19:11.180
콘텐츠 안전성은 입력과 출력 모드에서 보장되어 외부 정보나 복사된 로그를 통한 무차별적인 삽입을 방지합니다.

00:19:11.340 --> 00:19:15.500
충돌하는 로컬 정책 제거와 같은 고위험 작업은 PM, 프로젝트 관리자, 위스인을 거쳐야 합니다.

00:19:15.680 --> 00:19:17.760
수정 담당자의 신원은 자동으로 노출되지 않습니다.

00:19:17.980 --> 00:19:19.920
승인은 깔끔한 카드 형식의 로직 앱에서 이루어집니다.

00:19:20.060 --> 00:19:22.260
무엇이 잘못되었는지, 무엇이 변경될지 명확하게 제시합니다.

00:19:22.420 --> 00:19:23.960
롤백 단계와 관련 참조 정보를 제공합니다.

00:19:24.140 --> 00:19:25.780
승인 후 수정 담당자가 작업을 실행합니다.

00:19:25.980 --> 00:19:28.740
인튠 정책 업데이트는 항목별로 강력하고 정확하게 적용됩니다.

00:19:35.680 --> 00:19:37.900
456 에스크로 경로를 지원하는지 확인합니다.

00:19:38.040 --> 00:19:42.520
사전검사에 실패할 경우, 사람이 이해하기 쉬운 오류 메시지와 함께 부작용 없이 처리됩니다.

00:19:42.680 --> 00:19:44.660
메신저를 통해 모든 과정이 완료됩니다.

00:19:44.840 --> 00:19:51.100
기기 수정이 완료되면, 팀즈의 수정 내역, 앱인사이트 추적 링크, 그리고 엑셀을 가족보다 더 좋아하는 사용자를 위한 csv 파일이 포함된 요약 보고서가 전송됩니다.

00:19:52.960 --> 00:19:57.200
기기가 정책 준수를 거부할 경우, 검토자는 예외 스레드를 생성하고 제시도 일정을 예약합니다.

00:19:57.360 --> 00:20:01.100
관찰 가능성을 확보하기 위해 모든 도구 호출을 추적하고, 스레드별로 상관관계를 분석합니다.

00:20:01.100 --> 00:20:06.660
감사팀이 kql에 계속 머물지 않고도 규정 미준수와 준수 여부를 확인할 수 있도록 변경 전후의 변경사항을 잠급니다.

00:20:06.780 --> 00:20:11.260
또한 변경 후 요약에 대한 평가 에이전트를 실행하여 근거와 명확성을 확인합니다.

00:20:11.460 --> 00:20:18.240
근거가 떨어지거나 실패율이 급증하면 플래너는 검색 범위를 좁히거나 배치 크기를 줄이거나 파괴적인 작업을 일시 중지합니다.

00:20:18.440 --> 00:20:23.240
추출 및 분류에는 slm 모델을, 계획 합성에는 필요한 경우 m1 추론 모델을 혼합하여 사용합니다.

00:20:23.440 --> 00:20:24.780
야간 보고서를 일괄 처리합니다.

00:20:24.980 --> 00:20:26.300
ai에 대한 장황한 설명은 필요 없습니다.

00:20:26.540 --> 00:20:28.520
최종 결과는 비트로커가 실제로 활성화되어 있다는 것입니다.

00:20:28.520 --> 00:20:32.600
업데이트링의 드리프트가 줄어듭니다. 예외사항은 문서화되고 기한이 정해져 있으며 검토 가능합니다.

00:20:32.740 --> 00:20:36.540
그리고 분기마감 시 재무 담당자의 노트북을 재설치하여 문제를 해결하는 일은 없습니다.

00:20:36.840 --> 00:20:41.300
아키텍처는 파운드리, 시멘틱 커널, 도구, 아이덴티티로 구성됩니다.

00:20:41.500 --> 00:20:44.180
할당량에 영향을 주지 않고 내부 구조를 살펴보겠습니다.

00:20:44.640 --> 00:20:50.360
이 모든 것을 합리적으로 유지하는 4가지 계층, 즉 파운드리, 시멘틱 커널, 도구, 아이덴티티를 생각해보세요.

00:20:50.560 --> 00:20:52.020
파운드리는 핵심 기반입니다.

00:20:52.020 --> 00:20:59.080
엄격한 지침으로 에이전트를 정의하고, 역할별로 배포를 선택하고, 에이저 AI 검색을 통해 지식을 연결하고 작업을 등록합니다.

00:20:59.240 --> 00:21:05.380
개방형 API 도구, 로직 앱, 함수, 그래프, 에이저 자동화, 코드 인터프리터를 활용합니다.

00:21:05.560 --> 00:21:09.340
위협, 실행 기록, 추적, 평가 및 안전성이 모두 여기에 포함됩니다.

00:21:09.520 --> 00:21:16.340
콘텐츠 안전성 프롬프트 보호장치와 보호 대상 자료 검사는 모델 실행 전후에 실행되어 잘못된 입력으로 인해 토큰이 소모되거나 잘못된 출력으로 인해 작업이 중단되는 것을 방지합니다.

00:21:16.340 --> 00:21:22.080
시멘틱 커널, SK, 이 모든 것을 제어합니다. 코드에서는 플래너, 운영자, 검토자 루프를 연결합니다.

00:21:22.260 --> 00:21:26.820
도구에 대한 함수 카탈로그를 등록하고, 제시도 기능을 해제하고, 취소 토큰을 추가합니다.

00:21:27.020 --> 00:21:32.920
프롬프트는 간결하게 유지하고, 복잡성은 스키마에 포함시켜 SK가 가용성과 정책에 따라 호출할 도구를 결정하도록 합니다.

00:21:33.100 --> 00:21:36.140
그래프 시간 초과가 발생하면 SK는 Z 터링으로 처리합니다.

00:21:36.340 --> 00:21:38.760
접지도가 떨어지면 플래너로 돌아가 개선합니다.

00:21:39.000 --> 00:21:40.540
도구는 실행 도구의 역할을 합니다.

00:21:40.760 --> 00:21:43.320
개방형 API를 사용하여 계약을 엄격하게 관리합니다.

00:21:43.320 --> 00:21:46.360
API 관리를 통해 버전 관리 및 회로 차단을 구현합니다.

00:21:46.540 --> 00:21:50.860
로직 앱은 승인 및 장기 실행 흐름을 처리하고, 함수는 연결 및 변환 작업을 수행합니다.

00:21:51.060 --> 00:21:54.360
에이저 자동화는 가이드라인과 사후 검사를 통해 스크립트를 실행합니다.

00:21:54.560 --> 00:21:58.420
그래프는 인튠, 엔트라, 규정 준수 및 보안 점수에 대한 핵심 정보 소스입니다.

00:21:58.620 --> 00:22:01.180
에이저 AI 검색은 도메인별로 선별된 지식을 제공합니다.

00:22:01.380 --> 00:22:02.860
정보가 뒤죽박죽이 되는 일이 없습니다.

00:22:03.180 --> 00:22:04.340
아이디는 안전장치와 같습니다.

00:22:04.660 --> 00:22:06.520
각 에이전트는 고유한 관리 아이디를 갖습니다.

00:22:06.520 --> 00:22:10.440
모니터링 에이전트는 읽기 권한을, 복구 에이전트는 쓰기 권한을 가지며 관리자 권한은 부여되지 않습니다.

00:22:10.560 --> 00:22:12.300
PM은 파괴적인 작업을 차단합니다.

00:22:12.500 --> 00:22:14.880
권한 상승은 사람의 쓰인을 필요로 하며 만료됩니다.

00:22:15.060 --> 00:22:17.760
데이터 경계가 중요한 프라이빗 엔드포인트를 사용합니다.

00:22:17.940 --> 00:22:22.200
파운드리 프로젝트의 정책 기준서는 허용된 모델, 지역 및 탈당량을 적용합니다.

00:22:22.400 --> 00:22:28.840
앱 인사이트 및 로그 분석은 추적, 매트릭 및 감사를 수집하여 슬랙에서 데이터를 찾아 헤맬 필요 없이 누가 무엇을 했는지 파악할 수 있도록 지원합니다.

00:22:28.840 --> 00:22:31.780
모델은 파운드리 위 추론 엔드포인트를 통해 연결할 수 있습니다.

00:22:31.980 --> 00:22:35.980
고급 추론에는 서버리스를 사용하고, 고정된 오픈모델에는 관리형 컴퓨팅을 사용할 수 있습니다.

00:22:36.180 --> 00:22:41.780
코드를 다시 작성하지 않고도 모델을 교체할 수 있지만, 배포하기 전에 CI에서 관련성, 타당성 및 유창성을 평가할 수 있습니다.

00:22:42.000 --> 00:22:45.020
지역은 사용자와 일치하고, 데이터 영역은 규제기관과 일치합니다.

00:22:45.220 --> 00:22:48.140
이 모든 것을 종합하면 지루해 보일지 몰라도 안정적인 시스템이 됩니다.

00:22:48.140 --> 00:22:56.100
파운드리에서 정의되고, SK가 오케스트레이션하며, 엄격한 도구로 구동되고, 신원 확인으로 보호되고, 관찰 가능성으로 측정되고, 안전으로 보호되는 에이전트.

00:22:56.220 --> 00:22:57.240
지루함이 승리합니다.

00:22:57.440 --> 00:22:58.800
지루함은 확장성이 뛰어납니다.

00:22:59.020 --> 00:23:00.800
지루함은 당신이 잠을 잘 수 있게 해줍니다.

00:23:01.000 --> 00:23:02.140
모범 사례는 후회 없이 배포됩니다.

00:23:02.940 --> 00:23:03.400
알겠죠?

00:23:03.620 --> 00:23:06.100
토요일에 일을 망치지 않도록 시간관리 능력을 키우세요.

00:23:06.280 --> 00:23:08.100
각 에이전트에게 하나의 업무만 부여하세요.

00:23:08.320 --> 00:23:11.280
기획자는 계획하고, 운영자는 운영하며, 검토자는 검토합니다.

00:23:11.280 --> 00:23:15.000
에이전트가 장황한 소설을 쓰기 시작하면, 그 부분을 삭제하고 도구에 넘겨주세요.

00:23:15.180 --> 00:23:17.560
지침은 간결하고, 범위가 명확하며, 지루하게 유지하세요.

00:23:17.720 --> 00:23:19.260
그러면 예상치 못한 일이 줄어듭니다.

00:23:19.420 --> 00:23:21.120
긴 글보다는 도구 호출을 선호하세요.

00:23:21.320 --> 00:23:24.740
계약은 공개 API에, 스키마는 입력에, 가드레일은 출력에 명시하세요.

00:23:24.920 --> 00:23:27.340
도구가 특정 장치를 요구하면, 아마도 이 금융회사의 장치 읽어봅니다.

00:23:27.440 --> 00:23:28.960
라고 말하지 말고, 바로 그 장치를 보내세요.

00:23:29.120 --> 00:23:31.060
모델은 창의적이지만 도구는 그렇지 않습니다.

00:23:31.240 --> 00:23:32.020
바로 그 점입니다.

00:23:32.280 --> 00:23:35.460
당신의 업무가 달려있는 것처럼 최소 권한 원칙을 철저히 준수하세요.

00:23:35.680 --> 00:23:36.580
신원을 분리하세요.

00:23:36.820 --> 00:23:39.140
모니터링 담당자는 읽기 전용, 복구 담당자는 쓰기 전용으로 하고,

00:23:39.380 --> 00:23:41.240
PM 없이는 어떤 신원도 삭제 권한을 갖지 못하도록 하세요.

00:23:41.380 --> 00:23:43.540
권한 상승은 일시적이고, 정당한 이유가 있으며, 기록됩니다.

00:23:43.720 --> 00:23:46.820
누군가 연구적인 글로벌 관리자 자리를 요청하면, 스트레스볼과 정책 문서를 건네주세요.

00:23:47.280 --> 00:23:48.200
처음에는 소규모로 시작하세요.

00:23:48.380 --> 00:23:50.280
실행자와 검토자, 이렇게 두 명이 담당자로 시작하세요.

00:23:50.460 --> 00:23:52.040
시스템이 안정화되면, 계획 담당자를 추가하세요.

00:23:52.040 --> 00:23:55.240
그리고 규모를 확장해야 한다면, 처음부터 12명 규모의 디지털 스크럼팀을 만들지 마세요.

00:23:55.380 --> 00:23:57.760
그렇게 하면 YAML로 조직도를 다시 그려야 하고, 후회하게 될 겁니다.

00:23:57.940 --> 00:23:59.520
비용을 절감하기 위해 다양한 모델을 활용하세요.

00:23:59.700 --> 00:24:02.660
SLM은 데이터 추출에, GPT4 클래스는 중요한 추론에만 사용하세요.

00:24:02.840 --> 00:24:04.600
요약은 일괄 처리로 밤새 도록 진행하세요.

00:24:04.820 --> 00:24:07.200
날짜 문자열 형식을 지정하는데, 추가 비용을 지불할 필요는 없습니다.

00:24:07.480 --> 00:24:10.140
무거운 모델은 의사결정에 사용하고, 설명에는 사용하지 마세요.

00:24:10.320 --> 00:24:11.820
메모리는 가장 나중에 추가하세요.

00:24:11.820 --> 00:24:13.760
AI 검색에는 외부 상태를 사용하거나,

00:24:14.100 --> 00:24:17.440
컨텍스트 창을 기내용 가방처럼 가득 채우기 전에 작은 상태 저장소를 활용하세요.

00:24:17.640 --> 00:24:19.440
스레드 메타 데이터는 아주 작아야 합니다.

00:24:19.660 --> 00:24:21.440
다음 턴에 필요하지 않으면 삭제하세요.

00:24:21.660 --> 00:24:22.700
모든 것을 기록하세요.

00:24:22.940 --> 00:24:24.020
추적 기능을 활성화하세요.

00:24:24.240 --> 00:24:26.740
스레드 아이디, 도구 매개 변수, 지연 시간 결과 등을 기록하세요.

00:24:26.900 --> 00:24:29.660
프로덕션 환경보다 먼저 관련성 및 파당성 저하를 감지할 수 있도록

00:24:29.660 --> 00:24:31.060
CI 환경에 평가를 배포하세요.

00:24:31.260 --> 00:24:33.900
트위터가 반응할 때가 아니라, 안정성이 떨어질 때 알림을 보내세요.

00:24:34.080 --> 00:24:36.900
속도보다 안전장치를 우선시하고, 파괴적인 도구 사용에 대한 쓰인을 받으세요.

00:24:36.900 --> 00:24:38.900
부작용 없는 사전 테스트 모드를 활용하세요.

00:24:39.060 --> 00:24:41.340
기기 그룹 또는 지역별로 단계적으로 배포하세요.

00:24:41.520 --> 00:24:44.340
만약 모든 것을 한 번에 배포하려는 계획이라면, 이력서를 업데이트하셨기를 바랍니다.

00:24:49.440 --> 00:25:00.740
상호 배타성 규칙, 라이선스 번들, 기기 기준선 등을 구조화된 형태로 저장하세요.

00:25:00.960 --> 00:25:03.200
모델은 선택할 수는 있지만, 만들어내서는 안 됩니다.

00:25:03.480 --> 00:25:06.860
이것이 에이전트를 유용하게 유지하고, 영향 범위를 최소화하는 방법입니다.

00:25:06.860 --> 00:25:09.720
한 가지 기억해야 할 것은, 개별 에이전트도 도움이 되지만,

00:25:10.180 --> 00:25:13.220
계획적이고 도구 중심적이며, 권한 범위가 지정된 에이전트팀은

00:25:13.220 --> 00:25:15.680
당신이 자는 동안 조용히 환경을 변화시킨다는 것입니다.

00:25:15.860 --> 00:25:17.340
이 내용이 마음에 와 닿았다면 구독하고,

00:25:17.340 --> 00:25:20.880
제가 시멘틱 커널 저장소와 이두근 템플릿을 공개하는 후속 영상을 시청하세요.

00:25:21.080 --> 00:25:22.440
마음껏 뵙겨 쓰셔도 좋습니다.

00:25:22.640 --> 00:25:25.300
평가 담당자들이 약속을 지키는 모습을 담은 에피소드를 원하시나요?

00:25:25.500 --> 00:25:26.720
다음 주에 공개될 예정입니다.