씨미가 4K · 4초 저지연 라이브를 만든 방법 — Amazon IVS와 자체 구축의 하이브리드 설계

본 글은 씨미(ci-me) 라이브 스트리밍 플랫폼이 4K 저지연 라이브 시청 경험을 제공하기 위해 Amazon IVS의 매니지드 환경과 자체 구축 영역을 어떻게 결합했는지에 대한 사례입니다. 또한 1만 명 동시 시청자를 가정한 부하 테스트 과정에서 마주친 기술적 의사결정과 시행착오가 함께 공유됩니다.

1. 배경

씨미(CIME)는 버추얼 스트리머와 게임 스트리머를 위한 라이브 스티리밍 플랫폼입니다. 4K 초고화질, 초저지연 방송 환경, 실시간 후원, 커뮤니티, 다시보기, 클립, 굿즈 연동을 통해 스트리머와 팬이 방송 안팎에서 연결될 수 있도록 돕습니다. 또한 낮은 수수료와 타 플랫폼 동시송출을 지원하여 스트리머가 더 자유롭게 방송과 수익화를 운영할 수 있는 환경을 제공합니다.

씨미가 차별화 포인트로 두는 것은 2160p / 60fps / 최대 35Mbps / 4초 이내 저지연 라이브 시청 경험입니다. 이 사양을 안정적으로 제공하기 위해서는 라이브 스트리밍 인프라가 다층적으로 설계되어야 합니다.

2. 당면 과제

4K는 본질적으로 무거운 영상입니다. 해상도가 높아질수록 비트레이트가 커지고(씨미의 송출 기준 최대 35Mbps), 비트레이트가 커지면 네트워크 대역폭 부담이 늘어나며, 그만큼 시청자에게 도달하는 지연도 자연히 길어집니다. 지연이 길어지면 시청자가 스트리머와 실시간으로 소통할 수 없게 되어 라이브의 본질이 훼손됩니다.

씨미가 풀어야 했던 문제는 다음과 같이 정리됩니다.

4K 화질의 몰입감과 실시간 라이브의 즉시성을 동시에 제공 — 고비트레이트 영상의 저지연 시청 경험을 어떻게 보장할 것인가
소수의 인원으로 듀얼 트랙(1080p · 4K) 동시 운영 — 라이브 스트리밍 인프라 전체를 자체 구축하는 것은 인력·운영 측면에서 비효율적
1만 명 동시 시청자 시나리오 대비 — 운영 단계에서 트래픽 피크가 발생하더라도 시청 경험이 안정적으로 유지되어야 함

씨미는 이 과제들을 전략적인 하이브리드 설계로 풀었습니다 — 차별화 영역은 직접 설계하고, 일반 표준 영역은 매니지드에 위임함으로써 각 영역이 가장 잘 책임질 수 있는 주체가 책임지는 구조를 만들었습니다.

3. 씨미의 분기 설계 — 매니지드와 자체 구축의 경계

서비스를 처음 출시할 때, 트래픽 규모와 유저 진입 패턴은 모두 불확실했습니다. 소수의 인원으로 빠르게 시장에 진입하는 것이 우선이었고, 라이브 인프라의 일반 영역까지 처음부터 모두 자체 구축하는 것은 차별화 자원의 분산을 의미했습니다.

이러한 비즈니스 요구사항 하에 매니지드 측 라이브 스트리밍 서비스로 Amazon Interactive Video Service (Amazon IVS)를 선택하고, 이를 1080p 트랙의 중심축으로 두는 *분기 설계*를 채택했습니다.

Amazon IVS는 라이브 스트리밍 인프라를 매니지드로 제공하는 AWS 서비스입니다. 저지연 스트리밍으로 실시간에 가까운 인터랙션을 지원하고, Amazon S3에 라이브 스트림을 자동 녹화해 VOD로 즉시 활용할 수 있으며, iOS·Android·Web Broadcast/Player SDK를 지원합니다.

이 결정의 근거는 네 가지로 정리됩니다.

첫째, RTMP 수신·트랜스코딩·HLS 배포·자동 녹화·다중 비트레이트 전송을 Amazon IVS의 매니지드 환경에 위임하기로 결정했습니다. 이 영역에서 직접 운영 노하우로 차별화할 여지는 크지 않으며, 24/7 인프라 모니터링·확장·장애 대응을 매니지드에 맡기면 그만큼 4K 차별화 영역에 자원을 집중할 수 있다는 판단이었습니다.

둘째, 1080p 트랙을 Amazon IVS Standard 채널에 전면 위임한 근거는 단순합니다 — 1080p · 60fps · 8.5Mbps라는 채널 상한이 1080p 시청 시나리오 요구사항을 안전 마진까지 포함해 커버한다는 사전 검증 결과 때문입니다. 다시보기·클립 같은 VOD 영역도 동일한 위임 결정 하에 별도 인코딩 파이프라인을 두지 않고 Amazon IVS의 자동 녹화 자산을 그대로 활용합니다.

셋째, 송출 권한 검증과 라이프사이클 이벤트를 처리하는 컨트롤 플레인을 Amazon EventBridge → Amazon SQS 파이프라인 위에 구축했습니다. Amazon IVS 영역에서 발생하는 이벤트와 자체 4K 영역에서 발생하는 이벤트가 동일 파이프라인을 흐르기 때문에, 컨트롤 플레인은 이벤트 출처와 무관하게 같은 인증·검증 로직을 적용합니다 — 이 이벤트 채널 단일화가 두 영역이 한 시스템처럼 동작하는 핵심 통합 지점입니다.

넷째, 영어권·일본어권 확장 시점에 1080p 트랙을 리전별 추가 구축 없이 Amazon CloudFront 글로벌 PoP 위에서 그대로 확장할 수 있도록 Amazon IVS 채택 시점부터 의도적으로 설계했습니다. 단, 4K 트랙의 리전 확장은 별도로 설계해야 하는 다음 단계의 과제로 남아 있으며, 자체 트랜스코딩 클러스터의 멀티 리전 분산 시나리오를 현재 검토 중입니다.

차별화 포인트인 4K 송출 영역에 대해서는, 매니지드의 표준 사양 범위를 의도적으로 초과하는 요구사항을 시청 경험의 핵심으로 정의했습니다 — 2160p · 35Mbps · 4초 이내 저지연. 이 정의 자체가 자체 데이터 플레인을 설계해야 할 이유였습니다. 결과적으로 매니지드는 표준 영역을 안정적으로 책임지고, 자체 구축은 차별화 영역에 집중하는 분리가 만들어졌습니다.

채택한 분기 전략은 다음과 같이 요약됩니다.

1080p 이하: 스트리머가 Amazon IVS로 직접 RTMP push → 트랜스코딩·시청·다시보기·클립이 Amazon IVS의 매니지드 환경에 위임
4K(35Mbps): 스트리머가 자체 구축한 RTMP 트랜스코딩 서버로 push → GPU 트랜스코딩 → 자체 HLS 시청 인프라. 동시에 Amazon IVS로도 재push되어 자동 녹화·다시보기 자산이 활용됨

4K 송출이라도 Amazon IVS로의 재push는 그대로 유지됩니다. 4K HLS는 자체 시청 인프라로 직접 서빙되지만, 다시보기·클립·기타 다중 해상도 시나리오는 여전히 Amazon IVS의 매니지드 환경 안에서 처리됩니다.

이 분기 설계를 통해 소수의 팀으로 1080p와 4K 듀얼 트랙을 동시에 운영하는 구조를 만들어냈습니다. 엔지니어링 팀의 인력과 운영 자원은 4K 차별화 영역에 집중적으로 배치되었고, 1080p 트랙의 운영 부담은 Amazon IVS의 매니지드 환경이 책임집니다.

4. 4K 라이브 인프라 아키텍처

씨미의 4K 라이브 인프라는 송출과 시청이라는 두 개의 데이터 플레인으로 구성되며, 두 영역 모두 직접 설계했습니다. 송출 경로는 스트리머의 RTMP 트래픽을 받아 Amazon IVS와 자체 트랜스코딩으로 분기하고, 시청 경로는 Amazon CloudFront를 통해 시청자에게 4K HLS를 저지연으로 전달합니다.

4-1. 송출 경로

스트리머의 4K RTMP 송출은 다음 경로를 거칩니다.

트랜스코딩 서버는 단일 프로세스에서 4K 입력을 두 경로로 분기합니다. 자체 4K HLS 경로는 시청자에게 원본 4K 화질을 저지연으로 직접 전달하기 위한 시청 경로로, 입력을 재인코딩 없이 그대로 통과시켜 원본 화질과 비트레이트가 유지된 매니페스트가 자체 시청 인프라로 서빙됩니다. Amazon IVS 재push 경로는 자동 녹화·다시보기·클립을 만들기 위한 자산 생성 경로로, 4K 입력을 GPU에서 Amazon IVS Standard 채널 사양(1080p)에 맞춰 다운스케일·재인코딩한 뒤 Amazon IVS의 매니지드 녹화 환경으로 송출합니다. 시청자에게 도달하는 4K 경로는 재인코딩 비용 없이 원본을 통과시키고, 자산 생성을 위한 IVS 경로만 GPU에서 재인코딩이 이루어지기 때문에 — GPU 인스턴스에서 4K 시청 경로와 IVS 자산 생성 경로가 동시에 운영됩니다.

송출 시점에는 권한 검증과 라이브 라이프사이클 처리를 담당하는 컨트롤 플레인 서비스에 콜백이 발생합니다. 컨트롤 플레인이 스트림 키 유효성과 해당 채널의 4K 송출 가능 여부를 검증한 후에야 트랜스코딩 서버가 실제 송출을 진행합니다.

4-2. 시청 경로

시청자의 4K 라이브 m3u8 요청은 Amazon CloudFront에서 우선 처리됩니다. 캐시 미스가 발생하면 자체 운영하는 HLS 서빙 서버로 전달되며, HLS 서빙 서버는 Amazon ElastiCache에서 해당 스트림이 저장된 트랜스코딩 서버 위치를 조회한 뒤 직접 프록시 요청을 수행합니다

캐시 정책은 콘텐츠 특성에 맞춰 차별화했습니다.

m3u8 (재생목록): 짧은 TTL — 1~5초 단위로 변경되는 동적 데이터
TS / m4s 세그먼트: 장기 캐시 (immutable) — 한 번 생성된 세그먼트는 변하지 않음

5. 라이브 + VOD 통합 — 클립 생성

라이브 시청만큼이나 중요한 것이 방송 이후의 사용자 경험입니다. 씨미는 라이브 시청 단계에서 끝나지 않도록, 다시보기·클립까지 같은 의사결정의 연장선에서 인프라를 설계했습니다.

5-1. Amazon IVS 녹화

라이브 방송이 끝나면 Amazon IVS는 해당 스트림의 HLS 녹화본을 Amazon S3에 자동 저장합니다. 이 자동 녹화 자산을 별도 인코딩 파이프라인 없이 다시보기·클립의 단일 원천으로 사용함으로써, 인코딩 파이프라인의 운영 부담을 줄이고 클립 생성 로직 자체의 품질에 집중할 수 있었습니다.

5-2. 라이브 클립과 비디오 클립

씨미는 두 종류의 클립 생성 흐름을 지원합니다.

비디오 클립 (다시보기 클립): Amazon IVS가 Amazon S3에 저장한 매니페스트를 조회하여 endTime 기준 2분 구간 세그먼트를 필터링한 뒤 새로운 m3u8을 생성합니다.
라이브 클립 (방송 진행 중 클립 생성): Amazon IVS의 라이브 매니페스트(HTTP, no-store)와 Amazon S3의 비디오 매니페스트를 동시에 조회한 뒤 두 세그먼트를 병합합니다.

5-3. 라이브 ↔ VOD 경계의 정합성 — PDT 기반 매칭

라이브 방송이 Amazon IVS의 자동 녹화로 변환되어 Amazon S3에 저장되기까지 수 초의 지연이 있습니다. 이 지연 구간에서 라이브 클립이 생성되면 두 가지 문제가 발생합니다.

라이브의 최신 세그먼트가 아직 Amazon S3 매니페스트에 반영되지 않음
라이브 매니페스트와 비디오 매니페스트의 경계 부근에서 동일 세그먼트가 중복

적용한 해결책은 두 가지입니다.

(1) 매니페스트 매칭 재시도 — 변환 지연 흡수

라이브 매니페스트의 마지막 세그먼트와 Amazon S3 비디오 매니페스트가 매칭되지 않으면, 짧은 대기 후 재시도를 수행합니다. 라이브 → Amazon S3 변환 지연을 흡수하는 메커니즘입니다.

(2) 시간 정보 기반 매칭으로 라이브와 VOD를 자연스럽게 연결

라이브 매니페스트는 방송이 진행되는 동안 생성되고, 비디오 매니페스트는 Amazon IVS의 자동 녹화 변환이 끝난 뒤 Amazon S3에 저장됩니다. 생성 시점이 다른 두 매니페스트를 경계 부근에서 한 영상으로 이어붙이려면, 동일한 세그먼트를 식별할 수 있는 공통 기준이 필요했습니다.

씨미는 HLS 표준의 EXT-X-PROGRAM-DATE-TIME(PDT) 태그를 매칭 키로 채택했습니다. 자체 트랜스코딩 서버는 매니페스트 생성 단계에서 PDT를 매 세그먼트에 삽입하고, Amazon IVS의 자동 녹화로 Amazon S3에 저장된 변환본도 동일 PDT를 그대로 보존하기 때문에 — 두 매니페스트에서 PDT가 일치하는 첫 번째 세그먼트가 자연스러운 경계 지점이 됩니다. 씨미는 이 경계 지점부터 라이브 측 세그먼트만 잘라 비디오 매니페스트 뒤에 이어붙여, 라이브와 VOD가 한 영상처럼 매끄럽게 이어지는 클립을 시청자에게 제공합니다.

라이브 세그먼트와 비디오 세그먼트는 저장 방식이 달라, 두 형식이 한 매니페스트에 함께 들어가는 지점에는 플레이어가 경계를 인식하고 디코더 상태를 새로 시작하도록 안내하는 HLS 표준 메타 정보를 추가합니다.

5-4. 결과

라이브 방송이 끝날 때까지 기다릴 필요 없이 방송 중에도 클립이 즉시 생성됩니다. Amazon IVS 자동 녹화와 자체 매니페스트 처리 로직을 결합해 라이브와 VOD를 하나의 사용자 경험으로 통합하는 클립 시스템을 설계했습니다.

6. 1만 시청자를 향한 부하 테스트

라이브·VOD 인프라가 갖춰진 뒤의 과제는 이 구조가 대규모 동시 부하에서도 안정적인가였습니다. 서비스 오픈을 앞두고 1만 명 동시 시청자를 가정한 부하 테스트가 진행되었습니다. 실제 운영 환경에서 항상 도달할 수치는 아니지만, 최악의 시나리오에서도 안정적인 시청 경험이 보장되는 것이 목표였습니다.

단순 시청자 수치만 보면 1만이 그리 큰 규모처럼 보이지 않을 수 있습니다. 다만 4K(35Mbps) 환경의 1만 시청자는 일반 1080p(8.5Mbps) 기준 약 4만 시청자에 해당하는 대역폭(약 350Gbps)을 요구합니다. 즉 고화질 스트리밍의 1만은 일반 스트리밍의 4만과 동급의 인프라 도전입니다.

6-1. 시나리오

송출 스펙: 4K(2160p) / 60fps / 최대 35Mbps / 4초 이내 저지연 목표
동시 시청자: 1,000 → 5,000 → 1만 단계적 증설
측정 지표: p50/p95/p99 시청 latency, buffer stalled 발생률, CDN 캐시 히트율, NAT Gateway throughput

6-2. NAT Gateway 대역폭의 함정

처음 검토한 항목은 NAT Gateway의 처리량이었습니다.

HLS 서빙 서버는 프라이빗 서브넷에 배치되어 Amazon CloudFront 응답이 NAT Gateway를 경유합니다. 단계적 증설 과정에서 NAT Gateway의 처리량은 약 22Gbps 부근에서 정체되었습니다. AWS 문서에는 NAT Gateway가 5Gbps에서 시작해 최대 100Gbps까지 자동 확장된다고 안내되어 있어, 정체 현상의 원인을 즉시 파악하기 어려웠습니다.

문서 안내와 실측 사이의 차이를 두고 22Gbps 정체의 원인을 NAT Gateway 자체 한계가 아닌 별도 요인으로 가설을 잡고 좁혔고, 실제로 확장이 점진적으로 이루어지는 것을 확인했습니다.

트래픽 추세에 따라 단계적으로 처리량이 증설되며, 1차 테스트 후 ScaleDown 상태에서 2차 테스트가 진행되면 Warm-up이 부족해 충분한 대역폭이 확보되지 않습니다.

이 한계를 회피하기 위한 방법으로 다음 세 가지를 검토했습니다.

퍼블릭 서브넷에서 부하 테스트 — NAT Gateway를 경유하지 않도록 함
AZ별 NAT Gateway 분산 배치 — AZ당 독립된 처리량 확보
테스트를 점진적으로 진행 — Warm-up이 유지되도록 간격 최소화

이 중 첫 번째 방법을 채택했습니다. 부하 테스트 환경에서만 HLS 서빙 서버를 퍼블릭 서브넷에 배치해, NAT Gateway 영향 없이 순수 인프라 한계를 측정했습니다.

다른 팀을 위한 시사점: 라이브/스트리밍 워크로드의 인프라 대역폭 계산 시, EC2 NIC 대역폭만 보면 실효 대역폭을 과대 추정하게 됩니다. NAT Gateway warm-up 상태에서는 EC2 NIC 한계의 일부만 실제로 사용 가능합니다. 따라서 실효 수신 대역폭 = min(EC2 NIC 대역폭, NAT Gateway 현재 warm-up 처리량) 으로 산정하는 것이 안전합니다. 갑작스러운 트래픽 증가(방송 시작 직후 thundering herd 등)가 예상되면, AZ별 NAT Gateway 분산 또는 퍼블릭 서브넷 배치를 사전에 검토해야 합니다.

6-3. buffer stalled 오류와 L2 Fan-out 분석

본 절은 부하 테스트라는 특수 환경 + 4K(35Mbps) 고비트레이트 + 세그먼트 동시 인입 타이밍이 결합되었을 때 관측 가능한 사례입니다. 실제 운영 환경에서는 후술하는 자연 회피 메커니즘으로 인해 발생 가능성이 매우 낮습니다.

부하 테스트 도중 일부 시청자에서 buffer stalled 오류가 다발했습니다. 트랜스코딩 서버와 HLS 서빙 서버는 모두 여유 상태였기 때문에, 병목의 원인을 origin 병목이 아닌 CDN 내부 어딘가에서 발생하는 collapsing으로 가설을 좁혀나갔습니다. 이 가설을 AWS Solutions Architect 팀과 공유하면서 Amazon CloudFront POP 내부 구조를 함께 검증했습니다.

(a) Amazon CloudFront POP 내부 구조 — L1 / L2 / REC 계층

모든 요청은 L1 계층으로 인입
L1에서는 collapsing이 발생하지 않음 — 모든 요청이 L2로 전달되며, 동일한 캐시키(URL)는 단일 L2 host로 집중
L2에서 collapsing이 발생 — 1개의 요청만 다음 캐싱 계층(REC)으로 전달, 나머지 요청들은 L2에서 응답 대기
L2가 REC로부터 응답을 받는 순간, L2에서 대기 중인 수천 개 요청들이 동시에 fan-out

(b) 정량 분석

5,000명이 동일한 캐시되지 않은 세그먼트(약 3.6MB)를 동시에 요청하는 시나리오를 가정하면, 단일 L2 host 기준 순간 fan-out 부하는 약 57.6Gbps(3.6MB × 5,000 × 8 / 응답 시간)에 달합니다. 이 구간에서 단일 L2 host의 네트워크 처리 한계로 latency가 증가하는 것으로 추정했습니다.

(c) URL Sharding으로 L2 host 분산 (캐시키 분기)

이 구조를 바탕으로 씨미가 찾아낸 회피책은 동일한 세그먼트를 여러 개의 다른 URL로 요청해 L2 host를 분산하는 캐시키 분기입니다. shard 개수는 동시 시청자 수에 따라 동적으로 결정합니다.

예를 들어 5,000명 시청자를 4개 shard로 분기한 모습입니다.

/s0/…/playlist-xxx.m4s ← 시청자 그룹 A (1,250명)
/s1/…/playlist-xxx.m4s ← 시청자 그룹 B (1,250명)
/s2/…/playlist-xxx.m4s ← 시청자 그룹 C (1,250명)
/s3/…/playlist-xxx.m4s ← 시청자 그룹 D (1,250명)

Amazon CloudFront는 서로 다른 캐시키로 인식해 여러 L2 host에 분산 캐싱하고, HLS 서빙 서버에서는 shard prefix가 제거된 단일 URI로 트랜스코딩 서버에 프록시됩니다. 캐시 락(cache_lock) 메커니즘으로 모든 shard의 캐시 미스가 동시에 발생하더라도 트랜스코딩 서버에는 1개의 요청만 전달됩니다.

→ 트랜스코딩 서버 부하는 그대로 유지하면서 CDN L2 분산 효과만 취득.

(d) 운영 환경에서는 거의 발생하지 않는 시나리오

이 병목은 부하 테스트라는 인공적인 환경에서만 관측되는 패턴입니다. 운영 환경에서 동일한 패턴이 발생할 가능성을 매우 낮게 평가하는 근거는 세 가지 분산 효과가 중첩되기 때문입니다.

클라이언트 환경의 자연적 다양성: 실제 시청자들은 ISP, 디바이스, 플레이어 시작 시점이 모두 달라 동일 세그먼트가 정확히 동시에 요청되지 않음
HLS 클라이언트 자연 jitter: 플레이어마다 자연 발생하는 jitter로 세그먼트 요청 인입 타이밍이 자연스럽게 분산됨
의도적으로 적용한 1초 범위 클라이언트 시작 jitter: 자연 분산을 인위적으로 한 단계 더 강화

이 분산 메커니즘이 함께 작용하면, 단일 L2 host로의 collapsing 압력이 부하 테스트 수준까지 올라갈 가능성은 매우 낮습니다.

(e) 결론

URL Sharding은 운영 환경에서 거의 발생하지 않을 시나리오에 대한 사전 대비책입니다. 그럼에도 부하 테스트에서 관측한 패턴을 최악의 가정으로 두고 미리 적용한 이유는 단순합니다 — 방송 오픈을 안심하고 맞이하기 위해서. 충분히 가능성이 낮은 시나리오라도 회피 가능한 카드를 사전에 준비해두면, 알파·오픈 단계에서 예상치 못한 패턴이 발생하더라도 즉시 대응이 가능합니다.

6-4. 부하 테스트 결과

단계적 증설(1,000 → 5,000 → 1만)을 거치며 4K 35Mbps · 1만 시청자 동시 부하 환경에서 안정적인 시청 경험을 확인했습니다. 4초 이내 저지연 목표가 유지되었고, CDN 캐시 히트율도 안정 범위에서 운영되었습니다. NAT Gateway warm-up 한계, Amazon CloudFront L2 fan-out 같은 극단 시나리오에 대한 사전 대비책까지 적용한 상태에서, 알파·오픈 단계의 예상 외 패턴에도 즉시 대응 가능한 인프라 기반을 마련했습니다.

7. 시청자 경험을 위한 Amazon CloudFront 캐시 전략

부하 테스트 이후, 일상 운영 환경에서도 안정적인 시청 경험을 위해 Amazon CloudFront와 HLS 서빙 서버 사이의 캐시 정책을 다음 원칙으로 설계했습니다.

Origin Shield:글로벌 트래픽의 유입으로, 경유하는 Regional Edge Cache POP 수가 늘어나더라도 HLS 서빙 서버가 받는 요청 수가 일정하게 보장됩니다. 1만 시청자 시나리오에서 HLS 서빙 서버 부하를 일정하게 유지하는 핵심 장치입니다.
재생목록(m3u8) 짧은 TTL + stale-while-revalidate: 자주 갱신되는 매니페스트는 짧은 캐시를 두되, 만료 시점에는 stale 응답이 잠시 허용되면서 백그라운드 재검증이 수행됩니다. 캐시 만료 시점의 thundering herd가 자연스럽게 완화됩니다.
세그먼트(.m4s) 영구 캐시(immutable): 한 번 생성된 세그먼트는 변경되지 않으므로 영구 캐시되어, CDN 캐시 히트율이 높게 유지됩니다. 또한 압축 설정을 비활성화하여 압축과 관련된 캐시키를 최적화하여 히트율을 더욱 높입니다.(캐시키에서 HTTP Accept-Encoding 헤더 제거)

추가로 HLS 플레이어가 시작되는 시점에 랜덤 지터가 적용되어, 방송 시작 직후의 버스트 트래픽이 인위적으로 분산됩니다.

8. Amazon IVS와 자체 구축, 어디서 선을 그을 것인가

지금까지 살펴본 송출·시청·클립·부하 테스트·캐시 전략의 모든 의사결정에는 한 가지 공통된 원칙이 있습니다.

씨미 사례에서 가장 중요한 의사결정은 어떤 영역을 Amazon IVS에 위임하고, 어떤 영역을 직접 설계할 것인가였습니다. 이 분기 결정에 적용한 기준은 다른 라이브 워크로드를 검토하는 팀에도 참고가 될 수 있습니다.

8-1. 매니지드에 위임하는 영역의 조건

다음 조건을 모두 만족하는 영역은 Amazon IVS의 매니지드 환경에 위임되는 것이 합리적입니다.

표준 사양 안에서 동작 가능: 1080p 이하 · 8.5Mbps 이하처럼 매니지드 서비스의 사양 범위 내에서 충족 가능한 워크로드
차별화 포인트가 아님: 트랜스코딩·자동 녹화·다중 비트레이트 전송처럼 사용자 경험의 차별 요소가 아닌 일반 영역
운영 부담이 큼: 24/7 모니터링·확장·장애 대응이 매니지드에 위임될 때 ROI가 크게 개선되는 영역

씨미의 1080p 송출, 자동 녹화, 다중 비트레이트 전송이 이 조건에 해당합니다.

8-2. 자체 구축이 정당화되는 영역의 조건

다음 조건 중 최소 한 가지를 만족하면 자체 구축을 검토할 가치가 있습니다.

매니지드 사양의 한계를 넘는 요구사항: 씨미 케이스에서 4K · 35Mbps · 4초 이내 저지연이 여기 해당
차별화 영역: 비즈니스 가치와 직결되어 사용자 경험의 결정 요소가 되는 영역
자체 데이터 플레인 제어가 필요: 캐시 정책·라우팅 로직·트래픽 분산 정책이 비즈니스 요구사항에 따라 달라져야 하는 영역

씨미의 4K 시청 인프라(트랜스코딩 서버, HLS 서빙 서버, Amazon CloudFront 캐시 정책, URL Sharding)가 이 조건에 부합합니다.

8-3. 두 영역의 통합 — 이벤트 채널과 자산 공유

분기된 두 영역이 통합된 하나의 시스템처럼 동작하려면, 영역 간 인터페이스가 일관되어야 합니다. 씨미가 적용한 두 가지 통합 패턴은 다음과 같습니다.

이벤트 채널 단일화: 송출 시작·종료, 권한 검증 같은 라이프사이클 이벤트는 자체 구축 영역과 Amazon IVS 영역이 모두 같은 Amazon EventBridge → Amazon SQS 파이프라인을 통해 전달됩니다. 컨트롤 플레인은 이벤트 출처와 무관하게 동일한 인증·검증 로직을 적용합니다.
자산 공유: 4K 송출도 Amazon IVS로 재push되어 자동 녹화 자산이 생성됩니다. 다시보기·클립 같은 VOD 워크로드는 송출 경로의 차이와 관계없이 Amazon IVS의 자동 녹화 자산을 단일 원천으로 활용합니다.

씨미는 이 두 통합 패턴(이벤트 채널 단일화 + 자산 공유)을 통해 — 사용자에게는 1080p와 4K가 동일한 라이브 시스템으로 보이고, 운영 팀에게는 두 트랙이 동일한 모니터링·인증·VOD 흐름을 공유하는 추상화를 설계했습니다.

9. 마무리

씨미는 Amazon IVS의 매니지드 환경과 자체 구축 영역의 결합을 통해 다음 세 가지 측면에서 의도한 결과를 얻었습니다.

개발 측면, 4K GPU 트랜스코딩, 시간 정보 기반 매니페스트 매칭, URL Sharding 캐시 분산 같은 차별화를 두고, 일반 영역(1080p 송출·자동 녹화·다시보기)은 Amazon IVS의 매니지드 환경이 책임짐으로써, 소수의 팀이 듀얼 트랙을 동시에 운영하는 구조를 만들어냈습니다.

운영 측면, 1만 명 동시 시청자 규모의 부하 테스트를 안정적으로 통과했고, NAT Gateway warm-up 한계와 Amazon CloudFront L2 fan-out 패턴 같은 인공적인 환경 조건까지 사전 검증했습니다. 운영 환경에서 발생 가능성이 낮은 시나리오까지 사전 대비책을 적용해, 알파·오픈 단계에서 예상치 못한 패턴이 발생하더라도 즉시 대응 가능한 인프라 기반을 확보했습니다.

비즈니스 측면, 4K 화질의 몰입감과 실시간 라이브의 즉시성을 동시에 제공해, 시청자가 실제로 함께 게임하는 듯한 경험을 통해 시청자 체류와 실시간 인터랙션 같은 라이브 스트리밍 서비스의 핵심 가치를 제공할 수 있는 기반을 마련했습니다.

씨미는 이제 막 첫 걸음을 뗀 서비스입니다. 본 글에서 다룬 모든 의사결정 — 4K 라이브 스트리밍이라는 차별화 영역에서 AWS 매니지드와 자체 구축의 경계를 그은 결정, 부하 테스트에서 마주한 시행착오, 두 영역을 한 시스템처럼 묶은 통합 패턴 — 은 그 첫 걸음에서 씨미 엔지니어링 팀이 얻은 학습의 일부입니다. 이러한 학습이 비슷한 도전을 앞둔 다른 라이브 스트리밍 팀에게 한 가지 참고점이 된다면, 그 자체가 씨미에게도 의미 있는 다음 걸음이 될 것입니다.

AWS 기술 블로그