DEVOCEAN

Adot에 기억(Memory)을 장착하다

최근 저희팀에서는 에이닷에 ‘메모리’를 도입했습니다. (관련 기사)

이제 에이닷은 단순히 사용자의 대화를 기억하고 이를 토대로 점점 더 개인화된 경험을 주는 방향으로 진화하고 있습니다.

이를 구현하기 위해 저희 팀은 서비스 요구사항에 맞춘 Agentic Memory를 직접 설계·개발했고, 빠른 iteration으로 품질을 높이기 위해 DSPy 기반 프롬프트 최적화까지 도입했습니다.

이번 글에서는 이 메모리를 어떻게 만들었는지, 실제 적용 사례와 개발 과정에서의 시행착오, 그리고 DSPy 도입 배경과 효과까지 풀어보려 합니다.

Agentic Memory란?

Agentic Memory는 간단히 말해 Agent처럼 작동하는 메모리입니다.

사용자의 발화를 단순 로그로 남기는 것이 아니라, 의미 단위로 구조화하고, 인간의 뇌처럼 추가·수정·삭제를 통해 기억을 관리합니다.

그리고 필요할 때 꺼내 쓰거나 갱신하며 점점 더 정교한 맥락 기반 응답을 가능하게 합니다.

주요 기능

• 기억의 추출 및 병합 (Extraction & Consolidation)

  • 대화 중 사용자의 발화에서 중요한 정보를 추출하고, 기존에 저장된 기억과 비교하여 ADD / UPDATE / DELETE 중 적절한 연산을 수행해 최신 상태를 유지합니다.

    
    

  • 예시

    User: "우와 나 데몬헌터스 너무 재밌었어, '골든' 노래 왜 이렇게 좋아?"→ '골든 노래를 좋아함' 메모리 ADD

    User: "아 이제 '골든' 좀 질렸어… 소다팝이 더 좋은 것 같아"→ "골든 노래를 좋아함" 메모리와 비교·병합 → '소다팝을 더 선호' 한다는 메모리로 UPDATE

• 컨텍스트 기반 메모리 조회 (Contextual Retrieval)

  • 현재 질문의 의도와 맥락에 가장 관련성 높은 과거 기억을 검색하여 쿼리를 보강하고, 답변의 정확도와 개인화를 높입니다.

    
    

  • 예시

    User: "그거 틀어줘, 데몬헌터스에 나왔던 내가 좋아하는 노래"→ "소다 팝을 틀어줌"

실제 유저 대화 사례

메모리가 생기면서 확 달라진 경험을 예시로 들어볼게요.

이 차이는 ‘기억’이 있냐 없냐에서 발생합니다. 같은 질문도 훨씬 더 개인 상황에 맞는 답변으로 변한 것이죠.

개발 과정에서의 고민과 시행착오

Agentic Memory를 만들면서 기획자분들과 실제 서비스를 테스트 하면서 유저 발화 중 어떤 부분이 장기적으로 저장할 가치 있는지 계속 구체화해 나갔습니다.

이 과정에서 저희는 크게 세 가지 항목에 대한 고민과 시행착오를 거쳤습니다.

무엇을 기억할까? — relevance_score로 노이즈 줄이기

모든 대화를 다 저장하면 쓸데없는 데이터가 넘쳐났습니다. 단순 추천 요청/검색발화도 전부 중요한 메모리로 저장이되어 버려서 대화에 편향이 생기더라구요.

예를 들어, 등산복에 대해서 한번 물어봤는데 주말에 뭐하지? 를 했을 때에 '등산'과 관련된 내용으로 응답에 편향이 생기기도 했습니다.

추출되는 메모리가 얼마나 중요한가/반복적으로 언급되는가/장기적으로 기억할 가치가 있는가를 수치화하여 저장하고 선별적으로 활용하기로 하였습니다.

이런 시행착오를 거친 후에, 저희 에이닷의 One Agent는 사용자가 대화 중 언급한 ‘기억할만한 정보’를 자동으로 인식하여,

User Info와 User Event 두 가지 구조로 나누어 '구조화' 하여 문서 형태로 저장하게 되었습니다.

• 어떤 상황(context)에서

• 어떤 카테고리(category)에 해당하는

• 어떤 내용(content)과 그 세부정보(detail)을

• 언제까지 기억(expire_date)해야 할지

• 그리고 그 정보는 얼마나 장기적으로 기억할 가치가 있는지(relevance_score)

얼마나 자주 기억할까? — 실시간 대신 이벤트 기반 비동기

초기에는 API 요청 시 실시간으로 메모리를 저장하는 방식을 고려했으나, 다음과 같은 문제점으로 인해 적절하지 않다고 판단했습니다.

• 실시간 저장의 불필요성: 메모리 저장은 즉시 완료될 필요가 없으며, 일정 시간 내에 처리되면 충분함.

• 높은 Latency: 메모리 저장 로직이 복잡하여 응답 시간이 길어지고, 이는 사용자 경험에 부정적 영향을 미침.

• 시스템 안정성: 동기 처리 시 메모리 저장 실패가 전체 API 응답에 영향을 줄 수 있음.

따라서 아래와 같은 아키텍쳐를 구성했습니다.

앞단의 Message Broker로 Kinesis Data Streams 를 두었고, Lambda 에서 aggreagate 후 SQS 로 전송할 수 있도록 했습니다.

SQS 로 전송된 메세지들은 Lambda 에서 consume 하여 최종적으로 memory-layer 서버에 메모리 생성 요청을 하게됩니다.

N분간의 사용자 메시지를 모아서 메모리를 생성하여야하는 요구조건이 있었기 때문에 Window 를 지원하는 Kinesis Streams 를 사용하게 되었습니다.

따라서, 채팅 메시지 응답 이후에 저장 이벤트가 따로 발생되도록 구성되어, 사용자 응답 속도에는 영향을 주지 않습니다.

저장 로직의 최적화 — 프롬프트 수작업 대신 DSPy 자동화

오픈 전, 메모리 저장/발현에 대한 여러번의 Iteratioin을 돌면서, “무엇을 저장할지”에 대한 기준이 조금씩 바뀌면서 구체화 되기 시작했습니다.

이걸 매번 사람이 프롬프트를 고치면서 따라가는 건 속도도 느리고 일관성도 깨지더라고요.

그래서 DSPy(Programming—not prompting LMs)를 도입해 프롬프트를 데이터 기반으로 자동 최적화하는 루프를 만들었습니다.

데이터 준비 → 프롬프트 최적화 → 평가 → 배포 → 모니터링 → 다시 데이터 반영

이 최적화 루프를 통해 다음과 같은 개선이 가능해졌습니다.

• 개발 효율성 증가: 사람이 직접 수정하던 프롬프트를 자동 최적화 → 반복 작업 최소화.

• 성능 극대화: Golden Dataset으로 검증된 데이터를 활용해 메모리 저장 정확도 성능 향상.

• 유지보수 용이성: 새로운 요구사항이 생길 때마다 데이터 기반으로 빠르게 DSPy 기반으로 프롬프트를 업데이트.

마치며

이번 Agentic Memory 개발은 저와 우리 팀 모두에게 큰 도전이었습니다.

단순한 챗봇이 아니라, 사용자와 장기적인 관계를 맺는 에이전트를 만들기 위한 첫걸음이었으니까요.

시행착오도 많았지만, 그만큼 얻은 성과도 컸습니다.

덕분에 저희는 앞으로도 유저 맞춤형 기억을 빠르게 개선하고, 더 나은 개인화 경험을 제공할 수 있게 되었습니다.