💡 20. 다형성(Polymorphism)과 접근성(a11y)

🎯 이 섹션을 읽고 나면:

• 사내 공통 Button 컴포넌트가 왜 어떨 때는 링크(<a>)로 변신해야 하는지 유연성의 본질을 깨닫는다.
• as prop과 Radix UI의 Slot 패턴을 사용하여 마법처럼 태그 껍데기를 갈아 끼우는 '다형성' 컴포넌트를 설계할 수 있다.
• 키보드 네비게이션과 스크린 리더(VoiceOver)를 지원하는 aria- 속성의 기본기를 갖춘 배리어프리(Barrier-Free) 프론트엔드 개발자로 거듭난다.

📋 목차

• 🤔 왜 알아야 하는가: '껍데기'의 저주
• 🏗️ 비유로 먼저 이해하기
• 🧩 극의 체득: 유체이탈 다형성 설계하기
  • ✅ 방법 1: as Prop 패턴 (전통의 강자)
  • ✅ 방법 2: Slot (asChild) 패턴 (현대 Radix UI의 대세)
• 👂 빛과 소리: 접근성 (Accessibility, a11y) 챙기기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 6분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영숙(디자이너): "영철 님! 이번에 만든 [회원가입 완료] 버튼 디자인 너무 에뻐요. 저 디자인 그대로 복사해서, 메인 페이지 하단의 [이벤트 페이지로 이동] 버튼으로도 똑같이 렌더링해주실 수 있죠?"
• 영철(신입): "네! 그야 당연하죠 (자신만만). 어? 근데 [회원가입 완료]는 눌렀을 때 폼을 제출하는 <button>인데... [이동] 버튼은 다른 페이지로 완전히 넘어가는 <a> 태그(Next.js Link)여야 하잖아요? 그럼 디자인은 똑같은데 컴포넌트를 <Button>용, <LinkButton>용 2개로 따로 쪼개야 하나요? CSS 중복이 500줄이 넘어가는데..."
• 영호(리드): "영철 님, 태그 종류 때문에 같은 디자인을 계속 복사하면 디자인 시스템이 금방 흔들립니다. 버튼 컴포넌트는 스타일은 유지하되 실제 태그만 바꿀 수 있어야 해요. 그리고 스크린 리더와 키보드 사용자도 같은 버튼을 사용할 수 있도록 접근성(a11y) 속성까지 같이 설계합시다."

🤔 왜 알아야 하는가: 태그와 스타일을 분리해야 하는 이유

모양과 폰트 크기, 호버(Hover) 시 파란색으로 변하는 애니메이션까지 동일한 버튼 디자인입니다.
그런데 어떤 경우는 API를 쏘는 type="submit" 버튼이고, 어떤 경우는 구글 창을 여는 href="https://..." 형태의 앵커(A) 태그라고 칩시다.

// ❌ 영철이의 하드코딩된 구현 (디자인 중복의 늪)
 
// 1번: 폼 제출용 버튼
export function DefaultButton({ children, onClick }) {
  return <button className="super-gorgeous-blue-btn" onClick={onClick}>{children}</button>;
}
 
// 2번: 외부 링크 이동용 버튼
export function LinkButton({ children, href }) {
  // CSS 클래스 오타라도 나면 디자인이 틀어진다!
  return <a className="super-gorgeous-blue-btn" href={href}>{children}</a>;
}

디자인 시스템(Design System)을 구축하는 팀에서 이런 방식이 반복되면 유지보수 비용이 빠르게 커집니다. 디자인(Style)과 기능(HTML Tag)은 분리해서 생각해야 합니다. 우리는 스타일은 공유하되 실제 렌더링 태그는 상황에 맞게 바꿀 수 있는 다형성(Polymorphism) 버튼을 만들어야 합니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. 과거의 뻣뻣한 갑옷 (하드코딩): "이 파란색 갑옷은 무조건 '검사(Button)' 전용입니다!" 마법사(Link)가 입으려고 하면 같은 갑옷을 하나 더 만들어야 합니다.
2. 다형성의 마법 갑옷 (Polymorphic): 이 파란색 갑옷(CSS 스타일)은 입는 사람의 역할에 맞춰 형태를 바꿉니다.
   마법사가 입으면 지팡이 구멍(href)이 나 있는 옷으로 스르륵 변하고, 검사가 입으면 칼꽂이(type="submit")가 달린 버튼으로 변신하죠. 하지만 겉에서 볼 땐 눈부신 파란 황금색 스타일을 완벽하게 똑같이 유지합니다.

🧩 극의 체득: 유체이탈 다형성 설계하기

보통 실무에서는 이 "변신" 지시를 내리기 위해 두 가지 패턴을 주로 사용합니다.

✅ 방법 1: as Prop 패턴 (전통의 강자)

가장 무난하고 널리 알려진 패턴입니다. "as로 전달한 태그나 컴포넌트로 렌더링하라"라고 명시해줍니다.

// 🎯 as를 사용한 다형성 버튼 설계
export function MagicButton({ as: Component = "button", children, ...props }) {
 
  // Component에 "a"가 들어오면 <a> 태그로, "button"이면 <button>으로 렌더링한다.
  // Next.js의 <Link> 컴포넌트를 넘겨도 같은 스타일을 유지할 수 있다.
  return (
    <Component className="super-gorgeous-blue-btn" {...props}>
      {children}
    </Component>
  );
}
 
// ------ 사용하는 쪽 (소비자) ------
function App() {
  return (
    <div>
      {/* 1. 기본은 제출용 <button>으로 렌더링 됨 */}
      <MagicButton type="submit">로그인</MagicButton>
 
      {/* 2. 외부 링크로 이동하는 <a> 태그로 렌더링된다. 디자인은 같다. */}
      <MagicButton as="a" href="https://google.com">
        구글에서 로그인
      </MagicButton>
 
      {/* 3. 라우팅 최적화를 위해 Next.js Link 컴포넌트로 렌더링한다. */}
      <MagicButton as={Link} href="/home">
        우리집으로 가자
      </MagicButton>
    </div>
  )
}

이제 파란색 버튼 CSS는 한 번(className="super-gorgeous...")만 선언되고, 여러 태그 역할에 재사용됩니다.

✅ 방법 2: Slot (asChild) 패턴 (현대 Radix UI의 대세)

as 패턴은 직관적이지만 한계가 있습니다. 타입스크립트 추론(TypeScript Generic type infer)을 정교하게 작성하려면 코드가 꽤 복잡해질 수 있습니다. "as가 a라면 href를 허용하라" 같은 조건을 타입으로 표현하기가 까다롭죠.

그래서 Radix UI, shadcn/ui 같은 라이브러리에서 많이 쓰는 방식이 자식에게 디자인 속성을 병합하는 Slot (asChild) 패턴입니다.

// 🎯 Slot (asChild) 패턴의 철학
import { Slot } from '@radix-ui/react-slot'; // (원리를 구현한 유명 툴)
 
// 디자인 껍데기만 쥐고 있는 단순 래퍼 컴포넌트
export function MasterButton({ asChild, children, ...props }) {
 
  // asChild가 켜져 있으면 Slot이 자식 요소를 실제 태그로 유지하면서
  // className, 이벤트 핸들러 같은 props를 자식에게 병합한다.
  const Comp = asChild ? Slot : "button";
 
  return (
    <Comp className="super-gorgeous-blue-btn" {...props}>
      {children}
    </Comp>
  )
}
 
// ------ 사용하는 쪽 (소비자) ------
function App() {
  return (
    <MasterButton asChild>
      <a href="https://google.com">파란 구글버튼</a>
      {/* 결과: Slot이 <a href="..." className="super-gorgeous..." /> 로 병합해 렌더링! */}
    </MasterButton>
  )
}

이 방법의 장점: <a> 태그는 자신이 가진 고유 속성(href)만 책임지고, MasterButton은 공통 디자인과 이벤트만 책임집니다. 프롭스 구조가 덜 얽히고 실제 태그의 의미도 유지됩니다.

👂 빛과 소리: 접근성 (Accessibility, a11y) 챙기기

예쁜 다형성 버튼을 만들었다고 끝이 아닙니다. 이 버튼은 마우스를 쓰기 어려운 사용자, 화면을 보기 어려워 스크린 리더로 탐색하는 사용자에게도 똑같이 작동해야 합니다.

이것을 우리는 **a11y (접근성)**이라고 부르며, 현업 디자인 시스템에서 매우 중요한 품질 기준으로 봅니다.

1. aria- 속성의 늪: 저 버튼이 단순히 '전송' 글자만 있는 게 아니라면?

// 스크린 리더는 이 버튼을 "안내문 열기"라고 읽는다.
<MagicButton aria-label="안내문 열기" aria-expanded={isOpen} onClick={toggle}>
   🚀 {/* 눈에 보이는 텍스트 없이 아이콘만 있는 버튼에는 접근 가능한 이름이 필요하다. */}
</MagicButton>

2. Tab 포커스: 마우스를 쓰지 않는 사용자는 키보드의 Tab과 Enter 키만으로 화면을 이동합니다. 여기서 다형성 버튼이 div나 span 태그로 렌더링 되었다면 키보드 초점이 잡히지 않아 마우스로만 클릭 가능한 요소가 됩니다.

그렇기에 브라우저가 기본 키보드 조작을 지원하는 네이티브 <button> 요소나 <a> 태그를 유지하는 다형성 패턴은 개발자 취향을 넘어 실제 사용성을 지키는 핵심 설계가 됩니다.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
"모양은 같게 유지하고 태그의 의미는 상황에 맞춰 바꿔야 할 때, as와 asChild는 가장 실용적인 선택지다."

📝 마무리 퀴즈

Q1. 당신이 공통 컴포넌트(Design System) 개발팀에 합류했습니다. 첫 임무로 Button 컴포넌트를 설계하는데, 기존 팀원 영철이가 만들어둔 코드는 아래와 같습니다. 시니어의 관점에서, 다형성과 SEO, 접근성(a11y) 측면의 가장 문제가 큰 단점을 골라보세요.

function SimpleButton({ title, url }) {
  // 사용자가 url을 넘기면 자바스크립트로 강제로 창을 이동시킨다!
  const pushLink = () => window.location.href = url;
 
  return <div className="btn" onClick={url ? pushLink : undefined}>{title}</div>
}

• A) div를 렌더링하면 React가 컴파일 타임에 이를 거부한다.
• B) 이 버튼은 구글 검색 엔진 로봇(Bot)이 파싱할 때 그저 "아무런 이동 기능이 없는 글자 한 줄(div블록)"으로 취급하므로 사이트 간 연결 고리(SEO)가 깨진다. 또한, 키보드 Tab 키를 누르는 시각/지체 장애인 유저들이 이 버튼에 도달조차 할 수 없고, 엔터 키를 쳐도 아무 일도 벌어지지 않는다.
• C) 이 버튼은 div 태그로 얽매여 있기에 스타일(className="btn")이 밖으로 새어 나가 글로벌 오염을 일으키는 버그를 유발한다.

✅ 정답: B

💡 상세 해설: div에 onClick을 붙여 앵커 이동을 흉내 내면 링크의 의미, 키보드 접근성, 검색 엔진이 이해하는 연결 구조가 모두 약해집니다. 이동 동작은 실제 <a>나 프레임워크의 Link로 표현하고, 버튼 동작은 네이티브 <button>으로 표현하는 것이 기본입니다.

Q2. 최근 UI 라이브러리(Radix UI 등)가 제공하는 asChild 혹은 Slot 패턴이, 기존 as="a" 방식보다 선호되는 핵심적인 개발 경험(DX) 이유를 주관식으로 설명해보세요.
✅ 정답 및 주관식 해설:
"기존 as="a" 방식은 부모 컴포넌트가 href나 target="_blank" 같은 자식 태그의 속성까지 넓게 받아야 해서 제네릭 타입이 복잡해지기 쉽습니다. 반면 asChild(Slot) 패턴은 실제 태그를 자식이 책임지고, 부모는 공통 스타일과 이벤트만 병합하므로 props 충돌과 타입 분기를 줄일 수 있습니다."

Q3. 영철이의 테스트 타임: 영숙이 아이콘만 보이는 "알림 설정 열기" 버튼을 디자인 시스템에 추가했습니다. 같은 스타일은 <button>과 <a> 양쪽에서 재사용되어야 하고, 키보드 사용자와 스크린 리더 사용자도 사용할 수 있어야 합니다. 영호가 승인할 구현은 무엇인가요?

• A) <div onClick>에 CSS를 입히고, 아이콘만 넣는다. 마우스로 클릭되므로 충분하다.
• B) 기본 동작은 네이티브 <button>으로 두고, 링크가 필요할 때는 as나 asChild로 실제 <a>/Link를 렌더링한다. 아이콘 전용 버튼에는 aria-label 같은 접근 가능한 이름을 제공한다.
• C) 모든 버튼을 <a href="#">로 통일하고, 제출 동작은 preventDefault()로 흉내 낸다.

✅ 정답: B

💡 상세 해설: 디자인 시스템의 다형성은 "모양은 같게, 의미는 정확하게" 만드는 일입니다. 클릭 액션은 <button>, 이동은 <a>/Link가 맡아야 브라우저 기본 키보드 동작, SEO, 스크린 리더 의미가 살아납니다. 아이콘만 있는 컨트롤은 보이는 텍스트가 없으므로 aria-label처럼 접근 가능한 이름도 필요합니다. 영호라면 CSS 재사용보다 태그 의미와 접근성 계약을 먼저 확인할 겁니다.

🐣 영철이의 퇴근 일기

디자인이 같다는 이유로 링크도 버튼도 전부 한 컴포넌트로 우겨 넣던 코드가 떠올랐다. 오늘은 다형성이 단순히 CSS 중복을 줄이는 패턴이 아니라, 같은 시각 디자인 안에서도 HTML 의미를 정확히 보존하는 설계라는 걸 배웠다.

💡 "디자인은 공유하되 의미는 속이지 말자. 이동은 링크, 실행은 버튼, 아이콘 전용 컨트롤은 접근 가능한 이름까지가 계약이다."

영호 선배가 "컴포넌트 API가 예뻐도 키보드로 못 쓰면 디자인 시스템이 아니다"라고 한 게 오래 남는다. 내일부터 공통 컴포넌트를 리뷰할 때는 as/asChild 타입보다 먼저 실제 렌더링 태그, 포커스 가능 여부, 접근 가능한 이름, 링크의 SEO 의미를 체크하겠다. 영철도 이제 예쁜 컴포넌트가 아니라 사용 가능한 컴포넌트를 설계해야 한다.