Home데브기어 새소식기술자료[UX Summit 요약] 레거시 데스크탑 앱 UI/UX 현대화 – 이론부터 실제까지

[UX Summit 요약] 레거시 데스크탑 앱 UI/UX 현대화 – 이론부터 실제까지

  • 2020-11-09
  • Posted by: Narae Kim
  • Category: 기술자료
댓글 없음


레거시 데스크탑 앱 UI/UX 현대화를 주제로 선정한 이유

  • 이제는, 앱의 생존 조건으로, UI가 너무나 중요하기 때문에
  • 실제로 어려움이 있기 때문에
  • 델파이 개발자들이 도움을 필요로 하는 주제이기 때문에
  • 회사들이 요청을 하기 때문에


목차

전형적인 상황: “15년된 데스크톱 앱이 있는데 못생겼습니다. 애플 같은 UI를 가진 앱으로 바꾸고 싶은데 어떻게 해야 하나요?”
가능한 모든 것을 쉽게 진행해야 한다. 하지만, 쉽게 하는 방법을 찾는 것이 쉽지 않다.

  • [방향 선택] 첫번째 질문: 윈도우용 데스크톱 유지? 재설계?
  • [기반 기술 선택] 전형적인 윈도우 데스크톱 앱? 웹 기반 데스크톱 앱? 크로스-플랫폼 앱?
  • [구현 기술 선택] 사용할 수 있는 데스크탑 앱 개발 기술: VCL, FMX, PWA, …
  • [위험 관리] 마이그레이션 시 주의해야 할 함정
  • [절차와 시연] 발표자가 현대화 프로젝트를 수행하는 기본 절차
    • 1.사전 분석 및 결정: 기존 앱을 마이그레이션? 새로 개발?
    • 2.프로토타입 제작: 도구와 기술 소개 및 시연
    • 3.디자인: 디자이너가 필요한가?
    • 4.UI와 컴포넌트 구현: 자체 개발 또는 써드 타피 컴포넌트 사용
  • [실제 사례 전달] 사례1. UI 마이그레이션 프로젝트
  • [실제 사례 전달] 사례2. (하이브리드, 웹, 크로스-플랫폼이 아니라) 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트


당신의 앱 vs 애플 스타일 앱

  • 애플 스타일 앱은 사용자에게는 쉽고 단순하다. 하지만, 이런 수준의 UX를 구현하려면, 개발 능력 뿐만 아니라 풍부한 경험, 통찰력, 최신 트렌드와 고객에 대한 이해력까지 갖추어야 한다.
  • 당신의 앱이 못생기고 퇴물 같은 모습이라고 느껴지는가? 당신 잘못이 아니다. 나를 포함한 우리 모두 마찬가지 앱을 만들었다. 10~20년 전에 만든 것들이고 그때는 다들 그랬다. 10년전에 나온 자동차를 보면 지금 자동차에 비해 디자인이 훨씬 뒤떨어져 보이지 않는가?
  • 새 표준, 새 장비, 새 기능, 시간, 새 사용자의 선호도, 유행, 모든 것은 계속 바뀐다!


UI / UX 관련 용어

  • UI 용어: 사용자 눈에 어떻게 보이는가와 관련(스타일, 가독성, 색상…)
  • UX 용어: 각 사용자가 목적을 어떻게 이루는가와 관련(네비게이션, 반응… )
  • UI와 UX 공통 용어: 매력, 경험, 느낌…
  • 프로젝트 진행 시 UI와 UX 전문가가 각각 있는 것보다 한사람이 같이 하는 것이 좋다고 생각한다.


10년이 훌쩍넘은 전통적인 데스크톱 앱

델파이, 비주얼 스튜디오, 이클립스 등으로 만든 오래된 데스크톱 소프트웨어라면 어느 것이든 아래 문제를 가지고 있다.

  • 폼 100개 이상
  • 서로 다른 개발자, 서로 다른 컴포넌트, 서로 다른 스타일
  • 복잡한 네비게이션
  • 모든것이 다 작다 (고해상도 DPI를 지원 안됨)
  • 못생긴 UI (구식 화면, 업계 표준을 못 따라감)
  • 텍스트 읽기가 어렵다


지금은 델파이와 C++빌더로 만든 앱들만 다룬다. 그 이유는?

  • 네이티브 데스크톱 앱 개발 시 내가 가장 좋아하는 도구가 델파이이다.
  • 수많은 훌륭한 앱들이 델파이로 개발되어 널리 사용되고 있다.
  • 성능이 중요한 윈도우 데스크톱 앱을 빠르게 개발할 때, 델파이보다 좋은 도구를 아직 본적이 없다.


앱의 UI/UX 현대화 시 “나누어” 고려할 계층(과 이 주제 상 우리의 선택)



(고려할 계층: 어느 계층 안에 어느 계층이 들어가는 지 구분이 필요)

  • 플랫폼 (윈도우 OS) – 아키텍처 (데스트톱 애플리케이션)
  • 프레임워크와 개발 도구 (델파이 VCL과 FMX)
  • 사용자 상호 작용과 네비게이션
  • 스타일과 디자인


기본 전략 선택 :비용, 리스크, 최종 결과물을 종합적으로 고려하여 선택하자.

(예) 32-bit VCL 앱의 UI/UX 현대화 시, 선택할 수 있는 전략

  • 델파이 버전을 유지한 채, 색상 변경 등 UI와 UX만 현대화하고 나머지는 손대지 않기
  • 델파이 업그레이드 후 최신 VCL로 마이그레이션하기 (고해상도, 유니코드, 64-bit 모두 지원)
  • 델파이 업그레이드 후 최신 FMX로 마이그레이션하기 (고해상도, 유니코드, 64-bit 모두 지원 뿐만 아니라 필요시 맥OS와 리눅스 등 다른 플랫폼까지 지원 가능, 단, FMX와 VCL은 UI 영역의 엔진이 별개이므로 FMX에 대한 이해가 필요함)
  • PWA / Electron / 데스크톱 웹 – 웹 앱 – 모바일 앱
  • …


구현 방안 선택 :앱의 UI/UX 현대화 구현 시, 고려할 방안

  • 기존 화면이 훌륭하다면, 유지하면서 모양만 현대식으로 바꾸기 (이 경우, UI는 멋지게 바꿀 수 있지만, 네비게이션 등 UX는 손대지 못함)
  • 완전히 새로 폼 화면을 모두 현대화 하고 새 UX를 적용하기
  • 메인 폼 화면만 현대화 하기
  • 스타일만 적용하기 (주의, 스타일이 적용되지 않는 써드파티 컴포넌트들도 있음)
  • 컴포넌트를 업데이트하기 (일반 버튼을 멋진 스타일기반 버튼으로 업데이트)


위험 관리 :리스크 발생 가능성과 실패 확률은 정비례한다.

“비즈니스 분석 단계”에서 아래 영역을 나열하고 영역별 해당 요소를 적고 하나씩 검토하자.


위험 관리 검토 영역

  • 예산
  • 인적 자원과 역량
  • 시간
  • 버그 (기존 앱에는 수많은 버그 해소의 경험이 녹아있다. 버그가 새로 만들어 질 여지를 살피자)
  • 컴포넌트 마이그레이션
  • 잘못된 결정
  • 기대치
  • 잘못된 프로젝트 일정
  • 기술적 데드락
  • 커뮤니케이션 리스크
  • 병렬 개발 (기존 앱을 유지보수 하면서 고쳐간다면 코드 브랜치와 병합의 위험 고려가 필요)
  • …


수행 절차(와 시연) :발표자가 현대화 프로젝트를 수행하는 기본 절차

  • 비즈니스 분석
  • (생략 가능) 와이어 프레임 제작
  • (생략 가능) 디자이너의 작업
  • 구현

1. 비즈니스 분석 :목표, 전략, 위험 관리 등 계획 수립 단계

  • 마이그레이션 전략 선택
  • 리스크 관리 수행
  • 네비게이션 맵 작성 (계층도, 마인드 맵…):
    • 폼이름을 서로 연결하여 현재의 계층과 흐름을 작성한 후 더 사용하기 쉬운 흐름으로 개선
    • 같은 수준의 폼은 같은 모양의 글상자로 표현하여 흐름 뿐만 아니라 계층도 명확히 할것
    • (팀원들과 공유하기 좋은 도구인) Mind Meister로 시연 (https://www.mindmeister.com , 이외에도 비지오, 등 다른 도구 사용 가능)
  • 브레인스토밍, 안쓰는 폼을 모두 찾아서 제거 (개발 당시에는 분명히 필요하다고 믿었지만, 정작 개발 후에는 전혀 안쓰는 폼들이 반드시 있다. 어쩌면 많을 수도 있다)
  • 컴포넌트 마이그레이션 표 작성: 델파이 최신 버전에서 작동하는 지가 매우 중요
(Sample) 각 열의 제목에 대한 번역:
  • 프로젝트 관리 절차 확정: 프로젝트 관리가 중요해지는 시점
2. (생략 가능) 와이어 프레임 제작 :작업 범위, 변경할 영역을 내부 의견이 반영되는 단계
  • 20~30개 주요 화면을 와이어 프레임 도구를 사용하여 구현
    • 사용자가 실제로 어떻게 네비게이션을 하고 앱이 어떻게 반응하는 지를 빠르게 구현하는 도구가 필요
    • HotGloo.io로 시연
델파이 처럼 콘트롤이 제공되며, 폼 전환, 액션 등을 넣을 수 있는 도구. 팝업 윈도우도 구현 가능. 모든 폼에 공통으로 표시되는 영역도 설정 가능
(스샷)
    • inVisionApp.com로 시연
: 디자인 시안이 있다면 사용하기 좋은 도구(이미지 파일에서 원하는 영역에 폼 전환과 액션을 연결)
(스샷)
    • 이외에도 Axure RP, 비지오, 포토샵 등 다른 도구 사용 가능
  • 내부 시연 및 의견 수렴
  • 컴포넌트 마이그레이션 표


(컴포넌트 마이그레이션 표: 각 열의 항목 번역) 컴포넌트명, 최신 델파이 지원 패키지 유무, 최신 델파이 지원 컴포넌트 유무, 라이선스 정보, 라이선스 비용, 최신 델파이 지원이 안될 경우 선택할 수 있는 대체품, 대체품의 라이선스 정보, 대체품의 라이선스 비용, 무료컴포넌트 여부)

 

3. (생략 가능) 디자이너의 작업:앱을 예쁘게 만들려면 필요함(그림자, 색상 등)
  • 15~25개 주요 폼 화면에 대한 UI와 스타일 요청 (포토샵, 피그마 등)
  • 디자인 검토 회의 및 승인 (기존 사용자의 의견 청취가 중요)
  • (완성된 주요 화면을 기반으로) “브랜드 북”(UI 콘트롤 스타일, 네비게이션 규칙…) 작성



(브랜드 북)

4. 구현
  • 컴포넌트 마이그레이션, 필요시 자체 구현
  • 폼 마이그레이션 또는 구현
  • 소스 코드 리펙토링
  • UI 테스트 자동화

주의할 점 :현대화 시 함정

  • UI/UX 현대화 = 완전히 작동하는 앱 마이그레이션 = 시간과 인력 필요
  • 컴포넌트가 델파이 최신 버전에 맞지 않거나 아예 없을 수 있다.
  • 일정 계획을 확정하기 어렵다. 단계적으로 하는 것이 좋다.
  • 완전히 작동하는 앱으로 전환하지 못한 채 길게 지연되면 프로젝트가 중단되는 결과

 

[실제 사례 전달] 사례1. UI 마이그레이션 프로젝트 당면 상황: 뷰티 산업의 앱이므로 첫인상이 매우 중요함

UI 현대화와 재설계

  • 델파이7로 개발된 데스크톱 앱 (폼 갯수: 65개 이상)
  • 비즈니스 로직이 폼 파일에서 구현됨 (MVC 패턴 아님)
  • OOP 아님,요즘엔 안쓰는 UI
  • 사용되지 않는 폼이 많음 – 유지 보수가 어려움
  • 시장 점유율 하락 중

수행 내용 및 순서

  • 코드 분석
  • 기존 UI를 재사용하여 멋진 UI로 변경할 수가 없는 상황이었음
  • 핵심 폼 화면은 완전히 새로운 UI로 설계하기로 결정함
  • 네비게이션 맵 작성 (도구: Visio)
  • 새 폼과 새 네비게이션, 새 컴포넌트를 프로토타입으로 구현, 새 검색 필드 등 향상된 새 UI가 어떻게 사용될 수 있는지를 검증 (도구: HotGloo.io)
  • 폼 20개와 “브랜드 북 (Brand Book)을 디자이너가 작성
  • (FMX 스타일 엔진을 쓰기로 결정했으므로) FMX 애플리케이션을 하나 만듬
  • FMX 애플리케이션이지만 그 안에는 기존 VCL폼을 모두 추가 (VCL, FMX 섞어 쓰기가 가능함)
  • 그 후 기존 VCL 폼을 대체할 새 FMX폼으로 만들어 교체하는 작업을 하나씩 진행, 완료되기 전까지는 VCL 폼이 FMX폼을 호출하거나 FMX 폼이 VCL폼을 호출하면서 작동함

요약

  • UX 현대화 결과 기존 20개 폼은 45개 이상으로 나누어짐 (확인, 알림 등 여러 윈도우 팝업이 일관성이 없고, 현대적인 UI가 아니라고 고객이 결정했기 때문에 폼 갯수는 증가)
  • 총 11개월 걸림. 풀타임은 아니지만 전문가들이 참여 (프로젝트 관리자, 비지니스 분석가, 디자이너, 델파이 FMX 고급 개발자, 델파이 FMX 중급 개발자)
  • UI 프로토타입 만으로도 잠재 고객 3곳을 확보


[실제 사례 전달] 사례2. (하이브리드, 웹, 크로스-플랫폼이 아니라) 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트

당면 상황

델파이가 아닌 다른 기술을 사용하면 성능이 2배 이상 좋아진다 등 외부 전문가의 설득을 고객이 받고 있는 상황

  • 델파이 2006으로 개발된 데스크톱 앱
  • UI 요소가 많고 계산과 화면 구성 작업이 많은 앱 (처리 성능이 매우 중요한 앱) 수행 내용 및 순서
  • (매우 중요) 고객 의견 경청 후 고객의 우려를 분석
  • 비즈니스 분석 후 관련 기술 제안 (.NET WPF + C#, Electron + Javascript)
  • 비교를 위해 동일한 기능을 3개의 서로 다른 기술로 PoC 작성 – 델파이 이외의 기술 (닷넷과 자바스크립트)는 외부 해당 전문가가 코드 검증하여 효율성과 전문성을 보증

비교 결과

  • 델파이 성능이 가장 우수: 델파이(9점), 닷넷 WPF (7점), Electron 자바스크립트 (6점) 순
  • 그리드 안에 그리드가 들어가고 매우 복잡한 그리드에 1,000개 행을 표시할 때 WPF나 Electron은 가끔 엄청 느렸다. (엘렉트론과 델파이 비교 결과는 이전에 한번 발표했었다)
  • 일반 계산은 이미 일반적인 처리 기술이므로 어느 기술이나 별 차이가 없음
  • 하지만, UI 생성은 기술마다 독자적인 방식을 사용함 (속도에서 현격하게 델파이가 빠름, 흥미로운 사실은 닷넷과 델파이 모두 다이렉트X 기반임에도 결과에 차이가 컸음)



(비교 결과 요약표)

요약 

  • 델파이를 유지하기로 결정
  • 고객은 더이상 기술 선택을 고민하지 않음 (숫자로 검증되었으므로 )
  • PoC로 검증된 사항과 별개로 델파이 병렬 라이브러리를 사용한 결과 실제 구현된 속도는 더욱 향상됨


전체 요약 및 권장 사항 :성능이 중요하다면, 네이티브 데스크톱 앱이 최고이다.

  • 한방에 마이그레이션을 하려고 하지 말자 (지속적이고 안전하게 프로젝트를 진행하자)
  • FMX와 VCL을 섞어서 진행하자. (한방에 FMX로만 가는 건 위험할 수 있다)
  • FMX로 결정할 때는 FMX 중 무엇 때문인지 그 이유를 분명히 하자. (윈도우 전용이라면 VCL도 이미 매우 훌륭하다)
  • 델파이 스타일(Styles)을 미리 사용해 본 후에 전체 UI/UX를 현대화 하자. (원한다면 기본 스타일에서 일부만 바꿀 수도 있으므로 알맞은 스타일을 찾아보자)
  • 마이그레이션을 위한 마이그레이션 작업은 하지 말자 (작업을 하고 싶다면 차라리 기능을 확장하자)
  • 각 목적에 알맞은 도구를 사용하자


더 많은 정보: 유튜브 softacom: https://www.youtube.com/channel/UC91eYk4_Qqfobe9P4v8EyYQ/videos

Post Views: 584