【한글자막】 Docker & Kubernetes : 실전 가이드(이하 <도쿠 실전 가이드>)
왜 해당 강의를 선택했는가
사실 프론트엔드 개발자로서 <도쿠 실전 가이드> 강의를 듣고 있다고 말했을 때, 다들 동일한 반응이었다. '프론트엔드도 도커, 쿠버네티스를 많이 활용하나요?' 그럴 때마다 '그렇진 않아요. 😅'라고 답을 드렸었다. 그저 지난번에 클라우드 교육을 수강한 후 잠시 도커 이미지를 배포한 경험이 있었는데, 그때 도커를 왜 쓰는지 납득이 되지 않은 답답함을 해소하기 위해 강의를 선택했다고 말하고 싶다. 그래서 혹시나 '프론트엔드 개발자도 도커와 쿠버네티스를 공부해야 하는가'라는 위기감을 들고 이 글을 읽고 있다면, 그건 기우라고 말씀드리고 싶다.
필자는 AWS, Azure와 같은 클라우드 서비스를 사용하면서 알음알음 들었던 키워드들에 대해 그저 호기심이 생겨서 해당 강의를 선택했고, 오히려 <도쿠 실전 가이드>는 프론트엔드 내지 풀스택 개발자와 상성이 괜찮은 강의라고 생각이 들었다. 그 이유는 강사님에 있는데, 유데미에서 React, JavaScript 강의를 찾아본 적이 있는 사람이라면 한 번쯤 들어봤을 법한 'Maximilian Schwarzmüller(aka. Academind)'이다.
위 캡처에서 첫 번째 강의를 들은 기억이 있는데 <도쿠 실전 가이드>의 첫 강의에서 익숙한 목소리를 들으니 왠지 모르는 안정감이 생겼었다. 아무튼 해당 강사님은 웹 개발을 기반으로 DevOps 전문가 자격증도 취득한 강사이다. 강의 목록을 살짝 보면, 도커와 쿠버네티스로 배포하는 애플리케이션은 웹 애플리케이션이다. 그래서 React, Express에 대해 이해하고 있다면 어느 정도 유리하다고 볼 수 있다. 물론 해당 라이브러리의 지식이 해당 강의에서 중요한 비중을 차지하는 것은 아니다, 강사님이 친절하게 설명을 해주기 때문이다.
혹시나 도쿠, 쿠버네티스에 대해 일말의 관심이 있는 비 인프라 개발자라면 본 수강 후기를 통해 강의 선택에 도움이 되길 바라면서 후기를 시작하겠다.
공부하는 방법
<도쿠 실전 가이드>는 200개가 넘는 강의, 23시간 24분의 어마어마한 분량을 자랑한다. 이런 분량 때문이라도 해당 강의를 구입하는데 망설이고 있는 예비 수강생들이 분명히 있을 것이다. 필자 또한 순전히 궁금해서 일단 신청했지만, 과연 혼자서 이걸 다 수강할 수 있을까 걱정이 됐다.
그리하여 스터디의 필요성을 간절히 느꼈다. 혹시나 강의를 수강하고자 하는데, 어떻게 공부해야 할 지 모르겠다면 후술할 스터디 경험 및 팁을 바탕으로 원하는 방식을 찾길 바란다!
1. 스터디 모집하기
막상 스터디를 해야겠다고 마음 먹었지만, 도커&쿠버네티스 둘 다 모르는데 과연 스터디를 운영해도 되는 것일까, 걱정을 많이 했다. 인원수는 둘째치고, 어찌 됐든 두 가지를 학습하고 싶어 모이신 분들에게 도움이 되고자 관련 지식을 전해야 하는데, 그럴 자신이 없었기 때문이다.
그래서 필자가 잘할 수 있는 것들로 스터디 참여에 도움이 되도록 채워나갔다. 우선 강의 섹션을 바탕으로 커리큘럼을 짜기 시작했다. J로서 이때부터 신났던 것 같다.
편성된 커리큘럼을 바탕으로 강의 내용을 전부 긁어모아 노션 데이터베이스를 만들었다. 강의 키워드 자체가 생소한 분들이 많을 것으로 생각했고, 대부분 강의를 수강할 때 메모할 것으로 생각했기 때문이다. 이 과정도 단순한 노가다가 아니라 크롤링, pandas가 가미되었는데, 기회가 되면 관련된 크롬 익스텐션을 만들어 보고 싶다. 세미 자동화 기법이라고 말하고 싶은데, 혹시나 과정이 궁금하다면 댓글 남겨주길 바란다! 또한 아래 첨부한 템플릿 링크는 마음껏 복사해서 입맛대로 사용하길 바란다. 강의 메모는 물론 진도율 확인, 섹션 별 보기가 가능하도록 구성했다.
이후 스터디 공고를 올린 후, 스터디원이 오길 기다렸고, 생각보다 많은 인원인 24명으로 모집 마감을 했다. 사실 스터디 기간도 14주라 부담이 커 이렇게까지 많이 모일 줄 몰라서 인원 제한을 두진 않았는데, 당시 다소 당황했다. 그래서 이 많은 인원을 어떻게 이끌 수 있을지 고민을 한 뒤 스터디 운영 방식 공지 및 OT를 준비했다.
2. 스터디 룰 정하기
스무 명이 넘는 스터디원이 주중 동일한 시각에 모이는 것은 쉽지 않다. 그래서 주 2회 스터디 모임을 제안했고, 둘 중 참여가 가능한 시간에 자유롭게 참여하는 것을 규칙으로 정했다. 물론 스터디장으로서 매주 두 번씩 중복으로 참여했었다. 이 방식은 마지막 한 달 차에 추후 변경이 되는데, 자세한 사항과 이유는 바로 다음 장에서 이야기한다.
OT 공지 전, OT 참석 불가자에게는 원하는 스터디 운영 방식에 대한 의견을 받고, OT 때는 각자 가능한 요일에 대한 투표, 스터디 운영 방식에 대한 추가적인 의견을 받아 그라운드 룰을 정했다.
이 또한 혼자 정하는 것이 마음 편하겠지마는, 사실 많은 사람들의 의견, 특히나 스터디에 적극적으로 참여하고자 하는 스터디원의 의견을 듣고, 반영하는 것이 장기적으로 봤을 때 더 효과적이다. 비록 나의 관리 부담이 커질지라도, 결국엔 다른 사람들과 함께하는 활동이기 때문에 최대한 많은 사람의 욕구를 만족하는 것이 스터디 전체의 만족도를 올릴 수 있는 길이기 때문이다.
더 자세한 룰과 운영 기록에 대한 것은 스터디 레포지토리를 참고바란다.
3. 스터디 운영하기
이제 장장 14주 간의 여정이 시작됐다. 매주 스터디 모임을 진행하면서, 스터디장으로서는 전부가 아니더라도 최대한 많은 인원이 원하는 목표를 달성하도록 도움이 되어야겠다는 다짐을 잃지 않았다. 그래서 스터디가 끝날 때마다 인증샷과 개별 후기를 남겼다.
스터디 참여자에게는 뿌듯함을, 스터디 불참자에게도 격려를 줄 수 있다. 1시간의 스터디 종료 후 참여한 스터디원들이 어떤 활약을 했는지 명시하여, 보람을 느끼도록 했다. 그리고 불참한 스터디원들이더라도 이번 회차 스터디 때 어떤 활동을 했는지 확인하도록 하여, 실질적인 스터디가 이뤄지고 있는 것을 알리는 것과 동시에 참여 암시적으로 격려했다.
이렇게 스터디원들이 학습에 집중하도록 주변 환경을 만들기 위해 노력했다. 물론 이러한 노력이 유난으로 보일 수도 있겠지마는, 아무래도 긴 강의인 만큼 끝까지 함께하고 싶은 마음이 컸기 때문에 최선을 다하려고 했다.
4. 스터디 마무리
아무쪼록 한 주간의 방학 및 회고를 포함하여 지난 4월 3일을 기점으로 15주간의 스터디가 마무리됐다.
처음 시작한 인원 그대로 마무리를 하진 못했지만, 많은 스터디원분께서 열심히 활동해 준 덕분에 총 108개의 PR이란 기록을 남겼고, 6명의 만족도 조사에 의하면 전부 80% 이상 수강한 것을 확인할 수 있었다.
수강 후기 글이지만 스터디에 대한 이야기가 더 많은 것은 스터디가 없었으면 강의를 완강할 수 없을 것이기 때문이다. 이런 장기 스터디는 처음이지만, 그만큼 혼자라면 할 수 없을 것 같았던 <도쿠 실전 가이드>였다. 그래서 혹여나 해당 강의를 분량 때문에 고민 중인 예비 수강생이 있다면 스터디를 운영하는 것을 적극 추천한다.
이렇게 장기 스터디에서 무엇보다 가장 대단한 건 필자보다 스터디에 참여해 주신 스터디원분이다. 함께 하고자 하는 마음 하나 전해준 것으로 시작해 이렇게 아름다운 마무리를 할 수 있음에 감사하다! 글또를 통해서 함께하는 것의 힘을 배우고 있다.
도움이 된 점
도커, 쿠버네티스에 대한 두려움 타파
격리, stateless, container 등과 같은 도커와 쿠버네티스의 핵심 철학이 처음부터 등장하는데, 이러한 특성에 대해 여러 개념 및 실습으로 반복함으로써 도커와 쿠버네티스에 대한 두려움을 타파할 수 있었다. 강의를 듣기 전에는 마냥 도커는 배포할 때 어려운 친구, 쿠버네티스는 많은 것을 오케스트레이션 하기 때문에 그만큼 다양한 범위의 개념을 알아야 하는 어려운 친구로만 알고 있었다. 실습을 하면서 배포가 되는 것을 확인하면서, '생각보다 그렇게 어렵지 않네'라는 생각이 자연스럽게 들었다.
단도직입적으로 말하면 질릴 만큼 실습이 많다! 그래서 혹시나 개념에 대한 깊이 있는 이해를 원하거나, 실습하는 것이 귀찮거나 비용 문제를 맞닥뜨리기 싫다면 실습 강의가 지루할 수도 있을 것 같다.
따라서 도커와 쿠버네티스는 그렇게 무서운 친구가 아닌 것을 깨닫지만, 잊지 말아야 할 것은 진짜 무서운 친구는 AWS라는 점이다.
AWS의 ECS나 EKS를 이용할 때 실습이 끝난 뒤, 까먹고 리소스를 하나라도 지우지 않았다면, 요금 폭탄이 기다리고 있다. 강의에서도 경고하지만... 나는 까먹고 NAT Gateway를 남겨놓았고, 정작 EKS없는 네트워크 리소스에 대한 비용이 부과됐었다.
웹 애플리케이션을 도커/EKS에 배포
아무래도 강사님이 웹 개발을 주로 하셨던 분이라, 실습이 대체로 웹 개발, 특히 React, NodeJS였다. 그래서 코드와 작동 방식이 익숙했기 때문에 배포하는 것에서도 큰 문제는 없었다. React와 NodeJS를 처음 접하는 사람이라면 아무래도 애플리케이션을 빌드하는 과정과 이를 위한 명령어가 생소하여 이를 이해하는 시간이 별도로 필요할 것 같다. 그래도 코드상의 변경 사항이 있다면 그때마다 스냅샷 코드를 강의 첨부 자료로 남겨주었기에, 코드에 대한 이해가 100% 되지 않더라도, 강의를 수강하며 실습을 하기에는 큰 문제가 없다고 생각한다.
그래도 필자 관점에서는 꽤나 익숙하게 느껴져서 이 점을 도움이 된 점이라고 뽑았다. 이를 통해 추후 다른 React 프로젝트나 NextJS 프로젝트도 한 번 Docker image로 배포를 해볼까 생각하고 있다.
아쉬운 점
지연된 강의자료 업데이트
강의 업데이트가 23년 8월이라고 명시되어 있어서, 최신 정보 내지는 정오 정정으로 업데이트되었다고 생각했었다.
그러나 <도쿠 실전 가이드>는 도커, 쿠버네티스는 물론 NodeJS, MongoDB를 사용하기 때문에 모든 기술 스택에 대한 업데이트는 되지 않은 점을 확인할 수 있었다. 대표적인 예로 현재 Node LTS는 20인데, 강의에서는 14를 사용한다.
이 부분이 정말 치명적인 아쉬운 점이라고 생각한다. 왜냐하면 실습을 하면서 에러가 날 때 해당 문제가 개인 환경 문제 때문인지, deprecated 된 코드를 사용하기 때문인지 파악하기가 어려워지고, 에러가 나면 실습하는 열정이 급격하게 떨어지기 때문이다.
더불어 실습을 위해 제공되는 코드에서 틀린 지점이 있는 것 또한 업데이트되어 있지 않아 가끔 생각보다 강의를 마무리하기까지 오래 걸린 적이 있었다.
따라서 이런 부분에 대해 섬세하게 느끼는 예비 수강생들에게는 좀 더 최신 강의인 【한글자막】 초보자를 위한 Docker 실습 - 데브옵스 (DevOps)를 추천한다. (스터디원분께서 추천해 주신 강의인데, 개념적인 측면에서 도식화가 더 잘 되어 있어 이해하기 쉬웠다는 평을 남겨주셨다)
한정된 프레임워크에 대한 실습
이 부분은 도움이 된 점 중 두 번째에 대한 사이드 이팩트라고 말할 수 있다. 웹 애플리케이션을 위주로 실습을 다루다 보니 다른 AI, 데이터 분석 또는 batch 작업 등에 쓰일 만한 기술 스택 및 프레임워크는 다루지 않는다. 스터디 중에서는 이런 부분에 대한 니즈가 더 많았기 때문에 더욱 아쉬움을 공유해주셨었다.
따라서 다양한 애플리케이션에 대한 실습을 원한다면 <도쿠 실전 가이드>는 적절하지 않다고 말씀드리고 싶다.
누구에게 추천하는가
⭕️ 도커와 쿠버네티스가 중요하다고 알고 있어서 한 번쯤 찍먹해보고 싶은 사람
⭕️ 도커와 쿠버네티스의 환경 설정부터 시작해서 실습을 다수 진행해 보고 싶은 사람
⭕️ 웹 애플리케이션의 도커화, 쿠버네티스 실습을 진행해 보고 싶은 사람
❌ 클라우드 서비스를 사용해 본 적이 없는 사람
(ECS, EKS 실습 시 관련 개념에 대한 이해가 필요하다)
❌ mac M1을 개발 컴퓨터로 사용하는 사람
(M1과 docker의 비호환 이슈가 많기 때문인데, 이에 대한 자세한 해결 방법이 강의 내에서의 언급이 부족하다)
❌ 다양한 애플리케이션에 대한 도커, 쿠버네티스 활용 사례를 알고 싶은 사람
【한글자막】 Docker & Kubernetes : 실전 가이드를 수강하기 전 고민하는 분들에게 도움이 됐으면 합니다.
해당 콘텐츠는 유데미로부터 강의 쿠폰을 제공받아 작성되었습니다.
#유데미 #온라인강의 #인프라 #도커 #쿠버네티스
솔직하고 유용한 강의 후기도 좋았지만, 스터디 운영을 하기 위해 채정 님이 치열하게 고민했던 흔적을 볼 수 있어 인상 깊었습니다 :) 스터디에 참여했던 팀원으로서 스터디장 님의 헌신적인 노고에 다시 한번 감사한 마음입니다 🤗 다음 글도 기대하겠습니다!