Voice / Realtime 컨텍스트: 음성 대화에서 App의 동작

1. 맥락: ChatGPT App에서 “음성 모드”가 의미하는 것

먼저 ChatGPT Apps SDK의 범위에서, 여러분은 자체 오디오 클라이언트를 작성하지 않고, 마이크를 제어하지 않으며, 오디오를 직접 스트리밍하지 않는다는 점이 중요합니다. 이 역할은 ChatGPT 클라이언트(웹 또는 모바일 앱)가 담당합니다.

이미 위젯, callTool, GiftGenius에 대한 기본 이해가 있다고 가정합니다 — 여기서는 같은 요소를 음성 모드의 관점에서 살펴봅니다.

개발자인 여러분의 관점에서 App은 다음과 같이 보입니다.

• 사용자는 마이크에 대고 말합니다. ChatGPT 클라이언트가 음성을 인식하고, 모델에는 이미 텍스트로 전달됩니다.
• 스트림에서는 사용자가 타이핑했다면 보게 될 것과 동일한 내용을 “봅니다”. 다만 더 빠르게, 더 대화체로 도착합니다.
• 모델은 텍스트로 응답하고, 클라이언트가 이를 음성으로 읽어 줍니다.
• 동시에 모델은 여러분의 도구(callTool)를 호출하고, 위젯의 displayMode를 바꾸고, widgetState를 업데이트하며, 텍스트 모드와 동일하게 후속 제안(follow‑up)을 제공합니다.

핵심적인 차이는 사용자가 화면을 거의 보지 않거나, 휴대폰을 잠깐 흘끗 보기만 할 수 있다는 점입니다. 즉, 여러분의 UI는 상호작용의 주 채널이 아니라 음성의 보조가 됩니다. 그 반대가 아닙니다.

여기서 두 가지 결과가 나옵니다.

• 진짜 중요한 것은 GPT의 발화만으로 이해 가능해야 합니다.
• 위젯은 좋은 의미에서 “한눈에 파악 가능한” 상태여야 합니다. 흘끗 보기만 해도 상태와 핵심 선택지가 바로 드러나야 하며, 작은 글을 읽게 만들지 않아야 합니다.

우리의 GiftGenius에 바로 적용하면, “차에서 이동 중, 엄마 선물 골라줘” 시나리오는 단순한 텍스트 채팅이 아닙니다. 음성이 주도하고, UI가 안전망이 되는 멀티모달 대화입니다.

2. voice 시나리오가 텍스트와 다른 점

“같은 거고, 다만 사용자가 말하기만 할 뿐이야”라는 함정에 빠지지 않으려면, 여러 축에서 텍스트 모드와 음성 모드를 비교하는 것이 유용합니다.

여기서 몇 가지 중요한 결론이 나옵니다.

• 사용자가 “카드에서 읽어낼 것”이라고 기대하면 안 됩니다. 중요한 내용은 반드시 말로 알려야 합니다: 무엇을 이해했고, 무엇을 하려 하며, 어떤 결과를 얻었는지.
• UI는 “1초 훑어보기”를 견뎌야 합니다. 상태, 진행도, 핵심 선택은 모두 큰 글씨로 눈에 띄게. 세부는 2순위입니다.
• 공백을 메워야 합니다. MCP 서버가 무거운 요청을 처리 중일 때 모델은 무슨 일이 진행 중인지 음성으로 알리고, 위젯은 진행도를 보여주어, 어시스턴트가 멈춘 것 같은 느낌을 없애야 합니다.

음성 모드를 삽화가 있는 오디오북처럼 생각할 수 있습니다. 음성 내레이터(GPT)가 있고 그림(위젯)이 있습니다. 서로를 보완하도록 동기화해야지, 중복하거나 충돌하게 해서는 안 됩니다.

3. 음성 모드에서의 위젯 역할: “컨트롤 패널”에서 “전광판”으로

텍스트 시나리오에서 위젯은 종종 완전한 인터페이스 역할을 합니다: 폼, 표, 필터가 있는 캐러셀, 액션 버튼 등. 음성 모드에서는 역할이 바뀝니다. 멀티모달 인터페이스와 VUI 권장 사항은, 음성 시나리오에서 UI가 정보 전광판(glanceable UI)에 가깝다고 보여줍니다. 빠른 확인과 승인에 필요하지, 눈으로 빽빽하게 작업하는 용도는 아닙니다.

GiftGenius에서는 다음을 의미합니다.

사용자가 음성 마법사를 따라갈 때, inline 위젯 또는 전체 화면에서 다음을 표시합니다:

• 큰 상태 표시: “3단계 중 2단계: 예산과 선물 유형”.
• 최소한의 텍스트와 명확한 라벨: “예산 최대 50 달러”, “디지털 선물을 선호”.
• 음성 시나리오에서 클릭이 허용된다면, 크고 명확한 CTA 버튼 몇 개: “예산 변경”, “계속”.
• 여러 개의 잔잔한 인디케이터 대신, 단순한 progress bar 또는 stepper 하나.

음성 시나리오용 inline 위젯의 간단한 “전광판” 예시(TypeScript + React, 크게 단순화):

type VoiceUiMode = "default" | "voiceGlance";

interface GiftStepProps {
  step: number;
  totalSteps: number;
  summary: string; // 이미 수집된 내용의 요약
  uiMode: VoiceUiMode;
}

export function GiftVoiceStep(props: GiftStepProps) {
  const fontSize = props.uiMode === "voiceGlance" ? "text-lg" : "text-sm";

  return (
    <div className="rounded-xl border p-3 flex flex-col gap-2">
      <div className={`${fontSize} font-semibold`}>
        단계 {props.step}/{props.totalSteps}
      </div>
      <div className={`${fontSize} text-muted-foreground`}>
        {props.summary}
      </div>
    </div>
  );
}

여기에는 “음성 전용” 요소가 있는 것은 아니지만, uiMode가 === "voiceGlance"일 때 모든 것을 더 크고 단순하게 만드는 분명한 아이디어가 있습니다. 현재가 음성 모드라는 신호는 간접적 단서부터, 모델이 widgetState나 도구 응답에 명시적으로 플래그를 세우는 것까지 다양한 곳에서 올 수 있습니다.

4. 모달리티 동기화: GPT가 말하는 것과 App이 보여주는 것

Apps를 위한 voice‑UX의 핵심 원칙은 모달리티 동기화입니다. 음성과 시각적 UI는 동일한 이야기를 서로 다른 세부 수준으로 전달해야 합니다.

전형적인 실수는, 개발자가 모델로 하여금 위젯에 표시된 모든 것을 소리 내어 읽게 만드는 것입니다. 긴 선물 목록, 필터가 담긴 JSON 구조 등은 고통이 됩니다. 권장 사항은 이렇습니다: 음성은 간단한 요약을 제공하고, UI는 세부를 보여줍니다.

GiftGenius에 대한 올바른 동기화 예시.

사용자: “엄마 선물 골라줘. 정원 가꾸기를 좋아하시고, 예산은 50 달러까지.”

모델(음성): “몇 가지 옵션을 찾았어요. 제가 보기엔 가장 좋은 건 45 달러짜리 정원 도구 세트예요. 화면에는 이와 비슷한 항목 두 개를 더 보여드렸어요. 자세히 설명해 드릴까요, 아니면 바로 선택할까요?”

위젯(inline): 선물 카드 3개, 짧은 설명과 “선택” / “유사 항목 보기” CTA 버튼을 보여줍니다.

한 단계의 대화/JSON 풍 표현(실제 프로토콜이 아니라 사고를 돕기 위한 예시):

{
  "user": "엄마 선물 골라줘...",
  "assistant_text": "몇 가지 옵션을 찾았어요...",
  "widget": {
    "displayMode": "inline",
    "state": {
      "view": "gift_list",
      "items": [
        { "id": "g1", "title": "정원 도구 세트", "price": 45 },
        { "id": "g2", "title": "정원사 앞치마", "price": 30 },
        { "id": "g3", "title": "꽃 씨앗 세트", "price": 20 }
      ]
    }
  }
}

중요한 디테일: system‑prompt에서 모델이 UI를 어떻게 말로 설명해야 하는지 명시적으로 적을 수 있습니다. 예: “위젯에 옵션 목록을 보여줄 때는 각 항목을 모두 읽지 마. 최고의 항목을 간단히 설명하고, 나머지는 화면에 보인다고 말해.”

앞으로 Realtime API와 자체 voice 클라이언트로 작업하더라도 원칙은 같습니다. UI와 오디오 스트림은 일치해야 합니다. 차이는 스트리밍에 대한 직접 제어 여부뿐입니다.

5. Realtime과 지연(latency): 어색한 침묵을 피하는 법

기술적으로 tool_calls는 음성 모드에서도 텍스트와 동일합니다. 모델이 도구 호출을 결정하고, 여러분이 응답을 반환하며, 위젯이 갱신됩니다. 하지만 음성에서는 새로운 UX 문제 — 지연 — 이 생깁니다. MCP 서버가 외부 API를 호출하거나 복잡한 리포트를 계산하는 동안, 사용자는… 아무 것도 듣지 못합니다. 채팅에서 텍스트를 기다리는 것보다 훨씬 나쁘게 느껴집니다.

여기에는 두 층의 방어가 있습니다: 음성과 시각입니다.

• 음성 측면에서 system‑prompt는 모델이 “지금 작업 중”이라고 말하고, 도구가 아직 계산 중일 때 추가 질문을 던지는 것을 허용(권장)해야 합니다. 예: “지금 선물을 추려볼게요. 몇 초 정도 걸립니다. 그동안 추가 제약이 있으면 알려주세요.”
• 시각 측면에서 위젯은 진행도를 매우 명확히 보여야 합니다: 로더, “옵션을 찾는 중…” 같은 상태, 현재 단계 등. 그렇지 않으면 사용자는 멈춘 줄 알고 다시 말하기 시작해, 음성 흐름을 깨뜨립니다.

실제로는 지연된 작업으로 해결하는 것이 편합니다. 도구는 즉시 "pending" 상태와 jobId를 반환하고, 실제 검색은 백그라운드에서 진행합니다. 위젯은 "pending"에 맞춰 진행도를 표시하고, 음성은 “작업 중”임을 알립니다.

완료 결과를 기다리며 블로킹하지 않고, job‑id가 담긴 “플레이스홀더”를 반환하는 server‑side 도구의 가장 단순한 형태는 다음과 같습니다:

// GiftGenius server-side 도구의 의사코드
export async function startGiftSearch(params: SearchParams) {
  const jobId = await createBackgroundJob(params); // 작업을 큐에 넣음

  return {
    status: "pending",
    jobId,
    message: "선물 검색이 시작되었습니다"
  };
}

위젯은 status가 "pending"이면 UI를 진행 표시 모드로 전환할 수 있습니다:

if (toolOutput.status === "pending") {
  return (
    <div className="p-4 rounded-xl border flex items-center gap-3">
      <Spinner />
      <div className="text-base">
        선물 추천 중… 몇 초 정도 걸립니다.
      </div>
    </div>
  );
}

같은 tool‑output에 대해, 지시사항에 따라 모델도 비슷한 내용을 소리 내어 말하고, 필요하면 추가 질문을 합니다. 이후 백그라운드 작업이 완료되고, 예컨대 MCP‑notification으로 job.completed가 오면, 위젯은 선물 목록으로 갱신되고, 음성은 그 요약을 읽어 줍니다.

이렇게 하면 백엔드가 즉시 응답하지 않아도 realtime에 가까운 동작을 얻을 수 있습니다.

6. 음성 환경에서의 보안과 확인(confirmation)

음성 인터페이스는 결제, 데이터 삭제, 설정 변경처럼 크리티컬한 동작에서 매우 까다롭습니다. 음성 인식은 완벽하지 않고, 사용자는 이동 중에 말하며, “응”이 쉽게 “네, 구매해”로 오인될 수 있습니다. 그래서 음성 시나리오에서는 confirmation flow가 특히 중요합니다.

두 가지 기본 패턴이 있습니다.

• 명시적 음성 확인(Explicit Voice Confirmation). 위험한 동작에는 특정 문구를 요구합니다. 예: “구매를 확인하시려면 ‘구매를 확인합니다’라고 말해 주세요.” 그리고 system‑prompt에서 애매한 “응”, “오케이”, “가자” 같은 표현으로 결제를 수행하지 못하도록 금지합니다.
• 시각적 확인만(Visual Confirmation Only). 모델은 음성으로 동작을 안내합니다(“주문을 준비했어요. 화면에 최종 금액과 장바구니가 표시됩니다”), 하지만 실제 트리거는 위젯의 “결제” 버튼 클릭입니다. 상거래 시나리오에서 특히 적합하며, 14 모듈에서 다시 다룹니다.

GiftGenius에서는 다음처럼 보일 수 있습니다.

모델: “정원 가꾸기용 훌륭한 세트를 45 달러에 찾았어요. ChatGPT를 통해 구매를 진행할 수 있어요. 화면에 최종 가격과 배송 주소가 표시됩니다. 음성으로 확인하려면 ‘구매를 확인합니다’라고 말하시거나, 화면의 ‘결제’ 버튼을 누르세요.”

위젯(전체 화면): 최종 주문을 표시하고, 금액과 주소를 굵게 강조하며, 눈에 띄는 “결제”와 “취소” 버튼 두 개를 보여줍니다.

위젯 내부에서 확인 상태를 반영할 수 있습니다:

type CheckoutState = "review" | "waiting_voice_confirm" | "confirmed";

if (state.phase === "waiting_voice_confirm") {
  return (
    <div className="space-y-3">
      <h2 className="text-xl font-semibold">거의 완료됨</h2>
      <p className="text-base">
        음성으로 “구매를 확인합니다”라고 말하거나
        화면의 “결제” 버튼을 눌러 구매를 확인해 주세요.
      </p>
      <Button variant="primary">결제</Button>
      <Button variant="ghost">취소</Button>
    </div>
  );
}

이렇게 하면, 모델이 음성을 잘못 해석하더라도 사용자에게 시각적 “안전망” 층이 남습니다.

7. 간단한 음성 명령과 도구 설계

음성 사용자는 도구의 파라미터 이름 그대로 명령하지 않습니다. “첫 번째로 골라줘”, “좀 더 저렴한 거 보여줘”, “전자 제품은 빼자”라고 말할 것입니다. 개발자의 과제는, 도구와 system‑prompt를 설계하여, 모델이 이런 발화를 여러분의 도구 호출(callTool)로 쉽게 매핑하도록 만드는 것입니다.

GiftGenius에는 예를 들어 다음과 같은 동작을 넣을 수 있습니다.

• 화면에 표시된 옵션 중 인덱스 또는 id로 하나 선택.
• 예산 구체화: “더 싸게”, “30 달러까지”.
• 유형 필터: “디지털 선물만”, “우편 배송이 필요한 건 제외”.

이는 enum 파라미터 action과 추가 필드가 있는 간단한 도구로 표현하기 좋습니다:

// TypeScript로 쓴 도구의 의사 스키마
type VoiceActionInput =
  | { action: "select_item"; itemId: string }
  | { action: "refine_budget"; maxPrice: number }
  | { action: "filter_type"; type: "digital" | "physical" };

export function handleVoiceAction(input: VoiceActionInput) {
  switch (input.action) {
    case "select_item":
      // 선택된 선물을 표시
      break;
    case "refine_budget":
      // 새 예산에 맞춰 추천을 재계산
      break;
    case "filter_type":
      // 기존 목록을 필터링
      break;
  }
}

system‑prompt에서 이런 동작이 음성 명령과 어떻게 대응되는지 설명합니다. 예: “사용자가 ‘첫 번째를 선택해’라고 말하면, gift.voiceAction 도구를 action="select_item"과 화면의 첫 번째 선물 식별자를 넣어 호출해.”

UX 관점에서 이는 인지 부하를 낮춥니다. 사용자는 “30$ 이하의 디지털 선물만 나오도록 필터를 조정해줘” 같은 정확한 문장을 만들 필요가 없습니다. 사람처럼 말하면, 모델이 이를 데이터 구조로 변환합니다.

8. GiftGenius 음성 시나리오: 세 단계

지금까지의 내용을 합쳐, 아직 low‑level Realtime API까지는 들어가지 않고 GiftGenius를 위한 전체 음성 시나리오를 설계해 봅시다.

사용자를 상상해 봅시다. 그는 차를 타고 이동 중이며 ChatGPT의 음성 모드를 실행합니다. 그는 이렇게 말합니다: “엄마 선물 골라줘. 정원을 좋아하시고, 예산은 50 달러까지.”

1단계. 음성으로 정보 수집

모델: “좋아요, 선물을 골라볼게요. 몇 가지를 더 확인할게요. 선물이 필요한 시점은 며칠 이내인가요, 아니면 더 여유가 있나요? 그리고 무겁거나 부피가 큰 것은 피해야 하나요?”

위젯(inline): 현재는 “대상: 엄마, 정원 가꾸기, 50 달러까지”라는 상태만 보이는 작은 패널입니다. 한눈에 읽을 수 있도록 평소보다 글자를 조금 더 큽니다.

위젯 상태 코드는 다음처럼 생길 수 있습니다.

interface GiftSessionState {
  mode: "voice" | "text";
  step: 1 | 2 | 3;
  recipientSummary: string;
  budget?: number;
}

const [state, setState] = useState<GiftSessionState>({
  mode: "voice",
  step: 1,
  recipientSummary: "엄마, 정원 가꾸기 좋아함"
});

사용자의 답변에 따라 서버 측이 recipientSummary와 budget을 업데이트하고, 위젯이 반응합니다.

2단계. 검색과 대기

모델이 충분한 정보를 모으면, 선물 검색 도구를 호출합니다. 이 도구는 추천이 복잡하다면 백그라운드 작업을 실행하고, status: "pending"을 반환할 수 있습니다. 백그라운드가 동작하는 동안 모델은 이렇게 말합니다: “적합한 옵션을 찾아볼게요. 몇 초 정도 걸립니다. 그동안 실물 선물을 선호하시는지, 디지털 상품권도 괜찮은지 알려주실래요?”

사용자가 다른 화면으로 이동하면 위젯은 PiP에 가까운 모드로 전환하거나, inline 상태에서 “선물을 찾는 중…”과 작은 진행 표시기를 보여줍니다.

3단계. 결과와 선택

결과가 준비되면, 모델: “세 가지 옵션을 찾았어요. 첫 번째는 45 달러짜리 정원 도구 세트, 두 번째는 30 달러짜리 정원사 앞치마예요. 화면에 표시해 두었어요. ‘첫 번째 선택해’ 또는 ‘좀 더 저렴한 것 보여줘’라고 말해 주세요.”

위젯은 가격과 짧은 설명이 포함된 큰 카드 3개를 보여줍니다. 각 카드에는 “선택”과 “유사 항목” CTA가 있고, 별도로 “더 보기” 버튼이 있습니다.

사용자가 “두 번째 선택해”라고 말하면, 모델은 voiceAction 도구를 action="select_item"과 두 번째 선물의 id로 호출합니다. 위젯은 해당 항목을 선택 상태로 강조하고, 모델은 “좋아요. 30 달러짜리 정원사 앞치마를 선택했어요.”라고 말합니다.

선택적 4단계. 결제(Checkout)

App이 결제와 통합되어 있다면(미래의 14 모듈), 체크아웃이 시작됩니다. 모델은 조건을 말해 주고, 음성 또는 버튼으로 확인을 요청합니다. 위젯은 전체 화면 마법사로 바뀌며 “주문 확인” → “배송 주소” → “확인” 단계를 거칩니다.

각 단계에서 핵심은 음성으로 안내되며, 특히 사용자가 멈춰서 화면을 보고 있을 때 위젯이 시각적 기준점 역할을 합니다.

9. 구현 실무 노트와 Apps SDK의 경계

GiftGenius에 대해 설명한 모든 단계는 별도의 오디오 클라이언트나 WebRTC 없이, 일반적인 ChatGPT App 내부에서 구현됩니다. 스택의 경계를 잊지 않는 것이 중요합니다.

Realtime API, WebRTC, 오디오 스트리밍 같은 주제로 “멀리 날아가기” 쉽고, 머릿속에서 자체 음성 플랫폼을 만들기 쉽습니다. 이를 위해 강의에 별도의 20 모듈이 있습니다. 이 강의에서는 ChatGPT 클라이언트 안의 ChatGPT App이라는 경계를 기억하는 것이 중요합니다.

현 아키텍처에서:

• 오디오 스트림은 ChatGPT 클라이언트가 관리합니다. 위젯에서 오디오 바이트를 보내거나 받지 않습니다.
• 백엔드에서는 여전히 일반적인 도구 호출과 텍스트 메시지를 보지만, 모델은 음성 모드일 수 있고, 그 응답이 음성으로 낭독됩니다.
• 플랫폼은 현재가 voice 모드임을 암시하는 단서를 전달할 수 있습니다(user-agent나 환경 필드 등). 하지만 이에 강하게 의존하면 안 됩니다. API는 변할 수 있고, 여러분의 App은 순수 텍스트 모드에서도 여전히 유용해야 합니다.

따라서 좋은 구현 전략은 다음과 같습니다. 먼저 텍스트와 음성 둘 다에서 잘 작동하는 UX를 설계합니다: 짧은 상태 문구, 명확한 CTA, 이해하기 쉬운 진행 단계. 그다음 음성에 맞춘 몇 가지 개선을 더합니다: "voiceGlance" 모드에서 약간 더 큰 글꼴, 더 분명한 진행 표시, “3단계 중 2단계”, “승인을 기다리는 중” 같은 상태에 집중합니다.

추가로 system‑prompt에 모델의 음성 동작을 서술합니다: 위젯 상태를 어떻게 코멘트하는지, 확인에 어떤 문구를 사용하는지, 어떤 말은 피하는지(예: JSON을 읽지 않기, 목록의 자잘한 것을 낭독하지 않기).

나중에 Realtime API로 Custom Voice Client를 만들더라도, 이러한 UX 결정들은 그대로 “이식”됩니다. 차이는 이벤트와 스트리밍에 대한 접근 범위뿐이며, 원칙은 바뀌지 않습니다.

10. Voice / Realtime 컨텍스트에서 흔한 실수

오류 №1: UI를 낭독하는 것 vs 요약.
개발자가 도구를 작성할 때, 모델이 JSON 응답의 전체 내용이나 카드 전체 목록을 소리 내어 읽기 시작하도록 만들 때가 있습니다. 음성 모드에서는 UX를 망치는 지름길입니다. 사용자는 흐름을 잃고, 토큰은 낭비됩니다. 음성은 짧은 요약을 말하고, 한두 가지 핵심에 집중하며, 나머지는 화면에 남기는 편이 좋습니다.

오류 №2: 음성 시나리오에서 시각적 피드백이 전무.
“사용자가 말하고 있으니, 듣고 있을 거야. UI는 필요 없어.”라고 생각하기 쉽습니다. 실제로 사용자는 종종 화면을 흘끗 보거나, 1분쯤 뒤에 돌아옵니다. 그 순간 상태, 진행도, 명확한 결과가 없으면, App이 멈췄거나 아무 것도 하지 않았다고 생각합니다. “생각 중”, “3단계 중 2단계”, “결과 준비 완료” 등을 반드시 보여 주세요.

오류 №3: 강력한 확인 없이 위험한 동작을 수행.
텍스트 모드에서도 “결제”를 한 번의 버튼으로 처리하는 것은 위험하고, 음성에서는 애매한 “응”만으로 구매를 실행하는 것이 더 위험합니다. 음성/시각의 명확한 confirmation flow를 무시하면 잘못된 구매와 App에 대한 신뢰 문제로 이어집니다. 어떤 동작이 이중 확인을 요구하는지 고민하고, 이를 system‑prompt와 UI에 명시하세요.

오류 №4: 귀가 아니라 눈에만 맞춘 설계.
가끔 App을 사용자가 항상 텍스트를 읽는다고 가정하고 설계합니다. 너무 복잡한 문장, 긴 버튼 문구, 과도한 설명 등. 음성 모드에서는 이것을 모두 말해야 하므로 “말의 홍수”가 됩니다. 핵심 의미가 짧고 간단한 문장으로, 듣기에 쉽게 전달되도록 하세요.

오류 №5: Apps SDK와 자체 Voice 클라이언트를 혼동.
일부 수강생은 Apps SDK에서 마이크 이벤트, 오디오 스트리밍, WebRTC 등을(Realtime API처럼) 찾다가, “아무 것도 없다”고 실망합니다. 핵심은: ChatGPT App은 ChatGPT 클라이언트 내부에서 동작하고, 음성은 플랫폼이 관리합니다. 여러분은 텍스트, 도구 호출, 위젯 상태로 작업하며, 음성 모드에서도 “그냥 잘 동작”하도록 UX를 설계합니다. 음성에 대한 완전한 제어가 필요하다면, 그것은 Realtime API를 사용하는 별도의 더 복잡한 프로젝트입니다.

오류 №6: 지연에 대한 전략 부재.
긴 작업 동안 모델이 무엇을 말하고, 위젯이 무엇을 보여줄지를 고민하지 않으면, 사용자는 말을 끊고 새 질문을 던져 흐름이 깨집니다. 음성에서 지연은 텍스트보다 더 크게 느껴집니다. 중간 상태, 백그라운드 작업, “생각 중이에요. 그동안 …를 알려주세요.” 같은 음성 멘트를 사용해, 침묵이 버그로 느껴지지 않도록 하세요.