다사다난했던 2차 프로젝트를 회고해보고자 한다.
글을 쓰고 있는 시점이 벌써 한 달 전이라는 게 믿기지 않는다...써야지 써야지 하면서 못쓴 것도 그렇지만 벌써 2차 프로젝트로부터 한 달이나 지났다니, 위코드에서는 시간이 정말 빠르게 흘러가는 것 같다. 그만큼 숨가쁘게 달려왔다는 의미겠지. 그럼에도 아직 모르는 것이 한가득이고, 배워야하는 것은 산더미라는 게 아득하다. 기업협업까지 하고 나서도 한동안은 배우고 찾아보느라 정신 없을 것 같다만 위코드에서만큼은 아니길 바란다.
2차 프로젝트 기획 회의
우선적으로 회의에서는 백에서도 프론트에서도 흐름을 잘 알고 계신 팀원분들이 있으셔서 그렇게 크게 어렵지는 않았다. 역시 이끌어주는 사람, 흐름을 잘 유도하는 사람이 있다면 수월하게 회의가 진행된다는 것을 알 수 있는 부분이었다. 나는 아직 백에서 데이터에서 어떤 식으로 테이블의 흐름을 잡을 지에 대한 감도 없고 지식도 없었기 때문에 프론트에 관한 이야기를 하면서도 잠깐잠깐 대화의 흐름을 놓칠 때가 많았다.
특히 기획에서 말하는 특정 단어들 예를 들면 오더와 장바구니 같은 것을 일상생활에서의 개념으로 생각하고 있어서, 해당 부분을 구현하고 백과 통신을 준비하던 그 순간에서야 아 이래서 네이밍이 중요하구나 싶었다. 머리로는 플로우를 이해했지만 아 오더는 이 페이지, 이 기능을 의미하고 장바구니는 이 페이지에 이 기능을 의미하고 있는 거구나 하고 연관 지을 수 있었던 것은 해당 티켓을 구현하고 있을 때쯤이었으니. 이때 머리에서 생각하고 있는 것을 정확히 정립해놔야 다른 사람들과 의사소통하는 것에서도 프로젝트의 차원에서도 이슈가 생기지 않는 다는 것을 몸소 깨닫게 됐다.
기획회의가 끝나고 트렐로 티켓을 발급받았을 때에는 굉장히 아득했었다. PM을 맡으신 팀원분이 굉장히 꼼꼼한 성격이셨기 때문에 티켓을 매우 세세하게 분류했는데, 프론트 3명이서 분배를 맡고 나니 내 앞으로만 티켓이 8개 가량이 분배가 됐었다. 지금 생각해보면 두번째로 하는 프로젝트라서 아득해 보였지 이 후 3차 프로젝트에서도...어쨌든. 그 때 당시에는 아 할 수 있을까? 너무 많은 거 아닌가? 언제 다 할 수 있으려나 싶은 생각과 어떻게든 되겠지 싶은 낙관적인 생각이 교차했다. 그리고 프론트에 PM을 맡으신 팀원분이 알고 계신 것도 많고 이것저것 도입하고 싶은 것도 많으셨기 때문에 트렐로 발급을 위해 해야할 일들을 정리하고 있을 때부터 단호하게 component분리해서 사용하셔야 하는 거 아시죠? 라고 못박고는 티켓을 만드셨다.
component분리도 해본 적 없고, props도 예시로 조금 사용해 본 것 말고는 없었던 나는 속으로 당황했지만 머리는 그래 너도 해야되는 거 알잖아. 해. 라는 의식의 흐름에 따라서 입으로는 넵, 네 알겠습니다를 반복했었다...
트렐로 티켓 발급 이 후: 코드 작성
처음으로 만들었던 컴포넌트는 아마 시간이 좀 더 흘러도 쉽게 잊히지 않을 것 같다.
첫 컴포넌트는 props를 통해서 조건을 주고 그에 맞게 스타일이 달라질 수 있도록 로직을 짜둔 button component였다. scss에서 조건을 주는 것도 난생 처음이었고 props내리는 것도 처음이라 만드는데 하루는 족히 걸린 것은 물론 프로젝트 내내 이거 없어요. 이것도 없어요 이건 크기가 달라요. 수정 부탁드립니다. 라는 말을 들었다. 나중가서는 정돈된 코드고 뭐고 시간이나 정신력이 부족해서 지저분하게 코드를 작성하게 됐다. 그렇다고 처음에 깔끔히 작성했다는 것도 아닌게 슬프다만. 나중에 리펙토링 해야겠다는 다짐만...지금도 다짐만 하고있다.
props로 특정 값을 내려주고, button 태그에 속성을 넣어서 그 속성이 특정 값일 경우를
&[scale='small']{}
앤드 연산자와 대괄호 사이에 선언하여 선택해올 수 있었다. 막상 이렇게 보면 어렵지 않은데 그때 당시에는 완전히 처음 해보는 것이었어서 props로 내리면 뭐해 이걸 어떻게 가져오지 하는 생각에 꽤 시간을 잡아먹었다. 컴포넌트를 만들고, props를 설정하고 전달하고, 속성을 가져오는 것까지 예시코드와 함께 설명해주셨던 팀원분 덕에 수월하게 코드를 칠 수 있었다.
그 다음으로 애먹었던 부분은 장바구니 페이지에서 백으로 넘겨줄 데이터를 가공하는 부분이었다.
수량과 금액을 넘겨줬어야했는데 받아온 값을 어떻게 조합해서 원하는 형태로 깔끔하게 만들어서 보내줘야할지...데이터 가공의 무서움을 여기서 잔뜩 경험하게 됐다. filter나 find Array.map등의 배열관련 함수를 가장 많이 경험한 부분이 이 데이터 가공 부분이 아니었나 싶다. 앞으로도 많이 사용될 것 같으니 미리미리 찾아보고 공부할 수 있는 시간이 있었다는 것은 좋았지만 이 데이터 가공하겠다고 2~3일 가까이 잡아먹었던 것을 떠올려보면 적당한 타이밍에 멘토님에게 도움을 구하는 것이 낫지 않았을까 싶다. 다른 할 일도 많았던 순간에 한가지에 너무 몰두하고 붙잡고 있는 것은 프로젝트 관점에서 좋지 못했다.
2차 프로젝트 때에는 후반부분에 시간이 너무 없어서 밤도 꽤 세어가며 시간이 너무 없는 것을 한탄했는데 초반에 쳐내야할 것들을 빠르게 빠르게 해결하지 못했던 부분이 시간 부족의 주 원인이라고 생각한다.
물론, 변명을 해보자면 2주 프로젝트 였던 것이 중간에 추석이 끼며 한 주 정도 위코드가 휴가주였다. 일주일의 휴가 기간 중 당연히 코드를 안친 것은 아니었으나 위코드에 나가서 코드를 작성했던 것보다야 훨씬 적은 시간을 보냈다. 또한, 컴포넌트 분리에 익숙하지 않아서 이것저것 시도하고 공부하고 기능을 구현할 수 있을만큼 숙지하는데 시간을 꽤 잡아먹었다.
날 열심히 독촉하시던 프론트 팀원분께는 이 부분에 대해서 변명하지 말라고 하겠지만 말이다. 그리고 변명이 맞다. 그래도 팀원님 저 끝까지 포기는 안했어요.
프로젝트의 마무리: 반성과 느낀점
잘하고 못하고를 떠나서 작업할 때 성향이 맞냐 아니냐가 꽤 심력을 많이 소모하는 일이었다.
작업량이 많았던 것보다 같이 작업하는 팀원과의 성향을 맞추고 서로 의사소통을 어떤식으로 하는 것이 좋을지 대화는, 의견은 어떻게 말을 해야하는지가 훨씬 나에겐 정신적으로 힘들었다.
상대가 말하는 것이 근거가 있다고 모든 것이 맞다고 하는 것은 장기적으로 나에게 좋지 못하다는 것을 알아갈 수 있었는데, 상대의 근거를 듣고 내가 납득하고 수긍하는 것과 내 근거를 내세워 의견을 표출하는 것은 엄연히 다른 영역이다. 상대의 의견도 틀린 것이 아니며 내 의견도 틀린 것이 아니다. 그렇다면 그저 서로의 근거를 돌이켜보고 생각해본 뒤에 조율하는 과정도 필수적이다.
나는 내가 생각하는 것과 다르다해도 왜 그래야하지? 납득하지 못해도 근거가 타당하다고 생각하면 그저 수긍하고 내 의견을 말하지 않았다. 하지만, 조용히 수긍하는 것과 의견을 말하고 납득하고 수긍하는 것은 다르다는 것을 알게 해준 프로젝트였다.
서로가 서로에게 그다지 좋은 인상이 아니었으나 프로젝트 마지막주에 날을 세어가며 통신하고 수정하고 오류를 픽스하고 다사다난한 시간을 보내며 좋게 마무리해서 결과적으로는 나쁘지 않은 사람으로 내게 남게 되었는데, 팀원분들에게 나 또한 그렇게 남았기를 바라며.
2차 프로젝트를 하며 팀원들이 모두 고생을 많이 했다. 백에서도 이런저런 일들이 많았었고, 프론트에서도 저런이런 일들이 많았었다. 그럼에도 불구하고 프로젝트는 마무리되었으며 이렇게 시간이 지나 떠올려보면 힘들긴 정말 힘들었으나 얻어갈 게 많았던 2차 프로젝트였다. 1차 프로젝트를 하며 했던 발전보다 2차 프로젝트를 하며 발전이 훨씬 크고 넓었다.
스트레스를 받으면서도 포기하지 않고 마지막까지 붙잡고 있기를 잘했다는 생각을 한다. 만일 마지막 주에 아 이건 안된다. 못하겠다. 하고 포기하고 그냥저냥 넘겨버렸다면 이렇게 후련하지도 않았을 것이며 회고록을 작성하는 이 순간에 내뱉을 말도 없었을 것이다.
2팀 모두 감사합니다. 고생하셨습니다.
그리고 아직 모자른 게 많은 나에게, 좀 더 고생하자.
