소프트웨어 번역이 어색하게 되는 이유 (22)

한국어로 번역된 소프트웨어를 쓰다 보면 코웃음이 나오는 정도로 어색하게 번역이 되는 경우를 종종 본다. 물론 전문 번역가를 활용하지 않고 구글번역기를 이용해서 번역을 할 경우는 웃기는 경우가 많이 벌어진다. 하지만 전문 번역가가 번역을 하더라도 제대로 번역이 안되는 경우가 많다.

예를 들어 "Pan"이라는 말을 번역하려고 한다. "Pan"이라는 단어를 전세계 수십 나라의 번역가에게 보내면 어떻게 번역을 해올까? 많은 나라에서 "빵"이라고 번역을 할 것이다. 그리고 "프라이팬"으로 번역하는 번역가도 있을 것이다. 이렇듯 번역할 메시지만 보고 번역을 한다는 것은 거의 불가능에 가깝다. 그래서 번역 가이드가 필요한 것이다. 번역할 메시지만 번역가에게 전달하는 것이 아니라 어떻게 번역해야 하는지 방법도 전달해야 한다.

"Open"이라는 메시지를 번역해야 한다고 생각하자. 번역가에게 무엇을 알려줘야 번역을 제대로 할 수 있을까? 한국어로는 어떻게 번역이 될지 생각해보자. "열기"? "열어라"? 어떤 투로 번역을 해야 하는지 알려줘야 할 것이다. "명사입니다."라고 가이드를 주면 "열기"로 번역을 할 수 있을 것이다. 물론 번역 가이드는 전세계 수많은 나라의 번역가가 봐야 하므로 영어로 기록을 해야 한다. "It is a noun"과 같이 남기면 된다. 또한 "첫 글자는 대문자를 유지해주세요."와 같은 가이드도 남길 수 있다. 

그럼 번역 가이드를 남기는 방법과 어떤 가이드를 남겨야 하는지 알아보자.

번역 가이드는 별도의 파일이 따로 남기는 것이 아니라 소스코드의 메시지와 같이 기록해야 한다. 별도의 문서에 번역 가이드를 남기는 것은 관리가 너무 어렵기 때문이다. 프로그래머가 소스코드에 메시지를 기록할 때 번역 가이드를 동시에 적고 메시지를 추출할 때 자동으로 번역 가이드도 같이 추출되도록 해야 한다.

소스코드에 번역 가이드를 남기는 방법은 크게 3가지가 있다. 물론 번역 라이브러리에 따라서 지원하는 방법이 다르고 번역 가이드를 지원하지 않는 것도 있다. 번역 가이드를 지원하는 번역 라이브러리를 사용하는 것이 좋다.

첫째, 메시지 앞에 주석으로 남기는 방법이다. TRGUIDE라는 키워드는 번역 라이브러리마다 다를 수 있으며 사용자가 표준을 따로 정해서 지정해줄 수도 있다.

/* TRGUIDE: It is a noun. */

번역함수("Open");

둘째, 메시지 뒤에 주석으로 남기는 방법이다.

번역함수("Open");  // TRGUIDE: It is a noun.

셋째, 번역함수의 인자로 가이드를 추가하는 방법이 있다.

번역함수("Open", "It is a noun.");

첫 번째와 두 번째 방법은 메시지를 연속으로 번역해야 할 때 약간 까다롭다. 세 번째 방법이라면 아래와 같이 번역함수를 사용할 것이다.

StringFormat함수(번역함수("%1 of %2", "%1, %2 will be replaced any word. Please consider the order in your language"), 번역함수("Leg", "It is a leg"), 번역함수("dog", "It is a big dog"));

하지만 첫 번째 방법이라면 아래와 같이 사용해야 한다. 

/* TRGUIDE: %1, %2 will be replaced any word. Please consider the order in your language */

StringFormat함수(번역함수("%1 of %2"), 

/* TRGUIDE: It is a leg */

번역함수("Leg"), 

/* TRGUIDE: It is a big dog */

번역함수("dog"));

두 번째 방법이라면 다음과 같이 사용한다.

StringFormat함수(번역함수("%1 of %2"), // TRGUIDE: %1, %2 will be replaced any word. Please consider the order in your language

번역함수("Leg"), // TRGUIDE: It is a leg

번역함수("dog")); // TRGUIDE: It is a big dog

그럼 번역 가이드에는 어떠한 내용들이 추가되어야 할까?

1. 대문자 또는 소문자를 유지해주세요. 첫글자만 대문자를 유지해주세요. 이 경우 대소문자가 없는 언어라면 무시를 할 것이고, 대소문자가 있는 언어라면 가이드대로 번역이 될 것이다.

2. 메뉴 또는 버튼에 쓰이는 단어이니 명사로 번역해주세요. 명령어로 번역을 해주세요.

3. 이 단어는 번역하지 말아주세요. 고유명사입니다.

예를 들어 골프 선수 이름인 "Tiger Woods"를 번역해야 한다고 하자. 아무런 가이드가 없다면 "호랑이 나무"로 번역이 될 수도 있다. "사람 이름입니다."라는 가이드를 주면 "타이거 우즈" 정도로 번역을 할 것이다. 이렇듯 회사 이름, 지역 명 등 고유 명사는 적절한 가이드가 필요하다.

한화(당시 한국화약)의 고위임원이 1990년에 중국 정부를 방문했는데"환영 남조선 폭파집단"이라는 환영 플랜카드가 걸린 것을 보고 회사이름을 "한화"로 바꾼 계기가 되었다는 일화도 있다.

4. %1, %2는 다른 단어로 교체가 될 수 있으니 순서를 고려해주세요.

5. 이 단어는 반도체 관련 단어입니다. 번역을 하지 말거나 용도에 맞게 번역해주세요.

같은 단어라고 하더라도 분야별로 의미가 다른 경우가 많다. 따라서 어떤 분야의 단어인지 또는 그 뜻을 정확하게 설명해주는 것이 좋다. 개발자는 단어를 적을 때 번역가가 헷갈려 할 수 있다는 것을 생각해야 한다. 물론 그런 판단을 하는 것이 쉬운 것은 아니다.

6. 약어인 경우 원래 의미를 적어주는 것이 좋다. 그렇지 않으면 약어는 정말 엉뚱하게 번역이 될 수도 있다. 전세계 표준 약어라고 하더라도 영어로 된 약어를 받아들이지 않는 나라도 많다. 따라서 약어의 줄이기 전 원래 단어를 알려줘야 제대로 번역이 될 수 있다.

7. 문화의 차이에 따라서 잘 알지 못할 수 있는 단어는 의미를 자세히설명해주거나 해당 단어를 잘 설명하고 있는 웹사이트 주소를 같이 적어주는 것도 좋다. 이때 Wikipedia 주소를 추가하기도 한다.

대부분의 번역가는 번역 가이드가 없어도 최대한 번역을 한다. 하지만이러한 번역가의 자세가 번역을 엉터리로 되게 하기도 한다. 대부분의번역가는 번역회사와 계약 관계에 있는 계약직 번역가이며 외국어를 전공한 학생이기도 하고 외국에서 살다온 사람일수도 있고 전문 번역가인 경우에도 있다. 번역가는 번역 단어수로 수입이 결정되기 때문에번역이 애매할 경우 적극적으로 해결하려는 경우는 그리 많지 않다. 그래서 소프트웨어 개발사에서 적극적으로 번역의 품질을 높이기 위한 정보를 제공해야 한다.

우리가 번역 라이브러리 또는 프레임워크를 사용할 경우 번역 가이드를 지원하는 것을 선택해야 한다. 또한 전 과정은 자동화가 되도록 해야 한다. 프로그래머가 영어 실력이 부족하여 번역 가이드와 영어 메시지를 문법에 맞고 자연스럽게 적는 것이 어려운 경우라면 개발 과정에서 이를 감수해서 수정해주는 프로세스를 적용해서 개발이 끝나고 번역을 위해서 메시지를 추출할 때는 소스코드에 제대된 영어 문장이 존재하게 하면 된다.

필자가 설명하는 하나하나의 과정은 소프트웨어 국제화 품질을 올려주는 과정이고 이런 것들이 모여서 소프트웨어가 해외에서 더욱 인정받는 길이 될 것이다. 아직 가야 할 길이 많이 남아 있다.

개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화 중 하나는 '공유’ 문화라고 할 수 있다. 소프트웨어개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20년, 30년 계속 개발자로 일할 수 있도록 하는 기초 체력이기도 하다. 

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다. 내 주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다. 특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다. 하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은 잘 들려오지 않는다. 그 이유는 무엇일까?

여러 가지 이유가 있겠지만 그 첫 번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다. 

‘죄수 딜레마’라고 들어본 적이 있는가? 

상황은 다음과 같다. 두 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다.

•    둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

•    둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

•    둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

죄수A는 죄수B가 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다. 죄수B가 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A는 죄수B가 어떤 선택을 하든지 자백을 선택한다.

죄수B도 죄수A와 동일한 상황이므로, 마찬가지로 죄수A가 어떤 선택을 하든지 자백이 유리하다.

따라서 둘 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B 는 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건, 죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 더 빨리 교차로를 빠져나갈 수 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히있으면 교차로를 가장 늦게 통과하게 될 것이다. 심지어는 주변의 차들에게 욕먹을 각오도 해야 한다.꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 몇 배 더 손해를 보게 되어 있다. 그래서 어쩔 수 없이 다같이 손해를 보는 경우를 선택하게 된다.

몇 년 전 가족과 함께 괌의 한 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운 일을 목격했다. 수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다. 선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다. 몇 시간 후나타난 선배드의 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선배드를 찜 해놓고아침식사를 하러 간 것이었다. 사실 선배드는 모든 사람이 충분히 쉴 만큼 많았다. 하지만 이용도 하지않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀 쉴 곳이 없게 된 것이었다. 한국에서는 이런 현상이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지,바뀌었는지 알 수 없다. 어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드 몇 개를 찜 해 놓는 일에 동참하는 우리를 발견하게 되었다.

이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는확신이 없다면 약속은 순식간에 무너진다.

그럼, 규칙을 엄하게 적용하면 해결될 수 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 수있지 않을까? 이런 식으로 해결이 될 수 있었다면 우리나라의 대부분의 회사가 이미 공유문화가 잘 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

첫째 만들어 놓은 규칙이 엄격하기만 할 뿐 공유 문화 정착에 효과적인 경우가 별로 없다. 왜냐면 그엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해 본 적도 없는 사람들이기 때문이다. 대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이없다. 게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다. 문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들 수 있지만 진짜 필요한 내용이 다 들어 있는지 확인할방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜공유는 피해 다니게 되어 있다.

셋째 나만 공유를 제대로 하게 될 경우 나만 손해를 볼 수 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을내는 것도 안 된다. 현재 상황을 잘 파악해서 공유문화를 만들어 갈 수 있는 단계적인 접근이 필요하다. 개발자들이 소화할 수 있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과일치를 해야 한다. 이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 될 것이라는 확신을 직원들에게 심어주어야 한다.

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다. 그럼 비효율이 정착된 회사가 될것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.