[회고] 유레카 부트캠프 프론트엔드 과정: 융합 프로젝트 O+T

 

약 1달 간 진행한 융합 프로젝트에 대한 회고를 해보고자 한다. 다른 프로젝트와는 달리 프론트엔드만을 담당했기에 프론트엔드 위주로 작성하려고 한다.

 

주제는 총 4개가 있었으며, 4개 중 순위를 매기면 강사님과 매니저님이 각 주제에 배정해주는 방식이었다.

 

 

💼 FE Github - User Repo

GitHub - OpenTheTaste/frontend: 유레카 3기 융합 프로젝트 O+T의 프론트엔드 입니다

 

💼 FE Github - Admin Repo 

GitHub - OpenTheTaste/admin: 유레카 3기 융합 프로젝트 O+T의 프론트엔드 백오피스 입니다

 

 

📌 주제

콘텐츠 OTT 서비스 플랫폼 (데이터 분석 기반 맞춤형 콘텐츠 추천 서비스)

 

 

⚙️ 프론트엔드 기술스택

• React `^19.2.3`
• Next.js `^16.1.6`
• TypeScript `^5.9.3`
• Tailwind CSS `^4.2.1`
• Tanstack Query `^5.90.21`
• Zustand `^5.0.11`
• husky `^9.1.7`
• eslint `^9.39.3`

 

 

🏃🏻 유저 플로우차트

온보딩	홈 (메인)

콘텐츠 상세 페이지	마이페이지

 

 

🏃🏻 백오피스 유저 플로우차트

 

관리자와 에디터 백오피스 접근이 가능하지만, 에디터가 접근 가능한 도메인은 숏폼 관리 + 모니터링(대시보드 x)였다.

 

관리자 + 에디터 

로그인	숏폼 관리	모니터링 (대시보드는 only 관리자)

 

only 관리자

시리즈 관리	콘텐츠 관리	전체 유저 관리

 

 

🌆 피그마 - 디자인시스템 및 UI 구성

유저 페이지

 

 

백오피스

 

 

 

👾 내가 맡은 파트

▪︎ Jira 세팅 및 Github Actions를 통한 자동화 설정

이번에도 저번 종합 프로젝트와 같이 Jira와 Github Actions, husky를 사용해서 프로젝트 일정 + 이슈 관리를 도맡아 했다.

저번에 했던 것과 비슷하게 적용했다.

그래도 종합때와는 다른 점은 프론트엔드/백엔드 구분을 위해서 아래 이미지와 같이 에픽 앞에 [분야]를 붙이도록 강제했던 점이 다르다고 할 수 있다.

 

 

▪︎ 콘텐츠 (시리즈) 상세 페이지

이번 프로젝트 기획 상 콘텐츠(단편, 시리즈별 에피소드), 시리즈 원본 페이지를 따로 구분지어서 개발했어야 해서 url를 구분 짓는 게 쉽지 않았다.

타 OTT는 어떻게 url을 설정했나 확인해보기 위해 직접 눈물의 시장 조사(= 결제)를 하기도 했다. 

 

아쉬운 점은 프로젝트 후반으로 갈수록 점점 추가되는 쿼리스트링으로 인해.. 이런 식으로 url을 정리해서 파악해야 될 정도로 복잡해진 것이 조금 아쉽긴 했다.

 

그래도 해당 페이지를 구현하면서 댓글, 플레이리스트 목록 등 다양한 기능을 구현해 볼 수 있어서 좋았다.

 

추가적으로 홈 화면에서 진입하는 플레이리스트에 따라서 우측 하단의 다음 재생목록을 다르게 구현하기 위해서 쿼리스트링에 playlist param을 추가하는 부분도 구현했다. (아래 notion 참고) 

 

[FE] 진입 경로 기반 재생목록 유지 구조 설계 | Notion

 

 

 

▪︎ 영상 플레이어

사실 핵심이라고 볼 수 있는 기능을 감사하게도 저에게 기회를 주셔서 구현을 맡게 되었다. 

 

플레이어를 구현하기 위해 react-player 라이브러리를 사용하려고 했으나, 라이브러리 특성상 구현의 한계가 있어서 직접 hls.js 를 커스텀해서 사용하기로 했다. 이 과정에서 재생바, 음량 조절, 화질 조절, 뒤/앞으로 가기 등 직접 구현하느라 코드가 거의 600줄이 되는 경험을 하게 되었다.

관리해야 할 상태도 너무 많았고 생각보다 신경 써야 될 UX적 측면이 많아서 좋은 경험이었다.

player 구현

 

 

▪︎ 영상 플레이어 - 다음 영상 자동 재생

필수 구현 기능 중, 다음 영상 자동 재생 기능을 구현해야 했다.

그래서 영상 길이의 95%가 지나면, 다음 영상 자동 재생 banner 컴포넌트를 호출해서 클릭 시 다음 화 재생 or n초 뒤 다음화 자동 재생 기능을 구현했다.

 

 

▪︎ 영상 플레이어 - PIP 구현

기존에는 PIP (Picture In Picture)를 구현할 생각은 없었다. 그러나 현직자 멘토링 이후 우리 프로젝트의 컨셉을 2030 멀티태스킹으로 잡게 되면서 PIP는 선택이 아닌, 필수가 되었다. 그래서 구글링 해보니 쉬울 것 같아서 도입하기로 했다. 

그러나 JavaScript에서 브라우저 pip를 지원해주는 것은 플레이어 DOM을 벗어나지 않는 경우에만 지원이 됐고, DOM을 벗어나는 순간 영상 재생이 안 돼서 PIP도 커스텀해서 구현하게 되었다.

 

PIP의 핵심은 현재 재생 위치를 유지하기 위해 m3u8 src, currentTime을 zustand에 저장하여 전역 상태로 관리하게끔 하였고, 브라우저를 4분할로 나눠서 pip를 드래그하면 상/하, 좌/우 위치를 비교하여 가까운 가장자리로 이동하게 하는 등 PIP의 추가적인 기능을 구현하였다.

pip 구현

 

 

▪︎ 숏폼 스와이프/스크롤 애니메이션 구현

숏폼이 기존에는 따로 애니메이션 없이 다음 숏폼으로 넘어가도록 구현되어 있었다. 하지만 예선 진출 이후 이를 보완하고자 스와이프/스크롤 애니메이션을 추가했다.

 

애니메이션을 구현하기 위해 framer motion을 사용하려고 했지만, 레퍼런스가 많지 않아서 기본 CSS의 scrollSnap을 사용하여 구현했다.

 

[OT-367] [FIX]: scroll-snap으로 다음화 슬라이드 애니메이션 구현 · OpenTheTaste/frontend@d9603a3

 

숏폼 스와이프/스크롤 애니메이션

 

 

▪︎ 검색 기능

검색 기능에는 큰 특이사항(자동완성 등)이 없었어서 금방 구현할 수 있었다. 검색어에 '제목'을 입력하면 그에 맞는 콘텐츠 포스터를 렌더링하는 방식으로 구현했다.

백엔드 분들이 API를 잘 구현해 주셔서 빠르게 구현할 수 있었다.

 

 

 

▪︎ 백오피스 - 관리자 로그인, middleware 처리

백오피스 관리자 로그인은 OAuth를 사용하지 않고, id와 pw를 입력하는 로그인 방식을 채택했다. 쿠키에 저장된 토큰이 없으면, 백오피스에 접근하지 못하도록 하고 `/auth/login`으로 redirect 되도록 구현했다.

이때, 백엔드의 domains 설정이 배포 주소 기준으로 되어있어서 로컬 프론트 개발환경에서는 쿠키가 정상적으로 전달되지 않는 문제가 발생했다. 그래서 개발환경에서는 middleware의 토큰 검증을 수행하지 않도록 처리했다.

 

이에 관한 트러블슈팅은 아래 포스트에 작성해두었다.

[Next.js] middleware (proxy)에서 쿠키를 읽지 못한다? 알고보니 도메인 설정 (ft. 로컬 프론트 - 배포 서

 

 

 

▪︎ 백오피스 - 콘텐츠/숏폼 관리 - multipart upload 구현

영상과 메타데이터를 AWS S3에 멀티파트로 업로드하는 기능 구현을 맡았다. 이전 프로젝트에서 S3에 이미지 url을 서버로 보내서 서버가 S3에 업로드하는 방식을 구현해 본 경험이 있었다. 그렇기에 이번에도 그 방식대로 하면 될 줄 알았다.

그러나 이번에는 "영상"을 업로드하는 것이라 서버에 부하를 최소화하기 위해서 클라이언트 측에서 S3에 직접 업로드하는 방식을 채택했다.

 

위 내용은 아래 notion에 작성해두었다.

 

[FE] S3 멀티파트 업로드 로직 | Notion

 

 

📹 시연영상

https://www.youtube.com/watch?v=LIwTDKfkAxQ

 

💫 회고 

🌝 좋았던 점

 

▪︎ Hls.js를 사용한 플레이어 구현
이제 OTT는 선택이 아닌, 필수가 되어버린 사회에서 플레이어를 구현할 수 있는 경험은 정말 뜻깊고 소중한 경험이었다. 특히 팀프로젝트 + 경진 대회라는 특별 조건이 붙으니 UX 측면에서 더욱 고심해서 구현할 수 있어서 좋았다. 그리고 무엇보다 다른 팀원도 구현해보고 싶어 했는데 기회를 양보해 주어서 너무 감사하다..

 

▪︎ 실무 같은 팀프로젝트
이번에는 정말 '프론트엔드'만 맡아서 구현했기에 지난 두 번의 팀프로젝트와는 규모가 차원이 달랐다. 지난 프로젝트에서는 백엔드도 야매로 구현했기 때문에 규모가 크지 않았다. 그러나 이번엔 백엔드 반 팀원들과 기획부터 함께 진행을 하면서 백엔드 팀원과 회의를 정말 많이 하고, 어떤 방향으로 구현되면 좋을지에 관해서 여러 차례 대화를 나누게 되니 의사소통 방식에 있어서도 고민을 많이 하게 되었던 것 같다.

 

 

▪︎ FSD 아키텍처 도입 및 alias 올바르게 사용하기
지난 종합 프로젝트 심사위원으로 와주셨던 멘토님께서 이번 멘토링 때도 와주셔서 alias를 올바르게 사용하는 방법을 알려주셨다. 그래서 index.ts를 사용해서 경로 설정을 하니 실제로 컴포넌트명을 수정하는 일이 생겼을 때, 편하고 빠르게 수정할 수 있었다. 

 

또한 실무에서 사용하는 폴더 구조도 자세히 설명해 주셔서 폴더 구조에 관해서도 많이 고민해 보게 되었다. 멘토님께서 말씀해 주신 폴더 구조에 대해서 찾아보니 FSD 아키텍처와 유사해서 이를 실무에서 사용한다는 것도 알게 되었고, 이를 도입해 보는 게 어떠냐는 피드백을 받았다. 사실 프로젝트 진행 중간에 받은 피드백이라 폴더 구조 리팩토링 작업을 하는 게 쉽지는 않았고, 헷갈리기도 엄청 헷갈렸다.

그래도 한번 적용해보고 나니 자신감이 생겼던 것 같다. 그래도 아직 어렵긴 하다 ..

다음 프로젝트를 하게 되면 처음부터 FSD 아키텍처와 모노레포를 도입해서 구현하는 작업도 해봐야겠다는 생각이 들었다.

 

 

▪︎ UX 측면에서의 깊은 고찰
이번 프로젝트를 하면서 UX 측면에서 깊게 생각해 보게 되었다. 아무래도 기존 OTT들이 많다 보니, 더 UX를 신경 쓰게 됐던 것 같다. 특히 백엔드 팀원분들도 배포 환경을 둘러보면서 보이지 않았던 UX 측면에서의 문제를 잡아주셔서 더 세세하게 신경쓰게 된 것 같아 감사하다.

 

 

 

🌚 아쉬웠던 점

 

▪︎ 멘토링 시간 활용

이번에는 총 4번의 멘토링 시간이 있었다. 사실 2번째 멘토링 때까지는 프로젝트의 전반적인 기획, UI 등을 피드백받을 수 있어서 알차게 사용했다. 그러나 사실 매주 멘토링이 있다 보니, 마지막 멘토링을 잘 활용을 못한 점이 아쉬웠다. 그리고 멘토님께서 포트폴리오, 이력서도 봐주신다고 하셨는데 준비된 게 없어서 보여드릴 것이 없었던 것이 참 정말 너무 아쉽다.. 이 글을 보는 4기 분들은 미리 준비하고 가시면 좋은 기회가 될 것 같다!

 

▪︎ 프로젝트 측면에서 아쉬운 점이 없는 게 아쉽다

사실 이번 프로젝트에서는 정말 최선을 다했다고 말할 수 있다. 그나마 아쉬운 점은 짧은 시간에 많은 필수 요구 기능을 구현해야 했어서 AI를 많이 사용했다는 점이 아쉽다. 그래도 내가 하고 싶었던 플레이어나 업로드 기능을 구현해 봤다는 점이 너무 좋았다! 

 

 

---

마치며 ..

끝날 것 같지 않았던 마지막 최종 융합 프로젝트가 끝나게 되었다. 처음엔 백엔드분들과 정말 어색했고 낯을 많이 가렸다. 아직도 첫날의 팀회식이 기억에 남는다 .. 정말 어색했다... 그래도 매일 아침마다 회의 + 스크럼을 진행하면서 어색함이 점차 풀렸고, 매주 하루씩은 점심을 같이 먹는 시간을 가져서 더욱 프로젝트에 애정이 가게 되었던 것 같다.

그래서 사실 본선 진출하게 되었을 때 너무 행복했고, 본선 전날까지 수정의 수정을 거치며 후회가 없을 만큼 수정을 했던 것 같다.

수상을 하지 못한 점은 살짝 아쉽긴 하지만 좋은 사람들과 좋은 경험을 할 수 있어서 깔끔하게 보내줄 수 있을 것 같다!

 

저는 부트캠프에 대한 마지막 회고로 돌아오겠습니다