A CTO’s POV: Speaking With Your CEO About Agentic AI

Arvind Mathur:
이번 경영진 인사이트 에피소드에 참여해주셔서 감사합니다. 저는 AWS에서 Enterprise Strategist로 일하고 있는 Arvind Mathur입니다. 오늘 저는 제 동료인 Matthias Patzak과 이야기를 나누게 되어 정말 기대됩니다. Matthias는 최근 LinkedIn에 올린 블로그 글로 많은 논의를 불러일으켰습니다. 오늘은 그 글의 내용과 그렇게 많은 논쟁이 일었던 이유를 알아보도록 하겠습니다. Matthias, 쇼에 출연하신 걸 환영합니다.  

Matthias Patzak:
예, 감사합니다. 맞아요, 제 글 때문에 좀 시끄러웠죠. 댓글이 많이 달렸어요.

Arvind Mathur:
무엇보다도, 이러한 생각을 자극하는 글들이 촉발하는 대화가 가장 가치 있다고 생각합니다.

저는 이것이 많은 참여를 이끌어냈다고 생각합니다. 우리 모두 기술 리더로서, 주목해야 한다는 것을 알면서도 충분히 관심을 기울이지 못했던 새로운 트렌드를 마주한 경험이 있기 때문입니다. CEO나 임원이 와서 질문을 던지면 우리는 항상 뒷걸음질 치고 싶은 감정을 느끼게 되죠. 그런 점에서 많은 사람들에게 공감을 불러일으켰고, 높은 참여를 이끌어낸 것 같아요. 

Matthias Patzak:
예, 사실입니다. 그리고 아마 이것이, CEO가 CTO에게 “이 에이전틱 AI라는 게 뭐야?”라고 묻는 그 LinkedIn 게시물에 대해 많은 관심과 반응이 일었던 이유일 겁니다. 그리고 아직도 많은 조직은 CTO, CIO, 엔지니어링 부문 VP가 당면한 모든 우선 과제에 업무 능력을 분산시키면서 일상적인 업무에 너무 매몰되어 있습니다. 게다가 새로운 기술을 실제로 다뤄볼 정신적 여유, 물리적 시간, 그리고 예산 모두가 부족한 상황입니다. 

Arvind Mathur:
전적으로 동의합니다. 그리고 지금은 시장 환경이 매우 빠르게 변화하고 있는 만큼, CTO와 기술 리더가 이에 더 많은 시간을 투자하는 것이 그 어느 때보다 중요하다고 생각합니다. 더 중요한 것은, 이러한 기능들 중 상당수가 이미 소비자 중심으로 보편화되었고, 비즈니스 리더들 또한 그에 대해 훨씬 더 잘 알게 된 만큼, 더 이상 이런 문제를 미뤄둘 여유가 없다는 점입니다. 그래서 이런 흐름을 파악하고, 비즈니스 리더들에게 직접 소개하는 데 일정 역량을 투자해야 합니다. 말씀하신 대로, 그런 접근이 정말 중요한 거죠?

Matthias Patzak:
예.

Arvind Mathur:
이제 실제로 이 문제에 접근하는 방법에 대한 권장 사항을 단계별로 설명해 보겠습니다. 이에 관해서도 꽤 많은 논쟁이 있었던 걸로 압니다. 제시하신 제안 중 일부가 매우 도발적이었던 점이 정말 인상적이었는데요. 그런 부분들을 함께 깊이 있게 살펴보면 좋을 것 같습니다.

Matthias Patzak:
제가 실제로 추천한 첫 번째 단계는 이 문제를 비즈니스 대화로 전환하는 것이었습니다. 어쨌든 대부분의 경우 CTO와 CIO는 새로운 기술을 이해하기를 원하기 때문입니다. 그들은 가드레일을 이해하고 싶어하고 비용을 이해하기를 원하지만, Amazon에서 말하는 소위 고객으로부터 거꾸로 일하기는 제대로 고려하지 못하고 있습니다. 즉, 그들은 현장으로 나가지 않고 고객과 사용자를 실제로 관찰하지도 않습니다. 고객의 니즈와 고객의 문제를 제대로 이해하지 못하고 있으며, IT 전문가로서 비즈니스 부문의 동료들과 비즈니스 관련 대화를 나누지 못합니다. 이것이 제가 LinkedIn 게시물에서 언급한 첫 번째 요점입니다. 논의를 비즈니스 대화로 전환하라는 거죠.

Arvind Mathur:
전적으로 동의합니다. 비즈니스 대화가 되어야 한다고 생각합니다. 비즈니스가 영향력을 발휘할 수 있도록 만들 기회이니까요. 이는 단순한 백엔드 개선이 아닙니다. 그 글이 불러일으킨 논의 중 하나는 단순히 10%의 개선이 아니라 10배의 아이디어를 찾아야 한다는 것이었습니다. 다시 말씀드리지만, 저는 이게 꽤 도발적이라는 점이 정말 마음에 듭니다. 특히 이제 에이전틱 기술 덕분에 과거의 수많은 기술보다 이러한 10배의 기회를 더 많이 찾을 수 있게 되었으니까요. 하지만 현실적으로 우리는 90%를 10% 개선 아이디어에, 나머지 5~10%만 10배 아이디어에 집중하게 되는 것 같습니다. 10배 아이디어에 집중하는 이유는 무엇인가요?

Matthias Patzak:
일반적으로 저는 조직 내에서 이루어지는 점진적이고 반복적인 개선이 진정으로 성공적인 조직을 만든다고 믿습니다. 이렇게 해야만 학습하는 조직이 되기 때문이죠. 자신의 비즈니스와 기술을 잘 이해한다면, 매주, 매일 1%, 2%, 3%, 나아가 10%까지도 개선해 나갈 수 있습니다. 하지만 생성형 AI, 일반 AI, 그리고 이제 에이전틱 AI에 이르기까지, 여러 논의에서 관찰한 바에 따르면, 많은 조직이 내부 효율성 개선에만 초점을 맞출 뿐 비즈니스 모델을 어떻게 전환할지에 대해서는 생각하지 않고 있습니다. 제 관점에서 볼 때, 앞으로 과거 10~20년 전 디지털 네이티브 기업이 등장했을 때와 모바일 퍼스트 기업이 생겨났을 때와 비슷한 상황이 나타날 것입니다. 즉, 생성형 AI 네이티브 기업과 에이전틱 AI 조직이 등장하는 것을 보게 될 것입니다. 그런 상황에서 기존 비즈니스 모델만 고수하고 있으면 뒤처질 수 있습니다.

Arvind Mathur:
예, 동의합니다. 10배 기회를 빠르게 찾을수록 더 좋습니다. 이런 상황에서 제가 유일하게 주의하라고 당부하는 점은, 말씀하신 것처럼 뒤처진 상황에 있을 때 비즈니스 리더가 찾아온다면 그들이 뭔가 아이디어를 들고 오는 경우가 많다는 것입니다. 제가 관찰한 바는 이렇습니다. 이게 바로 상황의 역학인데요. 상황을 잘 파악해야 하고, 간혹 CEO가 가져온 아이디어에 대해 빠르게 조치하고 결과를 보여줘야 할 때도 있습니다. 예를 들어, “에이전틱 담당자 님, 항상 이 문제 때문에 걱정이었는데, 이걸로 해결할 수 있을까요?” 같은 말을 듣는 경우에 말이죠. 이 경우 보통 실현할 방법을 빠르게 찾아내는 것이 매우 유용합니다. 그리고 동시에, 일단 자신감과 신뢰가 쌓이면, 이에 대해 이야기하기 시작하는 겁니다. “이건 단지 작은 개선 기회가 아닙니다. 사실 이걸로 할 수 있는 일이 훨씬 더 많아요.” 채팅 대화에서도 이 주제에 대해 좋은 토론이 있었다는 것을 알고 있는데, 전 이 아이디어가 무척 마음에 듭니다. 두 번째로 넘어가겠습니다.

Matthias Patzak:
두 번째는 전통적인 조언입니다. 저는 기술팀이 아니라 혁신 스쿼드를 구성하라는 의미로 이렇게 말했습니다. 하지만 사실 중요한 것은 기존의 IT 사일로 형태로 일해서는 안 된다는 것입니다. 반드시, 먼저 새로운 기술의 핵심 개념을 이해해야 합니다. 하지만 프로토타입을 제작하고 싶고 비즈니스 기회에 대해 제대로 알고 싶다면 영업 책임자, 운영 담당자, 재무 담당자, 법률 담당자 등도 논의에 참여해야 합니다. 단순한 관리 차원이 아니라, 실질적인 부서 간 혁신에 대한 논의로 접근해야 합니다. 단순한 기술 프로젝트가 아니라 비즈니스 혁신이기 때문입니다.

Arvind Mathur:
대화에서 이에 대한 완전한 조율과 합의가 있었다고 생각합니다. 저도 같은 생각을 강하게 갖고 있습니다. 특히 에이전틱 같은 사례에서는 더욱 그렇죠. 10배 아이디어에 집중하고 싶다면, 그건 단순히 내부 기술 개선 아이디어가 아닙니다. 이는 고객이 우리 제품과 서비스를 경험하는 방식, 제품과 서비스가 할 수 있는 기능 등 모든 것을 재구상할 수 있는 기회입니다. 따라서 광범위한 변화가 요구됩니다.

Matthias Patzak:
고객과의 대화에서 이를 어떻게 인식하고 관찰하시나요? 이런 조직이 혁신 스쿼드에서 부서 간 팀을 이루어 일하는 모습이 보이나요? 아니면 IT 사일로 형태만 보이나요?

Arvind Mathur:
뚜렷하게 보편화되어 있습니다. 즉, 이를 잘 이해하고 있는 더 성숙한 조직도 있습니다. 이들은 단순히 기술 프로젝트로만 접근해서는 성공할 수 없다는 사실을 이미 경험했죠. 하지만 여전히 많은 조직에서는 이러한 프로젝트를 단순히 기술 과제처럼 다루고 있습니다. 그리고 우리가 CTO나 비즈니스 임원들과 대화할 때 맡는 역할은, 이것을 부서 간 사일로를 타파할 기회로 바라보도록 돕는 것입니다. 그리고 저는 개인적으로 제 경험을 통해서도 이 측면과 관련해 많은 것을 배웠습니다. 보험 회사에서 근무하던 시절에는 언더라이팅, 클레임과 같은 프로세스를 혁신하려고 노력했습니다. 이러한 프로세스는 운영 조직에 속해 있지만 단순히 운영만의 문제가 아니라 영업, 제품, 리스크, 고객 경험과도 연관된 문제입니다. 따라서 변화를 추진하려면, 이 모든 부서가 함께 참여해야 합니다. 저희의 경우, 클레임 처리 시간을 3~4주에서 1시간 이하로 단축하려고 시도했습니다. 이는 극적인 변화이며, 단순히 내부 운영 프로세스의 개선에서 비롯되는 것이 아닙니다. 그래서 전적으로 동의합니다.

Arvind Mathur:
좋아요, 그럼 3단계로 넘어가겠습니다.

Matthias Patzak:
3단계에서 제가 추천한 것은 관련 사용 사례를 2~3개씩 골라 빠르게 진행하라는 것이었습니다. 무엇보다 중요한 것은 빠르게 움직이고, 이러한 파일럿 프로젝트를 순차적이 아니라 병행으로 속도감 있게 가드레일을 적용하면서 진행하는 겁니다. 이런 실험을 할 때는 가드레일이 중요합니다. 완벽한 계획을 세우는 것보다 더 효과적이죠. 제가 보는 바로는, 저희 팀 동료 중 한 명인 Jake Burns가 자주 인용하던 말이 있습니다. “준비되었을 때 시작하지 말고, 시작함으로써 준비하라”는 말이죠. 그리고 저는 특히 에이전틱 AI와 관련해서 이 접근법을 좋아하고 추천합니다. 그리고 빠르게 움직이고 파일럿을 병렬로 운영하는 데에는 또 다른 이유가 있습니다. 새로운 기술이고 새로운 사용 사례이기 때문입니다. 실험인 만큼 70%가 실패할 것이라고 예상해야 합니다.

따라서 파일럿을 순차적으로 실행하면, 첫 번째, 두 번째, 세 번째 실험은 실패할 수 있고, 결국 네 번째 반복, 네 번째 실험에서야 비로소 성공할 수 있습니다. 그렇기 때문에 CTO로서 파일럿 프로젝트를 동시에 운영할 수 있도록 역량, 정신적 능력, 예산 관점에서의 역량뿐만 아니라 사람들의 관점에서도 역량을 갖추는 것이 좋습니다. 이에 대해 많은 논의가 있었습니다. 일부 조직에서는 이러한 욕구가 없고 이러한 용량을 사용할 수 없는 것처럼 보이기 때문입니다.

Arvind Mathur:
앞서 제가 고객과 나눈 대화에 대해 질문하셨는데, 아마도 이것이 가장 어려운 부분일 것입니다. 그 이유는 대부분의 CTO가 이와 같은 위치에 있을 때 역량이 없기 때문에 여러 대규모 프로젝트를 병렬로 실행할 수 있는 자신감이 없기 때문입니다. 그들은 편안함을 느낍니다. 심지어 제가 새로운 것에 대해 확신이 들었을 때 저도 종종 각광을 받지 못하는 몇 가지 실험을 통해 배우고 더 빨리 시작할 수 있다는 자신감을 키우는 것이 더 편할 것입니다.

그리고 제가 여기서 강조해야 할 요점이 바로 이 점이라고 생각합니다. CEO와 대화를 나누기 전에 이미 해봤으면 좋겠어요. 규모가 작은 실험을 해봤다면 10배 이상의 아이디어를 찾아 병렬로 실행할 수 있다는 자신감이 생기기 때문입니다. 제가 정말 좋아했던 이 글의 핵심은 이 일을 시작한 CEO와 대화를 나누면 안 된다는 점이었다고 생각합니다. 실험을 하고 아이디어를 가지고 진행했어야 합니다. 그러면 확신을 가지고 이 일을 추진할 준비가 된 것입니다.

Matthias Patzak:
네, 실제로 운영 모델의 일부여야 하고 기업 문화의 일부여야 합니다.

Arvind Mathur:
채팅에서 제기된 질문 중 하나는 다음과 같습니다. “이봐, 새로운 것들이 너무 많고, Agentic이 있고, 로보틱스가 다른 방향으로 움직이고 있고, 코어 AI가 있고, 데이터와 데이터 및 데이터 및 분석 기능을 구동하는 새로운 방법이 있습니다. 진행 중인 모든 일을 주시하고 비즈니스 리더에게 미리 다가갈 수 있도록 충분히 실험해 보려면 어떻게 해야 할까요? 지금까지 살펴본 모범 사례에는 어떤 것이 있나요?

Matthias Patzak:
따라서 실제로는 모든 트렌드를 원하는 만큼 다뤄보고 실험하고 지식을 얻을 수는 없습니다. 이것이 바로 조직에 혁신 또는 기술 레이더 역량이 필요한 이유입니다. 사고 리더인 파스칼 피네트는 디스럽트 디스럽션 (Disrupt Disrupption) 이라는 책을 썼습니다. 그는 신호, 기술, 시장, 고객의 신호 변화를 파악하는 방법에 대해 이야기합니다. 그리고 문제는 신호가 얼마나 자주 발생하는가입니다. 특정 기술의 일부 신호가 많이 나타나면 바로 실험해 봐야 합니다. 그렇기 때문에 실험을 위해 다양한 작업 방식이 필요합니다.

따라서 일부 시그널에서는 개별 개발자, 디자이너 또는 제품 관리자가 금요일 오후에 실제 고객과 함께 프로토타입을 실험하는 경우가 있을 수 있습니다. 다른 실험의 경우 타임박스와 함께 2주 동안 팀을 위한 여유 공간이 있어야 합니다. 따라서 2주가 걸리고 이 2주 안에 무언가를 달성해야 합니다. 더 많은 돈이나 더 많은 용량, 더 많은 시간을 투자하지 않아도 됩니다. 하지만 신호를 탐지하고 신호에 따라 조치를 취할 수 있어야 합니다. 또한 이것은 아마도 가장 중요한 측면일 수 있습니다. 일부 측면에서는 일부 신호를 거부하는 것이죠. 따라서 우선 순위를 정하는 것이 핵심입니다.

Arvind Mathur:
네, 그리고 앞서 말씀하신 것이 제가 개인적으로 실천하고 사람들에게 조언한 또 다른 정말 중요한 측면이라고 생각합니다. 호기심과 실험의 문화이며 궁극적으로 혁신으로 이어집니다. 제 개인적인 실무 경험에서도 알아차린 것은 팀과 조직에 그런 문화를 만들면 그들이 실험을 하고 무슨 일이 일어나고 있는지, 어떤 일이 일어나고 있는지, 어떤 일이 일어나고 있는지 주시하게 된다는 것입니다. 특별히 전략이나 실행 계획을 세우지 않아도 말이죠. 가장 유용했던 상황은 한 팀이 제게 와서 이렇게 말했을 때였습니다. “이봐, 아빈드, 우린 이걸 탐구하고 있는데, 여기에 잠재력이 있다고 생각해.” 그래서 비즈니스 팀에 가서 이렇게 말할 기회가 생겼어요. “이봐, 우린 이걸 알아냈어. 조치를 취할 방법이 있나요?” 그런 문화가 있다면 정말 멋지죠. 그렇지 않다면 지금 바로 구축을 시작하세요. 오늘날의 세계에서 팀이 자율적으로 스캐닝하고 실험하지 않으면 기회가 왔을 때 이를 수행하기가 매우 어렵기 때문입니다.

Matthias Patzak:
네, 전적으로 동의합니다. 여기에서 핵심은 실험의 성공과 실패를 보여줄 수 있어야 한다는 것입니다. 그렇지 않으면 결국 제품 관리자나 비즈니스 동료가 불만을 제기하게 될 것입니다. 팀의 역량 중 일부가 새로운 기술을 다뤄보면서 실제로 비즈니스 가치나 기능을 제공하는 데 필요한 용량을 빼앗기 때문입니다. 이것이 바로 성공을 축하해야 하는 이유입니다. 실험의 실패 역시 실험의 성공입니다. 하지만 조직 내에서 이를 축하해 주어야 합니다. 그런 다음 용량 일부를 취하여 새로운 기술이나 비즈니스 아이디어를 실험해도 괜찮다는 문화를 만듭니다.

Arvind Mathur:
굉장하군요. 4단계로 넘어가겠습니다.

Matthias Patzak:
네, 네 번째 단계입니다. 이 단계에서 정말로 흥미롭게 느껴진 댓글들을 많이 봤습니다. 제가 조언드리는 것은 파일럿을 하는 동안 규모에 대한 비용을 지불하라는 것입니다. 그러니 그냥 작은 데모를 프로토타이핑하지 말고, 첫날부터 엔터프라이즈 볼륨을 처리할 수 있는 프로덕션용 솔루션을 구축하세요. 제 관점에서는 다양한 유형의 에이전트가 있는데요, 물론 지식 근로자를 위한 에이전트도 있습니다. 예컨대 여러분의 고객 서비스 상담원이 데스크톱에 있는 에이전트를 사용하여 워크플로 중 하나를 자동화하려는 경우를 들 수 있습니다. 하지만 전직 CTO로서 두뇌를 가진 마이크로서비스 에이전트가 훨씬 더 흥미롭다고 생각합니다. 하지만 이러한 에이전트를 아키텍처 내부, 애플리케이션에 포함시키는 것은 쉽지 않습니다.

따라서 이벤트 기반 아키텍처가 필요합니다. 적절한 관찰성을 확보할 수 있어야 하고, 적어도 프로토타입 제작 초기에는 루프에, 때로는 루프 밖에 사람이 있을 수 있어야 합니다. 그리고 이 에이전트를 프로덕션 환경에 두면 에이전트의 기능에 대해 배울 수 있습니다. 트래픽의 100%까지는 아니고 사용자의 1%, 트래픽의 1% 정도겠죠. 따라서 10배 아이디어를 시도하면서 영향 범위를 제한할 수 있습니다. 하지만 많은 사람들에게는 이를 자신의 환경에서 이해하고 받아들이기가 정말 어려웠습니다. 아마도 실패 문화를 놓치고 있기 때문이죠.

Arvind Mathur:
그리고 여기서 보시는 것은 이전 요점과도 잘 연결된다고 생각합니다. 사실 실험 내에서도 단계가 있다는 것입니다. 기업과 완전히 단절된 상태에서 수행하고 있는 실험이 있을 수 있습니다. 그 중 일부가 가능성을 보이기 시작하면 먼저 IT 내부 실험을 시작하게 됩니다. 방금 설명하셨듯이 이 점이 마음에 듭니다. 이미 서비스와 API를 통해 제공되는 비즈니스 프로세스가 있고 내부적으로 두뇌를 심어 놓았습니다. 이를 통해 프로덕션급 에이전트 기능을 구축할 수 있는 경험과 편안함을 얻을 수 있습니다. 10X 비즈니스 크로스 사일로 기회에 대해 대화를 나누게 되면 여러 아이디어에 걸쳐 프로덕션에서 병렬로 이 작업을 시작할 수 있다는 확신을 갖게 될 것입니다. 정말 좋은 지적입니다. 먼저 기술 내에서 내부적으로 이 작업을 시작하는 것은 실험에서 혁신으로 이어지는 여정의 한 단계입니다.

자, 다시 말씀드리지만 많은 사람들이 이에 대해 불편해한다는 의견을 이해합니다. 그들은 당신이 말했듯이 초기에 몇 가지 실험을 하는 것이 중요하다고 생각합니다. 영향 범위를 줄이는 것이죠. 여기서 말씀드리는 요점은 비즈니스 대화를 시작하기 전에 먼저 해야 한다는 것입니다. 작은 영향 범위, 소규모 파일럿, 프로젝트, 실험을 거치면 비즈니스 기회가 나타났을 때 빠르게 움직일 수 있습니다. 실험을 하는 것이 아니라, 그 단계에서 70%의 문제가 발생할 수 있는 상황을 극복하고 그 단계에서 더 일관된 기능을 제공할 수 있기를 바랍니다.

Matthias Patzak:
네, 전적으로 동의합니다. 이것이 바로 사람들이 일찍부터 새로운 기술을 직접 체험해 봐야 하는 이유입니다. 제가 추천하는 것은 파트너를 포함시키고 AWS 계정 팀을 포함시켜 그들에게 새로운 기술을 실제로 사용하는 방법을 보여주는 것입니다.

Arvind Mathur:
좋아요, 다섯 번째 단계로 넘어가죠.

Matthias Patzak:
네, 다섯 번째 단계입니다. 당연한 얘기지만 평가 과정이 있어야 합니다. 따라서 5단계는 기술적 지표가 아니라 비즈니스 영향을 측정하는 것입니다. 따라서 모델 정확도나 사용자 적응률이 아닌 수익 증가, 비용 절감, 주기 시간 개선, 전환율 변화를 추적하세요. 물론 적응률에 대한 이러한 선행 지표가 있어야 합니다. 몇 가지 품질 메트릭을 알아야 하지만 신기술을 도입하려는 것은 신기술을 위한 것이 아니라 비즈니스 프로세스를 10% 개선하거나 10배 사용 사례를 달성할 수 있기 때문입니다. 따라서 실제 사용자를 대상으로 모든 솔루션을 프로덕션에 적용하고 실제 비즈니스에 미치는 영향을 측정해야 합니다. 기능 목록에서 상자를 체크하고 싶지는 않을 것입니다. 진심은 이런 거겠죠. “이봐, 이 새로운 에이전틱 AI 덕분에 웹 사이트 이탈률을 몇 퍼센트에서 마이너스로 줄일 수 있었어.”

Arvind Mathur:
이 점에 대해서는 이미 대체로 합의되었다고 봅니다. 동일한 클레임 프로세스 가속화 과정에서 이에 대한 제 개인적인 경험도 간단히 공유하고 싶습니다. 처음에 이 프로젝트를 진행할 때 팀 내 여러 사람을 측정하는 실수를 저질렀습니다. 그래서 우리 운영 팀은 한 가지 운영 조치를 취했습니다. 기술 팀은 기능 제공에 대한 또 다른 운영 조치를 취했고 영업 팀은 다른 조치를 취했습니다. 그 때문에 10배 수준에 도달하지 못했습니다. 모든 사람이 같은 목표, 즉 3주에서 5분으로 단축한 후에야 비로소 모든 사람이 동일한 지점에 도달했을 뿐만 아니라 창의성을 이끌었습니다. 10X와 이에 대한 정말 창의적인 솔루션을 제공하는 것을 방해하는 장벽이 부서 간에 드러났습니다. 사실 이것은 단순한 측정이 아닙니다. 팀을 조율하고 10배 성과를 달성하는 데 방해가 되는 매우 큰 장애물에 집중할 수 있는 좋은 방법입니다.

Matthias Patzak:
네, 맞아요. 조율 부분이 정말 중요합니다.

Arvind Mathur:
정말 좋은 내용이라고 생각합니다. 앞으로도 저희가 계속해서 사람들과 교류하고 이에 대해 더 많은 의견을 얻었으면 좋겠습니다. 하지만 제가 이 대화에서 얻은 가장 큰 교훈이 있습니다. 제 경험으로 배운 것이기도 하고, 모두에게 추천하고 싶은 것인데, 지금 바로 정보를 탐색하기 시작하라는 것입니다. 많은 변화가 일어나고 있는 지금, 여러분은 무엇이 가능한지 먼저 이해하고 이러한 아이디어를 비즈니스 리더에게 전달해야 합니다. 따라서 이를 바탕으로 한 제 제안은, 지금 바로 AWS 계정으로 가서 계정 팀과 이야기를 나누고 이러한 도구를 사용하기 시작하고 지금 구축을 시작하는 방법을 알아보는 것입니다.

Matthias Patzak:
네, 전적으로 동의합니다. 그리고 사용해야 할 도구 또는 아마존 서비스는 Amazon BedRock Agent Core입니다. 에이전트와 관련된 서비스는 서로 다르지만 아키텍처에 에이전트를 포함하기 위한 코어는 Amazon Bedrock Agent Core입니다. 이것이 바로 제가 여러 조직이 가능한 한 빨리 도입할 것을 권장하는 서비스입니다.

Arvind Mathur:
멋집니다. 그럼 이제 빌드하러 갑시다.

Matthias Patzak:
그럼 이제 빌드하러 갑시다.

지금 듣기

지금 듣기

지금 듣기