기존 일정 조회 방식

위 모든 일정 관련 데이터 조회에 대한 api 는 한 api 로만 사용한다.

api 응답 형식의 예시는 다음과 같다

{
  "code": 20000,
  "content": {
    "queryStartDate": "2024-08-31",
    "queryEndDate": "2024-09-01",
    "scheduleHeadDtos": [
      {
        "scheduleId": 1,
        "title": "디자인팀 회의",
        "scheduleRecordDto": [
          {
            "scheduleRecordId": 1,
            "isComplete": false,
            "recordDate": "2024-08-31",
            "deletedAt": "2025-08-03T05:50:24.096Z"
          }
        ],
        "color": "#FCDCDF",
        "category": "COMPUTER",
        "isAllDay": false,
        "startDate": "2024-08-31",
        "endDate": "2024-08-31",
        "daysOfWeek": [
          "MONDAY",
          "TUESDAY"
        ],
        "time": "10:30",
        "location": "일정 장소",
        "memo": "일정 메모"
      }
    ]
  },
  "message": null
}

일정 조회 api 초기 설계의 이유

처음 일정 조회 api를 위와 같이 설계한 이유는 일정이 달력에 표시하면 해당 일정을 클릭할 것이고 그렇다면 굳이 api 를 2번 나눠서 호출하는 것보다. 1번의 호출로 데이터를 캐싱해놓으면 좋지 않겠나라는 이유였다.

프론트 팀과의 협업

해당 api 에 과도한 정보를 제공한다고 판단했어서 프론트팀에게 일정 데이터가 보여지는 3가지 화면에서 사용자 행동에 목적을 찾아나갔다.

생각보다 달력 같이 조회할 일정의 데이터 수가 큰 api 에서는 해당 날짜에 일정이 있는 것에 관심이 있지 달력에 표시된 30일 정도의 모든 일정 데이터를 보지 않는 유저 패턴을 추적했다.

개선된 api

select distinct
    s1_0.id,
    s1_0.color,// 색
    s1_0.days_of_week, // 반복 요일
    s1_0.deleted_at, // 삭제 날짜
    s1_0.end_date, // 마감 날짜
    s1_0.start_date, // 시작 날짜
    s1_0.is_all_day, // 종일 여부
    s1_0.time, // 시간
from schedule s1_0
where
    s1_0.deleted_at is null
    and s1_0.user_id = ?
    and (
        (
            s1_0.start_date = s1_0.end_date
            and s1_0.days_of_week is null
            and s1_0.start_date between ? and ?
        )
        or
        (
            s1_0.start_date = s1_0.end_date
            and s1_0.days_of_week is not null
            and s1_0.start_date <= ?
        )
        or
        (
            s1_0.start_date <> s1_0.end_date
            and s1_0.end_date >= ?
            and s1_0.start_date <= ?
        )
    );