Kubernetes made deploying easy. Nobody warned you about the databases.

Kubernetes가 해결하지 못한 영역: 데이터베이스

Kubernetes는 애플리케이션 배포 방식을 근본적으로 바꿔놓았다. 컨테이너 오케스트레이션, 롤링 업데이트, 자동 복구 등 수많은 운영 부담을 플랫폼 수준에서 흡수하면서, 개발팀은 인프라보다 비즈니스 로직에 집중할 수 있게 됐다. 약 20년 전 시작된 DevOps 운동이 개발자와 IT 운영 팀 사이의 벽을 허물었고, Kubernetes는 그 철학을 기술적으로 완성시키는 도구처럼 여겨졌다.

하지만 이 흐름에서 조용히 빠져 있는 영역이 있다. 바로 데이터베이스다.

왜 데이터베이스는 여전히 다른가

애플리케이션 워크로드는 Stateless하게 설계하면 Kubernetes 위에서 자유롭게 스케일 아웃할 수 있다. 파드가 죽어도 새로운 파드가 뜨면 그만이다. 그러나 데이터베이스는 본질적으로 Stateful하다. 데이터는 어딘가에 영속적으로 저장되어야 하고, 그 일관성과 내구성은 인프라 레이어에서 쉽게 추상화되지 않는다.

Kubernetes에서 Stateful 워크로드를 다루기 위한 StatefulSet, PersistentVolume 같은 리소스가 존재하지만, 이것이 데이터베이스 운영의 복잡성 전체를 해결해주지는 않는다. 예를 들어 다음과 같은 문제들은 여전히 운영팀이 직접 다뤄야 한다.

백업 및 복구 전략: 파드 재시작과 데이터 복원은 전혀 다른 문제다.
리플리케이션 및 페일오버: MySQL, PostgreSQL 같은 DB의 HA 구성은 Kubernetes가 자동으로 보장하지 않는다.
스키마 마이그레이션: 배포 파이프라인에서 DB 마이그레이션을 안전하게 처리하는 것은 여전히 까다롭다.
스토리지 성능 튜닝: PVC로 볼륨을 붙이더라도, IOPS나 레이턴시는 클라우드 스토리지 계층에 따라 크게 달라진다.

실무에서 마주치는 현실

Java 백엔드 개발자 입장에서 이 문제는 생각보다 일찍 찾아온다. Spring Boot 애플리케이션을 Kubernetes에 올리는 건 Helm 차트 몇 줄로 가능하지만, 그 애플리케이션이 바라보는 PostgreSQL이나 MySQL을 어떻게 운영할지는 별도의 판단이 필요하다.

# StatefulSet 예시 - 단순히 띄우는 건 쉽다
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: "postgres"
  replicas: 1
  template:
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data

위처럼 단일 인스턴스 DB를 띄우는 건 어렵지 않다. 문제는 이후다. 운영 중 노드가 죽으면? 볼륨 마운트 실패 시 데이터는? 트래픽이 늘어날 때 Read Replica는 어떻게 붙이는가? 이 질문들에 대한 답은 Kubernetes 문서가 아니라 각 DB 엔진의 운영 가이드에서 찾아야 한다.

이런 이유로 많은 팀이 RDS, Cloud SQL 같은 매니지드 데이터베이스 서비스를 선택한다. Kubernetes 외부에 DB를 두고, 애플리케이션만 클러스터 안에서 돌리는 아키텍처다. 운영 부담을 클라우드 벤더에 넘기는 현실적인 선택이지만, 비용과 벤더 종속이라는 트레이드오프가 따른다.

반대로 Kubernetes 내부에서 DB까지 직접 운영하려는 팀은 Operator 패턴에 주목한다. CloudNativePG, Percona Operator 같은 툴은 DB 운영 지식을 Kubernetes 컨트롤러 로직으로 캡슐화하여, 페일오버나 백업 같은 작업을 자동화한다. 단, 이를 도입하고 운영하는 것 자체가 또 하나의 학습 곡선이다.

정리

Kubernetes는 Stateless 애플리케이션 배포를 크게 단순화했지만, Stateful한 데이터베이스 운영은 여전히 별도의 전문 지식이 필요하다.
실무에서는 매니지드 DB 서비스(외부 운영)와 Kubernetes Operator(내부 운영) 중 팀의 역량과 비용 구조에 맞는 선택이 중요하다.
배포 파이프라인을 설계할 때 DB 마이그레이션, 백업, 페일오버 전략을 애플리케이션 배포와 독립적으로 명시적으로 다루어야 한다.