edu/search_result_modal_branch_analysis.md

search_result 카테고리별 모달 분기 분석 및 적용 방안

작성 목적: search_result.php에서 검색 결과 카드 클릭 시, 각 카테고리 페이지와 동일한 모달 경험(모달 템플릿, 추천 로직, 진행 저장, 댓글/북마크 동작)을 제공하기 위한 사전 분석 문서.

원칙:

• 이 문서는 설계/분석 전용이다.
• 실제 코드 적용은 별도 단계에서 진행한다.

1) 현재 구조 요약

A. search_result (현재)

• 진입점: skin/search_result.php
• 모달 호출 방식:
  • VideoModalManager를 currentVideos로 초기화
  • #videoCardsContainer 내부 .card[data-video-id] 클릭 시 openVideo(videoId)
• 모달 엔진:
  • js/main/Videomodalmanager.js -> js/common/VideoModalBase.js
• 추천 로직:
  • VideoModalBase.loadRecommendedVideos() 내부에서 컨텍스트에 따라 API 자동 분기
    • 마이클래스 컨텍스트: /edu/bbs/api/get_recommend_videos_goal.php
    • 그 외: /edu/bbs/api/get_recommend_videos.php

핵심 특징:

• search_result는 현재 단일 공통 모달 체계(VideoModalManager)만 사용 중이다.
• 하지만 실제 서비스는 카테고리별로 모달 구현체가 다르다(특히 insight/biztrend/onboarding/legal).

B. index

• 진입점: skin/index.php
• 모달 호출: VideoModalManager
• 추천: VideoModalBase 경유(공용 API)
• 결론: search_result의 현재 방식과 가장 유사

C. myclass

• 진입점: skin/myclass_list.php, js/myclass_list.js
• 모달 호출: VideoModalManager + modalManager.openVideo(id)
• 데이터 특성:
  • type: comment
  • category_code: CA10001
  • goal_code 포함
• 추천: goal_code 전용 API(/get_recommend_videos_goal.php) 사용 맥락
• 결론: 공통 모달 기반이지만 추천 소스는 전용 분기 필요

D. onboarding

• 진입점: skin/onboarding.php, js/puzzle-onboarding.js
• 모달 호출: PuzzleModalManager 내부 VideoModalBase 직접 생성
• 모달 템플릿: ./_modal/video-onboarding.php
• 특징:
  • 퍼즐 진행 상태와 결합
  • 챕터/레슨 구조 기반
• 결론: search_result에서 일반 VideoModalManager로 대체하면 UX/상태 흐름 불일치 가능

E. legal learning (법정교육)

• 진입점: skin/learning.php, js/learning/modal.js
• 모달 호출: class VideoModal extends VideoModalBase
• 모달 템플릿: ./_modal/video-learning.php
• 특징:
  • 마커/챕터/학습진도 동기화 로직이 별도
  • skip 제한/저장 주기가 일반 페이지와 다름
• 결론: search_result에서도 법정교육 항목은 learning 전용 모달 흐름을 타야 정합성이 맞음

F. leadership

• 진입점: skin/leadership.php
• 모달 호출: 페이지 내부 openModal(info)
• 추천: /edu/bbs/api/get_recommend_videos.php (키워드 API)
• 특징:
  • jQuery 기반 전용 모달 DOM
  • 댓글/북마크/진행저장 루틴이 페이지 JS에 포함
• 결론: 공통 모달로 이관 가능성은 있으나 현재는 독립 구현

G. insight

• 진입점: skin/insight.php
• 모달 호출: 페이지 내부 openModal(info)
• 추천: API 호출이 아닌 현재 #video-list DOM 기반 buildRecommendedList()
• 특징:
  • 같은 페이지 목록 기반 추천이라는 정책 차이 존재
• 결론: leadership과 비슷해 보이지만 추천 정책이 다르므로 분리 판단 필수

H. biztrend

• 진입점: skin/biztrend.php, js/biztrend.js
• 모달 호출: 페이지 내부 openModal(info)
• 외부 브리지: window._biztrendOpenModal = openModal
• 특징:
  • 월/기사형 그리드와 결합
  • 전용 추천 리스트 구성/전용 UI
• 결론: search_result에서 biztrend는 전용 브리지 호출 방식이 안전

2) 문제 정의

현재 search_result는 카테고리 구분 없이 VideoModalManager 1개만 사용한다. 이 상태에서 발생 가능한 불일치:

• onboarding/legal: 전용 템플릿/전용 상태 흐름 미적용
• insight: 페이지 내 리스트 기반 추천 정책 미반영
• biztrend: 전용 모달 UI/브리지 미사용

즉, 검색 결과에서 클릭한 카드가 원본 카테고리 페이지의 체험과 달라질 수 있다.

3) 분기 설계안 (코드 적용 전 제안)

분기 기준: video.category_code (필요 시 category_group 보조)

제안 라우팅:

• CA10001 (마이클래스)
  • 핸들러: VideoModalManager
  • 추천: goal API 분기 유지
• CA10004 (리더십)
  • 1안(보수): 현행 VideoModalManager 유지 + 공용 추천 API
  • 2안(동일 UX 우선): leadership 전용 openModal 브리지 추가
• CA10005 (인사이트)
  • 인사이트 전용 모달 브리지 사용 권장
  • 이유: 추천 로직이 DOM 기반(동일 정책 유지)
• CA10006 (비즈트렌드)
  • window._biztrendOpenModal 브리지 우선 호출
• CA10002 (온보딩)
  • onboarding 전용 모달 호출(별도 브리지 또는 전용 manager 인스턴스)
• CA10003 (법정교육)
  • learning 전용 모달 호출(별도 브리지 또는 전용 VideoModal 인스턴스)
• 기타/미지정
  • 공통 VideoModalManager fallback

핵심:

• "공통으로 합치는 것"이 아니라 "카테고리 정책을 보존한 라우팅"이 목적.

4) search_result 적용 방식 제안

Step 1. 공통 분기 함수 도입

예: openSearchResultVideoByCategory(videoData)

• 입력: 현재 카드의 videoData
• 처리:
  1. category_code 판별
  2. 해당 카테고리 브리지 존재 여부 확인
  3. 브리지 있으면 전용 모달 호출
  4. 없으면 modalManager.openVideo(videoData.id) fallback

Step 2. 브리지 인터페이스 표준화

각 전용 페이지가 search_result에서도 재사용할 수 있도록 전역 함수 노출 표준 정의:

• onboarding: window._onboardingOpenModal(info)
• learning: window._learningOpenModal(info)
• leadership: window._leadershipOpenModal(info) (선택)
• insight: window._insightOpenModal(info)
• biztrend: 기존 window._biztrendOpenModal(info) 재사용

info 공통 스키마 제안:

• contentId
• videoUrl
• title
• description
• categoryName
• subCategory
• watchTm
• contentTm
• bookmark

Step 3. search_result 클릭 이벤트 수정(적용 단계에서)

현재 .card 클릭 -> modalManager.openVideo(videoId) 고정 호출. 이를 openSearchResultVideoByCategory(videoData) 호출로 변경.

5) 리스크 및 방지책

리스크:

• 전용 페이지 스크립트가 해당 페이지 DOM 전제(selector)를 강하게 가지는 경우 search_result에서 재사용 불가
• 전역 브리지 함수 미로딩 시 호출 실패
• 추천 정책 혼선(특히 insight DOM 기반)

방지책:

• 브리지 함수 내부에서 필요한 최소 DOM만 모달 내부로 한정
• 브리지 호출 전 typeof window._xxxOpenModal === 'function' 체크 + fallback
• 카테고리별 E2E 체크리스트 운영

6) 테스트 체크리스트 (코드 적용 후 검증용)

공통:

• 검색 결과 카드 클릭 시 모달 정상 오픈
• 닫기/ESC/배경 클릭 동작 정상
• 북마크 토글 즉시 반영 + 재오픈 시 유지
• 시청시간 저장/이어보기 동작

카테고리별:

• myclass: 추천이 동일 goal_code 묶음으로 노출되는지
• onboarding: 전용 템플릿/챕터 문맥 깨지지 않는지
• legal: skip 제한/진도 저장이 기존과 동일한지
• leadership: 키워드 기반 추천 API 노출 정상
• insight: 페이지 내 리스트 기반 추천 정책 유지
• biztrend: 전용 모달 UI + 외부 YouTube 폴백 동작

6-1) 카테고리별 기능 보존 요구사항 (절대 누락/변경 금지)

목표:

• search_result에서 모달 분기를 통합하더라도, 각 카테고리 기존 기능은 단 하나도 누락/변경되지 않아야 한다.

1. 마이클래스

• 한줄소감문
• 관련영상 리스트: 동일 목표(goal) 내 영상 리스트업
• skip 방지
• 시청기록 저장
• 북마크 기능

2. 온보딩

• 댓글
• 차시 리스트
• skip 방지
• 시청기록 저장
• 북마크 기능
• 배속 조절 방지 기능

3. 법정교육

• 차시 리스트
• skip 방지
• 시청기록 저장
• 북마크 기능
• 배속 조절 방지 기능

4. 리더십

• 댓글
• 관련 영상 리스트업
• 시청기록 저장
• 북마크 기능

5. 인사이트

• 댓글
• 관련 영상 리스트업
• 시청기록 저장
• 북마크 기능

6. 비즈트렌드

• 댓글
• 관련 영상 리스트업
• 시청기록 저장
• 북마크 기능

7. index

• 댓글
• 관련 영상 리스트업
• 시청기록 저장
• 북마크 기능

통합 분기 시 적용 원칙:

• 카테고리별 기능 차이는 유지하고, 호출 진입점만 통합한다.
• 공통 fallback 적용 시에도 카테고리 전용 기능이 축소되면 안 된다.
• 배속 제한/skip 제한/차시 구조/추천 기준(goal, DOM 기반 등)은 기존 정책을 그대로 유지한다.
• 기능 변경이 필요한 경우, 사전 합의 없이는 적용하지 않는다.

검증 게이트(배포 전 필수):

• 카테고리별로 위 항목을 1개씩 체크하여 전부 통과해야만 완료로 본다.
• 하나라도 실패하면 공통 분기 반영을 보류하고 해당 카테고리 전용 경로를 유지한다.

7) 결론

search_result에 필요한 것은 "모달 단일화"가 아니라 "카테고리 정책 보존형 라우팅"이다. 우선순위는 다음과 같다:

1. 분기 함수 도입
2. 전용 브리지 표준화
3. 브리지 불가 카테고리는 공통 모달 fallback

이 순서로 적용하면 기존 페이지의 안정성을 유지하면서 search_result 정합성을 높일 수 있다.