gpt-6.1-sol 프롬프트 레시피: 코딩, 추론, JSON, 도구 호출 (실제 출력 포함)

gpt-6.1-sol은 hiapi의 추론급 텍스트 모델로, 대화·코딩·단계적 추론을 모두 Responses API(POST /v1/responses)를 통해 제공합니다. 이미 호출 방법을 알고 있다면 이 페이지가 다음 단계입니다. 실제로 가장 많이 쓰이는 네 가지 작업—코딩, 추론, 엄격한 JSON, 도구 호출—을 다루는 복사-붙여넣기 가능한 프롬프트 레시피 모음이며, 각 레시피에는 이 글을 위해 실제로 실행했을 때 얻은 정확한 출력이 함께 실려 있습니다. 인증, 스트리밍, SSE 파싱에 대해서는 설정 가이드부터 시작하세요. 여기서는 프롬프트 자체에만 집중합니다.

아래의 각 레시피는 요청 본문 하나이며, 해당 설정에 그대로 넣으면 됩니다. 프롬프트는 두 필드로 구성됩니다. 최상위 instructions(역할 설정과 형식 규칙)와 input 배열(작업 자체)입니다. 이론은 전혀 없습니다—모든 출력은 실제 response.completed 이벤트에서 그대로 붙여넣은 것입니다.

gpt-6.1-sol 프롬프트 작성 방식을 좌우하는 세 가지 지렛대

레시피로 넘어가기 전에, 이 모델에 관한 세 가지 사실이 여러분이 쓰는 모든 프롬프트를 형성합니다. 세 가지 모두 hiapi 모델의 실제 계약과 대조해 확인했습니다.

1. temperature도 top_p도 없습니다. 이 실행 구성은 이 둘(그리고 max_output_tokens)을 비활성화합니다. 샘플링으로 결정성이나 창의성을 조절할 수 없습니다—조절 가능한 유일한 손잡이는 instructions, input, reasoning.effort입니다. 간결하고 결정론적으로 느껴지는 출력을 원한다면 instructions에 명시하세요. temperature: 0을 설정할 수는 없습니다.
2. reasoning.effort에는 다섯 단계가 있습니다: low, medium, high, xhigh, max(기본값 medium). effort가 높을수록 더 많은 숨겨진 추론 토큰을 소비하며, 이는 출력 토큰으로 과금됩니다. 레시피 2가 실제 곡선을 보여줍니다.
3. 컨텍스트 창은 약 1.05M 토큰(최대 출력 128K)입니다. 토큰 과금은 계단식이라, 단일 요청의 입력이 272K 토큰을 넘으면 입력/출력 요율이 대략 두 배가 됩니다. 일상적인 프롬프트에서는 이 선에 한참 못 미치지만, 긴 컨텍스트 작업(레시피 5)에서는 알아둘 가치가 있습니다.

레시피 1—코딩: 사양에 따라 함수 생성하기

엔지니어링 역할과 출력의 형태를 instructions에 넣고, 사양을 input에 넣습니다. 형태를 제약하는 것("코드 펜스 블록 하나, 그다음 한 문장")이 추론 모델이 코드를 세 문단의 서문으로 감싸지 않게 막는 방법입니다.

{
  "model": "gpt-6.1-sol",
  "instructions": "당신은 시니어 Python 엔지니어입니다. 단일 Python 펜스 코드 블록을 반환한 뒤, 한 문장으로 복잡도를 설명하세요. 서문은 쓰지 마세요.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "`merge_intervals(intervals: list[list[int]]) -> list[list[int]]`를 작성하세요. 겹치는 닫힌 구간을 병합하고 시작점 기준으로 정렬해 반환하세요. 빈 리스트를 처리하세요. docstring을 포함하세요." }
    ] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

반환된 내용(그대로):

def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
    """겹치는 닫힌 구간을 병합하여 시작점 기준으로 정렬해 반환합니다.

    입력 리스트와 그 안의 구간은 수정되지 않습니다.
    """
    if not intervals:
        return []

    ordered = sorted(intervals, key=lambda interval: interval[0])
    merged = [ordered[0].copy()]

    for start, end in ordered[1:]:
        if start <= merged[-1][1]:
            merged[-1][1] = max(merged[-1][1], end)
        else:
            merged.append([start, end])

    return merged

시간 복잡도는 O(n log n), 공간 복잡도는 O(n)입니다.

제약이 무엇을 가져왔는지 주목하세요. 빈 리스트를 올바르게 처리하고, 수정 전에 각 구간을 복사하여(ordered[0].copy()) 호출자의 데이터가 변경되지 않게 했으며, 분석을 정확히 한 문장만 말하고 멈췄습니다. 이런 기계적 코딩에는 effort: low로 충분합니다—추론 토큰을 0개 사용했고도 올바르고 비제자리 수정 코드를 생성했습니다.

레시피 2—추론: effort로 사고 예산 제어하기

temperature를 설정할 수 없으므로 reasoning.effort가 어려운 문제에 대응하는 주된 손잡이입니다. 프롬프트는 그대로 두고 effort만 바꿔 보세요:

{
  "model": "gpt-6.1-sol",
  "instructions": "단계적으로 생각한 뒤, 한 줄 `Answer: <value>`로 끝내세요.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "한 제과점이 6개입 상자와 11개입 상자로 쿠키를 판매합니다. 정확히 살 수 없는 최대 쿠키 수는 얼마인가요? 추론 과정을 보여주세요." }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

같은 프롬프트를 다섯 가지 effort 수준 모두에서 실행했습니다. 모든 수준이 정답 49를 반환했습니다. 달라진 것은 그 답을 위해 얼마나 많은 사고를 썼는가입니다:

reasoning.effort	추론 토큰	총 출력 토큰	대략 비용*
low	76	305	≈ $0.0008
medium	121	380	≈ $0.0010
high	209	427	≈ $0.0011
xhigh	626	845	≈ $0.0021
max	622	813	≈ $0.0021

*기본 요율 기준($0.50 / 1M 입력, $2.50 / 1M 출력), 추론 토큰은 출력으로 과금. 데이터는 이번 실행 기준, 2026-10. 현재 요율은 가격 페이지를 확인하세요.

실용적인 교훈은 마지막 두 행에 있습니다. effort는 low에서 high까지 완만하게 상승하다가 평탄해집니다—xhigh와 max 모두 약 620개의 추론 토큰에 머물렀는데, 이 문제가 더 많은 사고를 요구할 만큼 어렵지 않았기 때문입니다. 간단한 프롬프트에 effort를 최대로 올린다고 해서 더 나은 답이 나오지는 않습니다. 같은 "49"를 위해 출력 토큰을 약 2.5배 더 쓰는 것뿐입니다. effort를 난이도에 맞추세요: 대부분의 프롬프트에는 low/medium, 작업이 정말로 더 깊은 탐색을 요구할 때만 high 이상을 쓰세요.

다음은 medium의 출력으로, 프롬프트가 어떤 형태를 만들어냈는지 볼 수 있습니다:

가장 큰 수는 49개 쿠키입니다.

1. 49를 정확히 살 수 없음을 증명. 49 = 6a + 11b라고 가정하되, a, b는 음이 아닌 정수입니다. 양변을 6으로 나눈 나머지를 취하면 5b ≡ 1 (mod 6)이므로 b ≡ 5 (mod 6)입니다. 따라서 b는 최소 5이지만, 11개입 상자 다섯 개면 이미 쿠키 55개입니다. 불가능합니다.

2. 49보다 큰 모든 수를 살 수 있음을 증명. ……50 이상의 모든 정수는 연속으로 도달 가능한 여섯 개의 총합 중 하나에 6의 음이 아닌 배수를 더한 값입니다.

Answer: 49

instructions의 Answer: <value> 줄은 실제로 효과가 있습니다. 모델이 추론 과정을 버리도록 강요하지 않고도 마지막 줄을 간단히 파싱할 수 있게 해줍니다(text.rsplit("Answer:", 1)[-1].strip()).

레시피 3—스키마를 사용한 엄격한 JSON

산문으로 JSON을 요구한 뒤 기도하지 마세요. gpt-6.1-sol은 엄격한 구조화 출력을 지원합니다. json_schema와 함께 text.format을 전달하면 모델이 요구 사항을 충족하는 JSON을 출력하도록 제약됩니다—코드 펜스도, 군더더기 산문도 없습니다.

{
  "model": "gpt-6.1-sol",
  "instructions": "지원 티켓을 분류하세요. 해당 JSON 객체만 응답하세요.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "티켓: '오늘 아침부터 4K 업스케일 엔드포인트가 호출할 때마다 500을 반환합니다. 내일 출시인데 이 때문에 막혔습니다.'" }
    ] }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "ticket",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
          "topics": { "type": "array", "items": { "type": "string" } },
          "action_required": { "type": "boolean" }
        },
        "required": ["sentiment", "topics", "action_required"],
        "additionalProperties": false
      }
    }
  },
  "reasoning": { "effort": "low" },
  "stream": true
}

반환된 내용(그대로, 한 줄):

{"action_required":true,"sentiment":"negative","topics":["4K upscale endpoint","HTTP 500 errors","Service outage","Launch blocker","Urgent support"]}

두 가지를 새겨두세요. 첫째, strict: true는 타입과 필수 키를 보장하지만 키 순서는 보장하지 않습니다—스키마에서 마지막에 나열된 action_required가 맨 앞에 나온 점을 주목하세요. 그러니 위치가 아니라 키로 파싱하세요. 둘째, 스키마는 내용을 형성할 뿐 전송 방식을 바꾸지 않으므로, 다른 응답과 마찬가지로 response.output_text.delta 블록에서 답을 계속 누적해야 합니다.

레시피 4—도구 호출과 결과 이어가기

gpt-6.1-sol은 함수를 호출할 수 있고—중요하게도—여러분이 결과를 반환한 뒤 이어서 작업할 수 있습니다. tools 배열을 선언하세요. 모델이 호출을 결정하면 텍스트 대신 function_call 항목을 내보냅니다.

{
  "model": "gpt-6.1-sol",
  "instructions": "도구를 호출할 수 있습니다. 사용자가 어떤 작업에 대해 물으면 get_task_status를 호출하세요.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "task_abc123이 어떻게 됐는지 확인해 줄 수 있나요? pending 상태로 오래 있었어요." }
    ] }
  ],
  "tools": [
    {
      "type": "function",
      "name": "get_task_status",
      "description": "id로 비동기 이미지/비디오 생성 작업의 상태를 조회합니다.",
      "parameters": {
        "type": "object",
        "properties": { "task_id": { "type": "string", "description": "작업 id, 예: 'task_abc123'." } },
        "required": ["task_id"],
        "additionalProperties": false
      }
    }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

응답에는 텍스트가 없습니다—최종 이벤트에서 function_call 항목으로 전달된 하나의 도구 호출뿐입니다(그 인수는 response.function_call_arguments.delta 블록으로 스트리밍됩니다):

{
  "type": "function_call",
  "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b",
  "name": "get_task_status",
  "arguments": "{\"task_id\":\"task_abc123\"}"
}

이제 기본 설정이 다루지 않은 후반부입니다. 함수를 실행한 뒤 결과를 다시 넘기세요—모델의 function_call과 여러분의 function_call_output(같은 call_id로 연결)을 input 배열에 추가하고 다시 호출하세요:

{
  "model": "gpt-6.1-sol",
  "instructions": "도구를 호출할 수 있습니다. 도구 결과를 사용자에게 한두 문장으로 요약하세요.",
  "input": [
    { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "task_abc123이 어떻게 됐는지 확인해 줄 수 있나요? pending 상태로 오래 있었어요." } ] },
    { "type": "function_call", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "name": "get_task_status", "arguments": "{\"task_id\":\"task_abc123\"}" },
    { "type": "function_call_output", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "output": "{\"status\":\"failed\",\"error\":\"INVALID_REQUEST: image url could not be downloaded\",\"created_at\":\"2026-10-17T06:12:00Z\"}" }
  ],
  "tools": [ { "type": "function", "name": "get_task_status", "description": "id로 비동기 생성 작업의 상태를 조회합니다.", "parameters": { "type": "object", "properties": { "task_id": { "type": "string" } }, "required": ["task_id"], "additionalProperties": false } } ],
  "reasoning": { "effort": "low" },
  "stream": true
}

결과를 받은 뒤 평이한 언어로 답합니다(그대로):

작업 task_abc123은 더 이상 pending 상태가 아닙니다—이미지 URL을 다운로드할 수 없어서 실패했습니다(INVALID_REQUEST). 이미지 URL이 공개적으로 접근 가능한지 확인한 뒤 작업을 다시 제출하세요.

call_id가 접착제입니다. 여러분의 function_call_output은 모델의 function_call에 있는 정확한 call_id를 그대로 반영해야 하며, 그렇지 않으면 후속 턴이 거기에 묶이지 않습니다.

레시피 5—긴 컨텍스트에서 근거 있는 답변

1.05M 토큰 창은 로그, 변경 로그, 사양 문서 같은 실제 자료를 넣고 그것에 근거하여 답하는 데 쓰입니다. 모델을 정직하게 유지하는 프롬프트 패턴은 instructions에 있습니다. 제공된 텍스트만 근거로 답하고, 모든 사실의 출처를 인용하도록 강제하는 것입니다.

{
  "model": "gpt-6.1-sol",
  "instructions": "제공된 CHANGELOG만 근거로 답하세요. 어떤 사실이 없으면 'not in the changelog'라고 말하세요. 사용하는 모든 사실의 날짜를 인용하세요.",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "<여기에 CHANGELOG 붙여넣기>\n질문: 어제는 비디오 작업의 출력 URL이 제 파일을 반환했는데 오늘은 404가 나고, 또 이미지 호출이 방금부터 402를 반환합니다. 어떤 두 변경 로그 항목이 이를 설명하며, 무엇을 바꿔야 하나요?" }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

짧은 플랫폼 변경 로그를 주자, 관련된 두 항목을 정확히 추출하고 그 날짜를 인용하며 "무슨 일이 있었는지"와 "무엇을 바꿔야 하는지"를 분리했습니다(그대로):

두 항목이 이 문제들을 설명합니다:

1. 2026-10-02—임시 출력 URL 만료. temp.hiapi.ai의 출력 URL은 7일 동안 유효하며, 이후 404를 반환합니다……변경: 바이트를 즉시 다운로드하여 자체 복사본을 저장하세요. 핫링크하지 마세요. expireAt으로 만료 시간을 추적하세요.

2. 2026-09-20—잔액이 비면 이미지 모델에서 402 발생. 잔액이 완전히 빈 계정은 이제 모든 이미지 모델에서 HTTP 402를 받습니다……변경: 계정 잔액이 완전히 비었는지 확인하고, 그렇다면 충전하세요.

"날짜 인용" 지시는 값싼 근거 기법입니다. 환각을 가시화하고(인용할 날짜가 없는 사실은 모델이 지어낸 사실입니다) 답변을 감사 가능하게 만듭니다. 계단식 가격을 기억하세요—입력이 272K 토큰을 넘는 프롬프트는 더 높은 긴 컨텍스트 요율로 과금됩니다.

이번 실행에서의 한 가지 함정: 스트림을 UTF-8로 디코딩하기

추론 모델은 긴 줄표와 곱은 따옴표를 좋아합니다. 이 글을 쓰는 시점에 우리의 첫 SSE 리더는 멀티바이트 UTF-8 문자를 두 네트워크 청크에 걸쳐 쪼개 버렸고, 깔끔한 긴 줄표("—")가 깨진 글자("â")로 변했습니다. 모델의 출력은 문제가 없었습니다. 클라이언트가 성급하게 줄 단위로 디코딩한 탓이었습니다. 해결책은 원시 바이트를 버퍼링하고, 개행 문자로 나눈 뒤, 각 완전한 줄을 UTF-8로 디코딩하는 것입니다—불완전한 청크는 디코딩하지 마세요. gpt-6.1-sol 출력에 산발적인 Ã/â 문자가 보인다면 원인은 모델이 아니라 여기에 있습니다.

자주 묻는 질문

gpt-6.1-sol 설정 가이드와 무엇이 다른가요? 설정 가이드는 모델을 호출하는 방법—인증, 스트리밍이 필수인 이유, SSE 파싱—을 다룹니다. 이 페이지는 모델에 프롬프트를 주는 방법, 즉 특정 작업을 위한 instructions/input/effort 패턴과 그로 인해 나오는 출력을 다룹니다.

reasoning.effort를 max로 올리면 최고의 답을 얻을 수 있나요? 공짜가 아니고, 흔히 더 나아지지도 않습니다. 우리 테스트 문제에서는 xhigh와 max 모두 약 620개의 추론 토큰에서 평탄해져 high와 같은 답을 반환했습니다. 추론 토큰은 출력으로 과금되므로, 간단한 프롬프트를 최대로 올리면 같은 결과에 더 많은 비용을 씁니다. high 이상은 정말 어려운 추론에 남겨두세요.

프롬프트에서 요구하는 대신 유효한 JSON을 강제하려면 어떻게 하나요? strict json_schema와 함께 text.format을 전달하세요(레시피 3). 모델이 스키마의 타입과 필수 키를 충족하도록 제약됩니다. strict는 키 순서를 고정하지 않으므로 키 이름으로 파싱하세요.

왜 temperature나 top_p를 설정할 수 없나요? 이 실행 구성은 이 둘(그리고 max_output_tokens)을 비활성화합니다. 대신 instructions, input, reasoning.effort를 통해 출력을 형성하세요.

도구 호출이 채팅 모델에서와 같은 방식으로 작동하나요? 계약이 약간 다릅니다. 도구는 최상위 tools 배열에 선언하고, 모델은 (메시지가 아닌) function_call 항목으로 응답하며, 일치하는 call_id와 함께 function_call_output을 추가하여 계속합니다(레시피 4).

gpt-6.1-sol은 gpt-5.6-sol과 같은가요? 둘은 Sol 패밀리에 속하며 같은 Responses-API, 스트리밍 전용 계약을 공유합니다. gpt-6.1-sol이 더 새로운 세대입니다. 세대 간 대응 관계는 gpt-6 Astra 대 gpt-5.6 Sol 비교를 참고하세요.

여기서 시작하세요

위의 아무 레시피나 설정 가이드의 요청 본문에 복사하고, 여러분의 작업으로 바꾸고, 난이도에 맞춰 reasoning.effort를 조정하세요. 기능 소개와 온라인 체험 상자는 gpt-6.1-sol 모델 페이지에, 엔드포인트와 공유 요청 형식은 API 문서에, 토큰당 요율은 가격 페이지에 있습니다. hiapi 키 하나로 gpt-6.1-sol과 플랫폼의 다른 모든 모델에 접근할 수 있습니다.