Salesforce 해외 법인 Rollout시 다국어 설정의 문제

현재 여러 유럽 법인에 CRM시스템을 동시 Rollout하는 프로젝트에 참여하고 있다. 그러다 사소하지만 꼭 구조를 잡고 넘어가야 하는 다국어 설정의 문제를 발견했다.

 

일반적인 IT시스템 구축 프로젝트의 진행 순서는 다음과 같다.

• 요구사항 분석 - 기능 설계 및 개발 - 인터페이스 개발 - 마이그레이션 - 테스트 - 컷오버 - 오픈 - 안정화

어떤 회사가 한 번도 컴퓨터를 활용한 정보 관리 시스템을 도입한 적이 없는 흰 도화지라면, 기능 개발만 제대로 해도 괜찮을 것이다. 하지만 보통 회사들은 이미 ERP를 비롯하여 다양한 마케팅 솔루션을 활용하고 있거나 자체적으로 웹 개발을 하여 데이터를 수집하거나, 개인 컴퓨터에 엑셀 등으로 고객 데이터를 보유하고 있다.

따라서 이전에 사용하고 있던 웹페이지/솔루션 관리 현황을 파악하고 인터페이스를 대는 작업이 필수적이다. 이걸 인터페이스 개발 단계에서 진행한다.

 

지금 참여하는 프로젝트에서는 동일한 회사의 지사임에도 불구하고 법인마다 고객에게서 수집하는 데이터 종류가 조금씩 다르다. 또한 사용하는 언어도 다르다. 동일한 field value라도 다른 언어로 쓰였기 때문에 다른 pickvalue로 취급되는 경우가 발생했다.

 

→ 고객의 니즈 파악이라는 동일한 목표 하에 유사한 형태의 랜딩페이지에서 데이터를 수집하지만,

1) pickvalue 가짓수가 비표준화되어있고,

2) 동일한 pickvalue이더라도 언어별로 다른 값으로 인식되어,

범유럽 차원에서 고객 데이터를 표준화하여 관리하기 어려운 상황이 발생.

 

따라서 일단 시스템 내부적으로 관리하는 데이터의 label(노출되는 값)/api(식별자)가 존재하고 외부(사용자)로 노출하는 label값을 따로 관리해야했다. 관리할 표준 데이터 언어는 영어로 설정하였다.

 

1.

처음에는 label값을 특정 로컬 언어로 표기하고 api값을 영어로 통일하자는 비교적 간단한 해결방법이 제시되었다.

이렇게 되면 다른 법인의 사용자가 picklist를 열었을 때 타 로컬 언어 pickvalue도 노출되는 상황이 발생한다.

 

2.

이에 법인명을 조건값으로 사용자에게 노출되는 pickvalue 가짓수를 조정하자는 안이 제시되었다. 예를 들어, 법인이 이탈리아이면 이탈리아어로 label이 설정된 pickvalue만 보여주는 것이다. 직관적인 방법이었으나 Standard object(e.g. Account)에서는 해당 기능을 사용할 수 없었다. 또한  앞으로 해당 시스템을 사용할 유럽 법인이 추가될 때마다 pickvalue 가짓수가 늘어나게 되어 유지보수성이 떨어진다. 또한 동일한 value를 다르게 판단하는 문제가 해결되지 않았기 때문에 장기적으로도 데이터를 유의미하게 축적하기 어려운 형태였다.

 

3.

조금 까다로워보였지만 다행히 Translate Workbench 기능을 활용하여 비교적 쉽게 해결되었다.

표준 언어로 표기된 picklist/pickvalue와 법인별 로컬 언어로 표기된 picklist/pickvalue를 정리하고, 사용자에게 노출될 pickvalue값에 대해 언어별 노출값을 기입해주면 된다.

 

---

 

보통 법인별로 담당자가 붙어서 작업하기 때문에, 법인간 공통적으로 사용하는 field 목록을 실시간으로 공유하기 어렵다. 그래서 이미 field값을 trigger로 활용하여 개발이 완료하였는데, 프로젝트 중후반에 이르러서야 field값 통합 작업이 이루어지고, 이 때문에 연계된 개발 소스를 다시 손봐야하는 경우가 발생한다.

 

따라서 이번 작업을 통해 다국어 설정, field value 표준화와 같이 사소해보이는 요소가 프로젝트 후반부 타임라인을 관리하는 데에 영향을 미칠 수 있다는 것을 느끼게 되었다. 특히 이런 시스템을 구축하는 것이 결국 고객 정보를 효과적으로 적재하기 위함인데, 사소한 문제라고 생각하여 단순히 로컬 언어별 pickvalue를 추가하는 방식으로 접근한다면 추후 고객의 만족도가 떨어질 것이다. 따라서 언어 설정에 상관 없이 데이터 관리가 용이하도록 데이터 표준을 설계해야 한다.

 

사전에 이런 일을 방지하기 위해서는 법인별 담당자간에 식별된 data field 목록에 대해서 실시간으로 공유가 이루어지는 것이 제일이다. 하지만 당장 각 법인별 이슈를 해결하는 것에 집중하기 때문에 다른 법인의 field 목록까지 신경 쓴다는 건  현실적으로 어려움이 있다.

 

이에 대해 아직 명확한 솔루션을 생각하기는 힘들지만, 표준 모델을 바탕으로 여러 법인에 rollout하는 경우에는, 인터페이스 스펙 설계 단계에서 법인별 담당자들간의 정보 공유를 격려한다면 조금이라도 미리 이러한 문제를 인지할 수 있지 않을까.