오늘은 구름에서 운영하는 쿠버네티스 전문가 양성과정의 네 달 중에 두 달이 지나가는 시점이다. 또한, 이론과정이 마무리되는 날이기도 하다. 스스로의 성장을 되돌아보면서 반성하고, 격려하며, 성장하기 위해 글을 작성한다. 혹 같은 과정에 지원하기를 고민하는 분들이 계시다면 도움이 되면 좋을 것 같다.
시작 전
우선 시작 전의 내 상황을 떠올려보았다.
기술
- 전공여부 : 비전공
- 경력 : 프론트엔드 개발 1년
- 기술스택
- 프론트엔드 : React, JavaScript
- 백엔드 : Django, Python
- 인프라 : AWS S3, CloudFront, Route53, Amplify
우선 나는 비전공으로 부트캠프를 거쳐 1년 정도 학습하여 프론트엔드 개발자로 1년을 근무했다. 회사 상황에 맞춰 Django 코드를 학습하여 급한 경우 조금 고치는 수준이었다. 인프라는 정말 구글링하여 찾은 내용으로 굴러가기만 하면 다행인 상태로 운영했다.
지원이유
프론트엔드 개발자로서의 고도화보다는 팀 전체에 유기성을 부여하는 팀원이 되고 싶었다. 속해 있던 팀, 개인적인 프로젝트에 있어서 비용이 최적화되고 운영이 자동화되어야 반복적인 시도가 시스템으로 자리잡을 수 있다는 것을 경험했다. 도커와 컨테이너에 대한 막연한 용어만 들어본 상태에서 벗어나 각 시도마다의 비용을 측정할 수 있는 개발자를 목표로 했다.
과정 중
과정과 관련하여서는 교육, 학습, 교육지원으로 나누어 생각해보았다.
교육
- 시간 : 오전 10시 - 오후 7시
- 장소 : 온라인 교육
- 방식
- 인프런 강좌 활용
- 학습 단위 별 복습과제(Docker, Kubernetes, AWS, CI/CD(Terraform, Ansible, Jenkins))
- 내용
- 리눅스
- 컴퓨터 네트워크
- 웹 서비스 구축(Spring)
- Docker (+ Docker-compose)
- Kubernetes(+ GKE, CI/CD)
- AWS 기초
- AWS 심화
- Terraform
- Jenkins
- (+ CKA)
위 교육 내용이 두 달간 진행 된 이론과정의 교육 내용이다. 개인적으로 알고 있다고 할만한 내용은 예시용으로 쓰인 React나 Flask 웹 앱, AWS의 기초 정도이고, 나머지 내용은 전부 처음 접하는 내용이었다.
강의 나름이긴 하겠지만 두 달에 강의 한 두개도 버거웠던 나에게 9개는 많다 못해 무지막지했다. 아주 초반에 진행하던 사이드 프로젝트를 취소해야 가까스로 일정을 맞출 수 있었다. 게다가 복습과제 기한을 맞추려고 하니 늦은 시간까지 학습해야 하는 경우도 더러 있었다. 대체로 오후 9시-10시 정도까지 학습했던 것 같다.
게다가 쿠버네티스 전문가 과정이지, 쿠버네티스 환경 개발 전문가 과정이 아닌점을 인지하지 못했다. 때문에 웹 어플리케이션 구축에 대한 내용은 개별적으로 학습할 필요가 있었다.
팀 활동
- 시간 : 자율 / 매일 1-2시간
- 장소 : 구름유니버스(메타버스)
- 방식 : 자유 상호 질의 및 과제 진행상황 공유
본 과정 내에 공식적인 스터디 조가 존재한다. 조는 과정 초에 자율 결성기간을 주고, 남은 인원을 랜덤배정하는 형태이다. 대략 3-5인 정도의 조가 결성되며 14-16시를 스터디 권장시간으로 공지했다.
우리 스터디는 매일 시간을 지켜서 진행으며, 주로 교육 과정을 따라가며 매일 강의 분량을 정하거나 과제에서 어려운 점을 공유하는 방식으로 진행했다.
교육지원
- 교육환경 및 관리
- 관리자
- 구름EXP
- 구름스페이스
- 줌 강의실
- K-Digital Training 페이지
- 노션페이지
- 슬랙 채널
- 교육코칭
- 코치
- 오피스아워
교육환경은 출결 및 학습과정의 운영을 관리하는 담당자분들과, 학습 동기를 제공하고 커뮤니티 성격을 띈 EXP, 메타버스인 구름스페이스 정도로 구성되어 있다. 그리고 줌 강의실을 통해 출결 및 과정 전체 행사를 진행하는 형태이다. 기본적으로는 10시부터 7시까지 줌 강의실에 참석 하는 것이 필수적이며, K-Digital Tarining 페이지를 통해, HRD-NET 출결을 진행한다. 노션페이지와 슬랙채널까지 포함하여 대체로 과정 내 사용하는 창구가 다소 많다는 느낌이었다.
교육 코칭은 현업 전문가분께서 주마다 신청한 스터디 조에 한해서 멘토링을 진행한다. 대체로 과제에 대한 내용을 공유하거나, 코치분이 따로 지정해준 스터디 과제를 리뷰하는 방식이었다.
느낀 점
좋았던 점
1. 다양한 학습 내용
얕더라도 쿠버네티스 환경을 이해하고, 인프라 구축을 접해볼 수 있는 내용이었다. 백엔드-도커-쿠버네티스-클라우드 인프라까지 시야가 많이 트였으며, 향후 프로젝트에도 다양하게 접목해볼 수 있는 내용이 많았다.
강의도 나름 각 파트별 기초 과정을 잘 정리한 강의로 선정한 것 같았으며, 그것을 일단락하는 과제를 선정함으로써 완벽을 추구하지 않고 다음으로 넘어갈 수 있게 설계되었다고 느꼈다.
2. 강의, 클라우드 사용료, 관련 자격증 응시료 등 지원
큰 고민 없이 무료로 지원되는 부분이 많았다. 때문에, 학습하는 과정에서 빠르게 시도하고 수정하기 원활하였다. 예를 들면, 과정 초기에 강의와 도서가 지급된 편이라 스터디 내에서도 비교적 초반에 여러 학습 방식을 시도했다.
클라우드 사용료도 구름 측에서 일정 부분 지원해준다는 공지가 있어, 인스턴스 하나 생성하면서 벌벌 떨 필요가 없었다. GCP 크레딧의 영향도 있었지만, 쿠버네티스 클러스터도 많이 만들고 지울 수 있는 경험은 앞으로도 흔치 않을 것이다.
CKA나 AWS 관련 자격증 응시료도 지원(기간 내 합격 시)해주기 때문에, 스터디에서 보다 구체적인 목표를 잡고 진행할 수 있었다. 쉬엄쉬엄 하고 싶었던 적도 더러 있었지만, 의욕을 되찾는데 적지 않은 부분이었다.
3. 학습에 열의가 있는 스터디 조
과정이 다소 심화된 내용이어서 그런지, 스터디 조원분들의 덕을 많이 봤다. 스프링 강의부터 정신이 나갔던 터라 항상 뒤따라가는 입장이었는데, Best Practice를 만들어서 노션페이지에 공유해주신 조원분들과, 적절히 따라올 수 있도록 강의 분량을 조절해주는 조의 운영방식 덕분에 비교적 꾸준히 학습할 수 있었다.
취업 준비를 겸하는 입장이라 서로 응원도 되고, 정보도 주고 받을 수 있는 좋은 동료들이었다. 사주에 9-10월이 엄청 좋다고 했는데, 진짜였다.
아쉬운 점
1. 다소 어중간한 교육목표
오리엔테이션 때 쿠버네티스 전문가 과정이지만, 웹 어플리케이션에 대한 지식을 필요로 한다는 말씀이 있었다. 덕분에 과정 자체에는 Spring 기초 강의가 하나 끼어있지만, 향후 프로젝트에서는 웹 앱 프로젝트를 개발해야하는 상황이다.
개발 경험이 이미 있는 경우에는 가능할 수 있지만, 광고한 내용 대로라면 비전공에 무 경험자도 지원할 수 있을 것으로 보여 과연 가능할지는 의문이다.
압축하여 성장한 것을 장점으로 꼽았으나, 기간과 과정의 조율은 반드시 필요하다고 생각한다. 프로젝트의 성격을 바꾸더라도 어중간한 웹 어플리케이션 내용을 제외하고 배포용 웹 앱 코드를 제공하는게 어떨까 싶다.
2. 과정 내 커뮤니티 운영
과정 내 커뮤니티는 전혀 없다. 대부분을 자율로 두고 있으며, 줌에 접속하여 마이크도 끈 상태로 있다 하더라도 소통할 일이 없었다. 15-16명 정도로 시작한 과정이 현재는 8~10명 정도로 줄어든 것으로 보이는데, 누가 왜 나갔는지, 나간건지 만건지 조차 알 길이 없다. 구름 측에서 커뮤니케이션을 강조했던 터라 많이 당혹스러운 부분이다.
거의 모든 부분을 자율로 권장한 터라, 출결 외에는 별다른 관리도 없는 것 같았다. K-Digital Training 과정이 각자 한번 뿐이기 때문에, 관리되는 환경에서 학습하고자 들어오시는 분들이라면 다른 과정을 선택하시길 권한다.
내가 경험한 다른 부트캠프에서는 다소 불편하게 느껴질 수 있지만, 메타버스에 접속하여 조별로 모여 있는 환경을 만들었다. 덕분에 메타버스에 시큰둥했던 나도 상당한 몰입감으로 과정을 마쳤던 기억이 있다. 그 과정에서도 모토는 자율학습이었지만 말이다.
3. 강의 간 유기성
아무래도 인프런에서 강의를 몇 가지 골라 구성한 커리큘럼이라 각 강의의 퀄리티가 좋더라도, 유기성이 떨어질 수 밖에 없다. 덕분에 React, NodeJs, Flask, Spring을 모두 맛보는 엄청난 커리큘럼이 되어버렸다. 물론 아주 얕은 수준이라 상관 없는 분들도 많겠지만, 오류가 발생하면 원인을 규명하기 어렵다는 점에서 결코 작은 문제는 아니라고 생각한다.
위에서 얘기한 것처럼 비교적 모두가 활용하기 쉬운 Flask로 코드를 통일해서 Best Practice를 배포하거나 웹 앱 개발 부분 자체를 제외하는 것이 방법인 것 같다.
마무리
반의 만족
