프로젝트를 진행하며 팀원의 코드를 보던 중
public record OrderListResponseDto (
Page<OrderResponseDto> orderList
){}이런 식으로 Dto 안에 Page로 감싼 Dto가 또 있는 형식을 보게되었다.
설명을 들어보니 반환 타입이 Page면 Redis로 처리할 수 없어 Dto를 한번 더 포장하였고, Page를 Redis로 처리하는 여러가지 방법들이 있지만 그 중 이 방법이 가장 간단하여 이렇게 처리하였다는 답변을 들을 수 있었다.
페이징된 데이터를 Redis에 저장하는 방법은 여러 가지가 있을 수 있다. 예를 들어, Page 객체를 따로 변환하여 Redis에 적합한 형태로 직렬화하거나, 커스텀 직렬화 로직을 구현하여 Redis와 호환되도록 처리할 수 있다. 하지만 이러한 방식은 개발 시간이나 유지 보수 측면에서 더 복잡할 수 있으며, 성능 이슈를 발생시킬 여지가 있다.
팀원이 선택한 방법은 상대적으로 간단하고 구현이 쉬운 해결책이었다. Dto로 한 번 더 포장함으로써 Redis에 적재할 수 있는 데이터 구조로 변환하는 작업이 간소화되고, Redis에서의 처리 성능 역시 개선될 수 있다.
이 과정을 통해 Redis와 같은 캐시 시스템에서 데이터를 처리할 때의 제약 사항을 고려하는 것이 얼마나 중요한지 배웠다. 또한, 페이징된 데이터를 캐싱할 때 단순히 Page 객체를 Redis에 직렬화하는 것보다, 이러한 데이터를 한번 더 Dto로 감싸는 것이 더 효율적일 수 있다는 점을 깨달았다.
팀원의 코드를 통해 '단순하면서도 효과적인' 해결책이 무엇인지 다시금 생각하게 되었고, 앞으로 비슷한 상황에서 Redis나 다른 캐시 시스템을 사용할 때 유용한 패턴이 될 수 있을 것 같다.
