NetOps가 지속적 배포를 도입해야 할 때

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

지속적 배포가 모든 변경 사항을 매번 즉시 배포해야 한다는 뜻일 필요는 없습니다. 하지만 어디에서든 시작은 해야 합니다.

CI/CD(지속적 통합/지속적 제공)는 개발자의 영역입니다. 이는 제공 속도를 높이기 위한 포괄적인 모델로, 보다 능동적이고 사용자 중심적인 맥락에 익숙한 사람들에게는 사실상 ‘배포 준비 완료’를 의미합니다.

그렇다고 해서 NetOps가 CI/CD를 무시해도 된다는 뜻은 아닙니다. 오히려 그 반대입니다. 하지만 NetOps가 제공 준비가 완료될 때마다 반드시 1:1로 배포해야 한다는 뜻도 아닙니다. 특히 애플리케이션 개발자들이 지속적 제공을 완벽하게 구현한 경우, 앱이 ‘배포 준비 완료’ 상태가 되는 빈도는 감당하기 어려울 수 있습니다. NetOps가 아직 지속적 배포 를 완벽하게 구현하지 못했다면 더욱 그렇습니다. 하지만 배포 빈도를 더 높일 여지는 있으며, 경우에 따라 개발자와 비즈니스 부서가 보기에는 분명 지속적 배포처럼 느껴질 정도로 높일 수도 있습니다.

비결은 애플리케이션의 ‘사소한 변경’과 ‘중대한 변경’을 구분하는 데 있습니다.

The NetDevOps 2016년 가을 설문조사에 따르면, 소규모 변경 사항이 일반적으로 알려진 것보다 훨씬 더 자주 프로덕션 환경에 배포되고 있었습니다. 응답자의 약 51%가 하루에 두 번 이상 소규모 변경 사항을 프로덕션 환경에 배포하고 있었습니다. 3명 중 1명 이상은 한 달에 1~5회 주요 변경 사항을 배포하고 있었으며, 또 다른 3분의 1은 한 달에 한 번 미만으로 주요 변경 사항을 배포한다고 답했습니다.

안타깝게도 ‘주요’ 변경과 ‘사소한’ 변경의 정의가 정량적으로 규정되어 있지는 않습니다. 하지만 흔히 그렇듯 이러한 상대적 표현은 업계나 조직뿐 아니라 개별 애플리케이션마다 다르게 사용되는 경우가 많습니다. 그럼에도 절반을 조금 넘는 상당수는 매우 정기적으로 주요 변경 사항을 프로덕션 환경에 배포하는 것으로 보입니다.

이는 큰 틀에서 볼 때 우리가 지속적 배포를 향해 조금씩 나아가고 있다는 뜻입니다. 문제는 완전히 새로운 애플리케이션을 배포하는 것과 기존 애플리케이션의 업데이트를 배포하는 것은 같지 않다는 점입니다. 새로운 네트워크 또는 애플리케이션 서비스를 추가하는 경우라 해도, ‘서비스 중단 가능성’이라는 측면에서는 완전히 새로운 애플리케이션을 배포하는 것과 여전히 큰 차이가 있습니다.

그러니 일단은 완전히 새로운 앱에는 더 많은 조율과 계획이 필요하다고 해두겠습니다. 그렇더라도 현재 운영 중인 앱의 대다수는 여전히 지속적 배포의 잠재적 대상입니다. 이를 장려하기 위해 할 수 있는 일 중 하나는 ‘사소한’ 변경과 ‘중대한’ 변경을 구분할 때 프로덕션 환경에 미치는 영향을 기준으로 맥락을 명확히 하는 것입니다.

사소한 변경은 앱 내부에 영향을 미치는 변경으로 한정할 수 있습니다. 예를 들면 로직 변경입니다. 여기에는 앱 스택(웹 서버, 앱 서버 등)에 대한 패치나 업그레이드뿐 아니라 이를 지원하는 앱 인프라에 대한 변경도 포함될 수 있습니다. 기본적으로 사소한 변경은 앱에만 영향을 미칩니다. 일반적인 사용 환경에서 해당 앱을 실제로 제공하고 보호하는 네트워크나 앱 서비스를 변경할 필요는 없습니다.

그렇다면 주요 변경 사항은 앱을 지원하는 네트워크 또는 앱 서비스의 모든 요소에 영향을 미치는 변경을 의미합니다. 주요 변경 사항에는 전송 정책 조정(압축 좀 켜 주시겠어요?)이나 최근 발견된 취약점의 악용을 방지하기 위한 URL 필터링 또는 요청 검사 같은 새로운 서비스의 추가가 포함될 수 있습니다. 이러한 변경은 더 광범위한 운영 시스템에 영향을 미치고, 그 결과 다른 애플리케이션에도 영향을 줄 수도 있고 그렇지 않을 수도 있다는 점에서 주요 변경 사항에 해당합니다.

외부 서비스에 미치는 영향까지 고려하는, 보다 정교한 평가 체계를 마련할 수도 있습니다. 새로운 서비스를 도입하는 것은 기존 서비스를 조정하는 것보다 더 큰 혼란을 초래할 가능성이 높습니다. 또한 새로운 정책은 기존 정책을 소폭 업데이트하는 경우보다 구현에 더 많은 주의를 기울여야 합니다.

사용할 ‘시스템’에 합의하고 나면, 사소한 변경 사항을 필요할 때마다 적용하는 데 동의하기가 훨씬 쉬워집니다. 즉, 문제가 발생하더라도 앱 배포가 잠재적 영향이 미미하다고 판단되는 한 프로덕션 환경으로 이어지도록 함으로써 지속적 배포로 전환하는 것입니다. 변경이 작으면 위험도 작다는 것이죠. 적어도 전제는 그렇습니다.

이를 통해 사소한 기술적 변경이지만 어쩌면 중대한 비즈니스 변화일 수 있는 사항을 사용자에게 더 빠르게 제공할 수 있습니다. 대규모 전통적 조직에서는 이런 변경이 지연되는 경우가 많기 때문입니다. 사용자 인터페이스의 작은 변경조차 일정 충돌이나 프로젝트 우선순위 또는 사내 정치에 따른 변경 관리 위원회의 결정으로 인해 몇 주 이상 지연될 수 있습니다. 그 작은 변경이 더 나은 사용자 경험을 제공해 전환율이나 고객 유지율을 높일 수 있는데도 말입니다. 그 작은 변경이 앱에만 영향을 미치는, 즉 “사소한” 변경이라면, 정말 IT 조직 내 정치 때문에 이를 미뤄야 할까요?

지속적 배포는 단순히 프로덕션 환경으로의 자동 배포를 기술적으로 구현하는 것에 그치지 않습니다. 애플리케이션과 업데이트를 언제 프로덕션 환경에 반영할지 결정하는 프로세스를 지연시키는 기존의 관행을 허무는 것, 즉 문화를 바꾸는 일이기도 합니다.

조직은 앱 외부의 시스템에 영향을 미칠 가능성이 있는 업데이트와 그렇지 않은 업데이트, 즉 ‘사소한’ 업데이트와 ‘중대한’ 업데이트를 구분하는 공통 기준을 마련함으로써, 일부 변경 사항에 대해서는 추가적인 위험을 초래하거나 프로덕션 환경을 불안정하게 만들지 않으면서 지속적 배포를 실현할 수 있습니다. 이는 비즈니스에도 긍정적인 영향을 미칠 수 있으므로 모두에게 이익이 됩니다.

작성자 소개

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

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

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