spring boot를 사용한 웹서비스 제작기

spring boot를 사용한 웹서비스 제작하기

이번에 Jambox 사이트를 개발하는 중에 경험한 정보들을 남겨 놓습니다.

spring boot를 사용한 것은 딱히 큰 이유가 아니라 java에 익숙하기 때문이며, node.js를 사용해보기 위해 수년 노력 해봤으나 javascript 사용의 불편함을 견딜수가 없었기 때문이기도 하다. 한가지 언어로 모두 다 할수 있기 때문에 편리한 것처럼 수많은 수식어를 붙여 설명할 수많은 글을 보았지만 직접 경험해본 바로는 callback지옥, 비동기의 불편함 등의 괴로움을 참아내기 힘들었다.

그렇다고 django, ruby on rails 등을 사용하여 간단한 사이트를 제작한 경험은 있으나 편리함 뒤에 숨겨진 자유롭지 못한 제약이 걸렸으며, 그렇다고 php나 다른 서버 스크립트는 생각하고 싶지도 않았기에 '아, 그냥 자바로'하는 느낌으로 spring boot가 채택되었다.

spring도 수년간 많은 변화를 겪었고, JpaRepository 같은 부분은 기존에 본인이 직접 구현하였던 수많은 것들을 의미없는 것으로 만들어놓을 정도로 편리하고 강력하다. 

사이트 제작에 사용한 모든 것들을 일일히 설명하기에는 어렵기에 간단하게 설명하자면,

Springboot, Lombok, Thymeleaf, 소셜로그인 연동을 위한 oAuth2, 사이트 접근 제어를 위한 spring security 등의 일반적인 라이브러리를 활용하였다.

oAuth2를 사용한 소셜 로그인 연동

소셜 로그인을 사용한 목적은 딱히 사용자의 민감한 데이터를 가지고 있고 싶지도 않았고, 로그인 연동 프로세스를 제작하기도 싫었기 때문이라는 이유가 가장 컸다. 사용자 입장에서 사이트를 방문할 때에도 소셜 로그인이 아닌 회원가입은 귀찮아서 하지 않게 되기도 했고, 그런 경험을 서비스 방문자들에게 주고 싶지도 않았다.

oAhth2를 사용하여 로그인 연동을 하는 것은 짧은 가이드를 잠깐 읽는 것으로 충분하고 spring security의 auth로 자동연동되기 때문에 아주 편리하나, 사이트마다 각각 데이터를 다른 형태로 수신하기 때문에 닉네임 하나 연동하는 것도 사이트 마다 뒤져야 할 장소가 틀리다. 그렇기 때문에 공통으로 상용할 user 모델을 하나 만들어서 활용하는 것이 편리하다. 

네이버의 네아로는 복수의 사이트를 하나의 앱으로 묶는 것이 불가능하므로, 로컬, 테스트서버, 실서버 등의 앱을 하나하나 설정해야 하고, 실서버 구동을 위해서는 인증을 받아야 하는 등 불편함이 가득하다. 만약 한달 전으로 돌아간다면 네이버 연동은 제거하고 싶을 정도이다.

DEV, PROD등 실행 프로파일을 분리하기

개발자 로컬서버, 테스트 서버, 서비스 서버마다 각각 다른 설정이 필요하기 때문에 프로파일을 분리하여 만드는 것이 편리하다.

springboot에서 별다른 설정은 필요하지 않았고, application.properties, application-dev.properties 등으로 분리시키고, 

실행옵션으로  -Dspring.profiles.active=dev 넘겨주기만 하면 해당 프로파일로 실행된다.

intellij를 사용하는 경우 Edit Configurations를 선택하여 해당 실행 모듈의 설정에서 VM options으로 설정하는 것으로 설정된 프로파일로 실행된다.

개발 서버에 수정 내용을 적용하는 방법에 대하여..

의존 라이브러리를 포함한 jar 패키지를 사용하는 방법은 빌드된 jar파일을 jar -j 파일명으로 실행만 하면 되기에 간편하다. 하지만 추천하고 싶지 않다,

우선 빌드 시간이다. 빌드가 수행되는 동안 높은 자원 점유율과 시간으로 개발자를 피곤하게 만든다. 또, 귀찮은 절차도 추천하고 싶지 않은 이유중 하나이다.

빌드하고 빌드한 파일을 옮기고 해당 서버에서 프로세스를 죽이고, jar를 실행하고..

그럼 어떤 방법이 나을까..

git을 사용하는 방법을 추천한다. 아무리 소규모 개발 그룹이라고 하더라도 형상관리 버전관리 등의 이유로 git을 사용할 이유는 충분하다. 이젠 사용하지 않는 것이 이상할 정도로 편리하다.

git commit, push된 파일들을 git pull로 서버에서 내려받고

gradle build

gradle bootrun

정도로 충분히 편리하게 사용할 수 있다.

intellij 의 문제인지 gradle로 jar빌드에 걸리는 시간은 무지막지 했으며, 차라리 사양이 훨씬 낮은 서버에서 build하는 것이 더 빨랐다. 또한 잦은 변경시 주고 받는 파일의 용량도 git으로 줄어들기에 여러가지 면에서 소요되는 시간과 스트레스를 줄이게 되었다.

Thymeleaf

Thymeleaf는 그것만으로도 강력하다. 또한, layout을 위해 thymeleaf-layout-dialect, spring security와의 연동을 위해 thymeleaf-extras-springsecurity4 등을 사용하면 더 편리해진다. 다소의 시간이 소요되겠지만 layout-dialect는 반드시 먼저 익히고 시작하도록 하자. 아주 쉽게 사용할 수 있고 그다지 복잡한 기능을 포함하지는 않고 있기 때문에 오랜 시간이 필요한 것은 아니다. 

Spring Security

로그인이 필요한 서비스를 제작하거나 관리자 페이지를 제작할 때에 security 설정을 풀어놓고 개발하는 것보다는 session timeout을 길게 하고 서버 재시작 등에서도 세션이 유지되도록 store-type을 jdbc로 하는 등 영속성을 유지할 수 있도록 하는 것이 더 편리하고 안전하다고 생각된다.

Devtools

개발중 hotdeploy를 위해 spring tools에서 제공하는 devtools를 사용했는데, 그닥 좋지가 않다. 매번 리스타트를 하고 설명으로는 coldrestart보다는 이게 빠르다고는 하는데(훨씬 이라는 표현이 있었지만) 그닥 빠르지 않으며, 내 잘못인지 그냥 콜드리스타트가 반복되는 것 같은 기분이다. 도저히 참지 못하고 jrebel을 사용해봤으나 이것도 여러가지 문제가 있어서 다른 해결책을 찾는 중이다. 하지만 devtools보다는 나은것 같다.

이상으로 부분별로 고려하면 좋을 만한 단락적인 정보들을 언급하는 정도로 정리하고 다음에 기회가 된다면, 좀더 기초적인 내용들과 구체적인 내용들을 소개하도록 하겠습니다