[MCU 딥다이브] MCU는 왜 비싸지만 여전히 필요한가

MCU는 요즘 SFU보다 덜 자주 들린다. 그래서 처음에는 낡은 방식 정도로 생각했다. 그런데 녹화, 방송, 고정 레이아웃, 저성능 단말 지원을 떠올리면 MCU를 그렇게 쉽게 버릴 수 없다. SFU는 미디어를 열어 보지 않고 필요한 곳으로 전달하는 데 가깝고, MCU는 서버가 미디어를 디코딩하고 섞고 다시 인코딩한다. 비싸지만 그만큼 서버가 결과물을 책임질 수 있다. 비싸지만만 있으면 나머지는 따라올 거라고 믿었다.

MCU가 필요해진 지점

그래서 MCU를 제품에 넣을 때는 기본 경로와 부가 경로를 분리하는 편이 안전하다. 실시간 대화는 SFU로 낮은 지연을 유지하고, 녹화나 방송, 요약용 결과물은 MCU 성격의 별도 pipeline에서 처리할 수 있다. 사용자가 지금 말하고 듣는 경로와 나중에 저장되는 결과물 경로가 같을 필요는 없다. 오히려 같게 만들려고 하면 지연과 비용 요구가 서로 충돌한다.

예를 들어 10명 회의를 녹화한다고 해 보자. 각 클라이언트가 자기 화면에서 보이는 레이아웃을 따로 녹화하면 결과가 제각각이다. 누구 화면을 크게 둘지, 발화자를 어떻게 표시할지, 공유 화면과 카메라를 어떻게 배치할지 통일하기 어렵다. 서버에서 원본 스트림을 받아 하나의 레이아웃으로 합성하면 저장되는 결과는 예측 가능해진다.

이때 MCU 성격의 처리가 필요하다. 짧게 말하면 MCU는 SFU의 하위 호환이 아니다. 비용이 크고 지연이 생기지만, 녹화·방송·합성·저성능 수신자 지원에서는 여전히 필요하다. SFU가 실시간 전달을 잘 맡는다면 MCU는 결과물 생성을 잘 맡는다. 두 방식을 경쟁 관계로 놓기보다, 어떤 기능에서 미디어를 열어 보고 다시 만들어야 하는지 묻는 편이 낫다. 방송도 비슷하다.

시청자가 많고 수신 기기의 성능이 낮을 수 있다면, 각 시청자에게 여러 스트림을 직접 조합하게 하는 것보다 서버가 완성된 결과를 만들어 보내는 편이 안정적일 수 있다. 물론 이 선택은 공짜가 아니다. 서버가 모든 것을 열어 보고 다시 포장하기 때문에 지연과 비용이 올라간다. 실시간 대화에서는 몇백 밀리초가 크게 느껴질 수 있으니, 기본 통화 경로에 MCU를 무조건 넣는 것은 위험하다.

현재 구성의 가정

*MCU를 볼 때는 “편한 수신 경험”과 “비싼 서버 처리”를 항상 같이 적어야 한다. 합성 정책의 버전 관리도 필요하다. 오늘 만든 녹화와 다음 달 만든 녹화가 다른 레이아웃 규칙을 쓸 수 있다. 나중에 사용자가 “이 파일은 왜 이렇게 보이나요”라고 물으면 어떤 정책 버전으로 처리됐는지 알아야 한다. 코드 배포 이력만으로는 부족하다. job metadata에 입력 스트림, 레이아웃 정책, 인코딩 설정, 처리 시각을 남기면 문제가 생겼을 때 다시 재현하기 쉽다.

MCU 실패는 CPU 부족만이 아니다. 지연, 화질 열화, 원본 보존 실패, 합성 정책 오류가 같이 온다. 특히 MCU에서는 재현 조건을 같이 적어야 의미가 있었다. MCU 점검은 “쓸 것인가”보다 “어떤 결과물을 서버가 책임질 것인가”에 가깝다. 특히 MCU에서는 재현 조건을 같이 적어야 의미가 있었다. 보안과 개인정보도 MCU에서 더 무거워진다. 서버가 미디어를 열어 보고 처리한다는 것은 접근 권한과 저장 정책이 더 민감해진다는 뜻이다.

상담, 교육, 회의 기록처럼 민감한 내용이 들어갈 수 있다면 누가 원본을 볼 수 있는지, 처리 작업 로그에 어떤 메타데이터가 남는지, 실패한 job의 임시 파일을 언제 지우는지 정해야 한다. 단순 미디어 전달보다 책임이 크다.

가정을 깨는 사례

MCU를 더 깊게 보면 비용의 모양이 SFU와 전혀 다르다. SFU는 되도록 미디어를 열어 보지 않고 패킷을 전달한다. MCU는 열어 본다. 디코딩하고, 오디오를 섞고, 레이아웃을 만들고, 다시 인코딩한다. 이 단계마다 실패와 지연이 생긴다. 그래서 MCU는 “서버가 좀 더 일한다” 정도가 아니라, 서버가 미디어 제작 공정 일부를 맡는 구조라고 보는 편이 맞다. MCU를 설명할 때 transcoding을 빼놓으면 반쪽이 된다.

입력 코덱과 출력 코덱이 다르거나, 저장 포맷이 별도로 필요하거나, 외부 플랫폼에 맞춰 bitrate ladder를 만들어야 할 때 서버가 다시 인코딩한다. 이 과정은 계산 비용이 크고 품질 손실도 생긴다. 그래도 배포 대상이 다양하면 피하기 어렵다. 실시간 회의용 스트림과 다운로드용 파일, 방송 플랫폼용 스트림은 서로 다른 요구를 가진다. PonsLink에서 세션 기록이나 PonsCast 같은 결과물을 제공한다면 MCU 성격의 처리가 등장할 수 있다.

상담 중 실시간으로 보는 화면은 지연이 중요하지만, 나중에 공유되는 기록은 레이아웃과 안정성이 중요하다. PonsWarp와는 직접 다른 영역이지만, 원본을 어떻게 보존하고 실패 후 어떻게 복구할지라는 질문은 닮았다. payload를 서버가 소유하는 순간 제품의 책임도 달라진다. 그래서 MCU를 제품에 넣는 결정은 기능 추가라기보다 미디어 생산 라인을 만드는 일에 가깝다.

실시간 전달만 하던 시스템에 저장, 재처리, 검수, 비용 정산, 접근 제어가 붙는다. 그 무게를 감당할 수 있을 때 MCU는 아주 유용하다. 녹화와 방송, 저성능 단말 지원처럼 결과물이 중요한 기능에서는 비싼 값을 한다. 다만 그 값을 낼 이유가 분명해야 한다. 지연 목표도 기능마다 다르다. 실시간 통화에 들어간 MCU는 지연을 아주 작게 유지해야 한다.

반면 녹화 후처리는 몇 초나 몇 분이 걸려도 괜찮을 수 있다. 이 둘을 같은 pipeline으로 만들면 어느 쪽에도 애매해진다. 실시간 합성은 빠르지만 가볍게, 사후 합성은 느리더라도 품질과 복구 가능성을 더 챙기는 식으로 나눠야 한다. “MCU를 쓴다”는 말만으로는 이 차이가 보이지 않는다. MCU를 실시간 경로에 넣는 경우에는 더 엄격한 기준이 필요하다.

합성 지연이 조금만 커져도 대화가 어색해진다. CPU가 순간적으로 튀면 모든 수신자에게 같은 지연이 전파된다. SFU에서는 특정 수신자만 낮은 품질을 받을 수 있지만, MCU에서는 합성 결과가 하나라 전체가 영향을 받는다. 이 특성 때문에 실시간 MCU는 정말 필요한 경우에만 좁게 쓰는 편이 낫다. MCU를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

분리·중계·직접연결 선택

그래도 MCU가 주는 장점은 분명하다. 약한 기기에서도 하나의 스트림만 디코딩하면 되고, 결과물이 일정하며, 방송이나 녹화 후처리와 잘 맞는다. 기술 선택을 할 때 비용만 보면 비싸 보이지만, 클라이언트 복잡도와 결과물 검수 비용을 줄여 주는 면도 있다. 그래서 중요한 것은 MCU를 피하는 것이 아니라, 어디에 쓰면 값어치를 하는지 정확히 고르는 일이다.

작게 시작한다면 MCU를 모든 방의 기본값으로 두기보다 결과물이 필요한 기능에만 붙이는 편이 좋다. 예를 들어 실시간 참여는 SFU로 두고, 사용자가 녹화를 켠 세션만 별도 처리한다. 그렇게 하면 비용과 장애 범위를 설명하기 쉽다. 나중에 방송이나 자동 요약이 붙더라도 어느 pipeline에서 무게가 늘어나는지 추적할 수 있다. MCU는 강한 도구지만 기본 경로에 무심코 넣기에는 너무 무겁다.

이런 기준을 세워 두면 기능 요청이 들어왔을 때도 판단이 빨라진다. “녹화도 실시간처럼 바로 보여 주세요”라는 요구가 오면 지연과 비용의 대가를 설명할 수 있고, “원본은 저장하지 말아 주세요”라는 요구가 오면 재처리 불가라는 제한을 함께 말할 수 있다. MCU는 기술보다 약속 관리가 먼저다. 또, 처리 결과를 신뢰하려면 샘플 파일만 보지 말고 실패한 job의 재처리 기록까지 확인해야 한다.

성공한 결과물보다 실패 뒤에 남는 흔적이 운영 품질을 더 잘 보여 준다. 개발 단계에서는 작은 샘플 하나로 합성 성공을 확인하기 쉽다. 운영에서는 긴 세션, 화면 공유 전환, 중간 입장과 퇴장, 음소거, 네트워크 흔들림이 모두 합성 결과에 영향을 준다. MCU는 결과물이 남는 기능에 자주 쓰이므로, 실시간 화면보다 사후 검수가 더 중요해질 때도 있다.

자막이나 음성 인식이 붙으면 MCU pipeline은 더 넓어진다. 오디오를 따로 추출하고, 화자 정보를 맞추고, 결과 영상에 자막을 입힐 수 있다. 이때 미디어 처리와 데이터 처리의 경계가 흐려진다. 화자 분리 결과가 틀리면 자막 위치나 이름이 틀리고, 타임스탬프가 밀리면 영상과 자막이 어긋난다. 녹화 결과물의 품질은 영상 합성만으로 결정되지 않는다.

다시 짜 본 구조

영상 레이아웃도 단순한 격자 배치가 아니다. 발표자 모드, 화면 공유 모드, 질문자 강조, 카메라 꺼짐, 중간 입장과 퇴장이 모두 레이아웃을 바꾼다. 서버가 결과물을 책임진다면 이 변화를 시간축에 맞춰 기록해야 한다. 녹화 파일을 다시 재생했을 때 누가 말했는지, 언제 화면 공유가 켜졌는지, 빈 자리가 어떻게 처리됐는지가 자연스러워야 한다.

MCU는 미디어 처리와 UI 상태가 만나는 지점이기도 하다. MCU의 실패는 조용히 오지 않는다. 서버 CPU가 부족하면 합성 지연이 길어지고, 인코딩 큐가 밀리면 녹화가 늦게 나오거나 품질이 떨어진다. 합성 pipeline이 장애를 만나면 원본을 보존했는지 여부가 중요해진다. 원본 스트림이 남아 있으면 나중에 다시 처리할 수 있지만, 합성 결과만 믿고 있었다면 복구가 어렵다.

이 지점에서 MCU는 단순한 실시간 기능이 아니라 데이터 보존 정책과도 연결된다. SFU가 교차로라면 MCU는 편집실에 가깝다. 들어온 영상과 소리를 열어 보고, 배치하고, 필요한 크기와 포맷으로 다시 만든다. 이 과정에는 CPU나 GPU가 든다. 지연도 생긴다. 화질 손실도 생길 수 있다. 대신 수신자는 단순한 하나의 결과물을 받는다. 저성능 기기나 녹화 파일처럼 “누가 봐도 같은 결과”가 필요한 장면에서는 이 단순함이 큰 장점이 된다.

realtime-network-13-wh MCU를 운영에 올리면 queue 설계가 중요해진다. 모든 합성 작업을 즉시 처리할 수 있으면 좋지만 현실에서는 피크 시간이 있다. 수업이 끝나는 시간, 회의가 몰리는 시간, 방송 종료 직후에는 녹화 job이 한꺼번에 쌓일 수 있다. 이때 사용자에게 예상 시간을 보여 줄지, 우선순위를 어떻게 줄지, 실패한 job을 몇 번 재시도할지 정해야 한다. 단순히 worker를 늘리는 문제로만 보면 비용이 금방 커진다.

내가 세울 기준은 네 가지다. 녹화와 실시간 경로를 분리한다. 서버 인코딩 비용을 미리 계산한다. 원본 스트림을 보존할지 결정한다. 저성능 단말을 어느 수준까지 지원할지 정한다. 이 기준은 구현보다 먼저 필요하다. 코드가 돌아간 뒤에야 비용을 보면 이미 기능 약속이 굳어져서 바꾸기 어렵다. 특히 MCU에서는 재현 조건을 같이 적어야 의미가 있었다.

'[MCU 딥다이브 MCU는 왜 비싸지만 여전히 필요한가'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

마치며

이 글에서 확인한 경계는 다음 변경의 기준으로 남겼다.