[arXiv 2605.00817] LLM이 절차 수행을 멈출 때: 정답률 너머의 단계 실행 진단

When LLMs Stop Following Steps: A Diagnostic Study of Procedural Execution in Language Models

원문: https://arxiv.org/abs/2605.00817 / HTML: https://arxiv.org/html/2605.00817v1

저자/소속: Sailesh Panda, Pritam Kadasi, Mayank Singh | Indian Institute of Technology Gandhinagar; Abhishek Upperwal | Soket AI / arXiv 제출일: 2026년 5월 1일

---

1. 서론: 정답을 맞히는 모델과 절차를 끝까지 실행하는 모델 사이

1.1 문제의 출발점: 최종 답안 정확도만으로는 보이지 않는 실패

이 논문은 대규모 언어 모델이 수학 문제나 추론 벤치마크에서 높은 점수를 보이더라도, 프롬프트에 명시된 단계별 절차를 실제로 끝까지 수행했는지는 별개의 문제라고 주장한다. 많은 평가에서는 마지막 숫자가 맞았는지만 본다. 그러나 실제 업무에서 사용자는 모델이 우연히 그럴듯한 값을 내놓는 것보다, 주어진 규칙을 차례로 적용하고 중간 상태를 보존하며 지정된 시점에 멈추는지를 더 중요하게 여긴다.

논문이 겨냥하는 핵심 개념은 procedural execution, 즉 명시된 절차 실행 능력이다. 여기서 절차는 모호한 자연어 지시와 달리, $x$와 $y$라는 두 입력에서 시작해 $S_1=x$, $S_2=y$를 두고 이후 $S_3, S_4, \dots$를 사칙연산으로 계산하는 알고리즘이다. 모델은 설명을 읽고 각 단계를 수행한 뒤 마지막 값을 소수 셋째 자리까지 반올림해 반환해야 한다.

이 설정이 흥미로운 이유는 문제 자체가 상식 추론, 긴 문맥 이해, 외부 지식 검색과 거의 무관하다는 점이다. 각 단계의 연산은 초등적인 덧셈, 뺄셈, 곱셈, 나눗셈이다. 그런데도 절차가 길어지고 과거 중간값을 다시 참조해야 하면 모델 성능이 크게 흔들린다. 따라서 이 논문은 산술 난이도보다 절차 상태 추적을 전면에 내세운다.

저자들은 14개 모델을 55개 데이터셋, 총 55,000개 예제에서 평가한다. 평균 first-answer accuracy는 5-step 절차에서 61%였지만 95-step 절차에서는 20%로 떨어졌다. 이 하락은 단순한 실수의 누적만으로 설명하기 어렵다. 생성 로그를 보면 답을 아예 형식에 맞게 내놓지 않거나, 너무 일찍 답을 제출하거나, 중간에 틀린 답을 냈다가 나중에 고치거나, 필요한 단계보다 적게 실행한 흔적이 반복적으로 나타난다.

결국 논문의 질문은 “LLM이 추론하는가”라는 넓은 질문보다 더 좁고 진단적인 형태를 갖는다. 모델이 프롬프트에 적힌 알고리즘을 그대로 실행하는가, 그리고 절차 길이와 참조 깊이가 증가할 때 그 능력이 어떻게 무너지는가가 논문의 중심이다. 이 관점은 에이전트 워크플로, 규정 기반 의사결정, 계산 보조, 데이터 처리 파이프라인처럼 절차 준수가 중요한 응용에서 특히 의미가 크다.

2. 배경 및 관련 연구: 추론 신뢰성과 절차 충실성의 분리

2.1 추론 성능의 확장과 그 이면의 불안정성

최근 LLM 연구는 Chain-of-Thought, self-verification, test-time reasoning, 강화학습 기반 reasoning 튜닝을 통해 복잡한 문제에서 높은 성과를 보여 왔다. 하지만 높은 점수는 모델이 모든 중간 과정을 신뢰할 수 있게 계산했다는 보증이 되지 않는다. 논문은 이 지점을 겉으로 보이는 추론과 실제 절차 수행의 차이로 정리한다.

관련 연구에서는 모델이 복잡한 퍼즐이나 다단계 질문에서 패턴 매칭, 기억된 연관, shortcut을 사용할 수 있음을 지적해 왔다. 특히 알고리즘이 완전히 주어져 있어도 모델이 이를 안정적으로 적용하지 못하는 현상은 이미 여러 연구에서 보고되었다. 이 논문은 그 문제를 더 통제된 산술 환경으로 가져와, 자연어 해석의 애매함을 줄이고 실패 원인을 절차 유지 능력 쪽으로 좁힌다.

논문이 말하는 reasoning failure는 “계산을 못한다”라는 단순한 주장과 다르다. 모델이 무엇을 언제 기억해야 하는지, 어떤 중간값을 다음 단계에 넣어야 하는지, 언제 답을 내고 멈춰야 하는지를 모두 맞춰야 비로소 절차 실행에 성공한다. 이처럼 절차 실행은 산술 정확도, 작업 메모리, 명령 순서 보존, 출력 형식 준수의 결합 문제로 볼 수 있다.

2.2 기존 벤치마크와의 차별점: 모호한 과제에서 통제된 알고리즘으로

일반적인 수학 추론 벤치마크는 문제 풀이 전략이 여러 개일 수 있고, 모델이 중간 풀이를 생략해도 정답을 맞힐 수 있다. 반면 이 논문의 벤치마크에서는 절차 자체가 평가 대상이다. $S_1$, $S_2$로 시작해 지정된 $S_t$를 순서대로 계산해야 하며, 최종 출력 역시 명확히 결정된다. 따라서 정답 여부와 함께 생성 과정의 단계 수, 답의 위치, 태그 형식, self-correction을 분석할 수 있다.

이 접근은 특히 faithfulness 평가의 실험 단위를 바꾼다. 기존 연구가 모델의 설명이 실제 내적 판단과 일치하는지, 혹은 에이전트가 자신의 belief를 검증하는지를 다뤘다면, 이 논문은 “설명”보다 더 낮은 층위의 실행을 본다. 모델이 이미 주어진 procedure를 따라가며 intermediate state를 갱신할 수 있는지 묻는 것이다.

이 때문에 논문은 정답률을 버리지 않는다. 정답률은 여전히 첫 번째 핵심 지표다. 다만 정답률 하나만으로는 missing answer, malformed answer, premature answer, under-execution, hallucinated extra steps를 구분할 수 없다고 본다. 따라서 first-answer accuracy, Correct@Any, non-null answer rate, answer position, step-following breakdown을 함께 놓아야 한다.

비교 축	일반 추론 벤치마크	이 논문의 절차 실행 벤치마크
문제 해석	자연어 의미와 배경지식이 섞임	명시된 산술 알고리즘을 그대로 실행
정답 경로	여러 풀이 경로가 가능	단계 순서와 중간 변수 참조가 고정
실패 분석	주로 최종 정답 위주	답 형식, 답 위치, 단계 실행 수까지 분석
진단 초점	넓은 reasoning ability	faithful procedural execution

위 비교에서 보듯, 논문의 기여는 더 어려운 수학 문제를 만드는 데 있지 않다. 오히려 간단한 연산을 반복시켜 모델이 순서와 상태를 보존하는지를 드러내는 데 있다. 이 관점은 모델이 정답을 맞히는 능력과 사용자가 지시한 절차를 준수하는 능력을 분리해 관찰하게 해 준다.

3. 방법론: 단계별 산술 알고리즘으로 절차 실행을 고립시키기

3.1 과제 정의: $S_1=x$, $S_2=y$에서 시작하는 결정적 실행

각 예제는 두 입력 $x,y$와 자연어로 쓰인 단계별 알고리즘으로 구성된다. 알고리즘은 항상 $S_1=x$, $S_2=y$로 시작하고, 이후 $S_3$부터 $S_{T+2}$까지를 $+$, $-$, $\times$, $\div$ 중 하나의 연산으로 만든다. 모델은 마지막 return step이 지정한 값을 계산하고, 그 값을 세 자리 반올림 형태로 출력해야 한다.

이 문제의 장점은 참값 계산이 완전히 결정적이라는 점이다. 외부 executor가 각 단계를 파싱하고 같은 순서로 연산하면 기준 출력이 나온다. 따라서 모델의 실패를 “문제를 다르게 해석했다”라고 넘기기 어렵다. 프롬프트에는 절차가 주어지고, 답 형식도 지정되며, 평가자는 첫 번째 추출 답과 모든 추출 답을 기준값과 비교한다.

논문에서 사용하는 수식적 관점은 간단하다. 초기값을 $S_1=x$, $S_2=y$로 놓고, 각 단계에서 $S_i = f(S_j, S_k)$ 꼴의 값을 만든다. 여기서 $f$는 사칙연산 중 하나이고, $j,k$는 이미 계산된 인덱스다. 최종 목표는 $\mathrm{round}(S_{T+2},3)$과 같은 형태로 생각할 수 있다. 중요한 것은 연산 자체보다 어떤 이전 값을 가져오는지다.

function(x, y):
    Let S1 = x
    Let S2 = y
    Step 1: S3 = S1 + S2
    Step 2: S4 = S3 - S2
    Step 3: S5 = S4 / S2
    Step 4: S6 = S5 * S3
    Step 5: S7 = S6 - S4
    Final Step: Return S7

이 예시는 단순하지만 논문의 의도를 잘 보여 준다. 모델은 각 줄의 산술을 수행하는 것에 더해, 이전에 계산한 $S_3$, $S_4$, $S_5$를 기억하고 다음 줄에서 정확히 사용해야 한다. 사람이 보면 사소해 보이는 상태 추적이지만, 생성형 모델에게는 토큰을 늘려 가며 일관된 intermediate state를 유지해야 하는 장기 실행 문제로 바뀐다.

3.2 복잡도 축: 길이, look-back, 입력 범위, 연산 변형

첫 번째 복잡도 축은 단계 수 $T$다. 논문은 $T=5,15,25,\dots,95$로 10개 길이를 사용한다. 각 길이마다 100개 예제를 만들고, 하나의 데이터셋은 1,000개 예제로 구성된다. 이 설계는 “연산 하나의 난이도”를 거의 고정한 상태에서 실행 길이만 늘릴 수 있게 한다.

두 번째 축은 look-back dependency다. look-back1에서는 현재 단계가 바로 직전 중간값을 주로 참조한다. look-back7에서는 현재 단계가 이전 일곱 단계 안의 중간값 중 하나를 다시 가져와야 할 수 있다. 이 값이 커질수록 모델은 더 오래된 상태를 찾아야 하며, 잘못된 변수를 끌어오면 이후 모든 계산이 흔들린다.

입력 범위는 $[0,1]$, $[1,10]$, $[10,100]$이고, $[1,10]$과 $[10,100]$에는 integer와 floating 설정이 모두 포함된다. $[0,1]$은 floating만 사용한다. 연산 변형은 mixed, addition-only, subtraction-only, multiplication-only, division-only로 나뉜다. mixed는 연산 전환과 상태 추적이 동시에 요구되므로 절차 실행 관점에서 더 복합적이다.

구성 요소	값 또는 범위	진단 의도
단계 수	5, 15, 25, ..., 95	장기 절차 유지 능력 측정
look-back	1부터 7	오래된 중간값 검색과 상태 추적 부담 증가
입력 범위	$[0,1]$, $[1,10]$, $[10,100]$	숫자 규모와 분포에 따른 민감도 확인
데이터 타입	integer, floating	정수와 부동소수 입력의 차이 관찰
연산 변형	mixed, add, sub, mul, div	동질 연산과 이질 연산 전환 비교
전체 규모	55 datasets, 55,000 examples	모델별, 조건별 통계적 비교

전체 조합은 완전한 factorial design이 아니다. 비용을 관리하기 위해 look-back1에서는 입력 설정 5개와 연산 변형 5개를 모두 결합해 25개 데이터셋을 만들고, 더 큰 look-back에서는 mixed-operation으로 제한해 30개 데이터셋을 추가한다. 이렇게 해서 총 55개 데이터셋, 55,000개 예제가 만들어진다.

3.3 왜 산술 절차가 좋은 진단 장치가 되는가

산술 절차는 겉으로는 좁은 과제처럼 보이지만, 절차 실행 능력을 고립시키는 데 매우 효율적이다. 자연어 추론 문제에서는 배경지식, 문제 해석, 풀이 전략 선택, 계산, 출력 형식이 한꺼번에 섞인다. 반면 이 논문의 과제에서는 연산과 참조 규칙이 명시되어 있고, 기준값도 외부 executor로 계산할 수 있다. 따라서 모델이 실패했을 때 연구자는 “문제를 몰랐다”는 해석보다 “주어진 procedure를 유지하지 못했다”는 해석에 더 가까이 갈 수 있다.

또한 산술 절차는 중간 상태의 정답을 단계별로 정의할 수 있다. $S_5$가 무엇이어야 하는지, $S_{12}$가 어떤 두 이전 값으로부터 계산되어야 하는지, 마지막 return step이 어느 변수를 가리키는지 모두 명확하다. 이 특성 덕분에 후속 연구는 최종 answer뿐 아니라 각 intermediate variable의 정확도, 최초 오류 위치, 잘못된 참조 인덱스, 오류 전파 길이를 측정할 수 있다. 일반적인 긴 추론 문제에서는 이런 단계별 ground truth를 만들기 훨씬 어렵다.

이 벤치마크가 특히 유용한 지점은 난이도 조절 방식이다. 문제를 더 어렵게 만들기 위해 새로운 지식을 넣거나 복잡한 theorem을 요구하지 않는다. 같은 사칙연산을 유지한 채 step 수와 look-back만 늘린다. 이 단순한 조작은 모델의 약점이 지식 부족이나 문제 유형 미숙에서 온 것인지, 장기 상태 유지와 변수 참조에서 온 것인지 분리하는 데 도움이 된다. 논문이 “간단한 연산인데도 실패한다”는 메시지를 낼 수 있는 이유가 여기에 있다.

물론 산술 절차가 실제 업무 절차의 모든 특성을 담지는 못한다. 그러나 단위 테스트로서의 가치는 크다. 소프트웨어 개발에서 복잡한 end-to-end 테스트 전에 작은 함수의 입력과 출력을 먼저 검증하듯, LLM 에이전트도 실제 브라우저 조작이나 데이터베이스 업데이트 전에 state update, reference retrieval, output commit을 작게 검증할 필요가 있다. 이 논문의 benchmark는 그런 절차형 단위 테스트의 한 형태로 볼 수 있다.

따라서 이 방법론은 모델 순위를 매기는 용도보다 모델을 디버깅하는 용도에 더 잘 맞는다. 어느 모델이 평균적으로 높은가를 보는 것도 중요하지만, 어떤 조건에서 갑자기 under-execution이 늘어나는지, 어떤 연산에서 expected output magnitude와 오류가 강하게 연결되는지, 어떤 모델이 태그 형식부터 놓치는지 확인하는 편이 실무적으로 더 유용하다. 논문이 여러 보조 지표를 둔 것도 이런 진단 목적과 맞닿아 있다.

Figure 1: 논문 Figure 6. 연산 종류별 expected output 규모와 correct/incorrect 분포를 비교한 그림.

이 그림은 task type에 따라 correct와 incorrect 사례의 expected output 분포가 어떻게 달라지는지를 보여 준다. 덧셈과 뺄셈에서는 값의 규모 차이가 비교적 완만하지만, 곱셈과 나눗셈에서는 출력 크기와 오류가 더 강하게 얽힌다. 그럼에도 논문의 핵심은 값이 커져서 틀린다는 설명을 넘어, 절차 길이와 상태 추적 부담이 독립적인 난점을 만든다는 데 있다. 이 시각화는 연산 난이도와 상태 추적 부담이 서로 결합한다는 점을 보여 주므로, 뒤의 길이·look-back 분석을 해석하는 기준점으로 놓을 수 있다.

4. 실험 설정: 14개 모델과 다층 평가 지표로 본 절차 수행

4.1 평가 모델: 작은 reasoning 모델부터 대형 MoE까지

논문은 1.5B급 소형 모델부터 685B급 대형 모델까지 14개 모델을 평가한다. 목록에는 DeepSeek-R1-Distill-Qwen 계열, Qwen3 계열, Olmo, Mistral, OpenThinker, Ministral, Magistral, Sarvam, Nemotron, OpenAI-OSS, DeepSeek-V3.2가 포함된다. 서로 다른 모델 계열과 크기를 함께 놓아, scale이 절차 실행 안정성으로 이어지는지 살핀다.

모든 예제에는 고정된 prompt format이 사용된다. 시스템 지시, 전체 절차, 두 입력값이 주어지고, 모델은 최종 숫자를 <answer>와 </answer> 태그 안에 넣어 반환해야 한다. 추론은 가능한 한 결정적인 설정에서 진행된다. 논문은 temperature 0, top-p 1.0, 최대 생성 길이 32,768 tokens를 사용했다고 설명한다.

모델	규모	비고
DeepSeek-R1-Distill-Qwen-1.5B	1.5B	소형 distill reasoning 모델
Qwen3-4B-Thinking-2507	4B	thinking 지향 Qwen 계열
Olmo-3-7B-Think	7B	7B thinking 모델
Mistral-7B-Instruct-v0.3	7B	instruction tuned 모델
DeepSeek-R1-Distill-Qwen-7B	7B	distill reasoning 모델
OpenThinker2-7B	7B	open reasoning 계열
Ministral-3-14B-Reasoning-2512	14B	reasoning 특화 14B
DeepSeek-R1-Distill-Qwen-14B	14B	더 큰 distill 모델
Qwen3-14B	14B	Qwen3 14B
Magistral-Small-2509	24B	small 명칭이지만 24B급
Sarvam-30B	30B	30B급 모델
NVIDIA-Nemotron-3-Nano-30B-A3B-BF16	30B	Nemotron 계열
OpenAI-OSS 120B	120B	대형 open-weight 계열
DeepSeek-V3.2 685B	685B	대형 MoE 계열

이 표에서 중요한 점은 단지 큰 모델을 넣었다는 사실이 아니다. 논문은 reasoning-oriented 모델도 절차 길이가 길어지면 안정성이 무너지는지 확인한다. 실제 결과는 큰 모델이 전반적으로 유리하긴 하지만, 모든 조건에서 완전한 절차 실행을 보장하지는 않는다는 쪽에 가깝다.

4.2 평가 지표: 첫 답, 모든 답, 답의 존재, 답의 위치, 단계 수

가장 기본 지표는 first-answer accuracy다. 모델 출력에서 처음 추출된 answer span이 기준 출력과 세 자리 반올림 기준으로 일치하면 정답으로 처리한다. 실제 사용 상황에서는 첫 번째로 제출한 답이 중요하므로, 이 지표는 모델의 최초 commit 품질을 측정한다.

Correct@Any는 완화된 지표다. 모델이 여러 answer span을 냈을 때 그중 하나라도 기준값과 일치하면 정답으로 본다. first-answer accuracy와 Correct@Any 사이의 차이는 모델이 처음에는 틀렸지만 뒤에서 고치는 self-correction의 흔적으로 해석할 수 있다.

Non-null answer rate는 모델이 형식에 맞는 답을 적어도 하나 내놓았는지 본다. 이는 정확도와 다른 문제다. 어떤 모델은 계산을 틀리는 수준을 넘어 태그를 생략하거나, 프롬프트 일부를 반복하거나, 작업과 무관한 문장을 생성한다. 이런 경우는 절차 실행 실패와 출력 프로토콜 실패가 겹친 사례다.

Answer position은 첫 <answer> 태그가 생성된 위치다. 너무 이른 답변은 모델이 모든 단계를 실제로 수행하지 않고 곧바로 commit했을 가능성을 시사한다. 그러나 early answer가 항상 나쁜 것은 아니다. 일부 강한 모델은 빠르게 답을 내면서도 높은 정확도를 보인다. 따라서 answer position은 accuracy와 step-following behavior와 함께 해석해야 한다.

지표	정의	잡아내는 현상
First-answer accuracy	첫 번째 추출 답이 기준값과 일치	초기 답변의 신뢰도
Correct@Any	어느 answer span이라도 기준값과 일치	후속 self-correction 가능성
Non-null answer rate	형식에 맞는 답을 하나 이상 생성	missing 또는 malformed answer
Answer position	첫 답 태그의 상대적 생성 위치	premature answer 또는 긴 reasoning trace
Step-following behavior	실행한 중간 단계 수와 기대 단계 수 비교	under-execution, exact execution, over-execution

이 다층 지표 설계는 논문의 설득력을 높인다. 정답률만 보면 “어떤 모델이 더 잘 맞혔다”로 끝나지만, 이 지표들을 함께 보면 왜 틀렸는지의 윤곽이 보인다. 특히 under-execution의 증가는 모델이 계산 중간에 산술 오류를 낸 수준을 넘어, 절차를 끝까지 끌고 가지 못했다는 신호다.

5. 주요 실험 결과: 길어질수록 떨어지고, 멀리 참조할수록 더 흔들린다

5.1 알고리즘 길이의 효과: 5-step 61%에서 95-step 20%로

가장 큰 결과는 단계 수 증가에 따른 평균 accuracy 하락이다. 5-step 절차에서 평균 first-answer accuracy는 61%였고, 95-step에서는 20%까지 내려갔다. 개별 연산은 단순하지만, 절차가 길어질수록 모델은 중간 상태를 잃고, 필요한 단계를 건너뛰고, 답을 너무 빨리 내거나 형식을 망가뜨린다.

이 결과는 “긴 chain-of-thought를 만들면 더 잘 추론한다”라는 직관에 제동을 건다. 논문은 긴 reasoning trace가 항상 faithful execution을 의미하지 않는다고 본다. 더 많은 토큰을 생성해도 그 토큰들이 실제 절차의 올바른 상태 전이를 보존하지 못하면, 겉보기 reasoning은 길어졌지만 실행은 무너질 수 있다.

Figure 2: 논문 Figure 1. 알고리즘 단계 수가 5에서 95로 늘어날 때 모델별 정확도가 어떻게 하락하는지 보여 준다.

이 그림은 단계 수가 늘어날수록 여러 모델의 정확도가 함께 하락하는 흐름을 보여 준다. 개별 모델의 시작점과 기울기는 다르지만, 전체 패턴은 절차 길이가 핵심 부담이라는 해석을 강화한다. 특히 5단계에서 이미 완벽하지 않은 모델들이 95단계로 갈수록 더 낮은 영역에 모이는 점이 중요하다. 짧은 절차의 우위가 긴 절차의 안정성으로 자동 이전되지 않는다는 메시지도 함께 읽힌다. 따라서 이 곡선은 모델 규모의 차이보다 절차가 길어질 때 공통적으로 생기는 유지 비용을 읽는 데 초점을 맞춰야 한다.

논문은 expected output magnitude가 커져서 성능이 떨어졌을 가능성도 점검한다. 곱셈과 나눗셈에서는 값의 규모가 오류와 관계될 수 있지만, 전체적으로 단계 수 증가와 expected value 증가가 일관되게 맞물리지는 않는다. 따라서 저자들은 성능 하락의 주된 원인을 절차적 부담으로 해석한다.

5.2 look-back dependency의 효과: 깊은 참조는 상태 추적의 약점을 드러낸다

look-back1에서 look-back7로 갈 때 평균 정확도는 18.43 percentage points 떨어진다. 이는 길이만의 문제가 아니다. 같은 절차 길이에서도 현재 단계가 오래된 중간값을 필요로 하면 모델은 그 값을 안정적으로 찾아와야 한다. 잘못된 $S_i$를 선택하거나 이전 값을 덮어쓴 것처럼 행동하면 이후 계산은 연쇄적으로 틀어진다.

이 결과는 LLM의 문맥 보유 능력과 절차 실행 능력이 동일하지 않음을 보여 준다. 모델은 이전 토큰을 볼 수 있지만, 그것을 프로그램 변수처럼 정확히 참조하는 데 실패할 수 있다. look-back이 커질수록 필요한 것은 단순한 기억 용량보다 주소 지정 가능한 작업 상태에 가깝다.

Figure 3: 논문 Figure 2. look-back dependency가 깊어질수록 모델별 정확도가 낮아지는 heatmap이다.

look-back heatmap은 모델별로 의존성 깊이가 늘어날 때 정확도가 어떻게 줄어드는지 압축적으로 보여 준다. 일부 강한 모델은 얕은 참조에서는 견고하지만, 더 깊은 참조에서는 여전히 하락한다. 이는 “프롬프트에 정보가 있으므로 충분하다”는 설명이 절차 실행에서는 부족하다는 점을 드러낸다. 문맥 접근 가능성과 올바른 변수 회수 능력이 서로 다른 축임을 보여 주는 대목이다. 특히 각 행의 색 변화는 같은 모델 안에서도 참조 깊이가 바뀌면 신뢰도가 달라진다는 점을 강조한다.

결과 항목	낮은 복잡도	높은 복잡도	해석
Average first-answer accuracy by steps	5-step: 61%	95-step: 20%	절차 길이 증가에 따른 급락
Look-back dependency	look-back1	look-back7: 평균 18.43pp 하락	오래된 중간값 참조의 어려움
Exact-step execution	70.88%	46.84%	필요 단계 수를 맞춰 실행하는 비율 감소
Under-execution	24.25%	50.87%	절차를 끝내기 전에 멈추는 비율 증가

이 집계 결과의 핵심은 accuracy와 execution behavior가 같은 방향으로 나빠진다는 것이다. 정답률이 떨어지는 동시에 exact execution은 줄고 under-execution은 늘어난다. 이는 실패가 독립적인 산술 오류의 합을 넘어, 모델이 요구된 절차를 끝까지 따라가지 못하는 구조적 현상임을 시사한다.

5.3 실행 행동 분석: 정확도 하락 뒤의 under-execution

논문에서 특히 중요한 그림은 accuracy와 execution behavior를 함께 놓은 것이다. 단계 수가 증가하면 exact-step execution은 70.88%에서 46.84%로 내려가고, under-execution은 24.25%에서 50.87%로 올라간다. over-execution도 관찰되지만, 주된 실패 방향은 필요한 절차보다 적게 실행하는 쪽이다.

under-execution은 여러 모습으로 나타난다. 모델이 몇 개의 중간 단계를 계산하다가 곧바로 답을 적기도 하고, 중간 변수를 생략한 채 최종식처럼 보이는 값을 만들기도 하며, 생성이 길어지다가 형식 태그 없이 끝나기도 한다. 이런 현상은 모델이 절차를 상태 기계처럼 유지하기보다, 일정 지점에서 그럴듯한 completion으로 빠지는 경향을 보여 준다.

Figure 4: 논문 Figure 3. 정확도, exact execution, under-execution, over-execution을 단계 수에 따라 함께 비교한다.

이 그림은 정답률의 하락과 실행 유형의 변화를 함께 보여 주기 때문에 논문의 메시지를 가장 직접적으로 전달한다. exact execution이 줄어드는 동안 under-execution이 늘어난다는 사실은, 모델이 긴 절차에서 “조금씩 틀리며 계속 계산”하는 대신 절차 자체를 중간에 잃는 경우가 많다는 해석을 가능하게 한다. 따라서 정확도 곡선만 볼 때보다 실패의 작동 방식이 훨씬 선명해진다. 이 비교는 최종 정답률만으로는 보이지 않는 조기 중단 현상을 수량화한다는 점에서 논문의 중심 증거에 가깝다.

또한 Correct@Any는 모델의 self-correction을 포착한다. 어떤 출력에서는 첫 답이 틀리지만 뒤에서 다시 계산해 맞는 값을 내놓는다. 그러나 실제 사용자는 첫 답을 신뢰할 가능성이 높고, 시스템이 첫 answer span을 읽는다면 뒤의 수정은 반영되지 않는다. 이 때문에 first-answer accuracy는 여전히 엄격하고 실용적인 지표다.

5.4 절차 길이 결과를 운영 지표로 바꿔 읽기

5-step에서 95-step으로 갈 때 평균 accuracy가 61%에서 20%로 하락했다는 숫자는 단순한 연구 결과 이상의 운영적 의미를 갖는다. 실제 시스템에서 절차 길이는 사용자가 작성한 지시문의 줄 수, 정책 체크리스트 항목 수, 도구 호출 순서, 데이터 처리 단계 수로 나타난다. 짧은 demo에서는 안정적으로 보이는 모델이 긴 업무 흐름에서 갑자기 약해지는 현상은 이 논문의 step-count curve와 같은 구조를 가진다. 따라서 모델을 배포할 때는 “짧은 과제에서 맞혔는가”와 “긴 절차에서 같은 방식으로 유지되는가”를 별도 기준으로 관리해야 한다.

이 관점에서 95-step 결과는 극단 조건만을 의미하지 않는다. 서비스 환경에서는 사용자가 명시한 절차가 95줄까지 길지 않아도, 모델이 내부적으로 만든 하위 단계와 검산 단계까지 합치면 실행 경로가 상당히 길어진다. 예를 들어 문서 검토 에이전트가 파일을 읽고, 규칙을 찾고, 항목별 판단을 내리고, 결과를 표로 정리하고, 마지막에 예외를 보고하는 흐름은 표면상 몇 문장으로 보이지만 내부 상태는 계속 누적된다. 논문이 보여 준 성능 하락은 이런 장기 상태 누적이 모델의 약점이라는 사실을 수치로 고정한다.

또한 first-answer accuracy가 강조되는 이유는 실제 파이프라인에서 첫 답이 곧 실행 결과로 소비되는 경우가 많기 때문이다. 사람과 대화할 때는 모델이 뒤에서 스스로 고친 내용을 읽을 수 있지만, 자동화 시스템은 첫 번째 answer span이나 첫 번째 tool call을 바로 파싱해 다음 단계로 넘길 수 있다. 이때 Correct@Any가 높아도 첫 답이 낮으면 장애가 발생한다. 논문은 self-correction을 무시하지 않되, 시스템 commit 관점에서는 첫 번째 구조화 답이 더 엄격한 기준이 되어야 한다고 읽을 수 있다.

정확도 곡선을 운영 지표로 옮기면 세 가지 threshold를 만들 수 있다. 첫째, 특정 모델이 안정적으로 처리할 수 있는 최대 절차 길이를 정한다. 둘째, look-back이 깊어지는 작업에서는 더 보수적인 길이 제한을 둔다. 셋째, 모델이 answer tag를 너무 일찍 내거나 중간 단계 수가 기대보다 짧으면 결과를 자동 승인하지 않는다. 이런 기준은 모델의 일반 능력 점수보다 훨씬 구체적으로 서비스 실패를 줄이는 데 도움이 된다.

논문의 결과는 모델 크기만으로 이 threshold를 정하면 위험하다는 점도 보여 준다. 일부 대형 모델은 전반적 정확도가 높지만 곱셈, 나눗셈, 깊은 look-back 조건에서 여전히 급격한 하락을 보인다. 따라서 운영자는 모델별 평균 점수보다 조건부 신뢰도 프로파일을 봐야 한다. 어떤 모델은 짧은 덧셈 중심 절차에 강하고, 어떤 모델은 형식 출력은 안정적이지만 오래된 변수를 가져오는 데 약할 수 있다. 이 프로파일을 만들 때 논문의 55개 데이터셋 구조는 좋은 참고 틀이다.

5.5 look-back 결과가 말하는 작업 메모리의 형태

look-back dependency는 이 논문에서 가장 중요한 설계 축 중 하나다. 현재 단계가 바로 직전 값만 참조하면 모델은 비교적 단순한 rolling state를 유지하면 된다. 그러나 이전 일곱 단계 안의 값 중 하나를 선택해야 하면 상황이 달라진다. 모델은 단순히 “최근 문맥을 본다”를 넘어, 여러 중간 변수 중 어떤 이름과 값이 지금 필요한지 구분해야 한다. 이 능력은 사람이 메모장에 변수를 적어 두고 다시 찾는 동작과 더 가깝다.

LLM의 context window는 모든 이전 토큰을 접근 가능하게 만들지만, 접근 가능성은 주소 지정 능력과 같지 않다. $S_7$이라는 문자열이 문맥 안에 남아 있어도 모델이 현재 연산에서 $S_7$을 가져와야 하는지, $S_8$을 가져와야 하는지, 혹은 방금 계산한 $S_{t-1}$을 써야 하는지 구분하지 못하면 절차는 실패한다. 논문이 look-back1에서 look-back7로 갈 때 평균 18.43pp 하락을 보고한 것은 이 차이를 잘 드러낸다.

이 결과는 long-context 모델 평가에도 연결된다. 긴 문맥 benchmark는 보통 정답 단서가 먼 위치에 있어도 검색할 수 있는지 묻는다. 반면 여기서는 단서가 하나의 문장으로 존재하는 수준을 넘어, 중간 변수의 값과 그 값이 만들어진 연산 흐름을 함께 유지해야 한다. 즉 단순 retrieval보다 더 강한 stateful retrieval이 요구된다. 모델이 문서 검색 문제에서는 강해도 절차형 변수 참조에서 약할 수 있는 이유가 여기에 있다.

또 한 가지 중요한 점은 look-back 오류가 한 번 발생하면 이후 단계 전체에 전파된다는 사실이다. 단일 질문에서 잘못된 문장을 하나 골라도 다음 답변으로 넘어가며 복구할 수 있지만, 절차 실행에서는 잘못된 중간값이 다음 중간값의 입력이 된다. 따라서 오류는 독립적인 오답 하나로 끝나지 않고, 뒤쪽 계산 전체를 오염시킨다. 이 특성 때문에 절차 실행 평가에서는 최종 accuracy와 함께 최초 오류 단계, 오류 전파 길이, 재동기화 가능성을 따로 측정할 필요가 있다.

논문은 이 부분을 완전히 자동화된 변수 주소 추적까지 확장하지는 않지만, 결과만으로도 필요한 방향을 제시한다. 앞으로의 벤치마크는 모델이 어느 step에서 어떤 변수 이름을 읽었고, 그 변수의 실제 값과 모델이 사용한 값이 일치했는지 기록할 수 있다. 그렇게 하면 under-execution, wrong-reference, wrong-arithmetic, wrong-format을 더 세밀하게 구분할 수 있다. 이 확장은 절차 실행 실패를 단순한 성능 하락에서 디버깅 가능한 오류 로그로 바꾸는 단계다.

6. 추가 분석 및 Ablation Study: 입력 범위, 연산 종류, 출력 형식의 세부 영향

6.1 입력 범위와 데이터 타입: 숫자 규모는 일부 설명하지만 전부는 아니다

논문은 입력 범위 $[0,1]$, $[1,10]$, $[10,100]$와 integer, floating 차이를 따로 분석한다. 대체로 모든 범위에서 단계 수가 늘수록 accuracy가 하락한다. $[0,1]$ 범위는 상대적으로 나은 경향을 보이지만, 이 차이가 전체 성능 하락을 설명하지는 못한다.

데이터 타입에서도 비슷한 패턴이 나타난다. 짧은 단계에서는 floating이 약간 유리한 경우가 있지만, 단계가 길어지면 두 타입 모두 하락한다. 논문은 expected-output magnitude를 살피며 값의 크기가 오류에 영향을 줄 수 있음을 인정한다. 그러나 magnitude와 correctness의 관계는 모델, 범위, 연산에 따라 달라 일관적인 단일 원인으로 보기 어렵다.

Figure 5: 논문 Figure 12. 입력 범위별 모델 정확도 차이를 heatmap으로 정리한 그림.

범위별 heatmap은 입력 숫자의 구간이 모델별 정확도에 영향을 준다는 점을 보여 준다. 그러나 모든 모델이 같은 범위에서 같은 방향으로 움직이지는 않는다. 이 때문에 저자들은 range effect를 보조 요인으로 두고, 절차 길이와 look-back 의존성에서 반복되는 하락을 더 근본적인 현상으로 해석한다. 숫자 분포의 영향은 존재하지만, 모델 공통의 장기 실행 약점을 덮을 만큼 일관적이지 않다. 따라서 입력 범위는 독립 변수라기보다 절차 길이, 연산 종류, 모델별 수치 처리 방식과 함께 해석해야 한다.

6.2 연산 종류별 차이: 덧셈과 뺄셈은 비교적 강하고 곱셈과 나눗셈은 취약하다

operation-specific appendix 수치는 모델의 약점을 더 선명하게 보여 준다. 전반적으로 addition-only와 subtraction-only는 높은 편이고, multiplication-only와 division-only는 낮다. 예를 들어 DeepSeek-V3.2 685B는 add 99.9, sub 97.4, mul 53.4, div 69를 기록한다. GPT-OSS 120B 역시 add 99.7, sub 97.9에 비해 mul 49.2, div 43.2로 내려간다.

작은 모델에서는 이 차이가 훨씬 커진다. DeepSeek-R1-Distill-Qwen-1.5B는 add 10.8, sub 9.5, mul 2.0, div 4.7로 거의 모든 operation에서 낮지만, 특히 곱셈과 나눗셈은 극단적으로 취약하다. Sarvam-30B도 add 40.3, sub 28.1, mul 6.1, div 5.5로 나타나, 파라미터 규모만으로 절차 실행 안정성을 예측하기 어렵게 만든다.

모델	Add	Sub	Mul	Div
OpenThinker2-7B	91.1	88.9	31.0	36.9
Qwen3-14B	88.9	85.1	35.6	44.0
DeepSeek-R1-Distill-Qwen-14B	72.9	38.9	27.0	22.4
Ministral-3-14B-Reasoning-2512	86.7	76.6	29.6	43.6
Magistral-Small-2509	85.3	90.9	26.4	43.5
NVIDIA-Nemotron-3-Nano-30B-A3B-BF16	98.1	42.3	39.1	21.3
Sarvam-30B	40.3	28.1	6.1	5.5
OpenAI-OSS 120B	99.7	97.9	49.2	43.2
DeepSeek-V3.2 685B	99.9	97.4	53.4	69.0
DeepSeek-R1-Distill-Qwen-1.5B	10.8	9.5	2.0	4.7
Qwen3-4B-Thinking-2507	85.5	87.4	33.5	33.1
DeepSeek-R1-Distill-Qwen-7B	65.3	27.3	14.2	9.7

이 표는 두 가지를 말한다. 첫째, 연산 종류의 차이는 매우 크다. 둘째, 덧셈과 뺄셈에서 강한 모델도 곱셈과 나눗셈으로 가면 절차 실행이 크게 약해진다. 이는 arithmetic primitive 자체의 난이도와 중간값의 수치 규모가 procedural tracking과 결합하면서 실패를 증폭한다는 해석을 뒷받침한다.

Figure 6: 논문 Figure 13. addition, subtraction, multiplication, division, mixed task에서 모델별 정확도 차이를 보여 준다.

task heatmap은 연산 종류별 모델 성능 격차를 시각적으로 압축한다. 밝은 영역은 덧셈과 뺄셈에서 주로 보이고, 곱셈과 나눗셈으로 이동하면 많은 모델의 색이 어두워진다. 이 패턴은 모델이 산술 규칙을 알고 있어도 긴 절차 속에서 해당 규칙을 반복 적용하는 능력은 제한적임을 보여 준다. 특히 mixed task에서는 연산 선택과 변수 추적이 동시에 필요해 부담이 더 커진다. 이 그림은 표의 숫자를 한눈에 요약하며, mixed task가 단순 산술 지식보다 상태 관리와 연산 선택을 함께 요구한다는 점을 드러낸다.

6.3 답 형식과 답 위치: 실패는 계산 오류만이 아니다

생성 레벨 분석에서 missing 또는 malformed answer는 중요한 실패 모드다. 모델이 요구된 <answer> 태그를 내놓지 않으면, 설령 내부적으로 어떤 계산을 했더라도 시스템은 값을 추출할 수 없다. 이 문제는 특히 낮은 성능의 모델에서 두드러진다. 일부 출력은 프롬프트 반복, 무관한 문장, 종료 실패를 포함한다.

non-null answer rate는 accuracy와 구별된다. 정확도가 낮은 모델이라도 형식은 지킬 수 있고, 형식이 좋은 모델도 답을 틀릴 수 있다. 따라서 이 지표는 모델의 instruction following 중에서도 출력 프로토콜 준수를 따로 측정한다. 절차 실행 시스템에서는 값이 맞는지와 함께 값이 읽을 수 있는 위치와 형식으로 제공되는지도 중요하다.

Figure 7: 논문 Figure 14. 단계 수 증가에 따른 non-null answer rate 변화를 보여 준다.

non-null answer rate 그림은 일부 모델이 긴 절차에서 유효한 answer span 자체를 놓치는 경향을 보여 준다. 이는 정답률 하락의 일부가 계산값 불일치 이전 단계에서 발생한다는 뜻이다. 즉 모델은 산술 결과를 틀리는 경우도 있지만, 결과를 지정된 형식으로 제출하는 절차적 약속부터 깨뜨리기도 한다. 파싱 가능한 출력은 평가 파이프라인과 실제 서비스 모두에서 최소 요건이다. 결과적으로 형식 준수는 계산 정확도와 분리해 관리해야 할 배포 지표라는 점이 분명해진다.

answer position 역시 흥미로운 보조 신호다. 모델이 너무 일찍 답을 내면 모든 단계를 실행하지 않고 조기 commit했을 가능성이 있다. 반대로 답이 뒤에 있다고 해서 항상 faithful execution이라고 말할 수는 없다. 긴 reasoning trace 안에서도 잘못된 중간값을 유지하거나, 계산을 반복하다가 뒤늦게 그럴듯한 값을 낼 수 있기 때문이다.

Figure 8: 논문 Figure 15. 모델별 첫 answer tag의 normalized position 분포를 비교한다.

answer position 그림은 모델별 답변 전략의 차이를 보여 준다. 어떤 모델은 초반에 바로 답을 내고, 어떤 모델은 긴 reasoning을 생성한 뒤 답을 낸다. 그러나 위치만으로는 충실성을 판정할 수 없다. 이 신호는 first-answer accuracy, Correct@Any, step-count classification과 결합될 때 조기 답변과 자기 수정의 의미를 더 잘 드러낸다. 이 분포는 답을 언제 제출하는지가 모델별 전략 차이를 만들며, commit 시점 제어가 절차 실행 평가에서 중요함을 보여 준다.

실패 모드	관찰 양상	왜 중요한가
Missing or malformed answer	태그가 없거나 파싱할 수 없는 답	시스템이 값을 읽을 수 없어 즉시 실패
Premature answer	필요 단계 전에 답을 제출	조기 commit으로 절차가 생략될 가능성
Self-correction after initial error	첫 답은 틀리고 뒤의 답은 맞음	first-answer와 Correct@Any 차이를 만듦
Under-executed traces	기대 단계보다 적은 중간 계산	긴 절차에서 가장 중요한 실패 방향
Hallucinated extra steps	지시된 절차 밖의 추가 계산	멈춰야 할 시점의 통제 실패

이 실패 모드 표는 논문이 단순 accuracy paper가 아님을 보여 준다. 저자들은 생성물이 어떤 방식으로 실패했는지 분류함으로써, 모델이 계산을 틀렸는지, 절차를 덜 수행했는지, 답을 제출하는 규약을 깨뜨렸는지를 구분한다. 이 구분은 실제 배포 환경에서 오류를 줄이는 설계로 이어질 수 있다.

6.4 모델 규모와 reasoning 튜닝을 함께 읽는 법

operation별 appendix 수치를 보면 scale과 reasoning tuning의 관계가 단선적으로 정리되지 않는다. DeepSeek-V3.2와 OpenAI-OSS는 덧셈과 뺄셈에서 거의 포화에 가까운 성능을 보이지만, 곱셈과 나눗셈에서는 큰 폭의 여지가 남는다. 반면 Qwen3-4B-Thinking-2507은 작은 규모에도 덧셈과 뺄셈에서 높은 수치를 보인다. 이런 관찰은 모델 크기, 학습 데이터, reasoning style, 출력 규약 준수 능력이 서로 다른 방식으로 절차 실행에 기여한다는 점을 시사한다.

특히 reasoning 모델이라는 이름이 곧 절차 실행 모델이라는 뜻은 아니다. reasoning 튜닝은 긴 풀이를 만들고 self-reflection을 유도할 수 있지만, 절차 실행은 중간 상태를 정확히 갱신하는 능력을 요구한다. 모델이 “생각하는 방식”을 길게 배웠더라도, 각 step의 입력 변수를 엄격히 읽고, 해당 연산을 수행하고, 결과를 다음 변수에 바인딩하는 훈련 신호가 약하면 장기 절차에서 같은 문제가 반복될 수 있다.

이 차이는 곱셈과 나눗셈에서 더 크게 드러난다. 덧셈과 뺄셈은 값의 변화가 비교적 완만하고, 일부 경우에는 추정이나 패턴으로도 짧은 절차를 버틸 수 있다. 곱셈과 나눗셈은 값의 규모가 빠르게 변하고, 반올림과 부동소수 표현이 개입하며, 잘못된 중간값의 영향도 커진다. 따라서 같은 step 수라도 연산 종류에 따라 모델이 유지해야 할 상태의 정밀도가 달라진다.

논문 결과를 모델 선택에 바로 적용한다면, “가장 큰 모델 하나”보다 “작업 조건별로 검증된 모델”이 더 안전하다. 예를 들어 긴 check-list 실행이 필요한 업무, 깊은 변수 참조가 필요한 계산 업무, 출력 schema 준수가 중요한 업무는 서로 다른 failure mode를 가진다. 하나의 평균 점수로 모든 업무를 커버하려 하면, 특정 조건에서 성능이 급락하는 영역을 놓칠 수 있다. 이 논문의 실험표는 그런 조건부 취약성을 찾는 방법을 제시한다.

또한 작은 모델의 결과를 무조건 낮게 평가할 필요도 없다. 일부 작은 reasoning 모델은 특정 연산과 짧은 길이에서 경쟁력 있는 성능을 보인다. 이는 경량 모델을 완전히 배제하기보다, 처리 가능한 절차 길이와 연산 범위를 명확히 제한해 쓰는 전략을 가능하게 한다. 모델을 절차 executor로 사용할 때는 “가능한 과제의 경계”를 모르는 것이 가장 위험하다. 이 논문은 그 경계를 경험적으로 그리는 방식의 예시다.

6.5 출력 형식 실패를 시스템 오류로 보는 이유

non-null answer rate는 얼핏 부차적인 지표처럼 보일 수 있다. 그러나 자동화 시스템에서는 형식 실패가 곧 시스템 실패다. 모델이 매우 긴 reasoning을 생성하고 그 안에서 정답 비슷한 숫자를 언급하더라도, 약속된 <answer> 태그가 없다면 downstream parser는 값을 읽지 못한다. 이 상황은 계산 정확도 문제를 넘어 interface contract 위반이다. 논문이 이 지표를 별도로 둔 것은 실제 배포 관점에서 타당하다.

형식 실패는 절차 실행 실패와도 연결된다. 모델이 절차를 끝까지 따라가고 있다면 마지막에는 지정된 형식으로 commit해야 한다. 그런데 긴 절차에서 모델이 prompt 일부를 반복하거나, 태그 없이 설명만 이어 가거나, EOS 또는 길이 제한에 걸린다면, 이는 모델이 언제 결과를 제출해야 하는지 통제하지 못했다는 뜻이다. 즉 non-null 문제는 surface formatting 문제를 넘어 절차의 종료 조건 관리 문제로도 볼 수 있다.

answer position은 이 종료 조건을 더 세밀하게 보여 준다. 조기 answer는 모델이 단계 실행보다 결과 제출을 먼저 선택했을 가능성을 암시한다. 반대로 너무 늦은 answer는 모델이 불필요하게 긴 trace를 만들면서 중간 상태를 오염시킬 위험을 높일 수 있다. 이상적인 절차 executor는 충분한 중간 상태 업데이트를 수행한 뒤, 지정된 final step 직후에 한 번만 답을 제출해야 한다. 이 위치 안정성은 아직 많은 LLM 평가에서 잘 측정되지 않는다.

실무적으로는 출력 형식 실패를 줄이기 위해 schema validation, constrained decoding, tool-call response format, stop sequence를 사용할 수 있다. 그러나 이 장치들이 모든 절차 실행 문제를 해결하지는 않는다. constrained decoding은 태그를 강제할 수 있지만, 태그 안의 값이 올바른지는 보장하지 않는다. 따라서 형식 제약은 계산 검증과 중간 상태 검증을 보완하는 레이어로 배치해야 한다. 논문이 여러 지표를 병렬로 둔 이유가 여기에 있다.

이 지점은 LLM 에이전트의 tool use 평가와도 닿아 있다. 도구 호출이 JSON으로 잘 나와도, 호출 순서가 틀리거나 이전 호출 결과를 잘못 참조하면 작업은 실패한다. 산술 절차의 <answer> 태그는 tool-call schema의 축소판이다. 형식은 맞지만 상태가 틀릴 수 있고, 상태가 어느 정도 맞아도 commit 시점이 틀릴 수 있다. 따라서 절차 실행 평가는 “형식 준수, 상태 추적, 최종 값”을 함께 봐야 한다.

7. 한계점 및 향후 연구 방향: 통제된 진단의 장점과 외삽의 조심스러움

7.1 한계점: 산술 절차가 모든 절차 실행을 대표하지는 않는다

가장 분명한 한계는 과제가 산술 절차에 집중되어 있다는 점이다. 이는 강점이기도 하다. 산술은 기준값을 결정적으로 계산할 수 있고, 모호성을 크게 줄인다. 그러나 실제 절차 실행은 데이터베이스 업데이트, API 호출 순서, 조건 분기, 예외 처리, 사람 승인 단계처럼 더 복잡한 구조를 갖는다. 따라서 이 결과를 모든 에이전트 행동으로 곧바로 확장할 때는 주의가 필요하다.

또 다른 한계는 visible reasoning trace에 대한 분석이다. 모델이 내부적으로 어떤 계산을 했는지는 직접 볼 수 없고, 연구자는 생성된 텍스트를 바탕으로 under-execution, exact execution, over-execution을 분류한다. reasoning trace가 항상 실제 내부 연산의 faithful report라고 볼 수 없기 때문에, 이 분석은 행동적 진단으로 이해하는 편이 안전하다.

데이터셋 조합도 완전한 factorial design이 아니다. 비용상 look-back1에서는 다양한 operation variant를 모두 보지만, 더 높은 look-back에서는 mixed-operation 중심으로 제한된다. 이 선택은 실험 비용을 관리하기 위한 합리적 타협이지만, operation-specific 성능과 deep look-back의 상호작용을 더 자세히 보려면 후속 실험이 필요하다.

7.2 향후 연구: 절차 실행을 에이전트 시스템의 검증 단위로 확장하기

후속 연구에서는 조건문과 반복문을 포함한 procedure, 여러 변수의 동시 업데이트, 외부 도구 호출이 섞인 workflow를 사용할 수 있다. 예를 들어 산술 변수 대신 파일 상태, API 응답, 사용자 권한, 정책 조건을 중간 상태로 두면, 이 벤치마크의 철학을 실제 에이전트 환경에 더 가깝게 옮길 수 있다.

또한 decoding과 prompting의 영향을 더 체계적으로 볼 필요가 있다. 이 논문은 deterministic setting을 사용하지만, 실제 서비스에서는 temperature, stop sequence, tool call schema, scratchpad visibility가 달라질 수 있다. 절차 실행이 prompt engineering으로 어느 정도 개선되는지, 혹은 모델 내부의 state tracking 한계가 더 지배적인지 분리해 볼 수 있다.

평가 방식도 확장 가능하다. 현재는 first answer, any answer, non-null, answer position, step count를 중심으로 본다. 여기에 중간 변수별 correctness trajectory, 오류 최초 발생 단계, 잘못 참조한 변수 인덱스, 답 제출 전 검산 행동을 추가하면 실패 위치를 더 정밀하게 찾을 수 있다. 특히 look-back 오류를 변수 주소 지정 오류로 세분화하면 모델별 약점이 더 선명해질 것이다.

또 하나의 확장 방향은 절차의 문법을 더 프로그램답게 만드는 것이다. 현재 과제는 산술 단계가 자연어로 적혀 있지만, 실제 시스템에서는 JSON schema, workflow DSL, spreadsheet formula, SQL-like rule, policy checklist처럼 더 구조화된 형식이 자주 쓰인다. 같은 procedure를 자연어, 의사코드, 표, JSON plan으로 바꿔 제시했을 때 accuracy와 under-execution이 어떻게 달라지는지 비교하면, 모델이 실패하는 지점이 언어적 파싱인지 상태 전이 실행인지 더 잘 분리할 수 있다.

도구 사용과 결합한 실험도 필요하다. 산술은 계산기나 Python executor가 있으면 쉽게 해결되는 영역이지만, 여기서 관심사는 모델이 직접 숫자를 계산할 수 있는가만이 아니다. 모델이 각 단계마다 도구 호출을 올바르게 만들고, 반환값을 정확히 다음 상태에 저장하며, 마지막 단계에서만 답을 commit하는지도 별도 능력이다. 즉 tool-augmented LLM에서도 절차 스케줄링과 상태 바인딩 문제가 남는다.

실제 응용 관점에서는 검증 비용과 실패 비용의 균형도 다뤄야 한다. 95단계 산술 절차에서 모든 중간값을 검사하는 것은 가능하지만, 복잡한 업무 절차에서는 매 단계 검증이 비용을 늘릴 수 있다. 따라서 어느 구간에서 checkpoint를 두어야 하는지, 모델이 불확실하거나 오래된 변수를 참조할 때만 검증을 강화할 수 있는지, under-execution을 조기에 탐지하는 stop rule을 만들 수 있는지가 중요하다.

후속 평가 축	구체적 실험 아이디어	기대되는 진단 효과
표현 형식	자연어, 의사코드, JSON plan, 표 형식 procedure 비교	파싱 실패와 실행 실패 분리
검증 개입	매 10단계마다 중간값 확인을 요구	under-execution 조기 탐지
도구 결합	각 단계별 calculator call 또는 symbolic executor call 허용	계산 능력과 procedure scheduling 분리
오류 위치	최초 오답 단계와 잘못 참조한 변수 인덱스 기록	look-back dependency의 세부 병목 확인

마지막으로, benchmark가 모델 개발에 주는 신호도 크다. reasoning 튜닝이 단순히 긴 답변을 유도하는 방향으로만 최적화되면, 절차 실행의 정확한 state update는 충분히 개선되지 않을 수 있다. 학습 목표에는 최종 answer뿐 아니라 중간 변수의 정합성, 지정된 단계 수 준수, answer tag의 단일성과 위치, 불필요한 추가 단계 억제가 함께 들어가야 한다. 이 논문은 그런 학습 신호를 설계할 때 어떤 오류 유형을 관찰해야 하는지 좋은 출발점을 제공한다.

7.3 벤치마크 설계를 더 강하게 만드는 추가 통제 변수

이 논문의 벤치마크는 산술 절차를 사용해 모호성을 낮춘다는 점에서 강하다. 그러나 후속 연구에서는 난이도와 실패 원인을 더 정교하게 분해할 수 있다. 첫 번째 추가 통제 변수는 중간값의 수치 규모다. 현재 논문도 expected-output magnitude를 분석하지만, 데이터 생성 단계에서 magnitude growth를 별도 축으로 고정하면 절차 길이와 값의 폭발을 더 깨끗하게 분리할 수 있다. 예를 들어 모든 중간값이 특정 구간 안에 머물도록 생성한 절차와, 중간값이 빠르게 커지는 절차를 나눠 비교할 수 있다.

두 번째 변수는 변수 이름과 참조 패턴이다. $S_1, S_2, S_3$처럼 규칙적인 이름은 사람이 읽기 쉽지만, 모델에게는 숫자 인덱스가 길어질수록 비슷한 토큰들이 반복되는 환경을 만든다. 후속 실험은 변수 이름을 alphabetic token, JSON key, table row id, UUID-like label로 바꾸어 볼 수 있다. 만약 이름 체계에 따라 look-back 성능이 크게 달라진다면, 실패의 일부는 산술보다 변수 binding representation에 있을 수 있다.

세 번째 변수는 intermediate trace visibility다. 모델에게 모든 중간 계산을 반드시 쓰게 할지, 최종 답만 내게 할지, 혹은 일정 간격으로 checkpoint만 쓰게 할지에 따라 성능과 오류 유형이 달라질 수 있다. 모든 중간값을 쓰면 검증 가능성은 높아지지만 생성 길이가 늘고 오류 전파의 기회도 늘어난다. 반대로 최종 답만 요구하면 출력은 짧아지지만 절차를 실제로 수행했는지 확인하기 어렵다. 이 trade-off는 실제 시스템 설계에서도 매우 중요하다.

네 번째 변수는 recovery protocol이다. 현재 평가는 주어진 prompt에 대한 단일 generation을 중심으로 한다. 하지만 실제 서비스에서는 검증기가 중간 오류를 발견했을 때 “Step 37부터 다시 계산하라”라고 요구할 수 있다. 모델이 오류 이후에 재동기화할 수 있는지, 혹은 한 번 잘못된 상태에 들어가면 계속 같은 오류를 반복하는지 측정하면, 단순 accuracy보다 더 유용한 복구 능력 지표를 만들 수 있다.

마지막으로, 사람과 모델의 비교도 의미가 있다. 사람도 95-step 산술 절차를 머릿속으로만 수행하면 쉽게 틀린다. 그러나 사람은 종이에 중간값을 적고, 변수 이름을 확인하고, 필요한 지점에서 검산하는 도구적 습관을 사용한다. 모델 평가에서도 scratchpad를 단순히 많이 쓰게 하는 수준을 넘어, 어떤 외부 기록 구조가 절차 실행을 안정화하는지 비교해야 한다. 이 방향은 LLM을 독립 계산기로 보기보다, 검증 가능한 작업자와 도구의 조합으로 보는 관점에 가깝다.

7.4 에이전트 환경으로 옮길 때 생기는 새로운 실패 모드

산술 절차에서는 모든 step이 텍스트 안에 있고, 기준 출력도 executor가 쉽게 계산한다. 에이전트 환경으로 옮기면 실패 표면이 넓어진다. 도구 호출은 외부 상태를 바꾸고, API 응답은 매번 달라질 수 있으며, 사람 승인이나 권한 오류 같은 비결정적 요소가 들어온다. 그럼에도 논문의 구조는 유지된다. 에이전트도 결국 “이전 단계의 결과를 다음 단계에 정확히 넣고, 지정된 순서와 종료 조건을 지킨다”는 요구를 받기 때문이다.

새로운 실패 모드 중 하나는 state aliasing이다. 산술에서는 $S_5$와 $S_6$가 명확히 다르지만, 실제 에이전트에서는 “사용자 프로필”, “현재 파일”, “최근 검색 결과”, “승인된 옵션”처럼 이름이 비슷한 상태들이 많다. 모델이 오래된 검색 결과를 최신 결과로 착각하거나, 테스트 환경 파일을 운영 환경 파일로 착각하면 절차 실행 오류는 곧 실제 부작용으로 이어진다. look-back dependency는 이런 state aliasing의 축소판으로 볼 수 있다.

또 다른 실패는 partial completion이다. 모델이 일부 단계를 수행하고도 전체 작업을 완료했다고 보고하는 경우다. 논문에서 under-execution이 증가한 결과는 이 현상의 수학적 버전이다. 실제 코딩 에이전트가 테스트를 일부만 실행하고 “검증 완료”라고 말하거나, 문서 요약 에이전트가 몇 개 파일만 읽고 전체 폴더를 요약했다고 말하는 사례가 여기에 해당한다. 따라서 절차 실행 감사는 완료 보고 직전에 반드시 필요한 레이어다.

도구 사용이 들어가면 over-execution도 더 위험해진다. 산술에서 추가 step을 hallucinate하면 숫자가 틀리는 것으로 끝나지만, 실제 workflow에서 지시되지 않은 도구 호출은 데이터 삭제, 잘못된 이메일 발송, 중복 결제 같은 문제를 만들 수 있다. 논문에서는 주된 실패 방향이 under-execution이지만, 배포 환경에서는 under와 over 모두 심각하다. 시스템은 필요한 단계를 덜 한 경우와 허용되지 않은 단계를 더 한 경우를 모두 탐지해야 한다.

이런 확장 관점에서 보면, 절차 실행 벤치마크는 reasoning benchmark와 agent benchmark 사이의 중간 계층을 제공한다. 완전한 웹 에이전트 환경은 변수가 너무 많아 실패 원인을 찾기 어렵고, 순수 산술 문제는 실제성에서 멀어 보일 수 있다. 이 논문의 controlled arithmetic procedure는 두 극단 사이에서 상태 추적, 단계 순서, 출력 commit이라는 기본 능력을 분리해 볼 수 있게 한다. 따라서 후속 agent 평가의 단위 테스트 역할을 할 수 있다.

8. 내 해석: 약점 하나와 후속 제안 하나로 본 절차 실행 진단의 의미

8.1 약점 1: 절차 충실성의 원인은 보이지만 내부 메커니즘은 아직 흐릿하다

나는 이 논문의 가장 큰 장점이 “정답률 너머”를 실제 측정 항목으로 바꾼 데 있다고 본다. 특히 exact-step execution이 줄고 under-execution이 늘어난다는 결과는 매우 직관적이면서도 강하다. 다만 약점 1은 이 행동적 분류가 왜 발생하는지에 대한 내부 메커니즘까지 충분히 밝히지는 못한다는 점이다. 모델이 오래된 $S_i$를 잊는 것인지, 토큰 생성 중 계산 부담을 회피하는 것인지, 답 태그를 내는 정책이 절차 수행보다 먼저 활성화되는 것인지는 아직 분리되어 있지 않다.

이 약점은 논문의 결론을 약화한다기보다, 다음 질문을 더 날카롭게 만든다. 논문은 모델이 절차를 중간에 멈추는 현상을 설득력 있게 보여 주지만, 그 원인을 memory retrieval, arithmetic primitive, output formatting, decoding policy, learned shortcut 중 어디에 더 두어야 하는지는 추가 진단이 필요하다. 나는 특히 answer position과 under-execution의 결합이 중요하다고 본다. 조기 answer가 높은 모델과 긴 trace를 만들지만 틀리는 모델은 서로 다른 실패 메커니즘을 가질 수 있기 때문이다.

8.2 후속 제안 1: 변수 주소 지정 오류를 추적하는 step-level auditor

내가 제안하고 싶은 후속 제안 1은 step-level auditor를 붙여 각 단계에서 모델이 참조한 변수 인덱스를 자동 추출하는 것이다. 단순히 몇 단계를 실행했는지 세는 것에서 더 나아가, Step $t$에서 기대한 입력이 $S_{t-1}$과 $S_{t-4}$였는데 모델이 $S_{t-2}$를 가져왔는지, 혹은 이전 값을 새 값으로 덮어썼는지를 기록하는 방식이다. 이렇게 하면 look-back dependency가 왜 어려운지 “깊은 참조라서 어렵다”보다 더 구체적으로 설명할 수 있다.

이 지점에서 나는 기존 SAVeR 2604.08401의 reasoning faithfulness와 Agent Belief Verification 맥락을 연결해 보고 싶다. SAVeR가 에이전트의 belief나 action commit을 검증하는 방향에 가까웠다면, 이번 논문은 commit 이전의 explicit procedure execution 자체를 통제된 산술 벤치마크로 감사한다. 둘은 서로 대체재가 아니다. Agent Belief Verification이 “에이전트가 무엇을 믿고 행동하는가”를 본다면, 이 논문은 “그 믿음이나 행동을 만들기 전, 주어진 절차를 실제로 한 줄씩 수행했는가”를 본다.

따라서 내가 보는 실용적 연결점은 다음과 같다. 에이전트 시스템에서는 action commit 전 단계에 procedural execution auditor를 두고, 이후 단계에 belief verification 또는 action verification을 둘 수 있다. 예를 들어 금융 규칙, 의료 triage, 보안 승인 흐름에서는 모델이 최종 결정을 내리기 전에 규정 절차의 각 조건을 수행했는지 먼저 검사하고, 그 다음에 그 결정이 현재 belief와 외부 상태에 맞는지 확인해야 한다. 이 논문은 그 첫 번째 레이어의 필요성을 잘 보여 준다.

8.3 내가 이 논문을 후속 시스템 설계로 옮긴다면

내가 이 논문을 실제 LLM 에이전트 시스템에 적용한다면, 먼저 절차를 모델의 자유 텍스트 안에만 두지 않을 것이다. 절차를 step id, required inputs, expected outputs, allowed next steps로 나눈 구조화 plan으로 만들고, 모델은 각 단계마다 사용한 입력 변수와 새로 만든 상태를 제출하게 할 것 같다. 그러면 모델이 중간에 어떤 변수를 잘못 가져왔는지, 어떤 단계에서 조기 종료했는지, 어떤 단계가 중복 실행됐는지 자동으로 확인할 수 있다.

두 번째로는 answer commit을 분리하겠다. 모델이 아무 때나 최종 답을 쓰게 하기보다, plan executor가 모든 required step의 상태를 확인한 뒤에만 final answer slot을 열어 주는 방식이다. 이렇게 하면 premature answer를 구조적으로 줄일 수 있다. 논문에서 answer position이 별도 지표가 된 이유도 여기에 있다. 답을 빨리 내는 모델이 항상 나쁘지는 않지만, 고위험 절차에서는 commit 시점을 시스템이 통제하는 편이 안전하다.

세 번째로는 lightweight deterministic checker를 함께 쓰겠다. 모든 절차가 산술처럼 완전 결정적이지는 않지만, 많은 업무에는 부분적으로 검증 가능한 항목이 있다. 파일이 존재하는지, 날짜 형식이 맞는지, 이전 단계 출력 id가 다음 단계 입력으로 들어갔는지, 승인 flag가 true인지 같은 검사는 모델보다 프로그램이 잘한다. 모델에게 모든 것을 맡기기보다, 모델은 후보 상태 전이를 만들고 checker는 상태 전이의 합법성을 확인하는 구조가 더 견고하다.

네 번째로는 실패 로그를 학습 데이터로 재활용하고 싶다. under-execution, wrong reference, malformed answer, extra step 같은 분류가 붙은 로그는 단순한 오답 데이터보다 훨씬 가치가 높다. 모델이 어떤 조건에서 절차를 멈추는지, 어떤 변수 이름을 자주 헷갈리는지, 어떤 연산에서 중간값을 잃는지 알 수 있기 때문이다. 이 논문의 failure mode taxonomy는 그런 데이터 수집 스키마의 초안으로 쓸 수 있다.

마지막으로, 나는 이 논문을 읽으며 reasoning 모델의 발전 방향을 “더 긴 사고” 하나로만 설명하면 부족하다고 느꼈다. 필요한 것은 더 긴 출력보다 더 안정적인 상태 전이다. 모델이 긴 trace를 만들더라도 중간값이 틀리면 의미가 없고, 짧은 trace를 만들더라도 모든 상태 전이가 검증 가능하면 실무에서는 더 낫다. 이 차이를 평가에 반영하는 것이 다음 세대 에이전트 안정성 연구의 핵심 과제가 될 가능성이 크다.

9. 결론: 절차를 따르는 능력은 별도로 측정되어야 한다

9.1 핵심 메시지: 모델의 reasoning 점수와 절차 실행 신뢰성은 다르다

이 논문은 LLM 평가에서 중요한 빈틈을 찌른다. 많은 모델이 reasoning benchmark에서 좋은 결과를 내지만, 사용자가 명시한 다단계 절차를 그대로 실행하는지는 별도로 검증해야 한다. 5-step에서 61%, 95-step에서 20%로 떨어지는 평균 first-answer accuracy는 절차 길이가 모델에게 실질적인 부담임을 보여 준다.

look-back1에서 look-back7로 갈 때 평균 18.43pp 하락한 결과도 중요하다. 절차 실행은 단순히 “많은 토큰을 기억한다”의 문제가 아니다. 모델은 어떤 중간 변수를 가져와야 하는지, 그 변수가 몇 단계 전에 만들어졌는지, 그 값을 현재 연산에 어떻게 넣어야 하는지를 안정적으로 관리해야 한다. 이 능력이 약하면 문맥 안에 모든 정보가 있어도 실행은 실패한다.

생성 레벨 분석은 결론을 더 강하게 만든다. exact-step execution은 70.88%에서 46.84%로 줄고 under-execution은 24.25%에서 50.87%로 증가한다. 즉 성능 저하는 단순 산술 오답만의 문제가 아니다. 모델은 긴 절차에서 필요한 단계 수를 채우기 전에 답을 내거나, 답 형식을 놓치거나, 중간 상태를 잃어버린다.

연산별 수치도 실무적 함의를 준다. 덧셈과 뺄셈에서는 매우 높은 성능을 보이는 모델도 곱셈과 나눗셈에서는 크게 흔들린다. 이는 “이 모델은 산술을 잘한다”라는 일반화가 위험하다는 뜻이다. 어떤 연산이 반복되는지, 중간값 규모가 어떻게 변하는지, 참조 깊이가 얼마나 되는지에 따라 절차 실행 신뢰도는 달라진다.

종합하면 이 논문은 절차 실행을 독립된 평가 대상으로 세우는 데 성공한다. 단순한 산술 벤치마크처럼 보이지만, 실제로는 LLM이 명시적 algorithm을 수행할 때 어디서 멈추고 어떻게 흔들리는지를 보여 주는 진단 도구다. 에이전트와 자동화 시스템을 설계할 때, 최종 답의 품질뿐 아니라 단계별 실행 로그와 중간 상태 검증을 함께 요구해야 한다는 교훈을 준다.

내가 특히 중요하게 보는 실무적 메시지는 정답 검증과 절차 검증의 분리다. 최종 숫자가 맞으면 사용자는 안심하기 쉽지만, 절차가 잘못되었는데 우연히 맞았거나 뒤늦게 고친 경우라면 같은 시스템을 더 어려운 입력에 적용했을 때 실패할 가능성이 크다. 반대로 최종 답이 틀렸더라도 어느 단계까지는 충실히 실행했다면, 해당 모델을 보조 executor나 중간 검산기와 결합해 개선할 여지가 있다.

또한 이 논문은 reasoning 모델을 평가할 때 “얼마나 오래 생각하는가”보다 “생각의 상태가 얼마나 안정적으로 갱신되는가”를 봐야 한다는 점을 강조한다. 긴 답변, 자세한 풀이, self-correction은 모두 유용할 수 있지만, 각각이 faithful state transition으로 이어지는지는 별도 문제다. 이 차이를 무시하면 모델의 설명력을 실제 실행 신뢰도로 과대평가하게 된다.

배포 환경에서는 이 결과를 기반으로 간단한 안전장치를 설계할 수 있다. 예를 들어 긴 procedure가 주어졌을 때 모델에게 한 번에 최종 답을 요구하기보다, 일정 간격마다 중간 변수와 참조 인덱스를 구조화된 형태로 제출하게 만들 수 있다. 시스템은 그 중간값을 deterministic checker로 확인하고, 오류가 발생하면 해당 단계부터 재실행하거나 인간 검토로 넘길 수 있다. 이런 구조는 모델의 약점을 숨기기보다 드러내고 통제하는 방식이다.

결국 이 논문의 가치는 “LLM은 산술을 못한다”라는 단순한 결론에 있지 않다. 더 정확히는 LLM이 명시된 절차를 얼마나 긴 시간 동안, 얼마나 깊은 참조 구조 속에서, 얼마나 안정적인 출력 규약으로 수행하는가를 측정해야 한다는 제안이다. 이 질문은 산술을 넘어 규정 준수, 데이터 처리, 에이전트 계획, 도구 호출, 자동 의사결정 전반으로 확장될 수 있다.

따라서 이 논문을 읽은 뒤 남는 가장 실용적인 질문은 모델 선택보다 평가 설계에 가깝다. 어떤 모델을 쓰든 긴 procedure를 맡긴다면, 서비스는 최종 답 하나를 받는 구조에서 벗어나 중간 상태를 기록하고, 검증 가능한 checkpoint를 두고, answer commit 시점을 통제해야 한다. 절차 실행 감사는 고위험 자동화에서 선택 기능을 넘어 기본 안전장치가 되어야 한다.

9.2 평가와 배포 사이에 놓아야 할 체크리스트

이 논문의 결과를 평가 체크리스트로 바꾸면 첫 항목은 절차 길이별 성능 곡선이다. 모델을 한두 개 예제로 확인하고 배포하는 대신, 실제 업무에서 예상되는 최소, 평균, 최대 단계 수를 정하고 그 길이에서 first-answer accuracy와 non-null answer rate를 따로 측정해야 한다. 특히 긴 절차가 드물게만 등장하더라도 실패 비용이 큰 업무라면 평균 성능보다 최장 절차 조건의 성능을 더 보수적으로 봐야 한다.

두 번째 항목은 참조 깊이다. 업무 절차에서 “앞에서 선택한 옵션”, “처음 업로드한 파일”, “이전 승인 결과”, “세 단계 전 계산값”처럼 오래된 상태를 다시 쓰는 부분이 얼마나 많은지 세어야 한다. 논문의 look-back 결과가 보여 주듯, 정보가 문맥에 남아 있어도 모델이 그것을 정확한 변수처럼 꺼내 쓰는 것은 별개의 능력이다. 따라서 state reference가 깊은 업무에는 추가 checkpoint나 구조화된 state store가 필요하다.

세 번째 항목은 answer 또는 action commit의 위치다. 모델이 절차 중간에 결론을 내거나 tool call을 먼저 실행하면 이후 검증이 무의미해질 수 있다. 시스템은 모델이 final answer를 제출하기 전에 필요한 step id가 모두 완료되었는지 확인해야 한다. 가능하면 모델 출력에서 final slot을 별도로 두고, 그 슬롯은 검증기가 intermediate state를 승인한 뒤에만 열리도록 설계하는 편이 안전하다.

네 번째 항목은 형식 준수와 값 검증의 분리다. JSON schema, XML tag, answer span이 맞는다고 해서 값이 맞는 것은 아니며, 값이 텍스트 어딘가에 등장한다고 해서 시스템이 그것을 안전하게 읽을 수 있는 것도 아니다. 이 논문이 non-null answer rate와 accuracy를 분리한 방식처럼, 실제 배포에서도 parser success, schema validity, semantic correctness, procedural completeness를 서로 다른 로그로 남겨야 한다.

다섯 번째 항목은 오류 복구 정책이다. 모델이 Step 40에서 틀렸다면 전체 procedure를 처음부터 다시 실행할지, 마지막 검증 checkpoint 이후부터 다시 실행할지, 혹은 인간에게 넘길지 정해야 한다. 이 정책이 없으면 모델은 같은 오류 상태에서 긴 출력을 계속 생성할 수 있다. 절차 실행 시스템에서는 실패를 감추는 것보다 실패 위치를 빨리 찾고 작은 범위에서 재실행하는 구조가 더 중요하다.

여섯 번째 항목은 모델별 조건부 사용 범위다. 어떤 모델은 짧은 절차와 덧셈·뺄셈 중심 업무에 충분할 수 있고, 어떤 모델은 긴 look-back이나 곱셈·나눗셈이 포함된 업무에서 추가 검산 없이는 쓰기 어렵다. 모델을 하나의 점수로 선택하기보다, 절차 길이, 참조 깊이, 연산 종류, 출력 형식 조건별로 “허용”, “검증 후 허용”, “자동화 금지” 같은 정책을 만드는 편이 논문의 결과와 잘 맞는다.

마지막 항목은 관찰 가능한 중간 로그다. 절차 실행은 최종 결과만 남기면 디버깅이 어렵다. 모델이 어떤 변수를 읽었고, 어떤 값을 만들었고, 언제 답을 제출했는지 남겨야 실패 원인을 찾을 수 있다. 이 논문의 generation-level analysis는 연구용 분석처럼 보이지만, 실제 운영에서는 장애 대응 로그의 설계 원칙으로 바꿀 수 있다. 절차형 작업에서 로그가 없으면 모델 개선도, 사용자 신뢰도, 사후 검증도 모두 약해진다.

9.3 이 논문을 읽고 남는 모델 개발 과제

모델 개발 관점에서 남는 첫 과제는 중간 상태를 학습 신호로 만드는 일이다. 지금 많은 후학습 데이터는 최종 답, 선호 비교, 풀이 품질에 초점을 둔다. 그러나 절차 실행에서는 각 step의 입력 변수, 출력 변수, 참조 인덱스, 종료 조건이 모두 supervision이 될 수 있다. 모델이 $S_t$를 계산할 때 어떤 이전 값을 읽어야 하는지 명시적으로 맞히게 하고, 잘못된 참조를 별도 loss로 벌한다면 장기 look-back 실패를 줄이는 방향의 학습이 가능하다.

두 번째 과제는 scratchpad 형식의 표준화다. 모델에게 자유롭게 생각하라고 하면 중간 계산이 자연어 문장 속에 흩어지고, 검증기는 어느 값이 현재 상태인지 파악하기 어렵다. 반대로 각 단계마다 `step_id`, `read`, `operation`, `write`, `value`를 구조화해 쓰게 하면, 모델 출력은 길어지더라도 검증 가능성이 크게 높아진다. 이 논문의 산술 procedure는 그런 구조화 scratchpad가 실제로 정확도를 얼마나 올리는지 실험하기 좋은 환경이다.

세 번째 과제는 모델 내부 표현과 외부 state store의 역할 분담이다. 모든 중간값을 모델의 attention 안에만 맡기면 look-back이 깊어질수록 오류가 누적된다. 반면 외부 table이나 key-value store에 각 $S_i$를 저장하고, 모델이 현재 step의 read/write 요청만 만들게 하면 절차 실행의 부담을 나눌 수 있다. 이 경우 모델 평가는 산술 능력보다 올바른 state access plan을 생성하는 능력으로 이동한다.

네 번째 과제는 self-correction을 commit 이전 단계로 끌어오는 것이다. Correct@Any가 first-answer보다 높다면 모델이 뒤늦게 맞는 답을 찾는 경우가 있다는 뜻이다. 하지만 자동화 시스템에서는 첫 답이 이미 소비될 수 있다. 따라서 모델이 answer tag를 내기 전에 자체 검산 루프를 수행하고, 검산이 통과한 뒤에만 단일 answer를 제출하도록 훈련하거나 decoding policy를 설계해야 한다. 이는 self-correction을 사후 설명에서 사전 검증으로 바꾸는 문제다.

마지막 과제는 benchmark 결과를 모델 카드에 반영하는 것이다. 모델 카드에는 일반적인 reasoning 점수뿐 아니라 절차 길이별 accuracy, look-back별 하락폭, non-null answer rate, under-execution rate 같은 지표가 들어갈 수 있다. 이렇게 하면 사용자는 모델이 어떤 종류의 자동화에 적합한지 더 구체적으로 판단할 수 있다. 특히 규정 준수, 계산 보조, 장기 도구 실행처럼 절차가 중요한 업무에서는 이런 지표가 일반 benchmark 점수보다 직접적인 안전 신호가 된다.

이와 함께 평가 데이터 생성 도구도 공개 가능한 형태로 정리될 필요가 있다. 논문의 synthetic procedure는 길이, 연산, look-back, 입력 범위를 조절할 수 있으므로, 연구자나 실무자가 자신이 쓰는 모델에 맞춰 작은 regression suite를 만들기 좋다. 예를 들어 새로운 모델 버전을 도입할 때마다 15-step, 45-step, 95-step 조건을 빠르게 돌려 이전 버전 대비 under-execution이 늘었는지 확인할 수 있다. 이런 회귀 테스트는 reasoning benchmark leaderboard보다 배포 안정성에 직접 연결된다.

더 나아가 절차 실행 평가는 모델 업데이트 이후의 성능 퇴행을 찾는 데도 유용하다. 일반 대화 품질이 좋아진 모델이 구조화된 절차 실행에서는 더 자주 조기 답변을 낼 수 있고, 반대로 형식 제약이 강화된 모델이 중간 계산을 과도하게 생략할 수도 있다. 따라서 절차 실행 지표는 모델 릴리스 검증에서 별도 항목으로 남겨야 한다. 이 논문은 그 항목을 어떻게 작게 만들고, 어떤 실패 모드를 함께 기록해야 하는지 보여 주는 사례다.

요약하면, 절차 실행 평가는 모델의 지식량이나 대화 품질을 보완하는 별도 안전 계층이다. 사용자는 모델이 답을 알고 있는지뿐 아니라, 주어진 순서와 중간 상태를 지키며 답에 도달했는지를 확인해야 한다. 이 논문은 그 확인을 작은 산술 세계에서 시작하지만, 실제 자동화 시스템으로 옮겼을 때도 같은 원칙이 유지되며, 작은 회귀 테스트와 운영 로그 설계까지 함께 바꾼다.

10. 요약 정리: 이 논문에서 기억할 포인트

• 논문은 LLM의 procedural execution, 즉 프롬프트에 명시된 단계별 산술 알고리즘을 정확히 실행하는 능력을 진단한다.
• 과제는 $S_1=x$, $S_2=y$에서 시작해 $S_3$ 이후 중간 변수를 $+$, $-$, $\times$, $\div$로 계산하고 마지막 값을 세 자리 반올림해 반환하는 구조다.
• 복잡도는 단계 수 $T=5,15,25,\dots,95$, look-back dependency 1부터 7, 입력 범위, 데이터 타입, operation variant로 조절된다.
• 벤치마크는 55 datasets, 55,000 examples로 구성되며, 1.5B급부터 685B급까지 총 14개 모델을 평가한다.
• 평균 first-answer accuracy는 5-step 61%에서 95-step 20%로 크게 떨어져, 긴 절차 유지가 모델에게 어려운 문제임을 보여 준다.
• look-back1에서 look-back7로 증가하면 평균 정확도가 18.43pp 하락해, 오래된 중간값을 찾아 쓰는 능력이 중요한 병목임을 드러낸다.
• exact-step execution은 70.88%에서 46.84%로 감소하고 under-execution은 24.25%에서 50.87%로 증가해, 실패의 핵심이 절차 조기 중단과 상태 추적 붕괴에 있음을 시사한다.
• operation별로는 덧셈과 뺄셈이 강하고 곱셈과 나눗셈이 취약한 경향이 뚜렷하며, 대형 모델도 곱셈과 나눗셈 장기 실행에서는 완전히 안정적이지 않다.
• 내 해석상 이 논문은 SAVeR와 Agent Belief Verification이 다루는 믿음과 행동 검증 이전 단계에서, 명시적 절차 실행 자체를 감사해야 한다는 필요성을 잘 보여 준다.