디바이스별 픽셀 밀도 이해하기
Device Pixel Density
모바일을 포함한 반응형 웹 디자인과 밀접한 관련이 있는 장치 별 픽셀 밀도에 대해 알아보도록 하겠습니다.
오늘 날과 같은 발빠르게 다변화하고 있는 환경, 즉 수많은 디바이스를 접하는 시대에 디바이스마다 각각 픽셀을 어떻게 처리하고 있으며, 이에 대응하는 방법이 무엇인지를 알아야 합니다.
픽셀 밀도(Pixel Density)
픽셀 밀도란 공간(대부분 inch에서 사용)에 픽셀이 들어가는 물리적인 수치를 말합니다.
(국내에서는 센치미터나 밀리미터를 사용하지만 해외에서는 인치를 사용하기 때문에 인치가 기준)
제록스에 의한 연구결과로 나온 첫 번째 맥킨토시 컴퓨터(애플2)는 인치당(inch) 72픽셀이었습니다.
첫 번째 맥킨토시 컴퓨터인 Apple 2에서는 인치당 픽셀의 갯수가 72개였습니다.
구이(GUI)라고 불리는 Graphic User Interface 는 애플에 탑재되어 있기는 했지만 이 연구는 제록스에 의한 연구 결과였으며 스티븐 잡스가 맥킨토시 컴퓨터에 탑재하게 된 것입니다.
그 이후 마이크로 소프트사에서도 GUI 를 도입하면서 윈도우 운영체제를 만들게 된 것입니다.
픽셀 기반의 GUI 가 처음 나왔을 때는 사람들이 인식하기 쉬운 그림인 그래픽 아이콘 등으로 표시되는 인터페이스를 말합니다.
그래서 오리지널 맥 아이콘 디자인을 보게 되면 아래와 같은 픽셀 기반의 아이콘 디자인이었고 이것이 구이(해외에서는 이 발음대로 읽음)의 시작이었습니다.
디바이스 픽셀 밀도(Device Pixel Dentify)
디바이스는 물리적인 기계로 스마트폰, 데스크탑, 랩탑 등과 같은 것들이 디바이스에 해당됩니다.
디바이스마다 픽셀 밀도가 달라지게 되었는데 이 시작이 2010년의 애플사가 발표한 디스플레이에서 비롯됩니다.
애플(Apple)사가 2010년 inch 당 픽셀을 x2 배로 올려서 엄청나게 선명한 레티나 디스플레이를 소개한 이후, 그래픽 디자인과 설계 과정에서 디바이스의 픽셀을 고려해야 하는 상황에 직면하게 됩니다.
이렇게 레티나 디스플레이 발표 이후에 x3(3배), x4(4배)로 계속해서 늘어나게 되었으며, 이에 따라서 비주얼(CSS 포함) 디자인 과정도 복잡해지게 되었습니다.
과거에는 1배율 밖에 없었기 때문에 배수를 고려하지 않고 1비율에서만 디자인을 해 왔지만 2010년 이후로 지금까지 픽셀의 농도가 상당히 달라지게 되어 안드로이드 디바이스에서 보여지는 뷰와 애플 디바이스에서 보여지는 뷰 그리고 랩탑, 데스크탑에서 쓰는 뷰가 각각 픽셀 비율이 모두 다릅니다.
그래서 설계 과정에서 디바이스의 픽셀을 고려해야만 합니다.
앞서 밀도(농도)라고 하는 것은 물리적인 공간 1인치 안의 픽셀의 갯수라고 언급했는데 위의 그림의 좌측에 놓여진 노트북의 픽셀이 있고 노트북이 아닌 디바이스가 작은 스마트폰의 경우는 작아진 만큼 픽셀의 갯수를 많이 설정해 놓으면서 픽셀의 갯수를 늘려서 사용자가 보다 화면을 깨끗하고 선명하게 볼 수 있도록 만들어 놓았습니다.
그래서 1배율의 픽셀 갯수가 가로,세로 각각 2배로 커졌음을 의미합니다. 그리고 여기서 말하는 2배는 사실 픽셀의 갯수는 1개에서 4개로 바뀌었다는 점입니다.
즉, 픽셀의 총 갯수는 4배 증가(가로 2배, 세로 2배)한 것이지만 물리적인 공간 크기는 그대로인 상태에서 픽셀의 갯수는 4분할이 되었기 때문에 물리적인 1인치라는 공간에 들어가는 픽셀의 갯수는 4개지만 배수로 얘기하자면 2배라고 말하는 되는 것입니다.(다음의 그림 참고)
[ 픽셀 밀도 : 물리적인 공간인 1인치 안의 픽셀의 갯수 ]
그래서 보다 세밀해진 픽셀의 망점들이 생겨나게 되었고 레티나 디스플레이에서 선명한 그래픽들이 Non-Retina Display 에서는 덜 선명한 그래픽으로 보여지게 됩니다.
위와 같은 이유로 디자인(비주얼 및 설계) 과정에서 픽셀 밀도가 상당히 중요하고 제작자 입장에서는 3배, 4배율로 커져가는 디스플레이에 대응하기 위해 그래픽 제작을 좀 더 선명하게 작업해야 합니다.
디바이스 픽셀 밀도에 영향을 받는 비트뱁 그래픽, 벡터 그래픽의 경우에 비트맵 그래픽은 선명도가 떨어지지만 벡터 그래픽은 전혀 선명도가 떨어지지 않습니다. 이런 점을 숙지하고 고해상도를 지원하는 디바이스에 적합한 그래픽 제작이 필요합니다.
이렇게 디바이스 픽셀 밀도에 영향을 받는 것 중에는 jpg, png, gif 비트맵 데이터의 경우에 주의하여 그래픽 제작이 필요하고, 벡터 그래픽의 SVG 나 CSS 같은 것은 디바이스 픽셀 밀도에 영향을 받지 않는다 는 점을 기억해야 합니다.
SVG 나 CSS 와 같은 벡터 그래픽은 디바이스 픽셀 밀도에 영향을 받지 않기 때문에
CSS 제작자는 비율 1만 고려하면 되지만 jpg, png, gif 와 같은 비트맵 데이터를 CSS 로 제어할 경우에는 배수 x2, x3, x4 등을 고려해서 작성해야 합니다.
예를 들어 사진 같은 경우에 jpg 로 제작이 되는데 이를 CSS 로 제어할 때 고려해야 한다는 것입니다.
물론 사진 아닌 그 외의 제작된 그래픽이 SVG 로 제작된다면 CSS 제어 필요성도 없어지게 될 것입니다.
정리하면, 비트맥 데이터의 경우 레티나 디스플레이에서 선명하게 보여지게 하기 위해서는
x2, x3, xn... 의 이미지가 필요하고
그에 적절한 CSS 대응 전략이 필요합니다.
CSS 의 대응 방법이나 그래픽 제작에 대한 참고는 애플 사이트를 참고하길 바랍니다.
하지만 픽셀 밀도에 영향을 받지 않는 SVG 로 그래픽 제작이 된다면 배율 1만 고려하게 되기 때문에 CSS 대응 방법에 대한 고민도 필요없을 것입니다.
현재도 대부분의 비주얼 디자이너들은 2배수, 3배수로 디자인을 해야한다고 갑론을박을 벌이기도 합니다.
국내에서는 이 글을 포스팅하는 현재에도 레티나를 고려한다고 하면서 640, 750 으로 디자인하여 CSS 개발자에게 전달하곤 합니다.
사실 비주얼 디자이너들은 전체적으로 1배율로 작업하고 비트맵 데이터가 사용되는 곳의 그래픽만 좀 더 고려하여 따로 전달해 준다면
작업자 간의 협업은 물론 사용자에게 제공해 주는 UI도 한층 업그레이드가 될 수 있습니다.
디바이스별 UI 크기
위에서 계속 언급했지만 좀 더 실무적으로 접근하여 디바이스별에 따른 UI 크기를 어떻게 해야 좋은지에 대해 짚어보도록 하겠습니다.
사용자들의 스마트폰이 제각각으로 2배수, 3배수의 픽셀 밀도를 가졌다 하더라도 스마트폰 자체의 물리적 크기가 2배, 3배 커지는 것은 아닙니다.
즉, 물리적 공간의 화면 크기는 2,3배수와 상관없이 동일합니다.
예를 들어 시안 제작을 한다고 해봅시다.
물리적 공간의 크기는 똑같은데도 불구하고 열에 아홉은 시안 작업을 2배, 3배짜리로 시안 작업을 합니다.
그래서 시안은 1배수로 작업을 하되 UI 크기를 2배율, 3배율, 4배율에서 어떻게 제작해야하는 지에 대한 고민을 하는 것이 필요합니다.
다시 말해, 물리적으로 동일한 UI 크기를 유지하려면 픽셀 면적이 x2배일 때, 44px 크기 버튼은 88px이 되어야 합니다.
각기 다른 디바이스에 이와 같은 UI 개념을 적용하기 위해 디자이너는 원래 x1(1배수) 크기 제작은 물론 x2 크기 제작이 필요해진 것입니다.
44px의 높이로 1배수로 버튼을 디자인 제작을 했다면 고해상도의 디스플레이에서는 88px 의 높이로 디자인 작업이 필요하단 의미입니다.
그렇다면 디자이너들 어떻게 작업해야 할까요?!
앞서 말한대로 x1, x2... 에 따른 UI 크기를 모두 제작해야 하는 것일까요?
애초에 UI를 1배수로 디자인을 제작했을 때 2배수로 만들게 되면 비트맵이기 때문에 깨지게 됩니다.
그래서 2배수로 작업을 하고 나누기 2를 하여 결과를 내보내도록 하는 방법을 이용합니다.
그렇게 되면 깨지지 않게 처리를 할 수 있습니다.
하지만 여기서 문제는 나누기를 했을 때 정수가 나오도록 디자인이 제작되어야 하는데 소숫점이 나오도록 디자인을 하는데에 있습니다.
만약 버튼의 높이가 89px 이라면 44.5px 이 되고 이 외의 배수 고려된 결과값 UI 크기가 .7, .4, .2 등의 소숫점으로 처리되면 브라우저는 이 소숫점을 픽셀단위로 바꾸는 과정에서 각 제조사마다 픽셀단위를 처리하는 방법이 다 다르기 때문에 간격에 문제가 생기게 됩니다.
이러한 문제를 발생시키지 않기 위해서는 정수의 결과값이 나오도록 해주어야 합니다.
그렇다면 나누기 2를 하는 방식으로 개발하도록 정수값이 나오도록 해준다면 모든 것이 해결되는 것일까요? 절대 그렇지 않습니다.
2배수인 레티나 디스플레이만 있는 것은 아니기 때문입니다.
레티나 HD, 쿼드 레티나와 같은 디스플레이(3배수,4배수...)는 또 어떻게 대응해야 할지에 대한 문제에 직면하게 됩니다.
2와 3으로 나눠서 정수로 떨어지려면 2로 나눠도 0이 나와야하고 3으로 나눠도 0이 나와야 합니다.
그렇다는 것은 디자인 작업을 6배수로 작업해야 한다는 말입니다.
하지만 일반적, 상식적으로 옳지 않은 방식이라는 것은 누구나 알 것이라고 생각합니다.
지금 국내 실무 디자이너가 하는 방식인 2배수, 3배수로 작업하는 것은 애초부터 근본적인 설계에 문제가 있다는 것입니다.
이러한 문제를 해결할 수 있는 유일한 방법은 시안을 1배수로 작업을 하고 디바이스 픽셀 밀도의 영향을 받는 비트맵 이미지만 배수별로 UI 이미지를 제작하는 것이 아니라 원본 데이터를 보존할 수 있는 그래픽 데이터(Smart Object)타입을 이용, 즉 원본 데이터인 스마트 오브젝트를 이용하여 2배수, 3배수, 4배수에 대응할 수 있는 UI 별 크기만 뽑아서 전달하는 방식을 택해야 합니다.
모바일(앱) 애플리케이션(네이티브) 환경 이해하기
아마도 이 포스팅을 보는 어떤 디자이너분은 지금쯤 이렇게 질문을 던질 지도 모릅니다.
"2배수, 3배수를 고려하여 디자인을 하더라도 정수로 떨어지지 않더라"고 말이죠...
위 같은 질문을 던지는 디자이너들은 아마도 네이티브를 대상으로 디자인 제작을 하신 분들일 것입니다.
그래서 지금까지 포스팅한 내용은 웹(모바일웹,하이브리드 웹앱 포함)에 환경에 대한 내용이었다면 다음의 글은 네이티브 환경에 대한 이야기를 해볼까 합니다.
애플은 다양한 배수를 고려할 때 정수로 떨어지는 않는 문제점을 인지하고 다음과 같은 방법을 제시하게 됩니다.
수치 측정 단위 중에 픽셀 밀도를 특정하는 독립적인 단위가 없어 디자인 제작과정이 곤란해 지게 되자 이에 대한 해결책으로 애플은 Point(pt) 단위을 제시하게 됩니다.
(참고로 웹 UI와는 별개의 문제입니다)
본래 Point 수치는 인쇄상에서 쓰는 단위로 웹 UI 에서 사용되어서는 안되는 단위입니다.
인쇄 환경과 웹 환경이 다른데도 불구하고 국내 웹디자이너들은 기존 실무자들이 그렇게 했으니까란 이유로 이해없이 여전히 pt 단위를 사용하는 안타까운 현실의 환경에
놓여 있습니다.
이 글을 접하시는 웹디자이너분이 만약 웹 UI 에서 pt 단위를 사용하고 계신다면 올바른 px 단위를 사용하시길 바랍니다.
과거에 pt 단위는 인쇄용에서 쓰는 단위였지만 애플은 장치 독립적인 단위로 쓰겠다라고 발표하게 됩니다.
그래서 포인트란 단위를 보게되면 스크린의 density 가 1배수인 경우에는 1pt = 1px 로 해석이 되고
스크린의 density 가 2배수인 레티나 디스플레이에서는 1pt 로 작업을 하면 2px 로 계산(1pt = 2px)이 되도록 만들었습니다.
말 그대로 장치 독립적이란 의미입니다. 그러면 제작자는 1px 인지 2px 인지를 고민하지 않고 1pt 만 사용하면 된다는 것입니다.
앞서 언급한 내용에서는 버튼의 높이가 1배수에서 44px 2배수에서 88px 등으로 제작을 해야 했다면 그럴 필요없이 그냥 44pt 로 작업하실 수 있다는 것입니다.
이렇게 제작이 되면 4배수, 5배수, 6배수가 나오던 간에 장치 독립적으로 사용되기 때문에 각 디바이스별 밀도에 따라 대응할 필요가 없다는 말입니다.
단, 이 환경은 웹이 아니라 모바일(앱) 애플리케이션 특히 IOS의 환경에 주안점을 두게 됩니다.
그래서 버튼의 높이를 44pt 로 제작하게 되면 장치 독립적인 단위이기 때문에 1배수에서는 44px로 2배수에서는 88px로
변경되서 보여지게 되기 때문에 물리적인 공간에 보여지는 그래픽은 둘다 선명해 보여지게 됩니다.
다시 한번 말씀드리지만 물리적인 공간 크기는 동일하므로 눈에 보여지는 크기 또한 같으며 밀도만 다른 것입니다.
그렇기 때문에 디자인 제작자들은 다양한 픽셀 밀도에 대응할 필요없이 장치 독립적인 단위를 사용하면 아무런 고민없이 디자인 제작을 하실 수 있습니다.
위의 그림을 보면서 정리하자면, 레티나 디스플레이가 아닌 곳에서는 픽셀 농도가 44픽셀이었기 때문에 위와 같이 작업이 되어 있었다면
레티나 디스플레이 환경인 2배에서는 88픽셀로 작업을 해야했고 그림을 통해 얼마만큼 선명한 지를 알 수 있을 것입니다.
여기서 더 나아가 장치 독립적인 단위를 사용한다면 레티나급 이상의 픽셀 밀도에도 대응이 가능해지게 됩니다.
그렇다면 안드로이드는?
애플과 달리 안드로이드 진영은 장치 독립적인 픽셀 밀도(DIP)단위인 DP를 만들어 냅니다.
그리고 문제는 정수 배열을 가진 애플과 달라 실수 배열을 가졌다는 점입니다.
애플보다 훨씬 복잡하고 안드로이드 개발자는 안드로이드용 수치 계산 변환툴을 이용할 정도로 피곤한 수치 계산을 한다고 합니다.
필자는 네이티브 분야를 다루지 않기 때문에 이에 대한 내용은 더이상 자세히 다루지는 못합니다.
앱등이는 아니지만 아무튼 안드로이드는 디자이너와 개발자 모두를 괴롭히고 있다고 합니다.
다만 위에 언급한 디바이스 픽셀 밀도에 대한 이해만으로도 많은 궁금점이 해소되셨길 바랍니다.
디바이스 픽셀 밀도 UI 그래픽 내보내기(디자인의 시작점)
최종적으로 정리하자면 디바이스 픽셀 밀도에 대응하는 UI 그래픽을 내보낼 때는 어떻게 해야 하는가?
애플리케이션이 아닌 웹은 운영체제보다 웹 브라우저(모바일 웹 포함)에서 보여지는 것이 더 중요하여 그런 측면에서 웹 브라우저라는 것은 픽셀 농도를 1로 처리해준다는 관점과 픽셀 밀도에 영향을 주는 것을 비트맵 밖에 없다는 점을 기억하고 사진 같은 비트맵 이미지를 제외하고는 대부분의 UI는 벡터를 사용하여 제작하며 디자인 배율은 x1(1배수)에서 시작하여 디자인을 하도록 해야 합니다.
그리고 CSS 사용과 벡터 그래픽은 깨지지 않기 때문에 최대한 벡터로 제작한 후 사용하시기를 바랍니다.
비트맵을 사용할 경우에는 포토샵 사용자라면 스마트오브젝트(고급객체)를 이용할 수 있는데 프로젝트 환경이 x3(3배수)까지 고려된다면 비트맵의 그래픽은 3배수로 작업하고 1배수의 시안에 적용하도록 해야할 것입니다.
3배수로 제작된 스마트 오브젝트를 2배수, 1배수로 작게 내보내도 깨지지 않게 되기 때문입니다.
애플리케이션 제작자라면 최대한 벡터로 작업을 하고 벡터로 만든 데이터를 Export 할 때 배수로 내보내야 할 것입니다.
[포토샵을 이용하는 애플리케이션 제작자의 경우]