“선언적 구성과 자동화가 쿠버네티스 이후의 운영을 바꾼다” 깃옵스의 개념과 진화

지난 10년 동안 소프트웨어 개발을 주도한 것은 서로 밀접하게 연관된 두 가지 변화다. 하나는 데브옵스와 지속적 통합 및 지속적 제공(CI/CD)의 부상이다. 이를 통해 자동화되고 증분적인 소프트웨어 제공을 중심으로 개발 팀과 운영 팀이 뭉치게 됐다.

다른 하나는 기존 모놀리식 애플리케이션에서 마이크로서비스와 컨테이너로 구축되는 분산 클라우드 네이티브 시스템으로의 전환이다. 이런 시스템은 일반적으로 쿠버네티스와 같은 오케스트레이션 플랫폼에 의해 관리된다.

쿠버네티스 및 이와 유사한 여타 플랫폼은 분산 애플리케이션 운영의 많은 측면을 간소화하지만, 이런 시스템을 대규모로 운영하는 일은 여전히 복잡하다. 무분별하게 사용되는 구성, 환경 드리프트, 신속성과 신뢰성을 겸비한 변경에 대한 요구는 모두 운영 측면에서 과제를 야기한다. 이런 과제를 해결하기 위해 익숙한 데브옵스와 CI/CD 기법을 애플리케이션 코드 너머 인프라와 시스템 구성까지 확장하는 방법으로 등장한 것이 바로 깃옵스다.

깃옵스의 핵심은 코드형 인프라(IaC) 개념이다. 깃옵스 모델에서는 애플리케이션 코드뿐만 아니라 인프라 정의와 배포 구성, 운영 설정까지 모두 버전 제어 시스템에 저장된 파일로 기술된다. 자동화된 프로세스가 실행 중인 시스템과 이런 선언을 지속적으로 비교하면서 차이가 발생하면 라이브 환경을 다시 정렬 상태로 되돌린다.

이 접근 방식에서 버전 제어 리포지토리는 프로덕션 환경에서 애플리케이션과 이를 지원하는 인프라의 바람직한 상태를 정의하는 공식 기준 시스템 역할을 한다. 변경 사항은 개발자들이 소프트웨어에 이미 사용 중인 것과 동일한 검토, 승인, 자동화 파이프라인을 거쳐 흐르면서 클라우드 네이티브 운영에 더 높은 일관성과 추적가능성, 반복가능성을 부여한다.

간단히 설명하면 깃옵스는 선언적 구성, 버전 제어, 자동화된 조정을 사용해 클라우드 네이티브 시스템을 관리하기 위한 일련의 운영 관행을 의미한다. 깃옵스는 인프라와 애플리케이션 구성을 변경 가능한 런타임 상태로 취급하는 것이 아니라, 애플리케이션 코드와 동일한 검토, 테스트, 배포 프로세스를 거치는 버전이 부여된 아티팩트로 취급한다.

깃옵스 정의

깃옵스라는 용어는 위브웍스(Weaveworks)가 처음 사용해 대중화했다. 위브웍스는 쿠버네티스 운영과 관련해 깃옵스 접근법을 공식화하는 데 기여했는데, 이 같은 초기 활동은 깃옵스가 논의되고 구현되는 방식에 영향을 미쳤지만 이후 깃옵스는 업체 중립적인 패턴으로 발전하면서 광범위하게 채택됐다. 오늘날 깃옵스는 특정 제품이나 플랫폼보다는 공유되는 개념 집합에 가깝다.

깃옵스의 가장 큰 특징은 버전 제어 시스템에 저장된 선언적 구성에 의존한다는 점이다. 따라서 작업자는 명령을 실행해 라이브 시스템을 변경하는 것이 아니라 애플리케이션과 인프라의 의도된 상태를 구성 파일로 기술한다. 그러면 자동화된 에이전트가 이 선언된 상태와 실제로 실행 중인 상태를 지속적으로 비교하고 차이점이 발견되면 조정한다. 버전 제어 시스템에 정의된 의도된 상태를 향해 시스템이 수렴해 가는 이 풀 기반 모델은 변경 사항에 대한 드리프트 탐지, 반복가능성, 모든 변경에 대한 명확한 감사 추적을 기본적으로 제공한다.

깃옵스는 버전 제어 시스템에 저장된 구성 파일을 중심으로 작동하므로 익숙한 소프트웨어 개발 관행이 자연스럽게 적용된다. 변경 사항은 커밋을 통해 제안되고 검토를 거쳐 승인되고 시간 경과에 따라 추적된다. 롤백은 알려진 정상 버전으로 되돌리는 방식으로 이뤄지며, 시스템의 발전 과정에 대한 이력이 구성 자체와 함께 보존된다.

버전 제어 시스템으로 반드시 깃을 사용해야 하는 것은 아니지만, 현대 데브옵스 워크플로우 전반에서 깃이 워낙 보편적이고 협업과 변경 관리를 충실히 지원한다는 점에 힘입어 기본적인 선택 옵션으로 자리 잡았고, 이름에도 그대로 남게 됐다.

CI/CD 프로세스란?

CI/CD에 대한 자세한 설명은 이 기사의 범위를 벗어나지만, CI/CD는 깃옵스 동작에서 핵심적인 요소인 만큼 몇 가지는 설명하고 넘어갈 필요가 있다. CI/CD에서 앞부분, 즉 지속적 통합은 깃과 같은 버전 제어 리포지토리에 의해 실현된다. 개발자는 몇 달 또는 몇 년에 한 번씩 거대한 새 모놀리식 버전을 출시하는 것이 아니라 조금씩 지속적으로 코드베이스를 개선할 수 있다. 지속적 배포는 새 코드를 빌드, 테스트하고 프로덕션에 배포하는 파이프라인이라는 자동화된 시스템을 통해 구현된다.

보통 코드라고 하면 C나 자바, 자바스크립트와 같은 프로그래밍 언어로 작성된 실행 가능한 코드가 연상된다. 그러나 깃옵스에서 우리가 관리하는 “코드”는 대부분 구성 파일로 이뤄진다. 이것이 깃옵스가 하는 일의 핵심이다. 앞서 설명한 바와 같이 이런 구성 파일은 시스템의 의도된 상태를 기술하는 “단일 진실 공급원”이다. 구성 파일은 지시적이 아니라 선언적이다. 즉, “서버 10대를 시작하라”라고 지시하지 않고 단순히 “이 시스템에는 서버 10대가 포함된다”고 기술한다.

깃옵스와 쿠버네티스

깃옵스는 선언적 구성과 지속적 조정이 핵심 설계 원칙인 쿠버네티스 생태계에 처음 자리 잡았고, 그 결과로 쿠버네티스는 지금도 여전히 깃옵스 방식을 적용하는 데 있어 가장 보편적이고 가장 잘 이해된 환경이다. 쿠버네티스 애플리케이션에 대한 일반적인 깃옵스 기반 업데이트 프로세스는 다음과 같다.

1. - 개발자는 업데이트된 애플리케이션 코드 또는 구성을 일반적으로 풀 요청을 통해 버전 제어 리포지토리에 커밋하는 방법으로 변경을 제안한다.

2. - 이 변경 사항은 검토와 승인을 거쳐 메인 브랜치에 병합된다.
3. - 병합은 자동화된 CI/CD 파이프라인을 트리거한다. 파이프라인은 변경 사항을 테스트하고, 필요한 경우 새 아티팩트를 빌드해서 레지스트리에 게시한다.
4. - 깃옵스 컨트롤러 또는 이와 유사한 자동화된 에이전트가 버전 제어에 저장된 업데이트된 의도된 상태를 감지한다.
5. - 컨트롤러는 이 의도된 상태를 쿠버네티스 클러스터의 현재 상태와 비교하고, 필요한 변경 사항을 적용해 클러스터를 다시 일치 상태로 만든다.

클러스터가 버전 제어에 정의된 의도된 상태를 향해 지속적으로 수렴하는 이 풀 기반 조정 루프가 깃옵스 작동의 핵심이다. 쿠버네티스는 이 모델에 자연스럽게 부합하는 환경을 제공하지만 전형적인 사용례 중 하나일 뿐이다. 이 패턴은 쿠버네티스 자체를 넘어 인프라 프로비저닝, 정책 실행, 멀티 클러스터 운영으로 점점 확대 적용되고 있다.

실무 깃옵스 툴 : 아르고 CD, 플럭스, 생태계

깃옵스는 지금까지 살펴본 원칙을 구현하는 일련의 툴에 의해 실현된다. 이 가운데 몇몇 오픈소스 프로젝트가 클라우드 네이티브 환경에서 사실상의 표준으로 부상하고 있다.

깃옵스 생태계의 중심에는 오픈소스 컨트롤러인 아르고 CD(Argo CD)가 있다. 아르고 CD는 버전 제어 리포지토리를 지속적으로 모니터링하면서 실행 중인 시스템의 상태가 선언된 의도된 상태와 일치하도록 보장한다. 아르고 CD가 쿠버네티스 환경에서 광범위하게 사용되는 이유는 풀 기반 조정을 직접 구현한다는 데 있다. 즉, 깃에 저장된 의도된 상태와 클러스터의 실제 상태를 비교하고 드리프트가 발견되면 변경을 적용해 수정한다.

플럭스(Flux)는 아르고 CD와 함께 대표적인 오픈소스 깃옵스 엔진이다. 플럭스와 아르고 CD 모두 코드와 런타임 사이의 동기화 루프를 관리하는 방법으로 깃옵스 워크플로우 도입을 지원한다는 공통점이 있지만 운영 원칙과 통합 지점, 생태계 적합성 측면에서 차이가 있다.

깃옵스 툴은 따로 떨어진 유틸리티가 아니라 더 폭넓은 플랫폼이나 통합 스택의 일부로 제공되는 경우가 많다. 예를 들어 이제 멀티클라우드 및 클러스터 관리 솔루션에서 아르고 CD 또는 호환 컨트롤러와 배포, 정책, 거버넌스 기능을 번들로 묶어 깃옵스를 지원하는 경우를 흔히 볼 수 있다.

플럭스와 아르고 CD 외에도 깃옵스 생태계를 완성하는 데 기여하는 다양한 보조 툴이 나와 있다. 코드형 정책 엔진(예 : 오픈 폴리시 에이전트(Open Policy Agent)), 드리프트 탐지 시스템, 깃 중심 워크플로우와 연계되는 인프라 프로비저닝 툴 등이 있다.

깃옵스, 데브옵스, 그리고 일상화

깃옵스의 성장을 이끄는 힘은 데브옵스를 주류 IT 관행으로 이끈 힘과 동일하다. 초기 깃옵스는 선언적 인프라와 쿠버네티스 중심 시스템을 관리하는 데 맞춰진 데브옵스의 확장으로 논의되는 경우가 많았다. 당시 깃옵스는 비교적 새로운 개념으로, 클라우드 네이티브를 주도하는 기업을 제외하면 널리 채택되지 않은 상태였다.

그러나 지난 몇 년 동안 깃옵스 관행은 현대 클라우드 환경 운영에 깊이 스며들었다. 버전 제어되는 선언적 구성과 자동화된 조정 루프를 사용해서 실행 중인 시스템을 의도된 상태와 지속적으로 일치시킨다는 깃옵스의 핵심 개념은 더 이상 선택적인 부가 기능 또는 마케팅 문구가 아니라 많은 쿠버네티스 중심 기업에서 표준 운영 관행의 일부가 됐다. 즉, 과거 데브옵스가 그랬듯이 깃옵스도 가능성을 이야기하는 유행어에서 클라우드 네이티브 운영을 위한 기준 패턴으로 발전했다.

쿠버네티스와 선언적 시스템이 표준인 환경에서 깃옵스 워크플로우는 변경 사항을 관리하고 배포하는 기본 방식이다. 많은 기업이 “깃옵스”라는 명시적 이름을 사용하지 않더라도 이런 패턴을 구현하고 있다. 오늘날 많은 팀이 지속적 파이프라인을 당연하게 여기지만 굳이 “CI/CD를 한다”고 말하지 않는 것과 마찬가지다. 마케팅에서 용어가 갖는 존재감은 낮아졌지만 많은 경우 그 방식은 파이프라인, 컨트롤러, 플랫폼 툴에 내장돼 있다.

깃옵스 워크플로우가 더 넓은 운영 프레임워크에 결합되는 방식에서도 이런 일상화를 볼 수 있다. 예를 들어 플랫폼 엔지니어링 팀은 표준화된 개발자 API 이면의 깃옵스 패턴을 캡슐화하는 내부 개발자 플랫폼을 구축해 대다수 애플리케이션 팀에는 이 패턴이 보이지 않도록 하면서 깃옵스가 약속하는 감사 가능성과 자동화를 제공한다.

쿠버네티스를 넘어선 깃옵스 : 인프라, 정책, 드리프트

깃옵스는 처음에는 쿠버네티스 배포를 관리하는 방법 중 하나로 부상했지만 그 핵심 원칙은 특정 오케스트레이션 플랫폼을 넘어 인프라와 운영에 폭넓게 적용된다. 깃옵스는 의도된 상태를 버전 제어에 저장된 선언적 구성으로 다루면서, 자동화된 조정을 사용해 실행 중인 시스템이 그 상태와 일치하도록 한다. 이 패턴은 인프라 프로비저닝, 정책 적용, 구성 드리프트 탐지, 다양한 환경 전반의 거버넌스 워크플로우로 자연스럽게 확장된다.

현대 운영 스택에서 인프라는 쿠버네티스 매니페스트, 테라폼 모듈, 또는 기타 코드형 인프라 형식을 통해 선언적으로 정의되는 경우가 증가하고 있다. 이런 선언을 버전 제어에 저장하면 개발자가 이미 애플리케이션 코드에 사용하고 있는 것과 동일한 동료 검토, 감사 가능성, 롤백 관행을 그대로 구현할 수 있다. 그러면 자동화된 툴이 라이브 인프라가 선언된 상태에서 벗어나는 상황을 지속적으로 감지하고 다시 일치시켜 구성 드리프트와 의도치 않은 구성 오류의 위험을 줄인다.

구성 드리프트, 즉 환경의 상태가 버전 제어에 선언된 기준에서 벗어난 상태는 특히 복잡하고 동적인 시스템에서 여전히 운영상의 골칫거리다. 드리프트는 임시 수정안, 긴급 업데이트 또는 정상적인 파이프라인을 벗어나 이뤄진 수동 변경 등으로 인해 발생하며 비일관성과 가동 중단, 보안 공백으로 이어질 수 있다. 깃옵스 워크플로우는 실행 중인 시스템을 깃의 의도된 상태와 지속적으로 비교하면서 자동으로 차이를 조정함으로써 환경을 예측 및 감사 가능한 상태로 유지하는 데 일조한다.

정책 적용과 규정 준수도 깃옵스 패턴이 자연스럽게 확장되는 영역이다. 기업에서 선언적 관행을 도입하면 깃옵스 파이프라인에 코드형 정책 엔진과 드리프트 탐지 시스템을 결합해서 제안된 구성을 실행 중인 시스템에 적용하기에 앞서 해당 구성이 보안, 규정 준수 또는 운영상의 기준을 충족하는지 여부를 검증할 수 있다. 선언적 워크플로우에 정책 검사를 내장하면 데브옵스 팀이 기대하는 자동화와 속도를 유지하면서 일관적인 거버넌스를 구현할 수 있다.

쿠버네티스를 넘어 성장하는 깃옵스

깃옵스는 쿠버네티스 운영에 데브옵스 원칙을 도입하기 위한 하나의 수단으로 시작됐지만 장기적인 영향은 겉으로 잘 드러나지 않는 형태로 나타났다. 많은 측면에서 깃옵스는 선언적 구성, 버전 제어, 자동화된 조정이 당연시되는 현대 클라우드 네이티브 운영 구조에 흡수됐다. 오늘날 깃옵스는 특정 툴 집합이나 명시적 관행보다는 운영 사고방식에 가깝다. 깃옵스는 인프라와 구성을 버전이 부여되고 감사 가능한 아티팩트로 취급하고 자동화를 통해 일관성을 강제함으로써 대규모 환경에서 복잡성을 더 용이하게 관리할 수 있게 해준다. 깃옵스라는 용어 자체는 스포트라이트에서 멀어지고 있지만 깃옵스를 통해 도입된 관행은 분산 시스템의 구축, 배포, 운영 방식에 지속적으로 큰 영향을 미치고 있다.

dl-itworldkorea@foundryco.com

Josh Fruhlinger editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지