기독교 교리에 따르면,
제아무리 흉악범이라도 예수 믿고 구원받으면 하늘로 가며,
제아무리 착한 사람, 불쌍한 사람, 의로운 사람, 법조인, 경찰, 검찰뿐만이 아니라 심지어 흉악범에게 살해당한 피해자라 해도 예수 안 믿고 자기 죄 가운데 죽었다면 지옥에 간다.

그렇다. 그게 사실이다.
그래서 착한 일 많이 하면 구원받는다고 믿는 여타 종교 신자들이나, 자기는 지금까지 남보다 충분히 의롭게 살았다고 생각하는 불신자들은 세상에 그런 법이 어디 있냐며 항변한다. 그리고 복음을 받아들이기를 거부한다. 뭐, 지금 내가 그것에 대한 시비를 가리고 싶지는 않다.

그런데 이거 아는가?
흉악범이 구원받으면 구원받은 흉악범이고, 사형수가 예수 믿으면 구원받은 사형수가 된다.
성경의 법칙대로라면 그들은 하늘로 가더라도 교수형은 당하고 간다. 이 땅에서 법이 규정해 놓은 죄값은 치르고 간다!

사형 제도는 지극히 성경적이다.
하나님은 인간에게 결혼 제도를 제정한 것만큼이나 사형 제도도 만드셨고,
육식을 허락하신 것만큼이나 세상 정부가 사람을 사형에 처하는 걸 허락하셨다.
(창 9:6)
성경의 지론은 “ ‘살인하지 말지니라’를 어기는 자를 반드시 죽일지니라.”이다. 아멘.

여기서 살인이란 흉계를 품고(주로 자기 이익을 위해) 남을 고의로 죽이는 것을 말한다. 요즘 말이 많은 음주운전으로 인한 사망 사고는 성경으로 치면 출 21:29와 비슷한 맥락의 고의적인 살인으로 간주하여 처벌하는 것이 바람직하다고 여겨진다.

생명이 왔다 갔다 할 수 있는 신성한 영역을 더럽히는 성 범죄도 마찬가지이다. 속도위반 결혼으로라도 수습을 할 수 있는 수준을 넘어섰다면 성경에 따르면 한 치의 자비심 없이, 속죄 헌물도 안 통하고 무조건 사형이다.

다만, 고의성이 없는 과실치사는 성격이 다르며, 비록 처벌이 없는 것은 아니나 사형 정도까지는 아니다. 정당방위도 응당 인정하며, 면책의 범위가 오늘날 근대 국가의 법보다 관대한 편이다(출 22:2).

그리고 국가와 민족이라는 조직을 인정하고 공권력도 인정하는 성경의 특성상, 군인이 지휘관의 명령대로 전쟁터에서 적군을 죽이는 것 역시 그런 살인의 범주에 들지 않는다. (병역 거부는 잘못된 행동이다)

공무를 집행하는 경찰이 폭도들에게 발포하는 것이나, 사형 집행관이 교수대 스위치를 누르는 것도 성경적으로 하나도 잘못된 것이 없으며, 그런 공무원은 전혀 죄책감을 느낄 필요 없다. 오히려 그들은 목사가 교회에서 하나님의 일을 하는 것만큼이나 세상에서 하나님의 사역을 수행하고 있다! (롬 13:4)

전국을 떠들썩하게 하는 흉악 범죄가 터질 때마다 국민들은 분노한다. 인터넷 뉴스 기사에는 피의자를 저주하면서 저런 놈은 이렇게 각을 떠서 죽여야 한다는 식으로 온갖 폭력적인 댓글이 달린다. 그리고 너무 솜방망이(?) 처벌을 내리는 정치인과 법조인들을 욕하면서, 신은 저런 놈 안 잡아 죽이고 뭐 하냐는 식의 댓글도 올라온다.

그 마음을 나도 이해하며 어느 정도는 공감도 한다. 비록 이런 네티즌들의 마음 상태도 건전하다고 보기는 어려우며, 겉으로 표출만 안 되었을 뿐이지 살인자 본성이 남아 있긴 하지만 말이다.

이럴 때일수록 국가가 사형(死刑)이라는 필요악을 공의롭게 잘 집행해 줘야, 시민들이 분을 품고 보복 살인 내지 린치(私刑)를 할 생각을 안 하게 된다. 다시 말해 정부가 사형 집행을 안 하면 다른 시민들이 실족하여 악한 마음에 빠지기 쉽다는 뜻이다. 하나님은 사람이, 그것도 불신자들이 하나님 자신보다도 더 자비로울 거라고는 바라지도 않으며 기대도 안 하신다!

피해자 유족들이 참석한 가운데 사형 집행 장면이 국영 방송으로 생방송 중계된다. 김 길태, 강 호순, 오 원춘 같은 주인공이 교수대에 오른다. TV에서는 근엄한 분위기 가운데에 이들이 저지른 범죄를 다시 보여주고, 피해자 유족을 인터뷰하고 피의자의 마지막 유언을 공개적으로 받는다. 필요하다면 죄수들을 담당한 종교인 성직자의 인터뷰도 한다.
그 뒤 공개적으로 교수대가 작동하고, 잠시 후 법의관이 사형수가 완전히 죽은 걸 확인한다. 이 과정을 온 국민이 지켜보고, 사형 집행 장면이 트위터나 페이스북 같은 SNS로 나돈다.

너무 과격한 상상인가?
난 이렇게까지 하는데 사람들이 죄와 벌과 죽음에 대해서 가볍게 여기게 될지, 모방 범죄가 또 생기고 사람들이 감히 사람을 죽일 생각을 하게 될지에 대해서는 굉장히 회의적이다. 왜 이렇게 시행을 안 하는지 궁금하다. 제아무리 인간말종 흉악범이라 해도, 무슨 독립 운동가의 심정으로 사람을 죽인 게 아닌 이상, 자기 목숨 아까운 줄은 알고 죽음이 두려운 줄은 안다. 그래서 사형 당하기 직전에 어쩌면 복음을 받아들이고 구원받는 경우도 생긴다.

구약 율법 핑계를 대면서 사형 제도를 반대하는 의견이 아주 많다. 구약 율법 중에는 음식 규정이나 안식일 같은 것처럼 경륜의 차이로 인해 오늘날 전혀 무의미하고 적용되지 않는 제도나 규율도 있긴 하다. 그러나 인간에 대한 보편적인 윤리는 오늘날까지도 그대로 유효하고 최소한 그 의도를 되살려 시행했을 때 나쁠 게 없는 게 거의 대부분이다. 가령, 신약 시대라고 해서 짐승과 마음대로 수간해도 괜찮은 건 아니지 않은가? (출 22:19; 레 20:15)

또한 사형 제도는 구약 율법에만 얽매인 것이 아니라 그 전부터 존재했으며, 오히려 성경 전체가 인간의 죄와 벌과 구원 계획에 대해 논하면서 사형 제도를 두 말할 나위 없이 당연히 인정하는 뉘앙스에서 기록되었다고 보는 게 타당하다. (가령, 롬 1:32) 그래서 오죽했으면 바울조차 행 25:11에서 자기가 죽을 죄를 지었으면 기꺼이 사형 당하겠다고 말한 것이다.

우리나라에는 자기 아들을 죽인 흉악범을 용서한 손 양원 목사 같은 유명한 사례가 있다. 그런 사람이 나오기 위해서라도 사형 제도가 있어야 한다. 법대로라면 죽어야 하는데 용서를 하고 탄원을 해서 목숨을 건졌으니 그게 사랑을 실천한 것이다. 당신도 성령 충만한 크리스천이라면, 나라의 법은 공의롭게 요구하고 나서, 자기가 그런 일을 당했을 때에나 원수에게 그런 사랑을 개인적으로 실천해 보아라. 알겠는가?

그런데 이제는 아예 나라의 법이 흉악 범죄자에게 정당한 처벌을 내리지 않으니 오늘날 시국은 전 8:11처럼 되어 가고, 피해자 유족들은 가슴에 피멍이 든다.
오늘날은 정말로 가해자 인권만 있지 피해자 인권은 없다. 그냥 운이 나빠서 당한 것일 뿐이다. 이것만 생각하면 나는 도대체 민주화가 됐다는 요즘이, 옛날의 서슬 퍼런 군사 독재 정권 시절보다 인권이 뭐가 좋아졌다는 건지 도무지 이해를 할 수 없다.

결론을 내리겠다.
기독교 교리의 논리적인 성립을 위해서라도 사형 제도를 부정한다는 건 말이 안 된다.
당신이 불신자나 기독교 안티이고 그저 인본주의 박애주의자여서 사형 제도를 반대할 수는 있다.

그러나 당신이 성경을 믿는 크리스천이라고 하면서 사형 제도를 반대한다는 건 있을 수 없는 일이며, 당신은 지금 살인자 마귀에게 속아서 잘못된 생각을 하고 있는 것이다. 엄한 형벌을 필요하게 만든 것도 죄이지만, 죄에 대한 벌을 공의롭게 집행할 수 없게 만들고 있는 것 역시 인간의 죄이다.

그리고 또 생각을 해 보아라. 역사적으로 억울하게 사형 당하기로는 지금까지 크리스천들만치 많은 순교의 피를 흘린 집단이 또 있었겠는가? 그래도 그들은 사형 제도 자체를 문제삼지 않으며, 그럴 필요도 없다.

성경에 입각한 바른 교리가 세상에 널리 퍼져서 영화 <밀양>에서처럼 “내가 용서를 안 한 가해자를 어떻게 신이 용서해?” 같은 시험에 드는 사람이 이 땅에 없어야 할 것이다. 그리고 크리스천들이 믿는 복음은 그저 막연하고 맹목적이고 몰상식· 비합리적인 게 아니라 지극히 건전하고 이치에 맞는 진리라는 인식이 확산되어야겠다.

Posted by 사무엘

2012/07/31 19:27 2012/07/31 19:27
, , ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/714

Trackback URL : http://moogi.new21.org/tc/trackback/714

Comments List

  1. 사무엘 2012/09/04 14:44 # M/D Reply Permalink

    * 흔히 나오는 사형 제도 반대 논리에 대한 재반박

    1. 후진국, 야만 독재 국가일수록 사형 집행을 남용한다:
    - 그 논리대로라면, 뒤집어서 선진국이라는 껍데기를 쓰고 황금 만능주의 속에서 인간성 상실, 성 상품화, 저출산 고령화가 만연한 막장 국가일수록 사형 집행까지 안 한다고 비판할 수도 있다. 피장파장. 제아무리 북한이든 중국이든 야만 독재 국가라도, 성경적으로 바르게 하는 건 바르게 하는 것이다.
    - 우리나라는 제도적으로 사형 제도가 오남용될 가능성은 이미 전혀에 가깝게 없어져 있다.

    2. 사형 집행을 해도 흉악 범죄가 줄어들지 않는다:
    - 그 명제에 나는 개인적으로는 동의하지 않는다. 오히려, 범죄 방지 효과가 나타날 정도로 충분히 공개적으로 집행을 더 많이 해야 한다.
    - 형벌의 일차적인 존재 목적은 죄값을 치르게 하는 것이지, 교화가 아니다.

    3. 사형 집행을 한다 해도 죽은 피해자가 살아나는 것도 아닌데, 악을 악으로 갚고 복수만 한다고 해서 더 나아질 게 없다:
    - 그렇다고 해서 가해자는 무조건 아량을 베풀고 용서하고 살려 주자고? 그렇다면 이미 죽어 버린 피해자만 정말 재수 없고 운이 나빠서 죽은 것이다. 가해자 인권만 있고 피해자 인권은 없다. 이건 참 잔인한 생각이 아닐 수 없다.
    - 무엇보다도, 용서와 아량은 피해자 유족이 개인적으로 청원해야 할 일이지, 국가가 나서서 판단할 일이 아니다.

    4. 유럽 연합은 사형 집행을 하는 나라와는 경제적으로 상종을 안 한다고 한다:
    - 그쪽과 거래함으로써 발생하는 국익이 사형 제도 부재로 인해 발생하는 기회 비용보다 언제까지 더 클지 한번 두고 보자.
    - 도대체 유럽 연합이라는 인간들은 정말로 인권 막장 지대인 북한 같은 곳을 바로잡는 데는 하나도 기여하는 게 없으면서 왜 다른 주권 국가의 사법권에 안하무인격으로 감 놔라 배 놔라 하는지 알 수가 없다.

Leave a comment

1. 심벌 검색 기능의 퇴화(?)

예전에도 글에서 언급한 적이 있지만, 비주얼 C++에는 Alt+F12를 누르면 심벌 검색을 할 수 있다. 주어진 프로젝트의 소스 코드에 등장하는 모든 명칭들(클래스, 함수, 전역 변수 등등)의 선언과 정의가 있는 곳을 곧바로 찾아갈 수 있으니 이건 매우 편리한 기능이 아닐 수 없다.

이 기능이 특히 강력한 이유는 내가 해당 프로젝트의 내부에서 선언한 명칭뿐만 아니라, 인클루드 파일에 있는 명칭들도 전부 조회할 수 있기 때문이다. 따라서 C/C++ 라이브러리에 있는 함수나 윈도우 플랫폼 SDK 내지 MFC 라이브러리에 있는 방대한 명칭들도 다 조회가 되어서 해당 명칭의 출처를 쉽게 알아낼 수 있다.

어차피 소스 코드를 빌드하여 precompiled header나 인텔리센스 정보를 만들 때 이런 정보들을 다 한 번씩 파싱을 하기 때문에, 심벌 검색은 최적화된 자체 데이터베이스를 대상으로 신속하게 행해진다. 무식하게 수백, 수천 개의 헤더와 소스 파일들을 텍스트 형태로 찾는 find in files 형태가 아니다.

그런데, 비주얼 C++ 2010을 보니 심벌 검색은 해당 프로젝트에서 직접 선언한 명칭만 가능하고, 그 프로젝트가 stdafx.h에다가 인클루드하여 사용하는 플랫폼 SDK, MFC 같은 것들의 명칭은 조회되지 않는다.
200x 시절과 동일하게 '참조에서 찾기' 옵션을 켜고, 검색 범위를 'All components'로 바뀌었는데도 여전하다. 이 기능에 무슨 문제가 생겼는지 궁금하다.

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

(WM_CREATE 위치가 뜨는 2003 좌, 하지만 뜨지 않는 2010 우)

물론, 소스 코드에서 MFC나 플랫폼 SDK의 명칭을 참조하는 부분에서 F12를 눌러 보면 여전히 해당 명칭의 선언부로 가긴 간다. 하지만 명칭을 직접 입력해서 찾는 심벌 검색 기능은 왜 그게 불가능해진 걸까?

보아하니 그저 닷넷 프레임워크 라이브러리의 명칭을 조회하는 기능에만 신경 쓰느라, C++ 네이티브 개발 쪽은 지원이 간과되기라도 한 건지? 2010은 그렇잖아도 인텔리센스에다 빌드 보조 파일들이(*.sdf, *.ipch) 예전에 비하면 기겁을 할 정도로 방대해졌는데 편의 기능은 도리어 없어지면 어떡하냐 말이다.

2. 메뉴 편집기의 우클릭

C++ 프로젝트를 새로 만들거나 열어서 리소스에서 메뉴 편집기를 연다. 아, 프로젝트를 만들 필요 없이 그냥 리소스 템플릿만 하나 만들어서 메뉴를 생성해도 되겠다.

열었으면 클라이언트 화면의 빈 공간을 아무 데나 우클릭하여 메뉴 편집기에 대한 컨텍스트 메뉴를 연다. 그 후 마우스로 다른 곳을 클릭하거나, 명령을 선택하거나, ESC를 눌러서 컨텍스트 메뉴를 없앤다.
그러면 컨텍스트 메뉴가 화면 좌측 상단에 한 번 또 나타나서 사용자를 성가시게 할 것이다.

이는 명백한 버그이다. 대화상자 같은 다른 리소스 편집기에서는 우클릭을 해도 이런 현상이 생기지 않는다.
2010뿐만이 아니라 무려 2003에서도 동일한 현상이 발견된다. 거의 10년 묵은 버그라는 뜻인데 아무도 신경을 안 쓰는지 지금까지 고쳐지지 않았다.
설마 6.0에서까지 이랬을 것 같지는 않은데 잘 모르겠다. 아직도 6.0 쓰시는 분이 계시면 확인 요망.

여담이지만 마우스가 아니라 Shift+F10 같은 키보드로 컨텍스트 메뉴를 열면 이런 현상이 생기지 않는다.
그리고 화면 빈 공간이 아니라 편집 중인 메뉴 항목의 경우 우클릭하더라도 역시 그 현상이 생기지 않는다.
이건 아주 사소한 코딩 실수로 보이고, 몇 라인만 고치면 바로 제거할 수 있는 버그이다만, 10년에 가까운 시간 동안 발견하고 지적한 사람이 없었나 보다.

C#이나 VB, C++/CLI 같은 닷넷 환경의 경우, 폼(네이티브 개발 환경으로 치면 대화상자)에다가 메뉴 컴포넌트를 집어넣으면 그 자리에서 바로 메뉴를 편집할 수 있게 되어 있으니 네이티브 개발과는 환경이 꽤 다르다.
닷넷 프로그램도 기본 메뉴는 일반 윈도우 운영체제가 제공하는 표준 네이티브 메뉴 형태로 나오지 않겠나 하고 생각해 왔는데, 놀랍게도 그렇지 않다. 비주얼 스튜디오 200x와 비슷한 형태인 싸제 메뉴이다.

3. 툴바 편집기의 화면 잔상

이뿐만이 아니다.
리소스 중에서 툴바 편집기를 보면, 툴바 아이템들을 순서대로 하나씩 찍어 보기만 해도 예전 selection 흔적이 지저분한 잔상으로 잔뜩 남는다. 저건 절대로 multiple selection을 나타내는  게 아니며, WM_PAINT 메시지만 다시 받아도 잔상은 싹 없어진다.

사용자 삽입 이미지
열기, 저장, 모두 저장, 인쇄 아이콘의 테두리에 생긴 잔상들을 보라.
그리고 믿어지지 않겠지만 이건 비주얼 C++ 2003 시절부터 변함없던 버그이다!
전세계에서 압도적인 인지도와 점유율을 자랑하는 개발툴에 이런 초보적인 버그가 있다는 게 믿어지는가? 6.0은 그렇지 않았던 걸로 난 기억한다.

아이콘의 배치 순서를 조정하거나 중간에 여백을 넣기 위해서 드래그 드롭만 해도 잔상이 잔뜩 쌓인다. 구체적으로 재연 조건과 증상을 일일이 기술하기에는 구차하나, 잔상 현상은 2010에서 조금 더 심해졌다.

4. 속성 대화상자

비주얼 C++ 6.0까지는 전통적으로 가로로 길쭉한 자신만의 context-sensitive한(문맥 민감. 사용자가 키보드 포커스를 두거나 선택한 개체나 문서에 따라서 대화상자 내부 내용이 수시로 동적으로 바뀌는) 속성 대화상자가 있어서 Alt+Enter를 누르면 언제든지 그게 떴었다. old timer라면 추억의 옛날 스타일 대화상자를 기억하실 것이다.

사용자 삽입 이미지
그게 닷넷부터는 비주얼 베이직 스타일의 프로퍼티 그리드로 다 바뀌었다.
특히 프로젝트 설정 대화상자(VC6 표준 단축키 기준 Alt+F7)도 이 형태로 리모델링된 것 여러분들 다 아실 것이다.

그러나 프로퍼티 그리드가 커버하지 못하는 UI가 있었으니 그것은 바로 preview 기능이다.
비트맵, 대화상자, 메뉴 등 리소스들을 일일이 열 필요 없이 찍어 보기만 해도 이놈이 대략 어떻게 생겼는지 간략히 표시해서 보여주는 기능인데,
이건 2차원적인 공간에다 뭔가를 그려야 하기 때문에 기존 프로퍼티 그리드로 커버할 수가 없다.

그래서 별도의 버튼을 누르면 결국 과거 6.0 시절의 속성 대화상자와 비스무리하게 생긴 대화상자가 떠서 미리보기를 보여주는 기능이 들어갔다. 뭐, 여기까지는 뭐 나쁘지 않다. 메뉴나 대화상자가 좀 더 깔끔하게 그려졌으면 좋겠는데 10년 전이나 지금이나 하나도 바뀐 게 없이 똑같이 엉성하다는 건 아쉽지만 말이다.

그런데 과거의 200x 시절에는 미리보기를 보는 중에도 키보드 포커스는 각종 리소스들을 고르는 화면에서 계속 유지가 되어서 위· 아래 화살표를 누르며 리소스들을 조회할 수 있었는데,
2010부터는 뭔가를 선택하고 나면, 키보드 포커스가 미리보기 대화상자로 바뀌어 버린다. 그래서 마우스로 해당 아이템들을 일일이 찍어야 한다.

역사적으로 비주얼 C++은 4.0 때 Developer Studio (MSDEV)라는 첫 UI가 갖춰진 이래로 닷넷으로 넘어갈 때 대대적인 리모델링을 거쳤고, 2010 때는 WPF 기반으로 또 IDE의 구현체가 크게 바뀌었다.

요즘 다시 C++11 지원처럼 C++ 지원이 강화되고는 있다지만, 기존 코드들이 리팩터링되는 과정에서 예전에는 없던 사소한 버그들이 끼어 들어가는 게, MS에서 닷넷에 비해 네이티브 환경 개발에 점점 소심해지고 있다는 생각이 들어서 아쉽다. 닷넷과 관련된 개발 환경이라면 저런 버그가 들어갔을 리가 없을 텐데 말이다.

다음은 버그까지는 아니고, 비주얼 C++과 관란하여 추가로 떠오르는 생각들이다.

1. 비주얼 C++은 32비트 시절 이래로(무려 4.x부터) 80비트 초정밀 부동소숫점인 long double을 무시하고, 이것도 일반 double과 완전히 동일한 64비트 부동소숫점으로만 제공하는 것으로 잘 알려져 있다.
난 32비트 CPU에서는 10바이트 단위로 정보를 처리하는 게 불편해저서 long double이 도태한 게 아니겠나 정도로만 생각해 왔다.
그런데 나중에 알고 보니 인텔 CPU엔 80비트 부동소숫점을 연산하는 명령 자체는 존재한다고 한다. 단지, MS 컴파일러가 이를 활용하지 않는다고.

이것까지 지원해야 하면 %타입 문자부터 시작해서 언어 라이브러리에도 그야말로 대대적인 칼질이 가해져야 하는 건 사실일 것이다. 그런데 그렇다고 해서 있는 CPU의 기능을 컴파일러가 활용하지 않는 건 좀 문제가 있어 보이는데?
인텔 컴파일러 같은 다른 벤더 제품 중에는 long double을 쓸 수 있는 놈이 있는지 궁금하다.

2. 오늘날 거의 모든 IDE와 에디터들은 탭을 customize할 수 있다.
화면에 표시되는 탭 길이를 조절하고(보통 거의 다 4를 쓰지만), 코딩용 자동 들여쓰기를 할 때 공백을 삽입할지 탭을 삽입할지를 지정할 수 있다. 그리고 언어별로 어떤 탭 설정을 사용할지도 지정 가능하다.

그런데 여기서 한 발 더 나아가서, 읽어들이는 소스 코드의 형태를 보고 탭 컨벤션을 자동 감지하게 할 수는 없나?
space로 맞춰져 있는 소스 코드에다가 눈치 없게 탭으로 들여쓰기를 삽입한다거나 혹은 그 반대로 하는 것. 불편하다.

자동 들여쓰기를 구현했을 정도라면 앞뒤의 중괄호가 어떻게 돼 있고 whitespace들이 space인지 tab인지 주변 context들은 다 파악했다는 뜻이다.
따라서 조금만 더 센스 있게 동작하게 만드는 것은 마치 코드의 줄바꿈 문자의 종류를 자동 감지하는 것만큼이나 그렇게 어려운 일이 아니리라 여겨진다.

Posted by 사무엘

2012/07/29 08:33 2012/07/29 08:33
, ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/713

Trackback URL : http://moogi.new21.org/tc/trackback/713

Comments List

  1. 아라크넹 2012/07/29 11:54 # M/D Reply Permalink

    1. D에서 real이라는 타입으로 80비트 부동소숫점 형을 지원하는 걸로 알고 있습니다. 그 밖에도 웬만하면 long double이라고 하면 x86에서는 80비트를 가리키는 것 같았네요.

    현재 기존의 x87 FPU를 기반으로 한 부동소숫점 명령은 대부분 SSE2 기반 명령으로 다 옮겨 갔습니다. x87은 80비트 long double을 지원하지만 SSE2에서는 지원하지 않으니까 당연히 long double은 사양길로 가고 있는 거죠. 80비트 정밀도가 들어 간 이유는 제가 알기로 round-off error를 피하기 위한 것이었습니다만, 이제 FMA(fused multiply-add)가 들어 가고 있으니 별로 큰 문제는 되지 않을 것입니다. (FMA를 쓰면 본래 mantissa의 두 배 정도 되는 정밀도를 확보할 수 있습니다.)

    2. vim이 copyindent라는 기능으로 지원을 합니다. 엔터를 누르면 이전 줄의 indent에 사용된 문자들을 그대로 복사해서 다음 줄에 붙여 주는 것이죠. 아마 전문 편집기(제가 여기서 "전문"이라 함은 vim 아니면 emacs... =3)라면 다 지원할 겁니다.

    1. 사무엘 2012/07/29 20:42 # M/D Permalink

      1. x87만 생각하고 있었는데 실은 SSE2쪽에도 부동소숫점 명령이 있죠. 간과하고 있었습니다. ^^

      2. 아 그리고 추억의 D 언어..!!

      3. xcode는 sizeof(long double)이 16이라고 나오더군요? (double은 8이면서) “엥? 이건 뭐지” 싶습니다.

    2. 아라크넹 2012/07/30 00:18 # M/D Permalink

      long double이 16바이트인 경우는 보통 double 두 개로 구현한 경우입니다. 예를 들어서 0x1.23456789abcdefp0은 원래대로라면 mantissa가 56비트여서 double로 저장하지 못 하는데, 이걸 0x1.23456789abcdep0(53비트) + 0x1.ep-53(3비트)로 나눠서 저장하는 겁니다. 당연하지만 앞에서 말한 FMA 같은 거 없으면 하드웨어보다 훨씬 느리죠.

  2. 김재호 2012/07/29 13:31 # M/D Reply Permalink

    2번 눈치없는 탭이나 공백 자동 감지 기능은 VS2010부터 있어요.
    Productivity Power 툴 확장팩인가를 설치해야 하던가 그럴꺼에요.
    탭과 공백이 섞여 있는 눈치없는 소스 파일이 열리면 자동 감지 해서 tabfy혹은 untabfy 하겠냐고 물어봅니다.

    1. 사무엘 2012/07/29 20:42 # M/D Permalink

      오랜만에 다시 뵙네요. 반갑습니다. ^^;;
      그냥 제공되는 건 아니고 확장팩을 설치해야 되는군요.
      VC++ 20xx의 기본 IDE는 텍스트 파일이 줄바꿈 문자가 일관성 있게 돼 있지 않고 여러 종류가 섞여 있으면 정규화시킬지 묻긴 합니다.
      하지만 들여쓰기용 탭과 공백의 일관성을 검사하는 에디터는 저는 지금까지 본 적이 없네요.

  3. 주의사신 2012/07/31 15:56 # M/D Reply Permalink

    아래 사이트 가셔서 버그를 신고하면, 버그가 수정이 될 수도 있습니다.

    http://connect.microsoft.com/

    그쪽 개발팀에서 버그를 재현해 낸다면요.

    1. 사무엘 2012/07/31 16:11 # M/D Permalink

      사용자가 너무 많고 세계구 급으로 노는 회사이다 보니, 저같은 개인 개미 개발자의 목소리가 제대로 전달은 되려나 모르겠습니다.

      위에서 예를 든 것들은 프로그램이 죽는다거나 하는 심각한 게 아니고, 100% 너무나 쉽게 재연 가능한 것들이고, 한편으로는 어이없는 것도 있습니다. VS 2003 이래로 아직까지 안 고쳐졌다거나..; 그래서 제가 이 양반들이 C++ 네이티브 환경 개발을 너무 홀대하는 게 아니냐는 의혹을 제기하기도 한 것이고요.

    2. 주의사신 2012/07/31 16:17 # M/D Permalink

      과거 글 하나 올린 적이 있었는데, 그쪽 개발자가 친절하게 "똑같이 해 봐도 안 되는데 조금 더 정보를 줄 수 있느냐"는 이야기를 하더군요.

      그래서 버그 재현 과정을 다시 더 자세히 설명했는데 그래도 안 되서 "미안해요. 재현이 안 되요"라고 이야기해 주더라고요.

      생각보다 많이 친절한 회사더군요.

Leave a comment

일상 생활 여러 잡설

1.
매일 아침에 일어나서 체중계 눈금을 보는 게, 집 앞 주유소의 휘발유 값을 보는 느낌이다. (올라서는 안 되는 숫자인데 찔끔찔끔 조금씩 오르고 있다 ㄲㄲㄲ)

2.
원소 주기율표하고 한자 부수 테이블은 웬지 서로 뭔가 묘하게 비슷한 구석이 있는 것 같다. 이들은 해당 분야 학문의 근간을 이루는 정보이며, 각각 화학 교재와 옥편의 속표지에 어김없이 등장한다. 원자의 합성 원리하고 한자의 합자 원리에 묘하게 유사점이 보이는 듯하다..

3.
요즘 잘 알다시피 자영업자들이 너무 어려워서 못 살겠다고 난리이다.
내수 수요는 위축되어 가는데 관리비와 유지비는 계속 오르고, 하지만 함부로 제품 가격을 올리기에는 주변 경쟁 가게에 비해 눈치가 보여서 그러지도 못하겠고...
특히 치킨집 같은 식당은 마치 택시 기사 내지 편의점만큼이나 진입 장벽이 낮고 시장의 규모에 비해 '너도 나도' 너무 많이 뛰어들다 보니 공멸의 길로 가는 일종의 red ocean처럼 됐다.

하지만 그럼에도 불구하고 줄을 서서 기다려야 하고, 음식을 없어서 못 파는 맛집도 여전히 존재한다. 정말 아이러니가 아닐 수 없다. 대형 음식점 브랜드 체인점이 아닌데도 말이다. 그리고 사실 요즘은 브랜드 체인점이라고 해서 성공한다는 보장이 있는 것도 아니다.
그래서 식당을 운영하는 사람은 자기 가게만의 독자적인 맛을 개발하고, 자기 집이 매스컴을 한번 타서 맛집으로 소문나게 하는 데 사활을 걸고 목숨을 거는 모양이다. 자영업의 양극화 기질인 듯하다.

4.
언뜻 보기에 비슷한 주제를 다루지만 문제를 접근하는 방식이 다른 학문 분야의 쌍으로는 어학과 문학이 있고, 과학과 공학이 있다.
이에 덧붙여 정보 올림피아드의 경시부와 공모부도 그런 맥락으로 볼 수 있을 것이다.

경시부는 제한된 시간과 자원으로 주어진 문제를 해결하는 프로그램을 빠르고 정확하게 작성하는 게 목표이고,
공모부는 실질적인 문제를 해결하고 사회에 보탬이 되는 창의적이고 완성도 높은 완전한 소프트웨어를 개발하는 게 목표이다. 둘은 관점이 서로 완전히 다르다.

마치 촘스키를 능가하여 현대 언어학의 패러다임을 뒤집는 문법 체계를 내놓는 것하고,
셰익스피어를 능가하여 전세계를 울리는 노벨 문학상급 베스트셀러 소설이나 희곡을 쓰는 것은 격이 서로 완전히 다르듯이 말이다.

하지만 소설가· 시인이라고 해서 언어학을 전혀 모르는 게 아니듯,
나 같은 공모 출신도 전산학, 자료구조와 알고리즘 관념이 없는 건 물론 절대 아니다.
단지 경시 출신처럼 거기에만 완전 최적화된 체계적인 훈련을 받지를 않았을 뿐임.

5.
내 경험상, 고가 도로의 아래에서는 길 찾고 운전하기가 엄청 어렵다. 고가 도로의 기둥들이 하부의 도로를 분할하고 길의 선형을 왜곡하며, 찾아가기 어려운 복잡한 갈림길들을 만들기 때문. 내부 순환로의 아래, 아현 고가 차도의 아래 등에서.. 내비를 뻔히 켜 놓고도 초행에서 길을 제대로 든 적이 거의 없었다. ㅜㅜ

그리고 곡선 형태로 된 길에서 차들이 앞에서 신호 대기를 하고 서 있을 때 굉장히 조심해야겠다는 생각을 했다. 직선일 때와는 달리, 앞차와 나와의 간격이 정확히 얼마가 되는지를 알기가 어렵다. 조심 안 하면 추to the돌..;; 경험상 이런 길이 많지는 않지만, 이런 곳에서는 뒷차 배려를 위해 비상등이라도 켜고, 추돌을 당하더라도 내가 또 앞 차를 들이받아서 연쇄 추돌이 나지 않게 앞차와는 살짝 간격을 두고 서 있는 게 좋겠다는 생각이 들었다. 특히 신호 대 기가 아니라 사고 때문에 자동차 전용 도로에서 커브 구간에 멈춰 선 거라면 더욱 그래야 한다.

6.
경부 고속도로를 경부라고 안 하고 1번 고속도로라고 일관되게 부르는 분을 난생 처음 봤다. 모 대학교의 전산학과 교수님. 교통덕이 아닌 이상, 고속도로의 번호에 신경 쓰는 사람이 도대체 누가 있나? 방송에서도 거의 안 쓰는데. ㅋㅋ

그분은 교통 덕후여서는 아니고, 유학 생활 덕분에 미국물을 많이 드셔서 미국 프리웨이의 체계에 익숙해진지라 한국 고속도로도 번호로 식별하는 걸 선호하신다더라. 그 반면에 나는 철덕에서 파생된 교통덕이어서 미국 생활과는 무관하게 번호를 외우고 있는 것이고.

7.
내가 여러 번 경험했는데, 서울 지하철 2호선은 다른 노선들에 비해 배차가 불규칙한 경우가 많다. 무슨 말이냐 하면, 어떨 때는 거의 6~8분 가까이 열차가 안 오는데 그 차의 뒷차는 겨우 한 정거장 차이로 앞차를 바싹 뒤쫓아 오고 있다거나 하는 것 말이다. 이때는 배차만 불균등한 게 아니라 승객의 분포도 불균등하다.

오랫동안 안 오다가 갑자기 오는 앞차는 필연적으로 승객이 쏠려서 혼잡하다. 급하지 않으면 그 열차를 보내고 바로 뒤따라 오는 차를 타면 훨씬 더 쾌적한 여행을 즐길 수 있다. 2~3분만 투자해서 텅 빈 차를 타고 앉아서 갈 이유는 충분하다. 그렇잖아도 그 앞차는 지연을 먹고 있을 가능성이 높다. 내릴 승객만 내리게 하고 그냥 빨리 보내 주는 게, 지연을 만회하는 데도 도움이 된다.

Posted by 사무엘

2012/07/27 08:37 2012/07/27 08:37
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/712

Trackback URL : http://moogi.new21.org/tc/trackback/712

Comments List

  1. 다물 2012/07/27 11:37 # M/D Reply Permalink

    2호선 배차간격은 사람이 제일 많이 타는 노선이라는것도 원인이 되겠지만, 지선도 문제가 될겁니다.

    신도림역까지만 가는 열차가 있을 경우

    신도림역 전에 사람들은 그 열차와 다음 열차를 모두 보겠지만 신도림역 이후 사람들은 신도림역까지만 가는 열차는 못보고, 그 다음에 오는 열차만 보게 되니 간격이 조금 늘어나겠죠.

    1. 사무엘 2012/07/27 20:45 # M/D Permalink

      네, 좋은 지적입니다. 공감합니다.
      특히 한낮에 2호선이 의외로 열차가 굉장히 안 오는 때가 있는데, 그건 중간에 한 열차가 기지로 빠져 버렸기 때문인 것도 크게 작용합니다.
      반대로 중간에 뉴비 출고 열차가 삽입되면, 배차와 승객 분포가 필연적으로 불균등해지겠죠.

Leave a comment

조화평균, 조화수열, 황금비

1. 조화평균과 조화수열

우리는 중등 학교의 수학에서 산술, 기하, 조화평균을 배운다.
물론, 대부분의 일상생활에서 숫자를 다룰 때는 단순히 합계를 자료의 개수로 나누기만 하는 산술평균 하나만 있어도 충분하다. 그러나 다른 개념의 평균이 필요할 때도 있다.

가령, 어떤 수치가 1년 간격으로 예전보다 3배, 4배, 5배씩 증가해서 총 60배가 되었다면, 이를 해마다 4배씩 증가했다고 싸잡아 간주할 수는 없는 노릇이다. 4의 3승은 64이지 60이 아니기 때문이다.

이런 식으로 비율 내지 배율을 좋아하는 계산 분야에서는 기하평균이 필수이다. 앞의 예에서는 (3+4+5)/3이 아니라, 3*4*5의 세제곱근인 약 3.915가 정확한 값이다.

그럼 조화평균은 무엇이며 어떤 용도로 쓰일까?
역수의 산술평균을 또 역수로 취한 값이 바로 조화평균이다. 두 수 a, b의 조화평균을 그 정의대로 구해서 식을 정리하면 2ab / (a+b)가 나온다. 쉽게 말해 곱을 합으로 나눈 셈이다.

자동차가 동일한 길이의 두 구간을 달리는데 한 구간은 시속 30km로, 다른 구간은 시속 60으로 달렸다면, 전체 구간에 대한 자동차의 표정 속도는 30과 60의 조화평균인 시속 40이 나온다. 한 구간의 길이가 30km였다고 생각해 보면 가는 데 시속 30으로 1시간, 시속 60으로 30분이 걸렸을 터이니 전체 60km를 1시간 반 만에 주파하는 속도는 시속 40이기 때문이다.

반대로 길이가 중요하지 않고 소요 시간의 절반을 시속 30으로 달리고 나머지 소요 시간 동안 60으로 달렸다면 자동차의 표정 속도는 응당 산술평균인 시속 45가 될 것이다. 관점의 차이를 이해하시겠는가?

학교에서 조화평균은 병렬 연결된 저항들의 전체 저항값을 구할 때 정도에나 쓰였지만 교통 관련 계산을 할 때 더욱 유용히 쓰일 수 있다.
어떤 노선에 버스가 5분 간격으로 다닌다고 치자. 그런데 5분으로도 모자라서 그 상태에서 3분 간격의 버스가 추가로 더 투입되었다면, 실질적인 배차 간격은 얼마로 좁혀졌다고 볼 수 있을까?

답부터 말하자면 이 값은 5와 3의 조화평균의 절반과 같은 1.875분이다.
5와 3의 최소공배수인 15분이라는 시간을 생각해 보면, 그 동안 5분 간격 버스는 3대가 다닐 수 있다. 그러나 3분짜리 버스는 5대가 다닐 수 있으므로 15분 동안 버스가 총 8대로 늘어난 셈이 된다.

따라서 실질적인 평균 배차간격은 15를 8로 나눈 1.875분이다. 5와 3의 조화평균인 3.75는, 5분 간격 버스와 3분 간격 버스를 합친 것이 3.75분 간격 버스 두 대를 합친 것과 동일한 증차 효과를 낸다는 걸 의미한다.

임의의 동일한 수들에 대해서 기하평균(G)은 산술평균(A)보다 크지 않으며, 조화평균(H)은 기하평균(G)보다 크지 않다는 것이 증명되어 있다. 그리고 아예 H=G^2 / A라는 항등식도 알려져 있다. 어떤 데이터에 대해서 두 종류의 평균값을 알고 있으면 다른 한 평균값은 그로부터 유도해 낼 수 있다는 뜻이 되겠다.

한편, 1/3, 1/4, 1/5 ~처럼 역수가 등차수열을 이루는 수열은 조화수열이라고 한다. A, A와 B의 조화평균, B으로 구성된 세 수는 응당 조화수열이다.
이건 등차나 등비수열도 아니고 도대체 무슨 의미가 있는지 궁금할 것이다. 하지만 자연에서 조화수열은 아주 직관적으로 쉽게 찾을 수 있다. 이름에 괜히 harmonic이 붙은 게 아니다.

일단 우리 눈에 사물이 비쳐 들어오는 원근법이란 게 반비례이기 때문에 조화수열과 관계가 있다. 직선으로 뻗은 도로에 균일한 간격으로 그어진 차선을 보자. 멀리 떨어진 놈일수록 중앙의 소실점에 가까워지고 겉보기 간격이 더욱 조밀해진다. 그 간격이 수학적으로는 바로 조화수열인 것이다.

거시적으로 보면 태양은 달보다 N배나 더 크지만 지구로부터의 거리도 똑같이 N배나 더 멀리 떨어져 있다. 그렇기 때문에 지구에서의 겉보기 크기가 둘이 거의 같으며 일식도 일어날 수 있다.

사람의 뇌는 두 눈이 보내 준 2차원 영상을 합성하여 3차원 공간을 인지하는 능력이 대단히 발달해 있다. 그런데 그 능력은 수학적으로 따지자면, 2차원 조화수열 간극으로부터 3차원 등차수열 간극을 유추하는 게 상당수를 차지하고 있을지도 모른다. 그만큼 조화수열은 우리에게 친숙한 존재이다.

그 다음으로 우리가 조화수열을 시각적으로 볼 수 있는 흥미로운 분야는 음악이다. 실로폰도 그렇고 파이프 오르간이나 하프도 그렇고, 음을 만들어 내는 매체는 저음이 언제나 길고 고음은 한 치의 예외 없이 짧다.

그런데 그 짧아지는 간격이 조화수열이다. 매체를 그런 간격으로 만들면 소리의 파형 주기는 기하급수적으로(=등비수열) 짧아지는 평균율 음계가 나오는가 보다. 어떻게 그게 물리적으로 가능한지는 잘 모르겠다.

2. 황금비

조화수열이라는 말이 나왔으니 말인데, 아름다움이나 조화 같은 걸 수학적으로 설명할 때 빠짐없이 등장하는 건 황금비이다.

기본 발상은 a:b = (a+b):a 비례식을 만족하는 a와 b의 비율이다. 음, 뭔가 심오하지 않은지? 쉽게 말해 긴 변과 짧은 변의 비율이, 긴 변과 짧은 변을 합한 것하고 긴 변과의 비율과 같은 걸 말한다. 이걸 식으로 표현하면 이차방정식으로 귀착되고, 황금비의 값은 (1+sqrt(5))/2, 대략 1.618이 된다.

황금비 상수는 뭔가 심오함이나 신비로움, 괴팍함이 느껴지는 초월수도 아니고, 간단한 이차방정식만으로 값을 구해서 모든 특성을 파악할 수 있는 평범한 대수적 수에 불과하다. 그런데 이게 왜 그렇게 중요한 걸까?

인간이 보편적으로 새벽 2시에 가장 깊이 잠들어 있는지, 저녁 8시에 죄책감 없이 가장 잔인해지는지는 잘 모르겠지만, 저 비율이 인간이 보편적으로 가장 심리적인 안정감과 균형과 조화를 느낀다고 그런다. 오죽했으면 golden ratio라는 이름이 붙었겠는가? 이것 말고 golden이라는 말이 붙은 개념은 “자신이 대접받고 싶은 만큼 남에게도 대접해 줘라”로 요약되는 golden rule 정도밖에 없다.

얼굴의 이목구비 배치 비율도 그렇고 무슨 동식물이나 건축물의 외형에도 황금비가 적용되어 있다고 그런다. 하지만 현대인에게 가장 뼈저리게 황금비를 느낄 만한 요소는 카드(교통 카드, 신용카드 등등~)의 가로· 세로 비율이 황금비라는 점 하나로 게임 끝이 아닐까 싶다. 그렇다. 바로 그 비율이 황금비이다.

1 1 2 3 5 8 13 21~ 로 이어지는 그 유명한 피보나치 수열도 현재 항과 이전 항의 비율이 황금비로 수렴한다는 건 잘 알려진 사실이다. 일반항을 구하는 공식엔 응당 황금비 상수가 들어간다.

또한, 0부터 시작해서 x=sqrt(1+x)를 무한 반복해도 x는 황금비로 수렴한다. 계산 과정의 특성상 x는 sqrt(2)도 한 번 거치지만, 궁극적으로는 다른 수로 수렴하게 된다는 게 흥미롭다.
황금비는 역수가 자신에서 1을 뺀 값과 같다는 특징이 있기도 하다. (0.618...) 1/x = x-1인데, 이는 특별한 게 아니라 황금비의 정의의 특성상 당연한 귀결이다.

도형 중에서는 정오각형이 변 길이와 대각선 길이의 비가 황금비이다.
1마일이 대략 1.609km인 건 아무래도 황금비와는 관계가 없고 전적으로 우연인 듯하다.
또한 종래의 4:3 aspect ratio를 깨고 컴퓨터 화면이 가로로 좀 더 길쭉한 추세로 가는 것 역시, 사람들이 황금비를 심리적으로 더 좋아해서인지는 모르겠다.

한편, A4나 B4 같은 용지의 길이 비율은 황금비가 아니라 sqrt(2)이다. 본인은 A4 용지의 크기가 210*297mm인 건 알고 있었지만 그 비율이 sqrt(2)를 표방한 것인 줄은 전혀 모르고 있다가 최근에 알게 되고는 크게 놀랐다. 심심해서 297을 210으로 나눠 봤는데 딱 1.414...가 나왔으니 말이다.

이런 비율의 장점은 우리가 이미 실생활에서 적지 않게 경험한 적이 있지 싶다. 종이를 반으로 접어도 크기 비율이 접기 전과 동일하게 유지된다는 것.
즉, 황금비가 a:b = (a+b):a를 추구했다면, 용지는 a:b = b:a/2를 추구한 셈이다.
황금비가 길이가 1인 정오각형의 대각선 길이라면, sqrt(2)는 길이가 1인 정사각형의 대각선 길이이다.

원래는 조화수열에 대해서만 글을 쓰려고 했는데 어쩌다가 황금비까지 나오면서 얘기가 옆길로 샜는지 모르겠다. 둘은 실용적인 의미가 약간 유사점이 있다 보니 미묘하게 한 글로 엮이게 된 것 같다.

Posted by 사무엘

2012/07/25 08:26 2012/07/25 08:26
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/711

Trackback URL : http://moogi.new21.org/tc/trackback/711

Comments List

  1. 주의사신 2012/07/25 09:02 # M/D Reply Permalink

    1. 기하평균이 어디에 쓰는가 조금 궁금했던 적이 있었는데, 잘 알고 갑니다.

    2. 어릴 적 봤던 "요리왕 비룡"이라는 요리 만화에 "황금비 군만두"라는 것이 나왔던 적이 있습니다. 재료가 4개인가 들어가는데 그 재료의 위치를 잘 잡아서 맛의 황금비를 잡았다는 것이었습니다.... 소개 중에 배경에 삼각형이 있었던 것 같네요.

    1. 사무엘 2012/07/25 10:40 # M/D Permalink

      1. 글을 올린 뒤에 문득 생각났는데요, 기하평균은 숫자들을 모두 로그를 취한 뒤, 그 로그값들의 산술평균을 구하고 그 평균으로 로그 base의 승을 구했다고 볼 수 있습니다.
      즉, 조화평균이 역수의 산술평균의 역수라면, 기하평균은 로그의 산술평균의 지수인 셈이죠.

      2. 하하, 그 황금비는 수학에서 말하는 황금비하고는 다른 개념인 것 같습니다. <김밥천국>의 천국이, 성경이 말하는 천국하고는 무관한 것처럼요. ^^

  2. Paul Sohn 2012/07/31 00:08 # M/D Reply Permalink

    조화평균은 물리에 좀 더 많이 쓰입니다.
    합성 축전기 전기용량 공식, 용수철 직렬연결시 후크상수 계산, 피타고라스 음향학이 대표적인 예입니다.

    그러고 보니, 기독교를 표방하는 몇몇 사이트 중에는 피타고라스 때문에 수학 자체를 디스하는 곳도 몇몇 있더군요.
    웹엔 별별 사람이 다 있다는 건 알았지만 말입니다;;

    1. 사무엘 2012/07/31 16:07 # M/D Permalink

      물리에서 의외로 그런 예가 더 많이 발견되는군요.
      중학교 2학년 과학 시간에 병렬 회로에서의 전체 저항을 구하는 공식이 거의 최초로 접한 조화평균이었는데, 그 당시에 저는 그게 조화평균이라는 걸 몰랐죠.

      수학 자체는 가치와 이념에 절대적으로 중립적이고, 어쩌면 그것도 하나님의 질서와 조화의 성품, 지적인 성품을 알아 가는 아주 좋은 학문입니다. 그런데 역사적으로 그거에 탐닉했던 덕후들 중에 종교관이 심하게 불량했던 사람들이 종종 있었고, 그 수학 원리 자체를 신성시하고 숭배하는 경우가 있었던 건 사실입니다.
      너무 오버해서 과학 기술 자체도 디스하는데 수학을 디스하는 건 동의는 못 해도 이해는 하겠습니다.

Leave a comment

사진으로 본 한국 철도 100년

나 옛날에 <사진으로 보는 한국 철도 역사> 같은 자료가 좀 있으면 좋겠다고 블로그에다 글을 쓴 적이 있었다. 그런데 그것이 실제로 일어났습니다.

학교 도서관에서 <사진으로 본 한국 철도 100년>이라는 보물을 입수했다. 말 그대로 한국 최초의 철도인 경인선이 개통된 지 100주년이 된 1999년에 철도청에서 이런 도감을 출간했었다. 돈 주고 아예 사 버려서 개인 소장하고 싶다.. 까짓거 변상이야 몇 만원 내서 하면 되니까, 분실 핑계 대고 반납하지 말까? ㅜㅜㅜㅜ

여러 주옥 같은 자료가 많지만 이곳에는 딱 두 개만 소개하도록 하겠다. 늘 그렇듯이 책을 그냥 혼자 어설프게 디카로 찍은 것이기 때문에 화질이 시원찮은 것을 양해 바란다.

사용자 삽입 이미지
예전 글에도 적어 놨듯이, 1984년 8월 31일에는 경부선 서정리-천안 구간에서 특대형 기관차 견인 새마을호가 시속 150km 증속 시운전에 성공했다. 이것은 그로부터 딱 20년 뒤에 KTX가 등장하여 그 기록을 딱 두 배 더 올려 놓기 전까지(시속 300km), 한국의 철도 차량이 낸 가장 높은 속도라는 점에서 의의가 매우 크다. 대전, 대구에서만 서는 최고급 열차인 새마을호도 서울-부산이 아직 무려 4시간 50분이 걸리던 시절이었으니 말이다.

난 그런 역사 기록을 글을 통해서만 알고 있었는데 이렇게 인증샷 사진은 처음 봤다. 친절하게도 해당 기관차+열차의 모습과, 시운전 당시에 시속 150km를 가리키던 속도계 바늘을 모두 친절하게 사진으로 남겨 놨다. 속도계는 0, 50, 100, 150 단위로 눈금이 그려져 있는데, 바늘은 맨 오른쪽 끝의 150을 가리키고 있음을 알 수 있다.

그리고 또 본인이 눈 여겨 본 사진은 이것이다.
철길 건널목 안전을 홍보하기 위해 코레일이 지금까지도 이걸 영상물에서 종종 보여주고 있다. 달리는 열차와 충돌한 승용차가 박살이 나면서 질질 끌려가는 모습. 아마 본 적이 있는 분도 있을 것이다.

사용자 삽입 이미지
이 장면은 어떻게 만들어졌을까? 저것은 실제 사고 상황일까, 아니면 연출 연기인 걸까? 그리고 어디서 촬영되었을까? 1990년대에 (디젤) 기관차형 새마을호가 다니던 단선 구간이라면 전라, 장항, 중앙선 정도밖에 없을 것이다. 그게 궁금했는데 이 책을 통해서 본인은 해답을 얻게 되었다.

이것은 사진의 설명에서 볼 수 있듯, 연출된 장면이다. 과거에 철도청은 건널목 안전 홍보를 위해, 1년에 한 번씩 일영 역 구내에서 건널목 사고 모의 실험을 거행했다. 아마 부숴도 상관 없는 폐차 수준의 차를 기증받아서 하는 게 아닐까 싶다. 단, 장소가 새마을호와는 아무 관계가 없는 교외선 일영 역 부근이라니 상당히 뜻밖이다.

실험은 일반적인 기관차+객차형 열차를 시속 7~80km로 달리게 한 후, 실제 건널목 사고가 날 때처럼 몇백 m 앞에서 비상 제동을 거는 것을 가정한다. 그래도 열차는 승용차 앞에서 완전히 멈추지 못하고 차를 박살 낸다는 것을 입증해 보이는 것이다. 실험이 끝나고 나면, 차의 운전석에다 놔 둔 마네킹도 당연한 말이지만 형체를 알 수 없을 정도로 부서져 있다고 한다.

흥미로운 것은, 철도청은 이 시범을 다른 사람도 아니고 사법고시에 합격한 사법 연수생들, 다시 말해 똘똘이 예비 법조인들을 초청해서 보였다는 사실이다. 건널목에서 한번 사고가 나면 결과가 이 지경이 되며 이는 기술적으로 불가피하기 때문에, 나중에 철도 사고와 관련된 법을 제정하거나 집행할 일이 있을 때 이런 경험을 참고하라는 맥락에서이다.

어차피 열차와 자동차가 충돌하면 압도적인 힘과 무게의 차이로 인해 계란으로 바위 치는 결과밖에 나지 않는다. 철도 차량의 안정성을 시험하는 게 목적이 전혀 아니니, 철도 관련 엔지니어가 이런 모의 실험을 참관할 필요는 없다. ^^;; 아마 차 안에 집어넣는 것도 충돌 실험용으로 쓰는 비싼 ‘더미’가 아니라 그냥 일반 마네킹이지 싶다.

‘일영역 건널목 사고’라고 구글에서 검색하면, 1980년대부터 2003년까지 몇 년 간격으로 철도청이 건널목 사고 모의 실험을 실시했다고 보도한 신문 기사를 볼 수 있다. 1999년, 2001년, 그리고 2003년 것까지는 뜨는데 그 후의 기록은 찾을 수 없다. 철도청 이후의 코레일(2005년 출범)은 이런 실험을 더 진행하지 않는 모양이다. 아예 교외선에 일반열차의 운행 자체가 중단되기도 했고 말이다.

Posted by 사무엘

2012/07/23 08:45 2012/07/23 08:45
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/710

Trackback URL : http://moogi.new21.org/tc/trackback/710

Leave a comment

1.

<날개셋> 한글 입력기는 잘 알다시피 글쇠배열 수준을 넘어서 한글 조합 로직을 완전히 외부에 expose하고 사용자가 이를 입력 옵션의 일부로서 마음대로 고칠 수 있는 유일한 한글 입력 프로그램이다.

한글 조합 로직은 전산학에서 오토마타라고 불리는 '정규 문법'(regular grammar)으로 흔히 모델링되며, 보통은 그 알고리즘이 해당 한글 입력 프로그램의 소스 코드 내부에 복잡한 switch문의 형태로 하드코딩되어 있다. 그러나 <날개셋> 한글 입력기는 그렇지 않으며, 아예 C언어 수식의 문법 형태로 오토마타를 사용자가 일일이 지정이 가능하다.

정규 문법은 옛날에 1996년도 한국 정보 올림피아드 경시부(본인이 그 시절에 정올 공부를 한 세대여서.. ^^)에서 출제되었던 잠수함 코드 식별 문제와 같은 차원의 난이도이다. 주어진 규칙대로 상태를 쭉쭉 switch해 나가다가 코드가 yes로 끝나면 잠수함이고, 그렇지 않으면 noise이다. 한글 입력 오토마타도 그런 수준이라는 뜻이다.

첨언하자면, 이것보다 한 단계 더 복잡한 차원의 문법은 그 이름도 유명한 문맥 자유 문법(CFG)이다. 이제는 다단계의 여닫는 식별 부호를 재귀적으로 처리할 정도가 되어야 하고, 제대로 파싱하기 위해서는 스택이 필요하다. 여기서 스택은 한글 입력 순서를 기억하는 그런 스택이 아니라, 각 재귀 단계별 상태를 기억하기 위한 스택이다. 정규 문법이 Windows의 INI 파일 정도의 복잡도라면, 문맥 자유 문법은 XML 정도 된다고 보면 된다.

전산학 전공자라면 데이터 구조 시간에 복잡한 괄호와 연산자가 들어간 수식을 처리하는 프로그램을 만든 적이 있을 텐데, 그게 바로 간단한 문맥 자유 문법을 인식하는 프로그램을 구현해 본 것이다. 그러나 한글은 초-중-종성으로만 구성되지 '초성-여는 중성-종성-닫는 중성'이라든가, '여는 초성-중성-여는 종성-닫는 종성-닫는 초성' 처럼 글자 자체가 재귀적으로 이상하게 전개되는 형태는 아니므로, CFG가 아닌 정규 문법만으로 표현이 충분히 가능하다.

사람이 다루는 자연어든, 컴파일러가 다루는 프로그래밍 언어 소스가 아니어도, 컴퓨터라는 계산 기계가 인식과 생성과 처리 가능한 모든 파일 포맷은 결국 이런 문법으로 formal하게 생성 규칙을 나타낼 수 있으며 그럴 수밖에 없다. 텍스트 파일이든, 그래픽 포맷이든, 심지어 기계어 코드의 포맷이든 말이다. 그래서 오토마타 이론은 전산학에서 매우 중요하게 다루어진다.

2.

다시 본론으로 돌아와 한글 입력기 얘기를 계속하겠다.
한글 입력기도 구현체가 제각각이기 때문에 프로그램마다 동작 방식이 대동소이한 차이가 있었다. 예를 들어 “중성+종성 형태의 미완성 한글의 입력이 가능한가? 그리고 세벌식의 경우 초성+종성 미완성 한글도 입력 가능한가?” 하는 것 말이다. 오토마타는 바로 이런 세밀한 로직을 바꿀 수 있다.

아래아한글은 도스용 3.x까지만 해도 그런 게 가능하지 않다가 윈도우용으로 넘어오면서 어느 샌가 미완성 한글의 표현이 가능해졌으며, 특히 97 때는 전무후무하게 초-종-중 순의 입력도 가능해서 아주 초보적인 형태의 모아치기까지 지원했었다. 그게 워디안 이후부터는 다시 없어졌지만 말이다.

<날개셋> 한글 입력기는 그런 것들을 구분하기 위해서 일반적인 이어치기 오토마타뿐만이 아니라 미완성 한글의 입력을 불허하는 오토마타도 따로 갖추고 있다.
PC 환경이 도스에서 윈도우로 넘어가면서 한글 코드의 주류도 조합형에서 완성형으로 넘어갔다. 완성형은 구조적으로 낱자의 초성과 종성을 구분하는 게 불가능하고 미완성 한글도 표현할 수 없기 때문에, 한글 입력 오토마타도 그에 맞춰서 설계되는 게 불가피했다.

그런데 맥 OS가 제공하는 한글 입력기는 동작 방식이 흥미롭다. 두벌식은 별 차이가 없는데 MS의 한글 입력기와 큰 차이를 보이는 부분은 세벌식이다.
오토마타가 '미완성 한글을 허용 안 하는 이어치기'의 변종이다. 초성과 중성의 단독 입력은 허용하지만, 종성 단독이나 여타 미완성 한글의 입력은 아예 무시하여 허용하지 않는다. 또한 받침 ㄲ, ㅆ은 ㄱ, ㅅ의 연타로 입력을 못 하고 반드시 한 타로만 쳐야 한다.

입력 무시는 <날개셋> 한글 입력기의 오토마타에서 -1이라는 음수 상태로 정의되어 있으므로 이런 입력 로직도 <날개셋> 한글 입력기로 어렵지 않게 구현할 수 있다.

0 → A ? 1 : B ? 3 : C ? -1 : 0
1 → A ? 1 : B ? 2 : C ? -1 : 0
2 → B ? 2 : C ? 4 : 0
3 → B ? 3 : C ? -1 : 0
4 → C ? 4 : A|B ? 0 : -1

초기 상태에서는 종성 C만 -1로 빠지게 하여 무시하면 된다. 그리고 초성이 입력된 상태인 1번 상태에서도 C만 무시하면 된다.
초성과 중성이 모두 입력된 2번 상태에서만 종성의 입력이 허용되며, 이 경우 오토마타는 4번 상태로 가게 된다.
중성만 단독으로 입력된 상태인 3번에서도 중성만 동일 상태로 받아들이면 되고 종성은 여전히 무시한다. (C ? -1: 0)

끝으로 문제가 되는 건 초-중-종성이 모두 입력된 4번 상태이다. 받침 ㄴ+ㅎ=ㄶ 같은 결합은 계속 허용해야 하지만 더 결합할 수 없는 받침은 입력을 무시해야 한다. 그리고 초성과 중성은 다음 글자로 입력을 받아들인다. 이 상태를 어떻게 표현하면 좋을까?

<날개셋> 한글 입력기는 오토마타로부터 양수 상태값을 얻어서 결합 가능 승인은 받았지만 실제로는 낱자 결합 규칙이 존재하지 않아서 추가 결합이 불가능해진 낱자가 발견될 경우, 성분 변수 A~C에다가 모두 0을 집어넣어서 해당 상태에 대한 오토마타 함수값을 다시 구한다. 그렇기 때문에 C에 값이 있을 때는 일단 4번 상태를 계속 유지하게 하되, 초성이나 중성에 값이 있으면(A|B) 다음 글자로 넘어가서 조합을 진행하게 하고(0), 진짜로 세 변수가 모두 0일 때만 -1로 조합을 무시하게 하면 된다.

요컨대 초성과 중성만 단독 입력이 가능하고 정확하게 초-중-종 순서를 따르지 않은 unexpected 종성은 입력을 무시하게 한 오토마타인데, 이것도 좀 오래 써 보니 오타 방지 차원에서는 나쁘지 않은 것 같다.

3.

이제 오토마타 얘기 말고 다른 기술적인 얘기로 넘어가겠다.
맥 사용자라면 이미 충분히 아시겠지만, 매킨토시 컴퓨터는 별도의 한/영이나 한자 키가 없기 때문에 한/영 전환이 cmd+space이고, 한자 변환은 opt(alt)+enter이다.

다만 약간 불편한 점은, 두벌식이든 세벌식이든 겹받침을 입력하는 방법이 없다는 것이다. 두벌식에서 ㄱ+ㅅ을 누르면 둘은 따로 떨어지며, 세벌식은 아예 겹받침 단독 입력이 불가능하기 때문이다.

초성+한자로 특수문자를 입력하는 기능도 맥에는 없다. 일반 PC에서는 그야말로 도스 시절에서부터 존재한 오랜 전통임에도 불구하고, 맥은 그런 것의 영향을 지금까지 전혀 받지 않은 채 지내 왔다니 놀라울 따름이다. 전/반각 모드 같은 것도 맥에서는 찾을 수 없다.

윈도우에서는 두벌식/세벌식이 한 한글 IME 내부에서의 설정치로 존재해 왔지만 맥은 각각의 벌식이 마치 영문 쿼티/드보락처럼 별개의 입력 방식으로 다뤄진다. 어찌 보면 이게 더 직관적인 디자인인 건지도 모르겠다. 그래서 입력 환경 설정 대화상자에는 글자판을 선택하는 옵션은 없으며 backspace 키의 동작 방식 같은 것만 있다.

Windows는 95 이래로 조합 중인 한글을 깜빡이는 네모 커서로 나타내는 관행을 도스 시절 프로그램으로부터 확실하게 도입하여 정착시켰다. 이 당연한 관행이 3.1때까지만 해도 없었기 때문에, 한글을 조합 중일 때 커서는 그냥 해당 한글의 앞에 똑같은 길쭉한 형태로만 보였다. 당시 윈도우 3.x용 MS 워드 6.0이 예외적으로 IME를 자체 처리하여 네모 커서를 자체 구현하던 수준이었다.

그에 반해 맥은 조합 중인 한글을 그냥 일본어나 중국어의 조합을 표시하듯이 밑줄로 처리한다. 즉, 맥에서는 깜빡이는 네모 커서를 볼 일이 없다는 뜻. 사실, 깜빡이는 네모 커서는 도스 시절 이래로 오랫동안 봐 왔기 때문에 심리적으로 편하기는 하지만, 한글 조합을 두 글자 이상의 길이로 표현하는 가능성을 차단했다는 큰 제약도 존재한다.

그래서 MS 운영체제에서는 전통적으로 한글 조합을 단어 단위로 잡는 기능이 존재한 적이 없다. 한자 입력할 때를 빼면 사실 전/반각만큼이나 별로 필요하지도 않은 것도 사실이긴 하지만 말이다. 그 반면 맥에는 그 옵션이 있다.

이런 점들을 감안하면, 한글 입력 하나를 두고도 맥과 윈도우는 문화가 상당히 다름을 알 수 있다. 차이는 이것으로 그치지 않는다. 오류가 없는 100% 정확한 세벌식 최종 글자판이 윈도우에서는 무려 비스타와 오피스 2007 타임라인에 와서야 겨우 제공된 반면, 맥에서는 공 박사님의 영향력 덕분인지 그야말로 OS X도 아니고 20세기 클래식 시절부터 당연히 기본 제공되어 왔음도 감안할 필요가 있다.

Posted by 사무엘

2012/07/20 19:21 2012/07/20 19:21
, , , , ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/709

Trackback URL : http://moogi.new21.org/tc/trackback/709

Comments List

  1. 사무엘 2012/07/20 20:25 # M/D Reply Permalink

    첨언:
    현재 개발 중인 <날개셋> 한글 입력기 다음 버전(6.7)에서는 오토마타 수식에 주어지는 변수로 A~C, D~F 말고 O도 추가되어, 현재 조합 중인 한글이나 글쇠로 입력된 한글이 두벌식 자모인지를 판별할 수 있게 된다.
    그래서 한 오토마타가 두벌식이냐 세벌식이냐에 따라 다르게 동작할 수 있게 되어, 맥 OS 세벌식과 두벌식 오토마타를 한데 구현이 가능해진다. 특히 복벌식은 세벌식 모드일 때는 모아치기를 지원하면서 두벌식일 때에도 오동작이 없는 오토마타를 만들 수도 있게 된다.

  2. 김 기윤 2012/07/24 00:56 # M/D Reply Permalink

    역시 세벌식 덕후(..)이신 사무엘님께서 맥의 세벌식을 분석할 것이라 생각하고 있었습니다.

    역시 날개셋에서 맥 방식의 세벌식 오토마타 재현도 하셨고!!

    1. 사무엘 2012/07/24 07:23 # M/D Permalink

      헐, 그런 예상까지 이미 하셨다니..
      맥의 한글 입력기가 윈도우의 한글 입력기와 동작 방식이 다른 것에 대해서도 이미 충분히 인지를 하고 있으셨군요. ^^

      요 얼마 전엔 부분적인 모아치기를 지원했던 아래아한글 97의 오토마타도 만들어 봤는데 굉장히 재미있습니다. 생각보다 구조가 간단해서 0부터 2까지 3상태만으로 구현이 됩니다.
      <날개셋> 한글 입력기는 세벌식 중심이긴 하지만 꼭 세벌식이 아니어도 완전 한글 덕후의 장난감 및 마음의 고향을 표방하며 개발되고 있습니다. ㅎㅎ

Leave a comment

수인선 복선 전철 1차 개통!

‘수인선’이라 하면 대한민국 최후의 협궤 철도라고 굳이 철덕이 아니어도 우리나라 역사· 지리· 문화에 약간이나마 관심이 있는 사람이라면 다 알고 있다.
일제 강점기인 1937년에 개통된 수인선은 원래 더 먼저 만들어진 수려선(1930년)과 직결하여 경기도 여주까지 이어졌다. 여주에서 나는 쌀을 인천항으로 수송하여 일본으로 반출하려는 목적이었다.

그러나 대한민국 정부 수립 후엔 쌀을 인천항으로 나를 일이 없어졌고, 도로 교통도 발달하면서 이 장난감 같은 철도는 잉여로 전락하고 말았다. 그래서 수려선은 이미 1972년에 진작에 폐선되어 흔적도 없이 사라졌다. 참고로 현재의 국도 42호선이 수려선과 많이 겹쳤었다. 수원 시내 동쪽에서 수원 역 정문으로 닿는 그 도로가 바로 국도 42호선임.

그리고 수인선도 적자를 감당치 못하여 시간이 흐를수록 운행 구간은 축소되었고, 결국 1995년 12월 31일에 치른 종운식을 끝으로 운행이 중단되었다. (운행 중단이라 쓰고 폐선이라 읽는다 ㄲㄲ)

물론, 운행 중단과 폐선은 엄밀히 보자면 동일한 개념이 아니다. 가령, 서울 교외선은 여객 열차가 다니지 않는 운행 중단 상태이지만 폐선은 아니다. 그에 반해 수인선은 그 뒤로 선로가 관리되지 않고 방치되었으며, 협궤 열차 자체가 한국 철도에서 완전히 맥이 끊김으로써 폐선이나 다름없는 상태로 전락한 것이다.

그 수인선이 폐선된 지 딱 16년 반 만에 1차 구간이 부분적으로나마 표준궤 복선 전철로 부활하여 우리 곁에 돌아왔다. 만세! 개통 날짜도 2012년 6월 30일 토요일인 덕분에 본인은 전날인 29일 금요일에 회사 근무를 마친 후, 미리 시흥으로 답사를 갔다.

본인이 다니는 회사가 있는 곳은 판교이다. 자동차라면 성남에서 안산 내지 시흥으로 가는 경로로 우리의 친구인 외곽 순환 고속도로(고속국도 100호선)가 있지만, 우리나라 대중교통은 서울과 위성도시를 잇는 방사형 노선만 발달해 있을 뿐 위성도시 사이를 잇는 순환형 노선은 인프라가 무척 열악하다. 철도는 그게 더욱 심하다.

그래서 성남 버스 103번을 타고 서쪽으로 간 뒤, 4호선 인덕원 역에서 전철을 쭉 타는 경로를 택했다. 사실 버스가 워낙 느리기 때문에 이건 시간적인 메리트는 별로 없다. 인터넷 지도는 아예 서울 강남(분당선 - 2호선 선릉-사당 - 4호선)까지 매우 심하게 우회하는 지하철 경로를 제시할 정도였는데 차라리 그게 가장 빨리 가는 경로가 맞는 듯했다.

단지 나는 시간적으로 급한 상태가 아니고, 한국학 중앙 연구원 같은 생소한 지대를 구경하고 싶고, 외곽 순환 고속도로가 아닌 다른 길(안양판교로. 지방도 57호선)로 성남-의왕-과천을 횡단해 보고 싶어서 버스를 선택한 것이었다.

새로 개통하는 철도역이나 노선을 개통 당일 첫 차로 답사하러 내가 직접 그 전날에 미리 근처에서 외박까지 하는 건 4년 전(2008년 6월)의 서울 지하철 5호선 마곡 역 개통 방문 이래로 이게 두 번째였다.
전국이 거의 한 달 가까이 이상 고온과 가뭄에 시달리면서 찜통 같은 6월을 보냈는데 이 날 저녁부터 때마침 단비가 땅을 촉촉히 적시고 여행을 한결 더 운치 있게 만들어 줬다.

수인선을 타려면 출발역인 오이도 역 주변에서 대기하는 게 좋다. 하지만 거기 주변은 그냥 닥치고 아파트뿐이고 식당, PC방, 찜질방 같은 상업 시설이 눈에 띄질 않았다. 특히 오이도 역의 동쪽 방면인 3번 출구는 그야말로 잉여 황무지인 걸로 잘 알려져 있다. 오죽했으면 출구 역세권에 대해서 쓸 게 없어서 그냥 ‘동광장’이 끝이다!

그래서 본인은 부득이 그 앞의 정왕 역에서 내려서 거기 근처에서 외박을 했다. 이는 이튿날 실제로 오이도 역 주변을 살펴보니 정말로 현명한 선택이었다. 그래도 오이도 역에서 첫 차는 타야 하니 새벽 4시 무렵에 본인은 우산을 쓰고 어두컴컴한 빗길을 걸으면서 정왕에서 오이도 역으로 도보로 이동했다. 이것도 재미있는 추억이었다.
이런 과정을 거쳐 본인은 5시 30분에 오이도에서 송도로 출발하는 수인선 전동차에 성공적으로 탑승했다.

수인선은 세 단계에 걸쳐 개통될 예정인데, 이번에는 그 중 1단계가 개통한 것이다(오이도-송도). 아직 13km 남짓밖에 안 되는 짧은 구간이지만, 시흥시와 인천 광역시가 어떤 형태로든 철도로 이어지고, 인천 지하철 1호선 원인재 역과 환승이 가능해진 것만으로도 큰 효과가 기대된다. 그 유명한 수인선 소래 철교도 이 구간에 포함되어 있다.

2단계 때는 인천 시내를 좀 더 깊숙이 관통하여 수인선이 드디어 경인선 인천 역과 연결된다. 1단계 구간은 모든 역들이 지상이거나 지상 고가이지만(연수-송도 사이에 잠깐 지하 터널은 지남), 2단계 때는 지하역도 생길 것이고 특히 수인선 인천 역 승강장은 지하에 만들어질 거라고 알려져 있다. 현재 동인천 역에서 회차하는 경인선 급행 전동차는 나중엔 이 지하 인천 역까지 들어오게 될 것으로 보인다.

또한 2단계 구간에 포함돼 있는 용현 역이 개통되면 인하 대학교도 드디어 전철 역세권에 들게 될 것이다. 사실, 이 2단계 구간인 송도-인천은 수인선에서 가장 먼저 폐선된 구간이기도 하다. 무려 1973년이니, 수려선의 폐선과 시기적으로 별 차이도 안 난다.

마지막으로 3단계는 한대앞 역에서 수원 역까지 나머지 잔여 구간이다. 즉, 인천 다음으로 수원과의 연결이다. 여기는 수원 시내만 지하이고 나머지 교외 구간은 응당 지상이나 고가로 만들어질 것으로 보인다. 1995년 말 당시에 최후까지 영업을 하던 수인선 구간은 바로 여기였다.

한대앞-오이도는 복복선이 아니라 기존 안산선과 수인선 열차가 선로를 “공유”하게 된다. 이 구간은 안산선이 의도적으로 수인선과 동일한 선형으로 만들어지기도 했다. 또한 4호선 열차의 절반은 어차피 사당까지밖에 안 가기 때문에 안산선은 선로 용량이 남기도 하고 말이다.

그래서 인천-오이도-한대앞-수원이 연결됨으로써 수인선이 완공되고, 지금 기흥까지 가는 분당선도 수원까지 연장되어 내려오면, 수인선과 분당선은 수도권 남부를 도는 거대한 노란색 광역전철로 변모하게 된다! 이를 염두에 두고 수인선의 노선색은 분당선의 그것과 동일한 노랑으로 설정되어 있다. 마치 광역전철 중앙선과 경의선이 미래의 직결 운행을 염두에 두고 둘 다 옥색을 쓰고 있듯이 말이다.

아마 그때쯤이면 전철 노선도의 토폴로지도 크게 바뀌게 될 것이다. 지금까지 분당선은 동쪽으로 끝나고 안산선은 서쪽으로 끝나는 형태였는데 이젠 이들을 한데 이어 줘야 하기 때문이다.

지금 1단계 개통을 한 수인선은 다른 노선과 직결 운행을 하는 게 없이 오이도-송도만 짤막하게 왔다 갔다 하는 중이다. 6량 1편성이고 전철 중앙선과 비슷한 배차 간격인 15분당 1대 운행이다. 민자 사철이 아니라 전형적인 코레일 광역전철이기 때문에 독자적인 운임을 받는다거나 한 건 없다. 따라서 기존 기본 운임 체계에 따라 마음 놓고 타면 된다.

원래 오이도 역은 쌍섬식 승강장으로 한 섬은 상행, 다른 섬은 하행이 전담하고 있었다. 그러던 것이 수인선이 개통하면서 승강장의 용도가 반씩 분담되어. 한 섬은 안산선, 다른 섬은 수인선 승강장으로 바뀌었다. 시종착역은 플랫폼이 좀 많아야 할 텐데 저런 식으로만 운영해서는 회차 용량의 감소가 우려되긴 하지만, 안산선과 수인선 모두 배차가 최하 10분이 넘는 한적한 노선이고 둘 다 인상선도 있는 형태이니 그리 큰 문제가 되지는 않지 싶다.

수인선 1차 개통 구간의 주변 경치는 공장 아니면 고층 아파트들이다. 남동 인더스 파크는 남동 산업 단지를 쓸데없이 외래어 버프를 씌워서 표기한 것. 우리집에 있는 본드의 제조사인 ‘오공 본드’의 공장이 이 역 근처의 차창 밖에서 보였다.
인천논현 역은 서울 지하철의 논현 역과 헷갈리지 말라고 ‘인천’이라는 접두어가 붙었다. 사랑 침례 교회는 이 역에서 400m 남짓 떨어져 있다.

마치 지금 서울 지하철 6호선과 경의선 전철, 그리고 공항 철도가 공덕-DMC 사이에서 상당 부분 중복 구간이 존재하듯, 수인선과 안산선은 일부 구간을 중복 수준을 넘어서 아예 동일 선로를 공유한다. 하지만 대피선이 설치된 역이 많은 만큼, 수인선이나 오리지널 안산선(4호선) 중 어느 노선의 열차는 안산선 구간에서 표정 속도에 차이를 두어, 급행 형태로 좀 다니면 좋겠다.

본인은 수인선의 복선 전철 부활을 경축하는 바이다. 나머지 구간도 어서 개통하고 분당선-수인선이 경의-중앙선과 짝을 이루는 거대한 광역전철이 되는 날을 꿈꿔 본다. 그리고 안산선 구간과 만날 예정인 소사-원시선과 신안산선도 어서 개통하고 서울 지하철 7호선 연장 구간과 인천 지하철 2호선까지 개통한다면 철도 덕후로서 무진장 행복해질 것 같다. ^^

Posted by 사무엘

2012/07/18 08:17 2012/07/18 08:17
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/708

Trackback URL : http://moogi.new21.org/tc/trackback/708

Comments List

  1. 주의사신 2012/07/18 15:25 # M/D Reply Permalink

    고등학교 때 원어민 선생님과 지하철에 대한 이야기를 한 적이 있었습니다.

    "개인적으로 참 잘 만든 시스템이라고 생각한다"는 답변을 해 주셨던 기억이 나네요.

    그래도 아직 계속 개선해야 할 점이 많은가 봅니다.

    1. 사무엘 2012/07/18 23:45 # M/D Permalink

      우리나라 지하철은 시설 하나는 과잉 투자에 가까울 정도로 정말 짱입니다. 세계 어디에 내놓아도 부끄럽지 않답니다.
      “지하철을 타는 사람들은 복이 있나니 VVVF 구동음 음악을 매일 들을 것이요”

Leave a comment

※ <날개셋> 한글 입력기의 개발자가 알기 쉽게 요약한 우리나라 한글 기계화의 간략한 역사이다.

실용성을 떠나서 어떻게든 모아쓰기 형태의 한글을 찍을 수 있는 타자 기계를 완전히 최초로 만든 사람은 재미 교포 이 원익(1914)이다. 이건 세로쓰기 형태였다.
그 후 1949년에 잘 알다시피 공 병우가 최초의 세벌식 쌍초점 타자기를 발명하고,
1958년에는 김 동훈이 다섯벌식(자음 2, 모음 2, 받침 1) 타자기를 발명했다.

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

동일한 정사각형 공간에 한글을 모아쓰기 형태로 보기 좋게 찍으려면 잘 알다시피 한글 자모의 벌수가 많아져야 한다. 그러나 벌수가 많아질수록 기계 구조가 복잡해지고 치기가 어려워지는 등 타자 능률에는 여러 모로 애로사항이 꽃핀다.

공 병우는 미려한 자형을 과감히 포기하고, 자형은 그냥 알아볼 수만 있는 정도의 빨랫줄 샘물체 형태로 찍히지만 타자 능률 하나는 정말 기가 막히게 좋은 한쪽 극단을 선택하여, 세벌식이라는 글쇠배열 이념을 고안했다. 이때가 이분이 환자의 안과 진료까지 때려치우고 기계 덕질을 하던 시절이다.

세벌식은 외형만 약간 희생하면, 굳이 풀어쓰기까지 안 가고도 한글 역시 영문 뺨칠 정도로 기계로 편하게 칠 수 있는 문자라는 걸 최초로 입증해 보였다. 구조가 간단한 덕분에 한영 겸용 타자기까지 만들 수 있었다.

사용자 삽입 이미지

처음에는 왼손에서 오른손으로 흐르는 배열을 생각했는데, 왼쪽에서 오른쪽으로 종이가 진행되는데 글쇠가 엉키는 현상을 방지하기 위해 지금과 같이 오른손에서 왼손으로 흐르는 배열을 선택하게 되었다고 공 박사 자서전을 찾아보면 나온다. 기계식 타자기를 배제한다면 어느 방향이 더 좋을지에 대한 견해는 여전히 떡밥인 듯하다. R2L은 오른손잡이의 손에 유리한 반면, L2R은 시각적으로 무척 직관적이라는 장점이 있으니 말이다.

이렇게 세벌식 타자기는 성능이 좋은 덕분에, 닥치고 능률이 짱인 군대에서 아주 환영받았다. 뭐, 군대에서도 백 선엽 장군처럼 한글 기계화에 대한 관념이 없이, 여전히 세월아 네월아 한자를 섞어서 손으로 쓴 문서를 좋아하는 지휘관도 없지는 않았지만 말이다.
다만, 세벌식 타자기는 글자 모양이 심하게 보기 안 좋고 이질감이 심했던지라, 민간에서는 김 동훈 다섯벌식도 여전히 공존하여 쓰였다.

기계식 타자기는 몇 벌식으로 만드느냐에 따라서 기계 구조가 완전히 달라져야 했다. 구조가 상이한 한글 타자기가 공존한다는 것은 사회 비용을 증가시키고 손실이 이만저만이 아니었기에 국가가 나서서 통일안을 만들었다.

그래서 다섯벌식과 세벌식을 절충한답시고 1969년 6월에 과학기술처가 내놓은 게 네벌식이다. 개그 만화 일화 씰 사장님의 표현을 빌리자면...

“그래서 너희들은 새로운 글자판을 제정했다. 그것이 이것과 이것과 이것의 네벌식이다.
팔릴까보냐! 세벌식의 능률도, 다섯벌식의 자형도 어느 것 하나 제대로 못 살린 글자판이 되어 버렸지 않나! 더 이상해! 게다가 왜 공청회 없이 졸속으로 후다닥 만든 거냐! 누가 고안한 거냐, 제정 위원들은 글자판 전문가이긴 하냐? 대체 누구냐!”

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
뭐 이랬다.
과거 영국에서는 비숍 성경과 제네바 성경을 통합하는 킹 제임스 성경 표준안이 아주 훌륭하게 정착하였지만, 한국의 타자기 글자판 표준화는 해피엔딩이 되지 못했다.

허나 그때는 때가 박통 시절인지라 표준화는 불도저 식으로 추진되었다. 비표준이 된 세벌식과 다섯벌식은 모두 상당히 무식한 정치적 탄압을 받으면서 시장에서 씨가 마르고 말았다.
세벌식 지지자들이 이를 가는 대목이다. 오늘날 세벌식이 대부분의 사람들에게 듣보잡 글자판으로 전락해 버린 가장 큰 계기가 이것이기 때문이다. 이것으로 시즌 1은 종료.

시즌 2는 컴퓨터와 함께 시작되었다.
1970년대 후반엔 몇몇 선구자들을 중심으로 Apple II PC가 국내에 도입되었으며, 이에 타자기가 아닌 컴퓨터용 한글 입력 방식의 필요성이 논의되었다. 공 병우 박사 역시 당당한 Apple II 사용자였으며 그 후로도 매킨토시만을 애용하였다(오옷.. 1세대 앱등이).

컴퓨터는 전자식으로 동작하니 기계식 타자기를 만들 때와는 달리 여러 벌의 한글 자모를 갖추지 않아도 된다. 영문 글자판과 잘 어울리게 한글 자모를 하나씩만 곱게 집어넣으면 된다.

그 당시의 국내의 컴퓨터 전문가들은 한글을 어떻게 입력하면 좋을지, 한글이 조합 중일 때 시각적인 화면 피드백은 어떻게 만들면 좋을지 같은 것을 면밀히 연구하였고 중국이나 일본에서는 자국 문자 입력을 어떻게 하는지도 적극 벤치마킹했다.

지금은 당연한 개념으로 여겨지고 있지만 오늘날의 컴퓨터용 두벌식 한글 입력 오토마타의 이론적 근간을 처음으로 마련한 분은 KAIST 전산학과의 최 광무 교수이다. 그분의 1978년도 석사 학위 논문 <한글 모아쓰기에 관한 연구>의 요지가 이것이다. “자음과 모음 한 벌씩, 그리고 쌍자음은 Shift로 한 타 만에 바로 입력하게 하면 음절 경계 모호성이 없이 모아 쓴 한글의 연속 입력이 가능하다”는 것.

그렇잖아도 과학기술처는 KAIST에 용역을 주어 컴퓨터용 한글 글자판을 고안하게 했고, 그래서 1982년엔 최 교수의 사상을 기반으로 하여 오늘날의 KS X 5002 두벌식 글쇠배열이 표준으로 자리잡았다. 그냥 자음 모음만 아무 생각 없이 한 벌씩 배치하면, 요즘 천지인 같은 일부 모바일 한글 입력 방식이 그러하듯이 음절 경계 모호성이 존재하게 된다.

이 두벌식 배열은 타자기용 네벌식 배열보다야 구조가 훨씬 더 간단하고 배우기 쉬웠다. 왼손은 자음이나 오른손은 모음이니 언뜻 보기에 얼마나 직관적인가? 숫자와 기호가 영문 글자판과 완전히 일치하며, 딱 알파벳 26개 자리에만 한글 자모가 들어있다.

하지만 초중종성 세 벌로 이뤄진 문자를 두 벌의 글자판만으로 치려다 보니 필연적으로 타자 도중에 원하지 않는 글자가 생기는 도깨비불 현상을 피할 수 없었고, 또 타자기와 컴퓨터의 치는 방식이 서로 다르다는 큰 문제도 있었다. 예전에는 타자기에서 세벌식과 다섯벌식 때문에 사용자가 헷갈렸다면 이제는 타자기의 네벌식과 컴퓨터의 두벌식 때문에 혼동이 생긴 것이다.

이 때문에 5공 시절이던 1983년에는 타자기용 네벌식 글자판이 공식적으로 폐기되었고 역사 속으로 사라졌다. 네벌식을 웬수처럼 여기고 있던 세벌식 진영의 사람들도 이 순간만은 기뻐했다. 이제는 표준 글자판이 좀 개선되려나?

그러나 현실은 나아진 게 없었다. 컴퓨터용 글자판은 변함없이 두벌식이고, 타자기는 새로운 후속 표준이 정식으로 제정되는 게 없이 그냥 컴퓨터처럼 어중간한 두벌식으로 바뀌어 버렸다. 타자기에는 컴퓨터 같은 한글 입력 오토마타 장치가 없으니 그 대신 새로 무엇이 추가되었냐 하면 '받침' 키 신공이다. 여기서 또 씰 사장님의 절규 추가.

“그래서 너희들이 새로 만든 것이 이것과 이것과 이것의 두벌식 타자기이다.
무섭다구! 받침을 입력할 때마다 Shift를 눌러야 하는 기형 타자기를 도대체 누가 쓴단 말이냐! 이 기계로 타자를 해야 하는 타자수의 얼굴이 기분 나빠!”

사용자 삽입 이미지
아마 그 당시 높으신 분들은, 어차피 글자판은 이 지경이 돼 버렸고 이제 대세는 타자기에서 컴퓨터로 넘어가고 있으니 타자기는 이 참에 완전히 손을 놔 버린 모양이다. 그래서 실제로 한글 타자기는 컴퓨터와 비교했을 때 단순히 기계적인 기능의 차이 때문이 아니라, 글자판과 입력 방식 차원에서의 원론적이고 구조적인 차이로 인해 컴퓨터의 적수가 될 수 없어서 급속도로 몰락하고 말았다. 이것으로 시즌 2 종료.

오늘날 컴퓨터에서는 표준이 된 두벌식, 그리고 한글 구성 원리와 일치하는 세벌식만이 남아 있고 그보다 더 복잡한 벌수의 입력 방식은 완전히 역사 속으로 사라져 있다. 세벌식은 도깨비불 현상이 없고 타자 능률이 매우 좋다는 점, 그리고 기계간의 글자판 통일이 가능하다는 점이 두벌식이 흉내도 낼 수 없는 압도적인 장점이기 때문에, 한글이 남아 있는 한 절대로 없어지지는 않을 것이다. 비록 글쇠 수가 좀 많고 기호가 영문 자판과 다른 게 단점이긴 하지만 말이다.

하지만 처음부터 타자기와 컴퓨터가 모두 속 시원하게 똑같이 세벌식으로 갔으면 글자판 통일은 진작에 이뤄졌을 것이며, 타자기도 온갖 n벌식 입력 방식에 이리 저리 휘둘리다가 망하는 일이 없었을 것이다. 타자기도 자기가 할 수 있는 본분은 다 수행하면서 실제보다 더욱 늦게 현역에서 물러났을 것이다.

참으로 아쉬운 대목이 아닐 수 없다. 세상에 기계식 타자기로 저 정도로 칠 수 있는 문자가 라틴 알파벳 계열을 빼고 전세계에 얼마나 될까? 그런데도 고작 네모 글꼴 하나 건지려고 벌수 놀이를 한 것치고는 감수해야 한 사회적 손실과 치러야 한 대가가 너무 컸다. 기술이 발달하면 세벌식 타자기의 빨랫줄 모양 글꼴도 그 방향을 유지하면서 얼마든지 더 미려하게 개선할 수 있었을 텐데 말이다.

세벌식이 확고하게 타자기와 PC의 주 입력 방식으로 자리잡았다면, 두벌식은 세벌식을 적용하기에는 글쇠 수가 충분치 않고, 어차피 기계식 타자기와의 연결 고리가 없으며 장시간 빠르게 입력을 할 필요도 없는 기기를 위한 제한적이고 예외적인 변칙 입력 방식으로 추후에 논의되게 되었을 것이다.

요 얼마 전엔 드디어 모바일용 한글 입력 방식으로 천지인과 이지한글(나랏글), SKY 세 종류가 복수 표준으로 지정되었다. 기계식 타자기의 글쇠배열과는 상황이 달라도 너무 다르다. 어차피 한글 입력은 소프트웨어적으로 처리되기 때문에 무슨 입력 방식을 심든 물리적인 비용이 드는 게 없으며, 어차피 어느 입력 방식이든 두벌식 안에서 그 나물에 그 밥이기 때문에 성능 격차도 예전 같지 않다. 그러니 그냥 압도적으로 많이 쓰이는 기존 입력 방식 몇 개만을 그대로 인정해 주는 것만으로도 충분했다.

요즘은 한글날도 20여 년 만에 다시 공휴일로 되돌리려는 움직임이 있는데, 세벌식의 표준화에 “too late”는 있을 수 없다고 본다. 장기적으로는 390과 최종을 통합하는 글쇠배열이 있어야 할 것이고, 표준화는 언제든지 논의되어야 한다. 다시 강조하지만 한글은 두벌식으로만 쓰기엔 너무 아까운 문자이고, 세벌식의 압도적이고 상징적인 장점은 절대로 없어지거나 희석되지 않을 것이기 때문이다..

여담이다만, 아마 공 병우 박사님이 2010년대까지 살아 계셨다면, 맨날 아이폰으로 트위터 하면서 한글날 공휴일 지정과 세벌식 표준화를 주장하는 트윗을 남기고 젊은이들과 얘기를 나누셨을 것 같다. 비록 타자기/PC에서만치 세벌식을 강경하게 주장하지는 않을지라도 모바일용 한글 입력 방식을 연구하는 건 당연지사이고..;;

사용자 삽입 이미지
공 병우 박사(1907~1995). 안과 의사에다 불세출의 한글 공학자까지 인증..;; 하나만 제대로 하기도 무진장 힘들 텐데, 머리가 너무 좋고 시대를 너무 앞서갔던 분이다..;;

Posted by 사무엘

2012/07/15 08:29 2012/07/15 08:29
, , , , , ,
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/707

Trackback URL : http://moogi.new21.org/tc/trackback/707

Comments List

  1. 주의사신 2012/07/15 15:32 # M/D Reply Permalink

    세 번째 사진의 공병우 선생님 타자기가 스펀지에서 쳐 보셨던 그 타자기인가요?

    1. 사무엘 2012/07/15 23:10 # M/D Permalink

      K 자리에 ㄱ 대신 ㄷ, R 자리에 ㅐ 대신 ㅣ 이 있는 것까지는 일치하지만, 제가 쳤던 타자기와 정확하게 같은 배열은 아니네요.
      참고로 공 박사님의 생전엔 글쇠배열 개정이 무척 잦은 편이었습니다.

  2. LynTohno 2012/07/16 00:09 # M/D Reply Permalink

    http://newsis.com/magazine/view.htm?cID=11210&ar_id=NISX20091026_0003517398

    방금 본 기사인데...

    아래아 발음을 들어볼 방법 없을까요? 어떤 소리인질 모르겠네 ㅡ.ㅡ;

    1. 사무엘 2012/07/16 10:20 # M/D Permalink

      제 기억이 맞다면, 국어사를 연구하는 학자들 사이에서는 아래아의 정확한 음가는 '모른다'가 정설이었습니다. 다들 워낙 제각각의 주장을 해서 말이에요.

      아래아의 실제 음가는 이미 몇백 년 전에 소실되어서 ㅏ나 ㅡ로 역할이 흡수되었고, 글자는 진작부터 캐잉여로 전락해 있었습니다. 그걸 일제 강점기 때 조선어 학회가 한글 맞춤법 통일안을 제정하는 과정(사전을 만들기 위해)에서 잉여 옛글자를 정리했는데, 이때 아래아도 퇴출된 것입니다.

      아래아의 음가는 그렇다 치더라도, 조선 총독부가 한글 맞춤법에 무슨 관여를 해서 특정 자모를 없애기라도 했다는 건 사실이 아닙니다.

    2. Lyn 2012/07/16 17:51 # M/D Permalink

      그렇군요 ...

      사실상 들을 방법도 없는거군요 ㅠ.ㅠ
      하긴 언어가 초창기에 비해 많이 바겼다곤 들었지만... 없어진 발음(특히 받힘)이 태반이고 소리랑 글자의 불일지도 심각한 상황이고 ...

  3. Paul Sohn 2012/07/17 15:00 # M/D Reply Permalink

    '이 기계로 타자를 쳐야 하는 타자수의 얼굴이 기분 나빠!' ㅠㅠ

    통합안이라면 아마 팥알님의 3-2011 자판이 있을 것도 같습니다만, 제가 보기에는 무리한 절충안은 또 다시 양측의 반발만 사지 않을까 싶기도 합니다. 결국 이상글쇠 상태방정식은 또다시 미궁 속으로.

    1. 사무엘 2012/07/17 19:08 # M/D Permalink

      저야 개인적으로 최종 매니아이긴 합니다만, 너무 잉여력이 강한 겹받침과 더불어 모바일 시대에 맞지 않는 기호 배치 같은 사소한 문제가 있습니다. 아무래도 최종과 390 중에서는 390에 더 가까운 절충안이 나와야 하지 않을까 싶습니다.
      팥알 님의 글자판은 굉장히 훌륭한 작품이죠.

  4. 팥알 2012/07/18 00:12 # M/D Reply Permalink

    Paul Sohn님의 '이상글쇠 상태방정식'에 뿜었고, 사무엘님 말씀에 쑥스러워지네요.^^

    언젠가 사무엘님이 세벌 자판을 입체 교차로에 빗대셨는데, 저는 두 개씩 있는 겹홀소리 글쇠에서 그 뜻을 찾았습니다. 아쉬운 데가 조금 있는 3-90 자판과 3-91 최종 자판이지만, 군더더기 같은 요소에 업무 능률을 끌어올릴 만한 포석이 깔려 있음을 알고 감탄했습니다. 저도 두 세기(?)에 걸쳐 최종 자판을 썼는데, 왜 몇 달 전에야 그걸 깨달았는지 아쉽습니다.

    저는 공병우 자판이 더 사랑 받으려면 다른 자판으로 해내기 어려운 기능을 내세워야 한다고 생각합니다. 흔한 한글 넣기는 사람들에게 두벌식이든 세벌식이든 차이가 와닿지 않을 수 있습니다. 하지만 옛한글을 넣을 때는 공병우 자판이 아닌 것을 쓰기가 너무 끔찍합니다. 옛한글 넣기에서의 장점을 강조한다면 공병우 자판을 표준으로 밀고자 할 때에도 승산이 설 거라고 봅니다. 타자기 쓰던 때의 틀에서 벗어나, 배열에 제한을 두지 않고 옛한글이나 그림말(이모티콘) 따위를 넣는 타자 대회를 열어 보는 것도 공병우 자판의 강점을 알리는 길이 될 것 같습니다.

    1. 사무엘 2012/07/18 23:42 # M/D Permalink

      좋은 의견에 감사합니다.
      아무래도 세벌식이야 걸기적거리는 게 없이 병렬화=_= 입력에 유리하니 개념적으로 신호 대기 없는 입체 교차로에 잘 대응하겠죠.
      옛한글의 경우 자모 글쇠가 더 많이 필요해지는데, 두벌식은 굳이 장점을 찾자면 글쇠를 추가하기가 더 유리한 반면, 세벌식은 음절 구분에서 명백한 우위를 차지하고 있습니다.

      제 학위 논문에서도 역시 글쇠배열에 관계없이 세벌식의 원론적인 장점을 내세우는 방법을 고민했습니다만, 그게 훗날 제 논문을 읽게 될 사람들에게 잘 와 닿길 바랄 뿐이네요. ^^

    2. Paul Sohn 2012/07/19 15:44 # M/D Permalink

      글자판 설계에서도 PV=nRT처럼 딱딱 떨어지는 공식이라도 뭐 하나 나왔으면 좋겠습니다ㅠ.ㅠ

    3. 팥알 2012/07/20 08:56 # M/D Permalink

      딱 떨어지지는 않고 좀 복잡하지만, 영문 자판의 글쇠 배열을 평가할 때에 공식을 만들어 쓰는 걸 봤습니다.
      한글 자판도 어떻게 점수(또는 벌점)를 더해 갈지 가닥만 잡는다면, 타자 행동 분석기를 써서 여러 자판들의 평가해 볼 수 있을 것 같습니다.
      다만 연구한 사람에 따라 다른 식이 나올 수 있겠네요. 위아랫줄 오가기, 같은 손가락 쓰기, 제자리 치기 따위에 대하여 사람마다 겪은 바가 다르고 느끼는 바도 다를 테니 말이지요.

  5. Lyn 2012/07/19 18:41 # M/D Reply Permalink

    양자역학에 접목시켜보는건 어떨까요...

    우린 궁극의 키배열이 무엇인지 모른다는것을 알았다(....) 라던가;;

Leave a comment

성경 목록가의 멜로디 외

창세기 출애굽기 레~위기, 민수기 신명기 여호수아 ...
교회 다니는 분이라면 신구약 성경 목록가 다들 아시죠? 그런데 이 노래 멜로디의 origin이
1900년에 작곡된 일본 <철도 창가>라는 사실, 아십니까?
에, 그러니까 육당 최 남선이 지은 <경부 철도가> 같은 그런 노래입니다.

일본에 가면 심지어 전동차의 발차 경보음으로도 이 곡의 멜로디가 나옵니다.
철도와 성경 사이의 완벽한 연결 고리를 발견하여 대단히 기쁩니다.

저 곡 멜로디를 이용해서 경부선 역 목록가나 지하철 노선 목록가를 만들어 보면 어떨까 싶습니다.

자, 이것만 실으면 분량이 너무 적으니 아래 사진은 보너스.
사용자 삽입 이미지
지난 2010년 12월 21일, 경춘선에 복선 전철화 공사가 끝나고 무궁화호 대신 통근형 전동차가 첫 운행되기 시작했을 때의 모습입니다.
얼마나 철도를 사랑하고 철도 개통에 감격했으면 저러기까지 할까요? 진정한 철덕의 기상이란 게 무엇인지를 보고 도전을 받게 됩니다.

Posted by 사무엘

2012/07/12 19:21 2012/07/12 19:21
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/706

Trackback URL : http://moogi.new21.org/tc/trackback/706

Comments List

  1. Paul Sohn 2012/07/13 06:26 # M/D Reply Permalink

    무섭고 위험합니다

    1. 사무엘 2012/07/13 10:09 # M/D Permalink

      아니, 이미 알 거 다 아는 친구가 뭔 호들갑이여..? ㅎㅎ

    2. Paul Sohn 2012/07/13 15:20 # M/D Permalink

      파트 1만 22절이나 있다는 것을 확인했을 때 더 그러하였습니다

Leave a comment

오늘날 PC에서 명맥을 유지하며 살아있는 데스크톱용 운영체제는 역시나 윈도우, 맥, 리눅스 3관왕이다. 다만 이들이 대등한 점유율이 절대 아니며, 셋의 점유율은 공비가 무려 10에 육박하는 등비수열을 이룬다.

맥이야 x86 계열 CPU로 갈아타고 기계의 가격도 내리면서, 옛날에 비해서야 정말 많이 대중화가 되었다. 또한 아이폰/아이패드가 모바일에서 워낙 큰 성공을 거둔 덕분에 맥북/아이맥까지 반사 이익을 보고 있기도 하다. 아이폰/아이패드에서 돌아가는 소프트웨어를 만들려면 결국 그 계열의 PC가 필요하니까 말이다.

그래도 윈도우에 비하면야 맥 사용자는 정말 10% 이내의 소수이다. 맥OS를 작정하고 써 볼 의향이 있는 게 아니라면, 맥 계열 기계는 비슷한 사양의 일반 컴퓨터보다 여전히 비싸며 구입 후에 서비스도 구리고 키보드· 마우스의 일부 동작 방식이 이질적이기 때문에 덥석 권할 게 못 된다. 솔직히 나도 지금의 맥북 살 돈으로 일반 노트북을 샀다면 아마 화면이 두 배 정도 더 큰 걸 살 수 있었지 싶다. 그러나 ‘스잡빠’, ‘앱등이’로 대표되는 굳건한 추종자도 있는 마당에, 이쪽 진영은 결코 없어지지는 않을 것이다.

맥은 소수이지만 인지도라도 있지 리눅스는 그조차도 없다. 리눅스를 서버도 아닌 데스크톱 로컬 환경의 주 운영체제로 쓰는 사람은 가히 소수 중의 소수이다. 작정하고 MS 진영을 반대하고 철저한 copyleft 정신으로 무장한 컴덕후 해커이거나, 잡스를 숭배하는 것처럼 리처드 스톨먼을 숭배하는(최소한 그의 인격이 아니면 그의 이념을) 사람 정도만이 리눅스를 쓰지 않을까 싶다.

물론, 맥이 예전보다 접근성이 개선된 것만큼이나 리눅스도 옛날에 비해서는 초보자가 쓰기 정말 편해지긴 했다. 하지만 그래도 초보자가 쓰기엔 리눅스는 인지도 있는 응용 프로그램이 부족하고, 뭘 세팅하고 바꾸려면 유닉스 명령줄을 다뤄야 하는 등 생소한 면모가 적지 않다.

사용자 삽입 이미지
(연구 목적으로 2010년 무렵에 VM을 만들어서 돌려 본 우분투 리눅스 9.x의 화면이다. 한때 리눅스의 그래픽 셸은 GNOME이냐 KDE냐로 갈라져 혼란스러운 편이었으나, 요즘은 결국 둘 다 지원하는 쪽으로 가는 추세라 한다.)

20년이 넘게 도스와 윈도우에만 길들여지고 10년이 넘게 윈도우 프로그래밍만 해 본 본인의 입장에서 맥 OS에 존재하는 주목할 만한 특징을 간추려 보면 다음과 같다.

가장 먼저, 운영체제의 시스템 메뉴와 응용 프로그램의 메뉴가 한데 완전히 통합되어 있다는 점이 매우 인상적이다.
Windows는 운영체제의 시스템 메뉴에 해당하는 시작 메뉴가 task bar에 있다. 이것은 응용 프로그램의 창에 소속된 메뉴하고는 당연히 완전히 별개이다. CreateWindowEx 함수는 창을 생성할 때 메뉴 핸들도 별개로 받는다.

그러나 맥은 화면 상단에 항상 고정되어 있는 시스템 메뉴에 응용 프로그램의 메뉴가 얹힌 형태로 나타난다. 이런 건 윈도우에서는 OLE 개체 embedding 상태에서나 어렴풋이 볼 수 있는 모습이다.

사용자 삽입 이미지
(제목은 워드패드인데 도움말에 나와 있는 건 그림판. 어?)

응용 프로그램 메뉴는 파일이나 도움말 같은 기본적인 것만 남고, 그 사이엔 개체를 제공하는 프로그램의 메뉴가 뜨는 것 말이다. 요즘은 이런 디자인도 과거 유물로 치부되어 별도의 프로그램 창이 따로 뜨는 형태로 바뀌고 있지만. (MS부터가 자기네들이 만든 표준 메뉴 인터페이스를 구닥다리로 치부하고 안 쓰려 하니 말이다)

맥에서는 시스템 전체를 통틀어 pull-down 메뉴는 하나만 있으며, 한 순간에 현재 활성화되어 있는 프로그램의 메뉴 하나만 볼 수 있다. 문서 창에 메뉴가 따로 달려 있지 않다. 그리고 맥에서 돌아가는 GUI 응용 프로그램이라면 반드시 이런 디자인을 따라야만 한다.

윈도우에서는 대화상자 하나만 달랑 띄우고 따로 메뉴를 만들기는 곤란한 프로그램의 경우, 대화상자의 시스템 메뉴를 customize해서 보통 ‘이동 / 닫기’만 있는 그 메뉴에다가 About이라든가 Always on top 같은 추가 명령을 넣는 경우가 있다. 그러나 맥은 어떤 프로그램에게라도 무조건 기본 메뉴가 주어지니 그런 식의 테크닉이 존재하지 않는다.

맥은 그런 기본적인 인터페이스가 모든 응용 프로그램에서 무조건 동일하기 때문에 윈도우처럼 무슨 오피스 200x 스타일 메뉴나 도구모음줄을 만들어 주는 GUI 툴킷이라는 게 존재하지 않는다. 윈도우에서야 보급 메뉴 대신에 그 자리에다 싸제 메뉴 창을 얹어서 보급 메뉴처럼 동작하게만 만들면 custom UI를 손쉽게 만들 수 있지만, 맥은 그렇게 할 수 없으니 말이다.

비주얼 C++의 MFC 프로젝트 마법사를 보면, GUI 응용 프로그램을 전통적으로 MDI, SDI, 대화상자라는 세 형태로 분류한다. 그런데 맥에서는 어떤 형태의 프로그램도 일단은 가장 범용적인 MDI에서 시작한다고 볼 수 있다. 실제로 문서 창은 하나밖에 생성하지 않는 프로그램이라 할지라도 말이다. ‘<날개셋> 타자연습’을 맥용으로 만든다면, 프로퍼티 페이지의 밖에 존재하는 ‘사용자 로그인’이나 ‘종합 환경설정’ 같은 명령은 응당 메뉴에서 내리는 명령으로 바뀌어야 할 것이다.

또한 맥은 동일 프로그램의 중복 실행에 대한 개념이 Windows와는 다르다. 같은 프로그램은 한 번만 실행되고 그 동일한 프로그램이 여러 문서를 담당한다는 MDI 사고방식이 맥은 더욱 엄격하다. 그래서 맥 OS의 task bar에 해당하는 dock은 프로그램이 실행됐냐 안 됐냐의 여부만 표시되어 있지만, 이 아이디어를 차용한 윈도우 7의 task bar는 프로그램의 중복 실행 개수도 살짝 표시하고 있는 것이다.

이런 디자인 때문에, 맥에서 프로젝트 단위로 문서를 다루는 프로그램은 내부 구조가 많이 복잡해진다. 개발툴이 그런 예 중 하나이다. 비주얼 C++이야 여러 개를 실행해서 제각기 프로젝트를 열면 되지만, xcode는 프로젝트별로 각각의 문서창을 차지하고 있으면서 그 내부에서 또 파일을 편집하는 창을 관리해야 한다.

맥 응용 프로그램은 마지막 문서 창이 닫혀서 문서가 하나도 없는 상태에서 키보드 포커스가 다른 프로그램으로 넘어갈 때 자동으로 종료되는 편이다. 이런 동작 방식은 Windows에서는 볼 수 없던 모습이다.
물론 모든 프로그램이 그러는 건 아니다. 대표적으로 Finder도 파일 표시(윈도우로 치면 탐색기 창 같은) 창이 하나도 없이 포커스가 바뀌더라도 종료되지 않고 언제나 실행되어 있는다. 내장 웹브라우저인 사파리도 마찬가지이다.

키보드로는 Alt+F4에 해당하는 Cmd+Q를 누르면 언제나 프로그램이 종료된다. 단, 윈도우의 Alt+F4는 그냥 창을 닫는다는 보편적인 용도도 포함하는 단축키인 반면, Cmd+Q는 언제 어디서나 해당 응용 프로그램을 완전히 종료시킨다는 의미 차이가 있다.

윈도우 프로그래머라면, 맥에서는 저런 것뿐만이 아니라 응용 프로그램의 파일 구성까지 상상도 못 할 정도로 다르다는 사실에 더욱 놀라게 될 것이다. 단순 실행 파일 말고 GUI 응용 프로그램은 아이콘, 리소스, 구성 파일이 한데 담긴 패키지 형태로 배포된다. 파일 시스템상으로는 디렉터리 구조이지만 운영체제 내부에서는 가상적인 단일 패키지 파일로 취급된다.

맥에서는 그럼 레지스트리가 없으면 응용 프로그램의 설정 저장을 위해 어떤 기법을 쓰는지? 프로그램 추가/제거는 어떻게 하는지? 동일 개발자가 만든 여러 프로그램이 동일 코드를 공유하려면 DLL 같은 건 어느 디렉터리에다 집어넣으면 되는지? 맥은 윈도우 같은 32/64비트 코드 혼용 문제는 없는지?

알고 싶은 게 한두 가지가 아닌데 그런 걸 윈도우 프로그래머의 입장에서 잘 설명해 놓은 인터넷 사이트나 책은 아직까지는 난 못 봤다. 아무래도 둘은 서로 달라도 너무 달라서 두 플랫폼의 사고방식에 모두 완전히 통달한 개발자는 거의 없으리라 예상된다.;;

이렇듯, 그토록 쉽게 다가설 수 없는 이질감에도 불구하고, 맥 OS는 좀 써 보면 윈도우에서는 느낄 수 없는 참을 수 없는 고급스러움, 미적 감각이 느껴지는 건 부인할 수 없다. 맥 같은 녀석이 존재함으로써 IT 세계가 좀 더 다양해지고 MS의 독점을 약간이나마 견제하는 효과가 난 건 인류 전체의 관점에서는 그래도 이익이긴 한 것 같다.

Posted by 사무엘

2012/07/10 08:11 2012/07/10 08:11
, , ,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/705

Trackback URL : http://moogi.new21.org/tc/trackback/705

Comments List

  1. 주의사신 2012/07/10 09:30 # M/D Reply Permalink

    1. MS가 PC 점유율을 이용해 광고 몇 번 해서 맥을 완전히 죽일 수 있지만 그렇게 하지 않는 이유는 그냥 놔 두는 것이 독점 법망을 피하는데 좋기 때문이라고 주장하는 사람도 봤습니다...

    2. Mac같은 경우에는 UNIX가 밑에 있습니다. 다만 폴더 이름도 다 바꾸고 해서 UNIX가 밑에 있음을 알아 차리기 어렵게 되어 있지요.

    그래서 Windows보다는 작업 자동화하기가 더 낫다고 합니다.

    1. 사무엘 2012/07/10 10:33 # M/D Permalink

      1. 예전에 미국에 지금 같은 독점 금지법이 생기기 전엔, 지금의 MS보다 더 크고 더 돈 많고 더 독점 횡포를 부리는 기업도 있었지요. (그 이름도 유명한 록펠러 아저씨의 스탠더드 오일이라든가...)

      2. 그래서 텍스트 파일에서 줄 바꿈 문자 \r 관행도 사실상 없어졌지요. 이제는 맥도 유닉스처럼 \n을 쓰니까요.

      3. 본문에서는 언급을 안 했는데, 맥은 UI 디자인에서 '취소'라는 개념이 윈도우보다 덜한 것 같습니다. 대화상자에서 설정을 바꾼 건 대부분 곧바로 적용되어 효과가 나타나 버리며, 철회가 되지 않는 편이더군요.

      그러고 보니 맥OS에 대해서 글을 쓰면서 정작 맥OS 스크린샷은 한 장도 안 집어넣었습니다. 재부팅하기 귀찮아서 빼먹은 것입니다. =_=

  2. dlunch 2012/07/10 21:17 # M/D Reply Permalink

    1. 프로그램 설정은 홈 폴더의 Library/Preference에 보통 저장합니다.
    2. 프로그램은 App Store 설치, 압축파일을 통하여 /Application이나 ~/Application에 .app를 통째로 복사하여 설치하는 방식, 설치 패키지를 통하여 설치하는 방식이 있습니다.
    3. dll같은 공용 라이브러리는 보통 Framework라는 개념으로 설치됩니다
    4. 32/64bit 문제는 한 바이너리에 32/64bit 코드를 모두 집어넣는 방식으로 해결합니다. Universal binary라고 불릴 겁니다.

    1. 사무엘 2012/07/11 09:44 # M/D Permalink

      오옷, 도움 주셔서 대단히 고맙습니다. ^^
      universal binary는 x86과 파워피씨 공용 포맷인 줄 알았는데 x86 안에서도 32/64비트를 모두 포함할 수 있는 포맷인가 봅니다?

  3. 김진 2012/07/12 22:17 # M/D Reply Permalink

    맥은 써 본 적이 없는데 윗분 말씀을 들어 보니 윈도보다는 유닉스에 가깝지만 또 다르네요. 혹시 리눅스 환경에 관심이 생기시면 beginning linux programming 같은 책을 보시면 기본적인 개념을 잡으실 수 있을 겁니다. 맥쪽에도 이런 책이 있지 않을까 싶네요

    1. 사무엘 2012/07/13 10:10 # M/D Permalink

      그렇습니다. 윈도우보다야 유닉스에 더 가깝긴 하지만 다른 점도 적지 않습니다.
      맥OS가 설치된 디스크 볼륨엔 bin, dev, usr 등의 유닉스 고유 디렉터리도 있지만, 그건 형식에 불과하며 실제로 새로운 파일들은 맥OS의 고유 디렉터리에 주로 설치된다고 그러다군요.

      말씀하신 그 유명한 책은 저도 좀 옛날 에디션의 PDF를 구해서 틈틈이 보고는 있습니다. vi(m) 에디터를 단축키만으로 현란하게 다루고 셸 스크립트를 자유자재로 구사하는 건 제게는 완전 별나라 얘기여서 말이죠.
      자랑은 아닙니다만, 윈도우 플랫폼에서 이 정도로 프로그래밍을 할 줄 알면서(날개셋을 혼자 다 만듦) 유닉스/맥은 이 정도로 무경험인 사람은 흔치 않을 겁니다. ^^ 하지만 결국 자기가 동기 부여를 받고 필요를 느끼는 분야만 공부하다 보면 그렇게 되지 말라는 법도 없는 거겠죠?

  4. tolkien 2012/07/14 23:42 # M/D Reply Permalink

    어쩌다보니 그 세가지 환경을 다 쓰고 있습니다.
    linux는 개발을 주로 쓰고, 가끔 office쪽으로.
    windows는 outlook + office (회사 server가 outlook... + 기본OS)
    mac은 개발, email + office, 가끔 취미.

    각각의 UI는 고유의 철학을 가지고 있고, 그것을 알고 쓰면 그렇게까지 이해못할 것은 아닙니다.
    mac의 답답함이야, BSD나 debian쪽의 엄격함에 비한다면야... 그리고, 그래서인지 간단한 것을 짜는 것은 비교적 쉬운 편이라고 생각합니다. (선택할 것이 많지 않죠.)

    1. 사무엘 2012/07/15 09:09 # M/D Permalink

      오옷, 그렇군요.
      단순히 쓰는 것 이상으로, 그리고 콘솔 프로그램 이상으로
      세 환경에서 모두 운영체제들의 고유 API 기반으로 GUI 애플리케이션을 만들 줄 아는 사람은 얼마나 될까요? (qt 같은 공용 프레임워크를 쓰는 것도 아니고요.)

      PC는 몰라도 모바일 환경을 아이폰과 안드로이드, 윈도우 모바일을 한꺼번에 다룰 줄 아는 개발자는 몸값이 상당히 비쌀 것 같습니다. ^^

  5. Lyn 2012/07/15 22:28 # M/D Reply Permalink

    의외로 모바일은 3개 다 다루는사람이 흔해요. 데스크탑이 거의 없지...(라기보단 사실 맥이나 리눅스용으로 만들일이 없으니 =_=;;;)

    일단 셋다 이전의 OS에서 벗어나서 새로운 툴킷을 가지고 갔는데 이게 다 비슷비슷하고 ...
    셋다 모바일이라는 특성상 OS에서 제공하는게 뻔하고 할수잇는게 별로 없어서 (...) 보통 2개(안드로이드, 아이폰) 은 기본으로 다루고 좀 더 신경쓰는 사람은 윈폰까지 다룬다는

    1. 사무엘 2012/07/15 23:10 # M/D Permalink

      네, 그렇습니다. PC는 여러 플랫폼을 동시에 지원해야 할 일 자체가 모바일보다 드뭅니다.

Leave a comment

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2012/07   »
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 31        

Site Stats

Total hits:
162529
Today:
24
Yesterday:
206