10가지 LLM 평가 실험을 계획했지만 단 하나만 실행했습니다. 그것으로 충분했습니다.

저는 벤치마크 논문을 쓰려고 시작한 것이 아닙니다.

저는 훨씬 더 단순하고 훨씬 더 실질적인 질문에 답하고 싶었습니다:

“내가 실제로 업무에서 하는 일들을 위해, 언제 정말로 프런티어 모델 (Frontier Model)이 필요하며... 언제는 그냥 돈을 낭비하고 있는 것인가?”

그래서 저는 이 문제를 진지하게 다루고 싶을 때 엔지니어들이 하는 일을 했습니다:

• 10가지 실험을 설계했습니다
• 실제 에이전트 (Agent) 사용 사례 전반에 걸쳐
• **재사용 가능한 평가 하네스 (Evaluation Harness)**를 갖추고
• 나중에 스스로를 원망하지 않도록 **예산 상한선 (Budget Ceiling)**을 설정했습니다

그리고 나서 저는 그중 정확히 하나만을 실행했습니다.

결과적으로, 그 하나만으로도 충분했습니다.

분리된 뇌의 현실: 업무 예산 vs 개인 예산

직장에서는 다른 누군가가 LLM 토큰 비용을 지불합니다.

• 프런티어 모델 (Frontier Models)은 Jira 티켓 하나로 해결됩니다.
• 우리는 실제 데이터로 20-shot 실험을 수행할 여유가 있습니다.
• “일단 출시하고 배우자”는 합리적인 기본값입니다.

집에서는 다릅니다:

• 저는 Sonnet이나 V4를 로컬에서 실행할 수 없습니다.
• 제 GPU는 프런티어 품질의 4K 컨텍스트 윈도우 (Context Windows)를 삼켜내지 못합니다.
• 모든 생성 비용은 제 개인 신용카드로 결제됩니다.

저는 여전히 이 모델들이 장난스러운 프롬프트가 아닌 실제 워크로드에서 어떻게 작동하는지 이해하고 싶습니다. 하지만 제 개인 프로젝트에서는 돈이 어디에 쓰이는지 매우 정밀하게 관리해야 합니다.

그러한 긴장감이 프런티어 실험 프로그램 (Frontier Experiments Program)을 만들었습니다.

전체 범위를 파악하기 위해 10가지 실험을 설계했습니다

서류상으로 이 프로그램은 아름다웠습니다.

각 실험은 더 큰 질문의 단면이었습니다:

“DevOps 관련 업무를 수행하는 에이전트 (Agent) 군단에 대해, 어떤 모델이 어떤 작업을, 어느 정도의 노력 수준으로, 얼마의 비용을 들여 처리해야 하는가?”

저는 이를 중심으로 10가지 실험을 설계했습니다:

• Adaptive Budget Tuner (적응형 예산 조절기) – 품질 기준을 충족하면서도 가장 저렴한 추론 예산(reasoning budget)은 얼마인가?
• Frontier Lite Field Test (프런티어 라이트 현장 테스트) – 실제 워크로드에서 더 저렴한 모델이 비싼 모델을 대체할 수 있는가?
• Context Rot Detector (컨텍스트 부패 탐지기) – 실제 문서에서 긴 컨텍스트 회상(long-context recall)이 실제로 무너지는 지점은 어디인가?
• Tool Drift (도구 드리프트) – 한 번에 50~200개의 도구를 노출했을 때 도구 호출(tool-calling) 정확도가 저하되는가?
• Code Review Breakpoint (코드 리뷰 임계점) – AI 코드 리뷰가 더 이상 유용하지 않게 되는 PR(Pull Request)의 크기와 언어는 무엇인가?
• Local Vs Cloud Bench (로컬 대 클라우드 벤치마크) – 양자화(quantized)된 로컬 모델이 클라우드 모델의 성능에 충분히 근접할 수 있는가?
• Cache Hit Maximizer (캐시 히트 극대화 도구) – 프롬프트 캐싱(prompt caching)이 멀티턴 에이전트(multi-turn agents)에서 실제로 얼마나 많은 비용을 절감할 수 있는가?
• Open Weights Head-To-Head (오픈 웨이트 정면 승부) – 벤더 대 벤더가 아닌, 오픈 웨이트(open-weight) 모델 대 오픈 웨이트 모델의 대결
• Sovereign Agent Lab (주권 에이전트 실험실) – 미세 조정(fine-tuned)된 오픈 모델이 하나의 좁은 작업에서 프런티어(frontier) 모델과 대등할 수 있는가?
• Apex Threshold Detector (최상위 임계점 탐지기) – 어떤 작업이 실제로 가장 비싼 모델을 필요로 하는가?

그 외에도, 저는 재사용 가능한 평가 하네스(evaluation harness)인 model-compass를 구축했습니다:

• 9가지 실제 에이전트 작업 (CI 진단, 인시던트 분류(incident triage), 코드 리뷰, PR 초안 작성, 아키텍처 분석 등)
• 이진(binary) / 완전 일치(exact-match) / 테스트 러너(test-runner) / LLM 판사(llm-judge) 점수 산정 방식이 적용된 작업별 루브릭(rubrics)
• Anthropic, OpenAI, DeepSeek, OpenRouter, Together, Kimi를 위한 통합 어댑터 레이어
• USD 추정치를 포함하여 작업당 비용 자동 계산
• 라우팅 테이블(routing-table) 생성: “이 작업에는 통과 가능한 가장 저렴한 모델을 사용하라”

그것은 탄탄한 계획이었습니다.

그리고 저는 단 하나의 실험을 실행한 뒤 멈췄습니다.

왜 단 하나의 실험으로 CI 진단을 선택했는가

저는 아키텍처 추론이나 멀티 에이전트 조정(multi-agent coordination)처럼 더 “섹시한” 것으로 시작할 수도 있었습니다.

대신 저는 **CI 진단(CI diagnostics)**을 선택했습니다.

왜일까요?

그것이 제가 하루 종일 실제로 하는 일에 더 가깝기 때문입니다.

저희 팀은 여러 저장소(repos)에 걸쳐 TypeScript, Swift, Kotlin, C++, Java, Go, 그리고 BrightScript를 배포합니다. 저희의 CI 파이프라인(CI pipelines)은 수많은 퍼스트 파티(first-party) 및 서드 파티(third-party) 도구들을 하나로 묶어주는 역할을 합니다. 무언가 실패하여 빨간색 신호가 뜨면, 로그의 양은 킬로바이트(KB) 단위가 아니라 메가바이트(MB) 단위로 측정됩니다. 대부분의 실패는 무거운 통합 테스트(integration tests)에서 발생하며, 어떤 날은 도구 및 테스트의 불안정성(flakiness)만으로 특정 영역에서 5~20%의 실패율을 보이기도 합니다.

리더로서 제가 모든 실패 사례를 직접 읽지는 않았습니다. 제 팀원들이 읽었죠. 저는 그들의 고통을 이해하기 위해 개인적으로 투자했고, 실제로 도움이 될 수 있는 Claude 기술을 쌓기 시작했습니다. 추악한 현실은 "CI 실패(CI red) → 원인 파악 및 다음 단계 결정"까지가 로그를 다운로드하고 패턴을 찾는 데만 한 시간 이상 걸리는 작업이었다는 점입니다. 엔드 투 엔드(End-to-end)로 수정 사항을 프로덕션(production)에 반영하기까지는 종종 꼬박 하루가 걸리곤 했습니다.

적절한 자동화와 AI를 루프(in the loop)에 포함함으로써, 저희는 상황이 어떻게 돌아가고 있는지 파악하는 데 약 15분, 많은 경우 수정 사항을 머지(merge)하고 다시 프로덕션에 반영하는 데 2시간 미만으로 시간을 단축했습니다.

이 실험의 대부분의 실행은 동일한 방식으로 시작되었습니다. 저는 5,000줄에 달하는 GitHub Actions 로그를 찡그리며 바라보며 "이게 바로 내가 모델이 이 일을 대신 해주길 원하는 이유다"라고 생각하곤 했습니다.

만약 제가 다음과 같은 질문에 답을 얻을 수 있다면:

"CI 진단(CI diagnostics)을 위해, 실제로 어떤 모델에 비용을 지불해야 할까?"

그것은 즉시 업무에서의 더 나은 의사결정으로 이어질 것입니다.

그래서 실험 01(더 큰 프로그램의 전초전)은 서류상으로는 간단했습니다:

• 태스크(task): 실제 로그로부터 CI 빌드 실패 진단
• 모델(models): Haiku vs Sonnet
• 데이터(data): 오픈 소스 저장소(Django, Rails, Node, Pytest 등)의 실제 GitHub Actions 로그
• 채점(scoring): 모델이 올바른 실패 도메인(failure domain)을 식별하고 유용하며 정확한 단계를 제시했는가?

저는 엄격한 예산 제한을 두고 model-compass 하네스(harness)를 통해 이를 실행했습니다.

총 비용: $13.53.

이 실험이 무엇인지 (그리고 무엇이 아닌지)

더 자세히 설명하기 전에, 범위를 명확히 하는 것이 도움이 됩니다.

이 실험이 무엇인지

• 집중적이고 개인적인 현장 테스트 (Field test). 실제 내 업무와 유사한 하나의 DevOps 스타일 작업 (CI 진단)을 대상으로 합니다. 두 개의 모델, 실제 GitHub CI 로그, 그리고 품질, 지연 시간 (Latency), 비용의 패턴을 확인할 수 있을 만큼의 충분한 실행 횟수를 포함합니다.
• 나의 직관을 보정하는 방법. 나는 다음과 같은 질문에 답하고 싶었습니다: "CI를 위해 정말로 비싼 모델이 필요한가?" 그리고 "언제 저렴한 모델을 기본값으로 사용해도 안전한가?"
• 나의 하네스 (Harness)에 대한 현실 점검. 이 실험을 실행함으로써 하네스의 어느 20~25%가 진정으로 재사용 가능한지, 그리고 실험별 스크립트(데이터 다운로드, 프로파일, 플레이버, 요약)가 실제로 어디에서 비중을 차지하는지를 확인하게 되었습니다.
• 실제 제약 조건 내에서의 작업. 개인적인 예산, 본격적인 GPU 팜 (GPU farm)의 부재, 그리고 로컬에서 실행되지 않는 프런티어 모델 (Frontier models) 환경입니다. 목표는 "모든 것을 다루는 것"이 아니라, "잘 선택된 하나의 조각으로부터 최대한 많은 것을 배우는 것"이었습니다.

이 실험이 무엇이 아닌지

• 공식적인 LLM 벤치마크 (Benchmark)가 아닙니다. 나는 통계적 엄밀함을 갖추고 표준화된 공개 벤치마크를 통해 수십 개의 모델을 실행하는 것이 아닙니다. 나는 해당 팀들이 가진 인프라, 예산, 또는 전업 평가 전문가로서의 배경을 가지고 있지 않습니다.
• 리더보드 (Leaderboard)의 판결이 아닙니다. 하나의 CI 작업에서 두 개의 프런티어 모델을 비교하는 것이 "모델 A가 모델 B보다 전반적으로 우수하다"는 것을 의미하지는 않습니다. 이는 단지 "나의 프롬프트와 데이터를 사용한 CI 진단 작업에 있어서, 나에게는 이것이 합리적이다"라는 것을 말해줄 뿐입니다.
• 최종적인 하네스가 아닙니다. 원래의 model-compass 설계는 매우 범용적이고 재사용 가능한 코어를 가정했습니다. 실제로는 각 DevOps 실험마다 고유의 데이터 파이프라인과 스크립트가 필요했습니다. 이 실험은 더 나은 하네스를 만들어가는 과정이지, 그 자체로 최종적인 하네스는 아닙니다.
• 전문적인 평가 작업을 대체하는 것이 아닙니다. 전담 평가 팀과 막대한 예산을 보유한 조직이야말로 광범위하고 공식적인 모델 비교를 수행하기에 적합한 주체입니다. 내가 여기서 하고 있는 일은 훨씬 더 좁은 범위입니다. 즉, 내가 실제로 수행하는 업무에 사용하는 모델들에 대해 한두 가지 더 나은 결정을 내리는 것입니다.

핵심 결론: 저렴한 모델의 승리

결과:

• Haiku 4.5 vs Sonnet 5 (OpenRouter 경유)
• 동일한 프롬프트 (prompts), 동일한 로그 (logs), 동일한 채점 기준 (scoring rubric)
• 다양한 실패 유형(DB 연결, 테스트 실패, 빌드 오류, 의존성 문제)에 대해 약 50회 실행

Haiku:

• 10배 더 저렴함
• 67% 더 빠름
• 정확도 면에서 통계적으로 동등함

Sonnet:

• 더 많은 토큰 (tokens) 사용
• 비용이 더 많이 발생
• 더 느림
• 유일하게 중요한 지표인 "이 빌드 오류를 수정하는 데 도움을 줄 수 있는가?"에서 명확하게 성능이 앞서지 않음

"CI 진단(diagnostics)을 위해 Sonnet에 비용을 지불해야 하는가?"라는 질문에 대한 답은 다음과 같았습니다:

"기본적으로는 아닙니다."

이 내용만 읽는다면 다음과 같이 생각할 수도 있습니다:

• "와, 놀라운데요!"
• "비용 절감에 관한 멋진 이야기군요!"

하지만 저에게 와닿은 느낌은 그렇지 않았습니다.

그리고 이 부분이 중요합니다:

이 결과를 "모든 면에서 Haiku가 Sonnet보다 낫다"라고 받아들여서는 안 됩니다.

저의 구체적인 업무 영역에서는:

• CI 로그 분석
• DevOps 스타일 진단의 일부
• 제 팀이 실제로 맞닥뜨리는 유형의 사례들

Haiku가 이제 저에게 가장 합리적인 모델입니다:

• Sonnet보다 저렴합니다.
• 실제 사용 시 더 빠릅니다.
• 공개 데이터와 이번 실험 모두를 바탕으로 볼 때, 이러한 특정 작업들에 대해 "충분히 좋거나" 혹은 그 이상입니다.

업무를 할 때 저는 여전히 Sonnet이나 Opus를 많이 사용합니다. 특히 더 어려운 추론 (reasoning), 아키텍처 결정, 또는 더 모호한 문제들을 다룰 때 그렇습니다.

이번 실험은 단지 업무의 한 부분(CI / DevOps 진단)을 제 머릿속에서 "기본적으로는 Haiku를 사용하되, 필요할 때만 Sonnet/Opus를 사용한다"라는 카테고리로 옮겨 놓았을 뿐입니다.

여기에는 미묘한 차이가 있습니다. 어떤 실행에서는 Sonnet의 답변이 더 명확하고 일관성이 있었습니다. Haiku는 더 장황한 (verbose) 경향이 있었습니다. CI 진단에 있어서 그 장황함은 버그가 아니라 기능입니다. Haiku는 아마도 원본 로그의 1/1000 정도를 엔지니어나 후속 에이전트 (downstream agent)가 작업할 수 있는 무언가로 요약해 주는 것이니까요. 사람이 루프 안에 머물며(human in the loop) 추론할 수 있는 더 많은 맥락을 얻을 수 있다면, 저는 약간의 품질 차이를 감수할 수 있습니다.

비용은 놀랍지 않았습니다. 그것이 교훈은 아니었습니다.

저는 프런티어 모델 (frontier models)이 비쌀 것이라고 예상하고 시작했습니다.

다음과 같은 사실에 충격을 받지는 않았습니다:

• Sonnet에 대한 CI 진단은 이 작업에는 “가치가” 없었습니다.
• Haiku는 잡무(busywork)를 처리하기에 적절한 기본값처럼 보였습니다.

또한 저는 다음 사실에 충격을 받지 않았습니다:

• 단 하나의 작은 실험이 13.53달러가 소모되었고,
• 전체 10개 실험 프로그램은 수백 달러를 소비할 것이라는 점입니다.

이것이 바로 제가 개인적인 실험을 제한하고 업무상 실험을 더 개방적으로 유지하는 이유입니다:

• 직장에서는: 지갑이 크고, 탐색할 자유가 많습니다.
• 집에서는: 프런티어 모델(frontier models)로부터 배우고 싶지만, 사이드 프로젝트가 조용히 300달러짜리 청구서로 변하는 것은 원하지 않습니다.

실제 교훈은 다른 것이었습니다:

제가 하려고 했던 것을 배우기 위해 10개 실험을 모두 실행할 필요는 없었습니다.

광범위한 설계, 좁은 실행 (Wide Designs, Narrow Execution)

10개의 실험을 설계하는 것 자체는 여전히 가치가 있었습니다.

그 과정은 제가 다음 사항들에 대해 명확하게 생각하도록 강요했습니다:

• 다양한 작업에 “충분히 좋은(good enough)” 것이 무엇인지
• 컨텍스트 길이, 도구 개수, 캐싱이 실제로 어느 부분에서 중요한지
• 언제 파인튜닝(fine-tuning)이 단순히 “멋진 모델을 사용하기”보다 나은지

하지만 실행 측면에서는 다음을 깨달았습니다:

• 제가 일상적으로 얻는 이점의 대부분은 전체 실험실이 아니라 몇 가지 잘 목표화된 통찰력에서 나올 것이라는 점
• 더 나은 결정을 내리기 위해 모델 동작의 완벽하게 매핑된 프런티어(frontier)가 필요하지 않다는 점
• CI 진단을 “전형적인 DevOps 시나리오”로 실행하는 것만으로도 제 직관을 보정하기에 충분했다는 점

그 단 하나의 실험은:

• 모델 컴파스(model-compass) 하니스를 검증했습니다.
• 제가 실제로 관심을 갖는 작업에 대한 구체적인 라우팅 결정을 산출했습니다.
• 루브릭이 어디서 깨져 있는지 보여주었습니다 (이진 키워드 확인 대 실제 행동 품질).
• 모델을 선택할 때 머릿속에 남는 방식으로 “Haiku 대 Sonnet”의 트레이드오프를 수면 위로 끌어올렸습니다.

나머지 9가지 실험 설계는 필요할 때 여전히 남아 있습니다.

하지만 지금으로서는, 설계 작업과 하나의 집중적인 실행만으로 충분했습니다.

지저분한 부분: LLM에게 하니스를 구축하게 했다 (The Messy Part: I Let An LLM Build The Harness)

실험 결과보다 더 중요하다고 생각하는 또 다른 계층이 있습니다.

저는 LLM에게 평가 하니스를 직접 구축하도록 요청했습니다.

그것은… 작동했습니다.

어느 정도는요.

LLM이 잘해낸 점

• 전체 비교 스크립트 (comparison script)를 빠르게 생성함
• 정규화된 인터페이스 (normalized interface)를 통해 여러 제공업체 (providers)를 연결함
• 더 깔끔한 CLI로 리팩터링 (refactor)하는 것을 도와줌
• 제가 아직 구성하지 못했던 스코어링 훅 (scoring hooks; exact-match, LLM-judge, test-runner)을 제안함

실패한 점

• 재사용 가능한 코드 대신 계속해서 "일회성 (one-off)" 스크립트를 작성함
• 경로 처리 (path handling) 버그, 들여쓰기 오류, JSON/CSV 출력 시 필드 누락 발생
• 결국 6개의 서로 다른 스크립트가 compare_models_v3_final_real_final.py와 같은 이름으로 trial/ 폴더에 보관됨
• 사소한 실수들로 인해 API를 여러 번 재실행하게 되었고, 그때마다 조용히 추가 비용이 발생함

경로 버그를 수정하고 동일한 배치 호출 (batch of calls)을 세 번째 재실행했을 때, 배경에서 실험이 돈을 태우고 있다는 것이 느껴졌습니다.

메타 레슨 (meta-lesson)은 잔혹하고도 단순했습니다:

인간이 전체 명세 (spec)를 작성해야 한다. 모든 필드, 모든 출력, 모든 예외 상황 (edge case)까지 말이다.

제가 다음과 같은 내용을 작성하고 나서야:

• CSV에 정확히 어떤 컬럼 (columns)을 원하는지
• 라우팅 테이블 (routing table) YAML이 정확히 어떤 모습이어야 하는지
• 스코어링 (scoring)이 루브릭 차원 (rubric dimensions)에 정확히 어떻게 부착되어야 하는지

LLM은 마침내 유용해졌습니다.

그 전까지 그것은 그저 추측하고 있었을 뿐입니다.

내 하니스 (Harness) 설계는 생각보다 더 성급했습니다

이번 실행 과정에서 숨겨져 있던 또 다른 불편한 깨달음이 있었습니다.