저는 대부분의 시간을 에이전트 시스템(agentic systems)에 할애하며, 다른 모든 사람들이 가진 것과 동일한 생각을 흡수해 왔습니다. 즉, 플래너(planner)가 상황을 개선하고, 판사(judge)를 동반한 초안 작성자(drafters) 패널이 이를 더욱 개선한다는 생각입니다. 이는 분명 사실처럼 들립니다. 더 많은 사고, 더 많은 검토가 더 나은 답변을 만들어낸다는 것이죠.

하지만 저는 이를 한 번도 측정해 본 적이 없습니다. 그래서 측정할 수 있는 무언가를 만들었고, 그것을 제 자신의 설정에 적용해 보았는데, 결과는 제 생각과 달랐습니다.

결과

단 한 번의 스윕(sweep). 20개의 코딩 작업, 3가지 하네스(harness) 형태, 실제 모델들, 비용은 0.99달러였습니다.

제가 더 중요하게 생각하는 부분

도구가 실제로 말해준 내용은 다음과 같습니다:

단 3개의 작업만이 두 방식을 갈라놓았습니다. 3개의 작업이 압도적으로 차이 나더라도 p<0.05를 충족할 수 없으므로, 이 스위트(suite)는 이들 사이의 우열을 결정할 수 없습니다 — 이는 스위트의 한계이지, 하네스에 대한 발견이 아닙니다.

패널은 22배 더 많은 비용이 들고 스위트는 그들 사이의 차이를 결정할 수 없습니다 — 이 증거에 따르면 추가 지출은 아무런 이득을 주지 못합니다.

95% 대 80%는 결정적인 결과처럼 보입니다. 하지만 그렇지 않습니다. 20개의 작업 중 17개는 동점이었으므로, 오직 3개의 작업만이 정보를 담고 있었습니다. 그리고 3개의 불일치하는 작업은 한쪽이 모두 이기더라도 통계적 유의성(significance)에 도달할 수 없습니다. 리더보드(leaderboard)였다면 두 숫자를 출력하고 제가 패널이 더 나쁘다고 결론 내리게 방치했을 것입니다. 그것은 데이터가 뒷받침하는 것보다 더 강력한 주장(claim)이 되었을 것입니다.

따라서 정직한 해석은 더 좁지만 더 유용합니다:

• 이 스위트에서 패널이 도움이 된다는 증거가 없습니다.
• 패널은 22배 더 많은 비용이 들고 8배 더 오래 걸리며, 이는 추론이 아닌 측정된 사실입니다.
• 이것이 진정으로 더 나쁜 것인지 확인하려면 20개보다 더 많은 작업이 필요합니다.

이것들은 세 가지 서로 다른 문장입니다. 대부분의 평가 도구(eval tooling)는 이들을 하나의 순위로 뭉뚱그려 버립니다.

스위트(suite)의 크기가 실제 제약 사항인 이유

20개의 태스크(task)는 점수를 5점 단위로 움직입니다. 이것이 바로 테스트가 결론을 내릴 수 없는 근본적인 이유입니다. 측정 도구의 해상도(resolution)가 측정하려는 효과보다 더 거칠기 때문입니다. 해결책은 더 나은 통계가 아니라 더 많은 태스크입니다. 이것이 바로 이 도구가 사용자가 직접 자신의 스위트(suite)를 가져올 수 있게 허용하며, 스위트를 붙여넣을 때 각 태스크가 몇 점의 가치가 있는지 알려주는 이유입니다.

이는 지난달 제 드리프트 보드(drift board)가 저에게 가르쳐준 것과 같은 교훈입니다. 당시 네 개의 "회귀(regressions)"는 알고 보니 속도 제한(rate limits)과 단일 질문의 노이즈(noise)로 밝혀졌습니다. 작은 스위트는 확신에 찬 헛소리(confident nonsense)를 만들어냅니다.

작동 방식

하네스(harness) 설정은 데이터입니다 — 역할(roles), 모델(models), 프롬프트(prompts), 그리고 토폴로지 그래프(topology graph)로 구성됩니다. 사용자가 형태를 그리거나 JSON을 붙여넣을 수 있으며, 각 방식은 서로를 바라보는 다른 뷰(view)일 뿐입니다. 변경하고자 하는 축(axes)을 선언하면 매트릭스(matrix)를 실행합니다.

점수 산정(Scoring)은 결정론적(deterministic)입니다. 술어(Predicates)가 생성된 코드를 실행하고 판결을 반환합니다. 어떠한 모델도 점수를 매기지 않습니다. 따라서 점수가 변했다는 것은 판정관의 컨디션이 변한 것이 아니라 시스템이 변했다는 것을 의미합니다. 페이지에는 어시스턴트(assistant)가 있으며, 이 어시스턴트는 점수를 읽고 설명할 수는 있지만, 절대로 점수를 생성할 수는 없습니다.

비교는 두 평균을 비교하는 것이 아니라, 태스크별(per-task)로 짝을 지어(paired) 이루어집니다. 두 형태 모두 동일한 20개의 태스크를 실행하므로, 질문은 "한쪽이 얼마나 많은 태스크에서 승리했는가"가 됩니다. 이는 평균을 비교하는 것보다 이 정도의 표본 크기에서 훨씬 더 강력한 힘을 가집니다. 이 테스트는 정확한 부호 검정(exact sign test)입니다. 정규성 가정(normality assumption)도, 분산 가정(variance assumption)도 없으며, 방향성을 갖지 않는 동점(ties)은 제외됩니다.

사용자의 키(key)는 브라우저에 머뭅니다. 백엔드는 정화된 트레이스(sanitized traces)를 수신하며, 경계 지점에서 키 형태를 띤 모든 것을 거부합니다. 페이지는 전송되는 정확한 바이트(bytes)를 보여주며, 패널을 믿기보다는 사용자의 네트워크(Network) 탭을 직접 확인하라고 안내합니다.

기록해둘 만한 가치가 있는 벤더(vendor)의 세부 사항이 하나 있는데, 제게 한 시간을 허비하게 만들었습니다. api.openai.com은 CORS 프리플라이트(preflight) 요청에 올바른 헤더로 응답하지만, 실제 응답에서는 access-control-allow-origin을 누락합니다. 따라서 API 키가 아무리 유효하더라도 브라우저 직접 호출(browser-direct call)은 거부됩니다. Anthropic은 의도적으로 이를 허용합니다. 그것이 바로 anthropic-dangerous-direct-browser-access가 존재하는 이유입니다. curl -X OPTIONS로 프리플라이트만 테스트하면 성공으로 나타나기 때문에 오해를 불러일일 수 있습니다.

과장하지 않기 위해, 이 도구의 위치를 정의하자면

하네스(Harness) 및 프롬프트 비교(prompt-comparison) 도구는 새로운 카테고리가 아닙니다. promptfoo, LangSmith, Braintrust 등이 모델 및 프롬프트 비교를 수행하며, 그중 몇몇은 이보다 훨씬 더 넓은 범위를 다룹니다. 여기서 제가 다루는 좁은 영역은 교차점입니다: 브라우저 기반의 BYOK(Bring Your Own Key), 결정론적인 No-LLM-judge 채점, 그리고 판단할 수 없을 때 이를 보고하는 비교 기능의 결합입니다.

이 과정에서 치른 대가

0.99달러와 약 5분. 제가 더 낫다고 가정해 왔던 아키텍처가 — 이 증거에 따르면 — 더 낫지 않으며, 확실히 더 비싸다는 사실을 알아내는 데 걸린 비용입니다.

차라리 미리 아는 편이 낫습니다.

도구: https://github.com/egnaro9/never-touch-ai — 하네스를 설계하고 스윕(sweep)하세요. API 키가 전혀 없는 모의 기질(mock substrates) 위에서 무료로 실행됩니다.

원시 결과(Raw result): results/sweep_2026-07-25.json — 위의 모든 수치는 이 파일로부터 계산되었으므로 직접 확인할 수 있습니다.

심층 분석: 현장 기록(the field note) — 그래프 실행 모델, 이것이 왜 부호 검정(sign test)인지, 그리고 실제 실행 중에 발견된 두 가지 버그에 대해 다룹니다.

제작: Erik Hill · https://egnaro9.github.io