제품 디자이너로서 제가 계획하는 시나리오는 다음과 같습니다: 제품은 잘 작동하고, 마케팅은 성공적이며, 수요는 실재하지만—인프라가 이를 따라가지 못하는 상황입니다. 그날의 사용자 경험(User Experience)은 어떤 모습이어야 할까요?

온보딩 (Onboarding) 실패 모드

대부분의 AI 제품 온보딩 (Onboarding) 흐름은 무제한의 용량을 가정합니다: 가입하고, 권한을 얻고, 사용을 시작하는 것입니다. 용량이 소진되면 이 흐름은 깨집니다. 즉각적인 접속을 기대하며 가입한 사용자들은 이제 대기 명단(Waitlist), 메시지, 혹은 침묵에 직면하게 됩니다.

용량 초과 상황을 위한 설계

AI 제품의 온보딩 (Onboarding)은 "사용 가능"과 "가득 참"을 넘어선 세 번째 상태를 가져야 합니다:

핵심 설계 원칙: 사용자가 실패를 통해 용량 제한을 발견하게 만들지 마세요. 사용자가 흐름을 시작하기 전에 미리 알려주어야 합니다.

대기 명단 계약 (The waitlist contract)

만약 신규 가입을 중단해야 한다면, 대기 명단 (Waitlist) 페이지는 읽기 시작한 지 10초 이내에 다음 질문들에 답할 수 있어야 합니다:

1. 왜 접속이 중단되었는가? (구체적으로 명시: "수요가 우리의 컴퓨팅 용량 (Compute capacity)을 초과했습니다")
2. 언제 다시 재개되는가? ("곧"이 아니라 범위를 제공할 것)
3. 그동안 내 계정은 어떻게 되는가? (아무 일도 없는가? 아니면 제한된 티어 (Tier)인가?)
4. 기존 사용자들에게 영향이 있는가? (명시적으로: 아니오)

Kimi의 공지는 1번과 4번 항목을 다루었습니다. 2번과 3번 항목은 덜 명확했습니다. 당신이 설계하고 있는 제품을 위해서라면, 이 항목들이 필요해지기 전에 미리 정의해 두십시오.

살아남는 온보딩 (Onboarding) 흐름

1단계: 용량 상태 확인 (사용 가능 / 대기 명단 / 가득 참)
2단계: 사용 가능할 경우 -> 일반적인 가입
2단계: 대기 명단일 경우 -> 대기 명단 계약 표시 (이유, 시기, 내용, 대상)
...

이 흐름은 최악의 날에도 사용자가 막다른 길 대신 명확한 진행 경로를 가질 수 있음을 의미합니다.

Kimi의 분리가 우리에게 말해주는 것

Kimi는 컴퓨팅 자원 (Compute)을 더 정밀하게 할당하기 위해 구독 서비스를 "메인 제품" (Kimi Web, App, Work)과 "Kimi Code"로 분리하겠다고 발표했습니다. 제품 디자인 관점에서 이는 용량 기반 계층화 (Capacity-based tiering)입니다. 즉, 모든 컴퓨팅 자원을 필요로 하는 하나의 제품 대신, 독립적으로 확장 가능한 두 개의 제품으로 나누는 것입니다.

만약 AI 제품을 설계하고 있다면, 단순히 가격 책정이나 마케팅 목적뿐만 아니라 용량 문제로 인해 기능 세트 (Feature set)를 분리할 수 있는지 첫날부터 고려하십시오.

내가 설계하지 않은 것

나는 Kimi의 실제 온보딩 (Onboarding) 흐름을 설계하지 않았습니다. 이것은 K3 출시 주간에 공개적으로 보고된 사건들을 바탕으로 일반적인 AI 제품 온보딩 원칙에 적용한 디자인 프로토콜입니다. 이는 Kimi의 구체적인 UX 결정에 대한 비판이 아니라, 계획을 위한 프레임워크 (Framework)입니다.

출처

• K3 출시: Moonshot AI, 2026-07-16
• 구독 중단: Moonshot AI 발표, 2026-07-19
• 구독 분리 계획: 동일한 중단 공지에서 발표됨

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와는 관련이 없습니다. MonkeyCode는 오픈 소스 AI 코딩 플랫폼입니다: https://github.com/chaitin/MonkeyCode