Remio는 작은 팀이 공개적으로 만들고 있어요. 이곳은 작업 기록이에요. 뜯어고친 캡처 경로, 우리를 놀라게 한 인코더 설정, 무너뜨렸다가 다시 세운 지연 시간 예산을 담았어요. 새 글이 위에 있고, 이전 글은 나중에 생각이 바뀌었더라도 쓴 그대로 남겨 둬요.
마지막 업데이트 2026-05-19글 7개시간순, 최신 글이 먼저
각 글에는 날짜와 상태가 있고 그 자체로 완결돼요. 배포 중은 변경 사항이 최신 빌드에 적용되었다는 뜻이고, 실험은 아직 측정 중이라는 뜻이며, 보관은 다른 방향으로 넘어갔다는 뜻이에요.
몇 주 동안 macOS 호스트는 가상 디스플레이를 클라이언트 화면 해상도에 고정해 두었고, 그 탓에 어느 한쪽이 바뀌는 순간 호스트 커서와 클라이언트 커서의 크기가 서로 달라졌어요. 가상 디스플레이 관리자를 다시 써서 호스트 작업 공간이 클라이언트 창의 캔버스를 실시간으로 따라가도록 했어요. 이제 창 크기가 어떻든 경계를 넘어도 커서 크기가 같아요. Apple 화면 공유가 늘 그래 온 것처럼요.
가상 디스플레이 논리 포인트 ≡ 클라이언트 창 캔버스 포인트 · 픽셀 상한 3840 · Retina 1× 또는 2×는 창의 기본 픽셀 범위에 따라 선택
가상 디스플레이의 디스플레이 모드를 만드는 macOS 내부 프레임워크에는 조용히 문제를 일으키는 동작이 있어요. 최대 크기가 4096 이상으로 주어지면 최대 크기에서 가짜 2× Retina 모드를 만들어 내고 활성 플래그를 가로채요. 요청한 픽셀 수가 두 배가 돼요. 나흘 밤 동안 탐침하고 기록하며 경험적으로 확인했어요. 3840이면 모든 Retina MacBook 전체 화면과 4K 외장 디스플레이가 들어가고, 프레임워크가 더는 모드를 만들어 내지 않아요. 아직 드문 경우들을 계속 지켜보는 중이에요.
4096 이상에서 경험적으로 문제 발생 · 상한 = 3840 · MacBook Pro 16″ Retina(3456 × 2234)와 4K 외장(3840 × 2160) 포함
더 새로운 브랜치로 스트리밍 엔진을 다시 빌드하면 갱신된 페이싱 로직이 로컬 네트워크 경로에서 몇 밀리초를 줄여 줄 거라고 기대했어요. 하지만 측정한 모든 원격 세션에서 수신 버퍼가 오히려 나빠졌어요. 종단 간 중앙값이 18ms 늘고 편차도 커졌어요. 그래서 iOS, macOS, Android, Windows 모두 안정 빌드로 되돌렸어요. 상위 프로젝트의 동작이 바뀔 경우에 대비해 새 브랜치의 패치는 보관해 두었어요.
새 빌드 중앙값 지연 시간 · 원격 64ms · 이전 빌드 중앙값 · 원격 46ms · 튜닝 플래그는 그대로
이제 호스트는 연결이 만들어진 뒤 첫 왕복 시간 측정을 기다렸다가 두 가지 비트레이트 범위 중 하나를 골라요. 15ms 미만이면 로컬 네트워크 직접 연결로 보고 시작 8Mbps, 최소 8Mbps, 최대 30Mbps로 설정해요. 15ms 이상이면 릴레이 또는 먼 연결로 보고 시작 2Mbps, 최소 300Kbps, 최대 15Mbps로 설정해요. 기준선은 같은 네트워크의 Wi-Fi와 그럴듯한 모든 셀룰러 또는 지역 간 릴레이 사이에 있어서, 베타 텔레메트리에서 오탐은 드물었어요.
로컬 직접 · 1 – 5ms · 같은 네트워크 Wi-Fi · 5 – 10ms · 지역 릴레이 · 30 – 80ms · 4G · 40 – 100ms
경쟁 인코더들과 오랜 비교 끝에 AMD의 하드웨어 H.265가 우리가 중요하게 본 모든 Windows 호스트 벤치마크에서 이겼어요. 인코딩 시간 중앙값이 더 낮고, 키프레임 급증이 더 작고, 초저지연 고정 비트레이트 프리셋이 버퍼 압박에서도 예측 가능하게 동작해요. GPU가 지원하지 않으면 H.264를 대체로 써요. B-프레임은 꺼져 있고 저지연 플래그는 켜져 있어요. 인코더는 캡처 틱마다 정확히 한 프레임만 내보내요.
비트레이트 · 8Mbps 고정 · fps · 60 · 버퍼 · 1프레임 · B-프레임 · 0 · 프리셋 · 초저지연
원격 데스크톱은 화상 통화가 아니에요. 모든 프레임은 가장 최신의 화면 상태예요. 오래된 프레임은 정의상 거짓말이에요. 재생 버퍼가 없도록 수신 경로를 다시 만들었어요. 프레임이 도착하면 디코딩하고 렌더링해요. 그 순서로, 같은 프레임 간격 안에서요. 잃어버린 패킷은 제시간에 도착할 수 있으면 바로 다시 보내고, 그럴 수 없으면 Remio가 기다리지 않고 건너뛴 뒤 새 프레임을 요청해요. 가끔 짧게 멈추는 것은 받아들여요. 대기열이 매번 밀리초씩 물리는 세금은 받아들이지 않아요.
강제 재생 지연 · 최소 0 / 최대 0 · 최소 재생 지연 · 0 · 잃어버린 패킷은 제시간이면 재전송, 아니면 새 프레임
한 방에 모여 앉아 사용자가 느꼈으면 하는 숫자에서 거꾸로 계산했어요. 일반적인 로컬 네트워크 세션에서 유리에서 유리까지 20ms 미만이에요. 캡처, 인코딩, 페이싱, 전송, 수신 버퍼, 디코딩, 렌더링을 각각 적고 측정할 수 있는 밀리초 예산을 정했어요. 이 기록의 대부분의 글은 실제 운영 트래픽에서 그 숫자들을 지켜 내며 나온 거예요.
캡처 · 1ms · 인코딩 · 3ms · 페이싱 버스트 · ≤ 10ms · 수신 버퍼 · 0ms · 디코딩 · 2ms · 렌더링 · 1ms
이 네 가지 수치는 스펙 시트에 적힌 주장이 아니라 연결이 실제로 어떻게 느껴지는지를 설명하기 때문에 모든 릴리스 노트에 실려요.
랩은 무언가 반영되거나 무언가 깨질 때 업데이트돼요. 분기별 뉴스레터보다 쓸모 있어 보인다면 다운로드 링크가 바로 앞에 있고, 더 긴 이야기가 궁금하다면 보안 백서도 있어요.
계정 불필요추적 픽셀 없음공개적으로 만들어요