Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

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


Recommended Posts

<< UX Summit 2020 목록으로 이동


UX Summit 의 2020 시리즈 중, Legacy desktop apps UI & UX modernization - Serge Pilko 의 한글 요약본입니다.  


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

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

목차

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

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

당신의 앱 vs 애플 스타일 앱 
(비디오 7분 49초부터 보기)

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

UI/UX 관련 용어
(비디오 6분 57초부터 보기)

1_Term.png
그림1.  UI 전문가가 필요한지 아니면 UX 전문가가 필요한지를 알려면 관련된 용어들이 어디에 속하는지 알아야 한다.

  • UI 에만 해당되는 용어: 사용자 눈에 어떻게 보이는가와 관련 (스타일, 가독성, 색상 등)
  • UX 에만 해당되는 용어: 각 사용자가 목적을 어떻게 이루는가와 관련 (화면 이동, 반응 등)
  • UI와 UX 모두에 걸쳐진 매우 중요한 용어: 매력, 경험, 느낌 등
  • 프로젝트를 진행할 때, UI와 UX 전문가가 따로 있는 것보다 한 사람이 모두 할 수 있으면 더 좋다고 생각한다.
     

10년이 훌쩍넘은 데스크톱 앱의 전형적인 상황
(비디오 8분 54초부터 보기)

델파이, 비주얼 스튜디오, 이클립스 등으로 만든 오래된 데스크톱 소프트웨어 대부분이 가지고 있는 문제

  • 100개가 넘는 화면
  • 서로 다른 개발자, 서로 다른 컴포넌트, 서로 다른 스타일
  • 복잡하고 어색한 화면 이동
  • 모든 것이 다 작게 표현된다. (고해상도 DPI 지원 안 됨)
  • 못생긴 UI (구식 화면, 업계 표준을 못 따라간다.)
  • 텍스트 읽기가 어렵다.
     

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

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

앱의 UI/UX 현대화 시 “나누어” 고려할 (이 세션의 주제에 해당되는) 계층
(비디오 11분 37초부터 보기)

2_Layer.png
그림2. 현대화 프로젝트를 계획하려면, 애플리케이션의 각 계층과 그 범위를 먼저 이해하고, 세부 작업이 어느 계층에 포함되는지를 결정할 수 있어야 한다. 

  • 플랫폼: 윈도우 운영체제
  • 아키텍처: 데스크톱 애플리케이션의 아키텍처
  • 프레임워크와 개발 도구 :델파이 VCL 프레임워크
  • 사용자의 상호 작용과 화면 이동
  • 스타일과 디자인


기본 전략 선택

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

  • 32-bit VCL 앱의 UI/UX를 현대화할 때는 다음 전략 중 하나를 선택할 수 있다 
    • 델파이 버전을 유지색상 변경 등 UI와 UX만 현대화하고 나머지는 손대지 않기
    • 델파이를 업그레이드
      • 최신 VCL로 마이그레이션: 고해상도, 유니코드, 64-bit 모두 지원
      • 최신 FMX로 마이그레이션
        • 고해상도, 유니코드, 64-bit 모두 지원 뿐만 아니라, 필요시 맥OS와 리눅스 등 다른 플랫폼까지 지원 가능
        • 단, FMX와 VCL은 서로 독립된 UI 프레임워크이므로, FMX에 대한 이해가 필요하다.
        • UI를 제외하고, 기능 로직, RTL 등 나머지 코드는 재사용할 수 있다.
    • PWA / Electron / 데스크톱 웹
    • 웹 앱
    • 모바일 앱
       

구현 방안 선택 (새 구성 vs 업데이트)

애플리케이션의 UI / UX를 현대화 할 구현 방안을 결정하자.

  • 화면 기본 구성이 훌륭하다면, 그대로 유지하고 모양만 현대식으로 바꾸기 (이 경우, UI는 멋지게 바꿀 수 있지만, 화면 이동 등 UX에는 손대지 못한다.)
  • 모든 폼 화면을 완전히 새로 현대화 하고 새 UX를 적용하기
  • 메인 폼 화면만 현대화 하기
  • 스타일만 적용하기 (주의: 스타일이 적용되지 않는 써드파티 컴포넌트들도 있다.)
  • 컴포넌트를 업데이트하기 (예: 일반 버튼을 멋진 스타일 기반 버튼으로 업데이트)
     

위험 관리

리스크 발생 가능성과 실패 확률은 정비례한다는 점을 명심하자.

비즈니스 분석 단계에서 위험 관리 항목을 아래와 같이 나열하고 각 영역별 해당 요소를 적고 일일이 검토하자.

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

수행 절차(와 시연): 발표자가 현대화 프로젝트를 수행하는 기본 절차
(비디오 20분 46초부터 보기)

  1. 비즈니스 분석
  2. 와이어 프레임 작성 (생략 또는 간략 수행도 가능)
  3. 디자이너의 작업 (생략 또는 간략 수행도 가능)
  4. 구현
     

1. 비즈니스 분석

목표, 전략, 위험 관리 등 계획 수립 단계
(비디오 23분 01초부터 보기)

  1. 마이그레이션 전략 선택
  2. 리스크 관리 수행
  3. 네비게이션 맵 작성 (계층도, 마인드 맵 등) 

    • 폼이름을 서로 연결하여 현재의 계층과 흐름을 작성한 후 더 사용하기 쉬운 흐름으로 개선 

    • 같은 수준의 폼은 같은 모양의 글상자로 표현하여 흐름 뿐만 아니라 계층도 명확히 할 것

    • (팀원들과 공유하기 좋은 도구인) Mind Meister로 시연 (이외에도 비지오 등 다른 도구 사용 가능)
  4. 브레인스토밍 도구를 활용하여, 안 쓰는 폼을 모두 찾아서 제거
    • 개발 당시에는 분명히 필요하다고 믿었지만, 정작 개발 후에는 전혀 안쓰는 폼들이 반드시 있다. 어쩌면 많을 수도 있다.
    • 유용한 도구: Mind Meister, 비지오, draw.io 등
  5. 컴포넌트 마이그레이션 표 작성
    • 매우 중요하다! 각 컴포넌트가 델파이 최신 버전에서 작동하는지 미리 확인해야한다.
  6. 프로젝트 관리 절차 확정
    • 이 시점부터는 프로젝트 관리가 중요해진다.

Mind Meister를 브레인스토밍 도구로 활용하기 데모
(비디오 25분 05초부터 보기)

3_MindMeister.png

그림3. Mind Meister를 이용하여 기존 애플리케이션의 폼과 그 계층과 관계를 표현한 후에, 내부에 공유하고 브레인스토밍을 진행하고 향상된 구성을 새로 그릴 수 있다. 

컴포넌트 마이그레이션 표

  • 기존에 사용 중인 컴포넌트를 빠짐없이 나열하고 각 컴포넌트의 현황을 명확히 파악하기는 반드시 전략 수립 단계에서 진행해야 한다.
  • 아래의 마이그레이션 관련 항목을 표로 정리하고 확인하자. (실제 프로젝트 중에 필요한 항목이 더 있으면 추가하도록 한다.)
    • 컴포넌트명
    • 최신 델파이 지원 패키지 유무
    • 최신 델파이 지원 컴포넌트 유무
    • 라이선스 정보, 라이선스 비용
    • 최신 델파이 지원이 안될 경우 선택할 수 있는 대체품
    • 대체품의 라이선스 정보
    • 대체품의 라이선스 비용
    • 무료 컴포넌트 여부

6_Tool2InVision.png
그림4. 컴포넌트 마이그레이션를 통해 기존에 사용 중인 컴포넌트를 철저히 분석하고 마이그레이션 방법을 찾는 것은 계획 수립 단계에 미리 진행해야 한다.
 

2. 와이어 프레임 작성 (생략 또는 간략 수행도 가능) 

작업 범위, 변경할 영역을 내부 의견이 반영되는 단계
(비디오 30분 10초부터 보기)

  1. 20~30개 주요 화면을 선정하여 와이어 프레임을 작성

    • 사용자가 애플리케이션을 실제로 어떻게 사용하고, 이에 대해 앱이 어떻게 반응하는 지를 빠르게 구현한다.
      • 기존 애플리케이션의 와이어 프레임을 먼저 만들어서 브레인스토밍을 진행하고, 새 애플리케이션의 와이어 프레임을 만드는 것도 좋다.
    • 와이어 프레임과 프로토타입 작성 도구
  2. 내부 시연 및 의견 수렴

HotGloo.io로 와이어 프레임 작성하기 데모
(비디오 31분 20초부터 보기)

  • HotGloo.io
    • 델파이처럼 UI 컨트롤이 제공되며, 폼 전환, 액션 등을 넣을 수 있다. 
    • 팝업 윈도우를 만들 수도 있고, 모든 폼에 공통으로 표시되는 영역도 설정 가능
하다.

4_CompTable.png
그림5. HotGloo를 활용하면 와이어 프레임이나 프로토타입을 쉽고 빠르게 작성할 수 있다.

inVisionApp.com으로 와이어 프레임 작성하기 데모
(비디오 42분 15초부터 보기)

  • inVisionApp.com
    • 이미지 파일 안의 버튼 등의 부분에 화면 전환, 액션 연결 등 기능을 연결할 수 있다.
    • 화면 이미지나 디자인 시안이 있을 때 활용하기 좋다.

5_Tool1HotGloo.png
그림6. InVision.com은 화면 이미지를 사용한다. 화면 이미지(스크린샷)을 사용하여 마치 동작을 하는 애플리케이션인 것 처럼 보이게 할 수 있어서
더 사실적인 와이어 프레임을 만들 수 있다.
 

3. 디자이너의 작업: 앱을 예쁘게 만들려면 필요함(생략 또는 간략 수행도 가능)

디자인 작업 절차
(비디오 49분 35초부터 보기)

  1. 15~25개 주요 폼 화면에 대한 UI와 스타일 요청
    • 디자이너는 포토샵, 피그마 등을 사용하여 화면을 디자인한다.
  2. 디자인 검토 회의 및 승인
    • 기존 사용자의 의견 청취가 중요하다.
  3. 브랜드북 작성
    • 버튼 등 UI 컨트롤의 스타일, 화면 이동 규칙 등을 정의한다. 
    • 승인을 받은 화면 디자인 컨셉을 기반으로 작성한다. 

브랜드북

7_Brandbook.png
그림7. 브랜드북은 승인을 받은 화면 디자인 컨셉을 각 요소별로 정의하고 표현한다.

4. 구현

마이그레이션 구현 절차
(비디오 51분 20초부터 보기)

  1. 컴포넌트 마이그레이션 (필요시 자체 구현)
  2. 폼 마이그레이션 (또는 구현)
  3. 소스 코드 리팩토링
  4. UI 테스트 자동화 고려
     

마이그레이션 프로젝트에서 주의할 점: 현대화 시 함정

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


[실제 사례 전달] 사례 1. UI 마이그레이션 프로젝트

뷰티 산업의 앱이므로 첫인상이 매우 중요했던 프로젝트 사례
(비디오 55분 09초부터 보기)

  • 현대화 전의 상황 (UI 현대화와 재설계가 필요)
    • 델파이 7로 개발된 데스크톱 앱 (폼 개수: 65개 이상)
    • 비즈니스 로직이 폼 파일 안에 구현됨 (MVC 패턴이 필요)
    • OOP 아님 (리팩토링 필요)
    • 요즘엔 안쓰는 UI (현대화가 필요)
    • 사용되지 않는 폼이 많고 유지 보수가 어려움 (안쓰는 폼 제거가 필요)
    • 시장 점유율 하락 중 (브랜드 이미지 향상이 필요)
       
  • 마이그레이션 프로젝트 내용 및 순서
  1. 코드 분석
  2. 기존 UI를 재사용하는 방식으로는 멋진 UI로 변경할 수가 없는 상황이었음
  3. 핵심 폼 화면은 완전히 새로운 UI로 설계하기로 결정함
  4. 네비게이션 맵 작성 (도구: Visio)
  5. 새 폼과 새 네비게이션, 새 컴포넌트를 프로토타입으로 구현, 새 검색 필드 등 향상된 새 UI가 어떻게 사용될 수 있는지를 검증 (도구: HotGloo.io)
  6. 폼 20개와 브랜드 북(Brand Book)을 디자이너가 작성 
  7. (FMX 스타일 엔진을 쓰기로 결정했으므로) FMX 애플리케이션을 하나 만듦
  8. FMX 애플리케이션이지만 그 안에는 기존 VCL폼을 모두 추가 (VCL과 FMX는 섞어 쓰기가 가능함)
  9. 그 후 기존 VCL 폼을 대체할 새 FMX폼으로 만들어 교체하는 작업을 하나씩 진행, 완료되기 전까지는 VCL 폼이 FMX폼을 호출하거나 FMX 폼이 VCL폼을 호출하면서 작동함
     
  • 요약
    • UX 현대화 결과 기존 20개 폼은 45개 이상으로 나누어짐
      • 기존에는 확인, 알림 등 여러 윈도우 팝업이 일관성이 없고, 현대적인 UI가 아니라는 고객의 의견을 바탕으로 진행했다.
      • 폼을 나누고 표준화한 결과 폼의 개수가 증가되었다.
    • 전체 기간 11개월
      • 풀타임은 아니지만 참여한 전문가: 프로젝트 관리자, 비즈니스 분석가, 디자이너, 델파이 FMX 고급 개발자, 델파이 FMX 중급 개발자
    • 발주처에서는 UI 프로토타입만 가지고 영업을 시작했고 잠재 고객 세 곳을 확보할 수 있었다.
       

[실제 사례 전달] 사례 2. 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트

개발 플랫폼 전환을 검토하기 위해 하이브리드, 웹, 크로스-플랫폼, 델파이 네이티브를  비교 테스트 
(비디오 60분 04초부터 보기)

외부 전문가들이 고객에게 델파이를 걷어내고 다른 기술로 재구축하면 성능이 2배 이상 좋아진다 등의 설득을 하고 있었다.

  • 현대화 전의 상황:
    • 델파이 2006으로 개발된 데스크톱 앱
    • UI 요소가 풍부하고, 계산과 화면 처리 작업이 많음
      • 처리 성능이 매우 중요한 애플리케이션
         
  • 수행 내용 및 순서
    1. 고객 의견을 경청하고, 고객의 우려를 객관적으로 접근 (매우 중요했음!)
    2. 비즈니스 분석 후 분석된 현대 기술을 제안
      • 닷넷 WPF (C#), 엘렉트론(Javascript)
    3. 벤치마크 테스트를 위해 동일한 기능을 구현하는 PoC(Proof of Concept)를 각 세 가지 기술로 구현
    4. 각 기술 (닷넷, 자바스크립트) 별 해당 외부 전문가가 코드를 검증하여 효율성과 전문성을 보증받음
       
  • 요약 
    • 고객은 델파이를 유지하기로 결정
    • 고객은 더이상 기술 선택을 고민하지 않음 (이미 객관적인 비교 결과로 검증되었기 때문)
    • 실제 프로젝트에서는 PoC에서는 사용하지 않았던 델파이 병렬 라이브러리를 사용하여 최종 결과는 더욱 향상됨

비교 결과

  • UX 성능 평가 총점에서 델파이가 가장 우수: 델파이(9점) > 닷넷 WPF (7점) > Electron 자바스크립트 (6점) 순
    • 그리드 안에 그리드가 들어가는 매우 복잡한 그리드에 1,000개 행을 표시할 때 WPF나 Electron은 가끔 엄청 느렸다.
      (참고, 엘렉트론과 델파이를 비교한 결과는 예전에 이미 발표한 적이 있다.)
    • 일반 계산 능력 면에서는 어느 기술이나 별 차이가 없었다.
      • 일반 계산 능력은 이미 일반적인 처리 기술이 되었다.
    • UI 렌더링 면에서 델파이가 속도에서 현격하게 속도가 빨랐다.
      • 각 기술이 독자적인 방식으로 처리하고 있었다.
      • 닷넷과 델파이는 모두 다이렉트X 기반 렌더링을 하였으나, 속도 차이가 컸다는 점이 흥미로웠다.

8_ComparisonTech.png
그림8. 비교 결과 요약표에서 UX 성능 평가 총점과 요소 기능별 결과를 볼 수 있다. 델파이가 9점으로 가장 성능이 좋았다.

이 세션 요약 및 권장 사항

성능이 중요하다면, 네이티브 데스크톱 애플리케이션이 최고의 선택이다.

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

Serge Pilko의 마이그레이션 세션 더보기: Softacom의 레거시 소프트웨어 마이그레이션 전략 유튜브

 

<< UX Summit 2020 목록으로 이동


View full 아티클

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

 공유하기

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.