자주 묻는 질문

이 문서는
SLUR UX/UI System을 실무에 적용하는 과정에서
자주 발생하는 질문과 판단 기준을 정리한 Reference 문서입니다.

정답을 강요하기보다는,
어떤 기준으로 설계되었는지를 이해하는 데 목적이 있습니다.

SLUR UX/UI System은 CSS 네이밍 규칙인가요?

아닙니다.

SLUR UX/UI System은 단순한 CSS 네이밍 규칙이 아니라,
UI 구조를 설계하고 유지하기 위한 UI 구조화 방법론입니다.

클래스 네이밍은
구조를 강제하기 위해 사용하는 수단 중 하나일 뿐입니다.

컴포넌트에는 왜 접두사를 사용하지 않나요?

컴포넌트는
가장 기본적인 재사용 단위이기 때문입니다.

접두사가 없는 클래스는
의미 없는 클래스가 아니라,
의도적으로 중립적인 구조 단위입니다.

접두사별 역할과 근거는 접두사 기준표를 참고하세요.

내부 요소(i_)는 왜 단독 사용이 불가능한가요?

내부 요소는
상위 컴포넌트 맥락 안에서만 의미를 가지도록 설계되었기 때문입니다.

단독으로 사용하면
구조의 범위를 드러낸다는 목적 자체가 사라집니다.

각 접두사의 정의는 접두사 기준표에서 확인하세요.

수정자(m_)는 언제 사용해야 하나요?

수정자는
구조가 이미 결정된 이후,
상태나 변형이 필요할 때만 사용합니다.

수정자는
항상 “추가 조건”이어야 합니다.
수정자가 구조 역할을 대신하기 시작하면 규칙을 벗어난 것입니다.

수정자의 위치와 근거는 접두사 기준표에 정리되어 있습니다.

페이지(page_)와 컴포넌트의 차이는 무엇인가요?

한 문장으로 구분합니다.

페이지는 조합 역할
컴포넌트는 재사용 역할

계층 전체의 관계는 구조 모델을 참고하세요.

페이지 내부 요소(p_)를 컴포넌트로 만들면 안 되나요?

페이지 내부 요소는
해당 페이지에서만 의미를 가지는 구조이기 때문에
컴포넌트로 분리하지 않는 것이 원칙입니다.

재사용 가능성이 생겼다면
그 시점에서 컴포넌트로 승격을 검토합니다.

각 단위의 접두사 정의는 접두사 기준표에 있습니다.

레이아웃(layout_)과 페이지(page_)는 어떻게 구분하나요?

레이아웃은 전역 UI 구조를,
페이지는 특정 화면의 콘텐츠 구조를 담당합니다.

레이아웃이 콘텐츠 의미를 가지는 순간
구조가 흐려진다고 판단합니다.

두 단위의 계층상 위치는 구조 모델에서 정의합니다.

상태를 클래스가 아닌 data-*로 표현하는 이유는 무엇인가요?

상태는
구조가 아니라 조건이기 때문입니다.

클래스 → 구조
data-* → 상태

구현과 근거는 상태 기반 UI를 참고하세요.

같은 구조 단위를 중첩하면 왜 문제가 되나요?

같은 구조 단위의 중첩은
구조 범위를 모호하게 만들기 때문입니다.

구조 간 관계는 “포함”이 아니라
“조합”으로만 해석합니다.

조합 규칙과 계층은 구조 모델에서 정의합니다.

SLUR UX/UI System은 어떤 프로젝트에 적합한가요?

SLUR UX/UI System은
다음과 같은 프로젝트에 특히 적합합니다.

중·대규모 UI 프로젝트
여러 명이 협업하는 환경
장기 유지보수가 필요한 서비스
UI 구조 일관성이 중요한 제품

반대로,
단기 이벤트 페이지나 일회성 마크업에는
과한 규칙이 될 수 있습니다.

기존 프로젝트에도 SLUR UX/UI System을 적용할 수 있나요?

가능합니다.

다만 전체를 한 번에 바꾸기보다는

신규 화면
신규 컴포넌트
부터 점진적으로 적용하는 방식을 권장합니다.

SLUR UX/UI System은
점진적 도입을 고려해 설계되었습니다.

문서의 역할

이 FAQ는
규칙을 암기하기 위한 문서가 아니라,
판단 기준을 이해하기 위한 참고 문서입니다.

SLUR UX/UI System은
규칙보다 맥락을 중요하게 생각합니다.