화면을 도배한 배지 컴포넌트 덜어내기

그리드로 구성된 페이지를 개발하다 보니, 어느새 알록달록한 배지로 가득 찬 화면을 마주했다.

처음부터 이러지는 않았다. 기획이 고도화되고 데이터가 늘어나면서 새로운 컬럼이 추가될 때마다, "데이터가 많아지니 구분되어 보이면 좋겠지" 라는 생각으로 배지를 하나씩 씌우다 보니 어느새 그리드가 무지개 그리드가 되어 있었다.

특히 요즘처럼 디자이너 없이 AI 툴이나 개발자 주도로 빠르게 화면을 구성할 때 이런 현상이 자주 나타난다. 화면 전체에서 무엇을 강조하고 무엇을 덜어낼지 판단해 줄 관점이 빠지면, 컬럼 하나하나는 그럴듯해 보여도 한 화면에 모였을 때 '무엇이 중요한지 알 수 없는' 그리드가 되기 쉽다.

이 글에서는 실제 서비스를 개발하며 겪은 배지 오남용 경험과 그 원인을 짚어 보고, 배지를 값의 성격에 맞게 쓰기 위한 개선 방향을 정리해 보았다.

그리드를 처음 보았을 때는 색상 덕분에 데이터가 잘 구분되는 것처럼 보였다. 하지만 화면을 유심히 들여다볼수록 두 가지 문제가 눈에 들어왔다.

1. 표현하는 상태와 분류가 지나치게 많다. 한 그리드 안에 너무 많은 색상의 배지가 뒤섞여 있다 보니, 어떤 정보가 정말 중요한지, 그리고 이 배지가 정확히 어떤 상태를 나타내는지 한눈에 판단하기 어려워졌다.
2. 배지로 표현하지 않아도 되는 값에까지 남발되고 있다. 사용 여부 같은 단순 Boolean 값이나 품목 유형 같은 고정 분류값에까지 배지를 사용하고 있었다.

"그렇다면 어떤 값에 배지를 적용하고, 어떤 값에는 적용하지 않아야 할까?"

정작 이 질문에 바로 답할 수 있는 명확한 기준이나 컨벤션이 프로젝트 내에 없었다는 점이 가장 큰 문제였다.

이러한 배지 오남용은 누군가의 잘못된 결정이라기보다, 개발 과정 중에서 발생한 합리적인 작은 선택들이 쌓인 결과에 가깝다고 생각했다. 왜 이런 현상이 발생하는지 원인을 분석해 보았다.

배지를 쓸지는 보통 새로운 컬럼을 추가하는 시점에 정해진다. 그 순간에는 해당 컬럼 하나만 보게 되므로, "상태값을 배지로 감싸면 눈에 잘 띌 테고, 사용 여부를 초록과 회색으로 나누면 구분이 쉽겠지" 라는 판단이 자연스럽고 타당해 보인다.

하지만 사용자는 컬럼 하나가 아니라 화면 전체를 본다. 각자 그럴듯한 배지가 한 화면에 모이면, 어떤 배지가 정말 봐야 할 정보인지 구분이 사라진다.

디자이너 없이 AI 툴이나 개발자 주도로 화면을 만들 때 이 문제가 두드러지는 이유도 여기에 있다. 요청 단위, 컬럼 단위로 화면이 만들어지고, 한 걸음 물러서서 화면 전체의 강약을 조절하는 단계가 빠지기 쉽기 때문이다.

AI를 이용해 개발을 하다 보면 enum등의 분류형 데이터를 마주할 때마다 기계적으로 배지와 같은 컴포넌트를 입히려는 모습이 자주 보인다. 텍스트만 출력하는 것보다 무언가 스타일이 입혀진 배지를 씌우는 쪽이 더 보기 좋은 코드라 판단하기 때문이다.

개발자 입장에서도 AI가 뽑아준 알록달록한 화면이 한눈에 구분되어 보이고 동작에도 문제가 없으니, 의문 없이 코드를 받아들이게 된다. 나중에 이미 씌워진 배지를 굳이 일반 텍스트로 돌려놓으려면 별도의 판단과 수정 작업이 들어가다 보니, 우선순위를 미루어 그대로 방치 시켜버린다.

결국 AI의 배지 남발 습성과 이를 깊이 검토하지 않고 수용하는 개발 흐름이 맞물려, 배지 오남용은 이전보다 훨씬 가파른 속도로 프로젝트 전체에 퍼지고 있었다.

값의 종류가 여러 개면 색으로 구분하고 싶어진다. 카테고리가 다섯 개라면 다섯 가지 색을 입히면 한눈에 구분될 것 같다.

하지만 값을 구분하기 쉽게 하는 것과 그 값을 강조해야 한다는 것은 다른 문제다. 배지는 구분만 해주는 도구가 아니라, 채도 높은 색으로 "이 셀을 먼저 보라"는 신호를 함께 보낸다. 구분만 필요한 값에 배지를 쓰면, 강조할 이유가 없는 값까지 주의를 끌게 된다.

원인을 짚다 보면 자연스럽게 "그렇다면 배지는 도대체 언제, 어떤 데이터에 쓰는 것이 맞을까?"라는 질문으로 이어진다.

배지의 본래 목적은 화면을 스캔할 때 텍스트를 일일이 읽지 않고도 현재의 진행 상태나 주의가 필요한 상황을 빠르게 알아채도록 돕는 것이다. 즉, 단순한 꾸밈 요소가 아니라 데이터의 상태를 압축해서 보여주는 시각적 기호다.

문제는 사용자가 한 번에 받아들일 수 있는 시각적 주의력이 한정되어 있는데, 주의를 끌 이유가 없는 정적인 분류값에까지 관성적으로 배지를 씌울 때 발생한다. 모든 컬럼이 배지를 입고 있으면 정작 즉시 개입이 필요한 긴급 상태(오류, 지연 등)가 눈에 들어오지 않는다.

결국 배지가 남발되면 색이 주는 신호 자체가 완전히 마비되어 버린다. 사용자는 색을 통해 무언가를 판단하려는 시도조차 하지 않게 되고, 알록달록한 색상들은 그저 아무 느낌도 주지 못하는 무의미한 배경으로 전락해 버린다.

앞서 살펴본 원인들을 바탕으로 짚어낸, 내가 생각하는 배지를 UI에서 유용한 도구로 작동시키기 위한 2가지 핵심 조건은 다음과 같다.

1. 시간에 따른 상태의 전이가 존재한다

   결제 대기 → 결제 완료 → 환불 처리 중이나 배포 중 → 성공 / 실패처럼 작업의 흐름이 있는 데이터다. 배지의 목적은 텍스트를 읽기도 전에 "지금 이 작업이 어디쯤 가 있는가?"를 시각적으로 바로 알리는 데 있다.

2. 색상으로 담을 명확한 '판단 축'이 있다

   완료/정상은 긍정(Green), 대기/주의는 경고(Yellow), 지연/오류는 위험(Red)처럼, 색상 그 자체로 직관적인 의미나 긴급도를 전달할 수 있어야 한다.

반대로, 이럴 때는 배지 사용을 지양해야 한다.

1. 단순 Boolean 값 ⚠️

   '예/아니오' 정도의 가벼운 정보인데 배지를 씌우면 정보량에 비해 시각적 노이즈가 너무 크다. 테이블에 Boolean 컬럼 몇 개만 들어가도 화면 전체가 배지로 도배되면서 정작 중요한 상태가 묻혀 버린다. 이런 단순 여부는 일반 텍스트나 가벼운 아이콘으로 보여주는 것으로 충분하다.

2. 고정 분류 값(카테고리 등) ⚠️

   회원 플랜(Free/Pro), 권한 그룹(Admin/User) 같은 데이터는 상태가 아니라 데이터의 고유한 속성(metadata)이다. 속성에는 긍정/부정도, 우선 순위도, 진행 단계도 없다. 정적인 속성까지 배지로 감싸 버리면 '데이터의 속성'과 '처리해야 할 상태'의 경계가 무너지기 시작하므로 개인적으로 가장 주의해야할 부분이라고 생각한다.

앞에서 정리한 기준을 바탕으로 그리드를 다시 구성해 봤다. 같은 구조로 AI를 이용해 재현한 화면을 사용했다.

배지 사용을 줄이기 위한 기준을 정리해보았지만, 여전히 고민스러운 지점들이 남아있다.

• 고정 분류 값 과의 타협

위에서 얘기한 고정 분류 값에는 배지 사용을 지양하자와는 상이되는 지점이다. 정적인 분류 데이터라도 사용자가 해당 값으로 목록을 자주 필터링하고 비교해야 하는 화면이라면, 색상 구분이 데이터 탐색 속도를 높여줄 수 있다. 실용성을 위해 배지 허용 범위를 어디까지 열어둘지는 유저의 이용 패턴을 모니터링하며 조율해야 할 영역으로 남겨두어야 할 것 같다.

• 가설 검증의 한계: 본문에서 제시한 기준들은 정량적인 사용자 조사나 A/B 테스트로 검증된 절대적인 정답이 아니라, 현장에서 느낀바를 바탕으로 도출한 경험적 가설이다. 서비스 도메인과 사용자 성향에 따라 최적의 기준은 달라질 수 있다.

• 기존 사용자 경험의 관성: 이미 알록달록한 배지 화면에 익숙해진 기존 사용자라면, 시각적 요소를 덜어냈을 때 오히려 '정보가 잘 보이지 않는다'며 답답함을 느낄 수 있다. 인지 관성을 해치지 않으면서 디자인 개편을 연착륙시킬 방법도 함께 고민해야 한다.

배지를 줄이는 일 자체가 목적이 되어서는 안 된다. 핵심은 화면 위의 UI 요소들이 각자의 역할을 제대로 수행하고 있는지, 사용자의 판단을 방해하고 있지는 않은지 끊임없이 질문을 던지는 태도를 유지하는 것이다!

---

• https://www.eleken.co/blog-posts/badge-ui-design
• Badge