UDM Pro 문제 해결: WAN 불안정과 메모리 누수 디버깅

홈랩을 오래 굴리다 보면 제일 사람을 지치게 하는 순간이 있습니다. 분명 인터넷은 들어오는데 체감이 끊기는 것 같고, 화상회의는 순간적으로 튀고, 게임 핑은 갑자기 치솟고, 로그를 보면 또 멀쩡해 보이는 상황이요. 저도 UniFi Dream Machine Pro(UDM Pro)를 메인 라우터로 쓰면서 이런 일을 꽤 겪었습니다. 특히 UDM Pro 문제 해결이 필요한 순간은 보통 한 번에 오지 않더라고요. WAN 불안정과 리소스 누적이 겹치면서, 겉으로는 회선 문제처럼 보이는데 실제로는 장비 내부 상태가 원인인 경우가 있었습니다.

처음엔 ISP 회선부터 의심했습니다. 저도 늘 그랬거든요. 근데 며칠 단위로 패턴을 기록해 보니까, 회선 자체보다는 UDM Pro 내부 메모리 사용량이 점점 올라가고 특정 시점부터 UI 반응과 WAN 품질이 같이 나빠지는 흐름이 보였습니다. 여기서 중요한 포인트는 WAN 불안정과 메모리 누수를 따로 봐서는 안 된다는 거예요. 오늘 글은 제가 실제로 홈랩 라우터를 디버깅할 때 쓰는 순서대로 정리해보겠습니다.

UDM Pro를 중심으로 WAN, 스위치, 서버, 클라이언트가 연결된 홈랩 구조를 한눈에 보여주는 개요 이미지입니다.

1. 왜 UDM Pro 문제 해결이 까다로운가

쉽게 말해 라우터 문제는 증상이 거짓말을 많이 합니다. 인터넷이 순간적으로 느려지면 다들 WAN부터 의심하지만, 실제로는 NAT(Network Address Translation, 주소 변환), IDS/IPS(Intrusion Detection/Prevention System, 침입 탐지/차단), 로그 적재, 컨트롤러 프로세스 같은 내부 요소가 먼저 흔들리는 경우가 있습니다.

특히 UniFi UDM Pro는 라우터, 컨트롤러, 보안 게이트웨이 역할이 한 장비에 묶여 있거든요. 이 구조는 편합니다. 정말 편해요. 근데 한쪽 리소스가 밀리면 다른 기능에도 영향을 줄 수 있어요. 제가 직접 해보니 이런 식으로 연결되더라고요.

• 메모리 사용량이 계속 올라감
• 관리 UI 반응 속도가 둔해짐
• 세션 처리나 DPI(Deep Packet Inspection, 패킷 심층 분석) 쪽이 무거워짐
• WAN 지연시간과 패킷 손실이 간헐적으로 튐
• 사용자는 그냥 인터넷이 끊긴다고 느끼게 됨

그래서 네트워크 디버깅은 증상보다 흐름을 봐야 합니다. 한 번의 속도 측정으로 끝내면 안 되고, 시간 축으로 기록해야 하죠.

2. WAN 불안정과 메모리 누수를 어떻게 구분할까

저도 처음엔 헷갈렸는데, 기준을 세워두면 생각보다 빨리 갈립니다. WAN 쪽 문제인지, 장비 내부 문제인지 대략 아래처럼 분류할 수 있어요.

재부팅 후 한동안 멀쩡하다가 다시 나빠진다면, 저는 거의 무조건 메모리와 프로세스 상태부터 봅니다. 반대로 장비는 멀쩡한데 ISP 게이트웨이까지 핑이 튄다면 회선 쪽일 확률이 높더라고요.

3. 먼저 확인할 최소 체크리스트

본격적으로 SSH 붙기 전에, 저는 아래 순서부터 확인합니다. 괜히 깊이 들어가기 전에 큰 원인을 먼저 쳐내는 거죠.

1. 인터넷 회선 장애 공지가 있는지 확인합니다.
2. 광모뎀 또는 상위 모뎀의 링크 상태가 변한 적 있는지 봅니다.
3. UDM Pro의 WAN 포트 협상 속도와 케이블 상태를 확인합니다.
4. 최근 설정 변경 사항, 특히 IDS/IPS, Smart Queue, Traffic Identification 관련 변경이 있었는지 봅니다.
5. 문제가 생기는 시간대가 백업, 카메라 업로드, 대용량 동기화 시간과 겹치는지 체크합니다.

여기서 중요한 포인트! 설정 변경 이력을 꼭 보셔야 합니다. 홈랩은 특히 제가 직접 건드린 게 원인인 경우가 많았거든요. 삽질 좀 했습니다 ㅎㅎ

4. 실전 1단계: UDM Pro에서 기본 상태 확인

이제 SSH로 들어가서 최소한의 상태를 봅니다. 특정 버전 의존적인 명령보다는 범용 Linux/BusyBox 계열 명령 위주로 접근하는 게 안전하더라고요.

ssh admin@udm-pro-ip
uptime
free -m
top
df -h
dmesg | tail -n 50
ping -c 20 1.1.1.1
ping -c 20 8.8.8.8

제가 실제로 써보니까 여기서 바로 감이 오는 경우가 많았습니다.

• uptime: 장비가 얼마나 오래 켜져 있었는지 확인해요.
• free -m: 메모리 사용량과 여유 메모리를 봅니다.
• top: 어떤 프로세스가 CPU/메모리를 계속 먹는지 봐요.
• dmesg: NIC(Network Interface Card, 네트워크 인터페이스) 오류나 커널 메시지를 확인합니다.
• ping: 외부 목적지까지 손실과 지연 변동이 있는지 빠르게 확인해요.

만약 이 시점에 관리 UI도 느리고, 메모리 여유가 비정상적으로 줄어 있다면 회선보다 내부 상태를 더 의심해볼 만합니다.

SSH 터미널에서 uptime, free, top, ping 결과를 확인하며 UDM Pro 문제의 원인을 좁혀가는 장면을 보여주는 이미지입니다.

5. 실전 2단계: 외부 모니터링으로 WAN 불안정을 잡아내기

라우터 안에서만 보면 놓치는 게 있습니다. 그래서 저는 항상 별도 리눅스 장비나 NAS, 미니 PC 하나에서 외부 모니터링을 같이 돌립니다. 이게 진짜 중요합니다. 라우터가 힘들어하는 순간에도 바깥에서 본 기록이 남거든요.

아래처럼 간단한 bash 스크립트를 하나 돌려두면 packet loss와 latency 변화를 시간대별로 남길 수 있습니다.

#!/usr/bin/env bash
TARGETS=("1.1.1.1" "8.8.8.8")
LOGFILE="/var/log/wan-check.log"

while true; do
  TS=$(date "+%Y-%m-%d %H:%M:%S")
  for target in "${TARGETS[@]}"; do
    RESULT=$(ping -c 5 -W 2 "$target" | tail -n 2 | tr '\n' ' ')
    echo "$TS target=$target $RESULT" >> "$LOGFILE"
  done
  sleep 60
done

이 로그를 보면 재미있는 패턴이 보여요. 문제가 생긴 시간에 모든 대상이 동시에 튀면 WAN 또는 라우터 공통 구간 문제일 가능성이 높고, 특정 대상만 흔들리면 외부 경로 문제일 수도 있습니다.

좀 더 정리하면 이런 기준으로 보면 됩니다.

1. 모든 외부 대상 핑이 동시에 튄다: UDM Pro 또는 회선 공통 구간 의심
2. 관리 UI가 동시에 느려진다: 내부 리소스 문제 가능성 상승
3. 재부팅 후 그래프가 초기화되듯 좋아진다: 메모리 누적 문제 가능성 상승
4. 특정 시간에만 튄다: 스케줄 작업이나 트래픽 폭증 의심

6. 실전 3단계: 메모리 누수처럼 보일 때 제가 확인한 포인트

이 부분은 조심해서 봐야 해요. 엄밀히 말하면 모든 메모리 증가가 곧바로 leak(누수)인 건 아니거든요. Linux 계열 시스템은 캐시를 적극적으로 쓰기 때문에, 숫자만 보고 결론 내리면 안 됩니다. 저도 처음엔 숫자 보고 깜짝 놀랐는데, 실제로는 캐시(cache)와 프로세스 실제 점유 메모리(resident memory)를 같이 봐야 하더라고요.

제가 주로 보는 패턴은 이렇습니다.

• 특정 프로세스의 메모리 점유가 시간에 따라 계속 증가하는가
• 관리 기능이 느려지는 시점과 메모리 증가 시점이 겹치는가
• 재부팅 또는 관련 기능 비활성화 후 증상이 사라지는가
• DPI, IDS/IPS, 트래픽 통계 같은 부가 기능과 상관관계가 있는가

여기서 너무 공격적으로 설정을 다 꺼버리면 원인 파악이 안 돼요. 저는 보통 한 번에 하나씩만 바꿉니다. 예를 들면 이런 순서죠.

1. 트래픽이 많은 시간대를 기록합니다.
2. 그 시간대 직전과 직후의 메모리 상태를 비교합니다.
3. 부가 기능을 하나만 조정합니다.
4. 24시간에서 72시간 정도 추세를 다시 봅니다.

이 방식이 느려 보여도 제일 덜 헤맵니다. 한꺼번에 다 바꾸면 드디어 됐다 싶다가도 뭐가 원인이었는지 모르게 끝나거든요.

기능별 점검 포인트

7. ⚠️ 제가 실제로 겪었던 흔한 함정

이 섹션은 꼭 넣고 싶었어요. 문서만 보면 안 보이는 부분이 있거든요.

첫 번째 함정은 케이블과 링크 협상입니다. WAN 불안정이라고 해서 무조건 소프트웨어 문제는 아닙니다. 애매하게 손상된 케이블이나 포트 접점 문제는 정말 사람 미치게 합니다. 핑이 항상 나쁜 게 아니라 간헐적으로만 튀니까요. 저는 예전에 라우터 설정만 계속 들여다보다가, 결국 상위 모뎀과 UDM Pro 사이 케이블 교체로 증상이 크게 줄어든 적도 있었습니다.

두 번째는 재부팅 효과를 과대평가하는 것입니다. 재부팅 후 괜찮아졌다고 해서 원인이 사라진 건 아니에요. 단지 증상이 초기화된 걸 수 있거든요. 특히 UDM Pro 문제 해결에서 이 패턴이 자주 보입니다.

세 번째는 로그 없이 기억에 의존하는 것입니다. 사람 기억은 생각보다 부정확합니다. 저는 이제 무조건 시간 기록부터 남깁니다. 끊긴 시간, 어떤 서비스가 영향받았는지, 그때 내부 UI가 느렸는지까지 같이 적어두면 나중에 원인 분리가 쉬워져요.

네 번째는 기능을 너무 많이 켜두는 것입니다. 홈랩 라우터는 만능처럼 보여도 결국 자원은 유한합니다. 기능을 켜는 건 쉽지만, 디버깅은 어려워집니다.

메모리 사용량 증가와 외부 핑 지연 상승이 같은 시점에 나타나는 대시보드 형태의 결과 시각화 이미지입니다.

8. 검증: 문제를 해결했다고 판단하는 기준

해결은 느낌으로 하면 안 됩니다. 이 부분은 인프라 쪽에서 특히 중요하죠. 저는 아래 기준을 만족해야 해결로 봐요.

1. 24시간 이상 외부 대상 핑 손실이 안정적일 것
2. 관리 UI 반응 속도가 이전보다 일관될 것
3. 메모리 사용량 추세가 비정상적으로 계속 상승하지 않을 것
4. 문제 시간대에도 WAN 지연이 급격히 튀지 않을 것
5. 사용자 체감 이슈가 재현되지 않을 것

가능하면 before/after를 직접 남겨보세요. 예를 들어 설정 조정 전후로 다음 항목을 비교하면 좋습니다.

date
uptime
free -m
ping -c 20 1.1.1.1
ping -c 20 8.8.8.8
dmesg | tail -n 20

그리고 간단한 점검표도 추천드립니다.

이렇게 남겨두면 다음에 비슷한 문제 생겨도 훨씬 빨라져요. 저는 이 기록 덕분에 두 번째부터는 훨씬 덜 헤맸습니다.

9. 정리: UniFi UDM Pro 디버깅은 순서가 전부입니다

정리하면, UniFi UDM Pro에서 보이는 WAN 불안정은 회선 문제처럼 보여도 장비 내부 리소스 이슈와 연결되는 경우가 꽤 있어요. 특히 장시간 운영 후 느려지고, 재부팅 후 잠시 좋아지고, 관리 화면까지 버벅인다면 메모리와 프로세스 상태를 꼭 같이 보셔야 합니다. 제가 직접 해보니 핵심은 복잡한 기술보다도 순서 있게 분리해서 보는 습관이더라고요.

• 회선과 내부 리소스를 분리해서 확인하기
• 외부 모니터링 로그 남기기
• 기능은 한 번에 하나씩만 조정하기
• 재부팅 전후를 반드시 기록하기

혹시 이런 경험 있으신가요? 멀쩡하던 홈랩 라우터가 며칠 지나면 이상하게 답답해지는 그 느낌이요. 저도 처음엔 이게 뭔가 싶었는데, 결국 기록과 비교가 답이었어요. 다음 글에서는 UniFi 환경에서 VLAN(Virtual LAN, 가상 랜) 분리와 모니터링 기준을 어떻게 잡는지 이어서 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 기본 세그먼트 설계 내용과 함께 보시면 더 이해가 잘 되실 거예요.

회선 점검, SSH 확인, 외부 모니터링, 검증 단계까지 한 장으로 정리한 요약 인포그래픽 이미지입니다.

자주 묻는 질문

Q1. 메모리 사용량이 높으면 무조건 메모리 누수인가요?

아닙니다. 캐시 사용 때문일 수 있습니다. 중요한 건 시간에 따라 특정 프로세스가 계속 증가하는지, 그리고 그 증가가 실제 장애 증상과 연결되는지예요.

Q2. WAN 불안정이면 바로 ISP에 문의해야 하나요?

바로 문의해도 되지만, 가능하면 먼저 외부 핑 기록과 라우터 내부 상태를 같이 확보해두세요. 문의 품질이 달라집니다.

Q3. 홈랩 라우터에서 기능을 많이 켜면 무조건 안 좋은가요?

무조건은 아닙니다. 다만 IDS/IPS, DPI, 큐잉 같은 기능은 자원 사용량과 체감 성능 사이 균형을 봐야 합니다. 목적 없는 활성화는 디버깅 난이도만 올릴 수 있어요.