[리팩터링] Auth Application 구조 개선

Jayson·2025년 3월 7일
post-thumbnail

터닝 서비스 바로가기

해당 블로그 관련 PR 보러 바로가기

터닝은 1차 스프린트부터 4차 스프린트까지 기획의 요구사항에 맞춰 기능을 구현해왔다.
하지만 그 과정에서 서버 개발자로서 유지보수하기 좋은 코드, 좋은 코드에 대한 고민은 부족했다. 기획, 디자인, 클라이언트, 서버가 함께하는 프로젝트를 처음 경험했고, 이전까지는 학습에 집중하느라 실제 구현 경험이 적었다. 그래서 요구사항을 충실히 반영하고 동작하는 코드면 충분하다고 생각했다.

그러나 깊이 고민하지 않고 작성한 코드였기에 시간이 지날수록 애정이 식었다.
스스로도 코드가 엉망이라는 걸 알았고, 다시 읽기조차 부담스러워 리팩터링을 미루게 됐다.

그러다 3차에서 4차로 넘어가는 과정에서 개인적으로 큰 성장을 경험했다.
좋은 코드, 객체지향 설계, 테스트 코드에 관심을 갖고 노력한 결과, 코드 품질에 대한 기준이 생겼고 이를 유지하고 싶다는 욕심도 생겼다. 서버 팀원들에게 공유하며 도입을 제안했지만, 공감을 얻기 어려웠고, 리팩터링과 테스트 코드는 여전히 요구사항 구현에 밀려 후순위로 남게 되었다.

그래서 개인적으로 권한이 있는 소셜 로그인 및 회원 관리 부분부터 점진적으로 개선하기로 했다.
코드 리뷰를 요청하고 피드백을 주고받으면서 점진적으로 전체 코드의 품질을 높이자는 생각을 하게 됐다

1. 패키지 분리

가장 먼저 패키지 구조를 관심사에 맞게 개선해야겠다고 마음을 먹었다.
처음 개발할 때는 서버 팀원 모두 익숙한 형태인 MVC 계층형 구조를 가져갔지만 기능이 추가됨에 따라 클래스가 분리되지 않아 클래스 찾기가 너무 어려웠다.

User를 보면 VO로 관리하면 좋은 부분들이 많이 보여 수정하고 싶었지만 작은 부분부터 개선하기보다는
큰 부분부터 개선해가는 게 변경하기 쉬울 것 같았고 검증하기도 좋을 것 같았다.
유저가 있는 서비스인 만큼 동작하는 것은 여전히 중요하다고 생각한다.
그래서 코드는 가능한 유지한 채 패키지, 클래스, 코드 순으로 개선해가고자 한다.

먼저 auth 관련 클래스들을 패키지로 분리하였다.
앞으로 auth 관련 관심사는 이 패키지에서 찾아보면 될 것 같아서 마음이 놓인다.
이전까지는 여기저기 패키지를 돌아다니며 클래스를 찾아야 했는데, 이제는 auth 패키지에서만 찾으면 되겠다.

2. 연관관계 개선

서비스 클래스를 보면 메서드별로 구현 내용이 담겨 있다. 하단으로 내리면 여러 프라이빗 메서드들도 존재하는데, 이렇게 되면

  1. 하나의 API를 수정할 때 다른 API에 영향을 줄 가능성이 높다.

  2. 복잡한 비즈니스 로직이 다른 관심사들과 함께 있어 가독성이 떨어지고, 팀원이 읽을 때도 불편할 수 있다.

따라서 각 API를 인터페이스로 만들고 구현체를 분리할 것이다.

이렇게 하면 AuthService는 여러 인터페이스들(예: AuthSignInService, AuthSignOutService 등)을 가질 수 있고, 각 인터페이스는 별도의 구현체로 분리된다.

이렇게 하면 각 구현체의 비즈니스 로직이 변경되더라도 여러 API를 관리하는 AuthService는 큰 영향을 받지 않는다.

또한 코드 리뷰어 입장에서도 로그인 관련 코드는 로그인 관련 코드만, 회원가입 관련 코드는 회원가입 관련 코드만 볼 수 있어 유지보수와 코드 리뷰가 수월해질 것으로 기대된다.

3. 느슨한 연관관계

각 API를 인터페이스로 분리하여, 특정 API 변경이 다른 API에 미치는 영향을 최소화했다.

각 인터페이스의 구체적인 구현을 담당하는 클래스를 분리했다. 이렇게 나누면서 아쉬운 코드들이 보였지만, 일단 구조를 개선한 후 구체적인 부분들을 개선해나가기로 했다.

이러한 개선을 통해 코드가 보이는 것만으로도 성장했다는 것을 실감할 수 있어 뿌듯함이 생겼다. 또한, 인터페이스가 하나인 경우 구현체 이름을 어떻게 지어야 할지 고민했지만, 확장할 필요가 생기면 그때 네이밍을 재검토하기로 했다.

4. 개선된 패키지 구조

api별로 패키지를 나누지 말고 모아둘까 고민했지만, 이렇게 나누는 것이 유지보수하기 더 좋다고 판단했다. 찾기 쉬우니까. 각 패키지별로 최소 2개의 클래스가 존재하는데, application에 여러 클래스가 몰리는 것보다는 분리하는 것이 낫다고 생각했다.

5. 개선된 AuthService

클래스 간 연관관계만 느슨하게 만들었고, 코드는 바꾸지 않았지만 가시성이 확연히 좋아졌다. 뿌듯하다. 앞으로 해야 할 것들이 많지만, 리뷰를 받으면서 점진적으로 개선해 나가고자 한다.

profile
Small Big Cycle

0개의 댓글