Local Device Pairing: From Hell to Heaven (mDNS vs. QR)

최근 클라우드 애플리케이션과 상호작용해야 하는 로컬 IoT나 미디어 서버를 배포할 일이 있었는데

 

개발 과정에서 가장 큰 복병을 만났습니다. 바로 기기 검색과 페어링(Pairing) 문제입니다

 

로컬 네트워크 공유기에서 포트 포워딩(Port Forwarding)을 따로 설정하지 않으면

 

클라우드 서버, 클라이언트는 로컬에 있는 기기에 직접 접근할 수가 없습니다

 

하지만 포트 포워딩에 의존하게 되면 여러 가지 골치 아픈 문제들이 생깁니다

1. 유저가 공유기 접근 권한이 없을 때
2. 권한이 있다고 해도, 로컬 포트를 외부 인터넷에 그대로 노출할 때 발생하는 보안 취약점
3. 게다가 비전문가인 일반 유저에게 로컬 IP 주소를 직접 찾아서 입력하라고 할 때 저급한 UX

이런 네트워크 설정 지옥을 피하기 위해, 여러 가지 대안 페어링 전략들을 고민해 봤습니다

 

대안 1: BLE (Bluetooth Low Energy)

모바일 앱이라면 BLE가 좋은 대안이 됩니다

(프레임워크에서 강력한 스캔 및 페어링 API를 제공합니다)

 

기기가 퍼블리싱(브로드캐스트)을 하고, 앱이 스캔해서 페어링하면 끝납니다

 

그런데 웹 애플리케이션에서는 조금 다른 이야기가 됩니다

 

Web Bluetooth API는 브라우저 보안 정책에 의해 제약이 많고, 크로스 플랫폼 안정성도 떨어집니다

 

궁극적으로 이번 프로젝트는 웹에서 매끄러운 경험을 제공하는 것이 목표였기 때문에 BLE는 과감히 제외했습니다

 

대안 2: mDNS (Multicast DNS)

mDNS는 설정이 필요 없는 네트워크를 보장한다는 점에서 정말 매력적인 카드였습니다

 

처음 샌드박스 단계에서 웹 클라이언트와 로컬 서버를 같은 PC에 띄워두고 테스트했을 때는

 

아무런 설정 없이도 완벽하게 잘 작동했습니다

 

하지만 이 제로 세팅은 실제 환경에서 생각대로 작동하지 않더군요

(동일 Wi-Fi 환경에서 폰으로 pc를 찾으려고 할 때)

 

공유기를 별도로 세팅해주지 않으면 mDNS는 기본적으로 기기를 제대로 찾지 못하는 경향이 있습니다

 

요즘 나오는 대부분의 기업용/가정용 공유기들은 대역폭 최적화와 보안을 이유로 AP 격리(AP Isolation)나

 

IGMP 스누핑(IGMP Snooping) 차단 기능을 켜두기 때문에, 멀티캐스트 포워딩이 기본적으로 막혀있습니다

 

일반 유저에게 공유기 어드민 페이지에 접속하라고 강요할 수는 없는 노릇이니

 

mDNS 하나만 믿고 가기에는 무리가 있습니다

 

확실한 Fallback 전략이 필수적인 상황이죠

 

그래도 웹 개발자로서 클라우드에 올려놓은 클라이언트가

 

기기에 올라가있는 서버에 접근하는건 충분히 매력적이어서 한번 해봤습니다

 

해당 플로우를 보면

< 로컬 서버 연결 flow chart >

1. 로컬 서버가 부팅되면 클라우드에 쿼리를 날려 페어링 상태 확인
2. 아직 페어링되지 않은 상태라면, mDNS를 구동하여 특정 호스트 네임으로 브로드캐스트
3. 클라이언트가 이 브로드캐스트를 감지하면, 보안 핸드셰이크 토큰을 통해 페어링 시작
4. 페어링 트랜잭션이 완료되면, 로컬 서버는 mDNS 브로드캐스트를 안전하게 내리고 클라우드에 요청
5. 이후 클라우드는 MQTT 브로커를 위한 증명을 발급하고, 기기는 Standby 상태로 전환되어 클라이언트의 명령을 구독

 

클라이언트 사이드 Fallback의 필요성

< 클라이언트 paring flow chart >

 

1. 클라이언트는 먼저 지정된 로컬 mDNS 호스트 네임을 스캔하며 낙관적인 조회를 시도
2. 기기가 발견되면 상태를 확인하고, 클라우드에 보안 페어링 토큰을 요청
3. 토큰 데이터를 로컬 서버로 직접 보내 보내 페어링을 완료

하지만 앞서 말씀드렸듯이, 현실의 Wi-Fi 환경에서 mDNS는 예상치 못한 이유로 실패하곤 합니다

 

서비스가 완전히 먹통이 되는 걸 막으려면 강력한 대체 메커니즘이 필요하겠죠

 

그래서 준비한 것이 바로 클라우드 릴레이를 통한 QR 코드 페어링입니다

 

사실 대다수의 IoT 기업들이 기본 세팅으로 QR 코드를 사용하는 이유가 바로 이것 때문입니다

(로컬 네트워크의 인프라 제약을 완전히 우회하면서 가장 쉽고 깔끔하게 해결 가능)

 

유저가 이를 스캔하면 앱은 막혀있는 로컬 멀티캐스트 레이어를 싹 건너뛰고

 

Cloud에 유저 아이디랑 기기 일련번호만 넘겨주면 되니까요

 

마치며

스마트홈 허브부터 스트리밍 하드웨어까지 대부분 대형 IoT 기업들이

 

왜 더 간단한 pairing방법을 채택했는지 알게되는 좋은 계기가 된거 같습니다

 

1. 처음에는 mDNS라는 기술적인 우아함에 이끌려 시작했다가

2. 파편화된 공유기 설정이라는 혹독한 현실을 마주하고

3. 결국에는 QR 코드나 PIN 번호 기반의 클라우드 페어링으로 정착

 

이 변화를 받아들인 이유는 프로덕트 개발에 있어 변하지 않는 단 하나의 진리 때문이 아닐까 싶습니다

"비즈니스에서 유저 경험(UX)은 개발자 경험(DX)보다 훨씬 더 중요하다."

 

🛠️ 아키텍처 및 소스 코드 구경하기

• 전체 소스 (GitHub) 👉 https://github.com/devmemory/portfolio-device-sync
• 배포된 사이트 👉 https://www.devmemory.xyz/

 

< 테스트 화면 >

 

참고: 현재 클라우드 서버와 클라이언트는 호스팅되어 있지만, 실제 실시간 스트리밍 세션을 연결하려면 물리 카메라 옆에서 작동하는 로컬 서버가 필요합니다. 하드웨어 인프라 보호를 위해 로컬 런타임 환경의 동적 액세스 자격 증명(app-auth 설정)은 엄격히 제한해 둔 상태입니다. 채용 목적 제외하고는 오픈을 제한하고 있습니다(서버비용 많이내고싶지 않아요...)

추가로, 현재 클라우드 인프라는 글로벌 배포 최적화를 위해 독일(유럽)에 호스팅되어 있습니다. 이 때문에 한국에서 촬영한 라이브 데모 영상에서는 물리적 거리로 인한 대륙 간 네트워크 레이턴시와 약간의 렌더링 끊김 현상이 보일 수 있습니다. 유럽에서 대시보드에 직접 접속하시면 훨씬 더 매끄럽고 지연 없는 환경을 확인하실 수 있습니다.