Memory와 컨텍스트 관리

메모리는 모든 기록이 아니다

에이전트의 메모리는 "이전 일을 모두 저장하는 창고"가 아닙니다. 다음 작업에 다시 쓸 만한 정보를 골라 보관하고, 필요할 때 꺼내 쓰는 장치입니다.

메모리를 잘 설계하면 에이전트는 사용자에게 맞춘 결과를 만들 수 있습니다. 예를 들어 사용자가 "짧고 단정한 문체를 좋아한다"는 선호를 기억하면, 매번 같은 설명을 반복하지 않아도 됩니다. 반대로 모든 대화와 파일 내용을 무작정 저장하면 비용이 늘고, 개인정보 위험도 커집니다. 더 큰 문제는 잘못된 기억이 다음 작업에 섞여 결과를 망칠 수 있다는 점입니다.

따라서 메모리 설계의 핵심은 많이 기억하는 것이 아니라, 무엇을 기억하지 않을지 정하는 것입니다.

단기 메모리와 장기 메모리

단기 메모리는 현재 작업 안에서만 유지되는 정보입니다. 지금 사용자의 목표, 방금 호출한 도구 결과, 아직 끝나지 않은 단계, 임시 제약 조건이 여기에 속합니다. 예를 들어 "이번 글은 1,000자 안쪽으로 작성한다"는 조건은 현재 작업에는 중요하지만, 모든 작업에 적용할 필요는 없습니다.

장기 메모리는 여러 세션에 걸쳐 재사용하는 정보입니다. 사용자의 글쓰기 스타일, 자주 쓰는 채널, 선호하는 출력 형식, 금지 표현, 승인 규칙 같은 것이 대표적입니다. 장기 메모리는 다음 대화에서도 사용되므로 저장 전 기준이 더 엄격해야 합니다. 사용자가 명시적으로 말했거나 여러 번 반복되어 신뢰할 수 있는 정보만 저장하는 편이 안전합니다.

사용자 선호는 구조화해서 저장한다

사용자 선호를 긴 문장으로만 저장하면 에이전트가 매번 다르게 해석할 수 있습니다. 가능하면 구조화된 형태로 저장하는 것이 좋습니다.

{
  "writing_tone": "간결하고 실용적",
  "preferred_channel": "블로그",
  "banned_phrases": ["혁신적인", "마법 같은"],
  "default_length": "1200자 내외",
  "needs_approval_before_publish": true
}

이렇게 저장하면 Executor는 작업 전에 필요한 선호만 꺼내 프롬프트에 넣을 수 있습니다. 또한 값이 잘못되었을 때 수정하기도 쉽습니다. 중요한 선호에는 출처와 갱신 시간을 함께 저장하는 것이 좋습니다. 예를 들어 "사용자가 2026년 5월 10일에 직접 설정함"처럼 남기면, 오래된 기억을 계속 믿는 문제를 줄일 수 있습니다.

작업 히스토리에서 저장할 것과 버릴 것

작업 히스토리는 유용합니다. 이전에 승인된 제목 스타일, 자주 쓰는 제품 설명, 반복되는 캠페인 목적은 다시 활용할 수 있습니다. 그러나 모든 히스토리가 메모리가 되어야 하는 것은 아닙니다.

저장해도 좋은 정보는 다음 작업의 품질을 높이는 정보입니다. 예를 들어 "뉴스레터 제목은 질문형보다 선언형을 선호한다"는 정보는 재사용 가치가 있습니다. 반대로 일회성 초안, 임시 파일 내용, 접근 토큰, 주민등록번호, 결제 정보, 민감한 건강 정보처럼 재사용 필요가 낮거나 위험이 큰 정보는 저장하지 않는 것이 원칙입니다.

필요해서 민감 정보를 저장해야 한다면 일반 메모리와 분리해야 합니다. 암호화, 접근 권한 제한, 보관 기간, 삭제 기능을 함께 설계해야 합니다. 에이전트에게 기억을 주는 일은 곧 책임도 함께 주는 일입니다.

컨텍스트 창에는 필요한 기억만 넣는다

모델은 한 번에 읽을 수 있는 입력 길이에 한계가 있습니다. 이를 컨텍스트 창이라고 부릅니다. 모든 과거 기록을 컨텍스트에 넣으면 비용이 늘고, 중요한 현재 지시가 묻힐 수 있습니다.

실제 시스템에서는 보통 세 단계를 사용합니다. 첫째, 현재 요청을 분석해 필요한 기억의 종류를 정합니다. 둘째, 메모리 저장소에서 관련 정보만 검색합니다. 셋째, 검색된 내용을 짧게 요약해 프롬프트에 넣습니다.

예를 들어 "AI 에이전트 소개 글을 Threads용으로 바꿔줘"라는 요청이 들어오면, 에이전트는 모든 과거 대화를 읽을 필요가 없습니다. 사용자의 채널 선호, 금지 표현, 짧은 문장 선호 정도만 가져오면 충분합니다. 기억은 많이 넣을수록 좋은 것이 아니라, 지금 작업에 맞게 골라 넣을수록 좋습니다.

실습: 선호를 반영하는 콘텐츠 에이전트

간단한 콘텐츠 에이전트를 설계해 봅시다. 목표는 같은 주제를 사용자 선호에 따라 다르게 작성하는 것입니다.

먼저 장기 메모리에 다음 선호를 저장합니다.

{
  "blog": {
    "tone": "차분하고 설명 중심",
    "length": "1000자 내외"
  },
  "threads": {
    "tone": "짧고 단정한 문장",
    "length": "5문장 이내"
  },
  "banned_phrases": ["완전 자동", "알아서 다 해줌"]
}

사용자가 "AI 에이전트를 소개하는 글을 만들어줘"라고 요청하면, Planner는 먼저 출력 채널을 확인합니다. 채널이 블로그라면 설명 중심의 구조를 만들고, Threads라면 핵심 문장만 남깁니다. Executor는 생성 전에 관련 메모리만 가져옵니다. 금지 표현은 모든 채널에 적용하고, 길이와 톤은 선택된 채널의 값을 사용합니다.

마지막으로 사용자가 "앞으로는 더 친근한 말투로 해줘"라고 말하면 바로 전체 메모리를 덮어쓰지 않습니다. "블로그에도 적용할까요, Threads에만 적용할까요?"라고 확인한 뒤 저장합니다. 좋은 메모리 시스템은 사용자를 대신해 추측하지 않습니다. 필요한 만큼 기억하고, 위험한 것은 묻고, 오래된 것은 갱신합니다.