이곳 부트캠프에서는 처음 진행한 팀 프로젝트..! 2주 동안 정말 팀원들과 잠도 안자고 치열하게 달리면서 결국 하나의 쇼핑몰을 완성했다. 짧다면 짧은 기간 내에 문제가 생겼던 부분도 많고 새로 알게 된 내용도 정말 다양했다. 그래서 이번 프로젝트에 대한 회고록을 아래와 같이 정리해보려 한다. 전체 기능 소개는 깃허브 리드미에 남겨두고, 이번 글에서는 경험한 코드를 위주로 기록해본다.
목차
- 4iz 프로젝트
- 프로젝트 소개
- 개발 기간 및 인원
- Trello & Figma
- 첫 프로젝트를 마치며
- 잘한점 / 아쉬운점
- 마무리
4iz 프로젝트
🏃 4iz는 어떤 서비스일까?
이번에 참여한 프로젝트 4iz는 국내 1020 타겟의 스포츠 의류를 판매하는 웹서비스이다. 나이키를 벤치마킹하여 제작되었고, 인터렉티브한 UX와 직관적인 UI 구성을 중점적으로 염두에 두고 구현했다.
- 4iz 프로젝트가 궁금하다면? 깃허브 바로가기
📅 개발 기간 및 인원
2주 동안, 2명의 백엔드와 2명의 프론트엔드 총 4명의 팀원이 함께 하나의 웹서비스를 구현했다.
이번에 나는 Product Manager(PM)를 맡아 전반적인 프로덕트의 기획을 담당하고 방향성을 잡았으며, 발표까지 진행하게 되었다.
처음 만난 Trello ⏰
한정된 기간 내에 위 기능을 모두 구현하기 위해서는 무엇보다도 체계적인 일정 관리가 필수적이었다. 우리 팀에서는 Trello를 활용하여 티켓별로 업무를 구분하고, Backlog, ToDo, In Review(PR), Done으로 업무 진행도를 측정했다. 회의록 및 json 파일과 같이 프론트-백 간에 공유할 정보는 별도로 구역을 할당해서 모아두었다. google docs나 notion같은 별도의 플랫폼을 이동할 필요 없이 트렐로에서 문서를 한 번에 관리하니 확실히 헤매는 시간이 줄었다.
회의의 경우에는 매일 오전 10시에 스탠드업 미팅을 진행하고, 매주 스프린트 미팅을 진행하면서 2주를 일주일로 나눠 일정을 체크하는 시간을 가졌다. 애자일한 스크럼을 따라 촘촘하게 티켓을 관리하고 일정을 트래킹한 덕분에 추가 구현을 제외하고 목표했던 대부분의 기능을 완성해낼 수 있었다.
Figma 적극 활용하기 🎨
자칭타칭 피그마 덕후 (늘 외치는 갓그마) 는 피그마를 안쓰고 지나칠 수 없었다. 이번 프로젝트 역시 피그마를 처음부터 사용하게 되면 프론트엔드와 백엔드 모두에게 도움이 될 것 같다는 생각이 들어 팀원들에게 제안해보았다. 다행히도 모두가 선뜻 ok해줘서 바로 세팅을 진행했고, 프로젝트 진행 도중이나 끝난 이후에도 모두가 만족하는 것 같아서 개인적으로 쓰자고 말하기 잘했다고 생각한다!
피그마로 페이지별 시안을 우선적으로 제작하고 나서 모든 팀원이 컨펌을 완료하고, 그 이후에 개발을 진행했다. 백엔드는 피그마를 사용함으로써 화면에 그려질 모습과 필요한 데이터를 미리 확인할 수 있었다. 프론트엔드는 명확한 수치를 기준으로 통일감 있게 개발할 수 있고, Inspect 탭에서 css 코드를 그대로 가져와 사용할 수도 있기 때문에 더욱 효율적인 마크업이 가능했다. 또한 페이지와 사진, 이미지, 색상 등의 asset을 별도로 분리하고 각 페이지별로 개발 환경에 맞춰 명확한 그룹화 및 네이밍을 진행해서 가독성 높은 협업툴이 될 수 있도록 했다.
구현한 서비스 소개 👀
이번 프로젝트는 사실 프론트엔드가 2명이라 메인, 로그인/회원가입, 상품 리스트(필터링), 상품 상세, 장바구니, 주문, 결제까지.. 이 많은 페이지를 둘로 명확하게 쪼개서 작업하기가 사실 어려웠다. 그래서 함께 남은 티켓들을 하나씩 빠르게 쳐내면서 담당하는 방식으로 진행했다. 그럼에도 불구하고 각자 조금 더 집중적으로 담당한 기능이 있는데, 내 경우에는 기능 면에서 로그인/회원가입과 상품 리스트 페이지에 시간을 많이 할애했다. 아래에서 조금 더 자세히 살펴보자.
- 구현 항목(주로 구현한 부분 ✅):
- 메인, Nav, Footer ✅
- 로그인, 회원가입 ✅
- 상품 리스트, 필터링 ✅
- 상품 상세, 장바구니
- 주문, 결제
로그인, 회원가입 👤
이번 프로젝트에서 초반에 기획을 진행할 때, 우리의 로그인 및 회원가입 방식은 다른 팀과 달랐다. 사용자가 이메일을 입력하면 해당 사용자가 이미 가입했는지 확인한 후 이미 있으면 로그인으로, 없으면 회원가입으로 안내하는 방식이었다.
처음에는 이메일 중복검사, 로그인, 회원가입, 회원가입 성공 페이지를 각각 별도의 페이지로 만들어서 서로 조건에 따라 연결해주는 게 직관적일 것이라고 생각했다. 그런데 생각해보니 모두 유사한 형태(제목, input, 버튼...)를 가지고 있는데 하나의 컴포넌트로 합쳐서 사용할 수 있지 않을까 싶었다. 그래서 아래와 같은 로직으로 변경해서 모두 하나의 컴포넌트로 통합하고, (페이지가 아니라) 조건에 따라 '데이터'를 바꿔주는 방식으로 변경했다.
결과적으로 사용자는 매번 회원가입과 로그인 버튼 중 하나를 고를 필요 없이 이메일만 입력해서 자신에게 맞는 페이지로 안내받을 수 있다. 그리고 구현 측면에서는 하나의 컴포넌트에서 조건에 따라 데이터를 바꿔가며 렌더링하는 방식으로 구현함으로써 하나의 경로(/account)에서 여러 화면을 동적으로 보여줄 수 있게 되었다.
즉각적으로 리팩토링하며 코드 짜기 🧼
길게 늘어진 코드를 최대한 간결하게 줄이면서 코드를 작성하려고 노력했다.
아래와 같이 여러 개로 분리된 state와 함수를 간결하게 줄이는 리팩토링 과정을 구현과 동시에 진행했다.
🛍 상품 리스트 (필터링)
상품 리스트를 백엔드와 통신해서 보여주고, 할인율과 함께 확인할 수 있도록 했다. 할인율이 0일 때에는 별도의 계산 없이 원래의 가격만이 보여지도록 하는 조건도 넣어서 구현했다. 그 외에도 좌측의 카테고리와 필터 기능을 구현했다. 우선 상단의 서브 카테고리는 useSearchParams의 set을 사용해서 택1으로 작동하도록 구현했다. 반면 하단의 성별, 색상, 사이즈의 필터는 다중 선택 혹은 삭제가 자유롭게 가능하도록 구성했다.
우측의 정렬 드롭다운 역시 서브 카테고리와 같이 택1할 수 있도록 구성하고, 가격순 및 최신순으로 정렬 기준을 바꿔서 확인할 수 있도록 했다. 사실 필터 기능 자체가 완전히 처음 구현해보는 부분이라 처음에 많이 헤맸다. 평소에 영어로 자료를 찾는데도 불구하고 상황에 잘 맞는 자료가 많이 보이지 않아서 구글링에도 생각보다 시간을 많이 썼다. 그래도 결국 돌고 돌아 공식문서(돌돌공)이라고, useSearchParams의 공식문서 설명을 보면서 많은 도움을 받았다. 다른 팀에서 필터를 담당하는 팀원들과도 계속해서 머리를 싸매가며 고민하고 어떤 방법이 나은가 생각해보는 과정을 치열하게 거쳤던 것 같다.
추가적으로, 성별 / 색상 / 사이즈의 필터링 함수가 같은 형태로 여러 번 반복되어 이를 줄일 방식을 고안해봤다. 세 가지를 하나로 합쳐서 아래와 같이 구멍을 뚫어 사용하는 방식으로 변경했다.
SCSS에서 for문을 쓸 수 있다고? 🙀
ProductList에 들어갈 색상 필터를 만드는데 상당히 찝찝한 구간이 생겼다. 컬러 버튼을 하나 만들어서 map을 돌리는데 inline style을 쓰지 않고 구현하려다 보니 그에 맞는 컬러 클래스가 하나씩 있어야 했다. 그런데 이 8개의 클래스를 나열하자니 코드가 너무 길고, 같은 형태가 반복되고 있었다.
그래서 이 녀석들을 간결하게 줄일 방법을 고민하다가 결과적으로 찾은 것은 scss에서 반복문을 돌리는 방안이었다. 사용할 색상들을 배열로 선언한 후에 하단에서 nth-child에게 반복문을 돌려 자식 하나하나에 색상을 적용시키는 것이다. scss에서 js 문법을 사용할 수 있다는 것을 전혀 예상하지도 몰랐는데 이번 기회로 새로운 방식을 접하게 되었다. 게다가 공식문서를 더 찾아보니 반복문뿐만 아니라 조건문, 함수 등 대부분의 js 문법을 scss에서 사용 가능하다는 것도 알게 되었다. (뭔가 엄청난걸 알아버린 기분)
결과적으로 아래와 같이 30줄이 넘는 긴 코드를 단 4줄로 줄일 수 있었다.
첫 프로젝트를 마치며
이곳에서는 프론트엔드 개발자로서 참여한 첫 팀 프로젝트이자 처음으로 Product Manager도 맡았는데, 좋은 기억도 많았지만 한편으로는 꽤나 아쉬움이 남는다. 어떤 점이 아쉬웠고 또 어떤 점은 스스로 칭찬해줘야 할 지 아래에 작성해본다.
아쉬운 점
사실 프로젝트가 시작되기 전부터 프로덕트 매니저로써 좋은 프로덕트를 만들어나가고자 하는 욕심에 많은 아이디어를 구상해놨었다. http를 https로도 바꿔보고 싶고, 기획도 완전히 색다른 컨셉으로 변경해보고 싶고, UX도 대폭 개선하고 싶고... 팀원들과 다양한 이야기를 적극적으로 나누고 토론하면서 더 좋은 서비스를 만들어나가고 싶어서 많은 부분을 준비하고 있었다. 그런데 이런 나를 보고 누군가 이런 질문을 던졌다.
'PM이 너무 의욕적이면 팀원들이 부담스러워하지 않을까?'
생각해보지 못한 부분이었다. 당연히 PM이 열심히 준비해가면 프로젝트 전체가 더 많은 준비 하에 진행될 수 있고, 더 완성도 높은 결과물을 만들 시간을 번다고 생각했다. 그런데 다시 고민해보니 이건 나 혼자 일요일에 고민한다고 될 일이 아니었다. 이번 프로젝트는 혼자 하는 게 아니라 팀 단위로 움직이는 것이었다. 그 뒤로 어떻게 해야 팀원들과 나의 온도를 맞출 수 있을까 고민했지만 별다른 해결책을 찾지 못했다. 프로젝트를 시작한 첫날, 팀원들에게 내 아이디어들을 말하고 의견을 묻고 싶었지만 섣불리 말이 나오지 않았다. 가뜩이나 다른 팀보다 인원수도 적었기에 기간 내에 구현할 수 있을지조차 불투명한 상황에서 컨셉을 새로 짜거나 독특한 아이디어를 내놓기가 괜스레 조심스러웠다. 그렇게 주저하다 기획 회의가 끝나버렸고, 기능적인 부분에 있어 기본적인 부분만을 논의한 채 이야기가 마무리되었다.
물론 이후에 프로젝트를 더 진행하면서 UX도 더 개선하고, 디자인도 개편하고, 성능적으로도 완성도 높은 서비스를 만들어나가려는 노력이 이어졌다. 그렇기에 처음 기획한 내용보다는 훨씬 마음에 드는 결과물이 나왔지만, 한편으로는 첫 회의때부터 충분한 기획이 이루어졌으면 또 다른, 더 개성있는 결과물이 나오지 않았을까 하는 아쉬움이 들기도 한다. 다음에 2차 프로젝트를 하게 되면 내가 가지고 있는 아이디어를 혼자서만 가지고 있기보다는 밖으로 조심스럽게 꺼내서 팀원들에게 의사를 물어보고, 피드백을 받으면서 토의하는 보다 능동적인 자세를 갖춘 팀원이 되고 싶다.
+ 👀 첫 회의에서 스스로에게 충격을 받은 덕분에(?) 정작 프로젝트가 시작되고 나서는 여러 부분에 능동적으로 관여하면서 많은 의견을 전했고, 바로 적용하는 과정을 거쳤다. 매주 미팅을 할 때마다 피드백을 적극적으로 수용해서 회의 방식이나 티켓 분배 등 여러 부분을 개선해나가려고 했다. 돌아보니 스스로의 문제점을 빠르게 인식하고 바로 개선해나가려고 한 점은 잘한 부분인 것 같다.
그럼에도, 잘한건
😎 언제든 준비된 자세로
위에서 말했듯 프로젝트를 시작하기 전부터 PM으로서 마음이 무거웠고, 잘 해낼 수 있을지에 대한 걱정이 많았다. 하지만 오히려 이런 성향 덕분에 우리 프로덕트에 대해 많이 조사하고, 또 꼼꼼히 고민해볼 수 있었다. 그 성과는 PM으로 발표해야 할 상황에서 여실히 드러났다. 팀을 꾸리고 처음으로 멘토님들과 플래닝 미팅을 진행하며 프로덕트에 대한 관점과 구현 계획에 대해 발표한 적이 있었다. 예상치 못한 발표에 당황하기도 했지만, 사전에 철저한 준비가 있었기에 생각해놓았던 부분을 가감없이 말할 수 있었다.
게다가 멘토님들께서 '첫 미팅에서 이렇게 잘 준비된 팀은 전체 기수를 통틀어 거의 없는데, 정말 잘하셨다' 라고 칭찬을 해주셔서 '나 PM으로서 잘하고 있구나!'라는 용기를 얻었던 것 같다.
발표 당일을 떠올려보면 구현만으로도 시간이 부족해서 시작 2분 전까지 PT 자료를 만들고 있었던 기억이 난다. 초반부터 마이크로하게 작업하고 실시간으로 리팩토링하며 꼼꼼하게 나아간 덕에 confilct는 나지 않았지만.. 시연 영상을 늦게 촬영하게 되어 발표 준비 시간이 턱없이 부족했다. PM으로서 마지막 발표 역시 나의 몫이었는데, 평소와 달리 준비되지 않은 상태에서 발표를 한다는 게 두려움으로 다가왔다.
하지만, 위에서 말했듯이 나는 언제든 달릴 준비가 되어 있는 PM이었다. 누군가가 물어봐주기만 한다면 당장에라도 튀어나가 설명할 수 있다고 자부하는! 긴장이 되기도 했지만 이미 머릿속에 담겨 있는, 우리 프로덕트에 대한 의견과 생각을 담담하게 풀어나갔다. 프로젝트 마감 당일이라 동기분들은 많이 피곤해보였으나.. 발표가 끝난 후에 멘토님들의 피드백을 집중적으로 받았다. 내 발표에는 유독 흥미로운 지점이 많다는 피드백이 기억에 남는다. (우리 팀의 Trello 티켓 달성률을 정리해서 수치로 성과를 전달한 점, 앞으로 구현하고 싶은 사항에 https로의 변경을 추가한 점 등..) 앞으로 어떤 프로젝트를 하더라도 내가 맡은 프로덕트에 대해 충분히 고민하고 잘 이해하고 있는 자세를 유지하는 게 중요하다는 점을 깨달았다. 어쩌면 창업 경험이 여기서 도움이 되었을지도?!
🔥 고민보다 GO
(구현 과정에서) 너무 깊이 생각하지 않았다는 점 역시 스스로를 칭찬해주고 싶다.
이게 좋은 건가? 싶을 수도 있지만 내겐 이 '깊이 생각하는 버릇'이 독이 될 때가 있었다. 때때로 이러한 경향은 완벽주의와도 맞물려서 할 일을 끝까지 해내지 못하는 문제로 이어지기도 했다. 그런데 이번 프로젝트는 특히나 적은 인원으로 많은 기능을 만들어야 했기에 다른 생각은 잠시 접어두고 '구현하기로 한 기능을 잘 만들 것'. 그 한 가지 사실에만 집중했다. 그렇게 하루하루 해야 할 일을 꼼꼼히 해내다 보니 어느덧 완성된 서비스가 되어있었고, 매일 일정 시간을 꾸준히 투자하다 보면 그게 쌓여서 성장하는구나, 라는 걸 느꼈다. 앞으로도 내가 어떠한 일을 할 수 있다고 판단되면 더 이상의 불필요한 고민은 지양하고 바로 시도해보는 게 좋을 것 같다는 깨달음을 얻었다.
마무리
미친듯한 의욕으로 늘 체력보다 오버해서 토해내듯 일했던 창업과 달리, 개발 프로젝트는 일정 내에 반드시 정해진 만큼을 수행해내야 한다는 점이 중요했다. 나뿐만 아니라 팀원들의 체력 안배도 고려해야 했다. 내가 너무 의욕적으로 나가면 같은 팀원들이 허덕일 수 있었고, 그렇다고 너무 소극적으로 임하면 완성도 높은 결과물을 만들어내기 어려웠다. 팀에 폐를 안끼치려고 하다 보니 여러 우선순위 간의 밸런스를 조절하기가 다소 어렵다고 느꼈다. 반면에 이런 지점을 고려하다보니 항상 스스로를 한계로 몰아넣고는 했던 성향에 반해 자연스럽게 일정이나 업무 강도를 체력에 맞췄던 것 같다. 결국 나를 타인처럼 소중히 대해야 한다는 깨달음이 있었던 팀 프로젝트였다.
'Study > Wecode' 카테고리의 다른 글
| [회고📓] 우당탕탕 💨 2차 프로젝트를 돌아보며 (0) | 2023.04.14 |
|---|---|
| [회고📓] 부트캠프 1개월차, 하얗게 불태워진 나 (1) | 2023.03.19 |
| [회고 📓] 부트캠프 2주차 🫂 든든한 동지를 얻다! (0) | 2023.03.01 |
| [회고 📓] 부트캠프 1주차 🐥 나.. 잘하고 있는걸까? (3) | 2023.02.19 |
| [Git] 초심자를 위한 Git Github 정복하기 ⛳ (0) | 2023.02.17 |