모델보다 하네스가 돈이다 — 소수팀 LLM 비용 제어법

소수 개발팀이 AI를 진지하게 쓰기 시작하면 반드시 부딪히는 벽이 있다. 모델 품질이 아니라 비용 제어다.

Writer가 이번에 공개한 건 새 LLM 하나가 아니다. Z.ai의 오픈소스 GLM-5.2를 포스트트레이닝한 모델에, "하네스(harness)"라 부르는 비용 제어 레이어를 씌운 조합이다. TechCrunch 기사 제목에서 진짜 무게는 모델보다 하네스 쪽에 있다.

단, 여기에 함정이 하나 있다. 하네스를 만들면 비용이 줄어든다는 건 맞는데, 하네스를 잘못 설계하면 오히려 복잡도만 늘고 절감 효과는 미미하다. 그 경계가 어디에 있는지가 실제로 중요하다.

하네스가 뭔데, 왜 모델보다 중요한가

하네스는 LLM을 래핑하는 제어층이다. 어떤 태스크에 어떤 모델을 쓸지 라우팅하고, 토큰 예산을 관리하고, 출력 형식을 강제하고, 실패 시 재시도 방법을 결정한다.

오픈소스 모델을 파인튜닝하면 API 단가가 떨어진다. 그런데 단가를 아무리 낮춰도 호출 수가 걷잡을 수 없이 늘어나면 청구서는 다시 올라간다. Writer가 "업그레이드된 하네스"를 별도로 강조하는 이유가 여기 있다. 모델이 싸더라도, 그 모델을 어떻게 부르느냐가 실제 비용을 결정한다.

팀이 크면 전담 MLOps가 비용 모니터링을 맡는다. 우리 같은 팀은 개발자가 곧 MLOps고, 곧 PO고, 곧 운영이다. 하네스가 없으면 비용 폭발을 가장 늦게 발견한다. 그것도 청구서 날아오고 나서.

우리가 이미 갖고 있는 하네스, 그리고 빠진 것

솔직히 말하면 우리는 이미 간단한 하네스를 운영 중이다. /opt/common/claude_cli.py가 그거다. anthropic SDK를 직접 쓰는 대신 이 래퍼를 거쳐 LLM을 부른다. 재시도 로직, 모델 선택 인터페이스, 기본 로깅이 거기 집중돼 있다.

봇마다 claude-haiku-4-5로 본문을 생성하고, review_loop(검수 서비스)가 claude-sonnet-4-6으로 품질을 심사한다. 싸고 빠른 모델이 초안을 쓰고, 비싸고 정확한 모델이 OK/REJECT를 내린다. 어딘가에서 본 만화 한 장 같다 — AI 면접관한테 면접 보는 신입 AI. 그 구도가 우리 시스템에 그대로 구현되어 있고, 실제로 꽤 잘 작동한다.

그런데 우리 하네스에 명확히 빠진 게 있다. 태스크별 토큰 사용량 집계다. 지금은 호출 성공/실패 여부만 남긴다. 어떤 봇이, 어떤 태스크에서 토큰을 얼마나 쓰는지 데이터가 없다. 모르면 줄일 수가 없다.

오픈소스 파인튜닝의 현실적 계산

GLM-5.2는 Z.ai(Zhipu AI)의 오픈소스 모델이다. Writer가 이걸 포스트트레이닝해서 자기 도메인에 맞게 만들었다. "배포 준비된 성능을 훨씬 낮은 가격에"라는 게 그들의 주장이다.

구체적인 숫자로 따져보자. Claude Haiku 3.5 기준 input $0.80/M tokens, output $4.00/M tokens다. GPT-4o mini는 input $0.15/M, output $0.60/M. 오픈소스를 자체 서버에 올리면 inference 비용이 GPU 서버 월정액으로 고정된다 — AWS g4dn.xlarge 기준 약 $400/월이고, A10G 하나로 7B 파라미터 모델은 충분히 돌린다.

하루에 LLM 호출이 1,000건 넘어가면 고정비가 변동비를 이기기 시작하는 변곡점에 근접한다. 봇 15개가 하루 평균 1,500건 호출, 호출당 평균 1,500 tokens를 소비한다면 월 약 6,750만 tokens다. Haiku 기준 대략 $40~50/월 선. 이 수준이면 GPU 서버 직접 올리는 게 오히려 손해다. 두 배 규모에서는 계산이 달라진다. Writer의 접근법은 그 변곡점을 아래로 당기는 전략이다.

단, 파인튜닝은 공짜가 아니다. 데이터 큐레이션, 훈련 비용, 이후 유지보수까지 포함하면 소수 팀이 직접 감당하기엔 벅차다. 그래서 Writer 같은 회사가 파인튜닝 결과물을 API로 팔고, 그 위에 하네스까지 제공하는 조합이 시장에서 통한다.

소수팀이 지금 할 수 있는 현실적 시나리오

파인튜닝은 아직 우리 리소스 밖이다. 하지만 하네스 개선은 다르다.

당장 해볼 수 있는 가장 효과적인 변화는 system prompt caching이다. Anthropic API는 cache_control을 지원한다. blog 봇이나 ssul 봇은 system prompt가 길다 — learn-update.py가 매일 새벽 learned JSON을 갱신하고 다음 발행 system prompt에 주입하는 구조라, 반복 호출 때마다 그 긴 system prompt를 통째로 보내고 있다. cache_control로 마킹하면 캐시 hit 시 input 토큰 비용이 최대 90% 줄어든다. Anthropic 문서 기준 수치다.

두 번째는 태스크 분류 기반 모델 라우팅이다. 본문 생성 안에서도 태스크가 섞여 있다. 키워드 추출, 제목 후보 생성, 본문 초안 작성 — 이 셋이 동일한 모델로 동일한 토큰을 소비할 이유가 없다. claude_cli에 task_hint 파라미터를 추가하고 "classify" / "generate" / "judge" 세 가지로 기본 모델을 분리하면, 나중에 더 싼 모델이 나왔을 때 한 곳만 수정하면 전체에 반영된다.

세 번째는 "이게 정말 LLM이 필요한가" 게이트다. gov 봇처럼 공고를 크롤해서 정형 데이터를 뽑는 경우, 일부 필드는 정규식이나 간단한 파싱으로 충분하다. LLM을 부르기 전에 먼저 간단한 패턴 매칭을 시도하고, 실패했을 때만 LLM으로 넘기는 폴백 구조는 구현이 단순하면서 효과가 크다.

바로 써먹을 시사점

첫째, 토큰 사용량 로깅부터 시작하라. claude_cli complete() 함수에서 응답 usage 객체의 input_tokens·output_tokens를 꺼내 admin_db llm_usage_log 테이블에 INSERT한다. 컬럼은 bot_slug, task_type, input_tokens, output_tokens, model, called_at. 일주일만 쌓아도 가장 토큰을 많이 먹는 봇·태스크가 데이터로 보인다. 아무것도 안 하고 이것만 해도 다음 달 개선 방향이 생긴다.

둘째, system prompt caching을 blog·ssul 봇에 이번 주 안에 적용하라. 변경 범위가 claude_cli 단 한 곳이다. cache_control: {"type": "ephemeral"} 블록으로 system prompt를 래핑하면 끝이다. 인풋 토큰이 비싼 봇일수록 효과가 즉시 나온다.

셋째, claude_cli에 task_hint 파라미터를 추가하고 모델 매핑을 중앙화하라. 지금은 각 봇이 model을 직접 하드코딩한다. 이걸 claude_cli 레벨로 올려두면 새 모델이 나왔을 때 봇 15개를 하나씩 고치는 대신 설정 파일 하나만 바꾸면 된다.

Writer가 "하네스"를 제품 기능으로 포장해서 팔 수 있다는 건, 그 하네스를 필요에 의해 직접 만들어 쓰는 팀이 이미 있다는 얘기다. 우리가 그중 하나고, 체계만 덜 잡혀 있을 뿐이다. 그 간격을 메우는 게 지금 당장 가장 현실적인 생산성 개선 경로다.

원문: AI News & Artificial Intelligence | TechCrunch