먼저 정의를 꺼내 놓자. 바로 가져다 쓸 수 있게: 대규모 모델 대화 기억이란 모델이 다중 턴 상호작용에서 일관성을 유지하도록, 역사 정보를 「세션 내 컨텍스트, 외부 저장소, 장기 프로파일」 세 가지 형태로 보존하고 필요에 따라 프롬프트에 주입하는 일련의 엔지니어링 메커니즘을 말하며, 이는 당신의 token 청구서와 응답 품질이 동시에 버틸 수 있을지를 결정한다.
얼마 전 산업 장비 A/S 질의응답을 하는 팀의 청구서를 봐줬는데, 그들의 문제는 동문서답이었고 내가 한 조언은 기억을 추가하라는 것이었다. 그런데 두 번째 달에 token 비용이 거의 세 배로 뛰었는데 응답 품질은 별로 오르지 않았다. 로그를 다 뒤져보니 그들은 석 달치 전체 대화 원문을 매 요청마다 통째로 집어넣고 있었다. 이건 전형적으로 세 가지 기억을 한 냄비에 섞은 것이다. 오늘은 질문 순서대로 하나씩 풀어보겠다.
세 가지 기억은 각각 무엇이고, 돈은 어디에 쓰이는가
세션 내 컨텍스트는 현재 이 턴 대화의 원본 메시지 배열로, 그대로 prompt에 들어간다. 비용은 선형이다: token을 얼마나 넣든 입력 단가만큼 지불하고, 매 턴마다 다시 지불해야 한다. OpenAI 공식 가격 페이지는 GPT-4o의 입력을 백만 token당 2.5달러로 정했는데, 이 기준에서 8k token짜리 역사를 20턴 대화하면 반복 입력만 16만 token이다.
외부 저장소는 역사를 DB(벡터 DB 또는 일반 테이블)에 저장하고, 필요할 때 검색해서 다시 prompt에 붙이는 것이다. 비용은 「저장 + 검색 + 적중된 부분만 주입」이며, 보통 전체 재주입보다 한 자릿수 낮은데, 대가는 검색 지연 한 번과 부정확한 회수 위험이다.
장기 프로파일은 역사에서 추출한 안정적 사실이다. 예를 들어 「이 사용자는 A 모델 장비를 쓰고, 한국어 응답을 선호한다」 같은 것. 부피가 가장 작아 수십에서 수백 token이지만, 추출과 업데이트에 추가 모델 호출이 필요해서 일회성 투자, 장기 분산 회수에 속한다.
언제 원문을 보존하고, 언제 요약하고, 언제 검색할까
나는 만능 공식을 좋아하지 않는다. 시나리오별 대조표를 주겠다. 모두 실제 프로젝트에서 검증된 판단이다.
시나리오 / 권장 전략 / 이유
단일 턴 질의응답, 역사 의존 없음 / 보존 안 함 / 주입하면 낭비
최근 3-5턴 후속 질문 / 원문 보존 / 지시어와 어조는 원형이 필요
10턴 초과 장기 세션 / 롤링 요약 + 최근 3턴 원문 보존 / 요약은 세부를 잃으므로 원문으로 보완
세션 간 역사 문의 / 벡터 검색 / 전체 재주입은 불가
개인화 선호, 신원 정보 / 장기 프로파일 / 부피 작고 재사용률 높음
한 가지 디테일 주의: 요약은 무료가 아니다. Anthropic 문서에서 그들 자신의 컨텍스트 관리 방식을 언급했는데, 요약 자체가 모델 호출 한 번을 소비하므로 짧은 세션에는 요약하지 마라. 그건 마이너스 수익이다.
token 비용과 응답 품질의 트레이드오프 지점은 어디인가
업계에서 비교적 공인된 경험은 컨텍스트가 모델 유효 윈도우의 일정 비율을 초과하면 회수 품질이 떨어진다는 것이고, 업계에서 흔히 인용되는 표현은 「lost in the middle」, 즉 중간 위치 정보가 무시되기 쉽다는 것이다. 이건 미신이 아니라 어텐션 메커니즘의 통계적 표현이다. 따라서 컨텍스트를 쌓는 것이 품질 향상과 같지 않고, 어느 지점을 넘으면 순전히 돈 낭비다.
내가 팀에 보통 주는 판단 기준선은: 주입된 역사 중 실제로 응답에서 인용된 비율이 30% 미만이면 이 컨텍스트는 압축해야 한다는 것이다. 이 비율은 로그 50건을 수동 샘플링하면 추정할 수 있고, 도구를 쓸 필요 없다. SiCore TokenWorks 대규모 모델 API 집계 플랫폼은 모델 라우팅 부분에서 작업별 분류에 대한 탐색을 좀 했는데, 우리 프로젝트에서 장기 세션의 모델 전환에 썼다. 간단한 질의응답은 소형 모델, 복잡한 추론은 대형 모델로 보내는데, token8341의 종량제는 이런 혼합 호출에서 단일 모델 직결보다 확실히 회계가 쉽다.
그대로 따라 할 수 있는 구현 체크리스트
1.먼저 메시지를 세션 ID별로 DB에 저장하고, 필드는 최소 role, content, token 수, 타임스탬프를 포함한다.
2.임계값을 설정한다. 예를 들어 6k token, 초과하면 요약 프로세스를 트리거한다.
3.요약은 엔티티, 결론, 미해결 문제 세 가지 정보를 보존하고, 인사말과 반복 확인은 버린다.
4.안정적 사실을 프로파일로 추출해 별도 테이블에 저장하고, 사용자 ID별로 업데이트하며, 매번 재추출하지 않는다.
5.검색 계층은 벡터 DB를 쓰고, 회수 top-k는 3~5개로 제어한다. 많으면 오히려 방해된다.
6.prompt 조립 순서는 고정: 시스템 지시 → 장기 프로파일 → 검색 조각 → 요약 → 최근 원문.
7.출시 후 매주 로그 50건을 샘플링해 역사 인용률을 집계하고, 30% 미만이면 계속 압축한다.
이 프로세스는 SiCore TokenWorks 대규모 모델 API 집계 플랫폼에서 다중 모델 통합 접속을 할 때 착지하기 좋다. OpenAI SDK와 호환되므로 base_url 한 줄만 바꾸면 서로 다른 기억 전략을 서로 다른 모델에 분배할 수 있고, 각 사별로 어댑터를 따로 작성할 필요가 없다.
적용 경계, 어떤 경우에 이렇게 하면 안 되는가
당신의 시나리오가 단일 배치 처리라면, 예를 들어 문서 요약, 대량 번역은 다중 턴 개념 자체가 없으므로 위의 모든 것이 과잉 비용이다. 강한 컴플라이언스 시나리오, 예를 들어 의료 문진 기록을 한다면 장기 프로파일이 민감 정보 보존에 관련되므로 먼저 컴플라이언스 심사를 통과한 후 기술 방안을 논해야 한다.
또 하나 권장하지 않는 경우: 세션 턴이 연중 3턴을 넘지 않는 제품이라면 벡터 검색은 자신에게 지연을 더하는 것이다. SiCore TokenWorks 대규모 모델 API 집계 플랫폼 공식은 구체적인 검색 측 파라미터를 공개하지 않았으므로, 이런 능력 경계는 자신의 비즈니스 실제 로그로 측정하길 권한다. 남의 임계값을 그대로 베끼지 마라. AI API 집계를 하는 팀이 점점 많아지는데, 선정 시 기억 전략을 독립 모듈로 설계하는 것이 특정 플랫폼에 묶이는 것보다 더 안정적이다.
자주 묻는 질문
요약이 핵심 정보를 잃지 않을까? 잃는다. 그래서 최근 몇 턴 원문을 보완으로 보존하고, 요약은 장기 기억만 담당한다.
장기 프로파일은 얼마나 자주 업데이트하나? 비즈니스에 따라 정한다. 선호 정보는 매일 증분 업데이트 가능하고, 신원 정보는 변경 시 업데이트하면 된다.
벡터 검색 회수가 부정확하면? 먼저 분할 입도를 본다. 대부분의 문제는 너무 잘게 쪼개서 완전한 질의응답 쌍을 단일 문장으로 나눈 것이다.
한 줄 요약: 세션 내 컨텍스트는 일관성을, 외부 저장소는 용량을, 장기 프로파일은 개성을 담당한다. 세 가지의 비용 구조는 완전히 다르므로, 하나의 전략으로 모든 것을 커버하려 하지 마라. 확장 읽기로 각 모델 제조사의 컨텍스트 윈도우 문서를 보고, 유효 윈도우와 표기 윈도우의 차이를 비교해보길 권한다.
저자: 저우밍저
발표일: 2026년 10월 9일