개인사업자들의 매출을 볼 수 있는 App을 개발하면서 2차 개발은 1월에 들어갈 거 같아서 개발중인 프로젝트의 1차 개발이 끝나고나서 후기를 남기려고 한다.
네이버 클라우드 쿠버네티스 서비스로 배포했고 올라가있는 pod는 매출 api서버(nestjs) , auth서버(springboot) , van사에서 실시간으로 매출을 받아서 사용자에게 fcm을 보내주는 socket(nestjs) ,이전 데이터를 가지고 오는 schduler(nestjs)로 구성되어 있다.
devops , backend , deploy까지 프론트를 제외한 나머지 개발은 혼자서 해야 했고 처음 기획 문서만 봤을 때에는 어려운 문제가 없을 거라고 생각했었는데 그렇게 쉽게 개발한 거 같지는 않다.
갑자기 springboot
nice평가정보에서 휴대폰 번호 인증을 하는 방식에는 두가지가 있는데 nice평가정보 webview를 띄워서 사용자 인증하는 방식과 custom 화면으로 인증하는 방식 두가지가 있었는데 클라이언트가 custom 화면으로 인증하는 방식을 원했고 nice평가정보에서 custom 화면으로 인증할 때는 php , .net , java 세가지 방식으로 밖에 지원되지 않았다. 처음 공부했던 언어가 java이긴 했지만 인터프리터 언어에 너무 길들여져 있었고 java로 개발한지 너무 오랜 시간이 흘렀다. 가장 큰 문제는 vscode에 너무 익숙해져 있다 보니 springboot를 vscode로 개발할 수 있을까? 라는게 가장 큰 문제였고 flutter nodemon에 있는 live reload에 길들여져 있었기 떄문에 java를 하는 것 보다 vscode , docker 환경 , live reload 환경을 만드는게 일이었는데 구글링을 해도 원하는 방식으로 환경을 만드는 글들은 많이 없었고 여러 문서를 찾아가면서 환경 구성하는데에만 2~3일정도 소요됐던 거 같다.
(vscode docker springboot 글에 정리해뒀습니다.)
사용하는 api의 퍼포먼스
처음 했던 생각은 api가 있는데 굳이 테이블을 만들고 데이터를 담아둬야 할 일이 있을까 싶었고 사용자의 매출 데이터를 가지고 오는 api에서 생각보다 퍼포먼스가 굉장히.. 느렸다. 퍼포먼스는 적어도 request -> reponse가 떨어지기까지 0.3초 내에는 떨어져야 된다고 생각했는데 최소 1분 넘는 시간이 걸렸고 데이터가 많을 때는 10분 정도가 걸렸던 거 같다 여기서부터 모델링을 해서 데이터를 담아둬야 했고 생각에도 없었던 스케쥴러가 생겨야 됐고 각 매출별로 모델링을 해서 다 담아둬야 하는 상황이 생기면서 브릿지 정도로 구상했던 서버가 생각보다 커지고 스케쥴러가 생겨야 되고 trigger로 van에서 주는 데이터와 매출로 들어오는 데이터에 대한 값을 sync 시키고 매출값이 중복이 되었을 때 pk로 걸어놓은 키가 duplicate일 때 매번 update를 해주는 방식으로 데이터를 담았다.
늦게 시작된 실시간 매출
기획 문서에는 실시간 매출을 van사에서 줄거니까 우선 실시간 매출 먼저 개발했으면 좋겠다는 말이 지배적이었어서 데이터를 받는 작업 먼저 시작하려고 했었다. 하지만 van사와 협의가 늦어지면서 배포되기 3주 전에 socket 서버 개발에 들어가면서 시간적인 여유가 없다보니 심적으로 많이 초조했었던 거 같다.
아쉬운 점
springboot를 제외하고 나머지 서버들은 전부다 nestjs로 개발되어 있는데 가장 큰 문제는 공통으로 만들어놓은 schema , util , contants , models , enum들이 모든 폴더에 똑같이 들어가 있어야 했고 해당 폴더의 값이 하나라도 바뀌면 모든 폴더의 sync를 맞춰야 했는데 굉장히 귀찮은 일이었다. 방법은 찾을 수 있었는데 공통으로 된 파일들의 docker image로 만들어서 Dockerfile에 이미지를 받고 폴더를 복사해서 쓸 수는 있었지만 값이 하나라도 바뀌게 되면 image를 다시 만들어서 registry에 올리고 하는 일이 더 번거로울 거라고 판단해서 시도하지는 않았지만 협업하는 서버 개발자가 여러명이라면 과연...? 이 부분은 잘 모르겠다 확실한 건 여러명의 서버 개발자가 협업을 할 때는 좋은 방법은 아닌 거 같고 생각하는 방법은 두가지 있다.
현실적인 방법으로는 서버 개발자마다 프로젝트를 따로 관리 각 컨테이너 별로 pod를 생성해서 서비스를 운영하는 방법인데 이 방법으로 개발할 경우 개발자가 선호하는 언어나 프레임워크에 종속될 필요가 없기 때문에 기능마다 다르게 개발할 수 있고 공통된 부분을 개인이 관리할 수 있기 때문에 가장 현실적인 방법이지만 언어를 너무 dynamic하게 해서 개발하게 되면 유지보수 측면에서 다른 사람의 코드를 다시 전부다 읽어야 되는점이 많이 아쉬운 거 같고, 이상적인 방법으로는 golang으로 공통 부분만 따로 관리하고 module을 받아와서 하나의 공통으로 여러명의 개발자가 같이 사용하는 방법인데 유지보수 측면에서 가장 뛰어날 거라고 생각하지만 golang으로 서비스를 개발해본 적이 없고 개념만 알고 있기 때문에 현실적으로 가능한가... 라는 의문이 들기도 하고 아직 많이 아키텍처 설계하는 측변에서 부족하다는 생각이 든다.
