로디 서비스 아카데미의 서비스기획트레이닝과 Udemy의 온라인 강의 내용을 종합하여 정리한 내용입니다.

사례 1 피드백

사례 1은 전반적으로 구조 이해가 잘 되어 있는 편이었다. Main 영역에서 스플래시, 권한 설정, 메인 페이지, 메인 팝업까지 모두 포함한 것은 기본 구성을 정확히 이해했다는 의미다. 다만 스플래시와 권한 설정은 반복 노출되는 화면이 아니라는 점을 인지해야 한다. 한 번만 등장하는 성격의 화면이기 때문에 항상 메인 페이지와 동일한 위계로 다루기보다는 흐름상 별도 성격을 가진 화면으로 보는 것이 맞다.

Product 영역에서는 메뉴가 다양하게 구성되어 있었지만, 실제 구현 관점에서는 중복 가능성이 높다. 여행, 패션 등 카테고리가 다르더라도 목록 페이지와 상세 페이지의 기본 구조는 유사하다. 특별한 옵션 차이나 정책 차이가 없다면 동일한 구조를 재사용하는 것이 합리적이다. 정보 구조에서는 한 벌만 정의하고, 세부 분류 값은 별도의 정책이나 카테고리 체계에서 관리하는 것이 맞다.

QnA 구조는 특히 중요하다. 질문 등록 기능은 반드시 존재해야 한다. 이를 상세 탭 안에서 구현할지, 고객센터의 1:1 문의와 연계할지는 선택의 문제지만, 어느 쪽이든 등록 기능은 한 곳에 명확히 있어야 흐름이 성립된다. QnA에는 등록과 상세가 있고, 판매자 답변은 개념적으로 다른 영역이므로 분리하는 것이 일반적이다. 또한 마이페이지 하위의 ‘나의 문답 관리’와 반드시 연결되어야 한다. 메뉴는 분리되어 있어도 데이터 관리 구조는 이어져 있어야 한다는 점이 핵심이다.

상세 페이지는 CRUD 구조로 바라보는 것이 맞다. 수정 기능을 동일 페이지에서 처리할 수도 있고, 수정 모드를 별도 페이지로 둘 수도 있다. 중요한 것은 디자인 벌 수 기준으로 판단하는 것이다. 탭 안에 들어가 있다고 해서 페이지가 아닌 것이 아니다. 디자인이 다르면 페이지는 분리된다.

검색 결과 화면도 마찬가지다. 그리드형, 썸네일형, 결과 없음 화면은 각각 다른 디자인 단위를 가진다. 단 수가 달라지면 그 또한 다른 설계다. 준비되지 않으면 디자이너는 같은 구조를 반복 작업하게 된다. 따라서 기본적으로 1~3단 그리드와 썸네일 정도는 기획 단계에서 정의해두는 것이 필요하다.

Utility 영역에서는 메뉴와 페이지의 구분이 중요하다. 로그인 메뉴는 네비게이션 요소이므로 0이고, 실제 로그인 입력 화면은 1이다. 우편번호 검색처럼 외부 API를 활용하는 경우에는 ‘외부 0’으로 처리한다. 다만 결과 흐름은 구조상 명시해두는 것이 안전하다.

마이페이지에서는 연동 구조를 이해해야 한다. 관심 브랜드 상세가 전시 영역의 브랜드 상세로 이동한다면 이는 중복 페이지다. 이런 경우 0으로 처리한다. 브랜드 구조가 프로젝트 하위에 명확히 포함되어 있어야 상품과의 연계가 자연스럽다.

결제 영역에서는 외부와 자체를 명확히 구분해야 한다. 무통장 입금 팝업처럼 자체 제작 영역은 1이다. 간편결제 등록 화면 역시 자체 설계 대상이다. 반면 외부 결제 시스템은 외부 0으로 처리한다. 이 구분이 분량 산정의 기준이 된다.

 

사례 2 피드백

사례 2에서는 기능의 위치 판단이 핵심 이슈였다. 일정 만들기 기능이 유틸리티인지, 플랫폼의 핵심 상품 기능인지에 따라 위치는 달라진다. 서비스의 주력 기능이라면 Product 그룹으로 이동하는 것이 자연스럽다. 구조는 기능의 성격을 반영해야 한다.

Utility 구조에서는 로그인 누락이 보완 포인트였다. 일반적인 흐름은 로그인 → 회원가입 → 마이페이지다. 이 순서는 사용자의 기본 진입 구조이므로 크게 벗어나지 않는 것이 안정적이다.

마이페이지 하위에 예약 내역과 마일리지, 주문 이력이 섞여 있었는데, 구조상 주문 이력이 우선이고 혜택은 그 다음이 자연스럽다. 정보 확인 흐름을 기준으로 배열해야 한다.

장바구니 목록 하위에 주문서 작성이 있다면 반드시 1로 카운팅해야 한다. 0과 1의 표기 기준이 흔들리면 나중에 전체 페이지 수가 왜곡된다. 특히 표기 방식은 처음부터 일관성 있게 유지해야 한다. 띄어쓰기 하나가 나중에 일괄 수정 시 큰 차이를 만든다.

공지사항과 FAQ는 UI상 붙어 있어도 정보 구조상 목록과 상세를 분리해야 한다. 게시판은 등록, 수정, 삭제까지 포함되므로 기능 단위로 분리하는 것이 맞다.

 

사례 3 피드백

사례 3은 전체 정보 구조가 안정적으로 잡혀 있었다. Main, Product, Utility, Company 그룹이 명확했다. 스플래시, 권한 설정, 온보딩, 코치마크 구성도 적절했다.

Product 그룹에서는 랭킹 상세가 기존 상세와 동일하다면 0 처리하는 것이 맞다. 중복되는 상세를 다시 정의할 필요는 없다. 기획전 상세에서 상품 상세로 연결되는 경우도 동일하다.

이벤트에서 쿠폰을 다운로드하면 마이페이지의 쿠폰함으로 저장되는 구조는 연동 설계가 잘 이루어진 사례다. 이런 구조는 반드시 양쪽에서 크로스체크해야 한다. 한쪽에만 정의하면 누락이 생긴다.

Utility 그룹에서는 로그인 메뉴와 로그인 페이지의 차이를 정확히 구분한 점이 중요하다. 아이디 찾기, 패스워드 찾기, 본인 인증은 외부 시스템을 활용하므로 외부 0으로 처리한다. 우리가 직접 제작하지 않는 영역은 설계 분량에 포함시키지 않는다.

회원가입 단계는 인증, 기본 정보 입력, 추가 정보 입력 등으로 분리할 수 있다. 단계별 설계는 디자인 단위 기준으로 나누는 것이 맞다.

탭, 아코디언, 팝업 역시 본질적으로는 분리된 페이지를 묶는 방식이다. 디자인 벌 수가 다르면 페이지는 분리된다. 기획 단계에서 이를 분리하지 않으면 디자인 공수가 왜곡된다.

 

사례 4 피드백

사례 4의 핵심은 분류 체계와 뎁스를 혼합하지 말아야 한다는 점이다. 대분류, 중분류, 소분류, 상세 정도가 일반적인 최대 분류 체계다. 이 이하로 계속 세분화하면 정보 구조가 잘못되었다고 보는 것이 일반적이다.

메뉴 뎁스와 분류 체계를 동시에 깊게 가져가면 혼동이 시작된다. 추천하는 방식은 페이지 단위 뎁스를 관리하고, 분류 체계는 대중소상세 정도로 제한하는 것이다.

리뷰 구조 역시 동일하다. 리뷰 목록, 상세, 등록은 디자인 단위로 각각 한 벌씩 존재한다. 아코디언이나 탭으로 묶여 있더라도 디자인과 퍼블리싱은 별도 단위로 작업된다. 주소가 달라야만 페이지가 되는 것은 아니다. 앱에서는 주소 개념이 희미하다. 페이지는 디자인 단위로 판단하는 것이 가장 정확하다.

FAQ, 후기 역시 목록 한 벌, 상세 한 벌, 등록 한 벌이 필요하다. 이를 하나로 잡으면 디자인 공수가 급격히 늘어난다. 좋은 협업을 위해서는 기획 단계에서 공수를 정확히 분리해두는 것이 중요하다.

마이페이지 하위 구성도 정석적인 커머스 구조를 따르고 있다. 마이 쿠폰, 찜, 주문 배송, 마일리지, 장바구니, 마이 리뷰, 결제 수단 관리까지 안정적으로 정리되어 있다. 전체적으로 구조 이해도가 높고, 안정적으로 진행 가능한 형태다.

 

정리

결국 네 사례 모두에서 반복되는 핵심은 세 가지다.
중복은 0으로 처리하고, 디자인이 다르면 분리하며, 연동 구조는 반드시 양방향으로 확인한다는 원칙이다.

이 기준이 흔들리지 않으면 정보 구조는 안정되고, 설계 공수는 정확해진다.