내 클라우드를 가져오고, 영상을 지키고, 마크업을 없애세요.
BYOC는 Nulx의 운영 방식입니다. 이 페이지는 이 카테고리를 정의하고, 매니지드 플랫폼 및 직접 구축과 정직하게 비교하며, 누구에게 맞지 않는지도 분명히 말합니다.
정의
BYOC 비디오 인프라의 의미
BYOC(bring-your-own-cloud) 비디오 인프라란 영상이 벤더의 계정에 들어가지 않는 방식입니다. 원본 파일은 고객의 S3 또는 R2 버킷에 저장됩니다. 처리는 그 버킷에서 읽어서 결과물을 다시 같은 버킷에 씁니다. 재생은 고객의 CDN에서 서빙됩니다. 벤더는 작업을 오케스트레이션할 뿐 자산을 보관하지 않습니다. 실질적인 결과는 이렇습니다. 벤더가 스토리지와 대역폭을 전혀 건드리지 않기 때문에 마크업할 대상 자체가 없습니다.
비디오를 운영하는 세 가지 방식
매니지드 vs. BYOC vs. 직접 구축
같은 작업을 세 가지 소유권·비용 모델로 비교합니다.
| 매니지드 | BYOC | 직접 구축 | |
|---|---|---|---|
| 영상이 저장되는 곳 | 벤더 계정 | 내 계정 | 내 서버 |
| 전송 요금 | 벤더 마크업 | 클라우드 직결 요금 | 클라우드 직결 요금 |
| 운영 부담 | 없음 | 없음 | 전부 내가 |
| 벤더가 종료되면 | 자산 위험 | 영향 없음 | 해당 없음 |
| 국경 간 데이터 이전 | 발생 | 발생 안 함 | 발생 안 함 |
모델의 기원
엔터프라이즈에서는 오래된 방식, 비디오만 늦었을 뿐
Bring-your-own 방식은 새로운 것이 아닙니다. 소유권과 마크업이 함께 묶여 있다는 사실을 깨달은 구매자들 덕분에, 엔터프라이즈 소프트웨어는 몇 년 전부터 bring-your-own-storage와 bring-your-own-key를 채택해 왔습니다. 비디오 인프라만 늦었을 뿐입니다. 초창기 플랫폼들이 그렇게 만들어졌기 때문에 라이브러리를 벤더 계정에 업로드하는 것이 표준처럼 굳어졌습니다. 클라우드 스토리지가 저렴해지고 S3 호환 API가 표준이 되면서, 소유권을 넘겨야 할 이유는 사라졌습니다.
솔직한 한계
이런 경우 BYOC는 맞지 않습니다
- 클라우드 계정이 없고 만들 생각도 없는 경우. 매니지드 플랫폼이 더 낫습니다.
- 월 시청 시간이 대략 500시간 미만인 경우. 이 규모에서는 절약되는 마크업보다 정액 요금이 더 큽니다.
- 편집 워크플로를 갖춘 완전한 CMS가 필요한 경우. BYOC는 뉴스룸 도구가 아니라 인프라입니다.
- 가동 시간을 처음부터 끝까지 누군가에게 맡기고 싶은 경우. BYOC에서는 스토리지와 CDN이 내 계정에 남기 때문에 일부 구간은 고객의 몫입니다.
위 중 하나라도 해당된다면 가입하지 않는 편이 낫습니다. 해지는 서로에게 비용이 듭니다.
적합한 경우
BYOC가 맞는 팀
- 이미 AWS, Cloudflare 또는 다른 S3 호환 클라우드를 쓰고 있고, 영상도 나머지 인프라와 같은 곳에 두고 싶은 팀.
- 월 시청량이 충분히 커서 GB당 마크업이 비디오 비용에서 가장 큰 항목인 팀.
- 제3자에게 미디어를 넘기는 것이 심사의 걸림돌이 되는 컴플라이언스·데이터 상주 요건이 있는 팀.
- 마이그레이션 프로젝트 없이 언제든 떠날 수 있는 선택지를 원하는 팀.
흔한 오해
BYOC에 대한 다섯 가지 오해
| 오해 | 실제 |
|---|---|
| “결국 셀프호스팅 아닌가요?” | 인코딩, 오케스트레이션, 플레이어 파이프라인은 저희가 운영합니다. 고객에게 넘어가는 것은 운영이 아니라 파일 소유권뿐입니다. |
| “설정이 복잡할 것 같은데요.” | IAM 정책 하나와 버킷 이름이면 끝입니다. 대부분의 팀이 약 3분 만에 마칩니다. |
| “더 비싼 거 아닌가요?” | 월 시청 시간이 대략 500시간 미만이면 맞는 말입니다. 정액 요금이 절약되는 마크업보다 큽니다. 그 이상에서는 계산이 뒤집힙니다. |
| “벤더가 내 버킷에서 무엇을 할 수 있나요?” | Nulx가 요청하는 IAM 권한은 전문이 공개되어 있습니다. 고객이 지정한 프리픽스에 대한 읽기·쓰기뿐입니다. |
| “성능은요?” | 재생은 고객의 CDN에서 나가므로 리전과 캐시 동작을 직접 고릅니다. 지금 서빙하는 다른 자산과 동일한 전송 성능입니다. |
작동 원리
기술적으로 어떻게 동작하나
아키텍처는 의도적으로 단순합니다. 바이트는 가능한 가장 짧은 경로를 지나고, Nulx는 메타데이터만 다룹니다.
내 버킷
업로드는 고객의 자격 증명으로 S3 또는 R2 버킷에 바로 저장됩니다. Nulx는 바이트를 프록시하지 않습니다.
제자리 처리
워커는 범위가 제한된 IAM 역할을 맡아 원본을 읽고 인코딩한 뒤 결과물을 같은 버킷에 씁니다. 미디어는 Nulx 인프라로 넘어가지 않습니다.
내 CDN
재생 URL은 고객의 CDN 도메인으로 해석됩니다. Nulx는 메타데이터와 매니페스트를 제공하고, 세그먼트는 고객의 CDN이 서빙합니다.
다음 단계
내 계정에 정확히 무엇이 설치되는지 확인하세요
설정 가이드에서 IAM 정책, 버킷 구조, 모든 권한을 권한을 부여하기 전에 미리 볼 수 있습니다.