[Retrospect] 프로젝트 회고 - 김재우 #146
Description
파이널 프로젝트 4주간 회고록
드디어 길고긴 4주간의 프로젝트가 끝을 보이게 되었다.
지난 시간을 돌이켜 보아도 정말 힘든거 밖에 떠오르진 않는 시간이다.
이 글에서 4주간의 회고 기록을 남긴다.
1주차 회고
이번 파이널 프로젝트에서는 팀장이란 직책을 부여받고 프로젝트에 임하게 되었다. 당연히 어깨가 무거웠다.
그렇기에 더욱더 이번에는 퍼스트 때 보다 완성도가 있는 결과를 내고 싶은 욕심이 들었다.
팀장으로서 역할은 무엇이 있을까 생각하면서 팀윈분들에 아이디어를 모으는것에 적극적으로 임하면서 첫주를 시작했다.
SR 기획 아이디어 선택
첫날 부터 팀편성이 잡히는대로 바로 아이디어를 모으는것에 하루를 넘어 거의 이틀은 소비하였다.
우리 팀은 끝내 두가지로 나누어 정해야 했는데 하나는 이전에 기수분들이 만든 맥주 관련 맞춤형 큐레이션 방식에
서비스를 벤치마킹해서 같은 방식의 서비스를 만드는 것과 조금 독특하면 새로운 방식에 서비스인 내가 태어난 날에는
어떤 날씨인가에 대한 질문으로 시작함 서비스인 "Birth-Wiki"가 있었다.
이 서비스는 유저의 생일을 입력으로 다양한 과거의 정보를 불러와 카드의 카테고리별로 담게 되는데 주로 같은 생일날에
일어난 사건과 문화이슈, 그달의 영화정보와, 음악정보, 그리고 같은 생일날인 유명인과 사망정보까지 조회가 가능한 서비스다.
여기에서 우리팀은 조금 독창적인 후자를 선택하여 지금의 "Birth-Wiki" 서비스를 만들었다.
깃 플로우
지난 퍼스트 프로젝트에서 우리팀은 깃워크플로우를 제대로 활용하지 못 한부분이 있었다. 집나간 브랜치가 허다하게
나왔으며 이들 모두를 제대로 감당하지 못하고 마지막에는 서로의 코딩을 슬랫에 커뮤니티창에다 복붙해서 수정하는 일이
생겼다. 이같은 경험으로 우리는 이번 파이널에서 그 부분을 집중적으로 신경쓰면서 이틀내지안으로 다같이 확인 하며 PR을
날리고 리뷰하면서 신중하게 Merge까지 확인해 가면서 진행했다. 팀원분이신 "이창민"님께서 이를 하나하나 짚어가면서
확인하셨기에 지금의 파이널에서는 집나간 브랜치 없이 제대로 관리가 되었다.
새로운 스택
이번 프로젝트의 첫 주는 퍼스트때랑 다르게 우리가 사용하지 않은 기술 스택을 사용하여 프로젝트를 완성시키는 걸로
정했다. 분명 배우는게 있고 얻어갈수 있는 경험이지만, 그만큼 우리가 사용할 수 있을 정도로 학습을 하는 시간도 필요했다.
적용할 스택은 Typescript 였다. 분명 배우는게 어려움점이 있었지만 그 만큼 후반에 버그와 에러를 잡아준다는 점에서
큰 메리트가 있는 결정이었다. 또한 지난번 퍼스트때는 css을 관리하는게 힘들었다. 세명의 프론트엔드가 css 스타일을
App.css에 적용해서 중첩이 생기는 경우가 있었으며 이를 방지하고자 Styled component를 이번 파이널에 적용하기로 했다.
css 파일을 밖에 두지 않고, 컴포넌트 내부에 넣기 때문에, css가 전역으로 중첩되지 않도록 만들어주는 장점이 있어 선택했다.
그렇게 우리팀은 한주간 기획작성 더불어, Typescript, styled component를 각자 개인적으로 학습하는걸로 마무리 지었다.
2주차 회고
파이널 프로젝트 2주차에 들어오면서 본격적으로 코딩을 시작해 개발작업에 착수하게 되었다.
첫날부터 시작한 일이 바로 세명의 프론트엔드 개발자를 위한 vsCode에 환경 세팅이다.
환경 세팅
가장 먼저 Typescript 기반의 확장자가 있는 리엑트앱 설치는 그렇게 어려운 단계는 아니었다.
기존의 리액트에 CRA를 응용한 리액트 보일러플레이트와 동일한 방식에 Typescript가 깔려있는
환경이 세팅된 보일러플레이트 설치 할 수 있기 때문이다. 다음으로 코드의 가독성을 높혀주고 에러나
컨벤션에 관해 경고 해주는 유명한 툴을 설치하면 되는데 흔히 알려진 툴이 바로 eslint와 prettier다
회의시간 하루 한번
개발환경 세팅이후 팀원들 각자 맡은 부분을 작업하면서 진행했다. 아침에는 대체로 컨디션 조절이 힘들다고 생각되어서
하루 미팅은 오후5시에 진행하는걸로 정했으며, 좀 더 개인적으로 코딩을 집중하는 시간을 가지도록 했다. 물론 중간중간에
어려운 부분이 있거나 공유할 사항은 디코로 항상 연락하도록 정했다. 이때 당시에 다들 처음 써보는 스택에 학습을 변행하면서
개발에 착수하였던거 같다.
3주차 회고
분명히 적지 않은 시간이 주어진 것 같아도 막상 개발을 하다보면 금새 시간은 간다.
주어졌던 시간에 비해 크게 진척이 없었던게 아닌가 생각되던 3주차였다.
에러 핸들링
1주차 부터 시작해서 디코에다가 채널방에 코드 작업중에 에러 발생시 이를 공유하고 그것을 해결할수 있는 방법 또한 같이 공유할 수 있게
정했다. 물론 이는 비슷한 에러가 발생한것도 이미 공유한 내용에서 보고 참조하기 위한이었으며 작업중에 에러가 발생한 확률을 줄이게 된다.
깃 이슈에도 따로 에러 핸들링을 올릴 수 있지만 디코에서 먼저 빠르게 에러문제를 접해서 해결 할수 있다는 점에 나름 효율적인거 같아 그대로 썼다.
4주차 회고
아침에도 코딩...새벽에도 코딩...
대망의 마지막 주차까지 왔다. 여기서 부터는 거의 나부터 해서 우리 팀 모두의 생활 패턴이 크게 바뀌었을꺼라 생각한다. 당장의 나부터도 아침에 일어나면 컴퓨터 키고 코딩...밥먹고 코딩...새벽에 늦은 시간까지 코딩을 하게 된다. 자세하게 공유하지 않았지만 팀원 모두가 그렇지 않았을까 유추해본다.
최소한의 해야하는것, 나중을 기약해야 했던것
그만큼 현재 우리의 작업은 막판에 이르러 게속해서 버그와의 싸움이었다. 각자가 만든 결과물을 합치고 그걸 수정하고 아에 다시 만들어 집어넣고
많은 수정작업을 거치면서 최소 Bareminum 과정까지 나올 수 있게 했다. 최대한 할 수 있는 기능과 없는 부분을 나누어서 할 수 있는것을
시연 영상으로 담아 발표할 때 선보였으며, 이후에 더 추가하거나 리팩토링을 할 부분은 4주차 프로젝트가 끝난 이후를 기약하면서 보류했다.
그게 당장에 할 수 있던 최선의 선택이었다.
4주차가 끝나고 느낌점 그리고 반성
새삼 실감이 안난다. 어느새 4주차가 끝나고 각자 발표할 PPT를 만들고 기술영상도 찍고 바로 다음에 수료하는 날까지 지났다.
분명 코드스테이츠에 들어와서 배운점도 꽤 많았고 너무도 많아서 그냥 놓치것도 많은거 같아 걱정이다. 특히나 프로젝트를 진행하는 동안
스스로가 아직 덜 배운게 아닌가 생각될 정도다. 다른 팀원분에게 어떻게 하는게 좋을까요를 물어보면서 의지했던 점도 있었고, 게속 인터넷을
뒤져가면서 그것을 가져와 활용하기도 했다. 어찌보면 지금의 파이널프로젝트까지 진행하면서 스스로가 아직 더 공부가 필요한 점이 무엇이
있는지 알아낸것도 성과라면 성과일 수 있지 않을까 생각한다. 수료이후 좀더 시간을 가지고 나의 부족한점을 매꿔야 하는 시간이 필요하다.