[SEB BE 44] 코드 스테이츠 Main Project 후기

 

코드스테이츠 Main Project 후기

기쁜데.. .슬프다..

끝났다... 끝났다아... 끝나다악ㄱ가아ㅏㄱ아악!!!!!

 

??: 뭐해? 이제 취준해야지?

---

• Team name: 코벤져스
• Project: PliP
• Development Duration: 2023.06.29~2023.07.21
• Git Hub URL: https://github.com/dayoungee/plip

드디어 부트캠프 수련기간이 끝나간다.. 부트캠프 시작 전부터 그렇게 걱정하던 프로젝트들은 모두 무사히 끝냈다 ㅠㅜㅠㅠㅠ 프리 프로젝트만큼 빡세진 않았다. 그때는 점점 피폐해져가는 날 느꼈는데, 메인 때는 그정돈 아니었다. 맞닥뜨린 에러도 이미 프리 프로젝트 때 봤던 거라 수월하게 해결하기도 했었다. 프로젝트 경험이 이렇게나 중요하다...

 

프리 프로젝트에서는 하루종일 코딩만해서 힘들었어도 나름 즐거웠는데 메인 프로젝트 때에는 어땠는지 기억이 잘 안난다. 내가 즐거웠었나.. .힘들었었나... 정말인지 기억이 1도 안난다..

그래도 Spring Securitry와 토큰 인증 방식에 대해서 많은 것을 배울 수 있어 뜻 깊은 프로젝트임은 확신할 수 있다.

 

아무튼 메인 프로젝트에서 작용한 기술은 아래 사진과 같다. 

 

Tech Stack

 

 

프리 프로젝트 때 아쉬웠던 점들을 보완!

프리 프로젝트 회고에도 적어놨듯이 N+1문제를 해결하지 못한 것과 Logging이 잘 되지 않았다는 점이 아쉬웠는데 이번 프로젝트에서는 그때의 기억을 살려 싹다 해결했다. N+1문제는 Batch Size를 조절해서 쿼리문을 줄였기 때문에 완벽하게 해결한 것은 아니다. 그러나 37개의 쿼리문을 5개까지 줄였으니 안한 것보다는 더 나은 것 같다. 그리고 Spring AOP를 적용하여 Logging처리가 되어 컨트롤러에 들어올 요청 헤더, 바디, 엔드포인트 정보를 Log에 기록한다. 까먹을까봐 노션에도 적어놓았는데,, 이번엔 아쉬웠던 점들이 잘 보완되어서 다행이다.

 

드디어 써본다 Redis ...!

말로만 들었던 Redis를 프로젝트에서 처음 써보았다 ㅠㅠㅠㅠ 유효기간을 쉽게 정할 수 있어 유효기간이 정해진 데이터를 넣는 용도로 Redis를 사용했다. 인메모리 DB다 보니까 빠르기도 하다. 이메일 인증 코드 같은 경우 보안 때문에 이메일 인증 코드 검증 여부를 서버에서 확인하기로 정책을 정했다. 때문에 유요한 이메일 인증 코드를 서버가 보관하고 있어야 했다. DB에 넣기에는 유효기간이 너무 짧은 데이터였다. 스케줄러를 사용해서 MySQL에 들어간 데이터를 삭제하기 보다 Redis를 도입하여 간단하게 데이터를 관리하는 것이 더 효율적이라 생각했다.

 

Redis를 도입한 김에 토큰 블랙리스트 개념도 추가했다. 로그아웃을 한 유저의 토큰(더이상 유효하지 않는 토큰)을 통해 인증을 시도할 경우 인증이 되지 않도록 막는 개념이다. Redis에 토큰의 남는 유효기간 만큼 Set해주도록 했다. 토큰이 만료되면 Redis에서 삭제된다 ~

 

Redis의 대체제로 Memcached가 존재한다. 이 둘은 비슷하지만서도 차이점도 분명히 존재하는데, 이 중 하나만 크게 뽑으라 한다면 데이터의 영속성에 있다. Redis는 인메모리지만, 설정을 통해 서버가 재부팅된다 하더라도 그 데이터를 지속적으로 저장할 수 있는 방법이 있다. 

 

JWT.. 너 생각보다 더 복잡한 놈이었구나 ..?

Access Toekn이 만료되면 Refresh Token으로 다시 발급하는 과정은 어렵지 않았다. 이미 알고 있는 내용이기도 했다. Refresh Token은 만료되면 사용자가 다시 로그인하게끔 Refresh Token을 재발급 해주는 로직을 넣지 않았다.(귀찮아서 따로 발급해주는 절차 안넣은 거 아님 정말 아님). 여기서 Access Token을 재발급할 때 Refresh Token까지 재발급해주는 로직을 넣는다고 해보자. 사이트를 방문하지 않는다는 가정하에 Refresh Token이 만료된다면, Refresh Toekn의 유효기간이 지나면 로그아웃 상태가 된다. 이건 결국 프로젝트 정책에 따라 정할 수 있는 선택사항이다. 여기서 나는 전자를 선택한 것이고...

 

Refresh Token은 처음엔 헤더에 보관했다가 쿠키에 넣자는 프론트 분의 이야기에 쿠키로 넣는 것으로 바꾸었다. 쿠키에 넣어서 관리하는게 더 간편하기도 했다. 이때 XSS 공격을 방지하고자 Httponly 옵션을 걸어줘야 했다. 부가적으로 보안에 관련하여 Secure 설정을 걸어 HTTPS 통신을 통해서만 쿠키를 받을 수 있게 설정했다.

 

또, Access Token은 클라이언트에서 로컬스토리지에 담는 것이 아니라 자바 스크립트의 변수로 관리하기로 하여 보안을 강화했다. 이렇게 변경된 정책에 새로고침을 하거나 브라우저를 닫은 후 열었을 때, 로그인 상태를 유지하기 위해서 유효한 Refresh Token으로 Access Token을 발급 받을 수 있도록 API 작성했다. 

 

토큰 인증 방식이 토큰만 왔다리 갔다리 ~ 하면 될 것 같아 쉬워보이지만, 마냥 쉬운 게 아니다. 탈취 위험성에 대해서 보안 측면에서도 많은 주의가 필요했고, 토큰 만료, 유효하지 않는 토큰 등 세심한 에러 핸들링도 필요하다. 여러 상황을 생각하며 세심하게 다뤄야한다..

 

이처럼 토큰 인증 방식으로 로그인 상태를 유지하겠다면, 보안에 유념해야한다. 이전에는 이런 개념이 턱없이 부족했는데 이번 프로젝트를 통해 배울 수 있게되어 뜻깊었다.

 

이외에.. OAuth2.0.. Spring Security

Spring Security는 독학을 할 때도 코드를 볼 때도 직접 해봤을 때도 이해가 잘 되지 않는 부분이었는데, 이론을 공부하고 직접 프로젝트에 적용해보니 확 와닿는 기분이었다. 조금은 친해진 기분?? Filter Chain 구조 방식을 이해하니, 어떻게 Spring Security가 돌아가는지 조금은 알 것 같은 기분이었다. OAuth도 마찬가지였다. 이 두가지 개념이 나에게 부족한 개념이라 쭈욱 생각해왔는데 이번 프로젝트를 통해서 나와 Spring Security 사이에 가로막고 있던 벽을 허문 느낌이었다. 이젠 코드도 술술 읽힌다;

 

 

3줄 요약

1. 프리 프로젝트에서 아쉬웠던 점 해결 ~

2. Redis 안녕? 나랑 친해져볼래?

3. JWT... 만만하게 봤던 너.. 미안..

 

이렇게 마지막 프로젝트를 끝내고 취준의 길로 들어섰다... 저는 이제 취준하러 떠납니다. (팀원분들 정말 고생 많으셨고 앞으로 행복 길만 걸으세여...)

정말 잘하시는 분들만 있으셔서 믿음직스러웠고 개발 흐름도 나름 여유롭게 흘러갔던 것 같다. 그리고 디자인이 너무 잘 뽑혔다...

내일은 프로젝트 데모데이다. 프로젝트 마무리 시간이자 파티(?)인 것 같다. 내일이 기대된당