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

 (notnotp.com)
14P by GN⁺ | ★ favorite | 댓글 1개
  • 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로 고치는 방식이 빠르고 이해 가능한 비상 대응일 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 유럽 쪽에서는 이유가 분명함. CTO들은 K8s 위에 올리면 관리형 K8s 제공업체를 몇 주 안에 바꿀 수 있다고 믿음
    그게 맞다는 뜻은 아니지만, 실제로 그렇게 믿고 있음. PR 환경도 더 쉬워진다고 생각함
    하지만 핵심은 제공업체 전환임. 앞으로 몇 년 안에 미국과 연결된 제공업체 사용 금지가 생길 것으로 예상하고 있고, 특히 GDPR, 금융 시스템 등에서 그럴 가능성이 큼. 그래서 그 위험에 대비해 둔 것임

  • 회사 규모와 상관없이 기술 업계가 완전히 방향을 잃었다는 증거처럼 보임. 스택은 점점 더 획일적이고 복잡해졌는데, 결과적으로 이를 악물지 않고 쓸 수 있는 제품과 서비스를 찾기가 더 어려워지고 있음

    • 저수준 계층이 너무 버그가 많고 복잡해서, 살아남으려면 결국 Kubernetes 같은 것을 만들 수밖에 없는 면이 있음. 스택이 더 높아지는 걸 막고 싶다면 아래 계층을 더 좋게 만들어야 함
      훨씬 나은 운영체제 기본 요소가 필요함. 예를 들어 컨테이너는 일관된 설계 없이 커널의 여러 격리 기능을 뒤섞은 것이라 구멍이 많았음
      지금은 컨테이너 격리가 많이 나아졌지만, 처음부터 보안과 정상성을 설계한 게 아니라 두더지 잡기식으로 고친 결과임. 커널이 거대한 기술 부채를 처리하거나, 누군가 옮길 만한 커널을 만들기 전까지는 계속 그 위에 뭔가를 쌓게 될 것임

  • 충분히 복잡한 배포 도구는 결국 임시방편으로 만들고, 비공식적으로 정의되고, 버그가 많고, 느린 Kubernetes 절반짜리 구현을 포함하게 됨

    • “절반”이라는 표현은 맞음. 다만 그 절반이 하필 필요한 절반일 뿐임
      2009년에 10억 달러 규모 SaaS 전자상거래 회사를 어떻게 구성했는지, 초대형 AAA 멀티플레이어 게임의 온라인 백엔드가 어떻게 돌아갔는지 길게 말할 수 있는데, 그것들은 단일 머신 배포보다는 확실히 Kubernetes에 가까웠음
      하지만 더 빨랐고, 조직이 정확히 필요로 하는 방식으로 의견이 강했지, 제품 요구사항과 충돌하는 방식은 아니었음
      Kubernetes의 “버그 많음”은 핵심 시스템 자체라기보다, 우리가 원하는 대로 동작하게 하려고 그 위에 얹는 수많은 인터페이스 계층에서 나오는 경우가 많음
    • 이건 Kubernetes가 아니라 Erlang에 해당하는 얘기임. Kubernetes에는 전혀 말이 안 됨

  • 문제는 대부분의 조직이 K8s를 어설프게 도입하고, 이를 관리하는 DevOps 팀까지 두면서도 결국 소프트웨어 엔지니어에게 K8s 관련 작성, 배포, 디버깅, 운영을 다 떠넘긴다는 데 있음
    좋은 DevOps 팀이라면 내부적으로 Heroku 같은 경험을 제공해야 함. 필요한 리소스를 정의하고 main에 병합하면 배포가 이뤄져야지, 형편없는 GitOps/DevOps 대시보드에서 뭐가 잘못됐는지 헤매면 안 됨
    Heroku가 개발자 경험의 정점이었고, K8s 이후로 그걸 잃어버렸다고 봄

    • Pod가 노드에서 실행되는 걸 본다는 점 말고, Heroku와 Kubernetes 사용 경험의 큰 차이가 뭔지 모르겠음
      물론 Heroku는 데이터베이스 연동이나 git push 배포까지 더 통합된 경험을 주지만, Kubernetes 위에 맞춤형 외피를 만드는 건 별로임. 결국 모든 매개변수를 그대로 통과시키게 됨

  • 업계에서 기술 채택은 언제나 “기성복처럼 뽑고, 필요 없으면 해고” 원칙으로 움직임. 이것도 그 최신 사례 중 하나임

  • “지식은 사람이 아니라 시스템이 갖고 있어야 한다”는 문장이, 막연히 생각만 하던 걸 아주 잘 표현해 줌
    이런 형식화는 프로세스의 변동성이 줄어들 때만 가능함. 사람이 직접 하고, 프로세스를 문서화하고, 스크립트로 만들고, 그다음 자동화하는 식임
    인기 있는 도구나 생태계의 흔한 워크플로에서는 이 단계 대부분을 거의 공짜로 얻을 수 있음

  • DevOps를 많이 하지는 않고, 지금은 systemd와 가끔 쓰는 podman 컨테이너만으로도 시스템이 잘 돌아감. IoT/AgTech 쪽에서 일함
    이 글에는 비기술 경영진에게서 자주 듣는 식의 “주장”이 있음. 대략 “저쪽도 LoRa 하죠? 그럼 됐네요? 내일 출시할 수 있죠?” 같은 식임
    비균일성만이 성공의 유일한 장애물이라는 믿음이 있음. 두 시스템이 Fiber, Modbus를 쓰거나 “API가 있다”면 곧바로 연결해서 “1 + 1이 합보다 커지는” 멋진 경험을 만들 수 있다고 여김
    하지만 두 소프트웨어가 낮은 수준의 상호운용 표준에 합의했다고 해서, 쉽게 파싱되는 데이터를 어떻게 해석하고 유용하게 쓸지 결정하는 실제 작업이 사라지는 건 아님
    두 사람이 같은 언어를 할 수 있다고 해서 할 일이 없어지는 건 아님. 공통 언어를 쓴다고 해서, 팀 일부가 그 도구를 쓰며 당시 알고 있던 조건에서 내린 결정들이 사라지지도 않음
    초창기에는 과학/공학계에서 Fortran이 공용어였지만, 그렇다고 동료들이 한 일에 완전히 당황하거나 다시 작성하는 일이 없어지진 않았음
    K8s의 가치나 현재 “표준”으로 자리 잡은 점에는 불만이 없음. 다만 그것이 어떤 종류의 프로그래밍 문제가 사라진다는 주장에는 동의하기 어려움. 추함 보존 법칙은 여전히 남아 있음

  • Kubernetes는 괜찮은 배포 플랫폼임

  • 배포 형태도 또 다른 이유임. Canton 노드 작업을 하는데, 상류 Canton 소프트웨어와 관련 앱은 Helm 차트로 제공됨
    Kubernetes가 우리 작업에 적합한지와는 별개로, 나는 아니라고 보지만, 소프트웨어가 그렇게 배포되고 지원됨. 그 경로를 벗어나면 Kubernetes를 다루는 것보다 일이 더 많아짐

  • 이 글이 너무 AI가 쓴 것처럼 들리는 건 나뿐인지 모르겠음
    그래도 취지에는 동의함. 홈랩/셀프호스팅 구성들을 맞춤 systemd 설정, 기억 안 나는 셸 명령들, “젠장 그 설정 절차를 어느 Markdown 파일에 적어뒀지?” 같은 상태에서 옮기는 중인데 정말 상쾌함
    아직 진짜 지속적 배포 시스템을 쓰는 건 아니지만, 작은 apply 셸 스크립트와 YAML 파일 묶음만 있으면 재난이 나도 90%는 복구할 수 있겠다는 느낌이 좋음
    systemd는 개념적으로는 단순하지만 재현성이 복잡하고, Kubernetes는 반대임. 개념 비용은 더 내지만 재현성과 그에 따라오는 이해는 훨씬 강해짐. 적어도 지금은 그렇게 봄
    아직 Kubernetes를 배우는 중간 단계지만, 최근 꽤 재미있게 쓰고 있음

    • 10년 전에는 동의했겠지만, 지금은 다양한 네임스페이스 옵션과 동적 사용자 통합 때문에 systemd도 “또 하나의 괴물”처럼 느껴짐
      이런 1급 정의를 갖춘 수직 통합은 잘못된 방향처럼 보임
    • AI가 썼는지는 별로 중요하지 않음. 잘 썼느냐 못 썼느냐가 중요함
답변달기