서비스나 소프트웨어를 해외에 진출시키는 과정에서 가장 첫번째로 해결되야할 과제는 역시 인코딩변환과 번역작업이다.
최근에는 구글처럼 애초부터 유니코드(UTF-8)를 사용하는 서비스가 늘어나면서, 인코딩변환을 고민할 필요가 많이 없어졌지만, 만약 EUC-KR 등의 자국어 전용 인코딩을 사용하고 있었다면, 현지국가에서 사용하는 인코딩이나 UTF-8로 변환시킬 필요가 있다.
일본의 경우, SHIFT-JIS와 EUC-JP를 혼용해서 쓰고 있는데, 아무래도 MS Windows가 SHIFT-JIS를 쓰다보니 SHIFT-JIS가 대세이긴 하나, 야후재팬처럼 Unix 기반으로 서비스를 운영하는 곳은 EUC-JP를 쓰기도 한다. (SHIFT-JIS 인코딩이 backslash에 해당하는 0x5C 값을 사용하면서 Unix에선 제대로 동작하지 않는 경우가 많기 때문이다.)
아울러 웹과는 별도로 이메일 인코딩으론 ISO-2022-JP를 많이 사용하고 있다는 점도 특이할 만하다.
사실 SHIFT-JIS와 EUC-JP는 구조가 많이 다른데다, Unix에선 SHIFT-JIS 인코딩으로 개발하기가 쉽지 않고, MS Windows에선 EUC-JP를 제대로 지원하지 않기 때문에, 차라리 웹쪽은 UTF-8으로 통일하고, Windows Application의 경우는 UTF-16LE를 쓰도록 하는 것이 최적이 아닐까 싶다.
거대 웹서비스의 경우, 유니코드로 인코딩을 변환하는 과정 자체가 매우 큰 프로젝트가 되기 때문에, 특별한 이유가 없는 이상 처음부터 유니코드 기반으로 가져가는 것을 추천한다.
일단 인코딩 문제를 해결하고나면, 그 다음은 번역이다.
소스코드의 모든 메시지들을 긁어낸 후, 번역해서 다시 교체해넣는 과정인데, 당연한 얘기지만, 되도록 자동화시키는 방안을 찾는 것이 좋다.
Windows Application의 경우, 텍스트를 리소스로 분리해내기도 하지만, 실질적으론 소스코드 여기저기에 한글메시지들이 하드코딩 되어있기 마련이다. (다행히 한글이나 일본어 같은 multibyte 문자들을 소스코드에서 긁어내는 것은 크게 어렵지는 않다.)
일본어의 경우, 시중에 번역기도 여럿 나와있고, 웹에서 번역기를 돌릴 수도 있으니, 그런 것들을 이용하면, 훨씬 더 빠른시간 안에 손쉽게 번역작업을 마칠 수 있을 것이다.
아울러 인코딩변환과 번역작업이 꽤 시간이 걸리는 부분이긴 하지만, 사실 기존 서비스의 각 컴포넌트를 떼어다가 해외서비스를 위해 그대로 클론화시키는 작업은, 기존 시스템과 기술에 대한 높은 이해를 요구하기 때문에 훨씬 더 힘들다는 점도 상기해야 한다.
