AI 제품의 모델 선택과 운영 전략

Part 7. GPT냐 Claude냐, 언제 무엇을 왜 써야 할까?

Jun 17. 2025

Part 7. 핵심 요약

- LLM 비교/선택은 제품이 해결하고자 하는 문제와 제공하려는 경험에 기반해야 한다.
- 단일 모델보다 유연한 멀티 모델 전략이 더 일관된 사용자 경험을 주기도 한다.
- 비용, 속도, 평가 구조를 고려한 운영 전략이 곧 제품 품질을 결정 짓는다.

아마 AI 제품에 대해 이야기 나눌 때에 (실제로 나도) 자주 듣고, 묻던 질문일 것이다.

“어떤 모델 쓰세요? GPT-4o, Claude Opus, Gemini 1.5? 아니면 자체 모델이에요?”

익숙한 질문이지만, PM의 시선에서 보면, 이 질문은 단순한 기술 스택의 선택이 아니다. 우리가 어떤 모델을 쓰는지가 아니라 '왜' 그 모델을 썼는지가 더 중요하다는 점이다.

모델 선택은 기술적인 우위의 문제가 아니라, 우리가 설계하는 사용자 경험, 해결하고자 하는 과제, 제품의 전략 방향까지 담겨 있는 의사결정이다. LLM은 단지 호출 가능한 API가 아니라, 어떤 결과를 만들고자 할 때 그 과정 전체를 설계하는 도구다.

그렇다면 우리는 모델을 어떻게 바라보고, 선택하고, 운영해야 할까?

1. 결국 제품 전략과 유저 경험의 문제

LLM을 고를 때 우리는 성능 벤치마크나 업계 순위를 먼저 본다. 하지만 PM의 관점에서 더 중요한 질문은 따로 있다.

"이 기능이 사용자에게 어떤 경험을 줘야 하는가?"
"이 제품은 어떤 문제 해결을 핵심 가치로 삼고 있는가?"

이 질문에 대한 답이 곧 모델 선택의 우선순위를 결정짓는다.

실시간 응답이 중요한 인터페이스에서는 latency가 낮은 모델이 우선이다.

정보 요약이나 구조화가 필요한 기능이라면 long-context 처리와 요약 성능이 핵심이다.

짧고 빠른 액션 중심이라면 단가가 낮고 응답이 민첩한 모델이 더 적합하다.

결국 모델은 단순히 “무엇이 더 좋은가”가 아니라, "이 문제에 더 적합한 해결책은 무엇인가"라는 질문을 던지게 하는 존재다. 때로는 가장 고도화된 모델보다, 제약된 환경에서도 일관된 결과를 낼 수 있는 모델이 더 유용할 수 있다. 우리가 모델을 선택할 때 중심에 둬야 할 기준은 제품이 제공하려는 가치와 사용자에게 기대하는 행동 변화다.

2. 하나로는 부족하다

AI 제품을 실제로 만들다 보면, 하나의 모델로 모든 시나리오를 만족시키긴 어렵다. 기능마다 요구하는 품질, 속도, 비용이 다르고 사용자의 기대도 상황마다 크게 달라지기 때문이다. 그래서 많은 AI 제품은 기능별로 서로 다른 모델을 조합하는 멀티 모델 전략을 택한다.

나 또한 비용, 속도, 기능 목적 등을 고려해 단일 모델이 아닌, 목적에 따라 다양한 모델을 섞어 쓰는 구조를 설계했다. 반복 작업은 저비용 모델로, 고부가가치 기능은 고성능 모델로 처리하고, 경량화 가능한 응답은 캐시 방식으로 대체했다. 하지만 이 전략은 단순한 기술 구현이 아니다. 제품 구조와 UX 일관성까지 함께 설계해야 비로소 실현 가능한 전략이다. ~~상당한 고민이 필요한 비용 시뮬레이션도 놓칠 수 없다...~~

여기서 중요한 개념이 바로 "추상화 계층(abstraction layer)"이다. 이 구조를 통해 내부적으로는 다양한 모델을 유연하게 운영하면서도, 사용자에게는 하나의 일관된 AI가 응답하는 듯한 경험을 제공할 수 있다.

이를 위해선 내부적으로 동일한 프롬프트를 여러 모델에 적용해 비교 실험하고, 실제 사용자 피드백과 응답 로그 데이터를 기반으로 기능별 최적의 모델 조합을 찾아가는 지속적인 개선 루틴이 필요하다.

나의 경우에는 하나의 기능에서도 여러 상용 및 오픈소스 모델을 병렬 비교하며 품질, 속도, 비용의 균형을 반복적으로 실험했다. MLE, AI 엔지니어 동료들과 하루 이틀짜리 소규모 실험을 반복했고, 그 결과를 기반으로 모델 전략과 판단 기준을 점진적으로 구성해 나갔다.

모델은 한 번 고르면 끝나는 선택지가 아니라, 지속적으로 실험하고 다듬어야 할 전략적 자산이다. 이 구조를 설계하고 유지하는 역량이 바로 AI PM(Product Manager)에게 요구되는 핵심 능력 중 하나다.

3. 운영은 단순 호출만이 아니다

모델을 붙였다고 끝이 아니다. 오히려 진짜 운영 과제는 그 다음부터 시작된다.

AI 제품은 단순히 "질문하면 답하는 시스템"으로 끝이 아니다. 사용자의 요청 수, 기능별 사용 패턴, 유료화 구조, 기대하는 응답 수준 등 여러 현실적인 제약 안에서 모델이 ‘지속적으로’ 잘 작동해야 한다. 이를 위해서는 품질 관리에 필요한 핵심 요소를 운영 구조로 갖춰야 한다. (Part 3 의 품질 판단 기준 참고)

1️⃣ 비용(Budget)

모델마다 호출 단가가 다르고, 요청당 토큰 소비량도 천차만별이다. PM은 사용자수 보다도, "한 번의 요청에 얼마나 많은 토큰이 사용되고, 그게 제품 전체 비용 구조에 어떤 영향을 미치는가"를 계산해야 한다. 기능별로 고성능 모델을 유지할 것인지, 경량 모델로 전환하거나 프리미엄 기능으로 분리할 것인지 등은 제품 전략과 비즈니스 모델 설계의 일부다.

2️⃣ 속도(Latency)

사용자는 모델의 이름보다 응답 속도를 먼저 느낀다. PM은 기능별 latency 기준을 설정하고, 빠른 응답을 위해 캐싱, retrieval 기반 응답, fallback 구조 등 속도를 고려한 구조적 대응을 설계해야 한다.

3️⃣ 평가(Evaluation)

생성형 AI 모델은 같은 입력에도 매번 다른 출력을 낼 수 있기 때문에, "이 기능이 실제 유저에게 가치 있는 결과를 주는가?"를 판단할 기능 단위의 평가 기준이 필요하다. 샘플링 리뷰, 프롬프트 A/B 테스트, 사용자 피드백 수집 등을 통해 정확도, 일관성, 유용성을 주기적으로 측정해야 하며, 제품 출시 이후에는 시스템 프롬프트 구조, 유저 시나리오 기반 (자동화) 테스트, 인터널 평가 루틴 등을 기반으로 지속 개선이 가능하도록 설계해야 한다.

특히 요즘처럼 모델 성능, 가격, 기능이 빠르게 업데이트되는 시기에는 출시 전에도, 출시 후에도 모델 비교 실험이 일상처럼 수행되는 구조가 필요하다. 오픈소스든, 상용 모델이든 모든 LLM은 속도-정확도-비용-UX의 맥락 속에서 전략적으로 평가돼야 한다. 결국 이 모든 과정이 제품 경험의 일관성과 신뢰도를 좌우하게 된다.