/ 우리는 이렇게 합니다 / 탭 하나에 담당 셋
UX 설계 · 합작

탭 하나에, 담당 셋이 붙습니다.

탭은 “네모 버튼 누르면 아래가 바뀌는 거” 아니냐고들 합니다. 맞습니다. 그런데 그 작은 컴포넌트 하나에 우리는 셋이 모입니다. 무엇을 한 묶음으로 볼지 정하는 UX, 바뀌는 순간을 부드럽게 잇는 모션, 탭과 내용을 흐트러지지 않게 세우는 레이아웃. 아래 탭, 진짜로 동작합니다. 눌러보세요.

한 줄 직답

탭은 ‘같은 주제의 형제 정보’를 좁은 공간에서 골라 보게 하는 도구입니다. Findable은 무엇을 묶을지(UX), 어떻게 바꿀지(모션), 어떻게 정렬할지(레이아웃)를 담당이 같이 정하고, 검색 노출·키보드·축소 모션 같은 기본을 함께 챙깁니다.

요약

  • 탭은 형제 정보를 ‘좁은 공간에서 골라 보기’ 위한 것 — 한 번에 다 봐야 하는 내용은 탭에 숨기지 않는다.
  • 한 탭에 담당이 셋이다 — 무엇을 묶을지(UX), 전환(모션), 정렬(레이아웃)을 같이 정한다.
  • 탭 뒤 내용은 hidden으로 HTML에 두면 검색에 잡히지만, 자바스크립트로 나중에 불러오면 누락될 수 있다.
  • 탭은 Tab·Enter로 조작되고 포커스 링이 보여야 한다 — 키보드와 축소 모션은 기본값.

처음 이 탭을 그릴 때 회의가 짧게 한 번 엇갈렸습니다. UX 담당은 “검색·AI 답변·전환, 세 가지를 한 자리에서 비교하게 하자”고 했고, 레이아웃 담당은 “세 개를 좌우로 늘어놓으면 모바일에서 줄이 무너진다”고 했고, 모션 담당은 “바뀌는 게 너무 갑작스러우면 사람이 못 따라온다”고 했습니다. 셋 다 맞는 말이었습니다. 그래서 우리는 ‘각자 옳은 말’을 한 컴포넌트 안에서 맞물리게 했습니다. 그 결과가 아래에 있습니다.

그래서, 직접 눌러보세요

설명보다 빠릅니다. 탭 세 개를 차례로 눌러보고, 마우스 없이 Tab 키로도 이동해 보세요. 누가 무엇을 맡았는지는 바로 아래에 적었습니다.

Live · 합작 · 인터랙티브 탭

탭을 눌러 전환되는 콘텐츠

한 공간에 여러 이야기를 담는 탭 — UX·모션·레이아웃 담당이 함께.

검색에 발견

구글·네이버 + 구조화 데이터로 꾸준히 발견되게 합니다.

UX 담당: 무엇을 ‘한 묶음’으로 볼지부터 정합니다

탭의 절반은 디자인이 아니라 분류입니다. 위 탭에는 ‘검색 / AI 답변 / 전환’ 세 가지가 들어 있습니다. 셋은 따로 떨어진 주제가 아니라 ‘사람이 우리 사이트를 만나는 단계’라는 같은 부모를 가진 형제입니다. 형제가 아니면 탭에 넣지 않습니다. 서로 관계없는 것들을 탭으로 묶으면 사용자는 다음 탭에 뭐가 있을지 예측하지 못하고, 결국 안 누릅니다. 그래서 UX 담당은 라벨을 먼저 종이에 적어 “이 셋이 진짜 같은 줄에 설 수 있나”를 검사합니다.

그런데 탭, 아무 데나 쓰면 안 됩니다

탭의 단점은 분명합니다. 한 번에 하나만 보입니다. 그래서 한꺼번에 비교해야 의미가 있는 정보(요금표의 플랜들처럼)를 탭으로 나누면 사용자는 탭을 왔다 갔다 하며 머릿속으로 비교해야 합니다. 피곤한 일입니다. 또 순서가 있는 절차(1→2→3단계)는 탭보다 스텝 UI가 맞고, 검색에 꼭 잡혀야 하는 핵심 본문은 탭 뒤에 숨기지 않습니다. 우리는 새 탭을 넣기 전에 “이걸 굳이 숨겨도 되나?”를 먼저 물어봅니다. 답이 ‘아니오’면 그냥 펼쳐 둡니다.

레이아웃 담당: 탭이 흔들리지 않게 세웁니다

탭에서 가장 거슬리는 건 ‘점프’입니다. 짧은 내용 탭에서 긴 내용 탭으로 넘어갈 때 영역 높이가 확 바뀌면 페이지 전체가 들썩이고, 아래 버튼이 손가락 밑에서 도망갑니다. 레이아웃 담당은 탭 버튼 줄을 한 줄에 정렬하고, 패널의 좌우 여백·글머리 위치를 모든 탭에서 똑같이 맞춰 ‘바뀐 건 내용뿐’이라는 인상을 만듭니다. 모바일에서 탭 셋이 너무 좁아지면 줄을 바꾸거나 아코디언으로 형태를 바꾸는 판단도 여기서 합니다.

모션 담당: 바뀌는 ‘순간’만 책임집니다

탭을 누르면 내용이 톡 하고 갈리는 대신, 짧게 페이드되며 바뀝니다. 이 0.2초의 역할은 장식이 아니라 안내입니다. “방금 네가 누른 게 먹혔고, 지금 다른 내용으로 바뀌었다”를 눈으로 알려주는 겁니다. 다만 전환을 길거나 화려하게 만들면 그게 곧 기다림이 됩니다. 그래서 모션 담당은 전환을 짧게 잡고, prefers-reduced-motion을 켠 사용자에게는 애니메이션을 끄고 즉시 바꿉니다. 멀미를 만들지 않는 것까지가 모션의 일입니다.

접근성: 마우스 없이도 다 됩니다

위 탭을 Tab 키로 짚어 보면 포커스 링이 살아 있고, Enter나 Space로 전환됩니다. 화면낭독기 사용자를 위해 탭 버튼에는 ‘선택됨’ 상태와 어떤 패널을 여는지가 표시됩니다. 탭이 멋있어도 키보드로 못 쓰면 누군가는 그 내용을 영영 못 봅니다. 그래서 접근성은 세 담당이 각자 챙기는 게 아니라, 셋이 합쳐질 때 같이 점검하는 공통 항목입니다.

항목내용 다 펼치기탭으로 정리
스캔성다 보이지만 길어서 어디가 핵심인지 흐려짐관심 있는 한 묶음만 골라 본다
페이지 길이세 배로 늘어나 스크롤이 길어짐한 화면에 담겨 짧고 깔끔하다
집중비교는 쉬우나 시선이 분산됨한 번에 하나라 한 주제에 집중

물론 정답은 한쪽이 아닙니다. 한꺼번에 비교해야 하는 정보라면 펼치는 게 낫고, 형제 정보를 골라 보게 하려면 탭이 낫습니다. 우리가 회의에서 가장 오래 정하는 건 디자인이 아니라 바로 이 ‘어느 쪽이냐’입니다.

제가(UX 담당) 탭을 설계할 때 사용자가 라벨을 눌러 원하는 내용에 닿는 탐색 동선은 이렇게 흘러갑니다.

탭 탐색 동선 — 라벨에서 내용까지
탭 묶음 인지라벨로 원하는 묶음 판단탭 클릭/Enter짧은 페이드 전환‘선택됨’ 상태 확인해당 패널 읽기

그리고 탭에서 탐색이 끊기는 자리는 정해져 있습니다. 어디서 막히고, 세 담당이 그걸 무엇으로 푸는지 정리했습니다.

탐색 단계별 마찰과 해결
탐색 단계사용자가 막히는 지점해결(담당)
묶음 판단라벨이 모호해 어느 탭에 뭐가 있는지 모름형제 정보만 한 묶음으로(UX)
현재 위치지금 어느 탭을 보는지 흐림활성 탭을 또렷이·줄 안 흔들리게(레이아웃)
전환 순간내용이 톡 끊겨 바뀐 줄 모름0.2초 페이드로 ‘바뀌었다’ 신호(모션)
키보드 사용마우스 없이는 탭 전환 불가Tab 포커스·Enter/Space·선택됨 표시(공통)

같은 컴포넌트를 세 시선으로 보면, 라벨에서 내용까지 가는 길에 빈틈이 줄어듭니다.

다른 담당자와의 연결

탭 하나는 결국 세 일의 합입니다. 어떻게 묶을지는 UX 담당이 정보를 묶는 방식에서, 어떻게 바꿀지는 모션 담당의 전환 설계에서, 어떻게 세울지는 레이아웃 담당이 줄을 맞추는 법에서 더 자세히 다룹니다. 같은 컴포넌트를 세 시선으로 보면 빈틈이 줄어듭니다.

탭은 언제 쓰고 언제 쓰지 말아야 하나요?
같은 주제의 ‘형제’ 정보를 한 공간에서 골라 보게 할 때 탭이 맞습니다. 한 번에 다 봐야 비교가 되는 정보, 검색엔진에 다 노출돼야 하는 본문, 단계별로 순서가 있는 절차는 탭에 숨기지 말고 펼쳐 두는 편이 낫습니다.
탭 안의 내용은 검색에 노출되나요?
숨겨진 패널을 hidden 속성으로 두고 HTML에 그대로 담으면 구글은 대부분 읽습니다. display:none으로 가리거나 클릭해야 자바스크립트로 불러오는 방식이면 누락될 수 있습니다. 검색에 꼭 잡혀야 하는 문장은 탭 뒤에 두지 않는 것이 안전합니다.
탭과 아코디언은 어떻게 구분하나요?
한 번에 하나만 보면 되고 좌우로 나란히 둘 공간이 있으면 탭, 여러 항목을 위아래로 펼치고 접으며 스캔하는 흐름이면 아코디언입니다. 모바일에서 탭이 너무 좁아지면 아코디언으로 바꾸는 것도 방법입니다.
탭은 키보드로도 쓸 수 있어야 하나요?
네. 탭 버튼은 Tab으로 닿고 Enter·Space로 전환되며, 활성 탭에는 포커스 링이 보여야 합니다. role=tab·aria-selected·aria-controls를 붙이면 화면낭독기 사용자도 ‘세 개 중 첫 번째 탭’임을 압니다.
탭 전환에 애니메이션을 넣어도 되나요?
짧은 페이드 정도면 ‘바뀌었다’를 알려 도움이 됩니다. 다만 길고 화려한 전환은 기다림이 되고, prefers-reduced-motion을 켠 사용자에게는 꺼야 합니다. 전환은 내용을 가리지 않는 선에서 0.2초 안팎이면 충분합니다.

이렇게 한 컴포넌트를 셋이 봅니다

탭 하나도 UX·모션·레이아웃 담당이 같이 맞추는 팀이 당신의 홈페이지를 만들면 어떨까요. 무료 진단으로 시작하세요.

무료 진단 받기

이 글의 탭은 이 페이지에서 실제로 동작하는 코드입니다(전환·키보드·hidden 패널 모두 라이브). 본문의 원칙은 일반적인 UX·접근성 권고이며 특정 성과를 보장하지 않습니다. 날조된 사례·이름·수치는 사용하지 않았습니다.