KRDS React 컴포넌트 구현 시간 비교 - 직접 코딩 vs HANUI

"KRDS 가이드라인 문서 어디 있어요?"

공공기관 SI 프로젝트 시작하면 항상 듣는 말이에요. 그리고 PDF 열어서 색상 코드 찾고, 간격 값 복사하고... React 컴포넌트 하나 만드는 데 반나절이 가요.

오늘은 실제 코드로 Before/After를 보여드릴게요. HANUI 쓰면 얼마나 줄어드는지.

Case 1: 버튼 만들기

Before: KRDS PDF 보고 직접 구현

After: HANUI 사용

소요 시간: 10초

variant 8종, size 6종, 로딩 상태, 아이콘 지원까지 전부 들어있어요. 접근성? aria-busy, aria-disabled, 포커스 링 전부 적용되어 있고요.

Case 2: 폼 필드 만들기

Before: 직접 구현

After: HANUI 사용

Context로 id, aria 속성 자동 연결. 에러 아이콘, 성공 아이콘 자동 표시. role="alert", aria-live="polite" 적용.

Case 3: 헤더 + 메가메뉴

이건 진짜 직접 만들면 며칠 걸려요.

Before: 직접 구현하면 고려할 것들

• 반응형 (모바일 햄버거 메뉴)
• 메가메뉴 드롭다운
• 키보드 네비게이션 (Tab, Arrow, Escape)
• 포커스 트랩
• 스크롤 시 헤더 고정/숨김
• WAI-ARIA 패턴

솔직히 제대로 만들려면 일주일은 잡아야 해요.

After: HANUI 사용

메가메뉴, 모바일 대응, 키보드 네비게이션, 스크롤 동작까지 전부 포함.

진짜 비교

작업	직접 구현	HANUI
버튼 (variant 포함)	2-3시간	10초
폼 필드 (접근성 포함)	3-4시간	10초
헤더 + 메가메뉴	3-5일	10초
Select (검색, 다중선택)	1-2일	10초
모달 (포커스 트랩)	반나절	10초

그리고 직접 구현하면 빠뜨리기 쉬운 것들:

• aria-describedby 연결
• aria-expanded, aria-haspopup
• 포커스 관리
• Escape 키로 닫기
• 스크린 리더 공지

HANUI는 이런 거 전부 들어가 있어요.

숨겨진 비용

직접 구현의 진짜 문제는 시간만이 아니에요.

1. 일관성 깨짐

2. 접근성 누락

바쁘면 aria 속성 빼먹게 돼요. "나중에 추가하지 뭐" 하다가 검수 때 걸려요.

3. 유지보수 지옥

KRDS 가이드 업데이트되면? 전체 코드 다 수정해야 해요.

HANUI 쓰면

5분이면 프로젝트 세팅 끝. 나머지 시간은 비즈니스 로직에 집중할 수 있어요.

커스터마이징?

"우리 프로젝트는 색상이 좀 달라요"

그래서 복사 방식이에요. 파일 열어서 수정하면 돼요.

마무리

KRDS 컴포넌트 만드는 데 시간 쓰지 마세요.

이 세 줄이면 시작할 수 있어요.