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

1. HTTP 통신 고수준 API

오늘날 운영체제의 GUI API가 qt 같은 별도의 프레임워크가 나온 걸 제외하면 통일된 게 없고(통일이 될 수가 없음..) 그래픽 API가 통합된 게 없듯이..
네트워크, 특히 HTTP/HTTPS 기반 통신 API 역시 내가 아는 한 뭔가 ANSI/ISO 차원의 표준이 나온 게 없이 운영체제마다 다 파편화돼 있는 것 같다. 물론 제일 저수준의 소켓 API는 그럭저럭 표준화가 돼 있지만 오늘날 그것만 써서 밑바닥부터 프로그램을 짜는 건 클라이언트건 서버건 무리이니 말이다. 그러니 Windows, 안드로이드, iOS/macOS마다 또 API를 새로 익혀야 하는 게 다소 번거롭다.

요즘 인터넷에서 다른 프로토콜들은 거의 듣보잡이 돼 가고 HTTP/HTTPS만 남은 것 같다.
통합 라이브러리는 스위치만 달리해서 동일한 정보를 (1) GET와 POST 두 방식으로 간편하게 보낼 수 있으며, 이때 argument를 적절히 배치해 줘야 한다. 전자는 주소에다가 넣고 후자는 헤더에다가 넣어야 할 것이다.

URL 인코딩 처리를 적절히 해 줘야 하며, 바이너리 데이터 덤프를 base64로 인코딩, 또는 디코딩 하는 라이브러리도 덤으로 제공하면 좋을 것이다. post로 보낼 때는 Content-Type, Content-Length 같은 상투적인 헤더를 당연히 자동으로 넣어 줘야 한다.

Windows에서는 메시지를 보내는 방식이 post의 반대가 send인데, HTTP에서는 요청을 보내는 방식이 post의 반대가 get이다. get은 어떤 정보를 얻어 오기만 하는 read-only operation용으로 쓰고, post는 서버다 데이터를 등록하고 변경하고 삭제하는 등 side effect가 남는 요청을 할 때 쓴다. 일단은 그러하지만 홍보가 부족해서 현실에서는 그 용도가 엄밀하게 지켜지지는 않고 있다.

POST 방식 요청의 연장선이겠다만 (2) 다운로드뿐만 아니라 업로드도 당연히 지원해야 할 것이고, 받는 데이터 내지 올리는 데이터는 (3) 메모리, 파일명, 임의의 스트림 형태로 자유롭게 공급이 가능해야 한다. 전부 다 필요하기 때문이다.

그리고 아주 짤막한 파일을 주고받을 때나 UI 없이 그냥 명령줄 프로그램을 만들 때를 대비해서 그냥 (4) 동기형(응답이 올 때까지 block) + 짧은 대기 시간 형태도 지원하고, 별도의 스레드에서 돌아가는 비동기 방식도 자체 지원해야 한다.
비동기 방식은 결과가 왔을 때 콜백 함수 호출 하나로 끝나는 간편한 것을 생각할 수 있고, 한편으로 수십~수백 MB짜리 파일을 주고 받으면서 전송 상태를 늘 확인할 수 있는 복잡한 형태도 생각할 수 있는데, 둘 다 가능해야 한다.

단순 업데이트 체크 같은 건 굳이 지금 당장 안 돼도 상관 없는 것이니 프로그램의 반응성에 영향을 줘서는 안 될 것이다. 스마트폰 앱 같은 게 비행기 모드이거나 3G 데이터를 사용하고 있을 때는 괜찮은데 외부의 희미한 와이파이에 접속해 있을 때는 굼뜨는 경우가 있다. 이런 일이 없어야 할 것이다.

Java는 네트워크 쪽 클래스를 사용할 때는 try catch로 예외 처리가 무조건 돼 있어야 하고 안 그러면 컴파일조차 되지 않는데, 안드로이드에서는 그것도 모자라서 네트워크 통신은 무조건 별도의 스레드에서만 동작하게.. main GUI 스레드에서는 쓸 수도 없게 만들어 놓았다. 네트워크 에러 때문에 프로그램 전체의 동작· 반응이 멎는 걸 원천봉쇄하기 위한 조치인데, 이것 때문에 아주 간단한 소규모 통신에 대해서까지 일일이 스레드 만들고 함수 분리하는 건 번거롭기도 한 게 사실이다.

통신 API로 할 수 있는 일을 생각해 보니 이 정도인 것 같다. 이 모든 상황에 대한 대처가 가능하고 크로스 플랫폼까지 지원한다면 훌륭한 통신 API가 될 수 있을 것이다.

2. Windows CE 프로그래밍

회사에서는 이것저것 찝적대느라 안드로이드, macOS 코코아에 이어 근래엔 골동품인 Windows CE까지 만질 일이 있었다.
도스 기반의 Windows (1985), NT 커널(1993)에 비해 CE는 임베디드 환경을 타겟으로 나름 제일 나중에(1996) 등장했다. PC용 OS들과는 달리 CE는 리얼타임 OS이다.

그리고 CE는 훗날 Embedded Compact라고 이름이 미묘하게 바뀌었다가 2010년대부터 Windows Mobile, Windows Phone 등 스마트폰 OS로 변모하는가 싶더니.. 그냥 Windows 10 자체가 ARM용으로도 나오면서 모바일 분야를 흡수해 버렸다. 또한, 스마트폰 OS는 마소가 판단하기에도 Windows가 안드로이드와 iOS의 적수는 도저히 안 되겠다고 여겨져서 그냥 접어 버리고.. 그 대신 Visual Studio가 무려 안드로이드 개발도 지원하는 식으로, 완전히 다른 형태로 변화하게 되었다.

아무튼, 이 와중에 지금으로서는 좀 구닥다리가 된 Windows CE를 만져 봤다.
GUI에서 본인에게 아주 익숙한 Windows API로 프로그래밍 가능한 건 좋은 점이었다. 단, 같은 API를 사용하더라도 헤더 파일 구조가 PC와 동일하지는 않았으며, 생성되는 바이너리도 비록 PE 방식의 실행 파일이긴 하지만, PC Windows 버전처럼 kernel32, gdi32, user32 이런 DLL들 import가 있지는 않는 게 흥미로웠다.

그 대신 coredll.dll에 API들이 한데 몰빵돼 있는 듯하다. 그리고 메모리 절약을 위해 함수들은 이름이 아니라 ordinal 번호만으로 import하게 돼 있다.

static 라이브러리 같은 걸 만들어도 PC용과 CE 기기용을 동일 소스 기반으로 유지하기는 좀 어려워 보였다. 글쎄, #include 부분에 조건부 컴파일 로직을 정교하게 잘 짜 놓으면 불가능하지 않을지도 모르겠지만.. 거기까지는 잘 몰라서 말이다.
그러고 보니 옛날엔 Visual C++도 Embedded VC++라고 CE 개발 전용 에디션이 있긴 했다가 그건 2000년대 이후로 본가에 흡수됐다.

Visual Basic 6이라든가 Visual C++ 6은 후대 버전과 단절이 커서 꽤 오랫동안 쓰인 개발툴이라는 공통점이 있다. 그런데 Visual C++ 2008도 비슷한 면모가 있다. 바로 Windows Phone이 등장하기 전의 Windows CE 시절, 더 정확히는 Embedded Compact 6.5와 그 이전 버전 레거시 플랫폼의 개발을 지원하는 마지막 버전이라는 것이다.

자동차 내비에서도 이 운영체제가 돌아가는 경우가 있다.
PC용으로 오랫동안 개발되어 온 C++ 코드를 이 플랫폼과 컴파일러용으로 포팅하려다 보니 지금까지 편하게 써 왔던 auto와 lambda, nullptr 따위를 몽땅 구 문법으로 다시 써 주는 불편을 감수해야 했다. 저기서는 2010년대 이후에 새로 도입된 C++ 문법이 지원되지 않기 때문이다.

이 특정 플랫폼만 그런지는 모르겠지만, 인상적인 점은 뭔가 듬성듬성 빠진 함수가 많다는 것이었다. 덩치를 줄이기 위해서 다른 우회 대체제가 있다 싶은 건 몽땅 빼 버린 모양이다.
일례로, DrawText와 ExtTextOut은 있지만 더 단순한 함수인 TextOut은 없다(더 범용적인 대체제가 있으니까..). 파일 시스템도 도대체 뭐 어찌 되는지 GetCurrentDirectory, GetWindowsDirectory 이런 거 없다.

칼질은 C 함수 쪽도 예외가 아니다. 엄연히 ANSI 표준인 time 함수가 없어서 Windows API를 이용한 대체 함수를 직접 만들어야 했다.
그리고 어찌 된 일인지 FILE* 스트림 기반의 fopen 계열 말고, 정수형 파일 핸들을 주고 받는 저수준 _create, open 계열의 함수도 없더라. PC에서 쓰던 코드를 곧장 포팅하는 건 생각만치 쉽게 되지는 않았다.

제일 압권인 건 CE는 9x와는 정반대로.. API 함수에 W 버전만 있고 A 버전이 깔끔하게 없다는 것이었다.
9x는 W 버전도 껍데기는 있지만 실행이 에러 코드와 함께 몽땅 실패한다. CE에서는 A 버전이 컴파일은 되지만 링크가 되지 않고 곧장 실패했다. 1996년에 첫 개발된 신흥 OS이다 보니, 안 그래도 용량도 부족한데 구닥다리 레거시인 A는 처음부터 배제해 버린 셈이다.

Windows CE에는 W만 있고 A가 없다는 건 먼 옛날에 제프리 릭터 아저씨의 책에서 처음으로 봤는데 실제로 그렇다는 걸 그로부터 10수 년 이상 뒤에야 실제로 확인할 수 있었다.

3. 라이브러리의 형태의 변화

도스 시절에 프로그래밍에 필요한 무슨 라이브러리, API, 또는 SDK라 하면..
어셈블리어로 도스의 각종 특이한 인터럽트를 호출해서 하드웨어를 직통으로 건드리는 마우스 라이브러리, 그래픽/사운드 라이브러리, 심지어 한글 라이브러리 같은 게 많았다. 이런 기능들은 타 언어도 지원했지만 가장 먼저는 C/C++용 헤더와 라이브러리의 형태로 제공되었다.

Windows로 넘어가서는 어지간한 하드웨어 제어는 운영체제의 자체 API만 써도 커버가 되니 3rd party 라이브러리 같은 건 필요가 크게 줄어들었다. 그냥 MS Office와 Visual Studio의 외형을 흉내 내 주는 GUI 툴킷이라든가.. 이미지 파일 처리 라이브러리가 쓰였다. 아 그리고, DirectX SDK는 Windows 플랫폼 SDK로부터 완전히 분리 독립했기 때문에 따로 설치해야 하는 물건이 되긴 했다.

그런데 요즘은 그런 API, 라이브러리라는 게 용도와 형태가 바뀌고 있다. PC 안에서 혼자 돌아가는 프로그램이 고차원적인 하드웨어 제어 기능을 사용하는 게 아니라.. 웹사이트나 스마트폰 앱에서, (1) 특정 대규모 서버에서 제공하는 각종 실시간 정보 제공 기능(날씨, 버스와 지하철 위치, 지리 정보 등등)이라든가 (2) 아주 고수준의 인공지능 내지 패턴 인식 기능(이미지에서 사람 얼굴 인식, 음성 인식 등) 같은 것을.. 1인 개미 개발자가 자기 앱이나 사이트에서 곧장 사용할 수 있게 해 준다.

방대한 인공지능 데이터 검색과 계산은 서버가 담당한다. 바둑 AI로 치면 AI 코드가 라이브러리에 담겨 있는 게 아니라, 별도로 돌아가는 알파고 서버와 통신만 하는 거다.
언어는 무겁고 부담스러운 C/C++과는 거리가 멀며, JavaScript, Go, 파이썬 같은 것을 곧장 지원한다.
과금 체계도 과거의 전통적인 형태와는 사뭇 다르다. 비싼 라이브러리 제품을 몇만~몇십만 원 일시불로 지불하고 사 오는 게 아니라.. 월 얼마씩~ 사용 트래픽이 얼마까지는 무료이고 그 뒤부터는 한 건당 얼마 이런 식으로 매겨진다. 구매 대신 임대 형태이다.

기술은 그 자체는 온통 오픈소스다 뭐다 하면서 무료에 가깝게 공개되고 상향평준화되고 있다. Google API의 기능들을 개발하는 데 컴퓨터공학· 전산학 박사들이 얼마나 많이 투입됐을까..? 그 다음으로는 그냥 자본과 데이터 물량전이 대세이다.
그리고 소프트웨어로 돈 버는 건 기술과 기능 자체가 아니라 그걸로 온통 사용자들의 감성을 사로잡고, 자아· 정체성을 표현해 주는 대가로 형태가 바뀌는 것 같다. 온라인 게임의 부분 유료화라든가 각종 아바타가 대표적인 예이고 말이다.

아, 그렇다고 지금이 전통적인 형태로 판매되는 라이브러리· 미들웨어가 전멸했다는 얘기는 아니다. 게임에서 주로 쓰이는 네트워크 라이브러리, 동영상 캡처 라이브러리 같은 것들은 전적으로 로컬에서 기능이 동작하며, 단품 또는 출시되는 제품 타이틀의 규모 단위로 판매되고 있다. 돈을 한번 지불하고 끝인 것도 있고, 일정 주기로 꼬박꼬박 로얄티를 내는 형태인 것도 있다.

4. 함수 호출과 금융의 관계

좀 엉뚱한 생각을 하자면, 금융을 프로그래밍에다가 비유하고 돈이 오가는 걸 함수 호출과 데이터 전달에다가 비유할 수 있을 것 같다.

현금이 오가는 건 데이터 실물을 통째로 스택에다 얹는 call by value이다. 제일 단순하고 확실하지만 거액의 현금을 매번 들고 다니는 건 번거롭고 귀찮고 위험하다.
그러니 현금, 또는 가까운 미래에 들어올 예정인 돈에 대한 포인터가 등장하는데, 이것들이 바로 수표나 어음이다. call by reference가 현실 세계에도 존재하는 셈이다.
부도는 당연히 잘못된 포인터 접근으로 인한 page fault 내지 access violation과 직통 대응이다.

컴퓨터에는 지금 물리적으로 실제로 있는 메모리보다 더 많은 주소 공간을 끌어다 쓰고, 공간이 없으면 디스크 스와핑이라도 하는 '가상 메모리'라는 개념이 있다. 이게 어찌 보면 '대출'과 비슷한 개념으로 보인다.
물론 컴퓨터의 동작에 경제 용어인 '신용'과 정확히 대응하는 개념이 존재하지는 않는다. 그러니 완전 동일하게 대응하지는 않겠지만.. 그래도 이런 식으로 비유해 보면 생각보다 그럴싸하고 씽크가 맞아 보인다.

참고로, 성경이 말하는 헌금 원칙은 철저하게 리얼 모드이다. 빚을 내거나, 없는 돈을 미리 작정하는 보호 모드 가상 메모리 같은 개념은 없다.

5. 보안 정책

오래된 일이긴 하지만 마이크로소프트는 회사가 돌아가는 방식이 2002년 1월 1일 이전과 이후가 서로 싹 달라졌다. 더 엄격한 보안 정책과 더 일관성 있는 제품 지원 주기 정책이 적용되기 시작했기 때문이다.
일단, 이때를 기점으로 해서 모든 마소 제품에서 이스터 에그가 사라졌다. 문서화되지 않은 특정 동작을 하면 프로그램 개발자 명단이 나타나고 숨겨진 게임이나 애니메이션이 뜨는 것 말이다.

그리고 (a) 일반 지원은 제품 출시 후 몇 년 또는 차기 버전이 나온 지 몇 년 중 짧은 기간까지, (b) 연장 지원은 일반 지원이 종료된 뒤부터 5년간.. 요런 식의 규정이 추가되어 오늘날에 이르고 있다. 그와 함께 도스, Windows 3.x/95 같은 구닥다리 제품들은 지금까지 알음알음 지원되어 오던 것이 2001년 12월 31일을 끝으로 지원이 완전히 끊겼으며, 공식적으로 abandonware 판정을 받았다.

인터넷 덕분에 소프트웨어를 배포하는 데 물리적인 장벽은 사라지다시피한 반면, 원격으로 프로그램을 조종하고 컴퓨터를 장악할 수 있는 보안 위협이 커졌기 때문이다. 결국 소프트웨어라는 건 한번 만들고 나서 끝인 게 절대 아니라 계속해서 지원을 해야 하며, 굳이 기능과 컨텐츠에 아무 변화가 없더라도 보안 취약점이 발견되면 계속해서 고치고 지원해 줘야 하는 반제품 정도로 위상이 바뀌었다.

그러니 소프트웨어의 판매 비용에는 이런 잠재적 사후 지원 비용도 포함되어야 하며, 지원을 한도 끝도 없이 영원무궁토록 해 줄 수는 없으니 구체적인 기간이 법적으로 명시될 필요도 생긴 것이다.

그 뒤로 마소에서는 2000년 중반에 프로그램 개발의 기본 블록이라 할 수 있는 C 라이브러리에서부터 보안 결함을 잡겠다고 strcpy, gets 같은 함수들에 칼질을 가했으며, Visual Studio 2005에서 이를 최초로 적용했다. 컴파일러에 /GS 같은 검사 기능도 추가했다.
재래식 도움말인 WinHlp32 엔진은 너무 구닥다리 기능으로 전락한 데다, 이런 새로운 보안 기준을 충족하게 개량을 하기에는 가성비가 너무 안 맞는 관계(시간과 예산..)로 Windows Vista에서부터는 짤렸다.

Vista에서는 프로그램의 실행 주소를 그때 그때 랜덤화하는 보안 기능이 추가되기도 했다. Windows는 애초에 position independent code를 쓰지도 않는 운영체제인데, 오로지 보안을 위해 그 이념을 근본적으로 부정하고 성능을 희생하는 기능을 넣은 것이다.

이렇게 런타임 환경에다가는 예측 불가능한 요소를 일부러 가미한 반면, 빌드 타임 환경에는 정반대의 정책이 적용되고 있다. 같은 소스 코드를 같은 컴파일러 제품으로 빌드했으면 시간과 장소를 불문하고 바이너리 수준에서 언제나 완전히 동일한 실행 파일이 나오게 하자는 것이다. 이름하여 Reproducible builds이다.

단순히 생성되는 기계어 코드를 넘어서 객체들의 명칭과 배열 순서라든가 내부적으로 생성되는 각종 시그니처까지 완전히 똑같게.. 상상할 수 없을 정도로 다양한 환경에서 실행되는 프로그램을 테스트· 디버깅 할 때 문제를 재연하기 어렵게 만드는 변화 요인를 털끝만치라도 줄이겠다는 의도로 보인다.

시범타로 예전에 실행 파일의 헤더 차원에서 timestamp가 들어가던 곳에도 Windows 10에 들어가는 바이너리들은 그냥 고정된 hash값으로 바뀌었다고 한다. 시간이야 난수의 씨앗으로도 쓰일 정도로 매번 달라지는 값이니 말이다.
이렇게 21세기 들어서 세월이 흐를 수록 마소는 내부의 보안 정책이 갈수록 엄격해지는 것이 느껴진다. 그 와중에 실행 주소 랜덤화와 Reproducible builds라는 두 이념이 본인이 보기에 흥미로운 대조를 이루는 듯해 보였다.

Posted by 사무엘

북한은 정치 분야에서 언어 구사가 좀 과격한 구석이 있을지언정, 우리 남한만치 한자어나 외래어를 막 남발하지 않고 순화를 많이 한다고 그런다. 하지만 그렇다고 진짜로 아이스크림 대신 얼음보숭이 같은 오글거리는 말까지 적극 사용할 정도는 아니라는 탈북자의 증언도 있다.

이런 와중에 남한 같았으면 그냥 '정지'라고 할 것을 북한의 도로 표지판은 진짜 단순무식하게 '섯!'이라고 적혀 있다고 한다. 언어학적 의미 전달이야 이보다 더 명확할 수 없고 문제가 전혀 없지만, 그럼에도 불구하고 뭔가 격식이 안 어울리다 보니 우리 같은 사람들은 빵터지게 된다.

출처를 알 수 없는 이 흐릿한 사진이 제일 유명하지만, 구글링을 해 보면 이것 말고 다른 장소에서도 곳곳에 '섯/섯!'이라고 적힌 북한 표지판이 많이 나온다. 교차 검증이 되는 셈이므로 이 자료는 신빙성이 있다.

그런데 북한에 '섯!' 표지판이 있다면, 옛날에 남한에는 주차 대신 '둠'이라는 표지판이 있었다고 한다. 당연히 Doom 게임이 아니라-_-;; '(세워) 두다'의 명사형이다.
본인도 지금까지 '그랬다 카더라'라고 소문만 들었는데 그 표지판의 실제 모습을 우연히 발견했다. 다음은 1970~80년대의 어느 대한뉴스에서 교통 질서 캠페인이 나오던 화면을 캡처한 것이다.

둠. 참 강렬하지 않은가..??? =_=;;
이런 말이 잠시나마 만들어져 쓰인 배경에는 국어학자 최 현배 박사가 있었다. 이분이 한국어에서 '-음/ㅁ' 명사화 접미사를 굉장히 좋아했던 분이기 때문이다. 저서를 '지음'으로, 생활을 '살음'이라고 표현했을 정도로.

내가 지금까지 관련 자료를 소개한 적이 없었구나. 그분의 저서..라기보다는 유고작인 <한글만 쓰기의 주장>의 한 부분을 인용하고자 한다. 원작의 맞춤법과 띄어쓰기, 외래어 표기를 그대로 옮겨 썼다.

지금이야 민족이나 인종, 심지어 언어를 서로 대놓고 비교하면서 어느 게 우수하네 마네 하는 소리는 그야말로 히틀러스러운 나치즘, 파시즘, 국뽕 전체주의 소리 들으면서 욕 먹기 딱 좋다. 더구나 난 일본어를 전혀 모르기 때문에 동명사를 만드는 게 한국어보다 뭐가 그렇게 불편한지 저 말의 배경도 잘 모르겠다. 뭐, 일본인 학자가 거짓말을 하지는 않았겠지..

하지만 저 때가 어떤 시절이었는가? 최 현배 박사는 1970년에 세상을 떠났으니 지금으로부터 무려 반세기 전의 옛날 사람이다.
1968년 12월 8월이면 뭐 떠오르는 거 없으신가? 박 정희 대통령에 의해 국민 교육 헌장이 선포된 지 겨우 사흘 뒤의 일이다(12월 5일). 그야말로 어마어마한 옛날이 아닐 수 없다.

저 때는 언어건 문화건 경제건 "우린 안 될 거야 아마"라고 아무 꿈도 희망도 없던 시궁창 헬조선 반도에서 국민들에게 "우리는 우수한 민족이다, 우리(는/도) 할 수 있다"라고 정치인 지식인들 할 것 없이 무지한 국민들에게 마음껏 국뽕이라는 동기 부여를 주입해 줘야 했다. 그러던 와중에 한글은 가히 이보다 더 훌륭할 수 없는 약이었던 것이다. 그래서인지 저 글을 보면 알 만한 거물급 국어학자임에도 불구하고 '한국어'를 쓸 만한 문맥에서까지 문자인 '한글'이 엄밀한 구분 없이 종종 섞여 쓰여 있다.

최 현배는 당대를 살았던 공 병우· 이 승만 같은 인물과 비슷한 급의 천재이고, "방망이 깎던 노인"을 연상케 할 정도로 아주 강직하고 괴팍한 고집쟁이였다. 194~50년대엔 단순히 한자를 없애는 수준을 넘어서 문자를 기계화하지 못하면 민족이 망할 거라고까지 생각해서 <글자의 혁명> 같은 굉장히 과격한 책도 쓴 적이 있다. (한글을 라틴 알파벳 같은 풀어쓰기 문자로 마개조하자)

그리고 일본인 스승 밑에서 언어학을 공부했고 언어학뿐만 아니라 교육학과 철학에도 일가견이 있었지만, 한편으로 조선어 학회 사건 때 투옥되어 고초를 겪고 죽을 뻔하기까지 했다. 그렇기 때문에 그는 일본의 일 짜만 나와도 몸서리 쳤던 골수 민족주의자 항일 인사였다. 미국의 조지 부시 대통령(아들 말고 아버지)이 개인 소신으로는 평생 일본을 싫어하며 지냈듯이 말이다(군 복무 시절에 동료들이 미친 식인귀 일본군에게 잡아먹혔으며, 자기도 극적으로 구조되지 못했으면 그렇게 될 뻔..).

이런 최 현배 박사의 주장에 대해서 날틀, 배꽃계집큰배움터 같은 이상한 오해와 음해가 나돌았다. 하지만 그가 실제로 장려했던 순우리말 용어는 말본, 셈본, 넘보랏살, 콩팥 이런 온건한 선을 넘지 않았으며, 그리고 저런 '둠'이야말로 주작이 아닌 팩트이다. 최 박사의 저서를 보면 '둠'이 제안된 배경을 더 잘 이해할 수 있을 것이다. 순화라는 게 명사를 억지로 뭉쳐 붙이는 것만이 전부가 아니다.

본인이 생각하기에도, 동사를 명사화해서 표현할 때 영한사전 번역투 영향을 받아서 천편일률적으로 '-는 것'만 쓸 게 아니라, '-음/ㅁ', '-기' 같은 접미사도 많이 활용하는 것이 표현의 다양성 차원에서 좋다고 여겨진다. 뭐, 전에도 얘기했듯이 영어는 근본적으로 명사와 형용사를 좋아하는 반면, 한국어는 동사(용언)와 부사를 좋아하는 언어라는 차이가 있기도 하다.

도시락, 동아리, 모꼬지 이런 말은 최 현배의 사후에 그의 학풍을 물려받은 대학생 우리말 사랑 단체에서 1980년대쯤에 만들거나 재발견하여 보급되었다. 특히 동아리가 '서클'을 성공적으로 대체한 것은 매우 이례적인 현상이다.
이거 이후로 국내에서 순우리말 순화 운동은 1990년대에 컴퓨터 분야를 중심으로 무른모, 셈틀, 누리그물(...;; ) 이런 거나 나오다가 지금은 완전히 생명력을 잃고 자취를 감춘 것 같다.

이상. '둠, 섯'에서 시작해서 오랜만에 한글, 국어, 최 현배 박사 등 여러 얘기가 나왔다. 나의 모국어인 한국어의 문법과 어휘를 어떻게 활용하고 개량하면 이 영어 만능 시대에 더 간결하게 구사하고, 더 정확하게 번역할 수 있으려나 모르겠다. 쏟아져 나오는 용어들을 일일이 다 번역하는 것은 무의미하고 결국은 있는 그대로 빌려 쓰는 말도 있겠지만, 그게 결국은 독해력· 문해력의 격차로 이어지고 학문 수준의 격차로 이어지 않을지?

진실은 한국어· 한글이 앞으로 수십~수백 년 안에 사멸할지도 모른다고 걱정하던 옛날 민족주의 성향의 언어학자들하고, 그런 거 아무 의미 없다고 상대주의적으로만 흘러가는 요즘 추세의 중간에 있지 않나 생각이 든다.

Posted by 사무엘

오늘은 번듯한 산이라고 하기에는 너무 작고 낮고(해발 100여 m대) 그냥 공원 산책에 가까운 언덕 두 곳에 다녀온 기록을 남기도록 하겠다.

1. 북서울 꿈의 숲

서울 강북에 서울숲뿐만 아니라 더 북쪽에 이런 곳이 있다는 것은 본인도 비록 직접 보지는 못했어도 오래 전부터 알고 있었다. 서울숲은 산이 전혀 아닌 평지이고(원래 골프장..) 한강과 가까워서 한강 공원과도 연계되는 반면(강변북로를 육교로 횡단하여 서로 왕래 가능함), 저기는 벽오산인지 오패산인지 그래도 높이 차이가 존재하는 언덕이다.

옛날에는 서울 시내에 소규모 놀이공원 유원지가 좀 있었던 모양이다. 용마산 서쪽 기슭에 용마랜드라는 게 있었던 것처럼, 저기에는 ‘드림랜드’라는 게 있었다가 망했다. 그 뒤 시설을 철거하고 부지를 서울시에서 인수하여 이름에다가 예우 차원에서 나름 ‘꿈’이라는 단어를 붙여서 재개장한 게 북서울 꿈의 숲이라고 한다.

북서울 꿈의 숲은 북쪽과 남쪽이 언덕으로 둘러싸여 있다. 거기는 다 언덕을 오르내리는 등산로 구간이다. 그리고 양 언덕 사이는 일종의 분지이며 넓은 풀밭과 자그마한 호수, 갤러리가 있다. 돗자리 깔고 앉아서 쉬기 좋다. 혼자 변방의 언덕길 산책을 하거나 단체로 중앙의 풀밭에서 노는 게 모두 가능하다.

다만, 여기는 위치와 교통 접근성이 아무래도 서울숲만치 좋지는 못하다. 지하철만 타고 간편하게 갈 수는 없다. 그래도 정문· 동문 말고 언덕 쪽으로 나 있는 여러 등산로를 통해서도 접근 가능한 것은 서울숲보다 약간 좋은 점이다.
본인 역시 여기에 처음 갈 때는 번동의 모 아파트 단지 뒤로 나 있는 북쪽 언덕 진입로를 이용했다. 집에서 거기까지 한 번에 가는 버스가 있었으며, 애초에 방문 목적도 등산과 산책에다 비중을 뒀기 때문이다.

북서울 꿈의 숲이 어떤 구조로 돼 있는지 이 지도 한 장이면 곧장 이해 가능하다. 여기는 바로 8번 출입구를 통해 숲으로 들어갔다.

언덕을 오르는 산책로는 이런 모양이었다. 공원 형태로 나름 잘 꾸며 놨다.
서울숲의 북쪽 언덕에서 가장 높은 정상으로 추정되는 곳에는 공터가 꾸며져서 벤치, 간단한 운동 기구들이 놓여 있었다.

그 뒤 언덕을 내려가면서 서울숲의 서쪽 끝에 있는 문화 광장, 꿈의 숲 아트 센터 근처에 도달했다. 이제는 남쪽 언덕을 오를 차례였다.

남쪽 언덕에서 아래의 넓은 잔디밭, 월영지라고 불리는 연못을 내려다본 모습이다. 아직은 언덕과 평지 사이의 높이 차이가 그리 크지 않다.
남쪽 언덕도 꼭대기까지 올라 봤는데, 딱히 별로 볼 건 없었다.

북서울 꿈의 숲의 동쪽 끝으로 나가는 것으로 탐방을 마쳤다.

2. 동구릉

서울 서쪽의 고양시에 서오릉이 있다면, 서울 동쪽의 구리시에는 동구릉이 있다. 최고의 명당에다 만든다는 왕릉이 9개나 밀집해 있는 건 조선뿐만 아니라 한반도의 전체 역사를 통틀어도 여기가 유일하다고 한다. 태조 이 성계의 무덤도 여기에 있다.

하긴, 경주에도 왕릉 숫자로는 ‘오릉’이 최고이지, 신라 왕릉이 9개씩이나 밀집해 있는 곳은 없다.
광명시에서 광명 동굴을 관광 자원으로 미는 것처럼 구리시에서는 여기를 많이 홍보한다. 구리는 안 그래도 정말 작고 좁은 도시인데 나름 거물급 명소를 보유하고 있으니 말이다.

등산의 관점에서 살펴보면, 동구릉이 있는 곳은 ‘구릉산’이라고 불리는 작은 언덕의 동쪽이다. 서쪽은 ‘검암산’이라고 따로 불리면서 등산로도 있어 보인다. 하지만 근래에 산의 바로 서쪽으로 고속도로(구리-포천 29)가 뚫리면서 등산로가 많이 봉인되었다.
그리고 산의 남쪽에는 군부대가 있다. 사실, 서오릉이 있는 산도 서쪽 끝에는 군부대가 있긴 하다.

이런 특이한 점을 감안하여, 본인은 작년 겨울에 눈이 와서 제대로 등산을 할 수 없을 때에 동구릉 산책으로 등산을 대신했다. 실제로 찾아가 보니 왕릉에서 언덕 건너편의 등산로로 가는 길이 없지는 않았다. 물론, 왕릉은 입장료를 내고 정문에서 들어가야 하는 통제 구역이니 산 전체가 왕릉과 사통팔달 뚫려 있지는 않겠지만, 얼마나 산 속 깊숙히 갈 수 있는지 궁금해졌다.

허나 본인이 방문하던 당시엔 날씨를 비롯한 다른 사정 때문에 그 길로 진입이 금지돼 있었으며, 가까운 미래에 등산로가 개방될 것 같지는 않았다. 그렇다고 해서 이 산 전체가 다음에 또 찾아올 가치가 있을 정도로 크고 볼거리가 많은 산도 아니다 보니.. 본인은 이곳에서 그냥 동구릉만 다녀보는 것으로 만족하고 돌아왔다.

동구릉은 내부가 저런 구조이다.
본인은 이 산의 능선 쪽을 먼저 구경하고 싶어서 산을 깊숙하게 들어가는 순으로.. 경릉-원릉-휘릉 순으로 돌다가 다음으로 목-헌-수릉을 둘러봤다. 왕릉 안은 산 속으로 갈수록 약하게 오르막이 등장하긴 하지만 등산로의 경사에 비해서야 약과 수준일 뿐이었다.

혜릉은 방문 당시에 주변이 온통 공사 중인 관계로 가까이 있음에도 불구하고 제대로 구경하지 못했다. 또한, 맨 왼쪽의 숭릉은 다른 왕릉들과 달리 혼자 외진 곳에 있어서 찾아가기 힘들었다.
각 무덤과 무덤 사이의 거리는 그냥 100~300m 남짓이었던 것 같다. 슬금슬금 산책하기 아주 좋았다.

동구릉 안으로 입장하니 거의 곧장 이런 자그마한 전시관이 눈에 띄었다. 역대 모든 조선 왕들의 무덤 소재지를 저렇게 표시해 놓으니 아주 도움이 된다.
일부 왕릉은 북한으로 넘어가 버리기도 했구나. 그래도 개성 정도면 38선 시절에는 아직 미묘하게 남한 땅이었는데 아쉽다.

원래 조선 왕릉은 한양 도성으로부터 100리(대략 42km) 이내의 지점에 조성해야 한다는 규정을 따라 만들어지고 있었다. 그런데 화성이나 영월처럼 무덤이 혼자 독보적으로 먼 곳에 있는 왕은 사도세자나 단종처럼 정치적으로 좀 특이하고 예외적인 사연이 있는 사람들이다. 세종대왕의 경우 원래는 서울 강남의 헌인릉 인근에 무덤이 있었지만, 풍수지리상 더 길한 장소를 찾아서 훗날  멀리 여주로 이장된 거라고 한다.

저 때와는 달리, 오늘날의 전직 대통령은 죽으면 고인이 따로 유언을 남기지 않은 한 그냥 국립 현충원의 국가 원수 묘역에 순서대로 쭈욱 안장될 것이다. 김 영삼 이후로는 이 나라에 딱히 정치적인 격변도 없고 설마 또 서울 현충원에 묻히는 사람은 없을 테니 그냥 대전 현충원에 가게 된다. 참 대조적이다.

왕릉 내부에는 이렇게 아름드리 나무들과 함께 산책로가 잘 꾸며져 있었다. 그리고 작게나마 개울도 흐르고 있었다.

무덤 주변에 이런 스타일의 건물이 있는 건 예전에 서오릉과 천장산을 다녀보고 나니 이제 눈에 익숙했다.
눈이 쌓인 곳과 그렇지 않고 녹은 곳의 차이가 저렇다. 김 성모 만화에 나오는 "햇볕도 안 들고 양지바른 곳"이 저런 곳이라는 걸 알 수 있었다.

여기는 동쪽 끝으로 넓은 공터가 있던 목릉 주변의 모습이다.

여기는 휘릉.
사실, 무덤들이 다 그게 그거 같이 생겼다. 그렇기 때문에 따로 메모를 해 놓거나, 문화재에 대한 남다른 눈썰미를 갖추지 않는다면 어느 게 무슨 무덤인지 알기가 쉽지 않다.

뭐, 잘 알다시피 조선의 왕이라고 해서 죽은 뒤에 다 저런 예우를 받은 건 아니다.
성경에 나오는 이스라엘 왕조도.. 히스기야 같은 좋은 왕은 왕들의 돌무덤에서 제일 명당에 묻힌 반면(대하 16:14, 32:33, 35:24), 막장인 왕은 그냥 다윗의 도시에다가만 묻히고 왕들의 돌무덤에 가지는 못했다고 나온다(대하 21:20, 24:25, 28:27).

연산군과 광해군은 왕에서 짤렸기 때문에 사후에 '-종' 같은 휘호(명칭이 맞나?)를 못 받았고 무덤도 '릉/능'이 아닌 그냥 조촐한 '묘'이다. 박 근혜 전 대통령은 탄핵 인용 파면으로 인해 경호를 제외한 전 대통령 예우가 박탈되고, 역시 사후에 현충원에 묻히지는 못하게 됐다.

이상이다.
같은 날에 다녀오지도 않은 북서울 꿈의 숲과 동구릉을 좀 어거지로 한데 엮긴 했지만 그래도 등산 대체 산책 코스로서 일말의 동질감이 느껴졌다.
참고로, 북서울 꿈의 숲과 동구릉은 직선 거리로 8km쯤 떨어져 있지만 위도는 서로 비슷하다. 그리고 둘의 얼추 중간 지점에 봉화산이 있다.

Posted by 사무엘

5. 엔진 브레이크

엔진 브레이크라는 건 감속· 제동을 위해 자동차에 따로 장착되는 기계 장치를 가리키는 게 아니다. 이미 있는 엔진의 특성을 이용해서 차의 속력을 슬금슬금 줄이는 일종의 운전 테크닉에 가깝다.
자동차에서 엔진이 돌아가는 것과 바퀴가 돌아가는 것 사이의 관계는 뭐랄까 참 미묘하다. 서로 영향을 주고받는다. 엔진이 돌아가는 것에 비례해서 바퀴가 돌아가지만, 반대로 바퀴가 관성을 따라 계속 굴러가는 것이 엔진을 덩달아 회전시켜 주기도 한다.

엔진 브레이크의 본질은 강제로 기어를 저단으로 바꿔서 바퀴가 굴러갈 때 엔진을 덩달아 회전시키는 것을 굉장히 어렵게 하는 것이다. 그러면 아무리 내리막이라 해도 차가 호락호락 미끄러져 내려가지 않게 된다. 1단으로 고정이라도 시키면 차가 조금만 가속되어도 엔진 회전수가 팍 치솟으면서 굉장히 큰 저항 같은 게 걸린다. 물론 엔진 브레이크를 오· 남용하면 변속기를 포함한 파워트레인 계통이 퍼질 위험이 있지만, 그건 무슨 시속 100에서 1~2단 고정을 시켜서 엔진 회전수가 레드존 이상으로 치솟았을 때에나 걱정할 사항일 뿐이다.

이런 관점에서 보면, 변속기를 D로 놓고 주행하던 중에 가속 페달에서 발을 잠시 뗀 상황은 정말 순수하게 자전거 페달에서 발을 떼고 관성만으로 달리는 것과 같은 상황이 아니다. 정말 순수하게 관성 주행을 하려면 변속기를 N으로 옮기든가, 수동 변속기라면 클러치를 밟고 있어야 한다. 엔진이 바퀴와 연결되어 있는 한 고단 상태라도 아주 약하게나마 엔진 브레이크가 걸려 있는 셈이다.

관성만으로 자동차 바퀴를 굴리고 바퀴와 연결된 엔진까지 돌리는 상태는 오래 가지 못한다. 자동차는 지금 설정된 단의 기준으로 아이들링 rpm에 해당하는 최저 속도까지 서서히 감속될 것이고 엔진 rpm도 비례해서 줄어들 것이다. 액셀을 안 밟고 계속 방치하면 힘이 부족해서 현재의 '단'도 공기 저항 등 여러 이유로 인해 유지되지 못할 것이다. 그러니 자동 변속기는 알아서 더 저단으로 변속을 할 것이고, 궁극적으로 자동차는 최저단인 1단에서 그냥 슬슬 기어가는 상태로 되돌아가게 된다. 단순히 공기 저항 같은 요인 때문에 감속되는 게 아니라 엔진 브레이크가 걸려서 그렇게 된다는 뜻이다.

엔진 브레이크는 브레이크 페달의 부담을 일부 분담해 줄 뿐, 얘 단독으로 차를 완전히 세우지는 못한다. 토크가 작고 회전수 편차가 큰 휘발유 엔진이 엔진 브레이크의 성능이 더 좋은데, 정작 드럼 방식 브레이크 기반이고 엔진 브레이크가 더욱 절실히 필요한 차량들은 디젤 엔진 대형 차량이라는 게 역설적이다.

6. 접지력

브레이크라는 건 동작하기 위해서 충족되어야 하는 매우 기본적이고 중요한 전제 조건이 있다. 바로 바퀴가 제대로 된 접지력을 발휘하는 것이다. 바퀴가 접지력을 상실하면 굳이 급발진처럼 엔진에 의해 속도가 더 붙지는 않을지 몰라도, 핸들과 브레이크가 말을 전혀 듣지 않고 차가 미끄러지기 때문에 매우 위험한 상황에 빠진다.

밥을 먹고 있는데, 식탁 표면에 물이 흘려져 있으면 그 위의 밥그릇이나 반찬 그릇이 가끔 케바케로 미끄러지고 저절로 움직이기도 한다. 그 얇은 수면 위로 설마 부력이 작용했을 리는 없지만 지면 정지 마찰력이 극도로 작아지긴 한 것 같다. 그걸 보고서는 "아! 빗길에서 그 무거운 자동차가 미끄러지는 것도 바로 이런 원리이겠구나" 하는 생각이 들었다. 난 딱히 난폭운전을 하지 않아서 그런지 빗길에서는 차가 물의 저항 때문에 더 잘 안 나아가면 안 나아가지, 딱히 미끄러지거나 한 적은 없었던 것 같다.

일상생활에서 뭔가 도구 차원에서 접지력을 향상시켜서 미끄러짐을 방지하기 위해서는 스노우 타이어와 체인(자동차), 아이젠(등산) 같은 게 쓰인다. 그러고 보니 유리병 뚜껑 같은 게 너무 조여져 있어서 안 따지고 손으로 돌려도 손만 미끄러질 때도, 옷이나 헝겊류를 씌우고 그걸 돌리면 뚜껑이 돌아가서 열리는 경우가 생긴다. 이건 병따개나 손톱깎이처럼 지레의 원리로 토크를 키운 게 아니라, 순전히 접지력을 올리는 좋은 예이다. 회전력만 세다고 해서 장땡이 아니다.

자동차는 밥그릇과 비교했을 때 다소 길쭉한(?) 외형이고, 스스로 굉장한 고속으로 움직이기도 있기도 하다. 그렇기 때문에 진행 방향 기준으로 앞뒤의 무게 분배의 균형도 꽤 중요하다.
핸들을 꺾었는데 미끄러져서 차체가 운전자의 기대보다 더 큰 반경으로 돌게 됐다. 그래도 차가 앞뒤 방향이 유지라도 되면 그건 '언더스티어' 성향이다. 그 반면, 조향 과정에서 차의 뒷부분이 원심력을 감당 못 해 드리프트 하듯이 홱 도는 것은 '오버스티어' 성향이다.

묘기· 곡예 운전을 하려면 이런 차의 특성을 잘 알아야 한다. 갑자기 튀어나온 차량을 피하러 핸들을 갑자기 꺾다가 차의 뒷부분이 덜렁덜렁 요동치는 걸 피시테일(fish tail) 현상이라고 하는데.. 이건 일종의 언더스티어 성향으로 봐야 하나 모르겠다. 흔한 통념과는 달리, 딱히 전륜구동이냐 후륜구동이냐를 가리지는 않는다. 엔진이 실린 앞부분이 더 무거운 자동차라면 언제든 발생할 수 있다.

피시테일 현상에서 벗어나려면 마치 급발진에 대처할 때와 마찬가지로 당장의 직감과는 어긋나는 방식으로 자동차를 조작해야 한다. 브레이크를 밟을 게 아니라 오히려 가속을 해야 한다. 그래야 무게중심이 뒤로 쏠리면서 차량의 뒷부분이 무게를 얻고 불안정한 진동을 멈추기 때문이다. 커브를 돌 때 감속이 아니라 오히려 가속을 하듯이 말이다.

이런 식으로, 자동차의 주행에는 연료를 연소시켜서 그 폭발력으로 바퀴를 굴리기까지 전반적인 과정이 비선형적이고 정량적으로 기술하기 어려운 요소가 많다. 무슨 우주 공간처럼 마찰이고 공기 저항이고 다 없고, 그저 연료를 뒤로 분사해서 곧이곧대로 작용· 반작용대로만 나아가는 거라면 기술하기 참 쉽겠지만 현실은 그렇지 않다는 얘기이다. 타이어의 접지력이라든가, 공기 저항 같은 건 최하 대학에서 기계공학 학부나 대학원 수준이 돼야 다뤄질 것이다.

단적인 예로, 자전거만 해도 차체가 너무 무거우면 처음에 출발할 때 페달을 밟는 게 아니라 그냥 발로 땅을 뒤로 차고 나아가는 게 덜 힘들지 않은가? 그런 게 무슨 원리로 왜 발생하는 차이인지가 단순 경험적인 직감이 아니라 수식으로 아직 좀 알쏭달쏭하다. 완전히 이해를 못 했다.

타이어가 평소에 그렇게도 좋은 승차감을 선사하지만, 바람이 빠지면 완전히 다른 물질로 바뀐 게 아닌가 싶을 정도로 차체를 안 나아가게 만든다. 공기의 있고 없고 차이가 무슨 역학적인 차이를 만들어 내는 걸까?
더 나아가 차체의 무게와 엔진 종류, 배기량, 기어비가 주어졌을 때 그 차의 경제 속도나 최적 연비,  등판능력 한계를 구하는 근거도 내가 이해 가능한 한도까지 알아 가고 싶다.

7. ABS

자동차가 바퀴가 굴러가는 속도(A)와 차체가 움직이는 속도(B)가 일치하지 않게 돼서 좋을 건 전혀 없다. A>B인 건 바퀴가 헛도는 것이고, A<B인 건(심지어 A=0일 수도..) 미끄러지는 것이다. 미끄러지는 현상을 차량 전체의 관점에서는 skid라고 표현하고, 타이어의 관점에서는 잠김(lock)이라고 표현하는가 보다.

ABS란 제동력 자체가 아니라 접지력 향상을 위해서 고안된 안전 장치이다. 수십 년 전까지만 해도 고급차에만 존재하던 값비싼 선택사양이었으나, 2010년대 이후부터는 경차에도 의무적으로 달리는 모든 차들의 필수품이 된 지 오래이다.

얘는 브레이크를 기계의 힘으로 넣었다 끊기를 반복함으로써 접지력의 향상을 도모한다. 즉, 시속 100km 상태에서 150m를 더 나아가야 멈춰설 것을 120m 만에 멈추게 해 주는 게 아니다. 미끄러운 빗길· 빙판길 커브에서 브레이크를 꾸욱 깊게 밟았을 때 차가 전방을 향해 쫘악 미끄러져서 길을 이탈하는 게 아니라, 제동 거리가 얼마가 나오건 커브 틀면서 원래 성능대로 곱게 멈춰서는 것 자체를 도와준다는 뜻이다. 먼저 바퀴가 땅에 제대로 붙어 있어야 그 다음에 핸들이고 브레이크고가 말을 들을 것이기 때문이다.

위의 사진은 ABS가 하는 일을 정확하게 묘사하고 있다. 정말 센스 대박이다~!! ㅋㅋㅋㅋㅋ 한눈에 바로 이해된다.
노면이 미끄러워서 바퀴가 잠기는 현상이 감지되면, ABS는 운전자의 브레이크 동작을 기계적으로 수 차례의 브레이크 밟기+떼기 트레몰로로 구현해 준다. ABS는 anti-lock brake system의 약자이다만, 각종 프로그래밍 언어에서는 절대값을 구하는 함수의 명칭으로 훨씬 더 많이 알려져 있다..;;

굳이 빗길이나 빙판이 아니어도, 고속 주행 중에 그야말로 강한 관성이 느껴지고 타이어의 스키드 자국이 생길 정도로 브레이크를 강하고 깊게 밟으면 ABS가 발동된다. 스키드 자국이라는 게 타이어가 멈춘 채로 차체가 움직여서 타이어가 길바닥에 질질 긁혔다는 뜻이니 말이다.

이때 브레이크를 밟는 발에서 부르르르~ 떨림이 느껴질 것이다. 트레몰로가 연주되었다는 흔적이다. 브레이크를 사뿐히 즈려밟고 부드럽게 정지하는 평상시에는 ABS의 존재를 체험할 일이 없다.
사실, 오늘날은 ABS는 차체 자세 제어 장치(현대 자동차에서 사용하는 용어는 VDC)라는 최첨단 주행 안전 시스템의 일원, 구성원이 되어 있다. 자동차가 운전자가 의도했던 대로 움직이고 있는지, 아니면 미끄러지는 중인지, 어느 방향으로 무슨 가속도가 작용하고 있는지를 몽땅 파악해서 타이어별로 서로 다르게 구동력/제동력을 공급해 주는 경지에까지 도달해 있다.

본인도 옛날에 눈이 내리고 얼어서 빙판이 된 '오르막' 비탈길을 차를 몰고 오른 적이 있었는데... 뭔가 미끄러지겠다 싶은 상황에서 차가 미끄러지지는 않고 그 대신 부르르르~ 떨면서 계기판에는 생전에 본 적이 없는 경고등이 잠깐 켜졌다가 꺼지는 걸 봤다. 나중에 알고 보니 그건 VDC가 동작한 것이었고, 떨림은 VDC의 명령을 따라 ABS가 발동된 흔적이었다.

8. 맺음말: 타 교통수단의 제동 장치

(1) 지금까지 자동차 내지 자전거 위주로 브레이크 얘기를 늘어놓았다만.. 비행기의 랜딩기어 바퀴에도 브레이크가 달려 있다. 애초에 저 ABS도 맨 처음에는 젖은 활주로에 착륙할 때 미끄러지지 말라고 비행기용으로 개발되었다가 나중에 자동차와 철도 차량에도 전해진 것이다.
(여담이지만 안전벨트도 맨 처음엔 비행기를 위해서 개발된 거다. 이건 철도에는 필요 없어서 도입되지 않고 자동차에만 추가로 전해졌지만.. 처음부터 자동차를 위해서 발명된 대표적인 안전 장치로는, 금만 가지 와장창 박살나지 않는 '안전유리'가 있다.)

다만, 비행기는 지상 주행의 비중이 자동차보다 훨씬 작으며, 몇백 명이 타는 대형 여객기라 할지라도 접지 형태는 고작 '삼륜차'에 가깝다..! 그렇기 때문에 브레이크도 뒷쪽 바퀴들에만 달려 있다. 착륙 직후에는 플랩, 스포일러, 엔진 역추진처럼 공기를 직접 맞닥뜨리는 방법으로 속도를 줄이고 또 줄인 뒤에, 바퀴 제동은 기체를 완전히 세우는 결정타로만 사용된다.

비행기 조종석의 페달은 자동차의 액셀/브레이크와는 달리 양발로 조작하며 앞쪽과 뒤쪽의 부위 구분까지 있다. 발꿈치(뒤) 쪽은 비행기가 떠 있을 때 사용하는 방향타이고, 발가락(앞) 쪽은 비행기가 지상 주행 중일 때 사용하는 브레이크이다. 즉, 이륜차처럼 브레이크가 앞뒤 구분이 있는 게 아니라 좌우 구분이 있는 셈인데, 양쪽 바퀴의 제동 정도를 달리함으로써 '조향'을 할 수 있다. 무한궤도 탱크가 방향을 전환하는 것처럼 조향하긴 하지만 추력· 동력 조절이 아니라 제동력 조절이라는 차이가 있다.

(2) 전기로 달리는 차량은 차축을 발전기에다 연결해서 "기왕 제동을 걸 거면 이미 가진 운동량으로 에너지 생산이나 덤으로 하면서 서자"라는 발상을 실현한다. 이것도 방법이 한 가지만 있는 게 아니어서 '발전 제동'과 '회생 제동'이라는 메커니즘이 있다.

역에 정차할 때 전동기 인버터에서 나는 소리가 가속 구동음의 역순으로 주파수가 올라갔다 내려가기를 반복하는 것들이 있다. 이건 개념적으로 자동차의 단을 단계적으로 낮추는 거나 다름없는데, 일종의 엔진 브레이크이기라도 하나 하는 생각도 든다.
그나저나 1세대 KTX(떼제베)는 내부적으로 제동을 어떻게 하는지, 역에 정차할 때 여느 절도 차량에서도 들을 수 없는 시끄러운 굉음이 나는 걸로 악명 높다. 좀 개선이 필요한 점으로 보인다.

(3) 엘리베이터 중에도 한 30층 정도 되는 고층 건물에서 운행되는 초고속 엘리베이터는 브레이크가 있다. 도착층의 3~4층 전부터 이미 감속하는 게 느껴질 정도인 엘리베이터는 우리가 흔히 탈 수 있지는 않아 보인다.

Posted by 사무엘

* 예전에 썼던 글을 내용을 보충하여 리메이크 한 것이다.

1. 들어가는 말: 자전거의 브레이크부터

육해공의 모든 교통수단들은 가속 장치만 있는 게 아니라 제동 장치도 어떤 형태로든 갖추고 있다. 어찌 보면 잘 가는 것보다도 제때에 잘 서는 게 더 중요하기 때문이다.

제일 간단한 교통수단인 자전거의 경우, 19세기쯤에 자전거가 단순히 앞뒤로 배치된 바퀴 둘에다 안장 달린 수레에 불과했던 시절에는 페달이나 체인뿐만 아니라 브레이크도 없었다. 땅을 발로 차서 가속하고, 제동도 발바닥으로 땅을 끌어서 했다. 굉장히 원시적이었고 신발에 무리를 많이 줬을-_-;; 것 같은데, 페달이 발명된 것과 비슷한 맥락으로 브레이크도 응당 도입되었다.

이륜차의 브레이크는 잘 알다시피 양손 핸들에 두 개가 달려 있어서 각각 앞바퀴와 뒷바퀴에 대응한다. 자전거 정도야 림(rim) 방식이라고 타이어의 금속 테 부분에다가 브레이크 패드를 압박해서 제동을 거는 간단한 방식이 많이 쓰인다. 그러나 접촉 부위가 물이나 흙먼지 등으로 오염되면 제동력이 쉽게 떨어진다는 단점도 있다.

림 브레이크는 앞바퀴에서 주로 쓰이는 듯하다. 뒷바퀴는 다른 부분이 꽉 조여지면서 제동이 걸리는데 이건 무슨 방식이라 불리는지 잘 모르겠다.
고속 주행용 고급 자전거에는 크기만 더 작을 뿐 자동차의 것과 별 차이 없는 정교한 디스크 브레이크가 달려 있기도 하나, 너무 고퀄인 브레이크는 비싸고 무엇보다도 차체를 무겁게 한다는 단점도 있다는 걸 감안할 필요가 있다. (자전거는 사람의 힘으로 움직이는 만큼, 최대한 가벼워야 한다.)

평소에 서서히 멈춰설 때에야 취향대로 쥐기 편한 쪽의 브레이크만 편파적으로 써도 된다. 하지만 급제동을 걸 때는 편파적인 제동이 위험하다. 특히 자전거 같은 가벼운 이륜차는 뒷바퀴보다도 앞바퀴 급제동이 더 위험하다. 뒤쪽이 관성을 이기지 못하고 확 들려 올라가면서 운전자를 앞으로 패대기(...)치기 때문이다.

이런 이유로 인해 자전거는 오른손 브레이크가 앞바퀴이고 왼손이 뒷바퀴이던 것이, 2010년경부터는 방향이 바뀌어 오른손이 뒷바퀴와 연결되게 되었다. 사람들이 위급한 상황에서는 왼손보다 오른손 브레이크를 반사적으로 꽉 잡는 편인데, 그걸로 앞바퀴를 붙잡으니 더 위험한 경우가 많았기 때문이다. 비슷한 시기인 2009년쯤에 보행자의 통행 방향이 오랜 좌측통행 관행을 깨고 우측으로 바뀐 것과 비슷한 맥락으로, 이륜차에도 단절적인 변화가 추가된 셈이다.

2. 자동차의 브레이크 -- 제동력 전달: 브레이크액(소형차) 방식과 공기압(대형차)

다음으로 자동차의 브레이크는 사람의 누르거나 밟는 힘으로 감당하기란 택도 안 되게 무거우면서 또 넘사벽급으로 빠르게 운동하는 기계를 신속하게 세워야 한다. 그렇기 때문에 구조가 더 복잡하다.

자동차에 가속 구동축은 일반적으로 앞바퀴나 뒷바퀴 중 한 곳에만 있다. 모든 바퀴가 구동축인 차량은 오르막과 험지 주행 성능을 매우 중요시한 군용차나 일부 SUV 정도밖에 없다. 그러나 브레이크는 어떤 자동차라도 반드시 모든 바퀴에 달려 있다. 급제동을 편파적으로만 했다간 사륜 자동차도 옆으로 홱 돌아가는 등 이륜차만큼이나 큰 위험에 빠지기 때문이다.

그런데, 자동차는 한 페달만 밟아도 이 모든 바퀴가 동등(일단은..)하게 제동이 걸리는 게 일면 신기하게 느껴지지 않는가? 이건 브레이크액(소형차의 유압-배력 방식)이나 압축 공기(대형 트럭· 버스의 에어 방식) 같은 유체의 유압을 이용해 (1) 페달 밟는 힘을 각 바퀴의 모든 브레이크에 동시에 분산해서 전하기 때문이다. 엔진의 동력을 두 바퀴에 분산 전달하는 용도로는 차동 기어 같은 톱니바퀴가 쓰이는 반면, 브레이크에서는 저런 메커니즘이 쓰인다.

그리고 차량용 브레이크에는 어떤 형태로든 '엔진의 출력'을 동원하여 (2) 사람이 페달을 밟은 힘을 증폭시켜서 더 큰 제동력이 전해지게 하는 장치가 있다. 핸들의 파워스티어링에만 증폭 장치가 있는 게 아니며, 사실은 브레이크의 증폭 장치가 더 중요하다. 유압-배력 브레이크에는 엔진 압축 행정 과정에서 생기는 진공을 이용한 브레이크 부스터가 있고, 에어 브레이크는 아예 엔진 출력을 바탕으로 동작하는 압축 공기 챔버가 따로 있다.

그러니 자동차의 브레이크는 시동이 꺼지고 나면 마치 오르간 악기처럼 진공압 또는 공기압이 남아 있는 동안만 동작한다. 그게 다 빠진 뒤에는 브레이크 페달이 아예 밟히지 않는다. 급발진 폭주가 시작됐다고 해서 무작정 시동을 꺼 버렸다면 그 뒤부터는 핸들 잠기지, 브레이크도 동작 원천이 더 보충되지 않아서 일회용 시한부 인생이 되었음을 알고 유의해야 한다. 언제든지 잡을 수 있는 자전거 브레이크 같은 걸 생각해서는 안 된다.

엔진 동력에 의존하는 브레이크 말고, 차 시동이 꺼진 뒤에 멈춰 선 차를 미끄러지지 않게 고정하는 브레이크는 주차 브레이크라고 따로 있다. 요건 보통 뒷바퀴에만 달려 있는 편인데, 주행 중에 얘를 급하게 당겨서 차를 감속하거나 세우면 역시나 편파적인 제동으로 인해 차가 돌아가 버릴 위험이 있다. 그래도 차라리 뒷바퀴를 붙잡지 앞바퀴를 붙잡는 건 더 위험한 듯하다.

3. 베이퍼 락과 페이드

자동차의 엔진은 연료의 연소와 폭발로 인해 지속적으로 열을 받으며, 이거 조절을 위해서는 라디에이터와 냉각수 같은 냉각 계통이 반드시 필요하다.
한편으로 브레이크는 제동 과정에서 자기 패드와 로터 사이의 마찰로 인해 열을 받는다. (타이어와 지면 사이의 마찰열은 또 별개의 문제) 두 손바닥만 살살 비벼도 열이 나는데, 그 무겁고 빠른 자동차를 세우는 과정에서 열이 안 날 수가 없다.

그런데 더운 날씨에 급커브 내리막에서 짧은 시간 동안 브레이크를 수십 회 이상 너무 자주 깊게 오래 밟으면 브레이크 패드가 달아오르고 과열된다. 그래서 접촉면의 마찰이 작아지고 미끌미끌해져서 "브레이크를 밟았는데 왜 서지를 못하니" 상태가 돼 버린다. 이것을 페이드(fade) 현상이라고 한다.

이보다 상태가 더 나빠지면 유압-배력식 브레이크의 경우, 브레이크액 자체가 섭씨 300도를 넘나드는 온도를 견디지 못하고 부글부글 거품이 일고 기화해 버린다. 그래서 운전자가 브레이크를 밟아도 기화된 브레이크액이 스스로 압축되어 운동량을 흡수하고, 지시가 브레이크로 가지 않는다.
브레이크 페달은 밟는 대로 쑤욱 밟혀 들어가는데, 제동은 전혀 걸리지 않게 된다! 이것을 베이퍼 락(vapor lock) 현상이라고 한다.

베이퍼 락과 페이드는 원인은 비슷하지만 성격이 다르다. 페이드는 브레이크가 정상 작동했는데도 제동력이 떨어지는 것이고, 베이퍼 락은 애초에 밟아도 제동 명령 자체가 인식되지 않는 것이다.

브레이크액은 꼭 저렇게 혹사당하지 않았더라도 시간이 흐르면서 차츰 변질되고, 수분이 섞이면서 끓는점이 점점 낮아진다(= 베이퍼 락이 더 쉽게 발생하게 됨). 그렇기 때문에 엔진 오일만치 자주는 아니어도 일정 주기로 교환이 필요하다.
냉각수는 혹한기에도 얼지 않아야 하며 브레이크액은 끓지 않아야 하니, 자동차에 들어가는 액체는 어떤 온도에서도 액체 상태가 유지되는 게 중요하다는 것을 알 수 있다.

에어 브레이크 기반인 대형 차량들은 베이퍼 락 현상이 존재하지 않는다. 디젤 엔진에 점화 플러그가 없듯, 에어 브레이크에는 브레이크액이란 게 존재하지 않는다. 에어 브레이크는 베이퍼 락 없고 제동력을 전하는 성능도 탁월하지만, 더 비싸고 큰 부품이 필요하고 압축 공기의 비축을 위해서도 엔진 출력이 상시 소모되기 때문에 천상 대형 차량용이다. (에어컨도 냉매 컴프레셔에서 전기든 엔진 출력이든 에너지 소모가 제일 많다는 점을 생각해 보자)

버스를 타 보면, 신호대기로 인해 정지했을 때 기사 아저씨가 무슨 스위치를 조작하고 차에서는 "축~ / 취익!" 이렇게 공기 빠지는 것 같은 소리가 나는 걸 볼 수 있다. (문을 여닫을 때도 비슷한 공기 빠지는 소리가 나지만, 아직 문도 열리기 전이고 멈춘 직후에)
그건 그 잠깐 서 있는 동안에도 주차 브레이크를 채우는 소리이다. 버스는 주차 브레이크도 공기압 방식이기 때문이다.

에어 브레이크를 사용하는 대형 버스· 트럭의 계기판을 보면 승용차에는 없는 '공기압' 계기가 있다. 이건 타이어의 공기압이 아니라 에어 브레이크에 비축된 공기압을 나타낸다. 주행을 하다 보면 압력이 올라가고, 엔진 회전수가 높을수록 더 빠르게 올라간다. 그 반면, 빡세게 브레이크를 자주 밟다 보면 압력이 감소하여 바늘이 왼쪽으로 돌아간다.

쉽게 말해 이건 이 차량의 제동력의 비축 상태를 나타내는 것이나 마찬가지이기 때문에 속도계· 연료계· 냉각수 온도계에 준하는 매우 크리티컬한 계기이다. 타코미터가 오른쪽 끝(지나친 고회전)에 레드존이 있다면, 공기압계는 마치 연료계처럼 왼쪽(고갈..)이 레드존이다. 굉장히 흥미로운 특성으로 보인다.

4. 자동차의 브레이크 -- 제동 방식: 디스크와 드럼

브레이크는 제동력 전달과 증폭 방식에서는 저렇게 유압-배력 방식과 에어 방식으로 나뉘고, 실제로 바퀴를 붙들어 물리적인 제동을 거는 방식에서는 디스크 방식과 드럼 방식이 나뉜다. 차축 주변에 크고 반들반들 윤기 나는 금속 원판이 보이고 타이어 휠의 비주얼도 그걸 다 노출하는 형태이면 디스크 브레이크이고, 그냥 꽹과리 내지 솥뚜껑 같은 작고 납작한 금속판만 보이면 드럼 브레이크이다. 그래서 옛날 차들과 요즘 차들은 휠의 디자인 트렌드도 차이가 난다.

옛날에는 대부분의 자동차들이 앞바퀴는 디스크, 뒷바퀴는 드럼 방식 브레이크를 썼다. 그러나 오늘날은 어지간한 승용차들은 100% 디스크이고, 경차 또는 반대로 트럭· 버스 같은 대형차들은 뒷바퀴 드럼을 고수하는 중이다. 드럼 방식은 디스크보다 가격 대 제동성능이 더 좋지만, 폐쇄적인 구조로 인해 과열 위험(= 페이드 현상)이 더 높다는 단점이 있다.

유독 대형차들이 언덕길에서 갑자기 브레이크가 고장 나서 사고를 내는 빈도가 더 잦은 건 (1) 근본적으로 차가 워낙 크고 무거워서, (2) 워낙 저렴하게 혹사당하는 상용차이다 보니 주행 거리가 매우 길고 과적· 차량 노후· 정비 불량 등의 위험이 있어서 외에도 (3) 드럼 브레이크라는 점도 적지 않게 작용한다. 그러니 한여름에 긴 내리막을 조심스럽게 주행할 때에는 자꾸 페달만 밟지 말고 엔진 브레이크 같은 다른 보조 제동 방법도 적극 활용해야 한다.

Posted by 사무엘

요즘은 좀 덜해진 감이 있지만 한때 마소에서는 자사의 운영체제인 Windows에 단순히 기술과 기능뿐만 아니라 감성을 담으려고 애쓰곤 했다. 애플 진영만 감성 마케팅을 한 게 아니라는 얘기이다.
이쪽으로 굉장히 신경을 많이 썼던 때는 크게 세 시즌으로 나뉜다. (1) 95, (2) XP, 그리고 그 다음 (3) Vista 정도 되겠다.

Windows 95는 그야말로 마소의 Windows 개발 역사상 가장 큰 격변을 이룬 작품이었다.
그러니 3.1 시절의 너무 식상했던 tada.wav를 대신하여, 참신하고 세련되고 오픈되고 모던한 이미지를 표현할 수 있게, Windows 95 부팅이 마치 미래로 가는 창문을 열어젖히기라도 한 인상을 줄 수 있는.. 그런 시작음을 외주를 줘서 개발하게 되었다.

그 유명한 "또르릉~ 띵~ 띵.." 95의 시작음을 작곡한 사람은 Brian Eno이다. 파일 이름부터가 참 거창하게 The Microsoft Sound였다.
다만, 정작 그 작곡자는 DOS고 Windows고 전혀 사용하지 않는 골수 Mac 유저였다는 것이 훗날 당사자의 회고 인터뷰를 통해 알려지기도 했다.;;

Windows 95는 누구나 듣는 시작음뿐만 아니라, 소수의 매니아만이 열어 보는 이스터 에그 화면에다가도 고유한 음악을 집어넣었다. 여기에 들어간 음악이 바로 그 유명한 Clouds이다. 이거 작곡자는 Brian Orr이니 또 다른 Brian이다. 단, 이건 길이와 용량 관계상 wav가 아니라 mid 포맷이다.

저 작곡자가 회고하기를, 작곡을 의뢰받을 때 컨셉으로 받은 키워드가 clouds, floating, peaceful이었다고 한다. Windows 95는 부팅 스플래시 화면부터가 파란 창공과 구름이었으니까..;; 그래서 그 컨셉에 맞게 멜로디를 써 넣은 결과물이 저 음악이라고 한다.
여느 음악 예제들과 마찬가지로 Windows\media 디렉터리에 있었다고는 하지만 본인은 얘는 Windows 95가 실제로 사용되던 시절에 PC에서 찾아서 들어 보지 못했다.

저거 이후로 마소의 제품에서 이스터 에그 재생 중에 그럴싸한 음악이 나온 경우는 Visual Basic 5~6의 이스터 에그가 유일했던 듯하다. 공교롭게도 저 이스터 에그도 파란 창공을 배경으로 정육면체 상자 4개가 뱅글뱅글 돌아가고 그 배경 위로 개발자 명단이 스크롤 되어 올라간다.

물론 이스터 에그라는 것도 2002년 이후로는 마소의 제품에서는 싹 자취를 감춰서 볼 수 없게 됐지만 말이다.
우리나라 지하철에다 비유하자면, 처음에 인테리어가 좀 독특하게 꾸며졌던 역들이 모두 안전을 이유로 스크린도어로 뒤덮이고 불연재 재질로 교체되어 미관이 예전보다 안 좋게 바뀐 것과 비슷해 보인다. 뭐 아무튼..

Windows NT 4라든가 98~ME 사이에서는 전자 악기 기반의 시작음들이 많이 쓰였으며 특히 chimes, chord, ding 같은 메시지 비프음도 다시 만들어졌다. 이것들은 다른 아티스트들의 작품이다.

그러다가 Windows XP는 프로그램의 시청각 요소가 완전히 쇄신했다. 이제 PC의 속도와 메모리가 충분해진 덕분에 9x 계열 커널이 수명을 다할 때가 됐고, 그리고 64비트와 멀티코어 CPU도 등장하다 보니 하드웨어가 큰 변화를 겪을 시기였다. 이 시기에 맞춰 마소에서는 OOBE (out-of-box experience)라는 말까지 만들어 내면서 새 운영체제로 '사용자에게 새롭고 특별한 경험을 선사하자'에 목숨을 걸었다. 굳이 Windows 2002 대신 XP라는 브랜드명까지 만들면서 말이다.

일단 피아노 소리 위주인 시작음, 비프음들은 다 Bill Brown이라는 작곡가가 작곡하고 오케스트라를 동원해서 연주했다. 그리고 (1) Tour를 실행했을 때 나오는 고퀄의 배경 음악들도 이 사람의 작품이다. 시퍼런 Luna 테마와 풀밭 사진뿐만 아니라 음악도 Windows XP를 뭔가 종합 예술 작품 같은 인상을 심어 주는 요인이다.

사실, Windows XP는 애초에 설치를 하다가 작업이 마무리되고 비디오/사운드 카드가 자동으로 잡히고 나면 간단한 애니메이션과 함께 (2) 몽환적인 분위기의 intro 음악이 나온다. 길이도 무려 5분 24초나 된다. 이걸 듣고서 강렬한 인상을 받은 사람이 많았을 것이다.

그런데 이 유명한 음악의 작곡자는 의외로 Bill Brown이 아니며, 정확하게 알려져 있지 않다. 인터넷 상으로는 Brian Eno가 작곡했다는 말이 많지만 저 사람은 공식적으로는 Windows 95 로고송 이후로 딱히 마소와 다시 작곡과 관련된 계약을 맺은 내역이 없다.

Susan Ciani라는 미국의 여성 작곡자를 지목하는 곳도 있으나, 이 역시 정확한 출처나 근거가 부족하다. 이 곡은 Windows XP의 정체성 그 자체로서 Tour 음악과 쌍벽을 이룬다고 해도 과언이 아닌데, 작곡자가 공식적으로 미상인 것이 무척 미심쩍게 여겨진다.

그 뒤, Windows Vista부터 도입된 "따단 따단" 그 4개 음표짜리 전자음 멜로디는 Robert Fripp이라는 사람이 작곡한 것으로 알려져 있다. 이때 이후로 마소에서는 운영체제의 음악에 큰 신경을 쓰지 않고 있다.
옛날에는 사용자가 선택한 테마에 따라 GUI의 색상과 글꼴, 각종 사운드가 싹 달라지게 하는 게 유행이었고 애초에 Windows와 Office, Visual Studio 제품들도 버전이 바뀔 때마다 프로그램 외형과 색상도 같이 바뀌던 시절이 있었거늘, 그마저도 2010년대 이후로는 약발이 다한 모양이다.

시작음처럼 운영체제나 프로그램의 구동과 함께 연주되는 음악 말고.. Windows\media 디렉터리에 예제로 제공되는 음악들도 버전별로 바뀌어 왔다.
Windows 3.1 시절에는 canyon과 passport라는 이름의 mid 파일이 있었다. 95와 그 이후까지 존속했는지는 기억이 확실치 않다.

98/2000쯤에는 '엘리제를 위하여'를 포함해 뜬금없이 클래식 음악의 미디 파일이 갑자기 쭈욱 추가되었던 걸로 본인은 기억하는데, 후대 버전에서는 몽땅 다시 사라졌다.
그 대신 ME와 XP에서는 그 당시의 최신 외국 가요 음반에서 발취한 샘플 wma 한두 곡이 잠시 들어갔다. 미디로는 town, flourish, onestop이 들어가서 오늘날 Windows 10에까지 전해져 내려오고 있다.

특히 onestop의 경우 마치 음악계의 the quick brown fox jumps over the lazy dog처럼.. 미디에 정의되어 있는 모든 악기들을 일부러 모두 동원하는 형태로 만들어졌으며, 구간별로 분위기가 오락가락 하면서 굉장히 괴랄한 흐름과 중독성을 자랑한다.
뭔가 RPG 게임의 BGM 같기도 하고.. "이 음악 들으니 문득 집 앞 편의점까지 희망찬 모험을 떠나고 싶어졌어!" 뭐 이런 말이 나올 정도라고 한다..;;

Posted by 사무엘

0. 들어가는 말

날개셋 한글 입력기 9.3이 나온 지 벌써 50일 가까이 지났다.
올해 초, 이걸 만들던 당시에는 정말 머리를 쥐어뜯으면서 힘든 나날을 보냈다. '조합 안에 조합 생성', '조합과 후보 자동 완성' 같은 새로운 입력 도구들을 세세한 외형부터 시작해서 이들이 내부에서 입력 엔진과 통신하는 인터페이스를 완전 무에서 처음 창조해 내야 했으니 말이다.

단순히 당장 기능이 동작만 하게 만드는 게 아니라, 앞으로 두고두고 후회가 없을 정도로 최상의 성능과 최적의 확장 가능성을 현실적으로 잘 절충하여 구현한 거라고 개인적으로 확신을 갖는 것이 매우 어렵고 힘든 일이었다.
하지만 다 만들어 버리고 나니 언제 힘든 일이 있었냐는 듯 아무렇지도 않고 세상은 그저 평온하기만 하다.

본인은 2010년대 이래로 현재, 날개셋 한글 입력기의 개발 todo list의 분량이 역대 최저인 시기를 살고 있다. 그만치 마음의 부담을 많이 덜었다.
하지만 대단원을 장식할 그 마지막 기능을 과연 어떻게 설계하고 구현할지가 만만찮은 상태이고, '저것까지만 다 만들어 놓으면 뭐 어떻게 되겠지' 그렇게 생각하던 당시와 비교했을 때 세상이나 내 상태가 그렇게 확 달라진 것 같지는 않다. 이건 당연한 귀결인 건가..;; 아무튼.. 개발 근황 소식을 전하도록 하겠다.

1. 24픽셀 글꼴 추가

날개셋 한글 입력기는 지난 9.0 버전부터 150% (144dpi) 이상의 화면 확대 배율에서 24픽셀 비트맵을 지원하기 시작했다.
이건 굉장히 뜻깊은 과업이었으나, 24픽셀은 16픽셀에 비해 글꼴이 훨씬 적고 부족하다는 게 못내 아쉬움으로 남았다. 옛날에는 이게 화면용이 아니라 도트 프린터 인쇄용 크기였기 때문이다.

그랬는데.. 이때 본인의 머리를 스친 것은 1990년대에 PC 통신을 통해 한창 굴러다니던 아래아한글용 공개 글꼴들이었다. 이런 것들은 비록 비트맵이지만 문서에다 넣고 인쇄도 할 목적으로 쓰이므로 24픽셀, 그리고 심지어 레이저용 40픽셀 글립까지 있다. 내가 이것들 생각을 왜 지금까지 못 했을까?

본인도 중학교 시절까지는 글꼴에 완전 꽂혀서 수십여 종의 공개 글꼴들을 받아서 쓴 적이 있었다. 전문 업체에서 만든 글꼴의 퀄리티에 비할 바는 못 되었지만 저마다 개성이 담겨 있었다.
이것들은 아래아한글 1.0 ~ 1.2 시절, 비트맵 글꼴 에디터가 있던 시절에 근성의 도트 노가다를 통해 만들어진 물건이었다.

2.x도 아니고 1.5쯤 되면서 아래아한글은 자체적으로 조합 로직을 정의할 수 있는 한글 글꼴 포맷까지 제정했으나, 정작 예전처럼 사용자가 고정된 조합 로직 틀에서라도 한글 글꼴을 customize할 수 있는 통로는 완전히 막아 버렸다.
그리고 1.5, 그리고 2.0까지만 해도 보급 글꼴 말고 새로운 글꼴을 구해다 쓰는 건 마치 Doom 2에서 custom WAD 맵을 얹어서 플레이 하는 것만큼이나 번거롭고 귀찮고 어려웠다.

그때까지만 해도 아래아한글은 새로운 외부 글꼴을 등록해서 쓰는 것을 고려하여 설계되지 않았으며, 심지어 글꼴 파일 내부에 자기 이름이나 제조사 같은 메타정보도 들어있지 않았었다. 2.0 전문용에서 첫 도입됐던 한양 시스템의 윤곽선 글꼴조차도 말이다. 그 파일들은 나 같은 사람이 내부 포맷 분석에도 금세 성공했을 정도로 그냥 무식한 벡터 이미지 덩어리 그 이상도 이하도 아니었다.

그 와중에 과거에 만들어졌던 싸제 한글 비트맵 글꼴을 쓸 수 없어서 현기증 난다는 사용자들의 원성이 빗발치자.. 한컴에서는 이미 만들어진 글꼴들을 아래아한글 2.x 같은 후대 버전에서 사용할 수 있게 간단한 파일 포맷 변환 유틸 정도나 만들어서 던져 줬을 뿐이었다.

이렇게 상황이 열악하다가 그나마 1993년에 출시된 아래아한글 2.1은 잘 알다시피 통합 글꼴 포맷을 최초로 도입하고 글꼴 시스템 전용 환경설정 프로그램(fontcfg)까지 도입하면서 이 바닥 시스템이 크게 개선되었다. 뭐, 과거 회상은 이 정도까지 하기로 하고..

본인은 아래아한글이 제공했던 모든 HFT 폰트 파일들을 지금도 갖고 있지만, 그 시절에 추가로 받아서 썼던 공개 글꼴들은.. 너무 옛날 것이어서 그런지 컴퓨터가 바뀌는 과정에서 소실된 듯했다. 남아 있는 게 없었다.
그래도 인터넷 각지에 있는 고전 프로그램 자료실을 뒤진 끝에.. 현재까지 날개셋에 16픽셀로만 존재하던 다음 글꼴의 24픽셀 버전을 구해서 추출하는 데 성공했다. 굽은샘물, 손글씨, 타자기, 파도.. 4종이다.

특히 '손글씨'는 16픽셀에서는 획이 거칠고 별로 보기 좋지 않은데 24픽셀이 훨씬 더 보기 좋다.
굽은샘물은 언뜻 보기에는 예쁘게 생겼지만 '게'와 '계'가 분간되지 않는 등 결함이 몇 군데 있다. 그런데 24픽셀에서도 완전히 똑같은 결함이 남아 있다는 게 아쉬운 점이다.

명조 고딕, 거기에 기껏해야 필기체 일색이던 시절보다 글꼴 부족 문제가 좀 개선됐으면 좋겠다.
뭐, 한글뿐만 아니라 영문 글꼴도 아주 부족하긴 하지만.. 이건 더 답이 없는 문제인 듯하다.

2. 글꼴들의 내부 구조 최적화

그리고, 이렇게 글꼴 관련 작업을 하는 과정에서.. 내부적으로 조합형 한글 글꼴(*.hfn) 파일을 생성할 때 사용하는 빌드 툴을 대대적으로 손질하여 다시 만들었다. 그리고 꼼꼼한 최적화 기능을 추가했다.

최적화라는 게 무슨 말인가 하면...
샘물· 타자기 같은 글꼴들은 벌수가 적고 내부 구조가 굉장히 간단하다. 하지만 8*4*4 도깨비처럼 기존의 범용적인 조합 로직에 끼워 맞춰 글꼴을 만들다 보면 결국 같은 모양의 글자를 여러 벌에서 쓰도록 복붙을 해야 하고 중복 정보가 발생하게 된다.

먼 옛날, 날개셋 한글 입력기 5.3과 함께 본인이 처음으로 작성한 hfn 생성 툴은 사용자가 작성해 준 스크립트대로 곧이곧대로만 파일을 만들었다. 하지만 다음 버전에 들어가는 hfn 파일들은 크기가 약간이나마 더 작아져 있을 것이다.

 물론 지금 제공되고 있는 샘물 계열 글꼴들은 이미 손으로 직접 최적화한 굉장히 단순한 조합 로직 기반이기 때문에 16픽셀용이 크기가 4~5KB 남짓에 불과할 정도로 작다.
그런데 수동으로 최적화하면서 지금까지 생각하지 못했던 것이 바로.. 종성 그룹을 굳이 받침이 있는 경우와 없는 경우로 분류할 필요가 없다는 것이었다. 샘물 계열은 그 정의상 애초에 그거 구분이 필요하지 않은 글꼴이니까 말이다.

바로 이런 헛점을 프로그램이 추가적으로 찾아 줬기 때문에 종성의 그룹 수가 하나 더 줄어들었다. (group size → group reduced to)

아래아한글이 옛날에 제공하던 '가는샘물'과 '필기'는 나름 자체적인 조합 로직을 갖추고 있는 파일이다. 그럼에도 불구하고 최적화 검사를 해 보니 사용하지 않는 자모 그룹, 중복되는 벌이 존재하여 파일 크기를 몇백 바이트나마 더 줄일 수 있었다(16픽셀 버전 기준). 물론 겉으로 드러나는 글자 출력 모습은 하나도 변함없고 말이다.

2000년대 중반에 마소에서 Office Plus pack을 통해 제공했던 옛한글 글꼴은 일단 6*2*4벌 구조이다. 하지만 굴림과 바탕 말고 돋움과 궁서는 시간에 쫓겨서 대충 만들었는지 종성의 벌수가 실질적으로 더 적다. 궁서는 구조적으로 아주 정교한 글꼴인데도 종성이 두 벌로밖에 이뤄지지 않았으니 왠지 엉성해 보일 수밖에 없을 것이다. (날개셋 한글 입력기에 포함돼 있지는 않음)

아래아한글이 제공하던 24픽셀 명조도.. 중성의 벌수가 10개이던 것이 9개로 더 줄어들었다.
오히려 화면용 16픽셀 명조는 11개인데.. 더 큼직한 공간에서 더 미려하게 만들어야 할 인쇄용 글꼴이 미세하게나마 구조가 더 단순한 것을 알 수 있었다.

이건 뭐.. 최적화 기능을 구현하면서 테스트 용으로 사용했던 극단적인 예제이다.
벌과 그룹 수가 최적화 결과 얼마나 드라마틱하게 줄어드는지, 한편으로 아래아한글에서 쓰이던 24픽셀용 '타자기'체가 얼마나 비효율적인 형태로 저장돼 있었는지를 알 수 있다.

그리고.. 이미 만들어져 있는 다른 글꼴 파일을 바이너리 수준에서 변환만 할 때는 신경 쓸 필요가 없지만, 순수하게 텍스트 포맷의 스크립트로부터 조합형 한글 글꼴을 빌드할 때 해결해야 하는 문제가 하나 있다.
바로, 문자열 형태의 벌 명칭을 서로 겹치지 않고 중간 공백(slack) 낭비도 없이 최대한 조밀하게 번호로 대응시키는 알고리즘이다. 모든 벌이 한 성분(초중종 중 하나)의 모든 낱자를 사용하고 있다면 신경 쓸 필요가 없지만, 여러 벌들이 듬성듬성 부분적인 낱자 그룹을 사용할 때는 문제가 복잡해진다.

이 문제는 곧이곧대로만 푼다면 시간 복잡도가 그냥 NP 완전이 된다.. =_=;; 그런데 (1) 지도에서 여러 점들의 주변에 지명을 서로 겹치지 않고 최대한 많이 적절하게 배치하기, (2) 여러 지점들의 최단 순회 경로 구하기, (3) 컴파일러의 코드 최적화 과정에서 제한된 레지스터 공간에 구간별로 주요 지역 변수들을 적절히 등재하기, (4) 수직· 수평으로만 움직일 수 있는 여러 자동차들이 좁은 부지 안에 세워져 있고 이 차를 빼기 위해서 저 차를 빼야 되고 다른 차를 원상복구 시키는 복잡한 상황에서 특정 차를 빼내는 순서 구하기 등.. 실생활에서는 이런 부류의 intractable한 휴리스틱 문제들이 의외로 많이 존재한다.

모든 벌에 대해서 그냥 심벌 테이블을 부여하고 번호가 아니라 문자열로 벌을 식별한다면 slack 걱정을 할 필요가 없긴 하다. 하지만 겨우 날개셋이 사용하는 글꼴 파일이 그런 것까지 사용할 정도로 구조가 복잡하지는 않기 때문에 그냥 숫자 기반 인덱스 체계를 채택한 것이다. 컴퓨터에서 문자열로 아이템을 식별하는 건 포인터와 동적 메모리 등.. 단순 숫자보다 성능 비용이 더 크다.

이로써 조합형 한글 글꼴 빌드 절차는 데이터 읽기 → (글립 최적화 → 조합 로직 테이블 최적화 → 명칭 순서 최적화) → 출력의 순으로 절차가 깔끔하게 완성됐다. 컴파일하는 기능뿐만 아니라, 반대로 빌드된 hfn 파일을 다시 텍스트 기반 스크립트로 환원하는 디컴파일 기능도 이 참에 넣어서 관련 기능을 완전히 끝장을 봤다.

좋은 tool이 완성됐으니, 이제 도스 시절을 풍미했던 아래아한글용 공개 비트맵 글꼴들을 애타게 기다린다. 혹시 지금까지 갖고 계시는 분들은 본인에게 제보해 주시면 좋겠다. 이제 글꼴 분석과 빌드 툴이 완벽하게 갖춰졌고 무엇이건 내 프로그램에 반영 가능하다.

3. 한글 로마자 입력기

끝으로, 10여 년째 기능에 변화가 거의 없던 한글 로마자 입력기 빠른설정에 '공업진흥청 방식'이라는 새 템플릿이 추가되었다.
이건 macOS에서 전통적으로 지원되어 온 로마자 입력 방식인데, 정작 날개셋 한글 입력기가 제공하는 기존 템플릿 5개와는 일치하는 게 없는 독자적인 입력 방식이었다.

ㅓ, ㅡ는 표준 표기법처럼 eo, eu로 입력하지만 ㅇ은 x로 입력하고 ㅚ는 oe로만 입력하며, Shift로 쌍자음을 입력하는 게 마치 여러 입력 방식을 짬뽕한 것 같다.
공진청 방식을 실제로 즐겨 사용한다는 외국인에게서 요청을 받아서 이 기회에 템플릿을 추가했다.

이로써 로마자 입력기 중에서 쌍자음을 1타(Shift도 포함)로 입력 가능한 템플릿은 북한 방식, Korean Writer 방식, 그리고 공진청 방식 이렇게 세 종류가 존재하게 됐다.
지금까지는 ㄸ, ㅉ, ㅃ가 종성에도 들어갈 수 있게 수식이 만들어졌다. 하지만 다음 버전에서는 이를 수정하여 이 낱자들은 언제나 초성에만 입력되게 할 것이다. 로마자 입력 방식이 딱히 옛한글을 염두에 둔 입력 방식은 아니기 때문이다.

4. 나머지

(1) 홈페이지에서 날개셋 한글 입력기를 소개하는 컨텐츠를 더 추가했다.
"첫 화면"에는 한국어가 아니라 한글 차원에서 연구했다는 개발 이념을 더 강조했고, "전반적인 특징"에도 기능 소개 스크린샷을 잔뜩 추가했다.
그리고 입력 도구, 빠른설정, 텍스트 필터만을 소개하는 "입력 보조 기능 소개"라는 페이지를 새로 추가했다. 내가 지금까지 이 바닥으로 참 어지간히도 많은 기능들을 꾸역꾸역 집어넣었다는 생각이 들었다.

(2) 24픽셀 상태에서 날개셋 편집기로 일본어· 중국어 IME를 사용해 보면(빈 입력 스키마), 조합 상태를 나타내는 밑줄이 여전히 16픽셀 기준으로 찍혀서 밑줄이 아니라 취소선처럼 나타나는 버그를 뒤늦게 발견했다. 9.0 이래로 지금까지 계속 이런 버그가 있었다는 뜻인데, 이제야 발견되어서 고쳤다. 심지어 세로쓰기일 때도 이런 문제가 없는데 요건 9.0 작업 당시에 코딩 실수가 있었던 모양이다.

요건 현재까지 날개셋 한글 입력기에서 발견된 거의 유일한 버그이다. 프로그램이 죽는다거나 하는 문제도 아닌 외형적인 실수이다.

5. 맺는 말

(1) 예전에도 한번 말한 적이 있을 것이다. 본인은 사실 생각 같아서는 기능 구현뿐만 아니라 API 구조도 마음에 안 드는 것들을 다 갈아엎고 싶고, 지금의 set/ist의 파일 포맷도 다 바꿔 버리고 싶다. 저 기능들을 처음 구현하던 시절이랑, 지금 이렇게 실물이 완성된 뒤에 본인이 생각하는 날개셋 한글 입력기의 내부 구조 및 전체 그림이 서로 같지 않기 때문이다. 지금이 당연히 더 추상적이고 체계가 더 잡혀 있다.

하지만 그건 사용자의 눈에는 띄는 게 전무한 리팩터링에 불과하기 때문에, 내부 구조가 깔끔해지는 것 말고 들이는 시간과 노력 대비 단기적으로 드러나는 성과가 너무 없고 리스크도 크다.
그런 것까지 무리하게 욕심 내서 다 추진하다가는 내가 학교 졸업을 도저히 할 수 없어지니.. 그건 하더라도 졸업 후에, 날개셋 버전이 10 정도로 확실하게 넘어갔을 때의 매우 장기적인 과제로 남기고자 한다. 이미 지금도 당초 계획보다 이미 1~2년 정도 지연이 발생해 있다. 당초 계획이 없던 기능들도 이것저것 막 구현하는데 나의 귀차니즘과 슬럼프, 능력 부족까지 겹쳐서..

어쨌든, 내 근황과 신상에 큰 변화가 생기지 않은 지금 여건 하에서... 적어도 2010년대 동안은(18~19) 날개셋 한글 입력기는 잠정적으로 9.5x 정도가 마지막 버전이 될 것이다.
9.5 이후로 당분간은 새 버전이 나오더라도 사소한 기능 추가나 버그 수정 위주로만 나올 것이다. 운전에다 비유하자면, 저단에서 고rpm으로만 계속 가속하는 데 한계를 느낀다. 나도 고단으로 변속 좀 해야지..

(2) 당연하다면 당연한 얘기인데, 요즘 문자 입력기들의 추세는 확실히 언어 데이터를 기반으로 자주 사용하는 단어, 앞으로 또 나올 가능성이 높은 문구를 미리 제시해 주는 것이다.
Windows에 내장된 한국어나 중국어 IME는 15년 전이나 지금이나 동작이 크게 달라진 것이 없는 반면, 일본어 IME는 그렇지 않다. Windows XP에서는 TSF의 새로운 기능을 활용해서 조합(composition)을 만들고 있는 중에도 cursor가 조합 안팎을 자유자재로 드나들 수 있는 natural input mode라는 걸 도입했다.

그리고 Windows 8이나 10쯤에서는 전통적인 "발음 입력+space → 단어를 나눠서 구간별로 변환"이라는 동작에서 탈피하여.. 구간 구분 없이 대충 말을 입력하다 보면 다음에 입력할 걸로 예상되는 말이 같이 후보 리스트에 뜨면서 한꺼번에 뭔가 '스마트'하게 동작하는 걸로 재미있게 바뀌어 있었다.

한글과 영문은 단어 단위 조합은 모바일에서만 존재하며, PC에서는 그런 계층이 없다. 일본어는 기왕 단어와 문장이 조합창을 몽땅 거치다 보니, 거기서 할 수 있는 모든 언어적인 변환은 다 끌어들이는 것 같다.
그 반면 한글은 기본적으로 글자 단위+rule 기반의(data 기반이 아닌) 간단한 조합만 거친다. 이런 구조에서 할 수 있는 온갖 기괴한 응용 기능은 지금까지 날개셋 한글 입력기의 주된 관심사요 개발 아이템이었다.

하지만 거시적으로는 한국어의 입력도 그런 기능에다가 어절 단위의 더 큰 규모의 조합과 접목할 필요가 있다. 이를 염두에 두고 이번 9.3에서는 "조합 안에 조합 생성"이라는 입력 도구가 추가되었다. 이것은 날개셋 한글 입력기의 개발 역사상 매우 의미심장한 기능이다.
내 여건이 허락하는 한, 날개셋 한글 입력기는 한글 같은 문자를 기반으로 하여 생각할 수 있는 모든 입력 기능을 구현할 수 있고, 이를 토대로 세벌식 자판의 장점도 덤으로 부각시킬 수 있는 입력 엔진으로 굳건히 성장할 것이다. 그리고 그 결과물이 프로그램과 논문으로 더 나오게 될 것이다.

Posted by 사무엘

코딩을 하다 보면 한 자료형(타입)에 속하는 값 내지 개체를 다른 타입으로 변환해야 할 때가 있다. 아주 직관적이거나(C에서 정수와 enum), 작은 타입에서 큰 타입으로 가기 때문에 정보 손실 염려가 없는 상황에 대해서는 해당 언어의 문법 차원에서 대입이나 함수 인자 전달이 곧장 허용되곤 한다. 바이트 수가 대등하더라도 signed보다는 unsigned가 더 큰 타입이고, 정수보다 실수가 더 큰 타입으로 여겨진다.

그렇지 않고 정보 소실의 여지가 있거나 서로 호환되지 않는 타입에다 값을 집어넣는 건 컴파일러의 경고나 에러를 유발한다. 이 상황에 대비하여 프로그래밍 언어들은 여러 형변환 함수들을 제공하는데, 씨크하게 괄호 안에다가 타입 이름만 달랑 쓰면 형변환 연산자로 인식되는 C/C++이 여기서도 참 유별난 면모를 보이는 것 같다.

형변환이란 건 값의 초기 타입과 목적 타입이 무엇이냐에 따라 내부에서 벌어지는 일이 매우 다양한 편이다.

(a) 없음: LPARAM에서 void*, void*에서 char* 같은 무식한 형변환은 소스 코드상의 의미만 매우 과격하게 바뀔 뿐, 내부적으로 행해지는 일은 전무하다! (클래스 상속 관계를 신경쓸 필요 없는 간단한 것 한정으로)

(b) 그냥 뒷부분 짜르거나 늘리기: int와 char 사이의 변환

(c) 정수와 실수 사이를 변환: 내부적으로 일어나는 일이 분명 간단하지는 않지만, 요즘은 이런 건 CPU 명령 한 줄이면 바로 끝난다. x86 기준으로 cvtsi2sd이나 cvttsd2si 같은 인스트럭션이 있다.

(d) 고정된 오프셋 보정: 단순한 형태의 다중 상속에서 제n의 부모 클래스 포인터를 얻으려면 이런 보정이 필요하다.

(e) 함수 호출: 해당 클래스에다 사용자가 구현해 놓은 operator 함수가 호출된다. 사실, 100과 "100"처럼 숫자와 문자열 사이의 변환도 컴퓨터의 관점에서 보면 이 정도의 cost가 필요한 작업이다.

(f) 상속 계층 관계 그래프 순회: 이건 객체지향 이념 때문에 형변환 연산이 언어 차원에서 가장 복잡해지는 상황이다. 위의 1~5와는 근본적으로 차원이 다르다. 가상 상속 체계에서 부모 클래스를 찾아가거나 dynamic_cast 형변환을 하려면 자기의 타입 정보 metadata를 토대로 주변 클래스 계층 그래프를 O(n) 시간 동안 순회해야 한다(n은 상속 단계).
사용자의 코드가 아닌 컴파일러의 코드만 실행됨에도 불구하고 런타임 가변적인 반복이 발생할 수 있으며, 객체와 메모리 상태가 어떤지에 따라서 형변환 결과가 dynamic하게 달라질 수 있다!

내부적으로 벌어지는 일은 대략 저렇게 분류 가능하고, 겉으로 소스 코드의 의미 차원에서도 형변환의 성격을 몇 가지로 분류할 수 있다.
처음에 C++에는 그냥 C-style cast밖에 존재하지 않았다. 그런데 그랬더니 형변환 연산이 발생하는 부분만 검색으로 뽑아내는 게 어려웠고, 또 단순한 형변환과 좀 위험한 형변환 같은 걸 따져 보기도 어려웠다. 표현 형태가 괄호와 타입 이름이 전부이니까..

그래서 1996~97년경, C++98의 발표를 앞두고 C++에는 길고 굉장히 기괴해 보이지만 용도별로 세분화된 형변환 연산자가 4종류나 추가되었다. namespace, bool, explicit, mutable 이런 키워드들과 같은 타이밍에 도입되었다. C++이 숫자는 몽땅 machine-word int로 어영부영 때우려던 C스러운 사고방식을 탈피하고, 예전에 비해 나름 type-safety를 따지기 시작한 그 타이밍이다. (예: C와 C++에서 sizeof('a')의 값의 차이는?)

새 연산자들은 모두 *_cast로 끝난다. 옛날의 재래식 형변환은 (NEWTYPE)value라고 썼고 C++ 문법으로는 NEWTYPE(value)도 허용되는 형태였다(NEWTYPE이 딱 한 단어 토큰으로 떨어지는 경우에 한해서).
그에 비해 새 연산자들은 *_cast<NEWTYPE>(value)라고 쓰면 된다. < > 안에다가 타입 이름을 쓰는 것은 템플릿 인자 문법에서 유래되었는데 나름 직관적이고 적절한 활용 같다.

1. static_cast

얘는 일상적으로 가볍고 큰 무리 없이 일어나는 일반적인 형변환을 거의 다 커버한다. (1) 큰 타입에서 작은 타입으로(실수에서 정수, UINT에서 int, long long에서 int 등..), 그리고 (2) 범용적인 타입의 포인터에서 더 구체적인 타입의 포인터로(void*에서 타 포인터, 기반 클래스*에서 파생 클래스 포인터) 말이다. 이게 대부분이다.

그리고 형변환 operator 호출이라든가, 다중· 가상 상속으로 인한 포인터 보정도 언어에서 보장돼 있는 메커니즘이므로 알아서 처리해 준다. 정말 대부분의 상황에서 앞서 나열했던 (a)에서 (f)까지, C-style cast를 대체할 수 있는 무난한 연산자이다. 단, f에서 typeid와 RTTI까지 동원되는 제일 비싸고 난해한 기능은 없으며, 이건 나중에 설명할 dynamic_cast가 전담하는 영역이다.

2. const_cast

얘는 값이 아니라 포인터/참조자형에서 C/C++ 특유의 한정자(qualifier) 속성만을 제거해서 더 범용적인 포인터로 만들어 준다. 그러므로 용도가 아주 제한적인 형변환 연산자이다.
C++에서 공식적으로 제공되는 qualifer는 const와 volatile이 있다. 이런 한정자는 가리키는 대상 타입과는 아무 상관 없고, 포인터를 이용해 그 메모리를 접근하는 방식 차원에서 제약을 부여할 뿐이다. 전자는 읽기 전용 속성이고, 후자는 멀티스레드에 의해 값이 언제든 바뀔 수 있음을 대비하라는 최적화 힌트이다.

Visual C++에는 __unaligned라는 확장 키워드도 저것들과 동급인 한정자이다. 이 포인터는 machine word 단위의 align이 맞춰지지 않은 주소가 들어올 수도 있으니 그렇더라도 뻗지 말고 보정하라는 뜻이다(성능 오버헤드 감수하고라도). align 보정을 알아서 너무 잘 해 주고 있는 x86 계열은 전혀 해당사항이 없고, 과거에 IA64를 지원하던 시절에 필요했던 키워드이다. 이것도 포인터 한정자 속성으로서는 굉장히 적절한 예이며, 이런 속성들을 const_cast로 제거할 수 있다.

3. reinterpret_cast

이건 의미론적으로는 제일 무식하고 생뚱맞고 위험하지만 내부 처리는 제일 할 것 없는 형변환 전문이다. (1) 정수와 포인터 사이를 전환하는 것, 그리고 (2) 서로 관련이 없는 타입을 가리키는 포인터끼리 전환하는 것.. 어디 범용적인 함수나 메시지로부터 아주 polymorphic한 데이터를 전달받아서 처리할 때에나 불가피하게 쓰일 법하다.

void*를 char*로 바꾸는 건 static_*으로도 되고 reinterpret_*으로도 된다. 하지만 const char*를 char*로 바꾸는 것은 static_*나 심지어 reinterpret_*로도 안 되고 반드시 const_*로만 해야 한다.
그런데 그래 봤자 reinterpret_*과 const_*는 어떤 경우에도 실질적인 내부 처리는 (a)뿐인(= 없음).. 참 허무한 연산자이다. 실질적인 처리가 없지만 이 숫자값을 해석하는 방식을 변경하는 이유는 분야별로 여럿 존재할 수 있다는 뜻이다.

재래식 C-style cast는 따지고 보면 1~3을 그냥 싸잡아서 구분 없이 수행해 준다. 그런데 가끔 드물게 다중· 가상 상속 관계의 타입 포인터끼리 형변환을 할 때 정석대로 보정 연산을 거친 포인터를 원하는지(static_*), 아니면 이것도 아무 보정 없이 동일한 메모리 주소에서 타입만 바꿔서 해석하고 싶은지(reinterpret_*) 모호해질 때가 있다.

이런 문제도 있고, 또 C++에다가 좀 제대로 된 객체지향 언어의 기능을 뒤늦게 갖추려다 보니 새로운 형변환 메커니즘이 필요해졌다. 이쯤 되니까 형변환 연산자도 별도의 예약어로 도입해서 구분하지 않고서는 도저히 버틸 수 없는 지경이 됐다. 그럼 다음으로 제일 괴물인 형변환 연산자에 대해서 살펴보도록 하자.

4. dynamic_cast

가상 함수를 쓰면 기반 클래스의 포인터를 주더라도 자신이 실제로 속한 파생 클래스에 해당하는 멤버 함수가 알아서 호출된다.
그리고 다중 상속 때 가상 상속을 쓰면, 여러 부모 클래스들이 동일한 조부모 클래스로부터 상속받았을 때 공통 조부모가 한 번만 상속되는 마술(?)이 일어난다. 물론 객체지향 언어에서 유연한 코드 재사용성을 보장하는 모든 마술에는 그에 상응하는 성능 오버헤드가 대가로 따른다는 점은 감안할 필요가 있다.

그런데 과거의 C++은 상속과 함수 호출에서 이렇게 언어 차원의 동적 바인딩이 지원되는 것과 대조적으로, 형변환에는 "동적 바인딩 + 무결성"을 보장하는 메커니즘이 딱히 없었다. 이놈이 A의 파생 클래스이긴 하지만 더 구체적으로 A의 자식들 중에 B가 아닌 C의 파생 클래스가 진짜로 맞는지, 이 멤버에 접근하고 이 함수를 호출해도 안전하겠는지 말이다.

C++은 void*가 있을지언정, 언어 차원에서 모든 클래스들의 공통 클래스(Java의 Object 같은)라는 개념이 없다. 그리고 클래스 내부의 vbtl에 직접 접근한다거나, 가상 함수의 포인터 값을 보고 클래스 종류를 판별할 수 있을 정도로 C++이 ABI가 몽땅 왕창 노출돼 있느냐 하면 그렇지도 않다(겉에는 공통의 썽킹 함수의 주소만 노출돼 있기 때문). 뭔가 어정쩡하다.

그러니 MFC 같은 옛날 라이브러리들은 자체적으로 CRuntimeClass 같은 타입 메타정보를 구비하고, 이놈이 CObject의 파생이긴 하지만 특정 클래스의 파생형이 정말 맞는지 런타임 때 확인하는 함수를 자체적으로 구현해야 했다.
C++이 아무리 C의 저수준 고성능 제어 이념을 계승했다 해도 명색이 객체지향 언어인데 그런 기능조차 없는 건 좀 아니라 여겨졌는지, 훗날 언어 차원에서 타입 식별 정보와 전용 형변환 연산자가 도입됐다. 그 결과물이 바로 dynamic_cast이다.

함수도 virtual, 상속도 virtual인 걸 감안하면 얘의 이름은 기술적으로 virtual_cast라 해도 과언이 아닐 듯하다. 하지만 static_* 이라는 단어가 이미 있으니 그것보다 더 값비싼 형변환이라는 의미로 dynamic_*이라는 이름이 최종적으로 붙었다. static_*은 이놈이 진짜 조상 관계가 맞는지 확인하지 않고 그냥 O(1) 복잡도짜리 기계적인 오프셋 보정만 해서(필요한 경우) 파생 클래스로 형변환해 주는 반면, dynamic_*은 타입 식별자를 직접 확인까지 한다는 것이다.

가상 함수의 구현을 위해서는 함수 포인터 테이블과 테이블의 포인터(멤버)가 필요하고, 가상 상속의 구현을 위해서는 기반 클래스의 포인터(멤버)가 필요하다. 그것처럼 동적 바인딩 형변환을 구현하려면 클래스 이름과 계층 관계를 기술하는 메타데이터와 함께 그놈의 포인터(멤버)가 필요하다.

가상 함수와 가상 상속 지원을 위한 데이터는 비공개로 꽁꽁 감춰져 있는 반면, 동적 바인딩 형변환을 위한 타입 식별자 데이터는 공식적으로 스펙이 공개돼 있고 일반 프로그래머들이 언어 요소를 통해 접근할 수 있다. 일명 RTTI (run-time type info)이다.
#include <typeinfo>를 한 뒤 typeid() 연산자로 const type_info&라는 구조체, 아니 클래스를 들여다보면 된다. typeid는...

• sizeof와 마찬가지로 오버로딩 할 수 없다.
• sizeof와 마찬가지로 타입 이름과 일반적인 값을 모두 받을 수 있다. 단, sizeof는 값이 올 때는 괄호를 생략할 수 있는 반면, typeid는 그렇지 않아서 언제나 뒤의 피연산자를 괄호로 싸야 한다.
• sizeof는 결과값이 무조건 정적 바인딩으로 구해지는 반면, typeid는 바인딩이 정적과 동적 사이에서 어정쩡하다. 피연산자가 타입 이름이거나, 값이더라도 int 같은 primitive type 내지 상속이고 가상 함수고 아무것도 없는 구조체라면.. sizeof와 마찬가지로 수식을 실제로 evaluate하지 않는다. 그러나 뭔가 상속 관계 규명이 필요하다 싶은 개체라면 런타임 계산이 행해진다.

쉽게 말해 typeid는 MFC로 치면 obj->GetRuntimeClass()와 RUNTIME_CLASS(classnam)의 역할을 혼자 모두 수행한다는 뜻이다.
그럼 관련 타입들에 대해 DECLARE_DYNAMIC 내지 IMPLEMENT_DYNAMIC도 어딘가에 행해져야 할 텐데, 그건 C++ 컴파일러가 typeid 연산자가 쓰인 곳을 총체적으로 따져서 알아서 처리해 준다.

이런 RTTI 기능은 대다수의 C++ 컴파일러에서 사용 여부를 옵션으로 지정할 수 있게 돼 있다.
RTTI를 사용한 상태에서 dynamic_cast를 사용하면 실제 타입이 그게 아닌데 그 파생 타입으로 형변환을 시도하는 경우.. 피연산자가 포인터였다면 NULL이 날아오고, null이 가능하지 않은 참조자를 줬다면 예외(exception)를 날리게 된다.
이것도 다중 상속까지 생각한다면 상속 관계 그래프를 타고 오프셋을 보정하는 알고리즘이 가히 판타지가 될 것 같다.

이상.
객체지향 언어라는 게 그냥 구조체에다가 this가 자동으로 전달되는 함수가 같이 딸려 있고, 상속에 다형성 정도 지원되는 게 전부라고 생각하는 게 얼마나 순진한 생각인지 알 것 같다.
PC 환경에서 C를 초월하여 C++이 보급된 게 1990년대 초쯤인데, 이 무렵에 템플릿과 다중 상속도 도입됐다. 처음부터 있었던 게 아니다. 그리고 그때부터 C++은 뭐랄까, 괴물 같은 복잡도를 자랑하는 치떨리는 언어로 변모한 것 같다.

구리고 지저분한 면모가 많지만 그래도 그 정도 객체지향 이념에다가 고성능 저수준 제어까지 이만치 잡은 건 얘가 C++이 가히 독보적인 것 같다.
그러니 형변환 연산자도 언어를 따라 이렇게 복잡해진 것이다. 일례로, Java는 final이 있을지언정 포인터도 없고 const니 volatile 같은 건 신경 쓸 필요도 없는데 뭐 저런 구분이 필요하겠는가? 그러니 지금도 여전히 C-style cast만으로도 충분한 것이다.

Posted by 사무엘

1. 영동과 부강 역 인근의 비밀 선로

경부선 성환 역은 동쪽 인근의 학정리 야산을 다 점유하고 있는 군부대 탄약창으로 이어지는 선로가 있는 것으로 잘 알려져 있다.
그 외에도 대전 근처의 영동 역도 서쪽으로 거대한 탄약창으로 이어지는 선로가 있다. 육군 종합 행정 학교가 영동 제일 요양 병원 근처로 이전해 오긴 했는데, 탄약창은 그것보다 더 북쪽에 있는 별개의 부대이다.

한편, 부강 역은 가까운 동북쪽으로는 철길이 아니고 도로이지만, 거대한 컨테이너 화물 기지가 있고, 또 뭔가 일반인이 범접할 수 없어 보이는 코렁시설이 있다. 단순 화물 기지이기만 했으면 저렇게 민간 지도에서 가려지고 숨겨지지는 않았을 것이다.
그리고 서쪽으로는 2010년에 '부강화물선'이 개통하여 민간 지도에도 보이는 화물 기지가 있다.

저기는 세종 자치시 중심부와 꽤 가까우며 바로 옆에 호남 고속선이 지나는 게 흥미로운 형태이다. 나름 물류 허브도 추구하는 것 같다.

2. 서울 지하철 5호선의 동쪽 지선

서울 지하철 5호선은 강동 역 이후로는 잘 알다시피 상일동과 마천 방면으로 Y 자 모양으로 노선이 갈라진다. 역 수는 마천 지선이 좀 더 많다.
상일동 지선: 고덕 차량기지가 지나는 관계로 서울 지하철 5호선 중 가장 먼저 개통한 구간이다(왕십리-상일동).
서울 지하철 2호선이 군자 차량기지를 끼고 신설동-종합운동장이 가장 먼저 개통한 것과 같은 이치이다. (그때는 성수 지선이 2호선의 본선이었음)

2010년대에 들어서 두 지선은 서로 다른 방향으로 변화하게 되었다.
마천 지선은 기존 지하철의 연장 건설로 인한 환승역이 생겼다. 오금이 3호선과 환승되고, 그리고 앞으로 올림픽공원은 9호선과 환승될 예정이다.
그 반면, 상일동 지선은 노선 자체가 하남시 쪽으로 더 연장되어 길어질 예정이다. 환승역이 생기는 것과, 노선이 더 연장되는 것 중 어느 게 더 호재일까?

상일동 지선은 서쪽이 한강으로 막혀 있어서 타 노선과 환승이 될 여지가 없는 반면, 마천 지선은 동쪽이 청량산으로 막혀 있어서 자기 자신이 더 연장될 여지가 없다. 무척 독특한 차이점이다.

상일동 쪽은 한강과 가까우며 명일 공원, 길동 공원, 고덕산 이렇게 언덕과 근린공원이 많다. 그런데 '굽은다리'라는 역은 도대체 무슨 다리가 굽었다는 말인지 모르겠으며, '고분다리'라는 명칭과도 맞물려서 초행 방문자를 더욱 헷갈리게 하고 있댄다.

마천 쪽은 둔촌동이라는 역명도 그렇고 왠지 '둔촌 이 집' 선생을 기리는 흔적이 눈에 띈다. 후손들이 자기 선조를 띄워 주려고 많이 노력을 한 것 같다. '둔촌'은 강서구의 '등촌'과는 전혀 무관한 명칭이다.

마천역은 처음 만들던 당시에는 특전사 부대와 군인 아파트 보안 때문인지 지금의 오금로· 마천로 큰길 쪽으로 출구를 못 만들고 마천 초등학교 쪽의 엉뚱한 골목길에다가 출구를 만들었다.
하지만 군부대가 몽땅 이전하고 아파트가 지어지고 있는 지금으로서는 큰길 쪽에 지하철 출구가 만들어지지 못한 게 안타까운 지경이 됐다. 사실, 지금 용산구에 있는 미군 기지가 대거 이전하고 나면.. 미군 기지 때문에 잔뜩 굴곡지고 왜곡돼 있는 기존 서울 지하철들의 선형도(특히 4호선) 눈에 더욱 띌 것이다.

3. 크게 뒤집어엎어진 서울 지하철 계획

서울에 지하철에는 원래 이렇게 계획되었다가 대판 갈아엎어져서 사라진 흑역사가 두 건 정도 존재한다.

(1)
하나는 1970년대, 양 택식 서울 시장 시절에 나왔던 구 1기 지하철 계획이다. 강남이나 여의도 따위 안중에 없이 강북 사대문 안만을 염두에 둔 방사형으로 5개 노선을 계획했다. 특히 5호선은 천호대로와 종로를 직결 운행했으며(나중에는 송파대로와 성남대로까지!!), 종로 구간은 1호선과 복복선 선로를 나란히 달릴 예정이었다.

그렇게 계획이 추진되어서 일단 서울 지하철 1호선이 갖은 난관을 뚫고 잘 개통했다. 그랬는데.. 1974년 광복절, 육 영수 여사 피격 사건이 터졌다. 그래서 양 시장 인생에서 최고의 순간이어야 했을 지하철 개통식은 아주 침통한 분위기에서 치러져야 했으며, 박 대통령도 참석을 못 했다.

생각을 해 보시라. 옛날 대한뉴스 영상을 보면 2호선 때 전대갈부터 시작해 1990년대 분당선 때(김 영삼)까지만 해도 지하철· 전철이 개통하면 대통령이 친히 와서 시승을 하고 관계자들 노고를 치하해 주는 게 관행이었다. 하물며 우리나라 최초의 지하철의 개통은 경부 고속도로의 개통에 준하는 기쁘고 뜻깊은 일이거늘, 그 당시의 기록 영상을 보면 정작 1호선 개통 때 박 대통령의 모습은 어디에서도 찾을 수 없다. 영부인이 총을 맞았으니 거기 갈 수가 없게 됐기 때문이다.

그리고 이 사건에 대한 책임을 지고 양 시장은 경질됐다. 운이 참 더럽게 없는 것 같다. 후임 구 자춘 시장은 1호선이야 이미 완공돼 버렸고 어차피 구간도 종로밖에 없으니 그렇다 치지만 나머지 1기 지하철 계획을 싹 갈아엎어 버렸다.
그는 서울을 다핵도시로 키울 생각을 하고 20분 만에 선을 쭉쭉 그어서 이례적인 지금의 2호선 순환선 디자인을 확정했다.

오늘날 서울 1기 지하철들은 초기 지하철이다 보니, 얕긴 하지만 추후 건설된 지하철들과 환승이 막장인 편이다. 1기와 2기끼리는 그렇다 치더라도 서울 지하철 최초의 환승역인 신설동 역까지 잠실 역에 준하는 평행형 승강장 막장환승인 이유는 이렇게 지하철 건설 계획의 리부트와 단절이 있었기 때문이다. 구 계획대로 1호선과 5호선의 환승을 염두에 두고 만들어 뒀던 신설동 역 지하 3층 유령 승강장이 버려지게 된 것도 같은 이유 때문이다.

(2)
다음으로 대판 나가리 난 중대 계획은.. 짐작하셨겠지만 3기 지하철 계획이다. 이건 1990년대 초중반에 계획이 나왔지만 몇 년 못 가 외환 위기· IMF· 긴축 재정으로 인해 흑역사로 전락했다.
지하철 건설 기술과 노하우가 그럭저럭 축적되다 보니, 2기 지하철들은 미래에 또 건설될 3기 지하철과의 환승을 미리 대비까지 하면서 건설되었다. 그런데 그것들이 상당수 활용되지 못하게 되었으니 안타까운 일이다.

이렇듯, 지하철 건설 역사 한 분야만 봐도 사람 일이라는 건 가까운 미래조차도 알 수 없는 것 같다. 앞에서 언급된 양 택식 서울 시장만 해도 지하철 잘 만들어 놓고는 개통식 당일에 저런 일이 터질 줄 누가 예상했겠는가?

환승 대비를 해 놓은 것으로는 7호선 논현(11호선), 6호선 녹사평(11호선), 8호선 몽촌토성(9호선, 색깔띠까지) 등 내가 당장 떠오르는 것만 해도 여럿 있다. 그나마 여의도는 십자형 환승역으로 예상이 정확하게 잘 적중했으며, 오금과 가락시장도 3호선의 남쪽 연장에 대비한 설계가 계획대로 쓰였다. 9호선이 연장되어 8호선과 만나는 건 당초 계획됐던 몽촌토성이 아니라 석촌이 당첨됐다.

3기 지하철 계획 중 기존 노선의 연장(3호선 오금, 7호선 부평구청)과 9호선 신규 건설만이 살아남았다. 이들은 2009~2012년 사이에 완공됐다. 10호선은 서울 외곽 내지 시외 구간만이 변별성을 인정받아 광역전철 신안산선으로 대체됐으며, 그야말로 2020년대 중반은 가야 결과물이 나올 듯하다.

11호선도 남쪽의 서울 외곽· 시외 구간만이 원형 그대로 살아남아서 사철 광역전철인 신분당선으로 대체됐다. 하지만 북쪽은 아직 논현까지 올라오지 못한 상태이다.
12호선은 서울 최초의 경전철로 대체되었는데, 원래 계획되었던 왕십리 환승은 가망 없고 신설동에서 시작한다.

요약하자면 구 1기 지하철은 그냥 나가리 났다. 3기 지하철은 일부만 살아남고 나머지는 일부 구간이 서울 지하철이 아니라 민자 광역전철이나 경전철이라는 생소한 형태로 부활했다.

4. 미래의 간선 철도: 경강선, 강원선, 중부내륙선

우리나라는 1970년대의 태백선 이후로 지방에 장거리 간선 철도 건설의 맥이 끊기다시피했다. 그 뒤로 생긴 철도들은 다 수도권 광역전철이나 공항 철도가 아니면 다 기존 철도의 선형을 유지한 고속화나 복선· 전철화, 선형 개량뿐이었기 때문이다.
그러다가 2010년대 중후반에 가서는 서쪽으로는 소사-원시선이 만들어지고 있으며, 동쪽으로는 철도 소외지이던 강원도에 철도다운 철도가 만들어지기 시작했다. 횡축으로는 경강선이요, 종축으로는 동해선이다.

2018년 현재 경강선은 두 파트로 나뉘어 있다. 하나는 원래 '성남여주선'이라는 이름으로 판교-이매-여주를 이으며 현재 통근형 전동차가 다니는 그 광역전철 노선이다. 다른 하나는 원주에서 분기하여 영동 고속도로와 유사한 선형을 타고, 기존 태백선보다 더 북쪽인 평창-강릉 방면으로 가는 준고속선이다.

얘는 물론 평창 동계 올림픽 때문에 만들어졌지만 올림픽이 끝난 뒤에도 나름 '동서 고속철' 역할을 잘 감당할 것이다. 영동 고속도로는 이미 2001년에 온통 고가 놓고 터널 뚫어서 지금과 같은 깔끔한 형태로 잘 개통했건만 철도가 지금까지 너무 오랫동안 낙후해 있었다.

원주 서쪽의 중앙선 철도는 이미 진작부터 복선 전철화가 완료됐으며, 선형 개량을 통해 열차의 주행 속도가 경부선 급으로 상향 조정됐다. 서울에서 강원도로 가기 위해 경유해야 하는 곳이 먼 옛날의 영주(영동선!)에서 제천(태백선)을 거쳐 원주로 점점 더 짧아졌다.

미래에, 대략 2020년대 중반쯤엔 경강선은 여주와 원주 구간이 한데 연결될 것이며, 더 나아가 판교 이후의 서쪽으로도 더 확장돼서 광명을 찍고 시흥시 월곶까지 갈 것이다. 중간에 성남, 의왕, 안양 사이 구간은 나름 외곽순환 고속도로와도 비슷한 선형이 된다는 게 아주 흥미롭다. 그래, 거기도 철도가 진작에 필요했다.
이렇게 된 이상 쭉쭉 서쪽으로 가서 제2경인 고속도로처럼 인천 공항까지 가 버려도 되지 않을까 싶다.

경강선은 그렇고.. 종축으로 동해선은 먼저 부산 시내 기장군 정도 구간이 전면적인 선형 리모델링과 동시에 광역전철로 탈바꿈했다. 서울· 수도권 광역전철이 등장한 지 무려 40여 년 만의 일이다.
그리고 과거에 동해남부선이라고 불리면서 포항 북부에서 끊겼던 철길은 계속 북상할 것이다. 그래서 영덕과 울진에 역사상 최초로 철도가 들어오게 된다. 그래서 지금 영동선의 지선으로 취급되고 있는 삼척선과 만나고, 이것까지 동해선으로 흡수되어 동해 역까지 가게 된다.

이렇게 되면 동해-강릉도 전부 동해선으로 흡수되고 영동선은 영주-동백산-동해 구간만 불리게 될 가능성도 있어 보인다.
강릉 이북으로 최북단의 제진 역 구간은 동해중부선이라는 명칭으로 불렸으니, 국도 7호선에 상응하는 길다란 종축 철도는 일관되게 동해선이 되는 게 자연스럽겠다.
이렇듯, 경강선과 동해선 모두 말단에 광역전철 구간이 있으면서 나머지 강원도 방면 구간은 찢어진 채로 공사 중이라는 공통점이 있다.

아, 까먹을 뻔 했는데... 경강선은 여주와 원주로 가는 중에 부발 역 일대에서 중부내륙선이 분기하기도 할 예정이다. 얘는 충주(충북선)와 문경(문경선)을 경유하면서 점촌· 김천(경북선)과 연결된다. 현재의 말 그대로 영남대로 내지 중부내륙 고속도로와 얼추 비슷한 선형이 되는 셈이다.

지금이야 안 그래도 좁은 땅에 이미 건설된 도로와 철도도 많다. 그러니 옛날에 경부선과 경부 고속도로를 처음 만들 때처럼 총력전 치르듯이 일을 추진할 필요는 없고, 이미 있는 구간에서 뭔가 아쉽다 싶은 missing link만 찔끔찔끔 잇는 식으로 길을 만드는 게 추세이다. 고속도로도 갈수록 세 자릿수 번호가 늘어고 있듯이 말이다.

Posted by 사무엘

1. 물과 공기의 차이

1기압에 온도가 20도대인 지구의 공기는 사람이 활동하기 쾌적한 환경이다. 기온이 체온에 근접하면 체열을 밖으로 제대로 내보낼 수가 없어서 더위를 느끼게 된다.
하지만 20도대의 물은 수영을 하기에 여전히 꽤 차가운 물이다. 물의 온도는 체온에 근접해야 그럭저럭 미지근하고 물놀이를 할 만하다고 여겨진다.

7~80도대, 심지어 그보다 더 뜨거운 공기는 사우나에서 겪을 수 있으며 잠깐 정도면 버틸 만하다. 그러나 같은 온도의 물은.. 닿는 즉시 화상을 입는 뜨겁고 위험한 물이다. 그렇다면 여기서 온도라는 건 도대체 과학적으로 무엇을 의미하는 걸까?
사실, 인체 내부는 온도의 변화에 의외로 취약하다. 체온이 정상보다 단 몇 도만 더 높거나 낮아지면 사람은 정상적인 활동을 못 하고 앓아눕게 된다.

저온에서는 세포의 물질대사가 정상적으로 이뤄지지 못한다. 사람이 추운 실외에서 이불 같은 거 안 덮고 그냥 자다간 그대로 동사하는 수가 있다.
그리고 반대로 고온도.. 뇌를 구성하는 단백질은 40도 정도만 돼도 생화학적으로 변성되고 맛이 가 버린다고 그런다. 여기에는 내부의 감기 같은 질병 때문에 열이 나는 것, 혹은 외부의 혹독한 무더위 때문에 열이 나는 것(열사병..)이 모두 포함된다.

특히 소아 때 이런 열병을 오랫동안 겪는 건 굉장히 치명적인지라, 병이 나은 뒤에도 머리와 몸에 영구적인 장애가 남기 십상이다. 헬렌 켈러가 대표적인 예이다. 우리나라는 한여름에 어린이집 교사와 운전사의 부주의로 인해 어떤 아이가 한여름 땡볕에 더운 차내에서 몇 시간째 방치되어 혼수 상태에 빠진 사고가 몇 건 나곤 했는데 그 애가 지금은 어찌 됐나 모르겠다.

기왕 말이 나온 김에 더 끔찍한 얘기를 꺼내자면, "왕창 고온인 공기" vs "온도 자체는 그리 높지 않지만 열전달 효율이 넘사벽급으로 높은 유체" 이 둘의 차이가 따지고 보면 화형과 팽형의 차이를 만든다. 새까맣게 탄 시체도 끔찍하지만, 검지만 않을 뿐 뻘겋게 익고 퉁퉁 불어 터진 시체도 끔찍하기는 마찬가지일 것이다.

뜨거운 공기든 뜨거운 물이든, 작열통은 의학적으로 볼 때 신체 절단과 더불어 인간이 느끼는 가장 끔찍하고 괴로운 고통으로 여겨지고 있다. 성경에서도 지옥이 괜히 결코 꺼지지 않는 "불"로 묘사되는 게 아니다. 주토피아에 나오는 것처럼 "ice them"이면 차라리 양반이지, 진짜 본좌는 "burn them"인 것이다.

수은주가 달린 일반 온도계를 펄펄 타는 불에다 던져 넣으면 재질에 따라서 불타거나 녹고 깨지고 파괴될 것이다. 그러나 펄펄 끓는 물에 넣어서 100도대의 온도를 측정하는 것 정도는 문제가 없다. 이걸 생각하면 단백질로 구성된 인체(생체)만이 그런 저고온(?)에 굉장히 취약한 재질이라는 걸 유추할 수 있다. 고온의 공기는 그나마 고온의 여파가 끼치는 '정도'가 덜한 매체이기 때문에 상대적으로 더 오래 버틸 수 있을 뿐이다.

2. 습도

앞에서 물의 온도와 공기의 온도 얘기가 나왔는데.. 사실은 사람이 공기 중에서 더위나 추위를 느끼는 것에는 공기의 온도뿐만 아니라 잘 알다시피 공기에 포함된 습기도 굉장히 큰 기여를 한다. 이런 차이 때문에 날씨가 더워도 굉장히 기분 좋게 더울 때가 있는가 하면, 그렇지 않을 때도 있다.

낮 기온이 30도를 훌쩍 넘겨 40도에 근접한다면, 직사광선은 굉장히 뜨겁고 따가우며 땀 나고 더운 게 맞다. 실내에서는 에어컨을 틀어야 한다.
그래도 기온만 높지 습도가 별로 높지 않다면 상황이 낫다. 밖에서 조금만 바람이 불거나 그늘에 들어가면 금세 시원함이 느껴진다. 그리고 저녁이 되어 해가 지면 언제 그랬냐는 듯이 기온이 굉장히 신속하게 내려간다.

이와 반대로 습도가 높으면.. 낮 기온이 30도를 채 넘지 않고 심지어 해가 안 나더라도 푹푹 찌며 쏟아지는 땀을 감당할 수 없어진다. 땀이 나도 잘 증발하지도 않기 때문에 불쾌지수가 최고로 치닫는다.
이런 날이 꼭 밤에도 기온이 내려가질 않고 열대야가 계속돼서 사람들을 고통에 시달리게 만든다. 에어컨은 온도가 아니라 습도를 낮추는 기능 때문에 더 필요하다.

습도라는 건 공기 중에 존재하는 수증기의 농도를 말한다. 물은 1기압에서 섭씨 100도에서 끓기 시작해서 몽땅 수증기로 바뀌며, 물의 끓는점이나 어는점은 잘 알다시피 공기의 압력에 따라 달라진다(고산 지대에서는 물이 더 낮은 온도에서 끓음). 물이 공기를 녹이고 있는 것만큼이나 반대로 공기도 수분을 함유할 수 있다.

그 뿐만 아니라 100도보다 낮은 온도에서도 공기와 접촉하는 수면에서는 일부가 수증기로 증발하기도 한다.
이건 안개 내지 구름과는 다른 개념이다. 그건 수증기가 아닌 미세한 물 알갱이가 공기 중을 떠다니는 것이다. 이는 마치 순수한 회색과 흑백이 교대로 촘촘하게 늘어선 디더링의 차이와도 비슷하다. 물이 어떻게 이런 두 형태로 모두 존재할 수 있는지 난 완전히 직관적으로 이해를 못 하겠다.

공기가 머금을 수 있는 습기의 한계라는 게 공기의 온도에 따라 달라지기 때문에 습도에는 절대 습도와 상대 습도라는 개념이 따로 존재한다. 물이 온도가 올라갈수록 기체를 녹이고 있기 어려워지는 것과 마찬가지로, 공기 역시 온도가 올라갈수록 습기를 품기 어려워진다. 이 때문에 같은 양의 수분을 머금고 있더라도 온도가 올라가면 상대 습도는 더 올라간다. 겨울이 전반적으로 건조하고 여름이 전반적으로 습한 것도 이런 상대 습도의 차이 때문이다.

3. 진공

그럼 물과 공기가 있는 상황이 아니라, 반대로 물과 공기가 전무하여 진공에 가까운 우주로 나가면 온도라는 게 어떤 영향을 끼칠까? 솔직히 말해 이 역시 난 잘 모르겠고 상상이 잘 안 된다.
공기 제로, 압력 제로, 습도 제로이다 보니 거기는 햇볕을 받느냐 마느냐에 따라 뻑하면 영하 1~200도와 영상 수백 도를 오르내리게 된다. 단지 그 온도의 여파가 지구 표면보다 훨씬 덜하다. 진공인 게 인체에 훨씬 더 해롭지, 온도 자체가 사람을 즉시 태워 죽이거나 얼려 죽이지는 않는다.

하지만, 그럼 우주 공간에서 온도가 영향을 전혀 안 끼치는가 하면 그것도 아니다. 그렇기 때문에 인공위성은 뱅글뱅글 돌면서 몸체가 태양열을 골고루 받게 자세를 잡는다. 이거 조절 잘못해서 배터리가 과열이라도 되면 터지는 사고가 나기 때문이다.
또한, 우주 공간에서 수성이나 금성 같은 내행성으로 날아가는 탐사선은 커다란 양산처럼 생긴 차폐막을 앞에 두르는 형태로 설계되었다.

달에 착륙했던 아폴로 우주선 승무원들 역시 직사광선을 피해서 그늘 또는 저녁 시간대를 선택해서 주로 활동했다.
그러니 이런 정황들을 종합했을 때, 진공에서의 온도라는 게 어떤 의미를 갖는지 갈피를 잘 못 잡겠다. 일단 진공이라면 앞서 언급했듯이 각종 물질의 상태가 바뀌는 온도(끓는점, 어는점??)부터가 우리의 상식을 벗어나는 형태로 바뀌어 버리기도 하니 말이다.

참고로, 사람이 우주에 맨몸으로 있으면 체내의 공기가 유출되고 체액이 끓어오르면서 신체 상태가 잠수병 이상으로 엉망진창이 되며, 수 분 이내로 의식을 잃고 곱게 질식사한다. 그렇다고 해서 눈알이 튀어나오거나 몸이 풍선 터져듯이 터지면서 끔살 당하지는 않는다. 더구나 잘 훈련받으면 수 초 정도 동안 맨몸으로 우주 공간에 노출되고도 살 수 있다.

당연한 얘기이지만 진공은 무중력과는 별개의 조건이다. 진공은 쇠구슬과 깃털이 똑같은 속도로 떨어지는 것이고, 무중력은 둘 다 둥둥 떠다니는 것이다. 물론 둘 다 현실에서는 도저히 상상이 안 되는 상황인 건 마찬가지이다만... 우주 개발 초기에 선진국에서 벌어졌던 여러 테스트· 훈련, 생체 실험-_- 중에는 진공을 버티는 것이 당연히 포함돼 있었다. 원심 가속기나 자유 낙하를 통해 흉내 냈던 무중력과는 별개의 코스이다.

4. 열이 전달되는 원리

온도를 변화시키는 열이 전파되는 메커니즘으로는 "대류, 전도, 복사"라는 세 종류가 있다. 이 개념 자체는 초· 중딩 과학 시간에 진작부터 배운다. 그런데 이게 생각보다 굉장히 심오한 개념이다. '열전달'은 전자기학, 뉴턴 역학, 양자 역학만큼이나 물리학의 엄연한 한 분야이고 공대에서 전공 필수 과목이다.

'대류'(convection)는 유체(주로 기체) 내부에서 온도의 차이가 나는 분자들이 물리적으로 직접 상하로 움직이고 돌면서 열이 골고루 전달되는 것을 말한다. 바닷가에서 바람이 끊임없이 부는 것(땅과 물의 엄청난 비열 차이!), 화재 현장에서 불꽃이라든가 뜨거운 공기가 굳이 위로 솟구치는 것이 모두 대류 현상이다.
그러니 이건 가장 거시적인 규모의 열 전달이다. 분자간의 온도 차이가 아니라 단순 농도· 밀도 차이로 인해 발생하는 '확산'과는 다른 현상이다.

열은 매체가 저렇게 몸소 움직이지 않아도 전해질 수 있다. 펄펄 끓는 냄비의 영향으로 냄비 손잡이라든가 안에 넣어 뒀던 국자까지 뜨거워지는 게 대표적인 예이다. 금속의 분자가 직접 움직일 리는 없으니, 이때는 직접 이동이 아니라 일종의 열역학적 '진동'이라는 미시 현상을 통해서.. 마치 소리가 전해지듯이 열이 전해진다. 이 현상을 '(열)전도'(thermal conduction)라고 한다.

진정 골때리는 건 가장 미시적인 현상인 '복사'(radiation)이다. 열은 전자기파의 형태로 아무 매질· 매체가 없는 곳에서도 퍼져 나가서 전해질 수 있다. 적외선이라고 다들 들어 보셨을 것이다. 애초에 전자기파는 파동 같기도 하고 입자 같기도 한 이상한 물건이니 말이다. 저 복사는 copy나 duplication과는 아무 관계 없고, '내리쬠'이라는 뜻이다.

'복사'라는 게 있기 때문에 아무것도 없는 우주 공간에서도 태양열이 지구로 전해질 수 있다. 음파(소리)는 순수한 진동일 뿐이기 때문에 공기가 없는 곳에서는 퍼져 나갈 수 없고 속도도 훨씬 더 느리지만, 복사열은 위상이 빛과 같다.
전자레인지는 그릇은 별로 데우지 않고 안의 음식만 데우는 것이 무척 기가 막히고 신기한데, 이것만 봐도 열은 대류나 전도 같은 물리적인 접촉이 아니어도 직통으로 전해지는 게 가능함을 알 수 있다. 복사는 도선의 전기 저항으로 인해 발생하는 열하고도 물론 다른 개념이다.

물을 끓이면 왜 물이 가만히 있질 않고 보글보글 사정없이 요동치는지, 무슨 근거와 원동력으로 저러는 걸까? 이건 열전달 내지 물질의 상태 변화와 관련된 여러 미시적인 현상들이 복합적으로 작용한 결과이다.
그리고 지표면에서 물과 공기뿐만 아니라 그 밑으로 땅 속에서도 물질이 끊임없이 순환하고 화산· 지진 같은 지질 현상이 발생하는 원동력도 따지고 보면 맨틀의 대류 같은 열 때문이라고 해도 과언이 아니다.

지구의 자전은 아주 서서히 느려지고 있지만, 지구 내부는 지열 때문이든 자기장 때문이든 활동이 여전히 왕성하고, 옛날보다 오히려 더 활발해지는 듯한 느낌이다. 성경이 말하는 대로 지구 발 밑에 지옥이라는 뜨거운 장소가 있다면, 지구의 내부 구조와 양상은 타 행성과는 근본적으로 다를 수밖에 없을 것이다.

5. 열병합 발전소 -- 열전달과 폐열 재활용의 실제 사례

발전소 중에는 우리에게 친숙한 수력· 화력이나 원자력 말고 '열병합'이라는 놈이 있다. 얘는 사실 화력 발전의 파생 변종이다.
물을 끓이고 증기 터빈을 돌려서 발전기를 가동하려면 열을 만들어 내야 하는데, 이 열이라는 게 열역학 이론적인 한계 내지 기술의 한계로 인해 전부 전력 생산에 쓰이지는 못한다. 거의 과반이 폐열로 버려진다. 딱히 재활용할 길이 없기 때문이다.

8~90도에 달하는 뜨거운 물이 한 트럭이 있다 해도, 그것만으로 아무리 용을 써 봤자 100도 이상으로 실제로 펄펄 끓는 물을 한 컵만치라도 만들어서 증기 기관을 굴릴 수는 없잖은가? 그런 맥락에서 말이다.

전체 열량의 합이야 물론 90도짜리 물 한 트럭이 100도짜리 물 한 컵보다 더 많을 것이다. 그러나 외부에서 에너지를 소비하여 열을 가해 주지 않는 한, 물의 온도 자체를 스스로 높이는 것은 불가능하다. 그건 열역학적으로 자연스러운 방향을 거스르는 일이기 때문이다.

열병합 발전소는 이런 어중간한 열이 담긴 온수를 수집해서 난방용으로 주변 지역에 공급해 준다. 전기만 파는 게 아니라 열도 판다. 전동차에 회생 제동이 있다면 화력 발전소에는 이런 열병합 시설이 있는 셈이다.

그럼 처음부터 모든 화력 발전소에다 열병합 시설을 추가하면 되지 않나 의문이 들 수 있다. 하지만 이 열이라는 건 폐열을 기껏 수집한다고 해도 무슨 태양 복사열처럼 간편하게 전해서 활용 가능한 게 아니다. 열이 담긴 물을 수송할 수 있는 거리에 큰 한계가 있다. 쟤들은 대류, 전도, 복사가 아니라 송유관처럼 '열배관'이라고 극한의 보온 시설이 갖춰진 비싼 특수 수도관에다가 온수를 공급하는 형태로 열을 전한다.

그러니 열병합 발전은 온수를 곧장 중앙 집중 난방용으로 활용할 수 있는 대도시 위주로 소규모 화력 발전+열병합 시설을 갖춘 '지역 난방 공사'의 형태로 운영된다.
2018년 현재 경의선 곡산 역 근처에는 전국에서 유일하게 열병합 발전소의 자체 구비가 아니라 정식 화력 발전소와(한국 동서 발전 소속) 연계하는 대규모 열병합 발전소가 있다. 전국 유일의 인서울 화력 발전소인 당인리 발전소와 비슷한 격의 명물인 듯한데, 얘들도 얼마 못 가 더 외곽으로 이전하지 싶다.

그나저나 원자력 발전소에서도 폐열이 담긴 온수(원자로 냉각용)가 나오긴 한다. 그렇다고 해서 원자로를 소형화해서 대도시 근처의 지역 난방 공사를 운용할 수는 없으니(..; ) 이런 온수는 양식 같은 다른 용도로 활용되는 편이다. 원자력 발전소는 우주 기지와 마찬가지로 육지에서 최대한 떨어진 바닷가에 건설된다는 공통점이 있으니 말이다.

6. 차든지 뜨겁든지

"나는 네가 차든지 뜨겁든지 하기를 원하노라." 이건 성경에서 예수님 말씀의 직접 인용일 정도로 유명한 문구(계 3:15)이다.
물론 성경의 저 문맥에서 제일 좁은 뜻은 양자택일하라고 해서 진짜로 '차가운 극단'으로 나가지 말고 "영이 뜨거운 가운데"(롬 12:11) 주님을 섬기라는 책망 내지 독려이다. "그럴 거면 차라리 나가 죽어!" / "학교 때려치우고 공장이나 가!" 이런 부모나 선생의 막말 꾸중이 진짜로 애더러 공장 가거나 나가 죽으라고 하는 말이 아니듯이 말이다.

하지만 뭐, 좀 더 넓게 비유적으로는 "인간이라면 모름지기 이거 아니면 저거, 모 아니면 도 진영을 확실하게 골라서 화끈하게 살아라, 박쥐 같은 밍숭맹숭 회색분자 기회주의자가 되지 마라"라는 뜻으로 볼 수도 있다.

앞서 비유를 들었던 것처럼.. 폐열만 어중간하게 담긴 미지근한 물은 아예 펄펄 끓을 정도로 뜨거운 물이나, 얼음이 껴 있을 정도로 차가운 물에 비해서 효용이 낮다. 찬물과 더운물을 섞어서 미지근한 물을 만들기는 쉽지만, 미지근한 물이 저절로 찬물+더운물로 분리되지는 않기 때문이다. 열을 가하든 냉각을 시키든 에너지를 써야 한다. 이건 물이 위에서 아래로 흐른다는 것만큼이나 절대적인 사실이다.

그러니 "차든지 뜨겁든지 하길 원한다"란, "정체되거나 뒤쳐지지 말고 늘 전진하길 바란다", "아래로 떨어지지 말고 위를 향해 오르길 바란다" 같은 말을 "열역학적 엔트로피가 감소하는 쪽으로 나아가길 바란다"라는 비유를 동원해서 한 것이라 볼 수 있다.

그 밖에..

• 학창 시절에 열역학을 더 열심히 공부했으면, 비빔면을 끓여 먹을 때 이 정도 양은 물을 몇 번 헹궜을 때 면을 완전히 식힐 수 있을지를 숫자와 수식으로 모델링할 수 있겠다는 생각이 든다..;;
  
• 물에 대해서는 "10리터를 한꺼번에 끓이는 것보다 5리터부터 먼저 데운 뒤 나머지 5리터를 추가로 부으면 10리터 전체를 더 빨리 끓게 할 수 있다.", 심지어 "뜨거운 물이 더 빨리 언다" 같은 믿기 힘든 말도 존재한다. 물에다 날씬한 돌을 잘 던지면 수면에 몇 번 통통 튀는 것도 가능한데, 그것만큼이나 본인은 저런 현상은 어떻게 과학적으로 가능한지 입증할 만한 지식이 부족하다.
  
  
• 한국어는 '덥다'와 '뜨겁다', '춥다'와 '차갑다'의 차이가 존재하는 게 꽤 절묘한 것 같다. '덥다/춥다'는 사람이 느끼는 관점이고, '뜨겁다/차갑다'는 온도를 내는 해당 객체의 관점이다. "난 지금 덥다" / "난 뜨거운 남자다"처럼 말이다.
  
• 물리라는 학문은 계속 미시적으로 파고들다 보면 결국은 역시 '파동과 입자'로 귀착된다. 그리고 직선이나 포물선이나 갖고 노는 게 아니라 결국은 삼각함수의 형태로 표현되는 진동을 논하게 된다. 중력의 영향을 받지 않는 듯한 미시세계 입자들의 끊임없는 불규칙한 운동.. 일명 '브라운 운동'은 어떻게 벌어지는지, 걔네들은 무슨 원동력으로 계속 운동하는지, 텔레비전의 백색잡음 같은 움직임도 왜 발생하는지.. 따지고 보면 참 궁금한 게 많다. 이런 것도 열역학과 전혀 무관한 게 아니다.

Posted by 사무엘