· 1987 words · 10 min read

1. 자동화의 필연성#

“자동화할 것인가, 하지 않을 것인가 - 그것이 문제다.”

Software-Defined Networking (SDN)과 DevOps가 등장한 이후로, 엔지니어들은 네트워크 자동화가 필수인지, 사치인지, 아니면 과도한 엔지니어링인지 논쟁해왔다. 답은? 상황에 따라 다르다. 하이퍼스케일러들은 반드시 필요하다: 그들은 선택의 여지가 없었기 때문에 2010년대 초반부터 시작했다. 소규모 기업은 전면적인 자동화가 전혀 필요하지 않을 수도 있다. 대부분의 네트워크는 그 중간 어딘가에 있다. 문화, 기술, 도구 성숙도, 비즈니스 우선순위 모두 채택 속도에 영향을 미친다. 오늘날, 이러한 요소들이 하나로 수렴되고 있다. 자동화는 불가피해지고 있다.

한 지역 물류 회사의 네트워크 팀은 3년을 들여 자신들이 “자동화 플랫폼"이라고 부르는 것을 구축했다. VLAN 프로비저닝, BGP 네이버 설정, 장비 보안 강화를 위한 Ansible 플레이북. 코드는 Git에 보관됐다. 변경 사항은 동료 검토를 거쳤다. 배포는 며칠이 아닌 몇 분이면 됐다. 그들이 보유한 모든 기준으로 볼 때, 자동화를 올바르게 하고 있었다.

그러던 중 회사가 경쟁사를 인수하며 하룻밤 사이에 규모가 두 배로 커졌다. 새로운 사이트들, 두 개의 새 벤더, 기존 네이밍 규칙과 충돌하는 네이밍 컨벤션. 새 환경에 프로비저닝 플레이북을 처음 실행했을 때, 엣지 케이스에서 실패했다. 패치를 했다. 또 다른 곳에서 실패했다. 인수 후 6주가 지나자, 한 엔지니어가 수동으로 네트워크를 운영하는 것보다 자동화를 유지하는 데 더 많은 시간을 쓰고 있었다.

사후 검토는 불편했다. 도구가 실패한 것이 아니었다. Ansible은 문제없었다. 실패한 것은 눈에 보이지 않는 것이었다: 네트워크가 어떻게 보여야 하는지에 대한 단일 정의가 없었다. 각 플레이북은 네이밍 컨벤션, IP 할당 전략, 벤더 동작에 대한 자체 가정을 담고 있었다. 환경이 바뀌자, 모든 가정이 동시에 무너졌다. 팀은 기존 네트워크를 자동화했을 뿐, 변화에 적응할 수 있는 플랫폼을 구축하지 않았던 것이다.

이것이 모든 자동화 정체의 핵심 패턴이다. 조직은 오늘의 문제를 위해 구축된 자동화가 내일의 장애물이 되는 지점에 도달한다.

1.1. 완벽한 폭풍#

자동화는 더 이상 선택이 아니다. 하이퍼스케일러들은 폭발적인 Artificial Intelligence (AI) 성장에 대응한다: 수십만 개의 Central Processing Unit (CPU)와 Graphics Processing Unit (GPU)가 고속 Ethernet을 통해 통신한다. 기업과 서비스 제공업체는 레거시 인프라, 새로운 서비스, 클라우드/온프레미스/엣지 확산, 그리고 늘어나는 비용을 동시에 관리해야 한다.

기술 분야의 모든 영역이 API 우선, 셀프서비스로 이동했다. 개발자들은 네트워킹에서도 동일한 것을 기대한다. ML 워크로드는 구조화된 데이터를 필요로 한다. 보안과 컴플라이언스는 자동화되고 감사 가능한 프로세스를 요구한다.

이제 질문은 “자동화해야 할까?“가 아니다. “왜 아직도 안 했을까?“다.

명확한 이점에도 불구하고, 여러 장벽이 채택을 늦춰왔으며, 그 중 많은 것들이 아직도 남아 있다:

인텐트 모델 부재: 네트워크는 “네트워크가 실제로 어떻게 동작해야 하는가?“가 아닌 장비 설정으로 기술됐다. 명확한 인텐트 데이터 없이는, 자동화가 취약하고 장비 중심에 머문다.
지저분하고 일관성 없는 설계: 자동화는 예측 가능성이 필요하다. 예외, 임시방편, 일회성 처리로 가득 찬 네트워크는 자동화할 수 없다. 깔끔하고 표준화된 설계가 이긴다.
벤더 난립: 벤더, 플랫폼, 서비스의 혼재는 지속적인 통합 문제를 의미한다.
잘못된 기술 조합: 네트워킹과 소프트웨어 개발 모두를 아는 엔지니어가 거의 없었다. 그 간극이 자동화를 잘 설계하기 어렵게 만들었다.
변화에 대한 두려움: 네트워크는 중요한 인프라다. 보수적인 변경 관리로 인해 자동화를 정당화하기 어려웠다.
안전한 테스트 환경 부재: 대부분의 팀은 운영 환경과 일치하는 적절한 랩을 갖추지 못했다. 자동화를 안전하게 테스트하는 것이 거의 불가능했다.

이러한 장벽들은 독립적으로 작동하지 않는다. 서로를 강화한다: 인텐트 모델 없이는 자동화가 취약해지고; 취약한 자동화는 변화에 대한 두려움을 증폭시키며; 변화에 대한 두려움은 취약성을 줄일 기술과 테스트 환경을 구축하는 데 필요한 투자를 막는다.

flowchart LR
    subgraph 기술적 요인
        A[인텐트 모델 부재]
        B[지저분한 설계]
        C[벤더 난립]
        D[테스트 환경 부재]
    end
    subgraph 조직적 요인
        E[잘못된 기술 조합]
    end
    A --> F[변화에 대한 두려움]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|투자를 제한| E
    F -->|진전을 늦춤| A

    style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px

좋은 소식은: 2025년까지 이러한 장벽들 대부분이 해소되고 있다. 기업들과 벤더들이 앞으로 나아가고 있다. Chris Grundemann(Network Automation Forum)의 State of Network Automation Survey는 지금 이 변화가 일어나고 있음을 보여준다. 그럼에도 단 하나의 마법 같은 공식은 없다. 올바른 마음가짐을 이해하는 것이 먼저다.

1.2. 네트워크 자동화에 접근하는 방법#

이 책은 성공적인 네트워크 자동화에 필요한 근본적인 아키텍처 개념을 다룬다. 단일 도구를 쫓지 말라: 모든 문제를 해결하는 만능 해법은 없다. 성공은 세 가지 기둥을 결합하는 데서 온다: 사람, 프로세스, 기술 (이 순서대로).

1.2.1. 성공의 세 가지 기둥#

매슬로우의 피라미드처럼 (더 높이 쌓으려면 탄탄한 기반이 필요하다) 각 기둥은 그 위의 기둥을 지지한다.

flowchart BT
    A[사람] --> B[프로세스]
    B --> C[기술]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc

사람: 자동화는 그것을 설계하고, 구축하고, 운영하는 사람들에 의해 성패가 결정된다. 그들의 필요를 이해하라. 훈련과 협업을 통해 그들에게 힘을 실어주라.
프로세스: 조직적 정렬이 중요하다. 자동화 성과를 측정 가능한 가치인 비용 절감, 빠른 납품, 개선된 신뢰성과 연결하라.
기술: 도구는 존재한다. 과제는 올바른 것을 선택하고 견고한 아키텍처 안에서 통합하는 것이다.

이 세 가지의 균형을 잡으면, 자동화는 단순한 기술 프로젝트가 아닌 조직의 역량이 된다. 변화는 반복적이다. 진전은 한 번에 한 단계씩 온다. 구매 대 구축(buy-versus-build) 딜레마를 반복적으로 마주하게 될 것이다: 이 책 전반에 걸쳐 다룬다.

1.3. 현실이 어떻게 보이는가#

모든 조직은 자신만의 경로를 따른다. 대부분은 작은 스크립트로 시작해서 설정 관리, 컴플라이언스 검사, 트러블슈팅으로 확장한다.

1.3.1. 자동화 스펙트럼 이해하기#

자동화 성숙도는 수동 운영에서 자가 치유 네트워크로 이동한다:

graph LR
    A[수동 운영] --> B[스크립트 작업]
    B --> C[워크플로 자동화]
    C --> D[인텐트 기반 시스템]
    D --> E[자율 네트워크]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
    style D fill:#ccffcc
    style E fill:#ccccff

수동 운영: 모든 변경이 Command Line Interface (CLI)를 통해 사람이 수동으로 내리는 결정이다. 단일 엔지니어가 익숙한 장비에서는 빠르지만, 어떤 규모에서도 신뢰할 수 없다. 네트워크는 마지막으로 손댄 사람만큼만 일관성이 있다. 로그인 기록 외에는 감사 추적이 없다.

스크립트 작업: 반복적인 작업이 스크립트로 래핑된다. 스크립트가 스프레드시트에서 설정을 생성하고, 루프가 50개 장비에 동일한 변경을 적용한다. 엣지에서 취약하다: 장비 상태, 벤더 동작, 네이밍 컨벤션의 모든 변형은 새로운 스크립트나 새로운 예외를 요구한다. 대부분의 팀이 여기서 시작하고, 많은 팀이 여기 머문다.

워크플로 자동화: 스크립트가 구조화된 플레이북과 파이프라인으로 대체된다. 변경은 재현 가능하고 감사 가능하며 셀프서비스 인터페이스를 통해 트리거할 수 있다. 자동화는 여전히 네트워크가 어떻게 보여야 하는지가 아닌 어떻게 장비를 설정하는지를 기술한다. 상태 조정은 수동 작업으로 남는다. 이 단계의 팀들은 종종 자신들의 자동화가 잘 작동한다고 설명하지만, 환경이 바뀔 때까지만이다.

인텐트 기반 시스템: 네트워크가 설정(어떻게 달성하는가)이 아닌 인텐트(무엇을 원하는가)로 기술된다. 진실의 원천(Source of Truth)이 그 인텐트를 구조화된 데이터로 보관한다. 자동화 엔진이 인텐트를 장비 상태로 변환하고 결과를 검증한다. 환경이 바뀌면, 인텐트는 안정적으로 유지되고 실행 레이어가 적응한다. 이 책의 대부분은 이 레이어를 잘 구축하는 것에 관한 것이다: 2부의 진실의 원천, 실행, 옵저버빌리티, 오케스트레이션, 프레젠테이션 블록이 인텐트 기반 시스템의 구성 요소다.

자율 네트워크: 시스템이 자신의 상태를 관찰하고, 인텐트로부터의 이탈을 감지하고, 사람의 개입 없이 루프를 닫는다. 이것은 인텐트 기반 레이어가 신뢰할 수 있고, 잘 이해되며, 규율 있게 운영될 것을 요구한다. 4부와 5부는 이를 가능하게 하는 패턴을 탐구한다: 폐루프 자동화, 자가 치유 네트워크, 그리고 자율 운영을 신뢰할 수 있게 만드는 조직적 조건들.

이 책의 1부부터 3부까지는 인텐트 기반 시스템의 아키텍처 기반을 구축한다. 4부와 5부는 자율 운영으로 나아가는 데 필요한 것을 다룬다. 오늘날 대부분의 조직은 스크립트 작업과 워크플로 자동화 사이 어딘가에 있다. 목표는 앞서 나가는 것이 아니다: 다음 레이어가 이전 것을 다시 구축할 필요 없도록 각 레이어를 탄탄한 기반 위에 구축하는 것이다.

규모에서 실제로 바뀌는 것은 목표가 아니라 아키텍처다. 50개 장비를 위해 설계된 자동화는 500개에서 단점을 드러낸다. 암묵적인 네이밍 가정을 내포한 플레이북은 네트워크가 한 팀의 작업 지식을 넘어서 성장할 때 실패한다. 3부는 자동화 플랫폼이 수십 개에서 수천 개의 장비로 이동할 때 무엇이 깨지는지, 그리고 처음부터 어떻게 설계해야 하는지를 검토한다.

네트워크 자동화의 숨겨진 이점은 자동화를 용이하게 하기 위해 네트워크 아키텍처를 최대한 단순화하도록 동기를 부여한다는 것이다. 수동으로 관리할 때는 허용 가능했던 복잡성이, 자동화가 모든 예외를 처리해야 할 때는 적극적인 장애물이 된다.

완전한 자동화는 장기적인 목표다. 자동화는 사람을 대체하지 않는다: 전문성을 증폭시켜 엔지니어들이 설계와 문제 해결에 집중할 수 있게 한다. 진정한 이점은 일관성, 신뢰성, 속도다. 자동화는 또한 수동으로는 규모에서 불가능한 것들을 가능하게 한다: 실시간 검증, 즉각적인 컴플라이언스 검사, 수백 개의 사이트에 걸친 동시 조정 변경.

다양한 환경에서 자동화가 어떻게 보이는지 몇 가지 예를 들면:

하이퍼스케일러

설계를 가져다가 네트워크 인텐트에 필요한 모든 데이터로 확장: 랙, 장비, 케이블, Internet Protocol (IP), 오버레이, 네트워크. 이를 사용해 Bill of Materials (BOM)을 생성하고 장비가 연결될 때 Zero Touch Provisioning (ZTP)를 통해 제공되는 부트스트랩 설정을 만든다.
옵저버빌리티 데이터(메트릭, 로그, 플로우)를 컨텍스트로 보강된 실시간 이벤트로 상관시킨다. SLA 범위 내에서 용량을 유지하면서 연결을 드레이닝하는 워크플로를 트리거한다.

서비스 제공업체

트랜짓 제공업체 전반의 인터넷 링크 전체 메시 테스트. 패킷 손실과 지연을 허용 범위 내로 유지. 문제를 감지하고 의심스러운 링크에서 트래픽을 드레이닝. 수정되면 다시 복구.
제공업체의 회선 유지보수 알림(이메일, 웹훅) 감시. 구조화된 데이터로 변환. 경보를 뮤트하거나 영향을 최소화하기 위해 선제적으로 대응.

기업

사용자가 보안 정책을 정의하는 셀프서비스 포털. 집행 정책에 따라 방화벽 규칙으로 변환. 미사용 규칙을 정리하는 규칙 라이프사이클 활성화.
장비 교체 및 라이프사이클 관리. End of Life (EOL) 장비 감지, 소프트웨어 취약점 플래그, 업그레이드 자동화, 플랫폼 마이그레이션 지원.

핵심: 가장 시간이 많이 걸리고, 오류가 발생하기 쉽거나, 중요한 프로세스를 식별하라. 그것들이 비즈니스를 어떻게 지원하는지 이해하라. 그런 다음 그것들을 더 효율적이고 자동화된 버전으로 발전시켜라.

이러한 솔루션들은 단순하거나 복잡할 수 있지만, 공통 패턴을 공유한다. 이 책은 그 패턴들을 분석하고 5부 - 패턴과 유스케이스의 정교한 실제 유스케이스로 마무리한다.

좋은 의도로도 일이 잘못될 수 있다. 조심해야 할 일반적인 함정들이 있다.

1.3.2. 피해야 할 일반적인 함정들#

이 책 전반에 걸쳐 많은 함정을 발견하게 될 것이다. 왜냐하면 내가 직접 경험했기 때문이다. 항상 염두에 두어야 할 몇 가지가 있다:

한 번에 모든 것을 자동화하려는 시도: 작게 시작하라. 신뢰와 전문성을 쌓기 위해 영향력이 높고 리스크가 낮은 유스케이스를 선택하라.
도구 안에 인텐트 내포: 네이밍 컨벤션, IP 할당 전략, 벤더 동작 가정이 공유 레퍼런스가 아닌 플레이북과 스크립트 안에 있으면, 네트워크가 어떻게 보여야 하는지에 대한 단일 정의가 없다. 환경이 바뀌면, 내포된 모든 가정이 동시에 무너진다. 인텐트는 모든 자동화 구성 요소가 공유하는 한 곳에 있어야 한다.
데이터 품질 과소평가: 자동화는 데이터만큼만 좋다. 정확성과 일관성에 일찍 투자하라.
테스트 없이 구축: 운영 환경에 배포하기 전에 테스트하고 검증하라.
변화를 위한 설계 없이 현재 네트워크 자동화: 현재 토폴로지, 벤더, 네이밍 컨벤션에 맞춰 구축된 자동화는 무언가 바뀔 때까지만 작동한다. 자동화 구성 요소를 구축하기 전에, “지금 작동하는가?“가 아니라 “환경이 바뀔 때도 여전히 작동하는가?“를 물어라. 현재 네트워크를 자동화에 인코딩하면 비즈니스가 발전할 때마다 복잡해지는 기술 부채가 생긴다.
사용하는 사람이 아닌 구축한 엔지니어를 위한 구축: 구축한 팀만을 위해 설계된 자동화 플랫폼은 단일 실패 지점이다. 서비스 요청을 제출하는 애플리케이션 팀, 변경 게이트를 승인하는 운영자, 컴플라이언스 보고서를 검토하는 감사자 - 각자 다른 필요, 다른 어휘, 다른 기대를 갖고 있다. 처음부터 그 사용자들을 염두에 두는 것이 모든 아키텍처 결정을 형성한다: API가 어떻게 구조화되는지, 오류가 어떻게 표면화되는지, 상태가 어떻게 전달되는지. 엔지니어는 이해하지만 소비자가 사용할 수 없는 자동화는 조용히 우회될 것이다.

마지막으로: 작업이 스스로 말하도록 하라. 어떻게? 네트워크 자동화의 이점과 비즈니스에 미치는 영향을 객관적으로 보여주는 측정 지표를 정의하고 추적하라.

1.3.3. 자동화 성공 측정하기#

두 그룹에 집중하라: 기술 메트릭과 비즈니스 메트릭. 둘 다 리더십에게 중요하다.

기술 메트릭:

평균 복구 시간 (MTTR): 네트워크 문제를 얼마나 빨리 감지, 진단, 해결할 수 있는가?
변경 성공률: 인시던트를 일으키지 않고 배포된 네트워크 변경의 비율은?
Configuration Drift: 네트워크 전반의 장비 설정이 얼마나 일관성 있는가?
배포 속도: 새로운 서비스나 설정 변경을 얼마나 빨리 구현할 수 있는가?

비즈니스 메트릭:

서비스 가용성: 자동화로 관리되는 서비스가 수동으로 관리되는 서비스보다 더 신뢰할 수 있는가?
엔지니어링 생산성: 팀이 운영 작업보다 전략적 작업에 더 많은 시간을 쓰고 있는가?
컴플라이언스 태세: 컴플라이언스 위반을 얼마나 빨리 검증하고 수정할 수 있는가?
자원 활용: 네트워크 용량과 성능을 더 잘 활용하고 있는가?

이러한 메트릭을 정기적으로 추적하라. 지속적인 투자를 정당화하고 어디를 개선해야 하는지 보여준다. 6장에서는 옵저버빌리티 블록이 이러한 메트릭을 어떻게 수집하고 표면화하는지를 다루고, 14장에서는 이를 비즈니스 가치와 플랫폼 프로덕트 사고와 연결한다.

1.4. 요약#

물류 회사의 자동화 플랫폼은 기술적으로 유능했다. 실패는 아키텍처적이었다: 인텐트에 대한 단일 정의 없음, 네트워크가 어떻게 보여야 하는지와 어떻게 달성하는지 사이의 분리 없음, 환경이 바뀔 때 시스템에 대해 추론할 방법 없음. 그 실패 패턴은 드물지 않다. 자동화가 원칙 있는 설계를 갖춘 플랫폼이 아닌 스크립트 모음으로 취급될 때의 기본 결과다.

자동화를 추진하는 힘은 구조적이며 선택이 아니다: 현대 인프라의 규모, 개발자 속도 셀프서비스에 대한 기대, 네트워크를 수동으로 운영하는 증가하는 비용. 자동화를 도구 문제로 취급하는 조직은 모든 새 환경이 처음부터 다시 구축해야 한다는 것을 발견한다. 아키텍처 문제로 취급하는 조직은 복리처럼 성장하는 무언가를 구축한다.

세 가지 기둥(사람, 프로세스, 기술)은 체크리스트가 아닌 의존성 체인이다. 규모에서 작동하는 기술 선택은 문제를 이해하는 사람들이 명확한 프로세스를 위해 만들어진 것이다. 이 순서를 올바르게 가져가는 것이 성장하는 자동화와 몇 년마다 다시 구축해야 하는 자동화를 구분짓는다.

자동화 스펙트럼은 수동 운영을 거쳐 스크립트 작업, 워크플로 자동화, 인텐트 기반 시스템, 자율 네트워크로 이어진다. 오늘날 대부분의 조직은 중간 어딘가에 있다. 이 책은 인텐트 기반 레이어를 위한 아키텍처 기반을 구축한다: 1부와 2부는 왜와 어떻게를 확립하고, 3부는 규모에서 무엇이 바뀌는지를 검토하며, 4부와 5부는 자율 운영으로의 단계를 가능하게 하는 패턴을 탐구한다.

물류 이야기에서의 특정 아키텍처 실패는 우연이 아니다. 명시적인 원칙 없이 설계된 자동화의 기본 결과다: 공유된 인텐트 없음, 네트워크가 어떻게 보여야 하는지와 어떻게 달성하는지 사이의 분리 없음, 환경이 바뀔 때 시스템에 대해 추론할 방법 없음. 2장은 이러한 원칙들을 명명하고 각각을 예방하는 실패 유형에 매핑한다.

💬 Found something to improve? Send feedback for this chapter