1차 프로젝트 후기

커피 내리는 그냥 사람·2021년 3월 26일

위코드 1차 프로젝트

목록 보기

13/13

위코드 한 달 차 후기를 쓴지도 며칠 되지 않아 바로 1차 프로젝트 후기를 쓴다. 정해진 조와 구현 해야 할 홈페이지에 운명을 걸고 시작한 지난 월요일의 기억이 아직 생생한데 벌써 후기를 쓴다 생각하니 만감이 교차한다. 돌이켜보면 분명 잘 한 것도 있고, 아쉬운 것도, 즐거웠던 것도, 힘든 것도 있지만 그 모든 것이 나의 자산이 되었다 생각하니 그저 뿌듯할 뿐이다.

1. 어떤 프로젝트였나?

개요

프론트엔드 3명, 백엔드 2명 총 5명과 함께 '배민문방구'를 클론코딩했다. 팀 이름은 추후 이력서에 쓰일 것을 대비하여 진지하게 짓자는 의견이 다수라 '배민-스토어'라고 짓고 시작했다.

덕분에 노잼 소리를 굉장히 많이 들은 것 같다.

배민문방구 홈페이지에 대한 구조 분석을 한 후 어느 부분은 구현하고 어느 부분은 수정이 필요한지 논의하여 실제 구현까지 완료했다. 배민 문방구 특성은 아주 간편한 구조의 커머스였으며 로그인 및 회원가입, 장바구니, 위시리스트, 리뷰 등 주요 기능과 더불어 여러 카테고리들의 물건이 메인에서 각기 다른 분류(잘나가요, 새로 나왔어요...)로 뿌려지는게 특징이었다.
예 ) 물건에 마우스 호버를 했을 때 모든 물건에 장바구니, 좋아요가 뜨게 기능 추가
프론트엔드가 사용자 입장에서 보여지는 화면을 구성했다면 백엔드는 초기세팅 - 모델링 - view 구성을 통해 실제 데이터가 프론트엔드 화면에서 어떻게 뿌려질지 서로 협의하에 작업을 진행했다.

진행 경과

1. 1~3일차 : 플래닝 미팅 및 모델링

팀원 선정 및 플래닝 미팅
트렐로 정리 -> 역할 분담 및 우선순위 선정
멘토님과 플래닝 미팅 : '내실 있는 프로젝트'
장고 초기 세팅
모델링하며 우선순위 결정(로그인, 회원가입, 주문, 장바구니 등 필수 구현부터 검색, 회원정보 변경 등 추가 기능 구현으로 나누기)
모델링 지속 컨펌 및 수정(2~3일차)

2. 4~6일차 1차 스프린트 완성 :

(views) 로그인/회원가입 완성 및 상품 상세정보

로그인 및 회원가입 역할 분담 후 브랜치 구성
완성 후 프론트 엔드 조인 -> 성공
상품상세정보 (상품 눌렀을 때 나오는 것) 입력 및 출력 시작
주말 이용하여 상품 상세 정보 띄우는 것도 프론트와 붙여 봄. -> 성공

3. 7~8일차 : 2차 스프린트 시작

(view) 장바구니, 찜하기 기능 구현 주로
1. 상품 상세 정보 띄우기 최종 점검 -> 성공
2. 장바구니, 찜하기 기능 구현 시작
3. 완성 후 프론트와 맞춰보기 -> 성공 + 보완사항 수정

4. 9~10일차 : 2차 스프린트 완성 + 보완

(view) 메인화면 + 쿠폰 + csv자료 집어넣기
1. 메인화면에 출력되는 로직 구성 -> 성공
2. 쿠폰 적용하는 로직 구성 -> 추가구현으로 다음으로 넘김
3. csv 자료 제작 후 마지막 날에 자료 모두 넣고 키값, 데이터 에러 모두 점검

5. 11일차 : 최종 발표

백엔드 : 주요 로직 위주 설명 + 스크럼 방식 어떻게 진행 되었는지 설명

6. 리팩토리 사항

상품구매 후 리뷰 및 상품 후기 구현

구매 상품에 한하여 리뷰 및 상품후기를 등록할 수 있는 api 구축

더 많은 브랜치 활용하여 프론트엔드와 협업
검색 기능 api 구축
주문 시 주문을 관리할 수 있는 주문번호 기능 추가
마이페이지 구축

회원 정보 변경 api 추가
1:1 문의 게시판 api 추가
배송지 관리 api 추가

2. 프로젝트에서 사용된 기술?

1. 프로젝트 협업 기술 & Tool

스크럼 방식을 사용하였다. 스크럼 방식이란 간단히 말해 N개의 '스프린트'를 설정하여 그 스프린트마다 완성품을 내고 최종적으로 완성품을 merge하는 개념으로, 기존에 시작부터 완성품 하나의 단계가 아니다.
실제 우리 프로젝트에서는 백엔드, 프론트엔드가 각자 기능별로 맞춘 일정 정도의 브랜치가 완성되면 그 단위로 주 단위로 데이터가 원활히 맞춰지는지 확인하는 식으로 진행했다. 그리고 이 여러 완성품들을 마지막 전 날 하나의 완성품으로 merge했다.
스크럼 방식이 원활히 될 수 있도록 다양한 도구를 활용했다. 물론 너무 많은 유명한 도구들이 있었지만 우리 팀은 트렐로, 슬랙, 벨로그를 적극 활용했다.

트렐로를 사용해보니 팀원들의 업무 분담 및 업무 진도가 가시적으로 잘 드러나 있어 굉장히 편했다. 실제로 스탠딩 미팅 시 트렐로를 기준으로 팀원들의 역할 및 진도를 체크했고 그에 따라 스프린트 내 기간을 조정하고 스크럼을 할 수 있었다.
슬랙의 경우 채널을 만들어 파일, 토큰, ip등 빠르게 공유해야할 자료를 공유하기도 했고 상호 부재중일 때 긴급연락 수단 및 의견 공유의 장으로 쓰였다.
벨로그의 경우 단순히 블로그를 쓰는 것으로 그치는 것이 아니라 스탠딩 미팅, 그 날의 플로우를 모두 기록하여 정리하고 슬랙으로 공유하는 역할에 가장 걸맞는 도구였다.

위와 같은 도구들의 사용을 통해 명확한 공유만이 프론트/백엔드의 conflict를 방지하고 보다 효율적인 업무를 할 수 있게 해준다는 것을 느꼈다.

(내가 정리한 벨로그 캡쳐. 항상 일정이 끝난 후 10~11시 사이 공유)

2. 프로그래밍 기술 & Tool

크게 Django, MySQL, 포스트맨을 사용했다. 여기서 장고나 MySQL은 이미 많이 알고 사용해온 것이지만 포스트맨은 이번 프로젝트에서 조금 더 본격적으로 사용한 프로그램이었다.
포스트맨은 우체부라는 이름과 같이 데이터 송수신의 역할을 해주는 프로그램이다. 프론트엔드와 지속적으로 맞춰보면 가장 베스트한 결과를 낼 수 있지만 항상 맞춰볼 수 있는 것이 아니기 때문에, 프론트엔드에서 토큰과 json body를 이렇게 줬을 때 백엔드에서 어떻게 GET, POST 요청을 받을 것인지 확인한다. 실제로 다양한 사례를 넣어보고 요청 및 응답을 해봤고 이를 통해 디버깅도 할 수 있어서 굉장히 편하게 사용했다.

3. 협업의 경험?

초반 4주차까지는 모두 개인의 과제만 집중하고 모르는 것만 공유하는 정도의 시간이었다면 지난 2주는 진정한 '원팀' 플레이 시간이었다. 물론 팀플 자체가 낯선 것은 아니었다. 대학 시절 매 학기마다 팀플이 없는 과목은 없었고 그 때마다 좋은 성과도 안 좋은 성과도 함께 경험했다. 하지만 명확한 것은 대학 팀플과 다르다는 것이다.

처음에는 협업이라는 것 자체가 조금 걱정이 되긴 했다. 누군가는 혹은 내가 의도치않게 프리라이딩을 할 수도 있고 인간관계가 엮이는 것이다 보니 잘 되는 것도 있지만 잘못 될 경우도 많이 있다 생각했기 때문이다. 하지만 우려도 잠시, 일단 프리라이딩 같은 건 있을 수 없는 일이었다. 워낙 프로젝트 자체가 크게 느껴지다 보니 업무 분장이 안 될 수가 없고 내가 맡은 것을 책임지고 하지 못 하면 기능 구현이 안 되기 때문에 일어날 수가 없었다. 덕분에 책임감있게 내가 맡은 바를 수행할 수 있어서 좋았다.

뿐만 아니라 인간관계도 걱정한 것과 달리 너무 좋았다. 모두 서로 양보했고 심지어 점심 저녁 메뉴 고를 때도 서로 생각해주며 고르고 선정해줄 정도로 좋았다. 팀 케미스트리가 잘 맞아서 그런지 협업은 재밌는 경험을 주었다.

협업을 통해 빛났던 순간이 두 번 있었는데 한 번은 프론트엔드와 첫 송수신을 할 때였고 두 번째는 같은 백엔드 동기분에게 많은 도움을 받았을 때였다. 상품상세정보 입력이 끝나고 상품상세정보 출력을 앞두고 키값을 맞추는데 그 긴장감은 이루 말할 수가 없었고, 그 정보들이 모두 뿌려질 때 쾌감은 더 즐거웠다. 이 맛에 개발을 하는구나 싶을 정도였다. 동기분의 도움을 받은 것은 내가 모르는 부분이 많아서였는데, 코드 한 줄 한 줄을 치는데도 어떻게 생각을 해야하고 어떤 방식으로 로직을 접근해야하는지 하나하나 친절하게 알려주신 덕에 나중에는 좋은 코드를 비슷하게 따라서 배울 수 있는 계기가 되었다. 이 모든 것들은 혼자서는 절대 할 수 없던 정말 값진 경험이었다.

4. 프로젝트 중 나의 역할?

1. 팀 내 역할 : 정리 담당

무슨 정리인가? 그냥 먹은거 치우고 하는 그런 정리가 아니라 '일지' 관리 역할을 했다. 처음부터 정하고 시작한 것은 아니지만 추후 후기 작성, 2차 프로젝트를 위해서 어떻게 시간이 흘러갔는지를 정리하고자 하는 마음에서 쓰기 시작했다. 프로젝트 마지막 날까지 작성했으며 주로 스탠딩 미팅 결과, 그 날 한 일, 멘토님 리뷰, 내일 할 일에 대해서 슬랙을 통해 공유했다.

2. 기술적 역할 : 브랜치 기준

물론 아래서 설명을 더 할 예정이지만 나는 모델링, 로그인, 찜하기, 쿠폰 , 데이터CSV 파일 만들기 기능을 담당했다. 모델링에서는 같은 팀원들과 논의하여 홈페이지를 보다 효과적으로 구성 단계를 뜯어보며 계획하였고, 로그인, 찜하기, 쿠폰 기능에서는 각 기능마다 GET,POST 방식에 의거하여 어떤 장고 기술들이 필요한지 적절하게 사용하면서 만들었다. 마지막으로 데이터 CSV 파일을 만들어 홈페이지에 올라갈 실제 데이터 및 사진 자료를 구성했다.

물론 내가 맡은 브랜치 중에 사용되지 못한 추가구현 브랜치도 있었고 장바구니, 주문처럼 아주 중요한 브랜치아닌 브랜치도 있었다. 하지만 난이도나 중요도에 상관없이 내가 맡은 바에 최선을 다해 구현하려고 노력했고 실제로 결과가 모두 나와서 팀에 작게나마 기여할 수 있었다.

5. (백엔드) 실제 진행한 프로젝트 및 결과

1. 초기세팅 및 모델링

초기 세팅의 경우 위스타그램 때와 마찬가지로 진행 되었고 이후 모델링을 하였다.

모델링은 크게 3가지로 User, Order, Product로 구상했으며 각 관계에서 중요한 부분에 대해서는 unique_together, 등을 이용해서 관계를 명확히 했다.

<많이 고민한 부분>
1. product 부분을 굉장히 많이 고민했었다.

카테고리 > 서브 카테고리 (+ 옵션) > 물건
즉 서브 카테고리마다 옵션을 물고 있는 형태, 서브 카테고리에 맞게 옵션이 지급되어 물건에 옵션이 붙는 형태가 아님.
중계 테이블 통해서 서브 카테고리 내용까지 모두 파악하여 중간에 굳이 거치지 않고 바로 옵션을 알 수 있는 모델링. 이 부분이 제일 어려웠다.

주문 파트에서도 많이 고민했다.

만일 카트에 담긴 상품이 여러 개인데 하나만 사고 싶다면? 주문 상태가 변경되는 것을 어떻게 알 수 있을까? 이런 고민 끝에 주문 상태 테이블을 만들어서 관리했다.
또한 주문은 실시간으로 그 상태가 변경되므로 created_at 등을 고려했다.

이후 모델링 한 것에 ManyToMany와 unique_together를 걸어주어 컬럼 간 관계를 명확히 해줬다.

2. 브랜치 관리

기능별로 브랜치를 구성했고 로그인 및 회원가입, 상품상세정보 입출력, 찜하기, 장바구니 및 구매, 메인페이지 및 카테고리 구분 출력, 쿠폰, 데코레이터로 다양하게 브랜치를 활용했다.

6. 기록하고 싶은 코드(치열하게 고민한 코드)

1. get_or_create

정말 많은 코드들이 있었지만 그 중 가장 배우고 사용하면서 뿌듯한 코드가 이 코드였다.

브랜치 중 '찜하기'를 구현하였는데 찜하기 시 중요한 것이 같은 물건을 담을 때 물건의 로우가 뜨는 것이 아니라 상품 개수만 올라가야 했다. 따라서 “특정 요소는 유니크하게 묶이고 다른 값은 계속 올라간다"라는 전제의 ‘로직’을 구현해야했다.

여기서 사용된 개념이 모델에서 unique_together와 뷰에서 get_or_create였다.

유니크 투게더는 주어진 데이터 베이스 테이블에 고유 필드에 대해 도일한 여러 행의 데이터가 있을 수 없게 튜플로 통제하는 것으로 예를 들면 위의 예제처럼 유저, 프로덕트, 프로덕트가 가진 옵션의 아이디가 하나로 묶여야 하는 것을 들 수 있다.

모델링을 해준 뒤 뷰에서 이를 바탕으로 get_or_create를 해주는데 말 그대로 데이터가 있으면 get으로 가져오고, 없으면 create 해준다는 뜻이다.

여기서는 로우가 만들어진다면 그대로 로우를 만들어주지만 로우가 이미 존재한다면 수량만 올려주는 코드를 구현한 것이다.

이 때 is_created를 사용해준 것은 언패킹의 목적도 있으며 실제 get_or_create를 판별해주는 역할도 할 수 있다.

save()의 경우는 데이터베이스의 내용에 직접 접근해서 값을 더했기 때문에 저장한다는 의미로 사용했다.

2. filter(__in)

치열하게 고민했던 두번째 사례로는, 필터를 사용한 리스트 언패킹이다.

유저에게 쿠폰을 등록해야하는 상황에서 서브 카테고리가 여러 개로 들어올 때, 즉 쿠폰1 이 신발, 양말, 덧신 등 하나만 있는게 아니라 [신발, 양말, 덧신] 이렇게 들어올 때는 어떻게 필터링해야할까? 이를 스택오버플로어 등 다양한 통로를 통해 찾아본 결과 다음과 같이 해결할 수 있었다.
필터에 name을 기준으로 __in 리스트를 언패킹하여 받으면 해결할 수 있다.
간단한 해결방법이었음에도 불구하고 실제로 알아냈을 때는 굉장히 쾌감이 있던 부분이었다.

7. 잘한 점, 아쉬운 점

프로젝트를 하면서 정말 만감이 교차한 순간이 한 두 번이 아니었다. 잘 되어서 기뻤던 적, 안 되어서 화가 난 적, 더 잘하고 싶은데 안 되어 아쉬운 적, 그 와중에 재밌었던 적 등 생각한다면 굉장히 많다. 그래도 정리하자면 다음과 같지 않을까 싶다.

1. 잘한 점 :

스프린트 당 목표와 각자의 역할 분담이 명확하여 방향성 있는 프로젝트가 진행되었다.
규칙적인 스탠딩 미팅과 트렐로 활용, 일지를 통해 진도체크와 장애 요인 파악이 원활히 되어 프론트엔드 & 백엔드 간 소통에 문제가 없었다.
트렐로 활용한 키값 공유와 같은 사소한 부분부터 프론트엔드도, 백엔드도 서로 코드에 대한 리뷰가 잘 되어 맞춰보는데 비교적 원활했다.

2. 아쉬운 점 :

각 기능별 브랜치 처음엔 기능 잘 나눴는데, 프론트와 맞춰봐야 할 일이 많아지니까 브랜치 하나에서 여러 기능을 작업하게 돼서 이건 좀 아쉬웠다. 다음에는 브랜치 하나 당 소 기능 하나로 나누는, 조금 더 세분화된 작업이 필요하다.
카테고리와 서브 카테고리에 유니크를 걸어서 하나의 서브 카테고리에 여러 개의 카테고리가 걸리지 않는다.(리빙의 핸드폰 엑세서리와 ㅋㅋㅋ에디션의 핸드폰 엑세서리와 같은 예시)
모델링 시 데이터 길이를 넉넉하게 잡았어야 했다.(상품 상세 정보에 길이 등)
추가 기능 구현에 대한 계획이 많았는데 구현이 다 되지 못한 점은 아쉽다.

마무리

프로젝트 시작 전엔 걱정이 앞섰다. 내 실력으로 결과물을 낼 수 있을지, 사람들과 온전히 잘 지낼 수 있을지 말이다. 하지만 실제로 프로젝트를 하다 보니 내가 잘 하는 영역이 분명히 존재했고 그 덕에 팀원들에게 기여할 수 있는 점이 있다는 것도 알 수 있었다. 예를 들어 위에서 언급한 벨로그 정리라던가 마지막 중간, 최종 발표 때 자료 정리 및 배포를 통해 팀원들이 현재 상황을 더 명확히 이해하고 자신감 있게 해결해나갈 수 있게 도와줬던 경험이 그런 확신을 줬다.
이 뿐만 아니라 내가 PM 이라면? 내가 ~라면? 과 같이 상대 편의 입장에서 생각하고, 들어주고, 공감하며 업무를 진행하며 책임감을 가지려는 태도도 팀의 기여도를 높이는데 한 몫했다고 본다. 이런 마인드가 있었기에 바쁜 와중에도 정리를 해가며 공유할 수 있었지 않은가 싶다.
이런 노력들을 바탕으로 협업을 해보니 앞서 걱정한 모든 것들이 다 씻겨져 내려갔고 오히려 즐거운 경험으로 남았다. 물론 결과가 좋아서 더 그렇게 기억될 수도 있겠지만 혼자보다는 함께 결과물을 내는 것이 얼마나 즐겁고 소중한 경험인지 몸소 깨닫는 계기가 되었다.
끝으로 도움을 많이 받은 동기들 덕에 프로젝트가 무사히 잘 마쳐져서 감사하다. 좋은 질문을 만들어서 물어보기 위해 치열하게 노력하게 만들어준 원동력이기도 했고 내게서 좋은 역량을 끌어올려준 역할을 해주기도 했기 때문이다. 이 회고록을 비로소 더욱 감사하단 말을 전하고 싶다.
정말 마지막으로, 이번에 많이 배운 내용을 2차 프로젝트 때 공유하고 함께 즐겁게 공부하고 싶다. 이번에 같이 하신 분 덕분에 배운게 너무 많아서 감사하고 다음 프로젝트 때도 쓰고 싶고 다른 동기들에게도 알려주고 싶다.

어떤 개발자가 되고 싶은지에 대한 스스로의 질문을 던지고 답하며 마무리한다면, 지금처럼 책임감을 가지고 자기 자리에서 묵묵히 동료에게 기여하는 등대 같은 개발자가 되고 싶다. 또한 배운 것을 나만 갖고 있는 것이 아니라 모두에게 함께 어떤 수단으로도 공유하고 싶은 그런 개발자가 되고 싶다.