드디어 코드스테이츠에서의 파이널 프로젝트가 막이 내렸다.
파이널 프로젝트 인트로때 봤던 선배 기수들의 결과물들을 보면서 '와.. 진짜 잘했다.. 어떻게 한거지..?'라는 생각을 하며 시청을 했던게 아직도 기억에서 지워지지가 않는다. 어쨌든, 14팀 팀장은 사다리타기를 통해 '나'로 정해졌다.
그렇게 기대 반 걱정 반으로 시작했는데, 난 4주동안 팀장으로서 책임과 역할에 대해서 많이 깨닫게 되는 시간을 갖게 됐다.
팀장으로서 일정을 조율하고, 업무를 분담하고, 매일 회의때 팀원들 업무 진행 체크와 이슈를 공유했다. error 해결을 하지 못하는 팀원은 나와 공유해 같이 해결할 수 있도록 DM을 주고 받거나, 구글밋으로 만나 같이 해결했다. 또한 기능구현에 막힌 팀원은 나와 1:1 페어로 같이 진행해 해결하곤 했다. 솔직히 내가 할 일도 바빴다. 그래도 팀장은 내가 당장 할 일보다 팀적인 부분을 더 생각해야 된다고 매일 다짐하며 조금 희생한? 부분도 있었다. 그래서인지 나에게는 4주라는 시간이 짧게 느껴질 만큼 순식간에 지나갔다.
사실 난 프로젝트 팀장이 처음은 아니지만, 그래도 많이 부족하다고 느껴지는 프로젝트였다. 코드스테이츠 부트캠프에서 학습을 하고, 시험을 통과할 때 마다 어쩌면 자신감이 많이 생겼던 것 같다. 그런데 나의 이런 오만함을 '우물안의 개구리'라며 깨우쳐 준 프로젝트였던 것 같다. 배울게 아직도 많은 것 같다.
아이디어 선정 Jumo
우리가 정한 주제는 '막걸리 큐레이션 서비스'이다. 1.세계사를 지도로 보여주기, 2.화상 채팅으로 같이하는 방탈출 게임, 3.인생 그래프를 그리는 커뮤니티 사이트 등 이것저것 많은 아이디어를 거쳤다.
1번의 경우엔 CRUD 와 로그인 기능이 굳이 필요하지 않은 컨텐츠인 것 같아 반대했다. 2번은 시간적, 기술적으로 구현하기 힘들것 같다고 판단했다. 3번은 유저의 유입과 활동에 의존하는 컨텐츠이고, 인생그래프를 그리는 기준점이 애매모호했다. 그리고 개인적으로 나라면 굳이 이런 서비스를 이용하지 않을 것이라고 판단했다.
'막걸리'에 관한 서비스를 기획하게 된 이유는 우리나라 전통 술, 막걸리를 젊은 세대들에게도 관심을 주고 싶어서였다. 그래도 주제가 평범한데도 불구하고 정하게 된 이유는 랜딩페이지를 특별하게 만들어보고, css로 열심히(캐러셀, 인피니트 스크롤&애니메이션, 슬라이드 방식 등..) 이쁘고, 참신하게 꾸며보자라는 합의가 있었다.
SR단계
아이디어 회의를 통한 주제선정, SR단계에서 우리의 아이디어를 좀 더 구체적으로 그려냈다. SR단계가 정말 힘들었던 것 같다. 평범한 주제는 피하고 싶었고, 기술적으로 가능한 수준의 주제를 선정하고 싶었던 만큼 주제선정에 어려움이 많았다. 그렇게 우리는 SR에서 1주일이라는 시간을 보내야만 했다.
우리는 Miro 로 프로젝트의 전반적인 틀을 스케치하고, 다시 Figma 로 좀 더 구체적인 UI와 와이어프레임을 설계했다. 반응형을 고려한 UI를 기획하다 보니 첫번째 프로젝트 때 보다 두 가지의 일을 하는 것 같았다.
프로젝트의 전반적인 일관성을 유지하기 위해 컬러 컨셉부터 잡는 것도 신중했으며, UI 작업을 하다보니 주제가 더 뚜렷하게 되거나 추가하고 싶은 기능이 생기기도 했다.
UI단계
프로젝트 진행 1주일이 지나서야 드디어 우리는 본격적으로 코딩을 시작할 수 있었다. 우리는 하드코딩으로 목업을 먼저 잡기로 했다. 목업을 잘 만들어 놓으면 그 위에 css로 색을 입히고, 하드코딩된 부분은 javascript 함수로 기능구현해 실데이터를 넣어주는 작업에 집중할 수 있기 때문이다.
우선 우리가 잘 만들어 놓은 Figma 를 보면서 반응형(pc/tablet/mobile) 레이아웃을 잡았다. 반응형 제작을 처음하다보니 실수를 한 번했는데, 한 페이지의 pc view를 모두 만들고 다음 디바이스 view를 작업하려다보니 엘리먼트를 찾을 수 없는 복잡함을 겪었다. 그래서 결국 나는 처음 부터 다시 작업을 시작해야만 했다. 한 페이지에서 하나의 구간을 mobile > tablet > pc 단계적으로 레이아웃을 잡아줬다. 하나의 구간을 완료할 때 마다 브라우저 크기를 접었다 폈다 하면서 반응형이 잘 적용되고 있는지 확인 반복했다. 이렇게 작게 구간을 잘라서 작업을 하다보니 엘리먼트를 못 찾는 상황을 겪지 않아도 됐다.
캐러샐 슬라이드 UI 를 작업하는데 조금 어려움이 있었다. 캐러샐 원리를 깨닫기 위해 구글링도 열심히 해봤고, 우리가 생각하는 UI로 적용하기 위해 수 십장의 스케치를 하면서 진행했다. 구글링을 통해 볼 수 있었던 캐러샐은 한장씩 보여주면서 한쪽으로만 이동가능한 형태이거나, 모두 동일한 크기의 슬라이드로 구성됐다. 하지만 우리가 기획했던건 5개씩 보여주면서, 양쪽으로 자유자재로 이동가능한 형태이며, 가운데 부분에 포인트를 주기 위해 다른 슬라이드 보다 독보적으로 커야했다. mobile에선 위에는 1개 밑에는 3개로 보여줘야했다.
난 뫼비우스 띠를 생각했다. 배열형태로 슬라이스해서 버튼을 누를 때 마다 index를 1씩 증감해줘 구현에 성공할 수 있었다.
개발
local 에서 테스트 개발 진행을 먼저하고, server 와 연동하는 개발을 하려고 했다. 때문에 client 와 server 간의 완전히 분리된 상태로 서로 작업을 할 수 있었다. client 에서는 최대한 server 와 통신했을 때 응답받는 형태로 테스트를 진행했다. server 에서 응답주는 형태가 json 타입의 객체 형태인 점을 고려해 dummy 데이터를 js 파일에 객체 형태로 만들어 테스트했다.
Redux
local 테스트 개발 진행에선 Redux를 사용하는 그 이유와 목적이 빛을 발휘했다. 하지만 server와 연동하고 나서는 어떤 상태를 store에 저장해야 하는지 프로젝트 진행내내 이 고민을 했던 것 같다. server에게 요청을 하면 DB에 저장되 있는 data 를 응답으로 주는데, 어떤 data를 store에 저장할지 잘 몰랐던것 같다.
Redux는 state를 전역적으로 관리하기 위함이다. 어떤 컴포넌트라도 store를 통해서 접근가능하고 Container 컴포넌트에 데이터를 집중화시켜 하위 컴포넌트에서 데이터를 접근하지 않더라도 state를 쉽게 전달할 수 있게 해준다. 프로젝트 규모가 커지고 복잡해지면서 상태가 많아질 수 밖에 없다. 상태를 관리하기 힘들어져 상태가 언제, 왜, 어떻게 변화되었는지 알기 어렵다. 그렇기 때문에 이를 관리하고자 Redux가 만들어졌다고 생각한다.
나는 로그인과 모달창 상태 관리에 사용했다.
Infinite Scroll
평소에 유튜브를 많이 이용하면서 프로젝트에 꼭 넣고 싶은 기능으로 내 버킷리스트에 추가될 만큼 애착이 가는 부분이었다. 이를 구현하기 위해서 Infinite Scroll의 원리와 구현방법을 많이 공부할 수 있었던 시간을 갖었다. 나는 사용자의 디바이스 크기와 스크롤의 위치를 이용해서 구현하는 방법과 커스텀 Hooks로 Last Element에 마킹을 해줘 다음 Element를 덧붙이는 방식중 고민했다. 첫번째 방법은 성능 최적화에 좋지 않다고 느껴 두번째 방법을 이용해 만족스런 결과로 구현에 성공할 수 있었다.
프로젝트에서 굉장히 재밌었던 기억으로 남아 개인기술영상 주제로도 선정했다.
Git
우리는 일관성있고 직관적인, 의미있는 commit message 를 위해서 Gitmoji를 이용했다. 나중에 commit이 쌓일때마다 뿌듯함을 느끼곤 했다. 'push' or 'pull' 이런식으로 명확하지 않고 의미없는 commit message를 방지하기 위함이였다.
팀 프로젝트를 하다 보면 서로의 소스를 합치는 데 있어 충돌이 빈번히 일어나곤 한다. 우리 역시 프로젝트 내내 충돌로 고생을 했다. 처음엔 최대한 충돌이 일어나지 않도록 페이지 단위로 업무를 분담해 피할 수 있었지만, 프로젝트 중후반으로 갈 수록 컴포넌트 개발이 많아지면서 서로의 소스가 충돌이 일어날 수 밖에 없었다.
나는 파이널 프로젝트를 하면서 Git에 대한 두려움이 많이 사라진것 같다. 더이상 commit이 귀찮아서 의미없는 commit을 하려거나, 충돌이 두려워서 push, pull 을 미루는 일은 없어졌다.
프로젝트를 마치며
다시한번 팀원 간의 원활한 의사소통과 협업의 중요성에 대해 많이 깨닫게 되는 시간이었다. 프로젝트라는건 나 혼자서 완성할 수 없다. 우리는 서로의 다름을 인정하고, 팀 적인 시너지를 위한 업무 분담을 해야한다.
틀림이 아닌 다름
사실 우리는 프로젝트 주제를 선정할 때, UI를 구체화할 때, 클라이언트와 서버간의 통신 방법을 정할 때, 업무가 딜레이될 때 의견 대립이 있었다. 서로의 의견을 좁히는데 있어 시간을 소모하기도 했다. 예를 들어 내 주장에 대한 근거를 논리적으로 설명하기 위해서 구글링으로 찾아 설명하고, 해당 URL을 주기도 했다.
의견을 하나로 모으는 것이 그 만큼 힘들다는 것을 많이 느꼈다. 처음엔 의견 대립이 있을 때 답을 정해놓고 내 의견을 말하기 바빴다. 하지만 그건 의견을 좁히는데 있어 도움이 되지 않고, 시간만 보낸다고 생각했다.
그래서 방법을 바꿔봤다. 다시 처음부터 생각하면서 의견을 듣고, 상대방의 논리를 이해하면서 내 의견과 비교해 서로의 의견에 대한 장/단점에 대해 이야기를 하다보니 해결할 수 있었던것 같다.
지금 생각해보면 의견을 하나로 모으는 과정이 다소 시간적인 투자가 있긴 하지만, 우리 프로젝트의 완성도를 높이고 배우는 것이 그만큼 많았던 것 같다. 내 의견에 긍정하는 사람보다 피드백을 주는 동료를 더 가까이 하자!
원활한 의사소통
프로젝트 진행하고 같은 기능에 대해 서로 다르게 이해했던 부분도 있었다. 프로젝트 끝 무렵에 배포를 하고나서 한 팀원은 마치 처음 본 사이트인것 처럼 이것저것 우리에게 질문을 했다. SR단계에서 UI작업 인원과 DB스키마 & API 작성 인원을 나눠서 했던 게 화근이였던 것 같다.
그리고 대부분 프론트/백 나눠서 회의를 진행했던 부분도 공유가 제대로 안된 큰 원인이었던 것 같다.
팀 시너지
내가 오늘 작업한 부분, 앞으로 어떤 작업을 더 해야 할지에 대해 명확하게 이야기되지 않다보니 작업의 비중이 한 쪽으로 지나치게 쏠려버리는 문제가 발생하기도 했다. 분명 매일 회의를 통해 서로의 업무진행을 체크할 수는 있었다. 하지만 아직 끝내지 못한 부분에 대해서 언제까지 끝낼 수 있는지에 대해 명확하지 않았고, 결국 우리가 예정했던 기간보다 1일, 2일, 3일.. 딜레이만 계속 됐다. 이 부분은 개인의 의지나 실력적인 문제도 있겠지만, 그런 환경에서도 최선의 결과를 낼 수 있도록 협의하여 더 나은 방법을 제시해야 했다.
팀장으로서 느낀점
팀원의 실력이 모두 같을 순 없다. 나는 지금까지 실력적으로 조금 부족한 팀원은 쉬운 업무를 주거나, 조금 주는 방식으로 진행했다. 하지만 팀원 개인의 성장이 곧 프로젝트 결과에 긍정적인 영향을 줄 수 있다는 생각을 했다. 코딩 외적으로 프로젝트 참여에 대한 의지가 생겨 팀원이 성장할 수 있도록 동기부여하는 것 또한 리더인 내 역할이라고 반성한다.
'포트폴리오 > 웹개발' 카테고리의 다른 글
| 푸딩(Fooding) / 랜덤 음식 추천 푸딩봇 (0) | 2021.03.29 |
|---|---|
| 데코레이팅즈 / 웹 기반 인테리어 쇼핑몰 (0) | 2019.08.11 |
| 넘버원 / 사용자 중심의 학사관리 프로그램 (0) | 2019.08.11 |
