툴팁 컴포넌트는 없어야 한다 ("Tooltip Components Should Not Exist")

1. 핵심 요약

• 저자의 주장: 디자인 시스템의 퍼블릭 API로서 <Tooltip> 컴포넌트는 존재하면 안 된다.

• 이유:

  • 접근성(특히 키보드 내비게이션) 깨지기 쉽다.
  • “어디에 툴팁이 있는지/없는지”가 제각각이라 사용자 경험이 불일관해진다.
  • <Tooltip>은 너무 저수준 추상화라, API만 주면 반드시 잘못 쓰인다.

• 해법:

  • “툴팁”을 직접 노출하지 말고,
  • 버튼·아이콘·정보 아이콘·텍스트 패턴에 특화된 고수준 컴포넌트로만 툴팁을 내장해서 제공하자는 제안.

---

2. 왜 <Tooltip> 컴포넌트가 위험한가

2-1. 접근성 & 키보드 인터랙션 문제

대표 사례: MUI의 기본 예시

<Tooltip title="Delete">
  <IconButton>
    <DeleteIcon />
  </IconButton>
</Tooltip>

• 이 패턴은 버튼이 포커스를 받으므로 키보드 탭 + 포커스 기반 툴팁 작동이 가능하다.
• 문제는 여기서 한 발 더 나가서, 다음처럼 쓰기 시작할 때다:

<Tooltip title="Home">
  <IconHome />
</Tooltip>

<Tooltip title="Unread Mails">
  <Badge badgeContent={4} color="primary">
    <IconMail color="action" />
  </Badge>
</Tooltip>

• IconHome, Badge는 비인터랙티브 요소다.
• 마우스 호버 시 툴팁은 뜨지만,
  키보드 탭으로는 이 요소들을 건너뛰기 때문에 툴팁을 볼 방법이 없다.
• 타입 레벨에서 “children은 반드시 인터랙티브 요소여야 한다”를 강제할 수 없으니,
  이런 잘못된 사용은 막을 수 없다.

React Aria의 접근:

• 비인터랙티브 요소에는 툴팁을 아예 띄우지 않도록 해 두어,
  마우스로 테스트하더라도 “툴팁이 안 뜨는” 이상 징후를 알아차리게 한다.
• 그리고 필요하면 <Focusable>로 감싸도록 요구.
  → 이건 훨씬 낫지만, 여전히 저수준 API + 교육 의존 구조다.

2-2. Least surprise: 사용자 입장에서의 “최소 놀람”

툴팁이 어디에 붙어 있는지 예측 가능해야 한다.

현실에서 자주 보이는 패턴:

• 문장 한가운데 특정 단어에만 툴팁을 달아놓고,
  아무 시각적 표시도 없는 경우.

  • 마우스를 올려야만 “아, 설명이 있었네”를 알 수 있음.

• 반대로:

  • 의미 모를 아이콘만 있는 버튼인데 설명 툴팁도 없음.
  • 사용자는 눌러보기 전까지 무슨 동작인지 알 수 없다.

결과:

• 어느 곳에는 뜨고, 어느 곳에는 안 뜨는 툴팁 복권이 만들어진다.
• 개발자·디자이너 수가 조금만 늘어나도
  “각자 생각대로 쓰는 툴팁”이 퍼져 UX가 무너진다.

---

3. 저수준 <Tooltip> 대신 고수준 “패턴 컴포넌트” 전략

저자의 결론:

“툴팁을 직접 제공하지 말고,
툴팁을 내장한 고수준 패턴 컴포넌트만 제공하라.”

핵심은 두 가지:

1. 툴팁을 붙일 수 있는 대상 자체를 제한
   → 비인터랙티브 요소에는 원천적으로 못 붙이게.
2. 패턴마다 일관된 UX와 접근성을 강제
   → API에서부터 올바른 사용을 유도.

구체적인 패턴 제안:

3-1. <Button> / <Link>: 선택적 title prop

• 인터랙티브 요소에만 title을 허용.

• 내부적으로:

  • 툴팁을 띄우든, aria-label을 붙이든,
    디자인 시스템이 일관된 규칙으로 처리.

• 효과:

  • 키보드 포커스 보장(버튼/링크는 기본 포커스 가능)
  • 사용자는 “클릭 가능한 요소 = 설명 있을 수 있음” 패턴에 익숙해짐.

3-2. <IconButton>: 필수 title prop

• 아이콘만 있는 버튼은 텍스트 정보가 없다.

• API에서 title을 필수로 요구해서:

  • 시각적으로 아이콘만 보이더라도,
  • 스크린 리더와 툴팁을 통해 행동의 의미를 항상 노출.

→ 이걸 강제하면 “의미 불명 아이콘 버튼”을 시스템 레벨에서 차단 가능.

3-3. <InfoIcon> 컴포넌트

• “ⓘ / ?” 같은 정보 아이콘 + 툴팁을 묶은 전용 컴포넌트.

• 사용처:

  • 폼 필드 옆
  • 대시보드 지표 옆
  • 설정 화면 등

• 설계 포인트:

  • 항상 포커스 가능하도록 만들고,
  • 키보드·마우스 모두 동일한 패턴으로 동작.
  • 사용자가 “여기 아이콘 옆에 추가 설명이 있겠구나”를 학습하게 됨.

3-4. <InfoText> 컴포넌트

• 텍스트 안에 추가 설명을 붙이고 싶다면,
  무의미한 <Tooltip>이 아니라 전용 패턴으로 제공.

• 예:

  • 일반 텍스트와 구분되는 스타일

    • 예: 점선 언더라인, 다른 색상

  • 키보드 포커스 가능

  • 호버/포커스 시 설명 표시

→ “텍스트 어디에 툴팁이 숨어 있는지” 찾게 만드는 UI를 피하고,
“여기가 정보 텍스트다”라는 시각적·행동적 일관성을 제공.

---

4. 왜 “제약”이 더 나은가

툴팁은:

• 레이아웃이나 스타일 구조와 달리,
• 접근성과 정보 구조에 직접 영향을 준다.

그래서:

• “유연한 저수준 도구”보다는
  목적에 특화된 제한적인 도구가 더 낫다.

저자의 논리:

• 유연성은 레이아웃·컴포지션 컴포넌트에 써라.

• 툴팁은 포커스·접근성·UX 일관성이 더 중요하다.

• 제한이 생기면:

  • “툴팁 뒤에 숨기면 되지”라는 안일함을 막고,
  • 화면 설계 자체를 다시 생각하게 만들어 준다.
  • 즉, 제약이 오히려 더 나은 디자인을 강제한다.

결론:

조직용 디자인 시스템을 만든다면,
API에 <Tooltip>를 그냥 던져주지 말고,
툴팁이 녹아든 고수준 패턴 컴포넌트만 노출하라.

---

5. 실무 적용 관점에서의 정리

• 하지 말 것

  • <Tooltip>를 public 컴포넌트로 노출해 “어디나” 붙일 수 있게 만들기
  • 비인터랙티브 요소에 툴팁 붙이는 패턴 허용
  • 문장 중간 단어에 아무 표시 없이 툴팁 숨기기

• 할 것

  • Button/Link/IconButton에 title/description 같은 프로퍼티로만 툴팁 제공

  • InfoIcon/InfoText 같은 명시적인 “정보 패턴” 컴포넌트 도입

  • 키보드 내비게이션 기준으로 툴팁 노출 여부 테스트

  • “툴팁으로 해결” 대신 정보 구조·UI 재구성 먼저 고민

---

원문 - Tooltip Components Should Not Exist