OpenAI의 UX‑가이드라인: 언제 App을 보여주고 어떻게 대화를 “장악”하지 않을 것인가

1. Chat‑first: ChatGPT — 우선은 채팅, 그다음이 애플리케이션

처음 6개 모듈 동안 우리는 앱의 모든 측면—UI와 MCP부터 디버깅과 배포까지—을 다뤘습니다. 이제 모든 면을 다시, 더 깊이 살펴봅니다. 모든 게 그렇게 간단할 거라고 생각하진 않으셨죠?

시작은 UX입니다. 정확히는 공식 UI 요구 사항과 UX 가이드라인부터. 여러분의 앱이 review를 통과하길 원하시죠? 좋습니다. 그럼 SPA/Next.js에 익숙한 프런트엔드 개발자에게 필요한 가장 중요한 마인드셋 전환부터 시작하죠: ChatGPT는 무엇보다 대화형 인터페이스이고, App은 그 대화 안의 손님입니다. 그 반대가 아닙니다.

OpenAI의 가이드라인은 이렇게 말합니다: 애플리케이션은 사용자가 할 수 있는 일을 확장하지만, 대화의 흐름을 깨지 않습니다. 위젯은 새로운 브라우저 탭이 아니라, 텍스트만으로는 버거운 지점을 깔끔하게 보완하는 채팅 내 삽입물입니다.

역할 분리로 기억하는 게 가장 쉽습니다.

GPT와 App의 역할

ChatGPT 안에는 두 “등장인물”이 있습니다:

GPT는 여전히 주요 해설자입니다. 왜 App을 제안하는지, 지금 무엇이 일어날지, 버튼의 의미가 무엇인지 말로 설명하고, 위젯의 결과를 정리합니다. 반대로 App은 시각과 액션에 집중합니다: 옵션 선택, 필터 설정, 마법사 단계 진행 등.

계속해서 되뇌어야 하는 매우 중요한 규칙: 중요한 결정은 사용자가 UI를 클릭하더라도 GPT의 텍스트 답변으로 명시해야 합니다. 사용자가 위젯 UI의 모든 줄을 읽어야 할 의무는 없습니다 — 핵심 결과(예: “주문을 완료했습니다” 또는 “다음과 같은 매개변수를 선택하셨습니다”)는 채팅에서 말해줘야 합니다.

2. 언제 App이 진짜로 필요한가: 표시 기준

기술적으로는 매 메시지마다 위젯을 호출할 수 있습니다. 하지만 UX 관점에선 — 마치 input에 글자를 하나 입력할 때마다 전체 화면 대화 상자를 띄우는 것과 같습니다. 동작은 합니다. 그렇지만 편안하진 않습니다.

OpenAI와 Apps SDK는 간단한 원칙을 제안합니다: App은 텍스트만으로 생각하는 것보다 그것과 함께일 때 더 쉽다면 적절합니다.

구조와 반복 가능한 시나리오가 있는 요청

App은 사용자 요청 자체가 이미 구조를 암시할 때 특히 잘 맞습니다:

• “직장 동료를 위한 선물 5가지를 $50 이내로 골라줘.”
• “이 세 가지 요금제를 비교해줘.”
• “도쿄 3일 여행 코스를 만들어줘.”
• “이번 주 내 할 일 목록을 보여주고 우선순위를 정하는 걸 도와줘.”

이런 경우엔 조작해야 할 명확한 엔티티(선물, 요금제, 여행 일자, 할 일)와 단계가 있습니다: 선택, 필터링, 비교, 확인. 카드, 체크박스, 필터가 있는 UI는 여기서 정당하고 심지어 구원입니다.

GiftGenius 예시

우리의 단골 주인공 GiftGenius를 가져와 봅시다. 전형적인 요청은 이렇습니다:

결혼식 하객 10명을 위한 선물을 골라야 해요. 각자 예산과 관심사가 달라요.

GPT가 순수 텍스트로 10개의 개별 목록을 나열할 수도 있지만, 읽기 고통스럽습니다. 훨씬 낫죠:

• 하객, 예산, 관심사를 표로 보여주고,
• “더 저렴하게/더 비싸게” 같은 필터를 제공하고,
• 각 하객별 카드 묶음을 출력하는 것.

여기서는 App이 사실상 필수입니다. 엔티티와 파라미터가 너무 많아서 텍스트만으로 처리하기 어렵습니다.

반대로 이런 경우는 어떨까요:

형제에게 줄 선물로 5000 ₽ 정도면 뭐가 좋을까?

이건 한 단계의 작은 질문입니다. GPT는 3–5개의 아이디어를 텍스트로 답할 수 있고, 사용자가 “취미와 나이로 필터링할 수 있게 옵션을 보여줘”라고 요청할 때만 부드럽게 App으로 넘어가면 됩니다.

미니 휴리스틱

머릿속에 두면 좋은 간단한 표:

인라인과 풀스크린은 다음 강의에서 자세히 다루겠지만, 벌써 보이듯 App은 구조적이고 다단계인 과제를 위한 도구이지, 모든 “우울한데 어떡하죠?”에 쓸 도구는 아닙니다.

3. 언제 App이 방해가 되는가: “대화하기” 모드와 사색

어떤 경우에 App이 삶을 단순화하고 대화 구조를 돕는지 살펴봤습니다. 하지만 동전의 양면처럼, 어떤 상황에서는 어떤 UI도 오히려 방해만 됩니다.

“UI를 그려보자”는 이야기가 많다 보면 “오, 사용자가 뭔가 물었네 — 위젯을 켜자”라는 반사신경이 생기곤 합니다. 바로 이 지점에서 Store 리뷰에서 UX 감점을 받을 수 있습니다.

App이 대개 해가 되는 요청 유형이 있습니다:

1. 사용자가 “대화하기” 모드일 때. 철학적 사색, 개인사, 커리어 고민, 치료적 대화 등. 이런 시나리오에서 사용자는 텍스트 기반 대화, 추가 질문, 때론 공감을 기대합니다. 카드와 필터를 끼워 넣으면 스팸 배너처럼 느껴집니다.
2. 서비스에 대한 도입 질문. “GiftGenius가 무엇을 할 수 있어?”라고 쓰면, 당장은 UI가 아니라 개요를 원합니다. 여기서 GPT는 먼저 App의 목적을 짧게 설명하고, 예시 요청을 제시한 뒤, 마지막에 조심스럽게 위젯 사용을 제안하는 편이 낫습니다.
3. 일반 이론 질문. “내향적인 사람에게 선물을 고르는 방법은?” 또는 “매장의 로열티 시스템은 어떻게 작동해?” 같은 건 학습 시나리오지 트랜잭션 시나리오가 아닙니다. GPT가 좋은 텍스트 답을 주고, 끝에 가볍게 덧붙이면 충분합니다: “원하시면 GiftGenius를 열어 몇 가지 구체적인 옵션을 골라 드릴 수 있어요.”

UI가 새로운 가치를 주지 않고 텍스트를 복제하기만 하는 곳에선 그냥 채팅에 머무르세요. 이것이 UX 구루들이 좋아하는, 사용자 의도를 존중하는 태도입니다.

4. App을 제안하는 법: auto‑launch 대 “겸손한 전달”

App이 적절하다고 확신하더라도 “어떻게 시작할 것인가”는 별개의 문제입니다. 서툰 방식: 예고 없이 위젯이 갑자기 풀스크린으로 열림. 괜찮은 방식: GPT가 먼저 말로 설명하고, 동의를 묻거나 최소한 고지합니다.

UX 문서에서 ChatGPT Apps는 두 가지 패턴을 구분합니다: auto‑launch와 suggestion (humble handoff).

Auto‑launch: 사용자가 명시적으로 요청했을 때

Auto‑launch는 사용자가 명시적 의도를 보였을 때 적절합니다:

GiftGenius를 실행해줘.
GiftGenius 설정을 열어줘.
GiftGenius에서 내 선물 장바구니를 보여줘.

여기서 규칙은 간단합니다:

1. GPT가 짧게 “GiftGenius를 여는 중…” 같은 말을 합니다.
2. 모델이 즉시 도구/위젯을 호출합니다.

대화는 이렇게 보일 수 있습니다:

사용자: GiftGenius를 실행해줘, 친구 선물을 고르고 싶어.
GPT: 선물 고르기를 위해 GiftGenius 도우미를 엽니다.
[GiftGenius 위젯이 인라인 또는 풀스크린으로 나타남]

사용자가 “열어줘”라고 직접 요청했기 때문에 불필요한 추가 확인 없이 자동 실행이 정당화됩니다.

Suggestion (humble handoff): 의도가 암시적일 때

많은 경우 사용자는 여러분의 앱을 아예 모릅니다. 그는 이렇게 씁니다:

직장 동료 생일 선물로 뭐가 좋을지 고민 중인데, 예산은 크지 않아요.

올바른 패턴은 다음과 같습니다:

1. GPT가 요청을 분석해 App이 도움이 될 수 있음을 파악합니다.
2. GPT가 1–2개의 추가 질문을 하거나, 텍스트로 App을 제안합니다.
3. 동의 또는 명확한 시사가 있는 경우에만 위젯을 실행합니다.

예시:

사용자: 직장 동료 생일 선물로 뭐가 좋을지 고민 중인데, 예산은 크지 않아요.
GPT: 제가 아이디어를 바로 드릴 수도 있고, 예산과 관심사별로 옵션을 고를 수 있는 GiftGenius 앱을 열 수도 있어요. 그냥 조언을 듣고 싶으세요, 아니면 앱을 사용해 볼까요?
사용자: 앱으로 해보자.
GPT: 선물 옵션을 고르기 위해 GiftGenius를 엽니다.
[위젯이 나타남]

이 접근은 주도권이 여전히 사용자에게 있음을 강조합니다. App은 옵션이지 강제 배너가 아닙니다. 이는 UX 가이드라인의 “Respect user’s intent” 원칙과도 잘 맞습니다.

TypeScript로 만든 “의도 분류기” 미니 예제

백엔드 쪽에서 사용자 요청을 대략 분류한다고 가정해 봅시다(GPT 자체와 혼동 금지, 보조 로직입니다):

// 사용자 의도의 단순화된 타입
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// App에 어떤 트리거를 사용할지
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "GiftGenius를 실행해줘"
  if (intent === 'ask_gift_advice') return 'suggest'; // 암시적 요청
  return 'avoid';                                // 일반 채팅, App 없음
}

이 로직 자체가 위젯을 호출하진 않습니다 — 여러분의 UX 접근을 형식화하는 방법에 가깝습니다. 이후 이 규칙을 system‑prompt와 App 설명으로 옮겨 모델이 같은 철학으로 행동하게 합니다.

5. “대화를 장악하지 않기”: 좋은 패턴과 나쁜 패턴

ChatGPT Apps를 위한 OpenAI 문서와 UX 디자인 글들은 무엇을 하면 안 되는지 명확히 말합니다: 대화를 “훔치지” 마라. 즉, 채팅을 여러분 인터페이스 홍보 채널로 바꾸지 말라는 뜻입니다.

안티패턴

가장 아픈 것 — “깜짝‑위젯”. 사용자가 깊은 대화를 나누고 있는데, 요청한 적도 없는 풀스크린 앱이 갑자기 화면을 덮는 경우입니다. 맥락과 통제감이 날아갑니다.

또 다른 흔한 잘못 — App을 광고처럼 쓰는 것. 예컨대 사용자가 이론적 질문을 했는데, 모델이 “먼저 우리 슈퍼 위젯을 열게요. 거기에 다 써 있어요”라며 UI를 띄우고, 절반이 마케팅 문구인 경우입니다. 공식 가이드라인은 이런 시나리오를 “poor use cases”라고 명시합니다.

세 번째 안티패턴 — UI와 텍스트 사이를 불필요하게 자주 전환하는 것. 작은 추가 질문마다 App을 열고 닫으면, 대화는 반짝이는 전구처럼 깜빡입니다. 특히 모바일 사용자에게 금방 피로감을 줍니다.

모범 사례

그래도 App을 여는 모든 시나리오에서 지키면 좋은 세 가지 규칙이 있습니다.

첫째, 미리 알리기. GPT가 앱을 열려 한다는 점과 그 이유를 명확히 말하게 하세요. 예: “GiftGenius 도우미를 열어 카드 형태로 옵션을 보여드릴게요.” 이 1–2줄이 전환의 체감을 완전히 바꿉니다.

둘째, UI에서 무엇을 해야 하는지 설명하기. 모든 사용자가 새로운 인터페이스에 익숙한 것은 아닙니다. GPT가 “아래에서 선물 카드들을 보실 수 있어요. 페이지를 넘기고, 아무 옵션이나 ‘자세히 보기’를 눌러보세요.”처럼 텍스트를 덧붙일 수 있습니다. 위젯에 낯선 요소(예: “N개 더 보기” 또는 비표준 필터)가 있다면 말로 짚어 주는 편이 낫습니다.

셋째, 결과를 텍스트로 요약하기. App이 뭔가를 했으면(찾음, 계산함, 전송함) GPT가 짧게라도 말해 줘야 합니다: “선물 후보 3가지를 골랐어요. 처음 두 개는 $50 이내이고, 세 번째는 조금 비싸지만 배송이 빨라요. 더 좁혀 볼까요?” 모바일/보이스 환경에서는 특히 중요합니다. 사람은 UI를 보지 않아도 텍스트 요약은 들을 수 있으니까요.

6. UX를 좌우하는 system‑prompt와 App 설명의 역할

이미 system‑prompt가 App의 “페르소나”와 도구 사용을 규정한다는 걸 봤습니다. 여기에 UX 규칙을 추가합니다: 언제 App을 제안할지, 어떻게 알릴지, 언제는 자제할지.

system‑prompt에 무엇을 써야 하나

GiftGenius의 system‑prompt에는 “대화와 UX” 섹션을 넣을 수 있습니다. 문서와 글에서는 규칙을 구조화하여 별도 항목으로 기술하는 것을 권장합니다.

예시 조각(의사코드지만 현실과 매우 가깝습니다):

### 대화와 UX

1. 사용자가 선물 추천 조건(대상, 예산, 계기)을 제시하면,
   먼저 텍스트로 1–2개의 추가 질문을 하라.
2. 추가 질문 후 App GiftGenius를 여는 것을 제안하라:
   "선물 옵션을 카드 형태로 보여주는 GiftGenius 도우미를 열 수 있어요. 열까요?"
3. 사용자가 "GiftGenius를 실행해줘" 또는 "선물 목록을 보여줘"처럼 명시적으로 요청하면,
   "GiftGenius를 여는 중..."이라고 답하고 즉시 App을 호출하라.
4. 사용자가 이론이나 일반 조언을 요청(예: "선물을 고르는 방법")하면,
   텍스트로 답하고 사용자가 직접 요청하기 전에는 App을 열지 말라.
5. 사용자가 "앱을 열지 마" 또는 "그냥 텍스트로 답해줘"라고 말하면,
   그 대화에서는 이후에도 App 제안을 하지 말라.
6. App이 동작한 뒤에는 항상 결과를 텍스트로 간단히 요약하라.

여기에 우리의 UX 원칙이 응축되어 있습니다: chat‑first, 사용자의 거절 존중, auto‑launch와 suggest의 차이, 필수적인 텍스트 요약.

TypeScript 설정으로 스스로 돕는 방법

실제 프로젝트에서는 이 규칙의 일부를 구조화된 형태로 보관하면 편리합니다(나중에 프롬프트 텍스트를 수작업으로 찾지 않게). 예를 들어 간단한 설정을 둘 수 있습니다:

// App UX 트리거에 대한 가상의 설정 타입
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

이 설정을 모델이 직접 읽지는 않습니다 — 제품/디자인과 합의한 내용을 한 곳에 모아두고 이후 system‑prompt, App 설명, 문서에 깔끔히 반영하기 위해 개발자에게 필요한 도구입니다.

7. 예시: GPT가 GiftGenius를 어떻게 예고하고 대화를 가로채지 않는가

우리 앱과 연결해 봅시다. 사용자가 처음으로 채팅에 이렇게 쓴다고 가정해요:

직장 동료에게 줄 선물을 찾고 있어요. 대략 3000 ₽ 정도, 보드게임을 좋아해요.

우리의 system‑prompt를 고려한 좋은 모델의 답은 이렇게 보일 수 있습니다:

알겠습니다! 몇 가지를 더 확인한 뒤 아이디어를 추려볼게요.

나이는 대략 어느 정도인가요? 그리고 격식을 차리는 선물인지, 아니면 가까운 친구에게 주는 느낌인지도 알려주세요.

(답변을 주시면 GiftGenius 도우미를 열어 카드 형태로 옵션을 함께 살펴볼 수 있어요.)

추가 정보를 받은 뒤 GPT는 이렇게 씁니다:

좋아요, 필요한 정보가 충분합니다.

지금 GiftGenius 앱을 열어 몇 가지 선물 옵션을 카드 형태로 보여드릴게요. 세부 정보를 보고 예산과 게임 타입으로 선택을 좁힐 수 있습니다.

그리고 나서야 App을 실행합니다. “깜짝”은 없습니다. 모든 것이 말로 예고됩니다.

위젯 안의 작은 App “예고” React 컴포넌트

코드 관점에서 위젯은 대개 호출되면 그냥 렌더링됩니다. 그래도 이미 열려 있더라도 컨텍스트를 “가로채지 않겠다”는 철학을 UI에 녹일 수 있습니다.

예를 들어 GiftGenius의 첫 화면을 아주 단순하게 만들 수 있습니다:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        GiftGenius로 선물 고르기
      </h2>
      <p style={{ marginBottom: 12 }}>
        카드 형태로 몇 가지 옵션을 보여드릴게요. 마음에 드는 것을
        고르시면 ChatGPT가 장단점을 설명해 드립니다.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        언제든 일반 채팅으로 돌아가 대화를 계속할 수 있어요.
      </p>
    </section>
  );
}

이 컴포넌트는 기술적으로 “강력한” 일을 하지는 않지만, UX 관점에서 중요합니다. 채팅이 여전히 중심이며 GPT의 역할이 중심임을 상기시킵니다.

이 인트로 화면에서 선물 카드, 마법사 등으로 넘어가게 될 것이고, 이는 다음 강의의 주제입니다.

8. 실습과 연습

위에서 우리는 몇 가지 원칙—chat‑first, 사용자 의도 존중, auto‑launch와 App 제안의 구분—을 모았습니다. “언제, 어떻게 App을 보여줄지” 접근을 공고히 하려면 실제 요청을 생각해 보고, 어디서 App이 필요한지, 어디서는 아닌지를 명시적으로 나눠보는 것이 좋습니다. 숙제로 두 가지 작은 연습을 해볼 수 있습니다.

먼저 GiftGenius를 대상으로 5–7개의 사용자 요청을 만들어 보세요. 각 요청에 대해 스스로 솔직하게 답해 보세요:

• 여기서는 바로 App 열기를 제안해야 하는가;
• App을 옵션으로만 언급해야 하는가;
• 아니면 아예 App과 연결하지 않는 편이 나은가.

예를 들어:

1. “결혼기념일에 아내에게 줄 선물, 예산은 $1000 이하” — 아마도 먼저 텍스트로 몇 가지 추가 질문을 한 다음 App 열기를 제안.
2. “선물을 독창적으로 포장하는 방법은?” — 순수 이론 질문, App 없이도 충분.
3. “GiftGenius를 실행해줘, 팀 전체 선물을 고르고 싶어” — 직접적인 auto‑launch.

두 번째 연습 — App 시작을 예고하는 텍스트입니다. GPT가 사용자의 App으로의 전환을 설명할 때 쓰게 될 1–2개의 짧은 문장을 작성해 보세요. 톤을 비교해 보세요: 좀 더 포멀한(“GiftGenius 앱을 엽니다…”) 것과 좀 더 친근한(“GiftGenius 도우미로 가볼까요 — 이렇게 하면 옵션을 비교하기 쉬워요”) 것.

이렇게 하면 개발자뿐 아니라 대화의 작가처럼 사고하는 법도 배우게 됩니다.

9. “언제 App을 보여줄지” UX에서 흔한 실수

오류 1: 주제를 언급했다는 이유만으로 App을 보여주기.
흔한 극단입니다: App이 선물과 관련되어 있다고 해서 대화에 “선물”이라는 단어가 나오면 즉시 위젯을 트리거합니다. 사용자는 “상사 선물로 민폐 끼치지 않으려면?”이라고 묻는데, 살아 있는 조언 대신 카드를 보여주는 UI를 받습니다. 이는 광고처럼 느껴지고 사용자 의도를 무시합니다. 공식 UX 가이드라인과 “Respect user’s intent” 원칙에 정면으로 배치됩니다.

오류 2: 예고 없는 풀스크린.
갑자기 화면을 차지하는 “깜짝‑위젯”은 인상을 망치는 확실한 방법입니다. 특히 장문의 대화 중 텍스트에서 UI로의 급격한 전환은 더 안 좋습니다. OpenAI 가이드라인에 따르면 이런 시나리오는 나쁜 관행으로 간주됩니다. 전환을 항상 예고하고 가능하면 동의를 구해야 합니다.

오류 3: 답변 대신 UI.
가끔 App 제작자는 “텍스트로 답할 필요가 있나, 멋진 인터페이스가 있는데!”라고 생각합니다. 그 결과 GPT는 거의 말하지 않고, 모든 “답”이 위젯 안에 숨어 버립니다. 사용자, 특히 보이스/모바일 모드에서는 중요한 디테일을 놓칠 수 있습니다. 올바른 접근은 UI가 답변을 보완한다는 것입니다. App이 세부와 옵션을 보여주고, GPT가 그 의미를 설명합니다.

오류 4: 사용자의 App 거절을 무시.
사람이 명시적으로 “앱 열지 마” 또는 “그냥 텍스트로”라고 하면, 그 대화가 끝날 때까지 App은 이를 엄격한 규칙으로 받아들여야 합니다. 두 메시지마다 App을 계속 제안하는 건 집요한 “서비스를 평가해 주세요” 팝업과 같습니다. 이런 것들은 UX를 악화시키고 Store 리뷰에도 영향을 줄 수 있습니다. system‑prompt에 거절 존중을 명시적으로 넣어야 합니다.

오류 5: auto‑launch와 “제안”의 구분 없음.
명시적/암시적 의도를 구분하지 못하면, 사용자가 분명히 요청했는데도 App을 절대 실행하지 않거나, 반대로 “언젠가 써볼 수도”라는 말만 했는데도 항상 실행해 버립니다. 그러다 보면 단어가 비슷하다는 이유로 자동 실행이 벌어집니다. 트리거를 (auto / suggest / avoid)로 형식화하고 system‑prompt의 논리를 잘 설계하면 이런 혼선을 피할 수 있습니다.

오류 6: system‑prompt에 UX 규칙이 전혀 없음.
가끔 모든 UX 결정이 “팀의 머릿속”에만 있고, system‑prompt는 “너는 GiftGenius 어시스턴트다. 선물 고르기를 도와라.”로 끝입니다. 그러면 모델은 어떤 때는 App을 제안하고, 어떤 때는 잊고, 어떤 때는 부적절한 순간에 엽니다. 구조화된 UX 규칙을 system‑prompt와 문서에 기록하는 것은 도구의 JSON 스키마만큼 중요한 산출물입니다.

오류 7: “나중에 UX 붙이기”.
흔한 접근 — 일단 “돌아가게” 만들고, 언젠가 UX를 생각하자는 것. ChatGPT Apps에서는 이미 특정 도구 호출 패턴에 묶이기 쉽고, 나중에 system‑prompt와 GPT 행동을 바꾸기 어려워집니다. 최소한의 UX 가이드라인—chat‑first, 거절 존중, App 표시의 명확한 기준, “깜짝‑위젯” 금지—은 처음부터 깔아두는 편이 낫습니다. 그러면 이후 인라인 패턴, 풀스크린, 보이스 등 모든 발전이 탄탄한 기반 위에서 이루어집니다.