written by http://www.bluejini.net/archives/634
[잡솔] 아이폰6, 아이폰6+의 해상도
2015.11.17 수정. 2편 [잡솔] 아이폰6, 아이폰6+의 해상도 2편 (디자이너의 작업) 을 새로 등록했습니다. 아래의 글이 어려우시면 2편을 참고하시기 바랍니다.
커뮤니티들에서 기획자와 디자이너들을 포함하여 개발자들이 해상도 때문에 괴로워하는 모습을 보게 되었습니다. 물론 기본적인 문제는 기기와 해상도가 늘어남에 따른 검수 작업 증가지만 그보다는 어떻게 작업해야 하는지를 몰라서 멘붕에 빠진 모습이 더 자주 보였습니다. 그래서 관련 포스팅을 한 번 해보려 합니다.
한줄 정리 : 알고 보면 간단하다.
기존보다 맞춰야 할 해상도는 많아졌지만 어차피 제일 큰 사이즈로 작업 후 리사이즈로 이미지를 맞추는건 동일합니다. 여전히 안드로이브보다 훨씬 수월하고요. 단지 아이폰 6+의 DPI에 맞추어 아이폰 6와 다른 화면 구성을 할 것인가라는 고민이 추가된 것 뿐입니다. DPI를 외국 아이폰 포럼들에서는 Physical Pixel Per Inch 라고 하는 듯 하니 참고하시면 될 듯 합니다.
물론, 이 알고 보면 간단하다는 것에 대한 설명은 꽤 깁니다.
우선은 기존의 레티나와 아이폰 6, 그리고 아이폰 6+의 차이점을 알아야 합니다. 첫 아이폰부터 아이폰5s까지는 폰의 해상도만 업그레이드 되었습니다. 아이폰 5에서 폰의 세로가 커졌지만 딱 그만큼만 해상도가 높아졌기 때문에 아이폰5 역시 동일 선상에 있습니다. 그러니 좌표는 한 가지였고 이미지도 크게 만들어서 절반으로 줄이면 끝났습니다.
하지만 이번에는 폰이 커졌습니다. 그렇다면 해상도는 둘째 이야기가 됩니다. 왜냐면 폰 크기가 달라지면 해상도가 동일하든 정수배로 커지든 말든 화면에 보이는 정보량을 다르게 가져가는 것이 바람직하기 때문입니다. 따라서 이제는 크기가 다른 폰이 세 가지이므로, 세 가지의 DPI를 가지고 있다라고 생각해야 합니다.
현재 아이폰 6와 아이폰 6+의 해상도가 서로 다르고 아이폰 6는 변태 해상도, 아이폰 6+는 좌표값과 실 해상도가 맞지 않는 이슈가 있습니다. 사람들이 이해 할 수 없어 하는 건 첫 번째로는 동시에 두 기기를 내는건데 굳이 일부러 이렇게 어렵게 가느냐, 왜 아이폰 6는 HD도 아니고 750×1334냐 라는 것이고, 두 번째로는 아이폰 6+의 경우 해상도는 FHD인 1080×1920인데 실 작업을 왜 1242×2208로 해야 하는가 입니다. 개발툴을 보면 좌표값을 1242×2208의 1/3인 414×736로 사용하게 되어 있고, 스크린샷등도 모두 1242×2208 사이즈로 업로드하게 되어 있거든요.
그런데 사실 간단합니다. 오히려 두 번째의 의문이 없었다면 더 어려웠겠지만요.
먼저 아이폰 6가 변태 해상도인 이유는 5와의 연계성입니다.
먼저, 만약 아이폰 6+의 FHD 해상도를 단순하게 1/3으로 나누어서 좌표값을 360×640으로 작업을 하고 아이폰 6가 HD로 나왔다면 작업이 편했을 겁니다. 아이폰 6는 두배 이미지, 6+는 3배 이미지를 쓰면 되니까요. 하지만 그러기에는 6+ 의 화면이 너무 큽니다. 물리적인 화면의 사이즈가 너무 크기 때문에 이미지나 텍스트들이 너무 크게 보일 것입니다.
애플은 아이폰6와 아이폰6+에서 아이폰 시리즈로는 처음으로 DPI를 조정해야 할 일이 생겼습니다. 처음으로 폰의 화면 크기가 커졌으니까요. 기존처럼 밀집도만 올려서 더 선명하게 보이는 개념이 아니라, 실제적으로 물리적인 화면 크기에 따른 정보량을 달리 해야 할 필요가 생긴겁니다. 구현 방법에는 여러 가지가 있겟지만 애플은 좌표값을 변경하여 작업하는 방향을 사용하고 있습니다. 물론 이것이 처음은 아닙니다. 아이패드가 이미 선례지요. 다만 여기에 추가 된건 아이폰6+의 경우 이미지 사이즈를 실제보다 크게 잡는다는 부분입니다.
아이폰6+는 해상도가 1080×1920 이지만 좌표를 413×736 을 사용하고 실제 이미지는 x3인 1242×2208을 사용합니다. 그리고 폰은 그것을 자동으로 1080×1920의 해상도에서 보여지도록 합니다.
무슨 말이냐 하면, 디자이너는 1242×2208로 디자인을 합니다. 단 화면 구성은 아이폰 6를 기준으로 합니다. 즉 1242×2208 픽셀로 작업을 하지만 화면 크기는 4.7인치로 작업한다는 거지요. 4.7인치의 폰에서 클릭하기 쉬운 크기의 아이콘, 읽기 쉬운 크기의 글자를 사용한다는 의미입니다. 그렇게 작업한 결과물을 1242×2208 과 750×1334 두 가지로 저장합니다. 그러면 우선 아이폰6에서는 당연히 750×1334가 정상적으로 잘 보이겠고, 다만 5.5인치 크기의 아이폰6+에서는 약간 크게 보여야 하지 않을까 싶지만, 아이폰6+는 자동으로 1080×1920으로 크기를 줄여서 뿌리기 때문에 실제보다 모든게 작게 보입니다. 따라서 아이폰6와 아이폰6+는 클릭과 가독성에 있어 차이가 없어지게 됩니다.
아이폰 6+의 DPI를 이해하고 나면 아이폰 6의 번태 해상도를 이해하게 됩니다. 어차피 6+는 위에서 말한데로 전용 DPI를 쓰기 때문에 그와 동일한 좌표값을 아이폰 6에서 사용하는건 말이 안됩니다. 애초에 아이폰 6+ 자체가 다른 좌표값을 쓰겠다 라고 선언한 기기니까요. 그렇다면 아이폰 6의 좌표는 아이폰 5와 맞추느냐 아니냐를 선택해야 합니다. 아이폰 5의 해상도는 640×1136 이고 좌표는 320×568 입니다. 두 배 크기의 이미지를 사용하지요. 만약 세 배 크기를 하게 된다면 960×1804 가 됩니다. 960×1804 로 아이폰 6을 만들었다면 물론 작업은 편했을겁니다. 그러나 아이폰 6+와 동일한 이슈가 있지요. 폰은 큰데 정보량이 동일합니다. 물론 폰이 아주 큰 건 아니기 때문에 그러려니 할 수도 있겠습니다만, 아이패드 미니와 아이패드 에어 역시 아이폰과 크게 차이 나지 않는 크기의 아이콘과 텍스트를 사용하는 것을 보건데 애플은 전부터 DPI 기준을 가지고 있고 그것을 착실하게 유지하고 있다는 것을 알 수 있습니다.
* 내용을 수정/추가하였습니다: 아이폰5와 6의 관계를 보면, 5보다 6은 화면이 커졌습니다. 5보다 6은 해상도가 높아졌습니다. 어느만큼 커지고 어느만큼 높아졌냐면, 딱 커진만큼 높아졌습니다. 무슨 말이냐 하면, 3.5인치에서 4인치로 세로만 커진 아이폰5 처럼, 5에서 6은 세로/가로가 딱 해상도만큼 커진겁니다. 그래서 같은 @2x 이미지를 사용하죠. 같은 해상도의 icon을 사용하면 둘은 크기가 같게 나옵니다. 좌표만 다른거죠.
이제 실 작업을 살펴보면… 먼저 디자이너는 풀사이즈(1242×2208)로 작업을 합니다. 다만 화면의 아이콘이나 글자는 아이폰 6의 4.7인치 화면 크기를 기준으로 클릭과 가독이 쉬운 사이즈로 작업합니다. 즉 1242×2208에서는 다소 크게 보이는 형태로 작업하는거죠. 그 상태에서 필요하다면 아이폰 6+ 전용 UI를 추가해도 됩니다.그리고 작업 결과물을 각각의 이미지로 리사이즈해서 내보내면 됩니다. 즉 2208 하나, 1334 하나, 1136 하나입니다. (2015.03.08 글에 오류가 있어서 1500을 1334로 변경했습니다. 댓글 감사합니다.)
여기에서 1242×2208을 750×1334로 리사이즈시 정배율 문제를 떠나서 정확히 픽셀과 비율로 나눠지지 않는다는 부분은 있습니다. 하지만 결과적으로 보면 몇픽셀 차이가 안나서 무시하면 됩니다. 만약에 풀이미지라면 포토샵에서는 세로 기준(2208->1334)으로 리사이즈하면 맞습니다. 그리고 아이폰 5의 640×1136을 보면 가로 기준(2208->640)으로 리사이즈하면 세로가 1138이 되어 2픽셀이 남게 되고, 세로 기준(2208->1136)으로 리사이즈하면 가로가 1픽셀 부족하게 되는데요. 이 때에는 어느 쪽으로 리사이즈 했든간에 개발자가 원본이미지를 가운데 정렬로 사용하면 좌/우 또는 상/하가 아주 미세하게 비는 수준이기 때문에 티가 안납니다. 물론 풀이미지가 아니라면 1~2픽셀은 어딘가의 여백으로 쓰면 그만입니다. 개발자가 알아서 해도 아무런 티가 나지 않습니다. (물론 위의 여백 픽셀이 정확하지는 않을 수 있습니다. status bar 등의 기본 UI픽셀을 제거 후 리사이즈할 수도 있으니까요. 하지만 어쨌든 별 차이가 안 날 겁니다. 그리고 비트맵 이미지라 하더라도 아주 작은 텍스트들이 있는게 아니고 그냥 그림 같은 이미지라면 비율무시하고 사용해도 티가 안날겁니다.)
안드로이드와 아이폰을 동시에 만든다고 해도 이 역시 1242×2208 로 작업하면 됩니다. 4.7 ~ 5인치 정도의 화면 사이즈를 기준으로 잡아서 작업하면 됩니다.
물론 개발은 좌표에 맞게 레이아웃이 자동으로 짜지도록 작업하면 됩니다. 다만 글자가 포함된 비트맵 풀이미지의 경우 화면비율이 정확히 맞지 않는 걸 억지로 늘리기 보다는 어차피 1-2픽셀 티안나는거 여백을 두고 원본을 보여주는 것도 좋겠습니다만 로딩이미지에서 좌/우가 살짝 비었던게 로딩 후 다른 이미지로 채워진다면 어색할 수도 있습니다. 따라서 기본적으로는 풀로 채우고 퀄리티에 문제가 있다면 그 때 디자이너와 상의해서 이미지를 보정하든 화면사이즈를 보정하든 하면 될 것 같습니다. 어차피 풀 이미지일때의 이야기라 보정도 간단하겠지요.
알고보면 간단하다는 여기서 끝.
추가로 특별히 엄청난 퀄리티로 만들 것이 아니라면 QHD 해상도는 신경 쓰지 않아도 됩니다. 지금 5.5인치의 FHD 폰을 쓰면서 아 해상도가 낮아서 뿌옇게 보이네 라고 생각한다면 QHD를 신경써야 겠지만 그게 아니니까요. 물론 미세하게 좋기야 하겠지만 노력대비 결과가 티가 안나고 이미지 사이즈 때문에 오히려 퍼포먼스가 더 나빠질 수 있다는 점도 감안해야 합니다.
여담으로 정말 개인적인 생각입니다만 5.9인치 FHD폰을 쓰면서 5.3인치에서 FHD보다는 뭔가 아쉬움이 있습니다. 레티나 아이패드에서도 약간 느껴지는데요. 아마도 FHD는 5.5이하가 한계인 것 같습니다. 10인치에서는 QHD정도가 완벽한 것 같고요. 6~9인치는 그 중간이 되겠죠. 평소에 이리 생각해왔는데 5.5의 이미지 크기가 1242×2208여서 약간 놀랐습니다. 물론 해상도는 FHD이긴 하지만요. FHD와 QHD의 중간 해상도가 5.5~6에서 최상이라고 생각했거든요. 더 낮은건 약간 아쉽고 더 높은건 티가 안나니까요. 물론 1242×2208 같은 중간 해상도의 기기가 나올 일은 영원히 없겠지요.
![[윈도우 태블릿] Asus 비보탭 노트8 (Vivotab note8) 간단 후기](http://i1.wp.com/www.bluejini.net/wp-content/uploads/2014/03/11.jpg?resize=350%2C200)
[잡솔] 아이폰6, 아이폰6+의 해상도 2편 (디자이너의 작업)
1편은 http://www.bluejini.net/?p=634 에서 확인하실 수 있습니다.
2편을 작성하게 된 이유는 몇 가지 있습니다.
일단 글이 너무 난잡했습니다. 포커스도 없었고요. 짧게 써질 줄 알았는데 점점 같은 얘기를 다른 버전으로 반복 하게 되면서 (응?) 글이 쓸데 없이 길어졌고 오류도 여기저기 있습니다. 이 부분은 죄송합니다. 댓글이 달릴 때마다 조금씩 수정해왔으나 수정에도 한계가 있네요.
또한 지난 글에 정말 드문드문이지만 댓글들이 지속적으로 달렸습니다. 제 블로그에 앵간하면 댓글이 없기 때문에 제가 댓글 확인을 거의 안하거든요. 이런 블로그에, 네이버에 나오지도 않는 이 글에, 달릴지 안달릴지 모를 대댓글을 기다리며 질문 글을 올리신 분들께 일종의 책임감을 느끼게 되었습니다.
그리하여, 여전히 구어체 설명이기는 하겠으나 1편보다는 더 간략하고 실무에 맞춘 디자이너를 위한 글을 결심하게 되었습니다. 실제로 어떻게 작업해야 할지 아직도 막막한 디자이너분들에게 도움이 되었으면 좋겠습니다. 물론 디자이너가 아니어도 참고 용도는 되실 것 같습니다. 저도 디자이너는 아닙니다.
1. 세 가지 해상도의 이유.
먼저 세 해상도가 어떻게 돌아가는지 정확히 짚고 넘어가려 합니다. 아시다시피 아이폰은 대표적으로 세 가지 해상도의 이미지를 사용합니다.
- 1x – 3이하 (국내에서는 3gs)
- 2x – 4~6
- 3x – 6+
기존 글을 보신 분들은 왜 해상도가 다 제각각인지 대략 이해 하셨으리라 봅니다. 하지만 여전히 풀리지 않는 의문이 있습니다.
물리적으로 화면이 커져서 PPI가 달라졌고 따라서 좌표를 다르게 쓰는 것은 이해 하겠다. 그런데 아이폰4, 아이폰5, 아이폰6 은 어째서 같은 해상도의 2x 이미지를 사용하는가?
한마디로 답변 하자면 PPI 가 같기 때문입니다.
DPI는 Dot Per Inch로 화면의 크기(e.g. 1인치)에 보이는 도트의 개수를 의미합니다. dot 자체의 크기가 같다는 전제 하에, 1인치에 보이는 도트의 크기가 같다면, 해상도가 몇이고 화면 크기가 몇이고 간에 DPI 는 같은 겁니다. DPI 가 같으면 눈으로 보았을 때의 크기가 동일합니다. DPI 는 과거에 인쇄용으로 썼었던 용어로, 화면에서는 주 단위가 pixel 이어서 애플에서는 PPI 라고 합니다. pixel per inch.
중요한 부분은 눈으로 보았을 때 라는 부분입니다. 예를들면 아래와 같습니다.
가로 1인치와 2인치의 폰이 있습니다. 단순 계산으로 1인치 폰은 가로 해상도가 100이고, 2인치 폰은 가로 해상도가 200입니다. 이 때 가로 100px의 이미지를 넣습니다. 어떻게 보일까요? 1인치 폰에서는 꽉차고, 2인치 폰에서는 절반만 찹니다. 그럼 그 둘은 사람 눈으로 보기에는 동일한 크기로 보입니다. 이것이 PPI 개념입니다.
서로 다른 화면 크기와 해상도이지만, 특정한 조합에서는 서로 같은 PPI가 되고 그러면 눈으로 보이는 크기가 동일해 집니다. 물론 여백은 다를 수 있습니다. 화면의 크기가 다르니까요.
반대의 예제는 이렇습니다. 3GS -> 4에서 화면 크기는 같은데 해상도가 두 배 되었습니다. 레티나 디스플레이라고 부릅니다. 이건 PPI 도 두배가 된거죠. 정확히 두배가 되었습니다. 따라서 화면 크기는 같은데 가로 320px 의 이미지를 보면 3GS에서는 꽉차서 보이고 4에서는 절반만하게 보입니다. 즉 눈에 보이는 크기도 두 배 차이 납니다.
그래 PPI 가 같구나! 하지만 아직 감이 잘 오지 않을 수도 있습니다. 차근차근 설명해 보겠습니다.
2x를 사용하는 세 폰의 해상도를 보면 아래와 같습니다.
- 아이폰4 – 3.5인치 (2:3비율) 640×960
- 아이폰5 – 4인치 (9:16) 640×1136
- 아이폰6 – 4.7인치 (9:16) 750×1334
먼저 아이폰4에서 5로 3.5인치에서 4인치로 커졌을때, 거의 정확히 세로의 길이만 커졌던 것을 떠올려 봐야 합니다. (비율의 차이 때문에 크기가 커졌지만 가로는 동일) 그리고 해상도 역시 세로만 커졌습니다. 그 결과 가로 좌표는 변경이 없었고 작업하는 버튼들의 해상도 변경도 없었습니다. PPI는 물론 동일합니다. 100×100 픽셀의 이미지가 두 폰에서 정확히 같은 크기로 보이기 때문입니다. 따라서 이미지 작업은 풀 사이즈 이미지인 경우에만 세로를 늘린 이미지를 제작하면 되었고, 개발자는 세로가 늘어난만큼의 보정만 해주면 됐습니다.
아이폰6도 그 연장선에 있습니다. 4인치에서 4.7인치로 물리적인 화면이 커진 만큼, 딱 그만큼의 해상도가 높아졌습니다.물론 좌표는 수정해야겠죠. 하지만 이미지는 동일한 이미지를 사용하면 됩니다. 100×100 픽셀의 이미지는 결국 세 가지 폰에서 다 동일한 크기로 보여집니다. 그리고 나면 결국 화면이 넓으냐 좁으냐, 즉 더 많은 정보를 보여줄 수 있느냐만 다르게 됩니다. 한마디로 동일 이미지로 좌표만 다르게 쓴다는 이야기입니다. 따라서 세 폰은 동일한 2x 이미지를 사용합니다. 물론 가로가 꽉 찬 이미지의 가로 픽셀은 5와 6이 다릅니다. 풀 사이즈 이미지에는 커스터마이징이 필요합니다.
결론은 무엇인가?
고민할 필요가 없다는 겁니다. 그냥 알아서 잘 보이니 6의 해상도에서 작업하면 됩니다.
단, 두 가지는 염두 해 두어야 합니다.
첫째, 가이드는 필요합니다. 6용으로 작업한걸 5에서도 잘 보이게 한다면 버튼의 위치가 달라져야 합니다. 예를들어 상단에 뒤로가기(맨좌측)버튼, 타이틀, OK(맨우측)버튼이 있다면, 뒤로가기는 좌측정렬, 타이틀은 중앙정렬, OK버튼은 우측정렬이어야 모든 폰에서 정상적으로 보이겠죠? 세 폰의 차이는 가로bar의 길이, 타이틀의 글자 수가 됩니다.
둘째, 풀 사이즈 또는 그에 준하는(가로가 꽉 찬) 이미지는 별도의 작업이 필요합니다. 6에서 픽셀만큼 폰이 커졌기 때문에 5로 픽셀과 크기를 줄인다면 배너 역시 그 크기가 줄어들어야 정확하게 맞아 떨어집니다. 물론 반드시 정확하게 맞게 할 필요는 없습니다. 6의 파일을 5에서 리사이즈하여 읽었을 때 글자의 크기는 조금 줄어들겠지만 알아 볼 수 있다면 그것도 나쁘지 않죠.
결국 작업 아래의 세 가지 중에서 선택 하면 됩니다.
- 첫번째, 6용 이미지를 그냥 써버리는 겁니다. 물론 5에서는 cpu부하가 좀 있겠고(이미지가 성능에 비해 크고 추가로 리사이즈까지 해야 하므로) 4에서는 이미지가 정확하게 꽉차서 보이지 않겠죠. 이 때 이미지 안에 텍스트가 포함되어 있다면 그 텍스트는 약간 크게 해줘야 5나 4에서도 읽을 수 있겠죠.
- 두번째, 당연히 5나 4용 이미지를 추가 제작하고, 개발자가 코드로 각기 부여하는 겁니다. 예를들면 intro4 intro5 intro6 이미지를 각기 2x확장자로 저장하여 개발자가 4/5/6일 경우 각기 사용한다…로 해놓는거죠. 개별 배너 까지 적용한다면 완벽한 대응이 될겁니다만, 이벤트 하나 열 때 만들어야 하는 배너의 양도 무시 못 할 겁니다.
- 세번째, 타협하는 방법입니다. 귀찮으니까 5는 6용 쓰고 4만 따로 만들거나, 6은 따로 쓰고 5,4는 같이 쓰는거죠. 후자가 좋아 보입니다. 5,4를 쓰는 유저들은 적고 앞으로도 점점 줄어들테니까요.
이 정도면 세 가지의 해상도와 작업 방법에 대한 의문이 풀렸으리라 봅니다.
한 번 더 정리하면…
- 아이폰4와 5에 대응한다고 하여 6의 이미지들을 죄다 작게 리사이즈 하는 것이 아니다. PPI가 동일하기 때문이다.
- 2x 이미지는 하나만 만들고 기획자/디자이너가 의도한대로 가이드를 넘기면 개발자가 오토 레이아웃으로 배치 시 (또는 수동으로 배치 시) 이미지들은 알아서 제대로 보인다. 애초에 그렇게 보이라고 만들어졌다.
- 다만 풀 사이즈 또는 그에 준하는 큰 이미지들은 추가 작업이 필요할 수 있다. 이 부분은 리더와 상의하여 결정하고 추가 작업 시 파일명의 규칙은 개발자에게 받는다.
2. 그래서 어떤 사이즈로 디자인 하라는건가요?
위에서 말 한 건 아이폰 4/5/6의 해상도였죠. 그래서 실제로 작업 해야 하는 사이즈는 무엇일까요?
국내 작업 기준은 대부분 안드로이드이며 그 해상도는 FHD 입니다. 따라서 대부분의 경우 FHD 가 기준이 됩니다. 특별한 이슈가 아니라면 더 높은 해상도로 작업할 일은 없습니다. 그 이상의 해상도를 6인치 이하의 폰에서 구별하는 것은 무의미 하거든요. 구별이 안되는 건 아닙니다. 다만 구별 되는 건 눈꼽만큼인데 괜히 데이터만 더 쓰고 속도만 더 느려질 뿐이죠.
- 기준 폰이 무엇인지 알아야 합니다. 요새는 FHD 이상의 폰이죠. 갤럭시 s4와 노트3은 FHD이고 s5이상/노트4 이상은 QHD (2560) 입니다. 아이폰은 물론 6 입니다.
- 최소 지원 폰이 무엇인지 알아야 합니다. 갤럭시 s2인지 s3 인지, 아이폰 4인지 5인지 말이죠. (안드로이드는 큰 상관 없습니다. OS 버전 때문에라도 최소 지원 폰이 HD 이상이기 때문에 HD 폰이 최소 지원이라면 FHD에서 이미지를 비율에 맞게 HD로 리사이즈 해주면 끝입니다.)
기준 폰이 FHD 라면 망설일 것 없이 FHD 로 디자인 하면 됩니다. 하지만 확인은 받아야 겠죠. FHD 로 디자인 하면 되죠?
물론 기준 폰이 QHD 라면 한 번 정확히 확인 할 필요가 있습니다. FHD 로 디자인 하면 되느냐고 컨펌을 받으세요. 만약 QHD 로 디자인하게 된다 해도 달라지는 것은 없습니다. 안드로이드는 비율에 맞춰서 리사이즈 해주면 끝납니다.
어느 사이즈든지 디자인을 하고 나면 폰으로 옮겨서 보세요. 적당한가요? 이제 아이폰6 해상도로 리사이즈 후 저장하세요. 그러면 이미 6/5 에 대하여 대응 한 것이며, 6+도 깨지지 않고 보입니다. 중간에 안드로이드를 위하여 FHD 로 저장한 파일은 아이폰 6+ 에 사용하세요. 추가로 풀 사이즈 이미지 또는 가로 또는 세로가 꽉 차는 배너의 경우는 아이폰 5와 4(최소 지원 폰이 4라면 4까지 해야겠죠)의 해상도를 추가 지원 시 각 폰에게 더 높은 완성도의 이미지를 보여줄 수 있습니다.
FHD 로 작업을 마쳤으나 개발자의 요청에 의하여 특정 파일은 아이폰6+ 때문에 2208사이즈로 결과물을 내야 하는 경우도 있습니다. (스크린 샷 같은 경우) 이 때에는 그냥 이미지를 확대 해서 저장하세요. 1920을 2208로 확대하여 이미지가 약간 어벙하게 보인다 한들, 실제 폰에서는 다시 1920로 줄이게 되고 또한 폰의 화면 크기가 작기 때문에 아무런 문제 없이 깨끗하게 보입니다.
위와 같이 작업 시, 6/5/4 의 대응은 완벽합니다. 물론 6+까지 완벽하게 대응 한 것은 아니지요. 허나 6+ 에서 이상하게 보이는 것도 아닙니다. 단지 모든 UI 가 폰의 크기만큼 약간 크게 보일 뿐이지요.
그런데 만약 아이폰 전용 프로젝트를 하고 있고 리더가 6+에 대응을 정확히 하기를 원한다면, 즉 리더가 6와 6+의 차이를 정확히 이해 하고 있고 그에 상응하는 작업을 요구 할 때에는 처음부터 2208 사이즈로 작업해야 합니다. 국내의 SI에서는 잘 없는 경우지만 아이폰 용 앱을 제대로 만들어야하는 프로젝트에서는 필요할 수 있습니다.
이 때 작업에 앞서, 당연하지만 한 가지는 확실히 해야 합니다. 6+를 완벽하게 대응 하는 것은 꽤 수고스러운 일입니다. 6/5/4 에 대응 하는 것 보다 전 단계에서 더 큰 이미지로의 작업이 필요하기 때문입니다. 즉 6+보다 6이 더 많이 사용되는 폰이고 6에만 대응해도 6+에서 이상하게 보이지는 않으며, 6+로 작업 시 작업량이 늘어난다는 것을 미리 공유할 필요가 있습니다.
이제 실제로 6+로 작업을 해 보겠습니다.
지난 글에서는 2208로 작업 후 리사이즈한다고 써 놓았습니다. 맞는 말입니다. 하지만 중간 과정을 통으로 생략해서 100% 맞는 말은 아니었습니다. 또한 무조건 2208로 작업해야 하는 것도 아닙니다. 선택일 뿐입니다.
자세하게 설명해 보겠습니다.
6+에 제대로 대응을 한다고 했을 때, 하나의 icon이 있을 때 6와 6+를 비교하면 이렇습니다.
- 화면의 물리적인 크기는 6+이 크다.
- 눈에 보이는 icon의 크기는 같다. (하지만 4,5,6 처럼 PPI가 일치하지는 않습니다. 그 이유는 이이폰6+은 2208로 작업된 디자인을 1920으로 다운샘플링 한 후 보여주는데 그제서야 icon의 크기가 비슷해지기 때문입니다. 또한 1920으로 리사이즈 한다고 완전히 같아지는 것도 아닙니다. 정확한 사이즈는 따로 있고 아래에서 설명합니다)
- 따라서 6+에서는 6와 동일한 해상도의 icon을 배치 시 화면에 여백이 더 남는다. (5와 6의 차이와 동일한 원리.)
그렇다면 어떻게 디자인 해야 할까요? 1x 사이즈로 계산을 해보면 쉽습니다.
- 아이폰6 은 375×667
- 아이폰6+ 은 414×736
아이폰6+이 화면이 크죠. 이제 작업을 상상해 봅니다. icon 크기를 375×667 내에서 아이폰6에 담아서 정상적으로 보이도록 작업합니다. 그리고 이미지 사이즈가 아니라, 바탕인 캔버스 사이즈를 414×736 으로 바꿉니다. 그러면 빈 여백이 생기죠. 그만큼에 더 많은 UI를 담으면 6+ 대응이 됩니다. (물론 반드시 많은 걸 새로 그려서 담아야만 하는 건 아니죠? 단지 여백이 많아질 수도 있습니다. 많은 앱들이 더 많아진 여백을 단지 더 많은 텍스트를 담는 용도로 사용 중에 있습니다.)
하지만 1x는 작업 사이즈가 너무 작습니다. 벡터로 이미지 제작 후 늘리는 것도 방법이겠지만 모든 사람이 그렇게 작업하지는 않을 것입니다. 작은 사이즈에서 늘린다 하더라도 최종적인 사이즈는 알아야 합니다. 어쨌든 PC사양만 된다면 큰 이미지에서 작업 후 리사이즈하면서 처리 하는게 더 간편하죠.
그럼 두 배로 각각 올려 봅니다. 아이폰6 은 750×1334 고 아이폰6+은 828×1472 입니다. 미묘하죠.
마지막으로 세배로 늘려볼까요? 아이폰6은 1025×2001, 아이폰6+은 1242×2208 이 됩니다. 감이 오시나요? 1025×2001의 작업물을 아이폰6에 담아서 제대로 보인다면 그걸 2/3으로 줄이면 (당연하지만) 아이폰6 해상도이고 정상적으로 보일 것입니다. 그렇다면 1025×2001 에서 캔버스를 늘려서 1242×2208 을 만들고 그 여백만큼 추가 작업을 하면 어떨까요. 정확하게 아이폰6+ 해상도를 대응하게 됩니다.
즉 크게 작업할 수 있는 사이즈는 6 기준으로는 1025×2001 입니다. 이제 작업 방법은 본인 취향대로 결정 하기만 하면 됩니다.
먼저 1024×2001로 작업하는 방법입니다.
- 1024×2001로 작업한다.
- 풀 사이즈(또는 그에 준하는 사이즈)의 이미지는 1024×2001외에 1242×2208로도 작업한다.
- 1024×2001로 작업이 완료되면 컨버스를 1242×2208로 늘린다. 여백을 가지고 추가 기능을 넣거나 가이드 작업을 한다.
작업은 명료합니다. 다만 단점도 명확합니다. 1242×2208로 늘렸을 때 얼마만큼의 여백이 남는지 미리 확인할 수가 없습니다. 계획적으로 기획/디자인 할 수가 없죠.
그렇다면 1242×2208로 작업하는 방법입니다. (굳이 제가 적지 않아도 디자이너 분들이 더 잘하시겠지만 혹시나마)
- 1242×2208로 작업한다.
- 풀 사이즈 이미지는 컨버스에 꽉차게 그리고 1024×2001로도 재작업한다.
- 디자인 파일 내에 가이드로 1024×2001를 쳐 보면 여백이 미리 확인 가능하므로 그 여백에서 무엇을 할 수 있는지 고민한다.
이렇게 된다면 좋겠죠. 물론 1242×2208로 작업한 이미지는 6+에서 확인했을 때 정상적으로 보여야 합니다. 6에서 확인하면 안됩니다. 그럼 너무 작게 보여요. 6에서 확인하기 위해서는 가이드로 쳐 놓은 1024×2001로 커팅(크롭) 후 확인해야 합니다. 실제 저장시에는 1334로 리사이즈 하겠지만 확인 용도에서는 리사이즈가 필요 없죠. 알아서 해주니.
그리고 2번 작업 시 재작업으로 써 놓은 이유는 아시겠지만 2208로 작업 후 2001로 바로 줄이면 만약 이미지에 글자가 포함되어 있다면 글자크기도 함께 줄어들겠죠. 이를 방지하기 위해서는 글자는 그대로 두고 다른 이미지만 줄여야 합니다. (먼저번의 방식은 글자는 키우지 않고 다른 이미지만 키워야겠죠.) 물론 풀 이미지에서 글자 크기를 해상도에 정확하게 대응 하는 건 꽤 세심한 디자인일겁니다. 처음부터 글자를 조금 키워서 작업하면 바로 리사이즈 해도 무방하겠죠.
이 정도면 사이즈 작업에 대한 답은 된 것 같습니다.
단지 마지막으로 하나만 더 추가하면, SI 프로젝트를 하면 위의 사이즈 같은 건 별 의미 없을 때가 많습니다. 그냥 1920으로 하고요. 개발자가 알아서 하고요. 오오. 그런데 반대로 쓸데 없는 사이즈도 다 달라고 할 때도 있습니다. 어쨌든 사실을 알고 있다면, 로직을 정확하게 파악하고 있다면, 개발자와 협의 후 더 합리적이고 좋은 방법을 사용할 수 있을 겁니다. PM 말이라고 다 들으면 안돼요. PM이라고 다 아나~?
3. 가이드 작업을 해달라던데…?
어플리케이션 제작 시 디자인 작업은 파일을 쪼개서 건네 주는 것으로 끝나지 않습니다. 가이드 작업이 남아 있습니다. 개발자나 PM이 말합니다.
가이드 작업을 해 주세요.
네?
마지막 챕터입니다. 가이드 작업. 가이드 작업에 있어 주요한 팁!은 제가 모릅니다. 제가 디자이너가 아니거든요. 따라서 이 챕터는 디자인 가이드 작업이 무엇인지에 대한 설명입니다.
가이드 작업은 어플리케이션에 디자인을 입힐 때 필요합니다. 정확히 어느 위치에 이미지를 놓고 그 이미지는 화면의 크기/이동에 따라서 커지는지 제자리인지 중앙 정렬인지 등등을 표기 해놔야 하지요. 모바일 앱도 윈도우 어플리케이션도 모두 마찬가지 입니다.
물론 가이드 없이 슝슝 잘 돌아가는 앱도 흔합니다. 보통 여기서 하이브리드 앱이냐 네이티브 앱이냐를 구분해서 말하기도 합니다만, 정확히는 화면 별로 해당 화면이 네이티브로 구현되는가 웹뷰로 구현되는가를 확인해야 합니다. 또한 웹뷰라 하더라도 특정 영역은 네이티브인지를 확인해야 합니다. 저는 하이브리드 앱 또는 네이티브 앱이라는 용어의 정의가 상당히 애매하여 혼란만 부추키는, 결과적으로 전혀 의미가 없고 오히려 없어져야 할 말이라고 생각합니다. 작업하시는 분들은 다들 비슷하리라 생각합니다. 네이티브 앱도 필요한 화면에는 웹뷰를 쓰고 인터넷에서 HTML을 가져옵니다. 그럼 하이브리드 앱인가요?
앱은 화면으로 이루어져 있습니다. 그리고 그 화면은 기본적으로는 네이티브로 구성 되어 있습니다. 네이티브라는 말은 쉽게 말해서 앱의 고유 언어로 구현한다는 이야기 입니다. 하지만 특정 화면은 웹뷰를 불러서 사용할 수 있습니다. (물론 모든 화면을 웹뷰로도 할 수 있습니다.) 웹뷰는 이름만 들어도 딱 알겠듯이 HTML 을 이용합니다.
즉 앱이 자신의 고유 언어로 웹뷰를 불러오면 그 웹뷰 화면은 고유 언어 대신에 HTML 을 읽어서 화면에 뿌려줍니다. (HTML도 하나의 언어니까요) 고로 모든 화면이 웹뷰라면? 개발자는 웹뷰를 불러오는 코드만 간단히 넣으면 되고, 퍼블리셔는 HTML 코딩한 파일을 넘겨주면 끝입니다. HTML 파일이 서버에 있던 폰 로컬에 있던 상관 없지요.
하지만 네이티브로 구현되는 영역은 본연의 언어를 사용합니다. 아이폰은 과거에는 objective-c를 이용했었고 지금은 swift라는 언어도 함께 사용하죠. 이게 뭘까요. 개발자가 아니라면 깊게 알 필요는 없습니다. 화면에 이미지를 하나 보인다 할때 HTML에서는 <IMG> 쓰고 css에서 위치 잡아주듯, 각 언어들은 자신만의 다른 방식이 있습니다.
그리고 네이티브에서 이미지만 보자면, 개발자가 수동으로 타이핑해서 넣든 툴을 쓰든 어쨌든 이미지는 특정 좌표에 넣습니다. 물론 그 좌표는 x,y 축의 절대 좌표일 수도 있고 최상위의 가운데라던가 하는 식의 정렬에 의거한 위치일 수도 있으며 두 가지가 혼합되어 있을 수도 있습니다.
다 몰라도 상관 없습니다. 결론은 어쨌든 퍼블리셔가 아니라 개발자가 화면에 이미지를 넣는 작업을 한다는 거지요.
먼저 퍼블리셔를 생각해 보겠습니다. 퍼블리셔는 디자인 파일을 화면에 표시 할 때 어떤 방법으로 디자인 한 그대로 – 1픽셀의 오차 없이 – 표시하나요? 퍼블리셔는 포토샵에서 슬라이스 툴로 이미지를 쪼개면서 생각합니다. 이건 이미지를 작게 쪼개는 대신에 padding을 20주면 되겠구나, 저건 귀찮으니까 통 이미지 써버리자… 라고요. 그리고 자신이 생각한 데로 코딩을 합니다. 당연히 오차가 생길 수 없죠.
이제 개발자를 살펴보면, 개발자가 포토샵으로 이미지를 잘라서 화면에 넣을까요? 아니지요. 개발자는 못 합니다. 물론 할 줄 아는 개발자도 있습니다. 개발 할 줄 아는 기획자, 디자인 할 줄 아는 퍼블리셔입니다. 1인 다역할의 매일 밤새는 작은 규모의 벤처 회사가 아니라면 업무가 아니죠. 효율이나 퀄리티에 문제가 생길 수 밖에 없습니다. 당연한 이야기로, 개발자가 아무리 포토샵을 잘 다룬다 한들 그 시간에 개발을 해야 개발이 빨리 되니까요. 결국 개발자는 이미지를 어떻게 쪼개야 하는지 모릅니다. 그렇다면? 당연히 디자이너가 쪼개서 주겠지요. 이제 문제가 생깁니다. 개발자는 padding을 20을 줘야 하는지 30을 줘야 하는지 모른다는 거죠. 잘라진 이미지의 크기와 전체 디자인 시안의 픽셀을 직접 비교 하기 전까지는 알 수가 없기 때문입니다. 물론 개발자는 포토샵을 다루지 않으므로 알 수가 없습니다. 결국 디자이너의 디자인 가이드가 필요합니다. 여기 여백이 20px 이네요. 라고 말이죠.
물론 웹뷰를 사용하는 화면은 가이드가 없어도 됩니다. 왜냐면 웹뷰에 쓰이는 이미지는 디자이너가 통으로 전달하면 퍼블리셔가 알아서 쪼개고 직접 HTML을 입히기 때문입니다. 물론 기획서 단계에서는 최소한의 가이드가 필요한 경우가 있습니다. 폰의 화면 넓이에 따라서 배치가 달라져야 하거나 크기가 달라져야 하는 경우는 가이드를 해줘야겠죠. 예를 들면 반응형 웹처럼 말이지요. 웹뷰 영역은 웹기획/디자인이나 마찬가지이므로 여기서 추가로 설명할 필요는 없을 것 같습니다.
아놔 그냥 웹뷰 쓰지? 네이티브가 성능이 더 좋고 할 수 있는게 많습니다. (간단)
그럼 이제 글로만 실제 가이드 작업을 설명해 보겠습니다.
하나의 디자인 파일을 보면 이미지들이 여러 개 들어가 있겠지요? 그렇게 사용된 모든 이미지&텍스트에 대한 설명을 써놓는 것이 가이드 입니다. 가이드 파일은 네이티브 화면마다, 또는 네이티브의 기능 마다 필요합니다. 네이티브로 화면이 20개가 있다면 20개의 가이드 파일이 필요합니다. (물론 동일한 UI 를 쓰는 화면들은 하나만 작업하면 되겠죠.) 작성 도중 정렬 등 UI가 애매한 부분이 있다면 기획자에게 컨펌을 받으면 됩니다.
또한 가이드는 6+/6/3 용이 다 다릅니다. 하지만 반드시 개별적으로 모든 가이드 파일이 필요한 것은 아닙니다. (또한 위에도 말했듯이 3GS용은 요새는 개발을 거의 하지 않습니다.) 왜 아니냐면 개발자가 오토 레이아웃을 이용하거나 또는 다른 방법이 무엇이 되었든 스스로 계산을 이미 하고 있다면 (어차피 6과 6+의 픽셀은 정해져 있으므로) 가이드는 한 벌만 있어도 충분하기 때문입니다. (이 경우 6+에서 UI가 적극적으로 변화한다면 그 부분만 별도로 가이드를 요구 할 것입니다.) 따라서 가이드를 칠 때에 6 하나면 되는지, 6+ 하나면 되는지, 정말로 둘 다 해줘야 하는지 먼저 확인 해 보는 것이 좋습니다.
또한 추가로 6/5/4의 가이드가 문제가 될 수 있는데 특별한 경우가 아니라면 6 하나로 가이드를 끝낼 수 있습니다. 물론 개발자와 내용을 먼저 공유해야 겠지요.
잠깐 다른 이야기를 해봅니다.
안드로이드는 왜 가이드를 FHD한 벌만 작성하나요?
안드로이드 개발자들은 기본적으로 HD, FHD, QHD 해상도를 지원하지만 디자인 가이드를 세 벌 요구하지 않습니다. 기본적으로는 개발 툴이 알아서 다 맞춰서 들어가도록 오토 레이아웃을 지원하며, 수동으로 한다고 하더라도 HD, FHD, QHD 의 계산이 이미 명확하게 정해져 있기 때문입니다.
다만 4:3 비율처럼 특이한 해상도의 화면에서는 예상대로 나오지 않는 경우가 있는데, 이 때에는 개발자가 직접 테스트 하여 수정하는 것이 일반적입니다. 사용자 수가 적은 폰을 위하여 가이드를 따로 치는 건 가이드를 치는 디자이너에게도, 가이드가 나온대로 정확하게 적용해야 하는 개발자에게도 비효율적인 일이니까요.
어떤 개발자는 퍼센트로 좌표를 사용하기도 합니다. 만약 [이미지A] <-2픽셀-> [이미지B] <-2픽셀-> [이미지C] 와 같이 이미지 세개가 2픽셀씩 띄워져 있다면 개발자는 예를들어 0.1% 씩 띄워져 있다 라고 입력하면 해상도에서든 동일하게 보여지겠죠. 이 때 좌표가 절대좌표로 적혀 있다면 개발자가 직접 뺄셈을 해서 상대 좌표를 구해야 하니 상대 좌표를 요구 하기도 합니다. (그런데 뺄셈이 어려운 걸까요?)
다시 가이드 파일 작성으로 돌아오겠습니다.
파일은 보통 PSD 에 작업합니다. 디자이너가 익숙한게 포토샵이기도 하지만, 디자인이 수정되면 – 정확히는 디자인 요소의 가로 크기 또는 세로 크기 또는 위치가 변경되면 – 가이드도 수정되기 때문입니다.
완성한 가이드는 JPG나 PNG로 저장하여 개발자에게 전달합니다.
가이드에서 주요한 설명은 크게 두 가지로, 위치와 정렬입니다.
- 뒤로가기 버튼은 back.png 로 좌에서 20px떨어져서 상단에서 20px떨어짐
- 타이틀은 텍스트로 상단에서 22px 떨어져서 기본 폰트로 20px크기로 가운데 정렬
- SUBMIT 버튼은 submit.png 로 우측에서20px떨어져서 상단에서 20px떨어짐
이미지와 텍스트에 대하여 위치와 정렬을 설명해 두었습니다. 물론 가이드 파일에서 좌에서 20px떨어졌다는 내용을 말로 쓰지는 않습니다. 먼저 슬라이스 툴로 이미지를 어떻게 자를지 정해 놓은 뒤 기준점(e.g. 좌측끝)으로부터 이미지가 잘라지는 부분까지 line 을 그어놓고 20px라고 해놓으면 좌로부터 20px이구나 하고 알아보겠죠.
SUBMIT 버튼을 눈여겨 봐야 합니다. 우측으로부터 20px 떨어졌다 라고 표시하면 당연히 우측을 정렬로 할 것입니다. 아이폰6에서 우측으로부터 20px떨어졌다고 치면 5/4도 모두 동일하게 적용하면 되겠죠. 이걸 좌측으로부터 좌표를 때리면 6/5/4의 좌표가 모두 달라집니다.
이렇게만 된다면 간단합니다.
하지만 실상은 조금 더, 때로는 머리 뽀개질 정도로 복잡합니다.
- 첫째로 어느 폰까지 지원하는지, 그리고 폰 마다 가이드를 쳐야 하는지, 즉 가이드 대상 폰을 정확하게 알아야 합니다. 4와 3GS 지원을 하는지? 정말로 6+/6/3GS 의 가이드를 따로 쳐야 하는지? 진심으로 진심으로 진짜 진심으로 6/5/4 도 분리해서 쳐야 하는지?
- 둘째로 네이티브 영역을 정확하게 파악해야 합니다. 어디가 네이티브 영역인지는 개발자나 기획자에게 물어봐야 하겠죠. 본문은 웹뷰인데 상단 top bar와 하단의 floating버튼은 네이티브 일 수 있습니다. 가이드는 네이티브 영역만 쳐주면 됩니다.
- 셋째로 화면 상에 표시되는 모든 요소(이미지/텍스트)에 대하여 정확하게 짚어줘야 합니다. 희끄무리한 라인 하나까지도 정확하게 위치를 잡아줘야 하고 물론 그 위치는 기준점(상하/좌우 정렬)을 포함해야 겠죠. 또한 폰트는 특정 폰트를 global 하게 쓴다면 폰트 이름을 한 번만 언급하면 되겠지만 크기는 각기 다 정해주어야 합니다. 마지막으로 네이티브와 웹뷰가 섞여 있고 시스템 폰트가 아니라 웹폰트를 쓴다면 둘 다 동일한 폰트로 정확하게 의도한대로 보이는지도 개발자에게 확인 해야 합니다. 은근히 잘 안되는 부분이더군요.
- 넷째로 화면 너비나 높이에 맞추어 늘어나는 이미지는 정확히 어떻게 늘어나는지 알려줘야 합니다. 웹에서 이미 흔하게 하던 일이긴 합니다. 본문이 있을 때 텍스트의 세로 길이에 따라 본문 배경이 세로로 넓어지는 것들 말이죠.
- 다섯째로 단말기에 대응해야 합니다. 우상단에 위치한 SUBMIT 버튼을 6+ 기준으로 세로20px 띄우고 우측으로부터 20px 띄웠다고 생각해보세요. 그럼 6에서는 얼만큼 띄울까요? 5는 4는 3GS는? 개발자가 알아서 깔끔하게 잘 해줄 수도 있지만 그렇지 못 하거나 특정한 경우는 기획/디자인 의도를 맞추기 위해서 개별적인 좌표를 잡아줘야 할 수도 있습니다. 물론 SUBMIT 버튼을 우측 기준의 좌표로 사용한다면 6,5,4는 하나의 좌표를 사용할 수 있습니다. 다 똑같은 여백을 띄우는게 맞으니까요.
- 여섯째로 개발자에 대응해야 합니다. 예를들어 SUBMIT 버튼을 우측 픽셀로 알려주면 간단한데 개발자가 좌측 픽셀을 원한다면 4,5,6 모두 좌측 기준의 서로 다른 좌표가 필요합니다. 3GS,4,5,6,6+의 좌표가 다 다르겠죠. 또한 절대좌표를 원하는 개발자가 있고 상대좌표를 원하는 개발자가 있습니다. 즉 이미지가 25×25 픽셀의 위치에 있다고 하면 절대 좌표입니다. 그런데 좌측으로부터 25픽셀 떨어져 있고 상단으로부터 25픽셀 떨어져 있으면 상대 좌표가 됩니다. 똑같다고요? 똑같지요. 그런데 그 밑에 붙는 이미지는 어떨까요. 어떤 이미지가 절대좌표로 25×25와 25×28픽셀에 각각 위치한다면, 상대좌표는 25×25와 0x3이 되겠지요. 디자이너에게 사실 큰 차이는 없을 겁니다. 문제는 아이폰/안드로이드 개발자가 각각 있는데 한사람은 절대좌표로 달라고 하고 한사람은 상대좌표로 달라고 하면 이중 작업이 된다는 거죠.
- 일곱째, 마지막으로 디자인 수정 시 대응해야 합니다. 가이드 다 치고 폰에서 테스트를 하니 "최상단의 세로 여백이 너무 좁아요. 조금만 넓혀 주세요." 라고 합니다. 최상단의 상하 여백을 넓하고 나면 그 아래로 붙는 모든 이미지들의 좌표를 다 수정해서 줘야겠지요. 그 최상단이 Global 영역이라 한다면 관련된 모든 디자인의 가이드를 모두, 절대/상대 좌표 각각 다, 모든 폰에 대응하여…
네이티브 영역이 많은 프로젝트라면 사전에 서로 이야기를 상세하게 해 보는 것이 좋습니다. 기획자/디자이너와 마찬가지로 개발자도 사람이라 누구는 이렇게 해도 누구는 이렇게 못 할 수 있습니다. 또한 기획자/디자이너와 마찬가지로 특정한 이유로 저렇게 할 수 밖에 없기도 합니다. 서로가 좋은 방향이 되도록 좋게 이야기 해 보는 것이 좋습니다.
분명한 것이 딱 하나 있습니다. 가이드를 단말기 별로 나눌수록, 또 해상도 별로 나눌수록, 즉 가이드 파일의 숫자가 많아질 수록 다 함께 피곤해 진다는 겁니다. 가이드가 많으면 개발자도 그걸 다 적용 해야 하고, 그 가이드를 디자이너가 수정하면 개발자도 마찬가지로 어느 부분이 어떻게 바뀌었는지 확인 해 가며 수정 해야 합니다. 그걸 또 서로가 제대로 반영이 되었는지 확인 해 봐야 하고요.
일 자체는 어렵지 않으나 일정도 빡빡한데 가이드의 타입이 많고 막판에 수정까지 터지면 손목에 터널증후군이 오고 말겠지요.
여기까지 입니다.
그림이 있으면 글이 줄어들었을텐데, 그림 귀찮다고 무조건 글로 다 쓰고 보니 오히려 손목만 뻐근하네요. 다음에 유사한 글을 쓸 일이 생긴다면 그 때에는 그림도 좀 그려 넣겠습니다.
긴 글 읽으셔서 수고하셨고 조금이나마 도움이 되셨기를 바랍니다.
'모바일개발(Mobile Dev) > IOS개발(ObjectC)' 카테고리의 다른 글
| Using Unwind Segues (0) | 2015.12.19 |
|---|---|
| Introduction to Auto Layout (0) | 2015.12.16 |
| textfields Readonly (0) | 2015.12.15 |
| ABOUT UIBarButtonItems (0) | 2015.12.15 |
| Failed to allocate data stores for 854269899 rows in section 0. Consider using fewer rows" (0) | 2015.12.15 |
20 Comments
Pingback: iOS의 멀티 해상도 디자인 가이드 | Angel King
안녕하세요 블로그 보고 질문이 있어서 글 남깁니다.
지금 간단한 아이폰 어플리케이션 개발을 하고있는데
이미지 때문에 계속 진행이 안되고 있습니다.
아이패드 용은 만들 계획이 아니며, 아이폰4,5,6,6+ 용 만 만들고 있습니다.
1242×2208 로 이미지를 하나 만들어서 다 적용 시키면 되는건가요? images.xcassets 에 보면 1x 2x 3x 로 나뉘어져있는데
각 아이폰 크기에 맞추려면 어떻게 해야하는지 잘 이해가 가질 않습니다.
도와주실수 있으시면 알려주실수 있나요?
부탁드립니다.
제 이메일은 thdansgur@gamil.com 입니다.
사실 글에서는 1242×2208 로 작업해야 한다라고 했지만 실제로는 꽤나 어려운 일일거라는 생각을 합니다. 픽셀이 너무 크니까요.
국내 안드로이드 프로젝트들을 보면 720p이미지를 사용할 때가 많습니다.720×1280으로 작업해도 6인치 FHD 폰에서? QHD 5.5인치 폰에서? 쨍쨍하게 보입니다. 물론 1080×1920 의 이미지가 더 선명하게야 보이겠지만 아주 세밀한 (예를들면 작은 글자들이 빼곡한) 이미지가 아닌 이상 티가 안나죠. 퀄리티에 목숨을 거는게 아니라면 오히려 720×1280 쪽이 퍼포먼스도 좋고 데이터 사용량도 적습니다. 어느정도냐면 10인치 패드에서 보면 조금 아쉽지만 이것도 패드 전용 UI 를 짠다면 일반인들에게는 티가 나지 않는 정도입니다. 단순 확대했다면 티가 나겠지만 크기에 맞추어서 UI가 변형되는 스타일이라면 버튼 크기 등이 그대로니까요.
다시 아이폰으로 돌아와보면, 첫번째로 정말로 원본 사이즈를 2208로 디자인을 할 것인가를 고려 하셔야 할 것이고, 두번째로 2208로 디자인 하던 말던
x2 는 750×1334 이미지를 의미하고 x1 은 640×1136 을 의미합니다.(수정: x2는 750×1334와 640×1136을 모두 의미하네요. imageasset을 보니 @2x, retina @2x가 따로 있습니다. x1은 여전히 320×640 입니다.) 기존과 같이 @1하고 @2가 정배율로 나뉘던 시대는 끝났습니다. 각기 전혀 다른 사이즈라고 생각하시면 됩니다. 즉 원본이 2208이라면 그걸 1334로 리사이즈 후 @2로 저장하는 겁니다.마지막으로 가장 간소화 하는 방법은 750×1334 하나만 가져가는 겁니다. @1과 @3은 무시하는거죠. 아이폰5s에서는 약간 큰 이미지를 자체적으로 리사이즈해서 사용할거고 (예를들면 100×100 의 이미지를 브라우저가 HTML태그로 인하여 80×80으로 리사이즈해서 보는것과 비슷합니다.) 아이폰6+에서는 작은 이미지를 확대해서 사용하는 꼴이겠죠. (100×100 이미지를 120×120으로 사용하는거죠.) 5s에서는 퍼포먼스가 약간 부족할거고 6+에서는 퀄리티보다는(해상도는 위의 안드로이드 폰을 예로 들었듯이 사실 충분하므로) 좌표만 맞춰놓으면 별 문제 없을겁니다. (추가: 어차피 현재는 @2x가 애매하게 되어 있지만 나중에는 6용으로 정확한 사이즈나 배율을 요구할 수도 있습니다.)
각각 테스트 해 보세요. 글자들이 어느정도 있는 풀 이미지와 작은 이미지가 웹뷰 등에 녹아 있는 화면을 @1 @2 @3 으로 이미지를 이런 저런 크기로 해 보시면 차이를 느끼실 수 있습니다. 즉 1334 하나를 @1 @2 @3으로 저장해서 보시고, 제대로 제작해서 보신 후 차이를 보시면 되는거죠. 1334 하나만 만드셔도 별 차이를 못 느끼실거예요~
안녕하세요~ 좋은 글 잘 보았습니다. ^^
저희는 이전에 1x, 2x 두벌을 모두 앱에 넣어놓았었습니다. (가로 320px, 640px)
그래서 아무래도 6플러스에서 불러오는 이미지가 너무 흐릿하게 보여서 다시 작업을 하려고 하다 글을 읽고
대충 어떻게 해야할지 알게 되었습니다. 궁금한 점이 몇가지 있는데 답변해주시면 너무너무 고마울 것 같습니다. ^^
1. 3x 기준으로 디자인을 다시 하고 2x, 1x로 리사이징 해서 결국 3벌을 다시 만드는 방법을 말씀하신 것 같습니다. 그런데 제가 생각할 때 세로px 기준으로 2208(3x)를 만들고 이걸 2x는 1334로, 1x는 480으로 사이징을 줄이면서 한벌씩 총 세벌의 이미지를 만드는게 아닌가 해서요. 위의 글에서는 2208, 1500, 1366이라고 하셔서 약간 혼동스럽습니다. 제가 잘 이해를 못하는 것일 수 있어서 다시 리플로 질문드려요~
2. 세벌의 이미지를 모두 앱에 넣으면 용량이 정말 매우 커집니다. 이럴 때 2x나 3x 한벌만 작업해서 모두를 커버하거나 선별적으로만 3x를 적용하고 싶기도 한데 이럴 때 해당 해상도에 없는 이미지를 하위나 상위에서 자동으로 불러오는지도 궁금합니다. 저희가 넣어봤을 때 3x만 넣으면 1, 2x를 쓰는 폰에서는 못불러오는 것 같아서요 그럼 큰 이미지를 1x에 넣어야 하나 궁금하기도 합니다. ^^
질문이 많아 죄송스럽지만 ^^ 좋은 답변 부탁드립니다. 좋은 글 감사합니다. ^^
안녕하세요 . 먼저 죄송하실 건 없고요^^; 제 글에 오타인지 오류인지가 있었네요. 짚어주셔서 감사합니다. 제가 댓글 확인이 늦었습니다. 거의 댓글이 없는 블로그다보니…
말씀하신데로 가로 640px을 큰 화면에서 보기에는 아쉬운 감이 있습니다.
1. 제 글에서 뜬금없이 1500이 나왔는데, 그 부분을 정정해두었습니다. 2208 하나, 1334 하나,
1136 하나입니다.수정: 640 하나입니다. 가로로 말하면 1242, 750, 320 입니다. 가로 기준으로2. 말씀하신데로 하나의 이미지로 퉁친다면 x1 하나만 두면 됩니다. 3GS용으로 제작된 낮은 해상도의 어플도 5이상에서 뿌옇지만 잘 보이니까요. 제가 그 부분들까지는 신경쓰지 않았고 어쩌다보니 오히려 약간 반대로 이해가 되도록 쓴 부분도 있는데 개발자분이 5분만 테스트해도 알 수 있는거라 생각했거든요. (글 내용이 쓸데없이 어려워지고 길어지던 터이기도 했고;;) 그런데 지금 보니 음 모든 폰을 다 구비해놓고 테스트하는 개인 개발자분은 없겠네요.^^;
도움이 되셨기를 바랍니다.
안녕하세요. 정말 도움되는 글입니다 !!
조금의 도움을 더 요청하고자 글을 남깁니다ㅠㅠ
작년 앱디자인을 처음하게 되었는데요, 안드로이드는 개발업체에서 많이 도와주셔서 여차저차 만들었습니다.
그런데 ios의 경우 6+와 6가 나오면서 디바이스별 이미지가 필요하시다 하더라구요.
6+ 1242×2208 사이즈로 작업된 이미지들을 png파일로 저장하여 개발업체로 보내드렸는데,
6와5의 이미지도 별도로 작업해서 드려야 하는 것인 가요 ?
리사이즈 하는 방법은 일일이 하나씩 줄여나가야 하는 방법 밖에 없나요 ?
앱을 마냥 사용만 하다가 디자인하면서 공부하고, 책을 읽고 정보를 찾아 보아도 개발부분 단어나 내용을 이해하기에 한계가 있네요.
답변부탁드립니다 !
안녕하세요. 고생이 많으십니다.
1. 개별 이미지 저장은 개발업체에게 문의하시는게 정확할 것 같습니다.
내부 정책 결정에 따르는 사항일테니까요. 가장 좋은 건 모든 사이즈의 이미지를 다 만드는 것이지만 디자이너의 작업량을 떠나서 이미지 수정 시, 그리고 앞으로 유지보수 시 번거로운 면이 있으니까요. 예를들어 큰 이미지(전체 화면을 덮는 이미지)는 @1,@2,@3을 만들되 그 외에는 @1, @3만 만들것인지. 이 때 @1은 6에 맞춰서 하면 5는 자동적으로 리사이즈해서 볼 테니 그정도면 좋을 것인지 등은 정책 결정에 따라 다를 수 있습니다. 정책이 없다면 서로 합의를 해야겠죠. 개발자 쪽이라고 해서 다 알고 있지는 않는 경우도 많습니다. 잘 아는 사람이 나서지 않는다면 서로 어영부영 진행하는 부분도 생기긴 하겠습니다만 그래도 최대한 이야기를 해서 결론을 내리는 게 최선 같습니다.
여담으로 2208 하나만 보내기로 하고 가이드까지 전달했다면 화면상의 이미지 크기야 개발자분들이 잘 맞추겠지만, 최종적으로는 퍼포먼스 때문에 5나 6용 이미지를 요청할 수도 있습니다.
2. 리사이즈 하는 방법은 어플이나 사이트가 있기는 있습니다.
http://cafe.naver.com/mcbugi/ 맥부기 게시판에 가보시면 osx 용 어플로 @3을 만들어놓으면 자동으로 @1,@2도 저장해주는 어플이 있네요. (직접 써보지는 않았습니다.) 포토샵에서는 배치를 이용하셔야 할거고요. 사이트는 저도 지금은 찾을 수가 없네요. 죄송합니다.
쓰고보니 큰 도움은 안된 것 같네요(…) 그래도 조금이나마 참고가 되셨기를 바라는 마음으로 올려봅니다.
아닙니다 !! 도움이 되었습니다ㅠㅠ
어떻게 할지 갈피를 못잡고 있었는데, 역시 업체와의 소통이 필요한 것 같네요 !!
감사합니다 : )
댓글 내용 중
이미지 assets에서
1x: 레티나
2x: 6
3x: 6 plus
라는 내용이 있는데
확인 해보니 iphone 4~5s에서 모두 @2x를 로드하던데요 ..
보니까 이사람 뭐 제대로 모르는거같은데요 -_-;;
x1 이 엑스페리아 x1 모델을 의미하거나, '의미'라는 단어의 의미를 모르는거같네요.
아 내용 감사합니다. 제가 댓글을 달면서 잠깐 착각을 했습니다. 4~6이 모두 @2x를 쓰고 있습니다. 관련된 댓글 내용들을 약간씩 수정하였습니다.
그리고… 제가 제대로 뭐 모를 수도 있습니다. 의미라는 단어의 의미도 말이죠.^^ 짚어주셔서 황송하네요~
이번에 아이폰 디자인을 처음 맡게 되었습니다.
해상도와 관련해 서치중 이곳에서 귀중한 자료를 읽어보네요/
그리고 쉽게 잘 설명을 해놓이신 것 같아요/
뒤늦게 댓글 답니다. 제 글을 제가 읽어보니 너무 어지럽게 써 놓았네요^^; 길게 설명하지 말고 요점만 간략히 쓸 걸 하는 생각을 뒤늦게 하고 있습니다만(ㅠㅠ) 도움이 되셨다니 다행입니다~
Pingback: iOS: 멀티 해상도 디자인 가이드 | GTyga
좋은 글 감사합니다. 이번에 처음으로 앱 디자인을 하게 되었는데 걱정이 많았는데 도움이 됩니다.
어떤 곳에서는 아이폰 3Gs 크기인 320*480 크기로 작업하고 나중에 각 해상도별로 크기를 늘려서 작업해야 한다는 곳도 있고, 안드로이드 역시 가장 기본 해상도에서 작업해서 늘려야 한다는 말이 있는데, 말씀하시는 바로는 오히려 반대로 가야겠네요.
만약 아이패드까지 작업을 해야한다면 상당히 손이 많이 가는 작업이 되고, 기간도 길어져야 할 것 같은데, 현재 말씀하시는 것은 아이폰을 중심으로 말씀하시는 거라, 아이패드까지 맞춘다면 이건 따로 진행이 되어야 할 부분인지도 궁금합니다.
좋은 글 감사합니다.
안녕하세요. 댓글이 늦었습니다.
작게 디자인 후에 해상도별로 어떻게 늘리죠?^^;; 작은 사이즈로 작업을 먼저 한다는 전혀 말이 안 되는 것 같습니다. 게다가 320×480 의 해상도는 이제 쓰는 폰도 거의 없고요.
아마도 좌표 이야기와 혼동하신 게 아닐가 싶습니다. 640×960의 이미지는 320×480의 x2고 실제로 좌표는 320×480을 따라 가죠.
뭐 어쨌든, 간단한 방법이 있습니다. 어느 폰을 지원하느냐 입니다.
아이폰5부터 지원한다. 갤럭시S4부터 지원한다면 해당하는 단말기들에 맞는 해상도만 지원하면 됩니다.
다만 아이폰6+ 의 2208해상도는 보통 지원을 잘 안합니다. 그냥 실제 기기에 맞는 FHD 해상도만 지원을 하죠. 왜냐면… 아마도 귀찮으니까(…) 아이폰 개발자가 아니면 2208 해상도와 DPI 에 대해서는 아예 모르는 경우도 많거든요. FHD로 해도 어차피 다 잘 보이고요. (물론 모든 UI가 좀 큼지막하게 보이겠죠.)
그리고 안드로이드는 요새는 FHD 한 벌만 디자인을 하기도 합니다. 어차피 2560해상도인 QHD까지 맞추는건 다들 오버라고 생각하거든요. HD 구형 폰에 맞추는 작업도 귀찮고 하니 FHD하나만 합니다. 뭐 그래도 다들 잘 보입니다.
그래서 결론은 FHD 하나만 디자인 후 리사이징하여 안드로이드/아이폰에 모두 적용하는 시대죠. 대상 단말기들을 확인 하신 후에 어찌 되었든 크게 작업 후에 리사이징하면 됩니다. 물론 조금은 범용적인 케이스로 말씀드리는 거예요. 프로젝트마다 고객이나 PM의 생각이 다를 수 있죠.
그리고 아이패드 말씀을 해주셨는데요. 아무래도 태블릿은 PC와 모바일의 중간 정도의 성격이라, 기능은 모바일을 따라가고 화면은 PC를 따라가다 보니 기획/디자인을 새로 해야 하는 경우가 많죠. 하지만 물론 따로 해야 하는 거라고 정해져 있는 건 아닙니다.
먼저 설계를 어느 정도 새로 하느냐에 따라 새로 하는 작업(기획/디자인/개발)의 볼륨이 정해지겠죠. 결국 그에 따라 일정을 짜보고 따로 할지 말지를 정하거나 하겠지요. 아니면 메뉴나 몇 가지만 수정해서 그럭저럭 구색 맞춰서 런칭하는 방법도 있을거고요. 그러니 이 부분은 죄송하지만 제가 따로 해야 합니다 혹은 같이 하셔야 합니다 라고 답변을 드릴 수는 없습니다. 새로 해야 할 작업의 량이 어느 정도 될 것이다 라고 예측 후에 그에 맞추어서… 가야겠죠?
도움이 되셨기를 바래요~!
댓글 감사합니다. 결국 큰 사이즈를 만들고 그 사이즈를 줄여서 자르는 게 낫겠네요. 이미지를 그렇게 잘라서 @2x @3x 형식으로 붙이고요. 처음이라 얼떨떨하지만 약간 감이 옵니다. 감사합니다.
네 그렇게 작업하시면 됩니다.
다만 두 가지 추가 말씀 드리면
1. 정책은 PM하고 얘기한다 하더라도 실무를 개발자하고 한 번 더 이야기 해 보시는 게 좋을 겁니다.
2. 네이티브 영역에는 가이드를 해줘야 합니다. (네이티브 앱이라면 전체에, 하이브리드 앱이라면 메뉴단 정도에) 몇픽셀 서로 떨어져 있고 커질 경우 늘어나는지 위치가 이동하는지 등등을 기술 하는 것이 앱 디자인 가이드 입니다. 그리고 좌표를 어떻게 찍어줘야 할지 등등.
단적인 이야기로 @2x 이미지가 아이폰4~아이폰6를 어우릅니다. 3가지 해상도가 존재 하는 데 어느 사이즈로 제작해서 어떻게 작업해야 할까요…?