Mar 28, 2026 · 5654 words · 27 min read

8. 프레젠테이션 계층#

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

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

자동화는 제 역할을 했다. 결과가 보이지 않았다.

일주일 후, 팀은 애플리케이션 팀이 직접 요청을 제출하고 상태를 볼 수 있는 셀프서비스 포털을 빠르게 배포했다. 정오까지 한 시간에 47개의 VLAN 요청을 받았다. 모두 유효했고 형식도 맞았다. 문제는 포털에 인증 모델이 없었다는 것이다. URL을 가진 누구에게서도 제출을 수락했다. 모든 요청이 플랫폼 전체 관리자 권한을 가진 단일 API 토큰으로 실행되었다. 속도 제한도, 승인 게이트도, 누가 무엇을 제출했는지에 대한 감사 추적도 없었다.

자동화는 작동했다. 접근 모델은 그렇지 않았다.

이 두 가지 실패는 모두 프레젠테이션 실패다. 하나는 피드백 루프의 부재고, 다른 하나는 가드레일의 부재다. 이 챕터는 그 격차를 좁힌다.

8.1. 기초 개념#

8.1.1. 맥락#

지금까지 다룬 모든 구성 요소는 내부를 향하고 있다. 다른 블록들을 향하거나 플랫폼을 이해하는 엔지니어들을 향한다. Source of Truth (SoT)는 자동화 시스템을 위한 네트워크 인텐트를 보유한다. 실행기는 장치에 변경을 적용한다. Observability는 결과를 검증한다. Orchestrator는 이 모든 것을 조율한다. 이 블록들 각각은 UI, API, 또는 둘 다를 가지고 있으며, 플랫폼을 구축하고 운영하는 사람들을 위해 설계되었다. 상호작용해야 하는 모든 사람을 위한 것이 아니다.

Presentation (Layer) 계층은 외부를 향한다. 내부를 이해할 필요가 없는 대상에게 플랫폼을 접근 가능하게 만드는 것이 역할이다. 네트워크 서비스를 요청하는 애플리케이션 팀, 지난 분기에 무엇이 변경되었는지 묻는 보안 감사자, 사람 없이 인프라를 프로비저닝하는 CI/CD 파이프라인.

챕터 3에서 프레젠테이션 블록은 사람과 외부 시스템을 향한 NAF 프레임워크의 가장자리에 위치했다. 챕터 6은 가시성 시각화와 프레젠테이션 사이의 경계를 확립했다. 네트워크 텔레메트리 위에 직접 구축된 대시보드는 설계 친화성에 의해 가시성 블록에 속한다. 이러한 대시보드를 비엔지니어에게 노출하고, 접근을 제어하고, 포털에 내장하는 방법은 프레젠테이션의 관심사다. 챕터 7은 비동기 워크플로가 상태 엔드포인트와 알림 훅을 필요로 한다는 것을 확립했다. 프레젠테이션 계층이 둘 다 제공한다.

8.1.2. 목표#

프레젠테이션 계층은 세 가지 아키텍처 기능에 직접 매핑되는 세 가지 목표를 제공한다.

일관된 접근 모델을 가진 안정적이고 인증된 API를 제공한다. 사람이든 기계든 모든 소비자는 사전 통지 없이 변경되지 않는 버전화되고 접근 제어된 계약을 통해 플랫폼과 상호작용해야 한다. 기반 블록들은 교체되거나, 업그레이드되거나, 재구성될 수 있다. 소비자 대면 계약은 안정적으로 유지되어야 한다. 인증과 권한 부여는 이 경계에서 시행되며, 도구별로 중복되지 않고 중앙화된다.
각 소비자 유형의 워크플로에 맞는 인터페이스를 통해 모든 소비자 유형을 제공한다. 네트워크 엔지니어와 애플리케이션 팀 관리자는 서로 다른 요구사항, 서로 다른 수준의 기술적 깊이, 그리고 자동화가 어떻게 소통하는지에 대한 서로 다른 기대를 가지고 있다. 프레젠테이션 계층은 여러 인터페이스를 제공한다. GUI 포털, Command Line Interface (CLI), ChatOps 통합, 모두 동일한 API와 동일한 접근 모델을 기반으로 하며, 행동을 시작한 대상에게 상태가 표시된다.
플랫폼을 외부 시스템에 양방향으로 연결하고 소비자가 이미 사용하는 채널을 통해 결과를 전달한다. 애플리케이션 팀은 이미 ServiceNow에서 일한다. CI/CD 파이프라인은 이미 버전 제어 시스템에서 실행된다. 플랫폼은 그들이 있는 곳에서 만나야 한다. 그들의 시스템에서 요청을 받고 결과를 동일한 시스템으로 돌려보내야 하며, 워크플로에 새로운 도구를 요구해서는 안 된다.

8.1.3. 기둥#

세 가지 기둥이 이 목표들을 지원하며, 기능당 하나씩이다.

API 계층: 기반. 버전화되고, 인증되고, RBAC가 시행되고, 안정적인 계약. 인증과 다중 테넌시는 도구별이 아닌 여기서 시행된다. 다른 모든 인터페이스는 그 위에 구축된다.
클라이언트 인터페이스: 모든 소비자 대면 인터페이스(GUI 포털, CLI, 모바일, ChatOps)가 동일한 기반 API의 서로 다른 형식.
통합 및 알림: 외부 시스템 연결(ITSM, CI/CD 파이프라인, 메시징 시스템)과 아웃바운드 결과 전달(웹훅, 콜백, 푸시 알림).

8.1.4. 범위#

프레젠테이션 계층은 표면을 제공한다. 생산하지 않는다.

범위 내:

API 계층: 모든 소비자를 위한 인증, 권한 부여, 버전 관리, 속도 제한
그 API 위에 구축된 클라이언트 인터페이스: GUI 포털, CLI, ChatOps, 모바일 인터페이스
외부 통합: ITSM 워크플로, CI/CD 파이프라인 훅, 웹훅 전달
아웃바운드 알림: 상태 콜백, 푸시 알림, 메시징 채널 이벤트
비엔지니어 대상에게 노출될 때의 운영 대시보드(접근 제어, 대상 범위 지정, 포털 내장; 기반 메트릭 아키텍처는 챕터 6에 속함)

범위 외:

데이터 생산(Observability, 챕터 6)
구성 렌더링과 템플릿 처리(소스 오브 트루스, 챕터 4)
워크플로 실행과 감사 기록 생성(Orchestrator, 챕터 7)

비즈니스 로직을 축적하기 시작하는 프레젠테이션 계층(어떤 워크플로를 실행할지 결정하고, 네트워크 모델에 대해 입력을 검증하고, 워크플로 상태를 관리하는)은 다른 무언가로 성장한 것이다. 이러한 책임은 오케스트레이터와 소스 오브 트루스에 속한다. 포털이 네트워크 정책이나 재시도 로직을 인코딩하기 시작하면 아키텍처 경계가 붕괴되어 플랫폼을 독립적으로 발전시키기 어려워진다.

8.2. 기능#

세 가지 목표와 기둥은 세 가지 핵심 기능을 통해 실현되며, 각각은 하나의 목표와 하나의 기둥에 직접 매핑된다.

API 계층: 모든 소비자를 위한 계약과 접근 모델
클라이언트 인터페이스: 그 계약 위에 구축된 인터페이스
통합 및 알림: 외부 시스템에 대한 연결과 아웃바운드 전달

graph LR

    subgraph 목표
        direction TB
        A1[안정적이고 인증된 API와 일관된 접근 모델]
        A2[각 소비자 유형에 맞는 적절한 인터페이스]
        A3[외부 시스템과의 양방향 통합]
    end

    subgraph 기둥
        direction TB
        B1[API 계층: 버전화, 인증, 안정적]
        B2[클라이언트 인터페이스: GUI, CLI, ChatOps, 모바일]
        B3[통합 및 알림: ITSM, CI/CD, 웹훅]
    end

    subgraph 기능
        direction TB
        C1[API 계층]
        C2[클라이언트 인터페이스]
        C3[통합 및 알림]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. API 계층#

챕터 4는 SoT 자체 API를 심층적으로 다루었다. 자동화 시스템이 인텐트 데이터를 쿼리하는 방법, 소비 패턴(REST, GraphQL, 웹훅), 네트워크 구성에 대한 읽기/쓰기 모델. 여기서 논의되는 API는 목적이 다르다. 전체로서의 자동화 플랫폼 소비자를 위한 외부 대면 계약이다. SoT API가 “네트워크가 어떻게 보여야 하는가?“에 답한다면, 프레젠테이션 계층 API는 “자동화 플랫폼이 무엇을 하고 있으며, 어떻게 상호작용하는가?“에 답한다. 둘 다 REST API일 수 있지만, 서로 다른 접근 모델을 가진 서로 다른 대상을 제공한다.

프레젠테이션 계층 API는 기반이다. 모든 소비자 인터페이스(포털, CLI, ITSM 양식, ChatOps 봇, AI 에이전트)는 이 계층의 호출자다. 인증, RBAC, 버전 관리, 속도 제한이 여기서 시행된다. 잘 설계하지 않으면 위의 모든 것이 그 문제를 상속한다.

프레젠테이션 API는 내부 블록 인터페이스를 미러링해서는 안 된다. SoT API에 직접 프록시하는 /v1/sot/vlans/ 엔드포인트나 오케스트레이터 작업 ID를 래핑하는 /v1/orchestrator/jobs/ 엔드포인트를 노출하면 소비자를 내부 구현 세부사항에 묶게 된다. 하나의 블록을 다른 것으로 교체할 때, 해당 ID를 저장한 모든 CI/CD 파이프라인을 업데이트해야 한다. 프레젠테이션 API는 대신 플랫폼 수준의 개념을 노출해야 한다. 어떤 오케스트레이터가 처리했든 관계없이 서비스 요청을 나타내는 /v1/requests/ 엔드포인트, 어떤 블록이 각 데이터를 제공했는지 드러내지 않고 SoT와 가시성에서 집계된 VLAN의 현재 상태를 반환하는 /v1/services/vlan/ 엔드포인트. 소비자는 안정적인 계약을 얻고, 내부 구현은 그 뒤에서 자유롭게 발전할 수 있다.

8.2.1.1. API가 노출하는 것#

API는 두 가지 범주의 엔드포인트를 노출한다.

읽기 엔드포인트(Read endpoints): 워크플로 상태와 이력, 감사 기록, SoT와 가시성 블록에서 집계된 장치 및 서비스 상태. 애플리케이션 팀이 요청 상태를 확인하고, 감사자가 변경 기록을 검토하고, 모니터링 시스템이 플랫폼 상태를 검증하는 데 사용하는 쿼리들이다.
쓰기 엔드포인트(Write endpoints): 워크플로 트리거, 서비스 요청 제출, 대기 중인 게이트 승인 또는 거부, 실행 중인 작업 취소. 쓰기 엔드포인트는 더 강력한 권한 부여가 필요하다. 서로 다른 역할은 서로 다른 쓰기 작업에 접근할 수 있어야 한다. 애플리케이션 팀 구성원은 요청을 제출할 수 있지만 임의의 워크플로를 트리거할 수 없다. 네트워크 엔지니어는 대기 중인 게이트를 승인할 수 있지만 워크플로 정의를 수정할 수 없다.

읽기/쓰기 구분은 계약 안정성도 형성한다. 읽기 엔드포인트는 무기한 안정적으로 유지되어야 한다. 1년간 실행된 대시보드가 업스트림 스키마가 변경되었다고 작동이 멈추어서는 안 된다. 쓰기 엔드포인트는 명시적으로 버전화되어야 하며, 호환성이 깨지는 변경 전에 지원 중단 통지가 있어야 한다.

8.2.1.2. 버전 관리와 안정성#

소비자 대면 API는 버전화되어야 한다. 프레젠테이션 계층 API는 계약이고, 블록 내부는 구현이다. 오케스트레이터, SoT, 가시성 블록의 내부 리팩토링이 외부 호출자를 깨뜨려서는 안 된다.

표준 접근 방식: URL 접두사(/v1/, /v2/) 또는 Accept 헤더로 버전화하고, 정의된 지원 중단 기간 동안 이전 버전을 유지하고, 변경 로그를 통해 호환성이 깨지는 변경사항을 소통한다. 8개월간 /v1/workflows/trigger를 호출해 온 CI/CD 파이프라인이 엔드포인트가 경고 없이 이동했다는 것을 월요일에 발견해서는 안 된다.

8.2.1.3. 인증과 권한 부여#

인증은 “당신은 누구인가?“에 답한다. 권한 부여는 “당신은 무엇을 할 수 있는가?“에 답한다.

많은 팀이 권한 부여보다 인증을 먼저 구현한 다음, 누군가가 가져서는 안 되는 유효한 토큰으로 47개의 요청을 제출했을 때 “인증됨"과 “권한 부여됨"이 서로 다른 문제라는 것을 발견한다.

네트워크 자동화 플랫폼의 인증 패턴:

SSO / LDAP 통합: 기업 표준. 엔지니어와 애플리케이션 팀이 기업 신원으로 인증한다. 관리할 별도 자격 증명이 없고, 누군가가 떠날 때 자동으로 비활성화된다.
OAuth 2.0 / OIDC: 외부 시스템과 웹 포털 사용자를 위해. 장기 자격 증명 대신 단기 토큰을 생성한다.
범위가 지정된 API 토큰(Scoped API tokens): CI/CD 파이프라인과 자동화 스크립트의 프로그래밍 방식 접근을 위해. 각 토큰은 정의된 만료 기간과 특정 권한 집합으로 범위가 지정된다. 모든 소비자가 사용하는 공유 관리자 토큰은 인증이 아니다. 모든 호출자를 동시에 중단하지 않고는 취소할 수 없는 공유 비밀번호다.

RBAC를 통한 권한 부여. 역할은 도구 기능이 아닌 운영 책임에 매핑되어야 한다. 네트워크 자동화를 위한 시작 모델:

read-only: 데이터 보기만 가능, 행동 트리거 불가
operator: 사전 승인된 워크플로 트리거, 게이트 승인, 서비스 요청 제출
engineer: 전체 워크플로 관리, SoT 쓰기 접근, 모든 감사 기록 보기
admin: 플랫폼 구성, 사용자 관리, 자격 증명 교체

각 역할은 하위 역할의 모든 권한을 상속한다. 엔지니어는 운영자가 할 수 있는 모든 것과 추가로 SoT 쓰기 및 워크플로 관리를 할 수 있다.

flowchart TD
    RO[읽기 전용]
    OP[운영자]
    ENG[엔지니어]
    ADM[관리자]

    RO -->|추가: 워크플로 트리거 + 게이트 승인| OP
    OP -->|추가: SoT 쓰기 접근 + 워크플로 관리| ENG
    ENG -->|추가: 플랫폼 구성 + 사용자 관리| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

RBAC는 API 경계에서 시행된다. 기반 블록들은 프레젠테이션 계층에서 인증된 API 호출만 받는다. 소비자 신원을 독립적으로 관리하지 않는다. 다중 테넌시는 데이터 범위 지정을 통해 구현된다. 모든 쿼리는 호출자의 조직 범위로 필터링된다. Building B의 애플리케이션 팀은 Building A의 소매 팀의 요청을 볼 수 없어야 한다. 이것은 처음부터 설계되어야 한다. 평탄한 데이터 모델에 다중 테넌시를 나중에 추가하는 것은 고통스러운 재구성 작업이다.

감사 추적은 승인된 요청과 함께 거부된 요청도 캡처해야 한다. 누가 무엇을 시도하다 거부되었는지는 허용된 것만큼 컴플라이언스에 중요하다. 프레젠테이션 계층은 챕터 7의 워크플로 감사 추적과 함께 이 기록을 생성한다. 챕터 12는 이 모델을 비밀 교체, 코드로서의 정책, 컴플라이언스 기반 자동화 흐름으로 확장한다.

8.2.1.4. 속도 제한#

속도 제한 없는 자동화 소비자는 오케스트레이터의 큐를 소진시킨다. 47개 요청 인시던트에는 악의적인 행위자가 필요하지 않았다. 동기부여된 팀, URL, 그리고 제한 없음만 있으면 됐다.

API 경계에서의 속도 제한: 토큰당 제한(소비자당 분당 요청), 버스트 제한(동시 진행 중 요청), 작업별 제한(펌웨어 업그레이드 워크플로는 장치당 한 번에 하나 이상 실행되어서는 안 됨). 속도 제한 응답은 몇 시간 후 타임아웃으로 나타나는 조용한 큐 채움이 아닌 Retry-After 헤더가 포함된 HTTP 429를 반환해야 한다.

8.2.1.5. REST, GraphQL, 그리고 MCP 인터페이스#

REST가 기본이다. GraphQL보다 버전화하고, 추론하고, 캐시하기 더 단순하다. 네트워크 자동화 팀은 GraphQL의 소비자 중심 쿼리 유연성이 거의 필요하지 않으며 추가 복잡성에 대한 의미 있는 운영 비용을 지불한다. 예외: 플랫폼이 상당히 다른 쿼리 패턴을 가진 많은 수의 서로 다른 소비자 유형을 제공하는 경우, GraphQL은 과도한 데이터 페치와 여러 특화된 엔드포인트의 필요성을 줄일 수 있다. 정당화된 선택이지만 거의 올바른 첫 번째 선택은 아니다.

Model Context Protocol (MCP) 인터페이스는 프레젠테이션 계층의 AI 인터페이스다. 사람 운영자가 CLI를 통해 플랫폼에 접근하고 애플리케이션 팀이 포털을 통해 접근하는 것처럼, Large Language Model (LLM) 기반 에이전트는 MCP 서버를 통해 접근한다. 에이전트는 다른 모든 호출자와 동일한 RBAC 모델에 따라 추론이 요구하는 순서로 도구(워크플로 상태 쿼리, 수정 트리거, 감사 로그 읽기)를 호출한다. 이것은 챕터 7(섹션 7.2.7)에서 소개된 에이전틱 오케스트레이션 패턴과 직접 연결된다. 프레젠테이션 계층의 MCP 서버는 에이전트와 각 개별 블록 사이의 하드코딩된 통합 없이 이러한 패턴을 전체 플랫폼에서 작동 가능하게 만드는 인터페이스다.

REST와 MCP는 누가 상호작용을 주도하는지에서 다르다. REST 통합에서 소비자는 어떤 엔드포인트를 어떤 순서로 호출할지 미리 알고 있다. CI/CD 파이프라인은 POST /v1/requests/vlan을 호출한 다음 완료될 때까지 GET /v1/requests/{id}를 폴링한다. 순서가 코드에 고정되어 있다. MCP에서 Large Language Model (LLM) 기반 에이전트는 각 선행 호출의 결과를 기반으로 런타임에 어떤 도구를 어떤 순서로 호출할지 결정한다. 소비자는 미리 결정된 호출 그래프를 가진 파이프라인이 아니다. 다음에 무엇을 할지 결정하기 전에 각 결과를 읽는 추론 시스템이다. MCP 서버는 사용 가능한 도구와 그 스키마를 정의하고, 에이전트가 사용 방법을 결정한다. 이것은 MCP를 REST로 구현하면 개발자가 가능한 모든 호출 순서를 미리 예측해야 하는 개방형 운영 쿼리(“building-b와 코어 사이의 연결 문제 조사”)에 적합하게 만든다. 또한 권한 부여를 더 민감하게 만든다. 광범위한 도구 접근 권한을 가진 에이전트는 접근 모델이 명시적으로 설계되지 않은 방식으로 작업을 결합할 수 있다. RBAC 모델은 서버 수준뿐만 아니라 도구 수준에서 적용되어야 한다.

8.2.2. 클라이언트 인터페이스#

클라이언트 인터페이스는 API 위에 구축된 인터페이스다. 동일한 기반 플랫폼의 서로 다른 형식으로, 각각이 서로 다른 소비자 유형에 적합하다. RBAC 모델은 어떤 인터페이스가 사용되든 관계없이 균일하게 적용된다.

8.2.2.1. GUI와 셀프서비스 포털#

웹 포털은 비엔지니어를 위한 주요 인터페이스다. 설계 원칙은 점진적 공개(progressive disclosure)다. 기반 복잡성을 노출하지 않고 적절한 양의 정보를 적절한 대상에게 보여주는 것이다.

애플리케이션 팀은 세 단계 뷰를 본다. 제출됨, 진행 중, 완료됨. AWX 작업 ID가 아닌 평이한 언어로 “24개 스위치에서 사전 점검 실행 중"이라고 읽히는 상태 세부사항. 네트워크 엔지니어는 장치별 사전 점검 결과, 승인 또는 거부 행동이 있는 승인 게이트, 필요한 경우 전체 워크플로 추적을 본다. 관리자는 구성 및 감사 쿼리를 포함한 모든 것을 본다.

읽기와 쓰기 인터페이스는 서로 다른 설계 요구사항을 가진다. 읽기 전용 상태 대시보드는 상대적으로 허용적일 수 있다. 플랫폼의 모든 엔지니어가 자신의 요청의 현재 상태를 볼 수 있다. 쓰기 경로(요청 제출, 게이트 승인, 실행 중인 작업 취소)는 입력 검증, 확인 단계, 그리고 행동이 확정되기 전에 무슨 일이 일어날지에 대한 명확한 설명이 필요하다.

새로운 서비스 요청 양식의 제출 버튼이 검증 계층 없이 양식과 워크플로 사이에서 오케스트레이터 API를 직접 호출하는 포털을 구축한 팀을 본 적이 있다. 사용자가 기존 할당과 충돌하는 서브넷을 제출하면 형식이 없는 오케스트레이터 스택 추적으로 오류가 반환된다. 프레젠테이션 계층은 요청이 오케스트레이터에 도달하기 전에 SoT 모델에 대해 입력을 검증하고, 검증이 실패할 때 명확하고 실행 가능한 오류를 반환해야 한다.

채택 위험은 인터페이스에서 가장 높다. 팀이 이미 일하는 방식에 맞지 않아서 아무도 사용하지 않는 기술적으로 올바른 포털은 매일 아침 모두가 여는 도구의 더 단순한 통합보다 가치를 덜 제공한다. 이미 ServiceNow에서 생활하는 애플리케이션 팀은 별도로 배우고 로그인해야 하는 새 포털보다 ServiceNow 양식을 통해 더 일관되게 요청을 제출할 것이다. 인시던트 조율을 위해 이미 Slack을 사용하는 엔지니어링 팀은 추가 인증이 필요한 브라우저 링크보다 Slack 메시지를 통해 승인 게이트 알림에 더 빠르게 행동할 것이다. 친숙함은 채택 시 마찰을 줄이고 일상적인 사용에서 오류율을 줄인다. 새로운 인터페이스를 구축하는 것과 이미 알고 있는 도구에서 사용자를 만나는 것 중 선택이 있다면, 통합이 거의 항상 올바른 첫 번째 단계다.

8.2.2.2. CLI#

자동화 플랫폼을 위한 CLI는 챕터 9의 영역인 장치 CLI가 아니다. 이것은 플랫폼 자체에 대한 명령줄 인터페이스다. 엔지니어가 브라우저를 열지 않고 자동화를 트리거하고, 검사하고, 관리하는 데 사용하는 도구.

엔지니어는 반복적인 작업에서 GUI보다 셸 스크립트를 선호하는 것과 같은 이유로 CLI를 선호한다. 구성 가능성, 속도, 스크립트 가능성. CLI 명령은 별칭을 지정하고, 다른 명령으로 파이프하고, 장치 목록에 루프하고, 대응 절차서에 통합하거나, 관리하는 인프라와 함께 저장소에 커밋할 수 있다. 포털 클릭은 할 수 없다. 새벽 2시 인시던트 중, 5초 만에 기억에서 타이핑한 명령이 탐색하고 인증하는 데 20초가 걸리는 포털보다 빠르다. CI/CD 파이프라인의 경우 CLI는 파싱 없이 파이프라인 통과/실패 조건에 직접 매핑되는 구조화된 종료 코드(성공에 0, 실패에 비0)를 생성한다. 엔지니어는 또한 고위험 작업에서 CLI 도구를 더 신뢰한다. 파라미터가 셸 이력에 보이고, 감사 가능하며, 재현 가능하다.

CLI는 포털이 존재할 때에도 자리를 차지한다. 새벽 2시 인시던트 중 브라우저를 열고, 로그인하고, 워크플로를 탐색하고, 양식을 클릭하는 것은 단일 명령을 실행하는 것보다 느리다. CI/CD 파이프라인의 경우 CLI는 원시 API 호출보다 선호된다. 환경 변수에서 인증을 처리하고, 구조화된 종료 코드를 생성하며, 무언가 실패할 때 사람이 읽을 수 있는 출력을 제공한다.

자동화 플랫폼 CLI 설계 원칙:

API 작업에 예측 가능하게 매핑되는 일관된 명사-동사 명령 구조(workflow run, workflow status, request list)
파이프라인 스크립트가 결과를 파싱할 수 있도록 --json 플래그를 통한 기계 읽기 가능 출력
환경 인식 구성: 스크립트에 하드코딩되지 않고 구성 파일이나 환경 변수에서 읽는 API 엔드포인트와 토큰
API에 적용되는 동일한 RBAC가 CLI에도 적용된다. 운영자 수준 권한이 있는 토큰은 어떤 인터페이스가 사용되든 관리자 수준 작업을 트리거할 수 없다

8.2.2.3. 인스턴트 메시징과 모바일#

Slack, Teams 및 유사한 플랫폼은 네트워크 자동화에서 이중 역할을 한다. 알림 채널(프레젠테이션 계층이 이벤트를 푸시)과 상호작용 인터페이스(엔지니어가 명령을 보냄) 모두다. 이 이중 역할을 이해하는 것이 아키텍처에 중요하다. 알림 알림을 받는 동일한 워크스페이스가 승인 흐름을 지원해야 하며, 이미 해당 채널을 모니터링하고 있는 엔지니어의 컨텍스트 전환을 줄인다.

상호작용 인터페이스로서 메시징 플랫폼은 대화형 명령을 API 호출로 변환하는 봇을 통해 작동한다. 봇은 얇다. 메시지를 파싱하고, 발신자의 신원으로 프레젠테이션 계층 API 호출에 매핑하고, 채널에 맞게 응답을 형식화한다. 세 가지 패턴이 실제로 잘 작동한다.

승인 흐름(Approval flows): “승인"과 “거부” 버튼이 있는 Slack 메시지는 네트워크 엔지니어가 Slack을 떠나지 않고 대기 중인 게이트에 행동할 수 있게 한다. 버튼 클릭은 Slack의 OAuth와 플랫폼 SSO 통합을 통해 해결된 엔지니어의 신원으로 API 승인 엔드포인트를 호출한다.
상태 쿼리(Status queries): @netbot status app-payments는 형식화된 채널 메시지로 현재 워크플로 상태를 반환한다.
빠른 행동(Quick actions): @netbot compliance-check building-b는 경량 검증 워크플로를 트리거하고 결과를 인라인으로 게시한다.

모바일 인터페이스는 포털과 CLI가 도달하지 못하는 특정 대상을 제공한다. 현장에서 물리적으로 일하는 데이터센터 기술자. 랙에서 라인 카드를 교체하는 기술자는 노트북이 열려 있지 않다. 손이 바쁘고, 자세가 어색할 수 있다. 장치 바코드를 스캔하고, 현재 자동화 상태(자동화가 관리함, 마지막 배포 14일 전, 대기 중인 변경 없음)를 확인하고, 물리적 교체를 확인하고, 적절한 수정 워크플로를 트리거할 수 있는 모바일 앱은 워크스테이션으로 돌아가지 않고 물리적 작업을 자동화 플랫폼에 연결한다. RBAC 모델이 적용된다. 기술자의 토큰은 역할이 허용하는 작업으로 범위가 지정된다. 인터페이스는 현장 관련 데이터로 범위가 지정된다. 전체 플랫폼 뷰가 아닌 장치 신원, 현재 상태, 대기 중인 작업, 간단한 트리거 행동.

동일한 RBAC 모델이 적용된다. 봇은 SSO를 통해 엔지니어를 인증하고, 해당 엔지니어의 역할로 범위가 지정된 토큰으로 요청을 전달한다. 읽기 전용 접근 권한이 있는 엔지니어는 포털을 통해서처럼 Slack을 통해서도 워크플로를 트리거할 수 없다.

알림 대상으로서, 메시징 채널은 프레젠테이션 계층에서 이벤트 기반 업데이트를 받는다. 배포 완료, 실패 알림, 승인 게이트 요청, 심각한 워크플로 오류. 알림 라우팅은 구성 정책이다. 어떤 이벤트가 어떤 대상을 위해 어떤 채널로 가는지. 엔지니어는 전용 운영 채널에서 실패 세부사항을 받는다. 애플리케이션 팀은 ITSM 티켓을 통해 완료 상태를 받는다. 온콜 엔지니어는 PagerDuty를 통해 심각한 실패를 받는다.

8.2.2.4. 언제 구축할 것인가 대 내장 UI를 수용할 것인가#

거의 모든 블록에는 이미 UI가 있다. AWX에는 워크플로 포털이 있다. Nautobot에는 웹 인터페이스가 있다. Grafana에는 대시보드가 있다. 이러한 내장 UI는 플랫폼을 이해하는 엔지니어 대상에게 충분하다. 전용 프레젠테이션 계층을 구축하는 결정이 기본값이 되어서는 안 된다.

실용적인 결정 순서:

모든 소비자가 블록 UI를 이미 사용하는 엔지니어인가? 내장 UI를 사용하라. 커스텀 포털을 구축하지 마라.
비엔지니어가 자동화를 요청하거나 추적해야 하는가? 포털 또는 ITSM 통합이 필요하다.
ITSM이 이미 모든 서비스 요청이 관리되는 곳인가? ITSM을 프레젠테이션 계층으로 채택하거나 주요 소비자로 통합하라. ITSM의 워크플로 엔진, 승인 모델, 알림 시스템이 요청 패턴에 충분하다면 ITSM이 프레젠테이션 계층이 되도록 하라. 더 강력한 API 계약, 크로스 블록 상태 뷰, 또는 ITSM이 깔끔하게 시행할 수 없는 RBAC가 필요하다면, ITSM과 블록 사이의 얇은 전용 계층이 ITSM이 사용자 대면 인터페이스로 남아있으면서 이러한 속성을 제공한다.
여러 블록에 걸쳐 균일하게 적용되는 RBAC가 필요한가? 어떤 클라이언트 인터페이스를 구축하든 관계없이 중앙화된 인증이 있는 API 계층이 필요하다.
커스텀 포털을 장기적으로 유지하기로 약속할 수 있는가? 불확실하다면 ITSM 통합으로 시작하라. ITSM이 필요한 접근 패턴에 불충분하다고 증명될 때만 포털을 구축하라.
소비자가 ITSM 양식으로 표현할 수 없는 세부사항을 입력하거나 볼 필요가 있는가? 복잡한 입력 필드(YAML 스니펫, 토폴로지 파라미터, 서브넷 할당 미리보기), SoT 모델에 대한 인라인 검증, 또는 장치별 드릴다운이 있는 풍부한 상태 뷰는 일반적으로 ITSM 양식 빌더가 깔끔하게 지원하는 것을 초과한다. 소비자가 정기적으로 그 수준의 구체성이 필요하다면 커스텀 포털이 운영 비용을 정당화한다.

커스텀 포털은 비엔지니어가 ITSM이 깔끔하게 표현할 수 없는 접근이 필요할 때, 또는 내장 UI 중 어느 것도 제공하지 않는 단일 크로스 블록 상태 뷰가 필요할 때 구축할 가치가 있다. 가장 흔한 실수는 필요성이 실재한다는 것을 검증하기 전에 구축하는 것이다.

8.2.2.5. 문서화와 보고#

프레젠테이션 계층의 두 가지 관련된 읽기 전용 출력이 비동기적으로 자동화 지식을 소비하는 대상에게 제공된다. 문서 소비자(현재 네트워크 서비스 상태를 이해해야 하는 팀)와 보고 소비자(주기적인 요약과 컴플라이언스 증거가 필요한 관리자와 감사자).

코드로서의 문서 패턴이 여기에 적용된다. 템플릿 언어(Jinja2, Markdown)를 사용하여 라이브 플랫폼 데이터에서 생성된 문서, 자동화 코드베이스와 함께 버전 관리, 모든 변경 시 재생성. 생성된 문서에 내장된 Mermaid 다이어그램은 수동으로 유지되는 도면이 아닌 SoT의 실제 토폴로지를 반영할 수 있다. 마찬가지로 가시성 블록이 원시 메트릭에 적용하는 정규화 로직(챕터 6에서 다룸)은 여기서 재사용될 수 있다. 보고 템플릿이 정규화 작업을 복제하지 않고 감사자를 위한 표 형식 요약을 생성하기 위해 동일한 정규화된 시계열 데이터를 쿼리한다.

**자동 생성 문서(Auto-generated documentation)**는 수동 유지 없이 라이브 플랫폼 데이터를 읽기 가능하고 공유 가능한 아티팩트로 변환한다. 배포된 모든 네트워크 서비스에 대해 생성된 문서는 SoT의 서비스 정의, 가시성의 현재 운영 상태, 오케스트레이터 감사 추적의 변경 이력을 결합할 수 있다. 소스 데이터가 항상 최신이기 때문에 문서는 자동으로 최신 상태를 유지한다. 오케스트레이터의 워크플로 정의는 또 다른 소스다. 문서 생성기는 워크플로 정의에서 사람이 읽을 수 있는 대응 절차서를 생성하여, 절차서가 설명하는 것이 자동화가 실제로 하는 것과 일치하도록 보장할 수 있다.
**보고(Reporting)**는 실시간 뷰가 아닌 주기적인 요약이 필요한 관리 및 컴플라이언스 대상에게 제공된다. 주간 변경 요약(몇 개의 워크플로가 실행되었는지, 성공률, 평균 기간, 건드린 장치)이 운영 검토에 공급된다. 컴플라이언스 내보내기(기간의 모든 변경 기록, 감사 제출을 위한 구조화된)는 오케스트레이터의 감사 추적과 프레젠테이션 계층의 권한 부여 로그에서 조합된다. SLA 및 용량 보고서(프로비저닝 시간 추세, 장치 클래스별 오류율, 대기 중인 요청 백로그)는 용량 계획과 서비스 개선 논의에 공급된다.

운영 대시보드는 설계 의도에 의해 두 챕터에 걸쳐 있다. 챕터 6은 데이터 아키텍처를 다룬다. 무엇이 수집되는지, 어떻게 정규화되는지, 엔지니어 대상을 위한 텔레메트리 위에 직접 구축된 대시보드. 프레젠테이션 계층의 참여는 동일한 대시보드가 비엔지니어 대상에게 노출될 때 시작된다. 셀프서비스 포털에 내장하거나, 애플리케이션 팀이 자신의 서비스만 볼 수 있도록 접근을 범위 지정하거나, 현장 사용을 위한 모바일 친화적인 뷰를 구조화할 때. 기반 메트릭은 가시성 블록에 남는다. 접근 모델과 인터페이스 컨텍스트는 프레젠테이션의 관심사다.

운영 대시보드(챕터 6)와의 구분은 소비자와 시간적 프레이밍이다. 대시보드는 실시간 결정을 내리는 엔지니어를 위한 현재 상태를 보여준다. 문서와 보고서는 비엔지니어가 비동기적으로 소비하는 스냅샷이다. 기반 데이터는 같을 수 있다. 인터페이스와 주기가 다르다.

8.2.3. 통합 및 알림#

프레젠테이션 계층은 양방향으로 외부 시스템에 연결한다. 자동화를 트리거하는 이벤트를 수신하고 요청을 시작한 시스템에 결과를 전달한다. 이것이 소비자의 워크플로와 플랫폼의 워크플로가 수렴하는 곳이다.

API 계층과의 구분은 방향성과 시작이다. API 계층은 인바운드 요청을 처리한다. 소비자가 플랫폼을 호출하고 응답을 기다린다. 통합 및 알림은 현재 상호작용을 시작하지 않은 시스템에 플랫폼이 연락하는 것에 관한 것이다. ServiceNow 티켓에 상태 업데이트를 푸시하고, 비동기적으로 기다리는 CI/CD 파이프라인에 웹훅 콜백을 전달하고, 특정 서비스를 모니터링하는 Slack 채널에 이벤트를 게시한다. API 계층은 호출에 답한다. 이 섹션은 이벤트를 보낸다. 둘 다 동일한 인증 모델과 RBAC 경계를 사용한다. 차이는 시작 방향이다. 소규모에서는 단일 구성 요소가 두 패턴을 깔끔하게 처리한다. 더 큰 규모에서 아웃바운드 이벤트 전달(재시도 로직, 데드 레터 큐, 구독 관리 포함)은 일반적으로 자체 운영 관심사가 있는 별개의 구성 요소가 된다. 이것이 이 모델이 두 가지를 별개의 기능으로 구분하는 이유다.

8.2.3.1. ITSM 통합#

ITSM 플랫폼은 네트워크 자동화 아키텍처에서 두 가지 별개의 위치를 차지하며, 이 구분이 설계에 중요하다. 첫 번째 위치에서 ITSM 플랫폼이 프레젠테이션 계층이다. 양식이 사용자 인터페이스를 정의하고, 워크플로 엔진이 승인과 알림을 처리하며, 자동화 API가 ITSM 워크플로 내에서 호출된다. 이 모델에서는 외부 통합이 없다. ITSM이 프레젠테이션 계층 외부에 있지 않기 때문이다. ITSM이 프레젠테이션 계층이다. 두 번째 위치에서 전용 프레젠테이션 계층이 존재하고 ITSM 플랫폼은 동기화하는 소비자 중 하나다. 요청이 ITSM 웹훅을 통해 도달하고 상태 업데이트가 ITSM 티켓으로 다시 흐른다. 세 번째 역할도 흔하다. SoT 데이터 소스로서의 ITSM. CMDB에 권위 있는 자산이나 서비스 레코드가 있을 때 SoT가 페더레이션된 데이터 소스로 쿼리할 수 있다(챕터 4에서 다룸). 하지만 이 역할의 ITSM은 사용자 대면 자동화 인터페이스에서 아무 역할도 하지 않는다.

이 섹션의 나머지 부분은 통합 패턴(두 번째 위치)을 설명한다. 프레젠테이션 계층으로서의 ITSM 패턴(첫 번째 위치)은 ITSM 플랫폼의 워크플로 엔진, 승인 모델, 알림 시스템이 요청 패턴에 충분하고 사용자와 블록 사이에 별도의 계층을 도입하는 것을 피하고 싶을 때 올바른 선택이다.

ITSM 통합은 소비자가 자동화 플랫폼의 존재를 알 필요가 없어야 할 때 구축하는 것이다. 애플리케이션 팀은 이미 ServiceNow에서 일한다. 가장 사용 가능한 인터페이스는 이미 사용하고 있는 것이다.

“신규 네트워크 서비스 요청"을 위한 ServiceNow 양식은 SoT 모델이 필요로 하는 정확한 필드를 캡처하고 API 계층이 기대하는 구조화된 형식으로 제출한다. 양식이 프레젠테이션 계층이다. 소비자는 API 호출을 절대 보지 않는다. 제출 시, 프레젠테이션 계층이 페이로드를 검증하고, ITSM 통합이 사용하는 서비스 계정 토큰을 인증하고, 구조화된 요청을 오케스트레이터로 전달한다.

요청이 발사된 후, 티켓은 거의 실시간으로 워크플로 상태를 반영해야 한다. “SoT 검증 완료”, 그 다음 “사전 점검 실행 중: 24개 스위치”, 그 다음 “승인 게이트: 엔지니어 승인 대기”, 그 다음 “완료: 24/24 스위치 구성됨”. 이 양방향 동기화는 일회성 웹훅보다 더 복잡하다. 프레젠테이션 계층이 오케스트레이터 상태 이벤트를 구독하고 영속적인 이벤트 구독 또는 폴링 조정자를 사용하여 티켓 업데이트로 변환해야 한다.

많은 조직에서 ITSM 티켓이 변경 관리 기록이다. 권위 있는 감사 추적이 오케스트레이터에 있더라도 프레젠테이션 계층은 티켓에 변경 관리 요구사항을 충족하기에 충분한 정보가 포함되도록 해야 한다. 두 기록은 서로 다른 대상에게 제공된다. ITSM 티켓은 요청자와 그들의 관리자에게 제공된다. 오케스트레이터 감사 기록은 네트워크 엔지니어와 컴플라이언스 감사자에게 제공된다.

ITSM 통합에는 한계가 있다. 정의된 상태를 가진 구조화된 양식 기반 요청 워크플로에 적합하다. 실시간 운영 쿼리, 복잡한 워크플로 추적 검사, 또는 엔지니어가 빠르게 반복해야 하는 고급 사용자 작업에는 적합하지 않다. ITSM이 대부분의 비엔지니어 요청을 커버하고 CLI나 포털이 나머지를 커버한다는 것을 알고 플랫폼을 설계하라.

8.2.3.2. CI/CD 파이프라인 통합#

네트워크 리소스를 프로비저닝하는 배포 파이프라인은 정의된 단계에서 프레젠테이션 계층 API를 호출하고, 구조화된 입력을 전달하며, 성공 또는 실패 결과가 반환될 때까지 블록한다. 파이프라인은 범위가 지정된 토큰이 있는 서비스 계정으로 실행된다. 네트워크 워크플로를 트리거하고 상태를 읽기에 충분한 권한, 그 이상 없음.

이것은 또한 CLI가 자동화 컨텍스트에서 자리를 차지하는 곳이다. netauto workflow run vlan-deploy --params params.json --wait를 실행하는 파이프라인 단계는 인라인으로 API 페이로드를 구성하는 원시 HTTP 호출보다 디버그하기 쉽고, 버전 관리하기 쉽고, 교체하기 쉽다. CLI의 구조화된 종료 코드는 파싱 없이 파이프라인 단계의 통과 또는 실패 조건에 직접 매핑된다.

8.2.3.3. 푸시 알림과 웹훅 전달#

워크플로가 완료되거나, 승인 게이트에 도달하거나, 실패할 때, 프레젠테이션 계층은 올바른 채널을 통해 올바른 대상에게 알린다. 알림 라우팅은 정책 결정이지 하드코딩된 매핑이 아니다. 엔지니어는 전용 Slack 채널에서 실패 세부사항을 받는다. 애플리케이션 팀은 티켓 업데이트를 통해 완료 상태를 받는다. 온콜 엔지니어는 PagerDuty를 통해 심각한 실패를 받는다. 라우팅 규칙은 구성이지 코드가 아니다.

웹훅 전달은 들어오는 웹훅의 아웃바운드 대응물이다. 워크플로를 트리거할 때 콜백 URL을 등록한 호출자는 워크플로가 완료될 때 HTTP POST를 통해 결과를 받는다. 실패 시 전달 보장, 재시도 정책, 페이로드 스키마가 API 계약의 일부다. 조용히 실패하는 콜백(재시도 없음, 로그 없음, 알림 없음)은 콜백이 전혀 없는 것보다 나쁘다. 호출자가 결과가 전달되었다고 가정하기 때문이다.

8.2.4. 솔루션 환경#

여기에 나열된 도구들은 설명 목적의 예시이며 추천이 아니다. 팀의 역량, 기존 도구, 운영 제약에 대해 평가하라.

프레젠테이션 챕터는 파트 2의 다른 어떤 챕터보다 솔루션 환경과 다른 관계를 가진다. 프레젠테이션으로만 존재하는 도구는 거의 없다. 모든 블록에는 이미 UI가 있다. 아키텍처 질문은 “어떤 프레젠테이션 도구를 사용해야 하는가?“가 아니다. “언제 각 블록의 내장 UI를 수용하고, 언제 그 위에 전용 프레젠테이션 계층을 구축하는가?“다.

두 가지 모델이 성숙한 자동화 플랫폼에 공존한다.

내장 모델(Embedded model): 각 블록의 대상을 위해 내장 UI를 사용한다. 엔지니어는 워크플로 관리를 위해 오케스트레이터 포털, 인벤토리를 위해 SoT 웹 UI, 네트워크 상태를 위해 가시성 대시보드를 사용한다. 모든 소비자가 도구를 이해하는 엔지니어이고 크로스 블록 뷰가 필요하지 않을 때 효과적이다. 운영 오버헤드가 낮다. 추가로 실행할 시스템이 없다.
전용 프레젠테이션 모델(Dedicated Presentation model): 단일화된 경험을 제공하는 블록 위의 계층을 구축하거나 채택한다. 비엔지니어가 접근이 필요할 때, 단일 뷰에서 크로스 블록 상태가 필요할 때, 또는 RBAC 요구사항이 개별 도구의 내장 권한에 깔끔하게 매핑되지 않을 때 필요하다.

접근 방식	예시	사용 시기
블록별 내장 UI	AWX 포털, Nautobot UI, Grafana	엔지니어 대상; 도구별 RBAC 수용 가능; 크로스 블록 뷰 불필요
주요 인터페이스로서 ITSM	ServiceNow, Jira Service Management	엔터프라이즈 조직; 비엔지니어가 이미 ITSM 사용; 양식 기반 요청 흐름
커스텀 셀프서비스 포털	React/Vue 앱, Django 앱	비엔지니어가 접근 필요; 블록 전반의 균일한 RBAC; 승인 흐름이 있는 셀프서비스
API 게이트웨이	Kong, AWS API Gateway, NGINX	서로 다른 인증 요구를 가진 다중 소비자; 속도 제한; 버전 관리 시행
네트워크 특화 포털	Itential, NSO northbound UI	내장 RBAC와 ITSM 어댑터가 있는 네트워크 중심 플랫폼
개발자 포털	Backstage	단일 진입점이 필요한 많은 내부 플랫폼이 있는 대규모 조직

내장 UI 내부에 무엇이 있는지 이해하는 것은 커스터마이징 결정에 중요하다. NetBox는 Django(Python) 위에 구축되었다. 웹 인터페이스와 REST API는 Django 뷰와 Django REST Framework 엔드포인트다. Nautobot은 같은 계보를 공유한다. Infrahub는 FastAPI를 사용한다. 이러한 SoT 도구의 “프레젠테이션 구성 요소"는 성숙한 웹 프레임워크다. 플러그인, 커스텀 뷰, 시리얼라이저 확장을 통해 커스터마이징 가능하다. 그것이 강점(잘 문서화되고 프로덕션 수준)이자 제약(주로 SoT 사용 사례가 아닌 셀프서비스 포털 사용 사례를 위해 설계된 프레임워크 내에서 커스터마이징)이다.

위 표의 ITSM 행은 외부 통합이 아닌 프레젠테이션 계층으로서의 ITSM을 나타낸다. 조직이 모든 서비스 요청의 진입점으로 ServiceNow나 Jira Service Management를 표준화했을 때, ITSM이 프레젠테이션 계층이다. 자동화 API는 ITSM이 자체 워크플로의 일부로 내부적으로 호출하는 것이다. 사용자와 ITSM 사이에 별도의 게이트웨이가 없다. 게이트웨이는 ITSM과 하위 블록 사이에 있다.

모든 접근 방식을 관통하는 하나의 아키텍처 원칙이 있다. 프레젠테이션 계층은 얇아야 한다. 시스템이 아닌 인터페이스다. 비즈니스 로직은 오케스트레이터와 SoT에 속한다. 프레젠테이션 계층은 변환하고, 인증하고, 라우팅한다. 자동화 결정을 내리기 시작하는 순간 경계가 붕괴된다.

8.3. 구현 예시#

8.3.1. 두 가지 인터페이스, 세 가지 대상, 하나의 플랫폼#

파트 2 전반에 걸쳐 캠퍼스 네트워크를 따라왔다. app-payments를 위한 VLAN 서비스 요청이 챕터 4에서 SoT에 모델링되고, 챕터 5에서 실행기가 배포하고, 챕터 6에서 가시성이 검증하고, 챕터 7에서 오케스트레이터가 처음부터 끝까지 조율했다. 다루지 않은 것은 세 가지 서로 다른 대상이 그 워크플로와 어떻게 상호작용하는가다.

이 캠퍼스에서 프레젠테이션 계층은 세 가지 구성 요소로 구성된다. ServiceNow는 더 넓은 조직을 위한 주요 인터페이스다. 애플리케이션 팀은 ServiceNow 내에서 완전히 요청을 제출하고 상태를 추적하며, 이것은 자체 워크플로 자동화의 일부로 프레젠테이션 계층의 API를 통해 라우팅된다. 감사 뷰가 있는 커스텀 포털은 엔지니어링과 컴플라이언스 대상에게 제공된다. 네트워크 엔지니어는 사전 점검 결과를 검토하고 승인 게이트에 행동하며, 보안 감사자는 읽기 전용 감사 인터페이스를 통해 복합 변경 기록을 쿼리한다. 두 인터페이스는 동일한 API 계층을 공유하며, 이는 프레젠테이션 계층 내에 위치하고 요청이 기반 블록에 도달하기 전에 인증, RBAC, 버전 관리를 시행한다.

세 가지 대상

애플리케이션 팀은 ServiceNow 양식을 통해 요청을 제출한다. 그들은 서비스가 언제 준비되는지, 실패하면 무슨 일이 일어났는지 알고 싶다. AWX나 Nautobot을 열 필요가 절대 없어야 한다. ServiceNow가 그들의 프레젠테이션 계층이다. 플랫폼 API는 그들이 절대 보지 않는 것이다.
네트워크 엔지니어는 워크플로 중에 승인 게이트 알림을 받았다(챕터 7, 3단계). 24개 대상 스위치의 사전 점검 결과를 보고, 승인 또는 거부하고, 결과를 검사할 수 있어야 한다. 그들의 인터페이스는 커스텀 포털이다. ServiceNow 양식보다 더 상세하지만 여전히 팀 범위로 제한된다.
보안 감사자는 세 달 후 질문을 가지고 온다. 누가 이 VLAN을 요청했는지, 누가 승인했는지, 어떤 버전의 배포 워크플로가 실행되었는지, 영향 받은 스위치의 이전과 이후 상태가 무엇인지? 그들의 인터페이스는 포털의 감사 뷰다. 읽기 전용으로, 아무것도 트리거할 능력이 없다.

두 가지 프레젠테이션 인터페이스

API 계층은 프레젠테이션 계층 내의 공유 기반이다. ServiceNow와 커스텀 포털 모두 기반 블록에 도달하기 전에 모든 요청을 그것을 통해 라우팅한다. 세 가지 역할 기반 토큰을 시행한다. 애플리케이션 팀의 운영자 토큰(자신의 요청 읽기, 새 요청 제출), 네트워크 엔지니어의 엔지니어 토큰(범위 내 모든 요청 읽기, 게이트 승인 또는 거부), 감사자의 읽기 전용 토큰(전체 플랫폼에 걸쳐 감사 기록 쿼리, 쓰기 접근 없음). 어떤 인터페이스도 우회하지 않는다.

flowchart TD
    subgraph Consumers["소비자"]
        AT[애플리케이션 팀]
        NE[네트워크 엔지니어]
        SA[보안 감사자]
    end

    subgraph PL[프레젠테이션 계층]
        SN[ServiceNow]
        PORTAL[커스텀 포털]
        API[API 계층: 인증 · RBAC · 버전 관리]
    end

    subgraph Blocks["플랫폼 블록"]
        ORC[오케스트레이터]
        SOT[소스 오브 트루스]
        OBS[가시성]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

1단계: 애플리케이션 팀 인터페이스로서의 ServiceNow

애플리케이션 팀이 ServiceNow 양식을 작성한다. 서비스 이름(app-payments), 서브넷 크기(/24), 건물(building-b), 요청 팀, 비즈니스 정당성. 제출 시, ServiceNow가 자체 워크플로 자동화의 일부로 플랫폼 API 계층을 직접 호출한다. API 계층은 SoT 데이터 모델에 대해 페이로드를 검증하고, ServiceNow가 사용하는 서비스 계정 토큰을 인증하고, 구조화된 요청을 오케스트레이터로 전달한다.

검증이 실패하면(예를 들어, 요청된 건물이 SoT의 어떤 사이트와도 일치하지 않거나, 서브넷 크기가 기존 할당과 충돌하는 경우), API 계층은 오케스트레이터 워크플로가 시작되기 전에 즉시 구조화된 오류를 반환한다. ServiceNow는 명확한 실패 이유로 티켓을 업데이트한다. “building-c가 사이트 레지스트리에서 찾을 수 없음” 또는 “서브넷 /24가 building-b의 기존 할당 10.22.14.0/24와 충돌함.” 애플리케이션 팀은 티켓에서 거부를 보고 네트워크 엔지니어 참여 없이 요청을 수정할 수 있다. 부분적인 워크플로 상태가 생성되지 않고 사가 롤백이 필요하지 않다. 워크플로가 시작되지 않았기 때문이다.

워크플로가 진행되면서, 프레젠테이션 계층은 오케스트레이터 상태 이벤트를 구독하고 이를 ServiceNow 티켓 업데이트로 변환한다. “SoT 검증 완료”, “사전 점검 실행 중: 24개 스위치”, “승인 게이트: 엔지니어 승인 대기”, “완료: 24/24 스위치 구성됨”. 애플리케이션 팀은 오케스트레이터, SoT, AWX의 존재를 모르면서 티켓이 업데이트되는 것을 지켜본다.

2단계: 승인 게이트 인터페이스

워크플로가 승인 게이트에 도달하면 오케스트레이터가 일시 중지하고 이벤트를 내보낸다. 프레젠테이션 계층이 이를 수신하고, Building B를 담당하는 네트워크 엔지니어를 식별하고, 게이트 검토 페이지로 직접 링크가 있는 승인 요청을 Slack 채널에 보낸다. 검토 페이지는 스위치별 사전 점검 결과를 보여준다. 어떤 것이 통과했는지, 어떤 것이 실패했는지, 어떤 것이 건너뛰어졌는지, 그리고 왜. 엔지니어는 포털에서 승인하거나 거부한다. 행동이 기록된다. 누가, 어떤 인터페이스에서, 어떤 시간에, 어떤 토큰으로 승인했는지.

3단계: 감사 뷰

세 달 후, 보안 감사자가 프레젠테이션 계층 API를 쿼리한다. “VLAN app-payments, Building B의 전체 변경 기록을 보여주세요.” 읽기 전용 감사 엔드포인트가 세 가지 소스를 집계한다.

오케스트레이터의 실행 기록(챕터 7, 섹션 7.2.4): 어떤 워크플로 버전이 실행되었는지, 모든 단계 입력과 출력, 모든 사가 보상 행동
SoT 변경 기록(챕터 4): VLAN 정의의 이전과 이후 상태
프레젠테이션 계층 자체의 권한 부여 로그: 누가 요청을 제출했는지, 어떤 토큰을 사용했는지, 누가 게이트를 승인했고 언제

응답은 감사자가 변경 관리 기록에 첨부할 수 있는 구조화된 문서다. 세 가지 기반 블록 중 어느 것도 이 복합 기록을 독립적으로 생성하도록 설계되지 않았다. 프레젠테이션 계층이 감사자의 읽기 전용 토큰으로 그들의 개별 API에서 이를 조합했다.

이것이 보여주는 것

챕터 7의 동일한 10단계 워크플로가 이러한 대상 중 누구도 기반 플랫폼을 이해할 필요 없이 두 가지 프레젠테이션 인터페이스를 통해 세 가지 서로 다른 대상에게 제공되었다. ServiceNow가 더 넓은 조직에 자체 프레젠테이션 인터페이스로 제공되었다. 애플리케이션 팀은 AWX, Nautobot, 또는 그 뒤에 있는 오케스트레이터를 인식하지 않고 매일 이미 사용하는 도구를 통해 요청을 추적했다. 커스텀 포털이 엔지니어링과 컴플라이언스 대상에게 제공되었다. 네트워크 엔지니어는 팀 요청으로 범위가 지정된 깔끔한 승인 인터페이스를 검토했고, 감사자는 단일 읽기 전용 뷰를 통해 세 블록에서 조합된 복합 변경 기록을 쿼리했다. 두 인터페이스 모두에 동일한 접근 모델을 시행하는 하나의 API 계층이 플랫폼을 보이지 않게 만들지 않고 접근 가능하게 만들었다.

8.4. 요약#

Presentation (Layer) 계층은 파트 2의 마지막 구성 요소이며, 사후 고려로 취급될 가능성이 가장 높은 것이다. 그 아래의 블록들이 실질적인 작업을 수행한다. 인텐트 보유, 변경 적용, 결과 검증, 워크플로 조율. 프레젠테이션 계층은 그 중 아무것도 생성하지 않는다. 하지만 없으면 플랫폼은 그것을 구축한 사람들만 접근 가능하며, 다른 모든 대상은 사람 중개자에게 의존하게 된다.

API 계층이 기반이다. API 경계에서 시행되는 인증과 권한 부여(도구별이 아닌)가 접근 가능한 자동화와 위험한 자동화를 구분한다. 버전 관리와 안정적인 계약이 플랫폼과 모든 업데이트에서 호출자를 깨뜨리는 프로토타입을 구분한다. Model Context Protocol (MCP) 인터페이스는 동일한 접근 모델을 Large Language Model (LLM) 기반 에이전트로 확장하여 챕터 7에서 소개되고 챕터 17에서 더 발전시킨 에이전틱 오케스트레이션 패턴에 플랫폼을 제공한다.

클라이언트 인터페이스는 동일한 기반 API의 서로 다른 형식이다. 점진적 공개가 있는 GUI 포털은 플랫폼을 이해하지 않고 자동화를 요청하고 추적해야 하는 비엔지니어에게 제공된다. CLI는 속도, 스크립트 가능성, CI/CD 통합이 필요한 운영자에게 제공된다. ChatOps와 모바일 인터페이스는 승인 흐름과 인시던트 쿼리에 제공된다. 어떤 인터페이스를 구축할지에 대한 결정은 신중한 순서를 따라야 한다. 엔지니어 대상을 위한 내장 블록 UI로 시작하고, 비엔지니어가 자동화를 요청해야 할 때 ITSM과 통합하고, ITSM이 불충분하다고 증명될 때만 커스텀 포털을 구축하라.

통합 및 알림은 챕터 7의 비동기 응답 계약이 열어놓은 루프를 닫는다. 오케스트레이터가 워크플로 결과를 생성하고, 프레젠테이션 계층이 행동을 트리거한 대상에게 이미 사용하는 채널을 통해 전달한다. 양방향 ITSM 동기화, 웹훅 콜백, 푸시 알림은 편의 기능이 아니다. 이에 의존하는 사람들에게 자동화를 보이게 만드는 것이다.

캠퍼스 시나리오는 이것을 실제로 보여주었다. 하나의 워크플로, 세 가지 대상, 두 가지 프레젠테이션 인터페이스. ServiceNow가 자체 프레젠테이션 인터페이스로서 더 넓은 조직에 제공되었으며, 플랫폼 API를 직접 호출하고 친숙한 티켓 업데이트를 통해 상태를 표시했다. 커스텀 포털이 엔지니어링과 컴플라이언스 대상에게 제공되었다. 네트워크 엔지니어는 팀 요청으로 범위가 지정된 깔끔한 승인 인터페이스를 검토했고, 감사자는 오케스트레이터, SoT, 프레젠테이션 계층 자체의 권한 부여 로그에서 조합된 복합 변경 기록을 쿼리했다. 동일한 API 계층이 두 인터페이스에 접근 모델을 시행했다. 플랫폼은 더 이상 보이지 않지 않았다.

프레젠테이션 계층이 갖춰지면서, 파트 2는 NAF 프레임워크의 일곱 가지 구성 요소를 모두 다루었다. 다음 챕터는 이 모든 자동화가 궁극적으로 작용하는 하나의 블록으로 전환된다. 네트워크 자체, 챕터 9에서 다룬다.

💬 Found something to improve? Send feedback for this chapter