사용하고 있는 라이브러리가 많으며, 소켓의 경우에는 3개를 연결하고 있습니다. 이를 모두 관리하기 위해 room의 생명 주기를 토대로 FE에서도 생명주기를 만들었습니다. room과 관련 없는 상태인 init상태, room을 생성하고 카메라 세팅을 하는 ready상태, 실제로 연결하기 위해 로딩하는 staging상태, 회의중인 running상태 마지막으로 회의를 종료하고 사용한 데이터를 제거하는 finishing상태를 도입하였습니다.
이를 도입함으로서 running상태에서는 socket이 연결되어 있다는 것을 확실하게 처리할 수 있었으며, 3개의 editor와 3개의 소켓을 쉽게 관리할 수 있었습니다.
마찬가지로 카메라 및 마이크를 사용하지 않는 경우를 파악하기 쉬워 쓸데 없는 곳에서 사용하지 않는 것을 방지하였습니다.
Room의 생명 주기를 기반으로 각 상태별로 처리 가능한 WebSocket 이벤트와 권한을 가진 사용자들을 미리 정의함으로써 코드 설계가 훨씬 수월해졌습니다. 예를 들어, 특정 socket이 요청을 보낼 때, 속한 방의 상태에 따라 예외 처리를 간단히 구현할 수 있었습니다.
또한, 쌍방향 통신을 지원하는 WebSocket API를 설계하면서 'room status'라는 추상적인 개념을 명확히 정의하고 문서화하였습니다. 이를 통해 룸 참여를 포함한 다양한 작업에 대한 정책을 프론트엔드 팀과 효과적으로 소통할 수 있었습니다. 예를 들어, 특정 조건에서 사용자를 강제로 룸에서 나가게 하는 정책을 프론트엔드와 쉽게 합의할 수 있었습니다.
회의 후, 대용량 데이터를 저장하는 데 있어 관계형 데이터베이스를 사용하는 경우 비용이 과도하게 발생하는 문제를 확인했습니다. 이에 AWS S3를 활용한 데이터 저장 방식이 비용 효율적인 대안으로 제시되었습니다.
AWS S3를 사용하면 대규모 데이터를 저렴한 비용으로 처리할 수 있으며, 클라이언트에게 데이터를 전달할 때 S3에 저장된 객체의 링크를 공유하는 방식으로 운영됩니다. 그러나 S3 링크는 기본적으로 공개될 수밖에 없으며, 이 URL이 변하지 않고 공개된 상태로 남아있으면 누구든지 해당 링크를 통해 접근할 수 있는 보안 취약점이 발생할 수 있습니다.
이 문제를 해결하기 위해, 우리는 'Presigned URL' 기술을 도입하기로 했습니다. Presigned URL을 사용하면, 데이터가 저장된 S3의 객체 키를 통해 유효 기간이 설정된 URL을 동적으로 생성하여 클라이언트에게 전달할 수 있습니다. 이 URL은 설정된 유효 시간이 지나면 자동으로 만료되므로, 공개적인 링크의 위험을 줄일 수 있습니다.
그럼에도 불구하고, Presigned URL 자체가 일정 시간 동안 유효하므로 결국 누구나 해당 URL을 가지고 있으면 접근이 가능하다는 점은 여전히 해결해야 할 부분으로 남아 있습니다.
스크롤이 바닥이 아니고, 남에게 채팅이 왔을 경우 채팅 미리보기를 띄울 수 있는 기능을 추가하던 중 스크롤이 바닥임을 인식하지 못하는 문제를 발견함. Chrome에서는 바닥임을 잘 인식하였지만 Edge에서는 바닥인식이 이상한 경우가 있었음. ScrollTop을 사용해서 0일 시에 true가 콘솔창에 나올 수 있게 설정했지만 Chrome에서는 true가 잘 나왔지만 Edge에서는 바닥 직전에 true가 나왔다가 false가 나옴. 그래서 두 브라우저의 스크롤 정책의 차이 인줄 알았고, 구글링과 지피티를 활용해서 문제를 많이 찾아봄. 하지만 나와 비슷한 경험을 하는 사람을 찾지 못하였고, 그래서 문제점을 세세히 찾아감. 그러던 중 모니터 크기에 따라 바닥을 인식함이 다르다는 것을 알게 됨. 노트북에서는 0으로 잘 나왔지만 큰 모니터들의 경우 1이 바닥임을 인식하였음. 그래서 0인 경우가 아닌 0보다 크거나 같은 코드를 적으니 원하는 대로 바닥임을 인식하여 해결했음. 그래서 문제를 단계적으로 분석하고 원인을 좁혀가는 과정을 통해 디버깅 능력이 향상됨. 또한 사용자 환경에 따라 기능이 다르게 동작할 수 있다는 점을 학습해서 향후 개발 시에 다양한 디바이스와 환경에서 테스트의 중요성을 깨닫게됨.
음성 데이터를 실시간으로 처리하는 시스템 설계를 위해, 프론트엔드에서 음성을 텍스트로 변환하고 서버에는 텍스트만 전송하는 방식을 채택했습니다. 이 접근법은 서버의 처리 부담을 줄이고 실시간 녹음처럼 빠르게 데이터를 전송할 수 있도록 하여, 전체 시스템 성능을 최적화했습니다. 특히, 음성 데이터를 실시간으로 합치고 인코딩하는 작업은 구현하는데 난이도가 높은 편이며 서버의 리소스를 크게 소모할 수 있어, 프론트엔드에서 변환을 담당하게 함으로써 효율성을 높였습니다.