# 2022-06-16 유틸 클래스 활용하기 vs Spring Bean 활용하기

# 아고라

아고라

고대 그리스의 도시국가(폴리스)에서 자유 시민들이 자유롭게 토론을 벌이던 장소. 아고라라는 단어 자체의 의미는 '집결지'(Gathering Place)이다.

우리는 다양한 미션을 진행하며 많은 의문과 고민에 직면하게 된다. 미션을 진행하며 단순히 정답을 찾는 것이 아닌 자신만의 근거와 사례를 만들어가는 과정이라고 생각한다. 우리 아고라 에서는 구체적인 예시를 기반으로 다양한 상황을 제시한다. 참여자는 그에 대한 실제 적용 사례를 이야기 하거나 자신만의 근거를 이야기 하며 건전한 토론을 진행한다.

# 목적

미션을 진행하며 직면하는 다양한 의문들에 대한 자신만의 근거를 만들기 위한 의식적인 연습과 자신의 생각을 의도에 맞게 적절히 전달할 수 있는 말하기 연습이 가장 큰 목적이다.

# 유틸 클래스 활용하기 vs Spring Bean 활용하기

주최자: 우리는 Spring을 배우고 난 뒤 싱글톤 객체로 생성되는 Bean과 어디서든 사용할 수 있는 Utill Class의 용도가 비슷하다고 느낄 수 있다. 결국 두 방식 모두 반복적인 객체 생성 없이 원하는 기능을 실행시키는 목적을 달성하기에 충분하다.

그렇다면 우리는 어떠한 기준을 가지고 둘을 구별하여 작성하고 사용해야 할까? 이에 대해 이야기를 나눠보려 한다.

WARNING

보다 더 나은 표기를 위해 유틸 클래스 활용한 진영을 유틸 클래스파, Spring Bean 활용한 진영을 스프링 빈파로 작성하였습니다.

해당 내용은 토론을 진행할 때 주최자가 기록한 것을 기반으로 각색한 것입니다! 모든 내용을 기록하지 못했기 때문에 잘못된 부분이나 틀린 부분이 존재할 수 있습니다. 만약 잘못된 부분이나 추가하고 싶은 내용이 있다면 아래 코멘트에 남겨주세요!

익명의 크루1: 두 상황에 대해 비교해 본 적이 있나?

익명의 크루2: 두 가지 상황에 대해 진지하게 고민해본적이 없는 것 같다. 여기 참여한 다양한 크루들의 의견을 들어본 뒤 생각을 정리해보려 한다.

스프링 빈파: Authorization 헤더에서 토큰을 추출하기 위해 유틸 클래스를 활용했는데 Spring Bean으로 등록 했을 때의 단점은 무엇이라고 생각하는가?

유틸 클래스파: Spring에 종속적인 코드를 작성할 수 있게 된다. 또한 테스트를 진행할 때 결국 Spring 환경 위에서 한정된 코드를 작성할 수 밖에 없어진다.

스프링 빈파: Spring에 지나치게 의존적인게 단점인가? Spring을 사용하며 다른 프레임워크의 교체를 고려하는 것이 더 큰 문제이지 않을까 생각한다.

유틸 클래스파: 유틸 클래스가 아닌 Spring Bean을 선택한 이유는 무엇인가?

스프링 빈파: 우선 가장 큰 이유는 유틸 클래스는 객체지향과는 거리가 멀다. 오히려 절차지향에 가까운 패러다임이다.

유틸 클래스파: 객체지향과 거리가 멀다고 생각하는 이유는 무엇인가?

스프링 빈파: 유틸 클래스는 객체를 생성하지 않기 때문에 객체 사이의 관계가 명확하게 드러나지 않는다고 생각한다. Java는 온전한 객체지향을 지원하는 것은 아니기 때문에 유틸 클래스가 객체지향적이지 않은 것은 알고 있지만 아직 피부에 와닿을 정도로 느끼지 못한 부분도 있다.

스프링 빈파: 또한 이전에 Spring Bean을 활용하면 Spring에 종속적이며 Spring 환경 위에서만 테스트 가능하다고 언급했다. 이것은 생성자 주입을 통한 의존 주입을 진행하면 순수한 Java 코드를 활용하여 테스트를 진행할 수 있다.

유틸 클래스파: 어떨 때 Spring Bean으로 등록해야 한다고 판단하는가?

스프링 빈파: 이번 미션을 예시로 JwtTokenProvider를 들 수 있다. 해당 객체는 jwt와 관련된 외부 라이브러리를 사용하기 때문에 token의 생성 방식이나 암호화 방식의 변경에 대비하여 Spring Bean을 활용하면 다형성을 적극 활용할 수 있다.

스프링 빈파: 유틸 클래스는 다형성을 활용할 수 없다. 이에 대한 생각이 궁금하다.

유틸 클래스파: 다형성을 활용할 필요가 없기 때문에 유틸로 만든 것이다. 우리는 과연 절차지향이 나쁜 것인지 고민해봐야 한다. service 계층을 예시로 들면 객체 내부의 메서드는 객체들에게 메시지를 절차적으로 보내며 비즈니스 로직을 해결해야 한다. 유틸이 객체지향과는 거리가 멀다는 것은 동감한다. 하지만 이것이 유틸 클래스를 바라보는데 부정적인 영향을 끼칠 필요가 있을까 고민해봐야 한다.

유틸 클래스파: 우리는 이번 미션에서 제공된 코드에서 유틸 클래스를 쓰지 않아야할 이유를 찾지 못했다. 굳이 Spring의 생명주기로 가져갈 필요가 있을까? Java에서도 결국 static이라는 키워드를 제공하고 있으며 Math와 같은 클래스에서도 적극 사용하고 있다. 굳이 사용하지 말아야 할 이유는 없다고 생각한다.

스프링 빈파: 그렇다면 외부 리소스에 의해 변동할 여지가 있는 경우에는 어떻게 해야 할까?

유틸 클래스파: 해당 예시가 바로 유틸 클래스가 부적합한 경우이다. JwtTokenProvider와 같이 시크릿 키나 만료시간과 같은 외부 리소스를 필드로 가질 경우 유틸 클래스로써 사용하기에 적합하지 않다고 생각한다.

유틸 클래스파: 유틸 클래스가 더 적은 리소스를 차지 하지 않을까? 단순히 객체지향적이지 않아 지양해야 할까?

스프링 빈파: Spring은 우리가 유연하게 생명주기를 결정할 수 있기 때문에 계속해서 점유하는 메모리를 아낄 수도 있다고 생각한다.

# 최후의 발언

유틸 클래스와 Spring Bean은 각각의 장단점이 있으며 그에 맞는 사용처가 있다고 생각한다. 중요한 것은 이분법적인 사고로 나누지 않으면 괜찮다고 생각한다.

동일하게 두 방식 모두 뚜렷한 단점을 가지지 않는다고 생각한다. 각각의 특징에 맞춰 조화롭게 사용하면 좋을 것 같다.

유틸 클래스가 객체지향적이지 않기에 쓰지 말아야 한다는 것은 수단과 목적이 바뀐 느낌이다. 결국 Java에서도 static 키워드를 제공하고 있다. 우리는 이러한 이점들을 적절히 잘 활용할 줄 알아야 한다.

# 회고

방학이 시작되고 캠퍼스가 열리지 않아 슬립 게더를 통해 온라인으로 진행하게 되었다. 아무래도 온라인 환경에서는 오디오가 겹치거나 여러 환경에서 참여하기 때문에 원할히 진행하는데 한계가 있었다. 그로 인해 자연스럽게 질문과 의도를 이끌어 내는 것이 쉽지 않았다.

또한 최초 기획 당시에 매주 진행해보면 좋지 않을까 생각했다. 하지만 이것은 주최자와 참여자 모두에게 큰 부담으로 다가온다. 이후 일정은 2주 마다 진행하는 식으로 개선해볼 생각이다.

개강을 하게 되면 선릉과 잠실 캠퍼스로 많은 크루들이 흩어지게 된다. 결국 이전보다 참여하는 인원을 모집하는 것이 더욱 쉽지 않겠지만 의식적인 연습을 위해 포기하지 않고 꾸준히 노력해볼 예정이다.

# References

#

#우아한테크코스 #아고라

← 2022-06-03 service layer에서 dto를 반환하는 것 vs 도메인을 반환하는 것 2022-07-07 세션 & 쿠키 방식 vs 토큰 방식 →