chain of thought 프롬프팅, 단계별 풀이가 필요한 순간

chain of thought(사고의 사슬) 프롬프팅은 중간 풀이 과정을 명시하는 것이 도움이 되는 작업에 활용합니다. 다만 추론 모델에 매번 “단계별로 생각해 봅시다”라고 지시할 필요는 없습니다. 2022년에 처음 제시된 이 기법은 풀이 예시로 모델이 답에 도달하는 방법을 보여줬습니다. 오늘날의 추론 모델은 그 과정을 출력하지 않고도 내부적으로 추론할 수 있습니다. 업무에 활용할 때는 필요한 근거와 결과물을 먼저 정하고, 작업의 성격상 필요할 때만 추론 강도를 조절합니다.

chain of thought 프롬프팅이란 무엇인가요?

사고의 사슬 프롬프팅은 최종 답만 제시하는 대신, 언어 모델이 따라 할 중간 단계를 보여주거나 모델에 그 단계를 작성하도록 요청하는 방식입니다. 대규모 언어 모델, 즉 LLM은 주어진 지시와 맥락을 바탕으로 텍스트를 생성합니다. CoT는 이 상호작용을 구성하는 방법입니다.

Jason Wei와 공동 저자들은 2022년 1월 28일 처음 제출한 논문 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models에서 이 이름의 기법을 소개했습니다. 프롬프트의 각 예시에 문제, 짧은 풀이, 답을 함께 넣으면 모델이 새로운 문제에도 같은 패턴을 이어 가는 방식입니다. 작업마다 모델을 다시 학습시키는 것이 아니라, 기존 모델에 프롬프트를 입력하는 기법입니다. 원 논문.

분석가에게 재고 대사 방법을 가르치는 상황을 떠올려 봅니다. 마감 재고만 보여주면 계산 방법을 알 수 없습니다. 시작 재고, 출고량, 입고량, 그리고 그 결과인 잔여 재고를 함께 보여줘야 계산 방법이 드러납니다. 원래 기법의 발상도 이와 같습니다.

현대의 추론 모델에서는 구분할 것이 하나 더 있습니다. 분석가가 계산하면서 쓰는 메모와 관리자에게 제출하는 보고서는 서로 다릅니다. 모델이 내부적으로 더 충분히 검토하도록 하면서도 최종 답변은 짧게 요청할 수 있습니다.

사고의 사슬 프롬프팅은 왜 사용하나요?

중간 연산이나 처리 과정이 중요한 문제를 풀도록 돕는 것이 목적입니다. 명시적인 시범이 도움이 되는 모델이라면, 풀이 예시를 통해 어떤 수량을 조합하고 어떤 규칙을 적용해야 하는지 보여줄 수 있습니다.

실무에서 확인할 것은 결과가 더 정확해지는지, 더 쉽게 검증할 수 있는지입니다. 설명이 길어졌다는 사실만으로는 어느 쪽도 입증되지 않습니다. 프롬프트를 개선 후보로 보고, 자신의 작업에서 효과를 평가해야 합니다.

업무에 적용하는 CoT 프롬프팅 예시

풀이 예시는 방법을 가르치는 데 쓰고, 출력 요구사항은 검토자가 확인해야 할 내용을 지정하는 데 씁니다. 두 목적이 겹칠 수는 있지만, 단계를 요청하는 이유는 서로 다릅니다.

CoT 프롬프팅 적용 전후: 재고 계산 예시

아래는 업무 상황에 맞춰 구성한 재고 대사 프롬프트입니다. 논문에서 그대로 가져온 예시가 아닙니다. 계산은 설명을 위해 제시했으며, 모델 테스트에서 얻은 출력이 아닙니다.

적용 전: 답만 보여주는 예시

예시 질문: 시작 재고가 12개이고, 5개를 출고한 뒤 3개를 입고했습니다. 몇 개가 남습니까?

예시 답변: 10개입니다.

새 질문: 시작 재고가 18개이고, 7개를 출고한 뒤 4개를 입고했습니다. 몇 개가 남습니까?

적용 후: 같은 예시에 중간 계산을 추가

예시 질문: 시작 재고가 12개이고, 5개를 출고한 뒤 3개를 입고했습니다. 몇 개가 남습니까?

예시 답변: 잔여 재고 = 시작 재고 − 출고량 + 입고량 = 12 − 5 + 3 = 10개입니다.

새 질문: 시작 재고가 18개이고, 7개를 출고한 뒤 4개를 입고했습니다. 몇 개가 남습니까?

바뀐 부분은 예시 안에 계산 방법을 넣었다는 점입니다. 새 질문의 정답은 두 경우 모두 15개입니다. 이 프롬프트가 모델의 정답을 보장하는 것은 아닙니다. 퓨샷 CoT가 어떻게 작동하는지 보여주는 예시입니다. ‘퓨샷’은 프롬프트에 예시를 넣는다는 뜻이며, 예시 하나를 제시하는 것이 이 패턴의 가장 작은 형태입니다.

정보 추출: 필요한 필드와 근거를 함께 요청합니다

매입채무 담당자가 청구서 번호를 추출한다면, 직접적인 지시로 시작합니다.

청구서 번호를 적힌 그대로 반환하고, 그 번호가 있는 원문 줄을 함께 제시하세요. 번호가 없으면 null을 반환하세요. 다른 식별자로부터 번호를 추정하지 마세요.

모델이 어떻게 해당 항목을 알아봤는지 길게 설명할 필요는 거의 없습니다. 원문 줄이 있으면 검토자가 추출 결과를 확인할 수 있습니다. 작업 범위가 서로 맞지 않는 구매 주문서와 청구서를 대사하는 수준으로 넓어진다면, 추론 강도를 높이는 방안을 검토할 수 있습니다.

의사결정: 적용한 규칙을 요청합니다

고객 지원 담당자가 환불 요청을 검토한다면, 판단 결과에 포함할 항목을 지정합니다.

제공된 환불 정책만 적용하세요. 권고안, 적용되는 정책 조항, 이를 뒷받침하는 고객 관련 사실, 판단을 내리는 데 부족한 정보를 반환하세요. 판단 근거는 간결하게 작성하세요.

이 프롬프트는 비공개 추론 과정을 전부 기록하도록 요구하지 않으면서도 유용한 근거를 지정합니다. 반복해서 쓰는 정책과 출력 지침은 시스템 프롬프트에 두고, 개별 사례의 문서는 명확히 분리합니다.

제로샷 프롬프팅으로 중간 추론을 요청하는 방법

제로샷 CoT는 풀이 예시 없이 중간 추론을 요청하는 방식입니다. Takeshi Kojima와 공동 저자들은 2022년 5월 24일 처음 제출한 논문 Large Language Models are Zero-Shot Reasoners에서 “Let's think step by step.”이라는 문구를 사용해 이 방식을 연구했습니다. 제로샷 CoT 논문.

재고 계산 작업에 적용하면 프롬프트는 다음과 같습니다.

시작 재고가 18개이고, 7개를 출고한 뒤 4개를 입고했습니다. 몇 개가 남습니까? 단계별로 생각해 봅시다.

이 문구는 특정 풀이 방법을 보여주는 대신 일반적인 지시를 제공합니다. 기법의 역사를 이해하는 데는 유용하지만, 현재의 모든 모델을 개선하는 만능 지시는 아닙니다.

각 변형의 작동 방식도 다릅니다. 퓨샷 CoT는 풀이 예시를 제공합니다. 제로샷 CoT는 예시 없이 지시만 제공합니다. Auto-CoT는 모델을 사용해 다양한 질문으로부터 풀이 예시를 만듭니다. 추론 모델이 내부적으로 생각하는 것을 달리 부르는 이름이 아닙니다. Auto-CoT 논문.

업무에서는 작업을 명확히 지시하는 것부터 시작하고, 실패 사례를 살펴봅니다. 모델에 부족한 것이 풀이 방법, 경계 사례, 또는 요구한 출력 형식이라면 그때 예시를 추가합니다.

추론 모델을 쓰면 무엇이 달라지나요?

추론 기능을 갖춘 모델에서는 작업, 제약조건, 결과물을 정의하는 것이 핵심입니다. 추론 제어 설정은 모델이 내부 작업에 얼마나 많은 자원을 들일 수 있는지를 결정합니다. 최종 설명에 관한 지시는 사용자가 받는 내용을 결정합니다.

아래 지침은 2026년 10월 18일 OpenAI, Anthropic, Google의 공개된 최신 문서와 대조해 확인했습니다. 제어 방식은 모델과 API마다 다릅니다. 모든 제공업체에 그대로 붙여 넣을 수 있는 공통 ‘사고 예산’ 설정은 없습니다.

OpenAI: 추론 모델에는 명확하고 직접적으로 지시합니다

OpenAI의 추론 모델 지침에 따르면, 이 모델들은 내부적으로 추론하므로 단계별 사고를 지시할 필요가 없으며 그런 지시가 때로는 성능을 떨어뜨릴 수도 있습니다. 목표, 관련 맥락, 제약조건, 명확한 출력 형식부터 제시합니다. 추론 모델 활용 권장사항.

이 권고가 모든 OpenAI 모델에 적용되는 것은 아닙니다. GPT-4.1 프롬프팅 가이드는 이 모델을 비추론 모델로 분류하며, 단계별로 처리하도록 명시하는 프롬프트가 도움이 될 수 있다고 설명합니다. 다만 출력량과 지연 시간이 늘어날 수 있습니다. 실제로 사용하는 모델에 맞춰 프롬프팅 방식을 선택해야 합니다. GPT-4.1 프롬프팅 가이드.

Anthropic: 모든 단계를 지정하기 전에 사고 기능과 추론 강도를 활용합니다

Anthropic의 Claude 프롬프팅 가이드는 추론 순서를 일일이 작성하는 것보다 큰 방향을 제시하는 사고 지침을 권장합니다. 풀이 예시로 접근법을 가르치는 것은 여전히 유용할 수 있습니다. 해당 모델에서 사고 기능을 끈 경우에는 직접 CoT를 지시하는 방식을 대안으로 쓸 수 있습니다. 일부 최신 모델은 내부 추론을 그대로 써 달라는 요청을 거절할 수도 있습니다. Claude 프롬프팅 권장사항.

실무에서는 작업에 맞는 추론 강도를 먼저 선택하고, 모델의 동작을 더 조정해야 할 때 프롬프트에 방향을 제시하는 지시를 추가합니다. 간단한 요청에는 바로 답할 수 있으며, 추론 강도를 설정했다고 해서 눈에 보이는 사고 블록이 반드시 출력되는 것은 아닙니다. 사고 과정 조정 가이드.

Google: 내부적으로 추론한다면 계획을 출력할 필요는 대체로 없습니다

Google의 Gemini 프롬프팅 가이드에 따르면 Gemini 2.5와 Gemini 3 시리즈는 내부적으로 사고하므로, 개요나 상세한 추론 단계를 출력하도록 요청할 필요는 대체로 없습니다. 어려운 문제에서는 더 깊이 생각하라는 간단한 지시가 도움이 될 수 있으며, 이때 사고 토큰이 추가로 사용된다고도 설명합니다. 이는 작업에 따른 지침이지, 그 문구를 넣으면 모든 답이 좋아진다는 보장이 아닙니다. Gemini 프롬프트 설계 전략.

필드 값을 조회하는 작업에서는 지원되는 경우 사고 수준을 최소 또는 낮음으로 설정하라고 Google의 사고 기능 가이드는 권장합니다. 더 높은 추론 강도는 여러 단계의 계획 수립처럼 복잡한 작업에 사용합니다. Gemini 사고 기능.

추론 강도와 사고 예산은 어떻게 다른가요?

추론 강도는 모델이 얼마나 깊이 검토할지 조절합니다. 토큰 예산은 이를 지원하는 구성에서 사고에 사용할 수 있는 토큰의 한도를 지정합니다. 어느 쪽도 최종 답변에 어떤 근거를 담아야 하는지 정해주지는 않습니다.

이는 자신의 연동 코드에서 찾아볼 필드 이름이며, 공통 구성 형식이 아닙니다. 값을 바꾸기 전에 해당하는 OpenAI 추론 문서, Claude 사고 기능 가이드, Gemini Generate Content 문서를 확인합니다.

과금: OpenAI는 추론 토큰 원문이 API에 노출되지 않더라도, 추론 토큰을 출력 토큰으로 과금한다고 명시합니다. 제공업체의 과금 안내.

토큰은 모델이 처리하고 생성하는 단위입니다. AI에서 토큰이란 무엇인가에서는 화면에 보이는 텍스트와 토큰 사용량의 차이를 설명합니다. 답변이 짧아도 내부적으로는 상당한 작업이 이뤄질 수 있습니다.

풀이 단계를 보여 달라고 요청해야 할 때

단계 자체가 유용한 결과물의 일부일 때는 그 단계를 보여 달라고 요청합니다. 재무 담당자에게는 수식과 대입한 값이 필요할 수 있습니다. 고객 지원 검토자에게는 정책 조항과 그에 해당하는 사실이 필요할 수 있습니다. 비즈니스 분석가에게는 권고안의 전제, 출처, 계산 근거가 필요할 수 있습니다.

요청은 구체적으로 작성합니다.

권고안, 이를 뒷받침하는 출처, 주요 가정, 간결한 설명을 반환하세요. 결과를 재현하는 데 필요한 계산을 보여주세요. 부족한 근거가 있으면 표시하세요.

이렇게 요청하면 사람이 검토할 수 있는 설명을 얻을 수 있습니다. 모델의 모든 내부 사고, 실패한 접근법, 비공개 중간 상태를 요구하는 것은 아닙니다.

제공업체가 제공하는 사고 요약은 또 다른 출력 유형입니다. OpenAI는 추론 토큰 원문 대신 지원되는 추론 요약을 공개합니다. Anthropic도 Claude의 사고 텍스트를 원래 사고의 사슬 자체가 아닌 요약으로 설명합니다. 이 요약은 진단에 도움이 되는 맥락으로 활용하되, 계산 과정 전체를 기록한 것으로 보아서는 안 됩니다. OpenAI 추론 요약, Claude 사고 출력.

개발자는 애플리케이션이 검증할 수 있는 필드를 정의합니다. 실무 담당자는 검토자가 확인할 수 있는 근거를 정의합니다. 판단에 현재 잔액이나 주문 상태가 필요하다면 툴로 그 사실을 조회해야 합니다. 함수 호출은 모델을 이런 외부 작업에 연결합니다. 더 오래 추론하라고 요청해도 빠진 기록이 생기지는 않습니다.

사고의 사슬 프롬프팅이 오히려 방해가 되는 경우

단순 조회나 정해진 형식의 정보 추출에는 복잡한 추론 프롬프트를 생략합니다. 이미 알려진 계정 ID를 반환하는 데 장황한 논증이 필요해서는 안 됩니다. 설명이 늘어나면 애플리케이션이 파싱해야 할 내용과 검토자가 읽어야 할 분량도 늘어납니다.

다음 한계는 지연 시간입니다. 추론 과정을 텍스트로 쓰면 출력량이 늘고, 내장 추론 기능의 강도를 높이면 필요한 답을 받기까지 시간이 더 걸릴 수 있습니다. OpenAI는 GPT-4.1 문서에서 출력량과 지연 시간 사이의 상충관계를 설명하며, Google은 단순한 작업에는 가벼운 사고 설정을 권장합니다. 실무에서는 직접적인 프롬프트로 시작하고, 평가 결과가 뒷받침할 때만 복잡성을 높이는 것이 원칙입니다. GPT-4.1 가이드, Gemini 사고 기능 지침.

정보 누락은 다른 종류의 실패입니다. 관련 정책을 애초에 제공하지 않았다면, 더 오래 추론하라는 요청으로 해결할 수 없습니다. 정책을 가져오고 그 버전을 확인해야 합니다. 입력이 너무 크다면, 사고량을 늘리는 실험에 앞서 모델의 작업 공간인 컨텍스트 윈도우에 어떤 정보가 들어가는지부터 조정합니다.

고정된 풀이 방법이 작업에 맞지 않을 수도 있습니다. 입고와 출고를 다루는 재고 예시는 반품, 파손, 예약 재고를 어떻게 처리할지는 알려주지 않습니다. 실제 작업을 잘 대표하는 예시를 사용하고, 모델이 누락된 규칙을 알릴 수 있게 해야 합니다.

원 논문의 수치가 보여주는 것과 보여주지 못하는 것

원래 벤치마크는 특정 작업에서 얻은 당시의 결과를 보여줄 뿐, 업무 정확도의 향상을 약속하지는 않습니다. Wei와 공동 저자들의 NeurIPS 2022 논문은 수학 문장제 벤치마크인 GSM8K에서 PaLM 540B의 정확도가 일반 프롬프팅에서는 17.9%, 사고의 사슬 프롬프팅에서는 **56.9%**였다고 보고합니다. 이 실험에서는 풀이 예시 여덟 개를 사용했습니다. 이 수치는 2023년 1월 10일자 개정 논문의 표 1에 실려 있습니다. 논문과 결과.

이 수치로 청구서 정보 추출, 환불 권고, 현재의 추론 모델에서 얻을 개선 폭을 추정할 수는 없습니다. 모델, 벤치마크, 프롬프트 구성이 모두 중요합니다. 기법이 주목받은 이유를 이해하는 데 참고한 뒤, 실제로 배포할 작업에서 성능을 측정해야 합니다.

사고의 사슬에 대한 기대는 어디서 과장되나요?

설득력 있는 설명이 곧 완전한 감사 기록은 아닙니다. Anthropic은 2025년 4월 3일 발표한 연구에서 모델이 주어진 힌트를 활용하면서도 설명에는 그 영향을 드러내지 않는 사례를 발견했습니다. 이는 특정 모델과 작업을 대상으로 통제된 상황에서 수행한 실험이며, 모든 업무 흐름을 측정한 결과가 아닙니다. 그럼에도 모델의 설명을 답이 만들어진 과정을 입증하는 자료로 취급해서는 안 되는 이유를 보여줍니다. Anthropic의 설명 충실성 연구.

감사 가능한 의사결정을 위해서는 제공한 문서, 조회한 기록, 툴 실행 결과, 적용한 규칙, 최종 출력을 보존해야 합니다. 인용 내용은 원문과 대조하고, 산술 계산은 가능하면 다시 계산합니다. 모델이 작성한 설명은 검토자가 권고안을 이해하는 데 도움이 될 수 있지만, 이런 기록을 대신할 수는 없습니다.

추론 모델이 나오면 프롬프트 설계가 필요 없어질 것이라는 주장도 과장입니다. 달라지는 것은 무엇을 지정해야 하느냐입니다. 업무 목표, 근거로 삼을 정보의 범위, 예외 처리, 출력 형식은 여전히 사용자가 정해야 합니다.

이번 주 업무 흐름에서 바꿔볼 것

모든 요청에 일괄적으로 “단계별로 생각해 봅시다”를 붙이고 있다면 지금 점검합니다. 개발자는 일상적인 정보 추출에서 이 지시를 빼 보고, 같은 사례에 직접적인 작업 지시를 적용해 비교해야 합니다. 실무 담당자는 모든 추론을 빠짐없이 설명해 달라는 요청 대신, 검토에 필요한 결과물인 근거, 계산, 가정, 간결한 권고안을 지정해야 합니다.

대안을 테스트하는 동안에는 잘 작동하는 기존 프롬프트를 유지합니다. 유용한 예시를 활용하는 비추론 모델이 저절로 쓸모없어지는 것은 아닙니다. 추론 모델로 전환하는 것은 재평가할 이유이지, 기존 업무 흐름을 없애야 한다는 근거가 아닙니다.

1. 1

   정답을 확인할 수 있는 작업을 고릅니다

   청구서 필드 추출이나 재고 대사처럼 반복되는 업무를 고릅니다. 무엇을 정답으로 볼지, 언제 정보 부족을 반환해야 할지, 소프트웨어가 어떤 출력을 파싱할 수 있어야 하는지 적어둡니다.

2. 2

   한 번에 하나의 변경만 비교합니다

   모델과 입력 사례를 고정한 채 직접 지시하는 프롬프트와 풀이 예시를 넣은 프롬프트를 비교합니다. 이어서 추론 모델에서는 프롬프트를 고정하고, 지원되는 추론 강도만 바꿔봅니다. 답변의 정확성, 근거가 부족할 때의 동작, 완료 시간, 토큰 사용량을 기록합니다.

3. 3

   복잡성을 더할 만큼 효과가 있는 변경만 남깁니다

   산술 계산과 정확히 일치해야 하는 필드는 명확한 규칙에 따른 검증을 우선합니다. 판단이 필요한 부분에는 평가 기준과 사람의 검토를 적용합니다. LLM을 평가자로 활용하는 방식은 평가 규모를 늘리는 데 도움이 될 수 있지만, 그 점수도 보정해야 합니다. 품질과 응답 시간 요구사항을 충족하는 버전을 배포합니다.

다가오는 월요일에는 반복 업무에 사용하는 프롬프트 하나를 고르고, 검토자에게 필요한 근거를 지정한 뒤 위 비교를 실행해 봅니다. 검증을 통과하는 구성 가운데 가장 단순한 것을 유지합니다.

사고의 사슬 프롬프팅에 관한 자주 묻는 질문

사고의 사슬 프롬프팅이란 무엇인가요?

언어 모델에 최종 답에 앞선 중간 단계나 풀이 예시를 제시하는 프롬프팅 방식입니다. 원래의 퓨샷 기법은 풀이 방법을 보여주고, 제로샷 CoT는 예시 없이 단계를 요청합니다.

사고의 사슬에는 어떤 예시가 있나요?

AI 프롬프팅에서는 풀이 과정을 보여주는 재고 계산이 예시가 됩니다. 시작 재고에서 출고량을 빼고 입고량을 더하면 마감 재고가 나옵니다. 정답이 있는 예시에 이 계산을 함께 제시하면 비슷한 질문에 어떻게 접근할지 보여줄 수 있습니다.

사고의 사슬 프롬프트는 어떻게 작성하나요?

“시작 재고가 18개이고, 7개를 출고한 뒤 4개를 입고했습니다. 몇 개가 남습니까? 단계별로 생각해 봅시다.” 이는 제로샷 CoT를 보여주는 예시입니다. 추론 기능을 갖춘 모델이라면 최종 결과물로 마감 재고와 재현 가능한 계산을 요청할 수도 있습니다.

추론 모델이 있어도 사고의 사슬 프롬프팅이 유용한가요?

그렇습니다. 특히 명시적인 예시가 도움이 되는 모델이나 풀이 설명 자체가 유용한 작업에서 쓸모가 있습니다. 다만 추론 모델에서는 출발점이 달라집니다. 명확한 지시와 내장 추론 제어 설정으로 시작하고, 도움이 되는 경우에 예시나 설명 요구사항을 추가합니다.

사고의 사슬 프롬프팅은 누가 처음 제안했나요?

Jason Wei와 공동 저자들이 2022년 논문 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models에서 이 이름의 기법을 소개했습니다. 프롬프트 안의 예시에 자연어로 작성한 중간 풀이를 결합한 연구이며, 판단 근거 설명과 프롬프팅에 관한 선행 연구를 토대로 했습니다.

사고의 사슬 프롬프팅의 가장 큰 장점은 무엇인가요?

적합한 모델이 곧바로 답을 내는 대신 중간 연산과 처리 과정을 거쳐 문제를 다루도록 도울 수 있습니다. 실제 업무 흐름을 개선하는지는 모델과 작업에 따라 다릅니다. 설명의 길이 자체가 품질 척도는 아닙니다.

프롬프트 체이닝과 사고의 사슬 프롬프팅은 어떻게 다른가요?

프롬프트 체이닝은 업무 흐름을 여러 번의 모델 호출로 나누고, 앞선 결과를 다음 호출에 전달합니다. 사고의 사슬 프롬프팅은 프롬프트의 예시나 응답 안에 있는 중간 단계를 다룹니다. 하나의 업무 흐름에 둘 다 쓸 수 있지만, 별개의 설계 선택입니다.

실무에 도움이 되는 AI 업무 흐름 구축 가이드를 받아보려면 뉴스레터를 구독하세요.