드래그 앤 드롭 스케줄링에서 프로그램 시간 조정 관리

라이브 TV 운영자에게 스케줄링 도구에서 무엇을 보고 싶은지 물어보면, 그들은 거의 예외 없이 이렇게 말합니다. "폴더에 파일을 정리하는 방식으로 채널을 만들게 해주세요. 프로그램을 드래그하여 원하는 위치에 놓으면 끝입니다.

문제는 채널 스케줄이 폴더가 아니라는 점입니다. 채널 스케줄은 엄격한 제약 조건을 가진 법적 문서입니다. 두 프로그램이 동시에 재생될 수 없습니다. 인코더는 5초보다 빠르게 입력을 전환할 수 없습니다. 이미 시작된 프로그램은 편집할 수 없습니다. 그리고 자정을 넘어가는 영화는 날짜 경계에서 잘리지 않고 하나의 프로그램으로 취급되어야 합니다.

모든 드래그 앤 드롭 작업은 잠재적인 제약 조건 위반을 초래할 수 있습니다. 이 글은 mStudio의 스케줄러가 운영자 친화적인 드래그 앤 드롭을 AWS MediaLive에서 법적으로 보장된 채널 타임라인으로 바꾸는 엔지니어링 이야기입니다. 여기에는 운영자가 프로그램을 다른 프로그램 위에 직접 드롭하는 순간까지 포함되며, 시스템이 운영자에게 오류와 해결할 퍼즐을 제시하는 대신 이러한 충돌을 자동으로 해결하는 이유를 설명합니다.

빠른 개요

비즈니스 문제: 캘린더가 아닌 캘린더

채널 스케줄링은 캘린더 소프트웨어처럼 보입니다. 운영자들은 캘린더처럼 작동하기를 기대합니다. 영화를 오후 9시 슬롯으로 드래그하고, 프로그램을 타임라인 위로 밀어 올리고, 시리즈를 일괄 추가하여 에피소드가 연달아 배치되는 것을 봅니다. 그러나 라이브 채널 스케줄에는 캘린더에는 없는 제약 조건이 있습니다.

• 프로그램은 중복될 수 없습니다. 라이브 TV는 한 번에 정확히 한 가지만 재생합니다.
• 인코더에는 최소 동작 간격이 있습니다. AWS MediaLive는 5초보다 빠르게 입력을 전환하지 않습니다. 두 프로그램을 4초 간격으로 스케줄링하면 배포가 거부됩니다.
• 지난 프로그램은 편집할 수 없습니다. 이미 방송 시간이 지났고, 비트는 시청자의 화면에 이미 있습니다.
• 자정을 넘어가는 프로그램은 하나의 단위입니다. 23:30부터 01:15까지 실행되는 영화는 날짜 경계에서 두 개의 절반 프로그램으로 분할되지 않고 하나의 프로그램으로 처리되어야 합니다.

2초의 "거의 중복"은 운영자 오류가 아닙니다. 두 프로그램을 드래그했는데 거의 맞지만 완벽하게 맞지 않는 경우의 자연스러운 결과입니다. 진정한 엔지니어링 과제는 "영화 9시로 드래그"를 "법적 채널 스케줄"로 번역하는 것입니다. 잘못되면 운영자는 드롭할 때마다 오류의 벽에 부딪히거나, 더 나쁜 경우, 방송 시간에 인코더가 스케줄의 일부를 조용히 거부했다는 것을 발견하게 됩니다.

AWS MediaLive에서 '법적'이란 무엇을 의미하는가

MediaLive에서 스케줄이 법적 효력을 가지려면 인접한 프로그램은 다음 중 하나여야 합니다.

1. 연속적이어야 합니다 — 프로그램 사이에 간격이 없어야 합니다, 또는
2. 최소 5초 이상 떨어져 있어야 합니다 — 인코더의 최소 동작 간격입니다.

함정은 그 사이의 모든 것입니다. 1초 간격, 3초 간격, 4.9초 간격 — 이 모든 것이 UI에서는 완벽해 보이지만, 배포 시에는 모두 거부됩니다. 더 나쁜 것은, 거부가 깔끔하고 원자적인 실패가 아니라는 점입니다. 이는 부분적으로 배포된 채널을 초래할 수 있으며, 일부 스케줄 작업은 MediaLive에 적용되고 다른 작업은 적용되지 않을 수 있습니다.

애플리케이션 서버와 AWS 간의 클럭 드리프트에 대한 1초의 안전 여유를 추가하면 실제 최소 간격은 5초가 아닌 6초가 됩니다. 이 단일 숫자 — MIN_NEIGHBOUR_GAP_MS = 6000 — 가 전체 충돌 해결 시스템이 구축된 유일한 상수입니다.

명백한 접근 방식이 실패하는 이유

자동 해결 방식을 결정하기 전에, 몇 가지 더 명백한 전략들이 고려되었으나 기각되었습니다.

"모든 불일치를 거부하고 운영자에게 해결을 요청합니다." 이 때문에 운영자들은 드롭할 때마다 수동으로 스냅 계산을 수행해야 합니다. 5초의 드래그는 5분짜리 퍼즐이 되고, 재생 목록이 길어질수록 퍼즐은 더 어려워집니다. 실제로는 운영자들이 드래그 앤 드롭을 완전히 포기하고 스프레드시트로 돌아갑니다.

"모든 것을 5분 경계에 맞춰 중복되지 않도록 합니다." 이는 운영자의 의도를 파괴함으로써 기술적인 문제를 해결합니다. 21:03:15에 시작되어야 할 프로그램이 21:05:00으로 조용히 건너뛰어서는 안 됩니다. 스케줄은 반올림 기능이 아닌 운영자의 소유입니다.

"드롭 시간 대신 배포 시간에 충돌을 감지합니다." 이는 UI에서 더 빠르게 느껴지지만, 실패 시점을 최악의 순간으로 옮깁니다. 운영자가 배포를 클릭하고 "프로그램 47에서 스케줄 거부"를 볼 때쯤이면, 그들은 이미 해당 편집 작업에서 정신적으로 벗어난 상태입니다.

"UI에서 미세 간격을 허용하고 MediaLive가 거부하도록 둡니다." 이는 불투명한 인코더 오류를 운영자에게 직접 되돌려주며, 채널을 복구하기 매우 어려운 부분 배포 상태로 만들 수 있습니다.

실제로 효과가 있었던 해결책은 확정적인 규칙을 사용하여 드롭 시간에 충돌을 자동으로 해결하고, 수정된 타임라인을 운영자에게 즉시 반영하는 것이었습니다.

해결책: 4가지 규칙 스냅 알고리즘

모든 드롭 시, 스냅 알고리즘은 영향을 받는 채널의 인접한 프로그램 쌍 (새 프로그램-새 프로그램, 새 프로그램-기존 프로그램, 또는 드롭으로 인해 간격이 변경된 기존 프로그램-기존 프로그램 쌍)을 검사하고, 그들 사이의 간격에 따라 다음 네 가지 규칙 중 정확히 하나를 적용합니다.

• 간격 = 0 → 아무 조치 없음. 연속적인 것은 법적으로 유효하며, 거의 확실하게 운영자가 의도한 바입니다.
• 간격 ≥ 6초 → 아무 조치 없음. 운영자가 의도적으로 공간을 남겼으며, 슬레이트 또는 광고 삽입을 위한 것일 가능성이 높습니다.
• 0 < 간격 < 6초 → 두 번째 프로그램을 뒤로 이동하여 간격을 0으로 만듭니다.
• 음수 간격 (중복) → 중복된 양만큼 두 번째 프로그램을 앞으로 이동합니다.

결정적으로, 알고리즘은 정렬된 타임라인을 단일 순방향 패스로 인접한 쌍을 처리합니다. 각 이동된 프로그램은 다음 비교를 위한 즉시 "이전" 항목이 됩니다. 따라서 연쇄적인 이동을 유발하는 드롭은 재귀 없이 하나의 선형 탐색으로 해결됩니다.
다이어그램 1 · 스냅 의사 결정 트리

시스템 아키텍처

스케줄러는 작고 집중된 일련의 구성 요소로 구축됩니다.

• NestJS 백엔드 (schedule.service.ts)는 스냅 탐색, 연쇄 메모화, 그리고 MediaLive와의 쓰기 계약을 담당합니다.
• 시간 범위 중복 쿼리. 드롭이 도착하면, 백엔드는 새로운 배치 범위에 접촉하는 모든 기존 프로그램의 시간 창과 양쪽에 6초 버퍼를 가져옵니다. 이 쿼리는 캘린더 날짜가 아닌 시간 범위에서 작동하므로, 자정을 넘어가는 프로그램은 다른 프로그램과 동일하게 처리됩니다 — 시스템 어디에도 특별한 날짜 경계 로직이 존재하지 않습니다.
• 병합된 타임라인. 새로운 프로그램 DTO와 쿼리된 기존 프로그램은 단일 정렬된 목록으로 병합됩니다. 스냅 탐색은 이 결합된 타임라인에 대해 실행됩니다.
• shiftedExistings 맵. 시간 조정에 의해 영향을 받은 모든 기존 프로그램에 대해, 이 맵은 프로그램이 처음 영향을 받을 때 원래 시작 시간과 종료 시간을 캡처하며, 이후의 영향에서는 이를 덮어쓰지 않습니다. 이 단일 데이터 구조가 다단계 연쇄를 안전하게 만듭니다.
• Lambda DELETE_PROGRAM. MediaLive에 이미 배포된 이동된 프로그램의 경우, MongoDB가 업데이트되기 전에 해당 프로그램의 원본 시간이 정리 작업을 위해 Lambda 함수로 전송됩니다.

• MIN_NEIGHBOUR_GAP_MS = 6000 — 모든 규칙, 모든 중복 쿼리, 그리고 모든 안전 버퍼가 참조하는 단일 상수입니다.

   

주요 엔지니어링 결정

1. 네 가지 규칙, 한 번의 탐색, 특별한 경우 없음. 동일한 네 가지 규칙이 운영자가 만들 수 있는 모든 시나리오를 다룹니다. 두 기존 프로그램 사이에 드롭된 새 프로그램, 서로 충돌하는 두 새 프로그램, 또는 동일한 드롭에서 이전 이동에 의해 중복으로 밀려나는 기존 프로그램 등입니다. 이들 중 어떤 경우에도 별도의 코드 경로는 없으며 — 모든 경우는 "인접한 프로그램 사이의 간격을 검사하고 규칙을 적용"하는 것으로 귀결됩니다.

2. 5초가 아닌 6초. MediaLive는 스케줄 작업 사이에 최소 5초 간격을 강제합니다. 4.9초 간격으로 두 개의 입력 전환을 스케줄링하면 배포가 거부됩니다. 시스템은 6초를 강제합니다. 이는 백엔드 클럭과 AWS 클럭 사이의 클럭 드리프트에 대한 1초의 안전 여유입니다. 인코더 클럭이 4.997초로 읽을 때 정확히 5.000초에 작업을 제출하면 네트워크 오류처럼 보이고 재현 불가능한 버그처럼 느껴지는 간헐적인 거부가 발생합니다. 추가 1초는 간헐적인 실패 모드를 아예 발생하지 않는 모드로 전환합니다.

여기에는 의도적인 절충이 따릅니다. 6초의 최소 간격은 3초 또는 4초와 같은 짧은 연속 간격이 보존되기보다는 0으로 닫히도록 스냅 처리된다는 것을 의미합니다. 이러한 절충은 의도적으로 수용되었습니다. MediaLive에서는 연속 전환이 깔끔하며, 3초의 가시적인 간격은 시청자에게 관계없이 결함처럼 보일 수 있기 때문입니다.

3. 원본 시간 메모화로 연쇄를 안전하게 만듭니다. 한 번의 드롭으로 연쇄적인 이동이 트리거될 수 있습니다. 프로그램 A가 B를 이동시키고, B가 C를 이동시키고, C가 D를 이동시키는 식입니다. MediaLive에 대한 정리 호출은 각 프로그램의 연쇄적으로 이동된 시간이 아닌 원본 배포 시간을 대상으로 해야 합니다. 잘못된 시간을 사용하면 MediaLive가 "작업을 찾을 수 없음"으로 응답하여 정리 작업이 조용히 실패합니다. 탐색은 각 프로그램이 처음 영향을 받을 때 캡처된 programId → {oldStartTime, oldEndTime} 맵을 유지합니다. 이후의 연쇄 이동은 메모리 내 타임라인만 업데이트합니다. 메모화된 원본은 그대로 유지되며, 정리 작업은 항상 MediaLive에 실제로 기록된 내용을 정확히 사용합니다.
다이어그램 2 · 연쇄 예시
 

4. 지난 날짜 보호, 두 개의 별도 단계에서 강제됩니다. 지난 날짜의 편집은 의도적으로 두 번 차단됩니다.

• 단계 0, 스냅 탐색 실행 전: "지금"보다 시작 시간이 이른 새 프로그램은 명확한 오류와 함께 전체 배치를 즉시 거부합니다. 스냅 탐색은 불가능한 입력에 대해 아예 실행되지 않습니다.
• 단계 4, 스냅 탐색 후: 두 가지 다른 하위 사례가 다르게 처리됩니다. 스냅에 의해 실수로 과거로 당겨진 새로운 프로그램(드물지만 요청 시간 클럭 경계에서 가능)은 원래의 스냅 이전 시간으로 조용히 되돌려집니다. 운영자의 의도는 보존되며, 스냅은 단순히 적용되지 않습니다. 이동으로 인해 과거로 밀려나는 기존 프로그램은 전체 배치를 거부합니다. 이미 방송이 시작된 프로그램을 건드리는 것은 시스템이 조용히 흡수하지 않을 것입니다.

5. Lambda 우선, 데이터베이스 후순위 쓰기 계약. 스냅이 MediaLive에 이미 배포된 프로그램을 이동시킬 때, MongoDB와 MediaLive는 일시적으로 동기화되지 않으며, 조정 순서가 중요합니다. 계약은 다음과 같습니다: Lambda 우선, MongoDB 후순위. 백엔드는 프로그램의 원본 시간을 사용하여 Lambda에서 DELETE_PROGRAM을 호출합니다. 호출이 실패하면 데이터베이스 쓰기 전에 백엔드가 오류를 발생시킵니다. 모든 삭제 호출이 성공한 후에만 단일 bulkWrite가 MongoDB를 새 시간으로 업데이트하고 isDeployed: false를 재설정합니다.

이는 깔끔한 불변성을 생성합니다. MongoDB가 프로그램의 새 시간을 표시한다면, MediaLive는 이미 그 이동을 수락한 것입니다. 운영자가 오류를 보는 경우, 두 시스템 모두 변경되지 않은 것입니다. MongoDB와 MediaLive가 프로그램 시간에 대해 조용히 불일치하는 가능한 상태는 없습니다.

6. 초기화 날짜에는 자체적인 안전망이 있습니다. "초기화 날짜"는 특정 캘린더 날짜에 채널의 모든 프로그램을 삭제하는 시스템에서 가장 파괴적인 작업이므로, 두 가지 특정 보호 조치를 포함합니다.

• 2분 버퍼 (SAFETY_BUFFER_MS = 120000)는 다음 2분 이내에 시작하는 모든 프로그램을 제외하여, 라이브 재생에 유예 기간을 제공하므로 초기화 작업이 방송될 프로그램과 절대 충돌하지 않도록 합니다. 
• 이월 프로그램 보존은 전날 시작했지만 오늘까지 이어지는 프로그램을 제외합니다. 이 프로그램들은 오늘의 스케줄이 아닌 어제의 스케줄에 속합니다. 

또한 유연한 대체 방안도 있습니다. 채널이 MediaLive에 전혀 배포된 적이 없다면, Lambda는 백엔드가 이해하는 특정 오류 문자열을 반환하고, 이를 no_infrastructure로 기록한 다음, MongoDB만 사용하는 소프트 삭제를 수행합니다. 초기화는 여전히 성공하며, AWS 단계는 단순히 아무 작업도 하지 않게 됩니다.

이러한 설계 선택의 조합 이유

여전히 주시하고 있는 사항

정직한 엔지니어링은 해결된 문제뿐만 아니라 여전히 남아있는 간극을 명시하는 것을 의미합니다.

• 동일 채널에서 동시 편집. 두 명의 운영자가 수백 밀리초 이내에 동일한 채널에서 배포를 클릭하면, 둘 다 동일한 스냅샷을 로드하고, 둘 다 독립적으로 스냅 탐색을 실행하며, 둘 다 MongoDB에 기록합니다. 현재 채널별 잠금이나 낙관적 버전 확인은 없습니다. 현재 완화책은 운영적인 것으로 — 한 번에 한 명의 운영자가 하나의 채널을 소유하는 것입니다 — 반면 기술적인 수정 사항인 쓰기 시 확인되는 채널 문서의 버전 필드는 로드맵에 있습니다.
• 무엇이 스냅되었는지에 대한 UI 내 피드백 없음. 탐색이 프로그램을 3초 이동시킬 때, 운영자의 뷰는 수정된 상태로 새로 고쳐지지만, 무엇이 이동했고 왜 이동했는지는 아직 표시되지 않습니다. 데이터는 이미 응답 페이로드에 존재하며, 다음 스케줄러 UI 반복에서 토스트, 사이드바 또는 차이점 보기가 계획되어 있습니다.

결과

• 운영자는 타임라인 어디든 프로그램을 드롭할 수 있으며, 시스템은 한 번의 확정적인 패스로 결과 스케줄을 법적으로 유효하게 만듭니다. 충돌 모달, 오류 벽, 수동 스냅 계산이 없습니다.
• 단일 4가지 규칙 알고리즘은 새 프로그램 대 새 프로그램, 새 프로그램 대 기존 프로그램, 그리고 날짜 경계를 넘는 연쇄적 이동 등 모든 경우를 특별 처리 없이 다룹니다.
• 자정을 넘어가는 프로그램과 DST 전환은 다른 모든 경우와 동일한 시간 범위 중복 쿼리를 통해 처리됩니다. 별도의 "자정 코드 경로"를 유지할 필요가 없습니다.
• 초기화 날짜는 실수로 라이브 프로그램을 방송에서 내리지 않습니다. 2분 버퍼와 이월 프로그램 보존은 모든 채널에 항상 적용됩니다.
• Lambda 우선 / 데이터베이스 후순위 계약은 조용한 스케줄 드리프트를 불가능하게 만듭니다. MongoDB와 MediaLive는 동의하도록 보장되며, 그렇지 않으면 운영자는 명시적인 오류를 보게 됩니다.

• MIN_NEIGHBOUR_GAP_MS는 단일 조절 가능한 노브입니다. 모든 안전 여유, 모든 스냅 규칙, 그리고 모든 중복 창이 이를 참조하므로, 플랫폼의 "법적" 정의를 조정하는 것은 한 줄 변경으로 가능합니다.

   

마무리 생각

이 시스템에서 가장 흥미로운 점은 단일 규칙이 아니라, 얼마나 적은 규칙이 필요한지였습니다. 간격 값에 대한 네 가지 조건이 한 번의 순방향 패스에서 적용되어, 자정 경계를 넘는 다단계 연쇄를 포함하여 운영자가 만들 수 있는 모든 충돌을 처리합니다. 이는 의도적인 설계 결과입니다. 복잡성은 끊임없이 증가하는 특별 사례 목록을 처리하는 대신, 규칙을 한 번에 올바르게 만드는 데 집중되었습니다.

더 넓은 교훈은 스케줄링 소프트웨어를 넘어 일반화됩니다. 시스템에 인코더의 최소 간격, 데이터베이스의 일관성 보장, 방송 중단할 수 없는 라이브 방송과 같은 엄격한 외부 제약 조건이 있을 때, 이러한 제약 조건을 적용하는 가장 안전한 방법은 코드베이스 전반에 흩어져 있는 임시 처리가 아니라, 일관되게 적용되는 소수의 확정적 규칙에 있습니다. 그리고 두 기록 시스템(여기서는 MongoDB와 MediaLive)이 동기화 상태를 유지해야 할 때, 실패 시 항상 알려지고 동의된 상태로 남도록 쓰기 순서를 지정하는 것은 추가 지연 시간을 감수할 가치가 있습니다.
 

MicrocosmWorks 소개

MicrocosmWorks는 복잡한 엔지니어링 문제를 해결하는 조직을 위한 프로덕션급 소프트웨어를 구축합니다.

당사의 전문성은 AI 애플리케이션, SaaS 플랫폼, 엔터프라이즈 소프트웨어, 클라우드 네이티브 시스템, 미디어 기술, 그리고 맞춤형 백엔드 아키텍처를 포함합니다.

당사는 엔지니어링 블로그를 통해 실제 프로덕션 시스템을 설계하고 운영하면서 얻은 실용적인 교훈을 공유합니다.

계속 읽기

이 기사가 흥미로웠다면 다음 주제도 유용할 수 있습니다.

• 확장 가능한 SaaS 아키텍처 구축
• 클라우드 네이티브 인프라
• FFmpeg을 이용한 엔터프라이즈 비디오 처리