[발표자료 다운로드]쿠버네티스의 단점은 무엇인가요?

어려움에는 두 종류가 있다. 배우면 사라지는 어려움과 알아도 그대로 남는 어려움이다. 이 둘을 섞어 놓으면 도입 논의가 취향 다툼으로 흘러간다. 전체 17장, PDF 로 17쪽이다. 1부는 쿠버네티스가 왜 처음에 어렵게 느껴지는지를 개념 계층·설정 파일·디버깅 전환·관측 범위 순서로 풀고, 그 항목들이 학습과 적응으로 해소된다는 점을 확인한다. 2부는 기존 운영 방법을 같은 자로 잰다. 새로 배울 것은 없지만 수작업과 절차 개선의 한계가 그대로 남는 구조다. 발표 노트에 담은 비유는 결정권자에게 설명할 때 그대로 쓸 수 있도록 썼다. 내부 검토 자료나 팀 스터디 자료로 그대로 쓸 수 있도록 별도 가공 없이 원본 구성 그대로 공개한다.

슬라이드만으로는 두 어려움이 어떻게 갈리는지 잘 보이지 않는다. 쿠버네티스가 애초에 무엇을 해결하려는 도구인지를 먼저 보면 나머지가 선명해진다. 영상을 먼저 보면 이 발표자료의 논지 흐름이 한 번에 잡힌다.

영상에서 다루는 순서는 다음과 같다.

• 서버 한 대에 앱 하나를 올리던 시절의 한계
• 컨테이너 오케스트레이션이 필요해지는 지점
• 도입으로 얻는 것과 새로 떠안는 것
• 서비스 규모에 따라 달라지는 선택지

개념부터 순서대로 보고 싶다면 쿠버네티스란 무엇인가 — 개념과 도입 이유를 먼저 읽으면 이 발표자료의 전제가 이어진다.

쿠버네티스 도입 검토 회의에서 반복해서 나오는 질문을 기준으로 슬라이드를 배치했다.

1. 쿠버네티스를 한 문장으로 설명하면 무엇인가
2. 개념을 익히는 데 실제로 몇 달이 걸리는가
3. 도커를 써 봤으면 학습이 빨라지는가
4. 장애 대응 절차가 서버 시절과 무엇이 달라지는가
5. 쿠버네티스를 걷어내면 복잡함이 사라지는가
6. 우리 서비스 규모에서 도입이 값을 하는가

쿠버네티스는 서버를 사람이 운영하던 시대를 끝내고 인프라가 스스로 운영되는 시대를 연 표준 플랫폼이다. 컨테이너를 관리해 주는 도구라는 설명은 틀리지 않지만, 왜 이 기술이 업계를 바꿨는지는 설명하지 못한다. 옛 방식에서는 서로 간섭할까 봐 서버 한 대에 애플리케이션 하나를 올렸다. 장비는 10퍼센트만 쓰이는데 전기료와 상면료는 100퍼센트를 냈다. 더 큰 문제는 앱이 돌아갈 환경을 사람이 손으로 다시 만들었다는 점이다. 서버마다 OS 버전과 라이브러리가 조금씩 달랐고, 그 차이가 재현되지 않는 장애로 돌아왔다. 구글은 이 한계에 가장 먼저 부딪힌 회사였다. 데이터센터 한 곳이 수만 대인데 사람이 손으로 운영하는 것이 불가능했다. 그래서 Borg 라는 내부 시스템을 만들어 모든 것을 컨테이너로 돌렸고, 2014년 쿠버네티스를 공개할 때 주당 20억 개 컨테이너 실행이라는 숫자를 밝혔다. 구글이 컨테이너를 고른 이유는 가벼워서가 아니라 자동화가 가능해지는 최소 규격이었기 때문이다. 컨테이너는 호스트 커널을 공유하므로 기동이 수 밀리초에서 수 초로 끝나고, 이미지 크기가 수십에서 수백 메가바이트에 머물러 32기가바이트 서버 한 대에 60세대 이상을 올릴 수 있다(Cloud Native Forum 쿠버네티스 전자책 2.1.2).

마지막 줄이 나머지 전부보다 중요하다. 단독주택에 살면 보일러 모델과 수도 밸브 위치를 알아야 하지만 아파트에서는 몰라도 된다. 컨테이너가 가져온 본질은 가벼움이 아니라 몰라도 되는 것이 늘어났다는 데 있다. 다만 아파트 벽은 단독주택 담보다 얇다. 컨테이너 격리는 커널을 공유하므로 가상머신보다 격리 수준이 낮고, 보안 요구가 강한 구간에서 두 방식을 함께 쓰는 이유가 여기에 있다. 가상화 기반 구성에서 무엇이 남고 무엇이 바뀌는지는 AI 시대에 가상서버 대신 쿠버네티스를 선택하는 이유에 정리돼 있다.

쿠버네티스가 어렵게 느껴지는 항목은 여섯 가지이고, 드러나는 시점이 서로 다르다. 도입 검토 자리에서는 앞의 둘만 보인다.

▲ 단점 여섯 가지는 동시에 오지 않는다 — 도입 검토 자리에서 보이는 것은 앞의 두 칸뿐이다 (발표자료 4쪽)

초기 검토만으로는 총량이 보이지 않으므로 검토서에 시간 축을 넣어야 계산이 맞는다. 뒤의 네 항목이 언제 오는지를 도입 결재 전에 결정해야 한다.

개념은 나란히 놓인 목록이 아니라 층층이 쌓인 구조라 학습 순서를 바꿀 수 없다. 인원을 늘려도 기간이 압축되지 않는 이유가 여기에 있다. 1층 파드는 컨테이너가 실제로 도는 최소 단위다. 2층 레플리카셋이 같은 파드를 정해진 수만큼 유지하고, 3층 디플로이먼트가 레플리카셋을 갈아 끼우며 버전을 전환한다. 4층 서비스가 계속 바뀌는 파드 주소를 고정된 이름 하나로 묶고, 5층 인그레스가 외부 요청을 규칙에 따라 내부로 보낸다.

▲ 쿠버네티스 개념 다섯 층은 순서를 바꿀 수 없어 인원을 늘려도 학습 기간이 압축되지 않는다 (발표자료 5쪽)

집중 투입 기준으로 현실적인 학습 기간은 2개월에서 3개월이다. 가장 흔한 함정은 쿠버네티스를 기능 많은 도커로 이해한 채 2층부터 시작하는 경우인데, 도커 경험이 출발점을 앞당겨 주지는 않는다. 도입을 검토한다면 이 기간을 일정표에 먼저 적어 두어야 한다.

클러스터에서는 설정을 버튼으로 누르지 않고 형식 규칙을 지킨 파일로 제출한다. 그 형식이 까다롭다는 점이 두 번째로 걸리는 항목이다. 이미지 항목이 한 칸 더 들어가면 replicas 의 하위 항목으로 해석되어 배포 전체가 거절된다. 무엇이 틀렸는지는 따로 찾아야 한다. 서비스가 수십 개로 늘면 설정 파일이 수백 장이 되고, 파일을 찍어내는 도구인 Helm 템플릿이 다시 학습 대상으로 추가된다.

▲ YAML 한 줄의 들여쓰기 한 칸이 배포 전체를 거절시킨다 (발표자료 6쪽)

설정 작성과 검증에 드는 시간이 개발 시간을 넘어서는 구간을 업계에서는 YAML 지옥이라고 부른다. 변경 추적이 별도 업무로 갈라지는 시점이 곧 설정 관리 도구를 준비해야 하는 시점이다. 서비스가 열 개를 넘어서면 템플릿 도입을 함께 검토해야 한다.

서버에 접속해 파일을 고치고 프로세스를 재기동하던 절차가 이 구조에서는 그대로 무효가 된다. 새 파드가 뜨는 순간 수정분이 사라지기 때문이다. 올바른 경로는 컨테이너 이미지를 다시 만들고, 매니페스트 파일을 갱신하고, 배포 명령을 실행하는 순서다. 절차가 하나 더 늘어난 것처럼 보이지만 이것이 정상 경로다. 파드는 고쳐 쓰는 물건이 아니라 버리고 새로 찍는 물건이라는 것이 클라우드 네이티브의 통용 원칙이다. 아파트 비유로 보면 장기 거주 세대보다 호텔 투숙에 가깝고, 방 번호가 계속 바뀌므로 밖에서 부를 때는 프런트 데스크에 해당하는 서비스를 거친다.

▲ 파드를 직접 고치면 새 파드가 뜨는 순간 원복되고, 로그도 파드와 함께 사라진다 (발표자료 7쪽)

실무에서 가장 아픈 지점은 파드가 사라지면 그 안의 로그도 함께 사라진다는 것이다. 원인을 남기려면 로그를 클러스터 밖으로 내보내는 설정이 첫 장애보다 먼저 있어야 한다. 반출 경로는 첫 배포 전에 점검해야 한다.

응답이 없다는 장애 한 건의 원인 후보가 단일 서버 시절에는 그 서버 안에 한정됐지만 클러스터에서는 다섯 갈래로 갈라진다. 노드 자원 부족으로 스케줄이 안 됐을 수도 있고, 네트워크 정책에 통신이 막혔을 수도 있고, 배치 조건에 맞는 노드가 없었을 수도 있다. 이미지 태그나 레지스트리 접근 실패, 환경 변수와 시크릿 누락도 후보다. 문제 수가 늘어난 것이 아니라 한 문제가 여러 갈래로 나뉜 것이다.

▲ 장애 한 건이 원인 후보 다섯 갈래로 갈라져 관측 도구가 도입과 같은 시점에 필요하다 (발표자료 8쪽)

그래서 지표와 로그와 추적을 모으는 관측 도구가 도입과 같은 시점에 있어야 한다. 이것이 없으면 첫 장애에서 어디부터 볼지를 정하지 못하고 복구 시간이 통째로 늘어난다. 도입 일정에 관측 도구 구축을 같은 칸에 적어 두어야 한다.

클러스터가 알아서 복구하고 알아서 늘어난다고들 말한다. 왜 갑자기 그것이 가능해졌는지는 자율주행이 가능해진 조건을 따라가면 그대로 답이 나온다. 도로와 차선이 규격화되고, 핸들과 브레이크가 전자적으로 조작 가능해지고, 센서가 현재 상태를 항상 읽고, 사람은 목적지만 찍는다. 클러스터도 같다. 컨테이너라는 실행 규격이 생기고, 모든 자원이 API 로 조작 가능해지고, 클러스터 상태를 항상 관측하고, 사람은 원하는 상태만 선언한다. 차이가 나면 컨트롤러가 스스로 고친다.

▲ 쿠버네티스가 대신 해주는 자동 운영 기능 여덟 가지가 치르는 값의 대가다 (발표자료 13쪽)

그 대가로 얻는 것이 자동 운영 기능 여덟 가지다. 무중단 배포, 자동 장애 복구, 로드밸런싱, 서비스 디스커버리, 헬스체크, 롤백, 시크릿 관리, 자동 확장과 축소가 그것이다. 순서가 컨테이너가 먼저이고 쿠버네티스가 나중인 이유도 같다. 규격 없이 자동화부터 하려던 과거의 시도가 실패한 자리다.

여기서부터가 알아도 그대로 남는 어려움이다. 기존 운영 방법은 하드웨어 가상화 기반이라 새로 배울 것이 없다. 대신 수작업이 남고 절차 개선이 어렵다. 도입은 운영 업무를 없애는 일이 아니라 옮기는 일이다. 줄어드는 항목과 늘어나는 항목의 수가 비슷하다.

▲ 서버 운영 업무는 사라지지 않고 클러스터 쪽으로 옮겨간다 — 양쪽 항목 수가 비슷하다 (발표자료 12쪽)

도입 효과를 인력 감축으로 계산하면 빗나간다. 서버 담당 인원을 그대로 줄이면 클러스터 운영이 공백으로 남고 결국 외주나 재채용으로 되돌아온다. 업무가 어느 쪽으로 어떻게 재배치되는지는 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화에서 항목별로 확인할 수 있다.

쿠버네티스를 걷어내면 복잡함이 사라진다는 기대는 그 여덟 가지 요구사항이 애초에 필요 없는 서비스에서만 성립한다. 그렇다면 처음부터 도입 대상이 아니었던 것이다. 클라우드 네이티브 컴퓨팅 재단은 2026년 3월 글에서 복잡한 것은 도구가 아니라 그 도구가 하는 일이라고 정리했다. 도구를 걷어내도 무중단 배포와 자동 복구와 오토스케일 요구는 남고, 손으로 만든 구현이 더 복잡하고 더 잘 깨진다는 것이 반론의 근거다.

▲ 쿠버네티스를 걷어내도 서비스 운영 요구사항 여덟 가지는 그대로 남는다 (발표자료 11쪽)

정리하면 어려움의 절반 정도는 도구의 잘못이 아니라 분산 시스템을 하기로 한 순간 따라오는 값이다. 다만 그 값을 지금 치를 필요가 있느냐는 완전히 다른 질문이다. 값이 아니라 오해에서 비롯된 반대 논리는 쿠버네티스 도입을 막는 오해와 장벽 12가지에서 따로 정리했다.

클러스터 접근 통제는 담당자가 있을 때만 유지된다. 담당자 공백이 곧 접근 통제 공백이 되는 구조다. 역할 기반 접근 제어인 RBAC 는 누가 무엇을 할 수 있는지 정하는 설정인데, 초기값을 그대로 두면 필요 이상의 권한이 남는다. 클러스터 접속 자격증명 파일인 kubeconfig 는 파일 하나가 클러스터 전체 접근 권한과 같은 무게를 갖고, 한 번 공유되면 회수가 어렵다.

▲ 설치는 담당자 없이 되지만 운영은 되지 않는다 — 담당자 공백이 곧 접근 통제 공백이다 (발표자료 14쪽)

담당자가 이탈하면 설정 파일은 남지만 왜 그렇게 정했는지는 남지 않는다. 초기값 권한과 자격증명 파일의 보관 위치는 분기마다 점검해야 한다. 가장 비싼 순서는 먼저 설치하고 담당자는 나중에 구하는 방식이다. 관리사무소도 누군가는 운영해야 한다는 점이 아파트 비유의 한계이자 현실이다. 공공 부문이라면 요구 수준이 문서로 고정돼 있다. 국가정보원 국가 클라우드 컴퓨팅 보안 가이드라인 v4.0 은 컨테이너 가상화 기술 스택을 관리 노드와 컨테이너 노드와 레지스트리 3계층으로 나누고 보안기준 13개와 세부 점검항목 30개를 제시한다. 감사와 패치 점검과 런타임 탐지는 상시 운영 항목이라 담당자 없이는 유지되지 않는다.

도입 성패를 가르는 것은 도구 품질이 아니라 서비스 규모와 변동 폭의 적합성이다. 작은 서비스에서는 얻는 것이 운영 부담을 넘지 못한다. 규모도 작고 변동도 작으면 관리형 호스팅으로 충분하고, 도입하면 얻는 것 없이 운영 부담만 늘어난다. 규모는 작은데 변동이 크면 관리형 컨테이너 서비스가 중간 선택지가 된다. 규모는 큰데 변동이 작으면 일부 서비스만 부분 도입해 보는 구간이다. 규모도 크고 변동도 큰 구간이 치른 값을 회수하는 자리다.

▲ 규모와 변동 폭 두 축이 도입 성패를 가른다 — 작은 서비스에서는 얻는 것이 부담을 못 넘긴다 (발표자료 15쪽)

자주 인용되는 비유는 차고가 낮아 동네 마트 주차장을 빠져나오지 못하는 페라리다. 도구가 나쁜 것이 아니라 할 일과 크기가 맞지 않는 것이다. 우리 서비스가 어느 사분면에 있는지를 먼저 결정해야 한다.

규모와 담당자와 예산 세 질문에 모두 예라고 답할 수 있을 때만 치른 값이 운영에서 회수된다. 하나라도 아니오면 값만 치르게 된다. 첫째, 서비스 수와 배포 빈도가 수작업 한계를 넘었는가. 손으로 배포할 수 있는 양이면 자동화 대상이 아직 아니다. 둘째, 클러스터를 맡을 담당자가 지금 있는가. 나중에 뽑겠다는 답은 아니오다. 셋째, 관측 도구와 업그레이드를 감당할 예산이 있는가. 연 3회 업그레이드와 지표 수집이 상시 항목으로 들어가야 한다.

▲ 규모·사람·예산 세 질문이 모두 예일 때만 치른 값이 운영에서 회수된다 (발표자료 16쪽)

업그레이드가 왜 별도 예산 항목이 되는지는 쿠버네티스 업그레이드가 어려운 이유에서 의존성과 백업 관점으로 다룬다. 세 질문이 모두 예라면 처음의 어려움은 그대로 오지만 얻는 것이 그보다 크다. 하나라도 아니오라면 아니오인 항목을 먼저 해소하는 것이 도입보다 앞선 순서다. 검토를 시작한 팀이라면 이 세 항목을 30일 안에 점검해야 한다.

쿠버네티스는 배우면 쉬워지는 기술이고, 기존 운영 방법은 익숙하지만 수작업과 절차 개선의 한계가 남는 구조다. 어려움의 성격이 다르므로 같은 자로 재면 안 된다.

▲ 단점 여섯 가지는 조건이 서로 달라 우리 팀에 해당하는 행만 골라 읽으면 된다 (발표자료 9쪽)

여섯 가지가 같은 조건에서 오지 않으므로 우리 팀에 해당하는 행이 몇 개인지가 도입 시점 판단의 입력값이다. 해당 행이 셋을 넘으면 도입 시점을 미루는 쪽을 먼저 검토해야 한다.

쿠버네티스를 한 문장으로 쉽게 설명하면 무엇인가

서버를 사람이 운영하던 시대를 끝내고 인프라가 스스로 운영되는 시대를 연 표준 플랫폼이다. 개발팀은 컨테이너 이미지와 원하는 상태 한 장만 내놓고, 어디에 배치할지와 죽으면 어떻게 살릴지는 플랫폼이 맡는다.

컨테이너와 가상머신의 차이를 비유로 들면 무엇인가

단독주택 단지와 아파트 단지의 차이다. 가상머신은 집집마다 기초와 보일러와 수도를 따로 갖추지만 컨테이너는 건물이 한 번 갖춘 설비를 공유한다. 본질은 가벼움이 아니라 입주민이 몰라도 되는 것이 늘어났다는 데 있다.

쿠버네티스 학습에 실제로 몇 달이 걸리는가

집중 투입 기준으로 2개월에서 3개월이다. 개념이 파드부터 인그레스까지 다섯 층으로 쌓여 있어 순서를 바꿀 수 없기 때문에, 인원을 더 투입해도 학습 기간이 압축되지 않는다.

도커를 써 봤으면 쿠버네티스 학습이 빨라지는가

출발점을 앞당겨 주지는 않는다. 가장 흔한 함정이 쿠버네티스를 기능 많은 도커로 이해한 채 레플리카셋 층부터 시작하는 경우인데, 파드와 컨트롤러의 관계를 건너뛰면 그 위층이 이해되지 않는다.

장애가 났을 때 왜 원인 찾기가 더 어려워지는가

응답 없음이라는 장애 한 건의 원인 후보가 노드 자원 부족, 네트워크 정책, 스케줄링 실패, 이미지 문제, 설정 오류 다섯 갈래로 갈라지기 때문이다. 파드가 사라지면 그 안의 로그도 함께 사라지므로 로그 반출 설정이 첫 장애보다 먼저 있어야 한다.

쿠버네티스를 쓰지 않으면 복잡함이 사라지는가

사라지지 않는다. 무중단 배포와 자동 복구와 로드밸런싱을 포함한 여덟 가지 요구사항은 도구를 바꿔도 남는다. 클라우드 네이티브 컴퓨팅 재단은 손으로 만든 구현이 더 복잡하고 더 잘 깨진다는 점을 반론의 근거로 제시한다.

우리 서비스 규모에서 도입이 값을 하는지 어떻게 판단하는가

서비스 수와 배포 빈도가 수작업 한계를 넘었는지, 클러스터를 맡을 담당자가 지금 있는지, 관측 도구와 업그레이드 예산이 잡혀 있는지 세 질문에 모두 예라고 답할 수 있으면 검토를 진행할 만하다. 하나라도 아니오면 관리형 서비스나 기존 배포 방식을 유지하는 편이 낫다.

쿠버네티스 개념과 운영을 더 깊이 볼 때 함께 읽을 자료다.

• 쿠버네티스란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 Pod란? 개념과 생명주기와 멀티컨테이너 패턴
• 쿠버네티스 vs 도커 차이 완벽 정리
• 쿠버네티스의 탄생과 진화 — 구글 보그에서 AI 운영체제까지
• 쿠버네티스 설치 가이드 — 첫 클러스터 구축
• 쿠버네티스 네트워킹과 CNI — Calico와 Cilium과 Flannel 비교
• 쿠버네티스 접근 제어 — 인증서 관리 방안
• 쿠버네티스 보안 대응 — 클라우드 네이티브 보안의 4C 모델
• Prometheus가 쿠버네티스 메트릭의 표준이 된 이유
• k3s란? 경량 쿠버네티스의 구조와 배포판 선택 가이드
• 쿠버네티스 프로덕션 도입 사례와 운영 교훈
• 쿠버네티스 작동원리부터 운영까지 — 왜 지금 알아야 하는가
• 클라우드 네이티브란? 구성 요소와 아키텍처와 전환 사례
• 전자책 2.1.2 VM과 컨테이너 비교
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• 쿠버네티스 업그레이드가 어려운 이유 — 의존성과 백업과 버전 관리
• AI 시대, 가상서버 대신 쿠버네티스를 선택하는 이유

몰라서 어려운 것과 알아도 손이 가는 것을 구분한 발표자료 17장 전체를 17쪽 PDF 로 공개한다. 사내 검토 자료나 팀 스터디 자료로 자유롭게 쓸 수 있다. 아래 버튼에서 같은 PDF 를 다시 내려받을 수 있다.