Groq가 제가 의존하던 모델을 사용 중단했을 때 배운 것

저는 1인 창업자이며, 비즈니스 웹사이트에서 잠재 고객(lead)을 적격화하는 AI 채팅 위젯이 제 제품입니다. 이 제품은 Cloudflare Pages, Netlify Functions, Supabase, 그리고 LLM으로 Groq를 이용한 무료 티어 스택으로 운영되었습니다. 잘 작동했습니다. 그러던 어느 날 Groq가 제가 제품 전체를 구축했던 Llama 3.3 70B 모델을 사용 중단(deprecated)하게 되었습니다.

처음에는 극적인 문제가 발생하지 않았습니다. 하지만 저는 이 상황에 대한 계획이 전혀 없다는 것을 깨달았고, 그것이 진짜 문제였습니다.
실제로 문제가 된 부분
제 모델 이름은 몇 군데에 하드코딩되어 있었습니다. 시스템 프롬프트는 그 특정 모델의 동작에 맞춰 조정(tuned)되었었습니다. 그리고 적격화 흐름(qualification flow) 자체가 깨끗한 구조적 출력(structured output)을 반환하는 것에 의존하고 있었습니다.

'비슷한' 모델로 교체하는 것은 한 줄의 코드로 해결되지 않았습니다. 서로 다른 모델들은 지침을 다르게 따르고, JSON 형식을 다르게 만들며, 긴 시스템 프롬프트를 다르게 처리합니다. 제 프롬프트가 작동했던 이유는 제가 자신도 모르게 그 특정 모델의 특이점(quirks)에 맞춰서 구성했기 때문입니다.

교훈 1: 코드가 그렇지 않더라도, 당신의 프롬프트는 모델과 결합되어 있습니다 (coupled to your model).

OpenRouter로 이동한 이유

저는 두 가지를 원했습니다. 저를 무너뜨릴 수 있는 단일 공급업체(single provider)가 없다는 것, 그리고 앱의 절반을 재배포하지 않고도 모델을 변경할 수 있는 능력입니다.

OpenRouter는 여러 모델과 공급업체를 앞에 두고 하나의 OpenAI와 호환되는 API를 제공합니다. 저에게 있어 마이그레이션은 주로 기본 URL과 환경 변수(env var)만 바꾸는 것이었습니다:

// netlify/functions/chat.js

const MODELS = (process.env.LLM_MODELS || "").split(","); // 우선순위가 높은 모델부터, 그 다음 폴백 모델들

async function callLLM(messages) {

for (const model of MODELS) {
```
try {
const res = await fetch("https://openrouter.ai/api/v1/chat/completions", { ... }
// ...
} catch (e) {
throw new Error("모든 모델 실패");
}
}

이제 모델 목록은 환경 변수에 존재합니다. 만약 어떤 모델이 사용 중단된다면, 저는 코드를 수정하는 것이 아니라 설정 값(config value)만 변경하면 됩니다.

교훈 2: 모델 이름을 설정(config)처럼 취급하고 항상 대체 방안(fallback)을 마련하세요.
마이그레이션 과정 자체에 대하여
[실제로 무엇을 했는지 설명하세요: 어떤 모델로 옮겼는지, 얼마나 걸렸는지, 프롬프트에서 무엇이 고장 났는지, 그리고 무엇을 재조정해야 했는지. "새로운 모델이 JSON을 마크다운 울타리 안에 감쌌고 내 파서가 작동하지 않았다"와 같은 구체적인 예시 하나만으로도 일반적인 조언 한 단락보다 가치가 있습니다.]

완전히 전환하기 전에, 저는 두 모델 모두를 통해 실제 대화 세트를 실행하고 리드 자격 검증(lead qualification) 결과를 비교했습니다. 그 테스트 세트가 지금 제 레포지토리에서 가장 가치 있는 파일입니다. 다음번에는 이걸 더 일찍 만들었어야 했습니다.

교훈 3: 소규모 회귀 테스트(regression set)용 실제 입력 데이터를 유지하세요. 모델 변경은 느낌만으로 판단할 수 없습니다.
왜 무료 모델로 프로덕션 환경을 운영해서는 안 되는가
이것은 제가 과거의 저에게 해주고 싶은 말입니다. 무료 등급(free tiers)과 무료 모델은 구축하고 검증하는 데는 훌륭합니다. 하지만 고객이 의존하는 제품 부분에 대해서는 위험한 기반이 됩니다:

안정성 보장이 없습니다. 무료 모델은 경고가 거의 없이 더 강하게 속도 제한(rate limited)되거나, 느려지거나, 제거될 수 있습니다. 저에게 실제로 일어난 일이기도 하며, 이것은 비즈니스 모델이 설계된 대로 작동하는 방식입니다.
속도 제한은 바로 성공했을 때 발생합니다. 무료 한도는 테스트 사용자 5명 정도로는 괜찮습니다. 하지만 트래픽 급증이나 고객의 광고 캠페인이 필요할 때가 가장 많은 용량을 요구합니다.
아무도 당신에게 지원을 해줄 의무가 없습니다. 새벽 2시에 문제가 생겼을 때, SLA(서비스 수준 계약)도 없고 에스컬레이션 할 사람도 없습니다.
데이터 처리 방식이 다를 수 있습니다. 무료 엔드포인트는 유료 엔드포인트와 다른 로깅 또는 학습 약관을 가질 수 있습니다. 만약 사용자들이 고객 대화를 당신의 제품을 통해 전송한다면, 출시하기 전에 그 약관들을 읽어보세요. [사용하는 특정 모델에 대한 현재 약관을 확인하세요.]

각 실패한 응답이 고객에게 손실된 리드가 되는 제품이라면, 추론(inference) 비용을 지불하는 것이 제품 비용의 일부입니다. 이 지출은 서비스 중단(outage) 비용과 비교하면 적습니다.

제 규칙은 이제 이렇습니다: 프로토타입과 내부 도구에는 무료 등급(free tier)을 사용하고, 고객이 의존하는 모든 것에는 유료로 보호 장치를 마련합니다.

다르게 할 것이 있다면:

• 처음부터 설정 파일에 모델 이름을 명시할 것입니다.
• 출시 전에 실제 대화로 구성된 작은 테스트 세트를 구축할 것입니다.
• 필요하기 전에 대체(fallback) 모델을 추가할 것입니다.
• 유료 고객이 의존하게 되는 즉시 추론 계층(inference layer) 비용을 지불할 것입니다.

제가 이것으로 무엇을 만들었는지 보고 싶다면 Zappiq AI가 있지만, 위의 교훈은 LLM API를 기반으로 구축된 모든 앱에 적용됩니다.

모델 사용 중단(model deprecation)이 예기치 않게 발생한 적이 있나요? 어떻게 대처했는지 듣고 싶습니다.