✏️ 기록/취준생활

[프리온보딩 인턴십-FE] 1주차 회고

예진-D 2023. 5. 1. 22:37

 

첫 주차를 진행하며

 정말 다사다난했던 일주일이 지났다.😂 합격을 기뻐할 새도 없이 인턴십이 시작했고 첫 세션인 화요일에 바로 팀원을 배정받았는데 생각보다 많은 수(10명)로 이뤄져 있어서 놀랬다. 아무래도 동료학습이라는 개념이 너무나 생소해서 많은 수의 인원에 걱정부터 들었던 것 같다.

 최근 스터디나 커뮤니티 활동없이 취준생활을 지속해서 그런지 새로운 사람을 만나는 것에 대해 두려움이 생겼었다. 그러다 보니 의사소통에 문제가 없다 자부했지만 점점 할 수 있을까?라는 의문이 들던 참이었다. 사람들 앞에 서면 목소리가 벌벌 떨리던 것도 많이 극복했는데 이대로 예전 모습으로 돌아갈 순 없었다!

그래서 처음 디스코드 스레드에서 팀원분들을 만났을 때 정말 큰 용기를 내서 먼저 만남 시간을 가져보자 말을 꺼냈다!

너무너무 떨렸지만 인사도 잘나누었고 결론적으로 내가 팀장을 맡기로 했다..!

학교 프로젝트나 안면이 있는 학우들과 소규모 프로젝트는 모두가 팀장이 되어 으쌰으쌰 했던 기억이 있다. 당연하다, 다 아는 사이니까! 

그러나 처음으로 두자리수 인원에, 초면이신 분들을 두고 내가 팀장의 역할을 잘할 수 있을까 걱정이 됐다. 강사님은 어차피 동료학습이고 팀장은 일정관리 정도만 맡으면 된다고 하셔서 그나마 긴장을 풀 수 있었다.

 

팀원과의 첫 만남

 팀원별 디스코드 스레드에서 인사를 하고 구글 미트에서 첫 회의를 가졌다. 한명씩 정말 간단하게 자기소개를 했는데, 생각보다 부트캠프 수료자가 많았다. 나에게는 이번 인턴십이 첫 교육이어서 그분들이 너무 부러웠다. 이런 분들 사이에서 내가 팀장을 맡아도 되나.. 싶은 생각이 또 들었었다.

첫 과제

첫 과제는 프리온보딩 인턴십에 지원할 때 작성한 사전 과제를 바탕으로 진행됐다.. 기한은 그 주 금요일 24:00까지. 이번 회의에서는 소통 창구 생성, 깃허브 공유, 깃허브 조직 생성, husky 담당 선정, 코드 리뷰 방식 등을 논의했다. 코드 리뷰는 사전 과제 요구사항을 토대로 목요일 오전 10시까지 모여 의견을 나눠보는 걸로 했다.

 

README.md의 중요성

 코드 리뷰를 한창 하고 있는데, 팀원 한 분이 '짧게라도 코드 설명을 추가해보는건 어때요?'라는 의견을 주셨다. 어떤 식으로 진행될지 모르는 회의를 위해 본인 제외 9명의 코드를 리뷰해야 하는 피로도를 줄이기 위함이라고 하셨다.

이 말을 듣고 얼마나 부끄러웠는지 모른다. 다급하게 내 README 파일을 들어가보니 기능이나 구조 설명이 전혀 없었다.

 이왕 설명을 추가하는 김에 나라면 다른 분들의 코드에서 어떤 점을 볼 것 같은지, 코드를 이해하는 시간을 단축시키려면 어떤 설명을 넣어야 하는지 고민했다. 코드 리팩토링은 없이 진행하기로 했기에 부족한 부분이 많이 보였지만 아쉬움을 꾹 참고 글로써 보완해야 했다.

 고민 끝에 나는 다음 내용을 추가하기로 결정했다.

  • 주요 파일 설명

나는 page 역할을 하는 컴포넌트를 분리하지 않았기 때문에 파일 수는 적지만 그래도 역할을 명시해 주기로 했다. 파일 구조를 VScode의 file-tree-generator를 사용해 붙여넣었다. 그리고 중점적으로 봐주셨으면 하는 파일에 별표(*)를 쳤다.

  • 각 파일에 쓰이는 함수 역할 설명

 코드 리뷰를 해보니 state나 handler들을 hooks라는 다른 파일로 빼버리신 분들이 많았다. custom hook에 대해 개념이 부족했던 탓인지 state와 handler를 한 번에 뺄 생각은 못하고 한 파일에 같이 썼다. (다시 보니 가독성이 매우 나빴던)

 한 파일에서 복잡한 코드를 읽으실 분들을 위해 각 함수의 역할을 짧게 작성했다. useEffect에서 어떤 역할을 하는지도 작성했다! 그나마 다행인 점은 함수명은 직관적이게 제대로 썼다... 

  • 사용한 기술

크게 사용한 기술은 없지만 로그인 전역 상태 관리를 위한 Context와 API 요청으로 axios를 사용한 것을 작성했다. 그리고 TodoList 파일에서 반복문을 통해 TodoElement를 컴포넌트를 렌더링 하고 있다는 점도 명시했다. 

 

https://github.com/YejinHwang-D/wanted-pre-onboarding-frontend

 

GitHub - YejinHwang-D/wanted-pre-onboarding-frontend: 원티드 프리온보딩 프론트엔드 과정 선발 과제

원티드 프리온보딩 프론트엔드 과정 선발 과제. Contribute to YejinHwang-D/wanted-pre-onboarding-frontend development by creating an account on GitHub.

github.com

 이렇게 쓰고 나니 한결 정리된 느낌도 들고 뭔가 도움이 될 것만 같았다!

실제로 README 수정 후 Slack에 추가했다는 말을 전하니 팀원 한 분께서 깔끔하게 잘 썼다며 내 양식을 참고해도 되냐고 여쭤보셨다. 😆

 

코드 리뷰 후 Best Practices 산출

 대망의 코드 리뷰 시간이 왔다. 그래도 명색이 팀장이니 회의를 이끌어야 해서 이것저것 멘트도 생각해두고, 정해야 할 목록들을 미리 작성했다. 짧은 시간 내에 코드를 합쳐야 했으니 처음부터 끝까지 다 개발하는 건 말이 안 된다 생각했다. 때문에 Best Practices를 선정할 때 프로젝트 구조에 대한 부분도 결정을 해서, 그분의 구조를 기반으로 역할을 나누는 것을 제의했다. 다행히 잘 받아들여져서 한 팀원 분의 코드를 기본 베이스로 정했다.

 이후 논의 과정은 2시간 가량 꽤 길게 이어져서 아래의 깃허브 링크에서 확인할 수 있다. 베이스 코드에 논의에서 결정된 내용을 추가/개선하기로 했고, 역할 배분은 컴포넌트, 훅, API, 리다이렉트로 나눴다. 나는 API 쪽을 맡았고 한 분과 같이 진행했다. 사실 사전 과제 자체가 그렇게 큰 프로젝트가 아니고, 이미 다 개발된 상태에서 선정한 거라 정말 빨리 끝났다.

 TMI로 이번 과제의 README도 내가 작성했다. 연습도 하고 싶고 README 정리하는 것에 재미가 붙어서 개발이 마무리될 때 쯤 회의록을 바탕으로 README 초안을 Slack에 보내봤고, 반응이 좋아 내가 담당하기로 됐다. (신난다!🐾)

 

무시무시한 Git 관리

 많아봤자 3~4명의 팀원으로 진행하거나 혼자 프로젝트를 했던 나에게는 Git history 관리가 어려웠다. 첫 회의에서 Github Flow 전략을 사용하자고 결론이 나왔는데, 이런 전략도 없이 그냥 main 브랜치에 push, push, push... 만 해왔던 나는 정말 감사하게도 팀원의 도움을 많이 받았다. 😂

 가장 무서웠던건 merge였다. 제대로 쓸 줄 몰랐던 나는 혹시 내 실수로 main에 미완성 코드를 합치거나 되돌릴 수 없는 실수를 하게 되어 팀원의 노력을 없앨까 봐 무서웠다. 특히나 api 쪽은 개발할게 많지 않아 비교적 빠르게 시작했는데, main 브랜치에서 변경사항이 생겼다.(패키지 설치 등) 그래서 main의 내용을 가져와야 하는 상황인데, 이 경우가 처음이라 새벽 4시까지 잠도 못 자고 고민했다. 서칭 해보니 git rebase main으로 브랜치 변경사항을 가져오면 된다해서 입력했더니 main의 변경사항은 가져왔지만 '현재 브랜치와 origin/~가 갈라졌습니다.'라는 경고 문구가 떴다. 바로 여기서 git pull origin 브랜치명 --rebase를 했더니 오류없이 push가 가능했다! 

이후에도 추가된 브랜치를 위해 git remote update를, 병합 기간에는 main에 merge 했을 다른 팀을 생각해 개발 및 수정 전 git pull origin main을 습관화했더니 무리없이 진행이 가능했다.

정말 귀한 경험이었다.

 

마무리

일주일이 순식간에 지나간 것 같았다. 너무 긴장한 탓인지 잠도 잘 못 자고 하루종일 긴장 상태라 소화도 안 됐지만 그만큼 보람차고 기쁜 한 주였다. 특히 Git에서 force 옵션을 쓰지 말라던 사람들의 말을 뼈저리게 깨달을 수 있었다. (아주 아주 위험한 명령어..)

 

마지막으로 재학생 시절 참여한 RocksDB 연구 스터디에서 교수님께 정말 칭찬받았던 README가 생각났다. 이때 시각 자료도 만들어가며 하루를 꼬박 README 정리하는 데 썼던 것 같은데... 이번에는 왜 처음부터 그러지 못했는지 아쉽다. 그래도 좋게 마무리되었으니 문서 정리의 중요성을 잊지 말고 살면 된다!

 

생각난 김에 자랑 겸 도움이 될까 하여 링크 남긴다. 😋 

https://github.com/YejinHwang-D/RocksDB_Festival/tree/main/RF7_Team_Interface

 

GitHub - YejinHwang-D/RocksDB_Festival

Contribute to YejinHwang-D/RocksDB_Festival development by creating an account on GitHub.

github.com