2026-08-19

링크드인에 영상이 업로드되지 않는 이유 (그리고 아무것도 설치하지 않고 고치는 법)

영상이 링크드인이 공개한 숫자 안에 전부 들어맞을 수 있다 — 용량 제한 이내, 길이 제한 이내, 지원 목록에 있는 파일 형식 — 그런데도 업로드가 0%에서 멈추거나, 썸네일 없이 게시되거나, 처리 자체가 영영 끝나지 않는 경우가 있다. 우연도 아니고 링크드인이 이유 없이 까다롭게 구는 것도 아니다. 보통은 한 가지 구체적인 불일치 때문이다 — 파일의 컨테이너 확장자는 문제가 없는데, 그 안에 들어 있는 코덱을 업로드 파이프라인이 실제로 디코드하지 못하는 것. 링크드인 자체 고객센터가 밝힌 실제 업로드 규격, 아이폰과 맥 촬영본을 유독 많이 걸리게 하는 코덱 함정, 그리고 업로드하기 전에 로컬에서 이걸 고치는 법을 정리했다.

링크드인 자체 업로드 규격 — 공식 고객센터 기준

링크드인 자체 "Share videos on LinkedIn" 고객센터 문서는 네이티브 영상 게시물의 정확한 숫자를 명시한다 — 최대 용량 5GB, 최소 75KB, 최대 길이 15분, 최소 길이는 데스크톱 업로드 기준 3초(모바일 앱은 2초), 해상도 256×144에서 4096×2304 사이, 화면비 1:2.4에서 2.4:1 사이, 프레임레이트 초당 10~60프레임, 비트레이트 192Kbps ~30Mbps. 별도의 "영상 공유 문제 해결" 문서는 지원하는 파일 형식을 이름으로 나열한다 — MP4, MOV, AVI, WEBM, MKV, WMV, 그리고 오래된 방송용 형식 몇 가지(VC1, MPEG, MPEG2, MPEG1VIDEO, DVVIDEO, QTRLE, TSCC2). 내보낸 파일이 이 숫자 전부와 이 확장자 중 하나에 들어맞는다면, 링크드인 자체 공식 규격상으로는 통과해야 맞다.

그런데도 왜 업로드가 그 숫자 안에서 실패하는가

링크드인 자체 문제 해결 문서는 다음에 사람들이 걸리는 함정을 특정 형식 하나에 대해 정확히 문서화해 두었다 — "파일 형식이 ProRes라면 업로드는 될 수 있지만 처리는 되지 않을 수 있습니다." 이 문장을 잘 읽어보면 — ProRes 파일은 확장자가 틀렸다고 입구에서 거부당하는 게 아니다. 일단 받아들여지고, 그대로 멈춰서, 결국 끝나지 않는다. 컨테이너는 멀쩡해 보인다. 문제는 그 안에 들어 있는 코덱이다.

같은 종류의 문제가 링크드인 문서에는 이름이 나오지 않지만 훨씬 더 많은 일상적인 업로드에 영향을 주는 코덱 하나에서도 꾸준히 나타난다 — HEVC(H.265)다. 아이폰과 맥은 2017년 iOS 11부터 기본으로 영상을 이 형식으로 녹화해 왔고, 9to5Mac이 당시 보도한 애플의 원래 발표에 따르면 비슷한 화질에서 파일 크기를 절반가량 줄여준다 — 이 기본값은 애플 자체 지원 문서가 확인해 주듯 지금도 설정 → 카메라 → 포맷에 그대로 남아 있다. 영상 업로드를 준비해 주는 대상 플랫폼으로 링크드인을 명시적으로 꼽는 Buffer의 자체 고객센터는 HEVC를 "가장 흔한 원인"으로 직접 지목한다 — "영상이 0%에서 멈추거나, 업로드 중 멈추거나, 'Thumbnail generation failed' 같은 오류가 뜰 때"의 원인으로다. 그 해결책은 ProRes의 해결책을 일반화한 것과 같다 — "영상을 H.264로 재인코딩하라(MP4, H.264 영상, AAC 오디오)." 확장자는 .mov로 멀쩡하고, 용량도 5GB에 한참 못 미치고, 길이도 15분에 한참 못 미치는 파일이 그럼에도 링크드인이 공개한 숫자 어디에도 나오지 않는 이유로 멈춰 설 수 있다.

NearVid로 로컬에서 고치는 법

영상이 단순히 너무 길어서 — 링크드인의 15분 상한을 넘어서 — 문제라면, NearVid의 트림 카드가 먼저 해결한다 — "재인코딩 없이 클립을 자릅니다 — 빠르고 무손실이며, 원본 포맷도 그대로 유지됩니다." 대부분 파일에서 1초도 채 걸리지 않는 스트림 복사라 코덱에는 손도 대지 않는다. 여기까지는 쉬운 경우다. 코덱 함정 자체에는 "WebM으로 변환"이 더 안전한 기본 선택이다 — NearVid의 ffmpeg.wasm 엔진은 브라우저가 자체적으로 무엇을 디코드할 수 있는지와 무관하게 HEVC를 소프트웨어로 직접 디코드하고, WebM(VP8 + Vorbis)은 링크드인 자체 지원 형식 목록에 이름으로 올라 있는 포맷이라 — 그 결과물은 링크드인의 문제 해결 문서가 이미 받아주는 범위 안에 정확히 들어간다. 브라우저가 H.264 인코딩도 지원한다면 — 현재는 Chrome과 Chromium 계열 브라우저이며, 브라우저 이름을 짐작하는 게 아니라 파일마다 자동으로 실측 확인한다 — NearVid의 "MP4로 변환" 카드도 함께 나타나고, Buffer 가이드가 해결책으로 지목한 H.264 영상 + AAC 오디오 조합을 정확히 만들어 준다. 다만 특정 HEVC 소스에서 이 카드가 뜨는지는 그 브라우저가 애초에 HEVC를 디코드할 수 있는지에도 달려 있어서, 어디서나 확실히 되는 쪽은 WebM이다. 어느 재인코딩이든 링크드인 서버에 닿기 전, 브라우저 탭 안에서, 내 기기 위에서 전부 끝난다.

NearVid가 해결해 주지 않는 것

범위를 솔직하게 밝혀 둘 만하다. 링크드인의 화면비 요구사항 — 1:2.4에서 2.4:1 사이 — 은 크롭·프레이밍 제약이지 코덱이나 길이 문제가 아니고, NearVid에는 크롭이나 재구성 도구가 없다. 특이한 비율로 촬영한 영상이라면 여기서 다루는 것과는 다른 해결책이 먼저 필요하다. 5GB 상한은 보통 촬영본에서는 좀처럼 실제 제약이 되지 않지만, 길고 고비트레이트인 4K 내보내기가 그 근처까지 간다면, NearVid의 WebM·MP4 내보내기 화면에서 Quality 프리셋 옆에 작게 뜨는 "≈" 표시가 재인코딩을 기다리기 전에 예상 결과 용량을 보여준다 — 이 블로그의 다른 글에서 메일 첨부 용량 제한을 다룰 때와 같은 방식이다. 그리고 최소값들 — 75KB, 데스크톱 3초, 모바일 2초 — 은 트림이나 재인코딩 도구가 반대 방향으로 도와줄 수 있는 문제가 아니다 — 이건 "클립이 더 짧아야 한다"가 아니라 "더 길어야 한다"는 상황이다.

정직한 요약

링크드인의 숫자 중 어느 것도 비밀이 아니고, 이 중 어느 것도 NearVid가 지어낸 게 아니다 — 5GB, 15분, 지원 형식 목록 전부 링크드인 자체 고객센터에 공개돼 있고, "업로드는 되지만 처리는 안 되는" 함정도 링크드인이 ProRes에 대해 직접 문서화한 동작이며, HEVC도 Buffer의 별도 문제 해결 가이드에서 같은 실패 양상으로 등장한다. 사람들이 실제로 걸려 넘어지는 지점은, 컨테이너 확장자가 "지원됨"이라고 해서 그 안의 코덱까지 지원된다는 뜻은 아니라는 것이다. NearVid의 트림은 길이 상한을 무손실로 해결하고, WebM 또는 MP4로 변환은 HEVC 파일을 — 혹은 브라우저는 디코드할 수 있지만 링크드인 파이프라인은 처리하지 못하는 어떤 파일이든 — 링크드인 자체 지원 목록 안의 형식으로, 업로드 버튼을 누르기도 전에 내 기기 안에서 완전히 바꿔 놓는다.