같은 프롬프트, 11개 모델: 동네 카페 사이트 결과와 크레딧 비용 비교

Who Should Read

코딩 에이전트용 모델을 비용 대비 성능으로 골라야 하는 웹 서비스 개발자

Core Mechanics

• 모델별 비용이 200배 넘게 벌어졌다
  • 평균 크레딧은 Claude Opus 5가 519, DeepSeek V4 Flash(0731)가 2.4였다.
  • 프롬프트는 같았고 모델마다 3번씩 돌렸다.
• Opus는 한 번이 1,055크레딧이었다
  • Opus 3번은 253·249·1,055크레딧이었다.
  • 1,055크레딧 런은 다른 어떤 런보다 약 4배 많았다.
  • 저자는 Opus가 다른 모델보다 크레딧을 크게 쓰는 경우가 잦다고 썼다.
• GPT 5.6 Sol은 low effort로 평균 141크레딧이었다
  • Netlify는 Sol을 기본 low effort로 돌린다(Opus급 모델을 조금만 생각하게 한 설정).
  • 저자는 이 시나리오에서 Sol이 Claude Sonnet 5(평균 143크레딧)보다 기본 디자인 감각이 낫다고 평가했다.
• 같은 모델도 결과가 들쭉날쭉했다
  • GLM 5.2는 15·42·24크레딧으로, 저자는 서로 다른 모델이 만든 것 같다고 썼다.
  • 저자는 저렴한 모델은 여러 번 돌려 본 뒤 판단하라고 권했다.
  • DeepSeek V4 Flash 0731도 결과가 제각각이었다.
• Gemini는 세대 차이가 컸다

Community Reactions

• 표본 3번은 비교 근거로 부족하다는 의견
  • 한 댓글은 모델 평가가 확률적이라 표본 1개는 무의미하다고 썼다.
  • 이 댓글 작성자는 스팸 필터링용 로컬 모델 벤치마크에서 최소 5번씩 돌린다고 했다.
  • 다른 댓글도 3번이면 무작위성에 민감하다고 지적했다.
• 두 문장짜리 프롬프트는 비현실적이라는 의견
  • 여러 댓글이 실무에선 구체적 지시를 주기 때문에 이런 원샷 평가는 대표성이 낮다고 썼다.
  • 실제 가게의 영업시간·주소 같은 제약이 있어야 모델의 약점이 드러난다는 의견도 있었다.
• 저렴한 모델 결과물이 더 쓸 만했다는 경험
  • 한 댓글은 휴대폰으로 메뉴와 주소를 빨리 찾는 기준에서는 Kimi·GLM·DeepSeek 결과가 더 낫다고 썼다.
  • 다른 댓글은 Gemini 3.1이나 DeepSeek V4의 텍스트 위주 결과가 덜 AI스럽다고 썼다.
• 모바일 확인이 빠졌다는 지적
  • 한 댓글은 Firefox 개발자 도구로 보니 모바일에서 모델별 차이가 컸다고 했다.
  • 이 댓글에 따르면 Gemini 3.6 결과물은 3G 환경에서 로딩되지 않을 만큼 무거웠다.
• 내 문제로 직접 평가하라는 의견
  • 한 댓글은 범용 벤치마크 대신 내 실제 문제로 임시 eval을 만들라고 썼다.

How to Apply

• 내 서비스 프롬프트를 3~5번씩 돌려 보기
  • 오늘 쓰는 프롬프트 하나를 후보 모델 2~3개에 각각 3~5번 돌려라.
  • 결과물과 토큰·크레딧 비용을 표로 적어 편차를 확인하라.
• 저비용 모델은 반복 실행 후 고르기
  • GLM 5.2나 DeepSeek V4 Flash 같은 싼 모델은 같은 프롬프트로 여러 번 돌려라.
  • 쓸 만한 결과 비율이 높으면 후보에 올려라.
• 초안 모델과 반복 수정 모델을 분리하기
  • 초기 아이디어 단계에는 비싼 모델을 한두 번만 돌려라.
  • 이후 수정은 싼 모델에 후속 프롬프트로 지시해 예산을 아껴라.
• 실제 제약을 프롬프트에 넣어 평가하기
  • 영업시간·주소·모바일 로딩 같은 실제 요구를 프롬프트와 체크리스트에 넣어라.
  • 모델별로 틀리는 항목을 센 뒤 비용과 함께 비교하라.

Try It

# Claude나 ChatGPT에 붙여넣기: 원문 비교 방식의 간이 버전 (같은 프롬프트로 결과 편차 확인)

당신은 코드 리뷰어입니다. 아래 프롬프트로 같은 모델이 만든 결과물 3개를 비교합니다.

[원 프롬프트]
{{원 프롬프트: 예) 동네 카페 한 페이지 사이트 만들어줘. 영업시간, 주소, 짧은 메뉴, 사진. 내가 수정하기 전엔 바뀌는 게 없어야 해}}

[결과물 1]
{{결과 1}}

[결과물 2]
{{결과 2}}

[결과물 3]
{{결과 3}}

각 결과물에 대해 다음을 표로 정리하세요.
1. 요청 요소 누락 여부(영업시간, 주소, 메뉴, 사진)
2. 깨진 이미지·참조 오류 여부
3. 모바일에서 메뉴와 주소를 바로 찾을 수 있는지
4. 불필요한 과설계(DB·CMS 등) 여부
마지막에 3개 결과의 편차가 큰 항목을 한 줄로 요약하세요.

이어서 해 볼 것: 같은 표를 다른 모델의 결과 3개로 만들어 비교하고, 크레딧이나 토큰 비용을 옆에 적어 보세요.

Terminology

관련 논문

• The Judge Can Debias Itself: LLM-as-a-Judge가 스스로 편향을 고치게 하는 법

  심사 프롬프트에 편향 경고를 넣거나 스스로 비판시켰더니 21개 중 20개 조합에서 정확도가 올랐다

• 미국 노동시간의 90%는 AI 벤치마크가 제대로 다루지 못하는 일이다

  벤치마크 29개를 직업 과제에 매핑했더니 노동시간 90%가 커버 밖

• Postgres 19, AI 코드 리뷰가 버그를 너무 많이 찾아 출시 연기

  LLM 코드 리뷰가 버그를 쏟아내 Postgres 19가 11월로 밀리고 기능 8~10개가 빠졌다

• StarSkirmish Bench v0.2: LLM이 1시간 만에 짜는 StarCraft 봇 대결

  LLM에게 1시간 동안 StarCraft 봇을 짜게 했더니 GPT-6 Astra가 1위

• 그럴듯한 설명 하나면 멀티모달 LLM 심사위원도 속는다 (JUPE 벤치마크)

  정답은 그대로 두고 설명만 붙였더니 MLLM 심사위원의 오답 거절률이 12.7~13.8%p 떨어졌다

• 신경망은 이미 깔끔하다: polysemanticity의 원인 재해석

  뉴런을 직접 들여다봤더니 대부분 한 가지 역할이 있었다는 주장

• Linus Torvalds의 첫 LLM 보조 패치 시리즈

  Linus가 LLM으로 folio 조회 패치 10개를 만들어 read() 벤치가 10배 빨라졌다

Related Resources

• https://www.netlify.com/blog/one-prompt-11-models-very-different-results/
• https://wiki.roshangeorge.dev/w/images/4/4e/Screenshot_-_Eva...
• https://nehmeailabs.com/right-size