- Published on
Mastra 실전 가이드: 2026년 TypeScript 팀이 프로덕션 AI 에이전트에 채택하는 이유
- Authors

- Name
- Youngju Kim
- @fjvbn20031
프로덕션에서 Mastra가 중요한 이유
Mastra는 AI 기반 애플리케이션과 에이전트를 만들기 위한 오픈소스 TypeScript 프레임워크다. 공식 포지셔닝은 단순한 에이전트 래퍼보다 훨씬 넓다. 에이전트, 도구, MCP, 메모리, 워크플로, RAG, 평가, 벡터 스토어, 데이터셋을 한 스택에서 제공한다. 즉, 프롬프트 한 번 감싸는 도구가 아니라 실제 제품 안에서 돌아가는 AI 시스템을 위한 기반에 가깝다.
2026년에 들어서 이 메시지는 더 강해졌다. 2026년 1월 20일에는 Mastra 1.0이 AI SDK v6 지원, 서버 어댑터, thread cloning, composite storage를 추가했다. 이어서 2026년 2월 9일에는 observational memory가 안정적인 컨텍스트 윈도우를 제공한다고 설명했다. 2026년 4월 1일에는 실행마다 duration, token usage, estimated cost를 자동으로 잡는 metrics와 logs가 추가됐다.
이건 장난감이 아니라 프로덕션 스택이다.
가벼운 래퍼보다 나은 지점
Mastra는 하나의 모델 호출과 몇 개의 헬퍼 함수만으로 끝나지 않을 때 빛난다.
| 상황 | Mastra가 맞는 이유 |
|---|---|
| TypeScript로 제품을 만들고 있다 | 이미 쓰는 언어와 생태계를 기준으로 설계되어 있다 |
| 에이전트에 메모리와 컨텍스트가 필요하다 | 메모리가 후순위가 아니라 핵심 프리미티브다 |
| 제품에 워크플로가 필요하다 | 오케스트레이션이 별도 라이브러리가 아니라 프레임워크 일부다 |
| 평가와 관측 가능성을 함께 보고 싶다 | 로깅, 트레이싱, 평가, 메트릭이 한 흐름으로 이어진다 |
| MCP와 도구 실행이 필요하다 | 도구와 MCP가 핵심 플랫폼 구성요소로 들어 있다 |
| 기존 앱에 붙이고 싶다 | 서버 어댑터 덕분에 Express, Hono, Fastify, Koa와의 통합이 쉽다 |
단순한 프롬프트 보조만 필요하다면 더 가벼운 래퍼가 저렴하다. 하지만 메모리, 워크플로, 평가, 운영 가시성이 필요하면 Mastra가 훨씬 맞는 선택이다.
메모리와 컨텍스트는 핵심 기능이다
Mastra에서 가장 눈에 띄는 장점은 observational memory다. 2026년 2월 9일 글은 이 메모리 시스템이 안정적인 컨텍스트 윈도우를 유지하고, 여러 턴에 걸쳐 prompt cache에 잘 맞도록 설계됐다고 설명한다. 매번 동적으로 검색한 조각을 프롬프트에 다시 쓰는 대신, 예측 가능한 observation log를 유지하고 원시 대화를 compact observation으로 바꾼다.
이게 중요한 이유는 긴 대화가 보통 두 가지 방식으로 망가지기 때문이다.
- 컨텍스트 윈도우가 너무 커져서 비용이 올라가거나 불안정해진다
- 검색을 너무 많이 하거나 너무 적게 해서 동작이 예측 불가능해진다
Observational memory는 이 두 문제를 줄이기 위해 만들어졌다. 다음 같은 경우에 특히 잘 맞는다.
- 오래가는 고객 지원 도우미
- 세일즈나 계정용 코파일럿
- 사용자 이력이 반복되는 리서치 에이전트
- 컨텍스트 모양이 계속 바뀌면 성능이 나빠지는 모든 어시스턴트
실무 교훈은 단순하다. 메모리가 제품 요구사항이 되면, 명시적이고 측정 가능하며 캐시 친화적인 메모리 시스템이 필요하다.
워크플로와 스토리지는 분리할 수 없는 문제다
Mastra 1.0은 워크플로 이야기를 더 프로덕션 친화적으로 만들었다. 2026년 1월 20일 릴리스에서 AI SDK v6 지원, 서버 어댑터, thread cloning, composite storage가 들어갔다. 특히 composite storage는 memory, workflows, scores, observability를 한 저장소로 억지로 묶지 않고 도메인별로 맞는 백엔드를 고를 수 있게 해 준다.
실제 팀에서는 모든 하위 시스템이 같은 저장소 선택을 원하지 않는다.
- memory는 가벼운 저장소가 더 좋을 수 있다
- workflows는 트랜잭션형 데이터베이스가 더 맞을 수 있다
- observability는 분석 친화적 저장소가 더 맞을 수 있다
Mastra의 서버 어댑터도 중요하다. 이미 Express, Hono, Fastify, Koa 위에서 앱을 돌리고 있다면, 에이전트를 쓰기 위해 런타임 전체를 다시 짤 필요가 없다. 덕분에 점진적으로 도입하기 쉽다.
관측 가능성이 채택 이유가 되는 이유
Mastra는 관측 가능성을 덧붙이는 기능으로 취급하지 않는다. 공식 observability 문서는 에이전트와 워크플로를 위한 first-class logging, tracing, evals를 이야기한다.
2026년 4월 1일 기준으로 Mastra Studio는 모든 agent run, tool call, workflow, model invocation에 대해 duration, token usage, estimated cost를 자동으로 수집한다. 이건 운영에서 매우 큰 차이다. 동작과 비용을 같은 화면에서 볼 수 있기 때문이다.
실제로는 다음 질문에 답할 수 있다.
- 어느 워크플로 단계가 느린가
- 어떤 도구 호출이 비싼가
- 어떤 에이전트 경로의 점수가 가장 좋은가
- 비용 급증이 어디서 시작됐는가
- 변경이 품질을 올렸는지, 아니면 토큰만 옮겼는지
이런 가시성은 AI 기능이 데모 트래픽을 넘어서 실제 사용자에게 들어갈 때 꼭 필요하다.
MCP와 도구는 플랫폼의 일부다
Mastra의 공식 포지셔닝에는 에이전트, 도구, MCP가 같은 스택으로 들어 있다. 에이전트 문서도 memory, tool calling, MCP, logging, tracing, eval primitives를 갖춘 stateful agent 플랫폼으로 설명한다.
이게 중요한 이유는 본격적인 에이전트가 모델만으로는 부족하기 때문이다.
- 내부 도구가 필요하다
- 외부 서비스가 필요하다
- 안전한 실행 경계가 필요하다
- 승인과 추적이 필요하다
Mastra는 이런 요소를 플랫폼의 일부로 다루기 때문에, 각 팀이 직접 전부 만들어야 하는 부담을 줄여 준다.
1.0 이후 메모리 스토리
2026년 2월 9일의 observational memory 발표는 별도로 볼 가치가 있다. 핵심은 안정적인 컨텍스트 윈도우다.
동적으로 검색한 결과를 매 턴 다시 주입하는 대신, observation 중심의 예측 가능한 히스토리를 유지한다. 이렇게 하면 latency와 신뢰성이 모두 좋아진다.
특히 prompt caching이 중요할 때 효과가 크다. 컨텍스트 모양이 안정적이면 캐시 효율이 좋아지고, append-only 성격이 강하면 프롬프트 변동도 줄어든다.
즉, 컨텍스트 팽창이 비용 문제인 제품일수록 Mastra의 메모리 설계가 매력적이다.
실전 롤아웃 체크리스트
Mastra를 하나의 에이전트 데모 이상으로 넓히기 전에 다음을 확인하자.
- 비즈니스에 의미 있는 워크플로를 하나 고른다.
- 첫 버전에 메모리가 필요한지, 단순 상태만 필요한지 정한다.
- 각 storage 도메인이 어디에 살아야 하는지 정한다.
- 프로덕션 시험 단계부터 로깅, 트레이싱, 평가를 켠다.
- 프롬프트를 튜닝하기 전에 평가 데이터셋을 만든다.
- 허용할 MCP 서버와 모니터링 방법을 정한다.
- 실제 히스토리를 바꾸지 않으려면 thread cloning을 쓴다.
- duration, token usage, estimated cost를 기본 메트릭으로 본다.
- 모델 라우팅 규칙을 정해 앱 전체를 다시 쓰지 않고도 모델을 바꿀 수 있게 한다.
- 워크플로나 도구 호출이 중간에 실패했을 때의 동작을 테스트한다.
흔한 실수
가장 큰 실수는 메모리를 무제한 채팅 기록처럼 취급하는 것이다. 그러면 컨텍스트 윈도우가 금세 지저분하고 비싸진다.
그 외에도 다음 실수가 자주 보인다.
- 첫 출시가 끝날 때까지 평가를 미루기
- 모든 데이터를 하나의 저장소에 넣기
- 로그와 트레이스를 운영 계획 없이 섞어 쓰기
- 모든 문제를 멀티 에이전트 구조로 풀려 하기
- 제품이 이미 비싸진 뒤에 토큰 비용을 보기 시작하기
Mastra는 에이전트를 프롬프트 실험이 아니라 실제 런타임 시스템으로 다룰 때 가장 잘 맞는다.
실무 결론
Mastra는 AI 애플리케이션과 에이전트를 위한 오픈소스 TypeScript 플랫폼을 원하는 팀에 잘 맞는다. 메모리, 워크플로, 관측 가능성, 평가, MCP, 배포 친화적 어댑터가 함께 묶여 있다는 점이 프로덕션 지향적으로 느껴지는 이유다.
모델 호출만 살짝 감싸려는 목적이라면 더 가벼운 도구가 맞다. 하지만 실제로 운영하고, 측정하고, 확장할 수 있는 TypeScript 에이전트 스택이 필요하다면 Mastra가 그 역할을 위해 설계되어 있다.