Legacy System 고치기 (Refactoring Legacy System) Practice

'버튼 하나'만 누르면 재현 가능한 빌드를 만들어 주는 뭔가를 만려는 저의 모험이 시작됐습니다. (그 당시에 마틴 파울러의 이야깃거리 중 하나였습니다.) 

from 지속적인 통합 - 저자 :  듀발, 마티야스, 글로버 , 번역 : 최재훈

나는 지금 현재 Legacy System 을 담당하고 있으며, 해당 시스템을 고치는 작업을 진행중이다.

Legacy 시스템이라는 표현을 쓰는 이유는..  두가지 의미이다.

1) 회사에서 굉장히 중요한 시스템(수익을 창출하는 근간이 됨)이다. 

2) Sustainable 하지 않고 주먹구구 방식으로 돌아갔던 시스템을 의미한다. 

게다가 Test Code 한 줄 없고 방대한 코드들, 통신사의 History를 깊이 알지 않으면 이해할 수 없는 제품군이었다. 이를 조금씩 좋아지도록 하는 작업을 진행하고 있다. (사실 많은 이들이 어려운 Legacy 시스템을 고치려고 했으나, 퇴사 또는 다른 조직 전배를 갔다. 그러나 나는 혼자 서 있다..)

두가지 관점으로 일을 진행하고 있다.  

첫번째는 "Continuous Integration" 적용과 

두번째는 "Divide and conquer" 이다.

1) Continuous Integration

현재 돌아가는 상용버전은 svn, 브랜치 전략을 사용하지 않았다. 요즘은 흔하디 흔한 Test 코드조차 한 줄 없다. 게다가 가물거리는 프레임웍을 쓰고있다.  Sonar를 통해 확인해보니. 엄청난 양의 코드와 중복코드, 그리고 기간망간의 통신쪽은 건들기 어려운 부분이 존재했다. 게다가 model은 단 하나의 클래스로 사용하고 있었다.. 

그래서 운영/개발을 편하기 하기 위해서 조금씩 바꾸고 있다. 

1. SVN 으로 버전관리도 없이 하나의 branch에서 작업하던 개발 코드 (어느 버전이 상용인지. 개발인지 알수 없었음)을 모두 GIT 으로 전환한다.

2. 멤버들에게 GIT FLOW 교육을 실시하고 브랜치 전략 사용하도록 한다.

3. Jenkins 서버 설치하여 develop, master 빌드가 깨질때마다 메일이 전달되게 한다. (깨진 코드로 커밋 방지)

4. Sonar를 적용한다. 어차피 품질은 좋아지지는 않지만 언제나 현황을 본다. 

5. 중요 코드 Test Code로 품질 향상 (Legacy 시스템이라 많이 할 계획은 없지만. 

6. 소스 코드 정리 

  (사용하지 않아도 언제가 쓸 수 있다는 생각으로 코드가 삭제하지 않고 그대로 방치되고 있었고.. 배치성 코드는 하드코딩으로 버물려 있는 코드들이라. 우선 쓰지 않는 것부터 정리.)

7. CheckStyle, Formatter 적용

8. 진정한 Continuous Integration 적용 예정

(그동안 나는 DB 통합 자동화를 한적이 한번도 없었다. 그러나 이번에는 이 부분을 진행하면서 Ansible/Vagrant 기반위에 Tomcat을 두고 Node.js, DB등을 모두 Acceptance 테스트할 수 있는 환경.)

9. Ant를 통해 빌드/배포 모두 하는 구조에서 Ant/Ivy + 배포 서버, Maven + 배포서버 구조 변경

10. DB 스키마를 올바르게 변경

(오래된 Legacy 일수록 표준 문서와 개발 DB, 상용 DB의 constraints가 많이 깨져있었다. 그 부분을 모두 현행화하고 올바르게 바꿔야 한다.)

10. DB 변경 (검토)

(DB가 오래되면 물리적 장비를 바꿔야 하지만, DB 성능/기능이 제대로 동작하지 않으면 바꿀 수 있어야 한다. 그러나 리소스가 너무 없다. 리소스만 주어진다면 반드시 바꿔야 한다.)

(그러나 워낙 오래된 프레임 웍, 잘못 개발된 아키텍처로 CI 와 운영/패치일은 최소화할 수 밖에 없다.)

2)Divide and conquer

Legacy 시스템을 패기하나만으로 고칠 수 없다. 지식도 많아야 하고 관찰하고 관찰하고 또 관찰해야 한다. 한번에 개발하려고 했으나, 이는 쉽지 않다.  하나의 소스로 된 프로젝트를 여러개의 프로젝트로 나누고 개발한다. 

마치 진나라의 진시황이 한나라씩 나라를 정복한 방법처럼 하기로 했다. 

1. 공통모듈을 서버로 개발 (공용으로 개발가능한 개발 서버로 분리)

   서비스마다 비슷하게 구현하고 있는 것들은 다시 개발하지 않도록 하여 재활용할 수 있도록 하면 된다.

2. 특수모듈을 서버로 개발 (다른 서비스에서 필요하면 바로 연동할 수 있도록 분리)

(모듈을 7-8개로 쪼개서 분리시킨다.. 사실 항상 분리시키는 것이 좋은 방법이 아니다. 그러나 소스 자체의 의미를 모르고 정확한 의미를 위해서 복잡성을 제거한 서버 분리가 좋은 방법이라고 생각하고 진행중이다.)

3. 개발은 모두 Agile 방법론을 이용해서 진행한다.  

4. 새로 만든 서버들은 모두 배포 시스템을 이용해서 배포하도록 한다. (Continuous Deployment, Delivery 정책. Ansible, SSH 이용)

5. 가상 개발 환경을 구축한 후 Legacy API Test를 테스트할 수 있는 UI를 개발하고 그 UI로 selenium으로 기능 테스트(또는 시나리오테스트)를 진행하여 개발자들이 두려움 없이 테스트할 수 있는 방법을 제시한다.

(= Continuous Integration 8번과 공통)

'버튼 하나'만 누르면 재현 가능한 시스템과 API를 테스트해 주는 뭔가 (이것을 더 응용하면 자동 배포할 수 있는 시스템)를 만려는 저의 모험이 시작됐습니다.

김용환

처음에는 어려웠다. 그러나 계속 생각하며 Legacy System을 고치는 본질을 고민했다. 내가 적은  방법이 답이 아닐 수는 있다..

 "내가 배울 수 있는 것이 무엇인지를 알게 되는 시간"에서 작은 최선만 다할 뿐이다.