mc65 fm 팟캐스트에 오신 여러분 모두 환영합니다. 오늘은 마이크로소프트 365 코파일럿 프론프트 엔지니어링과 관련하여 가장 흔히 논의되는 주제 중 하나를 다뤄보겠습니다.한 기업에서 코파일럿을 본격적으로 사용하기 시작하면서 어떻게 하면 더 나은 프론프트를 작성할 수 있을까? 라는 질문에서 코파일럿을 우리 회사에서 실제로 실행되는 애플리케이션, 데이터, 앱, 비즈니스 프로세스 및 지식에 어떻게 연결할 수 있을까?라는 질문으로 빠르게 바뀌었습니다. 바로 이 지점에서 코파일럿 확장성 테스트가 중요해집니다.오늘 게스트는 스위스에 있는 AI IT 그룹의 마이크로소프트 MVP이자 비즈니스 애플리케이션 컨설턴트인 에바스 하베스트입니다.에바스는 마이크로소프트 365, 에이저 다이나믹스 365 및 파워 플랫폼 전반에서 활동하며 특히 에이전트 및 사용자 지정 개발을 통해 마이크로소프트 365 코파일럿을 확장하는 데 중점을 두고 있습니다.오늘 우리는 마이크로소프트 365 코파일럿 확장성, 코파일럿 스튜디오, 마이크로소프트 에이저 파운드리, 이름이 정확히 기억나지 않지만 마이크로소프트 그래프, MCPS 등에 대해 살펴보겠습니다.네, MC65 팟캐스트에 오신 것을 환영합니다.안녕하세요, 여러분.초대해 주셔서 감사합니다.이렇게 좋은 기회를 갖게 되어 정말 기쁩니다.초대해 주셔서 감사합니다.네, 감사합니다.본격적인 기술적인 이야기를 하기 전에 어떻게 마이크로소프트 생태계에 합류하게 되셨는지 간략하게 말씀해 주시겠어요?네, 네, 물론이죠.사실 저는 마이크로소프트에서 경력을 시작한 건 아니었어요.

애플에서 맥 플랫폼 소프트웨어 엔지니어로 일하다가 iOS 쪽으로 옮겼죠.그리고 꽤 오래 전, 아마 15년이나 20년 전 쯤일 거예요.마이크로소프트로 이직하게 됐습니다.솔직히 말해서 샤프에서 경력을 시작했고, 그 후 클라우드, 애저, M3 요구 쪽으로 옮겼습니다.음, 제가 온 프레미스 환경에서 시작했다면 이랬을 겁니다.그리고 클라우드 서비스로 옮겨갔고, 마지막으로는 파워 플랫폼, 그리고 가장 최근에는 AI 관련 기술들을 다루게 되었습니다.솔직히 말씀드리면, AI는 이제 M2고 위 큰 부분을 차지하고 있기 때문입니다.왜냐하면 이제는 자동화된 전환이 이루어졌기 때문이죠.간단히 말해서 이것이 제 여정을 요약한 것입니다.저는 소프트웨어 엔지니어링 분야에서 경력을 시작했는데, 오늘날.많은 사람들이 이 용어를 잊어버리는 것 같습니다.왜냐하면 지금은 AI 관련 기술들이 많아졌고, 이러한 활동이나 직종들이 AI 분야로 이동했기 때문입니다.그래서 20년 전과는 상당히 다릅니다.

네, SharePoint와 GraphSpeak Dynamic Power Platform을 다루신다고 하셨는데,이러한 배경이 현재의 AI 개발 환경에 어떻게 도움이 되었나요?

음, 기본적으로 제 프로필은 정말 다방면에 걸쳐있다고 할 수 있어요.왜냐하면 저는 경력 내내 정말 다양한 제품을 다뤄왔거든요.마이크로소프트 제품이든 아니든 말이죠.그래서 기본적으로 저는 다양한 기술과 도구에 대한 폭넓은 스킬을 보유하고 있습니다.이러한 모든 경험들이 제게 좋은 배경을 만들어주었어요.

특히 지금의 AI는 여러 접근 방식과 기술이 존재하는 백지 상태와 같죠.

에이전트 방식도 있고, 워크플로우 방식도 있고, 여러 가지가 있잖아요.솔직히 말해서 제 이전 직무 경험들은 지금의 AI 전환에 필요한 많은 스킬을 쌓는 데 도움이 되었어요.로우코드 개발부터 비프로세스 코드 개발까지 다양한 분야를 경험했거든요.네, 이러한 모든 기회와 활동들이 AI 분야에서 성공하는 데 필요한 스킬을 갖추는 데 큰 도움이 되었습니다.그리고 지금 당신은 AI 테스트 리더 시네요. AI 테스트 리더는 구체적으로 어떤 일을 하나요?음.정말 좋은 질문이에요.많은 분들이 저에게 물어보시거든요.제 업무는 기능.

명세와 기술 스택을 연결하는 거예요.비즈니스.분석이 완료되면 제가 주도적으로 나서죠. AI.

관련 사용 사례와 시나리오를 정의하고 비즈니스 분석을 모두 마친 후에 저는 이러한 요구 사항들을 기술 스택에 맞춰 연결하는 역할을 합니다.

그리고 개발 준비가 완료되면 도구와 솔루션 구현을 총괄하죠.네, 흥미롭네요.사실 많은 회사들이 직원들에게 교육을 제공하는데 특히 신속 엔지니어링 분야에 집중적으로 교육을 시키는 것 같아요.그런데 왜 그것만으로는 부족하다고 생각하시나요?

요즘은 신속 엔지니어링만 교육하는 시대인가요?네, 왜, 왜, 왜, 왜, 그들은 왜, 그건 단지 아시다시피회사 입장에서는 사람들에게 즉각적인 엔지니어링 기술만 가르치는 것으로는 충분하지 않기 때문이죠.아, 네, 알겠습니다.네, 네, 응.

솔직히 말해서 요즘에는 제가 전에 말씀드렸듯이 다양한 도구와 기술이 많습니다.그래서 기본적으로 AI는 어느 시점에서는 무엇을 해야 할지 이해하고 어느 정도 안내해 줄 수 있습니다.하지만 제 생각에는 예를 들어 아키텍트나 소프트웨어 설계자의 역할에는 고객을 이해해야 하기 때문에 뒤에 사람이 있어야 합니다.

기본적으로 AI는 때때로 고객의 맥락을 이해하지 못합니다.음, 보시다시피 전체 네트워크는 보이지만그 이면에는 즉각적인 엔지니어링에만 집중하는 것이 좋을 수도 있지만더 많은 것이 필요합니다.왜냐하면 그 이면에는 아키텍트, 소프트웨어 엔지니어, 그리고 시어포인트, 온드라이브, 세일즈포스와 같은정보 기술 분야의 전문가들이 필요하기 때문입니다.

AI는 많은 것을 이해하고 안내해 줄 수 있으며훌륭한 기술 또는 기능 문서를 생성할 수 있지만그 문서가 제대로 만들어졌는지 고객의 요구에 부합하는지 등을 검토하고 검증하는 사람이 필요합니다.

그래야만 즉각적인 엔지니어링에만 집중할 수 있는 것이죠.제 생각에는, 네, 시간적 여유가 없거나 특정 기술 습득에 투자할 여력이 없다면하나의 선택지가 될 수 있을 것 같습니다.

하지만 제 생각에는 솔루션을 구축하려는 분야의 기초 기술에 대한 탄탄한 실력이 필요하다고 생각합니다.

네, 그리고 코파일럿 확장성 전문가이신데표준 코파일럿 마이크로소프트 365 코파일럿은 어디까지 확장되고코파일럿 확장성은 어디서부터 시작되는 건가요?네, 좋은 질문입니다.솔직히 말해서 2년 전 코파일럿이 처음 출시되었을 때아마도 첫 번째 버전이었을 텐데채팅 기능이 정말 최소한에 그쳤습니다.기본적으로 GPT 기반의 채팅이었죠.하지만 마이크로소프트는 마이크로소프트 365 코파일럿을 많이 발전시켰습니다.기본적으로 지금은 다양한 기능을 갖추고 있지만확장성은 예전보다 떨어졌습니다.예전에는 플러그인 등을 개발할 수 있었지만솔직히 말해서 지금은 확장성이란 무언가를 구축하고 사용자 정의하고 싶을 때예를 들어 오케스트레이터를 사용자 정의하거나사용자 인터페이스를 좀 더 개인화하고 싶을 때또는 상담원을 마이크로소프트 365 채팅뿐만 아니라웹사이트에도 통합하고 싶을 때를 말합니다.

즉, 확장성은 백그라운드에서 더 많은 사용자 정의를 원할 때 시작됩니다.오케스트레이터를 사용자 정의하거나인터페이스를 사용자 정의하거나코파일럿 채팅이 기본적으로 할 수 없는 기능예, SN응답을 사용자 정의하고 싶을 때 확장성이 발휘됩니다.

많은 사람들이 상담원에 대해 이야기하는 부분입니다.음, 뭐죠? 뭐죠? 왜죠?왜 지금 이렇게 많은 에이전트가 코파일럿 에이전트에 의존하는 걸까요?그리고 왜 모든 걸 위한 하나의 큰 코파일럿을 만들지 않는 걸까요?네, 정말 흥미로운 질문입니다.솔직히 말해서 마이크로소프트는 앞서 말씀드린 것처럼 많이 발전했습니다.아마 6개월 전만 해도 에이전트는 그저 화제거리였을 겁니다.하지만 이제 마이크로소프트는 코파일럿 코워크를 도입했고솔직히 말해서 요즘 코파일럿 코워크는 많은 에이전트를 대체할 수 있습니다.

에이전트라는 용어는 단지 구분을 위한 것일 뿐입니다.이제 우리는 각 에이전트가 자신의 범위와 책임을 갖는멀티 에이전트 모델에 더 집중하고 있습니다.그리고 큰 코파일럿을 만들지 않는 이유는 기본적으로 성능 때문입니다.첫째, 명령어와 도구가 너무 많으면 성능 면에서 문제가 발생할 수 있습니다.그리고 요즘 아키텍처는 멀티 에이전트 방식입니다.코파일럿 스튜디오를 사용할 수도 있고직접 코드를 작성하거나 사용자 정의 개발을 통해 에이전트를 구현할 수도 있습니다.하지만 요즘에는 각 에이전트가 성능 측면에서자신의 범위와 책임을 갖는 멀티 에이전트 접근 방식이 더 좋습니다.또한 에이전트 아키텍처를 명확하게 정의하는 것이 중요합니다.

네, 그렇습니다.

기본적인 AI 에이전트 아키텍처를 생각해보면예를 들어 비밀번호를 처리한다고 가정해보겠습니다.하지만 추론, 도구, 지식, 그리고 명령어를 어떻게AI 에이전트 아키텍처에 통합할지 생각해봐야 합니다.

가장 먼저 답해야 할 질문은 바로 이 에이전트의 목표는 무엇인가?

입니다.

기본적으로 에이전트 아키텍처는로우 코드 방식 인지 커스텀 개발 방식 인지에 따라 크게 달라집니다.

커스텀개발 방식에서는 보안, 호스팅 등 모든 것을 직접 관리해야 합니다.반면 로우 코드 방식에서는 명령어를 입력하고필요한 도구를 선택하는 방식으로 간단하게 구현할 수 있습니다.

로우 코드 방식의 아키텍처는 생각만큼 간단하지는 않지만명령어를 정의하고 도구를 선택하거나연결하려는 다른 에이전트를 선택하는 등빠른 속도를 제공할 수 있습니다.하지만 커스텀 개발 방식, 즉 시멘틱 커널 이나에이전트 파머와 같은 도구를 직접 개발하는 경우에는 훨씬 간단합니다.아크틱 아키텍처는 보안과 같은 고급 개념을 다뤄야 하기 때문에 훨씬 더 복잡할 수 있습니다.

예를 들어 여러 도구를 사용하고ncp를 통합하거나 리버스 프록시로 보호되는 내부 도구에 연결하려는 경우인증 측면에서 더욱 그렇습니다.

따라서 코파일럿 스튜디오와 같은 환경에서사용자 지정 에이전트를 다룰 때는아키텍처 측면에서 더 많은 것을 고려해야 합니다.사용자 지정 개발 방식을 사용하면 아키텍처를 빠르게 정의할 수 있지만고급 개념을 다뤄야 함으로많은 사람들에게는 기초적인 부분이 어려워 보일 수 있습니다.

솔직히 말씀드리면 저는 다양한 요구사항을 다뤄왔습니다.커스텀 개발일 수도 있고코파일럿 스튜디오일 수도 있고에이전트 빌더에서 아주 간단하고 깔끔한 에이전트를 만들 수도 있습니다.기본적으로 아키텍처를 정의하는 것은어떤 접근방식을 택하느냐에 따라 달라집니다.기본적으로 일반적인 아키텍처를 만들 수는 있지만그 후에는 로우 코드 방식 인지 포 코드 방식 인지에 따라 결정됩니다.네, 네, 음일반적인 엔터프라이즈 AI 에이전트의 구조를 설명해 주시겠습니까?네, 가능합니다.

간단히 말해서예를 들어 IT 지원 에이전트와 같은 요구사항이 있을 때기본적으로 여러 에이전트가 있을 수 있습니다.

하지만 요즘에는 말씀드린 것처럼멀티 에이전트 방식을 사용하고 있으며저는 첫 번째 에이전트를 프런트엔드, 즉 최전선에 배치합니다.그러니까 이 담당자가 프런트 에이전트이고이 프런트 에이전트는 모든 요청을 예를 들어 다른 에이전트로 라우팅합니다.예를 들어 사용자가 세일즈포스 관련 질문을 하면이 담당자는 모든 요청을 세일즈포스 IT 지원 담당자에게 전달합니다.보시다시피 저희는 일부 고객을 위해 이러한 아키텍처를 구축했는데각 에이전트가 담당하는 범위가 다르기 때문입니다.

세일즈포스나 M365 같은 제품일 수도 있습니다.그리고 백그라운드에서 각 에이전트는일련의 지침과 두 개의 작업 세트를 가지고 있습니다.요즘에는 MCP 서버를 사용하는 것이 더 좋습니다. MCP 서버는 이제 여러 서비스를 AI와 통합하는 범용 플러그인이기 때문입니다.

그래서 저는 여러 대의 MCP 서버와 지라,서비스나우 지식 기반과 같은 내부 지식 소스를 가지고 있습니다.따라서 에이전트별로 일련의 지침이 제공됩니다.그리고 이러한 지침들은 에이전트의 범위와 각 에이전트의 역할을 정의합니다.

그 후에는 MCPS 서버 세트와 PDF 파일과 같은 지식 소스가 있을 수 있습니다.따라서 여러 종류의 데이터 소스가 있을 수 있습니다.그리고 사용자가 예를 들어 메인 에이전트에 요청을 하면메인 에이전트는 해당 작업을 각 에이전트에 위임해야 한다고 정의합니다.

이제 코파일럿 스튜디오가 전체 아키텍처에서 어떤 역할을 하는지 좀 더 자세히 살펴보겠습니다.솔직히 말해서 코파일럿 스튜디오는 마이크로소프트 위 로컬 도구입니다.따라서 아키텍처 측면에서 코파일럿 스튜디오는 기본적으로 개발자가 아닌 사람들을 위한 메이커 도구입니다.그리고 아키텍처 측면에서 말씀드리자면예를 들어 제가 앞서 언급했던 IT 지원 사례를 다시 살펴보면코파일럿 스튜디오가 적합할 것입니다.왜냐하면 아키텍처 측면에서 코파일럿 스튜디오는 필요한 기능을 제공하기 때문입니다.코파일럿 스튜디오를 사용하면 MCP 서버를 정의하고필요에 따라 외부 또는 내부 지식 소스를 쉽게 통합할 수 있습니다.

하지만 앞서 말씀드린 것처럼예를 들어 오케스트레이터를 조금 더 사용자 정의하고 싶은 사용 사례가 있다고 가정해보겠습니다.코파일럿 스튜디오의 기본 설정으로는 오케스트레이터를 사용자 정의할 수 없습니다. AI 오케스트레이터를 활성화하는 것만으로 충분하기 때문입니다.예를 들어 원하는 작업의 우선순위를 사용자 정의할 수는 없습니다.코파일럿 스튜디오가 내부적으로 실행 계획을 정의하고사용자는 그 계획을 실행하게 됩니다.하지만 좀 더 세밀한 맞춤 설정이 필요하다면예를 들어 시멘틱 커널이나 롱체인 같은 프레임워크를 사용하는 것이 좋습니다.최근 마이크로소프트에서 출시하니 프레임워크를 사용하면오케스트레이션을 쉽게 맞춤 설정하고워크플로우를 정의하고 원하는 대로 설정할 수 있습니다.

코파일럿 스튜디오는 개발자와 제작자를 위해 설계된 아키텍처로에이전트를 구성하는 것이 매우 간단합니다.다만 코파일럿 스튜디오의 유일한 단점은 라이선스 문제입니다.아키텍처를 설계할 때 라이선스 문제를 반드시 고려해야 합니다.

라이선스는 이제 모든 솔루션에서 중요한 부분을 차지하기 때문입니다.

요즘 코파일럿 스튜디오는 사용량 기반 요금제로 조금 바뀌었기 때문에비용 예측에 주의해야 합니다.

달성하고자 하는 목표에 따라 맞춤 개발이 더 나은 경우도 있기 때문입니다.맞춤 개발을 하면 원하는 위치에 호스팅하고 모든 비용을 직접 관리할 수 있어지금보다 비용을 더 쉽게 예측할 수 있습니다.

코파일럿 크레딧 방식으로는 한 달, 두 달 등의 비용을 정확히 예측하기 어려운 경우가 있습니다.

그리고 코파일럿 스튜디오의 제한사항은 무엇일까요?스튜디오, 음, 제가 선택해야 한다면, 음, 네,마이크로소프트 파운드리, 에이저, 파운드리, 정확한 이름이 뭔지 잘 모르겠네요.

그리고 좋아요.완전히 사용자 정의 개발을 해야 한다면 이라고 말해야 할 때가장 먼저 답해야 할 질문은오케스트레이션을 사용자 정의해야 할까요?

입니다.이게 제게는 첫 번째 질문입니다.왜냐하면 이 질문을 통해 오케스트레이션을 사용자 정의하고 싶지 않거나오케스트레이션이 어떻게 구성되는지, 계획이 어떻게 생성되는지 깊이 파고들고 싶지 않다면코파일럿 비디오 빌더 같은 로우 코드 방식을 사용할 수 있습니다.라는 것을 알 수 있기 때문입니다.또한, 간단한 사용 사례의 경우 이러한 도구를 사용할 수 있습니다.하지만, 오케스트레이션을 사용자 지정하려면 특정 개발 환경이 필요하며이 경우, 모델 개발을 위해 파운드리를 사용하거나 자체 플랫폼을 사용해야 합니다.사용자 지정 개발의 장점은마이크로소프트 파운드리에 호스팅되지 않은 모델도 통합할 수 있다는 것입니다.

원한다면 파운드리 모델뿐만 아니라 AWS, 구글, 제미나이와 같은 플랫폼이나외부에 배포한 모델도 사용자 지정 방식을 통해 에이전트에 직접 통합할 수 있습니다.

이는 또 다른 장점입니다.오케스트레이션, 플랜 생성 방식 등 모든 것을 사용자 지정한 후에는파운드리 에이전트에서 모든 작업을 처리하게 됩니다.현재 파운드리 위 문제는 초기에는 단순히 모델 호스팅 플랫폼이었다는 점입니다.몇 년 전만 해도 파운드리는 간단한 모델 카탈로그를 제공하고 배포하는 방식이었습니다.오늘날 마이크로소프트는 이 제품을 발전시켜코파일러 스튜디오와 같은 사용자 인터페이스를 통해 코드를 전혀 작성하지 않고도에이전트를 생성할 수 있도록 했습니다.

거버넌스 관리, 다양한 기능 관리가 가능하며로컬 코드 등을 위한 코파일러 스튜디오와 같은 진정한 에이전트 플랫폼으로 진화했습니다.하지만 현재 파운드리는 빠르게 발전하고 있기 때문에 생태계 내에서 위치를 정확히 파악하기가 어렵습니다.

마이크로소프트는 MCP 통합 등 코파일러 스튜디오와 유사한 기능을 몇 가지 도입했습니다.

그러나 코파일러 스튜디오의 주요 한계는 모델 기능에 있습니다.코드를 통합하거나 시각화하는 기능만 제공됩니다.하지만 예를 들어 특정 버전의 모델을 가지고 있어서 직접 통합하고 싶다면기본적으로는 불가능하고 자체 개발 도구를 사용해야 합니다.예를 들어 LN 플랫폼을 사용하는 경우처럼요.제 고객 중에는 AWS 플랫폼을 사용하는 분이 있는데이 경우에는 외부에서 관리하는 가격 책정 방식으로 모델을 통합할 수 있습니다.네, 맞습니다.그리고 에이전트를 개발할 때도마찬가지로많은 사람들이 모델 컨텍스트 프로토콜 MCP에 대해 이야기합니다.

왜 MCP가 에이전트 개발에서 가장 중요한 주제 중 하나가 되었을까요?

아직 MCP를 사용해 본 적이 없는 분들을 위해 설명드리자면MCP는 무엇일까요?좀 어려운 단어죠.간단히 말해서 많은 사람들이 MCP에 대해 이야기하는 이유는MCP가 중요한 문제를 해결하기 때문입니다.

MCP는 도구, 기술, 그리고 어쩌면 외부 툴까지AI에 통합하는 방법을 통합하는 기술입니다.

과거에는 MCP가 없었기 때문에여러 서비스들이 서로 다른 방식으로 통신하고각기 다른 기술 프로토콜과 아키텍처 접근 방식을 사용하면서 혼란스러웠습니다.

MCP는 이러한 서비스들을AI 에이전트 또는 AI 솔루션에 통합하는 역할을 합니다.좀 더 일반적인 표현으로 말하자면MCP는 외부 툴이든 내부 툴이든둘 다 통합하는 핵심적인 방법입니다. MCP는 기술적인 측면에서 통합을 제공하기 때문에AI 아키텍처에서 매우 중요한 부분을 차지합니다.과거에는 API 통합이 중요했지만지금은 MCP가 그 역할을 하고 있습니다.물론 이것은 진화라기보다는과거에는 API를 통해 에이전트를 통합했던 방식입니다.인증 방법이나 관리 방법 또는 도구를 호출하는 방법을 관리해야 합니다.하지만 AI는 이제 이 도구를 사용할 수 있으니목표 달성에 필요한 것을 선택할 수 있습니다.라고 말할 수 있습니다. MCP에서 API 연결로 바뀌면서실제로 무엇이 달라져들까요?

기본적으로 과거에는 통합 측면에서API는 지능적이지 않았습니다.

API는 단순히 도구를 호출하고데이터를 제공하는 방식이었죠.

MCP와의 차이점은 MCP가 아키텍처 측면에서훨씬 더 지능적이라는 것입니다.

MCP는 단순히 데이터나 정보를 제공하는 도구뿐만 아니라지시 능력과 다양한 기능을 갖추고 있어진정으로 지능적인 플랫폼이 됩니다.

기본적으로 MCP는 AI에게좋아요, 그걸 달성하고 싶으세요.

요청에 딱 맞는 도구를 제공해 드릴 수 있습니다.라고 말할 수 있습니다. AI는 하나의 도구만 호출할 수 있는 것이 아니라원하는 결과를 얻기 위해 이러한 도구들을 호출해야 합니다.이것이 MCP의 역할입니다. MCP는 AI에게 이러한 도구들이 있습니다.이제 이 도구, 저 도구, 또는 여러 도구를 호출하여목표를 달성할 수 있습니다.라고 알려줍니다. MCP는 AI에게 모든 것의 실제 맥락을 제공합니다. API는 단순히 도구와 설명만 제공하는 것이고그게 전부입니다.그렇다면 MCP는메타데이터와 유사한 모델 컨텍스트 프로토콜이라고 할 수 있을까요?

아니요. MCP는 내부적으로 작동하는 프로토콜입니다. B, 기본적으로 MCP는 기술 프로토콜입니다.그리고 그 이면에는 메타데이터, 설명, 그리고 AI 스킬이 있습니다. AI에 초점을 맞추니 프로토콜은 기본적으로 스킬과 명령어를 제공하며AI는 이 도구들은 이런 기능을 하고저 도구는 저런 기능을 한다.이 스킬들을 호출할 수 있고MCP 서버에의 정보를 요청해서 원하는 결과를 얻을 수 있다.라고 이해할 수 있습니다.하지만 메타데이터도 필요합니다.도구의 이름과 내부 작동 방식 등을 정의해야 하기 때문입니다.

MCP가 미래라고 할 수 있을까요?

기업들이 수백 개의 레스트 API를 보유하고 있다면이러한 API들을 기반으로 MCP 서버를 구축해야 할까요?네, MCP 서버는 API와 함께 작동합니다.물론 기존 API를 대체하는 것은 아닙니다.음, 요약하자면 MCP 서버는 괜찮은 편입니다.컨텍스트를 제공하고MCP는 백그라운드에서 API를 호출할 수 있습니다.백그라운드에서 작동하는 것이지MCP 서버는 프런트엔드입니다.즉, 사용자가 호출해야 하는 프런트엔드 도구입니다.백그라운드에서는 사용자의 요청에 따라API가 전달되기 때문입니다.내부적으로는 API, 데이터베이스, 여러 도구 등이 사용될 수 있지만자체 MCP 서버를 구축하려면 이러한 요소들을 모두 처리해야 합니다.

예를 들어, 회사 내부에 다양한 API와 서비스, 예, 재무서비스, 인사서비스가 있다고 가정해보겠습니다.자체 MCP를 구축하려면 이러한 API들을 모두 관리해야 하며MCP 서버는 이러한 API들을 노출해야 합니다.즉, 어떤 서비스, 어떤 도구, 어떤 스킬 등이 제공되는지 명확히 해야 합니다.또한, API마다 인증 방식이 다르기 때문에 내부적으로 인증 처리도 필요합니다.키 입력 방식 등 다양한 인증 방식이 존재하므로MCP는 이러한 요소들을 모두 처리해야 합니다. MCP는 사용 가능한 도구들을 제공하고이러한 도구들은 내부적으로 여러 API를 호출할 수 있습니다.하나의 API는 여러 가지 방식으로 작동할 수 있으며내부 아키텍처 또한 다양할 수 있습니다.그리고, MCP는 100에서 500개의 AI 에이전트가 있을 때 어떤 도구를 선택하나요?

우선 몇 가지 사항을 고려합니다.에이전트의 요청이 들어오면 사용 가능한 모든 도구를 검색합니다. MCP 서버는 사용 가능한 도구가 모두 있습니다.라고 확인합니다.그러면, 에이전트의 오케스트레이터는 이 도구를 사용할 수 있습니다. LLM도 있습니다.라고 인식합니다.그 후 실행 계획을 생성합니다.간단히 요약하면,수행할 작업을 포함하는 계획을 생성하고이 작업 내에서하나, 둘, 셋 또는 그 이상의 도구를 호출하여사용자가 요청한 작업을 완료할 수 있습니다.즉, 에이전트의 오케스트레이터는 MCP 도구를 이해하고요청에 가장 적합한 도구를 선택합니다.보시다시피이것이 바로 LLM의 도움을 받아 도구를 선택하는 등의 작업을 수행하는오케스트레이터의 역할입니다. LLM은일종의 두뇌 역할을 하며,오케스트레이터는 LLM 및 도구와 소통하여 작업을 달성하기 위한 최적의 선택과 계획을 세웁니다.네, 저는 많은 회사들이 한동안 파워셀로 시작해서지금은 마이크로소프트 그래프 API를 사용하고 있다고 생각합니다.그래프 API와 MCP는어떻게 작동하나요?

사실 그래프 API 자체에는 MCP가 없습니다.마이크로소프트 클라우드 플랫폼CFT 환경에서는 마이크로소프트 그래프 API를 기반으로 하는 여러 MCP 서버를 제공하고 있습니다.

예를 들어, 팀의 LCP 서버를 사용하고 싶다면백그라운드에서 MCP 서버를 사용할 때 그래프 API가 호출됩니다.따라서 마이크로소프트 365 환경에서 그래프 AI는 매우 중요합니다.백그라운드에서 MCP가 그래프와 통신하여 요청을 처리하고원활하게 작동하도록 하기 때문입니다.네, 맞습니다.요즘 그래프는 코파일럿에서도 핵심적인 역할을 합니다.코파일럿 위 의미 론적 인덱스는 원시 데이터를 기반으로 하지만실제로는 MCP를 통해 그래프를 사용합니다.현재, 마이크로소프트 365에는 조직의 컨텍스트, 문서, 회의, 이메일, 담당자, 팀, 대화 내용, 콘텐츠 공유 등 엄청난 가치가 담겨 있습니다.이러한 컨텍스트를 보안 문제를 일으키지 않고 어떻게 노출할 수 있을까요?

거버넌스 측면에서 말씀하시는 건가요?

네, 많은 사람들이 제대로 된 거버넌스 체계를 구축하지 않고 에이전트를 개발하기 때문에항상 문제가 됩니다.

에이전트를 만들고 배포하면 이 에이전트는 많은 데이터를 처리하게 되는데어떻게 관리해야 할까요?

첫 번째 질문은 에이전트 거버넌스를 어떻게 구축하느냐입니다.이전에는 말씀하신 것처럼 혼란스러웠습니다.많은 사람들이 에이전트를 만들고 싶어 하거나 AI 솔루션을 만들고 싶어 하지만그 이면에는 예를 들어 마이크로소프트 365 환경에서 라면가장 먼저 해야 할 일 중 하나가 데이터를 이해하는 것입니다.데이터를 이해하지 못하면 길을 잃게 됩니다.데이터를 이해하는 것은 매우 중요합니다.예를 들어 기밀 데이터를 다루고 있는지아니면 매우 기밀성이 높은 데이터를 다루고 있는지 등을 파악해야 합니다.음, 먼저 데이터를 이해해야 합니다.

마이크로소프트 CR을 사용하는 경우예를 들어 DLP 기능, 민감도 분석 등을 설정해야 합니다.

이러한 기능이 없으면 문제가 발생할 수 있습니다.또한 데이터를 어느 정도 정리해야 합니다. AI는 데이터가 불량하면 에이전트가 제대로 작동하지 않기 때문입니다.

예를 들어 SharePoint, Team Channel 등의 마스크가 있는 경우에이전트 방식이 제대로 작동하지 않을 수 있습니다.따라서 데이터를 이해하는 것이 매우 중요합니다.몇 가지 기본적인 보안, 예를 들어 인증 등을 마련해야 합니다.

제가 말씀드렸듯이 퍼뷰는 이러한 모든 보안 및 거버넌스 기능을 구현하는 데핵심적인 솔루션이 되었습니다.

데이터를 정리하고기본적인 보안 조치를 취한 후에는 라이선스에 대해서도 이해해야 합니다.에이전트를 구축하기 전에 개발자들이 무엇을 할 수 있는지,관련 교육을 받았는지,라이선스가 적절한지,구독 방식이 필요한지 등을 파악해야 합니다.

또한 가장 큰 문제 중 하나는 툴링입니다.모든 툴을 개발 환경과 에이전트에 어떻게 제대로 통합해야 할까요?어떤 부분을 제한해야 할까요?

솔직히 말해서 고려해야 할 사항이 많아 큰 문제입니다.하지만 제 생각에 가장 중요한 것은 데이터를 이해하는 것입니다.

기업이 데이터를 이해하지 못하면 처음부터 문제가 발생할 수 있습니다.네, 그리고 보안 주제에 대해서는 두 가지 유형의 사람들이 있다고 생각합니다.

한쪽에서는 사용자 권한이 필요하다고 하고,다른 쪽에서는 애플리케이션 권한이 필요하다고 합니다.에이전트 생성은 어떻게 이루어져야 할까요?에이전트는 일반적으로 어떻게 작동해야 할까요?

제 최고의 권장사항은 에이전트 기반 솔루션을 다룰 때는항상 사용자 권한 위임 방식을 사용하는 것입니다.

보안 측면에서 솔직히 말해서 더 낫기 때문입니다.사용자는 자신이 접근 권한이 있는 데이터와 도구만 사용하게 됩니다.이것이 가장 중요한 원칙입니다.

특정 API나 특정 컨텍스트에 대해애플리케이션 권한이 필요한 경우 애는 사용할 수 있습니다.하지만 애플리케이션 권한을 직접 사용하지 마세요.래퍼 컨텍스트 내에서 구현하세요.예를 들어 MCP 서버를 만들고,이 MCP를 백그라운드에서 애플리케이션 권한과 통합하세요.

그러면 MCP가 백그라운드에서 애플리케이션 권한을 사용하여API를 호출하고 필요한 정보를 제공합니다.사용자는 애플리케이션 권한을 직접 사용하지 않아도 됩니다.예를 들어, 사용자 권한으로 MCP 서버를 호출하면MCP 서버는 전용 애플리케이션 권한을 가진 애플리케이션이나 서비스를 백그라운드에서 호출합니다.차이점을 이해하시겠습니까?네, 알겠습니다.흥미롭네요.아키텍처에 대해 생각할 때 좀 더 깊이 살펴봐야 한다고 생각합니다.

아키텍처에는 크게 세 가지 주제가 있습니다.검색, 인자 생성, 지식, 그리고 백도어 엔터프라이즈 검색입니다.먼저, RAG부터 시작해 보겠습니다. RAG는 아키텍처에서 어떤 역할을 할까요?아, RAG 말입니다.솔직히 말해서 RAG는 성능 측면에서 가장 뛰어납니다.

AI는 다양한 종류의 데이터를 이해해야 하는데RAG는 기본적으로 질문에 답하기 위해 존재합니다.과거에는 RAG가 없었기 때문에 다른 접근방식을 사용해야 했습니다.구식은 아니었지만 복잡했습니다.하지만 RAG가 핵심적인 이유는RAG가 다양한 종류의 데이터를 이해하고필요한 정보를 검색할 수 있기 때문입니다.데이터는 여러 유형일 수 있습니다.따라서 RAG는 오늘날 AI 아키텍처에서 매우 중요합니다.네, 하지만 많은 사용자들이 RAG에 대해 이야기할 때그 이면에 숨겨진 원리를 잘 모르는 건 사실입니다.마이크로소프트 나달은 많은소프트웨어 회사들이 요즘 RAG에 대해 자세히 설명하지 않기 때문이죠.예를 들어 코파일러 스튜디오 같은 곳에서도사용자들은 그 이면에 RAG가 있다는 사실을 이해하지 못합니다.요즘에는 좀 더 깊이 파고들면 이런 개념을 알 수 있지만많은 사용자들은 RAG가 무엇인지 전혀 모릅니다.

그저 도구를 사용할 뿐이죠.그리고다음 주제는 지식입니다.

AI 시스템은 어떻게 지식을 얻는 걸까요? J보드에서 수집하는 걸까요?아니면 다른 방식으로 작동하는 걸까요?

솔직히 말해서 지식은 여러다양한 시스템에 저장될 수 있습니다.

텍스트 파일일 수도 있고마크다운 파일일 수도 있고지식 기반 파일일 수도 있고무엇이든 될 수 있습니다.하지만 사실 MCP 서버가 있다면이러한 지식에 접근할 수 있습니다.또는 예를 들어 저는 잘 모르겠지만SharePoint 커넥터가 있거나요즘에는 많은 서비스와 연결되는 커넥터가 있기 때문에지식에 접근하는 것이 예전보다 훨씬 쉬워졌습니다.솔직히 말해서과거에는 플러그인을 만들고모든 것을 일일이 확인해야 했습니다.하지만 지금은 어떤 시스템에든직접 연결할 수 있는 커넥터가 있어서대규모 개발 인력 없이도 지식을 통합할 수 있습니다.저는 종종 우리가 지식을 모아두는 경우가 있는데예를 들어 AI는 어떤 문서가 준비되지 않았거나오래되었거나 중복되었는지 어떻게 구분할까요?

AI 시스템은 어떻게 이러한 것들을 이해하고무엇을 사용해야 할까요?음, 기본적으로 RAG를 사용하는 이유는백그라운드에서 데이터가 무엇인지 이해해야 하기 때문입니다.솔직히 말씀드리면 간단히 요약하자면프롬프트에서 시작합니다.사용자는예를 들어 지식기반이나 온 드라이브에서 검색하고 싶어합니다.

백그라운드에서 오케스트레이터는 LME 도움을 받아프롬프트와 사용자 의도를 파악합니다.백그라운드에서는 인덱스가 작동합니다.예를 들어 콤류대는 시멘틱 인덱스가 있는데이 시멘틱 인덱스는 모든 정보를 담고 있으며시멘틱 인덱스 커리를 통해 AI가 직접 인덱스를 조회하여RAG를 수행하고필요에 따라 적절한 문서를 선택할 수 있도록 합니다.하지만 코파일럿에는 시멘틱 인덱스가 있고AI는 백그라운드에서 자연어로의 인덱스를 직접 커리할 수 있습니다.예를 들어 회사 VPN, PN을 어떻게 설정해야 하는지 모르겠습니다.라고 질문하면 백그라운드에서 시멘틱 인덱스의 RAG,리서치 어세스먼트 그룹을 적용하여회사 VPN 설정에 필요한 모든 정보를 담은 문서를 검색합니다.마이크로소프트 365 코파일럿 채팅의 경우백그라운드에서 그래프 API를 사용합니다.앞서 말씀드린 것처럼 시멘틱 인덱스가 그래프 API를 기반으로구축되어 있기 때문입니다.백그라운드에서 그래프 API 기능이 작동하는 것이죠.하지만 사용자 지정 개발의 경우예를 들어 파운드리 AQ를 사용합니다.이전에는 다른 이름의 에이저 서비스였지만이제는 원하는 경우 자체 렉 시스템을 구축할 수 있습니다.사용자 지정 에이전트를 사용하면파운드리 AQ 인스턴스에 직접 질문할 수 있습니다.

어, 저는 VPN 회사 설정을 사용하고 싶고AI가 필요한 문서를 검색할 수 있습니다. PDF, Word, Excel 등 어떤 파일이든 가능합니다.

검색 기능은 이런 식으로 작동하는 거죠.

아니면백그라운드에서 작동하는 건가요?네, 백그라운드에서 작동하는군요.네, 검색 기능이 있습니다.하지만요즘에는코파일럿 채 뒤 백그라운드에서세 가지 기능을 제공합니다.첫 번째는 표준 검색으로간단히 키워드를 입력하여 문서 전체를 검색하는 기능입니다.구글처럼 키워드 검색을 하는 것과 같은 간단한 검색이죠.그 외에두 가지 다른 기능이 있습니다.첫 번째는백그라운드에서 작동하는 기능입니다.그래프에는 RAG 기능이 있고코파일럿 시멘틱 인덱스 검색 기능도 있습니다.

RAG는 코파일럿 시멘틱 인덱스 검색보다 훨씬 고급 기능입니다.

하지만 이 세 가지 기능은모두 백그라운드에서 작동하여사용자가 직접 조작하는 것이 아니라AI가 자동으로 호출하여온드라이브, 팀즈, M365 등다양한 플랫폼의 데이터를 검색할 수 있도록 합니다.

코파일럿 시멘틱 인덱스에는코파일럿 커넥터도 포함됩니다.예를 들어, 세일즈 포스를코파일럿 커넥터로 연결하면세일즈 포스, 서비스 나우 등여러 도구의 모든 데이터를 검색할 수 있습니다.

코파일럿 커넥터를 통해모든 데이터를 그래프, 인덱스,시멘틱 인덱스에 통합하면외부 시스템을 직접 커리할 수 있기 때문입니다.

네, 알겠습니다.

그리고 음, 에이전트를 구축할 때거버넌스 부분을 고려해야 하는데그 중 하나가 바로에이전트 수명주기 관리입니다.실제로어떻게 구현될까요?

솔직히 말해서마이크로소프트 생태계에서는상당히 간단합니다.예를 들어 로우코드 애플리케이션인코파일럿 스튜디오를 사용할 때파워 플랫폼 컨셉 IM을 사용하고 있으며아무것도 변하지 않았습니다.

솔루션, ALM, 파이프라인이이미 구축되어 있습니다.따라서 코파일럿 스튜디오를 사용할 때도이전과 크게 다르지 않습니다.파워 플랫폼 거버넌스, 수명주기, ALM 측면에서 투자했던 모든 것이 그대로 적용되기 때문입니다.

이는 좋은 점인데많은 사람들이코파일럿 스튜디오는 어떻게 관리하나요?바른가요?라고 묻기 때문입니다.아닙니다.앱별 또는 코어 오토메이트 애플리케이션 수명주기 관리처럼 매우 간단합니다.이 경우에는 에이전트 수명주기 관리라고 하지만내부적으로는 코어 플랫폼과 동일한 개념입니다.예를 들어 사용자 정의 개발을 할 때는넷 애플리케이션 등을 구축하는 것과 비슷합니다.코드, 관리, 프레임워크 관리, 보안관리 등 모든 것을 직접 관리하기 때문입니다.

솔직히 말해서 애플리케이션 및 에이전트 수명주기 관리 측면에서는이전과 개념이 거의 같습니다.

이는 제게 좋은 점인데수명주기 프로세스 등에 많은 투자를 할 필요가 없기 때문입니다.물론 몇 가지 변경사항이 있지만가장 큰 변화 중 하나는이제 LLM, 배포 등을 관리해야 한다는 것입니다.하지만 내부적으로는 과거 데봅스 접근 방식즉 파이프라인과 같은 방식과 유사합니다.제 생각에는에이전트 관리 방식이 이전과 크게 달라지지 않았습니다.맞춤 개발이든 기존 방식이든솔직히 말해서 지금도 이전과 같은 접근 방식을 사용합니다.그리고만약 어떤 회사가 이전에는 AI를 사용하지 않았지만디펜더 및 모든 도구에 대한 완벽한 환경 설정을 갖추고 있다면다음에 해야 할 일이 있을까요?

아니면 AI 준비 상태를 의미하는 걸까요?아, 이건 정말 중요한 질문입니다.마이크로소프트의 AI 준비 상태는 괜찮습니다.

수수료를 높이고 이런 것들을 관리하는 것이죠.하지만 제게 있어 준비 상태는 단순히 기술적인 접근 방식만을 의미하는 것이 아닙니다.기술적 인 측면에서는 우리가 무엇을 해야 하는지 알고 있습니다.여러 서비스에 걸쳐 권한을 관리해야 하죠.제게 있어 AI 준비 상태는 데이터, 즉 데이터 관리까지 포함해야 합니다.이해하시겠습니까?왜냐하면 앞서 말씀드렸듯이 데이터를 이해하지 못하면기술적 인 부분을 관리할 수 없기 때문입니다.예를 들어 무엇이 기밀이고 무엇이 아닌지 모르면 보안 조치를 마련하기 어렵습니다.하지만 마이크로소프트의 사례를 보면 AI 준비 상태는 괜찮습니다.권한 관리, 민감도 레이블 지정, GLP, 일반 데이터 보호 규정, 준수 등을 할 수 있습니다.하지만 더 높은 차원의 측면도 고려해야 합니다.

제 생각에 AI 준비 상태는 기술적 인 측면뿐만 아니라 기능적, 고차원적인 측면도 포함합니다.솔직히 말해서 요즘은 그런 측면도 중요하게 생각해야 합니다.네, 정말 흥미로운 이야기네요.

많은 기업들이 AI를 도입했지만이제는 에이전트 때문에 내 이메일이 전부 삭제됐어, 라거나악의적인 행동을 했다는 불만을 토로하는 경우가 많습니다.음, 기업들이 AI를 두려워한다고 말할 거라고 어떻게 생각하세요?

좋은 질문입니다.저는 스위스에 살고 있는데스위스에는 많은 개인은행들이 있고솔직히 말해서 굉장히 민감한 고객들이 많습니다.그래서가장 중요한 건 데이터가 어디서 처리되는가? 라는 질문입니다.그리고AI 간의 이메일을 검색하는 건가?같은 질문도 있죠.그래서 그들은 항상 이런 질문을 합니다.

하지만 그들에게 가장 중요한 건데이터가 어디서 처리되는지 알아야 한다는 것이고또 내가 AI 위 소유자인데라는 생각도 한다는 겁니다.

그래서 저는 AI에게 지시를 내리고AI가 뒤에서 작업을 수행합니다.그런데 사람들은 자율적인 측면을 두려워합니다.왜냐하면 요즘에는 그런 작업이 가능하고AI는 뒤에서 무언가를 검색하고질의하고 처리하기 때문입니다.사람들은 제가 AI에게 무언가를 하도록 지시했을 때뒤에서 어떤 일이 일어나는지 궁금해합니다.

네, 이런 질문이 많습니다. AI 에이전트나 AI 서비스의 전체 프로세스를어떻게 제어할 수 있을까요?

네, 이런 질문들이 있지만이는 결국 도입과 교육의 문제입니다.

AI를 이해하고뒤에서 정확히 어떤 일이 수행되는지이해하는 교육을 마련해야 합니다.그리고 투명성도 중요한 포인트입니다.모든 AI 솔루션에는투명성이 필수적이기 때문입니다.

투명성은 저에게 매우 중요한 주제입니다.모든 것을 투명하게 만들어야 합니다. AI 솔루션은 투명해야 합니다.백그라운드에서 어떤 작업이 수행되는지어떤 데이터가 커리되는지모든 것을 추적하고 기록해야 합니다.따라서 오늘날의 솔루션에서는모든 것이 투명해야 합니다.백그라운드에서 어떤 작업이 수행되는지어떤 데이터가 처리되는지그리고 그 배경에 어떤 논리가 있는지정확히 이해해야 하기 때문입니다.좋습니다.어떤 사실들을 바탕으로이러한 계획을 세우셨나요?멋지네요.아, 시간이 조금 부족하네요.죄송합니다.정말 멋진 시간이었습니다.저는 모든 팟캐스트에서 속사포 질문 코너를 진행하고 있습니다.제가짧은 문장을 말씀드리면여러분은 짧게 답변해 주시면 됩니다.준비되셨나요?네.코파일럿 스튜디오를 사용하셨나요?아니면 사용자 정의 코드를 사용하셨나요?코파일럿 스튜디오마이크로소프트 파운드리 아니면 코파일럿 스튜디오코파일럿 스튜디오파이프 스튜디오를 사용하셨나요?아니면 사이페 스튜디오를 사용하셨나요?기터브 아니면 네이저 데봅스기터브렉 아니면 파인 튜닝좋습니다.가장 과소평가된 마이크로소프트 365 API는 무엇일까요?

레그 레그 API 2026년에 모든 마이크로소프트 개발자가 배워야 할 기술은 무엇일까요?기터브 코파일럿세타이어 니달리아가 와서우리 AI 플랫폼을 개선하는 데 필요한 모든 자금과 리소스를 제공하고기능 하나만 개발할 수 있게 해준다면무엇을 개발하시겠습니까?라고 묻는다면무엇을 개발하시겠습니까?필요한 모든 거버넌스 관련 기능들을 개발하고다음 팟캐스트에는 누구를 초대해서어떤 질문을 할까요?

좋은 질문이네요.친구가 많지만예를 들어 클로 모로에게 질문해 볼 수 있습니다.그녀는 이전에는 기능 컨설턴트였지만지금은 기술 분야를 담당하고 있습니다.그리고 그녀는 동적 세계에서 기능적인 측면즉 기술적인 측면보다 더 중요한 부분에 대한정말 좋은 이야기를 가지고 있습니다.그러니그녀를 초대해서요즘 기능적인 업무와 기술적인 업무를어떻게 조화롭게 처리해야 할까요?라고 물어보는 건 어떨까요?그 부분에 있어서 정말 큰 어려움이 있잖아요.네, 그리고 제 마지막 질문은 이것입니다.

이 세션에서 사람들이 한 가지를 얻어갈 수 있다면무엇을 얻어가야 할까요?

기본적으로 AI는 빠르게 발전하고 있습니다.그리고 요즘 최신 정보를 얻으려면모든 것을 따라가야 합니다.왜냐하면 요즘 AI는 정말 마이크로소프트의모든 영역에 걸쳐 있기 때문입니다.그리고 요즘 여러분이 이해해야 할 것 중 하나는진화가 매우 빠르다는 것입니다.

항상 최신 정보를 파악하고 있어야 합니다.

그렇지 않으면 언젠가 중요한 것을 놓치게 될 것입니다.이러한 진화를 이해하고 배우지 않으면 안 됩니다.네, 네, 함께해 주셔서 감사합니다.이 대화에서 가장 중요한 점은마이크로소프트 C65 코파일럿 위 확장성이단순히 점점 더 정교한 프롬프트를 작성하는 것에그치지 않는다는 것입니다.

코파일럿과 에이전트가 조직 지식,마이크로소프트 그래프 비즈니스 애플리케이션 등을연결할 수 있는 아키텍처로 나아가고 있다고 생각합니다.네, 코파트 스튜디오, 마이크로소프트 파운들이사용자 지정 개발 및 MCP와 같은 기술은개발자에게 놀랍고 강력한 도구를 제공합니다.

네, 맞습니다.

에이전트의 기능이 향상될수록 기본 요소들,즉 신원 확인, 권한 관리, 보안, 거버넌스,테스트, 관찰 가능성, 애플리케이션 수명 주기 관리 등이더욱 중요해집니다.네, 이 모든 주제에 대해 정말 좋은 개요를 제공해 주셨습니다.함께해 주셔서 감사합니다.청취자 여러분께서는 MC65 FM 팟캐스트 페이지의쇼노트에서 모든 정보를 확인하실 수 있으며, EES의 활동도 살펴보실 수 있습니다.

함께해 주셔서 감사합니다.좋은 시간이었습니다.