레거시에서 어떻게 탑을 쌓아올릴 것인가

개요

한달만에 글을 쓴다, 대규모 리브랜딩 후 배포를 앞두고 있어서 사실 블로그 뿐만 아니라 축구도 못하고 있다..

하지만 왜 글을 쓰냐, 그건 스터디를 해야하기 때문이지,  스타트업에 리드 개발자로 합류하면서 기존의 레거시에서 발생하는 문제점들을 인지하고 스타트업 특유의 빠른 생산성에 영향을 주지 않으면서 기존의 레거시를 개선하고 있는 경험을 공유하기 위해서이다.

 

모르겠고 다음주 월요일 새벽배포인데 교회 기도하면서 배포할 예정이다..

 리팩토링의 종류

처음에는 정말 많은 고민을 했다, 리팩토링의 중요성을 인지하고 있었지만 당장의 기능 개발과 버그 수정 때문에 손을 못 대고 있던 상황이였다. 하지만 나는 수많은 컨퍼런스와 기술 블로그 덕후로 알고 있었다, 생산성에 영향을 주지 않은 리팩토링 방법을

 

리팩토링에는 크게 두가지 방법이 있다, 빅뱅과 도살자 방법이다.

 

빅뱅 방법은 리팩토링 외에 모든 태스크를 중지하고 리팩토링에만 올인하게 되는 방법이다, 올인하게 되니 신규 기능부터 크리티컬한 버그가 아닌 이상 모든 팀원의 리소스가 리팩토링에 집중되게 된다. 하지만 난 이 방법은 우리에게 너무나도 부적합한 방법이라고 생각이 들었다, 코드단의 문제로 비즈니스적인 손실이 거의 안 일어나는 스타트업은 물론이고 네카라쿠배 같은 큰 회사들에게도 리스크 있고 부담스러운 방법이다.

 

그렇다면 도살자 방법도 있다, 도살자 방법은 기능 개발을 지속하면서 리팩토링 포인트를 잘라서 하나씩 개선해 나가는 방법이다. 이렇게 되면 기능 개발도 원래 일정대로 진행할 수 있으면서 빅뱅 방법보다는 2배 이상 오래걸리겠지만 언젠가는 리팩토링이라는 커다란 과업을 하나의 작은 단위를 해결함으로써부터 달성할 수 있게 된다.

그래서 저는 어떻게 했냐구요?

사실 리팩토링에 관한 의사결정을 내릴 당시에는 위에 적힌 리팩토링의 종류를 몰랐다, 하지만 돌아보니 내가 했던 방식은 도살자 방식이였다. 근데 어떤 리드가 와도 여기서 빅뱅 방식의 리팩토링하는것은 정신나간 판단이기 때문에 모두 나와 같이 결정하지 않았을까 싶다.

 

우리 서버의 문제점은 잘못 설계된 데이터베이스와 그에 대가를 말도 안되는 N+1 문제로 해결하고 있었다. 사실 요즘에는 N+1 문제가 정말 대중화되고 왠만한 취준생 이력서에 하나씩 적혀있으니 겨우 그거가지고? 라고 생각할 수 있다. 하지만 포트폴리오에 적는 N+1 문제와 필드에서 잘못 설계된 데이터베이스가 2년동안 신규 기능 개발을 하며 더 많은 테이블이 생기고 많은 데이터가 쌓여가며 발생시키는 N+1 문제는 어떻게 손을 쓸 수 없었다. (모든 엔드포인트에서 발생하고 있었다) 그래서 나는 당장 유저 경험에 영향을 미치는 API를 분류하고 급한 불을 끄는것이 내 합류 첫 과제였다.

 

그리고서는 리브랜딩 태스크도 한달에 끝내기엔 만만치 않기 때문에 아에 신규 기능을 위한 서버를 새로 만들기로 결정하였다, URL에 버저닝을 하고 최앞단에 로드밸런서를 놓으면서 해결하기로 하였다. 어떤 래퍼런스를 참고한건 아니였고 그냥 머리에서 그렇게 하라고 했다.

 

대충 이런 구성이다, 앞단의 ALB가 URI 패턴을 구분하여 v1은 legacy로 v2는 new 서버로 연결해주는 방식이다.

신규 기능을 모두 새로운 서버에 개발하고 있고, 주문 & 결제 같은 트랜젝션과 실패 전략에 예민한 부분들도 새로운 서버에서 적절한 방식으로 새로 개발하였다. 하지만 데이터베이스는 기존것을 그대로 사용하기 때문에 데이터의 마이그레이션이나 데이터 구조 재구축 등의 리스크가 큰 작업들은 피할 수 있었다. 그런데 기존의 엉망인 데이터베이스 구조에 맞춰서 좋은 코드를 개발하는게 이렇게 어려운 일인지는 몰랐다.

 

이번주에 리브랜딩 작업이 거의 마무리 되었고 기존 레거시를 약 70% 버릴 수 있게 되었다, 한마디로 빡빡한 리브랜딩 태스크를 소화하면서 기존 레거시 코드를 약 70% 개선한 셈이다. 물론 근본인 데이터구조를 바꿔야하지만 코드의 메인 도메인 로직들을 데이터베이스 테이블에 의존적이지 않게 개발해둬서 나중에 데이터구조가 변경되고 레고 조립하듯이 마이그레이션 할 수 있도록 개발해놨다.

마무리하며

데이터베이스 리팩토링은 내년 봄..? 솔직히 무기한 미뤄뒀지만, 요즘에 구조 자체에 대한 생산성의 저하와 유저 경험 때문에 계속 내부적으로 언급되고 있고 조만간 해야할지도 모르겠다.. 조만간 데이터베이스 리팩토링 글로 찾아올수도..

써야하는 글은 많다.. 조만간 다 정리하도록 하겠다
다음주 월요일의 새벽배포가 무사하길 기도하며.. 이번 글은 마치겠다