2026-09-04

2026년 위키백과는 당신의 MP4를 받지 않는다: 위키미디어 공용은 WebM 전용, 그리고 어디에도 업로드하지 않고 변환하는 법

위키백과는 자기 미디어를 직접 보관하지 않는다. 문서 맨 위의 사진도, 중간의 도해도, 기계가 실제로 돌아가는 짧은 영상도 대부분 위키미디어 공용(Wikimedia Commons)에 올라가 있고 문서는 그것을 불러올 뿐이다. 그래서 영상을 기여하기로 마음먹는 순간 — 문화재 한 채, 돌아가는 기계 한 대, 새 한 마리, 화학 실험 한 장면, 아직 영상이 하나도 없는 문서의 그 역에 들어오는 전차 — 처음 시도하는 거의 모든 사람이 같은 규정에 걸린다. 공용은 방금 폰이 만든 MP4를 받지 않는다. "별로 선호하지 않는다"가 아니다. 그 파일 형식은 허용 목록에 아예 없고, 이유는 화질이 아니라 라이선스다. 공용 자체 페이지에서 확인한 실제 규정, 100MB에서 업로드가 죽고 나서야 알게 되는 두 번째 관문, 그리고 그 변환을 내 컴퓨터 안에서 끝내는 법 — 이 도구가 오히려 틀린 선택인 경우까지 함께 — 을 정리했다.

규정: 공용 자체 페이지 기준

Commons:File types는 단도직입적이다: "동영상은 WebM 파일(.webm 확장자), Theora 영상 코딩 형식을 쓰는 Ogg 파일(.ogv 확장자), 또는 MPEG-1/MPEG-2 파일(.mpg 및 .mpeg 확장자)이어야 한다." Commons:Video는 거기서 한 번 더 좁힌다 — "선호되는 영상 형식은 WebM(.webm)이며, AV1·VP9·VP8 코덱으로 인코딩된 영상 데이터와 Opus 또는 Vorbis로 인코딩된 오디오를 담을 수 있다" — 그리고 사운드트랙 때문에 업로드가 막히기 전까지는 다들 잊고 있는 조건을 덧붙인다: "영상 파일 안의 오디오 데이터 역시 Vorbis나 Opus 같은 자유 형식이어야 한다." 같은 페이지가 내 카메라 파일이 탈락하는 이유도 그대로 적어 둔다: "공용은 MP4와 MOV 파일에 쓰이는 H.264(AVC)·H.265(HEVC) 같은, 더 흔히 쓰이지만 특허에 묶인 영상 형식을 지원하지 않는다. 그 사용에 로열티 지불이 요구될 수 있기 때문이다." 이건 내 영상의 품질에 대한 평가가 아니라 라이선스 입장이고, 영상이 좋다고 예외가 되는 종류의 규정이 아니다.

허용된 세 형식 중 하나는 사실상 죽어 있는데, 목표 형식을 고를 때 이게 중요하다. Commons:Video가 직접 그렇게 쓴다: Ogg Theora와 MPEG-1/2도 "공용에서 허용되지만, 현대 브라우저에서 그만큼 널리 지원되지는 않는다" — 그리고 이유까지 짚는다. "크롬과 파이어폭스가 최근 낮은 채택률과 보안 우려를 이유로 Theora 영상 디코딩 지원을 제거했다." 크로미움 자체의 "Intent to Ship: Deprecate and remove Theora support" 스레드가 시점을 못 박는다: 2024년 2월경 M123에서 코드 제거, 그리고 "크롬 123이 안정 채널로 나간다"는 게 그다음 달이다. 즉 오늘 올린 .ogv는 대부분의 독자 브라우저가 재생하지 못하는 파일이다. 실무적으로 허용 목록에서 살아 있는 항목은 하나뿐이고, 그건 WebM이다.

공용의 허용 목록은 짧고, 거기에 MP4는 없다 — 화질이 아니라 라이선스 때문이다. 허용된 세 컨테이너 중 현재 브라우저에서 여전히 재생되는 건 WebM뿐이다.

두 번째 관문: 업로드당 100MB

형식은 사람들이 가장 먼저 부딪히는 관문이고, 크기는 15분짜리 클립의 9분째에 부딪히는 관문이다. Commons:Maximum file size는 이렇게 적는다: 일반 양식을 통한 "업로드의 최대 파일 크기는 100MB". 반면 실제로 보관되는 파일의 천장은 훨씬 높다 — Commons:Video는 "파일은 5GiB보다 클 수 없다"고 쓴다. 두 숫자 사이를 잇는 게 청크 업로드다: "업로드 마법사와 여러 커뮤니티 도구는 청크 업로드를 써서 그런 파일을 100MB 미만 조각으로 나눠 올리고 서버에서 다시 합칠 수 있다." 즉 큰 파일이 불가능한 게 아니라, 일반 양식으로는 못 지나갈 뿐이다.

이게 지금 돌리려는 변환에 어떤 뜻인지는 정책이 아니라 산수다 — 공용의 숫자가 아니라 내 계산이다. 100MB는 800메가비트이므로, 영상 2Mbit/s에 오디오 약 128kbit/s를 얹으면 일반 양식이 거절하기까지 대략 6분, 1Mbit/s라면 대략 12분이 나온다. 백과사전에 쓰이는 영상은 원래 짧은 편이라 — 공정 하나, 작동 원리 하나, 울음소리 하나, 진입하는 모습 하나 — 대부분의 기여는 두 숫자 근처에도 가지 않는다. 그 선을 넘는다면 정직한 선택지는 셋이다: 더 짧게 자르거나, 더 낮게 인코딩하거나, 업로드 마법사를 쓰거나.

내 컴퓨터 안에서, 한 번에 끝내는 변환

니어비드의 WebM 변환은 WebAssembly로 컴파일된 진짜 FFmpeg 빌드를 페이지 안에서 돌린다. 파일은 내 브라우저가 읽고, 어디로도 전송되지 않는다. 출력은 VP8 영상 + Vorbis 오디오이고, 둘 다 위 허용 목록에 있는 조합이다. 이건 평소의 WebM 문제를 정확히 뒤집은 상황이기도 하다: 보통 WebM은 벗어나야 하는 형식이고, 공용은 그것 말고는 아무것도 받지 않는 드문 목적지다 — 같은 변환을 반대 방향으로 쓰는 셈이다.

실무적으로 두 가지. 첫째, WebM 카드는 트림 카드와 같은 시작·끝 입력을 받는다. 그래서 자르기와 변환이 한 번에 끝난다 — 남길 초만 재인코딩하니 전체를 변환한 뒤 자르는 것보다 빠르고 결과도 작다. 둘째, 어차피 인코더가 도는 경로라 이 컷은 입력한 지점에 정확히 떨어진다 — 키프레임에서만 시작할 수 있는 트림 카드의 무손실 스트림 복사와 다른 점이다. 품질 선택은 고정 비트레이트 셋(High 2Mbit/s, Medium 1Mbit/s, Low 500kbit/s)이고, 그 옆의 "≈" 숫자는 비트레이트 × 길이로 계산한 표시된 추정치이지 측정값이 아니다. 고를 때 참고하고, 100MB 관문과 견줄 때는 완성된 파일의 실제 크기를 확인하자.

이 도구가 틀린 선택인 경우 — 공용 안내서가 직접 말한다

긴 영상을 변환하기 전에 이 절을 먼저 읽는 게 좋다. 공용의 Help:Converting video는 VP9 영상 + Opus 오디오를, 그것도 2패스 고정 품질로 인코딩할 것을 권한다. "-crf의 목표 품질은 0에서 63까지의 척도로 지정하며, 값이 작을수록 품질이 높다"고 적고 HD 기본값을 30으로 든다. 니어비드는 그렇게 하지 않는다. 고정 비트레이트로, 1패스로, VP8과 Vorbis를 쓴다. 이건 실수가 아니라 의도된 선택이다: 엔지니어링 스파이크에서 VP9 경로가 이 빌드 자체의 로그 콜백에서 재현되는 크래시를 냈고, 그래서 도구는 끝까지 검증된 코덱 조합을 싣고 있다. VP8과 Vorbis는 공용 허용 목록에 명시돼 있으니 업로드는 받아들여진다 — 다만 VP9와 AV1은 같은 메가바이트로 눈에 띄게 더 좋은 화질을 낸다. 소재가 길거나, 디테일이 많거나, 100MB 관문에 아슬아슬하다면 그 차이가 전부다. 그런 업로드라면 공용 자체 안내서를 따르는 게 맞다: 데스크톱 FFmpeg, 또는 그 페이지가 이름을 든 video2commons. 로컬 변환은 프라이버시 속성이지 화질 주장이 아니다.

나머지 한계 목록은 짧다. 니어비드는 파일 전체를 메모리에서 처리하므로 데스크톱에서 파일당 500MB, 폰과 저사양 기기에서는 50MB까지만 받는다 — 그리고 몇 분짜리 4K 캡처는 바로 그 폰에서 이 숫자를 넘기기 일쑤라, 그럴 땐 파일을 컴퓨터로 옮겨야 한다. 리사이즈는 하지 않는다: 4K 소스는 4K WebM이 되고, 그게 보통 공용이 원하는 바이면서 동시에 파일이 무거워지는 이유다. 손떨림 보정도, 여러 테이크 병합도, 자막 트랙도, "100MB 아래로 맞추기" 버튼도 없다 — 있는 건 표시된 추정치와, 끝난 뒤의 실제 크기뿐이다. 그리고 어떤 도구도 되돌릴 수 없는 것 하나: 카메라의 MP4는 이미 손실 인코딩이라 WebM은 2세대다. H.264에서 자유 형식으로 가는 무손실 경로는 존재하지 않으므로, 규칙은 단순하다 — 메신저를 한 번 거친 사본이 아니라 원본 카메라 파일에서 딱 한 번 변환할 것.

파일 형식이 해결해 주지 않는 부분

형식 검사를 통과하는 건 쉬운 절반이다. 공용은 자유 콘텐츠 프로젝트라 Commons:Licensing은 파일 자체가 자유 라이선스로 배포될 것을 요구한다 — 보통은 내가 찍었고 내가 그렇게 공개하기 때문에 성립한다. 어디선가 주워 온 영상이나, 남의 음악이 깔린 클립은 어떻게 인코딩하든 자격이 없다. 사람이 찍히면 층이 하나 더 붙는다: 식별 가능한 인물 사진에 관한 공용 지침은 "사적 공간에서 식별 가능한 인물의 사진을 공개하려면 보통 동의가 필요하며, 관련 법이 요구하지 않더라도 공용은 이를 기대한다"고 적고, 반대로 "많은 나라(특히 영어권)에서는 공공장소에서 식별 가능한 인물을 평범하게 찍은 사진을 공개하는 데 보통 동의가 필요하지 않다"고 적는다 — 나라마다 다르다는 점도 그 페이지가 분명히 밝힌다. 둘 다 로컬 변환을 택할 이유가 된다. 찍고, 변환하고, 결과를 보고, 그래서 올리지 않기로 하는 흐름은 아주 흔한데, 변환 단계에 남의 서버가 끼지 않았을 때에만 그 결정이 온전히 내 안에 남는다.

같은 영상에서 뽑는 스틸

사진은 평범한 형식 그대로 환영받는다 — Commons:File types는 JPEG를 "사진에 적합하며, 특히 사진이 이미 JPEG인 경우 그렇다"고, PNG를 그림·도해용으로 든다 — 그리고 내가 찍은 영상에서 뽑은 프레임은 영상과 똑같이 내 저작물이다. 니어비드의 프레임 추출은 입력한 타임스탬프의 프레임을 영상 재인코딩 없이 캡처 원본 해상도의 JPG 또는 PNG로 뽑아 준다. 어떤 프레임이 올릴 만한지는 정지 프레임 고르기 글에서 다뤘다. 한 가지는 정확히 해 두자: 위키 러브스 모뉴먼츠는 2026년 대회를 9~10월 안의 30일 또는 31일 구간에서 진행하고 최종 마감은 10월 31일인데, 스스로를 "연례 사진 공모전"이라고 설명한다. 영상 스틸이 출품작으로 인정되는지는 주최 측이 판단할 문제이지 이 글이 답할 문제가 아니다. 공모전 바깥의 평범한 공용 업로드라면 애초에 생기지 않는 질문이다.

정직한 요약

공용 자체 페이지 기준: 영상은 .webm, .ogv, .mpg/.mpeg여야 하고, MP4와 MOV는 H.264·H.265의 사용에 "로열티 지불이 요구될 수 있"어서 빠져 있다. 오디오도 자유 형식(Vorbis 또는 Opus)이어야 하고, 일반 업로드 양식은 100MB에서 멈추며 5GiB는 업로드 마법사의 청크 업로드로 닿는다. 그리고 허용된 세 형식 중 현재 브라우저에서 여전히 재생되는 건 WebM뿐이다 — 크롬은 123에서 Theora 디코딩을 제거했다. 니어비드는 브라우저 안에서만 WebM(VP8 + Vorbis)으로 변환하고, 자르기와 인코딩을 한 번에 끝내며, 어느 단계에서도 업로드하지 않는다 — 아직 공개를 확정하지 않은 영상에 맞는 모양이다. 클립이 길거나 100MB 관문이 빠듯하다면, 공용 자체 변환 안내서와 그 VP9 + Opus 레시피가 이 도구보다 백과사전에 더 도움이 된다. 그걸 말해 두는 것까지가 이 글의 일이다.