지금까지 우리는 파이썬과 앤서블(Ansible), 그리고 New Central API를 무기로 네트워크 자동화의 핵심 요소들을 하나씩 정복해 왔습니다. 하지만 실무 환경에서 스크립트 파일 몇 개를 개인 PC에 가지고 있는 것만으로는 진정한 자동화라고 할 수 없습니다.
시리즈의 마지막인 오늘, 우리는 코드가 어떻게 기업의 비즈니스 전략(ITSM)과 융합되고, 최신 AI 기술과 만나 스스로 진화하는 네트워크(AIOps)로 거듭나는지 그 ‘큰 그림’을 그려보겠습니다.
1. 네트워크 운영에 ITIL 5와 CI/CD가 필요한 이유
엔터프라이즈 환경에서 가장 중요한 것은 ‘안정성’과 ‘추적 가능성’입니다.
개발자들이 소스 코드를 관리하듯, 인프라 환경 역시 IaC(Infrastructure as Code)로 관리되어야 합니다.
- 버전 관리 (Git): 3강에서 만든 스위치 VLAN 설정 코드를 Git에 올립니다. “누가, 언제, 왜 네트워크 구성을 바꿨는지” 완벽한 이력 추적이 가능해집니다. 이제 코드가 곧 네트워크의 ‘설계도’이자 ‘이력서’가 됩니다.
- CI/CD 파이프라인 연동: 코드가 수정(Commit)되면, GitLab이나 GitHub Actions가 자동으로 문법을 검사하고 테스트 망에 먼저 배포합니다.
2. [아키텍처] CI/CD 기반 네트워크 배포 워크플로우
전체적인 흐름은 소프트웨어 개발 프로세스와 완벽하게 동일합니다.
- Plan & Code: 엔지니어가 VS Code에서 새로운 VLAN 추가 코드를 작성합니다.
- Commit & Push: 변경된 코드를 사내 Git 저장소에 푸시합니다.
- Review & Merge: 시니어 엔지니어가 코드를 리뷰하고 승인(Approve)합니다.
- CI/CD Pipeline 연동: 코드가 병합되면 GitHub Actions 또는 GitLab CI가 작동합니다.
- Deploy (CD): 파이프라인 내의 격리된 환경(Runner)에서
ansible-playbook명령어가 자동으로 실행되어 Aruba CX 스위치에 반영됩니다.
3. [실전 예제] GitHub Actions로 Ansible 배포 자동화하기
3강에서 작성했던 앤서블 플레이북을 GitHub Actions를 통해 자동 배포하는 간단한 파이프라인 설정 파일(.github/workflows/deploy_network.yml) 예시입니다.
name: Deploy Aruba CX Network Config
# 'main' 브랜치에 코드가 푸시될 때만 이 파이프라인이 실행됩니다.
on:
push:
branches:
- main
jobs:
deploy-to-switches:
runs-on: ubuntu-latest
steps:
# 1. 저장소의 코드를 러너(Runner)로 가져옵니다.
- name: Checkout Code
uses: actions/checkout@v3
# 2. 파이프라인 환경에 앤서블을 설치합니다.
- name: Install Ansible
run: |
sudo apt update
sudo apt install -y ansible
# 3. Aruba CX 스위치 제어를 위한 Ansible Collection을 설치합니다.
- name: Install Aruba CX Collection
run: ansible-galaxy collection install arubanetworks.aos_cx
# 4. 실제 스위치에 설정을 배포합니다. (보안을 위해 패스워드는 GitHub Secrets 사용)
- name: Run Ansible Playbook
env:
ANSIBLE_HOST_KEY_CHECKING: "False"
run: |
ansible-playbook -i inventory.ini vlan_setup.yml \
-e "ansible_password=${{ secrets.ARUBA_SWITCH_PASSWORD }}"이 파이프라인이 구축되면, 여러분은 더 이상 스위치에 직접 접속할 필요가 없습니다. 오직 코드만 수정하고 푸시(Push)하면 됩니다.
4. 에반젤리스트의 인사이트: ITIL 5와 NetOps의 조화
네트워크에 CI/CD를 도입하는 것은 단순한 기술적 유행이 아닙니다.
이는 기업의 ITSM(IT 서비스 관리) 및 ITIL 5 프레임워크와 강력하게 결합됩니다.
ITIL 5의 핵심인 ‘변경 관리(Change Enablement)’ 프로세스를 생각해 보세요.
Git의 ‘Pull Request’가 곧 변경 승인 요청서가 되고, 승인된 코드가 CI/CD를 통해 배포되는 과정 자체가 완벽한 변경 통제 프로세스입니다. 만약 장애가 발생한다면? Git에서 ‘Revert(되돌리기)’ 버튼 하나만 누르면 이전 네트워크 상태로 즉시 롤백됩니다.
이것이 비즈니스 안정성과 IT 민첩성을 동시에 달성하는 진정한 자동화 생태계입니다.
DevNet 시리즈를 마치며..
자동화는 하루아침에 이루어지지 않습니다.
1강의 작은 API 호출 테스트가 모여, 오늘 5강의 거대한 CI/CD 파이프라인을 완성한 것처럼, 여러분의 현장에서도 작은 스크립트 하나부터 시작해 보시길 바랍니다.
HPE Aruba Networking의 강력한 API와 생태계가 여러분의 든든한 무기가 될 것입니다.



