가성비 코딩 AI, GPT-5 Mini·Haiku 4.5·GLM-4.6 실제 비교: 코드 품질부터 속도, 비용까지 뭐가 다를까?

최신 소형 코딩 모델 3종, 실제로 써보면 이런 차이가 있었다

요즘 AI 코딩 모델 중에는 성능과 가격 균형을 잡은 소형 API 기반 모델이 꾸준히 인기를 얻고 있습니다. 이번에는 Haiku 4.5, GLM-4.6, 그리고 GPT-5 Mini 세 가지를 놓고, 실제 개발 작업 환경에서 어느 모델이 어떤 특성을 보였는지 살펴본 비교 내용입니다. 누구든 IDE, CLI에서 바로 활용하는 모델들로, 지나치게 고가인 최신형은 아닙니다.

테스트는 단일 프롬프트로 진행해 공정성을 높였습니다. ▲타입스크립트 ▲SQLite 활용 ▲비동기 작업 큐 구축 ▲지연 실행·데이터 영속성·예시 코드까지 모두 요구한 점이 특징입니다. 즉, 현실적인 백엔드 코딩 과제 수준입니다. 이 조건 아래 세 모델을 동등하게 실행해 속도·비용·코드 품질·툴 호출 성공률을 모두 기록한 것이죠.

API 호출 비용과 실제 총비용, 숫자로 보면 의외가 있다

먼저 API 단가만 보면 GPT-5 Mini가 가장 저렴하고, Haiku는 출력 토큰당 단가가 좀 더 높습니다. GLM은 중간쯤인데, 정말 중요한 건 총비용입니다. 왜냐하면, 모델이 얼마나 말을 많이 하느냐가 비용에 엄청난 영향을 미치기 때문입니다. GLM은 토큰 단가는 저렴해도, 설계상 설명과 구조가 워낙 상세하다 보니 실제로는 0.14 수준으로 비용이 가장 높았습니다. Haiku는 0.08, Mini는 0.05 수준으로 책정되었습니다.

여기에 GPT-5 Mini만의 캐싱 시스템이 있습니다. 동일 반복 작업이나 문맥 길이가 길어져도, 재호출시 비용이 무려 90%가량 줄어듭니다. 긴 코딩 세션에서 누적 비용이 상당히 내려간다는 점, 실질적 개발 환경에서는 꽤 유용한 특장점입니다.

코드 완성도와 실제 동작, 어떻게 달랐나?

테스트 프롬프트 내용은 비동기 큐, 지연·영속성·예제까지 포함합니다. 이 작업이 실제로는 동시성·트랜잭션·에러 제어까지 수반돼서, 모델이 단순히 예시 코드만 뱉는 것과는 완전히 다릅니다. 결과적으로 각 모델별 특징은 아래와 같이 드러났습니다.

GPT-5 Mini

실제 사용 목적에 가장 가까웠던 모델입니다. SQLite의 동시성 제한을 정확히 이해했고, 리스 기반 잠금 시스템을 도입했습니다. 각 작업에 타임스탬프와 만료 컬럼까지 넣어, 실제 프로덕션에서 흔히 쓰는 구조로 해결한 것입니다. 트랜잭션과 지수 백오프 로직을 활용해 안정성도 챙겼습니다.

툴 호출에서 약간의 실패가 있었으나, 자동 재시도 후 정상 복구되는 모습이었습니다. 속도는 6분 정도로 무난했고, 무엇보다 "제품에 바로 넣을 수 있는 코드" 수준을 달성했습니다.

GLM-4.6

구조 완성도와 파일 분할 능력에서 유독 뛰어납니다. 여러 파일로 나누고, 타입·Enum·우선순위 큐까지 구현하면서, 코드를 보는 순간 "아, 설계자가 깊게 생각했구나" 싶은 느낌이 납니다. 다만, 무작위 UID 생성기를 직접 구현해, 현실적으로는 검증된 랜덤 함수가 필요한 부분을 아쉽게 넘겼습니다.

가장 큰 문제는 툴 호출이 '추론 모드' 에서 아예 고장났다는 점입니다. reasoning mode를 비활성화해야 코드가 실행될 수 있었고, 그 과정이 다소 느렸습니다. 또, 작업 목록을 메모리에만 저장해 앱이 다운되면 데이터가 날아가는 구조였으니, 동시성·영속성 관리에서는 프로덕션 수준으로 부르기 어려운 한계를 보였습니다.

Haiku 4.5

속도 하나만큼은 독보적입니다. 실행까지 3분이란 압도적 속도를 보였고, 추가로 통계·삭제·인덱스 같은 편의 기능까지 넉넉하게 구현합니다. 코드 상에서 API 호출 실패가 전혀 없었고, 파일 수정 정밀도도 매우 높았습니다.

다만 동시성이나 데이터 관리에서 기본적인 락킹·트랜잭션·성공 보장 로직 없이 진행해, 실제 API 뒷단에 올릴 때는 보완이 불가피할 것으로 보입니다. 통계, 삭제 등 부가 기능 구현이 세련된 반면, 안정성이나 데이터 손실 방지는 신경 쓰지 않은 점이 뚜렷합니다.

실제 모델별 강점, 단점, 속도와 구조를 비슷한 환경에서 비교하니

비교 결과만 놓고 보면,

• Mini는 안정성과 실전 코드에 강점

• GLM은 구조·확장성 중심 코드이지만, 실행환경이나 안전성은 취약

• Haiku는 압도적인 속도와 편의기능에 집중하되, 데이터 관리·동시성 제어는 미완성

툴 호출 관련해서도 GLM은 reasoning 활성화 시 아예 실패, Haiku는 전부 성공, Mini는 재시도 후 성공하는 양상을 보였습니다.

작업 규모가 커질수록 단가와 실제 총비용, 동시성 등 시스템 안정성에 차이가 벌어집니다. 즉, 단순 출력 토큰 단가보다는 실행 패턴과 실제 동작이 비용·품질을 크게 좌우한다는 점이 명확하게 드러났습니다.

현실적으로 따져봐야 할 부분들

이번 비교에서 드러난 각 모델의 특성이 실제 개발 환경에 얼마나 의미가 있는지 따져볼 필요가 있습니다. GPT-5 Mini의 동시성 및 데이터 안정성, 리스 기반 잠금과 트랜잭션 설계는 백엔드나 고객 데이터가 직접적으로 엮인 서비스에 중요한 요소입니다. 이런 특성은 단순히 코드 예시를 보기 위한 것이 아니라, "내가 곧 서비스에 반영할 코드"라는 전제에서 실질적 안전망을 제공하므로, 코드 자동생성 AI를 도입할 때 우선순위로 삼을 만합니다.

반면 GLM은 여러 파일에 분리된 구조, Enum·타입·우선순위 등 설계 미학이 분명한 장점입니다. 다만, 예시 모델에서는 reasoning 모드가 불안정해, 실제 도입하려면 별도의 컨피그·검증 과정이 필요합니다. 작업 내역을 메모리에만 보관하는 방식도, 지속적 서비스에 도입한다면 반드시 개선해야 할 부분입니다.

Haiku의 장점은 압도적인 속도와 개발 편의성에 있습니다. 빠른 프로토타이핑, 시연, 간단한 백엔드 데모 작업에는 효율성이 돋보입니다. 반면, 실제 트래픽이나 데이터 동시접속이 있는 환경에서는 오류나 데이터 손실 가능성이 무시할 수 없습니다.

결국, 어떤 모델이 '최고'인가 보다 어떤 상황에 맞춰 쓰느냐가 핵심입니다. 실전 투입, 안정성·복구 필요 작업에는 Mini 쪽이 실익이 큽니다. 설계와 구조적 코드에 집착하는 상황에서는 GLM이 흥미로운 선택이지만, 보완이 필수적입니다. 신속한 데모·기획 방향성 제시에는 Haiku가 충분히 매력적입니다.

개발자 입장에서는 단순 토큰 가격만 보지 말고, 자신이 얻고자 하는 코드 결과와 유지·운영 안정성, 프로토타이핑 속도 중 어디에 방점을 둘지 먼저 판단한 다음 모델을 선택할 필요가 있습니다. 그리고 아직 소형 모델들은 복잡한 도메인이나 대용량 서비스에는 분명 한계가 있으니, 실 적용 전에는 반드시 세심한 검증 절차가 필요하다는 점도 함께 확인해 둘 가치가 있습니다.

출처 및 참고 :