탭은 ‘같은 주제의 형제 정보’를 좁은 공간에서 골라 보게 하는 도구입니다. Findable은 무엇을 묶을지(UX), 어떻게 바꿀지(모션), 어떻게 정렬할지(레이아웃)를 담당이 같이 정하고, 검색 노출·키보드·축소 모션 같은 기본을 함께 챙깁니다.
요약
- 탭은 형제 정보를 ‘좁은 공간에서 골라 보기’ 위한 것 — 한 번에 다 봐야 하는 내용은 탭에 숨기지 않는다.
- 한 탭에 담당이 셋이다 — 무엇을 묶을지(UX), 전환(모션), 정렬(레이아웃)을 같이 정한다.
- 탭 뒤 내용은 hidden으로 HTML에 두면 검색에 잡히지만, 자바스크립트로 나중에 불러오면 누락될 수 있다.
- 탭은 Tab·Enter로 조작되고 포커스 링이 보여야 한다 — 키보드와 축소 모션은 기본값.
처음 이 탭을 그릴 때 회의가 짧게 한 번 엇갈렸습니다. UX 담당은 “검색·AI 답변·전환, 세 가지를 한 자리에서 비교하게 하자”고 했고, 레이아웃 담당은 “세 개를 좌우로 늘어놓으면 모바일에서 줄이 무너진다”고 했고, 모션 담당은 “바뀌는 게 너무 갑작스러우면 사람이 못 따라온다”고 했습니다. 셋 다 맞는 말이었습니다. 그래서 우리는 ‘각자 옳은 말’을 한 컴포넌트 안에서 맞물리게 했습니다. 그 결과가 아래에 있습니다.
그래서, 직접 눌러보세요
설명보다 빠릅니다. 탭 세 개를 차례로 눌러보고, 마우스 없이 Tab 키로도 이동해 보세요. 누가 무엇을 맡았는지는 바로 아래에 적었습니다.
탭을 눌러 전환되는 콘텐츠
한 공간에 여러 이야기를 담는 탭 — UX·모션·레이아웃 담당이 함께.
검색에 발견
구글·네이버 + 구조화 데이터로 꾸준히 발견되게 합니다.
AI 답변에 인용
answer block·llms.txt로 생성형 AI가 인용하게 만듭니다.
문의로 전환
흐름·폼·버튼 설계로 방문을 문의로 바꿉니다.
UX 담당: 무엇을 ‘한 묶음’으로 볼지부터 정합니다
탭의 절반은 디자인이 아니라 분류입니다. 위 탭에는 ‘검색 / AI 답변 / 전환’ 세 가지가 들어 있습니다. 셋은 따로 떨어진 주제가 아니라 ‘사람이 우리 사이트를 만나는 단계’라는 같은 부모를 가진 형제입니다. 형제가 아니면 탭에 넣지 않습니다. 서로 관계없는 것들을 탭으로 묶으면 사용자는 다음 탭에 뭐가 있을지 예측하지 못하고, 결국 안 누릅니다. 그래서 UX 담당은 라벨을 먼저 종이에 적어 “이 셋이 진짜 같은 줄에 설 수 있나”를 검사합니다.
그런데 탭, 아무 데나 쓰면 안 됩니다
탭의 단점은 분명합니다. 한 번에 하나만 보입니다. 그래서 한꺼번에 비교해야 의미가 있는 정보(요금표의 플랜들처럼)를 탭으로 나누면 사용자는 탭을 왔다 갔다 하며 머릿속으로 비교해야 합니다. 피곤한 일입니다. 또 순서가 있는 절차(1→2→3단계)는 탭보다 스텝 UI가 맞고, 검색에 꼭 잡혀야 하는 핵심 본문은 탭 뒤에 숨기지 않습니다. 우리는 새 탭을 넣기 전에 “이걸 굳이 숨겨도 되나?”를 먼저 물어봅니다. 답이 ‘아니오’면 그냥 펼쳐 둡니다.
레이아웃 담당: 탭이 흔들리지 않게 세웁니다
탭에서 가장 거슬리는 건 ‘점프’입니다. 짧은 내용 탭에서 긴 내용 탭으로 넘어갈 때 영역 높이가 확 바뀌면 페이지 전체가 들썩이고, 아래 버튼이 손가락 밑에서 도망갑니다. 레이아웃 담당은 탭 버튼 줄을 한 줄에 정렬하고, 패널의 좌우 여백·글머리 위치를 모든 탭에서 똑같이 맞춰 ‘바뀐 건 내용뿐’이라는 인상을 만듭니다. 모바일에서 탭 셋이 너무 좁아지면 줄을 바꾸거나 아코디언으로 형태를 바꾸는 판단도 여기서 합니다.
모션 담당: 바뀌는 ‘순간’만 책임집니다
탭을 누르면 내용이 톡 하고 갈리는 대신, 짧게 페이드되며 바뀝니다. 이 0.2초의 역할은 장식이 아니라 안내입니다. “방금 네가 누른 게 먹혔고, 지금 다른 내용으로 바뀌었다”를 눈으로 알려주는 겁니다. 다만 전환을 길거나 화려하게 만들면 그게 곧 기다림이 됩니다. 그래서 모션 담당은 전환을 짧게 잡고, prefers-reduced-motion을 켠 사용자에게는 애니메이션을 끄고 즉시 바꿉니다. 멀미를 만들지 않는 것까지가 모션의 일입니다.
접근성: 마우스 없이도 다 됩니다
위 탭을 Tab 키로 짚어 보면 포커스 링이 살아 있고, Enter나 Space로 전환됩니다. 화면낭독기 사용자를 위해 탭 버튼에는 ‘선택됨’ 상태와 어떤 패널을 여는지가 표시됩니다. 탭이 멋있어도 키보드로 못 쓰면 누군가는 그 내용을 영영 못 봅니다. 그래서 접근성은 세 담당이 각자 챙기는 게 아니라, 셋이 합쳐질 때 같이 점검하는 공통 항목입니다.
| 항목 | 내용 다 펼치기 | 탭으로 정리 |
|---|---|---|
| 스캔성 | 다 보이지만 길어서 어디가 핵심인지 흐려짐 | 관심 있는 한 묶음만 골라 본다 |
| 페이지 길이 | 세 배로 늘어나 스크롤이 길어짐 | 한 화면에 담겨 짧고 깔끔하다 |
| 집중 | 비교는 쉬우나 시선이 분산됨 | 한 번에 하나라 한 주제에 집중 |
물론 정답은 한쪽이 아닙니다. 한꺼번에 비교해야 하는 정보라면 펼치는 게 낫고, 형제 정보를 골라 보게 하려면 탭이 낫습니다. 우리가 회의에서 가장 오래 정하는 건 디자인이 아니라 바로 이 ‘어느 쪽이냐’입니다.
제가(UX 담당) 탭을 설계할 때 사용자가 라벨을 눌러 원하는 내용에 닿는 탐색 동선은 이렇게 흘러갑니다.
그리고 탭에서 탐색이 끊기는 자리는 정해져 있습니다. 어디서 막히고, 세 담당이 그걸 무엇으로 푸는지 정리했습니다.
| 탐색 단계 | 사용자가 막히는 지점 | 해결(담당) |
|---|---|---|
| 묶음 판단 | 라벨이 모호해 어느 탭에 뭐가 있는지 모름 | 형제 정보만 한 묶음으로(UX) |
| 현재 위치 | 지금 어느 탭을 보는지 흐림 | 활성 탭을 또렷이·줄 안 흔들리게(레이아웃) |
| 전환 순간 | 내용이 톡 끊겨 바뀐 줄 모름 | 0.2초 페이드로 ‘바뀌었다’ 신호(모션) |
| 키보드 사용 | 마우스 없이는 탭 전환 불가 | Tab 포커스·Enter/Space·선택됨 표시(공통) |
같은 컴포넌트를 세 시선으로 보면, 라벨에서 내용까지 가는 길에 빈틈이 줄어듭니다.
다른 담당자와의 연결
탭 하나는 결국 세 일의 합입니다. 어떻게 묶을지는 UX 담당이 정보를 묶는 방식에서, 어떻게 바꿀지는 모션 담당의 전환 설계에서, 어떻게 세울지는 레이아웃 담당이 줄을 맞추는 법에서 더 자세히 다룹니다. 같은 컴포넌트를 세 시선으로 보면 빈틈이 줄어듭니다.
탭은 언제 쓰고 언제 쓰지 말아야 하나요?
탭 안의 내용은 검색에 노출되나요?
탭과 아코디언은 어떻게 구분하나요?
탭은 키보드로도 쓸 수 있어야 하나요?
탭 전환에 애니메이션을 넣어도 되나요?
UX 담당이 정보를 묶는 법
무엇을 한 묶음으로 볼지 정하는 일.
모션 담당의 전환 설계
바뀌는 순간을 부드럽게 잇는 법.
담당자 합작 노트
한 화면을 여럿이 같이 만드는 이야기.
이 글의 탭은 이 페이지에서 실제로 동작하는 코드입니다(전환·키보드·hidden 패널 모두 라이브). 본문의 원칙은 일반적인 UX·접근성 권고이며 특정 성과를 보장하지 않습니다. 날조된 사례·이름·수치는 사용하지 않았습니다.