LLM 한 번만 쓰고 로컬에서 영원히 판단한다, 스트롯(Strot) 등장

LLM 호출비를 한 번만 내고 나머지는 로컬에서 해결한다

스트롯(Strot)은 '의도 컴파일러'를 표방한다. 개발자가 자연어로 "들어오는 지원 티켓을 올바른 워크플로로 분류하라"고 한 번만 지시하면, LLM이 이를 분석해 파이썬 아티팩트(작은 결정 모델)로 굳힌다. 이후 실제 운영에선 LLM을 전혀 부르지 않는다. 1억 4400만 파라미터(모델의 두뇌 용량에 해당하는 수치)짜리 줄리아-1(Julia-1) 모델이 CPU만으로 레코드당 약 60밀리초 만에 분류·점수·라우팅을 내놓는다. 마진 비용은 0원이다.

해커뉴스 쇼 HN 게시글은 점수 23, 댓글 10을 기록했다. "수십억 건 계약을 배치 추론할 때 LLM 비용이 감당 안 돼 이 방식을 썼다"는 실무자 댓글이 달렸지만, "리드미를 읽어도 정확히 뭐 하는지 모르겠다"는 혼란도 공존한다.

컴파일 한 번, 런타임 영원히 — 구조가 다르다

기존 LLM 앱은 요청마다 모델을 호출한다. 스트롯은 컴파일 타임과 런타임을 완전히 분리한다.

아티팩트는 파이썬 파일 하나다. 도커 이미지에 구워 넣으면 오프라인 환경에서도 돈다. pip install strot-ai[local] 후 strot.prefetch_nlu()로 모델을 미리 캐시하면 된다.

쉽게 풀어보면

스트롯이 하는 일을 뷔페에 비유해 보자. 기존 방식은 손님(요청) 올 때마다 셰프(대형 LLM)를 불러 요리를 시킨다. 손님 수만큼 셰프 인건비가 나간다.

스트롯은 첫 손님 왔을 때 셰프를 불러 '이 재료면 이 요리, 저 재료면 저 요리'라는 레시피북(아티팩트)을 한 권 만든다. 그 뒤로는 셰프를 부르지 않고 주방 보조(로컬 소형 모델)가 레시피북만 보고 뚝딱 내놓는다. 레시피북에 없는 재료면 "모르겠다"며 기권한다. 틀린 요리를 내는 대신 안 내는 쪽을 택한다.

이게 중요한 이유는 수억 건 티켓·계약·로그를 분류할 때 LLM API 비용이 수천만 원 단위로 나가는 문제를 원천 차단하기 때문이다. 컴파일 한 번에 수만 원 쓰고, 이후는 전기세만 든다.

커뮤니티가 짚은 구멍 세 가지

해커뉴스 댓글에서 세 가지 의문이 반복됐다.

1. "문서만 봐선 뭘 하는지 모르겠다" — 작성자 본인도 "더 자세한 설명이 필요하겠다"고 인정했다. DEVELOPERS.md에 아키텍처·캘리브레이션·배포·모델 교체 가이드가 있다지만, 입문자가 10분 만에 돌려보기엔 진입장벽이 있다.
2. "트윗 혐오발언 데이터셋에서 모델 천장(ceiling)을 친다" — 특정 벤치마크에서 이미 성능 한계가 보였다는 뜻이다. 작성자가 "수직적 스케일링(더 큰 모델)"으로 풀 수 있다고 답했는지는 본지가 확인하지 못했습니다. 한국어 혐오·스팸 탐지 같은 도메인에서 같은 한계가 올지 미지수다.
3. "그냥 LLM한테 코드 짜달라고 시키면 안 되나?" — "LLM에게 '분류기 코드 써줘' 하면 되지 않냐"는 회의론이다. 스트롯은 캘리브레이션(신뢰도 보정)·콘포멀 예측(오류율 상한 보장)·스키마 드리프트 감지까지 자동화해 준다는 차이가 있다. 이건 직접 짜면 며칠 걸리는 부분이다.

한국어 실서비스에 쓸 수 있을까? — 아직 검증 안 된 지점들

발표 자료와 벤치마크 저장소(benchmarks/)에 언어 표기가 없다. 한국어 티켓·문의·계약 분류에서 같은 60ms·같은 정확도·같은 기권율이 나오는지 확인된 바 없다. 줄리아-1 모델 카드에도 한국어 학습 비중은 명시되지 않았다.

또한 스키마 변경 시 재컴파일 비용이 실무에서 얼마나 드는지도 미공개다. "스키마 드리프트 감지 시 정확히 한 번만 재컴파일"한다고 하지만, 필드 하나 추가할 때마다 클로드 오퍼스를 다시 부르는 게 맞다면 운영비 예측이 어렵다.

본지가 앞서 다룬 AI가 '생각'을 숨기고 '말'만 내놓는다면 글에서 논의된 '사고 과정 은닉' 아키텍처와도 결이 닿아 있다. 스트롯은 사고 과정을 컴파일 타임에만 쓰고, 런타임엔 결과만 내놓는다. 하지만 당시 글에서 지적된 '검증 불가능한 블랙박스' 위험을 캘리브레이션과 기권 메커니즘으로 얼마나 완화했는지는 실전 데이터로 봐야 안다.

나에게 미치는 영향

당장 해볼 수 있는 것: pip install strot-ai[local] 하고 예제 코드(strot.run 또는 strot.decide)를 돌려보라. 5분이면 로컬에서 분류기 하나가 돈다. 한국어 샘플 50~100개로 compile → test 사이클을 한 바퀴 돌려보면 내 도메인에서 기권율이 몇 %인지, 오분류가 어디로 가는지 바로 보인다.

막히면 여기서 확인하라:

• 한국어 데이터로 기권율 30% 넘으면 → 샘플 더 넣거나 nlu= 슬롯에 한국어 특화 소형 모델(예: KoBERT 계열) 꽂기
• 스키마 바꿀 때마다 재컴파일 비용 부담되면 → 필드 분리·버전 관리 전략부터 짜기
• 오프라인 배포 필요하면 → Dockerfile에 prefetch_nlu 단계 넣고 STROT_NLU_CHECKPOINT 환경변수 고정

하지 말 것: "무조건 공짜니까 다 이걸로 옮기자"는 판단. 검증 없이 프로덕션에 올리면 기권한 레코드가 쌓여 사람이 다시 봐야 하는 역설이 온다. 파일럿 2주, 실데이터 1만 건 이상으로 지표 찍고 나서 결정해도 늦지 않다.

남은 쟁점 — 벤치마크 재현성과 한국어 지원 로드맵

작성자는 "벤치마크 디렉터리에 손실값까지 공개했으니 다 재현 가능하다"고 했다. 하지만 재현 환경(도커·하드웨어·파이썬 버전) 이 내 서버와 다를 때 같은 수치가 나오는지, 한국어 토크나이저 호환성은 어떤지가 다음 검증 포인트다. MIT 라이선스라 포크·수정은 자유지만, 한국어 커뮤니티에서 첫 생산 사례가 나오기 전까진 '가능성'으로만 둬야 한다.