api2/docs/verification-checklist.md

검증 및 체크리스트

기본 검증

• 변경 범위와 직접 관련된 모듈만 수정했는지 확인합니다.
• core 변경은 :01-api-core:compileJava를, 실행 모듈 변경은 :02-api-admin:compileJava, :03-api-front:compileJava를 최소 검증으로 사용합니다.
• 실행 설정이나 빈 구성이 바뀌면 admin/front를 각각 기동하거나 관련 테스트를 실행합니다.
• 검증하지 못한 항목은 사유를 명확히 남깁니다.

모듈 완료 검증

• 구현 중에는 관련 모듈의 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가 포함되지 않는지 확인합니다.