먹짱(쇼핑몰 프로젝트) - 킥오프

제대로 해보는 첫 프로젝트

스터디 활동에서 첫 미니 프로젝트를 끝내고, 부트캠프 진행하는 정규 프로젝트를 바로 시작하게 됐다. 오늘을 기준으로 이틀 전에 시작했다. 이번 프로젝트는 리액트가 아닌 순수 vanillna javascript와 node.js를 통해 쇼핑몰을 구현하게 된다.

우리가 구현할 쇼핑몰은 도매, 소매로 식료품을 구분하여 판매하는 이커머스 서비스이다. 서비스명은 귀엽게 먹짱으로 제안했고 감사하게도 채택됐다.

팀장만은 안되는데...

예전부터 앞에 나서는 걸 별로 안 좋아했다. 사람들 앞에서 긴장을 많이 하기도 하고, 빈틈이 많은 주제에 완벽주의적 성향이 강한 탓에 부담감과 압박감을 많이 느끼기 때문이다. 그런 내가 사다리타기로 팀장이 돼버렸다.

그런데 이상하게 긴장되지 않았다. 묘하게 편했다. 비대면의 힘일지도. 무엇보다 직전 미니 프로젝트에서 느꼈던 많은 문제점을 만회할 수 있는 절호의 기회라는 생각에 들떴다.

프로그래밍을 시작하면서 성장에 대한 열망이 폭발적으로 커지는 중이라. 자신감과 나름의 열정이 솟아났다. 그래서 정말 누구보다 잘한 팀을 만들어보기로 결심했다.

킥오프 미팅

프로젝트가 처음인데, 팀장을 맡아버리니 당장 킥오프 회의에서 어떤 주제를 얘기해야 하는지 감이 안 잡혔다.

그래서 내가 주로 찾아본 키워드는 다른 초보 개발자의 첫 프로젝트 후기를 검색했다. 회고에서 써진 문제점들, 좋았던 점들을 훔쳐와서 바로 내 프로젝트에 적용해보기로 했다.

핵심 가치관

• 한가지 핵심 가치관에 중점을 두고 여러가지 액션 아이템을 기획했다.

  무조건 오버커뮤니케이션. 소통하고 또 소통하자

• 첫 미니 프로젝트에서 느꼈던 문제점이다. 소통이 없기에 다른 사람이 진행하고 있는 업무, 전반적으로 모두가 그리고 있는 그림의 일부가 내가 생각하는 그림과 일치하는 지 알 수가 없었다. 내가 팀장인 이상 같은 실수는 용납되지 않는다.

협업 방식

체크인 / 체크아웃 미팅

• 오전, 저녁 하루에 두 번 체크인, 체크아웃 회의를 진행한다.
• 오전에는 구현할 기능을 공유하고 저녁에는 진행상황 및 구현한 기능을 공유하고 머지하면서 코드가 작동하는 구조에 대해 간략히 설명한다.
• 남이 짠 코드를 이해하지 못한다면 혼자 프로젝트를 진행하는 것과 다를 바가 없다. 나를 포함한 팀원들에 성장에 필수적으로 필요한 역량이다.

git flow

• 이제는 익숙하다. 이전에는 dev-main 2계층으로 진행했다면 이번에는 제대로 Back,front/dev/main 3계층 브랜치로 진행한다.
• 브랜치는 기능마다 새롭게 생성한다. (front의 경우 F/login, back의 경우 B/searchmiddleware)
• commit 메세지에 대한 모범적인 컨벤션도 함께 정했다.
  • 커밋 메세지는 한글과 명사형으로 표현하기
  • 한 개의 커밋에는 가능한 하나의 기능만
• 머지는 팀장이 하며 체크아웃 회의 때 다같이 화면 공유를 통해 각자의 코드에 대해 설명한다.

역할 분배

• 우리팀만의 커스텀 애자일을 적용하기 위해 유기적으로 나뉘었다 붙을 수 있는 소규모 목적형 셀을 나누기로 했다.
• 프론트3, 백엔드2로 구성된 팀에서 주요 기능 흐름별로 나누고 그 기능마다 담당자를 두는 형식이다. 이전 회사인 토스에서 사일로라고 부르는 개념을 소규모화했다.

  ex. 페이지 flow에 따른 역할 분배 (프론트 a,b,c / 백엔드 a,b)

  1. 프론트A, 백엔드A : 제품 목록 - 제품 상세 페이지 - 장바구니 추가/결제 페이지 이동
  2. 프론트B, 백엔드B : 회원가입 - 로그인 - 마이페이지 - 어드민 관리
  3. 프론트C : 메인페이지 - 페이지 단위 레이아웃

업무 공유 툴

• 아사나 : 아사나는 예전부터 사용해보고 싶었던 툴이다. 이번 프로젝트에서는 프로젝트 주요 일정 공유(회의, 스프린트 일정 등)와 업무 진행 상황에 대한 개략적인 공유를 하기 위해 사용할 예정이다. 이또한 이전 프로젝트에서 느꼈던 커뮤니케이션 부재로 꼭 활용해보고 싶었다.

• 깃랩 : 부트캠프에서 지정해줬기 때문에 깃헙 대신에 깃랩을 사용하게 됐다. 깃랩의 ISSUE, MILESTONE등을 적절히 활용하여 구체적인 업무 진행 상황에 대해 공유할 예정이다.

코드 컨벤션

• 프론트 파트에서는 변수명, CSS 규칙(margin 최대한 쓰지 말기), semantic하게 만들기 등을 정했고
• 코드 컨벤션은 아니지만 백엔드 api를 어떻게 하면 가독성있게 공유할 수 있을지에 대해서도 논의했다.

1/14이 지났다

주어진 프로젝트 기간은 14일이다. 팀이 지켜야 할 협업 룰을 정의하는 것 그리고 주어진 스켈레톤 코드를 이해하는 것에 귀중한 하루를 보냈다.

하지만 무의미한 시간은 절대 아니라고 생각한다. 마치 로스트아크라는 게임에서 딜러 4명의 누적 데미지량과 딜러3명과 서포터1명의 누적 데미지량 중 후자가 높은 것처럼 나는 지금 서포터를 우리 파티에 둔 것이라고 생각한다.

커뮤니케이션의 부재로 프로젝트가 원할하게 이루어지지 않는 것을 미리 경험해봤기 때문에 그에 대한 대비를 철저하게 하는게 당연했다.

이제 내가 실행해야 할 것은 물론 내가 담당하는 기능의 코딩도 중요하지만, 내가 설정한 이러한 협업 프로세스에 팀원들을 얼마나 얼라인시킬 수 있는지가 관건이였다.

이게 잘 지켜지지 않는다면 새해에 세우는 계획과 다를 바가 없다. 치밀하게 계산해서 팀원들의 적극적인 참여를 유도해야 한다.

그리고 다음 날 진행할 오프라인 미팅(애자일 어떻게 적용할 것인지)를 준비하며 하루를 마무리했다.