2026-09-14
로우코드 도입이 기존 시스템에서 막히는 지점은 새 화면 개발이 아니라, 이미 운영 중인 레거시 화면을 로우코드 환경으로 옮기는 단계입니다. 로우코드는 새로 만드는 화면을 빠르게 하지만 기존 화면을 저절로 가져오지는 않으므로, 도입 검토에 기존 화면 이관 방법을 함께 넣어야 합니다.
로우코드 플랫폼은 화면 배치, 데이터 바인딩, 기본적인 조회와 저장 기능을 시각적 도구와 자동 생성으로 처리합니다. 신규 업무 화면을 만들 때 반복 코딩이 줄어드는 것이 가장 큰 효과입니다.
줄지 않는 일도 있습니다. 기존 업무 규칙을 파악하는 일, 다른 시스템과 연동하는 일, 그리고 다른 기술로 만들어진 화면을 새 환경으로 옮기는 일입니다. 마지막 항목은 도입 제안 단계에서 잘 드러나지 않습니다.
로우코드 도구가 만드는 화면은 대개 도구가 정한 컴포넌트와 배치 규칙을 따릅니다. 기존 화면을 같은 모습과 동작으로 재현해야 한다면 그 차이도 검토 대상입니다.
MiPlatform, XPlatform, JSP, PowerBuilder 같은 레거시 화면은 각자의 화면 정의 형식과 스크립트를 씁니다. 로우코드 도구가 이 형식을 읽지 못하면 기존 화면을 하나씩 다시 그려야 합니다.
오래된 시스템일수록 입력 검사, 계산, 조건 분기가 화면 스크립트 안에 들어 있습니다. 화면만 다시 그리면 이 로직이 빠지고, 로직을 옮기려면 원천 스크립트를 분석해야 합니다.
여러 시기에 여러 인력이 만든 화면은 같은 기능이라도 구현 방식과 스타일이 다릅니다. 이 편차를 정리하지 않고 옮기면 로우코드 환경에서도 표준화의 이점을 얻기 어렵습니다.
앞의 두 항목은 도입 제안서에 잘 나오지 않으므로 먼저 질문해야 합니다.
로우코드 PoC는 흔히 새 화면 몇 개를 만들어 보는 방식으로 진행됩니다. 기존 시스템이 있는 조직이라면 대표 레거시 화면을 새 환경으로 옮겨 보는 항목을 함께 넣어야 합니다.
이관 공수가 크게 나오면 도입을 미루기보다 기존 화면 이관을 별도 전환 작업으로 분리하는 방법도 있습니다. 기존 화면은 전환 도구로 새 환경의 형식에 맞춰 옮기고, 신규 화면은 로우코드로 만드는 식입니다.
플랫폼과 레거시 종류에 따라 다릅니다. 기존 화면 형식을 직접 읽지 못하는 플랫폼이라면 원천 화면을 분석해 새 형식으로 바꾸는 별도 변환 작업이 필요한지 확인해야 합니다.
가능합니다. 다만 두 환경의 화면 표준, 인증, 공통 모듈이 달라 사용자 경험과 유지보수가 둘로 나뉩니다. 기존 화면을 언제 옮길지 계획을 함께 정해 두는 것이 좋습니다.
신규 화면 개발 속도와 함께, 대표 레거시 화면을 옮겼을 때 자동으로 처리된 범위와 수작업으로 남은 범위를 확인해야 합니다. 이 결과가 전체 이관 공수를 추정하는 근거가 됩니다.
대표 레거시 화면을 보내주시면 이젠고가 변환 가능한 범위와 수작업으로 남는 부분을 정리해 회신드립니다.