용량은 곱셈 한 번입니다
영상 파일의 크기를 정하는 것은 해상도도 프레임도 아니고 비트레이트입니다. 초당 몇 비트를 쓰기로 했는지에 재생 시간을 곱하면 총 비트 수가 나오고, 8로 나누면 바이트가 됩니다.
용량(byte) = (영상 Mbps × 1,000,000 + 오디오 kbps × 1,000) × 초 ÷ 8
해상도와 프레임은 "이 화질을 유지하려면 비트레이트가 얼마나 필요한가"를 통해 간접적으로 영향을 줄 뿐입니다. 4K로 찍어도 비트레이트를 5Mbps로 묶으면 파일은 작아지고 대신 화면이 뭉개집니다.
MB가 두 종류라 계산이 어긋납니다
이 주제에서 사람들이 가장 많이 틀리는 지점입니다. 비트레이트의 M은 1,000,000이고 파일 탐색기의 MB는 1,048,576바이트입니다. 접두어는 같은 M인데 크기가 4.86% 다릅니다.
| 표기 | 실제 값 | 어디서 쓰나 |
|---|---|---|
| 1 Mbps | 1,000,000 비트/초 | 인코더 설정, 인터넷 속도, 방송 규격 |
| 1 MB (MiB) | 1,048,576 바이트 | 윈도우 탐색기, 안드로이드·iOS 표시 |
| 1 MB (SI) | 1,000,000 바이트 | SSD·USB 제조사 표기, 맥OS 표시, 일부 리눅스 도구 |
8Mbps로 10분을 찍으면 총 4,800,000,000비트, 즉 600,000,000바이트입니다. 저장장치 기준으로는 정확히 600MB이지만 윈도우 탐색기에는 572MB로 뜹니다. 같은 파일인데 숫자가 다릅니다. 이 계산기는 두 값을 모두 표시하고 대표값으로는 탐색기 기준을 씁니다. 실제로 "메일 첨부 25MB 한도" 같은 제한이 어느 기준인지는 서비스마다 다른데, 경계에 아슬아슬하게 걸릴 때는 작은 쪽(1,048,576)으로 계산해 두면 안전합니다.
권장 비트레이트는 어디서 온 숫자인가
계산기의 표는 유튜브가 공개한 업로드 권장 비트레이트(SDR 기준)를 바탕으로 하고, H.265와 AV1은 같은 화질을 내는 데 필요한 비트레이트가 각각 약 60%, 50%라는 널리 쓰이는 경험칙을 곱한 값입니다. 프레임이 30을 넘으면 한 단계 높은 구간을 씁니다.
코덱 효율의 60%·50%는 평균적인 이야기이고 실제로는 콘텐츠에 따라 크게 흔들립니다. 정지 화면이 많은 강의나 프레젠테이션 녹화는 H.265로 바꿨을 때 절반 이하로 줄기도 하고, 화면 전체가 빠르게 움직이는 게임 영상은 차이가 훨씬 적습니다. 인코딩 프리셋을 빠르게 잡으면 효율이 더 떨어집니다.
같은 용량이면 어느 쪽을 포기할까
용량 한도가 정해져 있을 때 선택지는 셋입니다. 해상도를 낮추거나, 비트레이트를 낮추거나, 코덱을 바꾸는 것입니다.
보통은 코덱 교체가 손해가 가장 적습니다. 화질을 그대로 두고 용량만 줄이는 방법이기 때문입니다. 그다음은 해상도를 한 단계 내리는 쪽입니다. 1080p를 720p로 내리면 권장 비트레이트가 약 40% 줄어드는데, 화면 전체가 균등하게 부드러워지므로 시청 경험이 자연스럽습니다. 가장 나쁜 선택은 해상도를 유지한 채 비트레이트만 크게 깎는 것입니다. 이 경우 움직임이 많은 장면에서만 블록이 튀어나오는 불균등한 열화가 생기고, 사람 눈은 이런 불규칙한 손상을 특히 잘 알아챕니다.
업로드 시간이 계산보다 오래 걸리는 이유
업로드 속도 100Mbps는 회선이 이론적으로 낼 수 있는 최대치입니다. 실제로는 TCP 헤더와 재전송에 몇 퍼센트, 서버까지의 왕복 지연에 따른 처리량 손실에 더 큰 몫이 나갑니다. 집에서 다른 기기가 인터넷을 쓰고 있으면 그만큼 또 나뉩니다. 그래서 계산기는 이론값과 함께 실효 55~75% 구간을 함께 보여 줍니다.
거기에 더해 유튜브나 클라우드는 파일을 다 받은 뒤 서버에서 여러 화질로 다시 인코딩합니다. 업로드 진행률이 100%가 되고도 한참 "처리 중"인 것이 이 과정이고, 4K 장편이라면 업로드 자체보다 오래 걸리기도 합니다. 이 시간은 회선 속도와 무관해서 계산으로 예측할 수 없습니다.
CBR과 VBR
이 계산은 비트레이트가 처음부터 끝까지 일정하다고 보는 CBR 방식입니다. 실제로 많이 쓰는 VBR은 복잡한 장면에 비트를 더 주고 단순한 장면에서 아낍니다. 평균 비트레이트를 목표로 잡는 2-pass VBR이라면 결과 용량이 계산값에 가깝게 맞지만, 화질을 기준으로 잡는 CRF·CQ 방식은 용량을 미리 알 수 없습니다. 이 경우 30초 정도를 시험 인코딩해 나온 용량에 배수를 곱해 추정하는 편이 빠릅니다.
같이 보면 좋은 계산
단위 변환 전반은 단위 변환기, 화면 크기와 해상도의 관계는 화면 크기 계산기와 모니터 시청 거리 계산기에 있습니다. 사진 쪽 출력 크기는 사진 인화 계산기, 영상으로 수익을 추정해 보려면 콘텐츠 수익 계산기를 보세요.
자주 묻는 질문
왜 계산값과 실제 파일 크기가 조금 다른가요?
컨테이너 오버헤드 때문입니다. MP4나 MKV는 영상·오디오 데이터 말고도 인덱스, 타임스탬프, 메타데이터를 함께 담는데 보통 전체의 0.5~2% 정도입니다. 또 대부분의 인코더는 지정한 비트레이트를 평균으로 삼을 뿐 매 초 정확히 맞추지 않습니다. 자막이나 챕터를 넣었다면 그만큼 더 늘어납니다. 몇 퍼센트 차이는 정상 범위로 보면 됩니다.
해상도를 올리면 용량이 자동으로 늘어나나요?
아닙니다. 용량을 정하는 것은 비트레이트뿐입니다. 4K로 촬영해도 비트레이트를 5Mbps로 고정하면 1080p 5Mbps와 파일 크기가 같습니다. 다만 4K는 픽셀 수가 네 배라 같은 비트를 훨씬 넓게 나눠 써야 하고, 그래서 화질 유지에 필요한 비트레이트가 올라갑니다. 해상도가 용량에 간접적으로 영향을 준다는 말은 이런 뜻입니다.
유튜브에 올릴 때 권장값보다 높게 넣으면 화질이 좋아지나요?
어느 정도까지만 그렇습니다. 유튜브는 받은 파일을 자기 기준으로 다시 인코딩하기 때문에 최종 화질은 유튜브 쪽 설정에 좌우됩니다. 다만 원본이 이미 뭉개져 있으면 재인코딩으로 복구되지 않으므로 권장값보다 조금 넉넉하게 올리는 것은 의미가 있습니다. 대체로 권장값의 1.5배 정도까지가 체감되는 구간이고 그 이상은 업로드 시간만 늘어납니다.
메일에 붙일 25MB짜리로 줄이려면 어떻게 하나요?
계산기를 "용량 한도에 맞는 비트레이트 구하기"로 바꾸고 한도에 25를 넣으면 필요한 비트레이트가 나옵니다. 그 값이 권장값보다 한참 낮게 나온다면 비트레이트만 깎지 말고 해상도를 720p나 480p로 함께 내리는 편이 결과가 낫습니다. 5분이 넘는 영상이라면 메일 첨부 자체를 포기하고 링크 공유로 바꾸는 편이 현실적입니다.
오디오 비트레이트는 얼마로 잡는 게 좋나요?
말소리 위주라면 128kbps로도 충분하고, 음악이 섞이면 192~256kbps가 무난합니다. 유튜브는 스테레오 384kbps를 권장하지만 어차피 자체 규격으로 다시 인코딩합니다. 영상 비트레이트가 8Mbps일 때 오디오 192kbps는 전체의 2.4%에 불과해서, 용량을 줄이겠다고 오디오를 깎는 것은 효과가 거의 없고 체감 손해만 큽니다.