6개월 반이라는 기간이 벌써 지나가고 구름톤 트레이닝 풀스택 과정을 수료하게 되었다. 나는 11월부터 6월까지 수강한 4회차 수료생이고 이후 회차에서는 변경사항이 생길 수 있겠지만, 그럼에도 이 과정을 고민중인 사람들에게 전반적인 교육과정에 대한 후기가 도움이 되길 바라며 적는다.
물론 개인적인 회고의 목적도 있다. 어쩌다보니 끝에 개인 회고를 더 길게 적어버렸는데 알아서 걸러 듣자.
기본적으로 제공되는 강의나 진행 방식은 다른 후기에도 많이 올라와있기 때문에 생략하고 내가 느낌 장단점 위주로 포스팅 해보겠다.
구름톤 트레이닝 풀스택 후기
이 교육과정은 호불호가 명확하게 갈릴만한 코스이다. 왜냐하면 처음부터 끝까지 자기주도 학습으로 진행되기 때문이다. 과제를 던져주고 중간중간 오피스아워로 코치님들이 과제 풀이를 해주시길 하지만 강제는 아니다. 자유롭게 방목해놓고 알아서 공부하라는 식이다. 그렇기 때문에 의지박약이거나 내적 동기가 약한 사람들은 추천하지 않는다. 추천하는 사람은 나처럼 다른 사람이 터치하는 거 싫어하는 반골들, 자기만의 확고한 공부관이 있고 어느 정도의 의지가 탑재된 사람들이다.
실제로 4회차 사람들과 요모조모 대화해볼 일이 많이 있었는데, 내 예상보다 다들 힘겹게 따라가고 있었다. 그리고 이러한 파격적인 교육 정책에 많은 이들이 초반에 방황하거나 포기하기도 한다. 그러지 않기 위해서 우선 나의 성향과 구름이 정말 잘 맞는지 고민해보고, 하기로 했다면 마음을 먹고 정신을 바짝 차리고 시작하길 권한다.
제공되는 커리큘럼을 100% 따라가는 것은 당연히 불가능하다. (커리큘럼은 그냥 정말 참고사항일 뿐, 따라가려고 시도하지 않는 것이 몸과 마음에 좋다)
이름에 풀스택이 있다고 해서 정말 풀스택을 공부할 생각은 하지 않는게 좋다. 내가 가장 추천하는 것은 초반에 백/프론트를 정해서 나름의 커리큘럼을 정하는 것이다. 베이스가 짱짱한 사람이 아니라면 HTML, CSS, JS, Type Script, React를 다 떼고 나서 Java, 스프링, 스프링부트, DB기술, JPA를 다 뗀다는 건 님이 월~일 매일 12시간씩 하지 않는 이상 불가능하기 때문이다. 풀스택을 하고 싶다면 node를 공부해라. 스프링 하나만 하기에도 전공 하나 분량이다.
그리고 스터디에 적극 참여하는 것이 좋다. 구름에서 공부를 지속할 수 있는 외부 원동력은 스터디밖에 없다. 스터디 팀원이 내 동료이자 선생님이자 학생이다. 스터디 팀을 잘 만나는 것이 중요하기 때문에 왠만해서는 스스로 팀 빌딩을 하길 바란다. 그렇지 않고 팀원을 구하고 있는 팀에 들어가거나 그냥 랜덤 매칭되어 들어가게 되는 것은, 전자는 케바케겠지만 후자는 정말 비추한다. 높은 확률로 시간을 낭비할 것이다. (랜덤 매칭을 선택하시는 분들 중에 중도 포기가 많은 것 같다.)
내가 느낀 구름톤 트레이닝의 장점 (다른 국비 지원에 비해)
- 강의의 질이 (백엔드 한정) 좋다.
괜히 김영한 김영한 하는 게 아니다. 개발자 중에 이 정도의 강의 퀄리티와 강의력을 가진 사람이 정말 드문 것 같다. (프론트엔드 강의는 솔직히 얘기해서 EBS 강의보다 못하다.) - 온라인 과정이기 때문에 집에서 편하게 공부할 수 있다.
솔직히 코딩은 집에서 투모니터로 해야 제일 편하다. - 개발자에게 중요한 역량인 '스스로 공부하기'를 배울 수 있다.
- 다양한 지원금이 있기 때문에(맥북, chatGPT 멤버십, 자격증 응시료, 훈련장려금 등등) 금전적 부담을 조금 덜어준다.
단점
- 관리자와의 소통이 힘들다.
스타트업이라서 인력이 항상 부족하기 때문에 한 명의 관리자가 너무 많은 업무를 한다. 그래서 진행 과정의 실수도 많고 소통도 원활하게 되는 편은 아니다. 물론 관리자님들 늘 고생하시는 것은 알고 있지만, 사실만 얘기하자면 관리 측면에서 봤을 때 매끄럽진 않다. 스스로 필요한 게 있다면 찾아보고 질문하고 이의를 제기해야 한다. - 팀운에 따라 운명이 조금 달라진다.
스터디 팀은 한번 빌딩되면 바꿀 수 없기 때문에 이번 스터디 팀운이 불길하다? 일단 약간 조졌다고 봐야한다. 물론 의지로 충분히 극복할 수 있긴 하다.
총평 : 내가 소마나 우테코에 들어갈 실력이 안된다? 구름톤 트레이닝을 추천한다.
구름에 대한 후기는 위에서 다 말한 것 같고, 추가로 파이널 프로젝트를 하며 내가 느낀 점을 회고해볼까 한다.
파이널 프로젝트 이야기
놀랍게도 우리 팀은 파이널 프로젝트에서 4팀 중 1등을 했다. 왜 1등인지는 아직도 좀 의문이다. 발표 당일 아침에 우리 서비스에 급 이슈가 생겨서 그거 해결하느라 다른 팀 발표를 전혀 못 들었다. 그래서 다른 팀이 어느정도였는지는 모르겠지만, 내가 생각했을 때 코치님들이 우리 팀을 좋게 봐주신 이유는
- 개발 문화를 만들기 위해 노력했다.
1차 프로젝트 때 느낀건데, 내 생각보다 활발하게 소통하며 작업하는 팀이 많지 않은 것 같다. 우리 팀은 메타버스에 매일 항상 상주하며 필요할 때마다 호출하고, 새벽에 우리끼리 잡담도 많이 했다. 개발 측면에서도 사수-부사수 문화나 코드 리뷰, 팀 내 세미나(내가 이 기능을 어떻게 구현했는지 발표) 등을 하려고 노력했다. 물론 2개월이라는 제한 시간때문에 자주 하지는 못했다. - 팀 분위기가 좋아보인다.
다른 팀에 비해 우리 팀은 유독 친하고 즐거운 분위기가 있다. 팀원들이 대체로 성격 좋고 유쾌한 사람들이라서 자연스럽게 편안한 분위기가 형성되었고 그런 기운이 발표 자료나 우리의 반응에서 드러났던 것 같다. 발표날 우리는 오프라인으로 만나 모두 한 자리에 모여서 발표를 했다.
이거 두 개 말고는 우리 팀이 특별히 잘한 건 없는 것 같다. 완성도가 높은 것도 아니었고, 어려운 기술을 사용한 것도 아니고, 아키텍처 설계가 끝내주는 것도 아니었다. 사실 수강생 사이에서 기술적으로 유의미한 실력 차이는 없다.
나의 회고
테스트는 중요하다
테스트 코드를 통해 테스트를 하기 위해서는 로컬 테스트 환경 세팅부터 더미데이터 준비, 테스트 코드 작성까지 여간 귀찮은 게 아니다.
하지만 그럼에도 요즘 왜들 그렇게 단위 테스트를 중요하다고 외치는지 알 것 같다. 단위 테스트 코드가 있으면 배포 후 발생하는 에러도 훨씬 줄일 수 있고 작은 단위로 테스트하기 때문에 디버깅에도 편하다.
한 사례를 생각해보면 우리 팀은 영화 평론 사이트를 만들었는데, 한 영화에 대한 평균 별점을 모든 유저, 레벨 10 이상 유저, 네임드 유저로 구분하여 제공하고 있다.
저 레벨 별 유저의 평균 별점은 유저가 별점을 남긴 당시에는 레벨 10 이하더라도, 이후에 레벨 10에 도달했을 때 반영되어야 한다. 그 반대 상황도 마찬가지이다.
이런 부분을 스프링을 실행하여 테스트하기란 여간 번거로운게 아닐 뿐더러 테스트가 필요한 모든 영역을 커버하지 못할 수도 있다. 그래서 각 케이스 별로 경계값 분석 테스트를 진행하는 것이 훨씬 효율적이다. 테스트코드 작성하기 귀찮다고 그냥 무지성으로 코드 돌려보고 로컬 DB에 값 넣어가면서 테스트하는 행위를 몇 번만 반복해도 손해이다. 그냥 테스트코드 작성하는게 낫다.
로컬 테스트 환경의 중요성
이런 단위 테스트뿐만 아니라, 로컬에서 통합테스트(백+프론트 통합) 환경을 자 구축하는 것 또한 매우 중요하다.
나는 배포와 인프라 쪽을 맡았기 때문에 직접적으로 영향을 받진 않았으나, 우리 팀의 다른 기능 구현하는 백엔드 팀과 특히 프론트엔드 팀은 이 로컬 테스트 환경이 제대로 구축되지 못하여 프로젝트 내내 꽤나 고생했다.
원인은 Spring Security를 이용한 JWT의 보안 문제로 인해 로컬에서도 양측에 https 인증을 적용해야만 토큰 발급이 가능한데, 로컬에 https 인증을 적용하기 힘들다는 것이었다. 이 JWT 작업을 초기에 구현을 시작한 것도 다른 원인이라면 원인일 수도 있지만.
아무튼 인증/인가을 담당한 팀원이 백과 프론트 양측의 로컬 환경에 https를 적용하는 데 실패하여 ngrok이라는 터널링 서비스를 이용해 https를 적용해야 했다. ngrok은 외부에서 내 로컬로 쉽게 접근할 수 있도록 해주는 일종의 호스팅 역할을 하는 서비스이다. 내 컴퓨터 로컬호스트의 포트를 ngrok에 등록하면 ngrok이 외부 접속이 가능한 url을 발급해주는데, 이 때 자동으로 https를 적용해준다. 오로지 이 https 하나를 위해 ngrok을 사용했다.
문제는 프론트에서 테스트를 해보려면 백엔드 개발자가 로컬에서 스프링과 ngrok을 항시 돌려주어야 하고, 백엔드 코드가 변경되면 ngrok도 다시 배포해야 한다. ngrok을 돌리고 있는 팀원이 자리를 비우면 테스트를 하기 힘들었고, 무엇보다 ngrok은 너무 연약해서 아주 조금의 트래픽에도 죽어버렸다. 말이 길었는데 한마디로 말해서 백+프론트 테스트가 매우매우 힘들었다는 것이다.
이런 상황이 그 팀원의 잘못이라고 말하는 건 아니다. 나도 내 일을 하느라 바빠서 그런 문제가 있는걸 알았음에도 도와주지 못해서 미안했다. 이런 열악한 로컬 테스트 환경 때문에 특히 프론트 측에서 굉장히 고생했고 생산성과 속도가 많이 떨어졌다. 개발자의 피로도 또한 너무 높았다.
우리 모두가 제한된 시간에 프로젝트를 완성시켜야 한다는 압박감에 눈 앞의 문제점을 당장 해결하기에 급급한 나머지 이런 상황이 발생했던 것 같다. 우리 중 한명이라도 제대로 해결해봅시다! 하고 나섰다면 당장 공수가 꽤나 들어갔을지언정 이렇게 쌓인 개발 부채로 인해 작업 기간 내내 힘들지는 않았을 것이다.
나는 사회인이다
내가 담당한 인프라 부분에서도 아쉬움이 많지만, 프로젝트 전반적으로 아쉬움이 많이 남았다. 우리 팀이 분위기가 좋다고 말했지만 사실 우리끼리는 내부적으로 많이 삐그덕거리기도 했다. 우리는 개발자이기 전에 사회인이기 때문에 사회생활을 해야했고, 사람에게도 오는 스트레스도 은근히 컸다.
그렇다. 우리는 개발자이기 전에 사람이다. 함께 일하는 동료가 무심코 건네는 말 한마디, 표정, 하다못해 은근히 거슬리는 말버릇, 습관에 스트레스를 받는다. 기분 나쁘게 하지 말고 기분 나쁜 티 내지 않는게 사회생활이라는데, 그거 도대체 어떻게 하는건데? 다른 사람과 함께 일하는 게 제일 힘들다.
이전 프로젝트 때 내가 팀원 한 명을 겁나게 갈궈서 보내버린 적이 있기 때문에 그 이후로 그러지 않으려 노력했다. 무조건 꾹꾹 눌러담고 참는 게 능사는 아니지만, 무조건 참는다는 건 내 기준이고 남들 기준으로 봤을 때 나는 딱히 참을성이 좋은 편은 아닌 것 같다. 도저히 못참을 때 까지는 참을 줄 알아야 한다. 항상 겸손한 마음을 가지고 역지사지의 태도를 갖도록 하자.
