한화 시스템 부트 캠프 23주차 회고

중간 발표가 끝났습니다.

 

안녕하세요 ,, 시간이 너무 빠르네요 벌써 중간 발표가 끝나고 1차 스프린트 기간이 다가오고 있습니다.

오늘은 중간 발표 자료를 준비하면서 다른 팀원이 구현한 것을 살펴보게 되었습니다.

 

바로 알림 기능인데요, 특정 이벤트가 발생하는 상황에서 유저에게 알림을 전송하는 기능이었습니다.

알림 화면은 다음과 같이 구성되어 있습니다.

 

알림이 전송되는 상황은 크게 두가지로

 

1. 로그인한 상태

2. 로그인을 하지 않은 상태일 때 전송되었던 알림들이 로그인을 했을 때 한번에 전송

 

두 가지 상황으로 나눌 수 있었습니다.

 

실시간 웹 애플리케이션을 구현할 경우 사용되는 대표적인 방법으로

 

직접 만들었어요,,, ^ㅡ^ ...

 Polling, WebSocket, SSE가 있었습니다.

 

Polling 방식은 클라이언트가 일정한 주기로 서버에 업데이트 요청을 보내는 방식으로 지속적인 HTTP 요청이 발생하므로 리소스의 낭비가 발생합니다.

Web Socket 방식은 클라이언트간 서버를 통한 양방향 통신이 가능하는 기능이므로 알림 기능의 목적에 비해 리소스의 낭비가 일어날 수 있습니다.

 

 

따라서 저희가 택한 기능은 서버 전송 이벤트(Server-Sent-Event) 입니다. SSE는 클라이언트에서 서버로 요청을 보내면 일정 시간 동안 연결을 유지하면서 이벤트가 발생했을 때 실시간으로 클라이언트에게 데이터를 넘겨주는 서버에서 클라이언트로의 실시간 단방향 통신 방법입니다.
긴 폴링 방식과의 차이는 연결이 이루어지면 일정 기간동안 연결이 끊기지 않고 유지되면서 이벤트가 발생해서 데이터를 응답합니다. 즉, 한 연결당 한 메세지가 아니라 한 연결당 다중의 메세지 전송이 가능해 더 효율적이라고 보고 택하였습니다.

 

앞서 말씀 드렸던 SSE를 구현함에 있어서 사용되는 스프링에서 제공하는 클래스인 SseEmitter 장점에 대해서 말씀드리겠습니다.

먼저, SSE프로토콜을 지원하고 비동기 이벤트 처리가 가능합니다.
그리고 클라이언트의 연결에 대해서 자동 재연결을 하는 기능이 있고 다중 클라이언트 기능을 지원하여 여러명의 유저에게 동일한 알림을 전송할 수 있습니다.

 

 

 

스프링부트에서 SSE(서버 전송 이벤트)를 통해 알림을 구현하는 과정은 다음과 같은 동작 순서로 진행됩니다.

1. 우선 사용자가 로그인을 하면 클라이언트 측 JS에서 EventSource 객체를 생성하여 서버와의 연결을 설정합니다.
2. 연결이 설정된 후 SseEmitter객체가 생성되고 emitter에 저장됩니다.
3. 연결이 되면 pedingAlarms 메서드를 통해 사용자가 연결되지 않은 상황에서 발송된 메세지를 조회하고 메세지가 있는 경우 전송합니다.
4. 서버는 이벤트가 발생했을 때 알림 메세지를 생성하고 send 메서드가 실행됩니다.
5. send 메서드가 실행되면 수신자를 조회하고 각 수신자를 조회하여 알림을 전송합니다.
6. 클라이언트는 서버에서 전송된 메세지를 수신할 때마다 onmessage 이벤트 핸들러가 호출되고 이 핸들러가 수신된 알림을 유저에게 표시합니다.
7. 클라이언트와 서버간의 연결은 연결을 종료하는 이벤트가 발생할 때 까지 유지됩니다.

 

---

 

발표를 준비 하면서, 다른 팀원이 구현한 파트지만 보안 쪽에 관심을 갖다 보니 왜 리프레시 토큰을 사용할까? 라는 생각이 들었습니다. 현재 저희 프로젝트에서는 JWT 토큰을 사용하고 있습니다. 보안 강화를 위해 리프레시 토큰을 도입 할 예정이라고 나와있었습니다.

 

JWT Token ?

 

토큰이 만료되면, 사용자가 다시 로그인 해야 하며, 이는 사용자 경험을 저해하고

인증 서버에 부하를 증가 시킨다.

 

Refresh Token ?

토큰이 만료 되더라도, 자동으로 새로운 토큰을 발급.

사용자의 재로그인 요청이 줄어들고, 인증 서버의 부하를 줄여 DB 접근 빈도를 낮춰 성능을 최적화한다.

 

---

 

리프레시 토큰은 장기적으로 유효하며, 만료된 액세스 토큰을 새로 발급받기 위해 사용됩니다. 이를 통해 사용자는 로그인 상태를 유지하면서도, 액세스 토큰의 만료로 인한 불편함을 최소화할 수 있습니다.

리프레시 토큰은 레디스를 이용해 관리할 계획입니다. 레디스는 인메모리 데이터 저장소로, 빠른 속도와 효율성을 제공합니다. 리프레시 토큰과 레디스를 통해 사용자의 경험을 향상하고자 합니다.

 

이렇게 리프레시 토큰이 필요한 이유와, Redis를 도입하는 이유에 대해서 생각하게 되었습니다.

 

 

JWT 토큰은 유저의 신원이나, 권한을 결정하는 정보를 담고 있는 데이터 조각입니다.

JWT 토큰을 사용하여 클라이언트와 서버는 안전하게 통신합니다. JWT 토큰의 인증 방식은 비밀키로 암호화를 하기 때문입니다.

그런데, 탈취를 당했을 때가 문제입니다.

JWT 토큰을 탈취한 사람은 인증을 통과할 수 있고, 본 주인인 클라이언트와 탈튀한 사람은 서버를 구분할 수 없습니다. 그래서 유효기간을 두어야 하는 것입니다.

 

그런데 유효기간을 짧게 두면, 사용자가 로그인을 자주 해야 하므로 사용자에게 좋지 않고, 길게 두면 보안상 탈취 위험이 있기에 유효기간이 다른 Refresh Token 을 두는 것입니다.

JWT 토큰의 유효시간을 짧게 해 두고, 유효 시간이 긴 리프레시 토큰을 함께 발급하여 토큰 자체를 계속 갱신하는 것입니다.

그러면 JWT 토큰의 유효 시간을 짧게 했으니, 탈취당했을 때의 위험성도 줄어들게 되고, 사용자의 정보도 담지 않고 있으니 상대적으로 안전하다고 볼 수 있습니다. 

 

---

 

중간 발표가 끝나고, 피드백을 듣고 나니 이제 정말 실감이 났습니다 ,, 아 정말 곧 끝나는구나? 하는 생각이요,,,

또한 양이 중요하다고 생각해서 필요없는 정보들도 가득 담아둔 발표 자료도 어느정도 수정이 됐고, 간결하게 청취자를 생각하는 마음으로 재구성하게 됐습니다. 

 

모의발표 하자고 해 놓고 컴퓨터가 꺼진 필자...

 

열심히 발표 준비 했는데 생각보다 마음대로 안 나와서 속상했다 ,, 하지만 속상한 건 속상한 거고, 1차 스프린트도 완벽하게 해서 좋은 결과물을 들고 가야지...! 제가 스프린트 기간에 할 기능은 챗봇 만들기입니다 ,, ! 

아무래도 채팅과 관련된 성능 개선은 kafka를 도입함으로써 한 차례 했다고 생각하고, Ai 기능을 넣고 싶어 생각한게 챗봇이 되었습니다 ,, 어떻게 구현할지는 차차 회고 혹은 공부 방식을 올리는 블로그를 통해 전해드리겠습니다..!

 

다음 주에는 멘토님과 회식 자리가 있습니다. 꼭 사진 찍어서 올릴게요 하하 !! 

 

이번 주는 공부만 올려서 미안해요 ,, ~ ! 

 

 

저 닮았다고 팀원이 대표 사진으로 줬습니다. 너무 웃기죠 ,, 네 저도 웃기네요 ,, 

 

이건 디자이너인 제 친구가 ,, 그려준 저입니다 ~ !! 개발자를 꿈 꾸고 있다고 있지도 않은 맥북도 그려줬어요,,! 

그래 정말 열심히 해서 ,, 난 널 위한 웹을 만들어줄게 (아마도)

 

끝 !