컬쥐네 다락방

2021.04.12~04.18 항해 99 - 7주차 회고록(feat. Web Socket) 본문

카테고리 없음

2021.04.12~04.18 항해 99 - 7주차 회고록(feat. Web Socket)

코딩하는 갱얼쥐 2021. 4. 19. 01:57

벌써 7주차가 지나갔다는게 믿어지지 않는다 😥 해보고 싶은 건 많고 배울 지식은 더 많고.. 시간은 부족하고... 

7주차는 새롭게 정해진 팀원들과 관심사에 따라 채팅방을 만들고 소통하는 웹 채팅 서비스를 구현하며 시간을 보냈습니다. 

강의를 따라가며 초반에 배운 CURD 기능과 로그인, 회원가입 기능을 넘어서 이제 더 다양한 서비스를 구현해보고자 팀원들과 목표를 잡고 도전했는데.. 생각보다 쉽지 않다.. 

 

Web Socket 

채팅방 기능을 구현하려면 가장 먼저 Web Socket 기능을 이해해야 했다.. 

Web Socket은 ws 프로토콜을 기반으로 클라이언트와 서버 사이에 지속적인 양방향 연결을 만들어주는 기술로 채팅을 할 때는 지속적으로 채팅을 보내거나 받기 위해 양방향 소통이 필요해 ws 기능을 이용한다고 한다.

Web Socket을 이용해 채팅방을 구현할 때 Redis와 Stomp. 두 가지 기능이 정말 중요했다. (물론 전체적인 흐름과 현재 코드의 구성, 그리고 왜 이런 코드가 사용되는지 이해는 완료했지만.. 아직 클라이언트와의 소통 문제에서는 많이 부족하고 궁금증 투성이.. 😭)

 

1. Stomp

StompHandler를 이용해 사용자가 보내는 Connect 요청을 보고 토큰 유효성 검증을 거친 후 사용자를 웹소켓에 연결해주거나, Subscribe 요청이 왔을 땐 요청한 사용자와 요청된 채팅방의 id를 찾아내 구독 상태로 만들어주고 채팅방 정보를 수정한다던지, Disconnect 요청이 왔을 땐 요청한 사용자의 Web socket 연결을 종료하고 연결된 채팅방 정보를 수정하는 등 전체적인 Web Socket 기능을 이용하기 위해 사용자를 도와주는 역할이었다.

여기서는 Publish, Subscriber 기능을 사용해 어느 한 사용자로 인해 메세지가 발행(Publish)된다면 구독(Subscriber)중인 사람들에게 해당 메세지를 뿌려주기 위해 사용했다. 

이 기능을 이용해 pub으로 메세지가 들어오면 해당 사용자의 토큰을 이용해서 보내는 사람은 누구인지 알아내고, 해당 메세지와 보내는 사람 정보를 합쳐 메세지로 다시 만들어준 다음 /sub으로 보내준다.

그러면 구독중인 세션에게 해당 메세지를 쭉 발송해 채팅방에서 읽을 수 있다! 

 

2.Redis

Remote Dictionary Server의 약어인 Redis는 데이터베이스, 캐시, 메시지 브로커 및 대기열로 사용하는 빠르고 오픈 소스, 인 메모리 키-값 데이터 스토어.

Redis에 기록되는 메세지들은 따로 DB에 저장되지 않아서 메세지가 발행되는 순간 채팅방에 있는 사람들만 메세지를 볼 수 있기때문에 현재 실시간 채팅방을 구현하고 남은 시간을 활용해 MySQL에 연결해 데이터를 저장해두는 것이 목표다. 이렇게 하면 늦게 채팅방에 들어온 사람들도 채팅 내역을 읽을 수 있을테니.. 

 

한 주의 느낀점

채팅방 기능을 만만하게 생각했는데.. 생각보다 구현하는게 어려웠다. 

그 이유로 일단 WS라던지, Stomp나 Redis, SockJS 등 너무 새로운 지식을 한 번에 배웠기 때문이다. 

하나를 공부하다보면 다른 지식을 또 찾아 공부해야하고.. 또 Spring을 이용한 채팅방 기능 구현은 예제도 별로 없었다.. 

(그 부족한 예제와 설명 블로그들 사이에서 내가 사용하는 Gradle 방식의 Spring은 더욱 더 극 소수여서 힘들었다.. 왜 우리는 gradle 방식의 스프링을 배웠나요 !! 앞으로는 maven 방식의 스프링과 차이점을 공부하고 다른 방식이더라도 내가 정보를 사용하게끔 만들어야겠다!)

또 채팅 기능 확인은 WS 기능을 사용하다보니 처음에 간단한 기능을 테스트할 땐 내가 스스로 군데 군데 만들어진 소스를 가져와 프론트엔드 기능을 만들어 테스트 했었지만.. 추후 여러 가지 기능들을 고치고 나니 나 혼자 있을땐 지금 이 코드가 제대로 돌아가는지, 상대방은 어떻게 보이는지 확인하기가 너무 힘들어서 기능을 구현하는 시간이 많이 늘어지는 느낌을 받았다... 

다른 기능들은 ARC로 주고받는 정보를 찍어보기만 하면 끝이었지만.. 채팅 기능은 실시간으로 보내는 메세지를 받거나 구독중인 사용자들에게 뿌려지는 것을 확인해야 해서 더 힘들었다. 😥

다같이 테스트 해보는데 나 혼자만 궁금한 부분들을 건드리며 이걸 건드리면 어떻게 바뀌는지, 어떤 영향을 미치는지 빠르게 군데 군데 건드려볼 수 없어서 답답한 부분도 있다.. 이론으로만 이해하지 않고 실제로 코드에서 이것 저것 바꿔보면서 이해하는게 난 더 빠르고 좋았는데 아쉬웠다.. 혼자 코드를 바꾸고 돌리면서 테스트하는 건 (물론 테스트 코드를 돌리는 것도 포함) 1분이면 내가 알아보고 싶은 부분을 해결했지만, 이런 방식에서는 내가 코드를 고치고, 빌드를 하고, 빌드된 파일을 서버에 올리고, 서버를 다시 켜주고 프론트 분이 서버에 접속해서 결과를 확인하는 과정이기에... ㅠㅡㅠ 

이게 바로 실제 회사에서의 개발 과정일까 .. ? 실제로는 프론트 개발자들과 정말 정말 많이 이야기를 나눈다고 하던데..

 

아! 그래도 뭔가 터미널 화면을 보면서 서버에 정보가 들어오고 나가는 메세지를 보고 에러 메세지를 판단하며 코드를 수정하는 작업을 하다보니 뭔가 이제 슬슬 개발자가 되기 위한 길을 걷고 있다는 느낌이 확 들어서 기분은 좋았다.. 

그리고 평소에 궁금했던 JWT 방식의 로그인도 완벽하게 이해했으니 얻은 점은 분명히 있다! 

 

앞으로 남은 한 주, 채팅방 기능 구현에 성공하고, 남은 프로필 변경 기능까지 추가하면 이번 미니 프로젝트도 완성이다! 

 

그리고 요즘에는 미니 프로젝트 진행과 동시에 마지막 실전 프로젝트를 계획하고 있다.

마지막 실전 프로젝트 설명회에서 만난 React Native 팀원분과 함께 팀을 꾸려 실제 어플 런칭을 준비하고 있는데, 일단 지금은 요즘 뜨는 핫 플레이스를 공유하는 플랫폼을 만들 계획.. 

RN을 다루는 사람들이 워낙 적어서 계속해서 웹 플랫폼만 만지다 보니 애플리케이션을 꼭 만들어보고 싶었는데 정말 정말 운이 좋게도 성격 좋으신 분과 극적으로 팀이 성사됐다.. >< 

물론 팀원 구성이 완료되면 계획은 언제든 바뀔 수 있지만 팀 리더로서 팀원들과 다같이 즐기면서 마지막 5주를 마무리 하도록 준비 잘 해봐야겠다 ! 

Comments