플랫폼 가이드라인

스마트폰이 퍼지기 시작한 무렵, 회사들은 같은 앱을 아이폰과 안드로이드에 동시에 내놓아야 했습니다. 화면은 한 벌만 그렸습니다. 두 번 그릴 사람도 시간도 없었고, 같은 제품이면 같은 모양이어야 한다고 여겼기 때문입니다.

그렇게 내보낸 앱에서 사용자들은 같은 자리에서 같은 식으로 막혔습니다. 안드로이드 사용자는 화면 왼쪽 위 화살표를 누르는 대신 기기 아래쪽 뒤로 가기 버튼을 눌렀고, 그러면 한 단계 뒤로 가는 대신 앱이 통째로 닫혔습니다. 아이폰 사용자는 화면 맨 아래에 있으리라 기대한 메뉴 막대를 찾다가 왼쪽 위 구석의 줄 세 개짜리 아이콘을 지나쳤습니다. 공유 아이콘도 한쪽은 상자에서 화살표가 빠져나오는 모양, 다른 쪽은 점 세 개를 선으로 이은 모양이라 어느 한쪽을 골라 양쪽에 쓰면 절반의 사용자는 그것이 공유 버튼인 줄 몰랐습니다.

고객센터에 들어온 문의는 대개 "버튼이 없어요" 였습니다. 버튼은 있었습니다. 그 사람이 매일 쓰던 다른 앱들과 다른 자리에 있었을 뿐입니다. 사람은 앱 하나를 따로 배우지 않고 손에 든 기기를 배웁니다. 하루에 앱 열 개를 쓰는 사람에게 열한 번째 앱만 규칙이 다르면, 사용자가 보기에 틀린 쪽은 그 한 개입니다.

문제는 심사에서도 걸렸습니다. 앱을 내려받는 장터를 운영하는 쪽이 곧 운영체제를 만든 쪽이라, 등록 심사에서 반려 사유로 화면 설계가 지목되는 일이 생겼습니다. 출시 날짜를 잡아 둔 팀이 반려 메일 한 통에 일정을 2주 미루는 일이 반복되자, 무엇이 반려 사유인지를 미리 알아야 할 이유가 생겼습니다.

규범이 필요한 곳은 손에 드는 기기만이 아닙니다. 데스크톱에서도 창을 닫는 단추가 맥에서는 왼쪽 위, 윈도우에서는 오른쪽 위에 있고, 설정 창을 여는 자리도 서로 다릅니다. 한 회사가 만든 운영체제 위에서 도는 프로그램이 수십만 개라면, 그 사이에서 사용자가 옮겨 다닐 때 배운 것을 다시 쓸 수 있어야 한다는 요구는 똑같이 생깁니다.

그래서 운영체제를 만든 회사들이 자기 플랫폼에서 앱이 어떻게 생겨야 하는지를 문서로 공개했습니다. 어느 자리에 무엇을 두고, 터치 영역은 몇 밀리미터 이상이어야 하고, 어떤 상황에 어떤 종류의 알림을 띄우는지가 그림과 함께 적혀 있습니다. 앱을 만드는 쪽에서 보면 취향 문제로 길어지던 논쟁 하나가 줄어듭니다. 삭제 확인 창을 화면 가운데에 띄울지 아래에서 올릴지를 두고 팀이 한 시간 토론하는 대신, 이 플랫폼에서는 아래에서 올린다는 문장을 찾아 따르면 됩니다.

플랫폼 가이드라인 아래 묶인 용어는 두 갈래입니다. 플랫폼이 직접 써서 내놓은 문서(가이드)와, 그 문서가 답을 주지 않는 자리에서 무엇을 먼저 보장할지 정하는 사고방식(원칙)입니다.

가이드는 규범을 만든 주체로 갈리고 두 자리가 있습니다.

1. 머티리얼 디자인 — 구글이 2014년에 내놓은 체계입니다. 화면 요소를 종이 조각으로 보고 그림자의 깊이로 위아래 층을 나타내는 것이 출발점이라, 떠 있는 카드와 그 위를 덮는 창이 한눈에 구분됩니다. 오른쪽 아래에 떠 있는 동그란 주 동작 버튼, 화면 아래쪽에서 잠깐 올라왔다 사라지는 안내 막대, 누른 자리에서 물결이 번지는 반응이 여기서 나왔습니다. 안드로이드용으로 시작했지만 색과 글자 크기와 간격에 이름을 붙여 웹에서도 쓸 수 있게 열어 둔 덕에, 안드로이드 앱이 아닌 제품에서도 이 체계를 그대로 가져다 쓰는 경우가 많습니다. 최근 판에서는 사용자가 배경화면으로 고른 사진에서 색을 뽑아 앱 전체 색을 맞추는 방식까지 들어갔는데, 이 말은 우리가 정한 색이 기기에서 다른 색으로 보일 수 있다는 뜻이기도 합니다.
2. 휴먼 인터페이스 가이드라인 — 애플이 내놓은 규범이고 줄여서 HIG 라고 부릅니다. 아이폰·아이패드·맥·워치처럼 기기마다 장이 따로 있는데, 같은 회사 제품이라도 손가락으로 만지는 화면과 마우스로 가리키는 화면은 필요한 것이 다르기 때문입니다. 아래쪽 탭은 다섯 개까지, 누를 수 있는 영역은 한 변이 44포인트 이상, 뒤로 가기는 왼쪽 위 같은 수치와 위치가 문장으로 못 박혀 있습니다. 어두운 배경으로 바꾼 사용자와 글자 크기를 키워 둔 사용자에게 화면이 어떻게 보여야 하는지도 따로 다룹니다. 앱 장터 심사 기준이 이 문서를 근거로 삼기 때문에, 여기 적힌 것 중 일부는 권고가 아니라 사실상 통과 조건입니다.

문서를 쓰는 방법은 셋 중 하나입니다. 화면을 그리기 전에 그 기능에 해당하는 장을 찾아 읽는 것이 첫째이고, 시안 리뷰에서 배치를 두고 의견이 갈릴 때 근거로 인용하는 것이 둘째입니다. 셋째는 운영체제가 새 버전을 낼 때마다 바뀐 항목만 훑는 것인데, 해마다 한 번씩 부품의 기본 모양이나 권장 배치가 조용히 바뀌기 때문입니다. 세 방법 모두 문서를 처음부터 끝까지 읽는 일과는 거리가 멉니다. 사전처럼 필요할 때 펴 보는 물건에 가깝습니다.

두 문서를 나란히 놓으면 같은 기능이 다른 모양으로 갈리는 자리가 보입니다. 문서를 삭제하겠냐고 묻는 창을 아이폰에서는 화면 아래에서 밀어 올려 보여 주고, 안드로이드에서는 화면 가운데에 띄웁니다. 앱 안의 화면 이동도 아이폰은 왼쪽 가장자리에서 오른쪽으로 쓸어 돌아가고, 안드로이드는 기기 자체의 뒤로 가기 동작을 받습니다. 그래서 두 플랫폼에 같은 기능을 내려면 기획은 한 벌로 쓰되 화면은 두 벌을 그리게 됩니다. 어느 쪽에도 없는 우리만의 방식을 만들면 양쪽 사용자가 모두 헤맵니다.

원칙은 환경 차이를 다루는 방향으로 갈리고 두 자리가 있습니다.

1. 프로그레시브 인핸스먼트 — 가장 열악한 환경에서 되는 것을 먼저 완성하고, 여유가 있는 환경에서만 기능을 얹습니다. 문서 목록을 예로 들면 느린 회선에서도 글자와 링크만으로 목록이 뜨게 만들어 놓고, 화면이 넓고 최신 브라우저인 경우에만 미리보기 이미지와 실시간 갱신을 더합니다. 바닥이 먼저 서 있으므로 위에 얹은 것이 빠져도 제품은 계속 돌아갑니다.
2. 그레이스풀 디그러데이션 — 반대 방향입니다. 가장 좋은 환경을 기준으로 만든 다음, 그것이 안 되는 환경에서 무엇을 남길지 정합니다. 여러 사람의 커서가 문서 위에 실시간으로 보이는 기능이 구형 브라우저에서 안 돌아간다면, 화면을 깨뜨리는 대신 커서만 감추고 읽기와 저장은 그대로 되게 두는 식입니다.

둘은 끝 모습이 비슷해 보여도 정하는 순서가 다릅니다. 앞의 것은 무엇을 반드시 보장할지를 먼저 정하고, 뒤의 것은 무엇을 포기해도 되는지를 나중에 정합니다. 새로 만드는 화면에는 앞의 것이, 이미 만들어 둔 것을 넓은 환경으로 넓힐 때는 뒤의 것이 손에 맞습니다.

두 갈래는 한 줄로 이어집니다. 가이드는 플랫폼이 미리 내놓은 답이라 그 안에서는 고민할 것이 없지만, 문서가 다루지 않는 자리가 항상 남습니다. 3년 된 보급형 기기, 지하철에서 끊기는 회선, 글자 크기를 두 배로 키워 둔 설정 같은 것들입니다. 원칙은 그 자리에서 무엇을 먼저 세울지 정하는 기준이고, 결과적으로 장애나 상황과 무관하게 제품이 작동하게 만드는 접근성 작업과 같은 곳에서 만납니다. 두 갈래를 회사 안에서 다시 쓸 수 있게 부품과 값으로 묶어 두면 디자인 시스템이 됩니다. 플랫폼별로 갈리는 부분은 UI 컴포넌트를 두 벌로 만들어 두고, 갈리지 않는 색과 문구는 한 벌만 둡니다.

"이 화면 iOS 가이드라인이랑 안 맞아요. 뒤로 가기가 오른쪽 아래에 있으면 아이폰 쓰는 사람은 못 찾습니다."

우리 팀이 고른 배치가 그 기기 사용자의 몸에 밴 습관과 어긋난다는 지적입니다.

"안드로이드는 머티리얼 부품 그대로 쓰고, 색이랑 문구만 우리 걸로 입히죠."

플랫폼이 준 것을 가져다 쓰되 브랜드가 드러나는 얇은 층만 덧입히자는 제안입니다.

"이건 위반은 아니고 권고예요. 심사에서 막히진 않습니다."

가이드라인 안에서도 지키지 않으면 출시가 멈추는 항목과 안 지켜도 되는 항목이 갈린다는 구분입니다.

페이지덱이 웹으로만 쓰던 협업 문서를 모바일 앱으로 내놓기로 한 분기에 이 말이 가장 많이 오갔습니다. 민서가 웹 화면을 그대로 줄여 시안을 만들어 왔고, 문서 오른쪽 위에 있던 공유 버튼이 앱에서도 오른쪽 위에 놓여 있었습니다. 태오가 그 자리를 짚으며 아이폰에서는 오른쪽 위가 편집 완료 자리라고 말했습니다. 사용자가 공유하려다 편집을 끝낼 확률이 높다는 뜻이었습니다.

둘은 화면을 두 벌로 갈랐습니다. 공유는 아이폰에서 아래 탭 옆의 공유 아이콘으로, 안드로이드에서는 오른쪽 위 점 세 개 메뉴 안으로 들어갔습니다. 지현이 그러면 사용자 안내 문서도 두 벌이 되는지 물었고, 답은 화면 그림만 두 장이고 글은 한 벌이라는 것이었습니다. 어느 플랫폼에서든 공유 버튼을 누른 다음의 흐름은 같게 두기로 했기 때문입니다. 버튼이 어디 있는지는 기기가 정하고, 버튼을 누른 뒤에 무엇이 벌어지는지는 제품이 정한다는 선을 그은 셈입니다. 이 선은 나중에 새 화면을 그릴 때마다 같은 질문을 다시 하지 않게 해 주었습니다.

가이드라인을 따르면 앱이 다 똑같아진다고 여기는 경우가 가장 많습니다. 정해진 부품을 그대로 쓰라는 말로 읽히니 그럴듯합니다. 하지만 문서가 정하는 것은 주로 뼈대입니다. 무엇이 어디에 있고 누르면 어떻게 반응하는지는 정해 주지만, 색과 서체와 이미지와 문구는 거의 비워 둡니다. 실제로 같은 플랫폼 위에서 도는 앱들이 서로 전혀 다르게 보이는 이유가 여기 있습니다. 이 오해를 그대로 두면 팀은 구분을 만들려고 뼈대를 건드립니다. 남들과 달라 보이려고 탭 막대를 화면 위로 올리고 뒤로 가기를 오른쪽에 두는데, 얻는 것은 개성이 아니라 첫 사용 이탈입니다. 브랜드를 드러낼 자리는 비워 둔 쪽입니다.

가이드라인이 지켜야 할 규칙의 목록이라고 읽는 것도 흔합니다. 심사 반려라는 말이 붙어 있으니 전부가 통과 조건처럼 보입니다. 실제로는 강제와 권고가 한 문서 안에 섞여 있고, 강제에 해당하는 항목은 결제 흐름이나 개인정보 접근 권한처럼 수가 많지 않습니다. 나머지는 "이렇게 하기를 권합니다" 에 가깝고, 제품 성격에 따라 어기는 편이 나은 경우도 있습니다. 둘을 구분하지 않으면 두 방향으로 손해를 봅니다. 전부를 강제로 읽는 팀은 자기 제품에 맞지 않는 배치까지 그대로 베껴 쓰고, 전부를 권고로 읽는 팀은 출시 전날 반려 메일을 받습니다. 새 플랫폼에 처음 앱을 내는 팀이라면 문서에서 "must" 와 "should" 가 갈리는 지점을 한 번 훑어 두는 편이 안전합니다.