프로젝트 개발 프로세스와 협업

Java와 Spring을 공부하기 시작한지 어느덧 7주 가량의 시간이 지났고,

드디어 본격적인 팀 프로젝트를 시작하게 되었다.

오늘은 팀 프로젝트의 첫 발제날이여서 팀원들과 함께 프로젝트를 기획하고,

전체적인 구조를 설계해보는 시간을 가졌다.

그 과정에서 느낀점과 배운점을 기록하고자 한다.

---

✅ 프로젝트 아이디어 구상

프로젝트의 큰 주제는 '뉴스피드' 프로젝트였고, 다양한 뉴스피드중에서 우리가 구현할

뉴스피드를 구상해야 했다.  뉴스피드란 내 게시물을 포함한 모든 게시물을 볼 수 있는 공간,

즉 커뮤니티 사이트 같은 의미이다. 최대한 실용적이고, 프로젝트 구현에 있어서 재미를 느낄만한

좋은 아이디어를 구상하던 중, 가장 먼저 떠오른것이 '중고 거래 플랫폼'이였다.

팀원들이 모두 동의하여 아이디어 구상은 금방 끝났지만, 프로젝트의 전체적인 방향성을

결정하는 단계인 만큼 굉장히 중요하고 오래 고민을 해야할 단계라고 생각한다.

---

✅API 명세 작성

진행할 프로젝트에 필요한 기능들을 구상하고, API 명세를 작성하는 단계이다.

우리는 중고 거래 플랫폼을 개발하는데 있어서 반드시 필요할만한 API(회원가입 및 로그인, 상품 CRUD 등등)

들을 명세서 규격에 맞춰서 명세했다. 추가 구현해야 할 기능들은 따로 명세서 업데이트를 해야겠지만

반드시 구현해야 할 API들을 미리 명세서로 작성하는 것은 본격적인 개발단계에 들어갈 때 매끄러운 개발 진행에

큰 도움이 되고 역할 분담을 하는데도 좋은 기준이 된다.

---

✅ERD 설계

서버의 데이터를 저장, 관리하는 데이터베이스 스키마를 설계하는 단계이다.

사실상 협업을 할 때에 있어서 가장 중요한 단계라고 생각된다. 데이터베이스의 구조와 엔티티들의

연관 관계 및 필드 변수 설정은 전체 코드를 구현하는데 있어서 큰 영향을 미치기에  

각자 기능 개발을 시작하기 전에 꼭 합의하에 통일해야 할 필요가 있다. (충돌 방지)

이와 별개로 ERD를 먼저 설계해놓으면 데이터 구조가 명확하게 명시되어있기에

시스템의 요구사항을 사전에 분석하고 검증할 수 있다. 기능 구현 단계에서 발생할 수 있는 누락된 요구사항이나

잘못된 가정을 사전에 방지할 수 있다는 뜻이다.

ERD 예시

ERD를 설계할 수 있는 툴로는 ERDCloud(https://www.erdcloud.com/), drawio(https://app.diagrams.net/) 등이 있다.

우리는 drawio를 활용해 ERD를 설계했다.

---

✅와이어 프레임 작성

우리가 개발할 프로젝트의 UI/UX, 즉 서비스의 형태를 대략적으로 도식화 하는 것이다.

협업을 함에 있어서 큰 도움이 될 것 같지는 않았지만, 프로젝트의 기능 목록에 빠진 기능이 없는지

체크하고, 또 어떠한 기능이 추가되면 좋을지에 대해 구상해 볼 수 있다.

특히, 제 3자 입장에서 봤을 때 우리의 프로젝트가 어떤 서비스를 제공하는 프로젝트인지 한눈에

볼 수 있어서 좋을 것 같다.

와이어프레임 예시

디자인 퀄리티가 썩 좋지는 않지만, 프로젝트가 어떠한 서비스를 제공하는 프로젝트인지는 한눈에 확인이 가능하다.

와이어 프레임을 설계할 수 있는 툴로는 figma(https://www.figma.com/), drawio 등이 있다.

우리는 figma를 활용해 와이어 프레임을 설계했다.

---

✅본격적인 백엔드 기능 개발

📌 Github 레포지토리 생성

팀장이 다 같이 협업할 프로젝트의 Github 레포지토리를 생성한 뒤, 팀원들을 초대한다.

팀원들이 각자 개발한 기능들을 병합할 dev 브랜치를 생성한 뒤, 해당 브랜치를 

Default 브랜치로 설정해두면 좋다.

📌 디렉토리 구조 및 공통 클래스 통일

각자 맡은 기능에 대해 따로 브랜치를 생성하고 기능 개발을 시작하기 전, 프로젝트의

디렉토리 구조와 팀원들이 공통으로 사용할(필요한) 클래스 등은 미리 합의하에 통일해야 할

필요가 있다. 이 부분이 합의되지 않는다면 각 기능 브랜치를 merge하는 과정에서 많은 충돌이

발생할 수 있다. 따라서 dev 브랜치에 미리 디렉토리 구조를 설계하고, 공통 클래스를 생성해 둬야 한다.

디렉토리 구조

우리가 설계한 디렉토리 구조는 다음과 같고, 공통으로 사용할 properties, 엔티티 클래스 두 개를 합의 하에 통일하여 dev 브랜치에 추가하였다. 

📌 기능 개발 브랜치 생성 및 협업

여기까지 왔으면 이제 본격적으로 기능 개발을 시작하면 된다. 각자 맡은 기능을 구현할 브랜치를 새로 생성하고,

통일시켜둔 dev 브랜치의 디렉토리 구조와 공통 클래스를 받아와 기능 개발을 하면 된다.

그리고 맡은 기능 구현이 완료되었다면, dev 브랜치로 개발한 기능을 merge하면 된다.

충돌이 발생할 여지는 위 과정에서 사전에 예방했기 때문에 문제없이 병합이 가능할 것이다.

 

---

✅느낀점

과거 개발 협업이란 것을 처음 진행했을 때에는 Git 사용이 익숙하지도 않았고, 팀원들과의 별다른 합의 없이

맨땅에 헤딩하듯 협업을 진행했기에 병합 과정에서 충돌도 굉장히 잧았고, 오히려 혼자서 개발하는게 더 빠르고

효율적이겠다는 생각이 들 정도로 문제가 많았었다.

하지만 정석적인 개발 프로세스를 거치니, 짜증만 나고 비효율적이였던 첫 협업과 다르게 놀라울 정도로

협업 과정이 매끄러웠다. 협업을 시작하기 전 프로젝트 설계와 공통 환경 합의 과정의 중요성을 알게 되었고,

앞으로도 이러한 프로세스를 거치며 팀 프로젝트를 진행한다면 효율적이고 재밌는 협업이 가능할 것이라

생각된다.