에이전트 이야기를 하다 보면 하네스 줄이 과하게 커지는 자리가 있다. 그런데 플랫폼이 장기 메모리를 제품으로 올리기 시작하면, 하네스에 억지로 넣었던 기억·컨텍스트 줄은 다시 집에서 깎을 대상에서 빼야 할 후보로 옮겨갈 수 있다. 이 글에서는 Microsoft Foundry Agent Service 의 Memory 개념을 기준으로 무엇이 표준화되는지요약하고, 하네스에 남겨야 할 줄까지 한 번에 그어본다.

기술 요약 — 에이전트 메모리가 말하는 것

단기와 장기

에이전트 메모리를 나누면 대략 이렇다.

  • 단기 메모리 — 지금 세션 안의 대화와 즉시 문맥. 보통 세션 컨텍스트·오케스트레이션 프레임워크 줄에서 처리한다.
  • 장기 메모리 — 세션을 넘겨 남는 지식. 사용자 선호, 이전 상담 줄이기, 과거 스레드 요약처럼 다음 번에도 이어져야 할 맥락이다.

Foundry 문서가 말하는 Memory(프리뷰)는 장기 메모리 쪽을 관리형으로 제공하는 그림에 가깝다. 저장소 안에 항목으로 쌓이고, 추출 → 정리 → 조회의 흐름을 전제로 한다(What is Memory?).

세 단계: 추출, 정리·병합, 조회

  1. 추출(Extraction) — 대화에서 선호·사실·관련 맥락 등 의미 있어 보이는 조각을 뽑아 저장 후보로 만든다.
  2. 정리·병합(Consolidation) — 비슷한 기억을 합치고 중복을 줄이며, 서로 다른 사실이 충돌할 때(예: 제약 정보가 바뀜)는 한쪽으로 맞춰 저장을 일관되게 유지하려 한다. 프리뷰라 타입·설정에 따라 동작은 바뀔 수 있다고 문서에서도 적혀 있다.
  3. 조회(Retrieval) — 새 대화에서 저장소를 검색해 지금 턴에 맞는 기억을 끌어온다. 프로필성 정보는 대화 초반에 한 번 올려 두는 편이 낫다는 식의 가이드도 있다.

메모리 타입(문서 기준)

장기로 저장되는 타입 예시는 대략 두 갈래로 정리된다.

구분 직관
사용자 프로필 성격 이름·언어·식이 제한처럼 대화 배경색에 가까운 상대적으로 안정적인 선호
채팅 요약 성격 스레드·주제별로 대화를 증류한 요약 — “전에 무엇을 말했는지”를 이어 붙이기 좋음

조직 공통 문서처럼 큐레이션된 지식은 장기 사용자 메모리와 같은 통에 두지 말라는 안내도 있다. 문서에서는 조직 지식 베이스(Foundry IQ 등)·파일 검색 같은 그라운딩 채널과 장기 메모리를 구분할 것을 권한다.

쓰는 방식

  • 메모리 검색 도구(tool)를 에이전트에 붙여 읽고 쓰는 방식이 대부분의 시나리오에서 단순하다고 한다.
  • Memory Store 저수준 API는 통제나 커스터마이즈가 많이 필요할 때.

적합한 쓰임

문서 예시처럼 반복 설명 줄이기·선호 누적·이전 이슈/티켓 맥락이 중요한 대화형 지원, 좌석·식사 선호처럼 쌓여야 하는 플래닝형, 혹은 이전 실험·가설을 들고 가야 하는 리서치형 등, 세션 밖 맥락이 손익에 직결될 때 가치가 분명하다.

리스크와 한계(요지만)

  • 프롬프트 인젝션·메모리 오염 등, 잘못된 데이터가 저장되면 이후 응답·행동에 스며들 수 있다는 점을 문서에서 직접 경고한다. 입력·출력 검증, 적대적 테스트 등 보안·품질 줄은 별도 설계가 필요하다.
  • 호환 모델·scope·지역·쿼터 등 운영 제약은 프리뷰 제품답게 문서에 나열되어 있으니, “기능 소개”만 보고 도입하지 말고 계약·한도를 같이 읽어야 한다.

그래서 하네스와는 어떻게 맞물리나

나는 예전에도 이 줄을 골라 말한다. 본체는 의도(무엇을 하려 하는가) 와 스킬(실제로 세상을 바꿀 수 있는 도구 줄) 에 가깝다. 장기 메모리는 여기서 셋째 축에 가깝다.

  • 스킬 — 무엇을 할 수 있는가.
  • 의도 분석·라우팅 — 지금 무엇을 하려 하는가.
  • 장기 메모리 — 지금이 아니라 과거부터 이어져 온 사용자·과제 맥락은 무엇인가.

장기 메모리가 잘 들어가면, 팀 하네스에 억지로 얹던 저장 스키마·수동 요약 파이프·세션 간 컨텍스트 이어붙이기 같은 줄 일부가 플랫폼 줄로 이전될 수 있다. 그 의미에서는 하네스 난리의 일부 중복이 줄어드는 방향이 맞다.

다만 메모리는 스킬을 채워 주지 않는다. 기억만 많아지고 실행 줄이 비어 있으면, 길게 말하자면 “오래 기억은 하는데 손은 없는” 자리만 커진다. 내가 줄곧 말했던 줄과 같다.

마치며 — PaaS가 가져간 줄은 재발명하지 말 것

플랫폼이 추출·저장·검색까지 장기 메모리 줄을 표준으로 올리는 흐름이면, 팀별로 하네스에 다시 깎아 넣을 후보 목록에서 빼야 할 줄이 생긴다. 이미 같은 일을 하는 Paa스 스토어 줄까지 사내 재발명으로 이중화하면, 회의 줄만 무거워진다는 결에 가까워진다.

남겨 두어야 할 줄도 분명하다. 무엇을 기억해도 되는지·얼마나 두는지 같은 거버넌스, 실제 행위를 만들 스킬·MCP 줄, 그리고 성공 의미와 제약을 정하는 의도 설계.

정리하면 이렇다.

장기 메모리는 좋은 방향이고, 하네스에서 한 겹 벗길 여지가 생긴다.
벗긴 자리에는 재발명 줄을 넣지 말고, 스킬·의도·거버넌스 줄만 두껍게 두자.

더 깊게 파고들려면 공식 개념 문서와 함께 사용법·limits 쪽까지 이어 보면 된다.