적합한 AI 모델 선택: 비용과 성능의 균형

가장 강력한 모델을 고르면 어느 정도 안심이 됩니다. AI 기반 제품을 개발할 때 현재 사용 가능한 가장 강력한 모델을 선택하는 일은 책임감 있고, 거의 당연한 판단처럼 느껴집니다. GPT-4o, Claude Opus, Gemini Ultra는 모두 인상적인 기술입니다. 선택지 중 가장 똑똑한 도구를 골랐다는 이유로 해고된 사람은 없습니다.

하지만 한 가지 단서가 있습니다. 프로젝트가 비대해지고 비용이 치솟으며 지연이 서서히 늘어납니다. 세 번째 달쯤 되면 팀은 불편한 질문을 하기 시작합니다. 단순한 자동 완성 기능이 왜 지출에 책임질 필요도 없이 벤처 투자를 받은 스타트업처럼 API 크레딧을 소모하는 걸까요?

핵심은 ‘능력이 가장 뛰어난 것’과 ‘가장 적합한 것’이 전혀 다른 기준이라는 점입니다. AI 애플리케이션 개발 서비스 제공업체는 순위표가 아니라 평가 결과를 바탕으로 모델을 선택합니다.

더 크다고 자동으로 더 좋은 것은 아닙니다

프론티어 모델은 이상적인 조건에서 매우 뛰어난 성능을 내지만 운영 비용이 높고, 불완전한 입력을 잘 처리하지 못하며, 단순한 작업에는 필요 이상의 능력을 제공합니다.

GPT-4o는 시를 쓰고 법률 계약을 추론하며 코드를 디버깅하고 열 살 아이에게 양자 얽힘을 설명할 수 있습니다. 때로는 이 모든 일을 한 답변에서 합니다. 정말 인상적인 능력입니다. 그러나 앱이 고객 지원 요청을 요약하거나 청구서에서 구조화된 데이터를 추출한다면 사용하지 않는 능력에 비용을 지불하는 셈입니다.

더 작고 특화된 모델도 범위가 명확한 작업을 놀라운 정확도로 처리합니다.

• GPT-4o mini는 GPT-4o의 약 15분의 1 비용으로 대부분의 언어 작업을 처리합니다
• Claude Haiku는 대량의 구조화된 작업을 빠르고 효율적으로 처리하도록 설계되었습니다
• Mistral 7B와 Llama 3.1 8B는 빠르게 실행되고 미세 조정에도 적합한 오픈 소스 선택지입니다

작업 범위가 좁고 프롬프트를 잘 설계하면 이 모델들과 프론티어 모델 사이의 격차는 크게 줄어듭니다.

계획 회의에서 아무도 이야기하지 않는 비용 계산

프론티어 모델의 토큰당 API 요금은 경량 모델의 10~30배에 달할 수 있습니다. 이 차이는 대규모 사용량을 계산해 보기 전까지 추상적으로 느껴집니다.

앱이 한 달에 API를 50만 번 호출한다고 가정해 보겠습니다.

같은 기능이지만 이익률은 크게 다릅니다.

일부 팀은 하이브리드 아키텍처를 사용합니다. 단순한 분류 작업은 경량 모델에 보내고, 더 무거운 모델은 복잡한 생성이나 추론 단계에 사용합니다. Martian과 RouteLLM 같은 기업은 이러한 모델 라우팅을 위한 도구를 개발했습니다. 화려한 엔지니어링은 아니지만 최고재무책임자를 눈에 띄게 안심시키는 일입니다.

지연은 사용자 경험의 문제입니다

패스트푸드가 존재하는 데는 이유가 있습니다. 사람들이 언제나 다섯 코스짜리 식사를 원하는 것은 아닙니다. 때로는 당장 답을 원합니다.

프론티어 모델은 더 느립니다. 언제나 차이가 큰 것은 아니지만 실시간 애플리케이션에서 중요할 만큼은 차이가 납니다. 사용자가 대화형 UI, 채팅 인터페이스 또는 실시간 코딩 도우미에서 AI 응답을 기다린다면 응답 지연은 제품에 대한 인식에 직접 영향을 줍니다. 답변에 4~6초가 걸리는 모델은 출력이 기술적으로 더 뛰어나더라도 신뢰하기 어렵게 느껴지기 시작합니다.

경험칙은 간단합니다. 사용자가 로딩 표시를 보고 있다면 추가로 기다리는 매초가 신뢰를 떨어뜨립니다.

Haiku, Mistral, Llama 3.1 8B는 비슷한 부하 조건에서 훨씬 빠르게 실행되며, 때로는 3~5배 빠릅니다. 체감 속도가 중요한 사용자 대상 기능에서 이는 사소한 고려 사항이 아닙니다. 제품에 관한 결정입니다.

모든 것을 바꾸는 프롬프트 엔지니어링이라는 변수

모델 비교 논의에서 간과되는 점이 있습니다. 작은 모델에 잘 설계한 프롬프트를 사용하면 프론티어 모델에 대충 작성한 프롬프트를 사용할 때보다 좋은 결과를 내는 경우가 많습니다.

출력 품질은 모델 능력과 프롬프트 품질 모두의 결과입니다. 명확한 지시, 구조화된 출력 형식, 소수의 시범 예제, 잘 정의된 제약 등 프롬프트 엔지니어링에 투자하면 작은 모델도 겉으로 보이는 능력의 한계를 훨씬 뛰어넘는 성능을 냅니다.

알아 두면 유용한 도구는 다음과 같습니다.

• 프롬프트 파이프라인을 구성하고 최적화하는 LangChain과 DSPy
• 제약 조건에 따른 생성과 구조화된 출력을 위한 Guidance
• 여러 모델에서 체계적으로 프롬프트를 평가하는 PromptFoo

오늘날 실제 서비스에서 가장 인상적인 AI 기능 중 일부는 어떤 능력 순위표에서도 상위 다섯 개에 들지 못할 모델에서 실행됩니다. 단지 아주 좋은 프롬프트를 사용할 뿐입니다.

미세 조정은 계산을 바꿉니다

범용 프론티어 모델과 더 작은 오픈 소스 모델의 비교는 미세 조정을 적용하면 크게 달라집니다. 특정 분야의 데이터, 즉 해당 용어와 경계 사례, 선호하는 출력 형식으로 미세 조정한 Llama 3.1 8B 모델은 그 특정 작업에서 GPT-4o를 능가할 수 있습니다.

이는 가정이 아닙니다. 의료, 법률 기술, 전자상거래 기업들이 이를 반복해서 입증했습니다.

미세 조정은 다음과 같은 곳에서 시작할 수 있습니다.

• 오픈 소스 모델 호스팅, 데이터셋, 학습 인프라를 제공하는 Hugging Face
• 인기 있는 개방형 모델을 빠르고 저렴하게 미세 조정할 수 있는 Together AI
• 직접 GPU 인프라를 관리하지 않고 맞춤 모델을 배포할 수 있는 Replicate

미세 조정에는 데이터 선별과 정리, 컴퓨팅 시간, 평가 작업이라는 초기 투자가 필요합니다. 하지만 특정 분야의 작업을 대량 처리할 때는 경제성이 훨씬 좋아지는 경우가 많습니다.

보안과 데이터 저장 위치를 나중에 생각해서는 안 됩니다

일부 애플리케이션은 제3자 API에 데이터를 전혀 보낼 수 없습니다. 다음 사례를 생각해 보십시오.

• HIPAA에 따라 운영되는 의료 플랫폼
• 개인 식별 정보 또는 규제 대상 거래 데이터를 처리하는 금융 도구
• 데이터 저장 위치에 관한 엄격한 요건이 있는 기업용 소프트웨어

이러한 환경에는 능력이 아무리 뛰어나도 어떤 프론티어 모델 API로도 우회할 수 없는 제약이 있습니다. 자체 호스팅 모델이 온프레미스든 프라이빗 클라우드든 유일한 길입니다. 이는 Llama 3, Mistral, Phi-3 같은 오픈 소스 모델을 자체 인프라에서 실행한다는 뜻입니다. 운영 환경에서 합법적으로 사용할 수 없는 프론티어 모델은 올바른 선택이 아닙니다. 그뿐입니다.

팀이 계속 건너뛰는 평가 단계

대부분의 팀은 가장 비싼 모델이 가장 좋다고 가정하고 테스트 없이 선택합니다. 대신 실제 사용 사례를 대표하는 표본으로 구조화된 평가를 해야 합니다.

다음은 효과적인 절차입니다.

1. 대표적인 입력 100~200개와 예상 출력으로 평가 세트를 구성합니다
2. 현실적인 조건에서 두세 개의 후보 모델에 해당 입력을 처리하게 합니다
3. 정확도, 형식 준수, 어조, 지연, 호출당 비용 등 실제 기준으로 점수를 매깁니다
4. 직관이나 순위가 아닌 데이터에 따라 결정합니다

Braintrust, PromptFoo, Weights & Biases Prompts 같은 도구를 사용하면 연구 경력 없이도 이런 체계적 평가를 할 수 있습니다. 설정에는 몇 시간이 걸립니다. 그렇게 하면 잘못된 모델을 여섯 달 동안 사용하는 일을 피할 수 있습니다.

프론티어 모델이 정말 올바른 선택인 경우

공정하게 말하면 프론티어 모델이 실제로 제값을 하는 작업도 있습니다.

다음 경우에 프론티어 모델을 사용하십시오.

• 작업에 복잡한 다단계 추론이 필요하고 명확한 정형 패턴이 없는 경우
• 출력 품질의 변동으로 큰 비용이 발생하고 처리량은 비교적 적은 경우
• 프롬프트 조정으로 대체할 수 없는 폭넓은 세계 지식이나 섬세한 판단이 필요한 경우
• 프로토타입을 개발 중이고 아직 작업의 경계를 정하지 않은 경우

다음 경우에는 경량 모델을 계속 사용하십시오.

• 작업이 명확하게 정의되어 있고 반복적인 경우
• 현재 처리량에서 속도와 비용이 중요한 경우
• 프롬프트 엔지니어링이나 미세 조정에 투자할 수 있는 경우
• 데이터 저장 위치 또는 규정 준수 요건 때문에 제3자 API를 사용할 수 없는 경우

강력한 모델을 피하자는 뜻이 아닙니다. 순위표에서 가장 유명한 이름이 안전한 선택처럼 느껴진다는 이유로 기본값으로 고르는 대신, 증거에 따라 의도적으로 선택하자는 뜻입니다.

요약

애플리케이션에 사용할 AI 모델을 고르는 일은 명성 경쟁이 되어서는 안 됩니다. 문서상 능력이 가장 뛰어난 모델이 여러분의 문제에 항상 맞는 것은 아니며, 대개는 올바른 선택조차 아닙니다.

작업에 맞는 모델을 고르십시오. 실제 데이터로 평가하십시오. 지연, 비용, 보안 요건, 팀의 프롬프트 엔지니어링 또는 미세 조정 역량을 고려하십시오. 가장 좋은 AI 제품 결정은 어느 회사가 지난 분기에 가장 화려한 수치를 발표했는지가 아니라 이런 구체적인 요소에 근거합니다.

훌륭한 AI 제품을 내놓는 팀이 반드시 가장 강력한 모델을 쓰는 것은 아닙니다. 가장 적합한 모델을 씁니다.