취업 면접이 Kubernetes에 대해 알려준 것

• Kubernetes는 소규모 회사에서도 기술적 확장성보다 배포 방식 통일과 조직 운영 문제를 해결하는 기준으로 채택되고 있음
• 최근 구직 과정에서 대화한 회사들은 모두 Kubernetes를 쓰고 있었고, 5년 전의 VM·serverless·K8s 병존 구도와 달랐음
• CTO들이 꼽은 핵심 이유는 서비스마다 같은 방식으로 배포하고, YAML과 Helm 차트에 운영 지식을 남기며, GitOps로 변경 이력을 추적할 수 있다는 점이었음
• 작은 회사들은 HPA, Pod Disruption Budget, 노드 어피니티 같은 고급 기능보다 조직적 이점 때문에 복잡한 Kubernetes를 감수하고 있음
• 초기 회사는 제품에 집중하기 위해 Kubernetes 없이 시작하는 편이 낫고, CTO 혼자 엔지니어링을 맡지 않게 되는 시점부터 도입 필요성이 커짐

최근 구직에서 보인 변화

• 최근 구직 과정에서 채용 공고를 읽고 면접을 보고 약 열두 곳의 엔지니어링 팀과 대화한 결과, 대화한 모든 회사가 Kubernetes를 쓰고 있었음
• 5년 전 구직 때는 Kubernetes를 드물게 쓰는 그룹, VM/VPS/EC2 위에서 systemd를 쓰는 그룹, Lambda와 Cloud Run 같은 serverless 그룹이 함께 존재했음
• 현재 일하는 곳은 Big Tech 규모의 문제가 있어 Kubernetes가 명확히 맞지만, 두 개 서비스만 가진 10명 규모 스타트업까지 Kubernetes를 쓰는 점이 놀라웠음
• 대화한 회사들은 마이크로서비스를 운영하거나 높은 규모에 가까운 환경이 아니었고, Kubernetes의 기술적 측면에는 큰 관심이 없었음

Kubernetes 채택 이유와 판단 기준

• 왜 Kubernetes를 쓰는가

  • 첫 번째 이유는 uniformity였고, 모든 서비스가 같은 방식으로 배포되면 특정 서비스만 오래된 베어 VM의 bash 스크립트나 Docker Compose에 묶이는 상황이 사라짐
  • 두 번째 이유는 공유 가능하고 채용 가능한 지식이었고, Kubernetes가 공통 언어처럼 쓰이면서 Helm 차트와 Kube 설정만 봐도 아키텍처를 빠르게 파악할 수 있음
  • 지식이 사람의 머릿속이 아니라 YAML에 남아 있으면, 누군가 떠난 뒤 후임자가 실행 방식을 파악하느라 몇 주를 쓰는 일이 줄어듦
  • 현재 회사의 온콜 SRE는 처음 보는 서비스도 Kubernetes 패턴이 팀마다 같기 때문에 유지할 수 있음
  • 이 장점은 설정이 지나치게 특이하지 않을 때만 성립함
  • 세 번째 이유는 추적 가능성이었고, 클러스터에 직접 kubectl apply -f를 실행하지 않고 Helm 차트를 git에 올린 뒤 MR 승인과 FluxCD 또는 ArgoCD 배포를 거치면 변경 이력이 남음
  • 이런 흐름은 GitOps와 Kubernetes가 자연스럽게 맞물리기 때문에 거의 추가 비용 없이 컴플라이언스에 도움이 됨
  • 현재 회사는 이 방식으로 ISO 인증을 잘 통과하고 있음

• 얻은 결론

  • CTO들의 선택은 어리석은 선택이 아니라 실제 문제를 해결하는 방식이었음
  • Kubernetes는 기술적 문제를 위한 기술적 해법으로 보였지만, 많은 CTO들은 예상보다 비기술적 이점에 더 관심이 있었음
  • 작은 회사들의 기술적 문제는 Kubernetes가 꼭 필요할 정도가 아니며, 매니페스트에 topologySpreadConstraints, HPA, Pod Disruption Budget, 노드 어피니티 규칙이 없을 가능성이 큼
  • 이들은 VM을 썼을 때와 비슷한 수의 노드를 유지하면서도, 조직적 이점을 위해 복잡한 소프트웨어 운영 비용을 받아들이고 있음

• 왜 최근에 전환이 일어났는가

  • 5년 전에는 VM과 systemd, serverless, Kubernetes가 모두 선택지로 남아 있었지만, 지금 채용 공고에서는 VM과 systemd 조합이 거의 사라졌고 serverless는 틈새에 머물렀으며 Kubernetes가 이겼음
  • 전환 시점의 이유는 완전히 확실하지 않음
  • 가능한 이유는 EKS, GKE, AKS 같은 관리형 Kubernetes가 성숙했고, Kubernetes를 배운 사람이 충분히 늘어 다른 방식을 채용하는 편이 더 어려워졌다는 점임
  • Helm은 다른 사람이 만든 차트를 그대로 쓰는 선택지를 현실적인 옵션으로 만들었음

• 언제 Kubernetes를 쓸 것인가

  • 개인적 기준은 CTO가 더 이상 유일한 엔지니어가 아닌 순간임
  • 두 번째 엔지니어가 합류하면 서버를 직접 세팅하지 않은 사람이 배포해야 하고, 모든 것에 SSH 키를 주는 방식이 아니라 적절한 접근 제어가 필요해짐
  • 결국 누군가는 회사를 떠나고, 사람이 가진 운영 지식도 함께 빠져나갈 수 있음
  • 이 시점부터 지식은 사람보다 시스템 안에 남아 있어야 함
  • 그전 단계에서는 클러스터 디버깅이 실제로 어렵고, 제품에 써야 할 에너지를 인프라에 쓰게 될 수 있음
  • 큰 고객과 통화하기 직전 CrashLoopBackOff에 걸린 pod 원인을 두 시간 동안 찾는 상황보다, VPS에서 급하게 git pull로 고치는 방식이 빠르고 이해 가능한 비상 대응일 수 있음