LLM의 상태 구조: 명시적 상태, 암묵적 상태, 컨텍스트, 에이전트 런타임

핵심 요약

Transformer 기반 LLM 본체는 일반적인 서비스 대화나 작업 상태를 모델 내부의 명시적·영속적 변수로 계속 보존하는 시스템이 아니다. 단일 LLM 호출을 수학적으로 추상화하면, 고정된 가중치와 입력 컨텍스트를 바탕으로 다음 토큰 확률분포를 계산하는 함수에 가깝다. 이때 사용자의 이전 발화, 시스템 지시, 검색된 문서, 도구 결과, 메모리 기록은 모델 내부 상태라기보다 모델에 다시 제공되는 입력 컨텍스트에 속한다.

이 설명은 “LLM 내부에는 상태가 전혀 없다”는 뜻이 아니다. Transformer의 forward pass 안에서는 토큰 표현이 레이어를 지나며 계속 갱신되고, attention head와 MLP가 residual stream을 읽고 쓰면서 문맥 정보와 중간 계산 결과를 activation 형태로 구성한다. KV cache도 autoregressive generation 과정에서 이전 토큰의 key-value tensor를 저장해 재계산을 줄인다. 이들은 모두 일시적 계산 상태로 볼 수 있지만, 요청이 끝난 뒤 유지되는 의미론적 장기 기억이나 에이전트의 작업 상태와는 구분된다.

현대 AI 에이전트 시스템은 이 차이를 전제로 설계된다. LLM은 언어적 추론과 생성의 엔진으로 쓰이고, 에이전트 런타임의 상태 관리 계층은 목표, 계획, 대화 이력, 장기 기억, 도구 결과, 체크포인트를 명시적으로 저장하고 갱신한다. 여기서 State Manager라는 표현은 특정 프레임워크의 고유 명칭이 아니라, 에이전트 런타임에서 상태 저장·갱신·검색·복구를 담당하는 설계 계층을 가리키는 설명적 용어다.

문제의식

LLM을 설명할 때 “기억한다”, “상태를 가진다”, “문맥을 유지한다”는 표현이 자주 쓰인다. 이 표현들은 사용자 경험 차원에서는 자연스럽지만, 아키텍처 차원에서는 서로 다른 층위를 섞을 위험이 있다. ChatGPT 같은 대화형 서비스가 이전 대화를 반영한다고 해서, Transformer 모델 본체가 사용자별 대화 상태를 내부 변수로 영속 저장한다고 결론 내릴 수는 없다. 반대로 모델 내부 activation과 KV cache가 존재한다고 해서, LLM이 데이터베이스나 작업 관리 시스템처럼 안정적인 상태 관리 능력을 가진다고 보기도 어렵다.

이 구분은 단순한 용어 문제가 아니다. 퍼즐 풀이, 긴 문서 작성, 장기 계획, 도구 사용, 소프트웨어 에이전트, 연구 자동화처럼 상태 정확도가 중요한 과제에서는 “언어적으로 그럴듯한 다음 출력”만으로 충분하지 않다. 현재 상태가 무엇인지, 어떤 조건이 이미 만족되었는지, 어떤 선택지가 배제되었는지, 어떤 도구 호출이 실패했는지, 어느 시점으로 복구해야 하는지를 명시적으로 관리해야 한다. 따라서 LLM의 상태 구조를 이해하려면 모델 본체, 추론 과정, 입력 컨텍스트, 외부 메모리, 에이전트 런타임을 분리해서 보아야 한다.

개념의 정의

상태(state)는 시스템이 다음 계산이나 행동을 결정할 때 참조하는 현재 조건의 표현이다. 이 정의는 넓기 때문에, LLM 논의에서는 최소한 네 가지 층위를 구분해야 한다.

첫째, 명시적 상태(explicit state)는 개발자가 직접 정의하고 갱신하는 상태다. 프로그램 변수, JSON 객체, 데이터베이스 레코드, 그래프 상태, 체크포인트, 파일 기록, 작업 큐가 여기에 속한다. 예를 들어 에이전트가 goal, plan, tool_results, memory, current_step 같은 필드를 가진 객체를 유지한다면 이것은 명시적 상태다.

둘째, 암묵적 상태(implicit state)는 모델 내부 계산 중 activation으로 나타나는 고차원 표현이다. Transformer의 hidden states, attention pattern, residual stream에 누적된 표현이 여기에 속한다. 이 상태는 사람이 직접 이름 붙인 변수로 저장되는 것이 아니지만, 다음 토큰 확률분포에 영향을 준다.

셋째, 영속 상태(persistent state)는 한 요청이나 한 실행이 끝난 뒤에도 남아 다음 요청에 영향을 줄 수 있는 상태다. 사용자 메모리, 대화 로그, 장기 데이터베이스, 벡터 저장소, 에이전트 체크포인트, 파일 시스템 기록이 이에 해당한다.

넷째, 일시 상태(transient state)는 한 번의 forward pass 또는 한 번의 생성 과정 안에서만 유지되는 상태다. 레이어별 activation, attention weights, KV cache가 대표적이다. 이들은 현재 계산에는 중요하지만, 별도 저장·재삽입 절차가 없으면 다음 세션의 의미 기억이 되지 않는다.

이 구분을 적용하면 핵심 명제가 선명해진다. Transformer 기반 LLM 본체는 서비스 대화 상태를 모델 내부의 명시적·영속적 변수로 보존하지 않는다. 동시에 forward pass 내부에서는 암묵적·일시적 계산 상태를 형성한다. 에이전트 시스템은 LLM 바깥에 명시적·영속적 상태 관리 계층을 추가함으로써 장기 작업과 도구 사용을 가능하게 한다.

배경과 맥락

RNN의 명시적 시간 상태와 Transformer의 병렬적 문맥 처리

전통적인 RNN 계열 모델은 입력을 순서대로 처리하면서 hidden state를 갱신한다. 단순화하면 다음과 같이 쓸 수 있다.

h_t = f(h_{t-1}, x_t)

여기서 h_t는 시점 t의 hidden state이고, x_t는 현재 입력이다. 이 구조에서는 이전 시점의 계산 결과가 다음 시점 계산에 직접 들어간다. 그래서 RNN은 구조적으로 시간 방향의 상태 갱신을 가진다.

Transformer는 다른 접근을 취한다. Vaswani 등은 「Attention Is All You Need」에서 recurrence와 convolution을 제거하고 attention mechanism에 기반한 Transformer 구조를 제안했다. Transformer의 핵심은 각 토큰이 self-attention을 통해 같은 입력 시퀀스 안의 다른 토큰 정보를 참조할 수 있다는 점이다. 이 방식은 하나의 hidden state에 과거 전체를 순차적으로 압축하는 방식보다 병렬화에 유리하며, 입력 시퀀스 내부의 여러 위치 사이 관계를 직접 계산할 수 있게 한다.

scaled dot-product attention은 보통 다음 식으로 요약된다.

\mathrm{Attention}(Q, K, V)
= \mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V

Q, K, V는 각각 query, key, value 행렬이다. 각 토큰 위치는 query를 통해 다른 위치의 key와 관련도를 계산하고, 그 결과로 value들을 가중합한다. 이 구조 때문에 Transformer는 RNN처럼 단일 hidden state를 시간순으로 넘기는 방식에 의존하지 않는다.

Decoder-only LLM과 causal mask

GPT 계열처럼 다음 토큰을 생성하는 decoder-only Transformer는 causal mask를 사용한다. t번째 위치는 미래 토큰을 볼 수 없고, 현재까지의 prefix만 참조한다. 따라서 훈련에서는 여러 위치의 next-token prediction을 병렬적으로 계산할 수 있지만, 실제 autoregressive generation에서는 생성된 토큰이 다음 입력 prefix가 되므로 출력은 한 토큰씩 순차적으로 만들어진다.

이 지점에서 혼동이 생긴다. 생성은 순차적으로 일어나지만, 그 순차성은 RNN의 hidden state recurrence와 같은 구조가 아니다. 모델은 매 단계 현재까지의 prefix와 고정된 가중치를 바탕으로 다음 토큰 확률분포를 계산한다. 추론 서버는 효율을 위해 KV cache를 사용하지만, 이것은 과거 의미를 요약한 장기 상태라기보다 이미 계산된 attention 재료를 재사용하는 계산 캐시다.

컨텍스트 창과 실제 대화 상태

대화형 서비스에서 사용자가 체감하는 “상태”는 보통 입력 컨텍스트 구성 정책에서 나온다. 시스템은 새 요청이 들어올 때 system instruction, developer instruction, 이전 대화 일부, 검색된 문서, 저장된 메모리, 도구 결과, 현재 사용자 메시지를 합쳐 모델에 전달한다. 모델이 직접 참조하는 즉시 상태는 이 입력 컨텍스트다.

대화 이력이 항상 원문 그대로 무한히 제공되는 것은 아니다. 컨텍스트 창에는 길이 제한이 있으므로 오래된 메시지는 잘리거나 요약되거나, 별도 메모리 검색 결과로 대체될 수 있다. 따라서 “대화 상태는 프롬프트 이력에 있다”는 설명도 실제 시스템에서는 컨텍스트 구성 정책에 의존한다. 어떤 정보가 입력에 들어갔는지, 어떤 정보가 요약되었는지, 어떤 정보가 검색에서 누락되었는지에 따라 모델의 응답은 달라진다.

핵심 논리

1. 단일 LLM 호출은 함수형 추상화로 설명할 수 있다

단일 LLM 호출을 수학적으로 단순화하면 다음과 같은 함수로 볼 수 있다.

P(x_{t+1} \mid x_{\leq t}; \theta)

여기서 x_{\leq t}는 현재까지의 입력 토큰열이고, \theta는 학습된 모델 가중치다. 일반적인 추론 시점에서 \theta는 고정되어 있고, 입력 컨텍스트가 달라지면 다음 토큰 확률분포가 달라진다. 이 관점에서 LLM은 “고정된 가중치와 현재 입력을 바탕으로 다음 토큰 분포를 산출하는 함수”에 가깝다.

이 표현은 설명용 추상화다. 실제 서비스에서는 sampling, temperature, top-p, beam search 같은 디코딩 전략, KV cache, batching, tool wrapper, safety filter, prompt assembly, retrieval pipeline이 함께 작동한다. 따라서 LLM이 현실 구현에서 완전히 순수한 stateless function이라고 말하는 것은 과도하다. 더 엄밀한 표현은 다음이다. 단일 LLM 호출을 수학적으로 추상화하면, 고정된 가중치와 입력 컨텍스트를 바탕으로 다음 토큰 확률분포를 계산하는 함수에 가깝다.

2. 모델 가중치는 장기 구조지만 대화 상태와는 다르다

LLM에는 학습된 가중치라는 장기 구조가 있다. 이 가중치에는 언어 패턴, 사실적 연관, 추론 양식, 문체, 코딩 관습 등 학습 과정에서 형성된 통계적 구조가 반영된다. 넓은 의미에서 가중치도 모델의 장기 상태라고 부를 수 있다.

그러나 여기서 논의하는 “대화 상태”나 “작업 상태”는 가중치와 다르다. 사용자가 지금 어떤 작업을 하고 있는지, 이전 단계에서 어떤 도구가 실패했는지, 어떤 후보가 배제되었는지, 사용자가 어떤 파일을 방금 업로드했는지는 일반적으로 모델 가중치에 즉시 기록되지 않는다. 서비스가 이 정보를 반영하려면 대화 이력, 메모리 저장소, 파일 내용, 도구 결과를 입력 컨텍스트로 다시 제공해야 한다.

이 구분은 “대화형 AI가 기억하면 모델이 학습한 것이다”라는 오해를 막는다. 일반적인 서비스 사용에서 매 대화마다 모델 가중치가 실시간으로 업데이트되는 것은 아니다. 기억처럼 보이는 효과는 대개 컨텍스트 재삽입, 외부 메모리 검색, 세션 상태 관리에서 나온다.

3. Transformer 내부에는 forward pass 안의 암묵적 상태가 있다

Transformer가 명시적·영속적 대화 상태를 유지하지 않는다는 말은 내부 계산이 상태적 성격을 전혀 갖지 않는다는 뜻이 아니다. 입력 토큰은 embedding으로 변환된 뒤 여러 레이어를 통과하며 계속 갱신된다. 단순화하면 다음과 같이 표현할 수 있다.

h^{(l+1)} \approx h^{(l)} + \mathrm{Attention}(h^{(l)}) + \mathrm{MLP}(h^{(l)})

실제 구현에는 layer normalization, attention block과 MLP block의 분리, pre-norm 또는 post-norm 차이, 모델별 세부 구조가 있다. 위 식은 정확한 구현식을 제시하려는 것이 아니라, residual connection을 통해 이전 레이어 표현에 새 계산 결과가 더해진다는 구조적 직관을 보여주는 압축 표현이다.

Anthropic의 Transformer Circuits 연구에서 쓰이는 residual stream 개념은 이 구조를 이해하는 데 유용하다. residual stream은 여러 attention head와 MLP layer가 읽고 쓰는 중심적 벡터 흐름으로 분석된다. 각 구성요소는 residual stream에서 정보를 읽고, 변환 결과를 다시 residual stream에 더한다. 이 관점에서는 residual stream이 forward pass 내부의 임시 작업 공간처럼 작동한다고 말할 수 있다.

중요한 점은 이 “작업 공간”이 명시적 메모리 변수가 아니라는 것이다. residual stream은 사람이 읽는 노트, 데이터베이스, RAM 객체와 같은 자료구조가 아니다. 그것은 고차원 벡터 activation이며, 다음 토큰 예측에 필요한 정보를 분산적으로 담는다. 따라서 “암묵적 상태”라는 표현은 분석을 돕는 설명적 개념이지, 모델 내부에 state.memory 같은 필드가 있다는 뜻이 아니다.

4. KV cache는 계산 상태지만 의미론적 장기 기억은 아니다

KV cache는 LLM 추론에서 가장 자주 오해되는 상태적 요소다. autoregressive generation에서는 새 토큰을 만들 때 이전 토큰들의 key와 value가 attention 계산에 필요하다. Hugging Face Transformers 문서는 KV cache를 이전 토큰의 attention layer에서 파생된 key-value 쌍을 저장해 재계산을 피하는 장치로 설명한다. 캐시는 생성이 진행될수록 이전 key-value tensor를 보관하고, 다음 토큰 계산에서 이를 재사용한다.

이 캐시는 분명히 이전 계산 결과를 저장한다. 그런 의미에서는 상태다. 하지만 그것은 사용자 의미 기억, 장기 작업 상태, 에이전트 목표 상태와 다르다. KV cache는 현재 generation sequence의 계산 효율을 높이기 위한 일시적 tensor 저장소다. 캐시에 “사용자는 옵시디안을 메모리로 쓴다” 같은 명제가 명시적으로 저장되는 것이 아니며, 개발자가 그 명제를 안정적으로 조회·수정·검증하는 구조도 아니다.

따라서 KV cache는 다음처럼 분류하는 편이 정밀하다.

KV cache
= autoregressive inference를 위한 일시적 계산 캐시
≠ 의미론적 장기 기억
≠ 사용자 프로필
≠ 에이전트 목표 상태
≠ 명시적 작업 로그

5. 에이전트 런타임의 상태 관리 계층은 LLM 바깥에서 작동한다

에이전트 시스템은 LLM의 일회성 호출 구조를 보완하기 위해 별도의 상태 관리 계층을 둔다. 가장 단순한 형태는 대화 이력을 저장했다가 다음 요청에 다시 넣는 방식이다. 더 복잡한 형태는 목표, 계획, 하위 작업, 도구 호출 결과, 실패 로그, 사용자 선호, 장기 기억, 환경 관찰을 구조화된 state 객체로 관리한다.

LangGraph 문서는 graph를 정의할 때 먼저 State를 정의하고, State가 schema와 reducer functions로 구성된다고 설명한다. 각 node는 State에 대한 update를 내보내고, reducer는 그 update가 기존 상태에 어떻게 적용되는지를 결정한다. 또한 persistence 문서는 graph state가 checkpointer를 통해 각 단계에서 저장될 수 있고, checkpoint가 특정 시점의 graph state snapshot으로 기능한다고 설명한다. memory 문서에서는 short-term memory를 agent state의 일부로, long-term memory를 세션을 넘어 유지되는 사용자별 또는 애플리케이션별 데이터로 구분한다.

이런 프레임워크에서 상태 관리는 LLM 내부의 자동 현상이 아니라 런타임 설계의 문제다. 상태를 어떤 schema로 정의할지, 어떤 key는 덮어쓸지 누적할지, 어떤 메시지는 요약할지 삭제할지, 어떤 memory를 장기 저장소에 넣을지, 실패 후 어느 checkpoint에서 재개할지는 에이전트 시스템의 설계 결정이다.

구체적 사례

단순 대화형 LLM

가장 단순한 대화형 서비스는 이전 메시지 일부를 새 프롬프트에 붙인다.

[System]
You are a helpful assistant.

[User]
나는 옵시디안을 메모리로 사용한다.

[Assistant]
알겠습니다. 옵시디안을 메모리 시스템으로 사용한다는 점을 반영하겠습니다.

[User]
내 메모리 시스템의 장점은 뭐야?

모델은 마지막 질문만 보는 것이 아니라 앞선 발화가 포함된 전체 입력을 본다. 그래서 “옵시디안”을 언급하며 답할 수 있다. 이 경우 상태는 모델 내부의 영속 변수에 저장된 것이 아니라, 프롬프트 이력으로 제공된 것이다.

컨텍스트 창 한계가 있는 긴 대화

긴 대화에서는 이전 메시지 전체가 항상 그대로 들어가지 않는다. 시스템은 오래된 메시지를 삭제하거나, 요약하거나, 관련 메모리만 검색해 삽입할 수 있다.

원래 대화 이력:
- 메시지 1: 사용자 선호
- 메시지 2: 작업 목표
- 메시지 3: 세부 자료
- ...
- 메시지 200: 현재 수정 요청

실제 입력 컨텍스트:
- system instruction
- 요약된 이전 대화
- 관련 메모리 3개
- 최근 메시지 10개
- 현재 사용자 요청

이 구조에서는 대화 상태가 단순히 “이전 대화 전체”와 같지 않다. 실제로 모델이 참조하는 것은 컨텍스트 구성기가 선택한 부분이다. 그래서 긴 작업에서는 중요한 상태를 명시적 checklist, 작업 로그, 파일, checkpoint, 구조화된 state 객체로 따로 관리하는 편이 안정적이다.

메모리 기능이 있는 서비스

메모리 기능이 있는 시스템은 특정 정보를 외부 저장소에 저장할 수 있다.

memory_store += {
  "user_tool": "Obsidian",
  "use_case": "personal memory system"
}

다음 대화에서 시스템은 이 정보를 검색해 프롬프트에 삽입한다.

Relevant memory:
- The user uses Obsidian as a personal memory system.

이때 “LLM이 기억했다”는 표현은 사용자 경험을 설명하는 말로는 가능하다. 아키텍처 차원에서는 외부 저장소가 정보를 유지하고, retrieval 또는 prompt assembly 과정이 그 정보를 모델 입력으로 제공한 것이다.

도구 사용 에이전트

도구 사용 에이전트는 보통 다음과 같은 루프를 가진다.

User request
→ state update
→ planning prompt
→ LLM proposes action
→ tool call
→ observation saved
→ state update
→ next LLM call

예를 들어 사용자가 “자료를 찾아 설명문을 작성해”라고 요청하면 에이전트 상태에는 다음 항목이 생길 수 있다.

{
  "task": "write explainer",
  "sources_needed": true,
  "search_queries": [
    "Transformer residual stream",
    "KV cache",
    "agent state manager"
  ],
  "draft_status": "not_started"
}

검색 결과가 들어오면 상태가 바뀐다.

{
  "draft_status": "sources_collected",
  "source_notes": [
    "Transformer dispenses with recurrence and convolution",
    "KV cache stores key-value tensors for inference efficiency",
    "LangGraph represents graph state with schemas and reducers"
  ]
}

이 상태 갱신은 LLM 가중치 변경이 아니다. 외부 런타임이 작업 상태를 명시적으로 저장하고, 다음 LLM 호출에 필요한 형태로 재구성하는 것이다.

퍼즐·논리 문제에서 상태 오류가 생기는 이유

LLM이 지뢰찾기, 스도쿠, 장기 계획, 복잡한 제약 충족 문제에서 오류를 내는 이유 중 하나는 명시적 상태 갱신의 불안정성과 관련된다. 이런 문제를 풀려면 현재 보드 상태, 가능한 후보, 제거된 경우, 확정된 값, 모순 여부를 안정적으로 관리해야 한다.

board_state
candidate_set
constraints
moves_history
contradictions

전통적 solver나 잘 설계된 에이전트는 이런 자료구조를 명시적으로 둔다. LLM은 텍스트로 중간 상태를 생성할 수 있지만, 그 상태가 항상 정확히 갱신되고 검증된다는 보장은 없다. 이미 제거한 후보를 다시 선택하거나, 이전 조건을 잊거나, 부분 제약을 전체 결론으로 과장할 수 있다. 상태 정확도가 중요한 과제에서는 LLM 단독 생성보다 외부 solver, symbolic checker, scratchpad, tool loop, checkpoint, state manager를 결합하는 방식이 더 안정적이다.

주요 쟁점과 반론

“LLM은 상태가 없다”는 말은 정확한가

이 표현은 너무 압축적이다. LLM에는 학습된 가중치라는 장기 구조가 있고, 추론 중에는 hidden states, residual stream, attention pattern, KV cache 같은 일시적 계산 상태가 존재한다. 그래서 “상태가 전혀 없다”고 말하면 부정확하다.

더 정밀한 표현은 다음이다.

Transformer 기반 LLM 본체는 서비스 대화나 작업 상태를
모델 내부의 명시적·영속적 변수로 기본 보존하지 않는다.

이 표현은 모델 내부 activation과 외부 애플리케이션 상태를 구분한다.

“state = prompt text”는 충분한 설명인가

“state = prompt text”는 입문 설명으로 유용하지만 실제 시스템을 모두 설명하지는 못한다. 모델이 직접 읽는 즉시 상태는 입력 컨텍스트지만, 그 입력 컨텍스트는 외부 상태 저장소와 prompt assembly 과정에 의해 구성된다. 또한 컨텍스트 창 한계 때문에 원문 이력이 잘리거나 요약될 수 있고, 장기 메모리는 검색 정책에 따라 선택적으로 삽입된다.

따라서 더 정밀한 표현은 다음이다.

LLM이 직접 참조하는 즉시 상태는 입력 컨텍스트이고,
그 입력 컨텍스트는 외부 상태 저장소와 상태 관리 계층이 구성한다.

residual stream을 “작업 메모리”라고 불러도 되는가

residual stream을 작업 메모리처럼 설명하는 것은 교육적으로 유용하다. 레이어들이 residual stream을 읽고 쓰며 중간 계산 결과를 누적한다는 점에서 임시 작업 공간이라는 비유가 성립한다. 그러나 엄밀한 심리학적 의미의 작업 기억과 동일시하면 곤란하다. 인간의 작업 기억은 목표 유지, 주의 제어, 정보 조작, 행동 선택과 결합된 인지 기능이다. Transformer의 residual stream은 그런 기능을 이름 붙여 저장한 기관이 아니라, 계산을 구성하는 activation 흐름이다.

따라서 안전한 표현은 “forward pass 내부에서 임시 계산 작업 공간으로 해석될 수 있다”이다. “LLM이 인간 같은 작업 기억을 가진다”는 표현은 과장이다.

State Manager는 표준 학술 용어인가

State Manager는 이 글에서 특정 단일 프레임워크의 고유 명칭으로 쓰는 말이 아니다. LangGraph는 State, reducer, checkpoint, persistence, memory 같은 용어를 사용하고, 다른 오케스트레이션 시스템은 runtime state, execution state, session state, memory manager, checkpoint store 같은 표현을 쓸 수 있다.

이 글에서 State Manager는 에이전트 런타임 내부에서 다음 기능을 수행하는 설계 계층을 가리킨다.

상태 저장
상태 갱신
컨텍스트 구성
메모리 검색
도구 결과 반영
체크포인트 저장
실패 후 복구

따라서 “State Manager가 있다”는 말은 특정 라이브러리 객체명이 반드시 존재한다는 뜻이 아니라, 그 역할을 수행하는 계층이 필요하다는 뜻이다.

에이전트는 LLM과 동일한가

에이전트는 보통 LLM을 포함하지만 LLM 자체와 동일하지 않다. 에이전트는 목표, 상태, 행동 선택, 도구 사용, 환경 피드백, 메모리 갱신을 포함한 더 큰 시스템이다. ReAct는 reasoning trace와 action을 결합해 외부 지식원이나 환경과 상호작용하는 방식을 제안했고, Reflexion은 가중치 업데이트 대신 언어적 피드백과 episodic memory buffer를 통해 다음 시도의 의사결정을 개선하는 구조를 제안했다. Generative Agents는 memory stream, reflection, planning을 결합해 상호작용하는 시뮬레이션 에이전트를 구성했다.

이 연구들의 공통점은 LLM만을 고립된 모델로 두지 않는다는 점이다. LLM은 추론과 언어 생성을 담당하고, 외부 구조가 관찰, 메모리, 행동, 반성, 계획을 관리한다.

오해와 한계

오해 1: Transformer는 입력 전체를 동시에 처리하므로 생성도 완전히 병렬이다

훈련에서는 causal mask를 사용해 여러 위치의 next-token prediction을 병렬적으로 계산할 수 있다. 하지만 실제 autoregressive generation에서는 다음 토큰이 이전에 생성된 토큰에 의존하므로 출력 토큰은 순차적으로 만들어진다. Transformer가 병렬화에 유리하다는 말은 주로 훈련과 prefix 처리의 계산 구조에 관한 것이며, 모든 생성 단계가 동시에 끝난다는 뜻은 아니다.

오해 2: KV cache가 있으므로 LLM은 RNN처럼 상태를 가진다

KV cache는 이전 key-value tensor를 저장한다는 점에서 상태적 요소다. 그러나 RNN의 hidden state처럼 매 시점의 입력을 하나의 추상 상태로 갱신해 다음 시점에 넘기는 구조와는 다르다. KV cache는 attention 계산을 빠르게 하기 위한 저수준 추론 최적화이며, 의미 있는 장기 기억이나 목표 관리 체계가 아니다.

오해 3: 대화형 AI가 기억하면 모델 가중치가 바뀐 것이다

일반적인 서비스 대화에서 모델 가중치가 매번 즉시 업데이트되는 것은 아니다. 대화 내용이 반영되는 주된 방식은 대화 이력이 입력에 포함되거나, 별도 메모리 저장소에서 관련 정보가 검색되어 프롬프트에 삽입되는 것이다. fine-tuning이나 continual learning은 별도의 학습 절차이며, 단일 대화의 상태 유지와 구분해야 한다.

오해 4: 암묵적 상태가 있으므로 LLM은 자기 상태를 안정적으로 관리할 수 있다

암묵적 activation은 다음 토큰 예측에 영향을 주지만, 명시적 자료구조처럼 안정적이고 검증 가능한 상태 관리를 보장하지는 않는다. 복잡한 작업에서는 모델이 중간 정보를 누락하거나, 이전 조건을 잘못 갱신하거나, 이미 배제한 가능성을 다시 선택할 수 있다. 상태 정확도가 중요한 업무에서는 외부 state manager, 검증기, 도구, 로그, 체크포인트를 결합해야 한다.

한계: 용어는 연구 분야와 구현체에 따라 달라진다

“residual stream”, “implicit state”, “attention dynamics”, “working memory”, “state manager” 같은 표현은 문헌과 구현체에 따라 엄밀도가 다르다. residual stream은 mechanistic interpretability 분야에서 널리 쓰이는 분석 관점이지만, 모든 Transformer 논문이 같은 용어를 쓰는 것은 아니다. State Manager도 범용 설계 역할명에 가깝다. 따라서 이 글의 목적은 특정 용어를 표준화하는 것이 아니라, 상태의 층위를 혼동하지 않도록 개념 구조를 분리하는 데 있다.

종합 구조

LLM과 에이전트의 상태 구조는 다음과 같이 정리할 수 있다.

층위	무엇을 저장·표현하는가	지속성	예시	주의점
모델 가중치	학습으로 형성된 일반 패턴	장기	`\theta`	대화 중 보통 즉시 바뀌지 않음
입력 컨텍스트	현재 요청에서 모델이 읽는 텍스트 상태	요청 단위	system prompt, conversation history, retrieved docs	컨텍스트에 포함된 것만 직접 참조 가능
residual stream	레이어를 통과하는 토큰별 activation 흐름	forward pass 내부	hidden representation	명시적 메모리 변수는 아님
attention pattern	토큰 간 참조 관계	forward pass 내부	attention weights	인간적 의미와 항상 일치하지 않음
KV cache	이전 토큰의 key-value tensor	생성 과정 단위	`past_key_values`	추론 최적화이지 장기 기억이 아님
외부 메모리	세션·사용자·작업의 저장 정보	장기 가능	database, vector store, files	검색·선별·갱신 정책이 필요
checkpoint	특정 시점의 실행 상태 snapshot	장기 가능	graph state checkpoint	복구와 재현성을 위한 장치
상태 관리 계층	상태 갱신·검색·복구 알고리즘	시스템 지속 기간	reducer, planner state, memory manager	에이전트 신뢰성의 핵심 계층

이 표의 핵심은 “상태”가 단일 개념이 아니라는 점이다. LLM 내부에도 계산 상태가 있고, 서비스에도 세션 상태가 있으며, 에이전트에는 명시적 작업 상태가 있다. 문제는 어느 층위의 상태를 말하는지 구분하는 것이다.

정리

Transformer 기반 LLM 본체는 RNN처럼 시간에 따라 hidden state를 계속 넘기며 갱신하는 구조가 아니다. 단일 호출을 추상화하면, 고정된 가중치와 입력 컨텍스트를 바탕으로 다음 토큰 확률분포를 계산하는 함수에 가깝다. 따라서 서비스 대화나 작업의 의미 상태는 기본적으로 모델 내부의 명시적·영속적 변수에 저장되는 것이 아니라, 프롬프트 이력, 검색된 문서, 외부 메모리, 도구 결과를 통해 다시 입력된다.

동시에 Transformer 내부 계산에는 일시적이고 암묵적인 상태가 있다. residual stream, attention pattern, hidden states, KV cache는 현재 입력을 처리하고 다음 출력을 생성하는 데 중요한 역할을 한다. 이들은 문맥 정보를 표현하고 중간 계산 결과를 전달하지만, 명시적이고 검증 가능한 장기 상태 관리 시스템은 아니다.

AI 에이전트의 핵심은 이 두 층위를 분리하는 데 있다. LLM은 언어적 추론과 생성의 엔진이고, 에이전트 런타임의 상태 관리 계층은 목표, 기억, 계획, 환경 관찰, 도구 결과, 체크포인트를 명시적으로 저장하고 갱신한다. 안정적인 장기 작업, 복잡한 도구 사용, 퍼즐·계획·업무 자동화처럼 상태 정확도가 중요한 과제에서는 LLM 단독보다 “LLM + 명시적 상태 관리 계층 + 외부 메모리 + 검증 루프” 구조가 더 적합하다.

한 문장으로 압축하면 다음과 같다.

LLM은 영속적 상태 관리자라기보다 입력 컨텍스트를 바탕으로 작동하는 추론 엔진이며,
현대 AI 에이전트는 이 추론 엔진 바깥에 명시적 상태 관리 계층을 결합해 장기 상태를 만든다.

참고자료

Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Łukasz Kaiser, Illia Polosukhin, “Attention Is All You Need,” arXiv:1706.03762, 2017.
Hugging Face Transformers Documentation, “Cache strategies,” https://huggingface.co/docs/transformers/kv_cache, 확인일 2026-05-06.
Hugging Face Transformers Documentation, “Caching,” https://huggingface.co/docs/transformers/cache_explanation, 확인일 2026-05-06.
Nelson Elhage, Neel Nanda, Catherine Olsson, Tom Henighan, Nicholas Joseph, Ben Mann, Amanda Askell, Yuntao Bai, Anna Chen, Tom Conerly 외, “A Mathematical Framework for Transformer Circuits,” Transformer Circuits, Anthropic, 2021.
Catherine Olsson, Nelson Elhage, Neel Nanda, Nicholas Joseph, Nova DasSarma, Tom Henighan, Ben Mann, Amanda Askell, Yuntao Bai, Anna Chen 외, “In-context Learning and Induction Heads,” Transformer Circuits / arXiv:2209.11895, 2022.
LangChain Documentation, “LangGraph overview,” https://docs.langchain.com/oss/python/langgraph/overview, 확인일 2026-05-06.
LangChain Documentation, “Graph API overview,” https://docs.langchain.com/oss/python/langgraph/graph-api, 확인일 2026-05-06.
LangChain Documentation, “Persistence,” https://docs.langchain.com/oss/python/langgraph/persistence, 확인일 2026-05-06.
LangChain Documentation, “Memory,” https://docs.langchain.com/oss/python/langgraph/add-memory, 확인일 2026-05-06.
Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, “ReAct: Synergizing Reasoning and Acting in Language Models,” arXiv:2210.03629 / ICLR 2023, 2022–2023.
Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao, “Reflexion: Language Agents with Verbal Reinforcement Learning,” arXiv:2303.11366 / NeurIPS 2023, 2023.
Joon Sung Park, Joseph C. O’Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, Michael S. Bernstein, “Generative Agents: Interactive Simulacra of Human Behavior,” UIST 2023, 2023.