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

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 사무엘

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

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

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

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

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

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

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

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

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

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

생각해 보면 이건 매우 대단한 일이 아닐 수 없다. 하긴, LPG는 가스 레인지에 쓰이고 난방용으로는 안 쓰였던 것 같다. 내 기억이 맞다면 연탄 아니면 등유 기름 보일러를 썼겠지?
국내에서는 제주도만이 2019년까지 도시가스 인프라가 없어서 LPG 가스통과 기름 보일러가 여전히 현역인 최후의 보루이다가.. 2020년에야 드디어 도시가스가 개통했다고 한다.

물론 집집마다 가스관을 구축하고 연결하는 초기 비용은 분명 만만찮았을 것이다. 그러나 이게 일단 이뤄지고 나면 수입에 의존하는 석유 가스 대신, 더 풍부한 천연 가스를 굳이 힘들게 '액화'시키거나 압축할 필요 없이 기체 상태 그대로 손쉽게 공급할 수 있다.
천연 가스는 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 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

오늘은 지난 추석 때의 고향 풍경을 기록으로 남기고자 한다.
비가 한바탕 내린 뒤부터 전국이 날씨 하나는 참 기막히게 좋았던 것 같다. 낮에 늦더위가 기승을 부리긴 했지만 그래도 기분 좋게 더운 수준이며, 하늘은 아주 맑고 파랬다. 밤에는 기온이 20도 초반까지 내려가면서 환절기 기분이 났다.

1. 황성 공원

경주 시내에는 형산강이라는 강이 세로로 지난다. 강 서쪽에는 동국 대학교 경주 캠퍼스와 김 유신 장군 묘 등이 있고, 시가지는 동쪽에 발달해 있다.
그런데 그 동쪽에는 북천, 혹은 알천이라고 지금은 물이 거의 말라 버린 가느다란 개천도 흐르다가 형산강으로 합류한다. 교차하는 각도는 +라기보다는 X에 더 가깝다만..

이 북천 이남과 이북이 경주에서 구시가지와 신시가지를 얼추 가른다고 볼 수 있는데, 북천 이북으로 형산강 합류 지점 근처의 넓은 공간에는 황성 공원이라는 인공 소나무숲을 비롯해 운동장 경기장, 체육관, 궁도장 등 별별 시설이 다 있다. 인근 주민들의 아침 산책과 운동 코스로 사랑받는 건 두 말할 나위도 없고, 각종 행사나 콘서트, 축제 같은 게 열리기도 딱 좋다.
그야말로 거대한 복합 여가 문화 테마 공간처럼 됐다. 심지어 시립 도서관 내지 주민센터도 이 영역 끝자락에 자리잡아 있다.

황성 공원 자체가 생긴 건 1975년이라고 한다. 여기도 무슨 군부대가 있다가 이전하기라도 한 건지, 신라 시대 유물과 관계가 없는 공원이 어떤 계기로 들어서게 되었나 모르겠다. 자그마한 광명시가 광명 동굴 하나로 유명해졌듯, 황성 공원은 경주시의 명물임이 틀림없다.
이 글에서는 숲길 풍경 사진만 좀 소개하도록 하겠다. 흐리고 어둡고 비가 오기 직전이던 때에 찍어서 분위기가 좀 우중충하다.

공원 안에는 유명 문학인의 시비도 있고, 현충 시설도 여기저기 들어서 있다.

요렇게 생긴 충혼탑이 대표적인 예이고.. 무공 수훈자 전공비라는 것도 있다. 본인은 직접 보지는 못했다
그걸로도 모자랐는지 시립 도서관 근처에는 참전자 명예선양비라는 것까지 있다.

원래 명예선양비는 6· 25 버전만 자그맣게 있었는데, 지난 2017년에는 월남전 버전까지 추가하고 참전용사의 동상까지 만들어서 컨텐츠를 대폭 보강(?)했다. 들고 있는 총이 각각 카빈과 M16으로.. 이런 고증까지 신경 썼다.
이거 뭐 누가 보면 경주가 양구· 인제· 철원 같은 전방 도시인 줄 알겠다.;; 여기는 공산군에게 점령 당한 적도 없는 후방 지역인걸, 시장이 강한 애국 보수 성향인가 하는 생각마저 들었다.

2. 금장대와 암각화, 주변

형산강과 중앙선 철길을 끼고 있는 동국 대학교 캠퍼스 내지 병원의 모습이다. 평소 같으면 그냥 지나쳤을 텐데 날씨가 좋고 경치가 워낙 좋아서 사진을 찍게 됐다.

3. 보문호

유원지와 호텔들이 밀집해 있는 보문 관광 단지도 잘 돌아가고 있었다.

한때는 가뭄이 심해서 보문호가 바닥이 드러나 보일 정도까지 갔지만.. 지금은 다시 물이 출렁거리고 있으니 보기 좋았다.
다 말라 가는 와중에 "수심이 깊어 위험하오니 들어가지 마시오" 표지판이 덩그러니 놓인 모습도 어디선가 봤는데.. 마치 잔뜩 막히고 있는 고속도로에서 멀쩡히 돌아가고 있는 과속 단속 카메라를 보는 듯한 느낌이었다.
말로만 들은 드라켄 익스프레스가 돌아가는 모습을 이렇게 멀리서나마 봤다.

4. 감포 해수욕장

그리고.. 오랜만에 감포 나정 해수욕장에 들러서 바다 바로 코앞에 텐트를 치고 파도와 바닷바람을 즐겼다.

경주는 행정구역만으로 따지자면 엄연히 바다와 접하고 항구와 해수욕장이 있는 도시이다. 하지만 해안이 산으로 가로막혀 있고 대외 이미지가 완전히 내륙 관광 도시이다 보니, 바다의 존재감이 덜 느껴지는 것이다. 경주는 불국사, 석굴암, 보문 관광 단지가 유명하지, 감포 해수욕장이 무슨 해운대나 대천이나 송지호처럼 유명하지는 않다.

한때는 경주 시내에서 감포로 가려면 꼬불꼬불 산길을 타야 했지만 이것도 이젠 옛말이다. 산을 정면 관통하는 토함산 터널을 따라 국도 4호선이 아주 넓고 길고 곧게 잘 뚫렸기 때문이다. (2014년 말)
더 남쪽에는 더 긴 양북1터널도 역시 토함산을 정면 돌파한다. 얘는 더 나중에 생겼으며(2016년) 훨씬 더 길다. 얘는 65번 동해 고속도로 구간이다.

경주의 해수욕장은 경주의 신라 유적지만치 유명하지는 않다. 나정 해수욕장도 위키 같은 데에 항목이 별도로 개설돼 있지도 않을 정도로 인지도가 듣보잡인 것 같다.
그래도 본인이 찾아갔던 당시에는 물은 아주 맑고 깨끗한 상태였다.

여기 감포 해수욕장은 바다와 육지가 접하는 바닥이 모래가 아니라 온통 자갈인 게 특징이다. 본인은 동해· 서해의 타 해수욕장들 중에서 이런 자갈 바닥인 곳을 딱히 접해 보지 못했다.
덕분에 맨발로 다니기는 좀 애로사항이 있지만, 그래도 흙이 덕지덕지 묻지 않아서 깔끔하다는 장점도 있다. 그리고 여기는 동해의 해수욕장치고는 바닥의 경사가 완만한 편이다.

모래도 있긴 하지만 퀄리티가 아무래도 해운대나 대천 같은 전국구 해수욕장에 비할 바는 못 된다.

여름 피서철이 끝나고 해수욕장이 공식적으로는 폐장했지만 바닷가에서 텐트 치고 있는 사람들이 생각보다 많이 보였다. 이런 데서 고기가 잡히기는 하는지 낚시를 하는 사람도 있고, 드물게 물에 들어가는 사람도 있었다.
감포 해수욕장 근처에는 소나무숲과 함께 전문적인 캠핑장도 있는데, 거기도 텐트 친 사람들이 드글드글했다. 바닷가라는 곳을 굳이 한여름에만 가는 곳으로 제한할 필요는 없을 것이다.

그리고 말이 나왔으니 말인데, 본인은.. 폐장한 해수욕장에서 물놀이를 금지시키고 위반 시 과태료까지 물게 하는 건 과도한 규제라고 생각하고 반대한다.
아예 처음부터 수질이나 지형 문제로 인해서 1년 내내 물놀이 금지인 곳이라면 그렇게 해도 된다. 하지만 원래 물놀이가 가능한 곳인데 단순히 기간상으로 해수욕장이 폐장해서 안전요원이 상주하지 않는 거라면, "사고가 나도 100% 들어간 사람 책임. 알아서 하셈"이라는 조건으로 방문객이 전신을 물에 담그는 것 정도는 법을 어기는 일 없이 언제든지 얼마든지 가능해야 한다.

계곡에서도 가능한 물놀이를 바다에서 할 수 없다는 게 말이 되는가? 더구나 바닷물은 계곡물보다 수온이 훨씬 더 높고 따뜻하기 때문에 나 같은 사람은 9월, 심지어 10월 초까지도 한낮에 물놀이가 가능할 정도이다. 그걸 그냥 못 하게 하는 것은 과도한 규제 만능 행정 편의주의로 여겨진다.

Posted by 사무엘

1. 기억의 복원

(1) 옛날에.. A장조에 가사가 아무 내용 없고 애들이 '아에이오우'만 반복하는 좀 이상한?? 노래를 들은 적이 있었다. 모음 삼각도에 입각한 발음 연습용 동요인지? 저건 공교롭게도 라틴 알파벳의 모음 5개에 순서대로 대응하는 소리이기도 하다.

이 정도쯤이야 검색만 하면 출처가 곧바로 나온다. 예민(김 태업)이라는 싱어송라이터의 첫 데뷔작이자 대표작이더라. 발표 시기도 1990년으로 생각보다 오래됐다. 뭔가 '파란 나라'나 '어른들은 몰라요' 같은 느낌의 동요 같다. 들어 보면 알겠지만 주선율에 온통 당김음· 엇박자가 이어지는 게 특징이다.

저렇게.. 사람이 부르는 가사가 있긴 하나 언어적인 의미가 없는 글자 나열에 불과한 노래가 드물게나마 있다. 과거에 MBC 베스트극장 주제가인 "바라밥 바라밥 빠라 바라바라밥.."처럼 말이다.

아카펠라야 든든든 두두두 팝팝 팅팅~ 유후 같은 말소리로 악기 비트를 흉내 내는 게 일종의 테크닉인데.. 악기 반주가 따로 있으면서 가사도 의성어인 건? 바라바라밥 말고 나나나 라라라도 있고.. 이것도 몇 가지 패턴이 있는 것 같다. 아~ '담다디 담다디 담다디 담'도 있었다! ㅋㅋㅋ 사람들이 이런 데서도 참신함을 느끼기 때문에 옛날에 뚫훍쏭 같은 외국곡도 인기를 끌었던 것이지 싶다..

예민 저분은 아에이오우 이후에도 자연이 어떻고 하면서 성인용 동요 풍의 노래를 계속해서 작곡하며 지내 온 듯하다.

(2) 그리고 또 옛날에.. C장조 3박자 계열이고 어떤 남자가 꽤 느끼한 목소리로 "oh my love... for/fall" 이런 가사 정도를 부른 영화 주제가 같은 노래가 있었다.
오디오 CD라든가 비디오 테이프에서 깔끔한 음질을 홍보할 때 샘플로 이 노래가 꼭 나왔던 것 같다.

제대로 기억하고 있는 가사가 매우 소수여서 찾기 어려울 것으로 우려되었으나.. 우리의 구글신은 그것만으로도 사람의 마음을 읽어냈다. 무슨 '우아한 형제들'도 아니고 '의로운 형제들' Righteous brothers라는 그룹에서 부른 Unchained melody였다..;; 이건 1965년작으로 내 생각보다도 굉장히 오래됐다..

(3) Dolly Parton의 Nine to Five.
나 초딩 시절 진~~짜 왕창 옛날에 '모나리자'라고 웬 화장지 상표가 있었다.
티슈형 화장지 CF에서 배경음악으로 들었던 게 기억으로 남고 나서 그 뒤로 수십 년 동안 한 번도 접할 일이 없었는데... 최근에 우연히 곡의 정확한 출처를 알게 됐다.

1980년대 어느 미드의 주제곡이었던 듯??
"빰빰빰빰 빰빰빰빰" 이렇게 시작하는 리듬이 강렬해서 장기 기억에 금방 각인된 것 같다.

리스닝이 전혀 안 되다 보니 가사 내용은 알 길이 없었는데..
그냥 전형적인 커리어우먼 직딩의 일상을 노래한 가사이구나.
Gb (또는 F#) 장조에 속하는 곡이 하나 더 추가됐다.

옛날에 "곰을 잡으러 갑시다 좋아 좋아서 / 땡큐" 이건 모나리자 상표의 두루마리 화장지 CF였다.;;
"찾아보자 스모프, 숲 속으로 들판으로, 날아보자 스모프, 맛있는 양념통닭"이랑 비슷한 타이밍이 아니었나 싶다.

2. 노래로 듣는 아프리카 언어

라이온 킹 맨 처음 시작할 때 나오는.. "나~주평야! 발발이 치와와..."라고 무슨 판소리 같은 도입부 말이다.
이건 무의미한 음향효과 성대모사가 아니라, 인간의 언어였구나.. 2019년에 "처음"으로 알게 됐다. 아이고~~ ㅋㅋㅋㅋㅋㅋ

아프리카어의 양대 산맥인 스와힐리어 다음으로.. '줄루' 어라고 한다.
저 노래에서는 "잉오야마 ..." 어쩌구 저쩌구가 굉장히 자주 반복되는데.. '잉오야마' 이게.. 사자라는 뜻이랜다.
주인공의 이름인 '심바'는 스와힐리어로 '사자'이니.. 라이온 킹은 두 언어를 골고루 사용한 셈이다.

아빠라고 말하는 부분 부근이 '치와와'처럼 들렸구나. -_-;;
진짜.. 별것 아닌 내용이고 "새가 날아든다, 왠갖 잡새가 날아든다" 새타령 대신 아프리카 버전으로 사자타령이나 마찬가지인데
모르고 들을 때와 25년 만에 알고 들을 때의 느낌 차이가 장난이 아니다...!! ㅋㅋㅋ

(1) 옛날에 최 덕신의 CCM 앨범 <갈망>(1998)의 1번 트랙 "오 놀라워라"가... 라이온 킹 같은 시도를 했는지.. 시작과 끝에 "니아자부 사나~~ 뭄부 무움바~~" 하이튼 뜻은 기억 안 나는 스와힐리어 챈트를 넣은 적이 있었다. 하지만 느낌이 좀 어설펐다.

(2) 1997년, 남아공 케이프타운에서 열렸던 국제 정보 올림피아드에서는 첫째 날 3번 문제가.. 독충 '이숑고로로'의 움직임을 소재로 집어넣은 내용이었는데.. 저것도 줄루 어로 노래기 벌레라는 뜻이라고 한다. 사자나 독충이나 다 i 모음으로 시작한다는 공통점이 있네.. 진짜 그런 뜻인지는 모르겠다.

(3) 한편, 이집트의 왕자 When you believe 중간에 나오던 어린애들 코러스는.. 히브리어였다. "아쉬라 알 아도나이 어쩌구" (주께 노래하리라) 이런다. 이집트에서 이제 막 해방되어 빠져나가는 장면이지만 가사 모티브는 홍해까지 건넌 뒤에 부른 노래를 바탕으로 하고 있다.
얘들이 사자음어를 눈으로만 보고, 읽기는 다 그냥 '주'라고 읽었다는 걸 알 수 있다.

3. 큰 악기

집도 큰 거, 차도 큰 거, 총도 큰 것... 같은 논리로 악기도 큰 것에 갑자기 마음이 끌린다.
채로 켜는 현악기 중에서 제일 큰놈은 더블베이스 또는 콘트라베이스라고 불리는 물건이다. 바이올린처럼 들고 목에 얹을 수 없으며 그냥 아래에다 받쳐 놓고 켜야 한다. 그 크기와 이름에 걸맞게 음역은 매우 낮다.

한편, 금관악기 중에서 제일 큰놈은 튜바의 파생형인 '수자폰'이다. 관이 무슨 나팔꽃처럼 연주자의 몸통을 둥글게 감싸 올라가며 나팔 부위가 머리 위로 커다랗게 돌출돼 있다. 간지가 난다.

수자폰은 선 채로, 심지어 실외에서 걸으면서도 불기 편한 형태로 고안되었기 때문에 아주 군대 친화적이다. 이 악기를 발명한 존 필립 수자는 미군에서 오늘날까지 불리는 행진곡들의 상당수를 태반을 작곡한 사람이기도 하다.
그래서 수자폰은 군악대에서 엄청 많이 볼 수 있으며, 반대로 연주자에게 의자가 다 구비돼 있는 실내 오케스트라에서는 볼 일이 없다.

공교롭게도 이렇게 큼직한 두 악기만 갖고 공연을 하는 2인조 악사가 외국에 있다. 검색을 통해 우연히 알게 됐다. 위의 사진도 거기 공식 홈페이지에서 가져온 것이다. (☞ 링크)

4. 찬양곡 중에 비슷한 곡들

"하나님 아버지 주신 책은"과 "달고 오묘한 그 말씀"은 가사의 주제(성경)와 멜로디 구성(6/8박자 G장조), 분위기가 굉장히 비슷하다. 이어서 부르기 좋기 때문에 우리 교회에서 청년부 특송 때 말씀 찬송 메들리로 써먹기도 했다.
아니나다를까 이 두 곡은 Philip P. Bliss이라는 동일 인물이 1870년대의 비슷한 시기에 작사· 작곡한 찬송가이다.

"그를 향하여 우리의 가진 바"와 "사람을 보며 세상을 볼 땐 만족함이 없었네"는 왠지 좀 비슷하게 흥겨운 느낌이 나고 동일 한국인의 곡 같은 생각이 들었는데.. 그 감이 맞다.
작곡자는 지금도 김천에 개원해 있는 정신과 의사 겸 교회 장로이다(최 영택).

최근에는 "하나님이시여 나의 모든 죄를"(시 51)이라는 곡을 접해서 처음으로 들어 봤는데..
한 박 쉬고 시작하는 것, 전반적인 박자라든가 뒷부분에 조옮김이 일어나는 구성이 "나의 영혼이 잠잠히"와 비슷하게 들렸다.
둘 다 이 유정 작곡이다. 좋은 씨앗이라는 CCM 밴드를 만들어서 음반을 냈고 지금은 목사까지 된 분이다. "아침에 주의 인자하심을.." 그 찬양을 작곡하기도 했다.

한 사람이 여러 곡을 작곡하다 보면 결국은 비슷한 스타일이 묻어 나기는 하는 것 같다. 난 그 정도로 작곡을 한 경험도, 그럴 능력도 없어서 잘 모르겠다만..

Posted by 사무엘

1. 스마트 포인터의 필요성

C/C++에서 포인터로 참조하는 동적 메모리가 안전하게 관리되기 위해서는.. 가장 간단하게는 포인터의 생명 주기와 그 포인터가 가리키는 메모리 실체의 생명 주기가 동일하게 유지돼야 할 것이다. 어느 한쪽이 소멸되면 다른 쪽도 소멸돼야 한다. C++에서는 이 정도 절차는 포인터를 클래스로 감싸고 그 클래스의 생성자와 소멸자 함수를 구현함으로써 자동화할 수 있다.

하지만 이것만으로 문제가 다 해결되는 건 아니다. 어떤 메모리에 대한 포인터의 ownership이 더 깔끔하게 관리되고 통제돼야 한다. 멀쩡한 주소값이 딴 걸로 바뀌어서 원래 가리키던 메모리로 접근 불가능해지거나(leak..), 이미 해제된 메모리를 계속 가리키고 있다가 사고가 나는 일도 없어야 한다.

그런 일을 예방하려면 여러 포인터가 동일 메모리를 참조하는 것을 완전히 금지하고 막든가, 아니면 reference count 같은 걸 따로 둬서 그런 상황에 대비를 해야 한다. 실행시켰을 때 뻑이 날 만한 짓은 아예 컴파일이 되지 않고 거부되게 해야 한다.
이런 메모리 관리를 자동으로 해 주는 클래스가 표준 C++ 라이브러리에도 물론 구현돼 있으며, 크게 두 가지 관점에서 존재한다.

• 배열 지향: POD 또는 비교적 단순한 오브젝트들의 동적 배열로, 원소들의 순회, 추가· 삭제와 전체 버퍼 재할당 같은 동작에 최적화돼 있다. 원소 전체 개수와 메모리 할당량 정보가 별도로 들어 있으며, 문자열 클래스도 어찌 보면 배열의 특수한 형태라고 간주할 수 있다. [] 연산자가 오버로딩 돼 있다.
• 오브젝트 지향: 단일 오브젝트 중심으로 메모리 할당 크기보다는 소유자(ownership) 관리에 더 최적화돼 있다. 그래서 구현 방식에 따라서는 원소 개수 대신 레퍼런스 카운트 정보가 있곤 한다. 담고 있는 타입 형태로 곧장 활용 가능하게 하기 위해, ->와 * 같은 연산자가 반드시 오버로딩 돼 있다.

C/C++은 배열과 포인터의 구분이 애매하니 helper class는 각 분야에 특화된 형태로 따로 구현되었다는 것을 알 수 있다.
배열 버전이야 std::vector라는 유명한 클래스가 있고, 오브젝트를 담당하는 물건을 우리는 smart pointer라는 이름으로 오랫동안 불러 왔다.

Windows 진영에서도 ATL 내지 WTL 라이브러리에는 일반 포인터뿐만 아니라 COM 인터페이스를 감싸서 소멸자에서 Release를 해 주고, 대입 연산자 및 복사 생성자에서 AddRef 따위 처리를 해 주는 간단한 클래스가 물론 있었다.
소멸자는 예외 처리가 섞여 있을 때 더욱 빛을 발한다. 함수의 실행이 종료되는 경로가 여럿 존재하게 됐을 때 goto문을 안 쓰고도 메모리 단속이 꼼꼼하게 되는 것을 언어와 컴파일러 차원에서 보장해 주기 때문이다. 그리고 이 정도 물건은 C++ 좀 다루는 프로그래머라면 아무라도 생각해 내고 구현할 수 있다.

2. 초창기에 도입됐던 auto_ptr과 그 한계

C++은 이런 스마트 포인터도 표준화하려 했으며, 그 결과로 auto_ptr이라는 클래스가 C++98 때부터 도입됐다. 선언된 헤더는 #include <memory>이다.
그러나 auto_ptr는 오늘날의 최신 C++의 관점에서 봤을 때는 썩 좋지 못한 설계 형태로 인해 deprecate됐다. 이미 이걸 사용해서 작성돼 버린 레거시 코드를 실행하는 것 외의 용도로는 사용이 더 권장되거나 지원되지 않게 되었다.

그 대신, C++11부터는 용도를 세분화한 unique_ptr, shared_ptr, weak_ptr이라는 대체제가 등장했다. 이거 마치 C-style cast와 C++ *_cast 4종류 형변환의 관계처럼 보이지 않는가? =_=;;

auto_ptr은 한 메모리를 오직 한 포인터만이 참조하도록 하고 포인터가 사라질 때 소멸자도 호출해 주는 최소한의 기본 조치는 잘 해 줬었다. auto_ptr<T> ptr(new T(arg1, ...)) 같은 꼴로 선언해서 사용하면 됐다. 하지만...

(1) 단일 포인터와 배열의 구분이 없었다.
물론 스마트 포인터는 전문적인 배열 컨테이너 클래스와는 용도가 다르니, 원소의 삽입· 삭제나 원소 개수 관리, 메모리 재할당 처리까지 할 필요는 없다.

하지만 클래스의 소멸자에서 호출해 주는 clean-up을 별도의 템플릿 인자로 추상화하지는 않았고 그냥 delete ptr로 고정해 놓았기 때문에.. 당장 delete와 delete[]조차도 구분할 수 없어서 번거로웠다. 다시 말해 auto_ptr<T> ptr(new T[100]) 이런 식으로 써먹을 수는 없다.

(2) 포인터의 ownership을 관리하는 것까지는 좋으나.. 그게 복사 생성자 내지 대입 연산자에서 우항 피연산자를 변조하는 꽤 기괴한 형태로 구현돼 있었다.
무슨 말이냐 하면.. auto_ptr<T> a(ptr), b에서 b=a 또는 b(a)라고 써 주면.. b는 a가 가리키는 값으로 바뀜과 동시에 a가 가리키는 값은 NULL로 바뀌었다. 즉, 포인터와 메모리의 일대일 관계를 유지시키기 위해, 소유권은 언제나 복사되는 게 아니라 이동되게 한 것이다.

그렇게 구현한 심정은 이해가 되지만, 대입 연산에서 A=B라고 하면 A만 변경되어야지, B가 바뀌는 건 좀 납득이 어렵다.
복사 생성자라는 것도 형태가 T::T(const T&)이지, T::T(T&)는 아니다. 차라리 임시 객체만 받는 R-value 이동 전용 생성자라면 T::T(T&&)이어서 우항의 변조가 허용되지만, 복사 생성자는 그런 용도가 아니다.

(3) 위와 같은 특성이랄지 문제로 인해.. auto_ptr은 call-by-value 형태로 함수의 인자나 리턴값으로 그대로 전달했다간 큰일 났다.
메모리의 소유권이 호출된 함수의 인자로 완전히 옮겨져 버리고, 그 함수가 끝날 때 그 메모리는 auto_ptr의 소멸자에 의해 해제돼 버리기 때문이다. 이 문제를 컴파일러 차원에서 잡아낼 수 없다. (뭐, 이미 free된 메모리를 이중으로 해제시키는 사고는 나지 않는다. 깔끔한 null pointer 접근 에러가 날 뿐.)

auto_ptr을 함수 인자로 전달하려면 그냥 call-by-reference로 하든가, 아니면 그 원래의 T* raw 포인터 형태로 전해야 했다.
아니, 함수 인자뿐만 아니라 값을 그대로 함수의 리턴값으로 전할 때, 혹은 vector 및 list 같은 컨테이너에다 집어넣을 때 등.. 임시 객체가 발생할 만한 모든 상황에서 동일한 문제가 발생하게 된다.

이게 제일 치명적이고 심각한 문제이다. 여러 함수를 드나들고 컨테이너에다 집어넣는 것도 raw pointer와 다를 바 없이 가볍게 되라고 smart pointer를 만들었는데 그러지 못한다면.. 이걸 만든 의미가 없다. 그러면 한 함수 안에서 달랑 소멸자 호출만 자동화해 주는 것 말고는 쓸모가 없다.
또한, 매번 call-by-reference로 전하는 건 엄밀히 말해 포인터의 포인터.. 즉, 포인터를 정수가 아니라 구조체 같은 덩치 큰 물건으로 취급하는 거나 마찬가지이고..

이런 이유로 인해 auto_ptr은 좋은 취지로 도입됐음에도 불구하고, 현재는 이런 게 있었다는 것만 알고 최신 C++에서는 잊어버려야 할 물건이 됐다.
(1) C 라이브러리 함수라든가(gets...) (2) C++ 키워드뿐만 아니라(export) (3) C++ 라이브러리 클래스 중에서도 흑역사가 생긴 셈이다.

auto_ptr이 무슨 보안상의 결함이 있다거나 성능 오버헤드가 크다거나 한 건 아니다. 21세기 이전에는 C++에 R-value 참조자 같은 문법이 없었으니 복사 생성자에다가 move 기능을 집어넣을 수밖에 없었다. 나중에 C++에 언어 차원에서 smart pointer의 불편을 해소해 주는 기능이 추가된 뒤에도 이미 만들어진 클래스의 문법이나 동작을 변경할 수는 없으니 새 클래스를 따로 만들게 된 것일 뿐이다.

3. unique_ptr

auto_ptr의 가장 직접적인 대체제는 unique_ptr이다.
얘는 최신 C++에서 새로 추가된 문법을 활용하여 단일 개체와 배열 개체를 구분할 수 있다. unique_ptr<T>와 unique_ptr<T []>로 말이다. 신기하다..;;
그리고 템플릿 가변 인자 문법을 이용하여 new를 생략하고 std::make_unique<T>(arg1, arg2..) 이렇게 객체를 생성할 수도 있다. 얘는 C++14에서야 도입된 더 새로운 물건이다.

unique_ptr은.. 말 많고 탈 많던 복사 생성자와 대입 연산자가 막혀 있다. 함수에 날것 형태로 전달하거나 컨테이너에 집어넣는 등의 시도를 하면.. 그냥 컴파일 에러가 나게 된다. 그래서 안전하다.
이전의 auto_ptr이 하던 것처럼 소유권을 옮기는 것은 R-value 이동 생성자라든가 std::move 같은 다른 방법으로 하면 된다.

어떤 클래스에 대해서 복사 생성자와 대입 연산자가 구현돼 있지 않으면 컴파일러가 디폴트, trivial 구현을 자동 생성하는 편이다. 각 멤버들에 대한 memcpy 신공 내지 대입 연산자 호출처럼 해야 할 일이 비교적 직관적으로 뻔히 유추 가능하기 때문이다. 하지만 클래스에 따라서는 그런 오지랖이나 유도리가 바람직하지 않으며 이를 금지해야 할 때가 있다. 인스턴스가 단 하나만 존재해야 하는 singleton 클래스, 또는 저렇게 반드시 1핸들, 1리소스 원칙을 유지해야 하는 클래스를 구현할 때 말이다.

그걸 금지하는 가장 전형적이고 전통적인 테크닉은 해당 함수를 private으로 선언해 버리는 것이 있다. (정의는 당연히 하지 말고)
하지만 이것도 friend 함수에서는 안 통하는 한계가 있기 때문에 최신 C++에서는 액세스 등급과 별개로 상속 받았거나 디폴트 구현된 멤버 함수의 사용을 그냥 무조건적으로 금지해 버리는.. = delete라는 문법이 추가되었다. 순수 가상 함수를 나타내는 = 0처럼 말이다! unique_ptr은 이 문법을 사용하고 있다.

그럼 unique_ptr은 컨테이너에 집어넣는 게 전혀 불가능한가 하면.. 그렇지 않다.

vector<unique_ptr<T> > lc;
lc.push_back( unique_ptr<T>(new T) );

처럼 push_back이나 insert에다가 T에 속하는 변수를 줄 게 아니라 저렇게 애초부터 R-value 임시 객체를 주면 된다.
그러면 임시 객체의 ownership이 컨테이너 안으로 자연스럽게 옮겨지고, 컨테이너 안의 unique_ptr만이 유일하게 T를 가리키고 있게 된다.

얘는 auto_ptr보다 상황이 훨씬 더 나아졌고 이제 좀 쓸 만한 smart pointer가 된 것 같다.
사실, 작명 센스조차도.. auto는 도대체 뭘 자동으로 처리해 준다는 건지 좀 막연한 구석이 있었다. 그게 unique/shared로 바뀐 것은 마치 '인공지능'이라는 막연한 용어가 AI 암흑기를 거친 후에 분야별로 더 구체적인 기계학습/패턴인식 같은 말로 바뀐 것과 비슷하게 들리기도 한다. ㅎㅎ

4. shared_ptr와 weak_ptr

그럼 다음으로, shared_ptr을 살펴보자.
얘는 마치 COM의 IUnknown 인터페이스처럼 reference counting을 통해 다수의 포인터가 한 메모리를 참조하는 것에 대한 대비가 돼 있다. 그래서 unique_ptr과 달리, 대입이나 복사를 자유롭게 할 수 있다.

(1) 날포인터는 그냥 대책 없이 허용하기 때문에 ownership 문제가 발생하고.. 아까 (2) auto_ptr은 무조건 ownership을 옮겨 버리고, (3) unique_ptr은 깔끔하게 금지하는데 (4) 얘는 참조 횟수를 관리하면서 허용한다는 차이가 있다. 소멸자는 가리키는 놈의 reference count를 1 감소시켜서 그게 0이 됐을 때만 실제로 메모리를 해제한다.

그래서 shared_ptr은 크기 오버헤드가 좀 있다.
unique_ptr은 일반 포인터 하나와 동일한 크기이고 기술적으로 machine word 하나와 다를 바 없는 반면, shared_ptr은 reference count 데이터를 가리키는 포인터를 추가로 갖고 있다. 일반 포인터 두 개 크기를 차지한다.

이는 static_cast보다 dynamic_cast가 오버헤드가 더 큰 것과 비슷한 모습 같다. 그리고 멤버 포인터가 다중 상속 하에서의 this 오프셋 보정 때문에 추가 정보를 갖고 있다면, 얘는 ownership 관리 때문에 추가 정보를 갖고 있다는 점이 비교된다.

끝으로, weak_ptr이라고, shared_ptr와 같이 쓰이는 포인터도 있다. 얘는 이름에서 유추할 수 있듯이 reference count를 건드리지 않는다. 순환 참조 문제를 예방하려면 A에서 B를 참조한 뒤에 B에서 또 A를 참조할 때는 레퍼런스 카운트를 건드리지 않아야 하기 때문이다.
순환 참조는 단순히 A→B→A뿐만 아니라 A→B→C→A 같은 더 복잡한 형태로도 발생하며, 일단 발생한 것을 감지하기란 몹시 난감하다. 그러니 weak_ptr이라는 개념이 반드시 필요하다.

그럼 reference count를 건드리지 않고 shared_ptr에 접근하려면 그냥 raw 날포인터를 얻어서 간단히 써도 될 텐데 굳이 weak_ptr이 따로 존재하는 이유는? 비록 ref count를 건드리지 않더라도 날포인터보다는 더 안전한 놈이 필요하기 때문이다.

weak_ptr은 다른 shared_ptr을 가리킬 수 있다.
shared_ptr은 자신과 동일한 shared_ptr로부터 참조받은 횟수와, weak_ptr로부터 참조받은 횟수를 따로 관리한다. 그렇기 때문에 shared_ptr은 이렇게 2개의 숫자로 이뤄진 레퍼런스 데이터도 따로 동적 생성해서 포인터로 가리키면서 동작한다.

weak_ptr이 가리키는 객체에 실제로 접근하려면 weak_ptr::lock()을 호출해서 weak로부터 shared_ptr을 잠시 생성해야 한다. 이 동안은 shared_ptr의 실제 레퍼런스 카운트가 증가하기 때문에 한쪽의 스마트포인터가 소멸되더라도 dangling pointer 현상이 발생하지 않는다. 이게 weak_ptr이 날포인터와의 차이점이다.

하지만 이 lock이 언제나 성공하지는 않을 수 있다. lock이 걸리지 않았을 때 weak가 shared를 가리키고 있는 건 shared의 실제 참조 횟수에 아무 영향을 끼치지 않는다. 그렇기 때문에 이 동안은 shared가 가리키는 객체는 순환 참조 없이 소멸이 가능하다.

그럼 weak_ptr 따위 안 쓰고, 그냥 shared_ptr를 놔두고 평소엔 null을 저장했다가 lock을 걸 상황에만 원래 포인터 값을 참조하는 것과 무슨 차이가 있느냐는 의문이 생길 수 있는데.. weak_*는 그것보다 더 안전하다. 자신이 가리키는 객체가 소멸되었는지의 여부를 expired() 함수로 간편하게 알 수 있다. 레퍼런스 카운트를 이중으로 관리하고 메모리도 이중으로 관리하는 성능 오버헤드를 괜히 감수한 게 아니다.

weak_ptr은 shared_*와 마찬가지로 크기가 포인터 2개이다. 단, 사용법이 unique_*나 shared_*와는 좀 다르다.
저 둘은 ->나 * 연산자를 이용해서 자신이 가리키는 객체에 바로 접근할 수 있는 반면, weak_*는 그렇지 않다. 그리고 실제 객체를 생성하는 make_unique와 make_shared 함수는 있는 반면, make_weak는 없다. weak_*는 그 정의상 기존 shared_*로부터 유도되어 생성되는 걸 가정하기 때문이다.

이상이다. 그냥 생성자와 소멸자를 적절히 구현해 주고 ->와 *만 오버로딩 해 주면 끝일 것 같은 smart pointer도 깊게 들어가면 내막이 생각보다 더 복잡하다는 것을 알 수 있다.
Rust 언어는 garbage collector 기반이 아니면서 더 독특한 방식으로 메모리 소유권을 관리한다던데 그 내막이 어떠했던지가 다시 궁금해진다.

5. 여담

(1) = delete는 다시 봐도 참신하기 그지없다. delete라는 키워드가 연산자 말고 이런 용도로도 활용되는 날이 오더니!
배열 첨자 연산자이던 []와 구조체 참조 연산자이던 ->가 람다 선언에서 의미가 완전히 확장된 것만큼이나 참신하다.
하긴, 옛날에 템플릿이 처음 등장했을 때.. 그저 비교 연산자일 뿐이었던 <와 >가 완전히 새로운 여닫는 형태로 사용되기 시작한 것도 정말 충격적인 변화였을 것이다.

(2) 글쎄, 멤버 함수의 접근을 금지하는 방법이 저렇게 도입됐는데, 어떤 클래스에 대해서 Java의 final이나 C#의 sealed처럼 상속이 더 되지 않게 하는 옵션은 C++에 도입되지 않으려나 모르겠다. C++은 타 언어에 없는 protected, private 상속이 존재하지만 상속 자체를 금지하는 옵션은 없어서 말이다.

특히 내부 구조가 아주 간단하고 가상 함수가 존재하지 않는 것, 특히 소멸자가 가상 함수 형태로 별도로 선언되지 않은 클래스는 상속을 해도 어차피 polymorphism을 제대로 살릴 수 없다. 그냥 단순 기능 확장에만 의미를 둬야 할 것이다.
Java는 모든 함수가 기본적으로 가상 함수일 정도로 유연한데도 이와 별개로 상속을 금지하는 옵션이 있는데.. 그보다 더 경직된 언어인 C++은 의외로 그런 기능이 없다.

(3) C/C++의 사고방식에 익숙한 프로그래머라면 포인터란 곧 메모리 주소이고, 본질적으로 machine word와 동일한 크기의 부호 없는 정수 하나일 뿐이라는 편견 아닌 편견을 갖고 있다.
하지만 객체지향이라든가 함수형 등 프로그래밍 언어 이론을 조금이라도 제대로 구현하려면 숫자 하나만으로 모든 것을 표현하기엔 부족한 포인터가 얼마든지 등장하게 된다.

앞서 다뤘던 shared_ptr이라든가 다중 상속을 지원하는 멤버 함수 포인터..
그리고 자기를 감싸는 문맥 정보가 담긴 클래스 객체 포인터라든가 람다 함수 포인터 말이다.
C++은 전자를 기본 지원하지 않기 때문에 모든 클래스들이 Java 용어로 치면 개념적으로 static class인 거나 마찬가지이다.
그리고 후자를 기본 지원하지 않기 때문에 람다는 캡처가 없는 놈만 기존 함수 포인터에다 담을 수 있다.

그런 것들이 내부적으로 어떻게 구현되고 구현하는 시공간 비용이 어찌 되는지를 프로그래머라면 한 번쯤 생각할 필요가 있어 보인다.

(4) C++에서 class T; struct V; 처럼 이름만 전방 선언된 incomplete type에 대해서는 제일 단순한 직통 포인터, 그리고 무리수가 좀 들어간 멤버 포인터 정도만 선언할 수 있다. T나 V의 실체를 모르니 이런 타입의 개체를 생성하거나, 포인터를 실제로 참조해서 뭔가를 할 수는 없다.
그런데 이런 불완전한 타입을 가리키는 포인터를 상대로 delete는 가능할까? 난 이런 상황에 대해 지금까지 한 번도 생각해 본 적이 없었다.

sizeof(T)의 값을 모르더라도 포인터가 가리키는 heap 메모리 블록을 free하는 것은 얼마든지 가능하다. 애초에 malloc/void가 취급하는 것도 아무런 타입 정보가 없는 void*이니 말이다.
그러니 operator delete(ptr)은 할 수 있지만, 해당 타입에 대한 소멸자 함수는 호출되지 못한다.

컴파일러는 이런 코드에 대해서 경고를 띄우는 편이다. Visual C++의 경우 C4510이며, delete뿐만 아니라 delete[]에 대해서도 동일한 정책이 적용된다.

Posted by 사무엘

1. 기술 디테일

자동차가 자그마한 승용차 급이다가 대형 버스나 트럭 내지 그 이상으로 커지면 내부 구조가 다음과 같이 바뀐다.

(1) 엔진
휘발유 기반이다가 디젤로 바뀐다. 디젤 엔진은 휘발유 엔진보다 더 복잡하고 무겁고 비싸지만 저속 토크가 더 강하며, 실린더의 개당 부피에 제약이 없어서 엔진의 대형화에 근본적으로 유리하기 때문이다.
가령, 4기통만으로 4000cc에 달하는 엔진은 디젤로는 구현 가능하지만 휘발유로는 가능하지 않다. 이런 차이는 양 엔진의 점화 방식의 차이 때문에 존재한다(점화 플러그 vs 압축 착화).

물론 디젤 엔진 정도야 대형차 전용인 건 아니며 소형 승용차에도 쓰인다. 하지만 반대로 휘발유 엔진이 대형차에서 쓰이는 일은 없다. 휘발유 엔진의 GDI와 디젤 엔진의 CRDI는 둘 다 direct injection으로 끝나는데 각각 자기 분야에서 무엇을 크게 개선한 기술인지 궁금해진다.

참고로, 자동차 말고 타 교통수단들도 작은 놈은 자동차 같은 왕복 피스톤 엔진을 사용한다. 그러다가 덩치가 더 커지면 철도 차량은 아예 전기 모터로 갈아타고 비행기는 제트 엔진을 장착하게 된다.

(2) 브레이크
승용차 수준에서는 방열 성능과 정비성이 더 뛰어나고 제동력 조절도 용이한 디스크 방식이 앞뒤 바퀴에 모두 쓰인다. 그러나 대형차로 가면 닥치고 제동력이 더 좋은 드럼 방식이 적어도 뒷바퀴에는 여전히 지존이다. 다만, 대형차 말고 아예 경차도 원가 절감을 위해 드럼 브레이크가 쓰이곤 한다.

그리고 승용차와 소형 트럭에서는 제동력을 전하는 매체가 브레이크액이라는 액체인 반면, 중형급 버스나 트럭(4~5t쯤?)부터는 역시나 성능이 좋다는 이유로 압축 공기가 쓰인다. 대형차에서 걸핏하면 '축~ 취익~' 방귀 소리가 나는 이유가 바로 이 때문이다.

브레이크는 짧은 시간 동안 너무 자주 많이 밟으면 엔진만큼이나 과열될 수 있다. 브레이크액이 끓을 정도가 돼서 페달을 밟아도 쑤욱 들어가기만 하고 제동이 전혀 안 걸리는 것은 vapor lock 현상이다. 그리고 브레이크 패드가 달궈져서 제동력이 떨어지는 건 fade 현상인데, 디스크보다는 드럼 방식이 더 취약하다.
대형차는 브레이크액 방식이 아니니 vapor lock 현상에는 해당되지 않지만, fade 현상과 아예 공기압의 고갈을 조심해야 한다. 계기판에 브레이크 공기압 게이지가 달려 있다.

(3) 변속기
승용차급에서는 자동 변속기가 대세가 된 반면, 대형 상용차(트럭, 버스)에서는 차량 가격과 성능, 연비 같은 효율 문제 때문에 오늘날까지도 여전히 수동 변속기가 주류이다.
그리고 100~400마력짜리 자동차 레벨에서 수동 변속기라면 그냥 톱니바퀴만으로 감당 가능하다. 철도 차량도 짤막한 디젤 동차는 이런 식으로 동력을 변환한다.

그러나 수천 마력의 출력으로 여러 객차를 끄는 기관차에서 기어만으로 동력 변환을 하려면 변속기가 너무 커지고 복잡해진다. 그렇기 때문에 효율은 약간 떨어지지만 동력을 간접적으로 전해서 변환하는 유체 변속기 내지 토크 컨버터가 쓰이며, 자동차에서도 자동 변속기는 이 방식을 쓴다.

아울러, 전기도 교류는 같은 전력에서 전압-전류 출력 변환이 용이하니, 대형 디젤 기관차는 변속기 오일 대신 전기를 중간 매체로 사용해서 디젤 전기 기관차 형태인 게 보통이다.

사실은 철도 차량까지 갈 것 없이 버스 중에도 저상 버스는 커다란 물리적인 기어박스를 원하는 형태로 밑에 장착하기 곤란하다는 이유로 인해, 불가피하게 자동 변속기가 장착되어 왔다. 허나 최근에는 그런 기술적인 한계가 극복됐다는 얘기도 들린다. 저상 버스에도 수동 변속기가 널리 보급되면 기사가 운전하기는 더 힘들지만, 버스 회사의 입장에서는 구입 단가가 저렴해질 수 있겠다.

(4) 서스펜션
세상의 자동차들은 바퀴와 차체가 곧이곧대로 딱딱하게 붙어 있는 게 아니다. 한쪽으로 충격을 받으면 그걸 흡수하여 반대편으로 들썩거린다. 마치 초고층 빌딩이 바람을 맞으면 미세하게나마 흔들리게 설계되는 것과 비슷한 이치 같다.

육상 교통수단에는 이걸 담당하는 서스펜션 내지 현가장치라는 게 있어야 좋은 승차감이 보장될 수 있다. 자동차가 아닌 마차 시절에도 초보적인 형태의 현가장치는 고안되어 쓰여 왔다.
철도는 길이 워낙 곧고 부드러우니 차량에 이런 게 전혀 필요하지 않을 것 같다만, 그래도 거기에도 간략하게나마 자동차와는 다른 형태의 현가장치가 있다. (철도 차량에는 차동 기어는 없음. 커브를 돌 때 좌우 바퀴의 회전수를 달리하여 동력을 전하는 장치)

승용차의 바퀴 주변을 보면 지면과 수직으로 코일 내지 스프링이 둘러진 막대기가 보이는데, 그게 서스펜션이다. 더 세부적인 방식으로는 multi-link 방식, rigid axle 방식 등 여러 종류가 있는데 그것까지는 잘 모르겠고..

그 반면, 대형 트럭의 뒷바퀴를 보면 통상적인 스프링이 아니라 무슨 활 모양의 휘어진 작대기가 지면과 수평으로 여러 겹 둘러진 게 보인다. 요것은 대형차에서 주로 쓰이는 판(leaf) 스프링 서스펜션이다.

판 스프링 서스펜션은 코일 스프링보다 승차감이 별로이지만, 그래도 역시나 저렴하고 강한 충격과 하중에도 안 부러지고 버티기 때문에 천상 대형차용으로 쓰이고 있다. 하지만 정비를 제대로 안 하다가 판 스프링 중 일부가 주행 중에 부러져서 떨어지고, 그걸 뒷차가 밟는 바람에 휙 튕겨 날아가서 주변의 차들에게 사고를 유발하는 민폐를 종종 끼치곤 한다.

특히 지난 2018년 1월, 중부 고속도로 이천시 구간에서는 달리던 승용차의 앞으로 웬 철판이 날아들어 신혼 부부 신랑이 목숨을 잃는 비극적인 사고가 났는데.. '죽음의 철판'이라고 불린 그 물체도 바로 불상의 화물차에서 부러지고 떨어져 나간 판 스프링 조각이었다.

그걸 밟아서 반대편 차로로 튕긴 주범은 어느 관광버스였다. 경찰에서 두 달이 넘게 빡세게 CCTV를 판독하고 조사한 끝에 기어이 찾아냈다. 하지만 깜깜한 밤에 길쭉한 철판 조각이 떨어진 것을 일일이 확인하면서 달릴 수는 없는 노릇이고 그 버스 기사에게 책임을 물을 수는 없었다. 그리고 철판을 떨어뜨린 차량은 끝내 찾아내지 못했다.

2. 특수한 대형 자동차

세상에는 엔진이 달렸고 바퀴가 굴러가지만, 도로교통법의 적용을 받지 않으며 일반 도로에서 주행할 수 없는 자동차가 있다. 이런 차들은 특수한 구역 내부만 주행할 수 있으며, 통상적인 등록 절차를 거친 '바사아자'(자가용일 리는 없을 테니) 번호판이 달려 있지도 않다. 일반 도로를 주행할 수 없는 이유는 대체로 길이나 폭 같은 크기가 너무 크기 때문이다.

에버랜드의 주차장 셔틀버스가 좋은 예이고, 더 일반적으로는 공항 계류장에서 이런 특수한 자동차들이 여럿 볼 수 있다. 비행기를 활주로까지 밀고 당겨 주는 토잉카라든가, 탑승교가 없는 공항에서 승객을 비행기까지 단거리 수송하는 일명 램프 버스/에이프런 버스 말이다.

전자의 경우, 보잉 747급의 대형 여객기를 옮겨 주는 물건은 공사장이나 탄광에서 쓰이는 어지간한 중장비· 건설 기계보다도 출력이 훨씬 더 높다. (거의 1000마력 근처) 토잉카는 바퀴의 공전 현상 없이(= 충분한 접지력) 비행기를 견인하기 위해 자기 자신부터 엄청나게 무겁게 만들어지며, 엔진도 그에 상응하는 출력을 내야 하기 때문이다.

램프 버스는 어차피 경사가 전혀 없는 공항 계류장만 다닐 테니 기존 시내버스보다도 바닥이 극도로 낮다. 폭과 길이는 도로교통법에서 규정된 한계를 씹어먹을 정도로 더 크지만(비행기 승객을 한번에 모두 태우기 위해서) 좌석은 아예 전혀 없다. 도시형 입석 시내버스보다 더 단거리 가축 수송에 최적화돼 있는 셈이다.

얘들은 차량 크기뿐만 아니라 배기가스 규제 쪽도 통상적인 법의 적용을 받지 않는다. 그렇기 때문에 굉장히 오래된 연식의 차량도 계속 굴러다닌다고 한다. 글쎄, 아예 전기차로 바꿔 버려도 될 것 같다만 말이다.

단, 국내의 경우 원주 공항은 전국에서 유일하게 터미널과 활주로가 1.7km 가까이 멀리 떨어져 있으며, 중간에 일반 차도를 지나야만 두 장소를 왕래할 수 있다. 그래서 램프 버스도 일반 자동차들과 동일한 번호판에 동일한 체격인 일반 버스이다. 뭐, 저기는 국제 공항도 아니고 제주도 행 대한 항공 여객기가 하루 한 편 다닐까 말까인 군소 공항이니 그저 그러려니 하고 넘기면 된다.

공항을 벗어나서 여객이 아닌 화물· 중장비· 건설 기계 분야로 가면 역시나 엄청나게 크고 아름다운 특수 차량을 볼 수 있다.
Mack Titan처럼 road train이라고 불리는 초대형 트레일러는 그래도 그 나라의 도로교통법에 맞게 설계되었고 일반 도로를 주행하는 차량이다. 그것 말고.. 광산에서 쓰이는 트럭 중에는 통상적인 길이· 높이· 폭과 축중량 한계를 몽땅 무시한 괴물이 있다. Terex Titan, Komatsu 930E, CAT 797F 이런 것 말이다.

얘들은 공장에서 생산되고 나서 광산 현장으로 이동은 어떻게 했겠는지 궁금하다.
하긴, 가끔은 여러 개의 차선을 점유하는 초대형 화물--로켓 부품 같은?--을 일반 도로에서 트레일러로 불가피하게 수송해야 할 때가 있다.
이때는 미리 허가를 받은 뒤에 앞뒤로 에스코트 하는 차량을 두고 옛날 적기 조례가 적용되었던 것처럼 진짜 살금살금 조심조심 움직여야 한다. 이런 짓은 주변에 끼치는 민폐가 크기 때문에 한밤중에 몰래 하는 편이다.

3. 쌍동체 비행기

지금까지 글이 대부분 초대형 특수 자동차 위주로 진행됐는데, 초대형 특수 비행기에 대해서도 언급하고 글을 맺도록 하겠다.
현재까지 세계에서 가장 큰 비행기는 An-225 내지 에어버스 A380이 1위를 다투고 있다. 비행정까지 포함하면 옛날의 휴스 H-4 허큘리스가 명목상 최대이다.

그런데 옛날에는 마치 아이스크림 쌍쌍바처럼 꼬리날개를 포함한 동체가 둘로 구성된.. '쌍동체' 비행기가 있었다. 뭐 그때는 쌍동체라고 해 봤자 기체 전체의 크기가 그렇게 크지 않았다. 복엽기만큼이나 당대의 제한된 기술만으로 비행기의 성능과 수송력을 끌어올리려던 여러 시도 중 하나였을 것이다.

어느 공상 과학 소설에서는 보잉 747 같은 대형 여객기가 2개 내지 3개의 동체로 편성돼서 한번에 무슨 타이타닉처럼 1000~2000명씩 타는 게 묘사된 걸 본인은 읽은 기억이 있다. 무슨 열차도 아니고 말이다.

그런데 지금은 그게 얼추 비슷하게 현실이 된 게 있다.
Stratolaunch라는 회사에서 로켓을 완전 지상이 아닌 공중에서 저렴하게 발사하기 위해, 로켓을 실을 수 있을 정도로 거대한 특수 쌍동체 비행기를 제작했기 때문이다.

날개의 폭이 117m에 달한다고 한다. 기체 대비 저 깨알같은 사람의 크기를 비교해 보시라..;;
얘도 통상적인 규격 하에서 만들어진 공항 활주로에서 이착륙 할 수는 없을 것이다. 휴스 H-4 허큘리스를 제치고 전세계에서 폭 하나는 제일 큰 비행기라는 타이틀을 차지했다.

폭만 무식하게 크고 나머지는 상대적으로 가녀리게 생긴 저 비행기에서 로켓 발사를 어떻게 하겠다는 건지는 잘 모르겠지만, 세상엔 이런 식으로 특이하게 거대하게 생긴 특수 목적 교통수단이 분야별로 있다는 걸 알게 된다.
선박이야 원래부터 워낙 거대한 놈 천지이며, 뭔가 외형이 크게 특이하게 바뀌면서 덩치가 커지는 게 없으니 논외로 하자.

Posted by 사무엘

지난 2016년 여름에 영화 인천 상륙 작전이 나왔는데, 이제는 그 스토리의 프리퀄 격인 장사 상륙 작전을 다룬 영화가 만들어져 나왔다. 이건 적을 혼동시키고 군사력을 분산시켜서 진짜 본론인 인천 상륙 작전이 차질 없이 수행되게 하기 위한 밑밥이었던 셈이다. 본인은 개봉 초기에 영화를 잘 보고 왔다.

(1) 이 영화는 팩트와 실존 인물을 표방한다는 것을 시작과 끝에서 명시하고 있다. 최소한 "대장 김 창수", "고산자 대동여지도", "자전차왕 엄 복동", "말모이" 같은 급으로.. 주 스토리 차원에서 말도 안 되는 왜곡, 주작, 창작, 각색은 없으니 안심하셔도 된다.
문산호가 좌초· 침몰한 것, 갑자기 통신이 끊겨서 상륙 후에 곧장 귀환을 못 하고 학도병 팀이 오랫동안 고립됐던 것 등등은.. 모두 팩트이다.

(2) 학생들이 보트 타고 상륙하고 총질하는 게.. 마치 배틀로얄 2 레퀴엠 장면 같았다..;; 학도병 주인공 둘은 "15소년 표류기"에 나오는 브리앙과 도니판 같아 보이기도 하고..

(3) 작중에 나오는 터널은 단면이 말발굽 모양인 게 명백하게 단선 철도 터널처럼 생겼는데..
일제 말기 때 만들다가 말았던 동해중부선의 흔적이 아닌가 싶다. (실제로 작전이 수행되었던 곳은 7번 국도 구간이라고 한다만..)
일제는 전쟁 중에 물자가 부족해서 금강산선, 경북선 같은 철도의 선로를 뜯어 가긴 했지만, 러시아 진출에 필요한 경원선은 복선화하고, 동해중부선은 오히려 새로 건설하고 있었다.

(4) "공산군 저놈도 알고 보면 한 부모의 아들이고 착한 놈이었어"라든가(북괴 기관총 사수를 죽이고 나서 보니 걍 앳된 학도병..), 오글거리는 어설픈 "태극기 휘날리며" 스타일의 신파극이 살짝 들어가 있다.
그리고 국군과 미군 수뇌부를 마냥 절대선이 아니라, 융통성 없고 학생들을 일회용품 총알받이로 쓰고 갖다버리려는 꼰대 집단 비스무리하게 묘사하긴 한다. 하지만 이념적으로 불순한 정도까지는 아니다.

그도 그럴 것이 이 영화는 인천 상륙 작전과 달리, 적인 공산군 중에서 막 인상적인 활약을 하는 악역 주연이 딱히 없다. 그냥 떼거지로 몰려와서 아군에게 총질만 할 뿐이다.
그리고 아군도.. 스토리를 심하게 각색· 왜곡하지 않고서는 겨우 앳된 학도병이 일당백 용감무쌍 무공을 펼치는 식으로 묘사할 수도 없다. 걔네들은 일당백은커녕 총소리 듣고 혼비백산 겁 먹고 달아나지 않은 것만으로도 너무 대단했던 10대 소년들이다. 이런 스토리 구조에서 굳이 대립· 갈등 비스무리한 걸 넣으려면 아군 수뇌부에게라도 그 역할을 약간 감당시켜야 했을 것이다.

요즘 시대에 197, 80년대 스타일의 일방적인 절대선 절대악 애국심 호소만 존재하는 반공 영화를 기대할 수는 없는 노릇이고, 저 영화가 오히려 더 현실적인 묘사를 한 면모도 있다.
미국도 결국은 위험을 무릅쓰고 조치원함을 보내 주고 애들을 구하려고 일말의 노력은 했다. 그리고 불가능에 가까운 임무를 죽을 고생 하고 완수하고 살아 돌아온 이 명흠 대위를 국군에서는 전사자가 너무 많고 배(문산호)를 버리고 왔다는 이유로 사형에 처하려고 했을 정도이니.. 실제로 융통성 없는 꼰대 집단인 것도 맞았다.. -_-;; (그래도 다행히 진짜 처형하지는 않음)

(5) 결말도.. 액자식 구성이 아닌 것으로 시작한 영화가 갑자기 저렇게 끝나는 건 대놓고 "태극기.."를 따라 한 억지 급조인 것 같다.
그래도 전체적인 결론은.. 나쁘지 않은 작품이다.
아무리 민족이니 뭐니 해도, 추구하는 가치가 다르고 이념이 다르면 도저히 함께할 수 없으며, 서로 완벽하게 격리· 분리· 독립이 불가능하다면 최악의 경우 서로 죽고 죽이기도 해야 한다는 것을 느꼈다.

(6) 이 영화의 모티브인 장사리 상륙 작전은 6·25 중의 여러 전투들처럼 단순히 오래되어서 인지도가 낮을 뿐이지, 무슨 실미도 급으로 존재가 부정되고 조직적으로 은폐된 작전은 결코 아니다.

이미 196, 70년대의 언론 보도와 매체에서도 버젓이 언급되어 왔다. 일반인들이나 잘 모르지 근현대사 전쟁사를 전문적으로 연구하는 사람들까지 모를 정도는 아니었다. 학도병들이 무슨 실미도 북파공작원이나 국정원 흑색요원 같은 존재는 아니었으니 말이다.
그러니 이 전투가 완전히 잊혀졌다가 뒤늦게 발굴되었네 어쩌네 유세를 떠는 것은 영화의 유니크함을 어필하기 위한 마케팅 과장이다. 걸러가며 들을 필요가 있다.

(7) 내가 이 영화 소개글을 블로그에다 올리려고 마음먹게 된 결정적인 계기는..
저 실제 장사리 해변/해수욕장에 이미 철도로 접근할 수가 있게 됐다는 것을 본인도 뒤늦게 알게 됐기 때문이다.

현재 국도 7호선의 철도 버전으로 포항과 삼척을 잇는 동해중부선, 통합 동해선이 일단은 2022년에 전구간 개통을 목표로 공사 중인 것은 주지의 사실이다.
요즘 세상에 고속철이 아니고 광역전철도 아닌 생판 오지에 새로운 단선 비전철 철도가 새로 생긴다니 굉장히 이색적인데.. 포항-영덕 구간은 이미 작년 1월에 개통했다. 그 사이에 '장사'라는 역이 생겨서 여기서 내려서 몇백 m 걸어가면, 장사 해수욕장과 함께 그 이름도 장사 상륙 작전 전적지까지 갈 수 있다!

우와.. 정말 까맣게 모르고 있었다.
2018년 초 그 당시엔 평창 동계 올림픽과 함께 모든 관심이 경강선 KTX에만 쏠려 있었기 때문이다.
2017년 6월 말에 서울-양양 고속도로(60) 춘천 동쪽 구간과 영천-상주 고속도로(301)가 거의 동시에 개통했지만, 전자의 인지도에 밀려서 후자는 묻혔던 것처럼 말이다.

장사리 영화를 안 봤으면 내가 일부러 거기 지형을 찾아보지 않았을 것이며, 세상에 "영덕 역이란 게 어딨어?"라는 무식한 소리를 2019년 가을까지도 늘어놓고 있었지 싶다.
나의 무지를 회개하며, 이를 일깨워 준 장사리 영화에 감사드리며 반성한다.
평창역에는 KTX만 서지만, 영덕역에서는 RDC 무궁화호만 탈 수 있다.

Posted by 사무엘