[섞어마셔] 프로젝트 7일차 - 마지막날, 팀원과의 마찰, 전체회고

드디어 고난의 일주일이 끝나는 날입니다.

 

마지막 날이기 때문에 새로운 기능을 추가하지 않고 디자인만 살짝 변경을 해야 합니다.

1. SearchPage 버그 고치기

---

어제와 동일하게 로컬에서는 search가 제대로 작동하는데 배포환경에서는 작동을 안 하고 있었습니다.

vercel, netlify 둘 다 배포를 해보고 배포 세팅을 건드려봐도 해결이 안돼서 search와 관련된 코드를 하나씩 보기 시작했습니다.

 

천천히 다른 팀원과 읽어보니 문제가 되는 코드를 발견했습니다.

// api.js baseURL을 설정해놓은 파일

export const searchApi = axios.create({
	baseURL: "/api/json/v1/1",
	headers: {
		"Content-Type": "application/json",
	},
});

 

defaultURL을 설정을 해놔서 이런 식으로 짜놓은 줄 알았는데 defaultURL가 없어서 이상했습니다.

원래라면 baseURL이 https로 시작해야 되는데 /api로 시작하고 있었습니다.

 

변경된 코드 

export const searchApi = axios.create({
	baseURL: "https://www.thecocktaildb.com/api/json/v1/1",
	headers: {
		"Content-Type": "application/json",
	},
});

 

api를 가져오는 https://www.thecocktaildb.com를 추가하니깐. 배포를 해도 제대로 작동했습니다.

https관련된 코드가 없어도 로컬에서는 작동을 하고 배포를 하면 작동을 안 한다는 것을 배웠습니다.

 

2. 로그인 성공 시에만 유저페이지 진입

---

로그인 관련된 건 제 파트가 아니었지만 시간이 약간 남아서 아주 간단하게만 zustand에 로그인유무를 저장하고 로그인이 되어있다면 유저페이지로 진입이 가능하고 로그인이 안된 상태에서 유저페이지로 진입을 하려고 한다면 로그인페이지로 가도록 하였습니다.

 

이 코드는 상태관리 라이브러리인 Zustand

// Zustand
// loginStore.js 

import { create } from "zustand";

const useLogin = create((set) => ({
	isLogin: false,
	setIsLogin: () => set((state) => ({ isLogin: true })),
	setIsLogout: () => set((state) => ({ isLogin: false })),
}));

export default useLogin;

 

userPage에 로그인이 안되어 있다면 /login로 가도록 하였습니다.

// userPage

const { isLogin } = loginStore((state) => state);

useEffect(() => {
  if (!isLogin) {
    navigate("/login");
  }
}, [isLogin, navigate]);

 

3. 팀원과의 마찰...

---

발표 2시간 전 에러도 다 고치고 디자인도 마무리되어서 발표하시는 분이 발표만 잘하면 되는 상황이었습니다.

그때 팀원 한분께서 새로운 기능을 머지해 달라고 요청하셨습니다.

 

제 판단에는 디자인 관련 코드도 아니고 새로운 기능 + 다른 팀원의 페이지와 관련된 코드여서 어떠한 에러가 발생할 줄 모르고 또한 발표하시는 분이 그 파트를 다시 연습을 해야 된다고 하여서 머지를 해줄 수 없다고 말씀드렸습니다.

 

답장으로 그분의 입장에서는 제 파트인 Header의 유저페이지 라우팅이 늦게 자신의 개발이 늦어졌고 어차피 dev로 머지를 하는 거고 거기서 이상 없다면 바로 main브랜치에 적용해서 발표를 하는 건데 상관이 없다고 하셨습니다.

저는 고민을 했지만 그냥 그대로 머지를 안 하고 발표를 했습니다.

 

이런 상황이 일어나기 전에 미리 막았어야 했는데 아쉽네요.

발표하기 전 최소한 6시간 전에는 어떠한 새로운 기능을 추가할 수 없다고 공지하였어야 하고 회의에 참가하시지 않는 그 팀원을 위해서 카톡을 남기기보다는 개인톡으로 완료되었다고 말씀드렸어야 했었어야 합니다.

 

4. 일주일 간의 회고

---

짧은 시간이었지만 내가 직접 프로젝트를 운영해 볼 수 있는 경험을 할 수 있어서 좋았습니다.

하루에 평균 10시간 이상을 프로젝트에 쏟아부었지만 아쉬움이 많습니다.

회고록을 작성해 보면서 그 아쉬움에 대해서 작성해보려 합니다.

 

1) 팀원의 수준 파악

열심히 프로젝트 세팅을 하였지만 세팅에 대해서 회의 때 이런 식으로 세팅을 했으니깐. 써라!라는 식으로 말만 하고 넘겼습니다.

프로젝트 막바지가 되니깐. prettier를 아예 모르시는 분도 계시고 MUI를 적용하느냐 제대로 코드를 작성 못 하시는 분도 계셨습니다.

팀원들의 github을 보니 코딩을 시작한 지 한 달밖에 안되신 분들이 많았습니다. prettier를 모르는 게 당연하고 MUI를 배우는데 오래 걸리는 게 당연합니다. 

처음부터 팀원의 수준을 파악했더라면 stack을 최대한 보수적으로 잡고 prettier도 상세히 설명하고 github사용법도 그냥 제가 다 했어야 했었을 텐데 아쉬움이 남습니다.

다음부터는 팀원의 수준을 파악하고 팀원에 맞는 환경과 회의진행을 하겠습니다.

 

2) 팀장은 거절의 연속

현장에서도 동일하지만 팀 프로젝트에서도 팀장은 거절을 잘해야 됩니다.

저는 거절을 두려워했었습니다.

처음에는 거절을 잘했지만 계속 거절하다 보니 거절하는 게 팀원에게 상처가 될까 봐. 거절이 두려워졌었습니다.

 

모두 동일하게 배운 bootstrap, redux toolkit을 사용하지 않고 다른 팀원이 적극적으로 추천한 Zustand, MUI, tailwindcss를 새로운 stack을 넣게 되었습니다.

일주일이라는 짧은 시간 동안 팀원들은 이 스택에 적응하느냐고 제대로 개발을 하지 못하였고 몇몇 팀원은 규칙에서 벗어나 자신에게 편한 stack을 그냥 install 해서 사용하였습니다.

다음부터는 팀원이 아무리 추천을 해도 팀전체의 상황을 파악을 해서 거절을 하겠습니다.

 

디자인은 제가 잘 모르다 보니깐. 아무 생각 없이 적용을 했었습니다.

디자인은 담당하시는 두 팀원께서 Header의 logo에 대해서 상이한 의견이어서 의견을 줄 때마다 그때그때마다 PR올리고 머지하고를 반복해서 많은 시간이 소요되었습니다.

다음에는 동일한 파트에서 계속 요청이 온다면 요청을 멈추게 하고 두 분의 의견이 합치될 때 의견을 달라고 하겠습니다.

 

3) 카톡을 통한 보고

팀원끼리 의사소통이 너무 활발하다 보니깐. 중요한 이야기를 해도 팀원들이 제대로 파악하지 못하는 경우가 많았습니다.

다음부터는 팀원이 반드시 알아야 하는 중요한 보고는 노션에 적어놓기 or 공지 추가하기를 하겠습니다.

 

React App

 

GitHub - codingNoona-10/shake_drink