개발과 일상

이전 글에선 JWT 검증 코드를 인터셉터에 적용해봤다. 이번 글에선 Filter에 적용해보자. 먼저 가볍게 Filter에 대해 짚고 넘어가보자. Filter는 Interceptor와 다르게 Dispatcher Servlet이 동작하기 이전에 위치한다. 그리고 별도의 필터에 대한 설정이 없으면 모든 요청에 대해서 반드시 한번 실행이 된다. 때문에 인터셉터보다는 더 범용적이고, 한번은 무조건 타야하는 보안, 인증/인가 작업이 주로 Filter에서 이뤄지게 된다. 흔히 알고 있는 스프링 시큐리티의 필터 체인들이 여기서 수행된다. Filter는 별도의 설정없이 Filter 인터페이스만 implements해도 요청이 들어올 때마다 실행되기 때문에 구현은 비교적 간단하다. 구현 여기서부터 등장할 jwt 관련 코드는..

이전 글에서 JWT가 무엇이고 어떤 데이터를 실어서 보낼 수 있나를 알아봤다. 그럼 이번 글부터는 어떻게 적용하면 될지 알아보자. 이번 글에서 소개할 방식은 interceptor에 적용하는 방식이다. interceptor는 스프링에서 제공하는 컨트롤러 이전에 위치하는 공통처리부 중 하나이다. 아래 그림을 확인하면 편하다. 공통처리부에 관한 글을 예전에 썼었는데, 이 때는 스프링 MVC를 쓰던 시절이라 필터와 인터셉터를 xml에서 제어를 하도록 구성되어 있었다. (왜 썼는지, 어떤 역할을 하는지 보다 이런게 있다라고 정리한 글이었다) 여기서 추가적으로 간단하게 짚고 넘어가면, Interceptor는 스프링 내부에서 Dispatcher Servlet 이후에 동작한다. 컨트롤러 앞단에 위치해 요청과 응답을 간..

오랜만에 글을 쓴다. 9월에도 다양한 작업을 했지만, 새 서비스 런칭을 준비하면서 인증관련 작업을 할 일이 생겼다. 세션을 써야할까 JWT를 써야할까 고민하다가, 앞으로의 확장성과 러닝커브 등의 이유로 JWT를 선택했다. (서비스가 언젠가 MSA로 확장될 가능성이 있었다.) JWT를 적용하기 위한 방법으로는 크게 두 가지가 있었다. 1. filter에 적용 2. interceptor에 적용 기존 서비스는 interceptor에 적용되어 있었고, 이번 서비스에서는 filter+스프링시큐리티를 적용해봤다. 각각의 방범의 장단점이 있는데, 이 부분들은 차차 정리하도록 하고 이번 글에선 JWT에 대해서 알아보려고 한다. 1. JWT란? JSON 웹 토큰 (JSON Web Token, JWT)은 선택적 서명 및 ..

최근에 여러 일이 겹쳐 오랜만에 포스팅한다. 현재 담당하고 서비스의 개발은 대부분 RDB를 사용한다. 때문에 NoSQL DB를 접할 일이 많이 없었다. 이번에 이벤트성으로 개발할 일이 생겼는데, 이 개발에는 AWS DynamoDB를 사용해보자고 했다. 선택에는 별 다른 이유는 없었는데, 이벤트성 사용하고 치울 데이터를 메인 RDB에 저장할 필요가 없다고 느껴서였다. 그러나 저런 단순한 이유를 차치하더라도, AWS DynamoDB는 충분히 좋은 DB이다. 어떤 특성이 있는지 알아보자. DynamoDB란? Amazon DynamoDB는 키 값과 문서 데이터 모델을 지원하는 서버리스 NoSQL 데이터베이스 서비스의 일종입니다. 개발자는 Amazon DynamoDB를 사용하여 소규모로 시작하여 전 세계로 규모를..

이전 글에서는 QueryDSL을 왜 도입하려했는지, 왜 선택했는지 다른 툴과 비교 분석을 해봤다. 이번 글은 스프링부트에 어떻게 설치하고 사용할지 작성해보려 한다. build.gradle plugins { id 'com.ewerk.gradle.plugins.querydsl' version '1.0.10' ... } dependencies { implementation "com.querydsl:querydsl-jpa:5.0.0" implementation "com.querydsl:querydsl-apt:5.0.0" ... } def querydslDir = "$buildDir/generated/querydsl" querydsl { jpa = true querydslSourcesDir = querydslDi..

SI 회사에서 일할 무렵엔 항상 MyBatis만 사용했었다.(생각해보니 현재 기준으로 반년도 안지났다.) JPA를 사용하자고, 사용해보자고 자주 이야기했지만 결국 도입에 실패했던 기억이 있다. ㅠ 그런데 이직한 곳도 막 서비스가 런칭한지 얼마 안됐음에도 MyBatis를 쓰고 있었다. 하지만 여긴 JPA 도입을 권장해줘서 JPA를 사용해볼 수 있었는데,  사용하면서 마음에 들지 않는 부분들이 보이기 시작했다. 가장 큰 문제점이라 생각하는건 쿼리가 복잡해지면 JPQL이란걸 사용해야 했다. 아래는 JPQL의 예시다.public interface HistoryRepository extends JpaRepository { @Query("SELECT h FROM UserActivity h WHERE h.tim..

이전 글에서 사용했던 Cosine Search는 dense vector 하나만을 이용한 방법이었다. 그래서 내가 조금 더 다양한 정보를 갖고 있을 때, 이를 전부 활용하기 어렵다는 단점이 있다. 예를 들어, 내가 알고 있는게 게시물의 제목, 내용, 작성자, 작성 시간 등 몇 가지의 정보가 있음에도 게시물의 제목만 활용할 수 있다는 것이다. 모든 내용을 한문장에 섞어서 하나의 벡터화를 할 수도 있겠지만, 이럴 경우 엄밀히 말하면 각각을 비교한 결과가 아니게 된다. 이렇게 다양한 정보를 활용하기 위해서 Elasticsearch에서는 K-NN search 기능을 제공한다. 이를 이용해 검색 기능을 Springboot로 구현해봤다. 대략적인 구현은 cosine search에서 구현한 방식을 따라가려고 한다. 그..

아래는 한 서비스에서 쓰고 있는 application.yaml 파일이다. 위와 같이 길어진 이유는 서버의 종류가 엄청 많기 때문이다. 서버가 local/dev/stag/qa/prod 외에도 스케줄러가 붙어있어서 7~8개의 profile이 한 yml파일에 존재하게 됐다. 각각 서버의 profile은 아래와 같이 분리해서 application.yml 파일에 설정한다. ### ### ### local ### ### --- spring: config: activate: on-profile: local 나눠 놓을 수는 것 까지는 좋다. 그런데 관리를 제대로 하지 않았다. 그래서 모든 서버에서 공통적으로 사용하는 부분을 분리하지 않아서 yaml 파일이 엄청나게 길어지게 된 것이다. 이런 식으로 보관하면, 모든 서버..