beUI signup-form 회원가입 폼 블록 기본값과 수정 포인트

beUI signup-form 블록은 bunx --bun shadcn add @beui/signup-form 한 줄로 설치되고, 비밀번호 8자 최소값과 blur 뒤 오류 표시 같은 기본값이 코드에 박힌 채 들어옵니다.

코드는 파일 하나가 아니라 열 개가 넘는 묶음으로 들어와 프로젝트 소스로 남습니다. 그래서 무엇이 이미 정해져 있고 어느 줄을 갈아 끼워야 하는지부터 알고 붙여야 합니다.

오류 표시와 강도 막대는 그대로 두고 씁니다

beUI signup-form 은 오류를 언제 보여줄지까지 코드로 정해 두었습니다. 검증 자체는 값이 바뀔 때마다 다시 계산되지만, 오류는 포커스가 그 칸을 벗어난 뒤에야 화면에 나타납니다. 한 번 뜬 오류는 조건을 만족하는 즉시 사라지고, 제출을 누르면 모든 칸이 touched 로 바뀌어 남은 오류가 한꺼번에 드러납니다.

이 타이밍은 Mihael Konjević 가 2016년에 정리한 reward early, punish late 패턴입니다. 잘한 것은 빨리 알리고 혼내는 것은 늦추는 규칙이라, 오류 표시 쪽은 손대지 않고 그대로 쓸 만합니다.

비밀번호 칸 아래에는 막대 네 개와 라벨 다섯 종(Too short, Weak, Fair, Good, Strong)이 이미 붙어 있습니다. 다만 점수는 코드 주석이 밝힌 대로 엔트로피 추정이 아니라 길이 위주 피드백용이라, 유출 목록 대조는 서버에서 따로 해야 합니다.

설치하면 딸려 오는 것 — 의존성 4개와 버튼 파일들

설치는 bunx --bun shadcn add @beui/signup-form 한 줄입니다. shadcn 레지스트리에 등록된 블록이라 코드가 바깥 패키지로 격리되지 않고 프로젝트 소스로 들어와 남습니다. 설치 없이 컴포넌트 페이지에서 소스를 직접 복사해 붙여도 결과는 같습니다.

딸려 오는 외부 패키지는 clsx, lucide-react, motion, tailwind-merge 네 개입니다. 레지스트리 JSON의 registryDependencies 는 빈 배열이라 다른 UI 라이브러리를 추가로 끌어오지 않습니다. React 쪽은 useState 와 useCallback, useMemo, useId, useReducedMotion, useLayoutEffect 여섯 훅으로 돌아갑니다.

파일이 열 개를 넘는 이유는 버튼에 있습니다. 레지스트리의 button 디렉터리가 base, magnetic, stateful 세 종류로 나뉘어 폼과 함께 들어오기 때문입니다. 코드 전체는 beUI 저장소에 올라 있습니다.

제출 상태 네 가지를 넘기고 검증 함수는 바깥에서 바꿉니다

제출 상태는 idle, loading, success, error 네 가지입니다. 상태를 넘기면 버튼 글자와 아이콘이 따라 바뀌고, 글자 길이가 달라져도 버튼 폭은 흔들리지 않습니다.

검증 규칙은 defaultValidate 함수 하나에 모여 있고, 보는 항목은 다섯입니다. 전부 브라우저에서만 도는 검사라 값을 조작한 요청은 걸러내지 못하고, 같은 규칙을 서버에도 따로 두어야 합니다.

• 이름: 빈 값 불가
• 이메일: 정규식 /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 통과
• 비밀번호: 8자 이상
• 확인란: 비밀번호와 일치
• 약관: 동의 체크

그럼 규칙을 바꾸려면 컴포넌트 안을 뒤져야 할까요? 아닙니다. 검증 함수는 바깥에서 주입해 통째로 갈아 끼우는 구조이고, 값도 제어형과 비제어형 양쪽으로 받습니다. defaultValidate 를 복사해 조건만 고친 함수를 넘기면 나머지 동작은 그대로 유지됩니다.

붙여 넣기 전에 바꿀 값 — 8자 최소값과 유출 대조

beUI signup-form 블록을 붙여 넣은 뒤 첫 작업은 defaultValidate 의 비밀번호 조건 한 줄을 서비스 정책 값으로 바꾸는 일입니다. 기본값 8자를 그대로 둬도 되는지는 폼 코드가 아니라 인증 구성이 정합니다. 비밀번호 하나로 로그인하는 서비스와 OTP 를 얹은 서비스의 답이 다르기 때문입니다.

NIST SP 800-63B 개정 4판 3.1.1.2 절이 그 기준선입니다. 비밀번호가 단일 요소 인증이면 최소 15자, 다중 요소 인증의 한 요소면 최소 8자가 요구 사항(SHALL)입니다. 문자 종류를 섞으라는 구성 규칙은 부과 금지(SHALL NOT)이고, 새 비밀번호를 흔히 쓰이거나 유출된 값 목록과 대조하라는 요구도 같은 절에 붙어 있습니다.

EnzoicNIST SP 800-63B 개정 4판에서 달라진 항목을 정리한 글

유출 목록 대조는 블록에 없습니다. 강도 점수 주석이 서버에 맡기라고 한 것이 바로 이 공백입니다. 그래서 회원가입 API 에 대조 단계를 넣는 작업은 8자 조건 수정과 함께 해야 합니다.

채택을 가르는 기준은 인증 구성 하나입니다. 비밀번호가 유일한 인증 수단이면 defaultValidate 의 8자 최소값을 고치고 빠져 있는 유출 목록 대조를 채운 뒤에 붙입니다. OTP 같은 두 번째 요소가 이미 있다면 기본값 그대로 붙여도 됩니다.