1. 배경과 문제 의식

• Train-time scaling은 모델 파라미터, 데이터셋, FLOPs를 늘려 성능을 높이는 전통적 방법이다. 그러나 동일 모델이라도 inference 시간에 얼마나 “생각”할 기회를 주느냐(토큰 길이, 샘플링 횟수, 단계 반복)에 따라 추가 성능 향상이 가능하다.
• 따라서 같은 모델이라도 더 좋은 답변을 얻기 위한 연구 내용을 정리한다.

2. 토큰 예산(Token-Budget) 늘리기

2.1 표준 프롬프트의 한계

표준 few-shot 프롬프트는 정답 형식만 보여 주기 때문에 모델은 어떻게 풀었는지를 학습하지 못한다. 그 결과 복잡한 논리 문제가 주어지면, 겉으로는 맞는 형식을 출력하지만 중간 과정이 없어 오류를 낳기 쉽다.

2.2 Chain-of-Though(CoT)

이를 보완하기 위해 등장한 기법이 Chain-of-Thought(CoT) 프롬프트이다. 예를 들어 “12개의 사과를 세 아이에게 똑같이 나누면?”이라는 질문에 일반 프롬프트는 “4”라고만 답하지만, CoT 프롬프트는 “12를 3으로 나누면 4이다. 따라서 한 아이당 4개이다.”처럼 중간 계산을 모두 노출한다. 모델 규모가 커질수록 이러한 사고 과정 출력이 급격히 효력을 발휘하는 창발 현상이 보고되었다.

2.3 Zero-Shot CoT

CoT를 라벨 없이 쓰려면 “Let’s think step by step” 한 줄만 추가해도 된다. 하지만 이 Zero-shot CoT는 프롬프트 문구에 민감하고 few-shot CoT보다 성능이 낮다.

2.4 Analogical Prompting

이를 개선한 Analogical Prompting은 문제를 먼저 요약한 뒤, 모델이 스스로 비슷한 예제(예: Codeforces에서 난이도·패턴이 유사한 문제)를 찾아 답안을 읽게 한 다음 본 문제로 돌아와 해결하도록 유도한다. 실제 실험에서는 사람 손으로 만든 예시 없이도 기존 few-shot CoT보다 높은 정확도를 보였다.

2.5 Least-to-Most Prompting

또 다른 변형인 Least-to-Most Prompting은 문제를 여러 하위 단계로 분해해 “쉬운 것부터 해결 → 그 결과를 다음 단계 입력에 포함”하는 방식이다. SCAN 데이터셋(자연어 명령→행동열)에서, 모델은 먼저 “turn left” 같은 단순 명령을 처리해 규칙을 학습한 뒤 “turn left twice and jump” 같은 긴 명령을 성공적으로 변환할 수 있었다.

2.6 토큰 예산이 성능에 미치는 실제 효과

AIME(수학 올림피아드) 문제를 GPT-4 계열 모델에게 풀게 할 때, 답이 나올 때까지 256토큰만 허용하면 정답률이 34 %에 그쳤다. 같은 모델에게 1024토큰까지 허용하면 사고 과정을 길게 적을 수 있어 정답률이 48 %로 뛰었다. 여기서 계산량(FLOPs)은 늘어나지만 파라미터는 그대로이므로, 훈련이 끝난 모델도 “생각 시간을 더 주면” 똑똑해진다는 사실을 보여 준다.

---

3. 너비(Width)를 늘려 여러 가지 해답을 탐색하기

3.1 Self-Consistency

동일 문제에 대해 하나의 답만 생성하도록 강제하면, 모델이 초기에 작은 실수를 했을 때 회복할 기회가 없다. Self-Consistency 기법은 n개의 답안을 샘플링한 뒤, 이중에서 다수결을 취한다. 예를 들어 수학 문제의 답안을 다섯 번 풀어 결과가 42, 42, 39, 42, 45라면 42가 최종 정답이 된다. 논문에서는 n=30으로 샘플링했을 때 GSM8K(초등 수학) 정확도가 55 %→74 %로 상승하였다.

3.2 Verifier 모델

Self-Consistency에는 “답만 보고 다수결”이라는 한계가 있다. 이를 극복하고자 별도의 LLM을 Verifier 모델을 학습해 각 정답 후보들이 이를 도출해낸 경로마다 정확도를 예측해 최고 점수의 답변을 고른다.

3.3 Tree-of-Thought(ToT)

LLM을 트리 탐색 알고리즘과 결합해 부분 해답 단계에서도 가지치기를 수행한다. 예를 들어 ‘숫자 네 개로 24를 만드는 게임’에서 BFS-ToT는 “(3 × 8) − (8 ÷ 3)” 같은 부분 해답의 상태가 유망하다고 평가되면, 그 방향을 우선적으로 탐색하고 확장하여 단일 CoT보다 높은 효율성과 성공률을 얻는다.

4. 깊이(Depth)를 늘려 스스로 수정·향상하기

4.1 Reflection / Self-Refine

LLM도 인간처럼 처음에는 사소한 실수를 저지른다. Reflexion / Self-Refine 프레임워크는 (1) 초안 생성, (2) 모델 자신이 초안을 비평(“이러이러한 이유로 틀렸을 수 있다”), (3) 피드백을 참고해 개정안을 작성하는 자기-반성 루프를 돌린다.

4.2 Self-Debugging with Code Execution

들어 코드 문제의 경우에는 실제 파이썬 코드를 실행해 버그의 정보를 받아오도록 해 Self-Debugging을 진행할 경우 효율이 올라간다.

4.3 Self-Correction without Oracle

정답을 모를 때는 모델이 스스로 답의 옳고 그름을 판단해야 하는데, 이 과정에서 잘못된 자기 채점이 성능을 떨어뜨릴 위험이 있다. 따라서 Verifier 품질을 높이거나, Self-Consistency·ToT 같은 외부 견제 메커니즘과 함께 쓰는 것이 좋다.

5. 실무 적용 조언

• 쉬운 문제: 짧은 프롬프트로 바로 답하도록 해서 불필요한 FLOPs를 줄인다.

• 중간 난이도 문제: “Think step by step.” 프롬프트와 충분한 토큰 한도를 부여한다. 정확도가 불안하면 temperature를 높인 후 Self-Consistency 다수결을 쓴다.

• 고난도·복합 문제: Analogical Prompting이나 Least-to-Most로 예시 생성·서브태스크 분해 → ToT로 분기 탐색 → Verifier 또는 Reflexion 루프로 후속 수정.

• 코드·수식이 포함된 과제: 실행 가능한 환경을 마련해 Self-Debugging 루프를 자동화하면 오류 수정 속도가 대폭 빨라진다.

• 리소스 제약: 파라미터 수가 적은 모델에 더 긴 토큰 예산이나 더 많은 샘플을 주는 편이, 거대 모델을 한 번 돌리는 것보다 효율적일 수 있다citeturn1file4. 상황별로 최적 조합을 실험적으로 찾는 것이 중요하다.

이와 같이 토큰 길이(시간)·샘플 수(너비)·반복 수정(깊이)라는 세 축을 적절히 조절하면, 학습이 끝난 LLM도 추론 단계에서 지속적으로 성능을 끌어올릴 수 있다.