캐시와 엣지 레이어: CDN, 엣지 캐시, ETag, SWR, 엣지 함수(Vercel) 및 그 한계

1. 왜 ChatGPT App에서 캐시와 엣지를 고민해야 하나

고전적인 웹 애플리케이션에서도 속도는 중요하지만, 그나마 사용자는 스피너라도 볼 수 있습니다. ChatGPT App에서는 상황이 더 흥미롭습니다. 사용자는 모델과 대화하고, 때로 모델이 여러분의 App을 호출하기로 결정합니다. 위젯은 떠오르고 꽤 빠르게 유용한 무언가를 보여줘야 합니다.

실무는 매우 명확합니다: latency = 비용. 응답이 길어질수록 사용자가 이탈할 확률이 커지고, 불필요한 LLM/백엔드 호출은 모델과 인프라 비용으로 직결됩니다. 캐싱은 이 둘을 모두 줄여 줍니다.

게다가 ChatGPT Apps의 특성:

• ChatGPT에서 여러분의 App으로 가는 요청은 네트워크와 여러 레이어를 거칩니다. 각 단계의 몇 밀리초가 누적됩니다.
• MCP/HTTP 엔드포인트에는 실제 타임아웃이 있습니다(Vercel serverless 함수와 엣지 함수도 마찬가지). 제때 응답하지 못하면 ChatGPT는 오류를 보고하고, 심지어 “환각(hallucination)” 응답을 만들어낼 수도 있습니다.
• GiftGenius의 많은 데이터는 매초 바뀌지 않습니다. 선물 카탈로그 구조, 다양한 세그먼트를 위한 “탑 아이디어” 모음, 기능 플래그 등. 매번 DB나 외부 API를 두드리는 것은 비효율적입니다.

여기서 필요한 것이 바로 다음과 같습니다:

• CDN과 엣지 캐시를 통해 정적 리소스와 캐시 가능한 JSON을 빠르게 제공.
• HTTP 캐시로 Cache-Control/ETag/SWR를 활용해 반복 요청을 더 빠르고 저렴하게.
• Vercel 엣지 함수를 사용해 ChatGPT와 사용자에 최대한 가까운 곳에서 가벼운 로직을 수행하되, 이를 “미니 백엔드”로 오해하지 않기.

2. GiftGenius의 지연 시간 해부와 캐싱 지점

먼저 지연 시간이 어디서 생기는지 솔직하게 그려보는 것이 유익합니다.

sequenceDiagram
    participant User as 사용자
    participant ChatGPT as ChatGPT
    participant App as ChatGPT App (Apps SDK)
    participant GW as MCP Gateway / Edge
    participant GiftAPI as Gift REST API / 선물 마이크로서비스
    participant DB as 카탈로그/DB

    User->>ChatGPT: "형제에게 줄 선물을 골라줘"
    ChatGPT->>App: 툴 호출 + 위젯 렌더링
    App->>GW: HTTP / MCP 요청(카테고리, 추천 목록)
    GW->>GiftAPI: HTTP (REST)
    GiftAPI->>DB: 카탈로그/추천 질의
    DB-->>GiftAPI: 응답
    GiftAPI-->>GW: 응답 (JSON)
    GW-->>App: 응답 (JSON)
    App-->>ChatGPT: 결과가 담긴 위젯
    ChatGPT-->>User: 메시지 + UI

어디서 지연을 줄일 수 있을까요?

1. ChatGPT와 여러분의 경계(퍼리미터) 사이 — CDN/엣지 캐시(Vercel CDN/Edge Network). 변경되지 않는 위젯 에셋과 캐시 가능한 JSON을 origin 서버까지 가지 않고도 제공할 수 있습니다.
2. Gateway와 내부 REST/HTTP 서비스(Gift REST API, Commerce REST API 등) 및 DB 사이 — 애플리케이션 캐시(Redis/메모리/DB 캐시)로 동일한 요청(예: “선물 카테고리 목록”)을 여러 번 반복하지 않도록 합니다.

이 강의에서는 ChatGPT와 Vercel에 더 가까운 HTTP/엣지 레이어에 집중합니다.

3. 우리 아키텍처의 캐시 종류

아키텍처가 ‘레이어 케이크’처럼 여러 층으로 되어 있다면, 캐시도 여러 층이 있습니다.

지금은 앞의 두 가지, 즉 HTTP 캐시 + CDN/엣지에 집중하겠습니다.

4. HTTP 캐시: Cache-Control, max-age 및 s-maxage

HTTP 캐시는 우선적으로 Cache-Control 헤더로 제어합니다. 이를 통해 브라우저/ChatGPT 클라이언트 및/또는 CDN이 응답을 캐시할 수 있는지, 그리고 얼마나 오래 캐시할지를 결정합니다.

핵심 포인트:

• max-age — 브라우저가 응답을 캐시할 수 있는 시간(초).
• s-maxage — 공유 캐시(CDN/프록시)가 응답을 캐시할 수 있는 시간(초).
• public — 공유 캐시에서 캐시 가능.
• private — 특정 클라이언트 전용; CDN은 캐시하지 않음.

예를 들어 GiftGenius에서는:

• 위젯의 JS/CSS/폰트 — 버전이 붙은 파일(파일명에 해시 포함)은 다음과 같이 안전하게 제공할 수 있습니다: Cache-Control: max-age=31536000, immutable.
• 선물 카테고리 목록 JSON — 모든 사용자에게 동일하므로, public, s-maxage=60(또는 더 길게)이 합리적입니다.

GET /api/gifts/categories에 대한 가장 간단한 Next.js Route Handler 예시로, CDN에서 60초 동안 캐시합니다:

// app/api/gifts/categories/route.ts
import { NextResponse } from "next/server";

export const runtime = "nodejs"; // 일반적인 serverless 함수

export async function GET() {
  // 여기에서 DB/외부 API를 호출할 수 있습니다
  const categories = [
    { id: "for_brother", title: "형제에게 줄 선물" },
    { id: "for_mom", title: "엄마를 위한 선물" },
  ];

  return NextResponse.json(categories, {
    headers: {
      // CDN에서 60초 캐시하도록 허용
      "Cache-Control": "public, s-maxage=60",
    },
  });
}

Vercel CDN은 응답을 60초 동안 저장하며, 이 창구 안의 모든 ChatGPT 요청은 여러분의 함수까지 도달하지 않습니다. 즉각적이고 저렴합니다.

5. ETag: 콘텐츠 지문과 304 Not Modified

ETag는 리소스의 조건부 “지문”으로, 보통 콘텐츠의 해시입니다. 동작 방식은 다음과 같습니다.

1. 서버가 ETag: "v1-abc123" 헤더와 함께 응답을 반환합니다.
2. 다음 요청에서 클라이언트는 If-None-Match: "v1-abc123" 헤더를 전송합니다.
3. 서버가 콘텐츠가 변경되지 않았다고 판단하면 본문 없이 304 Not Modified로 응답합니다.

중요: ETag는 트래픽을 절약하지만, 왕복 네트워크 지연이 여전히 필요하므로 지연 시간을 반드시 줄여주지는 않습니다. ChatGPT Apps에서는 무거운 JSON 응답에 유용하지만, ETag 하나로 기적 같은 속도를 기대하기보다는 SWR과 엣지 캐시가 핵심입니다.

간단한 Next.js ETag 예시(복잡한 해시 없이 개념만 설명):

// app/api/gifts/config/route.ts
import { NextRequest, NextResponse } from "next/server";

const CONFIG = { version: 1, showExperimentalIdeas: true };
const ETAG = `"v${CONFIG.version}"`;

export async function GET(req: NextRequest) {
  const ifNoneMatch = req.headers.get("if-none-match");
  if (ifNoneMatch === ETAG) {
    // 콘텐츠가 변경되지 않음 — 304 반환
    return new NextResponse(null, { status: 304, headers: { ETag: ETAG } });
  }

  return NextResponse.json(CONFIG, {
    headers: {
      ETag: ETAG,
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

실제 서비스에서는 데이터 해시로 ETag를 계산하거나 DB의 레코드 버전을 사용할 것입니다.

6. Stale‑While‑Revalidate (SWR): 빠르고 충분히 신선하게

SWR은 “오래된 것을 즉시 보여주고, 새 것을 백그라운드에서 가져오자”는 접근입니다. 이를 구현하는 방법은:

• Cache-Control 헤더의 stale-while-revalidate 파라미터로 HTTP 수준에서.
• swr/react-query 같은 라이브러리를 사용해 UI 수준에서 로컬 캐시와 백그라운드 refetch를.

HTTP 헤더에서의 SWR

전형적인 헤더:

Cache-Control: public, s-maxage=60, stale-while-revalidate=300

의미:

• 처음 60초 동안 CDN은 최신 버전을 제공합니다.
• 61초부터 360초까지 CDN은 오래된 응답을 즉시 제공하고, 백그라운드에서 origin에 새 버전을 요청할 수 있습니다.
• 360초 이후에는 새 콘텐츠 요청이 블로킹됩니다.

사용자(및 ChatGPT)는 트래픽 피크에서도 즉시 응답을 받고, 여러분은 백그라운드에서 부드럽게 캐시를 갱신합니다. GiftGenius에서는 “연말 선물 탑 추천”처럼 매초 바뀌지 않는 데이터에 이상적입니다.

예시:

// app/api/gifts/top/route.ts
import { NextResponse } from "next/server";

export async function GET() {
  const topGifts = [
    { id: "coffee_mug", title: "문구가 있는 머그컵" },
    { id: "smart_led", title: "스마트 램프" },
  ];

  return NextResponse.json(topGifts, {
    headers: {
      "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
    },
  });
}

UI 위젯(React)에서의 SWR

GiftGenius 위젯은 ChatGPT 샌드박스에서 동작하며 어떤 React 코드든 사용할 수 있습니다. 이미 window.fetch로 API를 호출할 수 있습니다. 여기에 swr 라이브러리를 추가해 위젯 쪽 캐시를 구성해 보겠습니다:

// widget/GiftTopList.tsx
import useSWR from "swr";

const fetcher = (url: string) => fetch(url).then((r) => r.json());

export function GiftTopList() {
  const { data, isLoading } = useSWR(
    "https://api.giftgenius.com/api/gifts/top",
    fetcher,
    { revalidateOnFocus: false } // 채팅에서는 포커스가 자주 바뀌므로 끄자
  );

  if (isLoading && !data) return <div>아이디어를 불러오는 중...</div>;

  return (
    <ul>
      {data?.map((gift: any) => (
        <li key={gift.id}>{gift.title}</li>
      ))}
    </ul>
  );
}

동작 방식:

• 첫 렌더에서 우리 API로 요청을 보냅니다.
• 결과는 위젯 내부의 swr 캐시에 저장됩니다.
• 이후 렌더(또는 ChatGPT가 동일한 키로 이 위젯을 다시 삽입하는 새로운 응답)에서는 데이터가 캐시에서 제공됩니다. 사용자는 깜빡임/스피너를 보지 않고, 백그라운드에서 갱신이 일어날 수 있습니다.

이렇게 두 가지 SWR 레벨을 결합합니다:

• CDN/HTTP 수준 — origin 부하를 줄이기 위해.
• UI 수준 — 사용자의 체감을 부드럽게 하기 위해.

모두 합치면:

• 기본 Cache-Control(max-age/s-maxage) — 기본 레이어: CDN과 클라이언트가 응답을 캐시해 부하를 낮춥니다.
• ETag + If-None-Match — 대형 JSON에서 트래픽 절감이 중요할 때 추가하되, 네트워크 왕복은 감수합니다.
• stale-while-revalidate — 약간 오래된 데이터라도 즉시 제공하는 것이 중요한 경우(카탈로그, 탑 추천)에 활성화합니다.
• UI의 SWR(swr/react-query) — ChatGPT 샌드박스에서 위젯의 리렌더링을 완화하고 로컬 캐시를 유지하는 별도의 레이어입니다.

7. GiftGenius에서 무엇을 얼마나 오래 캐시할까

GiftGenius 데이터를 “캐시 가능성 레이어”로 나눠보겠습니다.

CDN/엣지 수준에서 캐시 가능

모든(또는 넓은 세그먼트의) 사용자에게 동일하고 자주 바뀌지 않는 것:

• 위젯 정적 리소스: JS/CSS, 폰트, 아이콘 — immutable로 “사실상 영구”(1년).
• 선물 카탈로그 구조: 카테고리, 섹션, 필터 — 수분/수시간.
• 공용 추천(“동료를 위한 최고의 아이디어, $50 이하”) — 수분/수십 분, 특히 성수기에는 더욱.

여기에는 public, s-maxage + stale-while-revalidate 조합이 이상적입니다.

애플리케이션/Redis에서 캐시하는 편이 더 좋음

좀 더 동적인 데이터지만 반복적으로 요청되는 것:

• 무거운 외부 API 결과(예: 환율, 외부 상점의 최신 가격).
• 자주 요청되는 추천 세그먼트(성별/연령/이벤트 기준).

여기서는 데이터가 토큰/조직/테넌트에 따라 달라질 수 있으므로 CDN이 항상 적합하지 않습니다. MCP Gateway나 내부 REST 서비스 수준에서 캐시하세요. 이는 전적으로 여러분 통제 하에 있고 사용자 간 데이터 혼합을 방지합니다.

(공유 캐시에서는) 캐시하면 안 됨

특정 사용자에 귀속되는 것:

• 개인 주문 및 주문 상태.
• 결제 정보, 주소, 이메일.
• 개인 주문 이력 기반의 구체적 추천(민감한 경우).

이는 애플리케이션 수준에서 신중한 의미 체계를 갖고 캐시할 수는 있지만(사용자 간 누수가 없도록), public CDN 캐시에는 절대 두지 마십시오.

8. 엣지 레이어: CDN과 엣지 함수의 차이

비슷해 보이지만 다른 두 가지를 혼동하지 마세요:

• CDN / 엣지 캐시 — 미리 계산된 응답을 저장하며, 로직은 거의 없습니다.
• 엣지 함수(Vercel Edge / Cloudflare Workers) — 엣지 노드에서 실행되는 작은 코드 조각입니다.

경험상 Edge ≠ Serverless입니다. 많은 개발자가 여기에 무거운 비즈니스 로직, LLM 호출, BLOB 처리까지 넣었다가 타임아웃과 각종 제한에 당황합니다. 엣지 함수는:

• 아주 빠르게 시작합니다(콜드 스타트 거의 없음).
• 하지만 CPU, 실행 시간, 사용 가능한 API에 심한 제약이 있습니다(완전한 Node.js 환경, 장시간 소켓 등은 종종 불가).

엣지 함수가 좋은 아이디어인 경우

GiftGenius와 ChatGPT App 컨텍스트에서 엣지 함수는 다음에 유용합니다:

• 가벼운 라우팅: locale, x-openai-user-location 또는 tenant ID 헤더로 어떤 리전 백엔드 클러스터로 보낼지 결정.
• 간단한 헤더 추가, 기능 플래그, A/B 라우팅.
• 엣지 KV 또는 CDN 캐시에서 읽어 오는 초경량 read-only 엔드포인트(계산 거의 없음).

엣지 함수가 나쁜 아이디어인 경우

• 긴 외부 API 요청.
• LLM 모델 호출.
• 복잡한 체크아웃 로직.
• 무거운 비즈니스 로직을 갖는 MCP 도구.

이 모든 것은 일반적인 Next.js serverless 함수(예: runtime = "nodejs")나 별도의 서비스/클러스터에서 처리하세요.

Next.js 16에서의 엣지 함수 예시

GET /api/geo-router 라우트를 작게 만들어, x-openai-user-location 헤더(가정)에 따라 어떤 리전 클러스터를 사용할지 반환해 봅시다.

// app/api/geo-router/route.ts
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge"; // 엣지에서 실행

export function GET(req: NextRequest) {
  const userLocation = req.headers.get("x-openai-user-location") ?? "US";
  const cluster =
    userLocation.startsWith("EU") ? "eu-gift-api" : "us-gift-api";

  return NextResponse.json({ cluster }, {
    headers: {
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

이런 엔드포인트는:

• 매우 빠르게 동작합니다(엣지).
• 복잡한 일을 하지 않습니다.
• CDN에서 캐시될 수 있습니다.

9. GiftGenius의 전체 아키텍처에서의 엣지와 캐시

모두 하나의 그림으로 정리해 봅시다.

flowchart TD
    ChatGPT[(ChatGPT / User)]
    CDN["CDN / Edge Cache (Vercel)"]
    EdgeFn["Edge Functions (라우팅, 기능 플래그)"]
    GW[MCP Gateway]
    GiftAPI["Gift REST API Cluster"]
    CommerceAPI["Commerce REST API Cluster"]
    DB[(DB/External APIs)]
    
    ChatGPT --> CDN
    CDN -->|캐시 히트| ChatGPT
    CDN -->|캐시 미스| EdgeFn
    EdgeFn --> GW
    GW --> GiftAPI
    GW --> CommerceAPI
    GiftAPI --> DB
    CommerceAPI --> DB

전형적 시나리오:

1. ChatGPT 위젯이 /api/gifts/categories를 요청합니다.
2. CDN이 캐시를 확인합니다. 신선하거나 “stale지만 아직 유효한” 버전이 있으면 EdgeFn/GW를 건드리지 않고 즉시 제공합니다.
3. 캐시가 없으면 요청은 EdgeFn(활성화된 경우) 또는 바로 GW로 전달됩니다.
4. GW는 필요 시 내부 Redis 캐시를 사용해 무거운 작업을 줄이거나, 내부 REST 서비스 및 DB로 요청을 전달합니다.
5. 응답은 다시 돌아오면서 CDN/엣지 캐시에 저장되고, 다른 사용자에게 제공됩니다.

이 구조는 다음을 보장합니다:

• 위젯과 ChatGPT의 지연 시간을 줄입니다.
• MCP Gateway와 백엔드 클러스터의 부하를 낮춥니다.
• LLM/DB 호출 비용을 줄입니다(중복 요청 감소).

10. GiftGenius를 위한 작은 실전 코드 조각

카테고리 캐시 + Next.js revalidate

지금까지는 API 엔드포인트만 이야기했습니다. 하지만 Next.js는 ISR(revalidate)를 통해 페이지 자체에도 유사한 메커니즘을 제공합니다.

revalidate = 60으로 카테고리 목록을 가져오는 server component 예시:

// app/(widget)/categories/page.tsx
export const revalidate = 60; // ISR: 60초마다 재생성

async function fetchCategories() {
  const res = await fetch("https://api.giftgenius.com/api/gifts/categories");
  return res.json();
}

export default async function CategoriesPage() {
  const categories = await fetchCategories();
  return (
    <ul>
      {categories.map((c: any) => (
        <li key={c.id}>{c.title}</li>
      ))}
    </ul>
  );
}

프로덕션에서는 Vercel이 이 페이지의 HTML 출력을 생성/캐시합니다. 이는 위젯/인터페이스가 ChatGPT 외에도 일반 웹 페이지(예: 디버그 패널이나 랜딩)로 열리는 경우에 유용합니다.

백엔드 서비스의 간단한 애플리케이션 캐시

이건 엣지 레이어가 아니라 애플리케이션 캐시(Redis/in‑memory, 여러분의 Gift REST API 또는 다른 백엔드 서비스 내부)입니다. 하지만 가장 단순한 형태를 보여주면 다음과 같습니다:

// Gift REST API 내부의 pseudo-code
const cache = new Map<string, any>();

async function getGiftCategories() {
  const key = "gift_categories_v1";
  const cached = cache.get(key);
  if (cached && Date.now() - cached.ts < 60_000) {
    return cached.data; // 60초 캐시
  }
  const data = await fetchRealCategories();
  cache.set(key, { ts: Date.now(), data });
  return data;
}

실전에서는 Map을 Redis/Memcached로 대체하겠지만 아이디어는 같습니다. DB/외부 API 호출을 줄이는 것입니다.

한 줄로 압축하면 이렇습니다: 먼저 무엇을 어디(CDN, 엣지, Redis, DB)에서 캐시할지 명확히 정하고, 그다음에 플랫폼의 “마법 같은” 플래그를 켜세요. 캐시는 설정 체크박스가 아니라 아키텍처의 일부입니다. 속도, 안정성, 비용 모두에 영향을 줍니다.

11. 캐시와 엣지 레이어에서의 흔한 실수

오류 №1: “빨라지기만 하면 뭐든 캐시한다”.
전형적인 실수입니다. 개발자가 모든 JSON 응답에 Cache-Control: public, s-maxage=3600을 무턱대고 설정합니다. 몇 시간 뒤 한 사용자가 다른 사용자의 주문을 보고, ChatGPT는 재고에 대한 오래된 데이터를 사용하기 시작합니다. 개인화되었거나 민감한 데이터에는 private 캐시가 필요하거나, CDN 캐시를 아예 끄고 애플리케이션 수준에서 격리된 캐시를 유지해야 합니다.

오류 №2: max-age와 s-maxage를 혼동.
일부는 max-age만 설정하고 CDN도 동일하게 캐시하길 기대합니다. 실제로 max-age는 주로 브라우저에 해당하고, 공유 캐시에는 s-maxage가 필요합니다. 결국 브라우저만 캐시하고 CDN은 캐시하지 않아 origin이 계속 과부하를 맞습니다. 정답은 CDN을 위해 s-maxage를 명시하는 것입니다.

오류 №3: ETag가 모든 것을 가속해 줄 거라 기대.
ETag는 특히 큰 JSON에서 트래픽을 잘 줄여주지만, 네트워크 왕복은 여전합니다. ChatGPT App 세계에서는 모델이 어쨌든 여러분의 서버 응답을 기다린다는 뜻입니다. 본문이 없는 304라도 말이죠. 지연 시간이 중요하다면 엣지 캐시 + SWR이 필요하고, ETag는 보조 메커니즘입니다.

오류 №4: 무거운 비즈니스 로직을 엣지 함수에 욱여넣기.
“Vercel Edge에서 외부 LLM을 호출하고, 복잡한 추천을 계산하고, 외부 API 3개를 동시에 붙자 — 빠르잖아!” 그다음은 고통입니다. 실행 시간 제한, 불완전한 Node.js 환경, 이상한 오류들. 엣지는 가벼운 라우팅과 A/B에 좋고, 무거운 작업은 일반 serverless 함수나 별도 백엔드 클러스터로 보내야 합니다.

오류 №5: 캐시 무효화 전략 부재.
“1시간 캐시”로 모든 게 빨라졌습니다. 그런데 비즈니스가 말합니다. “가격/카테고리/제한을 바꿨는데 왜 ChatGPT에는 여전히 옛날 정보가 보여?” 개발자들은 수동으로 캐시를 비우고 서비스를 재시작하기 시작합니다. 중요한 데이터에 대해서는 미리 캐시를 어떻게 비울지(관리자 웹훅, 버전, 키 기반 등)를 설계해야 합니다. “한 시간 뒤면 알아서 갱신되겠지”에 의존하지 마세요.

오류 №6: 캐시 ↔ 비용의 연관성을 무시.
일부 개발자는 캐시를 오직 속도의 관점에서만 봅니다. LLM 생태계에서는 비용 문제이기도 합니다. 모델과 외부 API를 한 번 더 호출할 때마다 비용이 듭니다. 캐시가 없으면 MCP 서버가 외부 서비스/모델을 너무 자주 두드려 월말 청구서가 충격적일 수 있습니다. 올바른 캐싱은 지연 시간뿐 아니라 비용도 낮춥니다.

오류 №7: 서로 다른 로케일/지역 데이터를 하나의 캐시에 섞기.
GiftGenius가 여러 국가에서 서비스되는데 캐시 키가 top_gifts 하나뿐입니다. 결과적으로 미국 사용자는 원화가 보이고 한국 상점이 뜨며, 유럽 사용자는 달러와 미국 상점이 나타납니다. 캐싱할 때는 항상 locale, currency, tenant 같은 키를 캐시 키 이름이나 라우트(예: /api/{locale}/gifts/top)에 반영하세요.

오류 №8: Next.js/플랫폼의 “마법”에 전적으로 의존.
ISR, revalidate, 자동 CDN — 모두 훌륭합니다. 하지만 내부 동작을 이해하지 못하면 예기치 않은 효과를 얻기 쉽습니다. 예를 들어, 페이지는 오래된 콘텐츠를 보여주고 API는 최신을 반환하거나, ChatGPT와 브라우저 사용자가 서로 다른 것을 보게 될 수 있습니다. Cache-Control, ETag, SWR 패턴이 어떻게 동작하는지 시간을 들여 이해하고, Next.js는 편리한 래퍼로 쓰세요. 블랙박스로 대하지 마세요.

오류 №9: dev/staging/production 간 캐시 전략이 동일.
개발 환경에서는 캐시가 디버깅을 방해할 때가 많습니다. (“데이터를 바꿨는데 왜 ChatGPT에는 아직도 옛날 추천이 보이지?”) 개발에서는 캐시를 거의 끄거나 TTL을 몇 초로 낮추고, 프로덕션에서는 공격적으로 캐시하도록 설정을 분리하는 것이 유용합니다. 그렇지 않으면 개발 중에는 미칠 것 같고, 프로덕션에 캐시 없이 배포해 MCP Gateway 뒤의 내부 백엔드 클러스터가 요청 폭주를 맞을 수 있습니다.