CS 리팩토링 목표

그룹 프로젝트 마무리 후 받은 피드백

기술적 완성도만 보자면 잘 구현했습니다. 다만, 인프라 구성이나 코드 품질 부분에서 비용이나 일정 문제로 인해 타협한 부분이 있습니다.

좀 더 깊이 있게 학습하고 여러 가지 방법이 있지는 않을지 고민이 필요해 보입니다.

폭넓게 여러 기술에 대해 검토하고 실제 프로토타이핑할 수 없어서 공식문서와 레퍼런스, 가벼운 테스트 등을 통해 근거를 파악할 수 밖에 없는 부분이 아쉽습니다.

더 보완하고 개선할 부분들을 직접 찾아보셨으면 좋겠습니다. 일정과 비용으로 타협한 부분들이 무엇인지, 나중으로 미뤄둔 리팩토링 요소는 무엇인지,

단순히 해결한 방식뿐만 아니라 그 외에도 다른 방식들이 있지는 않을지 찾아보시면 깊이 있는 고민과 학습이 될 것 같습니다.

그룹 프로젝트를 진행하면서 일정과 비용 제약으로 인해 타협했던 부분들을 되돌아보고, 특히 인프라 구성과 코드 품질 측면에서 개선이 필요한 영역을 파악하는 것이 필요하다고 생각했습니다.

프로젝트와 기존 코드를 다시 돌아보며 시간과 비용상 타협했던 부분이 무엇인지 파악하고 나열해보며 구체적인 개선 목표를 세웠습니다.

피드백을 바탕으로 개선 목표 세우기

1. 수평확장 환경 만들기

그룹 프로젝트를 진행하면서 시간과 비용 문제로 인해 하나의 인스턴스에 미디어 서버, 채팅 서버, 녹화 서버가 함께 동작하도록 구현했습니다. 이러한 구조는 특정 서버에 부하가 발생했을 때 다른 서버들의 성능에도 영향을 미치는 문제가 있었습니다.

특히 실시간으로 데이터를 처리해야 하는 미디어 서버, 채팅 서버, 녹화 서버의 특성상 부하가 자주 발생했지만, 프로젝트 기간 내에는 임시적인 해결 방안으로 타협할 수밖에 없었습니다.

이러한 문제를 해결하기 위해 **서버 아키텍처를 수평적으로 확장하고, 각 서버와 데이터베이스에 로드밸런싱을 적용하여 전반적인 시스템 성능을 개선**하는 것을 목표로 삼았습니다.

1-1. 채팅 서버 개선

프로젝트에서 구현한 채팅 서버는 단일 인스턴스인메모리 세션 저장 방식을 사용했습니다. NestJS 기반의 WebSocket 서버로 Socket.io를 사용했으며, room 정보 등의 메타 데이터를 Map 자료구조를 통해 인메모리에 저장하는 방식이었습니다.

이러한 구조에서는 다음과 같은 문제점이 있었습니다.

  1. 채팅 서버가 스케일 아웃되는 경우, 서버 간 정보가 공유되지 않아 같은 채팅방에 있더라도 일부 사용자는 채팅을 볼 수 없는 상황이 발생
  2. 다수의 사용자가 동시에 채팅을 사용할 때 서버의 안정성과 성능이 저하

이를 개선하기 위한 목표를 다음과 같이 설정했습니다: