배경
이번에 유료 강의 플랫폼을 만들면서, 강의를 구매한 사용자에게만 영상을 보여주기 위해 고민했어요.
처음엔 단순히 “재생을 제한해야 한다”는 기능 요구사항으로 접근했어요.
그런데 좀 더 생각해보니, 단순한 재생 제한 문제보다는 좀 더 복잡했어요.
- 어떤 사용자는 여러 디바이스를 사용하고 있고,
- 어떤 사용자는 영상 URL을 누군가와 공유할 수도 있고,
- 운영자는 사용자들이 어떻게 영상을 소비하는지 파악해야 하고,
- 무엇보다 정당하게 결제한 사용자에게만 자연스럽고 신뢰감 있는 경험을 제공하고 싶었어요.
이러한 문제를 고려해서 Mux의 signed playback token 을 활용하게 되었어요.
Mux 는 일정 시간 동안만 유효한 token을 기반으로 영상 재생을 허용하기 때문이었어요.
다만 이 token을 언제, 어떻게 생성하고 전달할지를 설계하는 게 중요했어요.
고민한 선택지
1) CSR + API Call
- 클라이언트에서 재생 시점에 토큰을 요청해 받아오는 구조였어요.
- 비교적 익숙하고 구현도 상대적으로 간단해 보였어요.
- 하지만 이 방식은 사용자 인증과 재생 권한 판단이 서버와 분리되다 보니,
클라이언트에서 video ID만 알아도 토큰 요청을 시도할 수 있는 구조가 되었어요.
2) SSR + Server Component
- 서버에서 인증된 사용자에 한해서만 token을 발급하고,
<MuxPlayer />에 바로 전달하는 방식이었어요.
- 이 방식은 인증 확인과 token 생성, UI 렌더링까지 한 흐름 안에서 자연스럽게 이어졌고,
사용자에게는 보이지 않지만, 신뢰할 수 있는 안전한 흐름을 만들 수 있었어요.
선택한 해결책과 그 이유
결국 저는 SSR 기반의 Server Component 방식을 선택했어요.
- 사용자의 진짜 문제는
결제하지 않은 사용자도 영상을 볼 수 있게되는 것이 아닐까, 가능한 이 부분을 막아보자 하는 생각이었어요.
- 그 과정에서 기술적인 해결책에 대한 고민은
민감한 정보를 클라이언트에 노출시키지 않고, 서버에서 가능한 모든 판단을 하고 안전하게 영상을 가져오는 구조를 만드는 것이었어요.
- 비즈니스 감각을 잃지 않는다는 건,
유료 강의라는 콘텐츠 자산을 보호하면서도, 사용자 경험을 해치지 않고 자연스럽게 접근 제어를 구현해서 브랜드 신뢰와 수익 모델을 동시에 지키는 것이었어요.
배운 점
이번 경험을 통해, 단순히 “토큰을 발급해서 영상을 재생하면 된다”는 수준에서
보안 수준을 어디까지 고려해야 신뢰를 줄 수 있는지 고민하게 되었어요.
그리고 Product Engineer로서 항상 기억해야 할 건,
사용자에게 공감하며,
기술적으로 가장 안전하고 명료한 해결책을 설계하며,
비즈니스가 지속 가능하도록 책임지는 선택을 하는 일이라는 걸 다시 느꼈어요.
이 구조는 당장 사용자에게 보이지 않을 수 있지만,
그 안에서 우리가 사용자와 맺는 신뢰, 제품의 철학, 기술적인 태도가 드러나는 것 아닐까 하는 생각이 들었어요.
