저렴한 비용으로 구현하는 최첨단 품질의 코딩: 우리가 구축한 것과 측정 방법

이 글은 벤치마크 표를 전문적으로 읽는 분들을 위한 /dev 포스트입니다. 논지는 간단합니다. 대부분의 요청을 저렴한 로컬 모델 (local model)로 처리하고, 어려운 요청만 최첨단 모델 (frontier model)로 에스컬레이션 (escalation)하는 캐스케이드 (cascade) 구조를 사용하면, 요청당 비용을 아주 적게 쓰면서도 최첨단 품질의 코딩 점수를 달성할 수 있다는 것입니다. 우리가 중요하게 생각하는 더 어려운 주장은, 신뢰성이 모델이 아닌 구조 (structure)에서 나온다는 점입니다. 이것이 대규모 환경에서 장기적으로 유지될 수 있는지는 우리의 미실행 벤치마크 (unrun benchmarks)가 해결해야 할 과제이므로, 결과가 아닌 목표로 표시해 둡니다. 아래는 우리가 측정한 내용, 점수 산정의 정직성을 유지한 방법, 그리고 아직 수치가 없는 부분들입니다.

아키텍처 (Architecture), 한 단락 요약

두 개의 채널이 있습니다. 하나의 능력 채널 (capability channel, 실제 문제를 해결하는 저렴한 로컬 모델 gpt-oss-120b)과 하나의 구조 채널 (structure channel, 답변이 신뢰할 수 있는지 아니면 에스컬레이션이 필요한지를 결정하는 검증 게이트 (verification gates) 및 가드 (guards))입니다. 앞단에는 캐시 (cache)가 위치하여 정확히 동일한 반복 요청은 다시 해결하지 않습니다. 로컬 모델이 확신을 갖고 가드 (guards)를 통과하면, 요청은 저렴하게 처리됩니다. 가드 (guards)가 실패하면, 최첨단 모델 (frontier)로 에스컬레이션됩니다. 가장 흥미로운 동작과 측정의 어려움 대부분은 구조 채널 (structure channel)에 존재합니다.

코딩 점수를 산정한 방식과 이를 신뢰하는 이유

주요 코딩 수치는 공개 리더보드 (public leaderboard)와 동일한 하네스 (harness)에서 실행된 HumanEval+로부터 도출되었습니다. 우리는 이를 정보 유출이 없는 (leak-proof) 방식으로 산정합니다. 공개/기본 테스트 (public/base tests)가 입력을 게이트 (gate)하고 (후보가 적격한지 여부를 결정), 숨겨진 "plus" 테스트가 점수를 매깁니다. 모델은 자신이 채점되는 테스트를 절대 볼 수 없습니다.
우리는 또한 이를 PRISTINE 방식으로 실행했습니다. 스테이징 캐시 (staging cache)를 먼저 비우고, 캐시 회상 (cache recall)을 제로로 설정하여, 점수가 이전 실행의 기억이 아닌 실제 해결 능력을 반영하도록 했습니다.

이러한 설정(2026-06-24, BENCH-DOSSIER-coding, n=164 문제): 전체 Tirtha 캐스케이드 기준으로 94.5% 이상 / 99.4% 베이스를 기록했습니다. 문제는 저렴하게 해결된 것이 96%, 에스컬레이션된 것이 3.7%였으며, 캐시 히트는 없었습니다(콜드런).

저희 자체 하네스에서 최전선 기준점(frontier yardsticks)을 측정했을 때도 동일한 164개 문제와 같은 날짜를 사용했습니다: Sonnet 4.6은 92.7% 이상, Opus 4.8은 93.3% 이상, GPT-5.3-codex는 90.2% 이상을 기록했습니다. 캐스케이드가 이 하네스에서 이러한 기준점과 같거나 그 이상의 성능을 보입니다. 이것이 저희 하네스를 기준으로 한 동등성 주장(parity claim)이며, 리더보드 제출 결과는 아닙니다.

비용 논점에서 중요한 부분은 향상분(lift)입니다. 캐스케이드 자체의 로컬 모델만 단독으로 실행했을 때(

장기적 관점(Long-horizon) 및 긴 문맥(Long-context) 동작

토큰 효율성(Token efficiency)에 대하여: 방해 요소가 포함된 스모크 테스트(distractor smoke test, 로컬 7B, 2026-06-26)에서 동일한 정답 정확도를 기준으로 했을 때, 압축 레이어(compaction layer)는 약 165개의 문맥 토큰(context tokens)이 필요했던 반면, 가공되지 않은 전체 문맥(raw full context)은 약 28,000개가 필요했습니다. 이는 대략 0.6% 수준입니다. 단일 바늘 다중 홉 문맥 회전 벤치마크(single-needle multi-hop context-rot bench)에서 7B 모델은 28K까지 100%를 유지했으며, 아직 회전(rot) 현상은 발견되지 않았습니다.

가공되지 않은 긴 문맥의 한계(raw long-context ceiling)에 대하여: 단일 프롬프트 NIAH(Needle In A Haystack) 다중 홉 프로브(3 hops x 2 reps, n=6, 2026-06-28) 결과, 208k 토큰까지는 100%로 깨끗했으나, 216k 이상에서 강력한 HTTP-500 제한에 부딪혔습니다. 이 제한을 정확히 해석해야 합니다: 이는 구성된 인프라의 한계이며, 상향 조정이 가능합니다. 모델의 262k 윈도우(224k에서도 실패함) 제한이나 품질 저하(quality cliff)가 아닙니다. 요청이 저하되는 것이 아니라 거부되는 것입니다. 또한, 단순히 토큰을 채워 넣는 방식(raw token-stuffing)은 시스템이 실제로 긴 문맥을 수용하는 방식이 아니라 압축/메모리 레이어(compaction/memory layer)를 사용하는 방식이므로, 이 프로브는 실제 경로에 대한 테스트라기보다 배관(plumbing)의 하한선 테스트입니다.

솔직한 격차(Honest gaps)

공식적인 장기적 관점(long-horizon) 벤치마크들은 구축되었으나 실행되지는 않았습니다. RULER, LongMemEval, faithfulness, SWE-bench 모두 실행기(runners)가 작성되어 병합되었으나, 아직 깨끗한 환경(clean box)에서 실행된 적은 없습니다(샌드박스에서 Docker를 복제하거나 실행할 수 없음). 따라서 현재 저희 측의 공식적인 RULER 수치, SWE-bench 수치, 공식 LongMemEval 수치는 없습니다. 특히 LongMemEval은 200k 이상 및 세션 전반에 걸친 압축/메모리 해자(compaction/memory moat)를 검증하는 진정한 테스트이지만, 아직 실행되지 않았습니다. 저희 내부의 NIAH는 포화 상태에 이르며, 공식적인 긴 문맥 결과로 인용될 수 없습니다.

HumanEval+ 점수 산정은 유출 방지(leak-proof)가 되어 있으나, 문제들이 공개되어 있으므로 학습 오염(training contamination)의 가능성이 있습니다. 절제 연구(ablation)는 저희의 하네스(harness)에서 작은 표본 크기(small-n)로 진행되었습니다. 단조 게이트(monotonic gate)는 테스트가 작동해야 하므로, 테스트가 없는 케이스는 증명되지 않았습니다. 208k 대역은 n=6입니다. 비용 및 서비스 믹스(cost and serve-mix)는 유동적인 실시간 스냅샷입니다.

우리가 주장하는 것과 주장하지 않는 것

우리가 주장하는 것: 우리의 하네스(harness) 상에서, 누출 없는 점수(leak-proof scored)를 기준으로 했을 때, 캐스케이드(cascade) 방식은 프런티어(frontier) 코딩 점수와 일치하면서도 대부분의 요청을 약 8배 더 저렴한 요청당 비용을 가진 저렴한 로컬 모델(local model)로 처리하며, 구조적 채널(structure channel)이 신뢰성 향상을 담당한다는 것입니다. 우리는 공식적인 장기 벤치마크(long-horizon benchmark) 결과를 주장하는 것이 아닙니다. 왜냐하면 아직 결과가 없기 때문입니다. 실행기(runners)는 존재하지만, 박스(box)는 존재하지 않습니다. 상황이 바뀌면, 동일한 방식으로 날짜 및 표본 크기(n)와 함께 해당 수치들이 이곳에 기재될 것입니다.