2015년 6월 27일 토요일

왜 소프트웨어 번역의 기준은 영어가 되어야 하는가? (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원칙의 원리를 몸에 익히는 것이 필요하다.

소프트웨어 번역 프로세스의 절대 원칙 (19)

소프트웨어를 국제화하려면 수많은 요소를 국제화해야 하지만 그 중에서 절대 빠지지 않는 부분이 번역이다. 또한 가장 중요하면서 어렵다. 필자가 얘기하는 주제는 번역 그 자체를 제외한 번역을 위한 모든 활동을 말한다. 소스코드에서는 어떠한 함수를 사용하고, 메시지는 어떻게 추출해서 어디에 저장하고 번역가에게는 어떻게 보내고, 번역된 메시지는 소프트웨어에서 어떻게 읽어 들여서 출력할 것인지에 대한 아키텍처와 프로세스 전반을 말하는 것이다. 


소프트웨어를 어느 정도 개발해 본 경험이 있는 개발자라면 소프트웨어를 번역해서 해외에 출시해 본 경험을 누구나 가지고 있다. 또한 별 문제를 겪지 않아서 소프트웨어 번역이 별거 아니라고 생각하는 개발자도 많다.

그럼에도 불구하고 필자는 왜 자꾸 어렵다고 얘기를 하는 것일까? 과장을 하는 것은 아닐까? 아니다. 소프트웨어 번역에서 별 문제를 겪어보지 못한 개발자들은 아직 심각한 상황을 경험해보지 못해서 어려움을 모르는 것일 가능성이 높다다. 아래 5가지 상황 중에서 2가지 정도만 닥쳐도 소프트웨어 번역은 심각한 문제가 된다.




10개 이상의 언어(로케일)을 지원
100명 이상의 개발자가 공동 개발
10000개 이상의 메시지를 번역
100,000명 이상의 고객이 사용한다.
적어도 한 달에 2번 이상 업데이트

한두 명의 개발자가 몇 백 개의 메시지를 번역해야 하는 상황이라면 어떤 메시징 아키텍처를 사용하던지 완전 수동화된 프로세스를 사용해도 거의 문제가 안 된다. 그래서 거의 모든 개발자들이 큰 고민 없이 여러 개발툴들이 제공하는 메시징 함수를 그냥 사용하고 수동에 의존한 프로세스에 익숙해져 있다.

그렇게 성장을 하다가 큰 제품을 만들 기회가 생기고 큰 조직에서 수십 명의 개발자와 같이 개발을 하게 되면 번역은 10배, 100배 비용이 들게 된다. 




예를 들어 전세계 백만 명이 사용하는 제품을 20개 언어(로케일)로 번역을 해야 하는 거대 프로젝트에 참여를 했다고 생각하자. 소프트웨어에 추가할 메시지들을 RC에 추가한다던지 별도의 파일에 추가하는 것은 쉽지가 없다. 메시지도 수만 개에 이를 뿐만 아니라 수십 명의 개발자들이 동시에 RC파일을 고쳐댄다. 똑 같은 메시지가 서로 다른 심볼로 중복 저장되기도 하고 반대로 의미가 다른 동일한 메시지를 사용하기도 한다. 더 이상 사용하지 않는 메시지를 삭제 했더니 다른 개발자는 사용하고 있는 경우도 있다. 그래서 메시지를 삭제 않다 보니 사용하지 않는 메시지가 넘치게 된다.

번역가에게 번역을 의뢰할 때도 처음에는 문제가 안되는데 두 번째 버전부터는 바뀐 메시지만 의뢰를 해야 한다. 번역된 결과물을 첫 번째 번역과 합치는 것도 문제다. 이렇게 복잡한 수동 프로세스에 의존하다 보니 누락된 메시지가 생긴다. 이를 개선하고자 자동화툴을 만들어보지만 깔끔하게 해결하는 것이 쉽지는 않다.

이런 거대 프로젝트에 참여를 해서 소프트웨어 국제화의 어려움을 실제로 겪어본 개발자는 그렇게 많지 않다. 하지만 모든 개발자는 언제든지 이런 상황을 겪게 될 것이고 지금의 국제화 지식만 가지고는 남들이 겪은 국제화 실패를 고스란히 다시 겪게 될 것이다.

그럼 소프트웨어 번역은 어떻게 해야 할까? 앞으로 여러 차례에 걸쳐서 설명을 하게 될 것이고 오늘은 대원칙 2가지를 알아보자.

첫째, 메시지의 키는 영어 자체를 사용해야 한다.
둘째, 번역 자체를 제외한 모든 프로세스는 완전 자동화 되어야 한다.

위 두 원칙에는 많은 의미를 포함하고 있고 적용하기 쉽지도 않다. 또한 기존에 수많은 개발자들이 소프트웨어 번역을 위해서 사용하고 있는 방법의 대부분의 뒤 두가지 원칙에 위배되고 있다.

다음 시간에는 왜 메시지의 키가 영어가 되어야 하는지 설명을 시작으로 소프트웨어 번역에 대해서 좀더 깊이 들어가보자.

국제화된 소프트웨어에서 날짜와 시간을 다루는 방법 (18)

개발자들이 소프트웨어를 개발하면서 가끔 하는 실수 중 하나가 현지 시간을 저장했다가 나중에 소프트웨어가 확장되면서 꼬이는 것이다. 보통의 소프트웨어라면 시간에 그렇게 민감하지 않다. 하지만 일정관리, 항공권 예약, 배송 시스템 등 시간에 민감한 소프트웨어들이 있다. 이 외에도 시간을 신경 써서 다뤄야 하는 소프트웨어가 많다. 이런 소프트웨어에서 시간의 기록과 처리를 현지 시간을 기준으로 처리를 하다가는 문제가 발생하고 꼬이게 된다. 



여기서 현지 시간이란 날짜와 시각을 모두 의미한다. 또 현지 시각은 그레고리력을 기준으로 하는 날짜 일 수도 있고 해당 나라에서 사용하는 독특한 달력을 기준으로 한 날짜일 수도 있다. 개인 혼자서 쓰는 시스템, 예를 들어 일기장과 같은 소프트웨어라면 문제가 안되지만 전세계 여러 사용자가 공유하는 시스템이라면 시간의 표시가 지역마다 다르게 표시되어야 한다. 또한 혼자 사용하더라도 일정 관리 소프트웨어 같은 경우에는 지역을 옮겨 다닐 때마다 현지 시간에 맞게 보정해서 보여줘야 한다.

그래서 시스템에 시간을 저장할 때는 절대 시간을 기록해야 한다. 소프트웨어에서 절대 시간이란 유닉스 시간을 말한다. POSIX 시간이라고도 부른다. 유닉스 시간은 영국 그리니치 천문대에서 그레고리력으로1970년 1월 1일 0시 0분 0초에 0으로 시작된 시간 표시로 1초에 1씩 증가한다. 예를 들어 한국에서 2015년6월5일 오전2시16분37초의 유닉스 시간은 1433524597이다. 거의 모든 OS와 Database에서는 유닉스 시간을 기준으로 시간을 처리한다. 그리고 화면에 출력할 때 타임존을 고려하여 변환하여 출력한다. 

따라서 시간을 기록할 때는 유닉스 시간을 얻어와서 DB나 파일에 저장을 하고 입출력 시 사용자의 입맛에 맞게 변환을 해야 한다. 출력 시에는 예를 들어 아래와 같은 변환 과정을 거쳐야 하고, 입력 시는 반대 과정을 거친다.


(유닉스 시간 10억초 달성 기념)

1. 유닉스 시간 : 1433524597
2. 협정 세계시 : 2015-06-05 17:16:37 UTC
3. 달력 변환 : 2015-06-05 17:16:37 UTC
4. 한국의 타임존 : 2015-06-06 02:16:37+09:00(or PDT)
5. 한국의 시간포맷 : 2015년 6월 6일,오전 2시 16분 37초

1~4번까지는 소프트웨어 내부에서 일어나는 변환 과정이고 5번이 사용자에게 보여지게 된다. 또한 형식은 언어(로케일)별로 다르다.

달력 변환에서 그레고리력일 경우에는 변환할 필요가 없지만 사용자가 그레고리력이 아닌 다른 달력을 사용하는 경우에는 변환이 필요하다. 예를 들어 일본 일왕의 연호나 불기, 음력을 사용한다면 변환이 필요하다.

개발 환경 즉, 개발 프레임워크나 라이브러리에서 제공하는 시간 함수들은 여러가지가 있고 위 변환 과정을 거의 모두 지원하는 것도 있고 일부만 지원해서 개발자가 추가로 개발을 해야 하는 경우도 있다. 대부분은 유닉스 시간과 타임존 변환은 제공하지만 달력 변환을 지원하는 경우는 거의 없고 로케일별 시간 포맷 제공도 프레임워크마다 제각각이다. 개발자가 상당한 세심한 신경을 써야 하는 이유다.


(타임존 지도)

그 외에 일정관리나 항공권예약 시스템에서는 시간과 관련해서 좀더 많은 정보를 보관해야 한다. 매 시간마다 위치나 타임존을 기록해서 하나의 시간에 대해서도 현지 시간과 현재 사용자가 있는 위치의 시간을 동시에 보여주기도 한다. 국제화가 잘된 소프트웨어에서는 시간 처리에 여러 가지 신경을 써야 한다.

그럼 국가별, 로케일별로 시간 표시 형식은 어떨까? 우선 로케일별 국가 이름을 보자

ar_SA : 사우디아라비아
de_DE : 독일
en_US : 미국
es_ES : 스페인
fr_FR : 프랑스
id_ID : 인도네시아
it_IT : 이탈리아
ja_JP : 일본
ko_KR : 대한민국
pl_PL : 폴란드
pt_PT : 포르투갈
ru_RU : 러시아
vi_VN : 베트남
zh_CN : 중국
zh_TW : 타이완
de_LI : 리히텐슈타인
th_TH : 태국

로케일(국가)별 시간 형식의 예는 다음과 같다. 

ar_SA : " ٣:٠٢:٢٧ م"
de_DE : "15:02:27"
en_US : "3:02:27 PM"
es_ES : "15:02:27"
fr_FR : "15:02:27"
id_ID : "15.02.27"
it_IT : "15:02:27"
ja_JP : "15時02分27秒"
ko_KR : "오후 3시 2분 27초"
pl_PL : "15:02:27"
pt_PT : "15:02:27"
ru_RU : "15:02:27"
vi_VN : "15:02:27"
zh_CN : "下午3时02分27秒"
zh_TW : "下午3時02分27秒"
de_LI : "15:02:27 "
th_TH : "15 นาฬิกา 2 นาที 27 วินาที "

위 시간의 포맷은 특정 Framework를 사용한 한 예다. 

물론 모든 소프트웨어가 위에서 언급한 타임존, 특수한 달력, 지역에 맞는 형식을 모두 지원하는 것은 아니다. 또한 우리가 만드는 소프트웨어도 모두 지원해야 하는 것은 아니다. 소프트웨어 성격과 판매 지역, 전력에 따라서 지원해야 하는 범위를 개발 초기에 결정해야 한다. 그래야 소프트웨어 국제화가 성공적으로 진행될 수 있다.

많은 소프트웨어에서 단수/복수 번역이 엉터리인 이유 (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를 사용하는 회사도 있다. 개발자가 번역이 필요한 메시지 하나를 소스코드에 추가하기 위해서 복잡한 절차를 밟아야 하는 경우가 많다.

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

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

독특한 달력을 사용하는 고집 센 나라들 (15)

미국에서 미터법을 잘 쓰지 않듯이 국제 표준이 있는데 자국만의 표준을 고집하는 나라들이 있다. 우리가 모든 나라의 문화를 다 이해하지 못하는 상황에서 이를 비난 해서는 안된다. 다만 소프트웨어를 개발하는데 엄청 번거로울 뿐이다. 날짜에서도 전세계 대부분의 나라가 그레고리력을 사용하는데 그레고리력을 사용하지 않는 몇몇 나라가 있다. 물론 그레고리력과 혼용을 하기도 한다.

게다가 달력은 로케일 표준 카테고리에 해당하지 않기 때문에 대부분의 개발툴이나 라이브러리에서 별도로 제공하지 않는다. 개발자가 직접 제공을 해야 하는 경우가 많다.




사실 한국도 19세기까지는 음력을 사용하다가 독자 연호를 거쳐 현재는 그레고리력을 쓴다. 우리나라는 국제 표준을 상당히 잘 따르는 나라 중에 하나다. 오랫동안 써왔던 면적 단위인 “평”을 못 쓰도록 법으로 금지했는데 이렇게 할 수 있는 나라는 그렇게 많지 않을 것이다. 그래도 그런 강제 표준 적용이 소프트웨어 개발에는 더 유리하다.
이렇게 전세계가 완벽하게 그레고리력으로 통일되지 못한 상황에서 소프트웨어가 그레고리력만 제공을 하면 해당 국가에서는 받아들여지기 힘들 수도 있다. 그래서 그레고리력 외에 크게 “불기”와 일본의 “연호”를 제공해야 한다. 그 외에는 여러 가지 달력이 추가로 더 있으니 소프트웨어의 성격에 따라서 추가 지원을 고려해야 한다.




먼저 “불기”를 알아보자. “불기”란 석가모니가 입적(불멸)한 해인 기원전544년을 기준으로 삼는 달력이다. “서기”는 예수의 탄생을 기준으로 삼는데 불교에서는 정반대의 기준을 사용하는 것으로 보아서 문화에 따른 생각의 차이를 엿볼 수 있다.

표준 “불기”로는 올해가 2559년이지만 태국에서는 이보다 1년 늦은 2558년이다. “불기”도 나라별로 약간 다른 것도 소프트웨어에서는 여간 귀찮은 일이 아니다. 또한 태국에서는 그레고리력을 쓰는 사람들도 있기 때문에 그레고리력을 선택할 수도 있도록 해야 한다. 즉, 로케일로 달력을 결정할 수 없고 별도의 설정이 필요하다.

다음은 일본이다. 일본은 일왕에 따른 연호를 사용한다. 올해는 平成27年(헤이세이)이다. 일본 역시 그레고리력도 쓰기 때문에 둘 다 지원을 해야 한다. 일본의 연호를 고려하지 않고 소프트웨어를 개발하게 되면 올해가 2015년이 아니고 0027년으로 처리가 될 수도 있다. 일본은 연도별로 연호가 다르기 때문에 대단히 귀찮은 변경작업을 해줘야 한다. 하지만 연호를 잘 제공하면 그만큼 일본 시장에서 소프트웨어의 품질이 올라갈 것이다.

그 외에 몇 개의 달력을 더 알아보자. 필자도 위의 달력 외에도 아래 소개하는 몇몇 달력 때문에 고생한 적이 있다.

이슬람력은 많은 이슬람 국가에서 사용하고 대부분의 나라에서는 그레고리력과 병기를 한다. 위에서 언급한 불기와 일본의 연호는 연도만 다르고 월과 일은 그레고리력과 같다. 하지만 이슬람력은 태음력을 사용하기 때문에 날짜가 완전히 다르다. 라마단도 이슬람력을 기준으로 한다.

이란과 아프가니스탄에서 사용하는 이란력(페르시아력)도 있다. 이는 태양력이다.

그 외에도 히브리력, 인도 국민력, 에티오피아력, 대한민국 단기, 음력, 북한의 주체연호가 있다. 대부분은 그레고리력과 병기를 한다.

어떤 달력을 지원하던지 날짜의 변환 작업과 날짜 선택기를 제공해야 한다. 그레고리력 날짜 선택기를 쓸 수 없는 달력들이 있다.

소프트웨어를 개발할 때 달력을 어디까지 제공할지는 소프트웨어의 성격과 판매하려는 지역과 전략에 따라서 매우 달라진다. 우리가 각 나라들의 문화를 다 알지 못하는 상황에서 무조건 그레고리력을 써야 한다고 주장하는 것은 소프트웨어 판매에 걸림돌이 될 수도 있고 그렇다고 모든 달력을 제공하는 것은 배보다 배꼽이 더 클 수도 있다. 전략에 따라서 적절히 판단을 해야 한다.

날짜 표기 국제 표준은 무엇일까? (14)

지난 12회에서 국가별, 로케일별로 날짜 표기 형식이 매우 다르다는 것을 보았다. 하지만 이런 방식을 따르기만 한다고 해서 날짜 표기 형식 문제가 모두 해결되는 것은 아니다. 시스템에서 제공하는 날짜 표기 형식이 실제로 해당 국가에서 오류라고 생각할 수도 있고, 입력 시 사용자의 실수로 인한 혼동도 무시 못한다.

그래서 국제화가 잘 된 소프트웨어에서는 날짜 형식에 대해서 조금 더 고민을 해야 한다. 우선 날짜를 출력하는 방법은 크게 3가지가 있다. 각각 장단점이 있다.

첫 번째 지난번 12회에서 봤듯이 로케일별로 각각 다른 날짜 형식으로 출력을 하는 것이다. OS나 개발툴, 라이브러리에 따라서 그 형식이 조금씩은 다르지만 웬만큼은 현지에서 받아들여 질만한 형식을 제공한다. 장점으로는 개발자가 날짜 형식을 직접 연구하고 다루지 않기 때문에구현이 상대적으로 간단하다. 하지만 단점으로는 라이브러리나 프레임워크에 따라서 제공하는 포맷이 일정하지 않고 원하는 날짜 형식을 제대로 제공하지 못할 수도 있다. 또한 그렇게 제공한 날짜 형식에 버그가 있을 경우 개별적으로 수정을 해야 하는 번거로움이 있다.
C에서는 strftime()함수를 사용하거나 QT Framework에서는 QDate::toString() 함수를 이용할 수 있다. 




두 번째사용자가 날짜 형식을 선택하거나 직접 입력하도록 하는 방식이다. 개발자가 완벽하게 사용자가 원하는 날짜 포맷을 제공하는 데는 한계가 있다고 생각하고 그 책임을 사용자에게 맡기는 것이다. 예를 들어 yyyy/MM/dd 라고 지정을 하면 2015/05/27이라고 출력을 할 것이다. 유독 월을 표시하는 M만 대문자인 이유는 분을 표시하는 m(minute)와 구분하기 위해서이다. 이 경우에도 요일과 월은 숫자가 아니라 문자로 표시를 할 수 있으므로 똑 같은 형식이라도 로케일별로 다르게 표시가 된다. 
소프트웨어에서 몇 가지 날짜 형식을 보여주고 사용자가 고르는 방법도 있고 사용자가 완전히 자유롭게 형식을 편집할 수 있도록 할 수도 있다. 물론 고르는 방법이 구현도 편하고 좀더 안전하다. 이 방법의 장점은 개발자가 각 나라의 날짜 형식에 대해서 너무 고민할 필요가 없는 것이다. 단점으로는 사용자가 뭔가 선택을 해야 하는 불편함이 있고, 사용하는 개발언어나 라이브러리에 따라서 날짜 포맷 표기법이 조금씩 다르다는 것이다.
그래서 첫 번째 방법과 두 번째 방법을 섞어서 사용하기도 한다.




세 번째국제 날짜 형식 표준을 이용하는 방법이다. 국제화된 소프트웨어를 개발할 때는 항상 날짜 표시 문제가 있다. 그래서 1988년도에 국제 날짜 표준 형식이 제안되었고, ISO8601이 발표되었다. ISO8601에서는 여러 가지 날짜와 시간의 표준 형식을 다루고 있다. 먼저 국제 날짜 표준 형식은 어떤 것인지 보자.
날짜는 2015-05-28과 같이 YYYY-MM-DD의 형식을 따르고 있다. 연도가 뒤에 있을 경우에는 앞에 온 숫자가 월일지 일일지 헷갈리지만 연도가 맨 앞에 오면 전세게 거의 모든 사람들이 연-월-일로 인식을 한다. 물론 예외는 있을 것이다. 이런 국제 날짜 표준 형식은 우리나라에서 흔히 사용하는 형식이라서 다행이다. 
시간과 같이 표시를 할 때는 2015-05-28T09:15:52와 같이 중간에 “T”를 넣어서 표시한다. Time Zone을 포함해서 2015-05-28T09:15:52+09:00과 같이 표시하는 방법도 있다. 기간을 표시하기 위해서 우리는 흔히 ‘~’를 사용하는데 ISO8601에서는 ‘/’를 사용한다. 2015-05-28/2015-06-28과 같이 표시한다.
이렇게 국제 표준 날짜 형식을 사용하면 소프트웨어를 개발하기 매우 편리하다. 나라별, 로케일 별로 고민을 할 필요가 없고 이로 인한 혼란이나 버그가 거의 없다. 하지만 고집이 센 나라에서 받아들여지지 않고 버그로 보고가 될 수도 있는 단점이 존재한다.

위의 모든 경우에 입력의 문제는 여전히 존재한다. 국제화가 잘된 소프트웨어에서도 흔히 날짜 입력의 문제를 해결하지 못하는 경우가 많다. 날짜 출력은 그 나라의 문화에 알맞게 지원을 하는데 날짜 입력에서 제대로 된 형식을 지원하지 못하는 경우도 흔하다. 또한 날짜 입력은 사용자의 실수를 무시할 수 없다. 그래서 날짜는 날짜 선택기 위젯 같은 것을 이용해서 마우스 클릭을 통해서 사용자가 날짜를 선택하게 하는 UI를 제공하는 것이 좋다. 물론 날짜 선택기가 그레고리력만 제공하는지 그 외의 달력도 제공하는지 이슈가 있기는 하다. 또한 날짜 선택기도 지역화를 제공해야 한다.




위에서 어떤 방식을 제공할지는 소프트웨어의 성격 및 회사의 전략에 따라서 달라질 수가 있다. 단, 일단 개발을 해 놓고 문제가 있다고 고치기 시작하면 이미 좀 늦은 것이다. 사전에 국제화 전략을 정해서 제대로 적용하는 것이 가장 효율적인 방법이다.