쿠버네티스가 뭐길래
— 컨테이너 수십 개를 대신 돌봐주는
'오케스트라 지휘자'

안녕하세요, 멘토 김부장입니다. 오늘은 이름부터 겁나는 녀석을 데려왔어요. 바로 쿠버네티스(Kubernetes)입니다. 개발 공부하다 보면 "요즘은 쿠버네티스 정도는 알아야지"라는 말을 어디선가 한 번쯤 듣게 되죠. 그 말을 처음 들었을 때 저는 속으로 이렇게 생각했어요. "아니, 컨테이너 겨우 이해했더니 이제 또 뭐가 나와…" 하고요.

그런데 막상 뚜껑을 열어보니, 쿠버네티스는 어려운 게 아니라 양이 많은 녀석이었어요. 용어가 수십 개고, 하는 일이 워낙 많다 보니 처음엔 안개 속을 걷는 기분이 듭니다. 하지만 그 안개 뒤에 있는 핵심 아이디어는 딱 한 문장이에요. "이렇게 돌아갔으면 좋겠다고 적어두기만 하면, 알아서 그 상태로 맞춰준다." 이거 하나만 붙잡고 가면 됩니다.

이 글은 컨테이너와 도커 이야기를 먼저 읽으셨다는 전제로 쓰지만, 안 읽으셨어도 괜찮아요. 바로 아래 한 문단으로 필요한 만큼만 복습해 드릴게요. 컨테이너를 이미 아신다면 이 문단은 건너뛰셔도 됩니다.

1. 도시락 한두 개는 손으로, 그런데 수백 개라면?

컨테이너가 한두 개일 때는 참 편합니다. 터미널에 docker run 한 줄이면 프로그램이 뜨고, 문제가 생기면 제가 직접 다시 띄우면 돼요. 서버 한 대에 컨테이너 두어 개 올려두고 운영하는 정도는, 저 같은 늦깎이 개발자도 어렵지 않게 합니다.

문제는 서비스가 커지면서 시작돼요. 상상해 보세요. 사용자가 몰려서 프로그램을 10개로 복제해 돌려야 하는데, 그중 3번 컨테이너가 새벽 3시에 조용히 죽어버립니다. 누가 다시 띄우죠? 저녁엔 사람이 없어서 컨테이너를 5개만 돌려도 되는데, 아침 출근 시간엔 30개가 필요합니다. 이걸 누가 시간마다 손으로 늘렸다 줄였다 하죠? 새 버전을 배포하는데 서비스가 잠깐도 멈추면 안 됩니다. 옛날 컨테이너를 하나씩 끄고 새 것을 하나씩 켜는 이 곡예를, 누가 손으로 실수 없이 하죠?

서버도 여러 대예요. A서버, B서버, C서버가 있는데 새 컨테이너는 지금 가장 여유 있는 서버에 올려야 합니다. 어느 서버가 한가한지 매번 사람이 확인하고 배치하나요? 여기까지 오면 답은 분명해집니다. 사람이 밤새 지킬 수 없다. 자동으로 이 모든 걸 대신 해줄 "관리자"가 필요합니다.

제가 처음 이 벽에 부딪혔을 때가 생각나요. 작은 서비스가 조금씩 커지면서, 저는 어느새 밤에도 휴대폰을 머리맡에 두고 자게 됐습니다. "서버 죽었어요"라는 알림이 언제 올지 모르니까요. 주말에 가족과 밥을 먹다가도 노트북을 켜서 컨테이너를 다시 띄운 적이 한두 번이 아니었어요. 그때 선배가 한마디 하더군요. "김부장님, 그거 사람이 할 일이 아니에요. 기계가 할 일이에요." 그 말이 정확히 쿠버네티스가 존재하는 이유였습니다. 반복되고, 규칙이 분명하고, 사람이 하면 실수하고 지치는 일 — 이런 건 기계에게 맡기는 게 맞아요.

컨테이너 한 개는 악기 하나예요. 혼자서도 소리를 냅니다. 하지만 악기 수십 개가 모이면 그냥 소음이 됩니다. 각자 언제 들어오고 언제 멈출지, 누가 크게 누가 작게 연주할지를 정해주는 사람이 있어야 '음악'이 되죠. 쿠버네티스는 바로 그 오케스트라 지휘자입니다. 수십 개의 컨테이너가 제각각 놀지 않고 하나의 서비스로 아름답게 연주되도록, 밤낮없이 지휘봉을 흔들어 줍니다.

같은 그림을 다른 곳에서도 볼 수 있어요. 대형 물류창고를 떠올려 보세요. 상자(컨테이너) 몇 개는 사람이 손으로 옮기지만, 하루에 수십만 개가 들어오고 나가면 자동 분류·배치 시스템이 없으면 창고가 마비됩니다. 또는 항구를 보세요. 컨테이너(진짜 배에 싣는 그 컨테이너!)를 어느 자리에 쌓고, 어느 배에 싣고, 어느 크레인이 옮길지 배치를 관리하는 시스템이 있죠. 쿠버네티스라는 이름이 바로 여기서 왔습니다.

2. 쿠버네티스가 대체 뭔가요

한 문장으로 정리하면 이렇습니다. 쿠버네티스는 여러 대의 서버 위에서 수많은 컨테이너를 자동으로 배치하고, 죽으면 다시 살리고, 필요하면 개수를 늘렸다 줄이고, 서로 연결까지 해주는 '컨테이너 관리 자동화 도구'입니다. 이렇게 여러 컨테이너를 조율하고 관리하는 일을 어려운 말로 오케스트레이션(orchestration)이라고 부르는데, 방금 말씀드린 '오케스트라 지휘'라는 비유와 정확히 같은 뜻이에요. 지휘한다, 조율한다는 거죠.

다시 강조하지만, 쿠버네티스가 하는 일은 '지휘'입니다. 컨테이너를 직접 만들거나 포장하는 건 도커 같은 도구의 몫이에요. 쿠버네티스는 이미 포장된 컨테이너들을 받아서, 어디에 놓고 몇 개를 돌리고 문제가 생기면 어떻게 대처할지를 관리합니다. 요리사(도커)가 도시락을 싸면, 매니저(쿠버네티스)가 그 도시락을 어느 매장에 몇 개씩 배치할지 지휘하는 셈이죠.

조금 더 풀어볼게요. '오케스트레이션'이라는 말이 낯설 수 있는데, 이건 원래 음악 용어예요. 여러 악기의 소리를 하나의 곡으로 짜맞추는 편곡·지휘 작업을 뜻하죠. IT에서는 이 말을 빌려와서, 여러 개의 작은 프로그램(컨테이너)을 하나의 서비스로 조화롭게 돌아가게 조율하는 일을 오케스트레이션이라고 부릅니다. 그러니 "컨테이너 오케스트레이션 도구"라는 어려운 표현을 만나면, 마음속으로 그냥 "컨테이너 지휘 도구"라고 바꿔 읽으시면 딱 맞아요.

여기서 한 가지 안심시켜 드릴게요. 쿠버네티스는 2014년 구글이 공개한 오픈소스로 출발했습니다. 구글이 내부에서 수십억 개의 컨테이너를 돌리며 쌓은 노하우를 세상에 풀어놓은 것이라, 이미 엄청나게 검증된 기술이에요. 지금은 특정 회사 소유가 아니라 여러 기업과 커뮤니티가 함께 발전시키는, 사실상 이 분야의 표준이 됐습니다. 즉, 여러분이 배우는 시간이 헛되지 않는 안정적인 기술이라는 뜻이죠.

3. 왜 필요한가 — 사람이 하기엔 너무 벅찬 일들

쿠버네티스가 없던 시절, 아니 지금도 쿠버네티스 없이 컨테이너를 많이 돌리는 팀이 어떤 고생을 하는지 보면 필요성이 확 와닿습니다. 쿠버네티스가 자동으로 해결해 주는 대표적인 네 가지 고민을 짚어볼게요.

첫째, 자동 복구(자기치유). 컨테이너는 언제든 죽을 수 있습니다. 메모리가 부족해서, 알 수 없는 오류로, 서버 자체가 고장 나서. 사람이 지키면 "어, 죽었네" 하고 다시 띄우기까지 시간이 걸리고, 새벽이면 몇 시간씩 서비스가 멈춥니다. 쿠버네티스는 컨테이너가 죽으면 몇 초 만에 알아서 새로 띄웁니다. 마치 지휘자가 연주 중 한 악기가 멈추면 곧바로 대기 중인 연주자를 무대에 올리는 것처럼요.

둘째, 오토스케일링(자동 확장·축소). 트래픽은 파도처럼 오르내립니다. 세일 시작하면 사용자가 폭증하고, 새벽엔 한산하죠. 컨테이너 개수를 손으로 조절하면 밤에도 서버 비용을 다 내거나, 갑자기 몰릴 때 서비스가 뻗어버립니다. 쿠버네티스는 부하를 보고 컨테이너 개수를 알아서 늘렸다 줄입니다.

셋째, 무중단 배포(롤링 업데이트). 새 버전을 배포하려고 서비스를 통째로 껐다 켜면, 그동안 사용자는 오류 화면을 봅니다. 쿠버네티스는 옛 버전을 하나씩 내리고 새 버전을 하나씩 올려서, 사용자가 눈치채지 못하게 갈아끼웁니다. 문제가 생기면 이전 버전으로 되돌리는 것(롤백)도 명령 한 줄이에요.

넷째, 로드밸런싱(부하 분산). 컨테이너가 10개 있으면 들어오는 요청을 골고루 나눠줘야 합니다. 한 놈에게만 몰리면 그 컨테이너가 뻗죠. 쿠버네티스는 요청을 여러 컨테이너에 균형 있게 분배합니다. 은행 창구를 떠올려 보세요. 창구가 열 개인데 손님이 전부 1번 창구에만 줄 서면 어떻게 될까요? 1번 직원은 과로하고 나머지 아홉 명은 논다면 그 은행은 엉망입니다. 번호표 기계가 손님을 창구마다 골고루 보내주듯, 쿠버네티스도 요청을 여러 컨테이너에 나눠 보냅니다.

이 네 가지를 사람이 손으로 하려면 어떤 일이 벌어지는지, 그리고 쿠버네티스가 있을 때 어떻게 달라지는지 나란히 놓고 보면 필요성이 확 실감 나실 거예요.

4. 핵심 개념, 비유로 딱 한 번만 정리

이제 용어가 나올 차례예요. 겁먹지 마세요. 지금부터 나오는 단어들은 깊이 팔 필요 없이 "아, 이런 역할이구나" 정도만 알면 됩니다. 쿠버네티스 문서를 처음 열면 수십 개의 용어가 쏟아져서 도망치고 싶어지는데, 사실 처음에 꼭 필요한 건 아래 여섯 개뿐이에요. 나머지는 필요해질 때 하나씩 만나면 됩니다. 표로 한눈에 정리해 드릴게요. 비유(가운데 칸)를 먼저 읽고 정식 설명(오른쪽 칸)을 붙이시면 훨씬 쉽습니다.

표만 봐도 그림이 그려지시죠? 공장(클러스터) 안에 작업장(노드)이 여러 개 있고, 각 작업장에서 일감 봉투(파드)가 처리됩니다. 관제탑(컨트롤 플레인)이 "이 일감은 항상 5봉투 유지해(디플로이먼트)"라는 지시서를 보고 작업장에 배분하고, 바깥 손님은 안내데스크(서비스)를 통해 필요한 일감으로 안내받습니다. 딱 이 정도만 머리에 넣으셔도 오늘은 충분합니다.

여기서 '서비스'가 왜 필요한지 조금만 더 짚고 갈게요. 처음 이 개념을 들으면 "파드 주소로 직접 부르면 되지, 왜 굳이 안내데스크를 하나 더 두나?" 싶거든요. 이유는 파드가 언제 죽고 다시 태어날지 모르기 때문이에요. 파드는 죽었다 살아날 때마다 주소(내부 IP)가 바뀝니다. 매번 바뀌는 사람의 휴대폰 번호를 외워서 전화하려면 미치겠죠. 그래서 '서비스'라는 절대 안 바뀌는 대표 번호를 하나 두고, 그리로 전화하면 서비스가 알아서 살아 있는 파드에게 연결해 줍니다. 파드가 5개든 3개로 줄었든, 바깥에서는 그냥 대표 번호 하나만 알면 되는 거예요. 이 편리함 덕분에 여러 앱이 서로를 부를 때 주소 걱정을 하지 않아도 됩니다.

5. 전체 그림 — '원하는 상태'만 적으면 알아서 맞춰준다

쿠버네티스를 이해하는 가장 중요한 열쇠가 지금부터 나옵니다. 바로 선언형(desired state, 원하는 상태)이라는 사고방식이에요. 말은 어렵지만 개념은 정말 쉽습니다.

보통 우리는 컴퓨터에게 "이거 해, 저거 해" 하고 동작을 하나하나 명령합니다. "컨테이너 켜, 죽었으면 다시 켜, 하나 더 켜…" 이렇게요. 쿠버네티스는 반대예요. 여러분은 결과, 즉 "이런 상태였으면 좋겠다"만 선언합니다. "이 앱은 항상 5개 돌아가고 있어야 해." 그러면 쿠버네티스가 현재 상태를 계속 지켜보면서 원하는 상태와 다르면 알아서 맞춰줍니다. 지금 3개뿐이면 2개를 더 띄우고, 6개면 1개를 줄이는 식으로요.

이 과정은 한 번 하고 끝이 아니라 쉬지 않고 반복됩니다. 그래서 새벽에 컨테이너가 죽어 3개가 되면, 쿠버네티스는 다시 "어? 5개여야 하는데 3개네" 하고 2개를 채웁니다. 여러분이 지시서에 5라고 적어둔 이상, 쿠버네티스는 무슨 일이 있어도 그 상태를 지키려고 끊임없이 애씁니다. 이게 앞서 말한 '자기치유'의 정체예요.

그럼 이 '원하는 상태'는 어디에 적을까요? 보통 YAML이라는 텍스트 파일에 적습니다. 코드처럼 보이지만, 사실은 "항목: 값"을 줄줄이 적은 설정 목록에 가까워요. 아래는 아주 단순화한 예시인데, 겁먹지 말고 한글 주석만 따라 읽어보세요.

kind: Deployment  ← "나는 디플로이먼트(지시서)야"
replicas: 5  ← "이 앱을 항상 5개 유지해줘"
image: my-app:1.2  ← "이 도시락 통(컨테이너 이미지)을 써"

보이시죠? "어떻게 5개를 만들지"는 한 줄도 없습니다. 그냥 "5개였으면 좋겠어"라고 선언할 뿐이에요. 어떻게 그 상태를 만들고 유지할지는 전부 쿠버네티스의 몫입니다. 이 파일을 코드처럼 저장소에 넣어 관리하면, 인프라 전체를 문서 한 벌로 재현할 수 있게 되죠. 이 개념은 CI/CD 이야기와도 자연스럽게 이어집니다.

6. 쿠버네티스가 알아서 해주는 일들

선언형 원리를 이해했으니, 이제 쿠버네티스가 그 원리 위에서 자동으로 해주는 일들을 단계 카드로 정리해 볼게요. 앞에서 조각조각 나왔던 이야기들이 여기서 한자리에 모입니다.

이 다섯 가지가 손발을 맞춰 돌아가는 덕분에, 개발자는 "서버가 죽으면 어쩌지, 사람이 몰리면 어쩌지"를 밤새 걱정하는 대신 "우리 앱이 어떤 상태였으면 좋겠다"만 선언하고 나머지는 맡길 수 있게 됩니다. 이게 쿠버네티스가 준 진짜 자유예요.

재미있는 건, 이 다섯 가지가 전부 5번 섹션에서 말씀드린 '선언형' 원리 하나에서 파생된다는 점입니다. "5개 유지"라고 선언했으니 죽으면 채우고(자기치유), 부하 규칙을 걸어두면 알아서 개수를 조절하고(스케일링), 새 버전을 선언하면 옛것을 하나씩 새것으로 바꾸고(롤링 업데이트)… 결국 전부 "현재를 원하는 상태에 맞춘다"는 같은 동작의 다른 얼굴일 뿐이에요. 그래서 용어가 많아도 원리 하나만 잡으면 나머지가 술술 풀리는 겁니다.

7. 그럼 나도 당장 써야 하나요? — 솔직하게 말씀드릴게요

여기서 저는 유행에 휩쓸리지 말자고, 아주 솔직하게 말씀드리고 싶어요. 결론부터: 대부분의 입문자와 작은 프로젝트에는 쿠버네티스가 과합니다.

쿠버네티스는 강력하지만, 그만큼 배우고 운영하는 비용도 큽니다. 용어도 많고, 설정 파일도 여러 개고, 잘못 만지면 오히려 장애의 원인이 되기도 해요. 컨테이너 한두 개짜리 개인 프로젝트에 쿠버네티스를 얹는 건, 혼자 밥 먹으려고 대형 급식소 시스템을 들이는 격입니다. 지휘자가 아무리 훌륭해도, 연주자가 한 명이면 지휘봉이 필요 없잖아요.

제 책 「코딩 몰라도 AI로 사주앱 만들기」에서 다룬 것처럼, 개인 서비스나 소규모 앱은 EC2 한 대(월세방 하나 빌리는 셈)에 컨테이너 몇 개 올려서 충분히 잘 돌아갑니다. 관리형 서비스를 쓰면 서버 자체를 신경 안 써도 되는 선택지도 많고요. 아래 표로 "언제 필요하고 언제 불필요한지"를 정리했어요.

그러니 지금 당장 못 쓴다고 조급해하지 마세요. "이런 게 있고, 언제 필요한지 안다" — 지금은 이 정도면 100점입니다. 규모가 커져서 손이 모자라는 순간이 오면, 그때 자연스럽게 쿠버네티스를 꺼내 들면 돼요. 저도 처음엔 EC2 한 대로 시작했습니다.

도구를 고를 때 제가 늘 스스로에게 던지는 질문이 하나 있어요. "이 도구가 해결해 주는 고통을, 내가 지금 실제로 겪고 있나?" 쿠버네티스가 해결하는 고통은 '컨테이너가 너무 많아서 사람이 감당이 안 되는' 고통입니다. 그런데 아직 컨테이너가 두세 개뿐이라면, 그 고통이 없는 거예요. 없는 고통을 미리 해결하겠다고 복잡한 도구를 들이면, 도구 자체가 새로운 고통이 됩니다. 이걸 개발 바닥에서는 '오버 엔지니어링(과잉 설계)'이라고 불러요. 멋있어 보이는 기술이 아니라, 지금 내 문제에 딱 맞는 기술을 고르는 게 진짜 실력입니다. 이건 쿠버네티스뿐 아니라 모든 도구 선택에 통하는 이야기예요.

8. 관리형 쿠버네티스 — 직접 짓지 말고 빌려 쓰세요

쿠버네티스를 처음부터 직접 설치하고 운영하는 건 정말 어렵습니다. 관제탑(컨트롤 플레인)을 직접 세우고, 서버들을 엮고, 장애를 관리하는 일은 전문 팀도 버거워해요. 그래서 클라우드 회사들이 "어려운 부분은 우리가 대신 관리해 줄게" 하고 내놓은 것이 관리형 쿠버네티스 서비스입니다. 대표 삼총사만 알아두세요.

이름은 달라도 하는 일은 같아요. 골치 아픈 관제탑 운영을 클라우드가 맡아주고, 여러분은 "앱 몇 개 돌려줘"라는 지시서 작성에만 집중하면 됩니다. 그러니 쿠버네티스를 도입하더라도, 대부분은 이 관리형 서비스로 시작하게 됩니다. (각 서비스의 정확한 요금·최신 기능은 값이 자주 바뀌니, 도입 시점에 각 클라우드 공식 문서에서 확인하세요.)

비유하자면 이래요. 직접 구축은 땅을 사서 집을 처음부터 짓는 것이고, 관리형 서비스는 잘 지어진 아파트에 입주하는 것입니다. 배관이 터지거나 엘리베이터가 고장 나면 관리사무소가 알아서 고쳐주죠. 물론 아파트에도 관리비가 나가듯 관리형 서비스도 비용이 듭니다. 하지만 그 비용을 아끼겠다고 집을 직접 짓다가, 정작 여러분이 만들려던 '서비스'는 뒷전이 되기 십상이에요. 우리가 진짜 하고 싶은 일은 인프라 관리가 아니라 좋은 앱을 만드는 것이라는 점, 잊지 마세요.

한 가지 더. 이 세 서비스 중 뭘 고를지 고민되신다면, 답은 대개 "이미 쓰고 있는 클라우드를 그대로 쓴다"입니다. AWS를 쓰고 있으면 EKS, 구글 클라우드면 GKE, 애저면 AKS. 굳이 새 클라우드를 배우면서까지 갈아탈 이유는 처음엔 없어요. 손에 익은 동네에서 시작하는 게 언제나 편합니다.

9. 컨테이너·CI/CD와 어떻게 이어지나 — 큰 그림

이 시리즈를 죽 따라오신 분이라면, 이제 조각들이 하나로 맞춰질 거예요. DevOps의 큰 흐름에서 각 도구가 맡는 역할을 정리하면 이렇습니다.

도커로 앱을 도시락 통에 포장하면, CI/CD가 코드가 바뀔 때마다 그 통을 자동으로 새로 만들어 창고에 올립니다. 그리고 쿠버네티스가 그 통들을 받아 실제로 운영하죠 — 배치하고, 지키고, 확장하고, 무중단으로 갈아끼우면서요. 셋은 경쟁 상대가 아니라 한 팀입니다. 만들고(코드) → 합치고(CI) → 포장하고(도커) → 자동으로 올리고(CD) → 운영하는(쿠버네티스) 릴레이인 셈이에요.

이 시리즈에서 우리가 걸어온 길 전체가 궁금하시면 DevOps 시리즈 개요를 보시면 됩니다. 지도를 펼쳐놓고 지금 어디쯤 와 있는지 확인하는 기분이 드실 거예요.

10. 초보가 겁먹지 않게 — 딱 한 문장만 기억하세요

솔직히 쿠버네티스는 용어가 많아서 무섭게 느껴집니다. 파드, 노드, 디플로이먼트, 서비스, 인그레스, 컨피그맵… 문서를 처음 열면 외계어 사전 같아요. 저도 그랬습니다. 하지만 이 많은 용어가 결국 단 하나의 아이디어를 위한 부속품이라는 걸 알면 마음이 편해집니다.

쿠버네티스의 전부는 이 한 문장이에요. "원하는 상태를 선언하면, 알아서 그 상태로 맞춰준다." 나머지 용어는 전부 이 문장을 실현하기 위한 조연입니다.

그러니 용어 하나하나를 지금 다 외우려 하지 마세요. "5개 유지해"라고 적으면 5개를 지켜준다는 그 감각, 죽으면 알아서 살려준다는 그 안심, 이것만 몸에 익히면 됩니다. 나머지는 필요할 때 하나씩 찾아보면 저절로 채워져요. 새로운 기술 앞에서 작아지는 그 마음, 저도 잘 압니다. 하지만 오늘 이 글을 끝까지 읽으신 것만으로도 여러분은 이미 절반을 넘어오신 거예요.

공부 순서에 대해서도 한마디 보태고 싶어요. 쿠버네티스부터 파고들지 마세요. 순서가 있습니다. 먼저 컨테이너와 도커로 "앱을 통에 담아 어디서든 똑같이 돌린다"는 감각을 몸에 붙이고, 그다음 CI/CD로 "코드를 올리면 자동으로 배포된다"는 흐름을 경험해 보세요. 이 둘이 손에 익으면, 쿠버네티스는 "그 통들을 여러 대에서 굴리는 이야기"라서 훨씬 자연스럽게 받아들여집니다. 기초 없이 쿠버네티스부터 붙잡으면 용어의 파도에 휩쓸려 지치기 쉬워요. 계단은 한 칸씩 밟는 게 제일 빠릅니다.

11. 자주 묻는 질문 (FAQ)

Q. 쿠버네티스, 꼭 배워야 하나요?
A. '지금 당장'은 아닙니다. 개념과 언제 필요한지만 알아도 충분해요. 다만 회사에서 여러 서비스를 큰 규모로 운영하는 방향으로 커리어를 잡는다면, 언젠가는 만나게 될 표준 기술입니다. 조급해하지 말고, 컨테이너·CI/CD를 먼저 탄탄히 다진 뒤에 넘어오세요.

Q. 도커랑 뭐가 다른가요? 둘 중 하나만 쓰면 되나요?
A. 역할이 완전히 달라서 보통 둘 다 씁니다. 도커는 앱을 컨테이너로 만들고 포장하는 도구고, 쿠버네티스는 그렇게 포장된 컨테이너를 여러 서버에서 운영·관리하는 도구예요. 요리사와 매장 매니저의 관계라고 보시면 됩니다. 경쟁이 아니라 협업입니다.

Q. 혼자 개발하는데도 쿠버네티스가 필요할까요?
A. 대부분 필요 없습니다. 컨테이너 몇 개짜리 1인 프로젝트라면 EC2 한 대나 관리형 서비스로 충분해요. 혼자 밥 먹는데 급식소를 차릴 필요는 없죠. 규모가 커져서 손이 모자랄 때 도입해도 전혀 늦지 않습니다.

Q. YAML 파일이라는 게 코딩인가요? 저는 코딩을 잘 못하는데요.
A. 코딩이라기보다 설정 목록 작성에 가깝습니다. "항목: 값"을 줄줄이 적는 형식이라, 프로그래밍 문법을 몰라도 예시를 보고 따라 쓸 수 있어요. 처음엔 남이 만든 예시를 조금씩 고쳐 쓰는 것부터 시작하면 됩니다.

Q. 쿠버네티스를 쓰려면 서버를 직접 다 설치해야 하나요?
A. 아니요, 그러실 필요 없습니다. 직접 구축은 전문 팀도 어려워하는 일이라, 대부분 클라우드의 관리형 서비스(AWS의 EKS, 구글의 GKE, 애저의 AKS)를 씁니다. 어려운 관제탑 운영은 클라우드가 맡고, 여러분은 "앱 몇 개 돌려줘" 지시서 작성에만 집중하면 돼요.

12. 마무리 체크리스트 & 시리즈 맺음말

여기까지 오시느라 정말 고생하셨어요. 오늘 배운 걸 딱 다섯 가지로 접어드릴게요. 이것만 기억하시면 됩니다.

• ✅ 쿠버네티스 = 수많은 컨테이너를 대신 관리해주는 지휘자(오케스트레이션 도구)
• ✅ 핵심은 딱 한 문장 — "원하는 상태를 선언하면 알아서 맞춰준다"
• ✅ 자동으로 해주는 일 — 배치·자기치유·확장·무중단 배포·부하 분산
• ✅ 작은 프로젝트엔 과할 수 있다. EC2 한 대나 관리형으로 충분한 경우가 많다
• ✅ 도입하더라도 EKS·GKE·AKS 같은 관리형 서비스로 시작하자

그리고 이 글로 우리 DevOps 시리즈가 한 바퀴를 돌았습니다. 되짚어 볼까요? 우리는 코드를 만들고, 여럿의 코드를 합치고(브랜치·PR·CI), 자동으로 배포하고(CD), 앱을 도시락 통에 포장하고(컨테이너·도커), 마지막으로 그 통들을 실제로 운영하는(쿠버네티스) 큰 그림을 전부 봤습니다. 처음엔 낯선 영어 약자투성이였던 이 세계가, 이제는 하나의 흐름으로 이어져 보이시죠?

기술은 결국 사람을 편하게 하려고 나온 도구입니다. 밤새 서버를 지키던 사람의 걱정을 덜어주려고 쿠버네티스가 나왔고, 배포의 두려움을 없애려고 CI/CD가 나왔어요. 그러니 도구 앞에서 겁먹지 마세요. 여러분은 이미 그 도구들이 왜, 무엇을 위해 존재하는지를 아는 사람이 됐습니다. 그게 진짜 실력의 시작이에요. 늦게 시작한 저도 여기까지 왔으니, 여러분은 분명 더 멀리 가실 겁니다. 다음 여정에서 또 뵙겠습니다. 👍

(2026년 8월 기준 작성 — 화면·정책·요금은 바뀔 수 있으니 각 클라우드와 쿠버네티스 공식 문서를 함께 확인하세요.)

← 기술 블로그 목록으로