UUID, Random 등 자주 사용하는 의존성의 경우

안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.

공통으로 사용하는 유틸 클래스들을 하나의 패키지에 모아 관리하는지가 궁금한 것으로 보이는데 맞으실지요? 네, 그렇게 사용합니다. util 패키지가 생기는 것 자체는 전혀 이상한 게 아닙니다. 스프링 프레임워크에서도 util 패키지 사용합니다. (참조: https://github.com/spring-projects/spring-framework/tree/main/spring-core/src/main/java/org/springframework/util) 그리고 ClockHolder, UuidHolder는 충분히 util 패키지에서 관리할 만한 인터페이스라 생각합니다.

다만 그렇다고 모든 프로젝트에서 항상 util 패키지를 만들어 사용하는 것은 아닙니다. 이는 상황에 따라 다릅니다. util 패키지를 만드는 경우, 도메인으로 엮여야 할 비즈니스 로직들이 종종 클래스 이름에 util이라는 이름을 달고 util 패키지로 모이는 경우가 생깁니다. 그래서 프로젝트 별로 util 패키지 자체를 만드는 것을 선호하지 않기도 합니다.

그러니 ClockHolder, UuidHolder의 위치는 common.domain에 들어가도 되고 util에 들어가도 된다 생각합니다. 사실 클래스의 패키지 위치나 이름 자체는 그렇게 중요한 문제가 아닙니다.

원하시는 답변이 됐는지 잘 모르겠습니다. 답변이 도움 됐길 바랍니다. 감사합니다.

+) 음… 그런데 제 생각엔 본질적으로 이 질문은 실제로 ‘어떻게 사용하는지가 궁금하다’기보다, 개발에 대한 확신이 없어서 긴가민가하고 있는 것에 기인한 게 아닐까 싶습니다. 그래서 답을 원하는 것 같기도 하고요…? (어차피 개발에 정답은 정해져 있지 않습니다. 확신과 근거만 있으면 됩니다. 만들어 보고, 막상 만들어 봤더니 별로다 싶으면 수정하면 되죠.) 그러니 그냥 마음내키는 대로 개발해 보는 게 좋지 않을까 싶네요!

안녕하세요, 인프런 AI 인턴입니다.

UUID, Random과 같은 자주 사용되는 클래스들의 경우 실무에서는 대체로 유틸리티 클래스로 만들어서 사용하곤 합니다. 공통 유틸리티를 제공하는 별도의 클래스 또는 인터페이스를 만들어 두고, 이를 필요한 곳에서 호출해서 사용하는 것이죠. 이렇게 함으로써 코드 중복을 줄이고, 프로젝트 전반에 걸쳐 일관된 방식으로 의존성을 관리할 수 있습니다.

이 과정에서 단위 테스트가 보다 쉬워질 수 있도록 스프링 프레임워크는 org.springframework:spring-test 모듈을 제공하며, 이를 통해 테스트에서 의존성 주입을 받을 수 있는 목(mock) 객체를 쉽게 사용할 수 있습니다. 이는 spring-boot-starter-test 스타터를 통해 트랜지티브(전이적) 의존성으로 포함시켜 활용할 수 있습니다.

또한, 테스트 유틸리티 클래스들은 spring-boot 패키지의 일부로 제공되기도 합니다. 이를 활용하여 어플리케이션을 테스트할 때 유용하게 사용할 수 있습니다. 테스트 관련해서 더욱 자세한 내용은 스프링 부트 레퍼런스 문서의 테스트 관련 섹션을 참고하시면 도움이 될 것입니다.

다만, 실제 프로젝트에서의 사용법은 팀의 상황이나 기술 스택, 코드베이스의 규모 등에 따라 달라질 수 있으므로, 팀 내부의 가이드라인이나 패턴에 따라 다르게 접근할 수도 있음을 유념해 주세요.