서론 사내 프로젝트(이하 P)에서는 외부 솔루션을 이용한 관리 시스템(이하 K)과 연동하여 동작하고 있다. 관리의 편의성을 위해서 P는 K와 별도로 데이터베이스를 운영하고 있고(K에서 유지할 필요가 없는 P 만의 데이터 등) K는 P 말고도 다른 프로젝트들과 연동하고

SimpleBBS를 Vue.js와 Nuxt.js, Node.js 백엔드 프레임워크(미정)로 기술 스택을 변경해보기로 결정했다. 얼마나 걸릴지는 모르겠지만 일단 Vue.js 기초부터 계속 학습하고 그러면서 자바스크립트도 다시 복습하려고 한다. 학습 내용 생명주기 Spri

이번 포스트도 '배포'가 아닌 '개발'이다. 오랜만의 개발 기록인데 가장 큰 변화는 JWT를 걷어내고 Spring Session 프로젝트를 적용한 것이다. 그 외에는 데브코스에서 팀원끼리 진행하던 클린 아키텍처 스터디를 참고하여 애플리케이션 구조를 변경한 것, 잠금 상

예전에 작성했던 포스트에 달린 댓글에서 고민했던 부분은 지난 기술 면접을 통해 JWT를 걷어내고 세션으로 돌아가자고 결정하게 되었다. 그러면서 경험한 내용을 적어보고자 한다.JWT 대신 세션을 사용하려는 이유는 이전 포스트에서 여러번 언급했으니 더 이상 적을 필요는 없

최종 프로젝트랑 이런저런 일 때문에 Vue.js 학습이 많이 게을러졌다. Java + Spring 스택도 중요하지만 JavaScript + Node.js 스택도 필요할 것 같아서 다시 자바스크립트 공부도 시작해야 하는데 일단 계속 미루던 프론트엔드 페이지 구현부터 다시

SimpleBBS 이후 JWT의 존재를 알게 되면서 API 애플리케이션의 인증 방식으로 Stateless한 토큰 방식 인증을 사용하면 확장성이나 인증 측면에서 더 간편하고 좋다! 라는 미신(?)에 빠져있었다. JWT의 장점이라고 알려진 무상태성으로 인한 확장성, 불필요

MySQL, MariaDB 같은 RDBMS만 써보다가 Redis, MongoDB 같은 NoSQL도 알게 된 이후로 언제 두 종류의 데이터베이스를 적절히 사용해야 하는지 평소에도 궁금했었다.흔히 들을 수 있는 얘기는 정규화된 고정된 형태(스키마)의 데이터를 저장할 때는

서론 나는 프로젝트를 진행하면서 관계형 데이터베이스 테이블을 작성하는 경우 대부분 정수 식별자를 PK로 사용했다. 특별한 이유가 있는 것은 아니지만 간단하고 AUTO INCREMENT 가 가능하며 익숙하기 때문에 활용하곤 하는데 지난번 면접에서 들었던 얘기가 생각나서

이번에 모 기업에 지원해서 과제 테스트를 수행했다. 기능은 완성했지만 과제의 품질을 위해 테스트 코드를 작성했는데 이상하게 애플리케이션 실행 중에는 정상적으로 동작하던 기능이 테스트 코드에서는 제대로 동작하지 않았다.해당 기능은 일대다 연관관계의 엔티티를 저장하는 기능

본 내용은 Spring Boot 2.x의 Jackson을 기반으로 작성하였다.나는 API 응답 클래스를 getter 메서드와 final 필드의 조합으로 작성하는 편이다.이 경우 한 번 생성한 응답이 중간에 실수로라도 변경될 일이 없고 어떤 데이터를 표현한다는 목적 자체

Spring Security를 적용해서 HTTP 요청에 대해 인증 및 인가를 적용할 경우 시큐리티 필터 체인에 의해 인증 여부나 인가 여부에 따라 요청이 수락되거나 거절된다. 그런데 필터 체인 특성상 이런 Spring Security에 의한 차단은 서블릿 필터 단계에

이전의 개인 프로젝트나 데브코스에서 진행했던 팀 프로젝트나 최근 진행한 프로젝트, 그리고 앞으로도 진행할 프로젝트는 JWT를 활용한 Stateless 한 인증 방식이 주가 될 것 같다. 그래서 처음에 구현할 때는 인터넷에서 관련 예제를 받아서 따라해보면서 적용하는 방식

\[문제 비공개]문제에선 주어지지 않았지만 날짜 데이터가 중복되지 않는다고 가정했기 때문에 마지막의 COUNT(\*) >= 3 으로 3일치를 뽑아낼 수 있었던 것 같다.

\[문제 비공개]여기서부터 조금 헷갈려서 주석을 쓰면서 풀기 시작했던 것 같다. 생각했던 대로 안 풀려서 조금 당황했는데 놓쳤던 부분은 모든 화로가 작동중인데 주문이 여러 개 들어왔다면 화로의 요리가 끝나는 대로 주문들을 즉시 처리해야 한다는 점이다.당연한 요구사항이고

\[문제 비공개]보드의 크기도 작고 요구사항도 어렵지 않아서 금방 풀 수 있는 문제였다. 중간에 계속 무한 루프가 나와서 왜 그런가 했는데 "\*"을 만났을 때 처리해야 하는 로직에서 놓친 부분(height++)이 있었기 때문이었다. 이것 때문에 시간을 좀 잡아먹어서

보일러플레이트 메서드(getter/setter, constructor 등)를 직접 작성하지 않아도 대신 작성해주는 Lombok를 최근에 많이 활용하고 있다. 그나마 setter 메서드같은 경우는 값을 변경시키는 메서드는 그 목적을 알 수 있도록 명명하라는 조언에 따라

이전 포스트에서 SimpleTodoList 같은 API 애플리케이션만 만들다보니 정작 화면 설계가 안되서 어떤 식으로 API를 개발해야 할 지 잘 모르겠다고 언급했었다. 그리고 이번에 OAuth 기능까지 적용하면서 리디렉션 때문에 정말 절실하게 프론트엔드 페이지가 필요

서론 인증, 인가가 필요한 애플리케이션에서 자신을 인증하는 가장 기본적인 방법은 해당 서비스에 가입하는 것이다. 그래서 아이디, 비밀번호, 이름, 생년월일 등을 입력하기도 하고 좀 더 인증이 중요한 서비스의 경우 주민번호, 휴대전화 인증 등을 요구하기도 한다. 그러나

이번에 SimpleTodoList에 Redis를 적용하면서 처음으로 NoSQL을 사용해볼 수 있었다. 그동안 들어본 이야기로는 NoSQL이 SQL, 즉 RDB에 비해서 월등히 빠르다는 장점이 있다는데 이를 직접 입증하기란 쉽지 않았다(데이터 셋, 환경, 메트릭 등).그

개인 프로젝트 중 JWT를 사용하는 SimpleTodoList 에서는 회원가입 후 로그인 시 아래처럼 JWT를 발급해준다.이 토큰은 애플리케이션 전반에서 사용자를 인증하는데 사용된다. 기존의 세션과는 달리 다양한 플랫폼에서 토큰만으로 인증할 수 있다는 장점이 있어 유용