BEYOND SW 캠프 15기 22주차 회고

부트캠프 22주차 회고를 적어본다. 전체 일정의 $\dfrac{1}{6}$만을 남겨두고 있다. 출석일 또한 곧 세 자리수로 바뀌게 된다.

최종 프로젝트

이번 주는 지난 주에 이어서 본격적으로 백엔드 개발을 진행하였다.

필자는 근태 관리, 관리자에 의한 사원 관리 기능의 개발을 맡았다. 이 중 근태 관리 부분은 결재 로직이 완성된 이후 검증 예정이지만 얼추 완성된 상태이고, 현재는 사원 관리 기능 개발을 진행 중이다.

멘토링

이번 월요일에는 멘토님께 개발 진행 상황을 공유드리고, 기획에서 수정된 부분을 전달드렸다. 이후 팀원으로부터 이력서 및 포트폴리오 준비에 대한 질문을 받아, 몇 가지 조언을 해주셨다.
오는 월요일에는 이력서, 포트폴리오 작성에 대한 1:1 멘토링을 진행하기로 했다. 유익한 시간이 될 수 있도록 주말동안 자료를 잘 준비해야겠다.

배운 점

1. 근태 관리 기능의 복잡성

근태 관리 기능의 구현을 위해 출근, 퇴근 등록 및 휴가, 출장 승인 시 work 테이블을 어떻게 관리할 지에 대해 고민하며 이를 코드로 작성하였다. 머릿속으로 로직을 정리하는 것은 크게 어렵지 않았지만, 막상 코드로 작성하려니 꽤 복잡했다.
필자는 유지보수성을 중요하게 생각하여 메서드 분리를 하며 개발을 진행했는데, 검증 로직이 많다보니 출근 등록 기능 하나만 해도 서비스 코드가 약 300줄 정도 되었다. 이 상태로 두면 나중에 수정이 필요할 때 유지보수가 어렵겠다고 판단하여, 책임에 따라 서비스 및 검증 클래스 여럿으로 분리하는 리팩토링을 진행하였다.
시차 출퇴근제, 유연 근무제 등 다양한 근무 형태나 반반차, 시간 연차 등 다양한 연차 형태는 주어진 시간 내에 구현하기에 어려움이 있다고 판단하였다.
최대한 유연하면서도 고려해야 할 법적 기준을 많이 반영하되, 어느 정도는 타협하여 단순화한 형태로 구현하였다. 시간이 된다면 보다 많은 기능을 제공하는 방법에 대해 고민해 봐야겠다.

2. DTO의 책임 분리

이번 프로젝트의 백엔드 개발을 시작하기 전에 팀원들과 어떤 구조로 작업을 진행할 지 논의하였다. 주로 다음과 같은 부분이었다.

1. MyBatis 사용 여부
2. 패키지 구조 (일반 layer 구조, CQRS 패턴 등)
3. JPA에서 연관 관계 매핑 사용 여부

백엔드 프로젝트에서는 강사님께서 지정해 주신대로 command에 JPA, query에 MyBatis를 사용하는 CQRS 패턴을 사용하였고, 지난 데브옵스 프로젝트에서는 JPA만 사용하는 layer 구조를 사용하였다.
논의 결과, 지난 백엔드 프로젝트와 동일한 구조를 사용하기로 결정하였다.

그리고 조회 기능을 개발한 후 PR을 올렸는데, 팀원으로부터 다음과 같은 리뷰를 받았다.

좀 더 알아보니 계층 책임 분리 차원에서 request 객체와 mapper 통신용 dto는 분리해두는 것이 유지보수성을 위해 좋다고 하여, 해당 내용을 반영하였다.

PS) 회고를 쓰다가 위에서 불필요한 import 구문을 삭제하지 않았음을 발견하였다. IntelliJ가 아래와 같이 import 구문을 숨겨주다 보니 당시에는 발견하지 못했다. 리팩토링 PR을 올려야겠다.

관련 코드에서 request 객체의 값을 가공해서 sql 쿼리에 보내는 작업 또한 필요했는데, 서비스에서 request 객체를 가공하는 대신 mapper 통신용 DTO에 가공된 값을 보내주는 형태로 코드를 작성하니 흐름이 더 명확해졌다. 빠른 개발이 중요한 작은 프로젝트라면 request 객체로 직접 통신할 수도 있겠지만, mapper용 DTO를 분리하는 건 좋은 개발 방법임을 몸소 느낄 수 있었다.

문제 상황

이번 프로젝트를 진행하며 겪은 문제 상황을 공유해본다.

MyBatis query was empty 에러

• 설명: Postman으로 요청을 보냈을 때, 아래와 같이 query was empty 에러 메시지가 확인되었다.
  
• 원인: 목록 조회 쿼리 작성 후 페이징 처리용 count 쿼리도 함께 작성해야 했는데, 아래 사진과 같이 쿼리에 아무 것도 입력하지 않아서 발생한 문제였다.
  
• 해결 방법: count 쿼리를 작성한 이후 해당 문제가 해결되었다.

단순한 실수이지만 처음 보는 에러 메시지라 당황했고, 디버깅이 꽤 오래걸렸기에 기록으로 남긴다. 이 외에도 MyBatis를 사용하며 다음과 같은 실수에 유의해야 했다.

1. 명명 규칙
   Java에서는 주로 lowerCamelCase를, DB에서는 snake_case를 사용한다. 하나의 MyBatis 쿼리 안에서도 아래와 같이 잘 구별해서 사용해야 한다.

• DTO 매핑이 필요한 부분(deptName, positionName 등)
• 쿼리 부분(emp_id, emp_no 등)

특히, JPA와 MyBatis를 함께 사용하는 경우, JPA는 camelCase를 사용하므로 혼동하지 않도록 각별히 유의해야 한다.

2. SQL 구문 실수
   개발자 최대의 적인 오타, 쉼표(,) 누락 등에 유의해야 한다.

느낀 점

1. 지난 백엔드 프로젝트에서는 구현에 급급해서 유지보수성 좋은 구조에 대해 고민할 틈이 없었는데, 이번에는 구조에 대한 고민도 해보고 메서드 분리도 신경쓰며 개발을 진행할 수 있게 된 걸 보니 그동안 경험을 쌓으며 많이 성장했음을 느낀다. 아직 갈 길이 멀지만 지금처럼 꾸준히 열심히 해봐야겠다.
2. 그동안 주로 Postman으로 테스트를 진행했다보니 테스트 코드 작성이 아직 좀 낯설다. 기능 구현을 우선으로 하되, 시간이 된다면 테스트 코드 작성에도 신경 써서 이번 기회에 잘 배워가야겠다.