GLM-5 vs DeepSeek V3 vs GPT-5: 개발자를 위한 속도 및 비용 비교

안녕하세요, 저는 Dora입니다. 저를 자극한 건 아주 사소한 일이었습니다. 5분이면 끝날 요약 작업이 15분으로 늘어졌는데, 첫 번째 응답이 시작 부분에서 멈춰버렸기 때문입니다. 모델만의 잘못은 아니에요. 토큰 스트리밍, 서버 부하, 그런 것들이 있으니까요. 하지만 그 일이 “정확도”만이 하루를 망치는 유일한 요소가 아니라는 걸 다시 한번 상기시켜줬습니다.

그래서 계속 머릿속을 맴돌던 질문과 마주 앉았습니다. 실제 세계에서 GLM-5, DeepSeek, GPT-5를 사용하면 어떤 느낌일까요? 차트 속 숫자가 아니라, 응답 시간, 예상 밖의 비용이 없는 요금, 그리고 작업에 세 가지나 네 가지 요소가 얽혀 있을 때의 안정성으로 느끼는 감각 말입니다. 이 글은 그것을 차분하게, 그리고 여러분의 스택, 지역, 엣지 케이스에 대한 허용 범위에 따라 그림이 달라질 수 있다는 점을 전제로 써 내려간 시도입니다.

최대한 현실적으로 이야기하겠습니다. 과장된 홍보와 흔한 벤치마크 스크린샷을 넘어서, GLM-5 vs DeepSeek vs GPT-5를 다뤄보겠습니다.

벤치마크 점수 너머에서 비교할 것들

벤치마크는 기본 검증 수단이지, 목적지가 아닙니다. 제가 주목하는 실행들은 화려하지 않습니다.

• 중요한 순간의 지연 시간: 첫 번째 토큰까지의 시간(TTFT)과 안정적인 처리량. “더 오래 생각하는” 모델이 문제가 되는 건 아닙니다. 시작조차 하기 전에 멈춰 있는 모델이 문제인 경우가 많습니다.
• 작업 형태에 맞는 비용: 백만 토큰당 가격도 좋지만, 컨텍스트 낭비, 재시도, 도구 호출이 실제 지출을 두 배로 늘릴 수 있습니다.
• 실패 방식: 프롬프트가 약간 어긋났을 때, 도구가 타임아웃됐을 때, 입력이 평소보다 길 때 모델이 어떻게 동작하는지.
• 제어 수단: 실제로 변동 폭을 움직이는 temperature, 효력을 유지하는 시스템 프롬프트, 스키마 엣지에서 흔들리지 않는 함수 호출.
• 부하 하의 성능 저하: 1분 안에 세 번째 실행할 때, 또는 배치에서 100번째 작업일 때.

GLM-5, DeepSeek, GPT-5 전반에 걸쳐, 저는 조용한 능숙함을 찾았습니다. 엉뚱한 방식으로 저를 놀라게 하지 않는 모델들. 또한 각 모델이 어디서 구부러지는지도 메모해뒀습니다. 마케팅 약속보다 알려진 약점을 중심으로 설계하는 게 더 쉽기 때문입니다.

추론 속도 (TTFT + 처리량)

저는 두 순간에 주목합니다. 첫 번째 토큰이 나타나는 시점, 그리고 나머지가 얼마나 빠르게 이어지는지입니다.

• TTFT: 이 수치는 모델이 바로 응답을 시작하는지, 아니면 저를 멍하니 기다리게 하는지를 알려줍니다. 인터랙티브 도구(초안 작성, 고객 지원 채팅)에서 빠른 TTFT는 일종의 친절함처럼 느껴집니다.
• 처리량: 일단 시작되면, 긴 출력에서 끊김 없이 꾸준한 속도를 유지할 수 있는가?

실제로 관찰한 내용 (2026년 2월, 미국/유럽 혼합 엔드포인트):

• GLM-5: 짧은 프롬프트에서 일관되게 빠른 TTFT를 보였습니다. 긴 컨텍스트(약 30~40k 토큰 이상)에서는 시작이 약간 느렸지만 스트리밍은 꾸준했습니다. 초안 작성과 코드 편집에서 “무난하다”는 느낌을 줬습니다. 구체적인 수치와 나란히 비교한 지연 데이터가 필요하다면, GLM-5 추론 속도 벤치마크 분석이 참고하기 좋았습니다.
• DeepSeek (특히 R1/V3 변형): 가벼운 배치 부하 하에서도 놀랍도록 빠른 TTFT를 보였습니다. 매우 긴 생성에서는 스트리밍 중간에 미세한 멈춤이 가끔 있었지만, 회복은 부드러웠습니다.
• GPT-5: 일부 엔드포인트에서 예상보다 느리게 시작하지만, 이후 매우 안정적인 스트리밍으로 만회합니다. 도구 호출이 포함된 경우, 핸드오프 오버헤드가 낮아 다단계 흐름에 도움이 됩니다.

스스로에게 반복하는 주의사항: 지역과 게이트웨이가 순수 모델 성능만큼이나 중요합니다. 애그리게이터를 통해 라우팅하고 있다면, 스트리밍을 켜고 탐색적 실행에서 max_tokens를 낮춰보세요. 품질을 바꾸지 않고도 공백 시간을 줄여줍니다.

---

백만 토큰당 비용

공식 가격은 출발점이지, 최종 청구서가 아닙니다. 세 가지 요소가 예상보다 실제 비용을 더 크게 바꿨습니다.

• 컨텍스트 낭비: 매 호출마다 같은 시스템 서문과 도구 스키마를 보내는 것이 쌓입니다. 캐싱하거나 스키마를 줄이면 금방 효과를 봤습니다.
• 재시도 정책: 속도 제한에 대한 공격적인 재시도 한 번이 바쁜 시간대에 조용히 지출을 두 배로 만들 수 있습니다.
• 출력 길이 제어: max_tokens를 합리적인 상한선으로 설정하고(함수 호출 시 모델이 멈추도록 하는 것도 포함) 어떤 할인 코드보다 더 효과적이었습니다.

이달 기준:

• DeepSeek은 특히 추론 변형에서 공격적인 가격 정책을 밀고 있습니다. 배치 워크플로우에 친화적이지만, 스타일의 간헐적 편차는 주의해야 합니다.
• GLM-5는 실용적인 중간 지점에 있습니다. 가장 저렴하진 않지만, 예측 가능성이 있고, 재무팀이 예측을 요청할 때 예측 가능성은 가치가 있습니다.
• GPT-5 가격은 아직 공식적으로 유동적입니다. 실제로는 GPT-4.1/4o 가격대를 하한선으로 모델링하고 GPT-5의 추론 티어를 위한 여유분을 추가했습니다. 오늘 당장 확실한 상한선이 필요하다면, 이것을 먼저 압박 테스트해봐야 합니다.

사과 대 사과 비교를 하려면, 토큰이 아닌 “유용한 출력당 실효 비용”을 측정하세요. 1.2배 비싼 모델이 수정 횟수를 절반으로 줄인다면, 제 기준에서는 그 모델이 이기는 겁니다.

---

추론 및 코딩 품질

리더보드를 돌린 게 아닙니다. 실제로 제가 하는 작업을 돌렸습니다. 구조화된 글쓰기, 소규모 코드 유틸리티, 멀티 도구 에이전트 흐름. 두 가지 관점이 가장 중요했습니다.

단일 작업 정확도

집중적인 작업(예: “이 JSON을 타입이 지정된 인터페이스로 변환해줘”, “액션 아이템과 함께 이 회의 노트를 요약해줘”)에서 GPT-5가 가장 완성도 있게 느껴졌습니다. 좁은 형식을 따르기 위한 추가 지시가 덜 필요했고, 함수 호출도 스키마 내에서 더 안정적으로 유지됐습니다.

DeepSeek은 단계를 명시적으로 설명할 수 있는 추론에서 잘 작동했습니다. 지나치게 상세하게 설명하는 경향이 약간 있는데, 초안에는 괜찮지만 max_tokens를 제한하고 간결함을 명시하지 않으면 엄격한 출력에는 이상적이지 않습니다. GLM-5는 차분한 중간 지점에 자리했습니다. 화려함은 덜하고, 꾸준한 준수, 차이가 작을 때는 코드 편집도 탄탄합니다. 모호한 프롬프트로 콜드 스타트할 때는 제가 원하는 것보다 더 안전하게 처리하는 경향이 있었지만, 더 구체적인 시스템 프롬프트가 이를 해결해줬습니다.

다단계 에이전트 안정성

도구들이 등장하는 경우, 검색, 스크래핑, 데이터베이스 읽기, 질문은 “답이 좋은가?”에서 “루프가 살아남는가?”로 바뀝니다.

• GPT-5: 짧은 체인을 계획하고 도구가 타임아웃될 때 회복하는 데 강했습니다. 누락된 필드를 추측하는 대신 다시 요청했습니다. 작은 것이지만, 정신 건강에 큰 도움이 됩니다.
• DeepSeek: 간결하고 효율적인 체인. 두 도구가 기능이 겹칠 때 가끔 자신 있게 잘못된 방향을 선택했습니다. 시스템 프롬프트에 명시적인 도구 선택 규칙을 추가하는 것이 도움이 됐습니다.
• GLM-5: 스키마가 잘 정의돼 있을 때 매우 안정적이었습니다. 도구가 예상치 못한 형태를 반환하면, 조용히 환각을 일으키는 대신 신중하게 처리하며 명확한 설명을 요청했습니다. 저는 그런 방식을 선호합니다.

처음에는 시간이 절약되지 않았습니다. 사실, 가드레일을 연결하는 데 오후 한 나절이 더 걸렸습니다. 하지만 몇 번 실행하고 나니 정신적 노력이 줄어든다는 걸 느꼈습니다. 알 수 없는 오류가 줄었습니다. “왜 이렇게 했지?” 하는 순간이 줄었습니다.

---

워크로드 유형별 최적 모델

이건 시상식이 아닙니다. 매칭 작업입니다. 제 일주일 동안 각 모델이 가장 잘 맞았던 곳을 알려드립니다.

실시간 앱 → ?

화면 반대편에 사람이 기다리고 있다면, 저는 빠른 TTFT와 예측 가능한 스타일을 선호합니다.

• 가벼운 채팅, 초안 작성, 지원 사이드바: GLM-5 또는 DeepSeek. 둘 다 민첩한 느낌입니다. DeepSeek은 첫 번째 토큰이 약간 더 빠른 편이고, GLM-5는 세션 전반에 걸쳐 일관된 톤을 유지하는 경향이 있습니다.
• 도구가 많은 어시스턴트: GPT-5. 계획과 스키마 안정성이 엣지 케이스 중단을 줄여줍니다. 예산이 빡빡하다면, DeepSeek으로 프로토타입을 만들고 가장 중요한 엔드포인트에는 GPT-5로 교체하세요.

배치 처리 → ?

대규모 오프라인 작업(수백에서 수천 항목)의 경우:

• 약간의 스타일 편차를 허용할 수 있다면 DeepSeek이 비용 효율에서 앞섭니다. 엄격한 출력 스키마와 차이 검사를 추가하세요.
• 이상값을 최소화하는 게 중요하고, 균일성을 위해 약간 더 지불해도 괜찮다면 GLM-5가 안정적인 기본값입니다.
• 작업에 항목당 더 깊은 추론이나 다단계 검색이 실제로 필요하지 않은 이상 GPT-5는 과도합니다. 그런 경우에는 재실행 비율이 충분히 줄어서 정당화됩니다.

멀티모달 파이프라인 → ?

이미지 + 텍스트 또는 오디오 + 텍스트 흐름의 경우, 브로셔보다 연결 방식이 더 중요합니다.

• GPT-5: 제 테스트에서 모달리티와 도구 간 가장 깔끔한 핸드오프를 보여줬습니다. 파이프라인이 추출, 추론, 생성 사이를 오간다면, 이 부드러움이 효과를 발휘합니다.
• DeepSeek: 빠르고 유능합니다. OCR + 요약이나 캡션 + 태그 작업에서 지연 시간을 낮게 유지했습니다.
• GLM-5: 구조화된 이미지-텍스트 작업에서 안정적입니다. 일관성이 화려함보다 중요할 때(예: 청구서 파싱이나 제품 데이터 정리), 먼저 손이 갔습니다.

설계 메모 하나: 중간 결과를 로그로 스트리밍하세요. 배포 전에 모달리티 불일치를 잡는 가장 쉬운 방법입니다.

---

WaveSpeed 가격이 세 모델 간에 어떻게 비교되는가

저는 WaveSpeed를 가격 합리성 확인 레이어로 사용해봤습니다. 마법 같은 해결책이 아니라, 지출에 대해 더 차분하게 생각하는 방법으로요.

눈에 띈 건 마법 같은 할인이 아니었습니다. 작동 방식이었습니다.

• 고정 라우팅: GPT-5를 계획이 필요한 엔드포인트에 고정하고, 단순 요약은 DeepSeek으로 보내고, 구조화된 편집은 GLM-5를 유지합니다. 청구서 하나, 놀라움은 줄어듭니다.
• 컨텍스트 캐싱: 시스템 프롬프트와 도구 스키마가 매 호출마다 다시 전송되지 않았습니다. 제 실행에서 평균적으로 입력 토큰을 3분의 1 줄였습니다. 화려하진 않지만, 쌓이는 절감 효과입니다.
• 엣지에서의 가드레일: 모델이 스키마에서 벗어나면, WaveSpeed가 일찍 잡아내고 같은 제공자로 재시도했습니다. 작업 중간에 제공자를 제비뽑기로 바꾸는 일이 없었습니다.

가격 측면에서 비교는 간단합니다.

• 이미 두 개 이상의 제공자를 관리하고 있다면, WaveSpeed의 라우팅과 캐싱이 공식 가격이 변하지 않더라도 실효 “유용한 출력당 비용”을 낮출 수 있습니다.
• 하나의 모델만 사용하고 프롬프트가 거의 바뀌지 않는다면, 큰 혜택을 못 볼 수도 있습니다. 그 경우에는 직접 API 가격에 자체 캐싱으로 충분합니다.

저는 WaveSpeed를 더 저렴한 토큰을 얻는 방법으로 생각하지 않습니다. 토큰을 덜 낭비하는 방법으로 생각합니다.

비슷한 제약 조건을 다루고 있다면, 한번 살펴볼 만합니다. 하나의 제공자에 만족한다면, 그것도 괜찮습니다. 가장 조용한 스택이 때로는 최선의 스택이니까요.