Cloudflare Stream 도입기 1: 영상 전달 구조와 시청 비용 계산

유료 강의를 Cloudflare Stream으로 옮기며 먼저 정리한 것은 플레이어보다 영상의 전달 경로였습니다. 파일 보관, 재생 권한, 시청 비용은 서로 다른 문제였습니다.

서비스의 초기 강의 화면은 YouTube iframe을 사용했습니다. 이후 자체 서비스 안에서 유료 강의를 제공하고, 수강권에 따라 재생을 허용하는 방향을 정했습니다. 이번 글에서는 그 과정에서 구분한 개념을 정리합니다. HTTP 요청과 웹 서버의 기본 구조를 알고 계신다고 가정합니다.

동영상 파일을 올린 다음에도 할 일이 남습니다

MP4를 저장하고 주소를 연결하면 영상이 재생되는 화면은 만들 수 있습니다. 하지만 긴 강의를 모바일에서 안정적으로 전달하려면 원본 보관 외에도 인코딩, 여러 화질 준비, 네트워크 상태에 따른 재생, 전송량 관리를 생각해야 합니다. 이 작업을 직접 운영할지 관리형 서비스에 맡길지가 첫 선택이었습니다.

Cloudflare Stream은 업로드·보관·인코딩·전달을 하나의 서비스로 제공합니다. 공식 문서는 H.264 기반의 적응형 비트레이트와 360p부터 1080p까지의 지원 범위를 설명합니다. 관리형 서비스를 선택한 이유는 이 전달 계층을 맡기고, 자체 서버를 수강권과 진도 처리에 집중시키기 위해서였습니다. Cloudflare Stream 개요를 기준으로 확인했습니다.

스트리밍도 브라우저로 데이터를 내려보냅니다

스트리밍이라고 해서 영상 데이터가 사용자 기기에 전달되지 않는 것은 아닙니다. HLS에서는 재생목록과 영상 조각인 세그먼트를 HTTP로 요청합니다. 여러 품질의 재생목록을 준비하면 플레이어가 네트워크 상황에 맞춰 사용할 품질을 선택할 수 있습니다. 이 구조는 일반 HTTP 캐시와도 함께 동작합니다. 프로토콜의 기본 개념은 RFC 8216에서 확인할 수 있습니다.

여기서 두 가지를 분리해야 했습니다. 적응형 스트리밍은 재생 품질과 전달 방식에 관한 기술입니다. 유료 수강생만 볼 수 있게 만드는 접근 제어는 별도로 설계해야 합니다. 영상이 여러 조각으로 나뉜다는 사실만으로 복제가 방지되지는 않습니다.

우리 서버는 허용 여부를 판단하고, 영상은 CDN이 전달합니다

이번 구현에서는 학생이 먼저 교육 서비스의 백엔드에 재생을 요청합니다. 백엔드는 로그인과 수강권을 검사하고 짧게 유효한 재생 토큰을 발급합니다. 그다음 브라우저는 Cloudflare의 플레이어와 영상 전달 경로를 사용합니다. 영상 본문을 교육 서비스의 API 서버로 다시 중계하지 않습니다.

학생 브라우저 → 교육 서비스 API: 재생 권한 요청
교육 서비스 API → 학생 브라우저: 만료 시간이 있는 재생 주소
학생 브라우저 → 영상 전달 서비스: 플레이어와 영상 조각 요청
학생 브라우저 → 교육 서비스 API: 시청 구간 기록

이 구조를 제어 경로와 데이터 경로의 분리로 이해했습니다. 누가 무엇을 볼 수 있는지는 우리 서비스의 정책이고, 실제 영상 바이트를 보내는 일은 전달 서비스의 역할입니다. API 서버의 영상 중계 부담은 줄어들지만, 로그인·DB·재생 권한 확인에 필요한 서버 비용까지 없어지지는 않습니다.

영역	이번 구현의 담당	확인할 정보
수강 권한	교육 서비스 백엔드	학생·상품·유효 상태
영상 전달	Cloudflare Stream	인코딩·재생·전달량
학습 기록	교육 서비스 DB	회차·영상 버전·시청 구간

비용은 파일 크기와 시청 시간 중 무엇으로 계산할까요

2026년 10월 11일 확인한 일반 Stream 요금은 저장 용량 1,000분당 월 5달러, 전달 1,000분당 1달러입니다. 영상 입력과 인코딩 비용, 별도 대역폭 요금은 이 구조에 포함됩니다. 실제 계약의 번들·포함량은 별도로 확인해야 합니다. 이 글의 계산은 공식 일반 요금표를 이용한 예시이며 특정 계정의 청구 예상서는 아닙니다.

예를 들어 20분짜리 강의 10개를 50명이 한 번씩 모두 본다고 가정해 보겠습니다. 저장 기준은 200분이고, 명목 시청량은 10,000분입니다. 저장 용량 한 단위 5달러와 전달 10달러를 합치면 15달러가 계산됩니다. 세금·환율·다른 서비스 비용은 제외한 값입니다. 인원이 늘거나 반복 재생이 많아지면 저장할 강의 수가 그대로여도 전달 비용은 늘어날 수 있습니다.

다만 재생 시간과 청구 전달량이 정확히 일치하는 것은 아닙니다. 공식 문서상 미리 불러오기와 버퍼링도 전달량에 포함되며, 브라우저 캐시에서 다시 재생한 데이터는 새 전달로 과금되지 않습니다. 따라서 실제 운영에서는 계산식과 함께 제공자 사용량을 확인해야 합니다. 단순히 페이지 조회 수에 영상 전체 길이를 곱하면 과대 추정할 수 있습니다.

전달량, 진도율, 전환율은 다른 숫자입니다

같은 학생이 20분 강의를 두 번 봤다고 가정해 보겠습니다. 영상 전달 서비스에서는 추가 요청이 발생할 수 있습니다. 학습 진도에서는 이미 본 구간을 다시 더하면 안 됩니다. 방문 분석에서는 수강 신청이나 결제와 연결된 행동을 별도로 봐야 합니다. 세 숫자를 같은 지표로 다루면 비용과 학습 성과를 모두 잘못 이해하기 쉽습니다.

이번에는 자동 재생과 미리 불러오기를 끄고, 수강권을 확인한 다음 플레이어를 만드는 구조를 적용했습니다. 불필요한 요청을 줄이려는 선택이지, 비용의 절대 상한을 보장하는 장치는 아닙니다. 사용량 경보와 비용 통제 정책은 별도 운영 과제로 남습니다.

초안 작성 시점에는 서버와 플레이어 연결, 로컬 DB, 모의 영상 제공자를 이용한 회귀 검증까지 진행했습니다. 실제 강의 영상으로 하는 검수는 아직 하지 않아 인코딩 품질·음성·실제 전달량은 확인하지 못했습니다. 다음 글에서는 이 전달 경로에 재생 권한을 붙이기 위해 사용한 서명 URL과 만료 시간의 의미를 다룹니다.