[구름톤 트레이닝 풀스택 3기] 구름톤 마무리

구름톤을 진행에 대한 최종 회고

구름톤을 마치면서

6개월간 진행된 구름톤 트레이닝이 끝난지 약 3개월이 지났다. 지금까지 시간이 날때 마다 프로젝트 기획과 진행 그리고 프로젝트가 끝난 후에 회고들을 적어왔다.
프로젝트 기획이나 진행에 대한 부분들은 프로젝트를 진행할때 이전 기수분들이 정리해놓았던 블로그를 보고 끝나고 내가 작성해보는 것은 어떨까 라는 생각에서 작성하게 되었다.

그러나 이렇게 프로젝트나 내 개인적인 생각을 정리하는 회고는 그닥 작성하고 싶지 않았다. 내 생각에 대해 정리하는 것은 좋아하지만 이렇게 공개된 장소에서 작성하는 것에 좀 꺼려졌다. 그럼에도 내친구는 지속적으로 회고를 작성하는 것을 추천했다. 그리고 지금까지 회고를 작성하면서 생각이 좀 바뀌었다.

그래서 구름톤을 마무리 하면서 느낀 점들을 필터링없이 이야기해보려고 한다.

구름톤이 원했던 방식

팀 네트워킹

구름톤을 진행하면서 관리자분들이 생각하는 이상적인 진행은 여러사람들과 네트워킹 하면서 팀들이 지속되는 것이 아니라 바뀌어 가는 것을 원했던 것 같다.
나도 그러한 방식이 이상적이라고 생각했다. 그런데 진행을 하면서 나도 어느정도 친해진 팀원들과 지속해서 팀을 하고 싶다는 생각을 했다. 그리고 내가 팀장을 하게 되면서 그러한 점이 더 크게 느껴졌던 것같다. 그래서 개인적으로는 자주 팀원을 수정하는 것보다 새로 팀을 생성하도록 유도하는 것이 좋아보였다. 구름톤에서는 팀을 형성할때 마다 애매하게 현재의 팀원을 몇명까지만 같이 갈 수 있도록 한정하는 방식을 원했다.(결국 여러사람들의 반발로 팀원 모두 동일하게 갈 수 있도록 했다.)
그래서 이런 방식보다 팀원을 새로 뽑는 방식으로 하거나 아니면 팀장을 유지시키고 새로운 팀원을 구름톤에서 임의로 배정해버리는 방식으로 하는 것은 어떨까 생각했다.

이론기간

구름에서 제공하는 인프런 강의들은 괜찮은 강의들이 많았다. 프론트엔드 백엔드에 관한 강의들이 적절하게 제공되었고, 이후 참여는 어떨지 모르겠지만 3회차에서는 구름에서 제공하는 강의가 모두 구름톤 이후에도 제공되었다.
이론강의의 양이 많은 편이라 완전 초심자에게는 따라가기 어려운 면이 있을 것 같다.
그래서 나는 구름에서 요구하는 과제를 먼저 진행하면서 안되는 부분들을 강의에서 찾아보거나 구글링해서 빠르게 습득하는 방식으로 학습했다.
이방식이 내가 생각하는 부트캠프에 맞는 습득방식인거 같다. 그래서 우리 팀원들에게 이런 방식으로 공부하는 것을 추천했지만, 비전공자나 완전 초심자에게는 어려운 방식인 것 같았다.
만약 전공자이거나 프로그래밍에 조금 공부를 해본 사람이라면 내가 한 방식이 적합한 방식이라고 생각한다.

자바는 커피조의 리더를 맡게 되면서

다른 사람들은 어떨지 모르겠지만 나는 리더에 대한 존경심이 있다. 그래서 학창시절 초등학교 중학교 고등학교까지 1년이라도 반장을 안한적이 없었다. 나가서 발표하는 것에 몹시 떨려 하면서도 이러한 역할에 대해 환상이 있었다. 내가 리더에 적합한 사람이냐고 묻는 다면… 리더로서 좋지 않은 부분들을 가지고 있다고 생각한다. 그럼에도 리더에 대한 열망이 있기에 이번 구름톤에 참가가 확정됬을 때부터 팀장을 하려고 생각하고 시작했다.

구름톤 OT에서 아이스브레이킹을 하면서 이야기를 했던 다른 참가자분이 열정적이셔서 같이 해보자고 하셨을 때 두리뭉실하게 거절했지만 사실은 팀에 합류하는 것보다 내가 팀을 만드는 것에 관심이 있어서 참여하지 않았다. 끝난 이후에도 그분께 솔직하게 말하지 못해서 아쉽지만 그게 나에게는 옳은 선택이었다고 생각한다. 지금까지도..

스터디 진행을 주도하기

우리팀은 6명으로 구성되었는데 4명이 프로젝트까지는 아니더라고 개발 경험이 있는 플레이어 분들이였고, 2명은 프로그래밍에 처음 접하는 분들이였다. 그럼에도 스터디 경험이 있는 사람은 나를 포함해서 2명 밖에 없었다.
부트캠프의 특성상 여러 개발 레벨의 사람들이 모이는 경향이 있었다. 그래서 스터디 진행방식에 대한 내용을 내가 주도해서 선정하고 적용했다. 이과정에서 자꾸 방식이 수정되다 보니 팀원들이 적응하는데 시간이 좀 걸렸다.

비전공자들이 개발에 익숙하게 하기

비전공자분들의 경우에는 일반적인 공대를 거친 사람들과 달리 컴퓨터의 구조나 기본적인 코드에 대한 개념이 부족한 점이 있었다. 그래서 처음부터 많은 어려움을 겪으시는 것 같았다. 나도 어려움을 느끼시는 분들에게 좀 더 도움을 주고 지식을 전달하려고 노력했다. 그러나 이러한 것들도 내 생각보다는 도움이 안되는 것 같았다. 좀 더 도움이 되는 방식은 CS스터디와 알고리즘을 진행하면서 익숙해지고 가까워졌다.

Groomy IDE & Polaroad 개발을 진행하면서

프론트와 백엔드의 밸런스

풀스택 3회차를 진행하면서 느끼는 것은 이 과정이 풀스택임에도 불구하고 정말 많은 사람들이 백엔드를 선호하는 경향이 있었다. 물론 나도 백엔드를 선호했다. 그래서 모든 프로젝트를 진행하는 팀마다 프론트 인원을 구하기가 어려운 현상이 일어났다. 우리 팀도 전원이 백엔드를 공부하고 싶어했다. 그래서 이론기간에도 프론트를 중점적으로 공부하는 인원들이 없었다.

이 점이 프로젝트 진행할때 어려움을 겪었던 부분이였다. 프론트를 진행하면서 주도적으로 리딩할 수 있는 인원이 없다는 점은 아쉬운 점이었다. 특히 내가 프론트를 부트캠프 기간에 배운 것이 전부이다보니 적용하는 스택이나 라이브러리등등에 많은 시행착오가 있었다. 그리고 팀장으로써 내가 맡은 부분을 겨우 해내느라 팀원들에게 피드백이나 리뷰를 상세하게 해줄 수 없었던 부분이 팀원들도 답답함을 느꼈을 것이다. (이부분이 프론트 팀원들에게 미안한 부분이다…)

그래서 만약 프로젝트를 시작하거나 할때는 항상 밸런스를 맟추고 시작하는 것이 좋다고 느꼈다. 그것도 아니라면 프론트를 리드할 수 있는 좋은 리더를 프론트와 백엔드에 한명씩 염두에 두고 시작하면 좋을것 같다.

git & github 협업

개발을 진행하면서 프론트 팀에서는 나를 제외한 2분이 github에 적응되지 않은 상태였고, 커밋 푸시도 어색해하는 상황이였다. 그래서 프로젝트 시작하기 전부터 git을 통해서 branch 생성과 commit push관련해서 설명을 했음에도 많은 이슈들이 생겼다. 특히 충돌해결에 대해서는 나도 잘 모르고 있는 부분이였어서 그부분을 해결하면서 git 협업에 대해서 정말 많이 배울 수 있었다.

그럼에도 많은 아쉬움이 남는 것은 팀원들이 충돌해결하는 방법에 대해서 알려주는 것보다 내가 해결하는 방식으로 진행하다 보니, 우리 팀원들이 자체적으로 충돌을 해결하는 방식에 대해서 습득할 수 있는 환경을 조성해주지 못했다. 다른 분들은 github desktop을 사용해서 작업하다 보니 커맨드라인으로 작업하는 나의 방식이 많이 생소하다고 느끼셨던 것같다. 내가 충돌을 해결하는 것을 원격 데스크톱으로 진행하다 보니 상세하게 설명하면서 진행하지 못한 부분이 아쉬웠다.

아이디어 회의

사실 프로젝트를 진행하면서, 그리고 프로젝트를 마무리하고 회고할 때에도 항상 아쉽다고 생각되는 부분이 이부분이다. 이전의 포스트에서는 브레인 스토밍 방식으로 잘 해결했다고 생각했다. 그럼에도 프로젝트를 진행하면서 개발에 집중했지만 우리 팀이 개발하고 있는 프로젝트 주제에 대한 작은 아쉬움이 마음 한켠에 지속적으로 있었다. 물론 우리 팀이 많은 시간을 사용해서 기획한 프로젝트였지만 내가 납득하지 못한 포인트들이 있었다고 생각한다.

이러한 상황이 내가 프로젝트를 진행하면서 내 100%의 개발 집중도를 만들지 못했다. 물론 학업과 병행하기 시작한 시점이 마지막 프로젝트 시작 시점이였지만, 그것과 별개로도 기획에 대한 의구심을 느꼈던것 같다. 이런 부분은 프로젝트가 끝나고서도 어디서 잘못됬는지 어떻게 해야 해결할 수 있을지를 고민하게 만들었다. 그에 대한 해답을 나는 책에서 찾을 수 있었다.

구름톤 피드백에 도움이 되었던책

“최고의 리더는 반드시 답을 찾는다”라는 책에서 기획단계나 아이디어 회의에서 가져야할 부분들을 알려주는 책이였는데 아이디어 회의나 어떤 문제가 생겼을때 어떻게 해결할 수 있는지에 대한 방식론이나 여러 기업가들이 성공한 방식에 대해서 설명해주는 방식의 서적이였다. 여기서 나는 우리팀과 내가 했던 잘못된 방식을 알 수 있었다.

대다수의 실수는 브레인 스토밍에서 나왔다.

공백을 참지 못하다

나는 팀장으로써도 그렇고 성격상 좀 급한 성격이여서 우리 팀 모두가 적극적으로 급박하게 생각하고 아이디어가 나왔으면 했다. 그래서 Polaroad 기획 아이디어 동안에 급한 모습을 자꾸 나타냈던 기억이 있다. 그래서 팀 전체적으로 여유있게 아이디어 생각을 못하고 지속적으로 급하게 아이디어를 내는 상황에 몰리게 되었다.

기획과 아이디어의 중요도를 생각하면 회의때 급하게 하는 것보다 여유를 가지고 생각하는 것이 좋아보인다. 특히 프로젝트의 전체적인 컨셉을 정하는 회의의 경우에는 정말 많은 생각을 해보는 것이 중요하다.

부정적인 이야기의 단점

기획단계에서 더 큰 문제였다고 생각하는 부분이고, 이부분은 팀에 대한 이야기보다 개인의 태도의 문제였다고 생각한다. 아이디어를 생각할때 부정적인 부분들을 먼저 생각해야 한다고 생각했던 나로써는 여러가지의 아이디어에 대해서 부정적인 이야기를 먼저 언급했다. 특히 자유롭게 아이디어를 내는 브레인 스토밍의 시간에도 그랬다. 이는 지금 생각하면 정말 잘못된 방식이라고 생각된다. 특히 서적에서도 이부분을 주의하라고 이야기가 나왔다.

물론 기획 구체화 단계에서는 부정적인 부분에 대해서 검토하는 것도 중요하지만 아이디어를 내는 단계에서는 모든 아이디어에 대해서 긍정적으로 생각하는 것이 좋다고 한다. 이렇게 생각하면서 아이디어에 대해서 긍정적인 부분들을 생각해볼 수 있고, 팀원들이 아이디어를 부담 없이 꺼낼 수 있는 환경을 구성할 수 있었다. 향후 프로젝트에서는 이러한 방식을 생각해보는 것도 좋을 것 같다.

통합적 사고?

프로젝트를 진행하면서 여행 관련된 아이디어가 좋기는 하지만 생각보다 내 마음속에 와닫지 않았다. 그럼에도 다른 팀원들이 맘에 들어 하는 것같아서 컨셉을 확정하고 프로젝트를 진행했다. 이전에 이야기 했던 것처럼 이부분이 내가 프로젝트에 100%의 몰입을 가지고 개발하는데 걸림돌이 되었다.

우리팀의 아이디어

그래서 현재 아이디어에 대해서 좀 더 필요성을 구체화 시키고, “최고의 리더는 반드시 답을 찾는다”에서 가장 많이 나온 방식인 통합적 사고를 통해서 여러가지의 아이디어들을 섞어 보는 방법으로 아이디어를 생각해보는 것도 좋았을 것 같다.

투표..?

아이디어를 선정할때 우리 팀은 대체로 다양한 의견이 나오는 경우가 많았다. 그러나 모든 인원들의 만장일치를 얻기에는 불가능하다고 생각했다. 그래서 우리는 투표시스템을 통해서 의견을 통합하고 진행했다. 그런데 이런 방식이 잘못됬던 것 같다. 모든 사람들이 같은 생각을 가질 수 없다고 생각했지만 실제로 그렇게 되면 팀에서 아이디어에 대한 애정도의 차이가 생기기 마련이였다.

그래서 어떤 방식을 통해서라도 모든 팀원들의 방향성을 동일하게 만드는 것이 필요하다. 그런 방식을 위해 모든 팀원들이 적극적으로 토론을 통해서 아이디어에 대해 생각해보고, 좀 더 여러가지의 방향으로 생각해보는 시간을 가지지 못했다.

부트캠프를 마무리 하며

개발을 공부하는 입장으로써 부트캠프를 많이 하고 싶어했고, 그래서 군대를 전역하자 마자 참여하고 싶었다. 정말 근사한 결과물을 가지고 싶었지만 내 생각대로 안되는 것이 프로젝트라고 생각한다. 그래서 마무리가 아쉬웠다. 그리고 가장 아쉬웠던 부분중 하나는 내가 팀장으로써 팀을 이끌어나가는데 잘못 생각했던 부분들이 많았고, 이떄문에 우리팀이 완벽하지 못했다고 생각한다.

프로젝트의 완성도

프로젝트의 완성도를 퍼센트로 표시하자면 80% 정도로 표현할 수 있을 것 같다. 기본적인 기능들은 완성했고 추가적인 부분들 특히 스타일적인 부분들이 많이 아쉽게 남겨졌다. 애초에 스타일적인 부분들에 약했던 프론트 팀이였기에 당연한 부분도 있었지만, 개인적으로는 CSS만을 활용했던 부분이 패착이였던것 같다. 스타일적인 부분에서 css가 아니라 tailwind등의 여러가지 스타일 스택을 사용했으면 좀 더 개발 속도도 빨라지고 완성도 높은 웹 & 앱이 만들어지지 않았을까 생각한다. 이에 대한 부분들도 마지막 발표에서 피드백으로 들으면서 얻을 수 있는 배울 점이였다.

학업과 부트캠프의 병행

다른 부트캠프는 모르겠지만 구름톤은 가능할 것 같다. 오프라인으로 진행하는 부분들이 많이 줄었다고 들었고, 내가 참여할때도 오프라인 행사들을 줄여가고 있는 추세였다. 개인적으로는 그런 부분들이 아쉬웠지만 오히려 학업과 부트캠프의 병행을 위해서는 다행인 부분이였다. 만약 팀장을 하지 않는다면 학업과 부트캠프는 충분히 병행가능하다고 생각한다.

그러나 나는 팀장이였고 우리팀이 많은 편의를 봐주어서 가능했다. 마무리 프로젝트 발표들의 대다수를 참여를 못하는 상황이 생겨서 백엔드 팀장분이 발표를 해주셨다. 그리고 시험기간에는 프론트 팀에 대한 질의응답이나. 데일리 스크럼에 참여못하는 경우가 종종 생기다 보니까 우리 팀에게 항상 미안한 마음이 생겼다.

팀원들과의 케미

우리 팀은 스터디 부터 시작한 팀원 5명과 후에 프로젝트 기간에 추가된 인원 1명과 같이 개발을 진행했다. 스터디때부터 서로 도움이 되고자 노력했고 서로에게 동기부여를 주는 등의 상부상조가 잘되는 케미 좋은 팀원들이였다. 팀원들과 오프라인으로 만나서 진행했던 회의는 한번 밖에 없었지만 서로 의사소통 하는데에 문제는 전혀없었다. 그래도 아이스브레이킹이나 분위기 메이커 역할을 할 수 있는 인원이 없다는건 아쉬운 느낌이였다. 내가 그런 흔히 말하는 분위기메이커의 역할을 하고 싶었지만 내능력이 부족했다…

팀장으로써 부족했던 부분

구름톤을 진행하면서 모든 아쉬웠던 부분들은 모두 내가 팀장으로써의 역할에서 아쉬웠던 부분들이 대다수이다. 이전의 회고에서부터 지속적으로 이야기해온 부분들이 우리 팀원들에게 미안하다는 생각이 많았다. 이번 회고에서도 말했듯이 내가 뛰어난 리더이기 위해 필요했던 역량과 배운 부분들이 대다수이다.
부족한 점이 많은 팀장과 불만없이 개발진행해준 팀원들에게 감사하다는 이야기를 많이 하고 싶었다. 사실 끝나고도 이러한 이야기를 했지만 구체적으로 어떤 부분에서 내가 부족했고 도움이 되지 못했는지를 이야기하고 싶었다. 그리고 이런 방식으로 향후에 또다른 프로젝트 리더가 되었을때 좀 더 나은 리더가 되어있을 수 있었으면 좋겠다.

결과 & 우수 플레이어 선정

프로젝트 발표가 끝나고 우리팀은 수상을 하지 못했다. 백엔드분들의 실력보다 프론트팀에서 해야할 일들을 완벽힘 마무리하지 못했다는 느낌이 강했다. 그리고 내가 생각하는 수준의 완성도를 마무리 하지 못했기에 수상은 기대도 하지 못했다. 그럼에도 프로젝트를 마무리했고, 완성했다는 것에 뿌듯함을 느꼈다. 그리고 여러 다른 팀들을 보면서 다들 정말 열심히 완성도 높은 개발을 해왔음을 확인하고, 반성하게 되는 부분도 있었다.

그리고 나는 생각지도 못한 우수 플레이어로 선정되었다. 아직도 어떠한 이유에서 내가 뽑혔는지, 정말 대단한 개발능력을 가지고 있는 여러사람들중에서 왜 내가 되었는지는 잘 모르겠다. 너무 급작스럽게 상을 받다 보니 덜덜 떨면서 발표하면서 우리 팀원들에게 감사하다는 이야기를 했던 기억이 난다.

여러가지 이유가 있겠지만, 우리 팀원들이 나를 정말 높이 평가해줬다는 것이 느껴졌다. 항상 팀원 투표에서 나를 선정해주셨던 과거가 생각난다. 그리고 이전 이론기간동안에 과제를 1개 제외하고 모두 제시간 안에 제출했다. 그리고 나의 기준에서는 높은 완성도로 항상 과제를 제춣하려고 노력했다. 그러한 부분들이 우수 플레이어를 선정하는데 기준이 되지 않았을까 생각한다.

끝마치며…

구름톤을 진행하면서 많은 개발자 지망생들을 보면서 개발에만 집중하는 시간이 정말 길게 느껴졌다. 그리고 최선을 다했다. 개발자를 꿈꾸는 사람이라면 부트캠프를 참여해보는 것은 정말 값진 경험이 될꺼라고 확신한다. 구름톤뿐 아니라 여러가지의 부트캠프를 보고 본인의 여건에 맞는 부트캠프를 선정해서 참여하는 것을 추천한다. 나는 어떤 경험이든 중요하다고 생각하는 사람이였다. 그렇게 해서 전역하고 부트캠프를 하면서 군대와 부트캠프에서 내가 생각하지 못한 세계를 경험한듯 하다.

이후 어떤 일들이 나에게 다가올지 모르지만 무슨일이든지 하면 나에게 도움이 되지 않을까 생각한다. 지금 이 회고를 작성하면서도 부트캠프가 끝나고 게을러 졌던 나를 반성하게 되는 것 같다. 지속적인 성장을 위해서 무슨일이든 해보는 것 그게 내가 생각하는 개발의 본질이 아닐까 생각한다.