#프로젝트 개괄적 소개

기간: 2023년 10월 12일(목) ~ 2023년 12월 3일(일)
주제: 동아리 관리 및 동아리 행사 홍보 서비스 프로젝트
프로젝트 이름: 스페이스클럽
참여인원: 프론트엔드 3명, 백엔드 3명
배포 링크: https://spaceclub.vercel.app/
깃헙 링크: https://github.com/Space-Club

이전글: 2023년 10월 프로젝트 회고

• README 작성해야 함

프로젝트 개발

내가 맡은 역할

• 디자인
• 사이드바
  - 유저 정보 조회하기
• 메인 페이지
  - 카테고리별 행사 조회하기
• 검색창, 검색 페이지
  - 행사 검색하기
  • 검색된 행사 조회하기
• 클럽 페이지
  - 클럽 생성하기
  - 클럽 일정 확인하기
  • 클럽 행사 조회하기
  • 클럽 가입하기
  • 클럽 탈퇴하기
• 제출된 폼 확인 페이지
  - 제출된 폼 조회하기
  • 제출된 폼에 대해 상태 변경하기

개발 시 겪었던 이슈

저번 팀프로젝트 때에는 개인 노션에만 기록해 놓아서 동기부여도 안 되고 전체적인 구조와 사용된 기술에 대해 파악하는 것이 힘들어서 이번에는 다함께 공통 노션에 개발일지를 적는게 어떻냐고 의견을 냈다. 다들 좋다고 동의해주셨고 꽤 많은 개발일지들이 쌓였다!

물론 키워드만 적어 놓고 나중에 보충할 심산으로 메모에 가까운 것들도 많지만 깊이 고민한 부분도 기록되어 있다.

내가 기록한 일지 중 몇 개만 꼽아보자면...

1. Tab 컴포넌트

거의 모든 페이지에 탭이 사용되고 있는데, 내가 이 Tab컴포넌트를 구현하게 되었다. 선택된 탭에 따라 하위 내용이 달라지고, 새로고침을 해도 선택된 탭이 계속 유지가 되었으면 좋겠어서 처음에는 context로 구현하고자 하였다. 이 과정에서 저번 프로젝트에서 다른 팀원이 구현했던 Tab 관련 로직을 많이 참고했었는데, context로 만들고 나서도 너무 비효율적이라는 생각을 했다.
웹 사이트에서는 보통 탭을 클릭하면 url 경로도 변경되므로 웹 서비스를 만드는 우리는 tab을 구현할 때 context를 쓸 것이 아니라 navigation처럼 동작 시켜야 하는 것 아닌가 하는 의문이 들었고, 로직도 복잡해서 다른 팀원들이 추후에 본인 코드들처럼 자유롭게 수정할 수 있을까 하는 걱정도 됐다.

따라서 전면적인 코드 삭제와 약간의 수정이 필요했고 Tab컴포넌트는 1/3 정도로 경량화되었다. 이 과정은 꽤나 오랜 시간이 들었는데, 왜냐하면 여러 서비스들을 참고하면서 탭 컴포넌트가 어떤 식으로 사용되고 있는지 알아보고 우리 서비스에서 탭이 어떤 역할을 하는지에 대해 고민했기 때문이다. 지금 돌아보니 별 거 아니긴 한데... 이미 공들여 몇백줄 작성한 코드를 리팩토링하는 게 품이 많이 드는 일이구나 깨달았다.

2. 제출된 폼 페이지

처음으로 개발하면서 어떻게 컴포넌트를 쪼개줘야 할지 고민했다. 우선 표 형태라고 생각했으므로 table을 사용하여 컴포넌트를 만드려고 했는데, 스타일을 먹이기도 제한적이었고 '요청, 상태, 취소처리'는 managed값에 따라 필요여부가 결정되므로 분기처리를 하기 곤란했다. 또한 하나의 폼에 대한 상태 관리가 어려웠다. 그래서 div로 바꾸어 스타일을 적용하게 되었음.
여기서 문제점은 div로 컴포넌트를 만들다보니 카테고리의 너비와 제출된 폼의 내용 너비가 통일되지 않았다는 것인데, 이 문제는 스타일 상속을 이용해 해결했다!
또한 response 데이터를 어떻게 하면 효과적으로 보여줄 수 있을지 고민했는데, 이 과정에서 '요청, 상태, 취소처리' 부분을 하나의 컴포넌트로 분리하여 상태변경을 해당 컴포넌트에서 처리하도록 만들었다.

이 과정에서 컴포넌트를 만드는 데에는 정답이 없음을 깨달았고, 추후에 리팩토링을 위해 어떤 식으로 컴포넌트를 구성할지 고민하는 방법을 깨달았다. 현재는 하나의 컴포넌트에 하위 컴포넌트들이 너무 많은 구조여서 좀 더 효율적으로 바꿀 수는 없을까 고민하고 있다.

3. 클럽 일정 data

구현해야 할 내용은 다음과 같다.

1. 클럽 캘린더
   : 클럽에서 생성한 행사들을 달력에 표시해주어야 함.
   : 특정 날짜를 클릭하면 해당 날짜에 속한 행사를 띄워주어야 함.

2. 일정 상세보기
   : 달력에서 클릭한 날짜에 속한 행사들의 제목을 나타낸다.
   : 클릭 시 해당 행사의 상세보기로 이동

데이터 가공
두 개의 컴포넌트로 만들어야겠다고 생각한 후 데이터가 어떻게 오는지 보았는데 … 문제가 있다고 생각했다.

스케줄: [
	{
		행사1제목,
		시작날짜,
		끝날짜,
		행사 생성자,
		행사 id, 
   },
	{
		행사2제목,
		...
	},
...

]

클럽에서 생성한 모든 행사의 내용이 위와 같이 주어진다.

캘린더, 일정 상세보기 캘린더에서는 날짜를 기준으로 행사를 보여주기 때문에 두 컴포넌트에서 모두 일정을 표시하려면 별도의 데이터 처리 과정이 필요했다.

캘린더 컴포넌트는 모든 행사들의 날짜 정보만 필요할 것 같아서 스케쥴의 모든 객체들을 돌면서 날짜 정보만 수집했다. 여러일에 걸친 행사도 있었으므로 행사 range를 구하는 함수도 필요했음.

일정 상세보기 컴포넌트에서는 각 날짜에 해당하는 모든 행사 정보가 필요했다. 선택된 날짜와 모든 행사들의 날짜를 비교하며 날짜가 일치하는 행사들만 배열에 저장함.

위 과정은 크게 어렵지 않았으나, 데이터의 구조와 사용자의 동작의 간극이 너무 크게 느껴져서 비효율적이라고 생각했다. 지금은 데이터가 많이 없으니까 괜찮은데, 데이터가 많아질 경우 클럽 홈페이지에 들어올 때에 로딩 시간이 더 걸릴 것이다. 또한 많은 데이터들의 날짜정보만 취합하여 캘린터에 표시하는 과정, 날짜에 해당하는 행사들의 정보를 선별하는 과정에 드는 시간도 늘어나서 사용자 경험에 악영향을 끼칠 것 같다.

그런데 캘린더가 있는 한, 클럽의 모든 행사 정보를 불러와야 하는 건 똑같지 않나? 흠….

context
한편…, 두 개로 구분된 컴포넌트는 공유해야 할 하나의 값이 있었다. 바로바로 ‘선택한 날짜’

캘린더에서 특정 날짜를 클릭하면, 일정 상세보기에서 해당 날짜의 행사들을 보여줘야 함. 팀장님이 어떻게 구현하실 생각이냐시길래, 사실 생각 안 해봐서 모르겠다고 했더니 context 쓸 것을 추천해 주셨다.

context…올 것이 왔구나.
캘린더와 일정 상세보기는 또 하나의 컴포넌트로 묶여 있어서 선택된 날짜를 전달하기 위해서는 상위 컴포넌트를 한 번 거쳐야 했다. 그건 그렇다 치고

내 우려와 달리, 유튜브 영상 하나를 보니까 context에 대해 대강 감이 왔다.
provider는 공유할 데이터를 자유롭게 쓸 수 있는 area를 지정해주는 느낌..
createContext는 공유할 데이터를 선언하는 느낌..
useContext는 공유할 데이터를 사용할 때 쓰는 듯…

걍 10분짜리 영상 하나 보고 해봤는데, context에 쓰일 데이터가 간단해서 그런지 금방 했다. 문제는 타입이었음 (오열)

다른 팀원들이 짜 놓은 context보고 따라하니까 이해하기 쉬웠으나 context에 대해 근원적으로 이해하진 못했으므로 추후에 보강하는 걸로~

이 과정에서 백엔드에서 보내주는 데이터 구조에 대해서도 충분히 얘기해봐야겠다고 생각했다. 실제로 구현이 끝난 뒤에 해당 기능을 담당한 백엔드 팀원과 데이터 구조에 대해 의견을 나눴다. 피그마를 통해 사용자 행동에 대해 같은 이해를 하고 있는데, 내가 생각한 데이터 구조와 백엔드 팀원이 만든 구조가 왜 상이한지, 백엔드에서는 데이터 구조를 어떤 기준으로 만드는지 이야기를 듣게 되었다.

#1인분?

데브코스에서 두 번째 프로젝트를 시작할 때에 이번 목표는 '0,8인분 하기'라고 팀원들에게 선언한 적이 있다. 결론부터 말하자면 이번 프로젝트에서 나는 1인분은 했다고 말하고 싶다.

TMI 호머스를 만들 때에는 잘하는 팀원이 개발환경 세팅과 api 훅, 데이터 타입까지 만들어 두어서 수동적으로 사용하기만 했는데 스페이스 클럽을 개발하면서는 내가 담당한 기능에 대해 둘부터 열까지 만들어야 했다. 처음에는 버겁다고 생각했지만, 한 번도 클릭해보지 않았던 폴더에 파일을 생성하고 팀원들과 함께 정해둔 코딩 컨벤션에 맞추어 작업하는 과정들이 재미있게 느껴져서 잠들기가 아쉬운 날이 많았다. TMI 호머스는 퍼즐을 맞추는 느낌이었다면, 스페이스 클럽을 만들 때에는 하얀 도화지에 스케치를 하는 기분이었다.

코딩도 잘하고 속도도 빠른 팀원들 템포에 맞추기 위해, 맡은 기능을 무사히 구현하기 위해 쉬는 날 없이 달리느라 un peu 힘들기도 했지만, 그것마저도 '코딩에 취한 나' 컨셉에 취해 있어서 즐겼다. 마지막 QA를 하는 날에 백엔드 팀원이

채연님, 그래도 1인분은 하셨네요?

라고 말씀해주셔서 '그래도 나... 다했구나' 생각했다. (칭찬인지 뭔지는 잘 모르겠지만)

#팀프로젝트에서 소통이란...

개발 실력이 뒤지는 편이라 소통이라도 적극적으로 잘 해야겠다고 생각했다. 최대한 내 의사를 명확하게 표현하고자 했는데, 프로젝트가 끝난 뒤 뒤풀이를 하는데 백엔드 팀원이 내 말을 약간 오해한 적이 있다고 해서 놀랐다. 내 의도는 약간의 진심과 농담 섞인 유쾌한 답변을 하고자 함이었으나, 그 팀원은 내 말이 너무 직설적이라고 생각했었다. 효율적인 회의를 이성적이고 논리적인 의사소통도 중요하지만 상대방의 기분도 중요하구나 깨달았다.

#겁쟁이

• 난 겁쟁이. form이 무서웠다. 그래서 역할 분배할 때 '폼은 제발 걸리지 말게 해주세요' 기도함...이 업보는 언젠간 돌아오겠지.

• 무서워서 또 못 한 것: 토큰. 유저 토큰... 그게 뭔데 어떻게 하는 건데,

• 다른 팀원들이 쉽다고 한 건 가져감. 근데 나한텐 어려웠음.

• 플젝 중후반부터는 너무 일정이 빡세서 '멈춰있는 글'을 읽고 싶다고 생각했음. 내실을 다지고 싶다... 한 두달 정도는 개발 '공부'에만 미쳐보고 싶다고 생각함. 이런것도 회피일까?

#마치며...

• 제대로 된, 완전한 팀 프로젝트를 한 것 같음. 계속 리팩토링 해나가고 싶음

• 팀원들과 협업 경험도 너무 좋았다. 프엔과 협업 경험이 있는 백엔드 분이 계셔서 소통하는 데 문제 없었고, 궁금한 점이 생기면 이해하기 쉽게 설명도 잘 해주심. 데이터 구조에 대해서도 서로 의견을 자주 나누고 수정사항도 바로 반영. 프론트는 두말 할 것 없이 잘 함. 그래서 오히려 회고할 때 할 말 없어서 조금 아쉬웠음. 좀 갈등도 있고 힘든 점도 있어야 배울 점도 생겼을 텐데..

• 다른 사람들의 개발 태도, 고민하는 자세를 배워감. 어떻게 공부해야 할지 감이 생김.

• 솔직히 우리팀이 우수상 받을 줄 알았다.