최근 회사에서 저번에 배포한 서비스의 2차 개발을 마무리했다.
예상했던 공수기간보다 빠르게 개발해서 남은 시간동안 리팩토링과 쿼리튜링 작업을 진행했는데, 그 과정에서 쓰인 것들을 글로 남겨보고자 한다.
내 역할
나는 스킬서버와 백그라운드 서버, 프론트 서버, 어드민 서버 등 사내의 여느 개발자분들과 마찬가지로 모든 분야에서 백엔드와 프론트엔드를 가리지 않고 개발중이다.
그 중에서도 특히 프론트 서버에서 통계와 대시보드 페이지에 공을 많이 들였다.
그럴 수 밖에 없었던 게 아무래도 통계인 만큼 쿼리가 상당히 복잡해서 테이블 구조를 파악하고 필요한 프로시저와 테이블 설계부터 API설계, 그리고 Vue.js 를 활용한 프론트엔드 작업까지 심혈을.....
속도전 = 레거시?
정식으로 서비스 런칭을 앞두었을 당시, 누구나 하는 변명이겠지만, 시간이 없었다.
때문에 아직 익숙하지 않았던 JPA로 그 복잡했던 MySql 쿼리를 시간 내에 구현할 수가 없었다.
최소한 Native로 쿼리해서 JPA 만큼은 잃고 싶지 않다고 생각했었는데, 그래도 통계쪽은 조회를 하는 것이지 insert 가 아니니까, 우선은 MyBatis로 처리하자는 사수님의 의견에 따라 진행하게 됐다.
결국 그 배포만 끝나면 반드시 JPA를 더 연마해서 MyBatis를 제거하리라 마음먹고 일단락되었다.
그 결과
불편했다.
마이바티스가 꼭 레거시인 것은 아니지만, JPA를 도입하기로 한 프로젝트에 섞어두니 Query문을 봐야할 때마다 다른 것들은 JPA를 보는 반면, 얘는 mapper xml을 따라가야 되니까 그게 여간 불편한게 아니었다.그리고 실제로 성능도 차이가 있었고.
이전 작업 시작
퇴근하고 근처 카페에서 JPA 강의와 교재를 몇 번이고 정독했다.
그리고 마침내 변경할 수 있는 시간까지 얻었다.
그리고 단순 이전 작업이 아니라, 그 사이에서 조금이라도 더 효율적인 쿼리와 로직을 갖추고 싶어 리팩토링이라고 생각하고 진행했다.
그 생각덕에 클린코드와 리팩토링에 필요한 기법들에 더 관심을 갖게 됐다.
Querydsl
서브쿼리로 연결되어 있는 쿼리는 Querydsl 로 옮기기 정말 힘들었다.
그래서 전에 생각해뒀던 Native 로 라도 붙여볼까 고민했는데, Querydsl 로 깔끔하게 붙이고 싶은 마음을 포기할 수 없어서 쿼리를 바꾸기로 결정했다.
사내 기밀이라서 코드를 유출할 수는 없지만.. 서브쿼리에 Inner Join 과 Left Join 을 적절히 섞어서 최대한 풀어냈고 MySql 에서 자체적으로 제공하는 것들은 StringTemplete 을 활용해 풀어낼 수 있었다.
총 12개의 쿼리를 하루 하고도 반나절.. 정도 계속 노트에 그려보고 쿼리 짜보고 고민하면서 결국 다 풀었다.
(짜릿함 x 2147483647)
함수형 프로그래밍
그리고 그 과정에서 함수형 프로그래밍을 도입해서 리팩토링을 해봤다.
함수형 프로그래밍 관련해서는 오라클 유튜브에서 토비님이 강의하시는 내용을 보고 '와우'를 남발하다가 이건 무조건 적용한다는 마인드로 접근했다.
이것도 코드를 유출할 수는 없지만,,,,,, 한가지 예로
기존에 for 반복문을 활용해서 구현된 18줄 정도의 코드를 단 4줄로 압축시킬 수 있었고 코드가 줄었지만 오히려 가독성은 높아졌다.
시간을 표현하기 위해 0~23까지 Int 타입이 필요했는데 이를 IntStream 으로 대체했고 이후에는 map() 을 적용시켜 원하는 로직을 구현했다.
교훈
이 작업을 통해 최종적으로 얻은 교훈이 있다.
-
기술 자체에 큰 의미를 두지 말자. 원리를 이해해야 응용이 수월하다.
대학교를 졸업하면서 당장 회사에서 일을 해야한다는 생각에 프레임워크에 대한 공부와 말 그대로 기술을 어떻게 사용하는 지 그 방법에 집중했었는데, 실제로 개념을 아는 것은 너무나도 중요하다.
-
백엔드 개발자의 기본은 쿼리다.
당연히 DBA가 있다면 좋겠지만, 아무튼 백엔드 개발자의 기본은 쿼리라고 생각한다. 쿼리를 꼭 해야된다가 아니라, 쿼리를 잘 해야 결국에 그 도메인의 흐름을 파악하기 유리해서 아키텍쳐 설계까지도 영향을 끼칠 수 있는 것 같다. 물론 개발을 할 때에도 너무 유리하고!
-
생각보다 안되는 건 없으니 겁내지 말자.
만약 그 프레임워크에서, 혹은 그 라이브러리에서, 또 그 플러그인에서 "그 기능은 없습니다. 안됩니다." 라고 말한다면, 그냥 내가 만들면된다. 너무 간단하다. 나는 개발자고 목표한 기능을 구현하기 위해 다방면으로 노력하는 사람이지 주어진 기술을 그냥 블록 쌓는 이용만 하고 그 기술에서 안된다고 하면 '아 안되는구나' 생각할 사람이 아니다.
