WEBVTT

00:00:00.000 --> 00:00:02.160
아무도 말해주지 않는 충격적인 사실이 있습니다.

00:00:02.360 --> 00:00:04.000
에이저 파운드리에 AI를 배포할 때

00:00:04.000 --> 00:00:06.320
단순히 거대한 모델 하나를 실행하는 것이 아닙니다.

00:00:06.480 --> 00:00:08.640
모든 관련 작업, 메시지, 도구 호출,

00:00:08.960 --> 00:00:12.240
실행 단계가 기록되고 추적되는 관리형 런타임의 AI를 배치하는 것입니다.

00:00:12.440 --> 00:00:15.100
스레드, 실행, 실행 단계가 어떻게 실험을 감사 가능하고

00:00:15.100 --> 00:00:17.800
기업 환경에 적합하게 만드는 추적 기록을 형성하는지 확인할 수 있습니다.

00:00:18.000 --> 00:00:21.580
이는 제멋대로였던 AI를 관리 가능한 규율 있는 시스템으로 바꿔줍니다.

00:00:21.780 --> 00:00:23.940
구조가 갖춰졌다면 이제 진짜 질문은

00:00:23.940 --> 00:00:26.740
이 디지털 팀을 누가 이끌 것인가 하는 점입니다.

00:00:26.920 --> 00:00:28.000
팀장을 소개합니다.

00:00:28.000 --> 00:00:31.560
파운드리에서 하나를 설정할 때 단순히 채팅창을 여는 것이 아닙니다.

00:00:31.700 --> 00:00:33.020
팀장을 임명하는 것입니다.

00:00:33.280 --> 00:00:35.480
자동 완성이나 두드리는 인턴이 아닙니다.

00:00:35.700 --> 00:00:39.300
명확한 설계에 따라 임무를 수행하도록 만들어진 현장 지휘관입니다.

00:00:39.520 --> 00:00:44.100
그 설계는 모델, 지침, 도구라는 세 가지 핵심 요소로 귀결됩니다.

00:00:44.340 --> 00:00:45.340
모델은 두뇌입니다.

00:00:45.600 --> 00:00:48.280
추론과 언어를 당당하며 사람의 말을 분석하고

00:00:48.280 --> 00:00:50.820
단계를 계획하며 응답을 작성하는 역할을 합니다.

00:00:51.080 --> 00:00:52.380
지침은 임무 명령입니다.

00:00:52.640 --> 00:00:55.260
이 지침은 두뇌가 자유롭게 날뛰지 않도록 하고

00:00:55.260 --> 00:00:57.180
필요한 결과에 집중하게 합니다.

00:00:57.180 --> 00:01:02.520
도구는 코드 실행, 검색 커넥터, 보고용 API 또는 연결된 타사 시스템처럼

00:01:02.520 --> 00:01:04.040
가슴에 장착된 장비입니다.

00:01:04.220 --> 00:01:07.200
에이저 AI 에이전트는 바로 이 세 가지 요소로 구성됩니다.

00:01:07.420 --> 00:01:10.340
이것이 없으면 재현 가능성이나 감사 가능성을 확보할 수 없습니다.

00:01:10.600 --> 00:01:12.760
그저 증거 없는 텍스트 생성만 남게 될 뿐입니다.

00:01:12.960 --> 00:01:14.480
이를 전장 상황에 비유해보겠습니다.

00:01:14.900 --> 00:01:16.540
모델은 지휘관의 전투 훈련과 같습니다.

00:01:16.840 --> 00:01:19.000
검을 휘두르거나 문장을 완성하는 법을 아는 것이죠.

00:01:19.180 --> 00:01:20.380
지침은 임무 브리핑입니다.

00:01:20.560 --> 00:01:21.180
호송대를 보호하십시오.

00:01:21.880 --> 00:01:23.640
계약서 세트에서 데이터를 추출하십시오.

00:01:23.640 --> 00:01:25.480
결과를 특정 형식으로 보고하십시오.

00:01:25.600 --> 00:01:27.820
이것이 지휘관을 일관되고 예측 가능하게 만듭니다.

00:01:27.980 --> 00:01:29.660
이제 도구는 전문성을 더 해줍니다.

00:01:29.900 --> 00:01:33.040
벽을 오르는 갈고리는 분석을 실행하는 코드 인터프리터와 같습니다.

00:01:33.360 --> 00:01:36.600
보안 무전기는 시어포인트 나 사용자 지정 mcp 커넥터가 실시간 데이터를

00:01:36.600 --> 00:01:37.720
계획에 공급하는 것과 같습니다.

00:01:38.000 --> 00:01:40.660
이 세 가지가 합쳐지면 에이전트는 즉흥적으로 행동하지 않습니다.

00:01:40.860 --> 00:01:42.940
로그와 체크포인트를 통해 임무를 수행하게 됩니다.

00:01:43.180 --> 00:01:45.380
파운드리는 이 메커니즘을 실용적으로 만들어줍니다.

00:01:45.380 --> 00:01:48.240
대부분의 채팅 api는 모델과 프롬프트만 제공합니다.

00:01:48.360 --> 00:01:51.620
대화가 시작되면 명령이나 도구 오케스트레이션에 대한 공식적인 개념이

00:01:51.620 --> 00:01:51.920
없습니다.

00:01:52.200 --> 00:01:55.320
이는 지휘관을 계획이나 장비 없이 전장에 내던지는 것과 같습니다.

00:01:55.640 --> 00:01:59.520
반면 파운드리 에이전트 서비스는 세 가지 계층이 모두 존재함을 보장합니다.

00:01:59.740 --> 00:02:02.320
더 좋은 점은 하나의 두뇌에 얽매일 필요가 없다는 것입니다.

00:02:02.480 --> 00:02:05.000
파운드리 카탈로그에서 모델을 자유롭게 전환할 수 있습니다.

00:02:05.220 --> 00:02:08.720
복잡한 전략에는 gpt4를 가벼운 작업에는 더 효율적인 모델을 또는

00:02:08.720 --> 00:02:10.480
미스트럴이나 딥시클을 도입할 수도 있습니다.

00:02:10.680 --> 00:02:12.160
임무에 맞는 것을 선택하세요.

00:02:12.160 --> 00:02:16.500
이러한 유연성 이야말로 획일적인 인턴과 상황에 적응하는 지휘관의 차이입니다.

00:02:16.660 --> 00:02:18.980
이제 이러한 계층이 없을 때의 위험을 고려해보세요.

00:02:19.200 --> 00:02:20.880
결과 값이 일관되지 않게 됩니다.

00:02:21.120 --> 00:02:24.280
계약서 요약본이 하나는 이렇게 읽히고 다음은 미묘하게 내용을 반박하는

00:02:24.280 --> 00:02:24.660
식이죠.

00:02:24.840 --> 00:02:28.020
답변이 어떻게 도출되었는지 기록하는 구조화된 로그가 없어 추적성을

00:02:28.020 --> 00:02:28.500
잃게 됩니다.

00:02:28.720 --> 00:02:31.740
개발자가 추론 과정을 다시 추적할 수 없어 디버깅이 추측 게임으로

00:02:31.740 --> 00:02:32.200
변합니다.

00:02:32.420 --> 00:02:34.580
기업 환경에서 이는 단순한 불편함이 아닙니다.

00:02:34.760 --> 00:02:36.780
신뢰와 도입을 가로막는 실질적인 위험입니다.

00:02:36.780 --> 00:02:38.920
파운드리는 이를 명확한 방식으로 해결합니다.

00:02:39.100 --> 00:02:40.880
바드레일이 에이전트 내부에 구축되어 있습니다.

00:02:41.180 --> 00:02:43.700
지침은 반드시 따라야 하는 고정된 규칙집 역할을 합니다.

00:02:43.900 --> 00:02:47.000
도구 세트는 사용 사례에 따라 범위를 좁히거나 확장할 수 있습니다.

00:02:47.260 --> 00:02:51.100
모델은 자유롭게 교체할 수 있지만 항상 책임을 강제하는 구조 안에서

00:02:51.100 --> 00:02:51.820
이루어집니다.

00:02:52.000 --> 00:02:55.560
이 세 가지가 결합되어 규율 잡힌 분대장, 예측 가능한 결과, 가시적

00:02:55.560 --> 00:02:59.040
인단계, 그리고 엔터프라이즈 커넥터와 사용자 지정 api를 통한 책임

00:02:59.040 --> 00:03:00.100
있는 확장성을 제공합니다.

00:03:00.320 --> 00:03:03.300
이것은 ai를 마법 같은 대화로 포장하려는 것이 아닙니다.

00:03:03.300 --> 00:03:07.200
조직의 로그를 실행하고 명령을 따르며 적절한 장비를 갖춘 노련한

00:03:07.200 --> 00:03:08.840
장교를 제공함을 보여주는 것입니다.

00:03:08.980 --> 00:03:12.240
훌륭한 선장처럼 모든 임무에서 일어난 일을 꼼꼼하게 기록합니다.

00:03:12.440 --> 00:03:15.680
시스템을 감사하거나 오류가 발생했을 때 그 일지가 필요하기 때문입니다.

00:03:15.860 --> 00:03:17.500
파운드리에서 그 일지는 이름이 있습니다.

00:03:17.760 --> 00:03:19.460
바로 스레드, 스레드 라고 합니다.

00:03:19.680 --> 00:03:21.300
스레드, 즉 전장의 로그입니다.

00:03:21.540 --> 00:03:23.960
스레드는 임무 로그가 형태를 갖추기 시작하는 곳입니다.

00:03:24.180 --> 00:03:27.900
에이저 파운드리에서 스레드는 닫으면 사라지는 일반적인 채팅창이 아닙니다.

00:03:28.100 --> 00:03:29.600
지속적인 대화 세션입니다.

00:03:29.600 --> 00:03:35.900
사용자, 에이전트 또는 멀티 에이전트 설정에 다른 에이전트 간의 모든 교환 내용이 여기에 저장됩니다.

00:03:36.100 --> 00:03:41.280
이것이 전장의 로그로서 채팅이 끝난 후에도 오랫동안 검토할 수 있는 연구적인 상호작용 기록을 유지합니다.

00:03:41.480 --> 00:03:44.800
진정한 강점은 스레드가 단순한 정적 대화록이 아니라는 점입니다.

00:03:45.020 --> 00:03:47.860
스레드는 자동 절단을 처리하는 구조화된 컨테이너로

00:03:47.860 --> 00:03:52.600
모델 제한 내에서 활성 컨텍스트를 유지하면서도 전체 감사 추적을 보존합니다.

00:03:52.820 --> 00:03:55.720
이는 에이전트가 진행 중인 대화를 계속 이해하는 동시에

00:03:55.720 --> 00:03:58.720
기업은 검토 가능한 연구 기록을 유지한다는 의미입니다.

00:03:58.720 --> 00:04:01.780
대부분의 채팅 앱과 달리 그 무엇도 허공으로 사라지지 않습니다.

00:04:01.980 --> 00:04:04.660
에이전트에게는 연속성을, 기업에게는 거버넌스를 제공합니다.

00:04:04.820 --> 00:04:06.740
그 로그의 항목들은 메시지로 구성됩니다.

00:04:06.940 --> 00:04:08.940
메시지는 일반 텍스트에 국한되지 않습니다.

00:04:09.140 --> 00:04:12.540
이미지, 스프레드 시트 파일 또는 생성된 코드 블록을 포함할 수 있습니다.

00:04:12.760 --> 00:04:16.740
각 메시지에는 타임 스탬프가 지키고 사용자 또는 어시스턴트라는 역할이 네이블로 지정됩니다.

00:04:16.900 --> 00:04:19.260
따라서 스레드를 검토하면 단순히 대화 내용뿐만 아니라

00:04:19.260 --> 00:04:23.300
누가 언제 말했는지, 어떤 유형의 콘텐츠가 포함되었는지까지 확인할 수 있습니다.

00:04:23.540 --> 00:04:26.840
컴플라이언스 담당자가 기록을 열어 어제 제출된 정확한 텍스트 요청,

00:04:27.240 --> 00:04:29.220
에이전트가 그의 대응에 생성한 차트 이미지,

00:04:29.600 --> 00:04:32.120
그리고 두 사건이 발생한 시간을 확인하는 모습을 상상해보세요.

00:04:32.400 --> 00:04:34.960
그것은 기억 그 이상이며, 완전한 실시간 장부와 같습니다.

00:04:34.960 --> 00:04:36.260
게임 용어로 비유하자면,

00:04:36.560 --> 00:04:38.680
스레드는 던전 앤 드래곤 캠페인의 기록장과 같습니다.

00:04:38.960 --> 00:04:40.440
던전 마스터는 어느 마을을 방문했는지,

00:04:40.800 --> 00:04:41.920
어떤 주사위 굴림이 성공했는지,

00:04:42.300 --> 00:04:43.700
어떤 전리품을 획득했는지 기록합니다.

00:04:43.880 --> 00:04:44.540
그런 기록이 없으면,

00:04:44.680 --> 00:04:46.960
플레이어들은 잊어버린 세부사항을 두고 말다툼을 벌이게 됩니다.

00:04:47.200 --> 00:04:49.940
기록이 있으면 사건이 문서화되어 있으므로 논쟁이 사라집니다.

00:04:50.140 --> 00:04:52.360
스레드는 엔터프라이즈 AI에서도 동일한 역할을 합니다.

00:04:52.600 --> 00:04:53.820
모든 것이 순서대로 기록되기 때문에,

00:04:53.960 --> 00:04:56.000
에이전트가 실제로 무엇을 했는지에 대한 분쟁을 방지합니다.

00:04:56.200 --> 00:04:58.060
이제 왜 그러한 기록이 중요한지 설명하겠습니다.

00:04:58.060 --> 00:05:00.920
감사 및 규정 준수 측면에서 스레드는 그야말로 금과 같습니다.

00:05:01.180 --> 00:05:03.460
규제기관이나 내부 감사팀은 스레드를 열어 전체 시퀀스,

00:05:03.720 --> 00:05:05.300
사용자 요청, 에이전트 응답,

00:05:05.340 --> 00:05:06.260
어떤 도구가 사용되었는지,

00:05:06.560 --> 00:05:08.500
그리고 언제 모든 일이 일어났는지 즉시 확인할 수 있습니다.

00:05:08.700 --> 00:05:11.460
개발자에게의 동일한 기록은 디버그 모드와 같은 기능을 합니다.

00:05:11.740 --> 00:05:13.440
에이전트가 잘못된 코드 조각을 생성했다면,

00:05:13.840 --> 00:05:17.220
스레드를 요청 시점으로 되돌려 정확히 어떻게 그런 결과에 도달했는지 확인할 수 있습니다.

00:05:17.420 --> 00:05:19.060
두 그룹 모두 가시성을 확보하게 되며,

00:05:19.380 --> 00:05:20.720
시간 낭비도 피할 수 있을 것입니다.

00:05:20.960 --> 00:05:23.680
대화 내용을 저장하지 않는 시스템과 비교해 보십시오.

00:05:23.680 --> 00:05:27.800
스레드가 없으면 스크린샷이나 희미한 기억의 의존의 동작을 추적해야 합니다.

00:05:27.980 --> 00:05:29.800
이는 컴플라이언스 팀이 증거를 요청하거나,

00:05:29.960 --> 00:05:32.340
지원팀이 버그를 재현해야 할 때 아무런 도움이 되지 않습니다.

00:05:32.520 --> 00:05:34.760
마치 게임에서 보스전을 다시 하라는 말을 듣고 보니,

00:05:34.860 --> 00:05:36.760
저장을 전혀 안 했다는 사실을 깨닫는 것과 같습니다.

00:05:37.060 --> 00:05:40.320
기록이 없으면 증거도 없고, 흔적이 없으면 수정도 불가능합니다.

00:05:40.540 --> 00:05:44.240
최악의 상황에서는 말뿐인 약속으로 이해관계자들을 안심시켜야 하는 처지가 됩니다.

00:05:44.500 --> 00:05:47.300
파운드리 위 스레드를 사용하면 그러한 함정에서 벗어날 수 있습니다.

00:05:47.540 --> 00:05:49.320
각 대화는 구조화된 증거가 됩니다.

00:05:49.540 --> 00:05:51.480
워크플로우가 법률문구를 불러오면,

00:05:51.860 --> 00:05:56.860
기록에는 원래 요청, 생성된 특정 답변, 그리고 지원 도구가 호출되었는지 여부가 표시됩니다.

00:05:57.060 --> 00:06:00.020
여러 에이전트가 작업을 분담하기 위해 서로 대화하는 경우,

00:06:00.480 --> 00:06:02.060
그들의 주고받은 내용도 기록됩니다.

00:06:02.280 --> 00:06:05.180
기업은 규정 준수를 증명하고, 개발자는 버그를 정확히 찾아내며,

00:06:05.180 --> 00:06:08.180
관리자는 시스템의 결과물이 책임질 수 있는 것임을 신뢰할 수 있습니다.

00:06:08.320 --> 00:06:12.380
바로 이 지점에서 스레드는 무질서한 대화를 프로덕션 수준의 결과물로 탈바꿈시킵니다.

00:06:12.540 --> 00:06:17.620
일시적인 대화 대신, 스레드는 임무와 결정에 대한 안정적인 이력을 생성하여 신뢰할 수 있는 기반을 마련합니다.

00:06:17.780 --> 00:06:18.860
하지만 기억하십시오.

00:06:19.020 --> 00:06:20.500
로그는 여전히 일기에 불과합니다.

00:06:20.740 --> 00:06:24.300
진정한 행동은 에이전트가 스레드에 기록된 내용을 받아 실제로 실행할 때 시작됩니다.

00:06:24.520 --> 00:06:28.940
다음 단계는 임무가 종이 위에 기록에서 멈추지 않고 실시간으로 실현되기 시작하는 지점입니다.

00:06:28.940 --> 00:06:31.520
런, 런,과 런스텝은 주사위를 던지는 것과 같습니다.

00:06:31.800 --> 00:06:33.660
런은 임무가 마침내 시작되는 곳입니다.

00:06:33.840 --> 00:06:38.780
파운드리의 용어로, 스레드는 대화의 백로그, 명령, 맥락, 스크롤된 지도를 담고 있습니다.

00:06:39.060 --> 00:06:42.880
런은 에이전트가 그 맥락을 가져와 실제로 실행하도록 활성화하는 트리거입니다.

00:06:43.120 --> 00:06:44.980
스레드는 기억하고, 런은 행동합니다.

00:06:45.180 --> 00:06:46.680
런을 발사 버튼이라고 생각하세요.

00:06:46.900 --> 00:06:49.260
스레드에는 csv를 분석해라, 라고 적혀있을지도 모릅니다.

00:06:49.440 --> 00:06:51.200
아니면 선 그래프를 그리라고 할 수도 있죠.

00:06:51.420 --> 00:06:55.520
하지만 런은 에이전트가 모델 지침과 도구를 통해 해당 요청을 처리하는 순간입니다.

00:06:55.520 --> 00:07:00.500
추가 데이터를 가져오거나, 수치를 계산하거나, 코드 인터프리터를 호출하여 아티팩트를 생성할 수 있습니다.

00:07:00.640 --> 00:07:04.780
테이블 탑 알피지 용어로 말하자면, 스레드는 파티가 테이블 주위에 모여 계획을 짜는 것입니다.

00:07:04.980 --> 00:07:07.280
런은 전투를 시작하는 선제권 주사위 분리기와 같습니다.

00:07:07.620 --> 00:07:09.340
그것 없이는 아무것도 진행되지 않습니다.

00:07:09.500 --> 00:07:11.180
파운드리는 바로 이 점을 명확히 합니다.

00:07:11.380 --> 00:07:12.740
런은 블랙박스가 아닙니다.

00:07:12.920 --> 00:07:15.420
런은 모니터링되고 상태가 추적되는 실행 과정입니다.

00:07:15.640 --> 00:07:19.860
일반적으로 대기 중, 진행 중, 작업 필요, 완료 또는 실패와 같은 상태를 볼 수 있습니다.

00:07:19.860 --> 00:07:24.460
SDK 샘플은 게임 마스터가 턴 순서를 확인하는 것처럼 루프 내에서 이러한 상태를 자주 폴링합니다.

00:07:24.620 --> 00:07:28.280
이를 통해 무엇이 완료되는지 뿐만 아니라 언제 발생하는지에 대한 가시성을 확보할 수 있습니다.

00:07:28.500 --> 00:07:29.980
하지만 더 큰 고민은 이건입니다.

00:07:30.180 --> 00:07:33.080
실행 내부에서 실제로 무슨 일이 일어났는지 어떻게 알 수 있을까요?

00:07:33.260 --> 00:07:39.500
답변은 괜찮아 보일지 몰라도, 세부 정보가 없으면 에이전트가 외부 API를 호출했는지, 코드를 작성했는지, 아니면 그냥 텍스트를 지어냈는지 알 수 없습니다.

00:07:39.740 --> 00:07:41.940
그러한 불투명함은 기업 환경에서 위험합니다.

00:07:41.940 --> 00:07:46.860
이는 체스 경기에 들어가서 게임 도중에 보드를 보고, 우리를 믿으세요, 올바른 수였어요, 라는 말을 듣는 것과 같습니다.

00:07:47.080 --> 00:07:48.300
다시 재생할 수도 없습니다.

00:07:48.600 --> 00:07:50.280
그 수가 정당했는지 알 길이 없습니다.

00:07:50.620 --> 00:07:51.940
런스텝은 그러한 추측을 제거해줍니다.

00:07:52.720 --> 00:07:59.320
모든 런은 어떤 모델 출력이 생성되었고, 어떤 도구가 호출되었으며, 어떤 계산이 실행되었고, 어떤 메시지가 생성되었는지 단계별로 기록됩니다.

00:07:59.520 --> 00:08:01.620
이것은 AI를 위한 체스 표기법과 같습니다.

00:08:01.940 --> 00:08:04.620
폰을 이사로, 나이트를 F6으로 옮기는 것과 같죠.

00:08:04.620 --> 00:08:09.820
여기서는 10시 2분의 파일 가져오기, 10시 3분의 코드 블록 실행, 10시 4분의 그래프 아티팩트 반환으로 기록됩니다.

00:08:09.960 --> 00:08:12.540
각 동작이 순서대로 기록되므로 나중에 다시 재생할 수 있습니다.

00:08:12.780 --> 00:08:14.880
이러한 구조는 개발자들에게 큰 안도감을 줍니다.

00:08:15.080 --> 00:08:18.440
런스텝이 없다면, 최종 답변만 보고 그것이 어떻게 도출되었는지 전혀 알 수 없게 됩니다.

00:08:18.640 --> 00:08:22.800
검색커리가 잘못되었나요? 수학적 오류가 끼어들었나요? 결국 추측만 하게 됩니다.

00:08:23.080 --> 00:08:27.340
런스텝을 사용하면 타임라인을 스크롤하여 정확한 오류 지점을 식별하고 수정할 수 있습니다.

00:08:27.580 --> 00:08:29.600
디버깅은 추측이 아닌 포렌식이 됩니다.

00:08:29.600 --> 00:08:36.400
이는 누가 공격했는지 알 수 없는 안개 속의 보스전과 모든 칼 휘두르기와 주문 시전이 기록된 전투로그의 차이와 같습니다.

00:08:36.680 --> 00:08:38.840
컴플라이언스 팀에게도 큰 이점이 있습니다.

00:08:39.080 --> 00:08:44.460
감사인이 요약이 어떻게 생성되었나요? 라고 물어볼 때 모델의 추론 과정을 추상적으로 설명할 필요가 없습니다.

00:08:44.740 --> 00:08:46.000
증빙 자료가 있으니까요.

00:08:46.140 --> 00:08:49.920
도구 호출, 인터프리터 단계, 구성된 답변까지 모두 타임스탬프가 찍혀 있습니다.

00:08:50.200 --> 00:08:51.980
이는 설명을 거버넌스로 전환합니다.

00:08:52.200 --> 00:08:54.480
이야기를 지어내는 대신 증거를 제시하는 것이죠.

00:08:54.680 --> 00:08:58.800
기업들은 이를 통해 위험이 책임으로 약속이 증명으로 바뀐다는 점을 매우 선호합니다.

00:08:58.800 --> 00:09:03.120
일상적인 운영에서 실행 단계는 신뢰할 수 있는 재현 가능한 패턴을 만들어냅니다.

00:09:03.260 --> 00:09:06.640
워크플로우를 다시 실행해야 할 경우 동일한 순서를 그대로 따를 수 있습니다.

00:09:06.860 --> 00:09:09.120
결과에 이의가 제기되면 다시 재현해볼 수 있습니다.

00:09:09.340 --> 00:09:14.220
성공적인 경우 전체 실행 단계가 포함된 실행 결과는 출력물이 어떻게 만들어졌는지에 대한 감사 가능하고 재현 가능한 증거를 제공합니다.

00:09:14.380 --> 00:09:17.840
다른 시스템에서 실패할 경우 남는 것은 추적할 수 없는 모호한 출력물뿐입니다.

00:09:18.040 --> 00:09:20.600
이것이 에이전트 수명 주기의 부분이 중요한 이유입니다.

00:09:20.800 --> 00:09:25.120
스레드라는 일기, 실행이라는 활성화, 그리고 실행 단계라는 동작 기록이 있습니다.

00:09:25.120 --> 00:09:30.460
이 요소들은 즉흥적인 AI를 추적, 테스트, 방어할 수 있는 책임감 있는 팀원으로 바꿔줍니다.

00:09:30.600 --> 00:09:33.700
물론 이러한 세부 정보가 존재한다는 것을 아는 것만으로는 부족합니다.

00:09:33.880 --> 00:09:40.120
원시 API 호출에 파묻히지 않고 에이전트를 실행하고 실행을 트리거하며 실행 단계를 읽어드릴 수 있는 구조화된 상호작용 방식이 필요합니다.

00:09:40.300 --> 00:09:43.500
놀라운 점은 이를 위해 화려한 명령 데크가 필요하지 않다는 것입니다.

00:09:43.680 --> 00:09:50.040
대부분의 사람들이 사용하는 콘솔은 친숙하고 경고하며 조금은 덜 화려한 네트워크, 도구 모음, 그리고 협력체계입니다.

00:09:50.040 --> 00:09:54.520
도구 모음과 협력체계는 에이전트를 단순한 수다쟁이에서 실무자로 바꿔줍니다.

00:09:54.700 --> 00:10:00.720
에이저 파운드리에서 도구 모음은 실질적인 확장 도구의 형태로 제공되어 에이전트가 말에서 행동으로 넘어갈 수 있게 합니다.

00:10:00.940 --> 00:10:06.800
문서 확인 방법이나 계산 실행 방법을 설명하는 대신 에이전트가 직접 수행하고 결과물을 반환할 수 있습니다.

00:10:07.040 --> 00:10:11.740
이러한 차이가 이 플랫폼을 데모에서만 인상적인 것이 아니라 실제 기업 환경에서 가치 있게 만듭니다.

00:10:11.900 --> 00:10:14.480
파운드리는 세 가지 명확한 기능 범주를 제공합니다.

00:10:14.480 --> 00:10:16.140
첫 번째는 내장 도구입니다.

00:10:16.360 --> 00:10:22.680
여기에는 코드 인터프리터, 빈 검색, 셰어포인트 및 마이크로소프트 패브릭 커넥터, 그리고 에이저 AI 서치가 포함됩니다.

00:10:22.860 --> 00:10:29.340
이러한 도구를 사용하면 에이전트는 별도의 복잡한 작업 없이도 데이터를 분석하고 파일을 가져오며 기업 콘텐츠를 검색하고 차트나 보고서까지 생성할 수 있습니다.

00:10:29.500 --> 00:10:34.220
각 도구는 단순한 대화형 응답을 넘어 검토하고 재사용할 수 있는 실질적인 작업 결과물로 범위를 확장합니다.

00:10:34.400 --> 00:10:37.420
둘째, 마이크로소프트가 제공하는 기능에만 얻을 필요가 없습니다.

00:10:37.420 --> 00:10:42.920
파운드리를 사용하면 오픈 API 사양이나 MCP, 모델 컨텍스트 프로토콜을 통해 맞춤형 도구를 등록할 수 있습니다.

00:10:43.080 --> 00:10:46.900
특히 MCP는 AI 도구를 위한 USB-C와 같은 역할을 함으로 중요합니다.

00:10:47.120 --> 00:10:55.340
에이전트를 원격 MCP 서버에 연결할 때 마다 일일이 래퍼를 작성할 필요 없이 시스템이 도구 검색, 버전 관리, 호출을 자동으로 처리합니다.

00:10:55.540 --> 00:11:00.520
이는 특히 수십 개의 시스템을 연결해야 하는 환경에서 통합 오버헤드를 크게 줄여줍니다.

00:11:00.800 --> 00:11:03.800
셋째, 파운드리 위 모든 도구 호출은 관찰 가능합니다.

00:11:03.800 --> 00:11:07.720
호출은 ID, 입력, 출력, 타임스탬프와 함께 단계별로 기록됩니다.

00:11:07.900 --> 00:11:10.860
즉, 이러한 에이전트에 대한 운영 관점이 단순히 믿고 맡기는 마법 같은 것이 아닙니다.

00:11:11.020 --> 00:11:12.020
철저한 기록부입니다.

00:11:12.240 --> 00:11:16.940
무엇이 호출되었는지 정확히 확인하고 적절한 권한을 따랐는지 검증하며 규정 준수를 위한 연구 기록을 유지할 수 있습니다.

00:11:17.140 --> 00:11:19.680
이 범주들을 이해하기 쉽게 퀵 스타트 데모를 떠올려보세요.

00:11:19.960 --> 00:11:22.300
스레드의 메시지로 CSV 파일을 업로드합니다.

00:11:22.520 --> 00:11:26.680
에이전트가 실행 단계 내에서 코드 인터프리터 도구를 호출하여 파일을 처리하고 차트를 생성합니다.

00:11:26.680 --> 00:11:30.320
결과물은 첨부 이미지로 반환되어 스레드 로그에서 바로 볼 수 있습니다.

00:11:30.520 --> 00:11:33.160
직접 파서 나 시각과 도구를 작성할 필요가 없습니다.

00:11:33.500 --> 00:11:38.840
지시만 내리면 에이전트가 도구를 선택하고 실행한 뒤 보고서에 바로 넣을 수 있는 파일을 돌려줍니다.

00:11:39.040 --> 00:11:42.120
이는 이론이 아니라 SDK 샘플의 문서화된 동작입니다.

00:11:42.360 --> 00:11:45.060
이 기능이 진가를 발휘하는 부분은 기업용 통합입니다.

00:11:45.280 --> 00:11:51.060
도구를 로직 앱과 연결할 수 있으므로 에이전트가 1400개 이상의 기존 세스 및 온프레미스 커넥터에 접근할 수 있습니다.

00:11:51.060 --> 00:11:57.400
CRM, ERP, ITSM 플랫폼을 위한 어댑터를 새로 코딩하는 대신 이미 비즈니스에서 운영 중인 커넥터를 구성하면 됩니다.

00:11:57.580 --> 00:11:59.040
확장성을 고려한 전략입니다.

00:11:59.260 --> 00:12:04.260
하나의 에이전트가 깨지기 쉬운 API 브릿지를 직접 작성할 필요 없이 강대한 환경 전반에서 안전하게 작동합니다.

00:12:04.440 --> 00:12:06.380
모두가 다음으로 묻는 질문은 보안입니다.

00:12:06.620 --> 00:12:08.600
파운드리는 이를 핵심에서 다룹니다.

00:12:08.800 --> 00:12:15.720
도구가 시어포인트 나 패브릭 같은 기업 시스템에 연결될 때는 마이크로소프트 엔트라를 통해 중계되는 사용자 위임 인증을 사용합니다.

00:12:15.720 --> 00:12:20.220
어제 파일을 읽을 권한이 없었다면 에이전트도 오늘 마법처럼 그 장벽을 우회할 수는 없습니다.

00:12:20.500 --> 00:12:24.380
아이디와 권한이 그대로 유지되며 이는 규정 준수팀이 수인을 내릴 수 있는 유일한 방법입니다.

00:12:24.580 --> 00:12:25.920
모든 호출은 추적 가능합니다.

00:12:26.120 --> 00:12:26.960
누가 호출했습니까?

00:12:27.180 --> 00:12:28.120
무엇이 전송되었습니까?

00:12:28.320 --> 00:12:29.200
무엇이 수신되었습니까?

00:12:29.380 --> 00:12:31.020
따라서 팀은 항상 증빙자료를 확보하게 됩니다.

00:12:31.200 --> 00:12:34.660
최고의 상황에서의 전체 툴킷은 에이전트 팀을 단순한 흥미거리 이상의 존재로 만듭니다.

00:12:34.840 --> 00:12:39.400
실제 데이터를 조회하고 처리하며 이미 IT 부서에 익숙한 가드레일 내에서 작동하는 유닛을 얻게 됩니다.

00:12:39.400 --> 00:12:44.160
이러한 옵션이 없는 최악의 상황에서는 말만 거창하고 실제 작업은 수행하지 못하는 체포 세션만 남게 될 것입니다.

00:12:44.320 --> 00:12:47.000
그것이 바로 지휘관만큼이나 무기고가 중요한 이유입니다.

00:12:47.160 --> 00:12:53.600
모델과 지침이 에이전트의 사고방식을 결정할 수는 있지만 도구가 책임감 있게 연결되고 신뢰성 있게 기록되지 않는다면 그것은 반쪽짜리 해결책에 불과합니다.

00:12:53.760 --> 00:13:01.980
파운드리 위 내장 도구 세트, MCP, 오픈 API 확장성, 그리고 엔터프라이즈급 보안을 갖추면 단순히 추측성 프롬프트의 나열이 아닌 체계적인 운영기반을 마련할 수 있습니다.

00:13:02.200 --> 00:13:03.600
이제 더 큰 그림을 살펴보겠습니다.

00:13:03.600 --> 00:13:07.300
파운드리 위 에이전트는 단순한 조수나 장난감으로 만들어지지 않았습니다.

00:13:07.460 --> 00:13:12.840
이들은 구조화되고 부하가 고려되며 실제 운영환경에서 유용하게 쓰일 수 있는 장비를 갖춘 관리형 운영자로 설계되었습니다.

00:13:13.100 --> 00:13:14.960
자, 이제 캠페인을 마무리할 시간입니다.

00:13:15.120 --> 00:13:16.180
결론을 내릴 시간이죠.

00:13:16.380 --> 00:13:18.760
파운드리는 단순히 모델의 프롬프트를 던지는 수준이 아닙니다.

00:13:18.920 --> 00:13:22.640
두뇌와 규칙, 그리고 툴킷을 갖춘 에이전트를 반복 가능하게 구축할 방법을 제공합니다.

00:13:22.840 --> 00:13:26.380
에이전트가 수행하는 모든 작업은 스레드, 실행, 실행 단계로 기록됩니다.

00:13:26.380 --> 00:13:29.680
개발 리드와 규정 준수 담당자 모두에게 핵심은 간단합니다.

00:13:29.840 --> 00:13:35.800
렉과 같은 sdk를 통한 재현 가능하고 감사가 가능한 실행으로 전체 라이프 사이클에 대한 제어와 가시성을 확보할 수 있습니다.

00:13:36.020 --> 00:13:42.020
다음 단계로 테스트 프로젝트를 시작하고 기본 에이전트를 생성하여 스레드를 실행한 다음 sdk나 포털에서 실행 단계를 검사해보세요.

00:13:42.240 --> 00:13:44.880
그렇게 하면 로그가 실제 기록과 일치하는지 확인할 수 있습니다.

00:13:45.120 --> 00:13:48.820
이번 영상이 성공적인 배포에 도움이 되었다면 구독하고 알림을 설정하세요.

00:13:49.040 --> 00:13:53.040
아니면 또 다른 클러스터를 제어하는 과정을 보고 싶다면 구독하여 여러분의 에이전트 군단을 정비하세요.