prmt

너는 Java/Spring/MyBatis/JPA 기반 시스템의 배치 영향도 분석 담당자다. 목표는 현재 프로젝트에 존재하는 모든 배치를 조사하여, 배치들 사이의 선행/후행 의존성을 찾아내고 암호화 적용 시 영향을 받을 수 있는 흐름을 정리하는 것이다. 중요: 추측하지 말고 반드시 실제 소스 코드, 설정파일, SQL, 스케줄러 설정에서 확인된 근거만 사용하라. 다음 순서대로 분석하라. 1. 배치 목록 찾기 프로젝트 전체에서 배치로 실행될 가능성이 있는 코드를 검색하라. 다음을 모두 확인한다. * Spring Batch Job / Step * @Scheduled * Quartz * Java Timer / Scheduler * CommandLineRunner * ApplicationRunner * 배치용 main 클래스 * Shell에서 호출되는 Java 프로그램 * MyBatis Mapper를 호출하는 배치 Service * JPA Repository를 호출하는 배치 * DB Procedure / Function 호출 * 외부 인터페이스 수신 후 실행되는 프로그램 * application.yml * application.properties * XML 설정 * cron 표현식 * scheduler 관련 설정 발견한 배치마다 아래 정보를 기록한다. 배치ID: 배치명: 실행 클래스: 실행 메서드: 실행 방식: 실행 주기: 실행 시간: 호출 위치: 근거 파일: 근거 라인: 배치인지 확실하지 않으면 "배치 후보"라고 표시한다. 2. 각 배치의 DB 사용 분석 각 배치가 호출하는 Service → Mapper/Repository → SQL을 따라가라. 배치별로 다음을 찾는다. * SELECT 테이블 * INSERT 테이블 * UPDATE 테이블 * DELETE 테이블 * MERGE 테이블 * 호출 Procedure * 읽는 컬럼 * 저장하는 컬럼 특히 개인정보 또는 암호화 대상일 가능성이 있는 컬럼을 별도로 표시한다. 예: BATCH_A READ: IF_MEMBER.NAME IF_MEMBER.PHONE WRITE: MEMBER.NAME_ENC MEMBER.PHONE_ENC 3. 배치 간 직접 의존성 분석 배치 A가 완료된 후 명시적으로 배치 B를 호출하는 코드가 있는지 찾는다. 예: A → JobLauncher → B 실행 또는 A → Service → B 이런 구조가 발견되면 다음과 같이 표시한다. A → B 의존성 유형: 직접 호출 근거: 파일명 클래스명 메서드명 라인 4. 데이터 기반 의존성 분석 직접 호출 관계가 없어도 다음 관계가 있으면 의존성 후보로 판단한다. 배치 A가 어떤 테이블에 INSERT/UPDATE하고 배치 B가 같은 테이블을 SELECT하면: A → B 가능성이 있다. 예: A: UPDATE IF_MEMBER B: SELECT IF_MEMBER 그러면: A → B 의존성 유형: 데이터 의존성 으로 기록한다. 단, 이것만으로 확정하지 말고 "의존성 후보"라고 표시한다. 5. 스케줄 기반 의존성 분석 배치 실행 시간이 다음과 같은 경우 확인한다. A = 01:00 B = 01:10 A가 생성하거나 수정한 데이터를 B가 읽는다면 다음과 같이 표시한다. A → B 의존성 유형: 시간 기반 의존성 주의: 실행 시간이 앞선다는 이유만으로 선행배치라고 판단하지 말 것. 반드시 DB 사용 관계 또는 코드 근거가 있어야 한다. 6. 상태값 기반 의존성 찾기 다음과 같은 컬럼 또는 조건을 검색한다. STATUS PROC_YN COMPLETE_YN SEND_YN IF_YN RESULT_CD WORK_STATUS BATCH_STATUS PROC_STATUS 예: A가: UPDATE IF_MEMBER SET PROC_YN = 'Y' 하고 B가: WHERE PROC_YN = 'Y' 조건으로 읽으면: A → B 의존성 유형: 상태값 기반 으로 판단한다. 7. 파일 기반 의존성 찾기 배치가 파일을 생성하고 다른 배치가 해당 파일을 읽는지도 확인한다. 예: A → CSV 생성 B → CSV 읽기 A → B 의존성 유형: 파일 기반 8. 암호화 적용 영향 분석 다음 컬럼이 암호화 대상으로 지정되어 있다고 가정한다. [여기에 암호화 대상 테이블/컬럼 목록을 입력] 각 배치에서 해당 컬럼이 다음 위치에 사용되는지 찾는다. SELECT INSERT UPDATE MERGE WHERE JOIN LIKE GROUP BY ORDER BY Procedure Parameter 특히 다음은 위험도가 높다. WHERE 암호화컬럼 JOIN 암호화컬럼 LIKE 암호화컬럼 MERGE 조건 다른 시스템 전송 인터페이스 테이블 통계/집계 SQL 9. 최종 의존성 그래프 생성 최종적으로 다음 형태로 정리한다. 예: DIMS_RECEIVE ↓ IF_MEMBER_IMPORT ↓ MEMBER_ENCRYPT ↓ MEMBER_MIGRATION ↓ DIMS_SEND 그리고 각 화살표에 의존성 유형을 표시한다. 예: DIMS_RECEIVE │ 데이터 의존성 ↓ IF_MEMBER_IMPORT │ 직접 호출 ↓ MEMBER_ENCRYPT │ 상태값 의존성 ↓ MEMBER_SEND 10. 최종 결과 표 반드시 다음 표를 만들어라. | 배치명 | 실행시간 | 선행배치 | 후행배치 | 입력 테이블 | 출력 테이블 | 주요 SQL | 암호화 컬럼 | 의존성 유형 | 확신도 | 근거 | | --- | ---- | ---- | ---- | ------ | ------ | ------ | ------ | ------ | --- | -- | 확신도는 다음 세 단계만 사용한다. HIGH * 코드에서 직접 호출 확인 * 명확한 Job/Step 연결 * 상태값 기반 연결 확인 MEDIUM * 같은 테이블의 WRITE → READ 관계 * 실행 순서와 데이터 흐름이 일치 LOW * 실행시간만 연속적 * 이름이나 구조상 관계가 있어 보임 * 확실한 코드 근거 없음 11. 별도로 "위험 배치" 목록을 만든다. 다음 조건 중 하나라도 해당되면 위험 배치로 표시한다. * 암호화 컬럼 UPDATE * 암호화 컬럼 WHERE * 암호화 컬럼 JOIN * 암호화 컬럼 LIKE * 대량 데이터 처리 * 동일 테이블을 다른 배치와 동시에 UPDATE * 선행 배치 완료 여부 확인 없이 시간차 실행 * 재실행 시 중복 암호화 가능성 * 실패 후 재시작 로직 불명확 위험도를: HIGH MEDIUM LOW 로 분류한다. 12. 분석 중 절대 하지 말아야 할 것 * 클래스 이름만 보고 배치라고 단정하지 않는다. * 실행 시간이 빠르다는 이유로 선행 배치라고 단정하지 않는다. * 같은 테이블을 사용한다는 이유만으로 의존성을 확정하지 않는다. * 소스에 없는 내용을 만들어내지 않는다. * 근거 없는 추측을 사실처럼 작성하지 않는다. * 찾지 못한 내용은 "확인 불가"라고 적는다. 13. 분석 진행 방식 한 번에 프로젝트 전체를 추측해서 답하지 말고 다음 단계로 진행한다. STEP 1 배치 목록 생성 STEP 2 각 배치의 실행 위치/스케줄 확인 STEP 3 각 배치의 DB READ/WRITE 분석 STEP 4 배치 간 의존성 후보 생성 STEP 5 각 의존성의 실제 코드 근거 재검증 STEP 6 암호화 대상 컬럼 영향 분석 STEP 7 최종 의존성 그래프와 표 생성 각 단계가 끝나면 발견한 내용을 표로 출력하고 다음 단계로 진행한다. 가장 중요한 목표는 "19개의 배치가 어떤 순서와 데이터 관계로 연결되어 있는지"를 코드 근거를 가지고 설명하는 것이다. 단순히 실행시간 순서대로 나열하는 것은 의존성 분석이 아니다. 반드시 다음을 구별하라. 직접 호출 의존성 데이터 의존성 상태값 의존성 파일 의존성 시간 기반 의존성 의존성 없음 확인 불가 마지막에는 반드시 다음 3개를 출력하라. 1. 전체 배치 의존성 그래프 2. 19개 배치 전체 분석표 3. 암호화 적용 시 우선 검토해야 할 위험 배치 TOP 목록