May 5, 2026 · 6534 words · 31 min read

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

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

그런데 사업 개발팀이 소매 체인 인수를 마무리했다. 120개의 신규 매장이 6개월 안에 네트워크 연결을 필요로 했다. 인프라 책임자는 단 하나의 이메일을 보냈다. “이번 일은 자동화 플랫폼에 의존하고 있습니다. 어떻게 시작하면 될까요?”

네트워크 플랫폼 팀의 첫 번째 내부 반응은 자신감에 차 있었다. 자동화할 수 있다고. 워크플로우도 있고, 템플릿도 있고, 검증된 툴링도 있다고.

그러나 이메일에 답하려 할 때 나온 두 번째 반응은 그렇지 않았다. 인프라 책임자는 자동화가 기술적으로 가능한지를 묻는 게 아니었다. 전혀 다른 질문들을 하고 있었다. 지점 온보딩의 SLA는 무엇인가, 구체적으로 사이트 정보가 제출된 후 매장이 연결을 받기까지 보장되는 시간은 얼마인가? 배포가 중간에 실패할 경우 에스컬레이션 경로는 누구인가? 인프라 책임자의 팀이 네트워크 팀에 직접 묻지 않고도 모니터링할 수 있는 상태 페이지나 대시보드가 있는가? 플랫폼의 처리 용량은 얼마인가, 20개의 동시 배포를 처리할 수 있는가, 아니면 요청을 일괄 처리해야 하는가? 그리고 가장 불편한 질문은 이것이었다. 플랫폼 장애 중에 온보딩된 매장들은 어떻게 되는가, 자동으로 복구되는가, 아니면 누군가가 각각을 감사해야 하는가?

네트워크 팀에는 자동화가 있었다. 하지만 (비즈니스/제품 관점의) 답변은 없었다.

“동작하는 자동화를 구축했다"와 “다른 팀이 의존하고 계획을 세울 수 있는 서비스를 제공한다” 사이의 이 간극이 바로 이 장의 주제다.

이것은 내가 열정적으로 다루는 주제다. Autocon3에서 발표한 세션은 설계 주도 자동화 관점에서 이를 다루고 있으며, 이 장의 참조 자료로 활용될 수 있다.

14.1 역량에서 제품으로#

13장은 팀이 자동화를 조직적 역량으로 구축하기 위해 인력, 역할, 업무 방식을 어떻게 전환하는지 설명했다. 그 전환은 필수적이다. 하지만 충분하지는 않다.

역량은 팀이 할 수 있는 일이다. 제품은 다른 팀(혹은 궁극적으로는 제3자)이 의존할 수 있는 것이다. 그 차이는 기술적 품질에 관한 것이 아니다. 소매 체인 온보딩 플랫폼은 기술적으로 탁월했다. 그 차이는 공급자와 소비자 사이의 관계에 관한 것이다. 역량은 그것을 만든 사람들을 위해 존재한다. 제품은 사용자를 위해 존재한다.

네트워크 팀의 산출물이 변했다. 자동화 이전에는 산출물이 장치 설정이었다. 프로비저닝된 라우터, 확장된 VLAN, 적용된 ACL. 그 산출물의 소비자는 장치 자체였고, 성공의 증거는 통과하는 핑이나 동작하는 애플리케이션이었다. 자동화와 함께 산출물이 변한다. 네트워크 팀의 제품은 다른 팀이 소비하는 네트워크 서비스가 된다. 네트워크와의 모든 상호작용, 지점 사이트 프로비저닝, 새 애플리케이션을 위한 세그먼트 확장, 보안 정책 적용, 회의를 위한 VLAN 임시 접근 허용, 인터넷 교환소에서의 피어링 연결 추가가 변경 티켓이 아닌 서비스 요청이 된다. 장치 설정은 구현 세부 사항이다. 서비스가 바로 결과물이다.

이것이 네트워크 서비스를 제품으로 (Network Service as Product) 패턴이다. 서비스가 1차 결과물이고, 기저의 네트워크는 구현이다. 이는 소프트웨어 엔지니어링에서 새로운 개념이 아니다. API는 인프라를 추상화하고, 호출자는 어느 서버가 요청을 처리하는지 알지도 신경 쓰지도 않는다. 하지만 역사적으로 장치, 벤더, 프로토콜 중심으로 업무를 구성해 온 네트워크 팀에게는 상당한 전환이다. 라우터 설정 스킬을 중심으로 정체성을 정의했던 엔지니어는 이제 서비스 제공 역량을 중심으로 정체성을 정의하도록 요청받고 있다. 이 재구성은 13장 13.1절의 장인의 딜레마와 직결된다. 옛 기술의 전문가가 이 재구성을 가장 시급하게 해야 하는 사람이며, 이를 완전히 해낸 엔지니어는 덜 가치 있게 되는 것이 아니라 더 가치 있게 된다.

이 제품의 기술적 거처는 8장에서 설명한 프레젠테이션 블록이다. 셀프서비스 인터페이스, API 표면, 웹훅 통합, 역할 기반 접근 모델이 소비자에게 서비스 계약이 보이는 곳이다. 14장은 기술적 인터페이스에서 한 발 물러나 그것을 둘러싼 조직 및 비즈니스 모델을 살펴본다. 인터페이스와 함께 오는 약속은 무엇인가? 고장났을 때 누가 책임지는가? 서비스는 어떻게 발전하는가? 다음에 무엇을 할지는 누가 결정하는가?

14.2 제품 정의하기#

팀이 네트워크 자동화를 서비스로 전환하려 할 때 두 가지 실패 유형이 일관되게 나타난다.

첫 번째는 과잉 노출이다. 인터페이스가 구현 세부 사항을 드러내고, 소비자가 그것을 사용하기 위해 네트워크 내부를 이해해야 한다. VLAN ID, 서브넷 마스크, OSPF 영역 번호를 요구하는 지점 프로비저닝 서비스는 서비스가 아니다. 웹 폼을 갖춘 CLI일 뿐이다. 소매 체인의 시설 담당자는 OSPF 영역이 무엇인지 알지 못하며 알 필요도 없다.

두 번째는 과잉 제한이다. 인터페이스가 너무 제약되어 있어 네트워크 팀이 예상한 정확한 사용 사례만 처리한다. 템플릿에서 벗어나는 요청은 예외 프로세스를 거쳐야 한다. 영구 소매 매장과 다른 연결 요건을 가진 임시 팝업 매장을 프로비저닝해야 하는 시설 담당자는 셀프서비스를 이용할 수 없다. 티켓을 제출한다. 티켓이 네트워크 팀으로 간다. 자동화의 이점이 해당 소비자에게 도달하지 못한 것이다.

**서비스 계약 패턴 (Service Contract Pattern)**은 두 실패 유형 모두를 해결한다. 인터페이스 정의를 명시적이고, 버전화되고, 의도적으로 경계 지어진 것으로 만드는 방식으로. 서비스 계약은 세 가지 구성 요소를 가진다.

입력 표면: 소비자가 제공하는 것으로, 네트워크 용어가 아닌 비즈니스 용어로 표현된다 (이 점을 강조해야 한다는 것을 양해 바란다, 이것이 핵심이다). 지점 사이트 요청은 위치 이름, 실제 주소, 사이트 등급(표준, 소형, 팝업), 그리고 활성화 날짜를 받는다. VLAN ID는 받지 않는다. 계약은 비즈니스 의도를 내부적으로 네트워크 구현으로 변환하며, 그 변환은 자동화 플랫폼의 책임이다. 등급 정의는 영구적이지 않다. 임시 소매 키오스크를 위해 정의된 팝업 등급은 다른 연결 요건을 가진 팝업 이벤트 공간을 커버하지 못할 것이다. 입력 표면은 로드맵과 동일한 주기로 소비 팀과 함께 검토해야 하며, 등급이 계약을 처음 작성할 때 네트워크 팀이 예상한 사용 사례가 아닌 실제 사용 사례를 반영하도록 해야 한다.
출력 표면: 소비자가 관찰하는 것으로, 성공적인 완료와 실패 모두를 포함한다. 잘 설계된 출력 표면은 “14단계 중 7단계에서 배포 실패: gNMI 푸시가 오류 코드 400으로 거부됨"을 노출하지 않는다. “활성화 실패: 이 주소의 물리적 회선이 아직 통신사에 의해 프로비저닝되지 않았습니다. 예상 완료 날짜: [SoT의 날짜]. 귀하의 조치가 필요하지 않습니다; 회선이 온라인 상태가 되면 시스템이 자동으로 재시도합니다"를 노출한다. 자동화는 단순히 성공하거나 실패하는 것이 아니다. 소비자가 이해할 수 있는 용어로 관찰 가능한 수명 주기 이벤트를 방출한다.
내부 의존성: 서비스가 내부적으로 추적하지만 소비자는 볼 수 없고 팀은 관리해야 하는 것. 통신사의 회선 상태. 이 서비스와 인프라를 공유하는 인접 서비스들. 새 사이트의 SoT 레코드와 자동화된 모니터링을 구동하는 인벤토리 레코드 간의 일관성 관계. 회선이 통신사 유지보수에 들어갈 때, 네트워크 팀은 어떤 서비스가 영향을 받는지와 그것이 만들어내는 SLO 노출을 알아야 한다. 소비자는 자신의 서비스에 대한 영향을 알아야 할 수 있다. 그것을 야기한 구현 세부 사항을 알 필요는 없다.

flowchart LR
    classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph Consumer["소비자 인터페이스"]
        IN["입력 표면<br/>위치, 등급, 날짜<br/>비즈니스 의도"]
        OUT["출력 표면<br/>상태, 수명 주기 이벤트<br/>비즈니스 언어"]
    end

    subgraph Contract["서비스 계약"]
        TRANS["변환 레이어<br/>의도에서 구현으로<br/>VLAN, 서브넷, OSPF 영역"]
    end

    subgraph Internal["내부 의존성"]
        CIRC["회선 상태"]
        SOT["SoT 일관성"]
        NEIGHBOR["인접 서비스"]
    end

    IN --> TRANS
    TRANS --> OUT
    TRANS --> CIRC & SOT & NEIGHBOR
    CIRC & SOT & NEIGHBOR -.-> OUT

    class IN,OUT consumer
    class TRANS contract
    class CIRC,SOT,NEIGHBOR internal

서비스 계약이 정의되면, 다음 질문은 시간이 지나면서 어떻게 되는가이다.

수명 주기 질문은 많은 팀이 과소 투자하는 곳이다. 서비스 계약은 단순히 프로비저닝의 순간에 관한 것이 아니다. 기저 인프라가 변경될 때 이 서비스는 어떻게 되는가? 예정된 통신사 유지보수에 들어가는 회선으로 운영되는 지점 사이트는 예상되는 SLO 영향을 가진다. 누가 그 영향을 알고, 소매 체인의 운영팀에 통보할지를 누가 결정하며, 유지보수 창이 초과될 경우 소통을 누가 담당하는가? 이 질문들은 서비스가 Source of Truth에서 1급 엔티티가 되도록 요구한다.

4장의 SoT는 의도를 네트워크가 어떠해야 하는지에 대한 권위 있는 기록으로 설명한다. 제품 모델에서의 서비스는 그 의도를 위로 확장한다. 단순히 네트워크 요소가 어떻게 보여야 하는지가 아니라, 그 요소들이 어떤 비즈니스 기능을 누구에게 제공하고 있는지. 장치와 회선을 모델링하지만 서비스는 모델링하지 않는 SoT는 “이 회선 유지보수로 어떤 소매 매장이 영향을 받는가?“라는 질문에 답할 수 없다. 서비스 인식 변경 관리를 가능하게 하는 의존성 맵을 제공할 수 없다. 7장의 오케스트레이션 블록은 복구를 조율할 때 이 의존성 그래프에 의존한다. 회선 장애에 반응하는 폐쇄 루프 워크플로우는 알림을 라우팅하고 올바른 복구 시퀀스를 트리거하기 전에 어떤 서비스가 영향을 받는지 알아야 한다.

이것이 바로 4장 4.2.2절이 설계 주도 빌딩 블록으로 공식화하는 추상화이다. 운영자는 고수준 의도(“지점 추가”)를 제공하고 SoT는 이를 Executor가 장치를 건드리기 전에 필요한 50개 이상의 기술적 객체로 확장한다. 14장의 서비스 모델은 동일한 원칙을 한 층 더 높이 확장한다. “어떤 기술적 객체가 존재해야 하는가"에서 “그 객체들이 어떤 비즈니스 기능을 누구에게 제공하는가"로. 운영자로부터 장치 구문을 추상화하도록 설계된 SoT는 서비스가 그 안에서 1급 객체로 모델링된다면, 마찬가지로 서비스 소비자로부터 네트워크 내부를 추상화할 수 있다.

실질적인 결과로서: 서비스는 의존성 체인과 함께 SoT에 모델링되어야 한다. 지점 사이트 서비스는 물리적 회선에 의존하고, 그 회선은 공급자에 의존하며, 그 공급자는 유지보수 이력을 가진다. 네트워크 세그먼트 서비스는 일련의 액세스 스위치에 의존한다. 인터넷 교환소의 피어링 서비스는 BGP 세션에 의존하고, BGP 세션은 물리적 포트에 의존하며, 그 포트는 특정 시설에 위치한다. 어떤 의존성이 상태를 변경하면, 서비스 모델이 업데이트되고, 영향받는 소비자는 자신이 이해할 수 있는 용어로 통보받을 수 있다.

flowchart TB
    classDef service fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef infra fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef external fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    S1["지점 사이트 서비스<br/>매장 847"]
    S2["애플리케이션 연결 서비스<br/>인벤토리 시스템"]

    C1["회선<br/>공급자 X, CID-44821"]
    SW1["액세스 스위치<br/>bldg-b-sw-01"]
    BGP1["BGP 세션<br/>AS64501"]
    PORT1["물리적 포트<br/>rack-14-u32"]

    S1 --> C1
    S2 --> SW1
    S2 --> BGP1
    BGP1 --> PORT1

    MAINT["통신사 유지보수 창<br/>2026-06-15 02:00 UTC"]
    C1 -.->|"영향받음"| MAINT

    class S1,S2 service
    class C1,SW1,BGP1,PORT1 infra
    class MAINT external

팀이 이런 방식으로 모델링할 수 있어야 하는 네트워크 서비스에는 다음이 포함된다. 새 지점 사이트 활성화, 컨퍼런스나 팝업 이벤트를 위한 임시 네트워크 접근, 의존성 규칙을 적용하는 ACL을 갖춘 애플리케이션 연결, 교환 지점에서의 인터넷 피어링 확장, 새 프로젝트 세그먼트를 위한 VLAN 확장. 이 각각은 비즈니스 소비자, 수명 주기, 의존성, 그리고 상태와 실패에 대한 의미 있는 정의를 가진다.

이 모델을 구축하는 대부분의 팀은 백지 상태에서 시작하지 않는다. 기존 네트워크에는 이미 300개의 지점 사이트와 수년간 축적된 설정 변경이 있으며, SoT는 장치와 회선을 모델링하지만 서비스는 모델링하지 않는다. 그 기존 사이트들이 서비스 모델에 참여할 수 있으려면, 실제 상태를 발견하고 SoT가 사실이라고 생각하는 것과 조정해야 한다. 실행 중인 설정이 SoT 레코드에서 이탈한 사이트는 그 이탈이 해결될 때까지 자동화된 수명 주기 관리 하에 안전하게 가져올 수 없다. 자동화는 의도에 대한 SoT의 관점을 기반으로 설정을 푸시하며, 그 관점이 잘못되면 푸시는 상황을 악화시킬 것이다. 장치 상태를 읽고 SoT 레코드와 비교하여 격차를 식별하고 해결하는 발견 및 조정은 브라운필드 환경의 전제 조건 단계다. 이 작업은 화려하지 않고 시간이 많이 걸리지만, 건너뛰면 서비스 모델은 플랫폼이 구축된 후 프로비저닝된 사이트에만 유효하게 되며, 이는 일반적으로 네트워크의 작은 부분에 불과하다.

SoT에서 서비스를 모델링하는 것은 필요하지만 충분하지 않다. 팀은 또한 올바른 수준에서 서비스를 관찰해야 한다. 6장의 가시성 블록이 루프를 닫는다. 소비자의 관점에서 서비스가 건강한지를 추적하는 서비스 수준 가시성은 기저 인프라가 건강한지를 추적하는 장치 수준 가시성과 다르다. 둘 다 필요하다. 서비스 모델이 올바른 수준에서 계측되지 않으면, 기저 장치들이 모두 정상 보고를 하는 동안에도 서비스가 소비자에게 저하된 것처럼 보일 수 있다.

14.3 비즈니스 정렬#

네트워크 자동화에 대한 전통적인 주장은 운영 효율성에 초점을 맞춘다. 더 적은 티켓, 더 빠른 프로비저닝, 더 낮은 오류율. 그 주장은 초기 투자를 정당화하는 데 유용하다. 하지만 시간이 지나면서 전략적 투자를 유지하기에는 충분하지 않다.

운영 효율성은 현재 기준선에 대해 측정된다. 수동 프로비저닝 시간을 4시간에서 40분으로 줄인 팀은 상당한 처리량 향상을 입증했다. 3년 전 예산을 승인한 사업 부서장은 만족하지만 전략적으로 관여하지는 않는다. 네트워크 팀이 더 잘 운영되고 있고, 그것은 좋은 일이지만, 추가 투자의 이유는 아니다.

더 강력한 주장은 역량이다. 자동화는 그것 없이는 불가능하거나 엄청나게 비용이 많이 드는 비즈니스 결과를 가능하게 한다. 소매 체인 확장이 구체적인 예다. 성숙한 자동화 플랫폼 없이는 6개월 안에 120개 매장을 온보딩하려면 6개월 동안 그 프로젝트에만 전담하는 네트워크 엔지니어 팀이 필요하다. 공격적인 수동 프로비저닝 속도인 하루에 엔지니어 1명당 매장 1개(연결 유형, 장치 수, 통신사 조정 시간, 사이트 조사 완료 여부에 따라 상당히 다름)를 가정하면, 이는 다른 책임 없이 약 8명의 팀이 필요하다. 성숙한 자동화 플랫폼이 있으면, 동일한 작업이 병렬로 자동화된 워크플로우를 실행하는 기존 팀에 의해 처리된다. 비즈니스 결과, 즉 허용 가능한 비용으로 6개월 안에 완성된 확장은 오직 자동화가 존재하기 때문에 달성 가능하다. 이것은 효율성 주장이 아니다. 역량 주장이다. 비즈니스 주장이다.

두 번째 예: 대규모 AI 모델 훈련을 운영하는 조직은 인터커넥트 프로비저닝 지연 시간과 안정성에 의존한다. 새 훈련 클러스터를 온라인으로 가져오는 데 2주간의 수동 네트워크 프로비저닝이 필요하다면, 경쟁력 있는 속도로 훈련 실험을 실행하는 비즈니스 역량은 네트워크 팀의 처리량에 의해 제한된다. 프로비저닝을 2주에서 48시간으로 줄이는 자동화는 비즈니스 부서가 전략적으로 중요하게 생각하는 비즈니스 역량에 대한 직접적인 입력이다. 그 연결을 표현할 수 없는 네트워크 팀은 영향력을 잃고 있는 것이다.

세 번째 예: 엔지니어가 새 엔터프라이즈 MPLS VPN 계약마다 수동으로 PE 라우터, VRF 인스턴스, 고객 CE 장치와의 BGP 세션, QoS 정책을 설정하는 서비스 제공자는 주문 수락부터 서비스 가동까지 4주가 걸린다. 그 타임라인은 운영 문제가 아니다. 영업 문제다. 동일한 프로비저닝 시퀀스를 자동화한 경쟁자들, 서비스 요청에서 일관된 설정을 생성하고, 기존 토폴로지에 대해 검증하며, 테스트된 워크플로우를 통해 푸시하는, 는 RFP 응답에서 2주 납기를 약속한다. 4주 제공자는 엔지니어가 아무리 숙련되어도 그 약속에 맞출 수 없다. 제약은 기술이 아니라 프로비저닝 프로세스의 직렬적, 수동적 특성이기 때문이다. 납기를 4주에서 3일로 압축하는 자동화는 영업팀이 약속할 수 있는 것을 바꾸고, 이는 회사가 따낼 수 있는 계약을 바꾼다. 이것은 효율성 주장이 아니다. 수익 주장이며, 자동화 플랫폼에 대한 투자 여부에 관한 대화에 속한다.

추론의 순서가 중요하다. 장치 동작에서 위로 설계된 자동화, 즉 “라우터 설정에 대해 무엇을 자동화할 수 있는가"에서 시작해 “비즈니스는 이것에서 무엇을 얻는가"로 나아가는 방식은, 비즈니스 결과를 제공하도록 설계된 적이 없기 때문에 비즈니스 가치를 표현할 수 없는 경우가 많다. 비즈니스 역량에서 아래로 설계된 자동화, 즉 “어떤 비즈니스 결과가 신뢰할 수 있는 네트워크 서비스를 필요로 하는가"에서 시작해 서비스 설계를 통해 거꾸로 그 서비스를 구현하는 자동화로 나아가는 방식은, 첫 번째 대화부터 자신의 작업을 비즈니스 우선순위와 연결할 수 있다.

비즈니스 주도 서비스 맵 (Business-Driven Service Map) 패턴은 이 연결을 명시적으로 만든다. 네트워크 서비스를 그것이 가능하게 하는 비즈니스 역량에 매핑하는 것이다. 각 네트워크 서비스에 대해, 맵은 세 가지 질문에 답한다. 어떤 비즈니스 프로세스가 이 서비스에 의존하는가, 이 서비스가 저하되거나 사용 불가능할 경우 비즈니스 영향은 무엇인가, 이 서비스가 더 빠르거나, 더 신뢰할 수 있거나, 셀프서비스가 된다면 어떤 비즈니스 역량이 가능해지는가. 이것은 네트워크 자동화 제품 관리자 (Network Automation Product Manager)가 소유할 문서이며, 자동화 로드맵을 비즈니스 우선순위와 정렬하기 위한 1차 도구다.

flowchart TB
    classDef biz fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef svc fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef auto fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph BIZ["비즈니스 역량"]
        B1["소매 확장"]
        B2["AI 훈련 속도"]
        B3["이벤트 운영"]
    end

    subgraph SVC["네트워크 서비스"]
        S1["지점 활성화"]
        S2["인터커넥트 프로비저닝"]
        S3["임시 접근"]
    end

    subgraph AUTO["자동화"]
        A1["사이트 온보딩 워크플로우"]
        A2["회선 및 BGP 프로비저닝"]
        A3["컨퍼런스 VLAN 수명 주기"]
    end

    B1 --> S1 --> A1
    B2 --> S2 --> A2
    B3 --> S3 --> A3

    class B1,B2,B3 biz
    class S1,S2,S3 svc
    class A1,A2,A3 auto

이 재구성은 많은 네트워크 팀에게 불편하다. 다른 것을 측정해야 하기 때문이다. 운영 지표(처리된 티켓, 변경 성공률, Mean Time To Resolution (MTTR))는 팀의 통제 범위 안에 있고 계측하기 쉽다. 비즈니스 결과 지표(새 소매 매장 오픈 시간, 훈련 처리량의 입력으로서의 인터커넥트 프로비저닝 지연 시간)는 다른 사업 부서와의 협력과 그들이 실제로 무엇을 측정하는지에 대한 이해를 필요로 한다. 이 전환을 하는 팀, 즉 기술적 우수성 측정에서 비즈니스 기여 측정으로 전환하는 팀은, 예산 대화에서 다른 질문에 답하고 있다. “이번 분기에 얼마나 효율적으로 네트워크를 운영했는가"가 아니라 “이번 분기에 어떤 비즈니스 결과가 네트워크 플랫폼에 의존했으며, 그것 없이는 무엇이 실패했을 것인가.” 답하기 더 어려운 질문이지만, 플랫폼이 다음 단계로 자금을 받는지를 결정하는 질문이다.

효율 측정보다 영향 측정 (Impact Measurement over Efficiency Measurement) 원칙이 뒤따른다. 네트워크 팀에게만 중요한 운영 지표보다 비즈니스에 중요한 결과를 측정하는 것을 우선시한다. 효율성 지표는 입력이다. 결과가 비즈니스가 신경 쓰는 것이다.

이 재구성은 또한 계획 주기에서 팀이 요청하는 것을 바꾼다. “MTTR을 40% 줄였습니다"를 발표하는 팀은 자신의 성과를 보고하고 있다. “소매 확장 타임라인이 달성 가능한 것은 우리의 온보딩 자동화가 수동 개입 없이 40개의 동시 활성화를 처리할 수 있기 때문입니다"를 발표하는 팀은 비즈니스 역량을 보고하고 있다. 두 사실 모두 사실일 수 있다. 그 중 하나만 소매 확장 프로젝트에 인력을 배치할지에 대한 결정과 관련이 있다.

14.4 내부 SLA#

신뢰성 약속 없이 다른 팀이 의존하는 자동화 플랫폼은 신뢰의 함정이다. 작동하다가 갑자기 작동하지 않으며, 소비 팀은 계획을 세울 데이터가 없다. 월요일 아침에 20개의 지점 활성화 요청을 동시에 예약하는 소매 체인 인프라 책임자는 월요일 아침 전에 플랫폼의 동작을 알아야 한다. 각 활성화에 얼마나 걸리는지, 20개가 병렬로 실행될 수 있는지 아니면 큐에 들어가는지, 하나가 배포 중간에 실패하면 어떻게 되는지, 플랫폼이 그 실패를 어떻게 전달할 것인지를.

이것들은 SLA 질문들이다. 제품 모델에서, 모든 자동화 서비스는 명시적인 SLA를 가진다. 법적 보호로서가 아니라 서비스를 계획 가능하게 만드는 운영 계약으로서.

자동화 SLA는 네 가지 구성 요소를 가진다.

가용성: 서비스 인터페이스가 연결 가능하고 요청을 수락하는 시간의 비율. 월간 99.5% 가용성을 가진 지점 활성화 서비스는 한 달에 약 세 시간 반의 허용 다운타임을 가진다. 그 숫자는 약속이다. 서비스가 다운되었을 때, 팀은 설명과 복구 타임라인을 제공해야 한다.
실행 지연 시간: 서비스가 제출에서 완료까지 요청을 이행하는 데 걸리는 시간. 지점 활성화의 경우, 이는 다음과 같을 수 있다. 30초 내 확인, 5분 내 프로비저닝 시작, 표준 사이트는 40분 내 완료. 이 숫자들은 서비스가 도달 가능한지 여부만이 아니라 “작동하는 것"이 어떻게 보이는지를 정의한다.
오류 예산: SLA를 위반하지 않고 서비스가 실패할 수 있는 빈도. 주당 성공적인 완료의 99%를 가진 서비스는 1%의 오류 예산을 가진다. 일주일에 1% 이상의 활성화가 실패하면, 무언가 잘못된 것이고 팀은 검토를 해야 한다. 13장 13.2절에서 설명된 NRE 역할은 이 예산을 정의하고 방어하는 책임을 지는 사람이며, SRE 문헌의 오류 예산 모델이 직접 적용된다. 오류 예산이 소진되면, 신뢰성이 복원될 때까지 새로운 자동화 배포가 중단된다.

SRE(사이트 신뢰성 엔지니어링)는 대규모 소프트웨어 운영에서 시작된 분야로, 서비스 수준 목표 정의, 오류 예산 측정, 기능 속도를 거버닝하기 위한 신뢰성 데이터 사용과 같은 신뢰성에 엔지니어링 원칙을 적용한다. NRE(네트워크 신뢰성 엔지니어) 역할은 이 원칙들을 네트워크 자동화 플랫폼에 적용한다. 두 역할과 네트워크 팀에 대한 적용은 13장 13.2절에서 자세히 다룬다.

에스컬레이션 경로: 서비스가 실패하거나 SLA를 놓쳤을 때, 소비자는 누구에게 연락하며, 예상 응답 시간은 얼마인가. 일반 네트워크 팀 받은 편지함으로 라우팅되는 에스컬레이션 경로는 에스컬레이션 경로가 아니다. 그것은 티켓 큐다. 제품 SLA는 정의된 응답 약속을 가진 명명된 또는 역할 기반 에스컬레이션 연락처를 필요로 한다.

지원 모델 질문이 자연스럽게 뒤따른다. 자동화가 실패하면 누가 소유하는가? 거의 모든 사고에서 세 가지 실패 모드가 나타나며, 어느 것이 활성화되었는지 혼동하면 사고가 팀 사이에서 떨어지게 된다.

실패 모드	증상	소유자
자동화 버그: 워크플로우 로직이 잘못됨	동일한 특정 입력에서 일관된 실패; 다른 입력에는 통과	자동화 개발자
플랫폼 실패: 실행 엔진, SoT, 또는 가시성 인프라가 실패	관련 없는 여러 서비스에 걸쳐 동시에 광범위한 실패	플랫폼 팀
네트워크 실패: 기저 장치 또는 회선이 실패	자동화가 오류 없이 완료되었지만; 네트워크 상태가 수렴하지 않음	네트워크 운영

이 범주들 사이의 겹침이 사고가 떨어지는 곳이다. gRPC Network Management Interface (gNMI) 푸시가 거부되어 실패하는 자동화 워크플로우는 자동화 버그(잘못된 데이터 모델), 플랫폼 실패(gNMI 컬렉터가 세션을 잃음), 또는 네트워크 실패(푸시 중 장치가 재시작됨)일 수 있다. 사고 대응 프로세스는 소비 팀이 어느 것이 활성화되었는지 이해하도록 요구하지 않고 이 범주들 간에 분류할 수 있도록 설계되어야 한다. 소매 체인의 관점에서, 매장이 연결을 받지 못했다. 누가 수정하고 언제 하는지는 제공자의 문제이지 그들의 문제가 아니다.

모든 자동화 실패에 대한 실용적인 분류 시퀀스는 세 단계를 따른다. 첫째, 자동화 로그를 확인한다. 워크플로우가 오류를 보고했는가, 그리고 그 오류가 동일한 입력의 여러 실행에 걸쳐 일관된가 아니면 하나에만 특정한가? 특정 입력에서의 일관된 실패는 자동화 버그를 가리키며, 무작위 또는 간헐적 실패는 다른 곳을 가리킨다. 둘째, 플랫폼 상태를 확인한다. 관련 없는 다른 서비스들도 동시에 실패하고 있는가, 그리고 실행 엔진, SoT, 가시성 스택이 정상을 보고하고 있는가? 관련 없는 서비스들 전반에 걸친 광범위한 동시 실패는 워크플로우 로그가 무엇을 말하든 관계없이 플랫폼 실패의 특징이다. 셋째, 장치 상태를 확인한다. 네트워크 요소가 의도한 설정을 수신하고 적용했는가, 그리고 현재 상태가 자동화가 푸시하려 한 것과 일치하는가? 워크플로우가 오류 없이 완료되었지만 네트워크가 수렴하지 않았다면, 실패는 네트워크 레이어에 있다. 이 시퀀스는 자동화된 런북의 처음 세 단계로 인코딩될 수 있으므로, 온콜 엔지니어가 처음부터 시작하는 것이 아니라 이미 완료된 분류와 함께 사고에 도착할 수 있다.

두 번째 실패 모드의 플랫폼 팀 참조는 10장과 연결된다. 플랫폼 신뢰성은 서비스 SLA의 전제 조건이다. 실행 엔진이 신뢰성 목표 없이 운영된다면 서비스는 99.5% 가용성을 약속할 수 없다. 10장의 플랫폼 엔지니어링 패턴, 즉 중복성, 상태 모니터링, 자동화된 복구가 자동화 SLA를 신뢰할 수 있게 만드는 것이다.

사고가 발생하기 전에 에스컬레이션 경로를 설계하라. 누가 무엇을 소유했는지에 대한 사고 후 대화는 항상 명확한 경계를 확립한 사고 전 대화보다 어렵다.

블래스트 반경은 동일한 사고 전 대화에 속하는 관련 설계 고려 사항이다. 수동 프로비저닝 실수는 엔지니어가 한 번에 한 사이트를 설정하기 때문에 하나의 사이트에만 영향을 준다. 자동화 버그는 사람이 무언가 잘못되었다는 것을 알아차리기 전에 입력 패턴과 일치하는 모든 사이트에 영향을 줄 수 있다. 이에 대한 대응은 자동화를 느리게 하는 것이 아니다. 서비스 계약에 동시성 제한과 단계적 롤아웃을 구현 세부 사항이 아닌 의도적인 안전 선택으로 설계하는 것이다. 5개의 활성 작업으로 동시 배포를 제한하고, 다음 배치를 해제하기 전에 첫 번째 배포가 완료될 때까지 검증하며, 실패한 작업은 사람이 지울 때까지 보류하는 지점 활성화 서비스는 느린 서비스가 아니다. 설계에 의해 블래스트 반경이 제한된 서비스다. 그 제한은 소비 팀이 플랫폼이 할 수 있는 것과 그들을 보호하기 위해 거부할 것 모두를 이해할 수 있도록, 가용성 및 실행 지연 시간과 함께 서비스 계약에 나타나야 한다. 플랫폼이 깨진 템플릿으로 39개의 추가 배포를 완료하는 대신 첫 번째 실패 후 40개 매장 롤아웃을 일시 중지할 것임을 이해하는 소매 체인 인프라 책임자는 플랫폼을 덜 신뢰하는 것이 아니라 더 신뢰할 것이다.

SLA 약속, 블래스트 반경 제어, 그리고 분류 프레임워크의 존재는 변경 거버넌스와 다른 관계를 위한 조건을 만든다. 전통적인 변경 관리 하에서 운영되는 조직에서, 자동화된 것을 포함한 모든 네트워크 변경은 사전 승인을 위해 변경 자문 위원회를 통해 라우팅될 수 있다. 그 프로세스는 각 변경이 고유하고 수작업으로 만들어지며 예측할 수 없는 세계를 위해 설계되었다. 인간 엔지니어에 의한 수동 변경을 검토하는 적절한 사람은 인간 판단이 다양하기 때문에 진정한 위험 감소를 추가한다. 사전 프로덕션 환경에서 설계, 테스트되고, SoT에 대해 검증되고, 블래스트 반경 제한에 의해 제한되며, 수십 번 성공적으로 실행된 자동화 워크플로우에 적용된 동일한 논리는 위험 감소를 추가하지 않는다. 프로덕션에서 한 번도 실행되기 전에 위험 프로필이 확립된 작업에 지연 시간을 추가한다.

**사전 승인 자동화 패턴 (Pre-Approved Automation Pattern)**이 이를 해결한다. 변경 승인은 워크플로우 설계에 한 번 적용되며, 해당 워크플로우의 각 실행에 반복적으로 적용되지 않는다. 지점 활성화 워크플로우가 검증 단계를 통과하고, 관련 엔지니어링 및 운영 이해관계자들로부터 검토 및 승인을 받으며, 안전 제약이 활성화된 상태로 프로덕션에 배포되면, 그 워크플로우의 각 후속 실행은 새로운 승인이 필요한 새로운 변경이 아니다. 이미 승인된, 경계가 정해진 작업의 인스턴스다. 적절한 거버넌스 질문은 “이 실행이 승인된 범위 안에 있는가?“이지 “이 실행이 이루어져야 하는가?“가 아니다. 클라우드 제공자는 각 가상 네트워크 생성 요청을 승인하기 위해 사람을 필요로 하지 않는다. 서비스는 적절한 제약으로 설계되고, 철저히 테스트되며, 서비스로 승인되었다. 그 서비스 경계 내의 개별 고객 요청은 검토가 필요한 변경 이벤트가 아니다. 서비스 호출이다. 네트워크 자동화 서비스는 적절하게 설계되고 승인되면 동일한 방식으로 운영되어야 한다. 이 신뢰를 정당화하는 작업은 정확히 14.2절부터 14.4절이 설명하는 것이다. 명시적 서비스 계약, 관찰 가능한 출력, 제한된 블래스트 반경, 그리고 무언가 잘못될 때의 정의된 분류 경로. 그 작업이 변경 승인이며, 올바른 순간에 한 번 이루어진다.

14.5 성과, 비용, ROI#

자동화에는 비용이 든다. 실행 엔진, 오케스트레이터, 가시성 스택을 위한 컴퓨팅 인프라. SoT 레코드, 작업 이력, 텔레메트리를 위한 스토리지. 자동화 코드 구축, 테스트, 유지보수를 위한 엔지니어링 시간(그리고 이를 지원하는 AI 코딩 토큰). 플랫폼의 상업적 구성 요소를 위한 툴링 라이선스. 소비자가 문제를 제출하거나 새 기능을 요청할 때의 지원 부담. 이 비용들은 실제이며 반복적이다.

ROI 질문도 실제이며, 이를 피하는 네트워크 팀은 덜 정확하게 답할 재무 및 조달 팀에게 예산 결정을 양보한다. 프레임워크는 세 가지 구성 요소를 가진다.

자동화 비용: 플랫폼을 구축하고 운영하는 완전히 로드된 비용. 플랫폼 개발 및 유지보수에 할당된 엔지니어링 급여, 인프라 비용(자동화 인프라 자체의 컴퓨팅, 스토리지, 네트워킹), 툴링 라이선스, 그리고 운영 오버헤드. 이 숫자는 알 수 있으며 팀이 알아야 한다.
수동 동등물의 비용: 자동화 없이 동일한 서비스를 제공하는 데 드는 비용. 지점 활성화의 경우, 이는 사이트당 엔지니어링 시간에 그 작업을 할 엔지니어들의 시간당 비용을 곱한 것에, 오류 비용(수동 프로비저닝 실수로 인한 사고, Mean Time To Resolution (MTTR)와 영향받는 서비스로 측정)을 더한 것이다. 소매 체인 확장의 경우, 수동 비용은 자동화 투자를 분명히 정당화할 만큼 크다. 연간 두 번 프로비저닝되는 저용량 서비스의 경우, 계산은 다르다.
열린 역량의 가치: 자동화 없이는 불가능한 비즈니스 결과. 이것은 정량화하기 가장 어려운 구성 요소이며 가장 가치 있는 주장이다. 6개월 안에 120개 매장은 효율성 문제가 아니다. 이진 역량이다. 자동화 없이는 엔지니어링 예산과 관계없이 그 타임라인에서 불가능하다. “소매 확장 타임라인이 우리의 자동화 플랫폼에 달려 있다"고 명확히 말할 수 있는 네트워크 팀은 예산 협상이 아닌 전략적 대화에 참여하고 있다.

세 가지 축이 모든 자동화 서비스의 설계 공간을 정의하며, 각각은 제품 모델이 표면화하도록 강제하는 트레이드오프를 나타낸다.

속도: 서비스가 요청 제출에서 완료까지 얼마나 빠른가?
안전성: 서비스가 검증, 드라이런 단계, 롤백 경로를 통해 상황을 악화시키지 않는 데 얼마나 신뢰성 있게 작동하는가?
활용률: 성능 저하 없이 플랫폼이 처리할 수 있는 동시 요청은 몇 개인가?

이 축들은 긴장 관계에 있다. 광범위한 검증과 감독된 실행 단계를 통해 안전성을 극대화하면 지연 시간이 추가된다. 더 안전한 워크플로우는 일반적으로 더 느리다. 검증 단계를 줄여 속도를 극대화하면 위험이 증가한다. 동시 활용률을 극대화하면 실제 요청 볼륨으로 정당화되지 않을 수 있는 인프라 투자가 필요하다.

제품 프레이밍은 이 트레이드오프들을 서비스 계약에서 명시적으로 만들도록 강제한다. 소매 체인 인프라 책임자가 20개의 동시 배포가 안전한지 물을 때, 답변은 “테스트에서는 작동합니다"가 아니다. 답변은 플랫폼 설계에 대한 구체적인 진술이다. 동시 배포 용량은 24개의 활성 작업으로 제한되고, 각 배포는 독립적인 롤백 경로를 가지며, 가시성 시스템은 작업을 완료로 표시하기 전에 성공적인 상태 수렴을 확인한다. 그 진술들은 트레이드오프를 엔지니어링 구현 세부 사항이 아닌 제품 설계 결정으로 생각한 팀에서 나온다.

ROI 측정은 우선순위 결정에 직접 연결된다. 다음에 어떤 자동화를 구축할지는 어떤 비즈니스 결과가 네트워크 제한에 의해 가장 제한되는지에 의해 알려져야 한다. 어떤 수동 요청이 가장 많은 엔지니어링 시간을 소비하는지, 어떤 서비스가 수동 프로비저닝 중 가장 높은 실패율을 가지는지, 어떤 비즈니스 역량이 네트워크 처리량에 의해 차단되는지를 추적하는 팀은 비즈니스가 평가할 수 있는 우선순위 주장을 위한 데이터를 가진다. 그 데이터를 갖지 않는 팀은 기술적으로 흥미로운 것에 기반한 우선순위 주장을 하며, 그 주장들은 영향을 정량화한 팀에게 예산 주기를 내준다.

14.6 우선순위 결정과 로드맵#

모든 네트워크 자동화 팀이 일관되게 직면하면서도 공식적으로 답하는 경우가 드문 두 가지 질문이 있다. 다음에 어떤 작업을 자동화할지, 그리고 언제 요청을 거절할지. 제품 모델은 두 가지 모두에 공식적인 답변을 요구한다. 다음은 우선순위 결정 범주들이다.

비즈니스 영향: 자동화될 때 가장 높은 가치의 비즈니스 역량을 가능하게 하는 서비스는 무엇인가? 14.3절의 비즈니스 주도 서비스 맵이 이 질문의 입력이다. 자동화될 때 전략적 비즈니스 이니셔티브를 차단 해제하는 서비스는 자동화될 때 연간 12시간의 엔지니어링을 절약하는 서비스보다 우선순위가 높다.
빈도 곱하기 노력: 이 작업이 수동으로 얼마나 자주 수행되며, 각 발생마다 엔지니어링 시간이 얼마나 걸리는가? 매일 수행되고 매번 4시간이 걸리는 작업은 30분이 걸리는 주간 작업보다 200배의 ROI를 가진다. 발생당 상당한 노력이 드는 고빈도 수동 작업이 자동화의 가장 명확한 사례다.
위험 감소: 일부 작업은 빈도가 낮더라도 자동화할 가치가 있다. 인간 오류의 비용이 치명적이기 때문이다. 잘못 설정되면 수백 명의 고객에게 영향을 주는 라우트 누출을 야기하는 수동 BGP 피어링 변경은 연간 6번만 발생해도 자동화할 가치가 있다. 자동화는 처리량이 아니라 허용할 수 없는 결과를 가진 오류 모드를 제거하는 것으로 정당화된다.
소비자 수요: 다른 팀들이 적극적으로 요청하는 것은 무엇인가? 소비자 수요는 불완전한 신호다. 팀들은 종종 가장 가치 있는 것보다 기술적으로 가능하다고 알고 있는 것을 요청하기 때문이다. 하지만 동일한 팀에서 동일한 역량에 대한 일관된 요청은 서비스 인터페이스가 실제 사용 사례에 맞지 않는 곳에 대한 의미 있는 데이터다.

자동화 백로그 (Automation Backlog) 패턴은 자동화되지 않은 작업을 제품 팀이 기능 백로그를 다루는 것과 동일한 방식으로 다룬다. 우선순위가 정해지고, 추정되며, “완료"가 무엇을 의미하는지에 대한 명확한 수락 기준을 가진다. 완료는 “자동화가 실험실에서 성공적으로 실행되었다"가 아니다. 완료는 “자동화가 13장 13.5.2절에 설명된 신뢰 사다리 (Confidence Ladder) 단계를 통과하고, 문서화되어 있으며, 관련 소비자 팀이 셀프서비스로 사용할 수 있다"이다. 백로그는 이해관계자들에게 공개되어 무엇이 오고 있는지 보고 그에 맞게 계획을 세울 수 있다.

로드맵 소통은 로드맵 자체보다 더 중요하다. 분기별 주기로 의존 팀들과 공유되는 네트워크 자동화 로드맵은 신뢰 신호다. 자동화 팀의 작업을 비즈니스에 이해 가능하게 만든다. 소비 팀이 다음 분기에 플랫폼이 할 수 있고 없는 것 주변에서 자신들의 작업을 계획할 수 있게 한다. 네트워크 팀이 알지 못했던 요구사항을 소비 팀이 표면화할 수 있는 피드백 기회를 만든다.

소비자/이해관계자로부터의 피드백 루프는 로드맵 결정에 가장 가치 있는 입력이다. 어떤 팀이 가장 많은 예외를 제출하고 있는가? 어떤 자동화 출력이 소비자가 그것에 대해 행동할 수 있기 전에 수동 해석을 필요로 하는가? 현재 서비스 인터페이스가 소비자로 하여금 비즈니스 용어보다 네트워크 용어로 요청을 제출하도록 강제하는 곳은 어디인가? 이것들은 제품 피드백 신호이며, 체계적으로 포착하는 것이 실제 소비자 요구를 반영하는 로드맵과 자동화 팀이 소비자가 원해야 한다고 생각하는 것을 반영하는 로드맵을 구분한다.

이해관계자 미팅 주기는 명시적으로 명명할 가치가 있다. 대부분의 플랫폼에는 분기별, 적극적으로 개발 중인 플랫폼에는 월별로 열리는 반복 미팅, 즉 로드맵이 검토되고, 소비자 피드백이 수집되며, 다가오는 변경 사항이 전달되는 미팅은 상태 미팅이 아니다. 자동화 플랫폼이 사용자의 말을 듣는 제품처럼 행동하는 메커니즘이다. 이 단계를 건너뛰는 팀들은 올해 예산을 소비하면서 작년 문제를 해결하는 자동화를 구축한다.

13장 13.4.1절의 세 가지 저항 패턴이 제품 대화에서도 나타난다. 얼어붙은 전문가는 자신의 전문성을 구현 세부 사항으로 재정의하기 때문에 제품 프레이밍에 저항한다. 보이지 않는 ROI 패턴은 무언가 변할 것이라고 가정하기 때문에 문제 보고를 멈추는 소비자로 나타난다. 블랙박스 패턴은 성공적으로 완료되지만 무슨 일이 일어났는지에 대한 가시성을 제공하지 않아, 소비자가 수동 검증 없이 출력을 신뢰할 수 없게 만드는 서비스로 나타난다. 대응은 동일하다. 전문가를 서비스 계약의 설계자로 만들고, 명시적인 지표로 성공을 가시적으로 만들며, 서비스 출력에 투명성을 구축하라.

14.6.1 제품 관리 기능#

모든 팀이 전담 제품 관리자를 필요로 하는 것은 아니다. 모든 성숙한 자동화 프로그램은 제품 관리 기능을 수행하는 누군가를 필요로 한다.

소규모 팀에서는 네트워크 아키텍트나 시니어 NRE가 기술 업무와 함께 제품 관리 기능을 흡수할 수 있다. 백로그를 유지하고, 이해관계자 미팅을 진행하며, 비즈니스 정렬 대화를 소유한다. 이 규모에서는 주당 몇 시간이 기능을 살아 있게 유지하기에 충분하다.

플랫폼이 성장하면서, 외부 이해관계자와 내부 엔지니어링 간의 번역 작업이 상당해진다. 10개의 소비 팀을 서비스하고, 30개의 서비스가 프로덕션에 있으며, 경쟁하는 우선순위들 간의 협상을 필요로 하는 분기별 로드맵을 가진 플랫폼은 주당 몇 시간으로 제품 관리가 될 수 없다. 기능은 풀타임 역할이 된다.

네트워크 자동화 제품 관리자 (Network Automation Product Manager) 역할은 성숙한 자동화 프로그램을 가진 조직에서 떠오르고 있다. 그 책임은 다음과 같다.

플랫폼을 대표하여 이해관계자 관계를 소유한다. 소비 팀의 1차 연락 창구이며, 그들의 요구를 서비스 요구사항으로 변환하는 책임을 진다.
비즈니스 영향과 엔지니어링 현실 모두를 반영하는 우선순위 결정으로 비즈니스 주도 서비스 맵과 자동화 백로그를 유지한다.
로드맵을 외부에 전달하고 우선순위가 변할 때 기대치를 관리한다.
비즈니스 영향 지표를 정의하고 추적하여 플랫폼의 비즈니스 결과 기여를 리더십에 가시적으로 만든다.
팀 우선순위 논의에서 소비자 피드백을 대표하여 엔지니어링 우선순위가 내부 기술 선호도보다 실제 사용자 요구를 반영하도록 한다.

이 역할은 깊은 네트워킹 전문 지식을 필요로 하지 않는다. 네트워크 팀이 제공할 수 있는 것, 비즈니스가 필요로 하는 것, 그리고 그 두 가지가 어디서 일치하고 일치하지 않는지를 이해하는 능력을 필요로 한다. 네트워크 자동화 제품 관리자와 13장 13.2절의 기술 역할들 간의 협업 모델은 소프트웨어 제품 조직의 익숙한 패턴을 따른다. PM은 무엇이 구축될지와 왜를 소유하고, 네트워크 플랫폼 엔지니어와 자동화 개발자는 어떻게 구축될지를 소유하며, NRE는 프로덕션에서 어떻게 건강하게 유지될지를 소유한다. 이 그룹들 사이의 충돌은 모델의 결함이 아닌 특징이다. PM은 소비자 요구를 위해 밀어붙이고, 엔지니어들은 플랫폼 지속 가능성을 위해 밀어붙이며, 그들 사이의 긴장이 어느 쪽도 단독으로 도달할 것보다 더 나은 결정을 낳는다.

네트워크 자동화 제품 관리자 역할은 비기술적 역할을 기술 중심 팀 구조에 도입하기 때문에 일부 네트워크 조직에서 논란이 된다. 우려는 유효하다. 충분한 기술적 근거 없는 PM은 엔지니어링 팀이 지킬 수 없는 약속을 하고, 구현하기 간단한 요청과 근본적인 플랫폼 변경이 필요한 요청을 구별하는 데 어려움을 겪을 것이다. 해결책은 역할을 피하는 것이 아니라 협업 경계를 구체적으로 만드는 것이다. 두 가지 가드레일은 협상 불가능하다. PM은 범위와 타임라인에 대한 엔지니어링 리드의 명시적인 서명 없이 외부 이해관계자에게 납기일을 약속할 수 없으며, 엔지니어링 리드는 아직 설계되거나 추정되지 않은 플랫폼 변경이 필요한 어떤 약속에도 거부권을 가진다. 이 가드레일 없이, PM 역할은 새로운 실패 모드를 만든다. 외부 이해관계자들은 엔지니어링 팀이 사후에 알게 되는 약속을 받고, 신뢰성 손상은 PM이 아닌 플랫폼에 떨어진다.

플랫폼 전환 2년 후, 자신의 팀을 수동 운영에서 자동화 플랫폼으로의 전환을 이끈 네트워크 아키텍트 Jordi(13장에서 소개됨)는 소매 체인 통합 프로젝트 미팅에 참석하도록 요청받았다. 비즈니스 팀 리드가 온보딩 타임라인을 설명하고, 40개의 매장이 동시에 가동되어야 하는 6주 기간을 가리키며 물었다. “플랫폼이 준비되었습니까?” Jordi는 답을 알고 있었다. 플랫폼은 기술적으로 처리할 수 있었지만, 새로 활성화된 사이트의 모니터링 커버리지는 전체 텔레메트리가 수집되기 전까지 12시간의 지연이 있었다. 40개의 동시 활성화는 40개의 사이트가 반나절 동안 줄어든 가시성 커버리지로 운영된다는 것을 의미했다. 그는 직접적으로 말했고, 위험을 명명했으며, 전체 타임라인을 연장하지 않으면서 활성화를 3일 창에 걸쳐 분산시킬 온보딩 시퀀스 수정을 제안했다. 비즈니스 팀은 그것을 수락했다. 그 대화는 Jordi가 기술적 제약과 그것의 비즈니스 결과를 모두 이해하고 있었기 때문에 15분 만에 이루어졌다. 그 번역, 즉 플랫폼이 하는 것과 비즈니스가 경험하는 것 사이의 번역이 누가 직함을 가지든 관계없이 제품 관리 기능이다.

14.6.2 서비스 수명 주기 관리#

14.6.1절의 PM 역할 설명이 책임을 명명한다. 이 절은 모든 네트워크 서비스가 거치는 네 단계, 즉 정의, 제공, 운영, 발전에 걸쳐 그 책임들이 어떻게 운영되는지를 보여준다.

flowchart LR
    classDef def fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef del fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef ops fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef evo fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b

    DEF["정의<br/>서비스 계약<br/>비즈니스 정당성"]
    DEL["제공<br/>백로그 관리<br/>수락 기준"]
    OPS["운영<br/>SLA 모니터링<br/>소비자 소통"]
    EVO["발전<br/>버전 관리<br/>폐기"]

    DEF --> DEL --> OPS --> EVO
    EVO -->|"다음 버전"| DEF

    class DEF def
    class DEL del
    class OPS ops
    class EVO evo

정의

PM이 새 서비스에 처음 관여하는 것은 엔지니어링 팀이 자동화 코드의 첫 줄을 작성하기 전이다. 소비 팀이 요청을 가지고 온다. “매장을 더 빠르게 온보딩해야 합니다,” 또는 “우리 애플리케이션 팀이 티켓을 제출하지 않고는 네트워크 세그먼트를 프로비저닝할 수 없습니다.” PM의 이 단계에서의 작업은 그 요청을 14.2절의 세 가지 구성 요소 구조를 사용하여 경계가 정해진 서비스 계약으로 변환하는 것이다. 소비자가 제공하는 것(입력 표면), 그들이 관찰하는 것(출력 표면), 그리고 서비스가 소비자가 이해할 필요 없는 내부 의존성을 무엇을 가지는지. 그 번역은 엔지니어링에 전달되는 요구사항 문서가 아니다. 소비자가 필요로 하는 것과 플랫폼이 제공할 수 있는 것 사이의 협상이며, PM과 엔지니어링 리드가 모두 방에 있다.

PM은 “완료가 소비자의 관점에서 어떻게 보이는가"라는 질문을 소유한다. 엔지니어링 리드는 “완료가 플랫폼의 관점에서 어떻게 보이는가"를 소유한다. 정의가 완료되기 전에 두 질문 모두 답해져야 한다. 소비자를 만족시키지만 플랫폼 제약을 무시하는 서비스 계약은 제공 중에 재작업을 생성할 것이며, 플랫폼을 만족시키지만 소비자를 만족시키지 못하는 계약은 출시 후 사용되지 않을 것이다.

정의가 닫히기 전에, PM은 14.3절의 비즈니스 주도 서비스 맵에 새 서비스를 배치한다. 이 단계는 서비스가 명시적인 비즈니스 정당성을 가지고, 다른 자동화 백로그 항목들과의 상대적 우선순위가 일관된 기준으로 평가될 수 있도록 한다. 서비스가 어떤 비즈니스 역량을 가능하게 하는지 또는 그것의 부재의 영향이 무엇인지 명확히 할 수 없어 맵에 배치할 수 없는 서비스는 정의될 준비가 되지 않은 것이다. 이것은 엔지니어링을 시작하는 것이 아니라 소비자 대화로 돌아가라는 신호다.

제공

서비스 계약이 합의되면, PM은 개발을 통해 해당 자동화 백로그 항목을 관리한다. 수락 기준은 소비자 용어로 작성된다. “표준 지점 활성화가 제출 후 40분 내에 완료되며, 각 단계에서 수명 주기 이벤트가 방출된다,” “PE 라우터에 대한 gNMI 푸시가 오류 없이 완료된다"가 아니라. 그 차이가 중요하다. 구현 용어로 작성된 수락 기준은 소비자 경험이 실패하는 동안 통과할 수 있다. 푸시가 완료되었지만, 소비자는 알림을 받지 못했고 매장이 활성화되었는지 알 수 없다.

제공 중에, PM은 타임라인과 범위에 대한 모든 외부 소통을 소유한다. 엔지니어링 리드는 내부 기술 결정을 소유한다. 이 분리는 대부분의 자동화 프로젝트를 탈선시키는 패턴으로부터 엔지니어링 팀을 보호한다. 서비스 계약이 합의된 후 도착하는 범위 추가. 계약 서명 후의 모든 새 요구사항은 현재 제공의 수정이 아니라 자체 우선순위 결정을 가진 새 자동화 백로그 항목이다. PM의 작업은 소비 팀과 그 경계를 유지하는 것이다. 엔지니어링 팀은 소비자 관계를 손상시키지 않고는 그것을 할 수 없기 때문이다. 어떤 이해관계자든 언제든지 확장할 수 있는 제공 범위는 결코 완료되지 않는 제공이다.

운영

서비스가 가동되면, PM의 역할은 제공에서 신뢰 유지로 전환된다. 14.4절의 내부 SLA는 서비스가 약속하는 것을 정의한다. 가용성, 실행 지연 시간, 오류 예산, 에스컬레이션 경로. PM은 실패를 진단하기 위해서가 아니라, 이것은 NRE의 책임이며, 임계값이 접근하거나 위반될 때 소비자 대면 소통을 소유하기 위해 이 지표들을 모니터링한다. 자신에게 보라고 말해지지 않은 대시보드를 읽으면서 서비스가 SLA 밖에서 실행되고 있다는 것을 발견한 소비 팀은 SLA를 받은 것이 아니다. 관계 없이 지표를 받은 것이다. PM은 관계다.

PM은 또한 운영 피드백 수집 프로세스를 실행한다. 어떤 소비 팀이 가장 많은 예외 요청을 제출하고 있는가? 어떤 서비스 출력이 소비자가 그것에 대해 행동할 수 있기 전에 수동 해석을 필요로 하는가? 현재 입력 표면이 소비자로 하여금 비즈니스 용어보다 네트워크 용어로 요청을 제출하도록 강제하는 곳은 어디인가? 이 신호들은 불만이 아니다. 제품 데이터이며, PM의 작업은 이를 체계적으로 집계하고 엔지니어링 팀이 그것에 대해 행동할 수 있을 만큼 충분한 구체성을 가지고 로드맵 대화에 가져오는 것이다. “소비자들이 지점 활성화에 불만족한다"로 도착하는 피드백은 실행 가능하지 않다. “지난 12개의 예외 요청 중 7개가 어떤 정의된 등급과도 일치하지 않는 팝업 사이트를 위한 것이었고, 7개 모두 직접적인 네트워크 팀 관여가 필요했다"로 도착하는 피드백은 실행 가능하다. 입력 표면의 격차를 명명하고 그 운영 비용을 정량화한다.

발전

발전을 멈춘 서비스는 처음 설계했을 때 처리하도록 설계된 것과 소비자가 실제로 필요로 하는 것 사이의 불일치를 축적한다. PM은 이전 단계에서 수집된 운영 피드백과 비즈니스 주도 서비스 맵의 변화하는 항목들로부터 알려져, 서비스가 언제 어떻게 발전하는지에 대한 결정을 소유한다.

모든 발전이 동일한 운영적 결과를 가지는 것은 아니다. 새 선택적 입력 필드를 추가하거나 더 풍부한 출력 이벤트를 방출하는 변경은 첨가적이다. 기존 소비자는 영향을 받지 않으며, 새 기능의 채택은 선택적이다. 필수 필드 이름 변경, 출력 이벤트 제거, 또는 SLA 약속 변경은 그것에 의존하는 모든 소비자에 대한 기존 계약을 깨뜨린다. PM은 발전이 시작되기 전에 이 두 범주를 구분해야 한다. 그것들은 다른 프로세스를 필요로 하기 때문이다. 첨가적 변경은 마이너 업데이트로 제공될 수 있는 반면, 파괴적 변경은 버전 증가, 마이그레이션 경로, 그리고 변경이 배포되기 전에 소비 팀에 전달된 폐기 타임라인을 필요로 한다.

폐기 타임라인이 많은 팀이 실패하는 곳이다. 엔지니어링 팀은 자연스럽게 새 버전이 안정되는 즉시 이전 버전을 제거하고 싶어한다. 소비 팀은 자연스럽게 마이그레이션할 용량이 생길 때까지 의존하는 버전에 머물고 싶어한다. PM은 그 두 위치 사이의 창을 협상하고 양측에 약속한다. 소비 팀이 마이그레이션을 계획하기에 충분히 일찍 전달된, 이전 버전이 더 이상 지원되지 않는 특정 날짜. 이 프로세스 없이 발전된 서비스는 서비스 계약이 구축하도록 설계된 신뢰를 침식한다. 프로덕션에서 파괴적 변경을 발견하는 소비 팀은 기술적 실패를 경험한 것이 아니다. 관계 실패를 경험했으며, 그것은 회복하기 더 어렵다.

14.7 요약#

네 가지 주제가 이 장을 고정한다.

스크립트가 아닌 서비스: 제품 전환은 실행되는 자동화를 구축하는 것에서 다른 사람들이 의존하는 서비스를 제공하는 것으로의 전환이다. 네트워크 서비스를 제품으로 패턴이 이 재구성을 명명한다. 서비스가 1차 결과물이고, 기저 네트워크는 구현 세부 사항이다. 서비스 계약 패턴이 이를 구체적으로 만드는 결과물이다. 입력 표면, 출력 표면, 내부 의존성에 대한 명시적이고 버전화된 정의로, 소비자가 이해할 필요 없는 네트워크 구현 세부 사항을 노출하지 않으면서 소비자가 제공해야 하는 것과 관찰할 수 있는 것으로 인터페이스를 경계 짓는다.

비즈니스 정렬은 구조적이다: 비즈니스 영향을 측정하려면 자동화를 장치 동작에서 위로가 아닌 비즈니스 결과에서 아래로 설계해야 한다. 비즈니스 주도 서비스 맵이 도구다. 네트워크 서비스를 그것이 가능하게 하는 비즈니스 역량과 저하 또는 사용 불가능의 비즈니스 영향에 명시적으로 매핑하는 것. 이 매핑을 유창하게 만들 수 있는 팀은 다른 사업 부서들이 새로운 계획을 세울 때 전화하는 팀이다. 그 팀들은 이미 “네트워크가 무엇을 가능하게 하는가"라는 질문에 답했기 때문이다. 그렇게 할 수 없는 팀은 타임라인이 이미 설정된 후에 새 이니셔티브에 대해 듣는 팀이며, 네트워크가 제때 준비될 수 없는 이유를 설명하는 자리에 남겨진다. 자동화 백로그는 동일한 논리를 우선순위 결정에 적용한다. 다음에 어떤 자동화를 구축할지는 어떤 자동화가 기술적으로 가장 흥미로운가가 아니라 어떤 비즈니스 결과가 네트워크 제한에 의해 가장 제한되는지에 의해 결정되어야 한다.

필요하기 전에 SLA와 지원 모델을: 첫 번째 주요 사고 전에 신뢰성 약속, 에스컬레이션 경로, 실패 소유권을 정의하는 것이 플랫폼을 스크립트 모음에서 구분하는 것이다. 내부 SLA는, 가용성, 실행 지연 시간, 오류 예산, 에스컬레이션 경로의 네 가지 구성 요소와 함께, 신뢰를 명시적으로 만드는 도구다. 세 가지 실패 모드 분류법(자동화 버그, 플랫폼 실패, 네트워크 실패)은 사고가 팀 사이에서 떨어지는 것을 방지하는 분류 프레임워크다. 사전 승인 자동화 패턴이 이를 확장한다. 워크플로우가 안전 제약이 활성화된 상태로 설계, 테스트, 승인되면, 개별 실행은 재승인이 필요한 새로운 변경이 아닌 승인된 작업의 인스턴스다. SLA 모델과 거버넌스 모델 모두 첫 번째 사고 후가 아니라 전에 확립되어야 한다.

서비스 수명 주기 전반에 걸친 제품 관리 기능: 모든 네트워크 서비스는 네 단계, 즉 정의, 제공, 운영, 발전을 거치며, 제품 관리 기능이 네 단계 전반에 걸친 연속성을 소유한다. 정의 단계에서, PM은 엔지니어링이 시작되기 전에 소비자 요청을 경계가 정해진 서비스 계약으로 변환한다. 제공 단계에서, PM은 범위 경계를 유지하고 외부 소통을 소유한다. 운영 단계에서, PM은 소비자 대면 SLA 소통을 소유하고 피드백을 실행 가능한 제품 데이터로 집계한다. 발전 단계에서, PM은 첨가적 변경과 파괴적 변경을 구분하고, 버전 관리 결정을 소유하며, 엔지니어링과 소비 팀 모두와 폐기 타임라인을 협상한다. 이 기능 없이, 서비스는 임시로 정의되고, 수락 기준 없이 제공되며, 소비자 관계 없이 운영되고, 공지 없이 발전한다. 그것과 함께, 플랫폼은 사용자의 말을 듣고 시간이 지나면서 그들의 신뢰를 얻는 제품처럼 행동한다.

이 장에서 설명된 제품 규율은 5부가 설명하는 것의 전제 조건이다. 폐쇄 루프 자동화는 실시간 복구 결정을 내린다. 자가 치유 네트워크는 인간 개입 없이 실패에 대응한다. 자율 네트워크는 소비자를 대신하여 라우팅 및 프로비저닝 결정을 내린다. 이 각각은 플랫폼이 그 특정 행동에 대한 직접적인 인간 승인 없이 소비자가 의존하는 행동을 취하는 것을 나타낸다. 정의된 서비스 경계, 관찰 가능한 상태, 신뢰성 약속, 그리고 임계값이 초과될 때 명확한 에스컬레이션 없이, 자율 운영은 제품이 아니다. 계약 없이 행동하는 예측 불가능한 시스템이다. 이 장의 작업이 자율 운영을 신뢰할 수 있는 것으로 만드는 것이며, 이것이 5부가 구축하는 기반이다.

참고 자료 및 추가 학습#

Continuous Delivery, Jez Humble, Dave Farley (Addison-Wesley, 2010). 소프트웨어 제공 수명 주기에 관한 기초 텍스트. 릴리스를 신뢰할 수 있고 저위험 운영으로 만드는 배포 파이프라인 구축 방법. 이 장의 서비스 수명 주기 패턴, 개발에서 프로덕션 운영까지, 은 네트워크 자동화에 적용된 이 원칙들에서 도출된다.
The Art of SLOs, Google SRE Workbook (sre.google에서 이용 가능). 서비스 수준 목표, 오류 예산, 신뢰성 약속과 기능 속도 간의 관계를 정의하기 위한 실용적인 가이드. 14.4절의 내부 SLA 모델은 내부 소비자를 서비스하는 자동화 플랫폼에 이 원칙들을 적용한다.
Empowered, Marty Cagan (Wiley, 2020). 기술 조직을 위한 제품 관리 프레임워크. 기능이 아닌 결과 중심으로 팀을 구성하는 방법, 제품 팀에 “완료"가 무엇을 의미하는지 정의하는 방법, 엔지니어링 작업과 비즈니스 우선순위 간의 전략적 정렬을 유지하는 방법. 14.6.1절에서 설명된 네트워크 자동화 제품 관리자 역할은 이 프레임워크에서 도출된다.
Team Topologies, Matthew Skelton, Manuel Pais (IT Revolution Press, 2019). 13장에서 참조되었으며, 여기서도 관련이 있다. 자동화 플랫폼이 내부 소비자로서 스트림 정렬 팀을 서비스하는 플랫폼 팀 모델이 이 장의 제품 모델이 지원하도록 설계된 조직 구조다.
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). 고성과 기술 조직과 저성과 조직을 구분하는 것에 대한 실증 연구. 14.4절과 관련이 있다. 데이터는 변경 승인 위원회가 더 나은 안정성 결과와 관련이 없지만 더 느린 제공과 강하게 관련이 있음을 보여준다. 사전 승인 자동화 패턴과 변경 거버넌스가 각 실행 시점이 아닌 워크플로우 설계 시점에 속한다는 주장의 증거 기반이다.

💬 Found something to improve? Send feedback for this chapter