모든 최전선 LLM을 기반으로 팀을 만드는 곳에는 늘 비슷한 종류의 회의가 있다. 누군가 최신 benchmark leaderboard를 공유한다. 다른 사람이 지난달 이후 순위가 바뀌었다고 지적한다. 세 번째 사람은 팀이 현재 쓰는 모델이 세 주 전까진 들어본 적도 없는 어떤 지표에서 두 계단 내려갔다고 말한다. 회의가 끝날 때쯤이면, 누구도 마이그레이션해야 할지 확신하지 못한 채, 다음 분기에 다시 논의하기로 잡아둔다.
그 회의의 문제는 사람들에게 있지 않다. 벤치마크는 합성 작업을 측정하고, 당신의 제품은 합성 작업이 아니다. 리더보드는 모델이 MMLU, SWE-bench Verified, GPQA Diamond에서 어떻게 수행하는지를 알려준다 — 연구자들이 모델 간 비교가 가능하도록 설계한 테스트들이다. 그 어떤 테스트도 실제 프로덕션에서 당신의 애플리케이션이 보내는 프롬프트처럼 보이지 않는다. 그 어떤 테스트도 사용자가 만들어내는, 특정 도메인 모양의 지저분한 입력을 모델이 어떻게 다루는지를 포착하지 못한다.
이 글은 벤치마크가 할 수 없는 바로 그 연습을 따라간다. 동일한 OpenAI 호환 엔드포인트로, 동일한 temperature 설정, 추가 프롬프트 없이 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는 전반적으로 고른 사실을 숨길 수 있다. 집계는 당신이 결정을 내리는 데 필요한 정보를 압축해 없애버린다.
아래 연습은 벤치마크가 집계 과정에서 지워버리는 바로 그 정보를 드러내도록 설계됐다. 목적은 우승자를 선언하는 것이 아니라 — 당신이 자신의 프롬프트로 같은 연습을 할 때 어떤 질문을 해야 하는지를 보여주는 것이다.
설정
대부분의 프로덕션 워크로드에 대응되는 카테고리에 매핑되는 세 가지 프롬프트. 설정: 각 프롬프트를 세 모델 모두에게 동일한 매개변수(temperature 0.3, 시스템 프롬프트 오버라이드 없음, 기본 응답 형식)로 전송한다. 단일 OpenAI 호환 엔드포인트를 통해 접근하여 비교를 동일 조건으로 유지한다 — 제공자별 SDK 특성 없음, 매개변수 매핑 차이 없음, 요청 구성 방식에 따라 특정 모델이 특혜를 받는 위험 없음.
프롬프트 자체는 아래 코드 블록에 있어 복사해 바로 실행할 수 있다. 각 프롬프트 뒤의 행동 설명은, 이런 비교를 수행하는 팀들이 일관되게 보고한 패턴들 — 당신이 자신의 환경에서 이 프롬프트들을 돌릴 때 기대할 법한 것들이다. 직접 실행해보는 것이 핵심이다; 이 글은 그 프레임워크와 시작 프롬프트를 제공한다.
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 기능의 절반은 이 Bread-and-butter 작업이다. 비정형 입력 — 이메일, 지원 티켓, 회의 기록, 스캔한 양식 — 을 받아 특정 필드를 구조화된 객체로 추출한다. 아래 프롬프트는 의도적으로 지저분한 고객 지원 이메일에서 일곱 개 필드를 추출하도록 요청한다. 부분 정보, 상충 신호, 그리고 원문에 존재하지 않는 필드 하나(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 밖에 추가 설명을 붙여서, 다운스트림 파싱 시 래퍼를 제거해야 하는 상황을 만드는지. urgency 필드도 주목할 만하다: “5일”은 즉각은 아니지만 고객은 분명히 초조해한다. 해석의 여지가 있다.
일관되게 보고되는 관찰
GPT-5.5. 보통 첫 시도에서 깔끔한 JSON을 낸다. 스키마 준수가 강하며, 요청된 필드는 모두 존재하고, 전처리 없이 파싱 가능한 형식이다. 누락된 필드에는 명시적으로 null을 반환하는 경향이 있다. JSON을 마크다운 코드 펜스로 감싸거나 산문 설명을 덧붙이지 않는 편이라 다운스트림 파싱이 수월하다. 이처럼 모호한 해석이 필요한 경우(여기서는 긴급도) GPT-5.5는 다른 두 모델보다 보수적으로 판단하는 편이다 — 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. 셋 중 가장 절제된 출력을 내는 경향이 있다. 요청된 필드만, 추가 필드 없음, 주변 설명 없음. 스키마 준수가 정확하다. 알아둘 만한 단 한 가지 특징: 누락된 필드에는 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는 암묵적 제약(이탈 정의, 대조군, 교란 변수)에 대한 가정을 열거한 뒤 단계를 제시해, 의도와 다른 해석이 있는지 쉽게 식별할 수 있다. 단계 의존성은 신뢰할 만하게 식별·표시한다. 요청하지 않았더라도 병렬화 가능한 단계 섹션이 포함되는 경우가 많아 실질적 가치를 더한다. 도구 사용과 에이전트형 학습이 드러나는 과제다 — 내려오는 실행을 전제한 계획 행동이 나타난다.
Claude Sonnet 4.6. 말 그대로 가장 “사려 깊은” 계획을 내는 편이다 — Claude의 계획은 다른 두 모델이 거론하지 않는 고려사항을 포함하는 경우가 잦다. 이런 질문에서 Claude는 상관과 인과의 방법론적 문제를 지적하고, “feature X를 사용하지 않음”이 원인이 아니라 이탈의 증상일 수 있음을 짚으며, 명시하지 않은 제약까지 신중하게 표면화한다. 단점: 계획이 필요 이상으로 길어질 수 있고, 개별 단계가 실제 질문에 비해 과도하게 설계되는 경우가 있다. 다른 영역에서의 Claude와 일관된 패턴 — 전문가 수준의 배려, 때로는 과업이 요구하는 것 이상.
Gemini 3.1 Pro. 구조가 가장 깔끔한 계획을 내는 경향이 있다. 의존성 그래프가 가장 명료하다. 추론 품질은 높다 — Gemini는 암묵적 제약을 안정적으로 식별하고, 문제를 방어 가능한 순서로 분해하며, 실제로 실행 가능한 단계별 지침을 만든다. 단점: 계획이 다소 기계적으로 읽히기도 한다. 일을 해내지만, Claude가 강조하는 방법론적 미묘함이나, GPT-5.5가 포함하는 병렬화 인사이트는 잘 드러나지 않는다. 더 넓은 Gemini의 패턴과도 맞아떨어진다 — 추론 품질은 강하고, 주변 판단은 보다 실용적이다.
이것이 말해 주는 것
이 과제에서의 추론 품질은 세 모델 모두 높다. 차이는 주변 행동 — 문자 그대로의 요청을 넘어 모델이 무엇을 더하느냐에 있다. GPT-5.5는 운영적 실용성을 더한다(병렬화, 실행 힌트). Claude는 전문가 수준의 배려를 더한다(방법론, 엣지 케이스, 통계적 뉘앙스). Gemini는 명료성과 절제를 더한다. 어느 것도 틀린 선택이 아니다. 당신의 애플리케이션이 과제를 마친 뒤 모델이 무엇을 하길 바라느냐에 따라 선택이 달라진다.
프롬프트 3: 특정 제약을 둔 코드 생성
이 프롬프트는 작지만 비사소한 기능을 구현하게 한다: 타임스탬프 이벤트 목록을 받아 연속 이벤트 간 가장 긴 간격을(초 단위로) 반환하는 Python 함수. 네 가지 엣지 케이스를 처리해야 한다. 제약을 명시적으로 부여했으며, 역량의 상한을 가늠하려는 것이 아니다 — 모든 모델이 이 함수를 작성할 수 있다. 달라지는 것은 제약을 어떻게 다루느냐다.
프롬프트
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을 포함하기도 한다). 예시 호출이 담긴 도크스트링이 붙는 편이다. 구현은 대체로 당연한 알고리즘(정렬, 선형 스캔, 최대 간격 추적)을 택하며 정확하다. 알아둘 점: 프롬프트가 함수만 달라고 명시했더라도, GPT-5.5는 유닛 테스트나 사용 예를 포함하는 경우가 잦다. 운영 실용성을 중시하는 모델의 트레이드오프 — 당신이 필요할 것 같다고 판단한 것을, 말리지 않는 한 덧붙인다.
Claude Sonnet 4.6. 가장 읽기 쉬운 코드를 내는 경향이 있다. 함수는 간결하고, 상단의 가드 절로 엣지 케이스를 깔끔하게 처리하며, 타입 힌트는 정확하고 최소화되어 있다. 프롬프트가 열어둔 판단에 대해 사려 깊은 주석을 덧붙이는 경우가 있다 — 예컨대 중복 타임스탬프를 길이 0 간격으로 처리하는 것이 타당하다는 설명처럼, 프롬프트가 명시하지 않은 판단이지만 방어 가능한 선택. “테스트 금지” 제약을 GPT-5.5보다 더 잘 지키는 편이다. 함수 자체는 셋 중 가장 유지보수하기 좋다. 코드 품질에서의 Claude의 평판과 일관된다: 깔끔하고, 관용적이며, 전문가의 감각이 느껴진다.
Gemini 3.1 Pro. 셋 중 가장 절제된 코드를 내놓는 경향이 있다. 함수는 정확하고, 엣지 케이스는 처리되며, 구현은 가장 짧다. 도크스트링은 보통 한 줄. 타입 힌트는 존재하며 정확하다. Gemini의 해법은 테스트나 장황한 주석을 거의 포함하지 않고, 과도한 설계를 하지 않는다 — 프롬프트가 정확히 요구한 바다. 동반 작업까지 모델이 해주길 바라는 개발자에게는 다른 두 모델이(요청하지 않았더라도) 더 많은 것을 덧붙여준다. 그게 아니라 작동하는 함수를 받고 테스트는 따로 추가하려는 개발자에게는 가장 직행하는 경로다.
이것이 말해 주는 것
세 모델 모두 함수를 작성한다. 행동상의 차이는, 문자 그대로의 요청을 넘어 각 모델이 주변 작업을 얼마나 덧붙이느냐 — 그리고 명시적 “X를 추가하지 말라”는 지시를 얼마나 엄격히 따르느냐에 있다. GPT-5.5는 철저함 쪽으로 기운다, 비록 프롬프트가 철저함을 면제했더라도. Claude는 공예적 감각 쪽으로 기운다(가독성 높은 코드, 판단에 대한 사려 깊은 주석). Gemini는 절제 쪽으로 기운다(요구한 것만 정확히, 그 이상은 없음). 모델 출력이 곧바로 프로덕션 코드베이스로 이어지는 에이전틱 워크플로에서, 원하는 행동은 다운스트림 리뷰 프로세스가 기대하는 바 — 그리고 부정 지시를 얼마나 엄격히 따를 필요가 있는지 — 에 달려 있다.
드러나는 패턴
위 세 프롬프트 전반에서, 2026년 내내 발표된 비교 연구와 개발자 보고서에서 일관된 세 가지 행동 패턴이 드러난다. 이는 역량 주장(capability claim)이 아니다 — 모든 모델이 모든 과제를 높은 수준에서 다룬다. 이는 경향성이다. 같은 모델이 수십 개 프롬프트를 처리하는 모습을 지켜볼 때만 보이는 것들이다. 위 프롬프트들을 자신의 환경에서 실행해보면 같은 패턴을 보게 될 것이다; 이 글은 그것을 인지하는 프레임워크와 시작 프롬프트를 제공한다.
| 모델 | 행동 경향 | 이런 경우에 적합… |
|---|---|---|
| GPT-5.5 | 운영적 실용주의. 실행 힌트, 방어적 코딩, 다운스트림 친화적 출력 추가. 에이전트·도구 사용에 의해 형성된 과제에서 강함. | 애플리케이션이 모델 출력을 후속 실행으로 연쇄하는 경우 — 에이전트, 워크플로, 다음 단계가 자동화된 파이프라인. |
| Claude Sonnet 4.6 | 전문가 수준의 배려. 문자 그대로의 요청을 넘어 고려사항을 표면화, 윤리와 방법론 문제 제기, 가독성 높은 코드 생성. | 애플리케이션에 사람이 모델 출력을 리뷰하는 경우 — 콘텐츠 생성, 코드 리뷰, 공예적 완성도가 중요한 분석. |
| Gemini 3.1 Pro | 절제되고 직설적. 요청한 것만 정확히 수행. 동등한 작업 대비 가장 깔끔한 스키마 준수와 최소 토큰 출력. | 출력 요구사항이 엄격하고, 비용 예측 가능성이 중요하거나, 모델이 사려 깊은 협업자라기보다 정밀한 도구이길 바라는 경우. |
중요한 단서. 이 패턴은 경향이지 규칙이 아니다. 적절한 프롬프트로는 어떤 모델이든 원하는 행동으로 유도할 수 있다 — 충분히 상세한 시스템 프롬프트로 Gemini에 테스트를 추가하게 하거나, Claude를 최소 출력으로 제약하거나, GPT-5.5가 유닛 테스트를 생략하도록 만들 수 있다. 요점은 기본 동작이 무엇이냐이다 — 스티어링 이전, 기본값. 프로덕션에서는 적극적으로 프롬프트로 거스르지 않는 한 기본 동작과 함께 살게 된다.
자신의 워크로드에서 테스트하는 방법
위 연습은 어떤 워크로드에도 복제 가능하며, 그렇게 해야 한다. 벤치마크 점수는 첫 필터로 유용하지만, 당신의 특정 애플리케이션에 중요한 모델 행동 패턴은 당신의 특정 프롬프트를 처리하는 모습을 봐야만 보인다.
실제 트래픽에서 연습을 수행하는 실용 가이드:
- 대표적인 프롬프트 카테고리 세 가지를 고른다. 임의의 세 프롬프트가 아니다 — 워크로드를 아우르는 세 카테고리다. 대부분의 프로덕션 시스템은 소수의 프롬프트 유형(추출, 분류, 생성, 추론, 코드, 요약)으로 분해할 수 있다. 트래픽의 대부분을 차지하는 카테고리를 고른다.
- 카테고리별로 20–30개 예시를 큐레이션한다. 가능하면 실제 트래픽에서. 필요 시 익명화. 프롬프트가 실제 애플리케이션이 보는 것과 같아야 한다는 점이 핵심이지, 벤치마크 문제처럼 보여선 안 된다. 카테고리당 20개면 패턴이 보이기 시작하고, 30개면 충분히 확신할 수 있다.
- 단일 엔드포인트로, 모든 모델에 돌린다. OpenAI 호환 집계 엔드포인트를 쓰면 각 모델의 SDK로 따로 돌리는 것보다 훨씬 빠르다. 이 글 상단의 코드가 전부다. 동일한 temperature, 동일한 매개변수, 동일한 프롬프트 — 출력의 차이는 모델의 차이다.
- 정량화에 앞서 정성 평가를 한다. 먼저 눈으로 출력물을 확인한다. 행동 패턴은 보통 첫 열댓 개 프롬프트 내에 명백해진다. 각 모델이 워크로드에서 어떻게 행동하는지에 대한 가설이 생기면, 그때 루브릭을 만들어 채점한다 — 하지만 가설은 관찰에서 나오지, 미리 만든 채점 템플릿에서 나오지 않는다.
- 모델이 “무엇을 더하는지”에 주목한다. 벤치마크의 질문은 모델이 정답을 맞히느냐이다. 행동의 질문은 그 외에 모델이 무엇을 하느냐다. 테스트를 추가하는가? 추론을 설명하는가? 우려를 제기하는가? 요청하지 않은 필드를 생성하는가? 모델 차이는 여기에 산다.
- 다운스트림 패턴에 맞는 모델을 고른다. 다운스트림 프로세스가 자동화되어 있다면, 기본 동작이 깨끗하고 파싱 가능한 출력을 내는 모델이 필요하다. 다운스트림 프로세스가 휴먼 리뷰라면, 기본 동작이 사람이 보고 싶어 할 주변 판단을 더하는 모델이 필요하다. 정답은 모델 다음에 무엇이 오느냐에 달려 있다.
결론
GPT-5.5, Claude Sonnet 4.6, Gemini 3.1 Pro 중 무엇이 “최고”인지가 핵심이 아니다. 당신의 워크로드의 모양에 어떤 모델이 맞느냐다 — 그 모양은 벤치마크가 볼 수 없다. 큐레이션된 프롬프트만 있다면 위 연습은 한 오후면 복제할 수 있다; 직접 해보는 가치는, 추측을 멈추고 관찰을 시작한다는 데 있다.
연습을 직접 돌리는 팀을 위해: 가장 쉬운 설정은 세 모델 모두를 하나의 자격 증명 뒤에서 노출하는 단일 OpenAI 호환 엔드포인트다. CometAPI는 한 가지 경로다; 기존 OpenAI SDK의 base URL만 바꾸면 모델 파라미터만 변수가 된다. 동반 글인 ‘2026 LLM API 가격 비교’는 같은 결정의 비용 측면을 다룬다 — 두 글을 함께 보면, 올바른 선택에 필요한 행동적·재무적 그림을 모두 얻게 된다.
벤치마크는 모델이 무엇을 할 수 있는지를 알려준다. 행동 패턴은 모델이 당신의 프롬프트에서 기본적으로 무엇을 할지를 알려준다. 첫 번째 답은 공개되어 있다. 두 번째 답은 직접 관찰해야 한다. 카테고리당 20개 프롬프트, 한 오후면, 그 어떤 리더보드도 주지 못하는 답을 얻게 된다.
신뢰성 있게 통합할 준비가 되었는가? 원활한 Claude Fable 5 액세스와 다른 최전선 모델을 하나로 묶은 결제, 엔터프라이즈급 신뢰성을 위해 CometAPI와 API 문서를 확인하라. 지금 가입하면 신규 사용자에게 넉넉한 크레딧이 제공된다 — 당신의 다음 돌파 프로젝트가 기다린다.