plan-1-brainstorm

name	plan-1-brainstorm
description	기획 브레인스토밍 스킬. "아이디어 정리해주세요", "뭘 만들지 같이 고민해주세요", "설계 논의", "디자인 같이 해주세요", "이거 어떻게 만들면 좋을까요?", "기능 구상", "접근법 제안해주세요" 등의 요청 시 트리거. 구현에 들어가기 전에 아이디어를 탐색하고, 접근법을 비교하고, 디자인을 확정하는 협업 대화 스킬. 새로운 기능, 컴포넌트 생성, 기존 동작 변경 등 모든 창작 작업 전에 반드시 이 스킬을 먼저 사용해야 한다. AI Driven Development 파이프라인의 1단계이자 진입점 — 대상 프로젝트와 Memory URL을 확정하여 이후 스킬로 전파한다.

아이디어를 디자인으로 — 브레인스토밍 (Step 1/6)

이 스킬은 AI Driven Development 파이프라인의 진입점이자 첫 번째 단계이다. SKILL.md 상단의 PROJECTS 상수에서 대상 프로젝트를 선택하고, 해당 프로젝트의 Memory URL을 파이프라인 전체로 전파한다. 완료 후 사용자에게 Step 2: 기획 시작 스킬 사용을 안내한다.

설정 (플러그인 배포 시 1회 채움)

아래 PROJECTS 상수에 프로젝트별 memory URL 4종을 직접 등록한다. 프로젝트 추가/변경 시 이 블록만 수정하면 되며, Notion Catalog DB fetch는 사용하지 않는다.

writing-style은 plan-6 스킬이 자체적으로 보유한 규칙이므로 PROJECTS에 등록하지 않는다.

PROJECTS:
  KiTplayer:
    glossary: https://www.notion.so/muzlive/35e4d6f383cf80ba8447e790b3198cd0?source=copy_link
    flowchart: https://www.notion.so/muzlive/KiTplayer-Flowchart-35e4d6f383cf8027a8f5c75d0f202a90?source=copy_link
    principle: https://www.notion.so/muzlive/KiTbetter-34b4d6f383cf80d6be2edfc64ef7de79?source=copy_link
    constraint: https://www.notion.so/muzlive/Constraints_rules-35d4d6f383cf80488a5bd50e67871887?source=copy_link
  KiTbetter (Artists):
    glossary: https://www.notion.so/muzlive/34b4d6f383cf80068c71d251aeb075b9?source=copy_link
    flowchart: https://www.notion.so/muzlive/Flow-Chart-34b4d6f383cf805d8afdf0c112af1ce8?source=copy_link
    principle: https://www.notion.so/muzlive/KiTbetter-34b4d6f383cf80d6be2edfc64ef7de79?source=copy_link
    constraint: https://www.notion.so/muzlive/Constraints_rule-34b4d6f383cf80ca8441f676f03d4434?source=copy_link

규칙:

• 최상위 key = 프로젝트명. 사용자에게 보여줄 선택지 라벨과 동일하게 작성한다.
• 4개 URL(glossary/flowchart/principle/constraint) 모두 등록 권장. 누락된 항목은 값을 빈 문자열로 두면 이후 단계에서 해당 memory 검사만 스킵된다.
• 프로젝트 추가/이름 변경/폐기는 이 블록만 수정한다. 플러그인 재배포만 필요하며, 별도 Notion DB 운영은 없다.
• PROJECTS가 비어 있거나 placeholder(<project_name>) 그대로면 스킬은 진입 즉시 초기 설정 안내 후 중단한다.

개요

자연스러운 협업 대화를 통해 아이디어를 구체적인 디자인과 스펙으로 발전시킨다.

먼저 SKILL.md 상단 PROJECTS 상수에서 대상 프로젝트를 선택하여 Memory URL을 확보하고, 프로젝트 맥락을 파악한 뒤, 한 번에 하나씩 질문하여 아이디어를 정제한다. 무엇을 만들지 충분히 이해하면 디자인을 제시하고 사용자 승인을 받는다.

디자인이 제시되고 사용자가 승인하기 전까지는 절대로 구현 작업(코드 작성, 스캐폴딩, 프로토타입 등)을 시작하지 않는다. 프로젝트가 아무리 단순해 보여도 예외 없이 적용한다.

안티패턴: "이건 너무 단순해서 디자인이 필요 없어"

모든 프로젝트는 이 과정을 거친다. 투두 리스트, 단일 함수 유틸리티, 설정 변경 — 전부 다. "단순한" 프로젝트야말로 검토하지 않은 가정이 가장 많은 시간 낭비를 유발하는 곳이다. 디자인은 짧을 수 있다(정말 단순한 프로젝트라면 몇 문장이면 충분). 하지만 반드시 제시하고 승인받아야 한다.

체크리스트

아래 항목을 반드시 순서대로 수행한다:

0. 대상 프로젝트 확정 (진입점) — PROJECTS 상수 로드 → 프로젝트 선택 → memory URL 4개 확보 → 플랫폼 제약 섹션 로드. 아래 "대상 프로젝트 확정" 섹션 참고.
1. 프로젝트 맥락 파악 — 관련 파일, 문서, 최근 변경 사항 확인. 컨텍스트 소스는 PROJECTS 상수와 Notion Memory(glossary/flowchart/principle/constraint)로 한정한다.
2. Notion 저장 페이지 확인 — 기획서를 저장할 Notion 페이지 URL을 요청. 아래 "Notion 저장 페이지" 섹션 참고.
3. 모호도 판단 및 명확화 — 입력이 모호하면 가설 기반 객관식 질문으로 정제. 명확하면 바로 다음 단계로. 아래 "모호도 판단 및 명확화" 섹션 참고.
4. 시각적 보조 제안 (시각적 질문이 예상되는 경우) — 별도 메시지로 제안. 아래 "시각적 보조" 섹션 참고.
5. 2-3가지 접근법 제안 — 트레이드오프와 추천안 포함
6. 디자인 제시 — 복잡도에 맞게 섹션별로 나눠서, 각 섹션 승인 후 다음 진행
7. 디자인 문서 작성 — Notion 페이지 + 로컬 md 파일에 저장 (프론트매터에 프로젝트/Memory URL 포함). 아래 "출력 전략" 섹션 참고.
8. 셀프리뷰 — 플레이스홀더, 모순, 모호함, 범위 문제를 빠르게 점검 (아래 참고)
9. 사용자 리뷰 — 사용자에게 Notion 페이지 링크와 함께 검토 요청, 승인 전까지 진행 불가
10. 다음 단계 전환 — Step 2 (기획 시작) 스킬로 안내

대상 프로젝트 확정

브레인스토밍을 시작하기 전에 가장 먼저 수행한다. 이 결과는 이후 plan-2 ~ plan-6 전체에 전파된다.

1) PROJECTS 상수 로드

SKILL.md 상단의 PROJECTS 블록을 읽는다.

• 블록이 비어 있거나 placeholder(<project_name>)가 그대로면: "플러그인 초기 설정이 필요합니다. plan-1-brainstorm/SKILL.md의 PROJECTS 블록에 프로젝트와 memory URL 4종(glossary/flowchart/principle/constraint)을 등록해 주세요." 안내 후 중단.
• 별도 fetch는 수행하지 않는다. 모든 매핑은 파일 내부에서 가져온다.

확보 결과: PROJECTS의 최상위 key 목록 = 프로젝트명 목록.

2) 프로젝트 선택 질문

AskUserQuestion으로 프로젝트 목록을 옵션으로 제시한다.

"어떤 프로젝트의 기획을 시작하시나요?"

• 프로젝트가 4개 이하: 모든 key를 옵션으로 노출. AskUserQuestion이 자동으로 추가하는 "기타" 옵션은 무시하고 등록된 프로젝트만 선택해도 충분하다.
• 5개 이상: 대표 4개를 옵션으로 노출하고, 나머지는 자동 추가되는 "기타" 옵션을 통해 직접 입력을 받는다. 기타 선택 시 프로젝트명을 타이핑 받고 PROJECTS key와 정확 일치 검색.
• 어떤 경로든 사용자가 타이핑한 프로젝트명이 PROJECTS key와 일치하지 않으면 "PROJECTS에 해당 프로젝트가 없습니다. SKILL.md의 PROJECTS 블록에 먼저 추가해 주세요" 안내 후 중단.

3) Memory URL 확보

선택된 프로젝트의 PROJECTS[project_name] 매핑에서 4개 URL을 가져온다:

• glossary
• flowchart
• principle
• constraint

값이 빈 문자열이거나 key가 누락된 항목은 사용자에게 알리고 계속 진행 여부를 확인한다. 누락된 memory_key는 이후 단계에서 관련 검사가 스킵됨을 안내한다. Notion fetch는 4단계(플랫폼 제약 섹션 로드)에서 constraint URL 1건만 수행한다.

writing-style은 plan-6 스킬이 자체적으로 보유하므로 여기서 URL을 확보하지 않는다.

4) 플랫폼 제약 섹션 로드

확보된 constraint_url을 notion-fetch로 읽고 ## 플랫폼 제약 섹션만 추출한다.

• 섹션이 없으면 fallback으로 constraint 페이지 전체를 로드하고 "이 프로젝트의 constraint 페이지에 ## 플랫폼 제약 섹션이 없어 전체를 참조합니다"라고 안내.
• 추출한 플랫폼 제약 내용을 내부 컨텍스트로 유지한다. 브레인스토밍 도중 아이디어가 이 제약을 명백히 위반하면 즉시 경고한다(아래 "발산 중 플랫폼 제약 감지").

5) 파이프라인 전파 준비

아래 값을 기억해두고, 7단계에서 로컬 md 프론트매터에 기록한다:

• project_name
• glossary_url
• flowchart_url
• principle_url
• constraint_url

이 값들은 plan-2 ~ plan-6이 질문 없이 계승하여 사용한다. writing_style_url은 더 이상 전파하지 않으며, plan-6 스킬 내부 규칙으로 대체된다.

발산 중 플랫폼 제약 감지

아이디어 발산 단계에서 사용자 제안이 로드된 "## 플랫폼 제약"을 명백히 위반하면 즉시 경고한다.

⚠️ 플랫폼 제약 위반 의심

• 제안: "iOS 14도 지원하자"
• 제약: "iOS 15+ 지원"
• 선택: (a) 제약 페이지 갱신 / (b) 기획 방향 재검토 — 사용자 판단 필요

경고 후 사용자가 결정한 방향으로 계속 진행한다. 제약은 참고용이며, PM이 필요하다고 판단하면 제약 페이지 자체를 개정할 수 있다.

다른 Memory(glossary, flowchart, principle)는 의도적으로 로드하지 않는다. 브레인스토밍은 발산 단계이므로 인지 부하를 줄이고 자유도를 확보한다. 용어 정합성·플로우 충돌·원칙 검사 등은 plan-2 이후 단계에서 집중 수행한다.

근거 없으면 추측 금지 (브레인스토밍 예외)

개인 맞춤 설정의 "근거 없으면 추측하지 말고 모른다고 대답" 원칙은 브레인스토밍에서도 지킨다. 단, 브레인스토밍은 본질적으로 탐색 단계이므로 가설/추측은 (추측) 태그로 명시한 뒤 제시할 수 있다.

예:

• "이 기획의 성공은 사용자 재방문 증가로 측정할 수 있을 것 같습니다 (추측). 실제 측정 지표는 PM님이 결정해 주세요."

(추측) 태그 없이 근거 없는 확신을 내놓는 것은 여전히 금지한다.

프로세스 플로우

digraph brainstorming {
    "대상 프로젝트 확정" [shape=box];
    "프로젝트 맥락 파악" [shape=box];
    "Notion 저장 페이지 확인" [shape=box];
    "시각적 질문 예상?" [shape=diamond];
    "시각적 보조 제안\n(별도 메시지)" [shape=box];
    "명확화 질문" [shape=box];
    "2-3가지 접근법 제안" [shape=box];
    "디자인 섹션별 제시" [shape=box];
    "사용자 승인?" [shape=diamond];
    "디자인 문서 작성\n(Notion + 로컬 md)" [shape=box];
    "셀프리뷰\n(인라인 수정)" [shape=box];
    "사용자 리뷰?\n(Notion 링크 전달)" [shape=diamond];
    "Step 2 기획 시작 안내" [shape=doublecircle];

    "대상 프로젝트 확정" -> "프로젝트 맥락 파악";
    "프로젝트 맥락 파악" -> "Notion 저장 페이지 확인";
    "Notion 저장 페이지 확인" -> "모호도 판단";
    "모호도 판단" [shape=diamond];
    "가설 기반 명확화\n(AskUserQuestion)" [shape=box];
    "모호도 판단" -> "가설 기반 명확화\n(AskUserQuestion)" [label="모호함"];
    "모호도 판단" -> "시각적 질문 예상?" [label="명확함"];
    "가설 기반 명확화\n(AskUserQuestion)" -> "시각적 질문 예상?";
    "시각적 질문 예상?" -> "시각적 보조 제안\n(별도 메시지)" [label="예"];
    "시각적 질문 예상?" -> "2-3가지 접근법 제안" [label="아니오"];
    "시각적 보조 제안\n(별도 메시지)" -> "2-3가지 접근법 제안";
    "2-3가지 접근법 제안" -> "디자인 섹션별 제시";
    "디자인 섹션별 제시" -> "사용자 승인?";
    "사용자 승인?" -> "디자인 섹션별 제시" [label="수정 필요"];
    "사용자 승인?" -> "디자인 문서 작성\n(Notion + 로컬 md)" [label="승인"];
    "디자인 문서 작성\n(Notion + 로컬 md)" -> "셀프리뷰\n(인라인 수정)";
    "셀프리뷰\n(인라인 수정)" -> "사용자 리뷰?\n(Notion 링크 전달)";
    "사용자 리뷰?\n(Notion 링크 전달)" -> "디자인 문서 작성\n(Notion + 로컬 md)" [label="변경 요청"];
    "사용자 리뷰?\n(Notion 링크 전달)" -> "Step 2 기획 시작 안내" [label="승인"];
}

최종 상태는 Step 2 (기획 시작)으로의 전환이다. 그 어떤 구현 스킬도 직접 호출하지 않는다.

프로세스 상세

모호도 판단 및 명확화

프로젝트 맥락 파악 후, 사용자 입력의 모호도를 판단한다.

모호함 판단 기준 — 아래 중 2개 이상 해당하면 "모호함":

• 목적이 불명확 ("더 좋게 만들어주세요", "개선해주세요")
• 범위가 특정되지 않음 ("로그인 기능 추가", "알림 시스템")
• 대상 사용자가 언급되지 않음
• 성공 기준이 없음
• 여러 가지로 해석 가능한 요청

모호한 경우 → 가설 기반 명확화 (vague 프로토콜)

AskUserQuestion 도구를 사용하여 가설을 옵션으로 제시한다. 개방형 질문 대신 가설-옵션 방식으로 질문한다.

나쁜 예: "어떤 로그인 방식을 원하시나요?"          ← 개방형, 인지 부하 높음
좋은 예: "OAuth / 이메일+비밀번호 / SSO / 매직링크" ← 옵션 제시, 인지 부하 낮음

규칙:

• 관련 질문을 AskUserQuestion 1회 호출에 최대 4개까지 묶어서 질문
• 복합 원인 파악이 필요하면 multiSelect: true 사용
• 총 5~8문 이내로 핵심 모호성 해소. 초과 금지.
• 모호성 카테고리: 범위, 동작, 대상 사용자, 제약조건, 우선순위
• 검증 질문 반드시 포함: "이 기획이 성공했다면 어떤 변화가 생겨야 하나요?" (옵션: 지표 개선 / 사용자 행동 변화 / CS 감소 / 기타)

명확화 완료 후 Before/After 요약을 터미널에 짧게 출력한다:

**Before**: "{원래 요청}"
**After**: "{정제된 요청 한 줄}"

명확한 경우 → 바로 다음 단계로

목적, 범위, 대상이 명확하면 명확화 과정을 건너뛰고 시각적 보조 제안 또는 접근법 탐색으로 직행한다.

아이디어 심화

명확화가 완료된 아이디어에 대해 추가 탐색한다.

• 범위 평가: 요청이 여러 독립적인 서브시스템을 포함하면 즉시 지적한다. 분해가 필요한 프로젝트의 세부사항을 정제하는 데 질문을 낭비하지 않는다.
• 프로젝트가 단일 스펙에 담기엔 너무 크면, 사용자와 함께 서브 프로젝트로 분해한다.
• 추가 질문이 필요하면 AskUserQuestion으로 가설-옵션 방식을 유지한다.
• 집중 포인트: 아키텍처, 데이터 흐름, 기존 시스템과의 연결점, 플랫폼 제약 위반 여부

접근법 탐색하기

• 2-3가지 서로 다른 접근법을 트레이드오프와 함께 제안한다
• 추천안을 먼저 제시하고 이유를 설명한다
• 대화체로 편안하게 옵션을 소개한다

디자인 제시하기

• 무엇을 만들지 충분히 이해했다고 판단되면 디자인을 제시한다
• 각 섹션을 복잡도에 맞게 스케일링: 단순하면 몇 문장, 복잡하면 200-300자 내외
• 각 섹션 후 "여기까지 괜찮으신가요?" 라고 확인한다
• 다루는 내용: 아키텍처, 컴포넌트, 데이터 흐름, 에러 처리, 테스트
• 무언가 맞지 않으면 돌아가서 재확인할 준비를 한다

격리와 명확성을 위한 설계

• 시스템을 더 작은 단위로 분리: 각 단위가 하나의 명확한 목적을 갖고, 잘 정의된 인터페이스로 통신하며, 독립적으로 이해하고 테스트 가능해야 한다
• 각 단위에 대해 답할 수 있어야 한다: 무엇을 하는가, 어떻게 사용하는가, 무엇에 의존하는가?
• 내부를 읽지 않아도 유닛의 역할을 이해할 수 있는가? 내부를 변경해도 소비자가 깨지지 않는가? 아니라면 경계를 다시 잡아야 한다.

기존 코드베이스에서 작업할 때

• 변경을 제안하기 전에 현재 구조를 먼저 탐색한다. 기존 패턴을 따른다.
• 현재 작업에 영향을 미치는 기존 코드 문제(파일이 너무 큰 경우, 불명확한 경계, 얽힌 책임)가 있으면 디자인의 일부로 타겟팅된 개선을 포함한다.
• 관련 없는 리팩토링은 제안하지 않는다. 현재 목표에 집중한다.

Notion 저장 페이지

프로젝트 맥락 파악 직후, 기획서를 저장할 Notion 페이지를 확인한다.

"기획서를 저장할 Notion 페이지 URL이 있으신가요? 없으시면 새 페이지를 자동으로 만들어 드립니다."

• URL을 제공한 경우: 해당 페이지에 기획서를 작성한다. notion-fetch로 페이지 접근 가능 여부를 먼저 확인한다.
• URL을 제공하지 않은 경우: notion-create-pages로 새 페이지를 생성한다. 페이지 제목은 [브레인스토밍] {기획 주제}로 한다. 생성된 URL을 사용자에게 안내한다.

이후 확보된 Notion 페이지 URL을 스킬 종료까지 유지하여, 디자인 문서 작성 및 사용자 리뷰 단계에서 사용한다.

출력 전략

토큰 절감과 가독성을 위해 출력 채널을 분리한다.

채널	용도	내용
터미널	대화 전용	질문, 응답, 간단한 요약 (3줄 이내)
Notion	상세 문서	디자인 문서 전문, 비교표, 아키텍처 설명
로컬 md	파이프라인 입력	plan-2-draft가 참조할 구조화된 요약 + Memory URL 전파

터미널 출력 규칙

• 접근법 제안 시: 각 접근법을 3줄 이내로 요약. 상세 비교는 Notion에 작성.
• 디자인 제시 시: 섹션 제목 + 핵심 포인트만 터미널에 출력. 전문은 Notion에 작성.
• 문서 작성 완료 시: Notion 링크와 1-2줄 요약만 터미널에 출력.

로컬 md 파일 규칙

• 저장 경로: 프로젝트 루트의 .claude/docs/brainstorm-{기획주제}.md

• 프론트매터에 아래 값을 반드시 기록한다 (plan-2~6 전파용):

  ---
  project_name: {선택된 프로젝트명}
  glossary_url: {URL}
  flowchart_url: {URL}
  principle_url: {URL}
  constraint_url: {URL}
  ---
  

  누락된 memory_key는 값 없이 null 또는 빈 문자열로 기록한다.

• 본문은 plan-2-draft가 참조할 수 있도록 아래 구조로 작성:

  • 기획 주제 및 배경
  • 선택된 접근법과 이유
  • 핵심 디자인 결정 사항
  • 성공 기준 / 검증 방법
  • Notion 상세 문서 링크

디자인 이후

문서화

• 검증된 디자인을 Notion 페이지에 상세 작성하고, 로컬 md 파일에 구조화된 요약 + Memory URL 프론트매터를 저장한다
• 터미널에는 Notion 링크와 로컬 파일 경로만 안내한다
• 핵심 결정 사항, 트레이드오프, 합의된 접근법을 명확히 기록한다

셀프리뷰

디자인 문서 작성 후 새로운 눈으로 점검한다:

1. 플레이스홀더 스캔: "TBD", "TODO", 불완전한 섹션, 모호한 요구사항이 있는가? → 수정
2. 내부 일관성: 섹션 간 모순이 없는가? 아키텍처가 기능 설명과 일치하는가?
3. 범위 확인: 단일 기획/구현 계획으로 충분한 범위인가, 분해가 필요한가?
4. 모호성 확인: 두 가지 이상으로 해석 가능한 요구사항이 있는가? → 하나를 골라 명시
5. 프론트매터 확인: project_name + 5개 memory URL이 모두 기록되었는가?

문제가 있으면 인라인으로 수정한다. 재검토는 필요 없다 — 수정하고 넘어간다.

사용자 리뷰 게이트

셀프리뷰 통과 후, 사용자에게 Notion 페이지 링크와 함께 검토를 요청한다:

"디자인 문서가 작성되었습니다. Notion에서 확인해 주세요: {Notion 페이지 URL} 로컬 파일: .claude/docs/brainstorm-{기획주제}.md 구현 계획(기획 시작)으로 넘어가기 전에 검토해 주세요. 변경 사항이 있으면 말씀해 주세요."

사용자 응답을 기다린다. 변경 요청이 있으면 Notion 페이지와 로컬 md 파일을 모두 수정한 후 셀프리뷰를 재수행한다. 사용자가 승인해야만 진행한다.

다음 단계 전환

사용자 승인 후 아래 메시지로 다음 단계를 안내한다:

✅ 브레인스토밍 완료 (Step 1/6)

디자인이 확정되었습니다. 다음 단계로 기획 시작을 진행합니다. 아래와 같이 요청해 주세요:

👉 "기획 시작해주세요"

핵심 원칙

• 한 번에 한 질문 — 여러 질문으로 압도하지 않는다
• 객관식 선호 — 가능하면 개방형보다 객관식이 답하기 쉽다
• YAGNI 철저히 — 불필요한 기능은 모든 디자인에서 제거
• 대안 탐색 — 확정 전에 반드시 2-3가지 접근법을 제안
• 점진적 검증 — 디자인을 제시하고, 승인받고, 다음으로
• 유연하게 — 무언가 맞지 않으면 돌아가서 재확인
• Memory 최소 로드 — 발산 자유도를 위해 constraint(플랫폼 섹션)만 로드. 정합성 검사는 plan-2 이후에 수행.

시각적 보조

목업, 다이어그램, 시각적 옵션을 보여주기 위한 보조 기능이다. 모드가 아닌 도구 — 수락해도 모든 질문에 시각화를 쓰는 것이 아니다.

제안 시점: 앞으로의 질문에 시각적 콘텐츠(목업, 레이아웃, 다이어그램)가 포함될 것으로 예상되면 동의를 한 번 구한다:

"앞으로 논의할 내용 중 시각적으로 보여드리면 이해가 더 빠른 부분이 있을 것 같습니다. 와이어프레임, 다이어그램, 비교 시안 등을 만들어서 보여드릴까요?"

이 제안은 반드시 별도 메시지로 한다. 명확화 질문, 컨텍스트 요약 등 다른 내용과 결합하지 않는다. 사용자 응답을 기다린 후 진행한다. 거절하면 텍스트 전용 브레인스토밍으로 진행한다.

질문별 판단: 사용자가 수락한 후에도 각 질문마다 시각화 사용 여부를 판단한다. 판단 기준: "이걸 읽는 것보다 보는 것이 더 이해가 빠른가?"

• 시각적 보조 사용: 콘텐츠 자체가 시각적인 경우 — 목업, 와이어프레임, 레이아웃 비교, 아키텍처 다이어그램
• 텍스트로 진행: 콘텐츠가 텍스트/개념인 경우 — 요구사항 질문, 개념적 선택, 트레이드오프 목록, 범위 결정

UI 관련 주제라고 해서 자동으로 시각적 질문은 아니다. "이 맥락에서 '구독'이란 무엇인가요?"는 개념적 질문이다 → 텍스트. "어떤 네비게이션 레이아웃이 더 나은가요?"는 시각적 질문이다 → 시각적 보조.