모든 최첨단 LLM 위에 제품을 만드는 팀에서 반드시 열리는 회의가 있다. 누군가 최신 벤치마크 리더보드를 공유한다. 다른 누군가는 지난달과 비교해 순위가 바뀌었다고 지적한다. 세 번째 사람은 자신들의 팀이 현재 사용 중인 모델이 3주 전엔 들어본 적도 없는 어떤 지표에서 두 계단 내려갔다고 말한다. 회의가 끝날 때쯤, 누구도 마이그레이션을 해야 할지 확신하지 못하고, 대화는 다음 분기 일정으로 다시 잡힌다.
그 회의의 문제는 사람들에 있지 않다. 문제는 벤치마크가 합성 과제를 측정한다는 점이고, 당신의 제품은 합성 과제가 아니라는 점이다. 리더보드는 모델이 MMLU, SWE-bench Verified, GPQA Diamond에서 어떻게 수행하는지를 알려준다 — 연구자들이 모델 간 비교가 가능하도록 만든 테스트들이다. 그 어떤 테스트도 실제 운영 환경에서 당신의 애플리케이션이 보내는 프롬프트처럼 생기지 않는다. 그 어떤 테스트도 사용자가 만들어내는, 특정 도메인 모양의 지저분한 입력을 모델이 어떻게 다루는지를 포착하지 못한다.
이 글은 벤치마크가 할 수 없는 바로 그 연습을 정확히 밟아간다. 동일한 OpenAI 호환 엔드포인트를 통해, 동일한 온도 설정과 추가 프롬프트 없이, GPT-5.5, Claude Sonnet 4.6, Gemini 3.1 Pro에 보내도록 설계된 세 가지 구체적 프롬프트. 프롬프트는 대부분의 운영 워크로드를 건드리는 세 범주를 아우른다: 지저분한 문서에서의 구조화 추출, 추론이 많은 계획 과제, 그리고 제약 하의 코드 생성. 아래의 관찰은 이런 비교를 수행하는 팀들이 일관되게 보고하는 행동 패턴들 — 즉, 당신이 직접 이 프롬프트들을 자신의 설정에서 실행하면 보게 될 것들이다.
리더보드에서는 이 세 모델이 SWE-bench Verified에서 서로 0.8%포인트 이내로 점수가 붙어 있다. 실제로는 매우 다르게 동작한다. 셋 중 무엇을 고를지는 벤치마크에서 누가 최고 점수를 받았느냐가 아니라 — 어떤 행동 패턴이 당신의 워크로드에 맞느냐에 관한 문제다.
벤치마크가 측정하는 것과 놓치는 것
벤치마크는 필요해서 존재한다. 모델 제공자는 역량을 주장하기 위해 표준화된 테스트가 필요하고, 연구자는 비교를 발표하기 위해 필요하며, 우리 모두는 모델을 평가할 객관적 출발점을 갖기 위해 필요하다. 유용하다. 또한 운영에서 중요한 방식으로 불완전하다.
아래 프롬프트 예시에서 각각 드러나는 세 가지 한계를 명시하는 것이 좋다.
- 벤치마크는 고립된 능력을 측정하지, 행동 패턴을 측정하지 않는다. SWE-bench Verified는 모델이 특정 유형의 GitHub 이슈를 해결할 수 있는지 알려준다. 모델이 단순한 문제를 과도하게 설계하는 경향이 있는지, 프롬프트가 모호할 때 명확화 질문을 던지는지, 처음에 요청한 구조와 맞는 출력을 내는지 등은 알려주지 않는다. 이게 당신이 운영에서 매일 관찰하게 될 것들이다.
- 벤치마크는 튜닝된다. 모델 릴리스가 특정 벤치마크 점수를 눈에 띄게 내세운다면, 그 모델이 적어도 부분적으로 해당 벤치마크에 맞춰 최적화되었다는 신호다. 실제 성능과 벤치마크 성능은 — 때로 상당히 — 벤치마크가 설계된 조건을 벗어나면 분기할 수 있다.
- 벤치마크는 집계한다. SWE-bench Verified에서 0.8%포인트 차이는, 모델 A가 특정 범주에서는 훨씬 우수하고 다른 범주에서는 더 약한 반면 모델 B는 전반적으로 일관된 사실을 숨길 수 있다. 집계는 의사결정에 필요한 정보를 접어버린다.
아래 연습은 벤치마크가 집계해 버리는 바로 그 정보를 드러내도록 설계되었다. 목적은 승자를 선언하는 것이 아니라 — 당신이 자신의 프롬프트로 같은 연습을 수행할 때 어떤 질문을 던져야 하는지 보여주는 것이다.
설정
대부분의 운영 워크로드가 맞닥뜨리는 범주와 매핑되도록 선택한 세 가지 프롬프트. 설정: 모든 프롬프트를 동일한 매개변수(온도 0.3, 시스템 프롬프트 오버라이드 없음, 기본 응답 형식)로 세 모델에 전송, 비교는 사과 대 사과로 유지 — 제공자별 SDK 특이점 없음, 다른 매개변수 매핑 없음, 요청 구성 방식 때문에 특정 모델이 특혜를 받는 위험 없음.
프롬프트 자체는 아래에, 복사해 실행할 수 있는 코드 블록으로 제공한다. 각 프롬프트 뒤에 이어지는 행동 설명은 이 종류의 비교를 실행할 때 팀들이 일관되게 보고하는 패턴들 — 2026년의 다수 서드파티 연구에 문서화되어 있고, 당신이 자신의 설정에서 이 프롬프트들을 실행할 때 기대해야 할 것이다. 직접 실행하는 것이 핵심이다; 이 글은 그 프레임워크와 시작 프롬프트를 제공하기 위해 존재한다.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
프롬프트 1: 지저분한 문서에서의 구조화 추출
2026년에 출시된 LLM 기능의 절반은 이 과제가 주력이다. 비구조화 입력 — 이메일, 지원 티켓, 회의록, 스캔된 양식 — 을 받아 특정 필드를 구조화된 객체로 추출한다. 아래 프롬프트는 일부 정보, 상충되는 신호, 원문에는 존재하지 않는 필드 하나(escalation_history)를 포함한 의도적으로 지저분한 고객 지원 이메일에서 일곱 개 필드를 추출하도록 각 모델에 요청한다.
프롬프트
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
주의할 점
세 가지. 첫째, 모델이 요청된 JSON 스키마를 발명 없이 준수하는지. 둘째, 원문에 존재하지 않는 필드를 모델이 어떻게 처리하는지(escalation_history — 고객은 이 특정 이슈에 대한 사전 연락을 언급하지 않는다) — 부재를 인정하는지, 그럴듯하게 날조하는지. 셋째, 모델이 JSON 외에 추가 설명을 곁들여 출력해, 후속 파싱에서 래퍼를 제거해야 하게 만드는지. 또한 긴급도 필드도 주목할 만하다: “5일”은 즉각은 아니지만 고객은 분명 불안해하고 있어 해석의 여지가 있다.
팀들이 일관되게 보고하는 것
GPT-5.5. 대개 첫 시도에서 깔끔한 JSON을 생성한다. 스키마 준수가 강하다; 요청된 모든 필드가 존재하고, 전처리 없이 파싱 가능한 형식이다. 누락된 필드에 대해 GPT-5.5는 명시적 null을 반환하는 경향이 있다. JSON을 마크다운 코드 펜스에 감싸거나 산문형 설명을 포함하지 않는 편이라 후속 파싱이 매우 쉽다. 이 프롬프트의 긴급도처럼 모호한 해석적 판단에서는 다른 두 모델보다 더 보수적인 경향이 있다 — Claude와 Gemini가 고객의 감정적 톤을 근거로 티켓을 “high”로 평가할 수 있는 상황에서, GPT-5.5는 구체적 5일 기한에 앵커링되어 “medium”에 머무르는 경우가 많다.
Claude Sonnet 4.6. 역시 깔끔한 JSON을 생성하며, 요청된 스키마를 가장 정밀하게 따르는 편이다. GPT-5.5가 누락 필드를 null로 남기는 곳에서, Claude는 요청되지 않은 필드를 추가해 데이터 품질 이슈를 표시하는 경우가 많다 — 요청하지 않았지만 실제로 유용한 정보를 담은 “notes”나 “data_quality_notes” 키를 넣는다. 그 추가 필드는 인간 리뷰어에게 유용하지만, 후속 파서가 스키마에 엄격하다면 실패를 야기한다. Claude의 반복되는 패턴이다: 고품질이지만, 때때로 프롬프트가 요구한 것보다 더 철저해, 이를 억제하려면 명시적 프롬프트 제약이 필요하다.
Gemini 3.1 Pro. 셋 중 가장 절약적인 출력을 내는 편이다. 요청된 모든 필드, 추가 필드 없음, 주변 산문 없음. 스키마 준수는 요청한 그대로다. 알아둘 만한 한 가지 특이점: 누락된 필드에 대해 Gemini는 null 대신 빈 문자열을 반환하는 경향이 있다. 이를 구분하는 엄격한 JSON 파서는 차이를 잡아내고; 느슨한 파서는 못 잡는다. 동작이 실행 간 일관적이어서 모델의 선호로 보이며 우연한 아티팩트는 아닌 듯하다.
시사점
세 모델 모두 구조화 추출을 수행할 수 있다. 차이는 요청된 스키마 주변의 행동 여백에 있다. 후속 시스템이 스키마에 엄격하고 추가 필드를 오류로 취급한다면, Gemini 3.1 Pro와 GPT-5.5가 더 안전한 선택이다. 모델이 요청하지 않아도 데이터 품질 이슈를 표면화하길 원한다면, Claude Sonnet 4.6이 더 도움이 된다. 벤치마크에는 나타나지 않는 차이다.
프롬프트 2: 추론이 많은 계획 과제
이 프롬프트는 다단계 조사 계획을 요청한다: 세 가지 암묵적 제약을 신중한 모델이라면 실행 순서화 전에 식별해야 하는 연구 질문. 에이전트형 애플리케이션이 도구 호출 전 계획 단계로 LLM에 위임할 법한 종류의 과제다.
프롬프트
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
주의할 암묵적 제약: 질문은 “이탈(churn)”의 정의를 규정하지 않는다(계정 해지? 로그인 없음? 구매 없음?), 교란 변수 통제를 어떻게 할지 명시하지 않는다(저관여 사용자는 feature X와 무관한 이유로도 이탈한다), 기준 비교 그룹을 확립하지 않는다. 신중한 기획자는 계획 단계 전에 이 셋을 모두 표면화해야 한다.
주의할 점
모델이 실제로 문제를 추론해 가는지, 겉보기 그럴듯하지만 따져보면 뒷받침되지 않는 단계 시퀀스를 생성하는지. 암묵적 제약을 알려주지 않아도 식별하는지. 그리고 단계 간 의존성이 올바른지 — 얼핏 괜찮아 보이나 3단계가 5단계 결과에 의존하는 식이면 실무에선 쓸 수 없다.
팀들이 일관되게 보고하는 것
GPT-5.5. 운영적으로 가장 사용 가능한 계획을 산출하는 경향이 있다. 추론이 눈에 보인다 — GPT-5.5는 암묵적 제약(이탈 정의, 대조군, 교란 변수)에 대한 자신의 가정들을 단계 나열 전에 열거해, 의도가 다를 경우 어디서 해석이 어긋났는지 쉽게 확인할 수 있게 한다. 단계 의존성은 신뢰성 있게 식별·표기된다. 출력은 종종 병렬화 가능한 단계 섹션을 포함하는데, 요청하지 않았지만 실제로 가치를 더한다. 이런 과제에서 GPT-5.5의 도구 사용·에이전트형 훈련이 드러난다 — 계획 행동이 후속 실행이 뒤따를 것이라는 가정에 의해 형성되어 있다.
Claude Sonnet 4.6. 문자 그대로 가장 “사려 깊은” 계획을 내는 편이다 — Claude의 계획에는 다른 두 모델이 언급하지 않는 고려사항이 포함되는 경우가 많다. 이런 질문에서 Claude는 상관과 인과의 방법론적 이슈를 지적하고, “feature X를 최근 30일간 사용하지 않았다”가 원인이 아니라 이탈의 증상일 수 있음을 언급하며, 명시되지 않았지만 신중한 분석가라면 식별해야 할 제약들을 명확히 적시한다. 단점: 계획이 필요 이상으로 길어질 수 있고, 개별 단계가 실제 질문에 비해 과설계되는 경우가 있다. 다른 곳에서도 일관된 Claude의 행동 — 전문가 수준의 배려, 때로 과제 요구를 넘어선다.
Gemini 3.1 Pro. 가장 깔끔하게 구조화된 계획을 내는 편이며, 의존성 그래프가 가장 명확하다. 추론 품질은 높다 — 암묵적 제약을 신뢰성 있게 식별하고, 문제를 방어 가능한 시퀀스로 분해하며, 실제로 실행 가능한 단계별 지침을 생성한다. 아쉬운 점: 계획이 다소 기계적으로 읽힐 수 있다. 일을 해내지만 Claude가 제시하는 방법론적 미묘함이나 GPT-5.5가 포함하는 병렬화 인사이트는 덜 드러난다. Gemini의 더 넓은 패턴과 부합 — 추론 품질은 강하지만, 주변 판단은 보다 실무적이다.
시사점
이 과제에서의 추론 품질은 세 모델 모두 높다. 차이는 요청의 글자 너머 모델이 무엇을 더하는지라는 주변 행동에 있다. GPT-5.5는 운영적 실용성(병렬화, 실행 힌트)을 추가한다. Claude는 전문가 수준의 배려(방법론, 에지 케이스, 통계적 뉘앙스)를 더한다. Gemini는 명료성과 경제성을 더한다. 셋 중 어느 것도 틀린 선택이 아니다. 당신의 애플리케이션에 맞는 것은 모델이 과제를 끝낸 뒤 기본적으로 무엇을 하길 원하는지에 달려 있다.
프롬프트 3: 특정 제약을 가진 코드 생성
이 프롬프트는 작지만 비사소한 함수를 구현하도록 요청한다: 타임스탬프가 있는 이벤트 목록을 받아 연속 이벤트 간 가장 긴 간격을(초 단위로) 반환하는 파이썬 함수, 네 가지 에지 케이스를 처리한다. 제약은 명시적이다; 역량 상한을 시험하기보다 제약 하 코드 생성이 의도다 — 모든 모델이 이 함수를 작성할 수 있다. 달라지는 것은 제약을 어떻게 다루느냐이다.
프롬프트
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
주의할 점
모델이 네 가지 에지 케이스를 모두 다루는지, 일부를 조용히 누락하는지. 타입 힌트가 정밀한지, 상투적인지. 구현이 방어 가능한 알고리즘(정렬 후 선형 스캔)을 선택하는지, 괴상한 것을 택하는지. 그리고 프롬프트 끝의 “테스트·사용 예시는 제외”라는 제약을 모델이 존중하는지 — 프롬프트 말미의 이런 지시는 지시 준수 성능이 강한 모델은 잘 지키고, 약한 모델은 조용히 위반하는 경우가 있다.
팀들이 일관되게 보고하는 것
GPT-5.5. 가장 철저하게 엔지니어링된 코드를 산출하는 경우가 많다. 네 가지 에지 케이스를 명시적 분기들로 처리하고, 타입 힌트가 정밀(종종 에지 케이스 반환값에 Optional이나 Union을 포함)하며, 예시 호출이 담긴 독스트링을 포함한다. 구현은 대개 자명한 알고리즘 — 정렬, 스캔, 최대 간격 추적 — 을 선택하며 정확하다. 알아둘 점: 프롬프트가 명시적으로 함수만 요청해도 단위 테스트나 사용 예시를 포함하는 경우가 잦다. 운영 실용성에 기운 모델의 트레이드오프 — 요청하지 않았더라도 필요할 것이라 생각되는 것들을 추가한다.
Claude Sonnet 4.6. 가장 읽기 쉬운 코드를 산출한다. 함수는 간결하고, 에지 케이스를 상단의 깔끔한 가드 절 패턴으로 처리하며, 타입 힌트는 정확하고 최소하다. 프롬프트가 남긴 판단을 설명하는 사려 깊은 코멘트를 포함하는 경우가 많다 — 예컨대 중복 타임스탬프를 길이 0의 간격으로 처리하고, 그 이유를 설명하는 식으로. Claude는 “테스트 제외” 제약을 GPT-5.5보다 더 신뢰성 있게 준수하는 경향이 있다. 함수 자체는 셋 중 가장 유지보수하기 쉽다. 코드 품질에서의 Claude의 평판과 일치: 깔끔하고, 관용적이며, 전문가의 감각.
Gemini 3.1 Pro. 셋 중 가장 절약적인 코드를 산출한다. 함수는 정확하고, 에지 케이스를 처리하며, 구현은 가장 짧다. 독스트링은 대개 한 줄. 타입 힌트는 존재하며 정확하다. Gemini의 해법은 테스트나 장문의 주석을 드물게 포함하고, 과설계하지 않는다 — 프롬프트가 정확히 요청한 바다. 작동하는 함수를 원하고 테스트는 따로 추가할 개발자에게 가장 직행이다. 주변 작업까지 모델이 해주길 원한다면, 다른 두 모델이 더 많이 추가한다(요청했든 아니든).
시사점
세 모델 모두 함수를 작성할 수 있다. 행동상의 차이는 요청의 글자 너머 각 모델이 얼마나 주변 작업을 더하느냐 — 그리고 “X를 추가하지 말라”는 명시적 부정 지시를 얼마나 잘 지키느냐에 있다. GPT-5.5는 철저함 쪽으로 치우친다, 프롬프트가 철저함을 면제했을 때조차. Claude는 공예(읽기 쉬운 코드, 판단에 대한 사려 깊은 주석) 쪽으로 치우친다. Gemini는 경제성(요청한 것만, 그 이상 없음) 쪽으로 치우친다. 모델의 출력이 곧바로 운영 코드베이스에 들어가는 에이전트형 워크플로에서는, 원하는 행동은 후속 리뷰 프로세스가 무엇을 기대하는지 — 그리고 부정 지시를 얼마나 엄격히 따라야 하는지 — 에 달려 있다.
드러나는 패턴들
위 세 프롬프트 전반에서, 2026년 내내 발표된 비교 연구와 개발자 보고에서 일관되게 드러나는 세 가지 행동 패턴이 나타난다. 역량 주장과는 다르다 — 모든 모델이 모든 과제를 높은 수준으로 처리한다. 이것들은 성향이다, 동일한 모델이 수십 개 프롬프트를 처리하는 모습을 팀들이 지켜볼 때만 보이는 종류. 위 프롬프트들을 자신의 설정에서 실행해 보면 같은 패턴을 보게 될 것이다; 이 글은 직접 실행할 때 무엇을 보고 있는지 인지할 프레임워크를 제공하기 위해 존재한다.
| 모델 | 행동 경향 | 이런 경우에 적합… |
|---|---|---|
| GPT-5.5 | 운영 실용적. 실행 힌트, 방어적 코딩, 후속 친화적 출력을 추가. 에이전트형·도구 사용이 반영된 과제에서 강함. | 애플리케이션이 모델 출력을 추가 실행에 바로 연결 — 에이전트, 워크플로, 자동화된 파이프라인 등에서 다음 단계가 자동화되는 경우. |
| Claude Sonnet 4.6 | 전문가 수준의 배려. 요청의 글자 너머 고려사항을 표면화, 윤리·방법론 이슈를 제기, 매우 읽기 쉬운 코드 생성. | 모델 출력에 사람이 리뷰를 수행 — 콘텐츠 생성, 코드 리뷰, 공예가 중요한 분석 등에서. |
| Gemini 3.1 Pro | 경제적이고 직접적. 요청한 것만 수행, 그 이상 없음. 동일 작업 대비 가장 깔끔한 스키마 준수와 최저 토큰 출력. | 출력 요구사항이 엄격하고, 비용 예측 가능성이 우선이며, 모델을 사려 깊은 협력자라기보다 정밀한 도구로 쓰고자 하는 경우. |
중요한 주의사항. 이 패턴들은 성향이지 규칙이 아니다. 적절한 프롬프트로 어느 모델이든 어느 행동으로 조향할 수 있다 — 충분히 상세한 시스템 프롬프트로 Gemini가 테스트를 추가하도록 만들거나, Claude를 최소 출력으로 제약하거나, GPT-5.5가 단위 테스트를 생략하도록 할 수 있다. 요점은 각 모델이 기본적으로, 조향하기 전에 무엇을 하는지다. 기본 동작은, 적극적으로 프롬프트로 반대 방향을 잡지 않는 이상, 운영에서 당신이 매일 마주하는 것이다.
자신의 워크로드에서 테스트하는 법
위 연습은 어떤 워크로드에든 복제 가능하며, 그래야 한다. 벤치마크 점수는 첫 필터로 유용하지만, 당신의 특정 애플리케이션에 중요한 모델 행동 패턴은 해당 모델이 당신의 특정 프롬프트를 처리하는 모습을 지켜볼 때만 보인다.
자신의 트래픽에서 연습을 실행하는 실무 가이드:
- 대표 프롬프트 범주 세 가지를 고르라. 임의의 프롬프트 세 개가 아니라 — 당신의 워크로드를 가로지르는 세 범주. 대부분의 운영 시스템은 소수의 프롬프트 유형(추출, 분류, 생성, 추론, 코드, 요약)으로 분해 가능하다. 트래픽의 대부분을 차지하는 범주를 고르라.
- 범주당 20–30개의 예시를 큐레이션하라. 가능하면 실제 트래픽에서. 필요 시 익명화. 핵심은 프롬프트가 실제 애플리케이션이 보는 것처럼 생겨야지, 벤치마크 질문처럼 생기면 안 된다는 점이다. 범주당 20개면 패턴을 보기 충분하고; 30개면 확신할 수 있다.
- 하나의 엔드포인트로, 모든 모델을 통과시켜라. OpenAI 호환 집계 엔드포인트는 각 모델을 자체 SDK로 돌리는 것보다 훨씬 빠르게 만든다. 이 글 맨 위의 코드가 전체 설정이다. 같은 온도, 같은 매개변수, 같은 프롬프트 — 출력의 차이가 곧 모델의 차이다.
- 정량화 이전에 정성 평가를 하라. 먼저 눈으로 출력들을 보라. 행동 패턴은 대개 첫 수십 개 프롬프트 안에서 분명하다. 각 모델이 당신의 워크로드에서 어떻게 행동하는지에 대한 가설을 갖게 되면, 그제서야 그것을 기준으로 채점 루브릭을 구성하라 — 하지만 가설은 관찰에서 오지, 미리 만든 채점 템플릿에서 오지 않는다.
- 모델이 무엇을 “더하는지”에 주목하라. 벤치마크의 질문은 모델이 정답을 맞히는가이다. 행동의 질문은 모델이 그 밖에 무엇을 하는가이다. 테스트를 추가하는가? 추론을 설명하는가? 우려를 제기하는가? 요청하지 않은 추가 필드를 생성하는가? 모델 차이는 이 지점에 있다.
- 당신의 후속 패턴에 맞는 모델을 선택하라. 후속 프로세스가 자동화라면, 기본 동작이 깔끔하고 파싱 가능한 출력을 내는 모델이 필요하다. 후속 프로세스가 사람 리뷰라면, 기본 동작이 사람이 보고 싶어할 주변 판단을 추가하는 모델이 필요하다. 정답은 모델 뒤에 무엇이 오는지에 달려 있다.
결론
GPT-5.5, Claude Sonnet 4.6, Gemini 3.1 Pro 중 무엇을 고를지는 모델이 “누가 최고인가”의 문제가 아니다. 당신의 워크로드 모양과 맞는 모델이 무엇인가의 문제다 — 그 모양은 벤치마크가 볼 수 없다. 위 연습은 프롬프트만 큐레이션되어 있다면 오후 한나절이면 복제 가능하다; 실제로 실행하는 가치란, 추측을 멈추고 관찰을 시작하는 데 있다.
직접 연습을 실행하는 팀을 위해: 가장 쉬운 설정은 하나의 OpenAI 호환 엔드포인트로 세 모델 모두를 하나의 자격증명 뒤에 노출하는 것이다. CometAPI는 한 경로다; 기존 OpenAI SDK의 base URL만 바꾸면, 모델 매개변수만 변수가 된다.
벤치마크는 모델이 “무엇을 할 수 있는지”를 알려준다. 행동 패턴은 모델이 “당신의 프롬프트에서 기본적으로 무엇을 할 것인지”를 알려준다. 첫 번째 답은 공개되어 있다. 두 번째 답은 스스로 관찰해야 한다. 범주당 20개 프롬프트, 오후 한나절, 그리고 그 어떤 리더보드도 내지 못할 답을 얻게 된다.
신뢰성 있게 통합할 준비가 되었나요? CometAPI와 API 문서를 통해 다른 최첨단 모델과 함께 Claude Fable 5에 원활히 접근하고, 통합 청구 및 엔터프라이즈 등급의 신뢰성을 누리세요. 지금 가입해 신규 사용자에게 제공되는 넉넉한 크레딧으로 시작하세요 — 다음 돌파형 프로젝트가 당신을 기다립니다.