모니터를 꽂았을 뿐인데 소프트웨어가 깔린다 — LG·Windows Update·드라이버 신뢰 체계의 구멍
모니터를 꽂았을 뿐인데 소프트웨어가 깔린다 — LG·Windows Update·드라이버 신뢰 체계의 구멍
모니터가 사용자 동의 없이 Windows Update 로 소프트웨어를 설치할 수 있다는 것은 개별 벤더의 일탈인가, 드라이버 서명·업데이트 신뢰 체계에 뚫린 구조적 구멍인가.
도입
2026 년 7 월 18 일 (KST), Hacker News 첫 페이지 맨 위에 오른 것은 videocardz.com 의 한 기사였다. 제목은 “LG monitors silently install software through Windows Update without user consent” — LG 모니터가 사용자 동의 없이 Windows Update 를 통해 소프트웨어를 몰래 설치한다는 것이었다. 1078 점, 댓글 546 개. 단일 벤더의 한 번의 실수를 다룬 기사가 이 정도의 호응을 받는 일은 흔하지 않다. 호응의 크기는 이 사건이 단순한 LG 의 실수로 읽히지 않았다는 신호다.
사실관계는 단순하다. 사용자가 LG 모니터를 Windows PC 에 케이블로 연결하면, 아무런 확인 창도 뜨지 않은 채로 LG Monitor App Installer 라는 Microsoft Store 앱이 설치된다. Microsoft Store 상의 패키지 식별자는 9PM9N6F47JB8-LGElectronics.LGMonitorApp 이고, 게시자는 LG Electronics 본인이다. 설치된 앱은 부팅할 때마다 McAfee 30 일 무료 체험 팝업을 띄운다. 사용자는 소프트웨어를 다운로드하겠다고 클릭한 적도, 라이선스에 동의한 적도 없다. 모니터라는 물리적 주변기기 하나를 연결한 것이 전부다.
이 사건이 큰 반향을 부른 까닭은, 이것이 LG 만의 문제가 아니라는 점을 다수의 사용자가 즉시 알아챘기 때문이다. 같은 메커니즘 위에서 Alienware, ASUS, Samsung 의 유사한 자동 설치가 같은 스레드에서 보고되었다. 즉 문제의 무게 중심은 “LG 가 나쁜 짓을 했다” 가 아니라, “모니터 제조사가 사용자 동의 없이 임의의 소프트웨어를 PC 에 밀어 넣을 수 있는 통로가 Windows 안에 이미 존재한다” 는 사실 자체다. 리드 질문은 여기서 나온다. 이것은 개별 벤더의 일탈인가, 아니면 드라이버 서명과 업데이트 신뢰 체계가 처음부터 안고 있던 구조적 구멍인가. 이 글은 무엇이 어떻게 설치되는지, 그 통로가 왜 존재하는지, 그리고 그 통로를 막을 수 있는지를 순서대로 본다.
현상 — 케이블 한 번에 따라오는 것들
우선 무엇이 설치되는지부터 정확히 짚는다. 설치되는 것은 드라이버 그 자체가 아니라 LG Monitor App Installer 라는 이름의 런처다. 이 런처는 연결된 모니터 모델에 따라 추가 소프트웨어를 내려받는 중앙 허브 역할을 한다. Microsoft Store 설명에 따르면 이 허브가 제공하는 것은 OnScreen Control, LG Switch, Dual Controller, UltraGear Control Center 같은 LG 모니터 유틸리티들이다. 이들 자체는 모니터의 밝기·화면 분할·KVM 전환 등을 다루는 정상적인 기능성 소프트웨어다. 문제는 기능의 유해성이 아니라 설치의 무단성에 있다.
무단성을 가장 선명하게 드러낸 것은 McAfee 광고였다. igorslab.de 와 Tom’s Hardware 의 보도에 따르면, 한 사용자가 LG UltraGear 27GP83B 한 대와 LG 27GN800 두 대를 연결한 뒤 Windows 안정성 기록 (Reliability History) 을 확인하는 과정에서 이 설치를 처음 발견했다. 발견의 방아쇠는 부팅 직후 뜬 McAfee 팝업이었다. 30 일 무료 체험을 유료 구독으로 전환하도록 유도하는 그 팝업은, 연속된 32 회의 부팅 가운데 31 회에서 나타났다. 모니터 유틸리티가 안티바이러스 벤더의 광고 게시판이 된 것이다.
더 무거운 것은 이 앱이 선언한 권한이다. privacyguides.org 의 정리에 따르면, LG Monitor App Installer 는 Microsoft Store 상에서 “모든 시스템 리소스에 대한 접근 (access to all system resources)” 과 “인터넷 연결 접근 (access your internet connection)” 을 선언한다. 즉 이 앱은 UWP 샌드박스의 제한을 받는 통상적 스토어 앱이 아니라, 전체 시스템에 접근할 수 있는 신뢰 수준으로 실행된다. 같은 매체는 그 함의를 이렇게 요약했다. “이론적으로, 인터넷 접근이 있다면 이 앱은 광고를 다른 것으로 바꿔치기하거나 시스템에서 데이터를 유출할 수도 있다.” 지금 뜨는 것이 McAfee 광고라는 사실은 오늘의 페이로드일 뿐, 그 자리에 무엇이 들어올지는 벤더와 그 파트너의 선택에 달려 있다는 뜻이다.
사용자의 통제권이 얼마나 약한지도 이 사건의 핵심이다. HN 사용자 Kelteseth 는 이렇게 적었다. “확인해 줄 수 있다. 어제 내 Windows 11 기기에서 똑같이 일어났다. 제거는 오직 Microsoft Store 의 라이브러리 항목에서만 가능했다.” 제어판의 일반적 프로그램 제거 목록에도, 앱 설정의 명확한 자리에도 잘 노출되지 않는다는 것이다. 게다가 제거해도 끝이 아니다. HN 사용자 thewebguyd 의 증언은 더 직접적이다. “나는 LG 모니터가 있는데, 어느 순간 그 멍청한 LG 앱이 나타난 걸 발견했다. 제거했더니, Windows Update 의 업데이트 항목으로 다시 튀어나왔다. Microsoft 가 이 동작을 능동적으로 가능하게 하고 있다.” 제거 → 재설치의 순환은 Windows 가 자동 다운로드한 드라이버·앱을 드라이버 저장소 (Driver Store) 에 캐싱해 두었다가 장치가 다시 인식될 때 재적용하기 때문에 발생한다.
여기서 사건의 성격이 드러난다. 이것은 악성코드의 침투가 아니다. 서명된 정품 소프트웨어가, 정품 통로를 통해, 사용자의 명시적 동의 없이 실행된 것이다. HN 사용자 devttyeu 의 요약이 그 역설을 정확히 찌른다. “당신의 OS 가 제3자 벤더의 멀웨어 (기술적으로는 제조사 소프트웨어) 를 백그라운드에서, 사용자 상호작용 제로로 설치한다.” 괄호 속 정정 — “기술적으로는 제조사 소프트웨어” — 이 이 사건의 회색지대를 정확히 표시한다. 코드는 합법이고 서명은 유효하지만, 사용자의 동의만이 없다.
심층 — Windows Update 는 왜 이것을 허용하는가
이 통로는 버그가 아니라 설계다. 그리고 처음에는 선의로 설계되었다. HN 사용자 joe_mamba 는 그 역사를 이렇게 회고한다. “이건 Windows 7 이후로 있던 기능이고, 잘 작동했다. 설치 후 인터넷을 뒤지고 다닐 필요 없이 필요한 드라이버를 전부 끌어와 줬으니까.” orbital-decay 의 지적은 그 통로가 언제부터 남용되었는지를 짚는다. “프린터, 마우스, 태블릿, 디스플레이 태블릿 제조사들은 적어도 Windows Vista 나 7 이후로 이 통로를 자기네 쓰레기 앱을 밀어 넣는 데 써 왔다.” 즉 “장치를 꽂으면 드라이버가 알아서 깔리는” 편의성과 “장치를 꽂으면 원치 않는 소프트웨어가 알아서 깔리는” 남용은 같은 하나의 메커니즘의 양면이다.
그 메커니즘의 현재 형태를 이해하려면 Windows 의 DCH 드라이버 모델을 봐야 한다. DCH (Declarative, Componentized, Hardware Support Apps) 는 Microsoft 가 밀어 온 현대적 드라이버 패키징 규격으로, 세 가지 원칙으로 이루어진다. 첫째 Declarative — 드라이버는 코인스톨러 (co-installer) 나 RegisterDll 같은 명령형 확장 없이, 선언적 INF 지시자만으로 설치되어야 한다. 둘째 Componentized — 기본 드라이버와 OEM·에디션별 선택적 커스터마이징이 분리되어야 한다. 셋째가 핵심인데, Hardware Support App (HSA) — 드라이버에 딸린 모든 UI 구성요소는 드라이버 패키지 바깥으로 분리되어, HSA 라는 별도의 앱으로 패키징되어야 한다.
바로 이 HSA 가 남용의 통로다. Microsoft 문서에 따르면 HSA 는 UWP 혹은 Desktop Bridge 앱으로 MSIX 패키징되어 반드시 Microsoft Store 를 통해 배포·업데이트되어야 한다. 그리고 제조사는 이 HSA 를 “장치가 연결되면 자동 설치” 되도록 구성할 수 있다. 자동 설치의 흐름은 이렇다. 장치를 연결하면 Windows 가 그 하드웨어 식별자를 WMIS (Windows Metadata and Internet Services) 에서 받아 온 장치 메타데이터와 대조하고, 메타데이터를 파싱해 연결된 앱을 식별한 뒤, 그 앱의 다운로드를 촉발한다. LG 사례에서 벌어진 일이 정확히 이것이다. 커널에 실제로 로드되는 디스플레이 드라이버는 Windows 기본 드라이버로 충분한데도, 장치 메타데이터가 가리키는 스토어 앱 — LG Monitor App Installer — 이 자동으로 딸려 온 것이다.
여기서 두 개의 신뢰 판단이 하나로 뭉개진다. 서명 신뢰 체계가 보증하는 것은 “이 코드는 검증된 게시자 (LG Electronics) 에게서 왔고 배포 도중 변조되지 않았다” 는 출처의 진정성이다. 그런데 자동 설치 메커니즘은 이 출처 보증을 “그러므로 이 코드는 사용자가 원하고 안전하다” 는 의도의 정당성으로 슬쩍 확장한다. 서명은 출처를 증명할 뿐 선의를 증명하지 않는다. HN 사용자 MatejKafka 는 이 지점을 이렇게 정리했다. “드라이버는 여전히 인증을 통과하고 서명을 받아야 한다. Microsoft 는 그것을 거부할 권한이 있다.” 형식적으로는 옳다. 그러나 인증과 서명이 검사하는 것은 코드의 기술적 적합성과 게시자 신원이지, “이 앱이 부팅마다 McAfee 광고를 띄울 것인가” 라는 행위의 정당성이 아니다. 게이트는 존재하지만, 그 게이트가 재는 척도가 다른 것이다.
문제를 원리 수준에서 짚은 것은 HN 사용자 coldtea 였다. “드라이버는 어떤 종류든 광고를 띄우는 전면 프로그램이어서는 안 된다. 샌드박스에 갇혀 엄격한 API 를 따라야 한다.” 이 지적이 정확한 이유는, DCH 모델이 원래 드라이버에서 UI 를 떼어내 샌드박스된 HSA 로 분리하려던 규격이었다는 데 있다. 그런데 그 HSA 가 “모든 시스템 리소스 접근” 권한을 선언하고 광고를 띄우는 순간, 샌드박스로 위험을 격리하려던 설계 의도는 뒤집힌다. 격리를 위해 만든 상자가, 격리되지 않은 권한을 담는 상자로 쓰인 것이다.
이 구조가 새로운 것은 아니다. OEM 이 특권적 통로를 이용해 사용자가 요청하지 않은 소프트웨어를 심는 패턴에는 잘 알려진 선례가 있다. 가장 악명 높은 것은 2015 년 Lenovo 의 Superfish 사건이다. Lenovo 는 소비자용 노트북에 Superfish Visual Discovery 라는 광고 삽입 소프트웨어를 선탑재했는데, 이 소프트웨어가 웹페이지에 광고를 주입하기 위해 자기 서명 루트 인증서를 시스템 신뢰 저장소에 심었다. 그 인증서의 개인키가 모든 기기에서 동일했기 때문에, 누구든 그 키를 추출하면 임의의 HTTPS 연결을 중간자 (MITM) 로 가로챌 수 있었다. 편의를 위해 심은 소프트웨어가 TLS 신뢰 체계 전체를 무너뜨린 것이다. 미국 FTC 는 2017 년 Lenovo 와 합의에 이르렀다.
Superfish 만이 아니다. HP 는 2017 년경 HP Touchpoint Analytics 같은 텔레메트리 서비스를 사용자 동의 없이 업데이트를 통해 심어 논란이 되었고, Lenovo 는 이보다 앞서 LSE (Lenovo Service Engine) 를 통해 BIOS/UEFI 의 WPBT 메커니즘으로 OS 재설치 후에도 소프트웨어를 자동 복구하도록 만들어 비판받았다. 통로는 매번 다르다 — 선탑재, 펌웨어, 텔레메트리 업데이트, 그리고 이번의 Windows Update HSA. 그러나 구조는 하나로 수렴한다. 소비자 기기에 대한 신뢰 — 하드웨어를 사면 그 제조사가 내 시스템에 특권적 접근을 갖게 된다는 사실 — 를 제조사가 사용자의 이익이 아닌 자사의 수익화에 전용하는 것이다. LG 사례는 이 계보의 최신 항목이며, 통로가 이제 “모니터 케이블 연결” 이라는 가장 수동적인 행위로까지 내려왔다는 점에서 오히려 더 무겁다.
전망 — 이 구멍을 막을 수 있는가
실무적 대응부터 본다. 개별 사용자가 이 자동 설치를 끄는 방법은 존재한다. 설정에서는 시스템 > 정보 > 고급 시스템 설정 > 하드웨어 탭 > 장치 설치 설정에서 “장치에 대한 제조업체 앱을 자동으로 다운로드하겠습니까?” 를 “아니요” 로 바꾼다. 더 확실하게는 그룹 정책 편집기 (gpedit.msc) 에서 컴퓨터 구성 > 관리 템플릿 > 시스템 > 장치 설치의 “인터넷에서 장치 메타데이터 검색 방지” 와 “메타데이터에 연결된 응용 프로그램의 자동 다운로드 방지” 를 활성화한다. HN 사용자 delta_p_delta_x 가 스레드에서 공유한 것도 정확히 이 경로다.
그러나 이 대응에는 세 가지 구조적 한계가 있다. 첫째, 이 설정들의 기본값이 “예” 라는 점이다. 즉 아무것도 하지 않은 절대 다수의 사용자는 자동 설치에 노출되어 있다. 옵트아웃 (opt-out) 을 요구하는 설계는, 문제를 아는 소수만 보호하고 모르는 다수는 방치한다. 둘째, gpedit.msc 는 Windows Home 에디션에 존재하지 않는다. 즉 이 가장 확실한 차단 수단은 가장 취약한 소비자 계층 — Pro 를 사지 않은 일반 사용자 — 에게는 애초에 주어지지 않는다. 셋째, 드라이버 저장소 캐시 문제로 인해 이미 유입된 항목은 장치 재인식 시 되살아날 수 있다. HN 사용자 Someone1234 는 그래서 이렇게 못박았다. “Microsoft 가 여기 개입해야 한다. 이건 자기네 제품을 쓰는 사람에게 정상적으로 기대되어야 할 동작이 아니다.” 사용자 측 완화책이 존재한다는 사실이, 설계 책임을 사용자에게 넘기는 근거가 될 수는 없다는 지적이다.
Microsoft 의 입장에서 보면 이것은 인센티브 구조의 문제다. 자동 드라이버·앱 설치 통로는 OEM 이 요구하는 기능이다. 프린터·마우스·GPU·모니터 제조사 모두가 “우리 장치를 꽂으면 우리 소프트웨어가 즉시 준비되어 있기를” 원하고, 그 즉시성이 Windows 의 하드웨어 호환성이라는 핵심 가치를 지탱한다. HSA 자동 설치를 전면 폐지하면 정상적인 장치 편의성도 함께 죽는다. 반대로 방치하면 그 통로는 계속 광고와 텔레메트리의 배관으로 쓰인다. Microsoft 는 사용성과 남용 방지 사이의 트레이드오프 한가운데에 서 있고, 지금까지의 기본값 선택 — 자동 설치 “예” — 은 OEM 쪽으로 기울어 있었다.
기술적 변화의 조짐은 있다. Microsoft 문서에 따르면 이번 사건의 배관인 장치 메타데이터 (device metadata) 방식은 이미 deprecated 상태이며, 향후 Windows 릴리스에서 제거되고 “드라이버 패키지 컨테이너 메타데이터 (Driver Package Container Metadata)” 로 대체될 예정이다. 그러나 이것이 남용을 끝낼지는 불확실하다. 대체 메커니즘 역시 “장치 식별자로 연결된 앱을 자동 설치” 한다는 근본 설계를 공유한다면, 배관의 이름만 바뀔 뿐 남용의 표면적은 그대로 남는다. 핵심 변수는 자동 설치의 기본값을 “아니요” 로 뒤집을 것인가, 그리고 스토어 인증 단계에서 “부팅마다 제3자 광고를 띄우는 HSA” 같은 행위를 거부 사유로 삼을 것인가다. 전자는 OEM 반발을, 후자는 심사 비용 증가를 부른다. 둘 다 Microsoft 가 지금까지 감수하지 않으려 한 비용이다.
OEM 측의 트레이드오프도 분명하다. 이 통로로 얻는 것은 소프트웨어 배포 마찰의 제거와 McAfee 같은 제휴사로부터의 부가 수익이다. 잃는 것은 신뢰다. 1078 점짜리 HN 스레드와 여러 매체의 동시 보도가 보여 주듯, 이런 남용은 이제 즉시 가시화되고 브랜드 비용으로 되돌아온다. Superfish 이후 Lenovo 가 “블로트웨어 없는 클린 이미지” 를 마케팅 포인트로 삼아야 했던 것이 그 비용의 실물이다. 규제 측면에서도 FTC 의 Superfish 합의라는 선례가 있어, 동의 없는 설치가 반복되면 소비자 보호·기만적 관행 (deceptive practices) 프레임으로 규제 리스크가 커진다. 단기 제휴 수익과 장기 신뢰·규제 리스크 사이의 교환에서, LG 는 지금 후자의 청구서를 받고 있다.
결국 세 당사자의 유인이 어긋난 자리에 이 구멍이 있다. Microsoft 는 하드웨어 호환성을 위해 자동 통로를 열어 두고 싶고, OEM 은 그 통로로 수익화하고 싶으며, 사용자는 원치 않는 소프트웨어를 거부하고 싶다. 앞의 둘은 통로의 존재를 원하고, 마지막 하나만 통로의 폐쇄를 원한다. 힘의 배분이 이렇게 2 대 1 인 한, 기본값은 계속 통로를 여는 쪽으로 설정될 것이다. 이 구멍을 막는 유일한 확실한 길은, 자동 설치를 옵트인 (opt-in) 으로 뒤집어 “사용자가 명시적으로 허락하지 않은 소프트웨어는 설치되지 않는다” 는 원칙을 기본값으로 삼는 것이다. 그러나 그 결정은 기술이 아니라 힘의 재배분의 문제다.
결론
리드 질문으로 돌아간다. 이것은 개별 벤더의 일탈인가, 구조적 구멍인가. 정직한 답은 둘 다이며, 그 둘은 분리되지 않는다. LG 가 모니터 유틸리티 런처에 McAfee 광고를 실어 부팅마다 띄운 것은 명백히 벤더의 일탈이다. 그러나 그 일탈이 가능했던 것은, “서명된 게시자의 앱을 장치 연결만으로 자동 설치한다” 는 통로를 Windows 가 기본값으로 열어 두었기 때문이다. 일탈은 개별적이지만, 일탈을 실행할 배관은 구조적으로 미리 깔려 있었다.
이 사건의 진짜 교훈은 서명 신뢰 체계의 한계에 있다. 코드 서명과 스토어 인증은 “누가 만들었는가” 와 “변조되지 않았는가” 를 증명하는 데는 유효하지만, “이 코드가 사용자의 이익을 위해 동작하는가” 는 증명하지 못한다. 출처의 진정성과 의도의 정당성은 다른 축이고, 지금의 신뢰 체계는 앞의 것을 검증한 뒤 뒤의 것까지 자동으로 승인해 버린다. LG, Alienware, ASUS, Samsung 이 같은 통로에서 발견되었다는 사실은, 이것이 한 회사의 도덕성 문제가 아니라 그 승인의 자동성이 만든 구조적 유인의 문제임을 말한다.
소비자 기기에 대한 신뢰란 결국 이런 것이다. 사용자가 모니터 한 대를 사서 케이블을 꽂을 때, 그는 화면이 켜지기를 기대하지 자신의 PC 에 전권 접근 소프트웨어가 심기기를 기대하지 않는다. 그 기대와 실제 사이의 간극을 메우고 있던 것은 제조사의 자제였고, LG 사례는 그 자제가 얼마나 얇은 방어선이었는지를 보여 준다. 자제에 의존하는 신뢰는 언제든 수익화의 유혹 앞에서 무너진다. 구멍을 진짜로 막으려면 기본값을 바꿔야 하고, 기본값을 바꾸는 것은 Microsoft·OEM·사용자 사이의 힘의 배분을 바꾸는 일이다. 그 재배분이 일어나기 전까지, 다음 벤더의 다음 팝업은 예정된 사건이다.
출처:
- https://videocardz.com/newz/lg-monitors-silently-install-software-through-windows-update-without-user-consent
- https://news.ycombinator.com/item?id=48956688
- https://www.tomshardware.com/software/windows/companies-are-now-using-automatic-windows-installers-to-display-adware-through-the-microsoft-store-when-you-install-new-hardware-customer-immediately-gets-mcafee-ads-on-their-pc-after-connecting-new-lg-monitor-heres-how-to-block-the-new-ads
- https://www.igorslab.de/en/lg-monitors-install-windows-app-mcafee-advertising/
- https://www.privacyguides.org/news/2026/07/17/lg-monitors-caught-installing-adware-and-app-with-access-to-all-system-resources-without-asking/
- https://learn.microsoft.com/en-us/windows-hardware/drivers/develop/dch-principles-best-practices
- https://learn.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app—hsa—steps-for-driver-developers