부트캠프 항해99 - 프론트엔드 개발자 솔직 후기

minkyung·2022년 8월 17일

UIUX를 전공해서 산업디자인과를 졸업하고 디자이너로 1년동안 사수없는 중소기업에서 근무했었는데
진로고민을 하다가 결국 퇴사를하고, 평소 관심이 있던 프론트엔드 개발을 한번 배워보자~ 라는 비교적 가벼운 마음으로 항해에 뛰어들었습니다.

현재는 프론트엔드 개발자로 취업준비를 적극적으로 하고 있습니다 🔥

항해를 시작하기 전에

저는 어느정도 ‘인생에서 (남들이 보기에) 낭비해도 되는 시간’이 있다고 생각하는 편이고,
항해 신청한 타이밍이 백수가 된지 3개월이 된 시점이었습니다.

그리고 이전에 500만원으로 ‘SBS게임’ 학원의 국비 커리큘럼을 수강한 적이 있었어요.

그래서 400만원에 3개월의 기회비용으로 항해에서 티끌만치라도 얻어가면 괜찮은 기회다 ~
라는 마음으로 항해에 임했습니다.

하차 후기도 꼭꼭 보시길 바랍니다.

항해가 누구나에게 잘 맞는 프로그램은 아닌 것 같아요.

저는 항해 수료 후기 보다 하차 후기를 많이 봤습니다.
1일만에 하차하신 분, 50일만에 하차하신 분 글도 봤는데
공통적으로 말하는 바는 비슷하셨던 것 같아요.

남들에 비해 뒤처지는 시간이 힘드신 분, 그 때문에 팀원들에게 피해를 주는 것 같아서 힘드신 경우도 있고
혹은 '방치형 커리큘럼'(항해가 깔아준 자리에서 스스로 고군분투 성장하는 항해 크루들 ...)이 힘드신 경우도 있고 ...

아래 이미지는 항해에서 필요한 마음가짐입니다.

저는 99일 동안 주 100시간을 수료하는 항해라는 커리큘럼에는
적당히 배우는게 빠르시고, ‘못하는 나’ 를 잘 견디시는 분이 잘 맞으시는 것 같습니다.
~~아니면 저처럼 티끌, 개미똥만큼씩만 성장해도 성장 그자체에 기분 좋아지시는 분들~~

못하는 기간을 잘 견디시고 잘하기 위해 노력하는건 어느 분야나 동일하다고 생각하는데
취업과 연결되어 있고 비교적 짧은 기간 내에 이루어지는 커리큘럼이기 때문에 심적으로 부담이 들 때도 있어요.

그래서 ‘못하는 나’와 ‘배우면 할 수 있는 나’가 마음 속에 모두 존재해야 건강하게 성장하실 수 있습니다.

항해 과정

힘들긴 힘들어요 ...

오전 9시부터 오후 9시까지가 정규 시간이고, 그 후에는 자율적으로 공부하거나 코드짜거나 하는건데
오후 9시, 오후 10시 정도에 퇴근(전 걍 이렇게 부름ㅋㅋ)할 수 있는 주는 엄청 드물었습니다.

공부할건 산더미처럼 많고, 나는 아무것도 모르고, 구현하고 싶은건 많고 어쩔줄모르는 마음때문에
새벽 세네시까지 공부하고 코드짜고 했었습니다.

근데 3개월 내에 그렇게 새벽까지 달려서 공부하거나 코드짜고나서 ‘푹’ 쉴 수 있는 기간이 없기 때문에
그냥 평소 루틴을 잘 수행하시는 걸 추천합니다 (말은 너무 쉽지만 ... )

그리고 항해 시작하기 전에 커리큘럼 시간 내에는 카메라와 마이크를 켜는 것을 약속으로 서약서를 제출하는데,
처음에는 너무 불편했어요 ㅋㅋ

근데 나중에는 저도 최대한 카메라를 켜놓고 있었습니다.
팀원이 공부하고 있으면 저도 자리에 앉게되고,
자리에 있는걸 볼 수 있으면 편하게 대화(질문) 걸고 하는 환경이 공부하기엔 좋긴 좋더라구요

항해 크루원

항해에서 제공해주신 강의, 커리큘럼에서도 얻어간 것이 많지만
같이 항해99 7기를 수료하신 동기분들한테서도 많이많이 얻었습니다.

혼자 공부하는 것보다 같이 공부하는 것이 덜 힘들고,
머리 하나로 고민하는 것보다 여러개로 고민하는 것이 더 옳은 방향으로 나아갈 수 있는 것 같습니다.

물론 어느 사람들과 뭉치냐에 따라 다른데, 지식 수준에 대해서 얘기하는 것이 아니라
공부 태도나 개발 태도가 좋으신 분들을 맘속에 찍어놓고 같이 공부하자고 권유하시면 싫다고 하실 분들 없으실거에요 ~

공부하시면서 개념 자체를 아는 것과 실제로 개발을 해보는 것, 자체에는 큰 차이가 있는데
개념 자체를 곱씹어보면서 이해하는 것에도 '대화'가 크게 영향을 끼치고
실제로 개발을 해보는 과정에서는 남의 코드를 많이 읽고 다양한 방법을 시도해보는 것도 좋습니다.

스터디

저는 항해 시작 2주차부터 마지막까지 계속 따로 스터디를 진행했습니다.
자바스크립트 스터디로 시작해서 지금은 사이드 프로젝트를 같이 진행하고 있어요!

항해 시작하기 전에 '사전 프로젝트' 신청하시면 항해에서 팀을 짜주셔서 연습 복습 겸 프로젝트를 하나 하게 되는데
그 사전프로젝트 팀원분이 같이 스터디 시작하자고 말씀해주셔서 시작한게 이 때까지 계속 이어지고 있습니다.

1) 스터디원들이 모두 같은 책을 구매하고, 매일매일 정해진 시간에 만나서 읽어오기로 한 분량에 대해 같이 얘기를 나누거나
2) 같은 강의를 구매해서, 강의를 듣고 퀴즈를 같이 풀고 과제를 했었습니다. (노마드코더 reactMasterClass)

같은 책을 공부하는 방법은 분량 정할 때 요약 정리해서 말해주는 담당자를 정하는 방법과
분량만 정하고 담당자는 당일에 사다리타기로 정하는 방법 둘 다 써봤는데

스터디 팀원들이 다들 더 잘하고 싶은 마음이 크고, 언어에 대한 욕심이 많아서 대화가 많았습니다.
그래서 저는 두가지 방법 다 좋기는 한데 정말 정말 저한테 남는 방법은

스터디 끝나고 TIL쓰기 인 것 같습니다!

스터디를 한다고 해서 '선생님'을 모셔놓고 '수업'을 받는게 아니고
같은 지식을 흡수하고 같이 의논하는거여서 막힐 때도 있습니다.(그게 대부분이었어요)

그럴 때는 같이 머리를 맞대서 이거아닐까? 저거아닐까? 코드도 따라 쳐보면서 이해하고 진도를 넘어갔는데,
그 이후에 정리를 안하니까 그 때 이해하고 넘어갔던 부분을 다시 마주치면 다시 도루묵 되는 경우도 있었어요.

공부하는 방법을 공유하고
리액트에 대해서 대화할 수 있는 시간이어서 엄청 유익했고
개발을 어떻게 잘, 어느 방향으로 해야하는지 생각해보는 시간이어서 좋았습니다.

그리고 항해는 결국 방 안에 혼자 있는 온라인 상황이기 때문에 루즈해지기 쉬운데
스터디가 있으면 스터디 안에서 서로 과제를 내주기 때문에
계속 뭔가를 해야하는 상황에 스스로를 던져서 … 좋았습니다.

실전프로젝트

처음 항해에 왔을 때 ‘미니프로젝트’ 1주차, 알고리즘 공부하면서 주특기 언어 공부하는 2주차, 주특기 강의들으면서 과제 제출하는 3주, 4주, 5주차를 지나서 주특기를 사용하고, 백엔드 팀원들과 만나서 팀 프로젝트를 하게 되는 주차가 2번(미니프로젝트와 클론코딩 주차) 지나면 실전프로젝트 주차가 옵니다.

실전프로젝트에서는 프론트 3명, 백 3명, 디자이너 1명으로 된 팀으로 6주동안 프로젝트를 진행했습니다.
(개발자 인원은 조마다 각각 달랐습니다!)

먼저 팀장(저, 프론트)과 부팀장(백엔드)이 팀을 하고 싶다고 신청하고 그 외 개발팀원들은 랜덤 + 매니저님이 분배해주셔서 만나게 되었습니다.

서비스 기획

팀장+부팀장이 팀 신청을 할 때 어느정도 기획안을 제출하기는 하는데,
팀원이 추후에 결정되다보니까 그 때 제출한 기획안은 기획 후보 (1)이 될 뿐이지,
그 기획안으로 결정된 상태로 시작하지 않아요. 팀원들을 만나서 그 때부터 ‘서비스 기획하기’가 시작됩니다.

디자이너까지 포함된 팀 전체가 달라붙어서 6주 동안 진행 할 서비스 기획을 1주 정도 가집니다.

저희는 기획이 한번 엎어져서 다른 조들보다 1주 늦어졌었는데 (원래 게임을 만드려고 했었음)

그래서 확장성이 좋은 프로젝트로 기획하고 (CRUD 후 채팅이나 화상채팅 등을 덧붙일 수 있는 프로젝트),
1차 스코프를 확 줄여서 애자일 방식으로 점점 확장시켜나가자는 의견으로 모아서 진행했습니다.

커뮤니케이션, 피드백

팀원들과 많은 시간들을 같이 보내면서 사실 저는 서로 대화하는게 프로젝트 진행 요소 중에 정말정말 중요한 요소라고 생각했어요.

어떤 서비스를 런칭하기 위해 팀원들과 달려나가는 과정 중에서 대화가 빠질 수 없기 때문에
서로가 알아들을 수 있는 말로, 같이 대화하는 것이 중요하다고 생각했습니다.

저는 사실 이슈가 발생했을 때나, 담당한 파트가 늘어질 때 빨리 이 사실을 팀원들이 인지할 수 있게끔 하는게 중요하다고 느꼈고(기간이 짧은 프로젝트여서 더 그런것같아요)

그 이슈를 같이 해결할 때나 같이 의논할 때 (정말 당연하게) 서로를 존중하는 태도와 말투가 중요하다고 느꼈어요

사용자 피드백

실전 프로젝트에서는 4주인가 5주 째에 서비스를 사용자들에게 실제로 런칭을 하고, 실제 사용자 피드백을 받았습니다. 저희 조는 50개의 응답을 받아서 피드백을 문장으로 쫙 푸니까 167개 정도 받을 수 있었어요.
그 피드백을 3개 카테고리로 나눠서 ((1)안돼요, 불편해요, 헷갈려요 / (2) ~했으면 좋겠어요 / (3) 이렇게 보였으면 좋겠어요) 1번 카테고리 부터 빠르게 효율적으로 개선할 수 있었어요.

실제 사용자가 사용하는 방식이나 관점이 개발자의 입장으로서 발견 못할 관점이 굉장히 많기 때문에
하나하나 꼭 읽어보시길 바랍니다.