03 / APPLE TV × BTV · 2026-09-09
Apple TV, 긴 랜선 없이 Btv를 보다.
실시간 방송의 유선 연결 조건 때문에 제한되던 TV 배치를 Pi와 NAS의 OpenWrt로 풀었습니다. 방을 가로지르는 연결은 Wi-Fi, Apple TV 바로 옆은 짧은 랜선입니다.
이동식 스탠드에도, 원하는 자리에도.
무선 기능이 있는 Apple TV, 실시간 방송은 유선 연결 요구
상위 구간을 Wi-Fi로 이어 원하는 위치에서 방송 재생
PLACEMENT FREEDOM, WITH A REAL NETWORK PATH
와이파이가 느려서 안 된다고? 2.4GHz로 재생해봤습니다.
운영자가 겪은 유선·직결 연결 조건을 NAS의 OpenWrt와 Pi로 풀었습니다. Apple TV에는 유선으로 보이지만, TV까지 오는 긴 구간은 무선입니다.
방송 재생 중 기록된 전송량
관측 구간의 패킷 손실
5초 간격, 끊김 없이 재생
2026-08-26, 해당 장소·구성에서의 짧은 실제 관측입니다. 2026-09-09에는 AP 변경 후 Pi·터널·Apple TV 연결 복구도 기록했습니다.
FROM REQUEST TO RESULT
어떻게 만들었을까요?
- 01
불편 확인
운영자가 겪은 유선·직결 조건과 설치 장소 제한을 정리합니다.
- 02
NAS 경로 구성
NAS의 OpenWrt에 방송 장치가 통신할 경로를 만듭니다.
- 03
무선 구간 연결
AP와 Pi는 Wi-Fi로, Pi와 Apple TV는 짧은 랜선으로 연결합니다.
- 04
실제 방송 확인
2.4GHz 재생과 전송량·손실을 확인하고 장애 복구를 기록합니다.
COULD THIS WORK FOR YOU?
내 환경에서도 가능할까요?
Apple TV에서 Btv를 무선으로 보려면 Pi와 NAS는 각각 어떤 역할을 하나요?
THE EVIDENCE & LIMITS
기록을 더 자세히 보기
어떤 기록으로 확인했나요?
2026년 8~9월의 Codex 작업 기록, 인계 문서와 보관된 프로그램을 대조한 사례입니다. 설명용 생성 이미지는 실제 설치 사진이 아닙니다. 각 검증은 기록된 날짜와 범위에 한정됩니다.
01무선 Apple TV에 유선 조건이 붙었을 때
운영자는 Apple TV의 Btv 실시간 방송을 사용하면서 유선 및 광모뎀 직결 조건 때문에 원하는 장소에 TV를 배치하기 어려웠다고 설명합니다. 이 환경에서 Pi와 NAS의 OpenWrt를 사용해 방송 통신 경로와 무선 구간을 구성했습니다.
상위 구간은 AP와 Pi 사이의 Wi-Fi이고, Pi와 Apple TV는 짧은 Ethernet 케이블로 연결됩니다. 따라서 방을 가로지르는 긴 랜선 없이 배치할 수 있지만 Apple TV 자체는 Ethernet 연결로 인식합니다.
022.4GHz로 직접 재생해 본 결과
원본 구성 기록은 Raspberry Pi 3의 2.4GHz Wi-Fi 사용을 명시합니다. 2026년 8월 26일의 25초 관측에서는 방송이 끊김 없이 재생됐고, 전송량 약 13.44–13.50Mbps와 패킷 손실 0%를 확인했습니다.
이 결과는 해당 환경에서 무선 구간으로 재생 가능했음을 보여줍니다. 모든 무선 환경의 품질이나 사업자의 제한 이유를 입증하는 범위까지 확대하지 않습니다. 2026년 9월 9일에는 AP 변경 뒤 Pi·터널·Apple TV 연결 복구도 기록했습니다.
03물리 연결과 상위 연결을 나눈다
Apple TV는 Raspberry Pi 3의 Ethernet 포트에 직접 연결하고, Raspberry Pi는 Wi-Fi로 상위 네트워크에 접속했습니다. OpenWrt와 Pi 사이에 VXLAN 터널을 구성하여 장치가 기존 LAN의 주소 체계와 통신 경로를 사용하도록 했습니다.
핵심은 작은 장비를 추가해 현재 환경의 연결 조건을 맞추는 것이었습니다. 에이전트가 인터페이스 구성과 자동 시작·장애 점검 문서를 작성하고, 사람은 실제 배선과 방송 재생을 확인했습니다.
04재생 중에 무엇을 측정했나
2026년 8월 26일 방송 재생 중 5초 간격으로 25초 동안 측정했습니다. 기록된 다운로드는 약 13.44–13.50Mbps였고, 해당 관측의 패킷 손실은 0%, 안정화 이후 일반 지연은 약 6–18ms였습니다. 재생은 해당 확인 동안 끊김 없이 진행됐습니다.
이 수치는 짧은 시간, 한 장소, 당시 무선 환경에서의 관측입니다. 하루 종일 안정적이었다거나 다른 영상 해상도·비트레이트에서도 같은 결과가 나온다는 뜻은 아닙니다. 처음 연결했을 때의 백그라운드 동기화로 지연이 일시적으로 커졌다는 기록도 함께 남겼습니다.
05배선과 복구 순서도 결과물이다
Pi의 Ethernet은 Apple TV에만 직접 연결하도록 구성했습니다. 브리지가 켜진 상태에서 같은 포트를 상위 스위치에 연결하면 네트워크 루프가 생길 수 있어, 케이블 연결 조건을 운영 문서에 명시했습니다.
장애 점검은 전원과 직접 연결 케이블, Wi-Fi 연결, 브리지와 터널, 장치 주소 순서로 정리했습니다. 부팅 후 자동 연결뿐 아니라 잘못된 연결을 되돌릴 수 있도록 원래 설정의 백업과 복구 절차도 남겼습니다.
06다음 실험에서 더 확인할 항목
재현 실험에서는 재부팅 후 복구, 무선 신호가 약한 위치, 동시 다운로드, 장시간 재생을 별도로 측정하는 것이 좋습니다. 평균 속도 하나보다 끊김 횟수와 가장 긴 지연, 복구에 걸린 시간이 실제 사용성을 더 잘 설명할 수 있습니다.
이 사례에서는 생산성 비교를 위한 작업 시간 기준선을 수집하지 않았습니다. 따라서 에이전트의 시간 절감률을 주장하지 않고, 실제 작동한 구성과 측정 범위, 운영자가 이어받을 수 있는 문서에 초점을 둡니다.
0701 · 요구 조건을 나누다
Apple TV가 실제 Ethernet 링크를 인식해야 하는 조건과 방까지 긴 선을 놓기 어려운 조건을 분리했다.
0802 · Pi에 짧은 선을 연결하다
Apple TV는 Raspberry Pi 3의 Ethernet 포트에 직접 연결하고, Pi는 Wi-Fi로 AP에 붙였다.
0903 · 같은 LAN으로 이어주다
Pi와 NAS의 OpenWrt 사이에 VXLAN을 만들고 양쪽 브리지에 연결해 DHCP·방송 트래픽을 전달했다.
1004 · 방송과 복구를 확인하다
B tv 실시간 방송 재생과 전송량을 확인했다. AP 교체 후 끊긴 연결도 Pi·터널·Apple TV 순서로 복구를 확인했다.
11확인한 결과와 범위
2026-08-26: B tv가 유선 연결로 인식하고 실시간 방송 재생을 확인했다.
당시 25초 표본: 약 13.5 Mbps 스트림, 측정 패킷 손실 0%. 장시간 품질 보증 수치는 아니다.
2026-09-09 복구 기록: Pi·Apple TV 연결, VXLAN, HomeKit 광고가 정상. 구독·계정 권한을 바꾸는 구성은 아니다.
NAS OpenWrt → 스위치 → 무선 AP ⇢ Wi-Fi·VXLAN ⇢ Raspberry Pi 3 → 짧은 Ethernet → Apple TV → B tv