2026-09-14
레거시 UI 현대화 방식은 기존 업무 기능을 얼마나 다시 쓰느냐로 나뉩니다. 화면을 옮기며 기능을 최대한 살리면 컨버전, 기능 일부를 살리며 구조를 개편하면 모더나이제이션, 처음부터 다시 설계하면 마이그레이션입니다.
세 용어는 문헌과 업체마다 조금씩 다르게 쓰입니다. 이 글은 위 정의를 기준으로 각 방식의 작업 내용, 맞는 상황, 결정 전에 확인할 항목을 설명합니다.
레거시 시스템을 바꾸는 이유는 대개 비슷합니다. 실행 환경이 더 이상 지원되지 않거나, 유지보수 인력을 구하기 어렵거나, 웹과 모바일에서 써야 하기 때문입니다. 방식의 차이는 목적이 아니라 기존 자산을 얼마나 가져가느냐에서 생깁니다.
기존 화면의 업무 로직, 데이터 처리, 화면 배치를 그대로 옮길수록 일정과 위험은 작아지지만 개선 폭도 작습니다. 반대로 새로 설계할수록 업무 흐름까지 바꿀 수 있지만 요구사항 정의부터 다시 해야 합니다.
재사용 범위는 화면 단위로 판단합니다. 같은 시스템이라도 조회 화면은 거의 그대로 옮길 수 있고, 업무 규칙이 자주 바뀐 등록 화면은 새로 설계하는 편이 나을 수 있습니다.
| 구분 | 컨버전 | 모더나이제이션 | 마이그레이션 |
|---|---|---|---|
| 기능 재사용 | 최대한 유지 | 일부 유지 | 새로 설계 |
| 화면 변화 | 배치와 동작 대부분 유지 | 구조와 사용성 개편 | 전면 재설계 |
| 주요 작업 | 원천 분석, 변환, 검증 | 재사용 대상 선별, 변환과 재개발 병행 | 요구사항 정의, 설계, 개발 |
| 일정 부담 | 작음 | 중간 | 큼 |
| 주요 위험 | 기존 구조의 문제도 함께 옮겨짐 | 재사용 경계가 흐려지면 범위가 늘어남 | 숨은 업무 규칙 누락 |
원천 화면을 분석해 새 플랫폼의 화면으로 옮깁니다. 반복되는 변환은 규칙과 도구로 처리하고, 결과를 원본과 대조해 검증합니다. 사용자가 익숙한 화면을 그대로 쓰므로 교육 부담이 적습니다.
안정적인 업무 기능은 변환으로 가져가고, 불편이 컸던 화면이나 흐름은 새로 만듭니다. 재사용할 부분과 새로 만들 부분의 경계를 초기에 문서로 확정하는 것이 핵심입니다.
기존 시스템은 참고 자료로만 쓰고 새 플랫폼에서 다시 설계합니다. 업무 방식 자체를 바꾸려는 경우에 맞지만, 기존 화면에 숨어 있던 예외 처리를 빠뜨리지 않도록 현행 분석을 충분히 해야 합니다.
한 시스템 안에서도 화면마다 맞는 방식이 다를 수 있습니다. 대부분의 화면은 변환하고 일부 화면만 재개발하는 혼합 구성도 검토할 수 있습니다.
특히 업무 로직의 위치는 방식별 공수를 크게 바꿉니다. 로직이 서버에 있으면 화면만 옮기면 되지만, 화면 스크립트에 섞여 있으면 어느 방식이든 스크립트 분석이 먼저 필요합니다.
이 네 가지가 정리되면 선택지는 대부분 좁혀집니다. 이 정보 없이 방식을 먼저 정하면 사업 중간에 범위가 바뀌기 쉽습니다.
화면 배치와 업무 동작은 대부분 유지됩니다. 다만 새 플랫폼에서 지원하지 않는 기능이나 외부 컴포넌트는 대체 구현이 필요하고, 스타일은 새 환경의 기준으로 정리하는 경우가 많습니다.
기존 업무 기능의 일부를 변환해서 다시 쓰면 모더나이제이션, 기존 시스템을 참고만 하고 새로 설계하면 마이그레이션으로 구분합니다.
됩니다. 화면 유형별로 변환 대상과 재개발 대상을 나누고, 두 결과물이 같은 화면 표준과 공통 모듈을 쓰도록 먼저 정해 두면 됩니다.
현재 플랫폼과 화면 규모를 알려주시면 이젠고가 방식별 적용 가능성을 검토해 회신드립니다.