스낵커 개발 회고

입사를 하고 신규 프로젝트를 시작하게 되었다. 언어선택부터 모든 결정을 신입 개발자인 내가 주도했다. 이전 회사는 할당되는 부분만 개발하면 되었었기에 시작 당시에는 꽤나 낭만이었다.

모든 것이 새롭다

언어는 JAVA 17

LTS 버전중에 8, 11, 17 중에 8버전은 가장 오랜기간 지원하지만 새로운 코드들에 대하여 호환성이 낮을거 같고 11버전은 가장 짧은 지원이라 17버전은 8버전보다 지원기간이 크게 차이나지 않았고 개선된 함수사용과 최신 기술 적용 가능성을 고려하여 채택되었다.
개발하는 과정에서 호환성 이슈는 거의 없었다고 봐도 무방할 정도로 무난했다.

Docker를 통한 개발 환경 구축

이전 프로젝트에서 그대로 가져온 기술 중 하나이다. 입사 전부터 매력적인 기술스택이라서 공부한 것이 도움이 되었다.
테스트 환경에서는 h2를 사용하지 않고 빠르게 적용할 수 있다는 장점이 있고 쿼리문을 따로 관리하지 않아도 된다.
운영 환경에서는 버전관리가 쉽다는 장점이 있었다.

만능 JPA

이전에서 데이터베이스 중심의 개발을 하다보니 제일 부딪혔던 부분이다. 개발의 용이성까지 고려하여 FK가 아닌 간접참조 애트리뷰트만 접하다보니 FK의 중요성을 알지만 개발하는 과정에서 테이블 구조변화에 따른 수정이 불편하다보니 나와 나자신의 싸움이 컸다.
"그래프 탐색의 용이함 vs 나의 쿼리작성 실력과 로직 설계로 커버"의 논쟁이 설득에 설득으로 이어져 갔었다. 그래서 적용을 한 부분도 있었고 아닌 부분도 있었는데 아무리 비교를 해도 결론을 낼 수가 없어서 일단 내가 기존에 접한 방식을 레거시라고 생각하고 좀 더 객체지향적 프로그래밍을 하기위해 JPA를 내 것으로 만들려고 열심히 노력했다.

편안한 MySql

새로운 것 중에 가장 잘 아는 것이다. 이전 회사에서 Oracle로 수많은 쿼리문을 작성하다보니 쿼리문만큼은 같은 연차에서 뒤지지않을 만큼 자신이 있었다. MySql과 큰 문법차이가 없고 JPA나 QueryDsl를 이용하게 되면 단순한 함수들 밖에 사용하지 못한다.
운영 배포이후 다양한 쿼리문으로 오류를 수정하였다.

나의 첫 NoSql은 Redis

JWT를 이용한 토큰 인증 방식의 서버였고 토큰은 Redis에 저장되는 구조로 개발을 했다. 사용하는데에는 일반 DB와 차이가 없다보니 깊이 파고들지는 않았다.

나의 우매함 Batch

이전 프로젝트에서 그대로 가져왔는데 기술블로그들을 찾아보니 Schduler에 로직만 추가한 구조였다. Batch를 제대로 돌렸을 때 생성된 테이블 9개가 생성되고 나서야 잘못됨을 알게 되었다. 그래서 tasklet 형식의 전환 작업을 진행했으나 전체 적용하지는 않았다.

클라우드 서비스는 역시 AWS

클라우드 서비스의 편하고 테스트용 서버로 여러개 늘렸는데 비용부담이 크지않아서 마음껏 사용했다. 물리 서버는 단점밖에 안보인다. 비용이라는 가장 큰 장점이 모든 것을 압도한다.

그 외에는 짧아서 생략

Open API, Junit, RabbitMQ, JIB, GitHub Action 등이 있다.

후기

새로운 것들이 하나하나 내 것이 되면서 속도가 붙고 자신감이 붙었고 최대로 오를때 쯤 Batch가 나를 다잡아주었다.
코드리뷰를 하다보니 로직을 짜는 능력에 비해 꼼꼼함이 부족했던 것 같다.
서비스를 시작하고 더 부족한 부분들이 보였었는데 그 부분들을 보완하면서 서비스도 나도 완성을 해나갔던것 같다.