2026-09-14
화면 수가 많고 업무 로직이 안정적이면 자동 변환이, 업무 흐름 자체를 바꿔야 하면 재개발이 유리합니다. 시스템 전체를 한쪽으로 정하기보다 화면을 유형별로 나눠 변환 대상과 재개발 대상을 가르는 편이 위험이 작습니다.
재개발은 요구사항을 다시 정리하고 새 플랫폼에서 화면과 로직을 새로 만드는 방식입니다. 자동 변환은 원천 화면의 구조와 스크립트를 분석해 정해진 규칙으로 새 플랫폼의 소스를 생성하고, 규칙으로 처리되지 않는 부분만 사람이 손봅니다.
두 방식은 공수가 드는 곳이 다릅니다. 재개발은 화면 하나하나에 설계, 개발, 테스트 공수가 듭니다. 자동 변환은 초기 분석과 규칙 정의, 그리고 변환 뒤 검증에 공수가 몰립니다. 그래서 화면 수가 늘수록 자동 변환 쪽의 화면당 부담이 줄어듭니다.
결과물의 성격도 다릅니다. 재개발 결과는 새 요구사항을 반영한 화면이고, 자동 변환 결과는 기존 화면과 같은 동작을 하는 새 플랫폼의 화면입니다. 따라서 자동 변환의 품질 기준은 원본과 같게 동작하는가이고, 재개발의 품질 기준은 새로 정의한 요구사항을 충족하는가입니다.
아래 다섯 기준은 시스템 전체가 아니라 화면 유형 단위로 적용합니다.
| 기준 | 자동 변환이 유리한 조건 | 재개발이 유리한 조건 |
|---|---|---|
| 화면 규모 | 화면이 많고 유형이 반복된다 | 화면이 적거나 유형이 제각각이다 |
| 업무 변경 폭 | 현재 업무 흐름을 유지한다 | 업무 흐름과 데이터 구조를 바꾼다 |
| 원천 코드 상태 | 공통 모듈과 명명 규칙이 일정하다 | 화면마다 구현 방식이 달라 규칙을 만들기 어렵다 |
| 일정 | 실행 환경 종료 등으로 시한이 정해져 있다 | 일정 여유가 있고 단계적 오픈이 가능하다 |
| 운영 인력 | 기존 화면을 아는 운영자가 검증에 참여할 수 있다 | 새 업무를 정의할 현업 담당자가 있다 |
다섯 기준이 한쪽으로 모이면 판단이 쉽습니다. 기준이 엇갈릴 때는 업무 변경 폭을 먼저 봅니다. 업무가 바뀔 화면을 변환하면 변환한 뒤 다시 고쳐야 하므로 같은 화면에 두 번 공수가 듭니다.
원천 코드 상태는 문서보다 실제 소스를 봐야 알 수 있습니다. 같은 기능을 화면마다 다른 방식으로 구현했거나 공통 함수를 복사해 고쳐 쓴 흔적이 많으면 변환 규칙의 예외가 늘어납니다.
업무 시스템에는 조회, 등록과 수정, 팝업, 출력처럼 반복되는 화면 유형이 있습니다. 이런 화면은 변환 대상으로, 업무가 바뀌거나 구현이 특이한 화면은 재개발 대상으로 나눕니다.
대표 화면 시험 변환은 가장 확실한 판단 근거입니다. 문서만으로는 알기 어려운 원천 코드의 편차가 이 단계에서 드러납니다.
이 자료는 방식 선택뿐 아니라 일정과 공수를 산정하는 근거로도 쓰입니다. 화면 목록에 사용 빈도를 붙여 두면 거의 쓰지 않는 화면을 전환 대상에서 빼는 판단도 함께 할 수 있습니다.
아닙니다. 정형화된 변환은 규칙으로 처리되지만 복잡한 스크립트, 외부 컴포넌트, 예외 처리는 사람이 확인하고 보완해야 합니다. 목표는 수작업을 없애는 것이 아니라 줄이는 것입니다.
화면 수가 적으면 규칙 정의와 검증 준비에 드는 초기 공수의 비중이 커집니다. 이 경우 재개발 공수와 비교해 보고 정하는 것이 좋습니다.
변환 결과는 새 플랫폼의 소스이므로 오픈 이후에는 일반 개발과 같은 방식으로 수정할 수 있습니다. 변환 전에 화면 표준을 정해 두면 이후 개선 작업도 수월합니다.
원천 화면 목록이나 대표 화면을 보내주시면 이젠고가 유형별 변환 적합성을 검토해 회신드립니다.