221226~230101 WIL

이번 주 한 일, 배운 것 

항해 7주차 클론 프로젝트 마무리

마지막 미니 프로젝트인 클론 프로젝트가 끝났다. 이번 주에는 팀원 중 한 분이 인프라와 관련된 대부분의 작업을 끝내 주셨기에 서비스 로직과 Spring Security 작업에 좀 더 집중할 수 있었다. 

 

이 글에서는 이번 주 프로젝트를 하면서 느끼거나 배웠던 점을 적어보려 한다.

 

1. CI/CD

 

이번 주에 처음으로 CI/CD를 직접 접해봤다. 내가 직접 설정한 건 아니었고, 다른 팀원 분이 설정해 준 CI/CD였다.

 

직접 사용해보니 왜 CI/CD를 그렇게 강조하는 지 알 수 있었다.

 

CI를 통해 develop 브랜치의 안정성을 보장해 주었고, 종종 일어나는 휴먼 에러를 줄여 주었다.

 

그리고 CD 덕분에 팀원들 모두 서비스 로직에 집중할 수 있었다. 지난 주차에는 서버, 배포로 대부분의 시간을 보냈었는데, 이번 주에는 CD가 완료된 후에 그 쪽에 신경을 끌 수 있었다. 그래서 체감상 업무 효율이 몇 배는 증가한 것처럼 느껴졌다.

 

그래서 이번 실전 프로젝트에서도 초반에 가벼운 CI/CD를 적용하고 시작하려고 한다.

 

2. Service Util 클래스

 

이번 주에 서비스 로직을 구현하면서 ServiceUtil 이라는 클래스를 만들게 되었다. 이 클래스는 서비스 로직들에서 공통적으로 사용되는 메소드들을 모아둔 클래스이다.

 

반복되는 메소드의 사용을 줄이고자 만든 클래스 였는데, 생각보다 장점이 많았다.

 

우선 서비스 로직의 코드가 전반적으로 깔끔해졌다. ServiceUtil 클래스에 들어가는 메소드들은 보통 데이터베이스를 조회하는 메소드들이었는데, 이 반복되는 부분을 메소드 하나로 바꿀 수 있어서 코드들의 가독성이 많이 올라갔다.

 

그리고 생각지도 못한 장점이 있었다. 바로 의존성 분리였다.

 

서비스 규모가 커질수록 점점 한 서비스에서 여러 Repository에 의존해야 하는 상황이 생겼다. 이번에 진행했던 프로젝트는 그리 큰 규모가 아니었음에도 한 서비스에서 4개의 Repository에 의존해야 하는 경우도 있었다.

 

그런데 ServiceUtil 클래스를 쓰면 각 서비스에서 웬만한 Repository에 대한 의존성을 끊어줄 수 있었다. 이건 유지 보수를 할 때 굉장히 큰 장점으로 와닿을 것이라 생각한다.

 

다만 Static 메소드로는 사용할 수 없다. Static 메소드는 Static 필드만 사용할 수 있는데, 그러면 의존성 주입 때 Repository를 주입 받을 수 없기 때문이다. 이 부분은 스프링의 DI를 좀 더 자세히 이해하게 되어야 정리할 수 있을 것 같다.

 

3. Mapper 클래스

 

프로젝트 중간에 담임 매니저님이 Mapper를 쓰는 이유에 대해 물어봤었다. 원래 나는 Mapper를 사용하는 이유를 알고 있었다고 생각했는데, 정작 질문을 받고 대답을 하려 하니 쉽게 설명할 수가 없었다.

 

즉, 나는 Mapper 클래스의 장단점을 전혀 모르면서 알고 있다고 착각하고 있던 상태였다. 이건 아예 모르는 것 보다 더 위험하다. 내가 모르는 걸 알고 있으면 나중에 찾아볼 생각을 하게 되는데, 이 경우는 나중에 찾아볼 생각을 안하기 때문이다.

 

부끄럽지만, 나는 아직도 Mapper의 장단점을 모른다. 하지만 이번 실전 프로젝트에서 본격적으로 개발을 시작하기 전에는 그 내용을 찾아서 정리하고, 팀원들과 공유한 다음 사용할 지 말지 결정할 것이다.

 

실전 프로젝트 시작

아직 실전 프로젝트를 시작한 지 며칠 안되었지만, 몇 가지 느낀점이 있어서 그 부분을 적어보고자 한다.

 

1. 의견 조율

 

실전 프로젝트에는 디자이너분이 합류하신다. 관점이 서로 다를거라 예상은 했지만 생각보다 훨씬 달랐다. 무엇보다 서로의 상황을 이해시키고 모두가 만족할 만한 합의를 이끌어 내는 것이 정말 어려웠다.

 

그나마 백엔드와 프론트는 둘 다 '개발' 이라는 공통 분모가 있어서 수월했지만, 디자이너님께 우리의 상황과 생각을 전달하는 것은 생각했던 것보다 훨씬 어려웠다.

 

그리고 이 과정에서 왜 다른 팀과 소통할 수 있는 리더의 역할이 중요한 지 약간이나마 느낄 수 있었던 것 같다. 지금은 겨우 디자이너 한 분이지만, 회사의 규모가 커지면 커질 수록 내가 소통해야 될 팀들은 정말 다양해질 것이다. 그런데 그 팀들에게 우리 팀의 상황을 전달하고, 서로가 만족할 만한 합의를 이끌어낸다는 게 정말 어렵겠구나 하는 생각이 들었다.

 

그래도 어렵기에 더욱 기대가 된다. 어렵다는 건 그만큼 경쟁력이 있다는 것을 의미하기 때문이다. 이번 실전 프로젝트에서 이 경쟁력 또한 길러보도록 해보자.