저는 경비행기 조종을 배우고 있습니다. 경비행기 조종을 하면 컴퓨터에서 벗어날 수 있죠. 얼마 전에는 세스나150Cessna 150을 조종하고 있었습니다. 브리스틀 공항에 접근하면서 기체 고도를 낮게 유지하려고 고군분투하던 중, 말 그대로 구름 속으로 빨려 들어가 버렸습니다. 비행 강사는 이렇게 말했습니다. “당신이 잘못한 건 아니에요. 하지만 어쨌든 처리해야 할 문제이긴 하죠.” 무언가 다른 외부 요인이 나를 방해하더라도, 고도를 유지하는 것은 내 책임이라는 의미였습니다. 그런 상황에 대처하며 비행기를 조종하는 법을 알았어야 했죠.
비행기 조종이 아니더라도, “당신 잘못은 아니지만 처리해야 할 문제이긴 하다”라는 말은 어떤 상황에도 적용될 만한 상당히 좋은 표현이라고 생각했습니다. 이 글에서는 CSS 그리드 레이아웃과 같은 신기술을 사용할 때 구형 브라우저를 지원하는 문제를 고민해 보려고 합니다. 개발자인 우리가 고객이나 팀 동료와 브라우저 지원을 논의할 때를 생각해 보죠. 인터넷 익스플로러 9에서 표시되는 사이트 모습이 최신 버전의 파이어폭스나 크롬에서 표시되는 모습과 같지 않은 경우가 있습니다. 이 문제가 마치 우리 잘못이기라도 한 것처럼 멋쩍어하고 당황스러워할 때가 많죠. 하지만 이게 우리 잘못이 아니라는 걸 받아들여야 합니다. 다만 이 문제를 모두에게 이익이 되는 방식으로 잘 처리해내는 것은 궁극적으로 우리의 책임, 우리가 처리해야 할 문제죠.
그리드는 새로운 기능이에요! 브라우저 지원은 틀림없이 형편없을걸요?
CSS 그리드 레이아웃은 2017년 3월에 크롬, 파이어폭스, 오페라, 사파리에 탑재됐습니다. 마이크로소프트 엣지의 경우 현재 프리뷰Preview 빌드에서 플래그를 활성화하면 그리드 업데이트 버전을 사용할 수 있습니다. (편집자주 : 마이크로소프트 엣지는 2017년 10월 17일 릴리스한 버전 16부터 그리드를 정식으로 지원하고 있습니다. 이 글은 2017년 7월 4일에 게시됐습니다.) 이 글을 쓰는 현재 Can I Use 사이트에 따르면, 전 세계적으로 CSS 그리드 레이아웃을 지원하는 브라우저를 사용하는 사용자는 65.64%입니다. 접두어 -ms-를 붙인 코드를 지원하는 인터넷 익스플로러 10, 11 및 엣지 현재 버전 사용자까지 포함할 경우 수치는 70.75%로 올라가죠. (편집자주 : 2017년 11월 15일 현재 전 세계 지원 비율은 69.57%입니다. 앞서 언급한 것처럼 엣지는 이제 정식 지원 브라우저에 포함됩니다. 부분적으로 지원하는 인터넷 익스플로러 10, 11 등을 포함하면 이 수치는 75.34%로 올라갑니다. 한편, 한국 사용자의 경우 정식 지원을 받는 비율은 60.63%이며 부분적 지원을 받는 비율까지 포함하면 80.99%입니다. 한국은 인터넷 익스플로러 11 사용자가 17.9%를 차지하기에 정식 지원 비율과 부분적 지원 포함 비율의 차이가 크게 납니다. 참고로, 인터넷 익스플로러에서 지원하는 그리드 레이아웃은 현재 사양이 아닌 예전 사양입니다. 2011년 4월 발표된 W3C Working Draft 7의 사양으로, W3C는 이 버전이 ‘구식 버전이 되었다outdated‘고 밝히고 있습니다. 인터넷 익스플로러의 ‘부분적 지원’이란 접두어 사용 및 예전 사양 지원을 의미합니다.)
CSS 그리드 레이아웃처럼 방대한 규모의 기능이 이만큼 높은 비율로 브라우저 지원을 받은 적은 지금까지 한 번도 없었습니다. 이 기능을 지원받는 방문자 수가 얼마나 많을지, 그야말로 상상할 수도 없습니다.
굳이 언급할 필요 없지만 그래도 언급하자면, 여러분 사이트의 지원 브라우저 사용자 비율은 사용자의 선택에 따라 위 수치보다 더 높을 수도, 더 낮을 수도 있습니다. 그렇지만 만약 지금 새로운 사이트를 구축할 계획이라면, CSS 그리드 레이아웃을 활용할 아주 좋은 기회입니다.
왜 그리드를 사용해야 하나요?
이전 글에서 설명한 것처럼, CSS 그리드 레이아웃을 활용하면 행을 감싸는 별도의 마크업row wrapper을 작성하지 않고도 2차원 레이아웃을 구현할 수 있습니다. (편집자주 : 예를 들어 float을 쓰면 각 행을 구성하는 엘리먼트를 별도의 마크업으로 감싼 뒤 float 속성을 주고, 또 그 다음 행에 미치는 영향을 없애기 위해 그것을 ‘clear’해 주어야 합니다. 플렉스박스를 쓰더라도 행마다 새로운 플렉스 컨테이너를 선언하거나, 여러 속성을 복잡하게 계산해 활용해야 합니다. 이런 내용이 저자의 이전 글에 포함돼 있습니다.) 그리드는 2차원 레이아웃이기에, 엘리먼트를 두 줄 이상의 행에 걸치게 할 수 있습니다. 이런 방식은 합리적이고 안정적이죠.(편집자주 : 플렉스박스에서 엘리먼트를 두 줄 이상의 행에 걸치게 하려면 별도의 마크업을 작성해 트릭을 써야 합니다.)
디자인 효과도 멋지게 낼 수 있습니다. 어떤 아이템이 콘텐츠에 따라 지정된 높이보다 더 커질 여지가 있다고 해 봅시다. 이 경우에 낼 수 있는 여러 효과를 데모 페이지에서 살펴보세요.
고정된 폭을 지닌 엘리먼트와 폭이 유연하게 변하는 엘리먼트를 섞어 쓰는 것도 쉽습니다. 그리드의 fr 단위 덕분이죠. 레이아웃 안에서 크기를 고정하여 유지하고자 하는 아이템을 다루기가 더 쉬워집니다.
화면 크기에 따라 레이아웃을 그리드 컨테이너에서 재정의해서 반응형 디자인을 더 쉽게, 더 직관적으로 해낼 수도 있습니다(편집자주 : 링크 예제를 보면, 미디어 쿼리를 그리드 컨테이너인 wrapper 클래스에만 적용한 것을 볼 수 있습니다). 그래서 각 레이아웃마다 디자인을 세밀하게 조절할 수 있죠.
아이템들을 그리드 영역 위에 겹쳐 쌓을 수도 있습니다. 아이템은 z-index를 준수하기에, 여러 아이템을 동일한 그리드 셀 위에 포개어 다양한 스코프를 만들어내는 방식으로 마음껏 창조성을 발휘할 수 있습니다.
그런데 지원하지 않는 브라우저는 어쩌죠?
CSS에 이미 해결책이 있습니다. 일단 한마디 하자면, 그리드와 플렉스박스가 예전 레이아웃 방식을 덮어쓰는overwrite 방법이 그리드와 플렉스박스 사양 자체에 이미 포함돼 있답니다.
따라서 그리드 레이아웃이 지원되지 않을 경우를 대비해 float, 인라인 블록, 다중 칼럼 레이아웃, 플렉스박스, 혹은 display: table 등의 방법을 대체 수단으로 사용하고자 한다면 CSS 사양을 잘 고려해야 합니다. 이런 방법을 작성할 때는 안전하게 검증된 방식으로 작성해야 하죠. 이런 대체 수단을 설명하는 요약 문서를 만들어뒀습니다. 제가 올해 초 렌더 컨퍼런스(Render Conference)에서 발표한 내용에도 몇 가지가 나와 있죠.
CSS에 Feature Query(편집자주 : ‘@supports’ 규칙을 이용하여 브라우저 지원 여부에 따라 특정 CSS 속성을 활성화하는 방법, 이를테면 ‘사용자 브라우저가 그리드 레이아웃을 지원한다면 다음과 같은 그리드 속성을 실행하고, 지원하지 않는다면 무시하고 넘어가라’라는 식의 쿼리를 작성할 수 있습니다.)라는 기능도 있습니다. 이 기능에 대한 브라우저 지원은 매우 훌륭합니다. (편집자주 : 인터넷 익스플로러 11이 이 기능을 지원하지 않기 때문에 한국은 상황이 좀 다릅니다. 전 세계적으로는 인터넷 익스플로러 11 점유율이 고작 3.22%이기에 피처 쿼리 지원이 92.59%에 달하지만, 한국은 인터넷 익스플로러 11 점유율이 17.9%이기에 피처 쿼리 지원이 67.53%입니다.) 특히 그리드 레이아웃과 관련하여 우리에게 좋은 점은, 브라우저의 피처 쿼리 지원 여부에 대해 걱정할 필요가 없다는 것입니다. 그리드 레이아웃을 지원하는 브라우저는 무조건 피처 쿼리를 지원하기 때문입니다. (편집자주 : 인터넷 익스플로러는 그리드 레이아웃을 부분적으로 지원하며, 피처 쿼리는 지원하지 않습니다.) 자, 그럼 우리가 할 일은 CSS 파일에 다음 두 가지를 작성하는 것입니다.
1. 대체 수단 CSS
2. 그리드 CSS
일단 모든 브라우저가 대체 수단 CSS를 해석할 것입니다. 그다음, 그리드를 지원하지 않는 브라우저는 거기서 딱 멈춥니다. 하지만 그리드를 지원하는 브라우저는 그리드 CSS를 사용합니다. 그리고 CSS 사양에 정의된 (또 제가 요약 문서에서 상세하게 설명해둔) 규칙에 따라, 대체 수단 CSS가 하기로 되어 있던 많은 동작이 무효화됩니다.
이 경우 일반적으로 모든 게 완벽히 무효화되지는 않습니다. 대체 수단 CSS가 하기로 되어 있던 동작 중 몇 가지는 ‘틈새로 빠져나가서’, 그리드 레이아웃이 지배하게 된 영역에 슬며시 끼어들 수도 있습니다. 우리가 예전 방식으로 레이아웃을 작성할 때는 마치 그리드(편집자주 : 여기에서는 ‘그리드 레이아웃’이 아닌 일반적인 ‘격자’를 의미하는 보통명사입니다.)를 사용하는 것처럼 보이려고 아이템에 폭을 설정하죠. 그렇게 설정된 아이템의 폭 수치가 종종 ‘틈새로 빠져’나갑니다. 이때 우리는 그저 피처 쿼리를 사용하기만 하면 됩니다. 브라우저의 그리드 레이아웃 지원 여부를 확인한 다음, 만약 지원한다면 그 폭을 auto로 재설정합니다. 이런 식으로, 구형 브라우저를 위해 설정한 대체 수단 CSS의 다른 속성들도 얼마든지 피처 쿼리 안에서 그리드 레이아웃용으로 재설정할 수 있습니다.
우리는 지금 CSS를 하기 위해서 CSS를 사용하고 있습니다. 이것은 폴리필도 아니고 핵도 아닙니다. (편집자주 : ‘폴리필’은 특정 기능을 지원하지 않는 브라우저에 대비해 개발자가 끼워 넣는 코드 혹은 플러그인입니다. 폴리필은 대체로 자바스크립트로 만들어집니다. 핵은 같은 목적을 위해 특정 브라우저만 인식할 수 있는 CSS 코드를 작성하는 것으로, 임시방편으로 쓰이며 웹 표준이 아닙니다.) 이것은 모두 CSS 사양에 정의된 그대로의 것입니다.
대체 CSS를 쓰면 레이아웃을 두 번 쓴다는 거잖아요!
웹 사이트가 모든 브라우저에서 똑같이 보여야 한다고 가정할 때만 그렇습니다. 그런데 정말 그럴까요? 그렇지 않습니다.
제가 2002년에 쓴 글이 있습니다. (편집자주 : 저자는 이 글에서, 모든 디바이스에서 같은 모습으로 보이는 사이트를 만드는 것은 실제로 불가능하며 개발자가 사용자를 통제할 수도 없으므로, 오히려 사고를 전환하여 화면이 다르게 보이는 것을 두려워하지 말고 웹의 다양성과 역동성을 추구하자고 주장합니다.) 2002년에는 사람들이 모든 브라우저에서 사이트가 “똑같아 보이지” 않을 것을 걱정해, 레이아웃을 위해 CSS를 사용하는 방법을 배우지도 않았습니다. 하지만 저는 CSS로 레이아웃을 만들면서 사이트를 구축했습니다. 이를 위한 최선의 방법을 알아내려 노력했고 다른 사람들에게 제가 배운 것들을 가르쳤습니다. 제가 회사를 직접 운영하기 시작한 초창기에는 사이트가 넷스케이프 4에서도 작동되길 원하는 고객들을 위해 일했습니다. 줄곧 이런 일을 했죠. 20년 동안 상호운용성(편집자주 : interoperability, 어떤 기능이 서로 다른 시스템에서도 잘 동작하는 것) 문제를 다뤄왔습니다. UI가 인터넷 익스플로러 9에서도 작동해야 했던 경우도 있었습니다. 이런 구식브라우저가 존재하는 것이 결코 제 잘못은 아니었지만, 전적으로 제가 책임져야 할 문제였고, 이를 해결하는 것이 지난 수년 동안 제가 해온 일이었습니다.
여러분의 웹사이트가 정말로 모든 브라우저에서 똑같아 보여야 한다면(이유야 어떻든 간에), 그리드 레이아웃만이 제공할 수 있는 기능을 사용해서는 안 됩니다. 그럴 때는 그리드 레이아웃을 쓰지 마세요! 기존 기술로 적절히 처리할 수 없는 문제를 해결하고자 할 때 그리드 레이아웃을 사용하세요. 그리드를 사용하기로 했다면, 구형 브라우저에서도 그리드로 만든 것과 똑같은 모습을 만들어내려고 고민하지 말고, 구형 브라우저에는 구형 브라우저대로 좋은 사용자 경험을 줄 수 있는 대체 수단을 만들어내세요. 그리드의 위력은 이전에는 불가능했던 일을 할 수 있다는 것입니다. 그런 일을 위해 그리드를 사용하세요. 단지 예전 디자인을 똑같이 만들어내기 위해 그리드를 사용하지는 마세요.
그냥 폴리필 한 방으로 해결이 안 될까요?
전체 레이아웃에 전역 폴리필을 적용하는 것은 방문자에게 아주 불쾌한 경험이 될 것입니다. 그리드가 하는 일은 자바스크립트를 기반으로 하는 방법으로는 잘 되지 않을 것입니다. 결국 끔찍하기 이를 데 없는, 불안정한 로딩을 경험하게 될 것입니다. 구형 브라우저에 자바스크립트를 통해 그리드 레이아웃을 억지로 적용하기보다는 구형 브라우저의 기능에 맞는 단순한 경험을 제공하는 편이 훨씬 낫습니다.
그리드 레이아웃 지원을 위해 폴리필을 사용할 경우, 시간이 지나면 수가 감소할 사용자 층 때문에 개발 및 테스트 시간이 현저하게 증가할 가능성이 큽니다. 다시 말씀드리지만 모든 이에게 동일한 레이아웃을 제공하는 것이 여러분이 제작하는 사이트의 궁극적인 목표라면, 지금 당장은 그리드를 사용하지 않기를 권장합니다. 어쩌면 모든 사용자가 그리드 레이아웃을 지원받을 수도 있었겠지만, 구형 브라우저가 있다는 사실 때문에 그럴 수 없다는 점을 받아들여야만 할 것입니다.
웹 개발이란 이런 것입니다!
전체적으로 완벽하게 지원되지 않는 것을 다루는 것. 이게 바로 웹디자인의 업무 방식입니다. 여러분이 몸담은 업계의 본성이죠. 프로젝트를 수행할 때마다 불가피하게 존재하는 기술적 타협점을 찾아내야 합니다.
여러분의 일은 새로 배워서 쓸 수 있게 된 기술을 활용해 고객이나 상사가 비즈니스 목표를 달성하게끔 최선의 방법을 조언하는 것입니다. 이 일은 새로운 것을 배워야만 할 수 있는 일이죠. 새로운 것을 배워야만 어떤 타협점이 가치 있느냐 하는 것을 조언할 수 있습니다. 마크업을 더 추가하고, 개발 시간을 더 들이고, 모든 브라우저에서 비슷한 느낌이 나도록 절충안을 찾아가는 등의 비용을 감수하면서도 디자인 일관성을 추구할 것인가? 아니면 인터넷 익스플로러 9를 위해서는 단순한 레이아웃으로 가면서 개발 시간을 줄이고, 대신 최신 기술을 사용해 더욱 더 성능이 뛰어난 사이트를 만들 것인가? 충분한 이해가 뒷받침된다면 자신만의 주장을 펼칠 수가 있습니다.
새로운 기술을 사용했을 때 전혀 혜택이 없다면 사용하지 마세요. 그러나 고객이 원하는 것이 그리드 같은 신기술을 사용해야만 이루어낼 수 있거나, 그리드를 사용하면 빠르게 처리할 수 있지만, 그리드 없이는 고생이 불 보듯 뻔하다면, 무엇을 버리고 무엇을 취할 것인지, 또 어떤 지점에서 타협할 것인지를 다양한 방식으로 설명하세요.
개발 시간에 근거해 설명하십시오. 신기술 덕분에 작업의 복잡함이 줄어들어, 현재 및 미래의 개발 시간을 얼마나 많이 줄일 수 있는지 설명하세요.
사실에 근거해 설명하십시오. 이를테면 그리드 레이아웃을 사용하지 않고는 견고하게 만들 수 없는 멋진 디자인을 디자이너가 제시했다는 사실을 이야기하세요.
성능에 근거해 설명하십시오. 그리드 레이아웃을 사용하지 않는다면 의존할 수밖에 없는 크고 무거운 프레임워크를 그리드 레이아웃 덕분에 버릴 수 있기에, 많은 경우에 성능을 높일 수 있습니다.
그리드 레이아웃을 선택한다면 그 대가로 구형 브라우저에는 더 단순한 형태의 레이아웃을 보여줄 수밖에 없습니다. 하지만 그렇다고 해서 “레이아웃이 없는” 것은 아닙니다. 또한 여러분은 브라우저들이 그리드를 지원하는 비율이 지금까지 다른 CSS 기능을 지원하던 비율과 같지 않다는 사실도 설명할 준비가 되어 있어야 합니다. 그리드 레이아웃은 현재 거의 모든 브라우저에서 구현되고 있습니다. 엣지는 프리뷰 빌드에서 플래그를 활성화하면 그리드 업데이트 버전을 지원합니다. (편집자주 : 앞서 언급한 것처럼 엣지는 10월 17일부터 그리드를 정식 지원하고 있습니다.) 그리드를 지원하지 않는 브라우저들은 역사를 통해 우리가 보아왔던 것보다 훨씬 더 빠른 속도로 사라져가고 있습니다.
무엇을 버리고 무엇을 취할 것인지에 대해 여러분이 관련 정보를 모두 파악하고 있다면 이런 논의는 어렵지 않게 할 수 있습니다. 구형 브라우저가 존재한다는 사실은 여러분 잘못이 아닙니다. 이런 논의를 할 때, 모든 브라우저에서 사이트가 똑같아 보이지 않는 것이 자신의 잘못이라는 식으로 행동하지 마세요. 그 브라우저는 지난 10년 사이에 출시된 것들이고, 여러분이 사용하는 기술은 겨우 올해 출시된 것입니다. 여러분 잘못이 아닙니다. 다만 여러분이 처리해야 할 문제인 거죠. 각 프로젝트에서 올바른 길로 나아갈 수 있도록 스스로 자리를 잘 잡는 것, 그것이 웹 전문가로서 여러분이 처리해야 할 문제이자 책임져야 할 의무입니다.
우리는 이런 방향으로 나아가고 있습니다!
테이블로 레이아웃을 만들다가 CSS를 사용하게 되면서 웹의 모습이 바뀌었습니다. 픽셀 퍼펙트pixel perfect의 파편화된 이미지들로 구성된 웹 페이지 세계를 떠나, 더 유연하면서 텍스트가 기반이 되는 세계, 프린트 디자인과는 사뭇 다른 세계로 오게 됐죠. 지난 15년 동안 웹의 모습을 규정한 것은 CSS 기술과 그 한계였습니다. 이제 그리드나 플렉스박스, 쉐이프(CSS Shapes, 편집자주 : CSS에 기하학 형태를 지정하여, 그 주위를 둘러싼 텍스트가 사각형이 아닌 해당 기하학 형태에 따라 흐를 수 있도록 해주는 기능. 현재 크롬, 사파리, 오페라 등에서 지원됩니다.)와 같은 새로운 레이아웃 방법들이 웹의 모습을 다시금 규정할 것입니다. 그러나 또 그것만 붙잡고 있어서는 안 됩니다. 실험하고 배워서 새로운 것들을 만들어내야 하죠.
그렇게 하기 위해서는, 누군가를 위해 사이트와 애플리케이션을 만들 때 그런 새로운 방이 얼마나 좋은 것인지를 그들에게 적극적으로 보여줘야 합니다. 웹, 브라우저, 특정 기능을 브라우저가 지원하는 데 걸리는 시간 등에 대해 우리 각자 나름대로 생각하는 바가 있겠죠. 적어도 새로운 것들을 배우는 동안만은 그런 믿음을 내려놓아야 합니다. 그제야 새로운 프로젝트에 들어갈 때마다 올바른 결정을 내릴 수 있을 겁니다. ‘이거 아니면 저거’ 식의 선택이 아니라, 타협점이 항상 존재할 것입니다. 우리의 일이라는 건, 언제나 그랬듯이, 타협점을 모색하는 것입니다.
