AI를 선택적 기능으로 만들기: 1인 개발자를 위한 실전 설계

왜 선택적 AI가 필요할까

AI를 서비스에 얽어두면, 모델 서비스가 중단될 때 전체 앱이 멈추는 상황을 자주 보게 된다. 특히 1GB VPS 같은 저예산 환경에서는 외부 API 호출 비용이 급증하거나, 네트워크 장애가 발생하면 바로 서비스 장애로 이어진다. 따라서 AI는 옵션이어야 하고, 오프라인 상태에서도 핵심 기능이 정상 동작하도록 설계해야 한다. 이 글은 WorldScript Studio가 사용한 네 가지 메커니즘을 살펴보며, 내 사이드 프로젝트에 적용 가능한지 평가한다.

내 프로젝트에 적용 가능한 패턴

1. 통합 Provider Seam – 모든 AI 호출을 하나의 팩터리(createLanguageModelForWorldScript)를 통해 라우팅한다. 이렇게 하면 키 관리, 재시도 로직, 오프라인 판단을 한 곳에 모을 수 있다. 저예산 Node.js/Express 서비스라면 services/ai/providerFactory.ts 같은 파일을 만들어, OpenAI, Ollama 등 여러 백엔드를 동일한 인터페이스로 감싸면 된다. ts export type LanguageModelConfig = | { provider: 'openai'; modelId: string; apiKey: string } | { provider: 'ollama'; modelId: string; baseURL: string; apiKey: string };

export function createLanguageModel(config: LanguageModelConfig): LanguageModel { /* … */ }

1. Policy Gates – 사용자가 “cloud off” 모드를 선택했을 때 코드 레벨에서 강제한다. 정책 위반 시 throw를 이용해 즉시 실패하도록 하면 테스트가 쉬워지고, 실수로 로컬 전용 모드에서 클라우드 호출이 섞이는 일을 방지한다.
   ts
   export function assertCloudAllowed(provider: AIProvider, mode: string): void {
   if (mode === 'local' && provider !== 'local') {
   throw new Error('Cloud provider blocked in local mode');
   }
   }

2. 실패 분류와 UI 메시지 – 오류를 transient, auth, offline 등으로 분류하고, UI가 정확히 어떤 조치를 취해야 할지 알려준다. 저예산 프로젝트에서는 재시도 로직을 간단히 setTimeout으로 구현하고, offline이면 바로 UI에 “네트워크가 끊겼습니다”를 표시하면 된다.

3. Fallback Layer – AI가 완전히 불가능할 때는 로컬 로직(예: 간단한 템플릿)으로 대체하거나 null을 반환한다. 이렇게 하면 사용자는 “AI 기능이 비활성화되었습니다”라는 명확한 피드백을 받는다.

비용·운영 관점에서의 결론

내가 보는 가장 큰 장점은 운영 비용을 제어할 수 있다는 점이다. 한 번에 여러 API 키를 관리하거나, 외부 모델 호출에 의존하지 않아도 되므로 VPS 메모리·CPU 사용량을 예측하기 쉽다. 반면, 로컬 대체 로직을 구현하려면 초기 개발 시간이 늘어난다. 현재 진행 중인 블로그 자동 요약 서비스에선 위 구조를 그대로 도입해, 클라우드 모델이 다운돼도 기본 템플릿 요약을 제공하도록 할 계획이다. 즉, 바로 적용 가능하지만, fallback 구현에 약간의 투자(코드 30~40줄 정도)가 필요하다.

---

원문: AI as an Optional Capability, Not an Application Dependency