[OpenAI][Responses API] reasoning summary와 usage를 같이 읽어야 비용과 디버깅이 덜 꼬이는 이유

IT 리서치 노트

[OpenAI][Responses API] reasoning summary와 usage를 같이 읽어야 비용과 디버깅이 덜 꼬이는 이유

Responses API로 reasoning 모델을 붙였는데 느리거나 비싸거나 디버깅이 어려울 때 많은 팀이 output_text만 본다. 하지만 2026년 6월 27일 기준 OpenAI 공식 문서를 다시 보면, reasoning summary는 모델이 어떤 판단 흐름을 탔는지 보여 주고 usage는 그 판단에 얼마만큼의 토큰이 쓰였는지 보여 준다. 이 글은 이 둘을 같이 읽어야 운영이 덜 꼬이는 이유를 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 reasoning summary는 설명용, usage는 비용용으로 따로 저장해야 한다. summary만 남기면 왜 비쌌는지 모르게 되고, usage만 남기면 왜 그런 판단이 나왔는지 설명할 수 없다. Responses API에서 reasoning 모델을 운영할 때는 summary와 usage.output_tokens_details, max_output_tokens를 한 묶음으로 읽는 편이 가장 실용적이다.

이미 prompt caching 글이 토큰 절감 관점을 다뤘다면 이번 글은 reasoning workload의 읽기 순서다. 또 Responses background mode 글을 봤다면 비동기 처리에서도 같은 summary와 usage 로그를 재사용할 수 있다.

2. 어디서 실제로 막히는가

실무에서 먼저 꼬이는 지점은 세 가지다. 첫째, output_text만 저장해서 reasoning 모델이 왜 느렸는지 설명이 안 된다. 둘째, summary만 보고 '생각을 많이 했다'고 해석하지만 실제 reasoning tokens가 얼마나 쌓였는지 usage를 안 본다. 셋째, max_output_tokens를 너무 낮게 잡아 incomplete response가 났는데도 summary와 usage를 같이 안 읽어 원인을 놓친다.

공식 reasoning guide는 reasoning models가 Responses API에서 더 잘 동작한다고 설명하고, 비용 제어 구간에서는 total generated tokens를 max_output_tokens로 제한한다고 적는다. 즉 reasoning workload는 visible output만의 문제가 아니다. 내부 reasoning tokens와 formatting tokens까지 포함된 전체 사용량을 usage 쪽에서 봐야 한다.

또 reasoning summary는 기본 포함이 아니라 opt-in이다. summary를 요청하지 않으면 output_text만 남고, 이 경우 복잡한 판단이나 연속 함수 호출 후 재전달 흐름에서 디버깅 힌트가 크게 줄어든다. 반대로 summary만 켜고 usage를 안 보면 왜 비용이 갑자기 올라갔는지, 왜 max_output_tokens를 올려야 하는지 설명이 끊긴다.

• 증상: output_text는 정상인데 응답 시간이 길고 비용이 높다.
• 실패: summary를 안 남겨 판단 흐름을 재현하지 못한다.
• 막힘: usage를 안 남겨 reasoning token 비중을 설명하지 못한다.
• 누락: max_output_tokens와 incomplete response를 함께 보지 않는다.

증상	먼저 볼 곳	판단 기준
응답은 오지만 느리다	usage.output_tokens_details	reasoning_tokens 비중이 큰지 본다
판단 이유가 안 남는다	reasoning.summary	summary opt-in이 켜졌는지 본다
incomplete가 나온다	max_output_tokens와 usage	총 생성량 상한이 너무 낮은지 본다

3. 실무에서 적용하는 순서

운영 기준은 다섯 단계가 실용적이다. 먼저 reasoning 모델 요청에서 summary를 opt-in으로 켠다. 다음으로 usage 전체와 output_tokens_details를 저장한다. 세 번째로 max_output_tokens를 함께 로그에 남긴다. 네 번째로 응답이 incomplete이거나 함수 호출이 이어지면 summary와 usage를 같은 trace로 묶는다. 마지막으로 reasoning effort를 튜닝할 때도 이 네 항목을 함께 비교한다.

1. reasoning summary를 요청에 명시적으로 포함한다.
2. usage와 output_tokens_details를 빠짐없이 저장한다.
3. max_output_tokens를 같은 로그에 남긴다.
4. summary와 usage를 같은 trace id로 묶는다.
5. reasoning effort 변경 전후를 같은 표로 비교한다.

이 구조를 잡아 두면 비용 튜닝과 디버깅이 한 방향으로 간다. 예를 들어 reasoning_tokens가 과하게 높고 summary를 보면 같은 비교를 반복했다면 prompt나 tool 설계를 바꿀 수 있고, summary는 간단한데 output_tokens가 큰 경우는 결과 포맷이나 출력 길이 제어를 먼저 손보면 된다.

요청 예시

const response = await client.responses.create({
  model: "gpt-5.5",
  input: "Summarize the retry decision.",
  reasoning: {
    effort: "medium",
    summary: "auto"
  },
  max_output_tokens: 2400
});

특히 함수 호출과 다중 턴이 들어가는 흐름에서는 summary와 usage 저장이 더 중요하다. 공식 가이드도 reasoning items를 이후 요청에 다시 전달하라고 설명하므로, 운영 로그도 output_text만이 아니라 reasoning 관련 항목을 기준으로 잡는 편이 안전하다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면은 OpenAI reasoning guide의 핵심 문장이다. 현재 reasoning 모델은 Responses API에서 더 잘 동작한다고 문서가 직접 설명한다.

OpenAI 문서는 reasoning 모델을 Chat Completions보다 Responses API에서 쓰는 편이 낫다고 안내한다.

즉 reasoning summary와 usage 읽기도 Responses 응답 구조를 기준으로 보는 편이 맞다. 예전 completion 감각으로 output_text만 뽑아 쓰면 운영 정보가 많이 빠진다.

두 번째 화면은 비용 제어 구간이다. 문서는 reasoning tokens, visible output tokens, formatting tokens를 포함한 전체 생성량을 max_output_tokens로 다룬다고 적고 있다.

Reasoning guide는 비용을 보려면 max_output_tokens와 usage 세부 항목을 같이 읽어야 한다고 설명한다.

여기서 많은 팀이 visible output만 보고 비용을 추정하는데, reasoning workload에서는 내부 추론 토큰이 더 큰 비중을 차지할 수 있다. summary만 보고 usage를 안 보면 비용 설명이 비게 된다.

세 번째 자료는 reasoning summary 구간이다. OpenAI는 raw reasoning tokens를 노출하지 않지만, summary 파라미터를 통해 요약을 opt-in으로 포함할 수 있다고 적고 있다.

reasoning summary는 기본 포함이 아니라 opt-in이며, output의 reasoning item 안 summary 배열로 들어온다.

즉 summary는 디버깅과 설명을 돕는 도구이고, 사용량 판정은 usage와 같이 읽어야 한다. 둘 중 하나만 보면 왜 느리고 왜 비싼지 또는 왜 함수 호출 후 재전달이 필요한지 설명 기준이 흔들린다.

응답 JSON을 한 번 손으로 보면 구조가 빨리 잡힌다. reasoning summary는 output 배열의 reasoning item에 있고, 사용량은 usage와 output_tokens_details 쪽에 있다.

Responses API 응답에서 summary와 usage를 같이 읽는 예시다.

실무에서는 이 두 군데를 같은 로그 묶음으로 저장해 두는 편이 좋다. summary는 왜 그렇게 답했는지의 힌트를 주고, usage는 그 힌트를 얻기 위해 얼마를 썼는지 보여 준다.

summary와 usage는 보는 목적이 다르다. 한쪽은 설명과 재현이고, 다른 한쪽은 비용과 용량 계획이다. 둘을 한 표에 고정해 두면 어떤 로그를 남겨야 하는지도 정리된다.

summary와 usage를 각각 언제 읽는지 정리한 비교표다.

이미 prompt caching 글을 봤다면, usage는 절감 여부를 보는 축까지 이어진다. Responses 운영을 볼 때는 결과 텍스트만 저장하는 로그보다 이 표가 훨씬 실용적이다.

마지막 자료는 운영 로그 예시다. summary, usage, 모델명, reasoning effort, max_output_tokens를 한 줄 메모로 같이 남기면 재현성이 좋아진다.

Responses 운영 로그는 summary와 usage를 같은 trace에 남기는 편이 좋다.

이렇게 남겨 두면 함수 호출이 여러 번 이어진 세션에서도 어느 요청이 토큰을 많이 썼는지와, 왜 그 판단이 나왔는지를 같은 기록에서 읽을 수 있다. Responses background mode 글과 같이 보면 비동기 작업에서도 같은 구조를 재사용하기 쉽다.

5. 주의사항과 리스크

첫 번째 리스크는 summary를 raw chain-of-thought 대용으로 오해하는 것이다. 문서는 raw reasoning tokens가 아니라 summary를 제공한다고 분명히 적고 있다. 두 번째 리스크는 usage를 총 토큰 수 하나로만 저장해 reasoning token 비중을 놓치는 것이다. 세 번째 리스크는 max_output_tokens를 낮게 잡고 incomplete를 모델 품질 문제로 착각하는 것이다.

운영 전에는 동일한 프롬프트로 reasoning effort와 max_output_tokens를 바꿔 보고 summary와 usage가 어떻게 달라지는지 짧은 표를 남기는 편이 좋다. 이렇게 해야 이후 지연과 비용 이슈가 났을 때 근거가 생긴다.

• summary는 설명 보조용이고 raw reasoning 노출과는 다르다.
• usage는 total만 말고 details를 같이 저장한다.
• incomplete response는 max_output_tokens와 함께 읽는다.

6. 결론

Responses API에서 reasoning 모델을 운영할 때 summary와 usage를 따로 떼어 보면 설명과 비용 둘 중 하나가 비게 된다. summary는 판단 흐름을, usage는 토큰 소비를, max_output_tokens는 예산 상한을 보여 주므로 셋을 한 묶음으로 남겨야 비용 튜닝과 디버깅이 덜 꼬인다.

• summary와 usage를 같은 trace에 저장한다.
• reasoning_tokens 비중을 별도로 본다.
• max_output_tokens는 항상 함께 기록한다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/reasoning
2. https://developers.openai.com/api/docs/guides/latest-model
3. https://developers.openai.com/api/docs/guides/migrate-to-responses