블로그 목록
시리즈: 실시간 통화, 어떻게 녹화하는가2/6
  1. 1.실시간 통화, 왜 녹화해야 하는가
  2. 2.내 서버에서 직접 녹화한다면 ← 현재 글
  3. 3.Agora 녹화 모드 비교
  4. 4.M3U8과 TS 구조
  5. 5.FFmpeg 미디어 처리
  6. 6.FFmpeg 실전 파이프라인
Backend시리즈8분 읽기

내 서버에서 직접 녹화한다면 — On-Premise vs Cloud Recording

데이터 위치·처리자·보유 방식에 대한 계약이나 규제 요구가 Cloud Recording의 데이터 흐름과 맞지 않을 때 On-Premise Recording을 검토할 수 있습니다. 이 글은 배포 위치, 운영 책임, 후처리 통제 범위를 Cloud 방식과 비교하고 raw-data callback은 사용하는 SDK 버전의 API 계약으로 확인해야 한다는 기준을 제시합니다.

On-Premise RecordingCloud RecordingYUVRaw Data의사결정
목차(19개 항목)
  1. On-Premise Recording이 필요한 순간
    1. 1. 데이터 주권 (Data Sovereignty)
    2. 2. 실시간 Raw 프레임 AI 처리
    3. 3. 커스텀 미디어 처리
  2. On-Premise Recording SDK 아키텍처
  3. Recording Engine 내부: 두 가지 모드
  4. Media callback을 처리 pipeline에 연결하기
  5. 추가 기능
    1. 워터마크
    2. 스크린샷
    3. 암호화 채널 지원
    4. 선택적 녹화
  6. Cloud vs On-Premise 의사결정 프레임워크
    1. 7가지 축 비교
    2. Decision Tree
  7. 핵심 요약
  8. 시리즈 네비게이션
  9. 관련 글
  10. 참고 자료

데이터 위치와 처리 주체를 직접 통제해야 하는 요구가 Cloud Recording의 데이터 흐름과 충돌한다면 On-Premise Recording을 검토할 수 있습니다.

Agora Cloud Recording 결과는 Agora 인프라를 거쳐 설정한 외부 클라우드 스토리지로 전송됩니다. 계약·규제상 데이터 흐름을 허용할 수 없거나, 자체 처리 파이프라인에 media callback을 연결해야 한다면 On-Premise Recording을 비교할 수 있습니다.

On-Premise Recording이 필요한 순간

1. 데이터 주권 (Data Sovereignty)

데이터 위치, 처리자, 보유 기간에 대한 요구는 관할 법률과 계약마다 다릅니다. 특정 배포에서 자체 서버만 허용되는지는 법률·보안 검토로 판단해야 하며, GDPR·HIPAA·PCI-DSS가 일률적으로 같은 저장 위치를 요구한다고 볼 수는 없습니다.

Cloud Recording 흐름 (데이터 주권 문제):

  RTC Channel
      │
      ▼
  Agora 인프라
      │
      ▼
  외부 스토리지 (S3 us-east-1, GCS asia-northeast3...)
                                ↑
                          허용된 데이터 흐름인지 검토

규제 산업에서는 녹화 경로뿐 아니라 접근 통제, 암호화, 삭제 정책, 하위 처리자와 데이터 이전 조건을 함께 검토합니다.

2. 실시간 Raw 프레임 AI 처리

녹화가 끝난 뒤 수행하는 STT라면 저장 파일을 입력으로 사용할 수 있습니다. 실시간 latency나 프레임 단위 분석이 필요하면 별도의 realtime pipeline이 필요합니다.

  • 학습자 집중도 분석 (눈 추적, 시선 방향)
  • 실시간 감정 인식
  • 이상 행동 탐지 (온라인 시험 감독)
  • 얼굴 인식 기반 출결 처리

이런 요구사항은 녹화가 끝난 MP4를 나중에 분석하는 방식으로 latency 목표를 충족하지 못할 수 있습니다. 모델이 지원하는 pixel format으로 디코딩된 프레임을 처리 pipeline에 전달해야 합니다. 얼굴·감정·시험 감독 분석은 개인정보와 자동화된 의사결정 위험도 별도로 검토해야 합니다.

3. 커스텀 미디어 처리

  • 특수 워터마크 (사용자별 고유 마크, 재유통 추적)
  • 실시간 자막 합성 (번역 자막을 영상에 직접 burn-in)
  • 독자적인 코덱/포맷 요구 (표준 MP4 외)

On-Premise Recording SDK 아키텍처

Cloud Recording이 REST API로 동작하는 것과 달리, On-Premise Recording은 자체 서버에 직접 설치하는 Native SDK입니다.

┌─────────────────────────────────────────────────────┐
│            Your Linux Server (자체 관리)              │
│                                                      │
│  ┌──────────────────────────────────────────────┐    │
│  │        On-Premise Recording SDK               │    │
│  │  ┌─────────────┐  ┌──────────────────────┐   │    │
│  │  │ Recording   │  │  Media Processing    │   │    │
│  │  │ Engine      │  │  (믹싱/레이아웃/워터마크) │   │    │
│  │  └──────┬──────┘  └──────────┬───────────┘   │    │
│  │         │                    │                │    │
│  │         └────────┬───────────┘                │    │
│  └─────────────────┼────────────────────────────┘    │
│                    │                                  │
│              로컬 디스크에 MP4 저장                     │
└────────────────────┼─────────────────────────────────┘
                     │ Agora SD-RTN
                     ▼
┌─────────────────────────────────────────────────────┐
│                 RTC Channel                           │
│        (참가자들이 실시간 통화 중)                       │
└─────────────────────────────────────────────────────┘

핵심 차이점 세 가지:

1. 지원 Linux 환경 필요 서버와 운영체제는 직접 운영합니다. 지원 배포판과 버전은 설치하는 On-Premise Recording SDK 릴리스 문서를 기준으로 확인해야 합니다.

2. Native SDK 설치 REST API 호출이 아닙니다. C++ 기반 SDK를 서버에 직접 설치하고, 애플리케이션 코드에서 SDK를 호출합니다.

3. 파일이 로컬 디스크에 저장 MP4가 외부 스토리지로 나가지 않습니다. 서버 디스크에 직접 씁니다. 이후 내부 스토리지로의 이동은 자체 파이프라인으로 처리.

Recording Engine 내부: 두 가지 모드

모드출력설명
Individual recording유저별 별도 파일참가자 A, 참가자 B의 오디오/비디오를 UID별로 분리 저장
Composite recording합쳐진 단일 파일모든 스트림이 믹싱된 하나의 파일

Agora 공식 문서의 On-Premise Recording 모드 명칭은 Individual recording과 Composite recording입니다. Cloud Recording의 Individual/Composite와 출력 개념은 유사하지만, 배포·API·기능·운영 책임까지 동일한 것은 아닙니다.

Composite 모드에서는 레이아웃 설정이 가능합니다. 누가 어느 위치에 표시될지, 화면 크기 비율을 어떻게 할지 SDK 설정으로 제어합니다.

Raw-data callback과 지원 format은 SDK 버전별 API 계약을 기준으로 확인해야 합니다. 현재 공개된 현행 문서에서 모드별 raw-data 지원 범위를 확인할 수 없으므로 이 글에서는 Individual/Composite 지원표를 단정하지 않습니다.

Media callback을 처리 pipeline에 연결하기

On-Premise 배포를 검토하는 이유 중 하나는 녹화 애플리케이션과 자체 media processing pipeline을 같은 운영 경계에서 연결할 수 있다는 점입니다.

정확한 callback type과 pixel/sample format은 사용하는 SDK API reference를 따라야 합니다. 개념적인 연결 구조는 다음과 같습니다.

RTC Channel → On-Premise SDK → YUV Frame Callback → AI Pipeline
                                       │
                                       ├─ 영상 분석 모델
                                       │
                                       ├─ 콘텐츠 분류
                                       │
                                       └─ 이상 행동 탐지
                                           (시험 감독 솔루션)

callback 주기는 end-to-end latency를 보장하지 않습니다. decode, queue, inference, 후처리 시간을 포함해 부하 테스트하고, callback thread를 block하지 않도록 worker queue와 backpressure를 설계해야 합니다.

PCM 접근도 마찬가지입니다. 서드파티 STT가 아닌 자체 음성 분석 모델을 실시간으로 돌릴 수 있습니다.

추가 기능

워터마크

워터마크·배경 이미지·레이아웃 지원 범위는 사용하는 SDK 버전의 Composite recording API를 확인합니다. 아래 그림은 가능한 구성의 개념 예시입니다.

┌────────────────────────────────────┐
│  [타임스탬프: 2025-03-26 14:32:01]  │  ← 텍스트 워터마크
│                                    │
│     [상담 ID: TXN-89234]           │  ← 커스텀 텍스트
│                                    │
│                       [logo.png]   │  ← 이미지 워터마크
└────────────────────────────────────┘

사용자별 식별 정보를 영상에 넣을 경우 개인정보 노출과 재식별 위험을 검토해야 합니다.

스크린샷

라이브 스트림에서 JPG를 지정 간격으로 뽑습니다. 썸네일 생성, 콘텐츠 모더레이션 용도.

암호화 채널 지원

Recorder가 암호화된 media를 처리하려면 복호화 capability와 key가 필요합니다. client만 key를 보유하는 E2EE 모델은 Cloud와 On-Premise recorder 모두 media를 해독할 수 없습니다. On-Premise recorder에 key를 전달하면 녹화는 가능해질 수 있지만, 그 순간 recorder가 새로운 trusted endpoint가 되어 기존 E2EE trust boundary가 바뀝니다.

선택적 녹화

채널에 20명이 있어도 특정 UID만 골라서 녹화할 수 있습니다. 강의 플랫폼에서 강사 화면만 녹화하거나, 주요 참가자만 선택하는 식.

Cloud vs On-Premise 의사결정 프레임워크

7가지 축 비교

항목Cloud RecordingOn-Premise Recording
인프라Agora 관리 (서버리스)자체 Linux 서버 운영
인터페이스REST APINative SDK (C++)
저장 위치3rd-party 클라우드 스토리지로컬 디스크
모드individual / mix / webIndividual / Composite
Raw 데이터 접근XO (YUV, JPG, PCM)
운영 부담낮음높음 (서버 관리 필요)
비용 구조Cloud Recording 사용량·저장소 비용SDK 계약·서버·저장소·운영 비용

Decision Tree

                    녹화가 필요한가?
                         │
                    ┌────┴────┐
                   Yes        No → 끝
                    │
           데이터가 반드시
           자체 서버에 있어야?
           (규제/데이터 주권)
                    │
              ┌─────┴─────┐
             Yes           No
              │             │
         On-Premise    실시간 Raw 프레임
                       AI 처리 필요?
                            │
                      ┌─────┴─────┐
                     Yes           No
                      │             │
                 On-Premise    Cloud Recording

대부분의 경우 Cloud Recording으로 충분합니다. On-Premise는 명확한 요구사항이 있을 때만 선택합니다 — 운영 부담이 크기 때문입니다.

서버 관리, SDK 버전 업데이트, 디스크 용량 관리, 장애 대응 — 이 모든 것이 자체 책임입니다. "쉬운 것을 어렵게 하지 않는다"는 원칙 하에, Cloud로 충분한 요구사항에는 Cloud를 씁니다.

핵심 요약

  • On-Premise Recording은 Native SDK를 자체 Linux 서버에 설치하는 방식. REST API 기반의 Cloud Recording과 구조적으로 다름
  • 파일은 로컬 디스크에 직접 저장 — 외부 스토리지 불필요, 데이터 주권 요구 충족 가능
  • media callback 지원 범위는 SDK 버전별 확인 — callback을 자체 분석 pipeline과 연결할 때 latency와 backpressure를 측정
  • 암호화 녹화는 trust boundary 변경을 수반 — recorder가 복호화 key를 받으면 client-only E2EE 모델이 아님
  • 운영 부담이 크므로 데이터 주권 또는 실시간 Raw 처리가 명확히 필요할 때만 선택

시리즈 네비게이션

실시간 통화, 어떻게 녹화하는가 시리즈

  1. 실시간 통화, 왜 녹화해야 하는가 — Cloud Recording Architecture
  2. 내 서버에서 직접 녹화한다면 ← 현재 글
  3. Agora 녹화 모드 비교 — Individual, Composite, Web page
  4. M3U8과 TS 구조 — HLS 녹화 파일 읽기
  5. FFmpeg 미디어 처리 — 컨테이너, 코덱, 스트림
  6. FFmpeg 실전 파이프라인 — Agora 녹화에서 프로덕션 VOD까지

관련 글

참고 자료

공식 문서

https://docs.agora.io/en/realtime-media/on-premise-recording

© 2026 Frank Kim. All rights reserved.