1. 왜 이 시리즈를 시작했나

솔직하게 시작하겠다. 나는 Python·Ansible 같은 코딩 도구에 대한 개념이 거의 없는 상태에서 출발했다. 네트워크 장비는 매일 만지지만, “자동화”라고 하면 막연했다. 그러던 중 관리 중인 Cisco 캠퍼스 스위치 14대를 매번 SecureCRT로 한 대씩 접속해 점검하는 일이 비효율적이라는 생각이 들었고, Ansible을 한번 제대로 파보기로 했다.

이 시리즈는 그 과정의 실패와 시행착오를 그대로 담은 기록이다. 매끄럽게 정리된 “정답 매뉴얼”이 아니라, 막히고, 에러 메시지에 당황하고, “이거 굳이 해야 하나” 의심하다가 결국 길을 찾은 날것의 과정이다. 같은 출발선에 선 사람에게는 잘 정리된 교과서보다 이런 기록이 더 쓸모 있다고 믿는다.

2. “SecureCRT로도 되잖아?” — 가장 먼저 든 의심

Ansible 환경을 구축하고 첫 점검 스크립트를 돌려본 직후, 가장 먼저 든 생각은 이것이었다.

이 의심은 정당하다. 그리고 이 질문을 회피하는 자동화 글은 신뢰하면 안 된다. 정직하게 답하면 — 지금까지 한 것(명령 실행 + 로그 저장)만 놓고 보면 SecureCRT로도 된다. 그게 사실이다.

핵심은 “되느냐”가 아니라 “같은 것이냐“다. 둘이 갈라지는 지점이 어디인지를 정확히 알아야, 내가 지금 시간 낭비를 하는 건지 아닌지 판단할 수 있다.

3. 되는 영역 vs 갈라지는 영역

3-1. SecureCRT로도 충분히 되는 영역

작업	SecureCRT 대응 기능
여러 장비에 같은 명령	Send Commands to All Sessions
출력 로그 저장	세션 로깅(Session Logging)
자동 접속·명령·저장	VBScript / Python 스크립트

여기까지는 사실상 동급이다. “오늘 14대 점검 로그 남기기”가 목표의 전부라면, 이미 SecureCRT를 쓰고 있는 사람은 굳이 Ansible을 새로 배울 이유가 약하다. 이걸 부정하면 거짓말이다.

3-2. Ansible이 압도하기 시작하는 지점

차이는 “수집 다음”에서 폭발한다. SecureCRT 로그는 장비별 텍스트 덩어리로 끝난다. 그걸 가공하려면 결국 별도의 파서를 또 짜야 한다. Ansible의 진짜 가치는 수집이 아니라 그 다음의 네 가지에 있다.

관점	SecureCRT 스크립트	Ansible
구조화·판정	텍스트 로그 → 별도 파서 필요	수집→조건판정→엑셀화가 한 흐름. CPU 90%↑ 자동 경고 등
기종 분기	if 분기 코드 복잡해짐	그룹별로 다른 명령셋을 선언적으로 지정
멱등성(설정변경)	이미 있어도 또 침. 결과 모름	있으면 안 건드림(ok), 없으면 생성(changed)하고 보고
버전관리·협업	개인 PC에 묶임	플레이북=텍스트 → Git 추적·팀 공유·재현

4. 도구 선택의 기준

며칠간의 시행착오 끝에 내가 내린 결론은 이렇다. 도구는 목적에 종속돼야지, 그 반대가 아니다. 판단 기준은 단 하나의 질문으로 압축된다.

그리고 한 가지 더. 14대 정도 규모에서는 SecureCRT와 Ansible의 체감 차이가 크지 않다. 하지만 자동화의 진짜 가치는 “노동량이 장비 수에 비례하던 것을, 장비 수와 무관하게 만드는 것”이다. 같은 플레이북이 14대든 140대든 1400대든 똑같이 명령 한 줄로 작동한다. 이 구조적 이점은 규모가 커질수록 폭발적으로 벌어진다.