크롬 말고 엣지 브라우저 자동 번역은 또 어떻게 문제를 일으키는가

이전에

https://99years.tistory.com/238

구글 크롬 자동번역과 Next 500 에러

이 게시글에서 구글 크롬 자동번역과 Next 500 에러에 대해 알아본 적이 있다. 이것만으로도 꽤나 성가시지만... 문제는 그게 전부가 아니었다!

 

프론트엔드 개발자로서는 웹이란 정말 온갖 별 일이 다 일어나서 통제하기 어려운 곳이다. 그래서 뭔 일이 일어나도 놀랍지가 않다.

 

지난 글에서 <span>으로 감싸 문제가 해결된 듯 보였지만, 그 이후에도 에러가 집계되었고 추가적인 CS가 접수되었다.

 

나의 경우 말했듯이 플랫폼 개발을 하고 있기 때문에 우리 서비스는 다양한 유저들이 다양한 환경에서 접속을 한다. 그래서 외국인 유저가 브라우저 자동 번역 기능을 사용하여 컨텐츠를 이용하는 경우도 꽤나 있는데, CS 스크린샷 중에는 모바일 엣지 브라우저도 있었다.

 

프론트엔드 개발을 하면 iOS 사파리도 화가 나고 삼성 브라우저도 애를 먹이는데... 엣지 브라우저는 고려했던 적이 별로 없었다.

내 추측이지만 한국인은 아이폰 혹은 갤럭시를 사용하고 갤럭시 기본 브라우저는 삼성 브라우저고 굳이 설치한다면 크롬을 설치하지 엣지브라우저를 설치하지 않지만 일본 등 안드로이드 폰 기본 브라우저가 엣지인 경우가 있어서 그분들은 엣지 브라우저를 사용하기 때문에 이런 문제가 있지 않았나 싶다.

 

아무튼 크롬과 엣지 브라우저는 자동 번역을 처리하는 방식이 좀 다르다. 방식은 비슷하긴 한데 테스트 해보면 엣지 브라우저가 좀 더 공격적으로 dom 조작을 하는 것을 확인할 수 있다. 둘 다 <font>를 사용하는 건 비슷하지만 엣지 쪽이 좀 예측이 어렵게 교체를 하여 하이드레이션 에러가 다발적으로 일어난다. 그리고 크롬과 다르게 엣지에서는 접근성 태그 (aria 같은 것)까지 번역하려고 시도해서 다 막는 게 힘들다. 

 

조건부 렌더링되는 단독 텍스트 노드 같은 데서 자주 발생하고. 크롬과 다르게 엣지용으로는 <span>을 이중으로 넣는다거나 하면 막을 수 있다.

 

 

https://github.com/react/react/issues/11538#issuecomment-417504600

Make React resilient to DOM mutations from Google Translate · Issue #11538 · react/react

 

원천적으로 번역이 발생했을 때 500 에러가 발생하는 것 자체를 막기 위해 이런 코드를 사용할 수 있다. (리액트 개발자가 알려준 코드라 더 믿음이 가긴 한다.)

우리는 이걸 테스트 해보기는 했지만 실제로 도입하지는 않았다.

 

 

if (typeof Node === 'function' && Node.prototype) {
  const originalRemoveChild = Node.prototype.removeChild;
  Node.prototype.removeChild = function(child) {
    if (child.parentNode !== this) {
      if (console) {
        console.error('Cannot remove a child from a different parent', child, this);
      }
      return child;
    }
    return originalRemoveChild.apply(this, arguments);
  }

  const originalInsertBefore = Node.prototype.insertBefore;
  Node.prototype.insertBefore = function(newNode, referenceNode) {
    if (referenceNode && referenceNode.parentNode !== this) {
      if (console) {
        console.error('Cannot insert before a reference node from a different parent', referenceNode, this);
      }
      return newNode;
    }
    return originalInsertBefore.apply(this, arguments);
  }
}

 

아무튼 이제 알 수 없는 에러가 발생하는 것은 막을 수 있었지만 또 한가지 문제가 있었다. 그것은 바로 엣지 브라우저에서만 번역 기능을 사용했을 때 발생하는 스켈레톤 무한 로딩 현상이었다.

 

이미지에 사용되는 스켈레톤이 스켈레톤 상태에서 전환이 되지 않는 것으로 보이며, SSR 하이드레이션에서만 발생한다. (SPA 이동할 때는 안 발생) 크리고 클릭을 하면 넘어가져서 유저 입장에선 스크롤을 한 번 하면 넘어가기 때문에 오류로 인지되지는 않았다.

 

여기에는 정말 복합적인 문제가 있는데, 일단 우리 프론트엔드가 서버사이드렌더링 단계에선 스켈레톤으로 보이고 클라이언트 사이드에서만 보이게 되어있었다. (어떤 것은 useEffect로 state를 변경 시키고 그걸로 분기해서 렌더링, 어떤 것은 ssr false로 되어있고...) 

그런데 엣지에서 하이드레이션 단계에서 에러가 여기저기서 발생하면 리액트의 재조정 단계에서 예기치 못한 에러가 발생하여 재조정이 중지되고 그냥 그 상태로 멈춘 것 처럼 보이게 됨. 클릭 등 유저 액션이 들어가면 또 자체적으로 리커버리를 진행해서 다시 하이드레이션이 진행되어 정상적으로 로딩 완료된 것으로 보임.

 

(이걸 막기 위해서, 아예 루트 컴포넌트는 traslate="no" 로 지정한후 클라이언트 컴포넌트를 하나 만들어 useEffect 훅 안에서,  하이드레이션 이후 translate="yes"로 바꾸는 꼼수를 써 보려고 했는데 이 역시도 크롬은 동작은 하나 엣지는 이후에 저 속성을 바꾼다고 자동 번역이 동작하지는 않았다...!)

 

이런 문제가 발생하는 걸 보고 나는 엣지로 다른 플랫폼에 접속해서 테스트 해봤는데 콘솔로그를 보니 다른 플랫폼도 하이드레이션 에러 자체는 막지 못하고 있는 것으로 보였음. 하지만 우리처럼 클라이언트 사이드에서만 렌더링되는 종류의 컴포넌트가 없었기 때문에 문제가 발생하지 않았다.

 

우리 서비스도 굳이 이런식으로 스켈레톤을 표시할 필요가 없었다. 그래서 근본적으로는 이유 없이 클라이언트 only 컴포넌트를 만들지 않는 것만이 해결책이다. 

 

그런데 우리는 이걸 갈아엎으려면 대대적으로 많은 수정을 해야 했기 때문에 그냥 알려진 이슈지만 수정하지 않고 점진적으로 개선해나가는 것으로 결론내렸다. 해외 이용자면서 엣지 사용자의 점유율이 높지 않은 것으로 파악이 되었기 때문이다. 그리고 말했다시피 그냥 스크롤 한번만 하면 전환되어서 유저는 오류를 인지하지 못한다.

 

...

 

간단하면서도 꽤나 애를 먹었던 이슈다. 크로스 브라우징이라는 건 참 쉽지 않은 일이다. 이런 자동 번역 쪽이 딱히 동작에 대한 문서를 제공하는 것도 아니고 브라우저마다 자신만의 철학이 확고하거나 브라우저 자체 기능이 있다거나 하는 경우가 있기 때문에 역시 개발자가 현실세계에서 겪는 문제들은... 성숙한 프로덕트를 유지보수하면서 더 많이 겪게 되는 것 같다.

 

구현자체는 항상 즐겁고 쉬운데 이런 일들이 참 쉽지 않은 듯. 

 

만약 여러분이 외국 유저도 있는 서비스를 개발하고 그들이 브라우저 자동 번역을 돌리고 있다면...!! 테스트는 엣지로 해보는 걸 추천한다. 엣지에서 문제가 없으면 크롬에선 잘 된다. 

 

ㅜㅜ.