[102호] (레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기
Last updated
Last updated
💡 By 권용근 우아한형제들
개발자라면 피할 수 없는 시스템 개편. 배달의민족 결제 시스템, 주문 시스템, 프런트 시스템, 회원 시스템을 개편하면서 터득한 성공적인 개편 리딩 경험과 기술을 소개합니다. ‘왜 우리는 계속 개편을 하고 있는 것일까?’, ‘개편을 어떻게 해야 할까?’ 등 평소 개편에 대한 궁금증이 있었던 분들께 도움이 될 것입니다.
현재는 비주류인 기술들
→ 개발자들에게 시간을 더 많이 주어 유지보수 및 기능 확장을 할 수 있다
현재는 성능이 부족한 시스템
→ 비용을 더 지불하여 부족한 성능만큼 보충한다
새로운 요구사항을 대응할 수 없는(어려운) 시스템
→ 새로운 시스템을 만든다
투자자본수익률(ROI)
노력 대비 이익을 따져봐야 한다
적당한 시기에 개편을 하게되면 큰 효율을 얻게된다
개편의 목적은 서비스를 지속, 설정 시키기 위해 일어난다
💰 결제시스템 개편
→ 폭발적인 성장으로 인한 데이터베이스 파티셔닝 도입
🛍 주문시스템 개편
→ 데이터 모델링 구조가 더 많은 트래픽을 처리하기에는 부족하여 모델 구조 변경
🏪 가게노출시스템 개편
→ 새로운 비즈니스 프로젝트를 수용하기 위해서 기존 레거시 시스템을 개편
👩🔧 회원시스템 개편
→ 인프라 성능에 한계치, 스케일 아웃.업을 할수 없는 상황이라 개선하기 위함, 도메인을 분리하기 위함(회원, 인증)
상호 의존하다보면 스파게티 같은 의존성이 발생한다
처음엔 잘 설계될지 몰라도 새로운 기능 개발하면서 재사용성을 높이기위해 의존성을 추가하다 보면 어느새 상호 의존된 모듈이 많이 발생하게 된다
스파게티 코드를 풀수 있는 방법은?
의존성을 한방향으로 설정하라
의존성의 깊이로 층을 형성하라
같은 층을 의존하는 것도 지양하라
스파게티 코드를 풀게되면 사이드 이펙트를 줄일 수 있다
책임과 역할이 제각각인것을 정리하자
각 계층별 변경된 내용을 별도 계층으로 우선 나누어본다(ex. 패키지 또는 레포지토리)
독립된 계층을 어떤 성격인지 파악한 후 정의하여 관리한다
만약 변경에 대한 코드가 레파지토리에 집중되어 있다면 디비를 개편해야 한다
책임을 분리하여 변경에 대한 가시성을 확보하면 유지보수에 용이하다
개편하면서 변경되는 부분에 대한 테스트 케이스는 무조건 있어야 한다
될수 있으면 상위 레이어까지 테스트 커버리지를 충족하는게 안전하다
테스트의 중요성…당연한거다.. 하지만.. 현실은 어렵다.. 그렇기에 개편은 정말 어렵다.. 일정도 지키기 어렵다..ㅜ
ngrinder를 도입해서 데이터 풀을 맥시멈으로 사용하도록 하여 개편에 대한 안정성을 높일수 있었다
라면을 제조하는걸 하나의 프로젝트라고 생각해보자
라면 제조 프로젝트는 대략 몇분 정도 소요될것 같은가?
5분? 7분?(물 끓이기 → 면 넣기 → 스프 넣기 → 계란도 넣기 → 끓이기)
실제로는 6분 35초가 걸린다고 한다..
이렇듯 어느 프로젝트를 전체 범위로 일정을 산정하다 보면 추상적인 경우가 있다
그러니 좀더 큰 문제를 작은 문제로 풀어나가면서 일정을 좀더 가시화 할 필요가 있다
일정에 대해서 예측을 한다는건 리스크를 잘 관리할 수 있다는 뜻이다
가장 최근에는 엑셀 시트에서 WBS로 간트차트를 작성하였다
가시성이 확보되면 이해 관계자한테 설듯하기도 쉽고 진행상황 공유도 수월해 진다
의사결정 과정에 참여하기 어렵다
큰 부담을 갖게 된다
똑같은 요구사항에 대해서도 다르게 이해한다
같이 일하는 과정에서 굉장히 많은 커뮤니케이션 비용이 든다
이벤트 스토밍을 통해서 도메인에 대해 같이 이해하는 자리를 갖자(발표자는 이 과정에서 굉장히 많은 도움을 받았다고 한다)
KCD 도메인 지식 탐구를 위한 이벤트 스토밍 강의 들어볼것
개편을 하면서 변화된 수치를 측정하여 트레이드 오프를 해본다
이 측정을 통해서 불확실성을 좀 더 낮출수 있는 기대심리가 있다
