스타벅스에서 WIFI 가 자주 끊길 때 "KT_starbucks_Secure"
오래 시간을 보내야 할 때, 노트북을 들고 스벅에 가끔 가는데, 지점마다 차이는 있지만 WIFI 가 자주 끊긴다는 공통점이 있다.
길게 얘기하면 복잡해서 짧게 말하자면, KT_starbucks_Secure 에 연결하면 문제가 해결된다. 접속시 ID 와 암호 모두 starbucks 이다.
여기까지가 간단한 설명이고, 이 아래에는 필요한 사람들만 보면 된다.
무슨일이 일어나길래?
스벅의 WIFI 서비스는 KT 와 협업으로 제공된다. 보통 WIFI 연결할때 필요한 암호를 직접 설정하지 않고, Captive Portal 이라는 방법으로 입력받는다. 관공서나 학교 등, 불특정 다수의 접근을 제어할 때 사용할 수 있다. 이게 중국은 거의 대부분 Captive Portal 을 사용하는데, 망에 접속할때 신원을 확인해야 하기 때문이다. 중국에서 발행한 핸드폰 번호, 외국인의 경우 여권번호 등을 통해 인증한다.
그럼 한국의 스벅은 대체 왜 Captive Portal 이 있는걸까? 스벅의 WIFI 를 연결하면 가장 먼저 보이는 페이지는, 귀하의 정보가 수집됩니다. 그래서 몇년 가지고 있습니다. 같은 내용이 나오고, 반드시 수락을 눌러야 인터넷 사용이 가능해진다. 카페라는 공간의 특성상 불특정 다수가 이용하고, 인터넷 망을 반드시 제공해야 하는 업장의 특성 때문에 공용망 이용에 대한 법적 고지 및 사용자 식별을 위한 관문(portal) 을 제공한다.
이처럼 Captive Portal 의 중요한 역할 중 하나가, 망에 접속시키기 전에 필요한 절차들을 낑궈넣는 역할을 한다.
지금이야 단순히 수락 버튼으로 간소화 되었지만 몇년 전에는 이름과 전화번호까지 입력해야 하는 때도 있었다. 그러나 외국인에 대해서는 이런식으로 본인 인증을 할 수 없으니, UA 를 한국어가 아닌 것으로 수정해서 외국인을 위한 간소화된 인증 절차로 넘어가는 편법도 있었다. 그래서 지금 수집하는 정보는 클라이언트의 MAC, IP, 호스트네임, OS 종류나 핑거프린트 같은 접속 기기에 대한 정보만 수집한다. (이마저도 불쾌한 사람들이 있기 때문에 최신의 OS 는 접속때마다 MAC 을 변조하는 기능이 생기고 있고, IOS 계열은 아예 이 기능이 기본으로 활성화 되어 있다.)
그럼 대체 왜 끊기나?
그런 의도는 알겠는데, 수시로 WIFI 가 끊기는건 참기가 어렵다. 대체 왜 이렇게 자주 끊기나? 무선 엔지니어가 아니라서 정확히 이유는 모르지만, 몇가지 추측은 해볼수 있다.
원인: Captivle Portal 접속시 설정되는 세션의 유효기간이 빠르게 만료
Captive Portal 을 통해 WIFI 에 접속할 경우 세션이 만료되는 시간이 정해진다. 이는 사용자가 계속 네트워크를 사용하는지 확인하기 위한 조치인데, 보통 30분~1시간 정도로 유효기간이 설정된다.
이 세션의 유효기간이 만료되면 연결을 끊어서 다시 인증절차를 밟아 사용자가 여전히 사용하고 있음을 증명해야 한다. 보통은 사용자 개입없이 갱신 절차가 있어서(Connectivity Check) 내가 끊긴지도 모르게 갱신되지만, 이 세션 만료 기간이 너무 짧게 설정되면 수시로 끊기면서 다시 연결해야 하는 상황이 생긴다.
원인: 프라이버시 기능 때문에 Captive Portal 의 동작이 방해받는 경우
Captive Portal 은 나의 정보를 자동/수동 으로 수집할 수 있는데, 내가 명시적으로 입력하는 정보 말고도 자동으로 수집되는 정보들도 있다. 이런 자동으로 수집되는 정보를 통해, 세션이 만료되더라도 자동으로 세션이 갱신될 수 있다. 그러나 내가 쓰는 장비에 여러가지 프라이버시 기능이 있을 경우, 이런 정보가 보호되어, Captive Portal 입장에서 사용자가 누구인지 파악할 수 없는 경우, 자동 갱신이 실패하기 때문에 수동으로 인증을 다시 해야한다.
세션의 유효기간이 어떤 이유인지 짧게 설정되어 있는데, 프라이버시 기능 때문에 세션의 자동 재갱신도 안되는 상황이라면 계속 WIFI 를 껐다 켜야 하는 상황이 생길것이다.
예를 들어 Adguard 같은 광고차단 소프트웨어를 쓰고 있을 경우, Adguard 의 DNS 암호화(DoT, DoH) 기능을 쓰면 모든 DNS 연결이 보호되며 중간에 가로챌수 없게 된다. 보통 Captive Portal 의 동작 원리가 암호화되지 않은 53/udp 로 지나가는 resolve query 를 가로채서 변조한 다음, Captive Portal 의 대문으로 납치하는 방법을 쓴다. 나는 분명 google 의 주소를 입력했는데, 뜬금없이 WIFI 로그인 화면으로 안내되는것이 이런 이유이다.
이것은 조직 내에서 정확히 의도한 설계이기 때문에, Captive Portal 에서 인증받기 전의 모든 아웃바운드 트래픽은 막히는게 정상이다. 오직 모든 연결은 Captive Portal 을 위한 인증 페이지만 허용되는데 (다른 연결 시도 조차 인증 페이지로 redirect 됨) 만약 보안 소프트웨어가 눈치없게 DNS 쿼리 내용을 암호화해서 외부에서 조작할 수 없게 하거나, 아예 외부 DNS 서버로 계속 접근하려고 시도한다면 정상적인 인증 과정에 실패하게 된다.
만약 너무 자주 wifi 연결이 끊긴다면, 혹시 adguard 같은 (혹은 그에 준하는) 어떤 보안 소프트웨어가 간섭하고 있는게 아닌지 확인해보자.
원인: WIFI 의 신호 간섭
WIFI 의 2.4Ghz, 5Ghz 모두 근거리 통신을 위한 비면허 대역을 사용한다. 비면허 대역이란건 아주 좁근 구역에서 다른 신호와 간섭의 걱정 없이 일반적으로 쓸수 있도록 배정된 주파수 대역으로, 우리가 쓰는 WIFI 말고도 블루투스, Zigbee 등 다양한 프로토콜이 비면허 대역에서 공존한다. 그렇기 때문에 만약 완전히 동일한 대역에서 다수의 장치가 사용하면 간섭이 발생한다. 단적인 예로, 전자레인지도 물분자를 진동하는 주기가 2.4Ghz 이기 때문에 전자레인지가 근처에 있다면 동작시 WIFI 연결이 방해받을 수 있다.
이를 막기 위해 채널 개념이 있어서, 동일한 대역이라도 채널을 빠르게 분리해서 직접적으로 신호가 충돌하는 것을 피한다. 다만 구성시 인근에 강한 신호원이 있다면 이러한 조치도 동작하지 않을 수 있다. 예를 들어 건너편 건물이 경찰청이나 군부대라면 재밍 전파의 영향을 받을수도 있겠다.
특히 Captive Portal 을 쓰는 경우는 별도의 암호화 처리를 하지 않은 신호이기 때문에 더 쉽게 외부 신호와 간섭을 일으켜서 신호가 끊길 수 있다. 적어도 암호화되는 WIFI 연결은 이러한 간섭에 더 강한 저항이 생긴다.
대안: 802.1X 를 통한 보안 WIFI 로의 연결
상기 설명한 것처럼, WIFI 에 접근하려면 Captive Portal 을 사용해야 하는 경우 보안 소프트웨어의 간섭이나, 세션 만료 시간이 잘못 설정되어 있으면 수시로 연결이 끊길 수 있다. 또한 암호 없이 열려있는 WIFI 의 경우 쉽게 다른 신호원에 의해 간섭되어 끊길 수 있다.
그럴땐 KT_starbucks_secure 를 사용하면 802.1x 로 연결 신호가 암호화되어, 외부의 신호 간섭으로 인한 끊김 문제는 해결할 수 있다.
대안: 프라이버시 기능을 잠시 꺼두기
앞서 말했듯, DNS 의 의도적인 오염을 통해 captive portal 이 동작하기 때문에 이를 방해하는 DNS 암호화 등의 방법은 정상적인 로그인이 불가능해진다.
이외로도, VPN 을 사용할 경우 DNS 문제 뿐 아니라, Captive Portal 을 아예 우회해서 외부로 트래픽이 나가기 때문에 captive portal 에 연결할 수 있도록 VPN 의 예외처리가 필요할수도 있다. VPN 을 사용할 경우 captive portal 과의 문제가 제법 발생한다. 정교한 예외처리를 하던가, captive portal 인증 넘어가기 전까지는 잠깐 vpn 끄던가 해야한다.
대안: TLS 의 버전 문제의 해결
이건 좀 좁은 예시이기는 하지만, 명확히 존재하는 문제이기 때문에 언급한다. 보안 연결을 위해 TLS 라는 것을 사용하는데, 보안을 위한 다양한 기능을 제공하는 라이브러리 이다. 보안을 위한 소프트웨어도 버그는 있기 마련이므로, 어떤 버전은 위험하니 쓰지 말라는 권고가 내려오기도 한다. TLS 1.0 이 바로 그렇다. 이 글을 쓰는 현재는 TLS 1.3 이 주로 쓰이며, 보통은 이것만으로도 충분히 동작한다. 문제는 오래된 장비와의 관계이다.
Captive Portal 을 쓰는 상황은, 다수의 불특정한 사용자를 위한 인증 서비스이다. 그러니까 우리 엄마가 될수도 있고, 건넛집 초등학생 일수도 있다. 이 사람들의 모든 기기가 최신 기기가 아닐것이고, 항상 업데이트가 안되어 있을 것이다. 보안 권고 떨어진지가 벌써 수년이 흘렀지만, 업데이트 한번 없이 사용하는 사람들이 우리 세상의 대부분이다. (잘못되었다고 말하는게 아니라, 현실이 그렇단 얘기다)
서비스를 제공하는 스벅이나 KT 같은 경우, 이 모든 경우의 수를 품어야 하기 때문에 어쩔수 없이 보안상 문제가 있음을 알더라도 모든 경우의 수를 준비할 수밖에 없다. Captive Portal 에서 구형 TLS 1.0 부터 TLS 1.3 까지 모두 준비를 해서, 접속해 오는 기기와 협상하여 적용할수 있도록 해야한다. 문제는, 이러한 인프라도 쉽게 바꿀 수 없는 것들이기 때문에 최신 보안 권고를 미처 적용하지 못할 수 있다. TLS 1.3 써야하는거 누가 모르나, 그러나 전국의 스벅에 일괄적으로 적용할수 없는 상황일수 있다는 얘기다.
그래서 내 컴퓨터에서 접속할때 이런 에러가 발생했다.
2026-02-18T18:34:41.354359+09:00 gogunbuntu NetworkManager[3218]: <info> [1771407281.3541] device (p2p-dev-wlp4s0): supplicant management interface state: associating -> associated
2026-02-18T18:34:41.366570+09:00 gogunbuntu wpa_supplicant[3221]: wlp4s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 -> NAK
2026-02-18T18:34:41.384564+09:00 gogunbuntu wpa_supplicant[3221]: wlp4s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
2026-02-18T18:34:41.384648+09:00 gogunbuntu wpa_supplicant[3221]: wlp4s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
2026-02-18T18:34:41.396403+09:00 gogunbuntu kernel: wlp4s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 06:09:b4:79:6f:d4
2026-02-18T18:34:41.403716+09:00 gogunbuntu wpa_supplicant[3221]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
2026-02-18T18:34:41.403828+09:00 gogunbuntu wpa_supplicant[3221]: OpenSSL: openssl_handshake - SSL_connect error:0A000102:SSL routines::unsupported protocol
2026-02-18T18:34:41.422431+09:00 gogunbuntu wpa_supplicant[3221]: wlp4s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed중간에 보이는 SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version 에러로 보아, 보안 연결을 시도하던 중 스벅에 설치된 KT 의 Radius 장비와 TLS 협상에 실패하여 이후의 모든 절차가 취소되었다.
계속해서 보안 라이브러리는 최신 OS 에서 업데이트 되고 있고, 일부 OS 에서는 아예 문제있는 보안 라이브러리를 비활성화 하여 사용할 여지를 줄이고 있다. (대부분 흔히 쓰는 OS 에서는 최대한의 호환성을 위해 보안상 위험이 있더라도 일단 동작을 하도록 남겨둔다.)
내가 사용하는 리눅스(Ubuntu 25.10) 에서는 TLS 1.0 에 대해서 비활성화 되어 있었고, TLS 1.3 부터 들이밀기 때문에 협상이 단절된 것으로 보인다.
이에, NetworkManager 의 설정을 통해, KT_starbucks_Secure 에 한정해서 TLS 1.0 을 사용하도록 다음과 같이 구성하였다.
# 설정 변경
sudo nmcli connection modify "KT_starbucks_Secure" 802-1x.phase1-auth-flags 0x30
# 변경 확인
nmcli -f 802-1x.phase1-auth-flags connection show "KT_starbucks_Secure"NetworkManager 에 한정해서 설명했지만, 다른 시스템에서도 비슷한 기능이 있을 것이다.
대안: 스마트폰을 유선으로 연결하여 핫스팟(인터넷 공유)하는 방법
다른 대안으로는 스마트폰의 핫스팟 기능을 활용하는 것이다. 스마트폰에 연결된 WIFI 의 인터넷을 USB 케이블로 원하는 장치 1개에 공유하는 방법이다. 공유받는 PC 입장에서는 이 연결이 "유선 연결" 로 취급되므로, 상기 나열한 모든 원인을 우회할 수 있고 아무 수정을 하지 않아도 된다. 가장 깔끔한 방법.
다만, 이 방법을 쓰려면 몇가지 단서가 있다.
- 적어도 스마트폰은 스벅 WIFI 에 안정적으로 물려 있을것 (안끊기고)
- 스마트폰과 PC 간에 USB 케이블로 연결되어 있을것. (1대 이상 연결 불가)
"이번달 나 모바일 트래픽 거의 다 써서 핫스팟 물리면 안되는데?" 싶겠지만, 요즘 스마트폰의 경우에는 연결된 WIFI 망을 그대로 USB 를 통해 PC 나 태블릿에게 제공하는 기능이 있다. 일종의 공유기 처럼 동작한다. (실제로 내부에 동작하는 프로세스는 비슷하다)
물론, WIFI 를 통해 인터넷 공유가 가능하다. 이미 스마트폰이 WIFI 안테나를 통해 인터넷에 연결되어 있더라도, 공유된 신호를 다른 주파수로 재공유가 가능하다. 문제는, 이 방법으로는 모바일 트래픽까지 끌어 사용될 수 있다는게 문제다. 스마트폰이 WIFI, 유선랜, 모바일(LTE) 등이 연결되어 있을때 핫스팟을 켜면 순위가 높은 유선랜과 WIFI 를 통해 연결된 네트워크를 재공유 하지만, 만에 하나 이들 연결이 모르는 사이 끊어지면 모바일(LTE) 트래픽이 공유되게 된다. 이를 막기 위해서는 USB 케이블을 통해 공유하고, "모바일 핫스팟" 옵션을 아예 꺼버리면 된다.
갤럭시 안드로이드를 기준으로 설명하자면, 다음과 같다.
- 스마트폰을
KT_starbucks_secure에 연결하고, 연결이 끊기지 않는지 확인 - 스마트폰과 PC 를 USB 케이블로 연결 (이때, 스마트폰에서는 암호를 입력하는 창이 뜨고, PC에서는 이 연결을 신뢰하겠냐는 질문이 뜨는데, 둘다 정확히 입력해줘야 함)
- 만약 USB 케이블이 적합하지 않거나, 암호를 잘못 입력했거나, 신뢰하지 않는다고 대답했다면 스마트폰은 단순히 충전 모드가 되어 USB 를 통한 핫스팟이 연결되지 않음
- 설정 ➔ 연결 ➔ 모바일 핫스팟 및 테더링 ➔ USB 테더링 만 활성화 하고, 모바일 핫스팟 을 포함해 나머지를 모두 끌것.
- 왜 "모바일 핫스팟" 을 끄냐면, 기본적으로 스마트폰의 핫스팟은 현재 연결된 가장 순위가 높은 연결을 공유하는데, 만에 하나 KT_starbucks 에 연결된 WIFI 가 끊길경우 자동으로 LTE 모바일 트래픽을 핫스팟으로 공유하기 때문입니다. 스마트폰과 스벅의 WIFI 가 끊긴지도 모르고 신나게 유튜브 몇편 보면 그 달의 모바일 트래픽을 모두 소진하게 됩니다. (무제한이라도 QoS 한계에 도달하는 영향이 있음)
- 이 모든 절차가 정상적이라면, PC 에서는 마치 유선랜카드가 연결된 것처럼 연결 아이콘이 뜹니다. 스마트폰만 정상적으로 WIFI 에 연결되어 있다면, PC 에서도 안정적으로 연결을 유지할 수 있습니다.
끝으로
사실 스마트폰은 굉장히 훌륭하고 안정적인 모바일 공유기 역할을 하기도 합니다. 다이소에서 3천원짜리 랜포트가 달린 USB-C 허브를 가지고 다닌다면, 스마트폰을 유선 공유기처럼도 사용할 수 있습니다.
다만 스마트폰의 특성상 들고 이동하는 경우가 많기 때문에, 공유기처럼 안정적으로 쓰기는 어렵지만, 블루투스 이어폰으로 통화한다는 전제로 간단한 데스크 셋업에서는 꽤 쓸만합니다.