“지난번에 말씀하신 배송지를 기억하고 있습니다.” 개인 비서라면 편리한 기능입니다. 그런데 주소가 이미 바뀌었거나 다른 가족의 대화에서 가져온 정보라면 편리함은 바로 사고가 됩니다. 기업용 AI 에이전트에서도 비슷한 일이 생깁니다. 과거 대화의 요약을 최신 계약 조건으로 착각하고, 중단된 업무를 처음부터 다시 실행하거나, 한 고객의 선호를 다른 고객에게 적용합니다. 기억이 많아질수록 똑똑해질 것 같지만 관리되지 않은 기억은 오래된 데이터와 잘못된 추론을 더 오래 보존할 뿐입니다.
에이전트의 기억은 하나의 데이터베이스나 긴 대화 기록이 아닙니다. 지금 모델이 보는 문맥, 한 대화의 세션 기록, 재개 가능한 업무 상태, 세션을 넘는 장기 기억, 그리고 실제 업무 시스템의 원본 데이터가 서로 다른 목적과 정확성 요구를 가집니다. 이들을 한 저장소와 한 검색 방식으로 다루면 성능·비용·보안·정합성 문제가 동시에 커집니다.
이 글은 에이전트에 기억 기능을 추가하는 방법보다 먼저 무엇을 기억이라 부를지, 무엇은 기억하면 안 되는지, 언제 믿고 언제 원본을 다시 조회할지를 설계하는 방법을 정리합니다. 결론부터 말하면 좋은 에이전트는 모든 것을 기억하는 에이전트가 아니라 필요한 범위의 검증된 정보만 현재 문맥으로 조립하는 에이전트입니다.
기억과 문맥과 상태는 같은 것이 아니다
용어가 섞이면 설계도 섞입니다. 문맥(context)은 이번 모델 호출에 실제로 전달되는 토큰입니다. 세션(session)은 한 대화나 스레드의 메시지 흐름을 이어 주는 저장 단위입니다. 업무 상태(state)는 현재 단계, 완료된 작업, 승인 결과와 산출물처럼 실행을 재개하는 데 필요한 구조화된 데이터입니다. 장기 기억(memory)은 여러 세션에 걸쳐 다시 활용할 가치가 있다고 판단해 보존한 정보입니다.
OpenAI Agents SDK 문서도 애플리케이션 코드가 사용하는 로컬 실행 문맥과 모델이 보는 대화 문맥을 구분하며, 세션은 특정 대화의 이력을 저장하는 기능으로 설명합니다. LangGraph 역시 단기 기억을 스레드 범위의 에이전트 상태로, 장기 기억을 세션을 넘어 사용자 또는 애플리케이션 범위에서 사용하는 데이터로 나눕니다.
이 차이는 구현 세부사항이 아닙니다. 업무 상태는 정확하게 저장되고 트랜잭션과 재시도를 견뎌야 하지만, 대화 요약은 일부 표현을 잃어도 됩니다. 사용자 선호는 수정과 삭제가 가능해야 하고, 계약 금액은 기억에서 꺼내지 말고 원본 시스템에서 다시 조회해야 합니다.
에이전트 메모리의 다섯 계층
1. 현재 모델 문맥
시스템 지시, 이번 사용자 입력, 최근 대화, 필요한 기억, 검색 문서, 도구 결과 중 이번 추론에 필요한 부분만 조립한 것입니다. 모델이 직접 볼 수 있는 유일한 정보이지만 저장소 자체는 아닙니다. 문맥 창이 크더라도 모든 기록을 넣으면 오래된 정보가 주의를 분산하고 지연시간과 비용이 커집니다.
2. 대화 세션
같은 스레드의 앞뒤 질문을 연결합니다. “그중 두 번째 안으로 진행해 줘” 같은 표현을 해석하려면 최근 메시지가 필요합니다. OpenAI Agents SDK의 세션은 실행 전 대화 이력을 가져오고 실행 후 새 항목을 저장하며, 세션 ID별로 대화를 분리합니다. 세션을 사용하면서 서버 관리형 대화 상태까지 중복으로 섞으면 같은 이력이 두 번 들어갈 수 있으므로 한 대화에서는 주된 지속 전략을 명확히 정하는 것이 좋습니다.
3. 업무 실행 상태와 체크포인트
주문 등록의 현재 단계, 이미 업로드한 파일 해시, 승인 ID, 외부 시스템의 접수 번호와 다음 재시도 시각을 구조화해 저장합니다. 이것은 자연어 요약이 아니라 워크플로 엔진과 데이터베이스가 관리해야 할 정확한 상태입니다. 프로세스가 재시작되어도 완료한 단계를 반복하지 않고 이어갈 수 있어야 합니다.
4. 장기 기억
사용자의 선호, 반복적으로 확인된 업무 관행, 이전 작업에서 얻은 유용한 교훈처럼 다른 세션에서도 가치가 있는 정보를 보존합니다. LangChain의 기억 개념은 장기 기억을 사실 중심의 의미 기억, 과거 경험 중심의 일화 기억, 수행 규칙에 해당하는 절차 기억으로 나눠 생각할 수 있다고 설명합니다. 종류에 따라 생성과 검증, 검색 방식이 달라집니다.
5. 기업 원본 데이터
고객 주소, 재고 수량, 계약 상태, 가격, 권한과 정책처럼 정답을 소유한 업무 시스템입니다. 이것은 에이전트의 기억이 아닙니다. 필요할 때 권한 있는 API나 데이터베이스에서 조회하고 버전과 시각을 확인해야 합니다. 기억에는 원본 전체를 복사하기보다 대상 ID와 사용 맥락을 남기는 편이 안전합니다.
대화 전체를 계속 넣으면 왜 나빠질까
긴 문맥은 정보 손실을 늦추지만 기억 설계를 대신하지 않습니다. 과거 도구 호출의 거대한 JSON, 이미 해결된 논의, 철회된 요구사항이 계속 남으면 모델은 현재 중요한 정보와 오래된 정보를 구분해야 합니다. 입력 토큰과 지연시간이 늘고, 동일한 지시가 서로 충돌할 가능성도 커집니다.
Anthropic은 에이전트의 문맥을 유한한 자원으로 보고, 긴 작업에서 압축, 구조화된 메모, 필요 정보의 선택적 로딩을 활용하는 문맥 공학을 설명합니다. 핵심은 최대한 많은 토큰을 채우는 것이 아니라 원하는 행동에 가장 도움이 되는 고신호 정보를 선택하는 것입니다.
실전에서는 최근 몇 개 턴을 원문으로 유지하고, 오래된 구간은 결정·제약·미해결 질문 중심으로 요약합니다. 대용량 도구 결과는 원문을 다시 넣지 않고 저장 위치와 핵심 결과만 남깁니다. 다만 승인 금액, 고객 식별자, 법적 문구처럼 손실되면 안 되는 값은 요약에 맡기지 않고 구조화된 상태에서 불러옵니다.
세션 요약은 사실이 아니라 파생 데이터다
요약 모델은 중요한 정보를 빠뜨리거나 추론을 사실처럼 적을 수 있습니다. 따라서 세션 요약을 원본보다 높은 권위로 사용하면 안 됩니다. 요약에는 생성 시각, 사용한 모델과 프롬프트 버전, 대상 메시지 범위, 원본 세션 ID를 연결합니다. 중요 결정을 표시할 때는 근거 메시지나 업무 기록으로 돌아갈 수 있어야 합니다.
AWS의 에이전트 메모리 문서는 세션이 끝난 뒤 대화 요약을 비동기로 생성하고, 보존 기간을 설정하거나 기억을 삭제하는 방식을 제공합니다. 이는 요약 자체도 생성 실패, 지연, 보존 정책을 가진 별도 파이프라인이라는 점을 보여줍니다. 요약이 아직 만들어지지 않았다고 업무 트랜잭션이 사라져서는 안 됩니다.
장기 기억에 무엇을 쓸지 먼저 제한한다
“유용해 보이는 것은 모두 저장”하는 정책은 위험합니다. 모델은 사용자의 일회성 말, 농담, 추측, 다른 사람에 대한 정보까지 선호나 사실로 저장할 수 있습니다. 기억 주제를 사전에 정의하고 저장 금지 항목과 동의가 필요한 항목을 구분해야 합니다.
- 저장하기 좋은 후보: 사용자가 명시적으로 밝힌 반복 선호, 검증된 업무 기본값, 완료된 작업에서 얻은 재사용 가능한 절차
- 조건부 후보: 직무·프로젝트·조직에 따라 유효 기간이 있는 설정, 사용자 확인이 필요한 추론된 선호
- 저장하면 안 되는 항목: 비밀번호와 토큰, 불필요한 민감정보, 근거 없는 성향 추정, 원본 시스템에서 항상 다시 확인해야 하는 최신 값
Google Cloud Memory Bank 문서는 추출할 기억의 주제를 정의하고 예시를 통해 기대하는 기억 형태를 조정하며, 세션 또는 사용자 같은 범위별로 다른 정책을 적용할 수 있도록 설명합니다. 제품과 관계없이 이 원칙이 중요합니다. 저장 모델에게 자유롭게 판단시키기보다 조직이 기억의 허용 범주를 먼저 정해야 합니다.
기억 레코드에는 값보다 더 많은 정보가 필요하다
장기 기억을 단순한 텍스트와 임베딩만으로 저장하면 충돌과 삭제를 다루기 어렵습니다. 최소한 다음 메타데이터가 필요합니다.
- 기억 ID와 유형: 선호, 사실, 경험, 절차, 요약
- 테넌트·조직·사용자·프로젝트·에이전트 범위
- 정규화된 내용과 검색용 표현
- 근거가 된 메시지·문서·업무 실행 ID와 생성 시각
- 사용자가 명시했는지 모델이 추출했는지에 대한 출처
- 신뢰도와 검증 상태, 검증자
- 유효 시작·종료, 만료 시각과 마지막 확인 시각
- 대체한 이전 기억과 현재 활성 버전
- 동의 근거, 민감도, 삭제 요청 전파 상태
임베딩은 관련 기억을 찾는 색인이지 권한과 유효성을 판단하는 기준이 아닙니다. 벡터가 비슷하다는 이유만으로 다른 고객의 기억을 반환해서는 안 됩니다.
기억 범위는 검색보다 먼저 적용한다
장기 기억 검색은 먼저 테넌트와 사용자, 프로젝트, 에이전트 역할, 데이터 분류로 후보를 제한한 뒤 그 안에서 유사도를 계산해야 합니다. 모든 기억을 벡터 검색한 뒤 결과 화면에서 사용자 ID를 걸러내는 방식은 중간 캐시와 로그, 잘못된 코드 경로에서 데이터가 섞일 수 있습니다.
Google Cloud의 기억 검색 문서도 지정한 범위가 정확히 일치하는 기억만 대상으로 유사도 검색을 수행하는 방식을 설명합니다. 기업 환경에서는 데이터베이스 행 수준 보안, 별도 네임스페이스 또는 물리 분리 같은 저장 계층의 통제를 함께 적용해야 합니다.
다중 에이전트 환경에서는 같은 사용자라도 에이전트마다 읽을 수 있는 기억 종류가 달라야 합니다. 일정 에이전트가 선호하는 회의 시간을 볼 수는 있어도 재무 상담의 민감한 메모까지 읽을 이유는 없습니다. 기억 접근도 일반 업무 데이터와 같은 권한 정책과 감사 로그를 가져야 합니다.
기억의 충돌은 덮어쓰지 말고 대체 관계로 관리한다
어제 사용자가 “보고서는 항상 PDF로 보내 주세요”라고 했고 오늘 “앞으로는 엑셀로 보내 주세요”라고 했다면 두 기억 중 하나를 무작정 삭제하기보다 최신 기억이 이전 기억을 대체한다는 관계를 남깁니다. 그래야 언제 왜 기본값이 바뀌었는지 설명할 수 있고 잘못 추출된 변경을 되돌릴 수 있습니다.
서로 다른 출처가 충돌할 때는 권위와 최신성을 따집니다. 사용자의 명시적 수정은 모델이 추론한 선호보다 우선하고, 승인된 업무 정책은 개인 메모보다 우선합니다. 어느 것이 맞는지 판단할 수 없으면 두 값을 동시에 모델에 넣지 말고 확인 질문을 하거나 원본 시스템을 조회합니다.
시간에 따라 변하는 사실에는 유효 기간을 둡니다. “현재 프로젝트는 A”라는 기억은 영구 사실이 아닙니다. 만료됐거나 오래 확인되지 않은 기억은 검색 후보에서 제외하고 필요하면 재검증합니다.
기억의 생성 경로는 빠른 경로와 느린 경로로 나눈다
대화 도중 즉시 기억을 쓰면 다음 턴부터 활용할 수 있지만 사용자 응답이 느려지고, 충분한 맥락 없이 섣불리 저장할 수 있습니다. 세션 종료 후 백그라운드에서 추출하면 여러 메시지를 종합하고 중복을 정리할 수 있지만 바로 반영되지는 않습니다.
명시적인 “이것을 기억해 줘” 요청이나 즉시 필요한 업무 제약은 빠른 경로에서 후보를 만들고 사용자에게 확인합니다. 일반적인 선호 추출과 경험 정리는 백그라운드에서 처리합니다. 어느 경로든 바로 활성 기억으로 쓰기보다 후보 생성, 분류, 민감정보 검사, 근거 확인, 중복·충돌 처리, 범위와 만료 지정 단계를 거칩니다.
업무 상태는 자연어 기억으로 복구하지 않는다
에이전트가 결제 요청을 만들다 승인 대기 상태에서 중단됐다고 가정해 봅시다. “결제 준비 중이었음”이라는 기억만으로는 어느 요청인지, 금액이 얼마인지, 승인받았는지, 외부 시스템에 이미 등록됐는지 알 수 없습니다. 재실행하면 중복 결제가 생길 수 있습니다.
내구성 있는 업무 상태에는 단계, 입력 데이터 버전, 완료된 도구 호출, 멱등성 키, 승인 증거, 외부 접수 번호, 산출물 해시와 재시도 횟수를 구조화해 기록합니다. 상태 전이는 트랜잭션으로 보호하고, 실행 재개 시 실제 외부 상태를 검증합니다. 모델에게는 다음 결정을 위해 필요한 요약만 보여줍니다.
LangGraph는 단기 기억을 그래프 상태와 체크포인터로 지속해 스레드를 재개할 수 있도록 설명합니다. 여기에서도 핵심은 메시지 이력뿐 아니라 필요한 상태를 명시적으로 정의하는 것입니다. 장기 기억 검색은 체크포인트 복구를 대신할 수 없습니다.
원본 데이터와 캐시와 기억을 구분한다
재고 수량을 빠르게 답하기 위해 최근 도구 결과를 캐시할 수 있습니다. 하지만 캐시는 성능 최적화이고 장기 기억은 사용자 경험과 추론을 위한 정보입니다. 캐시는 원본의 TTL과 무효화 규칙을 따르고, 기억은 출처·동의·범위·수정 정책을 따릅니다. 두 저장소를 합치면 오래된 캐시가 영구 기억처럼 남거나 사용자 삭제가 시스템 캐시까지 불필요하게 파급될 수 있습니다.
업무 원본에는 명확한 시스템 오브 레코드를 지정합니다. 고객 주소는 CRM, 주문 상태는 주문 DB, 문서 정책은 승인된 문서 저장소가 정답입니다. 기억은 “사용자가 배송 관련 질문을 자주 한다” 같은 맥락을 제공할 수 있지만 현재 배송지는 CRM에서 확인해야 합니다.
사용자가 기억을 보고 고치고 지울 수 있어야 한다
개인화가 강해질수록 투명성이 중요합니다. 사용자는 에이전트가 자신에 대해 무엇을 기억하는지 확인하고, 잘못된 항목을 수정하며, 더 이상 원하지 않는 기억을 삭제할 수 있어야 합니다. “모든 기록 삭제”뿐 아니라 특정 선호, 프로젝트 또는 기간별 삭제가 가능하면 실용적입니다.
삭제는 주 저장소의 행을 지우는 데서 끝나지 않습니다. 벡터 색인, 검색 캐시, 파생 요약, 평가 데이터와 백업의 보존 정책을 확인하고 삭제 상태를 전파해야 합니다. 법적 보존이 필요한 감사 기록은 개인화 기억과 분리하고 목적과 접근권한을 다르게 둡니다.
기억이 모델 문맥에 들어가기 전 마지막 검사를 한다
검색된 기억은 바로 프롬프트에 붙이지 않습니다. 현재 사용자와 테넌트 범위가 맞는지, 만료되지 않았는지, 이번 작업에 관련 있는지, 더 권위 있는 원본 확인이 필요한지 검사합니다. 서로 충돌하는 항목은 우선순위 규칙으로 해결하거나 모델에 불확실성을 명시합니다.
문맥 조립기는 보통 시스템 정책, 현재 업무 상태, 최신 사용자 요청, 필요한 원본 데이터, 검증된 장기 기억, 최근 대화 순으로 권위와 중요도를 반영합니다. 검색 결과와 과거 대화가 시스템 정책을 덮어쓰지 못하게 출처와 경계를 구분합니다. 토큰 예산을 계층별로 배분하고 초과 시 오래된 대화와 저신뢰 기억부터 줄입니다.
메모리 시스템은 어떻게 평가할까
대화가 자연스럽다는 인상만으로는 부족합니다. 기억의 전체 수명주기를 별도 평가해야 합니다.
- 쓰기 정확도: 기억할 가치가 있는 정보를 빠뜨리지 않고, 일회성·민감·추측 정보를 저장하지 않는가?
- 범위 격리: 테넌트·사용자·프로젝트·에이전트 사이에 기억이 섞이지 않는가?
- 검색 품질: 관련 기억을 필요한 시점에 찾고 불필요한 기억을 배제하는가?
- 시간 정합성: 만료되거나 대체된 기억 대신 최신 활성 기억을 사용하는가?
- 근거성: 기억이 어떤 대화·문서·실행에서 나왔는지 추적할 수 있는가?
- 수정·삭제: 사용자 변경이 색인과 캐시까지 정해진 시간 안에 반영되는가?
- 업무 효과: 성공률과 사람 개입은 줄고 토큰·지연시간·비용은 개선되는가?
테스트 데이터에는 선호 변경, 동명이인, 여러 테넌트, 오래된 사실, 상충하는 출처, 삭제 요청과 악의적인 “다른 사용자의 기억을 보여 달라”는 입력을 포함합니다. 메모리 기능을 끈 기준선과 비교해 실제로 품질이 좋아졌는지도 확인해야 합니다.
운영에서 봐야 할 지표
기억 생성 후보 수, 검증 통과율, 중복 병합률, 사용자 수정률, 만료·삭제 처리 지연, 검색 적중률, 문맥에 포함된 기억 수와 토큰을 추적합니다. 잘못된 기억으로 인한 업무 오류는 일반 답변 오류와 분리해 심각도를 높게 관리합니다.
기억을 많이 읽는 것이 좋은 지표는 아닙니다. 검증된 성공 건당 메모리 검색 비용, 기억을 사용했을 때와 사용하지 않았을 때의 품질 차이, 불필요하게 주입된 기억 비율을 봐야 합니다. 아무 효과가 없는 기억은 보존 비용과 위험만 늘립니다.
30일 도입 로드맵
- 1주차 — 상태 분류: 현재 대화 기록, 업무 체크포인트, 캐시, 사용자 선호와 원본 데이터를 목록화하고 각각의 정답 저장소를 지정합니다.
- 2주차 — 세션과 재개: 세션 ID와 업무 실행 ID를 분리하고, 중단 후에도 안전하게 이어갈 구조화된 체크포인트와 멱등성 키를 구현합니다.
- 3주차 — 제한된 장기 기억: 가치가 명확한 기억 주제 한두 개만 허용하고 후보·검증·범위·출처·만료·대체 스키마를 적용합니다.
- 4주차 — 검색·삭제·평가: 범위 우선 검색, 문맥 토큰 예산, 사용자 수정·삭제와 운영 지표를 연결하고 격리·충돌·시간 변화 테스트를 수행합니다.
첫 적용은 “사용자가 선호하는 보고서 형식”처럼 확인하기 쉽고 잘못돼도 되돌릴 수 있는 항목이 좋습니다. 금융 정보, 건강 정보, 접근 권한, 계약 상태처럼 영향이 큰 정보는 원본 조회를 유지해야 합니다.
Nature Fractal이 보는 에이전트 메모리의 핵심
에이전트 메모리는 벡터 데이터베이스를 하나 추가하는 기능이 아니라 데이터 아키텍처와 업무 상태 관리의 문제입니다. 대화형 UX, 장기 개인화, 워크플로 재개, 기업 데이터 정합성과 개인정보 보호가 한 경계에서 만납니다. 모델 프레임워크만 보고 설계하면 기존 CRM, ERP, 문서 시스템의 정답과 충돌하기 쉽습니다.
Nature Fractal은 에이전트가 기억할 정보와 매번 원본에서 확인할 정보를 먼저 나누고, 세션·업무 상태·장기 기억을 각자의 저장소와 수명주기로 연결하는 방식을 중요하게 봅니다. 이렇게 해야 모델이나 메모리 제품을 바꿔도 데이터의 권위, 권한, 삭제와 감사 구조는 유지됩니다.
도입 전 체크리스트
- 현재 모델 문맥, 대화 세션, 업무 상태와 장기 기억을 구분했는가?
- 기업 원본 데이터의 시스템 오브 레코드가 지정되어 있는가?
- 대화 요약을 원본이 아닌 파생 데이터로 취급하는가?
- 장기 기억으로 저장할 주제와 금지 항목이 정의되어 있는가?
- 기억마다 범위·출처·신뢰도·유효기간·대체 관계가 있는가?
- 테넌트와 사용자 범위를 적용한 뒤 유사도 검색을 수행하는가?
- 충돌한 기억을 덮어쓰지 않고 확인하거나 버전으로 관리하는가?
- 업무 재개는 자연어 요약이 아닌 구조화된 체크포인트를 사용하는가?
- 사용자가 자신의 기억을 확인·수정·삭제할 수 있는가?
- 삭제가 벡터 색인과 캐시, 파생 데이터까지 전파되는가?
- 문맥 조립에 토큰 예산과 권위·최신성 규칙이 있는가?
- 기억 사용 전후의 품질·비용·오류를 실제로 비교하는가?
좋은 기억은 많이 저장된 기록이 아닙니다. 누가 말했고 언제까지 유효하며 왜 믿을 수 있는지 설명되고, 필요할 때 정확한 범위에서 검색되며, 틀리면 수정하고 지울 수 있는 정보입니다. 에이전트가 오래 일하게 만들고 싶다면 대화 내용을 무한히 쌓기보다 기억과 상태와 원본의 경계부터 설계해야 합니다.
