Vilius Vystartas 작성 | 2026년 5월

모든 LLM은 작동하는 코드를 작성할 수 있습니다. 문제는 이것입니다: 그들이 '효율적인 (efficient)' 코드를 작성할 수 있는가 — 그리고 효율적으로 작성하라고 말하는 것이 실제로 도움이 되는가?

저는 10개의 모델을 대상으로 10개의 코딩 작업에 대해 테스트를 진행했으며, 각 작업은 두 단계로 나누어 진행되었습니다: 무프롬프트 (unprompted) (모델이 스스로 코드를 작성) 및 프롬프트 제공 (prompted) (깨끗하고, DRY하며, 효율적인 코드를 작성하도록 명시적으로 지시). 이는 총 200번의 API 호출이었으며, 비용은 총 $0.56였습니다. 결과는... 대부분의 프롬프트 엔지니어(prompt engineers)들이 예측할 만한 것이 아니었습니다.

GPT-5.4는 프롬프트 제공이 상당한 향상(+0.20)을 가져온 유일한 모델이었습니다. 대부분의 모델에서 "효율적인 코드를 작성하라"는 프롬프트는 무의미하거나 오히려 해로웠습니다.

지표 작동 방식

각 작업에는 알려진 최적 토큰 예산 (optimal token budget) 이 있습니다. 이는 해당 작업을 위해 정확하고 DRY한 코드를 생성하는 데 필요한 최소 토큰 수입니다 (예: CSS 클래스를 사용하여 스타일링된 10개의 버튼을 만드는 데 70토큰 vs 10개의 개별 버튼 블록을 만드는 데 340토큰).
효율성 점수 (efficiency score) 는 optimal_tokens / actual_tokens이며, 최대치는 1.0으로 제한됩니다.

0.63점이라는 점수는 모델이 최적치의 약 1.6배를 사용했음을 의미하며, 이는 나쁘지 않은 결과입니다. 0.43점은 최적치의 약 2.3배를 사용했음을 의미합니다. 무프롬프트와 프롬프트 제공 간의 격차는 "효율적인 코드를 작성하라"는 지시가 실제로 행동을 변화시키는지 알려줍니다.

리더보드 (프롬프트 제공 효율성 기준 정렬)

눈에 띄는 점

GPT-5.4는 프롬프트의 달인 (Prompt Whisperer)

GPT-5.4는 효율성을 위해 프롬프트를 제공했을 때 10개 작업 중 7개에서 개선되었습니다. 가장 큰 승리는 설정 생성 (config-generation) (+0.81 — 12개의 인라인 JSON 블록에서 템플릿 루프로 변경), 데이터 기반 HTML 생성 (html-from-data) (+0.71), 그리고 매직 스트링 (magic-strings) (+0.38 — Enum으로 전환) 이었습니다. 이 모델은 "효율적인 코드를 작성하라"는 지시가 일관되게 다른(그리고 더 나은) 출력을 생성하는 이번 배치 내 유일한 모델입니다.

비용은 주목할 만합니다. 20개 작업에 0.10달러는 중간 수준으로, 저렴하지도 비싸지도 않습니다. 하지만 효율성 이득은 실질적입니다.

Gemma 4 31B: 조용한 승자

Gemma 4 작업의 절반은 이미 "절약적 (frugal)"이었습니다. 즉, 별도의 지시 없이도 자연스럽게 효율적이었습니다. 이 모델은 단 0.003달러의 총비용으로 두 단계 모두에서 92%의 정확도를 기록했습니다. 이는 GPT-5.4 대비 40배의 비용 우위를 가지면서도 더 높은 정확도와 경쟁력 있는 효율성을 보여준 것입니다. 간결하고 정확한 코드를 원하는 대량 생산 환경에서 Gemma 4 31B는 이번 배치(batch)의 가성비 선택지입니다.

Cohere Command A: 프롬프팅의 역효과

Cohere Command A는 이번 배치에서 가장 높은 비지시적 효율성 (unprompted efficiency) (0.60)을 기록했습니다. 즉, 자연스럽게 간결한 코드를 작성합니다. 하지만 "효율적인 코드를 작성하라"는 지시를 받았을 때, 여러 작업에서 출력량이 급증했습니다. html-from-data 작업의 경우, 45개 토큰 내외의 타이트한 솔루션에서 600개 이상의 토큰이 들어가는 괴물 같은 결과물로 변했습니다 (-0.92 격차). 프롬프트가 모델을 과하게 생각하게(overthink) 만든 것입니다.

교훈: 모델이 이미 효율적이라면, 더 효율적이 되라고 프롬프트를 주지 마세요.

Qwen 3.6 Plus: 2위, 가장 느림

Qwen 3.6 Plus는 지시적 효율성(prompted efficiency)에서 2위(+0.17 개선)를 차지했지만, 20개 작업을 수행하는 데 26분이 걸려 단연 가장 느린 모델이었습니다. 효율성 이득은 실질적이지만(특히 html-from-data 작업에서 하드코딩된 행(row) 방식에서 map/join 패턴으로 전환됨), 기다림이 필요합니다. 배치 워크로드(Batch workloads)에만 적합합니다.

Kimi의 반전

Kimi K2.6는 가장 낮은 비지시적 효율성(0.34 — 장황하고 상용구(boilerplate)가 많은 코드)을 보였으나, 하위권 모델 중 가장 많은 개선(+0.09)을 이루었습니다. 여전히 최하위지만, 프롬프트가 실제로 코드를 압축하는 데 도움을 주었습니다. 이는 Cohere의 효과와 정반대입니다. 어떤 모델들은 자극(nudge)이 필요합니다.

절약성 (Frugality): 그것은 무엇을 의미하는가?

"절약적 (Frugal)"이라는 것은 모델이 요청받지 않고도 최적의 토큰 수에 도달하거나 그에 근접한 코드를 자연스럽게 생성했음을 의미합니다. Gemma 4 31B와 Gemini 2.5 Flash가 50%로 앞섰습니다. 즉, 작업의 절반이 이미 효율적이었습니다. GPT-5.4, DeepSeek Chat, Kimi K2.6는 절약성이 30%에 불과했습니다. 이들은 코드를 다듬기 위해 프롬프트가 필요했습니다.

더 큰 그림

프롬프트에 반감을 보이는 (prompt-antagonistic) 그룹이 가장 흥미롭습니다. 이 모델들은 프롬프트 없이도 효율적인 코드를 작성하는 법을 알고 있지만 (0.54-0.60), 명시적인 지시가 오히려 과잉 엔지니어링 (over-engineering)을 유발합니다. 즉, 추상화 (abstractions), 주석 (comments), 에러 처리 (error handling) 및 기타 불필요한 요소 (bloat)를 추가하여 측정 지표상 결과물의 효율성을 떨어뜨립니다.

만약 프롬프트가 "효율적인 코드를 작성하라"고 명령했는데 모델이 더 많은 토큰을 생성하며 응답한다면, 훈련 신호 (training signal) 중 무언가가 어긋나 있는 것입니다.

나의 선택 (My Picks)

• 최고의 프롬프트 기반 효율성: GPT-5.4 — 0.63, 20개 작업당 $0.10. 프롬프팅이 결과물을 안정적으로 개선하는 유일한 모델입니다.
• 전반적인 최고의 가성비: Gemma 4 31B — 프롬프트 적용 시 0.58, 정확도 92%, $0.003. 말도 안 되는 가격 대비 성능을 보여줍니다.
• 최고의 자연적 효율성: Cohere Command A — 프롬프트 없이 0.60. 프롬프트를 주지 말고 그냥 그대로 두세요.
• 가장 일관된 모델: Claude Sonnet 4 — 두 단계 모두에서 92%의 정확도를 보였으며, 효율성은 +0.04 소폭 상승했습니다. 신뢰할 수 있습니다.
• 급할 때는 건너뛰어야 할 모델: Qwen 3.6 Plus — 20개 작업에 26분 소요. 효율성 향상은 뛰어나지만 지연 시간 (latency)이 매우 심각합니다.
• 관찰 대상: Kimi K2.6 — 기본 효율성은 낮지만 프롬프트가 실제로 도움이 됩니다. 더 나은 프롬프트로 재테스트해 볼 가치가 있습니다.

방법론 (Methodology)

CSS, JavaScript, Python, SQL, bash를 아우르는 10개의 실제 코딩 작업을 수행했습니다. 각 작업은 정확하고 DRY (Don't Repeat Yourself) 원칙을 준수하는 솔루션을 위한 최적의 토큰 예산이 정해져 있습니다. 작업 내용은 다음과 같습니다: 버튼 10개 스타일링 (CSS), 20개의 데이터 행을 HTML로 렌더링 (JS/HTML), 일괄 이름 변경 (shell), 양식 유효성 검사 (Python), 매개변수화된 테스트 (Python), 단위 변환 (Python), SQL 보고용 쿼리, 설정 생성 (JSON), 매직 스트링 교체 (Python/Enum), 그리고 미들웨어 데코레이터 패턴 (Python/Flask)이 포함되었습니다.

각 모델은 별도의 프롬프트 없이 10개의 작업을 수행한 후, 동일한 10개의 작업에 효율성 프롬프트 (efficiency prompt)를 추가하여 다시 수행했습니다. 채점 방식은 다음과 같습니다: efficiency_ratio = optimal_tokens / actual_tokens (최대 1.0으로 제한). 정확성 (Correctness)은 예상 출력 패턴 (expected output patterns)을 기준으로 채점되었습니다.

총 비용: 200번의 API 호출 (10개 모델 × 10개 작업 × 2개 단계)에 $0.56이 소요되었습니다. Temperature (온도): 0.1. Max tokens (최대 토큰): 600.

전체 결과: benchmarks.workswithagents.dev