스케일링과 배포: 로드 밸런싱, 백엔드 서비스 클러스터, blue/green 및 canary

1. 이 강의의 주제와 왜 중요한가

GiftGenius가 Vercel에서 외롭게 단독으로 돌아가는 상태라고 상상해 보세요. MCP‑gateway 인스턴스 하나(외부로 MCP를 노출하면서 동시에 내부 REST 서비스에 접근), 에이전트용 백엔드 하나, 모든 것이 ‘어떻게든 동작’하는 수준. 이는 pet 프로젝트와 초기 100명 사용자까지는 괜찮습니다.

하지만 OpenAI가 당신의 App을 Store에 추가하고 크리스마스 직전에 메인 큐레이션에 갑자기 노출되면, ‘3000 포트의 게이트웨이 하나’는 매우 슬픈 이야기가 됩니다: 툴 호출 대기열, 타임아웃, 500 오류, Store 평점 하락, 그리고 “왜 매출 피크 시간에 모두 다운됐죠?”라는 마케팅팀의 메일까지.

이 강의의 목표는 GiftGenius(그리고 어떤 ChatGPT App이든)를 로드 밸런서 뒤의 동일한 인스턴스 다수로 구성된 시스템으로 사고하는 법을 익히는 것입니다. 또한 깔끔한 릴리스 전략과 “문제가 생기면 어떻게 빠르게 되돌릴 것인가”를 명확히 정리합니다.

2. 수평 확장과 stateless 디자인

기본 아이디어부터 시작합시다. MCP Gateway나 내부 백엔드 서비스가 특정 프로세스의 메모리에 중요한 상태를 저장한다면, 수평 확장은 사실상 제대로 하기 어렵습니다.

수직 vs 수평 스케일링

먼저 용어를 정리합시다.

수직 스케일링은 한 서버에 “근육을 더 붙이는” 방식입니다: 더 많은 CPU, 더 큰 RAM. 시작은 빠르고 때로는 저렴하지만 한계가 분명하고, 단일 인스턴스를 single point of failure로 만듭니다. 그 “괴물”이 다운되면 모든 것이 함께 다운됩니다.

수평 스케일링은 여러 서비스 인스턴스를 로드 밸런서 뒤에 두는 방식입니다. 각 인스턴스는 비교적 작고, 메모리에 중요한 상태를 보관하지 않습니다. 상태는 외부 스토리지(Postgres, Redis, 오브젝트 스토리지 등)에 둡니다. 부하에 맞춰 인스턴스를 자유롭게 늘리고 줄일 수 있습니다.

MCP Gateway와 백엔드 서비스들(Gift REST API, Commerce REST API, Analytics Service / REST API 등)에는 수평 스케일링이 사실상 필수입니다. ChatGPT가 갑자기 훨씬 더 많은 트래픽을 보낼 수 있고(시즌, Store 프로모션, 바이럴 TikTok 등), 그때는 “한 서버가 버텨주길 기도”하는 것이 아니라 인스턴스를 그저 추가하면 됩니다.

MCP Gateway와 백엔드에서의 stateless 서비스란

수평 스케일링이 동작하려면, 서비스는 가능한 한 stateless해야 합니다.

우리 맥락에서의 Stateless는 다음을 의미합니다:

• 서비스가 사용자별로 비즈니스 로직에 영향을 주는 고유하고 장기적인 상태를 프로세스 메모리에 저장하지 않는다;
• 중요한 상태는 외부 DB, 큐, 캐시, S3 유사 스토리지 등에 저장한다;
• 특정 인스턴스가 죽어도, 다른 인스턴스가 외부 스토리지에서 컨텍스트를 “가져와” 사용자를 계속 처리할 수 있다.

GiftGenius에서는 다음을 뜻합니다:

• 사용자의 선물 추천 히스토리, 좋아요/싫어요, 장바구니는 예를 들어 Postgres에 저장한다;
• 장기 작업 큐(대량 추천 생성, 이메일 추천 발송)는 Redis/Cloud Queue 같은 브로커에 둔다;
• 복잡한 에이전트 워크플로를 위한 별도 서비스가 있다면, 체크포인트와 장기 메모리는 하나의 프로세스 RAM이 아니라 해당 서비스의 스토어에 저장한다.

MCP Gateway나 어떤 백엔드 서비스 인스턴스든 ‘애완동물(pet)이 아니라 가축(cattle)’이 됩니다. 비즈니스 데이터를 잃지 않고도 과감히 종료하고 재생성할 수 있어야 합니다.

미니 예시: 메모리 상태를 외부 스토리지로 옮기기

예전에 아주 단순한 MCP‑tool add_to_cart를 만들었다고 가정해 봅시다. 게이트웨이를 통해 내부 로직을 호출하고, 그 로직이 장바구니를 프로세스 메모리에 저장합니다(데모에서는 가끔 이렇게 합니다 — 단, 프로덕션에서는 안 된다는 점을 이해하고 있을 때만).

// 나쁨: 백엔드 서비스 프로세스 메모리에 장바구니를 저장
const inMemoryCarts = new Map<string, string[]>();

export async function addToCart(userId: string, sku: string) {
  const cart = inMemoryCarts.get(userId) ?? [];
  cart.push(sku);
  inMemoryCarts.set(userId, cart);
  return cart;
}

여기서는 수평 확장이 불가능합니다. 한 요청은 인스턴스 A로, 다른 요청은 인스턴스 B로 가면, 사용자의 장바구니가 서로 달라집니다.

정답은 장바구니를 외부 DB나 캐시로 빼는 것입니다. 가령(크게 단순화하면):

// 좋음: 장바구니를 외부 저장소로 이동
import { db } from "./db";

export async function addToCart(userId: string, sku: string) {
  await db.cartItems.insert({ userId, sku }); // 단순화
  const cart = await db.cartItems.findMany({ where: { userId } });
  return cart;
}

이제 게이트웨이를 통해 들어온 요청을 어떤 백엔드 인스턴스가 처리하든 상관없습니다. 장바구니는 모든 인스턴스에 대해 단일합니다.

3. 로드 밸런싱: 트래픽이 백엔드 클러스터에 도달하는 방식

인스턴스가 둘 이상이 되는 순간, 요청을 그들 사이에 분배할 무언가가 필요합니다. 인기 있는 피자 가게의 주문 분배원과 같습니다. 배달원도 많고 손님도 많은데, 로직이 없으면 혼돈이죠.

L4 vs L7, 그리고 우리가 주로 L7에 관심을 갖는 이유

로드 밸런서는 여러 계층에서 동작할 수 있습니다:

• L4(TCP/UDP)는 실제 프로토콜을 크게 이해하지 못한 채 클라이언트의 바이트를 백엔드 중 하나로 전달합니다;
• L7(HTTP)은 HTTP 요청임을 이해하고, 경로, 헤더, 쿠키, 때로는 바디까지 확인할 수 있습니다.

MCP Gateway와 REST 서비스로 구성된 ChatGPT App 아키텍처에서는 거의 항상 L7 로드 밸런서가 필요합니다. 모두가 HTTP/SSE로 통신하고, 경로/도메인/헤더(예: canary 릴리스)를 기준으로 라우팅하고 health check를 수행하고 싶기 때문입니다.

Health check와 “아픈” 인스턴스를 회전에서 제외하기

로드 밸런서는 주기적으로 인스턴스의 생존 여부를 확인해야 합니다. 가장 간단한 방법은 GET /health 또는 /readyz 엔드포인트를 두고, 이상 없을 때 200 OK를 반환하게 하는 것입니다.

MCP Gateway나 백엔드로 동작하는 Node/TypeScript 서비스에서는 health check를 다음처럼 구현할 수 있습니다:

// apps/gateway/src/http/health.ts
import { type Request, type Response } from "express";

export function healthHandler(req: Request, res: Response) {
  res.json({
    status: "ok",
    version: process.env.RELEASE_ID ?? "dev",
  });
}

로드 밸런서는 /health를 N초마다 호출합니다. 응답이 5xx이거나 타임아웃이 발생하기 시작하면, 해당 인스턴스를 회전에서 제외하고 신규 트래픽을 보내지 않습니다.

Streaming / SSE에 대한 고려 사항

MCP Gateway는 특히 부분 결과를 스트리밍할 때 SSE(Server‑Sent Events)를 자주 사용합니다. 로드 밸런서는 다음을 지원해야 합니다:

• 장시간 지속되는 HTTP 연결;
• 인스턴스 선택 시 이러한 연결 수를 고려(일부 LB는 RPS뿐 아니라 활성 연결 수도 고려)할 수 있어야 합니다.

이는 한 “수다스러운” 툴 호출이 2분간 텍스트를 스트리밍하면서 활성 연결로 유지될 수 있기 때문입니다. 특정 인스턴스에 이런 연결이 너무 많아지면, 그 인스턴스는 일시적으로 “가볍게” 하고 — 새로운 연결은 다른 인스턴스로 보내야 합니다.

4. 백엔드 서비스 클러스터: 모든 것을 한데 모으지 말고 역할별로 분리

다음 논리적 단계는 “하나의 거대한 백엔드 서비스”로 생각하는 것을 멈추고, 부하 특성과 중요도에 따라 여러 클러스터로 시스템을 나누는 것입니다.

GiftGenius의 클러스터 기반 아키텍처 예시

모듈 16에서 모은 내용으로 GiftGenius에는 다음과 같은 구성을 추천합니다:

본질적으로 이는 bulkheads(격벽) 패턴의 구현입니다. 클러스터 B가 복잡한 텍스트를 생성하느라 갑자기 “토큰으로 CPU를 태워도” 결제 클러스터 C는 자체 리소스와 스케일링을 갖고 있으므로 계속 정상 동작합니다.

Gateway 관점에서 보면

모듈 첫 강의에서 설명한 MCP Gateway는 들어오는 MCP 트래픽을 보고 이를 백엔드 클러스터로 라우팅합니다. 대략 다음과 같습니다:

• 툴 호출 list_gifts, suggest_gifts → 클러스터 A(Gift REST API);
• 툴 호출 generate_greeting_card 또는 복잡한 agent 워크플로 → 클러스터 B(Agents REST 서비스 또는 워커);
• create_order, confirm_payment 같은 도구 → 클러스터 C(Commerce REST API).

그 뒤에는 하나의 공용 로드 밸런서가 있을 수도, 여러 개의 로드 밸런서가 있을 수도 있습니다(예: commerce 앞에 별도의 L7‑LB를 둬서 더 강하게 격리).

전체 그림은 대략 다음과 같습니다:

flowchart LR
    ChatGPT((ChatGPT))
    GW[MCP Gateway]
    LBA[LB Gift API Cluster A]
    LBB[LB Agents/Workers Cluster B]
    LBC[LB Commerce API Cluster C]

    A1[Gift REST API A-1]
    A2[Gift REST API A-2]
    B1[Agents Service B-1]
    B2[Agents Service B-2]
    C1[Commerce REST API C-1]
    C2[Commerce REST API C-2]

    ChatGPT --> GW
    GW -->|tools: gifts| LBA
    GW -->|agents workflows| LBB
    GW -->|commerce| LBC

    LBA --> A1
    LBA --> A2
    LBB --> B1
    LBB --> B2
    LBC --> C1
    LBC --> C2

도식은 약간 이상적이지만 핵심 원칙을 드러냅니다. 서로 다른 부하 유형은 하나의 MCP Gateway 뒤에서 별도의 백엔드 클러스터로 분리합니다.

5. 배포 전략: 왜 blue/green과 canary가 필요한가

이제 사용자들이 눈치채지 못하는 방식으로, 그리고 당신이 밤에 편히 잘 수 있도록 어떻게 업데이트할지를 살펴봅시다.

안티 패턴: 프로덕션 위에 덮어쓰기 배포

가장 간단하지만 가장 위험한 전략입니다. 현재 클러스터(예: Gift REST API A 클러스터)에 새 이미지를 기존 위에 올리거나, 컨테이너를 교체하거나 프로세스를 재시작합니다.

문제점:

• 일부 인스턴스는 새 버전, 일부는 옛 버전인 동안 시스템이 예측 불가능하게 동작할 수 있습니다(특히 DB 스키마가 바뀐 경우);
• 문제가 생기면 롤백은 “이전 상태로 다시 배포”하는 것으로, 몇 분이 걸릴 수 있습니다;
• 배포 순간에는 어떤 인스턴스도 아직 올라오지 않아 짧은 다운타임이 생길 수 있습니다.

Kubernetes나 PaaS에서는 롤링 업데이트가 어느 정도 이를 완화하지만, 본질은 같습니다. 명확한 전략이 없으면 서로 다른 버전의 코드가 동시에 트래픽을 처리하는 “회색 지대”가 커집니다.

Blue/Green 배포: 두 환경과 즉시 전환

Blue/Green은 Blue(현재 프로덕션)와 Green(새 버전) 두 개의 거의 동일한 환경을 동시에 유지하는 방식입니다.

절차는 대략 다음과 같습니다:

1. Green 환경에 새 버전(v2)을 배포합니다. 실제 트래픽만 없는 동일한 gateway + 백엔드 클러스터 묶음입니다.
2. Green에서 필요한 테스트를 모두 수행합니다: 자동화 테스트, 스모크 시나리오, ChatGPT Dev Mode로 수동 점검.
3. 릴리스 시점에 로드 밸런서/라우팅을 전환해 100% 실 트래픽이 Green으로 가도록 합니다.
4. Blue는 “비상 활주로”로 옆에서 계속 살아 있습니다. 문제가 생기면 몇 초 안에 트래픽을 다시 Blue로 돌립니다.

GiftGenius의 경우 mcp-gateway-blue.example.com과 mcp-gateway-green.example.com이 있을 수 있습니다. 프로덕션의 ChatGPT App은 공식 MCP 엔드포인트(gateway)를 바라보고, 릴리스 시에는 mcp-gateway.example.com 도메인이 green을 가리키도록 DNS/LB 구성을 변경합니다.

장점:

• 즉시 전환 가능;
• 문제는 롤백 후에 차분히 진단 및 수정 가능;
• “클러스터 절반은 새 버전, 절반은 옛 버전” 상태가 없음.

단점:

릴리스 동안 두 개의 완전한 환경을 유지해야 하므로 리소스 비용이 2배가 됩니다. 따라서 이 전략은 보통 가장 중요한 백엔드 서비스에 적용합니다 — 예를 들어 결제 클러스터 C와 MCP Gateway 자체(결제와 진입점은 어떤 상황에서도 깨지면 안 됨).

Canary 릴리스: 탄광 속 “카나리아”

Canary 릴리스는 더 경제적인 방식입니다. 두 개의 완전한 프로덕션을 띄우지 않고, 새 버전을 전체 트래픽의 작은 비율에 점진적으로 배포하고 면밀히 관찰합니다.

예시 시나리오:

1. Gift REST API A 클러스터의 v2를 동일한 풀에 배포하거나, 작은 카나리아 전용 풀에 배포합니다.
2. 로드 밸런서 또는 MCP Gateway를 설정해 선물 관련 툴 호출의 1%만 v2로, 99%는 v1으로 가도록 합니다.
3. 메트릭을 확인합니다: 오류율, 레이턴시, 비즈니스 메트릭(전환율, 성공한 checkout 비율 등).
4. 괜찮다면 점진적으로 비율을 올립니다: 1% → 5% → 10% → 50% → 100%. 문제가 있으면 즉시 롤백합니다.

ChatGPT Apps의 맥락에서는 코드만이 아니라 프롬프트 실험에도 canary가 유용합니다. 에이전트 서비스의 새로운 system 프롬프트는 동작을 급격히 바꿀 수 있으므로, 먼저 소수의 사용자에게서 검증하는 편이 좋습니다.

Gateway나 LB는 다음과 같은 기준으로 어떤 요청을 “카나리아”로 볼지 결정할 수 있습니다:

• 무작위(예: 전체 요청의 1%);
• userId 기준(일부 사용자는 실험군으로 고정);
• 특수 헤더나 쿠키(내부 테스트용).

게이트웨이의 라우팅 아이디어를 보여주는 간단한 TypeScript 유사 코드 예시:

// 게이트웨이의 의사 코드: 단순 랜덤 canary 5%
function routeToGiftBackendCluster(ctx: { userId?: string | null }) {
  const rnd = Math.random();
  if (rnd < 0.05) {
    return "gift-api-v2"; // canary
  }
  return "gift-api-v1";   // stable
}

실제 환경에서는 물론 runtime 코드의 Math.random()에 의존하지 않고 규칙을 설정/피처 플래그로 분리하지만, 개념은 유사합니다. 트래픽의 일부는 canary 버전 백엔드로, 나머지는 안정(stable) 버전으로 보냅니다.

6. 전략의 필수 요소로서의 Rollback

오래전에 배운 좋은 규칙이 있습니다: 롤백은 수정보다 빨라야 한다.

즉, 릴리스 후 오류가 쏟아지고 사용자들이 “다 망가졌어요”라고 한다면, 프로덕션에서 버그를 영웅적으로 고치려 하지 마세요. “되돌리기”라는 큰 빨간 버튼을 누르세요.

Vercel(우리가 이미 GiftGenius의 Next.js 부분을 배포했던 플랫폼) 같은 곳에서는 매우 자연스럽습니다. 각 배포는 immutable 아티팩트이고, Vercel은 이전 배포로 빠르게 돌아갈 수 있게 해 줍니다.

Kubernetes나 다른 오케스트레이터에 배포된 MCP Gateway와 백엔드 클러스터에서는 kubectl rollout undo가 그 역할을 합니다. 이전 pod/이미지 세트로 되돌립니다.

핵심은 현재 트래픽을 처리하는 버전을 로깅하고 노출하는 것입니다. 예를 들어:

• version을 /health 및 기타 진단 엔드포인트에 추가합니다(위에서 이미 해 봄);
• 릴리스 식별자를 로그에 헤더로 전달합니다(예: X-Release-Id).

미니 예시: ChatGPT App 위젯 내부에서 확인할 수 있도록 빌드 버전을 반환하는 Next.js API route:

// apps/web/app/api/version/route.ts
export async function GET() {
  return Response.json({
    version: process.env.RELEASE_ID ?? "dev",
    builtAt: process.env.BUILT_AT ?? "unknown",
  });
}

이런 엔드포인트는 디버깅에도 유용합니다. 프로덕션 인스턴스에 “지금 어떤 버전이 돌고 있는지”를 직접 물어볼 수 있어, “정말 최신 빌드가 배포됐나?” 하고 추측할 필요가 없습니다.

7. Capacity planning: GiftGenius에는 인스턴스가 얼마나 필요할까

이미 안전한 릴리스(blue/green, canary)와 빠른 롤백에 대해 이야기했습니다. 남은 실용적 질문: 실제 트래픽을 견디면서도 비용을 과도하게 쓰지 않으려면 프로덕션에 어떤 클러스터를 몇 개 운영해야 할까요?

공식에 집착할 필요는 없지만, 어느 정도는 필요합니다. 스케일링은 부하와 경제성을 연계해야 합니다: 하루/초당 요청 수, 무거운 LLM 호출 비중, 그리고 비용.

간단히 ‘자릿수’ 관점으로 생각해도 좋습니다:

• 하루 10k 요청(GiftGenius 기준, 평균 0.1 RPS 수준)이라면 MCP Gateway 1–2개, Gift REST API/Agents 워커 2개 정도로도 충분합니다;
• 하루 100k 요청(평균 1–2 RPS, 피크는 더 큼)이라면 gateway와 Gift REST API 클러스터에 3–5 인스턴스, 무거운 에이전트용 B 클러스터, 그리고 별도 commerce 클러스터를 두는 편이 좋습니다;
• 하루 1M 요청(두 자릿수 RPS, 명절 피크)은 클러스터 구성이 확실히 필요하고, LLM 에이전트 전용 리소스, 적극적인 캐시, 엣지 레이어(이는 별도 강의 주제)가 필요합니다.

이는 엄밀한 수치가 아니라, 부하의 규모를 가늠하고 미리 생각하게 만드는 장치입니다. 병목이 어디인지, 어떻게 확장할 것인지, 비용이 얼마나 들지 고민하게 합니다.

GiftGenius는 특히 명절 대비가 중요합니다: 새해, 크리스마스, 발렌타인데이, 블랙 프라이데이. 부하는 몇 배로 치솟을 수 있고, 시스템이 이를 견뎌야 합니다.

8. 실전 미니 예시: GiftGenius 배포의 진화

지금까지의 내용을 하나로 묶어 간단한 GiftGenius 배포의 진화를 그려 봅시다.
여기서는 앞서 이야기한 모든 요소를 순차적으로 적용합니다: gateway와 백엔드 서비스의 stateless 디자인, 로드 밸런싱, 분리된 클러스터, 릴리스 전략(blue/green, canary).

기본 단계: Vercel/Kubernetes에 gateway + 백엔드 하나

강의의 어느 시점에 이미 이렇게 했을 겁니다. Apps SDK를 포함한 Next.js 앱 하나를 Vercel에 올려, 그 안에 MCP 엔드포인트와 간단한 백엔드 로직(Gift/Commerce)이 함께 존재하는 형태. 제법 모놀리식입니다.

장점은 명확합니다. 단순하고 저렴하며, 실수할 지점이 적습니다.

단점은 단 하나지만 치명적입니다. 진지한 트래픽에는 전혀 스케일되지 않고, 업데이트에도 취약합니다.

2단계: 독립 MCP Gateway + 여러 백엔드 클러스터

다음 단계:

• MCP Gateway를 별도 서비스로 분리합니다(Node/Go/NGINX+Lua 등 구현은 중요하지 않음);
• Gift REST API 인스턴스를 여러 개 띄워 클러스터 A를 구성하고, 에이전트용 워커/서비스 여러 개로 클러스터 B를 구성합니다;
• commerce는 별도 서비스(클러스터 C)로 분리하고, 필요하다면 DB/인프라도 분리합니다.

여기서부터 전형적인 L7 로드 밸런싱, health check, 가능하다면 수평 확장이 작동합니다.

3단계: 릴리스 전략

이 단계에서 다음을 추가합니다:

• commerce 클러스터 C(필요하다면 MCP Gateway도 포함)에 Blue/Green을 적용해 checkout과 인증이 최대한 안정적이도록 합니다;
• Gift REST API와 에이전트 서비스 클러스터에는 Canary 릴리스를 적용해, 새로운 툴/에이전트 버전을 전체 프로덕션을 위험에 빠뜨리지 않고 실험할 수 있게 합니다.

도식적으로:

flowchart LR
    ChatGPT((ChatGPT))
    GWBlue[Gateway Blue]
    GWGreen[Gateway Green]
    LB[Traffic Switch]

    subgraph Prod
      LB --> GWBlue
      LB -.canary,% .-> GWGreen
    end

    ChatGPT --> LB

실제 환경은 조금 더 복잡할 수 있습니다(예: commerce에만 Blue/Green, gift 클러스터에만 canary). 그래도 핵심 아이디어는 같습니다. ChatGPT 입장에서는 여전히 단일 MCP 진입점(gateway)처럼 보이지만, 당신은 어떤 버전이 어디로 흘러가는지 항상 명확히 알 수 있습니다.

9. 버전 관리와 진단을 위한 작은 코드 조각들

이미 health 엔드포인트와 /api/version을 봤습니다. 여기에, 게이트웨이 측 MCP 툴 핸들러에서 버전과 클러스터를 로깅해 나중에 메트릭을 쉽게 “대조”하는 방법 예시를 추가해 봅니다.

툴 suggest_gifts가 Gift REST API의 REST 엔드포인트로 구현되어 있고, 게이트웨이를 통해 호출된다고 가정해 봅시다:

import { type McpToolHandler } from "@modelcontextprotocol/sdk";

export const suggestGifts: McpToolHandler<{
  occasion: string;
  budget: number;
}> = async ({ input, meta }) => {
  const releaseId = process.env.RELEASE_ID ?? "dev";
  const clusterId = process.env.CLUSTER_ID ?? "gift-api-A";

  console.log("[suggest_gifts]", {
    releaseId,
    clusterId,
    userId: meta.userId,
    occasion: input.occasion,
  });

  // 여기서 MCP Gateway는 라우팅 테이블에 따라 Gift REST API를 호출하고,
  // 툴 자체는 REST 호출 위에 얇은 래퍼로 남습니다
  return {
    content: [{ type: "text", text: "Gift ideas..." }],
  };
};

여기서 우리는:

• RELEASE_ID와 CLUSTER_ID를 환경변수에서 읽고;
• 이를 구조화된 로그에 기록하며;
• “어떤 버전/클러스터에서 오류가 더 많이 나는가?” 같은 분석에 쉽게 활용합니다.

ChatGPT App 관점에서는 완전히 투명하지만, 개발자인 당신에게는 canary/blue‑green과 결합될 때 큰 장점입니다.

10. ChatGPT App 스케일링과 배포에서의 전형적 실수

오류 №1: 세션/사용자 상태를 게이트웨이나 백엔드 프로세스 메모리에 보관.
이 방식은 수평 스케일링을 망칩니다. 두 번째 인스턴스가 생기는 순간 상태가 인스턴스 간에 “갈라”집니다. 특히 장바구니, 검색 결과, 워크플로 진행률을 메모리에 두는 것은 위험합니다. 이런 것들은 모두 외부 스토리지 — DB, 캐시, 에이전트 상태 전용 스토어 — 에 있어야 합니다.

오류 №2: “강력한 서버 하나면 충분”하다고 생각.
수직 스케일링은 시작하기 편하지만, 실제 성장에는 취약합니다. 머신의 물리적 한계가 있고, 단일 프로세스가 single point of failure가 됩니다. ChatGPT는 예측 불가능한 트래픽 급증을 가져올 수 있습니다. MCP Gateway와 백엔드 클러스터에는 거의 항상 stateless 디자인과 여러 인스턴스(+ 로드 밸런서)가 필요합니다.

오류 №3: 명확한 전략 없이 프로덕션 위에 새 버전을 덮어 배포.
운영 클러스터에서 그냥 컨테이너/프로세스를 업데이트하면, 일부 트래픽은 옛 버전으로, 일부는 새 버전으로 가는 중간 상태가 생기고, 오류가 나면 롤백이 “다시 배포”가 됩니다. 훨씬 안전한 방법은 두 환경(blue/green)을 유지하거나 적어도 canary 전용 백엔드 버전을 두어 소량의 트래픽만 보내는 것입니다.

오류 №4: 빠른 롤백 플랜의 부재.
나쁜 시나리오: 릴리스 후 메트릭이 붉어지고 사용자가 불만을 쏟아내는데, 그제야 롤백 방법을 고민하기 시작합니다. 올바른 시나리오: 즉시 롤백할 준비(blue/green 스위치, rollout undo, Vercel 롤백), 로그/health 엔드포인트에 명확한 버전 식별자, 그리고 “먼저 롤백, 이후 분석”이라는 강력한 원칙입니다.

오류 №5: 부하 유형별 분리 없이 “모두 통합” 단일 클러스터.
축하 메시지 생성(LLM 에이전트)과 checkout이 한 클러스터에 있으면, 모델 측 문제(지연, 타임아웃, 토큰 증가)가 결제까지 망칠 수 있습니다. 작업 유형별(가벼운 Gift REST API, 무거운 Agents 서비스, Commerce REST API) 클러스터 분리와 클러스터마다 별도의 한도/리소스를 두는 것이 안정성의 중요한 단계입니다.

오류 №6: 아키텍처와 비용의 연계 부재.
“노드를 몇 개 더 올리자”는 발상에 휩쓸리기 쉬운데, 각 LLM 호출과 인스턴스가 비용이라는 점을 잊기 쉽습니다. 최소한의 capacity planning(부하/비용 추정) 없이 가면, 과소 확장으로 프로덕션을 다운시키거나 과도 확장으로 마진을 잃을 수 있습니다. 하루 요청 수, 무거운 LLM 작업 비율, 호스팅 비용을 앱의 비즈니스 메트릭과 연계하는 습관이 유용합니다.