admin/front 분리

docs/verification-checklist.md

@@ -1,26 +1,48 @@
 # 검증 및 체크리스트
 
-## 기본 검증 원칙
-- 현재 테스트 코드는 최소 수준이므로 기능 수정 시 단위 테스트 또는 최소 통합 검증 범위를 직접 보강하는 쪽을 우선한다.
-- 기동 실패 가능성이 있는 설정 변경은 실행 또는 테스트로 검증한다.
-- 검증하지 못한 내용은 추정으로 말하지 않고 미실행 사유를 적는다.
+## 기본 검증
 
-## 변경 시 체크리스트
-- 변경한 코드와 직접 관련된 파일만 수정했는지 확인한다.
-- 새 API, 스케줄러, 설정 추가 시 관련 설정 파일과 테스트를 함께 검토한다.
-- 로그 레벨과 로그량이 운영 환경에서 감당 가능한지 확인한다.
-- Mapper 인터페이스 추가/변경 시 XML namespace, id, parameter/result 매핑이 같이 맞는지 확인한다.
-- 공개 경로나 권한 정책을 바꿨다면 SecurityConfig 와 Swagger 노출 범위를 같이 확인한다.
-- 파일 업로드/다운로드 기능 수정 시 DB 상태, Redis 상태, 실제 파일 시스템 경로가 같이 맞는지 확인한다.
-- TUS 경로를 바꾸면 nginx `/_upload_auth`, tusd hook URL, `SecurityConfig` 공개 경로, `tus-file.upload.tus-endpoint` 를 함께 확인한다.
-- `/file/**`, `/tus/file/**`, `/cors/**` 같은 shared API 권한을 바꾸면 user/admin 토큰 쿠키와 Bearer 인증이 모두 의도대로 동작하는지 확인한다.
-- SunEditor 또는 단순 업로드 설정을 바꾸면 `file.upload.root-path`, `file.upload.view.file-domain`, nginx `/uploads/` alias 경로가 같은 저장 루트를 가리키는지 확인한다.
+- 변경 범위와 직접 관련된 모듈만 수정했는지 확인합니다.
+- core 변경은 `:01-api-core:compileJava`를, 실행 모듈 변경은 `:02-api-admin:compileJava`, `:03-api-front:compileJava`를 최소 검증으로 사용합니다.
+- 실행 설정이나 빈 구성이 바뀌면 admin/front를 각각 기동하거나 관련 테스트를 실행합니다.
+- 검증하지 못한 항목은 사유를 명확히 남깁니다.
 
-## 기능 특성별 점검 포인트
-- 스케줄러 코드는 실행 주기, 중복 실행 가능성, 로그량을 반드시 점검한다.
-- 인증 방식이 섞여 있으므로 세션 기반 처리와 JWT `SecurityContext` 사용 위치를 먼저 구분하고 수정한다.
-- 파일 경로를 다루는 기능은 상대경로 탈출, 루트 이탈 방지 같은 검증을 같이 본다.
-- 설정 파일 수정 시 `local`, `pjt`, 공통 설정 간 차이를 함께 확인한다.
-- file-domain 정적 파일은 `/uploads/editor/...` 같은 최종 파일 URL이 브라우저에서 직접 열리는지 확인한다.
-- `/uploads/tmp/...` 는 404로 막히는지 확인한다.
-- SunEditor 업로드는 응답 JSON의 `result[].url` 이 file-domain 절대 URL인지 확인하고, 에디터 본문에 이미지가 실제 삽입되는지 확인한다.
+## 모듈 완료 검증
+
+- 구현 중에는 관련 모듈의 `compileJava`와 필요한 단위 테스트를 수시 실행합니다.
+- 모듈 작업을 완료하면 Core와 해당 실행 모듈의 `build`를 실행합니다.
+- 통합 테스트는 Spring, MyBatis, Security, DB 등 해당 기능의 연결 범위를 검증합니다.
+- 실제 연동 검증은 `API -> DB -> 조회 API`를 기본으로 합니다.
+- Redis, 파일, 외부 API, 메시지 등은 해당 기능이 실제로 사용할 때만 추가 검증합니다.
+- 실제 개발 데이터를 변경한 테스트는 테스트 데이터를 삭제하거나 원복합니다.
+
+## 업무 이관
+
+- Java Mapper, Mapper XML, namespace, id, DTO 패키지 참조를 함께 변경합니다.
+- 범용 처리는 `standard`, 업무 전용 처리는 `bespoke` 기준으로 배치했는지 확인합니다.
+- core에 Form, 화면 전용 VO, Controller가 들어가지 않았는지 확인합니다.
+- admin/front에 다른 서버 전용 Controller가 포함되지 않았는지 확인합니다.
+- Controller가 core DTO/VO, core Service 또는 Mapper를 직접 참조하지 않는지 확인합니다.
+- admin/front Service가 core standard/bespoke 호출 조합과 트랜잭션 경계를 소유하는지 확인합니다.
+- bespoke Service/Mapper/XML id가 기준 테이블과 기능명, 결과 형태 규칙을 같은 이름으로 사용하는지 확인합니다.
+
+## 보안
+
+- admin은 `ADMIN` scope와 `adminAccessToken`으로 인증되는지 확인합니다.
+- front는 `USER` scope와 `accessToken`으로 인증되는지 확인합니다.
+- 공개 경로와 역할 정책은 각 서버 `SecurityConfig`에서 확인합니다.
+- Swagger Basic 인증과 API JWT 인증이 각각 의도대로 동작하는지 확인합니다.
+
+## 설정과 리소스
+
+- admin/front의 `application*.yaml`, 로그 설정, banner, robots 리소스가 각 모듈에 있는지 확인합니다.
+- core Mapper XML이 두 bootJar에서 모두 classpath로 읽히는지 확인합니다.
+- `MainDataSourceConfig`가 `mapper/standard`, `mapper/bespoke`의 이관된 XML만 읽는지 확인합니다.
+- migration DataSource를 사용하지 않는 환경에서는 `migration.datasource.*.enabled`가 활성화되지 않았는지 확인합니다.
+- 파일 또는 TUS를 변경하면 저장 경로, nginx, tusd, SecurityConfig를 함께 확인합니다.
+
+## 빌드 산출물
+
+- `:02-api-admin:bootJar` 결과가 `api-admin.jar`인지 확인합니다.
+- `:03-api-front:bootJar` 결과가 `api-front.jar`인지 확인합니다.
+- admin JAR에 front Controller가, front JAR에 admin Controller가 포함되지 않는지 확인합니다.