“특정 LLM에 종속되면 안 된다.”
이 말은 맞습니다. 그래서 많은 기업들이 Multi-LLM 전략에 집착합니다. “에이전트에서 LLM 설정값만 바꾸면 그대로 쓸 수 있다”고 생각하죠.
하지만 현실에서 이를 실행해 본 분이라면 아실 겁니다. LLM을 바꾸는 순간, 에이전트의 행동 자체가 달라집니다. 같은 도구, 같은 프롬프트, 같은 파이프라인인데 결과가 완전히 다릅니다. Lock-in 방지는 API 엔드포인트를 바꾸는 문제가 아니라, 에이전트를 처음부터 다시 세팅하는 문제입니다.
Multi-LLM의 진짜 문제 “프롬프트는 이식되지 않는다”
많은 분들이 LLM을 API로 바라봅니다. “입력을 넣으면 출력이 나오는 함수”라고 생각하죠. 그래서 OpenAI 대신 Claude를 쓰고, Gemini로 바꾸면 되지 않느냐고 말합니다.
그런데 실제로 해보면 이런 일이 벌어집니다:
- 같은 프롬프트, 다른 결과. GPT-4o에서 잘 동작하던 프롬프트가 Claude에서는 과도하게 cautious한 응답을 내놓고, Gemini에서는 구조가 완전히 달라집니다.
- 컨텍스트 윈도우 전략이 달라집니다. 128K 토큰을 쓸 수 있는 모델과 200K를 쓸 수 있는 모델에서의 컨텍스트 설계는 완전히 다른 엔지니어링입니다.
- System prompt에 대한 반응성이 다릅니다. 어떤 모델은 system prompt를 충실히 따르고, 어떤 모델은 user turn의 마지막 지시를 더 우선합니다.
결국 모델을 바꾸면 프롬프트 엔지니어링을 처음부터 다시 해야 합니다.
LLM을 바꾸면 에이전트가 달라진다
프롬프트 이식성은 시작일 뿐입니다. 진짜 문제는 에이전트 수준에서 드러납니다. 에이전트는 단순히 프롬프트를 실행하는 것이 아니라, LLM의 판단력에 의존해 자율적으로 행동을 결정합니다. LLM이 바뀌면 그 판단이 바뀌고, 에이전트의 행동 전체가 달라집니다.
LLM을 바꾸는 것은 엔진을 바꾸는 것이 아니라 운전자를 바꾸는 것에 가깝습니다. 같은 차, 같은 길이어도 운전 방식이 완전히 달라집니다.
구체적으로 어떤 일이 벌어지는지 보겠습니다:
- Tool calling 패턴이 달라집니다. 같은 도구 목록을 줘도 모델마다 도구 선택 전략이 다릅니다. 어떤 모델은 도구를 적극적으로 호출하고, 어떤 모델은 자체 추론으로 해결하려 합니다. 도구를 호출하는 순서, 병렬 호출 여부, 파라미터 구성 방식까지 전부 달라집니다.
- 판단 기준이 달라집니다. “충분한 정보를 얻었는가”, “사용자에게 추가 질문이 필요한가”, “이 작업을 중단해야 하는가” — 에이전트의 모든 분기점에서 모델마다 다른 판단을 내립니다. GPT-4o에서 한 번에 끝나던 작업이 Claude에서는 확인 질문을 3번 거치는 식입니다.
- 오류 처리 방식이 달라집니다. 도구 호출이 실패했을 때 재시도할지, 대안 경로를 찾을지, 사용자에게 보고할지 — 이 전략이 모델마다 다릅니다. 한 모델에서 안정적이던 에이전트가 다른 모델에서는 무한 재시도 루프에 빠질 수 있습니다.
- 멀티스텝 추론 경로가 달라집니다. 같은 목표를 줘도 모델마다 문제를 분해(decompose)하는 방식과 순서가 다릅니다. 에이전트의 전체 실행 흐름 — 몇 단계를 거치는지, 어떤 순서로 처리하는지 — 이 LLM에 따라 완전히 달라집니다.
결론적으로 에이전트에서 LLM만 교체하면 “같은 에이전트”가 아닙니다. 겉은 같아 보여도 행동이 다른, 사실상 새로운 에이전트입니다. 그래서 LLM을 바꾸면 결국 에이전트의 세팅을 처음부터 다시 해야 합니다.
Lock-in의 본질은 API가 아니라 “엔지니어링 투자”
LLM lock-in을 API 호환성의 문제로 보면 간단해 보입니다. OpenAI 호환 API를 쓰면 되니까요. 하지만 진짜 lock-in은 세 가지 층위에서 발생합니다:
1. Prompt Engineering Lock-in
수개월에 걸쳐 최적화한 프롬프트 체계. Few-shot 예시, chain-of-thought 구조, 출력 포맷 제어 — 이 모든 것이 특정 모델의 행동 패턴에 맞춰져 있습니다.
2. Context Engineering Lock-in
RAG 파이프라인에서 어떤 정보를 얼마나, 어떤 순서로 컨텍스트에 넣을지. 이 설계는 모델의 컨텍스트 윈도우 크기, 위치 편향(positional bias), 정보 검색 능력에 종속됩니다.
3. Harness Engineering Lock-in
에이전트의 도구 호출 방식, 오류 처리, 반복 루프 설계, 멀티턴 대화 관리 — 이런 “모델을 감싸는 시스템”이 특정 모델의 function calling 스펙, 응답 구조, latency 특성에 맞춰져 있습니다. 여기에는 눈에 잘 보이지 않는 세팅들이 포함됩니다: 도구 선택 우선순위, 재시도 횟수와 백오프 정책, “충분하다”고 판단하는 임계값, 안전 장치의 트리거 조건 등. 이 모든 세팅이 특정 LLM의 행동 특성에 맞춰 튜닝된 것입니다. LLM을 교체하면 이 세팅을 전부 재검증하고 재조정해야 하며, 이는 사실상 에이전트를 처음부터 다시 만드는 것에 가까운 비용을 발생시킵니다.
모델을 바꾸는 것은 API 엔드포인트를 바꾸는 것이 아닙니다. 이 세 층위의 엔지니어링을 모두 다시 하는 것입니다.
관점의 전환: Multi-LLM이 아니라 Multi-Agent
여기서 발상의 전환이 필요합니다.
“어떤 LLM이든 갈아끼울 수 있게 만들자”는 접근은 각 모델의 강점을 포기하는 것과 같습니다. 최소공배수 방식으로 프롬프트를 설계하면, 어떤 모델에서도 “그럭저럭” 동작하지만 어떤 모델에서도 “최적”이 되지 않습니다.
대신 이렇게 생각해야 합니다.
각 LLM의 강점을 살리는 에이전트를 설계하고, 이 에이전트들을 오케스트레이션하는 Harness를 만들자.
- 복잡한 추론이 필요한 태스크 → Claude에 최적화된 에이전트
- 코드 생성과 실행 → Gemini에 최적화된 에이전트
- 빠른 분류와 라우팅 → 경량 모델에 최적화된 에이전트
이때 중요한 것은 개별 에이전트가 아니라 이들을 엮는 Harness Engineering입니다. 에이전트 간 통신 프로토콜, 상태 관리, 오류 전파, 관찰 가능성(observability) — 이것이 진정한 엔지니어링 과제입니다.