<div id="readability-page-1" class="page"><div id="post-body-344823506513081607" itemprop="articleBody"><p>
소프트웨어를 이미 개발해 놓고 비즈니스가 잘되면 나중에 국제화를 적용하려고 하면 늦다는 것을 이전 글에서 살펴 보았다.</p><p>소프트웨어를 기획할 때부터 향후 1%라도 국제화 가능성이 있다면 계획에 따라서 적절한 국제화 기술을 미리 적용하는 것이 좋다.&nbsp;</p><p>그럼 어떠한 경우 국제화가 필요한가?</p><div><ul><li>국내 외에 해외에 소프트웨어를 판매하거나 서비스할 수 있다.</li><li>국내에서만 판매할 계획이지만, 국내의 외국인 고객이 사용할 수 있다.</li></ul></div><p>그럼 소프트웨어 국제화가 필요한 경우 어떠한 국제화 전략을 어떻게 수립해야 하는지 알아보자.</p><h2>국제화 적용 수준을 결정한다.</h2><p>당장은 아니고 미래에 해외에 팔 계획이 있는 소프트웨어라면 초기부터 국제화 기능을 모두 적용하면 기간, 비용이 많이 든다. 이러다가 해외 판매 계획을 취소하면 국제화 투자 비용은 매몰 비용이 된다.&nbsp;</p><p>따라서 판매 계획에 따라서 국제화 적용 정도를 달리하는 것이 좋다.</p><p>소프트웨어에 국제화 기능을 구현하기 위해서는 크게 2가지 모듈이 필요하다.</p><div><ul><li>국제화 모듈 (i18n module or library)</li><li>지역화 모듈 (L10n module or library)</li></ul><p>국제화 모듈은 국제화 아키텍처 전체를 다루는 모듈이고, 지역화 모듈은 하나의 국가 또는 언어 기능을 지원하는 모듈이다. (아래 그림 참조)</p></div><div><p><a href="https://blogger.googleusercontent.com/img/a/AVvXsEinPkH9Y1iUkhv4EQ4VuhVf5N3Yntr7ydU4eg2mlRTmASZBJbha91Hi6N-GzfattjXNmb2luB3vRKzt_c723tEjnm-A3I67yy6-IqEZFC-HR8AAUwwBDyk1hQ6ix5FmChrFEmjbumuERFCo1WrR4sF1_BoFEFd-uqPLb4ZI-pj7E6C6PC1mDgVbdVfaUOw"><img alt="" data-original-height="368" data-original-width="637" height="161" src="https://blogger.googleusercontent.com/img/a/AVvXsEinPkH9Y1iUkhv4EQ4VuhVf5N3Yntr7ydU4eg2mlRTmASZBJbha91Hi6N-GzfattjXNmb2luB3vRKzt_c723tEjnm-A3I67yy6-IqEZFC-HR8AAUwwBDyk1hQ6ix5FmChrFEmjbumuERFCo1WrR4sF1_BoFEFd-uqPLb4ZI-pj7E6C6PC1mDgVbdVfaUOw=w443-h256" width="280"></a></p><p>당장 해외 판매 계획이 있다면 위 그림 처럼 여러 지역화 모듈을 모두 만들어야 하지만, 당장은 국내에서만 판매를 하고 추후에 해외에 판매를 하려면 아래와 같이 필요한 국제화 기능만 개발을 하면 된다.</p></div><div><p><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiFm_yqyHxP7V3BoRm6pMn3RUpMFs17Kb95agCfLG8iH_n9ErDJXGJhb_13joboEsF6Ruh3PpITRjQSlNfycd_SLAampdJzLGixMSx6dxUeFk9LfJ4xTE7GHw6ydad98fyENwpFXxjtcBgAcEsnU--hsXuwELvxpgrTR-EXz1zlHsNWjVkO1sO_8YOaDvk"><img alt="" data-original-height="369" data-original-width="640" height="161" src="https://blogger.googleusercontent.com/img/a/AVvXsEiFm_yqyHxP7V3BoRm6pMn3RUpMFs17Kb95agCfLG8iH_n9ErDJXGJhb_13joboEsF6Ruh3PpITRjQSlNfycd_SLAampdJzLGixMSx6dxUeFk9LfJ4xTE7GHw6ydad98fyENwpFXxjtcBgAcEsnU--hsXuwELvxpgrTR-EXz1zlHsNWjVkO1sO_8YOaDvk=w429-h248" width="280"></a></p></div><p>이렇게 개발을 하면 한국어 전용으로 개발하는 것보다 1~2%의 개발 비용이 더 들지만, 나중에 국제화 기능을 새로 추가하는 것보다는 10배 이상 비용을 절약할 수 있다.</p><h2>국제화를 적용할 범위 결정</h2><p>국제화는 매우 광범위하다.</p><p>아래는 국제화 시 고려해야할 49가지라는 지난 글이다.</p><p>물론 이 모두를 적용할 필요는 없다. 내용을 읽어보고 현실적으로 우리 소프트웨어에 적용해야 할 범위를 결정한다. 국제화에 대한 지식, 경험이 없다면 무엇이 필요한지 결정이 어려울 수가 있으므로 국제화 전문가나 경험자의 도움을 받는 것이 좋다.</p><p>보통 필수적으로는 아래와 같은 것들을 적용한다.</p><div><ul><li>문자열 (번역)</li><li>날짜/시간</li><li>숫자</li><li>쓰기 방향 (좌우, 우좌)</li><li>대소문자</li><li>문자 정렬</li></ul></div><p>시스템적으로 필수적으로 결정해야 할 기술적인 요소는 다음과 같다.</p><div><ul><li>문자 인코딩 방법 및 변환</li><ul><li>Database, File, Network communication 시 사용할 문자 Encoding</li><li>지금은 UTF-8이 대세지만 아닌 경우도 있어서 주의해야 한다.</li></ul><li>국제화에 유리한 UI 배치</li><li>타임존 처리</li></ul></div><p>선택적으로는 소프트웨어의 종류나 특성에 따라서 추가 결정을 한다.&nbsp;</p><div><ul><li>폰트의 종류와 크기</li><li>화폐 단위</li><li>주소</li><li>전화번호</li><li>이름 표기</li><li>아이콘</li></ul><p>처음에는 어려운 일이지만, 국제화 모듈을 한번 잘 만들어 놓으면 회사의 여러 소프트웨어에 재사용이 가능하다.&nbsp;</p><h2>국제화 조직 구성</h2><p>큰 소프트웨어 조직은 국제화 팀이 별도로 있지만, 작은 조직은 별도의 팀을 갖추기가 어렵다. 그렇다면 일반 SW팀에 국제화 담당자를 별도로 지정하여 국제화 아키텍처를 설계하고, 국제화, 지역화 모듈을 개발하게 하면 된다.</p><p>모든 개발자가 국제화 기술을 다 알 필요는 없다. 국제화 담당자가 잘 만들어 놓은 기능을 그냥 써서 개발을 하면 된다.</p><p>시간을 표시하는 함수 하나도 그냥 쓰지말고 또는 본인이 직접 국제화를 적용하지 말고 국제화 담당자가 잘 만들어 놓은 국제화 시간 함수를 사용하면 되는 것이다.</p><p>국제화 담당자도 개발 초기 부터 국제화 모듈을 모두 완성해 놓을 필요는 없다. 그렇게 한다면 국제화 담당자가 국제화 모듈을 완성할 때까지 일반 개발자들은 개발을 시작할 필요가 없다.</p><p>국제화 담당자는 국제화 범위를 정하고 Interface만 정해 놓으면 된다. 즉 국제화 모듈의 Interface만 정하고 지역화 모듈은 제대로 개발할 필요가 없다.</p><p>시간 함수를 예로 들면 시간 함수의 Interface를 잘 정하고 나면 그 내용은 그냥 시간을 출력하는 함수를 최대한 간단히 구현해 놓으면 되고, 국가별 언어별로 다른 표시법은 적용할 필요가 없다.</p><p>이렇게 인터페이스를 만드는 데는 며칠 걸리지 않는다.</p><p>나중에 개발을 진행하면서 지역화 모듈의 내용을 하나씩 채워가면 지연 없이 개발이 진행된다.</p><h2>국제화 마인드</h2><p>국제화가 잘 된 소프트웨어를 개발하는 것은 매우 어렵다. 경험이 적으면 국제화가 누락된 소프트웨어를 개발하기 쉽다.</p><p>예를 들어보자.</p><p>사용자가 입력한 문자열을 단어별로 쪼개서 처리하려고 한다. 그래서 띄어쓰기로 token을 구분하여 처리를 했다고 하자. 하지만 띄어쓰기를 사용하지 않는 언어는 의외로 많다. 이런 곳에서는 이 기능은 제대로 동작하지 않을 것이다. 이처럼 예상치 못하게 국가별 언어별로 다른 것들이 꽤 많다.&nbsp; 다음과 같은 것들이 있다.</p><div><ul><li>띄어쓰기</li><li>단수, 복수 처리</li><li>좌우 쓰기 방향</li><li>문장 순서</li><li>달력</li></ul><p>이외에 매우 많다. 어떤 것은 해당 국가에서 이상하게 보여도 나름 용인이 되는 것도 있고, 용인이 되지 않는 것도 있고, 명백히 버그가 되는 것도 많다.</p></div><p>예를 들어 숫자의 소숫점은 국가별로 다르다. 숫자의 소숫점을 잘못 처리하면 명백한 버그가 되고 큰 사고가 될 수도 있다.</p><p>그래서 우리가 이러니 전세계 모든 국가에서도 이럴 것이라면 생각을 버려야 한다. 어려운 일이다. 그래서 국제화 전문가가 회사에 적어도 한명은 있으면 좋다. 그렇지 않으면 국제화 전문가의 컨설팅을 받으면 적은 비용으로 큰 문제를 해결할 수 있다.</p><h2>국제화 프로세스</h2><p>국제화 조직 또는 담당자는 국제화 모듈만 개발하는 것이 아니고 국제화 프로세스를 잘 정해야 한다. 국제화 초보자에게는 매우 어려운 일이지만 필요한 것이 프로세스다.</p><p>예를 들어 문자열을 번역하기 위해서는 여러 단계가 필요하다.</p><div><ul><li>소스코드에 국제화 문자열 함수를 작성한다.</li><li>문자열을 추출한다.</li><li>추출한 문자열을 각 언어로 번역한다.</li><li>소프트웨어에 번역된 문자열을 적용한다.</li><li>검수를 한다.</li></ul><p>국제화 프로세스는 최대한 자동화가 되어야 한다.</p><p>국제화가 누락되는 부분을 찾기 위해서는 코드 리뷰 절차에 국제화 관련 부분이 추가 되어야 한다.</p><p>그리고 테스트 프로세스에서도 국제화 부분이 추가되어야 한다.</p></div></div><h2>결론</h2><p>우리나라에는 수많은 회사가 소프트웨어 국제화에 실패한 역사가 있다. 초기에 소프트웨어 인코딩 결정의 실수로 대규모 서비스가 글로벌 서비스에 실패하기도 한다.&nbsp;</p><p>소프트웨어 국제화의 실패로 좌초된 경우조차 그 원인을 국제화에서 찾지 못하는 경우가 대부분이다. 그래서 매우 중요하지만 아주 소홀히 하는 분야이기도 하다.</p><p>국제화는 결코 소홀히 하면 안되고, 소프트웨어 개발 초기부터 심각하게 고민하지 않으면 안된다.</p>

</div></div>

All of Software

소프트웨어를 이미 개발해 놓고 비즈니스가 잘되면 나중에 국제화를 적용하려고 하면 늦다는 것을 이전 글에서 살펴 보았다.
소프트웨어를 기획할 때부터 향후 1%라도 국제화 가능성이 있다면 계획에 따라서 적절한 국제화 기술을 미리 적용하는 것이 좋다. 
그럼 어떠한 경우 국제화가 필요한가?
국내 외에 해외에 소프트웨어를 판매하거나 서비스할 수 있다.
국내에서만 판매할 계획이지만, 국내의 외국인 고객이 사용할 수 있다.
그럼 소프트웨어 국제화가 필요한 경우 어떠한 국제화 전략을 어떻게 수립해야 하는지 알아보자.
국제화 적용 수준을 결정한다.
당장은 아니고 미래에 해외에 팔 계획이 있는 소프트웨어라면 초기부터 국제화 기능을 모두 적용하면 기간, 비용이 많이 든다. 이러다가 해외 판매 계획을 취소하면 국제화 투자 비용은 매몰 비용이 된다. 
따라서 판매 계획에 따라서 국제화 적용 정도를 달리하는 것이 좋다.
소프트웨어에 국제화 기능을 구현하기 위해서는 크게 2가지 모듈이 필요하다.
국제화 모듈 (i18n module or library)
지역화 모듈 (L10n module or library)
국제화 모듈은 국제화 아키텍처 전체를 다루는 모듈이고, 지역화 모듈은 하나의 국가 또는 언어 기능을 지원하는 모듈이다. (아래 그림 참조)
당장 해외 판매 계획이 있다면 위 그림 처럼 여러 지역화 모듈을 모두 만들어야 하지만, 당장은 국내에서만 판매를 하고 추후에 해외에 판매를 하려면 아래와 같이 필요한 국제화 기능만 개발을 하면 된다.
이렇게 개발을 하면 한국어 전용으로 개발하는 것보다 1~2%의 개발 비용이 더 들지만, 나중에 국제화 기능을 새로 추가하는 것보다는 10배 이상 비용을 절약할 수 있다.
국제화를 적용할 범위 결정
국제화는 매우 광범위하다.
아래는 국제화 시 고려해야할 49가지라는 지난 글이다.
https://www.allofsoftware.net/2012/09/49.html
물론 이 모두를 적용할 필요는 없다. 내용을 읽어보고 현실적으로 우리 소프트웨어에 적용해야 할 범위를 결정한다. 국제화에 대한 지식, 경험이 없다면 무엇이 필요한지 결정이 어려울 수가 있으므로 국제화 전문가나 경험자의 도움을 받는 것이 좋다.
보통 필수적으로는 아래와 같은 것들을 적용한다.
문자열 (번역)
날짜/시간
숫자
쓰기 방향 (좌우, 우좌)
대소문자
문자 정렬
시스템적으로 필수적으로 결정해야 할 기술적인 요소는 다음과 같다.
문자 인코딩 방법 및 변환
Database, File, Network communication 시 사용할 문자 Encoding
지금은 UTF-8이 대세지만 아닌 경우도 있어서 주의해야 한다.
국제화에 유리한 UI 배치
타임존 처리
선택적으로는 소프트웨어의 종류나 특성에 따라서 추가 결정을 한다. 
폰트의 종류와 크기
화폐 단위
주소
전화번호
이름 표기
아이콘
처음에는 어려운 일이지만, 국제화 모듈을 한번 잘 만들어 놓으면 회사의 여러 소프트웨어에 재사용이 가능하다. 
국제화 조직 구성
큰 소프트웨어 조직은 국제화 팀이 별도로 있지만, 작은 조직은 별도의 팀을 갖추기가 어렵다. 그렇다면 일반 SW팀에 국제화 담당자를 별도로 지정하여 국제화 아키텍처를 설계하고, 국제화, 지역화 모듈을 개발하게 하면 된다.
모든 개발자가 국제화 기술을 다 알 필요는 없다. 국제화 담당자가 잘 만들어 놓은 기능을 그냥 써서 개발을 하면 된다.
시간을 표시하는 함수 하나도 그냥 쓰지말고 또는 본인이 직접 국제화를 적용하지 말고 국제화 담당자가 잘 만들어 놓은 국제화 시간 함수를 사용하면 되는 것이다.
국제화 담당자도 개발 초기 부터 국제화 모듈을 모두 완성해 놓을 필요는 없다. 그렇게 한다면 국제화 담당자가 국제화 모듈을 완성할 때까지 일반 개발자들은 개발을 시작할 필요가 없다.
국제화 담당자는 국제화 범위를 정하고 Interface만 정해 놓으면 된다. 즉 국제화 모듈의 Interface만 정하고 지역화 모듈은 제대로 개발할 필요가 없다.
시간 함수를 예로 들면 시간 함수의 Interface를 잘 정하고 나면 그 내용은 그냥 시간을 출력하는 함수를 최대한 간단히 구현해 놓으면 되고, 국가별 언어별로 다른 표시법은 적용할 필요가 없다.
이렇게 인터페이스를 만드는 데는 며칠 걸리지 않는다.
나중에 개발을 진행하면서 지역화 모듈의 내용을 하나씩 채워가면 지연 없이 개발이 진행된다.
국제화 마인드
국제화가 잘 된 소프트웨어를 개발하는 것은 매우 어렵다. 경험이 적으면 국제화가 누락된 소프트웨어를 개발하기 쉽다.
예를 들어보자.
사용자가 입력한 문자열을 단어별로 쪼개서 처리하려고 한다. 그래서 띄어쓰기로 token을 구분하여 처리를 했다고 하자. 하지만 띄어쓰기를 사용하지 않는 언어는 의외로 많다. 이런 곳에서는 이 기능은 제대로 동작하지 않을 것이다. 이처럼 예상치 못하게 국가별 언어별로 다른 것들이 꽤 많다.  다음과 같은 것들이 있다.
띄어쓰기
단수, 복수 처리
좌우 쓰기 방향
문장 순서
달력
이외에 매우 많다. 어떤 것은 해당 국가에서 이상하게 보여도 나름 용인이 되는 것도 있고, 용인이 되지 않는 것도 있고, 명백히 버그가 되는 것도 많다.
예를 들어 숫자의 소숫점은 국가별로 다르다. 숫자의 소숫점을 잘못 처리하면 명백한 버그가 되고 큰 사고가 될 수도 있다.
그래서 우리가 이러니 전세계 모든 국가에서도 이럴 것이라면 생각을 버려야 한다. 어려운 일이다. 그래서 국제화 전문가가 회사에 적어도 한명은 있으면 좋다. 그렇지 않으면 국제화 전문가의 컨설팅을 받으면 적은 비용으로 큰 문제를 해결할 수 있다.
국제화 프로세스
국제화 조직 또는 담당자는 국제화 모듈만 개발하는 것이 아니고 국제화 프로세스를 잘 정해야 한다. 국제화 초보자에게는 매우 어려운 일이지만 필요한 것이 프로세스다.
예를 들어 문자열을 번역하기 위해서는 여러 단계가 필요하다.
소스코드에 국제화 문자열 함수를 작성한다.
문자열을 추출한다.
추출한 문자열을 각 언어로 번역한다.
소프트웨어에 번역된 문자열을 적용한다.
검수를 한다.
국제화 프로세스는  최대한 자동화가 되어야 한다.
국제화가 누락되는 부분을 찾기 위해서는 코드 리뷰 절차에 국제화 관련 부분이 추가 되어야 한다.
그리고 테스트 프로세스에서도 국제화 부분이 추가되어야 한다.
결론
우리나라에는 수많은 회사가 소프트웨어 국제화에 실패한 역사가 있다. 초기에 소프트웨어 인코딩 결정의 실수로 대규모 서비스가 글로벌 서비스에 실패하기도 한다. 
소프트웨어 국제화의 실패로 좌초된 경우조차 그 원인을 국제화에서 찾지 못하는 경우가 대부분이다. 그래서 매우 중요하지만 아주 소홀히 하는 분야이기도 하다.
국제화는 결코 소홀히 하면 안되고, 소프트웨어 개발 초기부터 심각하게 고민하지 않으면 안된다.

소프트웨어 국제화 전략 (25)

댓글