2023년 12월 20일, 유데미 강좌 <Docker & Kubernetes : 실전 가이드>로 글또 분들과 첫 스터디를 하고 나서 3개월이라는 시간이 흘렀다.
세 달이면 거의 한 학기나 마찬가지인 셈인데 그래도 이 기간동안 한 주제에 대해 성실히 공부하고 기록을 남겼다는 사실이 뿌듯하다.
유종의 미를 거두기 위해 회고를 남겨본다.
내가 도커와 쿠버네티스를 배우게 된 이유
지금까지 내가 해왔던 공부를 돌이켜보면 'AI나 데이터 사이언스에 관심이 있나보다'라고 생각이 들 것 같다.
그도 그럴 게 AI 관련 논문 스터디나 알고리즘 공부는 했어도, 막상 다른 분야의 기술은 쉽게 도전하지 못했었다.
글또에서 도커쿠버네티스 스터디 공고가 올라왔을 때 망설임 없이 참가한 계기는 두 가지였다.
- 데이터 엔지니어가 되고 싶다. 그런데 도커와 쿠버네티스는 현업(특히 데이터 엔지니어링과 밀접한 백엔드, 인프라, DevOps)에서 꼭 알아두어야 할 기술이라고 한다.
- 도커를 몰라서 가슴 아팠던 기억이 있다.
도커 때문에 가슴 아팠던 기억이라니?
제작년 한 스타트업에서 인턴으로 일하고 있을 때였다. 비슷한 업에 종사하는 분들은 무척 공감하시겠지만, 스타트업에선 투자금으로 돈이 부족하기 때문에 공공기관에서 과제를 열심히 수주받아 비용을 충당한다.
나도 이 과제에 투입되었고, 어찌어찌 딥러닝 모델을 하나 개발해서 모델 학습과 성능 평가까지 겨우 마친 상태였다.
하지만 마지막 단계가 하나 남아있었는데, 바로 모델 실행 환경을 도커 이미지로 빌드해서 검증 기관에 전달하는 작업이었다.
문제는 그 당시 내가 도커에 대해서 전혀 모른다는 사실이었다. 게다가 제출 마감 기한도 당장 코앞으로 다가와 있었다.
사수에게 물어보니 아주 간단한 일이라고 했다. 명령어 몇 줄만 입력하면 알아서 이미지라는 걸 만들어준단다.
지금 생각해보면 맞는 말이긴 한데...
음 쉬운 일이군, 생각해서 일단 구글링해서 나온 명령어를 복붙 실행해보았다. (참고로 이땐 챗GPT가 나오기 전이었다)
그러자 에러가 떴다. 이때부터 '어,' 이거 쉬워보이는데 왜 안되지?'라는 생각에 초조해져서 무작정 다른 명령어를 시도해봤다.
그래도 여전히 문제가 발생했다. 한숨 푹 쉬면서 쩔쩔매는 내가 안타까워 보였는지, 다행히 옆자리에 계셨던 선임 개발자 분이 시간이 남아 내 업무를 도와주신다고 했고 결국 이 분의 캐리로 고비를 넘길 수 있었다.
한편으론 아쉬운 마음이 컸다. 내가 도커를 좀 알고 있었으면 혼자서도 멋지게 해결할 수 있지 않았을까?
왜 난 혼자서도 할 줄 아는 게 없을까? 항상 내 능력을 인정받고 싶은 갈증이 컸지만 뜻대로 풀리지 않던 인턴 시절,
도커는 내게 커다란 미련 덩어리로 남았던 것 같다.
자, 각설하고 스터디 회고록으로 다시 돌아가보자. 이번 회고록은 크게 세 파트로 구분해서 작성해보았다.
- 강의: 강의는 어떠했는가? 강의에서 좋았던 부분, 아쉬웠던 점은 무엇인가?
- 그룹 스터디: 혼자가 아니라 글또 멤버 분들과 같이 스터디를 진행했다. 내가 여기서 느꼈던 점은 무엇인가?
- 나(개인)으로서의 변화: 나는 개인적으로 이 스터디 이후 어떻게 달라졌고 얼마나 성장했는가?
파트 1: 강의에 대하여
주요 특징
- 강의는 기본적으로 영어로 진행한다. 하지만 한글 자막 버전도 있기 때문에 영어 리스닝이 안돼도 무리없이 이해할 수 있다.
- 서로 다른 두 기술을 다룬다: 첫 절반까지는 도커, 그리고 후반부는 쿠버네티스에 할애해서 개념을 설명한다.
- 실습 중심이다: 간단한 웹 앱 프로젝트로 실습할 수 있는 코드를 제공한다.
장점 1: 설명이 자세하다
일단 설명이 참 자세하다. 나도 한 4주차 쯤 되어서야 느낀 건데, 강사 분이 '이건 이미 알고 있겠지'하고 휘릭 넘어가는 대신
최대한 꼼꼼하게 가르치려고 노력한다. 그리고 중요한 부분은 계속, 때로는 지겨울 정도로 강조해서 놓칠 염려가 없다.
장점 2: 실습 코드를 아낌없이 제공한다
실습을 충분히 따라갈 수 있게 코드를 버전별로 제공한다.
무슨 말이냐 하면, 1번째 강의에서 코드의 A를 수정하고 이어서 2번째 강의에선 A'로 수정했다고 하면 기존 코드 -> 1차 수정 결과(A) -> 2차 수정 결과(A')까지 모두 차례로 파일로 첨부해놓아서 쉽게 확인할 수 있다는 뜻이다.
간혹 내가 코드를 강의 보며서 따라 치다가 실수한 적이 있었는데 다행히 다음 버전 코드랑 비교해서 금방 고칠 수 있었다.
장점 3: 짧은 호흡의 강의
이건 본 강의에만 해당하는 게 아니고 유데미의 특징이기도 하다.
각 개념 별로 강의 영상을 짧게(5~10분) 쪼개놓아서, 숏츠 시대에 가뜩이나 인내심이 부족한 나같은 현대인에겐 안성맞춤인 것 같다.
강의 호흡이 짧기 때문에 하나만 완강해도 작은 성취감을 느낄 수 있고, 이걸 반복하다보면 어느새 섹션 전체를 마무리할 수 있었다.
아쉬운 점 1: 자세한데, 장황하기도 하다
내가 강의 첫번째 장점으로 설명이 자세하다고 했지만, 한편으로는 장황하다는 느낌도 받았다.
강의 들으면서도 '어, 아까 했던 얘기를 또 하네?' 라는 생각을 몇 번이나 하게 만든 순간이 있었기 때문이다.
그리고 비교적 덜 중요한 부분(웹 애플리케이션 코드를 수정하는 부분 등)은 빠르게 건너뛰고 중요한 부분(쿠버네티스의 핵심 개념)에 설명을 더 할애하면 좋을 텐데,
모든 과정을 다 꼼꼼히 설명하려고 하다보니 강의를 다 듣고 나서도 '그래서 요점이 뭐지?'하고 뒤로가기를 몇 번이나 눌렀던 적이 있다.
쿠버네티스로 주제를 한정한다면 유데미에 자타공인 1티어 강의가 있는데 바로 Mumshad Mannambeth 분의 쿠버네티스 시리즈다.
호기심에 <Kubernetes for the Absolute Beginners> 강의를 결제해서 초반부만 들어봤는데 확실히 기존에 듣던 강의(Maximilian Schwarzmüller 분)보다 설명이 간결하고 시각화 자료도 풍부하다고 느꼈다.
이 강의에서도 쿠버네티스를 설명할 때 그래프나 일러스트까지 같이 보여줬으면 이해하기 훨씬 편했을 텐데, 하는 아쉬움이 남는다.
아쉬운 점 2: 매번 똑같은 주제의 실습 프로젝트가 반복된다
이건 사실 우리 스터디장님께서 언급했던 부분이기도 하다.
실습 코드가 너무 웹 애플리케이션(유저 생성, 로그인, to-do list 작성 정도의 간단한 기능)에만 치중되어 있다보니 겉핥기로만 지나간 느낌이었다.
물론 강의 목적 자체가 도커와 쿠버네티스 개념을 전달하는 게 최우선이라 실습은 비교적 간단한 주제로 끌고 간 게 이해는 간다.
그래도 ML 기반의 앱이나 데이터 파이프라인을 구축하는 등의 프로젝트가 있었다면 더 재밌었을 것 같다. 좀 더 발전시켜서 포트폴리오 용으로 써볼 수도 있지 않았을까?
아쉬운 점 3: 최신 업데이트가 느리다
도커나 쿠버네티스 개념의 큰 틀은 변함이 없고 제공하는 코드도 대부분 잘 작동하지만 일부 강의 내용이 최신으로 업데이트되지 않아서 헷갈렸던 적이 있다.
예를 들어 AWS에서 ECS(Elastic Container Service) 설정하는 방식이나, 실습 코드에서 mongoDB를 쓰는데 버전이 오래돼서 에러가 났거나, CSI(Container Storage Interface)를 설명하면서 awsElasticBlockStore를 언급하는데 알고보니 이건 이미 deprecated된 기능이라든가 등등.
특히 나뿐만 아니라 다른 스터디 멤버 분들 중에 Arm 기반의 맥북(M1~)을 쓰는 분이 많았는데 이와 관련해서 발생할 수 있는 에러에 대해선 아무 설명이 없었던 게 아쉬웠다.
총평
전반적으로 만족한다.
다른 유데미 강의도 수강해본 내 경험에 비추어보면 Maximilian Schwarzmüller 강사 분의 딕션과 전달력이 좋은 편이고, 입문자에게 최대한 눈높이를 맞추려고 한 노력이 돋보였다.
다만 쿠버네티스를 깊게 배워보고 싶다면 아까 언급한 Mumshad Mannambeth 분의 강의도 추천한다.
나는 비록 스터디 진도 따라잡느라 버거워서 많이 듣진 못했지만, 입문자용 강의(Kubernetes for the Absolute Beginners)부터 CKA 쿠버네티스 자격증용 강의까지 있어서 도전 욕구를 불러일으키는 것 같다.
파트 2: 글또에서 첫 스터디를 경험하다
글또 9기로 합류하고 나서 다른 멤버 분들과 정기적으로 교류하는 기회는 이번이 처음이었다.
스터디하기 앞서 사실 걱정을 좀 했다. 예전에 온라인으로 초면인 분들끼리 논문 스터디를 한 적이 있었는데,
다들 퇴근해서 진 빠진 채로 스터디를 하다보니까 분위기도 축 쳐지고 끝날 때까지 어색했던 그런 기억이 있다.
반면에 이번 스터디는 끝내기 아쉽다는 생각이 들만큼 처음부터 끝까지 재밌게 할 수 있었다.
스터디장님이 워낙 긍정적인 기운으로 분위기를 캐리해주시기도 했고 몇몇 멤버 분들과 함께 끝까지 성실히 진행했기 때문이다.
Liked (좋은 점)
- 매 주마다 배운 내용을 깃허브 공동 repo에 마크다운으로 커밋해서 PR을 올린다. 강의만 듣고 온다면 대충 절반만 듣고 '완강했습니다'하고 오리발 낼 수도 있겠지만, 강의 내용을 정리하고 문서화까지 해야 한다면 말이 달라진다. 이런 강제성 덕분인지 꾸역꾸역 진도를 낼 수 있었다. 또 헷갈렸던 내용을 복습할 때 다른 멤버 분들이 올린 PR을 보면 '이걸 다른 분들은 이렇게 이해했구나' 혹은 '난 디테일에 집착했는데 이 분은 숲을 보면서 큰 그림을 이해하려고 했구나' 등 새로운 인사이트를 얻을 수 있었다.
- 스터디 미팅 때는 랜덤으로 순번을 정해서 두 명씩 돌아가며 발표를 한다. 저번주에 발표했다면 이번주에는 발표를 하지 않아도 되지만, 내 발표 순서가 언제 올지 모르기 때문에 내용 정리도 설렁설렁할 수가 없었다. 덕분에 허투로 이해하는 것 없이 매번 최선을 다해서 진도를 따라잡으려고 했던 것 같다.
Learned (배운 점)
이번 스터디를 운영하신 스터디장님께 여러모로 많은 점을 배웠다. 평일 저녁 9시면 피곤할 수도 있는데, 항상 밝은 에너지로 스터디를 이끈 게 대단하다고 생각한다. 분위기란 게 알게 모르게 그 사람의 기운이나 감정 상태를 따라간다는 사실을 잘 알고 있기 때문이다.
그리고 스터디에 진심인 모습도 인상깊었다. 매주 스터디가 끝나면 미처 참여 못한 분들을 위해 인증샷이랑 짤막한 후기를 슬랙 채널에 올리고, 스터디 도중 궁금했거나 해결 못한 문제가 있으면 깃허브 이슈에 따로 올려서 정리하기도 했다.
마지막엔 설문조사 폼까지 만들어서 스터디 피드백까지 받는 걸 보고 아 나도 스터디를 운영하면 적어도 이 정도는 해야겠구나, 새삼 나를 돌아보게 됐다.
Lacked (부족한 점)
나만 스터디에 부담을 느낀 건 아니었는지 중도에 하차하는 분들이 꽤 있었다.
첫 주차에는 스터디원들이 열 명도 넘어서 수요일 / 일요일로 나눠서 진행할 정도였는데, 점점 그 수가 줄어들더니 나중에 수요일에는 3명, 일요일도 한 2~3명 정도밖에 안 남아서 수요일로 통폐합해야 했다.
나도 만약 회사를 다니거나 수업을 듣고 프로젝트를 하면서 이 도커 쿠버네티스 스터디를 참여했다면 정말 밤잠을 줄여야 했을 것이다.
그만큼 생각보다 시간이 오래 걸리고 온전히 이해하기까지 공을 꽤 많이 들여야 했다는 뜻이다.
한편으론 일부 멤버들만 완주에 성공하고 모두가 그 성취감을 누리지 못했다는 사실이 아쉽긴 하다.
Longed for (바라는 점, 개선할 점)
하지만 결국 이 방식이 최선이 아니었을까? 하는 생각도 든다.
예를 들어 중도 하차를 막기 위해 결석하면 벌금을 내거나 예치금에서 차감하는 방식을 도입했다면,
일시적으로 참여를 강제할 순 있어도 자발적인 동기 부여를 하기는 어려웠을 것이다.
그리고 이렇게 하면 오히려 일부 사람들이 (강제로 돈을 잃었다는 생각에) 불만을 품어서 분위기가 안 좋아졌을 수도 있다.
한 가지 덧붙이자면, 이번 스터디를 통해서 많이 배웠고 다 너무 좋은 분들을 만나서 다른 주제로 스터디를 하거나 사이드 프로젝트를 연장선 상에서 해보면 어떨까 하는 기대를 살짝 해본다. 🫠
파트 3: 나는 스터디를 통해 성장했는가?
Keep: 참 잘했어요
배우고 싶은 건 참 많은데, 뭐든 시작만 해보고 건드리다가 흐지부지하던 나였다.
이번 스터디에서 3개월이라는 시간동안 한 주제를 끈덕지게 붙잡고 늘어져서 결국 완강을 했다는 사실이 대견하다.
그것도 어느 특정 기간에만 몰아서 한 게 아니라 매주, 꾸준히 말이다.
덤으로 얻은 것도 있다. 매주 공부 기록을 PR로 올리고 수정한 덕분에 내 깃허브 잔디도 푸르러졌다.
내가 성실히 스터디에 참여했다는 걸 포트폴리오에 입증할 증거도 생겼다(깃허브 리포).
하지만 무엇보다도 자신감이 생겼다. 내가 도입부에서 얘기했던 스타트업 인턴 시절로 돌아간다면, 이제는 잘 해결할 수 있을까?
그것쯤이야 하고 코웃음을 치면서 뚝딱 처리할 수 있을 것 같다(
...과연?
).
적어도 그런 자신감은 생겼다고 말할 수 있다.
설령 몇 차례 명령어를 잘못 입력하거나 에러를 일으켜도 잘못된 부분을 금방 찾아내서 고칠 수 있지 않을까.
이제는 도커가 돌아가는 작동 방식을 온전히 이해하고 있기 때문이다.
Problem: 이건 좀 고치자
미루고 미루다가 마감 기한이 다가오면 그제서야 시작하는 게 정말 문제다.
초반에는 그래도 의욕이 앞서서 주말 전에도 끝낸 적이 몇 번 있었지만, 후반부에는 여지없이 수요일 스터디 직전에도 PR을 허겁지겁 올리고 있었다.
이 정도면 거의 중력의 법칙 수준이다. 매주 수요일 스터디가 끝나면 '아 끝났다~' 하고 안도의 한숨을 쉬고 목, 금, 토, 일요일까지 딴 공부를 하거나 놀다가 월요일이 돼서야 슬슬 걱정이 돼서 공부를 시작하는 패턴이 이어졌다.
그리고 좀 비효율적으로 시간을 쓴 게 아쉽다.
PR 내용을 더 꼼꼼하게 다듬고 싶은 욕심에 시간을 너무 많이 쓴 나머지 다른 할일을 못 끝낼 뻔한 적도 몇 번 있었다.
가용 시간이 제한되어 있다면, 선택과 집중을 해서 주요 개념만 이해하고 넘어가면 되는데 디테일에 집착을 한 내 잘못이었다.
Try: 그래서 내 액션 아이템은?
- 모각강을 적극적으로 하자: 다음에 또 스터디를 한다면 내가 자발적으로라도 모각강을 열어야겠다. 예를 들어 스터디 당일이 수요일이면, 금요일이나 일요일 쯤 모각강을 열어서 참여하면 강제로라도 미리 진도를 나갈 수 있다.
- 시간을 측정하자: 내가 스터디에 투자할 시간을 미리 정해놓고 그 시간이 지나면 다른 작업으로 넘어가는 식으로 시간 배분을 해야겠다. 만약에 시간을 초과한다면? 그땐 스터디랑 다른 할일의 우선순위를 따져서 정말 중요한 것부터 끝내는 식으로 진행해보려고 한다.
- 도커&쿠버네티스 기반의 사이드 프로젝트: 이게 가장 어려운 액션 아이템이다. 그만큼 시간도 잘 배분해야 하고 긴 호흡으로 스스로 동기부여도 해야 하기 때문이다. 그나마 학습자료가 풍부하고 목표도 구체적인 자격증 취득에 초점을 맞출지, 아니면 리스크는 크지만 그만큼 가치도 큰 개발 프로젝트로 갈지는 아직 고민 중이다.
'회고록 > 글또' 카테고리의 다른 글
| 글또 10기를 시작하며: 회고와 다짐 (0) | 2024.10.13 |
|---|---|
| [글또 글쓰기 세미나 회고] 나만의 글쓰기 프로세스 2024 (0) | 2024.02.04 |
