실험실AI 두뇌, 클라우드라는 '새 몸'을 얻다

방구석 장난감에서 서비스로 진화하는 AI Agent 여정

by SunnyPark

지난 글에서 저는 여러분께 꽤나 어려운 질문을 던졌습니다. "넓은 연결(Web Service)인가, 깊은 통제(Local Control)인가?"

제 로컬 PC 안에 갇혀 있는 이 강력한 AI 에이전트를 세상 밖으로 꺼내기 위해, 저는 화려한 웹 서비스(SaaS)를 만드는 길과 PC 제어력을 극대화하는 길 사이에서 고민했습니다. 그리고 일주일이 지난 오늘, 그 두 가지 혼합한 모델인 '제3의 길(Option 2)'을 선택했음을 알려드립니다.


지난 5개월간의 AI 실험 중 가장 기술적으로 극적이었던 변화, "로컬 MCP 서버의 클라우드 이주기"를 이야기하려 합니다.


5개월의 여정: 파편화된 도구에서 '지능형 에이전트'로

본론으로 들어가기 앞서, 잠시 시계를 뒤로 돌려보겠습니다. 처음 'AI와 90일간의 실험'을 시작했을 때, 제 목표는 단순했습니다. "사람의 말을 알아듣고 업무를 대신해 주는 봇"을 만드는 것이었죠.

영업 비서: 잠재 고객 데이터를 정리하고,

IT Helpdesk: 단순 반복되는 기술 문의에 답하며,

일정 비서: 복잡한 캘린더를 관리하는 툴.

초기에는 이들이 각기 다른 파이썬 스크립트로 존재했습니다. 하지만 실험이 2부 '안정화 단계'에 접어들며 고민이 깊어졌습니다. 기능은 늘어나는데 관리는 어려워졌기 때문입니다.

그래서 저는 MCP(Model Context Protocol)를 도입했습니다. 흩어진 기능들을 모듈화하고, AI가 자율적으로 도구를 골라 쓰는 'AI Agent' 형태로 진화시켰습니다. 하지만 여전히 이 모든 것은 제 노트북, '로컬 PC'라는 물리적 공간에 갇혀 있었습니다.


왜 'Option 2 (Remote MCP Server)'인가?

제품화를 고민하며 저는 '웹 서비스(Option 4/5)'와 '클라이언트/서버 모델(Option 1/2)' 사이에서 치열하게 고민했습니다.

웹 서비스는 접근성은 좋지만, 제가 만든 강력한 'Claude Desktop'의 UI와 경험을 버리고 프론트엔드부터 다시 개발해야 했습니다. 반면, Option 2 (Remote MCP Server)는 달랐습니다.

Client/Server 모델의 부활: 사용자는 가장 단순한 코딩으로 효율성을 극대화 한, '새로운 개발 방식인 MCP 프로토콜'을 활용한 강력한 Claude Desktop(Client)을 그대로 사용합니다.

Enterprise급 확장: 대신, AI의 '도구(MCP Server)'는 내 PC가 아닌 안전한 클라우드 서버에 둡니다.

이것은 개인 비서의 능력을 강화하면서도, 향후 기업용 솔루션(Enterprise Solution)으로 확장하기 위한 가장 현실적이고 강력한 타협점이었습니다. 내 PC가 꺼져 있어도, 혹은 내가 다른 컴퓨터 앞에 앉아 있어도, 클라우드에 있는 나의 'AI 비서'는 언제든 호출될 준비가 되어 있기 때문입니다.


진화의 3단계: 내 방 책상에서 구글 클라우드까지

이 결정을 현실로 만들기 위해, 저는 단계적인 기술 이주를 감행했습니다. 첨부한 [Step별 아키텍처] 이미지가 바로 그 설계도입니다.

[Step 1] Local Path 연결: 태초의 단계

가장 기초적인 단계였습니다. Claude Desktop 설정 파일에 제 PC의 특정 폴더 경로(python /users/sunny/mcp-server/server.py)를 직접 입력했습니다.

방식: Stdio (표준 입출력 파이프)

한계: 제 PC, 딱 그 자리에서만 작동합니다. 코드를 조금만 수정해도 경로가 꼬이기 일쑤였습니다.


[Step 2] Docker Container 도입: 표준화의 시작

코드를 '도커(Docker)'라는 컨테이너에 담았습니다. 이제 제 PC 안의 가상 공간(Localhost:8000

)에서 서버가 돌아갑니다.

방식: HTTP/SSE (Server-Sent Events)

변화: 파일 경로가 아닌 'URL'로 통신하기 시작했습니다. 환경에 구애받지 않고 어디서든 똑같이 실행되는 '표준화'를 이뤘습니다. 하지만 여전히 제 PC가 켜져 있어야 했습니다.


[Step 3] GCP Cloud Run 배포: 진정한 해방 (현재 단계)

드디어 마지막 단계입니다. 도커로 감싼 AI 에이전트를 구글 클라우드 플랫폼(GCP)의 Cloud Run에 쏘아 올렸습니다.

방식: Pulic URL (https://xxxxx.xx.run.app/sse)

혁신:

Serverless: 서버를 24시간 켜둘 필요가 없습니다. 요청이 올 때만 깨어납니다.

CI/CD 파이프라인: 깃허브(GitHub)에 코드를 올리면(Push), Cloud Build가 자동으로 빌드해서 배포까지 끝냅니다.

Anywhere: 이제 저는 지구 반대편의 PC에서도 Claude Desktop에 이 URL만 입력하면, 즉시 제 전용 AI 비서와 연결됩니다.


시연: 구름(클라우드) 위에 지은 집

이제 이론은 끝났습니다. 저는 이 아키텍처를 실제로 구현했습니다.

제 로컬 PC의 Claude Desktop(클라이언트)이 수천 킬로미터 떨어진 구글 데이터센터(서버)에 있는 MCP Server와 실시간으로 통신하며, Gmail을 읽고 Salesforce 업무를 처리하는 모습을 보여드리려 합니다.

이 과정은 "나만의 작은 코딩"이 어떻게 "견고한 서비스"로 진화하는지 그 과정을 투명하게 공유하는 과정입니다.

USB 케이블과 같은 Local을 뽑아버리고, 보이지 않는 선, Cloud으로(클라우드) 연결된 이 새로운 AI Agent가 되는 과정 여기 영상 데모를 통해 확인해 보실 수 있습니다. https://youtu.be/zt5St_AfrxA


다음 단계 예고: 흩어진 지능을 하나로: '슈퍼 에이전트'의 탄생과 시련

영업 비서의 클라우드 이주는 시작에 불과했습니다. 제 PC 곳곳에는 지난 5개월간 만든 IT 헬프데스크, 일정 관리 비서, 회의록 요약 비서들이 파편화된 채 잠들어 있습니다.

다음 화에서는 이들을 모두 깨워, 하나의 거대한 뇌(Brain)로 통합하는 '슈퍼 에이전트(Super Agent) 구축'에 도전합니다.

하지만 클라우드는 마냥 천국이 아니었습니다. 내 방에서는 즉답하던 AI가 클라우드에서는 멈칫거리는 '지연 시간(Latency)', 잠든 서버를 깨우는 데 걸리는 '콜드 스타트(Cold Start)', 그리고 복잡해진 '보안 문제'까지...

로컬의 온실을 벗어나, 클라우드라는 거친 야생에서 이 거대한 지능이 과연 안정적으로 살아남을 수 있을까요? 진정한 엔터프라이즈 솔루션으로 가기 위한 운영에 어려움, 그 치열한 통합과 검증의 기록으로 돌아오겠습니다.

이전 04화마법 같았던 지난실험, 그리고 남겨진 숙제