대모델의 4가지 기억 메커니즘
모델 자체는 기억하지 않는다. 모든 API 호출은 독립적인 요청이며, 모델이 무엇을 볼 수 있는지는 전적으로 이번에 전달한 Prompt에 달려 있다. 이른바 "기억"이란 애플리케이션 계층이 이력, 요약, 검색 조각을 다시 조직해 컨텍스트에 넣은 결과다.
기억의 본질: 애플리케이션 계층이 컨텍스트를 관리하는 것
- 이력 — 최근 몇 턴의 원문 대화
- 요약 — 비교적 오래된 대화를 압축한 짧은 텍스트
- 검색 조각 — 이력 저장소에서 의미 유사도로 건져 올린 관련 내용
전략 1 (기본안): 전량 이어붙이기
- 방식: 첫 턴부터 지금까지의 모든 대화 기록 + 사용자의 최신 질문을 함께 모델에 전송
- 짧은 대화에서의 장점: 단순하고 직관적. 모델이 "사용자 이름 / 개인 선호 / 현재 목표"를 직접 획득 가능
- 대가: 대화가 길어질수록 → Token 증가 → 비용 증가 → 응답 지연, 최종적으로 컨텍스트 윈도우 상한에 부딪힘
- 결론: 실제 제품에서 매번 전량을 이어붙이면 금방 "비싸고 느려진다"
전략 2: 슬라이딩 윈도우 (눈앞을 관리)
- 방식: 최근 몇 턴의 원문만 유지. 새 메시지가 들어오면 가장 오래된 메시지가 밀려남
- 장점: 모델이 항상 현재 화제의 컨텍스트를 볼 수 있고 비용이 통제 가능
- 예시: 사용자가 하나의 주문에 대해 연속 질문할 때, 최근 몇 턴에 주문번호, 문제 설명, 상담원 설명이 있으면 답변에 충분
- 구체적 샘플값: 주문번호
10086, 문제 설명 「물류 정체」, 상담원 설명 「기상 원인」
- 명확한 단점: 초기의 중요 정보가 밀려난다
- 도식 예: 「평생회원 신분(1턴)」이 밀려나고 현재 컨텍스트 윈도우에는 48/49/50턴만 남음 → 초기 중요 정보 유실
전략 3: 요약식 기억 (주선을 관리)
- 방식: 주기적으로 오래된 대화를 짧은 요약으로 압축하고, 요청 시 "요약 + 최근 몇 턴 원문 + 현재 질문"을 함께 전달
- 요약 샘플 (이력 대화 압축 → 짧은 요약 생성):
- 사용자: 샤오밍
- 회원: 평생회원
- 학습 중: Python
- 선호: 생활 밀착형 예시
- 보관에 적합한 것: 사용자 프로필, 장기 목표, 단계별 결론, 안정적 선호
- 한계: 요지는 남고 디테일은 사라진다. 사용자가 아주 오래전 붙여넣은 에러 코드를 요약이 한 줄 한 줄 보존할 가능성은 거의 없다
전략 4: 벡터 검색 (먼 곳의 디테일을 관리)
- 방식: 과거 메시지, 문서 내용, 코드 조각을 벡터로 변환해 벡터 데이터베이스(Vector Database)에 저장. 새 질문이 들어오면 의미 유사도로 관련 조각을 소환해 Prompt에 보충
- 해결하는 문제: 먼 곳의 디테일
- 예시: 사용자가 갑자기 "예전에 그 로그인 API 에러 어떻게 고치지?"라고 물으면, 시스템이 그때 붙여넣은 코드, 에러 스택 정보, 팀 논의 기록을 정확히 검색해낸다. 최근 몇 턴이나 요약 한 단락만으로 억지 추측하지 않는다
핵심 통찰
- LLM API는 무상태이며, "기억"은 제품 계층의 공학 능력이다 — 모델은 이력을 저장하지 않으며 매 요청은 완전히 새로운 세션이다. "기억할 수 있는가"는 전적으로 Prompt를 조립하는 방식이 결정한다. "모델이 알아서 기억한다"고 답하면 즉시 탈락.
- 컨텍스트 관리의 진짜 제약은 이중이다: 윈도우 길이 + 비용 예산 — 윈도우 길이만 보면 문제를 과소평가한다. Token 수는 비용과 지연을 동시에 결정하므로 셋이 함께 악화된다. 그래서 전량 이어붙이기는 "길이 초과"만이 아니라 "비싸고 느린" 것이다.
- 각 기억 전략은 서로 다른 "시간 척도"에 대응하며 상호 대체 관계가 아니다 — 눈앞(슬라이딩 윈도우), 주선(요약), 먼 곳(벡터 검색) 세 척도가 각각 한 구간을 맡는다. 경쟁재로 보고 양자택일하는 것이 흔한 오해다.
- 압축은 필연적으로 손실이며, 관건은 무엇을 버릴지 제대로 고르는 것 — 요약은 요지를 지키고 디테일을 버리는데, 이것은 결함이 아니라 정의다. 따라서 구조적이고 안정적이며 변경 빈도가 낮은 정보(프로필, 등급, 선호, 목표)는 요약에 넣고, 롱테일이고 고정밀이며 원문급인 정보(코드, 스택, 로그)는 반드시 검색으로 가야 한다.
- "검색"은 정밀도를, "요약"은 연속성을 보충한다 — 둘은 직교 차원이다. 요약만 있으면 시스템은 "네가 누군지는 기억하지만 디테일은 못 맞히고", 검색만 있으면 "옛 코드는 찾아내지만 장기 목표는 모른다".
- 정보를 어디에 둘지는 "변경 빈도"와 "권위 소스"를 보고 판단한다 — 회원 등급은 DB라는 권위 소스가 있고 변경될 수 있으므로 요약에 밀어 넣으면 만료 위험이 있다. 주문 컴플레인은 현재 화제이므로 슬라이딩 윈도우의 관할이다.
- 성숙한 시스템은 조합이지 몰빵이 아니다 — 상용급 대화 시스템은 보통 슬라이딩 윈도우 + 요약 + 벡터 검색 세 갈래를 동시에 돌리고, 척도별로 계층화해 Prompt를 조립한다.
엔지니어링 실전 Tips
- 비용 3연쇄는 같은 방향으로 악화된다: 대화가 길어질수록 → Token 증가 → 비용 증가 → 응답 지연. 컨텍스트 최적화 시 비용과 지연을 Token 수라는 하나의 지표로 함께 측정할 수 있다.
- 슬라이딩 윈도우에는 "고정(pin)" 메커니즘이 필요하다: 단순 FIFO는 1턴의 회원 신분을 밀어내 버린다. 실무에서는 신분류 정보를 윈도우에서 빼내 상주시켜야 한다(요약식 기억이 존재하는 이유가 바로 이것).
- 요약은 한 단락 글보다 구조화 필드로 쓰는 편이 안정적이다: 「사용자 / 회원 / 학습 중 / 선호」 네 필드가 자유 텍스트보다 드리프트에 강하고 Token도 절약되며 증분 갱신도 쉽다.
- 에러, 스택, 코드가 요약에 남을 것을 기대하지 말 것: 이런 내용은 반드시 원문으로 벡터 저장소에 넣고 검색 시 통째로 소환해야 한다.
- 검색의 발동 조건은 "새 질문이 먼 곳을 가리킬 때": "예전에 그 로그인 API 에러"처럼 지시대명사를 동반한 질문이 검색 경로의 가장 전형적인 발동 신호다.
- 한 가지 전략으로 모든 문제를 풀려 하지 말 것. 단일 방안에 몰빵하지 말 것.