V1 BackEnd-Retrospect
V1 MyInstagram을 하게된 배경
회사에서 JPA, Querydsl과 관련된 프로젝트를 진행하게 될 수도 있으니 준비를 했으면 좋겠다는 이야기를 전해 들었습니다.
프로젝트의 구성은 Vue + Spring JPA라고 들었습니다. 그래서 처음엔 JPA, Querydsl과 관련된 강의를 들으며 ORM에 대한 감을 잡았던 것 같습니다.
강의를 다 듣고 난 뒤 실제 JPA를 적용할 토이 프로젝트가 필요했습니다.
하지만.. vue에 대한 이해가 부족했던 저였기에 회사에 vue를 하시거나 vue 공부를 하시는 분을 찾게 되었고 거기서 현재 프론트엔드 분을 만나게 되었습니다.
그리고 그 분께 같이 토이 프로젝트를 하실 의향이 있는지 묻게 되었고 그 분 또한 마침 vue 프로젝트를 원하셨습니다. (잘됐다 싶었습니닷..!)
그래서 쇠뿔도 단김에 빼라는 말처럼 곧바로 프로젝트를 진행하고자 했습니다.
그러나.. 토이 프로젝트의 주제를 어떻게 정할지... 애매한 부분이 있었습니다.
고민을 하다보니 프론트 엔드분이 진행하시던 인스타그램을 보게 됩니다.
그걸 본 저는 제가 다음에 진행할 프로젝트의 로그인 관련된 기능과 게시판을 만드는 기능에 대한 준비를 할 수 있겠다는 생각을 했습니다.
그리고 첫 프로젝트로 인스타그램을 같이 진행하자는 제안을 하게 되었고 프론트엔드 분도 승낙을 해주셔서 토이 프로젝트를 진행하게 되었습니다.
팀 관점에서 생각하기(CSS)
Continue(팀에서 계속 유지해야 할 것)
사실 토이 프로젝트를 하루 종일 할 수 있는 것이 아니라 일을 같이 병행하면서 진행되는 것이기에 서로 예민할 수 있는 상황이 많았습니다.
하지만 협업을 하는 대상간의 이해와 시간 조정등을 통해 서로 기분이 상하는 것 없이 잘 유지되었던 것 같습니다.
그리고 HTTP에 대한 통신 기초 및 JWT 사용법, RESTAPI 규칙, 와이어 프레임 적용 등 회의를 통해 각자가 부족한 부분을 전달받고 발표하는 시간을 통해 부족한 부분을 더 알 게되는 시간이되기도 했습니다.
Stop(그만 두어야 할것)
토이 프로젝트를 진행하며 서로 힘들었던 부분은 API 설계를 수정할 때였던 것 같습니다.
여지것 진행된 V2 프로젝트의 API가 REST하지 않았다는게 회의에서 문제가 되었고 이전에 잘못 적용된 부분을 전체 수정해야겠다는 결론을 냈습니다. (이때 멈췄어야 했습니다..)
프로젝트를 적용하며 기존의 잘 돌아가던 API설계를 수정했을때.. 기존에 잘 응답되던 값들에 문제가 생겼습니다.
그래서 중간에 Swagger를 도입했지만 .. 정말 ... 고난의 행군이 었습니다.
여차저차 문제가 발생했던 부분들을 고쳐가면서 프로젝트를 마무리했지만 중간에 과도하게 많은 수정을 하는 시간을 통해 서로 너무 지치기도 하고 힘들었던 부분들이 있었습니다.
그래서 다음엔 잘못된 부분이 있다면 다음 프로젝트에서 적용할 부족한 부분으로 남겨둬야 할 것 같다는 생각을 했습니다.
Start(새롭게 시작 해봐야 할것)
다음엔 게시판 기능을 구현이 주가 될 것 같습니다.
게시판 기능을 구현하며 무한 스크롤 게시판을 구현할 Slice 기능과 데이터가 1000만건(대용량 데이터) 일 경우도 잘 동작하는지 초점을 맞추고자 합니다.
대용량 데이터의 조회는 성능에 문제가 있다면 인덱싱 기능을 통해 게시판 기능을 구현하고자 합니다.
성능 확인은 이번에 사용해보았던 PinPoint를 통해 확인해보려 합니다.
수행한 일에 대한 솔직한 정리(4L)
Liked(좋았던 것)
협업을 통한 신기술을 사용했던 경험이 아주 좋은 경험이었던것 같습니다.
협업을 하는 과정속에서 프론트와 소통을 위해 와이어 프레임과 API가 잘 잡혀있어야 하는 것과 꾸준한 팀원들과의 소통이 중요하다는 것을 깨닫게 되었습니다.
Learned(배웠던 것)
Spring Security
JWT 적용
Spring Security의 장점은 권한 관리, 비밀번호 유효기간 설정, 동시 세션 제어 등 많은 장점이 있습니다.
특히 filter로 계정의 인증, 인가를 관리하기에 서버 자원 접근 전에 대상을 관리할 수 있다는 장점이 아주 컸다고 생각합니다.
하지만 제가 사용한 CSRF, session 방식의 큰 단점은 해킹이나 서버 부하와 같은 문제가 있다는 것을 확인했습니다.
그래서 이번엔 좀 더 안정하고 빠르게 유저를 처리하기 위해 CSRF의 사용을 해제하고 JWT를 이용해 페이지를 구현해보았습니다.
WJT는 웹 토큰으로 유저의 정보를 주고 받기에 토큰인증만으로 사용자 인증을 할 수 있고, 특히나 serverless하다는 특징이 있어 아주 좋은 방식이란 생각이 들었습니다.
하지만 JWT 또한 accessToken의 탈취나 refreshToken의 탈취가 문제가 될 수 있다는 것을 알게되었고 이를 막기위한 여러 기법들이 있다는 것을 알게되어 적용하려 했으나...
너무 많은 걸 한꺼번에 적용할 순 없었고 이번에는 JWT를 어떻게 사용했다에 초점을 두어 프로젝트를 진행하였습니다.
JWT를 활용한 임시 로그인 구현
JWT를 통해 임시 로그인을 구현해보았습니다.
임시 로그인의 목적은 비밀번호 변경페이지에서 곧바로 자신의 인스타그램 계정으로 접속하는 기능이었습니다.
임시 로그인은 UUID를 통해 id값을 추출하고 추출한 임시 id를 in-memory 방식으로 관리합니다.
임시 id를 발급받은 대상은 한번은 임시 id로 로그인할 수 있지만 한번이라도 로그인을 하게 되었다면 더이상 로그인을 할 수 없게 제한했습니다.
또한 로그인을 한 대상이 비밀번호를 변경하게 되었다면 기존에 발급받은 임시 id를 제거하는 방식이었습니다.
여기서 한가지 아쉬운 점은 계속해서 임시 id가 메모리에 쌓이게 만들었 다는것 그리고 JWT 토큰이 너무 길다는 단점이 있다는 것이 좀 아쉬웠습니다.
다음에는 이 두가지를 수정하거나 혹은 다른 좋은 방법을 찾아 적용하도록 노력해야겠습니다.
Lacked(부족했던 것)
의미있는 메서드 작성
최근 클린 코드를 읽으며 의미 있는 메서드 추가에 대한 중요성을 느끼게 되었습니다.
그래서 나의 코드를 읽을 독자인 미래의 나와 협업 대상자를 고려해 코드를 작성할 필요가 있음을 느꼈습니다.
DB Call 최소화
프로젝트를 진행하며 쓸데없이 DB Call이 발생되는 경우를 확인했습니다.
이에 DB Call 최소화를 위해 메서드별 중복되는 DB Call을 한번은 호출하되 이후에는 메모리로 관리하면서 성능을 향상 시키는 방법을 고려하고자 합니다.
또한 이 방법 이외에도 더 좋은 방법을 생각해보고자 합니다.
Refresh Token 관리방법
Refresh Token의 유효기간은 JWT 유효기간에 비해 상대적으로 길다는 특징을 가지고 있습니다.
하지만 Refresh Token도 탈취를 당할 수 있다는 문제점을 파악하게 되었고, 이에 Refresh Token과 Access Token의 유효기간을 동시에 짧게 가져가되 Refresh Token과 Access Token의 발행 시점에 차이를 줘서 발급하면 조금 더 보안에 안전한 개발을 할수 있다는 영상을 보았습니다.
영상 출처: [NHN FORWARD 22] 로그인에 사용하는 OAuth : 과거, 현재 그리고 미래
소셜 로그인 적용
소셜 로그인 적용을 다하지 못했네요..ㅠㅜ
다음엔 반드시 적용할 수 있도록 만들어야겠습니다.
Longed for(바라는 것)
현재 버전에 맞는 기술들을 적용해보았으면 합니다.
예를 들어, 자바 11을 적용했는데 자바 11기능 중 람다 파라미터로 var을 사용하거나 Optional에 추가된 기능 ..등 적용할 수 있는 기능들을 정리하여 적용할 수 있으면 더 좋았을 것 같다는 생각을 했습니다.
Trouble Shooting
이번엔 Trouble Shooting을 제대로 하질 못했습니다.
그 이유는 뭔가 너무 성급하게 기능을 구현해야 한다는 생각에 못했던 부분중 하나입니다.
다음 프로젝트를 진행하면서는 반드시 Trouble Shooting을 진행했으면 합니다.
마무리
개발을 배우면 배울수록 정말 많이 부족하다는 생각을 하게 됩니다.
앞으로도 제가 적용해야될 기술에 대한 고민과 적용을 하는 과정을 통해 더 발전하는 개발자가 되어야 겠습니다.