김 용묵의 절대공간 - 블로그

1.
자바는 잘 알다시피 파일 하나와 클래스 하나가 완전히 일대일 대응하며, 파일 이름이 클래스 이름과 일치까지 해야 한다(여러 클래스를 선언하더라도 한 클래스의 내부에서 선언해야 함). 자바는 여러 소스 코드를 한데 모아서, 다시 말해 링크해서 exe를 만든다는 개념이 없고 그냥 소스 코드가 그대로 바이트 코드로 컴파일된 클래스 파일이 되고 거기에 있는 static void Main 함수를 실행하는 구조이다. 그런 만큼 아예 그런 형태를 언어 차원에서 강제함으로써 관리 면에서 얻는 편의도 분명 있을 것이다.

그런데 C#은 그렇지는 않다. C++과 마찬가지로, 파일과 클래스가 일대일 대응하지 않아도 된다. 한 파일에 여러 클래스가 담길 수도 있고, partial 예약어를 쓰면 반대로 한 클래스가 여러 파일에 나눠 담길 수도 있다!
(MSDN에 설명돼 있는 것처럼, 여러 사람이 한 클래스에 대해 공동 작업을 할 때나 클래스의 일부분이 다른 출처로부터 자동으로 생성된다거나 할 때 무척 유용하겠다.)

게다가 C#은 비록 닷넷 전용이긴 해도 여러 소스로부터 한 exe를 만들 수 있는 언어이다. 그렇다 보니 자바에서는 걱정할 필요가 없던 문제가 하나 생기는 게 있는데, 바로 여러 클래스들이 자기만의 static void Main 함수를 정의할 수 있다는 점이다. 이 경우 컴파일러는 에러를 발생시키며, Main 함수를 하나만 남기든가, 어느 클래스의 Main 함수를 실행시킬 지 별도의 옵션으로 지정해 달라는 메시지를 남긴다.

Main 함수가 없거나 둘 이상 존재한다는 에러는 링크 에러가 아니고 런타임 에러는 더욱 아니며, 컴파일 에러라는 게 흥미롭다. C#도 자바와 마찬가지로 링크라는 개념은 없다.

2.
C#에는 C/C++과 마찬가지로 const라는 예약어도 있고 이에 덧붙여 readonly라는 예약어도 있다. const는 컴파일 시점에서 값이 완전히 고정되어 있는 primitive 타입의 상수나 문자열만 지정할 수 있다. 그리고 C++과는 달리 const와 static을 동시에 지정할 수 없다. 어떤 멤버가 const이기만 하면 static은 당연히 자동으로 지정되기 때문이다.

그 반면 readonly는 const보다 더 동적인 값을 선언할 때나 생성자 함수에 한 번 정한 후에 그 뒤부터 고칠 수 없도록 지정할 수 있어 편리하다. primitive 타입이 아니라 new로 할당하는 개체/배열이라든가, 상수이긴 한데 값이 실행 시점에서 가변적으로 정해질 수 있는 값--함수 실행 결과처럼--이라면 readonly로 지정하면 된다.

C++은 이 둘의 경계가 모호했다. 굳이 구분하자면 일반 const 멤버는 생성자 함수에서 동적인 값으로 초기화가 가능했던 반면, static const는 컴파일 때 정적인 값으로만 초기화가 가능했다.
C#은 배열은 자바와 마찬가지로 무조건 new로 할당하기 때문에, 값이 전혀 동적이지 않는 상수 테이블 같은 것도 배열이라면 const가 아닌 readonly로 할당해야 한다.

한편, 자바는 이 점에서 C#과는 다른 재미있는 차이를 보인다. 내 기억이 맞다면 const가 없고 아마 final이 const 역할도 하며, 오버라이드 가능하지 않은 고정 함수임을 나타낼 때도 쓰이는 예약어이다. 즉, C++과 C#은 virtual이라고 별도로 지정한 함수만 가상 함수인 반면, 자바는 별도로 지정하지 않은 모든 함수가 기본적으로 가상 함수인 것이다.

그나저나, this 포인터를 const로 바꿈으로써 이 멤버 함수가 실행 결과가 read-only임을 나타내는 const는, 자바와 C#에서 어떻게 표현하는지 모르겠다.

3.
뒷북일 수도 있지만 한 마디.
유니코드가 제정된 후에 발명된 언어인 자바와 C#은, 해당 언어가 규정하는 문자 집합이 유니코드이다. 그래서 char 형의 기본 크기가 놀랍게도 2바이트이며 문자열 리터럴도 기본이 유니코드 UTF16 형태이다. 게다가 변수를 비롯한 각종 명칭 이름을 한글로 지을 수 있다. ^^ 사실, 비주얼 스튜디오에서는 C# 소스 코드 자체가 기본적으로는 BOM까지 붙어 있는 UTF8 인코딩으로 저장된다.

하지만 C/C++은 그렇지 않다. 1970년대부터 존재한 저수준 시스템 언어인 만큼, 21세기에도 C/C++ 코드는 ANSI 인코딩이다. char 형은 규정상 무조건 1바이트여야 하고 절대로 바뀔 수 없으며, ""는 기본적으로 char 문자열이고 wide 문자열은 L""이라고 접두어를 붙여서 별도로 지정해 줘야 한다.

옛날의 일부 C언어 컴파일러는 키보드로 바로 칠 수 없는 일부 기호를 다른 기호의 나열로 대체하는 시퀀스까지 존재했었다. 그렇게도 열악한 환경에서부터 쓰였던 언어와 유니코드 시대에 등장한 언어는 그 배경이 극과 극일 수밖에 없다.

문자열 타입은 그렇다 치더라도 C/C++이 현대 언어들처럼 유니코드 명칭을 받아들이는 일도 있을 수 없다. 그러려면 그렇잖아도 링크라는 계층이 존재하는 언어인데 오브젝트 파일의 포맷이 바뀌어야 하고, 심지어 운영체제의 API 구조조차 바뀌어야 할지도 모른다. 윈도우 API 중에 GetProcAddress 함수의 둘째 인자가 괜히 PCSTR인 게 아니다(PCTSTR이 아닌 일반 string). 보수적이고 이식성을 생명처럼 여기는 이쪽 바닥에서는 상상조차 할 수 없는 일인 것이다.

이처럼, 똑같이 클래스가 있고 상속이 존재하는 소위 객체 지향 언어라 하더라도 C++, C#, 자바 같은 언어들의 설계 목적과 주 용도, 빌드 단계, 문법 구조, 고안된 당시 배경을 살펴보는 것은 각 언어들의 철학을 이해하는 데 큰 도움이 될 것이다.

Posted by 사무엘

본인은 얼마 안 있으면 적성 검사를 받아야 할 정도로 면허를 딴 지 오래 됐지만, 지금까지 차를 몬 경험이 거의 없고 운전 실력 역시 그 이름도 유명한 장롱 면허 수준에 머물러 왔다. 명절 때나 아니면 다른 일로 인해 고향을 드나들 때는 당연히 선택의 여지가 없이 대중교통만 이용했다. 이런 상황은 앞으로도 한동안 변하지 않을 것 같다.

하지만 이번 설에는 어떻게 여건이 잘 맞은 덕분에 21세기 이래로 최초로 자차를 이용했고, 더구나 꽤 장거리를 직접 운전까지 해서 무사히 도착하는 데 성공했다. 맨날 고속버스에 의지해서 다니던 경로를 내 손으로 주파하니 무척 기분이 좋았다.

1. 천호대로를 타고 지하철 5호선 라인을 따라 동쪽으로 쭉: 천호대로는 서울 시내에서 중앙 버스 전용 차선이 가장 먼저 생겼을 정도로 넓은 도로이다. 직진만 하면 되지만 길 자체가 직선으로만 된 것은 아니다. 중간에 커브도 있고, 언덕도 꽤 있다. 이쪽 구간은 한강이 수평선 방향이 아니라 수직선 방향에 가깝게 흐르기 때문에, 동쪽으로 가는 과정에서 천호 대교로 한강을 건너게 된다.

2. 외곽 순환 고속도로의 상일 IC까지 43번 국도: 강동 역까지 통과하고 나면 5호선 라인을 벗어난다. 이때부터 차선이 좁아지고 지나가는 차들이 눈에 띄게 뜸해지며, 아파트 대신 각종 화원, 공원, 언덕이 나타나면서 시가지가 아닌 교외 분위기가 물씬 풍긴다. 직진만 쫙 하면 고속도로가 나오니 이보다 간편할 수가 없다. 상일 IC로 진입하지 않고 또 직진을 하면 하남시가 나온다.지도로만 보던 지역을 실제로 구경할 수 있었다.

강남 고속버스 터미널이 반포 IC 인근에서 경부 고속도로를 접수하고 있다면 강변 동서울 터미널은 중부 고속도로를 접수하고 있다. 사실 이 터미널 자체가 중부 고속도로의 활성화를 위해 정책적으로 세워진 것이기도 하다. 그런데, 동서울 터미널에서 출발하여 중부 고속도로로 진입하는 버스들은 알고 보면 굉장히 비효율적인 경로를 이용한다.

먼저 올림픽 대교를 이용하여 강남으로 건넌 뒤, 올림픽대로를 타고 한참을 동쪽뿐만 아니라 ‘북쪽’으로 주행한다. 남쪽으로 가야 할 차가 북쪽으로 가서 상일 IC가 아닌 강일 IC를 통해 고속도로로 진입한다. 버스 차창을 살펴보면 서울 지하철 5호선 고덕 차량기지 근처를 지나는 게 보이니, 얼마나 우회 경로인지 알 수 있다. 이번에는 자가용을 직접 운전한 덕분에 그런 우회 경로를 피할 수 있었다.

3. 외곽 순환 고속도로(100): 8차선으로 된 근사한 도로이다. 조금만 남쪽으로 내려가면 하남 분기점이 나오고 여기서 중부 고속도로(35) 쪽으로 가면 동서울 요금소가 나온다. 새벽에 출발했지만 고난은 이제부터 시작이었다. 극심한 정체가 계속됐다.

4. 중부 고속도로: 이 도로는 처음엔 8차선인 것처럼 시작하지만 얼마 못 가 차선의 절반은 제2 중부 고속도로(37)로 빠져나가고 4차선으로 줄어든다. 제2 중부는 잘 알다시피 중부 고속도로의 용량 확장을 위해, 영동 고속도로(50)와 만나는 호법 분기점까지 오리지널 중부의 옆에다가 도로를 또 지은 것이다. 중부 고속도로는 경기도 남동부의 험악한 산지를 터널과 교량으로 연결한 험한 선형이기 때문에, 경부처럼 차선 확장을 도저히 할 수 없고 옆에 도로를 또 만들 수밖에 없었던 것이다.

5. 영동 고속도로: 호법 분기점과 여주 분기점까지는 잠시 영동 고속도로 구간을 이용한다. 8차선의 아주 시원시원한 길이었지만 중부내륙 고속도로(45)로 진입하는 길부터는 다시 차들이 거북이걸음을 시작했다.

6. 중부내륙 고속도로: 가장 장거리 구간이지만 정체가 심해서 좀 답답한 시간을 보내기도 했다. 4차선이고 최고 시속이 100이 아닌 110이며 터널과 고가 교량이 많다는 점에서는, 중부 고속도로와도 비슷하다.
내가 운전하던 무렵엔, 정체에 시달리던 하행과는 달리 맞은편 상행은 차가 거의 없고 한산하여 극단적인 대조를 보였다. 정체는 거의 괴산 이남까지 가서야 풀려서 차가 제 속도를 내기 시작했다.

그나저나 날씨가 정말 판타지 급이었다. 눈이 부슬부슬 내리다가 산악 지대로 가니 함박눈으로 돌변했는데, 터널을 하나 지나고 나오자 눈이 그치고 햇볕이 났다. 그랬는데 어느 샌가 또 잔뜩 흐린 날씨로 바뀌었다. 하지만 다행히 빙판길은 없었으니 눈 때문에 딱히 고생하지는 않았다.

7. 경부 고속도로: 김천부터 드디어 내게 아주 친숙한 경부 고속도로이다. 수도권이 아닌 곳에서 8차선이나 되는 유일한 고속도로이다. 물론 경산부터는 6차선으로 줄어들고 영천 이남부터는 4차선으로 줄어들지만 말이다. 경부 고속도로가 개통한 지 벌써 40주년이 돼 가는데, 아직까지 4차선을 유지하고 있는 극소수 구간이 그쪽이다.

여기부터는 가끔 서행 상태가 되긴 했지만 전반적으로는 소통이 원활했다. 무척 인상적인 점은 아까와는 반대로 상행이 막히고 있는 경우가 많았다는 것. 그나저나 포항으로 가는 길목인 도동 분기점에서의 극심한 혼잡이었다. 저 많은 차들이 포항을 드나드는 차들이라는 것에 적지 않게 놀랐다.

서울에서 경주까지 문에서 문까지 7시간 가까이 걸렸으니 그렇게 빨리 가지는 못했다. 워낙 정체가 심해서 이거 시속 100은 낼 기회가 있을까 궁금했는데 그래도 이따금씩 앞에 차가 없을 때는 순간적으로 130~140까지 밟은 적도 있었다.

영천에서 경주까지는, 중앙 분리대와 입체 교차로까지 갖추고 준 고속도로 급으로 변모해 있는 4번 국도를 이용했다. 시설 좋고 차도 거의 안 다니니 최적의 드라이브 코스였다. 최대 시속 80km로 설계되어 있지만 120까지 밟아 보기도 했다.
그런데 역시 고속도로와의 차이는 뭐니 뭐니 해도 커브의 반경이었다. 내가 지금까지 거친 어느 고속도로에서도 찾을 수 없는 급커브가 곧바로 느껴졌다. 국도와 고속 국도의 차이가 이런 것이구나. 도로의 설계 최대 시속은 이런 것까지 감안하여 산출된 것이다.

이렇게 무사고로 한번 완주는 했지만, 여전히 난 운전이 어렵게 느껴진다.
군대에서도 사고는 이병 시절이 아니라 어설프게 고참 행세를 시작하는 일병 시절에 많이 난다고 하듯, 자동차 사고도 완전 긴장이 바짝 든 왕초보 시절보다는 스스로 초보 딱지를 뗐다고 생각하고 방심할 때 가장 많이 난다고 생각한다.

아직까지도 핸들을 잡던 기억이 머리에 선하다. 방심하다가 금방이라도 앞 차를 추돌할 것만 같은 그런 느낌 말이다. 차간 거리를 굉장히 길게 유지하면서 달리고 싶은데 그러면 내 뒤에 있던 차가 어김없이 앞으로 끼어드니 그렇게 하기도 쉽지 않다.

Posted by 사무엘

예전에 짜 놓은 C++ 코드를 C#으로 포팅할 일이 있어서 모처럼 비주얼 스튜디오로 C# 프로젝트를 만들어 봤다. 그렇게 거창한 건 아니고, 그냥 콘솔에서 간단하게 입출력만 주고받는 150~200줄 남짓의 정올 답안 정도 되는 규모의 프로그램이다.

public void 이런 식으로 멤버 함수를 선언하는 것이나, 클래스 안에다가 함수 몸체를 다 써 넣는 것은 자바를 닮았다.
전처리기 같은 게 없고 C++보다 소스 코드 파싱이 훨씬 더 용이한 것 역시 자바와 일치한다. 사실 이건 요즘 객체 지향 언어들의 보편적인 추세이기도 하니까.

이 언어 역시 자바처럼 생산성 하나는 정말 좋겠다는 생각이 들었다. 파싱이 쉽기 때문에 IDE가 굉장히 똑똑해질 수 있다. 소스 코드 자동 리팩터링이라든가 인텔리센스 자동 완성, 코딩 컨벤션 교정 같은 것을 월등히 더 지능적으로 구현할 수 있다는 뜻.
실제로 C++ 쓰다가 C#을 쓰면 정말 그 편리함에 감탄하곤 한다.
환상적인 빌드 속도도 큰 매력이며, precompiled header 나부랭이도 없다. delete 때문에 골머리를 썩을 필요도 없다.
네이티브 바이너리를 못 만들어서 낭패이긴 하지만 말이다.

자바와 C#에는 C++에서 ::와 ->에 해당하는 연산자가 없으며 이들의 기능을 .이 모두 맡고 있다. 일단 포인터라는 게 존재하지 않으니 ->가 필요 없고, . 가 개체의 멤버 참조뿐만 아니라 scope와 namespace 식별까지 모두 맡고 있는 것이다. 그렇게 해도 문법상으로 모호해지지는 않는다.

C에는 다차원 배열이 존재하지 않으며 오직 배열의 배열 내지 다차원 포인터만이 그 개념을 대신하고 있는 반면, C#은 자유롭게 다차원 배열을 선언할 수 있다. 무슨 얘기냐 하면 실행 시간에 임의의 값으로 x*y 크기의 동적 배열을 만들 수 있다는 뜻. (C/C++은 언어 차원에서 이 간단한 일도 바로 가능하지 않다.)

C#은 콤마 연산자는 존재하지 않는 듯하다. 그리고 int 같은 기본 타입을 reference로 전달할 수 있는데, 이때는 반드시 ref를 추가해야 한다. 함수를 선언할 때 ref를 붙이는 건 마치 파스칼에서 var을 붙이는 것과 비슷한데, 이뿐만이 아니라 그런 함수를 호출할 때도 func(ref a) 이런 식으로 ref를 붙여야 하는 게 무척 신기하게 느껴졌다.

앞으로 간단한 벡터 그래픽 데모 프로그램을 짤 일이 있을 것 같은데 이것도 간단하게 C#으로 짜면 딱일 것 같다. 복잡한 최적화 루틴 같은 거 필요 없고, 그냥 결과물이 마음에 들 때까지 빌드를 엄청 자주 해야 할 텐데 C++보다 생산성이 월등히 더 뛰어날 수 있기 때문이다.
하지만 그러려면 Win32 API와는 완전히 다른 그래픽 체계를 또 공부해야 되네. -_-;;

Posted by 사무엘

http://tvnews.media.daum.net/view.html?cateid=100000&cpid=73&newsid=20100211210932494&p=sbsi
(인터뷰에 나오는 사람들은 네이버 바이트레인 운영진임. ^^)

2004년에 KTX가 개통한 이래로 드디어 완전히 새로운 고속철 차량이 도입된다.
경부 고속철 2차 구간(대구-부산) 개통을 앞두고서 아주 뜻깊은 소식이 아닐 수 없다.
이미 40년이 넘는 짬밥을 먹은 신칸센은 어마어마한 차량 계보를 자랑한다는 점을 기억하자.

국내 기술로 개발 중인 차세대 고속철인 HSR-350(프로젝트명) 시절에는 파란 도색이 아닌 빨간 도색이었고, 차의 디자인도 지금하고는 달랐는데 좀더 날렵하게 바뀐 모양이다. 이 열차는 현존하는 KTX보다 더 빠른 시속 350으로 달리게 설계되었으나, KTX II가 도입된다고 해서 지금 당장 서울-부산 주행 시간이 단축되는 건 아니라 함, 아직까지는 기존 KTX와 동일 속력으로 달릴 것이기 때문이다.

KTX II는 프랑스 떼제베의 로컬라이즈 버전 수준이던 초창기 KTX보다 굉장히 많은 면에서 발전했다.
좌석이 회전 가능하게 바뀌어서 역방향 논란이 없어졌으며, 크기와 간격도 더 넉넉해졌다. 식당차도 있다.
객차 내부를 우리 마음대로 개조할 수 없는 초창기 KTX와는 달리 우리나라 기존 열차와의 이질감이 크게 줄어든 셈이다. 국내 기술 개발이 이래서 좋다.
객실 내에서는 무선 인터넷이 되고 콘센트도 지금 새마을호처럼 객실 맨 앞과 뒤에만 존재하는 정도를 넘어, 놀랍게도 좌석마다 비치되었다.

(현 KTX에 콘센트가 없는 이유는? 고속철 건설과 차량 계약을 무려 1990년대 중반에 했는데 그때는 지금처럼 휴대전화나 DMB 같은 온갖 전자 기기들의 수요를 예상하지 못했기 때문이다. 식당차 역시, 어차피 서울-부산을 겨우 2시간대에 주파할 건데 필요를 느끼지 않아서 만들지 않은 것임.)

그럼 기술적인 면은?
비가 오나 눈이 오나 길이 400미터에 달하는 935명짜리 커다란 열차를 끌고 다녀야 하는 현 KTX와는 달리 편성수도 유동적으로 조절 가능하며,
그리고 언뜻 듣기로는 구조 자체가 근본적으로 동력 집중식이 아닌 동력 분산식으로 바뀌었다고 한다. 이것도 정말 큰 변화인데 뉴스 중에는 언급되어 있지 않다. 차량의 가감속력 향상이 기대된다.

KTX가 또 전동기의 무슨 기술은 굉장히 원시적인... 직류 전동기던가? 이런 걸 쓰고 있어서 심지어 8200호대 전기 기관차보다도 비효율적인 게 있다고 한다.
듣기로는 그런 것도 개선된다고 함.
뭐 그래 봤자 지금 KTX도 한 편성이 서울-부산을 한 번 오가는 데 전기 요금이 110만원 남짓밖에 안 든다고 하니 전기가 정말 싸게 먹히긴 한다.

새로운 열차가 도입되는 건 좋은데 운임이 문제되고 있는 듯하다. 그 좁디좁은 KTX가 객차 한 칸에 지금의 새마을호와 동일한 64명을 태운다. KTX는 차체가 기존 일반열차보다 훨씬 더 홀쭉함을 알 수 있다. 차 덩치는 비슷한데 좌석 공간은 더 커지다 보니, KTX II는 한 칸에 태울 수 있는 인원이 필연적으로 감소한다.

이런 면에서 보면 KTX II는 요금이 더 비싸져야 한다.
하지만 이 차도 등급상으로는 동일하게 고속열차 KTX인데 요금을 차등 부과하는 게 바람직하지 못하다. 같은 무궁화호가 구형 탕엥 객차하고 디자인리미트 신형 객차가 운임이 서로 다르던가?

무궁화호급 열차는 CDC를 개조한 RDC 무궁화호와 누리로가 등장했는데
이제 KTX급 열차에 새로운 바람이 불고 있다.
그럼 새마을호급 열차는? 누리로보다 내장재가 더 좋은 전기 동차 내지 틸팅 열차가 등장할 것이다. 과거 EEC의 후예뻘 되겠다. 그리고 그 즈음 지금의 새마을호 디젤 동차는 퇴역하여 역사 속으로 사라질 것이다.

아무쪼록 새로운 KTX II가 대구-부산 고속신선과 대구· 대전의 시내 구간까지 쌩쌩 전속력으로 잘 달려서 서울-부산을 어서 2시간대까지 단축해 주길 간절히 바란다.

Posted by 사무엘

Posted by 사무엘

※ 2.0x

조합형 아스키 파일을 불러와서 편집하는 입력기 기술 데모 수준에 불과하던 1.x 에디팅 엔진이 2.0에 와서는 비약적으로 향상됐다. 서로 다른 입력 설정을 가질 수 있는 입력 항목을 4개까지 가질 수 있고 간단하게나마 플러그 인 확장도 가능해졌다.
편집기는 이제 자동 줄바꿈과 탭 문자가 지원되고 옛한글도 쓸 수 있게 되었다. 유니코드에 대한 지식이 부족해서 당시 아직도 널리 쓰이던 한/글 97의 내부 코드를 사용했던 게 무척 이색적임. 이게 무려 2002년의 일이다.

※ 2.3x

2.0 엔진을 기반으로 해서 편집기에 굉장히 많은 편의 기능이 추가되었다. 예를 들어, 중복 실행 방지라든가 전체 화면 같은 옵션은 이 버전대에서 처음으로 추가되어 오늘날에 이르고 있다.

※ 2.5

2.4와 기능면에서는 큰 차이가 없으나 드디어 개발툴이 비주얼 C++ 2003으로 업그레이드되어 향후 6년간 이 툴이 쓰이기 시작했다. 그리고 이 때부터 MSI 패키지 방식으로 프로그램이 배포되기 시작했고, 이 버전에서 정말 허접하게나마 TSF 모듈이 시범적으로 도입됐다.

※ 3.0 ~ 3.02

<날개셋> 개발 역사상 버전업 gap이 가장 길었던 3.0은 더 말이 필요 없다. API가 밑바닥부터 완전히 revamp되었다.
입력 기본 문자가 64비트 크기로 확장되고 100% 유니코드 기반 설계, 오토마타와 글쇠배열에 수식 지원, 임의의 개수의 입력 아이템 등록, 입력 스키마와 문자 생성기 계층의 분리, 첫가끝 방식 옛한글 표현 등 지금 <날개셋> 한글 입력기의 근간을 상당수 이때 이뤄냈다.
물론 엔진 교체에만 치중하느라 2.x에 있던 기능이 다운그레이드된 것도 그때는 있었다.

3.01은 3.0의 여러 치명적인 버그 수정 중심이었다.
엔진뿐만 아니라 외부 모듈 쪽 연구도 꾸준히 이뤄진 덕분에 3.02 때는 드디어 <날개셋> 한글 입력기가 역사상 처음으로 정식 외부 모듈(윈도우 IME)로 개발되는 쾌거를 이뤘다. 전용 에디터인 편집기 말고도 또 하나의 프런트 엔드가 추가된 것이다.

※ 3.1

상당히 개발 기간이 길었다. 외부 모듈을 처음 만들면서 부딪혔던 지옥 같은 온갖 버그들의 해결에 초점을 맞췄다. 그 후로도 3.x, 심지어 4.x 초반때까지도, 너무 투박하던 3.0x의 UI 편의성 강화 내지 다운그레이드 요인 해소 같은 개선 작업은 계속됐다.

※ 3.41

기념비적인 작품이다.
지금과 같은 tree 형태의 <날개셋> 제어판 UI가 이 때 정착했다. (3.0 UI는 지금보다 훨씬 더 불편했음)
그리고 한 바이너리로 유니코드도 지원하고 윈도우 9x에서도 실행 가능한 기술이 자체 개발되어 이 버전 때부터 적용됐고, MFC 라이브러리에 대한 종속성도 이때부터 완전히 사라졌다. 이 외에도 추가된 기능들 엄청 많다.
원래 3.4가 나왔으나, 치명적인 버그들 때문에 약 3주만에 역사 속으로 묻혔다. -_-

※ 3.9

3.5와 3.65는 여전히 외부 모듈 버그 해결 위주였고..
3.9에 와서 한글 입력 엔진이 장족의 발전을 이뤘다. 특수 도깨비불과 결합 축약 규칙이 도입되어 휴대전화 같은 굉장히 특이한 한글 입력 방식을 기술하는 기반이 마련되고, 한글뿐만 아니라 임의의 문자를 조합 상태로 입력할 수 있는 "날개셋 고급 입력기"라는 문자 생성기도 추가되었다.
아울러 XML 방식으로 입력 설정 파일을 읽고 쓰는 기능이 최초로 도입된 것도 이 버전부터이다.

※ 4.2

외부 모듈 쪽 버그를 잡은 것도 많지만, 편집기에 세로쓰기가 가능해지고(비록 기괴해 보이지만 -_-) undo/redo 기능이 지금과 같은 수준으로 쓸 만해진 게 이 버전부터이다.
사실 4.x은 3.x 엔진을 기반으로 해서 끊임없이 기능이 추가되고 외부 모듈이 안정화되던 단계였지 옛날 같은 급격한 변화는 없었다.

※ 4.4

윈도우 비스타와 MS 오피스 2007 같은 거물급 소프트웨어가 연달아 출시된 지 얼마 안 된 2007년 초에 나왔다. 이 버전은 에디팅 엔진부터 시작해서 외부 모듈 등 다방면에 걸쳐 굉장히 많은 기능이 추가되고 강화되었다. 윈도우 비스타 환경에 특화된 업데이트가 적용되었음도 물론이다.

개인적으로 무척 의미 심장한 버전이었다고 생각하는데, 놀라운 건 4.4는 4.2가 나온 지 불과 90일이 채 안 되는 짧은 기간만에 완성되었다는 것이다. 게다가 그 기간 동안 세벌식 파워업도 먼저 업데이트하고, 타자연습도 적지 않게 기능이 더해지고 고쳐졌다. 10년에 가까운 <날개셋> 한글 입력기 개발 역사상, 거의 전무후무한 사건이 아닌가 싶다.
어떻게 이 일이 가능했을까? 당시 근무 중이던 병특 회사가 망해 가면서 사실상 조업 중단 상태였고, 덕분에 개인 시간이 굉장히 많았던 덕분이었다. =_=;;

※ 4.55

지금과 같은 언어 리소스 파일이 확실하게 독립한 게 이 버전부터이다. 영어 말고 여타 언어 UI도 이제 이론적으로는 얼마든지 추가가 가능해졌는데, 그런 거 할 인력이 없으니.. -_-;;
이 시기에 정 재민 님의 노력 덕분에 같이 제공되는 비트맵 글꼴의 양과 품질도 굉장히 향상되었다.

※ 4.8x

짠.. 시대의 요구에 부합하여 이때 드디어 64비트 에디션이 나오기 시작했다.
그리고 이때, 프로그램 디렉터리 구조도 윈도우 비스타 기준대로 더욱 깔끔하게 바뀌었다.
4.81에 와서야 드디어 수식에 상수 명칭이 도입되었다.

※ 5.0

비록 기능상의 큰 변화는 없지만 한글 표현 범위가 유니코드 5.2에 맞춰서 확장됐으니, 5.0이라는 번호에 걸맞은 매우 의미심장한 변화라 할 수 있다. 또한 3~4대 버전에서 사용되어 온 비표준 한글 표현 관행도 완전히 없어졌다.
3~4대 버전에서 그대로 쓰이던 입력 설정 파일 포맷이 이 버전에서부터 바뀌었다. 그 대신, 한글 코드 변환과 옛날 방식 설정 파일의 변환만을 전문으로 하는 별도의 유틸리티가 추가됐다.

※ 5.3

나이를 먹고 사회적 위치가 바뀌면서 본인은 점차 시간의 압박에 시달리고 있다. <날개셋> 개발 주기도 갈수록 길어지는 게 눈에 띈다. 하지만 5.3은 5.0 이후 꽤 긴 시간만에 완성된 만큼 알찬 변화가 많으며, 보기 좋은 작품이다.
편집기는 8*4*4 도깨비 한글 글꼴뿐만 아니라 임의의 조합 테이블을 내장한 자체 글꼴을 지원하기 시작해, 옛한글 자모까지 포함하여 더욱 다양한 한글 글꼴을 사용할 수 있게 되었다.
이것 말고도 5.3에서의 가장 큰 변화는 "입력 패드"라는 제 3의 프런트 엔드의 추가이다. 편집기처럼 실행해서 외부 모듈처럼 다른 프로그램에다 글자 입력을 보내 주는 이 도구는 포인팅 장비로 입력 UI를 클릭하여 문자 입력이 가능하다. 예전에 존재하던 화면 키보드도 이런 입력 UI 중의 하나로 위상이 바뀌고, 동일한 UI를 세 개의 프런트 엔드에서 동일하게 구동하는 체계가 정립된 것이다.

그건 그런데, 5.3에 와서도 아직도 외부 모듈 버그 수정 사항이 심심찮게 보인다. 정말 윈도우 IME는 제대로 만들기가 불가능하며, 문제가 생길 때마다 그때 그때 고치는 수밖에 없다.
5.31은 5.3의 버그 패치라기보다는, 5.3에서 미처 다 못 넣은 기능들에 대한 강화판에 더 가깝다.

※ 5.5x

이 버전부터는 프로그램의 무설치 실행이 가능해졌으며, 윈도우 7에서 새롭게 발생하는 문제에 대한 패치가 몇 차례 이뤄졌다. 내부적으로는 개발툴이 6년만에 업그레이드되었다.
이 외에, 입력 UI로 부수 한자 입력기와 문자표가 입력 UI로 추가되었다. <날개셋>은 기술적으로 키보드 입력뿐만 아니라 터치스크린 입력 방식까지 커버할 만반의 준비를 하고 있는 중이다.

최신 버전인 5.52가 나온 후 현재 개인적으로 작업해 놓았거나 작업 중인 사소한 수정 사항은 다음과 같다. 일종의 ‘알려진 버그’인 셈이다.

1. 윈도우 라이브 메신저에서 마우스 클릭으로 대화창을 연 후 한글을 바로 입력하면 첫 타가 영문으로 씹히는 문제 (이건 기술적으로는 메신저의 버그임. 문제를 피해 가도록 조치를 취함)

2. 지금은 기억도 안 나는 여러 UI 개선. 특히, 받침 결합 규칙이 전혀 없는 세벌식 최종 자판에서 글쇠배열만 390이나 두벌식으로 바꾸려 할 때 경고 메시지가 뜨게 바꿈. ^^;;

3. XML 방식으로 설정 파일을 저장할 때, "" 안에 들어있는 부등호나 따옴표 같은 문자가 & 엔티티로 제대로 바뀌지 않을 수도 있는 문제를 발견하여 수정

4. 윈도우 7의 콘솔에서 한글을 조합 중이다가 조합을 중단할 때, 조합 중이던 한글이 덧나는 문제가 있다. ‘다 -> 다다.’ 처럼. 이게 일단은 MS IME에서도 두벌식이 아닌 세벌식 모드일 때 동일하게 나타나며, 비스타에서는 전혀 나타나지 않는 증상이 7에서만 나타나는 걸로 미뤄 볼 때 운영체제의 버그일 가능성이 높다.

5.52 이후 다음 버전은 또 기능 추가에 초점을 둔 5.7 정도로 생각 중이다.

Posted by 사무엘

내 프로그램의 중복 실행 여부를 판단하려면? (물론 윈도우 프로그래밍 기준)

실행 직후에 자신만 식별할 수 있는 이름으로 커널 오브젝트를 만들어서, 이놈의 생성 여부로 판단하는 게 제일 무난하고 안전하다. 커널 오브젝트라 함은 메모리 맵드 파일, 뮤텍스, 이벤트 등 이름의 scope가 전역적인 어느 것이라도 될 수 있겠다.

다른 방법으로 중복 실행을 판단하는 방법은 크게 윈도우 아니면 파일로 식별하는 것으로 나뉘는데, 커널 오브젝트만치 완전하지는 못하다. 그 이유를 지금부터 설명하겠다.

※ 응용 프로그램이 생성한 윈도우로 판단하는 법

FindWindow 함수로 나만이 지정하는 윈도우 클래스 이름이나 윈도우 캡션 이름을 검색하여 그게 존재하면 그 윈도우로 포커스를 옮겨 버리고 나는 실행을 종료한다. 대개, 이미 존재하는 인스턴스로 포커스를 옮겨 주는 작업이 필요할 것이므로 윈도우로 검색하는 방법은 어지간해서는 상당히 간편하고 직관적이고 좋은 방법이긴 하다. 다만,

만약 MFC 같은 프레임워크로 프로그램을 개발하고 있었다면, 메인 윈도우의 클래스 이름을 나만의 명칭으로 변경하기 위해 PreCreateWindow 같은 함수를 번거롭게 오버라이드해야 한다.

또한 클래스 이름이 아니라 캡션 이름으로 검색하는 것은 어지간해서는 피해야 한다. 캡션 이름 검색은 모든 top-level 윈도우들에 WM_GETTEXT 메시지를 보내는 방법으로 행해지기 때문에 오버헤드가 클 뿐만 아니라, 이미 실행된 내 프로그램 윈도우가 작업 중이어서 응답을 안 하고 있다면 프로그램 실행이 의도대로 되지 않을 우려가 크다.

윈도우로 검색하는 방법은 근본적으로 큰 약점이 있다. 일반적으로 프로그램이 실행된 직후 로딩, 각종 초기화를 끝내어 메인 윈도우를 생성하기까지는 적지 않은 시간이 소요된다는 것이다. 커널 오브젝트를 생성하는 것처럼 즉시 생성되는 게 아니다. 그렇기 때문에 첫 인스턴스가 아직 메인 윈도우를 만들기 전에 사용자가 실수나 고의로 또 엔터를 눌러서 둘째 인스턴스까지 실행한 경우 여전히 프로그램이 두 개가 실행되어 버릴 수가 있다. 프로그램이 어떤 경우에도 절대로 두 인스턴스 이상이 실행돼서는 안 되는 중요한 프로그램인 경우 윈도우 검색의 결과에만 의존해서는 안 된다.

※ 파일 차원에서 판단하는 법

윈도우 3.1 시절에는 WinMain 함수의 둘째 인자인 hPrevInstance를 살펴보는 것만으로도 내 프로그램의 중복 인스턴스를 판단할 수 있었다.
32비트 이후의 운영체제에서는 인스턴스 핸들의 의미가 한 주소공간 안의 포인터로 완전히 바뀌어 버렸기 때문에, 주소공간 자체가 독립적인 프로세스를 식별할 수는 없게 되었다. 오로지 그 주소공간 안에 로드되어 있는 여러 DLL 같은 모듈들만 식별할 수 있다.

그 반면, 지금도 EXE 내지 DLL 내부에 공유 가능한 섹션을 따로 생성하여 여기에 중복 인스턴스와 관련된 정보를 간단하게 집어넣을 수도 있다. 즉,
#pragma data_seg()
#pragma comment(linker, "/Section:SHARED,RWS")
이런 지시문 안에다가 전역변수를 선언하면 그 변수는 운영체제의 가상 메모리 상으로 나의 모든 인스턴스들이 공유하게 된다는 뜻이다. 자세한 것은 MSDN 참고. 번거롭게 메모리 맵드 파일 API를 호출할 필요 없이 간단한 데이터 공유에는 이 방법이 굉장히 편리하다.

이렇게 파일 차원에서 식별하는 방법은 윈도우 차원에서 식별하는 방법이 잠재적으로 갖고 있는 부작용들이 전혀 없어서 좋으나, 말 그대로 파일에 전적으로 종속적이라는 큰 한계가 있다.
같은 EXE를 이름만 바꿔 복사해서 실행한 것은 중복 인스턴스로 전혀 판단하지 못한다는 것이다. 이 점이 매우 중요하며, 이는 대부분의 경우 원치 않는 결과일 것이다. 결국 실행 파일 그 자체가 아니라 그 실행 파일이 만들어 놓은 결과를 추적해서 중복 실행을 판단하는 접근 방식이 필요하게 된다.

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘