[Paper] 대형 언어 모델에서 선천적 계획의 한계에 대하여

Source: arXiv - 2511.21591v1

Overview

대형 언어 모델(LLM)은 코드를 생성하고, 질문에 답하며, 퍼즐을 푸는 능력으로 우리를 놀라게 했지만, 스스로 계획을 얼마나 잘 세우는지는 아직 불분명합니다. 이 논문은 LLM을 고전적인 8‑퍼즐에 적용해, 모델이 변하는 보드 상태를 추적하고 외부 계산 없이 목표까지의 경로를 설계하도록 강제합니다. 저자들은 교묘한 프롬프트 기법에도 불구하고, 현재의 LLM은 “본능적인” 추론만으로는 기본적인 계획 수립에 여전히 어려움을 겪는다는 것을 발견했습니다.

Key Contributions

• 계획에 대한 체계적 평가: 상태 기반 추론을 위한 깔끔하고 단계별 벤치마크인 8‑퍼즐을 사용.
• 네 가지 주요 LLM 비교(GPT‑4‑급 모델 및 오픈소스 대안 포함)와 세 가지 프롬프트 스타일: Zero‑Shot, Chain‑of‑Thought (CoT), Algorithm‑of‑Thought (AoT).
• 계층형 교정 피드백 실험: 모델이 잘못된 움직임이라고 알려졌을 때 움직임을 수정하도록 함.
• 외부 “움직임 검증기” 도입: 합법적인 움직임만 제공하여 최소한의 도구 지원이 격차를 메울 수 있는지 테스트.
• 정성적 분석: 두 가지 반복적인 실패 유형을 식별—불안정한 내부 상태 표현과 루프 혹은 비진전적 움직임을 초래하는 약한 휴리스틱 계획.

Methodology

1. Task selection – 8‑퍼즐(3×3 보드에서 타일을 슬라이드하는 퍼즐)은 모든 움직임을 검증할 수 있고, 최적 해의 길이가 알려져 있으며, 명시적인 상태 추적이 필요한 문제이기 때문에 선택되었습니다.
2. Prompting regimes –
   • Zero‑Shot: 퍼즐을 해결하라는 단일 지시문.
   • Chain‑of‑Thought: 모델에게 “소리 내어 생각”하도록 요청하고 중간 보드 상태를 나열하게 함.
   • Algorithm‑of‑Thought: 프롬프트에 고수준 알고리즘 골격을 제공(예: “해결되지 않을 때까지 빈 타일을 목표 위치로 이동”).
3. Feedback loops – 각 생성된 움직임 후 시스템이 유효성을 검사합니다. 움직임이 불법이면 모델에게 교정 메시지를 전달하고, 정해진 시도 횟수까지 다시 시도하게 합니다.
4. Move validator condition – 보조 모듈이 현재 보드에 대해 가능한 합법적 움직임 집합만 제공하여 모델이 제한된 행동 공간에서 선택하도록 강제합니다.
5. Metrics – 성공률(퍼즐 해결 여부), 평균 단계 수, 계산 비용(생성된 토큰 수).

Results & Findings

• Baseline performance(피드백 없음)는 전반적으로 낮았으며, 모델 및 프롬프트 스타일에 따라 성공률이 2 %에서 9 % 사이였습니다.
• Corrective feedback은 일부 조합에서 성공률을 높였지만(예: CoT를 사용한 GPT‑4는 ~22 %까지 상승), 많은 추가 토큰이 소모되고 종종 길고 간접적인 추론 체인을 동반했습니다.
• Move validator—모델에게 합법적인 행동만 제공했음에도 어떠한 퍼즐도 해결하지 못함. 모델은 움직임을 반복하거나 루프에 빠지거나 보드를 목표에 가깝게 만들지 못하는 행동을 선택했습니다.
• Failure analysis는 두 가지 주요 결함을 드러냈습니다:
  1. Brittle internal state – 모델이 현재 보드 구성을 자주 “잊어버려” 불법 움직임을 발생시킴.
  2. Weak heuristics – 명시적인 탐색이나 거리 메트릭이 없어서 움직임 선택이 거의 무작위이거나 역효과를 냄.

Practical Implications

• Tool‑augmented agents: 계획을 위해 LLM의 내부 추론에만 의존하는 것은 위험합니다(예: UI 워크플로를 자동화하는 자율 에이전트). 외부 상태 추적기나 탐색 모듈을 추가하는 것이 필수적입니다.
• Prompt engineering limits: CoT와 AoT가 행동을 개선할 수는 있지만, 체계적인 계획 구성 요소를 대체할 수는 없습니다. 프롬프트는 가이드일 뿐, 정확성을 보장하지 못한다는 점을 개발자는 인식해야 합니다.
• Cost considerations: 반복 피드백에 따른 토큰 오버헤드는 특히 실시간 애플리케이션에서 비용을 급격히 증가시킬 수 있습니다.
• Design of AI assistants: 코드 리팩토링, UI 자동화, 게임 AI와 같은 작업에서는 순수 언어‑전용 파이프라인보다 LLM과 가벼운 플래너(예: A* 탐색)를 결합하는 것이 더 신뢰할 수 있는 결과를 제공합니다.

Limitations & Future Work

• Scope of tasks – 연구는 단일하고 잘 알려진 퍼즐에만 초점을 맞추었으며, 상태 표현이 더 복잡한 도메인에서는 결과가 다를 수 있습니다.
• Model selection – 네 가지 모델만 조사했으며, 최신 또는 계획에 특화된 LLM은 다른 행동을 보일 수 있습니다.
• Feedback depth – 교정 루프는 제한된 시도 횟수로 제한되었습니다; 더 깊은 반복 정제가 성공률을 높일 수 있지만 비용도 상승합니다.
• Future directions(저자 제안):
  • 구조화된 프롬프트나 메모리 모듈을 통해 LLM 컨텍스트에 명시적 상태 변수를 삽입.
  • 클래식 탐색 알고리즘이나 미분 가능한 플래너와 LLM을 결합.
  • 시각적 보드 스냅샷과 같은 다중 모달 피드백을 탐색해 상태 기반을 강화.

Bottom line: LLM은 뛰어난 스토리텔러이지만, 외부 도구 없이 규칙적인 단계별 계획을 수행하는 데는 아직 부족합니다. 자율 시스템을 구축하는 개발자에게는 언어 모델을 전용 계획 도구와 결합하는 것이 견고하고 실용적인 성능을 달성하는 핵심이라는 점이 명확합니다.

Authors

• Charles Schepanowski
• Charles Ling

Paper Information

• arXiv ID: 2511.21591v1
• Categories: cs.AI
• Published: November 26, 2025
• PDF: Download PDF