AI 시스템을 만들 때 모든 요청을 가장 큰 모델로 보내는 방식은 단순합니다. 하지만 운영비와 지연 시간이 빠르게 커집니다. 특히 IDE 기능, RAG 후처리, 요청 라우팅, 도구 선택, 요약, 검증처럼 자주 호출되는 단계는 큰 모델이 항상 정답이 아닙니다. JetBrains가 공개한 Mellum2는 이 지점을 겨냥한 모델입니다. 12B Mixture-of-Experts 구조이지만 토큰당 활성 파라미터는 2.5B이고, 텍스트와 코드 워크로드에 맞춰 공개됐습니다.
Mellum2 발표에서 중요한 문장은 “frontier model 대체”가 아니라 “larger AI system 안의 focal model”이라는 설명입니다. Apache 2.0 라이선스, 코드와 자연어 작업, 라우팅·RAG·서브에이전트·프라이빗 배포에 적합하다는 포지션이 명확합니다. 실무 개발자에게는 모델 성능표보다 “어떤 단계에 작은 모델을 넣어 비용을 줄일 수 있나”가 더 중요합니다.
운영 중인 AI 서비스 로그를 보면 모든 요청이 같은 난이도가 아닙니다. 사용자의 질문 의도 분류, 검색 쿼리 재작성, 문서 조각 압축, 코드 파일 요약, 도구 선택, 최종 답변 검수 같은 중간 단계가 많습니다. 이 단계들은 대형 추론 모델을 호출하면 품질은 괜찮지만 비용과 지연 시간이 과합니다.
작은 코드 모델은 이런 high-frequency, low-to-medium complexity 작업에 맞습니다. 예를 들어 “이 요청은 결제 문의인가, 기술 문의인가”, “이 코드 변경은 테스트 파일을 함께 봐야 하는가”, “이 검색 결과 20개 중 답변에 넣을 5개는 무엇인가” 같은 작업입니다. 정답이 비교적 구조화되어 있고, 긴 추론보다 빠른 분류와 변환이 필요한 곳이 후보입니다.
Mellum2는 총 12B 파라미터지만 토큰당 2.5B만 활성화하는 Mixture-of-Experts 모델입니다. 이 구조는 같은 총 용량 대비 inference 효율을 높이는 데 유리합니다. 발표에서는 비슷한 크기의 모델 대비 경쟁력 있는 벤치마크와 2배 이상 빠른 inference를 강조합니다.
실무에서는 “벤치마크가 좋다”보다 “동시 요청을 얼마나 버티는가”가 더 중요합니다. RAG 파이프라인에서 문서 10개를 각각 요약하거나, 에이전트가 매 단계 tool selection을 할 때 모델 호출 수는 쉽게 늘어납니다. 이때 토큰당 활성 파라미터가 작은 모델은 처리량과 비용 측면에서 유리할 수 있습니다.
가장 쉬운 적용은 라우팅입니다. 사용자 요청을 몇 개의 경로로 나누고, 각 경로마다 다른 모델이나 도구를 호출합니다. 예를 들어 개발자 지원 챗봇이라면 요청을 bug_analysis, code_generation, docs_search, billing, unsafe_or_unknown으로 분류할 수 있습니다.
여기서 중요한 것은 라우팅 모델에게 긴 답변을 쓰게 하지 않는 것입니다. 출력은 JSON 하나로 제한합니다. route, confidence, required_tools, reason 정도면 충분합니다. confidence가 낮으면 큰 모델로 보내거나 사람에게 넘깁니다. 이렇게 하면 작은 모델이 잘하는 빠른 분류만 맡고, 어려운 판단은 더 강한 모델이 처리합니다.
RAG에서 작은 모델을 넣을 수 있는 위치는 많습니다. 첫째, 사용자 질문을 검색 쿼리로 바꾸는 query rewriting입니다. 둘째, 검색 결과를 압축하는 context compression입니다. 셋째, 답변에 쓸 근거와 버릴 근거를 고르는 reranking 보조 단계입니다. 넷째, 최종 답변이 근거 문서와 어긋나는지 확인하는 lightweight verifier입니다.
큰 모델 하나가 검색부터 답변까지 모두 처리하면 구현은 쉽습니다. 하지만 문서가 많아질수록 context 비용이 늘고, latency가 길어집니다. 작은 모델로 검색 전후를 정리하면 큰 모델에는 더 적은 문맥과 더 명확한 질문을 보낼 수 있습니다. 특히 내부 코드베이스 RAG에서는 파일 요약, 심볼 설명, 변경 영향 범위 추정에 작은 코드 모델이 유용합니다.
에이전트 시스템에서는 하나의 모델이 모든 일을 하는 구조보다 역할을 나누는 구조가 안정적입니다. Mellum2 같은 모델은 planner, validator, transformer, context preparer 같은 서브에이전트 후보입니다. 예를 들어 메인 에이전트가 “결제 API 오류를 분석하라”는 작업을 받으면, 작은 모델이 관련 로그를 요약하고, 변경 파일을 분류하고, 테스트 후보를 추천할 수 있습니다.
다만 작은 모델에게 장기 계획 전체를 맡기면 위험합니다. 작은 모델은 빠른 반복 작업과 명확한 스키마 출력에 적합합니다. 요구사항이 모호하거나 여러 이해관계가 엮인 판단은 큰 모델이나 사람 검토로 넘겨야 합니다. 모델 크기 선택은 비용 문제가 아니라 실패 비용 문제입니다.
작은 모델 도입은 A/B로 봐야 합니다. “큰 모델 대비 얼마나 싸다”만 보면 안 됩니다. 라우팅 오분류율, 검색 누락률, 압축 후 답변 정확도, verifier false positive를 측정해야 합니다. 특히 라우팅 모델이 낮은 confidence를 제대로 표시하는지가 중요합니다. 모르는 것을 모른다고 못 하면 전체 시스템 품질을 떨어뜨립니다.
운영 로그에서 200~500개 샘플을 뽑아 사람 기준 라벨을 만들고, 작은 모델과 기존 큰 모델의 결과를 비교합니다. 정확도가 조금 낮아도 비용 절감이 크고, 낮은 confidence를 안전하게 fallback할 수 있으면 도입 가치가 있습니다. 반대로 오분류가 사용자 데이터 변경이나 결제 처리로 이어지는 영역에는 쓰면 안 됩니다.
Mellum2 같은 작은 코드 모델의 핵심은 대형 모델을 이기는 것이 아니라 대형 모델을 덜 부르게 만드는 것입니다. AI 시스템이 커질수록 라우터, 요약기, 검증기, 서브에이전트가 늘어납니다. 이 고빈도 단계에 맞는 모델을 고르는 것이 비용과 속도를 좌우합니다.
