🥇[Bro's Insights - 인기글] → ⚠️오케스트레이션의 기본, Kubernetes 가 흔들린다

[cloudbro-radar]

2014년, Google이 Kubernetes를 오픈소스로 공개했을 때 세상은 완전히 달라졌다.
배포는 반복 가능해졌고, 확장은 탄력적으로 이루어졌으며, 우리는 ‘클라우드 네이티브’라는 새로운 언어를 손에 넣었다.

하지만 10년이 지난 지금, Mountain View 내부에서는 전혀 다른 분위기가 감지되고 있다.
최근 Google 내부 SRE Slack 그룹에서 유출된 슬라이드에 담긴 메시지는 단순하고도 직설적이었다.

“Kubernetes는 우리에게 절감 효과보다 더 많은 비용을 발생시키고 있다.”

Google은 Kubernetes를 부정하는 것이 아니라, 그것이 여전히 합리적인 선택인지 근본적으로 재검토하고 있다.
실제로 Borg 후속 경량 런타임을 사용하는 팀과 일반 K8s 클러스터를 운영하는 팀의 지표를 비교한 결과는 충격적이다.

• 비-K8s 팀의 인프라 비용이 평균 40% 절감
• YAML 의사결정 과정을 제거했을 때 배포 속도가 2배 향상
• 네트워킹 및 사이드카 관련 에스컬레이션 80% 감소

이런 변화는 단순한 운영 효율성의 문제가 아니라, Kubernetes라는 패러다임 자체가 다시 점검되고 있다는 신호다.

---

Kubernetes가 무겁게 느껴지는 이유는 명확하다.
처음부터 Google 규모의 문제를 해결하기 위해 설계됐기 때문이다.
하지만 지금 대부분의 Google 팀은 그런 수준의 문제를 더 이상 가지고 있지 않다.

피드백에서 반복적으로 등장하는 세 가지 불만이 이를 증명한다.

1. YAML 오버헤드 – 선언적 구성의 이상은 CRD, Helm, 템플릿 스파게티로 변질됐다. 기능 개발보다 헬름 디버깅에 더 많은 시간이 쓰인다.
2. 네트워킹의 복잡성 – 사이드카, 서비스 메시, 인그레스 컨트롤러가 얽히며 DNS 문제는 밈이 됐다.
3. 확장의 환상 – 무한 확장은 대부분의 팀에게 필요하지 않으며, K8s 운영비가 그 이점을 삼킨다.

---

Google 내부의 일부 팀은 더 단순한 방식으로 전환하고 있다.
200줄짜리 매니페스트도, 복잡한 Helm 차트도 없이 다음과 같은 간결한 선언만으로 서비스를 정의한다.

CREATE SERVICE payments
  IMAGE 'gcr.io/team/payments:v3'
  SCALE RULES (
    IF latency > 300ms THEN ADD 2 INSTANCES,
    IF errors > 1% THEN ALERT 'pagerduty'
  );

운영 복잡도가 줄어들고, 네트워킹 이슈가 사라지며, 비용과 속도 모두 개선됐다.
이는 단순히 내부 실험이 아니라, 오케스트레이션 방식 자체를 재설계하고 있다는 신호다.

---

이 변화가 외부 기업들에게 주는 메시지는 명확하다.
Kubernetes는 여전히 강력한 플랫폼이지만, 절대적인 존재는 아니다.
그동안 실제 문제를 해결하는 동시에, 또 다른 문제군—복잡성, 운영 오버헤드, 팀 속도의 저하—을 만들어냈다.

이제 모든 팀은 스스로에게 이런 질문을 던질 필요가 있다.

• 우리는 K8s가 진짜로 필요해서 쓰는가, 아니면 그냥 ‘기본값’이라서 쓰는가?
• 무한 확장이 정말 필요한가? 아니면 오버헤드가 우리를 조용히 갉아먹고 있는가?
• 더 단순한 스택으로 돌아간다면 제품 개발에 더 집중할 수 있지 않을까?

기술은 순환한다. 어제의 정답이 내일의 장애물이 될 수 있다.
Kubernetes의 집을 지은 Google이 방향을 바꾸고 있다면, 우리도 멈춰서 다시 생각해봐야 한다.

K8s는 위대한 도구지만, 언제나 ‘올바른 도구’는 아니다.
그리고 바로 지금, 그 질문을 던질 시점이 왔다.

[출처] https://medium.com/aws-in-plain-english/why-even-google-is-rethinking-kubernetes-internally-a4c457252450

[SeokhoSon]

안녕하세요. CNCF Ambassador 및 Kubernetes 컨트리뷰터로 활동하고 있는 손석호입니다. 역할과는 별개로, 이번 글을 읽고 여러 생각이 들어 처음으로 댓글을 남겨봅니다.

쿠버네티스, 클라우드 네이티브, 컨테이너 기반 워크로드가 여전히 유용하고 효율적인지 다양한 측면에서 고민하고 되돌아보는 일은 언제나 필요하다고 생각합니다.
다만, 이번 글처럼 다소 극단적인 메시지는 그 내용을 그대로 받아들이기에는 위험이 따릅니다.
특히 원문을 번역하거나 요약하는 과정에서 의도와 맥락이 왜곡되는 경우가 많기에 더욱 주의가 필요합니다.

제가 원문에 대해 신중한 입장을 가지는 이유는 다음과 같습니다.

1. 근거 부족과 검증 불가능한 정보에 대한 의존
   구글의 내부 이야기를 언급하고 있으나, 실제 사실 여부를 확인할 수 있는 근거가 없습니다.
   확인되지 않은 정보를 기반으로 논리를 전개하는 것은 비약으로 이어질 가능성이 높습니다. (저는 이 글에서 언급된 ‘구글 내부 슬랙 자료’를 직접 확인한 적이 없습니다.)
2. 균형 없는 시각
   쿠버네티스의 장점이나 맥락은 다루지 않고, 단편적인 문제점에만 초점을 맞춘 점이 아쉽습니다.
3. 비교의 타당성 부족
   설령 해당 내용이 실제 구글 내부의 의견이라 하더라도, 비교 대상이 쿠버네티스의 모체인 구글 내부 Borg의 후속이라면 ‘쿠버네티스가 무의미하다’는 결론으로 단정하는 것은 바람직하지 않습니다.

그럼에도 불구하고, 이 글은 우리 모두가 ‘클라우드 네이티브 인프라가 과연 최선인가?’, ‘불필요한 복잡성이 존재하지는 않는가?’를 다시금 되돌아보게 만든다는 점에서 의미가 있습니다.

요즘은 정보가 넘쳐나는 시대입니다.
경험이 많지 않은 분들은 자극적인 글에 쉽게 영향을 받아 잘못된 판단을 내릴 수도 있습니다.
그런 측면에서, 이 글이 충분한 검증과 논의 없이 다른 곳으로 확산되는 일은 바람직하지 않다고 생각합니다. 적어도 본 커뮤니티 내에서 시실 확인 및 충분한 공감대(컨센서스)가 형성되기 전까지는요.

건전한 커뮤니티가 되기 위해서는,
사실에 근거하고 경험을 바탕으로 한 양질의 글이 공유되어야 하며,
그 위에서 서로의 의견을 존중하면서도 비판적이고 생산적인 논의가 이루어져야 한다고 생각합니다.
그것이 진정으로 커뮤니티 구성원 모두에게 도움이 되는 방향이라 믿습니다. 모두 건승하기실 바랍니다!

[jerry (이제응)]

@SeokhoSon 손박사님! 역시 Insight 글 감사합니다. ^^

[Eleanor (이서연)]

균형잡힌 시각은 물론 커뮤니티 내 중심을 잡을 수 있는 방향성까지 제시해주셔서 감사합니다