AI 시스템에 더 큰 컨텍스트 윈도우(Context Window)보다 상태 관리(State Management)가 더 필요한 이유

더 큰 컨텍스트 윈도우(Context Window)를 가진 새로운 모델이 출시될 때마다, 항상 똑같은 대화가 반복됩니다.

이제 우리는 단일 요청(Request)에 더 많은 정보를 담을 수 있습니다.

더 많은 문서.

더 많은 대화 기록.

더 많은 워크플로(Workflow) 데이터.

더 많은 메모리.

가정은 단순합니다:

더 큰 컨텍스트 윈도우(Context Window)가 대부분의 AI 시스템 한계를 해결할 것이라는 점입니다.

하지만 실제 운영 환경(Production)에서 AI 시스템을 운영해 본 결과, 우리는 다른 것을 배웠습니다.

컨텍스트 윈도우(Context Window)도 도움이 됩니다.

하지만 상태 관리(State Management)가 더 중요합니다.

첫 번째 해결책은 보통 더 많은 컨텍스트(Context)를 넣는 것입니다

AI 시스템이 일관되지 않은 결과를 내놓기 시작할 때, 가장 먼저 나오는 반응은 종종 더 많은 정보를 추가하는 것입니다.

그 논리는 합리적으로 들립니다.

아마도 모델에게 다음과 같은 것들이 더 필요할지도 모릅니다:

• 더 많은 대화 기록
• 더 많은 검색(Retrieval) 결과
• 더 많은 워크플로(Workflow) 상태
• 더 많은 도구(Tool) 출력값
• 더 많은 비즈니스 컨텍스트(Business Context)

그래서 프롬프트(Prompt)가 커집니다.

그러다 또 커집니다.

결국 시스템은 모든 요청(Request)에 엄청난 양의 정보를 실어 나르기 시작합니다.

문제는 더 많은 정보가 자동으로 더 나은 결정을 만들어내지는 않는다는 것입니다.

때로는 정반대의 결과를 초래하기도 합니다.

컨텍스트(Context)의 성장은 숨겨진 문제들을 만들어냅니다

거대한 컨텍스트 윈도우(Context Window)는 아키텍처(Architecture)의 약점을 숨길 수 있습니다.

어떤 정보가 중요한지 결정하는 대신, 시스템은 단순히 모든 것을 포함해 버립니다.

초기에는 그렇게 작동합니다.

하지만 시간이 지나면서 몇 가지 문제들이 나타납니다:

• 토큰(Token) 비용 증가
• 지연 시간(Latency) 증가
• 추론(Reasoning)의 일관성 결여
• 검색 노이즈(Retrieval Noise) 증가
• 디버깅(Debugging)의 어려움
• 메모리 오염(Memory Pollution) 누적

시스템은 기술적으로 더 많은 정보를 가지고 있습니다.

하지만 모델은 종종 명확성(Clarity)을 잃습니다.

우리는 아주 적은 부분만이 관련이 있음에도 불구하고 몇 달 치의 과거 상태(Historical State)를 그대로 들고 다니는 워크플로(Workflow)를 목격하기 시작했습니다.

모델은 더 이상 중요하지 않은 정보를 처리하는 데 자원을 낭비하고 있었습니다.

상태(State)와 컨텍스트(Context)는 서로 다른 것입니다

이러한 구분은 규모(Scale)가 커질수록 중요해집니다.

컨텍스트(Context)는 요청(Request) 중에 사용할 수 있는 정보입니다.

상태(State)는 시스템이 시간이 흐름에 따라 알고 있는 정보입니다.

많은 AI 아키텍처(Architectures)는 이 둘을 동일한 것으로 취급합니다.

하지만 그렇지 않습니다.

예를 들어:

고객 프로필은 상태(State)입니다.

대화 요약은 상태(State)입니다.

워크플로우(Workflow) 진행 상황은 상태(State)입니다.

권한(Permissions)은 상태(State)입니다.

비즈니스 규칙(Business rules)은 상태(State)입니다.

이 중 어느 것도 반드시 모든 프롬프트(Prompt) 내에 나타날 필요는 없습니다.

그럼에도 불구하고 많은 시스템은 적절한 상태 관리(State management)가 부족하기 때문에 이들을 컨텍스트(Context)에 지속적으로 주입합니다.

그 결과 프롬프트는 더 커지고 워크플로우는 덜 효율적이게 됩니다.

전통적인 소프트웨어는 수년 전에 이 문제를 해결했습니다

분산 시스템(Distributed systems)은 모든 정보를 모든 곳에 전달함으로써 복잡성을 해결하는 경우가 거의 없습니다.

그들은 상태(State)를 별도로 관리합니다.

데이터베이스(Databases)는 상태를 저장합니다.

캐시(Caches)는 상태를 저장합니다.

큐(Queues)는 상태를 저장합니다.

서비스(Services)는 필요할 때 상태에 접근합니다.

AI 시스템은 종종 이러한 규율을 건너뜁니다.

대신, 컨텍스트 윈도우(Context window)를 임시 데이터베이스처럼 취급합니다.

이는 빠르게 운영상의 문제를 야기합니다.

컨텍스트 윈도우는 추론(Reasoning)에 유용합니다.

하지만 구조화된 상태 관리(Structured state management)를 대체할 수는 없습니다.

더 큰 컨텍스트 윈도우는 나쁜 습관을 조장합니다

더 큰 컨텍스트 윈도우가 가져오는 의도치 않은 결과 중 하나는 아키텍처 측면의 나태함입니다.

팀들이 다음과 같이 묻는 대신:

"어떤 정보가 필요한가?"

다음과 같이 묻습니다:

"모든 것을 다 넣을 수 있는가?"

이 질문들은 매우 다른 시스템을 만들어냅니다.

첫 번째 질문은 의도적인 아키텍처(Intentional architecture)를 만들어냅니다.

두 번째 질문은 종종 비용이 많이 드는 아키텍처(Expensive architecture)를 만들어냅니다.

모든 워크플로우가 모든 정보를 받게 되면, 시스템은 운영하기 더 어려워지고 이해하기도 더 어려워집니다.

용량이 커진다고 해서 설계 결정(Design decisions)의 필요성이 사라지는 것은 아닙니다.

컨텍스트 확장보다 상태 관리가 더 큰 개선을 가져왔습니다

우리가 목격한 가장 큰 개선 중 일부는 컨텍스트 크기를 늘리는 것이 아니라 상태 관리를 개선하는 데서 왔습니다.

예를 들면 다음과 같습니다:

• 운영 상태(Operational state)와 추론 상태(Reasoning state)의 분리
• 프롬프트 외부로 워크플로우 진행 상황 저장
• 메모리 만료 규칙(Memory expiration rules) 도입
• 구조화된 지식 계층(Structured knowledge layers) 생성
• 중복된 컨텍스트 감소

그 결과는 종종 다음과 같았습니다:

• 더 낮은 비용 (lower costs)
• 더 빠른 실행 (faster execution)
• 더 깔끔한 추론 (cleaner reasoning)
• 더 쉬운 디버깅 (easier debugging)
• 더 예측 가능한 동작 (more predictable behavior)

이러한 개선 사항 중 그 어느 것도 더 큰 모델을 필요로 하지 않았습니다.

그것들은 더 나은 아키텍처 (architecture)를 필요로 했습니다.

프로덕션 시스템에는 제어된 메모리 (Controlled Memory)가 필요합니다

AI 시스템의 과제 중 하나는 무엇이 영속성 (persistence)을 가질 가치가 있는지 결정하는 것입니다.

모든 것이 영구 메모리 (permanent memory)가 되어서는 안 됩니다.

모든 것이 모든 프롬프트 (prompt)에 포함되어서도 안 됩니다.

훌륭한 상태 관리 (state management)는 경계 (boundaries)를 생성합니다.

질문은 다음과 같이 변합니다:

• 무엇을 기억해야 하는가?
• 얼마나 오래 유지해야 하는가?
• 이 정보의 소유권은 누구에게 있는가?
• 언제 만료되어야 하는가?
• 언제 컨텍스트 (context)에 진입해야 하는가?

이러한 결정은 대부분의 사람들이 예상하는 것보다 더 중요합니다.

이러한 결정이 없다면, 시스템은 운영 부채 (operational debt)를 빠르게 축적하게 됩니다.

더 큰 교훈

더 큰 컨텍스트 윈도우 (context windows)는 유용합니다.

그것들은 실제 문제들을 해결합니다.

하지만 그것들은 종종 실제로는 아키텍처적인 문제인 사안들에 대한 해결책으로 취급되곤 합니다.

많은 프로덕션 AI 시스템들이 어려움을 겪는 이유는 컨텍스트 용량 (context capacity)이 부족해서가 아니라, 구조화된 상태 관리 (structured state management)가 부족하기 때문입니다.

목표는 모델에게 모든 것에 대한 접근 권한을 주는 것이 아닙니다.

목표는 모델에게 적절한 시점에 적절한 것에 대한 접근 권한을 주는 것입니다.

그것은 상태 관리 (state management)의 문제입니다.

그리고 엔터프라이즈 AI 인프라 (enterprise AI infrastructure)에서, 상태 관리는 보통 컨텍스트 100만 토큰을 추가하는 것보다 훨씬 더 중요합니다.