AI 온도 조절·답변 첫머리 넣기 — 최신 모델은 거부합니다

AI를 코드로 다루는 글과 강의에 오래 실려 온 기법이 둘 있습니다. 하나는 "창의성을 올리려면 온도를 높이세요", 다른 하나는 "답변 첫머리를 대신 써 두면 그 형식대로 이어 씁니다"입니다. 둘 다 잘 먹히던 방법이었죠. 그런데 공식 문서를 보면 지금은 사정이 달라졌습니다 — 최신 세대 모델에서는 둘 다 요청 자체가 거부됩니다. 예전 예제를 그대로 복사해 쓰면 코드가 아니라 요청이 통째로 튕깁니다.

📌 30초 요약

• 무작위성 조절 인자 세 가지가 막혔습니다. 기본값이 아닌 값을 넣으면 요청이 거부됩니다.
• 답변 첫머리를 대신 써 주는 방식도 막혔습니다. 대신 정해진 틀로 받는 기능을 쓰라고 안내합니다.
• 대화는 상태가 없습니다. 매번 전체 기록을 다시 보냅니다.
• 대신 예전 차례를 지어 넣어도 됩니다. AI가 실제로 한 말일 필요가 없습니다.
• 거절당하면 어떤 범주 때문인지가 함께 옵니다. 모든 모델에서요.

1. 대화는 매번 통째로 다시 보냅니다

먼저 기본 성질 하나. 이 방식에는 기억이 없습니다. 서버가 우리 대화를 들고 있지 않기 때문에, 두 번째 질문을 할 때도 첫 질문과 그 답변까지 전부 다시 실어 보내야 합니다. 대화가 길어질수록 매번 보내는 양이 늘어난다는 뜻이고, 요금이 대화 길이에 따라 커지는 이유이기도 합니다.

그런데 여기서 재미있는 자유가 나옵니다. 문서가 대놓고 적어 놨습니다 — 앞선 차례가 실제로 AI가 한 말일 필요는 없습니다. 내가 원하는 말투와 형식으로 답변을 지어서 대화에 심어 두면, AI는 그걸 자기가 한 말로 여기고 그 결을 이어 갑니다. "이런 식으로 답해 줘"라고 설명하는 것보다 실제 예시를 한 번 보여 주는 쪽이 훨씬 잘 먹히는데, 그 예시를 대화 기록에 끼워 넣는 방식이죠. 프롬프트를 다듬는 여러 패턴을 써 보셨다면, 이건 지시가 아니라 맥락으로 가르치는 방법이라고 보시면 됩니다.

2. 무작위성 조절이 최신 세대에서 막혔습니다

답변이 얼마나 예측 가능한지를 조절하는 인자가 전통적으로 세 가지 있었습니다. 흔히 온도라고 부르는 값, 후보를 확률 합으로 자르는 값, 후보 개수로 자르는 값입니다. "정확해야 하는 작업은 온도를 0에 가깝게, 아이디어를 뽑을 때는 높게"가 오래된 정석이었죠.

하려던 것	예전 방식	지금 해야 할 것
답을 일관되게	온도를 0 가까이	지시문에 "간결하고 일관되게"를 명시
다양한 아이디어	온도를 높이기	"서로 다른 방향으로 다섯 개"처럼 요구를 구체화
형식을 강제	답변 첫머리 대신 쓰기	정해진 틀로 받는 기능 사용
말투를 고정	지시문으로 설명	대화에 예시 답변을 지어 넣기

지금 주력으로 쓰이는 최신 세대 모델에서는 이 세 인자를 기본값이 아닌 값으로 넣으면 요청이 거부됩니다. 문서의 안내는 명확합니다 — 요청에서 아예 빼고, 원하는 성격은 지시문으로 유도하라는 겁니다. 예전 코드를 그대로 들고 최신 모델로 갈아타면 모델 이름만 바꿨는데 전부 실패하는 상황이 이래서 생깁니다.

3. 답변 첫머리 대신 써 주기도 막혔습니다

이건 더 널리 퍼진 기법입니다. 대화의 마지막 자리를 AI 차례로 두고 시작 문구를 미리 적어 두면, 그 뒤를 이어서 씁니다. 객관식에서 답 글자 하나만 뽑고 싶을 때 "정답은 ("까지 써 두고 최대 출력을 하나로 잡는 요령이 특히 유명했죠. 여는 괄호나 여는 중괄호를 미리 넣어 형식을 강제하는 용도로도 많이 썼습니다.

⚠️ 예제를 그대로 복사하면 튕깁니다

문서에 경고 상자로 못 박혀 있습니다 — 최신 세대 모델과 미리보기 모델에서는 이 방식이 지원되지 않고, 쓰면 요청이 거부됩니다. 인터넷에 돌아다니는 예제 상당수가 아직 이 기법을 쓰고 있으니, 복사해 붙인 코드가 갑자기 안 되면 여기부터 보세요. 대안은 둘입니다 — 정해진 틀에 맞춰 답을 받는 기능을 쓰거나, 지시문에 형식을 적어 두는 것입니다. 문서도 이 둘을 안내합니다.

바꿔 말하면 "출력을 억지로 붙잡던 시대"가 끝나고 "요구를 정확히 적는 시대"로 넘어간 셈입니다. 정해진 틀로 받는 기능은 형식이 어긋날 걱정 자체를 없애 주니, 사실 예전 요령보다 안전합니다. AI로 앱을 만들 때 자주 하는 실수에 한 줄 더 보태자면 — 오래된 예제를 검증 없이 옮겨 오는 것이 요즘 가장 흔한 실수입니다.

4. 그래도 남아 있는 것 셋

첫째, 대화 도중에 새 지시를 끼워 넣는 것은 됩니다. 일부 모델군에서 지원되고, 맨 처음 자리에는 올 수 없습니다 — 처음부터 적용할 규칙은 전용 자리에 넣어야 합니다. 좋은 점은 뒤에 붙기 때문에 앞서 쌓아 둔 캐시를 깨지 않는다는 것입니다. 나중에야 필요해진 규칙에 딱 맞습니다.

둘째, 거절당했을 때 이유의 범주가 함께 옵니다. 모든 모델에서 그렇습니다. "그냥 거절됨"이 아니라 어떤 종류의 정책에 걸렸는지가 표시되니, 로그를 모아 두면 우리 서비스에서 어떤 요청이 자주 걸리는지를 데이터로 볼 수 있습니다.

셋째, 이미지를 넣는 길이 셋입니다 — 파일을 그대로 실어 보내기, 주소만 알려 주기, 미리 올려 둔 파일을 번호로 가리키기. 지원 형식은 흔한 네 가지고요. 같은 이미지를 여러 번 쓸 거라면 올려 두고 번호로 가리키는 쪽이 가볍습니다. 문서에 근거를 달아 답하게 만드는 구조라면 출처를 자동으로 붙이는 방식을 같이 보세요.

5. 자주 묻는 질문 (FAQ)

Q. 온도를 못 쓰면 답이 매번 달라지는 건 어떻게 잡나요?

요구를 좁히는 쪽으로 해결합니다. 출력 형식을 정해 두고, 판단 기준을 지시문에 적고, 예시 답변을 대화에 심는 세 가지를 쓰면 흔들림이 크게 줄어듭니다. 완전히 똑같은 답을 보장받아야 한다면 같은 질문의 결과를 저장해 두고 재사용하는 편이 확실합니다.

Q. 예전 모델을 계속 쓰면 되지 않나요?

당장은 됩니다. 다만 막힌 기능은 되살아나지 않습니다. 새 모델이 나올수록 격차가 벌어지니, 코드를 고치는 시점을 미룰수록 한 번에 고칠 양만 늘어납니다. 지금 옮겨 두는 편이 쌉니다.

Q. 답변을 지어 넣는 게 속이는 건 아닌가요?

기능으로 공식 지원되는 방식이고, 문서가 직접 소개합니다. 원리상 매번 전체 기록을 새로 보내는 구조라 "이전에 실제로 있었던 일"이라는 개념 자체가 없습니다. 다만 사용자에게 보여 줄 화면에는 이 예시가 섞이지 않게 따로 관리하세요.

Q. 갈아탈 때 뭐부터 확인하나요?

순서는 이렇습니다 — ①무작위성 인자를 요청에서 빼고 ②답변 첫머리를 미리 채우는 코드가 있는지 훑고 ③그 자리를 정해진 틀로 받는 기능으로 바꾼 뒤 ④지시문에 형식과 기준을 옮겨 적습니다. 대개 ①과 ②만으로 대부분의 오류가 사라집니다.

✨ 정리하면

오래 쓰이던 두 요령이 최신 세대에서 막혔습니다 — 무작위성 조절과 답변 첫머리 채우기입니다. 둘 다 기본값이 아니면 요청 자체가 거부되니, 갈아탈 때 이 둘부터 걷어내세요. 대신 정해진 틀로 받기와 예시 답변 심기가 그 자리를 대신합니다. AI에 드는 돈이 새는 자리를 순서대로 훑고 싶다면 AI 지출 관리 허브에 단계별로 모아 뒀습니다.

※ 2026년 9월 기준 공식 문서(메시지 사용 안내)를 바탕으로 정리했습니다. 어느 세대부터 막혔는지는 모델마다 다르니, 쓰는 모델의 안내 문서를 직접 확인하세요. FAQ의 "지금 옮겨 두는 편이 싸다"는 부분은 동작 원리에 근거한 권고입니다.