2주차 릴리즈 노트

계획에 대한 내용은 2주차 진행 계획 페이지를 참고해 주세요!

FE

• 요약: 이번주 프론트엔드에서는 코드 개선을 진행하기 전 단계로 테스트 코드 작성, 문제 분석을 위한 테스트 도구 적용을 목표로 했습니다. 하지만 실질적으로 릴리즈까지 마친 목표는 있지 않았습니다. 남은 CS 리팩토링 기간을 잘 보내기 위해서 더 작은 단위의 유의미한 개선을 진행해야겠다고 느꼈습니다.

AS-IS: 테스트 코드가 작성되어 있지 않아 기능 동작을 비효율적으로 확인하는 환경

TO-BE: Yjs 데이터 관련 커스텀 훅에 대한 테스트 코드가 있어 작동 여부를 빠르게 확인가능한 환경

• 문제: 기존에 테스트 코드가 존재하지 않았기 때문에 작동 결과를 확인하는 과정에 번거로움이 있습니다. 동시 편집과 관련된 개선을 위해서 먼저 hooks/useYjsSpace.tsx, store/yjs.tsx와 같이 CRDT를 다루는 커스텀 훅이 정상적으로 작동되는지 확인하는 테스트 환경을 만들어야 합니다.
• 학습: vitest, @testing-library/react와 같은 테스트 라이브러리를 사용하는 방법을 익히고 적용을 위해 기존 코드를 분석합니다.
• 적용: vi.spyOn을 사용하면 Partial Mock으로 인해 안티 패턴이 발생할 수 있으므로 vi.mock을 통해 모듈 의존을 관리하여 테스트 코드를 작성합니다.
• 테스트 코드가 아직 완성되지 않았습니다.😢 완성될 경우, 동시 편집 로직의 개선이 진행될 때 작동 여부를 손쉽게 확인할 수 있을 것으로 예상됩니다.

AS-IS: 다수의 사용자가 이용하는 상황의 성능 분석을 실제 접속을 통해 확인하는 환경

TO-BE: 가상 유저를 만들 수 있는 테스트 도구를 통해 다양한 상황에 대한 성능 분석이 간편한 환경

• 문제: 기존에는 동시 편집 스트레스 상황을 테스트 할 때, 실제 접속을 통해서만 테스트가 진행되었습니다. 모든 테스트마다 실제 접속하여 테스트하는 것은 비효율적이므로 실제 다수 유저가 접속한 환경을 시뮬레이션해 볼 수 있는 테스트 도구가 필요합니다.
• 학습: E2E 테스트를 진행할 수 있는 playwright를 이용하여 테스트가 진행 가능할 것으로 예상됩니다.

BE

• 요약: 단일 Nest 서버가 API의 역할과 WebSocket GateWay의 역할을 모두 수행하고 있었습니다. API서버와 WebSocket서버를 분리하여 이후 확장 가능한 서비스가 될 수 있도록 설계하였습니다.

• 문제: 현재 하나의 Nest 서버가 서버 위에서 동작하고 있습니다. 만약에 트래픽이 몰리는 상황이 발생하는 경우 확장하기 어려운 문제가 있다고 생각하였습니다.

• 방법: 하나의 Nest 서버를 API 서버와 WebSocket 서버로 분리하는 작업을 수행 후 WebSocket Server 앞에 LB를 통해 확장 가능한 서비스를 논리적으로 구축하는 일을 목표로 합니다.

• 학습: kafka, redis pub/sub, docker container network를 학습해보았는데, 관련해서 다음 주에 유의미한 성과가 나올 것 같습니다.