브레드크럼(Breadcrumbs): 웹에서 필수 도구인가, 재평가 대상인가?

브레드크럼(Breadcrumbs)은 현재 페이지가 사이트의 어디에 속하는지 보여주고 상위로 이동하게 하는 내비게이션입니다. “브레드크럼은 죽었다”는 글을 보고, 저는 이 사망 선고가 성급하다고 느꼈어요.

다만 익숙한 패턴이니 무조건 넣자는 주장에도 동의하지 않습니다. 중요한 질문은 사용자가 현재 위치를 이해하거나 상위 범주로 이동해야 하는데, 다른 내비게이션만으로 충분한가입니다.

상위 계층과 현재 위치를 함께 보여주는 브레드크럼

먼저 세 가지를 구분하기

화면 위에 경로처럼 나열된 UI라도 같은 역할은 아닙니다.

종류	보여주는 것	예시
위치 기반	현재 페이지의 정보 계층	제품 → 노트북 → 모델 A
이력 기반	사용자가 실제로 지나온 경로	검색 결과 → 모델 A
속성·필터 표시	선택한 탐색 조건	노트북 · 14인치 · 재고 있음

홈 → 제품 → 노트북은 브라우저 방문 기록이 아닙니다. 사용자가 검색 엔진에서 곧바로 제품 상세로 들어왔어도 표시할 수 있어요. 이 계층으로 돌아가 비슷한 제품을 둘러보게 돕는 것이 목적이기 때문입니다. W3C 브레드크럼 패턴

반면 “검색 결과로 돌아가기”는 검색어·필터·페이지 번호를 복원하는 동작입니다. 필요하다면 위치 기반 브레드크럼과 별도 링크로 제공하는 편이 명확해요. 두 역할을 섞으면 같은 제품의 경로가 방문 순서마다 달라져 구조를 이해하기 어려울 수 있습니다.

무엇이 있으면 가치가 커질까

검색이 좋아져서 중간 계층을 거치지 않는 경우에도 브레드크럼은 쓸모가 있습니다. 오히려 상세 페이지로 처음 들어왔을 때 “이 제품이 어떤 범주에 속하지?”라는 질문에 답할 수 있어요.

다만 깊이가 3단계 이상이면 반드시 넣어야 한다는 기준은 없습니다. 링크가 실제로 의미 있는 상위 목적지로 이어지는지가 중요합니다.

화면의 상황	판단
깊은 제품 분류·기술 문서, 상세 페이지 직접 유입	상위 탐색을 돕는 브레드크럼을 검토
한두 화면의 단순 서비스	제목과 주 내비게이션으로 충분한지 먼저 확인
여러 카테고리에 속하는 같은 항목	대표 경로 또는 맥락별 경로 정책을 먼저 정의
검색·필터 중심의 업무 목록	브레드크럼보다 목록 상태 복원이 더 중요할 수 있음
단계별 작성·결제 화면	정보 계층보다 진행 단계 표시가 더 적합할 수 있음

URL을 /로 나눠 그대로 표시하는 것으로 정보 구조가 완성되지는 않습니다. /app/items/123/edit에서 app, 123을 사용자에게 보여줄 이유는 없죠. 라우트와 리소스의 이름을 기반으로 사람이 이해하는 경로를 구성해야 합니다.

여러 범주에 속한 제품은 더 신중해야 합니다. 같은 모델이 “업무용”과 “가벼운 노트북”에 속한다면 하나의 절대 경로만 정답이라고 말할 수 없습니다. 정책을 일관되게 적용하고, 직접 유입했을 때의 경로도 정해두면 예측 가능성이 높아집니다.

접근성은 작은 HTML에서 시작한다

다음은 위치 기반 브레드크럼의 예시입니다. 사이트의 실제 경로에 맞게 href를 바꿔야 합니다.

<nav aria-label="현재 위치">
  <ol class="breadcrumbs">
    <li><a href="/">홈</a></li>
    <li>
      <span aria-hidden="true">/</span>
      <a href="/products/">제품</a>
    </li>
    <li>
      <span aria-hidden="true">/</span>
      <span aria-current="page">노트북</span>
    </li>
  </ol>
</nav>

nav는 내비게이션 영역을, 레이블은 그 목적을 구분합니다. 목록은 항목의 순서를 나타내고, 구분 기호는 장식이므로 aria-hidden으로 제외했습니다. 기본 링크를 사용하면 별도의 키보드 이동 규칙을 구현할 필요가 없습니다.

W3C 패턴에서는 현재 페이지가 링크라면 aria-current="page"로 표시하도록 설명합니다. 현재 페이지를 링크가 아닌 텍스트로 표시하면 aria-current는 선택 사항입니다. 위 예시는 의미를 명시하기 위해 붙였어요. ARIA를 많이 붙이는 것과 접근성을 잘 구현하는 것은 다릅니다. W3C ARIA 브레드크럼 지침

SPA에서도 링크의 주소가 의미 있어야 합니다. 상위 항목을 누르면 예상한 목록이 나오고, 키보드 초점이 화면에서 보이며, 긴 제목을 확대해도 탐색을 방해하지 않는지 확인해야 해요.

모바일에서는 남길 정보를 먼저 고르기

긴 경로를 무조건 한 줄에 밀어 넣으면 글자가 너무 작아지거나 링크를 누르기 어려워집니다. 두 줄로 감싸는 방식, 중간 항목만 접는 방식, 바로 위 부모만 제공하는 방식 중 실제 과제에 맞는 것을 고르면 됩니다.

부모 하나만 남긴다면 뒤로 대신 노트북 목록처럼 목적지를 드러내는 레이블이 낫습니다. 브라우저의 이전 페이지와 상위 계층은 다를 수 있기 때문입니다. 중간 항목을 접는 버튼에는 무엇을 여는지 이름을 주고 펼침 상태를 전달해야 해요. 접기 UI 때문에 새 조작이 늘어나는 비용도 함께 봐야 합니다.

화면의 브레드크럼과 검색용 데이터는 별개다

위 HTML은 사람과 보조 기술을 위한 내비게이션입니다. Google의 검색용 BreadcrumbList 구조화된 데이터는 별도로 작성합니다. HTML에 aria-current를 붙였다고 JSON-LD가 자동으로 생기는 것은 아니에요.

Google은 구조화된 데이터가 있더라도 검색 결과 표시를 보장하지 않습니다. 브레드크럼을 추가했다는 사실만으로 검색 순위 상승을 약속할 수도 없습니다. Google BreadcrumbList 문서

또한 Google은 2025년 1월 모바일 검색 결과의 URL 표시에서 브레드크럼을 없애고 도메인만 표시하는 변경을 발표했습니다. 데스크톱에는 경로 표시를 유지한다고 설명했어요. 검색 결과에서의 표시 정책과 사이트 내부 브레드크럼의 탐색 가치는 구분해야 합니다. Google 모바일 URL 표시 변경

넣은 뒤에는 클릭률보다 과제 성공을 보기

브레드크럼 클릭률이 낮다고 바로 실패라고 판단하기는 어렵습니다. 사용자는 클릭하지 않고도 현재 위치를 확인할 수 있어요. 반대로 클릭이 많아도 주 메뉴가 혼란스러워 우회하는 것일 수 있습니다.

확인하고 싶은 것은 구체적인 과제입니다. 상세 페이지로 바로 들어온 사용자가 상위 범주를 설명할 수 있는지, 비슷한 항목을 찾을 수 있는지, 검색에서 왔을 때 목록으로 돌아가는 경로를 혼동하지 않는지 살펴보면 좋아요. 키보드와 좁은 화면에서도 같은 일을 할 수 있는지도 포함합니다.

저는 브레드크럼을 사이트의 완성도를 보여주는 장식으로 넣고 싶지는 않습니다. 실제 계층과 유용한 상위 목적지가 있고, 사용자가 그 관계를 이해할 필요가 있을 때 쓰면 됩니다. 그 조건이 없다면 브레드크럼부터 만들기보다 정보 구조와 주 내비게이션을 먼저 정리하는 편이 낫습니다.