같은 모델이라도 답을 만들어 내는 절차를 어떻게 짜느냐에 따라 정확도와 비용이 크게 달라진다. 아래는 논문으로 정리되어 널리 쓰이는 전략들이다. 대부분 모델을 바꾸지 않고 프롬프트와 호출 구조만으로 적용할 수 있다.
최근의 추론 특화 모델은 이 가운데 상당수를 모델 내부에서 이미 수행한다. 그런 모델에 단계별 사고를 다시 지시하면 오히려 출력이 길어지고 품질이 떨어지는 경우가 있으므로, 쓰는 모델이 어느 쪽인지 먼저 확인한다.
예시 없이 지시만 주는 것이 zero-shot, 입력에 예시를 몇 개 넣어 형식과 판단 기준을 보여 주는 것이 few-shot 이다. 가중치를 바꾸지 않고 문맥만으로 동작을 맞추므로 in-context learning 이라고 부른다.
출력 형식을 고정해야 하거나 도메인 특유의 판단 기준이 있을 때 예시 두세 개만으로 크게 좋아진다. 예시는 틀린 경우도 함께 넣는 편이 경계를 잡는 데 효과적이다.
예시가 길어지면 입력 토큰이 그만큼 늘어난다. 같은 예시를 반복해서 쓴다면 프롬프트 캐싱이 되는지 확인한다.
최종 답을 내기 전에 중간 추론 단계를 글로 쓰게 한다. 산술, 논리, 다단계 조건 판단처럼 중간 상태를 들고 가야 하는 문제에서 정확도가 올라간다.
대가는 두 가지다. 출력 토큰이 늘어 비용과 지연이 커지고, 중간 단계가 그럴듯하지만 틀린 경우 최종 답까지 함께 틀린다. 추론 과정이 보인다고 해서 그 과정이 실제로 답을 만든 경로라는 보장은 없다. 사후 정당화가 섞이므로 감사 근거로 삼지 않는다.
답만 필요한 경우 중간 과정을 출력에서 분리하도록 형식을 지정한다.
같은 문제를 온도를 올려 여러 번 풀게 하고, 나온 답 가운데 가장 많이 나온 것을 고른다. CoT 한 번의 결과가 흔들리는 문제에서 효과가 크다.
비용이 표본 수만큼 곱해진다. 그리고 모델이 일관되게 잘못 알고 있는 것은 다수결로도 고쳐지지 않는다. 표본 간 분산이 작다면 표본을 늘려도 얻는 것이 없으므로, 실제 분산을 먼저 재 보고 표본 수를 정한다.
정답이 하나로 떨어지는 문제(수치, 분류)에는 맞고, 서술형 결과물에는 집계 기준이 없어 그대로 쓰기 어렵다.
다음 단계 후보를 여러 개 만들고, 각 상태를 평가해 가망 없는 가지를 쳐 내며 탐색한다. 되돌아갈 수 있다는 점이 CoT 와 다르다.
탐색 비용이 가지 수와 깊이의 곱으로 늘고, 상태를 평가하는 기준을 따로 만들어야 한다. 평가 기준을 모델에게 맡기면 그 평가 자체가 또 하나의 불확실한 판단이 된다. 퍼즐이나 계획 수립처럼 중간 상태의 좋고 나쁨을 기계적으로 채점할 수 있을 때 쓸 만하다.
추론과 행동을 번갈아 한다. 생각을 적고, 도구를 호출하고, 결과를 관찰하고, 다시 생각하는 순환이다. 지금의 도구 사용 에이전트 대부분이 이 구조를 따른다.
외부에서 사실을 가져오므로 환각이 줄어든다는 것이 장점이고, 단계마다 호출이 일어나 지연이 누적되는 것이 단점이다. 실무에서 가장 자주 부딪히는 문제는 같은 도구를 같은 인자로 반복 호출하는 순환이다. 최대 단계 수와 중복 호출 차단을 반드시 건다.
한 번 낸 답을 스스로 비평하고 고쳐 다시 내게 한다. 코드 생성처럼 결과를 실행해 볼 수 있는 영역에서 효과가 확실하다.
검증 신호가 외부에 있을 때(테스트 통과 여부, 컴파일 성공 여부) 잘 동작한다. 모델이 자기 답을 스스로 평가하게만 하면 처음 답을 정당화하는 방향으로 기울기 쉬우므로, 채점자는 가능한 한 기계에 맡긴다.
| 문제의 성격 | 맞는 전략 |
|---|---|
| 형식을 맞추는 단순 변환 · 분류 | zero-shot, 필요하면 few-shot |
| 중간 계산이 필요한 문제 | CoT |
| 답이 흔들리는 수치·분류 문제 | CoT + self-consistency |
| 되돌아가며 탐색해야 하는 계획 문제 | ToT |
| 외부 데이터·시스템을 봐야 하는 작업 | ReAct |
| 실행해서 채점할 수 있는 산출물 | Reflexion 계열 |
사업 계획이나 제안서처럼 정답이 없는 문서 작업에는 위의 전략 대부분이 잘 맞지 않는다. 다수결로 고를 정답이 없고 기계적 채점자도 없기 때문이다. 이런 작업에서는 추론 전략보다 다음이 결과를 좌우한다.
전략을 고르는 것은 결국 토큰을 얼마나 더 쓰고 정확도를 얼마나 얻느냐의 문제다.
| 전략 | 추가 비용 |
|---|---|
| few-shot | 입력 토큰 증가 (예시 길이만큼, 매 호출) |
| CoT | 출력 토큰 증가 |
| self-consistency | 전체 호출이 표본 수만큼 배수 |
| ToT | 가지 수 × 깊이, 여기에 평가 호출이 더해진다 |
| ReAct | 단계마다 왕복. 도구 응답 길이가 입력에 누적된다 |
먼저 가장 단순한 구성으로 정확도를 재 두고, 전략을 하나씩 얹으며 그 증가분이 비용에 걸맞는지 본다. 측정 없이 얹으면 비싸기만 하고 나아지지 않는 구성이 남는다.