작년 말 팀에서 “AI 어시스턴트 하나로 통일하자”는 이야기가 나왔다. 그때까지 나는 Claude, GPT-4o, Gemini를 그때그때 기분에 따라 바꿔가며 쓰고 있었는데 — 솔직히 그게 효율적이지 않다는 건 나도 알았다. 맥락이 분산되고, API 비용도 중복으로 나갔다. 그래서 2주 동안 제대로 비교해보기로 했다. 우리 팀은 4명이고, 주요 작업은 Next.js 기반 SaaS 제품 개발, 주간 기술 문서 작성, 그리고 가끔 데이터 파이프라인 디버깅이다.
결론부터 말하면 — 세 모델 모두 2년 전과 비교하면 충분히 쓸 만하다. 문제는 “어느 것이 더 좋냐”가 아니라 “어떤 작업에 어떤 모델이 더 덜 실망스러우냐”다.
코드 작업: Claude가 아직 한 발 앞서 있다
TypeScript로 복잡한 제네릭 타입을 다루는 유틸리티 함수를 짜야 했다. 같은 프롬프트를 세 모델에 넣어봤다.
// 프롬프트: "재귀적으로 중첩된 객체에서 특정 키의 타입을 추출하는 유틸리티 타입 만들어줘"
// Claude가 생성한 코드 (실제로 첫 시도에 컴파일 통과)
type DeepExtract<T, K extends string> = T extends object
? K extends keyof T
? T[K]
: { [P in keyof T]: DeepExtract<T[P], K> }[keyof T]
: never;
// 사용 예시
type Config = {
database: {
host: string;
port: number;
credentials: {
password: string;
};
};
};
type PasswordType = DeepExtract<Config, "password">; // string
GPT-4o는 비슷한 결과를 냈는데, 엣지 케이스를 하나 빠뜨렸다. 배열이 중간에 끼면 타입 추론이 깨지는 상황인데, 내가 지적하자 고쳐줬다. Claude는 첫 답변에서 그 케이스까지 커버했다. 작은 차이처럼 보이지만, 이런 게 하루에 수십 번 반복되면 체감 차이가 생긴다.
Gemini 2.0은 여기서 솔직히 실망스러웠다. 코드 자체는 맞는데, 주석 설명이 너무 장황하고 가끔 TypeScript 공식 문서에 없는 패턴을 “이렇게 하면 됩니다”라고 자신 있게 제시한다. 한 번은 존재하지 않는 infer 키워드 용법을 설명해줘서 20분 허비했다. (나중에 알고 보니 Gemini가 만들어낸 문법이었다.)
코드 리뷰 작업에서는 세 모델 모두 쓸 만하다. 다만 Claude는 “왜 이 패턴이 문제인지”를 더 명확하게 설명한다. GPT-4o는 수정 방안을 여러 개 제시하는데, 그게 오히려 결정 피로를 준다. 하나만 추천해줘라고 후속 프롬프트를 써야 한다.
문서 작업과 한국어 품질: 생각보다 차이가 크다
기술 문서를 한국어로 작성할 때 — 이게 의외로 중요한 차별점이었다.
Claude는 한국어 기술 문서를 쓸 때 자연스러운 개발자 말투를 유지한다. “해당 함수를 호출하여 결과값을 반환받습니다” 같은 어색한 번역투가 아니라, 실제 개발자가 쓸 것 같은 문장이 나온다.
GPT-4o는 한국어 품질이 나쁘지 않은데, 영어 문서를 번역한 느낌이 가끔 든다. 문장 구조 자체가 영어 순서를 따르는 경우가 있다. 영어로 프롬프트를 넣고 한국어 답변을 요청하면 더 심해진다.
Gemini 2.0은 한국어에서 제일 아쉬웠다. 구글이 한국 시장에 진심인 건 알지만, 기술 문서 특유의 뉘앙스를 잘 못 잡는다. 특히 “개발자스러운” 표현 — 예를 들어 “빌드가 터졌다”, “타입이 안 맞는다” 같은 자연스러운 구어체와 공식 문서 사이 어딘가의 톤 — 이걸 Gemini는 매번 너무 격식 있게 바꿔버렸다.
비용 현실: API 청구서를 보고 나서야 깨달은 것
내가 처음에 놓쳤던 부분이 바로 이거다. 성능 비교에 집중하다 보니 실제 운영 비용을 제대로 안 따졌다.
우리 팀 기준으로 2주간 API 사용량을 추적했더니:
- Claude Sonnet: 컨텍스트가 길수록 비용 효율이 올라갔다. 코드베이스 전체를 컨텍스트로 넣고 작업하는 경우에 특히. 200K 토큰 컨텍스트 윈도우를 실제로 활용하면 반복 프롬프트가 줄어든다.
- GPT-4o: 단발성 쿼리가 많으면 가성비가 좋다. 짧고 명확한 질문-답변 패턴에서 비용 대비 만족도가 높았다.
- Gemini 2.0 Flash: 가격만 보면 압도적으로 싸다. 근데 정확도 문제로 재시도 횟수가 늘어나면 그 이점이 상쇄된다.
One thing I noticed: 비용 계산할 때 “토큰당 가격”만 보면 안 된다. 같은 작업을 완료하는 데 몇 번 왕복하느냐가 실제 비용에 더 큰 영향을 미친다.
긴 컨텍스트 작업과 데이터 분석: Gemini의 역습
Gemini 2.0이 진짜 빛나는 영역이 있다. 긴 문서를 분석하거나, 대용량 로그 파일에서 패턴을 찾거나, 스프레드시트 데이터를 해석하는 작업이다.
한 번은 500페이지짜리 API 명세서(영어)를 넣고 특정 동작 패턴을 추출해달라고 했는데, Gemini가 제일 정확하게 처리했다. Claude도 나쁘지 않았지만, Gemini는 문서 전체 구조를 먼저 파악하고 답하는 느낌이 있었다. GPT-4o는 컨텍스트 관리가 가끔 불안정했다 — 앞서 언급한 내용을 뒤에서 잊어버리는 경우가 있었다.
그리고 구글 스프레드시트, BigQuery 연동은 Gemini가 당연히 훨씬 자연스럽다. 우리 팀이 데이터 분석 작업을 많이 한다면 선택이 달라졌을 거다. 100%.
# 실제로 쓴 데이터 파이프라인 디버깅 프롬프트 예시
# Gemini에게 넣었을 때 제일 유용했던 케이스
"""
아래 BigQuery 쿼리가 예상보다 10배 느린 이유를 분석해줘.
실행 계획(EXPLAIN)은 다음과 같아:
[실행 계획 붙여넣기]
테이블 스키마:
[스키마 붙여넣기]
파티셔닝 설정:
[설정 붙여넣기]
"""
# Gemini는 이런 상황에서 쿼리 최적화 제안이 구체적이었다
# 파티션 프루닝 누락 문제를 바로 잡아냈다
내가 실제로 쓰는 세팅, 그리고 팀에 추천한 것
2주 테스트 후 우리 팀이 정착한 방식을 공유한다. “상황에 따라 다르다”는 답 말고, 진짜 권장 사항으로.
Claude를 메인으로 쓴다. 이유는 단순하다 — 코드 작업과 한국어 기술 문서가 우리 주요 업무인데, 이 두 가지에서 Claude가 일관되게 낫다. 특히 긴 대화 맥락을 유지하면서 코드 리팩토링을 해나갈 때, Claude는 앞에서 합의한 설계 결정을 끝까지 기억한다. GPT-4o는 이 부분에서 중간에 흐트러지는 경우가 있었다.
GPT-4o는 서브로 남겨뒀다. 주로 빠른 원샷 질문이나, OpenAI 에코시스템을 써야 하는 클라이언트 프로젝트 작업에. 그리고 솔직히 말하면 — Claude가 특정 라이브러리에 대해 모른다고 할 때 두 번째 의견으로 묻는 용도.
Gemini는 데이터 쪽 동료가 주로 쓴다. BigQuery 작업이 많은 팀원한테는 Gemini가 확실히 더 생산적이었다. 나는 개인적으로 잘 안 쓰게 됐는데, 이건 내 업무 특성 때문이지 Gemini가 나쁜 게 아니다.
한 가지 주의할 점 — 모델 버전 업데이트를 주시해야 한다. 내가 테스트하던 중간에 Claude API 동작이 미묘하게 바뀐 적이 있었다. 완전히 다른 건 아닌데, 특정 프롬프트 패턴에 대한 응답 길이가 달라졌다. 이런 변화가 자동화된 파이프라인에 끼치는 영향을 과소평가하지 말자. 나는 100% 확신이 없지만, 프로덕션에서 LLM 출력을 파싱하는 코드는 반드시 버전 고정과 회귀 테스트가 필요하다고 생각한다.
지금 당장 세 모델 중 하나만 골라야 한다면? Claude Sonnet이다. 2026년 3월 기준, 코드 품질, 한국어 처리, 긴 대화 일관성 — 이 세 가지를 동시에 가장 잘 처리한다. 다만 BigQuery나 구글 생태계가 업무 중심이라면 Gemini 2.0 조합을 진지하게 고려해볼 만하다.