# 취업 면접이 Kubernetes에 대해 알려준 것 > Clean Markdown view of GeekNews topic #30556. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30556](https://news.hada.io/topic?id=30556) - GeekNews Markdown: [https://news.hada.io/topic/30556.md](https://news.hada.io/topic/30556.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-17T09:13:36+09:00 - Updated: 2026-06-17T09:13:36+09:00 - Original source: [notnotp.com](https://notnotp.com/notes/what-job-interviews-taught-me-about-kubernetes/) - Points: 19 - Comments: 1 ## Topic Body - 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](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), 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`로 고치는 방식이 빠르고 이해 가능한 비상 대응일 수 있음 ## Comments ### Comment 59766 - Author: neo - Created: 2026-06-17T09:13:37+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/k6qon4/what_job_interviews_taught_me_about) - 유럽 쪽에서는 이유가 분명함. 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가 썼는지는 별로 중요하지 않음. 잘 썼느냐 못 썼느냐가 중요함