모바일 개발자와 디자이너가 함께 일하는 법 (1)

개발자는 왜 공수가 더 필요하다고 하는걸까?

*지극히 개인적인 경험을 담았습니다.

첫 직장에 취업하기 전까지 개발자 라는 직군을 마주한 적이 없었다. 디자인 결과물은 늘 UI 화면에서 그쳤고, 프로토타입을 만드는게 내가 아는 가장 고도화된 방법이었다. 첫 입사 후, 만난 개발자들은 상당히 다른 느낌이었다. 코드를 쓰고, 코드로 말하는 직업. 사용하는 용어부터 바라보는 관점까지 모든게 달랐고 서로를 이해하는데 많은 시간이 걸렸다. 개발자와 복작복작 일한지 벌써 4년차, 개발자가 주로 디자이너에게 말하는 것들을 정리해본다. 

공수(맨먼스)가 더 들어요. 

일정을 정리할 때면, 공수에 대한 이야기 빠질 수 없다. 스프린트 계획회의 마다 개발자들은 얼마나 일정이 더 필요한지 이야기한다. 결국 일정 앞에서 많은 욕심을 깎아내곤한다. 공수, 왜 더 드는 걸까? 

           

1. 새로운 뷰를 만들어야 합니다.                    

디자인에서 같은 뷰를 만드는건 그리 어렵지 않다. 개발도 같은 뷰를 쓰면 되지 않을까..? 라고 생각했지만 문제가 있었다. 디자인에서는 control c+v로 만들면 되지만, 조금이라도 구조나 동작이 달라지는 순간 개발자 입장에서는 완전히 새로운 뷰가 필요하다. 

2. 다국어만 다르게 처리하긴 어려워요

한국에서만 사용하는 서비스가 아니면 대부분 다국어를 버릴 수 없다. 다국어를 대응하기 시작하는 순간 최소 2벌을 고려해야한다. 우리 회사 서비스의 경우, 일본어와 영어를 기본적으로 대응하고 있다. 영어는 기본적으로 우리나라 말보다 1.5배 정도 길다. 같은 말이어도 길기 때문에 어떻게 처리해야할지 미리 고려해야한다. 특히 어려운 지점은 갤럭시 폴드와 같이 가로폭이 좁은 해상도를 대응할 때다. 이 때 대응하는 방법은 크게 3가지로 요약할 수 있다.
 

말줄임 처리 해주세요.
 말줄임처리는 대개 중요하지 않은 정보에서 사용된다. 하지만 말줄임 될만큼 중요하지 않은 정보를 프로덕트에 담는일도 없거니와, 앱에서 어떤 정보가 말줄임 된다고 생각하면 완성도가 훅 떨어져 보일 수 밖에 없다. 따라서 말줄임은 정말로 발생하기 어려운 케이스(예를 들면 한국 사람 이름이 50자가 넘는다거나..)를 대응하기 위해 만든다.
 

글자포인트 줄여서 대응해주세요.
 가장 많이 쓰는 방법 중 하나인 글자포인트 줄이기. 예를 들면 아이콘에 붙는 메뉴명과 같이 가로 영역이 한정된 케이스의 경우, 해당 영역을 벗어나지 않으면서 정보를 읽게끔 만드는 일이 중요하다. 따라서 나는 글자 포인트를 줄여서 대응해달라고 부탁한다. 예를들면 ‘장바구니’라는 메뉴명이 있는데, [장바구니]의 폰트를 1pt씩 줄여서 [shopping bag]을 같은 공간안에 노출하는 것이다. 물론 전체적인 레이아웃이 아쉬울 수 있지만, 늘 사용성이 1순위임을 명심하자. 보이지 않는 글자 앞에선 아무리 예쁜 디자인이어도 의미가 없다.

 줄바꿈 해주세요.
주로 리스트, 툴팁 등 줄글을 작성하는 영역에 많이 사용한다. 피그마의 Auto layout을 적용한 것처럼, 글이 길어지면 자동으로 다음줄로 넘어가게끔 처리하기. 이 방법도 가변이 많은 영역에서는 좋은 방식이다. 하지만 문제가 있다면 web에서 사용하는 word-break(단어 단위 끊기)가 os에서는 어렵다는 점이다. 그래서 대개 음절 단위로 줄바꿈되어, 우리가 견디지 못하는 아버지<br>가 방에 들어가셨다. 와 같은 문제가 생긴다. 방법을 찾아달라거나, 커스텀을 요청할 수도 있지만 대개는 마이너한 이슈가 되어 처리하기 어렵다. 수 많은 중요한 문제 앞에서 소수의, 그것도 특이 케이스를 대응해달라고 요청하기란 참 어렵다. 

3. 디바이스 대응 필요한가요?

웹은 디바이스 대응을 크게 하지 않는다. 브레이크 포인트 정도만 잡으면, mobile web, tablet, web을 모두 대응할 수 있다. 하지만 네이티브는 많은 세계가 있고, 그들의 화면에서 모두 잘 나오게끔 하려면 화면별 대응은 필수다. 우리 회사 같은 경우는 OS별로 각각 3개의 해상도를 대응한다. 3개의 해상도에서 3개의 언어로 확인을 하다보면 분명 이슈가 생긴다. 이를 미연에 방지하기 위해, 아름답진 않더라도, 작은 화면에서 어떻게 해상도가 보여져야하는지 체크가 필요하다. 그렇지 않으면, QA때 갑자기 특정 디바이스에서 엉망진창인 UI의 모습을 볼 수 있다. 

4. 컴포넌트 갖다 쓸 수 있나요?       

        
디자이너도 컴포넌트가 있으면 작업을 하기 수월하듯이, 개발자도 마찬가지다. 이전에 썼던 UI가 있으면 그대로 사용하는게 제일 편하다. 그렇기에 작업을 할 때 중구난방인 컴포넌트들이 산재해 있으면 결국 시간이 더 들 수 밖에 없다. 이를 위해 사내에서도 디자인 시스템을 만들기 위해 노력하고 있다. 반복적인 작업을 줄여서, 한정된 스프린트 내에 더 많은 작업을 소화할 수 있도록 만드는게 목표다.

디자인시안하고 실제 개발 화면 간격이 다르네요.

1. 폰트의 높이, 그것은 허상?

웹의 경우에는 폰트를 선언할 수 있다. 우리 회사는 기본 서체를 Noto sans kr과 Inter로 지정해서 사용하고 있다. 그렇다면 네이티브도 폰트 선언을 할 수 있지 않을까? 선언은 가능하다. 다만 문제가 있다. 안드로이드의 경우, 사용자가 직접 서체를 지정해서 사용할 수 있다. 그렇기에 내가 선언하는 폰트는 결국 무의미해진다. ‘이렇게 나올 것이다.’를 예상하는 의미가 없어진다. 우리 서비스의 경우에는 기본 폰트를 사용한다. android는 noto sans KR, ios는 apple sd gothic. 디자인 시안에서는 폰트가 약간 올라가보인다. 아마도 폰트가 갖고 있는 고유의 높이가 영향을 미치는 듯하다. 하지만 개발 상에서는 그렇지 않다. 폰트의 높이는 폰트의 1배, 즉 그 자체가 높이값이 된다. 따라서 디자인 시안에서 약간 어긋나보여도 오히려 개발에서는 정중앙에 위치하게 된다.

2. 해상도에 따른 간격의 의미

                         

안드로이드는 SP와 DP로 글자를 나눈다. DP는 고정폰트다. 안드로이드의 경우(ios도 그렇지만), 사용자가 핸드폰에서 글자의 크기를 늘려서 볼 수 있다. 대개는 40대 이상의 중장년층의 핸드폰에서 많이 볼 수 있다. 특히 노년층에서는 정말 큰 크기로 키워서 사용하는 경우가 있다. 이 때, DP로 폰트를 고정하게 되면 우리 서비스는 아무리 사용자가 기본 글자크기를 키워도 보여지는 폰트의 크기는 동일하다. 반면 SP는 유동적 폰트다. 사용자가 글자 크기를 키우는 만큼 더욱 커진다. 디자이너는 DP를 선호할 수 밖에 없다. 디자인이 깨지지 않고 잘 나왔으면 좋겠으니까. 하지만 분명 SP가 필요한 영역이 있다. 우리는 사용자를 대변하는 입장이고, 그 사용자에는 폰트를 크게 쓰는 사람도 분명 포함되어있다. 따라서 접근성을 고려하여 곳곳에 SP 를 사용하는게 좋다.

             

(최대 너비를 지정하지 않으면 넓은 화면에서는 이렇게 보이는 참사가 발생한다.)

3. 안드로이드 개발자는 최대너비가 궁금하다.

                          

ios의 기종은 비교적 적고, 해상도가 엄청 다양하지 않아서 대부분 1벌로 대응이 된다. 하지만 aos의 기종은 상상을 초월한다. 지플립(Z Flip)부터 폴드(Galaxy Fold)까지. 최대 너비를 설정하지 않으면 폴드에서는 정말 넓-게 나온다. 그래서 대부분의 콘텐츠는 최대 너비가 필요하다. 내가 가로 360 사이즈의 디바이스만 디자인 했다고 해서, 사람들은 360 사이즈만 사용하는게 아니니까.