Designing Network Automation at Scale

01 - 자동화의 필연성

Mon, 01 Jan 0001 00:00:00 +0000

1. 자동화의 필연성#

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

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

02 - 설계 원칙

Mon, 01 Jan 0001 00:00:00 +0000

2. 설계 원칙#

한 네트워크 자동화 팀이 6개월을 들여 진심으로 자랑스러워하는 시스템을 구축했다. 구조화된 데이터 모델에서 인텐트를 가져와 템플릿 엔진으로 장비 설정을 생성하고, 정책 라이브러리에 대한 변경 사항을 검증하며, 완전한 롤백 지원과 함께 NETCONF를 통해 푸시했다. 아키텍처적으로 견고했다. 리더십에 대한 데모는 잘 됐다. 그런 다음 그들은 네트워크 운영 팀에 넘겼다.

채택은 일어나지 않았다. 운영자들은 계속 CLI를 사용했다. 이유를 물었을 때 답변은 일관됐다: “실행하기 전에 무엇을 할지 모르겠어요.” “무언가 잘못되면 무슨 일이 있었는지 알 수가 없어요.” “출력 결과를 어떻게 읽는지 모르겠어요.” 자동화 팀은 기술적으로 인상적이지만 운영상 불투명한 것을 구축했다. 드라이런 모드도 없고, 사람이 읽을 수 있는 변경 미리보기도 없고, 운영자가 인식하는 방식으로 작성된 감사 추적도 없었다. 시스템은 아직 신뢰를 얻지 못했으면서도 신뢰를 요구하는 블랙박스였다. 6개월의 엔지니어링 노력이 사용되지 않은 채 방치됐다.

03 - 아키텍처적 사고

Mon, 01 Jan 0001 00:00:00 +0000

3. 아키텍처적 사고#

이 장은 이 책의 기초를 소개한다. 이 마인드셋을 채택해야 하는 이유를 설명하고, Network Automation Forum (NAF)이 제안하는 참조 프레임워크를 소개하며, 프로젝트에서 이를 어떻게 활용하는지 보여준다.

2부에서 이러한 주제들을 깊이 다룬다. 이 장에서는 세부 사항에 들어가기 전에 전체적인 그림을 제공하기 위해 간략하게 소개한다. 각 구성 요소를 설명한 후에 전체 그림을 갖는 것이 점들을 연결하는 데 도움이 되기 때문에 이것이 중요하다.

하지만 나는 무엇을 하기 전에 왜를 이해하는 것을 강하게 믿는다. 먼저 아키텍처를 활용해야 하는 이유를 이해해보자.

04 - 진실의 원천

Mon, 01 Jan 0001 00:00:00 +0000

4. 진실의 원천#

새로운 서비스가 주말까지 가동되어야 했다. 변경은 간단했다: 새 VLAN, 새 서브넷, 업데이트된 방화벽 규칙, 엣지 라우터의 새 BGP 커뮤니티. 네트워크 엔지니어는 정확히 무엇을 해야 하는지 알고 있었다. 이어진 것은 다섯 개의 시스템에 걸친 4일간의 조율이었다: 서브넷을 예약하는 IPAM 도구, 서비스를 등록하는 CMDB, 새 정책을 푸시하는 방화벽 관리 플랫폼, BGP 커뮤니티를 위한 라우터 설정 시스템, 그리고 새 임계값을 추가하는 모니터링 플랫폼. 각 시스템은 고유한 인터페이스, 고유한 데이터 모델, 고유한 승인 워크플로가 있었다. 그리고 공유 레퍼런스가 없었기 때문에 엔지니어는 컨텍스트를 수동으로 가지고 다녀야 했다: 한 시스템에서 다른 시스템으로 값을 복사하면서 단계 사이에 아무것도 드리프트되지 않기를 바라면서.

05 - 실행

Mon, 01 Jan 0001 00:00:00 +0000

5. 실행#

플레이북은 몇 달 동안 완벽하게 실행되고 있었다: 랩의 액세스 스위치 10대, 처음부터 끝까지 2분, 매번 깔끔한 결과. 팀이 800대 스위치의 전체 인벤토리로 출시하기로 결정했을 때, 아무도 문제를 예상하지 않았다. 처음 600대는 문제없이 업데이트됐다. 그다음 작업이 느려졌다. 그다음 멈췄다. 갑자기 150개의 동시 SSH 인증 요청을 받은 RADIUS 서버가 연결을 거부하기 시작했다. Ansible이 150대 장비에서 실행 도중 중단됐다. 엔지니어가 작업을 강제 종료했다.

이어진 것이 더 어려운 문제였다: 어떤 600대가 업데이트됐고 어떤 150대가 안 됐는지 아무도 알지 못했다. 실행 상태가 기록되지 않았다. 플레이북을 재실행하고 멱등성이 구해주기를 바랐다, 그번은 구해줬다. 하지만 이 사고는 중요한 것을 드러냈다: 실행 레이어가 랩을 위해 설계됐지, 네트워크를 위해서가 아니었다. 속도, 병렬성, 오류 경계, 상태 추적, 그 무엇도 고려되지 않았다. 자동화는 작동했지만, 실행 아키텍처는 그렇지 않았다.

Preface

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

06 - 가시성(Observability)

Mon, 01 Jan 0001 00:00:00 +0000

6. 가시성(Observability)#

한 서비스 제공업체의 핵심 라우터에서 팬 모듈이 밤새 조용히 고장났다. 경보는 아무것도 울리지 않았다. 라인 카드의 열 관리 서브시스템이 온도 상승을 감지하고 하드웨어를 보호하기 위해 포워딩 ASIC의 성능을 제한하기 시작했다. 프로덕션 트랜짓 링크의 처리량이 40% 감소했다. 모니터링 시스템은 아무것도 감지하지 못했다. 폴링하는 열 센서가 라인 카드가 아닌 섀시 수퍼바이저에 있었기 때문이다. SNMP 폴링은 5분마다 실행되었고 장치가 정상 상태라고 보고했다. 인터페이스 카운터에는 처리량 감소가 나타났지만, 해당 링크는 항상 용량 이하로 운영되어 왔기 때문에 그 패턴에 대한 임계값이 설정되어 있지 않았다.

07 - 오케스트레이션(Orchestration)

Fri, 20 Mar 2026 00:00:00 +0000

7. 오케스트레이션(Orchestration)#

네트워크 팀은 모든 것을 제대로 해냈다. 견고한 소스 오브 트루스(SoT), 모든 작업에 대한 충분히 테스트된 플레이북, 그리고 이를 실행하는 명확한 대응 절차서가 있었다. 서류상으로는 새로운 VLAN 서비스 배포가 완전히 자동화되어 있었다. 실제로는 반나절이 걸렸고 특정 엔지니어 한 명이 필요했다.

그 엔지니어는 순서를 알고 있었다. 먼저 SoT 데이터가 완전한지 검증한다. 그 다음 사전 점검 플레이북을 실행한다. 출력을 검토하고, 실패한 장치를 찾아 계속할지 결정한다. 그 다음 배포 플레이북을 트리거한다. 기다린다. 검증 플레이북을 실행한다. ServiceNow 티켓을 수동으로 업데이트한다. 중간에 장치가 실패하면 다른 장치들이 알아채기 전에 롤백한다. 그녀는 아무도 완전히 내면화하지 못한 공유 문서에 단계별로 모든 것을 대응 절차서로 작성해 두었다.

08 - 프레젠테이션(Presentation)

Sat, 28 Mar 2026 00:00:00 +0000

8. 프레젠테이션 계층#

VLAN 자동화는 6주째 실행 중이었다. 네트워크 팀은 자랑스러워했다. 매일 아침 애플리케이션 팀에서 서너 개의 새로운 서비스 요청이 들어왔고, 오케스트레이터가 네트워크 팀 누구도 키보드를 건드리지 않고 처리했다. 배포는 작동했다. 스위치는 구성되었다. 네트워크는 건강했다.

에스컬레이션은 목요일에 왔다. 애플리케이션 팀 리더가 포털에 “제출됨"이라고 표시되어 있는데 왜 VLAN 요청이 3~5 영업일이 걸리는지 묻고 있었다. 네트워크 팀이 큐를 확인했다. 대기 중인 요청 없음, 모든 배포 성공. 자동화는 수신 후 20분 이내에 모든 요청을 처리했다. 하지만 ServiceNow 티켓은 여전히 “진행 중"으로 표시되어 있었다. 아무도 티켓을 업데이트하는 통합을 작성하지 않았기 때문이다.

09 - 네트워크

Mon, 01 Jan 0001 00:00:00 +0000

9. 네트워크#

VLAN 자동화가 랩에서 3주간 실행되었다. 스위치 세 대, 각기 다른 벤더, 모든 워크플로우가 통과했다. 팀은 자신감을 느꼈다. 첫 번째 프로덕션 실행에서 800개 캠퍼스 스위치 중 23개가 실패했다. 모두 HPE였다. 모두 아무도 문서화하지 않은 펌웨어 버전을 실행하고 있었다.

플레이북은 VLAN 설정을 푸시한 후 각 장치의 오류 응답을 확인하고 있었다. 최신 HPE 펌웨어에서는 이미 존재하는 VLAN이 오류 코드 duplicate-vlan을 반환한다. 이 오래된 펌웨어 버전에서는 동일한 조건이 vlan-exists를 반환했다. 플레이북은 duplicate-vlan을 멱등성 신호, 즉 “이미 존재하므로 괜찮다"는 의미로 처리하도록 작성되어 있었다. vlan-exists를 처리하도록 작성되지 않아 해당 응답을 실패로 처리했다. HPE 플리트의 3분의 1이 실패를 보고했다. 롤백은 정상적으로 실행되었다. 애플리케이션 팀의 티켓은 네트워크 팀이 실제로 설정된 스위치와 그렇지 않은 스위치를 수동으로 감사하는 동안 3시간 더 열려 있었다.

10 - Platform Engineering and CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

11 - Scaling and Reliability

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

12 - Security, Governance and Compliance

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

13 - 문화적 전환

Mon, 01 Jan 0001 00:00:00 +0000

13. 문화적 전환#

회의 초대가 목요일에 도착했다. 제목은 “네트워크 팀 구조 업데이트"였다. Jordi는 15년간 네트워크 엔지니어로 일해왔다. CCIE를 가지고 있었다. 세 번의 인수합병, 두 번의 NOC 통합, 그리고 내부 사례 연구가 될 만큼 심각한 BGP 라우팅 인시던트 하나를 살아남았다. 그는 이것이 인사 업데이트라고 생각했다.

그렇지 않았다.

그의 매니저는 네트워크 팀이 플랫폼 엔지니어링 산하로 재편될 것이라고 설명했다. 팀의 이름은 네트워크 자동화 플랫폼으로 바뀔 것이다. 업무도 발전할 것이다: 수동 프로비저닝을 줄이고, 프로비저닝을 처리하는 자동화 시스템을 구축하고 운영하는 일이 늘어날 것이다. 새 직무 설명서는 이미 작성되어 있었다. 제목은 “네트워크 플랫폼 엔지니어"였다.

14 - 제품으로서의 자동화

Tue, 05 May 2026 00:00:00 +0000

14. 제품으로서의 자동화#

팀이 자신들의 업무를 바라보는 방식을 바꾼 그 대화가 이루어지기 6개월 전, 네트워크 플랫폼 팀은 진정으로 인상적인 무언가를 완성했다. 2년간의 지속적인 노력 끝에, 지점 온보딩을 처음부터 끝까지 처리하는 프로비저닝 플랫폼이 탄생했다. 사이트 요청을 위한 셀프서비스 인터페이스, 배포 전 잘못된 설정을 잡아내는 폐쇄 루프 검증 워크플로우, 그리고 300개 지점 전반의 서비스 상태를 추적하는 운영 대시보드가 갖춰졌다. 팀은 24시간 변경 작업창을 40분짜리 자동화 배포로 단축했다. 팀은 이를 자랑스러워했으며, 그럴 만했다.

15 - Closed Loop Automation

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

16 - Self Healing Networks

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

17 - Autonomous Networks

Mon, 01 Jan 0001 00:00:00 +0000

번역 진행 중. 이 챕터는 아직 한국어로 번역되지 않았습니다. 영어 버전을 참조하세요.
💬 Found something to improve? Send feedback for this chapter

저자 소개

Sun, 10 May 2026 00:00:00 +0000

Christian Adell 소개#

CoreWeave 수석 네트워크 개발자 | 스페인 바르셀로나

Christian Adell은 네트워크 자동화에 적용된 소프트웨어 개발을 중심으로 커리어를 쌓아왔습니다. 대규모 네트워크 자동화 솔루션 설계 및 구현에 풍부한 경험을 보유하고 있습니다.

📞 연락처#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

📖 출판 도서#

Christian은 네트워크 자동화에 관한 여러 영향력 있는 도서의 저자 및 공동 저자입니다:

Network Programmability and Automation, 2판

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2판

🎤 강연 및 커뮤니티 활동#

Christian은 주요 네트워킹 컨퍼런스와 커뮤니티 행사에서 활발하게 강연하고 있습니다:

법적 고지

Sun, 10 May 2026 00:00:00 +0000

법적 고지#

저작권 공지#

텍스트, 다이어그램, 예제를 포함한 이 사이트의 콘텐츠는 저자의 지적 재산이며 크리에이티브 커먼즈 저작자표시-비영리-변경금지 4.0 국제 라이선스 (CC BY-NC-ND 4.0)에 따라 제공됩니다.

허용되는 사항

공유 — 적절한 출처를 표시하는 조건으로 모든 매체 또는 형식으로 자료를 복사하고 재배포할 수 있습니다

다음 조건을 따라야 합니다:

저작자표시 — Christian Adell Querol에게 적절한 크레딧을 표시하고, 라이선스 링크를 제공하며, 변경이 이루어진 경우 이를 명시해야 합니다.
비영리 — 자료를 상업적 목적으로 사용할 수 없습니다.
변경금지 — 자료를 리믹스, 변형하거나 이를 기반으로 제작하여 배포할 수 없습니다.

중요 사항