« Previous : 1 : ... 204 : 205 : 206 : 207 : 208 : 209 : 210 : 211 : 212 : ... 215 : Next »

<날개셋> 한글 입력기는 2000년에 1.0이 첫 개발된 이래로 지금까지 윈도우 플랫폼만을 고수해 왔다.
윈도우 안에서는 윈도우 95/NT4부터 시작해 64비트 비스타/7까지 운영체제가 제공하는 모든 문자 입력 프로토콜을 정복하는 경지에 도달했지만, 윈도우 이외의 운영체제 지원은 개발자의 지식과 여유 부족으로 인해 전무한 실정이다.

사실 여러 통계들만 보면 개인용 PC 시장 운영체제의 점유율이 윈도우가 이미 90%대에 달해 있고, 맥/리눅스가 각각 7, 2% 정도를 차지하고 있으니 어떤 소프트웨어에서 맥/리눅스의 지원은, 마치 윈도우 시장 내부에서 XP/비스타를 제외하고 인제 와서 NT/2000이나 심지어 9x 계열을 지원하려 애쓰는 것처럼 아주 사소한 일일 수도 있다.

하지만 문제는 <날개셋> 한글 입력기의 사용자 집단은, 일반 PC 사용자 집단과는 그 비중이 같지 않다는 것이다.
비록 내 프로그램의 용도가 세벌식 자판에 국한된 것은 아니지만, 주 목적이 세벌식 관련 지원 기능이고 그쪽으로 실제로 기능이 풍부하기도 하기 때문에 프로그램 사용자 중에는 세벌식 사용자가 많다.

그런데 본인이 파악하고 있기로는, 세벌식을 쓸 정도의 매니아급 파워 유저 중에는 리눅/맥 사용자가 상대적으로 굉장히 많다. 전체 PC 사용자 중에는 리눅/맥 사용자가 10%도 채 안 될지 몰라도, <날개셋> 사용자 중에는 리눅/맥 사용자의 비율이 30%대에 달할 수도 있다는 뜻이다.
마치 본인이 글자판도 극소수 글자판을 쓰는 데다 성경까지 극소수만이 진가를 아는 성경을 읽는 것처럼, 소수 집단은 뭔가 소수 집단끼리 통하는 게 있기라도 한 것 같다.

이런 시대 흐름에 부합하여 본인 역시, 최근에는 평생 안 들여다볼 것 같던 맥 OS와 리눅스 쪽 자료를 틈틈이 살펴보고 있다. 물론 여기에는 회사에서 내 개인용 컴퓨터보다 더 다양한 플랫폼을 접할 기회를 얻은 것도 한몫 작용했다.
(사실 본인이 회사가 아니라 전산학과 대학원에 갔다면 맥은 몰라도 리눅스 지원은 확실히 빨라졌을지도 모른다.)

새로운 운영체제에 완전히 적응하고, 더구나 단순 응용 프로그램이 아니라 운영체제 쉘과 밀접한 관련이 있는 저수준 프로그램인 IME를 포팅하는 것은 쉬운 일이 아닐 것이다.
해당 운영체제의 프로세스/스레드/DLL 구조부터 시작해 GUI API, 도움말 및 배포 패키지를 만드는 요령, known directory 구조부터 당장 알아야 한다. 제아무리 크로스 플랫폼 GUI 툴킷의 도움을 받는다고 하더라도, 일단 그 툴킷 자체도 공부해야 하고 해당 운영체제에 맞는 개발툴 내지 에디터, 그리고 심지어 프로젝트(메이크파일) 세팅 요령도 익혀야 할 것이다. 헤쳐 나가야 할 건 아직 참으로 많다.

다음은 현재 본인이 생각하고 있는 프로그램 개발 및 포팅의 원칙이다.

1. 타자연습보다는 입력기가 우선순위가 더 높다.
적어도 본인에게는 입력기는 main이고 타자연습은 sub이다. 지금까지도 그래 왔고 앞으로도 그럴 것이다.
타자연습은 MFC를 사용했지만, 입력기는 WinMain함수부터 뼈대부터 완전히 100% 윈도우 API만 써서 내 손으로 만든 프로그램이다. 애착도 더 높다.

타자연습을 한동안 소스를 공개해 오다가 현재는 다시 닫았는데, 사실, 책임감 있고 믿음직한 후임이 나타난다면 그 사람에게 타자연습 소스 코드를 인계하고(단순한 코드뿐만 아니라 구조 설명까지) 개발을 전적으로 위임할 생각도 있다.

타자연습은 지금까지 버그 수정이나 입력기에서 먼저 개발된 신기능/기술의 동반 적용 같은 걸 빼면, 이렇다할 기능 추가나 구조적인 변화는 거의 없이 정체 상태였다. 타자연습도 만들고 싶은 게 많다. 연습글 관리 방식 개선이라든가 게임 리모델링, 네트워크 지원만 해도 굵직한 주제가 벌써 여러 개 나온다. 하지만 내가 도저히 그것까지 신경쓸 시간이 없다.

2. 윈도우용이 여전히 우선순위가 더 높다.
분배보다는 성장이라고 해야 할까? 타 운영체제를 살펴보기에는, 아직 당장 윈도우용 오리지널 프로그램에도 더 넣고 싶은 기능과 보강해야 할 것들이 훨씬 더 많다. 현실적으로 여기에 시간 할애 가중치가 더 실릴 수밖에 없다.

3. 리눅스보다는 맥이 선호도가 더 높다.
본인의 개인적인 바람은, 리눅스보다 점유율이 더 높고 여러 배포판 혼잡 같은 게 없이 일관성도 있는 맥 OS 쪽 포팅을 리눅스보다 먼저 해 보고 싶다.
하지만 현실적으로는 본인에게는 일단 맥북이 없으며, 오로지 이 포팅 작업만을 위해서 맥북을 구입하고 관리할 만한 여건도 못 된다. 현실적으로는 당장 VMware로 손쉽게 띄울 수 있고 한글 IME를 돌려 볼 수도 있는 리눅스를 먼저 살펴보게 되겠다.

4. 외부 모듈보다는 편집기가 우선순위가 더 높다.
윈도우용이 그랬던 것처럼 프로그램 개발 내지 포팅은 입력기 커널(플랫폼 독립적인) -> 제어판 GUI -> 편집기 -> 외부 모듈 -> 플러그 인의 순으로 진행될 것이다. 전용 에디터인 편집기부터 먼저 포팅한 후 외부 모듈은 나중에 등장할 것이다. 쉬운 것부터 진행하겠다는 원칙은 두말할 나위가 없다.

5. 소스 코드와 버전 관리
<날개셋> 한글 입력기의 코드는 크게 윈도우용과 리눅/맥용으로 나뉜다. 이미 윈도우 API만으로 지극히 가볍고 잘 튜닝되어 있는 기존 윈도우용 소스를 건드릴 필요는 없겠고 리눅스와 맥은 가능한 크로스 플랫폼 GUI 툴킷을 이용하여 한 코드 베이스로 관리할 것이다. 그 이유는 물론 본인이 각 OS의 native API를 익힐 시간이 없기 때문이다. 현재로는 그 툴킷으로 Qt를 고려하고 있는 중이다.

버전은 처음엔 1.0부터 시작해서(비록, 윈도우용 기준으로는 최소 미래의 5.x~6.x 엔진을 사용하더라도)
나중에 리눅/맥용도 윈도우용과 완전히 대등하게 포팅이 완료됐고 세 에디션 개발을 동시에 할 수 있게 됐을 때 윈도우용 버전으로 번호를 일괄 상향 조정할 생각이다.

전부 생각만 이렇게 해 놓은 것이다. 실제로 이게 실현되는 건 한참 먼 미래가 될 수도 있다. -_-

Posted by 사무엘

2010/01/11 10:28 2010/01/11 10:28
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/93

도스 시절의 한글 윤곽선 글꼴

사용자 삽입 이미지

도스 시절에 한글(한글에만 국한은 아니겠지만)을 출력하는 기법은 비트맵 아니면 벡터(윤곽선) 이렇게 두 갈래로 양분화해 있었다.

비트맵은 도깨비 한글의 8*4*4벌 규격에 맞게 만들어진 16*16 한글 글꼴을 찍는 것으로 사실상 통합이 되어 있었고, 윈도우 시대가 도래하기까지 널리 쓰였다. 뭔가 좀 아마추어스러운 냄새가 나고 상업/출판용 글꼴만치 고품질의 글자를 만들 수는 없지만, 그래도 가격 대 성능이 굉장히 뛰어난 좋은 방법이었기 때문이다.

본인이 아는 한, 한컴이나 MS 같은 회사가 아니라 개인이 만든 싸-_-제 프로그램이 이와 다른 기법으로 한글을 출력하는 것은 본 적이 없으며, 저 방식대로 수많은 싸제 글꼴들이 쏟아져 나오기도 했다. <날개셋> 편집기는 도깨비 글꼴도 지원하고, 임의의 조합 테이블을 가진 글꼴에다 2350 완성형 글꼴까지 지원함으로써, 한글 출력에서 그런 비트맵 글꼴 처리 분야는 완전히 마스터를 했다.

윈도우로 넘어가서도 이야기, 새롬 데이타맨처럼
그나마 고정폭 글꼴이 널리 쓰이는 VT 기반 통신 프로그램에서 비트맵 글꼴이 한동안은 명맥을 이어 나갔으나,
이마저도 이제 역사 속으로 사라져 버렸고, 오늘날 이런 16*16 한글 내지 8*16 영문 고정폭 비트맵 글꼴을 고수하고 있는 프로그램은 <날개셋> 편집기 뿐이다. ㄱㅅㄱㅅ

그럼 윤곽선 글꼴 분야로 가면 사정이 어떨까?
그 때에 도스에서 윤곽선 글꼴은 그래픽이나 워드 프로세서, 또는 그 둘의 중간에 해당하는 배너 같은 아주 특수한 분야의 전문 프로그램에서나 볼 수 있었다.

터보 C가 제공하던 BGI 라이브러리도 소위 벡터 글꼴을 지원은 했으나, 영문밖에 지원되지 않았고, 기술적으로도 진정한 의미의 곡선이 표현되지 못하며 내부 채움(래스터라이즈)도 안 되는 그냥 직선 나열일 뿐이었다.

그런 척박한 시절에 한글을 윤곽선 글꼴로 표현해 낸 프로그램이 있었으니 본인은 관심이 끌리지 않을 수 없었다. 아래의 프로그램들은 모두 1991~92년 그 시기에 제작되었다.
자형 디자인은 어떻게 하고 글꼴 파일 포맷은 어떻게 설계했을지, 래스터라이즈 루틴은 어떻게 작성했을지 모든 것이 그저 신기하게만 보인다.
(참고로 윈도우 운영체제도 3.x에서 윤곽선 트루타입 글꼴이 첫 도입된 건 이 시기이다!)

1. 하늘 (경북대 동아리)

내장하고 있는 싸제 글꼴은 형태가 심하게 조잡하긴 하다. =_=;; 이 글에서는 <하늘>만 예를 들지만, 과거 <수채화>도 글쓰기 기능의 퀄리티가 하늘과 굉장히 비슷했다. 단, <수채화>는 상업용 프로그램답게 얼추 배너 프로그램처럼 글자의 레이아웃을 변형하는 기능도 지원한다.

2. 한글 배너 (동국대 동아리?)

BannerMania라는 외산 상업용 프로그램으로부터 영감을 받아 개발된 게 분명한 프로그램이다. 영문 글꼴은 B에 있는 녀석을 그대로 쓴다. 즉, 이 프로그램의 개발자는 B의 글꼴 파일 포맷에 대한 정보를 입수했다는 뜻이다. 그 반면 한글 글꼴은 본인이 들여다본 바로는 B의 글꼴과 관계가 없는 자체 포맷이다.

학술 학회 명의로 되어 있지만 실질적인 개발은 개인이 혼자서 한 듯하다. 원전인 B보다 기능은 훨씬 더 뒤떨어지지만, 혼자서 저 정도 난이도의 프로그램 clone을 만든 거라면 지금 봐도 정말 대단한 거다.

글꼴 디자인도 개인 작품인지 궁금하다. 명조는 좀 어설픈 느낌이 나지만, 다른 글꼴인 고딕, 안상수, 샘물 등은 배너 용도로도 적합하고 은근히 볼 만하다.

3. 키다리 (개인+알파)

마우스로 조작하는 UI가 무척 특이하긴 한데, 이것도 상당히 잘 만든 공개 소프트웨어이다. 지금 <날개셋> 편집기에도 내장하고 있는 "키다리체"는 이 프로그램이 UI 출력용으로 쓰던 비트맵 글꼴이다. 그래픽체 비슷한 느낌을 낸 게 무척 참신하게 느껴지지만 좀 엉성한 느낌도 많이 들어 아쉬운 글꼴이다.

이 프로그램의 진면모는 바로 배너를 출력할 때 나오는 키다리 특유의 그래픽체이다. 신명 태그래픽을 연상시키는 이 글꼴은 개인이 디자인한 싸제이지만, 상당히 품질이 좋으며, 글꼴 전문 업체에서 만든 보급-_- 글꼴과 견주기에도 손색이 없다. 그러면서도 한글 11172자는 모두 표현 가능하다. 그래픽체는 비슷한 분위기의 영문 글꼴에서 착안하여 최초 원도를 최 정호 씨가 만든 것으로 잘 알려져 있는데, 자형 자체가 무척 깔끔하고 본문으로나 배너 장식으로나 적합해서 본인 역시 좋아한다.

엄청 옛날에 <자유>라는 프로그램도 있었다. 한번에 한두 줄짜리 배너만 출력하는 프로그램과는 달리, 얘는 한 페이지 안에 여러 배너 형태 문구들을 마치 벡터 드로잉처럼 배치하여 출력이 가능했는데 역시 윤곽선 글꼴과 다양한 효과를 지원했다. 본인이 본 버전은 무려 허큘리스에서 돌아가는 놈이었다.

4. 아래아한글 2.0 전문용

민간인이 열악한 여건 속에서 오로지 열정만으로 만들어 낸 "싸제" 글꼴과 공개 프로그램을,
한양 시스템이라는 번듯한 업체 글꼴을 사용한 상업용 프로그램과 동일선상에서 비교하는 것은 물론 무리가 있다. 그래도 역사 기록이니까 소개해 본다. 보급 글꼴은 2350자를 일일이 디자인한 것들이니, 싸제하고는 근본적으로 격이 다를 수밖에 없다. -_-;;;

그래픽체는 아래아한글 2.0 전문용에 원래는 없던 녀석이고, 아마 묵향 같은 한양 시스템 추가 패키지를 설치해야 추가되었지 싶다. (2.1 이후에 추가됨) 2.0 때는 아직 윤곽선 글꼴 파일 포맷도 굉장히 초보적이었으며, hft 파일 내부에 자기의 이름이나 제조사, 저작권/코드 페이지 정보 같은 것도 없었다. 오로지 윤곽선 벡터 드로잉의 컬렉션이었으며 이를 활용하는 방법은 전적으로 상위의 응용 프로그램에 달려 있었던 것이다.

그 당시 아래아한글 2.0 일반용 수준의 퀄리티와 가격에다, 윤곽선 글꼴 표현으로 아래아한글과 경쟁하던 프로그램으로 "21세기 워드"라는 게 있었다. 오늘날 말도 많고 탈도 많은 알툴즈의 개발사로 유명한 이스트소프트의 작품이다. 얘를 구경 못 한 채 어린 시절을 보낸 건 좀 아쉽다.

Note:

윈도우 3.1이 도입한 트루타입 글꼴은 어마어마하게 정교한 힌팅으로 유명했으며 이 기술을 이용하여 작은 크기에서도 상당히 좋은 품질의 자형을 제공했다. Arial이나 Times New Roman 같은 글꼴이 12포인트 이하의 작은 크기에서 antialiasing이 없을 때도 마치 비트맵 글꼴처럼 품질이 좋은 동시에 ClearType도 잘 받는 이유가 여기에 있다. 아예 굴림체처럼 내장 비트맵을 쓰는 글꼴은 ClearType의 영향은 받지 못한다.

윈도우 3.1 글꼴을 납품한 업체는 당시 우리나라의 유망 중소기업이던 큐닉스 컴퓨터이다. 아예 비트맵을 내장하는 게 아니라 힌팅만으로 바탕, 굴림, 돋움, 궁서 자형을 작은 크기에서 꽤 좋은 품질로 잘 만들었던 걸로 기억한다. 물론 윈도우 95 이후의 한양 시스템 서체는 아예 전부 내장 비트맵으로 대체를 해 버렸지만 말이다.

하지만 도스에서 윤곽선 글꼴을 구현하던 "싸제" 프로그램들은 그런 힌팅까지 구현할 정도로 전문적일 수는 없었다.

Posted by 사무엘

2010/01/11 10:20 2010/01/11 10:20
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/91

printf/scanf가 받는 % 문자는 이식성 면에서 매우 큰 문제를 일으킬 수 있다. 기계 종류와 운영체제/컴파일러(정확하게는 CRT 라이브러리)의 종류에 따라 미묘한 차이가 존재하기 때문이다.

이런 잡음이 제일 없던 꿈 같은 시절은 단연 32비트 시절이다. 포인터와 정수가 전부 4바이트가 됨으로써 %d와 %ld 같은 골치아픈 구분도 없어졌고, 포인터도 far/huge 같은 구분이 없어져서 모든 것이 32비트 단위로 끝이 났기 때문이다. %d, %x, %u 하나만으로 컴퓨터에서 통용되는 거의 모든 정수를 바로 읽고 쓸 수 있던 시절. -_-

* * * * * *
Note 1
  참고로 정수가 아닌 실수는?
16비트 시절에는 터보 C/C++에 무려 10바이트 크기의 실수인 long double이 있었고, 파스칼에는 아예 6바이트짜리 Real이라는 기괴한 실수가 존재했다. CPU의 machine word가 16비트 크기이고, GPU는커녕 부동소숫점 전용 프로세서(FPU)마저 흔치 않아서 이런 연산도 소프트웨어적으로 직접 구현하는 게 당연시되던 시절이었으니까 그런 게 존재 가능했다.
요즘 세상엔 무조건 32비트 float 아니면 64비트 double이지, 저런 건 상상도 못 할 개념일 것이다. 픽셀 크기조차도 옛날에는 트루컬러 24비트이다가 요즘은 컴퓨터가 더 처리하기 편한 형태인 32비트이다.
* * * * * *

하지만 이렇게 32비트 천하통일 시대에 끝이 보이기 시작한 것은, 64비트 컴퓨터가 속속 등장하고 문자열도 일반적인 8비트 크기가 아닌 16비트 단위의 소위 wide string이 공존하게 되고부터이다.

그럼, 이번에도 역시 숫자부터 예를 들어 보겠다.

32비트 윈도우 + 비주얼 C++의 CRT는
32비트 정수를 주고받을 때는 당연히 그대로 %d나 %u를 주면 되고 별도의 크기 지정자가 필요 없다. 하지만 64비트 정수에 대해서는 I64라는 접두사를 넣어서 %I64d처럼 해야 한다.

이 규칙은 64비트에서도 완전히 동일하게 적용되기 때문에 이식이 쉽다.
특히 호환성을 극도로 중요시하는 윈도우는 64비트 기계에서도 int 형을 32비트 4바이트로 책정한 관계로, 64비트에서도 %d가 아닌 %I64d를 해 줘야 32비트 영역을 넘어서는 정수를 읽거나 쓸 수 있다. 64비트 기계이더라도 숫자는 일단 변함없이 32비트가 주류라는 인상을 넣은 것이다.

* * * * * *
Note 2
  윈도우즈 문화권은 왜 이리도 호환성에 목숨을 걸까?
간단하다. 그쪽은 오픈소스 진영과는 근본적으로 분위기가 다르기 때문이다.
모든 것이 투명하게 소스 공개이고, 사용자들이 다 컴퓨터를 능수능란하게 다루는 능동적인 해커들인 세상에서는 뭔가 소프트웨어를 업데이트해도 줘도 못 먹는 사람이 없이 물갈이도 금방 된다. 소프트웨어 계층에 breaking change가 잦더라도 재컴파일 한 번으로 '끗'이며, 그렇게 문제가 되지 않는다.

하지만 여기는 사정이 다르다. 마우스로 느릿느릿 아이콘 클릭밖에 못 하고 악성 코드에 속수무책으로 당하는 컴맹도 많다. 또한 돈 내기 싫어서 구닥다리 OS를 계속 고집하는 사람도 많다. 오로지 MS라는 회사가 모든 내부 사정을 관장하고 고객을 다 떠먹여 줘야 한다. 그러니 무조건 한번 만들어 놓은 것에 대한 유지 관리가 편리한 시스템을 만들어야 하며, 새 제품을 단절 없이 많이 팔려면 하위 호환성이라는 보수적인 가치를 최우선 순위로 두고 목숨 걸 수밖에 없는 것이다.
* * * * * *

단, 딱 하나 문제가 될 수 있는 것은 소위 INT_PTR 타입으로, 32비트 기계에서는 32비트이지만, 64비트에서 실제로 64비트 크기로 확장되는 정수이다. 이게 진짜로 포인터의 크기와 같으며 machine word와 크기가 일치함이 보장되는 정수이다.

이런 정수를 다루는 프로그램의 이식성을 위해서 %Id가(64만 빼고) 별도로 추가되었지만, 이건 반대로 구형 CRT에서는 지원되지 않는 걸로 알고 있다.
그래도 다행인 건, binary format이 아니라 사람이 읽을 수 있는 문자열 형태로 숫자를 읽고 쓰는데 32비트 크기를 넘어서는 범위를 다루는 일은 굉장히 드물다는 것. 차라리 실수를 다루면 다뤘지 정수가 그러는 일은 드문 편이다.

참고로, 가변 인자 함수가 호출될 때, 모든 정수형은 기본적으로 int 형으로 promote가 일어난다. char이든 short이든 다 32비트 내지 64비트 크기로 폭이 증폭된다는 것이다. float는 double로 바뀐다. 그렇기 때문에 float나 double이나 동일하게 %f나 %g로 출력 가능하다. 단지, 값이 아니라 포인터가 전달되는 scanf를 호출할 때는, float에 대해서는 %f를, double에 대해서는 %lf라고 반드시 타입 구분을 엄격히 해 줘야 할 것이다.

64비트 정수를 전달할 때는 32비트 기계에서는 스택에 push가 두 번에 걸쳐 일어나지만, 본디 64비트이던 기계에서는 역시 한 번만에 인자 전달이 끝난다. 그렇기 때문에 %d %d %d 해 놓고 실제로 32, 64, 32비트의 순으로 변수를 전달했다면 32비트 기계에서는 마지막 숫자가 꼬이겠지만(push는 128비트, 하지만 pop은 96비트) 64비트는 둘째 정수가 범위만 32비트 내부에 있다면 세 숫자가 모두 제대로 출력이 된다(push와 pop 모두 64*3비트 동일).
물론 이 경우, 둘째 %d를 %I64d로 해 줘야 32와 64비트 기계에서 모두 잘 동작하는 portable 코드를 만들 수 있다.

윈도우 외의 다른 운영체제는 사정이 어떤가 모르겠다. 64비트 정수를 출력할 때 32비트 기계에서는 %lld, 심지어 64비트에서는 %ld 이렇게 차이가 존재한다고도 하는데.. =_=;;
gcc 자체가 I64와는 다른 관행을 사용하는데 기계마저 64비트로 가고 나면 이거 이식성 면에서 재앙이 발생하지는 않으려나 우려된다.

다음으로 문자열이 있다.
알파벳 이외의 문자는 다룰 일이 없는 서버나 게임 엔진 같은 아주 특수한 프로그램을 개발하는 게 아니라면 이제 유니코드 문자는 대세가 되어 있다. 물론 UTF8도 쓰이고 유닉스 계열 운영체제에서는 심지어 UTF32도 쓰이지만, 그래도 유니코드 문자열을 컴퓨터 메모리 상으로 저장하는 데 비용 대 효율이 가장 뛰어난 방법은 UTF16이다. 특히 윈도우는 NT 시절부터 이렇게 16비트 단위의 wide string을 내부적으로 다뤄 와서 wchar_t = 곧 unsigned short나 다름없을 정도이다.

printf는 ansi 버전과 wide 버전이 존재하며, format으로 지정해 주는 문자열과 %s로 전달하는 문자열의 타입은 대체로 일치한다. ansi 버퍼에다가 wide string을 출력한다거나 그 반대로 해야 하는 경우는 드물다. 하지만 그런 일이 아주 없는 것은 아니다.

이럴 때 윈도우에서는 %hs, %ls라는 지정자를 주어 h는 버퍼 크기와 상관없이 무조건 ansi, l은 버퍼 크기와 상관없이 무조건 wide라고 지정을 할 수 있게 했다. gcc 쪽은 잘 모르겠다.

그래서 함수 오버로딩이 지원되는 C++ 스트림이 짱이라는 말이 있을 정도이니까. 아무 곳에서나 그저 무조건 OK.

Posted by 사무엘

2010/01/11 10:15 2010/01/11 10:15
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/90

황금도끼 도스용 버전을 처음 해 본 게 초등학교 고학년이던 92년이었습니다.
그 후 무려 17년이 지나서 몇 달 전에.. 마메를 돌려서 오락실 아케이드 버전을 처음으로 해 봤습니다. -_-;;

둘을 충분히 해 보고서 내린 결론은
도스용과 오락실용의 차이는 아래아한글과 MS 워드의 차이와 비슷하다는 것. =_=;;;;
모든 동작 방식이 손에 익어 있고 예측 가능한 아래아한글과는 달리, MS 워드류는 영 적응이 안 되는 야생마 같습니다.

도스용은 눈에 띌 정도로 스프라이트 수가 엄청 감소(strip down)해 있다는 것을 알 수 있었습니다. 메모리가 부족해서 그런 거겠죠. 그리고 원본에 존재하던 다중 스크롤도 삭제되었고, 움직이던 독수리 눈도 도스용에서는 응당 정지해 있습니다.

때리는 프레임이 남자와 여자는 2프레임, 그리고 가장 날렵한 캐릭터인 난쟁이 할아버지는 단 1프레임이죠. 뛰기 전에 잠깐 다리를 굽히는 동작도 오락실에는 있지만 PC에는 없습니다.

하지만 이 덕분에 PC판이 주인공의 조작 반응성이 더 날렵-_-해진 것은 있습니다. 오락실은 타이밍을 놓쳐서 적이 나의 때리기 공격을 피하고 반격을 하는 게 가능하지만 PC는 거의 그런 게 없지요. 물론 나뿐만 아니라 적도 더 날렵해졌지만.. -_-;; 때리면 거의 무조건 맞거나 아니면 아예 피하거나 이뿐입니다.

1단계에 나오는 꼬리로 공격하는 괴물은 PC판보다 다루기가 훨씬 더 어렵고 불을 쏘는 용도 발사 후의 cooldown이 굉장히 길어서 운용하기 어렵습니다. 그거 발사한 후 뒤의 적에게 반격을 당하기 쉽습니다.
PC판은 용에서 한번 떨어지고 나면 용은 거의 즉시 달아나 버리는 반면, 오락실판은 그래도 관용이 좀 있더군요.

몬스터의 AI도 원판이 훨씬 더 강력합니다. 작은 몬스터도 점프 공격을 하며, 해골은 훨씬 더 똑똑하고 무섭고 공격 데미지가 강합니다. PC판은 해골은 남자 몬스터와 체력도 일치하고, 점프 공격을 할 줄 아는 것 외에 딱히 차이가 없거든요. 사실, 몬스터별 체력이라든가 데미지 체계도 PC판은 딱 정해져 있는 반면 오락실판은 이미 수십 판을 해 봤는데도 파악이 잘 안 되겠더군요.

몬스터는 PC판처럼 무조건 주인공을 향해 접근만 하는 게 아니라 근처에 용이 있으면 용부터 탑니다. 그리고 PC판처럼 x축부터 일치시킨 후 y축으로 접근하는 게 아니라, y축부터 일치시킨 후 달리기 박치기 시도를 굉장히 잘 합니다. 이런 이유로 인해 용 같은 걸 뺏어 타기도 PC판보다 더 어렵습니다.

그리고 무엇보다도 오락실판이 PC판보다 어렵고 전략 전술을 근본적으로 다시 짜게 만드는 원인은.. 바로 근거리 공격 때문입니다.
PC판은 모든 몬스터들은 주인공이 너무 바싹 붙어 있으면 일단 뒤로 물러나서 일정 거리를 확보한 후 공격합니다. 게다가 다른 AI가 전반적으로 무척 멍청하기 때문에, PC판으로는 한 대도 안 맞고 엔딩 보는 것도 가능합니다.

하지만 오락실판은 그렇지 않으며 얄짤없이 근거리에 있는 주인공은 곧바로 공격합니다. 매우 위험합니다. 게다가 큰 몬스터인 대머리 아저씨나 칼 든 기사는 주인공을 내던지기까지 하며, 원거리에서도 공격 성향이 더욱 짙습니다. 용 없이 기사 두 명을 피해 없이 상대하는 건 거의 불가능에 가깝습니다. (제가 보기엔) 큰 몬스터를 향해 날라차기를 해도 실패하고 반격 당할 확률이 훨씬 더 높고요.

다만, 오락실판에만 존재하는 필살기가 있더군요(마법 쓰는 것 말고). 뛰면서 위로 점프한 후, 칼을 아래로 내리찍기. 이게 데미지가 굉장히 커서 작은 몬스터는 한 방에 바로 골로 보내더군요.
PC판의 몬스터라면 100% 저게 성공일 텐데, 오락실판 몬스터는 그걸 피할 줄 압니다. PC판은 몬스터가 y축으로 왔다갔다 하는 걸 거의 볼 일이 없는 반면 오락실판은 y축으로 이동하여 필살 공격을 회피할 줄 압니다. 그래서 제일 밑으로 내려가서 회피를 못 하게 하고 때리면 성공률이 꽤 높습니다.

오락실판은 날라차기를 하다가 목표물을 맞으면 목표물이 힘을 받아 튕겨나가고 나는 추진력이 탁 떨어지기 때문에 타격감과 탄성을 느끼죠. 하지만 PC판은 목표물을 맞든 안 맞든 언제나 정해진 공식만큼 앞으로 나아갑니다. 기계적입니다. 오락실판은 도둑을 때려서 나온 물약병도 통통 튀지만, PC판은 그렇지 않습니다.

이런 것 말고도, 오락실판은 PC판에서 게임의 쾌감을 떨어뜨리던 그런 요인들이 없습니다.
가령, 열심히 때리고 한 몬스터를 집어 던지는 모션을 취하느라 uncontrollable한 도중에는 다른 몬스터가 나를 공격하지 않습니다. 저 경우를 따로 배려를 했다는 걸 단번에 알 수 있었습니다. PC판은 나도 반격을 당해 튕겨 나가고 잡혀 있던 몬스터도 같이 튕겨 나가는 어색한 상황이 벌어지죠.

난쟁이 도둑을 때리면 PC판은 완전 랜덤한 다른 위치로 도망가 버려서 일일이 쫓아다니며 또 때려야 하지만 오락실판은 원래 있던 곳에서 그렇게 멀리 나가지 않으며, 또한 도둑을 때리기도 훨씬 더 쉽습니다. 어지간히 날라차기를 해도 맞고, 불을 쏘는 용으로도 굉장히 쉽게 맞힐 수 있습니다. 도둑이 약병을 다 내 준 뒤에도 이따금씩 가만히 죽어 버려서 게임 진행을 더 못 하고 끝내야 하는 버그도 오락실판에는 전혀 존재하지 않죠.

또한 '해골 다구리'. 가끔 여러 해골들이 있는 상태에서 막다른 곳에 몰리면, 해골들이 나를 일어나서 반격할 틈도 안 주고 계속 점프 공격을 해서 결국 죽게 만드는 경우가 PC판에는 있습니다. 오락실판은 그런 식의 공격 패턴을 지니고 있지는 않거든요.
여러모로 PC판보다 더 신경을 쓰고, 쓸데없는 것 갖고 사용자를 짜증 나지 않게 설계가 돼 있다는 것을 알 수 있었습니다. 다만, 단거리 공격까지 틈을 조금도 안 주는 거는 너무 어렵습니다.

오락실용은 세 마리 정도는 죽고 엔딩을 봤습니다. 점수는 230점대, strength는 85점까지는 가 봤네요.

Posted by 사무엘

2010/01/11 10:14 2010/01/11 10:14
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/89

C++의 멤버 포인터

C++에는 pointer-to-member이라는 아주 기괴한 개념이 있다.

마치 일반 변수를 포인터로 가리키고 전역 함수를 가리키는 포인터가 있는 것처럼,
이 포인터는 포인터이긴 한데, 변수 포인터라면 특정 클래스(=구조체)에 대한 오프셋에 매여 있다고 볼 수 있으며, 함수 포인터라면 특정 클래스의 멤버 함수로 소속된 함수만 가리킨다는 특수성을 지닌다.

그래서 한 클래스 안에 프로토타입이 일치하는(리턴값, 인자의 개수와 type들) 여러 멤버 함수들이 있으면 그것들 중 하나를 가리켜서 특정한 한 함수를 if나 switch..case 없이 계속 가리키면서 호출하게 할 수 있다. 이걸 이용해서 얼추 다형성까지 구현할 수 있다는 것이다.

또한 한 클래스 안에 동일한 타입을 지닌 여러 멤버에 대해서 일괄적으로 초기화를 해 줘야 할 때, 멤버 함수를 가리키는 포인터를 써서 이 일을 아주 generic하고 수월하게 할 수 있다.
MFC에서 message map도 매크로를 파헤쳐 보면 응당 pointer-to-member를 써서 구현되어 있다.

C++에서 추가된 클래스 멤버 함수는 굉장히 묘한 존재이다.
사실, C에서도 구조체에다가 함수 포인터를 갖다 둠으로써 obj.func() ptr->func() 같은 문법 자체가 불가능한 것은 아니다. 그런데 이 경우 ()를 생략함으로써 해당 함수의 주소를 간단하게 얻을 수 있은 반면, C++ 멤버 함수는 그렇게 할 수 없다. 그 멤버 함수는 그 클래스의 '인스턴스'에 소속되어 있으면서 그 클래스의 크기에 영향을 주는 존재가 아니기 때문이다. scope이라는 개념이 존재하고 this 값을 기본으로 받는 것만 빼면 위상은 오히려 전역 함수에 더 가깝다.

아예 개체와 함께 함수 호출 연산자 ()를 줘서 확실하게 호출을 하든가, 아니면 &Class::Function과 같은 형태로 pointer-to-member 값을 얻어 와서 자기 타입에 맞는 pointer-to-member에다가 그 주소를 대입만 수 있다. 일반 함수 포인터와는 달리 이렇게 얻어진 값은 곧바로 함수 호출을 할 수 없으며, 반드시 그 클래스에 해당하는 개체가 있어야 한다. 개체 뒤에다 .* 이라든가 ->* 연산자를 붙이면 되는데, 이때 .*나 ->*은 *까지 붙어서 완전히 한 연산자 토큰이기 때문에 둘 사이에 공백이 들어갈 수 없다.

또 하나 주의해야 하는 것은 C++의 연산자 우선 순위이다. (obj->*pfnFunc)(함수인자)처럼 함수 인자 앞에는 반드시 괄호가 들어가야 한다. 또한 우리 클래스 안이라고 해도 ->*나 .* 앞에서는 this를 생략할 수 없으며 반드시 붙여야 한다. 여러 모로 문법부터가 기괴하다는 것이다.
이 pointer-to-member의 타입은 공식적으로 void (Class::*)(함수인자) 이라 불린다. 이때, ::와 *은 서로 독립된 토큰이다.

그런데 pointer-to-member하고 가상 함수가 서로 만나면 이거 정말 골치아픈 문제가 발생하고 만다. 둘 다 다형성을 위해 존재하는 기능이며, 둘 다 구현하기 위해서 컴파일러가 프로그래머가 모르게 암시적으로 몰래 하는 일이 상당히 많은 기능들이다. 하지만, 결론부터 말하자면 이 두 기능은 서로 연동해서 사용할 수 없다. 이게 무슨 말인지를 지금부터 설명하겠다.

A라는 클래스가 있고 f라는 가상 함수를 정의했다. 그 후 A로부터 상속 받은 B라는 클래스는 f라는 가상 함수를 또 오버라이드했다.

그 후 A의 포인터 pf에 어떤 값이 들어왔다. 얘가 가리키는 값이 실제로 A인지, 아니면 A의 파생인 B인지는 알 수 없다.
이때,

if( &pf->f == &A::f ) puts("pf 개체는 A 타입");
else if( &pf->f == &B::f ) puts("pf 개체는 B 타입");

와 같은 형태로, 이 개체에 소속된 가상 함수의 주소를 판단함으로써 그 개체의 원래 타입을 판별할 수 있을까? 마치 C 언어 구조체의 멤버로 들어있는 함수 포인터를 비교하듯이, 가상 함수와 pointer-to-member 주소를 이런 식으로 연계할 수 있을까?

그럴 수가 없다는 뜻이다.
일단 클래스 멤버 함수의 pointer-to-member 주소를 되돌리는 방법 자체가 pf 같은 동적 바인딩을 허락하지 않는다.

그리고 더욱 나쁜 사실은, &A::f와 &B::f의 값 자체가 실제로 확인해 보면 동일하다는 것이다!
어떤 A 타입의 포인터가 있는데, pointer-to-member를 이용하여 어떨 때는 강제로 A::f를 호출하고, 어떨 때는 일부러 B::f를 호출하여 기반 클래스와 파생 클래스를 구분하는 것 자체가 불가능하다. 한 클래스 안에서 프로토타입이 같은 여러 수평적 함수들을 구분할 수는 있으나, 부모와 파생 클래스 사이의 수직적 관계가 존재하는 가상 함수는 전혀 구분할 수 없다.

사실은 이것이 원래 의도했던 C++ pointer-to-member의 동작 스펙이기도 하다. 가상 함수와 일반 함수를 구분하지 않고 그 위 계층에서 동작하게끔 말이다.

C++에서 가상 함수가 어떻게 구현되는지 대충 아는 분들도 있겠지만,
가상 함수가 생기면 사실 해당 클래스에 가상 함수들의 포인터가 당장 쭉 추가되는 게 아니라, 해당 클래스를 나타내는 가상 함수 포인터 배열이 하나 생기고, 이를 가리키는 '포인터'가 하나 추가된다. 즉,

ptr->nonVirtual(...) ==> globalFunc(this, ...) 가 일반 함수라면, 가상 함수는

ptr->virtualFunc(...) ==> ptr->vtbl->pfn[n](this, ...) 처럼 전개된다는 뜻.

그런데 pointer-to-member 함수는 매 타입에 대해서 vtbl의 값을 저장하고 있는 게 아니다.

virtualFunc_stub(this, ...)
{
        return this->vtbl->pfn[n](this, ...)
}

가상 함수의 address란 바로, ptr에 대해 가상 함수 테이블을 뒤져서 실제 가상 함수를 호출해 주는 "껍데기 함수"의 주소로 정적으로 고정되는 것이다! &A::f이든 &B::f이든 가리키는 주소는 바로 저기가 된다는 것이다. 이 일을 컴파일러가 몰래 슬쩍 해 준다.

그렇기 때문에 pointer-to-member 함수는 함수의 프로토타입만 일치한다면 일반이든 virtual이든 전혀 구분 없이 함수를 가리킬 수 있으며,
(pp->*pfn)(); 와 같은 문장은

004010C8 8B CE            mov         ecx,esi
004010CA FF D3            call        ebx

가리키는 대상이 virtual이든 아니든 관계없이 위와 같은 두 명령으로 간단히 번역된다. 실제 가상 함수 호출은 저 껍데기의 내부에서 이루어지니까.
pp->SayA(); 처럼 대놓고 가상 함수를 호출할 때는

004010CC 8B 16            mov         edx,dword ptr [esi]
004010CE 8B 02            mov         eax,dword ptr [edx]
004010D0 8B CE            mov         ecx,esi
004010D2 FF D0            call        eax 

테이블을 참조하는 오버헤드가 해당 코드에서 바로 이뤄지는 것과 좋은 대조를 이루는 셈이다.

따라서 이 함수가 어느 가상 함수를 가리키는지는, 문서화되지 않은 컴파일러 꽁수라든가 어셈블러 같은 지저분한 방법을 동원하지 않고서는 알 수 없다는 것이 결론이 되겠다. pointer-to-member의 동작은 가상 함수의 영향을 받지 않는다.

그런데, 가상 함수는 그나마 이런 식으로 극복해서 일관성을 얻었다지만, 가상 상속, 다중 상속 같은 극악한 C++만의 기능과 마주치면(요즘 언어들은 채택도 안 하고 있는), pointer-to-member 구현의 복잡도는 그야말로 GG 치는 경지에 다다른다.

결국 자기가 가리키는 함수뿐만 아니라 기반 클래스처럼 그 클래스와 관련된 다른 정보도 들어가야 하기 때문에, machine word(통상 4 또는 8바이트) 단위 크기보다 크기가 더 커지게 된다! this 포인터도 막 왔다갔다 해야 하므로.
그런 클래스에서 멤버 포인터가 구체적으로 어떻게 구현되며 잉여 데이터가 어떻게 활용되는지는 본인도 잘 모르겠다.. -_-;; () [] * 가 막 뒤섞인 복잡한 타입을 바로 읽고 쓰는 것만큼이나 도저히 이해를...;;;

더구나, forward 선언만 해 놓은 클래스인 경우, 이 클래스의 pointer-to-member는 4바이트 크기로만 잡아도 될지, 아니면 더 커야 할지를 알 수 없기 때문에 일단 최악의 경우를 가정하여 엄청 큰 사이즈가 잡힌다. 같은 포인터가 클래스 몸체의 선언 전과 후에 계산되는 크기가 달라진다는 뜻이다. (차라리 몸체가 없는 클래스의 멤버 포인터는 크기를 계산할 수 없다고 컴파일 에러를 내뱉는 게 더 낫겠다 -_-)

pointer-to-member는 꼭 필요는 하지만 이렇게 지저분한 존재가 되어 있다.
C++ 다음 표준에서는 이것도 뭔가 문법이 바뀔 거라는 식으로 들은 것 같기도 한데 잘 모르겠다. 가령, 이제 true, false도 꽤 오래 전에 정식 예약어로 추가가 됐는데, 0말고 NULL 포인터만을 가리키는 nil 같은 키워드도 type-safety를 위해서라면 좀 있어야 않나 싶다. 사실, C++이 오버로딩이 가능해지면서 타입 구분 강화 쪽으로 개선이 많이 되어 왔으며, explicit도 type-safety 보장을 위해서 추가된 키워드이다.

차라리 함수 포인터는 껍데기 함수 만들지 말고 그 함수 실체만 바로 가리키게 하면 영 안 되려나?? 지금처럼 해 놓은 이유가 있는지 잘 모르겠다.

Posted by 사무엘

2010/01/11 10:13 2010/01/11 10:13
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/88

- 클래스 이름과 파일 이름이 반드시 일치함이 보장되니, 소스 navigation이 은근히 편하다. 그리고 각 클래스 내부에 static void main 함수만 구현해 주면, 그 클래스만 용도를 테스트하는 프로그램을 간단히 짜고 그 유닛 단위로 실행이 가능하니 무척 편하다.
- 클래스에 각종 명칭의 선언과 정의가 따로 구분되어 있지 않으며, forward 선언이라든가, 온갖 dependency 따지기, 재컴파일 같은 지저분한 튜닝이 자바에는 필요하지 않다. 링크 에러라는 개념도 자바에는 존재하지 않는다. ㅋㅋ

- 모든 오브젝트들에 무조건 RTTI 정보가 들어있어서 type을 알 수 있다.
- 프로그램이 뻗으면 자동으로 함수 호출 스택 목록과 줄번호가 다 뜬다.

물론, 자바의 장점들 중 구조적인 것 말고 프로그램 실행과 관련된 편의는, 대부분 C/C++에 비해 성능을 상당히 희생하고서 얻어진 것임은 의심의 여지 없는 사실이다.

그래서 남이 짠 코드를 분석하고 들여다보고 유지보수 해야 할 때, 자바가 적응만 잘 돼 있으면 생산성이 상당히 높겠다는 점을 인정한다.
C/C++은 정말 변태스러운 튜닝과 자유도를 추구하는 대신, 그 코드가 여러 사람의 손을 거치면서 무질서도의 증가로 이어진다면 maintenance 측면에서 재앙이 될 수도 있다. 복잡한 암호 같은 C++ 코드에서 메모리 누수 하나 찾아 보시겠는가?

C/C++은 각 기계의 특성을 일일이 수용하고 존중해 준다는 점에서 이식성이 높다. 조건부 컴파일, 공용체, 포인터, 온갖 복잡한 컴파일러/링커 옵션 등등등...
하지만 자바나 C#급 언어는 그런 기계스러운 건 숨기고 포인터를 감싸고 특히 C/C++의 야생마스러운 면모를 적당히 제어하면서, 그 언어를 돌리는 플랫폼 자체를 이식성 있게 여럿 만듦으로써 이식성을 추구한다고 볼 수 있다. (자바 가상 머신, 닷넷 프레임워크 등) 즉, 언어의 근본 설계 철학과 용도가 다르다.

C++은 virtual로 지정된 놈만 가상 함수인 반면,
자바는 final이 지정되지 않은 다른 모든 놈이 기본으로 다 가상 함수이다.
가상 함수의 구현 비용이 만만찮은데, 이런 발상의 전환이 어떻게 이뤄졌는지 대단하다.

C/C++은 static이 무척 의미가 다양한 키워드인데 이는 자바도 어느 정도 이어받고 있다.
그런데 자바에만 있는 키워드로 final이 있는데, 얘가 일종의 const 역할도 하고 비가상함수임도 나타내니 문법이 무척 기발하다.

끝으로, 자바에서 아쉬운 것을 꼽자면,

- 조건부 컴파일이 안 되고, 특정 코드를 #if 0 ... #end if 이렇게 간편하게 막아 버리는 방법이 없다. -_-
- C 스타일 %d, %s로 간편하게 스트링을 포맷하는 방법이 없나? (디버그 로그 찍을 때 필요)

- 나는 자바로 범용적인 swap 함수를 어떻게 만드는지 아직도 전혀 모른다.
int a=3, b=5; swap(a,b); 이렇게 할 수가 없나? (자바에는 템플릿도, 매크로 함수도 없으며, int는 무조건 call by value로 전달됨)

Posted by 사무엘

2010/01/11 10:11 2010/01/11 10:11
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/87

비주얼 C++ 2010 외

※ auto keyword

지금까지 signed와 더불어서 C/C++의 주요 '유명무실' 사문 예약어이던 auto가 비주얼 C++ 2010에서는 완전히 새롭게 거듭날 예정이다.
auto는 그 변수에 초기화해주는 값이 나타내는 타입을 그대로 부여해 준다. 즉,

int a=5; (...) auto b=a; 라면 b는 int형이 되고
vector<int> arr; auto itor=arr.begin(); 이라면 itor의 타입은 vector<int>::iterator 가 된다.

그래서 말 그대로 auto는, 뒤에 나오는 대입값을 보고 자료형을 '자동'으로 알아서 판단하라는 의미가 된다.
이런 게 언제 C++ 표준으로 상정됐는지는 모르겠는데, 기능과 문법을 만들어 놓은 방식이 정말 기발하고 참신하기 그지없다.
이 키워드 하나가 수많은 번거로운 자료형 하드코딩 타이핑 내지 typedef들을 예방해 주리라 기대된다.

당연한 말이지만 auto 자체는 sizeof 같은 연산자의 피연산자가 될 수 없다. 또한 auto가 무슨 비주얼 베이직의 variant 타입처럼 아무 자료형이나 수시로 집어넣을 수 있는 타입을 의미하지는 않는다.
auto 형으로 선언되는 개체나 변수는, 마치 참조자를 선언할 때처럼 반드시 선언과 동시에 값 대입 내지 초기화가 되어야 할 것이다.
C++은 함수의 인자 개수와 인자의 자료형으로만 오버로딩을 구현하지, 함수의 리턴값으로 오버로딩을 구현하지는 않기 때문에 이런 기능을 모호성 없이 구현할 수 있는 것이다.

이 외에 다른 이상한 C++ 문법도 도입되고 C++ 라이브러리 쪽에도 무슨 변화가 있는데 그건 잘 모르겠고,
프로젝트 파일 포맷이 또 바뀔 예정이라고 한다.

※ 비주얼 C++ 프로젝트 파일

여기서 잠깐 역사 수업. 비주얼 C++ 프로젝트 파일의 역대 계보는 다음과 같다.

1기 *.vcp는 16비트 1.x 초창기 시절에 쓰였다.
2기 *.mdp는 32비트 통합 IDE인 Developer Studio 초창기 시절인 4.x에서 쓰였다. 세월이 세월이니만큼, 1기와 2기는 지금은 거의 찾을 수 없는 전설의 파일 포맷이 돼 있다.
3기 *.dsw와 *.dsp는 드디어 여러 프로젝트를 한데 묶어 관리하는 워크스페이스라는 개념이 도입된, 5와 6 두 버전에서 쓰였다.
그 후 닷넷급이라 할 수 있는 비주얼 C++ 200x에 가서는 4기인 *.sln, *.vcproj 방식이 등장했다. 비주얼 베이직/C++/C# 모든 언어들의 프로젝트 사이에 일관성이 생겼으며 워크스페이스라는 명칭이 솔루션으로 바뀌었다. 그리고 프로젝트 파일은 내부 구조가 XML 형태로 바뀌었다.

이제 프로젝트 파일의 내부 구조가 또 바뀔 일은 없을 거라고 생각했는데 2010에서는 vcxproj라고 또 바뀔 거라고 하니 이게 웬일?
설마 MS 오피스 2007처럼 또 zip 압축을 하는 건 아닌가 모르겠다.
하지만 개발툴의 프로젝트 파일은 소스 버전 관리의 편의성 같은 이유도 있고 해서 다들 plain text 방식으로 저장하지, 바이너리 방식을 쓰지는 않을 텐데 말이다.

더구나 개발툴의 버전이 바뀔 때마다 각종 컴파일러 옵션들은 시시때때로 추가되거나 삭제, deprecate되기도 하기 때문에, 이런 프로젝트 파일들은 유연성, 하위 호환성, 확장성을 최대한 유지하는 게 짱이다. 즉 plain text가 정답이라는 뜻이다.

경험상 비주얼 C++ 2005하고 2008은 프로젝트 파일 포맷이 거의 차이가 없다.
sln과 vcproj 파일 앞줄에 있는 버전 번호만 1 줄여 주면, 2008로 만든 프로젝트도 2005에서 아무 문제 없이 바로 읽어들일 수 있다.

※ 비주얼 C++ 6.0이 나온 지 좀 있으면 벌써 12주년

얘기가 여기까지 왔는데 또, 애증이 교차하는 비주얼 C++ 6.0 얘기를 하지 않을 수 없다.
무려 11년 전엔 1998년에 출시되었고 아직까지도 애용되고 있는 소프트웨어로는 스타크와 더불어 양대 산맥이 아닌가 생각된다.
너무 구닥다리가 되어 외형이 후져 보이고(비록 당대로서는 MS 오피스 97 스타일의 새끈-_-한 UI였지만),
64비트 지원 안 되고 최신 하드웨어 기술 및 C++ 표준이 반영 안 돼 있는 것 자체만 빼면 정말 잘 만든 물건이긴 하다.

가끔은 6.0 특유의 그 클래스 마법사가 그리워질 때도 있다.
MFC는 이제 <날개셋> 타자연습 소스 열어볼 때 말고는 별로 접할 일도 없어졌구나.

그 비주얼 C++이 곧 있으면 연도도 2010이고 버전 번호로도 10.0이 나올 예정이다. 감회가 새롭다.
참고로 비주얼 C++ 2005는 2005년 하반기에 나왔지만 2005라는 타이틀이 붙은 반면,
2008은 비슷한 2007년 하반기에 출시됐지만 1이 더해진 2008이라는 타이틀이 붙었다.

※ 여자 프로그래머

7월 1일.. 경의선 전철 개통, 용인-서울 고속도로 개통, 거기에다 비정규직법 상정 2주년-_- 등 여러 굵직한 일이 많았는데, 나도 이제 병특 끝난 지 1주년이 됐다.
그리고 직장 생활 경력이 3년을 넘어갔다. 최소한 말단 신입사원 딱지는 떼는 짬밥이 됐고, 주임/대리급을 바라보는 신분이다. 하지만 옛날 회사나 지금 회사나 여전히 제일 나이가 어리고 내 밑으로 신입을 대한 적이 없으니, 예나 지금이나 늘 막내이다.

그리고 내가 지금까지 다닌 회사에서 여자 개발자를 본 적은 전혀 없다.
IT 회사라고 해도 여직원 하면 오로지 디자인, 기획 아니면 회계/경리이다. 개발자가 여자인 경우는.. 글쎄다.
하지만 외근 나간 연구소에서는 그래도 비주얼 C++ 띄워 놓고 코드와 씨름하고 있는 여자분들을 주변에서 여럿 볼 수 있어서 인상적이었다.

차라리 학교에 있을 때는 그런 모습을 심심찮게 볼 수 있었다. 내가 나온 학교는 공대 중에서 성비가 상당히 균형 잡힌-_-;; 편에 드는 곳이었으며, 전산과 역시 예외가 아니었기 때문이다.
하지만 나는 학교 시절엔 과 친구들하고 거의 어울리지 않고 동아리 같은 것도 안 하고 지냈기 때문에 그런 학우들로부터는 이렇다할 '임팩트'를 받지 못했다.

여직원하고 "아.. 그 땐 이런 함수를 쓰면 돼요"
"이 클래스는 여기서 상속 받았고 이 가상 함수는 이런 용도로 오버라이드하면 됩니다. 대략 이렇게 구현을 하면 어떨까요?"
"아 그렇게 생각해 보니 이렇게 짜면 버퍼 오버런이 우려되고, 멀티스레드 환경에서는 잠재적으로 또 문제가 있겠군요"
이런 이야기를 나눈다면.. 졸라 감회가 새로울 것 같다. 태어나서 이성하고 그런 얘기는 한 번도 한 적이 없으니까. =_=

하긴, 부부 교사도 있고,
커플이 나란히 코레일에 입사하여 기관차 운전 연수를 받던 부부 기관사도 봤는데, (촬영 당시 곧 결혼 예정이라고 쓴 걸 봤음)
부부 개발자라고 없을 이유는 없으리라 생각한다. -_-

Posted by 사무엘

2010/01/11 10:10 2010/01/11 10:10
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/86

예비군 갔다 온 소감 (2009/7/8)

본인, 병특 만료한 지 그래도 1년이 경과했고, 예비군 1년차 동미참 훈련에 들어갔다. 첫 날 갔다 온 소감을 분야별로 옴니버스 형태로 정리해 본다.

  총평: 합법적으로 꽤 오래 회사 빠질 구실 생겼다고 그저 꿀빨고 좋아만 할 사항은 아니다. =_=;; 훈련 자체야 하나도 안 빡세며, 조교나 교관은 그냥 친절한 후배 내지 동네 아저씨인 거 맞다. 하지만 오지로 왔다 갔다 하면서 군화 군복 차림으로 장시간 땡볕에서 고생하고 평소에 안 하던 꽤 긴 거리 도보-_-를 하는 거.. 본인은 그것만으로도 상당히 고생스러웠다. 갔다 오니 피곤해 죽겠다.

  훈련 교장의 접근성: 퇴소 명령이 떨어진 후 집까지 도착하는 데 1시간 반이 걸렸다. 집에서 그렇게 멀지 않고 전철+버스 연계가 괜찮으며 부대 바로 앞에 버스 정류장이 있는 것은 좋았다. 하지만 부대 내부의 집결/퇴소 장소에서 정문까지 가는 게 걸어서 15분 ㅜㅜ! 자가용 내지 수송 버스(물론 있었으나, 비싸고 어차피 집 근처까지 바로 안 감)가 아쉬운 순간이었다.

  현역 훈련병과 예비군의 차이: 물론 군기가-_- 들어간 정도라든가 조교/교관들이 대하는 태도 같은 것도 천지 차이이지만, 내게 질문한다면 외형상으로 가장 두드러지는 차이란 바로, “머리 길이와 담배”라고 요약하겠다. 이거 뭐 단순 80년대 장발 스타일을 넘어서, 뒤에서 보면 여자처럼 보일 정도로 치렁치렁 긴 머리를 묶은 예비군 아저씨도 있었으니 원! 현역 입대하는 훈련병이라면 상상도 못 한다.

  다른 아저씨들하고는: 말 한 마디도 안 했고 할 일도 없다. 서로 아는 사이인 예비역들은 같은 지방에서 자란 친구이기라도 한 걸까?
사실 근본적으로 나는 내 고향이 아닌 지역으로 부대 지정을 받았으니 이런 곳에서 아는 사람을 찾을 수도 없다. 차라리 2002년 신검 받을 때는 그때 중/고등학교 동기놈하고 얼굴 마주치기도 했는데 말이다.
작대기 네 개짜리 예비군 병장이 대부분이고, 가끔 해병대 출신 예비역도 보였는데 이들은 명찰이 빨간 배경 노란 글씨인 게 인상적이다. 나처럼 병특이나 공익 출신은 상의 주머니에 계급 작대기가 찍혀 있지 않다.

  담배: 우리나라의 내 또래 남자들의 평균 흡연율을 짐작케 할 정도였다. 현역 입대 훈련소라면 상상도 못 하겠지만, 일과 끝나고 조금만 틈만 생기면 예비군 아저씨들은 대부분 담배 뻑뻑 피워 댄다. 교관들도 “담배 피우는 분들은 건물 아래 말고 밖에서 피우세요” 이런 주의나 주는 정도이다.
예비군들이 머물렀던 훈련 교장 인근은 온통 담배꽁초 투성이가 되었다.

  손전화: 주위 아저씨들은 무지막지하게 들고 다닌다. 이건 반입을 원천 금지하는 게 사실상 불가능이니, 교관들도 사실상 묵인해 주고, 훈련 중에 대놓고 전화질만 하지 말라고 주의를 주는 수준이다. 사실 예비군 가 보면 기다리느라 보내는 시간 엄청 많은데, 심심하면 전화기라도 만지작거려야 직성이 풀리긴 한다. 하지만 나는 뭐 딱히 전화할 상대도 없고, 갖고 다니기가 거추장스러우니 앞으로도 손전화를 갖고 가지는 않을 것이다.

  점심 식사: 인터넷 상으로는 고작 4000원짜리 밥이 요 따위라니, 도대체 예비군 식사 납품 업체는 차익을 얼마나 챙기는지 모르겠다는 식의 악플이 엄청 많았지만 오늘 여기서 먹은 밥은 괜찮은 편이었다. 국은 육개장 내지 갈비탕 컨셉이었고, 더 달라고 하면 무료로 꽤 푸짐하게 많이 주기도 해서 잔반 하나 안 남기고 잘 먹었다. 밥에 관한 한은 나는 불만 없었다.

  총: 예비군한테는 이거 뭐 2차 세계 대전 내지 6 25 때나 쓰였다는 카빈 소총이 지급됐다는 루머-_-도 있었지만, 내가 간 교장에서는 오로지 M16 소총이었다. 논산 육군 훈련소에서도 만져 본 총이어서 친근했지만 사격 때는 정말 정신없었다. 물론, 폼으로만 들고 다니는 개인 소총으로 총 쏜 건 아니고, 사격은 사격장에 비치되어 있는 실제로 동작-_-하는 별도의 총으로 한다. ^^;;
물론 거기서 근무하는 현역들은 여전히 K2 소총 쓰더라.

  정신 교육: 앞으로 현역들의 복무 기간이 더 짧아지고 저출산 때문에 인구 갈수록 적어지면 예비군의 중요성이 더 커지게 되며, 여러분들이 국가 안보의 초석이라고 띄워 주는 멘트는 꽤 많더라. 그 외엔 북한이 우리의 주적이며 과거에 이렇게 나쁜짓 많이 저지르고도 전혀 반성의 기미가 없다는 식의 레퍼토리임. ㄱㅅ 그나저나 입소식 때, 현역 조교들도 앞으로 제대 후 우리처럼 될 애들인데, 걔네들 보기에 부끄러움이 없게 훈련에 임해 달라고 말한 연대장의 훈화가 좀 마음에 와 닿았다. =_=;;
참고로 정신 교육 때는 사람들 진짜 거의 다 잔다.

여기까지는 좀 평범한 내용이었고, 지금부터가 좀 썅소리 나오는 내용.. -_-

  날씨: 정말 증오로 죽이고 싶었다. ㅜㅜ 별로 덥지도 않았고 섭씨 20도 후반 정도의 평범한 흐린 날 같았는데 땀이 왜 이렇게 분수처럼 솟구치는지! 이미 오전이 채 가기 전에 온몸이 땀으로 샤워를 했다. 땀으로 젖은 손은 끈적끈적. 한번 어디 걷고 나면 몸의 기력이 싹 빠지는 느낌이었고, 강당에서 엎드려서 눈 좀 붙였다간 땀이 눈으로까지 들어갈 정도로 흘렀다.
햇볕은 별로 나지도 않은 거 같았는데 결국 팔뚝은 약간 벌겋게 타서, 손목시계를 찬 부위와 나머지 부위가 색깔이 다르게 보일 정도가 됐다. 어쨌든 날씨에 관한 한 최악이었다. 참을 수 없는 찝찝함!

  갈증과 피로: 훈련 자체는 예비군 특유의 정말 얼렁뚱땅 야메였음에도 불구하고, 집에 도착하자 녹초가 됐다. 술 좀 마셔서 알코올 독기가 몸에 퍼진 상태도 아닌데, 다리가 이렇게 저리고 쑤신 건 참 오랜만에 겪어 본다. 2년 전 훈련소에서 행군하고 나서도 저랬나? =_= 내가 체력이 꽝이어서 그런 것도 있겠지만 .. 정말 아무것도 하기 싫고 멍하고 짜증만 날 지경.
그리고 갈증. 내일 갈 때는 손수건(땀 닦으러)하고 사제 물병으로 물을 최소한 1리터는 꼭 챙겨 가야겠다고 굳게 다짐을 했을 정도로 제대로 고생했다. 너무 목이 말라서 집에 도착하자마자 물, 우유 등으로 거의 2리터 가까이를 비웠다. (음료수 사 먹고 싶지는 않아서. -_-)
그나마 집에서 싹 샤워하고 속옷 다 갈아입고 에어컨 바람 쐬면서 쉴 수 있었으니 망정이지, 동원(2박 3일 외박)이었으면 정말 자살했겠다. =_=;;

  증오로 죽이고 싶은 전투화: 내 발 상태를 엉망진창으로 만들고, 그 널널한 예비군 훈련을 극기 훈련으로 바꾼 일등공신이었다. 도대체 재질이 궁금하게 느껴질 정도로 까끌까끌 배긴다고 해야 하나? 결국 고무링이 닿는 발목에는 긁힌 흔적이 남았고, 양발 모두 발뒷꿈치는 완전히 까져 버렸다. ㅆㅂ~  사람 피부 껍질을 벗긴다는 게 얼마나 고통스러운지 체험했다. 발이 그렇게 아프니 뛰지도 못하고 오르막이나 내리막 걷는 것도 힘들고 엉거주춤 걸어야 했다.
이거 때문에 샤워도 제대로 못 했다. 가죽이 벗겨진 발뒷꿈치로  물이 흘러들어가자 “Oh no~” ㅠ.ㅠ
발도 발이지만 양말도 굉장히 무리를 많이 받았을 텐데, 이렇게 한두 번 신은 양말은 곧 발가락이나 뒤꿈치 쪽에 얼마 못 가 펑크가 날 것 같다. 이거 군화 뒷부분에다가 솜이나 휴지 같은 거라도 잔뜩 집어넣어야겠다.

이 짓을 금요일까지, 그리고 월요일에도 해야 한다. 발도 그렇고 팔뚝, 그리고 총을 메었던 오른쪽 어깨까지 벌건 자국이 생겨 있다.. 벌써 side effect가 꽤 크다.. ㅜ.ㅜ
빌어먹을 전투화는 무슨 일이 있어도 손을 좀 봐야 되는데 막막하구나.

동미참 교육은 금요일이 끝이지만, 월요일엔 지난번에 경조사 때문에 못 간 전반기 향방 작계 보충 교육을 받게 된다. -_-;;
집에는 회사 다닐 때보다야 일찍 들어왔지만, 무척 피곤하고 자기도 일찍 자야 하기 때문에 시간이 그렇게 많이는 못 난다. 그래도 동원보다는 동미참이 낫다. ㄱ- 부하 직원이 예비군인 회사의 생각은 이와 좀 다르겠지만.

Posted by 사무엘

2010/01/11 10:07 2010/01/11 10:07
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/85

※ JAL123 (1985년 8월 12일)

단일 항공기 추락 사고로는 최다 사망자가 나온 최악의 항공 사고로 손꼽힌다. 승무원 포함 탑승객 524명 중 520명 사망. 맨 뒤에 타고 있던 여성 4명만 생존. =_=
가장 먼저 드는 의문은, 아니 그때 지금 같은 초대형 에어버스급 항공기가 있었던 것도 아닌데, 도대체 무슨 500명이 넘게 사람이 몰살이냐? 비행기가 무슨 지상의 민간인을 덮치기라도 했냐는 것이다.
하지만 그렇지는 않다. 비행기는 산중턱에 추락했으며 희생자는 모두 비행기 탑승객 맞다.

여기에는 일본 특유의 짠돌이 근성이 한몫 기여했다.
일본이 어떤 나라인가? 전철만 봐도, 승객을 짐짝 취급하는 정도가 한국보다 더하다. 안 그래도 작은 협궤 전동차에 승객들이 터져나가다 보니 출퇴근 시간엔 승강장 길이보다 더 긴 열차, 한 량에 문이 우리나라처럼 4개가 아니라 6개인 열차, 아예 좌석이 없이 모든 승객이 서서 가는 열차처럼 별 게 다 다닌다.

사고기는 물론 보잉 747 대형 항공기이다. 원래 정원은 300명인데, 당시 경제 호황에다 명절 특수 덕분에 수요가 넘치는지라, 퍼스트/비즈니스를 없애고 모든 좌석을 이코노미로 개조하여 정원을 500명이 넘게 늘리고, 그 큰 비행기를 국내선에다 투입했다. 그렇다, 이 비행기는 도쿄에서 출발하여 오사카로 약 4, 50분 남짓한 시간만에 날아갈 예정이던 단거리 국내선이었다.

사고기에 크리가 터진 것은, 이륙 12분 후 거의 순항 고도에 진입했을 즈음에, 꼬리날개 부분이 바깥과 기내의 기압차를 견디지 못하고 폭발음과 함께 파괴되고부터였다. 이건 비행기에서 마치 배의 조향타, 사람 귀의 반고리관과 같은 부위인지라 비행기가 중심을 잡고 상하좌우 조향을 하는 데 반드시 필요하다. 조작은 사람의 힘만으로는 하기 어렵기 때문에 마치 자동차의 파워 스티어링처럼 유압 동력의 도움을 받아 행하는데, 이 오일도 다 유출되고 비행기는 한 마디로 엔진만 작동할 뿐 전혀 조종을 할 수 없는 상태에 빠지고 만다. 객실과 외부가 뚫려 버려서 산소 마스크가 내려왔으며, 그럼에도 불구하고 몇몇 승객은 산소 부족으로 인해 의식을 잃기도 했다고 한다.

사고기는 좌우로 들썩들썩거리면서 일반적인 착륙 속도의 수 배가 넘는 속도로 급강하하다가, 내려가는 과정에서 스스로 또 양력을 얻어서 붕 뜨고, 또 급강하를 지상과 완전히 충돌할 때까지 계속 반복했다. 삼각 함수처럼 진동했다는 소리인데, 뜨고 내리는 그 고도 진동의 폭은 가히 수 km는 됐다고 한다. 이렇듯 이 비행기는 바로 땅으로 자유 낙하를 한 게 아니다. 꼬리날개가 날아가 버린 후, 이 짓을 완전히 추락할 때까지 거의 3, 40분간 지속하면서 서서히 실속(stall) 상태에 빠졌고 평균 고도는 낮아져 갔다. 그러니 들썩거리는 비행기 안에서 승객들은 극도의 어지러움과 공포에 떨어야 했으며, 일부는 여권에다 유서를 쓰기도 했다. 물론 엄청난 진동 때문에 글씨는 완전 꼬불꼬불 제멋대로였다.

사고기의 조종사에 대해는, 그런 패닉 상태에서 비행기를 최선을 다해 그 시간 동안만이라도 조종한 게 대단했다는 평도 있고, 기장이 이미 산소 부족으로 인해 잠시 맛이 가서 정상적인 대처를 못 했다는 평도 있다. 어쨌든 한번 실속 상태에 빠진 비행기는 모두의 기대를 저버린 채 아래로 곤두박질치기 시작했고, 머리 부분이 '/' 모양으로 아래를 향하면서 산에 거의 수직으로 충돌함으로써 비참한 최후를 마쳤다. 추락 직전 드디어 GPWS (대지 접근 경보 장치)에서는 수 차례 "왱왱 pull up!" 죽음의 경고음이 흘러나왔다.

사고기는 저녁 6시에 출발했고 사고가 났을 때는 이내 해가 떨어진 밤이 되었다. 사고 소식을 들은 일본 정부에서는 즉시 수색/구조 헬리콥터를 출동시켰다. 그러나 현장을 확인한 헬리콥터는 생존자가 있을 리가 없다고 속단하고, 날씨도 안 좋은 깜깜한 밤에 빽빽한 산의 중턱에 헬리콥터를 착륙시키기란 힘들다는 귀차니즘에 입각하여 단념하고 그냥 돌아가 버렸다! 그리고 구조 대원들도 산기슭에서 하룻밤을 그냥 묵고 만다. 최후 생존자의 증언에 따르면, 사고 직후엔 사실 4명 말고도 아직 숨이 붙어 있는 위급 환자가 여럿 더 있었다. 그러나 그들은 밤을 지새우면서 추위와 구조 작업 지연으로 인해 결국 죽고 말았다. 온몸이 쑤시고 꼼짝달싹도 하지 않는 상황에서 필사적으로 헬기 불빛을 향해 손을 흔들었건만..! 일본 정부의 큰 판단 실수였다.

다음날 아침 드러난 사고 현장은 참혹하기 그지없었다. 흙더미에 파묻힌 채 나뒹구는 사람 손발, 이목구비 형체가 싹 사라진 민얼굴을 한 사람 모양의 숯검댕까지만 말하겠다.
(뜬금 없는 이야기이다만, 성경 창세기 1:2에서 땅이 형체가 없고 비었다는 말은, 멀쩡하던 사람 얼굴이 저 지경이 됐다는 것과 정확히 같은 맥락이다. 이전 세상에 대한 심판과 파멸 뉘앙스이지, 중간 과정을 나타내는 게 절대로 아니다)

대놓고 엔진이 고장났거나 기내에서 화재가 발생한 것도 아니고, 비행기가 뒷부분이 그렇게 망가져서 저렇게 서서히 추락하는 것은, 항공 역사상 무척 괴이하고 드문 사례였다. 그렇기 때문에 사건을 수사한 경찰과 항공 기술자들은 처음엔 무척 의아해했다. 그런데 진짜 원인은 사고기의 과거 내력에 있었다. 이 비행기는 7년 전 1978년엔 다 도착해서 착륙하던 중에 기수를 너무 높게 들어서 \ 뒷부분이 활주로에 긁히는 사고가 난 적이 있었다. 그때도 승객이 어마어마하게 많이 타서 비행기는 무거운 상태였고, 질량이 큰 항공기에게 조금이라도 더 큰 공기 저항을 주어 착륙 시 신속하게 속도를 줄이게 하려면 기수를 좀 높게 치켜세우면서 착지할 필요가 있었다. 그리고 이게 화근이었다.

비행기는 운항 종료 후 즉시 수리를 받아야 했다. 하지만 매우 critical한 부품인 뒷부분 벌크헤드의 정비는 일본 항공사가 자체적으로 할 능력이 없었기 때문에 항공기 제조사인 미국 보잉 사에 의뢰를 해야 했다.
그런데 최소한 두 줄로 땜질을 해야 하는 곳을 보잉 사에서는 한 줄만으로 대충 때웠다고 한다. 이것이 나중에 금속 피로도의 증가로 인한 파손으로 이어졌고 결국 비행기의 추락을 야기하고 520명의 승객의 목숨을 앗아갔다.

오랜 기간에 걸친 재판 끝에 사고 원인이 보잉 사의 수리 잘못으로 결정이 내려졌기 때문에 보잉 사는 상당한 거액의 보상금을 일본 측에 지불해야 했다고 한다. 전해지는 일화에 따르면 보잉 747를 처음으로 설계했던 기술자는 자기 회사 직원의 정비 불량 때문에 내가 설계한 비행기가 추락해서 사람들이 이렇게 많이 죽은 것에 통한을 감추지 못했고, 별로 책임이 크지도 않은 일본 항공 측의 한 비행기 정비사는 숫제 자살까지 했다고 한다. 무슨 큰일이 터지면 혼자 책임 다 뒤집어쓰고 희생양으로 자살하는 관행이 통용되고 있는 일본다운 스타일이다. 그렇지만 한편으로, 또 일방적으로 보잉 사만 나쁜놈으로 만들기에는, 그 부실한 벌크헤드가 왜 무려 7년이란 시간 동안은 별 문제가 없었는지에 대해 의문을 품는 사람도 있다.

이 사고를 계기로 전세계 항공업계는 아무리 대형 항공기라 해도 정원을 초과해서 승객을 태우지는 않게 됐다. 비록 이 사고의 직접적인 원인이 정원 초과는 아니었지만, 그래도 한꺼번에 너무 많이 태우고 가다가 사고라도 한번 났다가는 정말 너무 참혹한 올킬이기 때문이다. 그러나 요즘은 500명 이상급의 초대형 항공기가 다시 등장하고 있는 추세이다.

※ 테네리페 참사 (1977년 3월 27일)

잘 알다시피 비행기는 하늘을 날아다니는 3차원 교통수단이다. 그런데 두 비행기가 공중에서나 활주로에서나 서로 충돌할 일이 과연 있을까?
비행기는 단위 거리당 사망자 수로만 보면 자동차보다 월등히 안전한 교통수단이다. 더구나 요즘 같은 관제 시스템 하에서 추락도 아니라 비행기끼리 어이없게 충돌하기란, 그야말로 철길에서 열차가 정면 충돌할 확률 내지 가다가 벼락에 맞아 죽을 확률보다도 더 낮은 게 사실이다.

하지만 스페인 령 카나리아 제도 테네리페 섬의 로스 로데오 공항의 그 날은 그렇지 않았다. 대부분의 항공 사고가 자연 재해나 인재 등 단일 원인으로 인해 발생하는 반면, 이 사고는 하필 정말 "재수 옴붙었다고밖에" 볼 수 없을 정도로 최악에 최악의 가능성만 골라서 벌어지는 바람에 사상 최악의 최다 사망자 항공 사고가 터지고 말았다. 활주로에서 전속력으로 이륙 중이던 네덜란드 소속 여객기와, 이륙하려고 택싱 중이던 팬암 소속 여객기, 이렇게 보잉 747 두 대가 정면 충돌하여 두 비행기에서 총 무려 583명이 목숨을 잃은 것이다. (참고로 아까 JAL123기 사망자 520명, 삼풍 백화점 참사 사망자 501명)

정말 지지리도 운이 없었다. 로스 로데오 공항은 비좁고 한산한 '삼류(?)' 지방 공항이며 사실 보잉 747 급의 대형 항공기를 제대로 취급하기가 버거운 형편이었다. 사고를 당한 네덜란드 KLM기와 미국 팬암 기는 원래 거기에 갈 예정도 아니었으며, 착륙하려던 라스팔마스 공항에 테러 위협 경보가 들어오는 바람에 임시로 저 공항에 가게 된 것이다.

하필 그 시각, 날씨도 엄청 흐려지고 짙은 안개가 앞을 가려서 관제탑에서 활주로 전체 모습을 식별할 수가 없어졌다.
거기에다 비행기 조종사와 관제탑 사이에 같은 영어를 쓰고도 서로 말귀를 제대로 못 알아들었다. (전에 김 재주 님께서 영국 영어와 미국 영어에서 동사 table 의미 차이에 대해 지적한 것처럼)
KLM 기 기장의 멘트는 "이륙할 예정이다(의도한 뜻) / 이륙 준비 끝났다 (관제탑이 알아들은 의미)"로 의미가 서로 엇갈렸다.

이에 대한 관제탑의 회신은 "좋다. (2초간 쉬고) 이륙 허가를 곧 내리겠으니 기다리고 있어라"였는데, 뒷부분 멘트는 팬암 기 기장이 보낸 "안 돼. 우리가 아직 활주로에서 택싱 중이다!"와 겹쳐서 KLM 기로 제대로 전송이 되지 않았다.
"우린 이륙 준비 끝났다 / 좋다. 이륙 허가가 떨어질 때까지 좀 기다리고 있어 봐라" 가
"우린 이륙할 예정이다 / 좋다, 할 테면 해라" 로
의미가 순식간에 와전되고 만 것이다!

안개 때문에 KLM 기와 팬암 기, 관제탑 모두 상대편 비행기의 존재를 제대로 파악하지 못했으며, 일요일이라 관제탑엔 직원도 평소보다 적었고 지상 관제 레이더는 동작하지 않는 상태였다...;; 그리고 팬암 기는 지시받은 진입 지점을 안개 때문에 놓쳤지만, 돌아가기엔 귀차니즘에 입각하여 무시했다. 설마 별 일 있겠냐 하는 생각.

이륙 직전, 마지막으로 뭔가 수상한 낌새를 눈치챈 KLM의 부기장은 마지막으로 기장에게 "아직 팬암 기가 활주로에 있는 것 같은데요?"라고 반문했으나, 자신의 직속 상사이며 비행 시간 2만 시간이 넘는 KLM 최정예 조종사 기장의 "괜찮다" 한 마디에 그 의견은 묵살된다. 사실 KLM, 팬암 기 모두 기장은 베테랑급 고급 인재들이었다. 이로써 두 비행기가 충돌을 피할 마지막 기회마저 지나가고 말았다. 이 정도면 정말 재수 더럽게 없던 날이지 않은가?

결국 악몽 같은 일이 벌어지고 말았다. 상대방 비행기를 저 앞에서 발견해 버린 두 비행기의 조종사 입에서는 정말 "씨바! X됐다!" 소리가 나오고도 남았을 것이다.. 실제로 팬암 기의 조종실 음성 기록에는 "OMG! 저 개XX가 우리 쪽으로 돌진 중이야!"가 남아 있다..

택싱 중이던 팬암 기는 정면 충돌을 피하고 대피하려고 필사적으로 핸들(?)을 왼쪽 출구로 꺾었다. KLM 기는 이미 V1 (이륙을 중단할 수 없고 무조건 하늘로 떠야만 하는) 속도를 넘어서고 돌아오지 못할 강을 건너 버린지라, 필사적으로 하늘로 떠서 팬암 기를 타넘으려고 꼬리 부분을 손상시키면서까지 무리해서 기수를 들어올렸다. 하지만 완전히 피하지 못하고 KLM은 20미터 남짓 떴다가, 팬암 기의 윗부분을 박살내 버린 후 150여 미터를 타넘고 날아가다 추락했다. 그리고 두 비행기 모두 유출된 연료로 인한 맹렬한 화염에 휩싸였다.

하필 KLM은 이륙 직전에 급유를 마치고 연료도 5만 리터가 넘는 '만땅' 상태였다. 그것 때문에 무거워서 급하게 뜨기가 어려워진 것도 있었다. 그러나 불운의 KLM 항공기는 그 연료로 미처 날지도 못하고 오히려 그 연료 덕분에 홀랑 전소하고 말았으며 탑승객도 미처 탈출할 틈도 없이 전원 사망했다. 그 반면 팬암 기는 KLM 기가 비껴 간 중앙을 제외하고 맨 앞과 맨 뒤쪽에서 60여 명의 생존자가 나왔으며, 기장, 부기장 같은 승무원들도 살아남았다.

이 어이없으면서도 여러 변수가 복합적으로 AND로 작용하여 발생한 사고로 인해, 항공 규정은 크게 바뀌었으며, 무엇보다도 관제 중에는 의미가 명확한 표준 용어만 사용하게 되었다. 요즘은 특히 조종사들에 대해 요구하는 영어 실력도 크게 강화되고 있다. 작은 오해가 자칫 이런 식의 큰 항공 사고를 야기할 수도 있기 때문이다. 국제 민간 항공 기구(ICAO)는 2004년 9월, 한국 같은 비영어권 국가들에 대해, 영어 실력을 갖추지 못한 항공 종사자들을 현업에서 배제해줄 것을 요구하기까지 했다. 물론 여기에 대한 반발도 적지 않다.

따지고 보면, 당시 스페인 공항을 상대로 테러를 저지르고 싶었던 가상의 테러범들은 자신의 목표를 이런 사고로 인해 간접적으로 더욱 초과 달성한 것 같기도 하다. 자기를 피하려고 대형 여객기를 그 좁고 날씨 열악한 공항에다 몰아넣게 하고, 결국 저런 사고까지 나게 만들었으니 말이다.

참고로 두 항공기가 공중에서 거의 충돌할 뻔한 적이 놀랍게도 없지는 않다. 비행기라고 해도 날아다니는 항로는 정해져 있으며 여러 항공기가 한 항로를 공유한다면 사고의 위험은 언제나 존재하게 되는 법이다. 더구나 요즘은 수십 년 전과는 비교도 할 수 없이 많은 여객기들이 공중을 누비고 있다는 사실을 잊어서는 안 된다.
항공업계에서는 두 비행기가 불과 약 150미터 이내로만 근접해도 near-miss라 하여, 실제로 부딪치지 않았더라도 사고라고 간주한다. 전동차만 해도 추돌을 방지하려면 앞 차와 최소 200미터 이상 간격을 유지하면서 달리게 되어 있는데 그 빠른 항공기가 1초에 얼마나 멀리 나갈 수 있는지를 감안한다면, 저 정도만 해도 정말 큰 사고라고 간주할 수 있다.

순항 중인 항공기의 충돌이 우려되는 경우 관제탑에서는 한쪽 비행기는 고도를 높이고, 다른 쪽 비행기는 고도를 낮추어서 서로 비껴 가라고 명령한다(혹은 좌우 방향 틀기). 그런데 거의 충돌할 뻔한 상황이란, 의사 소통이 제대로 안 되어 두 비행기가 조치를 취하지 않았거나, 심지어 둘 다 동일하게 고도를 높이거나 낮추었을 때이다.

※ 결론

1. 비행기는 순항 중에는 좀체 사고가 나지 않는다. 사고는 대부분이 이륙, 착륙 과정에서 발생한다. 나는 옛날에는 착륙이 이륙보다 더 위험하다고 생각했는데, 젖먹던-_- 힘까지 내어 달려서 공중에 떠야만 하는 이륙도 만만찮게 위험하고 크리티컬한 순간이다. 개인적으로 이륙할 때의 그 비행기 엔진 소리와 떨림이 좋다. ^^;; 그런 의미에서 보면, 지난 6월 초에 발생한 에어 프랑스 비행기 사고는 멀쩡히 바다 위에서 순항 중이다가 갑자기 불의의 사고로 추락했다는 게 이해가 잘 되지 않는다.

2. 생명체는 아무리 심하게 다치더라도 최소한 뱃속의 음식물(연료??=_=)이 폭발하거나 각종 장기들이 누전, 합선되어 화재가 발생하지는 않는다는 게 존경스럽다. 전체 시스템의 한 고리가 끊어지는 순간에 와장창 조직 전체가 와해되는 게 아니라, 사실은 조직을 이루는 각 구성요소도 재귀적으로 별개의 미시적 시스템을 이루고 있고, 숨이 끊어지는 마지막 순간까지도 최대한 살려고 발버둥친다. 테란 건물과 저그 건물의 차이이며, 사람의 작품과 하나님의 작품의 구조적인 차이가 이런 게 아닐까 한다. ^^

Posted by 사무엘

2010/01/11 10:03 2010/01/11 10:03
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/82

원자폭탄, 기타 이것저것

20세기에 인간이 이뤄낸 위대한 과학 성과 중 하나는 원자력에 대한 지식이다.
학생들이 무려 고등학교나 대학 학부 수준에서 배우는 물리 교재에 chapter가 하나 추가될 정도로, 종전의 고전 역학과는 차원이 다른 지식이 추가되었다.
 
이를 바탕으로 인간은 예전에는 미처 상상도 할 수 없던 어마어마한 동력과 에너지를 얻을 수 있게 되었다.
원자력 발전은 태양에 전혀 근간을 두지 않고 에너지를 얻는 거의 유일한 방법이기도 하다.
20세기 이후에 시작된 찬란한 전기 문명은, 교류 전기의 실용화와 더불어 원자력 발전도 큰 일조를 했음을 부인할 수 없을 것이다.
 
그러나 원자력은 이내 핵무기라는 것을 만들었고, 국제 사회 정세를 완전히 다른 양상으로 바꿔 놓기도 했다. 예전에는 마음에 안 들면 애들처럼 서로 주먹으로나 툭탁거리고 싸우던 것이, 이제는 총을 손에 쥔 거나 마찬가지가 됐다는 소리이다.
 
현재까지 인류 역사상 자국민이 사는 도시에 핵무기를 맞아 본 나라는, 잘 알다시피 전세계에서 일본이 유일하다. 그것도 두 번이나 맞았다. 2차 세계대전의 말기에 유럽에 독일, 이탈리아는 다 항복하고 히틀러마저 제거됐는데 아직 일본만 유일하게 개기고 있어서 저랬다. '무시무시한 폭탄'을 맞고서야 정신을 차린 일본은 왕이 직접 서면으로 연합국에 항복하고, 자기 식민지들에 대한 권리도 일체 포기한다. 그래서 2차 세계대전이 정말 극적으로 끝나고, 우리나라도 일제로부터 해방된다.

아마 우리나라가 이렇게 당했으면 미국하고는 완전 철천지원수가 됐을 것이다. 방사선 피폭은 대물림까지 된다. 그 데미지의 레벨이 6 25 때 무슨 노근리 학살 같은 거하고 비교가 되나?
 
잘 알다시피 원폭은 1945년 8월 6일에 히로시마 상공에 먼저 떨어졌다. 의역 좀 하면 '귀여운 꼬마애'뻘 되는 길이 약 3미터, 무게 약 4톤쯤 되는 Little Boy 폭탄이 어지간한 여객기 고도와 비슷한 9.5km 상공에서 전투기로부터 투하되었다. 타이머를 걸었는지 뭐 어떻게 activate가 됐는지는 모르겠지만, 그 폭탄은 한참을 추락하다가 약 550m 상공에서 그대로 펑 터졌다.
수류탄도 그렇고 폭발물은 약간 공중에서 터져야 사방팔방으로 가장 큰 파괴력이 나오는 법. 이 원폭도 일종의 공중 폭발을 일으켰다.
 
곧바로 눈을 보호하기 위해 가글을 착용한 당시의 전투기 승무원들은 정말 경악할 만한 광경을 목격하게 됐을 것이다.
이것은 보어, 페르미, 천재 컴퓨터 과학자인 폰 노이만 등 이름만 들어도 아는 당대의 저명한 과학자들이 일본 본토 지형을 치밀하게 분석하고, 폭탄을 어디에서 투하하고 터뜨려야 가장 큰 피해가 나오는지까지 계산하여 진행한 프로젝트였다. 그 첫 실험 대상으로 일본이 선택된 것이다.
 
눈을 상하게 할 정도의 엄청난 섬광이 비쳤다가, 정신을 차리고 보니 어마어마한 불기둥과 무시무시한 후폭풍. 하늘이 어두워지고 그저 도미노처럼 힘없이 주저앉는 건물들. 영화보다 더 영화 같은 순간.
아마 핵실험 촬영 같은 것도 수십 킬로미터 떨어진 곳에서 zoom 무지막지하게 당겨서, 과장 좀 보태면 천체 활동 관측하듯이 해야 하지 않을까 싶다.

히로시마 시는 순식간에 폐허가 되었다. 죽은 사람 시체 사진을 보니까 거의 유대인 홀로코스트 내지 관동 대지진 학살 사진 수준이었다.
물론 그 며칠 전에 미국에서는 원폭 투하를 예고하고 어서 대피하라는 경고 전단지를 살포하긴 했었다고 한다.
하지만 대부분의 사람들은 사고방식이 "설마? 뭐 좀 위력이 큰 폭탄 떨어져 봤자, 늘 하던 대로 방공호로 대피하면 되겠지" 수준이었으며, 결국 원폭에 고스란히 당했다고 전해진다.
 
  (이런 예화는 기독교에서 복음 전할 때 자주 인용, 등장하기도 한다.)
 
나는 일본에 대해 완전 몸서리치게 증오하거나 딱히 피해 의식이 있지는 않다. 원폭 맞아서 도시 전체가 저렇게 개떡이 되고 만 것은, "꼬시다 쌤통이다 메롱"까지는 아니더라도, 감정 배제하고 객관적으로 봐도 정말 일본이 자기네가 심은 대로 거둔 것이다.
 
우리한테 한 짓이 얼마인데! 특히 잊어서는 안 되는 그들의 죄악 중 하나는, 관동 대지진 때 민심이 흉흉해지니까 조선인들을 폭도로 몰아서 수천, 수만 명을 다 학살하고, 그걸 일본 경찰과 정부 당국은 일부러 묵인까지 해 준 사실이다. 독립 운동 항일 투쟁을 하던 사람도 아니고 멀쩡한 민간인을! 사태가 수습된 뒤에도 이 학살극에 대해 법적으로 책임을 진 쪽은 일본에 아무도 없었다.
 
외모가 비슷하니까 일부러 한국인이 발음하기 힘든 일본어 단어를 발음까지 시켜서 사람을 죽였으며, 그러다 심지어 몇몇 자국인도 오인 살해 당했다고 한다. 성경에서 사사기 12장 5~6절을 읽어볼 것. 오히려 조선인을 단원으로 고용하고 있는 야쿠자 같은 조직에서 조직원의 목숨이 위태로우니 애써 숨겨 줬을 정도라고 한다. 그러니 저런 죄값쯤은 좀 치러야 하지 않겠는가? (물론 원폭 피해자 중에서도 조선인이 일부 있었지만.)
 
그럼에도 불구하고 일본은 자기가 저지른 죄에 대한 언급이나 진정한 반성과 사죄는 싹 회피하고, 오로지 핵폭탄을 맞아 자기네가 불쌍한 피해자인 것만 부각시키면서 동정을 호소하고 있으니, 경계해야 할 점이 아닐 수 없다. "다시는 이런 실수 되풀이하지 않겠습니다"... 일본 문화 특유의 뱅뱅 돌려 말하는 모호한 표현인데.. 도대체 그들은 무엇을 실수라고 생각하는 걸까?
 
'귀여운 꼬마애'를 실은 전투기를 조종한 사람은 폴 티베츠라는 베테랑 공군 조종사이다. 당시 30대 초반의 혈기왕성한 대령이던 그는 2차 세계대전을 종식시키는 데 일조한 영웅으로 미국 내에서 추앙 받았으며, 나중에 원스타 준장으로까지 진급한 후 전역했다. 그리고 천수를 누리며 굉장히 오래 살다 2007년에 작고했다.
그는 2002년이던가 미디어를 통해, 당시의 원폭 투하는 그저 명령에만 따른 것일 뿐 딱히 개인의 양심의 가책을 느끼지는 않는다고 회고했다.
 
사흘 뒤 나가사키 상공에 투하된 원폭은 원판보다 더 뚱뚱하고 위력도 좀더 강해진 것이었다. 하지만 평지인 히로시마와는 달리 나가사키는 지형의 기복이 큰 편이어서 히로시마 만한 데미지는 나지 않았다.
 
핵무기까지 가미된 2차 세계대전을 겪은 후 세계 지성인들의 세계관, 인간관은 정말 큰 변화를 겪게 되었음이 틀림없다. 아마 성선설에 대한 믿음이 크게 흔들리게 됐을 것이고, 이런 과학 기술로 이런 규모의 전쟁이 앞으로 더 터졌다간 진짜 지구가 멸망할 거라는 경각심을 갖게 됐을 것이다. 그러니 국가 위의 다른 중재 조직이라도 만들어서 세계 열강이 또다시 이런 끔찍한 전쟁에 도미노처럼 휘말리는 것만은 무슨 수를 써서라도 막아야 한다는 생각을 했을 것이다.
 
그래서 유명무실하던 국제 연맹도 없애고 국제 연합이라는 조직이 새로 생겼다. 그러나 그런다고 해서 세상에 전쟁이 없어지지는 않고 있다. 사악한 자에겐 결코 평화가 없다고 말하는 주님의 이사야서 말씀을 기억하자.
 
어쩌면 6 25 전쟁이 장기화되었다면, 냉전이고 나발이고 없이 2차 세계 대전이 끝난 지 10년이 채 안 지나서 한반도에서 거의 세계 대전급의 피터지는 싸움이 또 벌어졌을지도 모르며, 최악의 경우 핵무기가 또 동원되게 됐을지도 모르겠다. 특히 우리나라에서는 맥아더 장군을 욕하고 비판하는 진영이 이런 점을 주로 들추곤 한다. 하지만 이런 진영은 그 불행의 근본 원인 제공자에 대해서는 이상하리만치 언급이 없고, 저런 식의 주장을 하는 의도가 매우 불순한지라 본인은 별다른 의미를 두지 않는다. (아무리 생각해도 정말 불순하다.)
 
사실 6 25도 1951년 하반기 이후부터는 38선 인근에서의 지겨운 엎치락뒷치락 소모전 위주였기 때문에, 미국도 필요 이상으로 소련 심기를 건드리고 싶지도 않았으며 어지간해서는 승산 없는 이 전쟁에서 적당히 손 떼고 싶었을 것이다. 이승만, 맥아더 같은 짝짜꿍이 맞는 꼴통(?)들만이 오로지 북진 통일을 고집했던 것이다.
 
그 후 세월이 흘러 박정희 정권은 70년대 말에 우리나라도 전투기와 핵무기를 제외한 모든 무기를 국산화했다고 선언했다. 이는 박 대통령의 적극적인 지원 하에 국방 과학 연구소 연구원들이 헌신적으로 노력한 덕분이었다.
 
그는 더 나아가, 우리가 북한과 일본, 미국을 상대로 당당히 큰소리 치려면 우리도 핵무기를 만들어 내야 한다고 생각했다. 박정희가 부하의 총에 맞아 비명에 가지 않았다면, 그리고 이휘소 박사 같은 사람이 그렇게 허무하게 가지 않았다면 한국의 역사가 또 바뀔 수 있었을까? 얘기를 더 하자면 정치성 논쟁이 되므로 이 자리에서는 생략하겠다. (그런데 정작 이휘소 당사자는 오히려 유신 독재와 핵무기 개발을 강력 반대했던 걸로 유명하다. 김진명 씨의 소설에 나오는 설정은 허구이다 ^^)
 
아무쪼록 이 바닥으로 글을 쓰면서 또 느낀 것은, 역시 아는 것이 힘이고 냉혹한 세상에서는 힘이 최고라는 것. 어차피 강자와 약자가 둘 다 시편 20:7 말씀을 모르거나 안 믿는 상황이라면 말이다.
"무기를 만드는 자는 지배자가 되고 방패를 만들지 않는 자는 노예가 된다는 진리"는 돌도끼로 전쟁을 할 때부터 미사일로 전쟁을 할 때까지 인류문명이 만들어 놓은 진리이다. 과거에 우리나라가 힘이 없어서 일제에 주권을 빼앗기지 않았던가.
 
우리나라 국민들이, 일본에 대한 증오심과 적개심이 부족해서 양국의 국력 차이가 그 정도이고 우리가 이렇게 살고 있는 게 절대 아니다. 일본에 있는 동급의 저질 찌질이들하고 같이 댓글 논쟁, 사이트 DDOS 공격이나 주고받으면서 그게 애국인 줄로 착각하지는 말아야 한다.
일본으로부터 받아낼 건 비용 대 효율 최대로 받아내고, 말 없이, 모방을 통해 창조를 해 내고, 실력을 쌓고 기술을 개발하고 국부를 창출하는 것이 일본을 가장 수준 높게 이기는 것이다. 일본을 그런 방법으로 이기려고 애썼던 옛날 지도자의 공도 과와 더불어 객관적으로 인정과 평가를 받아야 하지 않나 싶다.
 
덧.
이 글의 전반적인 논조로부터 느껴졌겠지만, 본인은 원자력 발전 찬성이고, 핵무기 개발도 그렇게 반대 안 한다. 남이 만들면 우리도 해야 된다 주의에 가깝다. -_-;; 그깟 인본주의적인 반핵 반전 운동 한다고 해서 세계 평화가 유지될 거라고 믿지 않는다.

Posted by 사무엘

2010/01/11 10:01 2010/01/11 10:01
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/81

« Previous : 1 : ... 204 : 205 : 206 : 207 : 208 : 209 : 210 : 211 : 212 : ... 215 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/05   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
2710023
Today:
1318
Yesterday:
1311