현재 진행중인 프로젝트 중, 내가 맡은 부분에서 꽤나 큰 역할을 하고 있는것이 '레거시 개선' 이다.
'레거시'라고 하기엔 그렇지만.. 프로젝트를 진행 하면서 가장 크게 리팩토링 했던 작업에 대해 기록해본다.
어떤것을 개선하고 싶었나?
개선 할 것들을 리스트업 하기전, 몇가지 기준점을 세웠다.
-
레거시 코드가 많은 구조
여기서 레거시 코드라 함은 이전에 개발되어 코드 컨벤션이 맞지 않고 유지보수가 되고 있지 않은 코드, 비효율적으로 돌아가고 있거나, JPA를 잘 쓰지 못하고 N+1 등의 문제가 발생하는 코드들을 말한다. -
다른 사람이 알아보기 힘든 코드
너무 이전에 개발되었거나, 개발한 동료들이 모두 퇴사하여 히스토리가 부족한 경우. 로직 복잡도가 높아 손 대기 어려운 코드. 러닝커브가 높은 구조. -
테스트 코드가 잘 작성되지 않은 코드
흔히 알고 있는 레거시 코드 개선 가장 중요시 여기는 포인트 중 하나가 테스트커버리지를 높히는 것인데, 이것이 어렵거나 테스트 코드로 커버가 되어 있지 않은 코드 -
그외
테이블이 필요 이상으로 많거나 복잡도가 높은 경우, 서비스 개선이나 운영업무를 진행할때 휴먼에러가 자주 발생하여 시스템 적으로 개선이 필요한 경우
등으로 개선할 도메인들을 추려보았다.
왜 역할권한을 선택했나?
레거시라고 표현하고 싶지는 않다. 하지만, 위에서 나열한 조건들이 모두 부합된다해도 과언이 아니었다..!
아래에서 설명하겠지만, 역할/권한을 담는 테이블 구조 자체가 매우 복잡했고 히스토리를 알지 않는 이상 특히 신규 개발자들이 들어왔을때 역할 도메인에 대해 이해하는데 굉장히 큰 어려움을 겪었다.
이 부분을 해결하려고 문서화도 해보고, 백엔드팀 모두 모아서 전체적인 구조와 자주 발생하는 이슈나 운영건에 대해서 설명하는 시간도 가졌었지만, 이쪽 부분을 건드리는 일이 생기면 늘 다시 이게 뭐냐는 도돌이표 질문이 돌아왔다.
또 역할/권한으로 메뉴가 핸들링 되기 때문에 신규 메뉴가 추가 될때마다 수동으로 DB insert 해야 하는 경우(이 또한 운영 자동화가 필요했지만, 아무도 건드리지 못한것도 문제였던것 같다..)가 생겼는데, 이때마다 메뉴가 안보인다는 이슈는 꼭 한번이고 발생하곤 했다.
그 외에도, 프론트에서 메뉴를 그려내기위해 조회하는 API에서 70번 이상의 쿼리가 날라가는 등 (이건 발견 후 수정하여 해결되긴 했지만..) 굉장히 맘에 걸리는 기능중 하나였고, 이번 프로젝트를 진행하면서 '개선' 이라는 역할을 받자마자 가장 먼저 생각났고 꼭 개선하고자 하고자했다.
어찌보면 우리 시스템에서 핵심적이면서도, 말 그대로 애증의 기능이였다.
어떻게 ?
TO-BE 를 위해서는 AS-IS 분석은 필수이다.
그나마 팀내에선 가장 잘 알고 있던 기능이였지만, 감(?)으로 했던 것도 많았고.. 클라이언트 부터 서버까지 이 기능을 어떻게 쓰고있고 어떻게 동작하는지 프론트 코드부터 API 엔드 포인트 까지 모두 뜯어보았다.
첫번째. 테이블 구조 개선하기.
현재 가장 큰 문제는 테이블 복잡도가 높고 불필요한 데이터까지 테이블로 만들어 놓은 것이다.
따라서, 메뉴 path, 상세 권한 (실제로 핸들링 되지 않기도한), 또는 불변하지 않는 정의 값은 모두 Enum으로 대체하고 테이블을 제거하고자 했다.
또한 핸들링 되지 않는 프로퍼티들 중 Enum이나 데이터로 관리하지 않아도 되는것들을 추려 제거하거나 공통화 시켜 핸들링이 필요한 권한들은 테이블로 관리할 수 있도록 했다.
이 작업만 진행해도 테이블 수가 반이 줄어들 수 있었다.
두번째. 프론트 코드를 분석해보기.
프론트 코드를 까본이유는, 개선하겠답시고 무턱대고 모든 구조를 바꿔버리면 API나 response의 변경은 피할수 없는데 이때 프론트 작업에 대해 영향도는 얼마나 갈것이고 또 내가 원하는 방향으로 개선 가능한지 여부를 어느정도 파악을 해놔야 실제로 개선 포인트를 협의할때 원활하게 진행될 수 있을것 같았다.
현재 서버에서 접근을 막아야하는 역할별 path를 내려주고 있었는데, 이 또한 고정된 값이고 핸들링 되지 않는 부분이라 굳이 DB를 거치지 않아도 되었다.
vue router를 이용해 페이지 접근을 핸들링 하는것을, API를 통해서가 아니라 프론트에서 고정된 값으로 정의해서 접근을 막으면 될것 같았고 이부분이 확인이 되어 실제 협의때 반영이 되었다.
번외로 ..이번 역할권한 개선에 있어서 프론트 역할이 굉장히 중요했기 때문에 내 개선포인트를 함께 고민해주고 적극적으로 협의해준 프론트 팀원에게 매우 감사하다..
세번째. 네이밍 정의
복잡한 테이블도 문제였지만, 그에 맞지 않는 해석하기 어려운 네이밍도 한 몫 했다고 생각했다. 그래서 가장 고민하기도 했던 부분이기도하다.
최대한 테이블명만봐도 직관적으로 어떤 데이터인지 표현하기 위해 고민했다.
네번째. 정말 중요한 마이그레이션
암만 열심히 구조를 개선하고 보기 좋은 코드로 만들었다한들, 기존 데이터가 유실이되거나 기존 동작이 안된다면 말짱도루묵이다.
레거시 개선보다 중요한건 서비스가 원활하게 동작되고 이슈가 없어야하는것 ..
아예 테이블을 새로 만들고 구성한것이기 때문에 마이그레이션은 필수였다.
마이그레이션 자체는 시스템 구조와 테이블이 직결된것이라 크게 공유하고 쓸 내용은 없으나.. 어떻게 개선할지 고민하고 개발했던 내용중이라 적어보았다.
AS-IS를 완벽하게 분석하고 문서화해둔것이, 이때 굉장히 크게 도움이 되었다 !
작성중 ..
개선 전
개선 후
