웹개발 플로우?

트래픽 제어를 주제로 한 프로젝트는 어떻게 보면 웹개발의 시작보다는 웹개발의 유지보수와 확장에 더 가까운 프로젝트였다. 프론트엔드와의 소통과 협업적인 측면에 비추었을 때, 전체적인 웹개발은 결국 기획 내용을 전달받아 처음부터 구현을 하며 플로우를 익히는 점이 중요하다 생각했고 나는 아직 그 부분(과 더불어 백엔드 전반에 대한 개념)이 많이 부족하다 느꼈다.

마침 생각이 비슷한 프론트엔드 공부하시는 분이 있었고, 그분이랑 합을 맞춰서 간단한 웹 앱 프레임을 구축해보면서 전반적인 웹개발 플로우를 익히면서 포폴 쌓는 것을 목표로, 그리고 그 과정을 기록으로 남기는 것을 부수적인 목표로 삼았다.

웹 앱의 디폴트 기능

웹개발을 통해 구축되는 서비스들을 둘러보면서 느꼈던 점은, 웬만한 웹 앱은 디폴트 기능을 바탕으로 추가적인 것들을 덧붙이면서 서비스를 구축한다는 생각이 들었다. 그래서 어떤 디폴트 기능이 있을까 고민했다. 그리고 내린 나름의 결론은 회원기능, 그리고 CRUD였다.

1. 전체 세팅

자바를 공부하고 스프링을 연습했으니 당연히 스프링 써야지! 라는 마인드가 매우 강했지만, 그래도 사용하는 기술에 대한 근거를 마련하는 것이 중요하다고 여러 프로젝트를 거치며 느꼈기 때문에 설령 순서가 역전돼도 근거는 꼭 정리하고 진입해야지.

(1) Java

백엔드를 공부하며 접했던 언어. 그리고 타입 안정성과 객체지향에 대해 심히 고민하게 만든 주범 중 하나다. 개인적으로 객체지향의 꽃은 유지보수에 있어 최소한 덜 건드리고 확장에 있어 개방적인 특성을 살리는 것이라고 생각한다. 자바 기반 웹 개발 프레임워크인 Springboot를 통해 개발할 예정인데 자바의 특징들을 최대한 발휘하면서 개발해보고 싶다.

(2) PostgreSQL

정말 단순하게도 이제까지 써왔던 SQL이 MySQL이니까 다른 SQL도 접해보자가 주 이유였다. 물론 저 이유만은 아니지만 러닝 커브 대비 MySQL에 비해 상당히 높은 성능을 발휘해주는 SQL 언어고, ORM 기반 개발을 수행할 거여서 쿼리문에 직접적인 구애를 받는 일이 많지 않은 점을 근거로 삼았다.

(3) redis

주 데이터베이스는 PostgreSQL 기반 관계형 DB지만, 빠른 입출력 및 잦은 조회에 있어서는 메모리 기반으로 더 좋은 성능을 선보이는 redis를 추가적으로 채택할 예정이다. 마침 구현 예정인 웹 앱의 디폴트 기능 중 회원기능에서의 토큰 처리 및 재발급 과정에서 트래픽에 가까운 조회 및 수정 작업이 발생할 것으로 가정할 수 있어서 도입을 결정했다.

(4) Docker

자바 및 스프링부트를 제외한 DB 관련 툴 2가지는 내 로컬에 세팅되어있지 않다. 즉, 원래였으면 설치하고 세팅 환경 맞추는 과정이 필수일 테고 이것이 만약 협업의 과정까지 나아가면 각자의 운영 환경에 맞추는 과정까지 첨가될 것이다. 단순한 스터디 프로젝트지만 저 PostgreSQL과 redis를 내 로컬에 세팅하는 것이 아닌, 도커의 이미지를 기반으로 pull 받아서 컨테이너를 기반으로 앱을 시동해보고 배포 환경에서의 응용까지 나아가볼 예정.

2. 회원기능

회원기능을 구현하는 과정은 정말 다양하며 정답이 존재하지 않는다. 정확히는 사용자를 인증하는 기능이라고 하는 것이 옳을 듯하다. 다양한 방법을 접하는 것도 좋지만 보편적이면서도 효율적인 방향을 추구하는 것이 좋다고 생각했다.

(1) JWT

세션을 기반으로 인증하는 방식은 서버가 주도권을 강력하게 쥐지만, 그만큼 서버에 가해지는 부담이 늘어난다. 서버에 부담이 늘어나는 것은 확장성에 있어 불리하게 작용할 여지가 크고 자바를 선택한 취지 중 하나인 객체지향의 확장성 활용에 있어 모순이라는 점 때문에 세션이 아닌 JWT로 마음이 더 기울었다.

JWT를 활용해보고 싶은 이유 중 다른 하나는, 리프레쉬 토큰의 구현이었다. 과제나 이전 프로젝트에서는 엑세스 토큰까지만 나아갔는데 토큰의 유효기간 만료로 인한 재발급, 사전 처리로 인한 토큰의 블랙리스트 처리 등의 여러 예외 처리에 대한 고민을 거듭할 수 있다는 부분이 나름 매력적(?)이었다.

(2) Spring Security

당연히 자바 스프링부트를 기반으로 개발하니 스프링 시큐리티지! 라고 하기에는 옛말이고... 스프링 시큐리티를 좀 더 활용해보고자 하는 마음이 더 컸다. 위에서 언급한 redis를 기반으로 토큰 처리 및 유효성 검증 커스터마이징, 재발급 등의 절차를 DispatcherServlet을 지나기 전인 필터 단위에서 처리하는 것이 옳다고 생각했고 마침 스프링 시큐리티는 필터단에서의 인증을 위한 여러 도구들을 제공했다.

3. CRUD

게시글의 작성, 조회, 수정, 삭제는 웬만한 웹 앱이 기본적으로 갖고 있는 기능 중 하나다. 단순하게 게시판을 만드는 것을 넘어서 이미지 처리, 댓글 및 좋아요 구현 등의 다양한 기능을 확장해서 나아갈 수 있다.

일기를 작성하는 현재는 회원기능 구현 및 배포에 집중하는 시점이어서 상세한 API 명세를 작성하진 않았지만, 스터디의 목적이 웹 개발에 대한 전반적인 플로우를 익히는 것이고 그 과정에서 API 명세가 곁들어지는 것이므로 향후 추가로 아이디어가 구현되면 작성 및 보완할 예정.