Q7. 카드 정보 input — 제약은 어떤 도구로 거는 게 맞을까?

크루의 질문

“카드 정보를 입력하는 input 컴포넌트에서 최대 길이가 넘으면 입력을 못하게 하기 위해서 maxLength라는 props를 받도록 했는데, input 태그에서 maxLength를 설정하려면 type=‘number’ 상태가 불가능해서 문자열이 입력이 가능한 상태가 되었고, input 기본 속성으로 최대 길이 제한 vs 문자열 입력 제한 중 선택해야 했어서 결국 maxLength를 선택하고 카드 정보를 입력하는 input 컴포넌트에서는 고정으로 문자열을 입력하지 못하도록 함 (코드 작성이 더 쉬워서). 근데 input이 문자열을 입력하지 못하게 된다면 범용성이 떨어지게 될 것 같아서 좋지 않은 선택이라는 생각이 들기도 했는데, 한편으로는 카드 정보 입력이라는 도메인 규칙에서는 나쁘지 않은 선택이었다는 합리화를 하기도 했습니다.” — 라바·찰리 페어

AS-IS 코드

🔍 읽기 전에

두 코드는 무엇을 다르게 강제하나요?

type='number'가 잡아주는 것과 놓치는 것은 무엇일까요?

// 두 패턴이 공존하는 상황 — 어느 쪽이 더 견딜까?
 
// (a) type="number" + 자동 길이 제한 X
<input
  type="number"
  value={cardNumber}
  onChange={handleChange}
/>
 
// (b) type="text" + maxLength + 별도 숫자 검증
<input
  type="text"
  inputMode="numeric"  // 모바일 숫자 키패드 유도
  pattern="[0-9]*"
  maxLength={4}
  value={cardNumber}
  onChange={(e) => {
    if (/^\d*$/.test(e.target.value)) handleChange(e);
  }}
/>

라바·찰리 페어가 마주한 trade-off의 핵심: HTML input은 type="number"에서 maxLength를 적용하지 않는다. 그래서 최대 길이 제한이 중요하다면 type="text" + inputmode + 별도 검증 쪽을 검토해야 하고, type="number"는 길이가 아니라 숫자 입력 UI와 숫자 제약(min·max·step)에 가까운 도구로 봐야 한다.

공식문서 단서 — MDN HTMLInputElement

이 카드는 React 영역이 아니라 HTML 표준 영역입니다. 두 권위 문서를 함께 봅니다.

MDN — <input type="number">

• 원문: developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number 
• 핵심: <input type="number">는 min·max·step을 지원하지만 maxLength는 적용되지 않는다. 길이 제한이 필요하면 다른 도구를 써야 한다.

MDN — inputmode 속성

• 원문: developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode 
• 핵심: inputmode="numeric"을 type="text"와 함께 쓰면 모바일에서 숫자 키패드를 띄우면서도 maxLength·pattern을 함께 쓸 수 있다. 카드번호 입력의 현실적 표준에 가깝다.

React docs — <input> 컴포넌트

• 원문: react.dev/reference/react-dom/components/input 
• 핵심: React가 별도로 만든 행동이 아니라 HTML 표준 그대로 동작한다. type="number"의 한계는 React에서도 같다.

선배 PR 읽기 가이드

추가 읽을거리 — MDN · Dan Abramov

연관 PR 더 보기

이 주제는 카드별 명시적 매핑보다는 코드 패턴에서 드러나므로 부록에 별도 매핑되어 있지 않습니다. 자기 가설에 가까운 패턴이 궁금하면, 195개 PR을 부록에서 펼쳐 코드 발췌를 직접 따라가보세요. 특히 Q4 공통 Input 컴포넌트 합성에 매핑된 PR들이 보통 input 제약 결정도 함께 다룹니다.

라바·찰리 페어가 인지한 “도메인 규칙에서는 나쁘지 않은 선택”이라는 합리화 자체가 학습 포인트입니다. 공통 컴포넌트는 언제 도메인을 좁혀도 되는가 — 이 질문은 Q4와도 이어집니다.