국제화시 고려해야할 49가지

소프트웨어를 국제화해야 하기 위해서는 고려해야할 것이 한두가지가 아니다.
그런데 많은 회사들은 메세지나 번역하면 되는 것으로 안다.
그렇게 쉽게 접근했다가는 해외 진출을 하면 할수록 문제가 커지고 비용이 늘어나서 점점 어려워진다.

국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다.

기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할 수 있는 기본 기술이고
지역화(L10N)은 각 Locale을 지우너하는 것이다.

이 과정에서 고려해야 할 것은 수백가지가 넘는다. 그 중에서 49가지만 알아보자. 만약에 국제화된 소프트웨어를
개발하고 있는 개발자라면 이중에서 몇가지나 알고 있는지 세어보자.
어떤 항목은 그 하나가 엄청나게 큰 것도 있다. 특별하게 순서를 가지고 정리한 것은 아니지만 하나씩 살펴보자.

1~49번까지의 항목들이 제목만 본다고 쉽게 해결할 수 있는 것은 아니다.
하나의 항목을 가지고 10년 넘게 연구하고 개발하고 있는 것도 있을 정도로 크고 복잡한 것도 있다.
제대로 국제화를 적용하고 싶다면 국제화 전문가의 도움을 받는 것도 한 방법이다.
이것을 처음부터 제대로 하지 않고 시행착오를 거쳐서 고객이 버그를 찾을 때마다 하나씩 고쳐주는 것은
끝도 없고 제품의 이미지도 처음부터 추락할 것이다.

확실한 것은 국제화를 스스로 생각해서 직접 개발하면 잘못될 가능성이 99%이다.
대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

국제화 기술이 소프트웨어 해외 진출 필수임을 잊지 말자.

전략기획 실무 - (사업계획서, 기획, 마케팅, 재무, 인맥관리)_ 웹기획, 사이트 분석
2012 년, SERI.org 전략기획실무 포럼에서 야심차게 준비한 '마케팅콘서트'를 3월 14일 부터 새롭게 단장하여 회원님을 찾아갑니다. 기대해 주시구요. '마케팅콘서트'는 SERI.org '전략기획실무' 포럼의 교육세미나, 강연회, 찾아가는 열린 강의 등마케팅을 위한 브랜드입니다.
http://www.seri.org/forum/rss_xml/fr/fr_rss_002929.xml

자바 애플리케이션을 튜닝할때는 먼저 성능튜닝이 필요한지 파악해야 한다.

성능 측정과정은 매우 고되고 언제나 좋은 결과를 얻을 수 있다는 보장도 없기 때문에

목표 성능에 충분하다면 굳이 튜닝을 하지 않는 것이 효율적이다.

"문제는 단 한 곳에 있고 그 하나만 수정하면 된다."

위의 파레토 이론은 성능 튜닝에도 적용된다. 문제가 반드시 하나라는 의미보다는 가장 성능에 영향을 미치는 하나에만 집중해 접근할 필요가 있다는 뜻으로 해석하자. 하나에 집중해서 해결하고 난 다음에 다른 문제 해결을 위해 노력하도록 하자.

무엇을 얻기 위해 무엇을 포기해야 하는지 결정해야 한다.

캐시를 적용해 응답 반응성을 높일 수는 있지만 캐시의 크기가 커지면 풀 GC 시간이 길어질 수 있다.

적은 메모리 사용량을 선택하면 대개 처리 용량이나 응답 반응 시간이 나빠진다.

하나를 선택하면 하나를 포기해야 한다는 것을 염두에 두고 우선순위를 정해 선택하자.

개발문서를 잘 작성하기 위해서는 많은 시간과 경험이 필요한게 사실이다.

하지만 그 전에 기본적으로 문서 작성에 대한 사고체계를 정립하는 과정이 필요하다.

체계적인 규칙없이 생각나는대로 메모하듯 작성된 문서는 내용의 일관성이 떨어지고,

누구도 알아보기 힘들며, 문서의 신뢰성을 의심받을 것이다.

아래의 내용들을 염두에 두고 개발문서를 작성한다면 개인이 참고하기 위해 작성하는 메모 수준에서

벗어나 타인에게 유익한 정보를 제공하는 문서로써의 가치를 충분히 가질 수 있다. 

• 문서 작성 목적을 확실하게 인지한다.
• 주체를 확실하게 거론한다(두 개 이상의 주체는 지양).
• 사실과 의견을 확실히 구분한다.
• 주제는 직설적으로 전달해야 한다(~수도 있다는 추측성 표현은 지양).
• 반드시 필요한 내용만 작성한다.
• 상황에 맞는 올바른 조사를 사용한다.
• 같은 조사의 중복 나열은 지양한다.
• 가급적 쉬운 표현을 쓴다.
• 하나의 문장에는 하나의 논리만 표함시킨다.
• 맞춤법은 문서 신뢰도와 직결됨을 유념한다.
• 독자 눈높이에 맞추도록 노력한다(독자대상 파악이 필수).
• 필요 시 그림이나 표를 삽입해 집중도와 시각화를 동시에 만족시킨다. 

"사람에게는 스토리가 매우 중요한 요소입니다.

그리고, 그 스토리를 전개함에 있어서 양념도 잊지 말아야 합니다.

글쓴이는 글을 읽어나갈 동기를 명확히 부여해주고, 주의를 끌며,

갈등의 고조와 해소와 같은 굴곡과 호기심을 유발할 수 있는 요소들을

곳곳에 심어둬야 합니다. 그리고 무엇보다 독자를 폄하하는 수준이 아닌

독자들이 쉽게 이해할 수 있는 글을 써야 합니다.

또한 독자는 알지 못한다는 전제로 쉽게 쓰며 전문용어를 남발해서는

안 됩니다."

 - 《조엘 온 소프트웨어》의 저자 조엘 스폴스키

게이미피케이션

 : 게임적인 사고와 기법을 활용해 유저를 몰입시키고 문제를 해결하는 과정.

게이미피케이션은 게임외적인 분야에 게임을 활용하려고 시도했던 여러 논의를 하나로 묶어낸다.

기능성게임serious games 과 애드버게이밍advergaming(광고와 게임을 결합하는 것), 게임포체인Games for change(사회 문제를 해결하는 게임)같은

기존 개념을 행동 심리학에 대한 최신 연구와 소셜 게임의 성공을 통해 알아낸 탄탄한 세계관을 합쳐냅니다.

게이미피케이션 사이트 : http://gamificationu.com/

 - 사이트 가입하면 워크북 받을수 있다.(only english)

   http://gamificationu.com/wp-content/uploads/2011/04/Gamification-Master-Class-Exercises-Blank.pdf

게이미피케이션 상급자 코스 동영상 : http://shop.oreilly.com/product/0636920017622.do

Learn

What stage are you with gamification? Choose your stage to find out more.

1. I'm just getting started: What is Gamification & how can it help me?
2. I'm seriously thinking about using gamification but want to know more
3. I have a product, service or idea that I'd like to gamify ASAP
4. I'd like consulting help to gamify my product, service or idea

온톨로지(Ontology)

: 사람들이 세상에 대하여 보고 듣고 느끼고 생각하는 것에 대하여 서로 간의 토론을 통하여 합의를 이룬 바를 개념적이고 컴퓨터에서 다룰 수 있는 형태로 표현한 모델.

 개념의 타입이나 사용상의 제약조건들을 명시적으로 정의한 기술이다.

 일단 합의된 지식을 나타내므로 어느 개인에게 국한되는 것이 아니라 그룹 구성원이 모두 동의하는 개념.

그리고 프로그램이 이해할 수 있어야 하므로 여러 가지 정형화가 존재

온톨로지는 일반성 수준이 낮은 것에서 높은 순으로 아래의 네 가지 구분이 될수 있다. 그리고, 추가적으로

 두 가지 다른 형태를 제시할 수 있다. 

1. 영역 온톨로지(Domain ontology)
   : 전자,의학,기계,디지털 영역과 같이 특정 영역에만 통용되는 지식을 표현한 온톨로지
2. 메타데이터 온톨로지(Metadata ontology)
   : 온라인 정보의 내용을 기술하기 위한 어희를 제공하는 온톨로지를 지칭한다.
3. 일반 온톨로지(Generic or common sense ontology)
   : 시간, 공간, 상태, 사건 등과 같은 사물의 기본적 관념과 개념을 제공하는 세상에 대한 일반 지식을 포함하는 온톨로지이며, 결과적으로 이 형태의 온톨로지는 여러 영역에 공통으로 적용될 수 있다.
   
4. 표현 온톨로지(Representational ontology)
   : 영역 온톨로지처럼 특정영역을 대상으로 하지 않으며, 무엇을 표현해야 하는지 언급하지 않고 표현개체(representational entities)를 제공하는 온톨로지.
   

* 추가적인 두가지 온톨로지는 방법 온톨로지(Method)와 과업 온톨로지(Task)다.

   전자는 특정 문제해결 방법(Problem Solving Method)에 제한된 용어(terms)를 제공하고,

   후자는 특정과업에 제한되는 용어를 제공한다.

시맨틱 웹(Semantic Web)

: 현재의 인터넷과 같은 분산환경에서 리소스(웹 문서, 각종 화일, 서비스 등)에 대한 정보와 자원 사이의 관계-의미 정보(Semanteme)를 기계(컴퓨터)가 처리할 수 있는 온톨로지형태로 표현하고, 이를 자동화된 기계(컴퓨터)가 처리하도록 하는 프레임워크이자 기술이다. 웹의 창시자인 팀 버너스 리가 1998년 제안했고 현재 W3C에 의해 표준화 작업이 진행중이다.

시맨틱 웹의 목표

: 지금과 같이 사람만이 웹에 산재한 정보의 의미를 파악하는 것이 아닌, 자동화된 기계가 해석할 수 있는 일종의 표준 의미정보 교환의 수단 이 되는 것이 시맨틱 웹의 목적이다. 시맨틱 웹의 이상향은, 인터넷에 방대한 양의 온톨로지가 산재하고, 이를 자동으로 해석하여 처리할 수 있는 에이전트 소프트웨어에 사람 또는 에이전트가 질의를 하면, 컴퓨터가 자동으로 분산된 온톨로지를 탐색하고 추론하여 원하는 결과를 돌려주는 것이다.

http://www.foaf-project.org/

FOAF is about your place in the Web, and the Web's place in our world. FOAF is a simple technology that makes it easier to share and use information about people and their activities (eg. photos, calendars, weblogs), to transfer information between Web sites, and to automatically extend, merge and re-use it online.

The Friend of a Friend (FOAF) project is creating a Web of machine-readable pages describing people, the links between them and the things they create and do.

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 

http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.

그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

My IP Address, Whoami (Who am I?) - Your Online Information, Browser Headers, DNS, Whois, ISP

http://www.hashemian.com/whoami/