Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Azure AI Foundry 멀티 에이전트 시스템: 프로덕션을 망가뜨리지 않는 계획, 협업, 도구 설계 (AI 더빙)

Transcript

Azure AI Foundry 멀티 에이전트 시스템: 프로덕션을 망가뜨리지 않는 계획, 협업, 도구 설계 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
아시다시피, 채꽃은 말하고, 에이전트는 행동하고, 멀티 에이전트 시스템은 실제로 작업을 처리합니다.
0:04
인튠 문제를 해결해달라고 보세게 부탁했는데, 시 한 편만 읊어준 경험이 있다면, 이 글이 도움이 될 겁니다.
0:08
넷플릭스를 직접 체험해보세요.
0:10
여러분은 편하게 시청하시고, 간식도 드세요.
0:12
저는 위험 서비스 원칙을 지켜서 아무도 프로덕션 환경을 망치지 않도록 하겠습니다.
0:15
에이저 AI 파운드리와 시멘틱 커널을 사용하여 자체 복구 기능이 있는 소규모 멀티 에이전트 시스템을 구축할 겁니다.
0:20
실제 접점을 활용할 거예요.
0:21
인튠, 엔트라, 그래프, 에이저 오토메이션, 로그 애널리틱스 등을 사용합니다.
0:26
에이전트 하나와 멀티 에이전트 시스템을 직접 비교해보고, 12분과 3분을 비교해보겠습니다.
0:29
유일한 피해자는 제 구동료 크레딧 뿐입니다.
0:31
먼저, 팀즈는 빠르게 작동하는 반면, 에이전트 하나는 왜 멈추는지, 왜 에이전트 하나로는 부족한지 알아보겠습니다.
0:36
단일 에이전트는 주유소에서 파는 맥북 칼과 같습니다.
0:38
기술적으로는 도구가 많지만, 실제로는 첫 번째 나사만 조여도 휘어지죠.
0:42
계획, 추론, 실행, 승인, 보고를 하나의 프롬프트에 모두 담으면 컨텍스트가 부족해지고 속도가 느려지며, 잘못된 부분에 대해 이상할이 많지 확신하게 됩니다.
0:49
대부분의 사람들은 더 큰 모델, 더 큰 두뇌, 그러면 문제가 해결될 거라고 생각하지만, 실제 문제는 역할 혼란에 있습니다.
0:55
한 명이 상담원이 변경 계획, 콜 그래프 작성, 문제 해결 스크립트 작성, 승인 요청, 결과 검증, 문서화까지 모두 처리하려고 합니다.
1:03
마치 지친 인턴 한 명이 헬프 데스크, 변경 관리 게시판, 사후 분석까지 모두 담당하는 것과 같습니다.
1:07
실제로는 다음과 같은 일이 벌어집니다.
1:09
단일 상담원이 너무 많은 상태를 처리하려고 합니다.
1:11
프롬프트는 장황해집니다.
1:13
컨텍스트 창에는 로그, 정책, MDM 용어집의 절반이 채워져 중요한 부분이 잘리거나 누락된 세부 정보가 표시됩니다.
1:19
지연 시간이 급증하고 토큰이 소모되며 제시도는 마치 청구서를 받는데 자비처럼 느껴집니다.
1:24
이러한 문제를 해결하기 위해 다중 상담원, 역할, 경계, 병렬 처리가 필요합니다.
1:28
계획 담당자는 의도와 제약 조건에 집중하고, 운영 담당자는 도구와 실행에 집중합니다.
1:33
검토자는 가이드라인, 승인, 그리고 모든 것이 사실에 근거한 것인지에 집중합니다.
1:37
각 에이전트는 필요한 최소한의 메모리로 간결하고 명료한 명령어 세트를 유지합니다.
1:41
에이전트는 메시지, 도구 결과 또는 간단한 요약만 전달하며 인터넷 전체를 전송하지는 않습니다.
1:45
이것이 기업 환경에서 중요한 이유는 무엇일까요?
1:47
기업에서는 사람이 개입하는 게이트, 아이디 범위 지정작업, 제시도, 감사추적 기능을 갖춘 엔드투엔드 워크플로우가 필요합니다.
1:52
이는 단일 스레드 채팅으로는 해결할 수 없는 문제입니다.
1:54
팀워크가 필수적입니다.
1:56
계획자, 실행자, 검토자 패턴은 모든 단계에 자동화된 검토자가 있어 위험과 재작업을 줄여줍니다.
2:00
이 자동화된 검토자는 간단한 팀지 회의에 참여하는 소수 인원이 아닙니다.
2:04
비용과 지연 시간도 절감할 수 있습니다.
2:06
추출 및 분류에는 간단한 언어 모델을 사용하고, 계획 수립에 실제로 도움이 되는 경우에만 고급 추론 모델을 사용하십시오.
2:12
사용자가 자는 동안 요약 작업을 일괄 처리하십시오.
2:14
그러면 혼란이 줄어들고 결과가 빨라지며 비용도 절감할 수 있습니다.
2:18
작은 일화 하나를 소개하자면, 모든 작업을 수행하는 보다나가 비밀 정보를 조작하려 했던 것을 본 적이 있습니다.
2:22
키를 업데이트하고 앱 설정을 잊어버린 후 리소스를 삭제하여 문제를 해결했습니다.
2:26
바로 그날 검토자 에이전트를 개발하게 되었습니다.
2:29
멀티 에이전트 시스템의 기본 원리, 명확하고 간단하죠.
2:32
자, 그렇다면 실제로 출시할 수 있는 멀티 에이전트 시스템이란 무엇일까요?
2:35
하나의 거대한 두뇌가 아니라 디지털 팀을 생각해보세요.
2:38
각 에이전트는 역할, 엄격한 지침 세트, 그리고 제한된 도구를 가지고 있습니다.
2:42
계획 담당자는 목표, 제약 조건, 환경을 이해하고 운영자가 실행할 수 있는 도구 호출을 포함한 계획을 수립합니다.
2:49
운영자는 도구, 그래프, 로직 앱, 함수, 에이저 오토메이션, 넌북 등을 호출하고 구조화된 결과를 반환합니다.
2:57
검토 담당자는 위험한 상황이 발생하기 전에 근거, 규정 준수 범위, 승인 및 안전 출력을 확인합니다.
3:05
메신저 담당자는 감사 추적을 위한 알림, 승인 및 요약을 처리합니다.
3:09
이들은 어른들이 해야 하는 방식대로 간결하고 명확하며 필요한 정보만 메시지와 공유 컨텍스트를 통해 소통합니다.
3:15
작업이 이전 결과에 따라 달라지는 경우 순차적으로 하위 작업이 안전하게 분산될 수 있는 경우 병렬로 처리합니다.
3:21
50페이지의 짜리 정책 문서를 보내는 대신 관련 코드 조각, 장치 아이디, 그리고 변경 예정 사항만 보내세요.
3:26
도구는 핵심적인 역할을 합니다.
3:27
마이크로소프트 그래프용 네스트 API, 에이저 AI 검색을 통한 선별된 지식 검색 도구, 코드 조각용 코드 인터프리터, 오케스트레이션된 시퀀스용 로직앱, 연결도구 역할을 하는 함수, 반복 가능한 장치 작업을 위한 에이저 오토메이션 등을 활용하세요.
3:38
운영자가 임의로 테넌트를 삭제하지 못하도록 도구 입력 값을 스키마로 구조화하세요.
3:43
메모리는 마법이 아니라 예산입니다.
3:45
에이전트별 메모리 사용량을 최소화하세요.
3:47
외부 상태 저장소, 검색 인덱스, 벡터 저장소 또는 스레드 메타데이터 용 소형 상태 저장소를 사용하세요.
3:51
컨텍스트 창을 간결하게 유지하세요.
3:53
다음 결정에 필요하지 않은 정보는 기록하지 마세요.
3:55
시멘틱 커널은 계획과 실행을 효과적으로 지원합니다.
3:58
계획 담당자는 작업을 위임하고, 운영자는 함수 카탈로그를 통해 적합한 도구를 선택합니다.
4:02
검토자는 평가 프롬프트와 콘텐츠 안전성을 활용하여 결과물을 검토합니다.
4:06
검토자가 범위 위험을 지적하면 계획 담당자가 수정합니다.
4:09
이 루프를 이해하면 800단어짜리 프롬프트를 작성하는 대신 명확한 역할을 구축하기 시작합니다.
4:14
안전경계는 파협할 수 없습니다.
4:16
관리되는 아이디를 사용하는 아이디 범위 도구 호출.
4:19
에이전트 권한은 읽기와 관리로 분할됩니다.
4:22
파괴적인 작업에 대한 권한 상승은 PM에게 부여됩니다.
4:25
모든 도구 호출은 로그 분석에 기록됩니다.
4:27
입력과 출력 모드에 콘텐츠 안전이 보장됩니다.
4:29
탈옥 및 지식소스로부터의 간접 프롬프트 주입으로부터 프롬프트를 보호합니다.
4:33
비유하자면 연구원, 분석가, 운영자, QA 담당자입니다.
4:37
각자 자신의 역할에 대한 책임이 있습니다.
4:39
운영자는 자신의 변경사항을 승인하지 않습니다.
4:41
분석가는 프로덕션 환경을 건드리지 않습니다.
4:43
QA 담당자는 자신이 승인하는 코드를 작성하지 않습니다.
4:45
간단하고 지루하지 않으며 안전합니다.
4:47
에이저 AI 파운드리와 시멘틱 커널을 함께 사용해야 하는 이유는 무엇일까요?
4:50
파운드리는 에이전트 오케스트레이션, 모델 선택, 지식기반 구축, 도구 연결, 콘텐츠 안전, 추적, 평가 및 거버넌스를 한 곳에서 제공합니다.
4:58
시멘틱 커널은 코드 내에서 플래너, 스킬, 파이프, 라인, 제시도 및 취소 기능을 제공합니다.
5:03
각 역할에 맞는 모델들을 조합하고, 데이터 추출에는 SLM을, 계획 수립에는 GPT4 클래스를, 요약에는 배치 처리를 활용하세요.
5:10
프롬프트는 간결하게, 작업 범위는 좁게, 주말은 자유롭게 활용하세요.
5:14
이제 실제로 구현해보겠습니다.
5:16
에이저 AI 파운드리는 어떻게 멀티 에이전트 워크플로우를 지원하는지 알아보겠습니다.
5:20
에이저 AI 파운드리는 단순한 포털을 넘어 실제 운영 환경처럼 작동합니다.
5:24
파운드리를 사용하면 에이전트를 정의하고, 모델을 연결하고, 지식을 추가하고, 액션을 연결하고, 모든 것을 모니터링할 수 있습니다.
5:31
마치 덕트테이프 없이도 완벽한 오케스트레이션을 구현하는 것과 같습니다.
5:34
먼저 에이전트 정의부터 시작해보세요.
5:36
파운드리에서는 각 에이전트에 대한 명확한 역할 지침이 제공되며, 단순한 선언문이 아닙니다.
5:41
데포는 실제 모델을 구축하는 단계입니다.
5:43
계획 수립에는 GPT4 클래스를, 데이터 추출에는 P클래스 SLM을 조합하여 사용할 수 있습니다.
5:47
지식은 에이저 AI 검색 인덱스, 업로드된 파일, 웹컨텍스트가 필요할 때는 빈 검색 결과를 활용할 수 있습니다.
5:52
액션은 오픈 API 도구, 로직 앱, 함수, 그래프, 에이저 오토메이션 넌북, 또는 빠른 연산 및 구문 분석을 위한 코드 인터프리터를 사용할 수 있습니다.
6:00
연결된 에이전트, 네, 에이전트는 역할을 명확하게 유지하는 한 다른 에이전트를 도구처럼 다룰 수 있습니다.
6:06
이는 시멘틱 커널이 동일한 생태계에 연결되기 때문에 중요합니다.
6:10
코드에서는 플래너를 구축하고, 스킬을 정의하고, 함수 카탈로그에 도구를 등록합니다.
6:14
플래너, 운영자, 검토자 루프를 구성하고, 파운드리가 스레드, 기록 및 안전장치를 처리하도록 합니다.
6:20
프롬프트는 간결하게 유지하고, 스키마가 있는 도구의 핵심 작업을 맡기세요.
6:24
번역, 환상 감소, 객체 지향 오류 감소, 주말 시간 증가, 모델 선택은 중요합니다.
6:29
파운드리는 모델 엔드포인트를 통해 추론을 추상화하므로 전체 앱을 다시 작성하지 않고도 모델을 교체할 수 있습니다.
6:33
두 가지 일반적인 방식이 있습니다.
6:35
프리미엄 모델용 서버리스 엔드포인트와 빠른 방법을 위한 엔드포인트입니다.
6:38
토큰 단위로 비용을 지불하고 필요에 따라 확장할 수 있으며, 2018년처럼 GPU를 관리할 필요가 없습니다.
6:42
테넌트 경계에 고정하려는 특정 오픈 모델에 대한 관리형 컴퓨팅도 있습니다.
6:46
가동시간 단위로 비용을 지불하고 형태를 제어할 수 있지만 배포인프라는 마이크로소프트에서 관리합니다.
6:50
역할별로 모델을 혼합하여 사용할 수 있습니다.
6:52
추론에는 gpt4 또는 4.1 미니 기반의 플래너를 사용하고, 추출 및 파라미터 조정에 탁월한 소형 모델 기반의 오퍼레이터를 활용하세요.
6:58
긴 요약 정보를 밤새 일괄 처리하여 아침에 담당자가 보기 좋은 보고서를 받아볼 수 있도록 하세요.
7:02
모델이 더 이상 사용되지 않거나 딥식 또는 남아 변형 모델을 사용해보고 싶을 때, 파운드리 위추론 api를 통해 실험하는 동안에도 코드를 안정적으로 유지할 수 있습니다.
7:10
오퍼레이터의 역량은 도구와 액션에서 빛을 발합니다.
7:12
에이전트에게 모든 권한을 넘겨주지 않고도 실질적인 권한을 부여할 수 있는 곳입니다.
7:16
스웨거를 사용하여 내부 서비스를 위한 개방형 api 도구를 활용하세요.
7:19
계약 내용을 엄격하게 유지하세요.
7:21
스키마에서 장치를 문자열로 지정했다면 반드시 장치 아이디여야 합니다.
7:24
승인 흐름 및 휴먼 게이트에는 로직 앱을 사용하세요.
7:27
검토자가 변경 사항을 승인자에게 전달하고 승인 시 실행을 재개하도록 하세요.
7:31
에이저 펑션스를 사용하여 연결 코드 및 적절한 변환 작업을 처리하세요.
7:34
인튠, 엔트라 및 사용자 장치 조건부 액세스 작업을 위한 작고 테스트 가능한 버전 관리 그래프 api를 활용하세요.
7:40
모니터링 에이전트에게는 읽기 권한을, 복구 담당자에게는 관리 권한을 부여하세요.
7:44
에이저 오토메이션을 사용하여 장치 스크립트 및 실행 설명서를 작성하세요.
7:47
잠긴 서랍 속 날카로운 물건처럼 취급하세요.
7:50
오직 전문가만이 열 수 있습니다.
7:52
접지처럼 엄선된 정보만 관리하세요.
7:54
하이브리드 랭킹 및 시멘틱 재랭킹 기능을 갖춘 네이저 AI 검색을 활용하세요.
7:57
도메인별로 지식을 공유하세요.
7:59
온 보딩 SOP와 별도로 인튠 정책을 관리하세요.
8:02
모든 것을 한꺼번에 배포하지 않도록 하세요.
8:04
운영자는 백과 사전이 아닌 핵심 정보만 전달해야 합니다.
8:07
데이터 청크 크기를 적절히 조정하고, 출처를 저장하고, 프로덕션 환경에 배포하기 전에 검토자가 타당성을 확인하도록 하세요.
8:12
안전은 선택 사항이 아닙니다.
8:14
파운드리는 입력 및 출력에 대한 콘텐츠 안전 필터, 탈옥 및 간접 주입에 대한 프롬프트 보호 기능, 보호자료 검사 기능을 기본적으로 제공합니다.
8:20
잘못된 입력이나 출력으로 인한 PR 재앙에 대한 비용을 지불하지 않도록 모델 전후의 안전검사를 실행하세요.
8:26
에이전트 별 관리 아이디, 최소 권한 복구, 파괴적인 도구에 대한 임시 권한 상승을 위한 PM 기능을 함께 활용하세요.
8:31
모든 도구 호출은 추적되고, 모든 승인은 로그에 기록됩니다.
8:34
누군가, 누가 무엇을 실행했나요? 라고 물으면 아울록을 열 필요가 없습니다.
8:38
로그 분석 기능이 이미 모든 것을 알고 있습니다.
8:39
관찰 가능성은 성숙한 단계입니다.
8:42
실행 기록을 확인하려면 추적 기능을 활성화하세요.
8:44
어떤 에이전트가 어떤 도구를 어떤 매개 변수로 호출했는지, 지연 시간은 얼마였는지, 그리고 어떤 결과가 반환되었는지 확인할 수 있습니다.
8:49
성능 패턴을 파악하기 위해 애플리케이션 인사이트를 연결하고, 감사를 위해 앱 로그를 활용하며, 사용자가 문제를 발견하기 전에 관련성, 타당성, 유창성 저하를 감지하기 위해 CI의 평가를 배포하세요.
8:58
타당성이 떨어지면 검토자가 플래그를 지정하고, 플래너는 검색 커리를 좁히고, 운영자는 다시 시도합니다.
9:03
사람이 당황할 필요가 없습니다.
9:04
배포 기본 요소를 통해 깔끔하게 관리할 수 있습니다.
9:07
팀 범위 할당량 및 정책 기준선에는 파운드리 프로젝트를 사용하세요.
9:10
도구 서비스 앞에 에이저 API 매니지먼트를 배치하여 버전 관리, 스로틀링, 회로 차단기 구현, PTO와 중량제 추론 간의 라우팅을 관리하세요.
9:17
데이터 상주 또는 규정 준수를 통해 보안을 강화하는 경우 비공개 엔드포인트를 사용하세요.
9:21
단순히 목표가 아닌 실제 사용자에게 적합한 리전을 선택하세요.
9:25
그리고 시멘틱 커널이 모든 것을 완성합니다.
9:27
워크플로우를 코드로 정의하면 플래너가 이를 분해하고, 운영자는 기능 카탈로그와 가용성을 기반으로 도구를 선택합니다.
9:33
검토자는 평가 프롬프트와 콘텐츠 안전 결과를 통해 검사를 시행하고, 외부 API 가유지 보수를 위해 다운된 것처럼 가장할 경우 배고프 및 취소 토큰을 사용하여 재시도할 수 있습니다.
9:44
SK는 실행 두뇌를 제공하고, 파운드리는 운영 환경을 제공합니다.
9:47
이 둘을 결합하면 실용적인 패턴이 만들어집니다.
9:50
파운드리에서 엄격한 지침과 아이디를 사용하여 에이전트를 정의하고, SK에서 역할을 오케스트레이션하고, 선별된 검색으로 기반을 다지고, 개방형 API, 로직 앱, 함수, 자동화를 통해 작업을 연결하고, 추론 전후의 안전성을 강화하고 모든 것을 관찰합니다.
10:03
최고의 의미에서 지루할 수 있습니다.
10:05
안전벨트 착용이나 인터넷의 기본 키라는 이름의 전역 관리자 권한을 부여하지 않는 것과 같습니다.
10:10
데모 시나리오 1. 장치 정리. CSI 인튠 유령 장치 부서. 관리됨, 사용 중지됨, 그리고 비활성화됨으로 동시에 표시되는 장치들을 아시나요?
10:20
CSI 인튠 에오신 것을 환영합니다.
10:23
저희의 임무는 오래되었거나, 중복되었거나, 등록되지 않은 하드웨어를 찾아 스인을 통해 안전하게 수정하여 아무도 법적 조치를 취하지 않도록 하는 것입니다.
10:30
에이전트, 모니터링 담당자, 퀄이 담당자, 마이크로소프트 그래프 및 로그 분석 담당자가 장치 상태를 분류하고 이상 징후를 표시합니다.
10:37
복구 담당자는 인튠 및 에이저 자동화를 호출하여 장치를 격리하거나 폐기합니다.
10:42
감사 담당자는 모든 것을 기록하고 담당자에게 알림을 보내고 규정 준수를 위한 사후보고서를 작성합니다.
10:48
전체 흐름은 다음과 같습니다.
10:49
모니터링 담당자는 그래프 장치 기록에서 마지막 체크인, 규정 준수 상태, 등록 유형, 기본 사용자 및 폐기 플래그를 가져옵니다.
10:56
또한 로그 분석 신호, 디펜더 하트비트, 업데이트 규정 준수 및 인튠 관리 확장 이벤트도 수집합니다.
11:02
이러한 정보를 장치별로 간략하고 구조화된 레코드로 통합합니다.
11:05
마지막 접속 시간, UTC, 등록 여부, 규정 준수 여부, 중복 후보, 위험 신호 등이 포함됩니다.
11:10
장황한 설명 없이 필드만으로 구성됩니다.
11:11
이제 분석 담당자가 실제 담당자에게 작업을 인계합니다.
11:13
모니터링 담당자는 제한된 분류, 오래됨, 중복, 하트비트 없음 또는 정상, 를 보냅니다.
11:17
검토자는 근거를 확인합니다.
11:19
이러한 필드가 실제로 그래프 및 로그 분석에서 가져온 것인지 확인합니다.
11:22
콘텐츠 안전 기능은 사전 모델링을 실행하여 업로드된 파일이나 웹링크에서 발생하는 프롬프트 주입을 차단합니다.
11:27
분류가 통과되면 복구 담당자가 조치를 준비합니다.
11:31
1단계는 소프트 복구, 태그 지정 및 격리입니다.
11:34
폐기 대상 장치 범주에 후보를 적용하고 정책 확산을 유발하는 동적 그룹 바인딩을 제거하며
11:40
필요한 경우 액세스를 차단하는 에이저 AD 격리 그룹으로 장치를 이동합니다.
11:45
아직 삭제는 수행하지 않습니다.
11:47
승인은 로직 앱에서 이루어집니다.
11:49
검토자는 간략한 계획, 장치 아이디, 사유, 제한된 조치, 롤백을 포함합니다.
11:55
승인자는 그래프 커리 및 로그 분석 KQL에 대한 참조가 포함된 요약을 팀즈에서 확인합니다.
12:00
센서 토큰이 승인되면 복구 도구가 폐기를 실행하거나
12:03
정당한 경우 데이터를 삭제하거나
12:04
최신 하트비트를 가진 장치를 유지하고
12:07
중복된 데이터를 연결 해제하여 중복을 정리합니다.
12:09
관리형 아이디를 사용하여 모든 작업을 안전하게 처리합니다.
12:12
모니터링 도구는 장치에 대한 모든 읽기 권한으로 실행됩니다.
12:15
복구 도구는 장치에 대한 모든 읽기, 쓰기 권한과 필요한 인튠 권한만 있는 별도의 아이디를 사용합니다.
12:19
삭제는 팀, 프로젝트 관리 모니터링을 통해 이루어집니다.
12:21
복구 도구 에이전트는 자체적으로 권한을 상승시킬 수 없습니다.
12:24
권한 상승이 요청되면 로직 앱은 사람의 쓰인을 필요로 하며
12:27
임시 권한 만료 시간이 시작됩니다.
12:29
관찰 가능성은 본격적인 관리 단계입니다.
12:31
모든 도구 호출은 추적됩니다.
12:33
누가 무엇을 호출했는지, 매개 변수, 지연 시간, 응답 시간 등을 기록합니다.
12:36
감사자는 상관관계 아이디와 함께
12:37
이벤트 기록을 분석 로그에 기록하여
12:39
슬랙에서 데이터를 뒤져보지 않고도
12:41
사건 현장을 재구성할 수 있도록 합니다.
12:42
또한 변경 후 타당성, 관련성, 유창성을 평가하는 단계를 거칩니다.
12:46
타당성이 떨어지면 검토자는 추가적인 파괴적인 작업을 차단하고
12:50
계획을 기획자에게 되돌려 검색 범위를 좁히거나 개선하도록 합니다.
12:53
모델은 위도적으로 혼합하여 사용합니다.
12:55
분류에는 비용과 지연 시간을 낮추기 위해 소규모 모델을 사용합니다.
12:59
오토파일럿 이 한 장치의 이름을 변경했는데
13:00
에이저 AD가 두 장치를 동일한 장치로 인식하는 경우와
13:02
같은 예외적인 상황에서는 GPT-4 미니를 사용하여 추론 경로를 생성합니다.
13:06
요약은 일괄 처리됩니다.
13:07
오후 2시에 쉐익스피어 수준의 장황한 보고서를 작성할 필요는 없으니까요.
13:10
지난주 단일 에이전트 테스트에서 동일한 동적 그룹의 모든 항목을 폐기하여
13:14
오래된 장치를 수정하려고 했습니다.
13:15
다중 에이전트 흐름의 검토자는 범위 불일치를 발견하고
13:18
장치 수준의 확인을 요청한 후 작업을 중단했습니다.
13:20
이것이 바로 계획, 실행, 검토 단계를 분리하는 이유입니다.
13:23
결과적으로 유령 장치로 인한 규정 준수 문제가 해결됩니다.
13:26
라이선스 낭비를 줄이고 오탄을 감소시키며
13:29
실패한 장치를 폐기하는 것이 왜 일상인지 경영진에게 설명할 필요가 없어집니다.
13:37
두번째 데모 시나리오는 제로터치온 보딩입니다.
13:40
말 그대로 제로터치입니다.
13:42
사용자는 아무런 접촉 없이 에이전트가 배정될 때까지
13:44
엔지니어링팀은 500번의 접촉을 거치게 됩니다.
13:46
목표는 인사 담당자의 이벤트부터 사용자가 장치를 바로 사용할 수 있도록 만드는 것입니다.
13:50
인사 담당자가 사용자의 성을 3가지 다른 방식으로 표기하더라도 원활하고
13:53
관리되며 되돌릴 수 있도록 설계합니다.
13:55
팀 구성은 다음과 같습니다.
13:56
접수 담당자는 인사 웹북을 수신하고 페이로드를 표준화하고 필수 필드를 검증합니다.
14:01
프로비저 너는 엔트라의 사용자를 생성하고
14:04
그룹과 라이선스를 할당하고 오토파일럿 프로필을 등록합니다.
14:07
검증자는 새 노트북을 제공하기 전에 정책 준수 및 조건부 액세스 상태를 확인합니다.
14:13
컨시어지는 환영팩, 시어포인트 링크, 그리고 첫날 체크리스트를 전송합니다.
14:18
이제 흐름이 시작됩니다.
14:19
접수 담당자는 인사 담당자의 페이로드, 이름, 시작일, 역할, 부서, 관리자, 지역을 가져옵니다.
14:24
소형 모델은 데이터를 추출하고 정교화합니다.
14:26
표준 필드에 맵핑하고 2099년 시작일과 같은 비정상적인 값을 잡아냅니다.
14:30
필수 필드가 누락된 경우 로직 앱을 통해 구조화된 오류 메시지를 인사팀에 전달합니다.
14:34
프로비저 너는 사용자 권한에 따라 관리되는 아이디를 사용하여 그래프를 호출합니다.
14:38
엔트라 사용자를 생성하고 사용 위치를 설정한 후 기본 그룹을 적용합니다.
14:42
그런 다음 역할과 지역에 따라 라이선스 할당을 구성합니다.
14:45
이 과정에서 논리적 추론이 중요합니다.
14:47
이 사용자는 E5 보안 라이선스가 필요한가요?
14:49
아니면 비즈니스 프리미엄 라이선스가 필요한가요?
14:50
정책을 데이터에 인코딩하고 모델이 허용된 번들 중에서 선택하도록 합니다.
14:53
모델이 임의로 라이선스를 생성할 수 없으며 엄격한 메뉴가 제공됩니다.
14:56
그 다음은 자동 조종 단계입니다.
14:58
프로비저 너는 이미 보유하고 있는 하드웨어 해시를 등록하거나 사용자 그룹에 연결된 적시 프로필을 준비합니다.
15:04
기준 정책에 따라 장치 그룹의 태그를 지정하면 검증기가 작동합니다.
15:08
검증기는 그래프와 디펜더의 규정 준수 신호를 커리하고
15:10
조건부 액세스가 첫 로그인에 영향을 미치지 않는지 확인하고
15:13
올바른 장치 구성 정책이 적용되는지 검사합니다.
15:16
조건부 액세스로 인해 신규 직원이 입사 첫날부터 접근이 차단될 경우
15:19
검증자는 기한이 정해진 예외 사항과 그 이유를 명시하여 승인 요청을 보냅니다.
15:23
컨시어즈는 인적 자원 관련 업무를 처리합니다.
15:25
신규 직원의 UPN, 장치 할당 상태, 시어포인트 시작 키트 링크가 포함된 팀즈 메시지를 관리자에게 전송합니다.
15:32
또한 신규 직원에게 입사 첫날 업무, MFA 설정 안내, IT 포털 위치 등을 이메일로 발송합니다.
15:37
이메일에는 내부 IP 주소 범위를 포함하지 않습니다.
15:40
콘텐츠 안전성 검사는 유출 여부와 어조를 검사합니다.
15:43
거버넌스 역시 동일한 보안 원칙을 따릅니다.
15:46
프로비저 너의 관리 아이디는 라이선스 권한은 있지만 삭제 권한은 없습니다.
15:49
인테이크 담당자는 프로비저닝 권한이 없고 유효성 검사만 수행합니다.
15:51
PM은 사용자를 민감한 그룹에 추가하는 것과 같은 고위험 작업을 승인합니다.
15:55
모든 작업은 앱 인사이트와 로그 분석에 기록됩니다.
15:58
HR에서 수정된 페이로드를 전송하면 플래너가 변경 사항을 재계산하고 운영자는 변경된 내용만 업데이트합니다.
16:03
그룹 멤버십이 자주 변경되는 일은 없습니다.
16:05
관찰 가능성을 통해 주요 마일스톤을 확인할 수 있습니다.
16:08
HR 데이터 수집, 엔트라 생성, 나이선스 할당, 자동 프로필 생성, 규정 준수 판정 알림 전송,
16:14
SLA 지표를 제공하며 일시적인 그래프 오류 발생 시 백오프 기능을 통해 자동 제시도합니다.
16:18
HR 시스템에 오류가 발생하더라도 스레드가 종료되지 않고 일시 중지, 로그 기록 후 오류 수정 후 재개됩니다.
16:24
실제 채용 전에 관련성 및 타당성 관련 문제를 조기에 발견하기 위해 합성운 보딩 페이로드를 사용하여 CI 환경에서 평가를 실행합니다.
16:30
모델 조합을 통해 비용 효율성을 유지합니다.
16:33
SLM을 사용하여 데이터 추출 및 정규화를 수행합니다.
16:35
정책 선택 결정에 대해서만 추론 과정을 거칩니다.
16:38
요약 및 환영 이메일은 가능한 경우 일괄 처리합니다.
16:41
목표는 감사 추적에서 사람이 직접 확인할 수 있는 명확성을 유지하면서 지연 시간을 최소화하는 것입니다.
16:45
간단한 사례, 단일 상담원 온 보딩 시스템에서 사용자가 계약직 직원이라는 제목 때문에 모든 직원 및 계약직 그룹에 추가하려고 했습니다.
16:52
다중 상담원 시스템이 유효성 검사기에서 상호 배타성 규칙을 감지하고 사람의 판단을 요청하여 조건부 액세스 관련 오류를 방지했습니다.
16:59
결과적으로 사용자는 아무런 조작 없이 온 보딩을 경험할 수 있었습니다.
17:02
하나의 스레드, 4명이 에이전트, 깔끔한 승인 절차, 그리고 데모 시연에 대한 부담 없이 CISO에게 보여줄 수 있는 완벽한 문서 기록까지.
17:08
인사팀에서 불가피하게 시작일을 변경하더라도 시스템은 라이선스 예산을 낭비하지 않고 자동으로 재계산합니다.
17:14
세 번째 데모 시나리오는 자동화된 보안 강화입니다.
17:17
비트로커는 활성화되어 있어야 합니다.
17:19
보안 설정 변경은 잡초와 같습니다.
17:21
3개를 뽑으면 5개가 소산하고 그 중 하나는 악의적으로 비트로커를 비활성화합니다.
17:25
우리의 목표는 구성 변경을 지속적으로 감지하고 변호사도 인정할 만한 수준의 보안 조치를 통해 안전하게 해결하는 것입니다.
17:31
캐스트 드리프트 디텍터는 그래프와 디펜더를 커리합니다.
17:34
시큐어 스코어는 인튠 규정 준수 및 장치 구성 기준선을 가져와 변경 차이를 계산합니다.
17:39
픽서는 인튠 정책 변경, 비트로커 설정 및 윈도우즈 업데이트 링을 푸시합니다.
17:44
정책이 충분히 적용되지 않을 경우 에이저 오토메이션을 통해 장치 스크립트를 실행합니다.
17:49
리뷰어는 가이드라인을 준수하고 변경 범위를 지정하고 근거검사를 실행하고 위험한 단계에 대한 사람의 쓰인을 확보합니다.
17:56
메신저는 팀즈 또는 이메일을 통해 담당자에게 간략한 계획과 확인사항을 전달합니다.
18:01
플로우의 드리프트 디텍터는 예약된 일정과 필요에 따라 실행됩니다.
18:05
그래프를 통해 장치 규정 준수, 비트로커 상태, TPM 상태, OS 버전, 업데이트 링 및 정책 할당 정보를 가져옵니다.
18:13
각 장치를 구조화된 데이터, 빕스 문서가 아닌 인 골든 프로파일과 비교합니다.
18:19
비트로커 미적용, 최악한 암호화 방식, 정책 미적용, 보안 부팅 비활성화, 업데이트 링 범위 초과 등의 문제를 태그로 표시합니다.
18:26
플래너 단계에서는 장치 그룹별 최소 계획을 제안합니다.
18:30
비트로커 위 경우 장치가 비트로커를 지원하는 경우 인튠 비트로커 정책을 사용합니다.
18:34
정책이 이미 적용되었지만 상태가 비활성화된 경우 보호 기능을 다시 활성화하고 키를 에이저 AD에 에스크로 하는 자동화 스크립트를 제안합니다.
18:40
업데이트 드리프트의 경우 패치 적용보다는 장치를 단계별 업데이트 링으로 이동하는 것을 제안합니다.
18:46
조건부 액세스 문제의 경우 필요한 근거를 제시하여 기한이 정해진 예외를 제안합니다.
18:52
검토자는 제안의 타당성을 평가합니다.
18:54
드리프트 디텍터가 그래프 및 디펜더 위 필드를 실제로 인용했는지 확인합니다.
18:58
범위, 장치 ID, 정책 ID, 변경 유형을 검사합니다.
19:02
모든 기기에서 공통적으로 문제가 발견되면 무조건 차단됩니다.
19:05
콘텐츠 안전성은 입력과 출력 모드에서 보장되어 외부 정보나 복사된 로그를 통한 무차별적인 삽입을 방지합니다.
19:11
충돌하는 로컬 정책 제거와 같은 고위험 작업은 PM, 프로젝트 관리자, 위스인을 거쳐야 합니다.
19:15
수정 담당자의 신원은 자동으로 노출되지 않습니다.
19:17
승인은 깔끔한 카드 형식의 로직 앱에서 이루어집니다.
19:20
무엇이 잘못되었는지, 무엇이 변경될지 명확하게 제시합니다.
19:22
롤백 단계와 관련 참조 정보를 제공합니다.
19:24
승인 후 수정 담당자가 작업을 실행합니다.
19:25
인튠 정책 업데이트는 항목별로 강력하고 정확하게 적용됩니다.
19:35
456 에스크로 경로를 지원하는지 확인합니다.
19:38
사전검사에 실패할 경우, 사람이 이해하기 쉬운 오류 메시지와 함께 부작용 없이 처리됩니다.
19:42
메신저를 통해 모든 과정이 완료됩니다.
19:44
기기 수정이 완료되면, 팀즈의 수정 내역, 앱인사이트 추적 링크, 그리고 엑셀을 가족보다 더 좋아하는 사용자를 위한 csv 파일이 포함된 요약 보고서가 전송됩니다.
19:52
기기가 정책 준수를 거부할 경우, 검토자는 예외 스레드를 생성하고 제시도 일정을 예약합니다.
19:57
관찰 가능성을 확보하기 위해 모든 도구 호출을 추적하고, 스레드별로 상관관계를 분석합니다.
20:01
감사팀이 kql에 계속 머물지 않고도 규정 미준수와 준수 여부를 확인할 수 있도록 변경 전후의 변경사항을 잠급니다.
20:06
또한 변경 후 요약에 대한 평가 에이전트를 실행하여 근거와 명확성을 확인합니다.
20:11
근거가 떨어지거나 실패율이 급증하면 플래너는 검색 범위를 좁히거나 배치 크기를 줄이거나 파괴적인 작업을 일시 중지합니다.
20:18
추출 및 분류에는 slm 모델을, 계획 합성에는 필요한 경우 m1 추론 모델을 혼합하여 사용합니다.
20:23
야간 보고서를 일괄 처리합니다.
20:24
ai에 대한 장황한 설명은 필요 없습니다.
20:26
최종 결과는 비트로커가 실제로 활성화되어 있다는 것입니다.
20:28
업데이트링의 드리프트가 줄어듭니다. 예외사항은 문서화되고 기한이 정해져 있으며 검토 가능합니다.
20:32
그리고 분기마감 시 재무 담당자의 노트북을 재설치하여 문제를 해결하는 일은 없습니다.
20:36
아키텍처는 파운드리, 시멘틱 커널, 도구, 아이덴티티로 구성됩니다.
20:41
할당량에 영향을 주지 않고 내부 구조를 살펴보겠습니다.
20:44
이 모든 것을 합리적으로 유지하는 4가지 계층, 즉 파운드리, 시멘틱 커널, 도구, 아이덴티티를 생각해보세요.
20:50
파운드리는 핵심 기반입니다.
20:52
엄격한 지침으로 에이전트를 정의하고, 역할별로 배포를 선택하고, 에이저 AI 검색을 통해 지식을 연결하고 작업을 등록합니다.
20:59
개방형 API 도구, 로직 앱, 함수, 그래프, 에이저 자동화, 코드 인터프리터를 활용합니다.
21:05
위협, 실행 기록, 추적, 평가 및 안전성이 모두 여기에 포함됩니다.
21:09
콘텐츠 안전성 프롬프트 보호장치와 보호 대상 자료 검사는 모델 실행 전후에 실행되어 잘못된 입력으로 인해 토큰이 소모되거나 잘못된 출력으로 인해 작업이 중단되는 것을 방지합니다.
21:16
시멘틱 커널, SK, 이 모든 것을 제어합니다. 코드에서는 플래너, 운영자, 검토자 루프를 연결합니다.
21:22
도구에 대한 함수 카탈로그를 등록하고, 제시도 기능을 해제하고, 취소 토큰을 추가합니다.
21:27
프롬프트는 간결하게 유지하고, 복잡성은 스키마에 포함시켜 SK가 가용성과 정책에 따라 호출할 도구를 결정하도록 합니다.
21:33
그래프 시간 초과가 발생하면 SK는 Z 터링으로 처리합니다.
21:36
접지도가 떨어지면 플래너로 돌아가 개선합니다.
21:39
도구는 실행 도구의 역할을 합니다.
21:40
개방형 API를 사용하여 계약을 엄격하게 관리합니다.
21:43
API 관리를 통해 버전 관리 및 회로 차단을 구현합니다.
21:46
로직 앱은 승인 및 장기 실행 흐름을 처리하고, 함수는 연결 및 변환 작업을 수행합니다.
21:51
에이저 자동화는 가이드라인과 사후 검사를 통해 스크립트를 실행합니다.
21:54
그래프는 인튠, 엔트라, 규정 준수 및 보안 점수에 대한 핵심 정보 소스입니다.
21:58
에이저 AI 검색은 도메인별로 선별된 지식을 제공합니다.
22:01
정보가 뒤죽박죽이 되는 일이 없습니다.
22:03
아이디는 안전장치와 같습니다.
22:04
각 에이전트는 고유한 관리 아이디를 갖습니다.
22:06
모니터링 에이전트는 읽기 권한을, 복구 에이전트는 쓰기 권한을 가지며 관리자 권한은 부여되지 않습니다.
22:10
PM은 파괴적인 작업을 차단합니다.
22:12
권한 상승은 사람의 쓰인을 필요로 하며 만료됩니다.
22:15
데이터 경계가 중요한 프라이빗 엔드포인트를 사용합니다.
22:17
파운드리 프로젝트의 정책 기준서는 허용된 모델, 지역 및 탈당량을 적용합니다.
22:22
앱 인사이트 및 로그 분석은 추적, 매트릭 및 감사를 수집하여 슬랙에서 데이터를 찾아 헤맬 필요 없이 누가 무엇을 했는지 파악할 수 있도록 지원합니다.
22:28
모델은 파운드리 위 추론 엔드포인트를 통해 연결할 수 있습니다.
22:31
고급 추론에는 서버리스를 사용하고, 고정된 오픈모델에는 관리형 컴퓨팅을 사용할 수 있습니다.
22:36
코드를 다시 작성하지 않고도 모델을 교체할 수 있지만, 배포하기 전에 CI에서 관련성, 타당성 및 유창성을 평가할 수 있습니다.
22:42
지역은 사용자와 일치하고, 데이터 영역은 규제기관과 일치합니다.
22:45
이 모든 것을 종합하면 지루해 보일지 몰라도 안정적인 시스템이 됩니다.
22:48
파운드리에서 정의되고, SK가 오케스트레이션하며, 엄격한 도구로 구동되고, 신원 확인으로 보호되고, 관찰 가능성으로 측정되고, 안전으로 보호되는 에이전트.
22:56
지루함이 승리합니다.
22:57
지루함은 확장성이 뛰어납니다.
22:59
지루함은 당신이 잠을 잘 수 있게 해줍니다.
23:01
모범 사례는 후회 없이 배포됩니다.
23:02
알겠죠?
23:03
토요일에 일을 망치지 않도록 시간관리 능력을 키우세요.
23:06
각 에이전트에게 하나의 업무만 부여하세요.
23:08
기획자는 계획하고, 운영자는 운영하며, 검토자는 검토합니다.
23:11
에이전트가 장황한 소설을 쓰기 시작하면, 그 부분을 삭제하고 도구에 넘겨주세요.
23:15
지침은 간결하고, 범위가 명확하며, 지루하게 유지하세요.
23:17
그러면 예상치 못한 일이 줄어듭니다.
23:19
긴 글보다는 도구 호출을 선호하세요.
23:21
계약은 공개 API에, 스키마는 입력에, 가드레일은 출력에 명시하세요.
23:24
도구가 특정 장치를 요구하면, 아마도 이 금융회사의 장치 읽어봅니다.
23:27
라고 말하지 말고, 바로 그 장치를 보내세요.
23:29
모델은 창의적이지만 도구는 그렇지 않습니다.
23:31
바로 그 점입니다.
23:32
당신의 업무가 달려있는 것처럼 최소 권한 원칙을 철저히 준수하세요.
23:35
신원을 분리하세요.
23:36
모니터링 담당자는 읽기 전용, 복구 담당자는 쓰기 전용으로 하고,
23:39
PM 없이는 어떤 신원도 삭제 권한을 갖지 못하도록 하세요.
23:41
권한 상승은 일시적이고, 정당한 이유가 있으며, 기록됩니다.
23:43
누군가 연구적인 글로벌 관리자 자리를 요청하면, 스트레스볼과 정책 문서를 건네주세요.
23:47
처음에는 소규모로 시작하세요.
23:48
실행자와 검토자, 이렇게 두 명이 담당자로 시작하세요.
23:50
시스템이 안정화되면, 계획 담당자를 추가하세요.
23:52
그리고 규모를 확장해야 한다면, 처음부터 12명 규모의 디지털 스크럼팀을 만들지 마세요.
23:55
그렇게 하면 YAML로 조직도를 다시 그려야 하고, 후회하게 될 겁니다.
23:57
비용을 절감하기 위해 다양한 모델을 활용하세요.
23:59
SLM은 데이터 추출에, GPT4 클래스는 중요한 추론에만 사용하세요.
24:02
요약은 일괄 처리로 밤새 도록 진행하세요.
24:04
날짜 문자열 형식을 지정하는데, 추가 비용을 지불할 필요는 없습니다.
24:07
무거운 모델은 의사결정에 사용하고, 설명에는 사용하지 마세요.
24:10
메모리는 가장 나중에 추가하세요.
24:11
AI 검색에는 외부 상태를 사용하거나,
24:14
컨텍스트 창을 기내용 가방처럼 가득 채우기 전에 작은 상태 저장소를 활용하세요.
24:17
스레드 메타 데이터는 아주 작아야 합니다.
24:19
다음 턴에 필요하지 않으면 삭제하세요.
24:21
모든 것을 기록하세요.
24:22
추적 기능을 활성화하세요.
24:24
스레드 아이디, 도구 매개 변수, 지연 시간 결과 등을 기록하세요.
24:26
프로덕션 환경보다 먼저 관련성 및 파당성 저하를 감지할 수 있도록
24:29
CI 환경에 평가를 배포하세요.
24:31
트위터가 반응할 때가 아니라, 안정성이 떨어질 때 알림을 보내세요.
24:34
속도보다 안전장치를 우선시하고, 파괴적인 도구 사용에 대한 쓰인을 받으세요.
24:36
부작용 없는 사전 테스트 모드를 활용하세요.
24:39
기기 그룹 또는 지역별로 단계적으로 배포하세요.
24:41
만약 모든 것을 한 번에 배포하려는 계획이라면, 이력서를 업데이트하셨기를 바랍니다.
24:49
상호 배타성 규칙, 라이선스 번들, 기기 기준선 등을 구조화된 형태로 저장하세요.
25:00
모델은 선택할 수는 있지만, 만들어내서는 안 됩니다.
25:03
이것이 에이전트를 유용하게 유지하고, 영향 범위를 최소화하는 방법입니다.
25:06
한 가지 기억해야 할 것은, 개별 에이전트도 도움이 되지만,
25:10
계획적이고 도구 중심적이며, 권한 범위가 지정된 에이전트팀은
25:13
당신이 자는 동안 조용히 환경을 변화시킨다는 것입니다.
25:15
이 내용이 마음에 와 닿았다면 구독하고,
25:17
제가 시멘틱 커널 저장소와 이두근 템플릿을 공개하는 후속 영상을 시청하세요.
25:21
마음껏 뵙겨 쓰셔도 좋습니다.
25:22
평가 담당자들이 약속을 지키는 모습을 담은 에피소드를 원하시나요?
25:25
다음 주에 공개될 예정입니다.