[1/2] Amazon Bedrock AgentCore를 이용해서 Context-Aware Meeting Assistant 만들기

개요

25년 10월 13일, Amazon Bedrock AgentCore 서비스가 GA 되었습니다.

Bedrock AgentCore는 "From PoC to Production at Scale"을 핵심 가치로 내세우고 있는데요.

1) 도대체 Bedrock AgentCore는 무엇이고 2) 어떻게 PoC부터 Production까지, 그것도 대규모로 에이전트 서비스를 운영 할 수 있다는걸까요?

 

AgentCore를 활용해 Context-Aware Meeting Assistant를 만들어보면서, Bedrock AgentCore를 이해해보겠습니다.

 

시나리오

여러분은 AnyCompany사의 개발자입니다. 그런데, 여러분 회사의 세일즈팀의 이직율이 너무 높아서, 고객 히스토리에 대한 인수 인계가 잘 안되고 있습니다. 담당 세일즈가 바뀔 때마다 세일즈는 이전에 했던 질문을 고객에게 다시 해야하고, 이는 고객의 AnyCompany에 대한 불신을 높이고 있습니다. 물론, 세일즈가 CRM에 굵직한 이벤트는 기록을 하겠지만, 기존 고객의 세세한 성향이나, 누가 Decision Maker이고 Blocker인지와 같은 고객 인사이트에 대한 정보는 기존 세일즈의 머리속에만 기록되어있거든요. 결국 새로 바뀐 세일즈는, 고객 맞춤형 전략을 세울 수 없게 되고, 고객과의 Trust를 훼손시킬 각오를 하면서 다시 정보를 수집해야하는 상황에 놓입니다.

 

결국, AnyCompany사의 Leadership이 결단을 내립니다. 바로 단순한 FAQ 챗봇을 넘어서는, 고객의 Context까지 기억할 수 있는 Intelligent Meeting Assistant를 만들어보자는 것이죠.

 

아, 그런데 막막합니다.

어디서부터 시작을 해야할까요?

 

타임라인

 

Week 1

일단 시작이 반이라고, Lambda에 Claude API를 붙여서 테스트를 해봅니다.

프로토타입이 잘 작동하는군요. 생각보다 빠르게 일이 풀릴지도 모르겠습니다.

 

Month 1

Leadership이 본격적으로 requirements에 대한 요구를 해오기 시작합니다.

1. 동시 1000명까지 세일즈가 미팅 어시스턴트를 이용할 수 있어야 한다.

2. 여러 미팅을 걸쳐서 AI 에이전트가 기억을 해야한다.

 

음... 이럴 줄 알았습니다. 골치 아픕니다.

도대체 어디서부터 손대야할지도 모르겠네요.

확실한건, 프로토타입 아키텍처로는 프로덕션 수준의 구현이 절대 불가능하다는 것입니다.

 

Month 3

일단 에이전트는 제쳐두고, 인프라부터 손대봅니다.

여러분은 Leadership의 requirements를 다음과 같이 정리했습니다.

 

1. Session Isolation & Session Management

기본적으로, 한 명의 세일즈는 수 백명의 고객을 갖고 있고, 한 명의 고객과도 여러 건의 미팅을 진행하게 됩니다.

그렇다면?

1. 세일즈끼리 데이터가 섞이면 안됩니다. 그러면 누가 어떤 고객을 담당하고 어떤 미팅을 담당하는지 체크가 안되겠죠.

2. 한 세일즈가 보유하고 있는 여러 고객간의 데이터가 서로 섞이면 안됩니다. 고객 A한테 가서 고객 B의 얘기를 한다? 재앙입니다.

3. 한 고객의 여러 미팅에 대한 데이터가 서로 섞이면 안됩니다. 기껏 미팅간 타임라인을 정리해놨더니, 이게 섞이면 안됩니다.

 

따라서, 잘은 모르겠지만... 기본적으로 뭔가 격리가 필요해보이고, 뭔가 이에 대한 관리를 할 수 있어야 할 것 같습니다. 

이를 Session Isolation & Session Management라고 정리해봅니다.

 

2. Memory Management for AI Agents

여러 미팅을 걸쳐 AI 에이전트가 기억을 할 수 있어야 합니다. 그러려면 일단, 고객과의 대화 내용을 저장해야합니다.

메모리 관리가 필요하겠군요.

 

3. Scaling Infrastructure for Concurrent Users

동시에 1000명의 고객을 감당하려면, 인프라가 트래픽 증감에 따라 자동으로 늘어나고 줄어들어야 할 것 같습니다.

오토 스케일링이 필요할 것 같습니다.

 

자, 그러면 개발자인 여러분은 기본적으로 저 3개 requirements에 대한 인프라를 직접 구축해야합니다.

그런데, 아뿔싸. 여러분의 Leadership은 벌써 결과물이 나오기를 기대하고 있습니다.

인프라 구축보다 퇴사가 빠를 것 같아서 잠깐 고민하다가, 집에 있는 토끼같은 아이들을 생각하며 참습니다.

 

에이전트 개발이나 비즈니스 로직 구현은 커녕, 인프라 구축부터 막막합니다.

하루 이틀 안에 끝날 일이 아닙니다.

방법이 없을까요?

 

여러분은 혹시나하는 마음에, 새로나온 AWS 서비스를 찾아보다가, Bedrock AgentCore라는 서비스를 발견했습니다.

과연 이 서비스가 여러분의 구세주가 될 수 있을까요?

 

이제 Bedrock AgentCore에 대해 한번 살펴보도록 하죠.

Bedrock AgentCore

AWS Official docs가 말하길,

Bedrock AgentCore는 AI 에이전트를 대규모로 안전하게 구축, 배포, 운영할 수 있도록 설계된 완전 관리형 플랫폼이라고 하네요.

 

그런데, 6개의 서비스 중에서, AgentCore의 핵심 서비스 2개가 여러분의 마음을 사로잡습니다.

 

1. AgentCore Runtime

Agent Runtime offers a secure, serverless and purpose-built way to deploy and scale AI agents and tools using any agent framework and any model. Runtime unlocks fast cold starts, industry-leading long-running execution, true session isolation, built-in identity, and support for multi-modal payloads. Simply host your existing agent or tool code in Runtime to get started.

 

2. AgentCore Memory

Memory enables agents to retain knowledge and learn continuously by leveraging built-in and/or custom strategies for automatically extracting and storing key types of memory from every interaction. This allows agents to be context-aware across sessions.

 

아직 잘은 모르겠지만, 여러 키워드가 눈에 띕니다.

1. Session Isolation & Session Management

2. Memory Management for AI Agents

3. Scaling Infrastructure for Concurrent Users

 

왠지..

1번은 AgentCore Runtime의 true session isolation 기능이

2번은 Context-aware across sessions 기능이

3번은 Serverless and scale AI agents 기능이 해결을 해줄 것 같습니다.

 

 

 

그리고 또 한달의 시간이 흘렀습니다.

 

 

 

과연 여러분은 프로덕션 수준의 AI 에이전트 서비스를 위한 인프라를 한달만에 구축할 수 있었을까요?

놀랍게도 그렇습니다.

 

여러분이 구축한 인프라를 리버스 엔지니어링 해보도록 하죠.

 

잘은 모르겠지만... MicroVM이라는게 보이는군요. Isolation에 핵심적인 요소일 것 같습니다.

 

조금 검색을 해봅니다. 아하, MicroVM이라는 것이 AWS의 오픈소스 Firecracker 기술을 기반으로 하는군요.

일반 VM보다 훨씬 빠르게 시작되고, 세션이 종료되면 메모리를 완전히 초기화해서 보안을 보장한다고 하네요.

각 세션마다 독립된 MicroVM이 할당되니, 완벽한 물리적 격리가 이루어지는 셈입니다.

그런데 잠깐, 여기서 헷갈리는 부분이 있습니다. Actor ID라는 것도 보이는데, 이건 뭘까요?

조금 더 찾아보니, Actor ID는 Runtime의 세션 격리와는 별개로, Memory 서비스에서 메모리를 조직화하는 개념이군요.

 

이 구조에서는 각 고객을 Actor ID로 할당해서, 각 고객의 여러 미팅을 논리적으로 그룹화하는 것으로 보입니다.

이렇게 하면 담당 세일즈가 바뀌어도, 새로운 세일즈는 Actor ID만 조회하면 해당 고객과의 모든 미팅 히스토리와 인사이트를 즉시 파악할 수 있겠네요.

 

영리한 구조네요.

Runtime은 각 세션(미팅)을 물리적으로 완전히 격리하고, Memory는 Actor ID(고객) 아래 여러 세션(미팅)을 계층적으로 조직화해서 컨텍스트를 일관되게 유지하는군요.

 

1. Session Isolation & Session Management

2. Memory Management for AI Agents

3. Scaling Infrastructure for Concurrent Users

 

좋아요. 1번과 3번은 해결했습니다.

 

그럼 2번은 어떻게 해결해야할까요?

Memory Management라... 이름만 들어도 상당히 골치아파보이는데 말이죠.

 

 

다이어그램 안에 Short-term Memory와 Long-term Memory라는 것이 보이네요.

뭔지는 몰라도, 저게 메모리 역할을 하는 것 같습니다.

그리고 단어의 뉘앙스로 추측해보건대, Short-term Memory는 단기간 데이터를 저장하고, Long-term Memory는 장기간 데이터를 저장하는 것 같습니다.

 

AWS Official docs를 찾아봅시다.

 

아, 이제 알겠습니다. 미팅 대화(transcript)를 Short-term Memory에 저장하게 되면, AgentCore의 LLM이 고객 인사이트를 추출하고, 기존 Long-term Memory와 비교해 중복을 제거하거나 업데이트한 후 저장하는 구조군요.

 

오, 공간 효율적입니다.

굳이 Short-term Memory에 저장된 모든 대화를 굳이 계속 보관하는게 아니라, 대화에서 추출된 고객에 대한 인사이트만 Long-term Memory에 저장을 하는거네요. 그래도 여러 미팅에 걸친 고객에 대한 Context를 일관되게 유지할 수 있으니까요. 혹시 나중에 RAG를 위해서 전체 대화가 필요하면 S3에 따로 export를 하면 되니, 요건에 따라 선택할 수 있는 옵션이 늘어난 셈입니다.

 

 

아하, 대화에서 이런식으로 고객에 대한 인사이트를 추출하는군요.

어떻게 인사이트를 추출할지 정의하는 것을 Strategy라고 하는 것 같습니다.

일단은 이름만 알고 넘어갑니다.

 

1. Session Isolation & Session Management

2. Memory Management for AI Agents

3. Scaling Infrastructure for Concurrent Users

 

이렇게 2번도 해결을 했습니다.

 

 

 

그러면 이제, 여러분이 서비스를 어떻게 구현했는지 살펴봅시다.

 

 

아키텍처를 보니 그리 특별한 것은 없네요. 다만 Long-term Memory와 RAG가 둘 다 구현되어있는 것으로 보이는데, 둘의 차이가 조금 혼란스럽습니다. 이 부분은 다음 문서에서 다뤄보도록 하겠습니다.

 

 

아, 한 세일즈가 여러 고객에 대한 컨텍스트를 관리하는 것만 구현을 했나보네요.

좋아요. 오히려 AgentCore의 각 기능이 어떻게 서비스에 녹아드는지 이해하기가 더 쉬워졌습니다.

 

지금은 고객이 없기 때문에 고객을 추가해봅니다.

 

 

 

행복하면 좋으니, 회사의 이름은 Happy Company라고 하겠습니다.

 

 

여기서 Customer Snapshot은, Long-term memory에 저장된 고객 인사이트를 디스플레이하는 대시보드로 보이고, Meeting History는 Short-term Memory에 저장된 미팅 데이터를 보여주는 곳으로 보이네요.

 

아직 미팅을 한번도 진행하지 않았기 때문에, Customer Snapshot과 Meeting History 모두 고객에 대한 데이터가 없는 것으로 나옵니다.

 

 

세 가지 섹션으로 나뉘어져 있군요.

 

왼쪽 섹션에는, 고객의 대화를 적는 곳, 그리고 오른쪽 두 섹션은 고객 특화된 질문과 답변을 하는 곳으로 보입니다.

 

 

노란색 박스를 살펴보겠습니다.

 

고객이 Hi, I'm Kate, founder of a small eco-friendly clothing brand called Happy Company 라고 말하네요.

그런데 Personalized AI Coaching Answer을 보니, 특별하게 고객 특화된 답변을 하는 것 같지 않습니다.

보라색 섹션을 봐도, 이 대답은 이전 대화 내역 없이 만들어졌다고 나오네요.

아하, 아직 Short-term Memory에 저장된 대화가 Long-term Memory로 추출이 되지 않았군요.

최대 1분의 비동기적 추출 시간이 걸린다고 하더니, 그것 때문인 것 같습니다.

 

 

미팅을 저장하고 이전 화면으로 돌아가봅니다.

 

Customer Snapshot을 먼저 보겠습니다.

고객에 대한 정보와 Deal의 상태같은 고객에 대한 인사이트가 새롭게 업데이트 되었네요. 성공입니다!

그리고 Meeting History 역시, 해당 미팅에 대한 Summary가 잘 생긴 것을 볼 수 있습니다.

 

 

이번에는 새로운 미팅을 만들고 다시 고객의 대화를 입력해보겠습니다.

 

Hi again, this is Kate from Happy Company.

Thanks for the proposal you shared last week - I'd like to understand more about AWS hosting options and how pricing works. Also, can we migrate our existing customer database without any data loss during the transtion?

 

그리고 오른쪽 노란색 박스를 보면, Assistant가 Given your eco-friendly clothing brand's specific needs 라고 하네요.

어라, 이번 미팅에서는 분명히 Kate가 자기가 clothing brand의 설립자라고 말을 한적이 없는데 말이죠!

역시 성공입니다! 고객 특화된 답변을 주고 있군요.

 

 

그리고 보라색 섹션을 보면, Long-term Memory에서 고객 인사이트를 활용해서 대답한 것을 확인할 수 있습니다.

 

 

Memory의 Namespace structure를 살펴봐도, 고객, 미팅 모두 각각의 unique한 ID를 갖고 있는 것이 확인이 되는군요.

성공적으로 isolation이 이뤄졌습니다!

 

지금까지 미팅간 데이터가 서로 섞이지 않는다는 것을 확인했으니, 이번엔 마지막으로 고객간 데이터가 서로 섞이지 않는다는 것을 확인해보겠습니다.

 

 

새로운 고객을 만들고,

 

 

고객 대시보드에 들어가보면, Customer Snapshot과 Meeting History가 모두 비어있네요.

성공입니다. 고객간 데이터 역시 섞이지 않고 분리가 되는군요!

 

여러분은 이렇게 짧은 기간에, 별도의 인프라 구축 없이 Context-Aware Meeting Assistant를 만들 수 있었던건 AgentCore 없이는 불가능했을 것 같다는 생각을 해봅니다.

 

AgentCore 덕분에 오늘은 빨리 퇴근을 할 수 있겠네요!