스프링으로 팀 프로젝트를 진행하는 시간을 갖게 되었고, 성공적으로 마무리를 지을 수 있었다. 이러한 경험을 토대로 KPT 회고를 작성하려 한다.
KPT
회고란 Keep, Problem, Try의 약자로 회고 방법 중 하나라고 한다.
Keep
은 좋았거나 계속 이어갔으면 하는 부분
Problem
은 부족했거나 개선이 필요한 부분
Try
는 어떻게 개선할 것인지에 대한 부분
주어진 시간은 주말을 포함해서 6일이었지만, 저번 팀 프로젝트와 마찬가지로 주어진 요구사항은 절대로 6일 안으로 다 구현하지 못할 양이었다. 필수 요구사항만 먼저 구현하고 나머지 요구사항을 추가하는 방식으로 진행했어야 했지만, 욕심이 불타오른 나머지, 다 구현하겠다는 다짐을 하고 팀원들과 설계에 들어갔었다.
매번 게시판을 주제로 프로젝트를 진행하다보니 이번에는 키오스크로 주제를 바꿔서 진행하게 되었다. 확실히, 게시판과는 달리 새로운 여러 도메인들이 도출되었고 이들간에 연관관계를 생각하는 부분에서 시간이 많이 걸렸다. 그래도, 구현 단계에서 고생하는 것보단, 설계 단계에서 최대한 오류를 잡고 시작하는 것이 시간적인 측면에선 이득을 볼 수 있을거라 생각하며 끝까지 세세하게 진행하였다.
물론, 구현 단계에서도 살짝 수정된 부분이 있었지만, 설계가 잘 돼있어서 많은 시간을 들이진 않았다. 여기서 설계의 중요성을 느끼게 되었다.
설계를 다 하고 구현에 들어가기 전에, 팀원들과 github 컨벤션을 정하게 되었다. 여기서 커밋 메세지와 브랜치 전략, 그리고 Issue와 PR을 같이 써보는 기능도 활용해보는 기회를 가지게 되었다.
이번 프로젝트에선 저번 프로젝트때 구현하지 못한 기능들을 추가하기 위해 노력했던 것 같았다. 그렇게 Refresh Token
과 이메일 인증 기능
을 구현하게 됐다. 이를 이해하고 사용할 줄 안다면 다른 프로젝트에서 재활용될 가능성이 매우 높아보였다. 필자가 구현한 부분은 아니라서, 이를 재활용 한다면 코드를 다시 한 번 보면서 이해할 필요가 있어보였다.
소셜 로그인이랑 AWS EC2의 배포, HTTPS 설정은 진행하지 못하였지만, 좀 더 공부해서 다음 기회에 적용해보는 시간을 가져보도록 다짐하게 되었다. 특히, AWS EC2에 배포를 하려 했으나, EC2와 RDS가 서로간에 연결이 잘 되지 않아서 삽질하다가 결국 구현하지 못하였다. 각각의 서비스에 대해 좀 더 알아보고 적용해보는 시간을 가졌으면한다.
다음으로, 팀원들과의 KPT 내용을 적어본다.
Refresh Token과 Redis, 이메일 인증 기능에 대해 알아보는 시간을 갖게 되어 좋았다.
또한, 깃허브의 다양한 기능을 사용하게 돼서 많은 걸 배우게 되었다.
다음 프로젝트때는 시간을 전략적으로 사용해서 배포까지 진행해보자.