Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr
  • [DelphiCon 요약] 델파이 7에서 벗어나기 - 마이그레이션 프로젝트 사례


    Kori

    << 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의 개발자입니다.

    목차


     

    회사 및 프로젝트 소개

    회사 소개: 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로는 지금 시점에서 필요한 기술 모두를 지원하지 못한다.
        • 시스템 운영에 크리티컬할 기술에서도 그렇다. 구버전에서 벗어나서 최신 기술에 맞춰가자.

    참고 자료

    그림 자료

    마이그레이션 전과 후의 UI 비교: 로그인 화면
    a1.png

     

    새 UI에서 사용자 테마 선택 지원: 설정 화면
    a2.png

     

    새 UI에서 사용자 테마 선택 지원: 다크 테마 적용 시 화면

    a3.png

     

    마이그레이션 전과 후의 UI 비교: 일반 화면
    a4.png

     

    새 UI에서 대시보드 구현
    a5.png
     

    새 UI에서 실시간 그래프 구현1
    a6.png

     

    새 UI에서 실시간 그래프 구현2
    a7.png

     

    "맞춤" 자동 변환 도구
    a8.png

     

     

    예시: 써드 파티 컴포넌트의 경우 프로퍼티 변환이 필요함


    a9.png

     

     

    3단계 (검증 단계)의 버그 발견 및 해소 추이


    a10.png

     


    << DelphiCon 2021 목록으로 이동


    User Feedback

    Recommended Comments

    There are no comments to display.


×
×
  • Create New...

중요한 정보

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