« Previous : 1 : ... 209 : 210 : 211 : 212 : 213 : 214 : 215 : 216 : 217 : ... 221 : Next »

지하철 전동차의 반입 경로

지하철에 대해 조금이라도 공부해 본 사람이라면 상식으로 알겠지만,
갓 개통한 지하철 노선에다가 수십 편성이나 되는 열차를, 그것도 버스보다도 더 거대한 놈들을 안전하게 운반하여 집어넣는 것도 보통 일이 아니다.

그나마 지금까지 우리나라에 등장한 도시 철도들은 다 같은 표준궤를 쓰기 때문에 기존 철도 위에서 그대로 굴릴 수라도 있지, 경전철은 얄짤없이 별도로 실어서 운반해야 할 것이다. 차량 반입은 마치 "컴퓨터가 발명되던 당시에 최초로 고급 언어 컴파일러를 어떻게 만들었을까?" 같은 아주 원천적인 질문에 속하는 셈이다.

철도 차량은 응당 공장에서 생산되며, 생산된 차량은 경부선 같은 기존 철도에서 분기하여 공장으로 통하는 레일 위에 놓인다. 배로 치면 이게 진수식뻘 되겠다. ^^;; 공장에서 수도권까지는 디젤 기관차가 이런 지하철 차량을 끌고 가 준다.

우리나라는 로지스라 하여, 현재 지나고 있고 앞으로 운행할 예정인 모든 열차의 열차 편성과 운행 기록을 실시간으로 조회하는 서비스가 있다. 철도매니아에게 주옥 같은 정보가 아닐 수 없다. 전동차를 반입하는 화물 열차도 물론 여기에 잡히기 때문에, 이걸 보고 미리 대기하고 있다가 사진을 찍는 열성분자도 많다. 대전 지하철 반입, 서울 9호선 전동차 반입, 공항 철도 전동차 반입 등.

1호선이야 태생부터가 기존 철도와 지하철과의 직결 운행 연결이므로 차량 반입에 아무 어려움이 없다. 그럼 그 이후 지하철들은 어떻게 될까?

2호선은 1호선 신설동 역이 그 비결이다.
지하철 역에 승객이 다니는 환승 통로가 있듯이, 일부 역에는 레일상으로 인근의 노선을 연결하는 길이 있다. 이 역에서 1호선은 2호선 신설동 역 방면으로 몰래 진입하여 인근의 군자 차량 기지로 들어갈 수 있고, 성수 지선을 거쳐 2호선 본선으로도 들어갈 수 있다. 2호선은 원래 신설동에서 강남 종합운동장 역 사이가 가장 먼저 개통했다는 사실을 알면 더욱 쉽게 수긍이 갈 것이다.

1호선에는 가끔 신설동 직전의 동묘앞 역에서 운행을 마치는 서울 메트로 차량이 있는데, 이놈이 바로 지금은 사용되지 않는 신설동 역 지하 3층 유령 승강장을 거쳐 차량 기지로 들어간다.
(사실 1~4호선에 속하는 1기 지하철도 둘로 나누면 1~2호선과 3~4호선으로 나뉜다. 1~2호선만이 ATS 신호를 사용하고 있고 일부 구간에서는 자갈 노면을 볼 수 있기 때문이다. 그 이후 지하철은 모두 ATC로 바뀌고 콘크리트 바닥으로 모두 바뀌었다.)

3호선은 딱히 기존 철도와의 인연이 없으며 연결점이라고는 충무로 역이 유일하다. 이 역은 승객만 3, 4호선을 상호 환승할 수 있는 게 아니라 열차도 상호 노선을 바꿀 수 있다. 4호선은 금정과 창동 역에서 기존 국철 경부선 및 경원선과 만나기 때문에, 3호선 차량도 4호선을 통해 들어와서 충무로까지 가는 엄청난 우회를 한 끝에 3호선 기지로 들어갈 수 있다.

그런데, 5~8호선의 2기 지하철로 가면 사정이 좀 복잡해진다.
그 근본 이유는 지하철이 불연속적인 구간 순으로 개통하기도 했기 때문이다. 가령 A, B, C로 이루어진 한 노선이 A, C 구간부터 개통하고 나중에 중앙의 B 구간이 최종 개통함으로써 단일 노선이 완공되는 식이다.

그리고 어떤 불연속 구간은 기존 철도와는 완전히 단절되어 있기도 하다. 사실, 2기 지하철의 목표는 아예 기존 광역전철과의 직결 운행을 염두에 두지도 않을 정도로 완전히 새로운 노선을 창조해 내는 것이었다. 더구나 비밀 선로라는 건 같은 기간에 건설된 노선끼리나 존재하지, 1기 지하철과 2기 지하철 사이를 연결하는 비밀 선로 같은 건 없다. 그러니 그런 단절 구간에 차량을 넣는 것은 매우 어려운 일이 될 수밖에 없었다.

그럼, 왜 순서대로 개통을 안 하고 그런 식이 될 수밖에 없었을까?
중앙은 대체로 서울 중심부이며, 2기 지하철이 1기 지하철보다 아래로 지나느라 통상 굉장히 깊고 공사하기가 힘들어지는 구간이기 때문이다. 그리고 지하철은 어느 쪽이든 필연적으로 차량 기지가 있는 구간부터 개통을 할 수밖에 없으니 양쪽 외곽부터 개통하고 나서 중앙은 나중에 개통하는 것이다.

2기 지하철 시대를 개막한 5호선은 역 수가 50개에 달하는 상당한 장거리 간선인데, 개통도 여기저기서 산발적(?)으로 했다. 가장 먼저 개통한 구간은 고덕 차량 기지를 경유하는 왕십리-상일동이다. 기존 철도가 전혀 닿지 않는 단절 구간에다가 그 당시 차량을 어떻게 집어넣었는지 한번 생각해 보라.

정말 입이 벌어질 정도로 삽질을 했다. 경부선을 거쳐서 서울의 중심부인 충무로 역까지 간다. 그 후 3호선으로 갈아타서 서울 동남부의 수서까지 간다. 거기서 크레인으로 열차를 들어올린 뒤, 인근의 8호선 가락시장 역 지점까지 1.6km 거리는 트레일러로 운반했다. 그 시기엔 8호선도 건설되고 있었으므로 거기에다가 차량을 집어넣고, 1.3km 정도 떨어진 가락시장과 오금(마천 지선은 당시 아직 공사 중) 역 사이의 비밀 선로를 통해 5호선으로 집어넣었다고 한다. 1995년의 일이다.

쉽게 말해 지금 한창 연장 공사가 진행 중인 3호선 수서-오금 경로를 그대로 따랐다는 뜻이다.
지금도 8호선 가락시장과 5호선 오금 사이에는 비밀 선로 자체는 있지만, 복선일 리는 없을 테고 어차피 역을 만들려면 선로를 또 만들어야 하니 공사가 진행 중이다. 얼마 안 있으면 개통하지 싶다.
(참고로 수서 역은 3호선과 분당선의 연결 선로는 존재한다. 분당선 전동차는 이 경로로 반입되었다.)

5호선은 동쪽 구간이 먼저 개통한 후, 다음으로는 방화 차량 기지가 있는 서쪽이 까치산 역까지 개통했다. 여기는 조금만 센스가 있는 분이라면 짐작할 것이다. 바로 2호선 신도림-까치산 지선이 5호선 차량의 반입 경로였다(신설동 역을 거쳐서 2호선으로 수월하게 들어옴). 원래 양천구청까지밖에 안 가고 서울 메트로 신정 차량 기지로 통하던 그 지선이 까치산 역까지 연장된 것은, 전적으로 5호선 때문이었다! ^^

그 후 5호선은 여의도 구간이 개통하고 가장 마지막으로 을지로, 종로 구간이 개통함으로써 전구간 개통한다. 5호선과 비슷한 시기에 개통한 8호선도 차량이 두 차례에 걸쳐 도입되었는데, 처음엔 수서-가락시장 삽질을 하다가 나중에는 까치산을 거치는 식으로 거의 같은 방법으로 들어왔다. 서울 동쪽을 달리는 노선이 서쪽 끝까지 가면서 엄청난 삽질을 한 것이다. (서울 동남부에는 국철이 없음 -_-)

7호선은 1호선 환승으로 시작해서 1호선 환승으로 끝나는 노선이다 보니 5, 8호선 정도의 삽질은 없었다. 북쪽 장암 구간은 경원선 도봉산 역에서 아주 쉽게 반입이 가능했고(장암-건대입구), 남쪽만 북쪽과 단절되어 있던 시절에(온수-신풍) 약간 고생을 했다. 경인선 오류동 역에서 인근의 천왕 차량 기지까지는 도로 위에다 임시 선로를 깔아서 전동차를 굴려 넣었던 것이다. 그때 7호선 전동차는 마치 노면 전차처럼 차량 기지로 이동할 수 있었다. ^^;; 그 후 건대입구-신풍 구간이 2000년에 연결됨으로써 7호선은 전구간 개통했다.

2기 지하철 중 가장 늦게 개통한 6호선은 차량 기지가 봉화산 쪽에 하나밖에 없는 관계로 근본적으로 분산 개통을 할 수가 없었다. 반입 경로는 다 7호선의 경로를 빌렸는데, 처음엔 도봉산 역을 거쳐서 태릉입구의 연결 선로를 이용했고, 나중에 7호선이 남쪽까지 다 개통한 뒤에는 천왕 기지를 따라 쭉 올라가다 먹골 역에 있는 연결 선로를 타고 들어갔다고 한다.

그럼 9호선은 어떨까?
9호선 역시 차량 기지는 서쪽 끝의 개화 하나만 존재한다. 그리고 기존 지하철이나 국철을 연결하는 비밀 선로는 없다. 9호선 전동차는 경의선 행신 역까지 갔다가 트레일러를 통해 개화 차량 기지까지 수송되었다고 한다. 공항 철도는 경인선으로 인천 끝까지 간 후, 영종도에 있는 기지에 가기 위해 아예 배의 도움까지 받았다.

정리하자면 이렇다.

국철 포함 1호선은 2호선(신설동), 4호선(금정, 창동), 7호선(도봉산)과 연결돼 있다.
2호선은 5호선(까치산)과 연결돼 있다.
3호선은 4호선(충무로)과 연결돼 있다.
5호선은 8호선(가락시장)과 연결돼 있다.
6호선은 7호선(태릉입구, 먹골?)과 연결돼 있다.
9호선과 공항 철도는 딱히 다른 철도와의 연결이 없이 단절돼 있다.

종이를 꺼내서 한번 그래프를 그려 보시라. ^^;;
국철에서 1, 4, 7호선이 뻗어나가고
1-2-5-8,
4-3
7-6 이렇게 연결된 구도임을 알 수 있다.

지하철 노선의 개통을 위해서는 먼저 초대형 대량 화물인 전동차의 효율적이고 성공적인 수송이 전제되어야 한다는 것이 이 글의 요지이다.

Posted by 사무엘

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

우리나라의 공항

※ 김포

인천 공항이 개항하기 전엔 서울에 자리잡은 우리나라 최대/최고의 공항이었다. 지금은 이 위치가 서울 강서구이지만 이 공항이 처음 생기던 시절엔 여기가 서울 시내로 편입되기 전이었다. 일제 강점기 때는 여의도에 비행장이 있던 것이 제법 외곽이던 이곳으로 이전했다.

나름 우리나라를 대표하는 관문인데 부지가 비좁고 더구나 인근의 주거지 때문에 밤엔 비행기를 띄울 수 없는 문제까지 생긴 관계로, 관문 역할은 훗날 인천 영종도에 훨씬 더 큰 규모로 따로 만든 인천 공항에다 넘겨주게 되었다. 그 후 이 공항은 국내선 위주로 역할이 축소되었는데, 이제는 국내선만 취급하기에는 공항 용량이 많이 남는 관계로 중국과 일본 일부 국제선이 다시 취항하기도 했다.

이런 점에서 김포와 인천 공항의 관계는 일본으로 치면 도쿄 하네다와 나리타 공항의 관계와 거의 일치한다. 개인적으로 중국과 일본을 포함하여, 서울에서 2~3시간 안에 닿을 수 있는 단거리 노선은 그냥 김포에 남았으면 하는 바람이 있지만, 인천 공항 올인 육성을 위해서 이는 실현되기 곤란한 사항이다.

한때는 지하철 5호선만이 연결해 줬지만 지금은 9호선과 공항 철도까지 개통하여 나름 3개 철도 노선으로 접근 가능한 곳이 됐다. 본인은 1999년에 나름 대회 참가차 미국 갈 때 김포 공항 국제선을 이용해 봤다.

※ 인천

1990년대에 경부 고속철과 더불어 2대 맘모스급 국책 사업으로 추진된 끝에, 섬을 삽 떠서 메워 만든 초대형 허브 공항이다. 주거지하고는 멀찍이 떨어져 있고, 공간도 무진장 넓고, 비행기는 24시간 뜨고 내릴 수 있고... 건설 당시엔 세종 공항으로 하자는 제안이 있었으나, 인천 시 정치인 쪽의 입김 행사로 인해 반영되지는 못했다고 한다.

인천 이외의 우리나라의 국제 공항들은 거의가 아시아를 벗어나지 못하고 일본· 중국 소수 노선에 국한된 반면, 이 공항은 명실상부히 한국을 대표하는 국제 공항으로서 전세계 수많은 항공사가 취항하여 쉴 새 없이 비행기가 왕래 중이다.
2001년에 개항하여 시설도 깔끔하고 으리으리하고 좋으며, 경영도 잘 해서 흑자 많이 내고, 외국에도 가격 대 성능이 뛰어난(공항 이용료도 저렴) 좋은 공항으로 정평이 나서 어떤 면에서는 일본 공항의 실적도 따라잡고 추월했다고 한다.

그런데 이 좋은 공항을 왜 또 매각하고 민영화한다는 얘기가 나오나 모르겠다.

※ 성남

용도가 공군 비행장에 가깝고 민간인 여객 공항은 아니기 때문에, 다른 공항들과는 성격이 다르다(민간인용 지도에는 표기도 안 돼 있음. 가끔 에어쇼 할 때나 개방한다). 성남에 있지만 이름은 서울 공항이다. 서울에 있는 김포 공항처럼.. 이름과 실제 위치가 별로 매치가 안 되는 또 다른 예이다. ^^

그래도 서울 중심부와 가까우면서 비행기가 뜨고 내릴 수 있는 곳이기 때문에 이 공항이 차지하는 전략적 의의는 꽤 된다. 우리나라 대통령도 이용하고, 부시 대통령이 방한할 때 에어 포스 원 비행기도 이 공항으로 왕래했다.

※ 김해, 제주

서울에 있지 않은 국내 공항 중에 나름 저명도가 있고 자체 국제선도 취항하면서 흑자도 내고 있는 곳이다. 즉, 서울에서 충분히 멀리 떨어져 있는 대도시인 부산, 그리고 어차피 고립된 섬이어서 이렇다할 교통수단이 비행기밖에 없는 제주도이다 보니 수지도 맞고 육상 교통수단에 비해 승산도 있는 것이다. (대구-부산은 아직 고속 신선도 없음) 특히 제주 공항은 그 특성상 국내선의 비중이 높고 비행기가 엄청 많이 드나드는 바쁜 공항으로, 세계적으로 순위도 꽤 높다고 한다.

참고로 서울 김포 공항도 강서구에 있고, 부산 김해 공항도 강서구에 있다.

여담이지만, 제주 국제 공항은 이례적으로 X자 모양으로 활주로가 두 방향으로 건설되어 있는데, 바람이 너무 많이 불어서 한쪽 방향으로 이륙이 곤란한 경우 다른 편 방향으로 할 수 있게 하기 위해서이다. 단, 양 활주로의 길이가 같지는 않아서 다른 편 방향으로 이륙은 작은 비행기만 할 수 있다.

※ 청주

김포가 북쪽 끝이고 김해/제주는 남쪽 끝인 반면, 청주 공항은 국토의 중앙에 있어서 위치가 어중간하다. 그래서 국내선은 제주도로 국한돼 있고, 일부 국제선을 취항해 있으나 수지가 맞지 않아서 적자를 보고 있다고 한다. 철도 충북선에 청주공항 역이 있다.
한때는, 인천 공항을 새로 만드는 대신에 남한의 정중앙에 있는 이 청주 공항을 허브 공항으로 육성하자는 의견도 있었다고 한다.

※ 대구, 포항, 울산

영남 지방에 있는 공항들이다. 대구는 일부 단거리 국제선이 있지만 포항과 울산은 국제 공항은 아니며 국내선만 취급한다. 국제 공항치고는 그렇게 외곽에 있지 않아 접근하기 쉬운 편이다.
국내선은 제주 아니면 서울 행으로 국한되어 있는데 대구는 KTX에 밀려서 김포 공항 노선은 사라졌고(1시간 40분만에 서울 중심 접근 가능!), 그 대신 인천 공항으로 바로 가는 노선만 있다. 포항은 제주도도 없이 서울 김포 행만 제공한다.

대구와는 달리 포항과 울산은 나라에서 육성한 대규모 공업 도시임에도 불구하고 위치상으로 경부 고속도로나 경부선 철도로의 접근성이 열악했기 때문에, 이를 보완하고자 이런 식으로 공항이 존재해 왔다. 포항은 몰라도 울산은 KTX가 2차 개통하면 또 항공 교통이 어떤 양상으로 바뀔지 모르겠다.

서울에서 경주로 갈 때도 울산 공항을 이용하면 된다. 언제 한번 비행기 좀 타고 집에 가 보고 싶다.

※ 강원도, 호남

이런 지역에 있는 공항들에 대해서는 딱히 내가 아는 바가 없다. 서울에서 강원도로 가는 국내선은 과거에 육상 교통이 캐불편하던 시절에는 승산이 있었을지 모르나, 지금은 영동 고속도로가 굉장히 빠르게 잘 뚫려서(경부축의 KTX) 비행기의 장점이 크게 줄어들었을 뿐더러 강원도 쪽은 대도시도 없고 수요가 너무 부족하다. 양양 공항은 정말 악명 높던 사례이다.

광주 공항은 김포 공항으로 가는 노선이 있다. 두말할 나위도 없이 여기도 KTX가 고속으로 달리지 못하고 육상 교통에 비해 항공이 승산이 있기 때문이다.

Posted by 사무엘

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

메모장의 변천사

윈도우즈에서 메모장은 그야말로 운영체제의 역사와 함께 해 온 기본 프로그램이다.
1.0때부터 있어 왔고, 윈도우 7에서도 도구상자 하나, 리본 하나 장착되는 법이 없이 그 베이직한 형태를 유지하고 있다.

사실, 맥에서는 TextEdit, 우분투 리눅스에서는 gedit라고 하여 워드패드와 메모장의 구분이 딱히 없이 서식/비서식 텍스트를 모두 다룰 수 있고 텍스트의 경우 문법 강조까지 지원되는 우수한 에디터가 있는 반면 윈도우즈는 그렇지 못하다.

TextEdit은 수십 MB의 텍스트 파일을 열어서 수십 MB에 달하는 구간을 블록으로 잡아서 지워도 성능 하락이 그렇게 크게 느껴지지 않을 정도로 에디팅이 굉장히 탄탄하게 잘 만들어져 있다는 생각이 들었다.
(참고로 <날개셋> 편집기는 그렇지 못하다. 특히 TSF를 A급으로 지원해 주는 데 드는 오버헤드가 굉장히 큰 편이기 때문에, 10MB급 이상 되는 파일을 편집할 때는 “TSF 지원” 옵션을 끄고 프로그램을 다시 실행하는 게 좋다.)

어쨌든..
메모장은 운영체제가 제공하는 기본 에디트 컨트롤을 사용한다. 보통 텍스트 에디터는 매 줄별로 linked list를 사용하는 반면, 에디트 컨트롤은 텍스트 전체가 한 배열이다! 텍스트 맨 앞에다 문자를 삽입하는 경우 그 뒤 문자열은 일일이 한 자씩 뒤로 밀려나며, 메모리 공간이 부족한 경우 전체 메모리가 재할당된다. ㅎㄷㄷㄷ

이런 이유로 인해 메모장은 비록 가볍다고 해서 덩치 큰 파일을 편집하는 데 좋은 환경이 되지는 못한다. 윈도우 9x 때까지는 16비트의 잔재로 인해, 아예 64KB가 넘는 파일은 읽지도 못하던 암울한 시대가 존재했었다. NT급으로 와서는 그런 물리적인 크기 한계는 비록 해결되었지만, 에디팅 엔진은 여전히 64KB짜리 작은 파일에나 적합하게 설계되어 있다는 사실은 변함없음을 기억할 필요가 있다.

거의 변화가 없는 것 같은 메모장이지만 운영체제 버전이 올라가면서 개선된 것도 은근히 많았다.
Fixedsys 고정이던 글꼴을 바꿀 수 있게 된 것이 윈도우 98부터이고, XP부터는 자동 줄바꿈 옵션을 끈 경우 줄/칸 위치를 보여주는 옵션도 추가되었다.

같은 메모장이라 해도 윈도우 9x 계열과 NT 계열은 저렇게 읽을 수 있는 파일 크기만 차이가 나는 게 아니라 편집 기능에도 차이가 존재한다. 전자는 찾기 기능만 제공되는 반면 후자는 바꾸기도 지원하며 한번에 전체 바꾸기(replace all) 기능도 제공된다.

그런데 전체 바꾸기 기능을 구현한 방식이 무척 재미있다.
윈도우 2000/XP는 말 그대로 매번 메시지를 보내서 순차적으로 찾기/바꾸기를 수행한다. 그래서 화면이 쭉 스크롤되어 내려가는 모습이 보이며, 바꾸기 작업을 수행한 후에 Ctrl+Z를 누르면 바로 직전에 바꾼 문자열 하나만 취소가 된다.

그 반면 비스타는 문자열 전체를 선택하여(select all) 얻어 온 후, 내부적으로 문자열을 기계적으로 빠르게 치환한다. 그러고 나서 문서를 그 텍스트로 일괄 교체한다. 덕분에 Ctrl+Z를 누르면 바꾸기 작업이 전부 취소된다.

근본적으로 에디트 컨트롤에는 일괄 바꾸기 기능을 수행하는 기능이 없기 때문에 응용 프로그램이 그런 것을 직접 구현할 필요가 있다. 하지만 비스타의 메모장은, 메모리를 좀 희생하는 대신 더 빠르고 일괄 취소가 가능한 방법을 선택한 것이다.

Posted by 사무엘

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

영작을 할 때는 단순히 한국어로 작문할 때보다 더욱 다양한 문장부호가 쓰입니다.
한국어는 온점, 반점, 느낌표, 물음표, 따옴표 외에 딱히 쓰이는 문장부호가 없습니다.
물론 말줄임표 같은 것이 있지만 컴퓨터로 치기 어렵다는 점 때문에 그냥 ... 따위로 대체되는 추세이기도 하죠.

하지만 영어 정서법에는 한국어에서는 거의 쓰이지 않는 부호가 최소한 셋 이상 존재하는데, 일단 줄표(긴 것 짧은 것 모두), 세미콜론, 그리고 콜론입니다.

단순히 콤마만 써서 항목을 나열하는 게 아니라 그 위에 세미콜론이라는 상위 계층을 활용하기도 하며,
단순한 문장의 나열이 아니라 뭔가 대구 내지 인과 관계가 있음을 보이고 싶을 때는 재미없게 단순 마침표가 아닌 다른 부호를 쓴다는 것입니다.

나는 때린다; 너는 막는다.
네가 이 상황에서 선택할 수 있는 건 둘 중 하나이다: 죽거나 항복하거나.
미래의 3차 세계대전 때 어떤 무기가 등장할지는 모르겠지만, 그 다음 세계대전 때 무슨 무기가 등장할지는 대략 짐작할 수 있다 -- 바로 새총.
그는 외쳤다, "불이야!"
스레드-안전한 코드를 짜려면 동기화를 잘 시켜야 한다.
그의 세 아들--영수, 철수, 민수--들은 모두 자라서 의사가 되었다.

문장의 어순이라든가 문장부호의 쓰임만 봐도 딱히 우리말스러운 느낌은 안 나며 영문 번역투임을 알 수 있을 정도입니다.
줄표 같은 경우, 국문에서도 쓴다고 공식 명시는 되어 있지만, 사실상 거의 쓰이지 않는 것 같습니다. 위의 예에서 영수, 철수, 민수 같은 삽입 내용은 차라리 괄호를 써서 넣고 말죠.

영어 정서법에 존재하는 문장부호들을 모두 국문에다가 도입해야 할 필요는 없을 것입니다.
하지만 제가 개인적으로 필요를 느끼는 것은 반점의 역할을 보충하는 세미콜론의 역할과 비슷한 부호입니다.
이는 마치 strtok 호출 중에 각 토큰에 대해서도 또 strtok로 토큰을 해야 할 필요가 있는 것과 같은 이치이죠.

이런 용도로 국문에는, 세벌식 최종 자판에도 존재하는 가운뎃점이라는 훌륭한 부호가 있습니다.
그런데 국문학자 중에는 가운뎃점을 별로 좋아하지 않는 사람도 있습니다. 아래아와 혼동된다(비슷한 이유로 아래아도 별로 좋아하지 않기도..), 일본 정서법을 베낀 것이다, 시각적인 변별력이 떨어진다 등의 이유로 말입니다.

어쨌거나 tokenize 용도로 쓰이는 문장부호는 반점 하나만으로는 부족합니다. 한계는 조금만 길고 복잡한 글을 써 보면 금세 실감하게 됩니다. 가운뎃점이든, 심지어 세미콜론을 도입하든 이들의 용법이 국어 정서법에서 확고하게 원칙으로 명문화하고 정확하게 쓰였으면 좋겠습니다.

Posted by 사무엘

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

이번 <날개셋> 한글 입력기 5.5의 모든 바이너리들(EXE, DLL, IME)은 구동될 때 자기가 있는 곳과 동일한 디렉터리에서 ngsapp.ini라는 파일을 검색합니다.
메인 커널이라 할 수 있는 NGS3.DLL은 이 파일로부터 글꼴, 도움말 등 각종 부속 파일들이 있는 디렉터리 정보를 얻으며,
기타 응용 프로그램들은 NGS3.DLL 자체를 찾을 위치를 얻어 옵니다.

아래는 ngsapp.ini를 작성한 한 예입니다. [Paths]라는 섹션에다가 항목을 넣으면 됩니다.

[Paths]
Host=.
Font=..\Font
Help=..\Help
Plugin=.
Dic=..\Dic
Sample=..\Samples
CommonData=..
Applet=.
PluginX86=..\win32
AppletX86=..\win32
UserData=.

Host는 다른 응용 프로그램들이 NGS3.DLL을 찾는 경로입니다. 얘네들은 Host만 봅니다.
그 반면 ngs3.dll은 나머지 key들을 봅니다.
Font, Help, Plugin, Dic, Sample은 따로 설명이 필요 없을 것입니다. 디폴트 경로가 윈도우 비스타 기준 ProgramData\Ymsoft\Ngslib이던 바로 거기이죠.
CommonData는 현재는 언어 리소스인 *.mui 파일만 쓰는 공간입니다.
UserData는 바로 imeconf.dat가 저장되는 곳으로, 디폴트 경로는 Users\사용자 계정\AppData\Roaming\Ymsoft\Ngslib입니다.

PluginX86과 AppletX86은 64비트 프로그램이 32비트 바이너리가 있는 곳을 알아야 할 때 사용하며, 현재는 <날개셋> 입력 패드 64비트 버전만이 사용합니다.
만약 <날개셋> 한글 입력기 무설치 배포판을 만든다면, x86과 x64라는 디렉터리에다가 각각 32비트, 64비트 바이너리들을 한데 다 복사해 놓은 뒤, 두 디렉터리에다가 동일한 이 ngsapp.ini를 비치하면 됩니다.

다만 문제가 되는 것은 외부 모듈인 ngsime.ime인데요. 원래 TSF 모듈은 아무 디렉터리에나 있어도 되고 사용자가 수동으로 regsvr32로 등록만 해 주면 되지만, IME 모듈은 반드시 윈도우 시스템 디렉터리에 있어야 합니다. NgsIme.ime가 윈도우 시스템 디렉터리에 있는데 ngs3.dll은 user-defined 경로로부터 읽게 하고 싶으면 시스템 디렉터리에다가도 ngsapp.ini 파일을 만들어서 Path 섹션에다가 Host만 지정을 해 줘야 합니다.

모든 경로에는 상대 경로를 지정할 수 있어서 좋습니다. 그냥 .만 찍으면 해당 모듈이 있는 커런트 디렉터리가 지정되고, .. 를 찍으면 그 모듈이 있는 디렉터리의 부모가 지정됩니다. 그리고 비워 두면 디폴트가 됩니다.

<날개셋> 타자연습도 ngsapp.ini를 아래와 같이 지정해 주면 됩니다.

[Paths]
Host=
LocalData=
GlobalData=

Host는 ngs3.dll을 읽을 위치입니다.
(참고로, 당연한 말이지만, ngs3.dll은 자기가 있는 디렉터리의 ngsapp.ini를 읽어들이지, 타자연습이 있는 디렉터리의 파일을 읽어들이지는 않습니다.)
LocalData는 사용자 계정이 있는 디렉터리입니다.
GlobalData는 컴퓨터 기계에 관계없이 동일한 데이터인 연습글, 도움말 등이 있는 위치입니다.
셋 모두 .만 찍어 주면, 커런트 디렉터리에서 모든 작업이 이뤄지게 바꿀 수 있습니다.

이 기법을 사용함으로써 <날개셋> 한글 입력기 5.5와 타자연습 3.2부터는 굳이 정식 설치하지 않고도 플래시 메모리에서나 어디에서든 바로 간단히 실행할 수 있으며, 한 컴퓨터에 여러 버전을 충돌 없이 동시에 운용할 수가 있습니다.
이번 버전부터는 msvcr71.dll을 제거하는 데 성공한 것도, 프로그램을 더욱 수월하게 배포할 수 있게 해 줬지요.

다만 제가 말씀드리는 것은, 이 기법을 이용하여 프로그램의 무설치 복사 사용이 이론적으로 가능해졌다는 것뿐입니다.
저는 제가 공식 제공하는 msi 파일을 이용한 설치 외에 다른 방법으로 프로그램을 배포하거나 사용하는 것을 권장하거나, 지원하지는 않을 것임을 밝힙니다. 이런 식으로 프로그램 디렉터리를 변경하여 사용하는 건 전적으로 사용자의 재량이며 책임입니다.

Posted by 사무엘

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

<날개셋> 편집기는 <날개셋> 한글 입력기가 제공하는 프런트 엔드 중의 하나인 간단한 텍스트 에디터입니다.
메모장보다야 기능이 많지만, 이 프로그램의 개발 목적 자체가 외부 모듈과 입력 패드와 더불어 "<날개셋> 한글 입력기 커널의 기능 시연/제공"이기 때문에, 딱히 전문적인 텍스트 에디터나 워드 프로세서를 표방하면서 개발되지는 않는 프로그램이기도 합니다.

<날개셋> 편집기에는 컴퓨터용 언어 작성에 적합한 문법 표시(syntax highlight)라든가, 일반 자연어 작성에 적합한 맞춤법 검사/자동 교정 같은 기능은 없습니다. 하지만 프로그램의 특성상 문자 코드를 다루는 기능이 은근히 발달해 있으며, 버전업을 거치면서 지금은 텍스트 필터가 20여 종에 가깝게 추가된 덕분에 나름대로 독특한 텍스트 프로세싱 기능을 제공합니다. 숫자를 한글로 바꾸기, 한글을 소리나는 형태로 바꾸기, 풀어쓰기-모아쓰기 바꾸기 등 재미있는 기능이 많죠.

여기서는 <날개셋> 편집기의 고급 기능을 활용하여, 완성형-조합형 코드 변환 테이블을 생성하는 방법을 살펴보겠습니다. 조합형이나 유니코드는 현대 한글 11172자의 코드 번호를 계산으로 간단히 생성할 수 있지만, 완성형 코드는 테이블이 필요합니다. 사실, 윈도우 3.1의 한글 IME 프로그램도 헥사 에디터로 들여다보면 이런 테이블이 들어있는 것을 알 수 있습니다.

1. 먼저, 문자표를 이용해 완성형 한글 2350자 나열을 만듭니다.
Ctrl+I를 눌러서 '문자표'를 꺼내면, 코드번호에다 16진수를 입력하여 해당 유니코드 문자를 본문에다 삽입할 수 있습니다. 하지만 '-'를 이용해서 500-600 이런 식으로 입력하면 U+500부터 U+600까지 257자의 문자를 순서대로 한꺼번에 본문에 삽입할 수 있습니다.

그런데, 이 프로그램은 from과 to에 해당하는 문자가 모두 현재의 문자표 리스트에 있는 경우, 문자표 리스트에 등재되어 있는 문자만 본문에다 삽입합니다. 이 점이 중요합니다.
그래서 'KSC5601 문자표' 옵션을 체크하여 완성형 한글만 나오게 한 후, AC00-D79D (가~힝)을 입력해 주면 완성형 2350자 한글을 얻을 수 있습니다. 물론 2350자가 바로 삽입되는 건 아니고 처음 512자까지만 본문에 삽입되므로, 그 다음 문자부터 이 작업을 다섯 번 반복해 주면 됩니다.

  결과물: 가각간갇갈갉갊감갑값갓갔강갖갗같갚갛개객갠갤갬갭갯갰갱갸갹갼걀걋걍걔걘걜거걱건걷걸걺검겁것겄겅겆겉겊겋게겐겔겜겝겟겠겡겨격겪견겯결겸겹겻겼경곁계곈곌곕곗고곡곤곧골 ...

2. 이 글자들을 일단 줄을 나눠 줍니다. 블록으로 잡아서 "구분자 삽입" 필터를 고른 뒤, 설정에 들어가서 간격을 1로, 구분자는 '줄 바꿈'으로 지정하세요.

  결과물:



갇 ....

3. 결과물을 다시 블록으로 잡아서 "코드 번호로 변환" 필터를 고릅니다. 설정에 들어가서는 "문자를 기타 인코딩의 바이트 번호로"를 고르고, 기준 인코딩은 1361 조합형을, 번호 표현 형태는 "C언어 정수형"을 고릅니다.

  결과물:
0x88,0x61,
0x88,0x62,
0x88,0x65,
0x88,0x68, ...

4. 필터가 바꿔 준 숫자는 '바이트' 단위입니다. 하지만 우리는 한글 한 글자가 한 번호에 대응하도록 '워드' 단위로 바꾸고 싶습니다. 그렇기 때문에 찾기-바꾸기를 수행하여 ,0x를 없앱니다. 이걸 하고 싶어서 매 글자마다 임시로 줄을 바꾼 것입니다.

  결과물:
0x8861,
0x8862,
0x8865,
0x8868, ...

5. 이제 거의 다 됐습니다. 이제 다시 줄바꿈 문자를 없애고 모든 번호들을 한 줄로 도로 붙입시다.
결과물을 블록으로 잡은 뒤 "일괄 치환" 필터를 골라서 "\n","" 라는 문자열을 입력합니다. 줄바꿈 문자를 없앤다는 뜻입니다.

  결과물: 0x8861,0x8862,0x8865,0x8868,0x8869,0x886A, ...

6. 결과물을 블록으로 잡은 뒤 다시 "구분자 삽입"을 고른 뒤, 간격을 적당한 7의 배수로 입력하면, 2350개의 숫자가 84칼럼, 혹은 70칼럼 간격으로 가지런히 늘어서 있게 됩니다.
이 배열을 내가 짜고 있는 배열에다가 복사해서 붙여넣으면 되지요.

const unsigned short kshan[2350] = { ... };

Posted by 사무엘

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

<날개셋> 한글 입력기는 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

« Previous : 1 : ... 209 : 210 : 211 : 212 : 213 : 214 : 215 : 216 : 217 : ... 221 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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:
3041914
Today:
1541
Yesterday:
1700