프로젝트 개요
- 주제:
모임 중개 서비스
- 플랫폼:
데스크탑 웹 서비스
- 기간:
전체 기간: 19.11.12 ~ 20.02.12 (중단)
기획 및 서류 작성: 19.11.12 ~ 19.12.12
1차 개발 기간: 19.12.13 ~ 20.01.12
2차 개발 기간: 20.01.13 ~ 20.02.12
- 인원: 6명
- 🤚: PM
- 👩💻: PE, 소셜 로그인 API, 지도 API
- 👨💻: 이벤트 기본, 기타, 상태
- 👨💻: 회원 가입, 수정, 관리
- 👩💻: 이벤트 참가, 공지사항 관리
- 👩💻: 이벤트 문의, 후기
프로젝트 핵심 기능
- 소셜 로그인, 2단계 회원가입(선택정보)
- 관리자 회원 관리
- 공지사항 관리
- 이벤트 대시보드
- 이벤트 관리, 재개설, 조기 마감, 추가 모집
- 이벤트 문의, 후기
프로젝트 기술 스택
- 언어
- Java
- JavaScript
- HTML/CSS
- XML
- SQL
- JSP/Servlet
- 기술
- MyBatis
- AJAX
- JSON
- Spring Framework
- API
- Google Login
- kakao Login
- Kakao Maps
- 라이브러리
- Jackson
- commons-fileupload, commons-io
- javax.mail
- Spring Social, Spring Scheduler, Spring Security, Spring-AOP
- Gson
- JSTL
- jQuery
- Bootstrap
프로젝트 미리보기
서비스 스크린샷
서비스 아키텍처
서비스 ERD
프로젝트 문서
원래 Keep, Problem, Try를 돌아보던 방식과 달리 이번 프로젝트 회고는 복기하며 어떻게하면 상황이 달랐을 수 있을지에 대한 고민을 적으려고 한다.
욕심을 선택하다.
1. 팀
과정에 참여한 것은 취업을 위해서이고 이 프로젝트의 목적도 취업을 위한 포트폴리오였다. 이기적으로 생각하고 욕심을 가졌다면 혼자 프로젝트를 진행해도 이상하지 않았을 것이다. 하지만 나는 팀으로서 같이 성장하고 싶었고, 같이 과정동안 고생한 팀원들과 함께 잘 되었으면 했다. 그래서 선택을 해야했다. 목적이 명확하니 쉽게 결정할 수 있었팀과 프로젝트 중 팀을 선택했다. 다들 어려워하며 몰라서 불안해하는 마음을 해결책과 함께 다독이며 더 주도적으로 열심히 움직였다.
2. 프로젝트
학원에서 두 달, 따로 만나며 한 달, 각자 추가로 한 달 이렇게 총 4달 동안 진행된 프로젝트이다. 프로젝트 기획(요구사항) 및 설계 등 기반이 되는 문서 작업에만 한달을 몰두해 신경을 많이 썼다. 그만큼 기능을 구현하기 시작해서는 변동사항도 크게 없었다. Git을 사용할 줄 모르다보니 테스트가 완료된 기능을 합쳐가며 진행했다. 훈련이 종료가 된 이후에도 카페, 소호 사무실을 전전하며 다들 고생이 많았다. 하지만 결과적으로 프로젝트는 미완성으로 중단하기로 결정됐다. 이유는 데드라인을 지키지 못 하고 여러번 프로젝트 기간이 연장 되었기 때문이었다. 다들 취업이 급했는데 완성될 기미가 쉽게 보이지 않았다. 돌아보면 결국 내가 PM이었기 때문에, 내 책임이다. 욕심도 많았고 모두 최선을 다 해주었기 때문에 너무 아쉽고 속상하다.
다른 결과일 수 있었을까?
1. 도움의 범위
검색하거나 흔하게 찾아볼 수 있는 주제를 정말 싫어한다. 가급적이면 만드는 과정에서 결과물을 머리 속에 그리며 신이 날 수 있는 그런 주제를 찾고 싶어한다. 논의를 통해 흡사 SNS의 '공유 일기장' 서비스를 진행하려고 했는데 인원에 비해 스케일이 작다고 강사님께 동의를 받지 못 했다. 그래서 고민 끝에 결정된 주제가 '모임 중개 서비스'이다.
하지만 단순히 인원 수에 맞춰 스케일을 늘렸다 보니 팀원들이 자기 생각대로 쉽게 해결이 되지 않는 경우가 많았다. 알 수 없는 에러를 찾거나 실수들도 많았고 그런 디버그 과정에서도 시간을 많이 할애하게 되었다. 로직을 구성하거나 참조 자료를 찾지 못하여 곤란한 경우도 많아 내 담당 기능은 후 순위로 미루고 PM인 내가 이곳, 저곳 항상 바쁘게 뛰어다녔다.
그럼에도 WBS의 일정대로 진행되지 않은 경우가 다반사였고, 그게 쌓이다 보니 프로젝트 기간 자체를 기한안에 완성할 수 없었다. 연장을 하고 또 연장을 했는데도 추가적으로 연장이 필요해보였고 결국 중단하게 되었는데 촉박한 데드라인의 압박감 때문에 직접 해결해주는 경우도 많았다. 돌아보면 프로젝트의 완성, 미완성을 떠나 PM으로서 가장 후회되는 점이기도 하다. 만능 해결사같은 가이드 역할 보다는 길을 가다 가끔 만날 수 있는 안내표지판과 같은 역할을 지향했어야 그들의 성장에도 도움이 더 됐을 것이고 내 담당 기능들도 미완으로 남지 않았을 것이라는 아쉬움이 많이 든다.
2. 프로젝트 기간의 비율
훈련에서 강사님의 말씀중 "현업의 절반 이상은 문서작업이다." 라는 자주 하셨다. 그래서 다양한 문서들을 제대로 경험해보는 것을 중요하게 생각했었다. 그리고 만약 과정 기간(2달) 안에 끝내지 못 하게 되더라도 도움이 될거라는 생각이었다. 하지만 지금 결과적으로 보면 정작 중요한 프로젝트의 개발을 끝내 마무리 못했다.
원래 개발 기간의 절반을 할애하는 동안에 기능 구현의 지체를 예상하지 못 한 전략 미스였다. 더 여유 있게 비율을 두고 퀄리티를 낮추는 선택이 필요했어 보인다. 링크된 글의 필자는 소프트웨어 디자인과 기획에 30%, 실제 개발에 50%, 테스트에 20%를 투여하는 것을 프로젝트의 기준을 세우는 원칙으로 정하셨다고 한다. 또한, 테스트 코드에 관해서도 자세히 배우지 못 했고 비중있게 생각하지 못 했는데 너무 아쉽다.
3. 미숙한 개발자 준비생
내가 또 간과한 것이 다들 각자 자기 자신의 역량 잘 파악 하지 못 할 것이라는 것을 생각 못 했다. 그래서 담당 기능을 분배할 때 1차적으로 팀원 별로 잘 할 것 같은 기능을 나누고, 2차적으로 해당 팀원의 의견에 비중을 두었다. 그리고 그 담당 기능에 대해서는 변동이 없었다. 모두 수강생의 입장에서 함께 고생하며 최선을 다 했음은 변하지 않는다. 그렇다면 PM인 나의 책임인데, 만약 잦은 중간 정검을 통해 담당 기능을 과감하게 조정하는 선택을 했었더라면 더 나앗을 것이라고 생각된다. 담당 기능이 변경되는 일이 담당 팀원에게 상처가 될 것이라고 생각했었는데, 오히려 부담감과 함께 더 미안함을 가중시킨 것 같다.
마치며
고생은 참 많이하고 자랑할 수 있는 로직이나 코드가 많이 없는게 너무 아쉽게 생각한다. 또한, 가끔 속으로 팀원을 원망하기도 했지만, 결국 "프로젝트의 실패는 PM의 책임이다."라는 말이 있듯이 PM으로서 나의 부족함도 많았다. 이번 프로젝트를 통해 개발자들과 협업을 위해 PM, 팀원으로서 어떻게 나아가야할지에 대한 방향이 이 회고에 적힌 것 같다. "프로젝트는 실패였지만 커리어의 실패는 아니었다." 라는 말이 가장 크게 새겨질 것 같다.
