카페 Wi-Fi 느린 이유는 무엇일까? 카페 네트워크 분석 기록

카페에서 작업을 하다보면 왠지 "와이파이가 느린 것 같은데?" 싶은 순간들이 생긴다.

그런데 정말 느린 걸까? 아니면 그냥 기분 탓일까?

 

이번 글에서는 카페 Wi-Fi에 직접 연결해서 네트워크 품질을 측정하고, AP 구조까지 분석해보는 과정을 정리해본다.

 

 

1. AP(Acess Point)란 무엇일까?

- Wi-Fi 신호를 뿌리는 장치

- 반도체를 포함한 "완제품 네트워크 장비"

- 내부에는 Wi-Fi 칩셋, CPU, 메모리, LTE 모뎀 등이 들어 있을 수 있다.

 

그럼 내가 사용 중인 AP는 어떤 장비일까?

먼저 노트북에서 ipconfig 명령어를 실행해보자.

IPv4 주소: 172.30.1.87
기본 게이트웨이: 172.30.1.254

 

여기서 중요한 점은 IP 대역이다.

- 192.168.x.x > 가정용 광랜 공유기

- 172.30.x.x   > LTE 기반 AP (핫스팟형 구조)

 

카페에서 이런 IP가 나왔다면, "실제 유선 인터넷이 아니라 LTE/5G 네트워크를 쓰는 공유기"라는 의미이다.

 

요즘 소규모 카페에서는 회신을 따로 깔지 않고 데이터 유심 + LTE 라우터를 사용하는 경우도 많다고 한다.

 

 

 

---

 

 

 

2. LTE 백홀 AP 구조 이해하기

LTE 백홀 AP 구조를 이해하기 전에 간단히 개념부터 정리하자.

 

LTE 백홀 AP 란?

- 인터넷을 유선(광랜) 대신 LTE/5G 네트워크로 받아오는 AP

- 카페 · 편의점 · 소규모 매장에서 자주 사용

- 내부 IP 주소 대역이 보통 172.30.x.x

- 성능은 LTE 기지국 수신 품질에 크게 좌우 된다.

 

LTE 기반 AP는 일반 공유기와 다르게 다음과 같은 구조로 동작한다.

(1) LTE 기지국

> (2) 통신사 Core 망

> (3) LTE 모뎀 칩셋

> (4) 라우터 CPU/NAT 처리

> (5) Wi-Fi 칩셋 (SSID 제공)

> (6) 내 노트북

 

즉, 유선 회선이 없고, 핫스팟처럼 무선으로 인터넷을 끌어오는 방식이다. 이 구조로 인해 172.30.x.x 같은 내부 IP가 나온다.

 

 

---

 

 

 

3. 네트워크 품질 측정 (ping, tracert, pathping)

(1) AP 까지 ping 테스트

Ping 172.30.1.254 – 평균 1ms / 손실 0%

> Wi-Fi 연결은 매우 안정적이다.

 

평가 기준

지연(latency)의 기준

- 1~5ms > 매우 안정적 (기기와 AP 간 무선 상태 아주 좋음)

- 5~20ms > 양호 (카페/공공장소에서 흔함)

- 20~50ms > 불안정 가능성 (신호 약함, 간섭 발생)

- 50ms 이상 + 패킷 손실 발생 > 문제 있음

 

AP는 바로 옆에 있는 장비이므로 정상적이라면 5ms 내가 일반적이고, 10ms 이상이면 Wi-Fi 간섭(전자레인지, 블루투스, 벽, 거리 증가 등) 발생 가능성이 있다. 그리고 패킷 손실은 단 1%라도 체감 속도에 영향을 준다. 특히나 WeTRC/ 게임 등에서는 확실히 느낄 수 있게 된다.

 

 

(2) 인터넷까지 ping 테스트 (8.8.8.8 - 구글)

평균 37ms / 손실 0%

> 국내망 기준으로 아주 양호한 수준이다.

 

국내망 기준 지연(latency) 평가 (구글 DNS는 서울/도쿄에 노드가 있어서 국내 기준으로 적절하다)

- 10~30ms > 매우 빠름 (유선 광랜 수준)

- 30~60ms > 양호 (LTE/5G 기반 AP의 현실적 평균)

- 60~100ms > 느림 (기지국 부하, 전파 간섭, 거리 문제)

- 100ms 이상 > 지연체감 가능

- 200ms 이상 > 사용자가 확실히 체감 

 

패킷 손실(loss)의 기준

- 0% > 정상

- 1~2% > 경계

- 3% 이상 > 작업용으로 부적합 (영상통화, VPN, 게임에서 문제)

- 5% 이상 > 명백히 네트워크 불안정

 

(3) 경로 추적 (tracert)

2번, 5번 홉 응답 없음 (통신사 내부망에서 ICMP 차단)
나머지는 정상 연결

> LTE 기반 AP에서 매우 흔한 현상

 

 

 

---

 

 

 

4. Python 으로 네트워크 진단

import subprocess
import time
import requests
 
GATEWAY = "172.30.1.254"   
TARGET_IP = "8.8.8.8"
TARGET_URL = "https://www.google.com"
 
def ping(host, count=4):
    # 윈도우 기준 ping -n, 리눅스/맥이면 -c로 바꿔야 함
    result = subprocess.run(
        ["ping", "-n", str(count), host],
        capture_output=True,
        text=True
    )
    return result.stdout
 
def test_http(url):
    start = time.time()
    r = requests.get(url, timeout=5)
    elapsed = (time.time() - start) * 1000  # ms
    return r.status_code, elapsed
 
def main():
    print("=== 1. AP(게이트웨이)까지 테스트 ===")
    print(ping(GATEWAY))
 
    print("=== 2. 인터넷(8.8.8.8)까지 테스트 ===")
    print(ping(TARGET_IP))
 
    print("=== 3. 웹 요청 테스트 ===")
    try:
        status, elapsed = test_http(TARGET_URL)
        print(f"{TARGET_URL} 상태 코드: {status}, 응답 시간: {elapsed:.1f} ms")
    except Exception as e:
        print("HTTP 요청 실패:", e)
 
if __name__ == "__main__":
    main()

 

 

결과

=== 1. AP(게이트웨이)까지 테스트 ===
 
Ping 172.30.1.254 32바이트 데이터 사용:
172.30.1.254의 응답: 바이트=32 시간=1ms TTL=64
172.30.1.254의 응답: 바이트=32 시간=2ms TTL=64
172.30.1.254의 응답: 바이트=32 시간=1ms TTL=64
172.30.1.254의 응답: 바이트=32 시간=1ms TTL=64
 
172.30.1.254에 대한 Ping 통계:
    패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
    최소 = 1ms, 최대 = 2ms, 평균 = 1ms
 
=== 2. 인터넷(8.8.8.8)까지 테스트 ===
 
Ping 8.8.8.8 32바이트 데이터 사용:
8.8.8.8의 응답: 바이트=32 시간=37ms TTL=112
8.8.8.8의 응답: 바이트=32 시간=38ms TTL=112
8.8.8.8의 응답: 바이트=32 시간=38ms TTL=112
8.8.8.8의 응답: 바이트=32 시간=38ms TTL=112
 
8.8.8.8에 대한 Ping 통계:
    패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
    최소 = 37ms, 최대 = 38ms, 평균 = 37ms
 
=== 3. 웹 요청 테스트 ===
https://www.google.com 상태 코드: 200, 응답 시간: 520.2 ms
 

 

 

 

 

---

 

 

 

결과: 작업용으로 충분히 쓸 수 있는 안정적인 Wi-Fi 였으며, LTE 기반이지만 품질은 양호한 편이다.