“98% 지원”이 생각보다 별로 안 넉넉한 이유

• “98% 지원”은 듣기엔 압도적으로 좋아 보이지만, 기본 기능에서는 전혀 다른 의미가 됨

  • 복권을 98% 확률로 맞히면 미친 행운이지만, 식당이 98% 확률로만 식중독을 피하게 해준다면 그 식당은 매달 또는 매주 사람을 아프게 하는 곳임
  • 회사가 월급을 98% 확률로만 준다거나, 내가 식당에서 98% 확률로만 계산한다면 아무도 그걸 ‘충분히 좋다’고 안 봄

• 웹사이트에서 98%는 곧 “약 1억 5천만 명은 안 될 수 있음”이라는 뜻임

  • 전 세계 인구나 브라우저 사용자를 기준으로 보면 2%는 작은 숫자가 아니라 거대한 사용자 집단임
  • 어떤 사이트가 새 기능을 넣고 98% 방문자에게만 동작한다면, 사실상 기존 사용자 2%를 문전박대하는 셈이라는 비유가 나옴

• 더 큰 함정은 “전체 인구의 98%”가 “내 서비스 사용자의 98%”가 아닐 수 있다는 점임

  • 어떤 기술이 일반 통계로는 널리 지원돼도, 내 실제 방문자층에서는 지원률이 훨씬 낮을 수 있음
  • 저자는 고객 사이트에서 중첩 CSS 지원 여부를 직접 확인했는데, 최근 1년 방문 브라우저 중 약 70%만 해당 기능을 지원했음
  • 즉 “표준이고 안전하게 써도 됨”처럼 보였던 기능이 실제로는 방문자의 30%를 놓치는 선택이 될 수 있었음

• 결론은 최신 기능을 쓰지 말자는 얘기가 아니라, 깨졌을 때의 실패 방식을 설계하자는 쪽에 가까움

  • 새 브라우저 기능이 지원되지 않아도 핵심 사용 흐름이 유지되면 괜찮음
  • 반대로 우아한 성능 저하 없이 화면이나 기능이 망가지면, 그 기능은 “널리 지원됨”이라는 말로 포장하기 어려움
  • 글쓴이는 98% 통계를 게으른 지름길이라고 부름. 진짜 견고한 엔지니어링은 대부분이 아니라 경계 사례를 어떻게 다루는지에서 갈린다는 주장임

---

기술 맥락

• 여기서 중요한 선택은 최신 CSS나 브라우저 API를 쓸지 말지가 아니라, 지원하지 않는 환경에서 어떤 경험을 남길지예요. 기능이 안 보이는 정도인지, 핵심 플로우가 막히는지에 따라 같은 98%도 완전히 다른 리스크가 되거든요.

• 특히 브라우저 지원률은 전역 통계보다 서비스 로그가 더 중요해요. 글에 나온 중첩 CSS 사례처럼 일반적으로는 널리 지원된다고 해도, 실제 방문자 브라우저 분포에서는 70% 수준일 수 있어요. 이러면 빌드 파이프라인에서 Sass를 걷어내는 결정이 꽤 큰 장애로 바뀔 수 있죠.

• 그래서 실무에서는 기능 지원표만 보는 게 아니라, 내 사용자 분석 데이터와 실패 시나리오를 같이 봐야 해요. 결제, 로그인, 문서 열람, 검색 같은 핵심 기능이면 2% 실패도 제품 입장에서는 꽤 큰 손실이 될 수 있거든요.

• 현실적인 해법은 Progressive Enhancement에 가까워요. 기본 동작은 오래된 환경에서도 살려두고, 최신 기능은 가능한 환경에서 경험을 개선하는 층으로 올리는 방식이에요.