글로벌 웹 서비스를 다시 만든다면 실수하지 않을 것들

글로벌 웹 서비스를 다시 만든다면 실수하지 않을 것들

다국가를 지원하는 글로벌 웹 서비스를 구현하면 생각하지 못 한 많은 문제를 겪을 수 있습니다.
아래 게시글은 만약 제가 처음부터 다시 개발한다면 어떻게 할까? 라는 생각을 가지고 작성하였습니다.

하나의 국가만 지원한다면 상관없지만 다국가를 지원하는 경우 한번 읽어보시는 것도 좋을 것 같습니다.
제가 정답이라는 것은 아니고 이러한 방법도 있다 라는 생각으로 읽어주시면 감사하겠습니다.

다국어 처리

페이지, 기능 등 여러 단위로 다국어 파일을 관리할 수 있습니다.
위처럼 진행하면 처음에 구현할 떄는 문제가 없을 수 있습니다.
그러나 점점 서비스가 커지고 페이지, 기능이 많아지면 동일한 뜻을 가진 로케일 키가 기하급수적으로 증가합니다.
따라서 제가 생각할 때는 동일한 뜻을 가진 단어가 있으면 하나의 로케일로 관리하는 것이 좋아 보입니다.

이유는 페이지, 기능 별로 파일을 분리하여 관리하였을 때 VOC에 대응하기 힘들었습니다.
예를들어 '배'를 '사과'로 변경해주세요. 라고 요청이 들어왔다고 가정해봅시다.
만약 페이지, 기능 별로 파일을 분리하여 관리하였다면 각 파일마다 수정을 해주어야 할 것입니다.
그러나 하나의 로케일로 관리를 하였다면 '배'만 '사과'로 변경하면 됩니다.

더 자세히 확인하고 싶으시면 아래 링크를 확인해보세요.

• • 다국어 관리 방법

문자열 비교는 정규화 진행 후 하자

문자열 비교는 정규화를 진행 후 하는 것이 좋습니다.
실제로 사용자가 보는 텍스트는 동일하지만 컴퓨터에 다루는 값이 다를 수 있기 때문입니다.

ũ, ũ 해당 2개의 문자는 같아 보이지만 실제로는 다른 값입니다.
위와 같은 경우를 방지하기 위해 정규화를 진행하여 문자열 비교를 해야합니다.

더 자세히 확인하고 싶으시면 아래 링크를 확인해보세요.

• • 베트남 문자열 비교하기

Date 객체 다루기 (+ 썸머타임)

가장 힘들었던 Date 객체를 다루는 내용입니다.
도움이 되었으면 좋겠습니다.

썸머타임

처음 배포했을 때는 썸머타임에 대한 문제가 없었습니다.
생각도 못 했지만 다행히 국가들이 썸머타임을 적용하지 않았기 때문입니다.

그러나 이집트에서 다시 썸머타임을 적용하고 있어 이때부터 문제가 발생하였습니다.
개발 당시 썸머타임을 생각하지 못 했기 때문에 하루가 24시간이라고 생각하고 구현했던 것들이 제대로 동작하지 않았습니다.
썸머타임을 적용하는 시점에는 23시간이기 때문입니다.

대표적인 예시로 주 단위 캘린더를 구현할 때 문제가 발생하였습니다.
주 중 썸머타임 시작 날짜의 시작 시간이 01시이기 때문에 00시의 자리에 01시가 존재하는 문제가 발생하였습니다.
저처럼 위와 같은 문제를 겪지 않으시길 바랍니다.

그리고 대부분 Date 객체를 그대로 사용하는 것이 아닌 라이브러리를 사용하실 것으로 예상됩니다.
해당 라이브러리에서 썸머타임을 제공하는 지 꼭 확인하시는 것을 추천 드립니다.

제가 사용하였던 moment, dayjs는 모두 지원하고 있습니다.

타임존

시간은 고유한 값이기 떄문에 어떠한 타임존에서 사용하더라도 문제가 없습니다.
해당 타임존의 시간으로 변경되어 보여지기 때문입니다.

해당 부분은 하루 기준으로 특정 작업을 할 때 문제가 많이 생겼습니다.
예를들어 하루에 1개만 생성이 가능한 기능이 있다.
위와 같은 경우는 타임존을 변경하게 되면 시작 날짜가 달라지기 때문에 하루를 계산하는 기준이 달라집니다.
시간은 절대적이지만 한국과 미국의 시작 시간은 상대적으로 다르기 때문입니다.

제 생각에는 위와 같은 기능이 없는 게 최고입니다...
그러나 어쩔 수 없이 위와 같은 기능이 있는 경우 타임존을 명확하게 지정하는 것이 좋아보입니다.

가벼운 기능인 경우 프론트에서 서버로 타임존을 넘겨주어 서버에서 해당 타임존을 설정해서 계산하면 됩니다.
그러나 꼭 무조건 1개여야 한다. 이러한 경우는 해당 서비스의 타임존을 명확하게 하나로 지정하는 것이 좋아보입니다.

RTL은 적당히 지원하자

이집트와 같이 LTR이 아니라 RTL인 국가를 처리해야 하는 경우가 있습니다.
그러나 RTL을 완벽하게 처리해주기는 쉽지 않습니다.

대표적인 예시가 50%, %50 이런 것들입니다.
문자와 단위, 숫자 이런 것들이 섞여버리게 되면 단순히 *direction: 'rtl'*로는 해결되지 않습니다.
일일이 처리를 해주어야 합니다.

그러나 위와 같은 것들은 일단 배포하고 나중에 신경써도 되는 내용인 것 같습니다.
추후 알게된 사실인데 대부분의 웹 사이트들이 LTR로 되어 있기 때문에 RTL을 사용하는 국가도 큰 불편함 없이 사용한다고 합니다.
실제로 이집트에서 운영되고 있는 사이트만 보아도 모든 사이트들이 완벽하게 지원하고 있지는 않습니다.

따라서 나중에 VOC가 많이 접수되면 고도화 작업을 하는 것이 좋아보입니다.
추가로 React pdf 라이브러리 중 rtl을 제대로 지원해주는 것은 없는 것 같습니다... ㅠㅠ

동아라비아, 서아라비아 숫자

우리가 아는 숫자는 0, 1, ..., 9 입니다.
혹시 ٠,١,٢,٣,٤,٥,٦,٧,٨,٩ 를 알고 계신가요?

우리가 알고 있는 0~9는 서아라비아 숫자입니다.
위에 적혀 있는 문자로 되어 있는 것은 동아라비아 숫자 중 아랍 문자입니다.

그러나 많이 사용되는 서아라비아 숫자가 사용하기 편하겠죠?
따라서 가장 베스트는 해당 국가 법인과 이야기 하여 서아라비아 숫자만 사용하는 것입니다.
만약 이것이 안된다면 동아라비아 숫자를 서아라비아 숫자로 변환하는 함수를 구현하여 사용하셔야 합니다.

• • 서아라비아, 동아라비아 숫자 변환하기