2021.05.12

깃옵스가 '아직' 주류로 부상할 준비가 되지 않은 이유

Scott Carey | InfoWorld
깃옵스(Gitops)는 2017년 처음 고안된 이후, 특히 요즘 유행하는 분산 컨테이너 전반에 배포되고 쿠버네티스(Kubernetes)에 의해 조율되는 마이크로서비스를 구축하는 기업에서 데브옵스, 코드형 인프라, CI/CD 원칙과 같은 현대 소프트웨어 개발 방식의 자연스러운 발전 방향으로 부상했다.

그러나 업계에서 깃옵스가 애자일 및 데브옵스가 지금까지 이룬 규모의 주류 기술로 채택되기 위해서는 업계가 극복해야 할 여러 중대한 문화적, 기술적 장애물이 아직 남아 있다.
 
ⓒ Getty Images Bank


깃옵스란 무엇인가?

깃옵스는 데브옵스를 더욱 확장해 코드를 인프라로 다뤄 애플리케이션과 기반 인프라가 코드로 취급되고 버전 제어 시스템(주로 깃)에 저장되어 개발자와 운영자에게 단일 진실 공급원(single source of truth)을 제공할 수 있도록 한다. 제대로 구현되면 모든 변경 사항이 선언형 코드를 통해 푸시되고, 바람직한 상태로부터 이탈되는 경우 자동화된 단계를 통해 교정된다.

이론적으로는 흠잡을 데가 없지만, 펠로톤(Peloton), 볼보(Volvo), 티켓마스터(Ticketmaster), 저스트 잇 테이크어웨이닷컴(Just Eat Takeaway.com) 등 깃옵스 방식을 테스트 중인 것으로 알려진 기업 가운데 어느 한 곳도 현재 단계에 대해 본지와의 인터뷰에는 응하지 않았다. 

IDC의 데브옵스 솔루션 부문 연구 책임자인 짐 머서는 “깃옵스 이니셔티브를 도입 중인 기업과 대화를 해본 적이 없다. 내가 대화를 나눈 기업은 깃옵스라는 말을 들어본 적도 없는 경우가 대부분”이라고 말했다.

2018년 컨테이너 기술 전문업체 애플라틱스(Applatix)를 인수한 후 깃옵스 조기 도입 기업이 된 핀테크 업체 인튜이트(Intuit)의 내부 개발자 플랫폼 부문 제품 관리 책임자인 무쿨리카 카파스는 “깃옵스의 성숙도는 여전히 초기 단계”라고 말했다.

그보다는 소규모 클라우드 네이티브 기업이 소프트웨어 제공 프로세스를 개선하기 위한 깃옵스의 가능성을 탐색하기 시작했다. 대기업의 경우, 그린필드 디지털 이니셔티브 또는 연구 및 개발 센터와 같이 클라우드 네이티브 방식이 일반화된 분야에서 깃옵스에 관심을 둘 가능성이 높다.

개발자 중심의 시장조사업체 레드몽크(RedMonk)의 공동 창업자인 제임스 거버너는 “스마트한 기업은 개발자가 서버에 SSH로 연결하고 인스턴스를 만들고 통제되지 않는 방식으로 변경 작업을 수행하지 않도록 할 방법을 모색하고 있다. 깃옵스가 바로 그 문제를 해결해준다”라고 말했다.

그러나 밝은 전망에도 불구하고 깃옵스는 여전히 비주류에 머물러 있다. 깃옵스 방식이 아직 주류로 채택되지 않은 4가지 주요 이유와 이를 극복하기 위해 진행 중인 작업에 대해 알아보자.


깃옵스에는 정립된 패턴이 없다

깃옵스 생태계는 여전히 작고 열정적인 생태계다. 즉, 의사 결정의 기준이 될 수 있는 정립된 베스트 프랙티스와 실제 사례, 패턴 등 기업이 원하는 리소스가 거의 없다.

컨테이너 솔루션(Container Solutions)의 클라우드 전문 컨설턴트인 이안 미엘은 2020년에 이와 관련해 작성한 블로그 글에서 “현재 깃옵스의 가장 큰 과제는 선택의 가이드가 되는 정립된 패턴이 없다는 점”이라며, “진정한 표준이 정립될 때까지는 깃옵스 아키텍처를 제대로 구현하는 것은 과학보다는 예술에 가까운 상태가 지속될 것”이라고 지적했다.

이와 같은 과제를 해결하고 신규 도입을 더 용이하게 하기 위해 2020년 11월 CNCF 오픈 커뮤니티 프로젝트로 깃옵스 워킹 그룹이 출범했다. 아마존, 코드프레시(Codefresh), 깃허브(GitHub), 위브웍스(Weaveworks)가 주도하는 이 그룹이 초기에 맡은 일은 깃옵스의 원칙을 공급업체 중립적으로 명확하게 정의하고 깃옵스 방식의 도입을 늘리는 것이다.

코드프레시의 최고 오픈소스 책임자이자 깃옵스 워킹 그룹 공동 설립자인 댄 가필드는 본지와의 인터뷰에서 “지금은 부족(tribal) 지식을 끌어내 사람들이 쉽게 소비할 수 있도록 만드는 접근성 단계에 있다. 성숙 단계에 이르기 위해 깃옵스 원칙을 공식화하고 실무 전문가의 의견을 수렴해 우리가 놓친 부분을 확인하고 매끄럽지 않은 부분을 다듬고 사람들이 참고할 수 있는 커뮤니티 패턴과 참조 구현을 수집하고 있다"라고 말했다.

가필드는 워킹 그룹을 창설할 때 80명의 기업 대표가 참여하는 등 “커뮤니티의 호응이 컸다”라고 말했다.


깃옵스 도구의 성숙화 필요

일반적인 깃옵스 배포 프로세스를 보면, 개발자가 주로 깃을 통해(그래서 깃옵스라고 함) 새 기능을 위한 풀 요청을 수행한다. 승인된 요청은 CI/CD 파이프라인을 트리거하고 코드를 테스트하고 레지스트리에 배포된다. 이후 소프트웨어 에이전트(일반적으로 아르고(Argo) 또는 플럭스(Flux))가 클러스터의 상태가 깃의 구성과 일치하는지 여부를 자동으로 탐지하고 변경을 풀링하고 새 기능을 배포한다.

가필드는 “몇 년 전에는 대체로 깃 연산자와 비슷한 것을 만들어 버전 제어 스토리지를 사용해 인프라를 코드로 가져와 동기화했다. 문제는 깃옵스의 정의에 맞느냐가 아니라, 이것이 맞춤형 도구를 사용하는 팀의 비공식적인 방법이고 난해했다는 점이다. 이제 아르고 또는 플럭스와 같은 클라우드 전용 도구를 사용해 이 프로세스를 제대로 간소화할 수 있다”라고 지적했다.

이런 도구는 최근 몇 년 사이 큰 발전을 이뤘지만 도입을 간소화하기 위해 채워야 할 틈이 여전히 남아 있다. 코드프레시의 개발자 지지자인 코스티스 카펠로니스는 “깃옵스 방법론에는 몇몇 흥미로운 특징과 매력이 있지만 현재 깃옵스 도구는 애플리케이션의 배포 부분에만 주력할 뿐 그 외에는 아무것도 없다”라고 말했다. 

카펠로니스는 현재 제공되는 깃옵스 도구에는 환경, 비밀 취급, 연기(smoke) 테스트 및 감사 간의 전파를 규정하는 기능이 없다는 점을 지적했다. 카펠리노스는 "이는 팀이 소프트웨어 제공의 모든 측면에 대한 모범 사례를 자체적으로 만들어야 한다는 것을 의미한다"라고 덧붙였다.

포레스터의 수석 분석가 크리스토퍼 콘도는 깃옵스 도구의 다음 단계에 대해 테라폼(Terraform)과 직접 통합되어 개발자가 코드형 인프라를 더 쉽게 실행할 수 있게 해주는 깃허브 액션(GitHub Actions)과 같이 개발자들이 이미 작업하고 있는 클라우드 플랫폼에 내장되어 개발자들이 굳이 인식하지 않으면서 자연스럽게 깃옵스를 실행할 수 있게 되는 형태가 될 수 있다고 예상했다.

 
대규모 깃옵스 실행에 따르는 중대한 과제

서비스 업체 컨테이너 솔루션의 클라우드 전용 설계자인 애덤 샌도르는 깃옵스에는 대규모 실행 시 여전히 뚜렷한 제약이 있다고 지적했다. 이런 제약에는 여러 깃 리포지토리에 걸쳐 실행할 때의 감사, 교정, 관찰 가능성 문제가 포함된다.

기업이 자체 내부 개발자 플랫폼을 구축하도록 돕는 신생업체인 휴머니텍(Humanitec) CEO 카스파 본 그룬버그는 “10~15명의 전문가가 포함된 소규모 팀에서의 깃옵스는 가능한 최선의 방법”이라면서 “특정 수준에서는 훌륭하지만, 대기업에서의 대규모 깃옵스 구현은 극히 힘든 일”이라고 말했다.

다양한 환경 간에 변경 사항을 전파하는 프로세스를 보자. 카펠리노스는 “이는 깃옵스의 잘 알려진 문제점 가운데 하나이며, 깃옵스가 대기업에서 어떻게 작동할 수 있는지에 관한 논의에서 가장 먼저 나오는 주제”라고 말했다.

카펠리노스는 “누군가가 깃옵스 도입 과정이 쉽다고 말할 때마다 나는 항상 다양한 환경 간의 전파가 어떻게 작동하는지를 묻는다. 돌아오는 답은 항상 다르다. 깃옵스의 문답 페이지에서도 ‘깃옵스는 한 단계의 변경을 다음 단계로 전파하기 위한 솔루션을 제공하지 않는다. 우리는 하나의 환경만 사용해 단계 전파를 아예 피할 것을 권장한다’고 나와 있다는 점이 매우 실망스럽다”라고 비판했다.

대규모 깃옵스 배포의 다음 문제는 관찰 가능성 문제다. 카펠리노스는 “현재 상태의 깃옵스 도구는 기술적인 수준에서 클러스터의 콘텐츠를 관찰하기에는 좋지만 각 배포의 비즈니스 메트릭을 모니터링하는 부분에서는 크게 뒤떨어진다. 환경과 애플리케이션의 수가 많은 대기업에서 깃옵스를 도입하는 경우, 깃 리포지토리의 수가 급격히 증가하게 된다. 따라서 각 환경에서 현재 일어나는 일을 추적하기가 매우 어렵게 되고, 이내 구성 중복 또는 특정 환경에 커밋하는 문제로 이어질 수 있다”라고 지적했다.

예를 들어 쿠버네티스 매니페스트가 있는 20개의 깃 리포지토리가 있고 중앙 변경 작업을 수행해야 하는 경우 지금은 수동으로 20번의 깃 커밋을 수행하거나 이를 대신 수행해줄 코드를 직접 작성해야 한다.

코드프레시의 가필드는 “현재 이 관찰 가능성 문제를 극복하고자 모든 배포를 보기 위한 유용한 도구를 만들고 있다”면서, “규모 문제를 해결하는 것이 중요하다. 곳곳에 조정자(reconciler)가 있고 오늘 수행한 많은 변경 중에서 퇴행을 유발한 것이 무엇인지 알 수 없게 되는 상황이 갑자기 발생하고 규모에 대처할 수 있는 수단이 필요하기 때문이다. 지금은 이 부분에 주력하고 있다”라고 말했다.


깃옵스 필요성 설득의 어려움

사용자에게 더 많은 기능을 제공하기 위한 길은 데브옵스임을 이제 막 설득한 마당에, 사장실로 돌아가 이번에는 깃옵스라고 다시 설득해야 한다. 누구에게나 부담스러운 일이고 깃옵스의 주류 부상을 막는 또 다른 요인이기도 하다. 

위브웍스 CTO 코넬리아 데이비스는 “플랫폼 팀 또는 개발자 지원 팀에 있는 실무자, 깃옵스가 가져다줄 혜택을 인지하기 시작한 이들이 의사 결정권자가 깃옵스의 가치를 이해하도록 돕는 데 어려움을 겪고 있다. 이를 설명하는 방식이 지나치게 단순하거나 비즈니스 가치에 대응하지 않는 경우가 많기 때문이다”라고 말했다.

데이비스가 자주 보게 되는 실수 가운데 하나는 깃옵스를 데브옵스의 대체제로 생각하는 것이다. 데이비스는 “전환이 아닌 회전”이라면서 “애자일 개발과 이를 지원하는 도구의 성숙도는 크게 높아졌고 다양한 최적화도 이뤄지고 있다. 깃옵스가 말하는 것은 개발 측면에서는 그동안 많은 일을 했으니, 이제 운영 측면에서 더 많은 일을 해야 한다는 것”이라고 설명했다.

포레스터의 콘도는 “문제는 이 기술이 복잡하며, 익숙한 사람이 많지 않다는 점이다. 앞으로 몇 년 동안 개발자와 클라우드 엔지니어 스킬의 조합을 갖추지 못한 여러 기업이 개발과 운영을 하나로 모으기 위한 더 나은 방법을 찾으면서 많은 개선이 이뤄지게 될 것이다. 깃옵스의 문제가 있다면, 그건 너무 빨리 앞으로 나가는 바람에 모든 사람들이 정렬된 형태로 참여하지 못한다는 점”이라고 평가했다. 

레드몽크의 거버너는 깃옵스가 제공하는 제어 측면에 초점을 맞추는 것이 전환의 매력적인 이유가 될 수 있다면서, “개발자가 문제의 소지가 있는 시스템 변경을 수행하는 데 관한 우려에 바로 비즈니스 사례가 있다. 지금은 거친 서부 시대와 같다. 깃옵스의 핵심은 통제력을 되찾는 것”이라고 말했다.

깃옵스가 유의미한 방식으로 자리를 잡기 위해서는 사람들에게 적절히 투자하고 깃옵스로 가능한 혜택을 이해하기 위한 시간과 공간을 주는 것이 중요하다. 거버너는 “새로운 작업 방식이 그냥 실현될 것으로 기대하면 안 된다. 기업 전체가 갑자기 깃옵스를 실천하게 되는 일은 없다. 새 프로젝트를 계획하고 클라우드 전용 인프라를 살펴볼 때 몇몇 깃옵스 방식을 테스트해 조직적인 확신을 쌓을 수 있을 것”이라고 조언했다. 

모든 지표는 깃옵스의 도입이 아직 초기 단계에 있음을 가리키고 있지만 IDC의 머서는 "데브옵스보다 더 빠르게 자리를 잡을 가능성이 높다고 본다. 문화적 장벽이 이미 어느정도 허물어져 있기 때문이다. 데브옵스와 지속적 제공을 이미 실천 중이라면 소수에 속하지만 깃옵스를 도입하기 위한 준비는 잘 되어 있는 것이다"라고 말했다. editor@itworld.co.kr


2021.05.12

깃옵스가 '아직' 주류로 부상할 준비가 되지 않은 이유

Scott Carey | InfoWorld
깃옵스(Gitops)는 2017년 처음 고안된 이후, 특히 요즘 유행하는 분산 컨테이너 전반에 배포되고 쿠버네티스(Kubernetes)에 의해 조율되는 마이크로서비스를 구축하는 기업에서 데브옵스, 코드형 인프라, CI/CD 원칙과 같은 현대 소프트웨어 개발 방식의 자연스러운 발전 방향으로 부상했다.

그러나 업계에서 깃옵스가 애자일 및 데브옵스가 지금까지 이룬 규모의 주류 기술로 채택되기 위해서는 업계가 극복해야 할 여러 중대한 문화적, 기술적 장애물이 아직 남아 있다.
 
ⓒ Getty Images Bank


깃옵스란 무엇인가?

깃옵스는 데브옵스를 더욱 확장해 코드를 인프라로 다뤄 애플리케이션과 기반 인프라가 코드로 취급되고 버전 제어 시스템(주로 깃)에 저장되어 개발자와 운영자에게 단일 진실 공급원(single source of truth)을 제공할 수 있도록 한다. 제대로 구현되면 모든 변경 사항이 선언형 코드를 통해 푸시되고, 바람직한 상태로부터 이탈되는 경우 자동화된 단계를 통해 교정된다.

이론적으로는 흠잡을 데가 없지만, 펠로톤(Peloton), 볼보(Volvo), 티켓마스터(Ticketmaster), 저스트 잇 테이크어웨이닷컴(Just Eat Takeaway.com) 등 깃옵스 방식을 테스트 중인 것으로 알려진 기업 가운데 어느 한 곳도 현재 단계에 대해 본지와의 인터뷰에는 응하지 않았다. 

IDC의 데브옵스 솔루션 부문 연구 책임자인 짐 머서는 “깃옵스 이니셔티브를 도입 중인 기업과 대화를 해본 적이 없다. 내가 대화를 나눈 기업은 깃옵스라는 말을 들어본 적도 없는 경우가 대부분”이라고 말했다.

2018년 컨테이너 기술 전문업체 애플라틱스(Applatix)를 인수한 후 깃옵스 조기 도입 기업이 된 핀테크 업체 인튜이트(Intuit)의 내부 개발자 플랫폼 부문 제품 관리 책임자인 무쿨리카 카파스는 “깃옵스의 성숙도는 여전히 초기 단계”라고 말했다.

그보다는 소규모 클라우드 네이티브 기업이 소프트웨어 제공 프로세스를 개선하기 위한 깃옵스의 가능성을 탐색하기 시작했다. 대기업의 경우, 그린필드 디지털 이니셔티브 또는 연구 및 개발 센터와 같이 클라우드 네이티브 방식이 일반화된 분야에서 깃옵스에 관심을 둘 가능성이 높다.

개발자 중심의 시장조사업체 레드몽크(RedMonk)의 공동 창업자인 제임스 거버너는 “스마트한 기업은 개발자가 서버에 SSH로 연결하고 인스턴스를 만들고 통제되지 않는 방식으로 변경 작업을 수행하지 않도록 할 방법을 모색하고 있다. 깃옵스가 바로 그 문제를 해결해준다”라고 말했다.

그러나 밝은 전망에도 불구하고 깃옵스는 여전히 비주류에 머물러 있다. 깃옵스 방식이 아직 주류로 채택되지 않은 4가지 주요 이유와 이를 극복하기 위해 진행 중인 작업에 대해 알아보자.


깃옵스에는 정립된 패턴이 없다

깃옵스 생태계는 여전히 작고 열정적인 생태계다. 즉, 의사 결정의 기준이 될 수 있는 정립된 베스트 프랙티스와 실제 사례, 패턴 등 기업이 원하는 리소스가 거의 없다.

컨테이너 솔루션(Container Solutions)의 클라우드 전문 컨설턴트인 이안 미엘은 2020년에 이와 관련해 작성한 블로그 글에서 “현재 깃옵스의 가장 큰 과제는 선택의 가이드가 되는 정립된 패턴이 없다는 점”이라며, “진정한 표준이 정립될 때까지는 깃옵스 아키텍처를 제대로 구현하는 것은 과학보다는 예술에 가까운 상태가 지속될 것”이라고 지적했다.

이와 같은 과제를 해결하고 신규 도입을 더 용이하게 하기 위해 2020년 11월 CNCF 오픈 커뮤니티 프로젝트로 깃옵스 워킹 그룹이 출범했다. 아마존, 코드프레시(Codefresh), 깃허브(GitHub), 위브웍스(Weaveworks)가 주도하는 이 그룹이 초기에 맡은 일은 깃옵스의 원칙을 공급업체 중립적으로 명확하게 정의하고 깃옵스 방식의 도입을 늘리는 것이다.

코드프레시의 최고 오픈소스 책임자이자 깃옵스 워킹 그룹 공동 설립자인 댄 가필드는 본지와의 인터뷰에서 “지금은 부족(tribal) 지식을 끌어내 사람들이 쉽게 소비할 수 있도록 만드는 접근성 단계에 있다. 성숙 단계에 이르기 위해 깃옵스 원칙을 공식화하고 실무 전문가의 의견을 수렴해 우리가 놓친 부분을 확인하고 매끄럽지 않은 부분을 다듬고 사람들이 참고할 수 있는 커뮤니티 패턴과 참조 구현을 수집하고 있다"라고 말했다.

가필드는 워킹 그룹을 창설할 때 80명의 기업 대표가 참여하는 등 “커뮤니티의 호응이 컸다”라고 말했다.


깃옵스 도구의 성숙화 필요

일반적인 깃옵스 배포 프로세스를 보면, 개발자가 주로 깃을 통해(그래서 깃옵스라고 함) 새 기능을 위한 풀 요청을 수행한다. 승인된 요청은 CI/CD 파이프라인을 트리거하고 코드를 테스트하고 레지스트리에 배포된다. 이후 소프트웨어 에이전트(일반적으로 아르고(Argo) 또는 플럭스(Flux))가 클러스터의 상태가 깃의 구성과 일치하는지 여부를 자동으로 탐지하고 변경을 풀링하고 새 기능을 배포한다.

가필드는 “몇 년 전에는 대체로 깃 연산자와 비슷한 것을 만들어 버전 제어 스토리지를 사용해 인프라를 코드로 가져와 동기화했다. 문제는 깃옵스의 정의에 맞느냐가 아니라, 이것이 맞춤형 도구를 사용하는 팀의 비공식적인 방법이고 난해했다는 점이다. 이제 아르고 또는 플럭스와 같은 클라우드 전용 도구를 사용해 이 프로세스를 제대로 간소화할 수 있다”라고 지적했다.

이런 도구는 최근 몇 년 사이 큰 발전을 이뤘지만 도입을 간소화하기 위해 채워야 할 틈이 여전히 남아 있다. 코드프레시의 개발자 지지자인 코스티스 카펠로니스는 “깃옵스 방법론에는 몇몇 흥미로운 특징과 매력이 있지만 현재 깃옵스 도구는 애플리케이션의 배포 부분에만 주력할 뿐 그 외에는 아무것도 없다”라고 말했다. 

카펠로니스는 현재 제공되는 깃옵스 도구에는 환경, 비밀 취급, 연기(smoke) 테스트 및 감사 간의 전파를 규정하는 기능이 없다는 점을 지적했다. 카펠리노스는 "이는 팀이 소프트웨어 제공의 모든 측면에 대한 모범 사례를 자체적으로 만들어야 한다는 것을 의미한다"라고 덧붙였다.

포레스터의 수석 분석가 크리스토퍼 콘도는 깃옵스 도구의 다음 단계에 대해 테라폼(Terraform)과 직접 통합되어 개발자가 코드형 인프라를 더 쉽게 실행할 수 있게 해주는 깃허브 액션(GitHub Actions)과 같이 개발자들이 이미 작업하고 있는 클라우드 플랫폼에 내장되어 개발자들이 굳이 인식하지 않으면서 자연스럽게 깃옵스를 실행할 수 있게 되는 형태가 될 수 있다고 예상했다.

 
대규모 깃옵스 실행에 따르는 중대한 과제

서비스 업체 컨테이너 솔루션의 클라우드 전용 설계자인 애덤 샌도르는 깃옵스에는 대규모 실행 시 여전히 뚜렷한 제약이 있다고 지적했다. 이런 제약에는 여러 깃 리포지토리에 걸쳐 실행할 때의 감사, 교정, 관찰 가능성 문제가 포함된다.

기업이 자체 내부 개발자 플랫폼을 구축하도록 돕는 신생업체인 휴머니텍(Humanitec) CEO 카스파 본 그룬버그는 “10~15명의 전문가가 포함된 소규모 팀에서의 깃옵스는 가능한 최선의 방법”이라면서 “특정 수준에서는 훌륭하지만, 대기업에서의 대규모 깃옵스 구현은 극히 힘든 일”이라고 말했다.

다양한 환경 간에 변경 사항을 전파하는 프로세스를 보자. 카펠리노스는 “이는 깃옵스의 잘 알려진 문제점 가운데 하나이며, 깃옵스가 대기업에서 어떻게 작동할 수 있는지에 관한 논의에서 가장 먼저 나오는 주제”라고 말했다.

카펠리노스는 “누군가가 깃옵스 도입 과정이 쉽다고 말할 때마다 나는 항상 다양한 환경 간의 전파가 어떻게 작동하는지를 묻는다. 돌아오는 답은 항상 다르다. 깃옵스의 문답 페이지에서도 ‘깃옵스는 한 단계의 변경을 다음 단계로 전파하기 위한 솔루션을 제공하지 않는다. 우리는 하나의 환경만 사용해 단계 전파를 아예 피할 것을 권장한다’고 나와 있다는 점이 매우 실망스럽다”라고 비판했다.

대규모 깃옵스 배포의 다음 문제는 관찰 가능성 문제다. 카펠리노스는 “현재 상태의 깃옵스 도구는 기술적인 수준에서 클러스터의 콘텐츠를 관찰하기에는 좋지만 각 배포의 비즈니스 메트릭을 모니터링하는 부분에서는 크게 뒤떨어진다. 환경과 애플리케이션의 수가 많은 대기업에서 깃옵스를 도입하는 경우, 깃 리포지토리의 수가 급격히 증가하게 된다. 따라서 각 환경에서 현재 일어나는 일을 추적하기가 매우 어렵게 되고, 이내 구성 중복 또는 특정 환경에 커밋하는 문제로 이어질 수 있다”라고 지적했다.

예를 들어 쿠버네티스 매니페스트가 있는 20개의 깃 리포지토리가 있고 중앙 변경 작업을 수행해야 하는 경우 지금은 수동으로 20번의 깃 커밋을 수행하거나 이를 대신 수행해줄 코드를 직접 작성해야 한다.

코드프레시의 가필드는 “현재 이 관찰 가능성 문제를 극복하고자 모든 배포를 보기 위한 유용한 도구를 만들고 있다”면서, “규모 문제를 해결하는 것이 중요하다. 곳곳에 조정자(reconciler)가 있고 오늘 수행한 많은 변경 중에서 퇴행을 유발한 것이 무엇인지 알 수 없게 되는 상황이 갑자기 발생하고 규모에 대처할 수 있는 수단이 필요하기 때문이다. 지금은 이 부분에 주력하고 있다”라고 말했다.


깃옵스 필요성 설득의 어려움

사용자에게 더 많은 기능을 제공하기 위한 길은 데브옵스임을 이제 막 설득한 마당에, 사장실로 돌아가 이번에는 깃옵스라고 다시 설득해야 한다. 누구에게나 부담스러운 일이고 깃옵스의 주류 부상을 막는 또 다른 요인이기도 하다. 

위브웍스 CTO 코넬리아 데이비스는 “플랫폼 팀 또는 개발자 지원 팀에 있는 실무자, 깃옵스가 가져다줄 혜택을 인지하기 시작한 이들이 의사 결정권자가 깃옵스의 가치를 이해하도록 돕는 데 어려움을 겪고 있다. 이를 설명하는 방식이 지나치게 단순하거나 비즈니스 가치에 대응하지 않는 경우가 많기 때문이다”라고 말했다.

데이비스가 자주 보게 되는 실수 가운데 하나는 깃옵스를 데브옵스의 대체제로 생각하는 것이다. 데이비스는 “전환이 아닌 회전”이라면서 “애자일 개발과 이를 지원하는 도구의 성숙도는 크게 높아졌고 다양한 최적화도 이뤄지고 있다. 깃옵스가 말하는 것은 개발 측면에서는 그동안 많은 일을 했으니, 이제 운영 측면에서 더 많은 일을 해야 한다는 것”이라고 설명했다.

포레스터의 콘도는 “문제는 이 기술이 복잡하며, 익숙한 사람이 많지 않다는 점이다. 앞으로 몇 년 동안 개발자와 클라우드 엔지니어 스킬의 조합을 갖추지 못한 여러 기업이 개발과 운영을 하나로 모으기 위한 더 나은 방법을 찾으면서 많은 개선이 이뤄지게 될 것이다. 깃옵스의 문제가 있다면, 그건 너무 빨리 앞으로 나가는 바람에 모든 사람들이 정렬된 형태로 참여하지 못한다는 점”이라고 평가했다. 

레드몽크의 거버너는 깃옵스가 제공하는 제어 측면에 초점을 맞추는 것이 전환의 매력적인 이유가 될 수 있다면서, “개발자가 문제의 소지가 있는 시스템 변경을 수행하는 데 관한 우려에 바로 비즈니스 사례가 있다. 지금은 거친 서부 시대와 같다. 깃옵스의 핵심은 통제력을 되찾는 것”이라고 말했다.

깃옵스가 유의미한 방식으로 자리를 잡기 위해서는 사람들에게 적절히 투자하고 깃옵스로 가능한 혜택을 이해하기 위한 시간과 공간을 주는 것이 중요하다. 거버너는 “새로운 작업 방식이 그냥 실현될 것으로 기대하면 안 된다. 기업 전체가 갑자기 깃옵스를 실천하게 되는 일은 없다. 새 프로젝트를 계획하고 클라우드 전용 인프라를 살펴볼 때 몇몇 깃옵스 방식을 테스트해 조직적인 확신을 쌓을 수 있을 것”이라고 조언했다. 

모든 지표는 깃옵스의 도입이 아직 초기 단계에 있음을 가리키고 있지만 IDC의 머서는 "데브옵스보다 더 빠르게 자리를 잡을 가능성이 높다고 본다. 문화적 장벽이 이미 어느정도 허물어져 있기 때문이다. 데브옵스와 지속적 제공을 이미 실천 중이라면 소수에 속하지만 깃옵스를 도입하기 위한 준비는 잘 되어 있는 것이다"라고 말했다. editor@itworld.co.kr


X