왜 소프트웨어 번역의 기준은 영어가 되어야 하는가? (20)

이전 글에서 소프트웨어 번역 프로세스의 제 1원칙은 메시지 키는 영어 자체여야 한다고 했다. 즉, 번역의 기준은 영어여야 한다는 것이다. 
 

 현재 시중에 나와 있는 수많은 번역 함수들은 이 제 1원칙에 어긋나있다. 개발자들도 제 1원칙에 어긋난 수많은 방법을 이용해서 소프트웨어 번역을 하면서 수많은 문제가 봉착하고 있다. 

대규모 프로젝트들이 MS개발툴, Java 등 널리 쓰이는 개발툴에서 제공하는 번역 함수들을 그대로 이용해서 번역을 하고 있다고 착각하고 있는 개발자들이 매우 많다. RC파일을 이용해서 메시지가 10,000개,지원하는 언어(로케일)가 30개인 프로젝트를 수행해 낼 수 있다고 착각한다. 할 수도 있겠지만 너무 비효율적이고 거의 불가능하다. 대부분의 대규모 프로젝트에서는 오픈소스 또는 내부에서 개발한 번역 함수와 자동화된 번역 프로세스를 통해서 해결하고 있다. 이를 위해서 매우 전문적인 소프트웨어 국제화 담당자들이 활약하고 있다.

우리나라에서도 대규모 프로젝트에서는 스스로 개발한 번역 함수와 번역 프로세스를 사용하곤 하지만 원칙에 어긋나거나 완전 자동화에 실패를 해서 빠져 나오기 어려운 문제에 봉착하곤 한다. 

그럼 번역의 기준이 되는 메시지의 키는 어떤 것들이 있으며 영어가 아니면 왜 문제가 되는 것일까? 번역 함수에 “메시지 키”를 넘겨주면 “번역된 메시지”가 넘어 온다.
 번역된 메시지 = 번역함수(메시지 키)

"번역함수"에는 여러가지고 있고 물론 자동으로 번역을 해주는 함수가 아니고 번역가가 번역한 메시지를 소프트웨어서 보관하고 있다가 사용자가 사용하는 언어로 변경 해주는 함수를 말하는 것이다.

개발자들이 번역을 위해서 사용하는 메시지의 키는 대략 4가지 정도가 있다.
1. 숫자
2. 심볼
3. 한국어
4. 영어
 

첫 번째 숫자부터 알아보자. 번역의 기준을 숫자로 사용하는 방법은 매우 오래된 방법이다.
번역함수(1) => 사과
번역함수(2) => 딸기
이렇게 사용하는 방법이다. 이 방법의 문제점은 숫자를 잘 관리해야 한다는 점이다. 번역이 필요한 메시지를 새로 추가할 때 기존의 숫자들과 중복되지 않는 숫자를 찾아야 하고 삭제할 경우에는 해당 메시지가 더 이상 정말로 사용되지 않는지 면밀히 검토를 해야 한다. 이런 번거로운 절차를 자동화하는 툴들도 있지만 잘 동작하지 않는 경우가 많았다. 또한 숫자를 보고 바로 번역할 수 없으므로 영어 메시지를 전달해야 하고 영어 번역이 바뀌면 다른 언어도 번역을 변경해야 하는데 이를 관리하는 것이 너무 어렵다. 숫자를 기준으로 번역하는 것은 함수는 간단해 보이지만 관리가 너무 어려워서 이제는 거의 쓰이지 않는다.

두 번째 심볼을 쓰는 방법은 가장 널리 사용되고 있다.
번역함수(MSG_CLOSE) => 닫기
번역함수(BUTTON_OPEN) => 열기
이렇게 사용하는 방법이다. 이 방법은 숫자에 비하여 심볼을 보면 대충 무슨 의미인지 알 수 있어서 개발자들이 메시지 파일을 뒤지지 않고도 심볼을 기억해서 사용할 수도 있고 엉뚱한 메시지를 사용할 위험성이 줄어든다. 하지만 이 방법에도 치명적인 몇 가지 문제가 있다. 먼저 매번 새로운 메시지가 추가될 때마다 심볼을 정해야 한다. 이때 다른 동료와 동시에 같은 심볼을 정해서 충돌이 날 수도 있고, 기존에 사용된 심볼을 없는 줄 알고 다시 쓰는 문제도 발생할 수 있다. 이 또한 삭제할 메시지를 정하는 것이 매우 어렵다. 실수로 삭제하는 위험성 때문에 삭제는 영원히 안하는 회사도 있다. 그러면 새로 지원하는 언어가 늘어 날 때마다 사용도 안하는 메시지를 번역하는 일도 생긴다.
 

번역가에게는 영문 메시지파일을 전달해서 여러 언어로 번역을 요청하지만 나중에 영어가 바뀌면 바뀐 메시지만 다시 각 언어별로 번역을 요청하는 것이 너무 어렵다. 바뀐 영어 메시지를 찾고 관리하는 것도 어렵지만 번역가에게 몇 개의 메시지만 번역을 변경해달라고 요청하기도 힘들다.
어떤 소프트웨어가 v1.0에서 3,000개의 메시지를 번역했다고 하자. 그런데 v1.1에서 500개의 메시지가 삭제되고 500개는 영어 메시지가 수정되었고, 1,000개의 메시지가 추가되어서 최종 3,500개의 메시지가 되었다고 하자. 그럼 번역가에게는 1,000개는 새로 번역을 요청하고 500개는 번역 수정을 요청해야 한다.
어떤 메시지가 수정할 메시지이고, 삭제될 메시지, 추가된 메시지를 버전 별로 관리하고, 번역가에게 보내고, 번역된 메시지를 메시지 파일과 통합하는 일련의 프로세스가 얼마나 복잡한지 대규모 프로젝트의 번역 프로세스를 담당해본 개발자라면 잘 알 것이다
이런 과정에서 문제가 없이 번역 프로세스를 처리하는 것은 거의 불가능하며 수많은 버그를 포함하게 된다. 번역이 누락된 경우 “MSG_CLOSE”와 같은 심볼이 출력되기도 한다.
메시지 키에 심볼을 사용하는 이상 이런 복잡한 프로세스를 피해가기 어렵다.

세 번째는 한국어를 메시지 키로 사용하는 방법이다.
번역함수(닫기) => Close
번역함수(열기) => Open
이 방법은 먼저 영어로 번역을 한 후에 다른 언어로 번역을 해야 하기 때문에 번역 프로세스가 더 오래 걸린다. 그렇게 널리 쓰이는 방법은 아니다.

이 방법이 좋다고 생각하는 경우 한국어에서 영어, 한국어에서 일본어와 같이 우리와 친숙한 언어들을 위주로 지원하고 한국어를 잘아는 번역가를 활용을 하기 때문이다. 이렇게 한국어를 기준으로 변역해도 별 문제가 없는 경우도 있지만 대부분의 번역가는 영어와 해당언어의 전문가들이다. 한국어는 그 중에 하나의 언어인 경우가 많다.

이 방법은 지구가 우주의 중심이라고 생각하는 것과 같다. 그렇다고 영어가 우주의 중심이라는 사대주의적인 얘기는 아니다. 전세계 번역가를 충분히 활용하려면 그 중심은 영어라는 얘기다.

마지막으로 메시지 키로 영어를 쓰는 방법이다.
번역함수(Close) => 닫기
번역함수(Open) => 열기
이와 같이 개발자는 소스코드에 번역할 영어 메시지를 그대로 사용하는 것이다. 이 방법의 장점은 개발자가 소스코드에 영어 메시지를 적는 것 외에 아무 것도 할 것이 없다는 것이다. 심볼 이름을 정하려고 고민할 필요가 없고 심볼 이름이 중복될 까봐 고민할 필요도 없다. 다른 개발자가 동시에 Open이라는 메시지를 번역하려고 소스코드에 추가를 해도 충돌이 나지는 않는다. 삭제된 메시지를 개발자가 수동으로 찾아서 삭제를 할 필요도 없다. 이를 자동으로 찾아주는 툴이 있기 때문이다. 그리고 번역이 누락되면 화면에 영어로 출력된다. 숫자나 심볼로 출력된 것보다는 소프트웨어를 사용 할만 하게 된다. 이 방법의 가장 큰 특징은 번역을 제외한 전 과정이 완전 자동화가 가능하다는 것이다.
이 방법의 유일한 단점이 우리나라 개발자들이 영어 메시지를 제대로 만들어 내지 못한다는 것이다. 개발자가 영어를 너무 못하고 영어에 거부감이 커서 한국어를 키로 사용한다면 장기적으로는 여러 문제에 봉착한다. 그보다는 이를 해결하기 위해서 별도의 프로세스가 추가해서라도 영어를 키로 쓰는 것이 장기적으로는 낫다.

이 글에 의심을 품고 이의를 제기할 개발자가 많다는 것을 잘 알고 있다. 흔히 RC 파일 등에서 자주 쓰이는 심볼 방식이 무엇이 문제인지, 지금까지 문제 없이 잘 쓰고 있다고 주장하는 사람도 많다. 전에도 얘기를 했지만 아주 작은 소프트웨어, 적은 지원 언어를 처리하는 상황이라면 무슨 방법을 써도 문제가 안 된다. 또한 기존 방법의 수동 프로세스를 당연하게 생각하고 있다면 어떠한 조언도 귀에 들어오지 않을 수 있다. 필자는 20년 넘게 소프트웨어를 개발하면서 대부분의 독자들이 경험한 국제화 방법을 거의 경험해 봤고 문제를 다 겪어봤다. 
 
필자는 분명히 말할 수 있다. 나중에 대규모 프로젝트에서 소프트웨어 국제화를 적용할 때 이 원칙을 무시하면 소프트웨어 국제화 때문에 프로젝트에 실패하는 일이 발생할 수 있다. 지금 마음을 열고 소프트웨어 국제화의 원칙을 이해하려고 노력해야 한다. 대규모 프로젝트를 수행하게 될 기회는 개발자에게 언제든지 올 수 있다. 그때를 위해서 몸에 익혀놔야 한다.
 
작은 프로젝트라고 하더라도 원칙을 지키고 번역 프로세스를 완전 자동화하는 것이 훨씬 효율적이다. 그런 과정을 통해서 제 1원칙의 원리를 몸에 익히는 것이 필요하다.

항상 보스가 먼저 말하게 하라.

오늘 재미있는 글을 봤습니다. 그래서 공유를 할까 합니다.

A junior manager, a senior manager and their boss are
on their way to a meeting.
길이었다.

On their way through a park, they come across a wonder lamp.
이들은 공원을 지나다가 신기한 램프를
발견했다.
They rub the lamp and a ghost appears.

The ghost says,
유령이
말했다.
"Normally, one is granted three wishes but as you are three, I
will allow one wish each"

들어주겠다."
So the eager senior manager
shouted,
그러자 성격 급한 고참 부장이 소리쳤다.
"I want the
first wish. I want to be in the Bahamas , on a fast boat and have no worries."
“제가 먼저 소원을 빌게요. 저는 바하마 제도에 가서 쾌속정을 타면서 근심․걱정을 떨쳐버리고
싶어요.”
Pfufffff, and he was gone.


이번에는 신참부장이 얌전히 있지 못하고 소리쳤다
"I want to be in
Florida with beautiful girls, plenty of food and cocktails."
“저는 플로리다에 가서 맛있는 음식과 칵테일을 마시면서 예쁜 여자들과 지내고
싶어요.”
Pfufffff, and he Was also gone.
휭 소리와 함께
후임 과장도 사라졌다.
The boss calmly said,
그러자 사장이 나직한 목소리로 말했다.
"I want these two idiots
back in the office after lunch at 12.35pm."
“나는 이
멍청한 두 녀석이 점심 먹고 오후 12시 35분까지 사무실로 돌아오길 바랍니다.”

SPEAK FIRST."
* 이야기의 교훈: “항상 윗사람에게 먼저 말할 기회를 양보하라.

신참 부장과 고참 부장, 그리고 사장이 회의장으로 가는

 램프를 문지르자 한 유령이 나타났다.

"보통 한 명에게 세 가지 소원을 들어주지만, 너희는 셋이니 한 명당 하나씩 소원을

휭 소리와 함께 고참 부장은 사라졌다.

Now the junior manager could not keep quiet and shouted

* MORAL OF THE STORY IS: "ALWAYS ALLOW THE BOSSES TO 

(출처 영어등대이찬승)

오늘의 잡담 - 개발자와 영어

이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다.

나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다.

대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다.

이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 경쟁하는 것과 같다고 생각합니다.

일단 소프트웨어 업계로 들어서면 너무 바빠지는 것이 일반적이라서 개발자가 왠만해서는 영어 공부를 하기 쉽지 않습니다. 학교 다닐 때 미리미리 영어 공부 유창하게 될 때까지 하고 오세요.

이미 개발자로 일하고 있고, 영어가 부족하다면 음... 알아서 꾸준히 공부하세요.

참고로 제 개인 블로그(http://raymond.pe.kr)에서는 영어 공부에 대한 주제로도 글을 꾸준히 올리고 있습니다. 혹시 영어 공부에 관심이 있으시다면 미미하나마 도움이 되면 좋겠네요.

"영어는 가까이하기엔 너무 먼 당신이다" - 매우 다가갔다고 생각하면 어느덧 또 멀어져 있는.......