1. 문법 함정

C/C++에서 연산자로 쓰이는 토큰(문자)들 중에는 문맥에 따라서 의미가 중복될 수 있는 것이 있다.
예를 들어 * () [] 같은 토큰은 값을 계산하는 수식에서 쓰일 때와, 변수를 선언할 때 의미가 서로 다르다. 한쪽에서는 인근의 변수가 배열· 포인터· 함수 타입임을 나타내지만, 다른 쪽에서는 실제로 배열 첨자나 포인터를 역참조하고 함수를 호출하는 역할을 한다.

심지어 =조차도 int a=5; 와 그냥 a=5; 에서 =는 문법적인 의미가 서로 동일하지 않다. 똑같이 =를 썼더라도 중괄호를 동원하여 배열이나 구조체를 초기화하는 것은 일반 수식에서는 가능하지 않기 때문이다.

이런 것 말고도 콤마(,)의 경우.. 함수 인자 구분자와 쓰임이 완벽하게 겹친다. 그렇기 때문에 함수 인자에서 콤마 연산자를 쓰려면 수식을 괄호로 싸야 한다.

그리고 <>로 둘러싸인 템플릿 인자에서 부등호 내지 비트 이동 연산자를 쓸 때도 상황이 좀 난감해진다. 템플릿 인자에 typename만 올 때는 <>가 모호성을 전혀 일으키지 않지만, 문제는 템플릿 인자로 정수도 들어올 수 있다는 것이다. 그리고 값이 컴파일 타임 때 결정만 될 수 있다면 정수값을 만들어 내는 각종 연산자들도 당연히 쓰일 수 있다.

template class Foo<size_t N> { .... };

Foo<(a>b ? 5:3)> bar1;
Foo<(MAX>>3)> bar2;

그러니 위와 같은 상황에서는 수식 전체를 괄호로 싸야만 한다. 괄호가 단순히 같은 수식 안에서 연산 우선순위를 조절할 때만 쓰이는 게 아니라는 점이 흥미롭다. 수식 영역과 함수 및 템플릿 인자 영역을 구분할 때도 쓰인다.

std::vector<std::list<int>> vl;

요렇게 중첩되었던 템플릿 인자들이 한꺼번에 종결될 때 > 사이를 강제로 띄우지 않아도 되게 컴파일러의 동작 방식 지침이 달라진 때가 내 기억이 맞다면 C++03과 C++11사이였지 싶은데.. 정확하게는 모르겠다.

그 밖에 2[a]가 가능하다는 C/C++의 변태적인 특성상, 람다와 관련해서 또 변태 같은 중의성을 만들 수 있지는 않으려나 궁금한데, 너무 머리가 아파서 더 생각해 보지는 않으련다.
요즘 C++은 auto라든가 using, delete를 보면 =를 사용하는 새로운 문법이 여럿 생긴 것 같다.

2. 비표준이지만 표준처럼 쓰이는 함수

C언어 라이브러리에 있는 모든 함수들이 100% 표준이고 어느 플랫폼에서나 동일하게 사용 가능한 게 아니다.
본인은 평소에 Visual C++만 쓸 때는 이런 걸 전혀 의식하지 않고 지냈는데.. strlwr과 심지어 내 기억이 맞다면 strdup도 macOS에서는 지원되지 않는 걸 최근에 확인하고는 놀랐었다.
물론 저런 함수들이야 하는 일이 워낙 간단하니 3분 만에 직접 짤 수도 있다. 하지만 핵심은 저건 universal한 표준이 아니라는 것이다.

Visual C++도 세월이 흐를수록 '표준 준수'를 강조하는 쪽으로 라이브러리의 디자인이 바뀌다 보니, 관례적으로 제공되긴 했지만 엄밀히 말해 표준이 아닌 함수들에 대해서는 앞에 밑줄을 붙여서 구분하는 추세이다.
하긴 그러고 보니, Visual C++을 업그레이드 한 뒤에 기존 코드가 컴파일되지 않아서 수정하던 내역 중에도 멀쩡한 함수 앞에다가 _를 붙이는 게 많았다. 일례로, 이분 검색 함수는 bsearch가 당당히 표준으로 등재돼 있지만, 그에 상응하는 선형 검색 함수는 표준이 아니어서 그런지 _lfind이다.

3. 스택 메모리의 임의 할당

그러고 보니 비표준 함수 중에는.. malloc의 변종으로서 가변 길이(= 크기가 런타임 때 정해지는) 메모리를 heap이 아닌 무려 현재의 스택 메모리에서 얻어 오는 alloca이던가 malloca인가 하는 물건도 있었다. 옛날 16비트 Turbo C에만 있는 줄 알았는데 현재의 Visual C++에서도 지원은 하는가 보다. 물론 앞에 밑줄은 붙여서 말이다.

얘는 C에서 문법적으로 가능하지 않은 동적 배열을 heap이 아닌 스택 메모리에 구현해 준다. 메모리 할당 속도가 heap을 다루는 것보다 훨씬 더 빠르며, 함수 실행이나 scope이 끝날 때 해제도 자동으로 되어 memory leak 걱정을 할 필요 없으니 편리하다. 지금 실행 중인 함수의 stack frame을 조작하는 물건이니, 겉으로는 함수 호출 같지만 실제로는 컴파일러 인트린식 형태로 구현되지 싶다.

이렇게 생각하면 얘는 장점이 많아 보이지만.. 일단 할당 장소가 장소인 관계로 (1) 수 MB 이상급의 대용량 메모리를 할당할 수 없으며, (2) 할당 방식의 특성상 heap 메모리처럼 할당과 해제를 무순으로 임의로 자유자재로 할 수 없다. (3) C++ 언어의 보조를 받는 게 없기 때문에 해제와 C++ 객체 소멸을 한데 연계할 수도 없다.

이런 한계로 인해 스택에서의 동적 메모리 할당은 생각만치 그렇게 유용하지 않다. 본인도 지난 20여 년 동안 C/C++ 프로그래밍을 하면서 이걸 전혀 사용해 본 적이 전혀에 가깝게 없었다.
저 함수가 괜히 비표준이 아닌 셈이다. 마치 정수 기반 고정소수점과 비슷한 위상의 이단아인 것 같다. 다만, 그럼에도 불구하고 본인은 이런 상황은 어떨까 하는 생각을 해 보았다.

생성자에서 문자열을 인자로 받아들여 적절한 처리를 하는 기반 클래스가 있다.
이걸 상속받아 파생 클래스가 만들어졌는데, 얘는 자주 쓰이는 문자열 패턴을 손쉽게 생성하기 위해 여러 개의 문자열이나 숫자를 숫자를 인자로 받으며, 이로부터 단일 문자열을 생성하여 기반 클래스의 생성자에다가 전달한다. 즉, 이런 꼴이다.

Derived::Derived(string arg1, string arg2, int num):
 Base( prepareArgument(arg1, arg2, num) ) {}

예시를 보이기 위해 편의상 string이라는 자료형을 썼지만, 실제로 저기서 쓰이는 것은 const char * 같은 문자열 포인터이다.
즉, 나는 Derived의 생성자에서 char buf[128] 같은 스택 기반 지역변수 배열을 선언한 뒤, 거기에다 arg1, arg2, num의 정보를 담고 있는 문자열을 담고 그걸 Base의 생성자에다가 전달하고 싶으나.. 문법 구조상 그건 가능하지 않다. 기반 클래스는 파생 클래스의 생성자가 실행되기 전에 초기화가 완료돼야 하기 때문이다. 그러니 파생 클래스의 생성자 함수에서 확보해 놓은 스택 변수의 공간을 받을 방법도 존재하지 않는다.

이럴 때 prepareArgument(_alloca(len), arg1, arg2, num) 이런 식으로 static한 보조 함수를 만들면 굳이 힙 메모리 할당과 생성자· 소멸자가 뒤따르는 범용 string을 쓸 필요 없이 스택에다가 문자열을 담을 공간을 임시로 확보하여 소기의 목적을 달성할 수 있을 것으로 보인다.

4. 쓰레기값

'초기화되지 않은 변수, 쓰레기값'이라는 건 내가 아는 프로그래밍 언어들 중에는 C/C++에만 존재하는 개념이다. 물론 컴퓨터라는 기계에 본질적으로 존재하니까 C/C++에도 존재하는 것이지만 말이다.
이것 때문에 야기되는 버그의 황당함과 막장스러움은 뭐, 이루 말로 형용할 수 없다. 같은 소스 코드가 release 빌드와 debug 빌드의 실행 결과가 달라지는 건 애교 수준이다. 프로그램이 미묘하게 삑사리가 나고 있어서 몇 시간을 끙끙대며 디버깅을 했는데 원인이 고작 이것 때문인 일이 비일비재하다.

개인적으로는 부모 클래스의 멤버가 초기화되지 않았는데 그걸 자식 클래스에서도 초기화하지 않은 것, 처음에는 0 초기화가 보장되는 static 영역에 있던 오브젝트를 별 생각 없이 스택/힙으로 옮긴 것, 심지어 한 멤버를 초기화할 때 아직 초기화되지 않은 다른 멤버를 참조해서 망한 것이 기억에 남아 있다.

간단한 int 지역변수가 초기화되지 않은 건 컴파일러 차원에서 잡아 주지만 위와 같은 사항들, 복잡한 구조체의 멤버가 일부 초기화되지 않는 것, 스택이 아닌 힙에서 할당하는 동적 메모리가 돌아가는 사정은 컴파일러도 일일이 다 챙겨 주지 못하기 때문에 더 복잡한 정적 분석의 영역으로 가야 한다.

그런데 개인적으로 의문이 드는 건 초기화되지 않은 쓰레기값이란 건 어느 정도로 무질서하냐는 것이다. 무슨 수학적으로 균일한 난수 수준일 리는 없을 것이다.
그 쓰레기들의 값에 영향을 주는 것은 정확하게 무엇일까? (스택이냐 힙이냐에 따라 다르게 생각해야 할 듯) 컴파일 시점에서 결정되어서 한번 빌드된 프로그램은 동일한 동작 조건에서는 불변인 걸까? 혹은 운영체제에 따라 달라질 수 있을까?

마치 중간값 피벗 기반의 퀵 정렬이 최고 시간 복잡도가 나오게 공격하는 방법을 연구하는 것처럼 저것도 뭔가 컴퓨터공학적인 고찰이 필요한 의문인 것 같다.

5. 메모리 주소의 align 문제

"어..? 구조체의 크기가 왜 각 구조체 멤버들의 크기의 합보다 더 크지? 컴파일러의 버그인가?"
본인이 이렇게 크게 놀랐던 게 벌써 20여 년 전, 고딩 시절에 도스용 DJGPP를 갖고 놀던 때였다.
그때는 지금 같은 구글 검색도 없고 네이버 지식인도 없고.. 이런 시시콜콜한 이슈를 다루는 C언어 서적도 없었으니, 궁금하면 물어 볼 만한 곳이 PC 통신 프로그래밍 관련 동호회 게시판밖에 없었다.

메모리 취급에 매우 관대한 x86 물에서만 놀던 사람이라면 word align이라는 개념이 더욱 생소할 수밖에 없다. 더구나 그 경계에 맞지 않은 단위로 메모리 접근을 시도할 경우, CPU가 귀찮아서 예외까지 날린다면??
본인은 포팅이라는 걸 할 때 word align을 조심해야 한다는 것을 머리로는 들어서 알았지만 그 문제를 회사에서야 실제로 겪었다.

이제 네이티브 코드는 반드시 ARM64 기반으로 빌드해야 하니 해당 부분을 64비트로 다시 빌드했다. 그런데 동일한 엔진을 얹은 안드로이드 앱이 어떤 기기에서는 잘 돌아갔는데 다른 기기에서는 뻗었다.
죽은 지점이 어딘지는 stack dump를 통해 알아낼 수 있었지만 거기는 null pointer, buffer overflow 등 그 어떤 통상적인 메모리 문제가 발생할 여지도 없는 곳이었다.

알고 보니 거기는 파일 형태로 기록하는 조밀한 버퍼에다 wcsncpy( reinterpret_cast<wchar_t*>(buf+1), str, len) 이런 짓을 하고 있었으며, 타겟 포인터가 한눈에 보기에도 wchar_t의 크기 대비 word align이 되어 있지 않았다(buf 는 char* ㄲㄲㄲ).
그래서 wcsncpy를 memcpy로 교체함으로써 문제를 해결할 수 있었다. wchar_t는 long과 더불어 포팅을 어렵게 하는 주범이며, reinterpret_cast는 align과 관련된 잠재적 위험성을 발견하는 용도로도 쓰일 수 있다는 점을 알게 됐다.

복잡한 포인터 메모리 조작 코드에서 잠재적인 align 문제를 잡아내는 건 사람의 디버깅만으로는 한계가 있을 텐데, 정적 분석으로 가능한지 궁금하다. 그리고 반대로 레거시 코드를 돌리기 위해 컴파일러가 성능이 떨어지는 걸 감수하고라도 최소한 뻗지는 않게 align 보정 코드를 집어넣어 주는 옵션도 있을 텐데 그것도 궁금해진다.

6. 32비트 단위 문자열

C/C++에서 wchar_t 크기의 파편화로 인해 야기된 혼란과 원성이 워낙 장난이 아니었기 때문에 C++11에서는 아예 크기를 직접 명시하고 고정시킨 char16_t와 char32_t라는 자료형이 built-in으로 추가되었다. int는 32비트 시대에 크기가 변했고 long은 64비트 시대에 플랫폼별로 삐걱거리기 시작했다면, wchar_t는 유니코드와 함께 새로 등장하면서 저 지경이 된 셈이다.

개인적으로 인상적인 것은 char32_t는 U""라고 문자열 리터럴을 나타내는 접두사까지 언어 차원에서 새로 등장했다는 점이다. 드디어 확장 평면 문자도 취급하기 더 수월해지겠다.
그런데 그러면 Visual C++이라면 ""는 1바이트, L""는 2바이트, U""는 4바이트라고 자연스럽게 연결되는데, 처음부터 wchar_t가 4바이트였던 맥에서는 L과 U가 모두 4바이트이다. char16_t에 대응하는 2바이트 문자열은 리터럴로 표현하는 방법이 없나 궁금하다. 오히려 Objective C에서 사용하는 NSString의 @""가 2바이트 문자열 리터럴이다.

char32_t가 언어 차원에서 이렇게 지원되기 시작했는데 str*, wcs*처럼 32비트 문자열 버전에 대응하는 strlen, strcpy, sprintf 등도 있어야 하지 않나 싶다. C++이라면 char_traits 템플릿으로 땜빵할 수도 있겠지만 C에는 그런 게 없으니까..
그리고 템플릿이 없는 저쪽 동네 Java는 32비트 단위 문자열을 취급하는 string class 같은 것도 있어야 하지 않을까? 문자 하나도 확장 평면까지 감안해서 얄짤없이 int로 표기하는 건 직관적이지 못하고 불편하니 말이다.

7. 레퍼런스 사이트

C/C++은 마소의 C#, 애플의 Swift, 썬-오라클의 Java처럼 한 기업이 주도해서 개발하는 언어가 아니다. 그래서 C++ 라이브러리 레퍼런스 같은 걸 검색해도 딱 떨어지는 개발사의 홈페이지가 곧장 나오지는 않는다.
하지만 수 년 전부터 구글 검색에서 상위권으로 노출되고 있는 유명한 사이트는 아래의 딱 두 곳인 것 같다.

http://www.cplusplus.com
https://en.cppreference.com/w

얘들은 개인? 단체? 어디서 운영하는지 모르겠다. C++17, C++20 같은 최신 정보도 곧장 올라오는 걸 보니 유지보수도 활발히 되고 있고 만만하게 볼 퀄리티가 아니다.
마치 Doom 게임 관련 자료를 듬뿍 얻을 수 있는 위키 사이트가 doomwiki와 doom.fandom.com 요 두 계열로 나뉘듯이 말이다.

Posted by 사무엘

2019/11/13 08:33 2019/11/13 08:33
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1683

30여 년 전에 개최되었던 서울 올림픽은 운동 선수들만 잘 뛰어서 성공한 게 아니었다. 마스코트 호돌이와 주제가 "손에 손잡고" 같은 예술 감성 마케팅도 완벽했다.

개인적으로는 자국의 음악가 대신 일부러 외국인에게 주제가 작곡을 맡기고, 공연도 한국인이지만 외국에서 활동한 그룹에게 맡긴 것이 선견지명이었다고 생각한다. 그래서 음악의 퀄리티가 더욱 올라갈 수 있었다. 고유 모델 자동차를 개발할 때도 첫 단추를 끼울 때 돈 아깝다는 생각을 접고 쿨하게 외국 일류 디자이너에게 디자인을 맡겼으며, 이름도 군사정권이나 북한스러운 시덥잖은 국뽕물 형태로 짓지 않고, 수출을 의식해서 '포니'라고 지었던 것처럼 말이다.

그 뿐만이 아니다. 벤 존슨 선수의 약물 도핑을 잡아낸 기술력, 그리고 자체 개발한 통합 전산 시스템 같은 운영도 아주 성공적이었다. 정말 "우리도 할 수 있다"라는 저력을 세계를 상대로 보이기에 손색이 없었다. 물론 이런 노하우가 갑자기 하늘에서 뚝 떨어진 건 아니고, 자국의 전국체전, 그리고 86년 아시안게임이라는 베타테스트 기회가 먼저 있긴 했다.

오늘은 본인이 서울 올림픽 개막식 동영상을 보다가 문득 떠오른 생각을 좀 열거하고자 한다. 어쩌다 보니 기계 이야기와 사람 이야기가 하나씩 모였는데, 일단 기계 이야기부터 먼저 늘어놓겠다.

1. 전산 시스템의 디지털 서체

본인이 예전부터 강조한 바와 같이, 1953년의 휴전 협정 문서는 한글이 기계식 타자기로 찍혀서 국제적인 역사 기록이 만들어진 거의 최초의 사례이다.
알파벳을 쓰는 서양에서는 학술 논문은 말할 것도 없고 전쟁 중에 삐라 찌라시를 만들 때도 타자기를 써서 일을 아주 신속하게 진행했지만 동양은 아직.. 심지어 펜보다도 더 느리고 불편한 붓을 썼던 것이다.

그런데 그로부터 30여 년 뒤, 서울 올림픽 주경기장 전광판에 떴던 자막은 한글이 디지털 컴퓨터의 화면에 표시되어 국제적인 역사 기록으로 남은.. 완전 최초까지는 아니어도 충분히 초창기 축에 드는 사례이지 싶다. 특히, 내부적으로 단순무식 그림이 아니라 진짜 문자로 처리되어서 출력된 것 말이다.
(화면은 모두 대한뉴스 유튜브 영상들 캡처해서 적당히 짜깁기..)

사용자 삽입 이미지

알파벳· 숫자와 마찬가지로 모든 획을 수평 수직 45도 대각선만으로 구성한 단순한 디자인이요, 확대 계단 현상이 그대로 드러나 보이는 투박한 비트맵이다. 좀 허한 느낌이 드는 ㅅㄷㅈ 같은 초성의 배치를 보면.. 조합 벌수가 그리 많지도 않은 구조로 보인다.

전광판 말고도 그 시절의 대한뉴스 동영상을 열람해 보면 기자나 운영자들이 자료 입력용으로 사용한 전산 시스템의 접속 화면을 볼 수 있다. 일명 GIONS인데.. 난 1980년대의 컴퓨터 프로그래밍 환경은 어떠했을까 아는 게 없으니 신기하기 그지없다. 저 때는 PC 환경에서는 온갖 한글 코드들이 난립하고 조합형이니 완성형이니 하면서 싸우던 때였다. 한글 카드라는 하드웨어(!!)가 있었으며 소프트웨어적으로 한글 입출력을 구현하는 건 고난도 프로그래밍 테크닉이었다.

개인이 단말기 용도로 쓰던 컴은 그냥 IBM XT급인지, 아니면 다 IBM 워크스테이션급인 건지, 16비트인지 32비트인지, x86인지 아닌지(아마 아닌 듯)... 같은 것 말이다. 더구나 GIONS는 그 이름도 유명한 코볼 언어로 작성됐을 거라는 말이 있다.

사용자 삽입 이미지

이 화면에서 쓰인 한글 폰트는 비교적 친숙하다. 글자가 전반적으로 홀쭉하고 영문· 숫자도 전각으로 표현되었던 것 같다.

사용자 삽입 이미지
사용자 삽입 이미지

그런데 본인의 고개를 갸웃거리게 하는 것은 이 화면이다. 이건 분명 모니터 화면인데 영문· 숫자는 반각으로 표현되었을 뿐만 아니라 고해상도이다. 화면용 폰트가 아니라 24픽셀급의 도트 프린터 인쇄용 폰트가 쓰였다.
그 시절에 텍스트 모드 화면에서 인쇄용 폰트를 볼 일은 PC 레벨에서는 없었을 텐데.. 이건 도대체 무슨 기기인지 궁금하다.

서울 올림픽의 통합 전산 관리 시스템(모든 경기들의 진행 상황 파악, 선수들 기록 등록, 기사 전송 등...)인 이 GIONS는 순수하게 국산 기술로 개발되었고 대회 중에 한 번도 오류 없이 성공적으로 잘 돌아갔다. 서울 올림픽의 개최를 성공으로 이끈 숨은 일등공신 역할을 했음은 물론이다.

하지만 올림픽이 끝난 뒤에는 이 솔루션은 전혀 유지보수 되지 못한 채, 완벽하게 잊혀지고 사라져 버렸다. 심지어 후대의 올림픽 개최국 중에서 GIONS를 구매해서 도입하고 싶어하는 곳이 있었는데도 도움을 주지 못했다. 그때 한데 모였던 개발 인력은 각자 자기 먹고 살 길을 찾아 이직하고 흩어졌다. 이거 무슨 거북선도 아니고 뭐냐..

물론 지금이야 최신 웹과 DB 기술을 이용해서 그 정도 SI를 구축하는 것은 30년 전 그 시절만치 대단하고 거창한 일은 아닐지 모른다. 하지만 신기술이 아직 가치가 있던 시절에 그게 더 널리 쓰이지 못한 것은 애석한 노릇이다.

2. 고등학생들의 개회식 매스게임

올림픽의 개회· 폐회식 때는 주최국에서 준비한 온갖 화려 현란한 공연들이 펼쳐져서 흥을 돋우고 관객들에게 잔치 분위기를 내는 것이 관례이다. 서울 올림픽도 예외가 아니었다.
이런 건 주최국에서 내로라 하는 예술가들이 국가로부터 의뢰를 받아서 컨텐츠를 만든 뒤, 전공자 전문 무용수들이 대가를 받고 공연한다. 그런데 서울 올림픽의 경우, 거기에 덤으로 '동대문 상업 고등학교', '서울 여자 상업 고등학교' 이렇게 남녀 실업계 고등학교 두 곳에서 총 1100명이나 되는 2학년 학생들이 소집되어 매스게임을 했다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

이 사람들은 처음에 전문 무용수들이 '태초의 빛'이라는 창세기 1장스러운 공연을 할 때는 들러리로 자리 채우는 역할만 했지만, 그 다음 '어서오세요' 편에서는 자기들이 직접 운동장을 뛰어다니고 구르면서 88, WELCOME, 어서오세요, 오륜기 등등 글자 픽셀을 만들고 심지어 색깔띠(?)를 펼쳐서 펄럭이기까지 했다.

아예 체조 선수나 발레리나 같은 레오타드도 아니고 반쯤 운동 선수 같은 희고 짧은 복장에, 색깔띠는 저렇게 머리에 두르고 있는 게 무척 인상적으로 느껴졌다.

사용자 삽입 이미지

매스게임은 그 특성상 민주· 인권이 발달한 나라에서는 잘 안 하고 사회· 공산주의 집단· 전체주의 똥군기스러운 곳에서 체제 선전과 단결력 과시(?)를 목적으로 많이 하는 편이다. 가령, 북한의 아리랑 공연은 그야말로 HD급 해상도를 자랑하는-_- 카드섹션을 선보이는 걸로 유명하다. 그 대가로 침해되는 북한 어린이와 청소년들의 개인 시간과 건강, 학습권 따위는 아웃 오브 안중..

우리나라는 북괴 정도까지는 아니지만 그래도 옛날엔 주변에서 선진 문물이랍시고 보고 배운 게 온통 일본물밖에 없고, 또 생존을 위해서라도 멸사봉공 군대 문화와 전체주의 분위기가 오랫동안 쩔었다. 그렇기 때문에 학교나 대기업 같은 데서 맛보기 수준의 매스게임은 종종 행해졌다. 당장 전국체전 때만 해도 운동부 애들의 운동 경기뿐만 아니라 여학생들 집단군무가 관행이었다는 것을 옛날 대한뉴스를 보면 알 수 있다.

군대는? 제식부터가 일종의 집단군무이다. 카드섹션 같은 건 없겠지만 그 대신 무릎을 안 굽히고 걷는 거위걸음 행군이 있다.
그리고 국군의 날 기념 퍼레이드 연습이 통과의례였다. 퍼레이드에 선발된 부대의 일반 보병들이야 각 잡고 광낸 군장 메고 행군만 하겠지만 사관 생도나 특전사들은 뭔가 더 특별한 걸 보여줘야 하니 연습하느라 고생이 이만저만이 아니었을 것이다. 요즘이야 대규모 특별 행사를 5년마다 한 번씩 대통령이 취임한 해에만 하지만, 옛날 군사 정권 시절에는 그 짓을 여의도 광장과 서울 종로에서 매년 해야 했다.

자, 그런 와중에.. 서울 올림픽 개회식의 매스게임에 참여했었다는 익명의 서울여상 졸업생의 회고 인터뷰가 어째 딴지일보에 올라와 있어서 본인은 재미있게 읽었다. 참고로 딴지일보 기사도 무려 2004년작이니, 올림픽 당시와 지금의 중간 사이인 엄청난 옛날이다.;; "그리스 아테네 올림픽 개회식은 보셨나요?"라는 인터뷰 질문에서 세월의 격차를 느낄 수 있다.

인터뷰 내용에 따르면..

  • 그 아이들은 1학년 2학기에 들어갔을 무렵부터 거의 1년을 연습했다고 한다. 매일 하루도 빠짐없이는 아니었겠지만 그래도.. 연습날은 오전 수업만 하고 오후 내내 해 떨어질 때까지.. 이 때문에 수업 시간이 펑크난 건 방학을 줄여서 메워야 했다.
  • 자기 학교가 뜬금없이 개회식 매스게임에 참여하기로 결정된 것은 자기 반이 배틀로얄 시범 학급으로 지정된 과정과 다를 바 없다. 학생들의 의사는 반영되지 않았다. 그 시절엔 세계가 지켜보고 있으니 그냥 나라와 학교에서 시키면 애국이라는 명목으로 해야 했다. 까라면 까야 했다.
  • 두 학교가 같이 모여서 연습할 때는 연습 장소로 효창 운동장이 주로 쓰였다.
  • 세 번 정도 올림픽 주경기장에서 개막식 폐막식 총연습 리허설이 있었는데, 마지막 '최종' 리허설 때는 학부모들도 공식적으로 초청받았다고 한다.
  • 조금 씁쓸한 얘기이지만, 실업계고가 선택된 이유는 일반 인문계고에서는 애들 공부하는 데 방해 된다고 학부모들 반대가 심했기 때문이랜다. (그 전의 86년 아시안게임 때의 선례)
  • 올림픽이 끝난 뒤에 모든 참가자들은 고생했다고, 수고 많았다면서 나중에 국가로부터 자그마한 기념 훈장쪼가리를 받았다.

그래도 강제 동원된 것치고는 저 클로즈업 영상에 나오는 학생들의 표정은 대체로 밝아 보인다.
개회식 이후에 폐회식 때는 또 다른 실업계 고등학교 학생들이 매스게임을 했다. 학교명은 공주농고, 해성여상이라고 뜨는데, 지금은 두 학교 모두 특성화 고등학교를 표방하며 이름이 바뀌어 있다. 지방에 있는 학교이면 이동하느라 연습하기가 더 어려웠을 것 같은데..

정말 88 올림픽을 소재로 영화 좀 나오는 게 없으려나 모르겠다. 운동 선수, 운영 인력 등 무엇 하나를 집어도 드라마틱한 소재는 만들어질 수 있을 것 같은데 말이다.
참, '태초의 빛'을 지도한 이화여대 무용학과 교수는 성명이 어째 '유 관순' 열사랑 발음이 같다..; 일부러 노린 작명인지 진지하게 궁금해진다.

서울 올림픽은 전세계 지구촌 축제를 표방하며 개최되었고, 실제로 그 목표를 어느 정도 이뤘다. 자유 진영과 공산권 국가들이 모두 참가해서 그 전의 모스크바· LA 올림픽의 한계를 훌륭하게 극복했기 때문이다.
하지만 그 와중에 북괴는 펜대 굴리며 곰곰이 계산을 해 보니.. 결국 자기 주민들에게 미칠 여파를 생각하면 안 되겠다 싶었는지 불참했다. 불참만 한 게 아니라 KAL858편 테러나 일으키면서 남한의 올림픽 개최를 방해하고 해코지나 했다는 것을 우리는 잊지 말아야겠다.

사용자 삽입 이미지

Posted by 사무엘

2019/11/10 08:35 2019/11/10 08:35
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1682

본인이 다니는 교회에서는 매년 8월에 자연의 정취가 살아 있는 곳으로 2박 3일간 하계 수련회를 간다.
거기서 대부분의 교인들은 특정 주제를 두고 진행하는 담임목사님의 성경 특강을 시리즈로 듣는다. 하지만 불신자 내지 초신자들을 위한 복음 전도 집회를 따로 진행하는 분도 있고, 어린애들 주일학교를 진행하는 분도 있다. 이분들은 목사님의 특강을 못 듣는다.

그리고 본인은 언제부턴가 주일학교 강사 중 하나 역할을 맡기 시작했다.
작년에는 주일학교 공부 주제가 "하늘나라 heaven", 즉 미래 시제였다. 그랬는데 올해는 이와 대조적으로 주제가 "교회사"로, 어째 과거 얘기가 됐다.
형제들 세 명이 번갈아가며 2, 30분 남짓 강의를 하기로 했다.

신약 교회사에서 대격변에 달하는 큰 사건은 콘스탄틴 (313), 종교 개혁 (1517) 정도이다.
그렇기 때문에 이걸 기준으로 시기를 나누면 별다른 고민할 필요 없이 세 명의 강의 구간이 딱 정확하게 갈라지게 된다.

1부는 침례인 요한, 예수님의 승천과 교회 태동, 사도행전, 네로 황제의 박해, 최근 영화 '바울'의 고증 분석, 로마 제국에 의한 맹렬한 박해, 예수님 제자들의 최후, 초기 교부들.. 이런 게 나올 것이다.
다루는 시기가 상대적으로 짧으나, 첫 타인 만큼 기본 개념을 얘기해 줘야 되는 게 많다. 유대인과 교회의 차이, 세례와 침례의 차이, 기독교 천주교 개신교의 관계 등.

2부는 중세 암흑기, 종교 재판, 위그노· 노바티안· 왈덴시스 등 "개신교가 아닌 계통의" 기독교 크리스천들의 계보, 위클리프 이래로 틴데일 등 킹 제임스까지 영어 성경 번역 역사, 성 바돌로메 대학살, 에라스무스의 공인 본문, 루터가 나올 것이고..

그리고 3부는 미국 건국, 18~19세기의 부흥, 그리고 "한국의 교회사", 성경 변개 내력, 20세기 이후의 거대한 배도의 물결이 다뤄질 것이다.

내가 강의를 전부 맡는다면 내용을 저렇게 편성할 것이다.
본인은 셋 중 하나만 하라면 제일 최근인 3부를 맡아서 어린 꿈나무들에게 특별히 반공 교육을 해 주고 싶었다.

우리나라의 1948년 5월 10일 총선거일은 주일을 피해서 일부러 월요일로 정해졌는데 북괴는 1946년 11월 3일 총선거를 일부러 일요일로 정했다는 것을 얘기하고,
제헌 국회 기도문을 북괴의 제2차 로동당 대회와 대조해서 소개하고 싶었다.

일제 말기뿐만 아니라 1950년 가을과 겨울에도 반도에 순교의 피가 얼마나 많이 흘려졌는지, 북괴가 왜 저렇게 기독교를 못 잡아먹어서 안달일 수밖에 없는지 본질적인 이유를 얘기할 생각이었는데..

형제 중 한 분이 사정상 마지막 날 3부 시간대에만 강의가 가능하다고 해서 3부는 그 형제에게 양보하게 됐다. 나는 그 대신 2부를 맡았다.
하지만 그 형제도 나 만만찮은 반공 보수 우파이니 안심이 된다. 사실 크리스천이라면 누구나 이렇게 되는 게 정상이지.. 특히나 요즘 같은 나라 꼬라지라면 더욱 말이다.

좀 수위가 쎈 슬라이드 몇 장만 빼고 대부분을 내 블로그에다가도 공개하도록 하겠다. 도움 되셨으면 좋겠다.
다만, 듣는 애들이 대부분 초등학생이다 보니, 강의를 하던 당시에는 문장들이 전반적으로 여전히 너무 길고 어렵다는 평을 받았다.

사용자 삽입 이미지

제목부터가 '피 흘린 발자취'인데 슬라이드 배경은 응당 어두운 색으로 뽑아야겠다는 생각을 진작부터 했다.

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

3부작의 강사가 모두 다르지만, 강의하는 주제와 내용과 범위를 얼추 합의했기 때문에 '지난 줄거리'를 짤 수 있었다.
교회, 박해, 침례.. 모두 아주 중요한 개념이다.

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

천주교와 기독교는 그저 구원 교리나 마리아나 연옥 같은 교리만 다른 게 아니라 역사관부터가 극과 극으로 다르다.
콘스탄틴의 기독교 공인은 일제 시대 무단 통치가 문화 통치로 바뀐 정도라고 생각하면 된다. 참조할 만한 다른 사건은..

  • 예수님이 받으신 사탄 마귀의 마지막 시험 "내게 절하라. 그럼 내가 이 모든 걸 너에게 주겠다."
  • 파라오가 출애굽과 관련해서 모세에게 제안했던 온갖 타협 절충안들. "애들은 놔두고 성인들만 가라", "가축들은 놔두고 가라" 등등등..
  • 사사기 후반부에서 벌어지던 온갖 성직자들의 타락, 예배의 왜곡
  • 겨자씨가 거대한 나무가 되어 공중의 새들이 가지에 앉는 사건 비유

정도이다.

사용자 삽입 이미지

특히 침례교인들은 유아 세례 반대 같은 이유로 인해, 카톨릭뿐만 아니라 장로교 같은 종교 개혁 개신교 교파들로부터도 박해를 받았다. 쟤들을 가만 놔두면 자기 교리가 틀린 꼴이 되기 때문이다. 물론 그 박해는 스페인 종교재판소 같은 것하고는 규모나 스케일이나 맥락이 좀 다른 박해이다.

사용자 삽입 이미지

그래서 부유한 과부들이 제일 호구였다. 마 23:14 / 막 12:40와 정확히 일치한다.
이교도 마녀로 몰아서 죽여 버리고 재산 몰수하면 끝이다.

사용자 삽입 이미지사용자 삽입 이미지

중세 유럽은 이랬다.

사용자 삽입 이미지사용자 삽입 이미지

종교 개혁은 유익하고 선한 결과물도 있던 한편으로, 한계도 있었다.
성경 번역 내력과 관련된 슬라이드는 생략한다.

사용자 삽입 이미지

이제 강의를 마무리 하는 퀴즈 차례이다.
처음엔 '아닌 것은'이라고 문제를 만들었다가.. 교육학적인 요소를 감안(?)하여 '옳은 것은'이라고 형태를 바꿨다.

사용자 삽입 이미지

교회사를 총망라 정리하는 마지막 문제이다. 나름 머리를 굴려서 만든 문제이긴 한데...

  1. 돌탕질 -- 율법을 어긴 죄인을 처형하는 방법으로, 유대인 동족끼리 행함. (예: 스데반의 순교)
  2. 십자가형 -- 고대 로마 제국에서 행하던 가장 잔혹한 처형 방법. 로마 시민에게는 하지도 않았음. 그래서 로마 시민권이 있었던 바울은 로마 대화재의 주범이라는 극악 죄인으로 몰렸음에도 불구하고 십자가형까지는 아니고 참수형을 당했다.
  3. 화형 -- 이건 뭐.. 종교 재판소가 1순위이고, 로마 제국도.. 인간 횃불이라는 방법으로 행했다고도 볼 수 있다. 다만, 동족 유대인이 행한 건 절대 아니므로 오답이다.
  4. 로마 제국 시절에 콜로세움에서 행해졌으니 이게 정답이고..
  5. 로마 제국은 몽둥이질 채찍질을 하고 잔인하게 처형을 했지만, 중세 종교 재판소만치 별 희한한 변태적인 고문까지 하지는 않았다.
사용자 삽입 이미지
이렇게 다음 강의자의 내용 예고도 해 줬다~ 이상. ㅎㅎ

Posted by 사무엘

2019/11/07 08:31 2019/11/07 08:31
, , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1681

등산 답사기: 수락산 #2

본인은 올해 가을엔 어쩌다 보니 등산 야영을 시리즈로 계속하게 됐다. (1) 예빈산(남양주), (2) 청계산 국사봉+발화산(의왕+성남) 다음으로는 (3) 수락산을 다시 찾아갔다. 한강 근처의 예빈산· 예봉산 일대도 남양주이고 서울 북동부의 수락산 근처도 남양주라니.. 실감이 잘 가지 않았다. 세부 행정구역이 별내면과 와부읍으로 서로 다르긴 하다만 말이다.

지금으로부터 3년쯤 전, 겨울에 장암 역 근처에서 수락산을 올라서 주봉 정상에 도달한 뒤, 남양주의 청학리 수락산 유원지 방면으로 하산한 적이 있었다. 산을 서에서 동으로 횡단한 것이다. 이번에는 차를 가져가서 수락산 유원지에서 등산을 시작한 뒤, 하산도 동일 지점으로 했다.

그러니 등산 경로의 관점에서 보면 이번 산행은 새로운 산이나 등산로를 개척한 것이 없었다.
하지만 시간이 3년에 가깝게 지나니 기존 경로도 충분히 새롭게 느껴졌으며, 수락산은 재방문만으로도 예빈산이나 청계산과는 사뭇 다른 경험을 선사했다. 암반이 많은 돌산이며, 물이 졸졸 흐르는 계곡도 있기 때문이었다. 그리고 무엇보다도...

사용자 삽입 이미지

이 등산로는 꽤 높은 곳까지 자동차 접근성이 좋았으며, 이렇게 차를 댈 만한 곳도 곳곳에 있었다. 내가 굳이 이 경로를 택한 주 이유 중 하나 역시 이것이었다.

경치 좋은 계곡의 주변 공간을 어디선가 무단 점유하고는 방문객에게 바가지 요금을 물리는 식당들의 불법 영업이 어제오늘 일이 아니었다. 그랬는데 올해는 이 관행을 근절하겠다고 경기도에서 주도적으로 칼을 뽑고 나섰다. 언제까지나 생계형 범죄랍시고 오냐 오냐 봐 주지 않겠다고 말이다. 그래서 그런지 여기도 식당들이 상당수 박살이 난 듯한 모습이었다.

한강 공원들만 해도 텐트와 야식 광고 찌라시, 쓰레기 때문에 몸살을 앓다가 지금은 질서를 많이 되찾았듯이.. 저것도 공권력이 마음만 먹으면 얼마든지 금방 바로잡을 수 있었던 일이었던 셈이다.

사용자 삽입 이미지

한참을 올라간 뒤에야 드디어 차도가 끝나고 사람만이 접근 가능한 돌계단과 비좁은 등산로가 나타났다.

사용자 삽입 이미지

이게 '금류 폭포'이며, 요런 게 바로 여느 흙산에서는 볼 수 없는 풍경이다. 흙바닥이 아닌 바위 위로 물이 줄줄..
이렇게 높은 곳에서도 아주 가늘게나마 물이 흐르는 산은 본인은 지금까지 수락산밖에 못 봤다. 이 정도면 물을 그냥 인위로 끌어올리기라도 한 건가 궁금해진다. 수락산 계곡에서 발원한 이 물은 평지에서 청학천으로 이어진다.

금류 폭포의 바로 옆엔 산장이라고 해야 하나 휴게소라고 해야 하나 자그마한 간이 식당까지 있었다.
예전에도 언급한 적이 있지지만, 여기는 국립공원이 아니기 때문에 이런 민간 산장이 들어서는 게 가능하다. 북한산 같은 곳이라면 등산로를 벗어난 계곡 근처는 몽땅 울타리가 쳐지고, 무단 침입 시 과태료가 부과되었을 것이다.

여기서 정상을 향해 더 올라가면 그리 멀지 않은 곳에 '내원암'이라는 바위와 함께 절인지 암자인지가 있다. 차량이 들어올 수 없는 높고 험한 곳치고는 건물과 마당을 포함한 부지가 꽤 넓었던 것으로 기억한다.
게다가 '해우소'라고 불리는 공중 화장실도 있었다. 실제로 이용해 보지는 않았지만 생긴 형태는 마치 수돗물이 여기까지 들어오기라도 하는 것처럼 수세식이었다.

하긴, 나중에 집에서 지도를 확인해 보니 금류 폭포와 내원암 정도는 해발 고도가 아직 300~350m밖에 안 되었다.
지금까지 올랐던 200여 m 고도는 경사가 여전히 굉장히 완만한 편이었고, 내원함 이후부터가 급격히 가팔라졌다. 실제로 빽빽한 계단을 오르고 또 올라야 하는 곳이 계속해서 등장했다.

사용자 삽입 이미지

아직 정상이 보일 기미가 안 보이는데 날은 계속해서 어두워져 갔다. 하긴, 오늘은 등산 자체를 오후 5시가 돼서야 시작했다.
정상에 거의 다 와서야 그 이름도 유명한 '수락 산장'과 함께 약수터도 등장했다. 1리터짜리 통을 다 채우는 데 내 기억으로 거의 1분 가까이 걸릴 정도로 수압이 낮았지만, 그래도 이 높이에서 맑은 물이 나오는 것만으로 어디냐.. 마시는 용도와 씻는 용도로 모두 도움이 됐다.

사용자 삽입 이미지사용자 삽입 이미지

결국 해가 다 떨어진 뒤에야 주봉 정상에 도착했다. 1시간 반쯤 걸렸다.
수락산엔 여기 말고도 능선에 온갖 이름의 기암괴석 봉우리들이 더 있고 다른 등산로도 있는데, 거기는 아직 가 보지 못한 게 아쉽다.

사용자 삽입 이미지

성경의 '반석 위에 지은 집'에서 착안하여 '반석 위에 친 텐트' 정도 되겠다. ㄲㄲㄲㄲㄲ
따뜻한 간이 숙소에서 휴식을 취하고 도시락을 먹었다.
산을 오를 때까지만 해도 힘들어서 옷이 땀으로 흠뻑 젖고 물을 다 마실 정도였지만, 날씨는 이내 급격히 추워지고 땀이 식었으며, 바람도 세차게 불기 시작했다.

전에 예영을 했던 산들은 한밤중에 정말 아무도 없었지만 이 산은 달랐다. 새벽 1시쯤에 야간 산행을 하는 일행이 수락산 정상에 왔다가 갔다.
아무도 없을 줄 알았던 산 정상 근처 바위에 텐트가 덩그러니 놓여 있으니 그 사람들도 좀 놀랐을 것 같다. =_=;;
"웬 텐트? 허걱~" 하는 소리를 본인도 듣긴 했지만.. 서로 마주치지는 않았다.

그리고 사실은 아까 전에 저녁을 먹고 있던 중에 텐트 문을 열었을 때는 근처에 웬 고양이 한 마리와 마주치기도 했다.
옛날에 인왕산 정상 부근과 북한산 정상에서도 고양이를 봤던 기억이 있다. 야생일 텐데 어디서 어떻게 먹고 사는지 모르겠다.

바람이 너무 세게 불고 시끄러워서 결국은 숙소를 정상 아래의 숲 속 공터로 옮겼다. 여기가 훨씬 더 조용하고 자기 편했다.
달빛이 밝았던 덕분에 주변도 한 치 앞이 안 보일 정도로 암흑천지는 아니었다.

사용자 삽입 이미지사용자 삽입 이미지

그리고.. 눈을 감았다 뜨니 이튿날 아침이 되었다. 처음에 텐트를 쳤던 곳의 낮과 밤 풍경은 이러했다.

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

탁 트인 정상 주변 풍경은 몹시 멋졌다. 근처의 불암산도 수락산보다 약간 더 낮고 작은 축소판일 뿐, 내부 제원(?)은 수락산의 판박이인 것 같다.

사용자 삽입 이미지

어제 깜깜할 때 지나갔던 길이 낮에는 이런 모습이었다.

사용자 삽입 이미지

하산하고 차가 세워진 공터로 돌아오니, 이제야 여기에 차를 몰고 와서 주차 자리를 찾는 등산객들 일행을 여럿 볼 수 있었다.
본인은 여기 올 때는 용마 터널과 구리-포천 고속도로(29) 같은 유료 도로를 적극 활용해서 갔지만, 귀가할 때는 그냥 순화궁로, 덕릉로, 동부 간선 도로 등의 기존 종축 도로만 타고 갔다. 글쎄, 서울 동쪽의 구리와 남양주 쪽으로는 유료 도로와 관련 진출입로들이 유난히 많이 눈에 띄는 것 같다.

  • 산을 관통하는 유료 터널: 용마(아차산), 별내(불암산)
  • 서울-양양 고속도로(60): 남양주*, 덕소삼패
  • 외곽순환 고속도로(100): 구리남양주, 불암산, 토평
  • 구리(세종)-포천 고속도로(29): 갈매동구릉*, 남별내
  • 수석-호평 도시고속화도로: 이패

서울의 남쪽이야 서해안(서서울), 경부(서울), 중부(동서울)라는 3대 '종축' 간선 고속도로가 시작되는 요금소가 있으며, 좀 더 생각하면 관악산 아래를 지나는 유료 도로인 남부순환로, 그리고 유료 터널인 우면산 터널 정도가 떠오른다.

그런데 서울의 동쪽에는 서울-춘천-양양이라는 '횡축' 간선 고속도로가 시작된다. 남양주는 마치 경부의 서울, 서해안의 서서울처럼 폐쇄식과 개방식을 전환하는 톨게이트이다. 그리고 덕소삼패는 남양주보다 전인 개방식 구간에 있지만 경부의 판교 톨게이트처럼 고정된 요금을 징수하는 톨게이트이다.

그리고 서울의 북동쪽으로는 구리(세종)-포천이라는 '종축' 간선 고속도로가 시작된다. 공식 명칭은 세종이지만 과연 그 길고 먼 구간이 모두 개통하는 때는 과연 언제가 될지 모르겠다. 얘는 갈매동구릉 톨게이트가 폐쇄식과 개방식이 전환되는 곳이며, 여기 근처에서는 북중랑 톨게이트를 통해 고속도로를 드나들 수 있다.
폐쇄식 요금소와 개방식 요금소가 뒤섞여 있으니 구조가 더욱 복잡하게 느껴진다. 폐쇄식과 개방식 요금제는 열차로 치면 지정석과 자유석의 관계와도 비슷해 보인다.

서울 북쪽 외곽의 노고산, 사패산, 수락산, 불암산은 모두 터널이 뚫려 있다. 그 중 수락산 아래를 지나는 덕릉 터널만이 무료이고, 나머지는 다들 유료 터널이거나 유료 도로인 외곽순환 고속도로 구간에 포함돼 있다.
이에 덧붙여 수석-호평 고속화도로는 고속도로도, 터널도 아닌 마치 제3 경인 고속화도로와 비슷한 급의 유료 도로이다.

Posted by 사무엘

2019/11/04 08:32 2019/11/04 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1680

1. 흡연과 재떨이

오늘날은 옛날에는 상상도 할 수 없었을 정도로 금연이 당연한 사회 풍조로 정착했다.
군대에서 보급 담배는 진작에 없어졌으며, 담뱃갑에는 끔찍한 사진과 함께 경고문이 반드시 일정 크기 이상으로 부착되는 게 의무가 됐다.

버스 정류장을 포함한 모든 공공장소와 대중교통 내부에서는 담배를 일체 피울 수 없다. TV 드라마 같은 데서 담배를 뻑뻑 피우는 모습을 내보내는 것조차도 금지됐으며, 부득이하게 흡연 동작이 포함된 영화 장면 따위를 인용할 때는 담배가 무슨 흉기이기라도 한 것처럼 모자이크 처리를 하게 됐다.

하지만 그렇게까지 강하게 규제를 걸고 금기시해도.. "흡연은 폐암을 유발합니다", "당신이 지불한 담뱃값은 국회의원들 월급 주는 데 쓰입니다" 등의 온갖 기발한 문구로 경고를 해도..
그래도 담배를 피울 사람은 여전히 피운다.. =_=;; 수 년 전에 담뱃값이 2500원에서 4500원으로 폭등했어도 담배 판매량과 매출은 이내 예전 수준을 회복했다고 하니 말이다.

옛날에는 그런 풍조를 반영하여 승용차에도 앞쪽 대시보드의 아래엔 시거라이터 잭(...)과 재떨이가 있었으며, 좀 고급 승용차는 뒷좌석 도어의 안쪽에도 재떨이가 비치되어 있었다.
그에 반해 요즘 차는 뒷좌석 재떨이까지는 없다. 전국 지도(< 내비게이션)라든가 돌돌이 닭다리 창문 개폐 크랭크(< 파워윈도우)만큼이나 이제는 찾아볼 수 없어진 물건이다.

그래도 내 차를 살펴보니 시거라이터는 있다. 지금까지 동전통으로 사용했던 자그마한 통이 알고 보니 재떨이였구나..;; 물론 지금까지 이 통에는 담뱃재가 담긴 적은 단 한 번도 없었다.
그 옆에 하이패스 단말기를 연결해 두는 소켓은.. 자동차에만 존재하는 전자기기용 플러그이기라도 한가 모르겠다.

자, 비행기와 관계 없는 서론이 좀 길어졌는데..
이런 강력한 금연 트렌드에도 불구하고 여객기의 화장실 안에는 재떨이 비스무리한 물건이 2019년 현재까지도 의외로 여전히 남아 있다.
기내엔 흡연은커녕 액체 연료 라이터조차도 반입을 못 할 텐데, 그리고 기내 금연은 여객기의 내구연한보다 더 오래 전부터 시행되었을 텐데?
심지어 금연 표지판 바로 옆이나 밑에 재떨이가 버젓이 비치되어 있기도 하다. 왜 그런 걸까? 그 이유는...

사용자 삽입 이미지

아무리 화장실에다 연기 감지기를 설치하고 제발 화장실에서 담배 피우지 말라고 계도를 해도 말 안 듣고 담배를 몰래 피우는 사람이 수많은 탑승객들 중에 꼭 한둘씩 있기 때문이다. 장거리 노선이면 그 긴 시간 동안 담배를 전혀 피울 수 없으니 괴로울 법도 하다. 비행기에 고속버스처럼 휴게소가 있는 것도 아니고..

그래서 기어이 피울 거면 일말의 양심을 발휘해서 담뱃재와 꽁초를 아무 데나 버리지 말고 여기에다가 버리기라도 하라는 자포자기 심정으로 재떨이를 남겨 놓은 거라고 한다..;; 버릴 곳이 없어서 담배 꽁초가 휴지통을 포함한 아무 데나 떨어지면 최악의 경우 다른 쓰레기에 불이 붙어서 기내에 화재가 발생할 수 있기 때문이다.

이 재떨이는 기내에서 흡연이 가능하던 시절의 잔재 레거시가 아니며, 새로 만들어진 비행기도 반드시 갖춰야 하는 법적 의무 사항이다. 마치 자동차에 법적으로 방향지시등과 헤드라이트, 안전벨트가 반드시 있어야 하는 것만큼이나 말이다. 흡연자들을 배려해서가 아니라 화재 예방을 위해서 갖다 놓은 거라고 생각하면 정확하다.
육해공 대중교통 중에서 그나마 흡연이 제일 자유로운 곳은 역시나 선박인 것 같다. 갑판이 있으니까..;;.

여담이지만, 극장에서 영화 본편이 끝나고 엔딩 크레딧이 올라올 때 불이 켜지는 것도 '금연 비행기 내부의 재떨이'와 비슷한 맥락에서 존재하는 관행이다. 영화 제작자들이 엔딩 크레딧을 아무 이유 없이 만드는 게 아니고, 도의적으로 원칙적으로는 모든 관객들이 이것까지 다 진지하게 봐야 영화가 완전히 끝나는 게 맞다.

하지만 현실에서는 불을 켜건 말건 엔딩 크레딧이 나오기 시작하면 자리를 뜨고 나가는 관객이 적지 않으며, 이때 조명이 없으면 깜깜한 계단에서 넘어지는 사고가 발생하기 쉽다. 그런데 이러다 사람이 다치면 극장에 대한 고소로 이어지기 때문에(...), 시빗거리를 없애기 위해 "조기 조명 ON"이라는 권장되지 않는 관행이 극장에 존재하게 되었다.

2. 비행기 이모지

유니코드에는 U+1F6EC Airplane Arriving이라는 이모지가 있는데..
본인은 이걸 보니 피식 웃음이 나왔다.

사용자 삽입 이미지

현실의 비행기는 다들 아시다시피 착륙할 때도 이륙할 때와 마찬가지로 기수가 위를 향하고 있다. 뒷쪽이 앞쪽보다 먼저 착지한다.
이와 달리 저 그림처럼 기수가 아래를 향한 채로 하강하는 건 아무리 봐도 착륙이 아니라 추락하는 모습이다..;;;

일출 노을 풍경과 일몰 노을 풍경을 일반적으로 서로 구분할 수 없듯이.. (그림자 방향이나 지형 같은 단서가 없다면)
정지 사진만으로 비행기의 이륙과 착륙을 구분하는 건 내가 알기로 불가능하다. 굳이 따지자면 이륙이 착륙보다 미세하게나마 더 고각이긴 할 것이다.

그래서인지 이모지에서는 그냥 편의상 기수의 방향과 랜딩기어의 수납 여부로 이륙과 착륙을 구분시켜 놓은 것 같다.

3. 우주 발사체와의 차이

고정익 비행기와 우주 발사체(인공위성? 로켓?)는 모두 지표면에서 끊임없이 수평 이동을 해야 고도가 유지되며, 속도가 너무 느려지면 추락한다는 공통점이 있다. 그러나 이 둘은 당연한 말이지만 요구되는 속도의 수준과 추락 조건이 서로 완전히 다르다. 급이 다르고 차원이 다르다.
마치 육상 교통수단들이 고속으로 갈수록 더 가속하기가 어려워지는 건 공기 저항 때문일 뿐이지, 무슨 광속에 가까워지면서 상대성 이론에 따라 질량이 증가하기 때문은 전혀 아닌 것과 같은 이치이다.

비행기가 빠르게 이동하는 이유는 날개의 상하로 공기의 압력 차이를 만들고 이로부터 양력을 얻어야 뜰 수 있기 때문이다. 자동차는 연료를 연소시키기 위해서 공기 중의 산소가 필요하지만, 비행기는 엔진을 돌리는 것뿐만 아니라 뜨는 것 자체를 위해서도 공기라는 유체가 필요하다. 이걸 유지할 만한 속도를 못 내어 비행기가 양력을 잃고 조종성까지 상실하는 것을 실속(stall)에 빠졌다고 말한다.

한여름에 날씨가 너무 더워지면 공기가 부피가 커지고 밀도가 낮아지는데, 이러면 비행기도 뜨기가 어려워져서 활주거리가 길어진다. 그래서 작은 공항에서는 폭설도 아니고 폭염 때문에 큰 비행기가 뜨지 못해서 결항될 수 있다. (이륙 활주 공간 부족)
또한, 이륙 후에도 공중에서 공기가 갑자기 희박해지는 곳을 지나면 비행기가 고도를 유지하지 못하고 아래로 주저앉게 된다. 이건 폭염으로 인한 레일의 팽창 때문에 고속철이 서행 운행하는 것만큼이나 비행의 악재로 작용한다.

이런 비행기와 달리 지구 궤도를 도는 우주 발사체는 공기와 전혀 무관하게 움직인다. 실속이고 상승 기류고 난류고 나발이고 없다. 애초에 공기를 받는 날개가 있지도 않으며, 로켓은 양력이 아니라 전적으로 추력만으로 날아간다. 비행기의 제트 엔진과 달리, 로켓은 주변의 공기를 빨아들이지 않으며 오히려 연료와 함께 산화제를 자체적으로 내장하고 있다.

그리고 로켓은 그야말로 공기와의 마찰을 걱정해야 할 정도로, 초음속 여객기 콩코드가 그나마 돌파해 봤다는 지구 적도 표면의 자전 속도보다도 10배 이상 빠르게 이동한다.
지표면으로 수직으로 떨어지는 속도보다 수평 이동하는 속도가 커야 지구를 향해 "한없이 추락"하는 게 가능하기 때문이다. 이게 바로 우주 발사체가 추락하지 않고, 그리고 연료도 거의 쓰지 않으면서 비행(?)하는 비결이다.

달로 가는 로켓이라고 해서 무슨 위를 바라보고 달을 향해서 한없이 쭉쭉 올라가는 게 아니다. 우주로 나가는 모든 로켓들은 단별로 가동 시간이 보통 겨우 몇 분, 길어야 10분을 채 넘기지 않는다. 그 짧은 시간 동안 그 많은 연료를 몽땅 소모하면서 수직으로는 겨우 수십~수백 km 위로만 올라가며, 발사체가 지상의 시야에서 사라질 즈음에는 기수를 기울여서 수평으로 필사적으로 가속한다. 지구 궤도를 도는 상태를 만드는 것이 로켓의 목적인 것이다.

쉽게 말해 비행기는 한국에서 미국까지 날아가는 10몇 시간 내내 엔진이 켜져 있다. 그러나 로켓 내지 우주 발사체는 그렇지 않다는 것이 핵심이다. 달로 갈 때는 지구를 도는 타원 궤도의 이심률을 키우고 달 궤도로 끌려가기 위해서 또 가속을 하지만, 그 가속 시간 역시 단 몇 분에 지나지 않는다. 나머지 며칠 동안 날아가는 건 전부 관성 무동력으로 행해진다.
비행기와 로켓이 서로 얼마나 다른 존재인지를 알 수 있다.

Posted by 사무엘

2019/11/01 19:34 2019/11/01 19:34
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1679

한글 IME 개발 관련 에피소드

1. 크롬 브라우저

Google 크롬 브라우저는 뭔 바람이 들어서 디자인이 갑자기 동글동글하게 바뀌었나 모르겠다. 탭과 각종 버튼들, 주소 입력란의 테두리가 말이다. 본인이 변화를 감지한 건 대략 버전 69(작년 9월쯤)부터이니 벌써 1년 남짓 됐다. 탭 모양이 저렇게 바뀌니까 크롬이 아니라 다른 브라우저를 쓰는 것 같다.

혹시 기억하는 분이 계시려나 모르겠는데, 크롬은 원래는 탭이 각진 사다리꼴 모양이었다.
Edge도 탭의 테두리가 그냥 직사각형 모양이다가 차기 베타 버전은 약간 둥글어져서 "edge"가 좀 무뎌졌다. 그에 반해 FireFox는 직사각형을 고수하고 있는 것 같다. 아무튼..

크롬은 그렇게 외형이나 HTML 파싱 및 렌더링 엔진, JavaScript 엔진이나 개선하면 될 것을.. 한중일 문자 입력을 받아들이는 IME 계층까지 지난 1년간 왜 이렇게 널뛰기 하듯이 바뀌는지 모르겠다. 나의 오랜 소감을 말하자면, 크롬은 IME 지원이 파이어폭스보다 더 열악하고 버그가 더 많으며 더 불안정하다. 현재 Firefox는 TSF도 완전히 지원하지만 크롬은 여전히 그렇지 않다.

(1) 크롬 버전 71(작년 12월 중반)쯤에는.. 주소창에서 바로 한글 검색어를 입력하기 위해서 네이버나 위키 등의 주소를 자동 완성한 뒤 바로 탭을 눌렀는데, 한글 첫 타는 조합이 끊기는 현상이 발생했던 적이 있다. 'ㅎㅏㄴ글' 이렇게 말이다.
MS, 날개셋 모두 동일하게 발생하기 때문에 외부 모듈 쪽 문제가 아니다. 단, 이건 버전 73쯤부터 해결된 듯하다.

(2) 저거보다 더 오래되고 심각한 문제로.. 크롬은 대략 2016~17년이니 굉장히 오래 전부터(50대 버전), 주소창에서 한글을 조합하는 중에('고') 마우스로 주소창 딴 곳을 클릭해서 조합을 끊으면.. 내부적으로 조합 종료가 제대로 처리되지 않아서 조합이 덧나는 버그가 있었다. 새로 cursor 위치가 바뀐 곳에서도 기존 한글 조합이 계속되었다. ('ㅏ' 대신에 '과'로..)

날개셋만 그런지 MS IME도 그런지는 기억이 안 난다만.. 오래 전부터 알려진 문제였기 때문에 내 프로그램의 도움말에다가도 이 현상을 언급해 놓았다.
고급 옵션에서 "하드웨어 가속 기능 사용"을 켰을 때만 발생하는 문제라는 것도 굉장히 괴이한 점이었다. 그래픽에서의 하드웨어 가속이랑 IME의 동작이 도대체 무슨 상관이 있단 말인가?

그랬는데 버전 74쯤에서는 다행히도 이 문제가 '사라졌다.' 역시 크롬에서 자체적으로 이 버그를 수정한 것이었다. 모든 일이 해피엔딩으로 끝나는 듯했다.

(3) 허나, 올해 상반기 크롬 75쯤부터는 상황이 최악으로 나빠졌다.
고쳐진 듯하던 '고과' 문제가 재발했으며, 한글을 입력하던 중에 비한글 문자를 입력하다 보면 프로그램이 그냥 뻗고 꺼져 버렸다. 도대체 뭘 건드렸길래.. >_<

크롬 카나리아 77의 경우, 한글을 조합하던 중에 마우스로 딴 델 찍으면 조합 상태는 초기화되지만 그 조합 문자열이 두 번 덧나곤 했다. '가가'가 되었다. 그러면서 프로그램을 쓰다 보면 뻗는 건 동일했다.
그래도 어쩌겠나. 크롬은 그야말로 세계구 급인 프로그램인데 내 입력기가 크롬의 동작에 맞춰야지.. >_<

덕분에 날개셋 한글 입력기 9.8은 크롬에서 최소한 프로그램이 뻗지는 않게 개선되었다. 그리고 사실은, 이걸 작업하면서 Firefox에서 자잘하게 오동작하던 문제, IE + 키보드 보안 ActiveX이 돌아가는 모 사이트에서 내 입력기가 뻗던 문제까지 덤으로 해결됐다. 그러니 내 프로그램도 일말의 개선의 여지가 있긴 했던 모양이다.

(4) 크롬이 같은 75.x 버전대에서 또 잠수함 패치된 뒤부터는.. '고과' 문제는 없어졌으나, 한글 조합 중에 Alt+D나 마우스 클릭 같은 행동을 하면 카나리아 77처럼 '가가'로 덧나는 문제가 발생하기 시작했다. 크롬 본버전과 크롬 카나리아의 동작이 동일해진 것이다.
날개셋 9.8은 뻗는 문제까지만 해결됐지 '가가' 문제는 여전히 갖고 있다. 이건 지난 9.81버전에서야 추가로 조치가 취해졌다.

세상에 같은 조작 요청을 했는데 굳이 저렇게 이상하게 동작하는 프로그램은 난 지금까지 크롬밖에 못 봤다. 크롬 최신 버전은 조합이 외부에 의해 종료됐을 때 그때 IME에서 조합 문자열을 딴 걸로 변경하면 정신을 못 차리는 것 같았다.

그게 지금의 78 버전에까지 이어지고 있고, 78은 바로 지난번에도 언급했듯이 갑자기 겉으로 메트로 앱인 것처럼 동작하는 것 같다. 내부는 딱히 달라지지 않았는데도 말이다. 뭐가 자꾸 많이 바뀌는 중이다.

2. MS Word에서의 겹침 모드 지원

운영체제의 GUI에서 제공하는 기본적인 텍스트 입력란(컨트롤? 위젯?)은 대개 삽입 모드만 존재한다. 그러나 본격적인 텍스트 에디터나 워드 프로세서들은 ins 키를 이용해서 겹침 모드라는 것도 같이 제공하곤 한다.

일반적인 영문 입력에서야 겹침 모드를 구현하는 건 일도 아니며, 한글 입력 정도만 돼도 반드시 1글자씩만 조합했다가 덮어써지는 것이 명확하기 때문에 일이 그리 어렵지 않다.
특히 Windows에 문자 입력 프로토콜이 재래식 IME밖에 없던 시절에는 텍스트 입력란을 제공하는 응용 프로그램이 겹침 모드를 그리 어렵지 않게 재량껏 구현할 수 있었다. IME는 확정된 형태의 문자열과 조합 형태 문자열을 알려 주기만 하지, 이걸 본문에 삽입하는 건 응용 프로그램의 재량이었기 때문이다.

물론 중국어· 일본어 IME는 임의의 길이의 문장을 조합으로 잡아서 한꺼번에 내보낼 수 있기 때문에 겹침 모드라는 게 사실상 별 의미가 없다. 그렇다면 그냥 1~2글자씩만 주고 받을 때나 한국어 IME일 때만 겹침 모드를 지원하는 식으로 프로그램이 동작하면 됐다.

그런데 TSF라는 새로운 프로토콜이 도입되면서 상황이 다소 복잡해졌다.
TSF는 cursor 위치를 옮기고 거기에 무슨 텍스트가 있는지 얻어 오고, 텍스트의 일부 구간을 블록을 잡고 거기를 새로운 내용으로 대체하는 등.. 삽입/겹침이라는 모드별로 행해지는 동작을 저수준으로 직접 기술을 할 수 있다. (비록 모든 프로그램에서 이 정도로 자유로운 조작이 가능한 건 아니지만)

그렇기 때문에 이 체계에서는 겹침 모드에 따른 동작을 응용 프로그램이 아니라 해당 외부 모듈이 달리 처리하는 게 바람직하다. 텍스트 에디터의 삽입/겹침 상태가 TSF compartment 값으로 주어지기 때문에 외부 모듈은 이 값을 참고할 수 있고 말이다. 하지만 마소에서 프로그램을 그런 식으로 개발하지는 않은 것 같다.

MS Word의 경우, 먼 옛날 97~2000까지는 내 기억이 맞다면 IME 기반으로 그냥 trivial한 방법으로 겹침 모드를 제공했었다. 한글 입력에 대해서도 겹침 모드가 없지는 않았다.
그러다가 TSF로 바뀐 XP부터는 한글에 대해 겹침 모드가 사라졌다. 2003에서는 "한글 입력에 대해서는 겹침 모드가 지원되지 않습니다"라고 에러 메시지도 나타났다.

사용자 삽입 이미지

그랬는데 2007인가 2010에서는 TSF 기반으로도 한글 겹침 모드가 잠시 구현되었다. 외부 모듈이 아닌 Word에서 자체적으로 말이다.
아마 외부 모듈이 요청하는 문자 삽입 요청을 재구성하여, 요런 패턴을 만족하는 것은 진짜 삽입이 아니라 뒷글자를 대체하는 식으로 동작하게 인위적인 보정을 했던 것 같다.

게다가 이건 특정 외부 모듈, 아니 특정 패턴을 대상으로만 불완전하게 동작했다. 똑같이 한글을 삽입하고 한글 다음에 비한글 문자를 집어넣는데, 같은 마소 IME에서만 겹침 모드가 동작하고, 날개셋이나 한컴 IME 같은 3rd-party IME에서는 동작하지 않았다.
겹침 모드로 인식되게 하는 패턴을 개인적으로는 찾아내어 파악했다. 하지만 당장 날개셋 외부 모듈의 동작을 그렇게 고칠 수는 없다. 수많은 다른 부작용에 대한 우려 때문이다.

그리고 결정적으로는..
최근에 MS Office의 기간제 구독형 에디션인 365를 설치해 봤는데.. Word에서 겹침 모드로 지정해도 이제는 마소 기본 IME도 겹침 모드가 전혀 인식되지 않고 언제나 삽입 형태로만 동작했다. 몇 번이나 확인해 봐도 그렇다. 설마 365랑 정규 에디션인 201x가 동작이 서로 다를 리는 없을 테고..

겹침 모드를 저렇게 무리수로 구현하는 건 영 아니다 싶어서 도로 뺀 것 같다. 본가인 마소에서 포기했으니 날개셋 역시 겹침 모드에 대해서는 전혀 신경 쓸 필요가 없어졌다.
이야기가 좀 찝찝하게 끝난 것 같은데.. 다시 말하지만 내 생각은 TSF 환경에서는 삽입/겹침을 각 외부 모듈이 알아서 처리하는 형태가 됐으면 좋겠다. 날개셋 한글 입력기의 엔진은 그걸 가정하고 개발되었기 때문이다. 지금 텍스트 입력 모드가 겹침 모드라는 것을 알 수 있다면 당장 그렇게 동작할 수 있다.

날개셋 외부 모듈은 처음에는 언제나 겹침 옵션이 꺼져 있고 삽입 모드로만 동작한다. 날개셋 편집기를 쓸 때처럼 ins 키가 지원되지는 않으니 날개셋 제어판을 열어서 '겹침 모드' 옵션을 수동으로 골라 줘야 한다. 그리고 이 옵션은 TSF를 지원하는 프로그램에서만 사용 가능하다.

Posted by 사무엘

2019/10/30 08:32 2019/10/30 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1678

날개셋 한글 입력기 9.82

날개셋 한글 입력기 9.82가 어제, 9.81 이후 딱 두 달 만에 완성되어 나왔다. 딱히 원조가카의 서거 40주년에 맞춘 것은 아니다. 24일이나 25일에 완성을 못 했기 때문에 26일에 완성하게 됐을 뿐이다.

원래 생각 같아서는 아예 이 달 초 한글날쯤에 공개하고 싶었다. 그러나 답이 없는 지독한 버그(알고 나면 별것 아니지만..)와 컨디션 조절 실패 때문에 일정이 늘어져서 그보다 훨씬 더 늦게 나오게 됐다.

이번 버전은 눈에 띄는 기능 추가가 아니라 개선과 버그 수정 위주이다. 그러니 버전 번호도 0.01만치만 증가했다. 그리고 타자연습은 변화가 없으며, API 호환성도 달라지지 않았다.
그럼에도 불구하고 이번 9.82는 유의미한 변화를 열거하라면 꽤 많다. 특히 외부 모듈 내지 입력 도구 UI와 관련된 것이 많다.

1. 한자 변환 UI 관련

(1) 바로 직전 버전인 9.81부터는 MS Word의 우클릭 메뉴를 통해서 단어 단위로 한자 변환을 할 수 있게 되었다. 그런데 한자를 고르지 않고 ESC를 눌렀을 때 블록으로 잡힌 단어가 사라지는 문제를 비롯해 몇몇 사소한 glitch들이 있던 것을 바로잡았다. 오랫동안 본인의 심기를 건드려 온 찝찝한 문제였는데 드디어 해결되어 기쁘다.
또한, 단어의 앞부분 일부만 한자로 바꾼 뒤에 cursor가 다시 원래 있던 뒷부분으로 되돌아오는 것도 날개셋 편집기 내지 MS IME와 동일하게 처리되게 했다.

(2) 한자 변환 UI의 선택막대를 더 큼직하게 키웠다. 특히 간격이 하드코딩된 픽셀수로 지정되어 있어서 화면 DPI가 올라갈수록 실질적인 간격이 말도 안 되게 좁아지던 문제를 해결했다. 이제 high DPI 환경에서도 한자 변환 기능을 사용하기가 더 수월할 것이다.
아래 그림은 각각 100%와 150%배율에서 before와 after 모습이다.

사용자 삽입 이미지

(3) 그리고 키 동작 방식을 MS IME의 UI와 더 일치하도록 바꿨다.
가령, space로도 항목을 이동할 수 있으며, 화살표 키로 선택막대가 페이지의 시작이나 끝에 도달한 뒤에는 다시 끝이나 시작 지점으로 순환되게 했다. 또한, page up/down을 눌렀을 때는 선택막대가 해당 페이지의 맨 처음 지점에 가게 했다.

(4) 끝으로, 아까 저 한자 변환 UI 그림에서 '기사'의 위치를 보면 유추할 수 있듯, cursor의 아래에 나타나는 모든 UI들이(입력 도구).. 창 테두리가 아니라 창 내부 글자가 cursor의 바로 아래에 나타나도록 표시 위치를 조정했다. 아래 그림에서 위는 before이고, 아래는 after이다.

사용자 삽입 이미지

또한, 목록에도 불필요하게 여백이나 스크롤 영역이 생기지 않도록 초기의 창의 크기가 더 정확하게 계산되게 했다. 그 차이도 위의 그림에서 이미 묘사되어 있다.
옛날에는 이런 게 왜 눈에 들어오지 않았던가 모르겠다.

2. 엑셀에서 입력 도구의 특이한 오동작

날개셋 한글 입력기가 제공하는 입력 도구 중에는 GUI 요소에 콤보 상자가 들어있는 것이 있다.
'부수로 한자 입력'에서 부수의 획수를 고르는 UI, 그리고 '문자표'의 위쪽에서 글꼴과 문자표 종류를 고르는 UI 말이다.

사용자 삽입 이미지

그런데 MS Excel에서 날개셋 외부 모듈을 구동한 뒤, 여기서 저런 입력 도구의 콤보 상자를 눌러서 열고 나면 몇 초 못 가, 혹은 심지어 마우스 포인터를 살짝 움직이기만 해도 열었던 콤보 목록이 저절로 닫혀 버리곤 한다. 그래서 글꼴이나 획수 같은 걸 제대로 선택할 수 없다.
이건 다른 프로그램들은 괜찮고 오로지 엑셀에서만 발생하는 문제이다. MS Word에 black blank 문제가 있는 것처럼 Excel도 특이한 동작 방식이 존재하는 셈이다.

이것 때문에 본인은 며칠을 끙끙대며 헤맸으며, 그 과정에서 입력 도구 UI 엔진의 여러 미세한 버그들, 불필요한 코드 따위를 제거하는 부수적인 효과를 내긴 했다. 그러나 이 문제는 근본적으로는 엑셀이 굉장히 특이하게 동작하면서 날개셋 한글 입력기의 동작까지도 교란하기 때문에 발생한다.

심지어 마우스 휠을 굴렸을 때의 반응도 다르더라.
요즘 Windows에서는 입력 도구에서 마우스 휠을 굴리면 그게 입력 도구로 가는 반면, 엑셀에서만은 여전히 이전 버전 Windows처럼 휠 이벤트가 엑셀 창으로 간다.
내 추측으로는 쟤들도 마우스 관련 훅킹이라도 해서 마우스 포커스를 가로채는 것 같다.

엑셀에서 콤보 목록이 닫히는 문제는 엑셀의 버전에 따라 양상이 둘로 나뉜다.
첫째, 2007 초창기 버전과 그 이하의 구버전에서는 그냥 콤보 상자를 누르고 가만히만 있어도 몇 초 후에 목록이 닫힌다. 이건 근본적인 해결이 불가능하며, 저 예외적인 상황만 감지해서 어거지로 보정하는 것도 가능하지 않다.

둘째, 2007 SP3쯤과 2010 등 이후 버전에서는 콤보 목록을 연 뒤 마우스 포인터를 살짝 움직이면 목록이 닫힌다. 이건 다행히 내 프로그램에서 동작을 변경함으로써 해결 가능한 것을 확인했으며, 이번 9.82 버전에서 반영됐다. 최신 버전에서 해결 가능한 문제이니 이 문제는 사실상 해결된 것이나 마찬가지이다.

그리고 정사각형 문자표가 있는 입력 도구들(부수, 문자표, 이모지..)을 마우스로 클릭하고 잠시 있으면 확대된 글자를 잘 보라고 마우스 포인터가 사라지는데..
이때도 엑셀에서는 알 수 없는 이유로 인해 포인터가 사라지지 않곤 했다. 사라졌다가도 마우스 포인터를 살짝 움직이면 다시 나타났다.
그 문제를 이번에 덤으로 해결했다. 마우스 포인터를 숨기는 방법을 바꿨다. 이건 콤보 목록이 닫히는 문제와는 별개의 문제였다.

참고로, 당연한 말이지만 외부 모듈이 아니라 입력 패드에서 입력 도구들을 꺼내면 Excel에서도 아무 차이 없이 입력 도구들을 사용할 수 있다. 얘는 아예 별도의 프로세스에서 입력 도구를 구동한 것이기 때문이다.

3. 아래아한글에서의 미세한 문제

아래아한글은 MS Word와 달리 전통적으로 TSF를 지원하지 않는 불모지였다. 그런데 2018을 뒤늦게 써 보니 여기에도 변화가 느껴졌다. 비록 문서 본문은 변함없지만 대화상자의 텍스트 입력란에서는 TSF가 지원되기 시작했기 때문이다. 마소나 날개셋 한글 IME에서 단어 단위로 한자 변환을 할 수 있으며, backspace 달라붙기 같은 기능들이 모두 제대로 동작한다.

2010년대 중반이 되니 유니코드 5.2 방식의 옛한글 글꼴이 운영체제 차원에서 완전히 정착했고, 2010년대 후반이 되니 날개셋 말고도 TSF 기반의 한글 IME가 만들어져 나오고 심지어 TSF를 지원하는 텍스트 에디팅 엔진도 나오는구나 하는 생각이 든다. 뭐, 아래아한글의 경우, 문서 본문에도 TSF를 지원하는 건 여전히 쉽지 않을 것이다.

다만, 이렇게 아래아한글에 TSF 기반 텍스트 입력란이 구현되면서 날개셋 한글 입력기와도 충돌을 일으키기 시작했다. 버그 내지 오동작 의심 증상이 무려 세 가지나 있었는데, 이것 때문에 개인적으로 굉장히 힘든 나날을 보냈다.

  • 첫째는 그냥 답이 없는 문제였다. 안 그래도 동작 방식이 A형 B형 둘로 나뉘어 있는데, 아래아한글은 이미 알려진 다른 유형인 B형으로 인위로 보정을 해 줘야 했다.
  • 둘째는 프로그램이 뻗을 수도 있는 제일 치명적인 문제인데, 엄~밀히 말하면 내 입력기의 버그가 맞았다. 조합 상태가 아니면 그냥 조합을 완전히 해제해야 하는데 빈 조합으로 남겨 놓고 있었다. 하지만, 그런 결함이 있다고 실제로 이상한 문제를 외형적으로 일으키는 프로그램은 아래아한글이 처음이었다.
  • 마지막 셋째는 도대체 왜 내 입력기를 쓸 때만 이상하게 동작하는지 알 길이 없었는데, 알고 보니 일반적인 상황에서는 발생할 일이 없는 문제라는 것을 최종 확인했다. 간단하게만 말하자면 날개셋이 제공하는 한자 변환 기능과, 아래아한글이 자체적으로 제공하는 한자 변환 기능이 충돌하는 문제이다.

세 문제가 원인과 해결책이 전부 저 정도로 제각각으로 달랐다. 그래도 어쨌든 다 해결되니 기쁘다.

4. 크롬과 에지

(1) 마소의 Edge 브라우저가 크로뮴 기반으로 재개발(?)되고 있으며, 현재 베타 버전이 공개돼 있다. 그런데 얘는 크롬과 동일한 엔진(크로뮴) 기반이어서 그런지 예전의 크롬과 동일하게 조합 중인 글자가 덧나는 버그가 있었다. 이에 대한 보정을 추가했다.

(2) 그리고 크롬도 최근에 버전 78로 업데이트가 됐는데.. 생뚱맞게도 자신이 Metro 앱이라고 IME에다가 알려주고 있었다.
Metro 앱 환경에서는 통상적인 데스크톱 GUI가 제공되지 않기 때문에 날개셋 제어판을 꺼낼 수 없다. 그렇기 때문에 이 환경에서는 내 프로그램 역시 제어판을 여는 버튼을 disable시켜 버린다.

그런데 본인이 확인해 본 결과, 크롬과 Edge 베타 모두 말은 그렇게 해도 데스크톱 GUI의 구동에는 문제가 없었다. 그렇기 때문에 이번 버전에서는 저 프로그램에서 제어판이나 각종 대화상자들을 변함없이 열 수 있게 보정을 추가했다.

5. 외부 모듈의 응용 프로그램별 수동 보정 옵션

이 기능은 오래 전부터 날개셋 한글 입력기에 도입할까 말까 망설였는데.. 크롬 버그 이후로 갈수록 증가하는 glitch 신고를 계기로, 더는 대세를 거스를 수 없겠다 싶어서 결국 구현하게 되었다.
무엇인고 하니, 날개셋 한글 입력기가 응용 프로그램마다 호환성 차원에서 일부러 다르게 보정해서 동작하는 세부 알고리즘을 외부에 노출하고, 사용자가 프로그램별로 이를 수동으로 customize 할 수 있게 하는 것이다. 내부에 하드코딩 되어 있던 보정 규칙 테이블이 이 기회에 개방되었다.

Windows용 한글 IME라는 건 단일 로직으로 모든 프로그램에서 정확하게 동작하는 것이 불가능하다는 것이 확실시되고 있다. 크롬 브라우저와 MS Word는 걔네들에게만 적용되는 고유한 보정이 존재하고, 그것 말고도 전반적이 통신 방식이 크게 A와 B라는 두 갈래로 양분되어 있다.
어느 방식으로 통신하나 잘 동작하는 프로그램도 물론 있고 그래야만 정상이지만.. >_< 현실에서는 둘 중 한 방식을 거부하는 프로그램도 있다.

특히.. 지난번 9.8 시절의 크롬 버그를 잡고 그 방법을 다른 프로그램에다가도 범용적으로 적용시켰더니.. 기껏 지금까지 잘 돌아가던 모 프로그램에서 부작용이 발생하더라는 연락을 개인적으로 받기도 해서 멘붕했다.
아, 여기서 버그나 오동작이라는 건 한글 입력 자체가 안 된다기보다는 IME의 문자 입력 이벤트에 응용 프로그램이 반응을 제대로 못 해서 글자가 덧난다거나, 조합 중인 문자열이 사라진다거나 하는 glitch들을 말한다.

이제 제어판의 '시스템 계층'을 보면 "한글 표현 방식"과 "고급 시스템 옵션"의 아래에 "프로그램 호환성"이라는 카테고리가 하나 더 추가되며, 지금 당장 실행돼 있는 프로그램을 대상으로 통신 방식과 몇몇 보정 방식을 변경할 수 있다.

사용자 삽입 이미지

'대상 프로그램'은 지금 날개셋 IME가 동작하고 있는 프로그램이 가장 먼저 제시된다. 하지만 콤보박스를 열어 보면 현재 실행돼 있는 프로그램 또는, 실행되지 않았더라도 보정 정보가 등록된 프로그램을 고를 수 있다. 프로그램은 그냥 실행 파일 이름으로 식별한다.

앞으로 미묘하게 뭔가 잘 동작하지 않는 프로그램을 발견한 경우, 어지간해서는 '프로그램과 통신하는 방식'을 A에서 B로 바꿔 보시기 바란다. 응용 프로그램별 세부 보정은 해당 프로그램 외에서는 크게 쓸 일이 없을 것이다.

이로써 날개셋 한글 입력기는 글쇠배열은 말할 것도 없고 한글 입력 오토마타, 낱자 입력 규칙, 한영 전환 글쇠를 포함해 옛한글의 표현 방식에다 이런 응용 프로그램별 보정 방식까지도 customize 가능한 흠좀무한 프로그램이 되었다.

6. 나머지, UI 차원에서 사소하게 개선된 것들

(1) 편집기의 계산기에서 입력된 수식에 오류가 있는 경우, 에러 메시지를 더 구체적으로 표시하게 했다. 그리고 계산 결과를 무조건 10진법, 16진법 또는 상수 명칭 형태로 출력하는 게 아니라, 입력된 상수의 형태를 따라서 유동적으로 출력하는 모드를 추가했다. 100+100은 200이지만 0x100+100은 0x164이고, 'a'+3은 'd'가 되는 식으로 말이다. 이게 기본 상태이다.

사용자 삽입 이미지

사실, 계산기 기능이 아니라 날개셋 제어판 같은 다른 곳에서는 수식을 이렇게 더 자상하게 취급하는 기능이 이미 제공되고 있었는데 계산기로 도입이 다소 늦었다.
그리고 변수에는 언제나 값만 저장되지 대입된 상수의 형태가 저장되지 않는다. 그래서 'a'+1은 'b'라고 출력되지만, A='a'는 출력 방식이 특별히 지정되지 않은 한 그냥 97이라고 출력된다.

(2) 문자표 도구에서 "글꼴이 지원하는 모든 BMP 문자"를 지정했을 때 바탕, 굴림 같은 글꼴에서 공백(U+20) 미만의 제어 문자들이 앞에 표시되지 않게 했다. 그리고 영역 구분을 A 이상 B '미만'으로 해야 하는데 B '이하'로 하는 바람에 쓸데없이 깨진 문자가 하나씩 포함되던 문제를 이제야 발견해서 뒤늦게 해결했다.

(3) 부수로 한자 입력 도구에서 부수 목록은 화면의 확대 배율과 무관하게 언제나 한 줄에 5개씩 표시되게 했다. 150% 배율에서는 폭 계산이 이상하게 돼서 줄당 4개씩 표시되고 여백이 남아서 보기가 무척 안 좋았는데 이를 개선했다.

(4) 제어판의 '시스템 계층'에서 한자 출력용 글꼴을 수동 지정하는 콤보 상자에는.. 사용자의 선택을 돕기 위해 CJK 언어를 지원하는 글꼴들만 목록에 등록돼 표시된다.
그런데 이 목록에는 몇몇 글꼴이 누락되곤 했다. 가령, 한자 출력용으로 손색이 없는 Noto Sans CJK 같은 글꼴은 설치돼 있어도 표시되지 않았다. 정확한 이유는 알 수 없지만 운영체제가 얘를 평범한 트루타입 글꼴로 분류해서 조회해 주지 않았던 것이다.

이 문제를 해결하여 저런 글꼴도 목록에 등재되도록 했다. 다만, 목록 등재 여부를 떠나서 사용자가 이 글꼴 이름을 딴 데서 복사해서 강제로 지정해 주면 지금도 그 글꼴을 지정 자체는 할 수 있다.

(5) 날개셋 한글 입력기는 각종 단축글쇠에서 shift, ctrl, alt, win의 조합을 modifier로 지원한다. 다만, 편집기와 입력 패드 같은 자체 환경 말고 외부 모듈(IME)에서는 운영체제의 동작 특성의 차이로 인해 alt가 사실상 지원되지 않는다. 그래서 외부 모듈에서 단축글쇠 편집 대화상자를 꺼내면 alt를 조절하는 슬라이더는 disabled 상태로 나타났는데...

사용자 삽입 이미지

이번 버전에서는 그에 덧붙여 사용자가 alt를 할당할 경우 이렇게 풍선 도움말로도 추가적인 안내를 하게 했다.
프로그램에 따라서는 alt는 안 되면서 ctrl+alt 조합은 인식되는 경우도 있는데, 이것도 모든 프로그램에서 다 되는 건 아니다. 그러니 일반적으로 alt는 사용할 수 없다고 생각하는 게 속 편하다.

7. 나빌 한글 입력기와 3-18Na 입력 방식

지난 2000년대에는 '새나루'라고 Windows용 오픈소스 한글 IME 프로젝트가 있었다. 얘는 Windows XP 시절을 풍미하면서 활발하게 개발돼 왔지만 개발이 중단되고 2010년대부터는 맥이 끊어졌다.
그런데 바로 올해엔 어느 용자 능력자께서 '나빌'이라는 한글 IME를 개발하여 오픈소스 진영에 기여했고, 두벌식 글쇠배열 기반으로 신세벌식 원리(중성· 종성 중첩)를 적용한 자기 나름의 새로운 한글 입력 방식까지 제안해 놓았다. 컴퓨터 아키텍처 쪽으로 책도 쓴 유명한 분이던데..

내가 저분의 개발 후기를 읽으면서 정말 놀라고 감탄한 것은.. 세벌식 자판부터 시작해서 Windows 프로그래밍과 새로운 TSF 스펙, 예제 코드까지.. 나라면 몇 주 몇 달 이상을 끙끙대며 삽질했을 새로운 지식과 정보들을 단순히 잉여질(?)만으로 그 짧은 시간 만에 몽땅 습득하고 응용해서 새로운 결과물을 뚝딱 내놓았다는 점이다.
난 정말 무식하게 오래 질질 끌고 한 우물만 오래 팠기 때문에 이 정도 경험과 기술이 축적된 거지, 밑바닥부터 시작하면 절대로 저렇게 못 했을 것이다.

인간의 창의성과 지적 능력의 끝이 어디인지를 다시 생각하게 된다. 이번 버전에서는 3-18Na 입력 방식을 내 프로그램의 설정 예제로 구현해서 추가했다.

아이고 글이 또 왜 이리 길어졌나..? 아무튼, 이번 버전도 유용하게 사용하시기 바란다.
홈페이지의 트래픽을 관리하기 위해 64비트 바이너리는 여전히 Google Drive 링크로 제공하고 있다. 하지만 내 홈페이지에도 파일 자체는 올라와 있다. *_x86.msi 대신 *_x64.msi로 말이다.
그나저나 페이스북 의견 페이지가 왜 또 안 뜨고 있나 모르겠다.

Posted by 사무엘

2019/10/27 08:37 2019/10/27 08:37
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1677

난 석유(휘발유, 등유, 경유..)가 아니고 전기도 아니고 뭔가 석유에 준하는 연료인 '가스'에 대해서 그 특성과 기술적인 디테일을 지금까지 잘 모르고 지냈다.
가스라는 건 생각보다 종류가 다양한 물질이며, 종류별로 끓는점에도 차이가 있다. 끓는점에 차이가 있다는 것은 저장하고 활용하는 방법에도 차이가 생긴다는 것을 의미한다.
우리나라 공기업에도 가스 공사와 석유 공사가 괜히 분리돼 있는 게 아니다. 채굴하고 다루고 사업을 하는 방식이 다르기 때문이다.

또한, 영어에서 egg가 계란도 되고 더 보편적인 알도 되듯(저그 럴커 에그..), gas는 보편적인 기체라는 뜻이 있는 한편으로 특별히 가연성 기체 연료 가스라는 뜻도 있고, 심지어 미국 한정으로는 가솔린 휘발유의 준말 역할까지 한다(gas station). 물론, 석유는 상온에서 액체인 반면(끓는점이 수십~수백 도), 가스는 끓는점이 얼마이건 상온과 지표면 대기압 하에서 말 그대로 기체라는 점은 공통이다(끓는점이 -수십 도).

알코올이 에탄올과 메탄올 두 종류로 나뉘는 것처럼, 연료--가열과 동력원 모두--로 쓰이는 가스는 크게 두 종류로 나뉜다. 천연 가스인 LNG, 또는 석유 가스인 LPG. 두 이니셜에서 L은 모두 액화했다는 뜻이다.
LPG는 석유의 범주에 드는 추출물 중에서 그나마 분자량이 작고 제일 낮은 온도에서 기화· 증류되어 나오는 놈인 반면, LNG는 그보다 더 가볍고 석유의 범주를 벗어나는 물질이라는 차이가 있다. 다들 탄화수소 계열의 화합물인 건 동일하지만 말이다.

LNG의 주성분은 흔히 메탄 가스라고 불리는 메테인이며, LPG의 주성분은 프로페인(프로판..)과 뷰테인(부탄)이다. 하지만 뷰테인 같은 물질은 천연 가스와 같이 섞여서 추출되기도 하고 석유 원유에 녹아 있기도 하다. 그러니 출처의 경계가 모호한 구석이 있다.

석유는 장구한 시간 동안 화석화와 탄화까지 거친 뒤에야 생성된 것으로 추정되지만, 메테인 정도는 식물 유기물이 잔뜩 부패할 때도 간단하게 생성된다. 괜히 '천연' 가스라고 불리는 게 아니며, 매장량도 석유보다 훨씬 더, 석탄 급으로 매우 풍부하다고 여겨진다. 우리나라 동해에서 많이 채굴되고 있는 것 역시 이것이다.

사실, 천연 가스는 애초에 유전 근처에서도 많이 채굴된다. 하지만 천연 가스를 따로 수집하고 내보내는 전문적인 시설이 없다면, 얘는 아깝지만 불태워서 없애 버리곤 한다. 가만히 놔두면 불시에 화재· 폭발 사고를 일으켜서 유전을 통째로 날려먹는 골칫거리 지뢰가 되기 때문이다.

LNG와 LPG 중 더 작고 단순한 설비로 인간이 당장 활용하기 더 용이한 것은 LPG이다. LPG가 좀 더 묵직한지라, 액화시켜서 작은 부피로 저장하고 수송하기 더 쉽기 때문이다.
LPG는 공기보다 무겁지만 LNG는 공기보다 가볍다. 그래서인지 단위 분자량당 열량도 LPG가 조금 더 크다.

옛날에는 집집마다 가스레인지에서 사용하는 가스가 LPG였다. 얘는 무겁고 두꺼운 금속으로 만들어진 길쭉한 '가스통'의 형태로 배달하곤 했다. 본인은 어린 시절에 살던 집에서 가스 배달(?)이 오던 것을 본 기억이 있다. 석유를 담는 통이 제리캔이나 드럼통이라면 가스는 저런 통에다가 담았던 셈이다.
또한 휴대용 가스레인지에서 쓰이는 일명 '부탄 가스', 그리고 라이터에 들어있는 액체 연료도 다 LPG 계열의 물질이다.

사용자 삽입 이미지

그랬는데 요즘은 집집마다 가스통을 교환하던 번거로운 관행이 진작에 사라졌으며, 수도관이나 송유관처럼 가스관을 통해 가스 레인지나 가스 보일러에 가스가 손쉽게 공급되고 있다. 이건 도시 차원에서 '도시 가스'라는 명목으로 각 가정에 천연 가스를 연료로 공급하는 인프라가 구축된 덕분에 가능해진 일이다.

생각해 보면 이건 매우 대단한 일이 아닐 수 없다. 하긴, LPG는 가스 레인지에 쓰이고 난방용으로는 안 쓰였던 것 같다. 내 기억이 맞다면 연탄 아니면 등유 기름 보일러를 썼겠지?
참고로 국내에서 제주도는 2019년 현재까지도 내륙과 같은 도시가스 인프라가 없다고 한다. 그래서 LPG 가스통과 기름 보일러가 여전히 현역이다. 하긴, 울릉도 같은 다른 섬도 마찬가지일 것이다.

물론 집집마다 가스관을 구축하고 연결하는 초기 비용은 분명 만만찮았을 것이다. 그러나 이게 일단 이뤄지고 나면 수입에 의존하는 석유 가스 대신, 더 풍부한 천연 가스를 굳이 힘들게 '액화'시키거나 압축할 필요 없이 기체 상태 그대로 손쉽게 공급할 수 있다.
천연 가스는 LPG 가스통 수준의 용기에 담기에는 효율과 경제성이 매우 떨어지며, 가스관이 저렇게 구축됐다면 그 관으로 굳이 석유 가스를 공급할 필요가 없다. 이는 전기 교통수단으로 치면 배터리 대신 전차선이 쫙 깔리는 것과 같다.

또한, 천연 가스가 약간이나마 더 안전한 것은 덤으로 얻는 장점이다. 얘는 누출돼도 공기보다 가벼워서 하늘로 싹 올라가 버리는 반면, 석유 가스는 누출되면 지면에 내려앉아 있기 때문이다. 그렇게 쌓이고 쌓여 있다가 불꽃을 만나면 한꺼번에 펑 폭발해서 대형 사고를 일으키는 것이다. 연탄이 일산화탄소 중독 위험이 있다면 LPG는 이런 식의 누출과 폭발 위험이 있다.

이렇듯, 천연 가스는 액화시켜서 많은 양을 한데 저장하고 수송하는 기술이 개발된 뒤에야 에너지원으로 활용 가능하게 되었음을 알 수 있다. (1) 파이프를 통해 있는 상태 그대로 공급하는 게 제일 좋겠지만, 그 정도 시설까지 구축할 여력이 안 된다면 (2) 온도를 -160도 가까이 낮춰서 액화시킨 LNG 형태로 수송한다(부피 1/600 감소).

선박만 해도 LNG선은 유조선보다 만들기 훨씬 더 까다롭다는 점을 생각해 보자. 탄소가 붙은 천연 가스가 이 정도인데, 하물며 압축이나 액화가 더 어려운 쌩 수소는 연료로서의 실용화가 얼마나 더 난감할지가 같이 상상이 될 것이다. 그을음 없고 해양 오염 걱정도 없는(유조선의 기름 유출 사고..) 깨끗한 에너지원을 개척하는 일은 어떤 형태로든 말처럼 쉬운 일이 아니다. 유전에서 아까운 천연 가스를 그냥 불태워 없애는 것도 그런 이유 때문인 것이다.

위의 (1), (2)보다 소규모 설비로 천연 가스를 꽉꽉 쑤셔넣는 방법은 저온 대신 고압을 미는 것이다. 일명 (3) 압축 천연 가스.. CNG이다. 이건 같은 부피의 탱크에 저장 가능한 가스의 양이 LNG의 1/3 남짓밖에 안 되지만(부피 1/200 감소) 천연 가스를 기술의 힘으로 기존 석유 가스처럼 활용 가능하게 하는 나름 합리적인 tradeoff이다. 얘는 짐작하다시피 교통수단에서 많이 쓰이고 있다.

그럼 이제 가스로 다니는 차량에 대해서 얘기를 해 보자.
가정용 연료에 LPG가 먼저 쓰였던 것과 마찬가지로, 차량용 연료도 LPG가 먼저 쓰였다. LPG 차는 토크가 딸리는지 가속력이 약간 부족한 것 외에는 휘발유 차와 기술적으로는 그다지 다를 게 없다.

하지만 국내에서는 석유 연료를 통한 세수 확보 문제 때문에, LPG 승용차는 택시나 렌터카 같은 영업용 차량 형태로만 허용되었다. 자가용은 장애인이나 국가유공자만이 아무 제약 없이 소유 가능했다. 일반인은 경차, 7인승 이상의 큰 차, 아니면 5년 이상 차령의 중고차라는 괴상한 형태로만 LPG 차를 구경할 수 있었다.

그러던 것이 점점 제약이 완화돼서 올해 4월부터는 일반인도 자유롭게 LPG 차를 굴릴 수 있게 됐다. 자가용 굴리는 서민들에게 석유 차만 강요해서 유류세를 걷는 것보다, 친환경 차를 타게 하는 게 더 중요하다고 나랏님이 판단한 모양이다. 안 그래도 요즘 미세먼지 때문에 이만저만 고달픈 게 아니니 말이다.

참고로 다마스와 라보는 같은 경차 승용차들처럼 연료가 휘발유일까, 아니면 여느 승합차와 트럭처럼 경유일까 문득 궁금했는데.. 어느 것도 아닌 LPG 전용이라고 한다. 휘발유는 돈 한 푼이 궁해서 생계형 경차 상용차를 뽑은 서민에게 어울릴 것 같지 않고, 디젤 엔진은 그 작은 차체에 어울리지 않아 보이는데 결국은 이도 저도 아닌 제3의 선택을 한 셈이다.

LPG 차량은 처음부터 제조사에 의해 LPG 전용으로 나온 것, 아니면 휘발유 차량이 개조되어 휘발유/LPG 겸용이 된 것 이렇게 두 계열로 나뉜다. 겸용의 경우 오지에서 가스 충전소를 못 찾으면 아쉬운 대로 휘발유로 달릴 수 있으니 좋긴 하지만.. 마치 전기 하이브리드 차량처럼 평소에 차가 더 무거워지고, 가스통 때문에 트렁크의 용량이 줄어든다는 단점도 있다.

사용자 삽입 이미지

이렇듯, 가스는 디젤이나 하이브리드처럼 평소에 차를 엄청 많이 굴리는 운전자가 연료비 절감을 위해 고려하는 여러 카드들 중 하나인 것 같다. 초창기의 LPG 엔진은 마치 디젤처럼 추운 겨울에 시동이 잘 안 걸리는 문제가 있었는데, 이것은 LPI라는 직분사 기술이 개발되면서 그럭저럭 해결된 모양이다.

이제 마지막으로 살펴볼 것은 천연 가스 차량이다. LPG 차량은 있어도 LNG 차량은 없다. 천연 가스는 자동차 수준 크기의 설비에서 액화해서 굴릴 수 없기 때문에 현재로서는 CNG 형태밖에 선택의 여지가 없다.
그리고 당연한 말이지만 CNG 엔진과 LPG 엔진은 서로 호환되지 않으며, 충전소도 서로 다르다. 동일한 주유소에서 휘발유와 경유를 같이 팔듯이 동일한 가스 충전소에서 석유 가스와 천연 가스를 같이 제공하는 건 가능하지 않다.

CNG 엔진은 LPG 엔진과는 차원이 다른 신기술로 여겨지며, 국내에서는 시내버스의 형태로 먼저 등장했다. 마치 전국 지하철에 스크린도어가 단기간에 쫙 깔린 것처럼, 우리나라는 전국의 시내버스들이 세계에서 유례를 찾기 힘들 정도로 단기간에 CNG 기반으로 싹 물갈이 됐다.
이건 도시의 대기 오염을 완화하는 데 실제로 매우 큰 기여를 했다. 엔진이 달린 버스 뒷면에서 시커먼 그을음을 볼 일이 없어진 것이 그냥 이뤄진 게 아니다.

버스 말고 소형차 승용차가 처음부터 CNG 형태로 만들어진 건 현재로서는 없다. 안 그래도 LPG 충전소도 부족해서 난리인데 CNG는 뭐.. 버스에서도 CNG가 시내버스 수준에서만 머물고 시외· 고속버스 버전이 없는 이유는 엔진 출력 문제라기보다는.. 충전소 문제, 항속 거리 문제, 그리고 커다란 가스통으로 인한 짐칸 공간 감소 문제가 남아 있기 때문이라고 한다. 앞으로 CNG 차량이 늘어난다면 천연 가스 충전소는 오히려 건물의 기존 도시가스 인프라를 이용해서 구축해야 하지 않을까 싶다.

다만, 기존 승용차를 CNG 겸용으로 개조하는 건 이미 오래 전부터 존재해 왔다. 게다가 이건 진작부터 LPG 같은 일반인 접근성 제약이 없고 누구나 개조 가능했다! 같은 가스차여도 LPG와 CNG는 이렇게 법적· 기술적 계보가 달랐던 셈이다. 하지만 아는 사람이 없으니 CNG 승용차는 그냥 아는 사람만 사용하는 전유물이 돼 왔다.

CNG도 몇 년만 굴리면 개조 비용을 회수하고도 남을 정도로 연료비 하나는 기가 막히게 절약된다고 한다. 다만, CNG는 충전소가 더 부족한데 항속 거리는 LPG보다 더 짧은 것이 분명 큰 단점으로 작용할 것으로 보인다. 잘 생각해 보고 선택해야 한다.

앞으로 수소, 전기 하이브리드 등 자동차의 에너지원은 더욱 다양해지고, 시대의 변화에 맞게 관련 법이나 규제도 바뀌어야 할 것이다.
가스 엔진은 석유 가스건 천연 가스건 압축 착화가 아니라 휘발유 엔진처럼 점화 플러그가 쓰인다고 한다. 얘는 아무래도 경유보다는 근처의 휘발유와 성격이 비슷할 테니 말이다. 그런데 그걸로 디젤의 전담 영역인 커다란 버스까지 굴린다니 대단한 노릇이다.

여담으로..

  • 천연 가스를 수송하는 LNG선에는 원양어선의 생선 냉동 기능을 아득히 초월하는 초강력 초저온 냉동 기능이 필요하며, 천연 가스 기반 엔진도 덩달아 존재한다. 수송하던 LNG가 온도 관리가 안 되어 조금씩 기화해서 부피가 커져 버리고 팽창을 감당을 못 하게 되면, 그걸 엔진으로 보내서 배를 움직이기 위한 연료로라도 써먹게 해야 덜 아깝기 때문이다.
  • 석유는 저런 가스들과 달리 상온에서 액체이지만, 그래도 이런 일반적인 특성과 별개로 '유증기'라는 게 있기 때문에 여전히 취급에 주의해야 한다. 물이 일반적인 기압에서는 100도에서야 끓지만 그래도 일정량은 상온에서도 수증기 형태로 존재해서 공기 중의 습기를 형성하는 것과 비슷한 맥락이다.
  • 그리고 가스를 보충하는 건 주유라고 안 하고 충전(??)이라는 용어가 정착해 있다. 교통카드의 돈도 충전하고 가스도 충전하고... 이때는 한자가 電(전기)이나 錢(돈)이 아니라 塡이다.

Posted by 사무엘

2019/10/24 08:33 2019/10/24 08:33
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1676

남양주의 예빈산과 더불어 본인이 오래 전부터 구상하고 있던 등산 코스는 청계산에서 아직 미개척(?) 지역으로 남아 있는 남쪽 구간이었다. 거기는 상수도 보호 구역은 아니지만, 모종의 이유로 인해 온통 개발 제한 구역이다. 그래서 경치가 좋으며 뭔가 오지 탐험을 한다는 느낌이 난다.

사실 개인적으로는 남양주와 성남 중 어디부터 먼저 갈지도 꽤 진지하게 고민했을 정도였다. 둘 다 마음에 들었기 때문이다. 그랬는데 의식의 흐름에 따라 예빈산을 먼저 가게 됐고, 청계산은 그 다음 주에 찾아갔다.
처음에는 성남시 금토동에 있는 완만한 등산로(능안골)를 생각했다. 그러나 청계산을 갔다가 근처 길 건너편 남쪽의 발화산도 오랜만에 다시 가 보기 위해.. 계획을 변경했다.

남북으로는 청계산과 발화산 사이에, 그리고 동서로는 성남과 의왕 사이에는 외곽순환 고속도로, 그리고 비교적 최근에 생긴 제2경인 고속도로의 연장 구간(안양-성남 고속도로.. 터널로 지나니 밖에서는 보이지 않음), 지방도 57호선이 지난다. 이것들 말고 아마 가장 먼저 처음부터 있었던 것으로 추정되는 길은 '하오개로'라고 불리는 2차로짜리 꼬불꼬불 산길이다. 한국학 중앙 연구원을 지나서 계속 서쪽으로 달리면 자연스럽게 이 길로 진입할 수 있다.

한국학 중앙 연구원은 속세와 기막히게 단절된 곳에 자리잡은 것 같다. 여기서 더 동쪽으로 가면 학교 주변에 들어선 온갖 식당들과, 그리고 서판교의 으리으리한 고급 아파트 단지 때문에 전원적인 느낌은 없어진다.
본인이야 전공이 다르니 딱히 인연이 없지만, 한국학 중앙 연구원은 나름 인문계의 카이스트 같은 급의 국립 특성화 연구소 겸 대학원대학교이다. 학부 과정이 없고 석· 박사 대학원만 있는데, 카이스트도 1970년대에 처음 설립됐을 때는 학부 과정이 없기는 마찬가지였다.

아무튼, 본인은 바로 저 길을 따라 '하오 고개'의 꼭대기에서 등산을 시작했다. 성남과 광주 사이에 이배재 고개가 있다면, 성남과 의왕 사이에는 하오 고개라는 게 있는 셈이다.

사용자 삽입 이미지

한국학 중앙 연구원을 지나서 고개를 오르는 길이다. 단, 담장의 방향을 보면 알 수 있듯, 이건 고개 쪽이 아닌 연구원 쪽을 본 모습이다.

사용자 삽입 이미지

이 길은 곧고 넓게 잘 뚫린 고속도로나 57번 지방도와는 너무 대조되는 좁고 꼬불꼬불한 산길이다. 그 대신 차량 통행이 매우 뜸하며, 종종 갓길 공터가 나오기 때문에 중간에 차를 세우는 것에도 여유가 있었다.

사용자 삽입 이미지

하오 고개의 정상에는 이렇게 발화산과 청계산을 잇는 육교가 설치돼 있다. 이 육교를 통해 보행자는 하오개로와 지방도와 고속도로를 몽땅 횡단하여 두 산을 왕래할 수 있다.
이배재 고개의 정상에도 망덕산과 고불산(+영장산)을 잇는 육교가 존재한다는 공통점이 있다.

사용자 삽입 이미지사용자 삽입 이미지

육교를 올라서 청계산부터 오르기 시작했다. 금토동 등산로보다 수평 이동이 적기 때문에 등산로가 가파를 거라는 각오는 하고 있었다.

길은 좁은 편이지만 성남 누비길 구간이다 보니 울타리로 안내가 잘 돼 있었다. 여기는 안양 시민 묘지의 근처이기도 하기 때문에 무덤도 종종 보였다. 그리고 송전선 철탑과 두 번 마주쳤다.
산은 역시 잎이 초록색일 때 오르는 게 제일 좋은 것 같다.

사용자 삽입 이미지

한참을 오른 끝에 현 산등성이의 능선에 도달했다. 약간 넓은 공터와 의자가 있었는데, 여기서 국사봉으로 가려면 약간 하강해서 산등성이를 옮겨야 했다. 하지만 수직 이동이 막 심한 삽질 수준은 아니었다.

사용자 삽입 이미지

등산로는 이런 좁은 길 아니면 울타리 계단의 순으로 계속되었으며, 정상과 가까워지니까 바위도 슬슬 등장하기 시작했다.

사용자 삽입 이미지

국사봉 정상에 거의 다 오니 갈림길이 있었다. 그 갈림길에서 국사봉이 아닌 쪽의 바위를 오르니 이렇게 자그마한 바위 꼭대기가 나왔다.
여기는 아무 표지석이 없고 바깥 전망도 썩 좋지 않았지만.. 의외로 건너편 발화산의 능선 바깥이 어렴풋이 보였다. 나름 민간 지도에 표시되지 않는 시설의 산 속 잔디밭 부지가 눈에 들어오니 놀랍고 신기했다.

사용자 삽입 이미지

그리고 국사봉 정상에도 도달했다. 여기도 막 썩 경치 좋은 전망대가 있는 건 아니어서 고속도로 말고는 딱히 내려다볼 만한 게 없었다.
성남시 운중동 주변에는 보안 시설이 의외로 좀 있기 때문이다. 괜히 개발 제한 구역인 게 아니다. 아까 그 모종의 바위 꼭대기에서 봤던 것들은 이 정상에서는 전혀 볼 수 없었다.
이로써 본인은 청계산의 망경대, 서울(성남?) 매봉, 과천 매봉, 이수봉에 이어서 국사봉까지 정상을 모두 올라 보게 됐다.

예봉산이야 주변의 예빈산, 운길산, 갑산 따위가 몽땅 깔끔하게 남양주 소속이기 때문에 논란의 여지가 없다. 하지만 청계산은 지역 파편화가 꽤 심한 산에 속한다. 시계에 걸친 산들도 기껏해야 서울-구리(아차산), 성남-광주 같은 둘 정도가 보통인 반면, 청계산은 뭐 각 사분면별로 서울-과천-성남-의왕 4개로 찢어졌으니까..
경부 고속도로가 관할 구간이 달라지고(양재 IC 이남 이북으로 도로 공사 vs 서울시), 지하철의 관할 구간(서울역-청량리 서울 메트로 vs 코레일)이 달라지는 것과 같은 개념이 산에도 존재하는 셈이다.

사용자 삽입 이미지

하산 후에는 운종 저수지 근처의 어느 경치 좋은 카페에서 음료와 전기 보급을 받으며 쉬고 컴퓨터 작업을 했다. 그 뒤, 오후에는 다시 육교로 돌아와서 발화산을 오르기 시작했다.

사용자 삽입 이미지

육교에서는 이렇게 57번 지방도(왼쪽), 하오개로(오른쪽), 그리고 외곽순환 고속도로까지(저 앞쪽.. 청계 톨게이트 근처) 세 도로를 한데 내려다볼 수 있었다. 매우 흥미로운 경치이다.

사용자 삽입 이미지

건너 왔던 육교를 내려다 본 모습이다. 이제는 육교의 저쪽 건너편이 청계산이다.
이 발화산도 성남 누비길 구간이다. 하지만 표지판을 보니 발화산이 아닌 '태봉산' 구간이라고 불리고 있었다. 이 언덕은 사실 발화산 정상의 주봉이 아니며, 발화산 정상은 행정구역상 성남에 있지 않기 때문이다.
누비길은 더 동남쪽으로 응달산을 거쳐서 태봉산 쪽으로 이어진다. 그쪽은 본인이 예전에 가 본 적이 있다.

사용자 삽입 이미지

등산로는 비좁고 가파르며 딱히 볼 것이 없었다. 다 이런 식이었다.

사용자 삽입 이미지

언덕을 다 올라서 능선에 도달하니 드디어 재작년에 봤던 그 송신탑이 나왔다.
재작년에는 여기보다 더 서쪽인 청계 톨게이트 쪽에서 길 없는 곳에 잘못 들어가서 밀림을 헤치면서 온갖 고생을 하다가 어째 이쪽으로 합류했었다.

사용자 삽입 이미지

송신탑을 지나가면 약간의 내리막이 이런 식으로 펼쳐지며.. 길을 따라 더 진행하면 코렁탕 제조 시설, 응달산, 대장동 등으로 도달하게 된다.

사용자 삽입 이미지

차가 하오고개 쪽에 세워져 있기 때문에 한없이 더 진행하지는 않았다. 중간 길목에서 텐트를 치고 밤을 보내고 돌아왔다. 여기는 청계산보다는 덜 유명하고 교통 불편한 곳이다 보니 사람 한 명 얼씬하지 않아서 좋았다.

깜깜한 밤에 높은 산 깊은 숲 속에 혼자 있으면 일면 으스스한 느낌이 들기도 한다. 하지만 그 어디라도 텐트를 치고 안에 들어가면.. 이 얇고 연약한 텐트가 나를 바깥과 격리시켜 주고 추위와 바람과 각종 야생 벌레들을 차단해 준다. 넓은 산 속에 나를 위한 호텔 방이 짠~ 생기는 듯한 느낌?

그냥 돗자리나 침낭만 있을 때와는 차원이 다르다. 이 느낌이 너무 좋아서 이제는 텐트까지 들고 이동하는 수고를 감내하고라도 등산에다 야영을 겸하게 됐다.

Posted by 사무엘

2019/10/21 08:35 2019/10/21 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1675

등산 답사기: 예빈산 견우봉

지난 9월 중순엔 전반적으로 날씨가 너무 좋았다. 이렇게 날이 맑고 단풍도 들기 전에 꼭 등산을 가서 산 정상에서 야영도 하고 말겠다는 다짐을 진작부터 했다. 지난 5월의 이성산 이후로 등산이란 걸 굉장히 오랜만에 다시 해 보게 됐다.

어느 산부터 갈지 고민하다가 남양주 예봉산 옆의 예빈산을 오르기로 마음먹었다. 예봉산은 예전에 두 번이나 가 봤고, 요즘 양 예빈 선수가 우리나라 육상의 에이스로 뜨고 있기도 하니까.. 미리 봐 뒀던 예봉 산장 근처에다 차를 세우고, 팔당 유원지에서부터 등산을 시작했다.

사용자 삽입 이미지

캠핑 장비를 추가로 들고 오르느라 안 그래도 힘든데 이 등산로는 웬걸, 굉장히 가파르고 험했다. 땀이 비 오듯 쏟아지고 온몸이 흠뻑 젖었다.
뭐 그렇다고 서울의 북한산, 관악산처럼 로프를 잡고 바위를 오른다거나 하는 정도는 아니고.. 내려갈 때 스틱이나 주변 나무를 붙잡아야 되는 정도.. 그냥 흙산인 것치고는 가파르다.

그런 데다 최소한의 좁은 길 흔적만 있지 울타리나 이정표 같은 안내 시설이 아무것도 없다시피했다. 종종 등장하는 벤치나 평상도 없고, 정말 일체의 인공물이란 게 없는 자연 그대로의 모습..;;
얼마나 더 올라야 하는지 아무 기약이 없으니 심리적으로 힘든 정도를 더욱 가중시켰다. 온통 숲과 나무에 가려서 경치가 보이는 것도 없었다.

사용자 삽입 이미지

본인은 양 예빈 선수와 달리 저질 체력을 자랑하는 관계로..-_-;; 너무 덥고 숨 차고 힘들어서 몇 번씩 돗자리 깔고 한참을 쉬다 가야 했다. 오르는 동안 1리터에 가까운 음료수를 다 마셔 버렸으며 이걸로도 부족했다. 그래도 나뭇잎들이 아직 싱싱한 초록색이어서 자연의 정취가 살아 있고, 하늘도 맑고 적당히 더우니 이런 날이 등산 자체는 하기 아주 좋은 날이었다.

사용자 삽입 이미지

2시간 가까이 한참을 오르고 또 오른 뒤에야 견우봉 정상에 도착했다! 정상에 있는 것은 이렇게 아주 좁은 공터에다 돌무더기와 간단한 이정표가 전부였다.
예빈산은 주봉이 견우봉과 직녀봉 둘인 것 같았다. 하지만 직녀봉(588m)이 견우봉(581m)보다 미세하게 더 높고, 인터넷 사진으로 본 '예빈산 정상' 표지석도 직녀봉에 있는 듯했다.

사용자 삽입 이미지

어지간해서는 저 앞의 직녀봉도 가 보고 싶었지만 이렇게 그냥 보는 걸로 만족하기로 했다.
체력은 둘째치고 물이 고갈된 관계로.. 산을 한참 내려갔다가 또 오르면서 땀을 빼는 동작을 더 추진할 수 없었기 때문이다. 이 상태로 7미터만 더 오르면 되는 게 아니다.;;

사용자 삽입 이미지

근처 예봉산 정상에 건축된 기상 관측 레이더를 이렇게 멀리서 보게 될 줄이야.. 몇 년째 공사하던 게 드디어 다 완공된 듯했다.

사용자 삽입 이미지

우와~!!
정상 자체에는 별로 볼 게 없었지만 주변을 조금만 살펴보니 팔당호.. 즉 한강과 남한강, 북한강, 경안천, 양평 두물머리와 남양주 다산 유원지가 다 내려다 보이는 경치가 정말 일품이었다. 힘들게 예빈산 견우봉 정상까지 올라간 것에 대한 보상을 이제야 받을 수 있었다. 예봉산에서는 이런 걸 볼 수 없다.

사용자 삽입 이미지사용자 삽입 이미지

이건 각각 두물머리와 다산 유원지 쪽을 바라본 모습이다.

사용자 삽입 이미지사용자 삽입 이미지

이건 검단산 기슭의 배알미 마을 쪽으로 확대한 모습이다. 수돗물 취수? 정수장이 있는 거기 말이다.
경치 좋기로 소문난 남한강과 북한강의 합류 지점을 이렇게 한눈에 볼 수 있다는 것은 예빈산 견우봉의 큰 매력이 아닐 수 없다.

사용자 삽입 이미지사용자 삽입 이미지

이 전망대를 앞두고 바닥이 비교적 평평한 곳이 있어서 거기에다 텐트를 치고 밤을 보냈다.
5시가 넘어가니 슬슬 어두워지고 기온이 내려가기 시작했으며, 7시쯤부터는 주변이 암흑천지가 됐다. 춥고 어둡고 사람이라고는 전혀 없는 산 정상에서 혼자 야영을 하니 아늑하고 황홀하기 그지없었다.
밖은 추워도 텐트와 침낭 안은 따뜻했다. 새벽엔 텐트 안도 꽤 쌀쌀해졌지만 텐트 밖은 바람까지 불고 더 추웠다.

하산은 이튿날 아침 6시쯤부터 시작했다. 해가 완전히 뜨기 전이었지만 어둠이 적당히 걷혀서 앞을 보고 길을 찾을 수는 있었다.
처음에는 추워서 침낭을 점퍼처럼 두른 채 산을 내려갔다. 하지만 이게 웬걸, 길이 험해서 그런지 하산도 생각보다 꽤 길고 힘들었으며, 덕분에 체감상의 추위도 금방 없어졌다. 기온이 20도가 채 되지 않은 이른 아침에도 여전히 더워서 땀을 잔뜩 흘렸다.

내가 어제는 이런 험한 길을 도대체 어떻게 올라왔었나 싶은 생각이 드는 한편으로, 이 길이 정말 맞나 의문도 종종 들었다. 하지만 결과적으로는 길을 전혀 잃지 않았으며, 어제 올랐던 경로를 정확히 역순으로 거쳐서 차를 세워 뒀던 곳으로 잘 하산했다.
그리고 어제 산기슭에서 마주쳤던 계곡에서 세수를 하고 땀을 씻어내고, 물을 받아서 마시기까지 했다. 계곡물이 있으니 정말 좋았으며, 이렇게라도 하니 살 것 같았다.

예빈산에서 이렇게 좋은 추억을 하나 추가한 뒤, 집에는 딱 아침 8시 무렵에 잘 도착했다. 정작 이때는 선선하고 시원했는데 아까 산에 있을 때만 유난히 덥게 느껴졌다.

Posted by 사무엘

2019/10/18 08:34 2019/10/18 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1674

« Previous : 1 : 2 : 3 : 4 : 5 : ... 157 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/11   »
          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

Site Stats

Total hits:
1281176
Today:
363
Yesterday:
501