오픈 모델, 우리가 직접 돌려야 할까?

요즘 상담을 하다 보면 "오픈 모델 성능이 많이 올라왔다는데, 우리도 직접 돌리면 더 싸지 않을까요?"라는 질문을 자주 받습니다.
Llama, Qwen, Mistral, Gemma, gpt-oss처럼 가중치가 공개된 모델이 늘면서 선택지가 넓어진 건 사실입니다.
다만 "쓸 수 있다"와 "우리에게 이득이다"는 다른 문제입니다.
작은 팀 기준으로 언제 갈아타는 게 맞는지, 어디까지만 옮기는 게 안전한지 정리했습니다.

오픈 웨이트 모델, 지금 우리 팀에 이득일까?

결론부터 말하면, 대부분의 1인 빌더와 소규모 팀에게는 아직 상용 API가 기본값입니다.
직접 운영이 유리해지는 건 아래 세 조건 중 두 개 이상에 해당할 때입니다.
그렇지 않으면 GPU 대여비와 운영에 드는 사람 시간이 API 요금보다 커지기 쉽습니다.

• 데이터를 외부로 보낼 수 없는 경우 — 고객사 계약서에 외부 전송 금지 조항이 있거나, 의료·법무·공공 과제처럼 반출 자체가 심사 대상인 경우
• 좁고 반복적인 작업이 대량으로 발생하는 경우 — 문의 분류, 태깅, 요약, 임베딩처럼 정답 범위가 좁은 호출이 매일 쌓이는 구조
• 모델 버전을 우리 손으로 고정하고 싶은 경우 — 공급사 업데이트로 출력 톤이 바뀌면 곤란한 기능(예: 계약 문구 생성)

'직접 돌린다'에도 단계가 있습니다

많은 팀이 곧바로 서버 구매를 떠올리는데, 그 사이에 중간 단계가 있습니다.
순서대로 올라가면 위험이 훨씬 작습니다.

1. 관리형 서비스에서 오픈 모델을 API로 호출하기 (Together AI, Fireworks AI, Groq, Amazon Bedrock, Azure AI Foundry 등)
2. 전용 GPU 인스턴스를 빌려 vLLM 같은 서빙 엔진으로 직접 배포하기
3. 사내 서버·온프레미스에 올리고 우리 데이터로 파인튜닝하기

1단계만 해도 모델을 언제든 바꿀 수 있는 권한과 가격 협상력의 상당 부분을 확보할 수 있습니다.
한국어 비중이 높은 서비스라면 네이버의 HyperCLOVA X SEED, LG의 EXAONE처럼 공개된 국내 모델도 후보에 넣어볼 만합니다.

어디까지 오픈 모델에 맡기고, 어디부터 프론티어 모델을 쓸까?

기능 단위가 아니라 작업 난이도 단위로 쪼개는 것이 핵심입니다.
한 서비스 안에서도 어떤 호출은 작은 오픈 모델로 충분하고, 어떤 호출은 최상위 모델이 아니면 사고가 납니다.

예를 들어 온라인 편집숍이라면 이렇게 나눕니다.
들어온 문의를 '배송/교환/재입고' 중 하나로 분류하고, 상품 상세 초안을 뽑고, 검색용 임베딩을 만드는 일은 소형 오픈 모델로 처리합니다.
반면 반품 규정을 해석해 고객에게 나갈 답변을 쓰거나, 여러 주문 이력을 읽고 보상안을 제안하는 일은 프론티어 모델에 맡깁니다.

• 오픈 모델 쪽: 정답 범위가 좁음, 출력이 짧음, 틀려도 사람이 바로 알아챌 수 있음, 호출량이 많음
• 프론티어 모델 쪽: 긴 문맥을 읽어야 함, 도구·함수 호출이 여러 번 이어짐, 결과가 고객에게 그대로 나감, 금액·법적 책임이 걸림

도입 전에 무엇부터 재봐야 할까?

공개 벤치마크 점수 비교는 참고용일 뿐입니다.
우리 데이터로 만든 평가셋에서 기존 모델과 나란히 돌려보는 것이 유일하게 믿을 만한 근거입니다.
2주면 충분히 결론이 납니다.

1. 최근 실제 요청 로그에서 100~300건을 뽑고, 각 건의 합격 기준을 한 줄로 정의합니다
2. 지금 쓰는 모델로 돌려 기준선 점수를 만듭니다
3. 후보 오픈 모델 두 개를 관리형 API로 붙여 같은 평가셋에 돌립니다
4. 합격률이 기준선 근처면 실제 트래픽의 10%만 라우팅해 지연 시간과 오류율을 봅니다
5. 한 달치 총비용(요금 + GPU + 운영에 쓴 시간)을 비교해 확대할지 되돌릴지 정합니다

이 과정을 편하게 만드는 건 결국 구조입니다.
프롬프트와 평가셋을 코드 안에 박아두지 말고 밖으로 빼두면, 모델을 바꾸는 일이 배포가 아니라 설정 변경이 됩니다.
세느루로 만든 서비스도 같은 원칙을 씁니다. 지금 당장 오픈 모델로 옮기지 않더라도, 언제든 옮길 수 있게 만들어 두는 것이 올해 작은 팀이 챙길 수 있는 가장 확실한 이득입니다.