[실무 기록] 웹뷰 브릿지, 이거 누가 책임져야 하지?

회사에서 앱팀이랑 같이 일하다 보면 가끔 이런 식으로 얘기가 나온다.

"이 브릿지 웹에서 호출해서 써주세요~ 전역 객체로 내려드릴게요."

처음엔 당연히 이렇게 생각했다.

"브릿지는 앱에서 잘 내려주겠지. 난 그냥 window.xxx.yyy()만 호출하면 되겠구나."

근데 실제 운영 환경에서 한 번 이슈경험하고 생각이 바뀌었다.

---

웹은 항상 최신인데, 앱은 그렇지 않다

웹뷰라서 “앱 안에서 도는 웹 페이지”라는 느낌이 강하다 보니
앱이랑 웹이 같이 버전이 맞춰서 움직일 거라고 착각했다.

현실은 딱 반대다.

• 웹은 배포하는 순간 전 유저가 최신 버전을 보게 되고
• 앱은 강제 업데이트 안 걸면 예전 버전이 계속 살아 있음

여기서 문제가 터진다.

최신 앱 버전에서 새로 이런 브릿지가 생겼다고 치자

• 전역 객체: window.xxx
• 메서드: someMethod()

웹 코드에서는 아무 생각 없이 이렇게 썼다.

 

구버전 앱에서는 이 코드가 그대로 터진다. window.xxx.someMethod();

최신 앱에서는 잘 돌아간다.
근데 아직 업데이트 안 한 유저들,
그러니까 이 브릿지가 추가되기 이전 버전 앱에서는 window.xxx 자체가 없음.

결과는 뻔하다.

• Cannot read properties of undefined (reading 'someMethod')
• 그 뒤에 돌아가던 JS까지 같이 꼬이고
• 화면은 이상하게 굴고
• QA는 “가끔 앱에서 화면이 안 떠요” 라고 이슈를 올리고

처음엔 "앱팀이 브릿지 버전 관리 제대로 안 해서 그런 거 아닌가?" 싶었는데,
곰곰이 생각해보니 이건 웹도 책임이 있더라.

---

브릿지 호출 전에 일단 “있나부터” 확인하자

결론은 단순하다.
브릿지 호출 전에, 진짜 있는지부터 확인하자.

체크해야 할 건 두 가지다.

1. 전역 객체가 있는지: window.xxx
2. 그 안에 함수가 실제로 함수인지: typeof window.xxx.someMethod === 'function'

그래서 결국 코드는 이렇게 고쳤다.

 

if (window.xxx && typeof window.xxx.someMethod === 'function') { window.xxx.someMethod(); }

이렇게 해두면 상황별로 이렇게 행동한다.

• 최신 앱 버전
  • xxx도 있고 someMethod도 있으니까 그냥 정상 호출
• 구버전 앱
  • 객체나 함수가 없으면 if에서 걸러짐
  • 아예 호출을 시도하지 않으니 에러도 안 남

즉,
해당 브릿지를 모르는 구버전 앱에게는 그냥 “아무것도 안 한다” 로 정리하는 셈이다.

---

앱이 알아서 해야지라고 생각했다가 깨달은 점

솔직히 말하면 처음엔 이렇게 생각했다.

"브릿지는 앱에서 내려주는 건데, 하위 호환은 앱에서 챙겨야지."

근데 다시 보니까 구조가 애초에 이렇다.

• 웹은 항상 최신
• 앱은 버전이 쫙 퍼져 있음
• WebView는 최신 웹을 불러오는데, 그 안에서 구버전 앱의 브릿지를 호출하고 있음

이 조합이 완벽한 지뢰밭이다.

그래서 지금은 이렇게 생각을 바꿨다.

• 브릿지를 제공하는 앱도 버전/호환성을 신경 써야 하고
• 브릿지를 사용하는 웹도 항상 “없을 수도 있다”는 전제 하에 방어 코드를 넣어야 한다

특히 WebView 환경이라면

“웹은 늘 최신, 앱은 제각각”

이라는 걸 계속 머릿속에 두고 있어야 한다.
그걸 잊는 순간 window.xxx is undefined 지옥이 시작된다.

---

정리

이번에 얻은 결론은 이거 하나다.

브릿지는 내려주는 쪽만 신경 쓸 게 아니라,
쓰는 쪽에서도 항상 가드 치고 호출해야 한다.

그리고 그 가드는 사실 별거 아니다.

if (window.xxx && typeof window.xxx.someMethod === 'function') { window.xxx.someMethod(); }

딱 이 정도만 해도
“최신 웹 + 구버전 앱” 조합에서 터지는 에러들을 꽤 많이 막을 수 있다.