성능은 더 좋고 가격은 더 낮은 AI 모델이 끊임없이 나오고 있습니다. 앱을 출시할 때 적합했던 모델이 몇 주 뒤에는 더 이상 최선의 선택이 아닐 수 있습니다. 그런데 해당 모델 ID가 이미 출시된 iOS 앱이나 배포된 서버에 들어가 있다면, 업그레이드할 때마다 또 하나의 릴리스를 거쳐야 합니다. 사용자가 이전 빌드를 쓰고 있는 상황에서 애플리케이션을 최신 상태로 유지하려면 어떻게 해야 할까요? Haimaker를 사용하면 재배포 없이 애플리케이션이 사용하는 모델을 업데이트할 수 있습니다. 모델 ID로 haimaker/auto를 전송한 다음, 대시보드에서 기본 모델이나 프롬프트별 규칙을 변경하면 됩니다.
이 문제는 모델이 새로 나올 때마다 반복됩니다. 개발자는 자신의 워크로드에 맞춰 품질, 비용, 기능을 테스트해야 합니다. 모델 선택을 배포된 코드에서 분리해 두면, 별도의 릴리스 일정 없이도 테스트 결과에 바로 대응할 수 있습니다.
고정된 모델 ID는 릴리스 후에 금방 구식이 됩니다
고정된 모델 ID를 쓰면 모든 모델 업그레이드가 애플리케이션 릴리스 프로세스에 종속됩니다. 첫 번째 버전을 만드는 단계에서는 감당할 수 있습니다. 하지만 출시 후에는 새로운 모델이 나오거나 가격이 바뀔 때마다 코드를 수정하고, 테스트를 돌리고, 서버를 배포하거나, 모바일 업데이트를 제출해야 할 수 있습니다. 새 모델은 앱 릴리스 주기 사이에도 나옵니다.
iOS 앱의 경우, 클라이언트에 포함된 모델 ID는 업데이트를 설치하지 않은 사용자에게는 바꿀 수 없습니다. Apple은 배포 전에 앱 업데이트를 검토하며, 사용자는 새 빌드가 나온 뒤에도 한참 동안 이전 버전을 그대로 씁니다. API 호출을 백엔드로 옮기면 앱에 프로바이더 키를 넣지 않아도 되지만, 백엔드에 하드코딩된 모델 ID는 여전히 구성 변경이나 배포가 필요합니다.
게이트웨이 엔드포인트만으로는 이 문제를 해결할 수 없습니다. 요청에서 고정된 모델을 지정하면, 호출하는 쪽은 여전히 그 선택에 묶입니다. 예를 들어 OpenRouter는 지정 모델과 자체 openrouter/auto 라우터를 모두 지원합니다. 자동 라우터를 쓰면 모델 선택을 배포된 코드에서 분리할 수 있습니다. Haimaker를 사용하면 애플리케이션 출시 후에도 자신의 프롬프트 클래스에 맞춘 라우팅 정책을 조정할 수 있습니다.
배포된 앱이 새 모델을 따라가려면 어떻게 해야 하나요?
애플리케이션에서는 하나의 안정적인 모델 ID만 전송하고, 선택 정책은 Haimaker에서 관리하세요. 라우터에는 매칭되지 않는 요청에 적용되는 기본 모델과, 특정 유형의 프롬프트를 다른 모델로 보내는 규칙이 있습니다. 라우터는 API 키에 할당됩니다. 대상을 변경하면, 배포된 호출자가 계속 haimaker/auto를 전송하더라도 이후 요청은 다른 모델에 도달할 수 있습니다.
모바일 제품이라면 앱은 백엔드를 호출하고, 백엔드가 Haimaker를 호출하는 구조가 적절합니다. 이렇게 하면 API 키가 사용자 기기에 노출되지 않습니다. 서버 애플리케이션도 같은 패턴을 그대로 쓸 수 있습니다. 요청 코드는 그대로 두고 운영자가 라우터만 조정하면 됩니다. 설정 문서에서 라우터 생성, 기본 모델 선택, API 키 할당, 요청 테스트 방법을 확인할 수 있습니다.
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
위 코드는 기본 모델이 바뀌어도 모델 이름을 수정할 필요가 없습니다. Haimaker는 라우터 구성을 최대 60초간 캐시하므로, 대시보드에서 수정한 내용이 이후 요청에 반영되려면 약 1분 정도 기다리면 됩니다.
기본 모델을 업데이트하고, 저렴한 작업은 따로 라우팅하세요
기본 모델을 변경하면 전체 워크로드가 한 번에 업그레이드됩니다. 규칙을 활용하면 특정 작업에 더 저렴하거나 더 적합한 모델이 나왔을 때 좁은 범위만 변경할 수 있습니다. 이 차이를 이해하는 것이 중요합니다. 예를 들어, 앱은 장문 편집에는 성능 좋은 기본 모델이 필요하지만 짧은 제목 제안은 저비용 모델로 보내도 충분할 수 있습니다. 두 결정 모두 릴리스 후에 호출자의 모델 ID를 바꾸지 않고도 조정할 수 있습니다.
백엔드가 모든 AI 요청을 동일한 라우터로 보내는 글쓰기 앱을 생각해 보겠습니다. 새로 나온 모델이 장문 편집 품질을 높여 줘서, 팀이 테스트를 거친 뒤 라우터의 기본 모델을 변경합니다. 얼마 후 더 저렴한 모델이 제목 제안을 충분히 잘 처리한다는 것을 확인합니다. 팀은 “이 노트에 짧은 제목 5개를 제안해 줘”나 “이 초안에 간결한 제목을 달아 줘” 같은 예시를 넣어 규칙을 추가하고, 해당 규칙을 더 저렴한 모델로 지정합니다. 이전 버전 앱을 쓰는 사용자도 기존 백엔드를 통해 이 두 가지 변경을 모두 적용받습니다.
예시 기반 규칙을 만들 때는 작업당 3~10개의 대표적인 프롬프트를 사용하세요. 매칭되면 요청이 해당 규칙의 대상 모델로 라우팅되고, 매칭되지 않는 요청은 기본 모델을 사용합니다. 기능 검사를 통해 규칙이 비전, 도구 사용, 구조화 출력 요청을 처리할 수 없는 모델로 보내는 것을 방지합니다. 라우팅 로그에서 실제로 선택된 모델과 해당 규칙을 확인할 수 있습니다. 매칭 및 폴백 메커니즘에 대해 자세히 알고 싶다면 라우팅 워크스루와 비용 라우팅 가이드를 참조하세요.
출시 후 팀에게 무엇이 달라지나요?
가장 큰 이점은 모델 선택이 릴리스 일정이 아니라 워크로드를 따를 수 있다는 점입니다. 팀은 새 기본 모델을 도입하거나, 반복적인 프롬프트 클래스를 더 저렴한 모델로 옮기거나, 결과가 나빠지면 이전 대상으로 되돌릴 수 있습니다. 서버 코드와 설치된 모바일 클라이언트는 동일한 API 요청을 계속 보냅니다. 개발자의 역할은 라우팅 결정을 테스트하고 검토하는 쪽으로 바뀝니다.
| 출시 후 변경 사항 | 코드에 고정된 모델 사용 시 | haimaker/auto 사용 시 |
|---|---|---|
| 더 나은 범용 모델이 등장 | 모델 ID를 바꾸고 코드 또는 구성을 릴리스 | 테스트한 후 라우터의 기본 모델만 변경 |
| 더 저렴한 모델이 특정 프롬프트 클래스에 적합 | 애플리케이션에 라우팅 로직을 추가하고 배포 | 해당 프롬프트 클래스에 규칙 추가 또는 수정 |
| 모델 변경으로 출력 품질이 저하 | 코드 또는 구성 변경을 되돌림 | 이전 라우터 대상으로 복원 |
| 사용자가 이전 모바일 빌드를 사용 중 | 앱에 포함된 모델 ID가 오래된 상태로 남음 | 백엔드가 최신 라우터 정책을 사용함 |
서버 릴리스에 다른 작업이 묶여 있을 때도 이 방식이 유용합니다. 모델 변경 결정을 다음 배포 일정까지 미룰 필요가 없습니다. 워크로드별로 별도 라우터를 사용하려면 서로 다른 API 키에 할당하면 됩니다. Haimaker는 키당 하나의 라우터를 지원합니다.
라우팅 변경에도 코드 변경과 똑같은 판단이 필요합니다. 대시보드 샌드박스에서 프롬프트가 어떤 모델을 선택할지 미리 볼 수 있지만, 답변 품질까지 보장해 주지는 않습니다. 제안된 모델로 대표적인 프롬프트를 실행해 보고, 실제 출력을 확인하고, 라우팅 로그를 살펴보고, 품질이 떨어지면 이전 대상으로 되돌리세요. Haimaker가 바꿔 주는 것은 모델 선택입니다. 프롬프트, 도구 스키마, 애플리케이션 동작을 바꾸려면 여전히 애플리케이션 쪽 작업이 필요합니다.
다음 릴리스를 위해 모델 선택을 준비해 두세요
라우터를 생성하고, 기본 모델을 선택하고, 백엔드가 사용하는 API 키에 할당하세요. 요청에서 haimaker/auto를 전송한 다음, 워크로드를 대표하는 프롬프트 몇 개로 테스트해 보세요. 새 모델이 나오면 기본 모델이나 좁은 범위의 규칙을 변경하기 전에 해당 프롬프트로 먼저 평가해 보세요. Haimaker 문서에서 라우터 설정, 테스트 샌드박스, 라우팅 히스토리를 확인할 수 있습니다.
새 모델은 다음 앱 릴리스보다 먼저 나올 수 있습니다. 모델 선택을 Haimaker에 맡겨 두면, 개발자가 릴리스 주기를 새 코드가 필요한 변경에 집중하는 동안에도 애플리케이션은 최신 모델을 사용할 수 있습니다.
자주 묻는 질문
출시된 모바일 앱에서 AI 모델을 어떻게 변경할 수 있나요?
앱이 백엔드를 호출하고, 백엔드가 Haimaker에 model: ‘haimaker/auto’를 전송하도록 하세요. 그러면 새로운 모바일 빌드를 제출하지 않고도 대시보드에서 라우터의 기본 모델이나 프롬프트 규칙을 변경할 수 있습니다. 라우터 변경 사항은 최대 60초 후에 적용됩니다.
Haimaker를 통한 모델 전환에 서버 배포가 필요한가요?
아니요. 배포된 서버가 이미 라우터에 할당된 API 키와 함께 model: ‘haimaker/auto’를 전송하고 있다면, 대시보드에서 라우터의 모델 대상을 변경할 수 있습니다. 애플리케이션 프롬프트, 요청 형식, 코드 변경은 여전히 일반적인 배포가 필요합니다.
간단한 프롬프트만 더 저렴한 모델로 옮길 수 있나요?
네. 간단한 작업에 대해 3~10개의 예시 프롬프트로 규칙을 추가하고 더 저렴한 대상 모델을 선택하세요. Haimaker는 대상 모델이 해당 요청을 지원하는지 확인하며, 규칙에 매칭되지 않는 프롬프트는 라우터의 기본 모델을 사용합니다.