개발 공부를 시작하고 처음으로 해본 2주간의 팀 프로젝트! 나는 개발 실력은 현재 매우 부족하나 팀장 포지션이었고, 우리 팀 구성은 나 포함 다섯명. 두 분은 현업 경험이 조금 있는 분들이고 나 포함 나머지 셋은 처음 공부하고 팀 프로젝트 경험이 처음인 경우였다. 기술적 측면의 프로젝트 리드 및 백업을 경험자 두 분이 많이 맡아주셨고, 나머지 인원은 기능 구현 및 각자 맡은 역할에 충실했다. 프론트엔드 과정이라 백엔드, 디자이너는 없이 프론트 5인으로만 구성되어 진행되었다.
🧐 어떤 프로젝트를 만들었나?
OPEN MIND라는 서비스 로, 익명 기반으로 질문과 답변을 할 수 있는 소통 플랫폼이다.
- 일정: 2023. 11. 03.(금) ~ 2023. 11. 17(금) (2주)
- 서비스 기획안 및 디자인 시안은 Figma로 제공
- Swagger 기반 API 제공
- 주요 기능
- 유저 이름을 입력하고 '질문 받기'를 누르면 질문 목록 페이지로 이동
- 질문 목록 페이지에서 질문을 할 수 있는 대상인 익명의 유저 카드 리스트가 보임
- 유저 카드 리스트는 PC 기준 8개, Tablet/Mobile 기준 6개로 노출
- 유저 카드 리스트는 최신순 / 이름순으로 드롭다운 선택하여 정렬 가능
- 유저 카드 클릭 시, 해당 유저의 개별 피드로 접근
- 개별 피드는 질문이 없는 빈 상태 / 카드 리스트 노출 상태로 존재
- 개별 피드 페이지를 링크 클립보드 복사 / 카카오 공유하기 / 페이스북 공유하기 기능으로 공유할 수 있음
- 질문 작성하기를 클릭하면 모달 창이 떠서 해당 유저에게 질문을 남길 수 있음
- 각 카드에 좋아요 / 싫어요 표시 기능
- 답변하러 가기를 클릭하면 로컬 스토리지 기반으로 유저 페이지로 넘어감
- 질문에 대한 답변처리 - 답변 작성 / 답변 수정 / 답변 거절 / 답변 삭제 / 질문 삭제 기능이 있음 (버튼과 케밥으로 존재)
- 전체 삭제하기 버튼으로 계정 자체를 삭제 가능
- 주요 구현 범위
- 공통 시스템 및 컴포넌트
- 반응형
- 메인 페이지
- 질문 목록 페이지
- 개별 피드
- 개별 피드에 대한 질문하기 모달창
- 답변하기
- 사용 기술
- React
- React-Router
- Styled-Components
- Eslint / Prettier
- AWS S3
💟 진행 과정
1. 기획안 분석 & 팀 규칙, 협업 방식 선정
각자 기획안을 분석해서 어떤 기능 구현이 필요한지, 유저 플로우가 어떻게 되는지 생각해보고 논의하는 시간을 가졌고 이를 기반으로 기능 명세서를 작성하기로 했다. 사용 기술에 대한 부분도 논의하여 정리했다.
팀 규칙은 기본적인 협업 방식(커뮤니케이션 방식, 협업 툴 선정)을 정했고, 우리는 디스코드로 소통(스레드 단위)하고 노션에 기록을 남기기로 했다.
또한 중요한 점이 코드 컨벤션, 깃 프로세스 설정(브랜치 전략, PR & 머지 방식, 커밋 메세지 컨벤션)이었는데 실제로 협업을 할 때 정말 중요한 사항이라고 생각되었다.
2. 기능 명세서 작성
기능 명세서는 실제 업무에서만큼의 디테일하게는 아니어도, 최대한 세부 단위로 기능을 쪼개어 리스트업하는 시간을 가졌다. 각 페이지별로 카테고리를 나누고 페이지별 구현해야 하는 기능을 함께 적고 보완하는 시간을 가졌다. 이는 기능 구현 업무의 우선순위 파악과 담당 영역을 나누는 데에 꼭 필요한 단계라고 생각되었다.
3. 우선순위 파악 및 R&R 정리
각 기능의 구현 우선순위를 심플하게 페이지 내에서 1순위와 2순위로 나누었고, R&R을 나누면서 1순위를 우선적으로 작업하기로 했다. 기능 명세서를 처음 작성해보다 보니 어려움이 있었는데, 어느 정도까지 디테일하게 쪼개야 할지, 그리고 우선순위를 가늠하기 어려운 태스크도 있었고 2개 이상의 페이지에서의 공통 적용 기능의 경우 어떻게 해야할지 등등, 이러한 부분은 데일리 논의를 통해 정리할 수 있었다. 덕분에 수월하게 R&R 정리가 되었던 것 같다.
4. 프로젝트 초기 세팅
멘토링에서 조언을 받기로, 팀원 중에 좀 더 실력이 좋은 분이 프로젝트 초기 세팅을 맡으면 좋을 것 같다. 모든 작업의 기반이 되는 틀을 만드는 작업이기 때문에. 그래서 팀에서 에이스인 분이 초기 세팅을 맡아 주셨고, 초기 세팅에 필요한 부분은 다음과 같았다.
- CRA 세팅
- 디렉토리 및 파일 구성
- 라우팅 세팅
- 공통 폰트/컬러/스타일 세팅
- API fetch 모듈 구현
- 코드 컨벤션 및 Git 협업 규칙 정의
5. 각 기능 구현
담당한 R&R, 그리고 우선순위에 따라 기능을 구현했다. 내가 담당했던 부분은 아래와 같고 어려움을 겪었던 부분들이 있어서 코멘트와 함께 정리해본다.
- (초기 세팅) 깃허브 및 팀 채널 세팅
- 텍스트 시스템 세팅
자주 쓰이는 텍스트 스타일을 시스템으로 만들어 효율화를 추구하려고 했는데, 처음에는 정의를 비효율적으로 했고(공통화를 제대로 실천하지 못함) 가져다 쓰는 과정에서 더 복잡도가 높아졌었다. 멘토링을 통해 피드백을 받아 최대한 공통화를 구현했고, 가져다 쓰는 과정도 편리하게 적용하도록 보완하여(객체로 정의, 반응형으로 사용할 수 있도록 타입 적용) 개선했다. 초반에 세팅하여 모든 팀원의 작업 영역에 영향을 미치는 부분이다보니 많이 애를 먹었고ㅠ 중간에 뒤엎느라 또 고생을 하긴 했다. - 포스트(질문) 페이지 - 질문이 없는 디폴트 상태 구현
- 답변 / 질문 작성 폼 컴포넌트
- 답변 페이지
답변 페이지가 포스트 페이지와 공통적으로 적용되는 컴포넌트 영역이 많아서 처음에 페이지를 따로 만들어야 할지, 아니면 포스트 페이지 내에서 조건부 렌더링으로 구현해야 할지 고민이 되었었다. 공통화를 최대한 신경써서 해보려고 생각했고, 조건부 렌더링으로 다르게 표시되는 영역만 구현했다. - 답변 카드 컴포넌트
- 답변 카드 API 데이터 연동
api 연동하는 작업 자체를 많이 안해봐서 처음에 너무 어렵게 느껴졌다. useAsync를 활용하는 것도 아직 와닿지 않은 상황에서 구현하려니 어려웠고, 답변 내용을 받아오는 것과 답변 내용을 수정했을 때 PUT을 적용해보는 것도 처음이다보니 막연한 두려움이 있었다. 다른 분들이 구현한 코드 기반으로 참고해서 적용했고, utils 내에 apiClient.js, endPoint.js, createAnswer.js, editAnswer.js 이렇게 잘게 쪼개어서 깔끔하게 구현 및 정리할 수 있었던 것 같다. - 답변 수정하기 기능 구현
수정하기 버튼을 클릭하면 해당 답변 카드의 기존 입력된 답변 내용을 작성 폼에 넣어 편집을 활성화해야 하고, 답변 수정 완료 버튼 클릭 시 수정한 내용으로 데이터를 업데이트하고 이를 표시해주어야 하는 점이 어려웠다. 답변 작성 폼이 노출되어야 하는 조건과 수정하기 버튼이 노출되고, 활성화 되었을 때 조건에 따라 알맞는 상태를 적용하는 점이 어렵게 느껴졌으나... 많이 헤맨 덕에 조건부 구현하는 부분은 좀 익숙해진 것 같다. - 토스트 컴포넌트 구현
이 부분이 또 자잘하게 힘들었던 부분인데, 답변을 입력 완료하거나 수정해서 등록이 문제 없이 된 경우 등 상태를 유저에게 인폼해주는 토스트를 만들었는데 자꾸 입력 내용 등록이 성공했다는 메세지의 토스트가 중복 노출되는거다. 일정 시간 동안 페이드인 페이드아웃으로 정상 노출되었다가 막판에 갑자기 같은 토스트가 깜빡!하고 또 나타남.
에러를 고치려고 아무리 시도해도 개선이 안되는거다. gpt가 알려준 useEffect에서 토스트 스테이트에 setTimeout 조정으로 해결하려고 해도 계속 개선이 안되어서 진짜 멘붕이 왔는데, 아무래도 해결하고자 하는 컴포넌트 안에서는 안될 것 같아 해당 영역 외에 별도의 토스트 컴포넌트 파일 포함해서 검토한 결과, 토스트 컴포넌트 자체에 페이드인, 페이드아웃 애니메이션이 적용되어 있다보니 해당 스테이트에 대한 정보도 prop으로 내려주어 같이 케어했어야 했던 거다. 해당 토스트가 뜨는 영역의 상태 + 토스트에 적용된 상태 를 같이 컨트롤하니 해결이 되었다. - 링크 쉐어 기능 구현
6. QA & 리팩토링
조금 여유있을 줄 알았던 프로젝트는 생각보다 시간이 걸렸고, 막바지 2일 정도는 QA와 리팩토링을 하는데에 시간을 할애했다. 사실 리팩토링은 갈고 닦아 디벨롭하는 쪽 보단, QA로 발견된 예상치 못한 오류들을 해결하는데에 집중되긴 했다. 그래도 무사히 모든 구현 요구사항은 완수했고 기간 내에 마무리해 배포까지 할 수 있었다.
7. 배포
배포는 AWS S3를 활용해 시도해보고 싶어서 팀의 목표로 설정해두었고, 잘하시는 팀원 두 분이 같이 마무리 해주셨는데 이번에는 사실 여유가 없어서 배포에 대한 디테일한 부분은 팔로업하지 못했다. 다음에 프로젝트를 한다면 배포도 직접 구체적으로 관여하거나 맡아서 진행해보려 한다. AWS S3는 일단 과금 이슈가 있어서 전체 공유할 때까지만 열어두었었고, 간단 버전인 netflify 서비스로 추가 배포를 해두었다.
8. 발표
우리 팀은 발표에는 조금 힘을 빼고, 프로젝트 구현 자체에 좀 더 집중하자라고 초반에 방향성을 잡긴했으나... 다른 팀의 발표를 보고 많은 생각과 반성을 하게 되었다. 물론 선택과 집중을 했지만, 다른 팀들의 고민, 과정의 세부 내용을 공유 받으니 괜시리 우리도 좀 더 디테일하게 쉐어하면 좋지 않았을까 하는 아쉬움? 다른 팀의 고민의 깊이에 대한 놀라움? 그러한 깊이 있는 고민을 할 수 있는 기반 실력에 대한 부러움? 등등... 여러가지 생각이 들어 발표가 끝나고 좀 벙찌긴 했는데. 오히려 더 자극이 되었던 것 같았고 개발 프로젝트 발표는 이런 식으로 하는거구나 라는 배움도 얻었다. 나와 시작점이 다른 사람과의 비교는 조금 내려두기로 했고... 여튼 대단하고 멋진 분들이 많구나, 더 열심히 해서 다음 프로젝트는 좀 더 깊이 있게 경험을 쌓을 수 있게 스스로를 발전시켜야 겠단 생각을 했다.
🩵 Wrap-up
아쉬운 점?
첫 프로젝트이기도 하고 아직 내 실력이 많이 부족하다보니 일차원적으로 요구 기능에 대한 구현을 목적으로 임했던 것 같다. 물론 내 수준에서 그 이상을 하는 건 무리였을 수 있겠지만... 너무 기능 구현에 끌려다닌 느낌이 없지 않아 있어서ㅠ 다음 프로젝트에서는 구현에 끌려다니는 것에서 나아가 서비스 설계를 생각하며 접근해보고 싶다. 또한, 기능 구현하는 방식을 '왜' 그 방식으로 선택했는지에 대한 부분도 고민해가며 프로젝트에 임하고 싶다는 생각이 들었다. 그렇게 되기 위해선 일단 내 실력을 잘 쌓아두어야 겠지.
좋았던 점?
나의 첫 개발 협업 프로젝트(그것도 내가 어려워한 리액트 기반)를 기간 안에 큰 무리 없이 잘 완수하고 요구사항을 모두 잘 구현해 배포까지 했다는 점! 개발 협업에 대한 이해와 경험치를 상승시켰다는 점이 정말 좋았다! 2주간... 고생 많았다! 첫 프로젝트라 우당탕탕이었지만...(팀원들에게 미안한 마음ㅋㅋ) 그래도 잘 완수했음에 의의를 두고 다음 프로젝트도 화이팅 💟
'Today I Learned' 카테고리의 다른 글
| TypeScript의 동작 원리 (1) | 2023.11.26 |
|---|---|
| TypeScript를 사용하는 이유 (0) | 2023.11.26 |
| Presentationl & Container 디자인 패턴 (0) | 2023.11.04 |
| 웹 페이지 렌더링 방식 - CSR / SSR / SSG (0) | 2023.10.30 |
| Ajax란? (2) | 2023.10.14 |
