비활성 버튼은 왜 투명하게 만들면 안 될까

KRDS DS-011 — disabled 상태에 투명도 색상을 사용하지 않고 있다.

0. 들어가며 — 모순처럼 보이는 규칙

지난 10편에서 투명도(Alpha)를 다루며, 투명도가 쓰이는 자리 중 하나로 ‘비활성(disabled) 처리’ 를 들었습니다. 그러면서 한 가지를 예고했죠 — “비활성에 투명도를 쓰는 데는 주의할 점이 있다” 고요.

그 주의점이 바로 이번 편, DS-011입니다. 그런데 규칙을 보면 어리둥절합니다.

“disabled 상태에 투명도 색상을 사용하지 않고 있다.”

방금 “비활성에 투명도를 쓴다”고 해놓고, 이제 “disabled에 투명도를 쓰지 말라”니 — 모순처럼 보입니다. 하지만 모순이 아닙니다. 여기엔 투명도라는 도구의 양면성에 대한 깊은 통찰이 담겨 있습니다.

흔히들 비활성 버튼을 만들 때 그냥 opacity를 낮춰 흐릿하게 만듭니다. 가장 쉬운 방법이고, 거의 모든 사이트가 그렇게 합니다. 그런데 KRDS는 “그렇게 하지 말라”고 합니다. 왜일까요? 이번 편은 그 ’왜’를 끝까지 파헤칩니다. 작아 보이는 규칙이지만, 그 안에는 ’예측 가능한 디자인’이라는 중요한 원리가 들어 있습니다.

1. 규칙 원문 — 금지형 규칙

DS-011 (디자인 스타일 > 색상) “disabled 상태에 투명도 색상을 사용하지 않고 있다.”

846개 규칙 중 드물게 ’~하지 말라’는 금지형 규칙입니다. 두 부분으로 나눠 읽어봅시다.

“disabled 상태”

비활성 상태입니다. 지금은 누를 수 없는 버튼, 입력할 수 없는 필드, 선택할 수 없는 항목. 예컨대 필수 항목을 다 채우기 전의 “제출” 버튼, 이미 신청한 항목의 “신청” 버튼처럼 조건이 충족되지 않아 일시적으로 막힌 요소입니다.

“투명도 색상을 사용하지 않고”

그 비활성 상태를 표현할 때 투명도(opacity/alpha)로 흐리게 만들지 말라는 뜻입니다. 대신 — 명시되진 않았지만 — 정해진 불투명 색(전용 disabled 색) 을 쓰라는 의미가 깔려 있습니다.

정리: 비활성은 ’투명하게 흐리기’가 아니라 ’정해진 회색 등 불투명 색’으로 표현하라. 이게 DS-011입니다.

2. disabled 상태란 무엇이고, 왜 표시가 중요한가

먼저 disabled가 무엇인지 짚고 갑시다. 비활성 상태는 사용자에게 “이건 지금 쓸 수 없어요” 를 알리는 시각 신호입니다. 이 신호가 명확해야 사용자가 헛되이 클릭하지 않고, “아, 뭔가 조건이 안 맞았구나”를 이해합니다.

그래서 disabled의 표시에는 두 가지 요구가 동시에 걸립니다.

충분히 구분돼야 한다 — 활성 버튼과 명확히 달라 보여서 “못 누른다”가 전달돼야 함.

그러나 일관되고 예측 가능해야 한다 — 어디서든 같은 모습으로 보여서 사용자가 ’비활성’을 학습할 수 있어야 함.

이 두 요구를 모두 만족시키려면 disabled 색이 통제 가능해야 합니다. 그런데 바로 이 지점에서 투명도가 문제를 일으킵니다.

조금 더 생각해 보면, 비활성 상태는 공공서비스에서 특히 자주, 그리고 중요하게 등장합니다. 신청서 페이지를 떠올려 보세요. 필수 항목을 다 채우기 전까지 “제출” 버튼은 비활성입니다. 약관에 동의하기 전까지 “다음” 버튼은 막혀 있습니다. 이미 신청을 마친 항목의 “신청” 버튼은 다시 누를 수 없습니다. 이렇게 비활성은 사용자에게 “아직 조건이 안 됐어요” 또는 “이건 이미 끝났어요” 를 알리는, 작업 흐름의 핵심 안내입니다.

만약 이 비활성 표시가 불분명하면 어떤 일이 벌어질까요? 사용자는 막힌 버튼을 반복해서 누르며 “왜 안 되지?” 하고 혼란스러워하거나, 반대로 비활성인 줄 모르고 “다 했다”고 착각합니다. 특히 디지털에 익숙하지 않은 고령 사용자에게 이런 모호함은 큰 장벽입니다. 그래서 비활성 표시는 ‘있으면 좋은’ 디테일이 아니라, 작업을 끝까지 완수하게 돕는 필수 안내입니다. 이 중요한 신호가 배경 운에 따라 흐려지거나 사라지면 안 되는 이유가 여기 있습니다.

3. 왜 투명도를 쓰면 안 되나 — 세 가지 이유

비활성에 투명도를 쓰는 건 쉽지만, 세 가지 결정적 문제가 있습니다.

이유 ① 배경에 따라 모습이 변한다 (일관성 붕괴)

10편에서 배운 투명도의 핵심 성질 — 투명도는 배경에 따라 결과가 달라진다. 50% 투명한 회색 버튼은 흰 배경 위에선 연회색으로, 어두운 배경 위에선 진회색으로, 사진 위에선 또 다른 모습으로 보입니다.

비활성 버튼에 투명도를 쓰면, 같은 비활성 버튼이 배경마다 다르게 보입니다. 한 페이지에선 적당히 흐리고, 다른 페이지(배경색이 다른)에선 너무 연하거나 너무 진하게요. 사용자는 “비활성은 이런 모습”이라는 일관된 인식을 갖지 못합니다. 디자인의 예측 가능성이 무너지는 것입니다.

이유 ② 대비를 통제할 수 없다

투명도는 배경에 의존하므로 명도 대비도 배경마다 달라집니다. 어떤 배경에선 너무 흐려서 비활성 버튼이 거의 안 보이고(시각 약자에게 특히), 다른 배경에선 너무 또렷해서 활성 버튼처럼 보입니다. “지금 누를 수 있는지 없는지”가 헷갈리는 것이죠. 비활성의 핵심 메시지가 배경 운에 맡겨집니다.

이유 ③ 고대비·forced-colors 모드에서 사라진다

가장 기술적인 이유입니다. 윈도우 고대비 모드나 forced-colors 환경(5편 참고)에서는 시스템이 색을 강제로 치환하면서 투명도(opacity)를 무시하거나 제거할 수 있습니다. 그러면 투명도로만 표현된 비활성 상태가 활성과 똑같아 보이게 됩니다. 정작 비활성 표시가 가장 필요한 시각 약자 사용자에게, 그 표시가 사라지는 역설이 벌어집니다.

세 이유의 공통점: 투명도는 ‘결과가 환경에 따라 변하는’ 색이라, ‘언제나 똑같이 보여야 하는’ 비활성 상태에는 부적합하다는 것입니다. 비활성은 예측 가능해야 하는데, 투명도는 예측 불가능합니다.

4. 그럼 10편과 모순 아닌가 — 도구의 양면성

여기서 10편과의 관계를 정리해야 합니다. 10편은 “오버레이·구분선 등에 투명도를 쓰라”고 했고, 11편은 “disabled엔 쓰지 말라”고 합니다. 상충하는 것 같지만, 사실 같은 원리의 두 얼굴입니다.

투명도의 본질은 ‘배경에 따라 변한다’ 는 것입니다. 이건 상황에 따라 장점도 되고 단점도 됩니다.

오버레이·구분선(10편) — ’어떤 배경 위에서도 자연스럽게 융화’되어야 하는 곳. 배경에 따라 변하는 게 장점입니다. 모달 막은 뒤 화면이 무엇이든 자연스럽게 어둡게 덮어야 하니까요.

disabled(11편) — ‘어디서든 똑같이 예측 가능하게’ 보여야 하는 곳. 배경에 따라 변하는 게 단점 입니다. 비활성은 일관된 모습이어야 하니까요.

즉 같은 투명도라도 ’변해도 되는 곳’엔 쓰고, ’변하면 안 되는 곳’엔 쓰지 말라는 것입니다. 모순이 아니라 도구를 용도에 맞게 쓰라는 정교한 지침입니다. 좋은 디자인 시스템은 이렇게 한 도구의 장점과 단점을 구분해, 어디엔 쓰고 어디엔 쓰지 말지를 명확히 합니다. DS-010과 DS-011은 그 좋은 예입니다.

이 구분을 한 번 더 음미할 가치가 있습니다. 많은 디자인 규칙이 “X를 써라” 또는 “X를 쓰지 마라”의 단순한 형태인데, DS-010·011은 “같은 X를 어디엔 쓰고 어디엔 쓰지 마라” 라는 더 성숙한 형태입니다. 도구 자체에 선악이 있는 게 아니라, 그 도구의 성질을 이해하고 맥락에 맞게 쓰는 것이 핵심이라는 것이죠. 투명도의 ’배경 의존성’은 오버레이에선 축복이고 비활성에선 저주입니다. 같은 성질이 정반대 결과를 낳습니다.

이런 사고방식은 디자인을 넘어 모든 도구에 적용됩니다. 망치는 못을 박는 데는 훌륭하지만 나사를 박는 데는 최악입니다. 도구를 탓할 게 아니라 용도를 맞춰야 하죠. KRDS가 투명도 규칙을 둘로 나눠(쓸 곳 / 쓰지 말 곳) 명시한 것은, 담당자가 “투명도는 좋은가 나쁜가”라는 잘못된 질문 대신 “이 자리에 투명도가 맞는가”라는 옳은 질문을 하도록 안내하는 것입니다. 작은 규칙 하나에도 이런 설계 철학이 담겨 있습니다.

5. 그럼 disabled는 어떻게 표현하나 — 전용 색 토큰

투명도를 안 쓴다면, 비활성은 어떻게 만들까요? 답은 ‘정해진 불투명 색(전용 disabled 색 토큰)’ 입니다.

비활성 상태를 위한 고정된 회색 계열 색을 미리 정의해 둡니다. 배경색·텍스트색·테두리색 각각에 대해 ’비활성일 때의 색’을 명도 단계(DS-004)에서 골라 토큰으로 박아두는 것이죠. 예를 들어 비활성 버튼 배경은 gray-10, 비활성 텍스트는 gray-40처럼요.

이렇게 하면 세 가지 문제가 모두 풀립니다.

일관성 — 불투명 색이라 어떤 배경 위에서도 항상 같은 모습입니다.

대비 통제 — 정확한 색값이라 명도 대비를 미리 검증·보장할 수 있습니다.

고대비 모드 대응 — 투명도가 아니라 실제 색이라, forced-colors 환경에서도 의도대로 처리됩니다.

핵심은 ‘비활성도 하나의 색 상태로 설계하라’ 는 것입니다. 활성에 색이 있듯 비활성에도 정해진 색이 있어야 합니다. 투명도로 ’활성 색을 흐리게’가 아니라, 처음부터 ’비활성용 색’을 따로 두는 발상의 전환입니다.

이 발상의 전환이 왜 중요한지 더 들여다봅시다. opacity: 0.4로 비활성을 만드는 방식은 본질적으로 “활성 디자인을 그냥 흐리게 한 것” 입니다. 비활성을 독립된 상태로 설계한 게 아니라, 활성의 ’약화된 버전’으로 대충 처리한 것이죠. 그래서 결과를 통제할 수 없습니다 — 활성 색이 무엇이고 배경이 무엇이냐에 따라 흐려진 모습이 매번 달라지니까요.

반면 비활성을 독립된 색 상태로 설계하면, 디자이너가 “비활성은 정확히 이 모습”이라고 의도적으로 결정합니다. 비활성 배경은 이 회색, 텍스트는 저 회색, 테두리는 또 다른 회색 — 각각을 명도 단계에서 골라 대비까지 검증해 고정합니다. 그러면 비활성은 더 이상 ’운에 맡긴 흐릿함’이 아니라 ’의도된 디자인’이 됩니다. 이것이 아마추어식 처리와 디자인 시스템식 처리의 차이입니다.

그리고 이렇게 토큰으로 정의해 두면 관리도 쉬워집니다. 나중에 “비활성이 너무 흐려서 안 보인다”는 피드백이 오면, 비활성 토큰 값 하나만 조정하면 사이트 전체의 비활성이 일관되게 개선됩니다. opacity가 화면 곳곳에 흩어져 있으면 이런 일괄 조정이 불가능합니다. 비활성을 색 상태로 설계하는 것은 일관성뿐 아니라 유지보수 측면에서도 옳은 선택입니다.

6. disabled의 접근성 딜레마 — 그리고 read-only 대안

비활성 표시에는 사실 더 깊은 접근성 딜레마가 있습니다. 알아두면 DS-011을 더 잘 적용할 수 있습니다.

비활성 버튼은 흐려야 ’비활성’으로 보이지만, 너무 흐리면 시각 약자가 아예 못 봅니다. 반대로 잘 보이게 하면 활성처럼 보여 혼란을 줍니다. 실제로 여러 유명 디자인 시스템(Atlassian, Carbon 등)의 비활성 버튼이 WCAG 색 대비를 통과하지 못한다는 분석도 있습니다. 비활성 표시는 생각보다 까다로운 영역입니다.

여기서 DS-011의 ‘전용 색 토큰’ 접근이 빛납니다. 투명도로 ‘운에 맡기는’ 대신 정해진 색을 쓰면, 적어도 “이 색이 어떤 배경에서 어떤 대비를 갖는지” 통제하고 검증할 수 있습니다. 그래서 “비활성처럼 보이되, 완전히 안 보이지는 않는” 적정 지점을 의도적으로 설계할 수 있습니다. 투명도는 이 설계 자체를 불가능하게 만듭니다.

또 하나의 실무 팁 — 비활성 요소의 정보가 사용자에게 여전히 중요하다면, disabled 대신 read-only(읽기 전용) 를 고려할 수 있습니다. read-only는 ‘읽을 수는 있지만 바꿀 수 없는’ 상태로, 정보 가독성을 유지하면서 편집만 막습니다. “왜 비활성인지” 맥락이 중요한 경우엔 무작정 흐리게 만드는 것보다 나은 선택일 수 있습니다.

7. 흔한 위반 패턴

DS-011 위반은 거의 하나의 형태입니다 — opacity로 비활성 만들기.

/* ❌ 가장 흔한 위반: 활성 버튼에 opacity만 낮춤 */ .btn:disabled { opacity: 0.4; }

이 한 줄이 편하긴 한데, 3장의 세 문제를 다 일으킵니다. 배경마다 다르게 보이고, 대비가 통제 안 되고, 고대비 모드에서 사라집니다. 게다가 opacity는 요소 전체를 투명하게 만들어, 버튼 안 텍스트까지 흐려집니다 (10편의 opacity 함정과 동일).

이 외에 반투명 배경색으로 비활성 표현(background: rgba(...,0.3))도 같은 문제를 가집니다. 투명도가 들어간 모든 방식이 DS-011 위반에 해당합니다.

8. 무엇을 점검하나

DS-011은 비활성 상태가 투명도 없이 표현됐는지를 봅니다.

opacity 사용 여부 — :disabled 등 비활성 스타일에 opacity가 쓰였는가.

alpha 배경 여부 — 비활성 색에 투명도(rgba alpha)가 들어갔는가.

전용 색 토큰 사용 — 비활성이 정해진 불투명 색으로 표현됐는가.

일관성 — 사이트 전반의 비활성 모습이 배경과 무관하게 일관된가.

CSS에서 :disabled/[disabled]/.disabled 등에 적용된 opacity와 alpha 색을 검출하면 판정할 수 있습니다.

9. 누가 담당하나

역할	책임
디자인 시스템 담당 / 디자이너	비활성 전용 색(불투명) 토큰 정의
퍼블리셔/개발	opacity 대신 전용 색 토큰으로 비활성 구현
접근성 담당	비활성 색의 대비·고대비 모드 동작 검증

DS-011은 주로 구현 습관의 문제입니다. 개발자가 무심코 쓰는 opacity: 0.x 한 줄을, 전용 색 토큰으로 바꾸는 것이 핵심입니다. 디자인 시스템에 ’비활성 색’이 토큰으로 정의돼 있으면 이 전환이 쉬워집니다.

10. 우리 사이트에 해당될까?

적용 대상

기관 유형	DS-011 적용
중앙행정기관(대표)	✅ 필수
중앙행정기관(운영)	✅ 필수
공공기관	✅ 필수
지방자치단체	✅ 필수

비활성 상태를 가진 요소(버튼·입력·선택 등)가 있는 모든 사이트 = 해당. 폼이 있는 사이트라면 거의 예외 없이 비활성 버튼이 있으므로 대부분 적용됩니다.

예외(N/A)

비활성 상태 요소가 전혀 없는 사이트라면 예외가 될 수 있지만, 신청·로그인·검색 폼이 있는 공공 사이트는 대부분 비활성 버튼을 갖습니다.

11. 단계별 개선 방법

Before / After

/* ❌ Before: opacity로 비활성 (배경 의존·대비 불통제·고대비 소실) */ .btn:disabled { opacity: 0.4; } /* ✅ After: 비활성 전용 불투명 색 토큰 */ :root { --color-disabled-bg: var(--gray-10); --color-disabled-text: var(--gray-40); --color-disabled-border: var(--gray-20); } .btn:disabled { background: var(--color-disabled-bg); color: var(--color-disabled-text); border-color: var(--color-disabled-border); cursor: not-allowed; }

정비 순서

비활성 전용 색 토큰 정의 — 배경·텍스트·테두리 각각.

opacity 제거 — :disabled의 opacity를 전용 색으로 교체.

alpha 배경 교체 — 반투명 배경 비활성을 불투명 색으로.

고대비 검증 — forced-colors 모드에서 비활성이 구분되는지 확인.

12. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 비활성 버튼을 opacity로 흐리게 만들고 있지 않나요?

□ 비활성 색이 정해진 불투명 색(토큰) 으로 정의돼 있나요?

□ 배경이 다른 페이지에서도 비활성 모습이 일관된가요?

□ 고대비 모드에서도 비활성이 활성과 구분되나요?

□ 비활성 버튼 안 글자가 같이 흐려지지 않았나요?

❓ FAQ

Q1. opacity로 비활성 만드는 게 제일 쉬운데 왜 안 되나요? 쉽지만 배경 의존·대비 불통제·고대비 모드 소실이라는 세 문제를 일으킵니다. 비활성은 ‘어디서나 똑같이 예측 가능하게’ 보여야 하는데, 투명도는 그걸 보장하지 못합니다. 전용 불투명 색을 쓰면 한 번 정의로 해결됩니다.

Q2. 그럼 비활성을 무슨 색으로 하나요? 명도 단계(DS-004)에서 적당한 회색을 골라 비활성 전용 토큰으로 정의합니다. 활성보다 약하되, 완전히 안 보이지는 않는 적정 대비의 색이 좋습니다. KRDS를 채택하면 비활성 색이 토큰으로 제공됩니다.

Q3. 10편에선 비활성에 투명도 쓴다더니 11편에선 쓰지 말라니, 결국 뭐죠? 10편은 ’투명도가 흔히 쓰이는 자리’를 나열하며 비활성을 예로 들었고, 곧바로 “주의점이 있다”고 예고했습니다. 11편이 그 결론입니다 — 비활성엔 투명도 대신 전용 색을 쓰라. 투명도는 오버레이처럼 ’변해도 되는 곳’에만 쓰는 것이 원칙입니다.

Q4. 비활성인데 사용자가 그 내용을 봐야 하는 경우는요? disabled 대신 read-only(읽기 전용)를 고려하세요. 정보는 읽을 수 있게 두고 편집·실행만 막는 방식입니다. 맥락이 중요한 정보를 무작정 흐리게 가리는 것보다 나을 수 있습니다.

Q5. cursor도 바꿔야 하나요? 색뿐 아니라 cursor: not-allowed 같은 보조 단서를 함께 주면 좋습니다. 색을 못 보는 사용자에게도 ’못 누른다’가 전달됩니다(DS-006의 ’색만으로 정보 전달 금지’와 연결).

13. 마무리 — ’예측 가능함’이라는 가치

DS-011은 작은 규칙이지만 중요한 원리를 담고 있습니다.

어떤 상태는 ‘예측 가능하게 일정해야’ 하고, 그런 곳엔 환경에 따라 변하는 투명도를 쓰면 안 된다.

비활성은 사용자에게 보내는 명확한 신호입니다. “여기는 지금 쓸 수 없어요.” 이 신호가 배경에 따라 흐려지거나 사라지면, 신호로서의 역할을 못 합니다. 그래서 비활성은 ‘활성 색을 흐리게’가 아니라 ’비활성 전용 색으로’ 설계해야 합니다. 편한 opacity: 0.4 한 줄을 전용 색 토큰으로 바꾸는 것 — 작지만 디자인의 예측 가능성을 지키는 일입니다.

다음 편은 색상 카테고리의 또 다른 절제 규칙입니다. DS-012 — “강조 색상을 중요한 강조 요소에만 제한적으로 사용하고 있으며, 최대 5%를 넘기지 않고 있다.” 9편(60:30:10)에서 잠깐 본 ’강조 5% 이하’가 독립된 규칙으로 다시 등장합니다. 강조의 절제가 마지막 숫자로 한 번 더 못 박힙니다.

다음 편 예고 ▶ 「012. 강조 색상을 중요한 강조 요소에만 제한적으로 사용하고 있으며, 최대 5%를 넘기지 않고 있다.」

우리 사이트가 비활성에 투명도를 쓰고 있는지 확인하려면? ViewCheck는 :disabled 등 비활성 스타일에 opacity나 alpha 색이 쓰였는지를 검출하고, 비활성 색이 배경과 무관하게 일관된 불투명 색으로 표현됐는지를 진단합니다.

📚 참고 출처

KRDS 색상(Color) 스타일 가이드 — https://www.krds.go.kr/html/site/style/style_02.html

Carbon Design System — Disabled states — https://carbondesignsystem.com/patterns/disabled-states/

The Color Contrast Dilemma of Disabled Buttons (Bootcamp) — https://medium.com/design-bootcamp/the-color-contrast-dilemma-of-disabled-buttons-in-accessible-design-59811fc89f62

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준