긴 추론을 쓰는 모델이 답을 못 냈을 때 가장 쉬운 처방은 출력 토큰을 더 주는 것이다. 중간에서 잘렸다면 더 오래 생각하게 하면 된다는 논리다. 이번 실험은 그 처방이 실제 실패 원인을 고치는지 확인하려고 했다.
대상은 64바이트 입력을 검사하는 x86-64 바이너리 역공학 문제였다. 로컬 30B 모델에 원본 요청과 정적 증거만 주고, 알려진 답·이전 모델 출력·힌트·외부 접근·재시도를 모두 막았다. 먼저 공식 sampled 설정에서 출력 한도 4,096토큰으로 한 번 실행했다. 이어 65,536토큰 컨텍스트에서 입력 37,098토큰을 확인한 뒤, 출력 한도를 정확히 네 배인 16,384토큰으로 늘려 다시 한 번 독립 실행했다.
4,096토큰 실행은 677.215초 동안 초당 6.05토큰을 생성했다. 4,093개의 reasoning 조각과 11,278자의 내부 추론이 남았지만, 사용자에게 내놓을 본문·도구 호출·후보 답안은 모두 0바이트였다. 종료 이유는 길이 제한이었다.
16,384토큰 실행도 양상은 같았다. 모델은 초당 5.93토큰으로 16,384토큰을 전부 추론에 썼고, reasoning 원문은 47,353바이트까지 늘었다. 그런데 후보 답안은 다시 0바이트였다. 서버 오류, OOM, fallback, 중복 completion은 없었다. 요청은 정상적으로 한 번 처리됐고 모델만 답안을 제출하지 않았다.
토큰이 부족해서 핵심을 못 본 것도 아니었다. 모델은 64바이트 길이 검사와 네 개의 작은 helper 함수가 push, lookup, XOR, compare에 해당한다는 구조까지 찾아갔다. 문제는 그다음이었다. RIP-relative 주소와 상태 플래그의 의미를 여러 번 다시 계산하고 같은 가설을 반복했지만, 전체 연산열을 제약식으로 옮기지 못했다.
별도의 결정론적 풀이가 이 차이를 확인해 줬다. 바이너리의 작은 스택 머신을 그대로 에뮬레이션하자 64개의 방정식이 나왔고 rank도 64였다. 제약 검사는 통과했고 실제 바이너리 실행으로 정답을 검증할 수 있었다. 문제는 풀 수 없었던 게 아니라, 모델이 관찰한 구조를 실행 가능한 풀이로 바꾸지 못한 것이었다.
이 결과는 긴 추론 자체를 부정하지 않는다. 다만 출력 예산은 현재 사고 경로를 연장할 뿐, 그 경로를 자동으로 고쳐 주지는 않는다. 4,096토큰 동안 진전 없이 반복한 모델은 16,384토큰에서도 더 긴 반복을 만들 수 있다. reasoning 토큰 수와 문제 해결 진척도를 같은 값으로 취급하면 안 된다.
운영 설계도 달라져야 한다. 에이전트형 실행에서는 최종 답안 몫을 따로 남기고, 새 제약식·새 도구 결과·새 후보가 일정 구간 동안 나오지 않으면 경로를 중단해야 한다. 다음 시도는 단순 연장이 아니라 방법 변경이어야 한다. 예를 들면 call stream을 파서로 추출하고, 상태 전이를 표로 고정한 뒤, 제약식 생성기로 넘기는 식이다.
이 실험은 한 모델, 한 양자화, 한 sampled seed, 한 문제에 대한 독립 실행 두 건이다. 모든 reasoning 모델이나 다른 과제에 그대로 일반화할 수는 없다. 그래도 “조금만 더 생각시키면 된다”는 처방은 이 사례에서 기각됐다. 출력 한도를 네 배로 늘렸더니 답이 늦게 나온 것이 아니라, 제출되지 않은 생각만 네 배 가까이 쌓였다.