Blog

Zuplo API 게이트웨이: 개념과 활용법

Ashley Innocent

Ashley Innocent

27 April 2026

Zuplo API 게이트웨이: 개념과 활용법

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

대부분의 API 게이트웨이는 여전히 2014년 운영팀을 위해 설계된 것처럼 느껴집니다. YAML을 작성하고, 제어 평면과 씨름하며, 클러스터 접근 권한이 있는 사람이 변경 사항을 푸시하기를 기다립니다. Zuplo는 이러한 모델을 뒤집습니다. 이 게이트웨이는 프로그래밍 가능한 엣지 네이티브 API 게이트웨이로, 라우트가 Git 저장소에 저장되고, 정책은 TypeScript로 작성되며, 모든 커밋은 몇 초 만에 300개 이상의 전 세계 위치에 배포됩니다.

이 가이드는 Zuplo API 게이트웨이가 무엇을 하는지, Kong 및 AWS API Gateway와 어떻게 다른지, 비용은 얼마인지, 그리고 30분 이내에 첫 번째 게이트웨이를 배포하는 방법을 설명합니다. 라우팅, 인증, 속도 제한에 대한 코드 예시와 프로덕션에 적용하기 전에 Apidog로 모든 엔드포인트를 테스트하는 섹션도 볼 수 있습니다.

버튼

Zuplo는 과거 Kong, Apigee, AWS API Gateway가 지배했던 카테고리에 속합니다. 핵심은 간단합니다: 개발자는 실제 프로그래밍 언어를 얻고, 운영팀은 관리형 서비스를 얻으며, 제품팀은 내장된 수익화 레이어를 얻습니다. 이 게시물은 이러한 장단점과 실제 워크플로우를 자세히 설명합니다.

요약 (TL;DR)

Zuplo란 무엇인가요?

Zuplo는 API 관리 플랫폼으로, 코드 우선 설정, 리전 우선 엣지, GUI 우선 Git이라는 세 가지 아이디어를 기반으로 구축되었습니다. Cloudflare의 엣지 네트워크에서 완전 관리형 서비스로 실행되므로, 단 한 번의 배포로 사용자가 아무것도 프로비저닝할 필요 없이 300개 이상의 데이터 센터에 도달합니다.

대부분의 게이트웨이가 구성을 제어 평면 데이터베이스에 저장된 YAML 아티팩트로 취급하는 반면, Zuplo는 게이트웨이를 TypeScript 프로젝트로 취급합니다. 엔드포인트를 설명하는 routes.oas.json 파일, 사용자 지정 로직을 위한 TypeScript 모듈 폴더, 그리고 연결할 정책을 위한 구성 파일을 얻습니다. GitHub에 푸시하면 플랫폼이 빌드, 검증 및 배포합니다.

이 플랫폼은 REST, GraphQL, gRPC, WebSockets, SOAP를 지원합니다. SOC 2 Type II를 준수하며, AWS, Azure, GCP 백엔드에서 실행되고, 엄격한 데이터 상주 규칙이 있는 팀을 위한 자체 호스팅 Kubernetes 옵션도 제공합니다. 가격은 무료로 시작하며, 좌석당 요금이 아닌 요청 볼륨에 따라 확장됩니다. 전체 내역은 Zuplo 가격 페이지에 있습니다.

개발자들이 Kong, Apigee, AWS API Gateway 대신 Zuplo를 선택하는 이유

각 게이트웨이는 고유한 특징을 가지고 있습니다. Kong은 최대의 제어 권한을 제공하지만 Lua 전문 지식을 요구하는 오픈 소스 강자입니다. Apigee는 심층적인 분석과 가파른 학습 곡선을 가진 엔터프라이즈 플랫폼입니다. AWS API Gateway는 스택이 이미 AWS에 있는 경우 기본 선택이지만, 개발자 포털이 부족하고 람다 통합 시 콜드 스타트 비용이 실제로 발생합니다.

Zuplo는 다른 구매자를 목표로 합니다. 즉, 엔터프라이즈급 기능을 원하지만 이를 운영할 플랫폼 엔지니어링 인력이 없는 소규모 팀입니다.

몇 가지 구체적인 차이점은 다음과 같습니다:

팀이 이미 Kong이나 Apigee에 투자했고 운영 부하가 괜찮다면, 전환할 가치는 거의 없습니다. 새로 선택하거나 현재 게이트웨이가 불편하다면, Zuplo 워크플로우는 오늘날 출시된 어떤 플랫폼보다도 가장 명확한 개선점입니다.

Zuplo API 게이트웨이의 핵심 기능

TypeScript 우선 프로그래밍 가능성

게이트웨이 동작은 라우트 옆에 있는 TypeScript 파일에 정의됩니다. 사용자 지정 인바운드 및 아웃바운드 정책은 요청을 받아 원하는 작업을 수행하고 수정된 요청 또는 응답을 반환하는 함수입니다. TypeScript 툴체인 전체(타입, 자동 완성, 리팩토링, 테스트)를 얻을 수 있습니다.

클라이언트에게 응답하기 전에 내부 헤더를 제거하는 간단한 아웃바운드 정책:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  response: Response,
  request: ZuploRequest,
  context: ZuploContext,
) {
  response.headers.delete("x-internal-trace-id");
  return response;
}

이것이 정책의 전부입니다. 이를 modules/strip-internal-header.ts에 넣고, 라우트에서 참조하고, Git에 푸시하면 배포됩니다.

60개 이상의 사전 구축된 정책

대부분의 팀은 기본 사항에 대해 사용자 지정 코드를 작성하지 않을 것입니다. Zuplo는 API 키 인증, JWT 유효성 검사, OAuth 2.0, 속도 제한(고정 창, 슬라이딩 창, 토큰 버킷), OpenAPI 스키마에 대한 요청 및 응답 유효성 검사, CORS, IP 허용 목록, 요청 변환 및 몇 가지 업스트림 통합을 포함하는 60개 이상의 사전 구축된 정책을 제공합니다. 표준 사례의 경우 코드 변경 없이 라우트 정의를 편집하여 연결할 수 있습니다.

자동 생성되는 개발자 포털

포털을 OpenAPI 사양에 연결하면 호스팅된 문서 사이트를 얻을 수 있습니다. 이 사이트에는 대화형 "직접 해보기" 콘솔, cURL, JavaScript, Python, Go 등의 코드 샘플, 그리고 자체 서비스 API 키 발급 기능이 포함되어 있습니다. 최종 사용자는 등록하고, 키를 생성하고, API를 호출하기 시작할 수 있으며, 이 모든 과정에서 사람의 개입이 필요 없습니다. 개발자 채택에 의존하는 SaaS API의 경우, 이것만으로도 플랫폼을 사용하는 정당한 이유가 됩니다.

내장 API 수익화

Zuplo는 API 접근 판매를 위한 Stripe 통합 기능을 제공합니다. 요금제(무료, 프로, 엔터프라이즈)를 정의하고 Stripe를 연결하면 포털이 결제, 구독 관리 및 사용량 기반 청구를 처리합니다. 이는 API 게이트웨이에서는 드문 일입니다. Kong과 AWS API Gateway는 모두 수익화를 독자의 몫으로 남겨둡니다. API 호출에 대한 비용을 청구하는 경우, Zuplo의 수익화 흐름은 여러 주간의 구축 작업을 없애줍니다.

AI 에이전트용 MCP 서버 핸들러

최신 추가 기능은 MCP 서버 핸들러입니다. OpenAPI 사양을 가리키고 노출할 작업을 선택하면 기존 API는 Claude Code, OpenAI Codex, Cursor 및 기타 MCP 호환 클라이언트에서 호출 가능해집니다. 사람 호출자에게 적용했던 동일한 인증 및 속도 제한 정책이 AI 에이전트에게도 적용됩니다. Zuplo는 구성에 대해 자세히 다루는 MCP를 통해 API 노출에 대한 설명서를 발행했습니다.

엣지 배포, 50ms 미만 지연 시간

모든 게이트웨이는 기본적으로 300개 이상의 Cloudflare 엣지 위치에 배포됩니다. 플랫폼은 콜드 스타트 없이 엣지에서 50ms 미만의 지연 시간을 주장합니다. 실제로 이는 싱가포르의 사용자가 API를 호출하면 싱가포르에 상주하는 게이트웨이를 통해 호출되며, 이 게이트웨이는 사용자의 오리진이 있는 곳으로 프록시합니다. 사용자가 이를 구성할 필요는 없으며, 이것이 유일한 배포 모드입니다.

Zuplo의 작동 방식

가장 가까운 엣지 위치에 요청이 도착하면 다음 파이프라인을 거칩니다:

  1. 라우트 매칭. 요청 URL과 메서드는 routes.oas.json과 비교되어 올바른 핸들러를 찾습니다.
  2. 인바운드 정책. 연결된 모든 것(API 키 인증, JWT 유효성 검사, 속도 제한, 스키마 유효성 검사)이 순서대로 실행됩니다. 정책이 예외를 발생시키거나 응답을 반환하면 파이프라인이 단락되고 해당 응답이 클라이언트로 돌아갑니다.
  3. 핸들러. 핸들러는 업스트림 오리진으로 프록시하거나, 정적 값을 반환하거나, 사용자 지정 TypeScript를 실행하거나, MCP 서버 핸들러를 호출합니다.
  4. 아웃바운드 정책. 응답 변환, 헤더 제거 및 모든 사용자 지정 아웃바운드 로직이 실행됩니다.
  5. 응답. 최종 응답은 클라이언트로 돌아가고, 로그와 메트릭은 Zuplo의 관측 가능성 레이어(또는 통합을 통해 사용자의 공급자)로 전송됩니다.

이 모든 과정은 Cloudflare Worker에서 실행되므로, 낮은 지연 시간 수치가 유지되고 유휴 용량에 대한 비용을 지불할 필요가 없습니다.

첫 번째 Zuplo 게이트웨이 설정

대략 30분 만에 작동하는 게이트웨이를 구축할 수 있습니다. 워크플로우는 다음과 같습니다:

  1. zuplo.com에 가입하고 새 프로젝트를 만드세요. 프로젝트가 직접 제어하는 저장소에 동기화되도록 GitHub 통합을 선택합니다.
  2. OpenAPI 사양을 가져오세요. 업스트림 API에 이미 사양이 있다면 가져오세요. Zuplo는 각 작업을 라우트로 변환합니다. 아직 사양이 없다면 UI에서 라우트를 스케치하고 나중에 사양을 내보낼 수 있습니다.
  3. API 키 인증 정책을 추가하세요. 라우트 편집기에서 api-key-inbound 정책을 추가하세요. Zuplo는 소비자 데이터베이스와 키 발급 UI를 자동으로 생성합니다.
  4. 속도 제한을 추가하세요. rate-limit-inbound 정책을 사용하여 API 키당 분당 100회 요청과 같은 요청 예산을 설정하세요. 이것은 라우트 파일의 JSON 블록 하나입니다.
  5. 배포하세요. 브랜치에 푸시하세요. Zuplo는 고유한 URL로 미리보기 환경을 구축합니다. 병합하여 프로덕션으로 승격하세요.
  6. 게이트웨이를 엔드투엔드로 테스트하세요. Apidog를 사용하여 유효하거나 유효하지 않은 API 키, 초과된 속도 제한, 잘못된 페이로드를 포함한 요청을 새 게이트웨이 URL로 보냅니다. 시각적 응답 검사기를 통해 올바른 정책이 올바른 순서로 실행되었는지 쉽게 확인할 수 있습니다.

첫 번째 프로젝트는 몇 분 안에 배포됩니다. 더 어려운 작업은 라우트 이름을 잘 지정하고 사용자 지정 로직을 어디에 배치할지 결정하는 것인데, 이는 어떤 플랫폼에서든 발생하는 동일한 문제입니다.

TypeScript로 사용자 지정 정책 작성

사전 구축된 정책은 일반적인 경우를 다룹니다. 그 외의 모든 경우에는 사용자 지정 정책을 작성하십시오. 일반적인 예는 내부 서비스의 데이터로 요청을 강화하여 원본에 도달하기 전에 처리하는 것입니다:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

interface UserContext {
  userId: string;
  plan: "free" | "pro" | "enterprise";
}

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
): Promise<ZuploRequest | Response> {
  const apiKey = request.user?.sub;
  if (!apiKey) {
    return new Response("Unauthorized", { status: 401 });
  }

  const lookupUrl = `https://internal.example.com/users/${apiKey}`;
  const userResponse = await fetch(lookupUrl, {
    headers: { authorization: `Bearer ${context.environment.INTERNAL_TOKEN}` },
  });

  if (!userResponse.ok) {
    return new Response("User lookup failed", { status: 502 });
  }

  const user = (await userResponse.json()) as UserContext;
  request.headers.set("x-user-id", user.userId);
  request.headers.set("x-user-plan", user.plan);
  return request;
}

여기서 주목할 세 가지 사항이 있습니다. 첫째, 정책은 일반적인 비동기 함수입니다. 이를 테스트하는 것은 단위 테스트이며, 여러 Fixture를 사용하는 통합 테스트가 아닙니다. 둘째, 환경 변수는 context.environment에서 가져오며, 이는 타입 안전하고 프로젝트 설정에서 가져옵니다. 셋째, Response를 반환하면 파이프라인이 단락되는데, 이는 인증 실패 또는 업스트림 오류를 깔끔하게 표현하는 방법입니다.

2026년 Zuplo 가격

Zuplo의 가격 정책은 이 카테고리에서는 이례적으로 간단합니다. 세 가지 요금제:

AI Gateway 및 개발자 포털 제품은 별도의 티어를 가지며, 월 $0의 오픈 소스 자체 호스팅 포털도 포함됩니다. 현재 수치는 Zuplo 가격 페이지에 있으며, 계약 전에 확인하는 것이 좋습니다.

비교해보면: AWS API Gateway는 REST 요청 100만 건당 $3.50를 청구하며, 여기에 데이터 전송 비용과 람다 통합을 사용하는 경우 람다 비용이 추가됩니다. Kong의 엔터프라이즈 티어는 맞춤형이며, 역사적으로 Zuplo의 최소 $1,000보다 훨씬 높습니다. 무료 티어만으로도 초기 단계 프로젝트에는 Zuplo가 매우 매력적입니다.

Zuplo가 적합한 경우와 그렇지 않은 경우

Zuplo는 다음과 같은 경우에 강력하게 적합합니다:

Zuplo는 다음과 같은 경우에 적합하지 않습니다:

Apidog로 Zuplo 게이트웨이 테스트하기

게이트웨이가 미리보기 환경에서 활성화되면, 프로덕션으로 승격하기 전에 모든 라우트, 모든 정책 및 모든 엣지 케이스를 테스트해야 합니다. 이때 전용 API 클라이언트가 빛을 발합니다.

Apidog는 OpenAPI 사양을 직접 가져오므로, Zuplo 라우트를 구동하는 동일한 사양이 테스트 스위트도 구동합니다. 거기서부터 다음을 수행할 수 있습니다:

또한 Apidog의 자동화된 테스트 시나리오를 게이트웨이에 대해 실행할 수 있으며, 이는 일회성 스크립트를 작성하는 것보다 빠릅니다. 이전에 Apidog를 사용해 본 적이 없다면, Apidog VS Code 확장 프로그램을 사용하면 편집기를 떠나지 않고 요청을 보낼 수 있으며, 다른 클라이언트에서 전환하는 경우 Postman 없이 API 테스트 가이드가 마이그레이션 과정을 안내합니다. 시작하려면 Apidog를 다운로드하세요.

Zuplo API 게이트웨이에 대한 일반적인 질문

Zuplo는 오픈 소스인가요?

코어 게이트웨이 런타임은 비공개 소스이지만, Zuplo는 개발자 포털과 여러 지원 라이브러리를 GitHub에 오픈 소스로 공개했습니다. 자체 호스팅 옵션이 필요한 경우, 오픈 소스 포털과 게이트웨이의 자체 호스팅 Kubernetes 배포는 대부분의 요구 사항을 충족합니다. 대부분의 팀은 관리형 서비스를 계속 사용합니다.

Zuplo를 제 인프라에서 실행할 수 있나요?

네. 엔터프라이즈 플랜에는 자체 호스팅 Kubernetes 옵션이 포함되어 있습니다. 단점은 전역 엣지 배포를 포기하고 클러스터 운영을 직접 담당해야 한다는 것입니다. 엄격한 데이터 상주 규칙이 있는 팀에게는 이것이 올바른 선택입니다.

Zuplo는 Cloudflare API Shield와 어떻게 비교되나요?

API Shield는 모든 원본 앞에 위치하는 보안 중심 제품(스키마 유효성 검사, 남용 탐지, mTLS)입니다. Zuplo는 라우팅, 정책, 개발자 포털, 수익화, MCP 지원을 포함하는 완전한 API 관리 플랫폼입니다. 이 둘은 공존할 수 있습니다. 보안 신호만 필요한 경우 API Shield로 충분합니다. 전체 수명 주기가 필요한 경우 Zuplo가 플랫폼입니다.

Zuplo는 기존 OpenAPI 사양과 함께 작동하나요?

네. OpenAPI는 Zuplo에서 신뢰할 수 있는 정보원(Source of Truth)입니다. 사양을 가져오면 라우트가 나타나고, 동일한 사양에서 개발자 포털이 생성되며, 요청 유효성 검사 정책은 동일한 스키마를 사용합니다. 사양이 복잡하면 가져오기 과정에서 이를 알게 될 것입니다.

Claude 또는 Codex와 같은 AI 에이전트에 Zuplo 게이트웨이를 노출할 수 있나요?

네, MCP 서버 핸들러를 통해 가능합니다. 핸들러를 OpenAPI 사양에 연결하고 노출할 작업을 선택하면 게이트웨이가 모든 MCP 호환 클라이언트에서 호출 가능해집니다. 사람이 호출하는 경우에 정의한 것과 동일한 인증 및 속도 제한 정책이 자동으로 적용됩니다.

Zuplo 배포는 얼마나 걸리나요?

미리보기 환경의 경우 푸시-투-배포 주기는 일반적으로 60초 미만입니다. 프로덕션 승격은 아티팩트가 이미 빌드되었기 때문에 더 빠릅니다. 유지보수 기간이 없으며, 배포는 원자적으로 이루어집니다.

Cloudflare가 다운되면 어떻게 되나요?

Zuplo는 Cloudflare의 엣지 네트워크에서 실행되므로, Cloudflare의 지역 장애는 해당 지역에 영향을 미칠 것입니다. 엔터프라이즈 플랜은 99.999% 가용성이 필요한 팀을 위해 멀티 클라우드 장애 조치 옵션을 제공합니다. 대부분의 팀은 Cloudflare의 안정성 기록을 고려할 때 이러한 종속성을 받아들입니다.

결론

Zuplo는 운영 부담 없이 엔터프라이즈 기능을 원하는 팀을 위한 API 게이트웨이입니다. TypeScript 네이티브 정책, GitOps 배포, 자동 생성 개발자 포털, 내장 수익화, 그리고 이제 AI 에이전트를 위한 MCP 지원을 통해 단순한 라우팅 계층이 아닌 완전한 플랫폼이 됩니다. 무료 티어는 실제 프로덕션 트래픽을 처리하기에 충분히 관대하며, 엔터프라이즈 플랜은 그 외의 모든 것을 처리합니다.

평가 중이라면, 실제 API 중 하나로 30분 설정을 해보고, 모든 정책을 검증하기 위해 Apidog를 통해 실행한 다음, 마케팅 페이지가 아닌 증거를 바탕으로 결정하십시오. 관리형 엣지 게이트웨이와 강력한 테스트 클라이언트의 조합은 "API가 있습니다"에서 "제품이 있습니다"로 가는 가장 빠른 길입니다. Apidog를 다운로드하고 테스트를 시작하십시오.

버튼

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드