🎯 [네트워크 자동화 Ep.5] 최종 도달점 — 알림 · 로컬 AI 분석 · GitOps
“매일 아침, 14대 상태가 판정돼 와 있고, 이상은 AI가 한 줄로 요약하는” 상태까지의 로드맵
📋 이 글의 흐름
- 1. 자동화 성숙도 5단계
- 2. 레벨 2 — 이상만 골라 알림
- 3. 레벨 3 — AI 분석, 그리고 로컬 vs 클라우드 선택
- 4. 레벨 4~5 — 안전한 제어와 GitOps
- 5. 효율의 정체 — 무엇이 사라지는가
- 6. 시리즈를 닫으며 — 도구가 아니라 판단력
이 마지막 편은 로드맵과 예상이다. 내가 아직 실습하지 않은 상위 단계까지 포함한다. 다만 앞 편들에서 검증한 수집·판정 파이프라인 위에 자연스럽게 얹히는 구조이며, 각 단계에서 마주칠 핵심 판단 지점(특히 보안)을 미리 짚는다.
1. 자동화 성숙도 5단계
자동 판정 점검표
cron이 매일 플레이북을 돌려, 색상 입힌 엑셀 점검표를 자동 생성. (Ep.4에서 완성) 수동 점검 1~2시간 → 0분.
이상만 골라 알림
정상이면 조용, 이상이면 메신저로 알림. 엑셀을 매일 열 필요도 없어진다. 사람의 일이 “점검”에서 “대응 판단”으로 이동.
AI 분석 레이어
고정 임계치가 못 잡는 “애매한 이상”을 AI가 추세·패턴으로 해석. “MAC flap 5일째 증가, AP 이중연결 의심” 수준의 진단.
안전한 제어 (조회→변경)
VLAN·ACL·NTP 등 설정을 멱등성 있게, 사전검증(–check) 후 일괄 배포. SecureCRT가 따라올 수 없는 영역.
GitOps + 대시보드
모든 설정·점검 로직을 Git에 저장, 변경은 커밋·리뷰 후 배포, 실시간 상태는 웹 대시보드로. “코드로 네트워크를 운영”하는 최종형.
2. 레벨 2 — 이상만 골라 알림
점검 후 “정상이면 침묵, 이상이면 알림”으로 바꾼다. 결과물은 이런 모습이다.
⚠ [일일점검 05-31] 14대 중 1대 이상
• CAMPUS-2F-L2-01(10.20.0.52): VLAN20 MAC flapping 312건/24h
→ 무선 로밍 또는 L2 루프 의심
• 나머지 13대 정상
구현은 Ep.4의 판정 결과에 “이상이 있을 때만 webhook 호출” task를 추가하면 된다. 평소엔 알림이 안 오니 신경 끄고, 오면 그것만 본다. 여기서 사람의 일이 점검에서 대응 판단으로 완전히 이동한다.
3. 레벨 3 — AI 분석, 그리고 로컬 vs 클라우드
고정 임계치(CPU 90%)는 “넘었다/안 넘었다”만 본다. AI를 붙이면 맥락 해석이 더해진다.
🤖 CAMPUS-2F-L2-01 분석: MAC flapping이 5일째 증가 추세
(일 250→312건). 전부 VLAN20, AP포트↔L3업링크 구간.
단순 로밍이 아니라 AP 이중연결 또는 STP 경로 문제 가능성.
권장: Gi1/0/13-15 STP 상태와 해당 AP 무선설정 확인.
점검 데이터에는 장비 호스트명, 내부 IP 대역, MAC 주소, VLAN 구조, 때론 SNMP 커뮤니티·암호 해시까지 들어간다. 회사 네트워크의 내부 구조를 통째로 드러내는 민감 정보다. 이를 클라우드 AI로 보내는 것은 금융·공공·의료·대기업의 보안 정책에 정면으로 걸린다.
| 데이터 성격 | 권장 | 이유 |
|---|---|---|
| 민감 (설정·IP·MAC·로그) | 로컬 AI (Ollama) | 내부망 이탈 금지 |
| 비민감 (학습·문서·코드생성) | 클라우드 AI | 성능·편의 |
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen2.5:7b # 7B 모델 로컬 구동
“이상 로그 해석” 같은 운영 데이터는 로컬에서, 학습이나 플레이북 작성 도움은 클라우드에서. 단 7~8B 로컬 모델은 대형 클라우드 모델보다 분석 깊이가 얕다. 일일점검 이상탐지 수준에는 충분한 경우가 많지만, 더 깊은 분석이 필요하면 GPU 서버나 더 큰 모델이 필요하다.
4. 레벨 4~5 — 안전한 제어와 GitOps
조회를 넘어 설정 변경으로 가면 멱등성의 가치가 폭발한다. “14대에 표준 NTP·SNMP 설정 배포”를 명령 한 줄로 — 이미 설정된 장비는 건드리지 않고(ok), 빠진 장비만 교정(changed)하고 결과를 보고한다.
# --check : 실제 적용 전 "무엇이 바뀔지" 미리 확인 (안전장치)
ansible-playbook -i inventory.yml deploy_ntp.yml --check \
-e 'sw_user=admin sw_pass=... sw_enable=...'
# 확인 후 실제 적용
ansible-playbook -i inventory.yml deploy_ntp.yml \
-e 'sw_user=admin sw_pass=... sw_enable=...'
레벨 5의 GitOps로 가면, 모든 변경이 Git 커밋으로 기록된다. “지난주 누가 sw_52의 VLAN을 바꿨나”가 Git 로그에 다 남고, 누군가 콘솔로 몰래 바꾸면 다음 점검에서 “표준과 다름”이 자동 적발(드리프트 감지)된다.
5. 효율의 정체 — 무엇이 사라지는가
| 작업 | Before (수동/SecureCRT) | After (자동화) |
|---|---|---|
| 일일점검 | 1~2시간 × 매일 | 0분, 이상 시만 확인 |
| 이상 발견 | 로그 안 봐서 놓침 | AI가 추세까지 잡아 알림 |
| 설정 변경 | 장비마다 수동, 실수 위험 | 일괄·멱등·사전검증 |
| 변경 추적 | 기억/메모 의존 | Git에 전부 기록 |
| 규모 확장 | 100대면 50배 노동 | 100대도 명령 한 줄 |
노동량이 장비 수에 비례하던 것(수동)이, 장비 수와 무관해진다(자동). 14대에선 SecureCRT와 체감 차이가 작지만, 이 구조는 140대·1400대에서 그대로 작동한다. 그것이 진짜 차이다.
6. 시리즈를 닫으며 — 도구가 아니라 판단력
이 시리즈는 “머리 좋아지는 법”을 찾다가 시작된 우회로 같은 여정이었다. 코딩 개념 0에서 출발해, 다섯 개의 환경 벽을 넘고, 14대를 자동 점검하고, 그 과정에서 숨어 있던 MAC Flapping까지 발견했다. 그리고 중간에 “SecureCRT로도 되잖아?”라는 의심과 정면으로 마주했다.
2026년 현재, Ansible 플레이북이든 SecureCRT 스크립트든 결국 AI에 흡수되는 방향으로 간다. “5층 무선 느린데 원인 찾아줘”를 자연어로 시키면 AI 에이전트가 점검·분석·진단하는 세계가 오고 있다. 그 세계에서 네트워크 엔지니어의 가치는 “플레이북 작성자”가 아니라, 무엇이 정상이고 무엇이 이상인지 정의하고 AI의 진단을 검증·승인하는 사람”이다.
도구는 바뀐다. Ansible도 언젠가 다른 것으로 대체될 것이다. 하지만 “이 MAC flapping이 이상인가?”를 묻고 판단하는 그 감각 — 그것이 바뀌지 않는 진짜 자산이다. 이 시리즈가 남긴 건 Ansible 문법이 아니라, 그 판단의 근육이다.
이 기록은 고수가 쓴 정답집이 아니라, 입문자가 막히고 의심하며 길을 찾은 과정이다. 당신도 분명 같은 벽들(PATH, kex, 기종 차이)에서 막힐 것이다. 그때 이 시리즈의 해당 편으로 오면 된다. 막히는 건 실패가 아니라, 에러가 달라지는 한 전진이다.
