[Conference] 레거시 개편

 

컨퍼런스 영상 : (레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기 | 인프콘 2022

 

* 해당 블로그의 모든 내용과 사진은 위 영상을 참고하여 작성하였습니다.

 

레거시 시스템이란?

요약해서 말하면 낡은 시스템입니다. 예를들어 한때는 굉장히 각광 받았지만 시간이 지나면서 비주류인 기술을 의미합니다. 성능적으로 부족하거나, 요구 사항을 수행할 능력이 부족한 시스템을 의미합니다.

 

대표적인 예시로는 과거 휴대폰이 발달하기 전 인터넷의 트래픽양은 크지 않았습니다. 그렇게 Apache 의 요청마다 프로세스를 생성하는 동작방식으로도 잘 대응을 했지만, 휴대폰이 발달하고 인터넷의 트래픽의 엄청난 증가를 하면서 10K문제가 발생합니다. 이를 기점으로 Nginx의 스레드를 생성하여 메시지 큐에 요청을 담는 방식의 사용을 선호하여 이제는 Apache 류의 서버보다 Nginx 류의 서버를 선호하는 시대가 되었습니다.

레거시 시스템이 항상 개편 되어야하는가?

항상 그런것은 아닙니다. 레거시를 개편하는데의 필요한 비용보다 스케일 업이나 새로운 시스템을 만드는 비용이 더 적다면 회사에선 후자를 택할 가능성이 충분히 있습니다. 결과론적으론 투자자본수익률(ROI) 가 있어야합니다. 이는 회사에서 시간이나 학습 비용 및 비주류기술 채용등 다양한 요소를 고려하여 정해야할 것입니다.

개편의 기술

제 1장 의존성을 한 뱡향으로 정리하라

 

스파게티 코드라고해서 아래와 같이 객체간의 의존성이 꼬이는 것을 의미합니다.

개편을 하려면 코드를 수정해야합니다. 하지만 하나의 클래스에서 코드를 수정하면 어느곳에서 문제가 또 나게될지 정확히 판단하기 어렵습니다. 

그렇기때문에 스파게티 코드가 발생하지 않게 해야하는데, 그 방법에는 의존성의 깊이나 아키텍쳐의 설계대로 계층을 나눠놓은뒤에 의존관계의 역순으로 의존하는 코드를 만들지 않는것입니다. 

 

 

제 2장 변경 대상에 대한 경계를 나눈다

 

각 문제가 되는 계층이 있을텐데 각 계층마다 역할과 책임을 명확히 정하면 해당 계층에 맞지않는 코드들을 따로 다른 계층으로 분리할 수 있을 것입니다. 

 

위와 같은 계층에 맞지않는 코드들을 아래와 같이 빼버리는 식의 예시를 들수 있을것 같습니다.

 

 

반대로 해당 계층에 들어와야하는 코드들은 흡수를 하면서 코드를 정리할 수 있습니다.

 

이로써 제 각각이던 책임과 역할의 범위를 명백히 하게되면 변경범위에 대한 가시성을 확보할 수 있습니다.

 

 

제 3장 테스트를 확보한다

 

개편을 할 때 테스트를 짜면 좋겠지만 개편이라는 작업이 너무나 시간도 짧고 할일도 많은 작업일 경우일 것이므로 쉽지않습니다. 그럴때 강연하시는 분이 테스트를 어떻게까지 확보했는지를 알아봅니다.

 

언어, 프레임워크, 데이터베이스까지 전부 개편하는 작업일때, 기존에 있던 테스트 케이스는 재사용할 수 없는 경우입니다. 

테스트 케이스 복사 시간 또한 너무 오래걸리는 상황일때, JsonDiff를 사용했습니다.

즉, E2E 테스트입니다. 기존 시스템의 요청과 새로만든 Endpoint 요청의 결과가 똑같은지 확인하여 검증합니다.

해당 방식은 테스트의 원칙인 인터넷이 안되는 상황에서도 테스트가 되야한다 라는 원칙과는 맞지않으며 해당 시스템은 Command 작업이 아닌 쿼리만을 수행하는 시스템이어서 다행이 E2E 테스트로 진행하였다고 합니다.

 

하지만 저런 최악의 상황에서 저렇게라도 테스트를 챙긴다는것이 중요할 것 같습니다.

 

 

제 4장 프로젝트 가시성 확보

 

개편해서 해야할 큰일을 작은일들로 세분화 시켜 가시성을 확보하면 더욱 개편을 수월하게 할 수 있습니다.

예를 들어 라면을 끓이는 작업과 같은 경우에도 세분화해서 일정을 나눠보면 처음 라면을 끓일때 생각했던 시간과는 다를것입니다.

 

 

그렇게 된다면 일정에 대한 리스크를 잘 관리 할 수 있을것입니다.

또한 문서화를 시켜서 개발자들 뿐만아니라 다른 직무의 계신분들 또한 진행상황을 알 수 있게 해놓는것이 중요합니다.

 

 

제 5장 도메인 공유

 

제 생각에 이 내용은 개편을 할 때 뿐아니라 프로젝트를 구현할 때에도 적용되는 이야기 같습니다.

여러 구성원들이 모여 프로젝트를 진행할텐데 구성원들 간에 도메인에대한 이해 수준이 다를 수 있습니다. 

여기서 도메인이란 구현하려는 서비스에대한 이해를 의미합니다.

 

그래서 도메인을 이해하지 못한 사람의 경우 도메인을 이해하는데에만 큰 비용이 필요합니다. 이러한 사람들을 그대로 끌고 가게된다면 해당 사람들은 의사결정 과정에 참여하기가 어렵습니다. 

또한 도메인을 잘 아는 사람인경우 다른 이들에비해 결정의 부담을 느낄 수 있습니다.

 

따라서 도메인에 대해 이벤트 스토밍을 하면 좋습니다. 이벤트 스토밍이란 소프트웨어 프로그램 도메인에서 무슨일이 일어나고 있는지 빠르게 알아내기 위한 워크샵 기반 방법입니다.

 

 

제 6장 변화를 측정한다

 

여기서 "측정" 이란, 어떠한 관찰/수단을 이용하여 우리가 살펴보는 "무엇"에 대한 불확실성의 정도를 낮추는 행위를 말합니다.

위 말에서 "무엇"이란 개편을 하며 마주치는 여러 트레이드 오프나 도전들을 통해 발생하는 이점이나 단점을 측정하고 팀원들과 공유해야합니다. 따라서 이런 측정을 통해 불확실성을 낮추는것이 중요합니다.