제로베이스 팀프로젝트 진행록1 - 개발기획과 팀프로젝트

팀프로젝트에 들어가며(24.10.21~)

  첫주차 프로그램 기획단계에 들어와있는데, 처음부터 개인 프로젝트와 팀 프로젝트는 확연히 다르다는 것을 느낀다. 

(1) 매일 특정 시간에 만나서 회의를 하며, 매 안건마다 타인의 동의와 의견을 받고서 진행한다.

- 개인프로젝트에서는 내가 원하는 시간과 속도로 기획/개발하고서 어떻게 기획할지 심도있게 고민하는 방식으로 진행하였다면 팀프로젝트에서는 현장에서 즉각 즉각 Idea Pitching 형태에 좀 더 가까운방식으로 좀더 깊이있는 고민을 하기에는 어려웠다.

 

(2) 내가 할 수 없는 기술들을 배우고 개발에 적용할 수 있음, 반대로 내가 알고 있는 부분을 다른 사람들에게 적용시켜줄 수 있음.

- MSA 설계에 대해서 관심이 있었으나 시도를 해보지 못했는데 MSA에 대해서 이해도가 있으신 분이 있어서 덕분에 MSA 설계를 해볼수 있게되었다. 반면, 나는 멀티스레드를 미리 경험해보았기 때문에 이부분에 대해서 다른 분들에게 설명을 해줄 수 있을 것같다.

 

SWOT 툴로 보는 팀 프로젝트

  팀 프로젝트라는 것의 속성에 대해서 이해하고 기록하기 위해서 Strength(내부의 강점)-Weakness(내부의 약점)-Opportunity(외부의 우호적환경)-Threat(외부의 위협적 환경) 4가지 요소로 구성된 SWOT 툴로 분석을 진행해보겠다.

 

Strength

많은 인력이 있기때문에 많은 일을 할 수 있다

- 백엔드가 3명이기때문에 개인프로젝트보다는 보다 규모가 큰 프로젝트를 시도할 수 있다.

 

다양한 관점을 가지고 있어서 서로 몰랐던 내용을 보충해줄 수 있다.

- MSA 설계에 대해서 관심이 있었으나 시도를 해보지 못했는데 MSA에 대해서 이해도가 있으신 분이 있어서 덕분에 MSA 설계를 해볼수 있게되었다. 반면, 나는 멀티스레드를 미리 경험해보았기 때문에 이부분에 대해서 다른 분들에게 설명을 해줄 수 있을 것같다.

- 프론트에 대해서 모르지만 프로젝트 내에서  프론트를 구현할 수 있다.

 

합의를 통해서 이루어지기 때문에 공통책임으로 부담이 적다

- 매 결정이 합의를 통해서 책임이 분산되어 부담이 적었다. 그렇기 때문에 자유롭게 아이디어를 pitching할 수 있었다. 일단, idea를 던지면 다른 사람들이 이 부분에 대해서 평가와 가부를 결정해줄 수 있기 때문이다.

 

Weakness 

다양한 관점을 가지고 있어서 의견의 합치의 어려움으로 진행이 오히려 느릴 수 있다

- 매 결정을 모두 합의를 통해서 안건화와 합의를 통해서 진행하기 때문에 진척이 느리다. 반면 혼자할 경우 의사결정이 빠르기에 결과물도 빠르게 나올 수 있다.

 

다양한 관점을 갖고 있으며 모두 반영시킬 경우 결과물이 산으로 갈 수 있다.

- 특정 작업이 각 요소가 통일적이고 유기적으로 연동되어야 하는 경우, 팀으로서 서로 다른 관점으로 세부결정을 하다보면 전체적 결과물이 모순적인 경우가 있어 비효율적이다.

 

의견 조율 과정에서 갈등이 생길수 있다

- 비록 제기된 의견이 완전히 납득이 가지 않더라도 팀 내 대부분의 의견이라면 나의 의견을 접고서 따라야할 필요가 있다. 그렇지않으면 팀간 충돌발생가능함.

=> 나는 기획컨셉을 제안할때, 고객층에게 여행가이드는 아니지만 친구같은 여행가이드 서비스를 제공하는 컨셉이었기에 서비스 비용지불은 컨셉유지를 위해서 필요한 부분이라고 생각하였지만 팀원들이 비용을 지불이라는 기능을 넣는 것을 부담을 느껴서 팀의 의견을 따라서 

 

Opportunity

큰 구조와 틀 안에서 가이드가 명확하여 눈높이가 일치할때는 효과적임

- 기획이라는 틀이 끝나고 각자 책임과 역할이 명확하게 구분되는 순간 빠르게 일이 진행되고 서로 의견교류를 통해서 건설적인 방향으로 나아갈 수 있다고 생각함.

 

Threat

일관성이 있는 구조를 만들때, 여러명의 의견이 산발적으로 반영되면 결과물의 일관성이 떨어진다.

- 기획이라는 것은 일관성이 있는 구조를 만드는 것이 필요한데 모두 각자 의견이 들어가다보니 완성도가 부족해지고 모순이 발생한다고 생각함.

 

대표적인 조율사항들

백엔드내부 조율 및 토론사항

1. client가 자식테이블의 데이터를 삽입할때, 부모테이블의 데이터 존재여부를 검증시 DB의 join where문을 사용할 것인가 혹은 DB에 두번 접근하더라도 Java 서비스 로직에 녹여낼것인가 
   • → 코드 가독성을 위해서 비즈니스로직이 명확하게 드러나도록 구현에 우선 집중하도록 협의
2. 여행자모집 게시판과 리뷰 게시판을 별도 모듈로 분리할 것인가 혹은 합칠 것인가  → DB의 스케일아웃이 어렵기때문에 미리 분할하는게 좋을 수도 있지만 개발복잡도를 고려하여 합치기로 함
3. 인덱스의 설정의 비용과 효과
   1. → index가 걸려있으면 CUD 시에 시간 지연 문제 발생
   2. → insert cancel 후 인덱스 삭제전에 select시 시간지연 발생 (시간 지연이 너무심해 cancel 함 / 인덱스에 문제가 생긴것으로 추정 / 인덱스 삭제후 정상조회됨)
   3. → index 용량 문제 (root 패스워드를 잊어 확인은 못하였으나 10% 정도 증가한다고함 / 데이터 용량 3.3 G ) 확실히 index사용에도 장단점이 존재하는 것같아요

 

3. Resful API URL 설계원칙와 MSA에 대한 논의

-> URL은 자원의 위치를 표시하는 것으로 데이터 간의 계층구조를 반영한다. 때문에 ERD에서 데이터 테이블 간의 종속관계를 반영하여 url을 작성한다.

-> Restful API 내에서 queryParam와 Pathvariable의 차이는 Pathvariable을 한가지 자원을 식별하기 위해서 사용되고 queryParam은 collection 중에 filtering과 search를 위해서 사용된다.

-> 단, msa구조에서는 서로 다른 모듈의 데이터 테이블 간에 관계를 갖기 않기 때문에 독립적으로 표현한다.

 

4. 다중 계층을 갖는 게시글의 API를 어떻게 처리할 것인지 에 대한 논의

현재 개발중인 프로그램의 게시글은 1) 게시글 2) 게시글 내 일자별 게시글 2) 일자별 게시글 내 세부게시글으로 3중의 게시글 구조로 이루어져있다. 이를 작성하거나 수정할때 어떻게 처리할지?

→ 1안) 3가지 종류의 게시글을 모두 작성 및 수정하는 API를 작성한다.

→ 2안) 3자기 종류의 게시글을 각각의 API로 분리하고 이를 한번의 버튼클릭이라는 event 안에 transaction처리를 한다. 이는 프로엔트엔드와 백엔드 통신시에 모든 api호출이 도착했는지 확인하는 방법을 도입필요. (난이도가 있을 것으로 예상)

→ 1안으로 진행후 추후 리팩토링시 고민예정

 

프론트와 백엔드 조율사항

 

1. 여행모집 게시판의 로드맵을 여러 계층으로 나누는데 몇개의 계층으로 나누는 것을 희망하는지, 이에 따라 테이블설계가 달라지기때문 

-> 양자간의 의견 : 단순화를 위해서 가능하면 1개의 계층으로 통일했으면 좋겠다고 협

 

2. 백엔드 API를 구축할때, 기획문서가 내용이 완전하지 못하여 어떤 기능을 구현해야하고 어떤 기능을 구현하지 않아야 하는지 하지 않아서 가능한 기획문서를 

-> 팀으로 일을 할때 확실한 증빙을 가지고서 움직여야하며 이것이 문서라고 할 수 있다. 문서를 잘작성하고 이를 잘 따르는 것이 협업에 있어서 중요한 ㄴ

 

멘토 피드백

TIL : 최적화 전략에 왕도는 없다. 코드의 가독성과 기능구현이 우선이지, 성능은 문제가 되기전까지는 문제가 아니다. 성능문제는 환경에 종속적인 것이지 일반적인 원칙이라는 것은 존재하지 않기때문이다.

 

 

결론 및 첫주차 후기

팀 프로젝트에서는 해당 상황이 어떤 상황인지 판단하고 우선순위를 제대로 선정하는 것이 중요하다고 생각함. 모두가 동등한 직급으로 어떤 누구에게도 결정권이 없으며 창의성이 필요한 기획의 단계에서는 민주성이 중요하다고 생각함. 때문에 나의 의견의 관철 시키기보다는 팀워크가 깨지지 않는 것을 우선순위로 하였고 그렇기때문에 의견을 pitching하되 집요하게 관철시키지 않는 stance를 지키기로 생각함.

  초반에 소극적인 사람들도 있었으나, 적극적으로 참여하지 않는 팀원에 대해서도 그사람을 바꿀수 없는 것을 알기때문에 포용하는 방식으로 생각함. 결국에는 소극적인 팀원들도 분위기에 무르 익으면서 충분히 적극적으로 참여하였음.

  또한, 기획후 백엔드에서 API명세서를 작성한 것과 프로엔드의 와이어프레임 작성하였을때 두개의 사이에서 괴리가 큰 것을 보고, 이의 원인이 문서의 명확하지 않은 기술에 의한 것임을 배웠음. 이를 통해서 팀간 협의를 통해 문서를 잘작성하고 이를 준수하는 것이 팀워크의 기본인 것을 알게되었음.