[PonsLink] DataChannel 위에 PonsCast 프로토콜을 올린 이유

PonsCast는 방 안에 붙인 미디어 기능으로 시작하지 않았다. 언어가 잘 통하지 않는 사람과 같은 파일을 같은 시간에 보고 싶다는 개인적인 필요에서 출발했다.

화면 공유를 쓰면 화면은 같아진다. 하지만 상대가 파일의 어느 부분을 보고 있는지, 같은 속도로 따라오고 있는지, 한쪽이 바뀐 내용을 다른 쪽이 놓치지 않는지는 별개의 문제였다. 내가 해결하고 싶었던 것은 같은 화면보다 같은 시간을 공유하는 일이었다.

화면 공유로는 부족했던 장면

화면 공유는 가장 쉬운 답처럼 보였다. 상대에게 내 화면을 보여 주고, 파일을 설명하면 된다. 그러나 파일을 함께 읽거나 미디어를 함께 볼 때는 설명하는 사람과 따라가는 사람의 시간이 계속 어긋났다.

누가 다음 장면으로 넘어갔는지, 어느 파일을 열었는지, 상대가 같은 상태를 보고 있는지 알 수 있어야 했다. 이 요구는 화면의 복사보다 이벤트의 순서에 가까웠다.

DataChannel 위에 올린 경계

PonsCast는 방 안에서 발생하는 상태 변화를 작은 이벤트로 주고받는 쪽으로 기울었다. 재생 위치나 현재 파일, 다음 행동처럼 상대가 같은 리듬을 유지하는 데 필요한 정보만 보낸다.

모든 화면을 복제하려고 하면 연결이 복잡해진다. 반대로 사용자가 같은 시간을 공유하기 위해 필요한 상태만 정하면, 방의 다른 기능과도 분리해서 생각할 수 있다. DataChannel은 전송 수단이고, 어떤 이벤트를 신뢰할지는 제품이 결정해야 했다.

동작 순서에서 지킨 것

먼저 방에 있는 두 사용자가 어떤 대상과 어떤 상태를 보고 있는지 맞춘다. 그 다음 변경 이벤트를 보내고, 상대가 따라갈 수 있도록 현재 상태를 다시 확인한다. 이벤트가 빠졌을 때는 다음 이벤트만 기다리는 대신 기준 상태를 다시 읽어야 한다.

이 순서를 정하지 않은 채 화면 공유만 붙이면, 한쪽에서는 재생 중인데 다른 쪽에서는 멈춰 있는 상황을 기능 오류인지 사용자의 조작인지 구분하기 어렵다. PonsCast에서 중요한 것은 화려한 미디어 기능이 아니라 어긋남을 설명할 수 있는 상태였다.

마치며

같은 화면을 보여 주는 것과 같은 시간을 공유하게 만드는 것은 다르다. 다음에 PonsCast 같은 기능을 붙일 때는 전송 채널부터 고르지 않고, 사용자가 어떤 상태를 함께 보고 있어야 하는지 먼저 적겠다.