Maven Apps: 에이전트에 필요한 것은 스위치 패널이 아니라 운영자입니다

스위치 패널은 배선된 대로만 작동합니다. 스위치를 켜면 매번 정해진 응답 하나만 나옵니다. 그 회로를 벗어난 일을 맡기면 처리하지 못합니다. 변수를 다루지 못하고 배선만 따르기 때문입니다.

교환원은 다릅니다. 교환원에게 “프런트 데스크로 연결해 주세요”라고 요청하면, 처리 방법을 스스로 판단합니다. 어느 회선을 쓸지, 통화 중이면 어떻게 할지, 요청 자체가 모호하면 어떻게 할지까지 생각합니다. 신호를 그대로 전달하는 데 그치지 않고, 해석하고 행동합니다.

Maven Apps는 스위치 패널이 아니라 교환원입니다. App 인프라를 구동하는 프레임워크를 설계하면서 저희는 의도적인 결정을 내렸습니다. 또 하나의 통합 레이어를 만들지 않기로 했습니다. 대신 진정한 애플리케이션 플랫폼을 만들고, AI 에이전트가 그 위에서 일급 시민으로 동작하도록 했습니다.

현재 저희 프레임워크에는 수천 개의 앱이 있습니다. Salesforce, Zendesk, Notion 같은 주요 서드파티 시스템용 앱도 물론 포함됩니다. 하지만 실제 운영 중인 에이전트에서 프로덕션으로 동작하는 수백 개의 맞춤형 앱도 함께 있습니다.

기본 통합만으로는 부족한 이유

벤더 10곳에 자사 제품이 “Salesforce와 통합된다”는 것이 무슨 의미인지 물으면 10가지 답이 돌아옵니다. Salesforce, Zendesk, Front 같은 시스템은 결코 한 가지 역할만 하지 않기 때문입니다. 이런 시스템은 다음과 같은 역할을 할 수 있습니다.

• 에이전트가 정보를 찾으러 가야 하는 곳(지식 베이스, 케이스 이력)
• 에이전트가 작업을 수행하러 가야 하는 곳(티켓 생성, 레코드 업데이트, 환불 처리)
• 에이전트가 모습을 드러내야 하는 접점(지원팀이 이미 매일 사용하는 콘솔 안의 상담원 지원 코파일럿)

아티클만 다룰 수 있는 “Salesforce 통합”은 케이스까지 등록할 수 있는 통합과 같은 제품이 아니며, 상담원 콘솔 안에서 코파일럿으로 동작하는 통합과도 다른 제품입니다. 그런데 이들은 흔히 하나의 마케팅 용어로 묶여 있어, 그 차이는 구축 단계에 가서야 드러납니다.

이른바 자판기 문제입니다. 고정된 메뉴는 광고된 그대로 잘 작동하지만, 필요한 항목이 목록에 없다는 사실을 알게 될 때쯤이면 이미 도입을 결정한 뒤입니다. 저희는 Maven Apps가 그렇게 작동하기를 원하지 않았습니다. 그래서 범용 “커넥터”가 아니라 실제로 필요한 것이 무엇인지(지식, 기능, 채널)를 중심으로 프레임워크를 설계했습니다.

Maven Apps: 통합 그 이상

Maven Apps는 다양한 형태를 띨 수 있지만, 대부분 몇 가지 공통 패턴을 기반으로 합니다. 앱으로 할 수 있는 일의 예는 다음과 같습니다.

• 지식 앱은 외부 시스템의 콘텐츠를 읽고 색인해 에이전트가 이를 바탕으로 답변하게 합니다. 읽기 전용이며, 버전 관리가 되고, 대상별로 태그를 지정할 수 있습니다.
• 기능 앱은 에이전트가 해당 시스템에서 실제로 작업을 수행하게 합니다. 실제 API 호출을 다단계 워크플로(주문 조회, 반품 정책 확인, 환불 처리, 고객에게 결과 안내)로 연결해 하나의 대화 안에서 모두 처리합니다. ATM이 고정된 메뉴에서 정해진 거래 하나를 실행한다면, 기능 앱은 전담 은행원에 가깝습니다. 메뉴 항목이 아니라 원하는 결과를 받아, 예외 처리까지 포함해 그 결과에 이르는 데 필요한 일을 해냅니다.
• 채널 앱은 고객이나 지원팀이 이미 있는 곳에 에이전트를 배치합니다. 임베디드 위젯, 전화, 받은편지함, 또는 상담원이 매일 사용하는 콘솔 안의 코파일럿 패널이 그 예입니다.

디렉터리의 사전 구축 앱은 대개 몇 분 만에 설치할 수 있습니다. 고객의 시스템이 카탈로그에 없다면, 개발자는 동일한 프레임워크, 동일한 SDK, 동일한 라이프사이클 훅, 동일한 보안 모델로 맞춤형 앱을 만들 수 있습니다.

저희 엔지니어만 쓰는 별도의 “엔터프라이즈급” 프레임워크 등급은 없습니다. 앱 개발을 위한 개발자 플랫폼인 App Studio도 똑같은 아키텍처에서 동작합니다. 저희만을 위해 배워야 하는 독자적인 스크립트 언어가 아니라, 실제 TypeScript와 실제 SDK(@mavenagi/mavenagi), 실제 배포 파이프라인을 사용합니다.

MCP 기반으로 개발해 본 경험이 있다면, Maven App은 비슷한 개념을 완전 관리형으로 제공한다고 보시면 됩니다. 일반적인 MCP 서버는 직접 구축하고, 등록하고, 운영하고, 확장해야 합니다. Maven App은 자동으로 등록되고 자동으로 확장되는 MCP 엔드포인트에 가깝고, 관리해야 할 인프라가 전혀 남지 않습니다. 로직만 작성하면 엔드포인트, 인증, 호스팅은 저희가 처리합니다.

Apps가 강력하도록 설계된 방식

Maven App은 안전하게 격리된 환경에서 실행되며, 정의된 SDK를 통해 Maven 플랫폼과 통신하는 서버리스 애플리케이션입니다. 구체적으로 살펴보면 다음과 같습니다.

멀티테넌트 구조입니다. 하나의 앱을 한 번 만들면 여러 조직과 에이전트에 걸쳐 여러 번 설치할 수 있습니다. 설치마다 고유한 범위의 컨텍스트(조직 ID, 에이전트 ID, 런타임 구성)를 갖지만, 기반 코드는 공유합니다. 따라서 Salesforce 앱을 개선해 배포하면 이를 사용하는 모든 고객이 혜택을 받으며, 누구도 손수 만든 낡은 버전의 “자사 전용” 통합에 묶여 있지 않습니다.

덧붙인 것이 아니라 격리되어 있습니다. 각 앱은 안전한 환경에서 독립된 함수로 실행되며, Maven의 핵심 백엔드는 물론 다른 고객의 앱과도 분리되어 있습니다. 고객의 맞춤형 로직이 공유 모놀리스 안에서 다른 고객의 로직과 나란히 실행되는 일은 없습니다. 기록 시스템으로의 연결은 VPN, VPC 피어링, OIDC, 또는 IP 허용 목록을 적용한 일반 HTTPS 중에서 고객이 직접 선택할 수 있습니다.

폴링 일정이 아니라 실제 이벤트에 반응합니다. 야간 동기화 작업 대신, 앱은 트리거라는 이벤트 훅을 구현할 수 있습니다. 대화가 생성되거나, 피드백이 들어오거나, 지식 베이스가 갱신되면 플랫폼이 그 즉시 앱에 알립니다. 이미 익숙한 자동화 도구와는 구조가 다릅니다. Maven 트리거는 수동적입니다. 플랫폼 자체가 상태 변화를 감지해 관심 있는 모든 앱에 전달하며, 이벤트를 일으킨 앱과 이에 반응하는 앱 사이에는 결합이 없습니다. 실제로는 이메일 응답 앱과 완전히 별개인 Salesforce 동기화 앱이 같은 “대화 업데이트” 이벤트에 각자 독립적으로 반응해 자기 일을 하며, 서로의 존재를 알 필요조차 없습니다.

개미 군집이 사용하는 것과 같은 협업 방식입니다. 어떤 개미도 군집의 행동을 계획하지 않고, 다른 개미에게 직접 메시지를 보내지도 않습니다. 한 개미가 공유 환경에 변화(페로몬 흔적)를 남기면, 다른 모든 개미가 각자의 단순한 규칙에 따라 그 변화에 독립적으로 반응합니다. 최적화된 먹이 탐색 경로, 부하 분산, 둥지 이전 같은 집단적 의사결정까지, 군집 수준의 지능은 중앙 조정자 없이, 그리고 계획을 아는 개미 없이 바로 여기서 생겨납니다. Maven Apps도 같은 방식으로 협업합니다. 이벤트가 공유 상태를 바꾸면, 관심 있는 모든 앱이 각자 반응합니다.

실제 라이프사이클을 갖추고 있습니다. 모든 앱은 몇 가지 라이프사이클 훅을 구현합니다.

• preInstall: 서비스가 시작되기 전에 자격 증명과 구성을 검증합니다. API 키가 잘못되었다면 3주 뒤에 조용히 실패하는 대신, 이 단계에서 명확하게 설치가 실패합니다.
• postInstall: 설치가 성공하면 앱의 작업을 등록하고 필요한 리소스를 프로비저닝합니다.
• executeAction: 에이전트가 요청한 실제 작업을 실행하며, 주문 조회, 케이스 생성, 환불 처리, 계정 잔액 확인 같은 기능으로 고객에게 제공됩니다.

대부분의 통합은 전등 스위치와 같습니다. 켜짐 아니면 꺼짐, 그 중간은 없습니다. Maven의 앱은 설치, 검증, 실행, 해제로 이어지는 전체 라이프사이클을 거칩니다. 두 가지 상태만 있는 스위치라기보다, 컨텍스트를 읽고 상황에 맞게 대응하는(열려 있는 항목을 확인하고, 안전한지 확인한 뒤 실행하는) 루틴에 가깝습니다. 프로덕션 소프트웨어에 기대하는 바로 그 규율이며, 실제로 Maven Apps는 프로덕션 소프트웨어이기 때문입니다.

Apps vs. 통합

일반적인 통합은 대개 “데이터를 A에서 B로 옮길 수 있는가”라는 좁은 질문 하나에만 답하고 그것으로 끝냅니다. Maven App은 더 어렵지만 더 유용한 질문에 답하도록 만들어졌습니다. AI 에이전트가 지금 이 순간 시스템에서 무엇이 사실인지 확실히 알 수 있는가, 그리고 필요할 때 고객을 대신해 행동하도록 믿고 맡길 수 있는가 하는 질문입니다.

대부분의 엔터프라이즈 플랫폼은 “기본 제공되지 않으면 직접 만들면 된다”는 식의 옵션을 제공합니다. 하지만 직접 만든다는 것이 자체 서버, 자체 확장, 자체 보안 검토를 자체 인프라에서 감당해야 한다는 뜻이라는 점은 잘 알려주지 않습니다. 그러면 커넥터 카탈로그의 단순한 공백이 인력 문제로 바뀝니다. 엔지니어링과 인프라 예산을 확보할 것인가, 아니면 사전 구축된 것만으로 만족할 것인가. Maven Apps를 사용하면 고객이 차악을 고를 필요가 없습니다. 고객이나 고객의 개발자가 만든 맞춤형 앱은 디렉터리의 모든 사전 구축 앱과 동일한 모니터링, 확장, 보안 체계를 갖춘 저희 인프라에서 실행됩니다. 코드는 고객이 작성하고, 운영은 저희가 맡습니다.

그래서 이 아키텍처는 단순한 웹훅이라면 신경 쓸 필요가 없는 요소들을 반드시 갖추고 있습니다.

• 구조화되고 크기가 제한된 응답. 앱이 실행하는 모든 작업은 에이전트가 추측해야 하는 무제한의 원시 데이터가 아니라, 명확한 응답과 함께 에이전트가 추론에 활용할 수 있는 구조화된 데이터를 반환합니다.
• 서명 기반 상호 인증. 플랫폼은 앱에 보내는 모든 요청에 서명하므로 앱은 실제로 Maven이 호출했는지 검증할 수 있고, 앱도 자체 자격 증명으로 플랫폼에 인증합니다. 어느 쪽도 네트워크만 믿을 필요가 없습니다.
• 프로덕션 도달 전 구성 검증. 앱이 서비스를 시작하기 전에 preInstall이 실행되므로, 잘못된 자격 증명이나 누락된 설정은 고객이 처음 사용하는 순간이 아니라 설치 시점에 발견됩니다.
• 단순한 함수 호출이 아닌 실제 인프라. 앱은 완전한 애플리케이션이므로 상태를 저장하지 않는 요청과 응답에 그치지 않고, 캐시, 요청 집계, 소규모 데이터베이스 같은 실제 상태를 유지할 수 있습니다. 덕분에 특정 도메인의 해결률이 지난 24시간 동안 10% 넘게 떨어졌는지 추적하고, 그런 경우 팀에 알림을 보내는 일도 가능합니다. 단순 API 호출은 이런 기억을 유지할 수 없습니다. 어떤 개미도 먹이 위치를 기억하지 못하지만 개미 군집은 기억하는 것처럼, 실제 애플리케이션은 이를 해낼 수 있습니다.
• 민감한 데이터를 모델로부터 분리. 어떤 단계는 AI를 아예 거치지 않아야 합니다. 고객이 장바구니 상품을 구매할 준비가 되면 에이전트가 앱의 결제 기능을 실행하고, 앱은 자체 보안 인터페이스를 통해 고객에게서 결제 정보와 개인 정보를 직접 수집합니다. 에이전트는 흐름을 조율할 뿐, 카드 번호를 비롯한 민감한 정보는 AI와의 대화에 절대 들어가지 않습니다.
• 하나의 코드베이스, 모든 고객, 격리된 영향 범위. 멀티테넌시 덕분에 수정 사항과 개선 사항은 한 번만 배포하면 모든 고객에게 적용되며, 격리 덕분에 한 고객의 맞춤형 로직이 다른 고객에게 영향을 주는 일은 결코 없습니다.

고객에게 의미하는 것

Maven을 검토하고 계신다면, 핵심은 이것입니다. 저희가 에이전트가 질문에 답하고 그에 따라 작업을 수행할 수 있다고 말할 때, 그 작업 뒤에는 실제 애플리케이션이 있다는 뜻입니다. 버전 관리되고, 인증되고, 격리되어 있으며, 저희 팀이 만들었든 고객 팀이 만들었든 동일한 프레임워크 위에 구축된 애플리케이션입니다. 바로 이것이 시스템에 대해 말만 할 수 있는 에이전트와 시스템에 실제로 연결된 에이전트의 차이입니다.

저희가 Maven Apps를 만든 이유는, 이것이야말로 “통합”이 처음부터 의미했어야 하는 바라고 믿기 때문입니다.