---
title: "Claude Code를 사용하여 PRTG의 네트워크 장비 모니터링 정의를 Zabbix로 마이그레이션해 보았습니다[후속편]"
description: "Migration / Monitoring # Claude Code를 사용하여 PRTG의 네트워크 장비 모니터링 정의를 Zabbix로 마이그레이션해 보았다[후속편] 이전 UPS 편에 이어, 이번에는 스위치·라우터·무선 AP가 혼재된 환경을 마이그레이션했다. 전체 동일 벤더라는 통일성을 활용하면서, “먼저 등록·나중에 활성화”라는 안전한 절차로 진행했다. Claude Code PRTG Zabbix…"
url: "https://bestnetllc.co.jp/ko/docs/claude-code%eb%a5%bc-%ec%82%ac%ec%9a%a9%ed%95%98%ec%97%ac-prtg%ec%9d%98-%eb%84%a4%ed%8a%b8%ec%9b%8c%ed%81%ac-%ec%9e%a5%eb%b9%84-%eb%aa%a8%eb%8b%88%ed%84%b0%eb%a7%81-%ec%a0%95%ec%9d%98%eb%a5%bc-zabbix/"
updated: "2026-10-19"
category: Tech Blog
---

# Claude Code를 사용하여 PRTG의 네트워크 장비 모니터링 정의를 Zabbix로 마이그레이션해 보았습니다[후속편]

Migration / Monitoring

# Claude Code를 사용하여 PRTG의 네트워크 장비 모니터링 정의를
Zabbix로 마이그레이션해 보았다[후속편]

이전 UPS 편에 이어, 이번에는 스위치·라우터·무선 AP가 혼재된 환경을 마이그레이션했다. 전체 동일 벤더라는 통일성을 활용하면서, “먼저 등록·나중에 활성화”라는 안전한 절차로 진행했다.

  Claude Code PRTG Zabbix SNMP Python

## 이전(UPS 편)과의 차이점

[이전](https://bestnetllc.co.jp/ko/docs/claude-code%eb%a5%bc-%ec%82%ac%ec%9a%a9%ed%95%98%ec%97%ac-prtg%ec%9d%98-ups-%eb%aa%a8%eb%8b%88%ed%84%b0%eb%a7%81-%ec%a0%95%ec%9d%98%eb%a5%bc-30%eb%b6%84-%eb%a7%8c%ec%97%90-zabbix%eb%a1%9c-%eb%a7%88/)에는 전체 APC UPS라는 균일한 구성이었기 때문에, 템플릿을 1종류만 적용하는 것으로 완료되었다. 이번에는 **스위치·라우터·무선 AP**가 혼재된 2023년 백업이 대상이다.

이전(UPS 편)

### 전체 APC UPS

템플릿 1종류·즉시 활성화.
 30분 만에 완료.

이번(네트워크 장비 편)

### 3가지 카테고리 혼재

스위치·라우터·AP로 분류.
 SNMP 통신 확인 후 활성화하는 절차를 채택.

    **전체가 동일 벤더 제품이라는 점이 이번의 강점이었다.** 벤더가 통일되어 있어 템플릿 선정에 고민이 없었다.

## 이번 마이그레이션 대상

PRTG의 2023년 백업(`PRTG Configuration.dat`)을 분석한 결과, 네트워크 장비로서 다음 11대를 마이그레이션 대상으로 선정했다.

스위치(5대)

### 국내 대형 네트워크 벤더 제품

코어 스위치 1대, L2 스위치 4대.
 전체 동일 벤더로 통일되어 있었다.

라우터(2대)

### 엣지 라우터 × 2

프라이머리·세컨더리 구성.
 PRTG에서는 Syslog 센서도 설정되어 있었다.

무선 AP(4대)

### 법인용 무선 AP × 4

각 층·거점에 분산 배치.
 전체 동일 모델.

PRTG의 센서 구성

### 거의 Ping만

44 센서 ÷ 28대 ≈ 1.5개/대.
 SNMP 모니터링이 미설정된 대수가 많았다.

    **PRTG 측의 센서가 거의 Ping만이었기 때문에, SNMP 통신이 가능한지 불명확했다.** 그래서 이번에는 “먼저 Zabbix에 등록·모니터링은 비활성 상태로 보류하고, SNMP 통신 확인 후 개별 활성화”라는 절차를 택했다.

## 사전 준비: Zabbix 서버에 정적 라우트 추가

이번 대상 장비는 모니터링 전용 세그먼트(이하 `x.x.x.0/24`로 표기)에 존재한다. Zabbix 서버에서 이 세그먼트로의 경로가 없었기 때문에, 마이그레이션 작업 전에 정적 라우트를 추가했다.

  **포인트: `nmcli connection up`은 사용하지 않는다.**
 정적 라우트 추가에는 `nmcli connection modify`와 `ip route add`를 병용한다. `nmcli connection up`을 실행하면 인터페이스가 일시적으로 끊기기 때문에, 운영 환경에서는 피해야 한다.

```
# 영구 적용(재시작 후에도 유효)
nmcli connection modify 'System eth1' +ipv4.routes 'x.x.x.0/24 x.x.x.1'

# 즉시 반영(현재 세션만)
ip route add x.x.x.0/24 via x.x.x.1 dev eth1
```

## Claude Code 에 전달한 지시

이번에는 UPS 편의 반성을 살려, **템플릿 매핑 확인에서 반드시 일시 정지시키는** 단계를 지시에 포함했다. UPS 편에서는 전압 임계값 차이로 알림이 오발보했지만, 이번에는 사전 확인으로 그 문제를 방지하는 것이 목표다.

```
PRTG 백업을 분석해서 네트워크 장비를 Zabbix 로 이행해 주세요.
이번에는 스위치·라우터·AP 가 혼재된 환경입니다.

STEP 1: XML 분석. 디바이스를 switch / router / ap / other 로 분류해서 CSV 로 출력.
STEP 2: template.get 으로 템플릿 목록을 취득하고, 매핑 표를 작성해서 확인을 받는다.
        제가 "OK" 라고 답변할 때까지 STEP 3 으로 진행하지 말 것.
STEP 3: 호스트 그룹을 생성하고, 카테고리별로 등록한다.
        ※ 전체 Disabled(모니터링 비활성화)로 등록할 것. SNMP 통신 확인 후 개별 활성화한다.
STEP 4: 차이 확인 리포트를 출력한다.
```

### STEP 2 의 매핑 확인

Claude Code 가 Zabbix API 로 취득한 템플릿 목록을 기반으로, 다음 매핑을 제안했다. 전체가 동일 벤더 제품이므로, 스위치·라우터·AP 는 모두 동일 템플릿으로 문제없었다.

```
switch  → Network Generic Device by SNMP(templateid=10226)
router  → Network Generic Device by SNMP(templateid=10226)
ap      → Network Generic Device by SNMP(templateid=10226)

인터페이스: SNMP v2c / community=public / port=161
등록 상태: Disabled(전체·통신 확인 후 활성화)
```

## 등록 결과

등록 대수

### 11대 모두 성공

에러 제로.
전체 Disabled 상태로 등록 완료.

생성 호스트 그룹

### 3 그룹

Migrated-NW-Switch
 Migrated-NW-Router
 Migrated-NW-AP

### 카테고리별 등록 내역

스위치(5대)

- 코어 스위치 1대
- L2 스위치(PoE 지원)4대

라우터(2대)·AP(4대)

- 엣지 라우터 2대(프라이머리·세컨더리)
- 법인용 무선 AP 4대(각 거점)

## UPS 편과의 비교: 무엇이 달랐나

✅ 동일했던 점

- 백업 XML 의 직접 분석(서버 불필요)
- Claude Code 가 스크립트 생성부터 실행까지 자동
- 호스트 그룹·템플릿의 자동 적용
- 등록 후 차이 리포트 출력

📋 이번에 추가한 것

- 디바이스를 카테고리별로 분류해서 등록
- 템플릿 매핑 확인 단계(일시 정지)
- 전체 Disabled 로 등록(통신 확인 후 활성화)
- 정적 라우트의 사전 추가

## 주의점: Syslog 센서와 SNMP 통신

 **일부 라우터는 PRTG에서 Syslog 센서가 설정되어 있었다.**
 Zabbix에서도 Syslog를 수신하고자 하는 경우, 별도로 Zabbix의 Syslog 수신 설정이 필요하다. 이번에는 등록만 진행하고, Syslog 설정은 남은 작업으로 나중에 미루었다.   **Disabled 등록은 정답이었다.**
 PRTG 쪽 센서가 거의 Ping만이었다는 것은, 기기 측의 SNMP 설정이 미확인 또는 미설정일 가능성이 있다. 모니터링 활성화 전에 기기 측에서 `snmp-server enable`과 커뮤니티 문자열 설정 확인을 수행할 것을 권장한다.

### 활성화 전 확인 체크리스트

- 기기 측에서 SNMP 에이전트가 활성화되어 있는가(`snmp-server enable`)
- 커뮤니티 문자열이 설정되어 있는지 확인(Zabbix 측과 일치하는지)
- Zabbix 서버에서 대상 기기의 UDP/161로 통신이 가능한가
- Zabbix에서 `snmpwalk`로 실제로 응답이 반환되는지 확인

## 현재 상황과 남은 작업

완료

### Zabbix 등록

11대 모두 Disabled 상태로 등록 완료.
 호스트 그룹·템플릿도 적용 완료.

남은 작업

### SNMP 통신 확인 → 활성화

기기 측 SNMP 설정 확인 후,
 1대씩 개별적으로 모니터링을 활성화할 예정.

## UPS 편에서의 개선점

1. **템플릿은 반드시 사전 확인 후 적용한다**
    UPS 편에서는 전압 임계값의 차이로 알람이 오발보되었다. 이번에는 STEP 2에서 반드시 일시정지시켜, 매핑 표를 사람이 확인한 후 진행하는 설계로 변경했다.
2. **통신이 안 되는 기기는 Disabled로 등록한다**
    PRTG의 센서 구성을 보면 SNMP가 설정되지 않은 대수가 많았다. 즉시 활성화하지 않고 “등록만 먼저 완료하고 나중에 확인”하는 절차가 안전하다.
3. **사전 환경 확인을 프롬프트에 포함한다**
    정적 경로 추가 등, 마이그레이션 스크립트 실행 전에 필요한 환경 준비를 프롬프트 서두에 작성해 두면 Claude Code가 확인 단계를 제안해 준다.
4. **카테고리 분류 규칙을 명시한다**
    디바이스명으로부터 카테고리를 추정하게 하는 경우, 명명 규칙(접두사·접미사)을 구체적으로 나열해 두면 분류 정확도가 향상된다.

## 다음 단계

등록한 11대의 SNMP 통신 확인이 완료되면, 순차적으로 모니터링을 활성화해 나갈 것이다. 또한 일부 라우터에 대해서는 Syslog 수신 설정 추가도 검토 중이다.

PRTG 측 센서가 거의 Ping만이었던 기기도, Zabbix의 템플릿을 활용함으로써 CPU 사용률·인터페이스 트래픽·메모리 사용률 등을 추가 비용 없이 모니터링할 수 있게 된다. **마이그레이션은 목표가 아니라, 모니터링 품질을 높이는 출발선이다.**

   사용 도구: Claude Code(Anthropic) / Zabbix 7.x / PRTG Network Monitor 23.x
 작업 환경: Windows 11 + Ubuntu 24.04 (WSL2)
 ※ 기사 내 호스트명·IP 주소는 모두 마스킹 처리되었습니다.