{3줄 요약}

정보 구조(Information Architecture, IA)는 콘텐츠를 어떻게 조직하고 레이블을 붙이고 연결할지를 설계하는 일이에요.
내비게이션이 복잡하거나 원하는 걸 못 찾는 대부분의 경우, 화면 디자인이 아니라 정보 구조에 문제가 있어요.
이 원칙을 어기면 아무리 예쁜 화면도 사용자가 "뭘 어디서 찾아야 하지?"라며 헤매게 해요.

찾을 수 없으면 없는 것과 같아요

어떤 앱에 아무리 좋은 기능이 있어도 사용자가 그걸 찾지 못하면 의미가 없어요.

정보 구조가 잘못되면 이런 현상이 나타나요:

  • 사용자가 특정 기능을 검색으로만 찾아요 (탐색이 실패한 신호)
  • CS에 "이 기능 어디 있나요?"라는 문의가 많아요
  • 사용 빈도가 낮은 기능이 상단에, 자주 쓰는 기능이 깊은 곳에 있어요
  • 메뉴 이름이 사용자보다 만드는 쪽의 언어로 되어 있어요

Peter Morville과 Louis
Rosenfeld는 《Information Architecture for the Web and Beyond》에서 IA의 핵심 목표를
이렇게 정의해요.
사용자가 정보를 찾고, 이해하고, 사용할 수 있게 만드는 것이라고요.

정보 구조를 구성하는 세 가지 요소

조직 체계(Organization Systems): 콘텐츠를 어떻게 그룹화하는가예요.
주제별, 타겟 사용자별, 기능별, 시간순 등 여러 방식이 있어요.

예를 들어 쿠팡은 상품을 카테고리(생활용품, 식품, 패션)로 조직하는 동시에, 사용자 행동(오늘의 딜, 마이쿠팡, 로켓배송)으로도 조직해요.
카테고리형과 태스크형이 공존해요.

레이블링(Labeling): 각 섹션이나 기능을 뭐라고 부르는가예요.
메뉴 이름, 버튼 텍스트, 탭 레이블이 여기에 해당해요.

좋은 레이블은 사용자의 언어로 쓰여요.
"콘텐츠 관리"보다 "내 글", "사용자 계정 관리"보다 "내 계정"이 사용자에게 더 직관적이에요.

내비게이션(Navigation): 사용자가 콘텐츠 사이를 어떻게 이동하는가예요.
상단 메뉴, 사이드바, 탭 바, 브레드크럼(Breadcrumb, 현재 위치를 상위 메뉴부터 순서대로 보여주는 경로 표시) 등이 내비게이션 구조예요.

정보 구조를 설계하기 전에 해야 할 것: 카드 소팅

IA를 설계할 때 가장 흔한 실수는 만드는 사람의 논리로 구조를 짜는 거예요.

개발팀 구조가 '회원', '주문', '상품', '정산'으로 나뉘어 있다고 해서 내비게이션도 그렇게 만들면 안 돼요.
사용자가 생각하는 그룹과 개발팀 구조가 다를 수 있어요.

Card Sorting(카드 소팅)은 이 문제를 해결하는 방법이에요.

콘텐츠나 기능 이름을 각각 카드에 써서 사용자에게 주고, "비슷하다고 생각하는 것끼리 묶어보세요"라고 해요.
사용자들이 어떻게 묶는지를 보면, 그들의 정신 모델이 보여요.

네이버 앱이 '뉴스', '스포츠', '연예'를 별도 탭이 아니라 하나의 '콘텐츠' 그룹으로 묶어 접근성을 높인 것, 카카오페이가 '이체', '납부', '충전'을 '보내기·받기' 그룹으로 묶은 것 - 이런 결정 뒤에는 사용자 리서치가 있어요.

Findability와 Understandability

Findability(발견 가능성): 사용자가 원하는 것을 탐색 또는 검색으로 찾을 수 있는가요.

측정 방법: "이 기능을 찾아보세요"라고 하고 몇 번 클릭해서 찾는지 봐요.
3번 이내로 못 찾는다면 정보 구조 문제예요.

Understandability(이해 가능성): 메뉴나 레이블을 보고 무엇인지 바로 이해할 수 있는가요.

측정 방법: 메뉴 이름만 보여주고 "이 메뉴에 무엇이 있을 것 같아요?"라고 물어요.
실제 내용과 기대가 일치하지 않으면 레이블 문제예요.

두 기준이 모두 충족될 때 정보 구조가 잘 작동해요.

정보 구조가 무너지는 순간들

기능이 늘어나면서 메뉴가 무한정 늘어날 때: 처음에는 5개였던 메뉴가 기능이 추가되면서 15개가 되는 경우예요.
주기적으로 IA를 재검토하고 관련된 것을 묶어야 해요.

여러 팀이 독립적으로 메뉴를 추가할 때: 각 팀이 자기 기능을 가장 잘 보이는 곳에 넣으려 하면, 전체 구조가 누가 보스냐 경쟁이 돼요.
IA를 관리하는 오너십이 필요해요.

검색이 정보 구조의 구멍을 가리고 있을 때: "검색 쓰면 되니까"라며 정보 구조를 신경 쓰지 않으면, 검색 기능이 없거나 실패할 때 사용자가 길을 잃어요.
검색은 탐색을 보완하는 도구지, 대체할 수 없어요.

이 원칙을 적용할 때 스스로에게 물어보세요

  • 지금 메뉴 구조가 사용자의 언어로 되어 있나요, 아니면 내부 시스템 구조를 반영하나요?
  • 사용자가 "이걸 어디서 찾지?"라며 헤매는 기능이 있나요?
  • 새 기능을 추가할 때 기존 정보 구조에서 어디에 들어가야 하는지 명확한가요?
  • CS 문의 중 "이 기능이 어디 있나요?" 유형이 얼마나 되나요?

정보 구조 설계 후 내비게이션을 어떻게 구현할지는 Navigation Design에서, 정보 구조를 사용자 시나리오로 검증하는 방법은 사용자 시나리오에서 다뤄요.

관련 아티클

참고 문헌

  • Peter Morville & Louis Rosenfeld, 《Information Architecture for the Web and Beyond》(4th ed.) - 정보 구조 이론과 실무의 핵심 교과서예요. 조직 체계, 레이블링, 내비게이션을 가장 체계적으로 다뤄요.
  • Jenifer Tidwell, 《Designing Interfaces》(2020) - 정보 구조를 실제 인터페이스 패턴으로 구현하는 방법을 다뤄요.