2026-09-10

문자로 보낸 영상이 뭉개져 보이는 이유 (그리고 보내기 전에 직접 압축하는 법)

한 번에 찍었고 내 화면에서는 멀쩡했던 영상을 문자로 보냈는데, 상대방에게는 뭉개지고 끊기는, 훨씬 오래된 폰으로 찍은 것 같은 화면이 도착한다. 카메라 탓이 아니다. 내 폰과 상대 폰 사이 어딘가에서 통신사 네트워크가 조용히 그 영상을 대부분의 사진 파일보다도 작은 크기로 재인코딩했기 때문이다 — 평범한 초록 말풍선 문자 밑에 깔린 프로토콜인 MMS는 애초에 지금 해상도의 영상을 나르도록 만들어지지 않았다.

대부분 존재하는 줄도 모르는 상한선

MMS에는 통신사가 정한 확실한 용량 상한이 있다. 앱이 아니라 통신사가 정한다. AT&T의 자체 지원 페이지는 이를 그대로 밝힌다: "The AT&T mobile broadband network delivers picture, video, or audio messages of up to 1MB"이며, "larger media file attachments are compressed before sending to keep the message size below 1MB"라고 명시한다. 버라이즌과 T-모바일도 더 넉넉하지 않다 — Twilio의 통신사 비교 자료에 따르면 버라이즌은 이미지 1.2MB, 영상 3.5MB로 제한하고, T-모바일은 일반 MMS 기준 보낼 때 1MB, 받을 때 3MB까지 허용한다. 생일 케이크나 아기의 첫걸음마를 짧게 찍은 영상 하나도 센서에서 바로 나오면 30~50MB에 쉽게 이른다 — 한 바이트도 보내기 전에 이미 이 숫자들의 30~50배다.

폰을 떠나는 두 가지 다른 길, 그중 하나만 압축한다

애플 자체 설명 문서는 그 경계를 분명히 긋는다: 아이메시지와 RCS는 둘 다 "high resolution photos and videos"를 나른다고 똑같은 표현으로 적혀 있는 반면, 일반 SMS/MMS는 그런 수식어 없이 그냥 "photos and videos"를 나른다고만 적혀 있다. 이건 표현의 우연이 아니다. 아이메시지(파란 말풍선, 애플 기기끼리)와 RCS(초록 말풍선이지만 풍부한 기능, 이제 최신 아이폰과 안드로이드 폰 사이에서도 지원)는 둘 다 미디어를 실제 크기에 가깝게 인터넷 경로로 보낸다. 이 둘에서 벗어나면 — 상대 폰에 RCS가 꺼져 있거나, 더 오래된 기기이거나, 보내는 순간 데이터 연결이 불안정하거나, 특정 그룹 문자이거나, RCS 협상을 아예 하지 않는 메시징 앱을 쓰는 경우 — 메시지는 조용히 일반 MMS로 내려가고, 위의 1~3.5MB 상한이 그대로 적용된다.

대부분의 사람은 이걸 선택한 적이 없다. 폰이 메시지마다 조용히 대신 내리는 결정이고, 보통은 몇 주 뒤 받는 쪽에서 "이 영상 왜 물속에서 찍은 것처럼 보이지" 하고 나서야 알아차린다.

그 숫자를 맞추려고 폰이 실제로 하는 일

How-To Geek의 설명은 파란 말풍선과 초록 말풍선의 화질 차이를 이렇게 정리한다: 통신사는 "strict file size caps, often around 1 MB or less"를 두고 있으며, 영상이 MMS로 떨어지면 "your iPhone automatically compresses the video to fit within those limits, resulting in a blurry, pixelated version of what you recorded"라고 말한다. 폰이 게을러서가 아니다 — 4K로 찍은 40초 분량을 1메가바이트 안에 우겨넣으려면 화질 대부분을 버리는 것 말고는 방법이 없고, 폰은 그 결정을 사용자에게 아무것도 묻지 않고 대신 내린다: 해상도를 고를 수도, 정말 중요한 몇 초를 고를 수도, 사전 경고도 없다. 이미 한 번 압축된 그 영상을 나중에 다시 전달하면, 그 위에 압축이 한 번 더 얹힌다.

직접 먼저 압축하면, 타협은 통신사가 아니라 내가 정한다

통신사의 압축은 눈을 감고 하는 일이다 — 40초짜리 영상 중 어느 3초가 중요한지 모르니 전체를 고르게 짜부라뜨리고 결과를 맡길 뿐이다. NearVid의 트림은 무손실 스트림 복사다 — 재인코딩도 화질 손실도 없다 — 그래서 실제로 도움이 되는 첫 동작은, 어떤 압축이 끼어들기 전에 보낼 가치가 있는 부분만 기기 안에서 먼저 잘라내는 것이다. 10초짜리 클립은 40초짜리보다 훨씬 작은 원본에서 출발하므로, 그다음에 오는 압축이 통신사의 것이든 나의 것이든 메워야 할 간극이 훨씬 작다.

그다음 NearVid의 WebM 변환은 직접 고른 품질 프리셋 — High/Medium/Low, 각각 영상 2Mbps/1Mbps/500kbps에 오디오 약 128kbit/s가 더해진다 — 로 재인코딩하고, 내보내기 화면은 인코딩을 실행하기 전에 고른 구간과 프리셋에 대해 "≈" 용량 추정치를 보여준다. 이는 실제 인코딩 테스트가 아니라 같은 비트레이트로 계산한 근사치다. WebCodecs H.264 인코딩을 쓸 수 있는 크롬 등 크로미움 계열 브라우저에서는, 기능 감지로 나타나는 MP4 변환 카드가 같은 일을 4Mbps/2Mbps/800kbps로 해낸다 — 문자로 보낼 때는 특히 이쪽을 고를 가치가 있는데, WebM은 재생을 지원하는 모든 브라우저에서 열리는 것과 달리 모든 폰의 기본 갤러리 앱에서 열리지는 않기 때문이다. 반면 H.264 MP4는 거의 모든 폰의 기본 갤러리 앱이 별다른 설치 없이 여는 사실상 유일한 포맷이다.

앱 자체 추정치가 쓰는 것과 같은 라벨 붙은 근사 계산 — 프리셋 비트레이트에 오디오 약 128kbit/s를 더하고 길이를 곱하는 식 — 을 그대로 돌려보면, Low WebM 프리셋은 AT&T나 T-모바일의 1MB 발신 상한 안에 대략 13초, T-모바일의 3MB 수신 상한 안에 대략 38초, 버라이즌의 3.5MB 영상 상한 안에 대략 45초가 들어간다. Medium과 High 프리셋은 초당 화질을 눈에 띄게 끌어올리는 대신 같은 예산 안에 들어가는 초수가 줄어든다 — 통신사의 눈먼 자동 압축이 애초에 그런 예산이 존재한다는 사실조차 알려주지 않는 것과 달리, 이건 사용자가 직접 고를 수 있는 타협이다.

이걸로 해결되지 않는 것

NearVid는 상대방이 어느 통신사를 쓰는지, 그 폰에 RCS가 켜져 있는지, 지금 보내는 메시지가 아이메시지·RCS로 나갈지 아니면 일반 MMS로 떨어질지 전혀 알지 못한다 — 브라우저 안에서 돌아가는 페이지가 알 수 있는 범위 밖이고, 여기서 메시지 앱에 접근해 뭔가를 대신 보내는 일도 없다. NearVid가 하는 일은 메시지 앱을 열기 전 단계다: 중요한 몇 초만 자르고, 미리 크기를 가늠할 수 있는 수준으로 재인코딩하고, 업로드용이 아니라 재생을 위해 만들어진 포맷으로 담아내는 것. 그 파일이 RCS를 타고 원본 화질 그대로 나가든, 통신사의 MMS 게이트웨이에서 한 번 더 압축되든, 출발점은 이미 작고 이미 내가 고른 상태다 — 40초짜리 4K 원본을 통째로 넘겨 네트워크가 제멋대로 도려내게 두는 것과는 다르다.

정직한 요약

일반 MMS는 AT&T와 T-모바일 발신 기준 영상을 1MB로, T-모바일 수신 기준 3MB로, 버라이즌 기준 3.5MB로 제한한다 — 각 통신사가 직접 공개한 수치 그대로다. 아이메시지나 RCS에 닿지 못하는 폰은 조용히 이 상한으로 떨어지면서 보낸 영상을 그 안에 맞게 압축해 버리고, 그래서 문자로 보낸 영상이 아무 예고 없이 뭉개지고 깨져 보이는 일이 그토록 흔하다. 브라우저 안에서 할 수 있는 해법은: 보낼 가치가 있는 부분만 무손실로 자르고, NearVid로 직접 고른 품질 프리셋과 미리 가늠할 수 있는 크기로 재인코딩하는 것 — 어디서나 되는 WebM으로든, WebCodecs를 지원하는 환경이라면 MP4로든 — 그러면 살아남는 몇 초는 통신사의 압축기가 남긴 것이 아니라 내가 고른 것이 된다.