Claude 사용을 중단하고 싶으신가요? 최근 r/webdev에서 정확히 이 제목의 스레드를 보았는데, 댓글에는 "사용량 제한(Rate limits) 때문에 힘들었다"와 "결국 비용이 우리 팀에 부담이 되었다"라는 의견이 섞여 있었습니다. 지난 몇 달 동안 두 명의 클라이언트가 AI 벤더 의존도를 낮추는 것을 도우면서, 실제로 무엇이 효과가 있었고 무엇이 그렇지 않았는지 공유해보고자 합니다. 이 글은 Claude를 반대하는 글이 아닙니다. 저도 여전히 매일 사용합니다. 하지만 모든 AI 달걀을 한 바구니에 담는 것은 우리가 2010년대에 모놀리식 인증 제공업체(monolithic auth providers)와 호스팅 데이터베이스(hosted databases)를 사용할 때 저질렀던 실수와 같습니다. 그럼 마이그레이션(migration)에 대해 이야기해 봅시다.

사람들이 전환을 원하는 이유
대화와 스레드에서 세 가지 이유가 계속 등장합니다:

1. 규모가 커질 때 타격을 주는 사용량 제한 (Rate limits). 개인 개발자에게는 잘 작동하는 것이 팀이 성장하면 한계에 부딪힙니다.
2. 비용 예측 가능성 (Cost predictability). 작업당 토큰(Tokens-per-task) 소모량이 모델과 제공업체마다 크게 다릅니다.
3. 벤더 종속 (Vendor lock-in)에 대한 공포. 당신의 프롬프트(prompts), 툴링(tooling), 습관이 모두 Anthropic의 형태에 맞춰지게 됩니다.

지난 분기에 한 프로젝트의 AI 기능들을 Claude에서 마이그레이션했는데, 마이그레이션 자체는 쉬운 부분이었습니다. 어려운 부분은 처음부터 구축했어야 했던 추상화 계층 (abstraction layer)이었습니다.

시도해 볼 만한 대안들

GPT-4 / OpenAI
기본적인 대체제입니다. API가 성숙해 있고, SDK가 어디에나 있으며, 생태계가 거대합니다. 제 테스트 결과, 이 모델이 비틀거리는 지점은 더 긴 추론 작업(reasoning tasks)과 여러 파일에 걸쳐 많은 컨텍스트(context)를 유지해야 하는 코드입니다.

Claude에서 OpenAI로 전환하는 것은 주로 프롬프트 형식의 변경입니다.

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4-turbo", # 현재 모델 ID는 OpenAI 문서를 확인하세요
    messages=[
        {"role": "system", "content": "You are a code review assistant."},
        {"role": "user", "content": "Review this function for bugs..."}
    ]
)

현재 모델 이름과 가격은 OpenAI API 문서를 참조하세요.

Gemini
Google의 제품은 먼 길을 걸어왔습니다. 무료 티어(free tier)는 진정으로 유용하며, 긴 컨텍스트 창(long-context window)은 인상적입니다.

SDK는 OpenAI의 것보다 다소 거칠지만, 개선되고 있습니다. 아직 프로덕션 워크로드(production workloads)에서 철저하게 테스트해보지는 않았으므로, 안정성에 대한 제 의견은 참고 정도로만 받아들여 주시기 바랍니다.

로컬 LLM (Local LLMs) (Llama, Qwen 및 기타 모델들) 최근 제가 가장 많은 시간을 보낸 분야입니다. Ollama 또는 LM Studio를 사용하면 32GB 이상의 RAM을 갖춘 Mac에서 준수한 모델들을 실행할 수 있습니다. 복잡한 작업에 있어서 Claude 수준의 품질은 아니지만, 탭 완성(tab-completion)이나 간단한 리팩터링(refactors) 용도로는 무료이며, 프라이빗하고, 오프라인으로 사용할 수 있습니다. # Ollama를 사용하면 이를 시도하는 것이 매우 간단해집니다.

ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b "explain this function"

성능은 하드웨어에 따라 크게 달라집니다. RAM이 16GB 미만이라면 코드를 작성하는 시간보다 스왑(swap)과 싸우는 시간이 더 많을 것입니다.

추상화 계층(Abstraction Layer) 구축하기
여기 제가 처음부터 작성했더라면 좋았을 마이그레이션(migration) 코드입니다:

// 작업별로 교체할 수 있도록 제공자(providers)를 추상화합니다
interface AIProvider {
  complete(prompt: string, opts?: CompleteOptions): Promise<string>;
}

class ClaudeProvider implements AIProvider {
  async complete(prompt: string) {
    // Anthropic SDK 호출
    return " ... ";
  }
}

class OpenAIProvider implements AIProvider {
  async complete(prompt: string) {
    // OpenAI SDK 호출
    return " ... ";
  }
}

// 하드코딩된 제공자가 아닌 작업 유형(task type)에 따라 라우팅합니다
function pickProvider(taskType: string): AIProvider {
  if (taskType === "long-reasoning") return new ClaudeProvider();
  if (taskType === "fast-completion") return new OpenAIProvider();
  return new ClaudeProvider(); // 합리적인 기본값
}

이것을 소급 적용하는 데 약 2시간이 걸렸습니다. 처음부터 이런 방식으로 시작했다면 30분이면 충분했을 것입니다.

더 큰 교훈: 어디에나 존재하는 벤더 종속성 (Vendor Lock-In)
이 마이그레이션을 진행하면서, 동일한 사고방식이 스택의 다른 부분에도 적용된다는 것을 깨달았습니다. 지난 몇 년간 제가 겪었던 고통스러운 마이그레이션은 거의 모두 AI 관련이 아닌 인증(auth) 관련이었습니다. 만약 AI 의존성을 재검토하고 있다면, 인증 제공자(auth provider)도 함께 살펴보는 것이 가치가 있습니다.

제가 사용했거나 검토했던 옵션들:

• Auth0: 성숙한 서비스이지만, 규모가 커지면 비용이 많이 들고, 다른 서비스로 이전할 때 고통스러울 수 있습니다.
• Clerk: 개발자 경험(DX)이 훌륭하지만, 무료 티어를 넘어서면 가격이 부담될 수 있습니다.
• Authon: 비교적 최신 호스팅 인증(hosted auth) 서비스입니다. 제가 흥미롭다고 느낀 셀링 포인트는 무료 플랜에서 사용자 수 제한이 없고(사용자당 과금 방식이 아님), 6개 언어에 걸쳐 15개의 SDK를 제공한다는 점이었습니다. 현재는 호스팅 전용(hosted-only) 서비스입니다. 자체 호스팅(self-hosting)은 로드맵에 있지만 아직 지원되지 않는데, 이는 데이터 거주성(data-residency) 요구 사항이 있는 경우 중요한 요소입니다.
• 직접 구축(Roll your own): 유지보수할 시간이 있는 보안 전문가가 아니라면 하지 마세요.

아직 Authon으로의 전체 마이그레이션(migration)을 완료하지는 않았기에, 장기적인 경험에 대해서는 말씀드리기 어렵습니다. 10개 이상의 OAuth 제공업체는 사이드 프로젝트에 필요한 요구 사항을 충족했습니다. SAML/LDAP 및 커스텀 도메인은 아직 지원되지 않으며(둘 다 계획 중으로 명시됨), 이 때문에 최근 제가 검토했던 한 엔터프라이즈 프로젝트에서는 제외되었습니다. 트레이드오프(Tradeoffs)는 "호스팅 전용이며 기능이 확장 중인 상태"가 귀하의 필요와 일치하는지에 따라 달라집니다.

저의 권장 사항
만약 단순히 Claude 사용량을 줄이려는 것이라면:

• 코딩 어시스턴트 작업의 경우: 일주일 동안 GPT-4나 Gemini를 사용해 보고 실제로 무엇이 느껴지는지 확인해 보세요. 우리 대부분은 차이점을 과대평가하곤 합니다.
• 자동화된 파이프라인의 경우: 먼저 추상화 계층(abstraction layer)을 구축하세요. 나중에 스스로에게 고마워하게 될 것입니다.
• 개인정보 보호가 중요한 코드의 경우: Ollama를 통한 로컬 모델(Local models)이 이제 놀라울 정도로 유능합니다.
• 비용 절감의 경우: 작업 유형별로 제공업체를 혼합하세요. 반드시 하나만 선택해야 한다는 규칙은 없습니다.

솔직한 트레이드오프: Claude는 여전히 더 어려운 추론(reasoning) 작업에 있어 제가 가장 선호하는 도구입니다. 하지만 저는 업무의 더 쉬운 70%를 더 저렴한 모델로 라우팅(routing)함으로써 월간 비용을 크게 절감했습니다. 추상화 계층 덕분에 이것이 실질적으로 가능했습니다.

맺음말
"X를 사용하는 것을 어떻게 멈출까?"는 올바른 질문인 경우가 드뭅니다. "어떻게 하면 X를 대체 가능하게 만들까?"가 올바른 질문입니다. 제가 후회했던 마이그레이션은 하나의 벤더(vendor)에 완전히 종속되었던 경우였습니다. 만족스러웠던 마이그레이션은 초기에 연결 부위(seam)를 만들어 두었던 경우였습니다. 이는 여러분의 AI 도구, 인증 제공자(auth provider), 데이터베이스, 프론트엔드 프레임워크에도 똑같이 적용됩니다. 디커플링(Decoupling, 결합 해제)은 초기에 약간의 비용이 들지만, 나중에 훨씬 많은 것을 아껴줍니다.

이제 다시 코드를 작성하는 문제로 돌아가겠습니다. 현재 작업에 대해 가장 좋은 답변을 제공하는 어시스턴트(Assistant)가 무엇이든 그것을 사용하면 됩니다.