[자바 국비지원] 팀 프로젝트 회고 - 1. 후기

지난 한달간 조원 2명과 쇼핑몰 제작 프로젝트를 진행했고, 처음 팀 프로젝트를 경험하며 막막했던 부분들을 기록으로 남기고자 글을 작성하였다. 나와 마찬가지로 처음 팀 프로젝트를 경험할 누군가에게 도움이 될 수 있으면 좋겠다.

1. 후기

프로젝트를 진행하며 느낀 사항 중 좋았던 부분과 다음에 필히 개선해야겠다고 생각했던 부분을 되새겨 보았다.

1-1. 만족했던 점

팀 단위의 개발을 처음 경험해보며 혼자서 개발할 때는 추상적으로만 느껴졌던 협업에 대한 부분을 몸소 체험해볼 수 있는 기회가 되었고, 그러면서 여러 시도를 해볼 수 있어서 좋았다.

1-1-1. 협업 & 버전관리툴 활용

적절한 몇가지의 협업툴을 활용하는 것은 생산성을 높여주는 결과를 얻을 수 있다고 느꼈다. 경우에 따라서 카카오톡과 텍스트 파일로도 충분히 협업이 가능할 수도 있겠지만, 이것들이 충족해줄 수 없는 많은 기능들이 신속한 의사결정과 프로젝트 문서화에 도움이 많이 되었다. Git 또한 프로젝트의 이력과 안정성을 높이는데 도움이 되었고 여러명과 함께 다뤄보는 경험을 할 수 있어서 좋았다. 사용 간에 큰 오류는 없어서 문제 해결에 대한 경험은 많이 얻지못한 부분은 아쉬움으로 남는다.

1-1-2. 컨벤션 정의

다음에도 누군가와 작업을 한다면 컨벤션 정의는 빼놓지 않을 것 같다. 파일과 변수 명칭을 사전에 협의하여 혼란을 최소화 했고, 폴더 구조를 사전에 협의한 후 각자 역할에 맞춰 사용할 폴더 영역을 배분해 버전 관리에서 충돌도 방지할 수 있었다고 생각한다.

1-2. 아쉬운 점

아쉬운 점이나 뒤에 서술할 공부 방향에 대해서 언급하자면 끝도없이 많지만 대표적인 부분을 간추려 보았다.

1-2-1. 프로젝트 규모 설정 실패

최초에 규모를 크게 잡았고 그중 일부는 구현을 하지 못한채로 프로젝트를 종료 했다. 변명을 하자면 최초 5인으로 구성 될 예정이던 팀 규모도 3인으로 축소되고, 프로젝트의 절대적 기간도 짧았다고 할 수 있겠지만 그것만이 문제는 아니였다고 생각한다. 각 기능별 연결 부위나 관계 테이블 연관성 이슈를 사전에 파악하지 못해 지연이 발생하거나, 기능 구현을 위한 정보를 습득하는 부분에서 많은 시간을 소비하는 등 예외 변수들을 고려하지 못했고 이는 전체적인 구현도를 낮추게 된 직접적인 요인이 되지 않았나 싶다. 경험이 부족한데서 나온 결과였으며 계속해서 이 부분에 대한 시각을 넓혀야 겠다고 다짐하게 되었다. 그리고 다음 프로젝트에서는 핵심 기능에 초점을 두어 양보단 질을 다뤄보고 싶다고 느꼈다.

1-2-2. 단위 테스트 미흡

시작 단계에서는 TDD방식은 아니더라도 각 유닛별로 테스트 모듈을 모두 작성하려고 마음먹었으나 중 후반부로 가면서 부터 구현에 치중한 나머지 소홀해진 경향이 없지않아 있다. 그리고 프로젝트가 진행되며 각 기능들이 수정됨에 따라 기존 테스트 모듈이 동작하지 않거나 실제 서비스와는 상관없는 불필요한 코드가 되기도 했다. 테스트의 필요성에 대해서는 충분히 이해가 되지만 테스트 자체가 업무가 되는 괴리감을 느끼기도 했고 테스트 주도 개발이 이뤄지기 위해서는 프로젝트 구상단계가 더욱 정교하게 이뤄져 실제 프로젝트와 테스트가 긴밀하게 연관해야겠다는 생각이 들었다.

1-3. 추후 공부 방향

Spring Security with JWT

실제 쇼핑몰이 서비스 되기 위해서는 서버 부하를 분산시키는 것이 중요하다는 생각이 들었지만 미처 적용하지 못했다. 여유가 된다면 JWT를 따로 학습하거나 기존 프로젝트에 추가해봐야겠다.

Spring Exception Handling

예외의 발생 시점이나 종류에 따라 처리해주는 위치가 다르다는 것을 알게 되었고 여러 핸들러를 프로젝트에 적용했지만 아직도 처리되지 않는 예외가 있다.

Vanilla JS 컴포넌트화, 클래스, IIFE

프로젝트 중 여러 js 파일을 동시에 사용하는 페이지에서 변수 중복 이슈가 간헐적으로 발생했고, 이전에 가볍게 배웠던 IIFE 나 클래스에 대한 내용이 다시금 떠올랐다. 기존에 사용했던 모듈들을 다시금 개선할 수 있도록 손 볼 예정이다.

2. 프로젝트 소개

2-1. 기본 정보

기간: 5주

참여 인원: 3인

환경:

Spring Framework 5.2.6

JDK 8u202

Maven 3.8.4

Server - CentOS8, Docker (20.10.11), Tomcat (8.5.69), MariaDB (latest), Nginx (latest), Jenkins (lts)

깃허브 리포: https://github.com/taedi90/yiTeamProject

2-2. 주제 선정 사유

프로젝트의 가장 큰 목적은 스프링 프레임워크의 다양한 기능과 구조를 파악하는 데에 목적을 두었고 쇼핑몰 은 CRUD 뿐만아니라 결제, 보안, 관리, UX 등 다양한 기능과 고려사항들을 학습하는데 도움이 될 것이라 판단했다. 사골과도 같은 주제라 인터넷에 관련된 자료가 많을 것이라는 판단도 중요하게 작용했지만 의외로 상세한 내용은 찾기가 어려워 DB 설계 시점부터 어려움이 있었다.

3. 프로젝트 진행

프로젝트는 다음과 같은 흐름으로 진행했다.

분석

주제 선정

협업 툴 선정

페이지 구상

가능 여부 검토(API존재 유무, 기간 내 구현 가능 여부)

코딩 컨벤션 정의

Git 활용 방법 및 전략 구상

설계

DB & 플로우 차트

구현 및 테스트

공유 함수 작성

JUnit 단위 테스트 작성(dto, mapper, service)

실제 구현

주 2~3회 회의 진행(진행사항 체크, 이슈 사항 공유)

4. 협업 툴 & 버전 관리 툴

프로젝트 간 사용했던 툴과 용도는 다음과 같다. 원래는 장황하게 찬양글을 작성했지만 잘 정리된 글들이 많을테니 생략하도록 하겠다.

Slack : 채팅 + Github & Notion 알림

Notion : 공지사항, 프로젝트 공유 및 이슈사항 정리

ERDcloud : 데이터베이스 설계과정 공유, 변경 이력, 채팅 및 메모 기능

Drawio : 플로우 차트를 작성하여 각 기능별 흐름 파악

Github : 프로젝트 버전 관리

5. Git 활용 전략

git을 개인적인 용도 외에는 사용해본 적이 없었기 때문에 초보에게 맞는 전략을 나름대로 구상해 보았다. 물론 혼자 생각한 건 아니고 여러 자료를 찾아보았으며 그 중에서도 한 해외 영상을 보고 적극 반영했다.

commit은 주제를 구분해서 작게 나눈다.

하나의 commit에 여러 변경점을 두는 것이 아니라 기능이나 논리적으로 구분이 가능할 수 있는 단위로 나누어서 commit을 진행해 의미있는 히스토리를 만드려고 노력했다.

branch는 오래 유지하지 않고 최대한 작은 단위로 병합과 re-branch를 반복

conflict가 발생하더라도 조기에 발견할 수 있으며, 서로 간의 호흡을 맞추기 위하여 기능을 작게 나누어 구현하고 master에 반영하였다.

~~master 에 한 번 merge 한 branch 는 더이상 쓰지 않는다!~~

물론 이후에는 이 규칙은 깨뜨렸다. 처음 사용할 때 혹시 모를 상황에 의연할 자신이 없어 불확실한 도전은 지양하였다. 이밖에도 제대로 알지 못하는 기능은 사용에 유의하였다.

commit 메세지는 꼼꼼하게 작성한다.

제목은 변화를 요약하여 이해하기 쉽게 작성하도록 노력했고, 내용은 이전과의 변경 사항, 변경이 발생 된 이유, 변경 후 유의할 사항 등을 작성해 팀원이 이해하기 쉽고 후에 히스토리를 관리하기도 편하도록 구성했다.

공유부분 수정은 rebase를 활용한다.

브랜치를 열어 기능개발을 하다 공통부분에 대한 수정이 필요할 경우, rebase를 적절히 사용하여 의미없는 커밋들이 증식되지 않도록 하였다. 단, 기존에 원격 저장소에 푸시 이력이 있는 브랜치는 rebase를 사용하지 않았다.

덕분인지 사용간에 큰 오류는 없었지만 한가지 실수한 점이 있었다. 여러 PC를 오가며 작업을 했었는데, 한 PC에서 git 환경설정을 제대로 하지 않아 2개의 메일주소로 commit이 발생해버렸다. 해결방법이 전혀 없는 것은 아닌 듯 했지만 자칫했다간 git 이력 전체를 날릴 위험이 있을 것 같아 그대로 두었지만 아쉬움이 남는다.

글이 길어져 페이지 구상, 코딩 컨벤션, DB & Flow Chart 등의 내용은 나누어서 작성하도록 하겠다.