컴포넌트 라이브러리를 처음부터 혼자 만든다고 상상해보자. 디자인 토큰 정의, 다크모드 대응, 접근성 마크업, 폼 컴포넌트 구현, 데이터 테이블 정렬 로직… 77개의 컴포넌트를 프로덕션 수준으로 완성하기까지 얼마나 걸릴까. dev.to에 올라온 SoftUI 제작기는 이 질문에 실질적인 답을 건넨다. 그리고 TestSprite MCP를 활용한 자동 테스트 생성 사례, 6시간 안에 Drupal 모듈을 완성한 AI 보조 프로토타이핑 경험까지 나란히 놓고 보면, 컴포넌트 라이브러리를 '어떻게 더 잘 만드는가'에 대한 윤곽이 선명하게 드러난다.
뉴모피즘으로 77개 컴포넌트를 만든다는 것
SoftUI는 프레임워크 의존성이 없는 순수 CSS 컴포넌트 라이브러리다. React도, Vue도, 빌드 스텝도 없다. CDN 링크 하나로 바로 쓸 수 있다. 뉴모피즘이라는 다소 도전적인 미학을 선택한 이유는 명확하다. 플랫 디자인과 머티리얼 그림자가 지배하는 시장에서 '촉감 있는 깊이감'이라는 차별화를 만들고 싶었기 때문이다.
하지만 뉴모피즘에는 해결해야 할 구조적 문제가 있다. 낮은 대비, 불분명한 포커스 인디케이터, 애니메이션 과부하. SoftUI 제작자가 가장 공들인 부분이 바로 여기다. WCAG AA 대비 기준을 모든 텍스트 컬러에 적용하고, :focus-visible 아웃라인을 빠짐없이 추가했으며, prefers-reduced-motion으로 모션 민감 사용자를 배려했다. 모달·탭·드롭다운에는 ARIA 속성과 키보드 내비게이션을 완전히 구현했다. RTL 지원과 프린트 스타일까지 포함한 것은 '데모 수준'이 아닌 '프로덕션 레디'를 목표로 했다는 증거다.
컴포넌트 라이브러리 설계에서 종종 후순위로 밀리는 결정들, 예를 들어 네이티브 브라우저 UI를 완전히 제거하고 커스텀 셀렉트·데이트피커·넘버 인풋으로 대체한 선택은 크로스 브라우저 일관성을 위한 비타협적 판단이다. CSS 커스텀 프로퍼티를 디자인 토큰처럼 구성한 것도 눈여겨볼 점이다. --sui-primary, --sui-bg, --sui-radius 같은 변수 하나로 테마 전체를 교체할 수 있다. 그럼에도 제작자는 "토큰 시스템을 처음부터 설계했어야 했다"고 회고한다. dist/tokens.json은 사후에 추가한 결과물이었다.
77개 컴포넌트를 모두 완성하고 나서야 배포를 시작한 것도 반성 포인트로 꼽는다. "20개의 단단한 컴포넌트로 먼저 출시하고 피드백을 받았어야 했다"는 말은, 라이브러리 개발에서 빠른 검증이 완벽한 완성보다 우선한다는 교훈이다.
AI가 테스트를 생성하면, 개발자는 무엇을 하는가
실시간 다국어 더빙 플랫폼 PolyDub 개발기에서 TestSprite MCP의 활용 사례가 눈에 띈다. 해커톤 압박 속에서 외부 API 오류 케이스와 프론트엔드 유효성 검증 로직까지 직접 테스트 코드를 작성하는 것은 현실적으로 불가능에 가깝다. TestSprite MCP는 Claude Code에 MCP 서버로 연결되어 코드베이스를 읽고, 테스트 플랜을 생성하고, 실행 가능한 테스트 코드를 작성한다.
결과는 구체적이다. 백엔드 5개 테스트 케이스가 모두 통과했고, 프론트엔드 12개 케이스를 생성했다. 무엇보다 가치 있는 것은 버그 발견이었다. /api/dub가 특정 에러 경로에서 일관된 JSON 형태 대신 plain string을 반환하는 문제와, 서버로 전달되기 전 비정상 room ID를 걸러내지 못하는 프론트엔드 유효성 문제가 테스트로 발견되었다. 서버로 나가기 전에 잡은 것이다.
중요한 것은 TestSprite MCP가 '단일 통과 결과'가 아니라 '런 히스토리'를 제공한다는 점이다. 무엇이 깨졌고, 무엇이 바뀌었으며, 수정이 유지되고 있는지를 추적할 수 있다. 이것은 컴포넌트 라이브러리 유지보수에서도 직접적으로 유효한 접근이다. UI 컴포넌트의 접근성 속성이나 키보드 내비게이션이 리팩토링 후에도 유지되는지를 자동으로 검증하는 레이어를 AI가 생성해준다면, 개발자는 '구조적 결정'에 더 집중할 수 있다.
6시간 프로토타이핑이 말하는 것: AI는 속도를 주고, 판단은 남긴다
Drupal Canvas SDC 모듈 제작기는 결이 다른 인사이트를 준다. 개발자는 하룻밤 사이 AI와 대화하면서 아키텍처 방향을 잡고, 모듈 구조를 스캐폴딩하고, 서비스 와이어링 초안을 생성했다. 6시간 안에 dev 릴리즈까지 도달했다.
그런데 제작자가 강조하는 것은 AI가 아니라 그 이후다. 잘못된 모듈 이름, 서브모듈 경계 설정 오류, Drupal 클래스 상속 실수, 설정 엔티티 라우트 프로바이더 문제, 테스트 실패, 코딩 표준 위반. AI는 첫 번째 초안을 빠르게 만들어줬지만, '완성'까지는 여전히 사람의 판단이 필요했다. "AI가 초안을 빠르게 만들어줬다. 하지만 감독 없이 빠르게 완성까지 데려다주지는 않았다"는 고백이 핵심이다.
이 경험은 SoftUI 제작기, TestSprite MCP 사례와 삼각형을 이룬다. AI는 컴포넌트 스캐폴딩을 빠르게 해주고, 테스트를 자동 생성하고, 문서 초안을 만들어준다. 그러나 토큰 시스템 설계, 접근성 레이어 결정, 컴포넌트 간 경계 설정, 아키텍처의 철학적 일관성은 여전히 개발자의 몫이다.
시사점: 라이브러리 구축 워크플로우의 재설계
세 사례를 종합하면 컴포넌트 라이브러리 구축의 새로운 워크플로우 원형이 보인다. 설계 단계에서는 AI를 아키텍처 스파링 파트너로 활용한다. 디자인 토큰 구조, 컴포넌트 경계, 접근성 체크리스트를 함께 논의하고 빠르게 초안을 생성한다. 구현 단계에서는 AI로 스캐폴딩을 가속하되, 크로스 브라우저 일관성·RTL·print 같은 엣지 케이스는 사람이 직접 검증한다. 검증 단계에서는 TestSprite MCP 같은 AI 기반 테스트 생성 도구로 엣지 케이스와 에러 경로를 자동 커버하고, 히스토리 추적으로 회귀를 방어한다.
특히 '20개의 단단한 컴포넌트로 먼저 출시하라'는 교훈은 AI 시대에 더욱 유효하다. AI가 컴포넌트 생성 속도를 높여줄수록, 출시 전에 '무엇을 만들어야 하는가'를 결정하는 판단이 더 중요해진다. 속도는 AI가 채워줄 수 있지만, 우선순위는 여전히 프로덕트 사고의 영역이다.
뉴모피즘이라는 선택 자체가 하나의 메시지다. 모두가 같은 미학을 따를 때, 다른 질문을 던지는 것이 차별화의 시작이다. 컴포넌트 라이브러리도 마찬가지다. AI가 보편적인 패턴을 빠르게 생성해줄수록, '왜 이 구조인가', '이 경험이 사용자에게 진짜 도움이 되는가'라는 질문이 라이브러리의 진짜 경쟁력을 만든다.