운영실험I 마무리:왜 MCP였고, 무엇이 어려웠나

자동화를 넘어 자율화로, 그리고 로컬과 클라우드의 공존

Jan 11. 2026

실험실을 벗어난 AI

지난 '90일간의 실험( 북 1)'이 제 노트북 안에서 벌어진 '기능 구현(PoC)'의 축제였다면, 이번 '운영실험 I( 북 2)'은 그 기능들을 현실 세계로 내보내기 위한 치열한 '설계 구현 과정'이었습니다.

헬프데스크, 영업비서, 회의록 비서... 파편화되어 있던 이 기능들을 하나의 안정된 시스템으로 묶기 위해 저는 MCP(Model Context Protocol)라는 새로운 표준을 도입했고, 클라우드와 로컬을 오가는 하이브리드 아키텍처를 완성했습니다.

오늘은 그 과정에서 제가 마주했던 3가지 핵심 질문과 그에 대한 해답을 정리하며 이 실험을 갈무리하려 합니다.

1. Why MCP? : 왜 하필 MCP였는가?

"개발자가 일일이 떠먹여 주는 시대는 끝났다."

기존의 방식(API 연동)은 개발자인 제가 모든 경우의 수를

If-Else 문으로 코딩해줘야 했습니다. 하지만 기능이 많아질수록 코드는 복잡해지고 관리는 불가능해졌습니다.

제가 MCP를 선택한 이유는 명확합니다.

자율성(Autonomy): AI에게 '도구(Tool)'만 쥐여주면, AI가 상황에 맞춰 스스로 도구를 선택하고 실행합니다.

확장성(Scalability): 헬프데스크에 영업 기능을 붙이고 싶다면? 코드 전체를 뜯어고치는 게 아니라, '영업 도구(Server)' 하나만 레고 블록처럼 끼우면 끝입니다.

이것은 단순한 기술 교체가 아니라, "시키는 대로 하는 봇"에서 "스스로 판단하는 에이전트"로의 진화였습니다.

2. Challenge & Solution : 3번의 고비, 3번의 선택

하지만 이상과 현실은 달랐습니다. MCP를 실제 서비스로 구현하는 과정에서 저는 세 번의 큰 벽에 부딪혔습니다.

난관 1) MCP는 웹(Web)이 아니다 (5가지 설계의 딜레마)

MCP는 기본적으로 1:1 통신 프로토콜이지, 우리가 아는 웹 서비스 구조가 아니었습니다. "어떻게 하면 다수의 사용자가 웹/앱처럼 쓰게 할까?"를 고민하며 5가지 설계 옵션을 그렸습니다.

결정: 결국 저는 Hybrid Architecture (Remote + Local)를 택했습니다. 보안이 필요한 데이터는 클라우드(Remote)에, 내 파일 제어는 내 PC(Local)에 두는 것이 가장 현실적이고 강력했기 때문입니다.

난관 2) 서버리스(Serverless)의 배신과 VM으로의 회귀

"관리하기 편하게 서버리스로 가자"고 생각했던 것은 오산이었습니다. AI 에이전트는 사용자와 실시간으로 긴 대화를 나누며 '상태(Context)'를 유지해야 합니다. 하지만 서버리스는 잠깐만 쉬어도 연결을 끊어버렸고(Stateless), AI가 생각하는 동안 타임아웃이 발생했습니다.

해결: 저는 GCP Compute Engine(VM)으로 회귀했습니다. 다수 사용자(Multi-users)에게 끊김 없는 경험을 제공하기 위해서는, 투박하더라도 '항상 깨어있는 서버(Stateful)'가 필수적이었습니다.

난관 3) AI에게 '핵버튼'을 쥐여줘도 될까? (Local Commander의 보안)

로컬 MCP 서버 구축의 꽃은 MCP Commander였습니다. AI가 내 PC의 쉘(Shell)을 열고 명령어를 치게 만드는 기능이죠. 덕분에 AI는 스스로 보고서를 만들고 이메일에 첨부할 수 있게 되었습니다. 하지만 이는 AI에게 'Admin(관리자) 권한'을 주는 것과 같았습니다. AI가 실수로 "모든 파일 삭제"를 실행한다면? 상상만 해도 끔찍했습니다.