세 가지 모델, 세 가지 의견, 그리고 0달러

몇 주 전만 해도 저는 도구에 결정에 대한 "제2의 의견 (second opinion)"을 물을 때마다 약 1.50달러를 지불하고 있었습니다. 세 번의 모델 호출, 각각 약 50센트 상당의 토큰(tokens) 비용이 하루에도 여러 번 발생했습니다. 청구서상으로는 미미한 금액이었지만, 합산해 보면 코드를 생성하지도 않으면서 가장 많은 비용을 쓰는 습관이었습니다.

이번 주에는 동일한 세 가지 의견을 얻는 데 추가 비용이 전혀 들지 않았습니다. 동일한 이름의 모델, 동일한 프롬프트(prompts)를 사용하지만, 저는 이미 월 정액 요금을 지불하고 있는 구독 서비스를 통해 확인 과정을 라우팅(routing)합니다. 따라서 추가적인 자문이 청구 금액을 높이지 않습니다. 이 라우팅은 5분이면 끝나는 간단한 기술이며, 곧 설명하겠습니다. 하지만 이 기술보다 더 가치 있는 것은 제가 왜 하나의 모델 대신 세 개의 모델을 실행하는가 하는 "이유"입니다. 왜냐하면 그것이 제가 결과물로 내놓는 것의 품질을 실제로 변화시켰기 때문입니다.

하나의 모델이 당신에게 동의하는 것은 검토가 아니다

저는 예전에 하나의 강력한 모델을 결정 사항에 적용하고 그 답변을 검토(check)로 취급하곤 했습니다. 하지만 그것은 검토가 아닙니다. 단일 모델은 틀리는 방식이 일관적이며, 당신이 작성한 내용을 검증하도록 프롬프트를 입력하면 당신의 의견에 동의할 수 있는 해석을 찾아내는 경향이 있습니다. 당신은 검토를 받는 것이 아니라, 확신에 찬 메아리(echo)를 듣게 되는 것입니다.

이런 생각을 깨뜨린 것은 제가 자신의 지식 베이스(knowledge base)에 거의 반영할 뻔했던 규칙 하나였습니다. 저는 "긴 입력값에 대한 누적 계산 시 모델을 신뢰하지 마라"와 같은 내용을 적어두었습니다. 큰 문서 전체에서 합계가 틀려지는 것을 목격하고 이를 자연 법칙처럼 일반화했던 것입니다. 이 규칙의 타당성을 확인해 달라는 요청을 받은 하나의 모델은 기꺼이 동의했습니다. 그 모델 역시 동일한 실패 사례를 본 적이 있었기 때문입니다.

그 후, 저는 동일한 주장을 다른 계열(family)의 모델에게 던져보았습니다. 그 모델은 즉시 반박했습니다. 그러한 실패 모드(failure mode)는 특정 계열과 프롬프트 형태에 국한된 것이지, 언어 모델(language models)의 보편적인 특성이 아니며, 재현되지 않는 사례가 여기 있다는 것이었습니다. 그 모델이 옳았습니다. 저는 특정 벤더(vendor)의 특이 사항을 일반적인 진리로 격상시켜 미래의 제가 그에 따라 행동하게 만들 뻔했습니다. 만약 동일한 계열의 모델로부터 제2의 의견을 들었다면 아마 잡아내지 못했을 것입니다. 왜냐하면 그 사각지대(blind spot)를 공유하고 있기 때문입니다.

제 경험상 실패는 여기저기 흩어져 있지 않습니다. 벤더(vendor)별로 뭉쳐서 나타납니다. 서로 다른 계열의 모델 두 개가 동일한 부분에 대해 반대 의견을 낸다면, 그곳이 바로 제가 실제로 주의 깊게 읽어야 할 지점입니다.

제가 실제로 실행하는 방식

의도적으로 최소 두 개 이상의 서로 다른 계통에서 가져온 세 가지 목소리를 활용합니다:

• GPT급 모델 (한 벤더의 추론 계통)
• 중간 단계의 Claude (Sonnet)
• 최상위 단계의 Claude (Opus)

세 모델 모두에게 동일한 프롬프트(prompt)를 전달합니다. 저는 각 모델에게 단순히 결론만을 묻는 것이 아니라, 결론과 함께 *그 근거(reasoning)*를 요구합니다. 근거를 확인해야만 두 개의 "예"가 실제로 동의하는 것인지, 아니면 서로 다른 논리로 우연히 같은 결론에 도달한 것인지를 알 수 있기 때문입니다. 그다음 종합(synthesis)은 제 몫입니다. 위원회(council)가 투표를 하는 것도 아니고, 저는 그들의 의견을 평균 내지도 않습니다. 저는 모델들이 의견이 갈리는 지점을 읽으며, 그곳이 거의 언제나 제가 대충 넘어가려 했던 바로 그 지점입니다.

왜 두 개나 다섯 개가 아닌 세 개일까요? 저에게 다섯 개는 신호(signal)보다는 속도 저하(slowdown)에 더 가까웠습니다. 마지막 두 번의 호출은 대개 처음 세 가지 의견을 단어만 바꿔 표현한 것에 불과하며, 가장 느린 모델을 기다려야 하기 때문입니다. 세 개는 교착 상태를 깨기에 충분하며, 그 이상으로 늘려야 할 이유를 찾지 못했습니다.

라우팅(routing), 그리고 한 가지 주의사항

한계 비용(marginal cost)을 0달러로 만든 부분은 여기입니다. 각 조사를 개별적인 종량제 API 요청(metered API request)으로 청구하는 대신, 이미 고정 요금을 지불하고 있는 구독(subscription)을 활용합니다. 이 방식을 따라 하기 전에 한 가지 솔직한 주의사항을 말씀드리자면, 구독 계정은 대화형 사용을 목적으로 하므로, 이를 크론 잡(cron job)에 연결하기 전에 본인 요금제의 약관을 확인하십시오. 저는 종량제 과금을 피하기 위한 수단이 아니라, 저 자신의 개발을 위해 이 방식을 사용합니다.

# 의사코드(Pseudocode). 실제 버전은 환경 변수(env var)를 키로 사용하는 작은 라우터입니다.

def council(prompt):
...

저에게 반나절을 허비하게 만든 주의사항(gotcha)은 이것입니다. 제 환경에서는 환경 변수에 종량제 API 키가 존재할 경우 claude -p가 해당 키를 우선적으로 사용했는데, 이는 전체적인 목적을 조용히 무너뜨리는 행위였습니다. CLI가 구독 기반의 OAuth 경로로 전환될 수 있도록 자식 프로세스(child process)에서 해당 키를 제거하십시오:

import os, subprocess

def claude_cli(model, prompt):
...

claude -p --model X와 동일한 패턴은 헤드리스 (headless)로 실행되므로, 예약된 위원회 (scheduled council)는 대화형 (interactive) 방식과 동일한 경로를 사용합니다.

아무도 계산해 보지 않는 교차점 (The crossover)

이것이 제 청구서 이상의 의미를 갖는 이유는 다음과 같습니다. 저의 사용량은 두 가지 비용 범주로 나뉘어 있었고, 저는 습관적으로 두 가지 모두를 같은 방식으로 가격을 책정하고 있었습니다.

토큰당 API 과금 (Per-token API billing) 방식은 단발성 (one-shot) 작업에는 저렴하지만, 반복 작업에는 가혹합니다. 정액 구독 (Flat subscription) 방식은 또 다른 형태입니다. 단 한 번의 호출에는 어리석은 선택이지만, 하루 종일 비슷한 종류의 확인 작업을 수행한다면 거의 무료에 가깝습니다. 이 둘의 교차점 (crossover)은 실재하며, 그 지점은 그리 높지 않습니다. 하루에 몇 번의 조사 (probes)만 수행한다면 여전히 종량제 호출 (metered call)이 유리하지만, 제가 실제로 수행하는 볼륨, 즉 대부분의 날에 수십 번의 작은 재검토 (second-opinions)를 수행하는 경우에는 정액제가 압도적으로 유리하며, 제가 항상 수행해야 마땅한 확인 작업을 아껴가며 하지 않도록 도와줍니다.

그래서 저는 검증 (validation)의 설계를 "이 작업이 토큰을 얼마나 소모할 것인가"를 기준으로 하는 것을 멈추고, "이 작업이 어떤 비용 체계를 사용하는가"를 묻기 시작했습니다. 저를 포함한 많은 이들이 여전히 이 작업의 비용을 토큰당 가격으로 책정하곤 하는데, 이는 주로 청구서가 여러분으로 하여금 그 숫자를 주시하도록 훈련시키기 때문입니다.

제가 신경 쓰지 않을 때

위원회는 검증을 하는 것이지, 발명하는 것이 아닙니다. 기존의 아이디어를 확인하는 것이 아니라 새로운 아이디어가 필요한 진정으로 참신한 문제의 경우, 3자 위원회 (three-way committee)는 잘못된 도구입니다. 왜냐하면 위원회는 수렴 (converge)하기 때문이며, 실제로 막혔을 때 가장 원치 않는 것이 바로 수렴입니다. 그리고 단 한 번만 내릴 진정한 단발성 (one-shot) 결정의 경우에는 종량제 API 호출로도 충분합니다. 구독 방식의 라우팅 (subscription routing)은 하루 종일 이 작업을 수행할 때만 제 값을 합니다.

하지만 일상적인 질문들 — "이 규칙이 너무 광범위한가?", "이 수정 사항이 증상만을 다루고 있는 것은 아닌가?", "내가 명백한 무언가를 놓치지는 않았나?" — 에 대해서는, 저에게 동의하는 한 모델보다 그것을 쪼개어 분석하는 세 개의 모델이 더 낫습니다. 그리고 이제 한계 비용 (marginal cost)이 들지 않기 때문에, 저는 50센트를 아끼려고 스스로를 설득하는 대신 실제로 이 작업을 실행합니다.

Fillip Kosorukov는 약물 사용 심리학 분야의 동료 검토(peer-reviewed) 연구를 공동 저술하였으며(Journal of Substance Use, 2023; PMID: 37275205; 뉴멕시코 대학교(University of New Mexico), 심리학 학사, Summa Cum Laude, 2020), 현재는 창업자 주도형 소프트웨어(founder-led software)를 구축하고 있습니다. 더 자세한 내용은 fillipkosorukov.net 또는 ORCID 0009-0004-1430-2859에서 확인할 수 있습니다.