위코드에서 첫 프로젝트를 시작했다 이에 대한 내용을 정리해볼까 한다.
0. 회고내용에 앞서...
회고의 내용은 backend를 희망하고 배우고 있는 글쓴이의 주관적인 기준으로 작성하였으며 backend에 대한 관점과 의견이 다소 많이 녹아져 있으나 최대한 객관적으로 표현하고자 하였고 frontend 분들의 노력이 함께했기에 진행이 가능한 프로젝트였다.
코딩을 잘하는 코딩천재들이 분명 많기때문에 협업에 나이스한 개발자를 추구하는 사람의 자세를 가지려는 마음가짐을 기준으로 본 회고를 작성했다.
1. 프로젝트 개요
1-1. 기간 및 인원
- 기간 : 23년 2월6일 ~ 2월 17일
- 인원 : 프론트 3명 / 백 3명
- 구성원의 역할 : 구성원 중 2명의 PM(Product Manager, Project Mnager)과 4명의 팀원으로
프로젝트 진행
1-2. 프로젝트에 사용된 기술스택
- Front-End : React.js, sass, JavaScript, html, css
- Back-End : Node.js, Express, JSON Web TOKEN, Bcrypt, My SQL, uuid
- Common : RESTful API, Git, Github, Trello, Slack, Notion, Postman
2.프로젝트 컨텐츠 소개
2-1. 컨텐츠 내용
- 이번 프로젝트는 '배민문방구'를 모티브로 삼아 만들게 되었다.
- 프로젝트 명은
garbage collector이다. 이름을 이렇게 짓게 된 이유는 요즈음 시대에 살고 있는 사람들에게쓸모없는 선물이라는 트렌드를 넘어서 선물에 대한 부담스러울 수 있는 것을 무겁지 않고 재미로 승화시키기 위한소비에 대한 가치를 하나의 놀이로 생각하고자 하는 사람들을 위해 소비할 수 있는 컨텐츠를 하나의 웹으로 통합해보고 싶었다. - 웹페이지의 브랜드 이름은 프로젝트명으로 하게되면 다소 불쾌함을 줄 수 있었기 때문에 '풉'이라는 웃음을 제공할 수 있기 하기위한 단어를 사용하게 됐다.
- 판매제품 : 엔터키 쿠션(쿠션인데 usb를 연결하면 엔터역할을 할 수 있는 웃긴 쿠션),
짚신, 슬픈개구리 모형의 휴지케이스, 모아이석상 모형의 휴지케이스, 모자이크 모형의 선글라스 기타 등등..
⬆️ 이번 프로젝트를 통해서 만들게 된 제품군들인데 배민문방구의 성격과 비슷하게 아이템들을 선정하고 그에 맞는 위트있는 카피를 만들어서 사용해 보았다.
물론, 상업적으로 이용하거나 기타 어떠한 수익활동을 하게되면 저작권이나 기타 문제가 발생할 수 있어 개발의 클론프로젝트로 만든 것이기 때문에 상업적으로 이용하지 않을것이다.
3. 팀원들과의 협업
3-1 협업에 사용된 내용
A. DSM(Daily Standing Meeting)
B. Notion
C. Trello
3-1-1 Daily Standing Meeting (with. Notion)
매일 30분 정도를 프로젝트 팀원들과 진행했다.
팀원들과 매일매일 전날에 한 일, 오늘 해야할 일, block이 걸린일, 추가적으로 공유할 일 들에 대해서 Notion을 사용했다. 미팅은 간결하고 임팩트있게(?) 진행하기 위해서 내용에 대한 꾸밈을 최소화로 진행했으며 원활한 커뮤니케이션이 될 수 있도록 노력했다.
⬆️ 팀원들과 공유했던 DSM일부 내용 발췌
3-1-2 Trello
이번 프로젝트를 진행하면서 알게된 schedule tool이다.
개발영역에서도 스프린트라는 개념을 활용하는데 스프린트에 대한 내용은 다음에 간략하게 다른 포스팅으로 설명하는 시간을 가져야겠다.
각 티켓이라는 할 일에 대해서 스케쥴을 관리하는데 프로젝트별로 성격에 맞게 made할 수 있다.
⬆️팀원들과 공유했던 Trello일부 내용 발췌
4. 구현기능
4-1. 총 구현기능
- 메인 페이지
- 제품 상세 페이지(랜더링 페이지)
- 회원가입/로그인
- 상품 검색 조회
- 장바구니
- 주문
- 결제
여기서 나는 회원가입, 로그인, 상품 검색 조회 기능을 담당했다.
이렇게 나의 할당을 선택하고 배당받았던 이유는 비전공자로 개발자를 준비하는 나에게 있어서 이전의 기능들을 먼저 잘 이해하고 복기하며 기능에 대해서 조금 더 심화(?)해보고 싶었다.
내가 만든 기능에 대한 설명과 이해
4-2. 회원가입 기능
회원가입을 위한 유저 필요정보는 email,password(확인까지),name,phone-number,birth-day 다.
회원가입 유저에게 ID와 Email을 모두 요구하기에는 피로감을 줄 수 있다고 생각했기때문에 ID를 요구하지 않고 Email을 활용할 수 있도록 했다.
이전에는 사용해보지 않았던 '정규표현식'을 활용하였다. 회원가입 기능에서 사용한 정규표현식은 프로젝트의 특성상 각 항목에 맞도록 설정해 두었다.
4-2-1 Email
Email은 중복이 되지 않아야 하고 주소 형식에 맞도록 @와 .이 의무적으로 사용되어야 가입이 될 수 있도록 했다.
4-2-2. password
password는 최소한의 불편사항을 해소하기 위해 대/소문자 구분없이 문자와 숫자가 혼용되도록 하고 8자 이상 20자 이하로 설정했다. 또한 보안을 위해서 회원가입시 DB에 유저에 대한 비밀번호가 암호화되어 저장될 수 있도록 bycrypt를 사용하여 보안을 한층 강화시킬 수 있도록 했다.
4-2-3. Phone-number
Phone-number는 회원가입을 하는 유저에게 포인트를 지급하기 위해서 중복으로 가입할 수 있는 것을 방지하도록 했다. Email뿐만 아니라 폰번호로도 중복에 대한 방지를 한 것은 한사람이 여러 이메일을 가질 수 있기때문에 이에 대한 중복을 방지하기 위한 두번째 Lock 장치로 사용했다.
4-2-4. birthday
생년월일은 차후 방향성에서 생일의 정보를 통하여 포인트를 지급할 수 있도록 하기 위해 생년월일의 정규식(총 8자 oooooooo)으로 받도록 했다.
대신 1900년대 부터 받도록 하고, 1월~12월, 1일부터 31일 까지 정보를 입력할 수 있도록 했다.
front측에서 생년월일에 대한 정보를 입력을 받을때 oooo/oo/oo, oooo.oo.oo, oooo-oo-oo 방식으로 작성하게 하는것이 리소스라는 의견이 있어 이 의견을 backend측에서는 수용할 수 있는 부분이었기 때문에 순사 8자로 작성될 수 있도록 했다.
⬆️ 회원가입 페이지
4-3. 로그인 기능
로그인은 타 웹과 크게 다르지 않게 작동하도록 구현했다.
4-3-1 Worng password
비밀번호가 다를때는 DB에 암호화되어 있는 값이 다르면 잘못된 비밀번호라는 값을 전달 할 수 있도록 backend에서 기능을 포함시켜 놓았다.
4-3-2 Token
로그인시 Token을 발행하도록 jwt을 사용하였으며 PC에 제3자가 이용할 수 있는 위험을 어느정도 예방할 수 있도록 Token을 발행로그인시 해당 유저가 로그인 상태로 지속되어 웹에 활동할 수 있는 시간을 정해주어 24시간으로 token이 expire될 수 있도록 설정해놓았다.(expire의 시간 설정에 대한 정보는 open되는 것 보다는 서비스적인 부분에 있어서 공개하지 않는것이 좀 더 메리트 있기때문에 차후에는 환경변수를 이용하여 사용하는 것이 좋을것 같다는 생각을 했다.)
4-3-2-1 Check Valid Token
jwt를 통해서 발급한 토큰이 차후에 장바구니, 주문서, 결제의 기능에 해당 유저가 이용하기 위한 서비스인것을 인지하기 위해서 로그인기능때 토큰 유효성 검사기능도 같이 만들어 놓았다.
이때 payload에 user_id를 통하여 토큰에 대한 유효성 검사를 할 수 있도록 해놓았는데 이는 DB에서 table column에 id가 보안상으로 가장 효율적인 매칭 column이 될 수 있기때문에 user_id를 통해서 검사를 진행할 수 있도록 소스코드를 작성했다.
4-4. 상품검색 조회 기능
웹 페이지 접속하고나면 main 페이지로 웹의 첫 화면이 나타난다.
이때 많은 상품이 존재하는 상황에서 유저가 타겟팅하고있는 니즈의 제품이 있다면 그 제품에 대한 keyword로 제품을 찾아볼 수 있게끔 하는 기능이 필요했다.
backend에서 검색조회 기능에 대한 API와 frontend에서의 검색조회 화면 구현에 대해서는 main페이지라는 큰틀의 기능이 있었기 때문에 구현하는데에 있어서 큰 어려움은 없었다. main페이지에 대한 내용을 reference하여 만들 수 있었기 때문이었다.
5. 프로젝트를 하면서..
배운점
- 이전의 일과는 완전히 다른 직무로 액션을 취해본 거에 대해서 새로운 일에 대한 재미와 방향성에 대하여 생각해 볼 수 있었다. 그리고 배운것에 대해서 앞으로 어떻게 써먹어야 하는지에 대해서 느낄 수 있었다. 배울때는 "그래서 이걸 앞으로 어떻게 써먹어야 하는거고 뭘 어떻게 해야하는건데?"라고 생각했었다면 이번 프로젝트를 통해서 "아, 이게 이런식으로 사용하는거구나.." 라는 점을 배울 수 있었다.
협업에 대해서는 이전부터 강조하던 것이었는데 그래도 나름 회사생활을 10년 가까이 하면서 타 부서들과 협업에서 리더를 했었던 경험이 있었기 때문에 부드럽고 단단하게PM(Project Manager)로서 완벽하진 않지만 그래도 좋은 경험이 되었다는 생각을 했다. 배움과, 가르침이 많이 필요하긴 하지만 개발영역에 있어서 첫 시도로는 마냥 비관적이지만은 않았던 경험이었다고 생각한다.(당연히 혼자만 잘한것이 아닌 프로젝트 팀원들도 팔로우가 됐었기 때문이다.) 함께하는 사람들과 호흡에 대한 리듬이 중요하다는것을 알 수 있었다. 나름 우리 프로젝트를 진행할때에 구현시키고고자 하는 기능들에 대해 담당자들이 생기면 그 담당자들끼리 어느 부분을 먼저 진행해서 서로의 호흡을 맞추기로 하는 등이 예시로 들 수 있다.
배워야할 점
-
개발적인 부분에서는 팀원들과 협업을 함에 있어서 처음해보는 것이었지만
asile한 개발 프로젝트를 하는데 있어서 부족함이 있었다. Frontend와 backend에서 서로 맞춰야 할 컨벤션, 그리고 내가 속해있는 backend에서의 컨벤션도 나름 첫 도전에서 '시작이 나쁘지 않다.'라고 생각했는데 개선해야 할 점이 한두개가 아니었다.(DB 모델링에서 고려하지 못한 table과 table의 column들, 프론트와 백에서 통신을 해야할때 맞춰놔야 하는 변수와 상수의 이름들 등등..) -
나는 backend로서의 입장으로 개발을 시작하긴 했고 frontend의 코드를 많이 알지 못했기 때문에 통신을 하는데 있어서 소통의 아쉬움이 있었다. 각자의 용어에 따른 소통의 어려움이 있었는데 이부분은 분명 나도 성장하면서 나아져야 하는 부분이라고 인지하고 있기 때문에 frontend 영역의 공부도 병행해서 나아가야 하는 부분이 있다면 뒤로 미루지 말고 함께 하는 방향성을 찾아보아야 겠다.
마무리..
이런 회고의 글도 나의 성장을 위해서 정성스럽게(?) 써본적이 얼마나 있었는가를 생각하게 됐다. 그리고 이 회고의 글도 잘 쓰고 싶었고 잘 하고 싶었는데 뒤돌아 보았을때 분명 허술했고 부족했던 것들이 보이는 회고의 글이 될 지도 모르겠다. 하지만 가장 중요한건 내가 했었던 것들이 무엇이고 무엇을 느꼈고 앞으로 무엇을 해야할지에 대한 고민을 했으며 다시 실행할 의지가 담겨있다는 것이다. 모든 부분에서도 작용하겠지만 개발에서도 역시 중요한건 꺾이지 않는 마음.
간단한 프로젝트 시연영상
