전형적인 배포 오류와 디버깅 전략

1. 배포의 해부: 어디서 문제가 생길 수 있는가

먼저 전체 체인을 한눈에 보는 것이 유익합니다. 여러분의 아키텍처에서 ChatGPT App 배포를 다음과 같은 선형 흐름으로 생각할 수 있습니다:

flowchart TD
  A[내 노트북
git commit] --> B[Git 저장소
GitHub/GitLab]
  B --> C[Vercel Build
npm run build]
  C --> D[Vercel Deploy
Preview/Prod]
  D --> E[HTTP endpoint
/mcp, /api/...]
  E --> F[ChatGPT / Dev Mode
도구 호출, 위젯]

이 각 단계 어디에서든 오류가 발생할 수 있지만, ChatGPT에서 보이는 증상은 대체로 비슷합니다: "Error talking to app", "Network error" 혹은 그냥 응답 없음. 여러분의 과제는 — 아무렇게나 쏘지 말고, 먼저 파악하는 것입니다: 빌드 단계에서 떨어졌는지, 실행 중(runtime) 문제인지, 아니면 ChatGPT가 엉뚱한 곳을 보고 있는지.

문제를 크게 세 가지 범주로 나누면 편합니다:

• 빌드 오류(Build): Vercel이 프로젝트를 전혀 빌드하지 못함. 프로덕션은 업데이트되지 않으니 한편으론 “다행”이지만, 빌드가 빨갛게 실패합니다.
• 런타임 오류(Runtime): 빌드는 통과했지만 요청 시 500/502가 오거나 타임아웃, 이상한 동작이 나타납니다.
• 구성 드리프트(Config drift): 로컬도 정상, Vercel 로그도 정상인데, ChatGPT가 예전 URL을 보거나 오래된 매니페스트/비어 있는 env 변수를 사용합니다.

이제 이 세 층위를 따라가며 동시에 공통 디버깅 전략을 정리해 보겠습니다.

2. 빌드 오류: 프로젝트가 아예 안 빌드될 때

도입부에서 말한 첫 유형 — 빌드 오류입니다. Vercel이 여러분의 Next.js 프로젝트를 성공적으로 빌드하지 못해 프로젝트가 아예 빌드되지 않습니다.

Node와 Next.js: 환경이 다르면 요구사항도 다르다

로컬에서는(아쉽게도) 오래된 Node로도 잘 돌아갈 수 있지만, Vercel은 지원되는 Node 버전으로 여러분의 Next.js 16 프로젝트를 빌드하려고 합니다 (최소 18.18.0). package.json에 호환되지 않는 버전을 명시해 두었다면, dev 서버는 로컬에서 돌았더라도 프로덕션 빌드는 실패할 수 있습니다.

간단한 방어법 — package.json에 "engines"를 명시하세요:

{
  "engines": {
    "node": ">=18.18.0"
  }
}

그러면 로컬과 CI/Vercel 모두에서 Node가 너무 오래되었음을 미리 알 수 있습니다.

“내 컴퓨터에서는 잘돼요!”와 잊힌 의존성

클리셰 같은 상황: npm install some-lib로 라이브러리를 설치했지만, 업데이트된 package-lock.json을 커밋하지 않았거나 일부 의존성이 전역으로만 설치되어 있는 경우입니다. Vercel은 애플리케이션을 “처음부터” 빌드하며, 매니페스트를 바탕으로 npm install을 성실히 실행합니다. 하지만 여러분이 좋아하던 some-lib가 거기 없으면 — 빌드 에러가 납니다.

여기엔 엄격한 습관이 도움이 됩니다:

• 새로운 의존성은 추가 즉시 커밋한다;
• main/production으로 푸시하기 전에 로컬에서 npm run build를 실행한다. 로컬 빌드가 실패하면, Vercel에서는 더 나쁩니다.

대소문자 구분 파일 시스템

로컬에서는 많은 분들이 macOS나 Windows를 쓰며, 기본 파일 시스템이 파일 이름의 대소문자를 구분하지 않습니다. Vercel에서 빌드는 Linux 환경에서 진행되며, 거기서는 Widget.tsx와 widget.tsx가 서로 다른 파일입니다.

전형적인 버그:

// 코드에서의 import
import { AppWidget } from "@/components/Widget";

// 그런데 저장소에는 components/widget.tsx 파일이 있음

여러분의 컴퓨터에서는 잘 동작하지만, Vercel에서는 모듈 오류 “Cannot find module '@/components/Widget'”가 납니다. 해결책은 파일 이름 규칙을 정리하고 대소문자에 주의를 기울이는 것입니다.

빌드 단계의 env 변수

또 다른 놀라움의 근원 — 빌드 단계에서 실행되는 코드(예: next.config.mjs 또는 빌드 시 import되는 모듈)에서 process.env.* 를 사용하는 경우입니다. 로컬에서는 .env.local을 불러오고 있지만, Vercel의 빌드 환경에 해당 변수를 설정해 두지 않았다면, 빌드가 실패하거나 — 더 나쁜 경우 — undefined로 “조용히” 통과하며 잘못된 값이 번들에 “구워질” 수 있습니다.

특히 ChatGPT App에서는 MCP 엔드포인트의 baseURL이나 외부 API의 URL을 빌드 단계에서 구성한다면 매우 치명적입니다.

좋은 습관 — 애플리케이션 시작 전, 중요한 env 변수를 명시적으로 검증하여(별도 섹션에서 다룸) 빌드가 크고 예측 가능하게 실패하도록 만드는 것입니다.

3. 런타임 오류: 빌드는 성공했는데 동작하지 않을 때

이제 도입부의 두 번째 층위 — 런타임 오류로 넘어갑니다. 빌드는 통과했지만 실행 중에 문제가 생깁니다.

빌드는 통과했고, Vercel은 초록색 배포를 보여 줍니다. 여러분은 ChatGPT App을 프로덕션 URL로 전환했습니다 — 그런데 채팅에서 "Error talking to app"이 나타납니다. 즉, 문제가 실행 단계로 넘어왔다는 뜻입니다.

null 또는 비어 있는 env 변수

ChatGPT App 세계에서 프로덕션 사고는 대개 undefined로 시작합니다. 로컬에는 .env.local이 잘 준비되어 있고 OPENAI_API_KEY, MCP_BASE_URL 등이 들어 있지만, Vercel에는 이 변수를 만들지 않았거나 이름을 혼동했을 수 있습니다.

예를 들어, 다음과 같이 읽는데:

const apiKey = process.env.OPENAI_API_KEY;

Vercel에는 OPENAI_APIKEY나 OPENAI_API_KEY_PROD로 만들어 둔 경우입니다. 그 결과, 첫 MCP 도구 호출에서 라우트 핸들러가 인증 오류로 떨어집니다.

애플리케이션이 즉시, 그리고 명확하게 실패하는 편이 훨씬 낫습니다. 좋은 패턴은 Next.js 프로젝트에 env 변수를 import 시점에 검증하는 별도 모듈을 두는 것입니다:

// app/lib/env.ts
const required = ["OPENAI_API_KEY", "MCP_BASE_URL"] as const;

type RequiredKey = (typeof required)[number];

function getEnv(key: RequiredKey): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Missing required env var: ${key}`);
  }
  return value;
}

export const env = {
  OPENAI_API_KEY: getEnv("OPENAI_API_KEY"),
  MCP_BASE_URL: getEnv("MCP_BASE_URL"),
};

이제 Vercel에서 변수를 설정하지 않았다면, Next.js는 env를 처음 import하는 순간 실패하고 로그에는 "Missing required env var: ..." 같은 이해 가능한 메시지가 남습니다.

Vercel에서는 env 변수 변경이 자동으로 반영되지 않는다는 점을 기억하세요. 값을 수정했다면 새 배포(redeploy)를 해야 합니다. 그렇지 않으면 런타임은 이전 값을 계속 사용합니다.

route 핸들러와 MCP 엔드포인트의 오류

공식 ChatGPT App 템플릿에서 MCP 서버는 보통 app/mcp/route.ts로 구현됩니다. 내부에는 JSON-RPC 요청을 파싱하고 도구로 라우팅하며 응답을 돌려주는 코드가 있습니다. 체인 어딘가에서 처리가 없는 throw가 발생하면 — ChatGPT 사용자에게 500이 떨어집니다.

항상 MCP 핸들러의 최상위를 try/catch로 감싸고, 오류를 로깅하며 구조화된 응답을 반환하세요:

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

export const dynamic = "force-dynamic";
export const maxDuration = 30; // 초

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    // 여기서 MCP 요청을 처리
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json(
      { error: "Internal MCP error" },
      { status: 500 }
    );
  }
}

몇 가지 포인트:

• dynamic = "force-dynamic" 은 Next.js 16에서 MCP 경로에 대해 예상치 못한 정적 생성과 캐싱을 피하는 데 도움이 됩니다.
• maxDuration = 30 은 route 핸들러가 최대 30초까지 동작할 수 있음을 Vercel에 명시합니다. 긴 LLM 요청에서 중요합니다.

ChatGPT에서의 타임아웃과 “Network error”

Vercel은 서버리스 함수 실행 시간을 제한합니다. 무료 요금제에서는 보통 10초 내외, 유료 요금제에서는 더 길 수 있습니다(몇 분까지). MCP 도구가 데이터베이스나 외부 API에 긴 요청을 보낸다면 제시간에 응답하지 못해 ChatGPT가 "Network error" 또는 끊긴 스트림을 받을 수 있습니다.

스트리밍(SSE)으로 부분 결과를 보내는 경우, 타임아웃 만료 전에 첫 바이트를 전송하는 것이 특히 중요합니다. 그렇게 하면 전송 자체는 더 오래 걸려도 플랫폼은 함수를 “멈춘” 것으로 보지 않습니다.

작은 팁: 도구 호출 시간을 측정하고 도구 이름과 함께 로깅하세요. 그러면 로그에서 예를 들어 search_flights가 항상 12초가 걸려 제한에 살짝 걸린다는 사실을 한눈에 볼 수 있습니다.

export async function safeToolCall<TInput, TOutput>(
  name: string,
  handler: (input: TInput) => Promise<TOutput>,
  input: TInput
): Promise<TOutput> {
  const started = Date.now();
  try {
    const result = await handler(input);
    console.log("[tool] ok", name, { ms: Date.now() - started });
    return result;
  } catch (error) {
    console.error("[tool] fail", name, {
      ms: Date.now() - started,
      error,
    });
    throw error;
  }
}

이후에는 handler(args) 대신 safeToolCall("search_flights", handler, args)를 호출합니다.

네트워크와 외부 서비스

가끔은 사소한 https://와 http://의 차이나 오래된 baseURL 문제입니다. 로컬에서 한 URL로 먼저 테스트하고, 프로덕션에서는 다른 도메인이나 포트를 쓰는 경우 특히 그렇습니다.

기본 URL을 (환경에 따라) 구성으로 분리하고 도구 코드에 직접 박아 넣지 않는 것이 좋습니다. 그러면 환경을 바꿀 때 한 곳의 env만 바꾸면 되고, 코드의 다섯 군데에 흩어진 http://localhost:3001를 기억해내지 않아도 됩니다.

4. 구성과 환경 드리프트

마지막으로, 앞서 말한 세 번째 유형 — 환경 간 구성 드리프트입니다.

빌드가 통과했고 런타임 로그도 건강해 보이는데, ChatGPT가 “마치 다른 버전의 앱이 동작하는 듯” 보일 수도 있습니다. 이 경우는 코드 문제가 아니라 구성과 환경 일관성 문제인 경우가 많습니다.

Dev Mode 대 프로덕션

Dev Mode에서 ChatGPT는 여러분이 수동으로 지정한 Connector URL을 봅니다. 보통 터널 URL (https://myapp-dev.ngrok-free.app/mcp 같은 것)이나 Vercel의 스테이징 URL이죠. 프로덕션(스토어 또는 조직 설정을 통해)에서는 앱이 안정적인 프로덕션 엔드포인트를 가리켜야 합니다. 예: https://myapp.vercel.app/mcp.

거의 모두가 한 번쯤 하는 실수: Vercel에 배포했는데, ChatGPT App 설정에는 여전히 예전 터널 URL이 남아 있는 경우입니다. 로컬 서버는 꺼졌고 터널도 오래전에 만료되었는데, ChatGPT는 그곳에 계속 요청을 보내며 502를 받습니다. UI에는 "Error talking to app"처럼 보이고, 학생은 전혀 실행되지도 않는 MCP 코드를 고치기 시작합니다.

해결책은 규율입니다: 환경을 바꿀 때마다(터널 → 스테이징, 스테이징 → 프로덕션) Dev Mode와 프로덕션 앱 설정에 어떤 URL이 적혀 있는지 반드시 확인하세요.

오래된 매니페스트와 ChatGPT 캐시

ChatGPT는 여러분의 App 정보를 캐시합니다: 도구 목록, 설명, 메타데이터 등. 그래서 “도구 스키마를 바꿨는데도 모델은 여전히 예전 이름의 인자를 요구한다” 같은 상황이 현실로 발생합니다.

도구를 크게 변경했다면 유용한 절차:

• 정말 새 버전을 배포했는지 확인(로그에서 커밋 해시 확인, 시작 로그에 출력);
• Dev Mode에서 앱을 재생성하거나 재연결해 플랫폼이 매니페스트를 다시 읽게 만들기;
• MCP Inspector를 통해 디버깅하는 동안 실제 도구 목록과 스키마가 무엇인지 정확히 확인하기.

env 구성: dev/staging/prod

env 변수가 빌드와 런타임을 어떻게 망가뜨릴 수 있는지 이미 이야기했습니다. 여기서는 dev/staging/prod 전체를 위에서 내려다보며 이 값들의 일관성을 봅니다.

흔한 고통: 로컬의 .env.local은 완벽하지만 Vercel 환경들은 혼돈 상태. 결과적으로:

• 로컬에서는 하나의 API 키와 하나의 외부 서비스 URL을 사용하고;
• 스테이징에서는 완전히 다른 값들을 쓰며;
• 프로덕션에는 변수 절반이 정의도 안 되어 있습니다.

저장소에 docs/env.md 같은 간단한 텍스트 파일을 두면 큰 도움이 됩니다. 거기에 필요한 변수, 어떤 환경에서 필수인지, 예시 값 등을 정리해 두세요. 서류 작업처럼 보이지만, 실제 사고 순간에 몇 시간을 아껴 줍니다.

5. ChatGPT 측에서 보이는 오류는 어떻게 생겼나

이제 ChatGPT 사용자 관점에서 상황을 봅시다. 사용자는 인터페이스만 보고 Vercel, Node, MCP에 대해 아무것도 모릅니다. 안타깝게도 여러분도 아직 무엇이 깨졌는지 모를 수 있습니다.

ChatGPT에서 흔한 증상:

• 도구 사용 시도 직후 "Error talking to [App Name]" 메시지;
• 오류 없이 무한 스피너;
• 빨간 텍스트 "I encountered an error while running the tool";
• 위젯이 나타나지 않거나 빈 상태로 나타남.

각 증상은 보통 특정 수준의 고장과 대응됩니다:

• 앱이 아예 접근 불가(잘못된 URL, 터널 종료, SSL 오류 등)라면 ChatGPT가 MCP 엔드포인트에 접근할 수 없습니다 — 브라우저에서 도메인 접근 가능 여부와 Vercel 로그의 4xx/5xx 코드를 확인하세요;
• MCP가 error 필드가 있는 유효한 JSON-RPC로 응답하면, ChatGPT는 도구가 오류를 반환했다고 알려 줍니다 — 이는 비즈니스 로직이나 인자 검증 문제입니다;
• MCP가 성공적으로 응답했는데 위젯의 HTML이 깨졌거나 JS 오류라면, 위젯 콘솔(DevTools → 위젯 iframe)에서 무엇이 정확히 실패했는지 볼 수 있습니다.

따라서 좋은 습관: 이상한 행동을 보자마자, 즉시 타임스탬프(분 단위까지)를 기록하고 그 시간대의 Vercel 로그에서 해당 요청을 찾으러 가세요.

6. 디버깅 전략: 당황하지 말고 체계적으로

지금까지 내용을 바탕으로, 문제가 생겼을 때의 작은 플레이북을 만들어 봅시다. 목표 — 허둥대는 시간을 줄이고 차분한 알고리즘으로 대체하는 것.

1단계: 문제 유형을 식별한다

Vercel에서 빌드가 빨갛다면 — 오히려 기쁩니다. 프로덕션 이전에 오류가 잡힌 것이니까요. 빌드 로그를 열고, 진짜 첫 번째 오류를 봅니다( 200줄의 경고가 아니라) 그리고 로컬에서 npm run build로 재현하세요.

빌드가 초록색인데 ChatGPT가 불평한다면 — 런타임 또는 구성 문제입니다. 다음을 확인하세요:

• 브라우저에서 앱의 프로덕션 URL에 접근 가능한지(https://myapp.vercel.app/mcp가 뭔가를 응답하는지);
• MCP 엔드포인트가 200/500을 반환하는지, 아니면 아예 해석되지 않는지;
• App 설정의 URL이 방금 확인한 것과 일치하는지.

2단계: 추측이 아니라 로그를 읽는다

다음 정거장은 Vercel 로그입니다. 해당 배포와 해당 환경(Preview/Production)의 서버 로그를 보세요.

찾아야 할 것들:

• Error: Missing required env var ... 같은 오류 — 구성 문제입니다;
• MCP 핸들러의 스택 트레이스 — 비즈니스 로직이나 입력 파싱이 실패한 것입니다;
• 타임아웃 또는 함수 최대 실행 시간 초과 메시지.

동시에 MCP Inspector를 잊지 마세요. 같은 MCP 엔드포인트에 인스펙터로 붙어 도구를 직접 호출해 보면, 문제가 MCP 자체인지, 아니면 ChatGPT ↔ MCP 연결 사이에 있는지 금방 드러납니다.

3단계: 빠른 롤백인가, 핫픽스인가?

프로덕션 배포가 명백히 깨졌고(예: MCP 라우트가 모든 요청에서 같은 오류를 계속 던짐), 이전 배포는 건강했다면, 올바른 결정은 롤백입니다. Vercel에서는 재빌드 없이도 직전 성공 배포로 빠르게 전환할 수 있습니다 — 사실상 활성 버전을 바꾸는 것입니다.

원인을 완전히 이해하지 못한 상태에서 프로덕션을 “즉석에서” 고치려 들기보다 이 편이 낫습니다.

상황을 안정화한 다음, 차분히 원인을 분석하고 테스트를 작성하고 코드를 수정한 후 다음 버전을 배포하세요.

4단계: 문서로 지식을 고정한다

심각한 인시던트는 내부 README를 업데이트할 좋은 계기입니다:

• 없으면 바로 실패하는 필수 env 변수를 목록에 추가;
• 어떤 케이스가 오류를 유발했는지 기록(예: “파일 이름 대소문자 불일치 import”);
• 빠르게 문제를 해결하는 데 도움이 된 간단한 대응 알고리즘을 정리.

지루해 보일 수 있지만, 몇 달 뒤 여러분이 여러분에게 감사하게 됩니다.

7. 코드에서의 작은 실천 팁

이제 플레이북의 몇 가지 단계를 학습용 애플리케이션(ChatGPT App)의 작은 코드 팁으로 정리해 봅시다.

단일 구성 모듈

이미 env 변수 검증기를 간단히 작성했습니다. 여기에 환경 구분을 더할 수 있습니다:

// app/lib/config.ts
type NodeEnv = "development" | "test" | "production";

const nodeEnv = (process.env.NODE_ENV || "development") as NodeEnv;

const requiredBase = ["OPENAI_API_KEY"] as const;
const requiredProd = ["MCP_BASE_URL"] as const;

function ensure(keys: readonly string[]) {
  for (const key of keys) {
    if (!process.env[key]) {
      throw new Error(`Missing env var ${key} for NODE_ENV=${nodeEnv}`);
    }
  }
}

ensure(requiredBase);
if (nodeEnv === "production") {
  ensure(requiredProd);
}

export const config = {
  nodeEnv,
  openaiApiKey: process.env.OPENAI_API_KEY!,
  mcpBaseUrl: process.env.MCP_BASE_URL ?? "http://localhost:3000/mcp",
};

이런 모듈은 프로덕션이 필요한 변수 없이 실행 중이라면 즉시 드러나게 해 줍니다.

들어오는 MCP 요청 로깅

아주 간단하지만 MCP 핸들러에 매우 유용한 보일러플레이트:

// app/lib/mcp-logger.ts
export function logMcpRequest(body: unknown) {
  console.log("[mcp] request", {
    time: new Date().toISOString(),
    // 민감한 데이터는 로깅하지 않음
    keys: typeof body === "object" && body !== null
      ? Object.keys(body as Record<string, unknown>)
      : typeof body,
  });
}

app/mcp/route.ts에서 사용:

import { logMcpRequest } from "@/app/lib/mcp-logger";

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    logMcpRequest(body);
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json({ error: "Internal error" }, { status: 500 });
  }
}

로그에서 ChatGPT로부터 무엇이 들어오는지(최소한 키 수준에서 ("jsonrpc", "method", "params")) 볼 수 있어 어떤 호출이 실패하는지 파악하기 쉬워집니다.

MCP 엔드포인트의 간단한 헬스체크

가끔은 MCP 서버를 위한 작은 헬스체크 route 핸들러가 유용합니다. ChatGPT가 직접 호출하진 않지만, 브라우저에서 빠르게 열어 서버가 살아 있는지와 env 변수를 보고 있는지를 확인할 수 있습니다:

// app/api/health/route.ts
import { NextResponse } from "next/server";
import { config } from "@/app/lib/config";

export async function GET() {
  return NextResponse.json({
    status: "ok",
    env: config.nodeEnv,
    hasOpenAiKey: !!config.openaiApiKey,
  });
}

https://myapp.vercel.app/api/health가 status: "ok"로 응답한다면, 최소한 Node 코드까지의 기본 파이프라인은 살아 있다는 뜻입니다.

8. 배포와 디버깅 시 자주 하는 실수

오류 1: 로컬에서 npm run build 없이 배포.
개발자가 로컬에서 빌드를 한 번도 돌리지 않으면, 불일치 Node 버전, 경로 문제, TS 오류를 Vercel에서야 알게 됩니다. 이러면 “망가짐 → 수정” 사이클이 길어집니다. 실험 한 번이 새 배포 하나이기 때문이죠. 푸시 전에 npm run build를 습관적으로 실행하면 시간을 크게 절약합니다(섹션 2와 6.1 단계의 로컬 npm run build 참조).

오류 2: 시크릿이 .env.local에만 존재.
작성자 PC에서는 완벽히 동작하지만, 프로덕션에서는 process.env.OPENAI_API_KEY === undefined라서 실패합니다. 원인은 단순합니다: Vercel 설정에 env 변수를 추가하지 않았거나, 이름을 다르게 붙인 것입니다. 특히 Development/Preview/Production 구분을 잊어버리고, staging과 prod가 다르게 동작하는 데 놀랍니다(자세한 내용 — 섹션 3.1, 4.3, 7.1).

오류 3: 시크릿에 NEXT_PUBLIC_* 사용.
Next.js에서는 NEXT_PUBLIC_ 접두사가 붙은 모든 변수가 브라우저 번들로 전달됩니다. 부주의하게 API 키를 NEXT_PUBLIC_OPENAI_API_KEY로 명명했다면, 사용자 브라우저로 전송되어 DevTools에서 추출될 수 있습니다. 절대 그렇게 해서는 안 됩니다. 공개되어도 안전한 값(예: 기능 플래그 식별자 등)만 public이어야 하며, 토큰은 안 됩니다.

오류 4: Vercel 로그를 무시하고 “ChatGPT로 고치기” 시도.
때로 개발자는 채팅에서 "Error talking to app"를 보고 몇 시간을 프롬프트나 도구 설명을 바꾸고 Dev Mode에서 무언가를 만지지만, serverless 로그는 한 번도 보지 않습니다. 그런데 거기에는 아주 이해 가능한 오류가 있습니다: "Missing env var", "Cannot find module", 혹은 특정 도구의 스택 트레이스. 좋은 엔지니어는 먼저 로그를 보고, 그다음에 모델과 논쟁합니다.

오류 5: Dev Mode와 프로덕션 App 혼동.
Vercel에 첫 성공 배포 후에도 Dev Mode가 여전히 예전 터널이나 preview URL을 볼 수 있습니다. 결과적으로 여러분은 프로덕션을 테스트한다고 확신하지만 실제로는 오래전에 삭제했어야 할 로컬 브랜치와 대화하고 있을 수 있습니다. 반대도 있습니다: 임시 수정을 테스트한다고 생각했지만, ChatGPT는 실 운영 엔드포인트를 때리는 경우. App과 Dev Mode 설정에서 어떤 URL이 적혀 있는지 주기적으로 확인해야 합니다(섹션 4.1 참조).

오류 6: Vercel의 env 변경이 “실시간” 반영된다고 기대.
일부 수강생은 Vercel 콘솔에서 변수를 바꾸자마자 ChatGPT에서 결과를 확인하러 갑니다. 하지만 재배포가 없었기 때문에, 런타임은 여전히 이전 값을 사용합니다. env 변수를 변경하면 항상 새 배포가 필요합니다. 그렇지 않으면 함수는 업데이트를 보지 못합니다(섹션 3.1 자세히).

오류 7: 간단한 롤백 전략의 부재.
사고 순간에는 main에 “빠른 핫픽스”를 밀어 넣고 싶은 유혹이 큽니다. 하지만 이는 또 하나의 잠재적으로 깨진 배포를 추가할 뿐이고, 그동안 사용자는 고통받습니다. 더 안전한 습관은: 심각한 오류라면 즉시 이전 성공 배포로 롤백하고, 별도 브랜치에서 문제를 고친 뒤, 새로운 버전을 배포하는 것입니다. Vercel은 이를 위한 편리한 UI를 제공합니다. 꼭 활용하세요.