2026-09-14
자동 변환 결과는 화면, 로직, 데이터 세 층위로 나눠 원본과 대조해야 합니다. 변환 사업의 공수는 변환보다 확인에 더 많이 들기 때문에, 검증 기준을 변환 전에 정해 두는 것이 일정을 지키는 방법입니다.
변환은 규칙이 정해지면 반복 작업이 됩니다. 검증은 화면마다 원본과 결과를 비교하고, 차이가 허용 범위인지 판단하고, 문제가 있으면 원인을 찾아 다시 변환하는 과정입니다.
오래 운영된 화면에는 예외 처리와 화면별 특수 로직이 쌓여 있습니다. 이런 부분은 설계 문서에 남아 있지 않은 경우가 많아, 원본을 실행해 비교하지 않으면 누락을 찾기 어렵습니다.
차이를 찾는 것보다 그 차이가 문제인지 판단하는 데 더 많은 시간이 듭니다. 새 플랫폼의 기본 동작 때문에 생긴 차이는 허용하고, 업무 결과가 달라지는 차이만 오류로 처리하는 기준이 필요합니다.
| 층위 | 검증 항목 | 방법 | 자동화 정도 |
|---|---|---|---|
| 화면 | 컴포넌트 배치, 크기, 라벨, 탭 순서, 스타일 | 원본과 결과의 화면 캡처 대조, 속성값 비교 | 높음 |
| 로직 | 이벤트 처리, 입력 검사, 조건 분기, 화면 이동 | 업무 시나리오 테스트, 스크립트 비교 | 중간 |
| 데이터 | 조회 결과, 저장값, 코드 변환, 날짜와 숫자 형식 | 같은 입력으로 원본과 결과를 실행해 비교 | 중간 |
| 예외 | 오류 메시지, 권한별 동작, 경계값 | 예외 목록 기반 확인 | 낮음 |
컴포넌트 속성은 원본과 결과를 기계적으로 비교할 수 있습니다. 위치나 크기의 차이가 새 플랫폼의 표준 때문인지 변환 오류인지 구분할 허용 기준을 미리 정해 둡니다.
업무 시나리오를 기준으로 원본과 결과를 같은 조건에서 실행하고 결과를 비교합니다. 조회 조건, 저장한 값, 계산 결과처럼 사용자가 확인하는 값이 같은지가 기준입니다.
모든 화면을 사람이 같은 깊이로 보는 방식은 화면이 많을수록 유지하기 어렵습니다. 자동 대조를 통과한 화면은 표본으로 확인하고, 예외로 걸린 화면에 사람의 시간을 모읍니다.
예외는 원인별로 묶습니다. 같은 원인의 오류가 여러 화면에 반복되면 화면마다 고치기보다 변환 규칙을 고친 뒤 해당 유형을 다시 변환하는 편이 빠릅니다. 규칙으로 해결되지 않는 예외만 개별 수정 대상으로 남깁니다.
예외를 기록할 때는 원인과 함께 영향 범위를 적습니다. 일부 화면에만 있는 예외인지, 특정 유형 전체에 걸친 예외인지에 따라 규칙 수정과 개별 수정 중 효율적인 쪽이 달라집니다.
기준표는 변환 착수 전에 원본 시스템을 운영해 온 담당자와 함께 확정합니다. 원본을 가장 잘 아는 사람이 허용 차이를 정해야 오픈 직전에 기준이 바뀌는 일을 줄일 수 있습니다.
모든 화면을 같은 깊이로 볼 필요는 없습니다. 자동 대조를 통과한 화면은 표본으로 확인하고, 예외로 분류된 화면과 핵심 업무 화면을 중점적으로 확인합니다.
변환을 시작하기 전에 정해야 합니다. 허용 차이와 통과 기준이 없으면 같은 결과를 두고 담당자마다 판단이 달라지고 재작업 범위가 늘어납니다.
화면마다 고치지 않고 원인이 된 변환 규칙을 수정한 뒤 해당 유형의 화면을 다시 변환합니다. 이후 같은 기준으로 다시 대조해 수정 결과를 확인합니다.
대표 화면과 업무 시나리오를 알려주시면 이젠고가 층위별 검증 항목을 정리해 회신드립니다.