UI TERM 자동 매칭툴, 쉽지 않았던 개발 에피소드 1

blog main banner

일본에서 매뉴얼 업계에 발을 디딘 지 얼마 되지 않았을 때의 일이다.

Scripted by
Marco
SYSTEM Div.
일본에서 매뉴얼 업계에 있을 당시

깨알 같은 글자들이 정렬해 있는 엑셀파일 뭉치와 모 기업 카메라 매뉴얼의 출력물이 팀원들에게 골고루 나누어졌다. 이른바 “User Interface Terminology(이하 UI TERM) 매칭 검수” 작업이 시작된 것이다.

수백 페이지 가량되는 매뉴얼 속 수천 수만 개의 글자 중 볼드(UI TERM)로 처리된 글자만 찾아내어, 엑셀 파일로 정리한 UI TERM 테이블과 대조하는, 그것도 생전 듣지도 보지도 못한 언어로 되어있는 것을 확인하는 일은 생각만으로도 아득해지는 그런 작업이었다.

DTP 작업에서의 UI TERM 텍스트
실제 웹매뉴얼에서 보여지는 UI TERM 텍스트 (왼쪽부터 영문, 터키, 아랍)

당시 이 업계에는 3대 난제로 꼽히는 일들이 있었는데, 그 중 하나가 바로 ‘UI TERM 매칭’이었다. 나머지 두 개에 대해서는 추후 기회가 있으면 자세히 다뤄보도록 하겠다. 앞서 말했듯이 이 UI TERM 매칭이란 것은 다국어 전개 시 매뉴얼의 품질을 좌우하는, 대단히 중요한 공정 중 하나이지만 사람이 하는 수작업이다 보니 번역가나 DTP 작업자의 실수로 매뉴얼의 UI TERM이 누락되거나 잘못 기입되거나 하는 치명적인 단점이 있었다. 이 당시에는 이러한 난공불락의 난제를 해결하기 위한 기술적 인프라가 턱없이 부족하였고, 모두가 한 마음 한 뜻으로 밤을 새우는 것이 미덕으로 치부되던 시절이기도 하였다.

앞서 얘기한 공정들은 늘 단가상승으로 이어져, 발주 기업과 매뉴얼 제작사 간의 견적 협상 도마 위에 자주 등장하는 단골 이슈가 되었다. 이는 DTP 프로그램 제작사나 현장의 개발 마인드를 가진 이들에게 공정 개선에 대한 의지를 조금씩 쌓게 만드는 계기가 되었다.

필자 또한 개선에 대한 의지를 가졌던 사람 중의 한 사람으로써 이 문제를 해결하기 위해 수 많은 시행착오와, 끊임 없는 장벽 앞에서 좌절과 희열을 함께 맛보았던 경험을 이야기해 보고자 한다.

다섯 가지 난관을 만나다

삼국지 속의 ‘관우의 오관 돌파’에 얽힌 이야기를 보면 관우가 조조를 떠나 다섯 곳의 관문을 뚫어 나가기 위해 적장들을 차례차례로 베어 나간다. 듣는 사람 입장에선 참 시원시원하게 앞으로 나아가는구나 싶겠지만, 정작 자신은 매 관문에 부딪칠 때마다 얼마나 힘들었을까 하는 생각이 든다. 아래는 UI TERM 자동 매칭툴을 구현하기 위해 돌파해야만 했던 대표적인 조건들의 사례이다.

첫 번째 관문: UI TERM의 위치는 다국어 번역 후 변경될 수 있다.

세상 모든 언어의 문법이 모두 같다면 얼마나 좋을까 하는 생각을 이 첫 번째 장벽에서 하게 되었다. 도큐먼트 속의 UI TERM들이 번역 후에도 차례대로 유지되어만 준다면 엑셀 파일로 정리한 다국어 UI TERM들을 차례대로 대입해서 해결할 수 있는 노릇이건만, 실제로는 그렇게 간단하지 않았다.

영어와 다국어의 예를 들어 보자.

English On the Applications screen, tap Settings Accounts and select Google under My accounts, select the Google account, and then tick Sync Calendar.
Taiwan 在應用程式螢幕上,輕觸設定 帳號,然後選擇位於我的帳號之下的 Google,選擇 Google 帳號,然後勾選同步日曆
PRC 在应用程序屏幕上,点击设置 帐户,然后选择位于我的帐户下的 Google,选择 Google 帐户,然后勾选同步日历

때문에 우리는 UI TERM에 고유한 ID가 필요함을 알게 되었다. 순서가 뒤틀려도 도큐먼트 속의 UI TERM과 엑셀 파일에 테이블로 정리한 UI TERM이 서로 같은 ID를 가질 수만 있다면 되지 않을까? 그러나 엑셀 테이블의 UI TERM에는 고유 아이디를 붙일 수 있다 치더라도, ‘도큐먼트 속의 UI TERM에는 어떻게 고유 아이디를 붙일 것인가’가 우리를 고민스럽게 했다. DTP 작업이나 번역 작업에 지장을 주지 않으면서도 도큐먼트 속에 UI TERM의 고유한 아이디 정보를 숨겨 놓아야 하는 일은 불가능에 가까워 보였다. 이렇게 우리 앞을 막아선 첫 번째 장벽 앞에서 한참을 서성이며 고뇌했던 기억이 난다.

두 번째 관문: UI TERM은 새로 만들어지기도, 사라지기도 한다.

도큐먼트는 살아 있는 생명체처럼 출판되기 전까지 계속해서 성장한다.

매뉴얼의 경우 베이스 언어를 바탕으로 1차 매뉴얼이 만들어진 후에도 제품의 중도 버전 업그레이드나 개발 방향 전환 등에 의해 몇 번이나 수정되기 마련이다. 즉, 도큐먼트 안에는 새로 만들어지는 문장들과 사라지는 문장들이 있고, 그 변화에 UI TERM도 예외일 수는 없다는 것. 그래서 최초에 만들어졌던 개수에서 늘거나 줄어들 가능성이 생기는 것이다.

이렇게 도큐먼트 속 UI TERM의 변화를 자동으로 감지하면서, 고유 아이디를 붙여줘야만 하는 두 번째 난관에 봉착했다.

세 번째 관문: UI TERM은 프리 스타일이다.

일반적으로 도큐먼트 DTP 작업 시 UI TERM에 해당하는 텍스트에 UI TERM 문자 스타일을 적용한다. 작업자들과 최종 사용자들이 다른 문자들과 UI TERM을 쉽게 구분할 수 있게 하기 위함이다. 그런 점에서 UI TERM은 하나의 문자 스타일만을 고집하는 것이 아니라, UI TERM-bold나 UI TERM-Italic 등으로 파생될 수도 있다.

UI TERM 문자 스타일 적용

때문에 UI TERM 매칭을 위해서는 도큐먼트 안에서 하나의 문자 스타일만 찾아내는 것이 아니라 여러 종류의 문자 스타일을 찾아내야 하고, 그 결과를 엑셀 파일에 차례로 정리할 수 있어야 한다.

네 번째 관문: UI TERM은 1 대 1이 아니라 1 대 多 매칭이다.

UI TERM 테이블은 베이스 언어를 기준으로 해당하는 UI TERM이 각 언어별로 정렬되어 있는 표이다. 예를 들자면 아래의 그림과 같다.

UI TERM 테이블

베이스 언어가 영문이고, UI TERM 중 “High”라는 단어가 있다고 하자.

한국어로는 아마도 “높음”이라고 번역할 수 있겠다. 그러나 도큐먼트 내에서 “High”라는 글자가 쓰인 곳 어디에서나 동일한 의미로 번역될 수 있을까? 당장 구글 번역기에 High라는 글자를 입력해봐도 “짙은”, “주요한”, “고매한”, “고급의”, “고도의”, “비싼” 등으로 다양하게 번역된다.

이런 경우에는 아래와 같은 형태의 UI TERM 테이블이 만들어 진다.

ID English Korea
1 High 높음
2 High 짙음
3 High 고급
4 High 비쌈

또 하나 예를 들자면,

샘플
UI TERM 리스트

도큐먼트 내 UI TERM으로 쓰인 글자가 가지고 있는 다양한 의미 중 어떤 의미로 사용되었는지는 사람이 직접 살펴보면 알 수 있지만, 기계는 이것과 UI TERM 테이블에 있는 연관성에 대해 알지 못한다.

즉, 프로그램 상에서 여러 개의 UI TERM을 제시해주면 사람이 그 중 하나를 선택할 수 있도록 하는 UI를 제공해야 한다.

다섯 번째 관문: UI TERM의 위치 정보가 있어야 한다.

도큐먼트에서 모든 UI TERM을 추출하고, 리스트로 만들어 엑셀 파일의 UI TERM 테이블과 매칭시키기만 하면 우리는 만사 OK인 줄 알았다. 그러나 앞서 말한 UI TERM 매칭 대상의 다양성 때문에 우리는 추출된 UI TERM 리스트가 도큐먼트 내 어디에 위치해 있는지를 알 수 있어야 했다. (참을성이 많고 부지런한 사람들은 찾을 수 있다. 시간만 있다면..)

따라서 추출된 UI TERM 리스트에는 각 UI TERM의 위치 정보가 포함되어야만 한다.

눈 앞에 펼쳐진 또 다른 난관, 그리고 도전

이 난관들을 다 헤쳐 나오고 나면 비로소 UI TERM 자동 매칭을 구현할 수 있는 기본적인 준비 태세를 갖추었다고 할 수 있다.

그러나 모든 길이 하나의 길로 통하지 않는 것처럼 보다 근본적인 부분에서 우리는 다시 한 번 생각해 볼 필요가 있다. 앞의 내용에서 끊이지 않고 나왔던 ‘UI TERM 테이블’은 과연 얼마나 신용할 수 있는 데이터인가 하는 문제에서부터 그렇다면 어떤 공정을 통해서 만들어져야만 하는 것인가 등에 대한 이야기는 또 다른 카테고리 안에서 본격적으로 다루어도 그 내용이 만만치 않아 보인다.

그렇다고 해서 너무 일찍 실망하거나 좌절하지 말기를 바란다. 모든 길에서 만나는 난관이나 벽들은 늘 우리를 되돌아가게 하거나 서성이게 만들지만, 지금 필자가 여기에서 이 글을 쓰고 있다는 것은 어느 정도 완성된 단계에서의 성공을 거둔 후라는 사실을 위로로 삼기 바란다.

적어도 하나의 관문을 지치지 않고 넘어가보면 보다 큰 세상이 기다리고 있음을 알게 되고, 그 희열을 통해서 우리는 또 하나의 관문을 포기하지 않고 돌파할 수 있는 힘을 얻게 된다.

영화 ‘인터스텔라’의 명대사처럼 “우린 답을 찾을 것이다. 늘 그랬듯이”

Our Success Story

이런 경험과 인식을 바탕으로, 한샘EUG는 “Weaver”라는 이름의 UI TERM 자동 매칭툴을 성공적으로 개발 완료하였고 2018년부터 현장에 투입했다. UI TERM 자동 매칭툴의 도입은 콘텐츠의 다국어 현지화 작업에 잠재되어 있던 휴먼 에러를 혁신적으로 줄였고 다국어 현지화 콘텐츠의 안정적인 품질 관리 및 효율적인 제작 프로세스 운영에 크게 기여하고 있다.

LIST

  • Hansem Story

    중국 우한팀의 오피스 이전

    중국 우한팀의 오피스 이전

    5. 8, 2019

  • Hansem Story

    2019 World IT show 컨퍼런스 참관기 1

    2019 World IT show 컨퍼런스 참관기 1

    5. 3, 2019

  • Posts

    Developing Quality Technical Information_2. 사용자 중심으로 잘 만들어졌는가

    Developing Quality Technical Information_2. 사용자 중심으로 잘 만들어졌는가

    4. 30, 2019