정보 구조 정리와 요구사항 연계의 정의

정보 구조를 정리할 때는 단순히 메뉴와 페이지를 나열하는 데 그치지 않고, As-Is 구조와 To-Be 구조를 함께 비교하면서 요구사항 아이디를 병기해 두는 것이 중요합니다. 이는 이후 엑셀 등 별도의 산출물로 정리할 때 중복 작업을 줄이고, 누락을 방지하기 위한 실무적인 장치입니다.

특히 외부 시스템과 연계되는 항목이 있다면, 이를 정보 구조 단계에서 함께 표시해 두어야 합니다. 이렇게 정리해 두면 나중에 마인드맵이나 별도의 문서를 다시 열어보지 않고도, 엑셀 상에서 필요한 정보를 바로 확인할 수 있습니다. 즉, 정보 구조도는 단순 설계 도식이 아니라, 이후 문서화와 관리 단계까지 고려한 기반 문서로 활용되어야 합니다.

 

전시 카테고리와 정보 구조의 구분

정보 구조를 정리하다 보면 자주 등장하는 질문이 있습니다. “전시 카테고리를 모두 정보 구조에 나열해야 하는가”라는 문제입니다. 이에 대한 답은 명확합니다. 모든 카테고리를 나열할 필요는 없으며, 하나의 대표 사례만 정리하면 충분합니다.

전시 카테고리는 별도의 정책 문서에서 관리되는 영역입니다. 운영 과정에서 JIRA와 같은 협업 도구를 통해 변경되거나 확장될 수 있으며, 어드민(Admin) 시스템에서 설정값에 따라 자동으로 생성되거나 수정됩니다. 따라서 정보 구조 단계에서 모든 카테고리를 세부적으로 나열하는 것은 적절하지 않습니다.

정보 구조의 목적은 카테고리 목록 자체를 관리하는 것이 아니라, 카테고리가 어떤 뎁스로 구성되며, 해당 구조 안에서 몇 개의 페이지 유형이 필요한지를 정의하는 데 있습니다.

 

정보 구조에서 정리해야 할 핵심 요소

정보 구조에서 전시 카테고리를 다룰 때 핵심은 두 가지입니다. 첫째, 최대 몇 뎁스까지 노출할 것인지, 둘째, 해당 분류 체계 안에서 독립적인 페이지는 몇 개가 필요한지를 정리하는 것입니다.

예를 들어 여행 카테고리를 생각해 보겠습니다. 여행이라는 상위 카테고리 아래에 유럽, 동유럽, 아시아, 미주와 같은 세부 분류가 존재할 수 있습니다. 그러나 정보 구조에서는 이를 모두 개별 페이지로 나열하는 것이 아니라, “해외 여행 목록 페이지”라는 하나의 대표 사례로 정리합니다. 유럽 여행, 아시아 여행, 미주 여행이 각각 다른 상품 목록을 보여주더라도, 실제로는 동일한 목록 페이지 구조를 반복적으로 사용하는 경우가 대부분입니다. 이때 정보 구조에서는 “유럽 여행 목록 페이지”와 같이 명칭을 구체적으로 기입하되, 동일 구조로 재사용된다는 점을 명확히 표시하는 것이 중요합니다.

즉, 정보 구조의 역할은 “페이지 유형을 정의하는 것”이지, “카테고리 데이터를 나열하는 것”이 아닙니다.

 

신규 카테고리 추가 시 처리 방식

만약 운영 과정에서 새로운 전시 카테고리가 추가된다면, 이는 전시 카테고리 정책 문서에서 관리되는 사안입니다. 정보 구조 문서 자체를 수정하는 것이 아니라, 어드민 설정과 정책 문서를 통해 반영됩니다. 전시 카테고리는 관리자가 등록하면 자동으로 화면에 반영되는 구조일 수 있으며, 이러한 영역은 정보 구조에서 직접 관리하지 않습니다. 정보 구조는 구조적 틀을 정의하는 문서이고, 카테고리 데이터의 증감은 정책과 운영 문서의 영역입니다.

 

페이지 단위의 정의와 구조적 관계의 명확화에 핵심이 있다!

정보 구조 정리의 핵심은 페이지 단위의 정의와 구조적 관계의 명확화에 있습니다. As-Is와 To-Be를 비교하면서 요구사항 아이디를 함께 기록해 두면 이후 관리가 용이해지고, 외부 시스템 연계 여부도 한눈에 파악할 수 있습니다. 전시 카테고리는 모두 나열할 필요가 없으며, 대표 사례만 정의하면 충분합니다. 카테고리 데이터는 정책 문서와 어드민 시스템에서 관리되고, 정보 구조는 그 데이터가 어떤 페이지 구조를 통해 표현되는지를 정의하는 역할을 합니다.

결국 정보 구조는 “데이터를 나열하는 문서”가 아니라, “페이지 유형과 연결 구조를 설계하는 문서”라는 점을 명확히 이해하는 것이 중요합니다.