1. 최종 프로젝트 기획

TMI HOMERS 프로젝트를 무사히 끝내고 팀원들과 뒷풀이도 못 한 채 새로운 프로젝트를 시작하게 되었다. 방학과 공휴일이 포함되어 있어서 그 사이에 '사 놓은 리액트 강의도 듣고 전에 썼던 라이브러리 좀 공부해야지~'했는데, 안 했다. 그래도 정신적 회복에 많이 집중했음 :)

1-1. 팀 문화, 팀 규칙

데브코스에서 두 번째 팀 프로젝트라 그런지, 새로 만난 팀원들 모두 전 팀에서 아쉽게 생각했던 부분을 적극적으로 보완하고 싶어 했다. 공통적으로 중요하게 생각했던 부분은 역할 분배와 일정 관리, 그리고 소통이었다.

나름 팀의 분위기를 화기애애하게 만들고자 전 팀들의 규칙을 참고하여 만들어 봤는데, 확실히 도움이 되었던 것 같다. 참고로 내가 가장 좋아하는 규칙은 굳이라는 말 쓰지 않기다. 왜냐하면 굳이라는 말을 쓰고 싶어서 미쳐하는 사람들의 모습을 보는 게 즐겁기 때문이다.
최근에 내가 팀원들한테 서운한 일이 생겼었는데(궁금하면 DM 부탁드릴게요🙏), 규칙4번 덕분에 감정 커지기 전에 미리 말해서 가볍게 풀고 지나갈 수 있었다! 역시 문제는 바로바로 터트려야 끝이 깔끔하다.

스크럼 규칙도 구체적으로 세워놨었지만, 이전과 다르게 다들 일정관리 툴에 능숙해져서 스크럼에 시간을 많이 투자하기 보다는 협업툴을 보며 빠르게 상황을 공유하고 다른 사람들이 어떤 일을 하고 있는지 잘 파악하는 것 같다. 우리는 JIRA를 쓰고 있는데, 개인적으로는 깃헙 프로젝트가 더 익숙하고 편리해서 좋지만 이번 기회에 새로운 걸 써보는 것도 좋다고 생각하고 있다. 사실 지라나 깃헙 프로젝트 둘 다 기능을 전부 활용하고 있지는 못하고 있는 것 같다는 생각이 든다. 🥔

1-2. 협업방식 정하기

(1) 기술스택 정하기

전 팀과 거의 비슷한 스택으로 진행하게 되었다.

이번 프로젝트에서는 Next.js를 쓰는 팀들이 많아져서 우리도 써야할까 고민했었다. 팀원 모두가 Next.js를 써본 적이 없었기 때문에 공부를 해야 했고, 이런 상황에서 최종 프로젝트에 Next.js를 도입하는 것은 프로젝트 퀄리티와 학습적인 측면 모두에 불만족스러울 것이라는 결론을 내려서 React를 사용하기로 했다.

나에게 새로운 스택도 있긴 했는데, 전역 상태관리 라이브러리인 recoil과 emotion css였다. 결론적으로 둘 다 안 쓰게 되었음. context로 관리하다가 recoil이 정말정~말 필요할 때 쓰자고 결정되었고---난 그래서 정말정~말 필요할 때가 어떤 때인지 모른다;---emotion css는 emotion/styled와 함께 쓰기로 했다. emotion/styled(공식 표기 이게 맞나?)는 데브코스에서 제공한 강의에서 사용했기 때문에 익숙하긴 했지만, 실제로 내가 직접 사용해본 적은 없었기 때문에 두려움이 앞섰다. 그래서 전 팀에서 너무 잘 썼던 tailwind css를 쓰자고 적극 주장했지만, 난 tailwind css만 써본 사람이어서 두 개를 두고 논리적인 비교를 할 수 없었기 때문에 설득에는 실패했다. 그리고 tailwind css를 경험해본 사람은 나뿐이었기 때문에, 내가 주도적으로 알려주고 이끌어야 한다는 부담감도 있었다. 비겁하군...과거의 나.

이전 프로젝트 회고에서 기술 스택을 사용해보고 후기를 써서 올렸었는데, 이번 프로젝트를 끝내고 어떤 식으로 성장했는지 비교해서 써보면 좋을 것 같다. (나머지는 11월 회고에 쓴다는 말)

(2) 깃헙 전략

코딩 컨벤션, 코드 네이밍, 폴더 구조 등 협업에 필수적인 요소들은 다들 빠르게 정했다. 전 프로젝트 회고에 쓴 내용과 비슷하게 진행했기 때문에 생략!

1-3. 팀의 목표, 개인 목표 공유하기

백엔드 팀 매칭 이전, 프론트끼리 협업을 위한 규칙 같은 게 정해지고 나서 우리는 팀 목표와 개인 목표를 구체화해보기로 했다. 그런데 그때 당시에 썼던 거 보니까 내가 너무 유치하게 쓴 것 같음...

저번 프로젝트에서는 잘하는 팀원이 개발하기 편하게 이지모드로 세팅해준 걸 즐기면서 코딩했었다. 그러나 이번에는 개발하면서 분명하고 진지한(^^) 목표가 생겼다! 바로바로
'1인분 하는 팀원 되기'
10월 초만 해도 '나는 0.8인분만 해도 잘하는 거다' 생각했었는데, 프론트엔드도 3명으로 줄고 한 사람의 비중이 커지다 보니 내가 스근하게 하면 안 되는 상황이었다. 오프라인에서 api 테스트를 하는데 나만 아무것도 몰라서 멍때리고 있을 때, 1차 팀원분 중 한 분의 '00보다 잘하는 88도 열심히 공부하는데, 00은 그것보다 더 열심히 해야죠'라는 명언이 생각났고...당장에 실력으로 부족하여 시간으로라도 비비다 보니 열심히 하게 되었던 것 같다. 그걸 보고 로봇 같던 팀장님이 '채연님 1.2인분 하시네요'라는 말을 해주셨음.

대충 춤추는 고래 되어서 지금은 목표가 0.8과 1.2의 평균인 1인분하기가 되었다. 최종 프로젝트가 끝나고 나면 온전한 개발자 지망생이 되어 있으면 좋겠다고 진심으로 생각했다.

1-4. 백엔드와 첫 만남, 그리고 아이디어 구체화

사람이 친해지는 데에 함께 보낸 시간의 양은 필수 조건이 아니라고 생각하지만, 관계가 깊어지는 데에는 절대적인 시간이 필요하다... 라는 걸 백엔드 팀을 보면서 다시 한번 느낌.

여튼, 가벼운 아이스브레이킹과 함께 생각해온 아이디어를 발표해보기로 했고 운 좋게도 의견이 빠르게 취합되어 기능 구체화가 이루어졌다. 기획서도 하루만에 작성한 뒤 기능 명세서를 작성하고, 와이어프레임을 하루종일 만들고 있던 와중에 백엔드 측에서 기획을 다시 해야할 것 같다고 얘기했다. 기획서 제출 마감 기한 이틀 전이었으므로 새로운 아이디어를 세우고 급하게 구체화 했다.

결과적으로 아이디어도 잘 바꿨고 현재도 늦어지는 것 없이 잘 개발되고 있지만, 이 일을 통해 프론트엔드와 백엔드가 더 잘 소통하고 가까워야 한다는 것을 모두 배웠다.

프로젝트 주제는 Skrrr인데 프로젝트 끝나고 더 자세히 쓰는 게 나을 것 같음.

2. 프로젝트 개발

굴러가는 쓰레기에서 굴러가는 자동차로 발전시키는 MVP 패턴.

우린 1차 공통 목표로 굴러가는 Skrrr을 만들기로 했다. 자연스럽게 기능 명세서를 기반으로 우선순위를 Must, Should, Could로 나누었고 굴러가는 Skrrr에 필요한 최소 Must를 뽑아 역할을 분배하여 개발을 시작했다. 나는 우선순위는 자연수로만 나누었었는데 MoSCoW라는 걸 백엔드 덕에 알게 되었다.

갑자기 다른 말이지만,

MoSCoW...발음 편하게 하려고 삼행시마냥 억지로 짜맞춘 것 같음... 대소문자 섞여 있어서 타이핑도 힘듦... 지극히 개인적인 의견입니다.

유저 스토리 기준으로 역할을 분배하다 보니, 모두가 동일한 task를 맡을 수 있어서 좋았던 것 같다. 무슨 말이냐면, 전 팀에서는 api를 담당한 테크리더가 있어서, 직접 api관련 로직에 손 댈 필요 없이 갖다 쓰기만 하면 됐었는데 이번에는 한 명이 하나의 스토리에 대해 전적으로 책임을 갖고 있으므로 api 연결부터 ui 디자인, 테스트까지 전부 하게 되었다. 완전 1인분 하고 있는 것 같다는 생각에 심취해 있음 그래서.

아직 프로젝트 진행 중

• 데모데이도 끝나서 프로젝트 기간의 공식적인 절반이 지나버렸다. 회고글에 학습적인 부분이 빠진 이유는...개발하면서 막히는 기술 문제에 대해서 주제라도 프론트엔드 팀원끼리 공유하는 개발일지에 써놓고 있기 때문. 최종 프로젝트가 끝나면 홀가분한 마음으로 개발일지 정주행 하면서 정리하여 글을 쓸 수 있겠지.

• 본격적인 개발에 들어간 지 꽤 되었지만 지금까진 맛 보기였던 것 같고, 이제는 진짜 정신 없을 것 같다는 막연한 두려움이 있다. 그렇지만 열심히 하고 성공적으로 끝내서 쫑파티 하겠지 뭐. 재밌다

• 아무리 사회성이 좋고 착해도 개발자라면 개발을 잘해야 하는 것 같다. 이전 팀에서 받은 피어리뷰를 보고, 팀에 있어서 기술적인 기여를 하는 사람, 도움을 주는 팀원이 되고 싶다고 생각했다. '님 착한데 개발 못함요 ㄱㅊ' 보다 '재수 없는데 잘함;;'이 더 좋음... 계속해서 실력적인 한계를 느끼고 있지만 넘 바빠서 부채감을 인지하는 것도 사치 같다.