🐊[정글일지] 나만의 무기를 갖기(정글 최종 프로젝트) 회고

나만의 무기를 갖기

정글의 마지막을 장식하는 실전 프로젝트 주간, 나만의 무기를 갖기가 끝났다.
5주동안 진행했던 프로젝트에 대한 회고와 간단한 소회를 남겨보려고 한다.

팀 배정

각자의 선호도를 제출하여 stable-marriage 알고리즘을 통해 팀이 구성되었다. 대부분의 팀이 그랬듯, 나는 핀토스 1, 2주차를 함께한 동기 형과 함께 사전에 협의를 해서 선호도를 제출했고, 의도대로 팀이 구성되었다. 팀의 이름은 code EATERS. 초안 발표 이후, 우리의 서비스 이름을 내거는 것이 더 중요하다는 것을 깨닫게되어 잘 쓰지는 않았지만, 스티커를 제작해 노트북에 붙이기도 하며 팀플레이를 위한 소소한 즐거움이 되어주었던 것 같다.

초안 발표

초반 기획단계에서 예상보다 에너지를 많이 써야 했었다. 굳이 사업성을 갖출 필요는 없지만, 우리 주변의 문제를 해결할 수 있는 서비스를 생각해내야 했고, 그 와중에 정글 출신으로서의 빠른 학습능력과 구현능력을 뽐낼 수 있는 주제를 고르려니 여간 머리가 아픈게 아니었다.

팀 안에서 정말 다양한 아이디어들이 나왔지만, 최종적으로 우리 팀은 2개의 초안을 발표하게 되었다. 하나는 숏폼과 오디션을 결합한 '17초'(크리에이터 오디션) 라는 스트리밍 서비스, 다른 하나는 '렛츠디베이트'라는 온라인 토론 플랫폼이었다. 두 개 다 기획적으로는 좋은 평가를 받게 되었고, 우리 팀은 내부적으로 힘을 더 실고 있었던 '17초'를 가지고 프로젝트를 시작하기로 했다.

중간 발표까지

우리는 스트리밍을 위해 'openvidu'라는 라이브러리를 사용하기로 했다. 해당 라이브러리 문서를 정독하고, 그 외의 AWS, SSL, Docker, intelliJ 등등등등 여러 설정할 것들이 참 많아서 이를 조사하고 적용하느라 시간을 꽤 많이 썼던 기억이 난다.
openvidu를 우리 서비스에 맞게 커스터마이징 하고 제대로 동작하게 하는데에 고생을 많이 했다. 그래서 사실 중간발표 당시에는 스트리밍이 구현되지 않은 상태로, 다른 영상으로 대체해 시연을 했었다.
발표 후, 처음 기획이 가진 여러 장점에 비해 현재 구현된 내용이 거의 없고 발표도 미흡하다는 평을 받았다. 결국 거의 초반 기획단계로 거슬러 가다시피해서 남은 일정과 뒤늦게 깨닫게된 개발 속도를 고려하여 전체적인 스코프를 조정하기로 했다. 결국, 서비스 도메인을 '숏폼 컨텐츠'에서 '댄스 챌린지 컨텐츠'로 좁히기로 결정하고, 'PLAY DANCE LIVE!'라는 실시간 댄스 배틀 플랫폼을 구현하게 되었다.

마무리 발표까지

나로서는 초반 리서치에서 아직 헤어나오지 못한 상태로 중간발표를 하게 되고, 여러 부정적인 피드백과 위급 시그널을 파악하게 되자, 일단 되는대로 서비스가 작동하게만 구현을 빠르게 하자는 암묵적인 합의가 팀내에서 이루어졌다. 나는 팀장 형과 함께 프론트 사이드의 구현을 맡게 되었고, chat GPT를 아주 적극적으로 활용하면서 투표 시스템과 UI, 영상 레이아웃과 애니메이션, 연승 효과를 만들게 되었다. 와중에 영상과 오디오의 싱크 문제도 함께 파악하게 되어 팀장 형이 작성해두었던 openvidu 코드를 살펴보며 같이 고민했다. 결국 openvidu의 audioSource를 다른 음원 source로 대체할 수 있음을 알게 되었고, Web audio API를 활용하여 MP3 파일로 해당 audioSource를 대체하면서 싱크 문제를 해결할 수 있었다.

초반의 기대에 비해 프로젝트의 볼륨이 많이 줄어들긴 했지만, 그래도 얼추 한 판이 제대로 돌아가는 버전이 탄생하게 되었고, 시연을 위해 실제 춤까지 준비하여 마지막 발표를 하게 되었다. 하지만 예상치 못한 버그가 발생해 시연이 정상적으로 이루어지지는 않았고, 최종 발표일까지 디버깅을 하고 완성도를 높이는데 만전을 기했다.

최종발표와 포스터 세션

대망의 최종 발표일. 결론적으로는 우리가 바랄 수 있었던 시나리오중 최상의 시나리오대로 발표를 성공적으로 마무리했다. 최종 리허설 이후 네트워크 환경에 대한 걱정이 이만저만이 아니었는데, 다행히 발표장 와이파이는 정글 강의실의 것보다 매우 훌륭했다. 다행히 발표를 보러온 협력사 관계자분들, 운영진분들이 마음을 열고 크게 호응해주셨다. 우리 팀의 컨텐츠가 다름아닌 '춤'이었던 것도 무시할 수 없었다. 😅

발표 후의 질의 응답과 이후의 포스터 세션에서 생각해볼만한 좋은 질문들을 많이 들을 수 있었다. 정글 외부의 시선에서(약간의 격려가 섞여있긴 하지만,) 우리가 미처 생각하지 못했던 부분들을 많이 짚어주셨다.

• 투표 시스템에서의 어뷰징 행위에 대한 방어가 되어있는지?

  • 사실 현재 구현으로는 대응하지 못한다.
    질문을 듣고 떠올랐던 방안은, 버튼을 통한 api 요청에 '쿨타임' 같은 딜레이를 적용한다던지, 더 안전하게는 요청을 받는 서버가 같은 로그인 정보를 가진 요청에 대해 일정 시간내 최대 요청의 개수를 제한한다던지 하는 방안이 떠올랐다.

• 스프링 부트 선택 이유

  • 발표 직후 질의응답에서 나왔던 질문이었는데, 서버 구현을 담당했던 동료 형이 솔직하게 답변했다. 처음 기획은 앞서 언급했던 대로 대규모 스트리밍 서비스였는데, 스프링 부트가 대규모 트래픽에 적합한 프레임워크라는 정보를 여러 채널을 통해 확인했었기에 무게가 실렸고, 좀 더 솔직하게는 이후에 취업을 위해 선택했던 스택이었다. 하지만 5주전으로 돌아간다면, node.js로 서버를 구축해 좀 더 짜임새 있는 코드를 빠르게 작성하고 여러 기능들을 더 고민해 볼 수 있는 시간을 많이 가졌을 것 같다.

• 두 사람이 동시에 춤을 추게 하는 서비스를 하지 못했던 이유 (싱크 문제)

  • 현재 우리의 서비스는 두 명의 참가자가 번갈아가며 춤을 추는 형식이다. 기획적으로는 두사람이 동시에 춤 대결을 펼치는 것이 더 흥미로운 지점이 많았지만, 기술적으로는 많은 어려움이 예상되어 일단 번갈아 추는 것을 목표로 구현하고 각자의 춤과 노래의 싱크를 맞추는데 신경을 많이 썼다.
    그래도 간단하게 얘기가 나왔던 해결 방안으로는, 춤을 추는 두 사람은 서로 P2P로 연결해 같은 타이밍에 맞춰 춤을 출 수 있게 하고, 중계 서버는 이 둘이 보내는 stream을 실제 음원에 해당하는 하나의 타이밍을 통해 mixing한 후 산출된 stream을 시청자들에게 송출하는 방법이 언급되었다. 다만 이 경우 춤추는 두 사람과 시청자들 간에는 서버의 연산시간 만큼의 지연이 발생하게 된다.

• 싱크가 맞더라도, 네트워크 등의 문제로 방송 스트림 자체가 버벅거릴 때의 보정 여부

  • 이 경우도 사실 생각조차 하지 못했다. 영상과 음원의 싱크를 맞추는데 공을 많이 들였지만, 싱크가 맞은 후에도 네트워크 자체의 지연으로 영상이 뚝 뚝 끊길 수 있었다. 이에 대한 보정(?) 처리는 달리 고려하지 않았었는데 사실 질문을 듣고도 딱히 그럴듯한 해결 방안이 떠오르지 않았다. 추가적인 조사와 고민이 더 필요하다.

• 최대 몇명까지 시청이 가능할지?

  • 네트워크 상황만 잘 뒷받침 되어 준다면, 12명에서 15명 정도는 무리없이 시청할 수 있었다. 하지만 현재 구현 자체가 시연용에 최적화 되어있고, 춤을 추는 사람의 UI는 거의 개발자 용이나 다름 없어 시청자들의 의도하지 않은 조작이 서비스를 계속 다운시킬 수 있었다. 이는 완성도 측면에서 가장 먼저 보완해야 할 사항 중에 하나이다.

• 참가자가 중간에 나가는 경우나, 추가 참가자가 없을 경우의 예외처리

  • 이 또한 시연에 최적화된 구현 상황에서 고려되지 않았다. 원래 목표한 바로는 참가자가 중간에 나가는 경우에는 대기 중이었던 다른 참가자가 곧 바로 들어와 계속 진행이 되고, 추가 참가자가 없는 경우는 대기하게 된다. 다만 기획상으로는 경연 시간을 정하여 시청자와 참가자가 특정시간에 몰리게하는 서비스라 해당 상황에 대한 구현 중요도가 낮았다.

짧은 소회

돌이켜보면 꽤 괜찮은 판단을 했던 지점들이 있었던 것 같다.

• redis와 db 각각에 보관하는 정보를 구분할 때 했던 판단

  • 사실 redis를 처음 도입할 때 갑론을박이 있었다. 여러 자료들을 통해 살펴본 바로는 메인 DB에 대한 캐시로만 사용하는 것으로 이해를 했었는데, in memory db로서 사용될 수도 있었다. 결국 redis가 응용프로그램의 일종임을 상기하며 그것의 특성을 '빠른 처리 속도'와 'in memory'로 판단했고, 서비스에 사용되는 데이터 중 실시간성과 휘발성을 동시에 지닌 데이터 (e.g. 투표 데이터, 대기열 데이터)를 저장하는 db로 활용했다. 그리고 나머지 영속성이 보장되어야 하는 데이터 (e.g. 유저 연승 전적)등을 mysql에 저장하는 것으로 db를 이원화했다.

• 영상과 오디오의 싱크 맞추기

  • 앞서 언급하긴 했지만, 어쨋든 상용 라이브러리에 대한 커스터마이징이 빛을 발한 순간이었다. 팀장 형이 작성해놓은 코드를 살펴보고 이해하는 과정에서 audioSource 대체를 통한 해결방안 접근을 내가 제안하게 되었고, 팀장 형이 끝내 이를 구현하는 데에 성공했다.

• 중간에 도메인을 좁혔던 결정

  • 기술적인 부분은 아니지만, 현재 상황에 대한 현실적인 판단을 통해 계획을 과감하게 수정했고, 결과적으로 발표 완성도에 큰 영향을 미친 결정이 되었다. 어쩌면 MVP(minimum viable product)가 무엇인지 몸으로(?) 체감할 수 있었던 경험이었고, 초반 스코프를 결정하는 것이 얼마나 어려운지, 그리고 얼마나 중요한지 깨달았다.

개인적인 퍼포먼스 상으로 아쉬운 점도 있었다.

• 목표를 작은 단위로 쪼개지 못했음 (명확한 과제 없이는 작업을 스스로 시작하지 못했음)

  • 예전에 자전거 국토 종주를 하면서도 깨닫고 적어놓았던 부분인데, 작은 목표를 구체적으로 설정하는 것이 추진력에 얼마나 큰 영향을 미치는지 또 한번 깨달았다. 사실 이번에는 그렇게 하지 못해 초반에 손을 놓게 되는 시간이 많아서 너무 아쉬운 마음이다.

• 구현 전 조사하는 시간을 너무 많이 소비했음 (공부로 도망치기)

  • 핀토스를 할 때는 그래도 주어진 레퍼런스가 비교적 명확해 해당 자료를 빠르게 습득하고 구현에 미련없이 들어갔다면, 이번 자율 프로젝트는 말그대로 레퍼런스도 자율이라 스스로 절제하지 못하고 조사에 너무 몰두하여 시간을 많이 소비했다. 정글에 와서 여러번 느끼는 부분임에도 쉽게 고치지 못한 것이 너무 아쉽다.

• 체력이 부족했음

  • 솔직히 몸을 많이 버린 것 같다. 마감에 쫓기면서 밤샘도 정말 많이 했고, 카페인 섭취도 역대 최고치를 경신했던 것 같다.

여러모로 잘한 점도, 아쉬운 점도 많았던 최종 프로젝트지만 정글의 피날레였던 만큼 오래도록 기억에 남을 것 같다. 함께한 팀원들과 동기들에게 정말 감사하다.