📘 감정일기 작성 화면에서 날짜 선택 UI는 어떻게 설계해야 할까?— 달력을 직접 넣을까, 시트로 띄울까? 구조적 고민과 결론 정리

 

감정일기를 작성하는 6단계 UI를 만들면서,
마지막 단계(6/6)에서 날짜 + 사진을 선택하는 화면을 구현해야 했다.

처음엔 단순히 UILabel로 “2025년 12월 10일” 같은 표시만 하고,
여기를 탭하면 날짜를 선택하게 만들면 되겠다고 생각했다.

문제는 날짜 선택 UI를 어떻게 노출할 것이냐였다.

 

1. 두 가지 설계안 비교하기

날짜를 선택하는 UI는 크게 두 방향으로 구현할 수 있었다.

① Label을 탭 → Bottom Sheet → 달력 뷰 띄우기

(달력은 따로 만든 UICollectionView 기반 CalendarVC 사용)

이 방식은 카카오톡, 슬랙, 노션 등 대부분의 앱에서 사용하는 형태이다.
필요할 때만 달력이 화면에 나타나고, 선택하면 즉시 내려간다.

 

② 마지막 단계 셀 내부에 달력을 직접 넣기

(Cell 안에 UICollectionView를 그대로 넣어서 달력 UI 전체를 표시)

즉, DiaryWriteDateAndGalleryCell 내부 UI로 달력 전체가 들어가 버리는 구조다.

 

두 구현 모두 한 화면 안에서 날짜를 선택할 수 있다는 점에서는 동일하지만,
장기적인 유지보수와 UX 기준에서는 큰 차이가 있다.

 

2. 결론: 두 방식 중 정답은 ① Bottom Sheet 방식

간단히 말하면,

👉 Label을 탭하면 Bottom Sheet로 날짜 선택 화면을 띄우는 방식이 압도적으로 더 좋다.

왜 그런지 UI/UX · 아키텍처 · 성능 관점으로 하나씩 정리해보자.

 

3. 왜 Bottom Sheet 방식이 더 좋은가?

✔ 3-1. 현재 작성 단계UI 흐름과 가장 자연스럽게 맞기 때문

지금 감정일기 작성 UI는 총 6단계(step-by-step) 로 구성되어 있다.

• emotion
• situation
• thought
• reeval
• action
• dateAndImages ← 마지막 단계

여기서 갑자기 큰 달력 UI가 나타나면?

• UI 맥락이 갑자기 바뀜
• 마지막 단계가 "요약/완성" 느낌인데 갑자기 UI가 너무 무거워짐
• 화면 높이를 차지하는 요소가 늘어나면서 스크롤이 길어짐

반대로,
“날짜를 선택하세요 → 라벨 표시 → 탭하면 달력”
이라는 구조는 작성 흐름을 전혀 방해하지 않음.

 

✔ 3-2. 달력을 셀 안에 넣는 것은 메모리·성능 측면에서 비효율적

내가 만든 달력은 UICollectionView 기반이라:

• 월 데이터 모델
• 날짜 셀 렌더링
• 선택 상태 관리
• diffable datasource 적용

이런 내부 로직이 이미 복잡하다.

이걸 DiaryWrite의 셀 안에 넣으면,

• 셀 재사용 과정에서 상태 꼬일 위험
• 스크롤 시 매번 달력 로직이 호출됨
• 셀이 두 개만 있어도 달력 뷰가 여러 번 만들어짐
• 메모리 사용량이 불필요하게 증가함

즉, 달력은 독립적인 ViewController로 다루는 것이 가장 합리적이다.

 

✔ 3-3. UX 측면에서도 Bottom Sheet가 더 익숙하고 부담이 없다

대부분의 앱이 날짜 선택을 아래 방식으로 처리한다:

• iOS 기본 DatePicker → bottom sheet
• 카카오톡 일정 → bottom sheet
• 구글 캘린더도 modal/calendar picker 사용

사용자 입장에서도,
현재 화면을 유지한 채, 일부 UI만 위로 올려서 선택하는 구조가
훨씬 자연스럽고 피로도가 낮다.

 

✔ 3-4. 유지보수 및 확장성이 훨씬 좋다

Bottom Sheet 방식의 핵심 장점:

• CalendarViewController를 재사용 가능
• 다른 기능에서도 날짜 선택 UI가 필요하면 그대로 이용 가능
• 작성 화면과 달력 로직이 깔끔히 분리됨
• MVVM 구조에 맞게 역할 분리가 쉬움

반대로 셀 내에 달력을 넣으면:

• 로직이 뭉치고
• 셀의 책임 범위가 비대해지고
• 기능 확장이 매우 어렵다

4. 실제 구현 구조 (추천 아키텍처)

4-1. Cell(마지막 스텝)의 역할

• 현재 선택한 날짜 표시(label)
• label 탭 → onTapDatePicker 콜백 호출

var onTapDatePicker: (() -> Void)?

 

4-2. ViewController의 역할

• label 탭 시 → Bottom Sheet 띄우기

cell.onTapDatePicker = { [weak self] in
    self?.presentDatePickerSheet()
}

 

4-3. CalendarViewController의 역할

• 달력 UI 그리기
• 날짜 선택 후 onDateSelected 호출

var onDateSelected: ((Date) -> Void)?

 

4-4. 선택된 날짜가 오면 ViewModel에 저장

datePicker.onDateSelected = { [weak self] date in
    self?.viewModel.updateDate(date)
    self?.reloadCell(for: .dateAndImages)
}

 

 

5. 실제 앱 흐름 예시

[감정일기 작성 6단계 화면]
     ⬇
[날짜 라벨 탭]
     ⬇
[Bottom Sheet로 달력 띄움]
     ⬇
[날짜 선택 → sheet 닫힘]
     ⬇
[Cell 라벨 자동 업데이트]

 

6. 최종 결론

달력을 직접 셀에 넣는 방식
→ UI 무거워짐 · 메모리 비효율 · 재사용 문제 · 구조 복잡

Label + Bottom Sheet 방식(달력은 독립 VC)
→ UI 깔끔 · UX 친숙 · 유지보수 쉽고 확장성 높음 · 아키텍처적으로도 정석

따라서 감정일기 작성 마지막 단계에서
날짜 선택 UI를 구현할 때는,

🎯 “라벨을 탭하면 Bottom Sheet로 달력 ViewController를 띄우는 방식을 사용한다.”