실전프로젝트를 진행하며...
실전프로젝트 3주차가 지났다.
비교적 백엔드의 기능 구현이 프론트엔드보다 빠른편이라 우리팀 백엔드는 3주차 스코프에 해당하는 기능을 구현하며 종종 코드리뷰를 진행했다.
전체적인 코드 스타일을 맞춰가며 왜 이러한 코드를 썼는지, 왜 이렇게 예외처리를 했는지 등등을 이야기 하며 정말 많이 배울 수 있는 시간이었다.
개인적으로 어떻게 하면 데이터를 빠르면서 정확하게 가져올 수 있을까에 대해 고민이 많은데, 중간발표를 마치고 그동안 고민하던 QueryDSL을 적용해보기로 결심했다.
사실 처음부터 나는 QueryDSL을 꼭 프로젝트에 적용해보고 싶다고 생각하고 있었는데, 우리 프로젝트에서는 검색기능도 없고(앞으로 도입할지도 모르지만), 생각만큼 복잡한 쿼리를 쓰지 않을 것 같아 팀원들은 꼭 그걸 써야하냐며 회의적인 시각을 가지고 있었다.
그런데 프로젝트를 진행하며 내가 담당 기능 부분에서 이러저러한 조건으로 데이터를 찾아와야하는 일이 발생했고, 페이징 기능까지 함께 구현하려니 쿼리가 길어지고 복잡해져서 QueryDSL을 도입을 위해 팀원들을 설득해봐야지 생각하고 있었다.
그때마침 중간발표회에서 시니어 멘토님이 네이티브 쿼리보다는 QueryDSL을 쓰는 것이 좋다, Repository에 네이티브 쿼리(&JPQL)이 너무 많이 사용된다.고 피드백을 주셔서 팀원들과 다시한번 이에 대해 이야기 해보려고 한다.
개인적으로 3주차에 좀 더 많은 기술을 다루고 싶었는데, 그러지 못해 아쉬웠다.
토요일에 진행된 중간 발표회에서도 시니어 멘토님의 예리하면서도 공부해두었어야 할 질문들에 대답을 잘 하지 못한 것도 아쉬움이 많다.
나름대로 왜 기술을 써야 하는지, 왜 이렇게 코드를 짰는지 고민하며 프로젝트를 진행하고 있다고 생각했는데 막상 설명하려니 제대로 설명하기가 어려웠다.
게다가 꼬리에 꼬리를 무는 질문의 향연... 제대로 대답하지 못해 참 부끄러웠지만, 많이 느끼고 배울 수 있었다.
그리고 다시금 불타오르기 시작했다. 프로젝트 힘내자 힘!! 설연휴 끝나고 다시 달리는 거다!!!🔥
프로젝트에 도입한 기술들
Github Actions CI/CD
지난번 클론코딩에서 매번 File Zila를 이용해 서버를 배포해야해서 정말 번거롭다고 생각했었고, 이번 실전 프로젝트에서는 초반부터 꼭 자동배포를 도입하고 싶다고 생각했다.
기술적으로 여러 대안들이 있었지만, 깃허브에서 빌드과정을 확인하기 쉬우면서 서버를 따로 사용할 필요가 없고, 비교적 설정이 쉬운 Github Actions을 사용하기로 했다.
CI/CD에 대해서 워낙에 잘 정리해둔 블로그들이 많아서 설정 자체는 어렵지 않았다.
코드를 특정 브랜치에 pull request 하는 것만으로도 자동으로 jar 파일을 만들어 배포할 수 있어, 일일히 빌드하고 파일을 교체해주는 번거로운 작업을 하지 않아도 되니 절약한 시간은 개발에 더 집중할 수 있게 되었다.
그리고 CI/CD를 통한 빌드 결과를 깃허브를 통해 별도로 확인하는 번거로움을 줄이고, 편히 확인하기 위해 슬랙과 연동하여 팀 워크스페이스에서 확인하도록 하고 있다.
sentry, Slack Web hook
모두가 알듯이 배포한 서버의 로그를 확인하기란 쉽지않다.
테스트를 거치고 배포하더라도 개발중엔 어떠한 에러가 일어날지 모르는데 어떻게 해야 로그를 확인할 수 있을까? 고민하던 중 sentry를 알게 되었다.
적용법도 쉬워서 금방 프로젝트에 적용하고 사용했다.
에러 메세지 외에도 여러 정보를 확인할 수 있어서 유용하게 활용하고 있었는데, 알고보니 팀원들이 함께 이용하려면 비지니스 버전을 구매해서 사용해야 했다.
그래서 sentry 외에 다른 대안이 없을까 알아보던 중, slack web hook을 알게 되었다.
슬랙에 연동하여 로그를 실시간으로 확인할 수 있어 팀 워크스페이스에 적용하면 딱이겠다 싶어 바로 적용하여 slack으로 실시간 로그를 확인하고 있다.
팀 워크스페이스를 만들어두니 빌드 결과, 에러 로그를 함께 확인할 수 있어 활용도 만점이다!!
소셜로그인(네이버)
우리 프로젝트는 힙합 콘텐츠를 보다 많은 사람들이 즐길 수 있도록 장벽을 낮추고 싶다는 것을 목표로 진행중이다.
그래서 회원가입에 소셜로그인을 도입하여 보다 편하게 회원가입할 수 있도록 했다.
많은 소셜로그인 중에서도 한국인들이 보편적으로 편하게 사용하는 카카오와 네이버를 도입했다.
나는 둘중에서 네이버 로그인을 담당했는데, 카카오와 달리 네이버는 이런저런 조건이 세세하게 정해져있어 생각보다 번거로웠다.
로그인 코드를 구현하는 것 자체는 어렵지 않았는데, 개발자센터에 등록할 수 있는 서비스 Url을 하나밖에 등록할 수 없고, 실제 서비스에 적용하여 모든 사람들이 사용할 수 있게 하려면 사전에 검수요청을 해야하는 번거로움들이 존재했다.(그래서 사람들이 네이버보단 카카오 로그인을 많이 구현하나...?)
그런 점들은 불편했지만, 한편으로는 카카오보다 이런면에서는 구현하기 좋았다.
카카오는 사용자의 이메일이나 프로필 사진등의 정보를 사용자의 선택에 의해서 받아올 수 있도록 하고 있는데, 네이버는 개발자가 필수값으로 지정할 수 있어, 우리 서비스에서 필수로 하는 값이 없을 때의 예외처리가 간편하다는 장점이 있었다.
소셜 로그인은 이번에 처음 사용해보았는데, 사용자도 회원가입/로그인이 간편하고 개발자의 입장에서는 사용자에게 직접 개인정보를 입력받는 것이 아니기 때문에 보안성을 향상시킬 수 있어 활용하길 잘 했다고 생각한다!!
앞으로 도입하고 싶은 기술
앞으로는 아래와 같은 기술을 우리 프로젝트에 적용하고 싶다.
현재 우리 프로젝트에 어떤 것을 빨리 도입해야할지 우선순위를 잘 정해서 하나씩 적용해 나가고 싶다.
아직 프론트엔드의 기능 구현이 반정도 밖에 진행되지 않지만, 빠르게 기능 구현을 끝내고 리팩토링을 통한 최적화에 시간을 많이 투자하고 싶다.
- @Dynamicupdate
- QueryDSL
- Nginx : 무중단 배포
- AWS Lambda : 동영상 업로드 최적화
- Redis : 데이터 캐싱
충분히 할일이 넘치는데, 이것도 해보고 싶고 저것도 해보고 싶고...😅
