프런트엔드 날짜 선택기를 위한 친절한 가이드

• 복잡한 JavaScript 날짜 선택기 대신 단순하고 접근성 높은 입력 방식을 제안하는 가이드
• 브라우저 기본 입력 요소(date, time, datetime-local)를 활용하면 접근성, 성능, 국제화 지원을 자동으로 얻을 수 있음
• 분리된 입력 필드나 마스크 입력, 라디오 버튼 그룹 등으로 복잡한 UI를 단순화 가능
• React 등 프레임워크에서도 기본 HTML 입력 요소를 그대로 사용할 수 있으며, 스타일은 제한적이지만 사용자에게 익숙한 시스템 UI 유지
• 모든 날짜 선택기는 접근성 문제가 있으므로, 단순한 입력 구조와 실제 사용자 테스트가 성공적인 폼 설계의 핵심

---

JavaScript 날짜 선택기가 꼭 필요한가

• 대부분의 경우 별도의 JavaScript 날짜 선택기는 불필요함
  • 복잡한 UI는 오류와 폼 포기를 유발
  • 달력 위젯보다 더 쉬운 날짜 입력 방식 존재
• 이 가이드는 사용자 친화적 인터페이스를 위한 대안 제시 목적

브라우저 기본 날짜·시간 입력

• 모든 최신 브라우저는 기본 date, time, datetime-local 입력 타입을 지원
  • date는 날짜 선택, time은 시·분 입력, datetime-local은 둘을 결합
• 기본 입력은 한 줄의 코드로 구현 가능하며, 브라우저가 접근성·성능·국제화를 처리
  • 키보드 입력 지원, 기본 달력 UI 제공
  • 완벽하지 않지만 대부분의 JavaScript 라이브러리보다 안정적
• 단, 일부 접근성 문제는 여전히 존재

분리된 입력과 선택 요소

• 하나의 날짜 선택기보다 연·월·일을 분리한 입력이 사용성 향상
  • GOV.UK의 date input 컴포넌트 예시 제시
• 유효한 데이터가 제한적일 경우 select 요소 사용이 적합
  • 입력 오류 방지, 상호작용 감소
  • 숫자형 월 표기 시 스크린리더 오독 주의
• 여행 예약 등 고정된 시간 간격(예: 15분 단위)에는 상대적 날짜(오늘, 내일) 표현이 유용

마스크 입력과 유효성 검증

• 마스크 입력 필드는 달력 없이 날짜 형식을 유도하는 대안
  • JavaScript로 클라이언트 측 검증 및 형식화 가능
  • 예: “2월의 유효한 일자를 입력하세요(1~28)” 오류 메시지
  • Intl API로 날짜 형식 자동 포맷
• 단, JavaScript로 입력값을 갱신하면 undo/redo 기능이 깨질 수 있음
• CSS로 여러 입력을 시각적으로 하나처럼 보이게 결합 가능

범위 선택과 제한된 옵션

• 두 달력을 사용하는 범위 선택형 날짜 선택기는 조작이 어렵고 포인터 없이 사용하기 불편
  • 대신 두 개의 입력 필드로 단순화 가능
• 선택 가능한 날짜만 필요한 경우 radio 입력 그룹으로 대체 가능
  • 복잡한 UI 대신 단순한 단계적 작업으로 구성
  • 다단계 폼을 JavaScript로 단일 페이지 인터랙션으로 확장 가능

자유 입력과 제안 기능

• 정확한 날짜·시간이 필요하지 않을 때는 기본 텍스트 입력이 유용
• datalist 요소를 사용하면 입력 제안 제공 가능
  • date, time 입력 타입과도 함께 작동

자주 묻는 질문

JavaScript 프레임워크 사용 시

• 모든 주요 프레임워크는 기본 HTML 요소 사용 가능
  • 커스텀 컴포넌트로 만들 필요 없음
  • value 속성으로 양방향 상태 바인딩 가능

기본 날짜 선택기 스타일링

• input 요소 일부만 스타일 가능, 나머지는 불가능
  • 이는 사용자에게 익숙한 시스템 UI를 유지하기 위한 장점
  • 운영체제·입력 방식·브라우저에 따라 디자인이 다름
  • 추가적인 디자인 통일은 불필요

JavaScript 날짜 선택기를 요구하는 이해관계자 대응

• 목표는 성공적인 폼 제출이며, 복잡한 UI는 오류를 증가시킴
  • 모든 날짜 선택기는 접근성 문제 존재
  • 기본 입력 조합이 더 사용자 친화적
  • 검증되지 않은 JavaScript UI는 유럽 접근성법(EAA) 등 규제에 저촉될 수 있음
  • 단순함이 성공의 핵심

접근성 테스트와 보장

• WCAG 등 접근성 가이드라인 이해가 필수
  • 웹 표준을 활용해 커스텀 UI 오류 방지
• 브라우저 개발자 도구의 접근성 기능으로 오류 탐지 가능
  • 완벽한 도구는 없으며, 실제 사용자 테스트가 유일한 검증 방법
• 접근성 오버레이 사용은 강력히 비추천, 오히려 문제를 악화시킬 수 있음

접근성 관련 참고 자료

• Collecting dates in an accessible way — Graham Armfield
• What makes an accessible date picker? — Russ Weakley
• Maybe You Don’t Need a Date Picker — Adrian Roselli
• Date Picker Dialog Example — ARIA Authoring Practices Guide
• Designing The Perfect Date And Time Picker — Vitaly Friedman

JavaScript 날짜 선택기 추천 요청에 대한 답변

• 보편적 해결책은 없음, 모든 날짜 선택기는 한계 존재
• 이 가이드는 요구사항을 스스로 평가할 수 있도록 돕는 목적
• 가능한 한 단순한 방법으로 목표 달성 권장
• 날짜 선택기가 반드시 필요한 것은 아님

결론

• 실제 사용자 테스트와 피드백 수집이 필수
• 이 가이드는 진행 중이며, 피드백 환영

[GN⁺]

Hacker News 의견

• 몇 년 전 지역 병원 환자용 모바일 앱을 만들었음. 사용자 중에는 고령층이 많았는데, OS 기본 날짜 선택기가 너무 불편하다는 불만이 쏟아졌음
  “생년을 설정할 수가 없다”, “내 생일까지 가려면 이전 달 화살표를 720번 눌러야 했다” 같은 이야기들이 실제로 있었음
  iOS와 Android 모두 당시에는 연도가 단순한 제목처럼 보여서 클릭 가능한 요소로 인식되지 않았음
  미적 감각 중심의 Flat Design이 UX를 망치고 있다고 느낌. Don Norman 같은 UX 전문가가 아닌, 디자이너 중심으로 OS UI가 결정되는 현실이 문제라고 생각함
  결국 텍스트박스-드롭다운-텍스트박스(일-월-연도) 형태로 바꾸자 불만이 사라졌음
  • 영국 정부의 Gov.uk 디자인팀 연구에서도 같은 결론을 냈음.
    세 개의 텍스트박스(일, 월, 연도)가 가장 좋은 경험을 제공한다고 함.
    구현을 위한 패턴 가이드도 있음
  • 나도 처음 그 입력창을 쓸 때 100번 넘게 탭하다가 ‘이건 이상하다’ 싶어 검색해봤던 기억이 있음. 진짜 UX 악몽이었음
  • “연도가 클릭된다고??”라는 반응이 절로 나올 정도로 직관성이 없었음
  • 나도 그 달력에서 연도 이동 방법을 몰라 한참 헤맸던 적이 있음
  • 그런데 왜 생년월일 입력에 굳이 캘린더 피커를 썼는지 궁금함
• 여행 예약처럼 일정이 정해진 경우에는 “오늘”, “내일” 같은 상대적 날짜 표현이 편할 수 있음
  하지만 자정 무렵 비행기를 예약할 때 “오늘”이 내 시간대 기준인지, 서버 기준인지, GMT인지 헷갈림
  • “오늘”, “내일” 같은 상대적 날짜는 아이디어는 좋아 보이지만 구현은 지옥임.
    시간대, 서머타임, 월말(1월 31일 → 다음 달?), 자정 직후 등 예외가 너무 많음.
    이런 기능을 넣기 전엔 정말 신중해야 함
  • 몬트리올 대중교통은 예전에 28시간제 시계를 썼음. 자정 이후 버스가 27:30 같은 식으로 표시돼서 매우 혼란스러웠음
  • 컴퓨터가 ‘오늘’을 자정 기준으로 정의하는 게 싫음.
    새벽 12시 넘어서 일하다 보면 “내일”이라는 표현이 현실 감각과 어긋남.
    실제로는 “오늘 아침 이후”를 의미하는데 시스템은 다음 날로 인식함
  • 하지만 “오늘”이든 “11월 12일”이든, 시간대가 다르면 같은 문제가 발생함
• 20년 넘게 datepicker를 다뤄본 경험상, 그냥 input type="text"에 포맷 힌트를 주는 게 최선임
  브라우저, 접근성, 로케일 문제 등으로 고생하지 않음
  커스텀 컴포넌트는 진짜 지옥의 문임. 괜히 멋 부리다 10개의 토끼굴에 빠짐
  • 생일처럼 이미 알고 있는 날짜엔 괜찮지만, 비행기 검색처럼 “4월 초 금요일쯤”을 찾을 땐 달력이 필요함.
    날짜를 시각적으로 탐색해야 하니까
  • 어떤 포맷 힌트를 넣든 “3-9-1980”이 사용자에게 3월 9일인지 9월 3일인지 신뢰할 수 없음
  • 이건 나쁜 조언임. ISO 8601은 과거 시점엔 괜찮지만 미래 예약이나 국경 간 일정에는 맞지 않음.
    날짜 문제는 정말 복잡해서 사용 사례별 접근이 필요함
  • 그래도 모바일에서 연도 선택이 안 되는 달력보단 훨씬 낫다고 생각함
• 국제화를 이야기하면서 서양식 날짜 형식만 지원하는 건 웃김
  네팔 병원 시스템을 만든다면 네팔력과 일반력 둘 다 지원해야 함. 네팔력은 매우 복잡함
  에티오피아는 13개월 달력을 쓰는데, 마지막 달은 5~6일짜리임
  제대로 된 국제화 date picker 참고자료가 있다면 알고 싶음
• 날짜 입력의 맥락이 어떤 피커를 쓸지 결정해야 함
  예를 들어 저녁 예약은 주말 가용성을 보기 위해 달력이 유용하지만, 생일 입력은 숫자로 빠르게 입력하는 게 효율적임
• 신용카드 정보를 입력할 때처럼 숫자 입력 흐름이 중요한 경우,
  “월 이름 선택 → 드롭다운 → 연도 선택” 같은 과정은 리듬을 깨뜨림
  그냥 숫자만 입력하는 방식이 훨씬 자연스러움. 모바일에서는 키보드가 계속 열리고 닫혀서 더 불편함
• 키보드로 바로 입력할 수 있는 date picker를 보니 신선함
  기본 UI 대신 커스텀 피커를 강제하는 건 이상함.
  특히 Android에서 iOS 스타일의 휠 회전형 시간 선택기를 웹으로 흉내 낸 건 최악임
• 덴마크인으로서 “Pikaday”라는 이름이 웃김. “pik”은 덴마크어로 남성 성기 속어임
  • “그럼 포켓몬은 덴마크에서도 인기 있나요?”라는 농담이 나올 정도였음
• Date, Time, DateTime 피커만으로는 부족함
  월 단위, 주 단위, 커스텀 구간 선택기도 필요함. 네이티브 폼 요소가 너무 제한적임
  • <input type="week">나 <input type="month">에 Firefox 지원 외에 부족한 게 있는지 궁금함
  • 나는 그리스 신 크로노스의 힘을 빌린 AI 시간 피커가 있었으면 좋겠음
• 참고로 이 논의의 맥락은 Pikaday 관련 글에 있음
  • 예전에도 Pikaday라는 datepicker 라이브러리를 썼던 기억이 있음