AI 에이전트에 메모리(Memory)를 구축하는 방법

에이전트가 이전 행동으로부터 학습할 수 있도록 루프(loop)를 구축하면, 사용자와 함께 학습하는 즐거운 에이전트 경험(agentic experiences)을 만들 수 있습니다. 이를 흔히 **메모리 (memory)**라고 부릅니다. 메모리는 사용자가 에이전트에게 무언가를 올바르게 수행하는 방법을 처음 알려준 후, 에이전트가 이를 기억하여 사용자가 계속해서 수정을 반복해야 하는 상황과 그렇지 않은 상황의 차이를 만들어냅니다.

구현 방식은 여전히 진화하고 있지만, 추상화(abstractions)는 단순합니다. 메모리를 구현하려면 에이전트가 실수를 했거나 새로운 정보를 학습할 수 있었던 지점을 찾아내고, 해당 정보를 추출 및 일반화하여 데이터 구조(data structure)로 만드는 프로세스를 백그라운드에서 실행해야 합니다. 아직 해결해야 할 세부 사항이 많이 남아 있습니다. 이 포스트에서는 이 프로세스의 구체적인 구현 방법을 살펴봅니다. 다음을 사용합니다:

• 트레이스 저장소(trace store)로서의 LangSmith Observability
• 트레이스를 분석하는 프로세스로서의 LangSmith Engine
• 메모리 저장소(memory store)로서의 LangSmith Context Hub

메모리란 무엇인가?

메모리는 에이전트가 자신의 행동을 안내하기 위해 여러 실행(runs)에 걸쳐 검색할 수 있는 지속적인 컨텍스트(context)입니다. 여기에는 사실(facts), 선호도(preferences), 과거 상호작용(past interactions), 지침(instructions), 기술(skills), 예시(examples), 그리고 학습된 패턴(learned patterns)이 포함될 수 있습니다.

트레이스(trace), 전사(transcript), 또는 로그(log)는 무슨 일이 일어났는지 보여주는 유용한 증거입니다. 관련 교훈이 에이전트가 나중에 실행할 때 검색하여 행동을 변경할 수 있는 컨텍스트로 변환될 때 비로소 메모리가 됩니다.

무엇이 어디에 속할지 결정하기 위해서는 메모리를 두 가지 범위로 나누는 것이 도움이 됩니다: 단기(short-term, 또는 '작업용(working)') 메모리와 장기(long-term) 메모리입니다.

**단기 메모리 (Short-term memory)**는 에이전트가 눈앞의 작업을 수행하는 동안 사용할 수 있는 컨텍스트입니다: 현재 스레드(thread), 최근 메시지, 도구 결과(tool results), 검색된 문서, 중간 추론 결과물(intermediate reasoning artifacts), 그리고 에이전트가 현재 작업을 완료하는 데 필요한 임시 파일 또는 상태(state) 등이 이에 해당합니다.

**장기 메모리 (Long-term memory)**는 현재의 실행(run)을 넘어 지속되는 컨텍스트입니다. 여기에는 사실(facts), 선호도(preferences), 예시(examples), 워크플로(workflows), 정책(policies), 지침(instructions), 그리고 시간이 흐름에 따라 에이전트의 행동을 형성하기 위해 나중에 사용할 수 있어야 하는 기술(skills) 등이 포함됩니다.

두 메모리 사이의 관계는 읽기 및 쓰기 사이클(read-and-write cycle)입니다. 실행 중에 에이전트는 하네스(harness)가 관련 컨텍스트를 사용할 수 있게 만들면 장기 메모리의 이점을 얻습니다. 이는 프롬프트 조립(prompt assembly), 저장소로부터의 검색(retrieval), 도구 접근(tool access), 파일, 런타임 상태(runtime state), 또는 기타 컨텍스트 로딩 메커니즘을 통해 이루어질 수 있습니다. 실행이 진행됨에 따라 작업 메모리(working memory)는 변화합니다. 실행이 끝난 후, 트레이스(trace)는 어떤 일이 일어났는지에 대한 증거를 제공합니다. 그 증거의 대부분은 이력(history)으로 남아야 하지만, 일부는 유용한 신호(signal)를 포함할 수 있습니다. 즉, 에이전트가 기억해야 할 선호도, 명확히 해야 할 지침, 규칙이 되어야 할 도구 사용 패턴, 또는 업데이트되어야 할 기술 등이 될 수 있습니다.

장기 메모리를 생각하는 유용한 방법은 이를 의미론적(semantic), 일화적(episodic), 절차적(procedural) 메모리로 나누는 것입니다. 이는 인지 과학(cognitive science)에서 빌려온 분류 체계이며 언어-에이전트 시스템(language-agent systems)에 흔히 매핑됩니다.

**의미론적 메모리 (Semantic memory)**는 에이전트가 알고 있는 것, 즉 사실, 선호도, 일반 지식입니다. **일화적 메모리 (Episodic memory)**는 에이전트가 경험한 것, 즉 과거의 상호작용, 예시, 행동 및 결과입니다. **절차적 메모리 (Procedural memory)**는 에이전트가 어떻게 행동해야 하는가에 대한 것, 즉 지침, 워크플로, 정책, 기술 및 도구 사용 규칙입니다.

에이전트 행동에서 가장 눈에 띄는 개선 사항 중 상당수는 절차적 메모리에서 비롯됩니다. 에이전트가 답변 형식을 반복적으로 잘못 작성하거나, 도구를 잘못된 순서로 호출하거나, 잘못된 하위 에이전트(subagent)에게 위임하거나, 어조 규칙을 무시하는 경우, 해결책은 종종 절차적입니다. 즉, 규칙을 더 명확하게 만들거나, 에이전트가 따르는 단계를 변경하거나, 해당 행동을 그 작업을 담당하는 더 구체적인 기술로 이동시키는 것입니다.

상위 수준의 메모리 프로세스

상위 수준에서 잘 작동하는 에이전트 메모리 루프는 세 부분으로 구성됩니다: 트레이스 캡처(capture traces), 트레이스 분석(analyze traces), 그리고 메모리 업데이트(update memory).

1. 트레이스 캡처 (Capture traces)

트레이스(Traces)는 증거 계층(evidence layer)입니다. 잘 설계된 계측(instrumented) 트레이스는 에이전트가 작업을 수행하며 거친 경로를 기록합니다: 사용자 입력, 모델 호출(model calls), 도구 입력 및 출력(tool inputs and outputs), 검색된 문서(retrieved documents), 라우팅 결정(routing decisions), 지연 시간(latency), 오류(errors), 그리고 종종 사용자 피드백까지 포함됩니다.

이것이 중요한 이유는 전통적인 결정론적 소프트웨어(deterministic software)와 달리, 에이전트의 궤적(trajectory)을 조사하기 전까지는 에이전트가 어떻게 행동했는지 알 수 없는 경우가 많기 때문입니다. 예상치 못한 동작은 취약한 프롬프트(prompt), 누락된 도구, 혼란스러운 도구 스키마(tool schema), 부실한 검색(retrieval), 오래된 컨텍스트(stale context), 지나치게 광범위한 지시사항, 또는 작업을 조용히 잘못된 곳으로 보낸 라우팅 결정으로 인해 발생할 수 있습니다. 트레이스를 조사하면 이러한 원인들을 격리(isolate)할 수 있습니다.

2. 트레이스 분석 (Analyze traces)

트레이스가 캡처되면, 다음 단계는 유용한 신호(signal)를 찾는 것입니다. 일부 신호는 명시적인 피드백이나 평가(eval) 실패에서 오며, 일부는 반복되는 패턴에서 옵니다: 동일한 잘못된 출력, 동일한 잘못된 도구 호출(invalid tool call), 동일한 라우팅 실수, 또는 동일하게 무시된 지시사항 등이 있습니다.

까다로운 부분은 진단(diagnosis)입니다. 동일한 증상이 서로 다른 해결책을 가리킬 수 있습니다. 만약 에이전트가 말투(tone) 규칙을 무시한다면, 해당 규칙이 너무 모호하거나, 잘못된 위치에 있거나, 관련 스킬(skill)에서 누락되었거나, 혹은 다른 지시사항과 모순될 수 있습니다.

3. 메모리 업데이트 (Update memory)

신호가 파악되면, 시스템은 향후 컨텍스트를 변경해야 할지 결정해야 합니다. 이는 지시사항을 명확히 하거나 라우팅 규칙을 변경하는 것과 같이 문제를 해결하는 것을 의미할 수도 있지만, 사용자의 선호도, 성공적인 사례, 또는 에이전트가 나중에 재사용해야 할 패턴과 같이 유용한 정보를 기억하는 것을 의미할 수도 있습니다.

LangSmith를 사용하여 이를 수행하는 방법

LangSmith를 통해 이 전체 에이전트 메모리 루프(agent memory loop)를 수행할 수 있습니다:

• 트레이스 캡처 (Capture traces): LangSmith Observability
• 트레이스 분석 (Analyze traces): LangSmith Engine
• 메모리 업데이트 (Update Memory): LangSmith Context Hub

LangSmith에서 트레이싱(tracing)은 캡처 단계를 제공합니다. 트레이싱 프로젝트(Tracing projects)는 에이전트가 거친 궤적(trajectories)의 풍부한 저장소를 제공하여, 에이전트가 왜 그렇게 행동했는지 조사하고 이해할 수 있게 해줍니다.

LangSmith Engine은 이러한 트레이스(traces)를 개선 신호(improvement signal)로 전환하는 백그라운드 프로세스입니다. 사용자가 모든 실행을 수동으로 검사할 필요 없이, Engine은 반복되는 문제를 분석하고, 발생 가능한 근본 원인을 진단하며, 향후 동작을 개선할 수 있는 구체적인 변경 사항을 제시합니다. 이는 규칙을 추가하거나, 지침(instruction)을 관련 워크플로(workflow)에 더 가깝게 이동시키거나, 새로운 예시를 생성하거나, 기술(skill)을 업데이트하거나, 라우팅 정책(routing policy)을 변경하는 방식일 수 있습니다.

Context Hub는 이러한 변경 사항이 지속 가능한 에이전트 컨텍스트(context)가 되는 곳입니다. 이곳은 에이전트가 사용하는 지침, 도구(tools), 기술을 관리할 수 있는 버전 관리된 공간을 제공하므로, 메모리가 단순히 애플리케이션 코드에 자리 잡은 임시적인 프롬프트 수정(ad hoc prompt edit)에 그치지 않게 합니다.

컨텍스트가 업데이트되면, 향후 실행 시 이를 다시 에이전트로 로드합니다. 이로써 루프(loop)가 완성됩니다. 즉, 트레이스가 캡처되고, Engine이 개선 신호를 추출하며, Context Hub가 메모리를 저장하고, 다음 실행은 업데이트된 컨텍스트와 함께 시작됩니다.

유용한 메모리를 위한 설계 원칙 (경험으로부터)

이 루프를 신뢰할 수 있게 만드는 몇 가지 원칙은 다음과 같습니다.

모든 것이 메모리 업데이트가 되어서는 안 됩니다. 대부분의 트레이스 데이터는 이력(history)으로 남아야 합니다. 일부는 데이터셋 예시, 평가(evals), 코드 변경, 또는 도구 스키마(tool-schema) 수정 사항이 되어야 합니다. 오직 아주 작은 부분집합만이 지속 가능한 컨텍스트가 되어야 합니다.

향후 실행 시 실제로 업데이트를 읽는지 확인하세요! 만약 런타임(runtime)이 프롬프트, 도구 또는 기술을 캐싱(caching)한다면, 메모리 커밋(commit)에는 새로고침 경로가 필요합니다. 그렇지 않으면 시스템이 올바른 업데이트를 저장하면서도 계속해서 오래된(stale) 컨텍스트로 실행될 수 있습니다.

평가(evals)를 통해 중요한 동작을 보호하세요. 메모리 업데이트가 향후 동작을 형성할 만큼 중요하다면, 해당 동작이 퇴보(regress)할 때 이를 감지할 수 있는 방법을 마련할 가치가 충분합니다.

Acknowledgements

사려 깊은 검토와 피드백을 주신 Sydney Runkle과 Harrison Chase에게 감사드립니다.