1 of 25

웹뷰와 네이티브를�제대로 이어붙이기

Webview Request Protocol 🌯

2 of 25

발표자 소개

2014 ~ 2016�사이냅소프트에서�네이버오피스 (주로 Word) 개발�
2016 ~ 2018�스포카에서 도도포인트, 도도매니저 개발�
2018 ~ 2020�데브시스터즈에서 웹서비스 이것저것 많이 개발�
2020 ~ 현재�뤼이드에서 오늘 발표하는 것 같은 무언가를 이것저것 많이 개발

Twitter, GitHub - @disjukr

3 of 25

웹뷰가 얼마나 많이�사용되고 있을까요

(빌드 번호 연타하여 개발자 옵션 활성화 후)

개발자 옵션 > 레이아웃 범위 표시

발표를 준비하면서, 웹뷰가 얼마나 많이 쓰이고 있는지 궁금해져서 그걸 알아보려고 우선 웹뷰 사용 여부를 감지하는 법을 찾아봤는데요,

안드로이드 폰에서 개발자 옵션을 활성화하고 “레이아웃 범위 표시"라는 옵션을 켜면 안드로이드 UI 요소들이 화면에 어떻게 배치돼있는지 네모낳게 시각화가 됩니다.

웹뷰같은 경우에는 웹뷰가 사용된 영역이 하나의 커다란 네모로 보이기 때문에, 복잡한 UI 요소들이 네모 하나로 합쳐져서 보이면 여기에 웹뷰가 사용됐겠거니 짐작할 수 있습니다.

물론 캔버스가 사용된 경우에도 하나의 네모로 보이기 때문에 플러터 같은걸로 만들어진 화면일 수도 있는데, 그 것보다는 웹뷰일 가능성이 더 높으니까요.

4 of 25

5 of 25

대체로 메인화면에서 한 두번의 터치로 도달할 수 있는 곳에 웹뷰가 사용되고 있음

6 of 25

중복 개발 X

스토어 심사 X

이렇게 많은 앱들이 웹뷰를 즐겨 사용하는데는 그만한 이유가 있습니다.

(다음 슬라이드)

우선 같은 화면을 만드는 노력을 플랫폼마다 중복해서 들일 필요가 없어지고요,

웹뷰로 만든 화면은 스토어 심사를 받을 필요가 없어서 배포 주기를 짧게 가져갈 수 있는 장점이 있어요.

그래서 잠수함 패치나 A/B 테스팅 같은걸 빠르게 돌려보기에도 유리한 면이 있고요.

(다음 슬라이드)

하지만 웹뷰 만으로는 일반적으로 앱에서 기대하는 모든 경험을 제공하는 것이 불가능합니다.

네이티브에서 구현된 기능들을 웹뷰가 요청해서 사용할 일이 종종 생기는데,

웹뷰와 네이티브 사이의 통신을 직접 구현하는 것은 제가 생각하기에 크게 세가지 문제로 인해서 까다롭습니다.

7 of 25

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

웹페이지와 모바일 앱의 생명 주기가 다름

웹페이지와 모바일 앱의 버전이 서로 다름

8 of 25

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

9 of 25

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

10 of 25

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

웹페이지와 모바일 앱의 생명 주기가 다름

웹페이지와 모바일 앱의 버전이 서로 다름

11 of 25

웹페이지와 모바일 앱의 생명 주기가 다름

모바일 앱은 웹뷰보다 오래 살아요. 더 먼저 태어나고 더 나중에 죽어요. 웹뷰 입장에서 보면 엘프같은 존재입니다.

모바일앱이 태어나자마자 웹뷰한테 무언가 통신을 시도하면, 웹뷰는 아직 태어나지조차 않은 상태이기 때문에 응답을 할 수가 없어요.

웹뷰가 태어나더라도 자바스크립트가 로드되고 원하는 코드조각이 제대로 실행돼서 모바일앱한테 무언가 알려주기 전 까지는 모바일 입장에서 웹뷰와 통신할 수 있는 상태인지 구분하기가 어렵습니다.

통신이 이뤄지는 도중에 웹페이지가 새로고침 된다거나 다른 페이지로 이동해버리던가 하면, 웹페이지는 이전 실행 맥락을 잊어버리기 때문에 다시 태어난 상태가 돼요.

모바일앱은 웹뷰가 다시 준비될 때까지 기다리는 처리를 해줘야 합니다.

12 of 25

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

웹페이지와 모바일 앱의 생명 주기가 다름

웹페이지와 모바일 앱의 버전이 서로 다름

13 of 25

웹페이지와 모바일 앱의 버전이 서로 다름

심사 없음

스토어 심사 대기 필요

거절될 수도 있음

14 of 25

웹페이지와 모바일 앱의 버전이 서로 다름

새로고침 하면

나도 모르는 새에 최신버전

죽어도 업데이트 안 함

사용자 버전 파편화

게다가 웹페이지는 배포가 이뤄지고나서 사용자가 앱을 껐다 키거나 새로고침을 하게 되면, 캐시 처리같은게 잘돼있으면 항상 최신 버전이 됩니다.

매우 편리한 성질이죠.

근데 모바일 앱은 사용자가 스토어에서 업데이트하는 과정을 거쳐야하는데 이 과정이 불편하니까 잘 안 하게 되고요,

스토어 설정으로 강제 업데이트를 하게 만들 수는 있는데 사용자 경험이 안 좋아지고 지표가 나빠지니까 PM이 강업 허락을 안 해줍니다.

그래서 모바일 앱과 통신해야하는 웹뷰 입장에서는 사용자가 굉장히 옛날 버전의 모바일 앱을 사용하고 있을 가능성을 개발중에 항상 염두해야 합니다.

보통은 모바일 앱에서 자신이 무슨 버전인지 웹뷰한테 전달해서, 웹뷰가 모바일 앱의 버전마다 다른 분기를 타도록 우회를 많이 하는데요,

이런 대비조차 안 해놨으면 강업을 하는 수 밖에 없습니다.

15 of 25

해결책 - Webview Request Protocol (WRP)

앞서 언급한 문제들을 해결해주는 레이어
모바일 앱을 웹뷰를 위한 API 서버라고 생각하자

Protobuf 기술을 모바일 앱과 웹뷰 통신에 활용하자
Protobuf 코드 생성기가 gRPC 통신 코드를 생성하는 대신 WRP 통신 코드를 생성하게 만들자

이런 문제들을 해결하기 위해서 저희는 Webview Request Protocol이라는 기술을 개발했는데요, 줄여서 랩(WRP, Wrap)이라고 발음합니다.

핵심 아이디어는 모바일 앱을 웹뷰를 위한 API 서버로 생각하자는 것입니다.

요청/응답 모델은 우리가 이미 서버와 클라이언트가 통신할 때 쓰고있는 방식이라 익숙하게 사용할 수 있습니다.

저희 회사에서는 Protobuf랑 gRPC를 이미 서버랑 클라이언트가 통신할 때 사용하고 있어서 다들 익숙하기 때문에 모바일 앱이랑 웹뷰가 통신하는 데에도 이걸 쓰기로 했고요,

Protobuf 컴파일러는 기본적으로 gRPC 통신 코드를 생성하는데, 이거 대신에 WRP으로 통신하는 코드를 생성하도록 했습니다.

16 of 25

17 of 25

18 of 25

WrpGuest

WrpHost

WrpChannel

Glue (per Platform)

WrpSocket

Protobuf

Client

Protobuf

Server

WRP은 웹뷰의 부모 환경이 아주 다양할 것을 감안해서 설계됐습니다.

저희가 지금 구현해둔 환경은 안드로이드, iOS, iframe의 parent window 뿐이지만,

Electron, Tauri, Flutter, React Native 등 다양한 환경의 웹뷰 위에서 충분히 구현이 가능합니다.

WRP은 임의의 바이트열을 주고받을 수 있는 소켓과, 소켓을 감싸서 메시지를 주고받을 수 있는 채널과,

채널을 감싸서 요청을 할 수 있는 게스트와 응답을 할 수 있는 호스트로 구성되어 있습니다.

이런 WRP 런타임을 이용하도록 Protobuf 서버/클라이언트 코드 생성기가 제공되고요.

웹뷰 코드에 대해서 플랫폼마다 이 구현을 각각 하는 대신에, 가장 간단한 인터페이스를 가지는 소켓 부분만 플랫폼별로 구현을 했고요. 저희는 이를 Glue 코드라고 부르고 있습니다.

WRP에서 Glue를 제외한 나머지 부분은 플랫폼 독립적으로 구현되어있습니다.

19 of 25

( Protobuf Server )

useWrpServer(...)

( Protobuf Client )

client.getTextValue()

( WrpChannel )

20 of 25

05 00 00 00 0A 66 …

0A 00 00 00 32 37 0A 01 31 12 …

07 00 00 00 3A …

05 00 00 00 42 …

…

( WrpChannel )

( WrpSocket )

21 of 25

이 구조에서 앞서 말한 문제들은 어떻게 해결되는 건가요

웹뷰 통신을 위해 제공되는 네이티브 API가 불편함

Protobuf 스키마 컴파일러로 사용하기 편한 라이브러리 코드를 생성해서 해결�

웹페이지와 모바일 앱의 생명 주기가 다름

각 플랫폼 별 WRP Glue 코드에서 신경써서 잘 추상화
생성된 Protobuf 라이브러리 위에서 서버/클라이언트 코드를 작성하면�소켓 연결 등 나머지 처리는 WRP 런타임이 담당�

웹페이지와 모바일 앱의 버전이 서로 다름

WrpHost가 보내는 HostInitialize 메시지를 통해 현재 사용 가능한 메서드 목록 전달
Protobuf 메시지는 키 이름 변경 등 소스코드 수준 하위호환이 깨져도�직렬화된 메시지 수준 하위호환은 유지되는 성질이 있음

여기까지가 대강의 WRP 설명이었고요, 이 구조에서 아까 이야기했던 문제들이 어떻게 해결되는지 짚어보겠습니다.

우선 네이티브 API가 불편했던 문제는, RPC 스키마 정의로부터 라이브러리 코드를 생성하는 것으로 해결하였고요,

웹페이지와 모바일 앱의 생명 주기가 다른 부분은, 저희가 Glue 코드 수준에서 소켓 연결 및 재연결 처리등을 플랫폼마다 신경써서 처리해두었기 때문에

소켓을 사용하는 단계부터는 신경쓰지 않아도 되도록 하였습니다.

마지막으로 웹페이지와 모바일 앱의 버전이 서로 다른 부분은, 소켓이 연결되면 사용 가능한 메서드 목록을 게스트측에 전달하는 과정을 두어서,

어떤 기능이 구현되어있는지 여부를 웹뷰가 미리 확인할 수 있도록 하여 해결하였습니다.

또한 Protobuf의 메시지 직렬화 형식은 XML이나 JSON등과 달리 키 이름이 직렬화된 바이트열에 포함되지 않기 때문에

스키마에서 키 이름을 변경하여도 실제 통신에서 주고받아지는 페이로드는 변하지 않는 특징이 있습니다.

22 of 25

23 of 25

시연

그럼 작동하는 데모를 보여드리겠습니다.

https://wrp-demo.vercel.app/iframe-example

(pbkit devtools 연동 잊지말고 보여주기)

왼쪽 위에 보이는 슬라이더와 텍스트 인풋이 호스트 환경입니다.

모바일로 치면 네이티브 UI에 해당하고요,

그 아래 보이는 영역이 게스트 환경입니다.

여기서는 iframe으로 구현돼있는데, 모바일에서는 웹뷰에 해당합니다.

서비스 스키마는 이렇게 생겼습니다.

서버는 슬라이더 값과 텍스트 값을 상태로 가지고요,

이 예제에서는 텍스트 값은 단항 요청으로, 슬라이더 값은 스트림으로 제공됩니다.

오른쪽 위와 아래에 보이는 UI는 WRP 내부적으로 무슨 일이 일어나는지를 설명하기 위해 그려놓은 시각화입니다.

오른쪽 UI는 WRP 채널에서 주고받아지는 내용들을 자세히 보여주고 있고요,

아래에 보이는 UI는 각 코드와 채널에서 주고받아지는 메세지와 소켓에서 주고받아지는 바이트열이 어떻게 대응되는지를 시각적으로 연결해서 표현했습니다.

우선 바깥의 텍스트 인풋을 이렇게 수정해서 iframe 안에 있는 버튼을 누르면,

iframe 안쪽에서 바깥의 텍스트 인풋값을 가져와서 출력하는 모습을 확인할 수 있습니다.

슬라이더 값은 스트림으로 받아오고 있는데요, 이렇게 슬라이더를 움직이면 값이 실시간으로 업데이트되는 것을 확인할 수 있습니다.

코드를 보여드리겠습니다.

(server 코드 열음)

우선 호스트에서는 useWrpServer라는 리액트 훅으로 각 메서드가 구현돼있는 것을 확인하실 수 있습니다.

안드로이드와 iOS에서 사용할 때도 비슷한 수준의 추상화가 되어있는 라이브러리가 제공됩니다.

(client 코드 열음)

게스트 코드를 보시면 이렇게 클라이언트를 생성해서, 평범한 js 객체처럼 메서드를 호출하고 반환값을 얻어오는 것을 확인하실 수 있습니다.

스트림의 경우에는 async generator로 응답이 제공되어서 for await of 문을 이용해서 갱신되는 값을 받아오는 것을 확인하실 수 있습니다.

(다시 본래 데모로 돌아와서)

WRP은 코드 생성에 pbkit 컴파일러를 사용하고 있기 때문에 pbkit devtools를 이용할 수 있습니다.

크롬 개발자도구의 네트워크 탭처럼, 호스트와 게스트간의 통신이 이뤄질 때 무슨 메서드가 불렸고 무슨 값이 요청되었고 무슨 값이 응답되었는지 pbkit devtools에서 확인하실 수 있습니다.

데모는 여기까지 보여드리겠습니다.

모바일로 구현되어있는 데모는 wrp-kt, wrp-swift 저장소의 README에 동영상으로 첨부해두었습니다.

24 of 25

도와준 사람들

WRP의 전신인 앱브릿지 개발을 도와주셨던�옛 산타토익팀, 산타공인중개사팀, CMS팀�
Protobuf.js를 걷어내고 Pbkit 적용 작업을 진행해준 뉴토익팀�(토익 앱브릿지도 WRP으로 교체합시다)�
프로덕션에 WRP 적용 작업을 진행해준 에어매스팀�
wrp-kt 개발을 도와주신 안드로이드팀�
wrp-swift 개발을 도와주신 iOS팀�
같이 WRP을 개발한 용욱님 (이따 Deno 발표를 하시는 분입니다)

1 of 25

2 of 25

3 of 25

4 of 25

5 of 25

6 of 25

7 of 25

8 of 25

9 of 25

10 of 25

11 of 25

12 of 25

13 of 25

14 of 25

15 of 25

16 of 25

17 of 25

18 of 25

19 of 25

20 of 25

21 of 25

22 of 25

23 of 25

24 of 25

25 of 25