<초록집사> 프로젝트 회고

19일간의 팀 프로젝트가 끝났다.
이것은 나의 첫 팀 프로젝트였고, 처음이었던 만큼 많이 낯설고 어려웠지만
그래도 무사히 프로젝트를 완성할 수 있어서 뿌듯했던 시간이었다.

팀 소개 & 나의 역할

우리는 총 4명으로 구성된 팀이었다.
돌이켜 보면 개발 외에도 각자 잘하는 것이 있는, “밸런스가 좋은” 팀이었던 것 같다.
디자인 경력이 있는 팀원이 있었고, 문서화를 잘 하는 팀원, git 관리에 능한 팀원도 있었다.

이번 프로젝트에서 나는 팀장 역할을 맡았다.
팀장이었기에 회의 진행, 일정 관리, 역할 분배, 발표 등 개발 외적으로도 많은 일들을 해야 했다.
그래서 많이 힘들기도 했지만, 고생한만큼 많은 것을 느끼고 경험할 수 있었다고 생각한다.

기획

1. 프로젝트 개요

우리 팀은 “초록 집사”라는 웹 및 모바일용 어플리케이션을 기획하였다.
이름에서 유추할 수 있듯이, 반려식물에 관한 정보를 공유할 수 있는 SNS 플랫폼이다.
반려식물이란 ‘사람이 정서적으로 의지하고자 가까이 두고 기르는 식물’을 뜻하는 신조어이다.

프로젝트 개요를 정리하면 다음과 같다.

2.문서화

팀 프로젝트를 진행하면서 노션(notion)에 주요 문서들을 정리하고 일정을 관리하였다.
이 과정에서 정리 및 문서화가 개발만큼이나 중요하고 어렵다는 것을 깨달았다.

너무 바빠서 정리를 대충하고 싶은 마음이 때때로 들었지만,
그 때마다 마음을 다독이며 꼼꼼하게 문서들을 정리했던 것 같다.
덕분에 시간은 더 오래걸려도, 중요한 것과 중요하지 않은 것을 구별할 수 있게 되었으며
결과적으로 일의 효율이 상승하였다고 생각한다.

노션 문서

3. 와이어 프레임

Figma로 와이어 프레임을 제작하고 기능명세서를 작성하였다.
우리 모두 첫 프로젝트였기 때문에 간단한 와이어 프레임을 제작하는 것도 쉽지만은 않았다.

이 때 Figma가 큰 도움이 되었다. Figma는 기본적으로 협업 툴이기에,
팀원들과 의견을 나누면서 즉석에서 작업을 하는 것이 매우 쉬웠다.
Figma와 같은 협업 툴의 장점을 알 수 있었던 좋은 경험이었다.
문서를 공동으로 작업하는 것은, 혼자 작업하는 방식보다 훨씬 능률이 좋다는 것을 알게 되었다.

4. 디자인 시안

Figma로 디자인 시안을 제작하였다.
디자인을 담당하신 팀원 분이 있었지만, 다른 팀원들도 의견을 내면서 함께 만들었다.

뭐랄까…냉정하게 평가하자면 개발자의 입장이 과하게 반영된 디자인이라는 생각도 든다.
즉, “예쁘고 사용성이 좋은 디자인” 보다는, “개발을 하기 쉬운 디자인”을 추구했다는 생각이다.
예를 들어, 단순하고 반복적인 모양의 버튼이나 Input 등이 그러하다.
우리는 그것이 “재사용하기 쉬운 컴포넌트”가 될 것이라고 생각하며 디자인하였다.

물론 그 관점 자체가 나쁜 것은 아니라고 생각한다.
그렇지만 사용자를 위한 디자인이 아닌,
우리 개발자를 위한 디자인을 중시했다는 점에서 아쉬움이 남는다.
이것은 분명히 반성해야 할 점이라고 생각한다.

개발

1. 사용 기술

프로젝트에서 우리는 JavaScript를 기반으로 React를 사용하였다.
그 외 라이브러리는 React Router 등을 사용하였고 스타일 관리는 emotion으로 하였다.
패키지 관리는 yarn을, 컴포넌트 관리는 Storybook을 사용하였다.
ESLint와 Prettier로 코드 컨벤션을 통일하였으며, Netlify로 최종 배포하였다.
이를 정리하면 다음과 같다.

여기서 지적하고 싶은 것은 Storybook이다.
결론부터 말하면, 우리는 프로젝트에서 Storybook을 제대로 사용하지 못했다.
초반에 기본 컴포넌트를 만들면서 테스트하는데 잠깐 사용했을 뿐,
본격적으로 개발이 진행되면서 Storybook은 도외시했던 것이 사실이다.

물론 Storybook 사용이 능숙하지 않았기 때문일 것이다.
하지만 한편으로, 나는 이런 생각이 조금 든다.
“이렇게 어중간하게 사용할 거면 프로젝트에 도입하지 않아도 되지 않았을까?”
애초에 우리가 Storybook을 도입한 이유는 무엇일까?”

돌이켜보면, 우리가 Storybook을 도입한 이유는
단지 Storybook이 실무에서 자주 사용된다는 이야기를 들었기 때문이었다.

Storybook이 어떤 이점을 가지고 있는지, 그리고
우리의 프로젝트에 정말 필요한 도구인지를 고려하지도 않고 말이다.
이것이 반성해야할 지점이라고 생각한다.

최근 인기있는 기술, 실무에서 자주 사용되는 도구…그것은 부차적인 문제다.
정말 중요한 것은, 우리의 현재 프로젝트에 적합한 도구인가를 판단한 후 사용하는 것이다.
이러한 사실을 분명히 깨달았다.
다음 프로젝트에서는 같은 잘못을 반복하지 않도록 하겠다.

2. 협업 방식

우리는 git과 github를 사용하여 협업하였다.
브랜치 구성은 아래와 같다. feature 브랜치에서 기능을 완성한 뒤 develop에 PR를 하였고,
develop 브랜치에서 실행 가능한 상태가 되면 main에 PR을 하고 merge 하였다.
그리고 main 브랜치에서 배포를 하였다.

한편, 우리는 PR 과정에서 코드 리뷰를 하였다.
PR에서 자신의 작업물에 대한 설명을 하고,
동료들이 그 코드를 보면서 리뷰를 해 주는 방식이다.

나는 이 방식의 장단점을 다음과 같이 느꼈다.

장점

1. 리뷰를 통해 코드를 개선하는 데 도움을 받을 수 있다.
   만약 문제점이 있다면, merge 전에 수정할 수 있다.
2. 동료의 작업 상황을 파악함으로써,
   프로젝트를 진행 상황을 전체적으로 파악하기 쉽다.

단점: 리뷰를 받은 뒤 merge를 할 수 있으므로 수정 사항을 즉각적으로 적용하기 어렵다.

비록 단점은 있으나, 장점이 매우 좋았기에 우리는 꾸준히 코드 리뷰를 하였다.
또한, 단점을 보완하기 위해 PR의 등급을 ‘보통’, ‘긴급’으로 나누었다.
긴급한 PR은 빠르게 리뷰한 뒤 merge할 수 있도록 보완하였다.

그 외에도 다음과 같이 라벨을 나누어 작업하였다.

3. 컴포넌트 다이어그램

본격적인 개발에 앞서, 우리는 ‘컴포넌트 다이어그램’이라는 것을 그렸다.
각 페이지의 컴포넌트 구성을 트리 형태로 시각화하고, 데이터의 흐름을 그려보는 작업이었다.
이 덕분에 컴포넌트 구성에 대한 이해가 높아졌고, 실제 개발에 들어가기 전에 전체 흐름을 이해할 수 있었다고 생각한다.

작업 분담 - 나의 역할

마지막으로 페이지별, 기능별로 작업을 분담하였다.
내가 맡은 역할은 다음과 같다.

• 메인 페이지 구현
• 게시물 상세 페이지 구현

무한스크롤로 구현하였으며 게시물에 좋아요 및 취소를 할 수 있다.
이미 좋아요를 누른 게시물이라면, 새로고침을 하여도 좋아요가 유지된다.

포스트의 사진을 클릭하면 ‘게시물 상세 페이지’로 이동한다.
댓글을 작성할 수 있고 취소할 수 있다.
태그를 클릭하면 태그 검색 페이지로 이동한다.

그 외에도 다음과 같은 작업을 맡았다.

• axios로 API 요청 구현

• Context API로 로그인한 유저의 상태 관리

전체 시연 영상

배포 링크 깃허브 레포

에필로그

요구사항 충족 여부

이번 프로젝트에서는 충족시켜야 할 기본 요구사항들이 있었다.
이것은 100% 충족할 수 있었다.
우리 팀원들이 모두 열심히 노력하고 협력한 결과라는 생각이 들어 뿌듯하다.

느낀점

첫 팀 프로젝트를 끝낸 후, 내가 진솔하게 느꼈던 것은 다음과 같다.

1. 한 개의 부싯돌로는 불을 피울 수 없다

솔직히 말해 나는 팀에서 개발을 잘하는 편에 속했었다.
그렇기에 프로젝트 시작 전에는 자만심을 약간 가졌던 것이 사실이다.

그렇지만 팀 프로젝트는 절대로 혼자서 할 수 없다는 것을 다시금 깨달았다.
해야 할 작업은 산더미 같았고, 예상치 못한 이슈들이 도처에서 발생하였다.
그것을 해결하려면 팀원간의 협력이 절실하였다.

작업 진행 확인, 회의, 의견 조율, 역할 분배, 긴급 회의 등등…
하나부터 열까지 팀원들과 긴밀히 협력해야만 하는 일들이었다.

한편, 그렇게 협력을 했기 때문에 19일이라는 짧은 기간 내에
기획, 디자인, 개발을 모두 완성하고 만족할만한 결과물을 낼 수 있었다.
혼자였다면 절대로 해내지 못하였으리라고 생각한다.

“한 개의 부싯돌로는 불을 피울 수 없다”
팀워크의 힘과 중요성을 다시금 깨달을 수 있던 경험이었다.

2. 적당한 거리를 유지하는 것은 중요하다

이번 프로젝트를 하기 전에,
나는 팀원들과 허물없이 지내면서 장난도 치고 많이 친해졌었다.
바로 그것 때문에, 서로 너무 친해지고 가까워졌기 때문에,
프로젝트에서 어려움을 몇 번 겪은 적이 있었다.

일정 관리 등 엄격하고 진지한 이야기를 할 때,
분위기가 다소 흐려진 적이 몇 번 있었던 것이다.
친밀하고 가까운 사람에게 엄격하게 말하는 것은 아무래도 어려운 일이다.

또한, 회의 중 팀원의 악의 없는 농담에 기분이 조금 상한 적도 있었다.
평소라면 아무렇지 않게 넘어갔을지 모르나, 심신이 지쳐있는 상태라 기분이 좀 상했었던 것 같다.
감정적으로 상처를 받으니 집중도 잘 안 되고 일의 효율이 떨어졌던 것이 사실이다.

팀원들과 친해지는 것 자체는 좋은 일이라고 생각한다 .
하지만 친한 사이일수록 서로 존중하고 예의를 지키는 사이가 되어야 한다는 것,
그리고 감정적으로 다소 거리를 유지하는 것이 필요하다는 것을 배웠다.
이번 프로젝트에서 배웠던 중요한 깨달음이다.

3. 경험이 부족한 리더였기에 아쉬웠다

나는 이번이 팀 프로젝트에서 리더를 맡게 되었다.
그렇지만 경험이 부족했기 때문에 여러모로 부족했다는 아쉬움이 남는다.
무엇보다 작업량을 예측하고 일정을 짜는 것이 어려웠으며,
프로젝트 내내 초조함을 많이 느꼈던 것도 사실이다.

때문에 상술한 “코드 리뷰” 절차도 프로젝트 초반에는 생략하곤 하였었다.
기본 컴포넌트를 제작하는 시기였기에, 코드 리뷰가 꼭 필요한 시기였는데도 말이다.

지금 돌이켜 보면, 그렇게 서두르지 않아도 시간은 충분했던 것 같다.
차분한 마음가짐으로 하나씩 문제를 해결해나가면 되었을 것을…
그래서 아쉽고 팀원들에게도 왠지 미안한 마음이다.

그래도 이번에 얻은 경험을 자양분 삼아, 다음 프로젝트에서는 더 나은 리더가 될 수 있을 것 같다.
일정 계획도 잘하고, 차분하게 팀원들을 다독이며 프로젝트를 리드하는 사람이 되고 싶다.