비행기와 우주발사체의 관계

1. 비행기와 우주선의 하이브리드 가능성

본인은 예전에 자동차 겸 열차, 자동차 겸 비행기, 비행기 겸 선박처럼 하이브리드 교통수단에 대해 열거해 본 적이 있다. 심지어 같은 열차라도 가변 궤간이 가능한 놈, 같은 비행기라도 고정익과 회전익이 같이 가능한 놈이 있으니 이 분야도 창의적인 활용 가능성이 생각보다 넓다.
그런데 그때 본인이 미처 고려하지 못했던 조합이 있다. 바로 비행기와 우주선의 하이브리드이다.

잠시 이런 상상을 해 보자.
인천 공항에서 대한 항공 비행기(+ 겸 우주선)를 타고, 발사대가 아닌 활주로에서 사뿐히 이륙한다. 며칠 동안의 비행(??) 끝에 비행기는 아폴로 11호의 착륙을 기념하는 달 "고요의 바다 공항"에 우아하게 착륙한다. 비행하는 동안 객실에는 바깥 온도나 현지 시각뿐만 아니라 주변의 G값도 표시된다.

귀환할 때는 "승객 여러분, 우리 비행기는 잠시 후 지구 대기권에 재진입하게 됩니다. 약 5분간 지구와의 통신이 두절되며 진동이 발생할 수 있으니 안전벨트를 착용해 주셈.." 방송도 응당 나온다.
안개가 너무 짙으면 비행기가 결항되는 것처럼, 지구 밖에 태양풍 같은 게 너무 강해져 있으면 위험하기 때문에 우주 행 비행기는 결항된다.

이건 참 낭만적으로 들리는 이야기이지만 이렇게 간편하게 우주에 다녀오는 건 현실 내지 가까운 미래에는 요원한 일이다.
우주 발사체 내지 비행체를 단 분리 없이 일반 비행기의 역할까지 겸할 수 있게 만드는 건 현재의 인간의 기술로는 가능하지 않다. 둘은 엔진 구조가 엄청나게 다르고 비행 원리도 완전히 다르기 때문이다.

우주선을 비행기처럼 운용했다간 연료를 감당할 수가 없다. 핵 미사일을 쏠 때 무슨 활주로 이륙을 시켜서 띄우던가? 우주선의 기술은 대륙간 탄도 미사일 기술과 본질적으로 완전히 동일하다. 미사일 기술과 동일하기 때문에 냉전 시절에 우주 기술이 획기적으로 발전할 수 있었다.
우주선은 미사일을 쏘는 기술에다가 발사체와 엔진 크기를 더 키우고 연료를 출력 조절이 용이한 액체 기반으로 바꾸고, 안에 사람이 타는 공간과 각종 안전 장치를 넣었을 뿐이다.

그에 비해 항공역학적인 기체 설계는 어차피 공기가 없는 우주 공간에서는 전혀 유용하지 않다. 한쪽에 특화된 기술이 다른 한쪽에서는 전혀 쓸모가 없다.
사실은 지구처럼 양력을 이용한 대기권 비행이 가능한 행성 자체도 태양계에서 지구 말고는 없다.

전쟁이 스타크래프트 인게임이 아닌 것만큼이나 우주 비행 역시 스타크래프트 시네마틱 같은 게 아니다.
터보 팬/제트부터 램 제트, 로켓까지 다양한 엔진의 종류와 구분이 괜히 존재하는 게 아니다.

사용자 삽입 이미지
(게임에서는 종이비행기 레이쓰조차 대기권과 우주를 모두 잘만 드나들지만, 현실은.. -_-)

그렇게 SF물을 너무 많이 본 사람들은 실제 아폴로 우주선 사령선과 달 착륙선이 통상적인 비행기와 너무 동떨어지게 생긴 것을 보고 이질감을 느기께 된다. 날개 따위 없는 그냥 지상 구조물 캡슐처럼 생겼을 뿐..

사용자 삽입 이미지

그나마 역대 우주선 중에 비행기와 가장 비슷하게 생겼고, 지구 귀환 후에 바다가 아닌 육지 활주로 착륙이 가능했던 유일한 물건은 우주왕복선인데.. 얘도 지구 대기권만 벗어난 우주에 가는 용도이지, 지구 중력을 벗어난 우주까지 간 건 아니었다.

사용자 삽입 이미지

이렇듯, 비행기나 심지어 비행선처럼 우아하게 우주로 나가는 건 현재로서는 불가능하다.
1980년대에 나돌던 공상 과학 아이디어 중에서 정보 통신 분야는 오늘날 예상을 초월하여 달성되었지만 항공 우주 분야는 대부분 빗나갔다. 달과 화성에 기지는커녕, 이미 있던 우주왕복선과 초음속 여객기마저 대가 끊겼지 않은가?

1969년 7월 20일, 아폴로 11호 달 착륙은 가히 충격 그 자체였다. 우리나라에서는 이 날을 임시공휴일로 지정했으며, 공교롭게도 이 날에 맞춰 개통했던 경인 고속도로 연장 구간은 '아폴로 고속도로'라는 이름이 붙었다. 사람들도 개나 소나 아폴로라는 이름을 붙이면서 "미래의 과학 꿈나무 똑똑한 우리 아이는 아폴로 학원에 보내세요" 그랬다.

그랬는데 지금은 아폴로는 눈병 이름으로나 기억되고 있고.. 2010~20년대에 사람들에게 그만 한 충격을 주며 각인된 이름은 아폴로가 아니라 인공지능 '알파고'인 게 참 흥미롭다.
사실은 저 눈병(급성 출혈성 결막염)의 별명조차도 발견된 시기가 아폴로 11호의 달 착륙 타이밍과 일치하여 붙은 것이었다.

2. 철도 차량과 비행기의 국내 생산 업체

테란의 레이쓰, 발키리, 배틀크루저를 생산하는 미래의 업체는 기술력이 얼마나 될지 모르겠다만.. 다음으로 현실 얘기를 잠깐 해 보겠다.

1999년 7월 1일, 현대· 대우· 한진 중공업의 철도 차량 생산 부문을 통합해서 '한국 철도차량'이라는 합작업체가 출범하고 그게 훗날 '현대로템'으로 이름이 바뀌었다.
그런데 철도 차량뿐만 아니라 비행기를 만드는 업계도 비슷한 사정을 겪었나 보다. 1999년 10월 1일 국군의 날을 기해 현대 우주항공, 대우 중공업, 삼성 항공우주산업(업종 분리 이후 현재의 삼성/한화 테크윈)을 합병하여 '한국 항공우주산업'이라는 합작업체가 출범했다.

물론 보잉 같은 급의 대형 민항기까지 만드는 건 아니지만 경비행기, 훈련기, 헬리콥터, 무인기 정도는 뚝딱 만들고, 메이커급 전투기도 조립 면허생산 정도는 한다.

로템의 경우 본사는 철도 허브 도시인 의왕에 있고 공장 중 하나가 경남 창원에 있다.
항우산? KAI?는 본사와 공장 모두 경남 사천에 있다. 사천 공항이며, 인근의 공군 기지며, KAI 모두 비슷한 동네인 것 같다. 민간 지도에는 다 가려져서 나오지 않는다.
저기가 나름 우리나라의 항공 허브라고 봐도 될 듯하다. 철도 박물관이 의왕에 있다면, 우리나라 항공우주 박물관은 사천에 있다.

3. 지구 외의 행성에서의 비행 가능성

행성과 행성을 오가는 우주 비행이라는 건 로켓을 이용해 지구 대기권을 탈출하여 공전 궤도에 진입한 뒤, 그 다음에는 다른 천체의 중력에 끌려가거나 튕겨 나가는 고전역학을 예술적으로 조절하는 절차에 지나지 않는다. 잠깐씩 몇 분 동안 또 연료를 분사해서 가속하는 것도 있지만 나머지 대부분의 시간은 연료 없이 그냥 관성 비행이다.
이것 말고 그냥 한 천체 안에서 비행기를 띄우고 날아다니는 건 사정이 어떨까? 엔진 가동을 위해 필요한 산소 문제는 일단 빼고 생각하기로 한다.

  • 일단 진행 속도가 왕창 빨라야 양력이 생긴다. 그런데 한편으로 고속 주행과는 상극인 공기의 저항도 날개로(받음각) 잘 받아야 된다.
  • 날개의 받음각이 커지면 양력이 커진다. 그런데 그렇다고 그걸 무작정 키워 버리면 항력도 도로 걷잡을 수 없이 커지며, 기체는 실속에 빠져서 추락의 위험에 빠진다.

비행기 조종이란 건 이렇듯 서로 모순되는 듯한 여러 변수들을 적당히 조절해서 최적의 값이 나오는 지점을 찾아가는 과정이다. 그러니 날개에 달린 플랩이라는 물건도 비행기를 빨리 뜨게 할 때 쓰이지만(양력 증가), 착륙 후에 비행기를 빨리 감속시켜서 세울 때도 쓰이는 것이다(항력 증가). 그런데 플랩을 잘못 쓰면 착륙 직후에 비행기를 못 세우고 도로 띄워 버려서(양력 증가..) 기체에 대한 제동· 제어력을 상실하기도 한다. 이런 양날의 검 같은 면모는 열차나 선박 같은 타 교통수단의 운전에는 존재하지 않는 것 같다.

흔히 지구가 여러 복잡한 조건을 기적적으로 만족하여 생명이 탄생 가능했던 유일한 행성이라고 여겨지는데.. 이와 비슷한 급으로 지구만이 유체· 항공역학적으로 우리가 생각하는 비행기를 띄우고 날리는 게 가능한 유일한 행성으로 여겨진다. 적어도 태양계에서는 말이다.

달이나 수성은 대기가 없으니 날개고 양력이고 활강이고가 아무 의미가 없다. 굳이 공중으로 이동하려면 언제나 달 착륙선 같은 로켓을 띄워야 하며, 착륙할 때는 역시나 연료 역분사로 낙하 속도를 줄여서 내려앉아야 한다. 그리고 로켓은 연료 소모가 너무 극심해서 경제성이 떨어진다.

그 다음으로 금성과 지구와 화성은 공교롭게도 뒤의 행성이 앞의 행성보다 공기압이 거의 95~100배 더 옅다.
화성은 대기가 너무 옅기 때문에, 계산에 따르면 지상에서 초음속 자동차 급으로 달리며 공기를 받아야 양력이 생길까 말까라고 한다. 물론 고속 주행 자체에 공기 저항으로 인한 어려움은 지구보다 덜하겠지만, 그래도 어마어마하게 긴 직선 활주로가 필요하고 그만큼 사고 위험도 클 것이다.

반대로 금성은 공기가 워낙 뻑뻑한 덕분에 그냥 자전거 속도 정도로 달리면서 날개로 바람을 받으면 곧장 하늘로 뜰 수 있을 정도라고 한다. 양력이 아주 잘 생긴다. 다만, 어지간한 잠수함도 못 버틸 엄청난 압력인 95기압(거의 해저 수심 800m가량) 하에서 자전거 속도만치라도 달리는 게 선뜻 가능하겠는지는 별도로 생각할 문제다.;;
거기에다 고열 문제는 덤이다. 금성의 그 온도에서는 비행기 엔진이 전부 과열돼서 타 버릴 것이다.

참고로 금성은 중력가속도는 지구(9.8m/s^2)의 90% 정도이니(8.87m/s^2) 그렇게 큰 차이가 없다.
그리고 화성은 대기의 '비율'만 따지자면 거의 96%가 이산화탄소이며, 이는 의외로 금성과 동일하다. 농도만 훨씬 옅을 뿐..

목성 이후의 행성들은 그냥 설명을 생략하겠다.
목성은 중력가속도가 지구의 2배를 넘기 때문에(거의 22m/s^2) 거기서는 사람들이 자기 몸 가누기도 힘들 것이고 비행기가 뜨기도 그만치 더 힘들다. 물론, 거기는 아예 땅이 없고 거기 근접만 해도 그냥 초고압 유독가스와 방사선에 다 끔살 당할 것이다. (Quake 3의 fog of death 실사판)

나머지 행성들은 중력가속도가 그렇게 강하지는 않지만 극도의 저온과 악천후 때문에 여전히 지구 같은 낭만적인 비행이 불가능하기는 마찬가지이다.
공기가 적절한 배합과 양으로 구성돼 있고 순항 고도에 '제트 기류'라는 것까지 존재하는 지구가 그야말로 인류에게 축복이 아닐 수 없다.

Posted by 사무엘

2020/08/08 08:35 2020/08/08 08:35
, , , ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1782

1990년대 후반, Windows 95에서 98에서 넘어갈 무렵에 PC에는 USB 포트가 등장하고 마우스에는 휠이 추가되는 등 여러 변화가 일어났다.
그리고 그래픽 카드가 성능이 향상되면서 컴퓨터 한 대에 모니터를 두 대 이상 연결할 수도 있게 되었다. 이렇게 화면 공간을 키우니 컴퓨터 작업 생산성과 능률이 획기적으로 향상될 수 있었다.

그런데 이렇게 멀티모니터를 쓰는 건 다 좋은데 약간 불편할 때가 있다.
한창 제2 보조 모니터에서 작업을 하다가(탐색기 따위) 새 프로그램을 실행했는데 그 프로그램의 창은 언제나 다른 모니터(십중팔구 제1 주 모니터)에서만 나타나서 고개를 돌려야 하는 것 말이다. 그 프로그램은 무엇이 문제인 걸까?

마지막으로 종료되던 당시의 창 위치와 크기, 상태(특히 최대화 여부)를 기억해 뒀다가 다음에 재구성하는 프로그램이라면 뭐 더 할 말이 없다.
그리고 그런 것 없이 CreateWindowEx 함수에다가 CW_USEDEFAULT(알아서 해라~~)만 지정하고 때우는 프로그램이라면... 이 역시 논란의 여지가 없다. CW_USEDEFAULT를 해 주면, 같은 프로그램을 여러 번 실행했을 때 운영체제가 다음 창은 이전 창보다 약간 우측 하단에 배치해서 서로 겹치지 않게도 해 준다.

문제는 대화상자 기반의 프로그램이다.
그냥 운영체제의 제일 저수준 DialogBox 같은 함수만 쓰면 대화상자가 모니터나 parent(owner) 윈도우의 좌측 상단에 표시된다. 이는 일반적으로 바람직한 결과가 아니기 때문에 응용 프로그램이 창을 인위로 중앙으로 옮기는 후처리를 한다. MFC에도 이런 보정을 하는 훅 프로시저가 있다.

그런데 owner 윈도우가 딱히 지정되지 않았다면 한 화면 전체를 중앙 좌표 계산의 기준으로 삼아야 할 텐데, 이 화면이란 건 선택의 여지 없이 주 모니터의 화면으로 지정되곤 한다. 주 모니터 말고 보조 모니터를 기준으로 실행되게 할 수는 없을까?

프로그램을 실행할 때는 여느 대화상자를 띄울 때와 달리 parent 윈도우를 지정하는 게 없다. 그러니 사용자가 어느 모니터에서 작업을 하고 있는지도 알 수 없다.
이런 상황에 대처하기 위해 Windows에서는 프로그램을 실행할 때 기준으로 삼을 모니터 핸들을 주고받을 수 있다. 마치 WinMain 함수에 전달되는 명령 인자 문자열이나 창을 띄울 방식(SW_SHOW 따위)처럼 말이다.

일단, 타 프로그램을 실행하는 프로그램에서 모니터 정보를 직접 공급해 줘야 한다. 글쎄, 키보드 포커스를 받고 있는 윈도우가 속해 있는 모니터로 자동화의 여지가 없지는 않아 보이지만.. 일단 이건 굉장히 UI 종속적이고 인위적인 정보이다. 그렇기 때문에 운영체제가 자동화를 해 주지 않는다.

모니터 정보를 지정하면서 프로그램을 실행하는 함수로 일단 ShellExecuteEx가 있다.
SHELLEXECUTEINFO 구조체에서 fMask에다가 SEE_MASK_HMONITOR 플래그를 지정한다. 그 뒤 hMonitor에다가 HMONITOR 값을 주면 된다. 이 값은 MonitorFromWindow 같은 함수를 통해 얻을 수 있다.

저 구조체에서 hMonitor 멤버가 있는 자리에는 원래 hIcon이라는 멤버가 있었다. 얘는 도대체 왜 추가됐고 무슨 용도로 쓰이는지 알 길이 없다. 프로그램을 실행하는 데 무슨 아이콘을 지정할 일이 있는지(입력)?? 실행된 프로그램의 아이콘을 얻어 오는(출력) 것도 아니다. 그래서 현재는 이 자리가 hMonitor로 완전히 대체된 듯하다.

다음으로 모니터 정보를 받는 쪽에서는.. GetStartupInfo 함수를 실행해서 결과를 확인하면 된다. 그런데 그 방법이 좀 므흣하다.
STARTUPINFO 구조체에서 dwFlags에 STARTF_USESTDHANDLES 플래그가 지정되지 않았는데도 hStdOutput에 NULL이 아닌 값이 있으면 그게 실은 파일 핸들이 아니라 모니터 핸들이다. 요 값을 토대로 화면 좌표를 얻으면 된다. 따로 모니터 핸들이 온 게 없으면 예전처럼 주 모니터를 사용하면 되고..

Windows 탐색기는 프로그램을 실행할 때 그 탐색기 창이 표시돼 있는 모니터의 핸들을 저렇게 꼬박꼬박 넘겨준다. 그러니 Visual C++ IDE를 통해 실행하지 말고..;; 탐색기로 실행하면 모니터가 제대로 식별되는지를 테스트할 수 있다.

여기까지가 일단 MSDN에 문서화돼 있는 내용이다.
참고로, 앞서 언급했던 overlapped 윈도우의 CW_USEDEFAULT는 본인이 확인해 보니 확실하게 multiple-monitor-aware이다. 윈도우 클래스 이름과 모니터별로 마지막으로 창을 생성했던 위치를 기억하고 있어서 서로 겹치지 않게, 그리고 이 프로세스에 전달된 기본 모니터에 맞게 창을 적절한 위치에 생성해 주는 것으로 보인다. 그러니 프로그래머가 무슨 정보를 얻어 오고 지정하지 않아도 된다.

다만, MFC는 대화상자를 표시할 때 화면 중앙 보정만 해 주지, owner가 없는 대화상자에 대해 모니터까지 감안한 처리를 하지는 않는다. (최신 2019의 MFC의 소스 기준) 언제나 주 모니터를 기준으로만 처리하니 일면 아쉽다.

끝으로.. 본인은 의문이 들었다.
ShellExecuteEx도 궁극적으로는 제일 저수준의 프로그램 실행 함수인 CreateProcess를 호출할 텐데, CreateProcess로 직통으로 모니터를 지정할 수 없을까?

조금 검색을 해 보니 의문은 의외로 쉽게 해결되었다. 저 함수에다가 STARTUPINFO 구조체를 지정해 줄 때 모니터 정보를 같이 전달을 할 수 있었다.
dwFlags 멤버에다가.. 문서화되지 않은 0x400이라는 값을 주고, hStdOutput에다가 HMONITOR 값을 주면 된다.

그럼에도 불구하고 이 용법은 지금까지 MSDN에 단 한 번도 언급된 적이 없었다. kernel32 팀과 user32 팀이 서로 연계가 되지 않기라도 했는지, 정확한 이유는 모르겠다.
STARTF_MONITOR 같은 플래그가 정식으로 추가되고, STARTUPINFO 구조체도 SHELLEXECUTEINFO 구조체와 마찬가지로 hMonitor라는 멤버가 hStdOutput 자리에 공용체의 형태로 추가돼야 할 텐데 그렇지 못하다.

Posted by 사무엘

2020/08/06 08:35 2020/08/06 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1781

1. 파이썬

요즘 프로그래밍 언어는 네이티브 코드+수동 메모리 관리(= 가상 머신이나 GC가 없는) 분야에서야 C++이 무섭게 발전하면서 약진하는 중이다. D나 Rust나 델파이 같은 나머지 네이티브 코드 언어 진영은 요즘 어찌 지내나 모르겠다.

거기서 양상이 살짝 바뀌어서 VM 기반의 언어로는 Java와 C#이 대표적이다. C#은 매우 뛰어난 언어이고 기반이 탄탄한 건 사실이지만 PC와 Windows의 밖에서는 과연 쓸 일이 얼마나 있나 모르겠다. 안드로이드와 iOS 모두 앱 개발용으로 권장하는 주력 언어가 코틀린, Swift 등 생소한 것으로 바뀌었는데, 지난 수 년 동안 기존 언어(Java, Objective C)의 점유율은 어찌 바뀌었는지 역시 궁금하다.

이보다 표현이 더 자유로운 동적 타입 언어 세계에서는 닥치고 JavaScript 아니면 파이썬이 지존 압권 깡패로 등극했다. 펄, 루비, 루아.. 등등 필요 없고 이걸로 다 물갈이돼 버렸다. 특히 파이썬은 교육용과 실무용이라는 두 영역에서 완벽하게 주류로 자리잡았다는 것이 대단하고 신기하다.

대학교들 CS101 프로그래밍 기초 코스에서 가르치는 언어도 C, Java를 거쳐 지금은 몽땅 파이썬이다. 교육용이 아니면 일부 특수한 분야 한정의 마이너 언어에 그쳤던 과거의 베이식이나 파스칼과는 매우 대조적인 점이다. 한편, JavaScript는 웹의 세계 공용어라는 독보적인 지위를 획득했고 말이다.

네이티브 코드인 C++, 가상 머신 기반인 Java, 동적 타입인 파이썬.. 이렇게 등급과 종류를 불문하고 언어들에 한때는 객체지향 패러다임이 들어가는 게 유행이었는데, 21세기에 들어서는 함수형 패러다임도 필수가 돼서 익명 함수(람다) 정도는 지원해 줘야 아쉽지 않은 지경이 돼 있다.

C/C++, Java 같은 언어에만 파묻혀 살다가 컴파일 에러와 런타임 에러의 구분이 없는 언어..
catch되지 않은 예외 같은 에러를 잡고 나니 다음으로 소스 코드의 스펠링 에러를 접할 수 있는 언어를 쓰는 느낌은 참 묘하다.
그래도 컴파일 없이 바로 실행한다는 게 심리적으로 참 부담없고 가벼운 느낌을 준다. 먼 옛날에 Basic 쓰던 시절 이래로 얼마 만에 다시 경험하는 느낌인지?

  • 나눗셈은 정수/정수라도 언제나 실수가 되는구나. 이건 C/C++ 계열이 아니라 베이식/파스칼에 더 가까운 이념이다. 그래도 '같지 않음'이 <>가 아니라 !=인 것은 C/C++ 영향이다.
  • 비트 연산자는 & |로 두고, 논리 연산자를 and or이라는 단어로 분리한 것은 나름 양 계열의 특성을 골고루 적절하게 수용한 디자인인 것 같다.
  • 삼항 연산자 A ? B:C를 B if A else C로 표현한 것은.. 우와;;;;
  • 함수에 인자를 전달할 때 값만 그냥 전하기도 하고 경우에 따라서 config=100 이렇게도 주는 건.. C/C+++ 스타일과 objective C 스타일을 모두 접하는 것 같다.
  • 문자열이나 리스트 같은 복합 자료형에다가 상수배 곱셈 연산을 해서 복제 뻥튀기를 시키는 것도 상당히 유용하다. 단, 이 경우 내부에 있는 복합 자료형들은 shallow copy만 된다. 제대로 deep copy를 하려면 list comprehension 같은 다른 기법으로 원소들을 하나하나 새로 생성해야 한다.
  • 여러 변수에다 한꺼번에 대입하기, 그리고 리스트 원소들을 연달아 함수 인자로 풀어넣기...;;;
  • 코딩을 하다 보면 특정 자료구조 내부의 원소들을 range-based for 문으로 순회함과 동시에, 각 원소별로 1씩 증가하는 인덱스 번호도 같이 돌리고 싶은 때가 많다. 이럴 때 파이썬은 for i, elem in enumerator(set)라고.. enumerator를 사용하면 저 기능을 곧장 구현할 수 있다.. 오, 이거 사이다 같은데?
  • []는 배열, {}는 dictionary. 의도한 건지는 모르겠지만 JSON 자료구조와 딱 정확하게 대응한다.
  • 문자열에 "" ''을 모두 사용 가능한 건 SQL 같다. 다만, 문자로 표현된 숫자 리터럴과의 구분이 없다 보니, 'a'와 97을 상호 변환하는 건 베이식이나 파스칼처럼 별도의 함수를 써야 한다.

2. 각 프로그래밍 언어별로 없어서 처음에 좀 놀랐던 것들

  • JSON: JavaScript라는 프로그래밍 언어의 문법을 채용했다면서 정작 자신은 코멘트를 넣는 부분이 없고 정수 리터럴에 16진수 표기용 접두사가 없다. 얘는 오로지 machine-generation만 생각했는가 보다.
  • Java: int 같은 primitive type을 함수에다 reference로 전달해서 swap 같은 걸 시킬 수 없다. 그리고 가상 머신 환경에서 큰 의미가 없긴 하지만 sizeof 연산자도 없다.
  • 파이썬 1: goto가 없는 건 Java도 마찬가지이지만.. switch-case도 없다. 파이썬은 들여쓰기 구문이 콜론으로 끝나는 언어인데, 정작 C/C++계열에서 라벨과 콜론을 사용하는 문법이 저 동네에서 존재하지 않는 셈이다. 넣어 달라는 제안이 과거에 있긴 했지만 문법적으로 난감해서 봉인됐다고 한다. 뭐, 그 대신 얘는 elif가 있다.
  • 파이썬 2: 그리고 파이썬은 명시적인 const 속성도 없는 것 같다. 튜플이 값의 불변을 보장하는 자료형이기 때문에 const 테이블 역할을 같이 담당한다.
  • 파스칼: 오리지널 문법에서는 임의의 크기의 동적 배열을 만들 수 없다. 참고로 베이식은 배열의 크기 조절은 자유이지만 포인터가 아예 존재하지 않다 보니 리스트 같은 재귀 구조의 복잡한 자료구조를 구현하는 것 자체가 원천 불가능이다.
  • 익명 함수: C++의 람다만 그런 건지는 모르겠지만, 자기 자신을 간단히 가리키는 키워드가 없고 재귀호출을 구현할 수 없다. 그나마 구현했다는 것들은 다 주변의 다른 functor 등 갖가지 편법을 동원해서 매우 힘들게 억지로 구현한 것들이다.

사실, C/C++의 for문은 while문과 거의 동치일 정도로 조건 검사 지향적이고 range-based for는 21세기가 돼서야 도입됐다. 그러나 파이썬의 for문은 훨씬 더 range 내지 iterator 지향적이다.

그리고 베이식 같은 언어는 switch/case가 거의 if문의 연장선일 정도로 범위 지정도 되고 쓰임이 유연하지만.. C/C++의 switch/case는 그보다 제약이 심하다. 그 대신 그 제약을 이용해서 컴파일러가 최적화를 할 여지가 더 있다. (가령, 조건 검사 대신 테이블 오프셋 참조로..)

3. 언어 문법 차원에서의 지원

20여 년 전 먼 옛날에 스타크래프트 경기 중계방송이란 게 처음으로 행해지던 극초창기엔 경기 운영 노하우가 부족해서 이런 일이 있었다고 한다.
경기를 하는 선수 말고 화면 중계를 위한 옵저버도 게임에 join을 해야 하는데, 자기 기지는 없이 남들 시야 눈팅만 하는 상태로 참여하는 방법을 몰랐던 것이다.

그러니 그때 옵저버는 테란을 골라서 들어갔다. 자기 커맨드센터는 띄워서 맵 구석 모서리에 안 보이게 처박아 놓고, SCV 4기는 서로 공격시켜서 없앴다. 이런 궁색한 삽질을 해서 자기 존재를 최대한 없애 버린 뒤 선수들의 화면을 중계했던 것이다.

물론, 옵저버의 이런 자폭 플레이는 경기 시작 직후, 카메라가 잠시 각 선수들의 개인 화면을 비추고 있는 동안 최대한 잽싸게 행해졌다. 한편으로 선수들 역시 옵저버에게 자기 시야를 공개하는 설정을 매번 수동으로 해 줘야 했다.
선수가 옵저버의 커맨드센터를 고의나 실수로 부숴서 옵저버를 엘리시켜 버리는 건.. 그건 경기 진행 방해이며 규정상 거의 반칙 몰수패 사유가 됐을 것이다.;;

그러다가 잘 알다시피 경기용 맵은 특수하게 트리거를 조작해서 옵저버를 위한 전용 자리가 있는 "유즈맵, 커스텀 맵" 형태로 만들어지고 쓰이게 되었다. 이제 옵저버의 일꾼을 제거하고 커맨드센터를 치우는 삽질을 할 필요가 없어진 것이다.
하지만 경기 자체는 다른 특이 사항이 전혀 없고 건물 짓고 유닛 뽑아서 적 진영을 부수는 것밖에 없는데 매번 유즈맵을 쓰는 건 번거로웠다. 스타 프로그램 차원에서 일반 맵에다가 옵저버 참관 기능을 지원하는 게 제일 이상적이고 바람직했다.

결국 옵저버 참관 기능은 먼 훗날 스타의 1.18 패치에서 정식으로 도입됐다. 지난 1.08 패치에서 리플레이 기능이 추가된 것만큼이나 참신한 기능이다.
특히 이 참관 기능은 각 선수들의 개인 화면과 동급으로 진영별 자원 수, 생산· 연구 건물들의 내부 진행 상태까지 모두 볼 수 있어서 매우 편리하다. 과거의 유즈맵 옵저버로는 그런 게 가능하지 않았기 때문에 선수 개인 화면의 모습을 직접 봐야 했다.

이렇게 과거에 꼼수로 구현하던 기능들이 훗날 정식으로 가능해진 것의 예로는 C++ 프로그래밍이 떠오른다.
일례로, 복사나 대입이 가능하지 않은 클래스를 만들기 위해서 복사 생성자나 대입 연산자를 private에다가 미구현 상태로 박아 넣는 꼼수가 동원됐지만.. C++14부터는 = delete라는 더 완전하고 깔끔한 문법이 언어 차원에서 추가됐다.

Posted by 사무엘

2020/08/03 19:31 2020/08/03 19:31
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1780

한국어의 오묘한 면모

1. 청자를 배제한 1인칭 또는 2인칭

언어 의사소통이라는 게 기본적으로 화자와 청자 사이에서 이뤄지는 것이다 보니, 인칭대명사도 나와 너, 1인칭과 2인칭은 좀 특별하게 취급된다. I나 You가 아닌 다른 모든 사람은 제3자, 말 그대로 3인칭이 되며, 영어에서는 3인칭 단수에 대해 현재 시제 동사는 뒤에 -s가 붙기도 한다.

그런데 기본적으로 1인칭이나 2인칭이지만, "청자를 배제"하는 효과를 내는 대명사 내지 동사 굴절(활용??)이 존재하면 도움이 될 때가 있다. 이런 건 아무래도 주어 생략 눈치 100단과 높임법이 존재하는 한국어가 영어보다 더 발달해 있다.

대표적인 예는 '우리'와 '저희'이다. 1인칭은 복수형이 되면 나뿐만 아니라 주변의 다른 사람까지 포함할 수 있다. 하지만 '저희'는 '우리'와 달리 (1) 화자를 청자보다 낮출 뿐만 아니라 (2) 화자가 속한 집단과 청자는 서로 관계가 없는 별개라고 선을 긋는다.

이런 구분이 영어 we에는 존재하지 않으며, 언어학자에 따라서는 이건 가히 제4인칭이라고 보기도 한다. "저희나라는 틀린 말이니 우리나라라고 써야 한다??" 같은 성토가 존재할 수 있는 언어 자체가 한국어 말고는 거의 없을 것이다.

2인칭의 경우 화자에게는 you라고 부를 수 있을 정도로 가깝고 친근한 사람이지만 그렇다고 그 you가 청자를 의미하지는 않는 경우가 얼마든지 있다. 그래서 한국어는 '당신'이 웃어른에 대한 사실상 3인칭 높임말인데..
이게 2인칭일 때는 그다지 높이는 의도가 없고 낮잡아 부르는 말이라는 게 참 웃기는 짬뽕 같다. "당신이 뭔데 참견이야?"처럼.. 같은 단어가 2인칭과 3인칭을 오락가락 하는 건 한편으로 독일어의 Sie와 sie를 보는 것 같기도 하다.

CCM 가사에서 "당신은 평강의 왕"과 "당신은 사랑받기 위해 태어난 사람"에서 '당신'이 가리키는 대상이 서로 완전히 다르다는 것은 결국 통사가 아닌 화용 계층으로 가야만 분별할 수 있다.
뭐, 영어는 인칭 호칭이 한국어보다 훨씬 더 간결하니 하나님까지 you라고 서슴없이 가리키는 언어이다. 그나마 문자로 표기할 때는 첫 글자를 대문자로 써 주는 게 고작이다.

그리고 끝으로.. 한국어는 어휘 차원에서 청자 들으라고 하는 말이 아닌 '혼잣말'이 구분되는 굉장히 독특한 언어라고 한다. "그게 뭐였더라?"와 "그게 뭐였냐/뭐였니?"의 차이를 생각해 보자.
둘 다 똑같이 의문문이고 굳이 따지면 전자도 문맥에 따라서는 남에게 답을 듣고 싶을 때 쓸 수 있는 말이다. 하지만 골똘이 생각하면서 청자를 응시하지 않고 혼잣말로 중얼거릴 때 후자처럼 말을 하지는 않을 것이다. 한국어에는 이런 세밀한 문법적 기능이 존재한다는 뜻이다.

어떤 언어로든지 청자를 배제하는 1/2인칭, 높임법이나 성별에 구애받지 않고 단· 복수만 구분하는 간편한 대명사가 존재한다면 불필요한 오해를 줄일 수 있고 좋을 것 같다. 우리말 성경이 하나님이나 윗사람을 가리키는 2인칭 대명사를 '너, 그대'라고 번역하지를 못해서 몽땅 '주, 왕' 등으로 3인칭화하는 것은 상당히 불편하게 느껴지며 의미 왜곡까지 발생할 여지가 있는데.. 참 난감한 문제이다.

2. 용언들

한국어에서 활용되거나 접사가 붙는 양상이 좀 이상하게 꼬이고 있는 대표적인 용언을 몇 가지 정리하자면 다음과 같다. 뭐, 수 년 전에 이미 언급한 적이 있는 식상한 아이템도 포함해서 말이다.

(1) 바라다
개인적으로 ‘바랐는데’까지는 원리원칙대로 쓰지만, '바라요', '바람'(명사화된 형태)는 도저히 입에 익지 않아서 불가피하게 ‘바램’과 '바래요'가 튀어나온다. wind 바람과 구분하려는 심리도 있고, 또 ‘자라다, 발하다’ 같은 유사 형태의 다른 용언들은 그런 파생 명사가 존재하지 않는다는 점에서 비교도 된다. 쉽지 않은 문제이다.
‘바라다’는 “-(시)기 바랍니다”라는 형태로.. 평서문(통사)을 가장한 사실상의 정중한 명령문(화용)으로 쓰이고 있다. “-(시)면 고맙겠습니다/감사하겠습니다”는 명령에서 한 단계 내려가서 화용론상의 청유, 부탁에 가깝고 말이다.

(2) 날다
‘나는’이라고만 쓰면 체언+조사 형태와 구분이 안 되니 틀린 줄 알면서도 자꾸 ‘날으는’이라는 대체제가 쓰인다. 아니면 ‘하늘 나는’ 내지 ‘비행하는’이라고 말을 바꿔서 혼동을 줄여야 한다. UFO를 ‘미확인 비행 물체’라는 한자어 말고 순우리말로 도대체 어떻게 깔끔하게 설명할 것인가?

(3) 맞다
동사와 형용사의 경계가 완전히 난장판이다. 원래는 동사이지만 ‘알맞다, 걸맞다’ 같은 비슷한 형용사들이 용법에 영향을 주는 게 틀림없다.
그리고 반의어인 ‘틀리다’는 잘 알다시피 현재 과거 시제 경계가 완전 난장판이다. 이게 ‘다르다/틀리다’ 구분까지 난장판으로 만드는 데 일조하고 있다.

(4) 우습다
‘웃다’의 사동형 동사인 ‘웃기다’가 ‘우습다’라는 기존 형용사의 의미와 용법을 대체해 온 게 어제 오늘 일이 아니다. 아직까지는 원래 있던 ‘우습다’가 더 격식 있는 점잖은 말투로 여겨지지만 그런 인식이 언제까지 유지될지?
왜 이런 일이 생기는 걸까? 이건 옳다/그리다의 가치 판단이 필요한 현상일까? 내 역량으로는 정확하게 분석을 못 하겠다.

(5) 좋다/좋아하다, 싫다/싫어하다
good와 like의 관계, 그리고 "난 네가 좋다/싫다" 같은 말을 영어로 어떻게 표현할지를 생각해 보면 뭔가 묘한 느낌이 든다.
한국어는 영어와 달리 "덥다/춥다"(사람이 느끼는 결과)와 "뜨겁다/차갑다"(사람에게 느낌을 주는 공기, 물이나 다른 물체가.. 혹은 사람의 마음이)의 구분이 존재하는 언어이다. 저기서 "좋다/싫다"는 마치 "덥다/춥다"처럼 사람이 느끼는 결과 관점을 나타내는 형용사일 것이다.

(6) 모르다
내가 아는 언어들 중에 do not know가 타동사 한 단어로 딱 떨어지게 존재하는 언어는 모국어인 한국어 말고는 없다. 신기한 노릇이다.

3. 기억에 남는 단어들

  • 시력교정술인 '라식과 라섹', 폭염 속에서 발생하기 쉬운 '일사병과 열사병'. 요런 건 뭔가 비슷하면서 내부 디테일은 다른 용어쌍인 것 같다.
  • 충전은 일차적으로는 전기를 보충하는 것이지만 뭔가 리소스를 채운다는 뜻에서 교통카드 액수 보충, 휴식과 회복 같은 뜻으로 의미가 확장되고 있다. 물론 한자가 다른 充塡도 있다.
  • 포장도.. wrap과 pave는 서로 완전히 다른 뜻이긴 하지만, 도로를 포장하는 것도 노반을 싸매고 꾸민다는(?) 뜻과 그리 심하게 이질적이지 않은 것 같다. 앞의 '충전'의 의미 확장과 비슷하게 말이다.
  • 大/小가 쓰였지만 크다/작다의 의미가 많이 퇴색한 것이 좀 있다. 대학(고등교육) 대포(무기), 소설(문학..) 소포(우편물)

4. 스타크래프트 게임의 종족별 나레이션

스타크래프트가 출시된 지 20년이 훌쩍 넘었다는 게 믿어지지 않는다. 지금 2020년은 옛날에 PC 통신에서 큰 인기를 끌었던 소설 “환상의 테란”에서 상상하고 묘사하던 미래 배경이기도 하다.

스타는 처음 나왔을 때는 한국어 UI가 없었고 심지어 인게임 채팅창에서 한글 입력조차 되지 않았었다. Localization에 관한 한 불모지였다. 그러다가 스타 2라든가 리마스터 에디션이 나오면서 완벽하게 한국어로 번역되고 더빙까지 됐다. 컴퓨터 하드웨어 성능이 더 향상되었으며, 또 잘 알다시피 한국에서 스타가 넘사벽 급의 인기를 끌었기 때문이다. 처음에 스타가 로컬라이즈가 된 언어는 오히려 일본어였는데 그건 싹 묻혀 버렸다.

개인적으로는 3종족의 아나운서 나레이션을 모두 다른 문체로 번역했어야 했다고 생각한다. 자막은 합쇼체로 통일하더라도 음성 나레이션은 다르게 말이다. 몽땅 다 똑같이 합쇼체로 해 놓으면 너무 길기도 하고 종족별 개성이 살아나지 못한다.

  • 프로토스는 누가 봐도 점잖고 근엄한 분위기이니 디씨 같은 “핵 공격이 감지되었소. 파일런이 더 필요하오.”가 돼야 할 것이다.
  • 테란은 여성 부관이 사령관에게 보고하는 형태이니, 유구한 군대 말투 다나까를 반영하여 지금처럼 “핵 공격이 감지됐습니다. 서플라이가 더 필요합니다.”로 할 수도 있고.. 아니면 부관이 기계인간 사이보그인 걸 감안하여 무전 주고받듯이 뚝뚝 끊어서 “핵 공격 감지됨. 보급고 추가 요망”처럼 할 수도 있다.
  • 저그는 뭔가 공동체 같은 느낌이 드니 구어체 반말까지 생각할 수 있다. “핵 공격이 감지됐다! 오버로드를 더 뽑아야 돼.”

영어 원문은 주어가 다르다. 똑같이 미네랄이 부족해도 플토는 You’ve not enough minerals이지만 저그는 We require more minerals이지 않던가? 영어에 you와 we의 차이가 있다면 한국어는 합쇼체와 해라체의 차이가 존재하는 것이 합당하다.

스타크 세계관이 한국에서 주도적으로 창작됐고 스타라는 게임이 한국에서 만들어졌다면 세 종족의 특성과 개성에 맞게 나레이션의 형태도 저렇게 달라졌을 거라는 게 내 생각이다.
한국어에 기왕 복잡한 조사(체언)와 어미(용언)들이 존재한다면, 그것들을 제 역할을 발휘할 수 있는 곳에 최대한 잘 활용해야 할 것이다. 특히 번역을 할 때 말이다.

Posted by 사무엘

2020/08/01 08:35 2020/08/01 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1779

미국이 세계 대다수 나라들과 달리 일상생활에서 미터법을 쓰지 않는다는 것은 잘 알려진 사실이다. 그러니 거기에서 정착해서 살려면 인치, 마일, 화씨 같은 생소한 단위에 익숙해져야 한다.
그런데 거기는 용지의 표준 크기도 A4가 아니다. 이런 것도 차이가 있을 거라고는 미처 예상하지 못했는데.. 그냥 나의 단견이었다. 애초에 길이 단위계가 일치하지 않는 나라인데 용지의 표준 길이 역시 얼마든지 덩달아 일치하지 않을 수 있을 테니까..

미국에서 표준으로 쓰이는 용지 크기는 '레터'라고 해서 가로 21.59cm, 27.94cm이다. 인치로 환산하면 8.5 * 11로 딱 떨어진다. 210 * 297인 A4보다 가로는 약간 더 길고, 세로는 약간 더 짧다. 그 동네엔 레터의 자매품으로 '리갈 legal'이라고 폭은 동일한데 세로로 훨씬 더 긴 용지도 있다.
으음, 그러고 보니 본인은 이 시점에서 우리나라도 대중적으로 쓰이는 종이 규격이 변화가 있었다는 사실을 떠올리고 관련 자료를 찾아보게 되었다.

먼 옛날에는 전지부터 시작해서 'n절지'라는 명칭의 종이가 보편적이었다.
제일 큰 전지는 학교 미술 과제나 교회 수련회 과제로 뭔가 가족이나 조 단위의 글· 그림 컨텐츠를 만들 때 썼다. 2나 4절지는 프레젠테이션 프로젝터라는 게 없던 시절에 괘도라는 교보재를 만들 때 쓰이는 크기였다. 즉, 걔들은 개인이 휴대하는 인쇄· 출판물이 아니라 대중을 향한 전시· 게시용이었다.

8절지와 16절지 정도로 작은 게 휴대용 책이나 유인물 크기이다.
그런데 N절지라는 말은 '전지'라는 제일 큰 종이를 반반씩 접어서 N등분했다는 뜻일 뿐, 기준인 전지의 절대적인 크기를 규정하지는 않는다. 저때 8절지를 반으로 접은 16절지는 내 기억으로 지금의 A4 용지보다는 작았다. 저 규격의 정체는 무엇일까..??
1부터 16까지 2의 승수 단위로 쓰이는 게 많은 것이 마치 음악에서 음표· 쉼표의 크기를 보는 것 같기도 하다.

옛날에 공책, 연습장, 혹은 아무 제본도 안 돼 있는 쌩종이 갱지(?)는 오늘날의 A4용지만치 새하얗거나 두껍지는 않았던 것 같다. 그렇다고 해서 학교 시험지나 신문지 급으로 누런색 회색이 대놓고 느껴질 정도의 저질인 것 역시 아니지만.. 어쨌든 낙서나 필기를 하는 용도로 그런 종이가 쓰였다. 거기에다 미술 활동을 위해서는 좀 더 두꺼운 도화지가 쓰였다.

그리고 세월이 흘러 컴퓨터와 프린터라는 걸 접하게 됐는데.. 그 시절에 프린터의 주류는 '찌이익~~' 시끄러운 소리로 악명 높던 도트 프린터였다.
이 도트 프린터는 동작 원리가 타자기의 연장선이나 다름없었다.
동작 전에 초기화 같은 건 일체 필요하지 않고(수력 발전과 비슷..??), 페이지라는 개념이 전혀 없이 오로지 줄(line)이라는 개념만 있을 뿐이었다.

그때 도트 프린터에는 80칼럼짜리 또는 132/136칼럼짜리라는 두 종류의 전용 용지가 쓰였다.
80칼럼은 그야말로 20세기 중반, IBM의 펀치 카드의 줄당 문자 수에서 유래되어서 TTY(전신 타자기)와 컴퓨터의 텍스트 모드에까지 계승된 매우 유서 깊은 규격이다.

80칼럼 용지는 폭이 24cm로 A4의 가로폭보다 더 크고, 양 옆에 세로로 일정 간격으로 원형의 구멍이 숭숭 뚫려서 프린터의 급지 트랙터에 걸리게 돼 있다.
그리고 용지가 세로로 길다랗게 이어진 형태이며, 사용자가 필요하면 구간 구분을 위해 주욱 뜯을 수 있다. 이 정도면 나름 실용적인 디자인이다.

사용자 삽입 이미지

80칼럼보다 폭이 더 큰 13x칼럼 용지도 세로의 구획 간격은 11인치(28cm)로, 80칼럼과 동일하며 미국 표준인 레터와도 동일하다.
라인 피드(다음 줄), 폼 피드(다음 페이지) 같은 명령이 제어 문자로 존재하며, 과거에 인쇄용 비트맵 폰트는 화면용과 달리 90도 transpose되어 있는 게 다 이런 기술 배경 때문이었다.
화면용 폰트는 각 글자를 상에서 하로 찍는 것을 좌에서 우로 진행해야 해서 좀 번거롭지만, 전치시킨 인쇄용 폰트는 한 방향으로만 쭈욱 찍으면 되기 때문이다.

본인은 이런 도트 프린터 용지 실물을 본 적이 있다. 하지만 요즘은 영수증 인쇄용으로도 도트 프린터 방식이 퇴출된 걸 보면 참 격세지감이 느껴진다. 아직도 도트가 쓰이는 곳은 은행 ATM기의 통장 정리 기능밖에 없지 싶은데 이제는 종이 통장도 거의 퇴출 단계이니...
그렇게 도트가 한물 가고 1990년대 이후 잉크젯 프린터라는 걸 구경하면서부터 본인도 A4 용지라는 것을 처음으로 접하게 된 것 같다.

그럼 다시 전지 얘기로 돌아온다.
A계열의 전지, 즉 A0은 종횡비가 sqrt(2):1이면서 넓이가 1제곱미터에 대응하는 크기라고 정의된다. 종횡비가 저렇게 잡힌 이유는 반으로 접어도 가로· 세로 축만 바뀐 채 종횡비가 재귀적으로 동일하게 유지되게 하기 위해서이다. 음악으로 치면 평균율처럼..??
숫자로 표현하면 841 * 1189밀리미터이며, A1~n은 저걸 반으로 쭉쭉 접은 물건들이다. 이게 국제 표준이며, 한국 역시 이를 따른다.

그에 비해 B계열 전지는 종횡비는 동일하게 sqrt(2):1이면서 넓이가 1.5제곱미터인 놈이다. 그래서 1030 * 1456에서 시작한다. B4는 257 * 364, B5는 182 * 257이 되며, B4가 시험지에 얼추 대응하는 크기이다.
요게 정석이지만.. 일각에는 폭을 1m, 길이를 1414로 맞춘.. 바리에이션 B도 있는 것 같다. 넓이가 아닌 길이에서 미터를 맞춘 셈이다. 톤이라는 무게 단위에 여러 바리에이션이 있고, 정보량 단위에도 1000/1024 바리에이션이 있는 것처럼 말이다.

끝으로, 크기가 A와 B의 얼추 중간인 C계열도 있다. 하지만 얘는 정확한 sqrt(2)라고 보기엔 오차가 좀 큰 것 같고, 길이나 넓이가 정확하게 둘의 중간이지도 않은 것 같고.. 존재의 목적과 의미가 뭔지 모르겠다. 태어나서 지금까지 실물로나, 용지 종류 목록에서나 한 번도 본 적 없다. 일단 C0의 크기는 917 * 1297이라는 것만 적어 둔다.

오늘날은 가정용으로도 컬러 레이저 프린터가 쓰일 정도로 과거에는 상상도 못 할 정도로 기술이 많이 발전되고 대중화됐다. 하지만 A4보다 더 큰 B4 내지 A3 용지를 뽑는 프린터는 여전히 거의 눈에 띄지 않기 때문에 전문 인쇄소에 의지해야 한다. 이건 기술 문제가 아니라 그냥 수요가 없기 때문일 것이다.

지금까지 도트 프린터 전용지를 포함해 국제 표준 ABC 용지에 대한 얘기가 나왔다.
맨 먼저 언급했던 컴퓨터 이전의 전통적인(?) 종이는 일명 "4*6판 전지"라고 불리는 788 * 1090 크기를 기반으로 두고 있다. 얘는 sqrt(2) 종횡비가 아니며 그렇다고 6/4도 아니다. 어디서 무슨 근거에서 유래된 크기인지, 한국 말고 통용되는 곳이 더 있는지는 잘 모르겠다.
스케치북이나 도화지 등 미술 쪽에 쓰이는 종이는 이 전지의 8절지이며, 이 규격은 책을 만드는 데도 쓰인다고 한다.

그리고 이것보다 더 작은 "국판"이라는 것도 있어서 국판 전지는 636 * 939이다. 종횡비는 그 어느 기존 규격과도 정확하게 일치하지 않는 것 같은데, 얘 역시 출처와 유래를 알 길이 없다. 얘 역시 "4*6판"과 더불어 책 만드는 용도로 주로 쓰인다.

지금까지 논의되었던 종이들의 크기를 표로 정리하면 다음과 같다. 먼저 sqrt(2) 종횡비인 국제 표준 ABC를 나열하였다.

구분 A B C
0 841 * 1189 1030 * 1456 917 * 1298
1 594 * 841 728 * 1030 648 * 917
2 420 * 594 515 * 728 458 * 648
3 208 * 420 364 * 515 324 * 458
4 210 * 297 257 * 364 229 * 324
5 148 * 210 182 * 257 162 * 229
6 105 * 148 128 * 182 114 * 162

다음은 한국 재래식(?) 규격이다.

구분 4*6전지 국판
전지 788 * 1090 636 * 939
2절지 545 * 788 468 * 636
4절지 394 * 545 318 * 468
8절지 272 * 394 234 * 318
16절지 197 * 272 159 * 234
32절지 136 * 197 117 * 159

다음은 세로 길이가 11인치로 동일한 도트 프린터 및 미국 표준 규격이다..

종류 크기
도트 80 240 * 280
도트 132 380 * 280
레터 216 * 280

수많은 종이들을 한 치의 오차 없이 가로와 세로로 정확하게 잘라서 직사각형을 만드는 건 궤간을 정확하게 유지하면서 긴 철길 레일을 깔거나 차선을 그리는 것과 비슷한 일일 것 같다.

요즘이야 책 출판 시장은 인터넷에 밀려 많이 위축되고 침체된 게 사실이다. 특히 사전류는 치명타를 맞은 것 같다.
하지만 처음부터 끝까지 정독하는 부류의 종이책은 모니터 화면이 대체할 수 없는 독서 접근성을 제공하며, 휘발성이 너무 강한 인터넷 텍스트보다 권위와 공신력이 훨씬 더 높다. ISBN 코드가 기재된 책은 인류 역사상 이런 저자와 이런 문헌이 존재했다는 사실이 기록으로 영원히 남기 때문이다. 그렇기 때문에 종이책이 무슨 우체통이나 공중전화와 비슷한 급으로 명맥만 유지하는 레거시로 전락하지는 않을 것이다.

예로부터 우리나라는 외국에 비해 책의 외형이 필요 이상으로 사치스럽다는 비판이 있었다. 내용에 비해 쓸데없이 크고, 종이는 너무 크고 재질이 고급스럽고.. 재질이 고급스러워서 나쁠 것은 없지만 그게 다 책값의 불필요한 상승으로 이어지니 문제이다.

특히 옛날과 달리 '문고판'이라고 A5도 아닌 무려 A6.. 주머니에도 쏙 들어갈 정도의 작고 아담하고 저렴한 책이 전멸했다고 한다. 아무 이유 없이 없어진 건 아니고 아마 경제성이 떨어졌기 때문일 것이다. 소비자들이 내용이 아니라 비주얼을 보고 책을 고르는가 보다.

그에 반해 작은 걸 좋아하는 일본은 1980년대에 수많은 문고판 교양 서적들이 쏟아져나왔으며 내가 알기로 지금도 그러하다. 특히 과학 분야 말이다. 어릴 때부터 그런 양서를 접한 뒤에 나중에 위대한 과학자가 된 사람도 당연히 적지 않았을 테고..
한국의 출판인들은 그런 일본을 부러워하면서 그런 책들 판권을 사서 번역해서 비슷한 형태로 출간하느라 여념이 없었다. 혹은 일각에서는 교통· 통신이 불편하던 시절이니 안 걸릴 거라고 믿고 무단 표절도 했다.

한자 때문에 글자 크기를 무작정 깨알같이 작게 줄이기도 어려웠을 텐데 어째 책을 그렇게 작게 만들 생각을 했나 모르겠다. 그나마 세로쓰기를 해서 공간을 확보한 거라는 의견도 있지만, 세로쓰기는 다른 단점도 크기 때문에 이에 대해서는 논란의 여지가 있다.
종이의 크기 얘기를 하다가 책과 독서 문화.. 뭐 이런 사회 이슈 얘기까지 잠깐 논하게 됐는데.. 선진국 강대국은 출판 문화와 국민들의 독서 문화부터가 좀 남다르긴 해 보인다.

글이 좀 길어졌는데.. 우리는 종이의 크기와 종횡비, 텔레비전이나 모니터의 종횡비, 그리고 극장 스크린의 종횡비에는 다양한 역사적· 기술적 배경과 사연이 존재한다는 것을 알 수 있었다.
그럼 다음으로, 종이의 종횡비의 연장선 차원에서.. 나라별 국기들의 종횡비에 대해 논하고서 글을 맺도록 하겠다.

지구에는 200여 개의 나라가 있고 나라에는 나라의 상징인 국기가 있다. 그런데 국기의 도안뿐만 아니라 화면의 가로 세로 종횡비도 생각보다 제각각이다.
세계적으로 가장 흔한 종횡비는 3:2이다. 태극기를 비롯해 중국과 일본의 국기도 이와 동일하다.
그 다음으로 흔한 건 2:1로, 당장 북한 인공기부터가 공식적으로는 저 비율이다.

이것들 말고 마이너한 종횡비로는..
4:3이 있고 완전 정사각형 1:1도 있다. 심지어 토고의 국기는 이런 데에서까지 쓸데없이 수학적인 걸 추구했는지 종횡비가 황금비(1.618..)이다..;; 지갑 속 신용카드의 종횡비와 같다는 뜻이다.
네팔은 세계에서 유일하게 국기 모양이 사각형 자체가 아니며, 세로가 가로보다 더 길기까지 하다. 다만, A4 용지라든가(루트2 :1) 와이드 화면 16:9 종횡비인 국기는 내가 들어 보지 못했다.

이런 국기 종횡비를 보고도 철도가 떠오르는 게 있다. 마치 국가별 철도 궤간의 차이를 보는 것 같다. 3:2가 이 바닥의 표준궤 1435mm와 비슷하지 않나 하는 생각이 든다.
물론 국기의 종횡비쯤이야 철도 궤간이나 통행 방향, 전압처럼 산업 차원에서의 표준화가 필요한 분야는 전혀 아니니, 뭐 제각각 따로 놀아도 할 말은 없다. 자국 내에서 자기 국기만 게양할 때에야 자기 마음대로 아무 비율과 도안으로 게양하면 그만일 것이다.

그러나 여러 나라 국기들을 획일적인 종횡비로 한데 진열할 때도 있다.
그러니 보편적인 3:2나 2:1 정도의 종횡비에다 공간을 맞출 때는 내부 도안을 이런 식으로 보정· 재배치한다는 식의 통일 규격도 필요하지 않나 싶다.

Posted by 사무엘

2020/07/29 08:35 2020/07/29 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1778

좌석버스 이야기 외

1. 좌석버스

버스라는 대중교통을 더 세부적으로 분류해 보면 좌석버스라는 등급이 있다. 이게 생각보다 흥미로운 물건이다.
얘는 입석형 도시형 시내버스에 비해 말 그대로 좌석이 많고 더 장거리를 달리며 요금도 약간 더 비싸다. 일부 구간은 고속도로나 자동차 전용 도로에서 오랫동안 씽씽 달리기도 한다. 완행 입석 시내버스와 달리 전기나 CNG 차량, 저상 버스가 눈에 띄지 않고 그냥 고상+디젤 일색이다.

하지만 얘는 전용 터미널에서만 타는 장거리 시외/고속버스 같은 급이 아니다. 그렇기 때문에 여느 버스 정류장에서 쉽게 탑승 가능하며 다음과 같은 점도 시외/고속버스와 차이가 있다.

  • 앞문이 간지나는(?) 스윙 방식이 아니라 여전히 시내버스 같은 폴딩 방식이다.
  • 여전히 하차 전용 중문을 갖추고 있다. 다만, 좀 더 급행/광역에 특화된 좌석버스 중에는 중문이 없는 것도 있다.
  • 큼직한 우등형은 있을 리가 만무하고.. 좌석에 안전벨트가 있긴 하지만 거의 유명무실 상태이다.
  • 타이어에 휠캡이 달려 있지 않다. 옛날에는 이 휠캡이 뭔가 왕관과도 같은 고속버스의 상징이었는데.. 그러고 보니 2000년대 이후부터는 고속버스도 휠캡을 잘 장착하지 않는 것 같다.
  • 객실 아래의 짐칸 같은 게 쓰이지 않는다.

사용자 삽입 이미지사용자 삽입 이미지
(추억의 고속버스 휠캡. 출처는 한국 버스 연구회)

그러니 좌석버스는 위상이 여러 모로 시내와 시외의 중간인 셈이다. 좌석이 많다는 관점에서 좌석버스라고 불리는 게 보통이지만, 급행· 직행이나 광역이라는 수식어가 붙기도 한다. 여기서 직행이라는 건 시외버스에서의 '직행'과는 약간 다른 개념이다.
얘들은 관할 범위가 완벽하게 특정 지역구 내부에 한정된 게 아니고 그렇다고 완벽하게 전국구도 아니다 보니, 종류가 다양하고 버스들의 도색도 다양한 편이다. 서울/수도권 기준으로 이런 버스들이 존재한다.

  • 서울시 관할의 직행 좌석: GRYB 중에서 R에 해당하는 그 물건이다. 번호는 9로 시작하는 네 자리이다. 허나, 지금은 Y와 마찬가지로 많이 몰락해서 4권역(9403, 9401, 9408 등)과 7권역(9703 등..)에 소수밖에 존재하지 않는다.
  • 경기도 관할의 직행 좌석: 하남 9301, 구리 1650 같은 게 떠오른다. 차량의 외형은 지역마다 케바케이지만 대체로 서울과 비슷하게 빨강인 편이다. 단, 서울 버스는 온통 빨강 단일색인 반면, 경기도 버스는 위쪽만 붉고 아래쪽은 희다.
  • 광역급행: 중앙 정부인 국토교통부에서 노선을 고시한 좌석버스로, 번호는 M으로 시작하는 네 자리수이다. 기존 좌석버스들보다 더 직선화 고속화를 추구해서 더 빨리 간다. 차량은 파란 도색이며 중문이 없다.
  • 경기도 급행: 경기도에서 자체적으로 신설한 노선으로, 광역급행의 경기도 버전이라고 생각하면 된다. 번호는 G로 시작하는 네 자리수이다. 파랑-초록-노랑의 꽤 알록달록한 도색이며, 2층 버스가 유난히 많이 눈에 띈다. G라는 이니셜을 이용해서 '굿모닝 버스'라고도 부르는 것 같다.

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

하긴, 서울시는 환경 보호를 위해 이미 들어오려는 외부 차량들을 억제시키느라 정신이 없다. 그러니 경기도나 중앙 정부 말고 서울시에서 관할하는 광역 좌석버스가 근본적으로 많을 수가 없을 것이다.

이런 버스 업계와 달리, 철도에는 롱시트 통근형 입석형 전동차를 쓰는 도시철도· 광역전철이 아니면 그냥 일반열차 운임 체계 기반인 무궁화호 이상의 장거리 열차이다. 운영 방식이 좀 경직돼 있다.
그 중간 단계를 표방하는 누리로 전동차라는 게 도입되긴 했지만 현실에서는 그냥 무궁화호와 별 차이 없어 보인다.

신분당선은 코레일 계열이 아닌 광역전철이라는 새로운 장르를 개척했다. 그 뒤 앞으로는 고심도 급행 전철인 GTX가 저 광역급행 버스의 고속철 역할을 감당하지 않을까 생각해 본다.
롱시트가 아닌 좌석형이면서 고상홈에서 타고 내리고, 정차역이 적고 빠르고, 운임은 기존 시내버스· 지하철과 환승 할인이 되는.. 그런 광역전철이 좀 필요해 보인다.

2. 버스와 트럭의 주행 관련 규제

자그마한 5인승 자가용 승용차만 운전하는 대다수의 사람들은 실감할 일이 없겠지만, 이보다 덩치가 약간만 더 큰 차들에는 (1) 속도 제한 장치가 의무적으로 달려 있다.
먼저 사람이 많이 타는 승합차 계열부터 살펴보면, 지난 2013년 여름부터 11인승 이상 승합차에 110km/h 이상으로는 아무리 밟아도 가속이 되지 않는 리미터가 강제 장착되기 시작했다. 이건 많은 논란을 불러일으켰다.

승합차는 자동차세가 월등히 저렴해서 좋다. 승용차와는 달리 자가용도 영업용과 동일하게 배기량과 무관한 낮은 세금이 부과되기 때문이다.
하지만 승합차는 고속도로에서 추월 하나 제대로 못 할 정도로 차가 고자가 되니 단점이 장점을 묻어 버렸다. 리미터가 달리지 않은 기존 중고차의 가격이 더 오른다거나, 그냥 9인승 SUV/밴에 수요가 몰리는 기현상이 벌어졌다.

트럭은 3.5톤 이상부터는 아예 90km/h 리미터가 강제 장착된다. 이건 승합차보다 더 전부터 있었던 규제인 것 같다.
하지만 한 탕이라도 더 뛰어야 먹고 살 수 있고 바빠 죽겠는데, 엔진 속 컴퓨터를 해킹해서 속도 제한 장치를 불법으로 무력화시키고 질주하는 승합차나 트럭이 심심찮게 보인다. 아이폰 탈옥과 개념적으로 비슷해 보인다만..

하긴, 대형 트럭은 디젤 엔진 기반이다 보니 속도 규제뿐만 아니라 (2) 환경 규제도 꽤 까다롭게 걸려 있다.
유로4 이상의 규제를 만족시키기 위해 DPF라고 미세먼지 저감 장치의 장착과 가동이 의무화돼 있는데, 이것도 검사받고 혜택을 받을 때만 장착 인증을 하고서는, 실제 운행할 때는 불법으로 끄거나 떼어 버리는 경우가 있다. 얘는 작동 과정에서 엔진 성능과 연비를 일부 깎아먹으며, 괜히 차량의 유지 비용만 증가시키는 잉여 계륵 같은 구석이 있기 때문이다.

그리고 DPF에 SCR 등 온갖 배기가스 정화 장치를 돌려 놨다 해도 도를 넘는 막장 과적 앞에서는 답이 없다.
디젤 엔진이 제일 더티해지는 때는 바로 저회전 상태에서 큰 토크가 필요한 첫 출발 가속 시점이다. 이때 연료가 제대로 연소하지 못해서 시커먼 매연이 제대로 뿜어져 나오는데, 차가 설계 한도 이상으로 너무 무거운 상태이면 이런 상태의 지속 시간이 길어진다.
연료를 왕창 집어넣었는데 엔진이 빠릿빠릿 못 돌고 있으면 정화 장치들도 감당을 못 하고 매연이 더욱 심해진다.

과적은 도로 파손, 차량에 과부하, 제동과 조향 안정성 저해 같은 여러 악영향을 끼치는데, 환경 측면에서도 덤으로 악영향을 끼치는 셈이다. 이 와중에 속도 리미터와 DPF를 다 떼어 버리고 과적· 과속을 일삼다가 적발되면 도로교통법보다는 자동차관리법을 왕창 어겨서 과태료를 많이 물게 될 것이다.

그래서 4.5톤 이상의 트럭은 고속도로에 진입할 때도 (3) 과적 여부 검사를 병행할 수 있는 화물차 전용 진입로로
들어가야 한다. 하이패스를 달았다고 해서 승용차처럼 싹 무정차 통과를 할 수 없다.

버스건 트럭이건 대형차들은 생각보다 많은 규제가 걸린 채로 운행된다는 걸 알 수 있다.
아, 그러고 보니 이런 차들을 생계 수단으로 삼고 운전하려면 통상적인 운전 면허를 딴 이후에도 각각 화물 운송 자격증, 버스 운전 자격증 같은 자격증을 추가로 따야 하기도 한다. 자가용이라면 해당 사항이 없겠지만, 거대한 트럭과 버스를 자가용으로 굴리는 경우는 사실상 없을 테니 말이다.

이걸로도 모자라서 졸음 운전 대형 사고가 몇 건 터진 뒤에는 운전사의 휴식 시간 보장을 위해 4시간 주기로 강제 휴식이니, 운행 기록 장치 장착 의무화 같은 제도가 생겼는데 제대로 시행되고 효과를 보고 있는지 모르겠다.
그리고 요 근래에는 드디어 노후 경유차의 서울 시내 주행 금지라는 더 강력한 규제가 시행되었다. 이건 뭐 굳이 대형 상용차만을 대상으로 하는 건 아니지만 저격 대상이 사실상 그런 부류들밖에 없는 지경이다.

다른 규제라면 몰라도 이 글에서 맨 먼저 언급했던 속도 규제는 개인적으로 좀 회의적인 소신이다.
운동 에너지라는 게 물체의 속도의 ‘제곱’에 비례해서 급격히 커진다는 걸 본인도 모르는 바는 아니지만.. 본인은 그냥 적기 조례마냥 규제 만능 찍어 누르기 식의 조치를 매우 싫어한다.

고속버스 졸음 운전 사고가 몇 건 났다고 해서 전국의 고속버스들 주행 속도를 90km/h로 몽땅 낮출 생각인가? 안 그래도 시내에서 개나 소나 속도 제한이 60도 아니고 50km/h로 더 낮아지고, 단속 카메라도 요즘 너무 많이 생겨서 싫은데..

이런 건 운전자의 재량을 존중하여 좀 상향 조정하고, 고속도로에서 130~140 정도는 완전히 합법화를 했으면 좋겠다. 터널이나 교량에서 차로 변경도 정식으로 허용하고 말이다.
그 대신 꼬리물기나 1차로 저속 주행이나 단속해서 칼치기를 할 일이 없게 만들면 도로가 훨씬 더 안전해질 수 있다.

Posted by 사무엘

2020/07/26 08:36 2020/07/26 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1777

지성과 문명을 갖춘 인간 사회라면 어디건 전통이란 걸 만들고 자신의 족보와 역사 기록을 남겨서 후세에 전하는 걸 중요하게 여겨 왔다. 그래서 대한민국 이전의 조선만 해도 왕조 실록이라는 게 있고, 궁중 유물 중에는 왕의 모습을 그린 초상화가 있다. 이걸 '어진'이라고 한다. '어명, 어용' 이럴 때의 御에다가 '진리, 사진' 할 때의 眞이다.

사용자 삽입 이미지

이건 조선의 태조 이 성계의 어진이다.
어진은 비록 사진은 아니지만, 여느 그림과 달리 최고존엄의 초상화인 만큼 국가 공인 최고의 화가를 최고의 보수를 주고 고용하고, 최고 품질의 종이와 물감과 도구를 동원해서 그린 것이다. 그만큼 과장 좀 보태면 "머리털 하나라도 그대로 가감 없이 사실적으로 그려 넣어라.. 안 그러면 죽는다" 급의 책임감이 부과되기도 했다.

그러니 어진은 호락호락 만만한 퀄리티가 아니며, 역사적인 가치도 그만큼 크다.
유대인 맛소라들이 우리가 상상하기 어려울 정도의 까다로운 방식과 검증 시스템 하에서 성경 말씀을 필사했듯이, 그리고 조선 사서들이 "폐하께서 '이건 좀 실록에 기록하지 말고 우리끼리 하는 말로..'라고 말씀하시였다"까지 몽땅 다 실록에다가 옮겼듯이.. 어진도 그에 준하는 근성의 산물인 것이다.

아 물론 어진은 글이 아니라 그림인 관계로 무조건 사실적으로 그려지지는 않을 수도 있다. 얼굴 주인공의 취향이 반영된 뽀샵질도 들어간다거나.. 하지만 그것도 '정도껏'만 가능하다.

실록을 기록하고 어진을 그리고 보관하는 것은 조선 이전의 고려도 했던 관행이다. 오히려 조선이 고려의 시스템을 그대로 이어받고 약간만 더 강화· 보완했을 뿐이다. 하지만 고려의 실록은 임진왜란 때 거의 다 소실돼 버렸고 이를 참조해서 조선 시대 때 따로 편찬된 역사 기록만이 전해진다.

그에 비해 조선은 기록의 끝판왕인 나라였고 이중 삼중으로 백업도 많이 한 것, 제일 최근에 멸망한 왕조인 것, 조선의 도읍 한양이 현재 우리나라의 수도 서울로 그대로 계승된 것으로 인해.. 실록을 포함해 압도적으로 많은 역사 기록이 남아서 전해진다. 고종과 순종은 심지어 흑백이나마 얼굴 사진도 남아 있다. 그러고 보니 고종의 부친인 흥선대원군도 사진이 있으니 이 사람은 사진이 찍힌 가장 오래된 조선 정치인인 걸까?

그 유물들 중에서 조선 어진도 임진왜란을 겪으면서 기존 그림이 소실되고 다시 그려진 것이 있긴 하다. 이건 초상화라기보다 상상화에 더 가까워진다.
허나, 조선 시대 어진은 일제 시대와 6· 25를 거치면서 끈질기게 살아 남았다가 대한민국 초창기 시절의 참화 한 방에 상당수가 완전/부분 소실되어 버렸다. 이런 식으로 말이다.

사용자 삽입 이미지
(왼쪽은 왕자 시절의 영조, 오른쪽은 조선 후기의 철종. 둘 다 왕복 차림은 아니다.)

이건 찢어진 게 아니라 불에 그을리고 탄 부분을 도려낸 것이다. 전부 1954년 12월, 부산 용두산 대화재의 상흔이다. 이 정도면 2008년 숭례문 방화 화재는 애교 수준이다.

6· 25 전쟁 때 서울을 빼앗기게 생기자.. 공무원들이 다른 돈다발이나 식량이나 군사 무기뿐만 아니라 이런 유물까지 챙겨서 열차에 싣고 부산으로 허겁지겁 피난 보낸 것 자체는 잘한 일이었다.
그런데 안 그래도 부산은 판자촌에서 대형 화재가 몇 번이나 나서 1953년엔 국제시장이고 부산 역이고 몽땅 태워먹을 정도였는데, 휴전 이후에도 이 사람들이 뭘 깜빡 했는지 유물들을 다시 서울로 옮길 생각을 1년 넘게 하지 않았다. 이 지역은 화재에 취약하고 언제 또 불이 날지 모르니 어서 창고를 정리해야 한다고 경고했던 소수의 사람이 있긴 했으나.. 그 경고는 묵살당했다.

그러다가 1954년 12월, 용두산 대화재 때 결국 재앙이 벌어지고 말았다.
지금으로서는 상상이 안 되지만 저 때는 촛불을 켜 놓고 자다가 화재 사고가 많이 났다. 용두산 대화재, 그리고 1977년 이리 역 폭발 사고의 원인이 바로 이것이었다.;;

불 자체가 문화재 창고에서 시작된 건 아니었으며, 불이 거기까지 번지기 전에 짐을 미리 뺄 기회가 있었다. 하지만 그때는 어이없게도 창고 열쇠를 못 찾아서 그러지 못했다. 부서별로 "문교부: 야, 너한테 열쇠가 있는 거 아니었어?" / "구황실 재산 관리 총국: 아닌데? 그거 원래 너네 관할 아냐?" 하면서 우왕좌왕했다고 당시의 경향 신문 보도 자료가 남아 있다.

장비를 동원해서 창고를 부술 여건도 못 됐고.. 결국 창고가 통째로 불길에 휩싸이는 걸 사람들이 뻔히 지켜보면서 발만 동동 굴려야 했다고 한다.
맹렬한 불길 때문에 창고의 한쪽 벽면이 붕괴된 뒤에야 짐을 빼낼 수 있었다. 그리고 그때는 이미...

사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지
(위의 빨간 옷은 순조, 아래는 문조, 정원군 원종..)

어진이 불에 탄 모양이 그로테스크하기 그지없다. 돌돌 말려 있는 상태에서 불이 붙어서 저렇게 된 것이다. 지폐가 불에 탄 모습을 비교 참고용으로 소개한다. 지폐도 단순 종이를 넘어 섬유에 가까운 튼튼한 재질로 만들어진다는 걸 생각해 보자.

사용자 삽입 이미지

그 당시에 창고에 어진 말고 무엇이 더 보관돼 있다가 소실됐는지조차도 파악이 제대로 못 되고 묻혔다. 그걸 기록해 놨던 문서가 1960년 6월, 다른 화재로 인해 소실됐기 때문이다.. -_-;;

일제 시대에 기존의 조선 황실은 일제로부터 귀족 정도 등급으로 대접 받았다는 것이 주지의 사실이다. 그러다 해방 후 한반도에는 대한민국이라고 황실이나 귀족 신분을 인정하지 않는 민주 공화정 국가가 세워졌다. 기존 조선 황실은 아주 최소한의 기본적인 예우만 받을 뿐, 신분은 일반 평민 시민으로 모조리 조정되었다.

그럴 만도 한 것이, 이들은 항일 독립 운동을 도운 것보다 일제로부터 떡고물 받으면서 그냥 편하게 산 비중이 훨씬 더 컸다. 그러니 해방 후에 대한민국 땅에서 옛 조선 황실 복원 떡밥 따위는 단 1도 거론되지 않고 싹 묻혀 버렸다. 이 사람들은 새 나라에서는 그 어떤 정치적인 목소리도 낼 수 없고 영향력을 행사할 수 없었다. 그냥 찌그러져 있어야지..

조선 시대 궁궐을 비롯해 조선 황실의 재산도 깔끔하게 국가 소유로 넘어갔다. 그리고 나라에서는 건국 극초반부터 ‘구황실 재산 관리 총국’이라는 행정 기관을 설립해서 이것들의 수효와 규모를 파악하고 체계적으로 보관· 관리하려 했다. 그랬으나...

관리 조직 내부의 부정부패 비리로 인해 구황실 재산이 부동산과 동산을 가리지 않고 개인의 자산으로 야금야금 유출되기 시작했으며, 그 정황이 윗선에도 포착되었다. 그래서 나라에서는 제1공화국이 무너진 혼란 가운데에서도 암행어사 급의 외부 인사를 파견해서 모든 황실 재산이 잘 남아 있는지, 서류상의 목록과 실물이 일치하는지 전수조사를 지시했다.

그런데 바로 그때, 창경궁 안에 소재해 있던 구황실 재산 관리 총국 본사에 원인 모를 화재가 나서 관련 증빙 서류들이 소실돼 버렸다. 6년 전에 부산에 보관돼 있던 궁중유물 목록도 이때 사라졌다. 그래서 그때 구체적으로 무엇이 보관돼 있다가 소실되었는지조차 현재로서는 영원히 알 수 없게 되었다.

이 화재는 재산 유출 관련 비리가 탄로나지 못하게 하려고 내부 관계자가 저지른 방화일 가능성이 정황상 매우 높았다. 하지만 그때는 주변에 CCTV 같은 게 없고 행정이 전산화돼 있지도 않았고.. 이렇다 할 증거를 찾을 수 없었다.
결국 이 사건은 화재의 원인이나 범인을 밝혀내지 못하고 미제 사건으로 흐지부지 묻혀 버렸다. 그리고 이듬해인 1961년에 황실 재산 관리 총국은 폐지되고, 문화재 관리국이라는 상위 호환 조직으로 흡수되었다.

그럼 다시 어진 얘기로 돌아온다.
어진은 우측 상단에 그림의 주인공 내지 그림이 그려진 날짜 같은 식별 정보가 기록되었다. 그렇기 때문에 오른쪽이 소실된 어진은 얼굴이 남아 있더라도 누구의 얼굴인지 몰라서 애를 먹으며, 고고학자들이 각종 추리를 동원해서 어진의 정체를 추적한다. 파일로 치면 뒷부분의 데이터가 아니라 앞부분의 헤더를 날린 것과 비슷하다.;;

사용자 삽입 이미지

손상된 원래 순종 어진(좌) vs 2014년경에 복원된 버전(우). 얘 정도면 우측의 헤더가 날아갔어도 주인을 식별하는 데 별 어려움이 없었다.
저 때는 조선이 대한제국으로 페이스리프트(?)된 뒤이기 때문에 군주가 왕을 넘어 황제 취급을 받았다. 그래서 고종과 순종은 어진에 그려진 옷의 색깔부터가 노랗다.

비록 불의의 사고 때문에 수십, 수백 년째 전해지던 어진이 불에 타 버렸지만.. 요즘은 추가적인 사료 내지, 옛날에 어진을 흑백 사진으로라도 찍어 놨던 것 등 조금이라도 단서가 될 만한 건 몽땅 싹싹 긁어모아서 어진을 용케 복원하기도 한다.

하긴, (1) 어린 시절에 비무장 지대 안에 시뻘겋게 녹슨 채 버려진 증기 기관차라고만 사진으로 봤던 그 열차는 그럭저럭 녹 벗기는 복원 작업을 거쳐 임진각에 전시돼 있다. 지금은 복원을 했기 때문에 약간 짙은 갈색이지, 그 전엔 진짜 시뻘갰다.

(2) 어린 시절에 먼지를 뽀얗게 뒤집어쓴 채 방치된 낡은 모습으로 봤던 순종 어차는.. 2000년대에 정교하게 복원 재도색 리마스터링을 해서 아주 반들반들 광택 나는 새 차처럼 박물관에 전시돼 있다.

그리고 (3) 1950년대에 만들어졌던 시발 자동차조차 실물은 다 소실되어 버려서 지금 박물관에 전시돼 있는 건 레플리카뿐인데, 순종 어차는 오리지널 진품인지라 세계적으로도 보기 드문 사례이다. 그러고 보니 이건 전부 교통수단들이구나..

뭐든지 기록이 보존되고 복원되는 것은 흥미로운 일이다. 가령, 수원 화성은 뻔히 후대에 재건된 물건임에도 불구하고 그 기록이 너무 상세하게 고퀄로 잘 돼 있던 덕분에 유네스코 문화유산으로 등재됐을 정도이다.

과학 기술이 발달하고 등 따시고 배부르고 먹고 살 만하니까 그 다음으로 이런 문화재 복원 같은 정신적인 만족 분야에도 관심이 생기는 것이다. 그리고 앞서 얘기했던 바와 같이, 실록이나 어진 같은 걸 만드는 방식, 기록과 보존 같은 개념은 성경 말씀의 기록과 보존과 관련해서도 시사하는 바가 크다.

Posted by 사무엘

2020/07/23 08:34 2020/07/23 08:34
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1776

1. 텔레비전의 변천사, 라디오와의 차이

요즘 전화기가 유선, 무선, 위성, 인터넷이라는 네 방식이 있는 것처럼 텔레비전 방송에도 개념적으로 유선, 무선, 위성, 인터넷 방식이 모두 존재한다.
단, 전화는 처음에 유선(전화선)으로 시작했다가 나중에 무선 휴대전화(기지국..)가 개발된 반면, 텔레비전은 처음에 무선(지상파)부터 시작했다가 난시청 지역의 방송 접근성 개선을 위해 유선(케이블) 방송이 나중에 개발되었다는 차이가 있다.

사용자 삽입 이미지

(지상파 수신을 위한 텔레비전 안테나. 뭔가 기하학적인 직선 모양이다. 텔레비전 본체에 달린 더듬이 모양의 작대기 두 개만이 전부가 아니고, 이런 실외 안테나도 필요했던가 보다.)

텔레비전의 무선 신호는 처음에는 NTSC 내지 PAL이라는 아날로그 방식이었다. 동시대의 비디오 테이프에 VHS와 베타멕스라는 두 방식이 있었던 것처럼 텔레비전용 아날로그 신호도 하나만 있는 게 아니었다. 우리나라는 미국을 따라 NTSC 방식을 사용했었다.

처음에는 흑백만 지원하다가 1980년대부터 국내에도 컬러 방송이 시작됐는데, NTSC는 신호 구조에 하위 호환이 잘 지켜졌던 모양이다. 흑백 수상기는 여전히 흑백 영상이 나오면서 컬러 수상기에서는 컬러를 자연스럽게 볼 수 있었다.

그러다가 21세기에 와서는 신호가 통째로 디지털 방식으로 바뀌었다. 화질이 놀라울 정도로 크게 향상됨과 동시에, 화면의 종횡비도 바뀌어서 가로로 더 납작해졌다(4:3에서 16:9로).
이렇게 신호의 내부 구조가 달라진 한편으로 TV의 디스플레이 소자도 너무 크고 무겁던 브라운관이 퇴출되고, LCD 같은 얇은 물건이 등장했다. 2000년대 말~2010년대 초에 싹 물갈이가 된 것 같다.

우리나라에서 아날로그 방송 송출이 중단된 것은 2012년 말부터이다. 내 기억이 맞다면 지상파 방송이 평일에도 상시 24시간 방송을 하기 시작한 것도 2012년 하반기쯤으로 비슷하다.
물론 평일 낮 시간대는 대부분의 사람들이 생업에 바쁘니, TV를 보는 일이 잘 없다. 그래서 24시간 방송을 하더라도 저 때는 새 컨텐츠보다는 그냥 기존 방송의 재방송 위주로 편성되는 편이다.

그래도 24시간 방송 덕분에 텔레비전에서 화면조정 컬러바를 볼 일이 옛날에 비해 훨씬 더 없어진 것은 신통한 노릇이다. 서울 지하철 2호선은 순환선인 관계로 타 노선에 비해 종점에서 멈추는 열차를 찾기가 어려운 것처럼 말이다.

참고로, 이런 텔레비전에 비해 라디오는.. 디지털이건 아날로그건 음질이 크게 달라질 게 없으며, 전쟁· 천재지변 같은 상황에서도 아주 가볍고 저렴하고 단순한 장비만으로 수신이 가능한 게 좋다는 특성상 오늘날까지도 재래식 아날로그 방식이 여전히 유지되고 있는 듯하다.

그리고 라디오는 TV와 달리 딴 일을 하면서도 청취가 가능하다는 매우 중요한 특징이 있다. 특히 하루 종일 귀가 심심한 수많은 영업용 자동차(버스, 트럭, 택시) 운전사들의 고정 수요도 있기 때문에 망할 일이 절대 없다.
그러니 새벽 심야는 몰라도 평일 낮 시간에 라디오 방송이 끊겼던 적은 전무했다. 그리고 라디오 방송은 TV 방송보다 생방송의 비중이 더 크기도 한 것 같다. 이 바닥은 텔레비전과는 분위기 내지 물이 근본적으로 많이 다른 셈이다.

2. 위성 방송

무선 신호 얘기를 하다가 라디오 얘기도 나오면서 얘기가 옆길로 많이 샜는데.. 다시 본론으로 돌아오겠다.
유선, 무선 다음으로 위성은 기존 무선의 스케일을 확 키운 버전이라고 볼 수 있다. 통상적인 텔레비전 송신탑이나 휴대전화 기지국은 제아무리 높아 봤자 지상에 존재하며, 감당 가능 영역이 국내의 일정 지역까지로 한정된다. 그러나 정지 궤도 위성은 그야말로 지구 반대편으로 전파를 보낼 수 있다.

그래서 텔레비전의 위성 방송은 위성으로 쏘는 외국의 방송을 시청 가능하게 했으며, 위성 전화는 선박이나 남극 기지처럼 지상의 통신 인프라와 고립된 오지 외지에서 통신을 가능하게 해 주었다. 물론 위성 서비스는 통상적인 지상 기반 무선 서비스보다 단가가 훨씬 더 비싼 것을 감수해야 한다.

우리나라는 1995년에 무궁화 인공위성이 발사된 뒤부터 자체적인 위성 방송이 시작되었다. 하지만 그 전에도 외국의 통신 위성으로부터 서비스를 받는 외국 위성 방송 자체는 있었다.
내 기억으로 1990년대 중반, 그 시절에 국내에 수신된 대표적인 외국 위성 방송은 홍콩 StarTV였다. 뭔지는 모르겠지만 금빛 별 모양이 그려진 방송국 엠블럼이 나오고.. 정체 모를 팝송의 뮤직비디오와 운동 경기 중계가 많이 나오는 예능 채널 같았다.

본인은 스타TV 장면을 그 시절에 다니던 학원의 텔레비전에서 보고, 그리고 노래방 기계 화면의 배경 동영상으로도 많이 봤다! 그래, 그땐 그랬다. 이 TV에서는 어째 우리집에서는 볼 수 없는 외국 텔레비전 방송이 나오는지 의문을 가질 법도 했는데 그때는 그저 그러려니 하고 넘어갔던 것 같다.
그리고 비슷한 시기에 어디 친구 집에서 웬 일본 NHK 방송이 나오는 것도 본 적이 있다. 무슨 브랜드명이기라도 한지 화면에서 BS라는 이니셜이 자꾸 눈에 띄었던 것 같은데.. 알고 보니 그 이니셜 자체가 위성(S) 방송(B)이라는 뜻이었다.

사용자 삽입 이미지

(위성 방송 수신용 안테나. 접시 모양이다.)

위성 방송은 워낙 능력이 출중하니 통상적인 지상파 방송의 시청이 안 되는 문제를 해소하는 용도로 쓰이지만, 앞서 얘기한 것처럼 외국 방송 내지 위성 방송 사업자가 제공하는 고유한 컨텐츠를 시청하는 용도로도 쓰인다. 위성 방송 사업자가 2000년대에 개척한 영역은 바로 교통수단 내부에서의 이동 방송이다.

그래서 그 무렵에 고속버스에서는 ‘스카이라이프’ 위성 방송이 개시되었으며.. 새마을호 열차에서는 ‘코모넷’이라는 업체로부터 납품받은 위성 방송이 나오기 시작했다.
사실, 교통수단에다가도 전기 공급해 주고 안테나만 잘 꽂으면 그냥 지상파 TV를 수신하지 못하란 법이 없다. 그 시절에 버스가 아닌 승용차용 자그마한 흑백 TV도 있었다. 하지만 이렇게 교통수단용 별도의 이동 방송이 존재했던 건 신호 수신 때문이 아니라 고유한 방송 컨텐츠 때문이었다.

위성 방송은 다 좋지만 날씨의 영향을 받는 편이며, 특히 차량이 하늘이 보이지 않는 곳(터널..)에 진입하면 신호가 끊어지고 방송이 중단되는 단점이 있었다. 고속버스 말고 새마을호의 영상 서비스는 위성 방송이지만 그렇지 않았던 것 같은데 지금은 기억이 잘 안 난다.

2000년대 초중반까지 새마을호 열차에 위성 방송 기반의 영상 서비스를 제공했던 업체가 바로 그 이름도 유명한 ‘코모넷’이다. 새마을호의 시종착 때 Looking for you라는 마의 음악을 선곡해서 집어넣은 장본인도 코모넷인데.. 그 배후에 누가 있었는지 본인으로서는 너무나 궁금할 따름이다. 그 코모넷은 2000년대 후반에 소리소문 없이 망하고 폐업해 버렸으며, 이후에 창업주의 근황이 보도된 것도 전무하다. 그에 따라 새마을호의 영상 서비스는 2006년경에 연합뉴스로 바뀌었다가.. 얼마 못 가 완전히 폐지됐다.

3. 인터넷 TV (IPTV)

여기서 인터넷이란 유선 무선 같은 물리적인 기술 계층이 아니라, 그런 기술을 활용하고 해석하는 프로토콜 계층에서의 차이를 가리킨다. 인터넷의 물리적인 통신 방식이야 동축 케이블이나 유리 섬유 케이블 같은 유선으로 구현될 수도 있고, 수 GHz대의 와이파이 무선 통신으로 구현될 수도 있다.
단지, 영상과 음성 정보를 IP라는 인터넷 프로토콜에 근거한 패킷 형태로 주고받으며, 인터넷 자체가 양방향 소통 체계이다 보니 재방송, VOD 서비스 같은 인터랙티브한 서비스 제공도 덤으로 가능하다는 차이가 있다.

즉, 인터넷 TV에서 인터넷이란 컴퓨터 웹브라우저를 통해 사용자에게 친숙한 WWW(월드 와이드 웹)는 아니고, 그보다 저수준에서 인터넷의 범주에 드는 기술인 것이다. 개인이 마음대로 진행하는 유튜브나 아프리카 기반의 인터넷 방송하고도 당연히 다른 얘기이다.
인터넷 TV를 시청하려면 해당 서비스에 가입하고 거기서 받은 셋톱박스와 전용 안테나를 설치해야 한다. 아니, 지상파 외에 위성이나 유선 같은 다른 기술 계층의 TV를 시청하려면 저런 추가적인 장비가 필요하다.

인터넷 TV로는 지상파뿐만 아니라 기존 케이블 TV까지도 시청 가능하기 때문에 전통적인 케이블 TV와 사업 영역이 겹친다. 그래서 두 업종 간에 티격태격 하는 경우가 있다. 그래도 서로 완전히 동치는 아니기 때문에 IPTV 전용 채널이라든가 케이블 방송 전용 채널도 있다.

4. 유선(케이블) 방송

텔레비전은 원래 전파를 수신해서 동영상을 보여주는 물건인데 유선이라니..?? 그렇다고 CCTV도 아니고? 일면 의아한 생각이 드는데.. 헷갈릴 필요가 없다.
그 '케이블'이라는 건 방송국에서 유선 방송 사업자 사이가 연결돼 있다는 뜻이다. 방송사와 소비자 사이에 계층이 하나 더 생긴 셈이다. 거리가 충분히 가까워졌으니 소비자는 이 정도 양질의 신호는 셋톱박스 하나만 장착함으로써 수신할 수 있다. 물론 이 전파는 암호화도 돼 있어서 지상파 방송처럼 간단하게 시청할 수는 없다.

무선이 아니라 유선인 덕분에 이 방송은 기존 지상파 방송의 난시청 문제를 해결함과 동시에 지상파보다 훨씬 더 많은 채널도 제공할 수 있다. KBS, MBC, EBS, SBS가 뭔가 1군 지상파라면.. 그 다음으로 YTN, 아리랑 TV라든가 국회방송, 법률방송, 기독교 방송, 온게임넷 같은 건 유선· IPTV· 위성 형태로만 시청 가능한 2군 정도 되겠다. 물론 위성 방송처럼 외국 방송을 쏴 주는 건 아니고, 국내 한정이다.

이런 2군 방송들은 특정 장르와 분야의 방송으로만 한정되곤 했는데 얘들도 지상파 방송처럼 일반적이고 범용적인 분야로 방송 영역을 확장시킨 것이 그 이름도 유명한 종편, 종합 편성 채널이다. 채널A, JTBC, TV조선 같은 것 말이다.

유선, 무선, 위성, 인터넷 이런 것들이 자동차로 치면 수소 연료전지, 순수 전기, 하이브리드, CNG 개조, LPG 개조 같은 온갖 연료 바리에이션을 보는 느낌이다. 또는 택시, 렌트, 카셰어링, 타다 등의 서비스 바리에이션 같기도 하고..
지금까지 얘기가 나왔던 것을 한데 정리하면 이렇게 요약된다.

  • 태초에 제일 단순한 KBS MBC 같은 지상파 방송이란 게 있었으며, TV는 지상파 방송을 시청하라고 만들어진 물건이었다.
  • 그런데 지상파의 난시청 문제를 해결하기 위해 유선 방송이란 게 개발되었고 유선 방송 전용 채널도 많이 생겨났다. 즉, 얘는 지상파의 상위 호환이다.
  • 위성 방송은 유선 방송의 상위 호환이다. 덤으로 외국 위성 방송의 수신이 가능하고 교통수단 내부에서 쓰인 바 있다. 지상파의 지리적 한계를 극복하긴 했지만 얘만의 고유한 약점(날씨와 지형 제약)도 있다.
  • 인터넷 TV도 유선 방송의 상위 호환이며 오늘날의 대세이다. 뭔가 파일 기반인 게 DB 기반으로 바뀐 듯한 느낌인데(전문적인 계층 추가).. 인터넷 전화와 마찬가지로 인터넷 서비스가 불통되면 얘 역시 몽땅 먹통이 돼 버린다. (와이파이 전파 상태 내지 해저 케이블..)

그리고..

(1) 지상파 방송이 접근성이 제일 좋긴 하지만.. 지상파 방송이 곧 전국구 방송을 의미하지는 않는다. 가령, SBS는 엄연한 지상파 방송이지만 20세기까지는 서울· 수도권에서만 시청 가능했다. 지금도 경기방송, OBS경인TV 같은 건 지상파이지만 지방 방송이다.

(2) YTN의 경우 뉴스 보도 전문이니 종편은 아니다. 그런데 연합뉴스 TV는 YTN과 어떤 관계인지 난 잘 모르겠다.

(3) DMB는 스마트폰 같은 모바일 기기에서 TV를 시청하기 위한 기술 규격인데, 기존 TV 신호 기술과 비교했을 때 무슨 문제를 해결하기 위해 개발된 것인지 개인적으로 잘 모르겠다. 뭔가 더 좋은 구석이 있겠지..

(4) 엄청 옛날에는 전화기가 동그란 다이얼이 달려 있었듯이, 텔레비전도 옛날에는 채널을 변경하는 인터페이스가 - + 버튼이 아니라 다이얼 두 개였다. 한 다이얼은 2부터 13 정도까지 VHF라 하여 좁은 영역을 건드리고, 다른 다이얼은 UHF라고 두 자리수의 훨씬 더 넓은 영역을 촘촘하게 다뤘다.
대부분의 채널은 그냥 비어 있어서 지정해 봤자 치지직 잡음밖에 안 들렸는데.. 여기에다가 유선 방송 셋톱박스를 설치해야 그 채널들이 방송으로 채워졌던 것 같다.

사용자 삽입 이미지

(5) 옛날에는 매일 아침 지상파 방송에 CNN, NHK 등의 세계 외신의 주요 보도를 짤막하게 보여주는 '세계 뉴스'라는 코너가 있었는데.. 요즘이야 그것 말고도 외신 보도를 접하는 방법이 차고 널렸기 때문에 남사스럽게 그런 걸 하지 않는다. 정보를 접하는 게 이렇게 쉽고 간편해진 건 정말 전율에 가까운 모습이다.

(6) 덕분에 “텔레비전에 내가 나왔으면 정말 좋겠네”라는 동요도 의미가 참 무색해져 있다. 이제는 참신한 컨텐츠와 끼만 있으면 누구라도 개인 방송을 개설해서 언제든지 전세계에 자기 얼굴을 얼마든지 알릴 수 있기 때문이다.
다만, '메이저 지상파 방송'에 어떤 형태로든 출연하는 건 예나 지금이나 쉬운 일이 아니며 아무나 할 수 있지 않다. 본인조차도 지상파 방송 출연 경력은 현재까지도 지난 2005년 초의 스펀지 타자 실험맨이 처음이자 마지막이다.

(7) 컴퓨터에 TV 수신 카드라는 것도 있었는데.. 이 역시 격세지감이다. 국내에서는 두인 전자라는 기업에서 만들곤 했다.

Posted by 사무엘

2020/07/20 08:35 2020/07/20 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1775

1. 가상 함수 테이블을 강제로 없애기

C++에서는 가상 함수가 하나 이상 존재하는 클래스는 그렇지 않은 클래스와 좀 다른 취급을 받게 된다. 자기가 새로 선언한 것뿐만 아니라 기반 클래스로부터 상속받은 가상 함수까지 포함해서 말이다.
가상 함수가 존재하는 모든 클래스들은 각각 가상 함수 포인터 테이블(v-table)이라는 일종의 global 배열을 할당받으며, 이를 가리키는 포인터를 멤버로 갖게 되고 생성자에서 그 포인터의 값이 초기화된다.

클래스에 온갖 파생 클래스와 가상 함수들이 추가되고 상속 단계가 복잡해질수록, 이 테이블들의 개수와 크기도 무시 못 할 비중을 차지하게 된다.
A라는 클래스에 가상 함수가 5개 있으면 A의 v-table은 크기가 5이다. 그런데 A로부터 상속받은 클래스 B가 또 가상 함수를 3개 추가한다면 B의 v-table의 크기는 5+3 = 8이 된다. 그런 식이다. 다중· 가상 상속 같은 것까지 자연스럽게 지원하려면 B의 v-table에도 A의 것이 고스란히 몽땅 중복 등재돼 있어야 한다.

그런데 문제는 순수 가상 함수가 들어가 있어서 단독으로 인스턴스가 생성될 일이 전혀 없는 클래스에 대해서도 일단은 동작의 일관성을 보장하기 위해 v-table이 잉여스럽게 따로 생성된다는 것이다.
왜냐하면 B라는 클래스의 생성자는 그 정의상 기반 클래스 A의 생성자를 반드시 호출하게 돼 있고, A의 생성자가 하는 일 중 하나는 A에 대한 고유한 v-table을 참조하는 것이기 때문이다.

어차피 값이 거의 전부 다 NULL이고 실제로 쓰일 일도 없는 v-table이 쓸데없이 생성되는 일을 막기 위해, Visual C++에는 __declspec(novtable)이라는 비표준 확장 속성이 도입되었다. 특히 COM이라는 규격을 C++ 언어와 바이너리 차원에서 연계하려다 보니 이 기능이 없어서는 도저히 안 되는 지경이 되었다.

굳이 순수 가상 함수가 없더라도, 어쨌든 반드시 파생 클래스 형태로만 쓰이지 그 자체가 인스턴스 형태로 선언될 일이 없는 클래스라면 __declspec(novtable)를 지정해 주는 게 메모리 절약 측면에서 좋다. 날개셋 한글 입력기의 경우 이걸 적용해 주니 ngs3.dll의 크기가 수 KB 남짓 줄어드는 효과가 있었다.

특히 데이터 멤버 없고 순수 가상 함수밖에 없는 인터페이스라면 이거 지정이 무조건 필수이다. 이래서 후대의 객체지향 언어들은 구조체(생성자 소멸자 가상 함수 없는 POD) vs 클래스뿐만 아니라, 일반 클래스 vs interface(추상 클래스)도 언어 차원에서 구분한다는 게 느껴졌다. 이게 단순히 외형이나 기분상의 구분만을 의미하지 않는다.

파생 클래스 쪽의 초기화가 덜 된 오브젝트에 대해서 순수 가상 함수를 호출해 버리면 보통은 pure virtual function call이라는 C++ 예외가 발생한다. 그런데 __declspec(novtable)가 지정된 오브젝트에 대해서 가상 함수를 호출해 버리면 저런 high-level 예외가 아니라 그냥 NULL 포인터 접근에 준하는 평범한 access violation 에러가 나면서 프로그램이 죽게 된다.

2. 가상 함수 테이블의 메모리 오버헤드

가상 함수 테이블 얘기를 계속하겠다.
B가 가상 함수가 100개 있는 A라는 클래스를 상속받아서 자신만의 가상 함수를 새로 만드는 것 없이, A의 함수 중 딱 한두 개만 override를 했더라도.. 컴파일러는 내용이 한두 개밖에 차이가 나지 않고 거의 동일한 원소 100개짜리 함수 포인터 배열을 또 하나 만들게 된다. B의 모든 인스턴스들이 한데 공유하는 가상 함수 포인터 테이블 말이다. 일종의 copy-on-modify와 비슷한 메커니즘이다.

그렇게 해야만 A건 B건 오브젝트 종류를 불문하고 가상 함수의 주소를 배열 오프셋만으로 O(1) 시간 만에 곧장 얻어 와서 호출을 할 수 있기 때문이다.
가상 함수 호출은 그렇잖아도 오버헤드가 일반 함수 호출보다 훨씬 더 큰데, 메모리를 아낀답시고 주소를 얻는 것조차 클래스 계층이나 함수 테이블을 뒤지는 방식이어서는 곤란하다.

하지만 이런 내부 디테일과 오버헤드를 생각하면 클래스를 아무 부담 없이 막 상속받기가 좀 부담스러워진다. 뭐, 요즘처럼 컴퓨터에 메모리가 풍족한 시대에 무슨 198, 90년대 같은 메모리 구두쇠 쫌생이처럼 코딩을 할 필요는 없지만, 그래도 같은 값이면 컴퓨터의 자원을 아껴 쓰는 게 프로그래머의 미덕 아니겠는가?

그렇다고 언어의 스펙을 바꿔 버릴 수는 없으니, Windows용 C++ 라이브러리인 MFC는 저런 가상 함수 테이블 오버헤드를 줄이기 위해, CWnd 클래스의 Windows 메시지 handler 함수는 가상 함수 대신 pointer-to-member 기반의 message map으로 구현한 것으로 잘 알려져 있다.

얘는 사용자가 실제로 overriding을 한 함수의 개수만큼만 테이블의 크기가 커지니 공간 사용은 효율적이다. 그러나 메시지에 대응하는 함수를 찾는 일은 매번 테이블을 선형 검색을 해야 하기 때문에 시간 복잡도가 O(n)으로 커진다.
이 부분은 정말 밥 먹듯이 자주 호출되는 부분이고 목숨 걸고 성능을 최적화해야 하는지라, MFC 소스에서도 극히 이례적으로 인라인 어셈블리가 사용되어 있다~! (wincore.cpp의 AfxFindMessageEntry 함수)

객체지향을 구현하기 위해서 이런 시간-공간 tradeoff를 따져 봐야 하니, C++보다 더 유연한 디자인을 추구한 Objective C 같은 언어는 메시지를 아예 문자열로 식별하게 했다(selector). 이름으로부터 실제 주소 매핑은 물론 hash 기반이고..

C++은 배열 오프셋 기반이어서 당장 성능 자체는 제일 좋으나, 클래스에서 뭐가 바뀌었다 싶으면 몽땅 재컴파일 해야 한다. 그리고 그런 경직된 체계에서 다중/가상 상속과 멤버 함수 포인터까지 구현하려다 보니 디자인에 무리수가 많이 들어갔고, 그 뒷감당은 결국 컴파일러 제조사들이 비표준 확장을 도입해서 땜빵하는 촌극이 벌어졌다.

그에 비해 Objective C는 신호등 교차로 대신 회전 교차로, 수동 변속기 대신 아예 자동 변속기 같은 접근을 한 셈인데.. C++ 같은 C의 이념 적당히 절충이 아니라 객체지향 언어라는 이론만 생각해 보면 저런 접근 방식도 충분히 가능은 하겠다는 생각이 든다.

3. 캐사기 auto

람다 함수가 최초로 도입된 C++0x 시절에 곧장 가능했던 것 같지는 않다만..
요즘 람다는 인자와 리턴값의 타입으로 auto를 지정할 수 있다.. >_<
auto에서 또 auto가 가능하다니? 그것도 C++ 같은 언어에서.. 이건 좀 꽤 사악한 기능인 것 같다.

auto Func = [](auto x) -> auto { return x * 2; };
printf("%f\n", Func(1.4));
printf("%d\n", Func(25));

람다가 일반 C++ 함수 같은 오버로딩이나 템플릿을 지원하지는 않으나, 저기서는 auto가 템플릿 인자 역할을 하는 거나 마찬가지이다.
생긴 건 함수와 비슷하지만 캡처가 지원되고 호출 규약 제약 없고 저런 것까지 가능하니.. 기존의 함수와는 형태가 얼마나 다른지 알 수 있다.

그나저나 람다 함수는 함수 자기 자신을 지칭해서 재귀 호출을 하는 방법은 여전히 없는지? this처럼 자기 함수 자신을 가리키는 예약어가 필요하지 않을까 싶다. __self??
그리고 사실은 C++도 기반 클래스를 지칭하는 __super 같은 키워드도 있어야 할 듯하다.

4. export의 재탄생

C++에서 완전 존재감 없는 잉여로 전락했던 auto가 10여 년 전 2010년대부터는 잘 알다시피 언어의 패러다임의 변화를 주도하는 거물로 환골탈태했다.
그것처럼.. 지난 2000년대에 비현실적인 흑역사 키워드로 전락하고 봉인됐던 키워드 export가.. 2020년대부터는 모듈 선언이라는 완전히 다른 용도로 다시 쓰이게 될 것으로 보인다. 하긴 import, export는 그 대상이 무엇이 됐건 프로그래밍에서는 굉장히 즐겨 쓰일 만한 의미의 동사이긴 하다.

지난 수십 년을 C처럼 원시적인 텍스트 include와 라이브러리 링킹에 의존했던 C++에 파스칼이나 D처럼 신속하게 빌드 가능한 모듈, 유닛이 도입되려는가 궁금하다.
그럼 이제 C/C++에서 제일 존재감 없는 잉여 키워드로는 signed만 남는 건지?

C++이 이 정도까지 변하고 있는데 #pragma once는 좀 언어 차원에서 정식으로 표준으로 수용할 생각이 없는지 궁금하다.
이제 플랫폼을 불문하고 지원하지 않는 컴파일러가 거의 없는 사실상의 표준이며, 실용적으로도 꼭 필요한 기능인데 말이다.

5. 템플릿의 prtial specialization

C++ 템플릿에는 template<typename X> class A처럼 말 그대로 템플릿을 선언하는 게 있는가 하면, template<> class A<XXX> 처럼 특정 타입에 대해 specialization을 하는 문법이 있다. 둘의 형태를 주목하기 바란다.
그런데 C++03즈음에서는 partial specialization이라고 해서 단일 타입이 아니라 일정 조건을 만족하는 템플릿 인자에 대해서는 몽땅 이 specialization을 사용하도록 하는 기능이 추가되었다. 가령 X가 포인터 타입이라든가, 템플릿 인자 A,B를 받는데 B가 A 내부의 pointer-to-member 타입이라거나 할 때 말이다.

이런 specialization에서는 template<typename X> class A<X*> 내지 A<X, X::*> 같은 식으로 template과 A에 템플릿 인자가 모두 들어온다.
개인적으로 이런 기능을 사용해 본 적은 없다. 특정 상황에서 편리한 기능이 될 수는 있겠지만.. 컴파일러를 만드는 건 더욱 어려워질 것 같다..;; 저 시절에 이런 기능과 함께 export까지 제안됐었다니 참 가관이다.

6. C++ 코딩 중에 주의해야 할 점

예전 글에서 언급했던 것들이지만 다시 한데 정리해 보았다.
참고로, 클래스의 상속 관계에서 부모/자식(parent/child), 기반/파생(base/derived)은 서로 기능적으로 아무 차이 없이 기분 따라 섞여서 쓰인다.
인자와 매개변수도(argument/parameter) 그냥 섞여 쓰이는 것 같다.

(1) C++에서는 오버로딩과 오버라이딩이 동시에 같이 자동 지원되지는 않는다.
가령, 한 클래스에서 foo라는 같은 이름으로 void foo()와 void foo(int x)를 모두 정의하는 건 당연히 가능하다(오버로딩).
하지만 둘 중 하나를(가령, 후자) 가상 함수로 지정해서 파생 클래스에서 그놈을 오버라이딩 했다면.. 파생 클래스에서는 오버라이딩 되지 않은 다른 '오버로드' 버전은 자동 지정이 되지 않는다. 이건 혼동을 피하기 위해 C++ 언어의 스펙 차원에서 일부러 그렇게 설계된 것이다.

파생 클래스에서 전자를 사용하려면 기반 클래스의 이름을 거명해서 기반::foo() 이런 식으로 언급하거나..
아니면 파생 클래스의 선언부에서 using 기반::foo; 라고 명시적으로 선언을 해 주면 된다. 그러면 foo만으로 기반 클래스의 두 함수를 곧장 접근할 수 있게 된다. using에 이런 활용 가능성도 있었다니~!

(2) 클래스 객체의 생성 단계에서 멤버들이 초기화되는 순서는 헤더에서 선언된 순서이지, 생성자 함수의 이니셜라이저 목록에 등장하는 순서가 아니다. 그렇기 때문에..

class Bar {
    int x,y;
public:
    Bar(int n): y(n), x(y+1) {}
};

위의 코드에서 x는 제대로 초기화되지 않는다. x(y+1)이 y(n)보다 먼저 실행되기 때문이다.
이건 방대하고 복잡한 클래스를 구현할 때 정말 쉽게 간과하고 실수할 수 있는 특성인데 컴파일러가 경고라도 해 줘야 되지 않나 싶다. 함수 안의 지역변수에서 "초기화되지 않은 변수 거시기를 사용했습니다" 경고를 띄우는 것과 비슷한 로직으로 별로 어렵지 않게 구현할 수 있을 텐데..??

(3) 생성자와 소멸자 함수에서는 자기 객체에 대한 가상 함수를 호출하지 말아야 한다. 비록 기반 클래스의 생성자 및 소멸자가 파생 클래스의 생성자 및 소멸자의 실행 과정에서 같이 호출되겠지만.. 기반 클래스는 자기 객체가 진짜로 기반인지 아니면 상속된 파생 클래스로부터 호출된 것인지를 전혀 알 수 없으며, 알려고 하지도 말아야 한다. 그냥 기반 클래스 자신의 일만 하면 된다.

이는 프로그래머에게 불편을 끼치는 규제가 아니라 언어의 컨셉이 그러하기 때문이다. 생성자와 소멸자는 Windows 메시지로 치면 그냥 WM_CREATE/DESTROY가 아니라 NC 버전이다. (WM_NCDESTROY는 자식 창들이 몽땅 다 사라지고 없는 상태에서 호출) 그리고 복잡한 처리를 절대로 해서는 안 되는 DllMain 함수와도 같다.

기반 생성자는 이 객체가 파생 클래스로서의 초기화가 되기 전에 먼저 호출되고, 기반 소멸자는 파생 클래스 부분이 소멸된 뒤에 맨 나중에 호출된다. 그러니 파생 클래스가 어떠한지를 따지는 것은 전혀 무의미한 것이다.
이건 위의 2번과 마찬가지로 초기화의 순서와 관련해서 저지르기 쉬운 실수이다. 2번은 멤버들의 초기화 순서이고(수평??) 3번은 상속 계층에서의 초기화 순서이다(수직??).

소멸자 자체는 반드시 가상 함수 형태로 선언해야 하지만 소멸자 내부에서 또 다형성을 기대하지는 말아야 한다는 것이 아이러니이다.

(4) 멤버 함수 포인터로 가상 함수의 오버라이딩을 제어할 수는 없다.
한 함수 포인터로 기반 클래스의 함수 내지 파생 클래스의 오버라이딩 함수 중 원하는 것의 주소를 저장하고, ptr의 값(정확히는 ptr이 가리키는 vtbl의 값)과 무관하게 ptr에 대해 원하는 함수를 강제 호출하는 것은 가능하지 않다.

그런 시도를 했을 때 함수 포인터에 저장되는 것은, 그저 ptr->vtbl에 매핑된 버전의 함수를 따로 호출하는 역할을 수행하는 thunk뿐이다.
그러니 멤버 함수 포인터를 동원한다 하더라도 vtbl을 거친 가상 함수 본연의 동작을 변형할 수는 없다.

Posted by 사무엘

2020/07/17 08:35 2020/07/17 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1774

1. 독특한 윈도우 클래스

Windows의 GUI에는 버튼, 리스트박스, 에디트 컨트롤 등의 잘 알려진 제1군 컨트롤 윈도우들이 있고, 공용 컨트롤이라는 제2군 윈도우도 있다. 이런 것들은 누구나 널리 사용하라고 클래스 이름도 널리 알려져 있다.
그런데 Spy++로 들여다보면, 정식으로 공개되지 않았지만 이런 클래스들이 공용으로 쓰이는 것 같다. 정체가 무엇인지 궁금하다.

  • NetUIHWND: MS Office 프로그램들, 그리고 심지어 워드패드와 그림판에서도 리본이 이 클래스 이름으로 만들어져 있다. 마소에서만 내부적으로 사용한다. (Visual C++의 MFC 확장판에서 제공되는 리본은 마소 오리지널이 아님)
  • DirectUIHWND: task dialog 내부, IE 브라우저의 탭, 탐색기 제어판에서 뭔가 웹페이지처럼 꾸며진 대화상자들에서 종종 쓰인다. 클래스 스타일에 CS_GLOBALCLASS도 버젓이 지정돼 있다. 마소 내부에서 사용하는 GUI 엔진 윈도우 같은데..
  • HwndWrapper[모듈이름;;GUID]: 닷넷이나 WPF처럼 통상적인 Windows API나 기성 컨트롤이 아닌 다른 프레임워크를 이용해서 GUI를 꾸미는 프로그램 같다. 내가 아는 프로그램 중에는 Visual Studio 2010과 그 이후 버전, 그리고 아래아한글(+ 타 오피스 제품 포함) 요 두 프로그램만이 이런 스타일이다.

2. 파일 및 디렉터리의 삭제, 디스크 제거

Windows는 프로그램을 memory-mapped file 형태로 불러온다는 특성으로 인해.. 실행 중인 프로그램을 삭제할 수 없다. 그래서 실행 중인 프로그램을 제거하거나 업데이트 하는 것도 좀 어려운 편이다.
실행 중인 프로그램 파일을 '개명'하는 건 가능하다. 여기서 개명이란 같은 드라이브 안에서의 디렉터리 이동도 포함한다.

이런 Windows와 달리 macOS나 리눅스는 실행 중인 프로그램 파일을 삭제할 수 있다.
허나, 실행 중인 프로그램의 current directory를 당장 삭제할 수 있는 운영체제는 내가 아는 한도 내에서는 없다. 삭제 예약만 해 놓은 뒤, 프로그램이 종료되거나 디렉터리가 딴 데로 바뀌었을 때 삭제되는 게 그나마 제일 관대한 처분이다.

프로세스의 current directory는 USB 메모리를 안전하게 제거할 수 없다고 운영체제가 꼬장 부리면서 사용자를 귀찮게 하는 요인 중 하나이기도 하다.
특히 Windows의 경우, 파일 열기/저장 공용 대화상자를 열어서 USB  메모리를 조회하면 해당 프로그램의 current directory도 거기로 바뀌기 때문에 대화상자를 닫은 뒤에도 저런 꼬장이 발생할 가능성이 높아진다.

뭐, 사용자가 USB 메모리를 물리적으로 강제로 제거해 버리는 것에는 장사 없다. 과거의 디스켓이나 광학 드라이브도 매체를 강제로 꺼낼 수 있었으니 말이다. 하지만 이런 일이 발생하면 운영체제의 관점에서는 current directory가 갑자기 없어지는 것이나 다름없고, 거기에 파일이 열려 있던 것들도 다 꼬여 버린다. 프로세스가 아닌 스레드를 강제 종료하는 것만큼이나 좋지 않은 현상이다.
디스크 내용을 날리고 싶지 않으면 사용자도 가능한 한 그런 짓은 하지 않는 게 좋다.

3. Windows의 런타임 환경

Windows에서 전통적인 API 기반의 네이티브 코드 데스크톱 프로그램 말고 선보였던 프로그램 실행 환경으로는..
먼저 2000년대(XP..)엔 .NET이란 게 있었다. 얘는 네이티브가 아니라 가상 머신에서 돌아갔고, 언어도 C#가 주류였다. C++에는 C++/CLI라는 변종 언어가 도입됐다.
그 뒤 2010년대(8..)엔 메트로 UI와 함께 C++/CX라는 변종 언어가 도입됐다. 얘는 데스크톱 환경은 아니지만 의외로 네이티브 코드 기반이었다.

.NET이 표방했던 것이 언어의 통합이라면, Windows 8이 표방했던 것은 기기(PC와 모바일?)의 통합이었다. 그래서 오죽했으면 시작 버튼을 없애는 초강수까지 뒀었다.
그러나 Windows 8은 망했으며, 결정적으로 Windows Phone/Mobile도 안드로이드와 iOS에 완전히 밀렸다. 이젠 마소에서도 그쪽 사업을 접었다. 그 대신 Windows 10은 ARM용이 정식으로 출시되어서 그 CPU에서 네이티브 데스크톱 앱을 그대로 돌릴 수 있게 됐다.

그럼 이 와중에 메트로 앱을 돌리는 Windows Runtime이라는 건 무슨 존재의 의미를 갖게 되는지 난 궁금하다. 답을 잘 모르겠다.
그냥 데스크톱 앱보다 글자 큼직하고 시각적으로 flat하고, 안드로이드 용어로 치자면 material design스러운 외형을 제공하는 GUI 엔진 그 이상도 이하도 아니어 보이는데..??
쉽게 말해 기존 공용 컨트롤이 '제어판'을 가동한다면 이 UI 엔진은 '설정'을 가동한다는 것이다.

마소에서 새로운 걸 시도한 것이 언제나 다 성공적이고 오래 유지된 건 아니었던 듯하다.
그래서 GDI+는 닷넷 시절에 잠깐 뜨다가 Direct2D 부류로 대체됐고, 오히려 운영체제의 근간으로서 넘사벽급의 짬밥을 자랑하는 재래식 GDI보다도 존재감이 없어졌다.
Edge 브라우저는 잘 알다시피 재개발되어서 사실상 크롬과 다를 바 없는 브라우저가 됐다. 마소의 지난 20여 년의 개발 트렌드를 회고해 보니 이런 분석과 결론이 나온다.

4. 이모지, 날개셋 입력 패드

Windows 10의 1803버전쯤부터는 win+.을 눌러서 이모지 문자표를 꺼내는 기능이 추가되었다.
날개셋 한글 입력기에서는 지난 9.81 버전부터 자체적으로 이모지 문자표가 추가되었다. 그럼 이건 언뜻 보기에는 기능 중복처럼 보이지만 실제로는 꼭 그렇지 않다.

운영체제의 이모지 문자표는 마우스로 딴 델 클릭하기만 해도 사라져 버리는 반면, 날개셋의 입력 도구는 그렇지 않다. 더구나 결정적으로 이 문자표는 날개셋 편집기에서 자체 입력기를 지정해 놓았을 때는 사용할 수 없다.
그리고 내 프로그램에서는 선택된 이모지를 복사하기, 그리고 cursor가 가리키는 이모지를 문자표에서 찾아서 역으로 표시하기 같은 기능도 갖추고 있다.

예전에도 언급했듯, 2018~19년에 걸쳐 추가된 ‘필기 인식’과 ‘이모지’는 날개셋의 고유 기능이 아니라 운영체제가 제공하는 기능을 자체적인 UI 껍데기를 씌워서 제공하는 대표적인 입력 도구이다. Full feature를 갖춘 한글 IME로서 저런 기능도 한 프로그램 내부에서 제공할 필요가 있기 때문이다.

뭐 그건 그런데.. 운영체제에서 기본 제공하는 이모지 문자표는 응용 프로그램에다가 어떤 방식으로 이모지 문자를 보내는 걸까? 그게 갑자기 궁금해졌다. 쟤는 기술적으로는 ‘날개셋 입력 패드’과 비슷하게 훅킹을 사용해서 IME 메시지를 보낼 것 같은데..

프로그램이 TSF를 감지하는지 여부를 따져서 지원하면 TSF 방식으로 문자를 보내고, 그렇지 않으면 기존의 IME 메시지를 보낸다는 것을 확인할 수 있었다. IME 메시지만을 사용하는 날개셋 입력 패드보다 더 고차원적이다. 사실, TSF를 지원해야만 메트로 앱에서도 이모지를 입력할 수 있을 것이다.

날개셋 입력 패드를 처음 개발하던 시절에 본인도 개인적으로는 TSF 방식을 뚫어 볼까 생각을 했었다. 이게 성공하면 외부 모듈뿐만 아니라 입력 패드도 편집기와 비슷하게 주변 문자를 자유자재로 변형하면서 신기한 기능을 제공할 수 있다.

그러나 외부 모듈 하나만 개발해 봐도 내 경험상 TSF는 기술 난이도가 헬이고 응용 프로그램별로 제멋대로 동작하는 구현의 파편화가 너무 심하다. 더구나 그 TSF의 혜택을 보는 프로그램은 매우 소수이며, 편집기와 외부 모듈 다음으로 입력 패드 자체도 사용 빈도가 매우 낮은 제3군의 실험적인 유틸일 뿐이다.

그렇게 TSF를 뚫어 봤자 훅킹은 어차피 메트로 앱에서는 통하지도 않기 때문에 그 단계에서 막히니..
시간과 노력 대비 타산이 맞지 않는다는 결론을 얻어서 그 이상의 연구는 포기했다. 입력 패드는 write-only인 IME 프로토콜만 사용하는 데스크톱 앱 전용 프로그램으로 굳어져서 오늘에 이르고 있다.

5. 유니코드 5.2 자모

아시다시피 지난 10여 년 전에 KS X 1026-1 및 유니코드 5.2에서 옛한글 자모가 여럿 추가되었다. 시기가 시기이다 보니 연속된 공간을 쭉 확보하지 못하고 덕지덕지 지저분하게 추가되었지만, 그래도 잘 살펴보면 프로그래머의 관점에서 복잡함과 불편함을 최소화하는 방식으로 추가되었음을 알 수 있다.

답부터 말하면, 어떤 글자가 한글 초성인지 중성인지 종성인지 판별하기 위해 과거(유니코드 1.1)에는 A<=X<=B라는 영역 검사 하나만이 필요했다. 이제는 그래도 그 영역 검사가 각 성분별로 하나씩만 더 추가되면 된다.

  • 초성은 U+1100부터 1159까지 하던 영역에서 끝부분을 115E로 늘린 뒤(5개 추가), A960부터 A97C라는 새로운 영역 한 곳만 더 살펴보면 된다.
  • 중성은 U+1160부터 11A2까지 하던 영역에서 끝부분을 11A7로 늘린 뒤(5개 추가), D7B0부터 D7C6이라는 새로운 영역을 더 살펴보면 된다.
  • 종성도 그런 식으로 기존 영역을 조금 확장하고 나서 새로운 영역을 더 살펴보면 된다.

잘 알려져 있지 않지만, KS X 1026-1은 종성에 ㅇ으로 시작하는 겹받침(ㅇㄱ, ㅇㄲ, ㅇㅇ, ㅇㅋ)을 그냥 이응이 아닌 옛이응으로 수정한 규격(잠수함 패치..)이기도 하다.

그리고 KS X 1026-2는 정규화 규칙을 추가로 규정해서 현대 한글을 옛한글 자모의 조합으로 표현하는 것을 금지하고, 현대 한글 글자마디와 옛한글 자모가 합성되는 것도 명시적으로 금지했다. 한 한글은 오직 한 가지 방식으로만 표현되게 했다.
Windows는 2012년에 나온 8부터 저게 반영됐고, 날개셋 편집기에서는 지난 2015년에 나온 8.0 버전에서야 반영됐다. 저 표준을 제정한 분과 개인적으로 얘기까지 나누며 설명을 들은 뒤에야 말이다. 엇, 그러고 보니 둘 다 8부터네?!?

유니코드 2.0에서 한글 글자마디 11172자를 따 온 건 예전에 서울 올림픽 유치 성공만큼이나 역사에 길이 남을 위대한 쾌거였다. 현대 한글이 그렇게 정립된 뒤에 옛한글도 저렇게 됨으로써 한글 코드 논란은 완전히 종식됐다.

그 뒤로 유니코드 자체도 2003년쯤이던가 4.0에서 U+10FFFF라는 상한을 명확하게 정하고, 이 이상 글자를 더 등록하지는 않을 것이라고 못을 박았다. 그 이상은 UTF-16으로는 더 표현할 수가 없기 때문이다. 그래서 UTF-8도 4바이트 방식까지만 사용하고 5~6바이트 방식은 봉인했다.

따라서 현재 유니코드에 정의된 모든 평면이 고갈되고 글자들로 꽉 차는 날이 온다면.. 유니코드 위원회는 해산될 것이다. 지금의 문자 코드 체계는 지구와 현 인류 문명이 송두리째 멸망하지 않는 한 쭉 이어질 것으로 보인다.

Posted by 사무엘

2020/07/14 19:32 2020/07/14 19:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1773

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : 9 : ... 170 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/11   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

Site Stats

Total hits:
1483572
Today:
33
Yesterday:
520