Cloudflare Workers Service Bindings & RPC: 마이크로서비스 지연시간 0ms 및 비용 $0 아키텍처

전통적 마이크로서비스가 지불하는 숨겨진 세금: 네트워크 홉

모놀리식(Monolithic) 아키텍처를 독립적인 서비스(Auth, Payments, Users, Notifications 등)로 분리하는 마이크로서비스(Microservices) 아키텍처는 현대 백엔드 설계의 표준이 되었다. 각 서비스의 독립적인 배포, 개별 스케일링, 그리고 관심사의 분리(Separation of Concerns)는 큰 이점을 가져다준다.

하지만 기존 마이크로서비스 아키텍처는 내부 서비스끼리 통신할 때 심각한 성능 및 비용 세금을 지불하고 있다.

[API Gateway] 
      | -- (HTTP REST / gRPC 호출) --> DNS 조회 + TLS 핸드셰이크 + TCP RTT (15~50ms)
      v
[Auth Service]
      | -- (내부 HTTP REST 호출) --> API 토큰 인증 + JSON 인코딩 오버헤드 (15~50ms)
      v
[Payment Service]

1. 네트워크 지연시간 (Network Hop): 서비스를 분리할 때마다 DNS 조회, TLS 핸드셰이크, TCP 왕복 시간이 추가되어 지연시간이 최소 10ms~50ms씩 누적된다.
2. 이중 과금 및 Egress 수수료: 내부 서비스 간 HTTP 통신도 개별 요청(Request) 및 데이터 아웃바운드(Egress) 요금으로 정산된다.
3. 보안 복잡성: 내부 서비스가 외부 인터넷에 노출되지 않도록 API Key, OAuth 토큰, mTLS, VPC 게이트웨이를 복잡하게 관리해야 한다.

Cloudflare Workers Service Bindings와 **Native RPC (WorkerEntrypoint)**는 이 세 가지 문제를 한 번에 해결하는 차세대 서버리스 오케스트레이션 기술이다.

Service Bindings를 사용하면 두 개 이상의 독립적인 Workers 서비스가 통신할 때 네트워크 홉이 완전히 사라지며, 동일한 서버리스 V8 메모리 격리 공간(Isolate) 내부에서 지연시간 0ms(Sub-millisecond)로 인프로세스(In-Process) 직접 호출이 이루어진다.

이 글에서는 Service Bindings의 아키텍처 원리부터, 2025/2026년 표준인 WorkerEntrypoint RPC 실전 코드, 비공개(Private) 서비스 격리 보안, 그리고 벤치마크까지 상세히 다룬다.

Service Bindings vs 전통적 REST/gRPC 비교

Service Bindings 내부 동작 원리: In-Process Zero-Hop

Cloudflare는 전 세계 300개 이상의 데이터 센터에 애니캐스트(Anycast) 네트워크를 구축하고 있다.

사용자 요청이 오면 API Gateway Worker와 백엔드 Auth Worker가 동일한 Cloudflare 에지 데이터 센터 서버(V8 엔진) 내에서 실행된다. 이때 두 서비스를 Service Bindings로 묶으면 네트워크 카드를 거치지 않고 V8 C++ 메모리 레벨에서 직접 매핑된다.

+-------------------------------------------------------------------------+
| Cloudflare 에지 서버 (단일 V8 Engine 런타임)                              |
|                                                                         |
|  [API Gateway Worker]                                                   |
|           |                                                             |
|           |  (Service Binding: Zero Network Hop / 0ms Memory Call)      |
|           v                                                             |
|  [Auth Worker] ----------> [Payment Worker (WorkerEntrypoint RPC)]       |
|                                                                         |
+-------------------------------------------------------------------------+

1. HTTP/TCP 프로토콜 오버헤드 0: HTTP 메서드 헤더 파싱, TLS 암호화, TCP 패킷 조립 과정이 생략된다.
2. 100% 비공개 내부 서비스: auth-service나 payment-service는 인터넷 공개 URL(Route)을 가질 필요가 없다. 오직 외부 입구인 api-gateway를 통해서만 내부 진입이 허용된다.
3. 독립적 배포 파이프라인: 서비스는 내부 메모리로 연결되지만, 코드베이스와 Wrangler 배포 파이프라인은 100% 독립적으로 분리되어 팀별로 자유롭게 배포할 수 있다.

1단계: Native RPC (WorkerEntrypoint) 정의

2025/2026년 Cloudflare Workers는 과거의 fetch(request) 전송 방식 대신, TypeScript Class 메서드를 직접 호출하는 **Native RPC (WorkerEntrypoint)**를 공식 지원한다.

1. 결제 서비스 (payment-service) 구현

먼저 독립적인 내부 결제 마이크로서비스를 구현해보자. WorkerEntrypoint를 상속받은 클래스의 public 메서드가 곧 RPC 인터페이스가 된다.

// services/payment-service/src/index.ts
import { WorkerEntrypoint } from "cloudflare:workers";

export interface PaymentRequest {
  orderId: string;
  amount: number;
  currency: string;
}

export interface PaymentResponse {
  success: boolean;
  transactionId: string;
  processedAt: number;
}

// WorkerEntrypoint를 상속받아 외부 RPC 메서드 노출
export class PaymentService extends WorkerEntrypoint {
  // RPC 메서드 1: 결제 승인 연산
  async processPayment(req: PaymentRequest): Promise<PaymentResponse> {
    console.log(`[PaymentService] Processing order: ${req.orderId} for amount: ${req.amount}`);

    // 내부 결제 승인 연산 (DB 조회 및 암호화)
    const transactionId = `tx_${crypto.randomUUID().slice(0, 8)}`;
    
    return {
      success: true,
      transactionId,
      processedAt: Date.now(),
    };
  }

  // RPC 메서드 2: 환불 처리
  async refundPayment(transactionId: string): Promise<boolean> {
    console.log(`[PaymentService] Refunding transaction: ${transactionId}`);
    return true;
  }
}

// 공개 HTTP 핸들러가 없는 순수 비공개 서비스인 경우
export default {
  async fetch() {
    return new Response("Unauthorized - Internal RPC Service Only", { status: 403 });
  },
};

payment-service의 wrangler.jsonc 설정:

// services/payment-service/wrangler.jsonc
{
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "name": "payment-service",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"]
  // routes 등록 없음! -> 외부 인터넷에서 절대 직접 접근 불가
}

2. 인증 서비스 (auth-service) 구현

// services/auth-service/src/index.ts
import { WorkerEntrypoint } from "cloudflare:workers";

export interface UserSession {
  userId: string;
  role: "admin" | "user";
  isValid: boolean;
}

export class AuthService extends WorkerEntrypoint {
  // 토큰 검증 RPC 메서드
  async verifyToken(token: string): Promise<UserSession> {
    if (!token || !token.startsWith("Bearer ")) {
      return { userId: "", role: "user", isValid: false };
    }

    const rawToken = token.replace("Bearer ", "");
    // JWT 또는 KV 세션 검증 로직
    if (rawToken === "secret-admin-token") {
      return { userId: "usr_admin_01", role: "admin", isValid: true };
    }

    return { userId: "usr_regular_99", role: "user", isValid: true };
  }
}

export default {
  async fetch() {
    return new Response("Access Denied", { status: 403 });
  },
};

2단계: API Gateway에서 Service Bindings 연결 및 RPC 호출

이제 외부 요청을 받는 공개 메인 서비스(api-gateway)에서 위에서 만든 두 마이크로서비스를 Service Bindings로 묶고 RPC를 호출해보자.

api-gateway의 wrangler.jsonc 설정

services 배열을 선언하여 바인딩 이름과 대상 Worker 서비스 이름을 연결한다.

// services/api-gateway/wrangler.jsonc
{
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "name": "api-gateway",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // Service Bindings 선언
  "services": [
    {
      "binding": "AUTH_SERVICE",
      "service": "auth-service"
    },
    {
      "binding": "PAYMENT_SERVICE",
      "service": "payment-service"
    }
  ]
}

api-gateway 진입점 구현 (Hono.js 기반)

// services/api-gateway/src/index.ts
import { Hono } from "hono";
// 타입 안전성을 위해 각 서비스의 WorkerEntrypoint 클래스 타입 임포트
import type { AuthService } from "../../auth-service/src/index";
import type { PaymentService } from "../../payment-service/src/index";

type Env = {
  Bindings: {
    // ServiceBinding 타입 정의
    AUTH_SERVICE: Service<AuthService>;
    PAYMENT_SERVICE: Service<PaymentService>;
  };
};

const app = new Hono<Env>();

// 결제 요청 라우트
app.post("/api/v1/checkout", async (c) => {
  const authHeader = c.req.header("Authorization") ?? "";
  
  // 1. Auth Service RPC 직접 호출 (네트워크 홉 0ms!)
  // fetch() 대신 c.env.AUTH_SERVICE.verifyToken() 메서드를 바로 실행
  const session = await c.env.AUTH_SERVICE.verifyToken(authHeader);

  if (!session.isValid) {
    return c.json({ error: "Unauthorized access" }, 401);
  }

  const body = await c.req.json();

  // 2. Payment Service RPC 직접 호출 (지연시간 0ms 및 타입 지원)
  const paymentResult = await c.env.PAYMENT_SERVICE.processPayment({
    orderId: body.orderId,
    amount: body.amount,
    currency: "USD",
  });

  return c.json({
    message: "Checkout successful",
    user: session.userId,
    payment: paymentResult,
  });
});

export default app;

Notice how c.env.AUTH_SERVICE.verifyToken() is called just like a regular TypeScript function! There is no fetch(), no JSON body parsing code, and zero network serialization latency.

3단계: 로컬 개발 및 멀티 서비스 테스트 (wrangler dev)

Cloudflare Wrangler v3/v4는 여러 개의 독립적인 Worker 서비스를 로컬에서 동시에 띄우고 Service Bindings를 테스트할 수 있는 Multi-Worker Dev Mode를 지원한다.

로컬 테스트 명령어

# 1. Terminal A: auth-service 실행
cd services/auth-service
npx wrangler dev

# 2. Terminal B: payment-service 실행
cd services/payment-service
npx wrangler dev

# 3. Terminal C: api-gateway 실행 (로컬에서 Service Bindings가 자동 연결됨)
cd services/api-gateway
npx wrangler dev

api-gateway로 HTTP POST 요청을 보내면, 로컬 터미널 A, B, C에서 각 서비스가 인프로세스(In-Process)로 0.1ms 만에 상호작용하는 모습을 확인할 수 있다.

벤치마크: 전통적 HTTP REST vs Service Bindings RPC

동일한 3단계 마이크로서비스 연쇄 호출(Gateway -> Auth -> Payment) 시 응답 속도와 자원 사용량을 벤치마크하였다. (10,000회 요청 평균)

실전 아키텍처 패턴: Service Bindings 모듈화 패턴

Service Bindings를 활용하면 대형 엔터프라이즈 모노레포(Monorepo)나 도메인 기반 아키텍처(DDD)를 손쉽게 구축할 수 있다.

my-enterprise-app/
├── package.json
├── node_modules/
└── services/
    ├── api-gateway/       (공개 진입점 / Hono.js)
    ├── auth-service/      (인증 & 세션 RPC)
    ├── billing-service/   (Stripe & 결제 RPC)
    ├── email-service/     (Resend / 이메일 발송 RPC)
    └── ai-agent-service/  (Llama 3 / Workers AI RPC)

각 서비스 팀은 자신의 services/xxx 폴더 내에서 독자적으로 개발 및 테스트(npx wrangler deploy)를 진행하고, API Gateway 팀은 필요한 서비스의 Binding만 wrangler.jsonc에 수용하여 안전하게 오케스트레이션한다.

결론: 느린 마이크로서비스의 시대를 끝내다

그동안 마이크로서비스 아키텍처는 “개발 편의성을 얻는 대신 성능과 네트워크 비용을 포기한다”는 타협 위에서 성립되어 왔다.

Cloudflare Workers의 Service Bindings와 WorkerEntrypoint RPC는 이 모순을 완벽히 해결한다.

1. 지연시간 0ms: 네트워크 홉이 사라지고 단일 V8 엔진 메모리 상에서 직접 호출된다.
2. 비용 $0: 마이크로서비스 간 내부 데이터 이동에 대한 Egress 수수료가 없다.
3. 100% 타입 안전성: TypeScript Class 인터페이스를 그대로 사용하여 런타임 타입 오류를 완전 방지한다.
4. 강력한 엣지 보안: 내부 서비스는 공용 인터넷에 노출되지 않는 완전 비공개(Private) 상태를 유지한다.

지금 바로 백엔드 마이크로서비스의 느린 HTTP REST 통신을 Service Bindings RPC로 전환하고, 0ms의 경이로운 응답 속도를 경험해보자.

관련 글: Cloudflare Workers OpenTelemetry: OTLP 분산 트레이싱과 샘플링으로 비용 90% 절감에서 모니터링 파이프라인 구축 가이드도 함께 확인할 수 있다.