[회고] SSAFY 2학기 공통 프로젝트를 마치며...(feat.최우수상)

안녕하세요
데브당에입니다

몇주간 프로젝트에 올인하다보니 블로그에 포스팅을 하지 못했네요.
드디어 지난주 금요일 프로젝트를 성공적(?)으로 마쳐 회고를 작성해보려합니다.

사실 회고를 처음 작성해보기 때문에 구글링을 통해 알아본 회고방법인 KPT를 적용하여 회고를 작성하려 합니다.

들어가며

올해 1월 10일부터 2월 18일까지 DrawingDream 이라는 프로젝트를 진행했습니다.
Drawing Dream은 등교부터 하교까지 함께하는 WebRTC를 적용한 비대면 통합 교육 웹 서비스로 SSAFY 2학기 첫번째 공통프로젝트였습니다. 저는 이번 프로젝트에서 Back-End를 맡았으며 프로젝트에 대한 자세한 내용은 아래 GitHub를 참고해주시기 바랍니다.

GitHub - dayaeLee777/DrawingDream: 💫 세상에서 가장 편한 학교, Drawing Dream 에서 여러분의 꿈을 그려 보

Keep

1. Git, Coding 컨벤션 작성
프로젝트를 진행하기에 앞서 Git, Coding 컨벤션을 미리 작성해두었습니다.
Git의 경우에는, branch와 commit message 컨벤션을 사전에 정해두었습니다. 저희는 팀원이 6명이었기 때문에 Git-Flow 전략을 적용하여 필요에 따라 master-develop-feature-release 브랜치를 생성하여 프로젝트를 진행했습니다. 이로써 기능별로 명확하게 역할분담을 하여 프로젝트 개발을 진행할 수 있었습니다. 또한, Git commit message 컨벤션을 미리 작성해두었기에 commit message을 보고 다른 팀원의 작업 현황도 손쉽게 파악할 수 있었습니다.
Coding 컨벤션은 백엔드, 프론트엔드별로 네이밍 컨벤션을 작성했습니다. 상황에 따라 Pascal, Camel, Snake Case 등의 네이밍 규칙을 미리 설정해두어 프로젝트를 진행하면서 코드의 통일성을 유지하고 가독성을 높일 수 있었습니다.

2. DB 설계 시, 공통코드 적용
Drawing Dream이 비대면 통합 교육 서비스라는 특성 상, DB 내부적으로 많은 테이블이 존재했고 이들간에 복잡한 연관관계가 존재했습니다. DB를 더 효율적으로 관리하기 위해 데이터를 한 곳에 모아 관리할 수 있는 공통코드를 적용했습니다. 여러 테이블에서 반복적으로 사용되는 학년, 반, 학교구분, 교과목 등을 공통코드로 분류하였습니다. 따라서 공통코드를 사용해야하는 테이블에서는 별도 테이블간의 매핑없이 공통코드만을 불러올 수 있게 되었습니다. 또한 Spring 프로젝트에서는 공통코드를 enum 타입으로 작성하여 코드의 가독성을 높이고 타입 안정성을 확보할 수 있었습니다.

3. JIRA, Mattermost를 통한 협업관리
JIRA는 프로젝트 관리 툴로 팀원간에 프로젝트 진행현황을 손쉽게 파악할 수 있고 관리할 수 있게 합니다. 이번 프로젝트를 진행하면서 처음 사용해보았는데 에픽, 스토리, 스프린트를 생성하면서 프로젝트의 목표를 설정할 수 있고 프로젝트의 진행상황을 한 눈에 알아볼 수 있어 많은 도움이 되었습니다. 처음에는 스프린트를 시작한 후에도 해야할 작업이 생겨서 에픽을 추가, 추가, 추가하거나 스프린트 내에 작업을 완료하지 못해 다음 스프린트로 미루게 되는 일이 빈번했습니다. 하지만 프로젝트가 후반으로 갈수록 팀원들이 프로젝트와 지라에 익숙해져(?) 스프린트의 번다운 차트가 아름답게 그려지는 모습을 볼 수 있었습니다.
또한, 저희는 프로젝트 기간동안 Mattermost라는 커뮤니케이션 SW를 활용하여 소통을 했습니다. 컨설턴트님과 코치님께서 Mattermost를 카톡처럼 이용한다며 칭찬(?)을 하셨는데.. 사실 저는 모든팀이 그러는 줄 알았습니다..ㅎㅎ 팀 내부적으로 지속적인 소통이 이루어졌기 때문에 프로젝트에도 좋은 결과가 있었던 것 같습니다.

Problem

1. REST API를 위한 코드 통일
Keep 부분에 작성했듯이 Coding 컨벤션은 네이밍 규칙으로 한정되어 있었으며 네이밍을 제외한 부분에 대한 컨벤션을 미리 설정해두지 않았습니다. 이로써 REST API를 작성하면서 팀원간의 코딩 스타일이 다르게 나타나 코드의 통일성이 저하되고 말았습니다. 특히, JPA를 적용하여 Optional을 처리하는 부분에서 get, orElse, orElseThrow 등 팀원마다 다른 처리방식을 선택했고 이에 따라 예외처리도 다르게 나타날 수 밖에 없었습니다. 물론 다른 팀원의 코드를 보며 새로운 코딩 스타일을 공유할 수 있었지만, 기능별로 코드 형태가 달라져 아쉬움이 남게 되었습니다.

2. 코드 리뷰의 부재(?)
프로젝트의 기간은 짧고, 작업볼륨은 크다는 핑계로 Merge Request 시 피드백을 주고 받을 수 있는 코드리뷰 과정을 생략했습니다. 이로써 각자 개발한 기능에 대해서는 정확한 플로우를 알 수 있었지만 다른 팀원이 개발한 기능의 로직은 이해하기에 어려움이 있었습니다. 개개인이 새롭게 공부해가며 적용한 기술이 많았기 때문에 코드 리뷰를 바탕으로 한 지식공유가 있었다면 서로에게 발전적인 시너지 효과가 있지 않았을까 생각합니다.

3. WebRTC 로컬 환경 VS 서버 환경
저희는 개발 중간단계에 CI/CD 환경을 구축했지만, 기능 구현시 테스트 과정의 불편함을 최소화하기 위해 대부분의 기능구현이 완성되기 전까지는 로컬환경에서 테스트 및 개발을 진행했습니다. 프로젝트가 마무리 되어가는 시점에서 로컬에서는 분명히 정상적으로 동작했던 Kurento 화상 기능이 서버에서는 동작하지 않는 이슈를 발견했습니다. 로컬에서는 정상적으로 동작하였기 때문에 서버 환경설정의 문제라고 생각하여 오랜시간 동안 Nginx, Docker, Kurento Media Server를 확인했습니다. 하지만 재차 확인해보니 화상기능이 동작하지 않은 이유는 화면공유 기능을 추가하면서 작성된 JS 코드에서 버그가 발생한 것이었습니다. 이로써 버그는 해결할 수 있었지만 프로젝트 막바지에 발생한 주요기능 버그로 팀원 모두 새벽까지 고생했던 것이 기억에 남습니다. 만약 CI/CD를 중간단계에 적용했더라면 적기에 오류를 발견하여 빠르게 버그 수정을 할 수 있었을거라는 생각을 했습니다.

Try

1. 코드 리뷰
MR 혹은 스크럼 미팅 시, 코드리뷰 시간을 갖는다면 개발에 있어 확장된 시각을 갖을 수 있을거라고 생각합니다. 위에서 말씀드렸다시피, 저희는 개발을 빠르게 진행해야하다보니 코드리뷰의 시간을 갖는데는 무리가 있었습니다. 다음 프로젝트에서는 코드리뷰를 진행하면서 함께 작성된 코드에 대해 의견을 나누고자 합니다.

2. CI/CD 적용
Problem에서 보셨다시피, 저희는 CI/CD 적용시기를 늦추어 버그 해결에 문제를 겪은 경험이 있습니다. 이에 앞으로의 프로젝트에는 기본 기능이 구현된 후에는 CI/CD를 적용하여 버그를 신속하게 발견하여 해결하고 SW의 품질개선에 집중하고자 합니다. 프로젝트 진행 간에 각 일련의 과정이 존재하고 여기에는 적기에 적용하여 프로젝트 구현의 효율을 높일 수 있으면 좋겠습니다!

마치며

7주간 이번 프로젝트를 진행하면서 SSAFY 1학기(6개월) 동안 배운 내용보다 어떻게 보면 더 많은 것을 배울 수 있었던 것 같습니다. 새로운 기술을 적용해 보았고 협업 방법에 대해 알아갈 수 있었습니다. 특히 이번 프로젝트에서는 컨설턴트님, 코치님의 지도로 프로젝트를 보다 현업과 비슷하게 진행해갈 수 있었으며, 팀워크와 팀내 커뮤니케이션이 원활게 이루어져 프로젝트 즐겁고 성공적(?)으로 진행할 수 있었던 것 같습니다. 컨설턴트님, 코치님, 팀원분들 감사한 분들이 많네요 ㅎㅎ 이번 프로젝트를 발판삼아 앞으로도 많은 사람들이 편리하게 사용할 수 있는 프로젝트를 구현하고 싶습니다!