[우테코] 점진적 리팩터링: 달리는 기차의 바퀴를 갈아끼우기

 

 

💋 인트로

이 포스팅은 우테코 코치 구구의 강의를 듣고 깃짱이 정리한 글입니다. 

 

💋 달리는 기차의 바퀴를 갈아끼울 수 있을까?

• 우리는 처음부터 완벽한 설계와 완벽한 코드를 작성할 수 없다.
• 시장 상황은 계속 바뀌고, 참여하는 개발자들의 역량도 계속 변한다.
• 기술은 발전하고, 지금 사용하던 기술은 언젠가 레거시가 된다.
• 달리는 기차(운영중인 서비스)의 바퀴를 바꿀 수 있어야 한다.
• 점진적인 리팩터링을 통해서!

 

💋 다 뜯어고치자: 원대한 재설계의 꿈

• 결론부터 말하면, 지금 코드를 다 뜯어고치는건 좋은 방법이 아닐 때가 많다고 한다.
• 물론 현재 프로젝트의 규모가 작다면, 레거시에 허덕이는 것보다는 그냥 새로 만드는 것이 더 빠를 때도 많을 수 있다.
• 하지만, 원대한 재설계, 즉 뜯어고치는 것은 아래와 같은 순서로 망하게 될 수 있다.
  • 갑자기 옆 경쟁사에서 쿠폰을 뿌린다거나, 이벤트를 연다면 일단 레거시라도 막 갈겨서라도 우리도 서비스를 제공해야 한다.
• 레거시에 허덕이다가 팀 내 생산성이 떨어짐.
• 새로운 개발자가 오면서 이상한 코드를 설명해 줘야 하기 때문에 생산성이 더 떨어짐.
• 팀 내 불만이 폭발해서, 관리자에게 재설계를 요구하고, 허락을 받음.
• 기존 돌아가는 서비스를 중단하고 재설계할 수는 없기 때문에 새로운 타이거 팀은 만들고 잘하는 사람들을 다 모음.
• 레거시 팀은 유지보수를 하고, 타이거팀은 돌아가는 서비스를 전부 새로 만들게 됨.
• 하지만, 레거시 팀에게도 계속해서 새로운 요구사항이 발생함.
• 타이거팀은 기존 시스템 기능을 모두 제공하는 새로운 시스템을 개발하는 동시에 레거시 팀에 새롭게 발생하는 요구사항도 반영해야 한다.
• 초창기 타이거팀 팀원은 너무 지쳐서 모두 퇴사하게 되고, 새 시스템은 새로운 요구사항을 따라가는 동안 또 레거시 코드가 생기게 됨.
• 새로운 팀원을 뽑았는데, 새로운 팀원이 다시 시스템이 쓰레기라서 다시 만들자고 함.
• 무한반복

 

💋 MSA가 무조건 정답은 아니다!

• 모놀리스는 레거시와 동의어가 아니다. 모놀리스는 선택이다.
• 레거시 역시 나쁜 말이 아니다. 레거시가 있기 때문에, 그 회사가 계속 사업을 유지할 수 있었던 것이다.
• 처음 시작하는 서비스에서는 모놀리스로 하는 것이 바람직하다.
• 처음부터 MSA로 시작하는 스타트업이 있다면, 도망가는 것을 추천!
• 사례
• 전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것”
• 쿠팡의 사례
  • 2013년 전환 시작
  • 2015년 전환 종료
• 배달의민족 마이크로서비스 여행기

 

 

💋 참고자료

• https://www.youtube.com/watch?v=zNUErq5ESbw

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟