만들지 않기로 했어요

지난 글에서 KRDS 컴포넌트 라이브러리를 만들기로 결심한 이야기를 했어요. 그런데 결심하자마자 첫 번째 고민이 왔어요. 빈 폴더를 열어놓고 한참을 생각했죠.

"전부 직접 만들까, 아니면 이미 있는 것 위에 얹을까?"

직접 만들고 싶은 유혹

KRDS를 구현하는 거니까, KRDS만 바라보고 처음부터 만드는 게 가장 순수한 방법처럼 보였어요. 모든 걸 통제할 수 있으니까요.

그런데 팝업(모달) 하나를 뜯어보면 생각이 달라져요. 화면에 보이는 건 흰 상자 하나지만, 그 뒤에는 보이지 않는 일이 산더미예요. 팝업이 열리면 키보드 초점이 팝업 안에 갇혀야 하고, ESC 키로 닫혀야 하고, 닫히면 원래 자리로 초점이 돌아가야 하고, 화면낭독기(화면 내용을 음성으로 읽어주는 프로그램)에 "지금 팝업이 열렸다"고 알려줘야 해요. 이걸 틀리면 눈과 마우스로 쓰는 사람은 못 느껴도, 키보드와 낭독기로 쓰는 사람에게는 들어가면 못 나오는 방이 돼요.

이런 보이지 않는 동작을 41개 컴포넌트에서 전부, 처음부터, 실수 없이 만든다? 자신이 없었어요.

잘하는 것 위에 얹기로 했어요

그래서 shadcn/ui 위에 얹기로 했어요. shadcn/ui는 전 세계 개발자들이 널리 쓰며 검증해온 컴포넌트 모음이에요. 방금 말한 보이지 않는 동작들 — 키보드, 초점, 낭독기 대응 — 이 이미 들어 있죠.

비유하면 뼈대가 튼튼한 기성 가구를 사서 우리 집에 맞는 색으로 칠하는 거예요. 뼈대(동작)는 검증된 걸 쓰고, 겉(KRDS의 색과 크기)만 입히는 거죠.

규칙도 세웠어요. 원본에는 절대 손대지 않기. 원본을 고치기 시작하면 나중에 원본이 업데이트될 때 고친 부분이 사라지거나 꼬이거든요. 그래서 원본은 그대로 두고, 그 위에 KRDS 옷을 입히는 별도의 층(래퍼)을 만들었어요. 실제 코드에서 래퍼가 하는 일은 이게 거의 전부예요.

<DialogPrimitive.Content
  className={cn(
    "fixed top-[50%] left-[50%] ...",
    // KRDS 토큰만 덧입힘 — 동작은 전부 원본의 것
    "bg-krds-surface border-krds-border rounded-[12px] border p-6",
    variantClass,
    className
  )}
>

코드를 몰라도 괜찮아요. 요지는 "동작은 한 줄도 다시 만들지 않고, 겉모습만 입혔다"는 거예요.

예외도 있었어요

딱 하나, 버튼만은 감싸지 않고 직접 만들었어요. KRDS의 버튼은 원본과 치수 체계 자체가 달라요. 기본 높이부터 글자 크기까지 전부 더 큰데, 공공 서비스의 넓은 사용자층을 위한 설계죠. 감싸서 해결하려니 원본 스타일과 계속 싸우게 됐어요. 이건 오래 고민할 것도 없이 금방 분명해졌고요. 대신 "어디까지 오면 직접 만드는가"의 기준을 규칙으로 적어뒀어요. 다음에 같은 상황을 만나도 같은 결정을 내릴 수 있게요.

그 밖의 규칙들 — "색상 값을 직접 쓰지 말고 정해진 이름으로만 쓴다" 같은 것들 — 도 문서에만 적지 않고 최대한 코드가 스스로 지키게 만들었어요. 문서에 적힌 규칙은 바쁠 때 가장 먼저 잊히니까요.

배운 것

만들지 않기로 한 결정이, 만들기로 한 어떤 결정보다 어려웠어요. 직접 만들면 전부 통제할 수 있을 것 같고, 실력을 보여줄 수 있을 것 같거든요. 그런데 이 프로젝트의 목적은 실력 증명이 아니라 "믿고 쓸 수 있는 부품"이었어요. 목적을 기준에 놓으니 답이 보였어요. 검증된 것을 다시 만드는 건 용기가 아니라 낭비더라고요.

다음 글은 색 이야기예요. 정부의 파랑에는 번호가 있는데, 그 번호의 공식 이름을 버려야 했던 고민 — 「정부의 파랑은 몇 번일까」로 이어져요.