사용자 플로우: GPT가 앱을 제안하고 그 기능을 호출하는 방식

1. 서론

일반적인 웹‑서비스를 만든다고 상상해 보세요. 모든 것이 단순합니다. URL /search가 있고, 사용자가 버튼을 누르면 컨트롤러 searchController를 호출합니다. ChatGPT Apps 세계에서는 사용자가 /search 같은 것을 보지 않습니다. 사람의 언어로 이렇게 씁니다:

“게이머인 남동생에게 줄 선물, 예산은 50$ 아래로 추천해줘”

그리고 이어서:

• 모델이 판단합니다: “오, 선물 이야기네. 내게 GiftGenius가 있고, 이 앱이 이걸 잘해.”
• GPT가 스스로 “버튼을 누릅니다” — 여러분 앱의 도구들을 호출합니다.
• 가끔은 사용자에게 제안합니다: “GiftGenius를 열어 카드 형태로 보여줄까요?”

핵심 전환점: 사용자는 의도를 표현하고, 버튼은 모델이 누릅니다. 이 플로우를 이해하지 못하면, 아주 쉽게:

• 의미 없는 이름(run_func, doStuff)의 도구를 만들고,
• 모델이 절대 제안하지 않거나 상황에 맞지 않게 호출되는 App을 얻게 되고,
• 대화 흐름을 깨는 “불쑥 튀어나오는” 위젯을 만들게 됩니다.

그래서 이 강의에서는 GPT가 여러분의 App을 어떻게 알게 되고, 대화의 어떤 지점에 “끼워 넣는지”에 대한 멘탈 모델을 세웁니다.

Insight: 앱은 ChatGPT의 플러그인이다

스마트폰 앱이나 WeChat의 미니 앱과 달리, ChatGPT의 앱은 구조가 다릅니다.

ChatGPT는 언제 여러분의 앱을 실행하고 어떤 기능을 호출할지 스스로 결정합니다. ChatGPT의 앱은 (제약은 있지만) 대화 로직에 적극 개입할 수 있습니다. 그들의 주요 목표이자 강점은 ChatGPT 자체의 능력을 확장하는 것입니다.

ChatGPT가 사용자의 문제를 완벽히 해결할 수 있다면 — 굳이 여러분의 앱을 호출할 필요가 없습니다. ChatGPT가 전혀 해결하지 못하는 문제라면 — 사용자는 애초에 그런 질문을 하지 않을 것입니다. 이상적인 경우는 ChatGPT가 사용자의 요청을 부분적으로만 해결할 수 있는 때입니다. 즉, 수요는 많지만 결과가 부족한 상태죠.

바로 그때 ChatGPT가 여러분의 앱을 호출하고, 함께 사용자를 행복하게 만듭니다. 사용자는 더 행복해지고, 여러분은 더 부자가 됩니다.

2. 사용자의 눈으로 본 ChatGPT App 실행 방식

사용자에게는 “MCP‑서버를 호출하고 call_tool을 실행해” 같은 버튼이 없습니다. 대신 텍스트 입력창과 (가끔) 앱 메뉴가 있죠. 사용자 입장에서는 두 가지 기본 실행 방식이 있습니다: 명시적과 암시적.

명시적 실행 (explicit)

사용자가 의도적으로 여러분의 앱을 선택하는 시나리오입니다.

전형적인 경우:

• ChatGPT의 스토어에서 앱을 찾아 “열기”를 누릅니다.
• 런처(예: 텍스트 입력(Composer) 옆 + 버튼)를 통해 앱을 고릅니다.
• 메시지를 앱 이름으로 시작합니다: “GiftGenius, 선물 좀 추천해줘…” — 이를 named mention이라고 합니다. 프롬프트의 시작에 앱 이름이 있으면, ChatGPT는 자동으로 여러분의 App을 응답 컨텍스트에 섞어 넣습니다.

명시적 모드에서는 모델이 처음부터 압니다: 사용자가 바로 이 App을 쓰러 왔다는 것을. 따라서:

• GPT가 여러분의 도구를 더 자주, 더 적극적으로 호출합니다.
• 여러분 App의 UI‑위젯이 첫 번째 응답부터 나타날 수 있습니다.
• GPT가 App을 “무시”하고 자체 답변만 하는 경우가 줄어듭니다.

좋은 예시: 사용자가 선물 추천을 “만져보려고” GiftGenius를 직접 엽니다. 목록에서 App을 누르면, GPT가 이런 스타일로 인사합니다:

“안녕하세요! 저는 GiftGenius예요. 선물 고르기를 도와드릴게요. 누구에게, 어느 정도 예산으로 찾을까요?”

그리고 곧바로 여러분의 도구들을 적극적으로 사용합니다.

암시적 실행 (implicit / suggested)

완전히 다른 시나리오: 사용자는 앱을 전혀 떠올리지 않습니다. 그냥 일반 채팅에서 이렇게 씁니다:

“엄마 생일 선물 좀 골라줘. 정원 가꾸는 걸 좋아하시고, 예산은 100$까지야.”

GPT는 요청을 분석하고 다음을 파악합니다:

• 에코시스템에 GiftGenius라는 App이 있고, 그 도구 설명이 “Use this when the user wants to get gift recommendations”라고 되어 있다;
• 태스크와 제약(선물, 예산, 관심사)이 이 App과 잘 맞아떨어진다.

이 경우 모델은 이렇게 “조심스럽게 제안”할 수 있습니다:

“GiftGenius 앱을 사용해 구체적인 선물 후보를 찾아 카드 형태로 보여드릴 수 있어요. 열어볼까요?”

사용자가 동의하면 — GPT는 App의 적절한 도구를 호출하고, 경우에 따라 여러분의 위젯을 렌더링합니다.

중요한 점은 여러분이 어디에도 if (prompt.includes("선물")) openApp() 라고 쓰지 않는다는 것입니다. 모델은 다음을 바탕으로 스스로 결정을 내립니다:

• 요청 텍스트와 대화 히스토리;
• 여러분 도구의 메타데이터(이름, 설명, 파라미터 스키마);
• 사용자의 App 연결 상태(인증 여부), 기업 사용자 여부 등.

여러분이 영향을 미칠 수 있는 것은 알고리즘이 아니라, 여러분의 App과 도구가 모델에게 어떻게 “설명되어 있는가”입니다.

하이브리드: GPT가 먼저 묻고 그다음 앱을 제안할 때

가끔 사용자는 아주 포괄적으로 씁니다:

“동료에게 뭘 해줘야 할지 모르겠어. 아이디어가 전혀 없어.”

모델은 GiftGenius가 도움 될 걸 알지만, 정보가 너무 모호하다고 판단합니다. 자주 보이는 패턴:

1. GPT가 1–2개의 확인 질문을 텍스트로 합니다.
2. 그 다음 App 실행을 제안합니다: “선물 추천 도구가 있어요. 열어서 몇 가지 후보를 보여드릴까요?”

이건 좋은 UX입니다. 사용자가 “억지로 다른 앱으로 보내졌다”고 느끼지 않거든요.

3. Discovery: GPT는 여러분의 App을 어떻게 찾는가

이제 이 모든 것이 모델 관점에서는 어떻게 보이는지 살펴보겠습니다.

Apps SDK 문서에서는 이를 Discovery라고 부릅니다 — 사용자와 모델이 여러분의 App을 알게 되는 모든 방식입니다. 일반 채팅의 자연스러운 요청, 앱 카탈로그, 런처 같은 특별한 “진입점”이 포함됩니다.

모델은 여러분의 App 존재를 어떻게 아는가

등록 시 ChatGPT가 여러분의 App을 실행하고, App은 (MCP를 통해) 자신을 소개합니다: 사용 가능한 도구와 그 스키마 — 이름, 설명, 입력 파라미터의 JSON‑스키마를 나열합니다. 앱 정보는 등록 시 제공하고, 도구 정보는 ChatGPT가 MCP 메서드 list_tools를 통해 직접 가져갑니다.

모델은 여러분의 소스 코드를 보지 못하며, 접근할 수 있는 것은 다음뿐입니다:

• 도구 이름(name);
• 설명(description);
• 입력 시그니처(inputSchema).

이것이 바로 “모델을 위한 API”가 됩니다. 만약 여러분이 도구를 run_func로 이름 짓고 설명을 “Executes the function”으로 적으면, 모델은 언제 호출해야 할지 알 수 없습니다. 반대로 suggest_gifts에 “Use this when the user wants gift ideas based on recipient, occasion and budget” 같은 설명을 붙이면 — 모든 것이 명확해집니다.

Named mention과 in‑conversation discovery

공식 Apps SDK 스펙은 두 가지 핵심 메커니즘을 구분합니다:

• Named mention — 사용자가 메시지를 여러분 App 이름으로 시작할 때. 이 경우 App은 거의 확실하게 불려와 응답에 사용됩니다.
• In‑conversation discovery — 사용자가 그냥 요청을 쓰면, 모델이 App을 연결할지 판단합니다. 이때 고려되는 요소:
  • 대화 컨텍스트(메시지 히스토리, 이전 도구 결과, 사용자 선호도);
  • 텍스트 내의 명시적 브랜드 언급;
  • 여러분 도구의 메타데이터 — 이름, 설명, 파라미터 문서;
  • “링크” 상태 — 사용자가 App에 연결되어 있는지(인증 여부, 필요한 퍼미션 허용 여부).

개발자는 이 과정에 간접적으로 영향을 줍니다. 코드에서 if/else로가 아니라, 좋은 메타데이터와 UX 패턴으로요.

카탈로그와 런처

대화 방식 외에도, ChatGPT 내부의 스토어와 컴포저에서 접근 가능한 런처가 있습니다. 이를 통해 사용자는 일반 앱 스토어처럼 App을 명시적으로 고를 수 있습니다.

GiftGenius의 플로우를 설계할 때, 개념적으로 중요한 점은 다음과 같습니다:

• 누군가는 카탈로그를 통해 들어와 곧바로 App “안”에 있게 됩니다.
• 또 누군가는 카탈로그를 전혀 보지 않고, 대화 속 제안으로만 App을 접합니다.

이 모든 것이 App 자체의 디스커버리입니다: 현재 대화에서 모델이 여러분의 앱을 “올릴”지, 그리고 사용자에게 제안할지 판단하는 순간들 말이죠.

4. 상호작용 사이클의 해부: 문장에서 위젯까지

이전 강의의 모든 레벨 — ChatGPT UI와 위젯에서 Apps SDK와 MCP‑서버까지 — 을 하나의 명확한 논리적 사이클로 묶어 봅시다.

상위 수준 개요

프로세스 관점에서, 사이클은 다음과 같습니다:

sequenceDiagram
    participant U as 사용자
    participant G as ChatGPT (모델)
    participant A as App / MCP 서버

    U->>G: 텍스트 요청
    G->>G: 요청 분석 + 도구 선택
    G->>A: 도구 호출 (call_tool)
    A-->>G: 응답(데이터 / structuredContent)
    G->>U: 텍스트 답변 + (선택) 앱 위젯

쉽게 말해:

1. 사용자가 ChatGPT에 메시지를 씁니다.
2. 모델이 요청과 현재 컨텍스트를 분석하고, 다음을 결정합니다:
   • 스스로 답변할지,
   • 혹은 하나 이상의 도구를 호출할지.
3. 여러분 App의 도구가 선택되면, ChatGPT는 구조화된 요청 (call_tool)을 만들어 MCP‑서버로 보냅니다.
4. 여러분의 백엔드(또는 MCP‑서버)가 동작을 수행합니다: 데이터베이스, 외부 API, ACP 등을 호출하고 결과를 구성합니다.
5. 결과는 구조화된 데이터(그리고 경우에 따라 위젯용 JSON)로 돌아옵니다.
6. 모델은 이 데이터를 사용하여:
   • 사용자에게 이해하기 쉬운 텍스트를 생성하고,
   • 필요 시 — 답변 안에 App 위젯을 그립니다.

여러 단계의 계획 — “언제 무엇을 부를지”, “추가 질문을 할지”, “한 번 더 호출할지” — 는 AI 모델 쪽에 있습니다. Apps SDK와 MCP는 도구를 위한 통합 계약만 제공합니다.

우리는 어디에서 코드를 쓸까

이 사이클에서 실제로 TypeScript/코드를 작성하는 지점은 세 곳입니다:

1. App 및 도구 구성 — 도구의 설명(이름, 설명, 스키마)과 App 메타데이터(이름, 아이콘, 카테고리). 프로젝트에서는 아마 openai/app-config.ts 같은 파일일 것입니다.
2. MCP‑서버 / 백엔드 — call_tool 처리: DB 조회, 상품 필터링, 다른 API 호출 등.
3. 위젯(UI) — Next.js 앱의 React 컴포넌트로, 채팅에 렌더링되며 window.openai 또는 Apps SDK 훅을 통해 도구 결과를 읽습니다.

그 외의 모든 일은 모델과 플랫폼이 담당합니다.

5. GiftGenius 작동 방식: 두 가지 사용자 플로우 시나리오

플로우를 “눈으로 볼 수 있도록” 좀 더 구체적인 시나리오로 넘어가 봅시다.

시나리오 1: 사용자가 GiftGenius를 명시적으로 연다

시나리오:

1. 사용자가 ChatGPT에서 App 카탈로그를 열어 GiftGenius를 찾습니다.
2. “열기”를 누릅니다.
3. ChatGPT는 이미 해당 컨텍스트인 GiftGenius로 대화를 시작합니다.

대화는 대략 이렇습니다:

사용자:

카탈로그에서 GiftGenius를 엽니다.
그리고 씁니다: “안녕! 친구 선물 좀 고르고 싶어.”

GPT:

“좋아요, 선물 고르기를 도와드릴게요. 누구에게, 예산은 어느 정도이며, 무슨 일로 선물을 찾으시나요?”

이 단계에서 GPT는 첫 번째 도구를 바로 호출할 수 있습니다. 예를 들어 start_gift_session을 호출해 여러분의 백엔드에서 세션을 초기화(임시 장바구니 생성, sessionId 발급 등)합니다.

MCP‑서버 쪽의 코드는 대략 이렇게 생겼을 수 있습니다(아주 개략적으로):

// 의사 예시 future-TS: GiftGenius 도구 설명
const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this when the user wants gift ideas by recipient, occasion and budget",
  inputSchema: {
    type: "object",
    properties: {
      recipient: { type: "string" },
      occasion: { type: "string" },
      budgetUsd: { type: "number" },
    },
    required: ["recipient", "occasion", "budgetUsd"],
  },
};
    

MCP/Apps SDK에 어떻게 등록하는지는 별도 모듈에서 자세히 다루겠습니다. 지금 중요한 아이디어는 이것입니다: 이 설명을 바탕으로 모델은 이 도구가 “선물 추천” 요청에 적합하다는 걸 이해합니다.

사용자가 답한 뒤 GPT는 suggest_gifts를 호출해 여러분으로부터 후보 배열을 받고, 그 다음:

• 텍스트로 요약을 구성하고,
• GiftGenius 위젯을 삽입하여 선물 카드를 넘겨보고 필터링할 수 있게 합니다.

시나리오 2: 사용자가 일반 채팅에서 “선물 추천해줘”라고 말할 때

이번에는 다른 경우: 사용자는 GiftGenius를 전혀 모릅니다.

일반 채팅에 씁니다:

“형에게 줄 선물이 필요해. 보드게임을 정말 좋아해. 예산은 최대 50달러.”

ChatGPT 내부에서는 대략 다음이 일어납니다:

1. 모델이 요청과 사용 가능한 도구 목록을 분석합니다.
2. suggest_gifts라는 적절한 설명의 도구가 있음을 확인합니다.
3. GiftGenius가 바로 이런 작업을 위한 App임을 파악합니다.
4. 사용자가 이미 이 앱을 설치/연결했는지, 인증했는지, 어떤 퍼미션을 허용했는지 확인합니다.

이후 동작은 상황에 따라 달라질 수 있습니다:

• 요청이 충분히 구체적이면, GPT가 조용히 suggest_gifts를 호출하고 위젯과 함께 응답할 수 있습니다.
• 무언가 부족하다면(예: 계기나 나이 미기재), GPT가 먼저 텍스트로 확인 질문을 한 뒤 App을 제안할 수 있습니다.

이러한 유연성이야말로 “딱딱한” 폼 기반 UI와 다른 점입니다. 모델이 스스로 언제 도구를 쓰고, 언제 대화를 이어갈지 선택합니다.

6. 시맨틱 라우팅: “LLM은 디스패처”

디스커버리 단계에서 모델은 현재 요청에 여러분의 App을 연결할지 여부를 결정합니다. 그 다음, App이 이미 “올라왔고” 그 도구들이 현재 세션에서 모델에게 알려진 상태라면, 두 번째 단계 — 바로 이 도구들 안에서의 시맨틱 라우팅이 켜집니다: 이번 발화를 정확히 어떤 도구로 처리할 것인가.

전통적인 웹 백엔드에서는 URL로 라우트를 고릅니다: /checkout이면 checkout 컨트롤러를 호출하죠. ChatGPT Apps에는 URL‑기반 라우팅이 없지만, 시맨틱 라우팅이 있습니다: 모델이 요청의 의미와 도구 설명을 대조합니다.

간단히 말하면 프로세스는 이렇습니다:

1. 세션 시작 시 ChatGPT는 도구 목록(이름, 설명, 스키마)을 받습니다.
2. 이 데이터가 모델의 시스템 지침에 삽입됩니다.
3. 사용자가 요청을 쓰면, 모델은 그 의미를 도구 설명과 비교합니다: 어디가 “선물 추천”, 어디가 “호텔 검색”, 어디가 “차트 생성”인지요.
4. 좋은 일치 항목을 찾으면 — 해당 도구의 구조화된 호출을 생성합니다.

여기서 나오는 가장 중요한 실무적 결론:

• 도구 설명이 곧 모델을 위한 여러분의 API입니다. 한 번 더 읽어 보세요. 그리고 또 읽으세요.
• “does stuff” 같은 설명을 쓰면, 모델은 정말로 언제 호출해야 할지 모릅니다.

디스커버리 관련 문서와 베스트 프랙티스는 강조합니다: 메타데이터는 제품 카피라이팅 작업처럼 다뤄야 합니다. 그것들이 바로 어떤 대화에서 모델이 여러분의 App을 떠올릴지를 결정하기 때문입니다.

7. App을 둘러싼 대화 패턴

이제 GPT가 한 대화 안에서 App과 상호작용할 때 나타나는 전형적 UX 패턴을 살펴봅시다. 이걸 알아야 GPT 파트를 이해하지 못한 채 “진공 상태의 App”을 만들지 않게 됩니다.

Apps SDK의 실전 가이드는 몇 가지 특징적 패턴을 구분합니다:

“마법사” (The Wizard)

GPT가 사용자를 단계별로 이끕니다. 종종 App에 의존합니다.

GiftGenius 예시:

1. GPT: “선물을 누구에게 드리나요?”
2. 사용자: “남동생, 25살, 보드게임을 좋아해요.”
3. GPT: “예산은요?”
4. 사용자: “최대 50$.”
5. GPT가 suggest_gifts를 호출해 결과를 위젯으로 보여주고, “몇 가지 후보를 골라봤어요. 아래 목록을 확인해 보세요.”라고 씁니다.

이 패턴에서 App과 그 위젯은 다단계 대화 위의 시각적 레이어 같은 존재입니다. 사용자는 대부분 텍스트로 대화하고, 위젯은 선택지를 시각화해 돕습니다.

“적응형 위젯” (The Adaptive Widget)

텍스트가 기본 채널이고, App은 특수 작업에 점적으로 연결됩니다: 차트를 그리거나, 표를 보여주거나, 상품 카드를 렌더링하는 식이죠.

예:

• 사용자: “선물 세 가지 옵션(보드게임, 책, 경험형 선물)을 비교해줘.”
• GPT가 먼저 장단점을 텍스트로 설명합니다.
• 그다음 도구를 호출해 구조화된 상품 리스트를 받아 작은 표나 카드로 렌더링합니다.

여기서 App은 기본 모드가 아니라 시각적 보조 수단입니다.

“보이지 않는 에이전트” (Invisible Agent)

App이 UI를 전혀 보여주지 않을 수도 있습니다. 데이터 소스로 “후드 아래”에서만 동작합니다:

• 여러분은 자체 DB에서 선물을 찾는 MCP‑tool을 구현합니다.
• GPT가 이를 호출해 리스트를 받고, 위젯 없이 결과를 텍스트로 요약해 전달합니다.

이는 전형적인 “UI 없는 플러그인”과 비슷합니다. 사용자는 GPT가 최신 가격과 재고를 “알고 있다”는 사실만 보게 됩니다.

이런 패턴은 UI가 필수적이지 않은 tool‑first App에 유용합니다.

8. 플로우가 App 디자인에 미치는 영향

플로우를 이해하는 것은 철학만이 아니라 매우 실용적인 결정에 중요합니다: 어떤 도구를 만들지, 어떻게 설명할지, 언제 위젯을 보여줄지, 언제 텍스트로 답변하는 편이 나은지 등.

“chat‑first” 원칙

에코시스템의 핵심 아이디어: 채팅이 상호작용의 주 채널이고, UI 컴포넌트는 보조입니다.

이는 곧 다음을 의미합니다:

• “웹사이트 전체”를 하나의 위젯에 욱여넣으려 하지 마세요.
• 위젯은 채팅이 불편한 지점 — 목록 선택, 필터링, 비교, 복잡한 폼 — 에서 도움을 줘야 합니다.

GiftGenius의 경우:

• 선물 후보 리스트를 만들고, 사용자가 카드들을 “눌러 볼” 수 있게 하며,
• 필터(가격, 카테고리, 재고)를 시각화하고,
• 체크아웃을 몇 단계로 쉽게 돕는 것입니다.

반대로 “내성적인 여자친구를 위한 선물 고르는 법” 같은 긴 설명을 위젯에 적는 것은 좋은 생각이 아닙니다. 그런 건 채팅의 역할입니다.

언제 App을 실행하고, 언제 실행하지 말아야 할까

또 하나의 시사점: App을 “대화 납치범”으로 만들지 마세요.

나쁜 패턴:

• 사용자가 진지한 토론을 이어가는 중이고,
• App이 실행되어 거대한 전체 화면 위젯을 예고 없이 띄우며,
• 사용자가 혼란스러워합니다: “내 채팅은 어디 갔지?”

더 나은 방식:

• 우선 텍스트로 논의를 하고, 확인 질문을 몇 개 던진 뒤,
• 정말 UX가 좋아지는 경우에만 부드럽게 App 열기를 제안하세요(비교, 구성, 체크아웃).

도구 세트에 대한 영향

모델은 설명을 기준으로 도구를 고르기 때문에, 각 도구는 다음을 만족해야 합니다:

• 하나의 명확한 과제를 해결하고,
• “Use this when…” 스타일로 잘 설명되어 있어야 하며,
• 파라미터는 GPT가 사용자에게 물어볼 자연스러운 질문에서 바로 도출될 수 있어야 합니다.

GiftGenius에서는 하나의 거대한 do_everything 대신 다음처럼 구성하는 것이 합리적입니다:

• suggest_gifts — 후보 리스트 추천,
• get_gift_details — 특정 ID의 상세 정보,
• create_order — 주문 생성.

도구 디자인은 4번째 모듈에서 더 자세히 다루겠지만, 지금도 중요한 일반 원칙은 이겁니다: 대화 플로우가 어떤 도구가 필요한지를 결정한다.

9. 미니 예제: 도구 설명이 플로우에 미치는 영향 (TypeScript 스케치)

가상의 openai/app-config.ts 조각입니다. 이론과 코드를 연결하기 위한 것이고, SDK의 정확한 문법은 아닙니다(다음 모듈에서 다룹니다). 지금은 이름과 설명의 아이디어가 중요합니다.

// GiftGenius 구성의 가상 조각(향후 코드)
const tools = [
  {
    name: "suggest_gifts",
    description: "Use this when the user wants gift ideas based on recipient, occasion, and budget.",
    inputSchema: {/* ... */},
  },
  {
    name: "get_gift_details",
    description: "Use this when the user asks for more information about a specific gift from a previous list.",
    inputSchema: {/* ... */},
  },
];

만약 여러분이 suggest_gifts를 run_func로 바꾸고 설명을 “Main function”으로 바꾼다면, GPT는:

• 이 도구를 어떤 요청에서 호출해야 하는지 더 모호하게 이해하고,
• in‑conversation discovery에서 여러분의 App을 덜 제안하며,
• 사용자의 후속 질문을 기존 선물 리스트와 연결하기가 더 어려워질 수 있습니다.

반대로 좋은 이름과 설명은 바로 그 순간에 여러분의 App이 떠오를 확률을 높여 줍니다.

10. 사용자 플로우 설계에서 흔한 실수

오류 №1: 완전한 제어를 기대 — “언제 App을 실행할지 내가 결정한다”.
개발자들이 “선물 관련 요청을 내가 다 가로채서 내 App을 붙이겠다”는 패러다임으로 생각하는 경우가 있습니다. ChatGPT Apps 세계에서는 그렇지 않습니다. 결정을 내리는 주체는 모델입니다. 도구 설명, 대화 컨텍스트, 퍼미션 상태, 그리고 사용자가 바로 여러분 App 호출에 만족할지 여부 등을 고려합니다.

오류 №2: 의미 없는 도구 이름과 설명.
run, main, tool1 같은 이름과 “Calls the main function” 같은 설명은 최악의 폭풍을 만듭니다: 모델은 언제 호출해야 할지 이해하지 못하고, in‑conversation discovery는 거의 작동하지 않으며, 여러분의 App은 “보이지 않게” 됩니다. “Use this when the user wants…” 스타일의 좋은 설명과 명확한 이름이 생각보다 훨씬 중요합니다.

오류 №3: 하나의 App에 “세상 모든 것”을 우겨 넣기.
여러분의 App이 “선물 추천, 호텔 예약, 세금 계산, 고양이 사진 출력”을 동시에 한다면, 모델은 요청을 안정적으로 라우팅할 수 없습니다. 공식 권고와 실전 가이드는 “one clear job per tool/App” 원칙을 강조합니다. 하나의 메가모놀리스틱 앱보다, 여러 개의 전문화된 앱이 낫습니다.

오류 №4: 무리한 자동 실행의 무거운 UI.
멋진 전체 화면 위젯이 자랑스러워 “아무 때나” 보여주고 싶어질 수 있습니다. 그 결과 사용자는 채팅이 “망가져서” 이상한 웹앱이 되었다고 느낍니다. 훨씬 좋은 방식은 GPT가 먼저 텍스트로 대화하고, 확인 질문을 한 뒤, 왜 필요한지 설명하며 App 열기를 제안하는 것입니다.

오류 №5: UX 레이어로서의 GPT 역할을 무시.
일반 SPA처럼 App을 설계해서: 모든 걸 위젯에서 하고, ChatGPT는 “조용히 있으라”고 기대할 수도 있습니다. 하지만 그렇게는 작동하지 않습니다. ChatGPT는 여러분의 위젯을 표시하지 않을 수도 있고, 도구 호출마다 새로운 위젯을 표시할 수도 있습니다. 성공적인 제품을 원한다면 — 플랫폼에 맞추세요. 플랫폼이 여러분에게 맞춰줄 것이라 기대하지 마세요.