벌써 세 번째 그룹 프로젝트까지 끝이 났다. 앞으로는 3주짜리 프로젝트가 두 번 남았고, 즉 코드스쿼드 과정도 얼마 남지 않았다. 🥺 코쿼 안 끝났으면 좋겠는데.. 🥺🥺🥺

이번 프로젝트는 타미와 백엔드 새리와 함께했다. 셋 다 야구를 전혀 몰라 야구 규칙부터 익히는 시간을 가졌었고, 구현이 느리더라도 확실하게 학습하고 넘어가자고 이야기를 했다.

깨달은 점

1. 내 지식이 안 된 것들이 많았다.

프론트끼리 페어 플젝 1주일씩 두 번과 그룹 프로젝트 두 번을 거쳐오면서 나의 관심사는 협업을 어떻게 잘 할 것인지에 초점이 맞춰져있었다. 깃 플로우, 문서화, 칸반보드, 마일스톤, 시각화 이런 것들 말이다. 기능 구현은 거의 짝프로그래밍으로 진행을 했었는데, 내가 애써 머리를 쓰지 않아도 팀원이 있기에 프로젝트가 잘 마무리되었었다. 나는 팀원이 써내려가는 코드를 보면서 '아 이렇게 하는 거구나~' 하면서 넘겼었다. 새로운 것들을 다 습득했다고 생각했다.

그게 문제였다. 타미와 이번에 기능을 나눠서 구현하려고 해보는데, 리액트의 기초적인 부분에서 막히는 것들이 많았다. setState의 동작 방식, 컴포넌트 안에서 export 불가능, useState는 컴포넌트 안에서만 사용 가능. 그리고 리액트가 아닌 부분에서도, 라이브러리를 설치하면 리액트 서버를 껐다가 다시 켜야 하는 것, yarn.lock 파일을 직접 수정하면 안 된다는 것을 알게 되었다. 예전에 다 끄덕끄덕..하면서 알게 됐던 것들인데, 실제로 부딪혀보니까 확실히 알겠다!

2. API에 대해 초반에 충분히 고민을 해보고 이야기를 나누자.

첫 번째 그룹 플젝 때는 나스, 정이 알아서 API를 잘 만들어주셨었고, 두 번째 그룹 플젝 때는 API가 나와있었어서 그냥 가져다 썼다. 그러다보니 백엔드 분들과 API에 대해 이야기를 많이 나눠보지 않았고, API는 백엔드의 영역이라고 생각했었다.

그래서 이번에도 프로젝트 초반에는 API에 대해 많이 생각해보지 않고 새리가 대충 구조를 잡아온 것에서 약간 수정할 것이나 이야기 나누며 결정해봐야 되는 것들? 그 정도만 참여를 했었다. 그런데 기능을 구현하다보니 클라이언트에서 굳이 로직 처리를 하지 않고 API를 사용할 수 있도록 할 수 있을 것 같다는 생각이 들었는데, 이미 새리가 구조를 잡아둔 상황이라 바꾸기가 쉽지 않았다.

중간중간 수정할 사항이 생기는 것은 당연하긴 한데, 초반에 데이터 통신에 대한 전반적인 흐름에 대해서 너무 생각을 안해보고 새리에게 모든 것을 맡기지 않았나 하는 생각이 든다. API를 수정해야 될 것들이 생기면서부터는 새리와 API에 대해 정말 이야기를 많이 나눴다. 다음에는 더 잘해봐야지!

3. Context API와 useContext

이번 플젝에 Context를 사용해보면서, 저번 플젝에서 크롱이 왜 Modal을 굳이 사용하지 않아도 된다고 말씀하셨는지 깨달았다. 저번 플젝에서 모달이 카드의 props를 받아서 써야 해서 위치는 카드의 자식으로 두고 제일 윗레이어로 올리기 위해 모달을 썼던 건데, context를 사용해서 상태를 관리한다면 굳이 포탈을 쓰지 않고도 구현이 가능할 것 같다는 생각이 들었다. (정답이 아닐 수도 있다. 그냥 나의 생각일 뿐 😙)

아쉬운 점

1. 문서화를 잘 하지 못했다.

저번 플젝해서 해보고 좋다고 생각해서 이번에도 계속 해보려고 했던 매일 회의록 쓰기, 컴포넌트 트리, 활동기록을 끝까지 다 하지 못했다. 활동기록도 2주차 월요일까지만 쓰다가 멈췄고 회의록도 1주차 때는 열심히 쓰다가 멈췄고, 컴포넌트 트리도 그리다가 말았다. 아무래도 기능 구현이 급하다보니 미처 신경을 못썼던 것 같다. 다음번에는 더 의식적으로 시간을 정해두고 하는 식으로 해야할 듯..

2. Git 그래프를 깔끔하게 관리해보고 싶었는데 못했다.

그동안 플젝에서 git 그래프가 너무 알아보기 힘들 정도로 중구난방이어서 이번에는 좀 깔끔하게 관리해보고 싶었다. 몇 가지 시도를 해보다가 기능 구현도 느린데 여기에 너무 시간을 쏟을 수 없어서 포기했다. ㅠㅠ

3. 팀 회고를 하지 않았다.

저번 플젝이 끝난 뒤에 우아한형제들 기술블로그에서 팀 회고 방법에 대한 글을 읽고 너무 좋다고 생각해서 KPT 방식으로 팀 회고를 해보고 싶었는데, 막상 팀 회고 시간을 정해놓지 않아서 그런지 데모 전에는 데모 준비하느라 바쁘고 데모 후에는 얼른 쉬러 가기 바빠서 팀 회고를 하지 않았다.

4. 분업을 하니 조금 느슨해지는 면이 있었다.

아무래도 짝프로그래밍을 할 때보다 긴장감이 덜 하고 쉬고 싶을 때 쉴 수 있으니 느슨해지는 면이 있었다. 팀플 때는 거의 짝프로그래밍만 했어서 내 집중력이 올라갔다고 착각을 했는데, 분업을 해보니 그것은 짝프로그래밍에서 오는 긴장감 때문이라는 것을 알게 됐다. 깨달은 점 #1 때문에 다음 프로젝트에서는 '꼭 혼자' 해보겠다고 설문조사를 했는데, 느슨해지지 않고 스스로 긴장감을 유지할 수 있는 방법을 꼭 찾아서 적용해야겠다는 생각이 들었다.

Keep

• 활동기록, 회의록, 컴포넌트 트리, 이슈 및 마일스톤
• 팀끼리 데일리 스크럼

Problem

• 계획 없이 프로젝트를 진행한 것
• 프론트끼리는 자주 merge를 했지만, 배포는 마지막에 한 번만 한 것
• 팀 회고를 안 한 것
• 프로젝트의 목표가 없었던 것. 목표란 특별하게 시도해볼 것이나 중점적으로 해볼 것들..

Try

• 그 날의 기록은 시간 정해서 그 날 마무리하기. 미루면 안 하게 된다!!! 새로운 팀원들과 말을 해봐야하겠지만, 저녁 6시 정도에 마무리로 함께 모여서 작성하기

• 데일리 스크럼은 그동안 너무 잘했다. 더 잘 하기 위해서는, 지각하지 않기! 시간이 너무 길어지지 않도록 역시나 시간을 정해서 이야기나누기

• 기능을 정리했으면, 3주동안 어떻게 진행할 것인지 주차별로 목표를 세우고, 일주일 안에서도 언제까지 뭘 해보겠다고 팀원에게 말하기. 정해진 날에 목표를 완성할 수 있도록 하기

• 배포 마지막에만 한 번 하지 말고, 최소한 1주일에 한 번은 배포하기. 프론트 개인적으로는 매일매일 동작하는 버전을 푸시하기

• 팀 회고는 금요일에 시간 정해서 꼭 하기!!!

• 프로젝트 시작 전에 데이지, 빰빰이 위키에 정리해뒀던 것처럼 이번 프로젝트에서 도전해볼 것들, 목표를 글로 써보기