DEV_BBAK
← 포스트

Chain of Thought는 여전히 유효한가?

·8 min read·로딩중...
#AI#LLM#Prompt Engineering

Chain of Thought는 여전히 유효한가?

요즘 고객 문의를 분류하는 LLM 에이전트의 프롬프트를 정리할 일이 있었다. 코드는 별도 runtime 에서 돌아가고, 내가 본 것은 schema, 프롬프트 본문, 평가 케이스 같은 콘텐츠 쪽이었다.

그 과정에서 한 변경이 눈에 들어왔다. 분류 에이전트의 출력 schema 에 reasoning 이라는 필드를 추가하고, 프롬프트에서 "label 보다 reasoning 을 먼저 채워라" 라고 강제하는 변경이었다.

Chain-of-Thought (CoT) — 개념은 들어봤지만 한 번도 진지하게 들여다본 적은 없었다. 짧게 정리해봤다.

CoT 가 뭔가

2022 년 Wei et al. 의 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 가 시작이다. 모델에게 답을 바로 시키지 말고 중간 단계를 풀어쓰게 하면 multi-step 추론 정확도가 크게 오르더라, 는 발견.

같은 해 Kojima et al. 은 더 단순한 버전을 보였다. 프롬프트 끝에 "Let's think step by step." 한 줄만 붙여도 zero-shot 성능이 점프한다. text-davinci-002 의 MultiArith 정확도가 17.7 → 78.7%, GSM8K 가 10.4 → 40.7%.

요지는 두 가지였다.

  1. LLM 은 답을 생성하면서 추론을 한다. 출력에서 추론 분량을 늘려주면 답 품질이 올라간다.
  2. 추론을 강제하는 비용은 프롬프트 한 줄 또는 출력 schema 한 필드. 거의 공짜.

여기서 의문이 들었다. 그 발견이 2022 년이다. 4 년이 지났고 모델 세대가 두세 번 바뀌었다. 지금도 유효한가?

의문을 풀어본 결과

요점부터 — task 와 모델에 따라 갈린다.

증거 세 개를 봤다.

Sprague et al. 2024 — To CoT or not to CoT? 100+ 논문 메타분석. CoT 의 큰 효과는 수학·기호 추론에 집중. MMLU 같은 분류 task 는 등호(=) 가 들어간 케이스 외에는 직답과 차이가 거의 없다.

Wharton GAIL 2025 — The Decreasing Value of Chain of Thought in Prompting. 모델별로 CoT 효과를 측정. non-reasoning 모델(Sonnet 3.5, Gemini Flash 2.0) 은 +1113%p. reasoning 모델(o3-mini, o4-mini) 은 +3%p 안팎. Gemini Flash 2.5 는 오히려 -3%p. 모든 케이스에서 latency 520 초가 추가된다.

Anthropic 공식 가이드 (Claude 4.6 / 4.7). Claude 4.6 부터 adaptive thinking 이 디폴트다. 모델이 query 복잡도를 보고 추론 깊이를 알아서 조절한다. 그래서 manual CoT 는 "thinking 이 꺼져 있을 때의 fallback" 으로 격하됐다. 가이드 원문: "Prefer general instructions over prescriptive steps. A prompt like 'think thoroughly' often produces better reasoning than a hand-written step-by-step plan."

세 자료를 묶으면 이렇게 정리된다.

  • 분류·검색 같은 단순 task 에서는 CoT 정확도 효과가 거의 없다.
  • reasoning 모델이나 adaptive thinking 모델은 이미 내부에서 추론한다. 프롬프트로 한 번 더 시키는 건 중복이거나 역효과.
  • 단, 수학·기호·멀티 가설 추론처럼 추론 depth 가 본질인 task 에서는 여전히 큰 효과가 있다.

그럼 classifier 의 reasoning 필드는 뭐였나

여기서 흥미로워졌다. 내가 본 classifier 는 분류 task 에 가깝고, 최신 Claude 계열 모델을 사용하고 있었다. 위 기준으로 보면 CoT 가 정확도를 끌어올릴 자리가 거의 없는 케이스다. 그런데 왜 reasoning 필드를 도입했을까.

관련 프롬프트 전략 문서를 읽고 알았다 — 정확도를 위한 게 아니었다.

문서가 명시하는 reasoning 필드의 ROI 는 정확도가 아니라 다음 네 개다.

  • 운영 디버깅 자산: 오분류가 났을 때 모델이 무슨 단서를 보고 그 라벨을 골랐는지 가 출력 안에 함께 남는다.
  • 회귀 감지: 같은 입력의 reasoning 이 빌드 간 흔들리면 라벨이 흔들리기 직전의 leading indicator 가 될 수 있다.
  • 검수 효율: 사람이 라벨만 보고 검수할 때보다 reasoning까지 보면 옳고 그름 판단이 빨라진다.
  • eval 의 추가 신호: scorer 가 라벨 정확도뿐 아니라 reasoning 의 groundedness/structure 를 별도로 채점하면 라벨 noise 와 분리된 신호가 잡힌다.

CoT 의 역할이 "모델을 똑똑하게 만드는 트릭" 에서 "시스템 동작을 관측 가능하게 만드는 구조" 로 옮겨갔다는 얘기다. distributed tracing 이 latency 를 직접 줄이지 않는 것과 같다. reasoning 필드도 정확도를 직접 올리진 않는다. 둘 다 왜 그렇게 동작했는지 를 본다.

거기에 안전장치가 한 겹 더 붙어 있었다. 프롬프트가 "reasoning 을 가장 먼저 채워라. label 을 먼저 정한 뒤 reasoning 을 쓰면 사후합리화가 되므로 금지" 라고 명시한다. Oxford WhiteBox 의 2025 년 페이퍼 Chain-of-Thought Is Not Explainability 가 지적한 함정 — 모델이 답을 먼저 정해놓고 reasoning 을 쓰면 사후합리화가 된다 — 을 프롬프트 레벨에서 방어한 셈이다. 순서를 강제하지 않으면 reasoning 은 트레이싱이 아니라 알리바이가 된다.

정리

CoT 에 대한 의문 하나로 시작했는데 답은 의외로 깔끔했다.

  • "Let's think step by step" 의 황금기는 끝났다. frontier 모델 + 단순 task 에서는 사실상 효과 없음.
  • 그래도 CoT 패턴 자체가 죽은 건 아니다. 역할이 바뀌었다. 정확도 도구에서 관측성 도구로.
  • 적용할 때는 정확도 ROI 와 관측성 ROI 를 분리해서 평가하면 된다.

작은 변경 하나를 보고 시작한 의문이 이런 정리로 이어질 줄은 몰랐다. 가끔은 모르는 약어가 나왔을 때 그 자리에서 검색해보는 게 가장 큰 공부다.

참고