Kubernetes

규모가 커지면 문제는 ‘클러스터를 띄우는 것’에서 ‘수백~수천 개 클러스터를 사람 손 없이 유지하는 것’으로 바뀝니다.

쿠버네티스 프로덕션 사용은 이미 다수파가 됐습니다. CNCF 연례 조사에서 컨테이너 사용 조직의 프로덕션 쿠버네티스 사용률은 2024년 80%였고(CNCF Annual Survey 2024), 2025년 조사에서는 82%까지 올랐습니다(CNCF, 2026-01-20). 도입 자체는 더 이상 모험이 아니라는 뜻입니다.

그런데 규모가 커지면 과제의 성격이 달라집니다. 클러스터 1개를 운영할 때의 고민(설치, 배포, 모니터링)과 클러스터 수백 개를 운영할 때의 고민은 종류가 다릅니다. 대규모 사례들이 공통으로 마주친 벽은 대략 이렇습니다.

• 클러스터 수명주기 관리 — 생성·업그레이드·패치·폐기를 클러스터마다 손으로 하면 운영 인력이 규모에 비례해 늘어야 합니다.
• 네트워크 병목과 장애 추적 — 노드가 수만 대가 되면 트래픽 분배 구조 자체가 병목이 되고, 장애 원인 추적 범위가 폭발합니다.
• 배포 파이프라인의 확장 — 서비스 수천 개의 배포를 중앙 한 곳이 감당하면 그 중앙이 단일 병목이자 단일 장애점이 됩니다.
• 표준화와 자율성의 균형 — 팀마다 다른 구성을 허용하면 운영이 불가능해지고, 전부 틀에 가두면 개발 속도가 죽습니다.

아래 세 사례는 이 과제들을 각기 다른 각도에서 풀어낸 기록입니다. 공개된 쿠버네티스 도입 사례를 읽을 때는 규모 수치보다 어떤 문제를 만나 무엇을 바꿨는가를 따라가는 편이 유용합니다. 프로덕션 운영에서 드러난 병목과 그 해결책은 규모가 달라도 구조가 같은 경우가 많기 때문입니다.

카카오는 온프레미스에서 7,000개 이상의 클러스터와 12만 대 이상의 노드를 운영하며, 네트워크 계층을 eBPF 기반 Cilium으로 통일해 성능과 디버깅 단순성을 확보했습니다.

카카오의 규모는 국내 쿠버네티스 사례 중 단연 압도적입니다. 온프레미스 환경에서 7,000개 이상의 클러스터, 12만 대 이상의 노드를 여러 존(zone)에 분산해 운영합니다(카카오 쿠버네티스 구축 사례).

주목할 부분은 네트워크 계층의 의사결정입니다. 초기 구성은 kube-proxy와 Cilium, Nginx Ingress가 섞여 있었고, 장애가 나면 세 구성 요소를 동시에 분석해야 해서 원인 추적이 어려웠습니다. 카카오는 데이터패스를 eBPF 기반 Cilium으로 통일하는 쪽을 택했습니다. iptables의 선형 규칙 탐색 대신 해시맵 기반 조회로 규모 한계를 걷어 내고, 분석 대상을 한 구성 요소로 줄여 디버깅을 단순화했으며, 활발한 커뮤니티 패치로 안정성을 챙겼다는 것이 공개된 요지입니다.

이 쿠버네티스 도입 사례의 교훈은 명확합니다. 대규모에서는 개별 도구의 벤치마크 수치보다 “장애가 났을 때 몇 개의 구성 요소를 들여다봐야 하는가” 가 총 운영 비용을 좌우한다는 점입니다. 네트워크 계층의 기술적 배경은 쿠버네티스 네트워킹과 CNI 이해하기에서 자세히 다룹니다.

LY는 쿠버네티스를 애플리케이션 배포 도구가 아니라 ‘인프라 전체를 관리하는 제어 계층’으로 재정의해, 15명이 1,300개 클러스터를 운영합니다.

일본 LY Corporation(LINE과 Yahoo! JAPAN의 통합 법인)의 수치는 “자동화가 인력을 대체한다”는 말의 실물 증거입니다. 클러스터 1,300개, 노드 4만여 대, 파드 9만여 개, 600여 개 프로젝트에서 하루 약 3,000회의 릴리스가 일어나는 인프라를 운영 인력 15명이 담당합니다(LY 대규모 운영 사례).

비결은 쿠버네티스의 쓰임새를 뒤집은 데 있습니다. LY는 쿠버네티스를 애플리케이션 오케스트레이터로만 쓰지 않고, 인프라 자체를 관리하는 제어 계층으로 재정의했습니다. 커스텀 리소스(CRD)와 커스텀 컨트롤러로 “클러스터가 이런 상태여야 한다”를 선언해 두면, 컨트롤러가 실제 상태와의 차이를 스스로 좁히며 프로비저닝·복구·패치를 수행합니다. 쿠버네티스가 파드에 적용하는 선언형 조정 원리를 클러스터 함대 전체로 확장한 셈입니다.

공개된 교훈 중 곱씹을 대목은 관측성(observability, 시스템 내부 상태를 지표·로그로 들여다볼 수 있는 능력)의 순서입니다. 관측성 없는 자동화는 통제 불능이 될 수 있으므로, 자동 조치를 넓히기 전에 지표 수집과 경보 규칙부터 정비해야 한다는 것입니다. 자동화의 속도는 관측성의 깊이를 넘을 수 없다는 원칙입니다. 운영 자동화를 넓히는 순서 자체가 이 쿠버네티스 도입 사례의 핵심 자산인 셈입니다.

Adobe는 단일 허브 클러스터의 병목을 셀 기반 아키텍처(FiaB)로 풀어, 360개 이상 클러스터에서 월 3만 건 이상의 배포를 굴립니다.

Adobe의 사례는 배포 파이프라인의 확장 문제를 정면으로 다룹니다. Adobe 내부 플랫폼은 360개 이상의 원격 쿠버네티스 클러스터를 지원하며, Argo CD 애플리케이션 2만 2,000개 이상, 월 3만 건 이상의 배포, 1,000개 이상의 프로덕션 마이크로서비스를 처리합니다(Adobe GitOps 플랫폼 확장 전략).

초기 구조의 문제는 모든 배포를 관장하는 단일 허브 클러스터가 병목이자 단일 장애점이 된다는 것이었습니다. Adobe의 해법은 FiaB(Flex-in-a-Box) 라 부르는 셀 기반 아키텍처입니다. 배포 플랫폼 자체를 ‘플렉스박스’라는 독립 셀 단위로 쪼개고, 세 가지 원칙 — 선언 기반으로 새 셀을 자동 재생성(Recreation)하고, 요청을 적절한 셀로 보내는 리다이렉션(Redirection), 서비스를 무중단에 가깝게 다른 셀로 옮기는 재배치(Relocation) — 으로 수평 확장이 가능한 구조를 만들었습니다. 셀 하나에 문제가 생겨도 영향 범위(blast radius)가 그 셀 안에 갇힙니다.

이 쿠버네티스 도입 사례에서 얻는 교훈은 애플리케이션만 확장 가능해서는 부족하다는 점입니다. 배포·운영 플랫폼 그 자체도 확장 가능하게 설계해야 규모를 감당할 수 있습니다.

대규모 사례들의 공통분모는 선언형 자동화, 관측성 우선, 표준화, 영향 범위 격리로 수렴합니다.

배경도 규모도 다른 세 조직의 쿠버네티스 도입 사례를 겹쳐 보면, 다음 일곱 가지 원칙이 반복해서 나타납니다.

1. 사람이 아니라 컨트롤러가 반복 작업을 한다 — LY의 15명 운영은 선언형 컨트롤러가 프로비저닝·복구를 대신하기에 가능합니다.
2. 관측성이 자동화보다 먼저다 — 지표와 경보가 없으면 자동 조치는 통제 불능의 지름길이 됩니다(LY).
3. 장애 분석 대상을 줄이는 방향으로 스택을 통일한다 — 카카오가 데이터패스를 Cilium으로 모은 이유입니다.
4. 영향 범위를 구조적으로 격리한다 — Adobe의 셀 기반 설계처럼, 하나의 실패가 전체로 번지지 않게 만듭니다.
5. 플랫폼 자체의 확장성을 설계한다 — 애플리케이션이 아니라 배포·운영 플랫폼이 병목이 되는 시점을 대비합니다(Adobe).
6. 표준 템플릿으로 클러스터를 찍어 낸다 — 클러스터가 저마다 다르면 수천 개 운영은 불가능합니다(카카오·LY 공통).
7. 커뮤니티가 살아 있는 오픈소스를 고른다 — 규모에서 만나는 버그는 커뮤니티 패치 속도가 곧 안정성입니다(카카오). 상용 제품을 쓴다면 같은 질문을 벤더의 패치 대응 속도로 바꿔 던져야 합니다.

수치를 부러워할 것이 아니라, 이 원칙들이 클러스터 몇 개 규모에서도 그대로 통한다는 점을 가져와야 합니다.

“우리는 카카오 규모가 아니다”라는 반응이 자연스럽지만, 시사점은 규모가 아니라 원칙에 있습니다. 클러스터가 3개든 300개든, 수작업 운영은 클러스터 수에 비례해 인력을 요구하고, 관측성 없는 자동화는 규모와 무관하게 사고를 냅니다. 오히려 규모가 작을 때 표준 템플릿·선언형 관리·관측성 기반을 갖춰 두면, 성장 곡선에서 운영 인력이 같이 늘지 않는 구조를 미리 확보하는 셈입니다. 국내 조직이 참고할 쿠버네티스 도입 사례를 고를 때도 같은 기준이 적용됩니다. 우리와 규모가 비슷한 곳을 찾기보다, 지금 우리가 겪는 문제를 이미 통과한 곳의 프로덕션 운영 기록을 읽는 편이 빠릅니다.

또 하나의 시사점은 검증의 순서입니다. 세 사례 모두 전면 전환이 아니라 특정 문제(네트워크 병목, 클러스터 수명주기, 배포 확장)를 겨냥한 단계적 개선의 축적입니다. 카카오도 처음부터 Cilium 단일 구성이 아니었고, Adobe도 단일 허브의 병목을 겪은 뒤에 셀 구조로 옮겼습니다. 완성형을 처음부터 그리기보다, 지금 가장 아픈 문제 하나를 골라 쿠버네티스 도입 사례가 검증한 방식으로 풀고 다음으로 나아가는 접근이 실제 대규모 조직들의 이행 경로였습니다.

세 사례가 공통으로 보여 준 또 하나는 측정의 우선순위입니다. 카카오는 장애 시 들여다볼 구성 요소의 개수를, LY는 운영 인력 대비 클러스터 수를, Adobe는 배포 실패의 영향 범위를 각각 관리 지표로 삼았습니다. 무엇을 줄이려는지가 분명해야 자동화의 목표도 분명해진다는 뜻입니다. 도입 초기에 이 지표 하나를 정해 두면 이후 투자 판단이 훨씬 쉬워집니다.

도입을 검토하는 조직이라면 첫 실습 환경 구축(쿠버네티스 설치 가이드)에서 시작해, 조직 차원의 판단 기준과 로드맵(쿠버네티스 도입 전략)으로 나아가는 경로를 권합니다. 실증 사례가 이미 증명한 길을 굳이 처음부터 다시 개척할 필요는 없습니다. 세 조직 모두 공개 발표와 기술 블로그로 시행착오까지 남겨 두었기 때문에, 같은 벽을 만나기 전에 미리 읽어 두는 것만으로도 설계 판단의 폭이 달라집니다.

쿠버네티스를 프로덕션에서 쓰는 조직은 얼마나 되나요?

CNCF 연례 조사 기준 컨테이너 사용 조직의 프로덕션 쿠버네티스 사용률은 2024년 80%, 2025년 82%입니다(CNCF Annual Survey). 검토·시범 단계까지 합치면 90%를 넘어, 이미 업계 표준 단계에 들어섰습니다. 다시 말해 도입 여부를 묻는 단계는 지났고, 질문은 ‘어떤 규모에서 무엇을 조심해야 하는가’로 옮겨 갔습니다. 아래 사례들이 답하는 것이 바로 그 질문입니다.

국내에도 대규모 쿠버네티스 운영 사례가 있나요?

카카오가 대표적입니다. 온프레미스에서 7,000개 이상의 클러스터, 12만 대 이상의 노드를 운영하며, 네트워크 계층은 eBPF 기반 Cilium으로 통일했습니다(카카오 사례).

대규모 클러스터 운영에 인력이 얼마나 필요한가요?

자동화 수준이 좌우합니다. LY Corporation은 선언형 컨트롤러 기반 자동화로 1,300개 클러스터·4만 노드를 15명이 운영합니다(LY 사례). 수작업 중심이라면 같은 규모에 훨씬 많은 인력이 필요합니다.

작은 조직도 쿠버네티스 도입 사례의 원칙을 적용할 수 있나요?

적용할 수 있고, 오히려 작을 때 시작하는 편이 유리합니다. 표준 템플릿, 선언형 관리, 관측성 우선, 영향 범위 격리는 클러스터 몇 개 규모에서도 그대로 통하는 원칙이며, 미리 갖춰 두면 규모가 커져도 운영 인력이 비례해 늘지 않습니다.

대규모 운영에서 가장 먼저 투자할 영역은 어디인가요?

사례들의 공통 답은 관측성입니다. 지표 수집과 경보 체계가 없으면 자동화를 넓힐수록 위험이 커집니다. 관측성 기반을 갖춘 뒤 클러스터 수명주기 자동화, 배포 파이프라인 확장 순서로 투자하는 흐름이 세 쿠버네티스 도입 사례에서 반복됩니다. 운영 자동화를 먼저 넓히고 관측을 나중에 붙이는 역순은 사례들이 공통으로 경계한 실패 경로입니다.

• 카카오 쿠버네티스 구축 사례 — 온프레미스 7,000개 클러스터
• LY Corporation — 15명이 운영하는 4만 노드·1,300개 클러스터
• Adobe — 360개 클러스터를 지원하는 배포 플랫폼 확장 전략
• CNCF Annual Survey 2024
• CNCF 2025 조사 발표 — 프로덕션 사용률 82%
• 쿠버네티스란 무엇인가 — 필러 가이드
• 쿠버네티스 아키텍처 완전 해부
• 쿠버네티스 도입 전략 — 로드맵과 TCO
• 쿠버네티스 네트워킹과 CNI 이해하기
• 쿠버네티스 도입 전략 — 조직 관점의 채택 로드맵

더 깊이 들어가려면

대규모 쿠버네티스 운영 사례를 더 찾아보고 싶다면 아래 경로로 이어가 보세요.

• GitHub repo 방문 — kubernetes/kubernetes 에서 사례 속 기능들의 소스와 릴리스 노트를 확인하세요.
• CNCF 사례 연구 아카이브 — cncf.io/case-studies 에서 전 세계 프로덕션 도입 사례를 확인하세요.
• CNCF Slack 참여 — slack.cncf.io 에서 대규모 운영 경험을 가진 전 세계 실무자와 토론할 수 있습니다.
• CNCF Landscape 확인 — landscape.cncf.io 에서 사례에 등장한 프로젝트들의 생태계 위치를 살펴보세요.