🌈[프로그래머스] 프론트엔드 데브코스 회고 (5)

🍀 최종 프로젝트 시작

처음 백엔드와 협업하는 프로젝트이자 데브코스의 마지막 활동인 최종 프로젝트를 시작했다.
중간 프로젝트가 끝난 뒤 쉬어가는 시간을 갖고 강남에서 오프라인으로 만나 서로 간 알아가는 시간을 가졌으며, 백엔드 5명, 프론트 4명이란 대규모 인원이었기 때문에 함께 진행할 프로젝트를 결정하는데 고민이 많았다. 최종 프로젝트는 적게는 6명에서 많게는 9명까지의 인원수로 팀을 구성해 이루어졌으며, 약 2달간의 프로젝트 시간이 주어졌다. 10월은 이러한 프로젝트 기획 및 초기 개발을 진행하며 보냈다.

🚀 프로젝트 기획

기획 아이디어로 나와 간략히 기획서까지 진행한 의견은 5가지로 아래 정리한 내용과 같다.
이러한 다양한 의견들 중 소상공인을 위한 폐기 예정 상품 예약 서비스를 결정했으며, 아이디어를 구체화하고 기획안을 작성하는 등 기획 측면에 많은 시간을 투자했다.

기획을 하면서 개발자 9명만 모여서 의견을 나누다보니 막막한 부분이 많았었고, 항상 회의때마다 나왔던 이야기가 기획자와 디자이너가 있었으면 좋겠다는 것였다. 기획이 구체화되기 전까지는 몇시간씩 계속 회의를 했기 때문에 이 시기가 가장 힘든 시기였던 것 같다.

• 쿠폰 관리 서비스

  쿠폰 관리 서비스는 카페나 식당 등에서 받는 종이 쿠폰에서 아이디어를 떠올리게 되었으며, 이러한 여러 쿠폰들을 서비스를 통해 쉽고 간편하게 관리할 수 있으면 좋겠다는 취지로 진행하게 되었다.
  다만 실사용성 측면에서 어려울 수도 있다는 의견이 존재했고, 실제 비슷한 타서비스가 존재했다는 점, 개발 측면에서 고려해야 할 점이 많았다는 점 등을 토대로 기각되었다.

• 데브코스 백둥이와 프롱이의 만남 커뮤니티

  이 서비스는 타겟층을 확실하게 했으면 좋겠다는 취지에서 시작된 아이디어로 처음 백엔드 팀과 소통하면서 알아갈 때 그동안에는 접정이 없었는데 최종 프로젝트 전에도 만남을 가질 수 있어 소통하면 좋겠다는 아이디어에서 시작했다. 그러나 슬랙의 존재로 인해 서비스만의 장점이 사라졌고, 흔한 커뮤니티 서비스가 될 수 있다는 의견이 다수 존재해 기각되었다.

• 오프라인 행사 정보 플랫폼

  오프라인 행사 정보 플랫폼은 뮤지컬이나 연극 등 오프라인으로 참여하는 행사등에 대한 디테일한 정보를 얻고, 예약까지 고려된 아이디어였다. 다만 처음 아이디어 의견과는 달리 구체화하는 과정에서 정체성이 모호해져서 기각되었다.

• 반려견 산책 서비스

  반려견 산책 서비스는 반려동물이란 키워드에서 시작했으며, 산책 대행 서비스가 있으면 좋을 것 같다는 의견에서 구체화가 이루어졌다. 다만 이미 존재한 타서비스가 너무 우수했고, 여러 윤리적인 측면에서 아이디어가 부족해 기각되었다.

• 소상공인을 위한 폐기 예정 상품 예약 서비스

  이 서비스는 거의 마지막 시기에 나왔던 의견으로 처음 의견은 편의점 폐기 예정 상품, 소상공인들의 당일 유통기한 마감 임박 상품 등 의견과 타겟층이 나뉘어져 혼란을 빚었지만, 추후 기획을 구체화하고 커뮤니케이션을 지속적으로 가지면서 구체화했으며, 최종 프로젝트란 점과 실용성이 있다는 점, 9명이란 대인원으로 진행할 만한 프로젝트란 여러 점들을 토대로 결정하게 되었다.

프로젝트 소개를 간단하게 소개하면 다음과 같다.

🚀 디자인 작업

전체적인 프로젝트 디자인의 와이어 프레임 작업은 다같이 진행했다. 프론트엔드 개발자끼리 회의를 할 때 디자인을 맡게 되면서 디자인 총괄을 담당하게 되어 디자인 회의에서는 내 주도하에 진행하게 되었으며, 간단하게 작성한 와이어 프레임은 다음과 같다.
처음 기획했을 당시 사용자의 이용 측면을 고려하면 모바일이 적합하다고 판단했기 때문에 전체적인 디자인은 모바일로 이루어졌다.

이제 이 와이어 프레임을 토대로 테마 컬러를 투표해 결정하고, 프로젝트명이자 서비스명을 결정했으며, 로고나 대표 이미지 등을 회의를 통해 의논해 결정했다.
그 결과 테마 컬러는 노란색으로, 프로젝트명이자 서비스명은 거래와 기쁨이란 의미의 '딜라잇(Dealight)'으로 로고나 대표 이미지에는 퍼센트 기호와 시계를 넣어보자는 의견으로 정리가 되었다.

추가적인 세부 디자인 작업은 틈틈히 시간 내어 작업을 이어가고 있으며, 프로젝트에서 tailwind를 사용하기로 했기 때문에 tailwind 문서에서 제공하는 단위에 맞춰 디자인을 고쳐나가는 작업을 진행하고 있다. 혼자 진행하다보니 시간이 부족하기도 하고, 오래 걸리기도 했지만 팀원들이 믿고 기다려주기 때문에 최대한 부담을 덜 수 있었다. 여러 레퍼런스를 참곻하려고 노력했으며, 아이폰 8을 기준으로 디자인을 하게 되었다.
크게 사용자가 업체와 고객으로 나눌 수 있기 때문에 디자인을 2가지로 나누어 진행하고 있으며, 작업 일정에 맞춰 다른 팀원들이 참고하며 개발할 수 있도록 선작업을 진행하고 있다.

🚀 학습 기간 & 프로젝트 설정

⚒️ 깃허브 설정

처음 프로젝트에서 개발하기에 앞서 프론트 팀은 학습 기간을 자체적으로 가졌으며, 이때 학습한 내용은 크게 3가지 정도이다.

• 크로마틱을 이용한 스토리북 자동 배포
• 컴포넌트 구현 연습
• npm 라이브러리 생성

이 중 실제 최종 프로젝트에 적용한 것은 2가지 정도로 크로마틱, 깃허브 action등을 통해 자동 배포와 스토리북 자동 배포를 develop에 pr을 날릴 때마다 진행되도록 설정했다.
그 외에도 주에 한 번씩 스프린트를 갖기 때문에 이때 이용하는 Milestones 설정, issues, pr, discussions 등을 사용하기 위해 초기 세팅을 하였다.

⚒️ api 명세서 및 규칙

기본적으로 주 2회 스프린트 겸 전체 회의를 진행하며, 그 외에는 자유롭게 개별적으로 담당자와 소통하는 방식으로 진행했다.
문서화 작업은 보통 노션을 이용했으며, api 명세서 또한 노션으로 이루어졌다.
그 외에 컨벤션이나 개발 규칙 등은 백엔드와 프론트 자체적으로 이루어졌으며, 프론트에서는 git flow 방식으로 main develop feature 를 두어 진행했고, 그 외에는 이슈와 branch 연동, 라이브러리 사용 등 매일 커뮤니케이션하면 정해 나아가고 있다.

• 작업 진행 순서

  issue에서 작업을 등록한다. ex) 시작 화면 버튼 컴포넌트 작업
  issue에서 태그를 등록한다. ex) 작업자, project 등...
  issue 작업자가 branch 생성을 한다. ex) 19-시작-화면-버튼-컴포넌트-작업
  pull request 제목에서 이슈 번호는 제거한다. ex) 시작 화면 버튼 컴포넌트 작업

• branch 전략
  

  github flow 전략을 응용하여 develop branch를 추가해 사용한다.
  main - develop - 작업 브랜치

• commit 컨벤션

  feat 새로운 기능을 추가할 경우
  fix 버그를 고친 경우
  refactor 리팩토링한 경우(리팩토링 과정에서 파일 삭제, 이동 포함)
  style CSS 등 사용자 UI 디자인 변경
  docs 문서를 수정한 경우
  chore 이외의 것들