한줄 요약
B2B SaaS 고객의 맞춤 기능 요청을 소스 코드 수정 없이 처리하는 임베디드 AI 에이전트 오픈소스, Vendo.
무엇이 달라지나?
B2B SaaS 개발팀이라면 누구나 겪는 상황이 있다. 고객사 A는 "이 화면에 긴급도 색상 구분을 넣어달라"고 하고, 고객사 B는 "매일 아침 특정 문서 상태를 자동으로 체크하는 기능이 필요하다"고 한다. 이 요청들은 각각 사소해 보이지만, 쌓이면 개발 백로그를 잠식한다. 그리고 대부분은 다른 고객에게 재사용되지 않는다.
Vendo는 이 구조적 문제를 다른 방향에서 접근한다. 개발팀이 기능을 만들어주는 대신, 고객이 자신의 인터페이스 안에서 직접 뷰와 자동화를 구성하도록 만드는 것이다. 이를 가능하게 하는 것이 'Embedded Agent' 개념이다.
작동 방식은 세 단계로 구성된다. 먼저 Vendo가 제품의 기존 API를 읽어 에이전트가 실행할 수 있는 도구(tool) 세트로 변환한다. 그 다음 에이전트가 고객의 자연어 요청에 따라 UI 뷰나 미니 앱을 생성하는데, 이 UI는 샌드박스 iframe 안에서 렌더링되며 외부 네트워크 접근이 차단된 격리 환경에서 실행된다. 마지막으로 정책, 승인, 권한, 감사 로그 등 모든 실행 통제가 단일 지점에서 처리된다.
결정적인 점은 소스 코드를 건드리지 않는다는 것이다. 에이전트는 이미 존재하는 제품 API를 로그인된 사용자로서 호출하고, 그 결과를 브랜드 네이티브 화면 위에 렌더링한다. 제품의 핵심 코드베이스와 완전히 분리된 커스터마이징 레이어가 생기는 셈이다.
실무에서 어떤 의미인가?
외주 개발이나 내부 개발 모두에서 B2B 제품의 고객 커스터마이징 문제는 오래된 난제다. 일반적으로 선택지는 크게 세 가지다. 요청을 거절하거나, 전사 기능으로 개발하거나, 별도 외주 개발로 처리하거나. 세 가지 모두 비용이나 품질 면에서 타협이 따른다.
Vendo가 제안하는 모델은 이 삼지선다에 네 번째 경로를 추가한다. 고객에게 직접 에이전트 레이어를 제공하고, 고객이 자신의 워크플로우에 맞게 스스로 구성하게 하는 것이다. 이는 단순한 노코드 도구와는 다르다. 에이전트가 제품 API를 실제로 호출하고 실행하는 구조이기 때문에, 제품의 데이터와 로직을 그대로 활용하면서도 UI와 자동화를 고객이 정의할 수 있다.
구체적으로 지원하는 시나리오는 세 가지로 나뉜다. 첫째, 고객이 질문을 던지면 에이전트가 해당 데이터를 조합한 라이브 뷰를 구성한다. 둘째, 기존 UI 컴포넌트에 마우스를 올리고 변경사항을 설명하면 그 자리에서 리믹스가 적용된다. 셋째, 자연어로 자동화 조건을 설명하면 스케줄된 자동화가 생성되고, 각 도구 접근은 승인 단계를 거친다.
패키지 구조도 모듈화되어 있어 도입 방식이 유연하다. 이미 자체 에이전트가 있는 팀은 Vendo의 tool pack만 연결할 수 있고, 에이전트가 없는 제품은 단일 명령어로 루프·채팅 UI·승인 시스템을 한 번에 가져올 수 있다. MCP를 통해 Claude, ChatGPT, Cursor 같은 외부 에이전트가 제품을 직접 조작하게 하는 옵션도 있다.
데이터 저장 측면에서는 개발 환경에서 PGlite를 기본 저장소로 사용하고, 프로덕션에서는 동일한 스키마를 Postgres로 운영한다. 오픈소스 블록은 자체 호스팅이 가능하며, 클라우드 기능은 API 키를 통해 활성화된다. 라이선스는 Apache-2.0이고, Y Combinator의 지원을 받고 있는 것으로 알려졌다.
도입 전 체크포인트
이 구조가 모든 제품에 즉시 적합한 건 아니다. 몇 가지 전제 조건을 먼저 검토해야 한다.
API가 충분히 정리되어 있는가. Vendo는 기존 제품 API를 에이전트 도구로 변환하는 방식으로 작동한다. API가 파편화되어 있거나 인증 구조가 복잡하면 초기 셋업 비용이 올라간다.
고객층이 에이전트 인터페이스에 익숙한가. 자연어로 뷰를 만들고 자동화를 설정하는 패턴은 아직 모든 고객에게 직관적이지 않을 수 있다. 기술 친화적인 고객사가 많은 B2B 제품에서 먼저 효과를 보기 쉽다.
승인 정책을 어떻게 설계할 것인가. 에이전트가 고객의 데이터와 외부 도구에 접근하는 구조이기 때문에, 어떤 작업에 승인을 요구하고 어떤 범위를 허용할지에 대한 정책 설계가 선행되어야 한다. Vendo의 Guard 레이어가 이를 담당하지만, 정책 자체는 제품 팀이 정의해야 한다.
장기적으로 커스터마이징 레이어를 어떻게 관리할 것인가. 고객이 만든 뷰와 자동화가 쌓이면 이를 버전 관리하고 지원하는 운영 프로세스가 필요해진다.
