RN과 웹뷰

SangHyeon Lee·2025년 11월 25일

시작하며

사실, Motimo 서비스를 앱으로 배포하려고 했다.

애초에 모바일용으로 디자인이 이뤄졌고, 타겟 사용자를 고려했을 때 모바일 앱일 때 활용도가 높을 것으로 예상했기 때문이다.


그러나 팀 구성이 웹 FE들만 있었기 때문에, 우선 웹 개발 이후 앱으로 고도화할 예정이었다.

결국 웹 버전으로 서비스를 배포하게 되었지만, 그 과정에서 있던 경험들은 유의미했기에 회고록을 작성하고자 한다.

회고록

상황 설명

Motimo는 인증 방식으로 OAuth2를 사용하고 있었는데, 이로 인해 생기는 문제점이 있었다.

Google 로그인은 Webview 컴포넌트 안에서 OAuth 방식의 동작이 제한된다는 것이다.

토큰을 ReactNative 안에서 받아서 처리해야 하기 때문에, 로그인 화면을 RN으로 제작할 필요가 있었다.

다행히, 이는 AI를 통해 빠르게 제작했다. 이미 디자인이 나왔기에 빠르게 적당한 코드를 생성시키고, 디테일은 직접 RN코드를 수정하며 처리했다.

Webview 적용하기

인증 관련해서 고려 사항들이 있었다.

  • RN안에서 토큰을 발급받고, 이를 웹뷰 안으로 전송해야 함.

  • 웹뷰 안에서의 로그아웃 등의 토큰 처리에 대해 RN 환경과 연동해야 한다.


방법을 찾아보면, expo의 WebBrowser의 메서드를 사용하거나 Google.useAuthRequest 등을 사용해야만 한다.

기본적으로 RN에서 인증을 요청하는 과정인데, 예전에는 WebBrowser의 메서드를 사용하면 꽤 편하게 문제를 해결 할 수 있는 것으로 보였다.

RN에서 로그인 관련 처리 후, 웹에서 사용하던 방식대로 AccessToken과 RefreshToken을 발급받게 되고, 이러한 토큰을 SecureStore에 저장 후 웹뷰 안쪽으로 보내주는 것이다.

그러나, 현재는 403 에러가 뜨는 것이 확인 되었다.


OS가 제공하는 시스템 브라우저와 같이 신뢰할 수 있는 브라우저 환경에서 403에러가 발생하지 않는다는 것과 함께 다음의 방식을 사용해야 함을 봤다.

  const [request, response, promptAsync] = Google.useAuthRequest({
    androidClientId: 'YOUR_GOOGLE_ANDROID_CLIENT_ID.apps.googleusercontent.com',
    iosClientId: 'YOUR_GOOGLE_IOS_CLIENT_ID.apps.googleusercontent.com',
    // expoClientId: '...', // Expo Go에서 테스트 시 웹 클라이언트 ID를 여기에 넣을 수도 있습니다.
  });

  useEffect(() => {
    if (response?.type === 'success') {
      // Google로부터 인증 성공!
      const { authentication } = response;
      const idToken = authentication?.idToken;

그러나 이 방식은 idToken만을 얻기 때문에, 결국 세션 유지를 위해서는 백엔드에서 OAuth처리 후 토큰들을 보내줘야만 했다.


문제는, 고도화 과정은 나 혼자 진행하고 백엔드 분들의 도움을 받기 어려운 상황이었다는 점이다.

꼼수.. userAgent

어떻게든 웹뷰를 띄워보고 싶어 방법을 찾다, userAgent를 모바일 브라우저로 바꿔 미봉책을 마련할 수 있음을 알게 되었다.

아래의 user agent를 사용하면 되었다.

const FAKE_USER_AGENT =  'Mozilla/5.0 (Linux; Android 10; SM-G975F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Mobile Safari/537.36';

아래는 이를 통해 Webview를 적용해본 테스트 화면이다.

한계

결국 위 방법은 언제 막힐지 모르는 방식이라는 점과, 스토어 배포 시 반려의 원인이 될 요소가 될 것임이 단점이었다.

또한, 근본적으로 정석적인 방법을 사용하지 못한 이유는 백엔드와의 소통 부족임을 느꼈다.

애초에 백엔드에서 쿠키 기반의 인증 방식을 사용하지 못했는데, 관련해 인증과정을 함께 담당했떤 동료 FE의 말에 따르자면 해당 팀원 분이 쿠키 처리 방식을 어려워 하는 것으로 보였다고 했다.


당시에는 보안이 취약해지긴 하겠지만, 서비스 제작 동기와 규모, 그리고 유지 면에서 생각해보면 내 작업에 크게 영향 없을 것이라 생각했다.
또한, 해당 팀원 분은 다른 프로젝트도 동시에 진행하는 것으로 알고 있어 시간 관계상 어려웠나보다 생각이 들었다.

그러나 고도화 과정에서 이번 웹뷰 처리도 그렇고 SSR전환에 있어서도 인증 과정이 발목을 잡는 것을 통해 생각보다 인증이 미치는 영향이 크다는 것을 느꼈다.

또한, 확장성과 나 자신을 위해서라도 최소한의 기능 기준은 지켜지도록 팀원에게 확실히 요구할 수 있어야 함을 느꼈다.

마치며

이번 고도화 작업은 프로젝트 제작 기간이 종료되고 발표를 마친 이후에 혼자 했던 것이다.

다른 백엔드 한분이 더 계셨지만, 유지보수에 대해 생각이 없으셨기 때문에 경험을 쌓고자 스스로 진행했었다.


프로젝트를 진행하면서 조금 더 친분을 쌓고 분위기를 만들었다면 그래도 다같이 고도화를 진행하며 좋은 결과를 얻을 수 있었지 않았을까 아쉽다.

소프트 스킬의 중요성도 느낄 수 있었던 경험이었다.


그래도 FE 인원끼리 모여 짧게 진행했떤 RN 스터디 내용을 활용해서 로그인 화면도 만들고, 웹뷰도 띄워봤었기에 뜻 깊었다.

이를 잘 살려 다른 프로젝트에 적용해 꼭 앱을 배포할 생각이다.

profile
회고할 가치가 있는 개발을 하자

0개의 댓글