<aside>
☁️ 클라우드웨이브 · W06 · 1/5 · 예상 읽기 6~8분
</aside>
이번 특강을 돌아보며 가장 먼저 든 생각은 컨테이너가 단순한 포장 기술이 아니라 운영 단위를 다시 정의하는 방법이라는 점이었다. 하나의 큰 애플리케이션은 시작하기 쉽지만 일부 기능만 확장하거나 배포하려 할 때 결합도가 문제가 된다. 기능을 작은 서비스로 나누면 배포 단위가 유연해지지만, 실행 위치와 상태를 관리해야 하는 부담은 커진다. 컨테이너는 이 부담을 다루기 위한 공통 실행 단위를 제공한다.
이미지는 애플리케이션 실행에 필요한 파일과 메타데이터를 일정한 형태로 묶는다. 같은 이미지를 개발, 검증, 운영 환경에서 사용하면 환경 차이에서 생기는 변동을 줄일 수 있다. 그렇다고 컨테이너 하나를 실행하는 것만으로 운영 문제가 사라지는 것은 아니다. 장애가 난 컨테이너를 다시 띄우고, 여러 복제본에 요청을 나누고, 배포 순서를 관리해야 한다.
Kubernetes의 컨트롤러는 현재 상태를 관찰하고 원하는 상태와의 차이를 줄이는 역할을 한다. 이 조정 관점은 뒤에서 만날 Ansible의 멱등성과도 닮아 있다. 다만 Kubernetes가 클러스터 안의 워크로드를 지속적으로 조정한다면, Ansible은 호스트와 시스템 구성에 대한 작업을 자동화하는 데 더 직접적으로 쓰인다.
flowchart LR
A[애플리케이션 코드] --> B[컨테이너 이미지]
B --> C[오케스트레이션]
C --> D[복제·배포·복구]
D --> E[프라이빗 클라우드 운영]
E --> F[백업·장기 보존]
프라이빗 클라우드는 내부 자원을 표준화된 방식으로 제공하는 운영 플랫폼으로 볼 수 있다. 사용자는 콘솔이나 자동화 인터페이스를 통해 자원을 요청하고, 운영자는 정책과 관찰 가능성을 관리한다. 여기서 중요한 것은 서비스 기획과 플랫폼 구현을 따로 보지 않는 것이다. 자원 생성만 자동화하고 삭제, 권한, 백업, 비용, 장애 대응을 정의하지 않으면 플랫폼은 쉽게 일회성 환경이 된다.
이 관점에서 컨테이너 플랫폼의 운영자는 배포 성공만 확인해서는 안 된다. 어느 이미지가 실행 중인지, 롤백 기준은 무엇인지, 장애 시 어떤 상태를 복구할지까지 운영 계약에 포함해야 한다. 실행 단위와 데이터 보존 단위를 분리해 설계하는 것이 출발점이다.
운영 데이터와 백업 데이터는 목적이 다르다. 운영 데이터는 빠른 읽기와 변경에 초점을 두지만, 백업은 실수나 장애 이후 복구할 수 있는 복사본을 보존하는 데 초점을 둔다. 따라서 백업 주기, 보존 기간, 삭제 정책, 복구 테스트를 정책으로 표현해야 한다. 오브젝트 스토리지는 대량 데이터를 장기 보관하는 선택지가 될 수 있고, 저장 기간에 따라 비용과 접근 속도를 조절할 수 있다.
백업이 있다는 사실과 복구할 수 있다는 사실도 구분했다. 정기적으로 복구 절차를 시험하고, 복구에 필요한 구성 정보와 책임자를 함께 기록해야 한다. 그래야 컨테이너 장애와 데이터 손실을 같은 문제로 뭉뚱그리지 않고 각각의 대응 시간을 판단할 수 있다.
컨테이너를 배포할 때는 이미지 태그만 정하는 것으로 끝내지 않고 로그, 상태 데이터, 비밀정보, 복구 절차를 함께 기록해야 한다. 프라이빗 환경이라면 자원 표준과 네트워크 경계를 먼저 정하고, 백업이 성공했다는 기록과 실제 복구가 가능한지를 구분해서 확인한다. 운영팀이 수동으로 기억해야 하는 항목이 많을수록 자동화 후보가 된다.
컨테이너와 가상 머신은 모두 격리된 실행 환경처럼 보이지만 같은 방식으로 동작하지 않는다. 컨테이너는 호스트 커널을 공유하며 프로세스를 격리하고, 가상 머신은 별도의 운영체제 환경을 구동한다. 또한 Kubernetes가 모든 인프라 문제를 해결하는 도구는 아니다. 클러스터 밖의 네트워크와 저장소, 백업 정책은 여전히 별도의 설계가 필요하다.