WEBVTT 00:00:00.000 --> 00:00:03.720 팟캐스트에서 에이저 AI 파운드리 가 함정이라고 해서 클릭하셨죠. 00:00:03.820 --> 00:00:05.960 잘 하셨습니다. 제대로 찾아오셨네요. 00:00:06.240 --> 00:00:07.620 먼저 약속부터 하나 하죠. 00:00:07.780 --> 00:00:09.620 코파일럿은 근거 없이는 무너지지만 00:00:09.620 --> 00:00:14.740 검색 증강 생성, RAG, 이나 에이저 AI 검색의 하이브리드 및 시멘틱 기능 00:00:14.740 --> 00:00:19.260 그리고 근거성, 관련성, 일관성을 검증하는 평가 도구들을 활용하면 00:00:19.260 --> 00:00:22.060 답변으로 의장한 환각을 배포하는 일을 막을 수 있습니다. 00:00:22.300 --> 00:00:24.100 마케팅용 발표 자료는 건너뛰고 00:00:24.100 --> 00:00:26.980 현장의 실제 사례가 담긴 생존 전략을 보여드리겠습니다. 00:00:26.980 --> 00:00:32.000 M365 쇼뉴스레터를 구독하고 MVP들이 진행하는 라이브 스트림을 팔로우하세요. 00:00:32.240 --> 00:00:34.400 그곳에 실전 경험과 해결책이 있습니다. 00:00:34.680 --> 00:00:38.460 멀티모달 앱에서 가장 먼저 문제가 발생하니 거기서부터 시작하겠습니다. 00:00:38.780 --> 00:00:41.340 현실 세계에서 멀티모달 앱이 실패하는 이유 00:00:41.340 --> 00:00:44.420 무대 위에서 멀티모달 데모를 보면 완벽해 보이죠. 00:00:44.640 --> 00:00:46.900 발표자가 텍스트 프롬프트와 깔끔한 이미지 00:00:46.900 --> 00:00:51.200 때로는 음성 입력을 넣으면 모델이 완벽한 차트나 정교한 계약 요약을 내놓습니다. 00:00:51.440 --> 00:00:54.580 마법처럼 느껴지지만 실제 기업 환경에서 똑같이 시도하는 순간 00:00:54.580 --> 00:00:56.000 그 환상은 금방 깨집니다. 00:00:56.000 --> 00:00:57.980 데모는 깨끗한 입력 데이터로 실행됩니다. 00:00:58.160 --> 00:01:00.020 실제 업무 환경은 엉망인 데이터로 돌아가죠. 00:01:00.160 --> 00:01:01.520 그게 핵심적인 차이입니다. 00:01:01.740 --> 00:01:04.900 운영 환경에서는 누구도 모델에 잘 정리된 스크린샷이나 00:01:04.900 --> 00:01:07.260 표준화된 csv 파일을 주지 않습니다. 00:01:07.520 --> 00:01:10.000 인사팀은 흐릿한 신분증 사본을 입력하고요. 00:01:10.140 --> 00:01:13.540 구매팀은 팩스로 5번은 복사된 듯한 pdf를 가져옵니다. 00:01:13.740 --> 00:01:17.380 재무팀 누군가는 깨진 안드로이드 카메라로 송장 사진을 찍어올리죠. 00:01:17.560 --> 00:01:20.780 멀티모달 모델은 텍스트, 이미지, 음성, 비디오를 처리할 수 있지만 00:01:20.780 --> 00:01:24.500 복잡한 상황에서 제대로 작동하려면 잘 새견된 데이터와 검색 기능이 필요합니다. 00:01:24.640 --> 00:01:27.920 그렇지 않으면 모델에게 쓰레기 같은 데이터를 가지고 즉흥 연기를 시키는 꼴이 됩니다. 00:01:28.120 --> 00:01:31.340 gpu에 아무리 많은 돈을 써도 쓰레기를 넣으면 쓰레기가 나올 뿐입니다. 00:01:31.520 --> 00:01:35.120 이때 여러분을 구해줄 것이 바로 검색 증강 생성, 아레이지, 입니다. 00:01:35.340 --> 00:01:38.980 쉽게 말해 모델은 여러분의 비즈니스를 모르니 지식 소스에 연결하는 것입니다. 00:01:39.180 --> 00:01:41.980 데이터의 일부분을 검색하고 그에 맞춰 답변을 구성하는 거죠. 00:01:42.180 --> 00:01:45.040 데이터가 정확하게 일치하면 유용하고 근거 있는 답변을 얻게 됩니다. 00:01:45.040 --> 00:01:48.620 엄성하면 모델은 제멋대로 추측하며 자신있게 헛소리를 늘어놓습니다. 00:01:48.800 --> 00:01:53.840 그래서 책보시 존재하지도 않는 3분기 할인 정책이 있다고 우기는 일이 벌어지는 겁니다. 00:01:54.160 --> 00:01:57.680 모델이 자아를 가진 게 아니라 그저 잘못된 데이터를 가져온 것 뿐이죠. 00:01:57.880 --> 00:02:01.060 에이저 AI 스튜디오와 에이저 AI 파운드리는 모두의 패턴을 기반으로 하며 00:02:01.060 --> 00:02:05.000 언어, 시각, 음성, 심지어 비디오 검색까지 모든 유형의 모달리티를 지원합니다. 00:02:05.200 --> 00:02:08.060 하지만 문제는 아레이지 도 데이터가 좋아야만 성능이 나온다는 것입니다. 00:02:08.240 --> 00:02:10.140 대부분의 팀이 놓치는 핵심이 바로 여기 있습니다. 00:02:10.420 --> 00:02:13.020 검색 방식 하나만 연결해두고 다 되었다고 생각해서는 안 됩니다. 00:02:13.020 --> 00:02:16.460 결과를 일관성 있게 유지하려면 에이저 AI 서치에 내장된 시멘틱 제순위 지정, 00:02:16.660 --> 00:02:19.740 시멘틱 리랭커, 기능을 갖춘 하이브리드 키워드 및 벡터 검색이 필요합니다. 00:02:19.880 --> 00:02:23.200 이를 통해 시스템은 문자 그대로의 키워드 적중률과 시멘틱 의미의 균형을 맞추고 00:02:23.200 --> 00:02:25.940 올바른 컨텍스트가 상단에 배치되도록 결과를 재정렬할 수 있습니다. 00:02:26.120 --> 00:02:30.400 멀티모달 설정에 이를 도입하면 모델은 규정 준수 정책을 마음대로 지어내는 대신 00:02:30.400 --> 00:02:33.640 구겨진 스캔 문서 나흐리탄 이미지도 정확히 처리할 수 있게 됩니다. 00:02:33.640 --> 00:02:36.980 이제 왜 많은 도입 시도가 실패로 돌아가는지 이야기해보겠습니다. 00:02:37.320 --> 00:02:42.180 기업들은 첫날부터 완벽한 결과를 기대하지만 평가 루프에 대한 예산은 책정하지 않습니다. 00:02:42.380 --> 00:02:45.700 기반 타당성, 관련성, 일관성을 확인하는 배경작업이 없으면 00:02:45.700 --> 00:02:48.460 사용자가 피해를 보기 전까지는 오류를 알아차리지 못합니다. 00:02:48.640 --> 00:02:51.180 많은 초기 배포가 바로 이런 이유로 빠르게 실패합니다. 00:02:51.380 --> 00:02:54.780 출력물은 그럴듯해 보이지만 아무도 원천 데이터와 대조하여 검증하지 않았기 때문입니다. 00:02:54.940 --> 00:02:55.380 생각해보세요. 00:02:55.680 --> 00:02:58.220 모니터링 없이 새로운 데이터베이스를 배포하는 사람은 아무도 없을 것입니다. 00:02:58.220 --> 00:03:03.100 그런데도 멀티모달 AI는 마치 플러그 앤 플레이 마법 상자인 것처럼 임원들이 바로 프로덕션에 던져넣습니다. 00:03:03.260 --> 00:03:04.980 반드시 실패로 끝날 필요는 없습니다. 00:03:05.300 --> 00:03:08.300 카바나는 이 점을 입증하는 파운드리 고객 사례 중 하나입니다. 00:03:08.500 --> 00:03:11.440 그들은 검색 기능을 조정하고 에이전트의 기반을 적절히 다지며 00:03:11.440 --> 00:03:15.220 관찰 가능성에 투자하여 셀프 서비스 AI를 실제로 유용하게 만들었습니다. 00:03:15.440 --> 00:03:19.620 그 덕분에 단순한 장난감 같은 보시 고객이 신뢰할 수 있는 도구로 변모했습니다. 00:03:20.020 --> 00:03:25.540 이제 기반 타당성 검사 나평가 없이 일반 책봇을 지원 페이지에 붙이기만 한 기업들의 사례와 비교해보십시오. 00:03:25.540 --> 00:03:28.680 결과는 이미 보셨을 겁니다. 보증 청구가 영업 리드로 잘못 분류되고 00:03:28.680 --> 00:03:31.220 지원 대기열은 꽉 차며 기업의 신뢰도는 바닥으로 떨어집니다. 00:03:31.360 --> 00:03:33.500 같은 에이저 스택을 사용했지만 결과는 정반대입니다. 00:03:33.680 --> 00:03:35.380 자, 냉정한 결론을 말씀드리겠습니다. 00:03:35.660 --> 00:03:38.580 멀티모달이 붕괴하는 것은 AI가 충분히 똑똑하지 않아서가 아닙니다. 00:03:38.760 --> 00:03:42.200 데이터가 준비되지 않았거나 인덱싱 되지 않았거나 모니터링 되지 않기 때문에 붕괴하는 것입니다. 00:03:42.400 --> 00:03:46.220 검색 시스템에 쓰레기 데이터를 넣고 평가를 건너뛰면 신뢰가 무너지는 것을 보게 될 것입니다. 00:03:46.220 --> 00:03:56.140 하지만 하이브리드 검색, 시멘틱 재순위 지정, 지속적인 평가 실행을 활용하면 송장, 계약서, 사진, 심지어 거친 오디오 메모까지 처리하여 허구가 아닌 현실에 기반한 답변을 얻을 수 있습니다. 00:03:56.360 --> 00:03:59.380 기반 타당성이 확보되면 또 다른 위험이 보이기 시작합니다. 00:03:59.600 --> 00:04:04.280 데이터 파이프라인이 깨끗하더라도 그것을 구동하는 시스템 자체가 통제를 이룰 수 있기 때문입니다. 00:04:04.480 --> 00:04:05.760 여기서 질문이 바뀝니다. 00:04:05.760 --> 00:04:11.680 이 모든 것을 조정하는 에이전트가 실제로 비즈니스에 도움이 되고 있을까요? 아니면 IT 예산을 조용히 낭비하고 있을 뿐일까요? 00:04:11.840 --> 00:04:14.660 도움이 되는 에이전트일까요? 아니면 비싼 문진에 불과할까요? 00:04:14.800 --> 00:04:17.920 에이전트는 모델, 데이터, 트리거, 작업을 조정합니다. 00:04:18.080 --> 00:04:21.020 자동화된 워크플로우를 위한 교통경찰관이라고 생각하십시오. 00:04:21.140 --> 00:04:26.540 때로는 원활하게 지휘하다가도 때로는 덤프트럭 3대와 광대차를 들여보낸 뒤 점심 먹으러 가버리기도 합니다. 00:04:26.720 --> 00:04:30.720 깔끔한 정의와 지저분한 현실 사이에 그 간극에서 대부분의 팀이 미끄러집니다. 00:04:30.720 --> 00:04:32.940 서류상으로 에이전트는 완벽해 보입니다. 00:04:35.760 --> 00:04:39.160 서프로세스를 실행하고 답을 찾으며 워크플로우까지 시작해야 합니다. 00:04:39.340 --> 00:04:41.060 하지만 완벽한 동료는 아닙니다. 00:04:41.280 --> 00:04:47.740 새벽 2시에 반복적인 문제를 해결할 수도 있지만 오류로그를 잘못 읽어 대기열을 수백 개의 가짜 티켓으로 뒤덮어버릴 수도 있으니까요. 00:04:47.900 --> 00:04:49.700 서비스나워 안의 상황을 상상해보세요. 00:04:50.000 --> 00:04:55.060 범위를 잘 설정하면 에이아이는 진짜 문제에 대해서만 티켓을 생성해 사람들의 시간을 아껴줍니다. 00:04:55.300 --> 00:05:00.340 하지만 방치하면 멀쩡한 프린터에 치명적인 오류가 발생했다는 가짜 알람으로 헬프데스크를 마비시킬 수 있죠. 00:05:00.340 --> 00:05:02.980 CIO에게 생산성이 향상되었다고 설명해보세요. 00:05:03.180 --> 00:05:04.940 많은 사람이 놓치는 중요한 차이가 있습니다. 00:05:04.940 --> 00:05:06.780 코파일럿과 에이전트는 서로 다릅니다. 00:05:06.960 --> 00:05:09.100 코파일럿은 기본적으로 질문에 답해주는 도우미입니다. 00:05:09.260 --> 00:05:11.860 사용자가 질문하고 답을 얻으며 통제권은 사용자에게 있죠. 00:05:12.040 --> 00:05:14.940 반면 에이전트는 사용자를 기다리지 않고 스스로 판단합니다. 00:05:15.140 --> 00:05:18.760 결과가 말도 안 되는 상황에서도 모호한 지침을 문자 그대로 따르죠. 00:05:18.940 --> 00:05:24.240 그 지점에서 자동화는 시간을 절약해주기도 하고 수습하는데 2배의 시간이 걸리는 혼란을 초래하기도 합니다. 00:05:24.420 --> 00:05:28.200 많은 팀이 에이전트에게 선거 공약 같은 직무 기술서를 주는 게 문제입니다. 00:05:28.420 --> 00:05:31.720 프로세스를 최적화하고 통찰력을 제공하고 사람들을 돕겠다고 말이죠. 00:05:31.880 --> 00:05:32.340 축하합니다. 00:05:32.340 --> 00:05:34.360 보색의 마음대로 날뛰라고 허락하신 겁니다. 00:05:34.580 --> 00:05:36.820 범위가 정해지지 않은 에이전트는 자기 할 일만 하지 않습니다. 00:05:37.000 --> 00:05:38.000 마구잡이로 일을 벌이죠. 00:05:38.200 --> 00:05:39.660 해결해야 할 문제를 스스로 만들어냅니다. 00:05:39.840 --> 00:05:40.980 레코드를 중복 생성합니다. 00:05:41.180 --> 00:05:42.420 끝도 없이 루프에 빠집니다. 00:05:42.620 --> 00:05:45.600 그러고는 경영진이 왜 멋진 데모가 운영상의 고통으로 변했는지 위하이합니다. 00:05:45.820 --> 00:05:47.220 이제 진실을 바로 잡아봅시다. 00:05:47.420 --> 00:05:49.980 대부분의 조직이 두 달 안에 실패하는 것은 아닙니다. 00:05:50.200 --> 00:05:51.900 그런 연구 결과는 어디에도 없습니다. 00:05:51.900 --> 00:06:00.180 실제로 빠르게 일어나는 일은 에이전트의 범위를 좁히지 않고 검증 단계와 모니터링 체계를 갖추지 않아 조기의 난관에 봉착하는 것입니다. 00:06:00.380 --> 00:06:04.700 안전장치 없는 그럴듯한 신규 도구는 관리자 권한을 가진 무모한 인턴일 뿐입니다. 00:06:04.900 --> 00:06:08.060 여기서 마이크로소프트 스택이 필요한 핵심 도구들을 제공합니다. 00:06:08.300 --> 00:06:13.780 코파일러 스튜디오는 플로우, 프론프트, 이벤트 트리거 등을 설계하는 로우코드 플랫폼입니다. 00:06:13.780 --> 00:06:20.060 그리고 에이저 AI 파운드리 위 에이전트 서비스는 해당 에이전트를 모니터링 가능한 상태로 배포하는 엔터프라이즈 기반입니다. 00:06:20.220 --> 00:06:23.940 에이전트 서비스를 통해 모니터링, 로그, 매트릭을 추가할 수 있습니다. 00:06:24.200 --> 00:06:31.480 마이크로소프트는 검증되지 않은 에이전트를 현장에 투입했을 때 어떤 일이 벌어지는지 알기에 인간의 감독이 포함된 자동화 범위를 위도적으로 설계했습니다. 00:06:31.760 --> 00:06:34.500 그렇다면 에이전트가 정말 유용한지 어떻게 알 수 있을까요? 00:06:34.680 --> 00:06:36.320 냉정한 체크리스트로 확인해보세요. 00:06:36.600 --> 00:06:40.740 첫째, 사람의 업무 시간을 줄여주나요? 아니면 직원을 디버깅 작업에 매달리게 만드나요? 00:06:40.740 --> 00:06:47.340 둘째, 근거성, 유창성, 일관성 같은 지표를 측정하고 있나요? 아니면 그저 보기 좋은 마케팅 대시보드만 바라보고 있나요? 00:06:47.460 --> 00:06:52.060 셋째, 사용자의 불만이 접수되기 전에 편향을 포착할 수 있는 원격 측정 시스템을 갖추고 있나요? 00:06:52.220 --> 00:06:55.480 만약 이 중 하나라도 제대로 답하지 못했다면 당신은 지능형 에이전트를 보유한 게 아닙니다. 00:06:55.640 --> 00:06:57.600 그저 비싼 화면 보호기를 쓰고 있는 셈이죠. 00:06:57.800 --> 00:07:02.080 해결책은 에이저 AI 파운드리 위 관측성 기능과 내장 평가 도구를 활용하는 것입니다. 00:07:02.340 --> 00:07:03.860 이것들은 선택사항이 아닙니다. 00:07:04.040 --> 00:07:08.060 근거성, 관련성, 일관성, 그리고 원본에 대한 정확성을 측정하는 검증된 방법입니다. 00:07:08.060 --> 00:07:12.940 이런 도구가 없다면 에이전트가 정말 똑똑한지 아니면 그저 공손한 말투로 거짓말을 지어내는지 추측만 할 뿐입니다. 00:07:13.060 --> 00:07:16.480 도구를 사용하면 출력값이 벗어날 때 자신있게 개입하고 미세 조정할 수 있습니다. 00:07:16.700 --> 00:07:17.180 그렇습니다. 00:07:17.440 --> 00:07:19.420 에이전트는 판도를 바꿀 수 있는 게임 체인저입니다. 00:07:19.620 --> 00:07:23.200 범위를 잘못 설정하면 에이전트는 시간을 절약하기보다 오히려 낭비하게 만드는 혼란의 증폭기가 됩니다. 00:07:23.400 --> 00:07:26.760 명확한 업무 경계, 실제 원격 측정, 근거 기반의 답변으로 범위를 잘 잡으면 00:07:26.760 --> 00:07:29.740 사람이 더 가치 있는 일에 집중하는 동안 에이전트가 업무를 처리할 수 있습니다. 00:07:29.740 --> 00:07:33.220 이제 균형을 잘 잡았다고 생각할 때쯤 상황은 다시 바뀝니다. 00:07:33.420 --> 00:07:37.920 마이크로소프트는 이미 사용자를 기다리지 않고 스스로 행동하는 자율 에이전트를 추진하고 있습니다. 00:07:38.160 --> 00:07:42.720 이는 단순히 도움이 되느냐 무용지물이냐의 문제를 넘어 완전히 다른 차원의 위험성을 의미합니다. 00:07:42.920 --> 00:07:46.100 아무도 지켜보지 않을 때도 시스템이 스스로 돌아가기 때문이죠. 00:07:46.280 --> 00:07:47.740 자율 에이전트의 함정 00:07:47.740 --> 00:07:51.060 자율 에이전트는 과장된 기대가 위험으로 변하는 지점입니다. 00:07:51.420 --> 00:07:53.100 이론상으로는 꿈만 같은 이야기죠. 00:07:53.300 --> 00:07:58.580 AI가 대신 행동하게 하고 반복 업무를 자동화하여 새벽 2시에 티켓 대기열을 처리하느라 침대에서 끌려 나오지 않아도 됩니다. 00:07:58.780 --> 00:08:00.480 이사회에서 듣기엔 아주 훌륭한 말입니다. 00:08:00.640 --> 00:08:01.540 함정은 간단합니다. 00:08:01.760 --> 00:08:02.940 이들은 허락을 기다리지 않습니다. 00:08:03.100 --> 00:08:04.580 코파일럿은 사용자를 위해 잠시 멈춥니다. 00:08:04.740 --> 00:08:06.100 하지만 자율 에이전트는 그렇지 않습니다. 00:08:06.280 --> 00:08:09.480 에이전트가 잘못된 판단을 내리면 피해는 즉각적으로 발생하고 테넌트 전반으로 확산됩니다. 00:08:09.640 --> 00:08:10.860 개념 자체는 매우 쉽습니다. 00:08:11.020 --> 00:08:12.240 코파일럿은 반응형입니다. 00:08:12.460 --> 00:08:13.620 에이전트는 선제적입니다. 00:08:13.620 --> 00:08:20.580 누군가 프롬프트를 입력할 때까지 조용히 기다리는 대신 에이전트가 서비스 상태를 감시하고 보안 신호를 처리하거나 워크플로우를 자동으로 실행하도록 범위를 설정하는 것입니다. 00:08:20.920 --> 00:08:25.640 마이크로소프트는 이를 효율성, 인정 낭비 감소, 더 빠른 탐지, 더욱 원활한 운영으로 홍보합니다. 00:08:25.820 --> 00:08:28.720 그 약속은 사실이지만 중요한 맥락을 놓치지 마세요. 00:08:28.920 --> 00:08:32.160 오늘날 코파일럿 스튜디오 위 자율 에이전트는 아직 프리뷰 단계에 있습니다. 00:08:32.460 --> 00:08:36.500 프리뷰라는 것이 작동하지 않는다는 뜻은 아니지만 복잡한 현실 세계에서 검증되지 않았다는 의미입니다. 00:08:36.500 --> 00:08:42.300 마이크로소프트조차도 광범위하게 배포하기 전에 수명주기 거버넌스 가이드라인과 코파일럿 콘솔 시스템을 먼저 구축해야 한다고 말합니다. 00:08:42.440 --> 00:08:43.920 현실적인 위험을 고려해보세요. 00:08:44.200 --> 00:08:48.540 자율 헬프데스크 에이전트를 만들고 로그인 이상 징후에 대응할 권한을 부여했다고 가정해봅시다. 00:08:48.720 --> 00:08:51.360 5명이 사용자를 대상으로 한 데모에서는 완벽하게 작동합니다. 00:08:51.540 --> 00:08:53.100 알림이 울리고 계정이 관리되죠. 00:08:53.280 --> 00:08:55.940 하지만 실제 운영 환경에서는 노이즈가 섞인 데이터가 들어옵니다. 00:08:56.100 --> 00:09:00.300 대기하는 대신 잘못된 탐지로 수백 개의 계정을 일괄 초기화하기 시작합니다. 00:09:00.560 --> 00:09:02.600 결과는 가상의 중단 사태가 아닙니다. 00:09:02.820 --> 00:09:04.900 실제로 월말 업무를 마비시킬 수도 있습니다. 00:09:05.240 --> 00:09:06.820 이것은 공상과학 소설이 아닙니다. 00:09:07.020 --> 00:09:09.440 범위 설정을 건너뜰 때 감수해야 하는 실패 방식입니다. 00:09:09.640 --> 00:09:11.320 해결책은 기술을 버리는 것이 아닙니다. 00:09:11.320 --> 00:09:13.000 먼저 안전망을 구축하는 것입니다. 00:09:13.180 --> 00:09:14.940 그렇다면 생존 체크리스트는 무엇일까요? 00:09:15.100 --> 00:09:17.320 화려한 자동화 이전에 반드시 해야 할 세 가지가 있습니다. 00:09:17.540 --> 00:09:19.580 첫째, 아이디 및 액세스 범위 설정입니다. 00:09:19.780 --> 00:09:22.800 에이전트에게 최소한의 권한만 부여하고 포괄적인 관리자 역할은 주지 마십시오. 00:09:22.900 --> 00:09:24.480 둘째, 로깅 및 롤백입니다. 00:09:24.700 --> 00:09:26.900 모든 작업에는 감사 가능한 기록이 남아야 합니다. 00:09:27.120 --> 00:09:30.520 그리고 중요한 모든 작업에는 에이전트가 오작동할 때를 대비한 복구 경로가 필요합니다. 00:09:30.680 --> 00:09:32.620 셋째, 콘텐츠 및 동작 필터입니다. 00:09:33.080 --> 00:09:36.600 마이크로소프트는 이를 에이저 AI 콘텐츠 안전 및 지식 구성으로 강조합니다. 00:09:36.600 --> 00:09:41.200 의욕적인 보시 부적절한 답변을 생성하거나 설정된 범위를 벗어나지 않도록 막는 필터입니다. 00:09:41.380 --> 00:09:45.140 이것을 먼저 수행하지 않으면 에이전트의 영리함이 오히려 업무를 망치게 될 것입니다. 00:09:45.340 --> 00:09:47.440 윤리적 측면에서 이는 더욱 중요해집니다. 00:09:47.640 --> 00:09:50.260 HR 에이전트가 직원을 위험인물로 자동 표시하거나 00:09:50.260 --> 00:09:54.800 재무 에이전트가 사기로 오분류하여 공급업체 대금 지급을 보류하는 상황을 상상해보십시오. 00:09:54.940 --> 00:09:59.180 이는 무해한 결함이 아니라 법적 및 규정 준수 문제를 야기하는 인적 영향 실패입니다. 00:09:59.400 --> 00:10:04.400 학습 데이터 나 검색의 편향은 엔터프라이즈 프리뷰 환경에서 실행된다고 해서 사라지지 않습니다. 00:10:04.400 --> 00:10:08.260 필터, 점검, 인간의 개입 없이 판단을 맡기는 것은 변호사들이 절대 원치 않는, 00:10:08.540 --> 00:10:10.780 감독되지 않는 알고리즘에 의한 판단을 외주주는 것과 같습니다. 00:10:11.060 --> 00:10:14.040 이그나이트에서 마이크로소프트의 메시지는 이 점에 대해 단호했습니다. 00:10:14.040 --> 00:10:19.660 가드레일, 수명 주기 관리, 모니터링, 코파일럿 제어 시스템은 있으면 좋은 것이 아니라 필수적인 요소입니다. 00:10:19.800 --> 00:10:24.380 오늘날의 프리뷰는 화려한 데모보다는 테스터들이 어디에 허점이 있는지 증명하는 과정에 가깝습니다. 00:10:24.580 --> 00:10:27.520 단계별 테스트, 승인 워크플로우, 감사 없이 실무에 도입한다면 00:10:27.520 --> 00:10:31.320 그것은 에이전트를 운영하는 것이 아니라 프로덕션 환경에서 스트레스 테스트를 하는 것입니다. 00:10:31.500 --> 00:10:33.720 그렇기에 관측 가능성은 선택사항이 아닙니다. 00:10:33.900 --> 00:10:35.260 에이전트의 모든 단계를 보여주고, 00:10:35.620 --> 00:10:39.820 결과물이 정책에 근거하고 관련성이 있으며 일관성이 있는지 확인하는 대시보드가 필요합니다. 00:10:39.820 --> 00:10:42.360 그리고 휴먼인 더 룩, 인간 개입 옵션이 필요합니다. 00:10:42.620 --> 00:10:44.260 마이크로소프트도 이를 숨기지 않습니다. 00:10:44.460 --> 00:10:47.220 그들은 인간이 여전히 안전장치로 남아야 하는 패턴을 참조합니다. 00:10:47.420 --> 00:10:49.540 비행기 자동 조종 장치처럼 생각하십시오. 00:10:49.700 --> 00:10:52.580 매우 유용하지만 항상 수동 조작 기능이 설계되어 있습니다. 00:10:52.900 --> 00:10:55.140 보시 호수에 착륙하는 것이 최적이라고 판단한다면 00:10:55.140 --> 00:10:57.500 추락하기 전에 직접 제어권을 가져와야 합니다. 00:10:57.720 --> 00:11:00.300 적절한 비유는 10대에게 운전을 가르치는 것입니다. 00:11:00.560 --> 00:11:02.660 잠재력은 확실하고 속도도 인상적이지만 00:11:02.660 --> 00:11:05.460 키를 넘겨주고 차고를 떠나며 행운을 빌지는 않습니다. 00:11:05.460 --> 00:11:07.180 조수석에 앉아 경계를 설정하고 00:11:07.180 --> 00:11:09.420 직접 밟을 수 있는 브레이크를 설치해야 합니다. 00:11:09.560 --> 00:11:11.800 그것이 수명주기 거버넌스를 실천하는 방법입니다. 00:11:11.980 --> 00:11:14.120 시스템이 경로를 벗어나지 않을 거라는 확신이 들 때까지는 00:11:14.120 --> 00:11:15.000 보조바퀴가 필요하죠. 00:11:15.180 --> 00:11:16.740 이제 더 큰 공장으로 넘어가 보겠습니다. 00:11:17.040 --> 00:11:18.340 이곳은 에이전트, 코어 파일럿 00:11:18.340 --> 00:11:20.720 그리고 여러분이 테스트한 모든 워크플로우가 하나로 모이는 곳입니다. 00:11:20.940 --> 00:11:23.180 마이크로소프트는 이를 에이저 AI 파운드리라고 부르는데 00:11:23.180 --> 00:11:25.500 모든 도구를 갖춘 원스톱 AI 구축 공간입니다. 00:11:25.720 --> 00:11:27.480 이곳이 생산성을 높이는 핵심 기지가 될지 00:11:27.480 --> 00:11:29.260 프로젝트가 자폭하는 장소가 될지는 00:11:29.260 --> 00:11:31.420 전적으로 여러분이 어떻게 다루느냐에 달려있습니다. 00:11:37.180 --> 00:11:38.960 마이크로소프트가 내세운 새로운 주력 제품으로 00:11:38.960 --> 00:11:41.160 이른바 모든 AI를 위한 공장입니다. 00:11:41.320 --> 00:11:42.220 문제는 뭘까요? 00:11:42.460 --> 00:11:44.920 너무 많은 팀이 이곳을 이케아처럼 대한다는 겁니다. 00:11:45.160 --> 00:11:47.220 그들은 매력적인 카탈로그에 눈이 멀어 훌륭한 00:11:47.220 --> 00:11:48.780 거대 언어 모델 몇 개를 집어들고 00:11:48.780 --> 00:11:51.960 커넥터를 연결한 뒤 설명서도 없이 무언가를 조립해버립니다. 00:11:52.180 --> 00:11:54.320 결국 완성되는 건 기업용 AI 시스템이 아니라 00:11:54.320 --> 00:11:56.940 실제 사용자가 복잡한 PDF 파일을 넣는 순간 00:11:56.940 --> 00:11:59.160 무너져버리는 장난감 수준의 데모일 뿐입니다. 00:11:59.320 --> 00:12:02.540 공식 가이드 북에 따른 파운드리 위 실제 제공 기능은 다음과 같습니다. 00:12:03.040 --> 00:12:05.660 마이크로소프트, 오픈아이, 메타, 미스트럴, 00:12:07.180 --> 00:12:10.240 마이크로그, RAG, 검색 증강 생성, 파인 튜닝, 00:12:10.600 --> 00:12:12.180 증류와 같은 맞춤 설정 옵션, 00:12:12.360 --> 00:12:14.320 오케스트레이션을 위한 에이전트 서비스, 00:12:14.680 --> 00:12:16.800 평가 및 디버깅을 위한 프롬프트 플로우 도구, 00:12:17.200 --> 00:12:19.420 보안 기준 기능, 아이디 및 액세스 제어, 00:12:19.700 --> 00:12:22.040 콘텐츠 안전 필터, 관측성 대시보드, 00:12:22.180 --> 00:12:24.100 간단히 말해 코파일럿, 에이전트, 00:12:24.340 --> 00:12:26.480 자율 흐름을 구축하고 규정을 준수하도록 유지하는 데 00:12:26.480 --> 00:12:27.580 필요한 모든 부품이 있습니다. 00:12:27.780 --> 00:12:29.020 그게 바로 인벤토리입니다. 00:12:29.240 --> 00:12:30.680 도구 상자가 비어있는 게 문제가 아니라 00:12:30.680 --> 00:12:33.360 너무 많은 관리자가 GPT4 터보 스위치를 켜는 것을 00:12:33.360 --> 00:12:35.780 곧바로 프로덕션 준비 완료로 착각한다는 게 문제입니다. 00:12:35.880 --> 00:12:38.220 진실은 파운드리가 해커톤을 위한 장난감 상자가 아니라 00:12:38.220 --> 00:12:39.720 실제 공장 바닥이라는 점입니다. 00:12:39.880 --> 00:12:42.060 즉, 적절한 사람만 적절한 모델을 다룰 수 있도록 00:12:42.060 --> 00:12:43.840 신원 경계를 설정해야 한다는 뜻입니다. 00:12:44.040 --> 00:12:47.420 모든 파이프라인에 콘텐츠 안전 조치를 적용해야 한다는 의미이기도 합니다. 00:12:47.580 --> 00:12:49.980 관측성을 활용하여 답변이 근거가 있는 것인지, 00:12:50.440 --> 00:12:53.640 아니면 모델이 회사 정책을 멋대로 지어낸 것인지 파악해야 합니다. 00:12:53.860 --> 00:12:56.620 그리고 똑똑해 보인다는 이유로 가장 큰 모델만 고를 게 아니라 00:12:56.620 --> 00:12:58.940 업무에 맞는 적절한 모델을 선택해야 합니다. 00:12:58.940 --> 00:13:02.020 이런 단계를 건너뛰면 혼란이 뒷문으로 슬그머니 들어옵니다. 00:13:02.180 --> 00:13:04.460 어떤 팀이 셰어포인트에서 파운드리 코파일럿을 연결했다가 00:13:04.460 --> 00:13:07.520 제한된 인사 데이터를 20명이 인터넷에 그대로 노출하는 상황을 본 적이 있습니다. 00:13:07.700 --> 00:13:09.040 그건 똑똑한 게 아니었습니다. 00:13:09.360 --> 00:13:12.240 내장된 액세스 규칙으로 피할 수 있었던 규정 준수 재앙이었죠. 00:13:12.380 --> 00:13:14.160 실제 실패 사례에 대해 이야기해봅시다. 00:13:14.340 --> 00:13:17.460 어느 조직에서 제품 사진 태깅을 위해 GPT4 터보를 실행한 적이 있습니다. 00:13:17.700 --> 00:13:20.100 연구실 테스트에서는 데모를 성공적으로 마쳤습니다. 00:13:20.300 --> 00:13:23.480 깔끔한 스튜디오 사진에 완벽한 태그가 달리니 모두가 박수를 쳤죠. 00:13:23.480 --> 00:13:28.360 하지만 프로덕션 단계에서는 광택이 나는 JPG가 아닌 창고에서 찍은 흐릿한 폰 사진이 입력되었습니다. 00:13:28.520 --> 00:13:31.420 갑자기 AI가 유모차를 사무용 위자로 잘못 태그하고 00:13:31.420 --> 00:13:34.180 UPC 라벨을 가짜 일련번호로 뒤섞어 버렸습니다. 00:13:34.360 --> 00:13:36.980 신뢰도 저하뿐만 아니라 비용까지 치솟기 시작했습니다. 00:13:37.240 --> 00:13:39.740 메시지당 0.01달러 같은 동화 같은 이야기가 아닙니다. 00:13:39.900 --> 00:13:43.540 파운드리 파운드리 가격 책정은 사용량 기반이며 사용하는 특정 서비스에 따라 결정됩니다. 00:13:43.720 --> 00:13:47.580 모든 커넥터 모든 검색 호출 모든 메시지 미터가 테넌트에 청구됩니다. 00:13:47.780 --> 00:13:49.760 각 요소마다 고유한 과금 모델이 있습니다. 00:13:49.760 --> 00:13:54.660 유연성은 좋지만 에이저 가격 계산기로 예상치를 확인하고 사용량을 추적하지 않으면 00:13:54.660 --> 00:13:57.360 재무팀이 뜻밖의 청구서를 보고 아주 좋아할 겁니다. 00:13:57.580 --> 00:13:58.880 그게 바로 비용의 덧입니다. 00:13:59.120 --> 00:14:02.500 사용량 기반 가격 책정은 계획하고 모니터링하며 최적화할 때만 효과적입니다. 00:14:02.720 --> 00:14:04.860 그렇지 않으면 스포츠카를 피자 배달용 스쿠터로 쓰는 꼴이 되어 00:14:04.860 --> 00:14:06.860 비용만 많이 들고 시끄럽기만 할 뿐 아무 의미가 없습니다. 00:14:07.080 --> 00:14:09.140 파워BI 같은 서비스에서 다들 겪어봤을 겁니다. 00:14:09.380 --> 00:14:11.400 데모는 훌륭했지만 청구서가 폭탄이 되었죠. 00:14:11.560 --> 00:14:13.620 파운드리에서도 같은 상황을 겪지 않도록 하세요. 00:14:13.820 --> 00:14:16.700 개발자들은 파운드리 샌드박스가 매끄러워서 프로토타이핑을 좋아합니다. 00:14:16.920 --> 00:14:18.480 물론 샌드박스 안에서는 매끄럽죠. 00:14:18.620 --> 00:14:20.780 깔끔한 데모 데이터, 문제없음, 즉각적인 감탄. 00:14:20.960 --> 00:14:22.480 하지만 여기서 치명적인 문제가 발생합니다. 00:14:22.480 --> 00:14:25.560 팀들은 평가 파이프 라인 없이 프로토타입을 프로덕션으로 바로 밀어붙입니다. 00:14:25.700 --> 00:14:30.160 근거성, 유창성, 관련성, 일관성에 대한 평가를 건너뛰면 눈을 감고 배포하는 셈입니다. 00:14:30.340 --> 00:14:31.540 그럼 어떤 일이 벌어질까요? 00:14:31.740 --> 00:14:35.140 사용자는 결과물의 편차를 보게 되고 신뢰도는 떨어지며 임원들은 예산을 삭감할 것입니다. 00:14:35.300 --> 00:14:37.740 이건 파운드리의 실패가 아니라 팀의 거버넌스 실패입니다. 00:14:37.960 --> 00:14:41.300 많은 파운드리 프로토타입이 바로 이런 이유로 프로덕션에 도달하지 못하고 멈춥니다. 00:14:41.480 --> 00:14:44.360 관측 가능성도, 품질 검사도, 텔레메트리도 없기 때문입니다. 00:14:44.560 --> 00:14:45.840 답은 이미 플랫폼 안에 있습니다. 00:14:45.840 --> 00:14:48.660 첫날부터 에이저 AI 파운드리 관측 기능을 사용하세요. 00:14:48.820 --> 00:14:50.260 프롬프트 플로우를 연결하세요. 00:14:50.500 --> 00:14:52.380 모든 테스트에 내장 평가기를 실행하세요. 00:14:52.560 --> 00:14:57.200 라이브 환경을 생각하기 전에 하이브리드 검색과 의미론적 재순위 지점을 사용한 에이저 AI 검색으로 시스템의 근거를 마련하세요. 00:14:57.400 --> 00:14:59.620 마이크로소프트는 이 도구들을 구석에 숨기지 않았습니다. 00:14:59.800 --> 00:15:01.620 프로덕션 안전을 위해 문서화되어 있습니다. 00:15:07.740 --> 00:15:15.940 파운드리를 공장처럼 다루고, 거버넌스를 첫 번째 단계로 삼으며, 조건부 액세스처럼 규정 준수 정책을 내재화하고, 시작부터 관측 파이프라인이 작동하게 하세요. 00:15:16.120 --> 00:15:20.840 그리고 네, 아이디어 범위 지점과 콘텐츠 안전은 나중에 덧붙이는 것이 아니라 구성요소의 일부여야 합니다. 00:15:21.020 --> 00:15:24.020 거버넌스를 건너뛰면 잘못된 답변 이상의 위험을 감수하게 됩니다. 00:15:24.280 --> 00:15:29.920 그렇지 않으면 다중 모달보시 인사팀 급여를 외부 사용자에게 노출하거나 송장의 허구에 정책번호를 기재할 수 있습니다. 00:15:30.200 --> 00:15:34.380 이건 단순히 AI 가고장난 게 아니라 당신의 컴플라이언스 부서가 설명하기 난처해할 뉴스 거리가 될 수 있습니다. 00:15:34.380 --> 00:15:38.780 그리고 여기서 초점이 바뀝니다. 다음번 걸림돌은 기술적인 문제가 전혀 아니기 때문입니다. 00:15:38.960 --> 00:15:41.700 그것은 바로 당신의 AI가 책임감 있게 운영되는가 하는 점입니다. 00:15:41.880 --> 00:15:48.320 모두가 기조연설 슬라이드에 그 단어들을 넣길 좋아하지만, 실제로는 감사, 필터, 규정 준수, 그리고 출시 전에 내려야 할 수많은 선택의 연속입니다. 00:15:48.500 --> 00:15:50.900 그리고 바로 거기서 진정한 골칫거리가 시작되죠. 00:15:51.060 --> 00:15:55.360 M365 쇼 뉴스레터를 구독하고 팔로우하여 직설적인 해결책을 확인하세요. 00:15:55.560 --> 00:16:01.040 M365 쇼 링크드인 페이지를 팔로우하여 파운드리를 실제 환경에서 테스트하고, 문제점을 경험한 MVP들과의 라이브 스트리밍에 참여하세요. 00:16:01.040 --> 00:16:06.800 책임있는 AI인가, 책임져야 할 골칫거리인가, 모두가 기조연설에서 책임있는 AI라는 말을 던지 길 좋아합니다. 00:16:06.960 --> 00:16:09.800 공정성이나 투명성 같은 유행어 옆에 있으면 꽤 그럴싸해 보이니까요. 00:16:09.960 --> 00:16:12.520 하지만 실무 현장에서 이는 영감을 주는 철학과는 거리가 멉니다. 00:16:12.680 --> 00:16:17.740 혁신보다는 서버 유지의 보수처럼 느껴지는 구성, 감사, 필터링, 그리고 거버넌스 단계일 뿐이죠. 00:16:17.880 --> 00:16:20.520 책임있는 AI는 스포츠카가 아니라 안전벨트입니다. 00:16:20.760 --> 00:16:23.080 한 번만 건너 뛰어도 사고는 순식간에 일어납니다. 00:16:23.080 --> 00:16:29.260 마이크로소프트는 윤리와 보안을 앞세우지만, 이를 실제로 도입하는 관리자들에게는 실질적인 안전장치를 의미합니다. 00:16:29.400 --> 00:16:37.840 압박 속에서도 무너지지 않는 액세스 정책, 유해한 프롬프트를 실제로 차단하는 필터, 그리고 소환장을 들고 달려드는 규제기관을 만족시킬 만큼 상세한 로그가 필요합니다. 00:16:38.000 --> 00:16:39.260 화려한 작업은 아닙니다. 00:16:39.460 --> 00:16:48.860 인사팀 코파일럿을 재무데이터 로부터 격리하고, 팀스팟이 셰어포인트 보안 영역을 침범하지 않도록 범위를 설정하며, 응답이 어떻게 생성되었는지 증명하기 위해 로그를 태깅하는 일이죠. 00:16:48.860 --> 00:16:52.880 이걸 제대로 해내면, 책임은 기업 슬로건이 아니라 생존 그 자체가 됩니다. 00:16:53.120 --> 00:16:58.760 이 과정을 건너 뛰고 테넌트 범위 설정 없이 봇을 인사저장소에 바로 연결하는 최악의 상황을 가정해봅시다. 00:16:58.940 --> 00:17:01.260 사용자가 보험 혜택에 대해 질문합니다. 00:17:01.460 --> 00:17:05.100 봇은 친절하게도 직원 급여 범위를 채팅창에 공개해버리죠. 00:17:05.280 --> 00:17:10.020 이제 개인정보 유출, 사기 저하, 그리고 규제기관의 압박까지 감당해야 합니다. 00:17:10.220 --> 00:17:13.760 구입을 망치는 가장 빠른 길은 나쁜 UX가 아니라, 단 한 번이 민감한 데이터 유출입니다. 00:17:13.940 --> 00:17:15.660 그럼 그런 혼란을 어떻게 막을 수 있을까요? 00:17:15.820 --> 00:17:17.900 에이저 AI 콘텐츠 안전기능부터 시작하세요. 00:17:17.900 --> 00:17:22.780 폭력적, 외설적, 모욕적 인프롬프트와 응답이 사용자에게 도달하기 전에 걸러내도록 설계되었습니다. 00:17:22.980 --> 00:17:24.720 하지만 그건 기본 중의 기본입니다. 00:17:24.920 --> 00:17:29.100 파운드리와 코파일러 스튜디오는 그 다음 단계를 처리하는 평가 파이프라인을 구축합니다. 00:17:29.320 --> 00:17:34.340 근거 확인, 관련성 점수 산정, 투명성 대시보드, 그리고 설명 가능성 등이 포함됩니다. 00:17:34.540 --> 00:17:39.860 쉽게 말해, 인계값을 조정하고 입출력을 필터링하며, 보시 왜 그런 결과를 냈는지 설명하게 만들 수 있습니다. 00:17:40.120 --> 00:17:43.060 그것 없이는 AI가 뱉어내는 결과물에 도박을 거는 것과 다름없습니다. 00:17:43.240 --> 00:17:45.120 그리고 여기 자원에 관한 현실적인 문제가 있습니다. 00:17:45.120 --> 00:17:47.480 마이크로소프트는 이 부분에 큰 무게를 둡니다. 00:17:47.620 --> 00:17:52.960 보안에 전념하는 3만 4천명이 정규직 엔지니어와 1만 5천명이 보안 전문 파트너들이 있죠. 00:17:53.160 --> 00:17:54.280 그야말로 요새와 같습니다. 00:17:54.680 --> 00:17:55.940 하지만 방심해서는 안 됩니다. 00:17:56.220 --> 00:17:59.740 그 엔지니어들 중 누구도 여러분의 테넌트 안에서 액세스 규칙을 설정해주지는 않으니까요. 00:17:59.740 --> 00:18:06.360 마이크로소프트는 안전장치를 제공하지만 아이디의 잠금, 데이터 격리, 암호화 적용, 정책 구성은 여전히 여러분의 목입니다. 00:18:06.520 --> 00:18:09.540 범위 설정이 부실하면 그로 인한 사고의 책임은 결국 본인의 목입니다. 00:18:09.740 --> 00:18:11.760 진정한 해결책은 수명주기 거버넌스입니다. 00:18:12.160 --> 00:18:14.760 마이크로소프트가 직접 권장하는 레시피라고 생각하세요. 00:18:15.000 --> 00:18:18.740 테스트, 승인, 릴리스, 감사, 그리고 반복입니다. 00:18:18.960 --> 00:18:23.140 주기마다 검문 지점을 두면 문제가 뉴스거리가 되기 전에 편차를 계속 잡아낼 수 있습니다. 00:18:23.140 --> 00:18:26.120 한 번 배포하고 손을 놓는 팀은 결국 사고를 치기 마련입니다. 00:18:26.260 --> 00:18:29.560 모델은 진화하고 프롬프트는 변하며 출력값은 빗나가기도 하니까요. 00:18:29.700 --> 00:18:31.600 거버넌스는 불필요한 관료주의가 아닙니다. 00:18:31.780 --> 00:18:35.240 모두가 잠든 사이 인턴 보시 팀즈에서 멋대로 정책을 만드는 걸 막는 방법이죠. 00:18:35.440 --> 00:18:38.580 일부 관리자들은 책임 있는 AI가 속도를 늦출 뿐이라고 투덜댑니다. 00:18:38.760 --> 00:18:39.700 잘못된 시각입니다. 00:18:39.940 --> 00:18:43.380 책임 있는 AI는 속도를 죽이는 게 아니라 속도 때문에 당신이 죽는 걸 막아줍니다. 00:18:43.580 --> 00:18:46.920 훌륭한 거버넌스가 있으면 감사 과정을 견뎌내면서도 프로젝트를 계속 진행할 수 있습니다. 00:18:47.140 --> 00:18:49.080 이를 건너뛰는 건 절벽에서 다이빙하는 것과 같습니다. 00:18:49.080 --> 00:18:51.640 통제 없는 속도는 단 하나의 기록만을 남길 뿐입니다. 00:18:51.800 --> 00:18:53.580 사고 조사까지 걸리는 최단 시간이죠. 00:18:53.760 --> 00:18:55.660 구비구비 산길을 운전한다고 생각해보세요. 00:18:55.880 --> 00:18:59.200 불호가 200피트 아래로 꺾일 때 가드레일을 욕하는 사람은 없으며 오히려 그 존재에 감사하게 됩니다. 00:18:59.380 --> 00:19:00.980 책임 있는 AI도 마찬가지입니다. 00:19:01.140 --> 00:19:05.600 범위, 정책, 필터, 로그는 속도를 방해하는 게 아니라 당신의 차가 저녁 뉴스에 나오지 않게 지켜주는 겁니다. 00:19:05.780 --> 00:19:08.760 결론적으로 마이크로소프트는 막강한 기능을 제공했습니다. 00:19:09.060 --> 00:19:12.080 콘텐츠 안전, 평가 파이프 라인, 보안 프레임워크, 00:19:12.080 --> 00:19:18.920 SDK 가드레일이 있지만 헤넌트 범위를 정하고 액세스를 구성하며 운영주기에 그 루프를 연결하는 건 여전히 당신의 목입니다. 00:19:19.080 --> 00:19:23.060 그렇게 하면 규정 준수하에 무너지지 않고 살아남는 AI를 가질 수 있습니다. 00:19:23.320 --> 00:19:26.840 무시하면 단순한 중단 위험을 넘어 당신의 커리어까지 위태로워집니다. 00:19:27.020 --> 00:19:28.680 책임 있는 AI는 느리지 않습니다. 00:19:28.900 --> 00:19:32.040 책임 있는 AI는 생존 가능하며 생존이야말로 진정한 시험대입니다. 00:19:32.240 --> 00:19:38.120 다음 단계는 기능의 문제가 아니라 이 플랫폼을 플러그 앤 플레이로 대할지 아니면 거버넌스 우선의 인프라로 존중할지의 문제이기 때문입니다. 00:19:38.120 --> 00:19:41.180 그 차이가 누가 살아남고 누가 도태되는지를 결정합니다. 00:19:41.340 --> 00:19:42.300 핵심은 이렇습니다. 00:19:42.540 --> 00:19:46.440 함정은 파운드리나 코파일럿 스튜디오가 아니라 그것들을 플러그 앤 플레이로 생각하는 것입니다. 00:19:46.640 --> 00:19:47.980 기억할 원칙은 간단합니다. 00:19:48.180 --> 00:19:50.620 거버넌스 먼저, 실험은 그 다음, 운영은 마지막입니다. 00:19:50.820 --> 00:19:53.300 아이디 관리와 가시성을 건너 뛰는 위험을 감수하지 마십시오. 00:19:53.420 --> 00:19:57.320 도구는 이미 갖춰져 있지만 오직 거버넌스만이 프로토타입을 실제 운영 환경으로 바꿉니다. 00:19:57.480 --> 00:20:02.900 페넌트를 확실하게 지켜줄 명쾌한 해결책을 원하신다면 팟캐스트를 구독하고 리뷰를 남겨주세요. 00:20:02.900 --> 00:20:06.180 매일 시간을 들여 만들고 있으니 여러분의 지원이 큰 힘이 됩니다. 00:20:06.360 --> 00:20:08.540 도구는 변해도 생존 전략은 살아남습니다.