인프콘2022 - 레거시 시스템 개편의 기술 정리

레거시 시스템 개편은 왜 일어나는가?

• 레거시 시스템
  • 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어
  • 현재는 비주류인 기술
  • 과거에는 요청을 잘 처리했지만 현재는 성능이 부족한 시스템
  • 새로운 요구사항을 대응할 수 없거니 하기 어려운 시스템
• 레거시 시스템은 항상 개편되어야 할까?
  • 현재는 비주류인 기술은 시간을 더 들여서 해결
  • 현재 성능이 부족하면 비용을 더 지불해 스케일 아웃
  • 새로운 요구사항을 대응할 수 없으면 새로운 시스템을 만들어 해결
• 개편 결정
  • 투자자본수익률(ROI) -> 가성비를 따져본다
  • 시간, 비용, 인원, 학습 비용, 비즈니스 지연, 생명주기, 채용, 퇴사 리스크, 한계 등을 계산해야 함
  • 시간과 비용 면에서 개편을 언제 하는지도 굉장히 중요
• 결론은 서비스를 지속, 성장시키기 위해 개편을 하게 됨

내가 경험한 개편은?

• 결제 시스템
  • 성능이 부족한 시스템으로 인해 DB 파티셔닝 진행
• 주문 시스템
  • 성능이 부족하고 비주류 기술로 구현되어 DB 모델링과 도메인 개편
• 가게노출 시스템
  • 성능 부족, 비주류 기술, 새로운 요구사항 대응 어려운 시스템
  • DB 모델링, 새로 프로젝트 생성
• 회원 시스템
  • 성능 부족, 비주류 기술
  • 스케일 아웃, 스케일 업 불가능한 상황
  • 회원과 인증 도메인 분리

개편의 기술

의존성을 한 방향으로 정리하라

• 스파게티 의존성
  • 객체나 의존성의 방향이 한 방향이 아니라 얽히고 꼬힌 상태
  • 사이드 이펙트 측정이 어려움
  • 기능을 쫓으면서 재사용하게 되면서 발생하게 됨
  • 리스크 관리가 매우 어려움
• 기준을 정해야하며 기준을 정하기 어려우면 의존의 깊이로 층을 형성해서 판단하도록 함
• 같은 층을 의존하는 것도 다른 방향으로 취급
• 같은 층에서 의존하게 되는 경우, 다음 깊이에 코드를 정리해서 한 방향으로 맞추도록 함
• 의존성을 한 방향으로 정리하면 사이드 이펙트를 측정할 수 있음

변경 대상에 대한 경계를 나눈다

• 계층이 분포한 모양이 다르게 되면 책임과 역할이 각각 다르게 됨
• 변경 범위를 파악하기 어려워짐
• 패키지나 모듈로 범위를 나눌 수 있음
• 범위를 나눈 계층에 책임과 역할을 정의
• 개편에서 다루어야 할 계층을 확보 가능
• 계층을 책임과 역할에 따라 다시 분리
• 책임에 의해 분리되면서 변경 범위에 대한 가시성 확보 가능

테스트를 확보한다

• 변경 대상의 테스트 코드
• 인터페이스가 변경될 수 있어 테스트 커버리지를 채우면 좋음
• 변경해도 된다는 안정감을 얻을 수 있음

프로젝트 가시성 확보

• 큰 문제를 작은 문제로 만들어 풀어나가도록 해서 해야할 일을 가시화
• 일정에 대한 리스크를 더 잘 관리할 수 있음
• 이해 관계자가 프로젝트를 도와주기 더 쉬움
• 일정 예측, 진행 상황 공유 편리

도메인 이해

• 도메인 이해 수준의 차이가 있을 수 있음
• 도메인 이해가 낮은 경우
  • 도메인 이해에 큰 비용이 필요
  • 의사결정 과정에 참여가 어려움
  • 주도적으로 진행하기 어려움
• 도메인 이해가 높은 경우
  • 큰 부담
• 커뮤니케이션 비용 발생
• 결국 모두가 힘들어짐
• 이벤트 스토밍
  • DDD의 전술적 설계 방식
  • 참고 영상(도메인 지식 탐구를 위한 이벤트 스토밍)
  • 소프트웨어 프로그램 도메인에서 무슨 일이 일어나는지 빠르게 알아내기 위한 워크샵 기반 방법
  • 도메인에 대해 많이 배울 수 있음
  • 모든 구성원이 비즈니스 개선에 도움될 수 있도록 기여 가능
  • 사용 가능한 툴(miro)

변화를 측정한다

• 측정
  • 어떠한 관찰/수단을 이용하여 우리가 살펴보는 ‘무엇’에 대한 불확실성의 정도를 낮추는 행위
• 개편 중 살펴봐야 할 것들: 트레이드 오프, 도전적 업무
• 측정하는 과정 중에 잘 기록하고 공유도 하면 동료들에게도 도움이 될 수 있음