Chain-of-Thought 지시, 모델별로 검증해봤다

Chain-of-Thought 지시, 모든 모델에 똑같이 먹힐까?

아니다. 2026년 기준으로 정리하면, "단계별로 생각하라"는 지시는 비추론 모델과 추론 모델에서 다르게 작동한다. OpenAI의 추론 모델(o1 계열 등)은 내부적으로 이미 사고 과정을 거치기 때문에, 전체 사고과정을 그대로 출력하라는 지시는 불필요하거나 오히려 성능을 떨어뜨릴 수 있다 OpenAI 프롬프트 엔지니어링 가이드. 반면 Azure OpenAI 문서는 전통적인 Chain-of-Thought 프롬프트를 비추론 모델에 적용하는 기법으로 설명한다 Azure OpenAI 프롬프트 엔지니어링 개념.

이 글의 핵심:

"Chain-of-Thought를 넣으면 성능이 오른다"는 단일 법칙이 아니라 모델 종류에 따라 갈리는 설계 선택이다.
추론 모델에는 사고과정 공개보다 목표·제약·출력 형식·평가 기준을 명시하는 편이 권장된다.
비추론 모델에서는 단계 분해 지시가 여전히 유효한 실험 대상이다.
프롬프트 수정 효과는 평가 세트 없이 체감으로 판단하면 재현이 안 된다.
비용·지연시간 비교를 쓰려면 모델명·버전·토큰 수·측정일을 반드시 같이 적어야 한다.

이번 실험에서 검증하려던 것은 단순하다. "모델에게 생각 과정을 전부 보여달라고 요청하는 것"과 "결론·근거·불확실성만 구조화해서 요청하는 것" 중 어느 쪽이 더 재현 가능한 출력을 만드는가다. 정확도 수치를 비교하려는 게 아니라, 프롬프트를 어떻게 구조화해야 결과를 매번 검증할 수 있는 형태로 받을 수 있는지가 관심사였다.

비추론 모델과 추론 모델, 프롬프트를 어떻게 다르게 짜야 할까?

핵심은 모델 구분을 먼저 하는 것이다. 추론 모델(o1, GPT-5의 reasoning 모드 등)은 입력을 받으면 내부적으로 여러 단계를 거쳐 답을 생성하는데, 이 내부 과정을 그대로 출력하라고 요구하면 불필요한 토큰 소모가 생기거나 모델이 혼란을 겪을 수 있다는 것이 공식 권고다 OpenAI reasoning 모범 사례. 반대로 비추론 모델은 스스로 단계를 쪼개는 능력이 약하기 때문에, "먼저 문제를 분해하고, 각 단계를 설명한 뒤, 최종 답을 제시하라"는 전통적 Chain-of-Thought 지시가 여전히 유효한 실험 대상으로 다뤄진다 Azure OpenAI 프롬프트 엔지니어링 개념.

실무에서 이 구분을 놓치면 두 가지 실패가 생긴다. 추론 모델에 "생각을 단계별로 다 보여줘"라고 요구하면 불필요하게 긴 출력이 나오고, 비추론 모델에 "결론만 말해"라고 요구하면 중간 논리 없이 근거 없는 답이 나온다. 따라서 프롬프트를 쓰기 전에 모델명과 버전을 먼저 확인하고, 거기에 맞는 지시 방식을 고르는 것이 첫 단계다.

목표·제약·형식을 어떻게 구조화해야 재현 가능할까?

재현 가능성을 높이는 방법은 프롬프트를 목표·제약·형식 세 블록으로 쪼개는 것이다. OpenAI의 프롬프트 가이드는 원하는 결과, 맥락, 길이, 형식, 문체를 구체적으로 지정하라고 권고한다 OpenAI 프롬프팅 가이드. 실제로 써본 템플릿은 다음과 같다.

목표: 아래 고객 문의를 분류하고, 분류 근거가 되는 입력 문장만 인용하라.
제약: 500자 이내, 확인된 사실만 사용, 불확실하면 "확인 불가"라고 표시
출력형식:
- 결론
- 근거
- 불확실성

제약 조건은 "추측하지 말라"처럼 모호하게 두지 않고, 불확실할 때 쓸 대체 응답까지 정해두는 편이 실제로 구현 가능했다. OpenAI 문서는 예산 500달러 이하 같은 구체적 숫자를 제약 예시로 든다 OpenAI reasoning 모범 사례. 형식 쪽은 Markdown 헤더나 XML 태그로 입력의 각 부분(목표·자료·제약·출력형식)을 분리하면 모델이 프롬프트의 구조를 더 잘 따라간다는 설명이 있다 OpenAI reasoning 모범 사례.

추론 모델에서는 여기에 한 줄을 더 추가했다. "내부 사고과정은 출력하지 말고, 결론을 뒷받침하는 핵심 근거를 최대 3개와 확인되지 않은 가정을 분리해 제시하라." 이 문구는 설명 가능성을 확보하면서도 비공개 내부 추론을 장황하게 재현하도록 요구하지 않는다는 점에서 실무적으로 다루기 쉬웠다.

평가 기준 없이 프롬프트를 고치면 무슨 일이 생길까?

체감으로 판단하면 바뀐 게 실제 개선인지 우연인지 구분이 안 된다. 이번 실험에서 가장 자주 겪은 마찰이 이 지점이었다. 프롬프트를 수정한 뒤 "이번 답변이 더 낫다"고 느꼈지만, 같은 입력을 다시 넣었을 때 결과가 달라지는 경우가 있었고, 그게 프롬프트 때문인지 모델의 출력 변동성 때문인지 구분할 방법이 없었다.

이를 줄이려면 평가 세트를 미리 만들어야 한다. OpenAI 문서는 프롬프트를 수정하거나 모델 버전을 업그레이드할 때 동작을 측정할 수 있도록 평가 세트를 구축하라고 권고한다 OpenAI 프롬프트 엔지니어링 가이드. 실제로 적용해본 최소 평가 항목은 다섯 가지였다.

평가 항목	확인 내용
사실성	제공 자료에 없는 주장을 만들지 않는가
제약 준수	글자 수·언어·금지어를 지키는가
형식 준수	요구한 출력 형식(목록·태그 등)이 유지되는가
누락률	필수 항목을 빠뜨리지 않는가
재현성	같은 입력 반복 시 결과 편차가 허용 범위인가

다만 공개 문서는 "평가 스위트를 만들라"고 권고할 뿐, 각 항목의 합격률 기준이나 공식 수치는 제시하지 않는다. 그래서 "정확도가 30% 올랐다" 같은 문장은 이 실험에서 쓸 수 없었고, 쓰지 않았다.

공식 문서는 실제로 뭐라고 말하나?

세 문서가 일관되게 말하는 것은 "모델 종류를 먼저 구분하라"는 것이다. OpenAI의 reasoning 모범 사례 문서는 추론 모델에 대해 zero-shot 지시를 먼저 시도하고, 필요한 경우에만 few-shot 예시를 추가하라고 안내한다. 예시가 지시와 어긋나면 오히려 성능이 나빠질 수 있다는 경고도 함께 나온다 OpenAI reasoning 모범 사례. GPT-5 프롬프팅 가이드는 reasoning_effort를 낮추면 탐색 깊이는 줄지만 효율성과 지연시간이 개선될 수 있다고 설명한다 GPT-5 프롬프팅 가이드.

이 지점에서 주의할 점이 있다. 검색된 문서에는 특정 모델의 토큰당 가격, 평균 지연시간, 단계별 비용 절감률이 함께 제시되지 않았다. 그래서 비용 비교 문장을 쓰려면 모델명, API 버전, reasoning effort 값, 입력·출력 토큰 수, 실행 횟수, 측정일을 반드시 같이 기록해야 신뢰할 수 있는 비교가 된다. 이 글에서도 특정 모델의 비용 수치는 제시하지 않았다.

이 실험은 어디까지 검증했고 어디서 막혔나?

이번 실험은 프롬프트 구조(목표·제약·형식·평가)를 설계하고, 공식 문서가 권고하는 패턴과 일치하는지 확인하는 수준까지 진행했다. 실제 모델 출력을 대량으로 수집해 정량적인 정확도·재현율을 계산하는 벤치마크 단계까지는 가지 않았다. 공개 문서 자체가 보편적인 합격률 기준을 제시하지 않기 때문에, "이 템플릿을 쓰면 몇 퍼센트 개선된다"는 식의 결론은 이 글에서 낼 수 없었다.

또한 모델과 문서는 계속 업데이트된다. OpenAI 프롬프트 엔지니어링 가이드 자체가 모델별 권장사항을 구분하고 있고, 2025년 문서와 현재 공개 문서 사이에 표현이 달라질 수 있다 OpenAI 프롬프트 엔지니어링 가이드. 따라서 이 실험 결과를 다른 프로젝트에 그대로 옮기려면, 사용 중인 모델명과 스냅샷, 문서 확인일을 다시 점검하는 과정이 필요하다.

다음 실험에서는 무엇을 바꿔볼까?

이번 실험에서 얻은 가장 실질적인 수확은 "Chain-of-Thought 지시"를 하나의 기법으로 뭉뚱그리지 않게 된 것이다. 비추론 모델에는 단계 분해 지시가 여전히 실험할 가치가 있고, 추론 모델에는 결론·근거·불확실성을 구조화해서 요구하는 편이 공식 권고와 맞는다. 다음 단계로는 같은 프롬프트 구조를 여러 모델 버전에 고정 조건으로 돌려보고, 위에서 정리한 다섯 가지 평가 항목(사실성·제약 준수·형식 준수·누락률·재현성)을 실제 출력에 적용해 수치화하는 작업을 계획하고 있다. 이 부분은 아직 공개할 만한 측정값이 없어 이번 글에는 포함하지 않았다.

핵심 정리

Chain-of-Thought 지시는 모델에 따라 효과가 갈린다. 비추론 모델에는 단계 분해 지시가, 추론 모델에는 결론·근거·불확실성 구조화 지시가 더 맞는 설계다.
프롬프트는 목표·제약·형식 세 블록으로 쪼개면 재현 가능성이 높아진다. 제약은 "추측하지 말라"보다 불확실 시 대체 응답까지 정해야 구현 가능하다.
추론 모델에는 전체 사고과정 대신 "내부 사고과정은 출력하지 말고 핵심 근거 최대 3개와 가정을 분리하라" 같은 문구가 실무적으로 적합하다.
프롬프트 수정 효과는 사실성·제약 준수·형식 준수·누락률·재현성을 기준으로 한 평가 세트 없이는 체감으로만 판단하게 된다.
비용·지연시간을 비교하려면 모델명·버전·reasoning effort·토큰 수·측정일을 반드시 함께 기록해야 한다.