AI 대화 기록을 영구적으로 보관할 때 발생하는 비용

AI 인프라에서 저지르기 쉬운 실수 중 하나는 모든 것을 영구적으로 보관하는 것입니다.

처음에는 무해하게 느껴집니다.

저장 비용은 저렴합니다.
더 많은 메모리(Memory)는 유용해 보입니다.
더 긴 대화 기록은 더 똑똑하게 느껴집니다.

그래서 팀들은 대화 상태(Conversation state)를 끝없이 추가합니다.

모든 사용자 메시지
모든 모델 응답
모든 검색 결과 (Retrieval result)
모든 도구 출력 (Tool output)
모든 재시도 추적 (Retry trace)
모든 실행 로그 (Execution log)

그 어떤 것도 삭제되지 않습니다.

그러다 시스템이 몇 달 동안 지속적으로 실행됩니다.

그때 진짜 비용이 나타납니다.

단순히 재정적인 측면뿐만이 아닙니다.

운영(Operationally) 측면에서도 그렇습니다.

긴 대화 기록이 성능을 서서히 저하시키는 이유

대부분의 AI 시스템은 갑자기 실패하지 않습니다.

서서히 성능이 저하됩니다.

우리는 기업 통합(Enterprise integrations) 환경에서 지속적으로 실행되는 프로덕션 워크플로(Production workflows)에서 이를 목격하기 시작했습니다.

초기에는 증상들이 서로 관련 없어 보였습니다:

느려지는 응답 속도
커지는 프롬프트 (Prompts)
일관성 없는 추론 (Reasoning)
반복되는 출력
상승하는 토큰 비용 (Token costs)
불필요한 검색 호출 (Retrieval calls)

모델의 품질은 변하지 않았습니다.

인프라가 변한 것이었습니다.

대부분의 컨텍스트(Context)가 더 이상 중요하지 않음에도 불구하고 대화 기록은 계속 확장되었습니다.

시스템이 오래된 상태(Old state)를 영구적으로 계속 끌고 가고 있었던 것입니다.

더 많은 컨텍스트가 항상 더 나은 추론을 의미하지는 않는다

이것은 중요한 깨달음이었습니다.

AI 시스템은 메모리 창(Memory windows)이 커진다고 해서 자동으로 더 똑똑해지지 않습니다.

특정 지점을 지나면, 추가적인 컨텍스트는 간섭(Interference)이 됩니다.

과거의 정보가 현재의 추론과 경쟁하게 됩니다.

우리는 다음과 같은 내용이 포함된 프롬프트를 발견했습니다:

오래된 지침 (Outdated instructions)
쓸모없어진 도구 출력 (Obsolete tool outputs)
오래된 검색 청크 (Old retrieval chunks)
해결된 워크플로 상태 (Resolved workflow state)
반복되는 사용자의 명확화 요청 (User clarifications)

모델은 여전히 사용 가능한 응답을 생성했습니다.

하지만 일관성(Consistency)은 떨어졌습니다.

관련 없는 기록이 컨텍스트 파이프라인(Context pipeline)에 계속 유입되면서 추론의 집중도가 낮아졌습니다.

토큰 증가량은 청구 금액이 폭발하기 전까지는 보이지 않는다

이 문제는 개발 단계에서는 잘 숨겨져 있습니다.

소규모 내부 테스트에서는 거의 드러나지 않습니다.

하지만 프로덕션 시스템에서는 드러납니다.

특히 다음과 같은 경우에 그렇습니다:

대화가 몇 주 동안 활성 상태로 유지됨
사용자가 오래된 스레드를 다시 염
에이전트(Agents)가 영구적인 메모리(Persistent memory)를 유지함
검색 레이어(Retrieval layers)가 추가적인 컨텍스트(Context)를 주입함
도구(Tool) 출력값이 지속적으로 누적됨

한 엔터프라이즈 워크플로우(Enterprise workflow)는 운영 몇 달 만에 토큰(Tokens) 소비량이 몇 배로 늘어났습니다.

제품 자체에는 큰 변화가 없었습니다.

문제는 조용한 컨텍스트(Context) 누적이었습니다.

출력이 여전히 올바르게 보였기 때문에 처음에는 아무도 눈치채지 못했습니다.

토큰 관측성(Token observability)이 없었다면, 이 문제는 인지하지 못한 채 계속 커졌을 것입니다.

우리는 모든 메모리를 동일하게 취급하는 것을 중단했습니다

이로 인해 우리의 아키텍처(Architecture)는 크게 변화했습니다.

모든 대화 기록이 활성 컨텍스트(Active context)에 영구적으로 존재할 가치가 있는 것은 아닙니다.

우리는 메모리를 카테고리별로 나누기 시작했습니다.

단기 메모리 (Short-Lived Memory)

활발한 추론(Reasoning) 중에만 유용합니다.

예시:

일시적인 도구(Tool) 출력값
중간 실행 상태 (Intermediate execution state)
짧은 워크플로우 컨텍스트 (Short workflow context)

이것들은 빠르게 만료됩니다.

운영 메모리 (Operational Memory)

디버깅(Debugging)과 인프라 신뢰성을 위해 필요합니다.

예시:

재시도 (Retries)
실행 트레이스 (Execution traces)
감사 로그 (Audit logs)
배포 메타데이터 (Deployment metadata)

추론 파이프라인(Reasoning pipelines)과는 별도로 저장됩니다.

영구 사용자 메모리 (Persistent User Memory)

세션 전반에 걸쳐 실제로 유용합니다.

예시:

선호도 (Preferences)
안정적인 비즈니스 규칙 (Stable business rules)
장기 워크플로우 상태 (Long-term workflow state)

이 레이어는 더 작고 의도적인 상태를 유지합니다.

이러한 분리를 통해 프롬프트(Prompt)의 증가를 크게 줄였습니다.

더 중요한 것은, 추론의 일관성(Reasoning consistency)을 개선했다는 점입니다.

검색 시스템이 이를 악화시킵니다

검색 파이프라인(Retrieval pipelines)은 이 문제를 증폭시킵니다.

과거의 대화가 거대하게 남아 있으면, 검색 시스템은 중복된 정보를 반복해서 노출하기 시작합니다.

이는 다음과 같은 현상을 초래합니다:

중첩되는 컨텍스트 (Overlapping context)
중복된 추론 경로 (Duplicated reasoning paths)
반복되는 설명 (Repeated explanations)
부풀려진 프롬프트 (Inflated prompts)

모델은 이미 이전에 처리했던 정보를 처리하는 데 토큰을 소비하게 됩니다.

우리는 다음과 같은 기능을 추가했습니다:

검색 중복 제거 (Retrieval deduplication)
의미론적 압축 (Semantic compression)
메모리 노후화 규칙 (Memory aging rules)
컨텍스트 우선순위 레이어 (Context prioritization layers)

이를 통해 토큰 사용량과 추론 노이즈(Reasoning noise)를 모두 줄였습니다.

인프라의 교훈

AI 메모리는 단순한 저장(Storage)의 문제가 아닙니다.

그것은 시스템 설계(Systems design)의 문제입니다.

모든 것을 영구적으로 보관하는 것은 안전하게 들립니다.

하지만 현실에서는 다음과 같은 문제를 야기합니다:

운영 드리프트 (Operational drift)
추론 비용 (Inference costs) 상승
추론 일관성 (Reasoning inconsistency) 결여
실행 속도 저하
디버깅의 어려움
인프라 불안정성

전통적인 시스템들은 통제되지 않은 상태(State)의 성장이 결국 기술 부채(Technical debt)가 된다는 사실을 오래전에 학습했습니다.

AI 시스템들도 이제 동일한 교훈을 배우고 있습니다.

과제는 메모리를 영구적으로 만드는 것이 아닙니다.

과제는 무엇이 살아남을 가치가 있는지 결정하는 것입니다.