작업에 맞는 모델 크기 고르기

대부분의 팀은 감당할 수 있는 가장 큰 모델을 골라 놓고 더 고민하지 않습니다. 유능한 모델은 어떤 작업을 던져도 거의 다 처리해 준다는 점에서 그 방식도 통하긴 합니다. 하지만 옳은 선택인 경우는 드뭅니다. 가장 큰 모델은 가장 느리고 가장 비싼 선택지이며, 많은 작업은 그런 모델을 필요로 하지 않습니다. 모델 크기를 고르는 일은 매칭 문제입니다. 정당화할 수 있는 가장 큰 모델이 아니라, 그 일을 안정적으로 해내는 가장 작은 모델을 원해야 합니다.

"크기"가 실제로 사주는 것

모델 제공사는 보통 하나의 제품군을 내놓습니다. 작고 빠르고 저렴한 등급과 크고 느리고 유능한 등급, 그리고 그 사이에 무언가가 끼어 있는 경우가 많죠. 더 큰 모델은 어려운 추론, 미묘한 지시, 장기적 일관성, 그리고 실수가 명백하기보다 미묘하게 드러나는 작업에 더 강합니다. 더 작은 모델은 극적으로 빠르고 저렴하며, 단순한 작업에서는 정확도도 큰 모델 못지않은 경우가 많습니다.

핵심 통찰은, 역량이란 항상 최대치까지 올려놓고 싶은 단일 다이얼이 아니라는 점입니다. 역량은 소비하는 자원입니다. "작업에 필요한 수준보다 똑똑한" 모델은 그 잉여분으로 추가 가치를 만들어 내지 못합니다. 그저 더 비싸고 더 느리게 응답할 뿐이죠. 목표는 작업의 난이도와 모델의 역량이 만나는 지점을 찾아 거기서 멈추는 것입니다.

작업을 정직하게 묘사하는 것부터

모델을 비교하기 전에, 그 작업이 정말로 무엇을 요구하는지부터 묘사하세요. 몇 가지 질문이 이를 금방 날카롭게 만들어 줍니다. 이 작업은 여러 단계의 추론을 요구합니까, 아니면 조회나 변환에 가깝습니까? 입력은 얼마나 다양합니까. 좁고 예측 가능한 형식입니까, 아니면 지저분하고 열린 텍스트입니까? 틀린 답의 대가는 얼마나 큽니까. 사소한 성가심입니까, 아니면 실제 실패입니까? 그리고 지연 시간은 얼마나 눈에 띕니까. 사람이 응답을 기다립니까, 아니면 백그라운드에서 돌아갑니까?

분류, 추출, 형식 변환, 짧은 재작성, 라우팅은 이런 의미에서 보통 쉽습니다. 예측 가능한 입력, 명확한 정답, 낮은 추론 깊이죠. 열린 분석, 다단계 계획, 섬세한 글쓰기, 그리고 모델이 한 번에 여러 제약을 동시에 붙들어야 하는 작업은 어렵습니다. 여기서 정직해야 합니다. 작업이 중요하게 느껴진다는 이유로 어렵다고 부르고 싶은 유혹이 생깁니다. 중요도와 난이도는 다릅니다. 메커니즘이 단순한 중요한 작업은 여전히 작은 모델의 몫입니다.

저렴한 것부터 시작하는 방법

믿을 만한 선택 방법은 작게 시작해서 어쩔 수 없을 때만 올리는 것입니다. 제품군에서 가장 작은 모델로 시작해, 실제적이고 다양한 입력 묶음을 대상으로 돌려 보세요. 데모 하나가 아니라, 쉬운 경우와 까다로운 경우를 모두 포함하는 한 줌의 입력으로요. 출력을 읽어 보세요. 작은 모델이 안정적으로 충분히 좋다면, 끝난 겁니다. 가장 빠르고 가장 저렴한 선택지를 손에 넣은 거죠.

실패한다면, 어떻게 실패하는지를 보세요. 때로는 해법이 더 큰 모델이 아니라 더 나은 프롬프트입니다. 더 명확한 지시, 예시 한두 개, 이름 붙인 실패 유형 같은 것이죠. 그걸 먼저 시도하세요. 공정한 프롬프트를 줬는데도 작은 모델이 여전히 부족하다면, 중간 등급으로 올려 같은 과정을 반복하세요. 진짜 평가를 통해 더 작은 모델들이 그 일을 못 한다는 게 드러날 때만 가장 큰 모델로 올리세요. 바닥에서 올라가는 이 접근은 기본값으로 과지출하는 일을 막아 주며, 큰 모델이라면 조용히 가려 버렸을 프롬프트 문제를 드러내 줍니다.

앱이 아니라 단계에 모델을 맞추세요

흔한 실수는 애플리케이션 전체에 하나의 모델을 고르는 것입니다. 대부분의 실제 시스템은 난이도가 서로 다른 단계들로 이뤄진 파이프라인입니다. 요청을 올바른 핸들러로 라우팅하는 일은 쉽습니다. 복잡한 질문에 신중한 답을 작성하는 일은 어렵습니다. 그 답을 JSON으로 다시 포맷하는 일은 또 쉽습니다. 모든 단계에 가장 큰 모델을 쓴다는 건 사소한 단계에까지 프리미엄 요금을 낸다는 뜻입니다.

더 나은 설계는 각 단계에 모델 크기를 배정합니다. 저렴한 모델이 분류, 라우팅, 추출, 형식 변환을 맡습니다. 비싼 모델은 진정으로 깊은 추론이 필요한 한두 단계를 맡습니다. 이를 캐스케이드 또는 라우터 패턴이라 부르기도 합니다. 작은 모델이 대부분의 일을 하면서 직접 답하거나, 어려운 경우를 더 큰 모델로 넘기는 방식이죠. 그 결과 시스템은 역량 예산을 정작 중요한 곳에 쓰고 나머지에서는 아끼게 됩니다.

정확도뿐 아니라 비용과 지연 시간도 따지세요

정확도가 헤드라인이긴 하지만, 유일한 축은 아닙니다. 지연 시간은 사용자 경험을 직접 좌우합니다. 몇 초가 걸리는 응답은 대화형 채팅에서는 고장처럼 느껴지지만, 야간 배치 작업에서는 괜찮습니다. 사람이 기다리고 있다면, 약간 덜 다듬어졌더라도 빠른 작은 모델이, 근소하게 더 나은 느린 큰 모델을 이길 수 있습니다.

비용은 규모에서 복리로 불어납니다. 요청당으로 보면 사소해 보이는 등급 간 가격 차이가, 수백만 건의 호출로 곱해지면 지속 가능한 제품과 지속 불가능한 제품을 가르는 차이가 됩니다. 평가할 때는 각 후보의 정확도, 지연 시간, 비용을 함께 적어 두세요. 정확도 기준선을 통과하는 가장 작은 모델이 정답인 경우가 많은데, 나머지 두 축에서 결정적으로 이기기 때문입니다. 큰 모델은 정확도 격차가 실재하고 그 위험 부담이 프리미엄을 정당화하는 경우를 위해 아껴 두세요.

시간이 지나면 결정을 재점검하세요

모델 선택은 영구적이지 않습니다. 제공사는 정기적으로 새 모델을 내놓고, 내년의 작은 등급이 작년의 큰 등급에 맞먹는 경우가 많습니다. 오늘은 가장 큰 모델이 필요했던 작업이, 다음 출시 이후엔 더 저렴한 모델에서 편안하게 돌아갈 수도 있습니다. 평가 세트를 곁에 두어, 새 모델이 출시될 때 다시 돌려 볼 수 있게 하세요. 처음 선택을 도와준 바로 그 세트가, 그 선택을 저렴하게 재검토하게 해 줍니다. 그리고 추세는 거의 항상 등급을 올리는 게 아니라 내리는 쪽을 향합니다.

이것이 특정 모델에 대한 가정을 프롬프트와 코드에 하드코딩하지 말아야 할 이유이기도 합니다. 모델을 작은 추상화 뒤에 두어, 교체가 다시 작성이 아니라 설정 변경이 되게 하세요. 모델의 발전에서 가장 큰 이득을 보는 팀은 교체를 쉽게 만들어 둔 팀입니다.

정리

모델 크기를 고르는 일은 극대화가 아니라 매칭입니다. 작업의 진짜 난이도를 묘사하고, 가장 작은 모델로 시작해, 진정한 평가가 강제할 때만 올라가세요. 앱 단위가 아니라 단계 단위로 크기를 배정해, 저렴한 모델이 쉬운 일을 하고 비싼 모델이 몇 안 되는 어려운 부분을 맡게 하세요. 정확도와 함께 지연 시간과 비용을 따지세요. 기준선을 통과하는 가장 작은 모델이 대체로 종합적으로 이깁니다. 그리고 새 모델이 출시될 때마다 선택을 재검토하세요. 똑똑한 기본값은 계속 더 저렴해지니까요.