네이티브 앱 꼭 만들어야 할까?
UI/UX 디자이너가 생각하는 네이티브 앱의 필요성
취조실 같은 회의실에서 클라이언트가 한없이 착한 눈으로 제게 질문을 해옵니다.
"앱까지 만들면 견적이 얼마나 나올까요?"
순간 머릿속에서 짱구가 굴러다닙니다. 단순 회사 소개 웹사이트를 만들려는 양반이 액션가면도 아닌 앱을 만들어 달라니... 그의 무지함을 이용해 회사에 쏠쏠한 이득을 챙겨줄 궁리를 하니, 입꼬리가 올라가다 이내 콧잔등이 간지러워집니다.
믿기 힘들겠지만 저는 거짓말을 하면 코가 길어지...회사에 귀속된 디자이너이기 이전에 저도 사람이다 보니, 클라이언트를 벗겨먹는 걸 포기합니다. 착하게 살아야죠. 무지한 클라이언트에게 견적의 몽둥이가 아닌 당장 앱 제작이 필요 없다는 말을 휘두릅니다. 그렇게 오늘의 견적 뻥티기도 실패했습니다. 이런 성격 때문에 제 사업을 말아먹은 경험이 있습니다.
소규모 에이전시나 인하우스를 전전하다 보면 위와 같은 상황을 자주 경험합니다. 클라이언트뿐만 아니라 실무 중인 임직원들도 비슷한 소리를 합니다. 앱 디자인까지 하게 되면 제 작업량이 늘어나니 설득을 하게 됩니다. 역시나 오늘도 초심자를 위해 최대한 쉽게 풀어써봅니다. 부디 글을 읽는 모든 분들께 퍽퍽하지 않고 연한 글이 되길 바라봅니다.
그 설득으로 함께 빠져들어 보겠슴다애플리케이션 대충 알아보기
먼저 디자인 실무에 필요한 수준의 지식만 알아봅니다. 앱이라는 명칭보다는 애플리케이션이 온전한 표현입니다. 어플리케이션 또는 어플이라고도 합니다. 비개발집단인 일반 사용자들에겐 '앱'이라는 표현이 익숙하죠. 대개의 경우. 앱이라 떠들면 모바일 바탕화면에 깔려 있는 것들을 상상하지만, 이보다는 복잡합니다. 윈도우 애플리케이션, 웹 애플리케이션, 모바일 애플리케이션 등으로 나뉘고 개발방식에 따라 다시 세분화됩니다. 아래부터는 모바일 애플리케이션에 속한 것들에 대해 주로 이야기하고 가급적 앱이라는 표현을 사용합니다. 손가락이 아파서요.
네이티브, 하이브리드, 크로스 플랫폼의 삼파전위 그림처럼 개발방식에 따라 3가지로 나뉩니다. 네이티브, 하이브리드, 크로스 플랫폼. 이해를 돕기 위해 조금은 극단적으로 설명해봅니다. 네이티브는 모바일 게임이나 카메라 앱을 상상하면 이해가 쉽습니다. 하이브리드는 네이티브 안에 웹이 섞여있는 형태입니다. 크로스 플랫폼은 상대적으로 나중에 등장했는데 아래에 각각을 비교해가며 더 알아봅니다. 유사하며 좋은 글은 이미 많으나, 디자이너 관점에서 몇 가지 사견을 섞어 적어봅니다. (사실 우리에게 중요한 건 어떻게 개발하냐가 아닙...)
네이티브 앱 개발
디자이너인 우리에게 누군가 앱 개발을 이야기하면 보통은 네이티브 앱입니다. 가장 먼저 떠오르죠. 모바일 기기가 가진 모든 기능을 가장 원활하게 사용할 수 있으며, 인터넷 연결 여부(오프라인 시)에도 상관없이 작동시키기 용이하다는 장점을 지니고 있습니다. 문제는 프로젝트 진행 시 투입되는 인력과 개발 시간이 다른 방식에 비해 비싸고 오래 걸린다는 겁니다. 보통 안드로이드 개발자와 iOS 개발자가 있어야 하고, 웹 실무처럼 중간에 퍼블리셔라는 포지션은 없습니다. 앱 개발자의 실력이 곧 프로젝트의 성패를 좌우할 만큼 의존도가 커집니다.
카메라, 전화번호부, 저장공간, GPS 등 기타 하드웨어적인 이득을 자유롭게 취하면서, 기능이 많고 복잡한 형태의 앱 구축이 목적이라면 아직까지는 대안이 없는 최선의 선택이라 생각하고 있습니다. 안드로이드와 iOS 개발자를 상대하면서 시안을 각각 만들어야 합니다. 서로가 말하는 UI명칭도 다르고, UX관점도 다릅니다. 대부분 그랬습니다. 물론 안드로이드와 애플은 서로 다른 사용자 환경을 지니고 있고, 각 UX를 고려해 UI를 만드는 것이 맞지만 확실히 에너지 소모가 큽니다.
콘텐츠 영역에 웹을 재활용한 하이브리드 앱 개발 (네이버 앱)하이브리드 앱 개발
모바일 앱에 포커스를 맞춘 프로젝트가 아니라면 국내에선 일반적으론 모두 웹서비스를 우선 구축합니다. 가능하면 반응형으로 말이죠. 하이브리드는 이렇게 만들어 놓은 웹서비스 또는 페이지를 스토어에 등록, 사용자가 이용할 수 있도록 네이티브로 한번 감싼 형태로 이해하는 게 도움이 됩니다. 부분적으로 네이티브 기능을 활용하고, 딱히 네이티브로 개발이 필요하지 않은 부분은 웹 쪽 생산물을 재활용합니다.
때문에 규모가 크지 않고 복잡하지 않는 앱 구축에 적합하며, 고급 앱 개발자 없이도 앱을 개발을 할 수 있습니다. 개발기간과 비용을 줄일 수 있죠. 디자인 작업 범위 또한 축소됩니다. 네이티브 개발에 필요한 부분적인 UI작업만 해주면 되니까요. 기능보다 콘텐츠가 중심이 되는 제품에 어울리며, 통상 웹의 비중이 높아 업데이트 시(유지보수) 용이합니다. 소규모 웹 에이전시에서 앱 구축 시 주로 택하는 방식이고, 이때 앱 개발은 외주로 건 바이 건 처리하는 경우가 많습니다.
크로스 플랫폼 앱 개발
리액트 네이티브(React Native), 플루터(Flutter)와 같은 프레임워크가 실무에 자리 잡으면서 최근 주목하고 있는 개발 형태입니다. 가장 최신 기술이라 표현해야 할까요? 사무실에 플루터나 리액트 네이티브를 다루는 프런트엔드 개발자가 있다면, 어쩌면 앱 개발자는 따로 없을 수도 있습니다. 그들만으로도 앱 생산이 가능하니까요. 네이티브만큼 모든 기능/하드웨어를 활용할 순 없지만 빠르게 진화하고 있고, 꽤 유연한 개발이 가능해집니다.
한 번의 개발로 안드로이드와 iOS 앱 구축을 할 수 있다는 장점으로, 디자인 역시 하나의 시안으로 대응이 가능해집니다. 물론 안드로이드, 애플의 사용자의 UX를 고민한다면 따로 만들어야겠지요. 대표적으로 페이스북이 크로스 플랫폼 방식으로 개발되었고, 알리바바도 마찬가지입니다. 코드 푸시로 업데이트 또한 용이하고, 개발기간도 상대적으로 단축시킬 수 있다는 장점이 있으나 리액트 개발자들의 몸값이 많이 올랐습니다. 네이티브나 웹 개발자에 비해 사람 구하는 게 쉽지 않고, 실무에 적용된 게 그리 오래되지 않아 다양한 경험을 지닌 숙련 개발자들을 찾는데도 어려움이 따릅니다.
PWA 앱 개발(Progressive Web App)
위 3가지의 형태와는 조금은 성격이 다른 것입니다. 하이브리드와 비슷해 보이지만, PWA는 웹에 가깝습니다. 이름 그대로 기존 웹에서 조금 진보된 형태의 개발이니까요. 스토어를 거쳐서 설치되는 형태가 아니라 웹서비스에 접속해 '바탕화면에 아이콘 추가'등으로 사용자 유입을 지속시킵니다. 브라우저 캐시를 활용해 오프라인 상태에서도 사용자에게 페이지를 보여줄 수 있고 카메라, GPS 등 네이티브에서 가능한 몇 개의 기능 활용도 가능합니다. 알림(푸시) 기능도 사용할 수 있습니다만 아직까지는 iOS 지원이 부족하다는 단점도 지니고 있습니다.
웹 개발자만 있다면 가능한 개발 형태이며, 예산 부족 또는 기존 웹으로만 서비스를 운영해오던 제품이라면 추가로 시도해보는 걸 추천합니다. 난이도가 그리 높지 않거든요. 언젠가 모든 웹 프로젝트는 PWA가 되어있을지도 모릅니다. 기본으로 자리잡기를 바라고 있습니다.
정리하며
언젠가부터 사업을 시작하면 그게 무엇이건 웹사이트와 모바일 앱이 반드시 함께 준비되어야 한다는 인식이 생겨났습니다. 제품의 성질이나 서비스를 자세히 살피지 않고, 웹과 앱을 함께 구축해야 성공에 가까워진다는 검증되지 않은 믿음 같은 게 생겨났죠.
"바탕화면에 아이콘이 깔려 있어야 사용자를 지속적으로 유입시킬 수 있다."라고 떠들며 '접근성'이라는 단어를 들먹입니다. 참 이상하죠? 제가 생각하는 접근성이라는 단어는 그보다 포괄적인데 말이죠. 되려 묻게 됩니다. "당신은 바탕화면에 널려있는 모든 앱을 매일 사용하나요?"라고 말이죠.
아직 제품의 가치를 검증받기 전이거나, 네이티브에서만 얻을 수 있는 특별한 기능이 필요한 제품이 아니라면 굳이 앱 개발에 비용과 시간을 투자해가며 비효율적인 생산을 하는 게 타당하냐 묻는 거죠. 단적인 예를 들어보죠.
쇼핑몰을 하나 만든다 칩니다. 웹 구축이 완료된 후 우리에게 약 1억 가량의 예산이 남아있다면, 그 돈으로 앱을 만드는 것보다 웹에 집중하고 예산을 마케팅으로 돌려 지속적인 홍보를 시도하는 게 바람직하다 보는 겁니다. 네이티브의 기능이 필요치도 않고, 1억으론 앱 개발팀을 꾸릴 수도 없습니다. 장기적인 측면에서 혹자가 떠드는 접근성보단 사용성이 더 가치 있고, 접근성이라는 단어는 그렇게 쓰라고 나온 게 아닙니다.
"성격 급한 사용자가 언제 검색하고 URL 입력해가며 서비스에 접근하는 것보다 바탕화면에 아이콘 한번 누르는 게 낫지 않냐?"라는 물음. 네. 맞는 말입니다. 헌데 이게 어느 제품에나 먹히는 무적의 논리는 아니라는 거죠. 한정된 예산과 시간, 준비된 개발 인력 범위를 따져 보다 효율적인 방법을 찾는 게 타당한 거죠. 돈과 시간이 남아도는 자가 아니라면 말이죠. 네이티브가 가진 속도의 장점이요? 또 외국 아티클을 보고 와서 떠드는군요. 빠른 인터넷 속도를 가진 한국에서는 예외로 봐야 하는 장점입니다. 이미지, 영상, 데이터 등 웹서버에서 당겨다가 사용자에게 뿌려줘도 네이티브 앱과 큰 차이가 없습니다. 차라리 그로 인해 발생하는 트래픽 비용을 문제로 들먹이세요.
모든 사용자가 앱을 필요로 하거나 원하지는 않습니다. 웹만으로 구현된 서비스나 제품이 사용자에게 좋은 평가를 받으며, 승승장구하기도 합니다. 당장 우리가 할 수 있는 게 무엇인지, 사용자가 필요로 하는 게 무엇인지. 만들고 있는 서비스를 자세히 들여다보고, 그 성격을 잘 이해해 제품을 만들어내는 게 낫습니다.
라면을 먹는데 젓가락이 아닌 좋은 숟가락을 놓으려 하지 마세요. 나무젓가락만 있어도 충분합니다.
