프로덕트 디자이너의 개발지식 넓히기 : 앱 내 웹뷰
네이티브, 웹뷰(인앱브라우저), 기본 브라우저의 차이
지금부터 여러분들에게 비밀 하나를 알려드리겠습니다.
프로덕트 디자이너 중에서도 잘 모르시는 분들이 꽤 계실 거예요. 그건 바로… 앱 안에는 ‘진짜 앱’으로 구현된 화면이 몇 없다는 사실입니다.
오히려 100% 앱으로만 구현되어 있는 서비스를 찾는 게 더 어려울 정도예요. 깜짝 놀라셨죠? ㅎㅎ
링크드인의 피드를 둘러보다가 누군가가 공유한 아티클을 클릭해서 보신 적 있으신가요?
글을 읽다가 상단의 뒤로 가기 화살표를 누르면 다시 링크드인 피드로 돌아갈 수 있기 때문에 여전히 링크드인 앱 안에 있다고 생각하실 거예요.
네, 여전히 링크드인에 계신 게 맞아요. 하지만 아티클을 보여주는 그 페이지는 정확히 말하면 링크드인 앱 화면이 아니라 웹뷰입니다. 두 화면은 아예 다른 언어로 개발되었어요.
이렇게 하나의 APP에 네이티브와 웹뷰가 혼용되어 있는 앱을 하이브리드 앱(Hybrid App)이라고 합니다.
그런데 대체 왜 이렇게 복잡하게 섞어서 만드는 걸까요? 깔끔하게 네이티브로만 작업하면 이해하기에도 쉬울 텐데 말이에요.
앱 안에 웹뷰를 넣는 이유는 다양하지만, 한 마디로 정리하면 어떤 기능은 앱으로 구현하는 것보다 웹 뷰로 보여주는 게 간단하기 때문이에요.
예를 들면 앱 안에 결제 기능을 붙인다고 가정해 볼게요! 이걸 네이티브로 만들면 시간이 아주 오래 걸리고 복잡하지만, 웹에서는 이미 만들어진 모듈과 API가 있기 때문에 이걸 가져다 쓰기만 하면 됩니다. 우리가 순두부찌개를 끓일 때 순두부를 직접 갈지 않고 마트에서 사는 것과 같은 이유예요.
또 다른 이유로는 앱 서비스 론칭 시 앱스토어의 규제로 인해 앱 안에 넣을 수 없는 기능을 제공해야 하는 경우가 있는데, 흔한 경우는 아니지만 어쨌든 이럴 땐 웹으로 우회해서 개발해야 합니다.
이 영역은 사실 개발자들이 쓰는 블로그를 보면 더 깊고 자세하게 설명된 게 많아요! 하지만 우리는 디자이너니까, 딱 여기까지만 이해해도 개발자와의 미팅을 따라가는데 충분하실 거예요.
사실 유저 입장에선 화면마다 어떤 언어로 구현되었는지 알 필요는 없다고 생각해요. 오히려 유저가 그걸 눈치챈다면 앱과 웹화면 간에 이질감이 심하다는 뜻이므로, 좋지 못한 사용성을 제공하고 있다는 뜻이 됩니다.
하지만 서비스를 만드는 디자이너가 이를 정확하게 구분 지을 줄 알면 분명히 이득일 거라고 생각해요. 특히 앱 구현인지, 웹뷰인지에 따라 필수적으로 그려야 하는 UI가 있고 화면 전환 시의 인터랙션도 달라지기 때문에, 프로덕트 디자이너라면 기획과 개발의 오더를 맞추기 위해서 각 차이를 명확히 아실 필요는 있을 것 같습니다.
이번 글은 앱에서 웹을 연결할 때 주로 활용되는 방법인 웹뷰와 기본 브라우저에 대해 정리했습니다. 이 글을 읽고 개념을 탄탄하게 잡으면 기술 이해를 바탕으로 UX를 제안하는 멋진 프로덕트 디자이너가 되실 수 있을 거예요.
네이티브
우선 웹뷰가 아닌 것부터 말씀드릴게요. 바로 네이티브 앱(Native app)입니다. 줄여서 네이티브로 부를게요.
네이티브는 안드로이드나 iOS 같은 플랫폼만을 위해 만들어진 응용 프로그램이에요. 개발에 조금 관심이 있으신 분들은 들어보신 적 있으실 코틀린(Kotlin)이나 자바(Java), 스위프트(Swift)같은 언어가 네이티브 앱을 개발하기 위한 언어지요.
안드로이드 모바일 앱의 경우에는 Kotlin 또는 Java로 만들고, iOS의 경우에는 Swift로 만듭니다.
React Native는 두 플랫폼을 모두 대응하는 앱을 개발할 때 사용하는 프레임워크로, 비유하자면 피그마나 스케치같이 디자인을 위해 활용하는 프로그램이라고 생각하시면 됩니다.
개발 언어에 따라 구현에 활용할 수 있는 라이브러리가 다르기 때문에 디자이너도 어느 정도 알고 있으면 좋아요! 이에 대해서는 나중에 따로 정리해서 알려드리겠습니다 :)
네이티브로 구현했을 때의 장점은 실행 속도가 제일 빠르다는 점이에요. OS 기기랑 직접 소통하기 때문에 화면을 불러오는 것이던 데이터를 불러오는 것이던 뭐든지 웹에서 불러오는 것보다는 빠릅니다. 게다가 API의 지원도 받을 수 있기 때문에 OS에 내장된 기능인 AR이나 스와이프 제스처(Swipe gesture), 카메라, 마이크, 걸음수 같은 정보까지 활용할 수 있다는 장점을 갖고 있지요.
하지만 앱이 고도화될수록 각각의 플랫폼에 더 적합한 개발언어로 코드를 새로 짜야하고, 빌드하는데 시간이 더 오래 걸리기 때문에 웹뷰보다 비용이 더 든다는 단점이 있습니다.
이런 단점을 상쇄하기 위해 정말 네이티브가 필요한 화면만 네이티브로 만들고 부분적으로 웹뷰를 섞어 만드는 앱이 정말 많은데요, 전 이 방법이 현명하다고 생각해요. 서비스의 본질은 무슨 언어로 개발하냐가 아니라 좋은 사용성을 제공하고 있느냐니까요.
이해를 돕기 위해 네이티브만으로 구현된 앱이 무엇이 있을까 찾아보았는데요, 역시 OS에 내장된 기능인 카메라 성능을 많이 활용하는 앱이지 않을까 싶어 SNOW를 켜보았습니다.
과연 대부분의 앱 화면이 네이티브로 구현되어 있더라고요. 다만 하단의 ‘인기’ 탭은 웹뷰로 구현된 것 같아요.
앱 내에서 캡처를 하면 캡처를 인식하고 ‘Snow VIP가 되어, 모든 혜택을 즐겨보세요!’라는 팝업이 뜨는데, 인기 탭에서 연 필터 카메라에서는 해당 다이얼로그가 뜨지 않았어요. 네이티브에서는 캡처라는 유저 액션을 추적하기 수월하지만 웹뷰에서는 그렇지 않기 때문일 거예요.
네이티브와 웹뷰의 퍼포먼스 차이를 직접 경험해보고 싶은 분은 SNOW 앱을 한 번 써보시면 좋을 것 같아요!
웹뷰
앱에서 웹화면을 보여주는 방식의 하나로, 가장 큰 특징은 URL 접근이 불가능하다는 점이에요. 웹뷰이기 때문에 화면을 불러오는 데 시간이 걸릴 수 있고, 이때 앱바 하단에 프로그래스 바가 생기면서 게이지를 보여주는 게 보편적인 UI입니다.
URL 수정이 불가능하기 때문에 아예 주소를 보여주지 않는 웹뷰도 많아요. 주소 없이 페이지 타이틀만 보여주는 방법도 많이 씁니다. 웹뷰는 사용자들이 여전히 앱 안에 있다고 감쪽같이 속일 수 있는데요, 이에 대한 재미있는 글을 소개해드릴게요.
바로 토스의 화면은 앱이냐 웹이냐,를 종결했다고 쓴 어떤 사람의 글입니다.
https://gall.dcinside.com/board/view/?id=programming&no=2072461
요약하자면, 홈은 전부 네이티브로 구현되어 있지만, 단순한 화면에 하나의 CTA(Call to Action)만 있는 페이지는 웹뷰로 만들어졌다는 내용이에요.
아마 홈은 앱의 첫인상을 결정하므로 매끄러운 사용성을 제공해야 하기 때문에 네이티브로 구현하지 않았을까 해요. 또는 토스 홈에서 뱅크로 넘어갈 때 face ID 인식을 하고 넘어가기 때문에(이건 Native API거든요) 네이티브로 구현했을 것 같기도 합니다 :)
토스뿐만 아니라 원티드에서도 웹뷰를 활용한 사례가 있습니다. 눈에 띄는 점은 웹뷰지만 앱처럼 느껴지게 하려고 앱의 간결한 디자인을 웹뷰에 적용한 부분이에요.
웹뷰에 네이티브로 구현된 내비게이션을 함께 두는 경우도 있어요. 카카오 뷰가 바로 그 예시입니다.
두 번째 화면을 보면 이미 웹뷰로 넘어갔음에도 여전히 카카오톡 앱의 기본 바텀내비게이션이 있어서 언제든 다시 채팅 화면으로 돌아갈 수 있죠.
이렇게 만들면 앱의 기본 기능을 유저가 언제든 다시 할 수 있다는 장점이 있지만, 웹뷰로 보이는 화면이 작아져서 콘텐츠를 즐길 때 좀 답답할 수는 있습니다.
주소를 보여주지 않는 웹뷰는 유저에게 웹 화면을 보여주지만 앱 이탈은 최대한 막고 싶을 때 주로 쓰는 것 같아요. 웹뷰 화면을 다 보고 나면 그 화면에서 더는 할 게 없기 때문에 유저는 웹뷰 창을 닫고 다시 앱으로 돌아오지요. 그래서 보통 콘텐츠나 상품을 큐레이션 해주는 앱에서 많이 찾아볼 수 있어요. 앱 내 활동에서 잠시 웹으로 넘어가는 것이기 때문에 주로 페이지 시트 형식으로 구현되고요, 빠르게 앱으로 돌아가기 위해 상단 앱바에 ⬅️버튼이 있거나 X버튼이 있는 경우가 많습니다.
인앱브라우저
인앱브라우저는 웹뷰에 포함되지만, 이 글에서는 편의상 구분해 놓았습니다. 위에서 설명한 웹뷰보다 더 개방적이기 때문에 강조해서 설명하고 싶었어요.
‘브라우저’라는 이름답게, 앱 내 웹 화면에서 여러 화면을 앞, 뒤로 이동할 수 있다는 점이 가장 큰 특징입니다. URL 접근도 가능하기 때문에 주소만 알면 앱에서 보이고 있는 웹뷰 화면으로 외부에서 넘어올 수도 있고요.
인앱브라우저는 기본 브라우저 연결보다 자연스러운 사용자 경험을 제공하면서 구현이 쉽다는 장점을 가졌어요. 특히 커리어리같이 기본 UI를 그대로 활용한다면 필요한 개발 리소스가 더욱 적게 들 거예요.
위에서 설명한 웹뷰와 마찬가지로, 상단 앱바에 브라우저 창을 끄기 위한 CTA가 있습니다 하지만 인앱브라우저의 경우 앱바에 ⬅️버튼과 페이지 Back이 혼동되는 경우가 있을 수 있기 때문에 주로 X버튼을 활용하는 것 같아요.
또 상단 앱바에 페이지 주소를 제공하기 때문에 주소 복사가 쉽다는 특징이 있습니다.
기본 브라우저
핸드폰에 설정된 기본 브라우저 앱을 말해요. 아이폰은 주로 safari로 설정되어 있고, 크롬을 쓰시는 분들도 많죠. 기본브라우저로 연결하면 사용자는 앱을 벗어나게 됩니다. 그래서 UX가 뚝 끊어질 수밖에 없어요. 개발 구현이 제일 쉬운 방법이지만, UX를 책임지는 프로덕트 디자이너 입장에선 많이 고민하고 결정해야 하는 방법입니다.
저도 요즘 앱 내 웹의 진입점에 대해서 PM, 개발자분들과 수차례 미팅하며 시간을 보내고 있는데요, 첫 미팅에서는 네이티브와 웹뷰의 차이가 뭔지, 왜 따로 개발해야 하는지조차 이해하지 못해서 미팅 내내 멍하게 개발자분들이 '이렇게 합시다'라고 말씀하신 것만 받아 적고 있었어요. 그렇지만 점차 거듭된 미팅과 개미핥기 사수님(전직 개발자)의 도움 덕에 오스트랄로피테쿠스가 서서히 일어나듯 인앱 브라우저에 대한 이해도를 쌓아갈 수 있었습니다.
네이티브와 웹뷰의 차이를 애매하게 알 때는 오히려 네이티브 화면은 네이티브처럼 보이게, 웹뷰 화면은 웹뷰처럼 보이게 만들려고 했었어요. 사용성에 대한 고민보다는 '저 이제 알아요'를 드러내고 싶었던 것 같아요.
이 '애매하게 아는 구간'을 지나고 있는 요즘에는, 어떤 방식을 채택하느냐에 따라 유저의 경험이 달라지기 때문에 프로덕트 디자이너라면 반드시 앱 내에서 웹을 보여주는 이유와 방법들에 대해 자세히 알아야겠다고 생각하고 있어요. 네이티브와 웹뷰의 경계를 자연스럽게 잇는 디자인을 위해 노력하고 있습니다.
프로덕트 디자이너는 결국 서비스 사용성을 책임지는 사람들이니까요.
물론 개발자는 현실적인 구현을 책임지기 때문에 종종 '지금은 안 돼요'라고 말할 수도 있지만, 프로덕트 디자이너는 '지금은 안되지만 나중에는 꼭 이렇게 해줬으면 좋겠어요'라고 말할 책임과 힘이 있습니다. (하지만 개발자와의 소통은 늘 손에 땀을 쥐게 하죠 호호...^^;;)
이번 글은 디자이너가 찍먹 하기 좋은 앱 내 웹뷰에 대해 정리해 보았는데요, 이 글을 통해 개발자와의 미팅에서 적극적으로 의견을 말할 수 있는 힘이 생기시기를 응원하며 썼습니다.
모든 프로덕트 디자이너분들 파이팅! (그리고 나도 파이팅)
읽어주셔서 감사합니다! :)
