CodeGym /행동 /ChatGPT Apps /ChatGPT의 Dev Mode: 로...

ChatGPT의 Dev Mode: 로컬 애플리케이션 연결하기

ChatGPT Apps

레벨 2 , 레슨 3

사용 가능

1. Developer Mode를 ‘실전적으로’ 이해하기

여러분은 이미 Dev Mode에 대해 조금 알고 있지만, 이제 실제 사례를 바탕으로 전체 그림을 한 번에 정리하는 것이 중요합니다.

ChatGPT의 Developer Mode는 Store에 공개하지 않고도 바로 여러분의 애플리케이션을 연결할 수 있게 해주는 특수 모드입니다. 여러분이 ChatGPT에게 “이게 내 MCP 서버 URL이야”라고 알려 주면, ChatGPT는 그것을 UI가 있는 외부 도구로 취급해, 도구를 호출하고 위젯을 로드하는 등 모든 작업을 일반 채팅 흐름 속에서 수행할 수 있게 됩니다.

아키텍처를 떠올려 보면, Dev Mode에서는 ChatGPT가 MCP 클라이언트로, 여러분의 Next.js 템플릿이 MCP 서버로 동작합니다. ChatGPT는 /mcp에 연결해 “무엇을 할 수 있지?”(즉, tools와 resources 목록)를 묻고, 대화 도중 해당 도구들을 호출하거나 여러분의 위젯을 iframe 안에 표시할 수 있습니다.

Dev Mode와 Store는 반드시 구분하세요:

Dev Mode — 여러분만의 작은 “차고”입니다. 부수고, 실험하고, 도구 스키마를 5분마다 바꿔도 사용자에 대한 부담이 없습니다.
Store — 진열대(스토어)입니다. 리뷰를 거친 안정 버전과 정책, 설명 등이 갖춰진 상태로 올라갑니다. 여기에 우리는 과정의 끝에서 도달할 것이고, 지금은 차고에서 놀아 봅니다.

2025년 말 기준으로 Apps SDK가 포함된 Dev Mode는 모든 ChatGPT 요금제에서 사용할 수 있지만, 엔터프라이즈 계정의 경우 워크스페이스 레벨에서 관리자가 활성화해야 할 때가 있습니다. 설정에서 Developer Mode 토글이 보이지 않는다면, 가장 먼저 이것을 확인하세요.

2. 강의 시작 시 이미 갖추고 있어야 할 것

ChatGPT 인터페이스에서 무언가를 누르기 전에, 로컬 쪽 준비가 되었는지 확인합니다.

첫째, Next.js dev 서버입니다. 프로젝트 루트에서 이미 다음을 실행했습니다:

npm run dev

기본적으로 Next.js 16은 포트 3000을 리슨하므로, UI는 http://localhost:3000에서 접근 가능합니다.

둘째, MCP 라우트입니다. CodeGym Labs 템플릿에서는 MCP 서버가 route handler인 app/mcp/route.ts로 구현됩니다. 이 파일에서 도구와 리소스를 등록하며, Dev Mode에서 ChatGPT가 애플리케이션을 연결할 때 최초 요청이 들어오는 곳도 바로 여기입니다.

아키텍처 관점에서 현재 모습은 다음과 같습니다:

브라우저 ──> http://localhost:3000 (Next.js dev, UI)
                           │
                           └── /mcp (Next.js 내부의 MCP 서버)

아직 ChatGPT와는 아무 연결도 없습니다 — ChatGPT는 클라우드에 있고, 여러분의 localhost는 보이지 않습니다. 터널을 세부적으로 설정하는 것은 다음 강의의 주제입니다. 여기서는 단순화를 위해 이미 /mcp로 접속 가능한 공개 HTTPS URL(예: ngrok 또는 템플릿 README에 따라 설정한 Cloudflare Tunnel)이 있다고 가정하겠습니다.

아직 터널을 띄우지 않아도 걱정하지 마세요. 지금은 Dev Mode의 전체 단계 체인을 눈으로 먼저 훑어보고, HTTPS URL이 생겼을 때 무엇을 해야 하는지 파악하면 충분합니다.

이미 /mcp로 접속 가능한 HTTPS URL이 있다면, 이제부터는 모든 단계를 직접 따라 하셔도 됩니다.
아직 없다면 — 이번 강의는 ‘인터페이스 둘러보기’로 진행하세요. 단계의 흐름을 이해하는 것이 중요하며, 실제 실행은 터널을 설정하는 다음 강의에서 함께 해보겠습니다.

3. 인터페이스에서 ChatGPT의 Developer Mode 켜기

첫 단계는 ChatGPT가 필요한 설정을 보여 주도록 하는 것입니다. 다음을 수행하세요:

먼저, 개발에 사용할 계정으로 ChatGPT 웹 버전에 로그인합니다. 왼쪽 하단(또는 오른쪽 상단 — UI는 계속 변화합니다)의 프로필 아이콘을 클릭하고 Settings(설정)을 선택합니다.

설정에서 애플리케이션 관련 섹션을 찾습니다. 일반적으로 Apps & Connectors 또는 Connected apps로 표시됩니다. 이 섹션을 열면 페이지 하단(또는 Advanced / 고급 탭)에 Developer Mode 토글이 나타납니다. 이것을 활성화하면 됩니다.

Dev Mode를 켠 뒤 ChatGPT는 보통 개발자 모드가 켜졌다는 알림을 보여 줍니다. 같은 섹션에 Create, Create connector, New app 같은 버튼이 나타나는데, 문구는 조금씩 달라도 요지는 같습니다. 직접 연결된 애플리케이션을 만들 수 있는 기능이 생긴 것입니다.

설정에서 Apps & Connectors 섹션도, Developer Mode 토글도 전혀 보이지 않는다면 다음을 확인하세요:

사용하려는 ChatGPT 계정으로 정말 로그인되어 있는지;
엔터프라이즈 계정이라면, 워크스페이스 관리자만 이 모드를 켤 수 있는 경우가 있습니다.

가끔은 단순히 로그아웃 후 재로그인만으로 해결되기도 합니다(Dev Mode판 “인터넷 재연결”).

4. 애플리케이션/커넥터 생성 후 MCP URL 지정하기

이제 Dev Mode를 켰으니, ChatGPT에 여러분의 GiftGenius를 등록해 봅시다. 아래는 “실전에서 하는 방식”의 시나리오입니다. 아직 HTTPS URL이 없다면, 미리보기로 생각하고 읽으세요. 터널이 준비되면 그대로 따라 하게 됩니다.

모든 작업은 방금 다녀온 ChatGPT의 설정 섹션에서 진행합니다. 대략적인 순서는 다음과 같습니다.

다시 Settings → Apps & Connectors를 엽니다. 이미 연결된 앱 목록(아마 지금은 비어 있을 것입니다)과 Create / Add connector 버튼이 보일 것입니다. 이 버튼을 누르면 앱 생성 폼이 열립니다.

폼은 보통 세 가지 핵심 필드로 구성됩니다:

이름(Name). 여러분과 ChatGPT가 모두 보게 되는 사람 친화적인 이름입니다. 이번 과정에서는 GiftGenius (dev)처럼 명명하면 로컬 개발 버전임을 한눈에 알 수 있어 편리합니다.
설명(Description). 앱이 무엇을 하고 언제 사용하는지에 대한 간단한 설명입니다. 예: “사람의 관심사를 바탕으로 선물 아이디어를 추천합니다.” 이 문구는 이후 디스커버리에도 영향을 줍니다 — 모델이 채팅 중에 언제 여러분의 App을 제안할지 판단하는 데 사용합니다.
MCP 서버 URL(Connector URL, MCP endpoint, App URL 등으로 표기되기도 함). 핵심 필드입니다. 여기에는 /mcp로 이어지는 공개 HTTPS URL을 붙여넣습니다.

예:

https://my-giftgenius-dev.ngrok.app/mcp

또는

https://giftgenius-dev.trycloudflare.com/mcp

이 필드의 핵심 포인트:

반드시 https://여야 합니다. 아니면 ChatGPT가 연결을 거부합니다.
끝에 반드시 /mcp 경로가 있어야 합니다. 템플릿 내부에서 MCP 서버가 바로 그 경로에 있고, 공식 Apps SDK 문서에도 그 경로가 명시되어 있습니다.

이 URL을 어디서 얻는지는 다음 강의에서 자세히 다룹니다(터널, Cloudflare, ngrok). 지금은 개념을 이해하는 것이 중요합니다. 로컬의 http://localhost:3000/mcp를 어떻게든 공개 https://…/mcp로 바꾸고, 그 공개 주소를 폼에 넣는 것입니다.

필드를 채운 뒤 Create / 저장을 누릅니다. 이때 ChatGPT는 여러분의 서버와 “핸드셰이크”를 수행합니다. 지정한 URL로 HTTP 요청을 보내고, 기능 매니페스트(tools/resources 목록, 메타데이터 등)를 기대하며, 서버가 MCP 프로토콜에 맞게 응답하는지 확인합니다. 모두 정상이라면 커넥터가 목록에 나타나고, ChatGPT가 발견한 도구들이 무엇인지 볼 수 있습니다. 다음 장에서 이 핸드셰이크에서 정확히 무슨 일이 일어나는지, 로그로 어떻게 확인하는지 살펴보겠습니다.

아직 터널을 설정하지 않아 임시 URL을 입력했다면, ChatGPT는 서버에 도달할 수 없다고 정직하게 알려 줄 것입니다. 이것도 유익한 경험입니다. 오류가 어디서, 어떻게 표시되는지 바로 확인할 수 있으니까요.

5. ‘후드 아래’에서는 무슨 일이? MCP 핸드셰이크 쉽게 이해하기

겉으로 보면 URL로 앱을 추가하는 평범한 폼처럼 보이지만, 내부는 조금 더 흥미롭습니다. 지금 이해해 두면 나중에 디버깅이 훨씬 수월해집니다.

여러분은 이미 커넥터를 만들 때 ChatGPT가 여러분의 /mcp에 접근해 매니페스트를 기대한다는 것을 보았습니다. 이제 이 대화를 조금 더 자세히 뜯어보겠습니다 — 디버깅에 큰 도움이 됩니다.

Create 버튼을 누르면 ChatGPT는 몇 가지 단계를 수행합니다.

먼저 지정한 /mcp URL로 접근하면서 MCP 클라이언트로 동작합니다. MCP 프로토콜에 따라, 해당 HTTP endpoint에는 기본 능력을 구현한 서버가 있어야 합니다. 예를 들어 도구 나열(list tools), 리소스 제공(위젯), 도구 호출 처리 등입니다.

서버는 다음을 설명하는 JSON 구조로 응답합니다:

서버 이름과 버전;
도구 목록: name, title, description, inputSchema 등;
리소스 목록: 위젯의 HTML을 어디서 가져오는지, MIME 타입은 무엇인지, 어떻게 렌더링하는지.

CodeGym의 Next.js 템플릿에서는 이 모든 것이 이미 app/mcp/route.ts에 구현되어 있습니다. SDK를 사용해 server.registerTool(...), server.registerResource(...) 같은 것을 호출합니다.

이 핸드셰이크를 직접 눈으로 확인하고 싶다면, app/mcp/route.ts에 간단한 로그를 추가할 수 있습니다. 이는 개발자를 위한 디버깅 요령으로, 지금 당장 건너뛰고 더 깊게 파고들고 싶을 때 다시 봐도 됩니다:

// app/mcp/route.ts
import { NextRequest, NextResponse } from "next/server";
// 이미 존재하는 server / buildManifest를 임포트

export async function GET(req: NextRequest) {
  console.log("[MCP] Handshake from ChatGPT:", req.headers.get("user-agent"));
  const manifest = buildManifestSomehow(); // 템플릿에 이미 존재합니다
  return NextResponse.json(manifest);
}

이 함수는 다소 개념적 예시입니다(템플릿 구조는 다를 수 있음). 하지만 핵심은 간단합니다. app/mcp/route.ts는 평범한 Next.js route handler이므로, 들어오는 요청을 로그할 수 있습니다. Dev Mode 연결이 성공하면 npm run dev를 실행 중인 터미널에서 해당 로그를 볼 수 있습니다.

프로토콜 관점에서는 다음과 같은 간단한 다이어그램으로 그릴 수 있습니다:

sequenceDiagram
    participant ChatGPT
    participant Tunnel as HTTPS URL (/mcp)
    participant NextDev as Next.js dev + MCP

    ChatGPT->>Tunnel: HTTP(S) 요청: https://.../mcp
    Tunnel->>NextDev: http://localhost:3000/mcp 로 프록시
    NextDev-->>Tunnel: 도구와 리소스를 담은 JSON
    Tunnel-->>ChatGPT: 응답 전달
    ChatGPT->>ChatGPT: tools/resources 목록 캐시

Dev Mode 폼에 “단순히 URL”을 넣는 행위가, 실제로는 전체 프로토콜 대화를 촉발합니다.

6. 연결 후 ChatGPT가 여러분의 앱을 ‘보는’ 방식

핸드셰이크가 성공했다고 가정해 봅시다. 이제 무엇이 달라질까요?

첫째, 설정의 Apps & Connectors 섹션에 여러분의 GiftGenius (dev)가 연결된 애플리케이션 목록으로 나타납니다. 카드 안에서 이름, 설명, 발견된 도구 목록을 확인할 수 있습니다. 또한 Refresh, Delete 같은 버튼도 보일 텐데, 특히 Refresh는 나중에 도구 스키마를 변경할 때 유용합니다.

둘째, 앱이 실제 채팅에서도 사용 가능해집니다. 새 채팅을 열고 입력창 옆 “+” 버튼을 눌러 보세요. UI 버전에 따라 “More”, “Apps”, “Tools” 같은 메뉴가 있고, 거기에 여러분의 GiftGenius (dev)가 나타날 것입니다. 이 대화에 명시적으로 선택할 수 있습니다.

앱을 선택하면 해당 채팅에 “연결”됩니다. 여러분에게는 다음과 같이 보입니다:

자연어로 요청을 보냅니다. 예: “우주 팬을 위한 선물을 50$ 예산으로 추천해 줘.”
ChatGPT는 (설명과 대화 내역을 보고) GiftGenius를 사용할 수 있다고 판단하면 MCP 도구 중 하나를 호출합니다.
호출 결과에 HTML 위젯이 포함될 수 있으며, 채팅 안에서 카드/패널 형태로 렌더링됩니다.

Dev Mode에서는 보통 메뉴에서 선택하거나 이름을 명시하여 앱을 “명시적으로” 먼저 호출하게 될 것입니다. 하지만 프로덕션에서는 ChatGPT가 앱 설명과 도구 메타데이터를 바탕으로 여러분의 App을 “스스로 제안”하기도 합니다.

시각화를 위해 작은 표로 정리해 봅시다:

현재 위치	보이는 것	의미
Settings	앱 목록의 GiftGenius (dev)	커넥터 생성, MCP 동작 중
Chat → “+”	Apps/Tools 목록의 GiftGenius (dev)	현재 채팅에 연결 가능
대화	텍스트 + GiftGenius 위젯/카드	MCP를 통한 도구 호출 발생

7. 개발 사이클: 코드를 바꾸면 ChatGPT에서 어떻게 보이나

App을 연결하는 것은 절반입니다. 나머지 절반은, Dev Mode를 일상적인 개발 흐름에서 어떻게 다룰지 이해하는 것입니다.

변경 유형은 크게 두 가지입니다. UI(위젯) 변경과 MCP 로직/도구 변경입니다.

UI만 바꾸는 경우, 예를 들어 app/page.tsx에서 제목이나 스타일을 수정한다면, Next.js 입장에서는 일반 프런트엔드 작업입니다. Dev 서버가 모듈을 재시작하고, 브라우저에서는 hot reload가 보입니다. ChatGPT에서는 여러분의 UI가 iframe 안에 열리지만, 동작은 비슷합니다. 해당 위젯을 렌더링하는 도구를 다음번 호출할 때 ChatGPT가 업데이트된 HTML을 로드합니다. HMR이 iframe까지 바로 반영될 때도 있고, 채팅에서 도구를 다시 호출하기만 해도 충분할 때가 있습니다. 캐싱

확인을 위해 위젯을 조금 바꿔 봅시다. 예를 들어 app/page.tsx에 다음과 같은 코드가 있다고 합시다:

export default function GiftGeniusWidget() {
  return (
    <main style={{ padding: 16 }}>
      <h1>GiftGenius</h1>
      <p>여기에 선물 추천이 표시됩니다.</p>
    </main>
  );
}

제목과 텍스트를 바꿔 봅시다:

export default function GiftGeniusWidget() {
  return (
    <main style={{ padding: 16 }}>
      <h1>GiftGenius (dev)</h1>
      <p>이 버전은 Dev Mode에서 동작합니다. 실서비스용 선물 추천이 아닙니다.</p>
    </main>
  );
}

파일을 저장하고, GiftGenius가 연결된 채팅으로 돌아가 앱을 다시 호출하세요(예: 같은 선물 추천 요청). 위젯 내부의 변경된 제목이 보여야 합니다 — 이는 Next.js → 터널 → ChatGPT로 이어지는 연결이 제대로 동작한다는 좋은 신호입니다.

반면 MCP 영역을 바꾸는 경우 — 새 도구를 추가하거나, inputSchema를 변경하거나, 도구 이름을 바꾸는 경우 — ChatGPT의 캐싱이 영향을 줍니다. Dev Mode에 처음 연결할 때 ChatGPT는 도구 목록을 기억하고, 변경 사항을 항상 자동으로 반영하지 않습니다. 이럴 때는 Apps & Connectors 섹션으로 돌아가 GiftGenius (dev)를 선택하고 Refresh schema / Refresh 같은 버튼을 눌러야 합니다. 그러면 ChatGPT가 다시 /mcp를 조회하여 도구 목록을 갱신합니다.

사소해 보이지만, 이 과정을 놓치면 “코드에서는 이미 수정했는데 ChatGPT가 새 파라미터를 끝내 못 알아보는” 상황을 쉽게 겪게 됩니다.

8. 미니 실습: Dev Mode에서 GiftGenius 첫 시나리오

지금까지를 하나의 실습 시나리오로 묶어 봅시다. 여기서는 /mcp에 대한 동작하는 공개 HTTPS URL(터널 또는 배포)이 있다고 가정합니다. 아직 없다면, 읽고만 넘어가세요. 다음 강의에서 실제 URL로 그대로 따라 할 것입니다.

npm run dev가 실행 중이고 로그에 에러가 없는지 확인합니다. 템플릿에서 로그를 남긴다면 터미널에 “MCP server running at http://localhost:3000/mcp” 같은 메시지가 보이면 더 좋습니다.
ChatGPT를 열고, Settings → Apps & Connectors → Advanced settings에서 Developer Mode를 켭니다.
GiftGenius (dev)라는 새 커넥터를 만들고, 짧은 설명(“Helper for choosing gifts”)과 https://<your-domain>/mcp 형태의 URL을 입력합니다.
ChatGPT가 정상적으로 연결되었는지 확인합니다. 앱 목록에서 새 항목이 보일 것입니다. 연결이 안 되면 dev 서버와 터널의 로그를 확인하세요 — 이 자체로도 유용한 진단입니다.
새 채팅을 열고 “+”를 누른 다음, 여러분의 GiftGenius (dev)를 선택하고 다음과 같이 요청해 보세요: “개발자이면서 우주와 커피를 좋아하는 사람에게 줄 선물을 추천해 줘. 예산은 40$.”
현재 템플릿이 무엇을 하는지 살펴보세요. 기본 형태에서는 단순한 카드/위젯을 보여줄 수 있습니다. 아직 “똑똑한 선물 추천”까지는 아니더라도, 여러분의 코드가 만든 무언가가 채팅에 나타났다는 사실 자체가 큰 진전입니다.

추가 연습으로 Dev Mode 확인만을 위한 테스트용 MCP 도구를 하나 만들어도 좋습니다. 예시는 다음과 같습니다(지금 당장 구현할 필요는 없습니다. 아이디어만 보세요):

// app/mcp/route.ts 내부, 다른 tools와 함께
server.registerTool(
  "ping_dev",
  {
    title: "Ping GiftGenius dev",
    description: "Dev 서버가 살아 있는지 확인합니다.",
    inputSchema: { type: "object", properties: {} },
  },
  async () => ({
    content: [{ type: "text", text: "GiftGenius dev is alive ✅" }],
    structuredContent: {},
  })
);

server.registerTool에 대해서는 도구 모듈에서 자세히 다룰 것입니다. 지금은 다음만 기억하세요. MCP를 통해 “여러분의 App이 무엇을 할 수 있는지”를 선언하고, Dev Mode는 ChatGPT에게 그 능력이 선언된 URL을 알려 주는 방법입니다.

9. 어디서 오류를 확인할까 — “내 쪽 문제”와 “ChatGPT 쪽 문제” 구분하기

아무도 “시스템의 반대편”에서 30분 동안 버그를 찾고 싶지 않습니다. 올바른 위치를 바로 보는 습관을 들이는 것이 중요합니다.

커넥터 생성 중 오류가 발생한다면. 커넥터 생성 중 ChatGPT가 App을 연결할 수 없다고 하면, 가장 먼저 여러분의 dev 서버와 터널 로그를 보세요. npm run dev를 실행 중인 터미널에서 /mcp로 들어오는 요청이 전혀 없다면 — 문제는 ChatGPT → 터널 경로에 있습니다. 요청은 있는데 서버가 500을 반환하거나 콘솔에서 에러로 죽는다면 — MCP 코드의 문제입니다.

커넥터가 생성된 뒤 채팅에서만 문제가 생긴다면. 커넥터는 만들어졌지만 채팅에서 “App unavailable / App broken” 같은 배지가 간헐적으로 보인다면, 거의 항상 다음 중 하나입니다:

dev 서버가 다운됨(Next.js가 3000 포트를 더 이상 리슨하지 않음);
터널이 꺼졌거나 URL이 바뀜;
MCP endpoint가 에러/타임아웃을 내거나 응답이 매우 느림.

UI/위젯에 대해서는 별도로. UI에 문제가 있는 경우(위젯이 렌더링되지 않거나 빈 화면, 이상한 스타일) 브라우저 DevTools도 확인하세요. 위젯은 iframe으로 로드되며, 해당 iframe 콘솔에서 JavaScript/React 오류를 일반 웹앱과 똑같이 볼 수 있습니다.

경험이 쌓이면, 오류의 모양만 봐도 “터널 냄새”인지 “Next.js 냄새”인지 구분할 수 있게 됩니다. 당장은 세 가지 잠재적 장애 지점을 기억하면 충분합니다 — 여러분의 코드, 터널, 그리고 ChatGPT. 보통 문제의 원인이 ChatGPT일 확률이 가장 낮습니다.

Insight

이 글을 읽고 있고 유료 터널이 없다면, 지금 바로 구매해도 됩니다. 어차피 며칠 내로 하게 될 일이니까요. 미리 준비해 두면 마음이 한결 편합니다.

10. Dev Mode에서 자주 발생하는 오류

오류 №1: Developer Mode를 켜지 않고 Create 버튼을 30분째 찾는 경우.
개발자가 곧바로 ChatGPT 설정의 Apps & Connectors로 들어가서 아무것도 못 찾는 일이 종종 있습니다. Developer Mode가 켜져 있지 않으면, 커넥터 생성 버튼 자체가 없을 수 있습니다. 특히 새 계정이나 다른 브라우저에서는 먼저 Advanced settings에서 Dev Mode가 켜져 있는지 확인하세요.

오류 №2: /mcp가 없는 URL을 넣거나 아예 MCP endpoint가 아닌 곳을 넣는 경우.
정석적인 실수입니다. URL 필드에 https://myapp-dev.ngrok.app처럼 끝에 /mcp가 없는 주소나, 랜딩 페이지/다른 서비스의 URL을 넣습니다. ChatGPT는 예의 바르게 해당 주소에 MCP 프로토콜로 접속하지만, 기대한 인터페이스를 찾지 못해 연결 오류를 반환합니다. Next.js 스타터 템플릿에는 명확히 적혀 있습니다. /mcp로 이어지는 URL에 연결해야 하며, Dev Mode에도 그 주소를 기입해야 합니다.

오류 №3: http://localhost:3000/mcp를 그대로 사용하려는 경우.
직관적으로 dev 서버 로그에서 보이는 http://localhost:3000/mcp를 그대로 URL 필드에 넣고 싶어질 수 있습니다. 하지만 ChatGPT는 여러분의 노트북이 아니라 클라우드에서 동작하며, 여러분의 localhost에 접근할 수 없습니다. 게다가 ChatGPT는 HTTPS를 요구합니다. 따라서 터널이나 원격 배포 없이 이 방식은 동작하지 않습니다. 이것은 ChatGPT의 버그가 아니라 정상적인 네트워크 격리입니다.

오류 №4: MCP 스키마를 바꾼 뒤 Refresh를 잊는 경우.
핸드셰이크가 성공하면 ChatGPT는 도구 및 메타데이터 목록을 캐시하여 매번 서버를 호출하지 않으려 합니다. 새 tool을 추가했거나 inputSchema를 바꿨는데도 ChatGPT가 예전처럼 행동하면, Apps & Connectors에서 커넥터 Refresh가 거의 반드시 필요합니다. 새 도구가 생겼다는 사실을 모델이 모르는 것입니다.

오류 №5: dev 서버가 꺼진 상태에서 Dev Mode를 디버깅하려는 경우.
당연해 보이지만 자주 생깁니다. 터널과 Dev Mode를 원격으로 만지작거리는 동안, 실제로는 npm run dev가 돌아가지 않거나, 문법 오류 때문에 빌드가 깨져 있는 경우입니다. 로컬 dev 서버가 죽어 있으면 Dev Mode 오류를 쫓는 것이 무의미합니다. 항상 먼저 http://localhost:3000이 여러분의 브라우저에서 정상 동작하는지 확인하고, 그다음 ChatGPT에 연결하세요.

오류 №6: Dev Mode가 “모델 자체를 바꿔서 모든 걸 이해하게 만든다”고 기대하는 경우.
Dev Mode를 켰으니 이제 모델이 우리 앱에 대해 모든 것을 “알게 됐다”고 느껴질 수 있습니다. 하지만 Dev Mode는 모델을 바꾸지 않습니다. 단지 모델이 여러분의 MCP 서버와 도구에 접근하도록 해 줄 뿐입니다. 도구 설명이 모호하거나, App 설명이 불분명하거나, 서버 로직이 이상하면, 문서가 부실한 API를 처음 본 개발자처럼 모델도 헷갈립니다. 좋은 메타데이터와 도구 설계는 다음 모듈의 주제이지만, 지금부터 이 사실을 인지하고 계세요.

오류 №7: Dev Mode를 프로덕션처럼 사용하는 경우.
“Dev Mode에서 다 잘 돌아가니, 사용자에게 이 URL로 App을 연결하라고 하자”는 유혹이 있을 수 있습니다. 문제는 Dev Mode가 대규모 사용을 위해 설계된 것이 아니라는 점입니다. 터널이 불안정하고, 설정이 쉽게 깨질 수 있으며, ChatGPT 자체가 Dev Mode 동작을 하위 호환 없이 바꿀 수도 있습니다. 실제 사용자에게는 Store와 프로덕션 배포가 있습니다. Dev Mode는 오로지 여러분의 실험실입니다.

이전 이전 레슨

다음 다음 레슨

코멘트

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION