인프콘 2022 - (레거시 시스템) 개편의 기술

📎 (레거시 시스템) 개편의 기술

• 배달 플랫폼에서 겪은 N번의 개편 경험기, 우아한형제들 권용근님

 

최근 회사 업무또한 레거시 부분들을 개선하고 효율적으로 운영하는 작업을 진행하고 있기에 인프콘에서 가장 관심이 간 섹션 중 하나인데요, 공감가는 부분도 굉장히 많고 내용이 매우 유익하기에 정리해보고자 합니다.

(혹시 이미지와 관련하여 문제가 되는 부분이 있다면 삭제하겠습니다.)

 

전체 섹션은 아래 링크에서 확인할 수 있습니다. 😃

https://www.inflearn.com/course/infcon2022/dashboard

[무료] 인프콘 2022 다시보기 - 인프런 | 강의

 

 

콘텐츠 목차

1. 레거시 개편은 왜 일어나는가?

• 레거시는 무엇이고, 개편은 어떻게 결정되는가?

2. 경험한 개편은?

• 배달플랫폼에서 겪었던 4가지 개편 소개

3. 개편의 기술

• 개편에 사용했던 4가지 방법 공개

4. 프로젝트 가시성 확보

• 작은 문제로 분할하여 해결 -> 큰 문제 해결

5. 부록 1, 2

• 도메인 이해 공유
• 변화를 측정

 

 

1. 레거시 개편은 왜 일어나는가?

• 레거시 시스템이란?
  • (위키에 따르면) 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 의미함
  • 처음에는 인기있더라도 시간이 지남에따라 비주류인 기술이 되는 것 -> 낡은 시스템
  • 현재는 성능이 부족한 시스템
  • 새로운 요구사항을 대응할 수 없는(어려운) 시스템
• 레거시 시스템은 항상 개편되어야 하는가?
  • 당연히 그렇지는 않다.
  • 투자자본수익률(ROI), 즉 가성비가 있어야 한다. (노력 대비 효용)
  • 시간, 비용(시스템 운영), 인원, 학습비용, 퇴사 등등의 리소스가 가능할 때
• 레거시 시스템 개편은 왜 일어나는가? 
  • 시간 대비 비용이 비효율적일 때
  • 적당한 시기에 개편을 하면 시간 대비 비용 증가 폭이 적음
  • 여기서 의미하는 비용이란? 서비스를 지속시킬 수 있는지, 성장시킬 수 있는지 결정하는 것
  • 결론은 서비스를 지속, 성장 시키기 위해 발생

https://www.inflearn.com/course/infcon2022/dashboard

 

 

2. 경험한 개편은?(배달의 민족)

2018 결제시스템 개편

• 기존 대비 너무 많은 성장으로 인해 성능이 부족한 시스템 -> 데이터베이스 파티셔닝 도입

2018 주문시스템 개편

• 성능이 부족한 시스템
• 비주류 기술

2019 가게노출시스템 개편

• 성능이 부족한 시스템
• 비주류 기술
• 새로운 요구사항을 대응할 수 없는(어려운) 시스템

2021 회원시스템 개편

• 성능이 부족한 시스템(인프라 한계치, 도메인 분리)
• 비주류 기술

 

 

3. 개편의 기술

1) 의존성을 한 방향으로 정리: 정돈된 의존성

https://www.inflearn.com/course/infcon2022/dashboard

• 스파게티 코드, 스파게티 의존성? -> 객체간 참조방향이 복잡하게 섞여있어 심각한 상황
• 스파게티 코드의 문제점은? 코드를 변경했을 때 발생할 수 있는 사이드 이펙트 추적이 불가능함
• 스파게티가 발생하는 이유는, 추가적인 기능이 발생했을 때 기존 코드를 재사용하고 참조하는 등의 반복적인 작업을 통해 의존성 참조가 발생함
• 스파게티 코드를 풀기위해 의존성 방향을 한 방향으로 설정할 것
• 의존성을 한 방향으로만 잘 관리해도 의존성을 피할 수 있음
• 이와 같은 작업을 통해 사이드 이펙트가 여기저기 발생할텐데, 이는 사이드 이펙트의 추적이 가능한 상태이기에 좋은 점!

참고: https://techblog.woowahan.com/2637/

 

2) 변경 대상에 대한 경계 분리: 책임과 역할이 명확한 계층과 객체

• 의존성 방향이 정리되어야 변경 대상에 대한 경계를 나눌 수 있음

https://www.inflearn.com/course/infcon2022/dashboard

• 위 이미지에서 스프링을 기준으로 2번은 Controller, 3번과 4번은 Service, 5번은 Repository라고 가정

 

https://www.inflearn.com/course/infcon2022/dashboard

• 간단하게는 위와 같이 계층을 나누고, 변경 대상을 하나의 계층으로 파악
  • 여기서 어떠한 개편을 하는지, 변경되는 코드들이 무엇인지 생각해보며 책임과 역할을 재정의
  • 즉, 개편에서 다루어야할 계층을 확보하고 책임와 역할을 명백하게 분리하여 정의
• 예를 들어, 결제시스템 개편 시 데이터베이스 파티셔닝 작업을 진행했는데 변경 대상에 대한 내용을 추출해봤을 때 모든 내용이 DB를 수정하는 코드들이었고, 이를 분리하여 하나의 계층(인프라스트럭쳐 레이어)으로 정의함
• 그 후 계층 책임 및 역할에 의한 통합 작업을 진행
• 무엇을 얻었는가?
  • 제각각이던 책임과 역할을 하나의 계층으로 응집하고, 계층의 역할과 책임을 명백히 정의 -> 변경범위에 대한 가시성 확보

 

3) 테스트 확보: 안정감

• 2)에서 진행한 변경된 내용에 대해 테스트 케이스 작성
• 변경을 진행하면 인터페이스가 변경될 수 있는데, 해당 계층의 한 단계 상위 레이어까진 테스트 케이스를 작성하면 좋을 듯 함
• 개편은 일정이 정해져 있는 상황이 많기에 테스트 케이스 작성이 누락되기 쉬운데, 어떻게 테스트를 확보했는지 공유

 

2019 가게노출시스템 개편

• 언어, 프레임워크, 데이터베이스까지 전부 변경된 개편
• 기존의 테스트 케이스 재사용 불가능 -> 테스트 케이스 복사(시간 부족)
• 그렇기에 아래와 같은 방법으로 진행 ..

https://www.inflearn.com/course/infcon2022/dashboard

• JSON 요청 Diff -> 로컬에서 테스트 시 E2E 테스트에 대한 요청이 기존 시스템과 동일한 결과가 나오는지 검증
• nGrinder를 통한 성능(부하) 테스트 진행
  • 상당히 많은 시간동안 가지고 있는 모든 데이터 풀을 요청하여 비교를 진행함

 

2021 회원시스템 개편

• 데이터베이스, 일부 코드 변경
• 테스트 케이스 재사용 가능... 하지만 테스트 케이스가 존재하지 않음
• 블랙박스 E2E 테스트(중간 단계에서는 어떠한 작업이 일어나는지 상관하지 않음)
  • 요청, 데이터베이스 데이터로만 테스트를 진행
  • 앱에서 정상 동작하는 Access log를 수집하여 진행 : 엔드포인트 테스트 확보

https://www.inflearn.com/course/infcon2022/dashboard

• 무엇을 얻었는가?
  • 변경해도 괜찮다는 안정감

 

결국에는 유지보수하기 좋은 소프트웨어를 만들기 위한 원칙과도 동일하다고 생각한다.

 

4) 프로젝트 가시성 확보

https://www.inflearn.com/course/infcon2022/dashboard

• 작은 문제를 해결하다 보면 큰 문제를 해결할 수 있는 방법
• 해야할 일들을 가시화(작게 분할)
• 일정에 대한 리스크를 더 잘 관리할 수 있음
• 엑셀에서 시스템, 대분류, 중분류, 상태, 업무, 담당자, 일정 등을 기준으로 관리함
  • 같은 업무를 진행하는 담당자들과 진행 상황에 대한 공유가 가능함
  • 지표들을 보며 지칠 수 있는 상황도 힘을 낼 수 있음(?)
  • (명백한 지표, 데이터가 존재하면) 이해 관계자가 이 프로젝트를 후원하기 좋아진다.
  • 해야할 일들을 가시화하여 문서화 -> 일정 예측 & 일정 리스크 관리, 진행 상황 공유

 

부록1.

• 여러 구성원간 *도메인에 대한 이해 수준이 다른 상황이 존재할 수 있음

*도메인: 주문 시스템에서의 주문, 결제 시스템에서의 결제 등

 

• 개편할 때 도메인 이해에 큰 비용이 필요
• 더 리스크한 것은 의사결정 과정에 참여하기 어려움
• 도메인 전문가는? 큰 부담을 가질 수 있음
• 결국, 도메인에 대한 다른 이해관계에 의해 커뮤니케이션 비용이 발생 -> 모두가 힘들 수 있음
• 추천하는 방식은 이벤트 스토밍(DDD, 전술적 설계)
  
  • 참고 영상: 도메인 지식 탐구를 위한 이벤트 스토밍 Event Storming
  • 무조건 도움이 된다고 생각
  • 이벤트 스토밍은 소프트웨어 프로그램의 도메인에서 무슨 일이 일어나고 있는지 빠르게 알아내기 위한 워크샵 기반 방법
  • 결국 이벤트 스토밍은 어떤 문제를 해결해야 하는지 빠르게 알아내기 위한 방법
  • 도메인에 대해 익숙하지 않은 구성원도 도메인에 대해 배울 수 있음
  • 모든 구성원이 비즈니스 개선에 도움이 될 수 있도록 기여할 수 있음
  • 궁극적으로 모든 구성원이 도메인에 대한 이해를 공유할 수 있음 -> 동일한 목표, 동일한 방향으로 진행
• 2021 회원시스템 개편 시 이벤트 스토밍을 통해 도메인에 대한 이해 공유 -> 각자 도메인 지식 향상

 

부록2. 변화를 측정

측정: 어떠한 관찰/수단을 이용하여 우리가 살펴 보는 *무엇에 대한 불확실성의 정도를 낮추는 행위

*무엇? 트레이드 오프, 도전, 기술 선택 방식, 방법 등

 

주문수가 증가했는지, 비용이 감소되었는지, CPU 사용률이 증가했는지, TPS가 감소했는지 등의 지표를 분석

이전에 비해 나쁜 지표더라도 무조건 마이너스는 아니다고 생각하고, 어떠한 트레이드 오프를 했는지가 중요함

 

결국, 지식들이 기록되어 공유가되면 나와 내 동료들에게 좋은 유산이 될 것이라고 생각함

 

 

마무리

개인적으로 생각했던 것들과 비슷한 내용이 많아 굉장히 공감하며 재밌게 본 영상인 것 같습니다.

저는 특히나 3. 테스트 확보 와 4. 프로젝트 가시성 확보 의 내용이 더더욱 공감되었는데요, 테스트 코드를 충분히 확보하여 레거시 서비스를 개선하기 전 테스트 코드를 통해 반영하기 전 대부분의 로직은 테스트를 진행할 수 있었고, 추후 리팩토링을 진행할 때도 많은 덕을 봤기에 공감할 수 있었습니다. (물론 테스트 코드가 실제 이관 시 100% 커버하기엔 힘들지 않을까 생각합니다.. 😂) 

 

또한 프로젝트 가시성 확보를 위해 작은 문제로 분할한 뒤, 작은 문제에서 일어나는 모든 일들을 정리하여 이해한 뒤 개선하는 작업을 진행했는데요, 이렇게 프로젝트를 가시화하는 것이 훨씬 더 수월하게 진행되는 것을 경험하였습니다. 추가적으로 이관 시 발생할 수 있는 사이드 이펙트 등은 미리 파악을 하여 이슈가 발생하더라도 충분히 롤백 등의 컨트롤이 가능하도록 실패 케이스까지 고려하는 것도 굉장히 좋은 듯 합니다.

 

영상에서 진행한 개선건만큼 큰 프로젝트는 아니었지만, 영상을 보며 다시 한 번 정리할 수 있어 뜻깊은 시간이었습니다. 😃