[발표자료 다운로드]쿠버네티스를 쉽게 설명하면 무엇인가요?

전체 21장, PDF 로 21쪽이다. 1부는 쿠버네티스 이전이 왜 한계에 부딪혔는지를 서버 이용률, 환경 이관, 운영 부담 순서로 풀고 구글이 컨테이너를 표준으로 삼은 이유 세 가지를 확인한다. 2부는 그 규격 위에서 쿠버네티스 운영이 어떻게 자동으로 돌기 시작했고 현장의 일이 어떻게 달라졌는지를 제어 루프와 골든 패스로 정리한다.

컨테이너를 처음 듣는 사람도 따라올 수 있도록 단독주택과 아파트라는 비유 하나를 자료 전체에서 반복해 쓴다. 비유가 어긋나는 지점도 숨기지 않고 함께 적었다. 발표 노트에는 결정권자에게 설명할 때 그대로 쓸 수 있는 문장을 담았다.

회의 자료나 사내 스터디 자료로 그대로 쓸 수 있도록 원본 구성을 손대지 않고 공개한다.

슬라이드만 보면 이 자료가 왜 역사 순서로 짜였는지 잘 드러나지 않는다. 쿠버네티스가 애초에 무엇을 해결하려고 나온 도구인지를 먼저 보면 나머지가 선명해진다.

영상을 먼저 보면 이 발표자료가 왜 이 순서로 짜였는지가 한 번에 잡힌다.

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

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

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

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

1. 서버 이용률이 10%대였던 진짜 이유는 무엇인가
2. 구글은 왜 하필 컨테이너를 표준 규격으로 골랐는가
3. VM 과 컨테이너는 실제로 어디서 갈리는가
4. 쿠버네티스 운영이 자동으로 돌기 시작한 전제 조건은 무엇인가
5. 개발팀이 내놓아야 할 것은 무엇으로 줄었는가
6. 도입을 검토한다면 어떤 순서로 가야 하는가

예전 서버가 놀았던 원인은 장비가 느려서가 아니라 앱을 서로 떼어 놓을 방법이 없어서였다. 이것이 모든 이야기의 출발점이다.

발표자료의 예시에서 서버 세 대의 이용률은 각각 10%, 8%, 15% 다. 열 대 중 한 대만큼만 일하고 있었다는 뜻이다. 그런데 장비값과 전기료와 상면료는 이용률과 무관하게 100% 그대로 청구된다. 남은 용량에 다른 앱을 올리면 될 것 같지만 그렇게 하지 못했다. 한쪽 앱의 라이브러리 버전을 바꾸면 옆에 있는 앱이 멈춰 버렸기 때문이다.

▲ 서버 이용률이 10%대에 머문 원인은 성능이 아니라 격리였다 — 한쪽 앱의 라이브러리를 바꾸면 옆 앱이 멈추니 장비를 따로 샀고, 비용은 이용률과 무관하게 100% 나갔다. (발표자료 4쪽)

그래서 아예 장비를 따로 사는 편이 안전했고, 서버 한 대에 애플리케이션 하나가 당시의 기본 규칙이 되었다. 성능이 부족해서 낭비한 것이 아니라 안전을 위해 성능을 포기한 선택이었다.

두 번째 문제는 더 골치 아팠다. 앱이 돌아갈 환경을 사람이 손으로 다시 만들었다는 점이다.

개발팀이 내 PC에서 동작까지 확인해도, 운영 서버에 올리려면 그 서버에 똑같은 환경을 다시 구축해야 했다. 이 재구축 구간에서 갈라지는 지점이 셋이다. OS 버전, 라이브러리 버전, 설정 파일이다. 세 가지가 서버마다 조금씩 어긋난 채로 반영되면 어느 한 서버에서만 나는 장애가 생기고, 재현이 안 되니 원인도 못 찾는다.

▲ “제 PC에서는 됩니다”는 개인의 실수가 아니라 이관 구조의 산물이다 — OS 버전·라이브러리 버전·설정 파일 세 가지가 서버마다 어긋난 채 반영됐다. (발표자료 5쪽)

제 PC에서는 됐는데요라는 말은 그래서 개인의 실수가 아니다. 환경을 사람이 손으로 옮기는 구조가 만들어 낸 말이다. 구조를 바꾸지 않으면 담당자를 바꿔도 같은 말이 반복된다.

앞의 두 문제가 겹치면 현장에서는 다섯 가지 일이 일상이 된다. 공통점은 느리다는 것이 아니라 사람에게 묶여 있다는 것이다.

서버마다 설정이 달라 특정 서버에서만 장애가 나고, 배포가 두려워 주말 새벽에 작업하고 롤백 계획서를 쓰고 전사 공지를 돌린다. 장애가 나면 새벽 3시에 담당자가 깨서 서버에 접속한다. 증설은 장비를 사서 입고하고 설치하고 세팅할 때까지 몇 주가 걸려 이벤트가 이미 끝나 있기도 하다. 장비마다 이름을 붙여 아끼며 관리했기 때문에 한 대가 멈추면 대체할 방법이 없었다.

▲ 운영 부담 다섯 가지의 공통점은 느린 것이 아니라 사람에게 묶인 것이다 — 배포·장애·증설이 전부 특정 담당자의 시간과 기억을 기다려야 진행됐다. (발표자료 6쪽)

다섯 줄이 전부 특정 담당자의 시간과 기억을 기다려야 진행된다. 규모가 커질수록 사람이 먼저 한계에 도달하는 구조다.

수작업이 현장에서 어떤 모양으로 반복되고 왜 절차 개선만으로는 사라지지 않는지는 기존 IT 운영 환경에서의 반복적인 수작업과 그 한계에 항목별로 정리돼 있다.

이 한계를 가장 먼저 만난 회사가 구글이다. 데이터센터 한 곳에 서버가 수만 대, 그 위에서 도는 애플리케이션이 수천 종이었다.

이 규모에서는 사람이 손으로 운영하기 어려운 수준이 아니라 물리적으로 불가능하다. 그래서 구글은 2003년에서 2004년경 Borg 라는 내부 시스템을 만들어 모든 것을 컨테이너로 돌렸다. 2014년 쿠버네티스를 공개하면서 밝힌 수치가 주당 20억 개 컨테이너 실행이다.

▲ 구글이 먼저 부딪힌 것은 속도가 아니라 인원이다 — 수만 대에서 매일 생기는 고장을 사람 수로 따라갈 수 없어 Borg 로 넘겼고, 2014년 공개 시점의 실행량은 주당 20억 개 컨테이너였다. (발표자료 7쪽)

쿠버네티스는 새로 만든 실험이 아니라 10년 넘게 돌려 본 시스템을 다시 설계한 것이다. 구글이 먼저 부딪힌 것은 속도가 아니라 인원이었다. 수만 대에서 매일 생기는 고장을 사람 수로 따라갈 수 없어 기계에 넘겨야 했다.

구글의 데이터센터에서 시작된 이 흐름을 연표로 훑고 싶다면 쿠버네티스가 필요한 이유 — 구글 데이터센터에서 시작된 컨테이너 혁명을 함께 보면 배경이 이어진다.

구글이 컨테이너를 고른 이유는 셋인데, 셋 다 가볍다는 이야기와는 거리가 멀다.

첫째는 한 대에 빽빽이 채우기 위해서다. Borg 논문에는 admission control, efficient task-packing, over-commitment, machine sharing 네 기법이 그대로 적혀 있다. 둘째는 고장을 전제로 설계하기 위해서다. 기계가 사람 대신 복구하려면 무엇을 어떻게 실행할지가 기계가 읽을 수 있는 규격이어야 한다. 셋째는 개발자를 인프라에서 떼어내기 위해서다. Borg 논문은 개발자에게 원하는 상태를 적어 내는 선언형 명세 언어를 주고 자원 관리와 장애 처리는 그 아래로 감춘다고 목적을 적었다.

▲ 구글이 컨테이너를 고른 기준은 크기가 아니라 조작 가능성이다 — 규격이 통일돼야 배치·복구·확장을 기계에 맡길 수 있다. (발표자료 8쪽)

구글은 컨테이너를 가벼운 가상 서버로 본 것이 아니라 자동화가 시작될 수 있는 최소 규격으로 봤다. 규격이 통일되어야 배치와 복구와 확장을 기계에 맡길 수 있다.

컨테이너가 빨라진 원인은 최적화가 아니라 게스트 OS 한 벌이 통째로 빠진 것이다. 이 구조를 주택과 아파트로 보면 한 그림에 들어온다.

가상머신은 단독주택 단지다. 집마다 기초와 보일러와 수도를 따로 갖추듯 가상 머신마다 게스트 OS 한 벌을 통째로 싣는다. 땅은 넓은데 몇 채밖에 세우지 못하고 수리도 집집마다 따로 부른다. 컨테이너는 아파트 단지다. 공용 골조와 배관과 엘리베이터를 모든 세대가 함께 쓰듯 호스트 OS 커널 하나를 공유한다. 같은 땅에 수십 세대가 들어서고 짐만 들이면 바로 입주한다.

▲ 컨테이너가 빨라진 원인은 게스트 OS 한 벌이 빠진 것이다 — 단독주택이 집집마다 갖추던 설비를 아파트는 건물이 한 번 갖추듯, 호스트 커널 하나를 함께 쓴다. (발표자료 9쪽)

비유가 어긋나는 지점도 함께 적어 둔다. 아파트 세대는 좀처럼 이사를 다니지 않지만 파드는 수시로 죽고 다시 태어난다. 장기 거주보다 단기 투숙에 가깝고, 새로 뜬 파드는 새 IP 를 받으므로 어제의 주소로는 오늘 닿지 않는다. 그래서 바깥에서 부를 때는 호텔의 프런트 데스크에 해당하는 Service 를 거친다. 뒤에서 파드가 바뀌어도 부르는 쪽은 그대로다.

이 비유를 쓰는 이유는 설비 공유와 밀도와 책임 경계 세 가지를 한 그림에 담기 때문이다. 오케스트라 지휘자 비유는 여러 개를 조율한다는 인상만 주고, 항구와 컨테이너선 비유는 용어 암기에는 좋지만 개발팀의 일이 왜 바뀌는지를 설명하지 못한다.

컨테이너로 옮겨 담았을 때 실제로 얻는 것이 무엇인지는 컨테이너화의 필요성 및 장점에 항목으로 나뉘어 있다.

VM 과 컨테이너를 여섯 항목으로 재면 숫자 차이가 크게 보이지만, 도입 결정을 가르는 것은 마지막 한 줄이다.

기동 시간은 수십 초에서 수 분이던 것이 수 밀리초에서 수 초로, 이미지 크기는 수 GB 에서 수십 GB 이던 것이 수십에서 수백 MB 로 줄어든다. 한 대당 밀도는 몇 개에서 32GB 서버에 60개 이상으로 늘고, 성능 손실은 1~6% 오버헤드에서 거의 없는 네이티브 수준이 된다. 그런데 앞의 다섯 줄은 정도의 차이다. 운영 주체를 바꾸는 것은 설비 책임자 한 줄이다. 앱을 올린 팀이 직접 맡던 것을 플랫폼이 대신 맡는다.

▲ 여섯 줄 비교에서 운영 주체를 바꾸는 것은 설비 책임자 한 줄이다 — 기동 시간·이미지 크기·밀도는 정도의 차이여서 도입 결정을 가르지 못한다. (발표자료 10쪽)

대신 치르는 값도 있다. 커널을 함께 쓰므로 VM 보다 격리 수준이 낮다. 규제나 보안 요구가 강한 구간에서는 VM 과 병행하는 구성이 현실적이고, 관리 주체가 바뀐 것이지 관리가 사라진 것은 아니다.

▲ 컨테이너는 VM 을 전부 대체하지 못한다 — 커널을 함께 쓰므로 격리 수준이 낮고, 규제·보안 요구가 강한 구간에서는 VM 과 병행이 현실적이다. (발표자료 11쪽)

쿠버네티스 운영이 갑자기 자동으로 돌기 시작한 것처럼 보이지만 전제 조건이 다섯 개 갖춰진 결과다. 무인 주행이 성립한 조건과 나란히 놓으면 그대로 겹친다.

도로와 차선과 신호가 규격화된 것은 컨테이너라는 실행 규격이 생긴 것에 대응한다. 핸들과 브레이크를 전자적으로 조작하게 된 것은 모든 자원을 API 로 조작하게 된 것, 센서가 현재 상태를 항상 읽는 것은 클러스터 상태를 항상 관측하는 것, 사람이 목적지만 찍는 것은 원하는 상태만 선언하는 것, 차이가 나면 차가 스스로 조향하는 것은 컨트롤러가 스스로 조정하는 것에 대응한다.

▲ 자율 운영의 다섯 조건은 함께 있어야 의미가 있다 — 규격·API·관측·선언·조정 가운데 하나라도 빠지면 자동화가 스크립트 수준에 머문다. (발표자료 13쪽)

여기서 순서가 중요하다. 자율주행의 전제가 핸들이 전자적으로 조작 가능해진 것이었듯, 자율 운영의 전제는 앱이 컨테이너라는 규격으로 포장된 것이었다. 그래서 컨테이너가 먼저고 쿠버네티스가 나중이다. 다섯 조건은 함께 있어야 의미가 있고, 하나라도 빠지면 자동화가 스크립트 수준에 머문다.

조건이 갖춰지면 실제로 도는 것은 선언과 관측과 차이와 조정을 반복하는 제어 루프다. 정식 명칭은 Reconciliation Loop 다.

사람이 적는 값은 웹 서버 5대 유지 한 줄이 전부다. 그다음은 루프가 선언된 상태와 현재 상태 사이의 간격을 계속 메운다. 컨테이너가 죽어 5대보다 적어지면 컨트롤러가 즉시 다시 띄우고 사람은 다음 날 원인만 확인한다. 트래픽이 기준을 넘으면 대수를 늘리고 가라앉으면 다시 줄인다. 서버가 고장 나면 그 서버에 있던 몫을 남은 서버로 옮겨 싣는다.

▲ 제어 루프는 “웹 서버 5대 유지” 한 줄로 세 가지 상황을 처리한다 — 컨테이너 사망·트래픽 급증·서버 고장에 사람이 절차를 수행하지 않는다. (발표자료 14쪽)

예전에는 서버에 접속해 설치하고 설정하고 재기동하는 절차를 사람이 밟았다. 지금은 사람이 하는 일이 절차 수행에서 목표 선언으로 줄었고, 세 가지 상황을 전부 같은 한 줄이 처리한다.

선언형 API 가 이 반복을 어떻게 떠받치는지는 쿠버네티스가 제공하는 선언적 API와 자동화의 힘에서 더 볼 수 있고, 실제로 무엇이 자동화되는지는 쿠버네티스가 실현하는 구체적인 자동화 사례에 모여 있다.

현장의 일곱 가지 일상 업무를 예전과 지금으로 나란히 놓으면 변화의 크기가 드러난다.

배포 주기는 분기나 월 단위 주말 새벽 작업에서 하루에도 여러 번 업무 시간에 하는 일이 됐다. 장애 대응은 담당자가 깨어 직접 복구하던 것이 자동 복구로 바뀌었다. 증설은 몇 주에서 숫자 하나 변경으로 수 초가 됐다. 운영 지식은 담당자의 기억과 위키 문서에 있던 것이 YAML 코드에 적혀 검토와 버전 관리와 복제가 가능해졌다.

▲ 가장 크게 바뀐 것은 속도가 아니라 개발팀의 관심사다 — “어디서 어떻게 돌지”를 묻지 않게 되면서 “무엇을 만들지”에 쓸 시간이 늘었다. (발표자료 15쪽)

표의 결론은 맨 아랫줄이다. 개발팀의 관심사가 어디서 어떻게 돌지에서 무엇을 만들지로 바뀌었다. 속도가 빨라진 것보다 이쪽이 더 큰 변화다.

예전에 개발팀이 알아야 했던 범위는 앱부터 런타임, OS 버전, 미들웨어 설정, 네트워크, 로그, 백업, 서버까지 여덟 가지였다. 지금은 책임 경계선이 내려왔다.

개발팀이 내놓는 것은 두 가지다. 하나는 컨테이너 이미지로, 앱과 그 앱이 필요로 하는 것들이 이미 담긴 규격 상자다. 다른 하나는 원하는 상태 한 장으로, 이것을 3개 띄우고 80번 포트로 열어 달라고 적는 것이다. 어느 서버에 배치할지, 멈추면 어떻게 살릴지, 바쁘면 몇 개로 늘릴지, 새 버전으로 어떻게 무중단 전환할지는 전부 플랫폼의 몫이다.

▲ 개발팀이 내놓을 것은 컨테이너 이미지와 원하는 상태 두 가지로 줄었다 — 배치·복구·확장·롤백을 플랫폼이 맡아 OS 와 미들웨어를 몰라도 배포가 성립한다. (발표자료 16쪽)

그 위에 얹히는 것이 골든 패스다. 앱만 올리면 배포와 관측과 보안과 네트워크의 기본값이 따라온다. 이것을 닦아 두는 이유는 인지 부하 때문이다. 모든 개발자에게 쿠버네티스와 네트워크와 보안 전문가가 되라고 요구하면 학습 자체가 병목이 된다. 경로 밖으로 나가는 것을 막지는 않되 나간 만큼은 그 팀이 직접 책임진다.

▲ 골든 패스가 등장한 이유는 인지 부하다 — 쿠버네티스·네트워크·보안을 전원이 익히게 하면 학습 자체가 병목이 된다. (발표자료 17쪽)

이 분담이 훨씬 큰 규모에서도 유지되는지 궁금하다면 Line과 Yahoo — 15명으로 쿠버네티스 4만 노드와 1,300 클러스터를 운영하는 법이 인원과 클러스터 수를 밝힌 사례로 답한다.

오늘 이야기를 네 단계로 압축하면 도입 순서가 그대로 나온다. 이 순서를 뒤집으면 실패한다.

1단계는 예전 방식이다. 서버 한 대에 앱 하나를 올려 90%를 놀리면서도 다른 앱은 못 올렸고 환경은 사람이 손으로 다시 구축했다. 2단계는 규격 채택이다. 구글이 수만 대를 사람이 못 만진다는 것을 먼저 겪고 컨테이너를 표준 규격으로 삼았다. 3단계는 설비 공유다. 각자 갖추던 설비가 공용 설비로 바뀌고 본질은 가벼움보다 몰라도 되는 범위의 확대가 된다. 4단계가 자율 운영이다. 규격과 관측과 선언이 갖춰지자 비로소 성립했다.

▲ 도입 순서를 뒤집으면 실패한다 — 규격 없이 자동화부터 시도한 과거 방식들이 무너진 자리가 정확히 이 지점이다. (발표자료 20쪽)

규격 없이 자동화부터 시도했던 과거의 방식들이 무너진 자리가 정확히 이 지점이다. 쿠버네티스 운영을 검토한다면 컨테이너 규격화가 어디까지 되어 있는지를 먼저 재고, 자동화 도구 선택은 그다음에 놓아야 한다.

컨테이너 기반 배포가 클라우드 네이티브 전환의 어느 지점에 놓이는지는 컨테이너 기반 배포와 쿠버네티스 — 클라우드 네이티브 시대로의 전환에 단계로 정리돼 있다.

쿠버네티스 운영이 만든 가장 큰 변화는 개발팀과 플랫폼 사이의 분담이 새로 그어졌다는 것이고, 그 분담은 컨테이너라는 규격 위에서만 성립한다.

순서가 위에서 아래로 흐른다는 점이 이 표의 핵심이다. 규격이 없는 상태에서 자율 운영부터 기대하면 어느 단계에서도 값을 하지 못한다.

쿠버네티스 운영이 바꾼 것을 한 문장으로 말하면 무엇인가

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

예전 서버 이용률이 10%대였던 진짜 이유는 무엇인가

성능이 아니라 격리 때문이다. 한쪽 앱의 라이브러리 버전을 바꾸면 옆 앱이 멈췄기 때문에 아예 장비를 따로 사는 편이 안전했고, 장비값과 전기료와 상면료는 이용률과 무관하게 100% 그대로 청구됐다.

구글은 왜 하필 컨테이너를 표준으로 골랐는가

한 대에 빽빽이 채우고, 고장을 전제로 설계하고, 개발자를 인프라에서 떼어내기 위해서다. 셋 다 기계가 읽을 수 있는 실행 규격이 먼저 있어야 성립하므로 구글은 컨테이너를 가벼운 가상 서버가 아니라 자동화가 시작될 수 있는 최소 규격으로 봤다.

컨테이너가 VM 보다 빠른 이유는 최적화 때문인가

아니다. 게스트 OS 한 벌이 통째로 빠졌기 때문이다. 호스트 커널 하나를 함께 쓰므로 실을 짐이 수 GB 에서 수백 MB 로 줄고 기동이 수십 초에서 수 초 이하로 내려간다.

컨테이너가 가상머신을 전부 대체할 수 있는가

대체하지 못한다. 커널을 함께 쓰는 대가로 VM 보다 격리 수준이 낮으므로 규제나 보안 요구가 강한 구간에서는 VM 과 병행하는 구성이 현실적이다. 관리 주체가 바뀐 것이지 관리가 사라진 것은 아니다.

자율 운영은 쿠버네티스를 깔면 바로 되는가

되지 않는다. 실행 규격, API 조작, 상태 관측, 원하는 상태 선언, 컨트롤러 조정 다섯 조건이 함께 갖춰져야 성립하고 하나라도 빠지면 자동화가 스크립트 수준에 머문다. 그래서 컨테이너 규격화가 먼저고 쿠버네티스가 나중이다.

도입을 검토한다면 어떤 순서로 가야 하는가

규격이 먼저이고 자동화가 그다음이다. 컨테이너 규격화가 어디까지 되어 있는지를 먼저 재고 자동화 도구 선택은 그 뒤에 놓는다. 규격 없이 자동화부터 시도했던 과거의 방식들이 무너진 자리가 정확히 이 지점이다.

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

• 쿠버네티스란 무엇인가 — 개념과 도입 이유
• 쿠버네티스의 탄생과 진화 — 구글 보그에서 AI 운영체제까지
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 Pod란? 개념과 생명주기와 멀티컨테이너 패턴
• 쿠버네티스 vs 도커 차이 완벽 정리
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유
• 쿠버네티스 작동원리부터 운영까지 — 왜 지금 알아야 하는가
• 클라우드 네이티브란? 구성 요소와 아키텍처와 전환 사례
• 가상화 vs 컨테이너 vs 클라우드 네이티브, 구조 차이로 선택하는 법
• 클라우드 네이티브 전환 효과 — 가상화보다 수십 배 빠른 부팅 속도
• 전자책 2.1.2 VM과 컨테이너 비교
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• 쿠버네티스 프로덕션 도입 사례와 운영 교훈
• AI 시대, 가상서버 대신 쿠버네티스를 선택하는 이유

쿠버네티스가 필요해진 이유와 도입 뒤 달라지는 일을 원인에서 결과로 따라간 발표자료 21장 전체를 21쪽 PDF 로 공개한다. 사내 검토 자료나 팀 스터디 자료로 자유롭게 쓸 수 있다.

아래 버튼에서 같은 PDF 를 다시 내려받을 수 있다.