Xue Jiang, Tianyu Zhang, Ge Li, Mengyang Liu, Taozhi Chen, Zhenhua Xu, Binhua Li, Wenpin Jiao, Zhi Jin, Yongbin Li, Yihong Dong · Peking University & Tongyi Lab, Alibaba · 2026

Think Anywhere in Code Generation

이 논문은 코드 생성을 "사전 계획이 아닌, 필요한 순간에 즉각 생각하는 과정"으로 바라본다 — 인간 개발자가 코드를 작성하다가 복잡한 부분에서 멈춰 생각하듯, LLM도 임의의 토큰 위치에서 온디맨드로 추론을 호출할 수 있어야 한다.

arXiv → GitHub →
code generation chain-of-thought RLVR GRPO inline reasoning token-level thinking

문제의 배경 — 기존 연구의 한계

최근 LLM(대형 언어 모델)의 코드 생성 능력은 놀라운 수준으로 향상되었습니다. 이 발전의 핵심 동력은 업프론트 씽킹(upfront thinking)이라고 불리는 메커니즘입니다 — 코드를 생성하기 전에 먼저 <think>...</think> 블록 안에서 충분히 추론한 다음 코드를 출력하는 방식이죠.

Chain-of-Thought(CoT) 프롬프팅(Wei et al., 2022)을 시작으로, Self-Planning(Jiang et al., 2024), DeepSeek-R1, OpenAI o1, Kimi K2 등 최신 추론 최적화 모델들은 모두 이 패턴을 따릅니다. RL(강화학습)을 통해 추론 능력을 확장한 Skywork-OR1, OlympicCoder, CodeBoost, CodeRL+ 등의 포스트트레이닝 방법들도 마찬가지입니다.

업프론트 씽킹의 두 가지 구조적 한계

한계 1 사전 추론의 불충분성: 문제의 전체 복잡성은 코드를 실제로 구현하는 과정에서야 드러납니다. LLM은 업프론트 추론 단계에서 보통 "계획 수준"의 사고만 수행하지만, 실제 구현 단계에서 새로운 문제가 등장합니다. 예를 들어, 동적 프로그래밍 배열의 인덱싱 오류(1-based vs. 0-based 충돌)는 코드를 작성하다가 인지되는 문제이지, 사전 계획에서 발견하기 어렵습니다.
한계 2 추론 자원의 비효율적 배분: 코드의 위치마다 난이도가 크게 다릅니다. 단순한 보일러플레이트 코드는 깊은 추론이 필요 없지만, 복잡한 알고리즘 결정이나 엣지 케이스 처리는 심층 추론이 필요합니다. 업프론트 씽킹은 이 불균일성을 반영하지 못하고, 코드 생성 전에 모든 가능한 구현 문제를 사전에 예측하려다 보니 긴 추론 트레이스가 생성됩니다.
"upfront thinking is often insufficient, as the full complexity of problems typically only reveals itself during implementation... upfront thinking cannot precisely allocate reasoning effort to the positions where it is needed."

업프론트 씽킹은 종종 불충분합니다 — 문제의 전체 복잡성은 보통 구현 과정에서야 드러나기 때문입니다... 또한 추론 노력을 필요한 위치에 정확히 배분하지 못합니다.

보충 인간 개발자의 코딩 인지(coding cognition) 연구에 따르면, 개발자들은 코딩 전에만 생각하는 것이 아니라 구현 도중 복잡한 부분에서 멈추어 생각합니다. 이는 "필요한 순간에 생각하는" 방식이 더 자연스럽고 효율적임을 시사합니다. THINK-ANYWHERE는 이 관찰에서 출발합니다.

기존 Interleaved Thinking(Xie et al., 2025; Liang et al., 2025)은 각 서브스텝마다 추론을 강제하지만, 이는 불필요한 계산 오버헤드를 도입하고 가장 어려운 부분에 더 깊은 추론을 배분하는 유연성이 없습니다. 따라서 이 논문은 "임의의 토큰 위치에서 온디맨드로 추론을 호출할 수 있는" 메커니즘이 필요하다고 주장합니다.

이 논문의 선택 — 핵심 아이디어와 트레이드오프

핵심 아이디어 THINK-ANYWHERE: 코드 생성 중 임의의 토큰 위치에서 <thinkanywhere>...</thinkanywhere> 블록을 호출할 수 있는 메커니즘. 모델은 코드를 작성하다가 복잡도가 높은 순간을 스스로 감지하고, 그 자리에서 즉각 추론을 삽입합니다.

핵심 통찰은 간단합니다: 추론이 코드 전체에 걸쳐 필요한 곳에 분산되어야 한다면, 추론 호출도 코드 어디서나 가능해야 한다.

왜 이 접근법인가?

대안으로 "모든 서브스텝마다 추론"(Interleaved Thinking)을 고려할 수 있습니다. 하지만 이 방식은 추론이 필요 없는 단순한 코드 라인에서도 추론을 강제하여 불필요한 계산 비용이 발생합니다. THINK-ANYWHERE는 반대로, 모델이 스스로 언제 추론이 필요한지를 학습하도록 설계되었습니다. 이를 통해 추론 자원을 복잡도가 실제로 높은 위치에 집중할 수 있습니다.

트레이드오프: 무엇을 포기했는가?

포기한 것 단순한 학습 방식: "어디서 생각할지"는 지도학습 데이터만으로 가르치기 어렵습니다. 모델이 자신만의 고복잡도 순간을 판단해야 하므로, 복잡한 2단계 훈련 파이프라인(콜드스타트 + RLVR)이 필요합니다. 순수 프롬프팅이나 SFT만으로는 성능이 베이스 모델보다 오히려 낮아집니다.
얻은 것 효율 + 성능 동시 달성: THINK-ANYWHERE는 업프론트 씽킹 구간을 단축하면서 <thinkanywhere> 블록을 필요한 곳에만 추가합니다. 결과적으로 총 토큰 비용이 줄면서도 성능은 SOTA를 달성합니다.

THINK-ANYWHERE 메커니즘 시각화

기존: 업프론트 씽킹 입력 x ⟨think⟩...⟨/think⟩ 전체 추론 (긺) 코드 출력 ❌ 구현 중 버그 추가 추론 불가 THINK-ANYWHERE 입력 x ⟨think⟩ 간략 계획 code₁ ⟨thinkanywhere⟩ 온디맨드 추론 code₂ … ✓ 최종 코드 👆 각 블록을 클릭하면 설명이 표시됩니다

방법론

§3.1 THINK-ANYWHERE의 형식적 정의

업프론트 씽킹과 THINK-ANYWHERE를 수식으로 비교해봅니다. x는 코딩 요구사항(requirement), c는 생성된 코드를 나타냅니다.

업프론트 씽킹의 생성 확률 분해:

\[ P(c, s \mid x) = \underbrace{P(s \mid x)}_{\text{upfront reasoning}} \cdot \underbrace{P(c \mid x, s)}_{\text{code generation}} \]
변수의미비고
x코딩 요구사항 (입력 프롬프트)–
s⟨think⟩...⟨/think⟩ 블록 내 추론 트레이스코드 생성 전에 완성
c생성된 최종 코드s에 조건부

직관적 해설

이 식은 추론(s)과 코드 생성(c)이 순차적으로 분리된 구조를 나타냅니다. 추론이 완전히 끝난 뒤에야 코드 생성이 시작됩니다. 즉, 코드 작성 중에 새로운 문제가 생겨도 추론 블록으로 되돌아갈 수 없습니다.

수학적 의미

추론 s는 오직 입력 x에만 조건부이고, 코드 c는 x와 s 모두에 조건부입니다. 이는 정보 흐름이 단방향 — x → s → c — 임을 의미합니다. 구현 중 복잡도가 발생해도 s를 수정할 경로가 없습니다.

THINK-ANYWHERE의 생성 시퀀스:

\[ y = (s,\; c^{(1)},\; h^{(1)},\; c^{(2)},\; h^{(2)},\; \ldots,\; c^{(M)},\; h^{(M)},\; c^{(M+1)}) \]
변수의미비고
y전체 혼합 시퀀스 (코드 + 인라인 추론)–
s초기 ⟨think⟩ 블록 (업프론트 추론, 짧아진 버전)선택적이지만 권장
c^(i)i번째 코드 세그먼트–
h^(i)i번째 ⟨thinkanywhere⟩ 블록 (인라인 추론)–
M삽입된 thinkanywhere 블록의 수M ≥ 0, 모델이 동적으로 결정

직관적 해설

코드와 추론 블록이 교대로 등장합니다. 모델은 코드를 쓰다가 "여기서 생각이 필요하다"고 판단하면 ⟨thinkanywhere⟩ 블록을 삽입하고, 추론을 마친 뒤 코드 작성을 재개합니다. M과 h^(i)의 위치는 모델이 실시간으로 결정합니다.

업프론트 씽킹과의 관계

M=0이고 s가 코드 생성 전에만 존재하면, 이는 정확히 업프론트 씽킹과 동일합니다. 즉, 업프론트 씽킹은 THINK-ANYWHERE의 특수 케이스입니다.

THINK-ANYWHERE의 생성 확률 분해:

\[ P(y \mid x) = P(s \mid x) \cdot \prod_{i=1}^{M} \left[ P(c^{(i)} \mid x, y_{<c^{(i)}}) \cdot P(h^{(i)} \mid x, y_{<h^{(i)}}) \right] \cdot P(c^{(M+1)} \mid x, y_{<c^{(M+1)}}) \]
변수의미비고
y<c^(i)c^(i) 이전의 모든 토큰이전 코드 + 추론 블록 모두 포함
y<h^(i)h^(i) 이전의 모든 토큰이전 코드 + 추론 블록 모두 포함

직관적 해설

각 코드 세그먼트와 추론 블록은 그 이전의 모든 내용(코드 + 인라인 추론)을 컨텍스트로 받습니다. 이는 이전 코드 작성 과정이 다음 추론에, 이전 추론이 다음 코드에 영향을 미치는 양방향 정보 흐름을 가능하게 합니다.

최종 코드 추출 방법

최종 실행 코드 c는 y에서 모든 추론 블록을 제거하여 얻습니다: \( c = c^{(1)} \oplus c^{(2)} \oplus \cdots \oplus c^{(M+1)} \) — 여기서 ⊕는 시퀀스 연결(concatenation)을 의미합니다. 코드는 모든 ⟨thinkanywhere⟩ 블록을 제거해도 유효하고 실행 가능해야 합니다.

§3.2 콜드스타트 훈련 (Cold-Start Training)

LLM은 코드 생성 중 자발적으로 추론 블록을 호출하지 않습니다 — 심지어 명시적인 프롬프트 지시도 이 동작을 신뢰성 있게 유도하지 못합니다. 따라서 먼저 모델에게 "어디서든 생각할 수 있다"는 기초 능력을 훈련으로 가르쳐야 합니다.

자동 데이터 구성: 강력한 추론 LLM(Google Gemini 2.5 Flash)에게 Table 1의 템플릿을 사용하여 코딩 문제를 풀게 합니다. 이때 모델이 코드 작성 중 숙고가 필요한 위치에 ⟨thinkanywhere⟩ 블록을 삽입하도록 유도합니다. 잘못된 형식(블록 경계 오류, 토큰 중첩 오류)을 가진 샘플은 필터링하지만, 코드 정확성과 무관하게 올바르게 포맷된 샘플은 모두 유지합니다(약 5,000개). 이는 올바른 풀이와 틀린 풀이 모두가 학습에 기여한다는 선행 연구(Li et al., 2025a)를 따릅니다.

LoRA 기반 SFT: 구성된 학습 데이터로 LoRA(Hu et al., 2022)를 사용한 지도학습 파인튜닝을 수행합니다. 전체 파라미터 SFT 대비 LoRA가 유사한 성능을 내면서도 강건성이 높고 계산 비용이 낮습니다.

전용 추론 트리거 토큰 (THINK-ANYWHERE*)

기본 구현에서 <thinkanywhere>는 여러 일반 토큰으로 분리됩니다(예: "think", "any", "where"). 이는 두 가지 문제를 만듭니다: (1) 동일한 토큰이 어휘적 의미와 제어 신호로 이중 역할을 해 의미 모호성이 생기고, (2) 멀티토큰 구분자는 단일 제어 결정의 예측 경로를 길게 만들어 트리거 신뢰성이 낮아집니다.

해결책으로 새로운 단일 어휘 항목인 <ta>와 </ta> 토큰을 도입합니다. 문제는 무작위 초기화된 새 토큰을 효과적으로 학습하기 어렵다는 것입니다. 이를 위해 의미 인식 초기화(semantic-aware initialization) 전략을 제안합니다:

\[ e_{\langle ta \rangle} = 0.5 \cdot \text{mean}(e_{\text{think}}, e_{\text{any}}, e_{\text{where}}) + 0.5 \cdot e_{\langle im\_start \rangle} \] \[ e_{\langle /ta \rangle} = 0.5 \cdot \text{mean}(e_{\text{think}}, e_{\text{any}}, e_{\text{where}}) + 0.5 \cdot e_{\langle im\_end \rangle} \]
변수의미비고
e<ta>새 오프닝 특수 토큰 임베딩–
e</ta>새 클로징 특수 토큰 임베딩–
mean(e_think, e_any, e_where)"think anywhere"의 의미적 내용 인코딩0.5 가중치
e<im_start>, e<im_end>기존 구분자 토큰 (모드 전환 경계 역할)0.5 가중치

왜 이 초기화인가

두 정보 소스를 혼합합니다: 첫 번째 항은 "think anywhere"의 의미적 의도를 인코딩하고, 두 번째 항은 기존 <im_start>/<im_end> 토큰으로부터 "모드 전환 경계" 역할을 상속합니다. 모델은 이미 사전훈련에서 <im_start>/<im_end>를 모드 전환 신호로 학습했으므로, 이 구조적 동작을 새 토큰에 이전할 수 있습니다.

2단계 콜드스타트 절차

Stage 1: 모델 파라미터를 동결하고 입력 임베딩과 LM 헤드 가중치만 학습합니다 — 토큰이 기존 능력을 방해하지 않고 적절한 표현을 발전시킵니다. Stage 2: 특수 토큰 임베딩과 LM 헤드를 LoRA 어댑터와 함께 공동으로 파인튜닝합니다.

§3.3 RLVR을 통한 최적 사고 위치 학습

콜드스타트 훈련은 모델에게 "어디서든 생각할 수 있다"는 기초 능력을 줍니다. 하지만 "어디서 생각해야 하는가"는 지도학습으로 가르치기 어렵습니다 — 이는 패턴 매칭을 넘어서는 적응적 판단을 요구합니다. 이를 위해 RLVR(Reinforcement Learning with Verifiable Rewards)을 적용합니다.

GRPO 알고리즘: Proximal Policy Optimization(PPO)과 달리 별도의 값 모델 없이 그룹 수준 통계에서 기준선(baseline)을 계산합니다. 각 입력 x에 대해 현재 정책 π_θ에서 G개의 후보 출력 {y₁, ..., y_G}를 샘플링합니다.

\[ \hat{A}_i = \frac{R(y_i) - \text{mean}(\{R(y_j)\}_{j=1}^G)}{\text{std}(\{R(y_j)\}_{j=1}^G)} \]
변수의미비고
Â_i그룹 정규화된 어드밴티지그룹 평균 대비 상대적 성능
R(y_i)출력 y_i에 대한 보상구조 보상 + 정확성 보상
G그룹 크기 (각 입력당 샘플 수)본 논문에서 G=8

직관적 해설

같은 입력에 대해 여러 출력을 생성하고, 그 중 평균보다 좋은 출력을 강화합니다. 별도의 값 함수 없이 그룹 내 통계만으로 기준선을 계산하므로 계산 비용이 PPO보다 낮습니다.
\[ \mathcal{L}_{\text{GRPO}}(\theta) = \mathbb{E}\left[ \min\left( \rho_i \hat{A}_i,\; \text{clip}(\rho_i, 1-\epsilon, 1+\epsilon)\hat{A}_i \right) - \beta \cdot D_{\text{KL}}(\pi_\theta \| \pi_{\text{ref}}) \right] \]
변수의미비고
ρ_i확률 비율 π_θ(y_i|x) / π_old(y_i|x)정책 업데이트 크기를 제어
ε클리핑 임계값너무 큰 정책 업데이트 방지
βKL 패널티 강도참조 정책에서 너무 멀리 벗어나지 않도록
π_ref참조 정책 (일반적으로 초기 SFT 모델)–

직관적 해설

PPO의 클리핑 대리 목적 함수에 KL 다이버전스 패널티를 추가한 형태입니다. 클리핑은 정책이 한 번에 너무 크게 변하지 않도록 안정화하고, KL 패널티는 참조 정책에서 너무 멀어지는 것을 방지합니다.

계층적 보상 함수 (Hierarchical Reward)

\[ R(y) = \alpha \cdot R_{\text{struct}}(y) + R_{\text{correct}}(y) \] \[ R_{\text{struct}}(y) = \mathbf{1}\left[\text{HasInitialThinking}(y) \wedge \text{HasThinkAnywhere}(y)\right] \] \[ R_{\text{correct}}(y) = \mathbf{1}\left[\text{PassAllTests}(c)\right] \]
변수의미비고
α = 0.1구조 보상 가중치정확성 보상 대비 소규모
R_struct ∈ {0,1}THINK-ANYWHERE 형식 준수 여부초기 think 블록 + 최소 1개의 thinkanywhere 블록 필요
R_correct ∈ {0,1}테스트 케이스 통과 여부코드 실행 결과 기반

왜 계층적인가

두 보상이 "게이트 방식"으로 결합됩니다. R_struct는 모델이 THINK-ANYWHERE 형식(초기 think 블록 + 적어도 하나의 thinkanywhere 블록)을 유지하도록 유도하고, R_correct는 생성된 코드의 기능적 정확성을 보상합니다. α=0.1로 구조 보상을 상대적으로 작게 유지하여, 모델이 형식을 따르면서도 주로 정확성 향상에 집중하도록 합니다.

설계 의도

R_struct 없이는 모델이 RL 과정에서 thinkanywhere 블록을 포기하고 업프론트 씽킹으로 회귀할 수 있습니다. R_struct는 이를 방지하여 THINK-ANYWHERE 행동 패턴을 유지하게 합니다.

전체 훈련 파이프라인 (스텝 플레이어)

스텝 1 / 4
베이스 LLM Qwen2.5-Coder-7B 데이터 구성 Gemini 2.5 Flash로 ~5,000샘플 생성 콜드스타트 SFT LoRA 파인튜닝 THINK-ANYWHERE 패턴 학습 RLVR (GRPO) 최적 사고 위치 탐색 14K 문제, 8 A100 GPU

훈련 단계별 <thinkanywhere> 블록 통계 [부록 추가: Appendix B]

각 훈련 단계에서 <thinkanywhere> 블록의 평균 빈도(Avg.Freq)와 평균 길이(Avg.Len)를 분석합니다. 이는 콜드스타트 SFT와 RLVR의 기여를 명확히 보여줍니다.

데이터셋모델Avg.FreqAvg.Len (토큰)
HumanEval Base Model00
THINK-ANYWHERE (Prompting)0.24113.5
THINK-ANYWHERE (SFT)6.6931.9
THINK-ANYWHERE (Ours, RL)6.1522.5
MBPP Base Model00
THINK-ANYWHERE (Prompting)0.5366.4
THINK-ANYWHERE (SFT)5.7633.4
THINK-ANYWHERE (Ours, RL)5.2423.2
LeetCode Base Model00
THINK-ANYWHERE (Prompting)0.31219.7
THINK-ANYWHERE (SFT)11.2834.5
THINK-ANYWHERE (Ours, RL)11.2622.9

이 데이터가 보여주는 핵심 패턴: RL 훈련 이후 블록 빈도는 SFT와 거의 동일하지만 블록 길이는 감소합니다 — RL이 추론 횟수가 아니라 추론의 질을 개선한다는 증거입니다. Prompting 단계의 비정상적으로 긴 블록 길이(219.7 토큰)는 모델이 패턴을 제대로 학습하지 못했음을 나타냅니다.

구현 세부사항

항목설정값
베이스 모델Qwen2.5-Coder-7B-Instruct
RL 프레임워크VeRL (Sheng et al., 2024)
콜드스타트 데이터 수~5,000 샘플
콜드스타트 데이터 생성Google Gemini 2.5 Flash
RL 훈련 코퍼스Skywork 데이터셋 14K 문제
배치 크기 / 미니배치128 / 64
학습률1e-6
훈련 에포크2
문제당 롤아웃8
최대 토큰 길이4096
GPU8 × NVIDIA A100 (40G)
평가 샘플링greedy (temperature=0)
LoRA 파인튜닝전체 파라미터 SFT 대신 사용 (더 강건함)
소스 코드github.com/jiangxxxue/Think-Anywhere

결과

핵심 성능 지표

70.3%
4개 벤치마크 평균
베이스 모델 대비 +9.3%p
69.4%
LeetCode pass@1
GRPO(63.3%) 대비 +6.1%p
17.3%
AIME 2024 pass@1
코드만 훈련 → 수학으로 일반화
+13.9%
1.5B 모델 향상폭
소형 모델에서 특히 효과적

메인 결과 비교 (Table 2)

방법 LeetCode LiveCodeBench HumanEval MBPP 평균
Base Model (Qwen2.5-Coder-7B) 50.634.388.470.761.0
Post-Training OlympicCoder 45.330.975.661.058.0
Post-Training OCR-Qwen-7B 53.333.086.867.262.5
Post-Training CodePRM 52.834.888.458.960.2
Post-Training CodeBoost 53.334.687.273.965.7
Post-Training CodeRL+ 63.336.990.965.766.8
Reasoning CoT 53.930.986.677.762.3
Reasoning Self-Planning 49.231.186.977.961.3
Reasoning Interleaved Thinking 50.630.786.479.261.7
Reasoning GRPO 67.336.088.681.768.4
Think-Anywhere (Prompting) 41.134.484.867.456.9
Think-Anywhere* (SFT) 46.732.579.978.259.3
Think-Anywhere* (Ours, 특수 토큰) 68.936.790.284.570.0
Think-Anywhere (SFT) 47.932.382.979.460.6
Ours Think-Anywhere (Ours) 69.437.291.582.970.3

벤치마크별 성능 차트

에블레이션 스터디 (Table 5)

각 컴포넌트의 기여도를 LeetCode 벤치마크에서 분석합니다.

방법 변형LeetCode pass@1베이스 대비 Δ의미
Ours Think-Anywhere (완전체) 69.4% – 콜드스타트 + RLVR 완전 파이프라인
Only Cold Start (SFT만) 47.9% -21.5% 지도학습만으로는 효과적인 사고 위치 학습 불가
Only RLVR (콜드스타트 없이) 63.4% -6.0% 콜드스타트 초기화가 RL 안정화에 중요
Line-level Thinking 67.2% -2.2% 라인 단위 제한이 최적 위치 선택을 방해
No Upfront Thinking 66.6% -2.8% 초기 think 블록 제거 시 소폭 하락 (thinkanywhere가 주 기여)
Padding Thinking 67.6% -1.8% 추론 내용도 중요하나, 위치 선택 자체도 기여함

교차 도메인 일반화 — 수학 추론 (Table 3)

코드 생성 태스크만으로 훈련된 THINK-ANYWHERE를 수학 추론 벤치마크에 직접 평가합니다.

방법 AIME 2024 AIME 2025 HMMT 2025
pass@1pass@5pass@10 pass@1pass@5pass@10 pass@1pass@5pass@10
Base Model 5.314.620.0 4.013.416.7 0.00.00.0
GRPO 6.016.823.3 4.717.226.7 0.31.73.3
Ours THINK-ANYWHERE 17.332.940.2 17.728.033.2 14.418.519.6

보충 AIME 2024 pass@1 기준 베이스 모델 5.3% → THINK-ANYWHERE 17.3%로 3배 이상 향상되었습니다. 코드 도메인에서 학습한 "온디맨드 추론" 능력이 수학 도메인으로 전이된다는 것을 보여줍니다. 이는 THINK-ANYWHERE가 특정 도메인에 과적합되지 않고 범용적인 추론 능력을 향상시킨다는 것을 시사합니다.

다양한 LLM에서의 일반화 (Table 4)

모델Base Model+ GRPO+ Think-Anywhere베이스 대비 향상
Qwen2.5-Coder-7B-Instruct 61.068.470.3+9.3%
Qwen2.5-Coder-1.5B-Instruct 40.651.954.5+13.9%
LLaMA-3.1-8B-Instruct 38.442.043.8+5.4%

사고 위치 분석

THINK-ANYWHERE가 "어디서" 추론을 호출하는지 분석합니다. 두 가지 관점에서 LeetCode 벤치마크의 생성된 솔루션을 분석했습니다.

토큰 엔트로피 분석: 모델이 <thinkanywhere>를 호출한 위치에서, thinkanywhere가 활성화된 경우와 비활성화된 경우의 엔트로피 차이를 계산합니다. 결과는 이 차이가 대부분 양수로 나타났습니다 — 즉, thinking이 비활성화될 때 해당 위치의 토큰 엔트로피가 더 높다는 것을 의미합니다. 이는 모델이 스스로 불확실성이 높다고 예측하는 위치에서 <thinkanywhere>를 호출한다는 것을 보여줍니다.

구문론적 컨텍스트 분석: AST 파서를 사용하여 <thinkanywhere>가 호출된 위치의 구문 범주를 식별했습니다. 가장 많이 호출되는 순서는 다음과 같습니다:

  1. Assign (할당문): 복잡한 계산이나 변수 업데이트를 포함하는 경우가 많아 중간 추론의 이점이 큼
  2. Return (반환문): 함수 종료 전 최종 출력의 정확성을 확인하려는 경향
  3. Expr (표현식)
  4. If (조건문)
  5. AugAssign (복합 할당문, 예: +=)

보충 이 분석은 THINK-ANYWHERE의 "해석 가능성(interpretability)" 기여를 보여줍니다. 모델이 어디서 어떤 이유로 추론을 호출하는지 관찰할 수 있어, 코드 생성의 의사결정 과정을 투명하게 이해할 수 있습니다.

계산 효율성: 토큰 비용 비교 (Figure 3 + Appendix Table 6)

THINK-ANYWHERE의 업프론트 씽킹 구간이 GRPO/CoT 대비 크게 단축되고, 추가되는 <thinkanywhere> 블록 비용은 작습니다 (HumanEval 기준: GRPO 309.4토큰 → THINK-ANYWHERE 업프론트 215.6 + thinkanywhere 22.5 = 238.1 토큰으로 net 감소).

한계점 & 트레이드오프

한계 1 특수 토큰 변형의 데이터 제약: THINK-ANYWHERE* (특수 토큰 변형)는 텍스트 기반 버전(70.3%)과 유사한 70.0%를 달성하지만, 제한된 포스트트레이닝 데이터로 인해 새 토큰의 의미론적 학습이 충분하지 않습니다. 저자들은 이 변형이 대규모 사전훈련에 네이티브하게 통합되면 더 큰 잠재력을 발휘할 것이라고 언급합니다.
special token pretraining vocabulary expansion
한계 2 복잡한 2단계 훈련 파이프라인: 콜드스타트 SFT → RLVR의 2단계 구조는 단순 GRPO 대비 훈련 복잡성과 비용이 증가합니다. Only RLVR (콜드스타트 없이) 실험에서 pass@1이 69.4% → 63.4%로 낮아지는 것은 콜드스타트가 필수적임을 의미하지만, 이는 동시에 파이프라인이 단순하지 않음을 보여줍니다.
efficient RLVR training cold-start-free RL
한계 3 텍스트 기반 버전의 고정 위치 편향: 저자들은 텍스트 기반 버전이 "=" 토큰 이후처럼 정형화된 위치에 추론 블록을 호출하는 경향이 있다고 언급합니다. 특수 토큰 변형은 더 다양하고 맥락적으로 적절한 배치를 보여주었습니다. 이는 텍스트 기반 버전의 잠재적인 서브옵티멀 위치 선택 가능성을 시사합니다.
optimal thinking position
한계 4 코드 외 도메인에서의 추가 훈련 미수행: 교차 도메인 일반화 실험은 코드만으로 훈련된 모델을 수학에 직접 평가한 것입니다. 저자들은 코드 외 도메인(수학, 자연어 추론 등)에서 THINK-ANYWHERE를 직접 훈련하고 최적화하는 것은 향후 연구 과제로 남겨두었습니다.
cross-domain reasoning multi-domain RLVR
열린 문제 "무엇을 생각하지 말아야 하는가" 최적화: 현재 THINK-ANYWHERE는 언제 추론을 호출해야 하는지를 학습하지만, "언제 추론을 하지 말아야 하는지"를 최적화하는 것은 아직 미해결 문제입니다. 저자들은 이것이 추론 깊이와 계산 효율성 사이의 트레이드오프를 더욱 최적화하는 방향이라고 언급합니다.
adaptive computation thinking efficiency

영향력 & 후속 연구

THINK-ANYWHERE는 LLM의 추론 메커니즘에 대한 새로운 관점을 제시합니다. 업프론트 씽킹이 지배적인 현재 패러다임에서, 인라인 온디맨드 추론으로의 전환이 가능하고 더 효과적일 수 있음을 실증했습니다.

학술적 기여 코드 생성의 추론 메커니즘 설계에 새로운 방향을 제시합니다. 특히 "추론 자원의 위치 기반 할당"이라는 아이디어는 코드 외 다른 복잡한 순차적 생성 태스크에도 적용 가능한 범용 원리입니다.
실용적 적용 경쟁 프로그래밍(LeetCode, ICPC), 소프트웨어 엔지니어링 자동화, 코드 에이전트(code agent) 시스템에서 더 신뢰할 수 있는 코드 생성 가능성을 제공합니다.

저자들이 제안한 향후 연구 방향:

관련 분야 더 찾아보기

code generation LLM RLVR chain-of-thought GRPO DeepSeek-R1 interleaved thinking adaptive computation LoRA

Q&A — 연구자의 고민과 독자의 질문

Q1. 왜 SFT만으로는 효과적인 사고 위치를 학습하지 못하는가?

실험 결과(Table 5)에서 "Only Cold Start"는 47.9% pass@1으로 전체 방법(69.4%) 대비 21.5%p나 낮습니다. 이유는 명확합니다: "어디서 생각해야 하는가"는 패턴 매칭으로 해결할 수 없는 문제입니다.

"The decision of which token positions to invoke thinking requires the model to identify its own moments of high complexity or logical risk, which demands adaptive judgment that goes beyond pattern matching in supervised data."

어떤 토큰 위치에서 추론을 호출할지 결정하는 것은 모델이 스스로 높은 복잡도나 논리적 위험의 순간을 식별해야 하며, 이는 지도학습 데이터의 패턴 매칭을 넘어서는 적응적 판단을 요구합니다.

지도학습은 교사 모델(Gemini 2.5 Flash)이 삽입한 위치를 모방하는 것만 학습합니다. 하지만 다양한 새로운 코딩 문제에서 어디가 실제로 어려운지를 스스로 판단하는 능력은 RL의 보상 기반 탐색을 통해서만 발전합니다.

Q2. THINK-ANYWHERE와 Interleaved Thinking의 차이는 무엇인가?

Interleaved Thinking(Xie et al., 2025)은 각 서브스텝마다 추론을 강제하는 반면, THINK-ANYWHERE는 모델이 스스로 필요한 순간에만 추론을 호출합니다.

핵심 차이는 선택권(agency)에 있습니다: Interleaved Thinking은 고정된 주기로 추론하지만, THINK-ANYWHERE는 온디맨드입니다. 이로 인해 THINK-ANYWHERE는 단순한 코드 부분에서 불필요한 추론 오버헤드를 피하고, 정말 어려운 부분에서만 추론을 집중할 수 있습니다.

평가 Interleaved Thinking 실험은 원본 소스 코드가 없어 저자들이 직접 적용한 버전을 사용했다는 점에 주의할 필요가 있습니다. 완전히 동일한 조건의 비교라고 보기는 어렵습니다.

Q3. Padding Thinking 실험이 보여주는 것은 무엇인가?

"Padding Thinking"은 <thinkanywhere> 블록의 내용을 패딩 토큰으로 대체하고 계속 생성합니다. 결과는 67.6%로, 완전한 THINK-ANYWHERE(69.4%) 대비 소폭 낮지만 베이스 모델(50.6%)보다는 훨씬 높습니다.

이는 두 가지를 보여줍니다: (1) 추론 블록의 내용이 성능에 기여하지만, (2) 올바른 위치를 선택하는 것 자체도 중요하다는 것입니다. 패딩 토큰을 통해서도 모델은 포워드 패스에서 일종의 암묵적 추론을 수행합니다(Goyal et al., 2024; Pfau et al., 2024의 "pause token" 연구와 연관됩니다).

흥미로운 통찰 추론 블록의 내용과 위치가 독립적으로 기여합니다. 위치 선택이 좋으면, 실제 내용이 없더라도 성능이 일정 수준 유지됩니다 — 이는 "어디서 생각하는가"가 "무엇을 생각하는가"만큼 중요할 수 있음을 시사합니다.
Q4. 왜 코드 생성 훈련이 수학 추론으로 일반화되는가?

코드 생성과 수학 추론은 모두 복잡한 논리적 단계, 중간 결과 추적, 엣지 케이스 처리를 요구합니다. THINK-ANYWHERE가 코드 생성에서 학습하는 "온디맨드 추론 호출" 능력은 복잡도 기반의 범용 추론 전략으로 볼 수 있습니다.

평가 논문은 왜 이 일반화가 일어나는지에 대한 메커니즘적 분석을 제공하지 않습니다. AIME 2024에서 THINK-ANYWHERE가 17.3% pass@1을 달성하는 것은 인상적이지만, 이것이 수학 특화 훈련과 비교해서 어느 정도 수준인지는 논문에서 직접 비교하지 않습니다.

Q5. 코드와 구현은 어디서 볼 수 있는가?

소스 코드는 https://github.com/jiangxxxue/Think-Anywhere에서 공개되어 있습니다.

주요 구현 스택:

  • RL 프레임워크: VeRL (Sheng et al., 2024)
  • 베이스 모델: Qwen2.5-Coder-7B-Instruct
  • 콜드스타트 데이터 생성: Google Gemini 2.5 Flash API
  • 훈련 인프라: 8 × NVIDIA A100 (40G)
Q6. 왜 Prompting만으로는 THINK-ANYWHERE가 작동하지 않는가?

Table 7(Appendix)에서 명확히 보입니다: 베이스 모델에 THINK-ANYWHERE 프롬프팅만 적용하면 <thinkanywhere> 블록 빈도가 거의 0에 가깝고(HumanEval에서 0.24회), 블록 길이는 113.5 토큰으로 비정상적으로 깁니다. 이는 모델이 THINK-ANYWHERE 패턴을 사전훈련에서 학습하지 않았음을 의미합니다.

콜드스타트 SFT 이후에는 정상적인 빈도(6.69회)와 길이(31.9 토큰)로 패턴이 안정화됩니다. RL 훈련 이후에는 빈도(6.15회)와 길이(22.5 토큰)가 약간 감소하면서 pass@1은 크게 향상됩니다 — RL이 추론을 더 간결하고 목표 지향적으로 만든다는 증거입니다.

원본 Figures

논문에 수록된 원본 그림들입니다. 각 그림의 위치와 주요 포인트를 함께 설명합니다.

Figure 1: THINK-ANYWHERE 개요
Figure 1 (논문 §1 Introduction, p.2): THINK-ANYWHERE 메커니즘의 핵심 비교 그림. 좌측은 표준 업프론트 씽킹 LLM이 "Edit Distance" 문제에서 인덱스 오류 버그가 발생하는 모습, 우측은 THINK-ANYWHERE가 코드 작성 중 <thinkanywhere> 블록을 통해 인덱싱 세부사항을 즉각 확인하며 정확한 코드를 생성하는 모습입니다. "..." 표시는 지면 절약을 위해 생략된 추론 내용을 나타냅니다.
Figure 2: 사고 위치 분석
Figure 2 (논문 §4.4 Further Analysis, p.9): 사고 위치 분석 결과. (a) 토큰 엔트로피 분석: <thinkanywhere> 호출 위치에서 thinking 비활성화 시의 엔트로피 차이 분포 — 대부분 양수로, 모델이 높은 불확실성 위치에서 추론을 호출함을 보여줍니다. (b) 구문 컨텍스트 분석: <thinkanywhere>가 가장 자주 호출되는 상위 5개 구문 범주 (Assign, Return, Expr, If, AugAssign 순).
Figure 3,4: 토큰 비용 및 pass@k 비교
Figure 3 & 4 (논문 §4.4 Further Analysis, p.10): Figure 3(좌): 방법별 평균 토큰 비용 비교 — THINK-ANYWHERE가 GRPO와 CoT 대비 모든 벤치마크에서 더 적은 토큰을 생성합니다. Figure 4(우): pass@k 분석 — k가 커질수록 THINK-ANYWHERE와 GRPO의 성능 차이가 벌어지며, 특히 LeetCode와 MBPP에서 두드러집니다.