[잡솔] 아이폰6, 아이폰6+의 해상도 2편 (디자이너의 작업)

 

1편은  http://www.bluejini.net/?p=634 에서 확인하실 수 있습니다.

2편을 작성하게 된 이유는 몇 가지 있습니다.

일단 글이 너무 난잡했습니다. 포커스도 없었고요. 짧게 써질 줄 알았는데 점점 같은 얘기를 다른 버전으로 반복 하게 되면서 (응?) 글이 쓸데 없이 길어졌고 오류도 여기저기 있습니다. 이 부분은 죄송합니다. 댓글이 달릴 때마다 조금씩 수정해왔으나 수정에도 한계가 있네요.

또한 지난 글에 정말 드문드문이지만 댓글들이 지속적으로 달렸습니다. 제 블로그에 앵간하면 댓글이 없기 때문에 제가 댓글 확인을 거의 안하거든요. 이런 블로그에, 네이버에 나오지도 않는 이 글에, 달릴지 안달릴지 모를 대댓글을 기다리며 질문 글을 올리신 분들께 일종의 책임감을 느끼게 되었습니다.

그리하여, 여전히 구어체 설명이기는 하겠으나 1편보다는 더 간략하고 실무에 맞춘 디자이너를 위한 글을 결심하게 되었습니다. 실제로 어떻게 작업해야 할지 아직도 막막한 디자이너분들에게 도움이 되었으면 좋겠습니다. 물론 디자이너가 아니어도 참고 용도는 되실 것 같습니다. 저도 디자이너는 아닙니다.

 

 

1. 세 가지 해상도의 이유.

 

먼저 세 해상도가 어떻게 돌아가는지 정확히 짚고 넘어가려 합니다. 아시다시피 아이폰은 대표적으로 세 가지 해상도의 이미지를 사용합니다.

 

  • 1x – 3이하 (국내에서는 3gs)
  • 2x – 4~6
  • 3x – 6+

 

기존 글을 보신 분들은 왜 해상도가 다 제각각인지 대략 이해 하셨으리라 봅니다. 하지만 여전히 풀리지 않는 의문이 있습니다.

 

물리적으로 화면이 커지고 해상도가 달라졌고 따라서 좌표를 다르게 쓰는 것은 이해 하겠다. 그런데 아이폰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버튼은 우측정렬이어야 하며 또한 좌측정렬인 아이는 좌측0포인트에서부터 얼마나 떨어져야 있을까 등등을 알려줘야 모든 폰에서 정상적으로 보이겠죠? 세 폰의 차이는 가로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인치 이하의 폰에서 구별하는 것은 무의미 하거든요. 구별이 안되는 건 아닙니다. 다만 구별 되는 건 눈꼽만큼인데 괜히 데이터만 더 쓰고 속도만 더 느려질 뿐이죠.

 

  1. 기준 폰이 무엇인지 알아야 합니다. 요새는 FHD 이상의 폰이죠. 갤럭시 s4와 노트3은 FHD이고 s5이상/노트4 이상은 QHD (2560) 입니다. 아이폰은 물론 6 입니다.
  2. 최소 지원 폰이 무엇인지 알아야 합니다. 갤럭시 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를 사용하고 pt좌표만 다르게 전달하는 것입니다. 이것은 읽어내려가시면 하단에 내용이 있습니다.

FHD 로 작업을 마쳤으나 개발자의 요청에 의하여 특정 파일은 아이폰6+ 때문에 2208사이즈로 결과물을 내야 하는 경우도 있습니다.  (스크린 샷 같은 경우) 이 때에는 그냥 이미지를 확대 해서 저장하세요. 1920을 2208로 확대하여 이미지가 약간 어벙하게 보인다 한들, 실제 폰에서는 다시 1920로 줄이게 되고 또한 폰의 화면 크기가 작기 때문에 아무런 문제 없이 깨끗하게 보입니다. (폰의 크기 상 1280으로 작업해도 그 차이가 티가 안 나는 경우도 많습니다.)

위와 같이 작업해도 대응은 다 되는 것입니다. 

그런데 만약 아이폰 전용 프로젝트를 하고 있고 리더가 6+에 대응을 정확히 하기를 원한다면, 즉 리더가 6와 6+의 차이를 정확히 이해 하고 있고 그에 상응하는 작업을 요구 할 때에는 처음부터 2208 사이즈로 작업해야 할 수 있습니다. (또는 그 1/3사이즈로 pt로 작업할 수도 있습니다. pt에 대해서는 하단부에 다시 설명합니다.) 그에 상응하는 작업이란 6+에서 넓어진 화면 크기 만큼 추가 UI를 넣거나 또는 화면을 넓게 사용한다는 이야기입니다. 하지만 걱정은 없습니다. 기획단에서 먼저 기획이 되어서 넘어오니 디자인만 해주면 됩니다. 

 

이제 실제로 6+로 작업을 해 보겠습니다.

지난 글에서는 2208로 작업 후 리사이즈한다고 써 놓았습니다. 맞는 말입니다. 하지만 중간 과정을 통으로 생략해서 100% 맞는 말은 아니었습니다. 또한 무조건 2208로 작업해야 하는 것도 아닙니다. 선택일 뿐입니다.

 

자세하게 설명해 보겠습니다.

6+에 제대로 대응을 한다고 했을 때, 하나의 icon이 있을 때 6와 6+를 비교하면 이렇습니다.

  • 화면의 물리적인 크기는 6+이 크다.
  • 눈에 보이는 icon의 크기는 같다. 
  • 따라서 6+에서는 6와 동일한 해상도의 icon을 배치 시 화면에 여백이 더 남는다. (5와 6의 차이와 동일한 원리.)

 

그렇다면 어떻게 디자인 해야 할까요? 1x 사이즈인 pt로 계산을 해보면 쉽습니다.

  • 아이폰6 은 375×667
  • 아이폰6+ 은 414×736

아이폰6+이 화면이 크죠. 이제 작업을 상상해 봅니다. icon 크기를 375×667 내에서 아이폰6에 담아서 정상적으로 보이도록 작업합니다. 그리고 이미지 사이즈가 아니라, 바탕인 캔버스 사이즈를 414×736 으로 바꿉니다. 그러면 빈 여백이 생기죠. 그만큼에 더 많은 UI를 담으면 6+ 대응이 됩니다. (물론 반드시 많은 걸 새로 그려서 담아야만 하는 건 아니죠? 단지 여백이 많아질 수도 있습니다. 많은 앱들이 더 많아진 여백을 단지 더 많은 텍스트를 담는 용도로 사용 중에 있습니다.)

하지만 1x는 작업 사이즈가 너무 작습니다. 벡터로 이미지 제작 후 늘리는 것도 방법이고, 아주 단순하게 기본UI+텍스트로 구성되어 있다면 상관없습니다만, 비트맵 이미지(흔히 포토샵 이미지)가 포함되어 있다면 퀄리티가 떨어질 것입니다. 또한 작은 사이즈에서 늘린다 하더라도 최종적인 사이즈는 알아야 합니다. 어쨌든 PC사양만 된다면 큰 이미지에서 작업 후 리사이즈하면서 처리 하는게 더 간편하죠. 처음에는 글자만 있었다 하더라도 갑자기 배너를 넣어달라고 할 수도 있기 때문입니다.

그럼 두 배로 각각 올려 봅니다. 아이폰6 은 750×1334 고 아이폰6+은 828×1472 입니다. 미묘하죠.

마지막으로 세배로 늘려볼까요? 아이폰6은 1125×2001, 아이폰6+은 1242×2208 이 됩니다. 감이 오시나요? 1125×2001의 작업물을 아이폰6에 담아서 제대로 보인다면 그걸 2/3으로 줄이면 (당연하지만) 아이폰6 해상도이고 정상적으로 보일 것입니다. 그렇다면 1125×2001 에서 캔버스를 늘려서 1242×2208 을 만들고 그 여백만큼 추가 작업을 하면 어떨까요. 정확하게 아이폰6+ 해상도를 대응하게 됩니다.

크게 작업할 수 있는 사이즈는 6 기준으로는 1125×2001 입니다. 이제 작업 방법은 본인 취향대로 결정 하기만 하면 됩니다.

먼저 1125×2001로 작업하는 방법입니다.

  1. 1125×2001로 작업한다.
  2. 풀 사이즈(또는 그에 준하는 사이즈)의 이미지는 1125×2001외에 1242×2208로도 작업한다.
  3. 1125×2001로 작업이 완료되면 컨버스를 1242×2208로 늘린다. 여백을 가지고 추가 기능을 넣거나 가이드 작업을 한다.

작업은 명료합니다. 다만 단점도 명확합니다. 1242×2208로 늘렸을 때 얼마만큼의 여백이 남는지 미리 확인할 수가 없습니다. 계획적으로 기획/디자인 할 수가 없죠.

그렇다면 1242×2208로 작업하는 방법입니다. (굳이 제가 적지 않아도 디자이너 분들이 더 잘하시겠지만 혹시나마)

  1. 1242×2208로 작업한다.
  2. 풀 사이즈 이미지는 컨버스에 꽉차게 그리고 1125×2001로도 재작업한다.
  3. 디자인 파일 내에 가이드로 1125×2001를 쳐 보면 여백이 미리 확인 가능하므로 그 여백에서 무엇을 할 수 있는지 고민한다.

이렇게 된다면 좋겠죠. 물론 1242×2208로 작업한 이미지는 6+에서 확인했을 때 정상적으로 보여야 합니다. 6에서 확인하면 안됩니다. 그럼 너무 작게 보여요. 6에서 확인하기 위해서는 가이드로 쳐 놓은 1125×2001로 커팅(크롭) 후 확인해야 합니다. 실제 저장시에는 1334로 리사이즈 하겠지만 확인 용도에서는 리사이즈가 필요 없죠. 알아서 해주니.

그리고 2번 작업 시 재작업으로 써 놓은 이유는 아시겠지만 2208로 작업 후 2001로 바로 줄이면 만약 이미지에 글자가 포함되어 있다면 글자크기도 함께 줄어들겠죠. 이를 방지하기 위해서는 글자는 그대로 두고 다른 이미지만 줄여야 합니다. (먼저번의 방식은 글자는 키우지 않고 다른 이미지만 키워야겠죠.) 물론 풀 이미지에서 글자 크기를 해상도에 정확하게 대응 하는 건 꽤 세심한 디자인일겁니다. 처음부터 글자를 조금 키워서 작업하면 바로 리사이즈 해도 무방하겠죠.

이 정도면 사이즈 작업에 대한 답은 된 것 같습니다.

단지 마지막으로 하나만 더 추가하면, SI 프로젝트를 하면 위의 사이즈 같은 건 별 의미 없을 때가 많습니다. 그냥 1920으로 하고요. 개발자가 알아서 하고요. 그리고 몇 번 하다보면 감이 옵니다. 그냥 6용으로 디자이하면 6+은 알아서 여백이 넓어지는구나. 네, 보통 이렇습니다.

오오. 그런데 반대로 쓸데 없는 사이즈도 다 달라고 할 때도 있습니다. 어쨌든 사실을 알고 있다면, 로직을 정확하게 파악하고 있다면, 개발자와 협의 후 더 합리적이고 좋은 방법을 사용할 수 있을 겁니다. PM 말이고 다 들으면 안돼요. PM이라고 다 아나~?

 

** 2016.03.12 추가. 제 글의 내용을 그림으로 요약해 놓은 링크를 하나 추가합니다. 댓글로 알려주신 분이 있어서 추가합니다. (사실 왜 글자크기가 줄어들어서 결국 같은 크기의 글자로 보여지게 되는지까지 설명된 그림도 있었는데 제가 찾지를 못 하겠네요.)

http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions

작업 방식을 알고 싶으셨던 분들은 제 글은 그냥 읽으시면서 이해하는 식으로 넘어가시고 최종적으로는 위 링크만 기억하세요. 다만 링크에 한가지 오류가 있습니다. 아래에 설명합니다.

링크에서 이미지의 제일 우측을 보시면 iphone 6+ display zoom 이 있습니다. 좌표를 iphone 6 와 동일하게 사용할 경우에 대한 예제입니다. 아이폰6의 좌표를 쓸 경우 x3기준으로는 이미지를 아주 약간 줄여서 보여주게 되는데 (0.96배) 화면의 물리적 크기는 꽤 많이 커져서 결과적으로 화면의 요소가 커지게 된다는 이야기입니다. 

부가 설명을 추가하면 iphone 6 plus 사이즈는 1242×2208인데 줄어들 때 1.15배라고 써있지만 뭔가 이상하죠. display zoom 과 동일한 방식으로 계산하면 0.87배입니다. 더 많이 줄어듭니다. (당연하겠죠? 더 큰 크기에서 줄인거니) 결국 디자이너가 만든 동일한 픽셀의 이미지(또는 글자 등의 요소)는 아이폰6 캔버스로 작업한 것 보다 아이폰6+캔버스로 작업한 것이 결과적으로 더 작게 표현됩니다. 물론 아이폰6+는 폰이 크기 때문에 최종적으로는 알맞게 표현되는거죠.

이렇게 생각해 보세요. 맨 우측을 보시면 iphone 6 plus 가 두 개 있습니다.

* iphone 6 plus (display zoom) – 375×667에서 375×667로 네모를 그리시고.

* iphone 6 plus (오리지날) – 414×736에서 375×667로 네모를 그렸습니다. 여백이 생기겠죠?

둘다 아래 아래로 내려가서 최종 결과물(Physical Deivce)을 보면 1번은 풀로 화면에 찰 것이고 2번은 여백이 생깁니다. 그런데 아이폰6+의 물리적인 화면 크기는 동일합니다. 결론은 사람 눈에 네모는 1번이 더 크게 보이죠. 2번에서는 조금 작은 네모와 여백이 보일테니까요.

이제 x3 픽셀로 실작업을 해본다 하면 마찬가지로 맨 우측의 이미지 기준으로

* iphone 6 plus (display zoom) – 1125×2001 의 캔버스와

* iphone 6 plus (original) – 1242×2208 의 캔버스를 활용하면 됩니다. 큰 쪽에서 그린 후 잘라내어 크롭하면 6+ 먼저 작업 후 6까지 대응하는 것이 됩니다.

아이폰4,5,6도 마찬가지로 보시면 됩니다. 링크 그림대로 만약에 5로 작업한 결과물을 그대로 6에서 본다면 업샘플링을 통해 1.17배 크게 보여지게 됩니다. 5보다 폰이 크니까요. 6에서 제대로 표현하고 싶다면 6전용 좌표를 써야겠죠.

6+를 제외할 경우의 실 작업 사이즈인 Rendered Pixel 로 설명 드리면

* 아이폰5 – 640×1136 캔버스에 640×1136픽셀 이미지를 제작했다 치고

* 아이폰6 – 750×1334 캔버스에 640×1136픽셀 이미지를 제작하면 여백이 생기겠죠.

이제 이 둘을 최종 폰(Physical Device)에서 보면,

아이폰5는 당연히 화면에 꽉 찰 것이고

아이폰6는 이미지+여백이 화면에 꽉 찰 것인데, 늘어난 픽셀만큼 화면이 커졌으니 사람 눈에 이미지의 크기는 아이폰5와 아이폰6이 동일하게 됩니다. 4,5,6의 경우 이미지는 동일하게 사용하고 좌표만 다르게 쓴다는 부분이 이 부분입니다. (물론 풀이미지는 개별 작업 필요)

이제 가이드로 넘어가 보겠습니다.

 

** 2016.12.29 추가. 6+에서 풀사이즈의 이미지는 2208보다 1920으로 넘기는 것이 용량과 퍼포먼스 측면에서 낫습니다. 굳이 2208을 넘겨서 1920으로 리사이징 해서 보는 것 보다 처음부터 1920으로 넘기는게 좋겠죠. 이것은 런치 이미지처럼 가이드가 필요 없는 풀 이미지에 해당됩니다. 1편 글의 문의 댓글에 추가 댓글로 설명 등록해 두었습니다. http://www.bluejini.net/archives/634#comment-108 

 

 

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가 애매한 부분이 있다면 기획자에게 컨펌을 받으면 됩니다.

 

** 2017.01.20 내용 수정 – 이 후의 내용들을 전반적으로 축소/수정했습니다. 글이 중구난방이 되었으나 pt에 대한 설명은 문서 하단부에 별도로 있으니 적당히 읽어 내려가주시면 될 것 같습니다.

 

픽셀로 작업 시 가이드는 6+/6/3 용이 다 다릅니다. 하지만 pt로 작업 시에는 가이드 파일은 한 개면 됩니다. (또한 3GS용은 요새는 개발을 거의 하지 않습니다.) 

물론 아이폰의 몇몇 기본 앱 처럼 6+에서만 UI가 적극적으로 변화한다면 그 부분은 별도로 가이드가 필요할 것입니다. 따라서 가이드를 칠 때에 pt로 하나만 주면 되는지를 먼저 확인 해 보는 것이 좋습니다. 

 

파일은 보통 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 지원을 하는지? pt로 가이드를 하나만 치면 되는지?
  • 둘째로 네이티브 영역을 정확하게 파악해야 합니다. 어디가 네이티브 영역인지는 개발자나 기획자에게 물어봐야 하겠죠. 본문은 웹뷰인데 상단 top bar와 하단의 floating버튼은 네이티브 일 수 있습니다. 가이드는 네이티브 영역만 쳐주면 됩니다. (물론 웹 영역도 가이드가 필요할 수 있습니다. 이미지를 퍼블과 디자이너 중 누가 자르느냐, 롤의 차이겠죠.)
  • 셋째로 화면 상에 표시되는 모든 요소(이미지/텍스트)에 대하여 정확하게 짚어줘야 합니다. 희끄무리한 라인 하나까지도 정확하게 위치를 잡아줘야 하고 물론 그 위치는 기준점(상하/좌우 정렬)이 필요한 경우 기준점을 포함해야 겠죠. 기본적으로는 디자인이 특별하게 변화하는게 아니라면 여백은 항상 20이라던가 등의 가이드를 가지고 디자인을 하실 것입니다. 따라서 그런 것들은 생략되어도 개발에서 알아서 합니다. 하지만 혼자 수치가 다른 경우라면 반드시 적어줘야 합니다. 또한 폰트는 특정 폰트를 global 하게 쓴다면 폰트 이름을 한 번만 언급하면 되겠지만 크기는 각기 다 정해주어야 합니다. 마지막으로 네이티브와 웹뷰가 섞여 있고 시스템 폰트가 아니라 웹폰트를 쓴다면 둘 다 동일한 폰트로 정확하게 의도한대로 보이는지도 개발자에게 확인 해야 합니다. 은근히 잘 안되는 부분이더군요.
  • 넷째로 화면 너비나 높이에 맞추어 늘어나는 이미지는 정확히 어떻게 늘어나는지 알려줘야 합니다. 웹에서 이미 흔하게 하던 일이긴 합니다. 본문이 있을 때 텍스트의 세로 길이에 따라 본문 배경이 세로로 넓어지는 것들 말이죠. 물론 기획서에서 먼저 정의가 되어야 하겠죠.
  • 다섯째로 개발자 또는 기존 로직에 대응해야 합니다. 예를들어 SUBMIT 버튼을 우측 정렬 pt로 알려주면 간단한데 개발자가 좌측 픽셀을 원한다면 4,5,6 모두 좌측 기준의 서로 다른 좌표가 필요합니다. 3GS,4,5,6,6+의 좌표가 다 다르겠죠. 말도 안되는 케이스지만 살다보면  때때로 이상한 일들이 생기기 마련이죠.
  • 마지막으로 디자인 수정을 미리 대응해야 합니다. 가이드 다 치고 폰에서 테스트를 하니 "최상단의 세로 여백이 너무 좁아요. 조금만 넓혀 주세요." 라고 합니다. 최상단의 상하 여백을 넓하고 나면 그 아래로 붙는 모든 이미지들의 좌표를 다 수정해야 할 수도 있습니다. 따라서 하단의 좌표들은 특별한 경우가 아니라면 상대 좌표로 작성하는 것이 옳겠죠.

 

네이티브 영역이 많은 프로젝트라면 사전에 서로 이야기를 상세하게 해 보는 것이 좋습니다. 기획자/디자이너와 마찬가지로 개발자도 사람이라 누구는 이렇게 해도 누구는 이렇게 못 할 수 있습니다. 또한 기획자/디자이너와 마찬가지로 특정한 이유로 저렇게 할 수 밖에 없기도 합니다. 서로가 좋은 방향이 되도록 좋게 이야기 해 보는 것이 좋습니다.

분명한 것이 딱 하나 있습니다. 가이드를 단말기 별로 나눌수록, 또 해상도 별로 나눌수록, 즉 가이드 파일의 숫자가 많아질 수록 다 함께 피곤해 진다는 겁니다. 가이드가 많으면 개발자도 그걸 다 적용 해야 하고, 그 가이드를 디자이너가 수정하면 개발자도 마찬가지로 어느 부분이 어떻게 바뀌었는지 확인 해 가며 수정 해야 합니다. 그걸 또 서로가 제대로 반영이 되었는지 확인 해 봐야 하고요.

일 자체는 어렵지 않으나 일정도 빡빡한데 가이드의 타입이 많고 막판에 수정까지 터지면 손목에 터널증후군이 오고 말겠지요.

 

**2016.09.29 내용 추가 – 가이드 단위인 pt를 빠트렸기에 뒤늦게 추가합니다. 

가이드 작업시의 단위입니다. 아이폰에서는 pt를 사용하는데 point(좌표)입니다. 

pt와 실제 px을 비교해보면 아래와 같습니다.

아이폰4 pt 320×480 (x2 = 640×480) -> 1/2

아이폰5 pt 320×568 (x2 = 640×1136) -> 1/2

아이폰6 pt 375×667 (x2 = 750×1334) -> 1/2

아이폰6+ pt 414×736 (x3 = 1242×2208) -> 1/3

 

즉 1242×2208로 디자인 시 1/3하여 pt로 가이드를 잡아주면 됩니다.

중요한 부분은 pt단위로 놓고 보면 모두 PPI가 같다는 점입니다. 즉 하나의 가이드만으로 모든 기기에 적용이 된다는거지요.

– 무슨말이냐면 아이폰4에 비하여 아이폰6+는 가로/세로의 해상도가 커졌지만 그만큼 폰도 커졌죠.

  그 결과 만약 좌로부터 20pt를 띄우라고 가이드를 주면 아이폰6에서는 40px을 띄우고 6+에서는 60px를 띄우는데

  아이폰6+의 폰이 더 크기가 크고 픽셀이 촘촘하여 결과적으로 둘은 동일한 간격을 띄운 것처럼 보인다는 말입니다.

  (그렇게 보이도록 기기를 만들어놓은거죠.)

 

pt와 가이드에 대한 추가 설명은 하단에 댓글로 달아놓았습니다. http://www.bluejini.net/archives/955#comment-133

 

 

**2017.01.20 내용 추가 – 안드로이드와 아이폰을 동시에 작업 시 아이폰의 작업 사이즈 및 가이드는? 

글은 이미 엉망이 된 듯 합니다만 뒤늦게 더 내용을 추가 해 보겠습니다. 처음 디자인 하시는 분들이 흔히 겪는 문제일테니까요.

안드/아이폰을 동시에 하랍니다. 이 때 사이즈 및 가이드는 어떻게 해야 하나요?

가장 쉬운 방법은 FHD 하나만 디자인하고는 1/2로 pt를 주되 요소들은 약간 작게 디자인 하는 것입니다.

1334에서 40px의 크기로 디자인하고 싶었다고 칩시다. 그럼 1920에서 약 60px으로 디자인해야 하겠죠. 그리고 pt로 보자면 원래 1334에서 40px->20pt인건데 1920에서 1/2가이드를 하면 60px->30pt가 됩니다. 그럼 생각보다 커지게 됩니다. 즉 내가 디자인했을때에는 좌측에 글자가 있고 우측 여백이 디게 많은데, 실제로 폰에서 보면 좌측에 글자가 커지면서 우측 여백이 줄어드는거죠.

그럼 애초에 1920에서 40px로 디자인하고 20pt로 전달 하는 것입니다. 물론 이것도 위와 똑같은 결과가 나오긴 합니다. 디자인 파일에서는 글자가 생각보다 작습니다. 하지만 폰에 이식하고 나면 커지게 되죠. "글자는 이보다 약간 커질거야"라고 상상을 하며 디자인 했기 때문에 100%일치하지는 못하더라도 거의 원하는 결과를 얻게 됩니다.

또한 디자인 파일 내의 비트맵 이미지(jpg,png)는 원본이 넉넉한 사이즈라 안드로이드/아이폰에서 동시 사용하기에 충분합니다. (물론 저사양 단말을 위한 리사이즈는 별개 작업)

물론 단점도 있습니다. 예를들어 테두리 안에 글자가 있을 때, 그 글자와 테두리 사이의 여백이 완벽해야 폼도 완벽한 경우가 있습니다. 하지만 이렇게 한 벌로 처리 시 디자인 파일에서는 완벽해도 실제로는 완벽하지 않습니다. 여백이 생각보다 넓거나 좁거나, 테두리가 좌우로 길어진다던가 그렇습니다.

또한 하나의 화면에 딱 맞추는 디자인을 할 경우 티가 좀 더 나므로 주의가 필요합니다. 좌/우의 여백은 티가 덜 나지만, 상/하의 여백은 괜히 하단부가 비거나 모자를 수 있습니다

안드로이드1벌, 아이폰1벌은 좀 더 적극적인 가이드입니다. 그러면 각각 좀 더 잘 맞겠죠. 하지만 그렇다 하더라도 한 화면에 딱 떨어지는 화면은 상/하단 여백을 별도로 신경을 써줘야 합니다. 왜냐하면 6용으로 pt만으로 한화면에 딱 맞게 만들면 6+에서는 하단이 남을 수 밖에 없거든요. (물론 6을 단순하게 키워서 6+으로 제공하는 구형 App들은 안 그렇습니다. 다 확대되면서 여백도 똑같아요.)

여백을 방지하려면 가이드에서 정렬과 퍼센티지(예를들어 3개의 버튼이 가로로 각각 33%, 33%, 33% 내에서 중앙 정렬)를 적극 활용하면서 최대한 맞춰줘야 합니다.

 

 

여기까지 입니다.

그림이 있으면 글이 줄어들었을텐데, 그림 귀찮다고 무조건 글로 다 쓰고 보니 오히려 손목만 뻐근하네요. 다음에 유사한 글을 쓸 일이 생긴다면 그 때에는 그림도 좀 그려 넣겠습니다.

긴 글 읽으셔서 수고하셨고 조금이나마 도움이 되셨기를 바랍니다.

 

22 thoughts on “[잡솔] 아이폰6, 아이폰6+의 해상도 2편 (디자이너의 작업)

  1. Pingback: [잡솔] 아이폰6, 아이폰6+의 해상도 | 이것저것 내돈주고 산 것들 간단 리뷰 블로그입니다.

  2. 제가 아이폰 디자인작업을 처음해서 급하게 자료를 찾고 있었는데 유용한 자료 공유주셔서 감사합니다.^^

    아이폰은 초보자라 질문을 드리자면

    위의 내용에 따르자면 디자이너는 풀사이즈(1242×2208)와 리사이즈한 1334, 1136 이 필요하다고 하셨는데

    각기 파일명은 어떻게 붙여야 하나요.

    자료를 찾아보니 이미지 파일명 뒤에 @2x @3x을 붙히던데요…  2208은 @3x을 붙히면 될 것 같은데

    1334, 1136 의 식별법이 궁금합니다.

    실례가 안된다면 답변부탁드립니다. ㅜ,ㅜ

    • 안녕하세요. 아이폰 4,5,6 은 동일한 x2를 사용합니다. 따라서 셋 다 @2X입니다. 그런데 세 폰의 해상도가 달라서 풀 이미지를 각각 쓴다면 파일을 세 개를 만들게 되겠죠. 여기서 중요한 건 1. 정말로 셋 다 각각 쓸 것인지 2. 아니면 하나만 만들어서 다같이 쓸지 이고 1번일 경우 결국 또 다른 파일 구분 방법이 필요한데 이건 개발에 물어보시는게 맞을 것 같습니다. 개발에서 임의로 처리하는거라…

  3. 디자인 가이드 작업시 궁금증 문의좀 드릴께요^^

    ios개발자가 아이폰 포인트단위를 써서 달라고 하는데

    듣기로는 iphone 6 plus (original) – 1242×2208 사이즈의 경우 픽셀을 1/3하면 pt단위가 된다고 들어서 그렇게 넘겼고 별문제없이 넘어갔는데 글을보다 의문이 들어서요…

    정확히 px단위의 pt단위의 변환 계산법이 어떻게 되는지 궁금합니다.

    • 앗! 정말 궁금했던 내용들이었습니다~~감사합니다^^

      그럼.. 현재 안드로이드 xxhdpi 작업을 했는데,

      이미지는 아이폰6플러스에서 동일하게 사용해도 될까요 ?

       

      • 박소희님// 1080×1920으로 디자인한 것을 6+에 대응하려면 1242×2208 로 키워서 저장하는게 가이드 작업이 쉬울 겁니다. (1/3 하면 되므로)

        단순 확대만 해도 상관없을 겁니다. 이미지의 퀄리티 측면에서는 6인치 폰에서 720×1280만 되어도 괜찮고, 어차피 폰에서 다시 리사이징을 해서 1920×1080로 보여줍니다.

        안드로이드는 DP로 가이드 작업을 하지만 아이폰에서는 point(원좌표)로 가이드 작업을 합니다. 그러기 위해서는 바로 아래의 댓글처럼 1242×2208 의 1/3 인 414×736 의 좌표처리를 해줘야 하는데 1920 해상도를 기반으로 하는 DPI에서 만든 이미지를 사용하려면 계산이 좀 복잡하겠죠. 복잡하지 않게 하려면 편법을 쓰는 수 밖에 없습니다. 강제적으로 FHD에서 1/2를 한다던가요.

    • jjh님 댓글을 굉장히 늦게 봤네요;; 

      말씀하신데로 가이드는 x1의 좌표단위를 사용합니다. 이 부분이 굉장히 중요한데 본문에 빠트렸네요;;; 그 단위가 point 입니다.

      그리고 계산법에 대하여 문의를 주셨는데 이미 jjh 님께서 말씀하신데로 1/3 하거나 1/2 하면 됩니다.

      아이폰4 320×480 (x2 = 640×960) -> 1/2

      아이폰5 320×568 (x2 = 640×1136) -> 1/2

      아이폰6 375×667 (x2 = 750×1334) -> 1/2

      아이폰6+ 414×736 (x3 = 1242×2208) -> 1/3

      px와 pt의 단위 계산 법은 어느 크기로 디자인을 했느냐에 따라 다릅니다. 벡터로 디자인했다면 처음부터 작은 크기로 디자인하여 1:1 로 px를 그대로 pt로 사용할 수 있을거고, 만약 750×1334로 작업했다면 1/2 하면 됩니다. FHD 로 작업했다면 그걸 1242×2208로 늘린 후 1/3 하거나 또는 750×1334로 만든 후 1/2 해야겠죠. (물론 비율이 약간 다른데 가로를 맞추고 세로는 대략적으로)

      (제가 순수하게 이 글에 달리는 댓글때문에 앱도 깔아놨는데 알림은 왜 안오는지;;;)

  4. Pingback: [잡솔] 아이폰6, 아이폰6+의 해상도 | 리뷰 블로그: 내돈주고샀다

  5. 장말 궁금한 내용이었습니다.

    그런데 아이폰의 폰트 단위도 pt로 사용하는 건가요??

    pt로 사용하면 폰트의 크기도 기종에 따라 2X, 3X가 되는건가요?? 

    • 제가 원글에 뒤늦게 pt를 넣으면서 그 부분이 좀 미묘해진 것 같습니다. 먼저 사과의 말씀을 드리고, 원론을 포함하여 좀 길게 답변을 달도록 하겠습니다. 답변만 하면 글은 간단하지만 그 원리를 이해하지 못 하면 언젠가 또 다른 일에 부딪힐 수 있으니까요.

      1. 폰트도 pt로 전달해야 하는가.
      -> 예

      사실 이런 질문이 안나와야 정상적인 글인데 질문을 하신 것을 보고 제 글을 다시 보니 pt를 제가 뒤늦게 넣으면서 그 의미를 정확하게 작성하지 못 했더라고요.

      우선 pt도 그 자체는 따로 보면 픽셀입니다. 하지만 pt는 DPI 개념의 픽셀이죠. DPI가 어려운 말일 수 있습니다. 다른 각도로 쉽게 말하자면 기준점이 있다는 이야기입니다.

      만약에 디자이너님께서 100픽셀짜리 이미지를 개발에게 전달했다고 생각해보세요. "이미지 얹어 주세요."

      그런데 그 100픽셀 이미지는 실제로 640×320폰과 1920×1080폰에서 몇 픽셀로 보여주어야 할까요? 어떻게 얹어야 할지 정확하게 전달이 되지 않습니다.

      "30픽셀짜리 폰트예요. 그냥 넣으시면 되는데…" 라고 말해봐야 먹히지 않습니다.

      왜냐하면 기준점이 없기 때문입니다. 디자이너 두 명이 최소 사이즈의 폰트 크기를 정한다고 상상해 봅니다. 그런데 한사람은 HD캔버스 사이즈로 디자인하고, 또 한 사람은 FHD캔버스 사이즈로 디자인을 했어요. 한사람은 20px로, 한 사람은30px로 디자인했죠. 그리고 개발에게 말합니다. 20픽셀인데요? 아닌데 30픽셀인데? 이런 상황이라는 거지요.

      디자이너가 작업한 캔버스가 만약에 2208이었다고 치면 100픽셀은 실제로 우리가 눈으로 봤을 때 작은  글자 크기입니다. 폰을 손으로 들고 화면을 눈으로 볼 때 세로 길이의 1/20 크기죠. 그런데 만약에 736에서 작업한 100픽셀이었다면 1/7 정도를 차지하는 크기입니다. 꽤 크죠.

      즉, 기본적으로는 디자이너가 캔버스 대비 px를 얼마로 잡았는가(기준점이 있죠), 그리고 나아가서 그것이 폰에서 얼마만큼의 크기로 보이는가가 pt입니다.(폰에서 얼마만큼의 크기로 보이는가에 대해서는 하단에서 설명)

      따라서 개발에게 전달하는 사이즈는 글꼴이나 다른 이미지들 모두 pt 단위입니다. 그러면 아하 6+에서는 60사이즈구나, 아하 6에서는 40사이즈구나 하고 답이 나오고 실제로 폰을 양 손으로 놓고 비교하면 동일한 크기로 보여진다는 이야기입니다.

      물론 "30픽셀이에요" 대신에 약간 업그레이드 해서 "FHD에서 30픽셀이에요." 라고 말 할 수 있죠. 네 이것은 말이 됩니다.

      A. 하지만 이렇게 정규 사이즈와 다른 사이즈로 작업하면 1334와 2208을 쓰는 아이폰6+로 컨버팅 시(즉 pt로 전환 시) 정수로 떨어지지 않을 수 있고
      B. 캔버스 사이즈는 만들때마다 다를 수 있어서 유지보수가 힘들어집니다. 어느 업체에서는 2208로 만들어왔고 2년전에는 내부에서 1334로 만들었고 지금 내부에서는 1920으로 작업했고 그럼 가이드마다 pt로 전환하는 방식이 다 다르겠죠.
      C. 완료된 작업물을 검수할 때에도 문제가 있습니다. 이거 몇 픽셀로 했나요? 개발자는 픽셀로 작업하지 않죠.


      2. pt로 제작하면 2x, 3x를 전달해야 하는가.
      -> 아니오

      제가 2x, 3x 가이드를 따로 전달해줘야 한다는 것은 사실 pixel 단위의 약간은 올드한 가이드입니다. 제가 너무 옛날에 작업을 해서 해당 내용을 쓸데 없이 주절주절 써놨습니다. (저는 개발에 ㄱ만 담궈본 사람입니다^^;) 

      pt에 대한 설명을 이해하셨다면 이상하다고 생각하셨을 겁니다. 아마도 그래서 질문을 주셨을 것 같습니다. 두 개로 가이드를 줘야 하는가? 왜냐하면 pt하나면 2x, 3x에서 동일하게 잘 보인다는 건데 가이드가 두 개라는게 이상하거든요.

      2x에서는 좌로부터 15픽셀 띄우시고요. 3x에서는 좌로 30픽셀 띄우세요. => 말 됩니다. 하지만 px단위는 사용하지 않죠.

      2x에서는 15pt띄우시고요. 그럼 3x에서는? 똑같이 15pt겠죠.

      따라서 가이드는 하나만 주면 됩니다.

      물론 여기에서 아 그렇구나 하고 끝나고 그냥 디자인하고 파일을 넘겨도 괜찮습니다만, 작업을 하다 보면 또는 생각을 계속 하다 보면 이상한 부분이 있을 수 있습니다.

      6와 6+을 비교해보면 픽셀이 정확히 일치하지 않는다는 부분이죠.

      아이폰6 375×667 (x2 = 750×1334) -> 1/2
      아이폰6+ 414×736 (x3 = 1242×2208) -> 1/3

      만약에 1334에서 40px로 작업했다면 20pt인데, 그럼 2208에서 20pt는 60px라는 의미거든요. 하지만 캔버스를 같은 크기로 리사이즈하면 서로 px가 다릅니다. 1334에서 40px는 사실 2000px에서 60px거든요. 그런데 2208에서 60px로 표시한다라? 더 작게 표시하는거 아닌가?

      실제로 더 작게 표시합니다. 그 이유는 6+의 화면이 5.5인치로 더 크기 때문이죠. 그래서 사용자가 눈으로 폰을 볼 때에는 더 크게 보여지고 결론적으로 같게 보여집니다.

      따라서 pt는 기준점이 있고, pt의 계산 법칙은 폰에서 얼마만큼의 크기로 보이는가 까지 염두해 두었다고 말했습니다.

      가이드는 하나만 있으면 되겠죠. 내가 어느 크기의 캔버스로 디자인하든 상관없이 pt는 한가지고, 그 한가지는 모든 폰에 적용됩니다.

      단, 디자인 파일 자체는 경우에 따라 2x,3x로 저장해야 할 수 있죠.

      답변이 되셨기를 바랍니다. 저도 글 내용을 전반적으로 수정해야 할 것 같습니다. 감사합니다.
       

  6. 현재 iOS 공부중인데 유익한 정보 공유해주셔서 너무 너무 감사합니다.

    다름이 아니라 .. 현재 제가 진행하고 있는 프로젝트 경우,
    iOS 개발자분이 FHD 가이드와 리소스만 전달해주면 문제되지 않다고 하는데..이해가되지 않습니다.
    가이드도 pt단위가 아닌 FHD에서 1:1비율의 px값을 전달 달라고 합니다.

    저의 입장에서는 안드로이드에서 사용한 FHD 디자인/가이드/리소스를 그대로 활용할 수 있어서 좋긴하지만
    현재 저희 iOS개발자의 말처럼 진행했을 때 문제될 것이 있을까요?

    • 개발자가 괜찮다고 하면 문제 없겠죠^^;

      FHD의 px 가이드 하나만으로 진행하는 경우가 저도 있었습니다. 요새 그렇게는 잘 안하는 듯 하지만 제 기억에는 px값을 주면 그걸 본인이 %로 환산하여 적용하더군요. 그럼 뭐 대략 다 맞겠죠.

      일반 모델과 플러스 모델에 대하여 각기 잘 대응하는지만 확인하면 될 것 같습니다.

  7. 모바일은 운영과 웹뷰로 구현하는 프로젝트만 해보다가 

    이번에 처음으로 네이티브 앱 리뉴얼프로젝트를 하는 PM겸 기획자 입니다.

    사내에 모바일관련해서 디자이너도, 개발자PM도 잘아는 사람이 없어

    디자이너 디렉션주는것도 어렵고… 개발쪽에 가이드 전달하는것도 너무 막막했는데 

    이글 보고 한단계 업그레이드된 느낌입니다!! 정말 공들여서 정독했네요…

    너무너무 감사합니다~~^^*

    • 부족한 글이지만 도움 되셨다니 다행입니다.

      언젠가 그림포함해서 새로 올려야지…생각만 하고 있습니다.^^;;

      프로젝트 잘 진행하시구요~

  8. Pingback: MOBILE | katekim

  9. Pingback: MOBILE – kate kim

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.