🟪 Final Project 회고
길었던 2달이란 시간이 지나고 Final Project가 모두 끝났다.
나에게는 섹션 1~3때보다 재밌기도 힘들기도 했던 시간이였던 것 같다.
하지만 뜻깊은 시간이였고 섹션 3때보다는 훨씬 재미있었던 시간이였다.
프로젝트는 실전이라는 느낌을 많이 받았고, 직접 구현해보면서 이론보다는 피부로
와닿아서 그간 공부했던 것들이 이해가 되는 경험이 많았다.
본인은 구동되는 것을 봐야 하고 되는 것을 보면서 실적으로 느껴야 이해를
잘하는 편이기에 섹션 공부를 하면서 이해가 안 되었던 점이 프로젝트를 하면서
지난 스프린트 내용을 다시 공부하면서 이해가 많이 되었다.
그렇기 때문에 배운것이 너무 많고, 진짜 개발한다는 느낌이 들어서 시간이 가는 줄
모르고 개발을 했던 것 같다. 그리고 온전히 개발만 하지 않고 처음부터 SR단계에서
기획을 세우고 깃허브에 기록을 남기는 등 개발자는 개발만 할 수 없다는 경험을
하게 되었다. 나는 시간만 충분하다면 그 날 공부한 것을 복습의 의미로 정리하는 것을 좋아하지만 프로젝트나, SPRINT 중간중간 시간에 쫓기다보니 그러지 못했던 것이
너무나 아쉽다.
또한 개발자는 소통이 정말 중요하다는 것을 깨달았다.
과정의 특성상 모두 온라인으로 대화를 주고 받았기 때문에
그 기능에 대해서 혹은 코드에 대해서 프로젝트의 흐름 대해서 말하다보면
의도치 않게 오해나 이해를 못하는 점이 생길 수 있겠구나 싶었고 이를 방지하려면,
- Github의 Projects, Milestones, Issues
- Slack
- Notion
- Jira
등 다양한 커뮤니케이션 협업툴, 프로젝트 관리 툴등을 활용하는 것을 적극 권장한다.
또한 프로젝트를 하면서 자신이 무심코 툭 뱉은 말이 상대방에게 큰 상처가 될 수 있으니
항상 상대방에게 이야기할 때 다시 한 번 생각 해보고 이야기하기를 바란다.
👍🏼잘했던 점
1. 적극적으로 배우지 않은 것들을 사용해보려고 했다.
적극적으로 뭐든 사용해보려는 것이 정말 중요하단 것을 느꼈다. 보는 시야가 넓어진다는
느낌을 받기 때문이다. 설사 어렵더라도 도전해보면 다 해낼 수 있다고 생각한다.
안되면 선배 기수들이 사용하였던 코드들을 보면서 자신의 것으로 변경하여 적용해보는 것도 많이 도움이 된다. 사람의 성격이 다르드 사람마다 코드를 짜는 방식이 다 다르기 때문이다.
점차 코드를 보는 눈이 길러지게 된다면 그 코드를 보면서 '이렇게 코드를 짤 수도 있고, 이 부분은 정리가 필요한 것 같네?'라며 코드를 보는 눈도 길러진다.
지나고나면 에러들은 대부분 사소한 실수에서 일어나지만 그 때 해결했을때 그 기분은
이루 말할 수 없는 성취감을 준다.
어떤 스텍을 추가로 공부해서 사용할지 모르겠다면, 가고싶은 회사나 다른 스타트업에서
어떤 스텍을 사용하고 있는지 보고 사용해보는 것이 좋다고 생각이 된다.
가고싶은 특정 회사가 있으면, 그 회사에서 어떤 스텍을 사용하는지 종종 보곤했다.
아직 전체적인 프로젝트의 기능 구현과, CSS적인 측면에서 완성이 되지 않았다.
그래서 수료 이후에도 개인적으로나, 팀원들과 모두 소통하여 타입스크립트로 다시
리팩토링을 하려고 하고 있다.
2. 의사소통
팀장이 아닌 팀원으로써 프로젝트에 참여하였지만, 팀장을 도와 전체적인
- wiki, Repositorie 관리 등
한 명의 팀장이 아닌 모두가 팀장의 역할이 되었으면 하는 바램에서 소통을 많이하면서
프로젝트를 이끌어가려고 했던 점에서 의미가 있었다.
3. 팀원간 피드백
피드백이란 것은 사람마다 스타일이 다르기 때문에 그 사람의 성향을 파악해서
말을 해야된다고 생각한다. 그런 점에서 우리 팀은 회의때마다 팀원들간 피드백을
하려하고 받아들이기 때문에 좋은 방향으로 프로젝트를 할 수 있었던 것 같다.
💪🏻아쉬웠던 점
1. 글로 이야기하는 것과 목소리로 이야기하는 것은 다르다.
어떠한 문제를 제기하거나, 의견을 제시할때 텍스트로 이야기를 하는 것을 선호하는 타입이
아니라 어떠한 문제와 의견을 평소에 직접 마주보고 소리로 전달하는 방법을 좋아한다.
하지만 과정의 특성상 비대면 온라인 강의 및 페어프로그램, 프로젝트로 이루어져 있다보니
솔직한 자신의 의견을 내비치거나 서로에게 상처가 되는 말에 대한 오해 같은 단점이 생길 수
있으니 항상 말하는 것에 대해서 두번 세번 생각해보고 글을 작성하여 의견을 제시하는 방향이
좋을 것 같다는 의견이다.
2. 하나에 너무 많은 시간을 소비
어떠한 문제가 생겼을때 문제 해결에 대해서 많은 신경을 쓰는 타입이고 최대한
자신이 해결하려는 태도로 임하다보니 어떠한 오류나, 문제가 발생했을 때
최대한 본인 혼자서 해결해보려고 하고 안되는 경우 팀원들과 같은 이슈를 공유했지만
그로 인해서 같은 문제로 오랫동안 해결하는데 애를 먹고 시간을 소비했더 점이 아쉬웠다.
하지만 제가 어느 부분에서 부족한지 정확히 알 수 있었으며, 수료 이후에 백엔드쪽을 좀 더 보완을 하려고 생각중이다!
끝으로
섹션 1~3 과정을 진행하면서 섹션이 지나면 지날수록 어렵다는 생각을 떨치지 못하면서
공부를 했던 것 같다. 그리고 40명으로 시작했던 그 기나긴 여정 끝에 수료생은 12명인 것을 감안하면 현업을 하면서 공부를 한다는 것은 확실히 큰 결심과 책임감이 따른다.
그렇기 많은 생각을 하고 도전하기를 추천한다.
(물론 내가 수강중에 Part 기수는 이제 없어지고 과정도 백엔드, 프론트엔드 이렇게 나누어져서
국비지원으로 변경되었지만..)
아무튼 나는 최대한 과정을 진행하면서 걱정보단 배우지 않았던 것들을 도전하면서 즐기면서
하려 했고, 그럼에도 부족한 나에게 조금 덜 부족한 사람이 되지 않았나 생각이든다.
마치 훈련병이 수료식에 이병 계급장을 달고 즐거워하는 것처럼 모든 것을 놔두고 좋아해선 안된다.
이제 취업이라는 목표를 바라보며 계속해서 공부를하고 그 목표를 이루어낸 다음에도
"내가 개발자가 되고 싶었던 이유"를 항상 생각하며 성장하는 개발자, 좋은 개발자가 되려고
노력하자.
