정보구조와 정보구조도

구조

상단에는 뎁스(Depth) 라는 개념이 있다. 뎁스에는 메뉴와 페이지가 포함된다.

뎁스란 특정 페이지에 도달하기까지 몇 단계(몇 번의 선택)를 거쳐야 하는지를 의미하는 개념이다.

• 예를 들어, 어떤 페이지에 도달하는 데 7~8번의 클릭(또는 터치)이 필요하다면, 이는 사용자 경험(UX) 측면에서 좋지 않을 것.

그래서 뎁스의 깊이는 굉장히 중요한 문제.

• 실제로 사용자가 원하는 페이지에 3번의 클릭 이내로 도달하지 못하면 이탈할 가능성이 높다는 통계가 있다.
• 따라서 세 번 이내의 선택(클릭)으로 원하는 페이지에 도달할 수 있도록 구성해야 한다.

뎁스가 깊을수록 사용자가 원하는 정보를 찾기 어려워지고, 이탈률이 높아질 가능성이 크다.

 

사용자가 원하는 페이지로 이동하는 방법에는 두 가지가 있다 : 1. 메뉴(Menu), 2. 페이지(Page)

• 예를 들어, 사용자가 마켓컬리에 와서 쌀을 주문하려고 한다면 메뉴를 통해 원하는 페이지로 이동해야 한다.

 

뎁스 줄이는 방법

- 메뉴를 상단에 꺼내 놓지 않으면 뎁스를 짧게 만들기가 어렵다.

- 그래서 메뉴를 상단에 노출하면 뎁스는 짧아지지만, 반대로 한눈에 보이는 정보의 양이 많아지는 문제가 발생한다.

- 하지만 모든 메뉴를 노출한다고 해서 무조건 좋은 것도 아니다. 오히려 메뉴가 너무 많으면 사용자가 원하는 정보를 찾기 어려워질 수도 있기 때문.

 

정리하자면

- 정보 구조 설계에서 가장 좋은 방식은 7개 메뉴, 3 뎁스 안에 중요한 정보를 배치하는 것"이라는 것이 전문가들의 공통된 의견.

 

왜 7개 메뉴가 최적일까?

- 숫자 7은 인간이 한 번에 인지할 수 있는 정보의 한계치로, 전화번호 등에서도 사용되는 기준이다.

>> 즉, 한 번에 인지할 수 있는 정보의 양을 고려해야 사용자 경험(UX)이 좋아진다는 뜻.

>> 따라서 정보 설계 과정에서 뎁스 개념을 잘 이해해야 좋은 사용자 경험을 제공하는 사이트를 만들 수 있다.

 

---

화면과 페이지 ID

정보 구조에는 가로축(뎁스) 외에도 세로축(화면의 구조)이 있다.

화면을 보면 페이지 아이디(ID)가 있는 경우도 있고, 없는 경우도 있다.

왜 어떤 페이지에는 아이디가 있고, 어떤 페이지에는 없을까?

 

페이지 아이디는 '페이지'에 부여되는 값.

>>즉, *메뉴나 구분자 역할을 하는 요소에는 아이디가 없어야 한다.

- 따라서 메뉴와 페이지를 정리한 후, 아이디는 실제 화면을 구성하는 페이지에만 부여해야 한다.

⇒ 이 점이 매우 중요하다.

 

잘못된 정보 구조 설계의 예시

일부에서는 정보 구조를 정리할 때 페이지 내부의 상세 영역까지 모두 포함하는 경우가 있다.

예를 들면,

• 목록 페이지의 상단 배너
• 목록 페이지의 필터링 조건
• 목록 페이지의 네비게이션

이러한 요소들을 정보 구조에서 모두 포함하려는 것은 좋은 방법이 아니다.

• 왜냐하면 정보 구조에서 중요한 것은 "페이지 단위"의 구성이며, 내부 구성 요소들은 화면 설계 단계에서 정의하는 것이 맞기 때문.

즉, 정보 구조의 목적은 ‘상품 목록 페이지가 필요하다’는 것을 정의하는 것이지, 그 페이지의 세부 구성을 결정하는 것이 아니다.

⇒ 따라서 각 페이지의 명칭과 화면 아이디(GMB 6.1.1 등)를 정확하게 정의하는 것이 정보 구조의 역할.

 

메뉴 = 폴더

사실 페이지를 호출하는 역할을 할 뿐, 실제 페이지가 아니다.

쉽게 말해 메뉴는 사용자가 만든 추상적인 개념이며, 폴더와 같은 역할을 한다.

폴더를 클릭하면 대표적인 파일이 열리는 것처럼, 특정 메뉴를 클릭하면 약속된 페이지가 열리는 방식입니다.

예를 들어,

• 베스트 메뉴를 클릭하면 베스트 목록 페이지가 열리고,
• 알뜰 쇼핑 메뉴를 클릭하면 알뜰 쇼핑 목록 페이지가 열린다.
• 특가 혜택이나 신상품 메뉴도 같은 방식이며,
• 카테고리 메뉴를 클릭하면 중분류 카테고리 목록이 표시된다.
• 그리고 중분류 카테고리에 마우스를 오버(또는 클릭)하면 소분류 카테고리가 나타나도록 약속된 구조.

그러나 이러한 메뉴들은 실제 페이지가 아니다.

⇒ 따라서 정보 구조를 정의할 때, 개별적인 메뉴 목록을 전부 정리하는 것이 아니라, "중분류 → 소분류 → 목록 페이지"처럼 대표적인 사례만 정리하면 된다.

 

 

메뉴와 정보 구조의 차이

카테고리 메뉴는 *어드민(Admin)*에서 등록된 대로 화면에 표시됩니다.

그러나 정보 구조의 목적은 카테고리 자체를 정리하는 것이 아니라, 메뉴가 페이지와 어떻게 연결되는지를 정리하는 것이다.

예를 들면,

• 카테고리 메뉴가 있고,
• 그 아래 중분류가 있으며,
• 중분류를 클릭하면 소분류가 나타나고,
• 소분류를 클릭하면 상품 목록 페이지로 이동하는 흐름

이것이 정보 구조에서 중요한 요소이며, 이 연결 관계를 정리하는 것이 정보 구조의 역할.

 

메뉴는 많아도 실제 페이지는 하나

메뉴 개수는 많아 보이지만, 사실 동일한 목록 페이지가 여러 번 재사용되고 있을 뿐.

예를 들어,

• "견과·쌀" 카테고리를 클릭하면 상품 목록 페이지가 열리고,
• "친환경 농산물"을 클릭하면 다른 상품 목록이 나오지만,
• 실제로는 하나의 동일한 목록 페이지를 반복적으로 사용하고 있는 것.

이를 주소(URL)로 확인할 수 있다

• "견과·쌀" 페이지의 URL에 포함된 908_006 같은 숫자는 상품 카테고리를 구분하는 아이디(ID)일 뿐,
• "친환경 농산물"을 선택하면 뒤의 숫자만 변경될 뿐, 동일한 목록 페이지를 사용하게 된다.

즉, 모든 카테고리는 하나의 동일한 상품 목록 페이지를 공유하고 있으며, 단순히 카테고리 아이디 값만 변경될 뿐이다.

 

파라미터와 반복 사용되는 페이지

웹의 가장 큰 특징 중 하나는, 하나의 페이지가 여러 메뉴에서 재사용된다는 점.

 

 

 

파라미터란, 같은 페이지를 사용하면서도 데이터를 다르게 불러오기 위한 고유 값.

• 예를 들어, "쌀"과 "채소"는 각각 다른 카테고리이지만, 실제로는 같은 목록 페이지를 사용하며, 파라미터 값만 다르게 설정하여 다른 상품 목록을 불러오게 된다.

이 개념을 어려워하는 경우가 많다.

• 정보 구조를 만들다 보면 "채소 페이지"와 "쌀 페이지"가 서로 다른 페이지처럼 보일 수 있다.
• 그래서 두 개의 다른 페이지로 생각하고 개별적으로 정리하는 경우가 많다.

하지만 실제로는 퍼블리싱(HTML/CSS 개발) 단계에서도, 디자인 단계에서도 단 하나의 목록 페이지만 만들어지고, 이를 반복해서 활용하는 것이다.

 

정리하자면

카테고리 하위의 목록 페이지들은 반복적으로 사용되기 때문에 정보 구조를 정리할 때는 하나의 대표적인 사례만 정리하면 된다.

• 예를 들어, 채소든 쌀이든 동일한 목록 페이지를 사용하고 있으므로, 별도로 구분할 필요가 없다.

상세 페이지도 마찬가지.

• 각 상품의 이름이나 이미지는 다르지만, 결국 하나의 동일한 상세 페이지를 재활용하고 있는 구조이므로 한 번만 정의해주면 된다.

 

- 정보 구조를 정리할 때 가장 어려운 부분 중 하나가 '페이지가 구분되는 기준'을 명확히 이해하는 것.

- 처음에는 이를 구분하기 어려울 수 있지만, URL(주소 값)을 확인하면 페이지 구조를 파악할 수 있다.

• 동일한 파일명을 사용하면서도 **파라미터(parameter)**를 통해 다른 데이터를 불러오고 있다면, 단일 페이지를 재사용하는 구조라는 의미.
• 만약 확인이 어려우면, 함께 작업하는 개발자에게 동일한 파일을 사용하는지 확인하는 것이 좋다.

 

파일명과 정보 구조

마켓컬리의 신상품 카테고리를 예로 들어보자면.

- 신상품 카테고리는 일반 상품 카테고리와 구조적으로 거의 동일하지만, 상단 배너 유무 등의 차이가 있을 수 있다.

- 파일명은 다르게 설정될 수도 있으며, 이를 확인하려면 개발자에게 문의하여 기존 HTML 파일을 재사용하는지 아니면 새로운 파일이 필요한지를 체크한 후 파일을 카운팅하면 된다.

=> 즉, 정보 구조를 정리할 때는 불필요한 중복을 줄이고, 재사용되는 페이지를 파악하는 것이 중요하다.

 

정보 구조의 핵심: 페이지 수와 작업량 산정

- 상품을 포함한 카테고리 목록 페이지와 상세 페이지는 모든 상품 목록을 각각 정의할 필요 없이 한 번만 정리하면 된다.

- 이렇게 중복을 제거한 후, 독립적인 페이지 수를 산출하면 전체 작업량(분량)이 정리 된다.

- 이 페이지 수를 정확하게 파악하는 것이 정보 구조 설계의 핵심이다.

 

정보 구조에서 ‘페이지 분량’을 체크하는 이유

정보 구조에서 중요한 요소 중 하나가 페이지 분량 체크.

• 전체 페이지 수를 정확하게 계산해야, 프로젝트 일정과 작업량을 예측할 수 있다.

 

정보 구조와 화면 설계의 난이도 체크 방법

정보 구조에는 개발 여부 및 인증 여부 같은 요소도 포함될 수 있다.

이러한 항목은 해당 화면의 난이도를 평가하는 기준이 된다.

 

개발 여부

- 이 화면이 백엔드 개발(서버 사이드 코드)이 필요한지 여부를 판단한다.

- 서버 개발이 필요한 경우, 화면의 난이도가 높아지므로 작업 시간이 길어질 수 있다.

 

인증 여부

- 이 화면이 회원 로그인 시 다르게 동작하는지 여부를 판단합니다.

- 로그인 상태에 따라 UI가 달라지는 경우, 화면 설계 난이도가 증가한다.

- 따라서 기획자가 작업할 수 있는 페이지 수를 조정하여 안정적인 일정 계획을 세우는 것이 중요하다.

 

마켓컬리 페이지 예시 : 관리자 연동이 포함된 페이지 vs. 포함되지 않은 페이지

마켓컬리 메인 페이지에는 관리자가 설정한 기능들이 포함되어 있다.

• 예를 들면, 배너 영역이나 특가 상품은 관리자(Admin)에서 직접 설정할 수 있는 영역이다.
• 하지만, 신상품 영역은 관리자가 개별적으로 설정하는 것이 아니라, 자동으로 조건에 맞는 상품이 노출되는 구조다.

즉,

• 관리자가 직접 설정하는 영역 → 관리자 연동이 필요하므로 개발 난이도가 높음.
• 자동으로 데이터가 적용되는 영역 → 별도 관리 없이 조건에 따라 상품이 노출되므로 난이도가 낮음.

⇒ 따라서 어드민(관리자 시스템)과 연동된 부분이 포함된 페이지일 경우, 화면 설계 시간도 더 길어질 가능성이 크다.

 

 

관리자 연동 여부가 중요한 이유

FAQ 사례로 이것을 살펴볼 수 있다.

1) FAQ 항목이 관리자에서 등록되는 방식인가?

2) 아니면 HTML 파일로 고정된 목록을 노출하는 방식인가?

 

이 두 가지 방식은 모두 가능하지만,

- FAQ가 관리자 시스템에서 등록·관리된다면, 유지보수와 업데이트가 필요하므로 개발 난이도가 상승한다

- 반면, HTML 파일로 고정된 내용이라면 난이도가 낮다.

⇒ 따라서 정보 구조를 설계할 때, 이런 연동 여부를 미리 체크해두는 것이 중요하다.

 

자주 묻는 질문(FAQ)이 관리자에서 관리되는 경우

- 고객센터의 FAQ 관리 시스템과 연결됨.

- 신규 질문이 추가될 경우, 관리자에서 내용을 등록하면 자동 반영됨.

- 개발 난이도가 높음 → 화면 설계 시간이 길어질 가능성이 있음.

 

자주 묻는 질문(FAQ)이 HTML로 고정된 경우

- 초기 화면 설계에서 정의된 목록이 그대로 노출됨.

- 새로운 질문이 추가되더라도 개발자가 직접 HTML을 수정해야 함.

- 개발 난이도가 낮음 → 화면 설계 시간도 짧아질 가능성이 있음.

 

이러한 이유로 정보 구조도(IA, Information Architecture)에 난이도를 함께 체크하는 것이 일반적인 방법이다.

=> 즉, 단순히 페이지 목록과 ID를 정의하는 것이 아니라, 연동 여부 / 인증 여부 / 화면별 난이도 등을 함께 고려하여 작업 분량과 기술적 난이도를 예측하는 것이 중요하다.

 

요구사항 ID와 화면 ID의 중요성

추가적으로, 요구사항 ID를 화면 ID와 매핑해야 한다.

• 기획 과정에서 요구사항을 정의할 때 특정 기능들이 확정된다.
• 이후, 이 기능이 어떤 페이지에서 구현되는지 명확하게 연결할 필요가 있다.

또한, 화면 ID를 정의하는 것도 중요한 작업.

 

 

예를 들어,

• CEO 인삿말 페이지를 기획할 때, 기획 문서에서는 이를 "CEO 인삿말"이라고 부르겠지만,
• 실제 화면 설계서에서는 “CO2"라는 화면 ID를 부여할 수도 있다.

이렇게 화면 ID를 부여하는 방식에는 여러 가지가 있다.

 

1) 고유 번호 방식

: 001, 002, 003처럼 단순하게 부여하는 방식.

- 문제: 페이지가 많아질수록 해당 ID가 어떤 페이지인지 쉽게 파악하기 어려움.

 

2) 메뉴 코드 + 숫자 결합 방식 (권장)

 

• 예: CEO5 → "Company" 메뉴 하위의 다섯 번째 페이지
• 메뉴별 코드(영문 2자리) + 페이지 번호를 결합하여 의미를 부여.
• 예를 들어, CA 1.1.4.1.1
  • CA: 카트(cart) 관련 페이지
  • 1.1.4.1.1: 뎁스를 나타내는 구조

이 방식의 장점은

1) 고유값을 가지면서도 의미를 직관적으로 파악할 수 있다는 것.

2) 페이지를 뎁스(Depth)와 연결하여 관리할 수 있다는 것.

 

뎁스와 화면 ID 결합 방식

- 뎁스를 화면 ID와 결합하는 방식은 현재 널리 사용되는 방법 중 하나.

 

예를 들어,

CA 1.1.4.1.1 → "Cart 메뉴 하위에서 5번 클릭해야 도달하는 페이지"

CA 1.1.2.2 → "Cart 메뉴 하위에서 3번 클릭하면 도달하는 페이지"

 

이 방식의 장점은

- 페이지가 어떤 메뉴에서 몇 번의 클릭을 거쳐 이동할 수 있는지 한눈에 파악할 수 있다는 것.

- 더 체계적인 정보 구조 설계가 가능하다는 것.

 

단점이라면,

- 설정하는 데 시간이 더 걸릴 수 있다는 것.

- 하지만, 더 명확한 구조를 만들 수 있어 장기적으로 유지보수에 유리하다는 것.

 

일부 경우에는

팝업 여부를 구분하기 위해 **"P" (Popup)**를 추가하거나,

일반적인 화면(Flow Page)은 **"F" (Flow)**로 구분하는 방식도 있다.

=> 하지만, 너무 이런 요소에 집착하면 정보 구조의 본질적인 목적을 놓칠 수 있으므로, 상황에 맞는 방식을 선택하는 것이 중요하다.

 

정보 구조 정리 방식 : 오른쪽 논리도 형태

정보 구조를 정리할 때 논리도를 활용하는 방식도 중요하다.

- 한쪽 방향으로 정리하면, 구조를 파악하기 더 용이하기 때문이다.

- 물론, 다른 방식도 사용할 수 있지만 정보 구조 특성상 한쪽으로 정리하는 것이 더 효과적이다.