언어의 지역화란?
프로그래머가 반드시 알아야 하는 것이 언어의 지역화입니다. 한국어를 사용하는 게임을 미국에 출시하려면 NPC의 대사나 퀘스트, 케릭터 이름, 심지어 게임 무비의 대사까지도 영어가 되어야 합니다. 반대로 미국에서 출시한 게임을 한국에 출시하기 위해선 모든 영어를 한국어로 바꾸어야 하죠.

컴퓨터에서 영어(알파벳)를 표현하는 방법
컴퓨터는 숫자 밖에 알지 못합니다. 0~9까지 알기도 함들어서 0과 1밖에 알지 못합니다. 하지만 어떻게 우리 모니터 화면에는 0~9가, ‘ABC..’ ‘abc..’ 등등의 알파벳들이 떡하니 있는 걸까요? 다음과 같이 0,1로 된 숫자 세트를 문자와 연결시키면 되겠죠.
0000 = 0
0001 = 1
0010 = 2
0011 = 3

그 뿐만 아니라 다음과 같이 연결할 수도 있습니다.
0000 = a
0001 = b
0010 = c
0011 = d


그래서 0000을 보여주라고 하면 1번 방식의 컴퓨터에서는 0를 보여주고 2번 방식에서는 a를 보여줍니다. 여기서 문제가 발생하겠네요. 1번 방식의 컴퓨터에서 텍스트 파일에 “123”을 저장해 2번 방식의 컴퓨터에게 준다면, 텍스트 파일을 여는 순간 “123”이 아닌 “bcd”가 보이겠죠? 이건 아주 중요한 문제입니다. 전 “안녕?” 이라고 보냈는데 상대방은 “꺼져!”로 받을 수 있으니까요. 그래서 Standard라는 것이 생겨나 “모두 이런 방식으로 숫자와 문자를 연결해 주세요!” 라고 독려를 하는 것입니다. 이것에 관한 최초의 Standard가 ASCII였습니다.

최초의 인코딩 표준 : ASCII Code
아스키 코드는 큰 장점이 있습니다. 바로 그것이 128개의 문자만을 표현하고 있다는 것인데 그것은 1byte의 메모리의 절반만을 (0000 0000 ~ 0111 1111) 사용해서 다 표현할 수 있는 숫자입니다. 하지만 그것은 동시에 아스키의 단점이기도 하였습니다. 아스키가 표현할 수 있는 문자는 알파벳 소문자, 알파벳 대문자, 그리고 !?#@%^& 등의 특수문자를 포함합니다. 그럼 한글은 어떻게 보여주죠? 네, 아스키로는 방법이 없군요. 메모리의 나머지 절반을 사용해서 표현하려고 해도 한글을 조합 하면 10,000자가 넘어갑니다. 128개로는 택도 없죠. 근데 한글만 있습니까. 한자, 일본어, 불어, 헝가리어 등등 세상엔 수십가지 종류의 문자가 존재합니다. 그래서 먼저 나온 것이 UNICODE-16입니다.

UNICODE-16
UNICODE-16의 컨셉은 아주 간단합니다. 한 문자를 1byte가 아닌 2byte로 표현하는 것이죠. 그래서 와이드 Char라고도 불립니다. 그러면 0000 0000 0000 0000 ~ 1111 1111 1111 1111 까지의 숫자를 문자와 연결 시켜 훨씬 더 많은 문자를 표현할 수 있습니다. 하지만 그만큼 한 문자를 표현하는 데에 필요한 메모리를 더 잡아먹게 되고, 거기다 기존의 ASCII 코드를 사용하던 문자를 읽을 수가 없게 되는 단점이 생깁니다. ASCII 의 두 글자를 하나로 인식해 전혀 다른 글자를 보여줄 테니까요. 또한 기존엔 1byte면 충분한 알파벳과 자주 사용하는 특수문자들도 모두 2byte를 사용해야 한다는 사실은 그다지 매력적이지 않았습니다. 컴퓨터의 메모리는 소중하니까요. 이 방식은 또 메모리의 한계를 드러냅니다. 2byte를 사용해도 표현할 수 있는 문자는 65,536 개 뿐인데, 5만 글자가 넘어가는 한자는 또 어떻게 표현해야 할까요.

UNICODE-8
그래서 나온 것이 이 인코딩 방식입니다. 아스키 코드를 1byte로 표현할 때 가장 왼쪽의 숫자가 쓰이지 않는 점을 이용한 것인데, 만약 이게 1이 되면 한 문자를 읽는데 2byte를 사용합니다.
1000 0000 0000 0000 = 가
1000 0000 0000 0001 = 나
1000 0000 0000 0010 = 다

1000 1000 0000 0000 = 쀍

그리고 가장 왼쪽의 숫자 2개가 1이면 한 문자를 표현하는데 3byte를 사용합니다.
1100 0000 0000 0000 0000 0000 = ¢
1100 0000 0000 0000 0000 0001 = ¤

이렇게라면 정말 표현할 수 있는 문자의 범위가 끝이 없지 않을까요? 또한 기존의 아스키코드도 인코딩 변환 없이 바로 읽을 수 있겠고요. 게다가 아스키 코드를 표현하는 데에는 아스키 코드를 쓰던 시절 처럼 1byte면 충분하겠네요. 참 놀라운 인코딩 방식인 것 같습니다.

참조
조엘 온 소프트웨어
Game Engine Architecture( 책 )

오브젝트(Object)의 반대말로 서브젝트(Subject)가 있다. 서브젝트는 주체란 뜻이고, 오브젝트는 객체란 뜻이다. 주는 주인 주 자이고 객은 손님 객 자이다. 쉬운 말로 하면 서브젝트는 '나'이고 오브젝트는 '나를 제외한, 나의 관념으로 들어온 손님이다. 연필도 객체고 책도 객체고 친구도 객체고 거울도 객체다. 나를 제외한 내가 인식하는 모든 것은 객체이다.

지금은 객체지향 프로그래밍의 시대다. 객체지향 프로그래밍은 객체를 중심으로 프로그래밍한다는 뜻이다. 객체지향 프로그래밍의 시대가 오기 전에는 절차지향 프로그래밍의 시대였다. 어떤 일을 특정한 순서대로 처리해 나간다. 절차지향 프로그래밍은 함수 중심의 프로그래밍 패러다임이고 객체지향 프로그래밍은 객체 중심의, 즉 클래스 중심의 프로그래밍 패러다임이다.

객체는 자신을 표현하는 정보를 가지고 있다. 예를 들어서 책은 여러장의 페이지, 제목, 저자, 출판사, 소비자가격, 그리고 수만글자의 텍스트와 그림들을 가지고 있다. 그리고 자신에게 특수화된 행동을 하거나 행동이 행해질 수 있다. 책은 펴질 수 있으며, 각 페이지는 접힐 수 있고, 제목 옆에 주인의 이름을 기입할 수도 있다. 연필은 펴질 수 없다. 거울에는 이름을 기입할 수 없다. 객체를 표현하는 정보 하나하나를 객체의 Instance variable 이라고 하고, 객체가 가할 수 있거나 객체에 가해질 수 있는 특수한 행위들을 그 객체의 Instance methods라고 한다.

다음은 학생 객체의 가벼운 예시다.

// 학생 타입의 hanbyeol이란 이름의 객체 선언
Student hanbyeol = [[Student alloc] init];
// hanbyeol 객체의 instance variable 'name'을 "한별"로 셋팅
hanbyeol.name = @"한별";

// instance variable 'age' 셋팅
hanbyeol.age = 23;

// 'major' 셋팅
hanbyeol.major = @"Computer Scinece";

// hanbyeol이 'takeExam' 이라는 instance method를 통해 시험을 침. 총 세 번 침.
[hanbyeol takeExam];
[hanbyeol takeExam];
[hanbyeol takeExam];

// hanbyeol 자신이 지금까지 친 시험의 평균 성적을 계산해 돌려줌.
char grade = [hanbyeol calculateAverageGrade];

처음으로 서버 프로그래밍을 할 때, 가장 낯선 개념 중 하나가 로그였다. 로그를 남기는 이유는 막연하게나마 알 것 같은데 언제, 어떻게 남겨야 할지는 허공의 구름을 잡는 듯한 느낌이었다. 뭔가 잡히는 것 같은데 안 잡히는… 그래서 새로운 콘텐츠를 담당하게 되었을 때, 로그를 제대로 남기어보고 싶어서 그에 대한 고민을 해 보았다.

로그를 도대체 왜 남길까? 그 이유는 간단하다. 로그는 표시다. 로그는 표시를 하기 위해서 남긴다. 그렇다면 왜 표시를 하냐. 바로 표시된 부분을 알기 위해서이다. 왜 표시된 부분을 알아야 하냐. 그것이 로직의 흐름이나, 문제점이나, 오작동여부를 확인하는 데 도움을 주기 때문이다. 그렇다. 로그를 남기는 이유는 로직이 의도된 바로 흐르는지, 내 코드의 문제나 내 코드를 잘못 사용한 코드가 없는지를 감지하기 위해서이다.

로그의 주 된 목표인 오류를 방지하기 위한 로그에 대해 생각해보자. 오류엔 두 종류가 있다. 내가 실수해서 생긴 오류, 그리고 다른 프로그래머가 내 코드를 잘못 사용해 생긴 오류이다. 전자나 후자나 로그를 남기는 방식은 똑같다. 어느 함수의 몇 번째 줄에 위치한 에러인지를 기록하고, 그 에러를 가장 잘 표현해주는 메시지를 남기도록 한다. 또한 그 에러가 발생한 정황을 역추적할 수 있는 정보들도 함께 출력해주면 원인을 더 쉽게 찾을 수 있다.

객체지향의 환경에서 클래스를 구현할 때, 오류에 대해서 우리가 신경 써야 할 2가지 가정이 있다. 절대 가정과 체크 가정이다. 절대 가정은 그것이 사실이라는 가정하에 클래스를 구현할 정도로 당연시 되는 가정이다. 따라서 사실이 아니면 오작동을 하거나 프로그램이 크래쉬가 날 수 있다. 너무나 당연히 사실이어야 하는 부분이기에 보통 따로 그 에러를 체크하여 로그를 남기지는 않는다. 하지만 크래쉬가 난다는 것은 서버 프로그래머에게 있어서 매우 치명적인 에러이기 때문에 퍼포먼스상의 하향이 있어도 가능한 한 이런 오류도 체크를 해서 로그로 남기고 크래쉬가 나지 않도록 돌려 처리하는 것이 좋다. 아닌 경우 헤더파일에 이러한 가정에 대해서 분명히 명시하는 것이 좋다. 이러한 가정은 행여나 인수인계 후 다른 사람이 그 클래스를 수정할 때 반드시 알고 있어야 하는 부분이므로 타작업자의 소스 분석의 혼돈을 줄이기 위해서라도 꼭 명시해 주도록 한다. 절대 가정은 아주 위험한 결과를 초래할 수 있기 때문에 그 내부 사정을 잘 알고 있는 클래스 내부에서만, 혹은 아주 결합도가 높은 컴퍼넌트 레벨에서만 하도록 한다.

Check 가정은 그 클래스 외부에서 그 클래스를 올바로 사용하는지를 검출하기 위한 것이다. 다른 메소드를 호출한 후에 호출해야 할 메소드를 바로 호출하거나, 클래스 멤버의 어떤 값을 설정해야 유효한 메소드를 설정 없이 호출한다거나, 무효한 값의 파라미터를 넘기는 행위 등은 오작동을 초래할 수 있다. 이런 외부동작에 대해서 그 클래스는 무조건 무결성으로 동작하는 것이 좋은 코드이지만 로그나 어썰트를 남기어 주는 것은 그러한 잘못된 사용을 감지하고 수정하는 데에도 도움을 준다. 이 경우 우린 로그를 남기어 그 코드를 사용하는 사람이 오류를 수정하도록 도와준다.

한 MMORPG게임의 개발에 참여할 때였다. 기획자와 프로그래머의 협의 과정에 대한 사뭇 진지한 논쟁이 벌어졌다. 기획자의 기획이 프로그래머에 의해 구현되기까지의 협의 과정이 논의주제였다.

이 논의를 통해서 얻은 것은 기획자와 프로그래머가 서로의 역할을 침범해서는 안 된다는 것이다. 제안은 할 수 있고 질문에 호의를 베푼 대답은 줄 수 있지만, 프로그래머가 기획 시스템에 지나치게 관여를 한다든지 하는 것은 위험하다. 왜냐하면 프로그래머가 기획의 책임과 업무량까지 가져갈 수 있기 때문이다. 그러면 프로그래머로써 불필요한 고민의 시간을 갖게 되며 그것은 구현의 시간을 잡아먹게 된다. 개인이 일정을 관리할 수 있다면 좋은 것이지만 그렇지 않다면 나의 역할이 아닌 것을 위해 내 역할을 소홀히 하게 되는 과오를 범할 수 있다.

다음은 잊어먹고 싶지 않아서 한 번 정리해본 협의 과정이다. 일단 기획에서 구현까지 이르는 데 필요한 네 가지 역할이 있다.
- 시스템 기획자
- 콘텐츠 기획자
- 시스템 프로그래머
- 콘텐츠 프로그래머

일은 콘텐츠 기획자로부터 시작된다. 콘텐츠 기획자는 게임의 구체적인 콘텐츠를 기획한다. 예를 들어서 캐릭터의 공격에 대해 정의하고 기획한다. 하면서 그 콘텐츠의 시스템 기획자와 여러 협의를 한다. 캐릭터의 공격을 가지고 계속 예를 들자면, 콘텐츠 기획자는 시스템 기획자와 공격할 수 있는 방식에 대한 논의를 한다. 스킬, 기본 공격, 점프 공격 등이 가능한지 본다. 데미지 수용 방식에 대한 논의를 한다. 크리티컬 데미지, 얼음 데미지, 화상 데미지 등을 시스템적으로 추가할 수 있는지에 대해 논의한다. 특정 공격에 캐릭터가 몇 초간 쓰러질 수 있는지 논의한다. 이런 논의 후 콘텐츠 기획자는 “넉다운”이라는, 70%확률로 300% 크리티컬 데미지를 주며 캐릭터를 3초간 쓰러지는 스킬을 기획한다. 요약하면, 크리티컬, 얼음, 화상 데미지 등을 시스템화하고, 캐릭터가 쓰러질 수 있는지 없는지를 결정하는 것이 시스템 기획자이며, 이러한 시스템을 활용해 다양한 스킬과 구체적 아이템들을 기획하는 것이 콘텐츠 기획자이다.

시스템 기획자는 이 것들을 콘텐츠 프로그래머와 논의한다. 이러한 시스템들을 추가하고자 하는데 구현이 가능한 것인냐가 주 된 논의 내용이다. 시스템 기획자가 미처 보지 못한 논리적 오류도 콘텐츠 프로그래머가 잡아낸다. 콘텐츠 프로그래머는 이 내용을 가지고 시스템 프로그래머에게 이러한 시스템을 만들어달라고 요청한다. 그러면 시스템 프로그래머는 합리성과 가능성을 따져본 후 구현 해 준다. 콘텐츠 프로그래머는 그 시스템을 기반으로 콘텐츠를 제작한다. 가능한 한 일반적이고 추상적으로 제작하여 코드 재사용성을 높이도록 한다.

왜 역사인가?
   컴퓨터와 땔래야 땔 수 없는 관계를 가진 나로써, 내가 그것에 대해 너무 모르고 있진 않나 하는 생각이 들었다. 어떤 모호한 프로그래밍 개념에 대해 꼬리를 물고 물다 컴퓨터가 무엇이냐에 대한 질문에 도달했을 때 난 "그게 뭐였지..?"하며 머리를 긁고 있었기 때문이다. 과거에 여러 컴퓨터 관련 시험에 응시하면서 주입식으로 관련된 지식들을 줄줄이 외운적은 있었지만, 주입식은 주입식. 시험 후 줄줄이 출혈됐나 보다. 주입식 학습 방식의 폐해를 다시 한 번 체감한다.
   어쨌든 프로그래밍 전문가를 꿈꾸는 나였다. 따라서 프로그래밍 공간이 펼쳐지는 컴퓨터에 대해서만큼은 명확한 답을 갖고 싶었다. 그래서 컴퓨터 탄생의 시초부터 오늘날의 컴퓨터까지의 흐름을 짚어주는 역사부터, 찬찬히 훑어보기로 했다. 그게 오늘 포스팅의 주제다. 역사의 원활한 이해를 위해서, 컴퓨터의 시초는 컴퓨팅(계산)이었다는, 책상은 책상이다는 사실만 기억하자.

컴퓨터의 시초
   어떤 이유로든지, 옛부터 계산은 상당히 반복적이고 번거로운 일이었다. 그래서 옛 사람들도 계산을 단순하고 빠르고 편리하게 하기 위해 다양한 도구들을 고안해 냈다.그 중에서도 가장 간단하면서 효율적이었던 것은 주판이었다. 아버지의 말씀이 사실인지는 모르겠지만, 만단위의 곱셈 계산에 답하는데 1초도 안걸리셨단다. 하지만 주판을 제외하면 17세기에 이르도록 계산을 위한 특별한 도구는 없었다. 그러던 중 파스칼이 톱니바퀴를 이용한 수동식 계산기를 고안해 냈다. Pascal computer
Pascal computer by mikepilat 저작자 표시비영리동일조건 변경허락

   파스칼의 수동식 계산기는 십진수의 각 자리수를 나타내는 톱니바퀴들로 구성되었다. 각 바퀴에는 10개의 눈금이 있는데, 이 눈금들을 모두 움직이면 다음 자리의 톱니바퀴가 한눈금 움직인다. 계산의 예를 들면, 1017이라는 숫자에 207이라는 숫자를 더하려면, 톱니바퀴의 각 눈금을 1,0,1,7에 맞추고, 1의 자리의 톱니바퀴를 207번 돌리면 된다. ㅋㅋㅋ. 잘 낚였으면 다음으로 넘어가자. 하하, 그럴리가 없지 않은가? 각 자리수의 톱니바퀴를 2, 0, 7번 돌리면 된다. 총 9번을 돌리면 되겠다. 파스칼의 계산기는 그 원리에서 유추할 수 있듯이 덧셈과 뺄샘만을 위한 계산기였다.   그로부터 29년 후인 1671년, 라이프니츠는 곱셈과 나눗셈도 가능한 계산기를 만들었다. 또한 십진법보다 더 기계장치에 적합한 진법을 연구하다 이진법을 창안하였다. 이진법이 기계장치에 더 적합한 이유는 아마 곱셈과 나눗셈 등 더 복잡한 계산을 십진법보다 간결하게 표현해 주었기 때문이 아닐까 싶다.

전자 컴퓨터의 등장    1823년, 드디어 오늘날의 컴퓨터 모델의 원형과 가까운 계산기가 고안되었다. 이것은 찰스 배비지에 의해서 제시된 견해로, 현대 컴퓨터의 기본 구성 요소인 입출력 장치, 기억장치, 연산장치, 제어장치를 모두 갖춘 것이었다. 하지만 이것은 기술적인 제약 때문에 그 당시엔 실현될 수 없었다. 참으로 안타까웠을 것이다. 찰스 배비지는 그 외에도 차분기관과 해석기관을 설계하였다. 차분기관은 삼각함수표를 유효숫자 5자리까지 계산하여 종이에 인쇄하는 장치였고, 해석기관은 컴퓨터의 방정식을 순차적으로 풀 수 있도록 고안된 장치였다.

   1944년에, 이러한 배비지의 이론을 바탕으로 드디어 최초의 전자 컴퓨터가 탄생했다. 배비지도 그것을 보았으면 좋았을 텐데! 컴퓨터의 이름은 MARK-1. IBM사와 하버드 대학의 Howard Aiken이 이룬 업적이다. 3000개가 넘는 계전기와 기어로 만든 종이 테이프로 제어되는 자동순차적 제어방식의 거대한 괴물이었다. 연산 과정도 더럽게 느렸다고 한다. 빠른 계산 보다는,  복잡한 연산을 자동으로 해준다는 것에 의의가 있었단다.

다용도 컴퓨터의 등장과 역사
    1946년 미국 펜실베이니아대학 에거트와 J. W. 모클리는 최초의 전자식 계산기 에니악(ENIAC:Electronic Numerical Integrater And Computer)이라는 다용도 디지털 컴퓨터를 최초로 개발했다. 이것은 진공관을 사용한 최초의 자동 계산기로 18,000여 개의 진공관과 1,500개의 계전기를 사용하였고, 무게가 30t이나 되는 거대한 기계였다. 150kw의 전력을 소비하였고,프로그램을 배선판에 일일이 배선하는 외부 프로그램 방식이었으므로, 에니악에서는 작업에 따라 배선판을 교체해야만 하였다. 
   그 뒤 에니악의 단점을 보완하기 위해 1945년 존 폰 노이만이 기억장치에 컴퓨터의 명령이나 데이터를 모두 기억시키는 프로그램 내장방식을 제안하였다. 
   1949년 영국 케임브리지대학에서 이 프로그램 내장방식을 채택하여 세계 최초로 내부기억장치가 있는 에드삭(EDSAC)을 개발하였고, 미국에서는 1952년 노이만에 제안한 전자식 프로그램 내장방식인 에드박(EDVAC)을 만들었다. 
   또한 1951년에는 유니박-원(UNIVAC-I)을 만들어 상품화하는 데 성공하였는데, 이것이 최초의 상업용 컴퓨터이다. 에드삭은 소프트웨어 면에서도 크게 이바지하였다. 그 뒤 프린스턴고등연구소에서 노이만의 지도 아래 제작된 이아스(IAS) 컴퓨터를 비롯하여 차례로 매사추세츠공대의 월윈드(Whirlwind), 에커르트와 모클리의 바이낙(BINAC), 일리노이대학의 일리악(ILLIAC), 랜드회사의 조니악(JOHNIAC) 등이 제작되었다. 또한 컴퓨터의 크기는 반도체 기술과 전자기술의 발달로 점점 작아지고 연산속도도 피코초(ps) 단위로 빨라졌으며, 이용범위도 확대되어 가정은 물론 산업사회의 여러 분야에서 다양하게 이용되고 있다. 컴퓨터는 제1세대인 진공관, 제2세대인 트랜지스터, 제3세대인 IC, 제4세대인 초 LSI와 같이 대략 10년마다 집적도를 높여 고속화, 대용량화하였고, 슈퍼 컴퓨터가 출현하였다.
   [출처: Wikipedia]
   위의 글상자의 내용은 필요할 때만 한 번 읽어 볼 수 있게 내언어로 재해석 하지는 않았다.

결론
   이것이 대략적인 컴퓨터의 역사다. 컴퓨터는 별것이 아니었다. 그냥 계산기였다. 단지 지금의 컴퓨터는 더 다양한 입력을 받을 수 있고 더 다양한 방법으로 출력을 할 수 있으며 더 복잡하고 어려운 연산을 해내고 더 복잡하고 다양한 제어가 가능하다. 그리고 더 많이 기억할 수 있다. 어쩃거나 컴퓨터에 대해서 이제 좀 알 것 같다.
   컴퓨터는 계산기다. 이 사실만 기억한다면, 주판으로부터 시작되는 컴퓨터의 대략적인 역사의 흐름이 기억이 날 것이다. 그럼 된다.

흥미로운 사실
   대학의 힘은 정말 큰 것 같다. 최초의 컴퓨터가 발명된 곳이 대학이라니. 컴퓨터의 역사에서 언급된 대학의 업적만 보고 있어도 가슴이 두근거린다.

지식의 출처
위키피디아 -http://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0%EC%9D%98_%EC%97%AD%EC%82%AC