클라우드 AI 어시스턴트는 편하지만, 성장 단계에서 항상 ‘비용·제한·통제권’에 걸립니다. 피크 타임 레이트리밋, 대화 데이터의 외부 반출, 유저당 구독료 누적… 여기서 셀프호스팅 에이전트가 “와 이거다!” 포인트로 떠오릅니다. dev.to의 OpenClaw 사례처럼, 텔레그램/디스코드 같은 채팅 채널에 붙고 멀티모델을 라우팅하며 대화 데이터를 내 서버에 남기는 구조는 곧바로 성장 레버가 됩니다.
핵심은 두 가지입니다. 첫째, 비용 구조. 팀 단위로 Plus/Pro를 쌓는 대신, 공유 API 크레딧+라우팅으로 월 비용을 크게 낮출 수 있어요(OpenClaw 글의 비용 비교가 이 감각을 잘 보여줍니다). CAC 관점에선 “유료 좌석을 늘릴수록 마진이 깎이는” 구조를 “사용량 기반 최적화”로 바꾸는 셈이죠. 둘째, 데이터 프라이버시. B2B는 보안/컴플라이언스 질문에서 막히면 퍼널이 바로 깨지는데, self-hosted는 ‘데이터가 우리 네트워크 밖으로 안 나간다’는 문장 하나로 전환율이 달라질 수 있습니다.
문제는 여기서부터입니다. OpenClaw가 지원하는 MCP(Model Context Protocol)는 에이전트가 파일시스템·DB·API 같은 “툴”을 쓰게 해주며 가치가 폭발합니다. 그런데 같은 dev.to에서 지적됐듯(MCP 공급망 문제), MCP 생태계는 공급망 공격에 너무 취약한 패턴이 이미 대규모로 관측됩니다. npx를 -y로 자동 설치하면서 버전 핀을 안 걸어두는 설정이 수백 건, 검증 없는 원격 MCP 서버가 천 건 단위… 이거, 바이럴 될 것 같은 확장 속도만큼이나 “사고도 같이 스케일”할 조건입니다.
여기에 프롬프트 인젝션/툴 오용이 붙으면 더 위험해집니다. 요즘 위협은 모델이 실수로 무례한 말을 하는 게 아니라, 유저 입력이 ‘툴 실행’을 비틀어 데이터 유출이나 파괴적 작업을 시키는 쪽입니다(dev.to의 프롬프트 인젝션 하드닝 글이 강조). 특히 MCP로 파일 읽기/DB 질의/배포 트리거까지 연결해버리면, 에이전트는 사실상 “권한 있는 자동화 계정”이 됩니다. 이 지점에서 보안은 기능 품질이 아니라 리텐션 장치예요. 한 번의 사고는 신뢰 하락→이탈/해지로 직결됩니다.
그래서 시사점은 명확합니다: 셀프호스팅 에이전트를 성장 레버로 쓰려면, ‘배포’가 아니라 ‘하드닝’을 온보딩 체크리스트에 넣어야 합니다. 당장 빨리 테스트해볼 수 있는 액션은 ① MCP 서버 버전 핀ning(예: some-mcp-server@1.2.3)으로 공급망 리스크를 한 방에 줄이고 ② 툴 호출을 JSON 스키마로 구조화해(의도 분류→검증) 프롬프트 인젝션의 면적을 줄이며 ③ 실행 레이어에 allow-list/권한 스코프를 둬서 “LLM이 말한 것”이 아니라 “앱이 허용한 것”만 실행하게 만드는 겁니다. 그리고 ④ 툴 호출 승인/거절 로그를 남겨 보안 이벤트를 ‘제품 분석 지표’로 바꿔야 해요(거절률이 높다면 UX/권한 설계가 틀린 신호).
전망을 보면, self-hosted 에이전트는 개인용을 넘어 팀/회사 단위로 더 빨리 번질 겁니다. 이유는 단순해요. 채팅 앱(텔레그램/디스코드/슬랙)이라는 기존 습관 위에 얹히고, 멀티모델 라우팅으로 비용을 최적화하며, “우리 데이터는 우리 서버에”라는 B2B 스토리가 강력하니까요(OpenClaw가 딱 그 조합). 다만 승부는 기능 수가 아니라 신뢰입니다. MCP 생태계가 npm 초창기처럼 ‘락파일/감사/서명’으로 성숙하기 전까지는, 제품팀이 선제적으로 하드닝을 기본값으로 만들어야 합니다. 보안을 뒤로 미루는 순간, 퍼널은 성장해도 리텐션이 무너질 가능성이 큽니다. 결국 셀프호스팅 에이전트의 다음 성장 곡선은 “설치 5분”이 아니라 “안전한 기본값 5가지”를 누가 먼저 제품화하느냐에서 갈릴 겁니다.