Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Azure AI Foundry Threads: AI를 기업 환경에 맞게 준비하는 방법 (AI 더빙)

Transcript

Azure AI Foundry Threads: AI를 기업 환경에 맞게 준비하는 방법 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

• 0:00
  아무도 말해주지 않는 충격적인 사실이 있습니다.
• 0:02
  에이저 파운드리에 AI를 배포할 때
• 0:04
  단순히 거대한 모델 하나를 실행하는 것이 아닙니다.
• 0:06
  모든 관련 작업, 메시지, 도구 호출,
• 0:08
  실행 단계가 기록되고 추적되는 관리형 런타임의 AI를 배치하는 것입니다.
• 0:12
  스레드, 실행, 실행 단계가 어떻게 실험을 감사 가능하고
• 0:15
  기업 환경에 적합하게 만드는 추적 기록을 형성하는지 확인할 수 있습니다.
• 0:18
  이는 제멋대로였던 AI를 관리 가능한 규율 있는 시스템으로 바꿔줍니다.
• 0:21
  구조가 갖춰졌다면 이제 진짜 질문은
• 0:23
  이 디지털 팀을 누가 이끌 것인가 하는 점입니다.
• 0:26
  팀장을 소개합니다.
• 0:28
  파운드리에서 하나를 설정할 때 단순히 채팅창을 여는 것이 아닙니다.
• 0:31
  팀장을 임명하는 것입니다.
• 0:33
  자동 완성이나 두드리는 인턴이 아닙니다.
• 0:35
  명확한 설계에 따라 임무를 수행하도록 만들어진 현장 지휘관입니다.
• 0:39
  그 설계는 모델, 지침, 도구라는 세 가지 핵심 요소로 귀결됩니다.
• 0:44
  모델은 두뇌입니다.
• 0:45
  추론과 언어를 당당하며 사람의 말을 분석하고
• 0:48
  단계를 계획하며 응답을 작성하는 역할을 합니다.
• 0:51
  지침은 임무 명령입니다.
• 0:52
  이 지침은 두뇌가 자유롭게 날뛰지 않도록 하고
• 0:55
  필요한 결과에 집중하게 합니다.
• 0:57
  도구는 코드 실행, 검색 커넥터, 보고용 API 또는 연결된 타사 시스템처럼
• 1:02
  가슴에 장착된 장비입니다.
• 1:04
  에이저 AI 에이전트는 바로 이 세 가지 요소로 구성됩니다.
• 1:07
  이것이 없으면 재현 가능성이나 감사 가능성을 확보할 수 없습니다.
• 1:10
  그저 증거 없는 텍스트 생성만 남게 될 뿐입니다.
• 1:12
  이를 전장 상황에 비유해보겠습니다.
• 1:14
  모델은 지휘관의 전투 훈련과 같습니다.
• 1:16
  검을 휘두르거나 문장을 완성하는 법을 아는 것이죠.
• 1:19
  지침은 임무 브리핑입니다.
• 1:20
  호송대를 보호하십시오.
• 1:21
  계약서 세트에서 데이터를 추출하십시오.
• 1:23
  결과를 특정 형식으로 보고하십시오.
• 1:25
  이것이 지휘관을 일관되고 예측 가능하게 만듭니다.
• 1:27
  이제 도구는 전문성을 더 해줍니다.
• 1:29
  벽을 오르는 갈고리는 분석을 실행하는 코드 인터프리터와 같습니다.
• 1:33
  보안 무전기는 시어포인트 나 사용자 지정 mcp 커넥터가 실시간 데이터를
• 1:36
  계획에 공급하는 것과 같습니다.
• 1:38
  이 세 가지가 합쳐지면 에이전트는 즉흥적으로 행동하지 않습니다.
• 1:40
  로그와 체크포인트를 통해 임무를 수행하게 됩니다.
• 1:43
  파운드리는 이 메커니즘을 실용적으로 만들어줍니다.
• 1:45
  대부분의 채팅 api는 모델과 프롬프트만 제공합니다.
• 1:48
  대화가 시작되면 명령이나 도구 오케스트레이션에 대한 공식적인 개념이
• 1:51
  없습니다.
• 1:52
  이는 지휘관을 계획이나 장비 없이 전장에 내던지는 것과 같습니다.
• 1:55
  반면 파운드리 에이전트 서비스는 세 가지 계층이 모두 존재함을 보장합니다.
• 1:59
  더 좋은 점은 하나의 두뇌에 얽매일 필요가 없다는 것입니다.
• 2:02
  파운드리 카탈로그에서 모델을 자유롭게 전환할 수 있습니다.
• 2:05
  복잡한 전략에는 gpt4를 가벼운 작업에는 더 효율적인 모델을 또는
• 2:08
  미스트럴이나 딥시클을 도입할 수도 있습니다.
• 2:10
  임무에 맞는 것을 선택하세요.
• 2:12
  이러한 유연성 이야말로 획일적인 인턴과 상황에 적응하는 지휘관의 차이입니다.
• 2:16
  이제 이러한 계층이 없을 때의 위험을 고려해보세요.
• 2:19
  결과 값이 일관되지 않게 됩니다.
• 2:21
  계약서 요약본이 하나는 이렇게 읽히고 다음은 미묘하게 내용을 반박하는
• 2:24
  식이죠.
• 2:24
  답변이 어떻게 도출되었는지 기록하는 구조화된 로그가 없어 추적성을
• 2:28
  잃게 됩니다.
• 2:28
  개발자가 추론 과정을 다시 추적할 수 없어 디버깅이 추측 게임으로
• 2:31
  변합니다.
• 2:32
  기업 환경에서 이는 단순한 불편함이 아닙니다.
• 2:34
  신뢰와 도입을 가로막는 실질적인 위험입니다.
• 2:36
  파운드리는 이를 명확한 방식으로 해결합니다.
• 2:39
  바드레일이 에이전트 내부에 구축되어 있습니다.
• 2:41
  지침은 반드시 따라야 하는 고정된 규칙집 역할을 합니다.
• 2:43
  도구 세트는 사용 사례에 따라 범위를 좁히거나 확장할 수 있습니다.
• 2:47
  모델은 자유롭게 교체할 수 있지만 항상 책임을 강제하는 구조 안에서
• 2:51
  이루어집니다.
• 2:52
  이 세 가지가 결합되어 규율 잡힌 분대장, 예측 가능한 결과, 가시적
• 2:55
  인단계, 그리고 엔터프라이즈 커넥터와 사용자 지정 api를 통한 책임
• 2:59
  있는 확장성을 제공합니다.
• 3:00
  이것은 ai를 마법 같은 대화로 포장하려는 것이 아닙니다.
• 3:03
  조직의 로그를 실행하고 명령을 따르며 적절한 장비를 갖춘 노련한
• 3:07
  장교를 제공함을 보여주는 것입니다.
• 3:08
  훌륭한 선장처럼 모든 임무에서 일어난 일을 꼼꼼하게 기록합니다.
• 3:12
  시스템을 감사하거나 오류가 발생했을 때 그 일지가 필요하기 때문입니다.
• 3:15
  파운드리에서 그 일지는 이름이 있습니다.
• 3:17
  바로 스레드, 스레드 라고 합니다.
• 3:19
  스레드, 즉 전장의 로그입니다.
• 3:21
  스레드는 임무 로그가 형태를 갖추기 시작하는 곳입니다.
• 3:24
  에이저 파운드리에서 스레드는 닫으면 사라지는 일반적인 채팅창이 아닙니다.
• 3:28
  지속적인 대화 세션입니다.
• 3:29
  사용자, 에이전트 또는 멀티 에이전트 설정에 다른 에이전트 간의 모든 교환 내용이 여기에 저장됩니다.
• 3:36
  이것이 전장의 로그로서 채팅이 끝난 후에도 오랫동안 검토할 수 있는 연구적인 상호작용 기록을 유지합니다.
• 3:41
  진정한 강점은 스레드가 단순한 정적 대화록이 아니라는 점입니다.
• 3:45
  스레드는 자동 절단을 처리하는 구조화된 컨테이너로
• 3:47
  모델 제한 내에서 활성 컨텍스트를 유지하면서도 전체 감사 추적을 보존합니다.
• 3:52
  이는 에이전트가 진행 중인 대화를 계속 이해하는 동시에
• 3:55
  기업은 검토 가능한 연구 기록을 유지한다는 의미입니다.
• 3:58
  대부분의 채팅 앱과 달리 그 무엇도 허공으로 사라지지 않습니다.
• 4:01
  에이전트에게는 연속성을, 기업에게는 거버넌스를 제공합니다.
• 4:04
  그 로그의 항목들은 메시지로 구성됩니다.
• 4:06
  메시지는 일반 텍스트에 국한되지 않습니다.
• 4:09
  이미지, 스프레드 시트 파일 또는 생성된 코드 블록을 포함할 수 있습니다.
• 4:12
  각 메시지에는 타임 스탬프가 지키고 사용자 또는 어시스턴트라는 역할이 네이블로 지정됩니다.
• 4:16
  따라서 스레드를 검토하면 단순히 대화 내용뿐만 아니라
• 4:19
  누가 언제 말했는지, 어떤 유형의 콘텐츠가 포함되었는지까지 확인할 수 있습니다.
• 4:23
  컴플라이언스 담당자가 기록을 열어 어제 제출된 정확한 텍스트 요청,
• 4:27
  에이전트가 그의 대응에 생성한 차트 이미지,
• 4:29
  그리고 두 사건이 발생한 시간을 확인하는 모습을 상상해보세요.
• 4:32
  그것은 기억 그 이상이며, 완전한 실시간 장부와 같습니다.
• 4:34
  게임 용어로 비유하자면,
• 4:36
  스레드는 던전 앤 드래곤 캠페인의 기록장과 같습니다.
• 4:38
  던전 마스터는 어느 마을을 방문했는지,
• 4:40
  어떤 주사위 굴림이 성공했는지,
• 4:42
  어떤 전리품을 획득했는지 기록합니다.
• 4:43
  그런 기록이 없으면,
• 4:44
  플레이어들은 잊어버린 세부사항을 두고 말다툼을 벌이게 됩니다.
• 4:47
  기록이 있으면 사건이 문서화되어 있으므로 논쟁이 사라집니다.
• 4:50
  스레드는 엔터프라이즈 AI에서도 동일한 역할을 합니다.
• 4:52
  모든 것이 순서대로 기록되기 때문에,
• 4:53
  에이전트가 실제로 무엇을 했는지에 대한 분쟁을 방지합니다.
• 4:56
  이제 왜 그러한 기록이 중요한지 설명하겠습니다.
• 4:58
  감사 및 규정 준수 측면에서 스레드는 그야말로 금과 같습니다.
• 5:01
  규제기관이나 내부 감사팀은 스레드를 열어 전체 시퀀스,
• 5:03
  사용자 요청, 에이전트 응답,
• 5:05
  어떤 도구가 사용되었는지,
• 5:06
  그리고 언제 모든 일이 일어났는지 즉시 확인할 수 있습니다.
• 5:08
  개발자에게의 동일한 기록은 디버그 모드와 같은 기능을 합니다.
• 5:11
  에이전트가 잘못된 코드 조각을 생성했다면,
• 5:13
  스레드를 요청 시점으로 되돌려 정확히 어떻게 그런 결과에 도달했는지 확인할 수 있습니다.
• 5:17
  두 그룹 모두 가시성을 확보하게 되며,
• 5:19
  시간 낭비도 피할 수 있을 것입니다.
• 5:20
  대화 내용을 저장하지 않는 시스템과 비교해 보십시오.
• 5:23
  스레드가 없으면 스크린샷이나 희미한 기억의 의존의 동작을 추적해야 합니다.
• 5:27
  이는 컴플라이언스 팀이 증거를 요청하거나,
• 5:29
  지원팀이 버그를 재현해야 할 때 아무런 도움이 되지 않습니다.
• 5:32
  마치 게임에서 보스전을 다시 하라는 말을 듣고 보니,
• 5:34
  저장을 전혀 안 했다는 사실을 깨닫는 것과 같습니다.
• 5:37
  기록이 없으면 증거도 없고, 흔적이 없으면 수정도 불가능합니다.
• 5:40
  최악의 상황에서는 말뿐인 약속으로 이해관계자들을 안심시켜야 하는 처지가 됩니다.
• 5:44
  파운드리 위 스레드를 사용하면 그러한 함정에서 벗어날 수 있습니다.
• 5:47
  각 대화는 구조화된 증거가 됩니다.
• 5:49
  워크플로우가 법률문구를 불러오면,
• 5:51
  기록에는 원래 요청, 생성된 특정 답변, 그리고 지원 도구가 호출되었는지 여부가 표시됩니다.
• 5:57
  여러 에이전트가 작업을 분담하기 위해 서로 대화하는 경우,
• 6:00
  그들의 주고받은 내용도 기록됩니다.
• 6:02
  기업은 규정 준수를 증명하고, 개발자는 버그를 정확히 찾아내며,
• 6:05
  관리자는 시스템의 결과물이 책임질 수 있는 것임을 신뢰할 수 있습니다.
• 6:08
  바로 이 지점에서 스레드는 무질서한 대화를 프로덕션 수준의 결과물로 탈바꿈시킵니다.
• 6:12
  일시적인 대화 대신, 스레드는 임무와 결정에 대한 안정적인 이력을 생성하여 신뢰할 수 있는 기반을 마련합니다.
• 6:17
  하지만 기억하십시오.
• 6:19
  로그는 여전히 일기에 불과합니다.
• 6:20
  진정한 행동은 에이전트가 스레드에 기록된 내용을 받아 실제로 실행할 때 시작됩니다.
• 6:24
  다음 단계는 임무가 종이 위에 기록에서 멈추지 않고 실시간으로 실현되기 시작하는 지점입니다.
• 6:28
  런, 런,과 런스텝은 주사위를 던지는 것과 같습니다.
• 6:31
  런은 임무가 마침내 시작되는 곳입니다.
• 6:33
  파운드리의 용어로, 스레드는 대화의 백로그, 명령, 맥락, 스크롤된 지도를 담고 있습니다.
• 6:39
  런은 에이전트가 그 맥락을 가져와 실제로 실행하도록 활성화하는 트리거입니다.
• 6:43
  스레드는 기억하고, 런은 행동합니다.
• 6:45
  런을 발사 버튼이라고 생각하세요.
• 6:46
  스레드에는 csv를 분석해라, 라고 적혀있을지도 모릅니다.
• 6:49
  아니면 선 그래프를 그리라고 할 수도 있죠.
• 6:51
  하지만 런은 에이전트가 모델 지침과 도구를 통해 해당 요청을 처리하는 순간입니다.
• 6:55
  추가 데이터를 가져오거나, 수치를 계산하거나, 코드 인터프리터를 호출하여 아티팩트를 생성할 수 있습니다.
• 7:00
  테이블 탑 알피지 용어로 말하자면, 스레드는 파티가 테이블 주위에 모여 계획을 짜는 것입니다.
• 7:04
  런은 전투를 시작하는 선제권 주사위 분리기와 같습니다.
• 7:07
  그것 없이는 아무것도 진행되지 않습니다.
• 7:09
  파운드리는 바로 이 점을 명확히 합니다.
• 7:11
  런은 블랙박스가 아닙니다.
• 7:12
  런은 모니터링되고 상태가 추적되는 실행 과정입니다.
• 7:15
  일반적으로 대기 중, 진행 중, 작업 필요, 완료 또는 실패와 같은 상태를 볼 수 있습니다.
• 7:19
  SDK 샘플은 게임 마스터가 턴 순서를 확인하는 것처럼 루프 내에서 이러한 상태를 자주 폴링합니다.
• 7:24
  이를 통해 무엇이 완료되는지 뿐만 아니라 언제 발생하는지에 대한 가시성을 확보할 수 있습니다.
• 7:28
  하지만 더 큰 고민은 이건입니다.
• 7:30
  실행 내부에서 실제로 무슨 일이 일어났는지 어떻게 알 수 있을까요?
• 7:33
  답변은 괜찮아 보일지 몰라도, 세부 정보가 없으면 에이전트가 외부 API를 호출했는지, 코드를 작성했는지, 아니면 그냥 텍스트를 지어냈는지 알 수 없습니다.
• 7:39
  그러한 불투명함은 기업 환경에서 위험합니다.
• 7:41
  이는 체스 경기에 들어가서 게임 도중에 보드를 보고, 우리를 믿으세요, 올바른 수였어요, 라는 말을 듣는 것과 같습니다.
• 7:47
  다시 재생할 수도 없습니다.
• 7:48
  그 수가 정당했는지 알 길이 없습니다.
• 7:50
  런스텝은 그러한 추측을 제거해줍니다.
• 7:52
  모든 런은 어떤 모델 출력이 생성되었고, 어떤 도구가 호출되었으며, 어떤 계산이 실행되었고, 어떤 메시지가 생성되었는지 단계별로 기록됩니다.
• 7:59
  이것은 AI를 위한 체스 표기법과 같습니다.
• 8:01
  폰을 이사로, 나이트를 F6으로 옮기는 것과 같죠.
• 8:04
  여기서는 10시 2분의 파일 가져오기, 10시 3분의 코드 블록 실행, 10시 4분의 그래프 아티팩트 반환으로 기록됩니다.
• 8:09
  각 동작이 순서대로 기록되므로 나중에 다시 재생할 수 있습니다.
• 8:12
  이러한 구조는 개발자들에게 큰 안도감을 줍니다.
• 8:15
  런스텝이 없다면, 최종 답변만 보고 그것이 어떻게 도출되었는지 전혀 알 수 없게 됩니다.
• 8:18
  검색커리가 잘못되었나요? 수학적 오류가 끼어들었나요? 결국 추측만 하게 됩니다.
• 8:23
  런스텝을 사용하면 타임라인을 스크롤하여 정확한 오류 지점을 식별하고 수정할 수 있습니다.
• 8:27
  디버깅은 추측이 아닌 포렌식이 됩니다.
• 8:29
  이는 누가 공격했는지 알 수 없는 안개 속의 보스전과 모든 칼 휘두르기와 주문 시전이 기록된 전투로그의 차이와 같습니다.
• 8:36
  컴플라이언스 팀에게도 큰 이점이 있습니다.
• 8:39
  감사인이 요약이 어떻게 생성되었나요? 라고 물어볼 때 모델의 추론 과정을 추상적으로 설명할 필요가 없습니다.
• 8:44
  증빙 자료가 있으니까요.
• 8:46
  도구 호출, 인터프리터 단계, 구성된 답변까지 모두 타임스탬프가 찍혀 있습니다.
• 8:50
  이는 설명을 거버넌스로 전환합니다.
• 8:52
  이야기를 지어내는 대신 증거를 제시하는 것이죠.
• 8:54
  기업들은 이를 통해 위험이 책임으로 약속이 증명으로 바뀐다는 점을 매우 선호합니다.
• 8:58
  일상적인 운영에서 실행 단계는 신뢰할 수 있는 재현 가능한 패턴을 만들어냅니다.
• 9:03
  워크플로우를 다시 실행해야 할 경우 동일한 순서를 그대로 따를 수 있습니다.
• 9:06
  결과에 이의가 제기되면 다시 재현해볼 수 있습니다.
• 9:09
  성공적인 경우 전체 실행 단계가 포함된 실행 결과는 출력물이 어떻게 만들어졌는지에 대한 감사 가능하고 재현 가능한 증거를 제공합니다.
• 9:14
  다른 시스템에서 실패할 경우 남는 것은 추적할 수 없는 모호한 출력물뿐입니다.
• 9:18
  이것이 에이전트 수명 주기의 부분이 중요한 이유입니다.
• 9:20
  스레드라는 일기, 실행이라는 활성화, 그리고 실행 단계라는 동작 기록이 있습니다.
• 9:25
  이 요소들은 즉흥적인 AI를 추적, 테스트, 방어할 수 있는 책임감 있는 팀원으로 바꿔줍니다.
• 9:30
  물론 이러한 세부 정보가 존재한다는 것을 아는 것만으로는 부족합니다.
• 9:33
  원시 API 호출에 파묻히지 않고 에이전트를 실행하고 실행을 트리거하며 실행 단계를 읽어드릴 수 있는 구조화된 상호작용 방식이 필요합니다.
• 9:40
  놀라운 점은 이를 위해 화려한 명령 데크가 필요하지 않다는 것입니다.
• 9:43
  대부분의 사람들이 사용하는 콘솔은 친숙하고 경고하며 조금은 덜 화려한 네트워크, 도구 모음, 그리고 협력체계입니다.
• 9:50
  도구 모음과 협력체계는 에이전트를 단순한 수다쟁이에서 실무자로 바꿔줍니다.
• 9:54
  에이저 파운드리에서 도구 모음은 실질적인 확장 도구의 형태로 제공되어 에이전트가 말에서 행동으로 넘어갈 수 있게 합니다.
• 10:00
  문서 확인 방법이나 계산 실행 방법을 설명하는 대신 에이전트가 직접 수행하고 결과물을 반환할 수 있습니다.
• 10:07
  이러한 차이가 이 플랫폼을 데모에서만 인상적인 것이 아니라 실제 기업 환경에서 가치 있게 만듭니다.
• 10:11
  파운드리는 세 가지 명확한 기능 범주를 제공합니다.
• 10:14
  첫 번째는 내장 도구입니다.
• 10:16
  여기에는 코드 인터프리터, 빈 검색, 셰어포인트 및 마이크로소프트 패브릭 커넥터, 그리고 에이저 AI 서치가 포함됩니다.
• 10:22
  이러한 도구를 사용하면 에이전트는 별도의 복잡한 작업 없이도 데이터를 분석하고 파일을 가져오며 기업 콘텐츠를 검색하고 차트나 보고서까지 생성할 수 있습니다.
• 10:29
  각 도구는 단순한 대화형 응답을 넘어 검토하고 재사용할 수 있는 실질적인 작업 결과물로 범위를 확장합니다.
• 10:34
  둘째, 마이크로소프트가 제공하는 기능에만 얻을 필요가 없습니다.
• 10:37
  파운드리를 사용하면 오픈 API 사양이나 MCP, 모델 컨텍스트 프로토콜을 통해 맞춤형 도구를 등록할 수 있습니다.
• 10:43
  특히 MCP는 AI 도구를 위한 USB-C와 같은 역할을 함으로 중요합니다.
• 10:47
  에이전트를 원격 MCP 서버에 연결할 때 마다 일일이 래퍼를 작성할 필요 없이 시스템이 도구 검색, 버전 관리, 호출을 자동으로 처리합니다.
• 10:55
  이는 특히 수십 개의 시스템을 연결해야 하는 환경에서 통합 오버헤드를 크게 줄여줍니다.
• 11:00
  셋째, 파운드리 위 모든 도구 호출은 관찰 가능합니다.
• 11:03
  호출은 ID, 입력, 출력, 타임스탬프와 함께 단계별로 기록됩니다.
• 11:07
  즉, 이러한 에이전트에 대한 운영 관점이 단순히 믿고 맡기는 마법 같은 것이 아닙니다.
• 11:11
  철저한 기록부입니다.
• 11:12
  무엇이 호출되었는지 정확히 확인하고 적절한 권한을 따랐는지 검증하며 규정 준수를 위한 연구 기록을 유지할 수 있습니다.
• 11:17
  이 범주들을 이해하기 쉽게 퀵 스타트 데모를 떠올려보세요.
• 11:19
  스레드의 메시지로 CSV 파일을 업로드합니다.
• 11:22
  에이전트가 실행 단계 내에서 코드 인터프리터 도구를 호출하여 파일을 처리하고 차트를 생성합니다.
• 11:26
  결과물은 첨부 이미지로 반환되어 스레드 로그에서 바로 볼 수 있습니다.
• 11:30
  직접 파서 나 시각과 도구를 작성할 필요가 없습니다.
• 11:33
  지시만 내리면 에이전트가 도구를 선택하고 실행한 뒤 보고서에 바로 넣을 수 있는 파일을 돌려줍니다.
• 11:39
  이는 이론이 아니라 SDK 샘플의 문서화된 동작입니다.
• 11:42
  이 기능이 진가를 발휘하는 부분은 기업용 통합입니다.
• 11:45
  도구를 로직 앱과 연결할 수 있으므로 에이전트가 1400개 이상의 기존 세스 및 온프레미스 커넥터에 접근할 수 있습니다.
• 11:51
  CRM, ERP, ITSM 플랫폼을 위한 어댑터를 새로 코딩하는 대신 이미 비즈니스에서 운영 중인 커넥터를 구성하면 됩니다.
• 11:57
  확장성을 고려한 전략입니다.
• 11:59
  하나의 에이전트가 깨지기 쉬운 API 브릿지를 직접 작성할 필요 없이 강대한 환경 전반에서 안전하게 작동합니다.
• 12:04
  모두가 다음으로 묻는 질문은 보안입니다.
• 12:06
  파운드리는 이를 핵심에서 다룹니다.
• 12:08
  도구가 시어포인트 나 패브릭 같은 기업 시스템에 연결될 때는 마이크로소프트 엔트라를 통해 중계되는 사용자 위임 인증을 사용합니다.
• 12:15
  어제 파일을 읽을 권한이 없었다면 에이전트도 오늘 마법처럼 그 장벽을 우회할 수는 없습니다.
• 12:20
  아이디와 권한이 그대로 유지되며 이는 규정 준수팀이 수인을 내릴 수 있는 유일한 방법입니다.
• 12:24
  모든 호출은 추적 가능합니다.
• 12:26
  누가 호출했습니까?
• 12:27
  무엇이 전송되었습니까?
• 12:28
  무엇이 수신되었습니까?
• 12:29
  따라서 팀은 항상 증빙자료를 확보하게 됩니다.
• 12:31
  최고의 상황에서의 전체 툴킷은 에이전트 팀을 단순한 흥미거리 이상의 존재로 만듭니다.
• 12:34
  실제 데이터를 조회하고 처리하며 이미 IT 부서에 익숙한 가드레일 내에서 작동하는 유닛을 얻게 됩니다.
• 12:39
  이러한 옵션이 없는 최악의 상황에서는 말만 거창하고 실제 작업은 수행하지 못하는 체포 세션만 남게 될 것입니다.
• 12:44
  그것이 바로 지휘관만큼이나 무기고가 중요한 이유입니다.
• 12:47
  모델과 지침이 에이전트의 사고방식을 결정할 수는 있지만 도구가 책임감 있게 연결되고 신뢰성 있게 기록되지 않는다면 그것은 반쪽짜리 해결책에 불과합니다.
• 12:53
  파운드리 위 내장 도구 세트, MCP, 오픈 API 확장성, 그리고 엔터프라이즈급 보안을 갖추면 단순히 추측성 프롬프트의 나열이 아닌 체계적인 운영기반을 마련할 수 있습니다.
• 13:02
  이제 더 큰 그림을 살펴보겠습니다.
• 13:03
  파운드리 위 에이전트는 단순한 조수나 장난감으로 만들어지지 않았습니다.
• 13:07
  이들은 구조화되고 부하가 고려되며 실제 운영환경에서 유용하게 쓰일 수 있는 장비를 갖춘 관리형 운영자로 설계되었습니다.
• 13:13
  자, 이제 캠페인을 마무리할 시간입니다.
• 13:15
  결론을 내릴 시간이죠.
• 13:16
  파운드리는 단순히 모델의 프롬프트를 던지는 수준이 아닙니다.
• 13:18
  두뇌와 규칙, 그리고 툴킷을 갖춘 에이전트를 반복 가능하게 구축할 방법을 제공합니다.
• 13:22
  에이전트가 수행하는 모든 작업은 스레드, 실행, 실행 단계로 기록됩니다.
• 13:26
  개발 리드와 규정 준수 담당자 모두에게 핵심은 간단합니다.
• 13:29
  렉과 같은 sdk를 통한 재현 가능하고 감사가 가능한 실행으로 전체 라이프 사이클에 대한 제어와 가시성을 확보할 수 있습니다.
• 13:36
  다음 단계로 테스트 프로젝트를 시작하고 기본 에이전트를 생성하여 스레드를 실행한 다음 sdk나 포털에서 실행 단계를 검사해보세요.
• 13:42
  그렇게 하면 로그가 실제 기록과 일치하는지 확인할 수 있습니다.
• 13:45
  이번 영상이 성공적인 배포에 도움이 되었다면 구독하고 알림을 설정하세요.
• 13:49
  아니면 또 다른 클러스터를 제어하는 과정을 보고 싶다면 구독하여 여러분의 에이전트 군단을 정비하세요.