비싸게 만들고 싸게 돌린다: 스킬 비용을 매일 밤 깎는 법

에이전트를 운영하는 팀이라면 매달 청구서에서 같은 장면을 봅니다. 토큰 비용의 대부분이 프론티어 모델에서 나오는데, 정작 그 모델이 하는 일의 상당수는 창의적 난제가 아닙니다. 메일을 분류하고, 뉴스를 매칭하고, 표를 렌더링하고, 출력이 규격을 지켰는지 검사하는 일이 대부분입니다. 이 글은 엔지니어링 리더와 AI 팀을 위한 것입니다. 스킬을 비싼 모델로 만든 뒤 싼 모델로 내려도 품질이 유지되는지 어떻게 판단하고, 그 판단을 어떻게 매일 밤 자동으로 돌리는지를 실제 측정치와 함께 다룹니다.

결론부터 말하면 이렇습니다. 비싼 모델은 스킬을 처음 만들 때만 필요합니다. 일단 완성한 스킬의 포맷을 코드로 내리면, 실제로 돌리는 일은 훨씬 싼 모델로 충분합니다. 그리고 “충분한지”는 사람의 직관이 아니라 코드가 측정한 결과로 판정해야 합니다.

대부분의 업무는 프론티어 모델이 필요 없다

에이전트가 하루에 처리하는 일을 뜯어보면 성격이 갈립니다. 한쪽에는 진짜 어려운 추론이 있습니다. 애매한 아키텍처 결정, 미묘한 디버깅, 처음 보는 문제의 분해 같은 것들입니다. 다른 한쪽에는 정형화된 반복 작업이 있습니다. 라우팅, 분류, 요약, 렌더링, 규격 검사가 여기 속합니다. 문제는 두 종류를 같은 프론티어 모델에 몰아넣고 매번 최고가로 결제한다는 데 있습니다.

정형화된 작업의 품질은 사실 모델 지능보다 가드레일이 좌우합니다. 출력 포맷이 흔들리는 이유는 모델이 멍청해서가 아니라, 포맷을 산문으로 “부탁”했기 때문입니다. 길이 상한, 허용 enum, 렌더링 규격, 통과 기준을 코드가 강제하면 그 작업은 값싼 모델로도 안정적으로 나옵니다. 품질을 지키는 것은 더 비싼 모델이 아니라 코드 게이트입니다.

비싸게 만들고, 포맷을 코드로 내리고, 싸게 돌린다

우리가 실제로 쓰는 패턴은 세 단계입니다.

먼저 스킬을 비싼 모델로 완성합니다. 처음에는 판단의 여지가 많고 실패 사례를 발라내야 하므로 좋은 모델이 값을 합니다. 다음으로 스킬의 결정론적인 부분을 코드로 뽑아냅니다. 렌더링, enum 정규화, 길이 검사, 중복 제거, JSON 조립처럼 모델이 매번 다르게 풀 필요가 없는 것들입니다. 마지막으로 워커 모델을 싼 티어로 내립니다. 이제 모델은 본문 콘텐츠만 생성하고, 숫자와 포맷과 판정은 코드가 소유하기 때문입니다.

이 패턴이 왜 안전한지 실제 코드로 보여드리겠습니다. 아래는 트위터 타임라인을 슬랙으로 정리하는 스킬의 검증 게이트를 실제 산출물에 돌린 결과입니다. 이 스킬은 하루 다섯 번, 누적 1,000건이 넘는 레코드를 만들어 왔고, 예전에는 트윗마다 Opus를 썼지만 지금은 Sonnet으로 돌아갑니다.

$ tweet_validate.py --dir outputs/twitter/hjguyhan
validated: 2/2 passed; decisions=1 (code-capped)
{"status": "ok", "passed": 2, "total": 2, "decisions": 1, "failed_ids": []}

여기서 글자 수, 링크 수, 상태 enum, 통과 여부는 모델이 주장한 값이 아니라 코드가 실제 문자열에서 다시 계산한 값입니다. 판정 플래그도 코드가 상위 몇 개로 잘랐습니다. 이 게이트는 어떤 모델이 콘텐츠를 썼든 똑같이 동작합니다. 그래서 워커를 Opus에서 Sonnet으로 내려도 품질이 흔들리지 않았습니다.

영업 CRM 브리핑도 같은 구조입니다. 아래는 데이터 JSON을 넣으면 코드가 슬랙 포맷을 그대로 찍어내는 렌더러의 실제 출력입니다.

$ sales_crm_render_brief.py --data brief.json --print-slack
:sunny: *ThakiCloud 영업 데일리 브리프* — 2026-07-03 (목)
*③ 긴급 액션*
1. [A사] GPU 증설 RFP 마감 임박 <전자신문 2026-07-02>
...

헤더 번호, 링크 문법, 쓰레드 구조는 전부 코드가 붙입니다. 그래서 오케스트레이션과 포맷은 Sonnet과 코드로 내려가 있고, 고객에게 직접 나가는 문안 생성만 의도적으로 상위 모델을 유지합니다. 어디를 내리고 어디를 남길지가 뒤섞이지 않습니다.

비용 최적화 스킬: 측정하고, 내리고, 되돌린다

포맷을 코드로 내렸다면 다음 질문은 “그래서 이 스킬은 정말 싼 모델로 내려도 되는가”입니다. 이걸 사람이 눈대중으로 판단하면 안 됩니다. 그래서 스킬을 대상으로 실제 작업을 싼 티어와 현재 티어에 각각 돌려보고, 코드가 그 결과를 채점해 판정하는 비용 최적화 스킬을 만들었습니다.

동작은 단순합니다. 대표 작업 하나를 정해 싼 모델과 현재 모델에 각각 실행하고, 심판 모델이 차원별 점수만 매기면, 코드가 그 점수로 판정을 계산합니다. 진짜 추론 격차가 없고 전체 점수 차가 임계 안이면 강등하고, 추론 격차가 있으면 그대로 둡니다. 강등은 중앙 정책 파일에 기록되며, 나중에 그 스킬이 연속으로 실패하면 자동으로 다시 상위 모델로 되돌아갑니다. 비용을 아끼되 품질이 흔들리는 순간 다시 비싼 모델로 올라가는, 양방향 정책입니다.

핵심은 이 게이트가 “강등 기계”가 아니라 “진실 기계”라는 점입니다. 실제로 자주 쓰는 humanizer 스킬(AI 글 흔적을 지우는 스킬)을 Sonnet에서 Haiku로 내릴 수 있는지 측정해 봤습니다. 결과는 이렇습니다.

$ cost_evolve.py evolve --skill humanizer
{ "skill": "humanizer", "current": "sonnet", "candidate": "haiku",
  "headline_gap": 2.0, "reasoning_gaps": 1, "decision": "hold",
  "reason": "1 reasoning gap(s): rephrasing_naturalness",
  "recommend": "먼저 포맷 갭을 코드로 프로그램화하라" }

게이트는 강등을 거부했습니다. Haiku가 문장을 자연스럽게 다시 쓰는 능력에서 실제로 밀렸기 때문입니다. 동시에 포맷 격차 세 개를 짚으며 “이건 코드로 내리면 된다”고 알려줍니다. 이게 정확히 우리가 원하는 판단입니다. 아무거나 싸게 내리는 게 아니라, 내려도 되는 것만 데이터로 골라냅니다.

팩시스는 이 판단을 매일 밤 자동으로 돌린다

한 번 손으로 하는 최적화는 오래가지 못합니다. 스킬은 계속 늘고, 모델도 계속 바뀌기 때문입니다. 그래서 팩시스에서는 이 판단을 매일 밤 자동으로 돌립니다. 밤마다 강등 후보를 발굴하고, 코드 게이트로 검증하고, 안전한 것만 내리고, 나머지는 근거와 함께 보고합니다.

실제로 돌고 있습니다. 최근 사흘 치 후보 산출물이 그대로 남아 있습니다.

# cost-evolve candidates — 2026-07-03
10 candidate(s), ranked by est. savings.
| lever            | target   | action                              |
| model-deescalate | sod-ship | opus -> sonnet, apply only if PASS  |
| model-deescalate | eod-ship | opus -> sonnet, apply only if PASS  |
| mcp-prune        | codegraph| 미사용 MCP 서버 비활성화             |
| format-determinism | ...    | 포맷을 코드로 추출 후 강등 재시도    |

여기서 정직하게 짚을 부분이 있습니다. 이 시스템은 공격적으로 비용을 깎지 않습니다. 위의 sod-ship과 eod-ship은 하루 전에 막 상위 모델로 올라간 상태였고, 게이트는 “되돌리기엔 너무 이르다”며 강등을 보류했습니다. 시스템이 실제로 내린 것은 확신이 설 때뿐입니다. 대신 전체 스킬의 기본값은 이미 싼 티어입니다. 상위 모델에 고정된 것은 품질이 정말 중요한 소수(블로그 개선, 뉴스 만평, 고객 대면 문안)뿐이고, 나머지는 데이터가 요구할 때만 잠깐 올라갑니다.

정리하면 이렇습니다.

스킬	현재	판정	근거
twitter-timeline	Sonnet	강등 완료	포맷을 코드로 내린 뒤 Opus→Sonnet, 매일 정상 가동
humanizer	Sonnet	보류	Haiku가 자연스러운 재작성에서 밀림
sod/eod-ship	Opus	보류	어제 막 승격, 되돌리기 이름
기본 다수	Sonnet	유지	애초에 싼 티어가 기본값

비싼 모델은 예외이고, 싼 모델이 기본입니다. 그리고 그 경계는 매일 밤 데이터로 다시 그어집니다.

로컬 GPU가 있다면, 싼 티어를 직접 굴려도 된다

여기까지가 상용 API 안에서 티어를 내리는 이야기라면, 로컬 GPU가 있는 팀에는 한 걸음 더 나갑니다. 싼 티어의 상당 부분을 오픈웨이트 소형 모델로 직접 돌릴 수 있기 때문입니다. 최근 소형·중형 오픈웨이트 모델의 도구 호출 능력이 실무에서 쓸 만한 수준으로 올라왔습니다.

구글의 Gemma 4는 Apache 2.0으로 열려 있고, E2B와 E4B 같은 소형 변형은 휴대폰이나 Jetson급 보드에서도 온디바이스로 돕니다. 라우팅과 분류, 간단한 도구 호출 워커로 쓰기 좋은 크기입니다. Zhipu의 GLM 5.2는 MIT 라이선스 오픈웨이트이면서 에이전트형 도구 사용을 앞세워 프론티어 폐쇄 모델에 근접한 성능을 보입니다. Moonshot의 Kimi K2.7-Code는 코딩과 다단계 도구 실행에 특화된 오픈웨이트 모델입니다. 업계에서는 이미 에이전트 트래픽의 60~80%를 이런 오픈웨이트로 흘리고, 정말 어려운 20% 남짓만 프론티어 API로 올려보내는 구성이 자리 잡고 있습니다.

우리가 하려는 말은 단순합니다. 팀 업무의 대부분은 고난도 창작이 아니므로, 그 부분은 로컬에서 도는 작은 모델로 충분합니다. 프론티어 모델은 남겨두되, 진짜 어려운 소수의 일에만 쓰면 됩니다.

도움이 필요하다면

GLM 5.2와 Kimi K2.7-Code 같은 최신 오픈웨이트 모델을 조합해 비용을 최적화하고 싶은 팀이라면 연락 주십시오. 어떤 업무를 어느 티어로 내리고, 무엇을 코드 게이트로 지킬지 함께 설계해 드립니다.

로컬 GPU를 일부라도 보유한 팀이라면 우리 메티스 추론 플랫폼을 활용하시길 권합니다. 보유한 장비에 맞춰 추론을 최적화해 제공하므로, 소형 오픈웨이트 모델을 여러분의 하드웨어에서 가장 효율적으로 돌릴 수 있습니다.

싼 모델이 기본이고 비싼 모델이 예외인 구조는 한 번 세팅으로 끝나지 않습니다. 매일 밤 측정하고, 안전할 때만 내리고, 흔들리면 되돌리는 루프가 있어야 유지됩니다. 팩시스는 그 루프를 시스템으로 제공합니다.