솔직히 고백하자면, 저도 한때 햄버거 메뉴가 "깔끔하다"고 생각했습니다. 메인 화면을 건드리지 않아도 되고, 아이콘 하나로 모든 기능을 숨길 수 있으니까요. 그런데 모바일 뱅킹 앱을 리디자인하면서 그 생각이 완전히 뒤집혔습니다. 주요 기능에 도달하는 평균 탭 수가 3.2회에서 1.4회로 줄고, 첫 사용일 기준 작업 완료 시간이 12.8초에서 7.1초로 단축되는 걸 숫자로 확인하고 나서야 하단 탭바가 단순한 디자인 선택이 아니라 사용성의 핵심 구조임을 실감했습니다.
발견성을 결정하는 구조, 탭바에 무엇을 담을 것인가
앱을 처음 켠 사람이 "이 기능이 어디 있지?"라고 헤매기 시작하면 그건 콘텐츠 문제가 아니라 네비게이션 문제입니다. 저는 이것을 발견성(discoverability)이라는 개념으로 정리합니다. 여기서 발견성이란 사용자가 아무런 학습 없이 원하는 기능을 얼마나 빠르게 찾아낼 수 있는지를 나타내는 UX 지표입니다. 햄버거 메뉴는 이 발견성을 가장 빠르게 무너뜨리는 구조입니다. 기능이 드로어 안에 숨어 있으면 사용자는 메뉴를 열어봐야만 선택지를 확인할 수 있고, 그 순간 인지 부하가 급증합니다.
제가 작업했던 뱅킹 앱도 마찬가지였습니다. 기존에는 햄버거 메뉴 안에 이체, 조회, 카드, 설정이 모두 들어 있었고, 사용자들은 매번 드로어를 열고 스크롤하고 탭하는 3단계 동작을 반복해야 했습니다. 탭바로 교체하면서 홈·이체·조회·카드·전체메뉴 순으로 재배치했더니 이 3단계가 1단계로 줄었습니다. 수치가 달라진 건 디자인이 바뀌어서가 아니라 구조가 바뀌었기 때문입니다.
탭바에 담을 항목을 고를 때 저는 힉의 법칙(Hick's Law)을 판단 기준으로 씁니다. 힉의 법칙이란 선택지의 수가 늘어날수록 사람이 결정을 내리는 데 걸리는 시간이 로그함수적으로 증가한다는 원리입니다. 탭이 많아질수록 사용자는 어느 탭을 눌러야 할지 판단하는 데 더 오래 걸린다는 뜻입니다. 그래서 Apple Human Interface Guidelines는 탭바 항목을 최대 5개로 권장하고, Google의 Material Design도 3개에서 5개를 표준으로 제시합니다. 두 플랫폼이 같은 결론에 수렴한다는 사실은 이것이 취향이 아니라 인지과학에서 나온 기준임을 보여줍니다(출처: Apple Human Interface Guidelines).
탭바에 넣으면 안 되는 항목도 있습니다. 로그아웃, 도움말, 개인정보처리방침 같은 항목은 사용자가 매일 쓰는 기능이 아닙니다. 이런 것들을 탭바에 올리면 정작 중요한 기능이 밀려납니다. 저는 '전체메뉴' 탭을 두고 기존 햄버거 드로어 항목들을 그리드 형태로 재배치하는 하이브리드 구조를 선택했는데, 드로어보다 스캔 속도가 훨씬 빨라졌습니다.
터치타겟과 안전 영역, 손가락이 편한 설계
탭바를 설계할 때 가장 쉽게 놓치는 부분이 터치타겟(touch target) 크기입니다. 터치타겟이란 사용자가 실제로 손가락으로 누를 수 있는 반응 영역을 말하며, 눈에 보이는 아이콘 크기와 다릅니다. 아이콘이 24픽셀이어도 터치타겟은 44픽셀 이상으로 확보해야 실수로 잘못 누르는 오탭(mis-tap)을 줄일 수 있습니다.
저는 이번 작업에서 탭 하나당 터치타겟을 48x48dp로 설정했습니다. Apple과 Google 모두 44pt 이상을 권장하는데, dp 기준으로 48dp면 대부분의 성인 엄지손가락이 편하게 닿는 크기입니다. 솔직히 처음에는 "48이면 탭바가 너무 커지지 않나?" 걱정했는데, 탭바 전체 높이를 56dp로 설정하고 내부 패딩을 균형 있게 배분하니 시각적으로 전혀 무겁지 않았습니다.
그것보다 더 놓치기 쉬운 게 홈 인디케이터 영역입니다. 홈 인디케이터란 아이폰 및 물리 버튼 없는 안드로이드 기기 하단에 표시되는 얇은 제스처 바로, 사용자가 홈 화면으로 돌아가거나 앱 전환을 할 때 사용하는 시스템 UI 요소입니다. 탭바가 이 영역과 겹치면 사용자가 탭 아이콘을 누르려다 홈 화면으로 빠져나가버리는 오작동이 발생합니다. 저는 safe area inset을 코드 수준에서 자동으로 추가해 제스처 바 충돌을 완전히 없앴습니다. Figma에서 보기 좋아 보여도 실기기에서 직접 눌러보면 전혀 다르게 느껴지기 때문에, 실기기 테스트는 절대 생략하면 안 됩니다.
피츠의 법칙(Fitts's Law)도 여기서 함께 작동합니다. 피츠의 법칙이란 목표물이 클수록, 그리고 가까울수록 사용자가 더 빠르고 정확하게 도달할 수 있다는 원리입니다. 탭바가 화면 하단에 있는 이유가 바로 이것입니다. 엄지손가락이 자연스럽게 닿는 위치이고, 충분한 크기를 확보하면 정확도가 올라갑니다.
아이콘 스타일과 상태 구분, 사용자가 "지금 어디 있는지" 아는 방법
탭바 아이콘 하나를 두고도 생각보다 많은 결정이 필요합니다. 가장 먼저 결정해야 하는 건 라인 스타일(outline)로 갈 것인지 솔리드 스타일(solid/filled)로 갈 것인지입니다. 어느 쪽이든 상관없지만, 두 스타일을 한 탭바 안에 섞으면 안 됩니다. 저는 라인 스타일을 기본으로, 활성 탭에만 솔리드 스타일을 적용하는 방식을 선택했습니다. 이렇게 하면 아이콘 스타일 변화만으로도 현재 위치가 명확하게 드러납니다.
활성 상태(active state)를 표현할 때는 시각적 변화를 두 가지 이상 동시에 주는 게 핵심입니다. 색상만 바꾸거나 아이콘 모양만 바꾸는 것보다, 두 가지를 함께 바꾸면 사용자가 현재 위치를 즉각적으로 인식할 수 있습니다. 저는 아이콘 스타일 변화(라인→솔리드) + 브랜드 컬러 적용 + 라벨 텍스트 굵기 변화를 조합했습니다.
비활성 상태의 명도 처리도 중요합니다. WCAG(Web Content Accessibility Guidelines)에서는 텍스트 이외의 UI 컴포넌트에 대해 최소 명암비 3:1을 요구합니다. 여기서 WCAG란 W3C가 제정한 웹 접근성 지침으로, 시각 장애나 색각 이상이 있는 사용자도 정보를 인식할 수 있도록 최소 기준을 규정한 국제 표준입니다(출처: W3C Web Content Accessibility Guidelines). 저는 라벨에 12pt Noto Sans KR Regular를 적용하고 명암비 4.5:1을 확보했는데, 이는 텍스트 기준 AA 등급을 만족하는 수치입니다. 접근성 기준을 지키는 게 특정 사용자를 위한 배려처럼 보이지만, 실제로는 모든 사용자의 가독성을 높이는 결과로 이어집니다.
아이콘 선택 기준도 간단합니다. 검색이면 돋보기, 홈이면 집 모양, 알림이면 벨. 이미 전 세계 수십억 명이 학습한 기호를 쓰면 사용자가 아무 설명 없이 이해합니다. 야콥의 법칙(Jakob's Law)에 따르면 사용자는 자신이 이미 알고 있는 방식으로 작동하길 기대합니다. 독창적인 아이콘은 앱을 기억에 남게 하기보다 혼란을 유발할 가능성이 더 큽니다.
마이크로인터랙션, 느낌을 설계하는 마지막 단계
탭바가 구조적으로 완성되면 그다음 질문은 "이게 좋은가, 아니면 좋은 느낌인가?"입니다. 마이크로인터랙션(micro-interaction)이란 사용자의 단일 행동에 반응하는 작은 애니메이션이나 피드백 요소를 말하며, 앱이 살아있다는 인상을 만드는 역할을 합니다. 탭을 누를 때 아무 반응이 없으면 "제대로 눌린 건가?" 하는 의심이 생깁니다. 반대로 탭 순간 아이콘이 살짝 커지거나 색이 바뀌면 "눌렸다"는 확신이 들고 신뢰감이 생깁니다.
제가 이번 작업에서 아쉬웠던 부분이 바로 여기였습니다. 구조적 개선에 집중하다 보니 탭 전환 시 슬라이드 언더라인 애니메이션이나 화면 전환 페이드 효과를 제대로 챙기지 못했습니다. 나중에 사용자 인터뷰를 해보니 "탭을 눌러도 뭔가 바뀌는 느낌이 약하다"는 피드백이 몇 건 들어왔습니다. 수치는 개선됐는데 체감은 그보다 덜했던 이유가 이것이었던 것 같습니다.
마이크로인터랙션에서 주의할 점은 과하면 안 된다는 것입니다. 탭 하나 누를 때마다 긴 애니메이션이 재생되면 오히려 속도감이 떨어지고 답답해집니다. 빠르고 가볍게, 100~200ms 수준의 짧은 전환이면 충분합니다. 핵심 설계 포인트를 정리하면 다음과 같습니다.
- 탭 피드백: 아이콘 스케일 업(1.0→1.1) 또는 컬러 체인지, 100ms 이내
- 탭 전환 표시: 슬라이딩 언더라인 또는 배경 필 애니메이션, 150ms 이내
- 화면 전환: 페이드 인/아웃 또는 사이드 슬라이드, 200ms 이내
이 세 가지만 챙겨도 탭바의 체감 품질이 확실히 달라집니다. 구조를 바꾼 뒤 마이크로인터랙션까지 완성했을 때, 그 앱은 "쓸 만한 앱"에서 "좋은 앱"으로 넘어갑니다.
결국 하단 탭바 하나를 제대로 설계하려면 발견성, 터치 정확도, 시각적 상태 구분, 피드백 애니메이션이라는 네 층이 모두 맞아야 합니다. 어느 하나만 바꿔서는 사용자가 달라진 걸 체감하기 어렵습니다. 탭바 리디자인을 고려하고 계신다면, 먼저 현재 앱에서 사용자가 주요 기능에 도달하는 탭 수를 직접 세어보시길 권합니다. 그 숫자가 3 이상이라면, 바꿔야 할 이유는 이미 충분합니다.