[프로젝트 회고] Alcohol-Friday

Alcohol-Friday (AF) 프로젝트 회고

AF 프로젝트는 멋쟁이사자처럼 부트캠프(백엔드 스쿨)인 테킷에서 진행한 2차 프로젝트 겸 사이드 프로젝트이다.

 

프로젝트 소개

팀 구성

BE : 6명

FE : 2명 (외부 인원 섭외)

Design : 1명 (외부 인원 섭외)

으로 나는 BE에 참여함과 동시에 프로젝트에 팀장을 맡았다.

 

부트캠프 내에서 기본적으로는 프론트엔드와 디자인 등의 작업을 학생들이 모두 해야했으나

백엔드 개발자로써 더 좋은 방향으로 효율적인 성장을 하기 위해 수상을 포기하는 조건으로 외부 인원을 섭외하여 프로젝트를 함께 진행했다.

프로젝트 주제와 선정 이유

AF는 대한민국 전통주 시장의 점유율이 굉장히 낮은걸 해결을 하기 위한 프로젝트이다.

단순히 생각해서 내가 알고있는 우리나라의 전통주는 뭐가 있을까? 생각을 해보자

나는 여행가서 먹었던 동해, 서해, 니모메 정도 밖에 생각이 나지 않는다.

많은 사람들이 나와 크게 다르지 않을거다.

우리나라의 전통주는 굉장히 많은 종류가 있지만 일반적으로 소비자들이 접근을 하는건 쉽지 않다.

접근성이 좋지 않은 이유가 뭘까 “농림축산식품부 주류 시장 트렌드 보고서”와 “농민신문”, 유튜브, 구글 등을 찾아가면서 몇가지 결론을 냈다.

 

1. 전통주 제조업체들의 기업의 규모가 작다.

2. 탁주나 막걸리의 경우 유통기한이 문제가 된다.

3. 일반 소비자가 접근하기가 쉽지 않다 (온라인 쇼핑몰에서 구매 가능하지만..)

4. 동네 점포에서 구매 판매를 하지 않는다.. (소규모 제조업체에서는 소상공인으로의 유통망이 없음)

 

크게 4가지를 문제로 잡았고 이를 해결하기 위한 방법을 구상했다.

 

프로젝트 방향성

프로젝트를 통해서 개선하고 싶은 사항들은 문제로 꼽았던 4가지를 위주로 개선을 하고자 했다.

이를 어떻게 할 것인가 팀원들과 함께 고민을 시작했고 생각보다는 쉽게 서비스가 떠올랐다.

 

전제

우리는 가상의 유통회사가 되어 제조업체로 부터 주류를 받아 창고에 보관을 하며 배송 서비스를 제공한다.. (쿠팡의 로켓 배송과 유사)

 

 

서비스

1. 소비자들이 구매할 수 있는 전통주 온라인 스토어

2. 소상공인이(매장) 전통주를 도매가에 구매할 수 있는 온라인 스토어

3. 매장에서 취급하는 주류 정보를 제공하는 지도 서비스 (추후 매장으로의 전통주 픽업 서비스 제공)

 

크게 3가지 기능을 제공하는 것으로 프로젝트 방향성이 맞춰졌다.

 

 

프로젝트 기대 효과

1. 제조사와 소상공인 간의 유통망 확보

2. 일반 소비자의 전통주 접근성 향상

3. 자체 창고를 운영을 통해 매장에서의 소규모 발주 서비스 이용 가능

4. 창고 운영을 통한 재고 품질 관리 가능

 

디자인

 

기술 스택

Back End

Front End

Infra

전체 아키텍쳐

ERD

아래 DB는 최종적으로 사용하게 된 테이블들인데

생각보다 규모가 커졌고 생각보다 문제가 많았다 하하..

프로젝트 기능 목록

회원 기능

• 카카오 로그인
• 자동 회원 가입
• 개인 정보 수정
• 성인 인증
• 구매 상품 리뷰 관리
• 1:1 문의
• 배송지 관리
• 스토어 구매 내역 (조회, 수정, 환불, 취소)
  
  
  

매장 기능

• 전통주 취급 매장 지도 조회
• 매장 전용 폐쇄몰 (소상공인 온라인 스토어)
• 매장 제품 재고 관리
• 매장 정보 수정
  
  
  

스토어 기능

• 상품 구매
• 장바구니
  
  
  

관리자 페이지

프로젝트 결과물 (이미지)

스웨거

전통주 취급 매장 지도 서비스

온라인 스토어 상세 페이지

온라인 스토어 상품 목록

소상공인 폐쇄몰

 

프로젝트 회고

- 이번 프로젝트를 진행하고 마무리 하는 과정에서 많은 부분들을 경험했고 성장한 느낌이 들었지만 부족한 부분이나 힘들었던 일들도 많았다.

 

Keep

Mockito를 이용한 단위 테스트

이번 프로젝트에서 단위 테스트를 진행할 때 first 원칙을 고려하여 Mockito를 적용하여 테스트를 진행했다.

first 원칙에 대해서는 아래와 같다

 

- Fast: 유닛 테스트는 빨라야 한다.

- Isolated: 다른 테스트에 종속적인 테스트는 절대로 작성하지 않는다.

- Repeatable: 테스트는 실행할 때마다 같은 결과를 만들어야 한다.

- Self-validating: 테스트는 스스로 결과물이 옳은지 그른지 판단할 수 있어야 한다.

- Timely: 유닛 테스트는 프로덕션 코드가 테스트를 성공하기 직전에 구성되어야 한다. 테스트 드리븐 개발(TDD) 방법론에 적합한 원칙이지만 실제로 적용되지 않는 경우도 있다.

 

Mockito를 사용하면 DB에 의존적이지 않고 데이터가 있다 ~ 라는 가정을 두고 테스트를 진행하게 되는데 단위테스트를 어딘가에 의존하지 않고 진행을 한다는게 좋았고 테스트 코드에 대한 이해도도 많이 향상되었다.

 

 

QueryDSL JPA

프로젝트를 기획할때 DB에서 외래키를 설정하지 않고 대부분의 삭제를 논리적 삭제로 진행을 했다.

그에 따라 조회 조건을 주는게 까다로워 QueryDSL을 통해서 쿼리를 동적으로 생성을 했다.

사실 이전까지 QueryDSL을 많이 다뤄보지를 않았고 이해도도 많이 부족했는데

이번 프로젝트를 통해서 삽질(?)을 하다보니 조금은 자신감이 붙었다고 해도 과언이 아닌 것 같다.

 

[QueryDSL JPA 게시글]

1. QueryDSL JPA 1:N 관계에서 N의 조건 추가

2. QueryDSL JPA로 생성된지 일정시간이 지난 데이터 가져오기

3. QueryDSL LIKE 삽질

 

자바 백엔드 개발자에게 Query를 객체지향 관점에서 작성을 할 수 있다는게 좋았고 앞으로도 왠만해서는 연습을 위해 QueryDSL을 사용할 생각이다.

 

 

인프라 경험

프로젝트에서 사실 인프라를 내가 구성했다고 할 수는 없을 것 같다.

기술적인 부분에 대해서 나보다 잘 알고 있는 팀원이 있어 이 부분에 대해서는 모든 권한을 위임했고

해당 인원이 인프라에 대해 많은 부분을 구축을 해줬다.

Github Actions을 통한 CI/CD

Docker와 NCP를 이용한 배포 등..

 

 

Jira와 Confluence 그리고 Discord

프로젝트의 일정관리와 문서작업을 우리는 ATLASSIAN의 Jira와 Confluence를 사용해서 관리를 했다.

Jira는 Github와 연동하여 Jira의 이슈번호를 통해 git의 커밋컨벤션을 만들었고 이는 일정과 Todo를 관리하는데 굉장히 편했다.

 

Confluence에서는 기획에 대한 문서정리와 개발에 필요한 설정에 대한 문서 등 프로젝트에 필요한 문서들을 모두 모아 관리를 하여 팀원들끼리 상시로 공유가 되도록 관리를 했다.

 

Discord는 소통의 중심지였다.

온라인으로 진행되는 프로젝트인 만큼 서로간의 소통이 굉장히 중요했고 나는 대화를 할 때 제스처를 굉장히 많이 사용하는데 이를 캠을 통해 이야기를 했기에 내가 하고자 하는 의사 표현이 온라인이였지만 나름 잘 되었다.

 

채팅 채널을 우리에게 맞게 생성하여 관리를 했고 이 중에서도 “질문과소통” 은 정말 좋은 채널이였다.

질문과소통은 혼자서 개발하는 새벽 시간이나 집중 개발 시간 외에 문제를 맞닥들이거나 궁금한 부분이 있을 때 사용하는 채널로 게시물 형태로 질문을 만들고 답변을 받는 채널이였다.

 

코드 리뷰

기능 구현이 완료 되었을 때 dev 브런치로 pr을 올리고 merge를 하기 위해서는 각 파트별 개발자들의 승인이 필요하도록 git을 설정했다.

개발자들은 생성된 commit들을 확인하여 코드 리뷰를 진행하게 했고

서로간의 피어리뷰를 통해 미처 확인하지 못한 불필요한 코드나 오타등을 관리할 수 있었고

누군가 나의 코드를 리뷰한다는 행위 자체에 거부감이 사라지는 좋은 경험이 되었다.

 

소통과 협업

이번 프로젝트에서는 백엔드 개발자만이 아닌 프론트엔드, 디자인 인원들과 협업을 하며 문제가 없도록 소통을 하기 위해 매일 가벼운 스크럼 회의를 진행했다.

9명의 팀 구성이 적다면 적을 수도 있지만 팀장으로써 모든 파트와 소통을 하고 프로젝트를 진행함에 있어서 어떻게 커뮤니케이션을 해야하는지 알 수 있는 좋은 기회였고

나의 부족한 부분은 잘하는 사람에게 위임을 한다는 것은 부끄러운 일이 아닌 더 나은 프로덕트와 더 좋은 성장을 위한 것이라는 것을 알았다.

이번 프로젝트에서 소통과 협업에 대한 부분이 더 나은 내일의 나를 만들어 준 경험이라고 생각한다.

 

 

Problem

부족한 기획과 문서

이번 프로젝트에서 기획의 중요성을 절실히 깨달았다.

프로젝트의 방향성을 잡고 최대한 사용자의 입장에서 기획을 진행했으나

프로젝트의 중반부 부터 부족한 부분들이 튀어나오기 시작했다..

 

생각은 했지만 문서화 시키지 않은 파트라던가 API 정의서의 부재 등

초기에 내 생각을 잘 전달을 했으니 팀원들이 알아서 잘 해줄 수 있다고 생각한게 문제의 요인이였던 것 같다.

(내 모든 생각을 전달하지도 않았을 뿐더러 중간중간 변경되는게 나비효과처럼 번져나갔다..)

 

 

테스트코드

다소 많은 인원들과 소통을 하고 코드 리뷰를 위해 pr을 보고 팀장으로써 진행도 체크나 그 밖의 일들을 처리하면서 프로젝트 내내 코딩을 쫒기면서 한 것 같다.

이로 인해서 내가 작성한 테스트코드의 질이 다소 떨어졌다고 생각을 한다.

더 많은 경우의 수를 체크해보고 더 많은 실패 케이스도 작성을 해야 했는데

이번 프로젝트에서는 다소 부족한 부분이 있던 것 같다.

 

 

소통

소통은 좋았던 점도 있었고 개선하고 싶었던 부분이 있었다.

9명이 모여서 하나의 팀으로 운영이 되기 위해 많은 노력을 했었으나 부족한 부분이 많았다.

솔직히 말하기엔 사적인 이야기들이 많이 있어서 이 부분에 대해서 문제가 있었다 정도만 남겨야 겠다.

 

Try

부족한 기획과 문서

이 부분을 해결하기 위해 차기 프로젝트에서는 기획자를 1~2명 정도 섭외를 할 생각이다.

아무리 내 아이디어로 진행되는 프로젝트라고 하지만 나는 어디까지나 개발자다.

기획자가 필요하다.

 

기획자와 많은 이야기를 하고 이번 프로젝트를 통해 부족했던 문서에 대한 부분도

더 상세하게 다듬어 차기 프로젝트에서는 이번 프로젝트에서 부족했던 부분을 최대한 보완할 생각이다.

 

 

테스트코드

당분간 TDD 방식을 통해 작은 토이프로젝트를 해볼 생각이다.

이는 완성된 기능에 대해 작성하는 테스트코드와 느낌은 다르겠지만

테스트코드를 만들면서 더 상세하게 어떤 테스트를 진행해야 하는지 감을 잡을 수 있을 것으로 생각이 된다.

뿐만 아닌 앞으로 테스트코드에 대한 컨벤션을 만들어 볼 생각이다.

 

 

소통

이번 프로젝트에서는 어찌되었건 사람들과의 소통은 마무리가 잘 되었다.

이 과정에서 내 자신이 하지 말아야 할 것과 해야할 것에 대해 실수한 부분을 알았고

다음에는 똑같은 실수를 하지 않을 것이다.

또한 더 나은 방향으로의 소통을 위해서 소통의 방식도 바꿔볼 생각이다.

 

 

프로젝트를 마치며..

긴 시간 작업을 하며 잘한 것도 부족한 것도 많았었던..

과연 내가 이 프로젝트를 하면서 개발자로써의 성장을 했는가?라고 묻는다면

개발자로써 좋은 경험을 많이 했다고 이야기를 할 것이다.

성장을 못했다는 것은 아니다, 이 경험을 토대로 다음에 더 나은 결과를 남기면 그게 성장이라고 생각한다.

이 프로젝트에서의 경험은 나를 더 나은 사람으로 성장시켜주는 중요한 발걸음이 될 것이라고 생각한다.