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

이 사이트 검색

검색 태그: '현대화'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11.0 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. << DelphiCon 2021 목록으로 이동 원본 비디오(YouTube) 보기 (30 min) DelphiCon 의 2021 시리즈 중, Leaving Delphi 7 - A Success Migration Case - Dion Carlos Mai & Rafael Pereira (30 min) 의 한글 요약본입니다. 20년이 넘었고, 델파이 7로 운영하던 대형 시스템을 델파이 10으로 마이그레이션한 프로젝트를 정리한 내용을 공유합니다. 발표자 Rafael은 이 소매점 시스템 제공자인 Stone Co의 개발자입니다. 목차 회사 및 프로젝트 소개 현대화 마이그레이션을 계획하게 된 동기와 결과 마이그레이션 프로젝트의 개요 마이그레이션 프로젝트의 진행 단계 1단계 (분석 단계) 2단계 (실행 단계) 3단계 (검증 단계) 4단계 (배포 단계) 프로젝트를 통해 배운 점 참고 자료 그림 자료 회사 및 프로젝트 소개 회사 소개: Stone Co Linx: 뉴욕 증시에 상장된 브라질의 소프트웨어 기업. 브라질의 소매점 소프트웨어 시장에서 점유율 45.6% Stone: 뉴욕 증시에 상장된 브라질의 Stone Co.의 핀테크 기업. 지불 관리 도구와 유연한 금융 상품을 제공 Stone Co: 2012년에 시작하여 브라질 전역을 커버하고 있다. 2020년 11월, Stone Co는 Linx를 인수 대상 시스템 소개: Linx Big 20년이 넘은 소매점 소프트웨어. 약국에서 주로 사용 현재 3,000개가 넘는 고객사와, 5,000개가 넘는 소매점에서 사용 중 (2개 이상을 사용하는 점포가 많으므로, 배포된 소프트웨어는 훨씬 더 많음) 현대화 마이그레이션을 계획하게 된 동기와 결과 윈도우10은 2021년 10월 현재 전세계 데스크탑 점유율의 80%이상을 차지하고 있고 계속 증가하는 추세임 (관련 통계 보기) 윈도우 10에 집중해야 하는 상황 윈도우 10의 새 운영체제 기능을 충분히 지원하는 IDE 기능이 필요 윈도우 10에 맞는 더 좋은 시각적인 UI가 필요 (그림 참조: 예전 화면과 새 화면 비교) 스타일, 대시보드, 그래프, 메뉴 등 더 풍부한 화면을 제공하여 외관상 완전히 다른 새 소프트웨어로 보임 (그림 참조: 새 화면) 델파이 10에 내장된 컴포넌트와 스타일만 사용하여 화면 개발 새 UI를 구현하기 위한 코드는 새로 작성 하지만, 모든 클래스와 소스 코드는 예전 델파이 7과 거의 같음 스레드가 필요 요즘 소프트웨어는 API 통합이 많다. 델파이 7에서도 스레드를 구현할 수 있다. 하지만, 델파이 7은 소프트웨어를 개발하기에 여전히 매우 훌륭한 도구이지만, 20년 전에 나온 오래된 버전이다. 델파이 최신 버전을 사용하지 않으면, API 통합을 모두 지원하거나 JSON 직렬화하기 등 새 기술을 반영하기가 어렵다. 기타 개선 델파이 10의 장점을 가질 수 있게 됨: 64비트 지원, 윈도우 10 지원, FireDAC으로 데이터 연결, 다른 운영체제에서 접근 등등 델파이 10 시애틀을 선택한 이유 당시 우리 개발자 대부분이 사용할 수 있는 라이선스를 이미 가지고 있었기 때문 마이그레이션 프로젝트의 개요 목표 델파이 7에서 델파이 10 시애틀로 이전 마리아DB 10.4.13과 MySQL 8.0.21 지원 개요 기간: 총 7 개월 투입 인원 외부: 3명 (아쿠아소프트 개발자, 마이그레이션에만 집중) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 마이그레이션 대상 (소매점 관리 시스템)의 규모 델파이 프로젝트: 65개 모듈: 194개 .PAS 파일: 6,000개 .DFM 파일: 2,000개 코드 줄 수: 2백만줄 써드 파티 컴포넌트 세트: 23가지 마이그레이션 프로젝트의 진행 단계 총 4단계로 나누고, 앞 단계 완료 시 다음 단계를 진행: 분석, 실행, 검증, 배포 1단계 (분석 단계) 개요 기간: 3.5개월 투입 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 2명 (개발자 1명, QA 1명) 목표 측정 / 식별 / 문서화 델파이 10으로 마이그레이션이 끼칠 영향 새 데이터베이스와의 호환성 프로젝트로 인해 달라지는 점과 문제점 변경으로 인해 발생될 것으로 예상되는 문제 해소 자동 변환 도구 개발 작업 내용 외부 인력 (아쿠아소프트) 합류 전환할 컴포넌트를 3가지로 나누어 분석하고 대비 버전의 수명이 다한 컴포넌트 마이그레이션 시 문제가 많고, 작업도 많이 해야 하는 것들임 이 프로젝트에서 많이 사용될 컴포넌트 프로젝트에서 사용되는 비중이 크기 때문에, 그 만큼 프로젝트에 끼치는 영향도 큰 것들임 소스코드가 없는 컴포넌트 매우 이상하게 작동할 수 있고 마이그레이션 작업을 까다롭게 만들기 때문에 주의해야 할 것들임 예: Zeos (2003년부터 사용한 오픈 소스 데이터베이스 컴포넌트) [에러가 발생되는 코드] QPrincipal.FieldByName('datapre').AsDateTime :=now; 짐작하겠지만, 상업용 시스템에서 매우 많이 사용되는 코드이며, 모두 수정해야 하므로, 에러 해소 작업이 많다. 델파이 버전 간의 차이와 충돌을 식별하고 해소 유니코드 (영향 받는 dll이 있는 지까지도 파악할 필요가 있음) 자동 변환 도구 개발 ("마이그레이션 찾아 바꾸기"라고 이름 지음) 소스 변환 자동화 도구 개발을 이 분석 단계 안에서 완성 (그림 참조: 소스 변환 자동화 도구와 변환 결과) Zeos에서 UniDAC으로 마이그레이션하는 도구 마법사가 발생시키는 버그 수정 자동화 사용되는 모든 컴포넌트 마이그레이션 자동화 (많은 컴포넌트에서 일부 프로퍼티가 변경되었기 때문) 델파이 10과 델파이 7과의 차이로 인해 필요한 코드 변환 자동화 "모든" 소스를 변환할 수 있는 "맞춤" 도구 완성 소스 코드 동기화 소스 코드 동기화는 매우 중요! 마이그레이션 프로젝트 진행 중에도 전체 배포까지 완료되기 전까지는 전환해야 할 코드가 계속 변하기 때문이다. 분석 단계가 진행되는 중에도 내부 개발자 20명은 여전히 기존 코드나 화면을 변경하고 새 기능을 추가한다. 즉, 마이그레이션 대상인 델파이 7 소스 코드가 계속 변한다. 2단계 (실행 단계) 모든 코드를 변경하는 단계 개요 기간: 2일 (사전 준비가 완료되었으므로 가능) 참여 인원 외부: 1명 (아쿠아소프트 개발자) 내부: 1명 (개발자) 목표 코드 "전체"를 자동 변환 도구를 사용하여 델파이 7에서 델파이 10으로 변경 작업 내용 진행 전 실행 단계 직전에 기존 프로그램 변경을 금지 1일차 자동 변환 도구를 사용하여 변환 개발자 2명이 6시간 만에 완료 총 4,678개 소스 파일을 변경 2일차 컴포넌트 적합성, 데이터베이스 적합성이 파악된다. 모든 변경이 계획대로 되었는 지를 검증 3단계 (검증 단계) 개요 기간: 2.5 개월 참여 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 목표 모든 델파이 프로젝트와 모든 작동을 검증, 버그 파악 및 해소 팀 구성 개발자 (버그 픽스 전담) 그룹 개발자 (일반) 그룹 QA 그룹 델파이 프로젝트 별 책임자 그룹 작업 내용 검증 단계 시작 전 (즉, 실행 단계인 2일 간) 델파이 10 사용자 교육 이유: 모든 개발자는 이 검증 단계 시작을 기준으로, 그 이후에는 델파이 10만 사용 (그 이전에는 델파이 7만 사용) 내용: 델파이 10 사용법, 새 기능, 검증 단계 및 이후 유지 보수 시 작업 절차 결과: 개발자 등 모든 참여 인원이 검증 단계에 참여할 준비를 완료 검증 단계 시작 직후 버그가 매우 많이 보고되었고, 버그의 대부분을 신속하게 해소했다. 자동 변환 도구를 이용했기 때문이다. 버그 발생: 변환 도구에 버그가 있으면, 변환된 시스템에도 버그가 생긴다. 버그 해소: 변환 도구의 버그를 수정하면, 변환된 시스템의 해당 버그도 해소된다. 앞 단계에서 접근할 수 없었던 것들에서 발생되는 버그를 QA들이 찾아냈는데, 이런 검증은 도움이 되었다. 검증 결과 모든 기능 중 97% 검증 완료 나머지 3%는 외부 API라서 내부 테스트 불가 이유: 실제 운영 환경에서 테스트할 수 밖에 없는 외부 데이터) 대책: 외부 API 목록 작성과 운영 환경에서 완벽한 테스트를 할 수 있도록 미리 준비 (매우 중요) 이 단계에서는 버그 해소 작업에 큰 수고가 들지 않았다. 버그 등록이 지속적으로 줄어듬 종료 시점에 모두 해소 4단계 (배포 단계) RC (Release Candidate, 출시 후보) 버전 배포, 합격 판정 후 전체 배포 개요 기간: 5주 참여인원 내부: 2명 (QA 1명, 개발자 1명) 고객: 선정된 고객사 104곳 (사용 점포 브라질 18개 주에 있는 소매점에 총 184개 배포) 브라질 소매점 특성 상, "모든 지역"에서 문제가 없는 지 검증해야 함 (브라질은 각 주마다 세금과 규제가 다름) 작업 내용 4-1 단계: RC(Release Candidate, 출시 후보) 버전 배포 준비 RC (Release Candidate, 출시 후보) 버전 합격 기준 설정 중요도 0 (우회 해소 방법이 없는) 버그: 최대 5개 이내 중요도 1 (우회 해소 방법이 1가지인) 버그: 최대 20개 이내 위 기준 중 하나라도 통과하지 못하면 이 RC 버전은 불합격으로 판정하고 즉시 배포를 중단하기로 함 RC 버전 최대한 완벽한 버전을 준비 RC 버전을 배포 고객 "모든" 기능이 검증될 수 있도록 "세심하게" 고객을 선정 (고객마다 사용하는 기능, 방식, 환경이 제각각일 수 있다) 4-2 단계: RC 버전 배포 및 판정 배포 후 보고된 버그의 갯수 (모두 14개, 그림 참조: 버그 발견 및 해소 추이) 중요도 0: 1개 (기준치인 5개 이내, 통과) 중요도 1: 4개 (기준치인 20개 이내, 통과) 중요도 2: 7개 중요도 3: 2개 기준에 의거 성공 판정 4-3 단계: 전체 배포 100% 델파이 10으로 전환 완료 해소해야 할 마이그레이션 관련 버그가 없음 처음 계획한 데이터베이스를 지원 확인 현재, 99% 고객이 업데이트된 시스템을 사용 프로젝트를 통해 배운 점 분석 단계 (자동 변환 도구 개발 포함)에서 QA는 한두명만 참여하면 된다. 이 단계에서 QA가 많고, 버그를 많이 찾아낸다고 해서 무조건 좋은 것은 아니다. QA는 자동 변환 도구의 결과를 테스트 주의! 이 단계에 QA를 많이 투입할 것인지 아닌 지에 대한 결정은 프로젝트에 따라 다를 수 있으므로 매우 조심해야 한다. 써드-파티 컴포넌트는 분석이 매우 잘 되어야 한다. 심지어 프로젝트 전부터 미리 충분히 파악해야 한다. 마이그레이션 프로젝트가 시작되면 써드-파티 컴포넌트에 대한 작업과 부담이 많기 때문이다. 마이그레이션을 자동화하는 "맞춤" 변환 도구를 개발한다. 프로젝트가 많고 규모가 커도 처리할 수 있다. 검증 단계는 매우 중요하다. 충분한 테스트 시간이 필요하다. 검증 단계를 거치지 않고 바로 배포로 넘어가면 운영 시 문제가 많을 수 있다. 그러면 경영진은 이 프로젝트가 실패했다고 판정할 수 있다. 그러면, 검증 단계 하나의 실패로 끝나지 않는다. (우리는 검증 단계에 충분한 시간을 계획하였기 때문에 문제가 없었다) 프로젝트 중 소통이 매우 중요하다. 모든 팀원들이 진행 중인 작업을 항상 업데이트할 수 있는 절차와 환경이 구축되어야 한다. 그래야, 서로 다른 사람의 작업에 어떤 영향을 주거나 받는 지를 미리 파악할 수 있다. 프로젝트 평가 기준을 구체적이고 명확히 정하고 모니터링해야 한다. 계속 앞으로 갈 것인지 아니면 중단해야 하는 지에 대한 기준을 정하는 것은 매우 중요하다. 마이그레이션 목적이 분명해야 한다. 프로젝트 진행 중에 목적이 변경되면, 3-4개월 이상 지체될 수 있다. 목적과 목표가 분명해야 계획된 일정을 준수할 수 있다. 델파이 7은 매우 훌륭한 도구이지만, 거기에 머물고 있을 수 만은 없다. 머물러 있고 싶어도, 우리가 앞으로 가야할 시간은 언젠가 오게되어 있다. 20년 전에 출시된 델파이 7로는 지금 시점에서 필요한 기술 모두를 지원하지 못한다. 시스템 운영에 크리티컬할 기술에서도 그렇다. 구버전에서 벗어나서 최신 기술에 맞춰가자. 참고 자료 What's New in Delphi 10 Seattle https://www.embarcadero.com/products/delphi/whats-new Embarcadero Update Center https://www.embarcadero.com/rad-in-action/migration-upgrade-center Desktop Windows Version Market Share Worldwide http://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#monthly-201509-202110 Delphi Unicode: https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf 그림 자료 마이그레이션 전과 후의 UI 비교: 로그인 화면 새 UI에서 사용자 테마 선택 지원: 설정 화면 새 UI에서 사용자 테마 선택 지원: 다크 테마 적용 시 화면 마이그레이션 전과 후의 UI 비교: 일반 화면 새 UI에서 대시보드 구현 새 UI에서 실시간 그래프 구현1 새 UI에서 실시간 그래프 구현2 "맞춤" 자동 변환 도구 예시: 써드 파티 컴포넌트의 경우 프로퍼티 변환이 필요함 3단계 (검증 단계)의 버그 발견 및 해소 추이 << DelphiCon 2021 목록으로 이동
  2. << DelphiCon 2021 목록으로 이동 원본 비디오(YouTube) 보기 (30 min) DelphiCon 의 2021 시리즈 중, Leaving Delphi 7 - A Success Migration Case - Dion Carlos Mai & Rafael Pereira (30 min) 의 한글 요약본입니다. 20년이 넘었고, 델파이 7로 운영하던 대형 시스템을 델파이 10으로 마이그레이션한 프로젝트를 정리한 내용을 공유합니다. 발표자 Rafael은 이 소매점 시스템 제공자인 Stone Co의 개발자입니다. 목차 회사 및 프로젝트 소개 현대화 마이그레이션을 계획하게 된 동기와 결과 마이그레이션 프로젝트의 개요 마이그레이션 프로젝트의 진행 단계 1단계 (분석 단계) 2단계 (실행 단계) 3단계 (검증 단계) 4단계 (배포 단계) 프로젝트를 통해 배운 점 참고 자료 그림 자료 회사 및 프로젝트 소개 회사 소개: Stone Co Linx: 뉴욕 증시에 상장된 브라질의 소프트웨어 기업. 브라질의 소매점 소프트웨어 시장에서 점유율 45.6% Stone: 뉴욕 증시에 상장된 브라질의 Stone Co.의 핀테크 기업. 지불 관리 도구와 유연한 금융 상품을 제공 Stone Co: 2012년에 시작하여 브라질 전역을 커버하고 있다. 2020년 11월, Stone Co는 Linx를 인수 대상 시스템 소개: Linx Big 20년이 넘은 소매점 소프트웨어. 약국에서 주로 사용 현재 3,000개가 넘는 고객사와, 5,000개가 넘는 소매점에서 사용 중 (2개 이상을 사용하는 점포가 많으므로, 배포된 소프트웨어는 훨씬 더 많음) 현대화 마이그레이션을 계획하게 된 동기와 결과 윈도우10은 2021년 10월 현재 전세계 데스크탑 점유율의 80%이상을 차지하고 있고 계속 증가하는 추세임 (관련 통계 보기) 윈도우 10에 집중해야 하는 상황 윈도우 10의 새 운영체제 기능을 충분히 지원하는 IDE 기능이 필요 윈도우 10에 맞는 더 좋은 시각적인 UI가 필요 (그림 참조: 예전 화면과 새 화면 비교) 스타일, 대시보드, 그래프, 메뉴 등 더 풍부한 화면을 제공하여 외관상 완전히 다른 새 소프트웨어로 보임 (그림 참조: 새 화면) 델파이 10에 내장된 컴포넌트와 스타일만 사용하여 화면 개발 새 UI를 구현하기 위한 코드는 새로 작성 하지만, 모든 클래스와 소스 코드는 예전 델파이 7과 거의 같음 스레드가 필요 요즘 소프트웨어는 API 통합이 많다. 델파이 7에서도 스레드를 구현할 수 있다. 하지만, 델파이 7은 소프트웨어를 개발하기에 여전히 매우 훌륭한 도구이지만, 20년 전에 나온 오래된 버전이다. 델파이 최신 버전을 사용하지 않으면, API 통합을 모두 지원하거나 JSON 직렬화하기 등 새 기술을 반영하기가 어렵다. 기타 개선 델파이 10의 장점을 가질 수 있게 됨: 64비트 지원, 윈도우 10 지원, FireDAC으로 데이터 연결, 다른 운영체제에서 접근 등등 델파이 10 시애틀을 선택한 이유 당시 우리 개발자 대부분이 사용할 수 있는 라이선스를 이미 가지고 있었기 때문 마이그레이션 프로젝트의 개요 목표 델파이 7에서 델파이 10 시애틀로 이전 마리아DB 10.4.13과 MySQL 8.0.21 지원 개요 기간: 총 7 개월 투입 인원 외부: 3명 (아쿠아소프트 개발자, 마이그레이션에만 집중) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 마이그레이션 대상 (소매점 관리 시스템)의 규모 델파이 프로젝트: 65개 모듈: 194개 .PAS 파일: 6,000개 .DFM 파일: 2,000개 코드 줄 수: 2백만줄 써드 파티 컴포넌트 세트: 23가지 마이그레이션 프로젝트의 진행 단계 총 4단계로 나누고, 앞 단계 완료 시 다음 단계를 진행: 분석, 실행, 검증, 배포 1단계 (분석 단계) 개요 기간: 3.5개월 투입 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 2명 (개발자 1명, QA 1명) 목표 측정 / 식별 / 문서화 델파이 10으로 마이그레이션이 끼칠 영향 새 데이터베이스와의 호환성 프로젝트로 인해 달라지는 점과 문제점 변경으로 인해 발생될 것으로 예상되는 문제 해소 자동 변환 도구 개발 작업 내용 외부 인력 (아쿠아소프트) 합류 전환할 컴포넌트를 3가지로 나누어 분석하고 대비 버전의 수명이 다한 컴포넌트 마이그레이션 시 문제가 많고, 작업도 많이 해야 하는 것들임 이 프로젝트에서 많이 사용될 컴포넌트 프로젝트에서 사용되는 비중이 크기 때문에, 그 만큼 프로젝트에 끼치는 영향도 큰 것들임 소스코드가 없는 컴포넌트 매우 이상하게 작동할 수 있고 마이그레이션 작업을 까다롭게 만들기 때문에 주의해야 할 것들임 예: Zeos (2003년부터 사용한 오픈 소스 데이터베이스 컴포넌트) [에러가 발생되는 코드] QPrincipal.FieldByName('datapre').AsDateTime :=now; 짐작하겠지만, 상업용 시스템에서 매우 많이 사용되는 코드이며, 모두 수정해야 하므로, 에러 해소 작업이 많다. 델파이 버전 간의 차이와 충돌을 식별하고 해소 유니코드 (영향 받는 dll이 있는 지까지도 파악할 필요가 있음) 자동 변환 도구 개발 ("마이그레이션 찾아 바꾸기"라고 이름 지음) 소스 변환 자동화 도구 개발을 이 분석 단계 안에서 완성 (그림 참조: 소스 변환 자동화 도구와 변환 결과) Zeos에서 UniDAC으로 마이그레이션하는 도구 마법사가 발생시키는 버그 수정 자동화 사용되는 모든 컴포넌트 마이그레이션 자동화 (많은 컴포넌트에서 일부 프로퍼티가 변경되었기 때문) 델파이 10과 델파이 7과의 차이로 인해 필요한 코드 변환 자동화 "모든" 소스를 변환할 수 있는 "맞춤" 도구 완성 소스 코드 동기화 소스 코드 동기화는 매우 중요! 마이그레이션 프로젝트 진행 중에도 전체 배포까지 완료되기 전까지는 전환해야 할 코드가 계속 변하기 때문이다. 분석 단계가 진행되는 중에도 내부 개발자 20명은 여전히 기존 코드나 화면을 변경하고 새 기능을 추가한다. 즉, 마이그레이션 대상인 델파이 7 소스 코드가 계속 변한다. 2단계 (실행 단계) 모든 코드를 변경하는 단계 개요 기간: 2일 (사전 준비가 완료되었으므로 가능) 참여 인원 외부: 1명 (아쿠아소프트 개발자) 내부: 1명 (개발자) 목표 코드 "전체"를 자동 변환 도구를 사용하여 델파이 7에서 델파이 10으로 변경 작업 내용 진행 전 실행 단계 직전에 기존 프로그램 변경을 금지 1일차 자동 변환 도구를 사용하여 변환 개발자 2명이 6시간 만에 완료 총 4,678개 소스 파일을 변경 2일차 컴포넌트 적합성, 데이터베이스 적합성이 파악된다. 모든 변경이 계획대로 되었는 지를 검증 3단계 (검증 단계) 개요 기간: 2.5 개월 참여 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 목표 모든 델파이 프로젝트와 모든 작동을 검증, 버그 파악 및 해소 팀 구성 개발자 (버그 픽스 전담) 그룹 개발자 (일반) 그룹 QA 그룹 델파이 프로젝트 별 책임자 그룹 작업 내용 검증 단계 시작 전 (즉, 실행 단계인 2일 간) 델파이 10 사용자 교육 이유: 모든 개발자는 이 검증 단계 시작을 기준으로, 그 이후에는 델파이 10만 사용 (그 이전에는 델파이 7만 사용) 내용: 델파이 10 사용법, 새 기능, 검증 단계 및 이후 유지 보수 시 작업 절차 결과: 개발자 등 모든 참여 인원이 검증 단계에 참여할 준비를 완료 검증 단계 시작 직후 버그가 매우 많이 보고되었고, 버그의 대부분을 신속하게 해소했다. 자동 변환 도구를 이용했기 때문이다. 버그 발생: 변환 도구에 버그가 있으면, 변환된 시스템에도 버그가 생긴다. 버그 해소: 변환 도구의 버그를 수정하면, 변환된 시스템의 해당 버그도 해소된다. 앞 단계에서 접근할 수 없었던 것들에서 발생되는 버그를 QA들이 찾아냈는데, 이런 검증은 도움이 되었다. 검증 결과 모든 기능 중 97% 검증 완료 나머지 3%는 외부 API라서 내부 테스트 불가 이유: 실제 운영 환경에서 테스트할 수 밖에 없는 외부 데이터) 대책: 외부 API 목록 작성과 운영 환경에서 완벽한 테스트를 할 수 있도록 미리 준비 (매우 중요) 이 단계에서는 버그 해소 작업에 큰 수고가 들지 않았다. 버그 등록이 지속적으로 줄어듬 종료 시점에 모두 해소 4단계 (배포 단계) RC (Release Candidate, 출시 후보) 버전 배포, 합격 판정 후 전체 배포 개요 기간: 5주 참여인원 내부: 2명 (QA 1명, 개발자 1명) 고객: 선정된 고객사 104곳 (사용 점포 브라질 18개 주에 있는 소매점에 총 184개 배포) 브라질 소매점 특성 상, "모든 지역"에서 문제가 없는 지 검증해야 함 (브라질은 각 주마다 세금과 규제가 다름) 작업 내용 4-1 단계: RC(Release Candidate, 출시 후보) 버전 배포 준비 RC (Release Candidate, 출시 후보) 버전 합격 기준 설정 중요도 0 (우회 해소 방법이 없는) 버그: 최대 5개 이내 중요도 1 (우회 해소 방법이 1가지인) 버그: 최대 20개 이내 위 기준 중 하나라도 통과하지 못하면 이 RC 버전은 불합격으로 판정하고 즉시 배포를 중단하기로 함 RC 버전 최대한 완벽한 버전을 준비 RC 버전을 배포 고객 "모든" 기능이 검증될 수 있도록 "세심하게" 고객을 선정 (고객마다 사용하는 기능, 방식, 환경이 제각각일 수 있다) 4-2 단계: RC 버전 배포 및 판정 배포 후 보고된 버그의 갯수 (모두 14개, 그림 참조: 버그 발견 및 해소 추이) 중요도 0: 1개 (기준치인 5개 이내, 통과) 중요도 1: 4개 (기준치인 20개 이내, 통과) 중요도 2: 7개 중요도 3: 2개 기준에 의거 성공 판정 4-3 단계: 전체 배포 100% 델파이 10으로 전환 완료 해소해야 할 마이그레이션 관련 버그가 없음 처음 계획한 데이터베이스를 지원 확인 현재, 99% 고객이 업데이트된 시스템을 사용 프로젝트를 통해 배운 점 분석 단계 (자동 변환 도구 개발 포함)에서 QA는 한두명만 참여하면 된다. 이 단계에서 QA가 많고, 버그를 많이 찾아낸다고 해서 무조건 좋은 것은 아니다. QA는 자동 변환 도구의 결과를 테스트 주의! 이 단계에 QA를 많이 투입할 것인지 아닌 지에 대한 결정은 프로젝트에 따라 다를 수 있으므로 매우 조심해야 한다. 써드-파티 컴포넌트는 분석이 매우 잘 되어야 한다. 심지어 프로젝트 전부터 미리 충분히 파악해야 한다. 마이그레이션 프로젝트가 시작되면 써드-파티 컴포넌트에 대한 작업과 부담이 많기 때문이다. 마이그레이션을 자동화하는 "맞춤" 변환 도구를 개발한다. 프로젝트가 많고 규모가 커도 처리할 수 있다. 검증 단계는 매우 중요하다. 충분한 테스트 시간이 필요하다. 검증 단계를 거치지 않고 바로 배포로 넘어가면 운영 시 문제가 많을 수 있다. 그러면 경영진은 이 프로젝트가 실패했다고 판정할 수 있다. 그러면, 검증 단계 하나의 실패로 끝나지 않는다. (우리는 검증 단계에 충분한 시간을 계획하였기 때문에 문제가 없었다) 프로젝트 중 소통이 매우 중요하다. 모든 팀원들이 진행 중인 작업을 항상 업데이트할 수 있는 절차와 환경이 구축되어야 한다. 그래야, 서로 다른 사람의 작업에 어떤 영향을 주거나 받는 지를 미리 파악할 수 있다. 프로젝트 평가 기준을 구체적이고 명확히 정하고 모니터링해야 한다. 계속 앞으로 갈 것인지 아니면 중단해야 하는 지에 대한 기준을 정하는 것은 매우 중요하다. 마이그레이션 목적이 분명해야 한다. 프로젝트 진행 중에 목적이 변경되면, 3-4개월 이상 지체될 수 있다. 목적과 목표가 분명해야 계획된 일정을 준수할 수 있다. 델파이 7은 매우 훌륭한 도구이지만, 거기에 머물고 있을 수 만은 없다. 머물러 있고 싶어도, 우리가 앞으로 가야할 시간은 언젠가 오게되어 있다. 20년 전에 출시된 델파이 7로는 지금 시점에서 필요한 기술 모두를 지원하지 못한다. 시스템 운영에 크리티컬할 기술에서도 그렇다. 구버전에서 벗어나서 최신 기술에 맞춰가자. 참고 자료 What's New in Delphi 10 Seattle https://www.embarcadero.com/products/delphi/whats-new Embarcadero Update Center https://www.embarcadero.com/rad-in-action/migration-upgrade-center Desktop Windows Version Market Share Worldwide http://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#monthly-201509-202110 Delphi Unicode: https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf 그림 자료 마이그레이션 전과 후의 UI 비교: 로그인 화면 새 UI에서 사용자 테마 선택 지원: 설정 화면 새 UI에서 사용자 테마 선택 지원: 다크 테마 적용 시 화면 마이그레이션 전과 후의 UI 비교: 일반 화면 새 UI에서 대시보드 구현 새 UI에서 실시간 그래프 구현1 새 UI에서 실시간 그래프 구현2 "맞춤" 자동 변환 도구 예시: 써드 파티 컴포넌트의 경우 프로퍼티 변환이 필요함 3단계 (검증 단계)의 버그 발견 및 해소 추이 << DelphiCon 2021 목록으로 이동 View full 엠바카데로 기술자료
  3. Emad Bin Abid 가 작성한 Everything You Need To Modernize With RAD Server (영문 원본 보기) 를 번역했습니다. 현대 사회에서 우리는 기술에 둘러싸여서 파묻혀있고 그 기술의 형태도 다양하다. 전적으로 클라우드 기반인 기술이 대부분이긴 하지만 여전히 상당 부분은 클라우드와 물리적인 하드웨어 컴퓨팅 장비가 함께 섞여 있기도 하다. 하지만 아무리 최신 기술이라도 결국은 더 최신 기술에 의해 밀려나고 시대에 뒤쳐지게 되는 때가 반드시 온다는 사실 하나는 분명하다. 모든 기술이 각자 급격하게 발전하지만, 결국 이런 발전된 기술이 제공하는 더 발전된 단계에 의해서 또는 문제를 해결하거나 서비스를 제공하는 방식 자체가 더 새롭고 강력한 그 무언가에 의해 교체되고 만다. 기술과 애플리케이션이 뒤안길로 사라지지 않도록 지키려면, 끊임없이 기능을 업드레이드하고 다가올 트렌드와 사용 방식을 예측하여 반영해야 한다. 단순 명쾌하다.그리고, 이 과정에서 어떤 작업은 매우 고될 수도 있다. 애플리케이션이 복잡하고 코드 기반이 너무 광범위한 경우에는 특히 그렇다. 또한 애플리케이션에서 사용된 많은 라이브러리와 프레임워크들 중에는 단종되거나, 쓸모없어지거나 업데이트가 필요한 것들도 있다. 애플리케이션을 업그레이드하고 현대화하는 어려움을 극복하려면, RAD 서버와 같이 그 과정을 세련되게 진행할 수 있는 강력한 수단을 제공하는 견고한 개발 솔루션이 필요하다. 우리는 이런 수단을 통해서 변경을 어떻게 해낼 것인 지에 대한 감을 잡을 수 있다. 그리고 이런 수단들 자체가 직접 현대화 작업 자체를 가이드하는 역할을 하기도 한다. 이 글은 RAD 서버를 사용하여 현대화 하는 것이 어떤 것인지 왜 애플리케이션에서 필수 요소이고 최우선으로 고려해야 하는 지를 들여다 본다. 애플리케이션을 현대화 해야하는 이유는? 불과 5년 전과 비교해도, 소프트웨어 개발 분야는 상당히 달라졌다. 운영체제의 추상화와 지원 능력이 발전함에 따라 애플리케이션은 하드웨어 장비의 리소스를 훨씬 더 효율적으로 사용한다. 컴포넌트 생태계가 풍부해 지고, 개발 도구 업계가 더 성숙해졌고, 프로그래밍 언어의 범위도 넓어짐에 따라 애플리케이션이 복잡한 처리를 이전보다 더 잘 수행할 수 있도록 하는 코드를 구현하는 과정 역시 더 최적화되었다. 이런 환경에서 우리의 애플리케이션이 살아남기 위해서는, 현대화를 해야 하고, 이전보다 더 많은 서비스를 제공해야 한다. 웹 애플리케이션 개발을 살펴보면, 웹 브라우저와 그 렌더링 능력이 발전함에 따라 웹 애플리케이션은 훨씬 더 동적이고 견고해졌다. 웹 애플리케이션을 개발 속도 역시 엄청나게 빨라졌다. 또한 화면 렌더링 측면에서는 반응형 UI 기술이, 그리고 장비의 센서 활용 면에서는 여러 하드웨어 센서와 기능의 최소한의 공통 분모를 다룰 수 있는 속성과 메소드를 제공하는 API와 같은 기술이 나온 덕분에, 제대로 만든 웹 애플리케이션이라면 모든 장비에서 사용할 수 있다. 모듈화는 마이크로서비스를 통해 실현되었고, 서버리스(Serverless)를 통해 운영 경제성까지 갖추었다. 보안성과 확장성 역시 애플리케이션 개발과 관련하여 매우 중요한 요소가 되었다. 사이버 공격이 증가함에 따라, 애플리케이션은 모든 면에서 보안성이 확보해야 하고, 관련된 베스트 프랙티스 (가장 좋다고 검증된 조치법)를 반영해야 한다. 또한 애플리케이션의 확장성을 확보하여 많은 사용자를 품을 수 있고 필요할 때 바로 사용될 수 있어야 한다. 이런 것들이 없이는 경쟁에서 밀리고 결국 잊혀지게 될 수도 있다. RAD 서버는 무엇인가? 어디에 사용되는가? RAD 서버는 현재 백-엔드 개발 애플리케이션 분야에서 앞서가는 솔루션 중 하나로서, 애플리케이션 서비스를 구축하고 배포할 수 있도록 하는 플랫폼이다. 여러 뛰어난 장점들을 갖추고 있으며 특히 백-엔드를 구축하려고 마음 먹으면 RAD 서버를 사용하여 바로 시작할 수 있다. API를 개발하고 애플리케이션을 서비스 하는데 필요한 기능 대부분이 이미 준비되어 있기 때문에 백-엔드 서버 전체를 맨 처음부터 시작하지 않아도 된다. 필요한 외부의 서버와 서비스는 RAD 서버를 통해 손쉽게 연결할 수 있다. MySQL, 오라클, SQL 서버, 인터베이스(Interbase) 등 거의 모든 엔터프라이즈 데이터베이스 기술에 연결할 수 있다. RAD 서버에는 사용자 관리 서비스, 디렉토리 서비스 등의 중요한 백-엔드 기능이 이미 들어 있다. 특히 정기적으로 솔루션을 개발하고 재배포하는 소프트웨어 제조사에게는 가장 도움이 되는 도구가 될 것이다. RAD 서버를 사용하면 REST API와 해당 엔드포인트를 작성, 공개, 관리를 빠르게 할 수 있다. 더 나아가 API 분석 기능, 성능과 이슈 모니터링 등의 기능이 내장되어 있어서 바로 사용하면 된다. 또한 사용자 관리, 그룹관리, 접근 제어를 할 수 있는 관리 포털도 제공된다 RAD 서버를 사용하여 애플리케이션을 현대화하는 방법은? RAD 서버에 내장되어서 바로 쓸 수 있는 백-엔드 개발과 플랫폼 모니터링 기능은 제쳐두고, 기존의 델파이와 C++빌더로 만든 기존의 클라이언트/서버에 있는 비즈니스 로직을 RAD 서버를 통해 어떻게 현대화 할 수 있는 지를 살펴보자. RAD 서버를 사용하면 기존의 애플리케이션 로직을 보안성과 확장성이 높은 서비스 기반 아키텍처로 손쉽게 마이그레이션 할 수 있다. 서비스 기반 아키텍처는 애플리케이션이 원활하게 작동할 수 있도록 하기 위해 서비스가 필요한 애플리케이션 구성 요소에게 해당 서비스를 제공하는 것에 촛점을 맞춘다. 애플리케이션이 일단 RAD 서버로 옮겨서 현대화되고 나면, 많은 이점을 누릴 수 있으며 이전보다 훨씬 많은 것을 제공할 수 있다. 전용 관리 콘솔, 배포 간편, 내장된 통계 콘솔 역시 RAD 서버의 장점이다. 또한 마이그레이션된 기존의 비즈니스 로직을 서비스하는 엔드포인트를 생성하고 관리할 수 있다. RAD 서버를 사용하여 현대화를 하면 다음과 같은 장점들 역시 갖출 수 있다. 클라우드 서비스 연결 능력: 거의 모든 기술 분야에서 클라우드 컴퓨팅과 여기에 연결하는 능력이 생존을 결정하게 될 미래가 빠르게 다가오고 있다. RAD 서버를 사용하면 구글, 아마존, 등등 대표적인 클라우드 플랫폼에서 제공하는 REST 클라우드 서비스를 수용할 수 있다. 도커(Docker)를 견고하게 지원: 컨테이너 기술은 최근의 소프트웨어 개발 산업에서 가장 큰 혁신이다. 그 중에서도 도커(Docker)는 거의 모든 곳에서 사용되는 지배적인 컨테이너 서비스이다. RAD 서버를 사용하면 도커 이미지를 만들고 도커 허브 (Docker Hub)에 올려둘 수 있어서 구글 클라우드, 마이크로소프트 애저, AWS로 간단하게 배포할 수 있다. 사물인터넷 장비 연결 능력: 사물인터넷은 강력한 네트워크 그리고 속도가 빠른 데이터 전송 환경을 바탕으로 하는 멋진 기술이다. 사물인터넷을 지원하는 장비는 필요한 애플리케이션과 바로 연결되어 작동할 수 있다. RAD 서버를 사용하면, 사물인터넷 장비를 여러분의 애플리케이션 서비스에 손쉽게 연결할 수 있다. 위 기능들은 오늘날의 디지털 시대의 첨단 기술이다. RAD 서버로 마이그레이션을 하면, 이제 여러분도 이런 첨단 기능을 갖출 수 있으며 서비스 기반 접근을 반영할 수 있다. RAD 서버의 능력을 살펴볼 수 있는 사례는? 초창기의 RAD 서버는 가장 먼저나온 백-엔드 개발 플랫폼은 아니지만, 그 서비스와 기능을 통해서 백-엔드의 기준을 세웠다. 많은 기업과 개발자들이 비즈니스 로직 처리를 담당하는 백-엔드 서비스를 제공하는 견고한 애플리케이션을 만들기 위해 RAD 서버를 사용해오고 있다. RAD 서버를 활용하는 아래의 프로젝트를 보면, 여러분이 바랬던 어플리케이션이 어떤 모습일지에 대해좋은 아이디어를 얻을 수 있을 것이다. 아래 내용은 RAD 스튜디오에 들어있는 예제들이다. RAD 서버가 애플리케이션에 어떻게 생명을 주는 지를 볼 수 있다. RAD 서버 멀티-테넌시 예제: 일반적인 소매점을 위한 예제이다. 여기에는 EMS(enterprise management system)을 활용하며, 파이어닥(FireDAC) 컴포넌트를 사용하여 데이터베이스에 연결한다. 또한 RAD 서버 콘솔을 통해 엔드포인트의 갯수와 사용 빈도 등의 통계를 보는 기능도 볼 수 있다. RAD 서버 파이어닥(FireDAC) 리소스 예제: 파이어닥(FireDAC)은 델파이에서 데이터를 연결할 때 사용하는 컴포넌트 세트로써 엔터프라이즈 데이터베이스 연결 속도가 빠르다. 이 예제는 EMS서버와 여기에 연결하는 클라이언트를 만드는 프로젝트이며, 파이어닥(FireDAC)을 사용하여 SQLite 데이터베이스에 연결한다. RAD 서버 콘솔은 별도로 하고, 이 예제의 EMS 서버는 RAD 서버 엔진을 기반으로 작동한다. 따라서, 해당 서버 호스트를 클라우드에 둘 수도 있고, 온프레미스에 둘 수도 있다. 위 예제와 별개로, 이와 비슷하게 RAD 서버를 충분히 활용하는 사례 템플릿들도 있고 원하면 가져다 쓸 수도 있다. 예를 들어, RAD 서버 간호사실(RAD Server Nurses Station) 템플릿은 병원/의원에서 환자 데이터를 자동으로 수집하는 기능이 구현되어 있다. 이 템플릿에는 사용자 관리, 데이터 수집과 배포, 알림 서비스 등 RAD 서버가 이미 내장하고 있는 기본 기능들도 사용하고 있다. 또한 다른 시스템이 연결할 때 REST HIPPA(미국의 개인의료 정보 보호 규정) 연결을 활성화하는 기능도 있다. 당신의 델파이 애플리케이션을 현대화하고 마이그레이션 할 준비가 되었다면, RAD 서버를 살펴보자. 어떻게 활용하면 원하는 목적을 이룰 수 있는 지를 알 수 있다.
  4. Anbarasan의 Quickly Migrate and Modernize Your Delphi/C++ Apps Using FastReport With Windows High DPI Setup 을 번역했습니다. (원문 작성 시기: 2020년 11월) 디스플레이 패널의 물리적 공간 당 픽셀 수는 점점 더 많아지고 있어서 DPI (인치 당 도트수)가 높은 모니터가 많아졌다. 예전에는 디스플레이 대부분이 96 DPI 즉, 1 인치 당 96 픽셀이 들어있었지만, 2017년에는 거의 300 DPI가 넘는 것들도 생겨났다. 이제 시중에는 SD, Full HD, 4K 울트라 HD, 8K 울트라 HD 등 다양한 모니터가있다. 우리가 사용하는 노트북이나 화면이 작은 데스크탑에서 화면 배율 팩터/DPI를 변경할 수 없으면 사용하기가 매우 어렵다. 더 나아가 Full HD, 4K 울트라 HD, 8K 울트라 HD 모니터에서는 훨씬 더 복잡하다. 우리의 애플리케이션들은 이 모든 것을 다룰 수 있어야 한다. 어떤 사용자가 어떤 사양의 모니터를 사용할 지 모르기 때문이다. 화면 배율 팩터/DPI가 변경되는 일반적인 상황 몇 가지를 살펴보자: 모니터 여러 대를 사용하는데, 각 모니터의 화면 배율이 서로 다르고, 애플리케이션이 한 모니터에서 다른 모니터로 옮겨지는 경우 (예. 모니터 1은 4K이고 모니터 2는 1080p 화면) DPI가 낮은 외부 모니터를 DPI가 높은 노트북에 연결 또는 연결 해제하는 경우 (또는 그 반대의 경우) DPI가 높은 노트북/태블릿에서 원격 데스트탑을 통해 DPI가 낮은 장비를 연결하는 경우 (또는 그 반대의 경우) 애플리케이션이 작동하고 있는 중에 윈도우의 화면 배율 팩터 설정을 변경하는 경우 데스크탑 애플리케이션은 자신이 DPI Scaling을 지원하는 지를 윈도우에게 알려야 한다. 이 정보가 전달되지 않으면 윈도우 시스템은 일단 해당 데스크탑 애플리케이션은 DPI를 인식하지 않는다고 간주하고, 화면에 맞게 비트맵을 확대/축소 한다. 애플리케이션은 자신의 DPI 인식 모드를 Unaware, System, Per-Monitor, Per-MonitorV2 중에서 하나로 설정함으로써 윈도우가 해당 애플리케이션을 화면에 표현할 때 DPI 확장을 어떻게 처리할 지 명확하게 알려주게 된다. 일반 애플리케이션을 Per-MonitorV2 인식으로 업데이트할 때에는, UI 레이아웃을 제어하는 코드 역시 업데이트 되도록 해야 한다. 이 처리는 애플리케이션이 초기화되는 시점 뿐만 아니라 DPI 변경 (Win32의 경우 WM-DPICHANGED 윈도우 메시지) 알림을 받을 때마다 반영되어야 한다. 델파이 애플리케이션을 High DPI로 마이그레이션 할 때 꼭 알아두어야 하는 점들은 무엇일까? DPI Awareness 모드를 설정한다: Project > Options > Application > Manifest-DPI Awareness 에서 Per-MonitorV2를 선택한다. Screen.PixelsPerInch 에 주 모니터의 DPI를 사용한다. TImagesList 대신 TVirtualImageList를 사용한다. 모든 사용자 정의 그리기 작업에서 절대 위치를 확인한다. Control.CurrentPPI를 사용하여 각 컨트롤들이 표현되는 현재 PPI값을 받아낸다. 대화상자 혼합 모드 (SetThreadDPIAwarenesscontext) 폼의 OnBeforMonitorDPIChanged / OnAfterMonitorDPIChanged 이벤트를 사용한다. 주의: 플랫폼과 애플리케이션을 개발한 델파이 버전 호환성을 확인해야 한다. 델파이와 패스트리포트(FastReport)의 High DPI 컨트롤들: TControl: ScaleforPPI, ChangeScale, ScaleControlsForPPI와 같은 프로시저들은 High DPI 변경을 도와준다. TFrxBAseForm: UpdateResources, UpdateFormPPI, ProcessPreferences와 같은 프로시저와 WM_DPICHANGED 윈도우 메세지는 패스트리포트 폼의 DPI 변경을 도와준다. TFrxDPIAwareCustom: DoPPIChanged, GetScale과 같은 프로시저와 WM_DPICHANGED_AFTERPARENT 윈도우 메세지는 패스트리포트의 사용자 지정 컨트롤 DPI 변경을 도와준다. Fast Migration to Windows 10 High DPI 비디오에서 데모를 확인해보자!
  5. Muminjon의 5 Ultimate Ways To Modernize Your Apps For Windows 11 를 번역했습니다. 현대적이고 견고하고 엔터프라이즈급 UI를 구현할 수 있도록, 델파이는 윈도우 전용인 VCL (Visual Component Library)과 크로스-플랫폼 개발용인 파이어몽키 (FMX)를 제공한다. 델파이 VCL에는 윈도우 앱 개발에 필요한 최신 기능과 현대식 UI 컨트롤이 들어있다. 또한, 델파이로 만든 앱은 네이티브 성능을 발휘한다. 그리고 델파이를 사용하면 윈도우의 최신 기능과 하드웨어를 빠르게 반영할 수 있다. 이 글에서는 당신의 앱을 윈도우 11 용으로 현대화하는 핵심 방안 다섯가지를 정리해보았다. 1. 사용자를 포용하는 디자인(Inclusive Design)을 만들었는가? 사용자들은 앱이 어떤 정보를 수집하는 지 그리고 개인 정보 정책 안내가 잘 되어 있는 지를 쉽게 알을 수 있는 앱을 좋아한다. 따라서 사용자에게 이 모든 정보를 알려주고, 수집 정보를 제조사로 전송하는 기능을 직접 끄거나 켤 수 있도록 하는 것은 언제나 환영받는 요소이다. 종합적인 디자인 (Comprehensive Design)은 제품의 신뢰도를 더욱 높이고 누구에게나 알맞은 환경을 제공한다. 예를 들어, 앱의 내용이 수많은 글자로 되어있다면, 화면을 읽어주는 스크린 리더 기능을 추가하면 한결 좋아질 것이고 장애가 있는 사용자들도 만족할 것이다. UI 컨트롤과 메뉴에는 단순하고 아름다운 애니메이션 안내를 제공하자. 가능한 가장 좋은 배율 조정과 반응을 앱에 실현하자. 폰트 크기를 사용자가 직접 변경할 수 있도록 하자. 사용자마다 사용하는 화면의 크기가 제각각이다. 따라서 개발자는 앱이 어떻게 표현될 지를 모조리 알 수는 없다. 당신의 앱이 첫 화면에서 여러가지 정보를 제공하고, 이 정보가 여러 프레임으로 나누어져 있다면, 사용자가 직접 프레임을 재배치/재구성 할 수 있도록 하자. 그림. 델파이 11 IDE는 사용자가 레이아웃을 변경할 수 있도록 되어있다. 윈도우 11에서는 아이콘 대부분이 업데이트 되었다. 윈도우 11의 아이콘들은 반짝이고 질서정연하다. 게다가 UI 글꼴은 Segoe UI Variable 글꼴이 새로 도입되어서 당신의 앱이 사용하는 활자 역시 더 부드러워지고 가독성도 더 높아진다. 그림. 윈도우의 새 Segoe 폰트 (출처: 윈도우 문서) 2.현대식 UI 컨트롤을 사용하고 있는가? 그림. 델파이 VCL은 현대식 윈도우 UI 컨트롤들과 네이티브 성능을 제공한다. 아름답고 현대적인 UI 컨트롤들을 사용함으로써, 윈도우 11에서 당신의 앱은 더욱 멋지고 최첨단이라는 느낌을 준다. 윈도우 11 자체의 UI에 이미 수많은 혁신이 반영되었으므로, 당신의 앱 역시 윈도우 11의 UI와 잘 어우러질 필요가 있다! 게다가, 가벼우면서도 확대할 수 있는 애니메이션이 앱에 구현되어 있으면 사용자 경험(UX)을 향상시킬 수 있다. 애니메이션을 애플리케이션에 추가할 때 가장 널리 사용되는 방식 중 하나는 로티(Lottie) 애니메이션 파일을 사용하는 것이다. 그림. Skia4Delphi 그래픽 라이브러리를 사용하자. 로티(Lotti) 애니메이션 파일을 델파이 앱에 추가하는 방법을 알고 있는가? 쉽다! 델파이 커뮤니티가 개발 생태계에 기여하고 있기 때문이다. Skia4Delphi는 델파이에서 사용할 수 있는 크로스 플랫폼 2D 그래픽 API로써 구글의 스키아 그래픽 라이브러리(Skia Graphic Library)를 기반으로 한다. 델파이에서 SVG와 로티(Lotti)를 사용하는 방법은 Desktop First UX Summit에서 짐 맥키트가 진행한 세션에서 볼 수 있다. 3. 현대적인 시각 효과를 당신의 앱에서 사용하고 있는가? 윈도우 11은 다양한 UI 요소와 둥근 모서리를 데스크탑 운영 체제에 새로 도입했다. 일반적으로 사용되던 각진 모서리는 이제 둥글고 부드러운 모서리로 바뀌어서 데스크탑 앱에서 전과는 다른 느낌이 난다. 윈도우 11을 활용하다 보면, 모서리가 둥근 UI 컨트롤들이 다크 모드와 라이트 모드 양쪽에서 모두 멋지게 표현되는 것을 알 수 있다. 윈도우 11 둥근 모서리를 코드를 사용해 다루는 방법은 다음 글을 통해서 배울 수 있다. 윈도우 11 둥근 모서리를 내 앱에 적용하기 델파이 VCL에는 당신의 앱이 현대적인 모습을 갖출 수 있도록 하는 VCL Styles 라는 탁월한 옵션이 있다. 수십 가지 독특한 스타일이 제공되기 때문에, 원하는 스타일들을 당신의 윈도우 앱에 적용하기만 하면 현대적인 UI를 몇 초만에 완성할 수 있다. 플루언트(Fluent) 앱을 델파이로 디자인하려면 어떻게 할까? - 아크릴 재질 (Acrylic material) 디자인 하기 플루언트 디자인 시스템을 당신의 앱에 적용하고 싶다면, StyleControls VCL 패키지를 사용하면 된다. StyleControls VCL 패키지는 클래식 드로잉(classic drawing), 시스템 테마, GDI+, VCL 스타일을 사용하여 독특한 사용자 인터페이스를 만든다. 그림. StyleControls VCL 패키지는 마이크로소프트 플루언트 UI 디자인이 반영된 컨트롤을 제공한다. 4. 당신의 앱은 현대식 하드웨어와 기능 모드를 사용하고 있는가? 최근 몇년간, 터치스크린 용으로 디자인된 앱들도 많이 나왔다. 예를 들어, 투인원(2-in-1) 노트북을 사용하면, 앱의 UI 컨트롤이 더 크고, 더 정확한 위치에 있어야 사용하기 좋다. 게다가, 알림이나 공유 등의 훌륭한 베스트 프랙티스를 활용하지 않고 있는 애플리케이션들도 아직 꽤 많은데, 당신의 앱에서 이런 기능을 사용할 수 있으면, 당신의 앱은 보다 효율적으로 작동될 것이고 개발자는 그저 해당 API를 사용하기만 하면 된다. 만약, 델파이 VCL이나 FMX를 사용하고 있다면 마우스로 필요한 시스템 컴포넌트를 끌어다 놓기만 하면 된다! 윈도우 10 알림 기능 구현 샘플을 살펴보자. 또한, 윈도우 스토어(Windows Store)로 앱을 배포하려면 MSIX (오른쪽 그림. 출처: 마이크로소프트) 기능을 활용해야 한다. 윈도우 스토어는 당신의 윈도우 앱 전체를 아무런 변경도 하지 않고 그대로 스토어로 가져온다. 당신의 델파이 앱을 MSIX로 패키징을 통해 배포하는 방법을 살펴보자. 더 나아가, 델파이에는 시스템 센서 컴포넌트들이 들어있다. 센서 컴포넌트는 물리적 양을 측정하고 이것을 신호로 변환하여 애플리케이션에서 읽을 수 있도록 해준다. 센서 컴포넌트 몇가지를 소개한다. TBiometricSensor TElectricalSensor TLocationSensor TMotionSensor TOrientationSensor 센서 컴포넌트를 내 앱에서 넣고 사용하는 방법을 어디에서 배울 수 있는가? 센서 컴포넌트 대부분을 다루었던 이 CodeRage X 세션이 있다. 5. 윈도우 앱 현대화와 개발 트렌드을 따라잡기 위해, 앞서 나아가는 기업들을 보고 배우고 있는가? 현대화를 주제로 진행된 엠바카데로의 온라인 세미나는 윈도우 앱 개발을 배울 수 있는 가장 좋은 자료들 중 하나이다. 데스크탑 용 최신 UI/UX 패턴, WinAPI, COM 과 ShellAPI, WinRT 활용 방안 등등을 배울 수 있다. 마이크로소프트 스토어에 배포하기 보편적인 데이터베이스 액세스를 위한 파이어닥 (FireDAC) 윈도우 High DPI 윈도우 런타임 활용 마찬가지로, 가장 최근에 진행된 Desktop First UX Summit도 온라인에 오픈되어 있다. 업계 리더들과 소프트웨어 엔지니어들이 소프트웨어 개발에 관한 훌륭한 워크샵과 실제 사례를 제공한다. 이 웨비나는 디자인 절차, 디자인 시스템, 인공지능(AI), 비주얼 디자인, 정보 아키텍처 등등을 다룬다. Desktop First UX Summit 2020 (한글 정리본) Desktop First UX Summit 2021 (한글 정리본)
×
×
  • Create New...

중요한 정보

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