Skip to content

명시적 상태 갱신 알고리즘: LLM 에이전트와 메모리 구조

핵심 요약

명시적 상태 갱신 알고리즘은 시스템이 현재 상태를 별도의 자료구조로 보존하고, 새 입력이나 사건이 들어올 때 정해진 규칙에 따라 다음 상태를 계산하는 방식이다. 가장 단순한 형태는 \(S_{t+1}=f(S_t,I_t)\)로 표현할 수 있다. 여기서 중요한 점은 시스템이 매번 전체 과거를 처음부터 해석하는 대신, 과거에서 유지해야 할 정보를 상태 객체에 압축해 두고 그 상태를 점진적으로 바꾼다는 것이다.

이 개념은 유한상태기계, 게임 엔진, 데이터베이스 트랜잭션, 강화학습 환경, 운영체제, 웹 애플리케이션, 워크플로 엔진 등에서 공통적으로 나타난다. LLM 시스템을 이해할 때도 중요하다. 기본적인 autoregressive Transformer 추론을 단순화하면, 모델은 현재 입력 문맥에 조건화해 다음 토큰 확률분포를 만들고 그 분포를 바탕으로 출력을 생성한다. 이때 대화의 지속성은 모델 내부의 영구 변수라기보다 프롬프트, API의 서버 측 conversation continuation, SDK 수준의 session memory, 외부 메모리, 체크포인트 저장소 같은 시스템 계층이 담당한다.

따라서 “LLM이 상태를 가진다”는 말은 여러 층위로 나누어 이해해야 한다. 모델 실행 중의 KV cache는 추론 효율을 위한 임시 계산 캐시이고, 프롬프트 안의 이전 대화는 텍스트로 재제공된 문맥이며, 에이전트 프레임워크의 memory/state는 외부 시스템이 명시적으로 저장하고 갱신하는 상태이다. 명시적 상태 갱신 알고리즘은 이 중 세 번째 층위, 곧 외부적으로 관리되는 구조화된 상태의 원리를 설명한다.

문제의식

LLM과 AI 에이전트를 설명할 때 “메모리”, “상태”, “맥락”, “기억”, “세션”, “세계 상태”라는 말이 자주 혼용된다. 이 혼용은 여러 오해를 만든다. 예를 들어 사용자는 긴 대화가 이어지면 모델이 사람처럼 기억한다고 생각하기 쉽고, 반대로 개발자는 모델 호출이 stateless하다는 말만 보고 모든 대화형 AI가 상태를 전혀 갖지 않는다고 오해하기 쉽다.

정확한 구분은 다음과 같다. 모델의 기본 추론은 주어진 입력 문맥에 조건화된 토큰 생성 과정으로 설명할 수 있다. 반면 실제 AI 제품이나 에이전트 시스템은 대화 기록, 사용자 설정, 장기 기억, 도구 실행 결과, 작업 진행 상태, 승인 대기 상태, 파일 상태, 외부 API 상태를 별도로 저장할 수 있다. 이때 시스템은 단순한 “텍스트 생성기”가 아니라 상태를 읽고, 상태를 갱신하고, 갱신된 상태를 다음 실행의 입력으로 사용하는 워크플로가 된다.

명시적 상태 갱신 알고리즘은 바로 이 차이를 이해하기 위한 핵심 개념이다. “현재 무엇이 참인가”, “어떤 목표가 남아 있는가”, “어떤 작업이 이미 끝났는가”, “무엇을 기억해야 하는가”, “어떤 도구 결과를 신뢰할 수 있는가”를 별도의 상태 객체로 관리하면, AI 시스템은 단일 응답 생성기를 넘어 반복 실행 가능한 작업 시스템에 가까워진다.

개념의 정의

명시적 상태 갱신 알고리즘은 상태 공간 \(\mathcal{S}\), 입력 공간 \(\mathcal{I}\), 갱신 함수 \(f\)를 전제한다. 특정 시점의 상태가 \(S_t\), 그 시점에 들어온 입력이 \(I_t\)라면, 다음 상태는 다음과 같이 계산된다.

\[ S_{t+1}=f(S_t,I_t) \]

여기서 상태는 시스템이 다음 판단을 위해 보존해야 하는 정보의 집합이다. 입력은 외부에서 새로 들어오는 사건, 사용자 명령, 센서 데이터, 도구 실행 결과, 시간 경과, 다른 에이전트의 메시지 등을 포함할 수 있다. 갱신 함수는 현재 상태와 입력을 결합해 무엇을 유지하고, 무엇을 바꾸고, 무엇을 버릴지 결정하는 규칙이다.

출력이 함께 필요한 시스템에서는 다음처럼 확장된다.

\[ (S_{t+1},O_t)=f(S_t,I_t) \]

여기서 \(O_t\)는 시스템이 반환하는 출력, 행동, 도구 호출, 메시지, 로그, 제어 신호가 될 수 있다. 에이전트 시스템에서는 \(O_t\)가 자연어 답변일 수도 있고, 검색 요청, 파일 작성, 코드 실행, 캘린더 수정 같은 외부 행동일 수도 있다.

이 개념에서 핵심은 “상태가 명시적”이라는 점이다. 상태가 명시적이라는 말은 시스템이 현재 상태를 별도의 객체, 테이블, 파일, 메모리 구조, 체크포인트, 그래프, 키-값 저장소 등으로 보존한다는 뜻이다. 이는 과거 입력 전체를 매번 다시 읽어 결과를 계산하는 방식과 구별된다.

배경과 맥락

상태 갱신이라는 발상은 컴퓨터과학의 여러 영역에 널리 퍼져 있다. 유한상태기계는 가능한 상태들의 집합과 입력에 따른 전이 규칙으로 시스템을 설명한다. 게임 엔진은 플레이어 위치, 체력, 아이템, 맵, 적의 위치를 상태로 보존하고, 프레임마다 입력과 물리 법칙에 따라 상태를 갱신한다. 데이터베이스는 레코드와 인덱스를 현재 상태로 보존하고, 트랜잭션을 통해 상태 변경을 원자적·일관적 방식으로 적용한다. 강화학습에서는 환경이 상태를 갖고, 에이전트의 행동과 전이 확률 또는 전이 규칙에 따라 다음 상태와 보상이 결정된다.

AI 에이전트 시스템은 이 전통적 상태 갱신 구조를 LLM 주변에 배치한다. LLM은 자연어 이해와 생성, 추론 후보 생성, 도구 선택, 요약, 분류, 계획 수립에 강점을 갖는다. 반면 LLM 호출만으로 장기 작업의 상태를 안정적으로 유지하기는 어렵다. 그래서 상당수의 실무적 에이전트 설계는 LLM 바깥에 상태 관리자, 메모리 저장소, 도구 실행기, 체크포인터, 정책 검증기, 로그 시스템을 둔다.

이 점은 여러 공식 문서에서 확인된다. Hugging Face Transformers 문서는 KV cache를 이전 토큰 처리에서 생성된 key/value 쌍을 저장해 재계산을 줄이는 추론 최적화 장치로 설명한다. OpenAI API 문서는 Responses API에서 previous_response_id를 사용해 응답들을 연결하고 threaded conversation을 만들 수 있으며, Conversations API를 통해 persistent conversation object를 사용할 수 있다고 설명한다. OpenAI Agents SDK 문서는 Sessions를 여러 agent run 사이에서 conversation history를 저장·재사용하는 SDK 계층의 session memory로 설명한다. LangGraph 문서는 checkpointer가 graph state를 checkpoint로 저장하고, thread_id를 기준으로 상태를 저장·조회하며, durable execution을 통해 중단 후 재개를 지원한다고 설명한다. MCP 사양의 2025-11-25 architecture 문서는 MCP를 client-host-server architecture로 설명하며, host가 여러 client instance를 실행하고 각 client가 MCP server와 연결되는 구조를 제시한다.

이러한 구조는 모두 “모델이 모든 것을 내부적으로 기억한다”는 방식이 아니라 “모델 바깥의 시스템이 상태를 명시적으로 관리하고, 필요한 상태를 모델 호출 시 제공한다”는 방식에 가깝다.

핵심 논리

명시적 상태 갱신 알고리즘의 핵심 논리는 세 가지다. 첫째, 상태는 과거 전체가 아니라 다음 판단에 필요한 충분한 요약이다. 둘째, 갱신 규칙은 새 입력이 들어왔을 때 상태의 어떤 부분을 바꿀지 결정한다. 셋째, 시스템의 안정성은 상태 표현과 갱신 규칙의 품질에 의해 크게 좌우된다.

예를 들어 체스 게임에서 현재 보드, 차례, 캐슬링 가능성, 앙파상 가능성, 반복 수, 50수 규칙 카운터를 알고 있다면 전체 기보를 매번 다시 읽지 않아도 다음 합법 수를 판단할 수 있다. 이는 상태가 과거 전체를 대체하는 충분한 정보가 되었기 때문이다. 상태에 캐슬링 가능성이나 차례 정보가 빠져 있으면, 보드 말 배치만으로는 정확한 다음 상태를 계산할 수 없다.

LLM 대화에서도 같은 문제가 나타난다. 전체 대화 텍스트를 다시 넣는 방식은 구현이 쉽지만, 대화가 길어지면 중요한 정보가 희석되고 컨텍스트 창을 낭비한다. 반면 명시적 상태 객체를 두면 사용자의 장기 목표, 확정된 사실, 미해결 과제, 선호 형식, 금지 조건, 최근 결정 사항을 구조화해 저장할 수 있다. 이후 새 입력이 들어올 때 상태 객체를 갱신하고, LLM에는 현재 응답에 필요한 상태만 선택적으로 제공할 수 있다.

이 차이는 다음처럼 표현할 수 있다.

텍스트 재계산 방식:
입력 = 전체 대화 기록 + 새 질문
출력 = 모델이 즉석에서 문맥을 해석해 답변

명시적 상태 갱신 방식:
state_old = 저장된 구조화 상태
input = 새 메시지 또는 사건
state_new = update(state_old, input)
prompt = 필요한 상태 조각 + 새 질문 + 작업 지시
출력 = 모델 또는 시스템 행동

두 방식은 논리적으로 완전히 분리되지 않는다. 과거 입력 전체를 하나의 상태로 간주하면 모든 대화 시스템은 넓은 의미에서 상태를 가진다고 말할 수 있다. 실무적으로 중요한 구분은 상태가 구조화되어 별도로 저장되고, 정해진 규칙에 따라 선택적으로 갱신되는가이다. 명시적 상태 갱신은 바로 이 실무적 차이를 가리킨다.

LLM에서의 상태: 다섯 가지 층위

LLM과 상태를 논할 때는 적어도 다섯 층위를 구분해야 한다.

첫 번째는 모델 파라미터이다. 파라미터는 학습 이후 모델의 장기적 능력을 담고 있지만, 일반적인 추론 요청 중 사용자의 새 대화 내용을 즉시 영구 저장하지 않는다. 사용자가 한 말이 그 순간 모델 가중치에 학습되어 다음 모든 사용자에게 반영되는 구조가 아니다.

두 번째는 입력 컨텍스트이다. 모델은 system prompt, developer instruction, 이전 메시지, 검색 결과, 도구 결과, 새 질문 등 현재 요청에 포함된 텍스트를 읽고 출력을 생성한다. 이 컨텍스트는 응답 생성 동안 조건으로 작동하지만, 컨텍스트 창을 벗어나면 자동으로 유지되지 않는다.

세 번째는 KV cache이다. KV cache는 Transformer 추론 중 이미 처리된 토큰의 attention key/value를 저장해 다음 토큰 생성 때 재계산을 줄이는 장치이다. 이 캐시는 “의미론적 장기 기억”이 아니라 순차 디코딩을 빠르게 하기 위한 계산 캐시이다. 캐시 안에는 이전 토큰으로부터 계산된 중간 표현이 들어 있지만, 사용자의 장기 목표나 선호를 구조화해 보존하는 메모리와는 역할이 다르다.

네 번째는 API 또는 서버 측 conversation continuation이다. 예를 들어 OpenAI Responses API의 previous_response_id는 이전 응답 ID를 참조해 응답들을 연결하고 threaded conversation을 만들 수 있게 한다. Conversations API의 persistent conversation object는 대화를 별도 객체로 다룰 수 있게 한다. 이 방식은 모델 파라미터가 기억하는 것이 아니라 API 계층이 이전 응답 또는 conversation object를 이용해 대화 지속성을 제공하는 방식이다.

다섯 번째는 SDK 또는 애플리케이션 계층의 session memory와 external memory이다. OpenAI Agents SDK의 Sessions는 여러 agent run 사이의 대화 기록을 저장·재사용하는 SDK 수준의 session memory이다. LangGraph의 checkpoint, 애플리케이션의 데이터베이스, 벡터 스토어, 파일 메모리, 지식 그래프, 사용자 프로필 저장소도 이 계층에 속한다. 이 층위가 명시적 상태 갱신 알고리즘과 가장 직접적으로 연결된다.

이 구분이 중요한 이유는 “상태”라는 단어가 같은 의미로 쓰이지 않기 때문이다. KV cache, 프롬프트 히스토리, 서버 측 continuation, SDK session memory, 장기 메모리는 모두 이전 정보를 활용하지만, 저장 위치·갱신 규칙·수명·검증 가능성·사용자 제어 가능성이 다르다.

OpenAI의 conversation state와 SDK Sessions 구분

OpenAI 관련 상태 관리는 두 범주를 구분해 설명하는 편이 정확하다.

첫째, OpenAI API의 서버 측 conversation continuation이다. Responses API에서는 previous_response_id를 사용해 이전 응답을 참조하고, 응답들을 연결해 threaded conversation을 구성할 수 있다. 또한 Conversations API는 persistent conversation object를 통해 대화 상태를 관리하는 방식을 제공한다. 이 범주는 서버 관리 방식에 가깝다. 애플리케이션은 이전 응답 ID나 conversation ID를 보존하고, 다음 요청에서 이를 참조한다.

둘째, OpenAI Agents SDK의 Sessions이다. Sessions는 여러 agent run 사이의 conversation history를 저장·재사용하는 SDK 계층의 session memory이다. SDK 문서상 Sessions는 conversation_id, previous_response_id, auto_previous_response_id와 같은 서버 관리 conversation 설정과 같은 run에서 결합할 수 없다. 하나의 호출에서는 SDK session persistence를 사용할지, 서버 관리 continuation을 사용할지 선택해야 한다.

이 차이는 작지만 중요하다. 두 방식은 모두 “대화 지속성”을 제공하지만, 같은 종류의 상태 저장 메커니즘이 아니다. 서버 측 continuation은 OpenAI API의 응답 체인 또는 conversation object를 참조하는 방식이고, SDK Sessions는 SDK가 대화 기록을 저장하고 각 run에 필요한 history를 다시 제공하는 방식이다. 따라서 문서나 설계도에서 이 둘을 “OpenAI의 상태 관리”라는 큰 범주로 묶을 수는 있지만, 구현 제약까지 설명할 때는 반드시 분리해야 한다.

LangGraph와 명시적 상태 갱신

LangGraph는 명시적 상태 갱신 구조를 이해하기 좋은 사례이다. LangGraph의 Graph API에서는 상태를 정의하고, 노드가 상태 일부를 읽고 새 값을 반환하며, reducer가 여러 업데이트를 병합할 수 있다. 실행은 그래프의 노드와 엣지를 따라 진행되고, 각 단계에서 상태가 갱신된다.

LangGraph의 persistence 문서는 thread를 checkpointer가 저장하는 checkpoint들의 식별 단위로 설명한다. thread_id는 checkpoint 저장과 조회의 기본 키 역할을 하며, thread의 현재 상태와 과거 상태를 조회할 수 있다. checkpoint는 특정 시점의 graph state snapshot이다. 이 구조 덕분에 시스템은 중간 상태를 저장하고, interrupt 이후 다시 실행하며, 이전 checkpoint에서 replay 또는 fork를 수행할 수 있다.

Durable execution은 이 구조의 실무적 의미를 보여준다. LangGraph의 durable execution 문서는 completed work를 보존해 이전 단계를 재처리하지 않고 실행을 재개할 수 있다고 설명한다. 이를 제대로 사용하려면 workflow가 deterministic하고 idempotent하도록 설계되어야 하며, side effect나 비결정적 작업은 task 안에 감싸는 편이 권장된다. 이는 명시적 상태 갱신 시스템에서 “상태 저장”만큼이나 “재실행 가능성”과 “중복 실행 방지”가 중요하다는 점을 보여준다.

MCP와 상태: capability 연결과 세션 경계

MCP(Model Context Protocol)는 LLM 애플리케이션이 외부 데이터 소스와 도구에 표준화된 방식으로 연결되도록 하는 프로토콜이다. 2025-11-25 MCP architecture 문서는 MCP가 client-host-server architecture를 따른다고 설명한다. host는 여러 client instance를 실행할 수 있고, 각 client는 특정 MCP server와 연결된다. MCP server는 tools, resources, prompts 같은 capability를 노출하고, AI 애플리케이션은 이 capability를 통해 외부 시스템과 상호작용할 수 있다.

이 구조를 상태 갱신 관점에서 보면, MCP 자체는 “모든 메모리를 저장하는 범용 기억 장치”라기보다 외부 capability와 context를 연결하는 프로토콜 계층이다. MCP server가 데이터베이스, 파일 시스템, 업무 도구, 내부 API와 연결되어 있다면, 그 서버가 노출하는 resource나 tool은 상태 읽기와 상태 변경의 통로가 될 수 있다. 따라서 MCP는 명시적 상태 갱신 알고리즘의 직접 구현체라기보다, 상태를 가진 외부 시스템과 LLM 애플리케이션 사이의 표준 인터페이스로 이해하는 편이 정확하다.

공식 architecture 표현에 맞추려면 “host-client-server”보다 “client-host-server architecture”라고 쓰는 편이 안전하다. 더 풀어서 말하면 “host가 여러 client instance를 만들고 관리하며, 각 client가 특정 MCP server와 연결되는 구조”이다.

구체적 사례

게임 보드 상태

게임에서 상태는 보드, 점수, 플레이어 위치, 남은 시간, 아이템, 적의 위치, 현재 턴 등을 포함한다. 사용자의 입력이 들어오면 게임 엔진은 물리 법칙, 충돌 규칙, 승패 조건에 따라 상태를 갱신한다.

state = {
    "player_position": [3, 5],
    "hp": 80,
    "inventory": ["key"],
    "door_open": False,
}

def update(state, input_event):
    new_state = state.copy()

    if input_event == "use_key_on_door" and "key" in new_state["inventory"]:
        new_state["door_open"] = True

    return new_state

이 예에서 시스템은 전체 플레이 기록을 매번 다시 읽지 않는다. 현재 상태만 있으면 다음 상태를 계산할 수 있다.

데이터베이스 트랜잭션

데이터베이스 트랜잭션은 명시적 상태 갱신의 안정성을 보여주는 대표 사례이다. PostgreSQL 문서는 transaction을 여러 SQL 명령을 하나의 all-or-nothing operation으로 묶는 구조로 설명한다. BEGIN과 COMMIT 사이의 변경은 트랜잭션이 완료되기 전까지 다른 concurrent transaction에 보이지 않으며, 문제가 생기면 ROLLBACK으로 변경을 취소할 수 있다.

이 사례가 AI 에이전트에 주는 교훈은 분명하다. 에이전트가 도구를 호출해 데이터베이스, 파일, 캘린더, 이메일, 결제 시스템을 변경한다면 상태 갱신은 단순한 텍스트 생성이 아니라 실제 세계의 변경이다. 따라서 다음 조건이 필요하다.

  • 변경 전후 상태를 기록해야 한다.
  • 부분 실패 시 롤백 또는 보상 트랜잭션이 가능해야 한다.
  • 중복 실행이 일어나도 결과가 파괴되지 않도록 idempotent하게 설계해야 한다.
  • 동시 요청이 같은 상태를 바꿀 때 충돌을 감지해야 한다.

대화 메모리 시스템

대화형 에이전트는 사용자 정보, 작업 목표, 문서 작성 규칙, 금지 조건, 선호 출력 형식을 상태로 가질 수 있다.

state = {
    "user_name": "DK",
    "current_topic": "AI cognition",
    "long_term_preferences": {
        "language": "ko",
        "style": "formal_explanatory",
    },
    "known_facts": [],
    "open_tasks": [],
}

user_input = "나는 옵시디안에 AI 메모리 노트를 저장한다."

state["known_facts"].append({
    "claim": "The user stores AI memory notes in Obsidian.",
    "source": "user_message",
    "confidence": "user_reported",
})

이 예에서 중요한 점은 memory write에 출처와 신뢰도를 붙였다는 것이다. 사용자의 말, 외부 문서, 모델의 추론, 도구 실행 결과는 서로 다른 신뢰 수준을 갖는다. 출처 없는 memory write는 시간이 지날수록 잘못된 상태를 고착시킬 수 있다.

퍼즐과 보드 추론

지뢰찾기, 스도쿠, 체스, 로직 퍼즐은 상태 표현의 품질이 결과를 크게 좌우하는 사례이다. LLM이 보드를 텍스트로만 읽고 답하면, 이미 확정된 칸과 후보 숫자, 제약 조건, 이전 추론 결과를 안정적으로 추적하지 못할 수 있다. 반면 명시적 상태 시스템은 다음처럼 보드를 구조화한다.

board_state = {
    "fixed_values": {(0, 0): 5, (0, 1): 3},
    "candidates": {
        (0, 2): {1, 2, 4},
        (0, 3): {2, 6},
    },
    "constraints": ["row", "column", "box"],
}

이 구조에서는 후보 제거, 확정값 추가, 모순 감지를 규칙 기반으로 처리할 수 있다. LLM은 설명 생성이나 전략 선택에 쓰고, 상태 갱신은 별도 알고리즘이 담당하게 만들 수 있다.

상태 투영: 필요한 상태만 넣는 것의 위험

명시적 상태 객체를 두면 LLM에는 현재 응답에 필요한 상태만 선택적으로 제공할 수 있다. 이 설계는 컨텍스트 효율성과 성능 면에서 장점이 있다. 모든 대화 기록, 모든 도구 로그, 모든 DB 레코드를 모델에 넣을 필요가 없기 때문이다.

그러나 이 과정은 새로운 실패 원인을 만든다. 상태 객체 전체에서 모델 입력으로 들어가는 부분을 고르는 과정을 projection이라고 부를 수 있다. 필요한 상태 조각을 잘못 선택하면 모델은 중요한 제약을 보지 못한다. 이 문제를 projection loss 또는 state selection error라고 부를 수 있다.

예를 들어 사용자의 장기 선호, 법적 금지 조건, 결제 승인 상태, 이미 실행된 도구 호출 결과가 상태에는 저장되어 있지만 현재 프롬프트에 투영되지 않았다면, 모델은 그 사실을 고려하지 못한다. 이때 시스템은 상태를 “가지고” 있으면서도 실제 응답에서는 상태를 활용하지 못한다.

따라서 명시적 상태 갱신 시스템에는 두 종류의 함수가 필요하다.

update:      (old_state, input) -> new_state
projection: (state, task) -> model_context

update가 상태를 어떻게 바꿀지 결정한다면, projection은 상태 중 무엇을 모델에게 보여줄지 결정한다. 실무적으로는 projection도 검증 대상이다. 중요 제약 누락, 오래된 상태 사용, 잘못된 검색 결과 삽입, 과도한 요약, 출처 없는 memory write가 모두 projection 단계에서 발생할 수 있다.

상태 갱신 실패 조건

명시적 상태 갱신은 강력하지만 자동으로 안전한 것은 아니다. 상태를 별도로 저장하기 때문에 오히려 새로운 오류 유형이 생긴다.

첫째, 동시성 충돌이 발생할 수 있다. 두 요청이 같은 상태를 동시에 읽고 서로 다른 변경을 적용하면 한쪽 변경이 덮어씌워질 수 있다. 사용자 프로필, 재고 수량, 캘린더 일정, 작업 큐 같은 상태는 optimistic locking, version number, transaction, conflict resolution policy가 필요하다.

둘째, 중복 도구 실행 문제가 생길 수 있다. 네트워크 오류나 retry 때문에 같은 이메일이 두 번 발송되거나 같은 결제가 두 번 실행될 수 있다. 외부 부작용이 있는 도구는 idempotency key, 실행 로그, 중복 실행 감지 장치를 가져야 한다.

셋째, 부분 실패가 발생할 수 있다. 에이전트가 파일은 수정했지만 데이터베이스 기록은 갱신하지 못하거나, 캘린더 초대는 보냈지만 내부 작업 상태는 실패로 남을 수 있다. 이런 경우 rollback, compensating action, 상태 재조정 절차가 필요하다.

넷째, stale state 문제가 있다. 상태가 오래되어 실제 세계와 맞지 않을 수 있다. 예를 들어 “회의 시간이 3시”라는 상태가 저장되어 있어도 캘린더가 이미 4시로 바뀌었다면, 에이전트는 낡은 상태에 근거해 잘못 행동할 수 있다. 외부 세계 상태는 일정 주기로 재검증하거나, 중요한 행동 전에 source of truth를 다시 조회해야 한다.

다섯째, 권한 없는 상태 변경이 있다. 모든 입력이 모든 상태를 바꿀 수 있어서는 안 된다. 사용자의 임시 발화, 모델의 추론, 외부 문서의 내용이 사용자 프로필이나 시스템 정책을 마음대로 바꿀 수 있으면 상태 오염이 발생한다. memory write에는 권한, 출처, 승인 수준이 필요하다.

여섯째, 출처 없는 memory write가 있다. “사용자는 X를 선호한다” 같은 장기 기억이 모델 추론만으로 저장되면 잘못된 개인화가 고착될 수 있다. 장기 메모리에는 출처, 작성 시점, confidence, 삭제 가능성, 사용자 확인 여부가 붙어야 한다.

일곱째, schema drift가 있다. 상태 객체의 구조가 바뀌었는데 이전 버전의 상태가 그대로 남아 있으면 갱신 함수가 잘못 작동할 수 있다. 상태 schema version, migration, backward compatibility가 필요하다.

여덟째, projection loss가 있다. 상태에는 중요한 정보가 있지만 모델 입력에 포함되지 않아 모델이 그 정보를 사용하지 못하는 경우이다. 이는 장기 메모리 시스템과 RAG 시스템에서 특히 흔하다.

설계 원칙

명시적 상태 갱신 시스템을 설계할 때는 먼저 상태의 범위를 정해야 한다. 모든 것을 저장하는 상태는 좋은 상태가 아니다. 좋은 상태는 다음 판단에 필요한 정보를 충분히 담되, 갱신·검증·삭제가 가능한 구조를 가져야 한다.

첫 번째 원칙은 상태와 로그를 구분하는 것이다. 상태는 현재 판단에 필요한 요약이고, 로그는 과거 사건의 원본 기록이다. 상태가 잘못되었을 때 로그를 통해 재구성할 수 있어야 한다. 중요한 시스템에서는 event sourcing처럼 사건 로그를 보존하고, 현재 상태는 그 로그에서 파생된 projection으로 관리할 수 있다.

두 번째 원칙은 상태 갱신 규칙을 명시하는 것이다. 어떤 입력이 어떤 상태 필드를 바꿀 수 있는지 정해야 한다. 사용자 발화가 장기 메모리를 직접 바꿀 수 있는지, 도구 결과만 world state를 바꿀 수 있는지, 모델 추론은 임시 후보로만 둘 것인지 구분해야 한다.

세 번째 원칙은 상태 변경에 출처와 confidence를 붙이는 것이다. 사용자가 직접 말한 사실, 공식 API에서 조회한 사실, 모델이 요약한 사실, 검색 결과에서 추출한 사실은 같은 신뢰도를 갖지 않는다. 상태 객체는 값만 저장하는 것이 아니라 “이 값이 어디서 왔고 얼마나 믿을 수 있는지”를 함께 저장해야 한다.

네 번째 원칙은 projection을 별도 설계 대상으로 보는 것이다. 상태 저장소에 정보가 있다고 해서 LLM이 그 정보를 활용하는 것은 아니다. 현재 task에 필요한 상태 조각을 선별하고, 누락 여부를 검사하며, 중요한 제약은 항상 포함되도록 해야 한다.

다섯 번째 원칙은 트랜잭션과 idempotency를 적용하는 것이다. 외부 시스템을 변경하는 에이전트는 실패와 retry를 전제로 설계해야 한다. 도구 실행에는 idempotency key를 붙이고, side effect가 있는 작업은 완료 여부를 기록하며, 중복 실행에 안전해야 한다.

여섯 번째 원칙은 인간 승인 지점을 명확히 두는 것이다. 이메일 발송, 결제, 삭제, 권한 변경, 외부 게시, 법적·의료적·재정적 판단처럼 영향이 큰 행동은 상태 갱신 전에 승인 대기 상태를 거치게 할 수 있다. LangGraph의 interrupt와 human-in-the-loop 패턴은 이런 구조를 구현하는 대표적 방법이다.

일곱 번째 원칙은 오래된 상태를 자동으로 신뢰하지 않는 것이다. 외부 세계에 대한 상태는 source of truth를 다시 확인해야 한다. 캘린더, 이메일, 파일, 정책, 가격, 법령, API 문서처럼 변할 수 있는 정보는 마지막 확인 시각과 재검증 규칙을 가져야 한다.

오해와 한계

첫 번째 오해는 “LLM은 상태가 없으므로 대화형 AI는 기억할 수 없다”는 것이다. 모델 호출 자체는 상태 저장을 자동 보장하지 않지만, 제품과 에이전트 시스템은 외부 저장소와 API 계층을 통해 상태를 유지할 수 있다. 문제는 기억 가능성의 유무가 아니라 어떤 계층이 어떤 방식으로 상태를 저장·갱신하는가이다.

두 번째 오해는 “컨텍스트 히스토리를 모두 넣으면 상태 관리가 해결된다”는 것이다. 전체 히스토리 재주입은 단순하지만 길이 제한, 비용 증가, 중요 정보 희석, 모순 누적, 검색 실패 문제를 만든다. 긴 작업일수록 구조화된 상태, 요약, 검색, projection, 검증 루프가 필요하다.

세 번째 오해는 “KV cache가 LLM의 기억이다”라는 것이다. KV cache는 이전 토큰의 key/value 계산을 저장해 추론을 빠르게 하는 장치이다. 그것은 사용자의 장기 목표나 선호를 의미론적으로 정리해 보존하는 장기 기억과 다르다.

네 번째 오해는 “명시적 상태를 두면 오류가 사라진다”는 것이다. 명시적 상태는 오류를 줄일 수 있지만, 잘못된 상태가 저장되면 오류가 더 오래 지속된다. 상태 관리 시스템은 memory write 검증, 충돌 처리, 출처 관리, 만료 정책, 삭제 정책, audit log를 가져야 한다.

다섯 번째 오해는 “에이전트 프레임워크를 쓰면 자동으로 올바른 상태 관리가 된다”는 것이다. 프레임워크는 checkpoint, session, memory, tool orchestration을 제공할 수 있지만, 어떤 정보를 상태로 삼을지, 언제 갱신할지, 어떤 상태를 모델에 투영할지, 어떤 행동에 승인을 요구할지는 애플리케이션 설계 문제로 남는다.

정리

명시적 상태 갱신 알고리즘은 현재 상태를 따로 저장하고, 새 입력이 들어올 때 규칙에 따라 다음 상태를 계산하는 구조이다. 이 구조는 단순한 수식 \(S_{t+1}=f(S_t,I_t)\)로 표현되지만, 실제 의미는 크다. 상태를 명시적으로 관리하면 시스템은 전체 과거를 매번 다시 읽는 방식에서 벗어나, 현재 판단에 필요한 정보만 유지하고 갱신할 수 있다.

LLM 시스템에서 이 개념은 특히 중요하다. 기본적인 autoregressive Transformer 추론은 입력 문맥에 조건화된 토큰 생성으로 설명할 수 있고, KV cache는 추론 효율을 위한 계산 캐시이다. 대화 지속성, 장기 기억, 작업 진행 상태, 도구 실행 상태는 모델 내부의 영구 기억보다 API 계층, SDK 계층, 애플리케이션 계층, 외부 저장소 계층에서 관리되는 경우가 많다.

OpenAI의 Responses API와 Conversations API는 서버 측 conversation continuation을 제공하고, OpenAI Agents SDK의 Sessions는 SDK 계층의 conversation history 저장을 제공한다. LangGraph는 checkpoint와 thread 기반 persistence를 통해 장기 실행 워크플로의 상태 저장과 재개를 지원한다. MCP는 client-host-server architecture를 통해 LLM 애플리케이션과 외부 tools, resources, prompts를 연결하는 프로토콜 계층이다.

가장 중요한 결론은 다음이다. LLM 자체를 “모든 것을 기억하는 주체”로 보는 설명은 부정확하다. 실무적 AI 시스템은 LLM을 추론·생성 엔진으로 사용하면서, 상태 갱신과 기억 관리를 외부 구조로 분리한다. 좋은 에이전트 설계의 핵심은 더 긴 프롬프트를 넣는 것이 아니라, 어떤 상태를 저장하고, 어떤 규칙으로 갱신하며, 어떤 상태를 모델에 투영하고, 어떤 변경을 검증할 것인지를 명시하는 데 있다.

참고자료

  • Ashish Vaswani et al., “Attention Is All You Need,” NeurIPS, 2017. 확인일: 2026-05-06. https://arxiv.org/abs/1706.03762
  • Hugging Face, “Caching,” Transformers Documentation. 확인일: 2026-05-06. https://huggingface.co/docs/transformers/en/cache_explanation
  • Hugging Face, “Cache strategies,” Transformers Documentation. 확인일: 2026-05-06. https://huggingface.co/docs/transformers/en/kv_cache
  • OpenAI, “Conversation state,” OpenAI API Documentation. 확인일: 2026-05-06. https://developers.openai.com/api/docs/guides/conversation-state
  • OpenAI, “Migrate to the Responses API,” OpenAI API Documentation. 확인일: 2026-05-06. https://developers.openai.com/api/docs/guides/migrate-to-responses
  • OpenAI, “Conversations,” OpenAI API Reference. 확인일: 2026-05-06. https://developers.openai.com/api/reference/resources/conversations
  • OpenAI, “Sessions,” OpenAI Agents SDK Documentation. 확인일: 2026-05-06. https://openai.github.io/openai-agents-python/sessions/
  • OpenAI, “Running agents,” OpenAI Agents SDK Documentation. 확인일: 2026-05-06. https://openai.github.io/openai-agents-python/running_agents/
  • OpenAI, “Session,” OpenAI Agents SDK Reference. 확인일: 2026-05-06. https://openai.github.io/openai-agents-python/ref/memory/session/
  • LangChain, “Persistence,” LangGraph Documentation. 확인일: 2026-05-06. https://docs.langchain.com/oss/python/langgraph/persistence
  • LangChain, “Durable execution,” LangGraph Documentation. 확인일: 2026-05-06. https://docs.langchain.com/oss/python/langgraph/durable-execution
  • LangChain, “Interrupts,” LangGraph Documentation. 확인일: 2026-05-06. https://docs.langchain.com/oss/python/langgraph/interrupts
  • LangChain, “Use time-travel,” LangGraph Documentation. 확인일: 2026-05-06. https://docs.langchain.com/oss/python/langgraph/use-time-travel
  • Model Context Protocol, “Architecture,” MCP Specification, Version 2025-11-25. 확인일: 2026-05-06. https://modelcontextprotocol.io/specification/2025-11-25/architecture
  • Model Context Protocol, “Resources,” MCP Specification, Version 2025-11-25. 확인일: 2026-05-06. https://modelcontextprotocol.io/specification/2025-11-25/server/resources
  • PostgreSQL Global Development Group, “3.4. Transactions,” PostgreSQL 18 Documentation. 확인일: 2026-05-06. https://www.postgresql.org/docs/current/tutorial-transactions.html

본문 주장과 참고자료 연결

  • 기본 Transformer가 decoder output을 linear transformation과 softmax를 거쳐 next-token probabilities로 바꾼다는 설명은 Vaswani et al.의 「Attention Is All You Need」에 근거한다.
  • KV cache가 이전 토큰의 key/value 쌍을 저장해 재계산을 줄이는 추론 최적화 장치라는 설명은 Hugging Face Transformers의 “Caching” 및 “Cache strategies” 문서에 근거한다.
  • Responses API의 previous_response_id, threaded conversation, Conversations API의 persistent conversation object 설명은 OpenAI API의 “Conversation state”, “Migrate to the Responses API”, “Conversations” 문서에 근거한다.
  • OpenAI Agents SDK Sessions가 여러 agent run 사이의 conversation history를 저장·재사용하는 SDK session memory이며, conversation_id, previous_response_id, auto_previous_response_id와 같은 서버 관리 conversation 설정과 같은 run에서 결합할 수 없다는 설명은 OpenAI Agents SDK의 “Sessions”와 “Running agents” 문서에 근거한다.
  • LangGraph의 checkpoint, thread_id, durable execution, interrupt, time travel 설명은 LangGraph 공식 문서의 “Persistence”, “Durable execution”, “Interrupts”, “Use time-travel”에 근거한다.
  • MCP가 2025-11-25 사양에서 client-host-server architecture를 따르고, host가 여러 client instance를 실행하며 server가 resources 등 capability를 노출한다는 설명은 MCP Specification의 “Architecture”와 “Resources” 문서에 근거한다.
  • PostgreSQL transaction이 all-or-nothing operation, visibility isolation, BEGIN·COMMIT·ROLLBACK 구조를 갖는다는 설명은 PostgreSQL 공식 문서의 “Transactions”에 근거한다.