팀 프로젝트 회고 : 괴발개발

괴발개발 깃허브  |  괴발개발 바로가기  |  팀노션  |  괴발개발 기획서  |  컨벤션


안녕하세요. 9월도 벌써 끝나버렸네요.
제가 데브 코스에 합격하고 공부한지 벌써 4개월이 지났습니다.
이번달 회고는 이번 프로젝트에선 어떤것을 배웠지?를 중점으로 회고하겠습니다.

🍁9월의 시작

9월 첫 주부터 저는 너무 바빴습니다. 일단 Typescript 사용이 능숙해지고 싶어서 이펙티브 타입스크립트 스터디를 진행했고 어떻게든 3주라는 시간동안 모든 챕터를 읽었습니다. 다 읽었다는 사실은 있지만 머리에 많이 남았나를 물어본다면 그렇게 많이 남지는 않는 것 같습니다. 하지만 책을 고작 한번 읽어서 마스터 할 생각은 없었고, 퀴즈를 제출하기 위해 생각해보고 이 부분이 오늘 읽었던 분량에서 중요한부분인지 판단하는 과정에서 Typescript를 처음배웠던 저에게는 언어에 익숙해지는 계기가 되어 저는 굉장히 뜻깊었던 스터디를 마무리했습니다.

스터디가 종료되자마자 프로젝트를 5인으로 시작하는듯 했으나 갑작스러운 팀원의 개인사정으로 인해 2명이 그만두게되어 3인으로 시작하게 되었습니다. 너무 갑작스러워 팀프로젝트가 잘 진행될 수 있을지 걱정되는 마음으로 데브코스에서의 첫 팀프로젝트를 진행하게 됩니다.

🐾괴발개발

📅기획

괴발개발은 우리 팀의 프로젝트 이름입니다. 다들 개발새발로 많이 알고있지만 유퀴즈에 예전에 언급되었던 '고양이와 개가 이리저리 돌아다니며 어지럽게 발자국을 찍어 놓은 모양'이라는 뜻의 말로 개발(開發)과 동음이의어 개발로 끝나는게 마음에 들어 괴발개발로 프로젝트명을 정하게 되었습니다.

이번 팀 프로젝트의 주제는 SNS로 모든 팀이 공통 API를 이용해 자유로운 주제로 SNS 기능을 구현하면 되었습니다. 마크다운 문서 편집기를 직접 만드는것이 우리가 설정한 도전 과제였습니다.

프로젝트 개발을 하며 많은 것을 배웠지만 인원이 부족해 3명으로 기한내에 만들 수 있는 프로젝트를 제한적으로 정할 수 밖에 없는 상황이 너무 아쉽게 느껴졌습니다. 하지만 멘토님의 1차 피드백 “참신한 아이디어로 프로젝트를 만들어 포트폴리오에 넣는것”이 아닌 지금까지 배운 javascript 지식과 SPA 프로젝트의 기본기를 다지는 것에 의의가 있고 다행히 이러한 관점에서 적절한 프로젝트 기획이라고 해주셔서 감사했습니다.

🎨디자인

우리는 Figma를 이용해 함께 웹페이지 디자인을 했고 UI/UX 디자인도 중요하지만 일단 개발 시간이 많이 부족할 것 같다는 생각에 다른 사람들이 만들어 놓은 디자인을 여러곳에서 가져와서 조합해서 사용했습니다. Figma

🔨개발 진행 방식

아토믹 디자인 패턴

카카오 엔터테인먼트 기술 블로그의 글을 참고해 공통으로 사용하는 부분을 atoms, molecules, organisms, templates, pages로 나눠 가장 처음에 개발하고 각자 해야하는 부분은 이 부분을 다 하고 구현하도록 노력해봤습니다. 가장 공통으로 많이 사용하는 atoms, molecules는 모든 요소를 스토리북으로 구축했고 organisms는 선택적으로 구축했습니다.

느낀점

아토믹 디자인 패턴은 컴포넌트 재활용성을 극대화할 수 있는 방식으로 설계할 수 있다는 장점이 있고 개발을 하며 느끼기도 했습니다. (가장 기본적인 atoms는 정말 많이 재사용했던 기억이 있습니다.😁) 하지만 단점도 느껴지게 되었는데 컴포넌트를 만들었을 때 고려하지 않은 방식으로 사용하게 되면 컴포넌트를 고치거나 따로 만들어서 사용해야하는 불편함이 있었습니다. 그리고 그렇게 수정하다보면 컴포넌트가 지나치게 복잡해진다는 느낌이 들었고 이런 문제점들을 미리 예상하며 만들려고 노력하기때문에 컴포넌트를 만드는데 시간이 오래 걸리는 문제가 있었습니다. 하지만 한번쯤은 사용해보면 좋은 패턴이라 생각하고 설계를 잘한다면 굉장히 효율적인 방법이라 생각합니다.

사용 기술 스택

zustand, context API

zustand는 전역상태

1. 다크모드인지 판별 & 색상 전역 변수로 설정
2. 브라우저의 크기 저장용
3. 로그인 토큰 저장용

이 세 가지로만 사용하고 나머지는 props로 전달하거나 context API를 이용해 컴포넌트를 묶어 변수를 공유했습니다. zustand로 전역적으로 모든 컴포넌트들이 사용할 수 있는 스토어를 사용하는것 보단 컨텍스트 단위로 묶어 공유할 수 있는 컴포넌트들을 한정해 구역을 명확하게 나누는 방법이 깔끔하고 좋다고 느꼈습니다. 개발 후반에 이 방식을 사용했기 때문에 props를 많이 사용해 코드가 복잡하게 느껴지는데 리팩토링할 때 처음에 props를 사용했던 컴포넌트들을 context API를 이용해 깔끔하게 정리할 예정입니다.

react-query

리액트 쿼리는 데이터 Fetching, Caching, 동기화, 서버 데이터 업데이트 등을 비동기적으로 쉽게 만들어 주는 라이브러리인데 서버에 요청하는 작업을 거의 하지 못해 아직 어떤 방식으로 사용되는지 잘 모르는 상태입니다. 굉장히 편리했지만 무턱대고 쓴 느낌이라 다음 최종 프로젝트때는 반드시 어떻게 사용하며 어떤 점에서 좋은지 공부하고 사용해볼 예정입니다.

storybook

위에서 언급한 아토믹 디자인 패턴을 적용한 atoms, molecules, orgarnism에 스토리북을 이용해 구축했습니다. 각각의 컴포넌트들을 스토리북을 사용해 원하는 방식으로 커스텀해볼 수 있도록 만들었고 다른 사람이 만든 컴포넌트를 코드에 적용하기 전에 미리 사용해볼 수 있어 유용했습니다.

느낀점

스토리북을 이용한 결과 코드를 읽을줄 아는 개발자끼리는 큰 필요는 없는것 같습니다. 사실 스토리북을 실행시켜서 볼 시간에 컴포넌트를 사용해서 직접 구현해보는게 좀 더 친숙했던것 같습니다. 하지만 스토리북은 개발자끼리 하는 프로젝트보단 디자이너와 협업할 때 효과적이라 생각하기 때문에 사용할 줄 안다면 큰 도움이 될거라 생각됩니다. 하지만 아토믹 디자인 패턴을 사용해서 유용하게, 효과적으로 사용한 것 같지만 다른 방식으로 프로젝트를 진행한다면 과연 효과적일 수 있을까? 라는 생각은 듭니다. 다음 프로젝트를 진행할때는 사용을 굳이 하지는 않을것 같습니다.

prettier, eslint, husky, lint-staged

사실 husky와 lint-staged는 다른팀이 사용하기에 이게 뭔가? 하는 궁금증이 먼저 들었고 공식문서를 보고나니 일관성 있는 컨벤션 및 빌드에러 방지를 위해 기능이 좋다고 생각해 도입하게 되었습니다.

느낀점

직접 사용해보니 여러 작업을 한번에 할 때 오류가 하나라도 있으면 커밋이 되지 않아 브랜치를 옮기기 힘든 부분을 제외하면 굉장히 만족스러운것 같습니다. 또, 사람마다 코딩하는 방식이 달라 통일하기 힘든데 prettier와 eslint를 통해 컨벤션을 강제하니 실수할 일도 없고 파일이 변경되는 일도 없어 너무 좋았습니다.

react suspense 사용

React v18.0에서 정식 추가된 기능으로 컴포넌트의 랜더링을 어떤 작업이 끝날 때까지 잠시 중단시키고 다른 컴포넌트를 먼저 랜더링할 수 있습니다. 네트워크를 통해 비동기로 데이터를 가져오는 작업을 할 때 스켈레톤 컴포넌트를 먼저 보여주는 방식으로 사용했습니다.

Error Boundaries 사용

UI의 일부분에 존재하는 자바스크립트 에러가 전체 애플리케이션을 중단시켜서는 안 됩니다. React 사용자들이 겪는 이 문제를 해결하기 위해 React 16에서 도입된 개념입니다. 하위 컴포넌트 트리의 어디에서든 자바스크립트 에러를 기록하며 깨진 컴포넌트 트리 대신 폴백 UI를 보여주는 React 컴포넌트입니다. 에러 경계는 렌더링 도중 생명주기 메서드 및 그 아래에 있는 전체 트리에서 에러를 잡아냅니다.

👨‍👨‍👧협업 진행 방식

팀 프로젝트 경험에서 가장 중요한 어떻게 협업했는가?를 지금부터 소개하려합니다.
다행히 다들 서로의 의견 수용을 잘 해줘서 순조롭게 흘러갔던 것 같습니다.

또한, 인원이 부족하다보니 개발 시간이 많이 필요하다 느껴 평일 10:00 ~ 19:00에는 개발을 하기로 약속했고 가끔 오프라인으로 만나야할 때를 제외하곤 약속이 잘 지켜졌습니다.

Notion

모든 계획과 협업 규칙 기록은 노션에서 진행했습니다.

스크럼

스크럼은 매일 오전 10시에 시작했고

• 오늘 할 일 공유
• 어제 진행한 내용중 새로운 내용 공유

이 두가지 사항을 이야기했습니다. 원래 계획은 10~20분동안 진행하는 것이었는데 예기치 못한 일이 생긴 경우는 길어지기도 했고 프로젝트 마무리단계에선 문제를 해결하느라 1~2시간 정도까지 진행했던적도 있습니다.

스크럼시 그날의 해야할 일을 정했고 아래와 같은 방식으로 작성해 완료하면 체크박스에 체크하는 방식으로 진행했습니다.

저희는 지난 7월에 들었던 함께 자라기의 저자 김창준님의 특강에서 효과적으로 일하셨던 방식인 하루 일하는 시간을 정하고 그 시간까지 해결하지 못하면 함께 해결하는 방식을 채택해 진행했기 때문에 그날의 일정에 따라 오후 5시~6시 사이에 항상 모여 7시까지 진행 상황과 해결하지 못한 문제가 있다면 함께 해결하는 방식으로 프로젝트를 진행했습니다.

저는 도움을 많이 받았던 입장으로써 이런 제도가 좋기도하지만 남에게 피해를 주는건 아닐까 하는 생각에 편집기를 정할 때 삽질을 굉장히 오래 했는데 이를 팀원에게도 공유하긴 했지만 제가 할 수 있다고 생각해 혼자 해결하려고 했던점은 많이 잘못되었다고 생각하고 반성합니다. 미리 공유하고 확실하게 함께 해결했으면 좋겠다고 얘기했다면 금새 해결될 일이었는데, 편집기를 만들기 위해 노력도하고 시간이 없는데 커스텀이 필요한 편집기를 사용하려한다던지 하는 굉장한 삽질은 하지 않았을 것이라 생각됩니다.

일정 & 스프린트

일정관리를 캘린더로 했는데 스프린트2까지 목표했던 기능은 전부 완성하고 편집기를 만들어볼 예정이었는데 일정이 예상보다 많이 밀려 스프린트3에서 기능 구현도하고 버그 수정 및 디자인 디테일 & 최종 발표를 위한 데이터 만들기 작업을 진행했습니다.

Git & Github

칸반보드

협업을 위해 가장 많이 사용하는 Github을 사용했고 스크럼에서 그날의 해야할 일을 전부 이슈로 만들고 진행상황을 칸반보드를 통해 팀원이 전부 알 수 있어 굉장히 유용했습니다.

issue & pull request 템플릿

issue와 PR은 템플릿을 작성해 작성할때마다 편하게 사용할 수 있었습니다.

브랜치 전략

생성한 issue 번호를 브랜치에 입력하며 중복되는 브랜치명이 존재하지 않도록 설정했습니다.
hotfix도 동일하게 뒤에 #{이슈번호}를 붙이는 방식을 사용했습니다.

main <—————— dev <—————— feature/#{이슈번호}

           [hotfix]

github action을 이용한 issue 자동 close

데브코스에서 함께 학습하는 교육생분의 공유를 통해 github action을 처음 접하게되었고 PR시 사진과 같이 작성하고 Merge될 때 자동으로 해당 번호의 issue가 닫히는 기능도 사용해봤습니다. 더 많은 기능도 있는데 다음 프로젝트에선 더 사용해볼 수 있도록 노력할 예정입니다.

Merge 규칙

main과 dev는 push할 수 없게끔 github 설정으로 막아놓고 PR만으로 merge할 수 있도록 했습니다. 이때 PR은 1명 이상의 approve를 받아야만 가능하도록 설정했습니다. 다만 아쉬운점은 시간이 없어 기능 구현에 급급해 코드리뷰를 하지 못했던 점이 너무 아쉽습니다. 다음팀에선 코드리뷰하는 시간을 고정적으로 설정해 진행해보는 시간을 가져도 좋겠다고 생각했습니다.

🎭 마무리: 프로젝트 회고

Keep

• 구현하기 위해 많이 생각해보고 실행함 -> 코딩하기로 한 시간 외에 한 생각
• 적극적으로 하고싶은 부분 어필해서 진행함(사이드바)
• 새로운 기술을 도입하는데 적절한 수준의 러닝커브를 가진 기술만 도입함
• 팀원과의 소통을 위해 슬랙을 꾸준히 들어가 의사소통 문제가 생기지 않도록 함
• 새로 알게된 부분은 글을 작성해 기록으로 남겨둠

Problem

• 혼자 고민하는 시간이 너무 길다. -> 너무 비효율적으로 시간을 쓴 느낌
• 일처리가 느리다. -> 고민하느라 너무 비효율적으로 시간을 쓴 느낌
• 사용하는 기술에 대한 지식이 부족하다.
• 태스크를 에픽단위나 스토리 단위로 나누지 못함.
• 원래 gpt를 사용하지 않는데 갑자기 너무 의존하려함.-> 직접 찾는게 더 양질의 정보가 있었음

Try

• 일정 관리를 두루뭉술하게 하지말고 구체적으로 설정하자.
• 고민하는 시간은 최대 1시간! 그 이상이 된다면 하나에 꽂혀서 삽질하고있을 가능성이 높으니 팀원에게 도움을 요청하자.
• 서버 요청과 관련된 일도 해보자. (이번 프로젝트에선 다른것을 하느라 잘 못한것 같다. react query에 익숙해지자)
• 너무 이것저것 하려하지말고 한번에 하나의 일만 처리하자!
• 에러상황도 놓치지말고 문서화 해보도록하자

Feel

이번 프로젝트를 하며 느낀점은 나는 너무 삽질을 많이 했다! 입니다. 정말 많은 삽질을 했고 그로 인해 일정이 자꾸 딜레이 되는 바람에 팀에게 피해를 줬던것 같습니다. 문서 편집기에서 이 죄송함이 제일 커졌고 이 일 이후로 제가 하나에 꽂히면 그 부분에 심취해 다른 생각을 못한다는 점을 뼈저리게 느꼈고 제가 이 상황에서 빠져나오려면 다른 사람의 도움이 필요하다는것을 느꼈습니다. 다른 팀원에게 도움을 요청하는 것도 사실 죄송한 일이지만 일정이 밀려 피해를 주는것보단 나을거라 생각해 마음을 조금 가볍게 가지도록 노력해보려합니다. 이번에는 이렇게 했지만 인지하고 다음 프로젝트에는 같은 실수를 반복하지 않는다면 저는 큰 성장을 할 수 있을 것 같습니다. 시간 부족 문제도 해결될 것이고 그 남는시간에 개발을 하거나 부족한 지식을 채워넣는 공부를 할 수 있는 시간도 생기고 굉장히 좋은 효과가 있을 것이라 생각됩니다.