깃허브 레포지토리 https://github.com/phdljr/Hotel
서문
자바로 팀 프로젝트를 진행하는 시간을 갖게 되었고, 성공적으로 마무리를 지을 수 있었다. 이러한 경험을 토대로 KPT 회고를 작성하려 한다.
KPT 회고란 Keep, Problem, Try의 약자로 회고 방법 중 하나라고 한다.
- Keep은 좋았거나 계속 이어갔으면 하는 부분
- Problem은 부족했거나 개선이 필요한 부분
- Try는 어떻게 개선할 것인지에 대한 부분
KPT를 진행하기 전에 나의 느낀 점
다른 프레임워크나 라이브러리에 의존하지 않고 오직 자바로만 프로젝트를 진행하게 되었다. 요구사항을 처음 봤을 땐 쉽게 느껴졌고 애들 장난처럼 느껴지는 프로젝트였지만, 생각보다 많은 작업량이었고 고민할 부분도 많았다. 또한 팀원들과 협업하는 것이다 보니 혼자서 작업하는 것과는 느낌이 많이 달랐다.
주어진 요구사항대로 설계를 진행해 보며 프로젝트 구조는 어떻게 설계할 것인지, UI는 어떻게 할 것인지, 깃허브는 어떻게 사용할 것인지 등 처음부터 끝까지 팀원들과 항상 함께 진행하였으며 많은 고생을 하였다. 노션과 피그마를 통해 기초 설계와 UI 설계를 진행해 보았고, 구조는 스프링을 사용했을 때처럼 MVC 패턴으로 진행해 보기로 하였다.
여태까지 계속 스프링 프레임워크에 의존하다 보니, 프레임워크가 없는 상태에서 구현하는 것이 조금 낯설게 느꼈다. 그러한 도구 없이 MVC 패턴 구조로 설계를 진행하며 나아가 보니 스프링이 개발자에게 많은 도움을 준다는 것 또한 느꼈다.
구현을 다 했을 땐, 마치 스프링을 사용하는듯한 구조가 보였으며 유지 보수하기 좋은 형태가 된 것 같았다. 각각의 클래스는 하나의 역할만 책임지는 형태였으며(SRP, Single Responsibility Principle)데이터베이스같은 클래스는 싱글톤 패턴을 적용하였다. 출력단은 웹 프로젝트에서 html을 사용하는듯한 느낌으로 클래스를 작성하였다. 단순히 데이터를 인자 값으로 전달받아 출력하는 역할이 끝이다. 출력시킬 데이터는 서비스단에서 가공시켜서 출력단으로 값을 반환시키는 역할이 전부였다.
데이터를 가져오고 이를 출력단으로 전달시키는 과정에서, 이 부분을 어떻게 해결해 나아가야 할지 고민이 많았다. 마치 스프링의 Dispatcher Servlet을 구현하는 듯한 느낌이 들었다. 그렇게 우리는 HotelLounge라는 클래스를 만들어, 마치 컨트롤러와 비슷한 역할을 갖도록 설계하여 개발을 진행하게 되었다.
결과는 만족스러웠다. 구조가 기능별로, 클래스 별로 나뉘다 보니 팀원들과 역할을 분배할 때도 유연했으며, 구현할 때 코드가 겹치는 부분도 많이 없어서 깃허브로 협업할 때 충돌 문제가 별로 없었다. 또한, 마무리 작업으로 리펙토링을 진행하였는데도 용이했다.
한 가지 아쉬웠던 점은, 테스트 코드가 적용되지 않은 부분이다. 테스트 케이스를 미리 작성하여 개발하는 방식인 TDD를 적용해 보았다면, 좀 더 좋은 경험이 되지 않았을까 싶다. 또한, Github Actions처럼 CI/CD를 적용해 보면 더 나은 협업 환경이 될 것 같았다. 다음 프로젝트 때는 무조건 이를 먼저 적용하고 개발을 진행하면 어떨까 싶다.
다음으로, 팀 프로젝트를 진행하며 느꼈던 점들을 KPT로 정리하려고 한다.
Keep
- 프로젝트 진행에 있어 다들 적극적이어서, 어려운 부분도 잘 도움 받았고, 좋은 정보도 공유하며 수월하게 마무리된 점이 아주 상당히 좋았습니다.
- 소통이 원활하고 적극적이며 분위기가 좋았다. 새로운 의견을 제안하면 팀원들도 적극적으로 의견을 내고 생각을 공유하는 시간을 종종 갖게 되어서 개발하는데 큰 도움이 되었다.
- 프로젝트 동안 활발한 소통을 통해 문제를 해결할 수 있었음
- 문득 떠오르는 아이디어나 의문점 등을 기록해서 이후에 놓치지 않고 고려할 수 있었음
- 팀원들의 지식 공유로 많이 배워갈 수 있는 환경이 좋았음
- 팀 프로젝트에서 처음 시도해보는 것들이 많았을텐데 팀원들이 잘 따라와줘서 다행이라고 생각함
Problem
- 개인적으로 개념적인 부분이 많이 모자르고 헷갈려 코드작성하는데 어려움이 많았습니다. 팀원들의 도움을 받아 잘 해결되었지만, 혼자서도 문제없이 작성할 수 있도록 많은 학습이 필요하다고 느낍니다.
- Git에 대한 성숙도가 부족해서 약간의 두려움이 존재했다. 협업하는데 큰 문제는 없었지만, 다양한 기능을 적극적으로 활용했으면 더 좋은 협업 경험이 되지 않았을까싶다.
- 각자 맡은 기능을 구현하는 과정에서 테스트하기 어려움
- 깃허브에 PR을 올릴 때 맡은 역할 전체를 다 완성한 뒤 올림
- 개인 일정이나 면담으로 매일 진행되는 회의나 회고가 제시간에 진행하기 어려웠음
Try
- 이번 프로젝트를 다시금 뜯어보며 아직도 모르거나 헷갈리는 부분들을 취합해 추가로 공부해야겠습니다.
- Github Actions를 통한 자동 테스트 과정을 추가한다면, 브랜치를 합칠 때 마다 오류를 검사할 수 있어서 편할 것 같다.
- 작은 기능을 구현할 때마다 올려서 다른 팀원들에게 진행 상황을 공유할 수 있도록 노력
- 프로젝트 진행중에는 스크럼을 진행해서 본인이 진행했던 내용을 자세하게 공유할 수 있으면 좋을 것 같음
마무리
자바 프로그래밍은 스프링이 전부가 아니며, 이는 하나의 도구일 뿐이라는 사실이 프로젝트를 진행하며 크게 와닿았다. 즉, 설계의 중요성을 크게 느끼게 되었다. 여태 너무 스프링에 의존하다 보니 소프트웨어 설계의 본질을 잠깐 잊은 듯하였다.
또한, Github의 PR을 통해 기능도 합쳐보고 코드 리뷰도 받아보니 다양한 개발 시각을 얻게 된 듯 하다. 혼자서 생각하며 좋은 것이라 판단했던 것이, 팀원들과 공유하며 의견을 나눠보니 그리 좋지 않았던 것과 더 나은 의견이 있다는 사실 또한 느꼈다.
이번 프로젝트를 통해 중요한 사실을 되찾는 시간이 되었으며, 소프트웨어의 더 나은 구조와 개발 방법에는 어떤 것이 있는지 다시 알아보게 되는 시간을 가져보려 한다.
(Clean Architecture와 TDD 책을 읽어보려 한다.)
