[DelphiCon 요약] 델파이 7에서 벗어나기 - 마이그레이션 프로젝트 사례 - DelphiCon

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