음성 통화 서버는 어떻게 구축해야 할까?

최근 음성 통화 기능이 필요한 서비스를 검토할 일이 있었다.

처음에는 단순하게 생각했다.

클라이언트에서 마이크 데이터를 받아 서버로 보내고, 서버가 같은 방에 있는 사용자들에게 전달해 주면 되는 것 아닐까?

채팅 서버를 만들 때처럼 WebSocket 연결을 열고, 음성 데이터를 바이너리로 주고받으면 얼추 구현은 가능해 보인다.

하지만 음성 통화에서 중요한 건 단순히 데이터를 전달하는 것이 아니다.

네트워크가 조금 불안정해도 음성이 자연스럽게 들려야 하고, 패킷 일부가 유실되더라도 통화가 끊기지 않아야 한다. 에코와 주변 소음도 제거해야 하고, 사용자의 방화벽이나 공유기 환경도 고려해야 한다.

결국 음성 통화는 단순한 실시간 메시징의 문제가 아니라, 실시간 미디어 전송의 문제다.

그래서 오늘은 백엔드 개발자의 관점에서 음성 통화 서버를 구축하려면 어떤 기술이 필요한지 정리해 보려 한다.

WebSocket으로 만들면 안 될까?

음성 데이터를 WebSocket으로 전송하는 것 자체는 가능하다.

클라이언트가 마이크 데이터를 작은 단위로 잘라 서버에 전송하고, 서버가 이를 다른 사용자들에게 전달하면 된다.

대충 다음과 같은 구조다.

사용자 A → WebSocket 서버 → 사용자 B

1:1 통화 정도라면 간단한 프로토타입도 만들 수 있다.

하지만 실제 통화 기능으로 사용하려 하면 여러 문제가 생긴다.

음성 통신은 데이터가 정확하게 도착하는 것보다 빠르게 도착하는 것이 중요하다. 1초 전에 말한 음성이 완벽하게 도착하는 것보다, 일부가 유실되더라도 지금 말하는 음성이 바로 들리는 편이 낫다.

일반적인 WebSocket은 TCP 위에서 동작한다. TCP는 패킷이 유실되면 해당 패킷을 다시 전송하고, 순서가 맞을 때까지 이후 데이터를 대기시킨다.

파일 전송이나 채팅에서는 좋은 특성이지만, 실시간 통화에서는 오히려 지연을 발생시킬 수 있다.

이 외에도 직접 구현해야 하는 것이 많다.

• 음성 데이터 압축
• 지연 및 지터 처리
• 패킷 유실 보정
• 에코 제거
• 노이즈 억제
• 네트워크 상태에 따른 전송량 조절
• NAT와 방화벽 처리
• 미디어 암호화
• 오디오 장치 변경 처리

결국 WebSocket으로 음성 통화를 구현한다는 것은 통화에 필요한 기능을 대부분 직접 만들어야 한다는 뜻이다.

그리고 이 문제를 해결하기 위해 사용하는 기술이 WebRTC다.

WebRTC

WebRTC는 음성, 영상, 화면 공유와 같은 실시간 미디어 데이터를 전송하기 위한 기술이다.

이름에 Web이 들어가지만 브라우저에서만 사용하는 기술은 아니다. 모바일 앱이나 데스크톱 앱에서도 WebRTC 라이브러리를 이용할 수 있다.

WebRTC는 단순히 마이크 데이터를 네트워크로 보내는 것보다 훨씬 많은 일을 처리한다.

• 음성 및 영상 인코딩
• 미디어 암호화
• 네트워크 경로 탐색
• 패킷 유실 대응
• 지터 버퍼
• 네트워크 혼잡 제어
• 에코 제거
• 노이즈 억제
• 자동 음량 조절

음성 코덱으로는 일반적으로 Opus가 사용된다.

Opus는 음성 품질이 좋으면서도 지연이 낮고, 네트워크 상태에 따라 비트레이트를 유연하게 조절할 수 있다.

즉, 직접 오디오 스트리밍 프로토콜을 설계하기보다는 WebRTC를 사용하는 것이 일반적인 선택이다.

다만 WebRTC를 사용한다고 해서 서버가 필요 없는 것은 아니다.

여기서부터 조금 복잡해진다.

Signaling

WebRTC는 음성 데이터를 어떻게 전송할지는 정의하지만, 통화를 시작하기 위해 사용자들이 어떻게 서로를 찾고 연결 정보를 교환할지는 정해주지 않는다.

이 연결 준비 과정을 Signaling이라고 한다.

통화를 시작하려면 참가자끼리 다음과 같은 정보를 교환해야 한다.

• 어떤 음성 및 영상 코덱을 지원하는지
• 마이크와 카메라를 사용할 것인지
• 어떤 네트워크 주소로 연결할 수 있는지
• 누가 통화를 요청했고 누가 수락했는지
• 어떤 통화방에 참여할 것인지

이 정보는 WebSocket, HTTP, STOMP 등 원하는 방식으로 전달할 수 있다.

Spring Boot를 사용한다면 다음과 같은 역할을 담당할 수 있다.

• 사용자 인증
• 통화방 생성
• 통화방 입장 권한 확인
• 참가자 상태 관리
• WebSocket을 통한 연결 정보 전달
• 통화 시작 및 종료 기록

여기서 중요한 점은 Signaling 서버가 일반적으로 음성 데이터를 직접 전달하는 서버는 아니라는 것이다.

Signaling 서버는 연결에 필요한 정보를 교환해 줄 뿐이고, 실제 음성 데이터는 WebRTC 연결을 통해 별도로 전송된다.

P2P

가장 단순한 WebRTC 구조는 P2P 방식이다.

사용자 A ↔ 사용자 B

서버는 두 사용자가 연결될 수 있도록 정보만 교환해 주고, 연결이 완료된 뒤에는 음성이 사용자 사이에서 직접 전달된다.

1:1 통화에서는 꽤 괜찮은 구조다.

서버가 음성 데이터를 중계하지 않으니 서버의 네트워크 비용도 적게 들고, 사용자 간 거리가 가깝다면 지연 시간도 낮을 수 있다.

하지만 다자간 통화가 되면 문제가 생긴다.

예를 들어 5명이 통화한다면 각 사용자는 자신의 음성을 나머지 4명에게 각각 전송해야 한다.

참가자가 늘어날수록 연결 수도 급격히 증가한다.

참가자가 N명이라면 전체 연결 수는 대략 다음과 같이 늘어난다.

N × (N - 1) / 2

5명이라면 10개, 10명이라면 45개의 연결이 필요하다.

음성만 사용한다면 어느 정도 버틸 수 있을지도 모른다. 하지만 영상이나 화면 공유까지 포함되면 클라이언트의 업로드 대역폭과 CPU 사용량이 빠르게 증가한다.

그래서 다자간 통화에서는 보통 미디어 서버를 사용한다.

SFU

SFU는 Selective Forwarding Unit의 약자다.

이름만 보면 어려워 보이지만 하는 일은 비교적 단순하다.

각 사용자가 자신의 음성이나 영상을 SFU에 한 번 전송하면, SFU가 해당 스트림을 다른 참가자들에게 전달한다.

사용자 A → SFU → 사용자 B, C, D

P2P 방식에서는 사용자 A가 B, C, D에게 데이터를 각각 전송해야 한다.

SFU 방식에서는 SFU에 한 번만 전송하면 된다.

덕분에 사용자의 업로드 부담을 줄일 수 있고, 참가자가 늘어나더라도 클라이언트의 연결 구조가 비교적 단순하게 유지된다.

SFU의 Selective는 모든 데이터를 무조건 전달하는 것이 아니라, 필요한 스트림을 선택해서 전달할 수 있다는 의미다.

화상 통화를 예로 들면 다음과 같은 처리가 가능하다.

• 현재 화면에 보이는 참가자의 영상만 전달
• 작은 썸네일은 저화질 영상으로 전달
• 현재 발표자는 고화질 영상으로 전달
• 카메라를 끈 사용자는 음성만 전달
• 네트워크가 좋지 않은 사용자는 낮은 화질로 전달

음성 통화에서도 현재 발화자 감지, 참가자별 음량 제어, 음소거 상태 관리 등을 처리하기 쉬워진다.

결국 디스코드나 줌처럼 여러 사람이 참여하는 통화 기능을 만들려면 SFU 기반 구조를 우선적으로 고려하게 된다.

MCU와는 뭐가 다를까?

미디어 서버에는 SFU 외에도 MCU라는 방식이 있다.

MCU는 Multipoint Control Unit의 약자로, 여러 참가자의 음성과 영상을 서버에서 하나로 합친 뒤 사용자에게 전달한다.

SFU가 각각의 스트림을 그대로 전달한다면, MCU는 서버에서 스트림을 합성한다.

예를 들어 4명의 영상 통화라면 MCU는 4개의 영상을 하나의 화면으로 합쳐 하나의 영상으로 전달할 수 있다.

클라이언트 입장에서는 하나의 스트림만 받으면 되기 때문에 부담이 줄어든다.

하지만 서버가 모든 영상을 디코딩하고, 합성하고, 다시 인코딩해야 하므로 서버 비용이 크다. 화질이나 화면 배치를 사용자마다 다르게 제공하기도 어렵다.

반면 SFU는 미디어를 대부분 그대로 전달하기 때문에 서버의 연산 부담이 상대적으로 낮고, 참가자별로 다른 화질이나 화면 구성을 제공하기 쉽다.

최근의 일반적인 음성·화상 통화 서비스에서는 SFU 구조를 많이 사용한다.

STUN과 TURN

WebRTC에서 가장 낯선 부분 중 하나가 STUN과 TURN이다.

사용자들은 대부분 공유기나 회사 네트워크 안에 있다.

컴퓨터에서 확인할 수 있는 IP는 보통 다음과 같은 사설 IP다.

192.168.0.10

이 주소는 같은 내부 네트워크에서는 사용할 수 있지만, 외부 인터넷에서는 직접 접근할 수 없다.

WebRTC는 상대방과 통신하기 위해 외부에서 접근 가능한 주소와 포트를 알아내야 한다.

이때 사용하는 것이 STUN이다.

STUN

STUN 서버는 클라이언트가 외부 인터넷에서 어떤 IP와 포트로 보이는지 알려준다.

클라이언트는 STUN 서버에 요청을 보내고, 응답을 통해 자신의 외부 주소를 확인한다.

이 주소를 상대방과 교환하면 직접 연결을 시도할 수 있다.

하지만 모든 환경에서 직접 연결이 가능한 것은 아니다.

회사 방화벽이나 통신사 네트워크 정책에 따라 UDP 통신이 차단될 수도 있고, NAT 구조 때문에 외부 연결이 불가능할 수도 있다.

이때 TURN이 필요하다.

TURN

TURN 서버는 사용자 간 직접 연결이 실패했을 때 음성이나 영상 데이터를 대신 중계한다.

사용자 A → TURN 서버 → 사용자 B

TURN을 사용하면 직접 연결이 어려운 환경에서도 통화할 수 있다.

대신 모든 미디어 트래픽이 TURN 서버를 거치기 때문에 네트워크 비용이 많이 발생한다.

그렇다고 TURN을 빼기도 어렵다.

개발 환경이나 가정용 네트워크에서는 통화가 잘 되는데, 회사나 학교에서 갑자기 통화가 안 되는 상황이 생길 수 있기 때문이다.

상용 통화 서비스를 만든다면 TURN은 선택 사항이라기보다는 필수에 가깝다.

직접 구축할 경우에는 일반적으로 coturn을 사용한다.

ICE

STUN과 TURN을 찾아보다 보면 ICE라는 용어도 함께 등장한다.

ICE는 Interactive Connectivity Establishment의 약자다.

클라이언트가 사용할 수 있는 여러 네트워크 경로를 수집하고, 그중 실제로 연결 가능한 경로를 선택하는 과정이다.

대략 다음 순서로 이해하면 된다.

1. 내부 네트워크 주소로 직접 연결을 시도한다.
2. STUN을 통해 확인한 외부 주소로 연결을 시도한다.
3. 직접 연결이 불가능하면 TURN 서버를 사용한다.

WebRTC는 이 후보들을 수집하고 상대방과 교환한 뒤, 실제 통신 가능한 경로를 찾는다.

즉, STUN과 TURN이 서버라면 ICE는 어떤 경로를 사용할지 결정하는 과정에 가깝다.

Spring Boot 서버는 무슨 일을 해야 할까?

여기까지 보면 통화 기능의 대부분을 WebRTC와 SFU가 처리하는 것처럼 보인다.

그럼 Spring Boot 서버는 필요 없는 걸까?

당연히 그렇지는 않다.

WebRTC와 SFU는 미디어 전달을 담당하지만, 서비스의 비즈니스 규칙까지 알고 있지는 않다.

예를 들어 다음과 같은 판단은 애플리케이션 서버가 해야 한다.

• 이 사용자가 통화방에 들어갈 권한이 있는가?
• 최대 참가자 수를 초과하지 않았는가?
• 차단되거나 정지된 사용자가 아닌가?
• 누가 방장이고 관리자인가?
• 누가 다른 사용자를 음소거할 수 있는가?
• 통화 기록을 저장해야 하는가?
• 유료 사용자만 화면 공유를 사용할 수 있는가?

따라서 전체 역할은 다음과 같이 구분할 수 있다.

Spring Boot

• 회원가입 및 로그인
• 사용자 인증 및 권한 확인
• 통화방 생성 및 삭제
• 참가자 입장 권한 확인
• RTC 접속 토큰 발급
• 통화 시작 및 종료 기록
• 관리자 기능
• Webhook 이벤트 처리

SFU

• 음성 스트림 수신
• 다른 참가자에게 스트림 전달
• 참가자별 스트림 구독
• 네트워크 품질에 따른 전송 조절
• 현재 발화자 감지
• 녹화 및 방송 서버 연동

TURN

• 직접 연결이 불가능한 사용자의 미디어 중계

Spring Boot가 통화 서비스를 관리하고, SFU와 TURN이 미디어를 처리한다고 이해하면 된다.

통화방 입장 과정

실제 서비스에서는 대략 다음과 같은 흐름으로 동작한다.

1. 사용자가 Spring Boot 서버에 로그인한다.
2. 사용자가 특정 통화방에 입장을 요청한다.
3. Spring Boot가 사용자의 권한을 확인한다.
4. Spring Boot가 짧은 유효기간의 RTC 접속 토큰을 발급한다.
5. 클라이언트가 해당 토큰으로 SFU에 연결한다.
6. 클라이언트가 마이크 스트림을 SFU에 전송한다.
7. SFU가 같은 방의 다른 참가자에게 음성을 전달한다.
8. 입장과 퇴장 이벤트는 Webhook 등을 통해 Spring Boot에 전달된다.
9. Spring Boot가 통화 기록이나 현재 참가자 상태를 갱신한다.

여기서 SFU의 API Secret을 클라이언트에 직접 넣으면 안 된다.

클라이언트에 Secret이 포함되면 사용자가 임의의 통화방에 접속하거나 관리자 권한을 가진 토큰을 직접 만들 수 있다.

반드시 Spring Boot 서버가 사용자의 권한을 확인한 뒤 제한된 권한과 만료 시간을 가진 토큰을 발급해야 한다.

어떤 SFU를 사용해야 할까?

SFU를 직접 처음부터 개발하는 것은 현실적으로 어렵다.

WebRTC, RTP, RTCP, 코덱, 네트워크 혼잡 제어 등 알아야 할 것이 너무 많다.

대부분의 경우 기존 SFU 솔루션을 검토하게 된다.

LiveKit

LiveKit은 SFU뿐 아니라 통화 서비스에 필요한 기능을 비교적 완성된 형태로 제공한다.

• 통화방 관리
• 참가자 관리
• Signaling
• 접속 토큰
• 녹화
• 방송 송출
• Webhook
• 클라이언트 SDK

직접 호스팅할 수도 있고, 관리형 클라우드 서비스를 이용할 수도 있다.

백엔드 개발자 입장에서는 Spring Boot에서 통화방 접속 토큰을 발급하고, LiveKit의 이벤트를 Webhook으로 받아 처리하는 방식으로 연동할 수 있다.

통화 기능을 처음 검토한다면 비교적 접근하기 쉬운 선택지다.

mediasoup

mediasoup은 LiveKit보다 낮은 수준의 SFU 기능을 제공한다.

그만큼 자유도가 높지만 직접 구현해야 하는 부분도 많다.

• 통화방 관리
• Signaling
• 인증
• 참가자 상태
• Producer와 Consumer 관리
• 재접속 처리
• 클라이언트 연동 프로토콜

서비스에 특화된 미디어 동작이 필요하거나 RTC가 핵심 기술이라면 적합할 수 있다.

하지만 단순히 음성 통화 기능이 필요해서 시작하는 단계라면 구현 부담이 클 수 있다.

관리형 RTC

Agora, Twilio, Daily 같은 관리형 RTC 서비스를 사용하는 방법도 있다.

이 경우 SFU와 TURN 서버를 직접 운영하지 않아도 된다.

개발 속도가 빠르고 운영 부담이 적지만, 사용량에 따라 비용이 증가하고 특정 서비스에 종속될 수 있다.

초기 PoC나 MVP에서는 관리형 서비스를 사용하고, 사용량과 요구사항이 명확해진 뒤 셀프 호스팅을 검토하는 것도 방법이다.

구현에 주의할 점

SFU를 설치하고 연결만 하면 음성 통화 서버가 완성된다고 생각할 수 있다.

틀린 말은 아니지만, 실제 운영에서는 고려해야 할 문제가 많다.

참가자 상태

사용자가 SFU에 연결되어 있다고 해서 애플리케이션 서버에서도 항상 온라인이라고 볼 수는 없다.

네트워크가 끊겼는데 종료 이벤트를 받지 못할 수도 있고, 모바일 앱이 백그라운드로 이동할 수도 있다.

따라서 참가자 상태는 다음과 같이 구분할 필요가 있다.

• 통화방 입장 요청 상태
• SFU 연결 상태
• 마이크 게시 상태
• 일시적인 재접속 상태
• 정상 퇴장
• 비정상 연결 종료

단순한 boolean 하나로 관리하면 실제 상태와 서버 데이터가 쉽게 어긋난다.

재접속

모바일 네트워크에서는 Wi-Fi와 LTE 사이를 이동하거나, 순간적으로 네트워크가 끊기는 일이 자주 발생한다.

이때 사용자를 바로 퇴장 처리하면 사용자 경험이 좋지 않다.

짧은 재접속 유예 시간을 두고, 같은 참가자가 다시 접속하면 기존 세션을 이어주는 방식을 고려해야 한다.

동시 접속

한 사용자가 여러 기기에서 같은 통화방에 접속할 수 있는지도 결정해야 한다.

이를 허용한다면 사용자와 참가자 세션을 구분해야 한다.

한 명의 사용자에게 여러 개의 Participant가 존재할 수 있기 때문이다.

반대로 하나의 기기만 허용한다면 기존 연결을 종료할 것인지, 새로운 연결을 거절할 것인지 정해야 한다.

음소거

음소거도 종류가 여러 가지다.

• 사용자가 직접 마이크를 끄는 Self Mute
• 사용자가 다른 사람의 소리를 듣지 않는 Deafen
• 관리자가 특정 사용자의 발언을 막는 Server Mute
• 클라이언트에서 특정 참가자의 볼륨만 줄이는 Local Mute

특히 Local Mute는 해당 클라이언트에서만 적용하면 되지만, Server Mute는 서버 권한과 SFU 상태를 함께 관리해야 한다.

통화 기록

누가 언제 들어왔고 언제 나갔는지를 모두 실시간으로 RDB에 기록하면 쓰기 작업이 상당히 많아질 수 있다.

실시간 참가자 상태는 Redis 같은 저장소에서 관리하고, 통화가 종료된 뒤 필요한 기록만 RDB에 정리해서 저장하는 방식도 고려할 수 있다.

서버 확장

Spring Boot 서버는 일반적인 웹 서버처럼 수평 확장이 가능하다.

하지만 WebSocket이나 통화방 상태를 메모리에만 저장하면 서버를 여러 대로 늘렸을 때 문제가 생긴다.

사용자 A는 1번 서버에 연결되고 사용자 B는 2번 서버에 연결될 수 있기 때문이다.

따라서 다음과 같은 구성이 필요할 수 있다.

• Redis를 이용한 참가자 및 Presence 상태 공유
• Redis Pub/Sub 또는 메시지 브로커를 통한 이벤트 전달
• Sticky Session 또는 외부 WebSocket Gateway
• 분산 Lock
• 중복 이벤트 처리
• Idempotency 보장

SFU 역시 참가자가 많아지면 여러 대로 확장해야 한다.

일반적으로 하나의 통화방은 하나의 SFU 노드에 배치하고, 새로운 통화방을 생성할 때 여유가 있는 노드를 선택한다.

하나의 통화방 참가자가 매우 많다면 여러 SFU를 연결하는 분산 구조도 필요해질 수 있다.

하지만 처음부터 이 정도 규모를 고려할 필요는 없을 수도 있다.

예상 동시 접속자와 한 통화방의 최대 인원을 먼저 정하는 것이 중요하다.

모니터링

통화 서버는 HTTP API처럼 상태 코드만 확인해서는 문제를 파악하기 어렵다.

연결은 성공했지만 음성이 계속 끊길 수도 있고, 특정 통신사에서만 통화 품질이 나쁠 수도 있다.

따라서 다음 지표를 수집할 필요가 있다.

• 통화방 입장 성공률
• 연결에 걸린 시간
• 패킷 손실률
• 지터
• 왕복 지연 시간
• 오디오 비트레이트
• 재접속 횟수
• 비정상 종료 비율
• TURN 사용 비율
• SFU 서버의 CPU와 네트워크 사용량

특히 TURN 사용 비율은 비용과도 직접 연결된다.

TURN 비율이 지나치게 높다면 네트워크 설정이나 ICE 구성을 확인할 필요가 있다.

음성이 안 들린다는 사용자 문의를 받았을 때 로그만 보고 원인을 찾는 것은 어렵다.

통화 품질 데이터를 처음부터 수집해 두는 것이 좋다.

비용

음성 통화 서버에서 가장 부담되는 비용은 CPU보다 네트워크 트래픽일 가능성이 높다.

SFU는 참가자에게 음성 데이터를 전달해야 하므로 참가자가 늘어날수록 송신 트래픽도 증가한다.

예를 들어 10명이 하나의 통화방에 참여하고 모두 발언 중이라면, SFU는 각 사용자의 음성을 나머지 참가자들에게 전달해야 한다.

영상이나 화면 공유가 추가되면 트래픽은 훨씬 크게 증가한다.

TURN 서버까지 사용하면 사용자와 SFU 사이의 트래픽이 TURN을 한 번 더 거치게 된다.

따라서 기술을 결정하기 전에 다음 항목을 예상해야 한다.

• 최대 동시 통화 인원
• 하나의 통화방 최대 참가자 수
• 사용자당 평균 통화 시간
• 음성만 사용할지 영상도 사용할지
• 화면 공유가 필요한지
• 해외 사용자가 있는지
• 녹화 기능이 필요한지

초기에는 관리형 RTC의 비용이 비싸 보일 수 있다.

하지만 직접 구축하면 서버 비용 외에도 운영, 모니터링, 장애 대응, 네트워크 최적화 비용이 발생한다.

단순한 인프라 비용만 비교하면 안 된다.

정리

음성 통화 서버를 만든다고 하면 처음에는 WebSocket으로 음성 데이터를 전달하는 구조를 생각하기 쉽다.

하지만 실제 통화에서는 지연, 패킷 유실, 네트워크 경로, 에코 제거, 암호화 등 고려해야 할 것이 많다.

이를 직접 구현하기보다는 WebRTC를 사용하는 것이 일반적이다.

1:1 통화라면 P2P 방식도 가능하지만, 여러 사용자가 참여하는 통화방을 만들려면 SFU 기반 구조를 고려해야 한다.

각 기술의 역할은 다음과 같다.

• WebRTC: 음성, 영상과 같은 실시간 미디어 전송
• Signaling: WebRTC 연결에 필요한 정보 교환
• STUN: 외부에서 접근 가능한 네트워크 주소 확인
• TURN: 직접 연결이 불가능할 때 미디어 중계
• SFU: 다자간 통화에서 미디어 스트림 전달
• Spring Boot: 인증, 통화방, 권한과 서비스 로직 관리

현재로서는 음성 통화 기능을 처음 검토한다면 LiveKit이나 관리형 RTC 서비스를 이용해 PoC를 만들어보는 것이 현실적으로 보인다.

실제 동시 접속자 수와 트래픽, 필요한 기능을 확인한 뒤 셀프 호스팅이나 mediasoup 같은 낮은 수준의 SFU를 검토해도 늦지 않다.

과거에는 음성 통화 기능을 단순히 실시간 데이터를 주고받는 기능 정도로 생각했다.

하지만 조사해 보니 백엔드 서버 하나를 만드는 문제가 아니라, 네트워크와 미디어 처리 시스템을 함께 설계하는 문제에 가까웠다.

결국 중요한 것은 모든 기술을 직접 구현하는 것이 아니라, 서비스에서 어디까지 통제해야 하고 어디까지 기존 솔루션에 맡길지를 적절히 판단하는 것 같다.