NetOps 자동화에 선언적 모델이 중요한 이유는 무엇일까요?

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

모든 것을 자동화하려면 선언형 방식을 택하는 것이 좋습니다. 그 이유를 알아보겠습니다.

우리는 자동화, 특히 NetOps와 애플리케이션 서비스에 관해 이야기할 때마다 꽤 오랫동안 선언적 접근 방식의 중요성을 강조해 왔습니다. 하지만 이것이 왜 중요하고 어떤 이점이 있는지는 제대로 살펴보지 않았습니다. 지금 바로 그 점을 짚어보겠습니다.

기억을 되짚어 보자면, 현재 사실상 모든 것의 구성과 배포를 자동화하는 데 사용되는 모델은 두 가지입니다.

첫 번째는 명령형 모델로, 대상 시스템에 원하는 작업을 수행하는 정확한 방법을 지시합니다. 시스템에 SSH 터널을 열고 CLI에서 특정 명령어들을 입력해 본 적이 있다면 명령형 구성 모델을 사용한 것입니다.

두 번째(이자 선호되는) 방식은 선언형으로, 대상 시스템에 수행할 작업은 알려 주되 그 방법은 지정하지 않습니다. 대부분의 네트워크 자동화 솔루션이 여러 이유로 이 모델을 채택하고 있으며, 그중 가장 큰 이유는 특정 환경에 존재할 수 있는 수백 가지 장치와 시스템을 파악하고 통합하는 데 막대한 비용과 시간이 들기 때문입니다.

따라서 명령형 모델에서는 시스템을 구성하는 데 필요한 각 명령(또는 API 호출)을 일일이 지정해야 합니다. 선언형 모델에서는 원하는 상태를 설명하는 키-값 쌍을 (일반적으로) 지정하기만 하면 되며, 이를 구현하는 데 필요한 명령은 다른 시스템이 알아서 처리합니다.

식은 죽 먹기죠.

이제 이것이 왜 중요한지에 대한 질문에 답해 보겠습니다. 모든 것을 자동화하려 할 때 선언적 모델을 도입하면 얻을 수 있는 주요 이점은 네 가지입니다.

1. 인적 오류 감소

프로덕션 환경에서 발생하는 장애 사고의 약 22%가 사람의 실수로 인해 발생하는 것으로 알려져 있습니다. 여기서 다시 자세히 언급하지는 않겠지만, 상당히 세간의 이목을 끈 몇몇 사고도 단순한 사람의 실수가 직접적인 원인이었던 것으로 밝혀졌습니다. API 호출에 의존하는 명령형 모델에서는 각각의 호출이 언제든 사고로 이어질 수 있는 잠재적 위험 요소입니다. 변수를 검증하지 않았거나 오류 코드를 확인하는 것을 잊었거나, 그 밖의 수많은 가능한 상황 중 하나라도 발생하면 이력서를 새로 써야 하는 사태를 맞을 수 있습니다. 이는 결코 바람직한 일이 아닙니다.

선언적 모델은 API 호출을 통해 실행되기 전에 구문 분석과 유효성 검사를 거치는 일종의 템플릿 또는 구성 파일을 기반으로 합니다. 물론 구성 파일이나 템플릿을 잘못 작성할 가능성은 여전히 있지만, 필요한 코드의 양이 줄어들기 때문에 실수할 여지도 줄어듭니다. 일반적으로 코드가 적을수록 실수할 가능성도 낮아집니다.

2. 기술 부채 감소

기술 부채는 개발 분야에서 가져온 흥미로운 비유로, 우리가 내린 선택이 장기적으로 어떤 비용을 초래하는지 일깨워 줍니다. 명령형 모델에서는 여러 가지 방식으로 기술 부채가 쌓입니다. 우선 스크립트가 대상 시스템의 API에 종속됩니다. 해당 API는 다른 어떤 것도 지원하지 않을 가능성이 높으므로 시스템별로 스크립트를 개발하게 됩니다. 구성 단계 역시 앱마다 다를 가능성이 높습니다. 모든 것이 HTTP인 것은 아니며, HTTP 기반 애플리케이션이라고 해서 모두 정확히 동일한 서비스 구성이 필요한 것도 아닙니다. 결국 앱별, 시스템별로 스크립트를 작성하게 됩니다. 이는 엄청나게 많은 스크립트를 의미하며, 그러한 선택으로 인해 막대한 부채가 쌓이게 됩니다.

반대로 선언적 방식에서는 동일한 배포 프로세스 스크립트와 시스템을 사용할 수 있습니다. 템플릿/구성은 여전히 애플리케이션과 시스템에 따라 달라질 가능성이 크지만, 하나의 파일로 관리됩니다. 이를 통해 스크립트의 복잡성과 개수를 줄여 기술 부채를 크게 낮출 수 있습니다. 현실적으로 어떤 선택을 하든 어느 정도의 부채는 항상 발생하기 마련이며, 목표는 이를 최소화하는 것입니다.

3. 버전 충돌 제거

구성 및 배포 프로세스를 API에 연동하면 해당 API의 특정 버전에 종속됩니다. 인터넷에는 API 변경 사항과 그에 맞춰 앱을 수정하는 데 필요한 작업에 대해 적대적이고 분노한 개발자들이 목소리를 높이는 커뮤니티가 많습니다. 네트워크 및 애플리케이션 서비스에서도 똑같은 일이 발생할 수 있으며, 실제로 발생할 것입니다. 따라서 특정 API 버전에 종속된 상태에서 무언가가 변경되면 어떻게 될까요? 끝도 없이 스크립트를 업데이트하거나 아예 다시 작성해야 할 것입니다*.

하지만 선언적 모델을 채택했다면 API의 변경 사항을 대부분 무시할 수 있을 것입니다. 결국 API를 사용해 시스템에 서비스를 배포하는 방법을 알려주는 것이 아니라, 배포해야 할 대상이 무엇인지 알려주기만 하면 되기 때문입니다.

4. 도메인 전문 지식 요구 사항 완화

솔직히 말해, 네트워크 또는 애플리케이션 서비스용 API를 사용하려면 해당 시스템을 이해해야 합니다. 가상 IP와 가상 서버의 차이를 모른다면, 노드와 멤버의 차이는 아직 제대로 다루지도 않았는데 벌써 곤란한 상황에 처한 것입니다. 명령형 API 기반 방식을 사용하려면 대상 시스템의 구성을 다룰 수 있을 만큼 충분히 이해해야 합니다.

선언적 모델을 사용하면 대상 시스템에 대한 전문 지식이 덜 필요하므로 개발자와 DevOps 담당자 모두 이 방식을 활용해 애플리케이션을 셀프서비스 방식으로 제공할 가능성이 높아집니다. 물론 여전히 전문가가 필요하지만, 서비스 이용자에게 요구되는 부담은 줄어들고 프로비저닝 및 배포 부담은 더 폭넓은 관계자들에게 분산됩니다.

NetOps 자동화 작업에 선언적 모델을 도입해야 할 다른 이유도 있지만, 이 네 가지가 가장 설득력 있습니다. NetOps와 비즈니스는 물론, 애플리케이션을 더 빠르고 안전하게 운영하는 데 필요한 네트워크 및 애플리케이션 서비스에 셀프서비스 방식으로 액세스해야 하는 점점 더 다양한 이해관계자 모두에게 이점을 제공하기 때문입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물