🔍 프로그래머스 FE 데브코스 5기 12월~1월 한 달 회고 | 2차 프로젝트 MIL

🚀 Intro

지난 3차 단위기간 MIL 작성 때 설정한 4차 단위기간 목표들부터 점검해보자.

• 2차 팀 프로젝트 기한 내 기본 및 보너스 요구사항 구현 완료하기 ✅
  기본 요구사항부터 보너스 요구사항까지 무사히 구현했다! 걱정 반 기대 반이었던 2차 프로젝트였지만 큰 이슈 없이 성공적으로 마무리해서 뿌듯하다! 😜
  
  
• 처음이자 마지막인 딥 다이브 무사히 완료하기 ✅
  개발관계론 이란 제목으로 발표했다. 가볍게 경험 삼아 시작해보려고 한 발표였는데 많은 분이 관심과 기대를 해주셔서 프로젝트로 바쁜 와중에도 준비를 열심히 했었다. 발표 당일 전날에도 프로젝트 task를 마치고 밤새 발표 준비를 한 덕분인지 절지 않고 발표를 마칠 수 있었다. 😅
  
  
• 건강 챙기자 ✅
  항상 따뜻하게 방 온도를 유지하고 잠도 최대한 챙기면서 프로젝트를 진행하려고 노력했다. 피곤하면 조금이라도 자고 일어나서 코딩하는 식으로 피로를 이기려고 하지 않았다. 덕분에 4차 단위기간에는 크게 아픈 적 없이 건강하게 프로젝트를 마무리할 수 있었다.

---

💻 2차 프로젝트 회고

한달 반가량의 시간 동안 꽉꽉 채워서 2차 팀 프로젝트를 마무리 지었다.
OOTD를 공유할 수 있는 패션 특화 SNS 서비스 STYLED를 개발했다.

기본 및 보너스 요구사항까지 모두 구현하였고 추가적인 디자인이나 성능 최적화도 최대한 진행해보았다.

프로젝트를 진행하면서 생긴 이슈나 고찰 및 느낀 점을 공유해보려고 한다.

🧐 기획이 반

프로젝트 기간은 총 6주 남짓이었지만 기획에만 거의 1주가 소요되었다.
코드 및 PR 템플릿부터 디렉터리 구조 및 기능별 task 칸반보드, 피그마 디자인까지 꼼꼼하게 기획을 먼저 완료한 뒤에 개발에 돌입했다.

처음에는 기획을 간단하게 하고 개발을 빨리 돌입하는 것이 기간 내에 프로젝트를 완료하는 방법이라고 생각했다.
하지만 같은 팀 인혁님이 기획과 개발 방향성을 5명 팀원의 모두 제대로 파악하고 있지 않는다면 나중에 더 큰 혼란과 이슈를 맞이할 수도 있다고 경고 의견을 내주었다.

결과적으로 인혁님의 의견이 신의 한 수였다. 멘토님께서도 기획에 시간을 많이 들인 것에 대해서 잘한 선택이라고 하셨다. 실제로 개발을 돌입하기 전에 팀원 모두가 서비스에서 개발할 기능들과 디자인 및 코드 컨벤션을 완전히 숙지하지 않았다면 중후반부 스프린트에서 발생했던 기능 및 디자인 관련 이슈 및 충돌상황에서 큰 어려움을 겪었을 것이다.

노션 칸반보드를 통해 세부 기능별로 task를 기획 단계에서 잘 나눠놓은 것도 큰 도움이 되었다.
보통 각자의 기능을 구현한 뒤 PR을 통해 머지하다보면 잦은 충돌이 발생하기 마련이다.
하지만 위와 같이 세부적으로 task를 나누었기에 같은 파일을 수정하는 일이 적어 충돌 해결할 상황이 페이지 컴포넌트를 합칠 때 외에는 크게 발생하지 않아서 좋았다.

이러한 경험 덕분에 앞으로도 프로젝트를 진행하기에 앞서 개발을 같이 진행할 팀 내에서 기획과 개발 방향성을 심사숙고하여 정하고 해당 내용을 모두가 숙지하고 있는 것이 중요하다는 것을 깨달았다.

🙌 진짜 협업을 경험하다

이전까지는 팀 프로젝트를 진행해본 것은 처음 개발에 대해 입문하면서 KB 국민은행 주관 데이터 분석 교육에서의 파이널 프로젝트가 전부였다.

하지만 그것조차 데이터 분석을 찍먹하는 정도였다.
당시에는 분석한 결과를 웹 페이지를 통해 사용자에게 표시해주기 위해서 python Django를 사용해 구현했다. 이 부분도 팀원 중 미리 프론트엔드를 해보았던 친구가 전담했고 난 보조였다.

따라서 이때까지 제대로 된 팀 프로젝트를 해본 경험은 전혀 없었다. 개발 공부를 시작한 건 2년이 넘어가는 데 아직 협업 경험이 부족하다는 것이 나에게는 큰 치명적인 단점이었다.

이번 데브코스 2차 팀 프로젝트 기획을 마친 뒤 1주 정도 개발을 진행한 뒤에 난 먹먹한 감정을 느꼈다.
5명의 팀원과 밤낮으로 고민하여 서비스를 기획한 뒤에 각자 맡은 task를 개발하고 PR을 통해 코드리뷰를 받아 머지하는 일련의 협업 과정들이 하나도 힘들지 않고 오히려 재미를 느끼고 뭔지 모를 희열을 느꼈기 때문이다.
오죽했으면 그때 이렇게 팀 슬랙에 글을 남겼었다. (진짜 진심이었다...)

팀 프로젝트를 마친 지금은 이제는 협업에 대한 막연한 공포와 부담감은 말끔히 사라졌다. 그리고 당당히 나도 한몫 기여한 팀 프로젝트 경험과 포트폴리오가 생겼다는 것에 큰 자신감을 얻었다.

❓ 재사용하기 좋은 컴포넌트란?

위 사진은 내가 만들었던 공용 컴포넌트 중 하나인 Modal 컴포넌트이다.
처음 Modal을 구현하고 난 후 난 생각했다.

이 정도면 잘 구현했겠지?! 모든 경우에 다른 팀원들도 잘 사용할 수 있는 멋진 Modal 컴포넌트군!

에나꽁꽁(에게의 경상도 진주 지방 방언)? 어림도 없었다.
Modal 컴포넌트에 대해서 큰 이슈가 두 가지 정도 발생했었다.

1. Modal 전체를 감싸고 있는 wrapper의 width와 height를 100vw, 100vh로 지정해서 모달 크기가 부모 요소에 맞게 작아지는 현상

2. Modal의 렌더링 위치가 사용하는 컴포넌트에 국한되어서 모달 동작 및 렌더링이 겹치는 현상

이와 같은 에러 및 이슈를 팀원들이 사용하면서 바로 공유해주었고 이를 바로 수정해서 재수정 PR로 해결을 완료했다.

완벽했다고 착각했던 Modal 컴포넌트가 이러한 결정적인 이슈를 가지고 있었다는 사실에 또 한 번 크게 깨달았다.

모두가 사용할 수 있는 공용 컴포넌트를 만들 때는 props, 이벤트 동작, 디자인 등 생각할 수 있는 모든 경우의 수를 고려하는 것이 중요했다.
그래서 나처럼 일단 아무런 계획 없이 구현하다 보면 다른 사람이 사용해보고서야 이슈를 발견하고 이를 또 고치는 불필요한 수정 task가 발생했다.

따라서 컴포넌트를 구현하고 이를 다른 사람이 사용하더라도 옵션을 잘 사용할 수 있거나 추가적인 props 및 style을 부여할 수 있도록 예비조치가 꼭 필요하다는 것을 깨달았다.

항상 코드를 짜기 전에 구현에 대해서 추상적으로 생각하자. 그리고 다양한 엣지 케이스를 고려하자.

🏋️‍♀️새로운 기술 스택 학습 근육 단련하기

이번 프로젝트에서 처음 접했거나 얕게 알고 있었지만, 다시 제대로 공부하면서 사용한 기술 스택 및 라이브러리는 다음과 같다.

• React : 리액트 내 기본 훅 및 TS로 React 사용
• TypeScript : props, 이벤트, Promise 타입 및 인터페이스
• React Query(Tanstack Query) : 비동기 api 통신 라이브러리
  useQuery, useMutation, useInfiniteQuery(무한스크롤)
• Zustand : 전역 상태 관리 라이브러리
• axios: 비동기 통신
• Material-UI : 다크모드 및 전역 스타일 관리
  useTheme, ThemeProvider
• styled-components : CSS in JS, 컴포넌트별 스타일 분기

사용했던 거의 모든 기술 스택을 다시 공부하면서 개발을 진행했다고 말해도 무방할 거 같다.

그럴 수밖에 없었던 게 메서드나 라이브러리 자체 문법 및 로직을 정확하게 이해하지 않은 채 사용하게 되면 수많은 에러를 만나게 되었기 때문이다.
설령 당장에는 에러가 없었다고 하더라고 이후 다른 기능이나 페이지를 연결하거나 개발 환경 및 배포에서 에러가 나는 결정적 원흉이 되었다.

따라서 공식 문서와 해당 기술 스택에 대해 정리한 수많은 기술 블로그들을 달고 살았던 거 같다. 최우선적으로 공식 문서에서 내용을 찾아보고 이해해보려고 노력했지만 axios나 react query 같은 경우는 관련 내용이 너무 간결하게 나와 있어서 이해가 되지 않았다. 그럴때마다 가장 최신 일자에 올라온 기술 블로그 내용을 참고하여 익혀나갔다.

그래서 실제 기능을 구현하는 시간보다 구현하기 위해 사용해야 하는 기술 스택을 공부하는 데 더 많은 시간을 할애했다. 덕분에 위 기술 스택에 대한 문법 및 파라미터, 옵션 사용법에 대해서 다른 팀원들에게 알려줄 수 있을 정도로 나름 전문가가 되었다.

앞으로 더 많은 새로운 기술 스택 및 기존 기술 스택의 업데이트를 만나게 되겠지만 이에 대해 공식 문서를 기반으로 공부해나갈 수 있는 근육을 기를 수 있었다.

🤴 돌돌팀장 이거 맞아?

1차 팀에 이어 2차 팀에서도 팀장을 맡게 되었다.
1차 팀에서는 따로 팀 프로젝트가 없었기 때문에 크게 부담이 되지 않았다.
하지만 2차 팀에서는 팀 프로젝트가 있었기에 처음에는 뭔가 두려웠다.

팀 프로젝트는 팀원 모두가 각자의 역할을 잘 수행하고 팀워크가 중요하다.
난 개발 실력 자체가 월등하지 않다고 스스로 생각하기에 이 팀워크를 어떻게 잘 만들어줄 수 있을까 고민을 아주 많이 했던 것 같다.

내가 팀장으로서 노력한 부분은 다음과 같다.

1. 1차 팀에서도 그랬듯이 팀 결성 뒤 초반에 어색한 기간을 최소화하려고 했다.

좋은 팀워크를 위해서는 서로에 대해 개발적인 부분과 그 외의 정보에 대해서도 잘 알고 친밀감이 가장 중요하다고 생각했기 때문이다.
이 부분은 오프라인 커피챗과 소프트 스킬 마스터 세희 멘토님의 도움으로 급속도로 해결되었다. (바퀴벌레 포커 캐리)

2. 팀 프로젝트 일정을 리마인드했다.

프로젝트 진행 시에 팀이 전체적인 흐름을 잃지 않도록 스크럼과 회의에서 Todo List와 개발 일정을 끊임없이 리마인드했다. 덕분에 나도 잊지 않고 프로젝트 일정을 진행할 수 있었다.

3. 팀 회의 시에 각자의 의견을 낼 수 있도록 독려했다.

기획할 때 각자의 생각과 견해에 대한 공유가 필수였기에 한명 한명 의견을 물어보면서 서로의 의견을 잘 파악할 수 있도록 하였다. 나중에는 내가 굳이 독려하지 않아도 적극적으로 변한 팀원들을 보면서 뿌듯했다.

4. 깃허브 슬랙 연동과 vercel 배포 및 깃허브 레포 전체 관리, 최종 발표 영상 제작 및 편집을 도맡았다.

나도 잘 알고 있었던 건 아니지만, 팀원들은 개발에만 집중할 수 있도록 각종 개발에 도움될만한 기능이나 배포 및 깃허브 레포 관리, 발표 영상 편집과 같은 부수적인 업무는 내가 맡아서 했다. 덕분에 매우 편했다는 팀원들의 피드백을 듣고 정말 보람찼다.

이외에도 팀원들의 질문에 적극 참여해서 같이 해결하려고 하고 깃허브나 개발 도중 에러가 발생하면 먼저 같이 해결하고 넘어가려고 했더니 어느샌가 나도 깃허브를 잘 다룰 수 있게 되었고 프로젝트의 전체적인 흐름을 파악하는 데 도움이 되었다.

힘든 만큼 팀장을 맡길 잘했다고 생각했다. 그리고 그 누구보다 열심히 팀원들 모두가 각자의 역량을 최대한 뽐낼 수 있도록 도와주려고 애썼다. 프로젝트가 마무리되고 나에게 고생했다고 말해주는 팀원들의 말에 정말 뭉클했다. 고마워요 세희팀...

🧾 클린 코드의 중요성

난 맡은 task을 진행할 때 일단 기능이 구현되는 것을 최우선적으로 목표하여 코드를 짰다. 그렇게 기능을 구현하고 어느 정도 깨끗하게 주석과 코드를 작성했다고 생각하고 PR을 넣었으나 다른 팀원들의 코드를 보니 한참 부족하다는 것을 깨달았다.

내가 작성한 메인페이지의 코드는 무려 300줄이었다.

하지만 승민님의 유저 페이지나 현주님의 DM 페이지는 100줄 이내로 끝났다.

이걸 보고 난 적지 않게 충격을 받았다.
물론 다양한 기능들이 함축된 메인 페이지이기 때문에 코드가 상대적으로 길어질 수 있다고 생각할 수도 있지만 난 솔직히 말해 잡다한 로직이나 함수들 styled 컴포넌트 요소들조차 분기 및 정리되어 있지 않은 것이 사실이었다.

기능 구현에 집중한 탓도 있었지만, 처음부터 설계할 때 비슷한 기능들이나 역할에 따라 컴포넌트나 함수들을 분리하여 다른 디렉토리로 빼서 import 할 수 있도록 하는 것이 코드를 읽는 입장에서도 편한 것이 정설이다.

리팩토링을 추후 진행하면서 코드를 간결하게 변화시키면 되겠지만, 그 이전에 첫 구현 시에 조금 더 생각을 깊게 하고 코드를 짜는 것이 중요하다는 것을 깨달았다.

급한 내 성격도 한몫하는 거 같다. 일단 행동하고 보는 스타일이라 이 성격이 고스란히 코드에도 전해지는 것 같다.

하지만 이것은 결코 좋은 개발자의 자세나 습관은 아닌 거 같다고 스스로 생각이 들었다. 앞으로는 항상 코드를 짜기 전에 추상화와 구상에 대해 깊게 생각을 해보는 습관을 길러야겠다.

✅ 프로젝트에서의 나의 기여도 체크

이번 프로젝트에서 내가 수행한 task를 정리하자면 다음과 같다.

메인페이지

useInfiniteQuery를 통해 무한스크롤을 구현했고 zustand persist로 카테고리 채널 선택 상태를 세션스토리지로 새로고침 및 창을 이동해도 유지되도록 했다.

창이 작아지면 왼쪽 및 오른쪽 네비게이션이 트랜지션을 통해 사라지고 모바일 및 태블릿 디자인을 고려했다.

포스트 상세 페이지

메인 페이지 및 포스트 상세 페이지 좋아요, 팔로우, 댓글 실시간 api 연동

중첩 라우팅을 통해 배경에 이전 페이지가 있도록 구현

반응형 디자인

이외에도

• Modal, Image Upload, PostCard 공용 컴포넌트 구현
• 페이지 라우팅 및 중첩 라우팅 구현
• vercel 배포
• PR 템플릿 작성 및 적용...

이렇게 적고 보니 그래도 부끄럽지 않게 기여한 것 같아 다행이다. 내가 느끼기에는 세희팀에서 내가 가장 개발 역량이 부족한 것 같다. 다들 너무 코드를 깨끗하고 느낌(?) 있게 구현했다.

그래서 PR 코드 리뷰나 개발 방향성과 질문을 공유하고 의논할 때마다 항상 많은 것을 배우고 또 배웠다.
동시에 내가 조금 먼저 알고 있었던 vscode 내 git 사용법과 맡은 task를 진행하면서 공부한 react-query와 zustand 사용법에 대해서도 팀원들에게 쉽게 알려주려고 노력했다.

이번 팀 프로젝트를 통해 얻은 것은 개발 역량뿐만 아니라 서로의 지식을 공유하고 같이 공부해나갈 수 있는 좋은 동료를 얻었다.

💡 프로젝트 완성 후 보완할 점

프로젝트 주제의 차별성 미흡

프로젝트를 완성하고 각자 팀 프로젝트 발표 상영회가 있었다.
같은 api와 같은 요구사항을 가지고 시작했지만 정말 다양한 주제의 서비스가 있었다.

어떤 팀은 로그인 시 암호에 대한 보안 작업을 프론트엔드에서 구현한 팀도 있었고 슬랙 채널에 알림이 오도록 연결한 팀, 지도 api를 연결해서 사용자의 위치가 연동되도록 한 팀도 있었다.

이런 점을 보면서 우리 팀은 너무 기능 구현에만 치중한 경향이 없지 않다는 점을 느꼈다.

물론 모든 팀이 기능 구현을 완성한 것은 아니기에 기능 구현이 문제없이 깔끔하게 구현됐다는 것은 분명히 잘한 점이다.

하지만 멘토님께서도 지적한 부분처럼 어느 정도 비즈니스 모델과 연관을 지어보거나 특색있고 명확한 사용자를 대상으로 주제를 선정했으면 어땠을까라는 아쉬움이 남았다.

그래서 이번 2차 팀프로젝트는 react ts 기반의 다양한 기술 스택들을 사용한 기능 구현을 연습하고 협업에 대해 경험을 했다고 생각하기로 했다.

4차 단위기간에 있을 3차 파이널 프로젝트에서는 백엔드 데브코스 팀원들도 같이 협업할 수 있으므로 좀 더 서비스 주제와 타겟 사용자에 대해서 깊은 고민을 하여서 정말 실질적인 서비스 배포도 가능할 정도로 구현해보고 싶다.

깃허브 issue 및 actions, project 칸반보드 미사용

우리 팀은 노션 및 슬랙에서 task 일정을 관리했다. 노션 내 칸반보드와 슬랙에서 많은 질문과 이슈 공유를 통해 프로젝트 중 발생한 문제들을 해결했다.

결과적으로 프로젝트를 진행하는 데 있어서 큰 불편함을 없었다.

하지만 다른 팀 중에서 깃허브 내 issue, actions, project 탭의 기능들을 잘 사용해 프로젝트 진행 task를 잘 정리되어 있는 것을 보았다.

어차피 코드 버전 관리는 깃허브로 하는데 프로젝트 task 관리도 일원화하여 깃허브 내에서 처리할 수 있다면 함께 사용해보는 것도 좋았겠다는 생각이 들었다.

따라서 3차 프로젝트에서는 깃허브 내 task 관리 기능들을 사용하는 것에 대해 의견을 내 볼 예정이다. 대신 프로젝트 시작 전 사용법을 공식 문서를 통해 공부해야겠지...

성능 및 네트워크 호출 최적화 미완성

난 기능 구현을 우선하여 task를 진행하다 보니 불필요한 네트워크 호출 및 디바운싱, 쓰로틀링이 적용되지 않아 사소한 기능 에러가 발생했다.

처음 설계할 때부터 이런 부분을 고려했다면 좋았을 텐데 아직 기능 구현하는 것에 급급했다 보니 미처 점검하지 못했던 것 같다.

3차 프로젝트 때는 좀 더 성능이나 네트워크 최적화에 대해서 미리 생각해보아야겠다. 그리고 2차 팀 프로젝트에서 내가 구현한 부분에서 최적화할 수 있는 부분들에 대해서 리팩토링을 진행할 예정이다.

---

🤿 개발관계론 Deep Dive

해야지 말로만 약속했었던 딥다이브 발표를 3차 단위기간에 진행했다. (막차 탑승 완료)

개발 기술 스택에 대한 깊은 이해가 아직 부족했기에 내가 그래도 뭔가 많이 경험했고 전달할 수 있는 것이 무엇일까 고민했다.

그렇게 정한 주제가 바로 개발관계론.
개발자로서 협업할 때 다양한 사람들과 대화 및 의견 조율이 필요한데 이에 대해서 어려워하고 잘 못하는 사람들이 많다고 생각했다.

2차 팀 프로젝트 기간이기도 했고 나도 다양한 사람들을 만나보면서 얻은 나름의 커뮤니케이션 경험과 감명 깊게 읽은 데일 카네기의 인간관계론 책 내용을 바탕으로 발표를 진행하면 좋을 거 같아서 위와 같은 내용으로 발표를 진행했다.

발표 준비를 할 시간도 많이 없었지만 그래도 열심히 준비해서 나름 문제없이 발표를 마쳤다.
발표 전에도 적지 않은 분들이 내 발표 주제에 대해서 많은 기대와 응원해주셨고 발표 후에도 내용이 정말 좋았다고 평을 남겨주셔서 정말 하기 잘했다는 뿌듯함과 자신감을 얻었다.

데브코스가 끝난 다음 개발자 커리어를 밟아나가면서 내가 잘 알고 있는 개발 지식 및 경험들에 대해서 또 공유할 기회가 있다면 얼마든지 다시 하고 싶다.

정말 좋은 기회와 환경을 제공해주신 데브코스 및 매니저님, 프롱이들에게 다시 한 번 감사 드립니다.

---

🎯 5차 단위기간 목표

5차 단위기간이 시작되었다. 이제 3차 파이널 프로젝트가 곧 시작된다. 프론트엔드 뿐만 아니라 백엔드 팀원들과도 협업을 할텐데 정말 큰 관문이 남은 것 같다.

이번 5차 단위기간의 목표를 정리해보고자 한다.

• 차별성 있는 주제로 프로젝트 진행해보기

  2차 프로젝트에서의 아쉬운 점을 3차 프로젝트에서는 보완해서 주제를 잘 선정해볼 예정이다.

• 백엔드와 첫 협업 무사히 완료하기

  백엔드에게 요청할 수 있는 부분은 꼭 요청해보고 백엔드 측에서 요구하는 사항에 대해서도 맞춰서 개발을 진행해볼 생각이다.

• 이력서 점검 후 공고 지원 꾸준히 시작하기

  3차 프로젝트가 끝나면 바로 상반기 취준 시작이다. 미리 이력서 점검 후 단위기간 중에도 공고 지원을 넣어볼 것이다.

• 코딩테스트 준비 다시 시작하기

  이젠 코딩테스트 미룰 순 없다. 프로그래머스 1일 1문제를 JS로 다시 시작해보려고 한다.

• 토익 또는 토익스피킹 or OPIC 점수 미리 준비하기

  만료된 영어 점수 다시 찾자. 상대적으로 시간이 적게 드는 토익스피킹이나 OPIC을 먼저 딸 계획이다.

• 모던 JS / 리액트 딥다이브 책을 정독해서 부족한 부분 메꾸기

  공식문서와 함께 구입한 두 딥다이브 도서를 정독하여 기초를 다져야겠다.

• 기술 면접 CS 공부하기

  관련 깃허브 레포나 기술블로그, 책들을 통해 네트워크, 브라우저, JS 기본 동작 원리에 관해서 공부할 예정이다.

정리하고 나니 너무 많은데...? 하지만 중요한 건 꺾이지 않는 마음!
가보자고!!!