B2B SaaS를 운영하다 보면 늘 마주치는 딜레마가 있다. 고객마다 원하는 맞춤 기능이 다르고, 그 요구를 모두 제품 로드맵에 반영할 수는 없다는 점이다. 요청은 쌓이는데 개발 인력은 한정돼 있으니 대다수의 '작지만 절실한' 커스터마이징 요구는 뒤로 밀린다. YC S26 배치에 참여한 벤도(Vendo)는 이 문제를 정면으로 겨냥한 오픈소스 프로젝트로, 발상 자체가 흥미롭다. 제품 벤더가 기능을 하나하나 만들어 주는 대신, 고객이 제품 위에서 스스로 기능과 소규모 앱을 만들 수 있는 '커스터마이징 레이어'를 제공하겠다는 것이다.
임베디드 에이전트라는 개념
벤도의 핵심은 제품에 내장되는 에이전트다. 이 에이전트는 별도의 백엔드를 새로 뚫는 것이 아니라, 로그인한 사용자의 권한으로 그 제품이 이미 노출하고 있는 자체 API를 호출해 동작한다. 그리고 생성한 UI를 브랜드에 어울리는 샌드박스 화면에 렌더링한다. 문서에 반복해서 강조되는 표현은 '소스 코드는 절대 건드리지 않는다'는 것이다. 즉 벤더의 코드베이스를 수정하지 않고, 이미 존재하는 API 표면을 도구로 삼아 그 위에서 새로운 뷰나 자동화를 얹는 구조다.
제시된 사용 시나리오는 세 가지다. 질문을 던지면 호스트 앱의 컴포넌트와 API를 조합해 실시간 뷰를 만들어 주고, 화면의 특정 컴포넌트에 마우스를 올려 원하는 변경을 말로 설명하면 그 자리에서 UI를 수정하며, 자연어로 지시한 작업을 도구별 승인 절차를 거치는 상시 자동화로 바꿔 준다. 프로젝트 측은 소개 자료의 모든 캡처가 목업이 아니라 데모 호스트 앱에서 실제로 실행된 에이전트 결과라고 밝히고 있다.
실행은 어떻게 이뤄지나
동작 방식은 세 단계로 정리된다. 첫째 '추출' 단계에서 벤도는 제품의 API를 읽어 로그인 사용자로서 실행할 수 있는 도구 집합으로 변환한다. 둘째 '생성' 단계에서는 포맷 태그가 붙은 UI 문서로부터 뷰와 사용자 소유 앱을 구성한다. 이때 생성된 컴포넌트는 connect-src를 'none'으로 막은 iframe 격리 환경에서 실행되며, 꼭 필요할 때만 샌드박스 서버로 권한이 확대된다. 셋째 '가드' 단계에서 정책, 승인, 권한 부여, 서킷 브레이커, 감사 로그가 모두 하나의 실행 병목 지점에 모인다. 앱이 호스트의 도구에 접근할 때는 반드시 이 가드가 걸린 도구 프록시를 거치도록 설계돼 있다.
이 구조에서 눈여겨볼 지점은 보안 경계다. 사용자가 자유롭게 UI와 자동화를 생성한다는 것은 곧 임의 코드가 제품 안에서 돌아간다는 뜻이고, 이는 잠재적 공격 표면이 된다. 벤도가 iframe 격리와 네트워크 차단, 단일 실행 초크포인트에서의 승인·감사를 전면에 내세운 이유가 여기에 있다. 자동화의 모든 도구 호출이 승인 게이트를 통과하도록 한 점도 같은 맥락이다. 다만 이러한 격리가 실제 프로덕션 부하와 다양한 공격 시나리오에서 얼마나 견고한지는 도입 검토 시 직접 확인해야 할 몫이다.
도입 방식과 데이터 계층
벤도는 도입 상황을 네 갈래로 나눠 제시한다. 이미 자체 에이전트를 운영 중이라면 AI SDK나 Mastra, 자체 루프에 도구 팩 하나를 얹는 방식으로, 에이전트가 아예 없다면 명령 하나로 실행 루프와 채팅 UI, 승인 기능을 한 번에 들여오는 방식으로 붙인다. 또 제품을 MCP로 노출하면 클로드, ChatGPT, 커서, 클로드 코드 같은 외부 클라이언트가 로그인 사용자로서 작동할 수 있고, 에이전트를 자체 백엔드에 두고 싶다면 CLI나 UI 없이 agent()와 chat() 함수만 쓰는 패키지 형태로 통합할 수 있다. 스트리밍 에이전트는 어떤 AI SDK의 LanguageModel과도 연동된다고 설명한다.
데이터 저장은 설정이 필요 없는 PGlite를 .vendo/data 경로에 두는 것을 기본으로 하되, 프로덕션에서는 동일한 스키마를 그대로 포스트그레스에서 돌린다. 기본 구성 패키지는 @vendoai/vendo이며, 직접 조합하고 싶다면 개별 블록을 설치할 수 있다. 진단 도구인 vendo doctor는 문제를 점검하고 출력되는 코드마다 정확한 수정 위치로 연결해 준다고 한다.
오픈소스와 클라우드의 경계
비즈니스 모델의 윤곽도 드러난다. 공유, 퍼블리싱, 조직 단위 오버레이, 핀 고정 같은 기능은 VENDO_API_KEY를 통해 클라우드에서 활성화되는 유료 영역이고, 오픈소스 블록 자체는 셀프호스팅으로 남는다. 오픈코어(open-core) 전략의 전형으로, 핵심 실행 엔진은 개방하되 팀·조직 규모의 협업과 배포 관리를 상용 계층으로 두는 방식이다.
한국 SaaS 실무자 관점에서 벤도가 던지는 질문은 명확하다. 늘어나는 커스터마이징 요구를 벤더가 전담 개발로 소화하는 대신, 고객에게 안전한 생성 권한을 위임하는 방향이 현실적인가 하는 것이다. 이 접근이 매력적이려면 API가 이미 충분히 잘 정리돼 있어야 하고, 사용자가 생성한 코드에 대한 격리·승인·감사가 조직의 보안 기준을 만족해야 한다. 반대로 API 표면이 빈약하거나 규제 요건이 까다로운 도메인이라면 위임 자체가 부담이 될 수 있다. 아직 초기 단계 프로젝트인 만큼 실제 안정성과 운영 부담은 검증이 필요하지만, 'AI 에이전트를 제품 내부 커스터마이징 엔진으로 쓴다'는 방향성만큼은 앞으로 눈여겨볼 만한 흐름이다.