레이블이 번역인 게시물을 표시합니다. 모든 게시물 표시
레이블이 번역인 게시물을 표시합니다. 모든 게시물 표시

2015년 6월 27일 토요일

소프트웨어 번역을 효율적으로 하는 방법 (23)

국제화 개발팀에서 근사한 번역함수를 만들어 준다고 해도 번역이 잘 되도록 번역함수를 사용하는 것이 쉬운 것은 아니다. 특히 주니어 개발자들이 소프트웨어 번역의 원리를 이해하지 못하고 번역함수를 잘못 사용해서 번역가가 아무리 번역을 잘해도 이상하게 되는 경우가 있다. 

그래서 번역이 효율적으로 되도록 하고 번역함수가 제대로 동작하게 하려면 어떻게 해야 하는지 알아보자.


1. 용어 사전을 만든다.

번역에 있어서 용어사전(Dictionary)를 만드는 것은 매우 중요한 활동이다. 잘 정리된 용어사전은 번역이 일관되게 하며 여러 번역가가 협업을 할 때 같은 용어를 사용할 수 있도록 한다. 

영어에는 같은 뜻이지만 다른 단어가 엄청나게 많다. 따라서 용어사전에는 해당 뜻일 경우 어떤 단어를 사용하라는 지침이 포함된다. 이렇게 영어를 기준으로 용어사전을 만들면 번역가들은 각 로케일별로 각각 용어 사전을 만들어 달라고 요청을 하는 것이 좋다. 여기서 언어별이 아니고 로케일별인 이유는 스페인의 스페인어와 멕시코의 스페인어의 용어사전이 다를 수 있기 때문이다.
이렇게 용어 사전을 만들어 놓으면 나중에 번역회사를 교체해도 일관된 번역을 유지하기 좋다. 

2. 번역의 기준이 되는 영어 문장은 최대한 간결하고 번역이 쉬운 용어를 사용한다.

소프트웨어는 문학작품이 아니고 문법 시험이 아니다. 소프트웨어에서 사용하는 용어는 소프트웨어를 이해할 수 있는 정도로 최대한 간결하고 번역이 쉬워야 한다. 올바른 문법을 주장하다가 문어체 문장으로 도배를 하면 오히려 어색한 경우도 많다. 

용어 선택도 주의를 해야 한다. "Hard"라는 단어보다는 "Difficult"가 좋다. 예를 들어 실생활에서는 "Hard"를 더 많이 쓴다고 하는 경우라도 번역에 오해가 없는 "Difficult"를 쓰는 것이 더 좋다. 

3. 대소문자 번역을 효율적으로 한다.

Open, OPEN, open을 각각 번역하면 3번 번역을 해야 하고 비용도 3배 더 나간다. 한국어로는 모두 "열기"다. 이런 경우 "open"하나만 번역을 하고 대소문자 변환 함수를 이용해서 변환하여 사용하는 것이 효율적이다. 대소문자를 처리하는 로케일 카테고리 표준은 LC_CTYP이다. LC_CTYPE의 영향을 받는 대소문자 변환 함수를 사용하면 로케일에 따라서 적절히 대소문자를 변환해준다.

C언어에서는 strlwr, strupr, wcslwr, wcsupr, stricmp, wcsicmp 등이 있다. 내가 바퀴를 다시 만들 필요는 없고 있는 함수를 쓰면 된다.

4. Broken sentence를 피한다.

대표적인 Broken sentence는 한 문장을 통째로 번역하지 않고 단어들을 쪼개서 합치는 것이다. 이렇게 쪼개진 단어들을 번역하기도 어려울 뿐만 아니라 어쨌든 번역을 해도 언어별로 어순이 달라서 이상한 문장이 되게 된다. "Leg of dog"을 쪼개서 번역하면 "다리의 개"가 될 수도 있다.

문장은 온전한 문장을 통째로 번역해야 하며 문장을 분리하는 기준은 각 언어의 특성을 어느 정도 알아야 효과적으로 정할 수 있다.

반대로 쪼개야할 문장을 하나로 연결해서 번역을 할 경우 번역해야 할메시지가 엄청나게 늘어나는 경우가 있다. 번역가는 이렇게 반복되는 패턴을 발견해도 이상 여부를 알리지 않고 기계적으로 번역하는 경우가 많다. 번역가는 오히려 이런 현상을 환영한다. 번역은 쉽고 수입은늘기 때문이다. 번역할 문장을 적당히 자르는 것은 개발자의 몫이다.

5. 메시지 표준을 정한다. 

보통 여러 개발자가 함께 소프트웨어를 개발하기 때문에 개발자들이 작성한 영어 문장이 서로 상당히 다른 경우가 있다. 용어사전이 있다고 하더라도 일관되게 사용하기는 쉽지 않다. 몇몇 회사는 소프트웨어에서 사용하는 모든 메시지를 전문팀에서 정해주곤 하는데 100% 커버하기는 쉽지 않다. 개발자가 문장을 결정해야 하는 경우도 많다. 이럴 때 지켜야 할 규칙을 정해야 한다.

예를 들어 문장의 끝에는 마침표를 찍을지 말지, Cannot을 쓸지 can’t를 쓸지? 등과 같은 사소한 규칙들의 집합일 수도 있다. 이런 표준은 발견될 때마다 조금씩 보강해나가면 된다.

6. 번역 제외 메시지 표시 함수를 정한다. 

가끔은 번역을 하면 안되는 메시지들이 있을 수 있다. 그런 메시지는 번역을 하지 않아도 되니 번역함수를 사용하지 않고 그냥 놔두는 경우가 있다. 이렇게 해도 소프트웨어는 문제없이 동작한다. 하지만 이 소스코드를 본 어떤 개발자가 번역함수가 누락된 것으로 착각을 하고 번역함수로 메시지를 감싸는 경우가 발생한다.

예를 들어 "IT"라는 단어가 소프트웨어에 있고 절대 번역을 하면 안되는데 이를 본 개발자가 번역함수("IT")로 바꿔놨다고 하자. 그러면 또 이 단어를 수십개의 언어로 번역을 해야 한다. 비용은 비용대로 들고 이 단어가 번역이 돼서 문제가 발생하기도 한다.

번역을 하면 안되는 단어는 화면에는 출력이 되지만 번역을 하면 안되는 경우와 화면에는 출력이 안되고 소프트웨어 내부적으로만 사용을 하는 경우가 있다. 소프트웨어 내부적으로 사용하는 단어를 번역해버리면 소프트웨어가 동작하지 않기도 한다. 또한 로그 등 번역을 할 필요가 없는 경우도 있다.

이런 일을 방지하기 위해서는 번역 제외 표시 함수를 사용하는 것이 좋다. 번역제외("IT") 이렇게 해놓으면 어느 누구도 실로 번역을 하게 만들지는 않는다. 물론 번역제외 함수는 아무 일도 하지 않고 원래 메시지 그대로 넘겨줄 뿐이다.

번역 제외 함수는 번역 라이브러리나 프레임워크에 따라서 다르며 지원하지 않는 경우도 있다. 이런 경우는 번역제외함수를 직접 만들어서사용하면 된다.

7. 번역가에게 번역가이드를 전달한다.

지난번에 얘기를 했듯이 메시지 별로 번역가에게 어떻게 번역을 해야 하는지 번역 가이드를 전달해야 한다.

8. 메시지 파일은 UTF-8으로 인코딩한다.

국제화가 잘된 소프트웨어는 멀티바이트보다 유니코드를 지원하도록 개발하는 것이 여러모로 편리하고 자잘한 문제도 적다. 번역가에게 메시지 파일을 보내서 번역을 요청할 때 최초의 파일은 ASCII 인코딩일 가능성이 높다. 메시지키가 영어이기 때문이다. 이때 번역가들은 자국의 인코딩을 이용해서 번역을 해 오는 경우가 종종 있다. 이때 UTF-8으로 인코딩을 해달라고 요청하는 것이 좋다. 이때 지난번에 언급했듯이 Windows의 Notepad를 이용하면 BOM이 따라 붙어서 낭패를 보는 경우가 가끔 있다. BOM이 없는 UTF-8 파일이 필요한 번역 함수를 사용하고 있다면 Notepad는 사용하지 말라고 가이드를 해야 한다.

소프트웨어 국제화를 오래 하다 보면 이런 여러가지 노하우가 쌓이게 된다. 이런 노하우를 꾸준히 쌓아가면서 회사의 자산이 되도록 해야 한다.

소프트웨어 번역이 어색하게 되는 이유 (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 주소를 추가하기도 한다.

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

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

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

많은 소프트웨어에서 단수/복수 번역이 엉터리인 이유 (17)

앞으로 번역에 대해서 다룰 여러 주제 중에서 오늘은 단수/복수에 대해서 알아보자. 

국제화/지역화가 잘 된 소프트웨어라고 하더라도 단수/복수를 제대로 처리하고 있는 소프트웨어는 찾아보기 쉽지 않다. 우리는 단수/복수에 대한 구분을 하지 않는 언어를 사용하고 있다. 그래서 단수/복수 처리에 대해서 민감하지 않다. 하지만 단수/복수를 구분하는 언어권에서는 이를 제대로 처리하지 않으면 어색한 표현이 된다. 물론 의미는 알아보겠지만 그만큼 소프트웨어의 품질은 떨어지게 된다.




많은 소프트웨어에서 단수/복수 처리가 어렵기 때문에 꼼수를 부리곤 한다. 예를 들어 “%d file has been deleted”라는 문장을 사용해서 %d는 파일의 개수, 즉 숫자로 교체가 가능하다고 보자. 파일이 한 개라면 “1 file has been deleted”이 되지만 파일이 5개라면 “5 file has been deleted”가 되어서 어색한 문장이 된다.

그래서 “5 file(s) has been deleted”라고 하곤 하는데 has도 어색하다. 결국 “%d file(s) has(have) been deleted”라는 포맷을 이용하여 “5 file(s) has(have) been deleted”라고 할 수는 있지만 몹시 보기 지저분한 문장이 아닐 수 없다. 그래서 처음부터 “The number of deleted files: 5” 이와 같이 단수/복수와 무관한 문장들을 만들어 내지만 부자연스러운 것은 여전하다.

그리고 file(s)와 같은 꼼수를 쓰는 것은 영어나 몇몇 언어에서만 통한다. 우리나라 대부분의 개발자들은 한국어와 영어에 익숙하기 때문에 전세계 대부분의 언어가 그 틀에 크게 벗어나지 않으려니 추측하지만 우리가 상상할 수 없는 언어는 매우 많다.




예를 들어 폴란드어를 보자. 폴란드어에서 file은 plik이다. 이것은 단수 표현이다. 즉 file이 하나면 plik다. 그리고 2개면 pliki다. 3,4개도 pliki다. 하지만 5개가 되면 pliko’w로 바뀐다. 게다가 21개까지만 pliko’w다. 말로 설명하면 복잡하니 아래를 보라.

1 plik
2,3,4 pliki
5-21 pliko'w
22-24 pliki
25-31 pliko'w
32-34 pliki
35-41 pliko'w

복수의 형태가 두 가지인데 애매한 구간에서 바뀌며 끝에 ‘s’를 붙이는 형태도 아니다. 그래서 영어에서나 사용하던 끝에 (s)를 붙이는 형태로는 번역이 안된다. 

우리와 같이 단수/복수 구분을 하지 않는 언어는 일본어, 베트남어가 있다. 그리고 영어처럼 2개부터 복수로 처리를 하는 언어는 독일어, 스페인어, 이탈리아어, 그리스어, 터키어 등 가장 많은 언어가 여기에 속한다. 하지만 라트비아, 루마니아, 리투아니아, 러시아, 우크라이나, 크로아티아, 체코, 슬로베니아 등은 제각각 다른 단수/복수 체계를 가지고 있다. 

이런 상황에서 file(s)와 같이 쓰던가 단수/복수 처리를 별 것 아니라고 모두 단수로 처리해서 소프트웨어를 사용하라고 하는 것은 소프트웨어의 품질을 떨어뜨리는 결과가 된다. 현재도 여전히 많은 소프트웨어가 단수/복수 처리를 제대로 하고 있지는 않다.

그럼 소프트웨어에서 단수/복수 처리를 어떻게 할 수 있을까? 구체적인 방법은 추후 소개를 하도록 하겠다.



(을를이가 문제를 피해간 사례)

이와 유사한 문제로는 “을를이가은는” 문제가 있다. 한국어에만 있는 이슈인데 소프트웨어에서 “%s을 삭제했습니다.”라는 형식을 이용해서 %s를 “파일” 또는 “이미지”로 교체를 해서 출력한다고 보자. 이때 “이미지”로 교체를 하면 “이미지을”이라는 어색하는 문장이 된다. 그래서 “%s을(를) 삭제했습니다.”이라고 꼼수를 쓰던가 “파일을 삭제했습니다.”와 “이미지를 삭제했습니다.” 두 문장을 각각 번역하기도 한다. 하지만 %s에 들어가야 할 단어의 개수가 많고 문장이 조금만 더 복잡하면 번역해야 할 문장이 기하급수로 늘어서 좋은 방법은 아니다. 

단수/복수 문제는 전세계적인 문제라서 이를 연구하는 사람이 많지만 “을를이가은는”문제는 우리가 스스로 해결해야 한다. 

단수/복수 문제는 사소해 보이지만 무시할 수 없는 이슈이고 이러한 수준의 이슈들은 소프트웨어 번역에서 수 많이 존재한다. 급한 개발자나 경영자들은 언제 이런 이슈까지 신경을 쓰면서 소프트웨어를 개발하고 국제화를 하겠냐고 하소연을 하거나 스스로 해결을 해보고자 연구하고 라이브러리를 만들고 있을 수도 있다. 



하지만 소프트웨어 국제화는 이미 이전의 개발자들이 많이 연구를 해놓았고 해결책을 제시해 놓았기 때문에 대부분의 문제는 이미 제시된 해결책을 잘 찾아서 사용하기만 하면 된다. 스스로 해결해야 하는 문제도 있지만 이미 나와 있는 솔루션을 모르고 또 만드는 경우도 많다.물론 그렇게 재탄생한 자체 솔루션의 99%는 함정에 빠져서 문제를 완벽하게 해결하지 못한다. 이런 현상은 집을 만들기 위해서 망치가 없다고 망치를 직접 만드는 것과 비견된다. 

그래서 소프트웨어 국제화에는 방대한 지식이 필요한 것이다. 무엇이 필요하고 누가 이미 만들어 놓은 것들에는 어떤 것들이 있는지 알려면단편적인 지식보다는 소프트웨어 국제화 전반에 걸쳐 광범위한 지식이 필요하다. 

본 시리즈의 포스트를 통해서 조금씩 알아나가도록 하자.

소프트웨어 번역이 생각보다 훨씬 어려운 이유 (16)

이제부터 소프트웨어 국제화에서 가장 중요한 번역과 관련된 얘기를 시작하려고 한다. 번역은 다뤄야 할 주제가 광범위하므로 여러 회차를 거쳐서 다루게 될 것이다. 필자는 수십 개의 회사의 소프트웨어 국제화 방식을 조사했으며 대부분의 회사가 수많은 번역 함정에 빠져서 어려움을 겪고 있는 것을 보았다. “변역 함정”이란 소프트웨어를 번역하면서 비효율적인 방법에 쉽게 빠져서 허우적거리는 것을 말한다. 번창한 회사일수록 어려움은 더 커졌다. 그래서 어떻게 하면 번역 함정에 빠지지 않고 효율적인 번역을 통해서 소프트웨어 국제화를 성공할 수 있는지 공유를 할 것이다.


가상의 A사는 전세계 수십 개의 국가에서 사용하는 서비스를 개발하고 있다. 해당 서비스를 개발하는 소프트웨어 엔지니어는 수십 명에 이른다. 해당 서비스는 10개 언어로 번역이 되어서 서비스가 되고 있다.

그러다 보니 개발자는 소스코드에 번역이 필요한 메시지 하나를 추가하려고 해도 매우 복잡한 절차를 밟아야 한다. 소스코드에 “Hello”라는 메시지를 넣어야 한다고 가정해보자. A사의 개발자는 다음과 같은 프로세스를 밟아야 한다.

1. “Hello”에 대응하는 심볼을 정한다. MSG_HELLO로 정했다.

2. 소스코드에는 TranslateMsg("MSG_HELLO")라고 번역 함수를 이용해서메시지를 입력한다. 이 단계에서 소프트웨어는 MSG_HELLO라고 출력된다.

3. 개발자들이 공유하는 엑셀 파일에 “MSG_HELLO” 항목을 추가하고 영어 칸에 “Hello”를 입력한다. 이때 엑셀 파일은 여러 개발자가 공유를 해야 하기 때문에 소스코드 관리시스템이 아니고 파일서버에 보관하고 있다.

4. 해당 엑셀 파일에는 10개 언어별 컬럼이 있는데 각 언어별로 이번 업데이트에 추가된 메시지를 10개의 엑셀파일로 추출하여 언어별 번역가에게 번역을 의뢰한다.

5. 번역이 완료된 후에 엑셀파일은 각 언어별 메시지 파일로 저장한다. (예, Korea.ini, Japan.ini)

6. 이제 소프트웨어에서는 “MSG_HELLO” 대신 “Hello”가 출력된다.


가상의 A사의 예를 들었지만 현실과 전혀 동떨어진 얘기는 아니다. 위 프로세스를 보고 별일 아니라고 생각할 수도 있고 복잡하고 불편하다고 생각할 수도 있다. 아직 국제화된 소프트웨어를 개발해보지 못한 개발자나 한두 개 언어를 추가로 개발해본 개발자는 소프트웨어 번역의 복잡함을 과소 평가할 수도 있다.

하지만 소프트웨어는 지원해야 하는 언어가 많을수록 소프트웨어 규모가 클수록 개발팀의 규모가 클수록 업데이트 주기가 잦을수록 번역의복잡도는 기하급수로 증가를 한다. 

자연스러워 보이는 위 예도 이미 수많은 함정에 빠져서 매우 비효율적인 프로세스를 밟고 있는 상태다. 물론 소프트웨어가 잘 안 팔려서 사라져가고 있다면 번역의 복잡성 함정에 빠져서 문제가 되고 있다는 사실 조차 모르고 지나간다. 하지만 2,3개 지원하던 언어를 10개 이상으로 늘려서 지원하게 되고 소프트웨어가 계속 업그레이드되어서 규모가 몇배 커지고 개발자도 많이 투입이 된다면 그 때서 번역 프로세스로 인한 비효율이 눈에 띄게 커졌다가는 것을 발견하게 된다.

그때는 이미 소프트웨어 번역 아키텍처를 바꾸기 어려운 상태이기 때문에 비효율을 개선하기는 매우 어려워진다. 번역은 실제 메시지가 현지 문화에 얼마나 잘 맞게 번역이 되었는지도 중요하지만 어떤 메시징 아키텍처를 사용하는지도 중요하고 번역 프로세스도 매우 중요하다.

흔히 RC 파일을 사용하기도 하고 자체적으로 제작한 메시징 함수를 사용하기 위해서 INI파일이나 별도의 메시지 파일을 포맷을 만들어서 사용하기도 한다. 이 과정에서 중간 파일로 엑셀파일을 사용하기도 하고Database를 사용하는 회사도 있다. 개발자가 번역이 필요한 메시지 하나를 소스코드에 추가하기 위해서 복잡한 절차를 밟아야 하는 경우가 많다.

이런 복잡한 절차의 불편함을 당연하게 생각하고 개발하는 개발자도 있는가 하면 이를 개선해보고자 여러 자동화 툴을 만들면서 노력을 했지만 쉽게 개선되지 않음을 경험하기도 한다.

앞으로 소프트웨어 번역의 원칙과 원리를 중심으로 가장 효율적으로 번역을 하는 방법을 공유하도록 하겠다.