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

※ 프로세서 정보 얻기

현재 컴퓨터의 CPU 아키텍처 종류를 얻는 대표적인 함수는 GetSystemInfo이다. SYSTEM_INFO 구조체의 wProcessorArchitecture 멤버의 값을 확인하면 된다.
그런데, 64비트 컴퓨터에서 64비트 운영체제를 실행하고 있더라도 32비트 프로그램은 언제나 이 값이 0, 즉 32비트 x86이 돌아온다. 이는 호환성 차원에서 취해진 조치이다. 기존의 32비트 x86용 프로그램은 새로운 API를 쓰지 않으면 자신이 64비트 x64에서 돌아가고 있다는 걸 까맣게 모르며, 전혀 알 수 없다.

자신이 돌아가고 있는 환경이 진짜 x64인지 확인하려면 GetNativeSystemInfo라는 새로운 함수를 써야 한다. 이건 Windows가 최초로 x64 플랫폼을 지원하기 시작한 윈도우 XP에서 추가되었다. 이 함수가 존재하지 않는 운영체제라면 당연히 64비트 환경이 아니다.

64비트 프로그램이라면 그냥 기존의 GetSystemInfo만 써도 x64를 의미하는 9가 돌아온다. GetNativeSystemInfo는 동일한 코드가 32비트와 64비트로 컴파일되더라도 모두 정확한 동작을 보장한다는 차이가 존재할 뿐이다.

또한, 같은 64비트라도 아이테니엄(IA64) 환경에서는 기존 GetSystemInfo도 32비트 x86 프로그램에서 아키텍처를 x86이라고 속이지 않고 정확하게 IA64라고 알려 준다. 왜냐하면 IA64는 x86과는 명백하게 다른 환경이기 때문에 다르다는 걸 알려 줄 필요가 있기 때문이다. 뭐, 지금은 IA64는 완전히 망했기 때문에 일반인이 접할 일이 없겠지만 말이다.

※ 시스템 메모리 정보 얻기

메모리 양을 얻는 전통적인 함수는 GlobalMemoryStatus이다.
그러나 32비트 프로그램이라도 현재 컴이 64비트 운영체제를 사용하여 램이 4GB보다 많이 있는 걸 제대로 감지해서 표시하려면, 윈도우 2000에서 새로 추가된 GlobalMemoryStatusEx 함수를 써야 한다.

그리고 빌드되는 실행 파일의 헤더에 large address aware 플래그가 켜져 있어야 한다. 비주얼 C++ 기준 Linker → System → Enable Large Addresses를 yes로 지정해 주면 된다. 64비트 플랫폼에서는 이 값이 기본적으로 yes이지만, 32비트 플랫폼에서는 기본값이 no이다.
large address aware이 켜져 있지 않으면 32비트에서는 사용 가능한 가상 메모리가 아예 4GB가 아닌 2GB로 반토막이 난 채 표시된다. 포인터의 최상위 1비트를 비워 준다.

그리고 64비트 바이너리에 대해서는 사용 가능한 가상 메모리의 양이야 언제나 있는 그대로 운영체제가 알려 주지만, 해당 바이너리에 이 플래그가 없으면, 운영체제는 아예 상위 32비트를 비워 줘서 DLL 같은 걸 LoadLibrary해도 언제나 32비트 영역 안에서만 주소를 잡는다. 포인터까지 4바이트짜리 int와 구분 없이 작성된 구식 코드들의 64비트 포팅을 수월하게 해 주기 위한 조치이다.

참고로 64비트 전용 프로그램이라면 Ex 대신 기존의 GlobalMemoryStatus만 써도 괜찮다. 받아들이는 구조체의 크기가 int가 아니라 SIZE_T이기 때문에, 32비트 플랫폼에서는 32비트이지만 64비트 플랫폼에서는 자동으로 64비트가 설정되기 때문이다. Ex 함수는 플랫폼의 비트 수에 관계없이 숫자의 크기가 언제나 64비트 크기를 보장해 줄 뿐이다.

※ 32비트 프로그램이 지금 내가 64비트 운영체제에서 동작하고 있는지 감지하기

딱 그 목적을 위해 IsWow64Process라는 함수가 있다. 이것 역시 윈도우 XP 이상에서 추가되었다.

※ 윈도우 시스템 디렉터리에 접근하기

64비트 운영체제는 잘 알다시피 시스템 디렉터리가 64비트용과 32비트용으로 두 개 존재한다.
32비트와 64비트 프로그램에 관계없이 GetSystemDirectory는 언제나 C:\Windows\system32를 되돌린다.
그리고 윈도우 XP에서 추가된 GetSystemWow64Directory라는 함수가 있어서 역시 32비트와 64비트에 관계없이 C:\Windows\SysWow64를 되돌린다. 다만, 운영체제 자체가 64비트가 아닌 32비트 에디션이라면, 후자의 함수는 에러를 리턴한다.

그러니 의외로 이 함수는 플랫폼에 관계없이 절대적으로 같은 결과를 되돌리는 듯한데, 문제는 64비트 운영체제는 32비트 프로그램에 대해 시스템 디렉터리를 기본적으로 redirection한다는 것이다. 즉, 64비트 운영체제는 32비트 프로그램이 C:\Windows\System32를 요청한다고 해도 SysWow64의 내용을 보여주지 진짜 64비트용 시스템 디렉터리의 내용을 보여주지 않는다.

만약 32비트 기반으로 응용 프로그램 설치 관리자나 파일 유틸리티 같은 걸 만들 생각이어서 진짜로 64비트 시스템 디렉터리에 접근을 하고 싶다면, 운영체제에다 별도의 함수를 호출해서 요청을 해야 한다. 그래서 처음에는 Wow64EnableWow64FsRedirection라는 함수가 추가되었다. 이걸로 잠시 예외 요청을 한 뒤, 내가 할 일이 끝난 뒤엔 다시 설정을 원상복귀해야 했다. 왜냐하면 64비트 시스템 디렉터리에 접근 가능하게 해 놓은 예외 동작을 그대로 방치하면, 나중에 다른 32비트 모듈들이 32비트 시스템 디렉터리에 접근하지 못하게 되기 때문이다.

그런데 MS에서는 함수 디자인을 저렇게 한 것을 후회하고, 위의 함수의 기능을 Wow64DisableWow64FsRedirection과 Wow64RevertWow64FsRedirection 쌍으로 대체한다고 밝혔다. MSDN을 읽어 보면 알겠지만, 64비트 접근 여부 설정치를 마치 stack처럼 다단계로 저장했다가 다시 원상복귀를 더 쉽게 할 수 있게 만들려는 의도이다.

※ Program Files 디렉터리에 접근하기

64비트 운영체제는 응용 프로그램 디렉터리도 64비트용과 32비트용이 두 개 존재한다.
운영체제가 사용하는 특수 디렉터리의 위치를 얻어 오는 함수의 원조는 SHGetSpecialFolderPath이며, 이것은 윈도우 운영체제의 셸의 구조가 크게 바뀌었던 인터넷 익스플로러 4 시절에 처음 도입되었다. 그때는 특수 디렉터리들을 CSIDL이라는 그냥 정수 ID로 식별했다.

그랬는데 윈도우 비스타부터는 이 함수의 역할을 대체하는 SHGetKnownFolderPath라는 함수가 추가되었고, 이제는 식별자가 아예 128비트짜리 GUID로 바뀌었다. 문자열 버퍼도 구닥다리 260자짜리 고정 배열 포인터를 받는 게 아니라, 깔끔하게 별도의 동적 할당 형태가 되었다.

64비트 운영체제에서 64비트 프로그램은 64비트와 32비트용 Program Files 위치를 아주 쉽게 얻어 올 수 있다. 32비트를 가리키는 식별자가 따로 할당되어 있기 때문이다. 그러나 32비트 프로그램이 64비트 운영체제의 64비트 위치를 얻는 것은 위의 두 함수로 가능하지 않다. SpecialFolder 함수는 64비트만을 가리키는 식별자 자체가 없으며, KnownFolder함수도 32비트 프로그램에서 FOLDERID_ProgramFilesX64 같은 64비트 식별자를 사용할 경우 에러만 돌아오기 때문이다.

32비트 프로그램이 64비트 Program Files 위치를 얻는 거의 유일한 공식적인 통로는 의외의 곳에 있다. 바로 환경변수이다.

::ExpandEnvironmentStrings(_T("%ProgramW6432%\\"), wt, 256);

위의 환경변수를 사용한 코드는 32비트와 64비트에서 동일하게 64비트용 Program Files 위치를 되돌려 준다.

결론

이렇듯 32비트에서 64비트로 넘어가면서 윈도우 API의 복잡도와 무질서도는 한층 더 높아졌음을 우리는 알 수 있다. 가능한 한 급격한 변화와 단절을 야기하지 않으면서 새로운 기능을 조심스럽게 추가하려다 보니 지저분해지는 건 어쩔 수 없는 귀결이다.

프로그램 배포 패키지를 32비트 exe 하나만 만들어서 64비트와 32비트 플랫폼에서 모두 쓸 수 있게 하면 좋을 것 같다. 32비트 플랫폼에서는 32비트 바이너리만 설치되고, 64비트 플랫폼에서는 비록 32비트 EXE라도 64비트 프로그램 디렉터리들을 모두 건드릴 수 있어야 한다. 그런 프로그램을 만들려면 이 글에서 언급된 테크닉들을 모두 알아야 할 것이다. 설치 프로그램이니 UAC 관리자 권한이 필요하다는 manifest flag도 내부적으로 넣어 주고 말이다.

아, 그러고 보니, 윈도우 9x 시절에는 시스템 디렉터리가 16비트와 32비트로 나뉘어 있지도 않았다. NT 계열로 와서야 system과 구분하기 위해서 system32가 별도로 생기긴 했지만, 16비트용 시스템 디렉터리의 위치를 얻는 별도의 API는 존재하지 않았으며, 사실 필요하지도 않았다. 16비트 프로세스는 이제 NTVDM 밑에서 돌아가는 완전 고립된 별세계로 전락했기 때문이다.

Posted by 사무엘

아문센이 선택한 경로는 스콧이 선택한 경로보다 남극점에 96km 정도, 즉 서울-천안 정도의 거리만치 더 가까운 경로였지만, 완전히 새로운 길을 개척해서 가는 것이었다. 스콧의 경로는 선배 탐험가인 어니스트 섀클턴이 갔던 경로와 동일했다. 거기에다 아문센은 스콧보다 출발도 열흘 정도 더 일찍 했다.
아문센은 1등에 대한 압박 때문에 더 일찍 출발하려 시도를 했지만 역시 맹추위와 준비 미숙 때문에 포기하고 되돌아온 적도 있었다. 그렇잖아도 아문센은 북극점을 먼저 정복하려 했는데 선두를 미국인에게 빼앗겨서 조바심이 난 상태였기 때문이다.

참고로 섀클턴은 스콧보다 먼저 남극 탐험을 갔지만, 준비 미숙과 물자로 부족으로 인한 실패를 인정하고 북극점을 약 150km 정도 앞둔 지점에서 미련 없이 진행을 포기하고 되돌아온 사람이다. 그 대신 모든 대원들이 생환하는 데 성공했다.

아문센은 남극점을 빨리 찍고 돌아온다는 그 목표에만 집중하여 대원들도 전부 항해 측량술을 알고 스키를 능숙하게 탈 줄 알며 혹한 환경에서의 생존 능력이 뛰어난 베테랑들로 뽑았다. 그러나 스콧은 겸사겸사 학술 탐사에도 큰 비중을 둬서 대원 중엔 과학자들도 있었다. 군인보다는 민간인을 선호했던 셈. 스콧은 그 힘든 와중에도 죽는 마지막 순간까지 남극에서 채취한 광물을 16kg치나 갖고 보관하고 있었다.

아문센은 북극 원주민들로부터 노하우를 전수받은 대로 남극에 갈 때도 물이 스며들지 않는 두꺼운 가죽옷을 입었고, 짐을 싣는 썰매는 개들을 이용해 운반했다. 현지에서도 수시로 바다표범들을 사냥해서 식량을 비축했고, 탐험 중에도 효용이 떨어진다 싶으면 가차없이 개들을 잡아먹고 심지어 잡은 개고기를 다른 개에게 사료로 주기도 했다.

그러나 스콧은 원주민들이나 입는 가죽옷을 저속하다고 거부하고 개고기도 안 먹었으며, 현지에서의 사냥 역시 할 생각을 않았다. 개나 말이 죽으면 잡아먹기는커녕 묻어서 장례를 치러 줬을 정도이니! 모든 물자는 대영제국에서 조달하는 것만으로 충당하려 했던가 보다. 그러나 영국제 모직물 코트는 옷이 물에 젖고 얼면서 ‘망했어요’ 상태가 되었다.

이들은 개 대신 조랑말과 스노우모빌(설상차)을 활용했는데, 말은 평범한 환경에서야 개보다 먹는 양에 비해 큰 수송력을 제공하는 게 사실이지만 별도의 사료를 챙겨 가야 하며 개들보다 추위에 훨씬 취약했고 잘못해서 크레바스에 빠지기라도 하면 답이 없었다. 스노우모빌은 매서운 추위와 험악한 지형에서 무용지물로 전락했으며, 후원사로부터 지원받은 막대한 양의 통조림도 얼어서 안 따지거나 심지어 터지기 일쑤였다.

영국이 자랑하던 자본력과 당대의 과학 기술은 남극에서만은 그들이 한낱 피지배민 루저로 치부하던 원주민들의 생활 노하우를 앞설 수 없었다.

아문센은 1911년 10월 20일부터 그 해 12월 14일까지 55일 동안 거의 1300km에 달하는 거리를 이동한 끝에 남극점에 도달하는 데 성공했다. 매일 23~24km씩 진행한 셈. 남극점 주변엔 그 어떤 인간의 흔적도 없었으니 그들이 1등을 한 게 확실했다.

아문센은 영국인들이 한 근성을 하기 때문에 스콧 팀도 아마 며칠 안으로 남극점에 곧 도착할 거라고 생각했다. 그러나 스콧 팀이 도착한 것은 그로부터 34일이나 지난 이듬해 1월 17일이었다. 출발 시기가 열흘이 차이가 나고 거리 차이가 100km 정도 났으니 두 주~보름 정도의 간극은 자연스럽지만 한 달이 넘게 차이가 났다는 건 스콧 팀이 시스템적인 비효율로 인해 진행도 더뎠음을 의미한다.

그들은 이미 하루 전인 16일부터 무수한 개들과 썰매 자국을 발견했다. 그리고 남극점에 다다르니 거기엔 역시나 노르웨이 깃발과 함께 천막이 만들어져 있었고, 약간의 물자와 쪽지가 적혀 있었다. 쪽지에 적힌 글은 대략 다음과 같은 요지였다고 한다.

아문센은 라이벌을 배려해서 정말 정중하고 대인배스러운 행동을 한 것이었지만, 이 문구는 스콧에게는 가히 자존심을 건드리고 비수를 꽂는 대목이 아닐 수 없었다. 실제로 스콧 팀은 물자가 부족해서 추위와 굶주림에 시달리면서도 아문센이 남긴 보급 물자는 거들떠보지도 않았다. 이것은 현명하지 못한 선택이었다.

아문센 팀은 1월 25일에 자기네 베이스 캠프로 무사히 귀환했다. 갔던 길의 역순으로 그대로 돌아오는 것이었고, 귀환이 42일이 걸렸으니 55일이 걸린 출발보다 기간이 두 주 정도 더 단축됐다.

그러나 개도, 말도, 설상차도 없이 터덜터덜 허탈하게 귀환하던 스콧 팀에게는 이제부터 재앙이 시작되었다. 귀환을 시작한 지 한 달이 경과한 2월 17일인데 이들은 거의 반밖에 진행을 못 했다. 그리고 이때 팀원 중 지질학자인 에드가 에반스가 가장 먼저 혼수 상태에 빠졌다가 목숨을 잃었다. 그는 이미 몇 번 추락 사고를 당해서 뇌진탕과 폐렴 증세로 인해 건강이 몹시 안 좋던 상태였다.

그리고 그로부터 또 한 달이 경과하여 3월 17일이 되었다. 귀환 60일째이고 전체 경로의 70% 정도는 완주한 시점이었다. 대원 중 로렌스 오츠는 발에 심한 동상을 입어서 이미 괴저가 발생하고 거의 걸을 수가 없는 지경이 되어 있었다. 그는 대원들이 자신을 부축하고 자신과 보조를 맞추느라 귀환이 지체되고 있는 걸 알았으며, 제발 자기를 버리고 먼저 가라고 간청했다. 그러나 스콧은 그렇게 하지 않았다.

이에 오츠는 그 날 저녁, “대장님, 밖에 좀 나갔다가 오겠습니다”란 말을 남기고는 불편한 발을 이끌고 눈보라가 휘몰아치는 캠프 밖으로 절뚝거리며 나갔고, 그 길로 자취를 감춰 버렸다. 그는 시신조차도 영영 발견되지 않았다. (눈보라가 얼마나 지독했으면, 눈에 찍힌 발자국조차 이내 사라졌던가 보다.) 스콧은 오츠가 일부러 죽음을 택했다는 걸 눈치 채고, 그가 영국 신사다운 최후를 맞이했다고 슬퍼하는 한편으로 그를 칭송했다.

그러나 이런 오츠의 살신성인도 나머지 세 명을 궁극적으로 살리지는 못했다. 살인적인 악천후 때문에 3월 19일자 캠프에서 스콧 일행은 더 나아가질 못하고 1주일이 넘게 고립되었다. 베이스 캠프까지는 약 200km쯤 남았기 때문에(이미 1000km를 넘게 이동했고, 다 와 감) 저 기간 동안 조금만 더 분발했으면 근처의 보급 기지에도 도착했을 것이고, 베이스 캠프에까지 살아서 돌아갈 가능성은 충분했을 터이나 그들은 그럴 수 없었다.

남극에 무슨 생각으로 물을 끓여야 하는 번거로운 홍차를 가져갔는지 모르겠다. 식료품과 연료는 이미 다 떨어졌고 홍차는 생잎을 뜯어먹어야 했다. 그러다가 3월 29일, 나머지 대원인 에드워드 윌슨과 헨리 바우어즈가 극심한 추위와 굶주림, 어둠, 절망으로 인한 기력 소진 때문에 목숨을 잃었고, 가장 마지막으로 탐험대장인 스콧도 같은 캠프 안에서 사망했다. 그의 일기장에 죽은 두 대원에 대한 언급도 있기 때문에 스콧이 가장 나중에 죽은 것으로 여겨진다.

익사나 추락사처럼 단번에 훅 간 게 아니라 마치 성냥팔이 소녀처럼 굉장히 처절하고 비참하게 죽은 셈이다. 스콧 일행의 시신은 그로부터 무려 8개월 뒤에 남극에 여름이 다시 찾아왔을 때 미국의 탐사대에 의해 발견되었다.

자, 다음 그림은 아문센(빨간색)과 스콧(초록색)의 남극 탐험 경로를 정리한 것이다. (출처: 영문 위키백과)

영국에서는 영국 신사의 기품을 지키면서 남극에서 장렬히 산화한 스콧을 애국자와 영웅으로 열렬히 치켜세우고 떠받드는 한편으로, 어쨌든 1등을 해 버린 아문센을 헐뜯고 잡아먹지 못해 안달이었다. 한때는 아예 대놓고 역사를 왜곡하여 스콧이 먼저 남극점에 도착했다고 가르치기까지 하다가, 국제 사회로부터의 조롱과 비웃음을 한몸에 받고서야 슬쩍 시정했다.

영국이 이런 데서 은근히 찌질한 짓도 좀 했다. 영국인 중에서 양심껏 소신껏 아문센을 지지하고 그의 업적을 인정한 사람은 스콧의 롤모델 탐험가이던 섀클턴 정도가 고작이었다. 어니스트 섀클턴은 이 글에서는 많이 다루지 않지만, 아폴로 13호 같은 ‘성공적인 실패’를 기적적으로 이룩한 덕분에 이 양반 역시 아문센만큼이나 전설이 아니라 레전드급인 위대한 탐험가로 역사에 남아 있다. 관심 있으신 분은 찾아 보기 바란다.

콩진호, 콩라인-_- 같은 예외를 빼면, 세상 역사에서 2등은 정말 너무 가혹하다 싶을 정도로 기억에 남지 못하는 게 통념이다. 허나, 남극에서만큼은 영국의 저런 집요한 로비로 인해 각종 시설물에 꼭 ‘스콧-아문센’ 브랜드가 심심찮게 남아 있다.

남극의 정복자 아문센은 거의 60년 뒤에 달에 갔다 온 닐 암스트롱만큼이나 세계의 영웅으로 등극하였고 곳곳에서 강연 요청이 쇄도했다. 노르웨이 국내에서야 물어 보면 잔소리. 지금 한국으로 치면 김 연아, 안 철수 급의 유명인사가 되었다. 듣보잡 빈곤국이던 노르웨이의 위상을 그만치 끌어올린 사람이 역사상 누가 있었겠는가?

아문센은 교통 덕후여서 이 탐사 후에도 활발히 탐험 활동을 하였으며, 특히 20세기 초는 항공기 기술이 개발되던 시기인지라 남극을 아예 비행선으로 횡단하기도 했다. 그러다 1928년에 비행선 사고로 인해 행방불명되는 걸로 최후를 맞이했다.

훗날 냉전 시절에 미국과 소련이 우주 개발 경쟁을 할 때도 인공위성을 먼저 띄우고 달에 사람을 먼저 보내려고 기싸움이 엄청 벌어지긴 했다. 그러나 우주 개발은 전적으로 자본력과 기술에 의해 승패가 기울었으며, 다행히 우주 공간에서 실종되거나 죽은 사람도 없다. 또한, 소련은 자기네 연구 과정을 워낙 폐쇄적으로 공개를 잘 안 하기도 했고 말이다. 그래서 아문센과 스콧에 필적하는 드라마틱한 이야기도 없는 듯하다.

Posted by 사무엘

인류 역사상 인간이 지구 밖으로 제일 멀리 나간 여행은 1970년의 아폴로 13호이다. 정말 다행스럽게도 세 명의 승무원이 모두 살아서 돌아오긴 했지만 예상치 못한 폭발 때문에 계획이 틀어진 후 승무원과 관제 센터 직원들은 가히 피 말리는 시간을 보냈으며, 특히 승무원들은 갈증과 추위에 떨면서 엄청난 고생을 해야 했다.

지구에서 가장 높은 산은 8848m(현재는 더 높아져서 8850이라고도 하는데)의 높이를 자랑하는 에베레스트 산이며, 인간이 역사상 최초로 공식적으로 등반 후 생환에 성공한 것은 1953년의 에드먼드 힐과 텐징 노르게이의 공동 등반이다.

지구에 있는 모든 산들은 높아 봤자 대류권의 영역을 벗어나지 않으며, 대류권에서는 고도가 1km 상승할수록 온도는 대략 6.4도 정도 떨어진다. 그래서 이런 높은 산들은 일년 내내 기온이 영하이고 눈이 녹지 않는 만년설 지대이다.
또한 해발 고도가 5천 m 정도 되면 기압도 해수면의 절반 정도로 떨어지고, 에베레스트 산의 정상 무렵에서는 아예 1/3기압이 된다. 물은 100도보다 낮은 온도에서 끓기 때문에 밥을 지어도 쌀이 잘 익지 않으며, 산소도 덩덜아 부족하기 때문에 비숙련자는 조금 걷기만 해도 지표면에서 100미터 전력질주를 한 것처럼 헉헉 숨이 차게 된다고 한다.

에베레스트 산 정도면 지형이 그렇게 험하지 않으며(특히 이웃의 콩라인 K2에 비해서) 인지도도 압도적이고, 덕분에 등산로도 개척될 대로 개척되어 있어서 찾는 사람이 연간 수백여 명에 달한다. 그래서 인근의 네팔은 등산료와 관광 수입을 톡톡히 챙기고 있다고 한다. 지금은 잘 알다시피 심지어 산소통 없이 등반한 사람까지 나왔다. 그러나 세계의 지붕인 이런 산들은 오늘날에도 만만한 곳이 아니어서 날씨가 험악할 때는 입산할 수 없으며, 해마다 최소한 국내의 철길 건널목 사망자 정도만치는 산에 오르다 죽는 사람이 꼭 나온다고 한다.

한편, 지구에서 가장 깊은 바다는 필리핀의 근처에 있는 마리아나 해구 중에서도 더욱 아래에 11034m의 깊이를 자랑하는 비티아즈 해연이다. 1957년에 이곳을 발견한 구소련의 탐사선 비티아즈 호에서 유래된 이름이다. 이 탐사선이 그렇다고 해연의 밑바닥까지 다 내려가 본 건 아니고, 일정 수준 이상의 깊이부터는 그냥 초음파만으로 깊이를 측정한 거라고. 실제로 거기 밑바닥까지 내려간 건 1960년에 미국에서 트리에스테-II 호가 해냈다.

일반 비행기가 공기 때문에 성층권도 못 벗어나고 한없이 높게 뜰 수는 없듯, 일반적인 잠수함들 역시 의외로 깊게 못 들어간다. 겨우 대륙붕 정도의 깊이밖에 못 들어가고 최첨단 핵잠수함도 500~700m 정도의 수심이 한계라고 한다. 군사 목적으로도 더 깊게는 들어갈 필요도 없고, 어차피 그 깊이 안에서 더 오래 머무르는 것만이 목적이니까 말이다. 더 깊게 들어가려면 그 용도로 특별히 제작된 심해 잠수정을 써야 한다.

1만 미터 정도의 수심에서 물체가 받는 압력은 무려 1천 기압. 1㎠당 8톤의 힘이 가해져서 주변에 있는 모든 것을 으스러뜨릴 것만 같은 살인적인 압력이다. 수심이 10미터 깊어질 때마다 대략 1기압이 증가하며(참고로 금성의 표면의 대기압이 90~95기압. 덜덜~) 덩달아 빛도 적어져서 어두워진다. 그래서 어느 수심과 압력 이상부터는 그야말로 암흑천지가 된다. 태양열이 닿지 않으니 수온 역시 영하급이다.

심해 잠수정은 실용성은 포기한 채 최대한 둥글고 작고 단단하게 만들어졌고, 트리에스테 호는 무거운 추를 잡고 가라앉은 뒤, 그 추를 바다에 버리고 다시 떠 올라오는 방법을 썼는데, 그때는 기술상의 한계로 20분 남짓밖에 못 머무르고 다시 올라와야 했다. 그러다가 타이타닉 호의 제작자인 제임스 카메론 감독이 거의 반세기 만에 비티아즈는 아니고 챌린저 해연이라고 만만찮게 깊은 밑바닥을 2012년 지난 3월 말에 탐사한 바 있다.

우주나 심해 탐사는 아무래도 전적으로 기계에 의존하지 않을 수 없다.
그러나 고산 등정은 성격이 약간 다르다. 극소수의 연구원이 최첨단 기계에 탑승해서 탐험하는 형태가 아니라 목적지를 직접 발로 걸으면서 탐험하며, 물자를 보급하는 보조 staff의 숫자도 아주 많다. 마치 영화 한 편이 배우들에 의해서만 만들어지는 게 아니듯이 말이다.

오늘날은 마음만 먹으면 항공기로 금방 에베레스트의 정상에 오를 수 있는데 왜 그렇게 힘들게 산을 오르냐는 질문은, 이건 마치 상대방을 쓰러뜨리려면 권총을 쓰면 되는데 뭣 하러 무술을 연마하냐 하는 식의 우문우답이 될 듯하다.

지구에 저런 높은 산 말고 또 남아 있는 혹독한 미지의 환경으로는 사막과 극지방이 있다. 이 중 사막은 제끼고, 지구의 자전을 느낄 수 없는 두 꼭지점인 북극점과 남극점은 18세기~19세기 초 사이에 탐험계의 성배로 여겨져 왔다. 그 당시 인류 최초로 북극점을 정ㅋ벅ㅋ한 사람은 미국의 로버트 피어리로 알려져 있었다(1909년 4월. 훗날 그건 오류로 판명되긴 했지만). 그리고 남극점을 정복한 사람은 잘 알다시피 그 이름도 유명한 노르웨이의 로알 아문센이다(1911년 12월).

산이나 해저나 우주 같은 다른 곳에 비해서는 비교적 일찍 정복된 영역이지만, 두 극점 중에서 남극점에는 다른 미지의 영역에는 없는 특이한 역사가 존재한다. 그때는 노르웨이의 아문센 팀과 영국의 로버트 스콧 팀이 남극점을 먼저 찍으려고 경쟁 중이었으며, 궁극적으로는 유럽의 듣보잡 빈민국에 불과했던 노르웨이가 물자가 월등히 더 풍부했던 대영제국을 누르고 압도적인 1등을 차지했기 때문이다.

게다가 아문센 팀은 1등을 했을 뿐만 아니라 한 명도 죽거나 다치지 않고 무사히 돌아와서(개들만 약 40마리쯤 죽었음;;) 국제적인 영웅이 된 반면, 스콧 팀은 그렇잖아도 1등 자리를 빼앗기고 우울하게 돌아오는 길에 며칠째 혹독한 눈보라 때문에 조난을 당해서 스콧 포함 5명의 팀원들이 추위와 굶주림 속에 모조리 목숨을 잃고 말았다.

두 팀의 결말이 이렇게 극과 극으로 달라진 것에는 단순히 운(날씨)보다 훨씬 더한 차이가 존재했다. 아주 간단히 요약하자면, 아문센은 원주민들의 노하우를 받아들여 극도로 최적화와 현지화를 잘 해 간데 반해 스콧은 남극 탐험을 너무 낭만적으로 생각했으며 쓸데없는 곳에서 괜히 명분과 품위만 따지다가 참혹한 낭패를 당했다. 다음 글에서는 이 사람들 얘기를 좀 해 보겠다.

Posted by 사무엘

1.

수학에서 원주율 pi와 자연상수 e는 가장 유명하고 친근한 상수임이 틀림없다. 이들은 유리수를 계수로 가지는 대수방정식의 근이 되지 않는 초월수임이 증명되어 있고, 이들의 정의나 다른 특성에 따라 값을 구하는 식이 여럿 존재한다.

pi = 4(1/1 - 1/3 + 1/5 - 1/7 + 1/9 ... )
e = lim (1 + 1/n )^n (n → 무한대)

pi의 저 공식은 정말 이보다 더 쉬울 수 있을까 싶을 정도로 너무 깔끔하고, 저게 도대체 파이와 어떻게 관계가 있을까 하는 생각이 들기도 한다. 사실, 저것은 arctan(tan의 역함수) 함수의 테일러 급수에다가 1을 대입하여 얻은 식이다. 45도일 때 기울기(=탄젠트)가 딱 1이 되니, 저 값은 pi/4가 나오고, 따라서 pi를 구하기 위해 4를 곱한 것이다.

e의 경우, 숫자를 무한대로 띄우는 n승과, 그 지수 연산의 발산 효과를 무효로 만드는 1/n (1에다가는 아무리 큰 지수 연산을 해도 그대로 1..)의 극한이 저렇게 가까워지는 게 신기하기 그지없다.

그러나 위의 두 공식은 둘 모두 n 값이나 항의 개수가 100000이 넘어가도 소숫점 겨우 네댓 자리까지밖에 일치하지 않을 정도로 수렴이 대단히 느린 게 흠이다. 이 방식으로는 소숫점 n째 자리까지 일치하려면 계산량이 n의 지수함수 형태로 증가해야 한다. 알고리즘으로 치면 엄청나게 비효율적인 알고리즘이다.
그래서 실제로 pi나 e의 값을 계산할 때는, 매 회에 좀 더 복잡한 계산이 수행되더라도 적은 횟수로도 더 빠르게 수렴하는 다른 식을 찾아 쓴다.

자연상수 e는 exp(x), 즉, 미분해도 자신과 동일한 함수의 테일러 급수로부터 얻은 식을 이용해 값을 구할 수 있다. 바로 n팩토리얼의 역수의 무한합인데, 직관적일 뿐만 아니라 수렴 속도도 아주 빠르다. 물론 팩토리얼이 숫자를 폭발적으로 키우는 연산이긴 하지만, 그만큼 정확도도 커져서 14!까지만 계산해도 소숫점 8~9자리까지 정확한 값이 나온다. 그래서 이걸로 끝이고 다른 계산법을 찾을 필요가 사실상 없다.

자연상수라는 이름엔  '자연'이라는 단어가 괜히 붙은 게 아니다. 얘는 수학의 입장에서는 특성이 매우 자연스럽고 직관적이고 사랑스럽기까지(!) 한 수이기 때문에, 초월수라는 증명도 상당히 초창기에 이뤄졌다. 리우빌 상수--10진법 기준 n!에 속하는 소숫점 자리만 1이고 나머지는 0인 좀 괴랄한 0.110001000… --처럼 초월수의 존재를 증명하기 위해 일부러 설정된 수가 아닌 수 중에서는 초월수라는 게 증명된 최초의 수가 바로 자연상수이다.

pi는 e보다 더 오묘한 수여서 초월수 증명도 10년 남짓 더 늦게 나왔으며, 더욱 복잡하고 다양한 유도식들이 존재한다. 특히 컴퓨터가 발명되고 원주율 계산이 컴퓨터의 성능을 측정하는 잣대로 통용되기 시작한 뒤부터는 컴퓨터의 입장에서 더욱 계산하기 쉬운 형태의 식이 연구되기 시작했다. 그래도 어느 것이든 e만치 형태가 간단하면서도 빨리 수렴하는 식은 존재하지 않는 것 같다.

비록 컴퓨터 시대에 발견된 식은 아니지만,
sqrt(2) / 2 라는 분수에서 시작하여
sqrt( 2+ sqrt(2) ) / 2와 같은 식으로 분자에다가만 x → sqrt(2 + x)로 변환을 하면서 생성된 수들을 계속 곱하면 2/파이 (파이의 역수의  두 배)에 수렴하는데,
이것도 e만치는 아니지만 계속되는 곱셈과 제곱근 버프 덕분인지 수렴 속도가 빠른 편이다.

2.

1부터 n까지 자연수가 있고 이들의 역수를 나열하면 조화수열이 된다. 조화수열의 무한합은 비록 무지막지하게 느리지만 무한대로 발산한다는 것이 알려져 있다.
한편 n!의 역수의 무한합은 아까 말했듯이 e가 되는데,
그럼 n^2의 역수의 무한합은 무엇이 될까?

거듭제곱의 지수가 1보다 커지는 순간부터 역수의 무한합은 유한한 값으로 수렴하긴 한다. 그러나, 그 수렴값의 특성을 알아내는 건 아주 어려운 일이어서 지금까지도 알려진 게 그리 많지 않다.
n^x의 역수의 무한합을 일반적으로 x에 대한 리만 제타 함수값이라고 한다.

그리고 그 x가 짝수일 때는 놀랍게도 pi와 관련이 있는 값으로 수렴한다는 것이 천재 수학자 오일러에 의해 밝혀졌다. 가령, 2일 때는 이렇다.

1 + 1/4 + 1/9 + 1/16 + 1/25 ... = pi^2 / 6

그러니 이것도 응당 파이를 구하는 데 쓸 수 있는 공식이다.
비록 이것 역시 아까의 1/3 1/5 1/7 공식 만만찮게 수렴 속도가 몹시 느리기 때문에 실용성은 떨어지지만 말이다.

여기서 갑자기 pi가 튀어나오는 것도 신기하지만, 이 수의 진짜 놀라운 면모는 또 다른 곳에 있다.
바로 이 수는 자연수에 존재하는 소수의 분포와 관계가 있다.

1부터 N 사이에 있는 임의의 두 자연수를 뽑았을 때 이것이 서로 소일 확률은 N이 커질수록 바로 저 수, 다시 말해 (pi^2)/6의 역수로 수렴한다! 그 확률은 대략 60.8%이다.

아니, 리만 제타 함수에서 파이가 왜 조건부로 튀어나오며, 게다가 미적분· 해석학하고는 아무 관계가 없는 정수론과 관련된 의미가 왜 이런 데서 발견되는 걸까? 이걸 알아 낸 사람도 오일러이다.

2를 포함해서 리만 제타 함수의 짝수승의 값은 그래도 pi가 얽혀 있으니 초월수라는 건 확실히 인증이다만 홀수승의 값들은 무리수인 것만 알려져 있지 다른 특성은 알려진 바가 없다. 초월수일 게 거의 확실시되고 있긴 하나, 그조차도 정식으로 증명되지는 못했다.

3일 때의 값은 '아페리 상수'라 하여 일부 공학 분야에서도 쓰인다. 이 수가 무리수라는 증명을 1978년에 한 프랑스의 수학자 아페리의 이름을 딴 것이다. 정의대로 각 자연수들을 3승한 뒤 역수를 구해서 더하면 값을 구할 수 있지만, FM 방식은 역시 수렴이 더디기 때문에 훨씬 더 복잡하지만 더 빨리 수렴하는 별도의 급수 전개를 써서 값을 구한다.

그런데 이 값의 역수는 임의의 세 자연수가 서로 소일 확률이라고 한다. 마치 가위바위보에 참여하는 인원이 많아질수록 무승부가 나올 확률이 치솟듯, 세 자연수는 두 자연수일 때보다 서로 소일 확률이 올라가서 그 값은 약 83.1%에 달한다.

작은 범위에서라도 정말 얼추 그렇게 되는지는 프로그램을 짜서 간단히 확인해 볼 수 있다.
1부터 N까지 3중 for 문을 작성해서 모든 숫자 조합에 대해서 최대공약수를 구해서 1이 나오는 경우를 세면 되는데, N이 몇천 정도만 돼도 3중 for 문은 오늘날의 최신 컴퓨터에서도 버벅대는 작업량이다.

3.

그래서 본인, 이 기회에 멀티코어 프로그래밍을 실습해 봤다.
i5 쿼드코어답게 CreateThread 함수로 스레드를 4개 만들어서 뺑뺑이를 돌리는 분량을 인위로 분할한 뒤, 계산 결과를 취합했다. 그랬더니...

809615629/973620600 0.831551 (7753)
809615629/973620600 0.831551 (3448)

코어 하나밖에 못 쓰고 고로 CPU를 최대 25%만 쓰던 싱글스레드 오리지널 코드는 7.8초가 걸린 반면,
스레드를 여러 개 만드는 코드는 CPU를 95% 가까이 점유하면서 제 속도를 내더니, 싱글스레드의 절반이 채 안 되는 3.5초 남짓한 시간 만에 처리를 다 끝내는 걸 알 수 있었다. 실제로 서로 소인 조합이 전체의 83.1%가량을 차지하는 것도 사실이었다.

요즘 세상에 CPU를 70% 이상 한꺼번에 점유하는 프로그램을 내 손으로 직접 만들 일은 없었는데 참 오랜만에 보는 광경이었다. 요즘은 단일 프로그램이 CPU 성능을 제대로 활용하려면 이런 식의 테크닉을 동원해야 한다는 걸 더욱 절실히 느끼게 됐다.

Posted by 사무엘

2003년에 콩코드 여객기가 퇴역한데 이어 2011년엔 미국의 우주 왕복선들도 전량 퇴역했다. 이제는 천조국 미국도 우주 정거장으로 사람을 보내려면 러시아의 소유즈 우주선을 택시 삼아 얻어 타야 한다. 그래도 우주 왕복선이 소유즈보다 더 커서 사람이나 짐을 더 많이 실을 수 있었는데, 아쉬운 점이다.

오로지 학술 목적으로만 우주선을 띄우던 미국 NASA와는 달리, 돈맛을 알아 버린 러시아는 세계의 민간인 억만장자들을 상대로 우주 관광 사업을 벌이고 있다. 잘 알다시피 우리나라의 이 소연 씨를 포함해 전세계적으로 잘 알려진 우주 관광객들도 다 미국이 아니라 러시아를 통해서 우주에 갔다 온 사람이다.
누구든 한 200억 원 정도만 주면 갈 수 있다. 참 쉽죠?

요즘은 그래서 다시 러시아의 우주 기술이 주목을 받고 있는 추세인데, 그 러시아, 아니 구소련은 냉전 시절에 얼마나 공돌이들을 갈아 넣으면서 빡세게 기술을 개발했을지 상상이 되겠는지? 지금으로부터 50여 년 전으로 되돌아가 보겠다.

전산학계에 앨런 튜링이나 폰 노이만 같은 괴수가 있었다면, 항공 우주 공학계에는 로버트 고더드(액체 연료 로켓의 근간을..)부터 시작해 미국에는 폰 브라운, 소련에는 세르게이 코룔로프 같은 진짜 우주덕, 우주 괴수들이 있었다. 일반 항공기처럼 하늘에 잠깐만 떴다가 다시 내려오는 게 아니라 아예 지구 중력을 벗어나서 궤도에 진입하려면 가히 넘사벽급의 동력이 필요하고 이를 제어하는 최첨단 기술이 필요하다. 거기에다 '재돌입 성공' + '사람까지 태우고' 같은 단서가 추가되면 흠..;;

그런 우주 시대의 서막을 연 것은 1957년 10월, 세계 최초의 인공위성인 스푸트니크 1호이다. 이에 고무된 소련은 우주에 생명체를 보내는 게 가능하겠는지를 실험하게 되었다.

그래서 아직 1호가 지구를 돌고 있을 때에 소련은 1호보다 훨씬 더 크고 무거워진 스푸트니크 2호를 뒤이어 발사했는데, 이때는 개를 한 마리 실었다. 그 이름도 유명한 '라이카'라는 암캐이다.
약을 하나 새로 개발해도 임상실험은 먼저 동물에게 하지 않던가. 라이카는 지구 궤도로 나간 최초의 포유류가 되었다.

원래 라이카는 모스크바 길거리에서 주인을 잃고 배회하는 '똥개'였다고 한다. 그런데 어쩌다 보니 소련의 과학자들의 눈에 띄여서 나름 우주의 상황을 상상한 여러 훈련을 시켰다. 물론 얘만 수집한 건 아니지만 여러 후보들 중에서 라이카가 훈련 성적이 가장 좋았다. 사람 말을 잘 듣고 험악한 환경에서도 돌발행동 안 하고, 좁고 어두운 곳에서 얌전히 잘 견디는 성격이었던지라 최종 실험 대상으로 선택되었다.

전해지는 일화에 따르면, 라이카를 맡아서 훈련시키는 일을 한 모 과학자는, 그 개를 발사체에 태워서 공중에 잠시 띄웠다가 다시 돌아오게 하는 줄로만 알았다고 한다. 그러나 나중에 알려진 사실은 예상과 달랐다. 그 당시 소련은 우주 발사체를 무사히 재돌입시켜서 귀환시키는 기술이 아직 없었기 때문에, 스푸트니크 2호는 1호와 마찬가지로 지구를 빙빙 돌다가 대기권으로 떨어져서 마찰열로 인해 유성처럼 불타 없어질 운명이었던 것이다.

그래서 우주선에 탄 개에게는 발사 1주일 후에 독극물이 든 마지막 식사를 제공하여, 인공위성이 아직 지구 궤도에 있을 때 먼저 안락사시킬 계획이었다.
이 사실을 안 과학자는 통곡했지만, 국가의 프로젝트 계획이 그러한데 딱히 어쩔 도리가 없었다고 한다.

스푸트니크 2호는 1957년 11월, 1호가 발사된 지 거의 정확히 한 달 뒤에 발사되었다. 라이카는 온몸이 묶여 감금되다시피하고, 생체 상태를 실시간으로 측정하여 전달하는 장비가 부착되었다. 이거 무슨 카미카제 특공대에 출격하는 전투기 조종사 같다..;;

인공위성 자체는 성공적으로 발사되어 지구 궤도에 잘 진입했다. 1호도 모자라서 1개월 간격으로 2호까지 성공하자 미국은 가히 스푸트니크 쇼크라고 불리는 충격과 공포를 경험하면서 소련의 발달된 우주 기술에 전율하게 되었다.
이에 기세등등해진 소련은, 스푸트니크 2호가 성공적으로 잘 발사되었으며 안에 태운 라이카는 잘 살아 있다가 (유감스럽지만 그래도) 계획대로 1주일째에 안락사를 당했다고 공식 발표했다.

그러나 그로부터 수십 년이 지나서야 폭로된 비밀 문서에 따르면, 라이카는 며칠 못 가 더 일찍 죽었다는 것이 드러났으며, 궁극적으로는 발사된 지 겨우 5~7시간을 못 넘기고 고온· 고압과 굉음으로 인한 극심한 스트레스에 시달리면서 꼼짝도 못 한 채 고통스럽게 죽었음이 드러났다.

고온이라는 게 화상을 입을 정도의 뜨거운 온도이다. 수 시간 후부터 라이카의 심장 박동은 이미 감지되지 않았으니, 그때 진실을 알고 있었던 과학자들의 상심이 컸겠다. 그 원인으로는 선실에다 산소를 공급하고 온도를 조절하는 장치가 제대로 동작하지 못한 것으로 추정되었다.

스트레스가 극심했을 때는 라이카의 심장 박동수는 평소의 3배가 가깝게 뛰었다고 한다. 죽기도 그렇게 죽었을 뿐만 아니라 시체도 재돌입 과정에서 인공위성과 함께 공중분해되었을 터이니 확실한 끔살 인증이다.

라이카는 비록 살아서 돌아오지는 못했으나, 이 실험을 통해 지구 생명체가 지구 궤도에 진입하는 과정과 무중력 상태에 견딜 수 있음이 확인되었으며, 과학자들에게 우주공간에서 생명체 반응에 대한 귀중한 데이터를 제공하였다. (출처: 위키백과) 라이카의 죽음은 '개죽음'으로 그치지 않았다.
짧게나마 그래도 궤도에 진입하여 무중력 상태가 될 때까지 살아 있었기 때문이다. 정말로 사람이 아니라 동물부터 먼저 보내 보길 잘한 것이다.

라이카에 대한 비화가 알려지면서 라이카는 일약 영웅이 되었다. 좀 감수성 예민한 사람이 들으면 눈물이 핑 돌 정도의 스토리이지 않은지? 노래나 만화 같은 매체에도 등장하였으며 외국의 어느 동물 보호 단체에서는 이런 식으로 우주 개발을 강행한 소련 정부를 비판하는 한편으로 라이카의 기일에 맞춰 묵념까지 했다고 한다.

인류의 우주 개발을 위해 희생된 개 한 마리에게도 사람들이 이렇게 연민과 동정을 아끼지 않는다.
그 반면, 인류의 죄를 대속하기 위해서 희생된 어린양을 믿는 게 성경의 기독교라고 이해하면 되겠다.

다음은 추가 설명들.

1. 인간을 우주에 보내기 위해서 진공 상태가 생체에 어떤 영향을 끼치는지, 그리고 무중력 상태에서 얼마나 잘 버틸 수 있는지를 아는 것은 필수였다. 이 분야는 인류 역사상 정말로 경험 데이터가 전무했기 때문이다.
하긴, 과거에 일본군 731 부대가 행한 생체 실험 중에도 진공 실험이 있긴 했다. ㄷㄷㄷ

2. 소련의 도발에 다급해진 미국은 자기네도 황급히 인공위성을 쏘아 올리려 뱅가드(Vanguard) 로켓을 몇 차례 발사하였으나 발사 2초 만에 폭발해 버리는 등, 보기 좋게 실패하고 말았다. 그 뒤에 공돌이들을 더 갈아 넣으면서 연구한 끝에 1년 남짓 뒤인 주노 로켓으로 1958년에야 미국 최초의 인공위성인 익스플로러 1호를 띄운다..

3. 소련에서는 그 뒤 1960년 8월 스푸트니크 5호에 스트렐카와 벨카라라는 2마리의 우주견을 태웠는데, 이들은 지구궤도를 17바퀴 돈 다음 귀환함으로써 지구 궤도 비행 후 살아 돌아온 최초의 생명체가 되었다.

4. 라이카처럼 저렇게 사람을 살리고 자신은 죽은 유명한 개로 한국에는 군견 헌트가 있다. 1990년 3월, 현재로서는 마지막으로 발견된 북한의 남침용 땅굴인 제4 땅굴이 발견되었다. 당시, 헌트는 갱도 내에서 화약 냄새를 맡고 뛰어가다가 땅굴 내부의 목함 지뢰를 밟고 산화하였다. 소대원들의 목숨을 구했음은 두말할 나위도 없다.

군대에서 선임병이 후임을 놀릴 때 “군견이 너(졸병)보다 계급이 높기 때문에, 보면 경례해라”라고 하는 경우가 있는데 그 말은 물론 농담이다. 하지만 헌트는 사후에 진짜로 소위 계급이 추서되었으며, 땅굴 입구에 무덤과 동상, 추모비까지 건립되었다.

5. 라이카는 참고로 사막의 인간 식인범인 라이’타’하고는 관계 없다. 혼동하지 말 것. ㅠㅠ

Posted by 사무엘

※ 다리 한번 많기도 해라. 설명은 서쪽(하류)에서 동쪽(상류) 순이다. 당신은 두 개의 다리 이름 A, B가 주어졌을 때, 이들의 위치 관계를 비교할 수 있겠는가? (정렬용 비교 함수 ㄲㄲ)

방화 대교: 인천 공항 고속도로(130)와 통하는 다리이다. 6차선.

마곡 철교: 공항 철도가 다니는 교량이다. DMC - 김포공항 역 사이에 있다.

가양 대교: 21세기에 건설되었고, 교각들 사이의 간격이 굉장히 긴 다리라고 한다. 6차선.

성산 대교: 국도 1호선의 일부이다. 남쪽으로는 서부 간선 도로로 이어지고, 북쪽으로는 내부 순환로와 연결된다. 6차선.

양화 대교: 국도 6호선의 일부인 8차선 교량으로, 중간에 선유도를 경유한다.

당산 철교: 양화 대교 바로 근처에 있으며, 서울 지하철 2호선이 다니는 교량이다. 기존 교량이 1990년대 중후반에 철거되고 재건설된 이력이 있다.

서강 대교: 여의도로 가는 3대 교량 중 하나로, 6차선이다. 여의도의 서쪽을 경유하다 보니 국회 의사당과 가장 가깝다. 교량 중간에는 밤섬을 경유한다. 북쪽으로는 광흥창과 신촌 역을 찍고 연세대 방면으로 간다.

마포 대교: 자동차 교량들 중에는 꽤 오래 전에 건설되었고 현재는 차선수도 10차선으로 폭이 매우 크다. 여의도의 정중앙을 관통한 뒤부터 경인선 철도를 따라 간다. 국도 46호선의 일부 구간.

(서울 지하철 5호선이 지나는 하저 터널은 북단은 마포 대교 쪽에 있지만 남단은 한 블록 내려간다. 그래서 여의도와 여의나루 역은 국도 46호선상에 있지 않다.)

원효 대교: 마포 대교의 혼잡을 완화하기 위해 보조로 건설된 다리이다. 4차선으로 좁은 편.

한강 철교: 한강에 건설된 최초의 다리. 오늘날은 단선 교량 2, 복선 교량 2로 선로가 6개나 있는 크고 아름다운 3복선 교량의 세트가 되어 있다.

한강 대교: 한강 철교의 도로 equivalent로, 역시 그 전신은 한강 철교와 마찬가지로 일제 강점기에 이미 건설되었으니 역사가 깊다. 중간에 노들섬을 경유한다. 6· 25 때 폭파되었던 다리가 바로 이 지점에 있던 다리이다. 현재는 8차선이다.

동작 대교: 서울 지하철 4호선과 자동차가 공용하는 6차선짜리 다리이다. 남쪽으로는 동작 대로로 이어지지만 미군 기지 때문에 북쪽으로는 더 곧게 이어지는 길이 없다.

반포 대교: 우리나라 최초의 복층 교량으로, 아래에 잠수교가 있다. 폭은 6차선. 남쪽으로는 반포 대로를 타고 고속버스 터미널과 서초 역, 예술의 전당까지 쫙 내려가며, 북쪽으로는 남산 3호 터널로 갈 수 있다.

한남 대교: 아래로는 경부 고속도로 및 강남 대로와 직결하고, 위로는 남산 1호 터널과 직결하는 매우 중요한 다리이다. 덕분에 무려 12차선이나 되어, 2위인 마포 대교까지 제치고 서울에서 차선수가 가장 많은 다리이다.

동호 대교: 서울 지하철 3호선과 자동차가 공용하는 다리이다. 4차선이고 남북으로는 인근의 다리만치 지리적으로 중요한 경로가 없으며, 게다가 강변 북로에서는 이 다리로 진입하거나 이곳으로 나갈 수 없기 때문에 존재감이 다소 덜하다.

성수 대교: 한때 붕괴 사고로 인해 악명을 떨친 다리. 현재는 8차선이다.

(실드 공법으로 건설되었다는 분당선 하저 터널이 이 사이를 지날 예정.)

영동 대교: 국도 47호선의 일부이다. 박통 시절에 한창 개발 중이던 강남 지역의 발전을 촉진한 교량이라 함. 6차선 크기이다.

청담 대교: 자동차와 서울 지하철 7호선이 공용하는 6차선 복층 교량이다. 그 특징에 대해서 예전 글에서 잘 소개한 적이 있으므로 더 자세한 설명은 생략함. 영동 대교와 꽤 가까이 있다.

잠실 대교: 국도 3호선의 일부인 8차선 교량. 이 다리를 타고 남쪽으로 가면 잠실 역과 송파 대로가 나온다. 마포, 한남과 더불어 가장 오래 된 다리 축에 든다.

잠실 철교: 서울 지하철 2호선이 다니는 교량이다. 하지만 양 옆으로 자그맣게 자동차 도로도 생겨서 이름의 의미가 약간 므흣해졌다.

올림픽 대교: 동서울 터미널을 드나드는 버스가 즐겨 건너는 6차선짜리 다리이다. 사장교 형태이고 다리 중앙에 높이 88m짜리 주탑이 있는 걸로 유명하다. (참고로 대전 한빛탑의 높이는 93m!)

천호 대교: 국도 43호선의 일부인 6차선 교량이다. 이 다리는 한강의 선형상 지도 위상으로 볼 때 수직(남북)이 아니라 수평(동서)에 가깝다. 천호 대로로부터 이어지고 동쪽으로 계속 가면 하남시가 나온다. 서울 지하철 5호선이 지나는 하저 터널이 정확히 아래에 있다. (광나루-천호. 마포-여의나루 구간은 마포 대교와 정확히 평행이 아니다.)
인근에는 광진교라는 미니 다리도 있다.

강동 대교: 서울 외곽 순환 고속도로가 지나는 다리.
미사 대교: 서울-춘천 고속도로가 지나는 다리.

Posted by 사무엘

컴퓨터의 모니터 화면을 픽셀 단위로 있는 그대로 저장하는 기능의 필요성은 과거 도스 시절부터 쭉 있어 왔다. 프로그램의 기능을 설명할 때, 특정 인증샷을 남길 때 등 여러 모로 유용하고 필요한 기능이기 때문이다.

오늘날에도 키보드에는 print screen이라는 키가 있다. 옛날에는 사용자가 이걸 누르면 하드웨어 차원에서 인터럽트가 발생하여, 텍스트 모드 화면에 찍혀 있던 글자가 프린터 포트(LPT1)로 진짜로 갔다. 프린터가 안 켜진 상태에서 이걸 누르면 컴퓨터가 멎었다. pause를 누르면 컴퓨터의 전체 작동이 일시 중단되고 ctrl+alt+del을 누르면 컴퓨터가 곧바로 재부팅되던 시절의 얘기이다.

하지만 이런 기본 기능은 너무 원시적이고 빈약하며, 그래픽 모드에 대한 대비책이 전무했기 때문에 화면 캡처는 결국 소프트웨어 계층이 담당하는 영역으로 넘어가게 되었다.

도스 시절의 화면 캡처 프로그램은 응당 램 상주(TSR) 프로그램의 형태였다. 아래아한글의 경우, 1.5x에서는 hcopy.exe라는 자그마한 유틸리티가 있었는데, 텍스트 모드 아니면 무려 허큘리스 단색 그래픽 모드만 지원했었지 싶다. 2.0과 그 이후부터는 별도의 유틸리티는 없어졌고 대신 아래아한글 프로그램에 자체적으로 화면 캡처 기능이 들어갔다. 언제라도 Alt+키패드 +키를 누르면 지금 화면을 PCX 그림 파일로 저장할 수 있었다.

한동안 본인이 사용했던 프로그램은 수채화라는 그래픽 프로그램에 내장되어 있던 snap이라는 덜 유명한 국산 프로그램, 그리고 Screen Thief라는 비교적 유명한 외국산 프로그램이다 ST는 아주 특이하게도 텍스트 모드도 색깔과 바이오스 글꼴이 모두 가미된 그래픽 원형 그대로 캡처해 주는 끝내주는 기능이 있었다. 생성되는 그림 파일 확장자도 GIF로, 비록 오늘날의 JPG에 비할 바는 아니지만 PCX보다야 더 무겁고 압축률이 뛰어난 포맷이었다.

도스에서 윈도우로 넘어가면서 화면 캡처는 굉장히 쉬워졌다. 여러 프로그램들을 동시에 띄우고 드나들 수 있는 멀티태스킹 환경일 뿐만 아니라, 언제든지 Print Screen만 누르면 화면 전체 또는 활성화된 창이 비트맵 형태로 클립보드에 저장되기 때문이다. 그래픽 하드웨어가 워낙 겹겹이 잘 추상화되다 보니, 화면 캡처란 이제 기술적으로 대상 윈도우의 DC 내용을 내 DC로 Bitblt하는 것이 전부이다.

너무 간단해졌다. 옛날에는 하드웨어 가속을 받는 동영상이나 일부 게임 화면은 이 방법으로 캡처할 수 없어서 별도의 특수한 프로그램을 써야만 했지만 이것도 비스타부터는 옛말이 됐다.

기본적인 기능은 운영체제가 자동으로 제공해 주니, 캡처 유틸리티들은 편의성을 더욱 강화하고, 일정 수준 이상의 그래픽 편집과 보정 기능도 갖추는 방향으로 발전하기 시작했다. 여러 윈도우의 동시 캡처, 자동 스크롤 캡처, 그리고 현재 화면보다 더 큰 해상도를 가장한 화면 캡처, 멀티모니터 지원, 텍스트 정보 추출 등, 화면 캡처라는 주제 하나만으로도 기발한 아이디어가 적지 않다. 편집 쪽도 Blur 같은 전문적인 사진 보정보다는, 색깔 추출, 디더링 같은 산술적인 변환 기능이 더 필요할 것이다.

본인은 옛날에는 동영상 화면의 캡처를 위해 HyperSnap이라는 프로그램을 잠깐 썼었는데 나름 굉장히 잘 만든 프로그램이었다. 하지만 지금은 그거 없이도 동영상 화면 캡처가 얼마든지 가능해졌기 때문에 안 쓴다. 그냥 옛날 Paint Shop Pro가 같이 제공하는 화면 캡처 기능을 유용히 쓰는 중이다.
오늘날은 국산 프로그램으로는 ‘오픈캡처’가 이 분야에서 아주 유명하다. 완전 무료 프로그램이다가 최근에는 기업 대상으로 유료화되었다.

윈도우 환경이라도 게임들 역시 전통적으로 화면 캡처 기능을 제공해 왔다. 옛날에 256색 게임들은 운영체제의 print screen 키로는 비록 비트맵 데이터는 화면 캡처가 되지만 팔레트 정보가 저장되지 않아 화면이 이상한 색으로 저장되곤 했기 때문이다. 한편, 요즘은 컴퓨터의 성능이 놀랍도록 좋아지고, UCC 만들기가 보편화하면서 아예 게임 화면 동영상을 찍는 기능도 쓰이고 있다. 외산으로는 프랩스(Fraps), 국산으로는 반디캠 같은 프로그램이 좋은 예이다.

화면도 나오고 동영상도 나왔으니, 글을 맺기 전에 소리 캡처에 대해서도 잠깐만 언급하겠다. XP 이하 시절에는 내 컴퓨터에서 나오는 소리를 도로 녹음하는 것이 비교적 쉽게 가능했는데 비스타부터는 그게 방법이 꽤 까다로워지고, 하드웨어 환경에 따라서는 아예 불가능한 컴퓨터까지 생겼다고 본인은 알고 있다. 비스타 때부터 비디오와 오디오의 하드웨어 계층이 바뀌었다.

개인적으로, 키매크로 유틸리티와 저런 부류의 캡처 유틸리티는 운영체제가 기본 제공할 만한 보조 프로그램의 아주 좋은 예라고 생각한다. 컴퓨터의 활용 능력 및 생산성하고 직접적인 관계가 있는 도구이기 때문이다.

Posted by 사무엘

철도와 일반 도로가 평면 교차하는 곳에는 잘 알다시피 건널목이라는 게 설치된다.

철도 차량은 어지간한 육상 자동차하고는 잽도 안 되는 어마어마한 질량을 갖고 있고 이를 바탕으로 억소리나는 운동 에너지를 자랑한다. 그렇잖아도 이렇게 무거운 데다 쇠로 된 바퀴로 쇠로 된 길을 달리기 때문에 철도 차량은 가감속이 무진장 더디다. 새마을호가 비상 제동 수준의 강한 제동을 걸어야 시속 100km 상태에서 무려 600m를 더 진행한 후에야 완전히 멈춰 설 수 있을 정도라고 알려져 있다.

이것이 무엇을 의미할까? 열차가 한번 달리기 시작하면 주변의 다른 사람이나 자동차들이 알아서 피해야 한다. 열차는 장애물 앞에서 딱 멈춰 설 수가 없다.
그러니 건널목에서는 열차의 통과 우선순위가 언제나 갑이다. 사람과 자동차들이 기다리지, 열차가 잠시 멈췄다가 사람과 자동차들을 피해 다니는 일은 없다.

건널목에서 충돌 사고가 났다 하면 육중한 열차는 하나도 탈이 없지만 자동차는 형체를 알아볼 수 없는 개발살이 난 채로 수십~100수십 미터를 질질 끌려가며, 사람이 치이기라도 하면 즉시 끔살 당한다. 철도 차량 객차 내부에 안전벨트가 없는 이유를 알 수 있을 것이다. 자동차와는 달리, 사람이 밖으로 튕겨져 나갈 정도로 급정거를 할 일이 없기 때문.

물론, 속도를 주체하질 못한다는 특성이 장점으로만 작용하는 건 아닌지라, 장애물과 충돌한 열차가 그래도 뒷부분이 도무지 멈춰 서질 못한 나머지 탈선해서 앞 객차를 타넘고 오르는 일이라도 생기면, 철도로도 대형 인명 참사가 얼마든지 생길 수 있다.

건널목에도 세 가지 모델이 있어서 비교적 통행량이 많은 건널목은 표지판+노란 색의 차단기+경보기 3콤보가 모두 갖춰져 있지만, 잉여스러운 장소에는 몇몇 요소가 생략된 건널목도 있다. 자기 폐색 구간에 열차가 바퀴가 닿은 게 감지되면 띵동~ 띵동~ 소리와 함께 차단기가 내려온다. 그리고 열차가 다 지나가면 다시 차단기는 올라간다.

우리나라의 교통 관련법에 의하면 철길과 도로의 교차는 45도보다 작은 각도로 하지는 않게 되어 있다. 대부분이 90도 수직이지만, 그래도 시골 도로를 보면 예각 교차도 그럭저럭 볼 수 있다. 건널목 사고를 줄이기 위해 요즘은 많은 건널목이 입체화되었으며, 특히 오늘날 새로 건설하는 철도는 건널목을 전혀에 가깝게 만들지 않는다고 생각하면 된다.

그럼에도 불구하고 경원선은 서빙고 역 일대와 회기-외대앞 역 사이에 일반열차도 아닌 전동차가 수시로 다니는 선로에 건널목이 있으니 안타까운 현실이다. 어서 입체화가 되어야 할 것이다.

본인은 어렸을 때 주변에 중앙선 철길이 있는 지역에서 자랐다. 철길이 지역을 심리적으로 양분하는 효과는 무척 컸다. 옛날에 나라 분위기가 더 살벌하던 시절에는 ‘철길로 다니지 맙시다’와 더불어, 레일 위에다 돌을 올려 놓아서 열차 운행을 고의로 방해하거나 열차를 전복시키는 자는 무슨무슨 형에 처해진다는 경고문도 꼭 붙어 있었다.

우리나라에 발생했던 상당히 참혹한 건널목 사고로 철덕이라면 1970년의 장항선 모산 수학여행 참사를 기억할 것이다. 그건 아주 극단적인 예이다.
2002년 5월 1일에는 잘 알다시피 전라선 상행 새마을호에서 세계적으로 유례를 찾기 힘든 괴이한 3콤보 건널목 인명 사고가 난 적이 있다.

오늘날에도 전국에서 건널목 사고로 목숨을 잃는 사람이 연간 10~20여 명은 있는 모양이다. 이것도 물론 2, 30여 년 전의 100수십여 명에 비해서는 매우 크게 감소한 것이다.

비교적 최근인 2011년 7월 30일에는 좀 어처구니없는 사고가 났다. KTX가 건널목에서 제네시스 승용차와 충돌하여 여성 운전자가 목숨을 잃었는데.. 아니, 고속선에서 시속 300km로 질주하고 있을 KTX가 호남선 구간도 아닌 무슨 연기군에서 웬 건널목 사고에 연루되는 게 가능한지 궁금할 것이다. 이 KTX는 대전-서울 구간을 기존선으로 달리는 녀석이었다.

건널목을 건너던 중에 차가 시동 꺼져 뻗은 것도 아니고, 자세한 경위를 들어 보니 정말 “아 씨바 할 말을 잃었습니다” 급이다. 차가 건널목을 통과하고 있던 도중에 차단기가 내려와 버렸다.;; 그래서 그 차는 철길에 갇혀 고립됐다. 타이밍 한번 정말 더럽다. ㄷㄷㄷㄷ

경부선은 복선이기 때문에 철길의 폭과 양쪽 건널목 사이의 간격이 단선보다 훨씬 더 크다. 그래서 이런 케이스가 가능했다. 복선 건널목이 단선 건널목보다 더욱 위험하다는 건 두말 할 나위가 없다.

마치 고속도로 톨게이트에서 하이패스가 인식되지 않아서 차단봉이 내려오더라도 당황하지 말고 일단 통과는 해야 하듯, 이때도 차 범퍼로 차단기의 철길 안쪽면을 툭 치기만 하면 차단기는 다시 올라가게 돼 있다. 차단기는 위험을 알려서 사람을 살리려고 만들어진 장치이지 사람을 잡으려고 만들어진 게 아니다.

그랬는데, 지금은 이미 고인이 된 그 운전자는 당황하여 그대로 차를 세운 채 철길 위에서 아무 조치도 취하지 않았고, 하다못해 밖으로 탈출하지도 않았다. 마치 자신이 철길 밖의 건널목 앞에서 기다리고 있는 것처럼 그냥 가만히 있었다. 열차가 알아서 정지해 줄 거라고 생각했는가 보다.

충돌 직전 몇 초 동안 KTX 열차가 비상 제동을 걸면서 필사적으로 경적을 빵빵 울릴 때 그분, 무슨 생각을 했을까? 그 뒤 시밤쾅! 그 고급 승용차는 박살 난 채 전복되어 나뒹굴었다. 이건 뭐 스크린도어에 끼인 채로 열차가 출발해 버려서 사람이 죽은 것 같은 그런 기괴한 사고이다만, 더 근본적으로는 고인이 철도에 대해서 너무 무지하여 벌어진 참극이 아닐 수 없다.

우리나라 철도 당국은 사고의 원흉인 평면교차와 건널목을 없애려고 많은 노력을 기울이고 있다. 신호 받으면서 수시로 가다 서다 하기가 어려운 교통수단일수록 자기만의 독립된 길에서 쭉 가기만 하게 해 주는 게 당연히 유리하니까 말이다.

다만 철도가 너무 입체화만 되면 사람의 발이 철길과 직접 교감을 할 기회가 없어지니, 발을 어느 정도 뻗어야 표준궤 궤간인지 감을 익히기가 어렵다. 난 고향에 가면 철길 건널목에 도보로 들를 일이 있을 때 그거 연습을 하곤 한다.

.
.

그리고 또 여담 하나.

<다리>(Bridge)라고 2003년에 체코에서 만들어진 단편 독립영화가 있다. 원제목은 Most인데, 이건 영어의 형용사/부사를 뜻하는 most가 아니라, 자기네 체코 어로 bridge라는 뜻이다. 스토리는 대략 이렇다.

이 영화는 기독교적인 메시지를 의도하고 만들어졌다. 그 다리 관리인이 자기 아들을 희생시켜서 수백 명의 승객들을 살렸듯이 인간을 지으신 하나님도 자신의 아들을 십자가에 죽게 하셔서... 이하 생략이다.

영화 제작자의 의도는 알겠으나, 설정이 좀 억지스러운 면모가 있긴 하다. 오늘날 철도에 구비되어 있는 기본 중의 기본 시스템인 ATS 하나만 있어도 적색 신호를 무시하고 가는 열차는 얄짤없이 자동으로 멈춰 서게 된다. 하지만 저 때는 아예 증기 기관차가 다니던 시절이니 기관사의 시력과 재량이 철도 안전에 직접적인 영향을 끼칠 수도 있었겠다.

요즘은 그런 원시적인 후진국형 철도 사고는 근무 기강이 빠질 대로 다 빠진 막장이거나, 진짜 철도 인프라가 100년 전이나 지금이나 변한 게 없는 곳에서나 난다.
아무튼 철도는 디테일을 알면 알수록 더욱 재미있다.

Posted by 사무엘

프로그래밍을 하다 보면, 어떤 컨테이너 자료구조의 내부에 있는 모든 원소들을 순회하면서 각 원소에 대해 뭔가 동일한 처리를 하고 싶은 때가 빈번히 발생한다.
그 절차를 추상화하기 위해 C++ 라이브러리에는 algorithm이라는 헤더에 for_each라는 템플릿 함수가 있다. 다음은 이 함수의 로직을 나타낸 C++ 코드이다. 딱히 로직이라 할 것도 없이 아주 직관적이고 간단하다.

template<typename T, typename F>
void For_Each_Counterfeit(T a, T b, F& c)
{
    for(T i=a; i!=b; ++i) c(*i);
}

C++은 템플릿과 연산자 오버로딩을 통해 자료구조에 대한 상당 수준의 추상화를 달성했다.
iterator에 해당하는 a와 b는 그렇다 치더라도, 여기서 핵심은 c이다.
F가 무엇인지는 모르겠지만, 어쨌든 c는 함수 호출 연산자 ()를 적용할 수가 있는 대상이어야 한다.
그럼 무엇이 가능할까? 여러 후보들이 있다.

일단 C언어라면 함수 포인터가 떠오를 것이다. 함수 포인터는 코드를 추상화하는 데 지금까지 고전적으로 쓰여 온 기법이다.

void foo(char p);

char t[]="Hello, world!";
For_Each_Counterfeit(t, t+strlen(t), foo);

C++에서는 클래스가 존재하는 덕분에 더 다양한 카드가 생겼다. 클래스가 자체적으로 함수 호출을 흉내 내는 연산자를 갖출 수 있기 때문이다.

class MyObject {
public:
    void operator()(char x);
};

For_Each_Counterfeit(t, t+strlen(t), MyObject());

그리고 더욱 기괴한 경우이지만, 클래스 자신이 함수의 포인터로 형변환이 가능해도 된다.

class MyObject {
public:
    typedef void (*FUNC)(char);
    operator FUNC();
};

For_Each_Counterfeit(t, t+strlen(t), MyObject());

C++ 라이브러리에는 functor 등 다양한 개념들이 존재하지만, 그 밑바닥은 결국은 C++ 언어의 이런 특성들을 사용해서 구현되어 있다.
여기서 재미있는 점이 있다. 다른 자료형과는 달리 함수 포인터로 형변환하는 연산자 오버로드 함수는, 자신이 가리키는 함수의 prototype을 typedef로 미리 만들어 놓고 반드시 typedef된 명칭으로 선언되어야 한다는 제약이 있다. 이것은 C++ 표준에도 공식적으로 명시되어 있는 제약이라 한다.

이런 어정쩡한 제약이 존재하는 이유는 아마도 함수 선언문에다가 다른 함수를 선언하는 문법까지 덧붙이려다 보니, 토큰의 나열이 너무 지저분해지고 컴파일러를 만들기도 힘들어서인 것 같다. 이 부분에서는 아마 C++ 위원회에서도 꽤 고민을 하지 않았을까.
안 그랬으면 형변환 연산자 함수의 prototype은 아래와 비슷한 괴상한 모양이 됐을 것이다. 실제로 이 함수의 full name을 undecorate한 결과는 이것처럼 나온다.

    operator void (*)(char)();

비주얼 C++에서는 함수를 저렇게 선언하면 그냥 * 부분에서 '문법 에러'라는 불친절한 말만 반복할 뿐이지만, xcode에 기본 내장되어 있는 최신형 llvm 컴파일러는 놀랍게도 나의 의도를 간파하더이다. “함수 포인터로 형변환하려면 반드시 typedef를 써야 합니다”라는 권고를 딱 하는 걸 보고 적지 않게 놀랐다. 이런 차이도 맥북을 안 쓰고 오로지 비주얼 C++ 안에서만 틀어박혀 지냈다면 경험하기 쉽지 않았을 것이다. 우왕~

() 연산자 오버로딩은 this 포인터가 존재하는 C++ 클래스 멤버 함수이며 static 형태가 있을 수 없다.
그러나 함수 포인터로의 형변환 연산자 오버로딩은 this가 없으며 C 스타일의 static 함수와 같은 위상이라는 차이가 존재한다.
두 오버로딩이 모두 존재하면 어떻게 될까? 혹시 모호성 오류라도 나는 걸까?

그런 개체에 함수 호출 ()가 적용되는 경우, () 연산자가 먼저 선택되며, 그게 없을 때에 한해서 함수 포인터 형변환이 차선책으로 선택된다. 모호성 오류가 나지는 않는다.
포인터 형변환 연산자와 [] 연산자가 같이 있을 때 개체에 배열 첨자 참조 []가 적용되는 경우, 역시 [] 가 먼저 선택되고 그게 없을 때 포인터 형변환이 차선으로 선택되는 것과 비슷한 맥락이라 볼 수 있다.

그래서 클래스와 연산자 오버로딩 덕분에 저런 문법이 가능해졌는데, C++11에서는 그걸로도 모자라 또 새로운 문법이 추가되었다. 이른바 람다 함수.

For_Each_Counterfeit(t, t+strlen(t), [](char x) { /* TODO: add your code here */ } );

람다 함수는 코드가 들어가야 할 곳에 함수나 클래스의 작명 따위를 신경쓰지 않고 코드 자체만을 직관적으로 곧장 집어넣기 위해 고안되었다. 세상에 C++에서 OCaml 같은 데서나 볼 수 있을 법한 개념이 들어가는 날이 오다니, 신기하지 않은가?

덕분에 C++은 C언어 같은 저수준 하드웨어 지향성에다가 성능과 이념을 적당히 절충한 수준의 객체지향을 가미했고, 90년대 중반에는 템플릿 메타프로그래밍 개념을 집어넣더니, 이제는 함수형 언어의 개념까지 맛보기로 도입한 가히 멀티 패러다임 짬뽕 언어가 되었다.

함수를 값처럼 표현하기 위해서 lambda 같은 예약어가 별도로 추가된 게 아니다. C/C++은 태생상 예약어를 함부로 추가하는 걸 별로 안 좋아하는 언어이다. (그 대신 문법에 혼동이 생기지 않는 한도 내에서 기호 짬뽕을 좋아하며 그래서 사람이나 컴파일러나 코드를 파싱하는 난이도도 덩달아 상승-_-) 보아하니 타입을 선언하는 부분에서는 배열 첨자가 먼저 오는 일이 결코 없기 때문에 []를 람다 함수 선언부로 사용했다.

람다 함수는 다른 변수에 대입되어서 두고두고 재활용이 가능하다. 그래서 C/C++에서는 전통적으로 가능하지 않은 걸로 여겨지는 함수 내부에서의 함수 중첩 선언을 이걸로 대체할 수 있다.

어떤 함수 안에서 특정 코드가 반복적으로 쓰이긴 하지만 별도의 함수로 떼어내기는 싫을 때가 있다. 굳이 함수 호출 오버헤드 때문이 아니더라도, 해당 코드가 그 함수 내부의 지역변수를 많이 쓰기 때문에 그걸 일일이 함수의 매개변수로 떼어내기가 귀찮아서 그런 것일 수도 있다.
이때 흔히 사용되는 방법은 그냥 #define 매크로 함수밖에 없었는데 이때도 람다 함수가 더 깔끔하고 좋은 해결책이 될 수 있다. 람다 함수는 선언할 때 캡처라 하여 주변의 다른 변수들을 참조하는 메커니즘도 언어 차원에서 제공하기 때문이다.

그렇다면 의문이 생긴다.
람다 함수는 그럼 완전히 새로운 type인가?
기존 C/C++에 존재하는 함수 포인터와는 어떤 관계일까?
정답부터 말하자면 이렇다. 람다 함수는 비록 어쩌다 보니 () 연산을 받아 주고 함수 포인터가 하는 일과 비슷한 일을 하게 됐지만, 활용 형태는 함수 포인터하고 아무 관련이 없으며 그보다 더 상위 계층의 개념이다.

템플릿과 연동해서 쓰인다는 점에서 알 수 있듯, 람다 함수는 함수 포인터와는 달리 calling convension (_stdcall, _cdecl, _pascal 나부랭이 기억하시는가?)이고 리턴값이 나발이고간에 아무 상관이 없다. 그저 코드상에서 함수를 값처럼 다루는 걸 돕기 위해 존재하는 추상적인 개념일 뿐이다. 뭔가 새로운 type이 아니기 때문에 람다 함수를 변수에다 지정할 때는 auto만을 쓸 수 있다. 즉, 다른 자료형이 아닌 람다에 대해서는 auto가 선택이 아니라 필수라는 뜻이다.

auto square=[](int x) { return x*x; };
int n = square(9); //81

square는 템플릿 같은 함수가 아니다. 이 함수의 리턴값은 x*x로부터 자동으로 int라고 유추되었을 뿐이다. [](int x) -> int 라고 명시적으로 리턴 타입을 지정해 줄 수도 있다. 구조체 포인터의 멤버 참조 연산자이던 -> 가 여기서 또 화려하게 변신을 한 셈임. 우와!

또한, sizeof(square)을 한다고 해서 포인터의 크기가 나오는 게 아니다. 사실, 람다 함수에다가 sizeof를 하는 건 void에다가 sizeof를 하는 것만큼이나 에러가 나와야 정상이 아닌가 싶다. 그런 개념하고는 아무 관계가 없기 때문이다.

람다는 함수 포인터가 아니기 때문에, square에다가 자신과 프로토타입이 같은 다른 람다 함수를 대입할 수 있는 건 아니다. 함수 포인터의 역할과 개념을 대체할 뿐, 그 직접적인 디테일한 기능을 대체하지는 못한다. 그렇기 때문에 콜백 함수를 받는 문맥에서

qsort(n, arrsize, sizeof(int), [](const void *a, const void *b) { return *((int*)a) - *((int*)b); } );

구닥다리 C 함수에다가 최신 C++11 문법이라니, 내가 생각해도 정말 변태 같은 극단적인 예이다만,
이런 식으로 람다 함수를 집어넣을 수도 없다.

요컨대 람다 함수는 코드의 추상화에 도움을 주고 종전의 함수 포인터 내지 #define, 콜백 함수 등의 역할을 대체할 수 있는 획기적인 개념이다. C++ 철학대로 디자인된 여타 C++ 라이브러리와 함께 사용하면 굉장한 활용 가능성이 있다. 그러나 이것은 함수 포인터에 대한 syntatic sugar는 절대 아니라는 걸 유의하면 되겠다.

Posted by 사무엘

※ 나는 왜 예수님을 믿는가 -- 크게 작용한 요인들

• 세상 그 어느 종교도 창조주가 피조물에게 죽임을 당했다고 가르치지 않으며, 교주가 부활했다고 가르치지 않고, 또 이 정도로 역사적으로 방대한 증거와 증인들을 갖추고 있지 않으므로
• 인간이 자기 노력과 근성으로 신을 찾아가는 게 아니라, 신이 먼저 인간을 찾아주고 은혜와 사랑을 베풀었다고 가르치므로
• 없어졌으면 애시당초 진작에 씨가 말라 버렸을 정도로 황당하고 믿어지지 않는 교리를 갖고 있는데, 아직까지 당당히 존속해 있다는 것만으로도 최소한 무시할 수는 없고 한번 살펴볼 가치가 있다고 여겨졌으므로
• 이 정도로 무수히 많은 이단들이 압도적으로 집착할 정도이면, 웬지 이 바닥에 분명 진리가 있을 거라는 예감이 들어서
• 성경은 그 논조와 내용을 볼 때 인간이 쓸 만한 책이 절대 아니라는 확신이 들어서 (가령, 정치적으로 치우침이 없음. 인간 자신에게 절대 이롭지 않은 내용이 지나치게 장황하게-_- 많이 들어있음)
• 그래도 몇몇 증명 불가능하고 이해가 안 되는 사항들만 일단 믿고 나면, 이를 바탕으로 전개되는 각종 교리와 윤리관은 아주 논리적이고 이성적이고 합리적이고 인간에게 건전하다는 게 너무 분명하게 확 느껴져서
• 죄 문제라는 인간에 대한 상태 진단과, 그 해결책에 너무나 공감이 가서. 최소한 줘도 못 먹는 사람이 되지는 말아야지?
• 차라리 예수 그리스도라는 절대적인 의의 기준이 온갖 상대주의· 다원주의보다는 훨씬 더 명확하고 깔끔하고 건전하고 뒤끝이 없다는 생각이 들어서 (다 사회 구조 탓이다, 그 상황에서는 누구나 그럴 수밖에 없다 등등)

그래서 내가 지금 어떻게 되었는지에 대해서는 이 글을 참고할 것.

※ 나는 왜 예수님을 믿는가 -- 조금 작용한 요인들

• 개독안티들의 무례하고 표독스러운 말투에, 사실 여부를 떠나 괜히 반발심과 환멸을 느껴서 (다른 건 몰라도 저놈들 말은 절대로 듣지 말아야겠다는 식)
• 역사적으로 기독교의 과오라고 알려진 것들이 상당수가 기독교와는 아무 관계가 없고, 사실은 크리스천들도 오히려 피해자라는 걸 알게 되어서
• 파스칼의 팡세에 나오는 수준의 간단한 변증론. 가령,
  “지금 예수 믿었는데 나중에 알고 보니 사실 없는 게, 지금 안 믿었는데 진짜로 지옥이 있어서 낭패 보는 것보다 더 안전하고 리스크가 적다.”
  “신이 없다고 단정짓기엔 인간의 지식은 너무 좁고 빈약하다” 같은 식.
• 내세와 심판이 있을 거라는 양심의 자극. 죽음에 대한 두려움
• 성경이 과학적으로도 옳다는 걸 뒷받침하는 몇몇 자료들
• 이 정도 교리면, 정말 만에 하나 성경의 내용이 다 거짓이고 허구이고 설령 근거 없이 맹목적으로 믿는다 해도, 크게 손해 볼 게 없다고 생각되어서. 성경은 최소한 날 골탕먹이려고가 아니라 날 '위해서' 기록된 책이라는 느낌이 와서

※ 내 신앙관에 영향을 거의 끼치지 않은 것들

• 좋든  싫든, 주변 교회 사람들의 행동과 평판
• 잘한 것이든 못한 것이든, 해당 종교계에서 유명한 사람들의 언행 (그 사람들이랑 나랑 도대체 무슨 상관이냐? 나는 베르테르 효과 같은 것과는 담을 쌓고 지냄)
• 세상 불신자들로부터의 평판, 매스미디어에 묘사된 이미지
• 육신을 들뜨게 하거나 흥분시키거나 만족시키는 종교심. 나는 그런 부류의 종교심은 이미 철도교로 다 충족하고 있기 때문에 그런 종교에다 내 영원을 걸지는 않는다.
• 기복신앙

하지만 현실에서는 저런 것들을 보고 교회를 나가거나 종교를 선택하는 사람들이 무진장 많다. ㅜㅜ

※ 지금은 발현되지 않고 있지만, 언젠가 깊은 시험에 들고 신앙 면역 체계가 무너졌을 때 큰 위험이 될 수 있는 잠재적인 암적 요소들

• 성경에서 여전히 잘 이해되지 않고 해결이 안 된 의문이나 논리적 모순(처럼 보이는 것들) 몇 군데. 목사님에게 여쭈거나 주석서를 봐도 알 수 없는 것들
• 성경이 밥 먹여 주냐... 같은 부류의 유치하지만, 좁은 길을 가는 성도에게 결코 무시할 수 없는 시험. 현실의 염려 (눅 8:14)
• 신앙생활이 매너리즘으로 변질돼 가는 것
• 하나님의 뜻을 도무지 알 수 없을 때. 이것도 하지 말고 저것도 안 하면 도대체 뭘 하라는 건지 알 수 없는 상황이 들이닥치는 것

Posted by 사무엘