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

1.
프로그래밍을 하다 보면 단독 실행이 가능한 EXE 형태의 프로그램만 만드는 게 아니라, 다른 프로그램에 부속물로 붙거나 여러 프로그램들 사이에서 공유되는 라이브러리, 플러그 인 같은 걸 만들 때가 있다.
플러그 인 정도야 호스트 프로그램이라도 분명하게 존재하니 양반이지만, 임의의 프로토콜을 갖는 공용 라이브러리는 static LIB이든 DLL이든, 그 자체로 단독 실행이 가능하지 않다. 그렇다 보니 그 라이브러리를 사용하는 프로그램을 또 별도로 만들어야 해서 테스트와 디버깅이 여러 모로 불편하다.

그래서 Windows에서 DLL을 만드는 솔루션의 경우, 그 솔루션에다가 DLL을 테스트하는 간단한 EXE도 프로젝트로 따로 만드는 게 보통이다.
Visual C++은 지난 2005부터인가 프로젝트를 새로 생성할 때, 솔루션 디렉터리 아래에 동명의 프로젝트 디렉터리가 한 단계 더 생기고, 한 솔루션에 소속된 프로젝트들의 생성물은 다 동일한 output 디렉터리에 만들어지도록 기본 동작 방식이 바뀌었다. obj 같은 임시 파일들만이 프로젝트별로 자기 고유한 위치에 생성된다. 이것은 나름 바람직한 조치라 여겨진다.

2003 이하	2005 이상
프로젝트1\Release\프로젝트1.exe 프로젝트1\Release\프로젝트1.obj 프로젝트1\프로젝트2\Release\프로젝트2.dll 프로젝트1\프로젝트2\Release\프로젝트2.obj	솔루션\Release\프로젝트1.exe 솔루션\Release\프로젝트2.dll 솔루션\프로젝트1\Release\프로젝트1.obj 솔루션\프로젝트2\Release\프로젝트2.obj

그런데, 발상을 전환하면 DLL을 생성하는 소스를 기반으로 곧바로 EXE를 만들어 DLL의 함수들을 의외로 굉장히 간편하게 테스트를 할 수 있다.
링커의 SUBSYSTEM 옵션 하나만 바꿈으로써 WinMain을 사용하는 GUI 프로그램과 main을 사용하는 콘솔 프로그램을 곧바로 전환할 수 있듯, EXE와 DLL은 똑같이 PE 헤더가 있는 실행 파일이며 본질적인 차이가 거의 없다. 구조체 필드 값이 일부 차이가 나고 entry point에서 같이 전달되는 인자의 타입이 다를 뿐이다.

DLL 프로젝트에서 configuration을 하나 만든다. 테스트와 디버그가 목적이므로 Debug 빌드 것을 초기값으로 가져오면 되겠다. configuration 이름은 Debug EXE 정도로 하자.
그 뒤 프로젝트 속성의 General (일반)으로 가서 Target Extension (대상 확장명)은 .dll이던 것을 당연히 .exe로 바꾼다.
그리고 제일 중요한 Configuration Type (구성 형식)을 Dynamic Library (.dll)이던 것을 Application (.exe)으로 바꾼다.

'확인'을 누른 뒤, DLL 소스의 한구석엔 원래의 DLL엔 없던 WinMain 내지 main 함수를 추가하고, 그 안에다 호출하고 싶은 DLL 클래스/함수들을 마음껏 사용하며 테스트한다.
이것만 해 주면 끝이다. 프로젝트를 이 configuration대로 빌드해서 돌리면 된다.

별도의 EXE를 따로 만들어서 테스트를 하는 거라면 그 EXE에 또 테스트 대상 DLL을 로딩하는 코드가 추가되어야 하지만 DLL 자체의 소스로부터 EXE를 생성하면 그런 번거로운 절차가 필요하지 않으니 더욱 좋다. EXE 자체에 DLL의 코드가 그대로 포함되기 때문이다.

static LIB을 만드는 프로젝트도 이런 식으로 별도의 EXE 생성 configuration을 만들어서 테스트가 가능할 것이다.
다만 DLL/EXE와는 달리 static LIB는 링크 절차가 존재하지 않고 그냥 컴파일만 가능하면 라이브러리 파일이 만들어지기 때문에 이로부터 온전한 EXE를 만들려면 추가적인 링커 설정 같은 게 필요할 것으로 보인다.

2.
여담이다만 DLL뿐만 아니라 EXE도 DLL처럼 export 심벌을 가질 수 있으며 그걸 GetProcAddress를 통해 얻어 올 수 있다.
EXE만 자신이 로딩한 플러그 인 DLL로부터 함수를 얻어 오는 게 아니라, DLL 역시 자신을 로드한 EXE로부터
GetProcAddress( GetModuleHandle(NULL), "GetHostInfo") 이런 식으로 코드를 얻을 수 있다. 이것도 참 기발한 발상이 아닐 수 없다. 어디 활용할 데가 없을까?

내가 개인적으로 굉장히 놀란 것은, 저렇게 한 프로세스 공간의 주인 역할을 하는 EXE가 아니라..
완전히 다른 EXE를 로딩해서 거기에 있는 코드를 실행하는 것도 가능하다는 것이다. EXE는 보통 0x400000 같은 고정된 주소에 로드되며 재배치 정보가 존재하지 않기 때문에 자기 위치에 로드가 못 되면 로딩이 실패한다.

그런데 자신과 로드 주소가 겹치는 EXE도 LoadLibrary를 하면 일단 작업이 성공하며 리소스 추출뿐만이 아니라 GetProcAddress도 실행 가능한 듯하다. 이쯤 되면 EXE와 DLL의 경계가 어찌 되는지가 궁금해진다.

3.
아무 중간 계층 없이 C/C++ 언어만으로 뭔가 라이브러리를 남에게 제공하는 건 애로사항이 적지 않다.

• 디버그 or 릴리스?
• 32 or 64비트?
• 최종 형태는 DLL or LIB?
• VC++ 어느 버전? (보안 기능 링크 에러)
• 사용하는 CRT의 형태는 DLL or static?

이런 식으로 상호 일치해야 하는 변수가 급격히 늘어나기 때문이다. 조건부 컴파일이 괜히 필요했던 게 아니다.
C/C++ 런타임 라이브러리도 비주얼 C++의 버전이 바뀜에 따라 내부적으로 야금야금 더해지고 바뀌는 기능이 있기 때문에--특히 보안 관련-- static 링크하는 경우 빌드 툴의 버전이 안 맞으면 이상한 심벌명에서 링크 에러가 나고 각종 문제가 생기기 쉽다.

그나마 같은 비주얼 C++끼리이니까 망정이지 서로 다른 컴파일러끼리 C++ 클래스 라이브러리를 공유한다면 name decoration까지 문제가 됐을 것이다. 사실상 공유 불가능이다.
옛날에는 문자 집합의 크기(일명 유니코드/ANSI)조차도 변수가 따로 있었을 정도이지만 요즘은 그래도 유니코드, 정확히는 wide string만 고려하면 되니 그건 그나마 나아졌다.

이 문제가 워낙 복잡하니..
일차적으로는 COM 같은 바이너리 표준이 나왔을 것이다.
아니면 그냥 소스 코드를 통째로 넘겨줘서 필요한 사람이 알아서 빌드해서 쓰게 하든가. 그 라이브러리가 애초부터 오픈소스 진영의 작품이라면 다행이지만, 상업용 코드라면 인터페이스 부분을 제외한 나머지에다가는 난독화 처리가 필요할 것이다.

그것도 싫으면 저런 골치아픈 요소들을 싹 잊어버리고 자바/C# 같은 바이트코드 기반으로 가는 수밖에 없는데... 그건 물론 성능은 COM보다도 엄청나게 더 희생시킨 귀결일 것이다.
그래도 아무 클래스에나 public static void Main만 있으면 그게 곧 실행 가능한 물건이고 빌드 속도도 안드로메다 급으로 빠르며 골치 아픈 32/64비트 구분 같은 것도 없는 환경이.. C++ 프로그래머로서 참 부럽게 느껴질 때가 있다.

Posted by 사무엘

PL(프로그래밍 언어)계에서 함수형 프로그래밍 언어는
자동차 엔진으로 치면 로터리 엔진, 발전소 업계로 치면 핵융합 발전 같은 뭔가 이상은 높지만 현실은 아직 좀 시궁창인 그런 떡밥스러운 영역으로 간주되는 것 같다.

전산학을 전공해서 PL 수업을 들은 분이라면 이미 잘 아시겠지만, 프로그래밍 언어란 크게 절차형과 선언형으로 나눌 수 있다.
절차형은 튜링 기계라는 컴퓨터의 특성을 그대로 반영하여 메모리로부터 값을 읽은 뒤 연산을 수행해서 값을 변경하고, 메모리 위치도 바꾸는 절차를 순차적으로 일일이.. 즉 HOW 위주로 기술하는 언어이다. 정보 올림피아드 경시부가 다루는 것은 응당 절차형 프로그래밍 언어를 활용하여 프로그램을 작성해서 문제를 해결하는 능력이다.

(덧붙이자면 튜링 기계에다가 데이터뿐만 아니라 코드, 즉 상태 변환 로직까지 동일한 메모리에다 올려서 해석하는 계산 모델이 바로 오늘날 컴퓨터의 근간이 된 프로그램 내장형, 즉 폰 노이만 모델이다. 자동차 엔진로 치면 정말 외연 기관에서 흡입-압축-폭발-배기 4행정 내연 기관으로 변모한 수준의 발전이 아닌가 싶다.)

한편, 선언형은 우리가 원하는 솔루션의 정의 내지 조건이 이러하다.. 라고만 써 주는 형태의 WHAT 지향형 언어이다. 그러면 컴퓨터가 알아서 문제를 풀어 낸다.
따지고 보면 데이터베이스 질의어인 SQL은 DLL, EXE 같은 실행 파일을 만드는 용도의 언어가 아닐 뿐이지 아주 대표적인 선언형 언어이다. 복잡한 DB에서는 질의어를 만드는 것도 굉장히 복잡한 일이 되며, 두 DB간의 JOIN은 어떻게 시키고 어느 구문부터 풀이해서 최적의 성능으로 질의를 수행할지 결정하는 것도 아주 어려운 축에 든다. 이런 거 성능 소요 시간을 몇 % 단축시키는 알고리즘을 개발해 내면, DB를 연구하는 전산학과 대학원 연구실에서는 그게 곧바로 논문감이 된다.

흔히 인공지능 문제 풀이형 언어로 알려져 있는 프롤로그도 선언형 언어이다. 이건 진짜 여러 변수들을 선언한 뒤 변수들간의 인과관계를 쭈욱 나열해 주면 이를 바탕으로 언어 런타임이 문제의 답을 찾아 낸다.

까놓고 말해 절차형 프로그래밍 언어로 "아인슈타인의 퍼즐" 같은 걸 풀려면, 프로그래머가 재귀호출에 각종 백트래킹 알고리즘을 직접 구사해야 하니 앞에서 말했던 정보 올림피아드 경시부 급의 기술이 필요하다. 그러나 프롤로그에서는 "영국인.집 = 빨강, 스웨덴.애완동물 = 개" 이런 식으로 단서만 주어진 규칙대로 쓴 뒤 쿼리를 날리면 금붕어를 기르는 사람의 국적을 구할 수 있다.

아마 네모네모 로직이나 스도쿠 같은 것도 해답이 갖춰야 할 조건을 명시하는 것만으로 바로 풀 수 있지 싶다. 단서들을 바탕으로 뺑뺑이를 돌리는 추론 과정은 언어 런타임 내지 엔진이 해 준다.
대학 학부 시절, OR개론 수업 때 잠시 접했던 선형계획법 문제 풀이 프로그램인 k-opt도 역시 지정된 문법에 따라 변수와 부등식들을 써 놓고 최소화/최대화 조건을 명시하면 프로그램이 해를 찾아 주니.. 일종의 선언형 프로그래밍 언어 런타임에 속한다고 할 수 있겠다.

그러니, 절차형 언어의 컴파일러는 최적화를 하는 게 기계어 코드 생성이나 멀티코어 병렬화 같은 아주 미시적인 것과 관계가 있는 반면, 선언형 언어의 수행 방식을 최적화하는 것은.. 거시적인 알고리즘 전략까지 결정해야 하니 더욱 까다로울 것이다. 미시적인 건 해당 언어 엔진이 아주 정교하게 구현되어 있지 않은 이상 신경 쓰기 힘들다.

앞서 언급한 SQL이나 프롤로그는 선언형 프로그래밍 언어 중에서 일종의 '논리 지향'인 물건들이다. 그런데 선언형의 하위 범주로는 '함수 지향', 함수형 프로그래밍 언어라는 게 있다. 이게 절차형보다는 좀 더 수학자스러운 형태로 컴퓨터를 부려먹는 방법을 기술하는 방법론이라고 한다. (함수형이 여느 절차형 프로그래밍과 계산 능력이 동등하다는 것은 튜링 기계와 람다 대수가 동치라는 것이 증명됨으로써 알려져 있다.)

순수한 함수형 프로그래밍 언어에서는 지저분한 대입 연산이 없고 한번 생성된 값은 변경 없이 계속 그 값으로 남아 있다. 새로운 값이 계속 생성될 뿐이다. 사실 문자열을 이런 사고방식으로 처리하는 라이브러리나 언어, 프레임워크에서는 이미 있는 문자열을 변경하는 게 굉장히 어렵기도 하다. Windows RT의 String 클래스도 그랬던 걸로 기억..

함수형 언어에서는 대입이 없으니 응당 뺑뺑이 loop도 있을 수 없다. loop을 대신하는 것은 재귀호출이다! loop조차도 기존 값을 계속 바꾸는 게 아니라 새로운 값을 자꾸 만들어 내는 방식으로 구현된다는 뜻이다.
처음에 해답의 범위가 0부터 100 사이에 있었다면 그 다음 턴에는 0부터 50 (log n 시간 복잡도), 혹은 0부터 99로 자가호출이 이뤄지고, 이것이 문제가 완전히 해결될 때까지 반복된다. 왜냐하면 이 문제의 솔루션이 바로 그런 형태로 귀납적으로 정의돼 있기 때문이다. 팩토리얼이든, 두 수의 최대공약수이든, 정렬이든 다른 무엇이든.

이 패러다임에서는 함수가 다른 여느 데이터와 완전히 동일한 수준으로 다른 함수의 인자가 될 수 있고, 특히 이름 없이 함수의 몸체만을 여느 값처럼 달랑 전해 줄 수 있고, 다른 함수로부터 합성되고 유도된 새로운 함수가 함수의 리턴값이 될 수 있다. 새로운 함수가 동작하는 데 필요한 주변 문맥은 클로저라는 물건이 알아서 다 처리해 준다.
C/C++의 함수 포인터에 머리가 굳은 프로그래머라면 calling convension은 무엇인지, this 포인터가 포함된 멤버 함수인지, pointer-to-member라면 다중 상속으로 인한 부가 오버헤드는 없는지 같은 디테일 때문에 머리가 복잡해질 것이다.

함수형 언어에서 if문은 응당 자기 자신도 조건이 만족하는 쪽의 값을 되돌리는 함수 형태이다.
그러나 if는 조건이 만족하는 쪽만 '계산'이 행해질 터이니 if(a) b; else c; 를 나타내는 if(a, b, c)는 통상적인 함수 호출 func(a, b, c)와 의미상으로 완전히 동일할 수는 없다. 예약어로 따로 해석되고 취급을 받아야 할 듯하다.

물론 이런 함수형 프로그래밍 언어가 구현되기 위해서는 현실에서 컴파일러가 최적화해 줘야 하는 것, 그리고 언어 런타임이 해 줘야 하는 오버헤드가 적지 않다. 끝없이 새로운 값을 생성해 내더라도 이제 참조가 끝나서 더 쓰이지 않는 값은 GC가 알아서 제거해 줘야 하고, 재귀호출, 특히 tail recursion 정도는 알아서 메모리 복잡도를 O(n) 급으로 늘리지 않는 일반적인 loop처럼 돌아가게 컴파일러나 런타임이 최적화를 해 줘야 한다. 함수를 값처럼 부드럽게 다루는 것도 기술적으로는 단순 함수 포인터 이상의 추상화 계층이 필요하며, 말처럼 쉬운 일이 아니다.

예를 들어.. X라는 함수가 있는데.. 얘는 a라는 인자를 받고는,
b라는 인자를 받아서 a에다가 b를 더한 값을 되돌리는 Y라는 함수를 되돌린다고 치자.
결국 Y는 X라는 함수가 호출될 때 전달되었던 매개변수 내지 그때 생성된 X 내부의 지역 변수에 의존하여 동작하는데..
나중에 Y가 단독으로 호출될 때는 X라는 함수는 실행이 끝나고 그 문맥이 존재하지 않는다. 이를 어찌하리?
이런 딜레마를 피하기 위해 C/C++ 언어는 애초에 함수 안에 함수를 만드는 걸 지원하지 않는 쪽으로 설계되었으며, C++의 functor 같은 것도 전부 자기가 자체적으로 데이터 멤버를 갖고 있는 객체 형태로 만들어지게 된 것이다.

또한, 아무리 대입이 사이드 이펙트가 남는 지저분하고 기피되어야 하는 연산이고.. 다른 모든 연산을 loop 대신 재귀호출로 때운다 해도.. 당장 외부 파일/키보드로부터의 input은.. 대입 연산 없이는 감당이 도저히 불가능하다. 그리고
return t1.len() > t2.len() ? t1: t2
처럼 그 재귀호출의 결과값을 취사 선택하는 간단한 판단을 위해서라도 임시 변수에 대입하는 것 정도는 근본적으로 전혀 없을 수가 없다.
어디 그 뿐이랴. 대용량의 단일 데이터를 대상으로 여러 함수들이 포인터만 주고받으며 동작하다 보면, 한 함수가 자기 argument 안에 입출력 대상인 모든 데이터를 집어넣는 것은 무리가 있다.

허나 함수형 프로그래밍이 성능면에서 불리한 요소만 있는 건 아니다. 대입으로 인한 side effect 같은 게 없으니 소스 코드의 정적 분석은 더 용이할 것이고 병렬화 등 입맛에 맞는 최적화에도 더 유리할 것이다. 애초에 선언형 프로그래밍 언어는 구체적인 실행 방식은 그런 똑똑한 컴파일러나 언어 엔진에게 맡기고 있으니까.
이러니 PL 분야를 연구하는 전산학자나 수학 덕후들이 함수형 프로그래밍 언어에 더욱 열광하는 듯하다. 저런 패러다임이 응집도· 결합도 같은 소프트웨어 공학적인 측면에서 더 깔끔한 코드를 만드는 데 도움이 되는 것은 덤이다.

대학교 전산학과에서는 함수형 프로그래밍 언어로 보통 Scheme을 실습하는 편이다. 본인도 먼 옛날 학부 시절에 '프로그래밍의 이해(PP)'라는 과목을 통해 그 물건을 접했으며, 그걸로 무슨 다항식의 곱셈을 하는 프로그램도 숙제로 만들고 여러 덕질을 했었다. 함수형 언어의 진짜 본좌라고 일컬어지는 Haskell 같은 건 난 모름.;;

여담이지만 지금 생각해 보니, 온갖 복잡한 괄호가 배배 꼬여 있는 Scheme 코드는.. 언어학에서 문장 구문 분석을 괄호로 표현해 놓은 것과 사뭇 닮았다는 생각이 들었다. (S (NP .. ) (VP ...)) 이러는 식.
Schme에서는 S 대신에 define, lambda, if 따위가 있을 것이다.

물론 그때는 본인은 <날개셋> 한글 입력기 개발에 도움이 안 되는 건 진짜 생까고 무시하던 시절이어서 그 코스의 의미를 제대로 이해를 못 했다. 왜 괜히 계산 과정을 이 따위로 어색하게 표기를 하는지..??
그건 사칙연산 같은 기초적인 연산자조차도 통상적인 표기법이나 우선순위를 깡그리 무시하고 정말로 오로지 함수 위주로.. 프로그래밍이, 아니 계산(computing)이라는 작업 자체를 몽땅 주어진 규칙대로 피연산자들을 처리해서 reduce하는 과정이라고 극도로 추상화한 귀결일 것이다. 일종의 발상의 전환인 것이다. car, cdr 명령이 튜링 기계로 치면 메모리 셀을 이동하고 값을 읽는 동작에 해당할 것이다.

단, Scheme도 마냥 순수 함수형 언어이기만 한 것은 아니다. 필요한 경우 대입 연산이 있을 수 있고 일부 절차형 패러다임 구문을 집어넣을 수도 있다. 마치 C#에서 부분적으로 unsafe, unmanaged 코드를 집어넣듯이 말이다.
그리고 반대로 C++ 역시, 기본적으로 객체지향 패러다임을 주류로 내세운 절차형 언어이지만 최근에는 함수형 프로그래밍 패러다임도 받아들여서 람다 함수를 기존 함수 포인터나 functor의 대용으로 쓸 수 있게 되었듯이.. 요즘 언어들의 대세는 자기 정체성은 유지하면서 다른 패러다임에서도 유용한 건 적극 받아들이는 것인 듯하다.

과연 함수형 프로그래밍 언어가 그저 대학교 과목에서나 잠깐 접하고 마는 떡밥 내지 PL 분야의 연구자들만 쓰는 도구 수준을 넘어.. 현업에서 적극 즐겨 쓰이는 날이 올지 모르겠다. 지금 현업에서 전혀 안 쓰인다는 말은 아니지만 아직까지는 수학 덕후, 컴덕후들의 전유물이라는 인상이 강한 편이니 말이다. 그래도 한 가지 확실한 건, 함수형 프로그래밍 패러다임을 실현해도 될 정도로 요즘 컴터 환경이 좋아지자, 각종 언어들에도 이 패러다임이 적극 많이 도입되고 이게 유행을 타고 있다는 사실이다.

여담으로, 람다 대수를 고안한 앨론조 처치는 family name이 어째 '교회'다..;; 독실한 신자 가문이기라도 했나 싶은 잡생각이 든다.

그리고 궁금한 게 있는데.. 이름 없는 함수에서 재귀호출을 해야 할 때 함수 자기 자신을 가리키는 this, self 같은 키워드는 없는가 싶다.
이 의문은 C++에서 람다 함수가 추가되었을 때부터 여러 프로그래머들에 의해 제기되어 왔다. 하지만 뾰족한 해결책은 없으며, std::function에다가 자신을 저장한 뒤, 그 변수명을 캡처로 도로 넘겨 줘야만 재귀호출이 가능하다. Scheme 역시 일단 def로 자기 이름을 지은 뒤, 그 이름을 호출해 줘야 된다.

재귀호출을 그렇게도 좋아하는 함수형 언어가

[](int x) { return x<=1 ? 1: this_func_itself(x)*(x-1); }

개념적으로 this_func_itself에 해당하는 키워드 같은 건 정말 없는 건지 신기한 노릇이 아닐 수 없다.

Posted by 사무엘

본인이 다니는 교회에서는 교계에 통상적으로 알려져 있는 성탄절과 부활절이 이교도(pagan) 절기와 섞여서 교리적으로 많이 변질된 비성경적인 절기라고 간주한다. 그렇기 때문에 이를 교회에서 공식적으로 지키지 않는다.

물론 그렇다고 해서 예수님의 성육신 탄생 내지 부활 자체를 안 믿는 건 아니다. 단지 예수님의 생일이 12월 25일이라고 가르치지 않으며 크리스마스 트리와 산타 할아버지, 부활절 달걀과 토끼 같은 걸 만들거나 시행하지 않을 뿐이다. 또한, 성경에 예수님의 탄생보다 훨씬 더 분명하고 중요하게 기록되어 있는 예수님의 죽으심을 더 중요하게 기념할 뿐이다(일명 성찬식이라고 불리는 주의 만찬).

예수님의 탄생과 관련된 종교 음악/노래들을 살펴보자.

• I. 그나마 찬송가 축에 들고 성경 고증대로 예수님의 탄생만을 다루고 있는 <천사들의 노래가>, <기쁘다 구주 오셨네> 같은 건 종교 텍스트로 치면 진짜로 영감 받은 66권 성경 정도의 퀄리티일 것이고..
• II. 가사가 성경적인 배경이긴 하지만 크게 교리 측면의 영양가가 없고 찬양으로서의 가치도 별로 없는 노래는 외경 정도의 등급일 것 같다. 어떤 예가 있는지에 대해서는 논란의 여지가 있으니 이 자리에서 밝히지 않겠다.
• III. 그것보다 더 나아가서 아예 눈썰매, 크리스마스 트리나 산타 할아버지만 나오는 수준의 캐롤은.. 딱히 기독교와 교리적인 관계가 있다고는 볼 수 없고 위경에 가까운 레벨이라고 간주해야 할 것이다.

물론 외경, 위경급이라고 해서 그게 일고의 가치가 없는 쓰레기이고 배척하자는 건 아니다. 개인적으로 그런 노래 들으면서 연말연시 크리스마스 분위기를 즐기는 것 자체를 나쁘다고 할 수는 없다. 크리스마스가 아무리 세속화했다고 해도 아예 대놓고 드루이드 교의 마귀적인 의식에 기원을 둔 할로윈보다는 낫지 않은가.
다만, 즐기더라도 오늘날의 크리스마스가 성경이 말하는 기독교와 직접적인 연결 고리가 있지는 않다는 건 알고서 즐길 필요는 있다. 고증상 예수님의 실제 탄생일은 유대인 절기 중의 장막절에 속하는 가을, 우리로 치면 오히려 추석과 더 가깝다.

뭐, 그런 배경에도 불구하고 서양에는 12월 25일 크리스마스가 우리로 치면 꽤 중요한 공휴일이다. 한중일 중에서는 대한민국 우리나라만이 유일하게 정부 수립 극초반부터 이례적으로 공휴일로 지정됐다. 이건 빼도 박도 못하고 초대 대통령이 기독교인이었던 덕분이라 해도 과언이 아니다.
우리나라는 11월에 공휴일이 전혀 없는 관계로, 10월 9일 한글날 이후의 공휴일은 거의 70여 일 뒤인 성탄절이다. 12월 25일은 학교에서는 대개 겨울방학이기 때문에 성탄절은 근로자의 날과 더불어, 학교 졸업하고 직장인이 되고 나서야 존재감이 느껴지기 시작하는 양대 공휴일이다.

다시 본론으로 돌아와 오늘은 캐롤 얘기를 계속하겠다.
캐롤은 우리나라에 가사가 번역되어 소개된 <징글 벨>, <울면 안 돼>, <루돌프 사슴코> 같은 게 있는데 그냥 초등학교 음악 책에나 나오는 쉬운 동요 수준으로나 알려져 있다.
뭐, <탄일종>은 크리스마스 컨셉을 꽤 우회적으로 표현한 국산 동요이고, <성탄제> 같은 시도 있으니 국산 컨텐츠가 아주 없는 건 아니지만.

하지만 외국에서는 우리나라 정서와는 사뭇 다른 크리스마스 노래가 많이 있으며, 그리고 비교적 최근까지도 신곡이 나오고 있다. 짤막한 동요보다야 더 큰 스케일로 말이다.
<화이트 크리스마스>, <실버 벨> 같은 것들은 다 1940~1950년대에 발표된 곡이다. 세상에 알려진 지 100년이 채 지나지 않았다.
국내에 번역되지 않은 곡으로 내가 아는 것만 열거해 봐도 Do you hear what I hear라든가, 프랑스의 Chants De Noel, The Christmas Song이 있다. 특히 The Christmas Song의 경우 어렸을 때 경험했던 크리스마스 파티에 대한 추억을 굉장히 서정적으로 묘사했다. 첫 단락만 대충 의역 스타일로 옮겨 보면...

중간엔 “Everybody knows a turkey and some mistletoe”(칠면조 요리와 겨우살이풀. 다들 잘 알지요) 라는 대사가 있어서 본인은 mistletoe라는 단어를 여기서 처음으로 접했다.
크리스마스 장식용으로 이 식물이 이런 식으로 쓰이는가 보다. 우리나라 정서상으로는 everybody knows라고 할 수는 없을 듯. 참고로, 아래 그림에서 딸랑딸랑 소리 나는 종이 말 그대로 jingle bell이다.

그래도 나중에 Enya의 White is in the winter night이라는 캐롤 스타일의 노래를 들으니 저 캐롤이 같이 떠올랐다.

위의 그림을 같이 보시라. 풀잎은 green이고 holly(열매)는 빨갛다. 저 문화권에서는 겨우살이풀에 저런 심상이 담겨 있는가 보다. “아 아버지가 눈을 헤치고 따 오신 그 붉은 산수유 열매”(성탄제)가 문득 떠오르기도 하고.

뭐, 종교적인 면을 빼고 생각하자면, 연말을 앞두고 이렇게 촛불 켜고 칠면조구이를 먹고 사람들끼리 선물을 주고받는 명절이 있다는 것 자체는 본인 역시 좋고 훈훈하다고 생각한다. 교회에서 성경 운운하면서 교리적으로 하지만 않는다면 말이다.

이런 일체의 관행 자체를 계 11:10의 부정적인 장면과 연관 시키면서 굉장히 부정적으로 보는 분들도 있는데.. 그렇게까지 과민반응을 보일 필요는 없을 듯.
마치 성경에서 생일이 부정적으로 나온다고 해서 친구들끼리 일체의 생일 잔치까지 괜히 나쁘다고 매도할 필요는 없듯이 말이다. 그건 그저 사람마다 받아들이기 나름인 재량의 영역이 아닐까 한다.

(창세기 파라오의 생일, 복음서 헤롯의 생일. 다 적그리스도를 예표하는 왕이며, 그 생일 잔치에 하필이면 사람이 죽는다. 각각 빵 굽는 시종장과 침례자 요한. 보통 왕의 생일 정도면 국가적으로 아주 경사스러운 잔칫날이며, 사형 집행은커녕 죄수들을 사면하고 풀어 주는 날인데 저건 굉장히 이례적이고 이상한 사건이다)

어쨌든, 방문자 여러분께 메리 크리스마스 인사를 드리는 바이다.

Posted by 사무엘

2014년 한 해 동안은 국군 전방 부대에서 불미스럽고 안타까운 소식이 둘이나 있었다.
다른 계급도 아니고 전역을 겨우 3개월 남짓 앞두고 있던 어느 병장이.. 지금까지 쌓인 게 얼마나 많았으면 돌연 총기 난사 + 무장 탈영이라는 초대형 사고를 쳤다. 그리고 총격전까지 벌인 끝에 자기 인생은 물론 여러 동료 병사와 주변 간부들의 인생까지 덩달아 쫑치게 만들었다.

그 뒤 지난 여름엔 어느 폐쇄적인 부대에서 한 병사가.. 구타와 가혹행위를 견디다 못해 하다못해 저렇게 총기 난사를 벌이거나 혼자 자살한 것도 아니고.. 진짜 순수하게 맞아 죽는 초유의 참극이 벌어졌다. 거의 군대판 '일본 여고생 콘크리트 살인 사건, 인디애나 주 실비아 라이컨스 사건'이나 다름없다.

유 관순 열사가 사형이나 고문치사나 병사가 아니라 간수들에게 순수하게 맞아 죽었다고 최근에야 밝혀졌는데.. 나라 지키러 간 군인이 변태 가학적인 악마 아군에 의해 그렇게 죽은 것이다. 동물이나 심지어 적군 포로에게라도 해서는 안 될 몹쓸 짓을 당한 것이다. 이러니 오죽했으면 군대에서 “참으면 윤 일병처럼 되고, 못 참으면 임 병장처럼 된다”라는 웃을 수만은 없는 블랙코미디가 나돌 정도였다.

군대에서 차라리 제2 연평해전 전사자들처럼 적과 싸우다가 적군의 총탄에 산화한 거라면.. 그 무엇도 목숨과 바꿀 수는 없겠지만 그래도 제일 영예로운 죽음이긴 하다.
천안함의 경우는 적군들 얼굴도 못 보고 전투다운 전투를 못 벌이고 전사자가 발생했으니 위의 경우보다는 좀 더 원통하고 안타깝지만, 그래도 그것만으로도 충분히 영예로운 일이다.

다음으로 훈련이나 다른 근무· 작업 중에 사고로 죽은 거라면 위의 경우보다 더 허무한 축에 들 것이다. 그러나 이 역시 엄연히 나라 지키다가 순직한 것이다. 그런 죽음이 전혀 없을 수는 없다.
하지만 전투력과 아무 관계가 없는 저런 병폐로 인한 원통하고 억울한 죽음은 도대체 어떻게 해야 근절할 수 있을까?

이런 일을 예방하겠답시고 동기들만으로 구성된 소대를 만들겠다는 안이 나왔는데, 이 역시 멍청한 생각이 아닐 수 없다. 동기들만으로 구성된 학교 학급 안에도 양아치와 일진들이 포진해서 “나보고 형이라고 불러” 이러는 걸 정녕 모르나 보다. 문제의 근원이 계급에 있는 게 아니다. 저건 문제의 본질을 잘못 짚어도 한참 잘못 짚었다.

좀 더 훈련이 혹독하고 힘들어도 좋으니 군대가 일과 후 시간 동안에는 병사들의 사생활을 조금이라도 더 보장해 줄 수 없을까? 거의 모든 병영 스트레스는 내무 생활 때문에 발생하는 것이니 말이다. 본인이야 뭐 자대 생활을 하지도 않았고, 군대 행정 같은 건 비전문가이니 그저 이런 생각만 부질없이 늘어놓을 뿐이다.

이제는 우리나라도 모병제를 해서 진짜 군대에 갈 의향이 있는 사람들 위주로 전문화된 군대를 꾸며야 한다는 말이 있지만 이 역시 현실은 녹록치 않은 것 같다. 오히려 극심한 저출산 때문에 지금처럼 강제 징병을 하고도 군대에 갈 사람이 부족한 듯하다. 거기에다 복무 기간은 1년 9개월까지 단축되어서 사정은 더욱 심각한 듯. 징병 검사는 갈수록 엄격해지고 있고, 덕분에 소총을 쥐어 줘도 될 정도로 정상적인 신체와 멘탈을 갖추지 못한 사람까지 입영하는 바람에 사고가 발생하는 빈도도 느는 듯하다. 즉, 문제의 원인과 해결책을 모병제와는 정반대 방향으로 진단하는 견해도 있다는 뜻이다.

또한 정말로 순수하게 모병제인 일본 자위대는 한국보다 시설 복지가 더 우수함에도 불구하고 그 안에서도 구타· 가혹행위가 만연하며 단위 인원당 자살자 비율도 “더 높다”. 애초에 우리나라 국군도 해병대는 순수하게 지원자로만 구성되어 있지만--비록 일단 군대 자체는 무조건 가야만 하는 상황에서 병과· 직종만이 지원제인 것이긴 해도-- 2011년 한 해 동안 온갖 불미스러운 사고는 다 터지지 않았던가. 이 문제에 관한 한 징병이냐 모병이냐가 본질적인 문제는 아닌 것 같다.

1년에 우리나라 군대에서 자살하는 장병의 수가 옛날에는 세자리 수였다가 그래도 21세기에 들어선 뒤부터는 수십 명 수준으로 줄었다. 비록 우리나라 국군이 병사 월급이 매우 적고 복지와 보상이 안습한 수준이며 가끔 저런 대형 사고가 터지고는 있지만, 그렇다고 해서 국군 내부의 인권 실상이 겨우 북한 따위에게 디스를 당할 정도는 절대로 아니다.

그리고 만에 하나 인권 실상이 좋다고 해 봤자 북한은 고등학교를 졸업한 뒤에 남자가 10년, 여자가 7년간 군대에서 '썩어야' 하는 나라이다. =_=;;; 그것 자체가 나라의 미래인 청년들에 대한 넘사벽급의 인권 유린이지 않겠는가? 우리나라에서는 애초부터 국비로 양성된 육사 출신 장교나 복무할 만한 기간을 저쪽 동네에서는 병들이 복무하는 것이다.

아무튼, 군대에서 다시는 저런 비극이 발생하지 않기를 '앙망'한다. 내가 개인적으로 바란다고 해서 저런 일이 또 안 터지지는 않겠지만.
이런 일을 빌미로 평소에 동성애자에 대한 생각이 불건전하던 사람, 국가관이 이상하던 사람들이 옳다구나 물어뜯고 군대에 대해서 대안 없는 비난이나 늘어놓고 감 놔라 배 놔라 하는 광경도 보고 있자니 개인적으로 심기가 무척 불편했다.

예나 지금이나 군 복무는 국민의 의무이지만 한편으로 내 인생에서 적지 않은 분량을 국가의 이름으로 희생시키고 착취당하는 일이다. 군대에 갔다간 나도 위에서 열거한 저런 험한 꼴의 주인공이 될 것 같고..
그래서 기를 쓰고 군대에 안 가려는 병역기피 범죄가 많았다. 또한 마지못해 입대는 했지만 그 뒤 견디다 못해서 도망가 버리는 사람이 종종 발생하곤 했다. 이름하여 탈영이고 법적 용어로는 군무이탈이다.

군대는 안 그래도 사기와 기강이 중요한 엄격한 집단이며 군대에 가고 싶어서 선뜻 간 사람은 별로 없다. 이런 와중에 국가가 탈영병을 집요하게 추적해서 잡아 주지 않으면, 까놓고 말해 탈영 안 한 사람이 바보가 될 지경이 되면 군대가 제대로 유지되지 못한다. 그래서 탈영은 국민의 의무 수행에 대한 형평성을 보장하기 위해서라도 '탈세'만큼이나 굉장히 큰 범죄로 간주된다. (물론 애초에 군대를 불법으로 뺀 병역기피하고 형평성이 안 맞다는 비판은 좀 있지만)

하지만 무작정 탈영병을 흉악범마냥 취급하는 것도 어폐가 있다. 다른 모든 범죄들은 신체의 자유가 있는 상태에서 자기가 고의로 나쁜짓을 저지른 경우이지만, 군무이탈은 국가가 개인으로 하여금 신체의 자유를 군대 안으로 속박하려고 하는데 그걸 견디다 못해 법을 어긴 경우이기 때문이다. 범죄하고는 아무 상관 없이 살았던 청년이 한 순간의 잘못된 선택으로 인해서 흉악범과 동급으로 취급되고 무작정 법의 철퇴를 맞고 전과자 되고 인생 종치는 건 국가적으로도 손해이다.

이렇게 탈영병 내지 군무이탈자는 법적으로 예외 없이 단호하고 무겁게 다뤄야 하는 한편으로 정상을 참작하여 아량도 베풀어야 하는 이중적인 면모가 있는 것 같다. 그래서일까?
국군에서는 정기적으로(대략 3년 간격) 육해공 참모총장이 전국의 탈영병들을 상대로 복귀 명령을 내린다. 공고문이 철도역이나 버스 터미널 같은 데에 다 게시된다. 이 특별 기간(대략 2개월 남짓)에 탈영병이 자수를 하면 지금까지 탈영해 있었던 기간에 구애됨이 없이 정상을 참작하여 “최대한 관대하게” 처분해 주겠다는 당근(?)까지 제안한다.

이것은 여러가지 효과를 노린 것 같다.
탈영 기간에 비례해서 처벌의 수위가 마치 채무 이자마냥, 주차장이나 도서관의 연체료마냥 눈덩이처럼 불어난다면 장기 탈영병은 탈영 기간이 길어질수록 자수 의욕을 잃고 아예 자살 같은 더 극단적인 선택을 할 가능성이 높아진다. 이것은 개인에게나 국가에게나 좋은 결과가 아니다.

그렇다고 마냥 무조건적으로 봐 줄 수만은 없으니 저렇게 군대판 “어서 돌아오오”를 정기적으로 시전하여 특정 기간에만 미끼를 내던지는 게 군무이탈자들의 심리를 동요시키는 효과도 있고 적절해 보인다.
거기에다 탈영에 대한 실질적인 공소시효를 최대한 늘리는 건 덤이다. 40대 초중반의 나이까지 끝까지 탈영 안 하다가 붙잡히면 나중에는 군무이탈에 대한 공소시효는 끝나더라도 '명령 불복종죄'로 처벌할 수가 있게 된다.

그런데 여기서 한 가지 의문이 생긴다.
지금까지 내려진 군무이탈자 복귀 명령을 보면.. 적용 대상이 “1963년 12월 1일 이후로 육해공군 복무 중에 군무이탈 중인 자”라고 돼 있다.

현재까지 잡히지 않은 가장 오래 된 탈영병이 탈영한 때가 1988년이라고 알려져 있다. 이 정도면 사실상 죽었거나 외국으로 밀항한 수준이 아닌가 싶다.
그런데 왜 기준 날짜가 지금으로부터 무려 반세기 전, 비현실적으로 까마득하게 먼 과거인 1963년인 걸까? 작정하고 엄청난 옛날을 잡고 싶거들랑 아예 “1940년대 말의 건군 이래로”, 혹은 “1953년 휴전 이래로”라고 해도 될 텐데? 궁금하지 않으신지?

그 이유는 국가에서 1963년 11월 30일과 그 이전에 발생한 탈영은 모두 정식으로 사면을 해 줬기 때문이다. 옛날에는 나라가 워낙 혼란스러웠고, 개인 사정상 도저히 불가피한 생계형 탈영도 있었을 테니 말이다.
저 때는 박 정희가 군복을 벗고 제5대 대통령으로 당선된 지 얼마 안 된 시기였는데, 민생 안정을 위해 이것저것 여러 조치가 취해지곤 했다. 역사 기록을 찾아 보면, 공교롭게도 출입국 관리법 위반자도 1963년 11월 30일 이전 것들은 다 사면해 줬다고 한다.

1963년은 한국 철도사에서는 서울교외선이 전구간 개통한(8월) 해이다. 그 이전의 1962년엔 군사 정권이 들어섰고 경제 개발 5개년 계획이 수립됐다. 그리고 이때 현재까지 우리나라 역사상 최후의 화폐 개혁이 행해져서 '원'이라는 단위가 쓰이기 시작했다. 1962년은 박통 정부가 독립 운동가들을 국가 차원에서 대대적으로 찾아내어 훈장을 추서하고 예우한 해이기도 하다. 유 관순, 윤 봉길 등 네임드급 인물들이 다 이때 훈장을 받았으니 말이다.

1963년 12월 1일이라고 하면 바로 그 정도로 옛날이라고 생각하면 된다. 물론 대한민국이 이 정도로 시스템과 기강이 잡힌 이상, 앞으로 정부가 군무이탈자들을 사면하는 일은 지금 같은 상황에서는 두 번 다시 없을 것이다.

현재까지 행방이 묘연하여 수배 중인 누적 탈영병의 수는 역시나 전군을 통틀어 70여 명 수준이라고 하는데, 공교롭게도 연간 군대에서 발생하는 자살자 수와 얼추 비슷하다. 탈영하고도 안 잡히려면 이 사회에서는 주민등록도 말소되고 그야말로 완전 '없는 사람'으로 지내야 한다. 따로 국가나 군대에서 처벌을 안 해도 그렇게 매장당한 채 고생하는 것 자체가 탈영에 대한 처벌이나 마찬가지이다.

얼마 전에는 어떤 사람이 과거에 열차를 상습적으로 몰래 무임승차 한 것이 마음에 걸려서 무임승차 금액을 변제한다고 코레일에 100만원을 기탁하고 간 훈훈한(?) 사례가 있었다. 그 사건들은 이제 증거도 없고 공소시효도 옛날에 다 지났으니 100만원은 코레일의 입장에서는 그저 기부액이나 마찬가지가 됐다.

마치 그것처럼, 지난 2006년엔 한번은 무려 18년 가까이를 도피 생활을 하는 바람에 심지어 가족하고도 연락이 끊어져 버린 30대 후반의 안타까운 아저씨가 끝내는 자수한 경우가 있었다. 이런 사람은 군대의 입장에서도 병사로 막 부리기가 민망하니.. 그는 1개월 남짓만 형식적으로 병영 캠프를 하다가 복무 부적격 심사에 통과되어 어쨌든 드디어 정식으로 전역했다고 한다.

아무쪼록 우리나라 군대가 탈영병이 발생할 일이 없을 정도로 내부 부조리와 비극이 없는 군대가 되기를 간절히 염원해 본다. 월급을 많이 못 주더라도 병사들의 마음을 사는 방법은 다른 쪽으로도 얼마든지 있기 때문이다.

Posted by 사무엘

오뚜기 3분 고기덮밥은 본인이 태어나서 최초로 접한 레토르트 파우치 식품이다. 물론 밥까지 들어있는 건 아니기 때문에 덮밥 '소스'일 뿐이라고 단서가 자그맣게 붙어 있다.
영문 명칭 Goulash에서 알 수 있듯, 얘는 유럽풍의 매콤한 쇠고기 스튜 요리에서 컨셉을 따 온 듯하다.

처음 먹었던 때가 20여 년 전 초딩 중저학년 시절이었는데, 본인은 그때부터 이걸 굉장히 좋아했다. 비슷한 상품인 3분 짜장, 카레, 하이스보다도 더.
그 시절에 고기덮밥의 개당 가격은 700얼마 정도 했었다.

그런데 어느 샌가 이 고기덮밥은 상점에서 자취를 감추기 시작해서 더는 찾아 먹을 수가 없게 됐다. 유사 상품들도 다 변함없으며, 햄버그 스테이크나 미트볼도 지금까지 멀쩡히 팔리고 있는데 유독 고기덮밥만 없어진 것이다. 펭귄 통조림은 회사가 망하면서 단종된 게 맞지만, 고기덮밥은 왜 혼자서 단종됐지..??

그러나 여기에도 반전이 있었다. 없는 게 없는 인터넷 쇼핑몰을 뒤져 보니 고기덮밥은 멀쩡히 잘 팔리고 있었다. 이에 본인은 곧바로 12개짜리 패키지를 질러서.. 오랜만에 옛날 맛을 즐겨 보았다. 냠냠~

얼마 전엔 계몽사에서 에메랄드 색 '어린이 세계 명작 전집'을 재판해서 판매하자 옛날 추억에 잠긴 독자들이 많이 주문을 했었다... 내가 바로 그런 심정이다. 단지 이번엔 동화책이 아니라 인스턴트 식품일 뿐.

유통기한이 2016년 여름일 정도로 지금까지도 멀쩡히 잘 생산되고 있는 물건인데
왜 오프라인 상점에서는 편의점부터 홈플러스/이마트 등 대형 마트까지.. 좀체 물건을 찾을 수 없는지 난 이유를 도저히 모르겠다. 3분 고기덮밥을 오프라인 상점에서 목격하신 분(증명-_-), 혹은 반대로 그게 왜 온라인으로만 판매되고 오프라인 상점에서는 사라졌는지 이유를 아시는 분은 본인에게 제보해 주시길 바란다.

* 나같은 사람이 맛집이나 음식 소개를 한다는 건 정말 이례적인 일이다.. 전선 휴게소 메기 매운탕에 이어 음식 소개는 이번이 거의 두 번째이다. ㅎㅎ

Posted by 사무엘

우리 주변에서 연료를 태워 열 내지 에너지를 만드는 도구, 기계들을 생각해 보자.
하긴, 옛날에는 불을 최초로 피우는 것조차도 여간 어려운 일이 아니어서 집집마다 한번 만들어 놓은 불씨를 잘 간수해야 했으며, 옛날까지 갈 것도 없이 무인도 같은 오지· 험지에 홀로 내던져졌다면 불을 피우는 게 매우 중요한 생존 기술 중 하나로 변모한다. 성냥, 양초 같은 물건도 주류에서 밀려난 구시대 유물일지언정 완전히 없어질 수는 없을 것이다.

이렇게 연소나 폭발을 취급하는 물건들은 어떤 형태의 연료를 쓰는지에 따라 설계 방식이나 동작의 특성이 달라진다.
연료라는 건 크게 고체 아니면 액체로 나뉜다. 고체는 나무나 석탄, 혹은 다른 고체 폭약 같은 것이고, 액체는 잘 알다시피 석유나 액화 천연가스가 대표적이다.

일반적으로 액체 연료를 다루는 기계적 메커니즘이 고체 연료보다 더 복잡하고 까다롭다.
그러나 액체 연료가 그만큼 연료를 아주 찔끔찔끔 균일하게 공급하면서 화력을 조절하기가 더 쉽다. 그리고 연소 후의 부산물도 액체 연료가 훨씬 더 깔끔하며 처리하기가 더 편하다.

고체 연료를 사용하는 연탄/화목 보일러나 난로는 불에 탈 수만 있다면 통나무건 종이 뭉치건 아무 덩어리나 집어넣어도 되니 기계 구조가 간단하고 당장 열을 만들어 내는 건 쉽다. 하지만 그 뒤부터는 여러 모로 불편한 점과 애로사항이 꽃핀다. 매캐한 연기와 냄새가 나며, 일단 불이 붙은 연료를 통제하기가 어렵다. 점화나 소화를 스위치 하나로 간편하게 할 수가 없다.

연탄은 크기와 모양이 규격화돼 있는 고체 연료라는 점은 그나마 낫지만, 여전히 점화와 소화가 불편하며 연료를 배달하기가 매우 번거롭다. 매번 연탄재를 처리하는 것도 큰일이고 말이다.
양초는 고체 연료인 것치고는 심지를 통해 연소가 균일하게 잘 일어나는 편이지만, 역시나 강약 조절을 할 수 있지는 않다.

옛날에 증기선이나 증기 기관차에는 보일러에다 석탄을 삽으로 퍼 넣는 화부가 탑승해야 했으며 즉각적인 동력 조절이 되지 않았다. 고체 연료 화통의 화력은 공기를 불어넣는 양 정도로나 조절 가능했다. 성경의 다니엘서에서 풀무불을 평소보다 일곱 배나 더 뜨겁게 하는 건 과연 기술적으로 어떻게 실현했을까? (단 3:19)

이것은 발사체인 고체 연료 로켓도 고스란히 갖는 한계이다. 한번 점화가 된 뒤에는 연료의 연소를 일시적으로 중단하거나 동력 조절을 할 수 없으며, 가능하다 해도 그 과정은 몹시 어렵다.

이런 이유로 인해 요즘은 관광용 증기 기관차도 물을 끓여서 나아갈지언정, 물을 데우는 건 석탄이 아닌 석유로 한다.
그리고 로켓에는 액체 연료 로켓이 연구되었으며, 이 바닥의 선구자는 미국의 물리학자 로버트 고다드이다. 우리말 표기로는 '더'와 '다'가 공존하면서 혼란스러운 이름인데...

공기가 없는 우주에서도 움직이는 액체 로켓은 연료 자체뿐만이 아니라 산화제까지 액체여야 하기 때문에 고체 로켓보다 만들기가 더욱 어려웠다. 증발이나 부식 같은 문제 때문에, 산화제와 연료를 주입한 채로 로켓을 장시간 발사대에 놔 둘 수 없다는 점도 대단히 번거로운 점이다. 로켓의 발사가 연기된다거나 하면 그것들을 도로 빼내야 한다.

그럼에도 불구하고 액체 연료 발사체 기술 덕분에 인간이 우주로 나갈 수도 있을 정도로 안정적이고 통제 가능한 발사체가 만들어질 수 있게 되었다.
라이트 형제가 동력 비행을 성공한 지 30년이 채 되지 않아 미국의 학계에서는 로켓의 이론적 근간이 연구되고 “달까지 가는 진지한 방법” 같은 게 논문으로 발표되고 있었다니 정말 대단한 일이 아닐 수 없다. (한때는 그랬는데 미국이 어쩌다가 스푸트니크 멘붕을 당할 정도로 잠시 주춤했는지?)

단, 고다드의 연구는 시대를 너무 앞서 있었으며, 그 당사자 역시 언플이나 사교력이 뛰어난 공돌이는 아니었던 관계로... 그의 연구는 그가 살아 있는 동안에는 딱히 인정을 못 받았다. 1920년대에 뉴욕 타임스 신문은 고다드가 불가능한 목표를 두고 아무 쓰잘데기 없는 황당한 뻘짓을 한다고 막 조롱하고 디스하고 망신 주는 사설을 게재했을 정도였다.

그러나 그로부터 수십 년이 지나고 고다드의 연구를 토대로 새턴 로켓이 발사되고 아폴로 우주선이 달까지 간 뒤에야 뉴욕 타임스는 자기네 옛날 사설을 취소하고 고인에게 사죄를 했다. “그런데 그것이 실제로 일어났습니다. 님의 연구 덕분에 후손들이 달에 진짜로 갈 수가 있었습니다. 우리의 생각이 짧았습니다.”라는 요지로.

이건 20세기의 우주 개발 역사에서 매우 유명한 일화이다. 우리나라로 치면 일제나 독재 정권에 아부하던 메이저 언론이 나중에 자기 잘못을 스스로 인정하고 사죄한 것과 완전히 같지는 않아도 비슷한 격인데, 우리나라 언론에서는 찾기 힘든 모습인 것 같다. =_=;;

이것저것 얘기가 많이 나왔는데..
여러 분야를 막론하고 액체 연료는 고체 연료에 비해 점화· 소화와 화력 제어가 용이하고 연소 결과가 깨끗하다는 많은 장점이 있음을 알 수 있다.
이제는 친구들과 삼겹살을 구워 먹으러 갈 때도 고체 연료(숯)를 쓰는 식당과 액체 연료(도시 가스)를 쓰는 식당의 구조적인 공통점과 차이점을 나눠서 생각할 수 있을 것이다. 다만, 고기를 굽는 데는 '연기와 향'이라는 변수가 추가되기 때문에 굳이 경제적으로는 더 불편한 고체 연료가 선호되기도 한다. ^^;;;

Posted by 사무엘

1.
우리나라가 옛날보다는 소프트웨어 불법복제에 대한 경각심이 좀 생겼고 불시단속도 강화된 관계로..
기업들 역시 대기업· 중소기업을 막론하고 직원들의 컴퓨터에 혹시 불법복제 소프트웨어가 깔려 있는지 자체 단속을 하는 편이다.
그런데, 그런 소프트웨어 자체를 생산하는 일을 하는 IT 기업에서는 추가적으로 민감한 물건이 더 있다.
자사가 개발하는 제품의 내부에 혹시 오픈소스 솔루션이 예기치 않게 들어가지 않느냐 하는 것이다.

당장 돈을 안 들이고 원하는 문제를 쉽고 빠르게 해결할 수 있다고 해서 출처 명시 없이, 혹은 라이선스가 요구하는 사항을 이행하지 않고 그런 솔루션들을 자기 소스 코드에다 불쑥 집어넣었다가는..
글쎄, 그 회사와 회사 제품이 완전 듣보잡 마이너 내수급이라면 별로 문제되지 않고 넘어갈지 모른다.
그러나 외국으로도 널리 널리 쓰이고 돈을 빗자루로 긁어모으는 인기 프로그램이라면 얼마 못 가 당연히 걸리고 발목 잡히게 된다.

왕년에 병역비리 내지 논문 표절을 저지른 사람이 나중에 고위 공직자가 되려 할 때 청문회에서 탈탈 털리듯이 말이다.
오픈소스를 표방하는 자유 소프트웨어라고 해서 저작권이 전혀 없는 게 아니기 때문이다. 아무나 완전히 제멋대로 고치고 이득을 챙겨도 되는 '인류 공용 자산'급인 public domain이 아니다.

방대한 분량에 복잡한 로직을 가진 소프트웨어는 설령 소스 코드가 있다 해도 누가 함부로 찔끔찔끔 고칠 수 있는 물건이 아니다. 그래서 그런지 설령 컴파일된 바이너리이고 소스 코드가 없다 하더라도, 여기에 어떤 오픈소스 솔루션이 무단으로 포함되었는지 정도는.. 오픈소스 진영에서 매의 눈으로 감시해서 다 적발해 낸다. 컴파일된 바이너리 코드의 패턴 분석을 정교하게 하는 듯.

그래서 그렇게 자기는 이윤을 챙기면서 엔진 내부에 무료 오픈소스를 무단으로 사용한 양심불량 소프트웨어는 hall of shame 같은 데에 올라서 업계에서 국제적으로 망신을 당하며,
GPL 라이선스 급의 오픈소스를 잘못 따다가는 그걸 사용한 프로그램 전체에 대해 소스 공개라는 형벌(?)을 당하게 된다. 실제로 그런 소스 공개형을 당한 사례도 몇 건 있다. 물론, 프로그램 소스만 공개이지 그 소프트웨어 제품에 사용된 각종 데이터나 리소스까지 죄다 공개는 아니기 때문에 완전한 기술 유출은 아니다.

대기업의 경우, 자사 직원들만치 꼼꼼하게 감시하지는 않는 하청업체로부터 납품받은 소스에 이런 지뢰가 들어있어서 골탕을 먹는 경우가 있는 모양이다. 그래서 납품 계약을 할 때부터 그 솔루션에 오픈소스 저작권 문제가 확실하게 없다는 걸 확인시키며, 문제가 생길 경우 이런 책임을 지우겠다는 식으로 얘기를 하는 걸 본인은 업계에서도 경험했다.

여담이지만, 요즘은 응용 언어학에서 다루는 말뭉치(코퍼스)에도 저렇게 저작권 바람이 불고 있다.
그래서 국립 국어원에서도 21세기 세종 계획 성과물로서 세종 말뭉치를 배포하다가.. 저작권이 문제가 되는 데이터를 빼고 분량이 다소 감소한 말뭉치를 새로 배포하기 시작했다. 그 얘기를 들으면서 IT업계의 오픈소스 얘기가 문득 떠올랐다.

2.
요번 학기에 학교에서 오픈소스와 관련된 세미나 수업을 들었다. 오늘날 IT 업계에서 오픈소스라는 트렌드가 차지하는 비중을 더욱 절실히 알 수 있었다. 자유 소프트웨어는 무엇이고 오픈소스 소프트웨어는 무엇인지, 그리고 리눅스 진영과 리처드 스톨먼 진영의 차이는 무엇인지 예전에는 거의 관심이 없었고 아는 게 없었는데 이제 좀 어렴풋이 알게 되었다. 유익했다.

오늘날은 정말로 거의 모든 분야에서 github, sourceforge 같은 오픈소스 진영의 저작물을 이용하지 않고는 실용적인 프로그램을 만들기가 대단히 어렵거나 가성비가 안 맞아 의미가 없는 지경이 되었다. 그 오픈소스 진영에서 활동한 이력은 만천하에 공개된 자기 스펙과 자산이 되기 때문에, 당장 소프트웨어의 무료 공개로 인한 금전 손실 이상의 이득이 돌아온다는 말에는 공감이 됐다.

확실히 IT 업계에서 경력을 쌓는 방식의 패러다임이 바뀌긴 했다. 내 지인 중에서도 이 바닥에서 워낙 유명한 사람이 있다. 그 친구는 이런 수업 따위는 들을 필요가 없거나, 아니면 나처럼 따로 자료 찾으며 과제를 낑낑대며 할 필요조차 없이, 평소에 하던 오덕질을 갖고 학점 따위 그냥 날로 먹는 게 가능했을 것이다.

내게 오픈소스라는 건, 이거 소스 코드 하나쯤은 공개해 버려도 내 밥줄에 아무 지장 없고 그것보다 더 나은 것 정도는 얼마든지 또 만들어 낼 수 있고, 이 프로그램의 UI, 데이터 파일들을 업계 표준 관행으로 굳히는 효과까지 노릴 수 있는 괴수들의 전유물일 뿐인 것 같다. =_=;; 물론 그런 진영에서 기여를 하는 프로그래머들이 매우 고마운 대인배인 건 사실이지만, 일단은 무슨 희생, 헌신, 자선 행위라기보다는 “가진 자의 여유” 구도라는 것이다.

또한, 마냥 다 공개하는 게 능사만은 아닐 텐데.. “경쟁자가 따로 이득을 보기 vs 경쟁자를 원천 견제하고 차단하기”라는 결말의 차이가 어떤 과정에서 생기는지 궁금하다. 가령, IBM은 하드웨어계의 오픈소스라 할 수 있는 PC 규격을 내놓았고 그게 결국 세계를 평정하긴 했지만, 이 때문에 정작 자기는 아무 이득도 못 보고 PC 사업에서 손을 떼게 됐단 말이다.

id 소프트웨어에서도 둠과 퀘이크의 소스를 공개하긴 했지만, 그래도 해당 세대의 기술이 충분히 한물 갈 정도로 굉장히 나중에 공개하지 않았던가. 물론, 엔진을 유료로 판매하기도 하는데 소스를 돈 주고 산 업체들이 손해를 보지 않게 하려고 좀 늦게 공개하는 것도 있긴 하지만 말이다.
오픈소스가 과연 개발자와 사용자가 모두 윈윈 할 수 있는 소프트웨어 생태계로 계속 명맥이 유지되는 게 가능할지 지켜볼 일이다.

아 그리고, 이 모든 사실에도 불구하고 <날개셋> 한글 입력기는 완성품을 복사해서 사용하는 것만 무료이지 여전히 소스 비공개 사유 소프트웨어이다. 물론 오픈소스 저작물을 사용한 것도 최소한 C++ 코드 내부엔 전혀 없다. 거기 들어있는 모든 모듈의 모든 기계어 코드는 한 치의 예외 없는 100% 자작이다.
전세계에 한국어와 한글이 쫙 퍼져 있고 세벌식 자판이 주류 글자판이 돼서 누구나 이런 응용 한글 입력 엔진의 필요를 느끼고 있고 사용자가 왕창 많고 거기에 다른 형태의 돈줄까지 있다면야 내가 거기에 공개적으로 기여를 해서 오픈소스계에 등단(?)할 수도 있겠지만.

시장과 수요 자체가 극도로 마이너한데... 공개해 봤자, 한글 IME를 연구하는 일부 극소수 오덕들에게나 좋은 일을 하게 되고, 내가 노력을 보상받는 길도 없고, 날개셋의 리눅스나 맥 버전을 뚝딱 책임감 있게 만들어 줄 사람이 있는 것도 아닌 와중에..
무작정 오픈소스화는 현실에 맞지 않는다고 여겨진다. 오픈소스 진영이 있다고 해서 모든 프로그래머가 흙 파서 먹고 살 수 있는 건 아니다.  8.0 정도가 나온 뒤부터는 내 프로그램의 장기적인 생존 방법에 대해서도 슬슬 생각을 해 봐야겠다.

3.
저건 나름 학점이 붙은 과목이기 때문에, 세미나만 있는 있는 게 아니라 과제도 있었다. 관심이 가는 오픈소스 프로젝트를 하나 선정해서 그에 대해 조사를 하고, 관심이 있으면 자그마한 오타 수정이라도 직접 하나 contribute를 해 보라는 것.

그래서 평소에 프로그래밍 언어에 대한 관심이 무진장 많으며, 나보고도 줄곧 이것저것 다른 언어를 익혀 보라고 권유를 하던 대한민국 오픈소스 진영의 거물이자 프로그래밍의 천재 T모 군의 도움을 받았다. (IOCCC 입상자 ㅋㅋㅋㅋ) 권유의 대상도 예전부터 파이썬, D, 자바스크립트로 계속 바뀌어 오다가 요즘은 Rust로 정착했다.

Rust는 모질라 재단에서 자체 개발한 새로운 절차형 시스템 프로그래밍 언어이다. Java/C# 같은 언어는 full-time 쓰레기 수집기가 갖춰진 별도의 가상 기계에서 동작하는 반면, 이 언어는 그런 형태의 쓰레기 수집기가 없이 C++과 동급의 네이티브 코드로 컴파일되는 언어이다. 메모리 관리 수준은 걍 Windows RT의 C++/CLI와 비슷한 급이 되겠다.

웹 브라우저 렌더링 엔진을 만드는 단체가 웬 PL을 새로 만들게 되었는지는 나름의 이유가 있다. 렌더링 엔진도 응당 GPU와 멀티코어의 도움을 받아야 할 터인데 여러 페이지들이 자연스럽게 멀티코어를 활용하는 게 아니라 단일 페이지가 멀티코어를 적절히 활용하게 만들자니 C/C++로 만들어진 기존 코드들은 답이 없는 지경이었나 보다.

또한 C/C++은 알다시피 빌드 시간이 매우 길고 컴파일러가 잡아 주지 못하는 메모리 관련 버그에 무방비로 노출되어 있는 등, 대형 프로젝트의 진행에 전통적인 한계와 약점도 적지 않다. 그래서 대형 프로젝트의 개발과 유지에 적당한 새로운 언어를 찾았는데 마땅한 대안이 없자 언어를 직접 고안하게 되었다.

이 언어는 모질라 재단에 소속되어 있던 개발자인 Graydon Hoare가 개인적으로 설계하던 언어를 재단이 인수하여 발전시킨 것이다. 지금은 모질라 재단뿐만 아니라 삼성전자도 Rust의 개발을 후원하고 있다고 한다.
아직도 활발하게 개발되고 있어서 0.12까지 나왔는데.. (12는 소수점이 아니라 그냥 정수. 0.2보다 최신 버전임) 긴 베타 기간을 거친 후, 가까운 미래에 Rust의 1.0 정식 버전이 나올 예정이라 한다.

즉 멀티코어 병렬 처리 편의와 자동 메모리 관리, 그리고 성능을 만족시킬 목적으로 만들어진 언어라는 뜻인데, 구글에서 비슷한 시기에 개발한 Go라는 언어하고도 경쟁 구도인 듯하다. 하지만 둘은 패러다임이 좀 다른 언어이다.

Rust에서 모든 값은 그 값이 대입된 변수나 구조체 필드, 넘겨받은 함수 인자 등의 이름에 귀속된다. 이름은 자기에게 귀속된 값에 대한 소유권을 가지며, 다른 이름으로 값을 대입하면 그 이름으로 소유권이 이전된다. 예를 들어, 다른 언어에서 a = b와 같은 대입 연산은 b의 값을 a로 복사하거나, b가 가리키던 객체를 a도 함께 가리키겠다는 의미를 갖는 데 반해, Rust에서는 b가 가지고 있던 값을 a로 이동시킨다는 의미가 된다. C++로 치면, C++11에서 첫 도입된 R-value reference type과 개념적으로 비슷하다.

만약 함수의 리턴값을 받지 않는다던가 하는 일로 인해 소유권을 넘겨주지 못한 채로 이름이 사라지게 되면, 거기에 귀속되었던 값도 함께 사라지면서 그 값을 담았던 메모리도 해제되게 된다. 프로그래밍 언어 이론의 관점에서 보자면, binding과 object의 생명 주기를 일치시킨 셈이다.

Rust 컴파일러는 컴파일 단계에서 소유권이 어떻게 이전되는지를 모두 추적할 수 있으며, 필요한 메모리 할당 및 해제 코드를 컴파일 중에 정확한 위치에 삽입한다. 이런 방법으로 Rust는 런타임 오버헤드가 없는 안전한 메모리 관리를 이루어 낸다.
일단 대충 이 정도 조사하면서 그쪽 진영에서 뜨고 있는 이슈와 작업 진행 방식들을 조사해 봤다.

Posted by 사무엘

오늘은 여러가지 교통 관련 썰을 좀 풀어 나가도록 하겠다.

1.
지난 추석 때, 고향을 왕래하는 고속버스 차창 밖으로.. "고속국도 제1호선 언양-영천간 확장 공사" 라고 표지판이 붙고 터가 닦여 있는 걸 봤다. 경부 고속도로가 개통 이래로 지난 40여 년간 최후까지 오리지널 4차선 그대로 남아 있었던 마지막 구간까지도 드디어 확장된다니 감회가 새롭다.
이 고속도로에 대해서는 3년 남짓 전에도 글을 한번 쓴 적이 있으니 참고하시길.

경부 고속도로의 옛날 사진을 보면 중앙 분리대가 화단 형태로 된 모습이 있어서 무척 신기하게 보인다.

또한 옛날에는 일부 직선 구간(성환, 신갈)은 아예 물통 같은 임시 중앙 분리대만 만들어 놓고 유사시에 활주로로 쓸 수 있게 해 놓기도 했다. 그리고 실제로 해당 구간을 잠시 폐쇄하고서 전투기 이착륙 훈련을 한 적도 있다.
아래 사진은 신갈 활주로에서 실제로 훈련을 하던 모습이다. 신갈 일대 고속도로 좌우 모습이 저랬을 정도이면, 아니 경부 고속도로의 수도권 구간을 폐쇄하는 게 가능했을 정도이면 지금으로부터 엄청, 굉장히 먼 옛날의 일일 것이다.

화단 형태든 임시 형태든.. 경부 고속도로의 중앙 분리대가 모습이 저랬다는 것은 오늘날로서는 참 상상하기 힘든 모습이다.

경부 고속도로는 처음에는 전구간 4차선으로 건설되었다.
지금이야 88 올림픽만이 전국 유일의 겨우 2차선짜리 고속도로라고 까이지만, 옛날에는 반대로 경인과 경부 정도만이 처음 만들어질 때부터 다차선이었다. 2차선 고속도로는 여럿 있었다. 당장 호남이나 영동 등.
그런데 옛날에야 그렇다 치더라도 1990년대까지만 해도 높으신 분들이 무슨 생각을 했는지 모르겠지만, 고속도로를 마치 88 올림픽처럼 겨우 2차선으로 만들려는 시도가 있었다.

대표적인 예가 중앙 고속도로인데.. 이건 마치 21세기에 개통 예정인 철도를 표준궤가 아닌 협궤 크기로 만드는 것만큼이나 막장 행위였다. 이것은 다행히 감사원으로부터 지적을 받은 끝에 뒤늦게 4차선으로 허겁지겁 개조되었다.

감사원? 철도에서 일산선 건설도 서울 지하철 3호선처럼 우측 직류 규격으로 임의로 바꿔서 과천-안산선처럼 꽈배기굴 시즌 2가 생길 뻔한 것을 막은 그 기관 말이다. 철도뿐만 아니라 고속도로를 만들 때도 그나마 세금값을 했다.

2.
철도 경부선은 영업거리표 상으로 서울에서 부산까지 공식 거리가 441.7km이다.
옛날처럼 지금의 서울 역(그 당시엔 남대문) 이북으로 레알 서울 역이 있고, 지금의 부산 역(그 당시엔 초량) 이남으로 진짜 부산 역이 또 있었다면 거리는 지금보다 2km 남짓 더 길어졌을 것이다.
한편, 경부선 철도에 상응하는 경부 고속도로의 전체 거리는 416.4km이다. 개통 당시엔 428km가량이다가 선형 개량을 통해 더 짧아진 것이다.

그런데 여기서 의문이 생긴다.
경부 고속도로는 경주와 울산을 거쳐서 크게 우회하는데 어떻게 유사 노선의 철도보다 거리가 이렇게 짧을 수 있느냐는 것이다. 물론 경부선도 서울 구간에서는 서쪽 영등포 방면으로 우회를 좀 해서 동선이 안 좋지만, 그래도 고속도로에 비할 바는 아니기 때문이다.

하지만 해답은 생각보다 간단한데, 바로 시내 구간의 포함 여부이다.
철도는 서울 역이라는 서울 도심으로 깊숙이 들어가며, 부산 역도 부산 시내를 다 관통한 후 완전 최남단에 있다.
그러나 고속도로는 양재 IC라는 서울 남쪽 외곽에서 끝나고, 부산도 시점인 구서 IC는 부산의 북쪽 끝자락이다.
양재IC - 서울 역 내지 구서-부산 역만 쳐도 각각 직선 거리만 거의 15km에 달한다.

이걸 퉁쳐 주면 고속도로나 철도나 거리는 서로 비슷해진다.
경부선 기존선이 아니라 서울-대구 구간을 고속선으로 달리는 KTX는 서울-부산 전체 주행 거리가 408km대로 크게 감소한다. 경부고속선이 기존 선로의 구불구불하던 주름을 얼마나 폈는지를 알 수 있다.
하지만 대구 이남 구간은 고속선이 경주와 울산을 경유하기 때문에 KTX의 거리는 423.8km로 15km 남짓 증가한다.

3.
교통· 운수 업계에서는 경사로의 기울기나 차량의 등판능력을 말할 때 각도가 아니라 언제나 기울기(탄젠트)를 쓴다. 고정된 X축 거리를 이동하는 동안 높이 Y가 바뀌는 비율인 것이다.
요즘은 자동차 제원표에서 찾아보기 힘들지만 보통 등판능력이 0.3xx가 나오는데, 그것도 탄젠트이기 때문에 실제 각도는 10몇 도 정도이다. 도로 표지판에서 볼 수 있는 5% 경사, 10% 경사 이런 것도 당연히 탄젠트 값임.

우리나라 K2 전차의 홍보 영상을 보니 무슨 60도 경사를 오른다고 자랑을 하던데.. 이건 오류이다.
45도보다도 높은 60도 경사를 오른다는 건 말도 안 되는 소리이고, 사실은 탄젠트 0.6에 해당하는 거의 30도대의 오르막을 오를 수 있다는 뜻이다. 그 무거운 쇳덩어리가 그 정도 경사를 오르려면.. 엔진 힘뿐만이 아니라 무한궤도를 이용한 접지력이 정말 살인적인 수준이어야 할 것이다.

철도 차량은 일반 육상 차량보다 등판능력이 훨씬 뒤떨어지기 때문에 백분율도 아니고 천분율을 써서 '퍼밀' 단위로 표기한다. 각도로는 2도가 채 안 되는 30 퍼밀 정도의 경사도 철도 차량에게는 우리나라의 태백선 같은 산악 철도에서나 볼 수 있는 굉장한 급경사이다. 견인 중량이 가히 상상을 초월하는 데다 쇠 바퀴와 쇠 선로는 마찰도 작으니 등판능력이 쥐약일 수밖에 없다.

육상 교통수단뿐만 아니라 비행기의 상승/하강률도 기울기로 표기된다. 1000m를 이동하는 동안 고도가 몇 m 바뀌는지가 기준이다. 우주왕복선은 엔진이 없이 글라이더 활강을 하기 때문에 일반 여객기보다 하강률이 훨씬 더 높다. 정확한 숫자를 본 적이 있었는데 또 찾기는 귀찮..;;

이렇게 업계에서 각도 대신 탄젠트가 즐겨 쓰이는 이유는, 일상생활에서는 고저차를 무시한 이동 거리가 더 중요하게 다뤄지며, 또 경사각이 올라갈수록 차량에게 필요해지는 동력 같은 각종 물리량도 각도가 아니라 탄젠트에 비례해서 급격히 올라가기 때문이다. 여러 모로 탄젠트가 현실적인 의미가 더 크고 유용하다는 뜻이다.

Posted by 사무엘

1. disabled 스타일 개론

소프트웨어 GUI에서 대화상자나 메뉴 같은 구성요소를 보면, 상태를 나타내는 속성 중에 논리값으로 enabled 여부라는 게 존재한다.
이게 false여서 disable된 물건은 비록 화면에 보이긴 하지만 흐리게 표시되며 완전히 없는 물건으로 취급된다. 사용자의 키보드나 마우스 조작에 반응을 하지 않으며 선택할 수도 없다.

Windows 운영체제에서는 윈도우에서 WS_DISABLED라는 스타일 비트가 이런 역할을 한다. 기본 스타일에 이 비트가 지정되어 있는 윈도우는 키보드 포커스를 받을 수 없으며, 거기에다 대고 마우스 포인터를 움직여도 통상적인 WM_MOUSEMOVE, WM_?BUTTONDOWN 같은 메시지가 오지 않는다.

즉, availability는 어느 정도 운영체제가 직접 관리를 해 주는 예약된 속성이다.
어떤 윈도우가 enabled인지 여부를 알려면 IsWindowEnabled 함수를 호출하면 된다.
IsWindowEnabled(hWnd)는 !(GetWindowLongPtr(hWnd, GWL_STYLE)&WS_DISABLED)와 동치라고 생각하면 된다.

enabled 여부를 설정하는 함수는 EnableWindow이다. 이때 대상 윈도우는 WM_ENABLE라는 메시지를 받음으로써 자신의 availability 속성이 바뀌었다는 통지를 받는다.
Get과 마찬가지로 SetWindowLongPtr를 통해 스타일을 수동으로 바꿔 줘도 거의 같은 효과를 낼 수 있다.
단, 이 방법은 간단히 전용 함수를 호출하는 것보다 번거로우며, 이렇게 속성이 바뀌면 대상 윈도우는 WM_STYLECHANGED만을 받지 WS_DISABLED 비트에 차이가 있더라도 WM_ENABLE 메시지가 오지는 않는다.

2. 화면에 그리기

대화상자 컨트롤이라면 WM_ENABLE 메시지가 왔을 때 자신을 화면에 다시 그리는 처리를 한다.
가령, 평소에는 COLOR_WINDOWTEXT라는 시스템 색상으로 글자를 찍은 반면, disable된 뒤부터는 COLOR_GRAYTEXT 색상으로 글자를 다시 찍는다.

지금이야 Windows 8 때부터 고전 테마라는 게 사라져서 점차 과거의 유물이 돼 가지만..
옛날에 Windows UI를 보면, 메뉴나 도구모음줄에서 사용할 수 없는 항목은 글자가 단순히 회색이 아니라 흰색 위에 회색이 깔려서 뭔가 음각 엠보싱처럼 그려지곤 했다.

그거 처리를 해서 disable 상태를 화면에 표현하는 건 DrawState라는 함수 호출 한 방이면 바로 된다. 이건 딱 회색 3D 대화상자 스타일이 도입된 Windows 95와 NT4에서 첫 추가된 함수이다. 게다가 텍스트와 비트맵(아이콘) 모두 그렇게 그리는 걸 지원한다.

비트맵의 경우, 마스크 비트맵을 바탕으로 엠보싱을 만들며, 이 테크닉은 지금도 그대로 쓰인다. 그렇기 때문에 요즘은 32비트 비트맵 내부의 알파 채널이 투명색을 대신하는 지경이 되었음에도 불구하고 DrawState 함수로 disable 상태의 엠보싱 아이콘을 그리려면 비트맵에 모노크롬 흑백 배경 마스크 비트맵도 넣어 줘야 한다.
뭐, 궁극적으로는 트루컬러 아이콘이라면 구시대스러운 비트 연산이 아니라, 투명도를 높이고 채도를 낮춰서 그림을 더 엷고 탁하게 만드는 '현대적인' 방식으로 disable 상태를 그려야 하겠지만 말이다.

3. disabled 윈도우의 또 다른 용도

그러면 이런 disabled 속성은 오로지 대화상자 내부의 컨트롤 같은 WS_CHILD급 윈도우에서만 쓰이는가 하면 그렇지 않다. 타 윈도우의 자식이 아니라 top-level이 될 수 있는 WS_POPUP급 윈도우도 WS_DISABLED 속성을 줘서 생성할 수 있다. 이 윈도우는 화면이 달랑 떠 있기만 하지 사용자가 포커스를 줘서 키보드 입력을 할 수가 없게 된다.

사실, 한 프로세스 안에서 child 윈도우는 클릭했다고 해서 딱히 포커스가 자동으로 거기로 옮겨지지는 않는다. 포커스가 가는 건 해당 윈도우가 WM_LBUTTONDOWN이 왔을 때 SetFocus를 자체적으로 호출했기 때문이다.
그러나 소속된 프로세스가 다른 top-level 윈도우의 경우, 클릭하면 일단 그 창으로 WM_ACTIVATE 메시지가 가고 컨텍스트 전환이 발생한다. 이것은 프로그램의 의사와 무관하게 운영체제가 일방적으로 하는 일이었는데, disabled 윈도우는 그걸 막을 수 있다.

물론 disabled 윈도우는 앞서 말했듯이 정상적인 마우스 메시지가 오지 않는데, 그래도 이것도 받는 방법이 있다.
disabled라고 해도 top-level 윈도우에는 기본적으로 마우스 포인터 설정을 위해서 WM_SETCURSOR 메시지 정도는 온다. 이 메시지의 lParam에는 이 윈도우에 원래 오려고 한 메시지가 담겨 있기 때문에 이를 토대로 비록 disable 상태이지만 마우스 동작에 반응을 하도록 프로그래밍이 얼마든지 가능하다. child 윈도우가 아닌 top-level 윈도우이기 때문에 이런 메시지가 온다.

disabled 편법을 쓰지 않고 '클릭해도 반응만 하지 포커스가 바뀌지는 않는 간단한 윈도우'라는 개념은 비교적 늦게 등장했다. Windows 2000부터 WS_EX_NOACTIVATE라는 확장 스타일이 정식으로 도입된 것이다. 이런 윈도우는 ShowWindow에다가도 단순히 SW_SHOW가 아니라 SW_SHOWNOACTIVATE를 줘야 한다.

4. 상태 변경과 관련된 연계 작업들

대화상자에서 컨트롤을 enable/disable시키는 상황은 크게 선천적인 것과 후천적인 것으로 나뉜다. 전자는 WM_INITDIALOG에서 단 한 번 enable 여부가 결정되고 그 뒤에 대화상자가 닫힐 때까지 그 상태가 바뀔 일이 없는 경우를 말한다.
후자는 한 컨트롤의 조작 여부나 값에 따라 다른 컨트롤의 enable 상태가 인터랙티브하게 수시로 바뀌는 경우를 가리킨다. 예를 들어 라디오 버튼이 특정 항목으로 맞춰져 있을 때만 조건부로 사용 가능해지는 하부 조건 체크박스 같은 것. UI 프로그래밍을 해 본 분이라면 이 분류가 수긍이 갈 것이다.

그런데 이렇게 컨트롤들의 상태를 바꾸는 건, 단순히 한 윈도우에 대해 EnableWindow를 호출하는 것 이상으로 이와 결합된 반복 패턴이 여럿 존재한다.

(1) 첫째, 대상 컨트롤의 이전에 있는 label 컨트롤을 같이 enable/disable시키는 경우이다. 대상 컨트롤이 버튼이라면--push, check, radio 모두 포함-- 그 자체가 &로 시작하는 Alt 액셀러레이터 글쇠를 갖는다. 그러나 나머지 edit, list, combo 박스 같은 것들은 자신의 액셀러레이터가 없으며 그 이전의 static 라벨로부터 액셀러레이터를 넘겨받는 형태이다.

따라서 그런 컨트롤이 disable됐다면 자기의 앞의 컨트롤도 같이 disable되는 게 이치에 맞다. 앞의 단순 label은 보통 독자적인 컨트롤 ID가 없이 그냥 IDC_STATIC인 경우도 많으므로 핸들값을 GetWindow(hCtrl, GW_HWNDPREV)로 얻어 오는 수밖에 없다.

(2) 둘째, 대상 컨트롤을 화면에서 감출 때에도 ShowWindow(hCtrl, SW_HIDE)만 할 게 아니라 disable을 시켜 줘야 한다. 왜냐 하면 enable 상태인 컨트롤은 비록 화면에 없더라도 Alt 액셀러레이터에는 반응을 해서 사용자가 여전히 기능 접근이 가능하기 때문이다.
본인은 개인적으로는 이게 바람직한 설계가 아니라고 생각하며, Windows가 왜 그렇게 동작하는지 알지 못한다. 하지만 어쨌든 Windows 95부터 8.1에 이르기까지, 조건부로 컨트롤들을 보였다가 숨겼다가 하는 UI의 경우, 감춰지는 컨트롤은 disable도 시켜 줘야 한다.

(3) 셋째, 지금 키보드 포커스를 받고 있는 컨트롤이 disable되는 경우, 포커스를 자신의 다음 컨트롤로 옮기는 일을 해당 프로그램이 수동으로 해 줘야 한다. 이걸 안 해 주면 그 컨트롤이 disable된 뒤부터 키보드 상태가 꼬여 버린다.
이 단서의 주된 적용 대상은 push-버튼이다. 대표적인 예로는 프로퍼티 페이지에 있는 '적용' 버튼. 이 버튼을 누른 순간 이 버튼은 사용 불가 상태가 되며, 사용자가 다른 설정을 또 건드려 줘야 다시 사용 가능해지니 말이다.

본인의 개인적인 생각은 이것도 역시 운영체제가 자동으로 처리해 줘야 하는 게 아닌가 싶지만, 현실은 시궁창이다. 생각보다 자비심이 없다..;;
대화상자에서 특정 컨트롤에다 포커스를 주는 건 SetFocus를 해서는 안 되며, 대화상자 부모 윈도우에다가 WM_NEXTDLGCTL 메시지를 보내는 방식으로 해야 한다. 그렇게 해야 대화상자의 default 버튼에 굵은 테두리가 그려지는 처리가 올바르게 된다.

그래서 본인은 위의 세 시나리오를 모두 감안하여 대화상자 컨트롤을 enable/disable시키는 함수를 별도로 만들어서 사용하고 있다.
그림을 좀 더 곁들이면 전반적으로 설명하기가 더 편하겠다는 생각이 드는데.. 귀찮아서 생략한다. ㄱ-

Posted by 사무엘

2014년의 끝을 앞두고 <날개셋> 한글 입력기가 새 버전이 나왔다.
그 어느 때보다도 다방면에서 리팩터링, 기능 추가, 버그 수정이 진행되어 프로그램의 완성도가 더욱 향상되었다. 이 글은 지난달에 썼던 GUI 개선 사항에다 또 덧붙여진 주요 변화 사항에 대한 설명이다.

※ 한글 입력 관련

1. 일부 특수글쇠의 '두벌식 종성' 지원 강화

'도깨비불', 그리고 '초· 종성 교환' 특수글쇠가 두벌식 종성까지 감안해서 동작하게 했다.
전자의 경우, 두벌식 종성 글쇠로 '않' 같은 글자를 입력하고 있었다면 '안ㅎ'에서 ㅎ이 초성이 아닌 종성 형태로 분리되어 나온다. 또한 지금까지 이 글쇠는 종성이 단독으로만 있을 때는 동작하지 않았지만, 이제는 종성 단독이더라도 ㄶ 자음끼리 분리가 가능할 때는 동작하게 알고리즘을 개선했다.

후자의 경우를 설명하자면 이렇다. '강'이라는 글자를 '악'이라고 바꿔 주는데, 애초에 글자를 두벌식 종성으로 입력하고 있었다면 이때에도 '악'을 지울 때 ㅇ은 비록 지금은 초성 모양이지만 처음에 종성으로 입력한 것처럼 재현을 해 준다. 이런 변칙적인 상황에 대한 배려를 추가했다. 두벌식은 역시 세벌식보다 근본적으로 처리가 복잡한 방식임을 알 수 있다.

2. 외부 모듈에서 글쇠를 인식하는 알고리즘 개선

사용자에게는 예전 것이나 지금 것이나 큰 차이가 안 느껴지겠지만, 이번 버전에서는 외부 모듈도 글쇠를 인식하는 뼈대 부분을 다시 구현했다.
이 과정에서 외부 모듈에서는 구조적으로 Alt 조합의 인식이 지원되지 않는다는 것을 UI 차원에서 확실하게 표시하게 했다. 외부 모듈에서 단축글쇠 추가/편집 대화상자를 꺼내면 Alt에 해당하는 슬라이더가 사용 불가능 상태가 된다.

또한 우리 프로그램이 가로채지 않는 글쇠는 조합이 있는 중에도 확실하게 가로채지 않게 동작을 개선했다. 예를 들어 space 같은 글쇠는 예전까지는 한글을 조합 중일 때 누르면 우리 프로그램이 언제나 가로채지만 다음 버전부터는 그걸 가로채지 않고도 모든 구현체에서 조합 종료 처리도 매끄럽게 된다.

3. 초-종성 공유 방식의 종성 결합에 대해 가상 낱자와 낱자 치환 규칙 자동 적용

글쇠 수가 매우 적은 휴대전화 입력 방식에서는 어지간한 거센소리나 된소리 계열 자모도 2타 이상의 합성으로 만들곤 한다. 그렇기 때문에 조합 과정에서 ㄴ+ㅇ, ㄱ+ㅆ처럼 현실에서 존재하지 않는 낱자를 특히 종성에다 임시로 풀어서 표현해야 하는 일이 생긴다.

앞부분을 표현하기 위해서는 기존 가상 낱자를 쓰면 되고, 현재 글자의 경계를 넘어가는 뒷부분을 표현하기 위해서는 지난 7.4 버전에서부터 고급 입력기에다 '낱자 치환' 규칙이 추가되어 현재는 이 문제가 깔끔하게 해결되었다.
그러나 ㄴ+ㅇ을 300 같은 가상의 낱자 결합으로 등록하고, 그 300에 대해서 ㄴ과 ㅇ에 대한 표현 규칙을 일일이 등록해 줘야 하는 번거로운 문제가 여전히 남아 있었다.

이번 버전에서는 그 문제까지 싹 해결했다.
'고급 입력기'를 문자 생성기로 사용하고 '초· 종성 공유 낱자 결합' 옵션이 지정된 상태에서
종성 A+B=C에 해당하는 C라는 종성을 조합하는 상태가 됐고, C는 물리적으로 표현 가능한 낱자의 범위를 초과하는 값이고
C에 대해 다른 가상 낱자나 낱자 치환 규칙이 존재하지 않는다면...

이 복잡한 조건을 모두 만족할 경우 <날개셋> 한글 입력기는 자체적으로 C를 종성 A와 다음 글자 초성 B로 풀어서 표현해 준다.
그래서 당장 천지인, 나랏글 같은 예제 입력 방식에서도 300 이후의 수십 개의 종성 결합이 존재하지만 그에 대한 가상 낱자와 낱자 치환 규칙은 이제부터 삭제되었다. 이제 그런 추상적인 낱자는 낱자 결합 규칙에다가 한 번만 지정해 주면 되니, 휴대전화 입력 방식을 구현하기가 더욱 수월해졌다.

4. 수식 변수에 대소문자 구분 추가

예전에도 한번.. <날개셋> 한글 입력기의 글쇠 수식에서 변수의 용도 구분과 공간 부족이 앞으로 문제가 될 수 있다고 언급한 적이 있었다. 이 문제를 간단한 방법으로 깔끔하게, 완전히 해결했다. 변수는 여전히 알파벳 한 글자이긴 한데, 여기에다가 대소문자 구분을 추가함으로써 지원되는 변수의 개수를 종전의 두 배로 늘린 것이다.

그리고 이 프로그램이 버전업되어 입력 스키마 차원에서 여러 변수들이 추가로 제공되더라도, 프로그램은 언제나 오로지 대문자 변수만을 사용한다. 소문자 변수 26개는 사용자가 자신만의 내부 상태를 구현하는 용도로 얼마든지 사용하면 된다. 대소문자이니 형태를 구분하기도 아주 쉽다. 수식을 입력할 일이 있을 때 대소문자 상태만 좀 조심하면 된다.

고유한 내부 상태를 사용하는 복벌식 입력기 플러그 인은 글쇠배열에서 Q 대신 q 변수를 사용해서 수식을 생성하도록 수정되었다.

※ 동기화 관련

5. 타입간에 입력 설정 자료 보존

<날개셋> 한글 입력기의 오랜 숙원이 이뤄졌다.
빠른설정이나 예제 파일을 통해서 '기본 입력 스키마'와 '기본 입력기' 방식으로 어떤 입력 설정이 구축되었는데, 이것을 그대로 '고급 입력 스키마'와 '고급 입력기'에다 가져올 수는 없을까?

입력 항목의 기반 루틴을 넘나들면서 입력 설정을 가져오는 것은 지금 체계에서는 일반적으로 가능하지 않았다. 그래서 편법으로 입력 항목을 XML 방식으로 저장한 뒤, 텍스트 에디터로 object를 수동으로 고쳐서 다시 불러오는 것밖에 방법이 없었다. (어차피 기본이든 고급이든.. 공통 설정은 공통된 XML 형태로 저장을 하기 때문에 가능한 일)

이제는 사용자가 원한다면 이 일을 프로그램이 직접 해 준다.
입력 스키마나 문자 생성기를 변경하고 나면 '초기화' 버튼의 메뉴에 '예전 설정 가져오기'라는 명령이 사용 가능해진다. 그리고 이것을 선택하면 변경 전에 사용하던 입력 스키마/문자 생성기가 갖고 있던 설정을 지금의 입력 스키마/문자 생성기에다가 적용을 하게 된다.

앞으로 고급 입력 스키마와 고급 입력기가 많이 쓰이게 될 텐데 이것은 꼭 필요한 기능으로 자리잡을 듯하다.
당연히, 고급에서 쓰이던 설정을 기본으로 가져오는 것도 가능하다. 기본이 지원하지 않는 기능에 대한 설정치들은 물론 소실된다.

6. 처음에 무조건 지금 default로 지정되어 있는 입력 항목으로 구동

지금까지 외부 모듈의 '고급 시스템 옵션'에는 TSF 지원 확장 하나밖에 옵션이 없었는데, 다음 버전에서는 옵션이 두 개가 더 추가되었다. 하나는 위의 기능인데, 이것은 유용하다면 굉장히 유용한 옵션이다.

Windows 운영체제는 프로그램들의 GUI에 내부적으로 한영 상태를 관리하고 있다. 외부 모듈들은 그 상태를 따라 동작하며, 자신의 상태와 운영체제의 상태 중 어느 하나가 바뀌면 다른 한쪽도 알아서 동기화를 해야 한다. <날개셋> 한글 입력기 역시 외부 모듈 구현체는 그런 규격을 따르며 동작한다.
이런 공통 프로토콜이 스펙에 규정되어 있기 때문에 응용 프로그램은 자신이 지금 무슨 IME를 사용하고 있든지간에 소프트웨어적으로 한/영 상태 정도는 강제로 바꾸는 게 가능하다.

그런데 <날개셋> 한글 입력기 외부 모듈은 사용자가 직접 글자판을 강제로 전환하지 않았다면 자기가 먼저 운영체제의 상태는 절대로 바꾸지 않는.. 일종의 read-only 전략으로 개발되었다. 이것은 MS 한글 IME도 동일하게 따르는 정책이다.

그래서 입력 설정상으로 한글 글자판이 지정돼 있더라도 그 내부 상태가 영문이라면 <날개셋>도 자기 설정을 무시하고 빈 입력 스키마 계열을 기본으로 선택하며, 그런 게 없으면 자동으로 추가도 했다. 이런 동작 방식을 이상하다고 지금까지 사용자들로부터 문의도 엄청 많이 받았다.

하지만 "안 되면 되게 하라" 정신으로.. 이 옵션을 켜 주면 외부 모듈도 편집기처럼 무조건 설정대로 동작하며, 운영체제의 상태를 자신의 상태에다 강제로 맞춰 버린다. 프로그램이 실행되자마자 영문이 아닌 한글 모드에서 시작하는 것도 이제 가능하다. 운영체제의 여타 외국어 IME/글쇠배열을 <날개셋> 한글 입력기와 병행해서 쓰는 것도 좀 더 수월해질 것이다.

7. 응용 프로그램간에 <날개셋> 한글 입력기의 활성 입력 항목 동기화

Windows 8부터는 응용 프로그램간에 사용하는 키보드 로케일/IME와 내부 한영 상태가 모조리 자동 동기화되는 옵션이 추가되었으며 이 방식이 기본으로 지정되어 있다. 하지만 운영체제가 동기화해 주는 것은 한글 아니면 영문이라는 이분법적인 논리값인 반면, <날개셋> 한글 입력기는 3개 이상의 임의의 개수의 입력 항목을 가질 수 있다. '한글'이라고 분류되는 입력 방식 중에 세벌식, 두벌식, 드보락 같은 것은 여전히 응용 프로그램별로 따로 놀며, 동기화되지 않는다.

이 옵션을 켜면 <날개셋> 한글 입력기는 프로그램간에 자기가 사용하는 구체적인 입력 항목의 번호까지 동기화해 준다. 즉, 한 프로그램에서 입력 항목을 다른 걸로 전환하고 다른 프로그램으로 이동하면, 그쪽에서도 그걸로 동기화가 된다.
이 기능은 완전 만능 동기화 기능은 아니고 운영체제의 내부 상태가 맞아야만 동작하는 등 이것저것 단서와 제약이 있긴 하지만(도움말에 명시되어 있음), <날개셋> 한글 입력기를 Windows 8 스타일에 맞춰서 좀 더 매끄럽게 사용하는 데 큰 도움을 줄 것이다.

※ 기타 다른 개선

8. 버그 수정

Windows 8.1에서 권한 부족한 Metro 앱을 사용할 때, 단어 단위 한자 변환이 되지 않던 문제를 해결했다. 지난 7.4 버전에서 추가되었던 사용자 한자어 사전 연계 기능에 문제가 있음을 뒤늦게 발견했다.
권한 부족한 Metro 앱에서 동작이 실패할 때에 대한 처리를 해야 했는데 그걸 하지 않아서 내부적으로 프로그램이 죽었다가 다시 구동되곤 했다. 이런 실행 모드에서는 화면에 로그조차도 제대로 찍히지 않아서 디버깅을 상당히 특수한 방식으로 힘들게 해야 했다.

조금 더 심각한 문제로는 텍스트 조작을 온전하게 할 수 없는 TSF B급 프로그램에서 지금 글자 앞으로 이동하는 부류의 특수글쇠를 사용했을 때 단순히 거절만 되는 게 아니라 프로그램 전체가 무한 루프에 빠지는 문제가 있어서 이를 해결했다. 이 부분의 로직이 크게 바뀐 바로 직전 7.5에만 있던 문제이다.

그리고 편집기에 있는 '키 입력으로 붙여넣기' 기능이 언젠가 space를 제대로 처리하지 못해서 조합 중이던 한글이 덧난 채 붙여지던 문제를 해결했다. 이 역시 아마 이 부분 로직이 크게 바뀌었던 7.4때부터 생긴 버그가 아닌가 싶다.
Windows 7은 콘솔에서 세벌식을 사용할 때 '다다.' 이런 식으로 글자가 덧나는 문제가 있었는데 그런 것과 기술적으로 비슷한 문제이다.

이에 덧붙여 편집기의 '현재 편집 중인 문서의 경로 복사' 기능이 언제부턴가 텍스트를 클립보드에다 제대로 저장하지 않고 있던 문제, 그리고 아무 문자를 입력하지 않을 때에도 겹침 모드에서는 뒷글자를 무조건 하나씩 지우던 사소한 문제도 해결했다. 이것도 아마 7.4~7.5 사이에 슬며시 들어간 버그가 아니었나 싶다.

9. 제어판에서 설정 파일을 초기에 저장하는 위치

날개셋 제어판에서 글쇠배열, 유형, 전체 설정 등.. 뭔가 파일로 설정 데이터를 열 때는 처음엔 예제 데이터가 있는 디렉터리가 시작 위치로 표시된다. 그러다가 파일을 한번 저장하고 나면 마지막으로 저장했던 파일이 있는 디렉터리가 열 때에도 그대로 표시된다.

그런데, 최초로 저장을 할 때는 지금까지 기본 입력 설정 파일이 저장되는 생뚱맞은 이상한 디렉터리가 표시되곤 했다. 이것을 개선하여 이제는 사용자에게 친근한 '내 문서' 디렉터리가 표시되게 바꿨다. 지금까지 이게 상당히 불편한 점이었을 것 같다.
단, 전체 설정(set)은 제공되는 예제 데이터가 없기 때문에 저장뿐만 아니라 '열기'를 처음 할 때도 '내 문서'에서 시작한다.

10. 사용자 정의 후보 관련

7.0에서 첫 도입되었던 사용자 정의 후보 관련 기능에도 엔진이나 GUI에 이것저것 개선이 있었다.
(1) 외부 후보 파일을 불러왔을 때 설명문이 space 이후가 몽땅 잘려서 출력되던 어이없는 버그가 이제야 발견되어 고쳤다. (신고해 주신 분께 감사~)

(2) 그리고 후보 데이터를 추가하는 버튼을 Ctrl을 누르고 클릭하면... 후보 데이터를 한 덩어리로 등록하는 게 아니라 각 글자 단위로 독립적으로 한꺼번에 등록하는 기능을 추가했다. 즉, "☆★○●◎"이라고 입력하고 Ctrl+클릭을 하면 ☆, ★, ○, ●, ◎ 라고 5개의 후보 문자들이 떼어져서 등록되는 것이다.

(3) 이 외에도, 호환용 한글 자모 하나를 사용자 정의 후보의 key값으로 등록해 놓으면, 유니코드 표준 자모로도 그 key에 접근할 수 있게 했다.
초성 자음 중에 ㅉ은 한자 키 특수문자 변환이 전혀 존재하지 않는 유일한 낱자이다. 그리고 모음이나 종성 겹받침도 자리가 비어 있다. 그렇기 때문에 이런 자리에다가 사용자가 자주 사용하는 상용구나 특수문자를 제2 후보에 내장형으로든 외장형으로든 등록해 놓고, "한자 1 + 오름차순 포워딩" 또는 "한자 2 + 내림차순 포워딩"을 쓰면 기존 한자 변환과 내 custom 변환을 손쉽게 같이 쓸 수 있다.
물론, 낱자뿐만 아니라 한자 독음이 없는 한글, 가령 '바'나 '카' 같은 것도 유용하게 활용할 수 있다.

11. 사용자의 건의를 반영한 GUI 개선 추가분

제어판 대화상자가 대화상자 자체의 크기뿐만 아니라 좌우(분야 vs 각 항목)의 내부 크기 조절도 드디어 가능해졌다.
단, 좌우의 폭은 양쪽 모두 지금보다 키우는 것만 가능하지, 줄이는 것은 가능하지 않다.
좌우의 크기 조절이 가능하려면 먼저 대화상자의 폭부터 더 키워야 한다.

많은 사용자들의 요청에 힘입어, 글쇠배열 수식 대화상자도 가로로 크기 조절이 가능해졌다. 생각보다 길고 복잡한 수식을 고안해서 사용하는 분들이 많은 줄을 이제야 알았다. ㅎㅎ
3.0 버전 이래로 거의 10년간 S, P, N, L 등 알아보기 어렵게 돼 있던 인접글쇠 버튼들 역시 저렇게 깔끔하게 바꿨다.

12. 설명문 추가

<날개셋> 한글 입력기에서 XML 저장이 가능한 단위인 글쇠배열, 입력 항목(유형 ist), 전체 입력 설정(set)에 대해서..
자신만의 고유한 설명문을 집어넣는 기능을 추가했다. 그리고 옵션을 줄 경우, 사용자가 제어판에서 해당 파일을 불러왔을 때 그 설명문을 반드시 먼저 사용자에게 표시하게 할 수 있다.

이 입력 방식은 언제 누가 만들었고 버전과 저작권이 어떻게 되며 제작자와 연락은 어떻게 하는지 등의 정보를 설명문에다 간단히 기재해 넣을 수 있다.
또한 복잡한 글쇠배열의 수식 로직 해설을 메모해 두는 용도로도 쓸 수 있으니 여러 모로 유용하다.

Posted by 사무엘