한글화된 오라클 제품, 그 이면의 비밀

마지막 연재를 시작하며

 오라클 제품의 세계화 방식과 기술을 설명하기 위해 틈틈이 써온 글이 어느덧 마지막 회가 되었다. 첫 회와 두 번 째 회에서 우리는 오라클의 데이터베이스 제품을 중심으로 기본적인 NLS 지원과 올바른 사용 방법에 관해 알아보았다. 그리고 세 번 째 회에서는 오라클이 가지고 있는 NLS 정보를 접근할 있는 API의 집합인 GDK(Globalization Development Kit)을 이용하여, 사용자의 애플리케이션이 어떻게 그 정보를 열람 및 사용할 수 있는가에 대해 알아보았다. 이제 마지막으로는 오라클의 다국어 지원 제품들이 어떻게 태어나는지, 그 이면에 숨은 비밀을 공개할까 한다. "오라클의"이라는 수식어를 붙였지만, 오히려 일반적인 소프트웨어 세계화 프로세스를 기술하려고 노력할 것이다. 오라클은 다음에 기술된 세계화 프로세스를 충실히 구현해 운영하고 있다.

"우리도 세계화된 소프트웨어 좀 만들어보자 카이~"

특정 지역에서만 사업을 운영하는 기업을 위한 프로젝트를 수행한다거나, "한국"과 같이 특정 지역에 한정된 사용자만을 위해 뚝딱뚝딱 소프트웨어를 개발하는 경우에는 "세계화"라는 개념이 크게 중요하지 않을 것이다. 사용자의 요구사항에 맞는 기능들을 문제없이 수행해 주는 소프트웨어를 개발하고 운영해 주기만 하면 된다. 하지만, 첫 회에서 강조했듯이, 현실 세계의 글로벌화 추세는 소프트웨어 산업에서도 외면할 수 없는 화두가 된지 오래다. 세상은 점점 좁아지는데, 소프트웨어만은 각자 개발한다거나, 한 지역만을 위한 소프트웨어만을 고집한다면, 시대에 뒤떨어졌다는 말을 들어도 어쩔 수 없을 것이다. 특히, 다국적 기업의 운영 소프트웨어나, 또는 오라클과 같이 범용 패키지 소프트웨어를 생산할 경우에는 "세계화"된 소프트웨어가 필요하다.

"하긴 해야겠는데, 어떻게 준비해야 하나?"

이 글을 읽는 개발자의 현실은 어떠한지, 꿈은 어떠한지 일일이 다 알 수 없다. 현실에서 여러분들은 여러 나라에서 동시다발적으로 사업을 전개하는 업체의 내부 개발자일 수도 있고, 또는 오라클이나 마이크로소프트처럼 특정 나라나 특정 사업에 국한되지 않는 범용 소프트웨어를 개발하는 회사에 몸담고 있거나, 그런 제품을 만들어낼 꿈을 가지고 있을 지도 모른다. 국제화/현지화된 소프트웨어를 생산하기 위해서는 어떻게 조직을 정비하고, 어떤 프로세스로 작업해야 하는 것이 좋을까? 오라클을 비롯한 세계적인 소프트웨어 업체들은 이런 질문에 대해 이미 선진화된 체계를 이용한 답을 가지고 있다는 점을 주목해야 한다.

"세계화된 소프트웨어 생산을 위해 첫걸음을 내딛자"

오라클은 "한글"만을 위해서 어떤 개발을 진행하지는 않았다. 그래서 이 글의 제목에 포함된 "한글화된 오라클 제품"이라는 문구는 오라클의 입장에서는 "세계화된 오라클 제품"이라는 말과 동일한 셈이다. 지금부터 "세계화된 오라클 제품", "세계화된 소프트웨어"에 숨은 프로세스에 접근해 보기로 하자.

소프트웨어 세계화의 개념

우선, 뒤섞여 사용되고 있는 용어들의 개념부터 확실히 정리하고 넘어가자. 혹자는 "세계화" 또는 "글로벌화"를 외치기도 하고, 혹자는 소프트웨어의 국제화, 현지화를 외치기도 한다. 비슷한 개념으로 받아들여지지만, 그 범주는 확실히 다르므로, 독자 여러분도 구분하여 사고할 수 있기를 바란다. 이들 개념을 설명하기 위해서 현지화 산업 표준 협회(LISA)의 현지화 산업 입문서를 참고하였다.

국제화(Internationalization, I18N)

국제화는 특정 지역이나 특정 언어에 국한되지 않고, 어떠한 지역이나 언어에서도 동작할 수 있도록 소프트웨어를 설계하고 개발하는 절차를 의미한다. 제대로 된 "세계화"를 실행하기 위해서는 아래 언급된 "현지화"이전에 반드시 소프트웨어 자체의 "국제화"가 선행되어야 한다. 소프트웨어 생산 후, 판매 지역이 늘어날 때마다, 각 지역별 버전을 재생산하느라 땀을 쏟는 장면을 상상해 보라. 얼마나 비생산적인 프로세스인가? 지금 여러분들이 개발하고 있는 소프트웨어를 중국에서도 판매 및 서비스하려 할 경우, 많은 변화가 필요하다면 여러분들은 그만큼 국제화의 개념에 멀어진 상태에서 소프트웨어를 생산하고 있는 셈이다.

오라클의 소프트웨어들은 그 자체의 성능만으로 시장을 지배하는 것이 아니라, 거의 모든 제품의 국제화를 달성함으로써 더욱 강력해 지고 있다. 오라클 데이터베이스의 경우 완전히 동일한 소프트웨어로 아랍계부터 베트남 지역가지 140개가 넘는 종류의 로케일(Locale)을 지원하고 있다.

현지화(Localization,L10N)

LISA의 말을 빌리면, 현지화는 "개별 시장의 차이점을 고려하여 제품 또는 서비스를 수정하는 절차"라고 한다. 가장 대표적인 것이 소프트웨어 화면 및 도움말의 번역이지만, 현지화는 번역만을 포함하는 것은 아니다.  번역과 더불어 소프트웨어를 현지의 법규과 문화에 맞추는 작업을 반드시 수행해야 한다. 자동차를 세계화하는 작업에 빗댄다면, 매뉴얼과 조작 장치의 태그를 번역하는 것도 중요하지만, 영국의 교통 법칙과 문화에 맞게 핸들을 오른쪽으로 옮기는 작업도 필요한 것이다. 우리가 글을 읽을 때 왼쪽에서 오른쪽으로 읽는다고, 아랍계 언어를 사용하는 사람들에게도 그것을 강요한다면 통할 리가 없다.

오라클도 물론 중요한 판매 지역들에 대해 소프트웨어의 사용자 인터페이스 및 도움말에 대해 번역을 제공한다. 현재 영어를 포함한 10개의 언어에 대해서는 일반 사용자가 아닌 전문 관리자가 사용하는 화면과 도움말, 그리고 개발 API의 메시지(JDBC 등) 및 각종 유틸리티(SQLLoader, Exp/Imp)의 화면 출력의 번역을 제공하고 있다. 한국어 또한 전 세계 주요 10개 언어에 포함되니, 비록 일개 글로벌 기업의 서비스이지만, 한국의 위상을 느낄 수 있다. 그리고, SQLPlus와 같이 일반 사용자들도 빈번히 사용하는 애플리케이션에 대해서는 30가지 언어로 번역을 제공하며, 이 서비스로 혜택을 보는 나라들의 수는 훨씬 많은 셈이다.

물론 오라클의 현지화는 번역 이상의 조건도 만족한다. 오라클의 입장에서는 미국 세법에 맞게 개발된 E-Business Suite 애플리케이션을 한국에서도 판매할 수 있으리라 기대할 수는 없을 것이다.  오라클의 E-Business Suite은 각 지역별 세법 및 회계 전문가와 같은 지역화 전문가들이 제품의 지역화를 쉽게 할 수 있도록 국제화 방식으로 구현되어 있기 때문에 지역화가 쉽게 구현되고 있다.

세계화(Globalization)

세계화는 소프트웨어의 국제화와 현지화를 포함한 포괄적 개념으로, 소프트웨어를 전 세계 어느 곳에서나 사용할 수 있도록 개발 및 변경하는 절차를 의미한다. 결국 소프트웨어의 "세계화"는 한 마디로 다음과 같이 정의될 수 있다.

"국제화된 소프트웨어를 현지화 서비스와 함께 제공하는 것"

참고로, 본 글은 세계화된 소프트웨어의 생산,개발 측면에 관해서만 집중할 것이다, 세계화 정보의 수집 및 현지 마케팅과 같은 사업 영역에 대해서는 사업자의 지식을 참고해야 할 것이다.

세계화된 소프트웨어의 요구 조건

 오라클은 한국을 비롯한 전 세계의 모든 나라에 자사의 소프트웨어를 판매하고, 사용자들이 운영을 쉽게 할 수 있도록 도와주기 위해서 이미 수 년 전부터 소프트웨어의 설계시부터, 국제화/현지화를 고려해 왔다. 누누이 자랑해 온 바 대로 오라클 소프트웨어는 "지구 버전"만 존재할 뿐, "한국어판", "중국어판"이라는 것이 애시당초 존재하지 않는 것도 다 설계 자체부터 "지구 버전"으로 설계를 한 후 개발, 생산했기 때문이다.  초기 개발 비용은 크지만, 한 번 설계가 견고하게 완성되면 새로운 버전이 나오거나, 새로운 언어를 지원할 때의 확장 비용은 미미하다.

  국제화 및 현지화된 소프트웨어는 다음의 조건을 만족해야 한다.

 첫째, 지역의 고유한 환경에 관계없이 같은 기능을 오류없이 제공해야 한다.  특정 지역에서는 해당 기능이 동작하지만, 다른 지역 환경에서는 동작하지 않는 일이 있어서는 안된다. 사용자의 운영체제가 Windows 한국어판이든지, Windows 일본어판이든지 상관없이 소프트웨어가 가진 모든 기능을 제공해야 한다는 의미이다.
 
 둘째, 각 지역의 고유한 특성에 맞는 입력을 받아들여, 역시 그 특성에 맞는 출력 결과를 제공해야 한다.  애플리케이션은 사용자에게, 각자의 환경이 아닌 특정한 환경에 맞는 입력을 강요하거나, 특정한 환경에만 맞춘 출력 결과를 이해하도록 강요해서는 안 된다. 한국의 소수점 기호(.)와 숫자 분리 기호(,)를 사용한 숫자 출력 결과를 프랑스인에게 제공한다고 가정해 보자. 기본적으로 이 애플리케이션은 첫 번 째 조건인 "오류없이 동작"을 성공적으로 만족시키기는 했지만, 올바르다로 할 수 없다. 프랑스인이 소프트웨어를 사용하고 있다면, 당연히 같은 숫자 값이라도 프랑스의 소수기호와 숫자분리 기호를 사용한 출력 결과를 제공해야 하는 것이다.

 셋째, 양질의 번역된 인터페이스와 도움말을 제공해야 한다.  소프트웨어 현지화의 조건 중 가장 드라마틱한 결과를 제공해 주는 부분이 바로 번역이다. 소프트웨어 자체의 겉모습을 완전히 새로 치장하는 것으로 가장 이상적인 상황에서 이해한다면, 사용자의 입장에서는 지금 사용하고 있는 소프트웨어가 마치 자신의 나라에서 직접 생산된 소프트웨어인 듯한 편안함을 가지게 해 주는 기능이라고 할 수 있다. 표준화된 방식에 따라 소프트웨어의 구조를 변경한 이후로는 개발 비용이 크지 않은 첫 번 째나 두 번 째 조건과는 달리, 번역은 상당히 큰 "서비스"이며 비용 또한 만만치 않다. 첫 째, 둘 째 조건들이 모든 나라에서 반드시 제공되어야 하는 조건이라고 한다면, 셋 째 조건인 "번역"은 주로 다수의 사용자들을 이미 확보한, 또는 다수의 사용자가 있을 것으로 확실히 예측되는 지역에 대해 제공되는 것이 일반적이다.

탄탄한 소프트웨어 국제화/현지화 조직

위와 같은 조건을 맞족하는 국제화/현지화된 소프트웨어를 만들어내기 위해서는 다음과 같은 조직이 필요하다. 규모가 크지 않은 생산 업체라면, 각 조직이 소수의 전문가로만 구성될 수도 있겠지만, 그 기능의 분리 및 협력은 이와 같이 명백히 정의되어야 한다.

소프트웨어 국제화 조직

 소프트웨어의 기능을 각 나라별로 직접 구현하는 조직을 의미하는 것이 아니다. 소프트웨어 자체만 "지구 버전"인 것이 아니라, 개발 자체도 "한국어 기능을 포함하기 위한 개발", "베트남어를 지원하기 위한 개발"이라는 것이 존재해서는 곤란하다. 단순히 "국제화를 지원하기 위한 개발"이라는 목표만이 있어야 할 것이며, 이 조직은 소프트웨어를 그와 같은 방식으로 개발하기 위해 필요한 개발 방식을 정확히 알고, 실제 개발 조직이 그 방향으로 움직일 수 있도록 도와 주는 조직이다. 크게 보아 반드시 다음과 같은 기능을 제공해야 한다

• 소프트웨어 현지화 정보 수집 및 관리 : 특정 지역에서 사용되는 여러 가지 고유의 정보(통화 기호, 날짜 포맷 등)들을 모두 수집하고 관리해야 한다. 이런 정보들은 주로 고정적이지만, 통화 기호처럼 사회적 상황에 따라 변화되는 정보들도 있다. 예를 들어, 유럽 연합의 통화 기호가 "유로"로 통일된다는 것이 고지되었을 때, 이런 조직들은 상당히 발빠르게 움직였을 것이다. 자신들이 보유하고 있는 정보를 수정하는 것과 더불어, 해당 지역들이 상당 기간 기존의 통화와 새로운 통화를 동시에 사용하게 될 때 개발될 소프트웨어를 유동적으로 동작시키는 방법에 대한 고민을 했을 것이다.
• NLS 기능 라이브러리 제공 : 보유한 현지화 정보를 개발자들이 사용할 수 있도록, 통일된 방법을 제공하는 것도 이 조직의 몫이다. 여러 소프트웨어의 개발자들에게 각자 이 정보들을 직접 접근하도록 맡긴다면 효율이 떨어질 것은 분명할 뿐더라, 실수가 빈번할 것이 분명하다. 개발자들이 주로 사용하는 프로그래밍 언어로 개발된 통일된 라이브러리와 매뉴얼을 제공하는 것이 중요하다. 오라클의 인프라스트럭쳐 소프트웨어(데이터베이스, 웹 애플리케이션 서버 등)들의 경우, 이를 기반으로 개발을 진행하는 수많은 고객 개발자들이 존재하며, 이들에게도 이런 라이브러리들은 점점 중요해지고 있다. 따라서 지난 회에 언급한 대로 오라클은 GDK(Globalization Development Kit)을 오라클 소프트웨어 기반의 개발자들이 사용할 수 있도록 배포하고 있다.
  
• 국제화 테스팅 : 개발자들이 소프트웨어 국제화 기능(첫 째 조건)을 제대로 구현했는지 꼼꼼히 테스트하는 것도 이 조직의 중요한 임무이다.  이 테스팅은 모든 나라나 모든 언어에 대해 이루어질 수도 있지만, 그렇지 않을 수도 있다. 지역별  테스팅은 아래 언급할 현지화 테스터들에 의해 수행되게 된다. 이 조직의 테스트에서 그보다 중요한 것은, 하나의 멀티바이트 언어나 지역을 이용해 테스트할 지라도,  모든 기능에 대해 시험하는 것이다.

소프트웨어 국제화에 대한 지식을 가지고 있는 엔지니어들이 주로 이 조직의 구성원이 된다.

소프트웨어 번역 조직

소프트웨어의 번역은 비용이 많이 드는 작업으로 특히 그 운영이 효율적이어야 한다. 소프트웨어를 번역하는 조직은 다음과 같은 조건을 만족해야 한다.

• 정확한 용어 사용 : 단순히 사전을 열람하여 번역을 시도했다가는 터무니없는 번역 결과가 나올 수 있다. 번역 담당자는 반드시 해당 기술에 대해 지식을 가졌거나, 아니면 전문가 혹은 표준화된 산업 용어를 사용하여 번역해야 할 것이다.
  
• 일관성 :  특정 위치에서는 해당 단어를 번역하고(예:자바), 다른 위치의 화면에서는 해당 단어를 번역하지 않거나(예:Java) 다른 용어를 사용하여 번역해서는 안 된다. 소프트웨어는 그 특성상 외국에서 유입된 용어들이 상당히 많으며 이들이 단순히 소리나는 대로 표기되기도 하고(예: 버튼), 우리 말로 번역되어 사용되기도 한다(예: 단추). 어떤 방향이든 일관성을 유지하는 것도 중요하다.
  
• 비용 절감 : 번역시 불필요한 비용이 발생해서는 곤란하다. 예를 들어, 이전 버전의 소프트웨어 개발시 이미 번역했던 문장을, 단지 화면이 변경되었다고 해서 새로운 버전의 개발시 다시 번역한다면 이중의 비용을 들이는 셈이 된다.

이 조건들을 만족하는 번역 프로세스를 수행하기 위해 다음의 조직들이 필요하다.

번역 시스템 운영 조직

번역은 기계적은 프로세스만으로는 해결될 수 없다. 개발 과정에서 사람의 손을 가장 많이 거치게 되는 부분이라 할 수 있다. 그래서 앞서 말한 대로 프로세스가 느리고 상당히 값비싸다. 따라서,  번역에 대한 사전 준비 과정(preprocessing)과 번역 후의 처리 과정(postprocessing), 그리고 번역 결과의 보존 및 관리가 매우 중요하다. 소프트웨어 번역 조직의 시스템은 일단 그 완벽성을 위해서는 다음과 같은 금지의 법칙을 지켜야 한다.

• 번역 누락 금지 : 개발조직에서 번역 대상으로 분류한 리소스들은 반드시 누락 없이 번역 수행 조직으로 보내야 한다. 그리고 번역 수행 조직으로부터 돌아온 결과는 반드시 안전하게 개발 조직으로 공급해야 한다.
  
• 번역 반복 금지 : 이미 번역된 결과를 다시 번역 수행 조직으로 보내어서는 안 된다.

일단 운영 조직은 번역 수행 조직에게 번역 요청을 하기 전에 다음과 같은 작업을 선행해야 한다.

1) 번역 전 작업

개발 조직에서 전송되는 번역 리소스들은 상당히 다양한 형식을 취하고 있는 것이 보통이다. 그리고 번역 전문가들이 사용하고 있는 도구들 또한 다양하다. 따라서 번역이 필요한 리소스들을 번역가들에게 일관된 형식으로 전달하는 것이 중요하다. 번역가들은 각 지역별 환경에서 작업하므로, 지역별 특성도 함께 고려해야 한다. 운영 조직은 번역 리소스들에 사전 작업을 가하여 번역가들이 작업할 수 있는 환경을 만들어내야 한다.

또한 번역 리소스들 중에는 이미 번역한 결과가 포함될 수 있다. 이미 번역한 결과는 아래 언급되어 있는 번역 결과 데이터베이스에 저장이 되어 있다. 번역 전 작업시 번역 리소스들을 데이터베이스와 대조하여 이미 번역된 리소스를 다시 번역하는 일이 없도록 해야 할 것이다.

예를 들어 개발 조직에서 오라클 데이터베이스를 위한 메시지 파일을 번역하고자 할 때, 사전에 이 메시지 파일에서 번역 리소스들을 추출해 현재 번역 데이터베이스와 대조한다. 아직 번역된 일이 없는 새로운 리소스들만을 추출하여번역 조직에서 사용하는 도구에 맞는 번역 패키지를 생성한다.

2) 번역 후 작업

번역 수행 조직으로부터 돌아온 번역 결과는 다시 번역 전 작업의 역순으로 진행해 개발 조직으로 전송할 수 있는 형태로 만들어내야 한다. 그리고 새로운 번역 결과는 번역 결과 데이터베이스에 저장하여 다음 번역 수행시 활용할 수 있도록 해야 한다.

예를 들어, 번역 수행 조직에서 돌아온 번역 결과를 다시, 개발조직에서 처음에 전달했던 메시지 형식으로 복원하여 전달하게 된다. 그리고 새로운 번역 결과는 아래의 번역 결과 데이터베이스에 잘 저장을 한다.

3) 번역 결과 보존

앞서 언급했듯이 번역은 값비싼 프로세스이므로 그 결과는 잘 보존되어야 한다.

• 번역 결과 데이터베이스 : 번역된 결과를 문장 혹은 단락 단위로 저장하여 번역의 재사용성을 높이는 데 사용된다.
  
• 용어 데이터베이스 :  일관된 번역을 위해 어떤 제품에서 어떤 용어가 어떤 단어로 번역되었는지를 보존한다.

번역 프로세스를 잘 이해하고 있는 엔지니어들이 주로 이 조직의 구성원들이다.

번역 수행 또는 번역 수행 업체 관리 조직

소프트웨어의 번역을 실제로 수행하는 조직이다. 이 조직은 번역 시스템 운영 조직으로부터 전달받은 번역 대상물을 번역하여 그 결과를 약속된 형식으로 돌려주는 역할을 한다. 규모가 큰 소프트웨어 개발업체는 일반적으로 번역 자체를 내부 인력으로 감당할 수 없다. 그러기에는 번역의 규모가 너무 방대하기 때문이다. 따라서, 이 조직은 일반적으로 양질의 번역 협력사와 계약을 맺어 번역을 아웃소싱한다.

번역 프로세스의 실제 수행

• 번역 프로세스의 실질적 비즈니스 운영 주체 : 번역이라는 프로세스를 수행하는 데 필요한 예산을 요청 부서와 협의하고, 그 테두리와 협력사와의 계약을 기반으로 번역을 수행한다.
• 번역 수행 또는 보조 : 번역을 직접 수행하지 않는 경우에는 번역 전문가들이 문의하는 제품의 특성에 대해 적절히 답변하여 제대로 된 번역이 이루어지도록 해야 한다.
  
• 번역 검수  : 최종 번역 결과를 운영 조직으로 전달하기 전에, 그 결과물을 검수하여 문제있는 번역이 제품에 포함되는 일이 없도록 한다.
  

번역 프로세스 외의 작업

• 품질 관리 : 번역 결과가 개발 조직으로 전달되어 제품으로 출시된 이후에도 일반 사용자들로부터의 번역 품질 피드백에 따라 품질을 평가하고 향상을 도모하게 된다. 또는 자체 품질 평가 기준을 마련하여 해당 수치에 미달하는 품질을 판별 다음 계약을 안전하고 확실하게 할 수 있도록 해야 한다.
• 번역가(협력사) 교육 : 새로운 프로세스가 소개되었을 경우나 새로운 제품이 출시되었을 때 번역가들에게 사전 지식을 심어준다.

원본 언어(한국 제품의 경우 한국어, 미국권 소프트웨어의 경우 영어)와 번역 대상 언어에 능통하며, 해당 소프트웨어 대해 포괄적 지식을 가진 전문가들이 주로 이 조직의 구성원들이다.

소프트웨어 현지화 테스팅 조직

국제화 테스팅 작업은 주로 기능(Functionality) 테스트에 집중하지만, 현지화 테스팅은 각 지역별 입출력 및 번역된 화면을 검사하는 역할을 한다. 각 언어 및 지역별 지식을 가진 구성원들은 주로 다음과 같은 임무를 수행한다.

• 현지화 테스팅 : 각 지역별 환경(OS나 NLS_LANG과 같은 지역별 환경변수)을 정확히 구비하고, 그 환경 상에서 최종 사용자의 사용 시나리오를 기반으로 입출력 테스팅을 수행한다.
  
• 번역 테스팅 : 번역 결과가 제품에 포함된 이후, 제품을 수행하여 번역으로 인해 제품이 동작하지 않거나, 번역 결과가 제대로 나오지 않는 경우, 또는 번역되지 않은 부분이 있는 경우를 검사한다.
  

각 지역별 지식을 갖추고, 소프트웨어를 매뉴얼 대로 설치 및 운영할 수 있는 테스트 엔지니어들이 주로 이 조직의 구성원들이다.

소프트웨어 현지화 구현 조직

소프트웨어 현지화 정보 중, 법규나 비즈니스 같은 경우는 빈번히 수정되는데다가 통합 수집 관리가 불가능한 경우가 많다. 이럴 경우, 각 지역별 전문가 조직이 직접 해당 요구 조건을 구현해야 한다. 오라클은 한국에서 국세청을 비롯 다수의 공공기관을 고객으로 유치하였다. 이들 기관은 법규에 따라 행정을 수행하며, 특히 "연말 정산"과 같이 빈번히 변하는 법규도 있다. 그러므로, 해당 고객의 시스템은 법규의 변화에 민첩하게 대응할 수 있어야 한다. 어떻게 한국에서 생산된 제품이 아닌, 오라클 소프트웨어가 그런 변화에 대응할 수 있을까? 정답은 바로 각 지역별로 상주하는 현지화 전문가들에 있다. 이들은 법규나 시장의 상황의 변화를 긴밀히 살피고 변화가 감지 또는 고지되면, 즉시 시스템 현지화 작업을 재시행해 변화된 법규를 반영한다.

시스템 운영의 지식과 함께 현지화 대상 비즈니스 영역에 대한 지식을 보유한 전문가들이 주로 이 조직의 구성원이 된다.

표준에 기반한 국제화/현지화 가이드라인

개발 조직과 국제화/현지화 조직들을 위해서는 다음과 같은 가이드라인을 미리 만들어 준수하도록 유도해야 한다. 개발 조직의 규칙 위반은 번역 시스템의 입력이 되는 번역 대상에 오류를 발생시킬 수 있다. 그리고 번역 시스템 운영 조직의 잘못된 운영은 번역 자체가 이루어지지 않거나 번역의 비용을 증가시킬 수 있다. 번역 수행 조직의 오류가 야기할 문제는 품질 저하로 이어진다. 그리고 테스팅 조직의 실수는 문제를 발견하지 못할 수도 있고, 문제가 아닌 것을 문제라고 판단할 수도 있다.

개발 조직을 위한 가이드라인

• 국제화/현지화 지원을 위한 개발 가이드라인
  예) C혹은 Java로 구현된 NLS 라이브러리(API) 및 매뉴얼
  
• 번역 리소스 생성 및 전달 및 돌아온 결과 병합에 관한 프로세스 가이드라인
  예) 메시지 파일 혹은 Java property 파일 처리 방법
  

번역 조직들을 위한 가이드라인

• 번역 리소스들의 포맷에 대한 가이드라인
   예) java.util.ResourceBundle 클래스 형식의 리소스 처리 방법
  
• 번역 가능성(Transtability)에 대한 가이드라인.
    예) 고유명사, 기계명, 명령어 등은 절대 번역해서는 안 된다.
  

테스팅 조직들을 위한 가이드라인

• 각 지역별, 플랫폼 별 환경 설정 가이드라인
  예) 리눅스에서 한국어 및 한국지역 환경 설정 방법
  
• 오류 테스트 방법 가이드라인
  예) 번역 테스팅을 위한 테스트 케이스
  
• 버그(문제점) 보고 방식에 대한 가이드라인
  예) 버그 리포트 형식
  

소프트웨어 현지화 구현 조직을 위한 가이드라인

• 지역화 구현 개발 요청 및 진행 절차 가이드라인
  

연재를 마치며

소스 코드 예제가 없잖아?

개발자들은 문서에 소스 코드가 있으면, 소스 코드에 자연스럽게 눈이 먼저 가게 되는 습성이 있다. 그래서, 이와 같이 예제 소스 코드가 없는 글에 대해 잘 적응이 안 되었을 지도 모르겠다.  백마디 말보다, 몇 줄의 소스 코드로도 모든 것을 이해해 버리는 한국의 개발자들의 명성은 높다. 하지만, 반대로 "매뉴얼을 읽지 않는다"라는 악명도 함께 가지고 있다. 소프트웨어의 세계화, 소스 코드의 몇 줄을 먼저 치기 전에 반드시 개념을 익히기를 바란다.

소프트웨어의 세계화, 만만치 않구나!

 소프트웨어 세계화를 위한 조직이 이렇게 복잡한가 하고 반문하는 독자가 있을 수도 있다. 일견 그럴 수도 있다. 값비싼 국제화 프로세스 없이 필요할 때마다 아웃소싱으로 현지화를 수행할 수도 있다. 하지만, 냉정하게 말하면 그렇게 단순히 생각할 수 있는 이유가 바로 근본적으로 국제화를 해야 할 만큼 유명세를 탄 소프트웨어라는 것이 한국에 존재하지 않기 때문이기도 하다. 국제화/현지화는 대세이며 거스를 수 없다. 단지 우리가 그런 소프트웨어를 보유하고 있지 않을 뿐인 이 시점에서 개발자들은 현재 국제적인 명성을 얻고 있는 업체들의 "세계화" 노력을 특히 먼저 이해하고 받아들여야 한다.

NLS의 중요성을 알게 되었습니까?

지금까지 4회에 걸쳐, 오라클의 NLS 서비스 제공 방법과, 한글 환경에서 오라클 제품을 제대로 사용하는 데 있어 가장 문제가 되는 점을 짚어 보았다. 오라클의 NLS 지원은 전 세계에서 동시에 일하고 있는 수많은 NLS 전문가들에 의해 이루어진다. "특정 언어 버전"의 제품이 없다는 점에서 오라클은 진정한 "세계 버전"의 제품이라 할 수 있다. 하지만, 무엇보다도 시스템에 대해 최초 구성을 잘 하는 것이 중요하다. 최초에 잘못된 변수, 잘못된 캐릭터셋을 사용한다면, 계속 잘못된 데이터 조작 연산을 수행할 가능성이 높고, 시간이 흐르면 흐를 수록 이것은 수정하기 힘들다.  오라클 사의 직원이 이렇게 오라클의 NLS 지원에 대해 아주 훌륭하다고 입이 마르도록 칭찬한다 할 지라도, 결국 그 의미가 "오라클은 잘 만들어진 도구" 이상은 아니다. 필자는 이 네 번의 연재로부터 독자들이 오라클 이라는 도구에 대한 지식을 익히는 것도 중요하지만, 그보다는 소프트웨어에 있어 NLS 지원이 얼마나 중요하고 복잡한 요소인가에 대한 인식을 하게 되기를 바란다.

더 궁금한 사항이 있습니까?

만일 NLS의 핵심 개념들 중 더 깊이 알고 싶은 사항이 있다면 한국오라클 OTN 홈페이지의 NLS 포럼을 이용할 수 있다.

OTN 포럼 바로 가기

이 포럼에서 여러분들께서는 번역 관련 질문들을 포함해 NLS에 관련된 어떠한 질문도 할 수 있으며, 추가적인 연재에 대한 요구도 물론 할 수 있다. 그리고 이 글을 쓰고 있는 시점까지는 두 사람이 외로이(?) 답변을 열심히 하고 있으나, 이제 여러분들의 지식과 경험이 날로 쌓여 현장에 발견한 모든 지식을 함께 공유해 줄 수 있으리라 믿어 의심치 않으며 연재를 모두 마친다.


[출처] http://www.oracle.com/technology/global/kr/pub/columns/oracle_nls_4.html