국비학원 파이널프로젝트, 인원은 총 5명이다. 나는 각자 도메인만 맡아서 하면 잘 될거라고 막연히 생각했었다. 그러나 생각보다 유기적인 연결성과 코드스타일의 통일성이 부족했다. 나 또한 그것에 일조한 셈이다. 나는 postmortem 하고자 한다.

클라이언트와 API의 패키지가 분리되지 않아 계층 분리가 잘 되지 않았다.
중복된 영역을 다루는API가 발생했다. 공통으로 사용하는 기능을 원자화하여 재사용성을 높였으면 좋았을 것 같다. [EmpService.java] ,[EmployeeApiService.java] , [FranchiseBranchService.java] , [BranchApiService.java].
패키지 구조, 공통 API 대한 소통이 부족했다고 생각했다. 이것을 나중에서야 깨달았고 프로젝트가 반이상 진행중인 상황에서 구조에 대한 역설을 할 여력이 부족했다. 팀원들을 설득하는 것이 어렵다고 판단했기 때문이다. 난 팀원들이 프로젝트 구조에 대해 이해하지 못한다고 생각했고 이것에 대해 설명해야하는 것이 어려웠다. 왜냐하면 그것 외로 내가 프로젝트 전반으로 우선순위를 가지고 집중해야할 일이 많았기 때문이었다. 뒤늦게 깨달은 것이지만 전체적인 프로젝트 진도가 1주일 정도 늦어지더라도, 내가 내가 맡은 도메인을 거의 코딩을 못하더라도 해당 구조는 잡고 들어가는 것이 좋은 선택이었다고 후회가 든다. 다음부터는 이런 부분에 좀 더 집중하고자 한다.

로그인 세션관리는 통일된 클래스로 바꾸면 좋지 않았을까 생각
그 밖에 에러페이지처리, enum, 페이지네이션 등 공통으로 사용될 후보 API도 아쉬움
주도적인 소통부족. 다른 팀원이 막연히 로그인 기능을 총괄하고 API를 제공할 것이라고 생각했다. 하지만 팀원은 기대했던 것보다 로컬 변수로 세션체크를 하여 로그인 여부를 판단하는 방식을 사용했다. 그런 코드는 재사용이 불가능하기 때문에 나는 우선 분리가 가능한 직원 로그인 기능만 이관하여 공통의 접근제어 API로 만들었다. 좀 더 열띈 토론을 통해 공통기능을 되도록 함께 만들도록 했어야 했는데 팀원들이 다들 학원에서 배운 해당 방식만을 알고 있어서 내가 나서서 이렇게 하자고 하는게 조금 어려웠다. 적어도 직원 로그인 쪽 만큼만 내가 받아서 관리했다. 아쉽지만 다음에는 좀더 주도적으로 해야겠다고 생각한다.

유효성 검사의 경우 나는 커스텀 애노테이션과 validator를 사용해서 서버단에서 검사를 했다. 팀원 3명은 클라이언트 단 유효성 검사를 했다. 프로젝트가 끝나고 내가 앞선 기술, 팀원이 모르는 기술을 먼저 도입하기 전에 팀원들에게 얘기하거나 팀원들의 지식 수준으로 할 수 있도록 내 구현기술 수준을 낮춰야 했다고 생각했다. 각자의 속력차이를 배려하지 못한 잘못이었다.

코드리뷰에서 했던 얘기