동영상 파일은 10억 바이트를 훌쩍 넘는다

요즘 4K 영상을 로컬에 저장하다 보면 파일 하나에 10~20GB가 훌쩍 넘는다. 왜 이렇게 큰 건지 궁금해서, CPU 아키텍처와 메모리 체계를 공부하던 중 직접 계산해봤다.

동영상이 큰 이유: 직접 계산해보면 납득이 된다

동영상은 정지 이미지(프레임)의 연속이다. 1초에 30장의 사진을 이어붙이면 1초짜리 영상이 된다.

압축 없이 Full HD(1920x1080), 24비트 컬러, 30fps를 저장한다고 가정하면:

• 한 프레임의 픽셀 수: 1920 × 1080 = 2,073,600 픽셀
• 픽셀당 데이터: RGB 각 8비트 = 3바이트
• 한 프레임 크기: 2,073,600 × 3 ≈ 약 6MB
• 1초 영상: 6MB × 30 = 약 180MB
• 10초 영상: 180MB × 10 = 1.8GB

10초 분량이 1.8GB다. 1GB가 약 10억 바이트니까, “10억 바이트를 훌쩍 넘는다”는 게 과장이 아니다. 실제 영상 파일이 이것보다 작은 이유는 H.264, HEVC 같은 압축 알고리즘 덕분이다. 원본 데이터는 이 정도 규모다.

메모리 주소와 CPU 아키텍처

동영상 처리를 공부하다 보면 32비트/64비트 시스템 이야기가 나온다.

흔한 오해: “메모리 주소가 8비트 아닌가?” — 아니다. 주소의 크기는 CPU 아키텍처에 따라 결정된다. 32비트 시스템은 주소가 32비트이므로 최대 2³² = 약 4GB 메모리를 사용할 수 있다. 이게 32비트 윈도우가 RAM을 4GB 이상 인식하지 못하는 이유다. 64비트 시스템은 이론상 수십억 GB까지 주소 지정이 가능하다.

CPU 명령어 길이도 고정이 아니다. x86 아키텍처에서는 명령어 길이가 가변적이라, 단순 명령은 1바이트, 복잡한 명령은 여러 바이트를 쓴다.

GHz는 초당 사이클 수다

CPU 스펙에서 3 GHz라고 하면 1초에 30억 사이클이 발생한다는 뜻이다. 이상적인 상황에서는 한 사이클에 명령어 하나를 처리한다.

단위	사이클 수
1초	1,000,000,000 사이클
1밀리초	1,000,000 사이클
1마이크로초	1,000 사이클

현실에서는 파이프라인, 캐시 미스, 분기 예측 등 변수가 많아서 단순 계산과 다르다. 하지만 3 GHz라면 1초에 수십억 개 명령어를 처리한다는 감각은 맞다.

MMU: 논리 주소와 물리 주소 사이

프로그램이 사용하는 주소(논리 주소)와 실제 RAM의 위치(물리 주소)는 다르다. MMU(메모리 관리 유닛)가 이 변환을 담당한다. 프로그램 입장에서는 0번부터 연속적인 메모리 공간이 있는 것처럼 느끼지만, 실제로는 물리 메모리 여기저기에 흩어져 있을 수 있다.

이 덕분에 여러 프로그램이 동시에 메모리를 쓸 수 있고, 서로 침범하지 않는다.

동영상 데이터 처리의 요약

CPU가 영상 한 프레임을 처리할 때는 수백만 픽셀 데이터를 읽고, 디코딩하고, 디스플레이에 출력하는 과정을 초당 수십 번 반복한다. 이 모든 데이터가 레지스터 → 캐시 → RAM 순서로 이동하면서 처리된다. 동영상 재생이 무거운 이유가 여기 있다.

출처

ChatGPT