Junare's Blog

인공지능의 발전에 대한 경계

Junare — Fri, 7 Oct 2016 17:22:09 +0900

https://coolspeed.wordpress.com/2016/01/03/the_ai_revolution_1_korean/

Google AdSense 실적보고서 용어

Junare — Mon, 21 Mar 2016 10:49:27 +0900

Google AdSense를 통해 광고 게재 시 실적보고서에 등장하는 용어들을 정리한다.
원본은 다른 개인 블로그인 http://thinkpro.tistory.com/82 이며, 표현만 살짝 바꾸는 수준으로 변형하여 올린다.

페이지 뷰 (Page View)

사용자가 Google 광고가 게시된 페이지를 조회한 횟수.
페이지에 등록되어 있는 구글 광고의 개수와는 상관없이 그 페이지를 한 번 조회할 때마다 페이지 뷰 값이 1씩 증가한다.
한 명의 사용자가 페이지를 여러 번 호출할 수 있으므로 페이지 뷰가 방문자의 수(UV : Unique Visitor)를 의미하는 것은 아니다.

클릭 수 (Click Count)

광고를 클릭한 횟수.
사용자가 Google 광고를 클릭할 때마다 클릭 수가 1씩 증가한다.

페이지 CTR (Page Click-Through Rate)

페이지 뷰 대비 광고 클릭율.

CTR = 클릭 수 / 광고 노출 수 (페이지 뷰)

예를 들어, 100번의 광고 노출 중 단 한번의 광고 클릭이 있었다면 페이지 CTR은 1%가 된다.

CPC (Cost Per Click)

클릭당 광고 단가.
배치된 광고(들)의 광고비용에 따라 CPC가 달라지며, 이는 한 광고에 대한 CPC는 광고주와 구글간 계약을 통해 결정된다.

CPC가 100원이고 100번의 클릭이 있는 경우, 10,000원의 광고비용을 지불 받는다.

CPC와 동일한 의미로 PPC(Pay Per Click)가 쓰이기도 한다.

페이지 RPM (Revenue Per Mile)

페이지 노출당 수익.
페이지 RPM은 일반적으로 1,000회의 페이지 노출 시 발생하는 수익을 의미한다.
RPM은 CTR과 CPC를 통해 계산되는 것이으로 이 값 자체가 새로운 의미를 가지지는 않는다. 다만, 사용자 트래픽 지표 중 대표 지표인 MCU(Maximum Current User)와 같이, 다른 어려운 지표와 계산을 모두 생략하고도 거의 최종적인 예상수입을 직관적으로 보여준다.

예상 수입

예상 수입(페이지 뷰) = 페이지 RPM x 페이지 뷰 / 1,000
예상 수입(광고 클릭) = 페이지 뷰 x 페이지 CTR x CPC

별 기행 - 양평 벗고개

Junare — Sat, 9 Jan 2016 11:40:01 +0900

2016년 목표 중에 하나가 '멋진 은하수 보고 사진도 찍기'다.

2016년 1월 8일 금요일 저녁.
겨울이라 은하수를 볼 수는 없지만, 별도 보고 싶고 밤하늘을 찍는 연습도 할 겸 '양평 벗고개'를 찾았다. 집에서 차로 1시간 10여분 거리. 별을 보기 위해 평일 일을 마치고 양평까지 다녀온다는 다소 거친 일정이었지만, 다행이 많은 별을 볼 수 있어 굉장히 만족스러웠다.

올해는 자주 별 보러 다니고, 은하수도 꼭 봐야지.

P.S. - 다음에는 ISO를 800 정도로 높이고 셔터를 15초 언더로 잡아 찍어보는게 좋을 것 같기도...

은희경 소설과 아델 음반

Junare — Sat, 12 Dec 2015 15:01:21 +0900

소중한 분의 추천으로 은희경 소설집을 처음으로 구매했다.

'행복한 사람은 시계를 보지 않는다'
군대 말년부터 제대한 이후 잠깐 접했던 양귀자, 공지영의 소설 이후 한국 여성 문학은 처음인 듯 하다. 어떤 내용이고 어떤 생각을 줄지 궁금하다. 빨리 읽어 봐야지.

알라딘에 책을 주문하면서 최근 발매된 아델의 '25' 음반도 주문했다.

멜론과 같은 음원 스트리밍 서비스에서도 아델의 신보는 정액 요금제과 별도로 개별 구매하도록 되어 있어 결국 CD 구매를 택했다. '25' 음반을 사면서 기존 1, 2집인 '19', '21' 음반도 같이 구매.
얼마전까지만 해도 CD나 책과 같은 아날로그 미디어는 최대한 보관하지 않는 정책이었는데, 누구의 영향을 많이 받는 듯...

오늘은 아델 신보를 들으면서 기분을 달래야겠다.

알라딘에서 하는 연말 행사로 5만원 이상 주문결제를 했더니, 2016년 다이어리도 주더라.

경험상 효과적으로 쓸 것 같지는 않지만, 새 다이어리가 생기니 기분은 좋다.
부디 2016년에는 좋지 않은 일 보다 좋은 일이 더 많이 생기길...

[iOS] ipa 파일 배포 방법

Junare — Wed, 25 Nov 2015 17:31:21 +0900

iOS APP의 기본 패키지 파일 포맷인 ipa 파일을 빌드하여, 다수의 기기에 배포하는 몇가지 방법에 대해 서술한다.

1. USB 연결을 통해 Xcode에서 빌드하여 설치

• 가장 기본적인 ipa 설치 방법

• ipa를 빌드한 기기에 직접 모바일 기기를 연결하여 설치하는 방법

• 개발자가 빌드한 내용을 기기에서 테스트할 때 적합한 방법

2. USB 연결을 통해 iPhone Configuration Utility를 이용해 설치

• Beta Builder

• 역시 ipa를 빌드한 기기에 직접 모바일 기기를 연결하여 설치하는 방법

• 본 방법에 대한 자세한 내용은 추가적 확인이 필요

3. ADHOC 배포

• 등록된 기기에서 앱의 버전 및 스토어 등록 여부와 관계없이 ipa 파일만 있으면 itunes를 통해 설치, 테스트 가능

• ADHOC 배포 방법으로 빌드된 ipa 파일이어야 한다.

• ADHOC 배포 방법으로 빌드는 xcode enterprise 버전에서 가능

• 테스트 기기는 ADHOC 버전 빌드에 사용된 프로파일에 등록된 기기이어야 하며, 프로파일에 등록 가능한 기기의 최대 개수는 100개

• ADHOC 형태로 배포된 ipa 파일은 itunes를 통해 설치

3. TestFlight를 통한 배포

• TestFlight에 Test로 사용할 itunes 계정을 등록

• 온라인으로 ipa 파일을 기기로 다운로드 받아 설치하는 방법

• 등록된 계정으로 정식 배포 전 테스트 가능 (심의 등록 후 심의 기간에도 테스트 가능)

• FGT 또는 클베용으로 만들어진 기능이나 확장 활용이 가능

권한과 책임

Junare — Fri, 20 Nov 2015 12:17:22 +0900

'S4리그' 프로젝트를 맡고 있을 때의 몇 년도 더 된 일이다.

한국과 유럽, 두 개의 권역 서비스를 진행하고 있는 상황에서 유저 DB의 구조를 변경해야 할 일이 생겼다. 개발 입장에서는 향후 개발의 확장성을 고려했을 때 꼭 필요한 일이었지만, 서비스 관점에서는 여간 위험한 일이 아닐 수 없었다. 자칫 문제가 생기면 서비스를 중단해야 하는 상황이 생길 수도 있기 때문이다. 게다가 유럽은 S4리그 프로젝트를 유지하게 만들어준 시장이었기에 더더욱 서비스적으로 중요한 시점이었다.

당연히 사업 PM은 DB 구조 변경에 대해 반대를 했었고, 한동안 이 안을 두고 사업팀과 개발팀이 옥신각신했다. 어쨌든 해당 작업은 개발과 사업의 영역에서 개발쪽에 해당 하는 것이라 결국에는 사업 PM이 울며 겨자먹기로 동의할 수 밖에 없었다.

사업 PM은 전화 통화로 동의의 뜻을 전했고, 그 끝에 이런 말을 했다.

"다만 매우 중요한 사안이니, 만약 문제가 생기면 PD님이 책임을 지셔야 합니다."

실무자 간에 처음으로 '책임'이라는 단어를 들은데다가 저 단어 특성 상 문맥이 민감해질 수 밖에 없기에 당혹스럽기도 하고 어이가 없어 멈칫하고 있었더니, 사업 PM도 말을 너무 강하게 했다고 생각했는지 첨언을 했다.

"아, 오해하지는 마세요. 만약 문제가 생기면 문제 해결을 위해 PD님께서 선봉에 서서 최선을 다해달라는 의미입니다."

멋진 말이다. 나는 이날 이후 '책임'을 저렇게 정의내리고 있다.
단순히 옷을 벗거나 관련자들에게 평가 절하되는 그런 명예의 실추가 책임이 아니라, 잘못된 것을 바로 잡기 위해 그 누구보다 고민하고 노력하는 것이 바로 책임이다.

조직 생활을 하다 보면 책임의 정의를 잘못 내리는 경우가 많다.
내가 결정을 했으니 잘못되어도 내가 욕을 먹지 않겠냐는 경우, 내가 만든 회사라 망했을 때 누구보다 손해를 입으니 그게 곧 책임이지 않겠냐는 경우도 그렇다. 일이 잘못되면 자기가 옷을 벗겠다고 하는 경우는 말할 필요도 없다.

책임이라는 것이 누가 지겠다고 명시한다고 되는 것이 아니다.
어떠한 문제 해결을 위해 정신적, 육체적 기여를 하고 있다면 그 사람들은 모두 책임을 지고 있는 것이다.
그 기준에서 어떤 사람들이 같이 책임을 지게 되고, 그 중에 누가 가장 큰 책임을 지게 될 것인지를 잘 판단해야 한다.

그렇게 판단된 책임을 기준으로 권한을 부여하고 권한이행을 인정하는 것이 바로 이상적이고 효율적인 R&R (Role & Responsibility)일 것이다.

[NSIS] 언어선택창에 설정한 언어가 표시되지 않을 때

Junare — Thu, 11 Sep 2014 14:03:05 +0900

MUI_LANGDLL_DISPLAY를 통해 언어 선택창을 노출 시킬 수 있는데, 이 언어 선택창에 나타나는 언어 리스트는 MUI_LANGUAGE를 통해 지정한다.

문제는 MUI_LANGUAGE로 복수의 언어를 지정하더라도, 인스톨러가 실행되는 로컬 PC의 언어 환경에 따라 지정한 일부 언어가 노출되지 않을 수 있다.
NSIS v2.26 이후 기본적으로 OS가 지원하지 않는 언어는 언어 선택창에서 노출을 하지 않기 때문이다.

예를 들어, Spanish나 Japanese의 경우 한국어 OS에서는 노출되지 않는다.
게다가 언어를 두 개를 지정했는데, 둘 중 하나가 지원하지 않는 언어일 경우 언어 선택창 자체를 노출시키지 않는다.

OS가 지원하지 않는 언어는 당연히 보여주지 않는 것이 사용자 입장에서도 편리하지만, 꼭 보여주고자 할 경우에는 MUI_LANGDLL_ALLLANGUAGES를 통해 모든 언어를 표시해줄 수 있다.

!define MUI_LANGDLL_ALLLANGUAGES

아래와 같이 MUI_LANGUAGE 매크로를 사용하기에 앞서 MUI_LANGDLL_ALLLANGUAGES를 선언하면, MUI_LANGUAGE를 통해 등록한 모든 언어가 언어 선택창에 노출된다.

< 참고 >
http://nsis.sourceforge.net/Why_does_the_language_selection_dialog_hide_some_languages

아이의 이름은 누가 지어야 하나?

Junare — Wed, 13 Feb 2013 22:36:01 +0900

이틀 후, 그보다 정확히는 36시간 후 둘째가 태어난다.

첫째가 태어났을 무렵에 아이의 이름을 짓는 것 때문에 굉장히 짜증이 났었는데, 이번에도 여지 없이 똑같은 갈등이 생겼다. 나는 아이 이름은 부모가 지어야 한다고 생각하는 반면에 사람 이름은 신중히 지어야 하니 성명학에 기초하여 작명소(철학관)에서 지어야 한다는 집안 어르신들의 의견 차이에서 오는 갈등이다.

왜 내가 낳은 아이의 이름을 작명소에 맡겨야 하는 것일까?

성명학에 대해서 잘은 모르지만, 흔히 작명소에서 내세우는 주장은 "이름은 그 사람의 인생을 바꿀 수 있는 가장 큰 변수이고, 이름을 잘 지어야 그 사람의 인생이 편다."라는 것이다. 작명소에서 이름을 지어야 한다는 주위 어르신들의 주장도 이와 일맥상통한다.
행여 이에 반대 입장을 펴면, 이름 잘못 지어서 아이가 불운해지면 어떻게 할거냐고 되묻는다.

이에 대해 나는 두 가지 질문을 던진다.

먼저, 성명학에 기초하여 이름이 붙여진 사람은 100% 행복한 삶을 사는가?
누구도 이에 그렇다고 답을 할 수 없을 것이다. 심지어 돈을 받고 이름을 지어주는 작명소에서도...
"당신 작명소에서 이름을 지어준 수천명의 사람들이 모두 행복하게 살고 있습니까?"

첫 번 째 질문의 답을 기초로 한 두 번 째 질문은,
그럼, 행복하지 못한 삶을 사는 사람에 대해 그 책임을 작명소에서 지는가?
삶에 대한 가장 큰 책임은 본인에게 있는 것이고, 본인 외에 책임이 따르는 타인은 바로 부모다.
그 사람의 인생에 대해 작명소는 아무런 책임을 지지 않는다.

그럼, 잘되면 성명학 때문이고 못되면 부모탓이네?

내가 씨를 뿌렸고, 나의 아내가 씨를 받았고, 아내가 열달 동안 고생하고, 극심한 아내의 산고를 통해 아이를 세상에 낳았다. 아이가 성인이 되기까지 잘 자랄 수 있도록 돌봐주고 혼신을 다하는 것도 우리 둘인 부모다. 아이가 독립할 수 있을 때까지 부모가 책임을 다한다.

권한에는 책임이 따르듯 책임이 있으면 권한도 있어야 한다.
아이의 이름에 대한 권한은 부모가 아이에게 가지는 거의 유일한 권한이다.
어째서, 책임은 부모에게 지우면서 권한은 성명학이 가져간단 말인가?
심지어 부모가 가져야 하는 그 권한도, 아이가 성장하여 자기 이름을 마음에 들어했을 때라는 조건이 붙는데도 말이다. (이름에 대한 가장 큰 권한은 이름을 가진 당사자에게 있어야겠지.)

얄팍한 돈벌이에 지나지 않는 성명학에 의존하는 사람들이 안타깝다.
더욱 안타까운 것은 이런 논리로 설득이 안되는 사람들과, 설득시키지 못하는 나 스스로이다.

더 논의를 해봐야겠지만 결코 성명학을 통해 이름을 지어야겠다고 한다면,
적어도 이 말은 할 작정이다.

"나중에 일이 생겼을 때 그 책임은 이름을 지은 작명소에 물으시고, 그게 안되면 작명소를 선택한 분에게 물으시고, 그것도 안되면 받아온 이름 중에 선택을 한 사람에게 물으세요. 저는 아이가 잘 성장할 수 있도록 최선을 다하겠지만 잘못에 대한 책임은 안지겠습니다."

로컬라이징의 레벨 (1)

Junare — Sat, 5 Nov 2005 19:00:01 +0900

"어느 수위만큼 로컬라이징을 할 것인가?"

음... 체력을 가다듬고... [?!] 슬슬 로컬라이징시에 고려해야 할 요소에 대해 하나하나 정리를 해보도록 하겠습니다.

지난 포스팅에 제가 제시한 그 요소들은 아래와 같습니다.

1. 로컬라이징 레벨 - 어느 수위만큼 로컬라이징을 할 것인가?
2. 로컬라이징 컨텐츠 - 어떤 것들을 로컬라이징할 수 있게 할 것인가?
3. 스크립트의 구조 - 스크립트가 로컬 작업에 용이한가?
4. 해외 계약에 따른 업데이트 계획 - 어떠한 내용들을 단계적으로 업데이트 할 것인가?
5. 패치 프로세스 및 버전의 형식 - 버전 관리를 어떻게 할 것인가?
6. 이벤트 시스템 - 어떠한 이벤트를 지원해줄 수 있는가?
7. 툴의 준비 및 관리 - 해외에서 관련 툴의 사용이 얼마나 용이한가?
8. 시놉시스, 캐릭터 등에 대한 자료 - 서비스를 위해 필요한 정보들이 얼마나 준비되어 있는가?

이 중에서 오늘은 '1. 로컬라이징 레벨'에 대해서 이야기를 해보도록 하지요.

1. 로컬라이징 레벨

'로컬라이징 레벨'이라고 함은 쉽게 이야기 해서 '어디까지 로컬라이징이 가능토록 할 것이냐?' 라는 것입니다. 예전의 패키지 게임처럼 단순히 텍스트 스크립트와 이미지에서 글자 부분만을 번역하는 단계에 그칠 것인지, 아니면 서비스 되는 국가에 어울리는 아이템, 캐릭터, 배경 오브젝트들을 넣을 것인지, 또는 그것을 훨씬 넘어서 코어한 밸런스 부분까지 로컬라이징이 가능토록 할 것인지를 말하는 것이죠. 그렇다면 로컬라이징 레벨을 어떻게 나눌 수 있고, 나눠진 레벨별로 어떠한 준비가 필요한지를 알아야할 것입니다.

저는 이러한 로컬라이징 레벨을 다섯 개의 레벨로 나누어 구분하고자 합니다.

1단계 - [Translation]
게임에 사용되는 스크립트와 이미지의 로컬라이징

2단계 - [Localized Contents]
NPC, 아이템, 코스튬, 작은 배경 오브젝트 등의 로컬라이징(새로운 것의 추가가 아닌 응용 및 수정의 수준)

3단계 - [Localized Source]
순수하게 해외 용으로 작업된 NPC, 아이템, 캐릭터 등의 추가

4단계 - [Localized World]
존, 맵, 서킷 등과 같은 월드 단위의 로컬라이징

5단계 - [Localized Balance]
게임의 핵심적인 밸런스의 로컬라이징

1단계 - [Translation]
단순히 게임에 사용되는 스크립트와 이미지의 번역만을 처리하는 수준의 로컬라이징입니다. 패키지 게임이야 이 단계가 로컬라이징의 시작이요 끝이 될 수도 있겠지만, 온라인 게임에서는 '우리 게임도 로컬라이징을 했다' 라는 의미 그 이상도 그 이하도 아닐 것입니다. 제가 '단순히'라는 표현을 사용했지만, 사실 1단계의 로컬라이징을 하기 위해서도 상당히 많은 고려와 준비가 필요합니다.

우선 스크립트의 경우, 개발자, 관리자, 번역자. 이 세 명의 구미에 맞도록 구조가 잘 짜여져 있어야 합니다. 세 명 모두의 구미를 맞춘다는건 아래와 같은 내용을 의미합니다.

(로컬라이징을 위해 스크립트는..)
1. 개발자가 스크립트 작성에 불편이 없어야 한다.
2. 중간 관리자는 버전 및 여러 종류의 스크립트를 관리함에 있어 불편함이 없어야 한다.
3. 번역자가 번역을 할 때 용이하게 작업할 수 있어야 한다.

모두를 만족시키는 그런 완벽한 솔루션은 아마도 존재하지 않을 것입니다.
그러나, 완벽하지 못한 여러 대안 중에서 최상의 대안을 찾을 수 있도록 노력하고 또 찾아야 한다는 것이지요.

로컬라이징을 위한 스크립트 솔루션은 게임의 장르, 게임의 성격, 관리 시스템에 따라 달라질 것입니다. 게다가 스크립트 솔루션은 현재 사용하고 있고 논의되고 있는 것만해도 방대하리만큼 다양하니 이에 대해서는 별도의 시간을 할애해서 따로 다루도록 하겠습니다.

이미지의 경우 로컬라이징을 대비해서 어떠한 준비가 필요할까요?

우선 첫번째 문제로, 이미지 번역을 위해 자료를 준비하는 그래퍼 또는 중간 관리자가 흔히 하는 실수인 "작업에 사용된 작업파일을 그대로 해외에 전달한다."는 것입니다.
이미지 편집툴의 대명사인 "PhotoShop" 포맷인 PSD 파일을 기준으로 이야기를 해보겠습니다. 하나의 이미지 스프라이트를 만들기 위해서는 다수의 이펙트와 다수의 레이어를 사용하게 됩니다. 전체 화면에 사용되는 이미지의 경우 많게는 수십개의 레이어와 이펙트를 사용하기도 하지요. 그런데 이렇게 많은 이펙트와 레이어가 작업 파일에 그대로 남아 있는채로 해외에 넘어가게 되면, 해외에서 작업하는 작업자는 작업파일에 사용된 모든 레이어들이 어떻게 사용되고 있는지 파악하기 위해 많은 시간을 낭비하게 됩니다. 그리고 더욱 심각한 문제는 이로 인해 한국에서 작업한 그래퍼가 게임의 느낌을 위해 의도적으로 처리한 효과를 해외에서 임의로 변경해버릴 수 있는 여지가 있다는 것이죠.

두번째 문제는, 이미지에 사용된 텍스트에 대한 영문식 표현이나 설명이 없어 오번역의 여지가 크다는 것입니다. (물론 이 문제는 스크립트의 번역에서 더 많이 발생할 것입니다.)

세번째 문제는 때로 대중적이지 않은 포맷으로 저장해야 하는 이미지 파일이 가이드의 부족으로 인해 결과물이 오작업되어 넘어오는 경우가 많이 발생한다는 것입니다. 'DDS' 파일을 예로 들어보겠습니다. 개발사에서는 DXT3 ARGB 포맷으로 MIP maps 정보가 없는 DDS 파일을 사용한다고 가정할 때, 정보의 부족으로 인해 해외에서는 MIP maps 정보를 포함한 DDS로 작업을 하거나, 아예 포맷을 다른 포맷으로 저장해 오는 경우가 빈번하게 발생하게 됩니다. 이렇게 되면, 작업된 것을 다시 돌려보내 설명 후 재작업을 시키거나, 개발사에서 직접 제대로 된 포맷으로 다시 저장해야 하는 불필요한 작업을 감수하게 되죠.

위의 사례들을 비추어봤을 때, 효율적인 이미지의 로컬라이징 작업을 위해서는 적어도 다음 세가지가 준비되어야 할 것입니다.

(이미지의 로컬라이징을 위해...)
1. 번역에 용이한 간단한 구조의 작업 파일 (Only Background Layer + Text Layer) 로 저장되어야 한다.
2. 정확한 의미 전달을 위해 이미지에 사용된 텍스트의 영문 정보가 포함되어야 한다.
3. 작업 및 파일 저장에 필요한 가이드를 함께 제시해야 한다.

1단계의 로컬라이징을 위해 필요한 내용들을 나열했지만, 말처럼 쉽게 준비할 수 있는 것들은 아닐것입니다. 하지만 이러한 것들을 준비하지 않으면, 여러가지 자잘한 문제들이 개발자의 발목을 잡게 된다는 것은 자명한 사실입니다.

2단계 - [Localized Contents]
해외 현지 사정에 어울리는 NPC, 아이템, 코스튬, 작은 배경 오브젝트 등을 게임에 추가할 수 있는 단계로, 로컬라이징 작업이 해외에서 이루어져 국내 개발사에 전해지는 방식이 아니라, 해외의 요청 또는 자사의 필요로 인해 국내에서 처리하는 방식으로 작업되는 단계입니다. 사실, 이 단계부터 의미있는 로컬라이징이 시작된다고 할 수 있습니다.

이 단계의 로컬라이징을 시행할 때에는 일반적으로 통합 관리를 하는 것이 바람직합니다. 여기서 통합 관리라는 것은 어느 국가의 클라이언트든 간에 모든 리소스를 넣어두고, 해당 국가의 클라이언트 별로 필요한 파일들만을 선택적으로 사용하게 하는 것을 의미합니다. 국가별로 서로 다른 파일 구조를 가진 클라이언트와 서버를 따로 관리를 하게되면, 관리가 상당히 까다로워질 뿐더러 리소스 및 코드 소스의 유지 보수 측면에서도 어려움이 많기 때문입니다.

그렇다면, 이러한 통합 관리를 통한 지원이 용이하게 하기 위해서는 간단한 파일의 변경과 관련 내용(스크립트 따위)의 수정만으로 오브젝트를 변경할 수 있도록 만들어야 합니다. 복잡한 절차로 인해 그래퍼나 프로그래머를 귀찮게할 필요없이, 비전문가인 로컬라이징 담당자의 손쉬운 작업을 통해 이루질 수 있도록 해야 합니다. 예를 들어 동일한 NPC가 제공하는 특정 아이템이 미국과 중국이 서로 다른 아이템으로 하고 싶을 때, 코드 소스나 그래픽 리소스를 수정, 재빌드할 필요없이 간단한 스크립트의 수정과 같은 방법으로 쉽게 해결할 수 있어야 한다는 것입니다.

둘째, 이 단계의 경우 1단계와 동일하게 해외에서 요청할 때, 전혀 엉뚱한 내용이 요청되지 않도록 규정을 정리하여 해외에 제시, 이해시켜야 합니다. 그렇지 않으면, 당치도 않는 요청으로 인해 시간와 인력을 불필요하게 소모할 수 있기 때문이죠. (해외에 왜 안되는지를 설명하고 논쟁하는 건 생각보다 힘들고 짜증나는 일입니다.) 그리고, 필요한 자료를 전달 받아 가공하고 작업에 적용할 수 있을 때까지의 시간을 절약하기 위해, 자료의 폼에 대해서도 명확히 규정하고 이를 해외에서 지킬 수 있도록 유도해야합니다. 이 역시 불필요하게 낭비되는 시간과 인력을 절약할 수 있지요.

마지막으로, 이러한 통합관리에서는 체계적인 파일 관리가 필수적입니다. 동일한 파일명을 사용하지만 내용이 틀린 파일들은 국가별로 혼용되지 않도록 주의해야하며, 그 외 특정 파일들은 국가별로 서로 다른 이름을 가지게 하여 파일명 만으로 어떤 내용의 어떤 국가에 적용되는 파일인지 유추하고 적용할 수 있도록 해야합니다. 예를 들어, 해외 이벤트에만 사용되는 이미지 스프라이트를 모아논 이미지 파일이라던가, 한국과 동일한 오브젝트 파일인데, 텍스쳐를 로컬라이징할 경우 등이 이에 해당하겠습니다. 물론, 이렇게 파일명이 다르게 사용되는 파일의 경우 스크립트 등으로 파일명의 변환이 용이하게 이루어지는 경우로 한정해야할 것입니다.
국내 전용과 해외용 또는 더 세분화해서 각 국가별로 파일명을 어떻게 사용할 것인지를 사전에 정해놓는 것은 개발자의 교체시 새로운 개발자가 파일 구조를 빠르게 이해할 수 있도록 해줄 뿐더러, 차후 오랜 시간이 지나서 이루어지는 자료 관리에도 큰 도움이 될 수 있습니다.
또한, 프로그래머나 그래퍼 또는 그 외 부서원 개인이 관리가 필요한 특정 파일의 파일명을 마음 내키는대로 짓게 해서는 안됩니다. 이는 사용되는 파일명이 통일적이지 않게 할 뿐더러 위의 관리 체계를 뒤흔드는 요인이 됩니다. (관리가 필요한 파일에 한해) 파일명을 어떻게 지을지는 기획, 프로그래밍, 로컬라이징 이 3개 부서의 각 담당자들끼리 협의를 통해 지어져야 하며, 차후 체계적인 관리가 이루어져야 할 것입니다.

1. 로컬라이징이 필요한 모든 오브젝트는 필요에 따라 손쉽게 텍스쳐를 바꿀 수 있도록 해야한다.
2. NPC, 아이템, 코스튬, 작은 배경 오브젝트 등 로컬라이징이 이루어지는 컨텐츠의 경우 사전에 파일 구조 및 필요한 자료의 폼에 대해 외에 전달하고 인지시켜 작업의 용이를 꾀한다.
3. 로컬라징이 필요한 파일은 체계적으로 관리할 수 있도록 하며, 기획 단계에서 파일의 네이밍 규정을 명시하여야 한다.

기획단계에서 고려해야 할 로컬라이징의 요소

Junare — Tue, 1 Nov 2005 18:20:01 +0900

직업이 소위 '게임 로컬라이징' 임에도 불구하고, 지금까지 제 블로그에 로컬라이징에 관한 글이 전무한 것에 대해 심히 부끄러움을 느끼는 바입니다. ;ㅁ;

가깝게 개인의 발전과 기록적인 의미에서, 주위 관련 업무를 수행하는 동료간의 의견 교환을 위해서, 멀게는 게임 업계 여러분들이 수행하시는 프로젝트의 성공적인 서비스를 위해서, 앞으로는 게임 로컬라이징에 대한 포스팅을 게을리 하지 않아야겠군요. (~~뭔가 거창하다!~~) 아는게 있어서 포스팅을 한다기 보다는, 여러분과의 논의를 통해 보다 완성적이고 뭔가 클리어한 솔루션이 나오기를 기대하는 바입니다.

우선 이번에는 게임의 기획 단계에서 고려해야할 로컬라이징의 요소에는 무엇이 있고, 각 요소들이 프로젝트의 진행에 어떤 영향을 미치는지에 대해서 이야기를 해보고자 합니다. 글이 두서가 없더라도 너그로운 마음으로 이해해주시고 읽어주시기 바랍니다.

왜 기획단계에서 로컬라이징을 고려해야하는가?

흔히 '게임을 기획할 때에는 로컬라이징을 충분히 고려해야 한다.'라고 누군가가 조언 또는 주장을 하면, 그런 의견을 듣는 사람들은 이러한 말을 하기 일쑤입니다.

"로컬라이징? 그거 뭐, 스크립트랑 게임에 사용되는 이미지만 번역하기 쉽게 해주면 되는거 아냐?"

"에이... 스케줄도 빠듯한데, 그런거 고려하면서 어떻게 만들어?! 그냥, 그때 그때 필요한 기능을 넣어주면 되지."

해외에 서비스 되는 게임 프로젝트를 한 번이라도 이끌거나 수행을 해 본 사람이라면, 위와 같은 생각이 얼마나 잘못된 생각인지를 충분히 짐작하고도 남을 것입니다.

게임업계의 증가와 게임시장의 협소함으로 인해 이미 국내시장에서의 수익은 큰 기대를 하기 힘들고, 이로 인해 많은 게임업계들이 해외시장으로 방향을 돌리고 있는 실정입니다. (물론 개발 중인 게임이 전적으로 국내시장만을 타겟으로 하고 있다면 이야기는 달라지겠지요.) 이로 인해 게임의 개발 및 유지, 업데이트에 큰 영향을 미치는 요인의 많은 부분이 사내 또는 국내에 보다는 해외에 존재하는 것입니다.

퍼블리싱을 맡은 해외에서는 해당 국가에 맞는 요소들을 게임에 접목시키길 원하고, 이에 따라 많은 요청과 클레임을 제공(?)합니다. 이미 계약을 체결하고 서비스를 지원해주는 개발사 입장에서는 이러한 요청이나 클레임을 간과할 수는 없는 노릇이지요. 이런 해외의 요청을 수렴하기 위해, 즉흥적으로 대처를 하다보면 별도의 인력 및 시간이 많이 소비되고, 이는 곧 스케줄의 딜레이를 유발합니다. 게다가 시스템 자체가 지원하지 않는 시스템인데도 불구하고 그러한 요구를 구현해야할 때가 생기기도 합니다. 이로 인해 눈물을 머금고 시스템 자체를 뒤집어 버리는 극악의 상황이 닥치기도 하지요. 이것은 마치 단층만을 생각하고 집을 지었다가, 2-3층으로 증축할 필요를 느껴 지반공사를 위해 건물 자체를 무너뜨리고 다시 짓는 것과 마찬가지인 것입니다.

게다가 이러한 상황은 서비스하는 국가가 많아지면 많아질수록 프로젝트의 진행에 치명적으로 작용하게 됩니다. 프로그래머는 해외 여러 국가의 버그를 수정하고 요청을 처리하느라 업데이트 해야할 컨텐츠 개발에 장애를 겪고, 기획자는 국내 실정과 맞지 않는 해외의 요청을 수렴하거나 진행 중인 기획에 적용하다 보니 게임 프로젝트가 불완전해지거나 산으로 가는 경우가 허다하게 발생하는 것이지요.

이렇듯 프로젝트에 큰 영향을 미치는 해외의 요구를 보다 적은 자원으로 만족시키고, 동시에 해외에 얽매이지 않으면서 자유롭게 프로젝트를 진행하기 위해, 기획 단계에서부터 충분히 로컬라이징을 고려하고 이를 통해 프로젝트를 보다 유동적으로 만들자는데 그 목적이 있는 것입니다.

생각해야할 로컬라이징의 요소에는 어떠한 것들이 있는가?

그렇다면, 기획 단계에서 로컬라이징을 고려한다고 할 때 생각해야할 요소들에는 어떠한 것들이 있을까요? 로컬라이징을 어떠한 방법으로 어디까지 하느냐에 따라 천차만별이겠지만, 그런 많은 요소들을 유사한 것끼리 묶어 정리를 해보면 아래와 같이 구분될 수 있습니다.

간단한 설명을 달아 놓았지만, 각 요소별로 정확히 무엇을 의미하는지 아직 와닿지 않는 것들이 많을 것입니다. 급하게 생각치 마시고 천천히 하나 하나에 대해서 알아보도록 합시다.

오늘은 여기까지만 하고 다음 시간에는 '1. 로컬라이징 레벨' 에 대해서 다루도록 하겠습니다. 뭔가 정리되지 않고 끝나는 분위기이긴 하지만, 필자가 피곤에 지친지라... 쿨럭;