클라우드 네이티브 컴퓨팅 재단(CNCF) 환경을 살펴보면 클라우드 개발자가 매우 운이 좋아 보일 수 있다. 소프트웨어 개발 생애주기의 거의 모든 단계를 위한 도구가 이미 존재하는 듯 보이기 때문이다. 개발자가 원하는 작업(예: 기능 개발)에만 집중하고, 나머지 작업(예: 지속적 통합과 배포)은 이미 갖춰져 있다는 의미로 보일 수 있다. 정말 그럴까?

그렇지 않다. CNCF 환경은 전체 이야기의 일부만 보여준다. 현재 제공되는 클라우드 도구를 보면 모든 영역이 커버된 듯 보이고, 심지어 과도하게 많아 보이기까지 한다.

현재의 클라우드 생태계가 가진 문제는 초점이 잘못 맞춰져 있다는 점이다. 대다수 도구가 관리자와 운영자를 대상으로 설계돼 있으며, 기능 개발자를 위한 도구는 상대적으로 부족하다. 그 결과 기업에서 더 많은 도구를 도입할수록 개발자의 만족도는 오히려 낮아지는 역설이 생긴다. 이 상황을 피할 수 있을까?

클러스터 너머를 보라

처음 만들어진 클라우드 도구가 인프라 구축 중심이었던 것은 자연스러운 흐름이었다. 결국 사용자에게 가치를 제공하려면 애플리케이션을 실행할 장소가 필요했기 때문이다. 클라우드 생태계에서 명확한 승자는 쿠버네티스(Kubernetes)였고, 많은 도구가 이를 중심으로 발전했다. 지금도 대다수 도구는 클러스터 자체를 관리하는 기능을 제공한다.

이러한 도구는 훌륭한 출발점이지만, 개발자에게 실제로 도움이 되지는 않는다. 개발자는 기능을 배포하는 일만 신경 쓴다. 쿠버네티스는 개발자에게 과거 가상머신처럼 단순한 기술적 구성 요소일 뿐이다.

문제는 현재 존재하는 거의 모든 도구가 개별 클러스터에 초점을 맞춘다는 점이다. 기업에서 어떤 형태로든 쿠버네티스 대시보드를 사용 중이라면, 왼쪽 사이드바에 “클러스터”라는 큰 버튼이 있어 모든 쿠버네티스 설치 목록을 보여줄 것이다.

하지만 현실은 다르다. 개발자는 쿠버네티스 클러스터에 관심이 없다. 개발자가 신경 쓰는 것은 환경, 더 구체적으로는 QA·스테이징·프로덕션이라는 세 가지 전통적 환경뿐이다. 그것이 전부다.

기업에서 스테이징이 단일 클러스터일 수도 있고, 두 개의 클러스터로 구성될 수도 있다. 혹은 더 큰 클러스터 내부의 네임스페이스일 수도 있고, 심지어 가상 클러스터일 수도 있다. 개발자에게 이런 차이는 중요하지 않다. 개발자가 원하는 것은 기능을 한 환경에서 다음 환경으로 손쉽게 배포하는 방식뿐이다.

개발자의 작업을 쉽게 만들고 싶다면, 개발자가 실제로 필요로 하는 것을 제공해야 한다.

개발자에게 필요한 것은 다음과 같다.

• 논리적 단계가 명확히 구성된 사전 정의 환경 목록
• 쿠버네티스 내부 구조를 깊이 이해하지 않아도 애플리케이션을 해당 환경에 배포할 수 있는 방식
• 새로운 기능을 고립된 상태에서 시험할 수 있는 임시 미리보기 환경 생성 기능
• 배포 중 문제가 발생했을 때 이를 분석할 수 있는 진단 도구

이런 방식이 제공되면 개발자는 자신에게 중요한 작업에 집중할 수 있다. 개발자에게 헬름(Helm), 커스터마이즈(Kustomize), 또는 쿠버네티스 매니페스트 구조를 이해하라고 요구하면 시간만 낭비하게 된다. 배포가 실패할 때마다 “쿠브씨티엘(kubectl)로 클러스터를 확인하라”는 답만 제공한다면 잘못된 접근이다.

배포보다 더 중요한 프로모션

개발자에게 개별 클러스터가 아니라 환경 중심의 대시보드를 제공했다고 가정해보자. 이것만으로 충분할까?

환경에 배포할 수 있는 방법도 반드시 제공해야 한다. 그러나 중요한 차이가 존재한다. 대시보드는 배포와 프로모션의 차이를 명확하게 이해해야 한다.

환경으로의 배포는 단순해야 한다. 개발자는 다음 선택이 가능해야 한다.

• 애플리케이션 버전 선택(최신 버전 또는 이전 버전)
• 적절한 접근 권한을 가진 환경 선택
• 배포가 성공적으로 완료됐는지 확인할 수 있는 절차

겉보기에는 단순해 보일 수 있다. 실제로도 단순한 과정이다. 그러나 이 절차가 유용한 것은 코드를 최초로 검증해야 하는 첫 번째 환경에 한정된다. 그 이후 단계의 환경에서는 개발자가 배포가 아니라 프로모션을 원한다.

배포와 달리 프로모션은 조금 더 복잡하다. 프로모션은 이전 환경(예: QA)에서 이미 검증된 동일한 패키지를 다음 환경(예: 스테이징)으로 이동시키는 과정을 의미한다.

기업 내 여러 환경을 살펴보면, 환경 간 유사성을 얼마나 유지하느냐를 둘러싼 지속적인 균형 조정이 존재한다. 가장 대표적인 사례는 스테이징 환경이 프로덕션과 최대한 비슷해야 한다는 점이다. 그래야 실제와 유사한 조건에서 애플리케이션을 시험할 수 있기 때문이다.

반대로, 스테이징이 프로덕션 데이터베이스나 프로덕션 메시지 큐에 접근해서는 안 된다는 점은 명확하다. 스테이징 데이터는 분리된 인프라에서 관리돼야 한다.

즉, 기본적으로 일부 설정 값(예: 데이터베이스 인증 정보)은 프로덕션과 스테이징이 다를 수밖에 없다. 개발자가 애플리케이션을 프로모션하려고 할 때 실제로 원하는 것은 다음과 같은 작업이다.

• 환경 간 이동이 필요한 요소만 가져오기
• 환경마다 동일하게 유지되는 설정 값은 건드리지 않기

매우 중요하지만, 대다수 클라우드 도구는 이 차이를 이해하지 못한다. 많은 프로덕션 장애는 프로덕션과 스테이징 간 설정 변경이 서로 달랐거나, 또는 개발자가 이전 환경을 거치지 않고 잘못된 버전을 프로덕션에 배포했기 때문에 발생한다.

다시 개발자 대시보드 이야기로 돌아가 보면, 개발자에게 애플리케이션의 모든 버전을 나열한 목록만 제공해 원하는 버전을 선택해 배포하도록 하는 방식은 잘못된 구조다. 개발자가 실제로 원하는 것은 이전 환경에서 이미 작동이 검증된 상태 그대로의 패키지를 프로모션하는 것이다.

특히 프로덕션 환경에서는 이 규칙이 항상 강제돼야 한다. 프로덕션 배포는 애플리케이션 버전이 환경 간 단계를 따라 올라가는 최종 단계이기 때문이다.

대시보드는 환경별로 어떤 설정이 프로모션 대상인지, 어떤 설정이 환경마다 그대로 유지되는지도 함께 이해해야 한다. 예를 들어 쿠버네티스 기준으로 환경별 레플리카 수는 일반적으로 고정값이다. 반면, 프로모션이 발생할 때는 애플리케이션의 구성맵(configmap) 같은 요소는 환경 간 이동해야 한다.

클라우드 시대에는 기존 방식이 작동하지 않는다

앞서 환경과 프로모션을 살펴봤으니, 이제 실제 배포가 어떻게 진행되는지 살펴볼 시점이다. 전통적인 애플리케이션 배포 방식은 파이프라인을 이용하는 것이었다. 대다수 지속적 통합 도구는 여러 단계(또는 스크립트)를 순차적으로 실행하는 형태의 파이프라인을 제공한다.

전형적인 파이프라인은 다음 단계로 구성된다.

• 애플리케이션 소스 코드를 가져오기
• 코드를 컴파일하고 빌드하기
• 단위 테스트 및 통합 테스트 실행
• 취약점 검사를 수행
• 최종 산출물 형태로 패키징

클라우드 이전 시대에는 파이프라인의 마지막 단계에서 생성된 바이너리 산출물을 특정 서버로 배포하는 과정(FTP, rsync, SSH 등)이 추가되는 경우가 많았다. 문제는 파이프라인이 실행 중일 때만 상태를 알고 있다는 점이다. 파이프라인이 종료되는 순간, 클러스터 내부에서 무슨 일이 일어나는지 더 이상 파악할 방법이 없다.

이 구조는 개발자에게 매우 불리한 상황을 만든다. 전형적인 패턴은 다음과 같다.

• 개발자가 배포를 진행할 준비를 한다.
• 지속적 통합 도구의 대시보드에서 해당 파이프라인을 실행한다.
• 파이프라인은 정상적으로 실행돼 애플리케이션을 클러스터에 배포한다.
• 파이프라인은 성공(초록불) 상태로 종료된다.
• 몇 분 뒤 애플리케이션에 문제가 발생한다(예: 응답 지연, 데이터베이스 접속 불가, 파드 삭제).

개발자가 보는 화면은 여전히 성공 상태이기 때문에, 어디에서 문제가 발생했는지 알 방법이 없다.

이 시점에서 개발자는 문제 원인을 파악하기 위해 복잡한 지표나 외부 시스템을 직접 확인해야 한다. 그러나 개발자가 배포 성공 여부를 판단하기 위해 여러 도구를 전전하는 구조는 올바르지 않다.

배포 시스템은 초기 배포가 끝난 이후에도 애플리케이션을 지속적으로 감시해야 한다. 클라우드 환경에서는 자원이 수시로 생성되고 사라지며, 특히 쿠버네티스 환경에서는 자동 확장 기능이 항상 작동하기 때문에 이는 필수 요건이다.

클라우드 배포 방식에 맞춰 변화해야

클라우드 컴퓨팅에는 그 자체의 과제가 있다. 기존 도구 대부분은 클라우드 혁신 이전 시대에 만들어졌고, 클라우드 배포의 동적인 특성을 고려해 설계된 것이 아니다. 이런 흐름 속에서 개발자는 점점 뒤처지고 있으며, 그 이유는 개발자가 실제로 무엇을 필요로 하는지 업계가 제대로 이해하지 못했기 때문이다.

쿠버네티스 사례를 보면, 기존 도구는 대부분 운영자와 관리자 중심으로 설계돼 있다.

• 개발자에게 쓸모 없는 저수준 정보를 과도하게 표시한다.
• 환경 간 차이를 이해하지 못하고, 애플리케이션 프로모션 구조도 이해하지 못한다.
• 여전히 기존 지속적 통합 파이프라인 중심의 사고방식을 유지하고 있다.

클라우드 컴퓨팅이 개발자에게 미치는 영향을 재정립할 필요가 있다. 최근 생성형 인공지능과 대규모 언어 모델이 빠르게 확산되면서, 앞으로는 애플리케이션 개발보다 배포 과정이 더 큰 병목이 될 것이다. 스마트 개발환경이나 인공지능 에이전트를 통해 개발자는 기능을 빠르게 만들 수 있지만, 프로모션 방식이나 실패한 배포의 원인을 신속하게 파악하는 과정은 여전히 이해하기 어려울 것이다.
dl-itworldkorea@foundryco.com