한 줄 정의
reasoning content는 DeepSeek API 사고 모드에서 최종 답변과 따로 돌아오는 추론 기록이야. 실제 응답 필드 이름은 reasoning_content이고, 사용자가 받아야 할 문장은 보통 content에 들어가.
DeepSeek Reasoner와도 바로 이어져. Reasoner는 DeepSeek API에서 reasoning 계열 모델을 볼 때 같이 확인하는 항목이고, 이 페이지는 그 경로에서 응답과 추론 기록을 어떻게 분리해 다루는지 설명해.
그래서 이 용어를 보면 먼저 “답변 본문인가, 내부 추론 기록인가”를 나눠야 해. Chat Completions 응답에서 두 값을 같은 텍스트처럼 저장하거나 화면에 섞어 보여주면, 로그도 흐려지고 다음 요청을 만들 때도 헷갈려.
어떻게 작동하나
DeepSeek의 2026년 5월 7일 기준 API 참조는 /chat/completions 요청에서 사고 모드를 thinking 설정으로 제어한다고 설명해. 추론 강도는 high와 max 두 값으로 조절하고, 호환성 때문에 low와 medium은 high로, xhigh는 max로 매핑돼.
스트리밍에서도 답변 조각과 추론 조각은 따로 온다. 운영 코드에서는 화면에 보낼 답변, 디버깅용 사고 기록, 사용량 수치를 분리해서 누적하는 편이 좋아. 예를 들어 고객지원 챗봇이라면 사용자는 정리된 답만 보고, 운영자는 실패한 요청을 분석할 때 별도 추론 로그를 확인하는 식이야.
비용과 길이 계산에서도 차이가 난다. DeepSeek 응답 사용량에는 completion_tokens_details.reasoning_tokens가 있어서, 최종 답변이 짧아도 추론에 쓴 토큰이 많은지 확인할 수 있어. 이 값을 안 보면 “답은 짧은데 왜 비용이 늘었지?” 같은 질문에 답하기 어렵다.
왜 중요한가
이 필드가 중요한 이유는 에이전트 흐름에서 후속 메시지를 만드는 방식이 달라지기 때문이야. DeepSeek의 멀티턴 가이드는 /chat/completions가 상태 비저장형 API라서, 2번째 요청을 보낼 때 이전 대화 이력을 다시 messages에 붙여 보내야 한다고 설명해.
그런데 사고 모드에서는 이전 턴의 추론 기록을 어떻게 다룰지가 별도 규칙으로 갈려. 도구 호출이 없는 일반 대화라면 다음 문맥에 꼭 넣을 필요가 없어. 반대로 도구 사용이 들어간 사고 모드에서는 이 값이 tool call과 이어지는 중간 상태가 될 수 있고, DeepSeek 문서는 제대로 넘기지 않으면 400 오류가 날 수 있다고 설명해.
실무에서는 이 차이가 작지 않아. 검색 도구를 부르는 리서치 봇, 사내 함수를 호출하는 자동화 서버, 코딩 에이전트처럼 tool call이 있는 흐름에서는 assistant 메시지에 답변, 사고 기록, 도구 호출 목록이 함께 남아야 할 수 있어. 반대로 단순 질의응답에서는 추론 로그를 계속 다시 보내면 문맥과 저장소만 불필요하게 무거워질 수 있어.
주의해서 볼 점
첫째, 이 필드는 Chain-of-Thought와 가까운 개념이지만, 항상 사용자에게 보여줄 설명은 아니야. 최종 답변과 검토용 기록을 분리해서 저장해야 나중에 품질 분석, 비용 분석, 개인정보 점검을 따로 할 수 있어.
둘째, 입력 기능과 출력 기능을 섞으면 안 돼. DeepSeek API 참조에는 Chat Prefix Completion 베타에서 마지막 assistant 메시지의 CoT 입력으로 같은 이름의 필드를 쓰는 좁은 경우가 있어. 이때는 base_url="https://api.deepseek.com/beta"와 prefix: true 조건이 붙어.
셋째, 이 규칙을 OpenAI 호환 API 전체의 공통값으로 보면 안 돼. SDK 문법이 비슷해도 제공자마다 추론 기록 공개 여부, 토큰 집계 방식, tool call 뒤 메시지 재구성 규칙이 다를 수 있어. 다른 모델 제공자로 옮길 때는 필드 존재 여부부터 다시 확인해야 해.