[프로젝트 설계에서 사용자까지] 2–1. 설계하기 (일정 분배와 개발방법론)

1. 요구사항 분석 
2. 설계하기 
  1) 일정 분배와 문서화 << 현재단계
  2) 데이터 모델링과 코딩 컨벤션
  3) 배포 프로세스 설정
  4) 설정 세팅 
3. 구현하기 
4. 테스트와 모니터링

1️⃣ 일정 분배와 문서화

1. 노션 팀원별 업무 분배

a. 업무 난이도 및 양을 고려한 분배 (담당자 확정 전)

설정 세팅과 비즈니스 로직 2개로 구분하여 총 4개의 섹션으로 나눔

b. 팀원 선호도 조사

프로젝트를 하며 얻어가고 싶은 것 써보고 싶었던 기술에 대한 선호도 조사

팀원들 개개인의 선호도 및 몰입할 수 있는 시간적 상황 등을 고려하여 a. 번에서 나눈 4개의 구분에 각각 담당자를 할당시켰다.

2. 문서 공유와 소통 경로 확정

문서는 어디에 공유하고, 소통은 어디서 할지 그 기틀을 잡고 계속해서 기록해나가야 한다.

팀원들이 사용하는 문서들이 산발적으로 흩어지지 않고 한 곳에 모아져서 아카이브 형태로 볼 수 있어야만 소통에 들어가는 비용이 줄어들기 때문이다.

노션 메인 페이지 팀원들이 쉽게 문서 공유 페이지에 접근할 수 있다.

3. 설계 단계 개발 일정 산출

각 담당자별로 맡은 개발 설정의 순서를 정하고 언제 시작하여 대략 언제 완료될지 일정을 계획해본다.

고려하였던 것은 우선

코딩 컨벤션을 잡고 (팀원 1명이 중심으로 작성하되, 세팅 담당자가 책임 부분을 작성한다) -> AWS 연결 -> 데이터 모델링 -> 공통 응답 api -> swagger -> CI/CD -> 파일업로드 순으로 세팅 순서를 설정하였고 주차별로 완성되어야 하는 기능들을 표로 정리해두었다.

설계 총 5주간 각 담당자별 주차별 맡은 업무

주 2회 회의를 진행하며 업무 진척상황을 공유하였고 기획팀과도 끊이없이 소통하며 요구조건을 좀 더 상세화를 진행하였다.

💥 프론트와의 소통의 문제

백엔드 팀만 관리를 하다보니 프론트팀과의 소통에 어려움이 있었다. 서로 진척 상황에 대한 파악이 어려웠고, 서버쪽으로 데이터를 보내지 않고도 프론트단에서 처리할 수 있는 기능에 대해서 사전에 충분한 협의를 거치지 못 했다는 것이 아쉬운 점이었다.

💠 노력의 과정 : “규칙, 규격화”

백엔드 팀은 설계 과정에서 총 2주의 회의를 진행하였는데 주 1회는 전반부에 프론트 팀과 함께 회의를 진행하였다.

프론트와 공유할 사항을 최대한 자세히 정리 / 1차 2차 회의 나누어서

이때 프론트 팀과의 협의가 필요한 것들은 따로 정리하여 논의를 거쳤으며, 협의가 가장 필요했던 API 명세의 경우는 따로 노션 페이지를 만들어서 댓글과 멘션으로 소통할 창구를 마련하였다. 어떻게 멘션을 달고, 어떻게 글을 작성하는지 규칙을 정해두고 전파하였다.

정확한 규칙에 따라 ‘문서화’ 를 해서 서로 다른 언어를 사용함으로써 발생하는 의사소통의 비효율을 줄이려고 노력하였다.

2️⃣ 개발 방법론

코딩에 필요한 규약들은 github에 WIKI를 사용하여 정리하였다.

공통으로 컨벤션을 정의하는 담당자 1인을 중심으로 각자가 담당했던 설정 세팅 그리고 다른 팀원이 따라야 하는 정확한 규칙들을 ‘문서화’ 하여 팀원에게 전파하도록 하였다.

컨벤션 잡으면서 계속해서 기술에 대한 고민도 함께 진행하였다.

코드 리뷰/파일업로드/PR 작성법 등 그때 그때 팀원들과 협의를 진행했고, 프로젝트 구조를 짤 때 어떤 방법론으로 설계가 들어갔는지 고민하고 이를 전파하는 시간도 가졌다.

아키텍처 설계 원리 전파 및 코드 리뷰 방법 논의

💥 일감 트래킹의 어려움

실무에서 하는 방식대로 각자 일감을 할당하고 그 일감의 진척도를 구체적인 퍼센테이지로 관리하는 것이 쉽지 않았다. 깃허브에도 그런 기능이 있지만 팀원들이 각 일감을 세부적으로 나누고 진척 상황을 트래킹하게끔 매일 독려하는 것을 잘 못했던 게 큰 원인이었다.

🍀 노력의 과정: “분배” “주차별” 관리

각 팀원이 스스로 일감 및 일정 관리가 어렵다면, 프로젝트의 큰 그림내에 각각의 일감을 생성해놓고 주차별로 할당하였다.

매 회의시에 얼만큼 진척이 되었는지 확인하는 식으로 일감을 관리하고자 했다.

3️⃣ 데이터 모델링

SB 전체 플로우를 분석하여 전반적인 데이터 모델링을 도출하였다.

비록 객체 지향 TDD 방법론으로 개발을 하기 때문에 데이터 모델링의 중요성은 그다지 크지 않았지만, 팀원들이 전반적인 서비스의 흐름을 이해하도록 하는 목적으로 ERD 를 작성하였다.

데이터 모델링의 이론을 최대한 참고하여 기준 Entity를 먼저 잡고 개념 -> 논리 모델링을 번갈아 진행하며 entity 들을 구체화 시켰다.

또한 ERD 는 클라우드로 작성하여 팀원들이 쉽게 접근할 수 있도록 하였고, 데이터 모델링을 도출하는 도중에 염두해야할 각 entity의 특징은 컨벤션에 기입해두어서 각 모듈별 담당자들이 쉽게 참고할 수 있도록 하였다.