쿠버네티스 리소스 관리, 도입 전에 따져야 할 것

쿠버네티스 리소스 관리, 우리 서비스에 정말 필요할까?

결론부터 적는다. 쿠버네티스의 리소스 관리 기능은 서비스 수가 많고, 트래픽 변동이 크고, 이를 튜닝할 운영 인력이 있을 때 이득이 커진다. 서비스가 10~20개 미만이고 트래픽이 안정적이면, 그 정교함이 오히려 운영 부담으로 먼저 나타난다. 이건 쿠버네티스가 느리거나 나쁘다는 뜻이 아니라, 정교함에는 그만큼의 튜닝 비용이 따른다는 뜻이다.

이 글의 핵심

• requests/limits는 자동 최적화 장치가 아니라 사람이 계속 조정해야 하는 정책 도구다.
• 2025년 Komodor 리포트 기준 워크로드의 65% 이상이 요청 리소스의 절반도 못 썼고, 82% 이상이 과다 프로비저닝 상태였다.
• 같은 리포트에서 고영향 장애의 median MTTD는 약 40분, MTTR은 50분 이상, 운영 시간의 60% 이상이 트러블슈팅에 쓰였다.
• 20개 미만 컨테이너 규모에서는 단순 구성(예: Docker Compose 방식)이 관리 명령·설정 라인 기준으로 더 단순하다는 보고도 있다.
• 판단 기준은 "쿠버네티스가 좋냐 나쁘냐"가 아니라 "이 정교함을 감당할 규모와 인력이 있냐"다.

직접 겪어본 바로는, 쿠버네티스 리소스 관리를 제대로 쓰려면 먼저 이게 뭘 하는 기능인지부터 다시 봐야 한다. "리소스를 관리한다"는 말은 막연하지만, 실제로는 파드 하나하나에 CPU·메모리 숫자를 박아 넣고, 그 숫자를 스케줄러와 커널이 어떻게 해석하는지까지 신경 써야 하는 일이다.

requests와 limits는 스케줄링을 어떻게 바꾸나?

requests는 "이 컨테이너가 최소 이만큼은 필요하다"는 선언이고, limits는 "이 이상은 쓰지 마라"는 상한이다. 쿠버네티스 공식 문서는 Pod 단위로 requests.cpu, requests.memory, limits.cpu, limits.memory를 명시하도록 안내한다. 스케줄러는 이 requests 값을 보고 어느 노드에 파드를 배치할지 결정한다. 노드에 남은 할당 가능 용량이 requests 합보다 적으면 그 파드는 아예 스케줄링되지 않는다.

문제는 이 숫자를 정하는 게 감이라는 점이다. requests를 너무 낮게 잡으면 실제 트래픽이 몰릴 때 노드 자원이 부족해 스로틀링이 걸리고, 너무 높게 잡으면 노드에 여유가 있어도 스케줄러가 새 파드를 못 붙인다. 그 결과가 바로 Komodor 리포트가 지적한 "워크로드의 65% 이상이 요청량의 절반도 못 쓰는" 상황이다. 즉 requests는 안전하게 잡을수록 클러스터 전체의 활용률이 떨어지는 구조적 트레이드오프를 안고 있다.

QoS 클래스와 OOM Kill은 어떤 원리로 얽혀 있나?

쿠버네티스는 requests와 limits 설정 조합에 따라 파드를 Guaranteed, Burstable, BestEffort 세 QoS 클래스로 나눈다. requests와 limits가 같으면 Guaranteed, requests만 있고 limits가 없거나 서로 다르면 Burstable, 둘 다 없으면 BestEffort다. 노드 메모리가 부족해지면 커널 OOM Killer는 이 QoS 순서의 역순으로, 즉 BestEffort부터 죽인다.

여기서 실무 함정이 하나 있다. limits를 넉넉히 잡아둔 Burstable 파드가 순간적으로 그 상한까지 메모리를 쓰면, 노드 전체 메모리 압박이 걸리면서 예상치 못한 다른 파드까지 함께 죽는 경우가 생긴다. limits는 "이 컨테이너를 보호하는 장치"가 아니라 "이 컨테이너가 다른 컨테이너를 침범하지 못하게 막는 장치"에 가깝다. 이 구분을 안 하고 limits를 그냥 넉넉하게만 잡으면, 장애가 났을 때 원인을 추적하는 데 오히려 시간이 더 든다.

파드가 많아질수록 리소스 관리가 왜 더 어려워지나?

파드 수와 클러스터 수가 늘어날수록 설정 하나하나의 오차가 누적되기 때문이다. Komodor 리포트는 조사 대상 조직이 평균 20개가 넘는 클러스터를 운영하고, 절반 가까이가 4개 이상의 환경을 오간다고 밝혔다. 클러스터마다, 환경마다 requests/limits 기준이 조금씩 다르면 어느 하나가 문제를 일으켰을 때 원인을 특정하기가 그만큼 어려워진다.

같은 리포트에서 생산 장애의 79%가 최근 시스템 변경에서 비롯됐고, 고영향 장애의 median MTTD가 약 40분, median MTTR이 50분 이상이라는 수치도 이 맥락과 이어진다. 리소스 설정 하나 바꾼 게 몇 클러스터를 거쳐 어떤 파드에 영향을 미쳤는지 추적하는 데 걸리는 시간이 그대로 장애 복구 시간으로 나타난다. 쿠버네티스는 고성능·저지연 워크로드를 위한 Node Resource Manager 같은 세밀한 제어 기능도 제공하지만, 이런 기능은 애초에 "latency-critical and high-throughput workloads"를 겨냥한 것이지, 소규모 서비스에 자동으로 필요한 건 아니다.

쿠버네티스를 쓰면 리소스가 자동으로 최적화된다는 말, 맞을까?

틀렸다. 쿠버네티스는 리소스를 "나눌 수 있는 틀"을 줄 뿐, 그 안의 숫자를 최적화해주지는 않는다. Komodor 리포트가 보여준 65%의 저활용, 82% 이상의 과다 프로비저닝은 쿠버네티스를 이미 쓰고 있는 조직들의 데이터다. 즉 오케스트레이터를 도입한다고 rightsizing이 저절로 되는 게 아니라, 별도로 사용량을 모니터링하고 requests/limits를 주기적으로 재조정하는 운영 프로세스가 있어야 그 이득이 실현된다.

이 오해가 위험한 이유는, "일단 쿠버네티스로 옮기면 리소스 문제는 해결된다"는 전제로 마이그레이션을 결정하는 팀이 실제로 있기 때문이다. 마이그레이션 이후에도 튜닝 인력을 붙이지 않으면 과다 프로비저닝 상태가 그대로 유지되거나, 오히려 클러스터 관리 오버헤드만 더해진다. HPA(Horizontal Pod Autoscaler)나 VPA(Vertical Pod Autoscaler) 같은 자동화 도구도 결국 requests 기준값과 메트릭 수집 파이프라인이 정확히 세팅돼 있어야 제 역할을 한다.

그래서 언제 쓰고 언제 피해야 하나?

서비스 수가 적고 배포 패턴이 단순하며 트래픽 변동이 작다면, 쿠버네티스의 리소스 관리 기능보다 단순 컨테이너 런타임이나 매니지드 플랫폼이 더 실용적일 수 있다. 2026년 공개된 한 비교 자료는 20개 미만 컨테이너 규모에서 Docker Compose 방식이 관리 명령·설정 라인 수 기준으로 약 60% 더 단순했다고 정리했다. 다만 이 수치는 2차 출처라 참고 수준으로만 봐야 한다.

반대로 같은 자료는 서비스 규모가 20개 이상으로 커지면 쿠버네티스가 거래당 컴퓨트 비용을 약 23% 절감할 수 있다고도 서술한다. 단, 이 이득에는 "운영 오버헤드를 흡수할 충분한 규모와 인력"이라는 전제가 붙는다. 반대로 작은 팀·적은 서비스·낮은 트래픽 변동성 조건에서는 TCO가 15~30% 늘어날 수 있다는 지적도 함께 있다. 매니지드 플랫폼은 이 중간 지점을 채우는 선택지다. 오토스케일링·롤링 배포·헬스체크 정도는 필요하지만 클러스터 자체를 직접 운영할 여력은 없을 때 고려할 만하다.

결국 무엇으로 판단이 갈리나?

• requests/limits는 스케줄링과 QoS, OOM Kill 우선순위를 결정하는 정책 도구이지 자동 최적화 장치가 아니다.
• 워크로드 저활용(65%↑)과 과다 프로비저닝(82%↑) 데이터는 쿠버네티스 도입 이후에도 rightsizing이 별도 과제로 남는다는 걸 보여준다.
• 클러스터·환경 수가 늘수록(평균 20개 이상, 절반이 4개 이상 환경) 설정 오차가 누적되고 장애 추적 시간(MTTD 약 40분, MTTR 50분↑)이 늘어난다.
• 서비스 수가 적고 트래픽이 안정적이며 운영 인력이 제한적이면 단순 런타임이나 매니지드 플랫폼 쪽이 실이득에서 유리할 가능성이 크다.
• 반대로 서비스 수가 많고 변동성이 크며 튜닝을 지속할 인력이 있다면 쿠버네티스의 정교한 리소스 통제가 그만큼의 값을 한다.

2026년 기준으로 봐도 이 판단 축은 크게 바뀌지 않았다. 쿠버네티스 자체의 기능은 계속 정교해지고 있지만, 그 정교함을 쓸지 말지는 여전히 서비스 수·트래픽 변동성·운영 인력이라는 세 축으로 갈린다.

핵심 정리

• requests/limits는 스케줄링과 QoS 우선순위를 정하는 정책 도구일 뿐, 자동 최적화 기능이 아니다.
• 쿠버네티스 도입 조직도 워크로드의 65% 이상이 저활용, 82% 이상이 과다 프로비저닝 상태로 나타난다(2025년 Komodor 리포트).
• 클러스터·환경 수가 늘수록 설정 오차가 누적되고, 장애 시 MTTD 약 40분·MTTR 50분 이상이 걸릴 수 있다.
• 서비스 20개 미만·트래픽 안정적·운영 인력 제한적이면 단순 런타임/매니지드 플랫폼이, 그 반대 조건이면 쿠버네티스가 실이득에서 유리하다.
• 판단 기준은 "쿠버네티스가 우수한가"가 아니라 "이 정교함을 지속적으로 튜닝할 여력이 있는가"다.