2024.11.07(목)
팀 프로젝트를 진행하면서, 프로젝트를 빌드하는 방향에서 고려해야 할 프로젝트 진행구조를 어떻게 빌드하고 작성해야 하는지 깨닫게 되었습니다.
물론, 제가 깨달아서 정리한 부분이 모든 프로젝트에서 정석적으로 사용될 지는 모르겠습니다만, 개인적으로 팀 프로젝트를 어떻게 진행해야 하는지를 적립하게 된 것 같습니다.
다음은 이번에 진행한 팀 프로젝트의 구조입니다.
이번 팀 프로젝트의 프로젝트 구조 및 역할분담은 다음과 같습니다. (팀원 별로 도형으로 표시했습니다. 동그라미가 저입니다.)
이번 프로젝트에서는 프로젝트 구조를 각 기능들을 모듈로 나눠서 앞선 모듈들을 구현하면 다음 모듈을 구현할 수 있는 지도를 만들어서 진행했습니다.
화살표 이전에 있는 모듈을 구현해야만, 다음 모듈을 만들 수 있는데, 이 정보가 있는 지도를 만들고 공유하여, 프로젝트를 진행하면서 팀원분들은 자신이 구현하고 싶은 모듈이 선행 모듈(앞서 구현되어야 할 내용이 있는 부분)이 모두 구현되어있는지 확인한 후 모듈을 선택해서 구현합니다.
이 방식으로 팀 프로젝트를 진행하면서 들이닥친 문제점이 있었는데, 이제 한 팀원이 앞선 모듈을 개발하다가 문제점이 생겼을 때, 그 모듈과 의존된 뒤의 모듈들을 다른 팀원이 개발하기 어렵다는 점이 있습니다.
개발 가능한 다른 모듈들이 있을 땐 어느정도 상관없을 수도 있지만, 프로젝트 전반에 걸쳐서 의존성이 많이 있는 부분에서 문제가 생긴다면, 연계되는 많은 부분들을 작성하기 어렵다는 문제가 있습니다.
이번 프로젝트에서 적립한 팀 프로젝트 빌딩 과정에서 고려해야 하는 부분을 정리하겠습니다.
이번 프로젝트에서는 기능들을 모듈별로 나누어서 그 모듈이 만들어지기 위해 선행되어야 하는 모듈을 순서도로 작성하여, 앞선 모듈부터 각각 선택해서 차례대로 만드는 방식으로 진행했습니다.
이 방식의 문제점은 중간의 한 모듈을 만들 때, 문제가 발생하면 그 모듈을 이용해서 만드는 이후 기능들을 만들지 못한다는 단점이 있습니다.
이 방식을 해결하기 위해서, 각 팀원들이 그냥 한 모듈별로 맡아서 작업을 하면서 필요한 부분들을 interface로 요청하면 그 기능들을 만들어 주는 방식으로 작업을 하면 된다고 느꼈습니다.
정리하면, 각 개발자가 모듈의 내부기능들을 만들면, 다른 모듈을 담당하는 개발자가 그 모듈의 정보를 필요로 할 때, 그 인터페이스를 요청하는 방식으로 프로젝트를 진행하면 좋을 것 같다는 생각이 듭니다.
끝.