Standard Schema 1.0 도입 — AI 에이전트 도구에서 Zod 의존성 없앤다

AI 에이전트에게 새로운 도구를 쥐어줄 때, 왜 항상 Zod라는 특정 라이브러리만 사용해야 했을까요? 지금까지 수많은 에이전트 프레임워크는 도구의 입력 데이터 구조를 정의하고 검증하기 위해 Zod에 지나치게 강하게 결합되어 있었습니다.

하지만 최근 에이전트 생태계의 판도가 완전히 바뀌고 있습니다. 모델 컨텍스트 프로토콜(MCP) TS SDK v2.0과 에이전트 프레임워크인 마스트라(Mastra) v1.2.0 등이 '스탠다드 스키마(Standard Schema) v1.0'을 전격 도입했기 때문입니다.

이제 개발자들은 Zod뿐만 아니라 밸리봇(Valibot)이나 아크타입(ArkType) 같은 가볍고 빠른 검증 라이브러리를 취향에 따라 마음껏 섞어 쓸 수 있게 되었습니다. 에이전트 개발 환경을 더 자유롭고 가볍게 만들어 줄 이 새로운 흐름을 지금부터 살펴보겠습니다.

왜 Zod만 써야 했을까? 의존성 지옥의 시작

LLM이 외부 도구를 사용하려면 입력받을 데이터의 규격을 명확히 알아야 합니다. 인공지능에게 "이 도구를 실행하려면 이런 데이터 형식으로 값을 보내줘"라고 알려주는 'JSON 스키마'가 반드시 필요하기 때문입니다.

그동안 타입스크립트 환경의 개발자들은 이 복잡한 스키마를 정의하고 입력값을 검증하기 위해 관행처럼 Zod 라이브러리를 사용해 왔습니다. 타입스크립트 타입 선언과 실시간 데이터 검증을 동시에 매끄럽게 해결해 주다 보니, 에이전트 도구를 만들 때 사실상 표준처럼 쓰였습니다.

하지만 이 결합은 뜻밖의 '의존성 지옥'을 불러왔습니다. 에이전트 프레임워크나 SDK가 특정 Zod 버전을 내부적으로 고집하면서, 정작 개발자가 프로젝트에서 쓰는 최신 버전과 충돌하는 일이 빌비재했습니다. 또한, 가볍고 빠른 엣지 환경에 맞추어 더 경량화된 검증 도구를 쓰고 싶어도 무겁고 거대한 Zod를 억지로 패키지에 담아야 하는 비효율이 발생했습니다.

Standard Schema v1.0 — 모든 검증 라이브러리를 하나로

스탠다드 스키마(Standard Schema) v1.0은 쉽게 말해, 서로 다른 언어를 쓰는 사람들이 막힘없이 대화할 수 있도록 돕는 공통 약속입니다. 이것은 새로운 데이터 검증 라이브러리가 아닙니다. Zod, Valibot, ArkType처럼 각기 다른 방식으로 데이터를 검증하던 도구들이 하나의 공통된 규칙으로 소통할 수 있게 약속한 아주 가볍고 단순한 인터페이스 체계입니다.

핵심 원리는 매우 간단합니다. 표준을 따르는 모든 라이브러리는 객체 내부에 ~standard라는 약속된 공간을 마련하고, 공통 검증 메서드인 validate를 제공하기만 하면 됩니다.

// Standard Schema v1.0 규격을 따르는 스키마 객체의 기본 구조
const mySchema = {
  "~standard": {
    version: 1,
    vendor: "valibot",
    validate: async (value) => {
      // 검증 라이브러리가 내부적으로 처리 후 표준화된 결과 반환
    }
  }
};

이렇게 약속된 규격이 잡혀 있으면 에이전트 프레임워크나 SDK를 만드는 개발자 입장에서 매우 편리해집니다. 사용자가 Zod를 쓰든 Valibot을 쓰든 상관없이, 언제나 ~standard.validate()라는 동일한 방법으로 데이터를 안전하게 검증할 수 있기 때문입니다.

특히 AI 에이전트 환경에 맞춘 확장 규격은 더욱 유용합니다. LLM이 도구를 올바르게 사용하려면 입력받을 데이터 규격이 담긴 JSON 스키마를 읽을 수 있어야 하는데요. 이 표준 규격을 활용하면 별도의 변환기 없이도 스키마에서 LLM이 이해하는 JSON 스키마를 즉시 안전하게 추출할 수 있습니다.

MCP SDK v2.0과 Mastra가 이 표준을 쓰는 법

이 표준이 단순한 기술 제안을 넘어 실제 에이전트 생태계의 대세로 빠르게 자리 잡고 있다는 것은 최근 발표된 핵심 도구들을 보면 확실히 알 수 있습니다.

가장 대표적인 변화는 2026년 7월 말 공식 출시된 MCP TS SDK v2.0에서 일어났습니다. 이전 버전까지는 도구의 입력 형식을 정의할 때 무조건 Zod 스키마에 의존해야 했습니다. 하지만 v2.0부터는 Zod 의존성을 완전히 제거하고, 대신 스탠다드 스키마 기반의 StandardSchemaWithJSON 인터페이스를 전격 채택했습니다. 이제 개발자는 특정 라이브러리에 묶이지 않고 Zod v4, 발리봇(Valibot), 아크타입(ArkType) 중 프로젝트 상황에 맞는 최적의 검증 도구를 선택해 자유롭게 도구를 만들 수 있습니다.

또 다른 강력한 에이전트 프레임워크인 마스트라(Mastra) v1.2.0도 발 빠르게 움직였습니다. 마스트라는 서로 다른 검증 도구들의 충돌 문제를 깔끔하게 정리하기 위해 @mastra/schema-compat이라는 호환성 패키지를 도입했습니다. 이 패키지가 제공하는 toStandardSchema() 함수를 사용하면 Zod v3, v4 또는 다양한 AI SDK 스키마를 하나의 단일화된 표준 포맷으로 매끄럽게 변환해 줍니다.

이 기술이 실제 코드에서 어떻게 사용되는지 마스트라의 통합 방식을 보면 한눈에 이해할 수 있습니다.

// Mastra v1.2.0 기반 스키마 변환 예시
import { toStandardSchema } from '@mastra/schema-compat';
import { z } from 'zod';

// 평소처럼 작성한 Zod 스키마
const userProfileSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});

// 스탠다드 스키마 표준 포맷으로 간편하게 변환
const standardSchema = toStandardSchema(userProfileSchema);

이렇게 변환된 스키마는 에이전트가 LLM에게 도구 스펙을 전달하고 입력 값을 다시 검증하는 모든 과정에서 일관성 있게 작동합니다. 특정 라이브러리에 강하게 묶여 있던 제약이 사라지면서, 개발자가 원하는 퍼즐 조각을 자유롭게 골라 끼울 수 있는 유연한 환경이 열린 것입니다.

클라우드플레어 워커에서 만나는 뜻밖의 함정

클라우드플레어 워커 같은 가벼운 엣지 환경에 에이전트를 올릴 때는 예상치 못한 복병을 조심해야 합니다. Mastra v1.2.0의 @mastra/schema-compat처럼 다양한 검증 도구를 표준 스펙으로 바꿔주는 변환기를 사용할 때 자주 발생하는 문제입니다.

가장 대표적인 함정은 Zod 스키마에서 세부 검증을 위해 사용하는 refine 이나 superRefine 메서드입니다. 이 메서드를 적용하면 Zod 스키마 타입이 ZodObject에서 ZodEffects로 바뀌게 됩니다. 변환기는 이 특수한 타입을 처리하기 위해 내부적으로 AJV 같은 라이브러리를 동원해 실시간으로 JSON 스키마를 동적 컴파일하려고 시도합니다.

이때 자바스크립트의 동적 코드 실행 기능인 new Function()을 호출하게 되는데, 보안이 엄격한 V8 아이솔레이트 기반의 클라우드플레어 워커는 이 명령을 엄격히 차단합니다. 결국 에이전트가 도구를 호출하는 순간 즉시 멈추며 에러를 뿜게 됩니다.

// ❌ 엣지 환경에서 에러를 일으키는 패턴
const bugSchema = z.object({
  apiKey: z.string(),
}).refine((data) => data.apiKey.startsWith("sk-"));

// ✅ 안전한 패턴: 스키마는 단순하게 유지하고, 검증은 실행 함수 안에서 처리
const safeSchema = z.object({
  apiKey: z.string(),
});

따라서 엣지 환경에서 도구 스키마를 정의할 때는 가급적 단순한 기본 타입만 정의하고, 복잡한 커스텀 검증 로직은 스키마 외부인 도구의 실제 실행 함수 내에서 처리하는 것이 훨씬 안전합니다.

더 가볍고 유연해지는 에이전트 생태계

스탠다드 스키마 v1.0의 도입은 단순히 데이터 검증 라이브러리 하나를 바꾸는 것 이상의 변화를 뜻합니다. 특정 검증 도구에 묶이지 않는 유연함 덕분에, 앞으로 우리가 개발할 에이전트 도구들의 이식성은 훨씬 더 높아질 것입니다.

이제 개발자는 프레임워크의 제약에서 벗어나 가볍고 빠른 에이전트를 만들기 위해 필요한 기능만 골라 담을 수 있게 되었습니다. MCP TS SDK v2.0과 마스트라 v1.2.0이 이끌어갈, 한층 더 모듈화되고 가벼워질 에이전트 개발 환경을 기대해 봅니다.