— 상황별로 어떤 선택이 현실적일까
쿠버네티스 도입 시점을 고민하다 보면,
자연스럽게 이런 비교로 이어진다.
- “굳이 쿠버네티스까지 가야 할까?”
- “도커 컴포즈로도 충분하지 않을까?”
- “차라리 서버리스가 더 맞는 건 아닐까?”
이 글에서는
쿠버네티스, 도커 컴포즈, 서버리스를
기술 우열이 아니라 사용 맥락 기준으로 비교한다.
실무에서 선택이 갈리는 지점을 중심으로 정리한다.
비교의 전제: 같은 문제를 푸는 도구가 아니다
먼저 짚고 가야 할 점이 있다.
이 세 가지는 같은 문제를 다른 방식으로 푸는 게 아니라,
애초에 풀려고 하는 문제의 범위가 다르다.
그래서 “무조건 뭐가 낫다”는 비교는 의미가 없다.
대신 어떤 상황에서 어떤 선택이 덜 아픈지를 보는 게 중요하다.
도커 컴포즈: 가장 단순하고 빠른 선택
도커 컴포즈는
여러 컨테이너를 한 서버에서 관리하기 위한 도구다.
도커 컴포즈가 잘 맞는 상황
- 단일 서버 또는 소규모 환경
- 서비스 개수 적음
- 배포 빈도 낮음
- 운영 자동화 요구가 크지 않음
실제로 많은 서비스가
도커 컴포즈만으로도 충분히 안정적으로 운영된다.
도커 컴포즈의 한계
운영 규모가 커지면
다음 지점에서 한계가 드러난다.
- 서버 장애 시 자동 복구 어려움
- 수평 확장 개념이 약함
- 무중단 배포 구현이 번거로움
- 서버가 늘어나면 관리 복잡도 급증
즉, 서버가 늘어나는 순간부터
운영 부담이 빠르게 증가한다.
쿠버네티스: 운영 복잡성을 시스템으로 넘기는 선택
쿠버네티스는
여러 서버에 걸친 컨테이너 운영을 전제로 설계된 플랫폼이다.
쿠버네티스가 강점을 가지는 지점
- 다수 서버(Node) 운영
- 자동 복구와 재스케줄링
- 무중단 배포 기본 제공
- 선언형 운영 방식
- 확장성과 표준화
운영을 해보면
“사람이 하던 판단을 시스템에 넘긴다”는 느낌이 강하다.
쿠버네티스의 비용
다만, 장점만 있는 선택은 아니다.
- 학습 비용이 크다
- 초기 설정이 복잡하다
- 운영 관점 이해가 필요하다
- 소규모 환경에서는 과할 수 있다
⚠️ 특히 팀에 운영 경험이 거의 없는 상태라면
도입 초기에 부담이 크게 느껴질 수 있다.
서버리스: 운영을 최대한 없애는 선택
서버리스는
서버와 인프라 운영 자체를 최소화하는 접근이다.
대표적인 특징은 다음과 같다.
- 서버 관리 없음
- 자동 확장
- 사용한 만큼 비용 지불
- 빠른 초기 구축
서버리스가 잘 맞는 경우
- 이벤트 기반 처리
- 트래픽 변동이 큰 서비스
- 빠른 MVP, 프로토타입
- 인프라 운영 리소스가 부족한 팀
실제로 초기 스타트업이나
내부 도구, 백오피스 서비스에서는
서버리스가 훨씬 효율적인 경우도 많다.
서버리스의 제약
하지만 서버리스도 만능은 아니다.
- 실행 시간 제한
- 상태 관리 제약
- 로컬 개발/디버깅 난이도
- 벤더 종속성
특히 복잡한 상태를 가진 서비스에서는
구조가 오히려 더 복잡해질 수 있다.
한눈에 보는 선택 기준 정리
정리를 위해
현실적인 기준으로 나눠보면 다음과 같다.
- 도커 컴포즈
- 소규모
- 단일 서버
- 운영 단순성 우선
- 쿠버네티스
- 중·대규모
- 다수 서버
- 안정성과 확장성 중요
- 서버리스
- 이벤트 중심
- 빠른 개발
- 운영 최소화
중요한 건 “유행”이 아니라
“지금 우리에게 가장 덜 복잡한 선택”이다.
섞어서 쓰는 것도 현실적인 선택이다
실무에서는
이 셋을 완전히 분리해서 쓰지 않는 경우도 많다.
예를 들어,
- 핵심 서비스는 쿠버네티스
- 배치성 작업은 서버리스
- 내부 도구는 도커 컴포즈
이런 구조는
각 도구의 단점을 서로 보완해준다.
선택을 잘했다는 신호는 무엇일까
도구 선택이 잘됐다는 신호는 의외로 단순하다.
- 배포가 두렵지 않다
- 장애 대응이 예측 가능하다
- 운영 부담이 점점 줄어든다
반대로,
- 도구 관리 자체가 일이 된다면
그 선택은 다시 돌아볼 필요가 있다.
정리하며
이번 글에서는
쿠버네티스, 도커 컴포즈, 서버리스를
상황 중심으로 비교해봤다.
- 쿠버네티스는 운영 복잡성을 시스템에 넘기는 선택
- 도커 컴포즈는 단순함이 최대 장점
- 서버리스는 운영 자체를 줄이는 접근
- 하나만 고집할 필요는 없다
이 비교를 통해,
“왜 쿠버네티스를 쓰는지”뿐 아니라
“왜 쓰지 않을 수도 있는지”까지 함께 보였기를 바란다.
다음 글에서는
이 비교를 한 단계 더 확장해서,
실제 서비스 아키텍처 예시를 놓고 어떤 선택이 나왔는지를
케이스 중심으로 풀어볼 수 있다.
'infra' 카테고리의 다른 글
| 관리형 쿠버네티스(EKS·GKE) 장단점 정리: 편해지는 만큼의 비용과 책임 (0) | 2026.02.19 |
|---|---|
| 실제 서비스 사례로 보는 아키텍처 선택 (0) | 2026.02.18 |
| 쿠버네티스 도입 시점 판단 가이드: 언제 쓰는 게 맞을까 (0) | 2026.02.16 |
| 로컬 쿠버네티스 실습 ③: Ingress로 외부 접근과 라우팅 흐름 이해하기 (0) | 2026.02.15 |
| 로컬 쿠버네티스 실습 ②: ConfigMap과 리소스 설정으로 운영 구조 만들기 (0) | 2026.02.14 |