🗓️여기어때 Date·인원 선택 UI 만들기-SwiftUI Calendar Core & DateTravelerSelector 구조 재설계

안녕하세요. 여기어때컴퍼니 iOS 개발팀 레이너입니다.

이번 글에서는 실제 서비스에서 가장 자주 사용되는 UI 중 하나인

“날짜 + 인원 선택(DateTravelerSelector)” 화면을 어떻게 SwiftUI 기반으로 재설계했는지 공유해보려 합니다.

여기어때 앱에는 패키지·국내숙소·해외숙소·찜목록 등 다양한 도메인이 존재합니다.

겉으로 보기엔 비슷한 UI지만, 정책이 전부 다르기 때문에 완전히 공통화하기 어려운 영역이기도 합니다.

예를 들어:

• 패키지는 출발일만 선택
• 국내숙소는 체크인/체크아웃 + 인원
• 해외숙소는 국내와 비슷하지만 어른·아이·객실 수를 각각 조절해야 하는 인원 정책이 추가
• 찜 화면은 또 별도의 정책으로 작동

이처럼 화면 형태는 비슷해 보여도 로직은 모두 다르기 때문에, 단순히 하나의 통합 달력으로 만들기에는 무리가 있었습니다.

🎯 해결해야 했던 문제들

SwiftUI로 Date·인원 선택 UI를 재설계하면서, 겉으로 보기에는 단순한 화면 같지만 실제로는 도메인별로 정책도 다르고 기술적으로도 해결해야 할 난관이 많았습니다. 특히 아래와 같은 부분들은 실제 개발 과정에서 깊은 고민이 필요했습니다.

1. 하나로 통일하려 했지만… 도메인별 정책 차이가 너무 컸던 문제

처음에는 모든 도메인을 하나의 “통합 Date·인원 선택 화면”으로 묶어보려고 했습니다.

하지만 실제로 패키지·국내숙소·해외숙소·찜 화면은 UI와 정책이 모두 달랐습니다.

• 패키지: 출발일 단일 선택(멀티 선택 허용), 인원 선택 UI는 별개로 존재
• 국내숙소: 체크인/체크아웃 + 총 인원(어른/아이 합산)
• 해외숙소: 체크인/체크아웃 + 성인/아동 분리 + 객실 수 선택
• 찜: 해외와 유사하지만 객실 선택 없음
• 달력 기간 범위도 다름: 국내 180일, 해외·찜 365일

이 모든 정책을 하나의 달력에서 분기로 처리하면

로직이 너무 복잡해지고 유지보수 난이도가 크게 증가합니다.

👉 결론: 전체 화면(DateTravelerSelector)은 도메인별 정책 차이 때문에 분리하되 달력 셀·스타일 등 UI 컴포넌트는 YDS 디자인 시스템을 기반으로 공통화하 고, 그 위에서 동작하는 날짜 계산 Core(월 생성·셀 생성·Range 계산 등 로직)만 별도로 추상화해 각 도메인에서 재사용하는 구조로 정리했습니다.

2. Range 모드 및 consecutiveDays 정책의 복잡성

국내·해외·찜 화면은 모두 “Range(체크인/체크아웃)”을 사용하지만, 세부 정책은 다르게 작동합니다.

• 체크인 기준 ±30일(또는 서버 제공 값) 내에서만 체크아웃 가능
• 중간에 예약 불가일이 포함되면 선택 불가
• 날짜 범위가 도메인별로 다름 (180일 vs 365일)
• 각 도메인별 인원 정책이 달력 활성 조건에 영향을 줌

즉, 단순한 range 계산이 아니라 도메인별 정책이 함께 작동하는 구조 여서

Core와 Selector가 반드시 분리되어야 했습니다.

👉 결론: DateViewData 생성 로직을 Calendar Core로 분리하고,

도메인 정책은 DateTravelerSelector에서만 제어하는 아키텍처가 필요했습니다.

3. LazyVGrid의 iOS 16 버그 및 성능 이슈로 인한 Grid 구조 재설계

초기 달력 시도에서는 LazyVGrid를 사용했지만,

• iOS16에서 offset 계산 오류
• 스크롤 중 셀 포지션이 튀는 현상
• 스크롤 버벅임
• 성능 저하 및 layout pass 반복
• iOS17/18에서는 정상인데 16에서만 불안정

같은 문제가 발생했습니다.

또한 달력은 180~365일 분량을 한 번에 그리는 구조라

LazyVGrid + GeometryReader 조합은 성능이 더 악화되었습니다.

👉 최종 선택은 아래 세 가지 전략이었습니다.

✔ 직접 Grid 구성

• LazyVGrid를 버리고, 우리만의 7열 Grid 구조로 재구성 (iOS16 안정화 + 렌더링 일관성 확보)

✔ GeometryReader 최소화

• GeometryReader를 남발하면 성능이 급격히 저하되므로 필요한 위치에서만 제한적으로 사용

✔ 초기 렌더링 최적화 — Precompute & Cache Strategy

• 초기 진입 시 전체 Month × Date 정보(DateViewData)를 한 번에 계산해 캐싱 → 뷰 렌더링 시 diffing 최소화

이 구조로 변경한 뒤 iOS 16에서도 스크롤 버벅임이 크게 감소했습니다.

⭐ Calendar Core 구조로 해결한 방식

앞서 말한 문제들을 해결하기 위해 우리는 캘린더 기능을 다음 두 축으로 나누어 재설계했습니다.

• Calendar Core (공통 로직 + 날짜 계산 + 렌더링 데이터 생성)
• ScrollableCalendarView (UI 레이어, SwiftUI 공통 캘린더 컴포넌트)

이 두 구조를 통해 패키지·국내숙소·해외숙소·찜 화면이 모두 같은 Calendar Core를 공유하면서도, 각 도메인의 정책은 독립적으로 유지할 수 있게 되었습니다.

1. Calendar Core: 월 단위로 “미리 계산된 렌더링 데이터”를 만드는 구조

Calendar Core(DateTravelerSelectorUtils)는 다음 역할들을 담당합니다.

① Month 리스트 계산 (generateMonths)

Calendar Core에서는 먼저 시작일 ~ 종료일 사이에 포함된 모든 (YYYYMM) 을 만들어 둡니다.

이 Month 리스트가 나중에 Dictionary<YearMonth, [DateViewData]> 형태의 캐시 키가 됩니다.

예를 들어:

• startDate = 2025-01-10
• endDate = 2025-03-05

라면, Core에서는 아래와 같은 Month 리스트를 만듭니다.

[202501, 202502, 202503]

실제 코드는 다음과 같이 구성되어 있습니다.

typealias YearMonth = Int //예: 202501

static func generateMonths(from startDate: Date, to endDate: Date) -> [YearMonth] {
    var months: [YearMonth] = []
    var current = startDate
    let calendar = Calendar(identifier: .gregorian)
    // endDate가 속한 달까지 포함되도록 마지막 달의 말일로 보정
    let endOfMonth = calendar.date(
        byAdding: DateComponents(month: 1, day: -1),
        to: endDate
    )!
    while current <= endOfMonth {
        let year = calendar.component(.year, from: current)
        let month = calendar.component(.month, from: current)
        let yearMonth = year * 100 + month   // 2025년 1월 -> 202501
        if !months.contains(yearMonth) {
            months.append(yearMonth)
        }
        // 다음 달로 이동
        current = calendar.date(byAdding: .month, value: 1, to: current)!
    }
    return months
}

이렇게 해두면:

• 국내 숙소처럼 180일짜리 달력
• 해외/찜처럼 365일짜리 달력

처럼 도메인별로 기간이 달라도 , 위 generateMonths만 호출하면 항상 공통된 Month 리스트 를 얻을 수 있어서 뒤에서 설명할 initDateViewData / updateMonthDateViewData 로직이 모두 같은 흐름을 타게 됩니다.

② 각 월의 Grid 생성 (makeDateGridArray / makeCalendarGridItems)

Calendar Core에서는 한 달(month)을 가로 7열(일~토), 최대 6행(총 42칸) 의 고정된 Grid로 정규화해서 다룹니다.

SwiftUI에서 어떤 레이아웃을 사용하더라도, 항상 이 42칸짜리 배열만 받아서 그리면 되도록 만든 구조입니다.

예를 들어, 아래와 같이 월 시작 요일에 따라 앞부분은 nil로 채우고,

실제 날짜는 1 ~ 31까지 숫자로 채웁니다.

[ nil, nil, 1, 2, 3, 4, 5,
  6, 7, 8, 9, 10, 11, 12,
  ...]

이 배열을 만드는 코드의 핵심은 다음과 같습니다.

static func makeDateGridArray(for startOfMonth: Date) -> [Int?] {
    let calendar = Calendar(identifier: .gregorian)
    
    // 해당 달의 1일이 무슨 요일인지 (1 = 일요일)
    let startWeekday = calendar.component(.weekday, from: startOfMonth)
    
    // 이 달이 며칠까지 있는지 (예: 1...31)
    let range = calendar.range(of: .day, in: .month, for: startOfMonth)!
    
    // 월 시작 요일 앞쪽을 nil 로 채움
    let leadingEmptyCount = (startWeekday - 1) % 7
    var array: [Int?] = Array(repeating: nil, count: leadingEmptyCount)
    
    // 실제 날짜 채우기
    array.append(contentsOf: range.map { Optional($0) })
    
    // 마지막 줄도 7의 배수가 되도록 뒤쪽을 nil 로 채움
    let remaining = array.count % 7
    if remaining > 0 {
        array.append(contentsOf: Array(repeating: nil, count: 7 - remaining))
    }
    
    return array
}

이렇게 만들어진 [Int?] 배열을 기반으로,

makeCalendarGridItems에서 각 셀을 다음과 같은 형태로 감싸서 사용합니다.

struct CalendarGridItem {
 let index: Int // 0 ~ 41
 let day: Int? // nil 이면 빈 칸, 아니면 실제 날짜
 let dateViewData: DateViewData?
}

결과적으로 MonthView 입장에서는:

• “이 달은 항상 42개의 셀을 가진다”
• 각 셀은 “날짜가 있거나(nil로 비어있거나)” 둘 중 하나다

라는 전제가 깔리기 때문에,

도메인에 상관없이 같은 MonthView 컴포넌트를 재사용할 수 있었습니다.

③ 날짜 셀(DateViewData)을 만드는 핵심 로직 — buildDateViewData

①에서 Month 리스트를 만들고, ②에서 각 월을 7×6 그리드로 정리했다면,

다음 단계는 “각 칸이 어떤 상태의 날짜 셀인지 ”를 결정하는 일입니다.

이 역할을 하는 함수가 buildDateViewData입니다.

이 단계에서 실제로 달력 UI의 거의 모든 비즈니스 로직이 결정됩니다.

• 선택된 날짜인지 (isSelected)
• 공휴일/일요일인지 (isHoliday)
• 가격/재고 정보가 있는지 여부
• 선택 불가 여부 (isDisabled)
• Range 모드에서 체크인/체크아웃/중간 구간인지 (rangeType)
• 서브 텍스트(가격 텍스트)를 숨겨야 하는지 등

실제 서비스 코드는 도메인별 정책(국내/해외/찜, 가격/재고, 최대 연박 등)이 더 많이 포함되어 있지만, 핵심 흐름만 요약하면 아래와 같은 형태입니다.

/// 날짜 셀(DateViewData)을 만드는 핵심 흐름 요약본
private static func buildDateViewData(
    date: Date?,
    context: CalendarRenderContext,
    previous: DateViewData?
) -> DateViewData {

    // 빈 칸(날짜 없음) 처리
    guard let date else { return handleEmptyDate(context, previous) }

    // 기본 상태 계산
    let isSelected = context.isSelected(date)
    let isHoliday  = context.isHoliday(date)
    let priceInfo  = context.priceInfo(for: date)

    // 도메인 정책을 반영한 비활성화 여부
    let isDisabled = context.isDisabled(date, priceInfo: priceInfo)

    // Range 모드에서 체크인/체크아웃 edge 계산
    let rangeType  = context.rangeType(for: date)

    // diff 기반 업데이트 (불필요한 렌더링 방지)
    return previous?.updated(
        isSelected: isSelected,
        isDisabled: isDisabled,
        rangeType: rangeType,
        priceText: priceInfo?.priceText
    ) ?? DateViewData(
        date: date,
        isSelected: isSelected,
        isHoliday: isHoliday,
        isDisabled: isDisabled,
        rangeType: rangeType,
        subText: priceInfo?.priceText ?? ""
    )
}

핵심 아이디어는 모든 비즈니스 로직을 CalendarRenderContext 내부로 캡슐화 하고, buildDateViewData에서는 “이 날짜를 어떤 상태로 표현할지”만 결정하도록 만든 것입니다.

이렇게 해두면 SwiftUI View 쪽에서는 DateViewData 배열만 받아서:

• 비활성화 스타일로 그릴지
• 오늘 표시를 할지
• Range의 시작/중간/끝 스타일을 입힐지

만 신경 쓰면 되기 때문에, 도메인별 정책 변경이 생겨도 Core 로직에서만 수정하고 각 도메인의 UI 코드는 그대로 재사용할 수 있게 됩니다.

④ 변화된 상태만 갱신하는 구조 — updateMonthDateViewData

달력 화면은 날짜 선택·가격·공휴일·재고 등이 바뀔 때마다 상태가 변합니다.

하지만 월 전체를 다시 계산하면 성능이 급격히 저하되므로, “변경된 셀만 갱신하고, 나머지는 재사용하는 구조”로 설계했습니다.

핵심 아이디어는 딱 두 가지입니다.

(a) 이전 셀(DateViewData)을 그대로 넘겨서 비교 후 필요한 부분만 업데이트

let newData = calendarGridItems.map { cell in
    buildDateViewData(
        date: date,
        context: context,
        previous: cell.dateViewData   // ← 이전 값 전달
    )
}

buildDateViewData는 내부에서:

• 값이 같으면 → previous 반환(= 재사용)
• 값이 달라졌으면 → 새 DateViewData 생성

이렇게 동작합니다.

(b) 계산 비용이 큰 요소는 한 번만 묶어서 Context로 전달

let context = CalendarRenderContext(
    selectedDates: selectedDates ?? [],
    holidaysSet: holidaysSet,
    openDaysSet: openDaysSet,
    priceDataMap: priceDataMap,
    model: model
)

date마다:

• 공휴일 여부
• disabled 여부
• 가격 존재 여부
• rangeType(start/mid/end)
• consecutiveDays 연박 가능 범위

같은 계산을 매번 하면 성능이 급격히 떨어집니다.

그래서 필요한 값을 한 번에 묶어 둔 CalendarRenderContext 를 만들고, 각 셀은 이 값을 빠르게 참조하도록 설계했습니다.

SwiftUI는 동일한 Identifiable 셀은 재렌더링하지 않기 때문에, 이 구조는 변경된 셀만 최소로 갱신되는 실제 서비스 성능 최적화에 큰 효과가 있었습니다.

2. ScrollableCalendarView: UI를 담당하는 SwiftUI 레이어

ScrollableCalendarView는 여기어때 앱의 모든 Date·인원 선택 화면에서 공통으로 사용하는 SwiftUI 캘린더 UI 레이어 입니다.

앞에서 설명한 Calendar Core가 월별 DateViewData를 계산해 넘겨주면, 이 뷰는 그 데이터를 그대로 그리기만 합니다.

즉, UI는 렌더링 + 이벤트 전달 ,

정책·계산·검증은 Core가 담당하는 구조입니다.

① ScrollableCalendarView

전체 구현은 길지만, 핵심 구조만 보면 굉장히 단순합니다.

struct ScrollableCalendarView: View {
    @Binding var monthDateViewData: [YearMonth: [DateViewData]]
    @Binding var selectedDates: [Date]

    let model: DateSelectorModel
    let openDaysSet: Set<Date>

    var body: some View {
        ScrollViewReader { proxy in
            ScrollView {
                ForEach(monthDateViewData.keys.sorted(), id: \.self) { month in
                    DTSMonthView(
                        month: month,
                        dateViewData: monthDateViewData[month] ?? [],
                        onDateSelected: { date in
                            handleDateSelection(date)
                        }
                    )
                    .id(month)
                    .equatable()
                }
            }
        }
    }

    private func handleDateSelection(_ date: Date) {
        DateTravelerSelectorUtils.handleDateSelection(
            date: date,
            selectedDates: &selectedDates,
            dateSelectorModel: model,
            selectionMode: model.selectionMode,
            openDaysSet: openDaysSet
        )
    }
}

UI는 셀 상태를 전혀 계산하지 않습니다.

Core에서 만들어준 DateViewData만 그대로 렌더링합니다.

② Core가 계산한 DateViewData를 그대로 그린다

DTSMonthView(
    month: month,
    dateViewData: monthDateViewData[month] ?? [],
    onDateSelected: { date in handleDateSelection(date) }
)

SwiftUI는 Equatable 적용 덕분에 “변경된 셀만 최소로 다시 그리기”가 가능해 성능이 매우 안정적으로 유지됩니다.

③ 실제 도메인 화면에서는 이렇게 재사용된다

Calendar Core는 도메인별로 달력 정책이 달라도, DateSelectorModel만 다르게 주입하면 그대로 동일한 ScrollableCalendarView를 재사용할 수 있습니다.

• 국내 숙소 - 체크인/체크아웃 Range 달력

let model = DateSelectorModel(
    startDate: today,
    endDate: today.adding(days: 180),
    consecutiveDays: 30,
    selectionMode: .range
)

ScrollableCalendarView(
    dateSelectorModel: model,
    openDaysSet: openDates,
    monthDateViewData: $monthData,
    selectedDates: $selectedDates
)

• 패키지- 출발일 단일/멀티 선택

let model = DateSelectorModel(
    startDate: today,
    endDate: today.adding(days: 365),
    maxSelectableDays: 31,
    selectionMode: .multi
)

ScrollableCalendarView(
    dateSelectorModel: model,
    openDaysSet: openDates,
    monthDateViewData: $monthData,
    selectedDates: $selectedDates
)

Calendar Core를 중심으로 UI · 정책을 완전히 분리하면서 여기어때의 패키지·국내숙소·해외숙소·찜 등 다양한 화면을 하나의 SwiftUI 캘린더 컴포넌트로 유연하게 구성할 수 있게 되었습니다.

[ DateTravelerSelector (도메인별) ]
          ↓ 모델 주입
[ Calendar Core ] — 날짜 상태 계산
          ↓ DateViewData
[ ScrollableCalendarView ] — 그리기 + 이벤트 전달

UI는 얇고 단순하게 유지되고, 정책 변경은 Core에만 손대면 되기 때문에

확장성·재사용성·유지보수성 모두 크게 개선된 구조입니다.

👥 인원 선택(Traveler Selector) 구조

Calendar Core와 마찬가지로, 인원 선택도 도메인별 정책 차이가 컸기 때문에 완전 공통화가 쉽지 않은 영역이었습니다.

그래서 날짜 선택과 동일한 철학으로, UI는 얇게·정책은 밖에서 주입하는 구조로 재설계했습니다.

1. TravelerView는 “공통 UI 컴포넌트”, 정책은 외부에서 주입하는 방식

TravelerView는 아래 요소들이 모두 외부에서 전달되는 구조로 되어 있습니다

• 어떤 도메인인지(layoutType: package/domestic/overseas/favorite)
• Traveler 목록(성인/아동/객실 등)
• 최소/최대 인원 규칙
• 메시지(안내문구)
• 객실 수 필요 여부
• 아동 나이 선택 필요 여부

즉, 인원 정책은 뷰 내부에 박혀있지 않고, 모두 TravelerViewData로 주입됩니다.

struct TravelerViewData {
    let layoutType: TravelerView.TravelerLayoutType
    let travelers: [Traveler]
    let minTravelerCounts: [TravelerCategory: Int]
    let maxTravelerCounts: [TravelerCategory: Int]
    let minRoomCount: Int?
    let maxRoomCount: Int?
    let messages: [TravelerMessage]
}

해외 숙소 예시를 하나만 보면 흐름이 더 잘 보입니다.

// 예: 해외 숙소 인원 선택용 ViewData 구성 예시 (축약 버전)
let viewData = TravelerViewData(
    layoutType: .overseas,
    travelers: [
        .init(category: .adult, subTitle: "총 성인 수"),
        .init(category: .child, subTitle: "총 아동 수(만 0세~17세)")
    ],
    messages: [
        .init(text: "인원 관련 안내 메시지 1 ..."),
        .init(text: "인원 관련 안내 메시지 2 ...")
    ],
    minTravelerCounts: [.adult: 1, .child: 0],
    maxTravelerCounts: [.adult: 4, .child: 3],
    minRoomCount: 1,
    maxRoomCount: 3
)

TravelerView(
    viewData: viewData,
    selectedTravelerCounts: $selectedTravelerCounts,
    selectedRoomCounts: $selectedRoomCount,
    selectedChildAges: $selectedChildAges
)

TravelerView는 단순히 이 데이터를 렌더링하는 역할만 수행합니다.

• Stepper UI 배치
• 메시지 박스 노출
• 아동 나이 선택 UI
• 객실 스텝퍼
• +/-버튼과 현재 값 상태 바인딩

등 UI 작업만 담당하고, 정책 판단은 단 하나도 하지 않습니다.

현재 여기어때에서는 도메인별로 인원 구성이 아래처럼 사용되고 있습니다.

• 패키지: 성인 · 아동 · 유아 3종 인원 구성
• 국내숙소: 성인 + 아동 통합 인원 1종그
• 해외숙소: 성인 · 아동 분리 인원 + 아동 나이 + 객실 수
• 찜: 해외와 동일한 구성(성인·아동 분리 + 아동 나이) 단, 객실 수 없음

이렇게 도메인별 차이는 모두 외부 데이터(TravelerViewData)에서 정의하고,

TravelerView는 그 정보를 받아 동일한 레이아웃 규칙에 맞춰 그리기만 하기 때문에 코드 한 줄 수정 없이도 여러 도메인에서 공통으로 재사용할 수 있습니다.

2. DateTravelerSelector에서 “달력 + 인원”을 조립하기만 하면 끝

최종 DateTravelerSelector 화면에서는 아래처럼 조립만 하면 됩니다:

[ ScrollableCalendarView ]     ← 날짜 선택 (공통)
[ TravelerView ]               ← 인원 선택 (공통)

모든 도메인은 자신들의 정책대로 TravelerViewData만 만들어서 전달하면 되고, TravelerView 내부 코드나 레이아웃 분기에는 손댈 일이 없습니다.

이 방식의 장점은 명확합니다.

• UI는 절대 복잡해지지 않음 (단순 렌더링 계층 유지)
• 도메인 정책이 추가되어도 TravelerViewData만 확장하면 됨
• 패키지·국내·해외·찜 화면이 공통 컴포넌트를 100% 그대로 재사용
• 유지보수 포인트가 Calendar Core와 동일하게 한 곳으로 정리됨

✨ 마무리하며

이번 구조 개편을 통해 Date·인원 선택 UI는 도메인별 정책 차이를 유지하면서도, SwiftUI 기반의 일관된 Calendar Core + 가벼운 UI 레이어 구조로 재정비되었습니다.

덕분에 패키지·국내숙소·해외숙소·찜 등 다양한 화면에서같은 컴포넌트를 안정적으로 재사용할 수 있게 되었고, 앞으로 새로운 정책이 추가되더라도 Core 확장만으로 대응 가능한 구조를 갖추게 되었습니다.

긴 글 읽어주셔서 감사합니다.

더 나은 구조를 위한 고민과 경험을 계속 공유해보겠습니다!