Source: Dev.to

왜 AI 에이전트는 단일 공급자에 의존해서는 안 되는가

AI 에이전트를 설계할 때 가장 흔히 저지르는 실수 중 하나는 하나의 클라우드 제공업체 혹은 특정 AI 서비스에 전적으로 의존하도록 만드는 것이다. 처음에는 구현이 간단하고 비용도 저렴해 보이지만, 장기적으로는 벤더 락인(vendor lock‑in), 가용성 위험, 비용 상승 등 여러 문제에 직면하게 된다. 아래에서는 이러한 위험을 구체적으로 살펴보고, 멀티‑프로바이더 전략을 채택해야 하는 이유를 설명한다.

---

1️⃣ 벤더 락인의 위험

• 가격 변동: 대부분의 클라우드 제공업체는 사용량 기반 요금을 적용한다. 서비스가 인기를 끌수록 가격이 상승할 수 있다.
• 기능 제한: 특정 공급자의 API가 업데이트되면, 기존 코드가 깨지거나 새로운 기능을 바로 활용하지 못할 수 있다.
• 이탈 비용: 한 공급자에 종속되면 다른 플랫폼으로 옮기는 데 필요한 마이그레이션 비용과 시간은 상당히 커진다.

예시: 2022년 한 스타트업이 단일 LLM 제공업체에 의존했지만, 해당 업체가 가격을 2배로 인상하면서 급격한 비용 폭증을 겪었다. 결국 다른 모델로 전환하려면 데이터 파이프라인 전체를 재구축해야 했다.

---

2️⃣ 가용성 및 복원력

• 단일 장애점(SPOF): 한 공급자에만 의존하면 해당 서비스가 다운될 경우 에이전트 전체가 작동을 멈춘다.
• 지역 제한: 일부 클라우드 서비스는 특정 지역에만 데이터 센터를 보유하고 있어, 지연 시간(Latency)이나 규제 문제를 야기한다.

멀티‑프로바이더 접근법은 서로 다른 공급자의 인프라를 조합해 자동 페일오버와 로드 밸런싱을 구현함으로써 이러한 위험을 크게 감소시킨다.

---

3️⃣ 비용 최적화

• 가격 경쟁: 여러 공급자를 동시에 사용하면 각 서비스의 가격 변동을 실시간으로 비교해 가장 저렴한 옵션을 선택할 수 있다.
• 스팟 인스턴스/프리 티어 활용: 공급자마다 제공하는 무료 티어나 스팟 인스턴스가 다르다. 이를 조합하면 전체 운영 비용을 크게 낮출 수 있다.

---

4️⃣ 데이터 주권 및 규제 준수

• 데이터 위치: 일부 국가에서는 데이터가 물리적으로 해당 국가 안에 있어야 한다는 규제가 있다.
• 프라이버시 정책: 각 공급자는 서로 다른 개인정보 보호 정책을 가지고 있다. 멀티‑프로바이더 전략을 통해 규제에 맞는 공급자를 선택할 수 있다.

---

5️⃣ 구현 팁

---

6️⃣ 결론

AI 에이전트를 단일 공급자에 묶어두면 초기 개발은 쉬워 보이지만, 장기적인 비용, 가용성, 규제 측면에서 큰 리스크를 감수하게 된다. 멀티‑프로바이더 아키텍처를 도입하면:

1. 벤더 락인을 방지하고 가격 협상력을 확보한다.
2. 가용성을 높여 서비스 중단 위험을 최소화한다.
3. 규제와 데이터 주권 요구사항을 유연하게 충족한다.
4. 비용을 최적화하고 경쟁력을 유지한다.

따라서 AI 에이전트를 설계할 때는 추상화, 컨테이너화, 동적 라우팅 같은 모듈식 접근 방식을 채택해, 언제든지 공급자를 교체하거나 추가할 수 있는 유연성을 확보하는 것이 가장 현명한 선택이다.

Setup

저는 OpenClaw를 지속적인 AI 에이전트로 사용하고 있습니다. 이 에이전트는 연구, 콘텐츠 초안 작성, 코드 리뷰, 예약된 검사, 그리고 다양한 자동화 작업을 처리합니다. 지난 한 달 동안 저는 꽤 정교한 시스템을 구축했습니다:

• 다양한 간격으로 실행되는 14개의 크론 작업
• 중앙 모델이 전문화된 하위 에이전트에게 작업을 위임하는 brain‑as‑router 아키텍처
• 세션 간 연속성을 제공하는 메모리 파일들로 가득 찬 작업 공간

모두 단일 공급자를 대상으로 설정되었습니다.

이것이 위험 요소라는 것을 알고 있었습니다. “공급자 독립성을 위한 설계”가 할 일 목록에 있었지만, 시스템이 너무 잘 작동해서 마이그레이션이 계속해서 다음 주로 미뤄졌습니다. 전형적인 경우죠.

진실의 순간

제공자가 지원을 중단했을 때, 저는 마이그레이션을 위해 3일의 기간이 주어졌습니다. 실제 전환은 오후에 끝났습니다—제가 빠르기 때문이 아니라, 아키텍처가 이미 올바르게 구성돼 있었기 때문입니다.

OpenClaw는 모델을 시스템과 분리합니다:

• 모델은 openclaw.json에 설정됩니다.
• 크론 작업은 사용할 모델을 매개변수로 지정합니다.
• 서브 에이전트는 생성할 때 모델 인자를 받아들입니다.

프롬프트, 메모리 파일, 워크플로 정의, 그리고 도구 설정은 어떤 모델이 실행되는지 신경 쓰지 않습니다.

따라서 마이그레이션은 주로 다음과 같습니다:

1. OpenClaw 설정에서 모델 이름을 변경합니다.
2. 크론 페이로드를 업데이트합니다.
3. 게이트웨이를 재시작합니다.

완료되었습니다.

패닉은 마이그레이션 자체에 대한 것이 아니라, 필요하기 전에 테스트하지 않았던 점에 대한 것이었습니다.

---

실제로 깨지는 부분

프로바이더를 바꾸면 가장 눈에 띄는 것이 바뀝니다: 모델. 하지만 미묘한 차이 때문에 문제가 발생할 수 있습니다.

---

Source: …

나를 구한 아키텍처

모델을 코드가 아닌 설정으로

OpenClaw에서는 기본 모델이 openclaw.json에 한 번만 나타납니다. 나머지는 모두 간접적으로 이를 참조합니다. 기본 모델을 변경하면 다음 실행 시 모든 세션, 크론 작업 및 서브‑에이전트가 업데이트됩니다.

// openclaw.json
{
  "agents": {
    "defaults": {
      "model": "google/gemini-2.5-pro",
      "thinking": "low"
    }
  }
}

한 줄. 제공자를 업데이트하고 게이트웨이를 재시작하면 모든 구성 요소가 새로운 기본값을 적용합니다. 모델이 프롬프트 템플릿에 하드코딩되어 있거나, 크론 정의에 흩어져 있거나, 배포 스크립트에 고정돼 있다면 큰 어려움을 겪게 됩니다.

폴백 체인

OpenClaw에서는 기본 모델과 폴백 모델 목록을 설정할 수 있습니다. 기본 모델이 실패(요청 제한, 서비스 중단, 인증 오류)하면 시스템이 자동으로 다음 모델을 시도합니다.

// openclaw.json
{
  "agents": {
    "defaults": {
      "model": "google/gemini-2.5-pro",
      "fallbackModels": [
        "google/gemini-3.1-pro-preview",
        "google/gemini-2.5-flash"
      ]
    }
  }
}

기본 모델은 일반 요청을 처리합니다. 요청 제한에 걸리거나 오류가 발생하면 OpenClaw가 체인에 있는 다음 모델을 자동으로 시도합니다. 접근 권한이 남아 있는 한 마지막 옵션으로 이전 제공자를 폴백 목록 끝에 두어 마지막 보루로 활용할 수도 있습니다.

이는 마이그레이션에만 유용한 것이 아니라 일상적인 안정성도 향상시킵니다. 제공자 API가 다운되거나 요청 제한에 걸리면 폴백 체인이 에이전트를 계속 실행하게 합니다.

작업 기반 라우팅

모든 작업에 최고의 모델이 필요하지는 않습니다. 저는 세 가지 티어로 나누었습니다:

Brain이 작업에 필요한 티어를 판단한 뒤, 해당 모델에 서브‑에이전트를 생성합니다. OpenClaw에서는 크론 작업과 서브‑에이전트가 model 파라미터를 직접 받습니다:

// 크론 작업 — 저비용 모델에서 실행
{
  "label": "morning-news",
  "schedule": "0 9 * * *",
  "model": "google/gemini-2.5-flash",
  "thinking": "off",
  "task": "오늘의 상위 5개 뉴스 항목 전달"
}

// 서브‑에이전트 생성 예시
{
  "name": "code-reviewer",
  "model": "google/gemini-3.1-pro-preview",
  "task": "풀 리퀘스트를 검토하고 개선점을 제안"
}

요약

1. 모델을 하드코딩된 상수가 아니라 구성 값으로 다루세요.
2. 장애와 속도 제한을 견디기 위해 폴백 체인을 구축하세요.
3. 작업을 역량에 따라 라우팅하여 필요한 성능에만 비용을 지불하세요.

이 세 가지 설계 결정을 적용하면, 일주일이 걸릴 수 있었던 공급자 중단 복구가 오후에 해결될 수 있었습니다. 지속적인 AI 에이전트를 구축한다면, 처음부터 아키텍처에 공급자 독립성을 반영하세요.

크론 작업 — 고가 모델에서 실행

{
  "label": "weekly-review",
  "schedule": "0 18 * * 5",
  "model": "google/gemini-2.5-pro",
  "thinking": "medium",
  "task": "Run the weekly strategic review"
}

---

내가 다르게 할 일

만약 되돌아갈 수 있다면, 첫날부터 세 가지를 할 것입니다.

1. 필요하기 전에 장애 조치를 테스트하세요.
   한 달에 한 번, 기본 모델을 임시로 백업 모델로 전환하고 시스템을 몇 시간 동안 실행해 보세요. 아직 수정할 시간이 있을 때 미묘한 호환성 문제를 발견할 수 있습니다.

2. 마이그레이션 체크리스트를 유지하세요.
   계획이 아니라 체크리스트입니다. 제공업체가 파괴적인 변화를 발표했을 때 압박 속에서도 실행할 수 있는 종류죠. 제 체크리스트는 15항목으로 구성돼 있습니다. 시계가 똑딱거리기 전에 작성했더라면 좋았을 텐데요.

3. 크론 작업이 실제로 필요로 하는 모델을 추적하세요.
   이를 분기별로 감사하세요. 비용이 많이 드는 모델에서 실행되는 작업을 찾아서 더 저렴한 모델로 옮길 수 있는 경우가 거의 확실히 발견될 것입니다.

---

실제 교훈

프로바이더 독립성은 불신 때문이 아닙니다. 저는 이전 프로바이더가 마음에 들었어요—모델은 훌륭했고, 개발자 경험도 매끄러웠습니다. 하지만 기업은 가격을 바꾸고, 플랫폼 지원을 중단하고, 전략을 전환하거나, API가 몇 시간 동안 다운되는 안 좋은 날도 있습니다.

여러분의 프롬프트, 컨텍스트 파일, 워크플로 정의, 메모리 시스템—이것들이 진정한 자산입니다. 모델은 스택에서 가장 교체 가능한 부분이죠. 마치 그럴 것처럼 설계하세요.

마이그레이션을 하면서 제 시스템을 명확히 볼 수 있었습니다. 솔직히 지금이 더 좋습니다: 각각의 강점을 살리는 여러 모델을 사용하고, 하나가 다운되면 자동으로 페일오버가 이루어집니다. 이는 타협이 아니라 업그레이드입니다.

오늘 AI 에이전트를 운영하면서 하나의 프로바이더만으로도 모든 것이 잘 돌아간다면, 그것은 멋진 일입니다. 이제 그 프로바이더가 작동하지 않을 때 어떤 일이 일어나는지 테스트해 보세요.

---

이 글은 모델 마이그레이션 및 멀티‑모델 아키텍처에 관한 시리즈의 1부입니다. 다음 편: 서로 다른 작업 유형을 담당하도록 모델을 라우팅하는 방법.

프로바이더 마이그레이션을 경험해 보셨나요? 어떤 점이 놀라웠나요? 아직 겪어보지 못한 함정이 있다면 꼭 알려 주세요.