인프런 커뮤니티 질문&답변

안녕하세요.

"spring-data에서 제공하는 것들이라 컨트롤러나 애플리케이션(서비스)에서 사용하면 안 될 것 같아서" 라고 하셨는데요. 왜 안 되는 거라고 생각하셨나요?

혹시 Spring Data 프로젝트를 사용하지 않게 되면, 그때 Pageable과 같은 인터페이스도 쓸 수 없다고 생각하시는 것인지요?

저는 세 가지 이유로 그냥 사용하시라고 말씀드리고 싶습니다.

스프링 기반의 애플리케이션을 개발하시면서 알려진 대부분의 저장 기술을 사용하신다면 Spring Data 프로젝트만한 좋은 도구는 없다고 생각합니다. 그 안에서 RDB와 NoSQL도 바꿔서 사용할 수도 있고, DB 종류도 당연히 제한없이 변경 가능하죠. Pageable 같이 특정 데이터 기술(예를 들어 JPA)에 의존하지 않은 공통 기능으로 제공되는 것은 데이터 기술의 변경에도 영향을 받지 않고 동일하게 사용할 수 있도록 설계되고 구현되어 있습니다. 페이징 방식을 적용하신다면요.

두 번째로 설령 스프링을 안 쓰고 완전 다른 기술로 대체하신다면, 그때도 Pagaeble을 그냥 기술에 의존성이 없는 인터페이스로 사용하시면 됩니다. Pageable을 쓰면서 그 인터페이스를 구현한 클래스는 직접 정의해서 쓰거나 다른 기술에 맞게 개발하도 됩니다. Pageable 자체는 그게 정의된 패키지 이름을 제외하면 스프링 기술에 전혀 의존하지 않습니다. 잘 정의된 인터페이스를 쓰기 위한 라이브러리로 spring data commons를 추가해서 쓰거나, 인터페이스 파일 하나만 뽑아서 계속 쓰셔도 상관없습니다. Spring Data 프로젝트에 정의되어 있다고 이게 스프링이나 스프링 데이터 기술을 풀로 쓰지 않으면 사용할 수 없다는 것은 사실이 아닙니다. 애노테이션도 그 자체로 어떤 기본 구현을 사용하겠다는 선언으로 본다면, 이 애노테이션을 단순한 각주로 남겨둬도 되고, 그걸 사용하는 인터셉터나 스프링 MVC 확장 기능을 만들어 쓰셔도 되죠. 그러니까 Spring Data를 설령 안 쓰게 된다고 해도 Pageable과 같은 인터페이스는 그대로 사용하실 수 있습니다.

그리고 데이터 처리와 관련된 라이브러리인데 이걸 웹 쪽에서 사용해도 되는가라는 생각을 하실 수도 있는데요. 이것도 아무 상관이 없습니다. 이 인터페이스와 이걸 사용하는 스프링MVC 코드에는 어디서도 스프링 데이터에 의존해서 동작하는 기능이 들어가지 않습니다. 설령 들어간다고 하더라도 이게 개발자의 코드에 의존성을 부여하지 않습니다. 보통 프레임워크는 특정 레이어에 종속된다고 생각하실 필요가 없습니다. 개발자가 작성하는 코드가 특정 구현에 의존해서 환경이나 기술에 종속되는 코드로 만들어지지 않는다면 상관없다는 것이죠. 그래서 프레임워크는 여러 계층에 걸쳐서 기반이 되는 베이스로 동작한다고 봐도 됩니다. 특정 패키지 이름이 코드에 들어가는 것으로 해당 코드가 특정 기술에 의존하는 것은 아닙니다.

이걸 억지로 피하려고 또 추상화를 해서 한 단계 인터페이스를 더 위에 만든다고 했을 때 얻게 되는 유익이 제가 보기엔 거의 없습니다. 그러니 편하게 Pageable을 사용하세요. 그렇게 추가한 코드가 테스트를 만들기 어렵게 한다거나(웹 컨트롤러만 단위 테스트 하는데 DB까지 동작해야 한다 같은 일이 강제되지 않는다면요), 특정 기술을 위한 환경에서만 실행시킬 수 있는게 아니라면 아무 문제 없습니다.

두 번째 질문 @HttpExchange 질문은 제가 잘 이해를 못하겠네요. 조금 풀어서, 코드와 함께 질문해주시면 다시 답변 드리겠습니다.

안녕하세요, 인프런 AI 인턴입니다. 3831568님.
페이징 처리에 대한 고민을 말씀해 주셨군요. Spring Data JPA에서 제공하는 Pageable 인터페이스와 @PageableDefault는 웹 레벨에서 페이징 기능을 쉽게 구현하기 위한 도구입니다. 이들은 컨트롤러 레벨에서 주로 사용하는 것으로, 웹 요청을 처리하는 데에 있어 매우 유용합니다.

고민 포인트와 해결 방안:

1. 웹 계층에서의 사용: Pageable과 @PageableDefault는 주로 컨트롤러와 같은 웹 계층에서 사용됩니다. Spring MVC와 통합되어 있어 잘 맞아떨어지기 때문에, 해당 부분에서 사용하는 것을 권장드립니다. 이는 웹 레이어에서 페이징 요청을 처리하는 매우 표준적인 방법입니다.

2. 서비스 계층에 대한 고려: 서비스 계층에서는 실제 비즈니스 로직을 수행합니다. 여기서는 Pageable을 받아 해당 파라미터를 기반으로 리포지토리에서 데이터를 조회하고, 결과를 리턴하는 식으로 처리할 수 있습니다. 즉, Pageable을 서비스 계층 깊은 곳까지 침투시키지 않는 것이 좋습니다.

3. 새롭게 객체를 정의할 필요: PageRequest와 같은 객체를 사용해 추상화를 할 수 있는데, 이는 복잡한 비즈니스 로직을 가진 서비스 레벨에서는 유용할 수 있습니다. 하지만, 웹 레벨에서 다양한 매개변수와 함께 간편하게 페이징 처리를 하도록 돕는 Pageable 사용도 합리적입니다.

4. 공식 문서 및 사례 참고: 페이징과 관련된 더 구체적인 실습과 사용방법은 토비님의 강의와 Q&A에서 더욱 자세한 설명과 사례가 있을 수 있습니다. 예를 들어, 스프링에서의 페이징 구현 방법과 고려사항을 다룬 기존의 게시물을 참고하시면 도움이 될 것입니다.

면밀히 검토한 후 적절한 레이어에서 Spring의 제공 기능들을 활용하는 것이 필요합니다. 웹 계층에서는 Spring Data JPA의 기능을 활용하는 것이 오히려 유지보수성에서 유리할 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.