GPT-5 vs Claude 4 Sonnet 코딩 비교: Cursor CLI와 모델 선택 기준

여러분, 2025년 8월 OpenAI가 GPT-5를 출시하면서 개발자들이 가장 궁금해하는 질문은 명확합니다. “이제 Claude 4 Sonnet을 대체할 수 있을까?”죠. 그런데 코딩 성능, 프론트엔드 UI 품질, 대규모 리팩토링, 비용, IDE 통합까지 함께 보면 단순 벤치마크만으로는 답하기 어렵습니다.

결론부터 말하면, GPT-5, Claude 4 Sonnet, Claude Opus를 같은 프로젝트와 비슷한 프롬프트로 비교했을 때 한 모델이 모든 상황에서 이긴다는 식은 아닙니다. GPT-5는 큰 컨텍스트와 비용 효율에서 매력이 있고, Claude 4 Sonnet은 일상적인 개발과 프론트엔드 결과물에서 여전히 강하게 느껴집니다. 여기에 Cursor CLI 베타까지 함께 보면, 도구 성숙도도 모델 선택만큼 중요하다는 걸 알 수 있습니다.

GPT-5와 Claude 4 Sonnet 비교 요약

• GPT-5는 OpenAI가 가장 강력한 코딩 모델로 내세운 모델이며, 복잡한 프론트엔드 생성과 대규모 저장소 디버깅 개선을 강조했습니다.
• 단일 프롬프트 데모만으로 모델 성능을 판단하기는 어렵습니다.
• LMArena 웹 개발 리더보드에서는 GPT-5가 높은 점수를 기록했습니다.
• 동일한 프로젝트 관리 보드 구현 실험에서 GPT-5는 기능은 만들었지만 UI와 일부 필터 동작에서 아쉬움이 있었습니다.
• Claude 4 Sonnet은 더 자연스러운 UI와 안정적인 필터 동작을 보여줬습니다.
• GPT-5는 더 큰 컨텍스트 윈도우와 상대적으로 낮은 API 비용 때문에 대규모 백엔드 작업이나 리팩토링에 매력적입니다.
• Cursor CLI는 터미널 기반 코딩 에이전트로 등장했지만, 2025년 8월 기준 베타라 기능 제약이 많았습니다.

GPT-5 코딩 성능을 어떻게 봐야 할까

원샷 데모는 출발점일 뿐이다

OpenAI는 GPT-5로 단 하나의 프롬프트만으로 게임, 픽셀 아트, 드럼 시뮬레이터 같은 결과물을 만들 수 있다고 내세웠습니다. 그래서 저도 같은 류의 원샷 프롬프트를 GPT-5와 Claude Sonnet으로 직접 돌려봤습니다. 결과만 놓고 보면, 이렇게 HTML 파일 하나로 끝나는 간단한 결과물은 Claude Sonnet도 충분히 잘 만들어줍니다.

실제로 GPT-5에 드럼 시뮬레이터 류의 프롬프트를 그대로 넣으니 index.html 하나가 만들어졌고, 실행도 잘 됐습니다. 같은 프롬프트를 Claude Sonnet 4의 Max 모드에 넣어도 비트 메이커가 문제없이 만들어졌죠. 두 결과 모두 한 번에 동작했기 때문에, 이 정도 데모로는 두 모델의 차이를 가늠하기 어려웠습니다. 게임이나 픽셀 아트 역시 구조가 단순한 단일 파일 결과물이라는 점에서 마찬가지라고 봅니다.

이 지점이 중요합니다. 데모는 모델의 가능성을 보여주지만, 실무 성능을 그대로 대표하지는 않죠. 개발자라면 “한 번에 예쁜 데모를 만들었는가”보다, 요구사항이 많아졌을 때 얼마나 잘 유지하는지, 오류를 얼마나 잘 고치는지, 기존 코드베이스 안에 얼마나 잘 맞춰 넣는지를 봐야 합니다.

사용자 평가 기반 벤치마크도 참고하되 맹신하지 않는다

LMArena 웹 개발 모드를 잠깐 짚어보죠. 사용자가 같은 프롬프트를 두 모델에 보내고, 결과물을 블라인드로 비교해 더 나은 쪽에 투표하는 방식입니다. 예를 들어 “프로젝트 관리 보드를 만들어줘”라고 요청하면 두 LLM 에이전트가 각각 실제 코드를 생성하고, 그 코드로 만들어진 서비스를 직접 조작해 볼 수 있습니다. 처음에는 어떤 모델인지 가려져 있다가, 더 잘 동작하는 쪽에 투표하면 그제야 모델 이름이 공개됩니다. 2025년 8월 기준으로는 GPT-5가 웹 개발 영역에서 1479점으로 1등을 기록했습니다.

이런 벤치마크는 전통적인 정답형 테스트보다 실제 사용자 경험에 가깝다는 장점이 있습니다. 그래도 모든 개발 환경을 대표하지는 못해요. 프롬프트 유형, 프로젝트 구조, 라이브러리, IDE 통합, 사용자 선호에 따라 결과가 달라지니까요. 그래서 저는 점수만 믿기보다 직접 써보는 쪽을 택했습니다.

같은 프로젝트로 비교해 본 결과

프로젝트 관리 보드 구현 실험

GPT-5, Claude 4 Sonnet, Claude Opus(정확히는 Claude Opus 4.1)에 같은 프로젝트 환경과 유사한 원샷 프롬프트를 주고 프로젝트 관리 칸반 보드를 만들게 했습니다. Next.js 프로젝트를 초기화하고, Tailwind CSS와 shadcn/ui 같은 스타일링 도구를 쓰는 조건으로 통일했죠. 세 모델 모두 Cursor의 Max 모드로 실행해 조건을 최대한 맞췄습니다.

요구사항에는 백로그, 투두, 진행 중, 리뷰, 완료 같은 컬럼, 카드 생성, 드래그 이동, WIP 제한, 필터, 캘린더 뷰, 간트 차트 등이 들어갑니다. 단순 화면이 아니라 여러 기능이 함께 있는 작은 앱이죠.

GPT-5 결과: 기능은 만들지만 UI와 세부 동작은 아쉬움

GPT-5로 만든 프로젝트는 칸반 보드, 카드 생성, 드래그 이동, WIP 제한, 캘린더 뷰, 간트 차트 같은 주요 기능을 잘 구현했습니다. 그런데 검색 필터가 정상적으로 동작하지 않았어요. UI도 별도의 세부 지시가 없으면 비교적 단순하게 나오는 편이었습니다.

이건 GPT-5가 못 쓴다는 뜻이 아닙니다. 기능 구현 자체는 충분히 강력하죠. 다만 프론트엔드 결과물의 사용성이나 미감, 디테일은 프롬프트에서 더 구체적으로 요구해야 한다는 의미입니다.

Claude 4 Sonnet과 Opus 결과: 프론트엔드 체감 품질이 좋다

Claude 4 Sonnet으로 만든 결과물은 UI가 더 화려하고 자연스러웠고, 카드 이동과 필터 기능도 잘 동작했습니다. Claude Opus도 비슷한 수준의 UI와 기능을 보여줬고, 검색, 캘린더, 간트 차트 같은 기능이 무리 없이 돌아갔습니다.

제 실험 기준으로는, 일상적인 코딩 작업과 프론트엔드 개발에서는 아직 Claude 4 Sonnet이 더 편했습니다. 특히 특별한 스타일 지시가 없어도 UI를 어느 정도 알아서 다듬어주는 점이 좋았어요.

요구사항별 결과 비교

세 모델의 결과를 요구사항 기준으로 정리하면 이렇습니다.

요구사항	GPT-5	Claude 4 Sonnet	Claude Opus 4.1
5개 컬럼 생성	정상	정상	정상
카드 생성·수정	정상	정상	정상
드래그로 카드 이동	정상	정상, 더 자연스러움	정상
WIP 제한 경고	정상	도달·초과 경고 모두 표시	정상
검색·라벨 필터	동작하지 않음	정상	정상
캘린더 뷰·간트 차트	정상	정상	정상
UI 완성도	단순한 편	화려하고 자연스러움	Sonnet과 비슷한 수준

표로 보면 차이가 선명하죠. 기능 목록 자체는 세 모델 모두 대부분 채웠습니다. 갈린 건 필터 같은 세부 동작과, 따로 지시하지 않았을 때의 UI 완성도였습니다. 이 프로젝트 말고 다른 프로젝트에서도 써봤는데, 프론트엔드 쪽은 전반적으로 비슷한 경향이었습니다.

GPT-5가 더 잘 맞는 작업

큰 컨텍스트가 필요한 작업

GPT-5는 Claude Sonnet보다 컨텍스트 윈도우가 약 두 배 큽니다. 큰 컨텍스트는 대규모 리팩토링, 복잡한 백엔드 분석, 여러 파일을 함께 읽어야 하는 디버깅에서 유리하죠.

실무에서는 작은 프론트엔드 컴포넌트보다 오래된 백엔드 코드, 넓은 도메인 모델, 여러 계층의 호출 흐름을 한 번에 봐야 하는 작업이 많습니다. 이럴 때 모델이 더 많은 맥락을 유지할 수 있다는 점은 큰 장점이 됩니다.

API 비용 효율

API 비용 측면에서도 GPT-5가 매력적입니다. 입력 비용을 비교해보면 Claude Sonnet보다 약 2.5배 저렴하고, Claude Opus 4.1과 비교하면 거의 12배까지 차이가 납니다. 정확한 비용은 시점에 따라 달라지지만, 핵심은 GPT-5가 성능 대비 비용 면에서 보조 모델로 쓰기 좋다는 점이에요.

비용은 개인 개발자보다 팀과 회사에서 더 크게 와닿습니다. 에이전트가 긴 컨텍스트를 반복해서 읽고, 여러 번 시도하고, 테스트 로그까지 넣는 환경에서는 토큰 비용이 정말 빠르게 늘어나거든요. 그래서 모델 선택은 성능과 비용을 같이 봐야 합니다.

Cursor CLI 첫인상

터미널 기반 Cursor 에이전트

이번 비교에는 Cursor CLI도 넣어봤습니다. Cursor CLI는 Claude Code처럼 터미널에서 동작하는 코딩 에이전트입니다. 2025년 8월 기준 Cursor IDE에서 Claude Code로 넘어가는 개발자가 많아졌는데, 그래서 Cursor도 터미널 기반 에이전트를 내놓기 시작한 흐름이죠.

설치 후 터미널에서 Cursor CLI를 실행하면 MCP 연동이나 AGENTS.md 규칙 파일을 활용할 수 있습니다. IDE 안의 채팅만이 아니라 CLI 기반 작업 흐름으로 Cursor를 확장하려는 방향인 거죠. 설치 명령 한 줄로 설치한 뒤, Claude Code처럼 터미널에서 대화하며 코드를 수정하게 하는 방식입니다. 프로젝트 루트에 AGENTS.md를 만들어 두면 Cursor CLI가 그 규칙을 참고해서 동작합니다.

베타 기능의 제약

다만 2025년 8월 기준 Cursor CLI는 베타라 제약이 많았습니다. 제가 얼리버드로 며칠 써봤는데, Claude Code에 있는 hooks, custom slash command, subagents 같은 기능을 Cursor CLI에서는 아직 쓰기 어려웠어요. 이 부분이 가장 아쉬웠습니다.

그래서 저는 Cursor CLI를 메인 도구로 쓰기보다, Cursor IDE와 Claude Code를 함께 쓰는 방식을 택했습니다. 에이전트 성격이 강한 개발은 Claude Code로, 코드 에디터 안에서의 작업은 Cursor로 나눠 쓰는 식이죠.

벤치마크와 체감이 다른 이유

커뮤니티 반응

흥미로운 건 벤치마크 결과와 달리, 커뮤니티에서는 GPT-5 성능이 기대만큼 좋지 않다는 의견이 꽤 많았다는 점입니다. 특히 Cursor와의 통합이 아직 덜 되어 있어서 Cursor에서 쓸 때 성능이 떨어진다는 이야기가 많았고, Cursor 포럼에도 비슷한 글이 올라왔습니다.

반대로 큰 컨텍스트 덕분에 대규모 리팩토링, 버그 수정, 복잡한 백엔드 작업에서는 GPT-5가 제 역할을 한다는 의견도 많았습니다. 제가 며칠 써본 경험도 여기에 가깝습니다.

새 모델에는 최적화 기간이 필요하다

사실 이건 GPT-5만의 문제는 아닙니다. 다른 LLM도 Cursor에 처음 들어왔을 때는 Cursor 에이전트와의 통합이 덜 되어 있어서 성능이 떨어지는 걸 체감할 수 있었죠. 그래서 제가 말하고 싶은 건, 출시 직후의 IDE 체감만으로 모델을 최종 판단하지 말자는 겁니다. Cursor 쪽에서 모델에 맞춘 최적화가 이뤄질 때까지는 조금 기다려 보면서, 작업 유형별로 나눠 써보는 게 현실적이라고 봅니다.

넓어지는 코딩 에이전트 선택지

LLM 모델은 계속 새로 나오고, 모델 비용도 점점 낮아지는 추세입니다. 도구 쪽도 마찬가지입니다. Cursor CLI, Claude Code, Gemini CLI처럼 개발자가 쓸 수 있는 터미널 기반 코딩 에이전트가 빠르게 늘고 있죠. 개발자 입장에서는 선택의 폭이 넓어진 만큼, 모델과 도구를 하나로 고정하기보다 작업에 맞게 조합하는 감각이 더 중요해졌습니다.

모델 선택 기준

작업 유형	더 잘 맞는 선택
프론트엔드 UI 초안	Claude 4 Sonnet 우선 검토
대규모 백엔드 리팩토링	GPT-5 보조 활용
긴 컨텍스트 분석	GPT-5 강점 확인
일상적인 IDE 작업	Cursor + Claude 모델 조합
터미널 기반 에이전트	Claude Code가 더 성숙한 선택
비용 민감한 반복 작업	GPT-5 API 비용 구조 검토

마무리

결론부터 말하면, GPT-5는 분명 강력한 코딩 모델입니다. 큰 컨텍스트, 비용 효율, 백엔드와 대규모 작업에서의 가능성은 충분히 매력적이죠. 그래도 제 실험에서는 프론트엔드 UI 품질과 일상적인 개발 체감에서 Claude 4 Sonnet이 여전히 더 좋은 선택이었습니다.

제가 말하고 싶은 건, 모델 선택을 대체 관계가 아니라 조합 관계로 봐야 한다는 겁니다. 저는 Claude 4 Sonnet을 메인으로 쓰되, 큰 컨텍스트가 필요하거나 비용이 중요한 작업에서 GPT-5를 보조로 함께 씁니다. Cursor CLI는 앞으로 충분히 기대할 만하지만, 2025년 8월 기준으로는 Claude Code의 성숙한 하네스 기능을 대체하기엔 아직 이른 단계라고 봅니다.