모델이 문제가 아닙니다. 당신의 라우팅(Routing)이 문제입니다.

지난 화요일, 저는 제 파이프라인(pipeline)이 왜 계속해서 데이터베이스 스키마(database schema) 세부 정보를 환각(hallucinating)하는지 디버깅하는 데 4시간을 보냈습니다. 프롬프트(prompts)를 교체하고, 예시를 추가하고, 온도(temperatures)를 변경해 보았습니다. 아무것도 효과가 없었습니다. 그러다 동일한 작업을 GPT-4o에서 Claude 3.7 Sonnet으로 옮겼더니 단 한 번에 완벽하게 수행했습니다. 이는 Claude가 더 "뛰어나서"가 아니라, 해당 특정 작업(엄격한 사실적 근거를 바탕으로 한 긴 문맥 코드 추론(long-context code reasoning))이 마침 Claude의 전문 분야(wheelhouse)에 해당하기 때문입니다. GPT-4o는 최적화되지 않은 부분에서 실패하고 있었고, 저는 프롬프트 튜닝(prompt-tuning)의 늪에 너무 깊이 빠져 있어 이를 알아차리지 못했습니다. 그 깨달음은 저에게 큰 전환점이 되었습니다. 우리는 잘못된 질문을 던지고 있었습니다. 어떤 모델이 가장 좋은가가 아닙니다. 어떤 모델이 어디에서 실패하는가 — 그리고 당신이 그 실패 지점(failure surface)을 파악하기 전에 그 실패가 당신을 덮치지는 않는가 — 가 핵심입니다.

GPT-4o: 빠르고, 유창하며, 위험할 정도로 자신만만한

GPT-4o는 항상 잘 작동하고 있는 것처럼 느껴지는 모델입니다. 응답은 빠르고, 말투는 자연스러우며, 거절하는 경우가 거의 없습니다. 하지만 바로 그 점이 모델의 실패 모드(failure modes)를 모르는 개발자들에게는 위험 요소가 됩니다.

첫 번째 균열은 **긴 문서 충실도(long-document faithfulness)**에서 나타납니다. GPT-4o에게 40페이지 분량의 법률 계약서를 요약하라고 시키면, 문장은 아름답게 읽히지만 중요한 세부 사항에서 미묘하게 틀린 결과물을 만들어냅니다. 모호함을 매끄럽게 다듬어 버립니다. 존재하지 않는 의미를 추론합니다. 원문 문서의 모순을 지적하는 대신 자신 있게 해결해 버립니다. 창의적인 작업에서는 이것이 하나의 기능(feature)이 될 수 있습니다. 하지만 기술 문서, 계약서 분석, 재무 보고와 같이 원문 자료에 대한 정확성이 핵심인 작업에서는 이는 치명적인 결함(liability)이 됩니다.

두 번째 결함은 **긴 컨텍스트에서의 지시 사항 지속성 (instruction persistence across long contexts)**입니다. GPT-4o에게 12개의 규칙이 담긴 시스템 프롬프트 (system prompt)를 주고, 8번째 턴 (turn)까지 얼마나 많은 규칙을 조용히 누락하는지 지켜보십시오. 모델은 이러한 이탈 (drift)을 공지하지 않습니다. 그저... 느슨해질 뿐입니다. 만약 GPT-4o를 사용하여 에이전트 워크플로우 (agentic workflows)를 구축하고 있다면, 정기적인 간격으로 명시적인 재고정 (re-anchoring) 작업이 필요합니다. 그렇지 않으면 에이전트가 흥미로운 작업을 수행할 즈음에는 제약 조건의 절반을 잊어버린 상태가 될 것입니다.

세 번째는 **복잡한 체인에서의 도구 사용 (tool use in complex chains)**입니다. GPT-4o의 함수 호출 (function calling)은 빠르지만, 도구를 과잉 선택하는 경향이 있습니다. 다중 도구 환경 (multi-tool environments)에서 모델은 직접적인 답변이 적절한 상황임에도 도구를 사용하려 들며, 때로는 매우 높은 확신을 가지고 잘못된 도구를 호출하기도 합니다. 실제 운영 환경에서는 사용자의 요청과 전혀 상관없는 엔드포인트 (endpoints)로 의문의 API 호출이 발생하는 것을 목격하게 될 것입니다.

Claude: 심층 추론, 취약한 포맷팅

Claude 3.7 Sonnet은 진정한 다단계 추론 (multi-step reasoning)이 필요하거나, 여러 파일에 걸친 코드 작업, 또는 논리의 흐름을 놓치지 않고 긴 체인을 유지해야 하는 분석 작업에 제가 라우팅하는 모델입니다. 제 경험상, 응답 속도보다 사고 과정의 정확성이 더 중요한 작업에서 가장 신뢰할 수 있는 모델입니다.

하지만 Claude도 고유의 실패 지점 (failure surface)을 가지고 있으며, 이는 몇 번 경험하고 나면 예측 가능합니다.

지시 사항의 압박이 가해지면 구조화된 출력 (structured output)의 신뢰도가 저하됩니다. Claude에게 JSON 형식을 요구하면서 동시에 동일한 프롬프트 내에서 어려운 추론을 수행하도록 요청하면, 모델은 추론을 우선시하느라 포맷을 소홀히 다룹니다. 마지막에 쉼표가 붙은 JSON을 받거나, 여는 중괄호 앞에 추론 텍스트 블록이 삽입되거나, Claude가 다른 이름이 더 명확하다고 "판단"하여 필드 이름을 바꿔버리는 일이 발생합니다. GPT-4o는 표면적인 준수 (surface compliance)를 더 중요하게 여기기 때문에 이 부분에서는 실제로 더 신뢰할 수 있습니다. Claude는 정답을 맞히는 것에 집중하며, 이는 때때로 사용자의 스키마 (schema)를 재작성하는 결과를 초래합니다.

Claude는 또한 사용자의 프롬프트에 대해 반박(push back)할 가능성이 가장 높습니다. 이는 버그가 아니라 설계상의 선택입니다. Anthropic은 엣지 케이스(edge-case) 요청에 대해 더 많은 저항성을 심어두었습니다. 소비자용 앱(consumer apps)의 경우 이는 아마도 올바른 방향일 것입니다. 하지만 내부 개발자 도구(internal developer tools)의 경우, 이는 지연 시간(latency)을 추가하고, 품질을 높이기 위해서가 아니라 단순히 규정 준수(compliance)를 얻어내기 위한 프롬프트 엔지니어링(prompt engineering)에 토큰을 소모하게 만듭니다. 당신은 Claude의 반박을 선제적으로 해결하는 프롬프트를 작성하는 법을 배우게 될 것이며, 이는 그 자체로 하나의 기술이 됩니다.

마지막으로: 속도입니다. 확장된 사고(Extended thinking)를 수행하는 Claude는 느립니다.

두 번째 실패 모드는 **비주류 언어 및 프레임워크를 위한 코드 생성 (code generation for non-mainstream languages and frameworks)**입니다. Python과 JavaScript의 경우 Gemini는 탄탄한 성능을 보여줍니다. 하지만 Elixir, Gleam, Zig, 혹은 잘 알려지지 않은 Go 라이브러리와 같은 니치(niche)한 분야에서는 품질이 급격히 떨어지며, Claude를 사용할 때보다 환각(hallucination)된 API 시그니처가 더 빈번하게 나타납니다. 이는 추론(reasoning)의 문제가 아니라 학습 데이터 밀도(training data density)의 문제이며, 이는 더 나은 프롬프팅(prompting)으로 해결될 수 없음을 의미합니다.

실패 표면 지도: 라우팅 체크리스트 (The Failure Surface Map: A Routing Checklist)

모델을 선택하기 전에, 귀하의 작업을 다음 항목에 대입해 보십시오:

• 소스 텍스트로부터 엄격한 사실적 근거(factual grounding)가 필요한가? → Claude. GPT-4o는 모순된 부분을 매끄럽게 뭉뚱그려 처리할 것입니다.
• 빠른 구조화된 출력(JSON, XML, 함수 인자 등)이 필요한가? → GPT-4o. Claude는 과도한 추론으로 인해 형식 이탈(format drift)이 발생합니다.
• 최신 사건을 다루거나 검색에 기반한 답변이 필요한가? → Gemini. 기본적으로 실제 근거 생성 파이프라인(grounding pipeline)을 갖춘 유일한 모델입니다.
• 100K 토큰 이상의 컨텍스트 윈도우(context window)가 필요한가? → Gemini 1.5 Pro. 비용 측면에서 이 분야의 경쟁 상대가 없습니다.
• 복잡한 다중 파일 코드 추론이 포함되는가? → Claude. GPT-4o는 파일 간의 맥락(threads)을 놓칩니다.
• 여러 턴(turn)에 걸쳐 일관된 페르소나나 톤을 유지해야 하는가? → GPT-4o 또는 Claude. Gemini는 일관성이 흐려집니다.
• 사용자 대면 서비스이며 지연 시간(latency)에 민감한가? → GPT-4o 또는 Gemini Flash. 사고(thinking) 기능이 포함된 Claude Sonnet은 동기식 UX(synchronous UX)를 구현하기에 너무 느립니다.
• 다중 도구 환경에서 신뢰할 수 있는 도구 사용(tool use)이 필요한가? → Claude. GPT-4o는 도구를 과도하게 선택(over-selects)합니다.
• 소스에 대한 정확도가 결정적이지 않은 창의적 또는 생성적 작업인가? → 어떤 모델이든 상관없지만, GPT-4o가 가장 빠릅니다.

이것은 순위 매기기가 아닙니다. 라우팅 지도(routing map)입니다. 귀하가 사용하는 모델은 지난주에 읽은 벤치마크 트윗이 아니라, 무엇을 만들고 있는지에 따라 바뀌어야 합니다.

AI Handler가 이 문제에 접근하는 방식

AI Handler를 구축하면서 저는 위의 모든 사항을 실행 가능한 상태로 만들어야만 했습니다. 핵심적인 통찰은 단일 모델 파이프라인(single-model pipelines)이 함정이라는 점입니다. 모델의 약점을 보완하기 위해 프롬프트(prompt)를 과도하게 설계(over-engineering)하거나, 다른 모델이라면 완벽히 해냈을 작업에서 낮은 품질을 수용하게 되기 때문입니다.

AI Handler는 작업 분류(task classification)를 기반으로 작업을 적절한 모델로 라우팅(routing)합니다. 워크플로(workflow) 단계를 정의할 때, 여러분은 단순히 모델을 선택하는 것이 아니라 해당 단계가 수행해야 할 작업, 즉 정답 충실도(ground truth fidelity), 출력 구조(output structure), 지연 시간 예산(latency budget), 컨텍스트 크기(context size)를 기술하는 것입니다. 라우터(router)가 모델 선택을 처리하며, 단계가 실패할 경우 재시도(retry) 시 이를 재평가합니다. 이는 여러분의 파이프라인이 중요한 지점에서는 Claude의 추론(reasoning) 능력을, 속도와 형식 준수(format compliance)가 중요한 지점에서는 GPT-4o의 능력을, 그리고 대규모 작업 시에는 Gemini의 컨텍스트 창(context window)을 활용할 수 있음을 의미합니다.

AI Handler가 수행하는 두 번째 작업은 실패 처리(failure handling)를 정규화(normalize)하는 것입니다. 모든 모델은 서로 다른 방식으로 실패합니다. Claude는 형식이 어긋나고(format-drifts), GPT-4o는 도구 호출을 과하게 하며(over-calls tools), Gemini는 출력이 가변적입니다(output-varies). 이러한 현상을 통합(integration)별로 개별적인 예외 케이스(edge cases)로 처리하는 것은 개발자의 AI 통합 시간 중 30%를 조용히 잡아먹는 작업입니다. AI Handler는 모델별 실패 시그니처(failure signatures)를 포착하여 적절한 복구 전략을 자동으로 적용합니다. Claude의 경우 명시적인 제약 조건을 포함하여 재프롬프트(re-prompt)를 수행하고, GPT-4o의 경우 도구 모호성 해소(tool disambiguation)를 추가하며, Gemini의 경우 출력 검증(output validation)과 재시도를 추가합니다.

이것이 통합 AI 워크플로 도구가 실제로 해야 할 일입니다. 단순히 "여러 모델을 지원하는 것"이 아닙니다. 지능적으로 라우팅하고, 우아하게 실패(fail gracefully)하며, 개발자가 모델의 실패 표면(failure surface)을 머릿속에 담아두지 않도록 해야 합니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.