Skip to content

맥락 크기가 아니라 명시적 상태 갱신 알고리즘의 문제다

핵심 요약

LLM이 지뢰찾기, 스도쿠, 보드 게임, 다단계 제약 문제에서 틀리는 이유를 단순히 “컨텍스트가 작아서”라고 설명하면 핵심을 놓치기 쉽다. 작은 보드나 짧은 퍼즐에서도 오류가 발생할 수 있기 때문이다. 더 정밀한 설명은 다음과 같다. 컨텍스트는 모델이 읽는 입력 공간이고, 상태는 규칙에 따라 갱신되는 자료구조다. 많은 현대 LLM, 특히 autoregressive decoder-only LLM은 문맥을 바탕으로 다음 토큰 분포를 계산하도록 학습된 모델이지, 보드 배열·후보 집합·불변 조건·검증 루프를 명시적으로 유지하고 갱신하는 알고리즘은 아니다.

이 말은 LLM이 아무 상태도 갖지 않는다는 뜻이 아니다. 모델 내부에는 hidden activation이 있고, 추론 중에는 KV cache가 있으며, 애플리케이션 계층에는 대화 기록이나 외부 메모리가 있을 수 있다. 핵심은 이러한 요소들이 지뢰찾기 보드의 board[i][j], 남은 지뢰 수, 후보 집합, 제약 만족 여부처럼 명시적이고 검증 가능한 문제 상태를 자동으로 유지·갱신하는 구조와 다르다는 점이다. 따라서 퍼즐 오류는 여러 원인의 결합으로 발생하지만, 작은 입력에서도 반복적으로 드러나는 중요한 취약점 중 하나는 명시적 상태 표현, 상태 전이, 정합성 검증이 기본 생성 구조에 강제되어 있지 않다는 점이다.

이 한계를 보완하려는 설계가 Tool Use, Program-of-Thought, PAL, ReAct, LangGraph 같은 상태 기반 에이전트 프레임워크, MCP 같은 외부 도구·데이터 연결 프로토콜, 그리고 더 넓은 의미의 neuro-symbolic AI다. 이들은 같은 층위의 기술이 아니다. Tool Use와 PoT/PAL은 계산을 외부 도구나 프로그램 실행기에 위임하는 방식이고, ReAct는 추론과 행동을 교차시키는 프롬프트·에이전트 패턴이며, LangGraph는 상태를 읽고 쓰는 워크플로 오케스트레이션 프레임워크이고, MCP는 도구·데이터·프롬프트를 표준적으로 연결하기 위한 프로토콜이다. Neuro-symbolic AI는 신경망과 기호적 표현·추론을 결합하려는 더 넓은 연구 패러다임이다.

문제의식

사용자가 제기한 핵심 문장은 다음이다.

맥락 크기가 아니라 “명시적 상태 갱신 알고리즘이 없는 구조”가 문제다.

이 문장은 LLM의 한계를 설명할 때 매우 중요한 관점을 제공한다. LLM의 실패를 “기억을 못 한다”로만 설명하면, 컨텍스트 창이 커지면 문제가 자동으로 사라질 것처럼 오해할 수 있다. 지뢰찾기 보드를 텍스트로 모두 제공하면 보드 정보는 분명히 컨텍스트 안에 있다. 토큰 수가 작다면 입력 길이의 한계도 아니다. 그런데도 모델이 조건을 빠뜨리거나, 이미 확정한 상태와 모순되는 결론을 내거나, 한 단계 전 결론을 다음 단계에서 반영하지 못하는 일이 생긴다.

이 현상은 정보가 “보이는가”와 정보가 “계산 가능한 상태로 갱신되는가”의 차이에서 나온다. 모델이 보드를 읽을 수 있다는 사실은 보드 상태를 알고리즘적으로 유지한다는 사실과 다르다. 퍼즐 풀이에는 읽기, 규칙 적용, 상태 갱신, 모순 검사, 재탐색이 필요하다. LLM은 이런 과정을 텍스트로 흉내 낼 수 있지만, 기본 생성 구조 자체가 state -> rule -> new_state를 보장하지는 않는다.

개념의 정의

맥락

맥락(context)은 모델이 현재 입력으로 받는 토큰들의 배열이다. 사용자의 질문, 이전 대화, 보드 설명, 규칙 설명, 예시, 시스템 지시 등이 모두 맥락에 포함될 수 있다. 맥락은 모델이 참조할 수 있는 정보 공간이다.

예를 들어 다음 지뢰찾기 보드 설명은 맥락이다.

A1은 숫자 1이다.
A2는 미확인 칸이다.
B1은 미확인 칸이다.
전체 지뢰는 1개 남아 있다.

모델은 이 텍스트를 읽고 다음 토큰을 생성한다. 텍스트가 충분히 짧고 명확하다면, 모델은 단순한 경우에 올바른 결론을 낼 수 있다.

상태

상태(state)는 알고리즘이나 시스템이 현재 문제의 조건을 표현하기 위해 유지하는 내부 자료구조다. 상태는 단순한 설명이 아니라 연산의 대상이다. 갱신 가능하고, 비교 가능하고, 검증 가능해야 한다.

예를 들어 알고리즘은 다음과 같은 상태를 유지할 수 있다.

board[0][0] = 1
unknown_cells = {(0, 1), (1, 0)}
remaining_mines = 1
constraints = [sum([(0, 1), (1, 0)]) == 1]

이 상태는 규칙에 따라 갱신된다. 어떤 칸이 지뢰로 확정되면 후보 집합에서 제거되고, 인접 숫자의 제약식이 바뀌며, 남은 지뢰 수가 감소한다. 알고리즘은 이 변화가 모든 제약과 일관되는지 검사할 수 있다.

상태 갱신

상태 갱신(state update)은 현재 상태에 규칙이나 행동을 적용해 새로운 상태를 만드는 과정이다. 보드 퍼즐에서는 다음 구조가 반복된다.

현재 보드 상태
→ 규칙 적용
→ 후보 제거 또는 확정
→ 새 보드 상태
→ 모순 검사
→ 다음 규칙 적용

알고리즘적으로는 다음과 같이 표현할 수 있다.

state_t -> transition(rule, action) -> state_{t+1}

여기서 중요한 점은 새 상태가 이전 상태와 독립적으로 다시 쓰이는 텍스트가 아니라, 이전 상태에서 계산적으로 도출된 결과라는 것이다.

맥락과 상태의 차이

맥락은 “읽히는 정보”이고, 상태는 “갱신되는 정보”다. 맥락은 길어질 수 있고, 상태는 구조화될 수 있다. 맥락은 모델의 입력 토큰 배열에 머물지만, 상태는 배열, 그래프, 집합, 데이터베이스 레코드, 제약식, 체크포인트처럼 외부 시스템이나 프로그램 내부에서 명시적으로 유지될 수 있다.

이 구분은 LLM의 오류를 이해하는 핵심이다. 보드가 맥락 안에 있다는 사실은 보드가 정확한 자료구조로 관리된다는 뜻이 아니다. LLM이 “A2는 안전하다”고 말한 뒤 다음 문단에서 A2를 다시 지뢰 후보로 취급할 수 있는 이유는, 그 결론이 명시적 상태 전이에 의해 고정된 값으로 저장·검증되지 않았기 때문이다.

배경과 맥락

Transformer 원 논문인 Vaswani 등 「Attention Is All You Need」는 sequence transduction을 위해 recurrence와 convolution을 제거하고 attention mechanism에 기반한 구조를 제안했다. 이 논문은 오늘날 LLM 논의의 핵심 배경이지만, 원래 논문의 Transformer는 encoder-decoder 구조이고, 현재 대화형 LLM에서 널리 쓰이는 autoregressive decoder-only 모델과 완전히 동일한 구조는 아니다. 따라서 이 글에서 말하는 “LLM의 생성 한계”는 주로 많은 현대 autoregressive decoder-only LLM의 생성 과정에 대한 설명으로 이해하는 편이 안전하다.

Autoregressive LLM은 주어진 이전 토큰들을 바탕으로 다음 토큰의 확률분포를 계산한다. 이 구조는 언어 생성, 요약, 설명, 코드 작성, 계획 초안 작성, 패턴 인식에서 많은 경우 유용하다. 동시에 이 구조는 알고리즘 실행기와 다르다. 알고리즘 실행기는 명시적 변수, 분기, 반복문, 스택, 큐, 그래프, 해시 테이블, 제약 솔버를 사용해 상태를 갱신한다. LLM은 그런 구조를 텍스트 안에서 묘사할 수 있지만, 모델 단독 생성만으로 그 구조가 항상 충실히 실행된다고 보장할 수는 없다.

KV cache도 이 차이를 보여 준다. Hugging Face Transformers 문서는 KV cache를 이전 계산을 저장해 재계산하지 않도록 하는 추론 최적화 장치로 설명한다. 즉 KV cache는 이전 토큰의 key/value 관련 계산을 재사용해 생성 속도를 높이는 장치이지, 지뢰찾기 보드의 확정 칸이나 남은 지뢰 수를 검증 가능한 변수로 저장하는 장기 의미 기억은 아니다. KV cache는 “모델이 이전 토큰을 처리할 때 만든 attention 계산 결과를 효율적으로 재사용한다”는 의미의 상태일 수 있지만, 퍼즐 풀이에 필요한 “문제 상태”와는 기능이 다르다.

핵심 논리

1. LLM의 텍스트 생성은 상태 전이 알고리즘과 다르다

퍼즐 풀이 알고리즘은 보통 상태 전이를 중심으로 설계된다. 지뢰찾기라면 각 칸의 상태, 주변 숫자, 후보 지뢰 집합, 남은 지뢰 수, 이미 안전하다고 확정된 칸을 구조화한다. 이후 규칙을 적용해 상태를 갱신한다.

반면 LLM은 입력 텍스트를 바탕으로 다음 텍스트를 생성한다. 이 과정에서 모델은 통계적으로 학습된 패턴, 현재 문맥, 내부 활성화, attention 계산을 활용한다. 복잡한 문제에서도 상당한 추론처럼 보이는 출력을 만들 수 있다. 그러나 출력이 명시적 자료구조에 쓰이고, 이후 단계에서 그 자료구조를 기준으로 일관성 검사를 받는 구조가 기본적으로 내장되어 있는 것은 아니다.

따라서 다음 두 과정은 겉으로 비슷해 보여도 계산적으로 다르다.

알고리즘:
board = update(board, rule)
assert consistent(board)

LLM 단독 생성:
보드 설명 텍스트 → 다음 설명 텍스트 생성

첫 번째 과정에서는 상태가 자료구조로 갱신된다. 두 번째 과정에서는 상태 갱신이 텍스트 서술 안에서 암묵적으로 이루어진다. 암묵적 서술은 간단한 경우 충분히 맞을 수 있지만, 여러 제약을 동시에 추적해야 할수록 누락과 모순의 위험이 커진다.

2. 오류 원인은 단일하지 않지만 핵심 취약점은 분명하다

LLM이 퍼즐에서 틀리는 원인을 “명시적 상태 갱신 알고리즘의 부재” 하나로만 설명하면 과도한 단순화가 된다. 실제 오류에는 여러 요인이 함께 작용한다. 훈련 데이터 분포, 보드 표기 방식, 공간 관계를 토큰 시퀀스로 표현할 때의 손실, 위치 인코딩과 공간 표상의 한계, 샘플링 방식, 프롬프트 형식, 모델 크기, 검증 루프 유무, 도구 사용 여부 등이 모두 영향을 줄 수 있다.

Minesweeper를 이용해 LLM의 논리 퍼즐 풀이를 평가한 Li, Wang, Zhang의 연구도 LLM이 셀 상태, 숫자 힌트, 공간 관계, 행동 전략을 통합해야 한다고 설명한다. 이 연구는 GPT-4 같은 강한 모델도 일관된 다단계 논리 추론에서 어려움을 보였다고 보고한다. 여기서 얻을 수 있는 보수적 결론은 다음이다. LLM의 퍼즐 오류는 여러 요인의 결합으로 발생하지만, 작은 보드와 충분한 입력 길이에서도 반복적으로 나타나는 핵심 취약점 중 하나는 명시적 상태 표현, 상태 전이, 정합성 검증이 기본 생성 구조에 강제되어 있지 않다는 점이다.

이 문장이 이 글의 중심 주장이다.

3. “상태가 없다”는 말은 층위를 구분해야 한다

LLM에 “상태가 없다”고 말할 때는 주의가 필요하다. 적어도 네 가지 층위가 있다.

첫째, 모델 가중치(model weights)는 학습된 장기 파라미터다. 이것은 훈련 과정에서 만들어진 통계적 지식의 저장 방식이지만, 특정 퍼즐의 현재 보드 상태는 아니다.

둘째, forward pass 중 hidden activation은 현재 입력을 처리하면서 생기는 내부 계산 상태다. 이것은 다음 토큰 분포를 만드는 데 사용되지만, 사용자가 직접 읽고 수정할 수 있는 보드 배열은 아니다.

셋째, KV cache는 autoregressive generation에서 과거 토큰의 key/value 계산을 재사용하는 추론 최적화 장치다. 이것은 계산 효율을 위한 캐시이지, 문제 풀이 상태를 검증 가능한 방식으로 저장하는 기호 메모리는 아니다.

넷째, 애플리케이션 계층의 session, conversation state, memory, database, vector store, checkpointer는 모델 바깥의 상태 저장 장치다. 예를 들어 OpenAI Agents SDK의 Sessions는 agent run 사이의 대화 기록을 저장하는 client-side session memory를 제공하고, OpenAI server-managed continuation은 conversation_id나 previous_response_id 같은 방식으로 대화 흐름을 이어갈 수 있다. 이들은 대화 이력을 유지하는 데 유용하지만, 그 자체가 지뢰찾기나 스도쿠의 제약 솔버는 아니다.

따라서 더 정확한 표현은 “LLM에는 아무 상태도 없다”가 아니라 “LLM의 기본 생성 구조에는 특정 문제의 상태를 명시적 자료구조로 유지하고 규칙에 따라 검증 가능하게 갱신하는 알고리즘이 강제되어 있지 않다”이다.

구체적 사례

지뢰찾기

지뢰찾기에서는 각 숫자 칸이 주변 8칸에 있는 지뢰 수를 제약한다. 예를 들어 어떤 숫자 1 주변에 미확인 칸이 A와 B뿐이라면 다음 제약이 생긴다.

A + B = 1

다른 숫자 1 주변에 미확인 칸이 B뿐이라면 다음 제약이 생긴다.

B = 1

알고리즘은 두 제약을 결합해 다음 결론을 낸다.

B = 1
A = 0

이 과정은 선형 제약식, 후보 집합, constraint propagation으로 처리할 수 있다. 결론이 나오면 상태가 갱신된다.

mines.add("B")
safe.add("A")
unknown.remove("A")
unknown.remove("B")
remaining_mines -= 1

LLM도 이 과정을 설명할 수 있다. 짧고 단순한 문제에서는 올바르게 푼다. 그러나 보드가 조금 복잡해지고 여러 숫자 칸의 제약을 동시에 비교해야 하면, 텍스트 설명 중 일부 조건을 빠뜨리거나, 이미 확정한 후보를 다시 후보로 취급하거나, 전체 남은 지뢰 수 조건을 반영하지 않는 오류가 발생할 수 있다. 이 오류는 “보드를 못 봐서”라기보다 “보드 상태가 갱신 가능한 구조로 고정되지 않아서” 발생하는 경우가 많다.

스도쿠

스도쿠도 같은 구조를 가진다. 각 칸은 행, 열, 3x3 박스 제약을 동시에 만족해야 한다. 알고리즘은 각 칸의 후보 집합을 유지한다.

candidates[(r, c)] = {1, 2, 3, 4, 5, 6, 7, 8, 9}

숫자가 하나 확정되면 같은 행·열·박스의 후보에서 제거한다.

for cell in peers[(r, c)]:
    candidates[cell].discard(value)

LLM은 “이 칸에는 5가 들어갈 수 없다” 같은 단일 규칙을 설명할 수 있다. 그러나 수십 개 후보 집합을 안정적으로 유지하면서 여러 단계에 걸쳐 갱신하는 것은 모델 단독 생성에 부담이 된다. 그래서 스도쿠를 안정적으로 풀려면 LLM에게 설명을 맡기고, 후보 집합 유지와 탐색은 별도 solver에 맡기는 설계가 더 견고하다.

코드 실행과 수치 계산

다음과 같은 산술 문제를 생각해 보자.

12명이 각각 7개의 상자를 갖고 있고, 각 상자에는 9개의 물건이 있다. 전체 물건 수는?

LLM은 답을 직접 텍스트로 계산할 수 있다. 그러나 복잡한 수식, 반복 계산, 금융 표, 날짜 연산에서는 중간 계산 실수가 생길 수 있다. Program-of-Thought나 PAL은 이 지점을 분리한다. LLM은 문제를 코드로 변환하고, 계산은 Python interpreter 같은 runtime에 맡긴다.

people = 12
boxes_per_person = 7
items_per_box = 9
total = people * boxes_per_person * items_per_box
print(total)

여기서 핵심은 “모델이 더 똑똑해진다”가 아니라 “계산의 책임을 확률적 텍스트 생성에서 결정적 실행기로 옮긴다”는 점이다.

보완 접근의 층위 구분

Tool Use

Tool Use는 LLM이 직접 모든 계산을 수행하지 않고 외부 도구를 호출하게 하는 방식이다. 계산기, 검색 엔진, 데이터베이스, 코드 실행기, 캘린더, 파일 시스템, 사내 API 등이 도구가 될 수 있다. Toolformer는 모델이 어떤 API를 언제 호출하고, 어떤 인자를 넘기며, 결과를 어떻게 다음 토큰 예측에 반영할지 학습하는 접근으로 제안되었다.

Tool Use의 장점은 명확하다. 산술 계산, 최신 정보 조회, 데이터베이스 검색, 파일 조작, 코드 실행 같은 작업을 전문 시스템에 맡길 수 있다. 한계도 명확하다. 도구 선택이 틀릴 수 있고, 인자가 잘못될 수 있으며, 도구 결과를 해석하는 과정에서 오류가 생길 수 있다. 도구를 붙인다고 곧바로 전체 시스템의 정합성이 보장되지는 않는다.

Program-of-Thought와 PAL

Program-of-Thought는 reasoning과 computation을 분리하려는 접근이다. LLM은 자연어 문제를 프로그램 형태로 표현하고, 실제 계산은 외부 컴퓨터가 실행한다. PAL도 비슷하게 LLM이 자연어 문제를 Python 같은 실행 가능한 코드로 바꾸고, 해결 단계는 interpreter에 위임한다.

이 방식은 산술, 표 계산, 반복문, 조건문, 알고리즘 문제에서 특히 유용하다. LLM이 중간 계산을 텍스트로 수행할 때보다 코드 실행기가 더 안정적이기 때문이다. 다만 코드 생성 자체가 틀릴 수 있다. 문제 해석이 잘못되면 실행 결과가 정확해도 정답은 틀린다. 따라서 PoT/PAL은 계산 오류를 줄이는 방식이지, 문제 이해 오류까지 자동으로 제거하는 방식은 아니다.

ReAct

ReAct는 reasoning trace와 action을 교차시키는 방식이다. 모델은 내부적으로 문제를 해석하고, 필요한 경우 외부 지식원이나 환경에 action을 취하며, observation을 다시 추론에 반영한다. 이 구조는 질문 답변, 사실 검증, 웹 탐색, 환경 상호작용에서 유용하게 쓰일 수 있다.

ReAct의 핵심은 모델이 단일 응답을 한 번에 생성하는 대신, 추론과 행동을 번갈아 수행한다는 점이다. 이 구조는 상태 추적을 어느 정도 개선할 수 있다. 그러나 ReAct도 상태 갱신을 완전히 보장하는 알고리즘은 아니다. action 기록과 observation이 다시 문맥으로 들어가더라도, 그 정보가 명시적 자료구조로 관리되지 않으면 여전히 누락과 모순이 생길 수 있다.

LangGraph 같은 상태 기반 오케스트레이션

LangGraph는 LLM 자체의 구조라기보다, 장기 실행·상태ful agent·워크플로를 만들기 위한 오케스트레이션 프레임워크다. 공식 문서는 LangGraph를 long-running, stateful agents를 만들고 관리·배포하기 위한 low-level orchestration framework로 설명한다. LangGraph의 StateGraph는 노드들이 공유 상태를 읽고 쓰는 방식으로 동작하며, 각 노드는 정의된 State를 입력으로 받고 Partial State를 반환할 수 있다.

이 구조는 LLM 단독 생성과 다르다. 작업 상태를 별도 객체로 두고, 각 단계에서 그 상태를 갱신하며, checkpointer나 persistence layer를 통해 중간 상태를 저장·복원할 수 있다. 따라서 복잡한 작업을 안정화하려는 시스템 설계에서는 LLM을 “모든 것을 직접 계산하는 단일 모델”로 두기보다 “상태 기반 워크플로 안에서 판단·생성·도구 호출을 수행하는 구성 요소”로 배치하는 방식이 늘고 있다.

MCP

MCP, 즉 Model Context Protocol은 LLM 애플리케이션과 외부 시스템을 연결하기 위한 공개 표준이다. 공식 문서는 MCP를 AI applications가 데이터 소스, 도구, 워크플로에 연결되도록 돕는 open-source standard로 설명한다. MCP는 자체적으로 퍼즐을 풀거나 상태를 검증하는 알고리즘이 아니다. 대신 도구·데이터·프롬프트를 표준화된 방식으로 노출하고 연결하는 프로토콜이다.

따라서 MCP를 Tool Use, PoT, LangGraph, neuro-symbolic AI와 같은 범주로 놓으면 층위가 섞인다. MCP는 연결 계층에 가깝고, LangGraph는 상태 기반 워크플로 계층에 가깝고, PoT/PAL은 프로그램 실행 위임 방식이며, neuro-symbolic AI는 연구 패러다임이다. 이 구분을 유지해야 기술 설명이 정확해진다.

Neuro-symbolic AI

Neuro-symbolic AI는 신경망의 학습 능력과 기호 시스템의 명시적 표현·논리·규칙·추론 능력을 결합하려는 연구 방향이다. 중요한 점은 모든 도구 사용이나 모든 RAG가 곧 neuro-symbolic AI인 것은 아니라는 점이다. Mättas, Järv, Tammet의 neurosymbolic AI survey submission은 명시적 의미를 가진 symbolic structure가 학습이나 추론에 직접 참여하는 경우를 neuro-symbolic 접근으로 보고, 단순 retrieval이나 external tool use는 인접 맥락으로 구분하려는 기준을 제시한다. 이 원고는 2026년 5월 현재 Neurosymbolic Artificial Intelligence 저널 사이트에서 Major Revision 상태로 확인되므로, 최종 게재 논문처럼 인용하기보다 심사 중 survey submission으로 표기하는 편이 안전하다.

Neuro-symbolic AI는 LLM의 상태 갱신 문제에 더 근본적으로 접근할 수 있다. 예를 들어 신경망이 자연어와 패턴을 해석하고, 기호 시스템이 규칙·제약·논리식을 다루며, 양자가 상호작용하는 구조를 만들 수 있다. 다만 이 분야도 아직 해결된 단일 기술이라기보다 여러 접근이 경쟁하고 있는 연구 영역이다. Colelough와 Regli의 systematic review는 2020년 이후 neuro-symbolic AI 연구가 활발해졌고, learning and inference, logic and reasoning, knowledge representation, explainability and trustworthiness 같은 축에서 연구가 진행되고 있음을 정리한다. 해당 자료는 arXiv 2025판과 CEUR Workshop Proceedings 수록본이 확인된다.

주요 쟁점과 반론

LLM도 내부 상태가 있지 않은가

있다. 그래서 “LLM은 상태가 없다”라는 표현은 압축적이지만 불완전하다. 모델에는 hidden activation, attention 계산, KV cache가 있다. 대화형 제품에는 conversation state나 session memory도 붙을 수 있다. 문제는 그 상태가 무엇을 위해 존재하느냐다.

퍼즐 풀이에 필요한 상태는 문제 세계의 상태다. 예를 들어 “A2는 안전한 칸으로 확정되었다”, “B3은 지뢰 후보에서 제외되었다”, “현재 남은 지뢰 수는 2다”, “이 제약식과 저 제약식은 동시에 만족되어야 한다” 같은 구조다. LLM 내부의 activation이나 KV cache는 이런 기호적 상태를 사용자가 직접 읽고 수정할 수 있는 자료구조로 제공하지 않는다.

따라서 반론을 반영한 더 정확한 결론은 다음이다. LLM에는 계산 과정상의 내부 상태가 있지만, 그 상태는 일반적으로 특정 문제의 명시적·검증 가능·갱신 가능한 자료구조와 동일하지 않다.

프롬프트를 잘 쓰면 해결되는가

프롬프트는 많은 오류를 줄일 수 있다. 보드를 표 형식으로 제공하고, 단계별 후보 집합을 쓰게 하고, 매 단계마다 검증을 요구하고, 결론을 내기 전에 전체 조건을 재검토하게 하면 성능이 좋아질 수 있다. 그러나 프롬프트는 상태 갱신을 텍스트 안에서 더 명시적으로 흉내 내게 하는 방식이다. 실제 자료구조와 solver가 붙은 것과 같은 보장은 제공하지 않는다.

프롬프트 기반 해결은 “작은 문제를 더 잘 풀게 하는 실용적 방법”으로 이해해야 한다. 복잡하고 오류 비용이 큰 작업에서는 외부 계산기, 코드 실행기, constraint solver, database, workflow state, 테스트 루프를 결합하는 편이 더 안전하다.

모델이 커지면 해결되는가

모델 크기와 학습 데이터, 추론 기법이 개선되면 상태 추적 능력은 향상될 수 있다. 실제로 대형 모델은 작은 모델보다 긴 문맥 처리, 패턴 일반화, 코드 생성, 추론 형식 모방에서 더 좋은 성능을 보이는 경우가 많다. 그러나 모델이 커진다고 해서 명시적 상태 전이와 정합성 검증이 자동으로 생기는 것은 아니다.

특히 오류 비용이 큰 영역에서는 “잘할 가능성이 높다”와 “검증 가능하게 보장된다”를 구분해야 한다. 수학 증명, 프로그램 실행, 회계 계산, 법률 절차, 의료 판단, 안전 제어처럼 정합성 요구가 높은 작업에서는 모델 규모보다 상태 관리와 검증 구조가 더 중요해질 수 있다.

Tool Use가 만능인가

Tool Use는 강력하지만 만능은 아니다. 도구 호출형 시스템에서는 새로운 오류 지점이 생긴다. 어떤 도구를 선택할지, 어떤 인자를 넣을지, 도구 결과가 무엇을 의미하는지, 도구 결과와 기존 문맥이 충돌할 때 어떻게 처리할지, 도구 호출 권한과 보안을 어떻게 관리할지가 모두 문제가 된다.

따라서 안정적인 설계는 단순히 “도구를 붙인다”가 아니라 다음 구조를 요구한다.

문제 해석
→ 상태 표현
→ 도구 선택
→ 도구 실행
→ 결과 검증
→ 상태 갱신
→ 다음 행동 결정

이 구조에서 LLM은 자연어 해석, 계획 생성, 결과 설명, 예외 처리에 유용하다. 계산과 검증은 가능한 한 결정적 시스템이나 명시적 검사기에 맡기는 편이 안전하다.

오해와 한계

첫 번째 오해는 “컨텍스트가 작아서 못 푼다”는 설명이다. 컨텍스트 부족은 실제 원인일 수 있다. 긴 문서, 긴 코드베이스, 긴 대화에서는 문맥 길이와 attention 분포가 성능에 영향을 준다. 그러나 작은 보드에서도 오류가 난다면 문제는 입력 길이만이 아니다. 이때는 상태 표현과 갱신 구조를 봐야 한다.

두 번째 오해는 “LLM은 아무것도 계산하지 않는다”는 설명이다. LLM은 복잡한 행렬 연산을 통해 입력을 처리하고, 많은 경우 유용한 추론처럼 보이는 결과를 생성한다. 문제는 계산의 존재 여부가 아니라 계산의 형식이다. LLM의 계산은 확률적 언어 생성에 최적화되어 있고, 알고리즘 실행기처럼 명시적 변수와 검증 루프를 기본 단위로 삼지 않는다.

세 번째 오해는 “외부 도구를 붙이면 문제가 사라진다”는 설명이다. 도구는 계산 오류를 줄이고 최신 정보 접근을 가능하게 하지만, 도구 호출과 결과 해석도 별도의 설계 문제다. Tool Use는 상태 갱신 문제의 해결책 중 하나지만, 완결된 보증 체계는 아니다.

네 번째 오해는 “neuro-symbolic AI는 곧 LLM + 검색 또는 LLM + 도구”라는 설명이다. 최근 survey submission들이 지적하듯, neuro-symbolic AI를 엄밀하게 보려면 명시적 의미를 가진 symbolic structure와 reasoning operator가 학습이나 추론에 직접 참여해야 한다. 단순히 외부 문서를 검색하거나 API를 호출하는 것은 neuro-symbolic AI와 인접하지만 동일하지 않을 수 있다.

이 글의 한계도 있다. 여기서는 LLM 내부 표현이 실제로 어떤 형태의 구조적 정보를 담는지, 특정 모델이 보드 게임을 어느 정도까지 학습했는지, 최신 reasoning model이 어떤 벤치마크에서 얼마나 개선되었는지를 세부적으로 비교하지 않았다. 또한 LLM의 상태 추적 실패를 하나의 보편 법칙으로 단정하지 않는다. 모델, 프롬프트, 도구, 환경, 평가 방식에 따라 성능은 달라진다. 이 글의 목적은 “컨텍스트 크기”와 “상태 갱신 구조”를 구분하는 개념적 설명을 제공하는 것이다.

설계적 결론

복잡한 상태 추적 작업을 안정화하려는 시스템 설계에서는 LLM을 단독 계산기로 두는 것보다 역할을 분리하는 편이 더 견고하다. LLM은 문제를 해석하고, 가능한 접근을 제안하고, 도구 호출을 계획하고, 결과를 설명하는 데 강점을 가진다. 반면 상태 저장, 후보 집합 갱신, 제약 만족 검사, 산술 계산, 코드 실행, 데이터베이스 조회는 외부 시스템에 맡기는 편이 안정적이다.

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

LLM: 문제 해석과 계획
상태 저장소: 현재 상태 유지
도구/solver: 계산과 검증
오케스트레이터: 단계 전환과 체크포인트 관리
LLM: 결과 설명과 다음 행동 제안

도구 결합형 에이전트 시스템에서는 LLM이 단독 계산기라기보다 orchestration layer의 일부로 쓰이는 경향이 있다. 다만 이 표현도 모든 LLM 사용 사례에 적용되는 일반 명제는 아니다. 단순 질의응답, 창작, 요약, 설명 생성에서는 LLM 단독 사용이 충분할 수 있다. 상태 추적과 정합성 보장이 중요한 작업에서만 외부 상태·도구·검증 구조의 필요성이 커진다.

정리

보드 상태는 맥락이다. 토큰 수가 작다면 컨텍스트 용량 문제도 아닐 수 있다. 그러나 보드가 맥락 안에 있다는 사실은 보드가 알고리즘적 상태로 유지된다는 뜻이 아니다. LLM의 기본 생성 구조는 텍스트를 읽고 다음 토큰을 생성하는 방식이며, 명시적 변수, 후보 집합, 제약식, 상태 전이, 검증 루프를 자동으로 강제하지 않는다.

따라서 “맥락 크기가 아니라 명시적 상태 갱신 알고리즘이 없는 구조가 문제다”라는 진단은 매우 유효하다. 다만 이를 절대화해서 “LLM은 상태가 없다”거나 “모든 오류의 유일한 원인은 상태 갱신 부재다”라고 말하면 부정확해진다. 더 안전한 결론은 다음이다.

LLM의 퍼즐 오류는 여러 요인의 결합으로 발생하지만, 작은 보드와 충분한 입력 길이에서도 반복적으로 나타나는 핵심 취약점 중 하나는 명시적 상태 표현, 상태 전이, 정합성 검증이 기본 생성 구조에 강제되어 있지 않다는 점이다. 이 취약점을 줄이기 위해서는 LLM을 외부 계산기, 프로그램 실행기, 제약 솔버, 상태 기반 워크플로, 도구 연결 프로토콜, 기호 추론 시스템과 결합하는 설계가 필요하다. 이것은 “컨텍스트를 더 크게 만드는 문제”가 아니라 “언어 생성과 상태 갱신을 분리하고 다시 결합하는 시스템 설계 문제”다.

참고자료

  • Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, Illia Polosukhin, “Attention Is All You Need,” NeurIPS, 2017. https://arxiv.org/abs/1706.03762
  • Hugging Face, “Cache strategies,” Transformers Documentation, 확인일 2026-05-06. https://huggingface.co/docs/transformers/en/kv_cache
  • Yinghao Li, Haorui Wang, Chao Zhang, “Assessing Logical Puzzle Solving in Large Language Models: Insights from a Minesweeper Case Study,” NAACL 2024 / arXiv 2023. https://arxiv.org/abs/2311.07387
  • Wenhu Chen, Xueguang Ma, Xinyi Wang, William W. Cohen, “Program of Thoughts Prompting: Disentangling Computation from Reasoning for Numerical Reasoning Tasks,” arXiv, 2022. https://arxiv.org/abs/2211.12588
  • Luyu Gao, Aman Madaan, Shuyan Zhou, Uri Alon, Pengfei Liu, Yiming Yang, Jamie Callan, Graham Neubig, “PAL: Program-aided Language Models,” arXiv, 2022. https://arxiv.org/abs/2211.10435
  • Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom, “Toolformer: Language Models Can Teach Themselves to Use Tools,” arXiv, 2023. https://arxiv.org/abs/2302.04761
  • Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, “ReAct: Synergizing Reasoning and Acting in Language Models,” arXiv, 2022. https://arxiv.org/abs/2210.03629
  • LangChain AI, “LangGraph,” GitHub repository and documentation, 확인일 2026-05-06. https://github.com/langchain-ai/langgraph
  • LangChain AI, “StateGraph,” LangGraph.js API Reference, 확인일 2026-05-06. https://langchain-ai.github.io/langgraphjs/reference/classes/langgraph.StateGraph.html
  • Model Context Protocol, “What is the Model Context Protocol (MCP)?,” 공식 문서, 확인일 2026-05-06. https://modelcontextprotocol.io/docs/getting-started/intro
  • Model Context Protocol, “Architecture overview,” 공식 문서, 확인일 2026-05-06. https://modelcontextprotocol.io/docs/learn/architecture
  • 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/
  • Brandon C. Colelough, William Regli, “Neuro-Symbolic AI in 2024: A Systematic Review,” arXiv 2025 / CEUR Workshop Proceedings 수록본 확인. https://arxiv.org/abs/2501.05435
  • Brandon C. Colelough, William Regli, “Neuro-Symbolic AI in 2024: A Systematic Review,” CEUR Workshop Proceedings, 2024/2025 수록본 확인. https://ceur-ws.org/Vol-3819/paper3.pdf
  • Zishen Wan, Che-Kai Liu, Hanchen Yang, Chaojian Li, Haoran You, Yonggan Fu, Cheng Wan, Tushar Krishna, Yingyan Lin, Arijit Raychowdhury, “Towards Cognitive AI Systems: a Survey and Prospective on Neuro-Symbolic AI,” arXiv, 2024. https://arxiv.org/abs/2401.01040
  • Otto Mättas, Priit Järv, Tanel Tammet, “A survey of neurosymbolic artificial intelligence: foundations, advances, and future trajectories,” Neurosymbolic Artificial Intelligence, survey submission, 2026년 5월 현재 Major Revision 상태로 확인. https://neurosymbolic-ai-journal.com/paper/survey-neurosymbolic-artificial-intelligence-foundations-advances-and-future-trajectories