라온피플

“말하는 AI에서 ‘행동하는 AI’로, 그 뼈대는 인프라에 있다“

머리가 아무리 뛰어나도 손발이 묶여 있다면 무슨 소용일까요? 단순한 챗봇을 넘어 스스로 업무를 수행하는 ‘AI 에이전트’가 되려면, 모델의 지능만큼이나 이를 외부 세계와 이어줄 탄탄한 ‘연결 인프라(Connectivity Infrastructure)’가 필수적입니다. AI가 스스로 API를 호출하고, 복잡한 인증(Auth)을 통과해 도구를 실행하는 이러한 일련의 과정이 결국 시스템의 성능과 무한한 확장성을 결정짓기 때문입니다.

흥미롭게도 현재 에이전트에게 ‘손발’을 달아주는 방식은 전혀 다른 두 갈래로 나뉩니다. 하나는 1970년대부터 수십 년간 IT 생태계를 지탱해 온 관록의 CLI(Command Line Interface)이고, 다른 하나는 AI 시대를 맞아 야심 차게 등장한 새로운 표준 MCP(Model Context Protocol)입니다.

반세기를 뛰어넘는 이 두 아키텍처 중, 과연 우리의 에이전트 시스템에는 어떤 방식이 더 적합할까요? 지금부터 두 기술의 매력과 실용적 가치를 파헤쳐 보며, 최적의 설계를 위한 해답을 찾아보겠습니다.

“MCP(Model Context Protocol) 방식: 에이전트를 위한 새로운 표준“

규격 없는 연결의 한계: AI 통합을 가로막는 파편화 (N×M 문제)

AI가 아무리 똑똑해도 사내 데이터에 접근하지 못하면 결국 ‘헛똑똑이’에 불과합니다. 이를 해결하기 위해 AI와 사내 시스템을 연결(API)하려다 보니 곧바로 끔찍한 현실에 부딪혔습니다. 예를 들어 3개의 AI 모델을 5개의 사내 시스템(DB, 메신저 등)에 연결하려면 무려 15개(3×5)의 맞춤형 코드를 일일이 개발해야 합니다. 새로운 툴이 도입될 때마다 작업량은 기하급수적으로 늘어납니다. 마치 국가마다 전원 콘센트 규격(110V, 220V, Type C, G 등)이 전부 달라서, 새로운 기기를 연결할 때마다 각기 다른 변환 어댑터를 일일이 구비해 끼워 맞추어야 하는 것과 똑같은 ‘통제 불능의 파편화(N×M 문제)’가 발생한 것입니다.

AI 생태계를 구원한 ‘범용 USB-C 포트’의 등장

이 지독한 스파게티 코드의 늪을 구원한 것이 바로 앤스로픽(Anthropic)이 선보인 MCP(Model Context Protocol)입니다. “AI 모델과 시스템마다 따로 선을 만들지 말고, 전 세계가 쓰는 단 하나의 표준 규격을 만들자!”는 선언이었죠. 이제 시스템 중앙에 MCP라는 튼튼한 ‘표준 멀티탭’만 깔아두면 끝입니다. 어떤 신규 AI 모델이나 데이터베이스가 추가되든, 정해진 규격에 맞춰 ‘딸깍’ 꽂기만 하면 즉시 대화할 수 있습니다. 현재 글로벌 오픈 표준(AAIF)으로 자리 잡은 MCP는, 바야흐로 AI 에이전트 생태계를 하나로 묶어내는 거대한 혈관이 되었습니다.

그렇다면 이 거대한 혈관, 즉 ‘표준 멀티탭’은 구체적으로 어떻게 작동하는 걸까요? 핵심은 바로 복잡한 기능들을 규격화된 상자로 포장하는 데 있습니다. 기존의 복잡한 프로그램들을 ‘MCP 서버’라는 표준화된 상자 안에 담아두면, AI 에이전트는 하나의 통일된 규격으로 이 상자들과 자유롭게 소통할 수 있습니다. 이를 통해 에이전트는 세 가지 강력한 무기를 얻게 됩니다.

도구(Tools): DB 검색, 이메일 발송 등 에이전트가 직접 실행할 수 있는 ‘행동’
리소스(Resources): 에이전트가 참고할 수 있는 내부 문서나 데이터 같은 ‘지식’
프롬프트(Prompts): 에이전트가 헤매지 않도록 잡아주는 업무 ‘가이드라인’

기업이 MCP에 열광하는 이유: 철벽같은 보안

이렇게 다양한 시스템을 자유자재로 다루는 강력한 무기를 AI 에이전트의 손에 쥐여주게 되면, 필연적으로 중대한 고민이 뒤따릅니다. ‘과연 이 AI가 우리 회사의 핵심 데이터베이스나 시스템에 직접 접근하도록 내버려 두어도 안전할까?’ 하는 근본적인 신뢰의 문제입니다. 바로 이 지점에서 MCP의 진가가 발휘됩니다. 새로운 기술임에도 수많은 기업이 MCP를 표준 인프라로 채택하는 결정적인 이유는 바로 ‘보안과 격리’에 있습니다.

MCP 환경에서는 각각의 도구들이 서로 완벽하게 차단된 독립적인 방(프로세스)에서 실행됩니다. 만약 외부 공격이나 오류로 인해 특정 도구 하나에 문제가 생기더라도, 그것이 시스템 전체로 번지는 것을 구조적으로 완벽히 막아냅니다. 또한 파일 삭제나 결제처럼 위험하고 중요한 작업은 반드시 사람의 최종 승인(결재)을 거치도록 안전장치를 걸어둘 수 있어 기업 입장에서는 안심할 수 있습니다.

완벽해 보이는 MCP의 치명적 아킬레스건

이처럼 강력한 범용성과 보안성을 지녔음에도 불구하고, 실제 프로덕션 환경에서 마주하는 아주 뚜렷한 기술적 한계가 존재합니다. 가장 대표적인 문제는 이른바 ‘컨텍스트 비만(Context Bloat)’ 현상입니다.

MCP는 에이전트의 오작동을 막기 위해, 도구의 입력 파라미터와 제약 조건 등을 매우 엄격하고 상세한 JSON 스키마(설명서)로 정의합니다. 문제의 핵심은 이 방대하게 작성된 모든 도구의 명세서가, 에이전트가 작업을 시작하기도 전에 ‘컨텍스트 윈도우’에 선제적으로 전부 주입되어야 한다는 점입니다. 비유하자면, 신입사원(AI)이 출근하자마자 자신이 어떤 업무를 맡을지도 모르는 상태에서 회사에 있는 수십 개 기기의 두꺼운 사용 설명서를 강제로 통째로 외워야만 하는 상황과 같습니다.

실제로 단 6개의 서버(약 84개 도구)만 연결해도 첫 지시를 받기 전에 15,500개 이상의 토큰이 오직 이 설명서를 숙지하는 데 증발해 버립니다. 대규모 엔터프라이즈 환경에서는 5만~10만 토큰이 소모되기도 하죠. 이는 모델의 ‘핵심 추론(Reasoning)’ 공간을 앗아가 지능을 저하시키고 막대한 API 비용 폭탄을 초래합니다.

또한, ‘래퍼 세금(Wrapper Tax)’이라 불리는 무거운 구현 오버헤드도 존재합니다. 기존 API를 이 새로운 범용 규격에 맞추려면, 인터페이스를 다시 작성하여 ‘MCP 서버’라는 새로운 포장지를 씌워주는 번거로운 호스팅 작업을 거쳐야 합니다.

2026년, 한계를 넘어 진화하는 생태계

다행히 이러한 단점들은 빠르게 극복되고 있습니다. 처음부터 두꺼운 설명서를 다 주입하는 대신, 필요할 때만 설명서를 쏙쏙 뽑아 읽는 ‘지연 로딩(Lazy Loading)’ 기술이 도입되면서 데이터 낭비를 최대 95%까지 획기적으로 줄여냈습니다. 나아가 최근에는 텍스트만 주고받던 답답함에서 벗어나, AI가 대화창에 직접 대시보드나 버튼 같은 시각적인 화면(UI)을 띄워주는 기능까지 추가되며 생태계가 진화하고 있습니다.

“CLI(Command Line Interface) 방식: 검증된 유니버설 인터페이스“

무거운 JSON 스키마와 래퍼 세금에 지친 개발자들은 소프트웨어 역사상 가장 오래되고 검증된 인터페이스로 눈을 돌리고 있습니다. 바로 투박한 흑백 화면, 명령줄 인터페이스(CLI)와 스킬(Skill) 아키텍처입니다.
최신 프로토콜을 놔두고 왜 차세대 AI 에이전트들이 50년 전 유닉스(Unix) 철학으로 회귀했는지, 그 압도적인 매력을 살펴보겠습니다.

에이전트의 ‘모국어’: 래퍼 세금(Wrapper Tax) 제로화

대규모 언어 모델(LLM)은 학습 과정에서 방대한 쉘 스크립트와 기술 문서를 이미 다 학습했습니다. 즉, git, docker, aws 같은 명령어는 에이전트에게 번역이 필요 없는 ‘모국어’입니다. MCP처럼 복잡한 중개 서버(포장지)를 만들 필요 없이, 빈 터미널 창만 띄워주면 세상의 수만 가지 CLI 도구들이 즉시 에이전트의 팔다리가 됩니다.

‘컨텍스트 다이어트’와 점진적 정보 노출

CLI 방식은 시작부터 모든 설명서를 억지로 주입하지 않습니다. 업무 시작 시 SKILL.md 파일에서 스킬 이름과 짧은 요약(약 90토큰)만 가볍게 훑어보고, 특정 도구가 진짜 필요한 순간에만 –help 명령어나 세부 지침을 동적으로 읽어옵니다. 이 ‘점진적 정보 노출(Progressive Disclosure)’ 덕분에 84개 도구 기준 MCP가 15,500토큰을 낭비할 때, CLI는 단 300토큰으로 구동됩니다. 아낀 95%의 뇌 용량을 온전히 ‘추론’에 쏟아부을 수 있습니다.

유닉스 철학과 조합(Composability)의 승리

대용량 로그를 분석할 때, MCP는 거대한 텍스트 뭉치를 통째로 AI 메모리에 쏟아부어 병목을 일으킵니다. 반면 CLI 에이전트는 파이프(|) 연결을 활용합니다.
kubectl get pods | grep “api” | awk ‘{print $1}’
이렇게 터미널 내에서 불필요한 데이터를 1차로 걸러내고, 정제된 ‘핵심 결과’만 컨텍스트로 반환받아 AI의 인지 과부하를 막고 비용을 극적으로 절감합니다.

폭발하는 생태계, 그리고 치명적 아킬레스건

이러한 우월성을 바탕으로 현재 OpenClaw, Claude Code CLI 등 CLI 기반 워크플로우가 개발 생태계를 주도하고 있습니다. 하지만 이 강력한 자유도에는 ‘보안 취약성’이라는 그림자가 따릅니다. 철저히 격리된 MCP와 달리, CLI는 에이전트가 내 컴퓨터(호스트) 권한으로 직접 명령어를 실행합니다. 실제로 ‘ClawHavoc’ 같은 악성 스킬을 통한 데이터 탈취 공격이 그 위험성을 뼈저리게 증명했죠. 따라서 CLI 에이전트를 실무에 도입하려면, 악성 명령어(rm -rf 등)를 물리적으로 가두는 샌드박스(Sandbox)가 필수입니다. 현재 E2B, Modal 같은 전용 마이크로VM 플랫폼들이 필수 안전장치로 자리 잡았습니다.

AI의 위험한 질주를 막는 1회용 방탄 실험실, 마이크로 VM

CLI 환경에서 에이전트가 내리는 명령어는 너무나 자유로워서 때로는 치명적입니다. 이를 제어하기 위해 등장한 E2B나 Modal 같은 플랫폼은 우리가 흔히 아는 무거운 가상 머신(VM)이나 일반적인 도커 컨테이너와는 결이 다릅니다. 이들은 오직 AI 에이전트의 코드 실행만을 위해 극한으로 다이어트한 ‘초경량 샌드박스(MicroVM)’입니다.
비유하자면, 한 번 쓰고 가차 없이 버릴 수 있는 ‘방탄유리로 둘러싸인 임시 실험실’과 같습니다.

일반적인 가상 머신을 띄우는 데 수십 초에서 수 분이 걸린다면, E2B나 Modal이 제공하는 마이크로VM은 에이전트가 코드를 실행하려는 찰나의 순간에 단 몇 밀리초(ms) 만에 생성됩니다. 에이전트는 이 완벽히 고립된 임시 환경 안에서 마음껏 파일을 생성하고, 외부 패키지를 다운로드하며, 심지어 이상한 악성 코드를 실행할 수도 있습니다.

하지만 작업이 무사히 끝나거나 혹은 에이전트가 rm -rf 같은 치명적인 사고를 치는 순간, 이 실험실은 메인 시스템(호스트)에는 먼지 한 톨의 영향도 주지 않은 채 즉시 통째로 폐기되어 버립니다. 결국, 보안이 가장 취약하다는 CLI 아키텍처가 엔터프라이즈 실무 환경에 당당히 도입될 수 있었던 결정적인 이유는, 에이전트의 모든 돌발 행동을 0.1초 만에 안전하게 가둬버리고 소멸시키는 이 강력한 마이크로VM 플랫폼들의 등장 덕분입니다.

” CLI vs MCP: 핵심 특성 비교 분석 “

‘행동하는 AI 에이전트’에게 외부 세계와 연결할 수 있는 ‘손발’을 달아주는 방식은 앞서 살펴본 바와 같이 크게 두 가지 철학으로 나뉩니다. 이를 요약하면 다음과 같습니다.

MCP (Model Context Protocol): 모든 도구를 독립된 상자에 캡슐화하는 구조입니다. 강력한 프로세스 격리로 호스트 시스템을 보호하는 ‘철벽 보안’이 최대 무기입니다. 반면, 작업 시작 전 수만 토큰의 스키마를 강제로 외워야 하는 ‘컨텍스트 비만’과 전용 서버를 만들어야 하는 개발 오버헤드가 단점입니다.
CLI와 스킬 (Skill): 에이전트가 터미널에서 직접 명령어를 치는 구조입니다. 필요할 때만 지침을 불러오는 ‘압도적 토큰 효율성’과 통합 비용 제로가 최대 무기입니다. 반면, 로컬 권한 직접 실행으로 인한 ‘보안 취약성’이 커서 샌드박스 인프라 구축이 필수적입니다.

한눈에 보는 아키텍쳐 비교

요리 재료(MCP)와 레시피 카드(Skill)의 완벽한 조화

그렇다면 최후의 승자는 누구일까요? 정답은 “둘 다”입니다. 미래의 AI 에이전트 시스템은 이 두 방식을 배타적으로 경쟁시키지 않습니다.

아키텍처 관점에서 볼 때, MCP는 에이전트에게 안전하게 제공되는 ‘요리 재료(Tools)’입니다. 그리고 스킬(CLI)은 그 재료들을 언제, 어떻게 조합해서 요리할지 알려주는 ‘레시피 카드(Workflow)’와 같습니다.

실제 2026년 엔터프라이즈 AI 통합의 새로운 표준은 이 둘을 융합한 하이브리드 아키텍처로 굳어지고 있습니다. 기업의 민감한 데이터는 ‘MCP 게이트웨이’를 통해 철통 보안 속에서 공급받고, 에이전트가 로직을 수행하는 과정은 가볍고 날렵한 터미널 환경의 ‘스킬(CLI)’을 통해 통제하는 것입니다. 결국 지켜야 할 곳에는 철벽(MCP)을 두르고 달려야 할 곳에는 무한한 자유(CLI)를 허락하는 정교한 설계가 에이전트의 잠재력을 100% 끌어냅니다.

” 상황에 맞는 최적의 선택 가이드: 통제권, 속도, 보안의 삼각관계를 풀다 “

에이전트를 구현하는 방식을 결정하는 것은 단순한 기술 스택의 선택을 넘어, 우리 시스템이 ‘통제권’, ‘작업 속도’, 그리고 ‘보안’ 사이에서 어떤 균형점을 찾을 것인가를 묻는 치열한 아키텍처적 결단입니다. 그리고 흥미롭게도 이 결단은 에이전트의 ‘뇌’로 어떤 특성의 AI 모델을 탑재할 것인지까지 연쇄적으로 결정짓습니다.

통제 가능한 범용성과 속도가 생명이라면 (CLI 방식 추천): 기업 내부의 레거시 인프라 직접 제어, 복잡한 시스템 관리 자동화, 빠른 프로토타이핑이 목표라면 압도적으로 유리합니다. 이때는 코드 작성과 시스템 명령어 실행에 고도로 특화된 언어 모델들이 최고의 파트너가 됩니다. 순수한 기술적 리팩토링이나 로직 구현에서 타의 추종을 불허하는 퍼포먼스를 냅니다.
구조화된 정밀도가 필요하다면 (MCP 방식 추천): 외부 고객 응대용 SaaS 에이전트, 사내 팀 간 표준화된 도구 공유 등 철저한 규격과 통제가 필요한 환경에 적합합니다. 외부 도구 활용(Tool Use) 능력과 복잡한 API 연동에 최적화된 모델들이 찰떡궁합입니다. 정교하고 안전한 외부 시스템 제어에서 독보적인 강점을 보입니다.

하지만 진정한 엔터프라이즈 에이전트의 완성은 ‘삼각 구도’에 있습니다. 고도로 성숙한 시스템은 결국 MCP를 통해 외부 데이터에 안전하게 접속(Connect)하고, CLI를 통해 로컬 인프라를 실행(Execute)하며, 스킬(Skill)을 통해 이 과정을 오케스트레이션(Orchestrate)하는 완벽한 하이브리드 형태를 갖추게 될 것입니다

” 향후 전망 및 기술 트렌드: 대통합과 ‘안전한 자유’의 시대 “

미래의 시스템 설계를 위해 반드시 주목해야 할 세 가지 기술 트렌드는 다음과 같습니다.

벤더 종속을 벗어난 ‘표준화 거버넌스의 대통합’: 각 빅테크 기업들의 파편화된 규격 경쟁이 끝났습니다. 구글이 주도하던 A2A 프로토콜과 IBM의 ACP가 통합되어 리눅스 재단 산하의 AAIF(Agentic AI Foundation)로 이관되었습니다. MCP 역시 이 생태계에 편입되며, 통합 인프라가 완벽히 벤더 중립적인 글로벌 오픈 표준으로 확고히 자리 잡았습니다.
‘보안 인프라의 내재화’와 샌드박싱 기술의 수렴: CLI의 강력한 권한을 통제하기 위해 실행 환경 격리는 생존 필수재가 되었습니다. 현재 Anthropic은 터미널에 bubblewrap, 웹 환경에 gVisor를 활용하고, Vercel은 Firecracker microVM을 에이전트 런타임에 아예 내재화했습니다. 에이전트가 승인된 경로로만 통신하는 ‘화이트리스트 기반 프록시(allowlist)’ 패턴이 모든 구현체의 보안 표준으로 굳어지고 있습니다.
컨텍스트 다이어트를 통한 ‘극한의 성능 최적화’ 경쟁: 하이브리드 아키텍처 시대의 핵심 경쟁력은 ‘가벼움’입니다. MCP의 오버헤드를 극복하기 위한 UTCP(Universal Token Context Protocol) 같은 신규 최적화 기술이나 스킬 기반의 점진적 정보 노출 전략이 향후 API 비용과 처리 속도의 승패를 가를 것입니다.
결론적으로, 우리가 맞이할 미래의 AI 에이전트 인프라는 파편화된 규격을 통합한 ‘단일한 글로벌 표준(AAIF)’ 위에서 구동될 것입니다. 그리고 그 뼈대 속에는 철벽의 샌드박스가 DNA처럼 내재화되어, 에이전트가 발휘하는 무한한 자유(CLI)와 강력한 연결(MCP)이 ‘안전’이라는 탄탄한 지반 위에서 비로소 완성될 것입니다.