모임 일정 시간 조회 - 페이지네이션(무한 스크롤) 도입

[f1v3-dev]

1. 도입 계기

세빈님 특별출현 ㅋㅋㅋㅋ

프론트 측의 요청과, #121 의 이슈에 나와있는 내용처럼

모임 의 일정 시간(DateOfSchedule) 을 조회할 때 전체 데이터를 한 번에 불러오게 API를 구성하였습니다.
이러한 경우에, UX (사용자 경험)도 그렇고, 서버에 대한 응답도 오래 걸린다는 문제점이 존재하여 해당 방식을 해결하고자 하였습니다.

무한 스크롤 (Infinite scroll)

그 전에 페이지네이션은 알고 있지만, 무한 스크롤을 구현해본 경험이 없어 찾아봤습니다.

사용자가 페이지의 맨 아래에 도달할 때 데이터나, 컨텐츠가 계속 로드되게 하는 방식을 의미합니다. (인스타그램, 페이스북, 유튜브 등)

장점

• 사용자 참여 증가: 사용자가 웹 사이트에 머무르는 시간이 증가한다. 즉, 이탈률이 적다
• 추가적인 액션이 필요 없다: 스크롤 > 클릭/탭 보다 상호작용 비용이 적다.
• 모바일 기기에 적합하다: '모바일 화면'을 기준으로 만드는 현 상황에 페이지네이션은 적합하지 않아보인다.

단점

• 페이지 성능이 느려진다: 한 페이지에 보여줘야 할 내용이 많아질 수 있다.
• 특정 위치로 이동하기 어렵다
• 컨텐츠 수량이 얼마나 되는지 알 수 없다.

이러한 장단점이 존재하며 특히,

• 모바일 기기에 적합하다
• 추가적인 액션이 필요 없다

이러한 장점을 기반으로 도입하면 좋을 것 같다고 판단하였습니다.

2. 접근 방법

고려사항

실시간으로 변경되는 데이터를 무한 스크롤로 구현을 하려다 보니 문제점이 있다는 것을 알게 되었습니다.

시나리오

1. A 회원이 모임 일정 시간 조회 페이지 에서 스크롤을 내리고 있는 상황
2. B 회원은 일정 시간을 입력함.
3. 스크롤을 내려 조회하고 있던 A 회원에게 보여질 데이터가 부정확함. (데이터 중복 및 데이터 정합성 문제)

이러한 문제를 대응하기 위해 '커서 기반 페이지네이션' 을 생각해보았지만,
커서 기반 페이지네이션 같은 경우, 마지막에 조회된 데이터의 ID 값을 통해 진행되는 것으로 파악됩니다.

하지만, 우리의 데이터에는 별도의 ID 값이 없으며, 정렬 기준 또한 '우선순위 (많은 사람이 입력한 순, 빠른 시간 순)' 으로 복잡한 정렬 기준을 가지고 있어 해결하기 어려웠습니다.

해결 방안

다양한 접근 방법을 태웅님과 함께 생각해보고 불가피한 문제점이 존재하지만, 현 상황에서는 다음과 같은 방향으로 진행하였습니다.

API 요청 시간(최초 호출) 과 일정(Schedule)의 할당 시간을 비교하여, API 요청 시간보다 이후에 할당된 일정(Schedule)은 불러오지 않는다.

문제점

• A 회원이 조회하고 있을 때 B 회원이 생성한 데이터를 조회하지 못하는 상황에만 유효하다.
• 중간에 데이터가 변경되거나, 삭제되었을 때는 지속적인 문제가 존재한다.
• 단, 중복 조회는 발생하지 않는다.

위와 같은 문제점이 있지만, 중간에 삽입된 데이터는 조회하지 않아 중복 조회는 발생하지 않는 점을 생각하고 진행하게 되었습니다.

구현 방법

1. 일정 (Schedule) Entity 필드 추가 - assignedAt
2. 일정 시간 조회 요청 시점 기준 으로 이전에 입력된 데이터만 조회 하도록 쿼리문 수정
3. 조회 응답에 요청 시점(requestTime) 을 클라이언트에게 넘겨, 쿼리 파라미터로 넘겨받도록 요청
4. PageableDefault 를 활용하여 페이징 처리하기

MeetingController - 모임 시간 조회

    /**
     * 모임 시간을 조회하는 메서드입니다.
     *
     * @param uuid     조회할 모임 UUID
     * @param pageable 페이징 정보 (default: page = 0, size = 10, sort = count)
     * @return 200 (OK), body: 모임 시간 응답 DTO
     */
    @GetMapping("/{meetingUuid}/times")
    public ResponseEntity<PagedResponse<MeetingTimeResponseDto>> getMeetingTimes(
            @PathVariable("meetingUuid") String uuid,
            @PageableDefault(sort = "count") Pageable pageable,
            @RequestParam(value = "request_time", required = false) String requestTime) {

        LocalDateTime time = LocalDateTime.now();

        if (requestTime != null) {
            time = LocalDateTime.parse(requestTime);
        }

        PagedResponse<MeetingTimeResponseDto> responseDto = meetingService.getMeetingTimes(uuid, pageable, time);
        responseDto.getData().setRequestTime(time);

        return ResponseEntity.ok(responseDto);
    }

Querydsl 쿼리문 수정

        List<MeetingTime> meetingTimeList = from(dateOfSchedule)
                .join(dateOfSchedule.schedule, schedule)
                .join(schedule.meeting, meeting)
                .where(meeting.meetingUuid.eq(uuid)
                        .and(schedule.assignedAt.loe(requestTime))) // <- 변경된 파트 (요청 시간 이전까지만 조회)
                .groupBy(dateOfSchedule.dateOfScheduleStart, dateOfSchedule.dateOfScheduleEnd)
                .orderBy(orderSpecifiers.toArray(new OrderSpecifier[orderSpecifiers.size()]))
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .select(Projections.constructor(MeetingTime.class,
                        dateOfSchedule.dateOfScheduleStart,
                        dateOfSchedule.dateOfScheduleEnd,
                        dateOfSchedule.dateOfScheduleRank.avg()
                ))
                .fetch();

위와 같은 방식으로 무한 스크롤을 구현하였습니다.

결과

개선된 점

기존 요청 시간

변경 후 요청 시간

1. 700ms에서 100ms로 약 7배 개선된 것을 파악할 수 있습니다.
2. 사용자 경험(UX) 측면에서도 빠른 응답시간으로 인해 만족도가 높아질 것으로 예상됩니다.
3. 추가적인 데이터가 많아져도, 성능이 안정적으로 유지될 수 있는 구조로 변경되었습니다.

고민해볼 점

• 위에 문제점에서도 언급했던 '수정/삭제' 작업으로 인해 문제가 될 점은 여전해 보임
• 좋은 해결 방안이 있는지 더 찾아봐야 함! 개선할 부분