어떤 모델이 실제로 TypeScript를 더 잘 작성할까요? 그리고 그것이 우리가 사용하는 도구를 바꿀 만큼 중요할까요? 저는 Claude Fable 5와 GPT-4o를 동일한 TypeScript 생성 작업 세트에 실행하여 확인해 보았으며, 그 결과는 리더보드의 숫자보다 더 유용했습니다. 각 모델은 서로 다른 실패 모드(failure mode)를 가지고 있으며, 어떤 모델이 당신을 곤란하게 만들지는 당신이 무엇을 구축하고 있는지에 따라 달라집니다.

저는 AI 시스템 아키텍처 (AI systems architecture) 작업을 꽤 많이 수행하는데, 파이프라인 내부의 코드 생성(codegen)을 위해 적절한 모델을 선택하는 것은 복리로 작용하는 결정입니다. 잘못 선택하면 생성된 모든 PR(Pull Request)에 대한 리뷰 시간에 비용을 지불하게 됩니다. 다음은 테스트를 통해 실제로 검증된 내용입니다.

테스트 설정 방법 (동일 조건 비교 방법론)

저는 테스트를 최대한 공정하게 유지했습니다. 두 모델 모두 동일한 프롬프트(prompt), 동일한 채점 기준(grading rubric)을 받았으며 재시도(retry)는 허용되지 않았습니다. 채점 기준에는 세 가지 관문이 있었습니다:

1. 생성된 코드가 수정 없이 컴파일(compile)되는가.
2. tsconfig에서 strict: true 설정 하에 새로운 에러 없이 통과하는가.
3. Promise가 조용히 거부(reject)되도록 두는 대신 에러를 우아하게 처리하는가.

각 작업은 잘 정의된 현실적인 TypeScript 문제였습니다: 타입이 지정된 API 응답(typed API response) 형성하기, 상태 머신(state machine)을 위한 태그된 유니온(tagged union) 모델링하기, 그리고 적절한 에러 경계(error boundaries)를 가진 비동기(async) 함수 작성하기입니다. 저는 모든 프롬프트를 두 모델 모두에 실행하고 채점 기준에 따라 출력을 점수화했으므로, 출력의 차이는 프롬프트나 채점이 아닌 모델에 기인합니다.

TypeScript 타입 추론 (Type inference): 각 모델이 실수하는 지점

두 모델 모두 기본적인 타입 추론(type inference)에는 능숙하지만, 상황이 덜 사소해지면 서로 다른 지점에서 실수합니다.

Claude Fable 5는 제네릭 (generics) 및 유틸리티 타입 (utility types)에 대해 일반적으로 더 강력하며, 별도의 가이드 없이도 엄격 모드 (strict mode)를 통과할 수 있는 출력을 생성하는 경향이 있습니다. 반면, 깊게 중첩된 판별된 유니온 (discriminated unions)에서는 다소 어려움을 겪습니다. 유니온의 엣지 케이스 (edge case)를 간혹 놓치거나 브랜치 (branch)를 잘못 좁히는 (narrowing) 경우가 있으므로, 변체 (variants)가 두세 개 이상인 경우에는 여전히 사람이 직접 검토해야 합니다.

GPT-4o는 단순하거나 중간 단계의 추론 (inference)에서는 일관적이지만, 조건부 타입 (conditional types)이나 고도로 제네릭한 유틸리티 헬퍼 (utility helpers)와 같은 고급 패턴에서는 실패할 가능성이 더 높습니다. 다음은 두 모델 모두에게 적절한 스트레스 테스트가 될 수 있는 판별된 유니온 패턴입니다:

type RequestState<T> =
  | { status: "idle" }
  | { status: "loading" }
...

만약 모델이 해당 switch 문에서 철저함 검사 (exhaustiveness check)를 누락한다면, 마지막에 never 단언 (assertion)을 추가하지 않는 한 엄격 모드 (strict mode)가 누락된 케이스를 잡아내지 못할 것입니다. 두 모델 모두 간혹 이를 건너뛰기 때문에, 이것이 바로 제가 수동으로 확인하는 부분입니다.

에러 핸들링 패턴: 누가 더 안전한 비동기 코드를 생성하는가

이 부분은 일상적인 생성 코드에서 격차가 가장 눈에 띄는 지점입니다. Claude Fable 5는 await 호출을 try 또는 catch로 감싸는 데 더 철저하며, 에러 브랜치 (error branch)를 타입 좁히기 (narrowing) 없이 any나 unknown으로 남겨두는 대신 타입을 지정하는 경향이 있습니다. GPT-4o는 일반적인 경로에서는 괜찮지만, 특히 Promise.all 호출이나 이벤트 콜백 (event callbacks) 내부에서 핸들러 없이 거부(reject)될 수 있는 프로미스 체인 (promise chain)을 남겨둘 가능성이 더 높습니다.

제가 생성된 모든 비동기 코드에서 명시적으로 확인하는 패턴은 다음과 같습니다:

async function fetchUser(id: string): Promise<User> {
  try {
    const res = await fetch(`/api/users/${id}`);
...

사소한 부분이지만, .message에 접근하기 전에 err instanceof Error로 타입을 좁히는 (narrowing) 작업은 빠른 생성 과정에서 간과되기 쉬운 바로 그런 디테일입니다. 어떤 경우든 이를 검토해야 하지만, GPT-4o의 출력물에서 더 자주 발견될 것으로 예상됩니다.

도구 호출 (Tool calling) 및 Zod 스키마 생성 비교

Zod 스키마 검증 (validation)을 포함한 구조화된 도구 호출 (Structured tool calling)은 현재 LLM 애플리케이션의 프로덕션 표준이며, 이는 모델 자체만큼이나 모델을 연결하는 SDK가 중요한 카테고리입니다. 에이전트 파이프라인 (agentic pipelines)을 위한 모델 선택에 대해 더 자세한 그림을 보고 싶다면, 이 에이전트 AI를 위한 LLM 비교 (LLM comparison for agentic AI)에서 더 깊이 있게 다루고 있습니다.

순수 스키마 생성 (raw schema generation) 측면에서, Claude Fable 5는 기본적으로 더 엄격한 Zod 스키마를 생성하는 경향이 있으며, 선택적 필드 (optional fields)와 필수 필드 (required fields)를 더 정확하게 구분해냅니다. GPT-4o의 스키마도 사용 가능하지만, 특히 Nullable 필드 주변에서 수동으로 엄격하게 다듬는 과정이 더 자주 필요합니다.

import { z } from "zod";

const ToolInput = z.object({
...

SDK 레이어를 선택하기 전에 알아두어야 할 성능 지표(footprint)가 있습니다. Vercel AI SDK는 gzipped 기준 67.5kB인 반면, OpenAI SDK는 34.3kB이며, LangChain JS가 101.2kB로 가장 무겁습니다. 배포 대상에 따라 번들 크기 (bundle size)가 중요하다면, 이는 어떤 모델을 호출하느냐와는 별개로 고려해야 할 실제적인 트레이드오프 (tradeoff)입니다.

2026년 기준 실제 지연 시간 (latency) 및 1,000 토큰당 비용

Claude Fable 5와 GPT-4o의 모든 티어 (tier)에 대한 명확한 일대일 가격 비교 데이터는 가지고 있지 않으므로, 정확하지 않은 수치를 제시하지는 않겠습니다. 실제 수치로 말씀드릴 수 있는 것은 다음과 같습니다. 더 작은 티어의 경우, GPT-4o-mini는 입력 토큰 1M(100만) 개당 약 $0.15가 소요되는 반면, Claude Haiku는 입력 토큰 1M 개당 $0.80에 가깝습니다. 일회성 요청이 아니라 CI 파이프라인을 통해 대규모로 코드 생성 (codegen)을 실행할 때는 이 격차가 매우 중요해집니다.

어떤 모델을 선택하든 전반적인 추세는 도움이 됩니다. LLM 가격은 2025년 초와 2026년 초 사이에 약 80% 하락했으므로, 비용에 관한 논의는 2년 전과는 매우 다릅니다. 높은 볼륨의 낮은 복잡도 생성을 수행하는 비용 민감형 팀들은, 더 비싼 티어를 사용하더라도 이전보다 훨씬 유리한 위치에 있습니다.

Claude Fable 5를 선택해야 할 때와 GPT-4o를 선택해야 할 때

저는 애매한 태도를 취하는 대신 명확한 입장을 밝히겠습니다. 프로토타이핑을 하고 있거나, 비용에 민감한 대량 생성(high volume generation)을 수행 중이거나, 혹은 출력이 어차피 인간의 검토(human review)를 거칠 예정이라면 GPT-4o가 실용적인 기본값(default)입니다. mini 티어에서는 더 저렴하며 일반적인 패턴에는 충분히 훌륭합니다.

만약 검토 과정을 줄이면서 실제 프로덕션(production)에 더 가깝게 배포될 코드를 생성해야 한다면, 특히 중첩된 유니온(nested unions), 비동기 에러 경로(async error paths), 또는 API 경계에서의 Zod 스키마(Zod schemas)와 관련된 작업이라면 Claude Fable 5가 추가 비용을 지불할 가치가 있습니다. Claude Fable 5는 코드 리뷰에서 잡아내기 비용이 많이 드는 부분에서 오류를 덜 범하며, 바로 그 지점이 코드 생성(codegen) 파이프라인의 실제 비용이 발생하는 곳입니다.

어느 쪽이 보편적으로 정답인 것은 아닙니다. 생성된 코드와 프로덕션 사이에 얼마나 많은 인간의 검토가 위치하는지에 따라 모델을 맞추십시오.

FAQ

TypeScript를 위해 Claude가 GPT-4보다 나은가요?
엄격 모드(strict mode) 준수와 더 안전한 비동기 에러 처리(async error handling) 측면에서, 이번 테스트에서는 Claude Fable 5가 앞서 나옵니다. GPT-4o는 일반적인 패턴에서 근소한 차이를 보이며 mini 티어에서 더 저렴하므로, 더 나은 선택은 귀하의 검토 프로세스와 예산에 달려 있습니다.

어떤 LLM이 가장 좋은 TypeScript 코드를 작성하나요?
이번 비교에서는 Claude Fable 5가 판별 가능한 유니온(discriminated unions), 비동기 에러 처리(async error handling), 그리고 Zod 스키마 생성에서 더 신뢰할 수 있는 출력을 생성했습니다. GPT-4o는 더 단순한 생성 작업에 대해 견고하고 저렴한 옵션입니다.

개발자 입장에서 Claude Fable 5는 GPT-4o와 어떻게 비교되나요?
Claude Fable 5는 복잡한 타입 패턴(type patterns)과 에러 처리에서 수동 정리(manual cleanup)가 덜 필요하며, 이는 생성과 프로덕션 사이에 인간의 검토가 적게 개입될 때 중요합니다. GPT-4o는 프로토타이핑과 더 단순한 코드 생성(codegen) 작업을 위한 강력하고 예산 친화적인 옵션으로 남아 있습니다.

프로덕션 파이프라인을 위한 모델 선택에 대해 더 깊이 있게 알고 싶다면, 제 사이트에서 더 자세히 다루고 있습니다.

이 기능을 귀하의 사이트에 엔드 투 엔드(end to end)로 구축하고 싶다면, 바로 제가 수행하는 작업의 종류입니다.

여러분의 설정이 이와 다르다면 댓글을 남겨주세요 — 사람들이 실제 운영 환경(production)에서 어떤 변형된 방식을 사용하고 있는지 궁금합니다.