태스크 오케스트레이터(Task Orchestrator)를 만들었다가 최고의 수치를 삭제한 경험
요약
태스크 오케스트레이터 ORA 개발자가 가상의 절약 수치를 삭제하고 실제 실행 비용을 측정하도록 시스템을 개선한 경험을 다룹니다. 단순한 비용 계수 비교가 아닌, 토큰 사용량 기반의 진실된 지표가 왜 중요한지 설명합니다.
핵심 포인트
- 가상의 시나리오를 기반으로 한 'X% 절약' 지표는 왜곡된 정보를 제공할 수 있음
- 모델별 토큰 효율성을 고려하지 않은 단순 비용 계수 비교의 위험성
- 가정(counterfactual) 대신 실제 API 반환 토큰 기반의 비용 측정 권장
- 측정 지표는 화려한 수치보다 실제 의사결정에 유용한 진실성을 가져야 함
Tags: #ai #agents #golang #opensource
ORA는 다음과 같습니다: 하나의 Go 바이너리로, 태스크를 받아 하위 태스크로 분해하고, 각 태스크를 실제로 수행할 수 있는 가장 저렴한 모델로 라우팅하며, 실행하고, 결과를 조정합니다. Claude Code, Codex, Pi, Cursor, Cline, Hermes 등과 함께 작동하거나 독립적으로 사용할 수 있습니다.
go install github.com/vystartasv/ora/cmd/ora@latest
ora "build a login system with JWT"
...
이것이 발표 내용입니다. 더 유용한 부분은 다음과 같습니다: README는 예전에 훨씬 좋은 수치로 시작했는데, 배포 이틀 전에 제가 삭제했습니다.
그 수치(The number)
원래의 README에는 실행 비용이 플래그십 모델(flagship model)에 모든 것을 보내는 것보다 68% 저렴하다고 주장되어 있었습니다. 보기 좋았습니다. 눈에 가장 먼저 들어오는 것이었습니다.
하지만 그것 역시 가짜였습니다 — 사기적인 의미가 아니라, 더 나쁜 의미로 말하자면: 조용히 측정치처럼 자리매김한 작업 예시였을 뿐입니다. 저렴한 하위 태스크 1개, 중간 난이도 3개, 플래그십 모델 1개. 비용 계수(Cost factors)가 각각 1, 2, 그리고 10이었습니다. 50단위 대신 17단위였습니다. 66%였던 것이 어딘가를 거치며 반올림되어 68%가 되었고, 그 이후로는 아무도 의문을 제기하지 않았습니다.
아무도 측정하는 것이 없었습니다. README의 다이어그램이 바로 증거였습니다.
왜 수정이 수정이 아니었는가(Why the fix wasn't a fix)
첫 번째 본능: 모델을 문서화하고, 재현 가능하게 만드는 것입니다. 저는 비용 계수표를 추가하여 누구나 산술 계산을 다시 실행해 같은 수치에 도달할 수 있도록 했습니다.
그러고 나서 당연히 던져야 할 질문, 즉 제가 먼저 물어봤어야 할 질문이었습니다: 플래그십 모델은 토큰당 단순히 더 비싼 것만이 아니라, 토큰당 더 많은 작업을 수행합니다. 저렴한 모델은 2,000개의 토큰을 사용하고 틀리게 되어 두 번 재시도할 수 있습니다. 플래그십 모델은 400을 사용하며 맞힐 수도 있습니다. 하위 태스크(subtask)당 비용 계수는 이것들이 같은 사건인 것처럼 가장합니다.
따라서 이 지표는 부정확한 것이 아니었습니다. 저를 기쁘게 하는 방향으로, 잘못된 것을 측정하고 있었습니다. ORA가 내린 모든 라우팅 결정은 절약처럼 보였습니다. 왜냐하면
아닙니다. 절약이라는 관점에서는요. ORA에는 더 이상 절약 비율이 없습니다. 저는 보고서 구조(report struct)에서 해당 필드를 삭제했고, orchestrate.go의 계산 로직을 제거했으며, README에서도 관련 표를 지웠습니다.
대신 남아있는 것은 작고 진실한 수치입니다: 실제 실행 비용(actual run cost). 모든 서브태스크의 실제 토큰 사용량이 API로부터 반환됩니다. 이를 모델당 실제 가격에 곱하면 됩니다. 그 실행 비용을 출력하는 겁니다.
5 subtasks · 4 models · $0.0038
가정(counterfactual)이 없습니다. 비교할 가상의 플래그십 전용 실행 결과도 없습니다. 오직 당신이 지출한 비용만 있습니다.
이 수치는 덜 화려하지만, 훨씬 더 유용합니다. 만약 이 도구를 도입할지 결정하는 중이라면, 이론적으로 어떤 구성을 사용했을 때 얼마나 절약했는지(절대 실제로 실행하지 않았을 구성)가 아니라, 당신에게 실제 얼마의 비용이 드는지를 알아야 합니다.
근본적인 규칙
실행되지 않은 가상의 시나리오를 상상해야 하는 모든 측정 지표는 측정이 아닌 이야기입니다.
절약 주장은 본질적으로 가정(counterfactual)에 기반합니다. 현재 AI 툴링 분야의 대부분의 'X% 더 빠르다' 또는 'Y% 더 저렴하다'라는 수치들 역시 마찬가지입니다. 여기에는 이번 달에 읽으신 많은 내용들이 포함됩니다. 이들은 발생한 일과 누군가 가정했던 일을 비교하는데, 그 가정을 발표하는 사람이 항상 선택합니다.
실제 비용(Actual cost), 실제 토큰 사용량(actual tokens), 실제 지연 시간(actual latency): 이것들은 그냥 출력할 수 있는 것입니다. README에 들어갈 숫자의 기준은, 당신이 하는 말 중 어떤 것이든 믿지 않는 낯선 사람도 그것을 재현할 수 있어야 합니다.
ORA가 실제로 하는 일
이제 과장할 것이 아무것도 없으므로:
- 분해(Decompose) — LLM이 당신의 작업을 독립적이고 검증 가능한 서브태스크로 분리합니다.
- 라우팅(Route) — 각 서브태스크는 그 유형에 맞는 가장 저렴한 모델 계층으로 이동합니다 (조회 및 리서치는 저가형; 코드 생성 및 리뷰는 중급형; 디버깅 및 아키텍처는 플래그십).
- 위임(Delegate) — 서브 에이전트를 생성하거나 CLI 에이전트를 호출하며, 그래프가 허용하는 범위 내에서 병렬로 처리합니다.
- 압축(Compress) — 프롬프트와 출력물에서 불필요한 내용을 제거합니다.
- 조정(Reconcile) — 검증하고, 병합하며,
.ora-report.json으로 보고합니다.
ORA.md 파일을 규칙 파일(rules file)을 읽는 모든 에이전트에 넣으면 동일한 워크플로우를 학습합니다 — CLAUDE.md, .cursor/rules/, .clinerules/, Copilot 지침, Hermes 스킬 등.
라우팅(Routing) 자체가 핵심 아이디어입니다. 모든 서브태스크가 세상에서 가장 좋은 모델일 필요는 없으며, 라우팅 결정은 그렇지 않으면 매번 수동으로, 잘못 내리게 되는 것입니다.
GitHub: vystartasv/ora — MIT 라이선스, 단일 Go 바이너리, v0.1.0.
허용 오차(Tolerance), 복원력(resilience), 아니면 그냥 피곤함? 어느 것도 아닙니다 — 이번 것은 제때 포착되었습니다. 간신히요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기