어제 클로드,내일 챗GPT.. AI매번 바꿔야하나요?

특정 AI에 끌려다니지 않는, AI에 종속적이지 않는 에이전트란..

"어떤 AI에 베팅해야 할까요?" 요즘 업계에서 가장 많이 듣는 질문입니다. 하지만 이 질문을 던지고 계신다면, 정말 중요한 진짜 질문을 놓치고 있는 겁니다.

"AI를 교체할 때, 우리는 시스템을 얼마나 뜯어고쳐야 하는가?"

어떤 AI를 선택할지는 '오늘의 결정'에 불과합니다. 하지만 언제든 다른 AI로 갈아탈 수 있는 구조를 만드는 것은 '내일을 위한 보험'입니다.

지난 <AI 운영실험: 에이전트 완성> 연재를 통해 꽤 많은 것을 이뤄냈습니다.

혼자 코딩하던 AI를 조직이 함께 쓰는 다중 사용자 시스템으로 확장했고, '사람의 승인'이라는 안전장치를 달았으며, 에이전트의 모든 행동을 투명하게 추적하는 대시보드와, 6개의 전문 에이전트 팀이 구축을 했습니다.

저는 앞서 말한 '내일을 위한 보험'을 떠올리며 다음 질문을 던질 수밖에 없었습니다.

"우리가 만든 이 시스템은 진정으로 '자율적'인가?"

시스템이 알아서 잘 돌아간다고 해서 자율적인 것은 아닙니다. 만약 그 똑똑한 시스템이 오직 하나의 특정 AI 모델(예: Claude 또는 OpenAI)에만 의존하고 있다면 어떨까요?

해당 모델의 정책이 바뀌거나, 가격이 폭등하거나, 더 뛰어난 오픈소스 모델이 등장했을 때 우리는 그동안 구축한 에이전트 인프라를 통째로 뜯어고쳐야 할지도 모릅니다.

진정한 AI 자율성은 '시스템이 사람 없이 혼자 일하는 것'을 넘어, '특정 벤더나 모델에 얽매이지 않고 시스템 스스로 독립성을 유지하는 것'에서 완성됩니다.

그래서 직접 실험해 보기로 했습니다. "시스템을 지휘하는 두뇌(AI Orchestrator)를 갈아 끼워도, 손발(Server & Tools)은 수정 0줄로 똑같이 움직일 수 있을까?"

두뇌를 갈아 끼워도, 손발은 그대로 움직일 수 있을까?

엔터프라이즈 비즈니스 시스템을 오래 다뤄오며 얻은 교훈이 있습니다.

확장 가능한 아키텍처의 핵심은 '분리(Decoupling)'라는 것입니다. 그래서 저는 앞서 GCP에 구축한 다중 에이전트 MCP 서버를 도마 위에 올렸습니다.

실험의 룰은 아주 가혹하면서도 단순했습니다. "서버 코드는 단 한 줄도 건드리지 않는다. 오직 지시를 내리는 '관리 AI(Orchestrator)'만 교체한다."

지난번 완벽하게 호흡을 맞췄던 Claude Desktop을 잠시 내려두고, 다음의 세 가지 각기 다른 환경에서 동일한 6-Agent 시스템에 업무를 지시해 보았습니다.

Claude Desktop (PC 채팅 UI + Claude AI): 기존의 안정적인 환경

Cursor + GPT-4o (PC 채팅 UI + OpenAI): 개발 환경에서의 GPT 연동

Cursor + Llama 3.1 (PC 채팅 + 오픈소스 AI): 외부 API 없이 제 노트북에서 돌아가는 8B 파라미터의 로컬 모델

"현재 서비스 상태를 알려줘, 일정도 알려줘, 나한테 온 메일 확인해줘.. ."

머리만 바뀐 상태에서, 과연 6개의 에이전트들은 혼란 없이 제 역할을 해냈을까요?

27번의 호출, 100% 성공, 그리고 수정 0줄

이틀에 걸쳐 총 27번의 API 호출 실험을 진행한 결과는 제 예상을 훌쩍 뛰어넘었습니다.

결과는 100% 성공이었습니다. 그리고 GCP 서버의 코드는 정말 단 한 글자도 수정할 필요가 없었습니다.

클라이언트가 Claude든, GPT-4o든, 심지어 제 노트북 CPU 자원만으로 돌아가던 Llama 3.1이든 상관없었습니다.

이들은 모두 서버에 정의된 도구(Tool) 명세서를 완벽하게 이해하고, 정확한 타이밍에 run_email_agent 와 run_calendar_agent 를 호출했습니다.

이번 실험을 통해 세 가지 중요한 사실을 확인했습니다.

MCP 아키텍처의 진짜 가치: 클라이언트(지시자)와 서버(실행자)가 완벽히 분리되었습니다. 이제 우리는 사용하는 플랫폼이 바뀔 때마다 서버를 재배포할 필요 없이, 그저 접속하는 클라이언트만 바꿔주면 됩니다.

서버가 병목이다, AI가 아니라: 여러 번 반복 테스트를 해보니, 어떤 AI를 쓰든 실제 에이전트의 실행 시간은 2.5초~4.5초로 수렴했습니다.

오픈소스 AI의 가능성 증명: 무거운 상용 클라우드 AI가 아니더라도, 로컬 환경의 가벼운 모델이 엔터프라이즈급 다중 에이전트를 훌륭하게 지휘할 수 있음을 확인했습니다.

종속성을 끊어낸 시스템, 그리고 이어지는 '독립의 로드맵'

새로운 구조를 설계하고, 그것이 각기 다른 환경에서도 톱니바퀴처럼 완벽하게 맞물려 돌아가는 결과를 눈으로 직접 확인할 때의 희열. 무언가를 기획하고 만들어내는 사람으로서 느낄 수 있는 최고의 즐거움이 아닐까 싶습니다.

이제 우리의 에이전트 팀은 Claude가 아프면 GPT로, 보안이 극도로 중요해지면 내부망의 Llama로 언제든 유연하게 환승할 수 있는 든든한 보험을 얻었습니다.

하지만, 이것은 이제 막 첫 번째 마일스톤을 넘은 것에 불과합니다. 이번 27번의 완벽한 성공은 시스템의 '오케스트레이션 레이어(Orchestration Layer)' 중에서도 PC안에 채팅 환경에서의 교체를 증명한 것입니다.

서버 코드 한 줄 바꾸지 않고 아키텍처의 독립성을 검증해 나가는 저의 실험은 다음 로드맵을 따라 계속될 것입니다.

[완료된 여정]

✅ Claude Desktop + Multi-Agent (기존)

✅ Cursor + GPT-4o (클라이언트/AI 교체)

✅ Cursor + Llama 3.1 (AI교체 /로컬 오픈소스 AI 도입)

[앞으로의 실험 로드맵]

Google ADK + MCP (웹/모바일 확장): 데스크탑 채팅창을 넘어, 구글의 Agent Development Kit을 활용해 커스텀 웹/모바일 UI에서 동일한 MCP 서버를 호출해 봅니다.

LangGraph / CrewAI + MCP (프레임워크 다각화): LLM의 암묵적(Implicit) 판단에만 의존하지 않고, 명시적인 그래프/노드 기반의 오픈소스 프레임워크를 웹/모바일 UI에서 통해 6개의 에이전트를 조율해 봅니다.

Server-side LLM Swap (완벽한 독립 스택 완성): 클라이언트 단의 검증이 모두 끝나면, 최종적으로 서버 레이어에 진입합니다.

각 에이전트 내부에서 실제로 도구를 쥐고 일하는 AI(현재 gpt)마저 오픈소스로 교체해 보면서, 머리부터 발끝까지 특정 API에 의존하지 않는 '독립 스택'을 완성할 계획입니다.

이전 북 <AI 운영실험: 에이전트 완성>이 AI를 길들이고 조직의 시스템으로 안착시키는 과정이었다면, 앞으로 '어떤 기술 격변에도 흔들리지 않는 독립적이고 자율적인 AI 아키텍처'를 향하면서 확장의 여정을 다룰 예정입니다.

이번 오케스트레이터 교체 테스트의 실제 구동 화면과 3개 모델의 속도 비교 로그 등 상세한 과정은 이 영상 LINK 에 기록해 두었습니다.

범용 API에 기대지 않고, 당장 내 로컬 환경에서 돌아가는 '나만의 오픈소스 AI(Llama 등)'를 직접 구축하고 연동해 보고 싶으시다면, 제가 작성한 아래의 Medium 기고(영문)를 확인해 주시길 추천합니다. 상세한 기술 스택과 가이드를 확인하실 수 있습니다.

AI 시스템의 벤더 종속성(Lock-in) 문제로 고민하는 분들께, 이 로드맵의 첫 번째 결과가 명쾌한 해답과 작은 영감이 되기를 바랍니다.