무료 초안 볼륨 vs 유료 첫 시도: 에이전트 SQL 예산에 대한 논쟁

제 연구실의 야간 분석 작업은 일반 영어 질문을 SQL로 변환하며, 모든 초안은 사람이 보기 전에 리허설 데이터베이스를 통과해야 합니다. 이 루프를 3주 동안 실행한 후, 팀 내부의 논쟁은 프롬프트 설계에 관한 것이 아니었습니다. 예산이 어디에 할당되어야 하는지에 관한 것이었습니다. 즉, 저렴한 등급으로 더 많은 초안을 만들 것인가, 아니면 비싸지만 적은 수의 더 나은 초안을 만들 것인가입니다.

아래 숫자는 제품 벤치마크가 아닙니다. 왜냐하면 저는 귀하의 스키마나 작업을 측정할 수 없기 때문입니다. 여기에 있는 모든 것은 직접 실행해야 하는 장치(harness)이며, 제가 주장하는 유일한 내용은 방법론과 그로 인해 생성되는 의사결정 규칙에 관한 것입니다.

입장 A: 초안의 폭(draft breadth)이 병목 지점이다

첫 번째 입장은 생성이 검토에 비해 저렴하므로, 루프는 감당할 수 있는 한 많은 독립적인 초안을 구매해야 한다는 것입니다. 만약 어떤 작업이 올바른 첫 시도일 확률이 12%라면, 열 번의 시도는 적어도 하나가 통과할 확률이 약 72%가 되며, 이 산술적 계산이 전체 논거입니다. 폭(Breadth)은 운 좋은 단발성 기회를 엔지니어링 프로세스로 바꾸지만, 각 시도가 거의 비용이 들지 않을 때만 작동합니다.

여기서 무료 모델 접근과 무료 서버 옵션은 할인이 아니라 기술적인 논거가 됩니다. 무료 초안 등급에 무료 리허설 호스팅이 결합되면, 열한 번째 시도의 한계 비용(marginal cost)이 0이 되므로, 귀하의 accept@k 곡선은 청구서보다는 벽시계 시간(wall-clock time)에 의해 제한됩니다. 오픈 소스 프로젝트로 소개하는 MonkeyCode는 이러한 조합을 광고합니다: 무료 모델 접근과 무료 서버 옵션이며, 저에게 인용된 토큰 할당량은 작성 시점 기준으로 1천만 토큰입니다.

공개 고지: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 준비되었습니다.

어떤 공개된 할당량도 계약이라기보다는 스냅샷으로 취급하십시오. 왜냐하면 할당량, 모델 버전 및 가용성은 협상 없이 변경되기 때문입니다. 어떤 무료 용량을 가지고 있든, 모델 식별자(model identifier)와 응답 해시(response hash)를 사용하여 로그에 기록하여, 조용한 모델 교체가 미스터리한 사건이 아니라 accept rate의 단계적 변화로 나타나게 하십시오.

입장 B: 검증이 병목(bottleneck)이다. 따라서 저렴한 초안은 부채를 만든다

두 번째 입장은 덜 매력적입니다. 이 입장에 따르면 진정한 제약 조건은 사람이 하루에 얼마나 많은 변경 사항을 검증할 수 있는지이며, 저렴한 초안은 단순히 비용을 청구서에서 검토자에게로 이동시킬 뿐입니다. 실행에 실패하는 초안은 폐기하기가 무료이지만, 파싱하고 실행하여 잘못된 답변을 반환하는 초안은 비쌉니다. 왜냐하면 오직 사람이 그것을 알아차리기 때문입니다.

이러한 관점에서 볼 때, 토큰당 비용(cost per token)은 허세 지표(vanity metric)이며, 승인된 초안당 비용(cost per accepted draft)은 주의를 산만하게 하는 요소입니다. 중요한 숫자는 사람이 그럴듯한 SQL을 거부하는 데 쓰는 시간을 포함하여, 하나의 병합된 변경 사항에 대한 총비용입니다. 광범위함(breadth)은 특정한 방식으로 이를 악화시킵니다: 구조적 검증기(structural verifier)를 통과하고 인간의 대기열까지 도달하는 의미적으로 잘못된 쿼리 수를 곱하기 때문입니다.

입장 A에 대한 반대 증거는 여러분 자신의 로그에서 쉽게 찾을 수 있으며, 이는 실패 이유들의 분포처럼 보입니다. 만약 실패가 파싱(parse)과 실행(execution) 단계에 집중되어 있다면, 검증기가 이를 흡수하고 광범위함은 거의 무료입니다. 하지만 실패가 '유효한 SQL이지만, 잘못된 단위(wrong grain), 잘못된 조인(wrong join), 잘못된 필터(wrong filter)'에 집중되어 있다면, 광범위함은 검토 작업을 줄이기보다는 곱하는 것입니다.

아티팩트: 두 입장을 모두 측정하는 하네스

아래의 하네스는 예시적이며 이 기사를 위해 실행되지 않았습니다. 여러분 자신의 작업 세트와 엔드포인트에 대해 이를 실행해 보십시오. Python과 sqlglot, requests 패키지가 필요하며, 리허설 데이터베이스를 위해 Docker가 추가로 필요합니다.

1단계 - 오라클을 사용하여 작업 세트를 고정(freeze)합니다. 25개의 작업을 작성하고 각각에 정확한 행 수 또는 정렬된 결과에 대한 체크섬과 같은 기계가 검사할 수 있는 기대치를 부여하십시오. 오라클 없이는 실행 실패와 의미적 실패를 분리할 수 없으며, 전체 결정은 의견으로 되돌아갑니다.

2단계 - 폐기 가능한 리허설 데이터베이스를 프로비저닝합니다. 임시 Postgres 컨테이너를 시작하고, 스키마와 픽스처(fixtures)를 로드하며, 모든 초안을 BEGIN ... ROLLBACK 내부에서 실행하여 하나의 픽스처가 모든 시도에 사용되도록 합니다.

docker run --rm -d --name rehearsal -p 55432:5432 -e POSTGRES_PASSWORD=postgres postgres:16-alpine
psql postgresql://postgres:[email protected]:55432/postgres -f schema.sql -f fixtures.sql
export REHEARSAL_DSN=postgresql://postgres:[email protected]:55432/postgres

Step 3 - 하나의 설정 파일에서 백엔드를 설명합니다. 무료 등급(free tier)과 유료 엔드포인트는 보통 동일한 chat-completions 형태를 사용하므로, 단일 함수로 둘 다 구동할 수 있습니다. 식별자(identifiers)와 가격은 본인의 것으로 대체하세요. 아래 값들은 제품 사실이 아닌 자리 표시자(placeholders)입니다.

[
  {"name": "free-hosted", "url": "https://<host>/v1", "key_env": "FREE_KEY",
   "model": "<model-id>", "usd_per_mtok": 0.0},
...

유료 엔드포인트의 usd_per_mtok는 본인의 청구서(invoice)에서 가져오고, 무료 등급의 이용 약관 및 할당량(quota)을 확인한 후에만 이 값을 0으로 유지하세요.

Step 4 - 시도마다 하나의 JSONL 행을 초안 작성(draft), 검증(verify), 로깅합니다. 검증기(verifier)는 다음 순서로 세 가지 검사를 수행합니다: 단일 구문으로 파싱, 짧은 구문 시간 제한 하에 실행, 그리고 작업 오라클(task oracle)과 비교하는 것입니다.

import json, os, subprocess, time, sqlglot, requests

def draft(backend, schema_card, prompt, attempt):
...

Step 5 - 시도들을 하나의 비교 테이블로 줄입니다. 백엔드별로 그룹화하여 수락률(accept rate), 승인된 초안당 비용(cost per accepted draft), 그리고 p95 지연 시간(latency)을 계산합니다. 이렇게 하면 두 입장 모두 형용사 대신 숫자로 주장할 수 있습니다.

def summarize(rows):
    stats = {}
    for row in rows:
...

의사결정 규칙 (The decision rule)

동일한 25개의 작업을 두 백엔드 모두에 대해 실행하고, 검토 과정에서 방어할 수 있는 공식으로 하나의 규칙을 적용합니다.

tco_per_merged_change =
    (draft_usd + verify_usd + review_minutes * review_usd_per_min) / accepted

review_minutes는 추측이 아니라 풀 리퀘스트(pull-request) 기록에서 가져와야 하며, 대부분의 팀에서는 이 항이 방정식에서 가장 큰 비중을 차지합니다. 그런 다음 아래 분기(branches)를 적용하여 이념 대신 구성을 선택하세요.

제한 사항 및 사용을 지양해야 할 경우

개별 작업(per-task) 오라클을 작성할 수 없다면 폭 우선 루프(breadth-first loop)를 건너뛰세요. 그렇지 않으면 감지하지 못하는 실패를 정확히 곱하게 됩니다. 스키마 카드나 샘플 행이 해당 제공업체를 다루는 데이터 처리 계약에 포함되지 않는 경우, 호스팅되는 무료 티어는 사용을 건너뛰고 첫 감사 이후가 아니라 요청 전에 약관을 확인하세요.

게시된 할당량(quota)을 기준으로 예산을 계획하지 말고, 무료 티어가 영구적이라고 가정하지 마세요. 제공업체 변경 후에는 항상 하네스(harness)를 다시 실행하세요. 왜냐하면 수용률 기록이 여러분이 얻을 수 있는 유일한 조기 경고이기 때문입니다.

이 워크플로우는 단발성 스키마 마이그레이션에도 적합하지 않습니다. 그 경우 검토가 유일한 게이트이며, 10개의 저렴한 초안은 단순히 검토자에게 틀릴 수 있는 열 가지 방법을 제공할 뿐입니다.

초당 비용을 지불하지 않고 폭 우선 분기(breadth-first branch)를 테스트하고 싶다면, 무료 티어가 하네스를 작동시키는 가장 저렴한 방법입니다. 이를 채택하기 전에 동일한 오라클과 동일한 결정 규칙으로 측정해 보세요.