Plum 1차 포스트모르템

네이버 부스트캠프에서 진행한 마지막 프로젝트인 Plum 프로젝트가 공식적으로 종료되었습니다. 공식적으로 종료되었지만, 앞으로 팀원들과 함께 리팩토링과 성능 개선을 함께 진행할 예정입니다. 다만 공식적인 기간은 종료되었기 때문에 포스트모르템을 작성해보고자 합니다.

개요

Plum 프로젝트는 네이버 부스트캠프(이하 네부캠)에서 진행된 그룹 프로젝트로, 온라인 화상 강의 플랫폼입니다. 초기 기획 및 설계 2주, 기술 학습 및 검증 2주, 개발 5주 총 9주간 진행되었고, 그 중 기술 학습 및 검증 주간은 공식 기간이 아닌 인터미션에서 따로 진행한 기간이었습니다.

처음 기획단계부터 새로운 기술, 학습해볼만한 것을 사용하면서도 실제 불편한 문제를 해결하는 서비스를 제공하는 것으로 의견이 모였고, 이에 따라 의견을 주고 받으면서 네부캠 강의에서 마스터분들이 불편해 하셨던 점(캠퍼분들의 의견이 수렴이 되지 않은 점, 의견을 물어보고자 채팅창에 1, 2를 제시하던 점, slido, 구글 설문 등과 같은 문서를 활용한 점 등)을 해결하고자 Plum 서비스를 기획했습니다.

기획 단계부터 팀원들의 원할하고 활발한 소통이 이뤄졌다고 생각하고, 비슷한 생각을 가진 팀원들 끼리 만나 좋은 기획이 나왔다고 생각합니다.

나의 역할

Plum 프로젝트를 위해 내가 한 역할은 무엇인가? 고민해봤을 때 크게 비개발적인 요소와 개발적인 요소로 나눌 수 있다고 생각했습니다.

비개발적인 부분은 설계와 문서관리 등에 대한 부분이라고 생각합니다. 그래서 어떤 것을 했나? 생각해보면 다음과 같았습니다.

• 초기 설계 이후 기술 탐색 및 기술 검증: Mediasoup와 Mediapipe라는 기술을 선택하고, ai를 이용한 초기 프로토타입 구현
• 필요한 기능에 대한 세부 설계 및 다이어그램 작성
  • 전체 아키텍처 구성
  • 강의실 생성/참여, 미디어 송수신, 제스처 인식 등 기능 프로세스 다이어그램 작성
  • 초기 데이터 모델 구성
• API 및 소켓 이벤트 통신 규약 문서 작성 및 관리
• 커밋 규칙 및 PR 규칙 작성
• Release Note 발행 책임
• 백엔드 ↔ 프론트엔드 간 기술 부채 연결
• 백엔드 팀원 의사결정 조언
• 프론트엔드/백엔드 모니터링 및 오류 파악, 전파
• README 문서 작성

개발적인 부분에서는 초기에 백엔드/프론트엔드 개발을 2명씩 나눠서 개발을 진행하였고, 저는 일단 백엔드 개발을 맡았고, 프론트엔드도 시간이 나면 함께 작업하는 것으로 하였으나 실제 개발 시 개발에 필요한 내용이 많아 백엔드 개발만 전반적으로 맡을 수 밖에 없었습니다.

• 프론트엔드 CI/CD 환경 구성
• 프론트엔드 모니터링 도구
• 백엔드/프론트엔드 공통 라이브러리 관리
• 강의실 생성/입장/종료 기능 구현
• 투표/질문 관리 기능 구현
• 강의요약 작성 파이프라인 설계 및 구현

돌아보면?

가장 신경쓴 부분들

작업을 하면서 가장 신경 쓴 부분은 백엔드와 프론트엔드를 맡은 팀원들끼리의 소통이었던 것 같습니다. 작업을 진행하다보니 프론트엔드/백엔드를 맡은 팀원끼리의 소통은 자주 발생하지만 백엔드와 프론트엔드의 직접적인 소통은 적어졌습니다. 이로 인해 서로 작업을 정확하게 어느부분을 하고 있는지 추적하기 힘들었고, 같은 기능을 구현하기 위한 작업인데 작업이 서로 맞지 않는 문제도 발생하였습니다. 이를 해결하기 위해서는 어떻게 해야할까? 라는 고민을 했고, 기존 PR규칙을 바꾸고, 스크럼 회의를 바꾸기로 하였습니다.

기존 PR 규칙은 1명이 Approve를 누르면 머지를 진행하고, 이로 인해 다른 팀원들이 작업을 확인하지 못하였음에도 작업이 머지되는 경우가 빈번하게 발생하였습니다. 또한, 백엔드 작업자들은 백엔드 코드만 더 상세하게 보고, 프론트엔드 작업자도 마찬가지었습니다. 그래서 1명에서 2명으로 규칙을 변경하고, 코드 리뷰또한 이전보다는 상세하게 진행하자는 의견을 제시했고, 이를 통해 이전보다는 작업 추적을 쉽게 할 수 있게 되었습니다.

또한, 스크럼 회의에서는 단순하게 어제 무엇을 헀고, 오늘 무엇을 할 것 같다. 라는 단편적인 이야기만 진행하였는데, 매주 월요일에 이번주까지는 백엔드/프론트엔드에서 어디까지 진행하는 게 맞는 것 같고, 프로젝트 목표를 달성하기 위해서는 이번주 목표는 무엇이라는 것을 정하고, 매일 무엇을 해야한다. 라는 것을 말하기로 바꿨습니다. 이를 통해 전체적인 목표도 잘 정할 수 있었고, 이전에 큰 규칙 없이 진행하던 작업들이 체계있게 진행되는 것을 알았습니다.

잘했는가?

상대적으로 생각했을 때 잘했다? 라기에는 어려움이 있는 것 같습니다. 처음 사용하는 기술이 많아 학습하는 시간보다는 구현을 바로바로 진행하고자 기술에 대한 학습을 진행하였고, redis만을 사용해 작업을 진행하였는데, 그 당시에는 회원가입도 없고, 영구적으로 저장하는 어떤 데이터도 없으니까 DB 없이 redis 만을 이용해서 분산된 서버 환경에서도 작업을 추적할 수 있지 않을까? 생각했습니다. 지금 와서 생각해보면 redis가 죽으면 어떡하지? 라는 생각을 놓친 것 같습니다. 실제로 redis에 있는 정보가 휘발된 경우가 있었음에도 불구하고요. 이런 경우의 전략을 한번 더 고민해봐야 할 것 같습니다.

STT 변환 부분에서도 아쉬운 부분이 많은 것 같습니다. 데이터 저장용량을 현재 값으로 잡는 것이 적절한가? 결국 실험(다양한 값으로 시도)를 해봐야할 것 같은데, 부족한 것은 아니었을까? 모든 참가자의 음성을 모두 녹화하는데, 100명이 모두 말하는 상황에서도 서버가 터지지 않을까? 애초에 모든 참가자의 음성을 녹음하는 것이 적절한가? 이러한 고민들은 여전한 것 같고, 조금 더 고민해보고 개선해봐야 할 것 같습니다.

팀원들 모두 이야기해봤을 때 잘한 점보다 못한 점이 많이 보인다는 공통적인 의견이 많아 앞으로도 차근차근 개선해보고자 합니다.

사용자 테스트

사용자 테스트에 대한 이야기는 다른 글에서도 남겼지만, 이러한 경험 자체가 너무 좋은 경험이었던 것 같습니다. 따로 진행한 공개 사용자 테스트에는 총 56명의 테스터분들과 함께, 최종 발표에서는 약 40명의 테스트 분들과 함께 저희 서비스를 테스트해보고 피드백을 받을 수 있었습니다.

이전에 다른 프로젝트를 해봤을 때 이러한 사용자들이 직접 개발한 서비스를 체험해보고 후기를 준 경험이 전혀 없는 상황으로, 이번 테스트는 저에게 정말 새로운 경험이었습니다. 직접 만든 서비스가 실제 사용자 앞에서 동작하는 것을 보면서, 코드 너머에 있는 사용자의 존재를 체감할 수 있었고, 피드백 하나하나가 앞으로의 개선 방향을 잡는 데 큰 도움이 되었습니다.

마치며

9주라는 시간이 길다면 길고 짧다면 짧은 시간이었는데, 돌아보면 기술적으로도 협업 면에서도 배운 것이 정말 많았던 프로젝트였습니다. 잘한 점보다 아쉬운 점이 더 눈에 들어오는 건 사실이지만, 그만큼 다음에 무엇을 개선해야 하는지가 명확해졌다는 뜻이기도 합니다.

Redis 단일 저장소의 한계, STT 파이프라인의 확장성 문제, 그리고 백엔드-프론트엔드 간 소통 구조까지 공식 기간은 끝났지만 팀원들과 함께 하나씩 개선해나갈 예정입니다. 좋은 팀원들과 함께할 수 있어서 좋았고, 이 경험이 앞으로의 개발에 좋은 밑거름이 될 거라 생각합니다.