사용자 탭 정보구조 검토

ADR-330 사용자 탭 정보구조 검토

1. Metadata

• ADR ID: ADR-330
• Status: draft
• Date: 2026-03-15
• Owner: YSY

2. Context

• 현재 사용자 하단 탭은 탐색 / 예약 / 이력 / 프로필 구조다.
• 관심매장 등록의 시작점은 탐색/상세인데, 관리 화면은 프로필에 있어 정보구조가 일관되지 않는다.
• 관심매장을 탐색 화면 내부 섹션으로만 올리면 상단 영역이 커져 핵심인 슬롯 리스트 가시성이 줄어들 수 있다.
• 별도 저장 탭을 만들면 관심매장의 위치 문제는 해결되지만, 저장이 단순 관심매장 목록만 의미하면 탭 하나를 차지하기에는 약할 수 있다.
• 최근 본 매장/슬롯은 재탐색 비용을 줄일 수 있어 저장 탭의 최소 보강 축이 될 수 있다.
• 예약은 현재 또는 가까운 미래의 사용 행동을 관리하는 화면이고, 이력은 과거 사용 사실을 확인하는 화면이므로 시간 관점과 행동 목적이 다르다.
• 현재 예약 화면은 확보한 슬롯의 사용 준비, 체크인/사용 완료, 검증 피드백에 집중된 화면이다. 반면 이력은 캘린더와 완료 내역 조회 중심이다.
• 현대 스마트폰 화면 크기 기준으로 5탭 자체가 물리적으로 과도하다고 보기는 어렵다. 실제 리스크는 탭 수보다 탭 의미가 약하거나 빈 탭처럼 보이는 데 있다.

3. Option Review

3.1 옵션 A. 현재 4탭 유지 (탐색 / 예약 / 이력 / 프로필)

장점:

• 하단 탭 수가 적어 익숙하고 단순하다.
• 현재 구현 구조를 크게 흔들지 않아도 된다.
• 예약과 이력의 시간 관점을 분리한 현재 장점을 유지한다.

단점:

• 관심매장 관리가 프로필에 있으면 계정 정보와 저장/재방문 도구가 섞인다.
• 관심매장을 탐색 내부 섹션으로 키우면 슬롯 리스트 높이가 줄고, 탐색의 1차 목적이 흐려질 수 있다.
• 관심매장/저장 관련 확장 기능이 생겨도 이를 둘 최상위 위치가 없다.

3.2 옵션 B. 4탭 재구성 (탐색 / 저장 / 이력 / 프로필)

장점:

• 관심매장을 프로필에서 분리할 수 있다.
• 저장을 재방문 허브로 정의하면 탐색과 프로필의 책임이 더 선명해진다.
• 탭 수는 늘리지 않으면서 저장 개념을 최상위 수준으로 올릴 수 있다.

단점:

• 예약을 이력에 합치거나 탐색 안으로 다시 넣어야 하므로 현재/과거 사용 문맥이 섞인다.
• 예약 직후 다시 찾아와야 하는 화면이 약해질 수 있다.
• 저장 탭이 생겨도 실제로는 관심매장만 보여주면 정보 밀도가 낮다.

3.3 옵션 C. 5탭 확장 (탐색 / 예약 / 저장 / 이력 / 프로필)

장점:

• 저장, 예약, 이력, 프로필의 성격을 명확히 분리할 수 있다.
• 관심매장을 탐색과 프로필 사이의 애매한 위치에서 꺼내 독립된 재방문 허브로 둘 수 있다.
• 예약은 현재 사용 관점, 이력은 과거 검토 관점으로 계속 유지할 수 있다.
• 저장 탭을 관심매장 + 최근 본 정도로 시작해도 재방문 UX 개선 효과가 있다.
• 현대 기기 화면 폭을 고려하면 5탭 자체가 UX에 결정적 부담이라고 보기는 어렵다.

단점:

• 하단 탭의 시각적 무게는 증가한다.
• 저장의 정의가 약하면 가장 비어 보이는 탭이 될 수 있다.
• MVP 단계에서 한 화면의 데이터 조합 책임이 늘어난다.

3.4 옵션 D. 4탭 재구성 (탐색 / 활동 / 저장 / 프로필)

장점:

• 예약과 이력을 하나의 활동 축으로 묶어 탭 수를 줄일 수 있다.
• 저장 탭을 따로 둘 수 있다.
• 장기적으로 사용자의 행동 흐름을 찾기 -> 저장 -> 이용 -> 계정 구조로 단순화할 수 있다.

단점:

• 예약과 이력이 같은 화면에 들어가면 현재 행동과 과거 기록의 긴장감이 약해진다.
• 이용 직전 사용자가 빠르게 들어가야 하는 예약 화면이 한 단계 더 추상화될 수 있다.
• 세그먼트/필터를 잘 설계하지 않으면 한 화면 안 복잡도만 커진다.

3.5 옵션 E. 5탭 확장 (탐색 / 활동 / 저장 / 이력 / 프로필)

장점:

• 활동을 현재 사용 맥락의 허브로 넓게 정의할 수 있다.
• 저장과 이력도 독립성을 유지할 수 있다.
• 향후 예약 외 추가 행동 정보가 생길 때 확장성이 있다.

단점:

• 현재 화면 내용만 놓고 보면 활동이라는 이름이 실제 제공 정보보다 더 넓게 들린다.
• 이력이 별도 탭으로 남아 있으면 활동과 이력의 경계가 다시 모호해질 수 있다.
• 활동으로 이름을 바꿔도 정보가 여전히 예약 사용 준비 화면에 머무르면 탭명만 추상화된다.

4. Domain Decision

1. 사용자 하단 탭은 최소한 탐색, 저장, 현재 사용, 과거 기록, 계정이라는 다섯 가지 정보영역 중 일부를 대표해야 한다.
2. 저장은 단순 관심매장 목록이 아니라 다시 보고 싶은 대상과 신호를 모아두는 재방문 도메인으로 정의한다.
3. 예약은 현재 또는 가까운 미래의 사용 상태를 다루는 영역으로 정의한다.
4. 이력은 완료/취소/만료 등 과거 사용 사실을 확인하는 영역으로 정의한다.
5. 활동은 예약보다 넓은 개념이며, 현재 사용 준비 외 추가 행동 맥락이 있을 때만 채택 검토 대상이 된다.
6. 프로필은 계정/인증/설정/파트너 전환과 같은 계정성 기능을 우선 책임으로 둔다.

5. Product Decision

1. 현재 유력 후보안은 탐색 / 예약 / 저장 / 이력 / 프로필의 5탭 구조다.
2. 5탭 자체는 현대 기기 UX에서 허용 가능하다고 보고, 실제 판단 기준은 탭 의미 명확성과 탭 내용 밀도에 둔다.
3. 저장 탭은 초기에도 최소 관심매장과 최근 본 매장/슬롯을 함께 제공해야 한다.
4. 저장 탭의 다음 확장 후보는 활성 슬롯이 있는 관심매장, 저장한 위치/최근 선택 지역, 알림/재오픈 대기 순으로 검토한다.
5. ADR-180 기준 보류 상태인 관심업종은 저장 탭의 초기 필수 구성요소로 간주하지 않는다.
6. 탐색 화면은 슬롯 리스트 가시성을 최우선으로 유지하고, 관심매장은 큰 고정 섹션 대신 진입점/요약 카드/얇은 스트립 형태로만 노출하는 것을 기본 원칙으로 둔다.
7. 예약과 이력은 사용 시점과 행동 목적이 달라 현 단계에서는 분리 유지하는 방향을 우선 채택한다.
8. 예약 탭은 현재 구현처럼 확보한 슬롯을 실제로 사용하기 위한 화면에 머무는 동안 이름을 유지하는 쪽을 우선 검토한다.
9. 예약을 활동으로 바꾸려면 예약 리스트 외 추가 행동 정보가 실제로 들어와야 한다.
10. 활동 탭명 채택을 정당화할 수 있는 추가 정보 후보는 체크인/검증 대기, 현장 근접 확인 필요, 사용 직전 주의/실패 피드백, 이용 중 상태, 당일 행동 타임라인이다.
11. 위 추가 정보가 충분히 없으면 활동은 과한 추상화로 보고 채택하지 않는다.
12. 프로필에서는 관심매장 관리 기능을 장기적으로 제거하고 계정 중심 역할만 남기는 방향을 검토한다.
13. 활동 탭을 채택할 경우 카드 표현은 탐색 카드보다 더 큰 밀도로 설계한다.
14. 활동 카드 상단에는 매장명, 혜택, 남은 시간, 현재 상태, 주 액션을 우선 노출한다.
15. 활동 카드 하단에는 구분선 아래 주소, 거리, 운영시간, 검증 방식, 취소 가능 여부, 간단 안내 등 실행형 상세 정보를 노출할 수 있다.
16. 활동 카드 탭 동작은 탐색과 동일하게 기존 슬롯 상세 화면 진입을 허용한다.
17. 활동 카드 하단 확장 영역은 전체 매장 상세를 복제하지 않고, 사용 직전 판단과 행동에 필요한 정보만 제한적으로 노출한다.

6. UX Decision

1. 탐색 화면 안에 관심매장을 크게 펼쳐 슬롯 리스트의 첫 화면 높이를 줄이는 구조는 기본안으로 채택하지 않는다.
2. 탐색 화면의 관심매장 표현은 상단 저장 진입점, 얇은 요약 배너, 활성 슬롯 수 요약, 단일 액션 카드 수준으로 제한한다.
3. 저장 탭의 첫 화면은 단순 목록보다 지금 다시 볼 이유가 있는 항목을 먼저 보여줘야 한다.
4. 저장 탭의 상단 우선순위는 현재 활성 슬롯이 있는 관심매장 -> 최근 본 항목 -> 일반 관심매장 순으로 검토한다.
5. 최근 본은 탐색 복귀를 빠르게 만드는 실용 기능이므로 초기 저장 탭에 포함할 가치가 있다.
6. 최근 본은 읽기 전용 목록에 머무르지 않고, 재방문 허브라는 탭 목적에 맞게 관심매장으로 전환하는 보조 상호작용을 제공할 수 있다.
7. 저장 탭에서의 관심매장 추가 보조 경로는 최근 본 카드 내부의 명시적 추가 버튼을 기본안으로 한다.
8. 이 보조 액션은 최근 본의 핵심 동작인 상세 재진입과 충돌하지 않도록 카드 기본 탭과 분리되어야 한다.
9. 예약 화면은 다가오는 예약 관리와 사용 직전 행동에 집중하고, 이력 화면은 과거 결과 확인과 재방문 판단에 집중한다.
10. 활동은 예약 외 부가 정보가 누적될 때만 더 자연스러운 이름이 된다. 현재 수준에서는 사용자가 기대하는 범위보다 실제 내용이 좁을 수 있다.
11. 활동 카드의 정보 구조는 상단 기본 정보 + 구분선 + 하단 실행 상세를 기본 패턴으로 한다.
12. 사용자는 활동 카드만 봐도 즉시 행동할 수 있어야 하고, 더 많은 맥락이 필요할 때만 상세 화면으로 이동해야 한다.
13. 활동 카드 하단 상세는 인라인 노출을 기본으로 검토하고, 별도 확장 인터랙션은 필수 조건으로 두지 않는다.

7. Tech Decision

1. 저장 탭은 단일 리스트가 아니라 favorite_store, recent_view, saved_location, watch_alert 등 저장 항목 타입을 구분하는 조합 모델을 전제로 한다.
2. 초기 5탭안에서는 favorite_store와 recent_view만으로도 첫 릴리스를 구성할 수 있다.
3. 저장 탭의 SoT는 각 하위 도메인(user_favorite_store, 최근 본 로컬 기록, 위치 저장, 알림 상태)을 유지하고, 탭 화면은 조합 뷰로만 구성한다.
4. 예약과 이력을 분리 유지하는 동안 라우팅, 딥링크, 알림 진입점도 upcoming과 past 문맥을 구분해야 한다.
5. 탭 개편 시 탐색 -> 저장 등록, 저장 -> 상세 재진입, 예약 -> 이력 이동 전환 이벤트를 추적해야 한다.
6. 활동 탭을 검토하려면 예약 데이터 외 행동 이벤트를 묶는 별도 뷰모델 또는 집계 계층이 필요하다.
7. 활동 카드에서 노출하는 인라인 상세 정보는 기존 슬롯 상세 SoT를 재사용하되, 카드 계층에는 요약된 실행 정보만 투영한다.

8. Ops Decision

1. 탭 구조 변경 여부는 탐색 이탈률, 관심매장 재방문률, 최근 본 재진입률, 예약 화면 재진입률, 이력 조회율을 함께 보고 판단한다.
2. 저장 탭을 도입하면 관심매장만 있는 빈약한 탭으로 남는지 월 단위로 점검한다.
3. 예약과 이력 통합 실험은 별도 실험 플래그 없이 전체 전환하지 않고, 필요 시 제한 실험으로만 검토한다.
4. 예약 -> 활동 명칭 변경은 이름만 먼저 바꾸지 않고, 실제 제공 정보 증가와 함께 평가한다.

9. Implementation Contract (Optional)

9.1 Information Architecture Contract

• 탐색은 실시간 탐색과 신규 발견의 기본 진입점이어야 한다.
• 저장은 재방문 대상/신호를 모으는 허브여야 하며 계정 설정 화면이 아니어야 한다.
• 예약은 현재/예정 상태를, 이력은 과거 결과를 우선 보여줘야 한다.
• 프로필은 계정/설정/인증/파트너 전환을 우선 제공해야 한다.
• 활동은 예약 외 현재 행동 정보가 충분히 포함될 때만 허용한다.
• 활동 카드 탭 시 기존 슬롯 상세 화면으로 이동할 수 있어야 한다.
• 활동 카드 내부에는 사용 직전 판단에 필요한 실행형 상세 정보가 인라인으로 제공되어야 한다.

9.2 Data Contract

• 저장 항목 타입은 최소 favorite_store, recent_view, saved_location, watch_alert를 후보 표준값으로 검토한다.
• 초기 저장 탭 구현 최소치는 favorite_store + recent_view다.
• 저장 탭을 도입해도 각 항목의 SoT는 기존 도메인 모델에 남기고 탭 화면은 읽기 조합 계층으로 유지한다.

9.3 Error/Observability Contract

• 저장 탭 진입 시 섹션별 로드 실패를 분리 기록한다.
• 예약과 이력 간 잘못된 라우팅 또는 복원 실패는 별도 이벤트로 기록한다.
• recent_view 노출 대비 실제 재진입 전환율을 추적한다.

9.4 Test/Acceptance Contract

• 관심매장 관리가 프로필에 남아 있는 빌드에서는 저장 탭을 동시에 기본 탭으로 도입하지 않아야 한다.
• 탐색 화면 상단에 관심매장 요약을 추가하더라도 첫 화면 슬롯 카드 가시 수가 과도하게 줄지 않아야 한다.
• 저장 탭 도입 시 최소 관심매장과 최근 본이 함께 노출되어야 한다.
• 예약과 이력이 분리된 빌드에서는 현재/예정 예약이 이력으로 기본 이동되지 않아야 한다.
• 활동 명칭을 사용할 경우 예약 리스트 외 추가 행동 정보가 실제로 노출되어야 한다.
• 활동 명칭을 사용할 경우 카드가 탐색 카드보다 더 큰 정보 밀도를 가져야 한다.
• 활동 카드에는 구분선 아래 실행형 상세 정보가 노출되어야 한다.
• 활동 카드 탭 시 기존 슬롯 상세 화면 진입이 가능해야 한다.

10. Open Questions

1. 저장 탭을 처음부터 5탭 구조로 도입할지, 먼저 숨은 진입점이나 실험 빌드로 검증할지 결정이 필요하다.
2. 최근 본을 저장 탭의 일부로 볼지, 탐색 복귀 보조 기능으로만 둘지 기준 정리가 필요하다.
3. 저장한 위치/지역을 저장 탭에 올릴 만큼 사용 빈도가 있는지 검증이 필요하다.
4. 알림함 또는 재오픈 대기를 저장 탭에 포함할지, 별도 인앱 알림 레이어로 둘지 정리가 필요하다.
5. 예약 탭이 앞으로도 슬롯 사용 준비 화면에 머무를지, 현재 행동 허브로 확장할지 제품 방향 결정이 필요하다.
6. 예약 -> 활동 변경을 하려면 어떤 추가 정보가 실제로 MVP 범위 안에 들어올 수 있는지 우선순위 정리가 필요하다.
7. 활동 카드 하단에 넣을 실행형 상세 정보의 최소 집합을 어디까지 볼지 결정이 필요하다.

11. Validation

• Domain/Product/UX/Tech/Ops 결정이 충돌하지 않는다.
• ADR-180, ADR-190, ADR-260과 정합성을 유지한다.
• 저장 탭 정의가 단순 관심매장 목록을 넘어서는지 검증된다.
• 예약과 이력의 시간 관점 분리가 실제 사용자 흐름과 일치하는지 검증된다.
• 활동 명칭은 실제 정보 범위가 넓어질 때만 채택된다.

Buy me a coffee