Docker Compose 만으로 1년 — Kubernetes 로 가지 않은 이유

늘 나오는 질문

“지금 규모면 Kubernetes 쓸 때 되지 않았나요?” 이 질문을 외부에서도, 팀 내부에서도 받는다. 1년 동안 Docker Compose로만 운영을 유지했는데, 그게 부족해서 고생한 적은 있었다. 그럼에도 아직 전환하지 않은 이유를 정리하면 세 가지다.

이유 1: 운영 복잡도는 인원에 비례해야 한다

Kubernetes는 강력하다. 오토스케일링, 자동 복구, 세밀한 배포 전략—이 기능들이 필요한 팀에게는 분명히 맞다. 그런데 이 기능들을 제대로 쓰려면 관리할 사람이 필요하다. 클러스터 상태를 모니터링하고, 업그레이드를 관리하고, 설정을 유지하는 일이 계속 생긴다.

세 명이 운영하는 팀에서 그 일을 담당할 한 명을 붙이면, 제품 개발에 투입할 수 있는 인원이 줄어든다. 인프라 복잡도를 높이는 건 팀 규모에 맞게 결정해야 한다.

이유 2: 우리의 스케일 문제는 수평 확장이 아니었다

Kubernetes의 핵심 강점 중 하나는 수평 확장이다. 트래픽이 늘면 컨테이너를 더 띄운다. 우리 시스템의 병목은 수평 확장으로 해결되는 문제가 아니었다. 쿼리 최적화, 불필요한 외부 API 호출 제거, 캐시 전략 개선—이런 쪽이 실제 성능 개선을 만들었다.

수평 확장이 필요한 문제가 아닌데 수평 확장에 최적화된 도구를 도입하면, 진짜 문제 해결을 미루는 것과 같다.

이유 3: Compose로 해결하지 못한 게 없었다

1년 동안 Docker Compose로 해결하지 못해서 고생한 상황을 구체적으로 떠올려봤다. 배포 중 다운타임이 있었던 적이 있다. 이건 Compose의 한계가 아니라 배포 스크립트 설계 문제였다. Blue-green 배포 스크립트를 직접 작성해서 해결했다.

로그가 분산되어 있어서 추적하기 불편했던 적도 있다. 이건 로그 수집 컨테이너를 Compose에 추가해서 해결했다.

물론 Kubernetes가 이 문제들을 더 깔끔하게 해결해준다. 하지만 “더 깔끔한 방법이 있다”는 것과 “지금 당장 전환해야 한다”는 건 다른 이야기다.

언제 전환할 것인가

전환을 고려하게 되는 기준은 세 가지다. 팀 인원이 인프라 담당을 따로 두기에 충분히 늘어났을 때, 수평 확장이 실제로 필요한 트래픽 수준에 도달했을 때, Compose로 해결이 안 되는 구체적인 문제가 생겼을 때.

기술 도입의 타이밍은 기술의 성숙도가 아니라 팀의 상황이 결정해야 한다. 그 기준이 명확하지 않은 상태에서 “남들이 쓰니까” 전환하는 건 비용을 선불로 내고 혜택은 나중에 오거나 아예 안 오는 도박이다.

— by mings