2026-08-05

Gmail·Outlook·Yahoo 메일 동영상 첨부 용량 제한 25MB (그리고 변환 전에 결과 크기를 미리 아는 법)

화면 녹화를 트림해서 메일에 첨부했는데 반송되거나, 보내기 버튼이 아예 눌리지 않은 경험이 있을 것이다. 대형 웹메일 서비스 세 곳이 동영상 첨부에 대해 거의 똑같은 선을 긋고 있다: 25MB. 동영상 치고는 유독 작은 숫자다 — 실제로 흔히 쓰이는 비트레이트라면 단 몇 분짜리 영상도 손쉽게 이 상한을 넘겨버리기 때문이다. 각 서비스가 지금 실제로 걸어두고 있는 상한과, 재인코딩을 다 기다리기 전에 고른 품질 프리셋이 실제로 그 안에 들어갈지 미리 아는 방법을 정리했다.

지금 실제로 적용되는 상한

2026년 중반 기준, 3대 웹메일 서비스가 공교롭게도 같은 숫자에서 첨부 용량을 막고 있다:

Gmail: 25MB. Gmail 공식 고객센터는 이렇게 직접 밝히고 있다: "개인 Gmail 계정의 경우 한도는 25MB입니다(For personal Gmail accounts, the limit is 25 MB)." 이를 넘기면 Gmail은 전송 자체를 거부하는 대신 자동으로 그 첨부파일을 Google 드라이브 링크로 바꿔서 보낸다 — 파일은 결국 도착하지만, 받는 사람이 받은편지함에 바로 들어 있는 게 아니라 클릭해서 열어야 하는 링크가 된다.
Outlook.com: 25MB. 마이크로소프트 공식 지원 문서도 똑같이 명확하게 말한다: "파일 첨부 용량 한도는 25MB입니다(The attachment size limit for files is 25 MB)." Outlook.com도 Gmail과 비슷한 대안을 제공한다 — 직접 첨부하는 대신 OneDrive로 파일을 공유하는 방식인데, 이 경로의 상한은 훨씬 넉넉한 2GB다.
Yahoo Mail: 25MB. Yahoo 공식 고객센터는 표현은 조금 다르지만 결국 같은 숫자로 귀결된다: "메시지 하나에 첨부된 모든 파일의 합계는, 수신·발신 상관없이 25MB를 넘을 수 없습니다(The sum of all attached files in a single message ... must not exceed 25MB in total file size)." 이 표현에서 특히 눈여겨볼 점은, 이 상한이 파일 하나당 허용치가 아니라 메시지 하나에 붙은 모든 첨부의 합계라는 것이다.

서로 무관한 세 회사가 정확히 같은 25MB에서 멈춘 건 어떤 공유된 기술 표준이 있어서라기보다는 눈여겨볼 만한 우연에 가깝다 — 하지만 우연이든 아니든, 실제로 세 곳 모두에서 동영상이 첨부되느냐 반송되느냐를 가르는 숫자인 건 똑같다.

목표로 삼아야 할 숫자는 25MB보다 살짝 낮아야 하는 이유

첨부파일은 원본 바이트 그대로 메일을 타고 이동하지 않는다 — 먼저 base64로 인코딩되는데, 이 방식은 원본 3바이트를 인코딩된 텍스트 4바이트로 바꾼다. 어느 서비스에서든 고정적으로 발생하는, 피할 수 없는 약 33%의 팽창이다. 이건 특정 서비스의 특이한 사정이 아니라 인코딩 방식 자체의 기초적인 산술이며, 디스크에서 정확히 25MB로 측정되는 파일도 실제 전송 시점에는 눈에 띄게 더 무거워질 수 있다는 뜻이다. 위 세 서비스 모두 그 팽창분을 자기 파이프라인의 어느 지점에서 발표한 한도와 대조해 측정하는지 정확히 밝히지 않으므로, 여기서 얻을 수 있는 실용적인 결론은 정밀한 목표 숫자가 아니라 — 25MB를 정확히 맞춰야 할 목표가 아니라 실제로 여유가 남도록 그 아래에 두어야 할 천장으로 다뤄야 한다는 것이다.

NearVid 품질 프리셋별로 실제 몇 분짜리 영상이 들어가는가

NearVid의 WebM·MP4 내보내기는 각각 High/Medium/Low 품질 프리셋을 제공하는데, 각 프리셋은 그저 목표 영상 비트레이트일 뿐이다 — WebM은 2M/1M/500k, MP4는 4M/2M/800k — 여기에 오디오 트랙에 대한 고정 추정치 약 128kbit/s가 더해진다. 비트레이트에 길이를 곱하면, 프레임 하나 인코드하기 전에도 25MB 한도 안에 대략 어느 정도 분량의 영상이 들어가는지 계산할 수 있다:

NearVid 자체 비트레이트 프리셋을 같은 25MB 계산식에 넣어 보면: MP4 High는 한도에 도달하기까지 대략 48초, WebM Low는 약 5.3분까지 늘어난다. 더 낮은 품질 프리셋을 고르거나 먼저 트림하는 쪽이, 서비스별 요령 어떤 것보다 훨씬 큰 여유를 벌어준다.

NearVid가 실제로 여기서 하는 일

NearVid의 WebM·MP4 내보내기 화면에서 Quality 드롭다운 옆에는 이제 선택한 프리셋의 예상 결과 용량을 "≈" 기호와 함께 보여주는 작은 숫자가 나온다 — Process를 누르기 전에, 즉 결과를 다 기다린 뒤가 아니라 미리 보여준다. 이 숫자는 실제 길이를 알고 있을 때만 나타난다 — 파일을 불러올 때 NearVid 자체의 ffprobe 기반 길이 측정으로 얻거나, 직접 입력한 시작·끝 트림 구간으로 얻으며, 품질 프리셋을 바꾸거나 그 구간을 조정할 때마다 실시간으로 갱신된다. 이 숫자가 정확히 무엇이고 무엇이 아닌지는 짚어둘 가치가 있다: (영상 비트레이트 + 고정 128kbit/s 오디오 추정치) × 길이를 인코더를 건드리지 않고 기기에서 즉시 계산한 값이다 — 실제로 테스트 삼아 재인코딩해 본 결과가 아니라, 라벨이 붙은 근사치이지 보장된 숫자가 아니다. 실제 오디오 비트레이트는 여전히 진짜 인코더가 결정하고, 목표 영상 비트레이트도 인코더가 맞추려 하는 평균값이지 절대 넘지 않는 바이트 상한이 아니다. 그러니 이 "≈" 숫자는 "이 근처에서 여유 있게 들어올 것"으로 받아들여야지, "정확히 이 크기가 나온다"로 받아들이면 안 된다. 같은 추정치는 트림, GIF, 프레임 추출, 오디오 추출에는 나오지 않는다 — 이들은 비트레이트를 목표로 하는 재인코딩이 아니거나(트림은 무손실 스트림 복사다), 추정할 품질 단계 자체가 없기 때문이다.

범위를 정확히 짚자면: NearVid는 Gmail·Outlook·Yahoo 각각의 구체적인 상한을 알지 못하고, 메일에 무언가를 대신 첨부해 주지도 않는다 — 용량 추정치를 보여줄 뿐이고, 그걸 보내려는 곳의 실제 상한과 비교하는 건 사용자의 몫이다. Low 프리셋으로도 여전히 안 들어간다면, NearVid의 트림(재인코딩이 아니라 무손실 스트림 복사)이 더 큰 지렛대다 — 원본을 실제로 필요한 몇 초만 남기고 잘라내면 비트레이트 × 길이 계산식에서 길이 쪽을 직접 줄이는 셈이고, 변환 전에 이 작업을 하는 데는 추가 비용이 들지 않는다. 그리고 이 모든 과정이 원본 파일을 어디에도 업로드할 필요가 없으므로, 클립이 맞는지 확인하는 행위 자체가 애초에 그 용량 제한이 막으려던 것과 비슷한 서버 측 사본을 만들어내지도 않는다.

정직한 요약

2026년 중반 기준 숫자는 이렇다: Gmail, Outlook.com, Yahoo Mail 모두 메일 첨부를 25MB로 제한한다 — 세 회사가 공유된 표준 때문이 아니라 우연히 같은 숫자에 도달한 것으로 보인다. 그리고 base64 인코딩의 고정된 약 33% 오버헤드 때문에 실제로 안전한 목표는 그 선보다 살짝 낮아야 한다. NearVid 자체 비트레이트 프리셋을 같은 25MB 계산식에 넣어 보면, 대략 48초(MP4 High)에서 5.3분(WebM Low)까지의 영상이 들어간다. 이 분·초 숫자들은 NearVid가 무엇을 하든 바뀌지 않는다 — 보내려는 서비스가 정한 값이기 때문이다. 달라지는 건 결과물이 안 맞는다는 사실을 재인코딩을 다 기다린 뒤에 아느냐, 아니면 그 전에 미리 아느냐다 — Quality 옆의 "≈" 추정치가 그걸 즉시 알려주고, 가장 낮은 프리셋으로도 안 들어간다면 먼저 트림하는 게 여전히 가장 큰 지렛대다.