300개 이상의 모델을 테스트했다. 그리고 벤치마크 (Benchmark)를 폐기했다.

Let It Break — part 1
태그: #ai #llm #benchmark #postmortem

지난 5월, 나는 Agent Autopsy라는 시리즈를 진행했다. 에이전트 (Agents)들이 실패하는 과정 — 깨진 패키지 (broken packages), 잊혀진 컨텍스트 (forgotten context), 조용히 죽어버린 크론 잡 (cron jobs) — 을 지켜보며, 내가 무엇을 모르는지조차 모른다는 사실을 배워나갔다. 모든 실패는 사후 분석 (post-mortem)을 거쳤다. 모든 실패가 그럴 만한 가치가 있다고 느껴졌기 때문이다.

그 시리즈는 피날레와 함께 끝난 것이 아니다. 내가 관심을 끊었을 때 끝났다. 여덟 번째 파트쯤 되었을 때, 망가진 것들이 더 이상 비상사태처럼 느껴지지 않았다. 이를 인내라고 부르든, 회복탄력성 (resilience)이라고 부르든. 어쩌면 그냥 지쳤던 것일지도 모른다. 아마 세 가지 모두일 것이다.

그다음에 온 것은 이것이다: 내가 의도적으로 무엇을 죽이는지, 무엇을 의도적으로 망가진 채로 두는지, 그리고 그것이 나에게 무엇을 가져다주는지에 대한 시리즈다. 이 포스트의 그 어떤 것도 실패하지 않았다. 벤치마크 (benchmark)는 내가 그것을 폐기하기 전 저녁까지 완벽하게 작동했다.

당시 나는 아무도 요청하지 않은 SPFx 에이전트 하네스 (agent harness)를 폐기하는 것에 대해서도 글을 썼다. 그 포스트에서 나는 벤치마크 (benchmark)를 사람들이 실제로 원하는 것, 유지할 가치가 있는 것으로 제시했다.

이번 달, 나는 벤치마크 (benchmark) 또한 폐기했다.

같은 교훈. 더 긴 도화선.

그것은 무엇이었나

열 가지의 실제 에이전트 (agent) 코딩 작업 — 파일 작업 (file operations), 쉘 명령 (shell commands), 오류 복구 (error recovery), 데이터 파싱 (data parsing), SQL 쿼리 (SQL queries). OpenRouter를 통해 접근할 수 있는 모든 모델과 내 자체 하드웨어에 담을 수 있는 모든 것을 포함했다. 최대 토큰 (Max tokens) 400, 온도 (temperature) 0.1, 패턴 매칭 점수 산정 (pattern-matching scoring), 불안정한 엔드포인트 (flaky endpoint)가 0점을 속이지 못하도록 하는 사전 검증 (pre-flight verification).

내가 마지막으로 게시한 배치 (batch)는 공개 데이터셋을 168개 모델로 만들었다. 실제 수치 — OpenRouter와 로컬 모델, 그리고 내가 따로 정리하지 않은 배치들을 포함하여 — 는 300개를 넘어섰다.

10개 모델 배치 비용은 약 $0.10였다. 200회 호출 효율성 연구 비용은 $0.56였다. 전체 데이터셋 비용은 배달 음식 한 번 값보다 적었다.

실행하는 것은 저렴하다. 하지만 정직함을 유지하는 것은 비싸다. 나는 수백 개의 모델을 깊이 파고들기 전까지 그 차이를 이해하지 못했다.

벤치마크 (benchmark)가 스스로 자신의 부고를 작성했다

내 헤드라인들을 순서대로 읽어보라.

5월: 가장 성능이 좋은 로컬 모델이 50%를 기록했다. 며칠 후: 다섯 개의 완전히 새로운 모델 제품군이 데뷔했으며, 그중 75% 미만인 모델은 없었다. 그 후: 두 모델이 90%에 도달했으며, 그중 하나는 1페니(penny) 미만의 비용이었다.

50%에서 75% 하한선으로, 그리고 1페니 미만의 가격으로 90%까지. 불과 몇 주 만에 일어난 일이다.

매 배치(batch)의 결론이 "대부분 괜찮고 모두 저렴하다"가 될 때, 리더보드(leaderboard)는 스스로 질문에 답한 셈이다. 실제로 누군가에게 도움이 되었던 마지막 발견은 모델의 품질에 관한 것이 전혀 아니었다 — 그것은 무료 티어 (free tier)가 도박이라는 사실이었다, 동일한 배치 내에서 81.6%와 10%가 나타났다.

흥미로운 질문은 "어떤 모델이 이것을 할 수 있는가"에서 멈췄다. 대부분의 모델이 할 수 있기 때문이다. 질문은 "얼마나 적은 스캐폴딩 (scaffolding)이 필요한가"로 바뀌었다. 리더보드는 그 질문에 답할 수 없다.

내가 무시했던 신호

아무도 그것을 사용하지 않았다.

포스트에는 조회수가 발생했다. 몇 개의 좋은 댓글도 달렸다. 하지만 내 수치를 바탕으로 의사결정을 내리는 사람은 단 한 명도 찾을 수 없었다. 나는 데이터셋 (dataset)이 충분히 커지면 독자들이 찾아올 것이라고 스스로를 다독였다. 데이터셋은 커졌다. 하지만 독자는 여전히 나뿐이었다.

지나고 나서야 보이는 징후가 여기 있다: 공개된 모델 수는 168개에서 멈췄지만, 나는 300개를 넘어 계속 테스트를 진행했다. 나는 더 이상 글로 쓰지도 않을 배치들을 실행하고 있었다. 아무도 읽지 않는 리더보드, 아무도 보지 않는 테스트들로 채워지는 리더보드 — 결국 나조차도 그것들을 거의 들여다보지 않게 되었다.

스스로를 설득해야만 얻을 수 있는 견인력 (traction)은 견인력이 아니다. 리버풀 (Liverpool)을 응원하는 것은 아무런 진전이 없는 시즌 동안 충성스럽게 자리를 지키는 법을 가르쳐준다. 나는 리더보드에 똑같은 충성심을 보였다. 하지만 리더보드는 그럴 자격이 없었다.

사인 (Cause of death)

노후화, 그리고 그것은 구조적인 문제였다. 모델들은 매주 출시된다. 모든 배치는 움직이는 기차를 찍은 사진과 같았다 — 포스트를 작성하는 데 걸리는 시간만큼만 정확했다. 리더보드의 정직함을 유지한다는 것은, 단 한 명의 독자를 위해 나의 개인 시간을 들여 영원히 모든 것을 다시 실행해야 한다는 것을 의미했다.

여기에 개인적인 아이러니가 있습니다. 저는 올해 초에 한 달에 4.57유로의 인프라 비용으로 20개의 에이전트를 실행하는 것에 대해 글을 쓴 적이 있습니다. 그 효율성 덕분에 벤치마크 (Benchmark)가 유효 기간이 지났음에도 불구하고 살아남을 수 있었습니다. 좀비 프로젝트가 유지비로 단 몇 푼의 비용만 들고 크론 (cron)에 의해 스스로 실행될 때, 이를 종료하는 데 필요한 것은 예산이 아니라 '인지 (noticing)'입니다. 저렴한 자동화는 좋은 아이디어를 확장할 뿐만 아니라, (문제를 방치하게 만들기도 합니다.)

그리고 테스트 환경 (Harness)에는 제가 더 이상 보지 못하게 된 타협점들이 있었습니다. 400토큰 제한은 말이 많지만 정확한 모델들에게 불이익을 주었습니다. 패턴 매칭 (Pattern-matching)은 역량만큼이나 형식을 점수에 반영했습니다. 이를 수정한다는 것은 더 많은 테스트 환경을 구축해야 함을 의미했습니다. 모델들은 테스트 환경이 더 공정해지는 속도보다 더 빠르게 발전하고 있었습니다.

저는 모델을 측정하기 위한 스캐폴딩 (Scaffolding)을 구축했습니다. 하지만 모델들이 그 스캐폴딩보다 더 빠르게 성장했습니다. 이것은 엔지니어링의 실패가 아닙니다. 이는 생태계가 광고된 대로 작동하고 있다는 증거이며, 제가 이를 인지하기를 거부하며 매주 스스로에게 비용을 청구하고 있었다는 뜻입니다.

살아남는 것들

습관. 저는 여전히 관심 있는 모든 모델이 출시되는 당일에, 제가 실제로 중요하게 생각하는 작업들을 대상으로 테스트를 수행합니다. 그 반사적인 습관은 벤치마크로부터 생겨났으며, 벤치마크보다 더 오래 지속되었습니다.

발견 사항들. 저는 느낌(vibes)이 아닌 데이터를 통해 알고 있습니다: 코드 품질이 에이전트 역량과 동일하지 않다는 것, "효율적인 코드를 작성하라"는 프롬프트가 대부분의 모델에 아무런 도움이 되지 않는다는 것, 그리고 무료 티어 (Free tiers)는 디버깅 시간으로 비용을 지불하게 만든다는 사실을 말입니다.

아카이브된 데이터. 만약 누군가 진정으로 데이터가 필요하다면, 오후 한나절 만에 MCP를 통해 제공될 수 있습니다. 리더보드가 아닌 쿼리 인터페이스 (Query interface)로서 말이죠. 유지보수도 없고, 매주 다시 실행할 필요도 없으며, 필요할 때 가치를 제공합니다. 동일한 아이디어의 경량화 버전입니다.

테스트 환경 (Harness)은 살아남지 못합니다. 그것이 올바른 순서입니다.

규칙

주말 테스트 환경은 나쁜 아이디어가 저렴한 화이트보드 위에서 죽었습니다. 벤치마크는 모델이 300개를 넘어서며, 더 이상 아이디어가 저렴하지 않게 되었을 때 죽었습니다. 같은 질병이었고, 진단은 나중에 내려졌습니다: "누군가 이것을 찾고 있는가?"라는 질문은 시작할 때 한 번만 던지는 질문이 아닙니다. 무언가를 유지보수하려 할 때마다 던져야 하는 질문입니다.

그것을 없애는 데는 저녁 한 번의 시간이 걸렸습니다. 그것을 유지하는 데는 매주 시간이 걸렸습니다. 저는 그 계산을 부끄러울 정도로 늦게 끝냈습니다.

다음번에는 300개가 아니라 50개의 모델에서 그것을 없애겠습니다.

인내심인가, 회복 탄력성(Resilience)인가, 아니면 그저 지친 것인가? 이번 사례는 지쳐 있었습니다 — 그리고 늦었습니다. 이 시리즈의 다음 포스트들은 제가 의도적으로 망가뜨려 놓은 것들을 다룰 것입니다. 그것들은 방어하기가 더 어렵습니다. 그렇기에 글을 쓸 가치가 있습니다.