24년 9월 5일부터 25년 4월 11일까지 진행한 스프린트 풀스택 과정이 드디어 끝이 나서 회고 글을 작성해보려 한다.
계기
나는 1년 반 정도 프론트엔드를 독학했다. 개인 프로젝트를 하나 만들고 이를 토대로 이력서를 작성해서 지원을 해봤지만 결과는 좋지 못했다.
다른 방법을 찾아보다가 부트캠프에서 취업 관련해서 도움을 받았다는 지인의 얘기를 듣고 부트캠프를 참여 해보기로 결정했다. 이미 프론트엔드는 경험이 있었고 백엔드도 할 줄 아는 것이 경쟁력이 있지 않을까 하는 생각에 풀스택 과정을 지원하게 됐다.
커리큘럼 및 진행 방식
풀스택 과정은 강의+실습 / 12개의 스프린트 미션 / 3번의 팀프로젝트로 이루어져 있다.
미션은 강의에 나온 내용들을 활용해 요구사항들을 구현해서 제출하고 멘토님이 리뷰를 남겨주시는 방식이다.
그리고 팀 프로젝트는 3번 모두 코드잇 측에서 준비한 디자인과 기획을 토대로 진행했다.
스프린트 미션
나는 스프린트 미션을 진행하면서 두가지를 지키려 노력했다.
1.정해진 기한 내에 미션을 완성해서 제출할 것
2.멘토님이 주신 피드백을 반드시 반영할 것
첫번째는 부트캠프가 끝나고 되돌아 봤을 때 후회하지 그러기 위해선 일단 마감 기한이 있고 제출 여부를 통해 결과를 알 수 있는 미션을 빠지지 않고 제출하는 것이 중요하다 생각했다.
그렇게 12개의 미션 중 1개의 미션을 제외하고 마감일 안에 모두 완성하여 제출할 수 있었다. (1개의 미션은 개인 사정이 있어서 마감일 이후에 제출하게 된 것이 마음에 많이 걸렸다.)
두번째는 미션을 완료하는 것 만큼이나 멘토님의 피드백을 반영하는 것 역시 중요하다고 생각했는데, 주어진 피드백을 잘 반영하는 것이 실제 업무를 하는데 있어서 가장 중요한 태도 중 하나라고 생각했기 때문이다.
덕분에 동영 멘토님에게 공개 칭찬을 받을 수 있었다. 리뷰를 반영하려 노력했던 점을 잘 알아주신 것 같아 기분이 좋았다.
팀 프로젝트
기존에 협업 경험이 없었기 때문에 부트캠프에서 크게 기대했던 부분 중 하나가 팀 프로젝트였다.
프로젝트 전체 흐름 파악
총 3개의 프로젝트를 진행했는데 두번째 프로젝트에서 기억에 남는 부분은 팀원 중 한 분이 본인이 맡은 파트에서 기획적으로 이해가 안되는 부분이 있었는데 내가 이해한 부분을 설명해줘서 도움을 준 적이 있다.
나는 공통 컴포넌트 작업을 했기 때문에 모든 페이지를 훑어보면서 프로젝트의 전체적인 흐름을 파악하고 있었는데 이러한 점 덕분에 팀원에게 도움을 줄 수 있었던 것 같다.
그 후 세번째 프로젝트에선 내가 팀장을 맡았는데 이번엔 팀원 모두가 프로젝트의 기획을 파악하는데 중점을 뒀고 이를 위해 1주일이라는 시간 동안 기획을 파악하고 함께 공유하는 시간을 가졌다.
모든 팀원이 프로젝트의 전체 흐름을 파악하는 것이 중요하다고 생각한 이유는 다음과 같다.
내가 생각했을 때 프로젝트가 분업이 아닌 협업이 되기 위해선 작업하는 과정에서 각자가 작업한 부분에 대해 다양한 의견을 주고받는 것이 중요하다고 생각했다. 그 과정에서 작업한 팀원이 놓친 부분을 다른 팀원이 발견할 수도 있고 해결하지 못한 문제를 해결할 수도 있기 때문이다. 그러기 위해선 모든 팀원이 프로젝트의 전체적인 흐름을 파악하는 것이 필요하다고 생각했다.
처음엔 너무 긴 기간을 할애한 것이 아닌가 걱정도 했지만 프로젝트를 진행하면서 다른 팀원들이 작업한 부분에 대해 피드백을 진행하고 팀원들이 겪는 문제들을 함께 해결해보니 충분히 시간을 투자할 가치가 있었다고 느꼈다.
프로그래밍에 대한 정의
프로젝트의 전체 흐름을 파악하면서 또 새롭게 배운 것이 있었다. 프로그래밍을 요청에 대한 응답으로 분석하는 관점이다. 프론트엔드는 사용자의 요청에 따라 거기에 맞는 인터렉션을 응답하고 백엔드는 클라이언트의 요청에 따라 알맞는 데이터를 응답하는 것이기 때문에 요청에 대해 응답한다는 관점에서 본다면 훨씬 이해하기가 쉬웠다.
이러한 관점으로 각 페이지에서 일어나는 요청과 응답을 모두 정리해보고 이를 프론트엔드와 백엔드로 나누었다.
이 프로젝트에서 프론트엔드는 피그마에서 보여지는 것에서 크게 복잡한 인터렉션이 없다보니 정리할 부분이 많지 않았지만 백엔드의 경우 시각적으로 정리된 것이 없기 때문에 특정 페이지에서 어떤 데이터를 요청하는지 정리해보는 것이 굉장히 도움이 됐다.
다른 팀원들에게도 이 방법을 공유했는데 설명이 조금 부족했는지 반응이 애매했다. 가장 친했던 팀원 한명과 이 부분에 대해 얘기해볼 기회가 있었는데 이 팀원은 처음엔 프론트엔드를 정리한 부분만 보고 피그마를 보면 알 수 있는 내용인데 왜 정리를 했을까? 생각했다고 한다.
그러다가 내가 백엔드 부분을 설명하면서 일종의 의사코드라고 설명을 드리니 바로 이해를 하시고 이 방식이 유용한 것 같다고 하셨다. 피어리뷰에도 아래와 같이 남겨주셔서 참 뿌듯했다.
팀원 교육
마지막 프로젝트 때 백엔드를 처음 작업해보는 팀원이 있었다. 마지막 프로젝트인 만큼 모든 팀원이 프론트엔드,백엔드를 모두 경험해보는 것이 중요하다고 생각했기 때문에 이 팀원에게 백엔드 교육을 해줬다.
먼저 코드를 작성하지 말고 API가 동작하는 흐름을 글로 정리한 다음 GPT에게 사용하는 기술 스택과 DB 스키마와 함께 정리한 글을 주면서 어떻게 구현하는지 물어보라고 했다.
그렇게 하니 코드를 줬지만 실제로 API를 호출했을 때 예상과 다른 결과가 나왔다. 코드를 살펴보면서 어느 부분이 문제인지 함께 찾아보고 수정하는 식으로 구현했고 그렇게 여러번의 수정을 거쳐서 하나의 API를 구현할 수 있었다.
그 이후에도 막히는 부분이 생겨서 여러번 내게 질문을 하셨는데 그 때 마다 나는 문제를 해결하는 과정을 설명해드리려 노력했다. 지금 구현하는 기능이 어떤 기능인지에 대해 정확하게 파악하는 것과 에러가 어디에서 발생한건지 찾아내는 작업이 주된 내용이었던 것 같다. 그렇게 나중에는 질문 빈도가 줄어들고 스스로 해결할 수 있게 되어서 팀원이 맡은 나머지 API를 프로젝트가 끝날 때까지 구현할 수 있었다.
해당 팀원이 남긴 피어 리뷰인데 이 팀원을 돕는데 꽤 많은 시간을 쓰긴 했지만 나는 오히려 적극적으로 물어본 점이 좋았다. 막히는 부분이 있는데 혼자 해결하려다가 시간을 낭비하는 것보단 빠르게 도움을 요청하는 것이 더 낫기 때문이다.
당연히 스스로 문제를 해결하려고 시도해보는 것은 중요하지만, 자신이 문제를 해결하려는 올바른 시도를 하고 있는지, 그냥 머리만 싸매고 끙끙 앓고 있는지 명확하게 알 수 있어야 한다. 내가 아는 선에서 시도를 해보고 막힌다면 도움을 요청하는 게 좋다고 생각한다.
성장
기술적인 성장에 관해서 어떤 기술을 사용해 봤는지 적을까 생각했지만 하나의 글에 모든 내용을 담기엔 너무 양이 많고 종류가 다양하다고 생각했다. 그래서 구체적인 기술 사용 사례는 개별 글로 작성해보려 한다.
조금 더 포괄적으로 성장한 부분을 적어보자면, 우선 기술 사용의 목적을 파악하려는 자세를 갖게 됐다는 점이다. 해당 기술의 가장 큰 특징, 다른 기술과의 차이점을 알면 그 기술을 왜 사용하는지 알 수 있다.
예를 들어 Next.js를 쓴다면 그냥 React를 사용하는 것과 가장 큰 차이점이라면 서버액션일 것이다. 서버 컴포넌트,서버 사이드 렌더링,미들웨어,API Route가 있는데 Next.js를 쓴다면 이러한 서버액션을 사용하기 위한 것이다. 만약 Next.js를 사용한다면 이러한 서버액션이 필요한지 파악하는 것이 중요하다.
또 앞에서도 적은 내용이지만 프로그래밍을 요청과 응답으로 바라보는 관점을 갖게 된 것 또한 내게 굉장히 큰 성장이었다. 백엔드를 배워보기 전에는 막연히 프론트엔드와는 엄청 다른 영역일 거라 생각했다.
하지만 본질적으로는 요청에 대해 적절한 응답을 하는 점에서 크게 다르지 않다는 것을 알게 됐고 새로운 기술을 배우는데 있어 자신감이 생기게 된 계기였다.
그리고 팀 프로젝트를 진행해보니 내 생각을 다른 팀원에게 잘 전달하는 것이 굉장히 중요하다는 것을 알게 됐다. 프로젝트를 진행하다보면 서로 다른 의견을 갖게되는 경우가 있다.
이 때 의견을 잘 설명하는 것이 중요한데 단지 내 의견을 반영시키기 위해서가 아니라 협업하는 과정에 있어서 원활한 소통을 위해선 각자의 의견의 근거를 명확하게 표현하고 의사결정 과정을 거쳐야 하기 때문이다. 그래야 내 의견에 대한 피드백을 받을 수도 있고 만약 내가 다른 팀원의 의견과 반대되는 의견을 제시한다면 그 근거를 명확하게 설명해야 상대방도 납득할 수 있다.
부트캠프 후기
내 개인적인 회고를 마치고 혹시나 부트캠프에 대해 궁금한 분들도 있을 것 같아서 간단하게 남겨본다.
부트캠프를 시작하기 전엔 나 역시 부트캠프에 대해 부정적인 입장이었지만 지금 생각해보니 명확한 근거가 없는 의견이었던 것 같다. 지금 내 생각은 결국 자기 하기 나름이라는 것이다.
코드잇 스프린트 부트캠프의 경우 꽤 커리큘럼이 괜찮다고 생각한다. 배우는 기술스택도 좋고 미션을 통해 직접 기술을 사용해 구현해볼 수 있다는 점도 좋았다. 하지만 미션에 관해서 몇가지 아쉬운 점도 있었다.
주중에 실습 시간을 활용해 미션을 진행하는데 1주일 안에 미션을 완성해야하는 경우가 많았다. 하지만 1주일 내내 실습 시간만 있는 건 아니다 보니 미션을 진행할 시간이 생각보다 많지 않다는 것이다. 또 실습 시간에 미션 뿐만 아니라 다른 실습을 진행하다보니 미션을 진행할 시간 자체가 그리 많진 않았다.
물론 실습은 자율적이다 보니 그 시간에 나는 미션을 진행했다. 하지만 많은 수강생들이 미션에 대한 일정 관리를 잘 못해서 제출하지 못하는 경우가 많이 발생했다. 물론 일정은 개개인이 관리를 해야되는 부분이긴 하지만, 이에 대해 좀 더 리마인드를 자주 해주거나 어떤 장치가 있었다면 좋지 않았을까 싶다.
사실상 미션을 진행하고 멘토님들께 받은 리뷰가 굉장히 유익했기 때문에 이를 활용하지 못한 수강생들은 많이 아쉽다는 생각도 들었다.
3번의 팀 프로젝트 역시 많은 도움이 됐지만 몇가지 아쉬운 점도 있었다.
우선 기획에 있어서 실제 서비스라고 생각하면 이게 왜 있지? 싶은 것들이 많이 있었다.
또 이미 준비된 기획을 사용해 개발하는 것 또한 아쉬운 부분이었다. 실제 개발자로 일을 하면 기획이나 디자인을 직접 하지 않기 때문에 주어진 기획을 사용하는 것은 크게 문제되진 않는다고 생각한다. 하지만 매 기수마다 똑같은 주제로 진행을 하기 때문에 내가 이력서에 작성한 프로젝트가 이미 다른 지원자가 제출했던 것과 겹칠수도 있기 때문에 문제가 될 수 있다고 생각한다.
프로젝트를 세번 진행하는 것보다 차라리 하나의 심화된 프로젝트를 팀원들끼리 계획해서 만들었다면 어땠을까라는 생각도 들었다.
또 만약 이 부트캠프를 참여하게 된다면 반드시 프로젝트가 끝나고 바로 포트폴리오를 정리하는 것을 권장한다. 대부분 프로젝트가 끝나고 바로 수업을 진행하다보니 그럴 시간이 없었는데 막상 지나고 정리하려고 보니 뭘 했었는지 잘 기억이 나지 않는다.
좋은 점과 아쉬운 점을 간단하게 요약해보자면 이렇다.
좋은 점
1. 커리큘럼이 좋다.(다양한 기술을 경험해볼 수 있다.)
2. 미션을 진행하고 멘토님들께 리뷰를 받는 시스템이 도움이 많이 된다.
3. 협업을 경험할 기회가 있다.
4. 멘토링 시간을 통해 좋은 정보나 노하우를 알 수 있다.
아쉬운 점
1. 커리큘럼이 처음 배우는 입장에선 빡세다. (프론트엔드던지 백엔드던지 하나는 어느 정도 경험이 있는 분에게 추천)
2. 미션 일정이 꽤 빡빡하다. (일정관리에 많은 신경을 써야 함. 누가 뭐해라 뭐해라 말해주지 않음)
3. 팀 프로젝트의 기획 완성도가 조금 아쉽고 포트폴리오가 중복된다.
4. 부트캠프 측에서 케어가 조금 부족하다는 느낌이 있다.
