Supporting older browsers

김동현·2026년 3월 18일

mdn 학습 번역 - CSS

목록 보기

33/190

구형 브라우저 지원하기 (Supporting older browsers)

여러분의 웹사이트 방문자 중에는 구형 브라우저를 사용하거나, 여러분이 땀 흘려 적용한 최신 CSS 기능을 지원하지 않는 브라우저를 사용하는 분들도 꽤 있을 거예요. 웹 플랫폼에는 늘 새롭고 신기한 CSS 기능들이 지속적으로 추가되기 때문에, 이는 웹 개발을 하면서 정말 흔하게 겪는 상황이랍니다. 브라우저를 만드는 회사들마다 우선적으로 개발하는 기능이 다르다 보니, 브라우저별로 최신 기술을 지원하는 수준도 제각각이거든요.

이번 시간에는 웹 개발자인 우리가 최신 웹 기술을 마음껏 사용하면서도, 구형 기기나 구형 브라우저를 쓰는 사용자들까지 우리 사이트를 문제없이 잘 이용할 수 있게 보장하는 방법에 대해 재미있게 알아볼게요!

사전 지식 (Prerequisites):	HTML 기초 (HTML 소개 학습하기), 그리고 CSS가 어떻게 동작하는지에 대한 이해 (CSS 스타일링 기초 학습하기).
학습 목표 (Objective):	우리가 사용하고 싶은 최신 기능들을 지원하지 않을 수도 있는 구형 브라우저 사용자들을 위해, 레이아웃에 대한 호환성(지원)을 제공하는 방법을 완벽히 이해하는 것.

우리 사이트의 브라우저 환경 파악하기 (What is the browser landscape for your site?)

웹사이트마다 타겟으로 하는 고객층(사용자)이 모두 다릅니다. 어떤 방식을 사용해서 구형 브라우저를 지원할지 결정하기 전에, 우선 우리 사이트에 방문하는 분들 중 구형 브라우저를 쓰는 비율이 얼마나 되는지부터 파악해야 해요.

이미 운영 중인 기존 웹사이트에 새로운 기능을 추가하거나 개편하는 상황이라면 꽤 간단합니다. 방문자들이 어떤 기기와 브라우저 환경을 쓰는지 알려주는 애널리틱스(Analytics, 통계 분석 도구)가 이미 연동되어 있을 확률이 높으니까요! 만약 아직 애널리틱스를 달아두지 않았거나 아예 새로운 사이트를 처음 런칭하는 거라면, Statcounter 같은 사이트의 도움을 받아보세요. 지역별로 필터링할 수 있는 아주 유용한 브라우저 점유율 통계를 확인할 수 있답니다.

통계뿐만 아니라 사람들이 우리 사이트를 접속하는 기기의 종류와 사용 방식도 꼭 함께 고민해 보셔야 해요. 예를 들어 모바일 기기를 통한 접속률이 평균보다 훨씬 높을 수도 있겠죠. 그리고 항상 잊지 말아야 할 가장 중요한 점은, 접근성(Accessibility)과 보조 기술(스크린 리더 등)을 사용하는 분들을 최우선으로 배려해야 한다는 점입니다. 어떤 종류의 서비스냐에 따라 이건 정말 치명적으로 중요할 수 있어요.
개발자들은 종종 특정 환경의 단 1% 사용자 경험을 완벽하게 만들려고 밤을 새우면서 고민하는데, 정작 접근성 지원이 필요한 훨씬 더 많은 수의 사용자들을 깜빡 놓치는 실수를 하기도 한답니다.

💡 강사님의 꿀팁: 실무에서는 "우리가 어디까지 브라우저를 지원할 것인가(Target Browser 범위)"를 정하는 게 프로젝트 초기 기획 단계의 핵심 안건 중 하나예요! 구글 애널리틱스(GA) 등을 보고 점유율이 0.5% 미만인 아주 오래된 브라우저는 과감히 지원을 중단(Drop)하기도 한답니다. 하지만 시각장애인 분들이 많이 사용하는 스크린 리더 환경 등 접근성(Accessibility) 관련 지원은 절대 타협해서는 안 되는 필수 영역이라는 점, 꼭 명심하세요!

사용하려는 기능의 지원 현황 파악하기 (What is the support for the features you want to use?)

MDN의 각 기능 페이지 하단에 가시면 "Browser compatibility(브라우저 호환성)"라는 섹션이 있고, 거기에 아주 유용한 표가 하나 들어있어요. 사이트 방문자들이 어떤 브라우저를 주로 쓰는지 파악하고 나면, 내가 쓰고 싶은 특정 기술이 각 브라우저에서 얼마나 잘 돌아가는지, 그리고 그 기술을 쓸 수 없는 환경의 방문자를 위해 대안(fallback)을 제공하는 게 얼마나 쉬울지 평가해 볼 수 있거든요.

예를 들어, grid-template-columns 속성에 대한 브라우저 호환성 표를 간략히 요약해 드리면 아래와 같습니다. (실제 MDN 문서를 보면 훨씬 자세한 인터랙티브 표를 볼 수 있어요!)

브라우저 호환성 (grid-template-columns)

기능	Chrome	Edge	Firefox	Opera	Safari	모바일 (Android/iOS)
`grid-template-columns`	지원 (57)	지원 (16)	지원 (52)	지원 (44)	지원 (10.1)	전반적 지원 (57+)
`Animation of tracks`	지원 (107)	지원 (107)	지원 (66)	지원 (93)	지원 (16)	전반적 지원 (107+)
`subgrid`	지원 (117)	지원 (117)	지원 (71)	지원 (103)	지원 (16)	전반적 지원 (117+)
`masonry` 🧪	미지원	미지원	미지원	미지원	프리뷰 지원	미지원

MDN에서는 모든 CSS 속성 페이지마다 이처럼 브라우저 호환성 정보를 표 형태로 친절하게 제공하고 있어요. 주요 브라우저 목록은 물론이고, 각 브라우저의 몇 버전부터 해당 속성을 지원하기 시작했는지까지 다 나와 있죠! 표의 열 머리글에는 브라우저 이름이 적혀 있습니다. 방금 제가 요약해 드린 표나, 직접 grid-template-columns 페이지로 들어가셔서 가장 최근에 추가된 subgrid 값과, 아직 실험적(Experimental) 기능이라 대부분 지원되지 않는 masonry 값을 한번 주의 깊게 살펴봐주세요.

이 호환성 표들을 보면 내가 쓰려는 기술과 친한 브라우저는 무엇인지, 언제부터 지원됐는지 명확하게 알 수 있습니다. 게다가 데스크톱 브라우저와 스마트폰(모바일) 브라우저의 호환성 정보가 따로따로 분리되어 표시되니 정말 편리하죠.

특정 기능이 얼마나 널리 지원되는지 알아볼 때 사용하는 또 다른 엄청나게 유명한 방법은 Can I Use 웹사이트를 활용하는 거예요. 이 사이트에는 웹 플랫폼의 거의 모든 기능이 나열되어 있고, 각 기능이 브라우저별로 현재 어떤 지원 상태인지 상세히 알려줍니다. 위치별(국가별) 사용 통계도 볼 수 있어서, 전 세계 특정 지역의 사용자들을 콕 집어 타겟팅하는 사이트를 만들 때 정말 요긴해요. 심지어 여러분의 구글 애널리틱스 계정을 연동해서, 철저하게 내 사용자들의 데이터를 기반으로 분석 결과를 뽑아볼 수도 있답니다!

사용자들의 브라우저 덕분에 그들이 어떤 기술 환경에 있는지 파악하고, 내가 쓰고 싶은 최신 기능들의 크로스 브라우저(cross-browser) 지원 상황을 알아보는 과정은 정말 중요해요. 이 과정을 잘 거치고 나면, 앞으로 어떤 방식으로 개발을 해나갈지 결정하고 모든 사용자들을 완벽하게 지원하는 방법을 아는 유리한 고지에 설 수 있게 됩니다.

💡 강사님의 꿀팁: 'Can I Use'는 프론트엔드 개발자들의 영혼의 단짝입니다! 새로운 CSS 속성이나 자바스크립트 문법을 쓰려고 할 때마다 무조건 Can I Use부터 검색해보는 습관을 들이세요. 주니어 개발자들이 현업에서 자주 하는 실수가, 본인 최신 크롬 브라우저에서만 잘 돌아가는 걸 보고 "완성했다!"고 생각하는 거랍니다. 사파리나 구형 기기에서는 화면이 와장창 깨져 있을지도 몰라요!

기능 지원이 모든 환경에서 '완벽히 똑같은 외형'을 의미하진 않습니다 (Feature support does not mean identical appearance)

웹사이트가 세상에 존재하는 모든 브라우저에서 자로 잰 듯 똑같이 보일 수는 없습니다. 여러분의 사이트를 스마트폰으로 보는 분도 있을 테고, 으리으리한 대형 데스크톱 모니터로 보는 분도 있을 거예요. 또 누군가는 구형 브라우저 버전을, 누군가는 방금 업데이트된 따끈따끈한 최신 브라우저를 쓰겠죠. 시각 장애가 있으셔서 화면 내용을 스크린 리더(화면 읽기 프로그램)로 듣고 계시는 분도 있을 거고, 글씨가 잘 안 보여서 화면을 잔뜩 확대(Zoom in)해서 보시는 분도 있을 겁니다.

모든 사용자를 지원한다는 것은, 방어적으로 잘 설계된 버전의 콘텐츠를 제공한다는 의미예요. 즉, 최신 브라우저에서는 눈이 부시게 멋지게 보이면서도, 사용자가 어떤 환경이나 기기로 접속하더라도 뼈대가 되는 핵심 내용과 기능만큼은 막힘없이 사용할 수 있도록(기본적인 수준으로) 서비스하는 거죠.

이런 튼튼한 기본기는 콘텐츠의 구조(HTML)를 올바르게 짜서, 페이지의 흐름(Normal flow) 자체가 논리적으로 자연스럽게 읽히도록 만드는 것에서 출발합니다. 데이터 요금제가 제한된 척박한 환경의 사용자라면, 브라우저가 이미지나 웹 폰트, 심지어 여러분이 공들여 짠 CSS 파일 자체를 로드하지 않을 수도 있거든요! 하지만 이렇게 꾸밈 요소들이 싹 빠져버린 상황에서도, 텍스트(콘텐츠)만큼은 여전히 읽을 수 있고 접근 가능해야만 해요. 그렇기 때문에 잘 짜인 구조의 HTML 문서가 언제나 출발점이 되어야 합니다.

스스로에게 항상 이 질문을 던져보세요: "만약 내 사이트에서 스타일시트(CSS)를 완전히 날려버리더라도, 내용이 무슨 말인지 이해가 될까?"

모든 사람에게 100% 똑같은 시각적 경험을 제공하려고 끙끙대며 시간을 쏟는 것은 상업적으로도 타산이 맞지 않는 일입니다. 사용자들의 접속 환경은 우리가 상상하는 것 이상으로 다양하고, 우리의 통제 범위를 한참 벗어나 있기 때문이죠. 우리는 그저 '아무것도 없는 순수 HTML 페이지'와 '풀옵션이 장착된 화려한 웹사이트' 사이에서 적절한 균형을 찾아야 해요.

사이트에 CSS를 쏙 빼버린 민낯 버전(plain view)을 띄워놓고, 대비책(fallback) 상태에서도 사이트 접근성에 무리가 없는지 직접 테스트해 보는 걸 적극 추천합니다. 이런 민낯 상태의 화면은 구형 브라우저를 쓰는 소수의 사람들만 볼 것 같죠? 아닙니다! 여러분의 주요 타겟 고객(최신 브라우저를 쓰는 분들)도 인터넷 연결이 순간적으로 끊기거나 잠시 오류가 났을 때 이 화면을 마주할 수 있어요. CSS를 잘 다루면 이런 훌륭한 대비책을 만드는 게 훨씬 수월해집니다.

결론적으로, 여러분이 확실하게 통제할 수 있는 것들에 집중하는 편이 낫습니다. 즉, 웹사이트의 접근성(Accessibility)을 높이는 데 시간을 투자해서 결과적으로 더 많은 사람들이 여러분의 서비스를 즐겁게 이용할 수 있게 만들어주세요!

💡 강사님의 꿀팁: 이를 전문 용어로 점진적 향상(Progressive Enhancement)과 우아한 성능 저하(Graceful Degradation)라고 부릅니다. 또한 뼈대부터 잘 만들어야 한다는 뜻에서 시맨틱 HTML(Semantic HTML)을 작성하라고 항상 강조하죠. <header>, <nav>, <main>, <article> 같은 태그를 용도에 맞게 잘 쓰면, 디자인이 다 깨져도 스크린 리더기나 검색 엔진 봇(Bot)이 문서를 아주 똑똑하게 이해한답니다. 디자인보다 구조가 먼저입니다!

CSS에서 폴백(대비책) 만들기 (Creating fallbacks in CSS)

CSS 명세(specifications) 문서들에는 비슷한 역할을 하는 두 가지 기능(예를 들어 레이아웃 기능들)이 하나의 요소에 동시에 적용되었을 때 브라우저가 어떻게 대처해야 하는지에 대한 규칙이 적혀 있습니다.

예를 들어, 어떤 요소에 Float 처리를 해놨는데 그 요소가 CSS Grid 컨테이너 안에 있는 자식(Grid Item)이기도 하다면 어떻게 될까요? 또, 한 요소에 margin-top 속성과 margin-block-start 속성을 둘 다 적어두면 브라우저가 어떻게 판단할지에 대한 약속이 다 정해져 있답니다.

브라우저는 자기가 모르는 새로운 CSS 기능을 발견하면, 에러를 뿜으며 화면을 멈추는 대신 그 줄의 코드가 유효하지 않다고 생각하고 그냥 조용히 무시해 버립니다. 브라우저가 자신이 지원하지 못하는 CSS 속성이나 값을 이렇게 쿨하게 버려주기 때문에, 우리는 동일한 CSS 룰셋(Ruleset) 안에 '옛날 방식의 값'과 '최신 방식의 값'을 사이좋게 나란히 적어둘 수 있어요!

단, 지켜야 할 규칙이 하나 있습니다. 반드시 옛날 값을 먼저 적고, 그 다음에 최신 값을 적어주세요. 그래야 최신 값을 아는 브라우저가 나타났을 때, 나중에 쓴 최신 값으로 옛날 값(폴백)을 예쁘게 덮어씌울(overwrite) 수 있거든요. (CSS는 캐스케이딩 방식이라 아래에 적은 게 힘이 더 세니까요!)

쉬운 예시를 들어볼게요. 요즘 대부분의 모던 브라우저들은 display 속성에서 두 단어를 쓰는 문법(two-value syntax)을 잘 지원합니다. 하지만 이걸 모르는 옛날 브라우저라면, 두 단어 문법을 무시하고 바로 윗줄에 적어둔 옛날 방식의 한 단어(single-value) 문법을 쓰게 될 거예요.

.container {
  display: inline-flex;
  display: inline flex;
}

이와 비슷하게, 브라우저의 이런 똑똑한 에러 처리 방식 덕분에 과거에 유행했던 벤더 프리픽스(vendor-prefixed) 기능들을 브라우저가 더 이상 지원하지 않게 되더라도, 예전에 짜둔 CSS 코드 베이스가 여전히 고장 나지 않고 돌아갈 수 있는 거랍니다.

요즘은 벤더 프리픽스를 직접 손으로 일일이 다는 일이 꽤 드물지만, 만약 꼭 접두사가 붙은 속성이나 값을 적어야 한다면 표준(Standard) 값보다 무조건 앞줄에 적어주세요. 그래야 훗날 브라우저가 벤더 프리픽스 없이 표준 값을 지원하게 되었을 때, 접두사가 붙은 값을 버리고 표준 값으로 싹 덮어쓸 수 있답니다.

💡 강사님의 꿀팁: 요즘 현업에서는 Webpack, Vite 같은 빌드 도구나 PostCSS의 Autoprefixer 플러그인을 기본으로 사용합니다. 그래서 개발자가 일일이 -webkit- 이나 -moz-를 안 붙여도 빌드할 때 컴퓨터가 알아서 싹 붙여주죠! 정말 편해졌죠? 하지만 브라우저가 코드를 위에서 아래로 읽으며 모르는 건 무시하고(Fallback), 아는 건 덮어쓴다(Overwrite)는 이 핵심 원리는 디버깅을 위해 반드시 머릿속에 담아두셔야 합니다.

새로운 선택자 사용하기 (Using new selectors)

모든 브라우저에서 다 지원하지는 않는 따끈따끈한 '새로운 선택자(Selector)'를 쓸 때는 조금 더 신중하게 접근해야 해요. 여러 개의 선택자를 쉼표(,)로 구분해서 길게 나열했을 때, 만약 그중 단 하나라도 유효하지 않은(브라우저가 모르는) 선택자가 섞여 있다면 브라우저는 해당 스타일 블록 자체를 통째로 무효 처리하고 싹 다 무시해버리거든요!

만약 특정 브라우저가 아직 모를 수도 있는 벤더 프리픽스 의사 요소(pseudo-elements)나 새로운 의사 클래스(pseudo-classes)를 함께 적어야 한다면, 접두사가 붙은 값들을 :is()나 :where() 같은 관대한 선택자 목록(forgiving selector list) 함수 안에 살포시 감싸주세요. 이렇게 하면 선택자 블록 전체가 한 번에 무효화되어 억울하게 무시당하는 일을 막아낼 수 있답니다.

:is(:-prefix-mistake, :unsupported-pseudo),
.valid {
  font-family: sans-serif;
}
:-prefix-mistake,
:unsupported-pseudo,
.valid {
  color: red;
}

위 예제를 같이 볼까요? 첫 번째 블록에서는 :is()를 쓴 덕분에 에러가 나지 않아서 .valid 요소의 폰트가 sans-serif로 예쁘게 적용될 거예요. 하지만 두 번째 블록에서는 :is() 없이 알 수 없는 선택자들과 함께 적었기 때문에 전체 룰이 무시되어 버립니다. 그래서 글자색이 red로 바뀌지 않게 되는 거죠!

기능 쿼리 (Feature queries)

기능 쿼리(Feature queries)는 현재 페이지를 띄우고 있는 브라우저가 특정 CSS 기능을 지원하는지 안 하는지, 우리가 직접 코드로 물어보고 테스트할 수 있게 해주는 아주 강력한 마법 같은 기능이에요.

이게 무슨 뜻이냐면, 먼저 옛날 기능들로 돌아가는 기본 CSS를 쫙 짜둔 다음에, 기능 쿼리로 브라우저에게 "혹시 너 이 최신 기능 지원하니?"라고 묻는 겁니다. 만약 브라우저가 "응, 나 그거 알아!"라고 대답하면, 그 쿼리 블록 안에 넣어둔 화려하고 세련된 최신 CSS를 추가로 와르르 쏟아부어 주는 거죠!

자, 실제로 subgrid 기능을 브라우저가 지원하는지 테스트해보고, 지원한다면 그에 맞게 스타일을 바꿔치기하는 예제 코드를 한번 살펴볼게요.

* {
  box-sizing: border-box;
}

.wrapper {
  background-color: palegoldenrod;
  padding: 10px;
  max-width: 400px;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

.item {
  border-radius: 5px;
  background-color: rgb(207 232 220);
}

@supports (grid-template-rows: subgrid) {
  .wrapper {
    grid-template-rows: subgrid;
    gap: 10px;
    background-color: lightblue;
    text-align: center;
  }
}

<div class="wrapper">
  <div class="item">Item One</div>
  <div class="item">Item Two</div>
  <div class="item">Item Three</div>
  <div class="item">Item Four</div>
  <div class="item">Item Five</div>
  <div class="item">Item Six</div>
</div>

이 기능 쿼리(@supports)는 요즘 나오는 모던 브라우저들에서는 찰떡같이 완벽하게 지원됩니다.

코드를 작성하실 때 꼭 추천하는 순서가 있어요. 일단 기능 쿼리 블록 바깥쪽에는 완벽하게 검증된 기능들 위주로 CSS를 작성하세요. 그래서 브라우저 종류를 막론하고 모든 사용자가 무난하게 사이트를 쓸 수 있게(사용 가능하고 접근 가능하게) 기본 세팅을 마치는 겁니다. 그 다음, 기능 쿼리(@supports) 블록을 열고 그 안에 새로운 기능들을 추가하는 거예요. 이렇게 하면 그 최신 기능을 아는 똑똑한 브라우저들만 쿼리 안쪽의 코드를 읽어서 한층 업그레이드된 화면을 보여주게 됩니다.

뼈대가 되는 코드를 먼저 잘 작성한 뒤에, 지원 여부에 따라 기능을 살포시 얹어주는 이 멋진 접근법(Enhancement)을 적극 활용해 보세요!

💡 강사님의 꿀팁: @supports는 자바스크립트를 쓰지 않고 오직 CSS만으로 브라우저 분기 처리를 해줄 수 있는 아주 소중한 도구입니다. 예전에 display: grid나 display: flex 같은 굵직한 신기능들이 세상에 막 등장하던 과도기에 정말 요긴하게 쓰였고, 지금도 최신 스펙을 도입할 때 안전망으로 톡톡히 제 역할을 한답니다.

구형 브라우저 테스트하기 (Testing older browsers)

내 사이트가 정말로 구형 브라우저에서 잘 돌아가는지 두 눈으로 직접 확인(테스트)하고 싶다면, Sauce Labs 같은 온라인 테스트 도구들을 써보는 걸 추천해요. 자세한 내용은 MDN의 테스트(Testing) 모듈 문서에 친절하게 설명되어 있으니 꼭 한번 읽어보시길 바랍니다!

요약 (Summary)

자, 축하합니다! 여러분은 이제 구형 브라우저를 위해 안전한 대비책(fallback) CSS를 만들어주는 방법과, 새로운 기능을 안심하고 테스트해서 적용하는 지식을 완벽하게 장착하셨어요. 이제 앞으로 어떤 기상천외한 새로운 웹 기술이 등장하더라도 쫄지 않고 여유롭게 활용할 수 있는 자신감이 생기셨을 겁니다.

지금까지 CSS 레이아웃에 관한 여러 아티클을 열심히 달려왔으니, 이제 여러분의 이해도를 직접 점검해 볼 시간입니다! 기본 레이아웃 이해도 평가(Fundamental layout comprehension) 모듈로 이동해서 여러분의 실력을 뽐내보세요!

참고 자료 (See also)

조금 더 깊이 파고들고 싶다면 아래 문서들을 참고해 보세요:

MDN 개선에 도움을 주세요 (Help improve MDN)

이 문서가 학습에 도움이 되셨나요? (Was this page helpful to you?)
[Yes][No]

문서 기여 방법 알아보기: Learn how to contribute
최종 수정일: 2025년 12월 19일 (MDN contributors 작성)
이 문서를 GitHub에서 보기 | 문서의 문제점 신고하기

김동현

프론트에_가까운_풀스택_개발자

이전 포스트

Legacy layout methods

다음 포스트