# 정책서: 인터페이스/도메인/운영

## 인터페이스별 역할
- 메인 서비스(`alist.co.kr`)
  - 교재/자료, 스마트 콘텐츠, 지원 센터, 마이페이지, 교사 지원 서비스 중심
- 캠퍼스 메인(`a-campus.co.kr`)
  - 서비스 소개, 이용 방법, 체험하기, 캠퍼스 진입
- 캠퍼스 교사용(`class.a-campus.co.kr`)
  - 강좌/학생/학습/알림/수업준비/캠퍼스 관리 중심
- 캠퍼스 학생용(`student.a-campus.co.kr`)
  - 오늘 학습, 셀프 스터디, 나의 학습, 알림방 중심
- 백오피스/CMS(`admin.alist.co.kr`)
  - 운영 관리, 교재/콘텐츠/CMS, 파트너, 홍보, 문의, 통계 관리

## 교사용 I/F 핵심 메뉴
- 강좌 관리
- 학생 관리
- 학습 관리
- 소통방
- 수업 준비
- 마이페이지
- 역할에 따라 가맹 캠퍼스 관리, 캠퍼스 관리, 공지 관리 등 추가 메뉴 노출

## 학생용 I/F 핵심 메뉴
- 오늘 학습
- 셀프 스터디
- 나의 학습
- 알림방
- 마이페이지
- 학생만 `학습 교재 추가`, `교재 추가` 같은 자기주도학습 확장 기능 사용 가능

## 백오피스/CMS 핵심 메뉴
- 관리자/권한 관리
- 메뉴 관리
- 파트너/유통업체 관리
- A*List/A★캠퍼스 메인 관리
- 팝업, 이벤트, FAQ, 세미나, 게시판, 1:1 문의
- 교재 분류/레벨 메타 관리
- 교재 관리, 캠퍼스 서비스 교재 관리
- 콘텐츠 저작/관리, 온라인 콘텐츠 관리, 제휴사 콘텐츠 관리
- 학습 관리, 통계 관리

## 도메인 정책
- 메인 서비스와 캠퍼스 서비스 도메인을 분리한다
- 캠퍼스 생성 시 개인화 도메인을 제공한다
- 기본 URL 구조는 `/home/...`, 임대/개인화 URL 구조는 `/{campusId}/...` 이다
- 학생용 기본 자기주도학습 화면은 `student.a-campus.co.kr/home` 이다
- 개인화 도메인은 서버 부하 분산, 확장성, 운영 편의성을 고려한 정책이다

## 캠퍼스 개인화 도메인 개발 정책
- 정책서에는 Next.js 자동 라우팅 + 미들웨어 + 템플릿 파일 자동 생성 방식이 예시로 제시된다
- 핵심 요구사항은 다음과 같다
- 관리자에서 캠퍼스 ID 등록 시 개인화 경로가 반영될 것
- 캠퍼스 ID별 로고/헤더/GNB 스타일을 동적으로 적용할 것
- 허용된 캠퍼스 ID만 접근 가능하도록 제어할 것
- 기본 사용자와 임대/브랜드 사용자의 URL 흐름을 분리할 것

## 서버/소프트웨어 구성
- Web / WAS / DB / File Storage / Legacy / 관리 서버를 분리한 구성을 기본으로 본다
- 정책서 권장 스택
  - Web: Linux, Apache 2.4, Node.js / Next.js
  - WAS: Linux, Apache/Tomcat 9.x, JDK/OpenJDK, Spring Boot, Gradle, MyBatis, Swagger
  - DB: Linux, MariaDB 10.6 이상
- Legacy 서버는 기존 회원 로그인 연계와 앱 유지 목적상 일정 기간 병행 운영한다

## 데이터 이관 정책
- 교재 정보, 수업 자료, e-Book, 온라인 PPT, 레벨테스트, 문항, 내신 수행평가, 세미나, 교재 소개 등은 재구조화 후 이관 대상이다
- 기존 회원 DB는 품질 이슈와 암호화 방식 차이로 직접 이관이 어렵다
- 기존 앱 화면, 일부 ASP 기반 화면, 구 LMS 학습 이력은 신규 구조와 차이가 커서 병행 운영 또는 별도 연계가 필요하다
- 온라인 PPT는 변환기(PPT to HTML)를 거쳐 탑재한다

## 서비스 오픈 정책
- 개발
- 알파 테스트
- 베타 테스트
- 서비스 오픈 및 운영
- 일정 기간 기존 서비스 시스템 병행 운영

## 개발 해석 포인트
- 정책서의 화면 메뉴는 단순 네비게이션이 아니라 권한/역할/도메인 경계 정의에 가깝다
- 도메인과 URL 구조는 운영 정책과 강하게 연결돼 있으므로 하드코딩보다 설정/데이터 기반 관리가 적합하다
- 레거시 병행 운영과 최초 로그인 연동은 회원 기능 수정 시 항상 영향 범위를 같이 봐야 한다