Mastra Agent Builder 공개, 팀 내부 에이전트의 권한 문제

Mastra가 2026년 5월 28일 Agent Builder를 발표했습니다. Mastra는 이를 "internal agent platform"이라고 부릅니다. 개발자가 도구, 모델, 워크플로를 코드로 준비하고, PM·운영·지원팀 같은 비개발 팀원이 Builder UI에서 그 구성요소를 조립해 내부 에이전트를 만들고 게시하는 방식입니다.

이 발표를 단순한 low-code 화면 추가로 보면 절반만 읽은 것입니다. Mastra의 설명에서 먼저 보이는 것은 자연어 생성보다 허용 목록입니다. tools.allowed, agents.allowed, workflows.allowed, models.allowed를 개발자가 MastraEditor 설정에 넣고, Builder는 그 경계 안에서만 새 agent를 만들도록 설계됩니다. 팀원이 agent를 만들 수 있게 하되, 어떤 tool을 실행하고 어떤 model을 호출할 수 있는지는 코드와 권한 정책이 정합니다.

Mastra 블로그의 예시는 꽤 직접적입니다. crm-lookup-tool, ticket-search-tool, account-research-agent, customer-onboarding-workflow, OpenAI와 Anthropic provider, observational memory를 허용 목록에 넣습니다. 사용자가 새 agent 생성을 요청하면 Mastra는 허용된 tools, agents, workflows의 description을 discovery하고, 생성된 agent를 configured storage에 저장합니다. 게시 전까지 agent는 private이고 draft 상태도 가질 수 있습니다.

export const mastra = new Mastra({
  editor: new MastraEditor({
    builder: {
      enabled: true,
      configuration: {
        agent: {
          tools: { allowed: ["crm-lookup-tool", "ticket-search-tool"] },
          agents: { allowed: ["account-research-agent"] },
          workflows: { allowed: ["customer-onboarding-workflow"] },
          models: { allowed: [{ provider: "openai" }, { provider: "anthropic" }] },
          memory: { observationalMemory: true },
        },
      },
    },
  }),
});

이 코드는 Mastra 발표의 축약본이지만, 제품 방향을 잘 드러냅니다. agent를 만드는 화면은 비개발자에게 열 수 있습니다. 그러나 agent가 호출할 수 있는 CRM lookup, ticket search, onboarding workflow, model provider는 개발자가 코드로 좁힙니다. 내부 자동화에서 가장 위험한 순간은 사용자가 agent를 만들 때가 아니라, agent가 실제 고객 데이터나 운영 시스템에 닿을 때입니다.

권한 모델도 같은 맥락입니다. Agent Builder는 admin과 member 두 역할로 시작합니다. member는 stored-agents:write, tools:execute, workflows:read 같은 IAM-style permission pattern으로 범위를 좁힙니다. Mastra는 역할을 permission bundle로 설명합니다. agent는 public으로 게시되기 전까지 private이고, draft status를 거칠 수 있습니다. 내부 agent marketplace를 만들려면 생성, 테스트, 게시, 실행 권한이 섞이지 않아야 합니다.

이 구조가 개발팀에 던지는 질문은 명확합니다. "누가 agent를 만들 수 있는가"보다 "누가 어떤 primitive를 조합할 수 있는가"를 먼저 정해야 합니다. 예를 들어 지원팀은 ticket search와 customer summary tool을 쓸 수 있지만 refund workflow는 읽기만 하게 할 수 있습니다. 영업팀은 CRM lookup과 follow-up draft는 열되, pricing approval workflow는 별도 review를 요구하게 만들 수 있습니다. Agent Builder의 허용 목록은 이런 조직 규칙을 코드에 가깝게 옮기는 장치입니다.

Mastra가 같은 주에 Workflows Enhanced를 낸 점도 같이 봐야 합니다. 5월 27일 글은 Temporal integration을 통해 durable execution, advanced retries, scheduling, observability를 강화한다고 설명합니다. Agent Builder가 "누가 agent를 만들고 공유하는가"의 문제라면, Temporal 통합은 "그 agent가 실행한 긴 업무가 중간에 실패했을 때 어떻게 이어가는가"의 문제입니다.

Mastra의 workflow 설명은 single agent reasoning과 structured workflow를 분리합니다. Mastra Workflows 페이지는 반복 가능하고 예측 가능하며 감사 가능한 multi-step process에는 workflow가 필요하다고 설명합니다. step은 input/output schema를 갖고, sequential, parallel, branch, loop로 구성됩니다. workflow step은 agents, tools, memory, MCP를 직접 호출할 수 있습니다. 즉 agent가 모든 판단을 한 번에 하도록 두지 않고, 반복 업무의 경로를 코드로 드러내는 방식입니다.

Temporal 통합은 이 경로를 더 길게 가져갑니다. Mastra의 5월 12일 Temporal support 글은 @mastra/temporal 설치를 안내합니다. 함께 쓰는 패키지는 @temporalio/client, @temporalio/worker, @temporalio/envconfig입니다. createWorkflow()는 Temporal workflow가 되고, createStep()은 Temporal activity가 됩니다. 글은 외부 API를 호출하거나 몇 시간·며칠 동안 이어지거나 worker restart를 견뎌야 하는 workflow에 Temporal을 쓰라고 설명합니다.

이 부분은 agent product에서 자주 과소평가됩니다. 사용자는 "계약 갱신 리마인더 agent" 또는 "고객 onboarding agent"를 만들고 싶다고 말합니다. 실제 구현은 이메일 수집, CRM 조회, 문서 생성, 승인 요청, Slack 알림, 실패 재시도, 감사 로그 보존, 일정 실행으로 쪼개집니다. 한 단계가 실패했을 때 전체 step을 다시 실행할지, 특정 API call만 retry할지, 어느 시간대 기준으로 schedule할지, 누가 실행 이력을 볼지 정해야 합니다.

Mastra Workflows Enhanced 글은 Temporal의 retry 제어를 이 점에서 설명합니다. Mastra 자체 RetryConfig는 maxRetries, retryDelayMs, backoffMultiplier, maxRetryDelayMs, retryableErrors를 제공합니다. Temporal을 붙이면 특정 action이나 call 단위로 retry할 수 있고, jitter, max retry time, separate server 기반 retry 관리가 추가됩니다. 이 기능은 화려한 agent demo보다 덜 보이지만, production workflow에서는 에러 비용을 줄이는 핵심 구성입니다.

스케줄링도 같은 이유로 중요합니다. Mastra workflow는 cron 문자열로 daily report workflow를 돌릴 수 있습니다. Temporal은 schedule을 별도 definition으로 다루고, interval, calendar, timezone-aware schedule, Temporal UI 탐색을 제공합니다. 내부 agent가 매일 아침 고객 리스크 보고서를 만들거나 매주 release note를 작성한다면, schedule은 편의 기능이 아니라 운영 계약입니다.

관측성은 builder와 workflow를 연결하는 세 번째 축입니다. Mastra는 workflows가 snapshot, suspend/resume, time travel, run trace를 통해 debugging을 지원한다고 설명합니다. Temporal UI를 붙이면 execution history query, workflow attribute search, worker and queue monitoring까지 볼 수 있습니다. agent가 만든 결과만 보는 단계에서는 "왜 이렇게 했는가"를 설명하기 어렵습니다. workflow trace는 agent가 어떤 step에서 어떤 data를 받았고, 어떤 도구 호출 뒤에 멈췄는지를 재구성하는 자료가 됩니다.

Mastra의 위치는 대형 SaaS 플랫폼과 다릅니다. Microsoft Copilot Studio나 Salesforce Agentforce는 이미 업무 앱, identity, admin console, billing surface를 갖고 있습니다. Mastra는 TypeScript 프레임워크에서 출발합니다. 그래서 Agent Builder의 메시지는 "모든 기업 데이터를 우리 플랫폼으로 가져오라"보다 "기존 TypeScript app과 infra 안에서 agent platform primitive를 구성하라"에 가깝습니다.

Mastra 홈페이지는 core framework가 Apache 2.0 오픈소스이고, enterprise 기능은 별도 license라고 설명합니다. Agent Builder도 self-hosting과 Mastra platform enterprise edition에서 제공되며, local Mastra Studio에서 시험할 수 있지만 배포에는 license key가 필요하다고 발표 글에 적혀 있습니다. 이 구분은 도입 검토에서 중요합니다. 프레임워크 실험과 조직 내부 builder 운영은 같은 구매 단위가 아닙니다.

오픈소스 프레임워크가 이런 enterprise 기능을 붙이는 배경에는 agent 개발의 비용 구조가 있습니다. 초기에는 "agent를 만들 수 있는가"가 질문이었습니다. 이제는 "많은 팀이 만든 agent를 어떻게 catalog, permission, trace, retire 할 것인가"가 질문입니다. 내부 agent가 늘어나면 중복 tool, 오래된 prompt, 잘못된 model 선택, 불분명한 owner가 생깁니다. Builder UI만으로는 이 문제를 해결하지 못합니다. 역할, 저장소, publish 상태, 실행 로그, workflow state가 함께 필요합니다.

Mastra의 2026년 5월 업데이트 목록을 보면 이 방향이 더 분명합니다. 블로그 인덱스에는 ClickHouse observability, background tasks, response caching, A2A support, upgraded CLI가 연속으로 올라와 있습니다. Elasticsearch RAG, Temporal workflows, Agent Builder, multi-user multi-channel agents도 같은 달에 이어졌습니다. 각 기능은 작아 보일 수 있지만, 묶으면 agent runtime의 운영 표면을 채웁니다. 비용은 caching, 장기 작업은 background task와 Temporal, 팀 협업은 Builder, 외부 연결은 MCP와 A2A, 관측은 observability로 나뉩니다.

경쟁 구도에서는 Vercel AI SDK, LangGraph.js, OpenAI Agents SDK, LlamaIndex.TS, Microsoft Copilot Studio, Glean Agent Builder를 같이 봐야 합니다. Vercel AI SDK는 UI와 streaming, provider abstraction에 강합니다. LangGraph는 graph-based agent orchestration과 durable execution을 앞세웁니다. Microsoft와 Glean은 enterprise context와 governance를 강조합니다. Mastra는 TypeScript 애플리케이션 개발자가 같은 언어와 배포 환경 안에서 agent, workflow, memory, eval, observability를 묶는 쪽에 베팅합니다.

커뮤니티 반응은 아직 제한적입니다. HN이나 Reddit에서 Agent Builder 발표 자체가 큰 토론으로 번진 흔적은 확인하지 못했습니다. 대신 Enterprise DNA 같은 오픈소스 디렉터리는 Mastra를 LangGraph.js, Vercel AI SDK와 비교하며 TypeScript agent stack의 후보로 정리합니다. Thoughtworks Technology Radar도 Mastra를 TypeScript-native framework for AI applications and agents로 언급했습니다. Agent Builder는 아직 제품 검증보다 early adopter 평가가 필요한 단계입니다.

도입팀이 확인해야 할 빈칸도 있습니다. 첫째, permission pattern이 실제 조직 구조와 얼마나 잘 맞는지 봐야 합니다. tools:execute 같은 권한이 충분히 세밀하지 않으면 민감 tool 호출과 안전한 lookup이 같은 범주에 묶일 수 있습니다. 둘째, generated agent가 저장되는 storage와 review workflow를 정해야 합니다. agent가 private에서 public으로 넘어갈 때 누가 코드와 prompt, tool binding을 승인하는지 문서화해야 합니다.

셋째, Temporal 통합은 강력하지만 운영 부담이 있습니다. 별도 Temporal server, worker process, task queue, deployment config가 필요합니다. Mastra의 Temporal support 글도 @mastra/temporal이 experimental이고 API가 release 사이에 바뀔 수 있다고 적습니다. 규제 산업이나 고객 데이터가 있는 workflow에 바로 넣으려면 패키지 안정성, migration plan, observability export, failure replay policy를 확인해야 합니다.

넷째, 비개발 팀원이 agent를 만들 수 있게 되면 template 품질이 중요해집니다. 도구 description이 애매하면 builder가 잘못된 primitive를 고를 수 있습니다. workflow 이름이 추상적이면 사용자는 agent가 어디까지 할 수 있는지 오해합니다. 좋은 internal agent platform은 자유 입력창보다 curated tool catalog와 예제, owner, risk label을 먼저 갖춰야 합니다.

Mastra Agent Builder 발표의 실무적 의미는 "PM도 agent를 만든다"가 아닙니다. 개발자가 준비한 안전한 building block을 조직 내부에 배포하고, 그 조합을 권한과 실행 이력 안에 묶는 방식입니다. Temporal 통합은 그 agent가 만든 long-running workflow가 실패해도 실행 상태와 retry 정책을 잃지 않게 합니다. TypeScript 팀에게는 새로운 선택지가 생겼습니다. agent를 앱 옆의 실험 스크립트로 둘 것인지, 아니면 permissioned internal platform으로 올릴 것인지 결정해야 합니다.

가장 먼저 할 일은 작은 내부 업무 하나를 고르는 것입니다. 예를 들어 고객 피드백 요약, release note draft, onboarding checklist 생성처럼 읽기 권한이 중심인 작업이 좋습니다. 그 작업에 필요한 tool, model, workflow만 allow-list에 넣고, draft agent를 만든 뒤 trace와 retry 결과를 봅니다. 이 과정을 거치면 Mastra Agent Builder가 조직에 맞는지보다 더 중요한 사실을 알 수 있습니다. 그 조직이 agent에게 맡길 업무를 충분히 구조화했는지입니다.