2023. 08 본과정 Week 09 WIL - 본 프로젝트 2주차 회고

Fact

프로젝트 1차 목표 기능 구현 작업을 했다.

Feeling

매번 1주 단위의 소규모 프로젝트를 진행하다가 6주짜리 프로젝트를 진행하다 보니, 생각할 게 더 많아지는 것 같다.

Finding

 백엔드와 프론트엔드의 개발 환경에 따라 특정 기능을 구현하는 라이브러리 편의성이 다를 수 있다는 걸 체감하게 됐다.

 

 프로젝트의 모든 인원이 소켓에서부터 시그널링 서버 구현을 비롯한 WebRTC 기술 자체를 처음 접하다 보니 각자가 자료를 찾아보게 됐다.

그렇게 찾아본 결과, SpringBoot에서 웹 소켓을 다루려고 하면 보통 org.springframework.boot:spring-boot-starter-websocket 의존성을 추가한 후 사용하는 게 일반적인 듯했다. 이 라이브러리를 사용하면 기본 웹 소켓 기반 채팅 기능을 아주 간편하게 구현할 수 있으며, STOMP형식을 지원하는 인메모리 방식 메시지 브로커도 사용할 수 있다.

 

 일단 SpringBoot 기본 웹 소켓을 사용하는 걸로 결정하고, 메시지 브로커 형식을 적용할지에 대해 고민해보았다. 우리 프로젝트의 매칭 방식이 단순히 만들어진 방에 스스로 입장하는 게 아니라 언어 정보를 기반으로 매칭 가능한 대상이 있을 경우 자동으로 매칭되거나, 대기열에 진입하도록 만들어야 했다. 소켓 통신 시스템과 매칭 매커니즘을 연결하는 과정에서 토큰 기반으로 유저를 인증하거나 유저 정보를 추출하는 것이 가능하기 때문에, 메시지에 헤더를 구분할 수 있는 STOMP방식으로 헤더에 토큰을 담아 사용하는 게 더 편하다고 생각했다. 또 추후에 고도화된 채팅 기능이나 전체 공지사항 같은 기능 등 확장성을 고려해서 인메모리 방식의 메시지 브로커를 사용해서 STOMP 메시지를 주고 받는 것으로 구현하기로 결정했다.

 

아직 프로젝트 초기다 보니 프론트 분들은 레이아웃 작업이나 관련 이론 학습 중인 상황이어서, 조건부 1:1매칭 시스템 로직을 먼저 고민해보고 적용하기 위해 내가 먼저 작업에 들어갔었다.

 내가 이해한 방식은 어쨌든 peerConnection 하기 위한 정보를 텍스트 형식으로 주고받으면서 서로의 연결 정보를 교환함으로서 시그널링이 된다고 이해했기 때문에, 일단 매칭된 서로 간에 메시지를 교환할 수 있는 환경만 만들어준다면 별 무리 없을 거라고 생각하고, 여차저차 매칭 후 서로 메시지를 보낼 수 있는 상황까지 구현했다.

 

 그런데 시간이 지난 후 프론트분들이 webSocket을 연결하는 과정에서, 약간의 문제가 있었다. React를 사용하는 프론트엔드 환경에서는 STOMP메시징을 이용해 peerConnection을 수립하는 레퍼런스 자체가 많지 않아서, 그 소량의 레퍼런스를 참고해가면서 시그널링을 진행하기에는 조금 지장이 있었던 것 같다. 모두 소켓 관련 작업을 처음 진행해보는 거기 때문에 이해도가 부족한 데서 비롯된 문제일 수도 있겠지만, 당장 프로젝트를 진행상황을 고려해보았을 때 프론트에서 해야 할 작업이 상대적으로 많기 때문에 프론트환경에서 좀 더 레퍼런스가 많고 관련 자료도 많은 Socket.io를 사용하자는 의견이 있었다.

 그래도 나름대로 소켓 통신과 매칭 매커니즘을 연결하는 과정에서 어느 정도 연결 과정이 이해가 됐었기 때문에, 해당 안건 회의 당시에는 사실 별 무리 없을 거라고 생각하고 바꾸기로 결정했다.

 

 그렇게 자료를 찾다 보니, 아까 얘기했던 것과 반대의 상황이 발생했다. Socket.io를 사용하는 시그널링 서버 레퍼런스의  대부분은 Node.js를 기반으로 하는 라이브러리를 통해 매우 간편하게 작성할 수 있었는데, 정작 Spring에서 Socket.io기반으로 작동하는 시그널링은 레퍼런스가 매우 부족했다. 더군다나 Socket.io 시스템을 기반으로 비즈니스 로직의 매칭 시스템과 결합시켜야 했기 때문에, 단순히 레퍼런스를 복사 붙여넣기 할 수도 없었다.

그리고 예제도 많고 설명도 많아서 비교적 간편하게 적용할 수 있었던 SpringBoot 기본 webSocket 라이브러리를 사용했을 때와는 다르게, Spring으로 Socket.io를 사용하는 경우 이것 저것 고려해야 할 게 좀 더 많고 설정과 관련된 자세한 설명을 찾기가 힘들었다. 다행히 어느 정도 깔끔하게 정리된 레퍼런스와 관련 자료들을 분석해가면서 어찌저찌 연결에 성공하긴 했지만, 작업 당시에는 굉장히 막막했던 것 같다.

Future

제일 좋은 건 미리 관련 정보들을 파악하고 처음부터 최선의 결정을 내리는 것이겠지만, 상황에 따라 급박하게 바뀔 수 있는 일은 얼마든지 있는 것 같다. 새로운 걸 더 배울 수 있다는 마음가짐으로 변화에 대응하려고 노력해야겠다.