시스템 이니셔티브, 데브옵스를 바꿀 수 있을까 : zum 뉴스

사실을 직시하자. 최근 데브옵스 영역, 특히 인프라 자동화 분야에서는 뚜렷한 혁신이 없었다.

기술이 급변했음에도 인프라 자동화 방식은 본질적으로 크게 달라지지 않았다. 물론 온프레미스 구성에서 클라우드, 컨테이너 환경으로의 전환은 있었고, 테라폼, 오픈토푸 같은 도구들도 등장했다. 그러나 선언형 구성 관리라는 기본 개념은 1990년대부터 이어져온 방식 그대로다.

시스템 이니셔티브(System Initiative)의 CEO 아담 제이콥은 이렇게 지적한다. “기술 환경은 바뀌었지만, 자동화를 구축하는 방식에 대한 사고방식은 정체돼 있다. 지금까지는 잘 버텨왔지만, 그 아이디어는 더 이상 확장될 수 없다.”

인프라를 코드로 관리하는 방식(Infrastructure as Code, IaC)이 잘못된 개념은 아니지만, 멀티클라우드 환경과 확장된 데브옵스 협업을 따라가기에는 한계가 있다. 테라폼 같은 도구는 범용적으로 적용하기 어렵고, 구성 파일은 버전 관리와 유지보수에서 큰 부담이 된다.

클라우드 라이프(Cloud Life)의 CEO 라이언 라이크는 기존 방식을 이렇게 비유한다. “테라폼이나 오픈토푸 같은 전통적 모델은 매우 선언적이다. 처음엔 ‘성채를 짓자!’라는 마인드로 시작하지만, 이틀만 지나면 누군가 수정하면서 성이 무너진다.”

궁극적으로 IaC는 여전히 깃허브 저장소에 정적으로 저장된 구성 파일일 뿐이다. 시간이 지나면 노후화되고, 지속적인 검토, 테스트, 업데이트가 필요해진다. 환경은 늘 변하기 때문에, 구성과 실제 인프라 간의 불일치도 끊임없는 걱정거리다.

“패러다임 전환”이라는 표현은 쉽게 써서는 안 된다. 그러나 시스템 이니셔티브는 그 표현에 가장 가까운 시도다라고 말한 이는 로키 리눅스(Rocky Linux)의 창립자이자 인프라 리드인 닐 핸런이다. 핸런은 시스템 이니셔티브를 “부딪히면 다치게 하는 유리창이 아니라, 사용자에 맞게 휘어지는 유리창”에 비유했다.

인프라 코드의 문제

현재의 IaC 구현 방식은 학습 곡선이 높다. 시스템 이니셔티브의 제이콥은 “자동화를 고민하기에 앞서, 모든 기술을 먼저 이해해야 한다는 것이 현실”이라고 설명한다.

대부분의 엔지니어는 테라폼, 풀루미(Pulumi), AWS 클라우드포메이션, 애저 리소스 매니저(Azure Resource Manager) 등을 통해 인프라를 정의하고 관리하며, 코드를 애플리케이션 코드와 함께 Git에 버전 관리한다. 그러나 애플리케이션 코드와 달리, 인프라 구성의 사소한 변경은 팀 전체에 영향을 미칠 수 있고, 배포 실패, 회귀 오류, 협업 지연으로 이어질 수 있다.

제이콥은 “구성 프로그래밍은 애플리케이션 프로그래밍보다 더 어렵다. 잘못되면 아예 동작하지 않는다”라고 말한다. “결국 혼자서, 시스템과, 팀원들과 끝없는 대화를 나누게 된다. 이걸 어떻게 작동하게 만들지 고민하는 대화 말이다.”

라이크 역시 IaC가 과도한 유지보수 작업을 초래한다는 점에 공감한다. “결국 테라폼 자체를 관리하는 데 시간을 쓰게 된다. 우리는 그 모든 도구 위에서 작동하는 단일 도구가 필요하다”라고 강조한다.

제이콥에 따르면 문제의 본질은, 업계가 인프라 자동화를 독립된 영역(domain)으로 보지 않았다는 데 있다. 건축가에게는 오토CAD가 있고, 게임 개발자에게는 유니티가 있다. 그러나 데브옵스에는 상응하는 표준이 없다.

시스템 이니셔티브는 이를 바꾸고자 한다. 엔지니어가 인프라를 하나의 살아있는 모델로 구축하고 유지하는 엔진을 제공하는 것이 목표다. 제이콥은 “그 엔진만 확보되면, 저수준 구성 요소를 고민하기보다 엔진과 어떻게 상호작용할지에 집중할 수 있다”라고 말한다.

시스템 이니셔티브의 작동 방식

시스템 이니셔티브는 기존 데브옵스 모델을 완전히 뒤집는다. 인프라 구성 코드를 데이터로 변환해, 인프라의 디지털 트윈을 생성한다. 서버 재시작, 복잡한 배포 실행 같은 작업은 함수(function) 형태로 표현되며, 이를 시각적 UI에서 동적으로 연결할 수 있다. 인프라 상태는 실시간 다이어그램으로 표시된다.

디지털 트윈은 시스템이 워크플로우와 상태 변화를 자동으로 추론하도록 돕는다. 예를 들어, 도커 컨테이너를 새로운 아마존 ECS 인스턴스에 연결하면 시스템 이니셔티브는 그 관계를 인식하고 모델을 갱신한다.

이런 워크플로우는 클릭 몇 번으로 재사용 가능한 모델로 저장할 수 있어, 속도가 비약적으로 향상된다. GUI 중심의 플랫폼은 실제로는 클라우드 인프라에 API 호출을 자동 생성한다.

기업마다 인프라 요구사항은 다르다. 보안, 컴플라이언스, 배포 방식 모두 제각각이다. 시스템 이니셔티브 같은 추상화 도구는 이런 다양성을 포용하면서도, 인프라 모델링과 운영의 일관성을 제공할 수 있다.

특히 멀티클라우드 채택이 늘어나고 있는 지금, 클라우드 간 일관된 관리 도구의 부족을 고려하면 이 점은 더욱 주목할 만하다. 시각적 모델은 데브옵스 팀이 공통된 인식 하에 협업할 수 있게 해주며, 병목 제거, 피드백 루프 단축, 가치 실현 시간 단축 등의 효과를 낳는다.

로키 리눅스의 커뮤니티 개발 지원

로키 리눅스 프로젝트는 시스템 이니셔티브를 이용해 새로운 MirrorManager 인프라를 구축 중이다. 이 서비스는 전 세계 로키 리눅스 설치 환경에서 지리적으로 가까운 패키지 미러를 찾을 수 있게 해준다.

이전에는 테라폼, 앤서블 등 다양한 도구를 병행하며 인프라를 개별적으로 관리했지만, 확장성과 접근성 모두에서 한계를 느꼈다. 핸런은 “이전 방식은 팀별 애플리케이션 소유권을 보장하기 어려웠다”라고 설명했다.

도입 중반이지만 협업 효과는 이미 나타나고 있다. 핸런은 “분산된 조직 구조를 가진 오픈소스 조직에서, 시스템 이니셔티브는 효과적인 중앙 관리 수단”이라고 평가한다. “이제는 보안, 인프라, 릴리스 팀 모두가 더 편하게 일할 수 있게 됐다”라고 말했다.

핸런은 특히 변화에 유연하며 과거 기록까지 조회 가능한 살아 있는 인프라 다이어그램 기능을 높이 평가하며, 시스템 이니셔티브가 데브옵스의 미래라고 확신하고 있다.

클라우드 라이프의 IaC 민주화

클라우드 컨설팅 기업 클라우드 라이프는 20~30개 고객사의 AWS 마이그레이션과 IaC 구현을 지원해왔다. 다양한 고객 요구를 충족시키려 테라폼 모듈을 수년간 수정해왔지만, 항상 부족함을 느껴왔다.

라이크는 “만능 모듈은 없었다”라고 잘라 말한다. “매번 다른 고객을 위해 모듈을 뜯어고쳐야 했고, 어떤 고객은 소스 코드 안에 테라폼을 넣기도 했다.”

이처럼 테라폼 생태계는 공용 포크, 비공개 모듈, 수작업 업데이트 등으로 인해 지나치게 복잡해졌다. 라이크는 “콘솔에서 클릭 한 번이면 끝날 일을 위해 너무 많은 시간과 비용이 들어간다”라고 지적한다.

라이크는 시스템 이니셔티브의 디지털 트윈 접근법이야말로 해결책이라고 본다. “중요한 점은, 시스템 이니셔티브는 단순 선언형 상태가 아니라 현실 세계 자체를 다룬다는 것이다.” 최근 분기 기준, 클라우드 라이프는 신규 프로젝트 6건에서 이를 기본 도구로 채택했다.

라이크는 “고객은 테라폼 따위 신경 쓰지 않는다. 앱이 어디서 잘 돌아가는지만 중요하다”라고 단언한다. 이제는 시각적 인프라 모델을 고객에게 인계하는 방식으로 운영 유지 부담을 없앴다.

기술적 전환의 시작점

시스템 이니셔티브는 단기적인 해법이 아니다. 제이콥은 “지금 가장 어려운 문제들을 근본적으로 바꾸려는 중”이라며, 빠른 전환은 어렵다고 인정한다. 기존 자동화 구조가 큰 팀일수록 전환은 더욱 복잡할 수 있다.

따라서 점진적인 테스트, 워크플로우 관찰, 부분적 도입을 권장한다. 초기 도입 대상으로는 그린필드 앱이나 아직 IaC를 도입하지 않은 대규모 배포 환경이 적합하다.

기존 인식도 장벽이 된다. 라이크는 “과거 클라우드 전환 때와 마찬가지로, 많은 기술자들이 이런 변화에 거부감을 보인다”라고 말한다.

제이콥은 클릭옵스에 대한 부정적 시선도 이해한다. 과거 GUI 기반 인프라 프로비저닝은 기능성과 완성도를 희생했기 때문에 실패했다. 그러나 시스템 이니셔티브는 그런 희생 없이, 사용성과 기능성을 동시에 잡을 수 있다고 강조한다.

물론, 예측 가능한 반복 작업이 많은 팀에는 기존 IaC가 더 적합할 수 있다. 테라폼이 여전히 잘 작동하는 환경도 많다. 크로스플레인(Crossplane), CDK 포 테라폼, 오픈토푸 등 다양한 현대화 시도 역시 병행되고 있다.

라이크는 시스템 이니셔티브가 아직 초기 제품의 특성을 갖고 있다고 본다. 일부 마찰 지점은 있으나, 팀이 적극적으로 대응하고 있으며, 앞으로 검색 기능, 운영체제 지원 범위 확대를 기대하고 있다. 현재는 AWS만 지원하고 있고, 구글 클라우드 플랫폼(GCP)과 마이크로소프트 애저(Azure) 지원은 예정 단계다.

또한 무료 배포판이 없다는 점도 고려 요소다. 시스템 이니셔티브의 엔진 코드는 오픈소스지만, 제품 자체는 유료다. 제이콥은 “시스템 이니셔티브는 무료 배포판이 없다”라고 명확히 밝혔다.

데브옵스의 미래

소프트웨어 세계는 급격히 변했다. 프로그래밍 언어가 바뀌고, 출시 주기가 몇 달에서 몇 시간으로 단축되고, 아키텍처가 진화했으며, 생성형 AI가 산업 전반을 흔들고 있다. 그러나 인프라 자동화의 기반 코드는 여전히 수십 년 전 방식에 머물러 있다.

제이콥은 “지금 인프라 자동화의 상태는 CRM이 등장하기 전의 기업 환경과 같다”라고 표현한다.

어떤 이는 이렇게 질문할 수도 있다. “그렇다면 생성형 AI로 IaC를 처리하면 되지 않을까?” 제이콥의 대답은 단호하다. 문제는 데이터다. 대부분의 사람들은 LLM이 마법처럼 느껴지지만, 결국 정형화된 데이터가 없다면 작동할 수 없다. 전통적인 인프라 도구는 그런 데이터를 노출하지 않는다.

시스템 이니셔티브는 고정밀 데이터 기반, 즉 LLM이 작동하기 위한 기반을 제공한다. 제이콥은 “우리가 마법 같은 AI 미래를 원한다면, 그 기반이 먼저 마련돼야 한다”라고 강조한다.

시스템 이니셔티브는 유지보수가 어려운 코드 중심 IaC를 버리고, 데이터 중심 디지털 모델로 전환함으로써 데브옵스의 생산성을 극대화하고자 한다. 아직 클라우드 지원은 부족하고, 검증된 사례도 많지는 않다. 전통적인 IaC 대신 독자적 실행 모델에 의존하는 구조 또한 기업 입장에선 리스크로 작용할 수 있다.

그럼에도 불구하고, 시스템 이니셔티브가 확산되고, 디지털 트윈 접근법이 성과를 입증한다면, 데브옵스의 새로운 시대가 도래할 가능성은 충분하다.

dl-itworldkorea@foundryco.com