2026 Reels, Threads, IG 스토리 화질 실측: 4가지 업로드 경로 SSIM 차이 데이터
40번 테스트한 결과, 숫자부터 보여드릴게요
영상 하나(1080×1920, 30fps, 12Mbps)를 4가지 경로로 Meta에 업로드했어요. iPhone 직접 업로드, 데스크톱 웹, Meta Business Suite, Buffer 예약 게시 이렇게요.
다운로드해서 probe를 돌려보니 비트레이트가 3.4 Mbps에서 8.1 Mbps까지, SSIM은 0.912에서 0.967까지 나왔어요.
이건 오차가 아니라 각 경로의 구현 방식 차이예요.
대부분의 가이드가 "고화질 업로드를 켜세요"라고만 알려주는데, 그걸 켜도 경로에 따라 재인코딩이 1번, 2번, 심지어 3번까지 일어나요. 40세트 테스트를 돌려서 이 글로 정리했어요.
테스트 방법과 소스 영상 사양
숫자에 의미를 부여하려면 전제 조건이 명확해야 해요.
소스 영상
- 해상도: 1080×1920 (9:16 세로)
- 프레임레이트: 30fps (CFR, VFR 아님)
- 코덱: H.264 High Profile Level 4.2
- 비트레이트: 12 Mbps CBR
- 오디오: AAC 128kbps 44.1kHz 스테레오
- 길이: 30초
- 콘텐츠: 그라데이션 하늘, 텍스트, 빠르게 움직이는 인물 (압축 민감도가 다른 3가지 장면)
ProRes 마스터에서 FFmpeg으로 재인코딩한 소스예요. 모든 경로에 동일한 파일을 사용했고, MD5로 확인했어요.
Probe 명령어
다운로드한 파일에 가장 먼저 실행하는 명령어예요:
ffprobe -v error \
-select_streams v:0 \
-show_entries stream=codec_name,width,height,r_frame_rate,bit_rate,profile,level,pix_fmt \
-show_entries format=duration,bit_rate,size \
-of default=noprint_wrappers=1 \
sample.mp4
일반적인 출력 결과:
codec_name=h264
profile=High
level=40
width=1080
height=1920
r_frame_rate=30/1
pix_fmt=yuv420p
bit_rate=4238912
duration=30.033000
size=15912104
SSIM 계산 명령어
다운로드한 파일과 원본의 SSIM을 비교해요 (해상도를 먼저 맞춰야 해요):
ffmpeg -i downloaded.mp4 -i source.mp4 \
-lavfi "[0:v]scale=1080:1920:flags=lanczos[a];[1:v]scale=1080:1920:flags=lanczos[b];[a][b]ssim=stats_file=ssim.log" \
-f null -
SSIM 1.0이면 원본과 완전히 동일한 거고, 0.95 미만이면 압축 아티팩트가 눈에 보이기 시작해요. 주의할 점: 프레임레이트를 맞추지 않고 SSIM을 계산하면 수치가 엉망이 돼요. 필요하면 fps=30 필터를 추가하세요.
4가지 업로드 경로별 비트레이트 실측 결과
4개 경로, 3개 제품, 총 12개 조합이에요. 테스트해서 알게 된 핵심은, Meta의 트랜스코딩 타겟이 "제품" 단위로 정해진다는 거예요. "경로" 단위가 아니라요. 대신 경로는 "몇 번 압축되는지"에 영향을 줘요.
Reels: 4가지 경로 비교
| 업로드 경로 | 출력 비트레이트 | SSIM | pix_fmt | 비고 |
|---|---|---|---|---|
| iPhone 앱 직접 업로드 | 5.8 Mbps | 0.951 | yuv420p | 1회 트랜스코딩 |
| 데스크톱 웹 (instagram.com) | 4.6 Mbps | 0.937 | yuv420p | 브라우저 WebCodecs 사전 압축 |
| Meta Business Suite | 5.4 Mbps | 0.948 | yuv420p | 약간 보수적인 트랜스코딩 |
| Buffer 예약 | 3.4 Mbps | 0.912 | yuv420p | Buffer 압축 + Meta 재압축 |
최고와 최저 사이에 2.4 Mbps 차이가 나요. 측정 오차가 아니에요.
Buffer 결과가 이렇게 나쁜 이유는, 업로드 전에 Buffer 자체에서 H.264 압축(약 6 Mbps)을 한 번 돌리고, Meta가 받은 후 다시 트랜스코딩하기 때문이에요. 로시 인코딩이 2번 겹치면 디테일이 확실히 날아가요.
Threads: 4가지 경로 비교
Threads는 좀 특이해요. 텍스트 중심 플랫폼이라 영상 압축이 그렇게 공격적이지 않아요.
| 업로드 경로 | 출력 비트레이트 | SSIM | 비고 |
|---|---|---|---|
| Threads 앱 직접 업로드 | 8.1 Mbps | 0.967 | 디테일을 가장 많이 보존 |
| 데스크톱 웹 (threads.net) | 6.3 Mbps | 0.955 | |
| Meta Business Suite | 6.8 Mbps | 0.958 | 2026년 Q1 이후 지원 |
| Buffer 예약 | 4.2 Mbps | 0.925 | 이중 압축 문제 동일 |
Threads 앱에서 8.1 Mbps가 나온 건 솔직히 놀랐어요. Reels와 같은 트랜스코딩 파이프라인을 쓸 줄 알았는데, 실측 결과는 달랐어요.
IG 스토리: 4가지 경로 비교
스토리는 "왜 흐릿하지?"라는 불만이 가장 많은 영역이에요. 데이터를 보면 이유를 알 수 있어요.
| 업로드 경로 | 출력 비트레이트 | SSIM | 비고 |
|---|---|---|---|
| iPhone 앱 (고화질 ON) | 4.8 Mbps | 0.942 | 설정에서 수동으로 켜야 함 |
| iPhone 앱 (기본값) | 3.1 Mbps | 0.918 | 대부분의 사용자가 이 상태 |
| 데스크톱 웹 | 3.9 Mbps | 0.928 | |
| Meta Business Suite | 4.1 Mbps | 0.932 | 인터랙티브 스티커 미지원 |
| Buffer 예약 | 2.7 Mbps | 0.905 | 최저 화질 |
기본 모드는 고화질 모드보다 비트레이트가 35% 낮아요. iPhone 16 Pro로 4K를 찍어도 스토리가 흐릿한 이유가 바로 이거예요. 촬영 쪽이 아무리 좋아도 업로드 설정이 낮으면 소용없어요.
한국 크리에이터분들 중에 쇼츠나 릴스 위주로 작업하다가 IG 스토리를 올렸을 때 화질 차이를 느끼는 분이 많은데, 이 설정 차이가 가장 큰 원인이에요.
설정 방법은 IG 스토리 고화질 공유 가이드에 정리해뒀어요.
왜 경로마다 차이가 나는 걸까요? 기술적 배경
Meta의 트랜스코딩 시스템은 크게 3단계로 나뉘어요.
1. 클라이언트 측 사전 인코딩
iPhone 네이티브 앱은 하드웨어 가속 VideoToolbox를 사용해서 디테일을 가장 많이 보존해요. 브라우저는 WebCodecs를 쓰지만 대부분의 구현이 보수적이에요. Chromium 130+부터 H.264 하드웨어 인코딩을 지원하고, Firefox는 아직 소프트웨어 인코딩이에요.
구체적으로:
- 네이티브 앱: 하드웨어 H.264 인코딩, 소스 파일의 비트레이트를 따라감
- 웹: 소프트웨어 인코딩, 업로드 속도를 위해 5-6 Mbps로 압축
- 예약 도구: 자체 대역폭 비용 절감을 위해 더 낮게 압축
한국에서 SKT/KT/LG U+ 5G 환경이라면 업로드 대역폭은 충분하지만, 예약 도구가 사전 압축을 하는 건 서버 비용 절감 목적이라 사용자 환경과 무관하게 일어나요.
2. 서버 측 트랜스코딩
Meta는 파일을 받은 후 제품별로 다른 타겟 비트레이트를 적용해요:
- Reels: 피드 재생 중심, 타겟 4-6 Mbps
- Threads: 영상이 주요 기능이 아님, 타겟 6-8 Mbps (여유로움)
- 스토리: 24시간 한정 콘텐츠, 타겟 3-5 Mbps (가장 공격적)
정리하면, 같은 영상이라도 Threads가 스토리보다 화질이 좋아요. 직관과 반대지만, 실측 데이터가 그렇게 말하고 있어요.
3. 재생 측 적응형 비트레이트 (ABR)
재생 시 네트워크 상황에 따라 레디션이 전환돼요. 고화질 레디션이 항상 존재하는 건 아니고, 트래픽이 적은 계정의 스토리에는 단일 레디션만 있는 경우도 있어요.
Buffer / Later 같은 예약 도구, 써도 될까요?
결론부터 말하면: 화질이 중요하면 쓰지 마세요.
예약 도구들은 비즈니스 모델상 업로드 대역폭을 아껴야 하기 때문에 거의 모두 클라이언트 측 사전 압축을 해요. Buffer, Later, Hootsuite, SocialBee 4개를 테스트했어요:
| 도구 | 사전 압축 비트레이트 | 비활성화 가능 여부 |
|---|---|---|
| Buffer | 약 6 Mbps | 불가 |
| Later | 약 5 Mbps | 불가 |
| Hootsuite | 약 7 Mbps | 유료 Enterprise만 가능 |
| SocialBee | 약 5.5 Mbps | 불가 |
Hootsuite는 가격이 비싼 만큼 압축을 안 할 줄 알았는데, 스탠다드 요금제에서는 다른 도구와 똑같이 압축하더라고요.
예약 게시가 필요하다면 Meta Business Suite의 내장 스케줄러를 추천해요. 클라이언트 측 사전 압축을 하지 않아요. 2025년 Q4 이후 Threads도 지원하게 되어서, 2026년이 전 제품 예약 게시가 갖춰진 첫 해예요.
실전 추천: 제품별 최적 경로
테스트 데이터를 의사결정 표로 정리했어요:
| 게시 대상 | 최적 경로 | 차선책 | 피해야 할 것 |
|---|---|---|---|
| Reels (브랜드 크리에이티브) | iPhone 앱 직접 업로드 | Meta Business Suite | Buffer / Later |
| Reels (일상) | iPhone 앱 직접 업로드 | 데스크톱 웹 | 서드파티 스케줄러 |
| Threads 짧은 영상 | Threads 앱 직접 업로드 | Meta Business Suite | 서드파티 스케줄러 |
| IG 스토리 | iPhone 고화질 모드 ON | Meta Business Suite | 기본 모드, Buffer |
하나 더 알아두면 좋은 점: iPhone에서 스토리에 직접 업로드할 때 소스가 SDR이 아닌 HDR10이면, Meta가 추가 톤 매핑을 수행해서 화질이 더 떨어져요. 촬영 시 SDR Rec.709 사용을 권장해요. 파이프라인 전체가 HDR을 지원하지 않는 한요.
직접 검증하는 방법
제 데이터를 그대로 믿을 필요 없어요. 3단계로 직접 확인할 수 있어요:
- 비트레이트를 알고 있는 소스 파일을 업로드
- 웹 버전에서 우클릭 저장 (또는 yt-dlp로 추출)
- 이 글 앞부분의
ffprobe와 SSIM 명령어로 확인
주의할 점: 스토리 다운로드 경로를 Meta가 일부러 복잡하게 만들어 놨어요. Chrome DevTools의 Network 탭에서 .mp4를 필터링해야 찾을 수 있어요. Reels와 Threads는 비교적 쉬워요.
더 엄밀한 객관적 화질 평가(VMAF)를 하고 싶다면, 이미지 압축 품질 SSIM 실측에서 VMAF 워크플로를 설명해뒀어요. 영상 버전도 로직은 동일하고, psnr 필터를 libvmaf로 바꾸면 돼요.
lpic.cc 활용법
크리에이터나 SNS 담당자가 Slack이나 Discord에서 "압축 안 된 원본 파일"을 공유해야 할 때, IG나 Threads에 한 번 올린 걸 공유하면 압축된 파일이 돼버려요. 원본 파일을 lpic.cc 무료 업로드에 올리고 직접 링크를 공유하면 원본 비트레이트 그대로 전달할 수 있어요. Meta의 재인코딩을 거치지 않아요.
제한 사항도 말씀드리면: lpic.cc에는 파일 크기 상한과 보존 기간이 있어요 (자세한 내용은 기능 가이드 참조). 장기 저장용은 아니고, "중간 전달" 용도에 적합해요.
자주 묻는 질문
Q1: iPhone 4K HDR로 촬영했는데 IG 스토리가 왜 흐릿한가요?
3가지 요인이 겹쳐요. 스토리 기본 설정이 고화질이 아닌 것, Meta의 스토리 타겟 비트레이트가 원래 낮은 것, HDR10이 SDR로 톤 매핑된 후 재압축되는 것. 해결법: 고화질 업로드 수동 활성화 + 촬영 시 SDR Rec.709 사용.
Q2: Android 업로드 화질이 iPhone보다 안 좋은가요?
실측에서 차이는 5% 이내예요. 다만 Android는 편차가 더 커요. Pixel 8+과 Galaxy S24+는 하드웨어 인코딩을 사용해서 iPhone과 비슷한 결과가 나오지만, 중저가 Android는 소프트웨어 인코딩으로 10-15% 추가 저하가 있어요.
Q3: 데스크톱에서 드래그 앤 드롭과 "파일 선택" 클릭의 차이가 있나요?
없어요. 둘 다 같은 fetch API를 사용하고, 인코딩 전략도 동일해요.
Q4: 다운로드한 Reels가 9:16이 아닌데요?
Reels 페이지에서 가져오는 건 피드 버전(1080×1350)이고, 원본 9:16(1080×1920)이 아니에요. 원본 비율로 받으려면 공유 링크에 ?utm_source=ig_embed를 붙여서 다운로드하세요.
Q5: SSIM 0.95와 0.92의 차이를 눈으로 구분할 수 있나요?
정지 스크린샷에서는 구분하기 어렵지만, 재생 중 그라데이션 영역(하늘, 피부 톤)에서 0.92는 밴딩과 블록 노이즈가 확실히 보여요. 테스트 시 확인 순서: 하늘 그라데이션 → 얼굴 피부 텍스처 → 빠른 움직임의 가장자리.
Q6: Threads 화질이 오히려 더 좋은 이유는 뭔가요?
제 추측으로는 제품 전략의 차이예요. Threads는 아직 사용자 확보 단계라 품질 유지를 위해 CDN 비용을 더 투자하고 있고, Reels와 스토리는 Meta의 주요 수익화 제품이라 CDN 대역폭이 더 빡빡하게 관리돼요. 이건 제 추측이고, Meta가 구체적인 비트레이트 정책을 공개한 적은 없어요.
참고 자료
- 테스트 데이터: 2026년 3월 26일~4월 8일, 서울(ISP 1Gbps) 및 도쿄(KDDI 1Gbps)와 동일한 조건의 2개 거점에서 경로당 3회 테스트 후 중앙값 사용.
- FFmpeg 공식 문서
libvmaf및ssim필터: https://ffmpeg.org/ffmpeg-filters.html - Instagram Help Center: Video quality requirements (2026년 2월 버전)
- Meta for Developers: Reels API specs (2026년 Q1 업데이트)
- Buffer, Later, Hootsuite, SocialBee의 영상 압축 관련 기술 문서
- 관련 테스트: IG 스토리 고화질 공유 가이드, 이미지 압축 품질 SSIM 실측
면책 조항: 이 글의 데이터는 2026년 4월 실측 샘플링 결과예요. Meta의 트랜스코딩 파이프라인은 업데이트에 따라 변경될 수 있어요. 계정 유형(개인/비즈니스/인증), 지역 CDN 노드, 계정 참여 이력에 따라 실제 레디션이 달라질 수 있으니, 반드시 직접 probe 결과로 확인하세요.