[AI] 스테이트풀(Stateful) AI 서비스: 대화 문맥(Context) 관리의 최적화 방식

대화형 서비스를 만들다 보면 문맥을 얼마나 오래, 어떤 형태로, 어디까지 보존할지부터 정해야 합니다. 스테이트풀(Stateful) 방식은 단순히 이전 대화를 저장하는 개념이 아니라, 현재 턴에 필요한 문맥만 정확하게 꺼내 쓰도록 설계하는 문제에 가깝습니다. 스테이트풀 서비스에서 대화 문맥(Context)을 어떻게 관리하면 좋은지 정리해보겠습니다. 

스테이트풀(Stateful) 서비스에서 대화 문맥 관리가 중요한 이유

스테이트풀 서비스의 핵심은 이전 상호작용을 다음 응답에 반영할 수 있다는 점입니다. 다만 여기서 자주 생기는 오해가 하나 있습니다. 문맥을 많이 넣으면 더 똑똑해질 것 같지만, 실제로는 무조건 긴 문맥이 정답이 아닙니다. Anthropic의 Messages API는 기본적으로 상태 비저장 방식이라 이전 대화를 계속 보내야 하고, OpenAI의 Responses API는 이전 응답을 이어 쓰는 방식으로 대화 상태를 구성할 수 있습니다. 즉, 서비스가 상태를 가지는지 여부는 모델 자체보다 애플리케이션 계층에서 어떻게 문맥을 저장하고 이어 붙이느냐 라고 보시면 됩니다. 

또 하나 중요한 점은 긴 문맥이 항상 품질을 보장하지 않는다는 사실입니다. 장문 입력을 다룰 수 있는 모델이라도, 핵심 정보가 입력 중간에 묻히면 성능이 떨어질 수 있다는 결과가 이미 알려져 있습니다. 이른바 Lost in the Middle 문제인데, 관련 연구에서는 중요한 정보가 문맥의 앞이나 뒤에 있을 때보다 중간에 있을 때 성능이 유의미하게 낮아질 수 있다고 설명합니다. 그래서 스테이트풀 서비스는 단순 저장보다 문맥 압축과 재배치가 더 중요합니다.

대화 문맥은 세 가지로 나눠서 관리하는 편이 좋습니다

실무에서는 모든 대화 데이터를 한 덩어리로 다루기보다 성격별로 분리하는 편이 훨씬 낫습니다. 저는 보통 문맥을 세션 문맥, 사용자 기억, 외부 지식 참조로 나눠서 봅니다. 이 구분이 있어야 어떤 데이터는 바로 프롬프트에 넣고, 어떤 데이터는 데이터베이스에만 남기고, 어떤 데이터는 검색해서 붙여야 할지 판단이 쉬워집니다.

1. 세션 문맥

현재 대화 흐름을 유지하는 데 필요한 최근 메시지 묶음입니다. 방금 어떤 질문이 오갔는지, 직전에 어떤 도구를 호출했는지, 지금 답변이 어느 작업의 연장선인지 같은 정보가 여기에 들어갑니다. 이 레이어는 thread_id나 conversation_id 단위로 관리하는 경우가 많고, LangChain 계열 문서도 스레드 범위의 단기 기억과 세션 간 장기 기억을 구분해서 설명합니다.

2. 사용자 기억

사용자의 선호, 금지사항, 자주 쓰는 표현, 자주 요청하는 포맷처럼 세션을 넘어 재사용할 정보입니다. 이 데이터는 전체 대화를 그대로 저장하는 방식보다, 검증된 사실만 구조화해서 저장하는 편이 유지보수에 유리합니다. 예를 들어 선호 언어, 말투, 출력 형식, 관심 주제 정도는 키-값 또는 프로필 테이블 형태가 더 읽기 쉽습니다.

3. 외부 지식 참조

상품 정보, 정책 문서, 사내 위키, 매뉴얼처럼 대화 중간에 필요할 때만 꺼내야 하는 정보입니다. 이런 데이터까지 매 요청마다 통째로 붙이면 프롬프트가 빠르게 비대해집니다. RAG는 이런 문제를 줄이기 위한 전형적인 방법으로, 필요한 시점에 관련 자료를 검색해 문맥에 넣는 구조입니다. Anthropic 문서도 RAG를 외부 지식을 런타임에 검색해 답변의 정확성과 근거성을 높이는 방식으로 설명하고 있습니다. 

 

스테이트풀 문맥 관리의 최적화 방식

최적화라는 말을 성능 튜닝처럼만 볼 필요는 없습니다. 여기서는 정확도, 유지보수성, 응답 일관성, 토큰 사용량의 균형을 맞추는 것이 더 중요합니다. 실무에서 자주 쓰는 방식은 크게 다섯 가지입니다.

최근 대화만 유지하고 오래된 내용은 요약으로 치환하기

가장 기본적이면서 효과가 큰 방식입니다. 최근 N턴은 원문으로 유지하고, 그 이전 내용은 요약본으로 압축합니다. 이렇게 하면 직전 문맥의 정확도는 지키면서 전체 세션의 흐름도 잃지 않을 수 있습니다. 긴 대화 전체를 계속 넣으면 모델이 오래된 주변 정보에 끌려갈 수 있기 때문에, 오래된 메시지를 요약하거나 제거하는 전략이 실제로 많이 사용됩니다.

중요 사실만 구조화해서 별도 저장하기

대화 전체를 기억하려고 하면 오히려 필요한 사실을 다시 찾기 어려워집니다. 예를 들어 사용자가 “앞으로는 표보다 문단 설명을 선호한다”라고 말했다면, 이 문장 원문을 계속 들고 다니기보다 preference 테이블이나 memory store에 정규화해서 넣는 편이 낫습니다. 이렇게 해야 세션을 넘어도 안정적으로 재사용할 수 있고, 잘못된 요약이 누적되는 문제도 줄일 수 있습니다.

필요한 지식만 검색해서 붙이는 RAG 계층 두기

정책 문서나 매뉴얼처럼 크고 자주 바뀌는 정보는 세션 상태에 직접 넣지 않는 편이 좋습니다. 대신 현재 질문과 관련 있는 문서 조각만 검색해서 붙입니다. Anthropic 문서도 대규모 정적·동적 문맥을 모두 프롬프트에 넣는 것은 비용과 지연, 컨텍스트 한계 문제를 만들 수 있으므로 RAG가 더 확장 가능한 방식이 될 수 있다고 설명합니다.

프롬프트 캐싱으로 반복 문맥 재사용하기

시스템 프롬프트, 도구 설명, 긴 정책 문서처럼 반복해서 들어가는 접두 문맥은 캐싱 대상입니다. Anthropic은 프롬프트 캐싱이 같은 시스템 프롬프트, 문서, 대화 이력 일부를 반복 처리하지 않도록 해서 비용과 지연을 줄여준다고 설명하고 있습니다. Google Gemini도 explicit caching과 implicit caching을 제공하며, 반복 입력을 다시 보내지 않거나 더 낮은 비용으로 처리할 수 있도록 안내합니다. OpenAI 역시 prompt cache 관련 설정을 공식 문서에서 제공하고 있습니다. 스테이트풀 서비스에서는 이 기능이 있으면 “기억” 자체를 줄이는 것이 아니라, 반복되는 공통 문맥의 처리 비용을 줄이는 방향으로 활용하는 편이 좋습니다. 

문맥 우선순위를 다시 배치하기

긴 대화에서 중요한 사실을 어디에 놓느냐도 결과에 영향을 줍니다. 그래서 최근 사용자 요청, 시스템 제약, 현재 작업 목표, 검색된 근거, 과거 요약 순서처럼 레이어를 나눠 재배치하는 편이 낫습니다. 단순히 시간순으로 붙이는 것보다, 이번 응답에 직접 영향을 주는 정보가 앞부분에 오도록 정렬하는 방식이 더 안정적입니다. 

 

실무에서는 어떤 구조로 설계하는가

설계는 복잡하게 시작할 필요가 없습니다. 다만 저장 계층을 처음부터 나눠두는 편이 이후 수정이 훨씬 쉽습니다. 아래처럼 구성하면 대부분의 대화형 서비스에서 무난하게 확장할 수 있습니다.

[Client]
   ↓
[Conversation API]
   ├─ Session Store
   │   └─ 최근 대화, 요약본, tool 결과
   ├─ Memory Store
   │   └─ 사용자 선호, 장기 속성, 금지 규칙
   ├─ Retrieval Layer
   │   └─ 문서 검색, 정책 조회, 지식 조각 반환
   └─ Prompt Builder
       ├─ system 규칙
       ├─ 현재 사용자 입력
       ├─ 최근 대화
       ├─ 요약 문맥
       ├─ 사용자 기억
       └─ 검색 근거
            ↓
         [Model]

여기서 핵심은 Prompt Builder가 모든 저장소를 그대로 붙이지 않는다는 점입니다. 현재 턴에 필요한 것만 선택적으로 조합해야 합니다. OpenAI Responses API처럼 이전 응답을 이어서 상태를 구성하는 방식이든, Anthropic Messages API처럼 전체 대화 이력을 다시 보내는 방식이든, 결국 애플리케이션이 어떤 정보를 넣을지 결정해야 한다는 점은 같습니다. 

 

자주 헷갈리는 포인트

스테이트풀은 모든 대화를 영구 보관하는 구조가 아닙니다

상태를 가진다는 말과 무한히 기억한다는 말은 다릅니다. 서비스 목적에 맞는 단위로 문맥을 남기고, 나머지는 버리거나 요약해야 합니다. 특히 오래된 메시지를 계속 원문으로 유지하면 품질이 좋아지기보다 오히려 현재 질문의 초점이 흐려질 수 있습니다. 

요약은 편하지만 원문 대체재는 아닙니다

요약은 토큰 절약에 유리하지만, 잘못 요약되면 이후 모든 응답이 그 왜곡을 따라갑니다. 그래서 사실성에 민감한 도메인에서는 요약본만 두지 말고, 필요 시 원문 로그나 검색 가능한 원본 저장소를 함께 두는 편이 안전합니다.

프롬프트 캐싱과 장기 기억은 다른 문제입니다

프롬프트 캐싱은 반복 입력의 처리 비용을 줄이는 기능이지, 사용자 성향을 장기간 기억하는 저장소가 아닙니다. 반대로 장기 기억 저장소는 캐시가 아니라 명시적 데이터 계층입니다. 이 둘을 섞어서 생각하면 설계가 금방 꼬입니다.

 

어떤 방식이 가장 적절한가

대부분의 서비스에서 정답은 하나가 아니라 조합입니다. 최근 대화 몇 턴은 원문 유지, 오래된 대화는 요약, 사용자 선호는 구조화 저장, 외부 지식은 RAG, 반복 시스템 문맥은 캐싱으로 가져가는 조합이 가장 무난합니다. 긴 컨텍스트를 지원하는 모델이 늘고 있지만, 공식 문서들 역시 긴 입력 자체와 함께 캐싱, 상태 관리, 검색 계층 같은 보조 전략을 계속 제공하고 있습니다. 결국 좋은 스테이트풀 설계는 많이 기억하는 구조가 아니라, 지금 필요한 문맥을 가장 정확하게 불러오는 구조라고 보는 편이 맞습니다.

 

마무리

스테이트풀(Stateful) 서비스의 대화 문맥 관리는 단순 저장 문제가 아닙니다. 무엇을 세션에 남기고, 무엇을 장기 기억으로 승격하고, 무엇을 검색으로 대체할지 구분하는 설계 문제입니다. 처음부터 모든 것을 기억하는 구조로 가기보다, 최근 문맥 유지와 요약, 구조화 기억, 검색 보강, 프롬프트 캐싱을 분리해 두면 훨씬 다루기 쉬워집니다. 문맥 관리가 정리되면 응답 품질뿐 아니라 시스템 설명 가능성, 팀 협업, 이후 기능 확장까지 함께 좋아집니다.