🎯 02. CSS 선택자와 Specificity: '우선순위 충돌을 읽는 법'

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분(전체) / 핵심 파트만: 5분

🗺️ 이 문서의 흐름
[선택자의 종류] → [Specificity 계산기] → [!important 없이 충돌 해결하기]

🎯 이 문서를 다 읽으면 할 수 있는 것

• 단순 선택자부터 복합 선택자까지 용도에 맞게 골라 쓸 수 있습니다.
• 내 스타일이 왜 적용되지 않는지 명시도 점수를 통해 논리적으로 파악합니다.
• 유지보수하기 쉬운 선택자 작성 전략을 세울 수 있습니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 (입문자): "영호 님! 분명히 .button 클래스에 빨간색을 줬는데, 개발자 도구에서는 줄이 그어져 있고 화면에는 계속 파란색으로 나와요. 어떤 규칙이 이긴 건지 모르겠습니다."
• 🦁 영호 (리드): "영철 님, CSS는 위에서 아래로 흐르지만 그 전에 명시도(Specificity)를 비교합니다. 누가 더 구체적으로 대상을 가리키는지 계산할 수 있어야 !important 없이도 충돌을 해결할 수 있어요."

🤔 왜 알아야 하는가

CSS(Cascading Style Sheets)의 앞글자인 **Cascading(폭포)**은 스타일이 우선순위에 따라 겹쳐지며 적용된다는 뜻입니다. 이 우선순위를 결정하는 핵심 공식이 바로 **명시도(Specificity)**입니다.

스타일이 적용되지 않을 때마다 선택자를 계속 길게 만들거나 !important를 붙이면 당장은 해결된 것처럼 보입니다. 하지만 다음 수정자가 더 높은 명시도로 다시 덮어써야 해서 CSS가 점점 예측하기 어려워집니다. 5년차 이상의 시니어는 최소한의 명시도로 스타일을 관리해 수만 줄의 CSS 안에서도 충돌 원인을 추적할 수 있게 만듭니다.

🏰 1. 선택자의 계급: 명시도 점수판

명시도는 보통 점수처럼 설명하지만, 실제 판단은 "ID 개수 → 클래스/속성/의사 클래스 개수 → 요소/의사 요소 개수" 순서로 비교한다고 생각하면 더 정확합니다.

🦁 영호의 계산법:
"영철 님, #nav .list-item a 의 점수는 얼마일까요?
ID 1개(100) + Class 1개(10) + Element 1개(1) = 111점입니다.
만약 누가 .menu a (11점)로 스타일을 덮어쓰려 한다면? 절대 이길 수 없죠."

⚖️ 2. 우선순위 비교: 어떤 규칙이 적용될까?

1. 동일 점수면?: 나중에 선언된 규칙이 적용됩니다. (폭포의 원칙)
2. !important는?: 일반 명시도 비교보다 우선하지만, 남용하면 다음 수정이 더 어려워집니다.
3. 상속받은 스타일은?: 직접 선택한 스타일보다 약합니다. 명시도가 낮아도 요소를 직접 선택한 규칙이 상속값보다 우선합니다.

input {
  /* form 요소가 브라우저 기본 글꼴을 쓰지 않도록 부모의 타이포그래피를 명시적으로 이어받습니다. */
  color: inherit;
  font-family: inherit;
}

이 패턴은 "명시도를 높여 덮어쓰기"가 아니라 "기본 상속 전략을 명확히 하기"에 가깝습니다. 특히 버튼과 input처럼 브라우저 기본 스타일이 강한 요소에서 디자인 시스템의 글꼴을 유지하는 데 유용합니다.

아래 예시는 영철이가 같은 버튼에 색을 선언했는데도 다른 규칙이 적용되는 상황입니다. 개발자 도구에서 취소선이 보이면 먼저 선택자 점수를 비교합니다.

/* 클래스 하나: 0-1-0 */
.button { color: red; }
 
/* ID + 클래스 + 요소: 1-1-1 */
body #container .button { color: blue; }

해결은 무조건 더 긴 선택자를 만드는 것이 아닙니다. 가능하면 기존의 높은 명시도 규칙을 낮추거나, 컴포넌트 경계에서 클래스 하나로 의도를 드러내는 쪽이 유지보수에 더 안전합니다.

🛡️ 3. 5년차의 전략: '구체성'의 함정 피하기

시니어들은 선택자를 너무 길게 쓰지 않습니다. #main section div ul li a 처럼 쓰면 나중에 스타일을 바꾸기가 너무 힘들어지기 때문이죠.

[영호 리드의 클린 선택자 팁]

• ID 선택자 사용 지양: 가급적 클래스(.) 위주로 설계하세요. ID는 너무 힘이 세서 나중에 제어하기 힘듭니다.
• BEM(Block Element Modifier) 활용: .header__nav-item--active 처럼 클래스 하나에 의미를 담아 명시도를 낮게(10점) 유지하세요.
• 범용성 vs 특수성: 공통 스타일은 낮은 점수의 선택자로, 특별한 스타일은 클래스를 추가해 살짝 높은 점수로 관리하세요.

📝 마무리 퀴즈

Q1. 다음 선택자 중 점수가 가장 높은 것은 무엇일까요?

1. nav ul li a
2. .main-nav .link
3. #logo
4. div.content p

✅ 정답: 3. #logo

💡 상세 해설:

• 원리 설명: 명시도 점수표로 비교하면 — ① nav ul li a = 0-0-4 (요소 4개), ② .main-nav .link = 0-2-0 (클래스 2개), ③ #logo = 1-0-0 (ID 1개), ④ div.content p = 0-1-2 (클래스 1 + 요소 2). ID(100점) 가 클래스(10점)보다 항상 이깁니다.
• 오답 피드백: "영철 님, 선택자가 아무리 길어도 **계급(ID > Class > Element)**을 못 이겨요. 요소 선택자 100개를 합쳐도 클래스 하나보다 약합니다!"
• 📌 핵심 기억법: "요소를 많이 붙이는 것보다 ID 하나가 훨씬 강하다."

Q2. !important를 사용하지 않고 스타일 충돌을 해결하는 가장 올바른 방법은 무엇일까요?

1. 부모 요소를 더 많이 써서 선택자를 길게 만든다.
2. 모든 속성에 ID 선택자를 붙인다.
3. 현재 적용된 스타일보다 명시도 점수가 높거나 같은 클래스를 추가한다.
4. CSS 파일의 맨 마지막 줄로 코드를 옮긴다.

✅ 정답: 3. 현재 적용된 스타일보다 명시도 점수가 높거나 같은 클래스를 추가한다.

💡 상세 해설:

• 원리 설명: 명시도의 원리에 따라 같은 수준의 선택자로 논리적으로 대응하는 것이 가장 건강한 해결법입니다. 불필요한 ID 남용이나 선택자 길이 늘리기는 유지보수를 망치고, 파일 순서에 의존하는 것은 리팩토링 시 깨지기 쉽습니다.
• 오답 피드백: "영철 님, ①은 불필요하게 복잡하고, ②는 ID 남용으로 이어지며, ④는 CSS 파일을 합치거나 순서가 바뀌면 바로 깨져요!"
• 📌 핵심 기억법: "충돌 해결의 정석: 의도한 범위에서 필요한 만큼만 명시도를 올린다."

Q3. [영철이의 테스트 타임: 긴급 디버깅]
영철이가 버튼에 :hover 시 배경색을 노란색으로 바꿨는데, 특정 페이지에서는 계속 원래 색인 회색으로 나옵니다. 확인해보니 해당 페이지 가이드에서 #sidebar a 라는 스타일이 이미 배경색을 회색으로 고정하고 있었습니다. 영철이가 영숙 디자이너 님이 원하는 '노란색 호버 효과'를 내기 위해 가장 권장되는 해결책은 무엇일까요?

✅ 정답: 버튼에 더 명확한 클래스(예: .btn--yellow-hover)를 부여하거나, 선택자의 명시도를 높여(예: .sidebar .btn:hover) 대응한다.

💡 상세 해설:

• 원리 설명: #sidebar a는 ID가 포함되어 101점입니다. 영철이의 .button:hover는 20점밖에 안 되죠.
• 오답 피드백: "영철 님, 여기서 !important를 쓰면 다음번에 버튼 상태를 바꿀 때 더 강한 규칙이 필요해질 수 있어요. 먼저 기존 ID 선택자를 낮출 수 있는지, 어렵다면 컴포넌트 범위 안에서 명시도를 논리적으로 맞춰주세요."
• 📌 핵심 기억법: "강한 규칙을 더 강한 규칙으로만 막지 말고, 가능한 한 규칙 자체를 낮춘다."

🐣 영철이의 퇴근 일기

오늘은 내 코드가 왜 무시당했는지 그 이유를 명확히 알게 됐다.
ID 선택자가 그렇게 강한 규칙인 줄 몰랐다. 그냥 이름표인 줄 알았는데, 스타일 충돌에서는 팀 전체의 선택지를 좁힐 수도 있었다.
영호 님이 "선택자가 길어질수록 미래의 수정 비용도 같이 길어진다"라고 하신 말씀이 가슴에 콕 박혔다.

💡 "명시도는 무기가 아니라 균형이다. 가장 낮은 점수로 원하는 목표를 달성하는 개발자가 진짜 고수다."

집에 가면서 오늘 짠 코드들에서 불필요하게 긴 선택자들을 어떻게 줄일 수 있을지 머릿속으로 리팩토링해봤다.
BEM이라는 것도 좀 더 자세히 찾아봐야겠다.
오늘도 1% 시니어에 가까워진 느낌! 맥주 한 잔 하러 가야지! 🍻

🔗 더 알아보기

• MDN: Specificity (명시도)
• MDN: CSS selectors 레퍼런스