FAQs

개념과 철학
Semantic CSS
경험과 협업
설계와 확장성
성능과 기술
FROG UI의 핵심 개념은 무엇인가요?

FROG UI는 “코드가 아니라 언어로 스타일을 말하는 것”을 목표로 만들어졌습니다. 개발자가 약어나 축약 코드 대신, 자연어에 가까운 단어들을 조합해 UI를 그림 그리듯 표현하도록 설계되었습니다.

왜 CSS‑in‑JS가 아닌 CSS 프레임워크·semantic CSS 방식인가요?

디자인 토큰과 스타일 레이어를 자바스크립트 런타임에서 분리해서 성능을 확보하고 동시에, 프레임워크/플랫폼과 무관하게 재사용 가능한 디자인 언어를 만들기 위해 semantic CSS 패턴을 채택했습니다.

Semantic CSS란 무엇인가요?

컴포넌트의 시각적·의도적 특성을 의미 있는 단어들로 표현하는 방식을 말합니다. 예를 들어 버튼의 역할, 크기, 모양, 아이콘 위치 등을 그대로 단어로 풀어 클래스로 사용합니다.

자연어처럼 스타일을 적용한다는 것은 구체적으로 어떤 방식인가요?

“둥글고 왼쪽 아이콘이 포함된 작은 주요 색상 버튼”이라는 문장을 button primary round icon left small 같은 클래스 조합으로 그대로 옮기는 식입니다. 즉, 머릿속의 문장을 거의 그대로 코드로 번역하는 경험을 제공합니다.

Tailwind처럼 약어 유틸리티 클래스를 쓰지 않는 이유는 무엇인가요?

약어 기반 유틸리티는 빠르지만, 팀이 커질수록 규칙을 외우고 해석하는 비용이 커지게 됩니다. 이 시스템은 primary, round, small처럼 의미가 바로 읽히는 단어를 사용해, 가독성과 온보딩 경험을 더 중요하게 생각합니다.

디자이너와의 협업에는 어떤 도움이 되나요?

디자이너가 말하는 언어와 코드의 단어가 거의 동일해집니다. “primary 라운드 스몰 버튼에 왼쪽 아이콘 추가해 주세요”라는 문장이 곧 클래스 조합이 되므로, 디자인 스펙을 코드로 옮기는 과정의 해석 손실이 줄어듭니다.

신규 팀원이 합류했을 때 학습 곡선은 어떤가요?

프레임워크 고유 약어를 외우기보다, 이미 알고 있는 단어들만 이해하면 됩니다. 클래스 이름만 훑어봐도 컴포넌트의 역할과 스타일이 추론 가능해, 기존 코드 파악과 적응 속도가 빨라집니다.

대규모 프로젝트에서도 일관성을 유지할 수 있나요?

핵심 어휘(예: button, primary, danger, round, small 등)를 디자인 시스템에서 선제적으로 정의하고 강제하기 때문에, 팀이 늘어나도 모두가 같은 단어 세트를 공유합니다. 그 결과, 스타일의 조합은 자유롭되 토큰과 의미는 일관되게 유지됩니다.

컴포넌트 variant를 어떻게 표현하나요?

각 variant는 의미 있는 단어 하나로 표현합니다. 예를 들어 버튼은 primary, secondary와 같은 역할과 tiny, small, large, huge 같은 크기 variant를 조합해서 사용합니다.

새로운 스타일 토큰을 추가할 때 어떤 원칙을 따르나요?

가능한 한 “많이 사용하고 쉽고 익숙한 단어인지”를 기준으로 정합니다. 디자이너와 개발자가 회의에서 실제로 사용할 표현을 우선 고려하고, 약어보다 풀네임과 의미 중심의 네이밍을 선호합니다. (단, 흔하게 쓰이는 약어는 예외로 사용을 허용한다. xs, sm 등등)

반응형(Responsive) 스타일은 어떻게 다루나요?

반응형 역시 의미 기반의 접두어나 별도 규칙으로 표현한다. 예를 들어 md나 lg 같은 기기 기준을 사용하더라도, 내부 토큰과 조합은 여전히 사람이 읽기 쉬운 단어로 유지하는 것을 원칙으로 한다.

FROG는 특정 프론트엔드 프레임워크에 종속적인가요?

아닙니다. 스타일은 프레임워크와 독립된 CSS 레이어로 존재하기 때문에, React, Vue, 웹 컴포넌트 등 다양한 환경에서 동일한 디자인 언어를 사용할 수 있도록 설계되었습니다.

성능 측면에서 어떤 이점이 있나요?

런타임에 스타일을 생성하거나 삽입하지 않고, 미리 준비된 정적 CSS를 사용하는 방식을 기본으로 합니다. 덕분에 초기 로드와 재렌더링 시 불필요한 자바스크립트 오버헤드를 줄일 수 있습니다.