나만의 동영상 스트리밍 시스템 설계하기 - (2. 동영상 업로드/재생 설계)에서 이어집니다!
3. 동영상 업로드 실시간 알람 설계
1. 서비스 이해 및 해결해야 할 문제 파악하기
띵동 서비스에서 동영상 업로드가 필요한 곳은 피드를 생성할 때이다.
피드는 동아리 활동을 일반 학생들에게 쉽게 보여줄 수 있도록 만든 기능이다.
피드 생성은 총 3단계로 이루어져 있다.
- 활동 내용을 입력한다.
- 동영상을 업로드한다.
- 업로드 하기 버튼을 클릭한다.
아래 실제 피드 생성 페이지를 보면 더욱 쉽게 이해할 수 있을 것이다.
현재 동영상은 위에서 말했던 것과 같이 비동기 방식으로 업로드를 선택했다.
동영상 업로드를 성공적으로 끝났다는 것은 원본 동영상 업로드뿐만 아니라 비동기로 처리되는 트랜스코딩 및 변환 파일 저장까지 완료된 것으로 정의한다.
현재 비동기 방식을 사용하면서 한 가지 문제가 발생했다. 원본 동영상이 S3에 저장되는 즉시 사용자에게 "업로드 완료" 응답을 보내지만, 실제로는 백그라운드에서 트랜스코딩 작업이 여전히 진행 중인 상태다. 즉, 사용자는 업로드가 완료되었다고 생각하지만, 실제로 동영상을 재생할 수 있는 상태가 아닐 수 있다. 이러한 간극으로 인해 사용자 경험에 혼란이 생길 수 있으며, 트랜스코딩 실패 시 사용자에게 이를 알릴 방법이 없다는 문제가 있다.
따라서 트랜스코딩 및 변환 파일 저장이 완료된 시점에 사용자에게 알람을 보내는 기능이 필요하다.
어떻게 할 수 있을까? 가장 단순한 방법은 트랜스코딩 및 변환 파일 저장 작업까지 동기 작업에 포함시키는 것이다. 하지만 이 방법은 앞에서 말했던 것과 같이 한계가 명확하다. 그래서 나는 비동기 작업을 유지하면서 실시간으로 비동기 작업에 대한 성공 알람을 보내는 방법을 알아봤다.
동영상 성공 알람을 보여주는 시점은 아래 두 가지 경우가 있었다.
- 사용자가 “업로드 하기”를 클릭하는 것과 관계없이 동영상 업로드를 한 후 업로드 완료되었다면 바로 알람을 보여주는 것
- 사용자가 “업로드 하기”를 클릭했을 때만 동영상 업로드 완료 알람을 보여주는 것
팀 내 회의를 통해 두 번째로 결정하였다. 아직 피드 업로드를 안했는데, 동영상 업로드 완료 알람이 발생되면 어색할 것 같았기 때문이다.
사용자가 “업로드 하기”를 클릭했을 때만
이를 재해석해서 아래로 표현할 수 있다.
피드 작성을 완료했을 때만
알람 발생 조건에 “피드 작성을 완료했을 때만”이라는 사용자의 액션이 포함되어있기 때문에, 알람 전송 경우가 두 가지로 나뉘었다.
아래의 그림으로 살펴보자.
첫 번째는 사용자가 피드 작성을 완료하기 전, 동영상 업로드가 완료되었을 때이다.
이때는 동영상 업로드가 완료된 직후 알람을 보내지 않고 대기한 뒤, 사용자가 피드 작성을 완료했을 때 동영상 업로드 알람도 바로 전송을 해야한다.
두 번째는 사용자가 피드 작성을 완료했지만, 동영상 업로드가 완료되지 않은 경우다.
이때는 동영상 업로드가 완료될 때까지 대기했다가 업로드가 완료되면 알람을 전송해야 한다.
나는 이 두 경우를 동영상 업로드 작업 및 알람 상태관리와 SSE를 통해 해결하였다.
동영상 업로드 작업 및 알람 상태관리로 사용자의 액션에 따라 달라지는 알람 시점을 해결하였고, SSE를 통해 비동기 작업으로 인해 응답 후 끊어지는 HTTP 비연결성을 해결하였다.
2. 상태관리 설계 및 SSE 설계
먼저 상태관리를 받을 테이블(Entity)를 VodProcessingJob, VodProcessingNotfication 두 개를 생성하였다.
VodProcessingJob에는 세 가지 상태가 있다.
- PENDING - 변환 작업 중
- COMPLETED - 변환 작업 완료
- ERROR - 변환 작업 실패
VodProcessingNotfication에는 네 가지 상태가 있다.
- PENDING - 알람 대기
- SENT - 서버에서 알람 전송
- COMPLETED - 클라이언트 알람 수신 완료
- FAILED - 알람 실패
이제 각각 엔티티의 상태를 어느 시점에 변경시켰는지 알아보자.
위 그림은 앞서 살펴봤던 동영상 업로드 파이프라인이다.
업로드 파이프라인에 하나씩 추가해 볼 것이다.
1. VodProcessingJob, VodProcessingNotfication PENDING 상태 생성하기
제일 먼저, S3 원본 저장소에 원본 동영상이 저장된 후 실행되는 Lambda 함수에 VodProcessingJob, VodProcessingNotification 상태를 PENDING으로 바꿔주는 서버 어플리케이션 API를 호출한다.
이때 동영상 변환 작업이 시작되었기에, 동영상 변환작업 히스토리성 엔티티와 동영상 변환작업 알람 히스토리성 엔티티를 준비시켜주는 작업이다.
2. VodProcessingJob COMPLETED 상태로 변경하기
EventBridge가 Mediaconvert의 작업 완료 혹은 실패 이벤트를 감지하면 완료 처리를 담당하는 Lambda 함수가 실행된다.
이 Lambda는 이벤트에서 jobId와 status를 추출하여 서버 애플리케이션 API를 호출한다. 동영상 변환 작업이 성공하였을 경우, 서버는 해당 요청을 받아 동영상 상태를 COMPLETED로 변경하고, 변환된 파일의 S3 경로 정보를 저장한다.
3-1 동영상 업로드 작업 관점에서 알람 전송
앞서 MediaConvert에서 작업이 완료되어 서버 API를 호출하여 VodProcessingJob을 COMPLETED로 변경한 후 알람 전송 작업을 추가로 진행해야한다.
사용자가 피드 작성을 완료했다면, 피드 작성 완료한 후 동영상 업로드가 완료되었으니 즉시 알람을 보내고 VodProcessingNotification 상태를 SENT로 변경시켜준다.
사용자가 피드 작성을 완료하지 않았다면, 피드 작성 완료 전 동영상 업로드가 완료되었으니 알람을 보내지 않고 그대로 종료한다.
3-2 피드 생성 관점에서 알람 전송
사용자가 피드 업로드 버튼을 클릭하면 실시간 알람을 위한 SSE구독 API를 먼저 호출한 후 피드 생성 API를 호출한다.
동영상 업로드가 완료되었을 경우 즉시 알람을 보내고 VodProcessingNotification 상태를 SENT로 변경시켜준다.
동영상 업로드가 완료되지 않았을 경우 기다려야하기 때문에 그대로 종료한다.
4. 클라이언트가 알람 수신 완료 API 호출
클라이언트가 알람 수신 API를 호출함으로써 VodProcessingNotification 상태를 COMPLETED로 변경한다.
마무리
이번 글에서는 동영상 스트리밍의 핵심 개념부터 업로드·처리 파이프라인 설계, 그리고 실시간 알림 구현까지 실제 서비스 상황을 기준으로 어떤 기술을 선택했고 왜 그렇게 결정했는지를 중점적으로 다뤘다.
다만, 글의 범위를 넘어서거나 깊이 있게 다루지 못한 부분도 있다.
첫째, SSE, CDN 등의 기술적인 세부 구현과 이유를 충분히 설명하지 못하였다.
간략하게 SSE는 비동기 트랜스코딩 완료 알림을 실시간으로 전달하기 위해 선택했고, CDN은 캐싱 및 S3전송 비용을 절감 및 접근 제어 역할을 위해 사용했다. 하지만 이 글에서는 핵심 설계 맥락에 집중하기 위해 해당 기술의 원리나 구현 방법까지는 다루지 않았다.
둘째, 실패 전략(Failure Strategy)을 다루지 않았다.
지금 글에서는 성공 플로우만 설명했지만, 실제 서비스 환경에서는 트랜스코딩 실패, 업로드 중단, 알림 전송 실패 등 다양한 예외 상황이 발생할 수 있다. 이 부분에 대한 재시도 전략, 멱등성 보장, 알림 실패 대응 방안은 안정적인 시스템 운영에 있어 매우 중요한 요소이며, 반드시 별도의 설계가 필요하다.
셋째, 파일 메타데이터 관리에 대한 설명도 다루지 않았다.
영상 자체만큼이나 메타데이터(파일 이름, 길이, 상태, S3 경로, jobId 등)를 관리하는 방법도 중요하다. 실제 서비스에서는 DB 등에 별도로 두고, 파일 상태와 처리 결과를 체계적으로 관리해야 한다.
모든 기술을 선택한 이유가 명확하고 합리적이어야 한다!
[Reference]
https://en.wikipedia.org/wiki/Progressive_download
https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming
https://cloudinary.com/guides/video-formats/pixel-perfect-h-264-vs-h-265-explained
https://docs.aws.amazon.com/mediaconvert/
'프로젝트 > 띵동' 카테고리의 다른 글
| 나만의 동영상 스트리밍 시스템 설계하기 - (2. 업로드/재생 설계) (0) | 2025.10.28 |
|---|---|
| 나만의 동영상 스트리밍 시스템 설계하기 - (1. 핵심 개념) (0) | 2025.10.28 |
| Critical GC 장애 대응기: 19초 서비스 중단에서 30ms 이하로 (2) | 2025.09.06 |