프로그래머스 데브코스 백엔드 엔지니어링 과정에 참여한 지 어느덧 2개월이 넘었고, 1차 프로젝트가 끝남과 동시에 1차 스프린트도 끝이 났다. 벌써 데브코스의 반이 지나갔지만 허무하게 소비한 시간도 있고 알뜰하게 사용한 시간도 있었다. 그럼 이제 하나하나씩 풀어보도록 하겠다. 시작처음 데브코스에 합격하고 쉰 시간만큼 열심히 해야겠다고 다짐했다. 하지만 수업은 9 to 6를 모두 온라인으로 진행하다 보니 집중력이 부족해지는 경우가 많았다. 또 초반에는 기초반과 숙련자 반으로 나누어서 기초반은 수업을 듣고 숙련자들은 따로 과제를 주는 방식으로 진행되었다. 나는 과제를 풀면서 평소에 깊게 공부하지 못한 자바의 GC나 Virture Thread의 정의뿐만 아니라 사용하는 이유 등 자바를 깊게 공부하는 시간을 가졌..

팀이나 프로젝트마다 각각의 공통된 Response(이하 응답이라 칭하겠다) 형식을 정하곤 한다. 그렇지 않으면 클라이언트 입장에서는 API 마다 응답 형식이 다 달라 혼란을 야기할 수 있다. 그래서 이번엔 나의 첫 번째 프로젝트인 쪼잉에 공통 응답을 정해서 처리해 보도록 하겠다. 현재 코드의 상황 현재 나의 코드는 아래와 같다. HttpStatus를 넘기기 위해 ResponseEntity를 감싸서 응답을 반환하고 있고, 공통된 응답 형식도 없이 그냥 DTO만 반환하고 있는 상황이다. HttpsStatus만 넘기려면 ResponseEntity보다 아래와 같이 @ResponseStatus를 사용하는 것이 훨씬 간편하고 코드도 보기 편하게 바뀐다. 코드만 간략해질 뿐 아까와 결과는 같다. 그래서 이제 공통 R..

스프링 시큐리티는 인증과 인가를 도와주는 프레임워크로 많은 사람들이 사용하고 있다.하지만 시큐리티를 잘 알고 능동적으로 사용하는 사람이 있는 반면 잘 모르고 그냥 사람들이 사용하기 때문에 사용하는 사람들도 있을 것이다. (내가 그런 사람이었기 때문) 그렇다면 내가 왜 이 글을 쓰게 되었는지에 대해 말해보겠다. 이 글을 쓰게 된 계기나는 프로젝트를 개발할 때마다 인증과 인가가 필요하면 일단 몸이 스프링 시큐리티를 사용하고 있었다. 하지만 이번 식견이라는 프로젝트를 할 때 같은 백엔드 팀원 한 명이 시큐리티 없이 인증과 인가를 구현하자고 하여 팀원이 시큐리티 없이 구현을 해주었다. 그 당시까지만 해도 나는 시큐리티 없이 인증과 인가를 구현하는 방법은 찾아보았지만 사용하는 이유를 생각하지는 못했다. 하지만 이..