작성자 노트: 지금 쓰는 Agent가 client.chat.completions.create에 tools를 붙여서 동작하고 있다면, GPT-6.1로 바꿀 때 아주 구체적인 분기점을 만나게 돼요. 텍스트 대화는 그대로 돌아가지만, 도구 호출은 엔드포인트를 바꿔야 해요.
GPT-6.1로 업그레이드하면 도구 호출이 엔드포인트에서 막히는 이유
결론부터 말씀드릴게요. GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra 세 모델은 모두 Chat Completions를 지원하지만, 도구 호출은 반드시 Responses API를 거쳐야 해요. 같은 코드 안에서도 순수 대화는 Chat에 그대로 두면 되지만, 함수를 붙이거나 도구 반환값을 읽거나 여러 턴에 걸친 도구 루프를 돌려야 하는 순간부터는 요청을 Responses 엔드포인트로 보내야 해요.
파라미터를 바꿔서 우회할 수 있는 호환성 문제가 아니에요. tools의 작성 방식을 바꿔도, tool_choice를 추가해도 소용없어요. 이 세 모델에 대해서는 Chat Completions 경로가 애초에 도구 호출 기능을 제공하지 않거든요. 실제로 손봐야 하는 것은 엔드포인트 자체와, 엔드포인트를 둘러싼 요청/응답 구조 전체예요. 두 엔드포인트를 내 키로 직접 돌려 비교해 보고 싶다면 APIYI(apiyi.com)의 통합 엔드포인트를 쓰면 돼요. base_url을 https://api.apiyi.com/v1로 지정하고 모델 ID만 바꾸면 바로 전환할 수 있어요.
또 하나 쉽게 놓치는 부분이 GPT-6 Sol과 GPT-6 Luna예요. 이 두 모델은 Chat Completions에서 함수 호출을 할 수 있지만, 조건이 reasoning_effort를 none으로 두는 것이에요. 즉 Chat으로도 도구를 호출할 수 있지만, 그 대가로 추론 강도를 꺼야 해요. 추론을 유지해야 한다면 이 경우에도 Responses로 돌아가야 해요. 이 세부 사항은 자주 간과돼서, 코드는 문제없이 돌아가는데 결과 품질이 이상한 상황이 생기곤 해요.
핵심 가치: 이 글을 읽고 나면 내가 쓰는 도구 호출 체인이 어떤 유형인지 판단할 수 있고, 전체 아키텍처를 뒤엎지 않고도 요청을 Chat 엔드포인트에서 Responses 엔드포인트로 옮길 수 있어요.
GPT-6.1 도구 호출 핵심 포인트
아래 표는 모델 3종과 이전 모델 2종이 각각 어떤 엔드포인트를 쓰는지 정리한 거예요. 먼저 자신이 쓰는 모델을 표에서 찾아보고, 그다음 마이그레이션 단계를 보는 걸 추천해요.
| 모델 | Chat Completions 텍스트 전용 | Chat Completions 도구 호출 | 도구 호출 시 사용할 엔드포인트 |
|---|---|---|---|
| gpt-6.1-sol | 지원 | 미지원 | Responses |
| gpt-6.1-terra | 지원 | 미지원 | Responses |
| gpt-6-astra | 지원 | 미지원 | Responses |
| gpt-6-sol | 지원 | reasoning_effort가 none일 때만 지원 |
Responses (추론을 유지해야 할 때) |
| gpt-6-luna | 지원 | reasoning_effort가 none일 때만 지원 |
Responses (추론을 유지해야 할 때) |
엔드포인트 역할 분담: 텍스트는 Chat, 도구는 Responses
표를 한 문장으로 요약하면 이렇게 돼요. GPT-6 시리즈에서 Chat Completions는 텍스트 전용 채널이 되었고, 도구 채널은 Responses로 따로 분리되었어요. 이 분리가 기존 프로젝트에 미치는 영향은 서비스 성격에 따라 달라요. 질의응답, 요약, 분류만 하는 서비스는 거의 손댈 필요가 없어요. 반면 에이전트, 함수 호출, 여러 단계에 걸친 도구 오케스트레이션을 하는 서비스는 반드시 마이그레이션해야 해요.
이미 SDK를 한 겹 감싸서 쓰고 있는 팀이라면 마이그레이션 범위가 생각보다 작아서 다행이에요. 모델 ID, 인증 방식, base_url은 모두 그대로예요. 바뀌는 건 요청 본문 구조와 도구 실행 결과를 다시 넘겨주는 방식에 집중되어 있어요. 그래서 실제 작업량은 ‘모델 교체’가 아니라 ‘호출 방식 교체’에 있어요.
주력 모델 3종의 선택 기준
GPT-6.1 Sol과 GPT-6.1 Terra는 이번 세대의 주력 쌍둥이 모델이고, 차이는 주로 포지셔닝과 비용에 있어요. GPT-6 Astra는 이전 세대의 플래그십으로, Chat 텍스트 전용 호출과 Responses 도구 호출을 모두 지원해요. 이미 안정적으로 운영 중이라 크게 바꾸고 싶지 않은 프로젝트에 잘 맞아요. 모델을 고를 때는 먼저 도구 호출 빈도를 보고, 그다음 한 번에 쓰는 컨텍스트 길이를 보고, 단가는 마지막에 보세요. 도구 호출은 보통 여러 번 왕복하면서 토큰 소모가 크게 늘어나기 때문이에요.
구체적인 가격은 뒤에 나오는 가격표를 참고하시거나, APIYI(apiyi.com) 문서에서 현재 적용 중인 과금 기준을 직접 확인해 보세요. 예전 가격으로 예산을 잡는 실수를 막을 수 있어요.
GPT-6.1 도구 호출, 어디를 5곳 고쳐야 할까요
이 부분이 글 전체에서 가장 실용적이에요. 아래 5곳만 고치면 일반적인 도구 호출 루프를 Chat 엔드포인트에서 Responses 엔드포인트로 옮길 수 있어요.
| 번호 | 변경 지점 | Chat Completions 방식 | Responses 방식 |
|---|---|---|---|
| 1 | 호출 메서드 | client.chat.completions.create |
client.responses.create |
| 2 | 입력 전달 방식 | messages 배열 |
input 파라미터 |
| 3 | 도구 선언 | tools (유지) |
tools (구조가 거의 동일) |
| 4 | 도구 결과 반환 | role: "tool" 메시지 |
function_call_output 타입 항목 |
| 5 | 멀티턴 컨텍스트 | messages 전체를 직접 이어 붙임 |
previous_response_id로 연결 가능 |
1번과 2번은 가장 놓치기 쉬워요. tools 구조만 고치고 마이그레이션이 끝났다고 생각했는데, 알고 보니 SDK 메서드는 그대로라 요청이 여전히 chat.completions로 가고 있는 경우가 많아요. 엔드포인트는 메서드가 결정하니까, 메서드를 바꾸지 않으면 엔드포인트도 바뀌지 않아요.
4번은 마이그레이션에서 가장 많이 막히는 부분이에요. Chat에서는 도구 실행 결과를 role: "tool" 메시지로 messages에 다시 넣었어요. Responses에서는 모델이 반환한 호출 항목을 그대로 함께 보내고, 그 뒤에 function_call_output 항목을 하나 더 붙여야 해요. 항목을 하나라도 빠뜨리거나 순서가 한 칸만 어긋나도 모델이 같은 호출을 반복해서 보낼 수 있어요.
5번은 “안 바꿔도 되지만 바꾸길 권하는” 항목이에요. Responses는 previous_response_id로 이전 턴을 이어받을 수 있어서, 매번 전체 히스토리 메시지를 다시 보내는 부담을 덜어줘요. 도구 호출 턴이 많은 Agent라면 모델을 바꾸는 것보다 이쪽이 비용에 더 큰 영향을 줘요.
🎯 기술 팁: 마이그레이션 중에 가장 손쉽게 검증하는 방법은 새 경로와 기존 경로에 같은 요청 묶음을 동시에 보내서 도구 호출 적중률과 반환 구조를 비교하는 거예요. APIYI(apiyi.com)의 통합 인터페이스를 쓰면 여러 플랫폼의 API 키를 따로 관리하지 않아도 돼요. 한 번만 설정하면 Responses와 Chat의 실제 응답 차이를 바로 대조해 볼 수 있어요.
GPT-6.1 도구 호출 빠르게 시작하기
도구를 호출하는 가장 간단한 예제
주문 상태를 조회하는 함수 도구가 있다고 가정해 볼게요. 이름은 get_order_status이고, 입력값은 주문 번호예요. 바꿔야 할 부분은 딱 두 군데예요. 호출 방식과 결과를 다시 전달하는 부분이에요.
- 클라이언트 초기화는 그대로 두세요.
api_key에는 본인의 키를 넣고,base_url은https://api.apiyi.com/v1로 설정해요. 이렇게 하면 OpenAI 호환 인터페이스를 지원하는 모델을 바로 호출할 수 있어요. - 모델 ID에는
gpt-6.1-sol(또는gpt-6.1-terra,gpt-6-astra)을 넣어요. 이 세 모델은 모두 Responses 방식으로 도구를 호출해요. - 기존의
client.chat.completions.create(...)를client.responses.create(...)로 바꾸고,messages파라미터는input으로 바꿔요. tools는 예전처럼 그대로 넘기면 돼요. 도구 설명과 파라미터 스키마를 다시 작성할 필요는 없어요.- 반환된
output에서 타입이function_call인 항목을 찾아 도구 이름과 파라미터를 꺼내고, 로컬에서 주문 조회 함수를 실행해요. - 실행 결과를
function_call_output으로 추가한 뒤, 두 번째 요청을 보내 최종 답변을 받아요.
이 6단계 중에서 “반드시 바꿔야 하는” 부분은 3단계와 6단계예요. 1, 2단계는 설정이고, 4, 5단계는 Chat 시절의 습관을 읽는 위치만 바꿔 주는 정도예요.
🚀 빠른 시작: 테스트 환경을 직접 구축하기 번거롭다면 APIYI(apiyi.com)에서 무료 테스트 크레딧을 받아 위의 주문 조회 예제를 한 번 돌려 보세요. 그런 다음 운영 코드를 수정하면 리스크를 가장 줄일 수 있어요.
더 간편한 방법은 도구 계층과 모델 계층을 먼저 분리하는 거예요. 도구 정의는 한곳에 모아 두고, 호출 진입점은 하나의 함수로 감싸요. 그리고 그 내부에서 “순수 텍스트면 Chat, tools가 있으면 Responses”로 분기하도록 하면 돼요. 이렇게 하면 마이그레이션은 래핑 계층에서만 일어나고, 비즈니스 코드는 한 줄도 건드리지 않아도 돼요.
GPT-6.1 모델 가격과 선택 가이드 (2026-11-12)
아래 표는 2026-11-12부터 적용되는 기준으로 정리했어요. 가격은 모두 100만 토큰(1M tokens)당 달러 단위예요.
| 모델 | 입력 | 출력 | 캐시 읽기 | 권장 엔드포인트 |
|---|---|---|---|---|
| gpt-6.1-sol | $2 | $10 | $0.1 | responses |
| gpt-6.1-terra | $1 | $5 | $0.05 | responses |
| gpt-6-luna | $0.1 | $0.5 | $0.01 | chat(reasoning_effort가 none일 때) 또는 responses |
이 표에서 아주 실용적인 결론을 하나 읽을 수 있어요. GPT-6.1 Terra의 입력·출력 가격은 Sol의 딱 절반이라서, 도구 호출 턴이 많고 컨텍스트가 자주 반복되는 환경에서는 Terra가 더 알맞은 기본 선택지인 경우가 많아요. GPT-6 Luna는 가격이 한 자릿수 배수가 아니라 한 단계(10배) 더 낮아서, 분류나 추출 같은 가벼운 작업은 Luna에 맡기고 Sol이나 Terra는 정말 추론이 필요한 도구 오케스트레이션 단계에 아껴 두기 좋아요.
캐시 읽기 가격 열도 따로 눈여겨볼 만해요. 도구 호출은 시스템 프롬프트, 도구 정의, 이전 대화 기록처럼 반복되는 앞부분(prefix)이 많이 생기는데, 이 부분이 캐시에 적중하면 단가가 입력 가격의 약 20분의 1 수준이에요. 그래서 Responses에서 previous_response_id로 컨텍스트를 이어 가면 트래픽만 줄어드는 게 아니라 실제 비용도 확실히 아낄 수 있어요.
💰 비용 팁: 프로젝트별로 예산을 나눠서 관리해야 한다면, APIYI(apiyi.com)의 통합 키로 호출해 보세요. 여러 모델의 사용량을 한곳에서 집계할 수 있고, 종량제 과금 방식과 함께 쓰면 도구 호출에 드는 실제 비용을 훨씬 쉽게 계산할 수 있어요.
GPT-6.1 도구 호출 자주 묻는 질문 FAQ
Q1: GPT-6.1은 무엇이고, GPT-6와는 어떤 관계인가요?
GPT-6.1은 GPT-6 시리즈의 개선 버전이에요. 현재 GPT-6.1 Sol과 GPT-6.1 Terra 두 가지가 있어요. GPT-6 시리즈에는 GPT-6 Astra, GPT-6 Sol, GPT-6 Luna가 포함돼요. 이들은 같은 Responses 도구 호출 채널을 공유하고, 차이는 주로 능력 포지셔닝과 가격에 있어요.
Q2: Chat Completions에서 도구 호출이 안 되는데, 파라미터를 잘못 쓴 건가요?
파라미터 문제가 아니에요. GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra는 Chat Completions에서 순수 텍스트 기능만 제공하고, 도구 호출은 Responses API로 제한돼요. `tools`나 `tool_choice`를 아무리 바꿔도 적용되지 않으니, SDK 메서드를 `chat.completions.create`에서 `responses.create`로 바꿔야 해요.
Q3: GPT-6 Sol과 GPT-6 Luna는 Chat에서 함수 호출을 할 수 있나요?
가능하지만 `reasoning_effort`를 `none`으로 설정했을 때만 가능해요. 추론 강도를 유지해야 한다면 이 두 모델도 Responses를 사용해야 해요. 이 제한은 마이그레이션할 때 가장 놓치기 쉬워요. 오류가 나지 않고, 결과만 기대와 다르게 나오기 때문이에요.
Q4: Responses로 마이그레이션하려면 모델 ID를 바꿔야 하나요?
바꿀 필요 없어요. 모델 ID는 `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-astra` 그대로 쓰면 되고, `base_url`과 인증 방식도 같아요. 실제로 바꿔야 하는 부분은 호출 메서드, 입력 형식, 도구 결과를 다시 전달하는 구조, 이렇게 세 가지예요.
Q5: 마이그레이션 후 도구 호출이 정상인지 빠르게 확인하려면 어떻게 하나요?
주문 조회 같은 간단한 도구 하나로 스모크 테스트를 해 보세요. 먼저 요청이 실제로 Responses 엔드포인트로 전달됐는지 확인하고, 다음으로 반환된 `output`에 `function_call` 항목이 있는지 확인해요. 마지막으로 `function_call_output`을 다시 전달한 뒤 모델이 최종 답변을 내놓는지 확인하면 돼요. 세 단계를 모두 통과하면 연동이 제대로 된 거예요. APIYI(apiyi.com)에서 테스트용 키를 받으면 이 검증을 바로 해볼 수 있어요.
Q6: 순수 텍스트 서비스도 Responses로 같이 옮겨야 하나요?
그럴 필요 없어요. 주요 모델 세 가지의 Chat Completions 순수 텍스트 기능은 여전히 사용할 수 있어요. 질의응답, 요약, 번역 같은 작업만 하는 서비스는 그대로 두면 돼요. `tools`가 포함된 요청만 옮기면 되고, 그래서 이번 변경의 영향 범위가 단계별로 나뉘어요.
Q7: 멀티턴 도구 호출에서 컨텍스트 비용은 어떻게 관리하나요?
매 턴마다 전체 대화 기록을 다시 보내는 대신 `previous_response_id`로 이전 턴을 이어 가세요. 그러면 반복되는 앞부분이 캐시에 적중하기 쉬워지고, 캐시 읽기 단가는 입력 단가보다 훨씬 낮아요. `gpt-6.1-sol`을 예로 들면 입력은 $2, 캐시 읽기는 $0.1로 차이가 꽤 커요.
Q8: Responses 마이그레이션에서 알려진 함정이 있나요?
대표적으로 두 가지가 있어요. 하나는 `tools` 구조만 바꾸고 호출 메서드는 바꾸지 않아서 요청이 여전히 Chat 엔드포인트로 가는 경우예요. 다른 하나는 도구 결과를 다시 전달할 때 예전 방식인 `role: “tool”`을 그대로 써서, 모델이 출력을 받지 못하고 호출을 반복하는 경우예요. 또 팀에서 `reasoning_effort`가 `none`이어야 하는 GPT-6 Sol 같은 모델을 함께 쓴다면, 래퍼 계층에서 제약을 통일해 두는 게 좋아요. 그래야 “같은 도구가 어떤 모델에서는 되고 어떤 모델에서는 안 되는” 상황을 피할 수 있어요.
GPT-6.1 도구 호출 핵심 요약 Key Takeaways
- 엔드포인트가 갈라졌어요: GPT-6.1 Sol, Terra와 GPT-6 Astra는 텍스트는 Chat으로 처리하지만, 도구 호출은 반드시 Responses를 사용해야 해요.
- 예외가 하나 있어요: GPT-6 Sol, GPT-6 Luna는 Chat에서도 함수 호출을 할 수 있지만,
reasoning_effort가none이어야 해요. - 바뀌는 곳은 다섯 군데예요: 호출 메서드,
input구조,tools선언,function_call_output회신,previous_response_id연결이에요. - 모델 ID는 그대로예요:
base_url과 키는 건드릴 필요가 없고, 마이그레이션은 래퍼 계층에서만 일어나요. - 비용은 캐시가 좌우해요: 도구 호출은 프리픽스 반복률이 높아서, 캐시 읽기 가격이 입력 가격의 약 20분의 1이에요.
- 검증은 세 단계로 해요: 엔드포인트를 확인하고,
output에function_call이 있는지 확인한 다음, 결과를 회신한 뒤 최종 답변이 오는지 확인하세요. - 시작하는 방법: APIYI apiyi.com의 무료 크레딧으로 주문 조회 같은 작은 도구를 먼저 돌려 보고, 그다음에 운영 환경의 호출 경로를 바꿔 보세요.
정리
이번 변화의 핵심은 한 문장으로 요약돼요. GPT-6.1은 도구 호출을 Chat Completions에서 Responses로 옮겼고, 순수 텍스트 기능은 그대로 남겨 뒀다는 거예요. 여기서 기억해 둘 만한 세 가지가 나와요.
- 먼저 분류하고 마이그레이션하세요: 텍스트만 다루는 서비스는 그대로 두고,
tools가 들어간 요청만 엔드포인트를 바꿔야 해요. - 파라미터가 아니라 메서드를 바꾸세요: 엔드포인트를 바꾸는 스위치는
client.responses.create이고,tools구조는 거기에 맞춰 따라오는 부분이에요. - 결과 회신에서 가장 많이 실수해요:
function_call_output이role: "tool"을 대체했기 때문에, 순서와 완전성을 모두 맞춰야 해요.
이미 운영 환경에서 도구 호출을 쓰고 있다면, 먼저 가장 작은 도구 하나로 점진적 배포(카나리 배포)를 해 보고, 호출 경로가 정상인 것을 확인한 뒤에 전체를 전환하는 걸 추천해요. 여러 플랫폼의 키와 환경 설정에 드는 시간을 줄이고 싶다면, APIYI apiyi.com에서 하나의 키로 Responses와 Chat의 실제 응답을 비교해 볼 수 있어요. base_url은 https://api.apiyi.com/v1로 통일하면 돼요.
참고 자료
- OpenAI 공식 모델 문서: GPT-6 시리즈와 GPT-6.1 시리즈의 엔드포인트별 지원 기능 설명이에요. 도구 호출은 Responses를 써야 한다는 제약도 포함돼 있어요.
- 링크:
developers.openai.com/api/docs/guides/latest-model -
설명: 특정 모델이 Chat Completions에서 함수 호출을 지원하는지 판단할 때 가장 신뢰할 수 있는 1차 자료예요.
-
APIYI 모델 및 가격 문서: 모델별 입력·출력·캐시 읽기 단가와 권장 엔드포인트를 정리한 문서예요.
- 링크:
docs.apiyi.com/models - 설명: 2026-11-12부터 적용되는 과금 기준과 엔드포인트 권장 사항을 확인할 수 있어요.
작성자: APIYI 기술팀
기술 교류: APIYI apiyi.com 홈페이지에서 언제든 문의해 주세요. 더 자세한 API 설명은 docs.apiyi.com 문서 센터에서 확인하실 수 있어요.
