|
기술: 세계화
세계화 전략
Ron Hardman
Oracle Database 10g Release 2의 세계화 지원 기능은 지역화를 용이하게 해줍니다.
프로젝트의 개발 주기가 거의 완료 단계에 와 있고 팀원 모두 이제 일이 다 끝난 것처럼 느끼고
있었습니다. 늦게까지 일하던 날들, 지독히도 긴 회의, Jerry 사장님이 열광적으로 하시던 말씀들, 셀 수 없이 마셔댄 커피로
이어진 6개월이었습니다. 2주만 있으면 이 회사 주력 상품의 중요한 릴리스가 출시될 예정이었습니다. Oracle Database
선임 개발자였던 Scott은 그 누구보다도 기뻤습니다. 길고 긴 터널 끝에 드디어 빛이 보이기 시작했으니까요.
며칠 전 대형 계약이 체결되었다는 소문이 돌기 시작했습니다. 거물급 고객을 확보하는 경우 늘 그렇듯이 사장님은 개발자들과 해당 계약건에 대해 논의하고 구현에 관한 지시를 내리기 위한 회의를 마련했습니다. 사장님은 몇 마디 의례적인 인사말을 건넨 후 곧장 “오늘의 가장 멋진 소식”을 발표했습니다. "
“우리는 화요일에 일본 최대 유통회사와 우리가 출시할 릴리스를 지역화된 버전으로 제공하는 계약을 체결했습니다.” 사장님은 이렇게 말씀하시면서 이번 계약건에 무척 기뻐하는 듯이 보였습니다. “일본의 한 회사에 번역 작업을 맡기기로 계약되었으니 이 회의가 끝나는 대로 각 팀에서는 코드를 지역화할 수 있는 상태로 준비해 주십시오. 영어 버전 출시 후 1달 내에 새 고객에게 애플리케이션을 제공해야 합니다.”
Scott은 마음이 뒤숭숭했습니다. 이 제품의 첫 릴리스가 나올 때부터 이 회사에서 일해왔지만 이 소프트웨어를 외국으로 배포하는 일에는 한번도 관여해본 적이 없었기 때문이었습니다. Oracle8i Database에서 제공하는 오라클의 NLS(National Language Support)에 대해 어렴풋이 들어본 적은 있었지만 회사에서는 Oracle Database 10g Release 2를 기반으로 작업하던 중이었습니다. “우리 애플리케이션 디자인으로는 이 일이 불가능할 텐데.” Scott은 사무실로 돌아가면서 동료에게 말했습니다.
터널 끝에 막 보이기 시작하던 빛은 그만 어디론가 사라져버리고 말았습니다.
문제 정의
Scott과 그의 팀은 아주 힘든 일을 맡게 되었습니다. 이 일을 성공적으로 해내기 위해서는 다음과 같은 작업이 필요했습니다.
- 회사와 제품에 대한 세계화 전략 확인
- 국제화에 필요한 단계 결정 및 구현
Scott과 그의 팀은 Oracle Database 10g의 세계화 문서와 지역화 업계 표준 협회(LISA: Localization Industry Standards Association)를 참고하기로 결정했습니다.
세계화. LISA는 세계화(g11n)를 다음과 같이 정의하고 있습니다.
"[세계화는] 진정한 의미에서 회사를 세계적으로 만드는 일과 관련된 기업의 모든 문제를 처리하는 과정을 의미한다. 제품과 서비스의 세계화 과정에는 내외부의 모든 비즈니스 기능을 세계 시장의 마케팅, 판매, 고객 지원 업무와 통합하는 일이 포함된다.”
Scott은 Jerry 사장님, 제품 개발팀, 부서 책임자와의 회의를 통해 이들 모두가 해당 업무와 제품에 대한 g11n 전략을 완전히 이해할 수 있도록 했습니다. 일단 방향이 설정된 후에 Scott은 작업을 UI 팀과 나누기로 합의했습니다. UI 팀에서는 Oracle Globalization Development Kit의 Java API를 주로 사용하여 사용자 인터페이스에 필요한 변화를 중점적으로 다루기로 했고, Scott과 그의 팀은 데이터베이스에 주력하여 이를 로케일 독립형으로 재설계하기로 했습니다. 그들은 매일 만나서 진행 상황을 점검하고 중복되는 분야가 있는지 논의하기로 했습니다.
이 팀은 또한 제품 설치를 단일 지역 및 언어로 제한하기로 결정했습니다. 다음에서 알 수 있듯이 이러한 결정을 통해 디자인을 대폭 단순화할 수 있게 되었습니다.
국제화. LISA는 국제화(i18n)를 “…재설계를 거치지 않고 다수의 언어와 문화적 관습을 처리할 수 있도록 제품을 일반화하는 과정이다. 국제화는 프로그램 디자인 및 설명서 개발 단계에서 이루어진다”고 정의하고 있습니다.
Jerry의 선포 후 처음 열린 회의에서 Scott과 그의 팀은 데이터베이스 디자인을 둘러보면서 i18n에 따라 처리해야 할 특정 영역을 찾아냈습니다. 이 팀에서 제품 데이터베이스의 지역화를 위해 준비해야 할 작업은 다음과 같은 4개의 주요 범주로 분류되었습니다.
애플리케이션에 따라 다른 i18n 영역의 문제를 다루어야 하는 경우도 있었지만 이 목록으로 Scott과 그의 팀이 처리해야 하는 주요 영역을 파악할 수 있었습니다.
오라클의 세계화 지원
NLS(National Language Support)라는 용어는 모든 Oracle Database의
i18n과 지역화 기능을 일컫는 말이었습니다. 그러나 지금은 오라클에서 세계화 지원(Globalization Support)이라고
부르는 기능의 하위 집합에 해당됩니다. Scott이 받았던 Oracle8i Database 교육 이후에 추가된 두 가지 주요
기능이 문자 의미(character semantics)입니다. Oracle9i Database는 멀티바이트 문자를 처리하는 방식을
바꿔 놓은 문자 의미를 도입했습니다. 열이나 변수 정밀도를 두 배, 세 배로 늘이는 대신, NLS_LENGTH_SEMANTICS = CHAR를 설정할 경우, Oracle Database는 ‘Today’라는 문자열 저장을 일본어 문자열 'こんにちは'와 같은
것으로 취급합니다. 이러한 설정에서는 문자 저장에 필요한 바이트 대신 글리프(문자)가 열과 변수 정밀도에 대한 측정 기준이 됩니다.
(문자 의미에 대한 자세한 내용은 본 기사 마지막에 나오는 다음 단계 의 링크를 참조하십시오.)
Globalization Development Kit. Oracle Database
10g Release 1에는 Java와 PL/SQL 개발자들을 위해 i18n와 지역화 속도를 높여주는 GDK(Globalization
Development Kit)가 추가되었습니다. Oracle Database 10g Release 2는 새로운 음역 및 로케일
매핑 기능을 추가하여 UTL_I18N 제공 패키지에 포함된 기능 집합을 향상시켰습니다. GDK에는 Java와 PL/SQL API가
포함되어 있습니다. UTL_I18N 패키지는 GDK를 위한 대부분의 PL/SQL 작업을 수행하는 반면 UTL_LMS 패키지는
오류 메시지를 받아 특정 언어로 형식을 변환합니다.
그 외에도 Oracle Database 10g Release 2는 Unicode 4.0도 지원합니다. 이는 전세계의 모든 공용 언어의 모든 문자가 하나 이상의 Oracle Database 문자 집합에 의해 지원된다는 것을 의미합니다.
국제화 작업 진행
Scott과 그의 팀은 연구를 통해 확인한 내용을 검토하여 각각의 문제를 해결해나가기로 결정했습니다.
통화. 첫 번째 범주, 통화에서는 다음과 같은 한 가지 요구 사항을 준수해야 했습니다.
국제적으로 인정된 ISO 통화 형식 준수
통화 간 거래를 지원하는 회사라면 통화 전환이 필요할 수도 있었습니다. Scott의 회사에서는 제품 설치 당 단일 지역만을 허용하기로 결정했기 때문에 이 요구 사항은 문제 삼을 필요가 없었습니다.
Scott은 몇 가지 방법으로 통화 형식을 설정할 수 있었습니다. 우선 NLS_CURRENCY매개변수를 사용하여 세션 별 통화 기호를 설정할 수 있었습니다.
통화 기호에 대한 기본값은 NLS_TERRITORY 매개변수 값을 기반으로 정해집니다. 세션을 NLS_TERRITORY = 'AMERICAN'로 설정하면 기본 통화 기호 값은 달러($)가 됩니다.
설정된 NLS_CURRENCY 매개변수 값은 NLS_TERRITORY 매개변수와 일치하는 기본
기호는 무효화합니다. 이를 테스트하기 위해 Scott은 다음과 같이 실행하여 NLS_TERRITORY 매개변수는 AMERICAN으로,
NLS_CURRENCY 매개변수는 엔(￥)으로 설정했습니다.
ALTER SESSION SET
NLS_TERRITORY = 'AMERICA';
ALTER SESSION SET NLS_CURRENCY = '¥';
그런 다음 iSQL*Plus에서, TO_CHAR 함수와 형식 마스크를 사용하여 PRODUCT_PRICE 테이블에 대해 SELECT를 실행했습니다
SELECT TO_CHAR(price, 'L999G999')
AS "Price"
FROM product_price;
/
Price
¥23
¥55
¥34
참고: iSQL*Plus를 사용하여 멀티바이트 문자가 표시되는지 확인하고 브라우저 인코딩을 Unicode(UTF-8)로 설정하십시오.
형식 마스크가 L부터 시작되므로 해당 통화 기호가 결과 내에 포함되어야 한다는 것을 보여줍니다. G는 NLS_NUMERIC_CHARACTER 매개변수가 지정한 그룹 분리자입니다.
Scott은 또한 NLS_TERRITORY 값을 사용하여 적절한 통화 기호를 파생시킬 수도 있었습니다. NLS_TERRITORY 값과 TO_CHAR 함수에 전달된 형식 마스크가 통화 형식을 결정합니다.
이 대안을 테스트하기 위해 Scott은 새 세션에서 NLS_TERRITORY를 GERMANY로 설정해보았습니다.
ALTER SESSION SET
NLS_TERRITORY = 'GERMANY';
그런 다음 같은 SELECT 문을 실행하여 TO_CHAR와 함께 사용된 형식 마스크를 수정했습니다.
SELECT TO_CHAR(price, 'L9999') AS "Price"
FROM product_price;
/
Price
€23
€55
€34
형식 마스크에 L이 포함되어 있으므로 역시 해당 통화 기호가 결과 내에 포함되어야 한다는 것을 보여줍니다. 그룹 분리자는 사용되지 않았습니다.
제품 설치는 한 번에 한 지역만을 지원하므로 NLS_TERRITORY가 적절한 통화를 지원하게 하는 방법을 사용할 수 있었습니다. Scott은 관리 테이블에 모든 통화 형식을 저장하고 설치 시 애플리케이션 전체에 대해 이를 설정하기로 결정했습니다.
문자열. 두 번째 범주인 문자열에는 두 가지 요구 사항이 있었습니다.
- 현재 US7ASCII인
문자 집합 권장 사항 평가
- 멀티바이트 문자열이 열/변수 정밀도를 초과하지 않아야 함
첫 번째 요구 사항의 경우 US7ASCII 문자 집합이 멀티바이트 데이터와 함께 작동되지 않습니다. 일본어 문자는 각각 3바이트 크기이므로 허용되지 않기 때문입니다. Scott 팀은 특정 언어 문자 집합을 선택하거나 범용 문자 집합을 계속 사용할 수 있었습니다. 개별 고객이 사용하는 언어를 기반으로 한 문자를 선택하는 것도 얼마든지 가능하지만 범용 문자 집합을 사용할 경우 다음과 같은 방법으로 도움이 됩니다.
- 모든 클라이언트 사이트에서 개발, 테스트, 지원을 위해 같은 문자 집합이 사용되는
경우, 문자 집합 관련 문제를 쉽게 잡아내고 쉽게 재현할 수 있습니다.
- 명령 집합이 단 하나뿐이므로 개별 언어 권장 사항이 필요 없습니다. 따라서
혼동의 염려가 적고 명령을 수정하지 않고도 거의 모든 언어를 간단히 지원할 수 있습니다.
Scott과 그의 팀은 Unicode AL32UTF8 데이터베이스 문자 집합을 권장하기로 결정했습니다. (이 문자 집합은 NATIONAL 문자 집합에 대한 유효한 선택이 아니라는 점에 주의하십시오.)
두 번째 요구 사항은 바이트 의미와 관련된 것이었습니다. Oracle Database 10g는 문자열에 들어 있는 문자 개수 대신 문자가 요구하는 바이트 개수에 따라 문자를 저장합니다. 이로 인해 각각 3바이트인 문자 5개가 정밀도 5의 변수 하나에 할당될 경우 문제가 발생합니다. Scott은 다음 보기를 통해 이러한 상황을 보여주었습니다.
ALTER SESSION SET
NLS_LENGTH_SEMANTICS = 'BYTE';
SET SERVEROUTPUT ON
DECLARE
v_string VARCHAR2(5);
BEGIN
v_string := 'こんにちは';
DBMS_OUTPUT.PUT_LINE(v_string);
END;
/
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 4
Oracle9i Database에 도입된 문자 의미는 몇 가지 방식으로 사용할 수 있습니다. 첫 번째 방식은 이 보기와 같이 CHAR를 추가하여 변수 선언을 변경하는 것입니다.
v_string VARCHAR2(5 CHAR);
프로덕션 코드의 모든 변수 선언을 변경하려면 모든 코드를 샅샅이 뒤져서 변경해야 하므로 너무 시간이 많이 걸리는 방법이었습니다. 게다가 오라클이 제공하는 패키지를 수정할 수 없기 때문에 내장형을 사용하는 경우에도 역시 문제가 될 수 있었습니다. Oracle Database 10g는 NLS_LENGTH_SEMANTICS 매개변수를 사용하여 이러한 문제를 훨씬 간단하게 해결해줍니다. NLS_LENGTH_SEMANTICS 매개변수는 단 하나의 세션 또는 전체 시스템에 대해 CHAR로 설정될 수 있습니다. 설정 후에는 문자 의미를 사용하도록 모든 코드를 재컴파일해야 합니다.
이 방법을 테스트하기 위해 Scott과 그의 팀은 한 세션에 NLS_LENGTH_SEMANTICS = 'CHAR'를 설정했습니다.
ALTER SESSION SET
NLS_LENGTH_SEMANTICS = 'CHAR';
앞에서 오류를 반환했던 익명의 블록을 재실행하여 이 문제가 해결되었는지 검증하였습니다.
SET SERVEROUTPUT ON
DECLARE
v_string VARCHAR2(5);
BEGIN
v_string := 'こんにちは';
DBMS_OUTPUT.PUT_LINE(v_string);
END;
/
こんにちは
PL/SQL procedure successfully completed.
데이터베이스에 대해 NLS_LENGTH_SEMANTICS = 'CHAR'를 설정하여 두 번째
문제를 해결했습니다. Scott은 이것을 설치 필요 조건 목록에 추가했습니다.
날짜 시간. Scott과 그의 팀은 날짜 시간에 대한 요구 사항 하나를 확인했습니다.
사용자의 지역에 해당되는 시간대를 확인하는 방법을 제공할 것
시간대 확인은 PL/SQL용 GDK를 사용하여 간편하게 해결할 수 있는 부분입니다. Scott은
한 번에 단 한 지역만을 지원해야 했지만 한 지역에도 여러 개의 시간대가 있을 수 있었습니다. 그러한 예로 미국을 들 수 있습니다.
NLS_TERRITORY 값 AMERICA에 대해 Oracle Database 10g는 뉴욕에서 하와이까지 7개의 시간대를 보여줍니다.
날짜 시간이 정확히 처리되는지 확인하기 위한 가장 편리한 방법은 각 사용자의 관리 화면에 시간대
선택란을 추가하는 것입니다. 시간대를 표시하는 드롭다운 목록이 이상적이기는 하나 이 목록을 어느 정도까지 줄일 수 없다면 실용성이
떨어집니다. PL/SQL용 GDK를 구현하는 UTL_I18N 패키지에는 GET_LOCAL_TIME_ZONES이라는 함수가 포함되어
있습니다. 이 함수는 지역을 입력하면 시간대 목록을 반환합니다.
Scott은 지역을 지정하여 시간대 목록을 검색할 수 있도록 다음과 같은 익명의 블록을 실행했습니다.
SET SERVEROUTPUT ON
DECLARE
v_array utl_i18n.STRING_ARRAY;
BEGIN
v_array := utl_i18n.GET_LOCAL_
TIME_ZONES('AMERICA');
FOR y IN v_array.FIRST..v_array.LAST
LOOP
DBMS_OUTPUT.PUT_LINE(v_array(y));
END LOOP;
END;
/
America/New_York
America/Indianapolis
America/Chicago
America/Denver
America/Phoenix
America/Los_Angeles
America/Anchorage
America/Honolulu
나중에 이 애플리케이션이 시간대 정보와 함께 날짜 시간을 표시해야 하는 경우에도 간단하게 이를 수행할 수 있습니다. 통화 형식을 설정할 때와 마찬가지로 TO_CHAR를 사용하여 결과 형식을 지정할 수 있습니다. NLS_DATE_LANGUAGE 매개변수는 원하는 언어로 표시되도록 지정하는 역할을 하며, 이 테스트에서는 일본어로 표시되도록 되어 있습니다.
SELECT TO_CHAR(SYSTIMESTAMP,
'yyyy/MM/dd hh:mi:ssxff AM',
'NLS_DATE_LANGUAGE = JAPANESE')
AS "Japanese Timestamp"
FROM dual;
/
Japanese Timestamp
2005/06/01 10:43:57.625000 午後
오류 처리. 오류 처리는 일반적으로
i18n에서 잘 고려하지 않는 내용이지만 실제로는 가장 중요한 작업 중 하나입니다. 이 문제를 명확히 짚고 넘어가기 위해 Scott은
다음 메시지를 바탕으로 어떤 조치를 취해야 할지 팀원들에게 물었습니다.
'行1でエラ?が ? 生しまし':
表名が無 ?す
Scott 팀에는 일본어를 아는 사람이 없었기 때문에 오류 번호만을 가지고 오류 메시지 내용을 짐작했습니다. “영어를 모르는 사람이 영어로 표시된 오류 메시지를 보고 추측하는 과정도 이와 똑같다”고 Scott은 말했습니다.
Oracle Database 10g에는 여러 언어로 쓰여진 메시지 파일이 포함되어 있습니다. 특정 언어로 쓰여진 메시지가 필요하면 별도로 설치해야 합니다.
소프트웨어 설치 시 그림 1과 같이 Oracle Database 10g에서는 언어를 추가 또는 제거할 수 있습니다. 나중에 다른 언어가 더 필요할 경우 설치자를 재실행하고 필요한 언어를 선택하거나 install_dir/install/addLangs.* 프로그램을 실행하여 언어를 추가할 수 있습니다.
|
| 그림 1: 언어 선택 대화상자
|
Scott은 테스트 데이터베이스 상의 언어 목록에 일본어를 추가했습니다. 메시지가 일본어로 반환되는지 확인하기 위해 그는 우선 세션의 NLS_LANGUAGE 매개변수를 수정했습니다
ALTER SESSION SET
NLS_LANGUAGE = 'JAPANESE';
그리고 나서 다음을 시행하여 오류를 생성했습니다.
SET SERVEROUTPUT ON
DECLARE
v_string VARCHAR2(2);
BEGIN
v_string := 行1でエラ?が ? 生しまし;
DBMS_OUTPUT.PUT_LINE(v_string);
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.PUT_LINE(
DBMS_UTILITY.format_error_stack);
END;
/
ORA-06502: PL/SQL:
?値まは値の エラ?:
文字 列バッファが小さすぎます が ? 生しまし
_
이것도 확실히 도움은 되지만 때때로 여러 언어로 형식을 추가 설정해야 하는 경우에는 어떻게 해야 할까요? 이 때에는 GDK에 포함되어 있는 UTL_LMS 패키지를 이용할 수 있습니다. UTL_LMS에는 두 가지 함수, 즉 원시 메시지를 가져오는 함수와 메시지 형식을 설정하는 함수가 있습니다. Scott은 영어뿐만 아니라 해당 지역 언어로도 오류를 보고하여 기술 지원을 통해 신속히 문제를 해결할 수 있기를 원했습니다. 그는 목록 1에서와 같은 빠른 테스트를 생성하여 오류 메시지를 일본어와 영어로 표시하였습니다.
코드 목록1: 영어와 일본어로 메시지 표시
SET SERVEROUTPUT ON
DECLARE
v_english_message VARCHAR2(500);
v_l10n_message VARCHAR2(500);
v_string VARCHAR2(2);
v_function PLS_INTEGER;
BEGIN
v_string:='行1でエラ?が ? 生しまし';
EXCEPTION
WHEN OTHERS
THEN
v_function := UTL_LMS.GET_MESSAGE(6502, 'RDBMS',
'ORA', 'JAPANESE',
v_l10n_message);
DBMS_OUTPUT.PUT_LINE(UTL_LMS.FORMAT_MESSAGE(v_l10n_message,
': Japanese Version'));
v_function := UTL_LMS.GET_MESSAGE(6502, 'RDBMS',
'ORA', 'AMERICAN',
v_english_message);
DBMS_OUTPUT.PUT_LINE(UTL_LMS.FORMAT_MESSAGE(v_english_message,
': English Version'));
END;
/
이를 통해 Scott은 이 테스트에 “영어 버전”을 추가한 것과 같은 방식으로 나중에 사용자 정의 메시지를 Oracle Database 10g의 메시지에 연결하는 융통성을 발휘할 수 있었습니다.
지역화
i18n이 올바르게 수행되면 지역화(l10n)는 간단하게 이루어집니다. LISA는 l10n을 다음과 같이 정의하고 있습니다.
"[지역화]란 제품을 이 제품이 사용되고 판매될 목표 로케일(국가/지역 및 언어)에 언어적, 문화적으로 적합하도록 만드는 일이다.”
다른 회사에서 지역화 작업을 담담하고 있었기 때문에 버그 수정 문제를 지원하는 일을 제외하고 Scott과 그의 팀은 세계화 프로젝트 작업을 완료할 수 있었습니다.
결론
Scott이 데이터베이스 변경 내용을 제출한 지 거의 3주가 지났습니다. 그 후 Jerry는 한국과 프랑스 등, 두 건의 해외 판매를 추가로 발표했습니다. 세계화된 애플리케이션을 만들어낸 팀원들의 노력 덕분에 이 제품은 두 나라에서 곧장 l10n 작업에 들어갔습니다.
Ron Hardman (Ron.Hardman@PeakRetrieval.com)
은 Academy District 20 schools의 애플리케이션 개발자이며 Peak Retrieval, LLC.의 창립자입니다.
Oracle Press에서 출판된 Oracle Database 10g PL/SQL Programming과 Expert Oracle
PL/SQL의 공동 저자입니다.
의견 보내기
| 
Bookmark
