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

* 지금으로부터 무려 4년 전에 Windows 공용 컨트롤에 대해서 글을 쓴 적이 있었는데 오늘은 그에 대한 연장선이다. 또 옛날 이야기를 늘어놓아 보겠다.

예전에도 글을 썼듯이, 공용 컨트롤은 좀 더 새끈한 UI를 제공하기 위해, Windows 1.0 이래로 기본 제공되던 시스템 컨트롤에 추가적으로 도입된 컨트롤들이다.
사용 전에 InitCommonControls 함수 호출이 필요하다지만, 요즘은 공용 컨트롤 (6.0) 매니페스트를 지정하는 것만으로도 초기화가 자동으로 되기 때문에 EXE에서는 이 절차가 굳이 필요하지 않다.

공용 컨트롤들은 완전히 새로운 기능이라기보다는 Windows의 특정 응용 프로그램이나 Office에서 내부적으로 자체 구현으로 돌리던 싸제 컨트롤이 보급품으로 바뀌는 경우가 많다.
이들은 16비트 시절을 경험한 적이 없고 Windows 95/NT 3.51과 역사를 같이하기 때문에, '32비트'를 강조하기 위해 클래스들의 이름이 대부분 32로 끝난다는 특징이 있다. ListView, TreeView 같은 것들은 이런 1기 공용 컨트롤이다.

그 뒤 Internet Explorer 3 이후로 공용 컨트롤은 IE의 버전업을 따라 비약적으로 발전하기 시작했다. 달력 컨트롤, 날짜 선택 컨트롤, ReBar 같은 건 운영체제 보급 컨트롤이라기보다는 뭔가 델파이 컴포넌트 같은 느낌이 드는데.. 이것들은 IE와 함께 도입된 2기 컨트롤이다.

그렇게 새로운 GUI 컨트롤을 만들어서 자기 혼자만 안 쓰고 꼬박꼬박 다른 프로그래머에게도 공개한 건 의도는 좋지만, 그 대신 1990년대 말엔 4~5.x대의 온갖 버전의 comctl32.dll이 난립하면서 Windows가 DLL hell 비판을 받기도 했다. 응용 프로그램이 자신을 기준으로 하는 comctl32.dll을 시스템 디렉터리에다가 막 덮어쓰면서 운영체제의 안정성을 떨어뜨렸기 때문이다.

공용 컨트롤의 3기는 side-by-side assembly라는 방식으로 DLL hell을 종식시키고 GUI가 근본적으로 싹 바뀐 Windows XP와 함께 도래했다. 그리고 3기와 함께 추가된 새로운 공용 컨트롤은 아시다시피 하이퍼링크 컨트롤이다. 인터넷 시대가 도래하면서 하이퍼링크 역할을 하는 컨트롤의 필요성은 예전부터 대두되어 왔으니 말이다.

텍스트 전체가 단일 링크인 게 아니라 A 태그로 둘러싸인 부분만 링크이며, 한 컨트롤 내부에 여러 링크가 있을 수 있기 때문에 더욱 편리하다. A 태그가 없는 하이퍼링크 컨트롤은 그냥 텍스트 static 컨트롤과 별 차이가 없다. 얘는 재래식 InitCommonControls(Ex)가 아니라 오로지 공용 컨트롤 6.0 매니페스트로만 사용 가능하다.

공용 컨트롤들 중에 에디트 컨트롤과 동작이 비슷해 보이는 건 IPv4 주소를 입력받는 컨트롤이 있는데, 내부적으로 자그마한 에디트 컨트롤을 4개 나란히 생성하여 동작한다. 운영체제의 제어판 밖에서는 별로 볼 일이 없는 물건임. IPv6 주소를 입력받을 때는 그냥 일반 에디트 컨트롤을 썼더라.

그리고 잘 쓰이지는 않지만 단축글쇠 입력 컨트롤도 있다. 캐럿도 생성하고 언뜻 보기에 에디트 컨트롤의 서브클래싱 버전 같지만 얘는 에디트 컨트롤을 사용하지 않고 독자적으로 동작하는 물건이다. 사용 가능하거나 반드시 써야 하는 modifier를 Ctrl, Alt, Shift 중에서 지정할 수 있다.
<날개셋> 한글 입력기는 이것들의 좌우 구분이 가능해야 하고 Win키까지도 modifier로 지정 가능해야 하는 관계로, 용도에 맞지 않아서 단축글쇠 규칙 편집 UI에서도 이 컨트롤을 사용하지 않았다.

위의 컨트롤과는 달리 리치 에디트 컨트롤은 공용 컨트롤이 아니다. 얘는 혼자 독자적인 DLL을 갖고서 따로 노는 물건이기 때문에 초기화도 공용 컨트롤과는 다른 방법으로 한다. 복잡한 워드 프로세서를 통째로 컴포넌트화한 것이기 때문에 이것 하나만으로도 다른 어지간한 컨트롤들의 덩치를 모조리 능가한다고 봐야 할 것이다.
예전에도 한번 글로 썼듯이 리치 에디트 컨트롤은 파일 이름과 버전 사이의 관계가 굉장히 이상하게 꼬였다. SxS 방식을 쓰는 것도 아니고.

IE 웹브라우저 컨트롤은 공용 컨트롤이 아닐 뿐만 아니라 일반 윈도우 자체도 아니다. ActiveX 컨트롤이기 때문에 COM API를 써서 훨씬 더 복잡한 방식으로 초기화해서 사용해야 한다. MFC의 도움 없이는 난 불러다 써 보지도 못했다.

comctl32.dll에는 공용 컨트롤을 구동하는 코드가 주로 들어있을 테니 이들을 초기화하는 함수 말고 딱히 다른 기능이 있을까 싶은 생각이 든다. 하지만 기성 대화상자를 변형하여 동작하는 property sheet나 wizard GUI를 구동하는 함수도 여기 있고, 또 image list를 관리하는 함수들도 죄다 여기에 들어있다. 이게 user나 gdi에 들어있지 않고 comctl에 들어있는 이유는, 이 이미지 리스트들은 여러 공용 컨트롤들이 이미지를 표시할 때 한데 공유하는 자료구조이기 때문이다.
그런데 윈도우 컨트롤이 전혀 아닌 물건이 다른 공용 컨트롤과 같은 등급의 카테고리에 문서화돼 있으니 이건 좀 의아한 점이다.

공용 컨트롤들에 대해 본인이 오랫동안 의아하게 생각해 온 점은.. 클래스 이름들의 작명에 일관성이 없다는 점이다. 작명 방식은 크게 세 가지가 있는데, 이것들이 별다른 원칙 없이 뒤죽박죽으로 섞여 있다. 32라는 숫자로 끝난다는 점 말고는 다른 공통점이 없는...데, 그러고 보니 하이퍼링크와 pager 컨트롤은 예외적으로 32가 안 붙었다!

1. Sys+대문자 계열: SysIPAddress32, Header32, Link, ListView32, TreeView32, TabControl32, Animate32, MonthCal32, DateTimePick32, Pager
2. msctls_+소문자 계열: msctls_hotkey32, statusbar32, trackbar32, updown32, progress32
3. 아무 접두사가 없음: ToolbarWindow32, ReBarWindow32, ComboBoxEx32

어지간한 응용 프로그램에서 안 쓰이는 경우가 없는 도구 모음줄과 상태 표시줄만 해도 클래스 이름의 작명 스타일이 (2)와 (3)으로 서로 다르다.

심지어는 소스 코드상으로 클래스 이름을 나타내는 매크로 상수조차도 작명 방식에 통일성이 없다. WC_* 로 시작하는 명칭이 있는가 하면 그냥 *CLASSNAME로 끝나는 명칭도 있다. (toolbar, rebar, statusbar)
서로 다른 팀에서 별개로 만들던 컨트롤들을 한데 합쳐서 이런 일이 생긴 것 같다. 물론 대세는 WC_* 스타일이다.

마소에서도 이런 식의 이름 혼란에 대해서 의식을 전혀 안 하고 있는 건 아니다.
공용 컨트롤들이 사용하는 구조체를 보면 TV_*로 시작하는 구조체가 NMTV*로 바뀌고 예전 명칭은 typedef로 처리되는 등, rename을 종종 하기도 한다. 하지만 처음부터 개명을 할 일이 없게 명칭을 잘 정하는 게 더 좋았을 것이다.

이상이다.
그나저나 공용 컨트롤의 스펙을 다시 보니 옛날에는 Native font control이라는 게 있었던 모양이다. 클래스 이름도 NativeFontCtl이라고 당당하게 있는 윈도우인데.. 도대체 뭘 하는 물건이었지?

MSDN에 문서화는 이렇게 돼 있지만, 도대체 이런 윈도우를 만들어서 해결하려고 한 문제가 무엇인지.. 그리고 지금은 그게 왜 불필요해졌는지에 대한 의문은 해결되지 않는다. 공용 컨트롤의 세계도 다시 살펴보니 재미있다.

Posted by 사무엘

1. elseif 키워드

프로그래밍 언어에 따라서는 else if를 한데 묶은 축약형인 elseif 또는 elif 키워드를 별도로 제공하는 경우가 있다.
베이직이나 파이썬, 그리고 프로그래밍 요소 중에 없는 게 없는 백과사전형 언어인 Ada에는 저게 있다.

하지만 파스칼, C/C++이나 그 파생형 언어들은 전통적으로 그게 없다. 굳이 그걸 또 제공할 필요 없이 기존 if/else만으로도 동일한 표현력과 계산 능력 자체는 낼 수 있으며,
또한 더 큰 이유로는, 이들 언어는 안 그래도 공백이나 줄바꿈에 구애를 받지 않는 freeform 문법이기 때문이다. 필요하다면 어차피 else if를 한 줄에 나란히 연달아 써도 elseif와 얼추 비슷한 비주얼을 만들 수 있다. (컴파일러의 구문 분석 스택은 복잡해지겠지만..) 베이직과 파이썬은 그렇지 않다.

elseif 축약형은 else 절에서 실행되는 구문이 다음 if 절에 '완전히' 포함되어 있을 때 유용하다.
원래는 else 다음에 소스 코드의 들여쓰기가 한 단계 증가해야 하지만 그렇게 하기는 귀찮고..
수평적인 들여쓰기 단계에서 여러 개의 if를 대등한 위상에서 마치 switch-case처럼 늘어놓고 싶을 때 elseif가 쓰인다.

이런 점에서 보면 elseif 축약은 if-else에 대해서 tail-cut recursion을 한 것과 개념적으로 유사하다.
함수 재귀호출 뒤에 또 다른 추가적인 계산이 없다면, 그런 단순 재귀호출 정도는 스택을 사용하지 않는(= 한 단계 깊이 들어가는) 단순 반복문으로 바꾸는 것 말이다.

사실 C/C++은 elseif 축약이라는 개념은 언어 자체엔 없고 전처리기에만 #elif라는 형태로 있다.
전처리기는 알다시피 freeform 문법이 아니기 때문에 elif 없이 else와 if를 동시에 표현하려면 얄짤없이 줄 수가 둘로 늘어나야 하니,
문법을 최대한 간단하게 만들고 싶어서 부득이 그런 지시자를 넣은 것 같다.

2. NULL 포인터와 0

하루는 통상적으로 사용하던 #define NULL을 0에서 nullptr로 바꾸고 날개셋 코드를 리빌드해 봤다. 그랬더니.. 생각지 못했던 곳에서 엽기적인 컴파일 에러가 떴다.

아니 내가 머리에 총 맞았었나.. 왜 bool 변수에다가 NULL을 대입할 생각을 했지? =_=;;
HRESULT 리턴값에다가 S_OK 대신에 return NULL을 해 놓은 건 도대체 뭔 조화냐.
그리고 그 정도는 애교고.. obj=NULL이 원래는 컴파일 에러가 났어야 했는데 잘못된 코드를 생성하며 지나쳐 버리는 경우가 있었다. 포인터를 별도의 클래스로 리팩터링하는 과정에서 실수가 들어간 것이다.

그 클래스가 정수 하나를 인자로 받는 생성자가 있기 때문에 obj=Class(0)으로 자동으로 처리되고 넘어갔는데, 그 클래스는 독자적인 메모리 할당이 있으면서 대입 연산자 같은 것도 별도로 존재하지 않았다.
이런 일을 막으려고 C++엔 나중에 생성자에 explicit이라는 속성을 지정하는 키워드가 추가되었지만 그걸 사용하지 않는 레거시 코드를 어찌할 수는 없는 노릇이고..

아무튼 언어에서 type-safety를 강화하는 게 이렇게 중요하다는 걸 알 수 있었다.
Windows 플랫폼 헤더 include에서 NULL의 definition이 nullptr로 바뀌는 날이 언제쯤 올까? 옛날에 16비트에서 32비트로 넘어갈 때는 핸들 타입에 대한 type-safety를 강화하면서 STRICT 상수가 도입된 적이 있었는데.

NULL은 C 시절에 (void *)0, 초창기 C++에서는 타입 오버로딩 때문에 불가피하게 그냥 0이다가 이제는 nullptr로 가장 안전하게 변모했다.
개인적으론, PSTR ptr = false; 도 컴파일러 차원에서 안 되게 좀 막았으면 좋겠으나.. 포인터에 0상수 대입은 뭐 어찌할 수 없는가 보다.

3. 자바의 문자열

자바(Java)로 코딩을 하다 보면 나처럼 C++ 사고방식에 머리가 완전히 굳은 사람의 관점에서 봤을 때 궁금하거나 불편하다고 느껴지는 점이 종종 발견된다.
int 같은 기본 자료형이 아니면 나머지는 모조리 클래스이다 보니 한 함수에서 데이터 참조용으로나 잠깐 사용하고 마는 int - string 쌍 같은 것도 못 만드는지? 그런 것도 죄다 새 클래스로 만들어서 new로 할당해야 하는지?

그리고 기본 자료형은 값으로만 전달할 수 있으니 int의 swap 함수조차 만들 수 없는 건 너무 불편하지 않은지?
인클루드가 없는데 자신 외의 다른 클래스에 존재하는 public static final int값이 switch case 상수로 들어오는 게 가능한지? 등등..

이와 관련되어 문자열은 역시 자바 언어에서 좀 어정쩡한 위치를 차지하며 특이하게 취급되는 물건이다.
얘는 일단 태생은 기본 자료형이 아닌 객체/클래스에 더 가깝다. 그래서 타입의 이름도 소문자가 아닌 대문자 S로 시작하며, 이 개체는 가리키는 게 없는 null 상태가 존재할 수 있다.

그러나 얘는 문자열 상수의 대입을 위해서 매번 new를 해 줘야 하는 건 또 아니다. 이건 예외적으로 취급되는 듯하다.
그럼 그냥 String a; 라고만 하면 얘는 길이가 0인 빈 문자열인가(""), 아니면 null인가? 그리고 지역 변수일 때와 클래스 멤버 변수일 때에도 그 정책이 동일한가? 뭐 직접 회사에서 프로그램을 짜 본 경험으로는 전자인 것 같긴 하다.

단, 자바의 문자열을 다룰 때는 주의해야 할 점이 있다. 자바 프로그래머라면 이미 잘 숙지하고 계시겠지만, 문자열의 값 비교를 ==로 해서는 안 된다는 것이다. equals라는 메소드를 써야 한다.
==를 쓰면? C/C++식으로 얘기하자면 문자열이 들어있는 메모리 포인터끼리의 비교가 돼 버린다. 애초에 포인터의 사용을 기피하고 다른 걸로 대체하는 컨셉의 언어에서, 이런 동작은 99% 이상의 경우는 프로그래머가 의도하는 결과가 아닐 것이다.

C++에서야 문자열 클래스에 == 연산자가 오버로딩되지 않은 경우가 없을 테니 언어가 왜 저렇게 만들어졌는지 이해하기 어렵겠지만.. 자바는 연산자 오버로딩이란 게 없는 언어이며 String은 앞서 말했듯이 기본 자료형과 클래스 사이의 어중간한 위치를 차지하는 물건이기 때문에 이런 디자인의 차이가 발생한 듯하다. 자바는 안 그래도 걸핏하면 클래스 새로 만들고 get/set 등 다 메소드로 구문을 표현해야 하는 언어이니까.
오죽했으면 본인은 회사에서 자바 코드를 다루면서도 문자열 비교를 실수로 ==로 잘못 해서 발생한 버그를 발견하고 잡은 적도 있었다.

그나저나 유사 언어(?)인 스칼라, 자바스크립트 같은 언어들은 ==로 바로 문자열 비교가 가능했던 걸로 기억한다.

4. true iterator

파일을 열어서 거기에 있는 문자열을 한 줄씩 얻어 오는 함수(A), 그리고 각 문자열에 대해 출력을 하든 변형을 하든 일괄적인 다른 처리를 하는 함수(B)를 완전히 분리해서 별도로 작성했다고 치자. 혹은 한 디렉터리에 파일들을 서브디렉터리까지 빠짐없이 쭉 조회하는 함수(A)와, 그 찾은 파일에 대해서 삭제나 개명 같은 처리를 하는 함수(B) 구도로 생각할 수도 있다.
그런데 이 둘을 연계시켜서 같이 동작하게 하려면 어떻게 하는 게 좋을까?

이럴 때 흔히 떠올릴 수 있는 방법은,
A 함수에다가 B 함수까지 인자로 줘서 호출을 한 뒤, A의 내부 처리 loop에서 B에 넘겨줄 데이터가 준비될 때마다 B를 callback으로 호출하는 것이다. B는 간단한 일반 함수 + context 데이터 형태가 될 수도 있고, 아니면 가상 함수를 포함한 인터페이스 포인터가 될 수도 있다.

데이터 순회를 하는 A 자체도 파일을 열고 닫거나 내부적으로 재귀호출을 하는 등 state가 존재하기 때문에 매번 함수 실행을 시켰다가 종료하기가 곤란한 경우, 상식적으로 A를 먼저 실행시킨 뒤에 A가 계속 실행되고 있는 중(= 상태도 계속 유지되고)에 그 내부에서 B를 호출하는 게 바람직한 게 사실이다.
물론, 반복문 loop을 B에다가 두고, 반대로 B에서 A를 callback 형태로 호출하는 것도 불가능한 건 아니다. 그런데 프로그래밍 언어에 따라서는 이런 B 중심적인 사고방식의 구현을 위해 좀 더 획기적인 기능을 제공하는 물건도 있다.

def func():
    for i in [1,5,3]:
        yield i

a=func()
print a.next()
print a.next()
print a.next() # 예상하셨겠지만 1, 5, 3 순서대로 출력

파이썬에는 함수에 return 말고 yield 문이 있다. 그러면 얘는 함수 실행이 중단되고 리턴값이 지정되기는 하는데..
다음에 그 함수를 실행하면(정확히는 next() 메소드 호출 때) 처음부터 다시 실행되는 게 아니라, 예전에 마지막으로 yield를 했던 곳 다음부터 계속 실행된다. 예전의 그 함수 호출 상태가 보존되어 있다는 뜻이다.

난 이걸 처음 보고서 옛날에 GWBASIC에 있던 READ, DATA, RESTORE 문과 비슷한 건가 싶었는데.. 저건 당연히 GWBASIC을 아득히 초월하는 고차원적인 기능이다. C++이었다면 별도의 클래스에다가 1, 5, 3 static 배열, 그리고 현재 어디까지 순회했는지를 가리키는 상태 인덱스 정도를 일일이 구현해야 했을 텐데 저 iterator는 그런 수고를 덜어 준다.

단순히 배열이 아니라 binary tree의 원소들을 prefix, infix, postfix 방식으로 순회한다고 생각해 보자.
순회하는 함수 내부에서 다른 콜백 함수를 호출하는 게 아니라 매번 원소를 발견할 때마다 리턴값을 되돌리는 형태라면..
구현하기가 굉장히 까다로울 것이다. 스택 메모리를 별도로 할당한 뒤에 재귀호출을 비재귀 형태로 일일이 구현해 주거나, 아니면 각 노드에다가 부모 노드의 포인터를 일일이 갖춰 줘야 할 것이다.

C++의 map 자료형도 내부적으로는 RB-tree 같은 자가균형 dynamic set 자료구조를 사용하는데, 이런 iterator의 구현을 위해서 편의상 각 노드에 부모 노드 포인터를 갖고 있는 걸로 본인은 알고 있다. RB-tree는 내부적으로 로직이 굉장히 복잡하고 까다로운 자료구조이긴 하지만, 그래도 부모 노드 없이도 구현이 불가능한 건 아닌데 말이다.
안 그랬으면 iterator가 자체적으로 스택을 멤버 변수로 갖거나, 최소한 메모리 할당· 해제를 위해 생성자나 소멸자까지 갖춰야 하는 복잡한 class가 돼야 했을 것이다. 어떤 경우든 포인터 하나와 비슷한 급인 lightweight 핸들이 될 수는 없다.

개인적으로는 지난 여름에 <날개셋> 한글 입력기 7.5에 들어가는 새로운 한글 입력 순서 재연 알고리즘을 구현할 때 비슷한 레벨의 iterator를 비재귀적으로 구현한 적이 있는지라, yield문의 의미가 더욱 절실히 와 닿는다.

Posted by 사무엘

1.
말라기서는 구약 성경의 맨 마지막 책이다. '말라기'는 이 책을 기록한 대언자의 이름이다.

구약의 예언/선지서들은 분위가 다 비슷하다.
우선 이스라엘 백성들의 죄를 신랄하게 깐다. 좀 우파스러운 원론적이고 영적인 죄뿐만이 아니라, 당대 상류층들의 부정부패를 까발리면서 민생 안정과 사회 개혁을 촉구하는 좌파스러운 책망도 골고루 균형있게 나온다.

그런데 결론은 기승전철..은 아니고 기승전'회'로 동일하다. 저런 죄악에도 불구하고 하나님의 타임라인에서 궁극적으로 최후의 승자는 이스라엘이다. 하나님과 이스라엘의 관계는 회복되며 옳다구나 이스라엘 백성들을 괴롭힌 놈들은 다 작살이 나고 씨도 안 남는다. 이러니 오늘날 이스라엘 사람들은 예수를 안 믿음에도 불구하고 반유대주의와 반기독교 성향은 바늘과 실처럼 따라다니는 것이다. 단적인 예로, 천주교 교황이 전세계를 돌면서 예수님 재림과 이스라엘 회복을 말한 적이 있던가? (말한다면 그건 해가 서쪽에서 뜰 일이며, 그 종교는 이미 천주교가 아닐 게다)

그래도 성경 말씀은 기록된 대로 이루어질 것이고 구약 예언서들이 일관되게 말하는 크고 두려운 '주의 날'은 임할 것이다. 단지 구약 대언자들은 산봉우리 너머의 재림만을 보았을 뿐, 예언의 골짜기에 속하는 신약 교회에 대한 계시가 없었으며 초림과 재림의 구분에 대한 개념도 아직 몰랐다는 차이가 존재한다. 물론 실질적으로 초림과 재림 구분은 이스라엘 백성들의 예수님 거부 이후부터 생겼겠지만 말이다.

본론으로 돌아오자면, 말라기서는.. 이스라엘 백성들이 자기 땅으로 귀환까지 하고 나서 거의 100여 년 뒤에 구약 중에서 혼자만 굉장히 늦게 기록됐다.
이스라엘 백성들은 바빌론 포로 귀환 후, 우상 숭배라는 죄 하나는 완전히 떨쳐 냈다. 그러나 노골적으로 바알 숭배만 안 할 뿐이지 영적 상태는 여전히 정상이 아니었다.

주 하나님에 대한 신앙은 막장급의 매너리즘에 빠졌다. 사람들은 자기가 못 먹는 거니까 흠 왕창 많고 병들고 상품으로서의 가치가 없는 가축을 헌물로 바쳤다. 출애굽기 이후로 모세오경에 without blemish이라는 단서가 얼마나 지겹도록 많이 나오는데.. 저건 상상도 할 수 없는 일이었다.
그리고 십일조 헌금을 안 바치니까 레위 지파 성직자들은 먹고 살 수가 없어서 생업을 따로 구해서 투잡을 뛰어야 할 정도였다. 요즘으로 치면 밤에 대리운전?? =_=;;;

말라기서는 전반적으로 하나님에 대한 사랑과 두려움이 완전히 상실되고 “뭐 대충 이렇게 해도 괜찮겠지”, “어차피 다 소용없어”, “우린 아마 안 될 거야” 등, 하나님에 대한 온갖 잘못된 생각들에 대해 하나님이 친히 반박을 하고 책망하는 논리로 진행된다.

말이 나왔으니 말인데 성경에서 사람들의 잘못된 신앙관을 먼저 제시하고서는 그걸 반박하는 형태로 진행되는 텍스트가 신구약을 통틀어 여럿 있다. 로마서의 “그럼 ...하겠느냐? 결코 그럴 수 없느니라(God forbid)”는 완전히 같지는 않지만 비슷한 예이고. 개인적으로는 성경을 통틀어 이런 예들만 한데 모아도 주일 예배 설교 한 편 분량은 충분히 나올 것 같다.

말라기도 기본적으로 그런 논조이니 유쾌한 분위기는 절대 아니다. 오죽했으면 하나님께서 자꾸 동물 헌물을 그딴 식으로 바칠 거면, 그 동물들의 똥을 꼴도 보기 싫은 성직자 네놈들 얼굴에다 덕지덕지 쳐발라 버리겠다는 노골적인 책망까지 하셨을 정도이다. (말 2:3)
헌물 말고도 이 책은 '의의 태양', 침례인 요한 예언도 나오고 십일조에 결혼 문제 등 생각보다 다양한 주제를 이것저것 부랴부랴 다룬다.

그런데 지금 내게 굉장히 절실히 와 닿는 구절은 말 3:14-17이다.
“교회 다니고 하나님 섬기는 거 다 무가치한 헛일일 뿐이다. 어차피 세상에는 자기를 내세우고 적당히 줄 잘 서고 죄도 잘 짓는 사람들이 사회성이 뛰어나고 잘 되고 성공한다..”는 식의 생각.. 역시 일반적인 사람들의 심리는 2400여 년 전이나 지금이나 똑같다.

허나 16절을 보자. 하나님을 두려워하는 사람들이 자주 성경을 강론하고 서로 믿음을 북돋우는 교제를 나누면..
그 사건은 하나님이 친히 귀를 기울여 듣고, 정말 기쁘고 기특하다면서 그걸 책으로 기록으로 남기신댄다.
그리고 다음 17절에 따르면.. 그런 사람들은 보석만큼이나, 친아들만큼이나 하나님께서 무진장 귀중히 여겨고 보상할 것이라는 약속이 나온다.

성경에서 역사· 교리적으로 유대인 얘기를 하고 있는 곳에다가 교회가 유대인 사칭을 하는 건 병크이지만.. 저것만큼은 정말로 오늘날 교회에까지 그대로 적용되는 약속이 아닐 수 없다.
“그러므로 이 말씀들로 서로 위로하라.” (살전 4:18) 휴거와 재림만큼이나 위로의 명분이 성립하는 게 틀림없다.
스바냐서에서 “하나님께서 너로 인해 기뻐하고 노래까지 부르실 것이다”라는 말씀이 나오는 것만큼이나 엄청난 구절이 의외로 소선지서 한구석에서 발견되곤 한다.

이렇게 본인은 길고 길던 구약 통독을 드디어 끝냈다.

2.
난 예나 지금이나 아예 문을 걸어 잠그고 아무것도 안 믿고 무신론자 회의론자로만 산다면 모를까,
내세와 영원을 논하는 '종교'관을 판단하는데 겨우 그 종교에 속한 사람의 외적 행실, 또는 대외 이미지, 유명인사의 의견을 높은 가중치에 두는 건 아주 굉장히 대단히 매우 어리석은 발상이라고 생각해 왔다.

그런 걸 전혀 볼 필요가 없다는 얘기가 아니며 물론 신자들은 좋은 행실로 좋은 간증을 남기고 가능한 한 세상과 화평하게 지내야 한다. 병싯같은 짓으로 불신자에게 쓸데없이 실족거리를 줘서는 안 된다. 허나, 그렇다고 해서 어차피 구도자의 입장에서도 그런 외형적인 것들은 주된 판단 근거가 돼서는 안 된다.

본인은 몇 차례 글을 썼듯이, 무슨 하나님 믿고 예수는 믿지만 교회는 안 믿는다는 식의 생각을 굉장히 싫어한다.
예수님이 무슨 좋은 덕담이나 남긴 4대 성인 도인 슈퍼스타이고 자신의 상식과 교양 한 줄 정도나 기여하는 아이템인 줄로 아는가 본데, 그 예수가 당신이 싫어하는 교회의 창립자이고 교회의 머리이다. 뭘 좀 알고서 얘기해야 하지 않을까?

불신자들하고 어울려서 대형 교회 욕이나 하고 다니는 헛똑똑이 겉멋 든 좌독 성향도 완전 혐오.
경제 쪽으로 대기업에 대한 생각하고 완전히 똑같은 논리이다.
대기업을 엿먹이고 싶고 중소기업을 살리고 싶으면, 나 자신부터 중소기업 제품을 애용하면 되듯이
한국 교회를 진심으로 걱정하고 대형 교회가 한국 교계의 레알 비성경적인 악의 축이라고 생각한다면.. 나 자신부터 아주 보수· 근본주의적이고 신앙의 양심을 충족하는 작은 교회를 찾아서 다니면 된다.

대형 교회가 당신의 개인의 양심의 자유와 신체의 자유를 빼앗지 않았고 폭력을 행사하지 않았다면.. 그렇게까지 피해의식 갖고 미워하지는 않아도 된다. 그리고 작은 교회에는 사람간의 트러블, 부조리가 어디 없을 줄 아는가? 대안 없는 비판, 일관성 없는 판단은 이제 좀 그칠지어다.

세상의 모든 대중교통들은 운송 약관을 보면 "만취자, 중환자 또는 신변이 불결한 자에 대해서는 당사가 승차를 거부할 수 있음"이 명시돼 있다. 무조건이든 단독 승차에 한해서든.

그러나 다른 곳은 몰라도 목욕탕이.. 만취자는 몰라도 신변이 불결한 자를 입장 거부한다는 게 말이 되는 소리이겠는가?
병원이.. 중환자를 거절한다는 게 말이 되는가? 교회가 바로 그런 곳이다.
교회 성도들보다 자신이 너무 똑똑하고 의롭고 질이 높아서 차마 예수는 믿어도 교회는 못 믿겠다(다니겠다) 이러는 분들.. 정말 구원이라도 받은 사람이라면 그 불평을 나중에 예수님 앞에서 자신 있게 털어놓고 예수님을 논쟁에서 이길 수 있기를 난 바라마지 않겠다.

나는 행실이 너무 막장 저질이었는데 나 같은 사람을 구원하고 일꾼으로 써 주신 예수님의 은혜가 너무 고맙고, 가끔 교회에서 이상한 사람과 싸우더라도 교회의 정체성과 본분을 잊지는 않을 것이다. 100% 완벽한 성도로만 구성된 교회에 내가 등록하는 순간부터 그 교회는 완전성이 깨진다는 생각을 하며 다닐 것이다.

* 나는 늘 공언한다. 누군가가.. 있지도 않은 신을 숭배하고 교회 다니느라 인생을 낭비하는 나같은 중생을 너무 불쌍히 여기고 사랑해서.. 무신론을 전하기 위해 나를 위해서 목숨까지 버렸다가 나중에 부활했다면 나는 그 정도 표적에는 기꺼이 반응하여 지금의 기독교 신앙을 버리고 무신론자가 되겠다. 이 정도면 내가 왜 교회를 다니는지 논리가 설명이 되었을 것이다.

Posted by 사무엘

우주 개발과 관련하여 일반적인 항공· 우주덕, 역덕들에게 잘 알려져 있는 유명한 사고는 아폴로 1호나 13호, 그리고 챌린저와 컬럼비아 우주왕복선처럼 유인 우주선에서 발생한 인사사고 위주이다. 그게 임팩트가 크다.

하지만 컴퓨터공학 관련 수업에서 종종 언급되는 우주 사고는 저런 것들보다는 덜 알려진 무인 우주선의 오동작· 자폭 사고 두 건이다. 바로 (1) 1999년에 미국이 발사한 화성 기후 탐사 인공위성의 추락 사고와, (2) 1996년 유럽 우주국에서 발사한 정지 궤도 진입용 아리안 5호 로켓의 자폭 사고이다. 이것들은 다른 기계 구조적인 실수· 결함이 아니라, 전적으로 발사체 포함 로켓을 제어하는 소프트웨어의 버그로 인해 발생했기 때문이다.

전자는 서로 다른 팀의 엔지니어들이 같은 물리량에 대한 단위계를 제각각 다르게 가정하고 코딩을 하는 바람에, 계산 결과의 scale이 산으로 가 버려서 위성이 추락한 정말 안습한 사례이다. 흔히 길이(미터 vs 인치)의 착오라고 알려져 있는데, 더 자세한 문헌을 찾아 보니 사실은 단위 시간당 힘(킬로그램힘 vs 파운드)의 착오이다. 뭐 어느 것이든 표준 단위계와 비표준 단위계의 착오인 건 마찬가지이고 우리나라로 치면 제곱미터와 평, 킬로그램과 근 같은 게 헷갈린 것과 동일하다.

이 때문에 무려 9개월간의 긴 여행을 마치고 기껏 화성까지 잘 가서 궤도에 진입하려던 위성은 예상보다 고도가 급격히 낮아졌으며, 화성의 뒷면으로 들어가는 예상 시각보다 더 일찍 통신이 끊어졌다가 다시는 통신이 회복되지 못했다. 화성의 대기권에까지 들어가 버린 위성은 대기와의 마찰열로 인해 파괴되고 추락했다.

지구로부터 수천만 km나 떨어져 있는 다른 행성에서 벌어진 사고이다 보니, 사고 장면도 전해지는 게 없다.
사고의 원인이 어처구니없는 실수 때문이었음이 밝혀지자 미국 내부에서도 “우리도 미터법의 국내 도입이 시급합니다”라는 여론이 당연히 일었다. 그러나 오랜 관행을 바꾸는 일은 요원해 보인다.

한편, 후자의 사고도 사연이 만만찮게 안습하다.
로켓을 제어하는 프로그램의 내부에는 64비트 float 부동소수점을 16비트 int로 형변환을 하는 루틴이 있었다. 알다시피 이건 양 자료형의 표현 범위의 차이가 엄청나다. 단순히 소수점이 잘리는 것 이상으로 수의 표현 가능한 범위 자체가 잘릴 위험이 높다.

다만, 이전의 아리안 4호에서 이게 별 문제가 된 적이 없었던 관계로 이 부분을 맡은 엔지니어는 앞으로도 오버/언더플로우가 발생할 일은 없다고 판단했다. 그래서 성능 향상을 위해 범위 검사를 하는 옵션을 제외하고 프로그램을 빌드해서 우주선에다 탑재했다.

그런데 아리안 4호와 5호는 로켓의 규격이 서로 달랐으며, 일어나지 않으리라 예상했던 그것이 실제로 일어났다.
완전히 엉뚱하게 형변환된 정수 숫자가 예외 처리도 없이 계산식에 들어가면서 프로그램의 내부 상태는 엉망이 되었으며, 사태 극복을 할 수 없던 컴퓨터 프로그램은 결국 최후의 수단으로 설정되어 있던 자폭 모드로 진입했다. 그래서 아리안 5호 로켓은 발사된 지 겨우 37초 만에 기수를 아래로 숙이면서 추락했다.

중앙 통제실은 싸늘한 초상집 분위기로 변함. 망연자실한 직원들..;; (☞ 동영상 링크)
무인 우주선인 관계로 인명 피해는 없었지만 둘 모두 수억 달러급의 손실을 초래했다. 나로 호의 발사 실패하고도 급이 다른 게, 아리안 5호만 해도 나로 호보다 5배 이상 더 무거운(= 크기도 더 큰) 로켓이었기 때문이다. 그게 고스란히 폭죽으로 전락해 버렸으니.

학부 시절에 소프트웨어공학 수업 시간 때 들은 얘기를 먼 훗날 대학원에서 프로그래밍 언어 수업에서 다른 교수로부터 또 들으니 감회가 새로웠다.
전자 시간에는 체계적인 소프트웨어의 테스트/검증의 중요성에 대해 얘기하면서, 후자 시간에는 프로그래밍 언어 차원에서 타입 검증과 예외 처리의 필요성을 얘기하면서 저것들이 타산지석 사례로 소개되었다.

그나저나 아리안 5호에 들어가는 프로그램도 Ada로 작성되었다고 한다.
Ada에는 배열 첨자 범위라든가 형변환 overflow 예외를 감지하는 기능이 있고, 그걸 끄는 옵션도 별도로 존재한다.
C/C++처럼 무작정 프로그래머에게 모든 걸 맡기기보다는 적당히 언어 시스템이 개입해서 안전을 추구하는 것도 많다 보니 Ada가 프로그래밍 언어계에서는 꽤 noble한 대접을 받는가 보다. 하지만 배열 첨자를 마치 함수 호출처럼 ()로 하고, 명칭에 대소문자 구분이 없는 것은 좀 Basic스럽고 요즘 언어가 아닌 구시대 언어 같은 느낌이 든다.

참고로 Ada는 명칭 자체가 여자 이름인 반면, 코볼은 주 설계자가 수학자 출신의 여성 해군 장성이다(그레이스 호퍼).

Posted by 사무엘

인간이 발명한 교통수단은 그 형태가 자동차(육상-도로), 열차(육상-철도), 비행기(하늘), 그리고 배(물)라는 네 종류로 크게 나뉜다. 각 교통수단은 일반적으로 자기가 다닐 수 있는 형태의 길 위에서만 다닐 수 있는데..
군사 같은 특수한 용도를 목적으로 두 분야의 성격을 동시에 갖는 하이브리드 교통수단도 드물게나마 있다.

1. 자동차+열차

도로도 달릴 수 있고 레일 위도 달릴 수 있는 차량이다.
바퀴에다가 밖으로 툭 튀어나온 채 레일에 닿는 특수한 휠캡을 끼우는 방법이 있고, 아예 레일 주행용 대차를 타이어의 전후에 따로 갖추고 있다가 필요할 때 내리는 방법도 있다. 전자는 사람이 휠캡을 착탈하는 게 골치아픈 일이겠으며, 후자는 엔진 구동축 자체가 도로 바퀴용과 철도 바퀴용이 둘 존재해야 하니 기술적으로 구현하기가 더 어렵겠다.

도로+철도 겸용 차량은 군용 내지 선로 시설 보수용 차량으로 일부 존재한다. 우리나라 군용 트럭들은 특수한 휠캡을 끼워서 유사시에 레일 주행이 가능하다는 얘기를 어디에선가 들었는데, 그게 사실인지 확인은 못 해 봤다.
하긴, 과거에는 굳이 동력 엔진이 없는 인력거나 마차조차도 열차 버전이 없지는 않았다. 오늘날도 관광· 레저용으로 레일바이크가 있고 말이다.

2. 열차+열차

사실은 철도는 길에 대한 제약이 가장 심하기 때문에 도로가 아니라 같은 철도끼리라 해도 궤간이 다르면 차량이 못 다닌다. 우리나라야 육로로 인접하는 나라가 사실상 없는 지형에다가 표준궤 단일 궤간이 잘 정착하여 궤간 혼란이 존재하지 않지만, 당장 러시아의 시베리아 철도만 해도 표준궤가 아닌 광궤이다.

이 문제를 해결하는 전통적인 방법은 한 선로에다가 궤간이 다른 궤조를 동시에 여럿 설치하는 것이다. 전차선이 아니라 협궤/광궤용 제3궤조가 생기는 셈이다. 이건 이것대로 몹시 힘든 일이며, 선로가 분기라도 하는 곳에서는 작업 난이도가 답이 없는 수준으로 치솟는 걸 감안해야 한다.

궤간 문제를 선로가 아닌 차량을 바꿔서 해결하는 방법은 가변궤간 대차를 설치하는 것이다. 틸팅열차가 대차 위의 객실의 기울기를 조절해서 원심력을 상쇄한다면, 가변궤간 대차는 양 바퀴 사이의 간격을 궤간 변경 구간 사이에서 조정한다.
튼튼하게 꽉 고정되어 있어야 하는 부품의 유격이 유동적으로 변하기 때문에 가변궤간 대차는 일반적인 고정형 대차보다 수명이 짧고, 정비불량이 발생할 위험도 있다.

이것도 마치 앞의 도로+철도 겸용 차량처럼 그냥 A궤간용 바퀴와 B궤간용 바퀴를 둘 다 들고 다니면서 필요한 것을 들었다 놓았다만 하는 방법을 생각할 수 있을 텐데, 둘 다 들고 다니기엔 철도 차량의 대차 부품들은 너무 무겁다는 게 흠일 것이다. 일반적인 화차나 객차를 다 그렇게 만들기에는 경제적이지 못하다.

3. 자동차+비행기

사실, 자동차와 비행기는 한 물건에 다 구겨넣기에는 엔진 구조가 서로 너무 다르고 차체/기체의 외형도 차이가 너무 많이 난다. 이런 이유로 인해 flying car 같은 물건은 SF 창작물에서나 볼 수 있는 상상의 산물로 치부돼 왔다.
하지만 엔진 출력이나 차의 덩치, 연비 같은 실용적인 제약이 없다고 치면.. 고정익기와 회전익기 중 어떤 형태가 자동차와의 융합에 더 어울리는지를 먼저 생각할 필요가 있다.

고정익기 겸용 자동차가 있다면 미국처럼 땅 넓은 데서 원래부터 자가용 비행기를 굴리고 살던 부자들이 아주 좋아할 것이다. 한 기계만으로 하늘과 땅에서 모두 장거리 주행이 가능하기 때문이다. 이런 차량은 도로를 달릴 때는 날개를 잘 접어 두는 기능이 있어야 할 것이고 완전한 고정익 비행기처럼 연료를 날개 안에다 집어넣기는 어려울 것이다.
이착륙을 위해서는 온전한 형태의 활주로가 필요하며 타이어 역시 도로 주행뿐만 아니라 랜딩기어 역할도 할 수 있게 아주 튼튼한 고가의 제품을 써야 할 것이다.

하지만 이 비행이라는 게.. 단순히 보조용을 더 원한다면.. 다시 말해 차가 꽉 막히고 있을 때 정체 구간이나 사고 지점만 폴짝 뛰어 넘어갈 수 있고 주차장에서도 옆 차를 밀 필요 없이 원하는 지점에 쏙 드나들 수 있는 걸 원한다면.. 헬리콥터 같은 회전익기 형태의 비행 겸용 차량이 더 유용할 것이다. 고정익기는 뜨고 내리기 위해 활주로가 필요하기 때문에 이런 역할은 할 수 없다.

아니면 아예 자동차용 제트팩이라도? =_=;;
평소에는 제트 가스를 후방으로 분출해서 가속력을 얻는 데 쓰지만 그걸 아래로 분출하면 차를 뜨게 만들 수 있을 것이다. 특수한 용도로 쓰이는 초음속 자동차 같은 건 조금만 개조하면 비행도 가능하지 않을까 싶다.

4. 비행기+비행기

비행기 중에는 뱅글뱅글 돌아가는 바람개비를 고정익기의 프로펠러로도 쓸 수 있고, 회전익기의 로터처럼도 쓸 수 있게 한 '틸트로터' 형태의 하이브리드가 있다. 바람개비가 향하는 각도를 바꾸면 된다.

5. 자동차+배

다음으로 배 이야기를 해 보자.
자동차와 선박 사이의 교배는 '수륙양용'이라는 이름으로 우리에게 상대적으로 친숙한 개념이다. 물론 십중팔구 군용차 형태로 말이다. (1) 물에 뜨지는 못하지만 그래도 방수 처리가 되기 때문에 차체의 대부분이 물에 잠긴 상태에서도 운행 가능한 차, 아니면 아예 (2) 물에서도 뜬 채로 달릴 수 있는 차 이렇게 두 부류로 나뉜다.

(이런 차가 민수용 자가용으로 양산되면 일단 낚시꾼들이 무진장 좋아하겠다. 저 차의 이름은 Python이라고 한다. 전산업계에서는 '파이썬'이라고 명칭이 통일되다시피했는데, 다른 업계에서는 '톤', '손' 등 여러 표기가 혼재하는 듯.)

6. 열차+배/비행기

철도 차량은 그 배타성으로 인해 육지가 아닌 다른 교통수단과의 하이브리드는 사실상 무의미하다. 배는 제끼고 랜딩기어가 철도 차량 형태인 비행기가 있어서 활주로가 철길 형태인 상황만을 한번 가정해 보자.

쇠는 고무보다는 착륙 충격과 마찰열에 더 강하겠지만, 그래도 일반 철길도 매일 유지보수를 해야 하는 판에 레일 활주로가 maintanance-free를 보장해 주는 것도 아니고, 활주로 이탈 사고를 크게 예방해 주는 것도 아니고 딱히 유리한 게 없다. 오히려 쇠로 만들어진 바퀴와 대차는 아무래도 중량면에서 불리할 것이고 착륙 후 제동을 거는 데도 큰 악재로 작용할 것이다.

음, 그나저나 하늘을 날 수 있는 열차라니 은하철도 999 생각도 나고 철덕으로서 이색적인 느낌이 든다.

7. 비행기+배

사실, 20세기 이래로 하이브리드가 가장 잘 발달한 조합은 비행기와 배끼리이다.
지금과 같은 잘 닦인 공항과 활주로가 없던 시절에는 자연적으로 형성된 강, 호수, 바다에서 쉽게 뜨고 내릴 수 있는 비행기가 있는 게 좋았기 때문이다.
또한 옛날에는 엔진 기술이 지금처럼 발달하지 못했던 관계로, 장거리 비행기는 비행 중에 엔진이 퍼져서 망망대해로 떨어질 위험이 높았다. 그러니 이걸 감안해서라도 물에 뜨고 내리는 비행기는 자연스럽게 생각할 수 있는 개념이었다.

먼저, 다리에 바퀴 대신 뗏목이나 스키처럼 생긴 플로트가 달려서 물에 뜰 수 있는 자그마한 수상기(floatplane)라는 게 있다.
그리고 이것보다는 규모가 크고, 동체 자체가 하부가 둥그렇게 생겨서 물에 뜰 수 있는 비행정(flying boat)이 있다.
A380이나 심지어 An-225보다도 더 커서 역사상 가장 거대한 비행기로 간주되는 휴즈 H-4 허큘리스도 비행정이다. (참고로 '휴즈'의 철자가 Hughes인데.. gh는 알다시피 영어에서 발음이 가장 기괴하게 다양한 걸로 악명 높은 철자이다.;;)

하지만 비행기 기술이 발달하고 육지에도 공항과 활주로 시설이 구축되면서 배의 기능을 겸하는 비행기는 인기를 잃게 됐다.
가장 큰 이유는 수상기든 비행정이든, 물에 뜨는 데 쓰이는 장비들이 일단 기체가 하늘로 뜬 뒤부터는 항공역학적으로 아무 도움이 되지 않고 무게만 차지하는 잉여가 되어 비행 가성비를 떨어뜨리기 때문이다.

또한 물에 착륙(응? 륙?)하면 활주로나 랜딩기어 타이어의 정비는 필요 없을지 모르지만, 그래도 착수 충격도 생각보다 크기 때문에 이로 인한 기체의 정비가 여전히 불가피했다. 바닷물이라면 염분 부식 문제도 있고 말이다.

오히려 비행 원리가 적용되어 수면을 수~수십m 남짓 떠서 매우 빠르게 달리는 선박으로는 호버크래프트나 위그선 같은 부류가 있다.
고정익기는 "공기를 거슬러 빨리 달린다 → 날개에 양력이 생긴다"의 순인데 이런 선박의 원리를 설명할 때는 "뜬다 → 물의 저항이 없어서 빨리 달린다"로 순서가 바뀌는 것 같다.
성능면에서 장점이 있지만, 조종을 위해 선박과 항공기 면허가 모두 필요하고 안전 같은 문제가 있어서 이쪽 역시 생각만치 실용화는 못 돼 있다.

* 교통수단간의 이종교배 하나만 생각했는데 글 쓸 것, 생각할 거리가 무척 많고 재미있다.

Posted by 사무엘

1. 경의-중앙선 전철 직결 운행

지난 2014년 12월 27일엔, 지하 공덕에서 끝나던 경의선이 용산까지 연결됨과 동시에.. 운행 계통도 둘이 통합되어 직결 운행을 시작했다.
무슨 말이냐 하면 문산에서 출발하여 탄현을 경유한 전철이 용산, 옥수, 한남, 왕십리, 청량리를 거쳐 양평, 용문까지 한번에 간다는 뜻이다.

1978년에 용산에서 성북까지 겨우 1호선의 지선 국철 취급이나 받았던 마이너 노선이 2005년 말부터 용산-덕소 중앙선으로 운행 계통이 분리되었는데, 그게 동쪽으로는 용문까지 연장되고 그걸로도 모자라서 서쪽의 경의선과도 연결되는 발전을 이뤘다. 네 시작은 미약하였어도 끝은 심히 창대하리라.

이 경우, 중앙선을 달리는 열차도 경의선 시내 구간(공덕, 서강대 같은)에서는 잠시 지하 운행을 하게 된다.
공항 철도와 복층으로 겹치는 구간도 있지만, 어쨌든 서울역-공항(김포, 인천) 테크와 용산역-파주,청량리,양평 테크가 확실하게 분리가 이뤄질 것이다.

이 날짜에 맞춰서 일산선(서울 지하철 3호선 직결)의 원당-삼송의 무려 4km에 달하는 구간 사이에도 역이 하나 더 생겼고, 수인선에도 중간에 역이 하나 더 개통했다.
나는 프로그래머이면서 뭐 Visual Studio 새 버전이 나오고 아이폰 6이 나오고 뭐가 나오고 하는 건 별 관심 없고, 새로 개통하는 철도에 더 관심이 많고 그게 더 기쁘게 들린다. 어떡하지? =_=;;

2. 야탑 역 대합실의 열차 위치 안내 전광판

대한독립만세...!! 응? 까지는 아니어도 어쨌든 만세 만세 만만세!
자고 일어나니 드디어 야탑 역에도 생겼다. 열차 위치 안내 전광판. (승강장 말고 대합실 기준)
인근의 가천대, 태평, 모란, 이매, 서현 등엔 다 있는데.. 도대체 무슨 조화인지 야탑에만 이런 기본 시설이 지금까지 없었다.

내가 타려는 열차가 지금 어디쯤 있는지, 빨리 내려가면 탈 가망이 있는지를 예측을 할 수 없어서 얼마나 불편했나 모른다.
카드 찍고 개표 구역으로 들어갔는데 이제 막 하차 승객들이 내 쪽으로 스물스물 계단을 올라오는 게 보이면 낚였다는 생각에 내면으로부터 진심어린 짜증과 분노와 빡침이 솟구치곤 했다. 안 겪어 본 사람은 내 심정을 이해할 수 없다.
탈 가망이 없는 걸 진작에 알았으면 화장실이라도 먼저 들르면서 다음 6분간의 시간 활용 계획을 달리 수립했을 텐데.

서울 지하철 9호선처럼 아예 지하철 출입구에서부터 위치 안내가 되는 건 좀 오버라고 치더라도, 최소한 대합실 층에는 있어야 한다. 개표 구역으로 들어가기 전까지는 의사 결정이 가능해야 한다.
개인적으로는 스크린도어 같은 건 없어도 되니 저 전광판이 현실적으로 더 필요했다.
너무 불편하고 싫어서 성남시에 민원이라도 넣을 생각이었다.. 아무튼, 이 기쁜 소식을 온 천하 알리세~

3. 2013년 1월 5일

지난 이 명박 대통령 시절에는 을지로/안국에서 출발하여 청와대 분수대/춘추관까지 가는 초록색 지선 버스가 있었다. 번호는 8000. 시내버스답지 않게 타이어에 무슨 고속버스처럼 은색 휠캡이 고급스럽게 장착돼 있었고, 앞부분에 '청와대' 마크가 달려 있었다.

그러나 비현실적인 노선 설정 때문에 이 버스는 한강 수상 택시와 영등포-광명 셔틀 전철을 능가하는 극심한 공기 수송에 시달렸다. 현재 영등포-광명 셔틀은 주말에는 운행을 안 하는데 얘는 반대로 주말에만 운행하다가 결국 나중엔 폐선됐다.

그런데 얘가 폐선이 확정된 날짜가 왜 하필 2013년 1월 5일이어서 철덕인 나의 눈을 번득이게 하는 걸까?
새마을호 전후동력형 디젤 동차가 운행을 완전히 중단한 날과 동일하다. 같은 날에 나란히 은퇴했다. 물론 버스의 경우는 노선만 없어졌지 물리적인 차량이 없어진 건 아니지만. 우연치곤 대단한 우연의 일치임을 뒤늦게 발견했다.

4. 언제 터널 내부 전등이 교체됐지?

서울 지하철 5호선 마포-여의나루 하저터널 구간.
원래는 노란 나트륨등이 켜져 있었는데 언제 여타 구간들처럼 흰 형광등으로 바뀌었지..???
교회 갈 때 지하철이 아닌 자차를 이용하기 시작하면서 지금까지 모르고 있었다.
그러다 오랜만에 이 구간을 이용해 보니 바로 티가 남.

<공주와 완두콩> 동화에서 진짜 공주는 담요와 매트리스 수십 장 밑에 깔려 있는 자그마한 콩알에도 배겨서 잠을 제대로 못 잤다고 한다.
그것처럼 정말 철도와 교감하는 철덕이라면 전동차의 구동음 멜로디 주파수가 자그마한 Hz만치 바뀌어도,
레일의 상태가 조금만 바뀌어도, 지하 터널 바깥 배경이 조금만 바뀌어도 바로 눈치를 챌 것이다.

(1) 그나저나 콩알이라기보다는 차라리 쇠구슬이 더 현실적이었을 거다. 콩알이었으면 그 무게를 못 버티고 그냥 으깨져 버릴 테니.
(2) 서울 한강의 아래에 존재하는 전철용 하저 터널은 총 3개이다. 지하철 5호선 마포-여의나루와 광나루-천호, 그리고 분당선의 압구정로데오-서울숲. 각각 폭약 NATM, 개착식, 실드라는 서로 다른 공법으로 건설되었다는 것도 특이하다. 광나루-천호는 강을 가림막으로 완전히 틀어막고 맨땅이 드러난 바닥을 파서 터널을 만든 뒤, 다시 터널 위를 덮어서 완공을 했는데 그래서 그런지 마포-여의나루보다는 얕고 존재감이 덜하다.

5. 답정너, 결론은 철도 자뻑

신약 성경 사도행전에 유독 자주 나오는 '이 길', '그 길'은..
this way 9:2, 22:4
that way 19:9, 19:23, 24:22
the way 24:14
분명 강철로 된 1435mm 궤간의 레일이 깔린 길이 틀림없다.
어쩌면 그 길은 그런 궤도가 두 개 깔려 있고 그 위로 25000V 60Hz 교류 전기 전차선이 깔려 있을 가능성이 높다.
사도행전이라는 책이 전반적으로 기행문 분위기이기도 해서 이런 느낌이 더욱 강하게 든다.

그리고 송명희 시인의 <나>를 생각해 보자.
난 솔직히 전반부에 나오는 것처럼 가난하고 못 배우고 병약한 처지는 아니다. 하지만 후반부 가사를 보면..

나 남이 못 본 것을 보았고, 나 남이 듣지 못한 음성 들었고
나 남이 받지 못한 사랑 받았고 나 남이 모르는 것 깨달았네

는.. 새마을호+Looking for you를 집어넣으면 너무, 딱 맞아떨어진다. 아, 음성은 아니고 그 자리에 '음악'이 들어가야 하겠다.
하나님은 역시 공평하시다. 그래서 난 한국 철도를 통해 받은 이 셀 수 없는 복을 주변에 나눠 주는 삶을 살고 싶다. 철도교의 사도 바울 같은 사람이 되고 싶다.

Posted by 사무엘

철도 얘기를 하기 위해 먼저 컴퓨터 비유를 들어 보겠다.
어떤 복잡한 컴퓨터 아키텍처가 완전 처음으로 발표되었고 이걸 타겟으로 하는 고급 언어 컴파일러를 완전 최초로 만든다고 생각해 보자. 어떤 상황일까?

이 경우, 일단 그 언어를 타겟 기계어로 옮기는 컴파일러를 그 언어와 타겟 환경 기준으로 만든다. 그런데 그 컴파일러의 소스 자체가 컴파일되지 못했으니 아직 그 언어를 타겟 기계어로 곧장 옮길 수는 없다.
이럴 때는 원래 목표로 하는 아키텍처보다 구조가 훨씬 더 간단한 가상 기계 내지 임시 P-code 아키텍처를 설계한 뒤, (1) 원래 언어를 임시 기계어로 옮기는 컴파일러와 (2) 임시 기계어 코드를 돌리는 가상 머신을 타겟 기계용으로 야메로 만든다. 둘 다 성능 따위는 쌈싸먹어도 되고 그냥 정확하게 돌아가기만 하게 극도로 단순하게 후딱 만들면 된다.

그 뒤, 원래의 컴파일러 소스를 (1)을 이용하여 컴파일하면 임시 코드 기반이긴 하지만 일단 타겟에서 돌아가고 원래 타겟 기계어를 생성하는 컴파일러가 완성된다. 이렇게 생성된 컴파일러를 이용하여 원래 소스를 다시 컴파일하면.. 드디어 타겟 기계에서 돌아가는 타겟 기계어 컴파일러가 완성된다. 자기 자신도 컴파일할 수 있고, 다른 소스도 컴파일할 수 있고.. 이제 컴파일러 2.0은 1.0을 이용하여 개발한 뒤, 그 2.0 소스를 2.0 컴파일러로 다시 빌드하는 식으로 만들면 되는 것이다.

자, 이런 얘기가 철도와 무슨 상관이 있는 걸까?
컴퓨터가 난수를 생성하기 위해 먼저 난수가 필요하고, 자동차나 발전기가 동력을 생산하기 위해서 먼저 최소한의 동력이 필요하며, 또 고급 언어로 작성된 고급 언어 컴파일러는 먼저 동작하기 위해 자기 자신의 소스부터가 컴파일되어야 한다.
그와 마찬가지로 철도 역시 부설을 위해서 다른 보조 철도가 먼저 필요하여 건설된 경우가 드물지만 있다.

가까운 예로는 서울 지하철 7호선의 온수-신풍 구간 개통 때의 일이다. 전동차를 천왕 차량기지에다 반입하기 위해 경인선 오류동 역에서 기존 경기화학선 선로를 이용하여 차량을 최대한 접근시켰다. 거기에서 최종 목적지까지는 임시 선로를 지상에다가 깔아서 옮겼다.
그러니 1990년대 중반에 거기 주변을 살았던 사람들은 거대한 지하철 전동차가 마치 지상 전차처럼 이동해 가는 걸 볼 수 있었을 것이다. (실제로 차량의 견인은 디젤 기관차가 했겠지만)

이에 대한 자세한 자료는 한 우진 님 블로그, 그리고 '전동차를 사랑하는 모임' 다음 카페의 게시글을 성지순례 하시기 바란다.
차량 반입이 끝난 뒤엔 그 임시 선로는 곧장 철거되어 사라졌다.

그리고 다음 예는 1900년대 초, 일제에 의해 경부선 철도가 건설되던 시절의 일이니 지금으로부터 까마득히 먼 옛날이다.
흔히 우리나라 철도에서 스위치백이라고 하면 영동선에만 딱 한 군데 있다가 지금은 없어진 그 스위치백만을 떠올리기 쉽다. 그러나 영동선은 대한민국 정부 수립 이후에 건설된 철도이고, 더 옛날의 일제가 한반도에다 건설한 철도 중에도 스위치백이 없지는 않았다. 단지 그것들은 한반도의 최하 중· 북부 구간 한정이었기 때문에 지금 우리로서는 실감이 잘 안 날 뿐이다. 대표적인 예가 지금은 흑역사가 된 금강산선이고 말이다.

그런데 중앙선도 아니고 경부선의 건설 과정에서 작업을 위해 인근에 보조 철도가 그것도 스위치백 형태로 건설된 적이 있었다.
바로 경북 청도군에 있는 삼성-남성현 역 사이에 터널을 뚫는 구간이다.
서울 사람이라면 강남에 있는 지하철 2호선 삼성 역밖에 기억이 안 날지 모르나, 철덕이라면 경부선의 대구 이남에 있는 삼성 역도 알 것이다.

거기는 경부선 본선이 부설되는 공사 현장의 지대가 높고 좁고 험준하여 공사 자재를 운반하는 것부터가 고역이었다.
그래서 무려 8단계의 스위치백을 거쳐서 터널의 남북 양 끝을 우회하여 연결하는 임시 선로를 먼저 만들게 되었다. 이건 당시 일본의 입장에서도 처음 시도하는 대공사였다고 한다.

경부선의 대전-대구도 아니고 대구-부산 사이에 이런 곳이 있었다는 게 신기하다. 컴파일러로 비유하자면 산을 직통으로 뚫는 터널은 본디 기계어요, 우회하는 임시 선로는 그 임시 P코드인 셈이다.
그 스위치백은 경부선의 완공 이후에는 응당 철거되었고 철거된 지 무려 100년이 넘었지만, 오늘날까지도 흔적을 아주 약간은 확인할 수 있는 정도라고 한다. 자세한 것은 이 블로그 글을 참고하시기 바란다.

Posted by 사무엘

1. 신호등

교통수단이 발달하면서 보행자용 신호등, 자동차용 신호등, 심지어 철도 차량용 신호등이 다 있다. 신호등은 처음 등장한 건 19세기 말이고, 지금과 같은 전기식 신호등에 지금과 같은 색깔 관행이 정착한 건 20세기 초쯤이다. 처음에는 정지 신호가 빨강이 아니던 시절도 있었는데, 철도던가 자동차던가 어디서 한번 신호 오인 때문에 대판 사고가 난 뒤에 빨강으로 변경됐다는 걸 읽은 기억이 있다.

다른 신호등은 그냥 별 특징 없는 색깔등에 불과하지만 보행자용 신호등은 색깔뿐만 아니라 사람이 선 모양과 걷는 모양이 추가적으로 그려져 있다. 모든 나라에서 그렇지는 않을 수도 있지만 아무튼 우리나라는 그렇다. 색깔뿐만 아니라 정말 motion으로도 이때는 건너도 되거나 반드시 서야 한다는 걸 표시하고 싶었나 보다. 그래서 단순히 X나 O 모양도 아니고 굳이 사람 모양을 그렸다.

그런데 이것 아시는지? 우리나라 횡단보도의 신호등은 처음에는 색깔이 배경으로 그려져 있고 사람 형상은 검정 고정이었다. 그랬는데 나중에 신호등이 쫙 교체되면서 검은 배경에 사람 형상이 빨강 내지 초록인 형태로 바뀌었다.

이건 특별한 이유는 없고, 신호등이 단순한 전등에서 전기를 덜 잡아먹는 LED 소자 기반으로 교체되었기 때문이다. 단순히 전구 하나를 켜는 게 아니라 사람 그림 모양의 픽셀을 표시하는 방식으로 바뀌면서 신호등의 점등 모양도 지금처럼 바뀌었다.
그러면서 대부분의 보행자 신호등에는 남은 시간도 게이지 내지 숫자로 표시되게 UI가 개선되었다. 2000년대까지만 해도 이런 신호등을 보기가 쉽지 않았는데 어느 샌가 다 교체되었다.

신호등은 전국의 교차로와 횡단보도에 이거 뭐 한두 개가 있는 게 아니며, 마치 냉장고처럼 사실상 24시간 반영구적으로 가동되는 물건이다 보니 거시적으로 볼 때 전력 소모가 엄청나다. 그러니 조금이라도 전기를 덜 먹는 방식으로 교체하면 투자 비용을 생각보다 짧은 시간 만에 회수할 수 있다.
백열등도 효율이 너무 안 좋다고 국가에서 나서서 퇴출시키는 마당에 하물며 신호등이겠는가. (그나저나 처음 켤 때 깜빡거리는 형광등도 마지막으로 본 지 굉장히 오래 됐다. 세상 참 많이 변했다)

보행자에 이어 자동차용 신호등에도 빨간불이나 파란불에 남은 시간이 표시된다면 어떨까?
악명 높은 노란불 딜레마를 예측하고 대처하는 데 유리해지는 면이 분명 있겠지만, 운전자들이 저걸 보고는 더 조급해져서 사고가 날 가능성도 더 커질 것이다. 그래서 차라리 모르고 있으라고 도입을 안 하는 게 아닌가 싶다.

경상북도 봉화군은 얼마나 차량 통행이 없고 한적했으면, 대부분의 도로 교차로가 그냥 황색 점멸일 뿐이라고 한다. 그 지경이라면 차라리 로터리를 만들면 신호등을 운영할 필요가 없고 좋을 텐데. 단, 로터리는 공간 소모가 더 크다는 단점이 있다.

빠른 교통수단은 단위 시간 동안 더 긴 거리를 이동하며 더 많은 공간을 점유한다. 그렇기 때문에 얘가 차지하는 트래픽 때문에 느린 교통수단은 신호 대기 때문에 표정속도가 더 떨어지는 효과가 난다. 이것도 일종의 빈익빈 부익부 현상인지는 모르겠다.
자동차 신호 때문에 자동차를 이용하지 않는 보행자는 교차로에서의 신호 대기 때문에 동일 구간에서의 통행 소요 시간이 더 길어진다.

철도만 해도 KTX 때문에 기존선 구간에서는 일반열차들의 통행 시간이 더 길어진다. 영등포 역에서 KTX를 먼저 보내 주고 출발하느라 하위 열차들은 몇 분간 더 기다려야 하기 때문이다. 이것은 교통 분야에서 공통적으로 찾을 수 있는 현상이다.

2. 자동차의 국제화

컴퓨터 소프트웨어는 국제화를 용이하게 하기 위해 각 나라의 언어마다 달라지는 GUI 요소들을 별도의 파일로 분리하곤 한다. 소스 코드를 고쳐서 재빌드를 하지 않고도 이 데이터만 추가하거나 교체하면 새로운 언어에 대한 지원을 얼마든지 할 수 있게 말이다. 그나마 문자 코드 하나는 유니코드 덕분에 천하통일이 이뤄진 관계로 일이 예전보다 많이 수월해졌다.

그런데 자동차에도 이렇게 각 국가별로 따로 세팅을 해야 하는 요소가 있다. 물론 자동차 내부에서 동작하는 내비게이션 소프트웨어 같은 건 프로그램 차원에서 다국어 UI를 갖춰야겠지만, 그런 것 말고 대시보드나 계기판에 있는 간단한 표현들은 그냥 영어 원어 표현을 냅두지 그런 걸 일일이 다 현지 언어로 바꾸지는 않는다.
그것보다 더 결정적으로 중요한 것은 바로... (1) 운전대의 위치와 (2) 속도계 숫자의 단위이다.

세계적으로는 자동차가 우측통행을 하는 나라가 대부분이긴 하지만 좌측통행을 하는 소수의 나라들이 영국과 영연방, 과거에 영국 식민지였던 나라, 그리고 영국식으로 근대화를 한 일본처럼... 존재감을 절대로 무시할 수 없는 나라들이다. 그러니 좌측통행용 우핸들도 반드시 고려해야 한다.
이건 마치 글자를 쓰는 방향이 L2R이냐 R2L이냐 하는 문제 같다. 아랍권에서는 프로그램의 세로 스크롤 막대가 창의 오른쪽 구석이 아니라 왼쪽 구석에 있다.

요즘 자동차 중에는 운전석 쪽 대시보드와 조수석 쪽 대시보드의 외형이 대칭이 되게 해서 좌핸들과 우핸들을 동일 생산 라인에서 최대한 저렴하게 동시 처리 가능하게 설계된 경우가 있다. 이건 마치 양손잡이용 가위 내지 마우스 같은 컨셉이라고 생각하면 되겠다.

우리나라가 일제 강점기가 더 오래 지속되고 일제 치하에서 도로 시설이 확충되고 자동차가 대중화됐다면, 한반도까지 좌측통행 지역으로 굳어졌을 가능성이 높다. 그러나 해방 당시까지 한반도에는 등록된 자동차 수가 1만 대가 채 되지 않았으며, 서울을 제외하면 압도다수의 길이 여전히 차선이고 신호등이고 뭐고 없는 비포장이다 보니 여전히 자동차의 통행 방향은 그냥 정하기 나름이었던 것 같다.

그래서 미군정이 들어선 지 얼마 안 되었던 1946년 4월에 한반도에서 자동차의 통행 방향은 우측으로 개정되었다. 그래야 우측통행을 하는 미국에서 들여온 좌핸들 차량들이 별다른 불편 없이 한반도에서 곧장 다닐 수 있었을 테니까 말이다.

그럼 철도는 사정이 어떨까? 철도야 조향이라는 게 존재하지 않기 때문에 운전대가 어디에 있든지 별 의미가 없다. 국내에는 수도권 전철 4호선처럼 한 전동차가 좌측통행 구간(국철 과천· 안산선)과 우측통행 구간(서울 지하철 4호선)을 아예 직통 운행까지 한다. 자동차로서는 상상도 못 할 일이다.
또한 해방 당시엔 통행 방향의 구분이 필요한 복선 철도 자체가 경부· 경의선 말고는 없었기 때문에 그때 마음만 먹고 좀 매몰비용을 감수했다면 철도의 통행 방향도 우측으로 과감하게 확 뜯어고치는 게 불가능하지는 않았다.

그러나 철도는 여전히 좌측통행으로 그대로 유지되었다. 자동차처럼 차량의 운전대 방향을 꼭 맞춰야 할 필요가 없었고, 또 기존 철도역들의 시설을 고치는 게 번거로웠기 때문이다. 또한 이건 정말로 그냥 하나로 정하기 나름일 뿐, 무슨 협궤-표준궤 개궤라든가 100-220V 승압처럼 미래를 내다보고 꼭 바꿔야 할 과업까지는 아니기도 하니까.
우리나라는 일본보다 근대화· 산업화가 한 박자 늦었던 대신, 그래도 전압이나 철도 궤간 같은 건 깔끔하게 통일이 잘 됐고 승압 같은 것도 너무 늦어지기 전에 잘 해냈으니 이건 다행스러운 점이다.

좌측 우측 얘기가 길어졌고, 다음으로 속도계 단위이다. 이건 잘 알다시피 세계에서 거의 유일하게 미터법을 안/못 받아들이고 있는 나라가 세계 최강대국이다 보니.. 빼도 박도 못하고 생긴 고려 사항이다.
미국의 자동차 속도계를 보면 바깥에 큰 숫자로 마일이 적혀 있고, 안쪽에 작은 숫자로 킬로미터가 적혀 있다. 미국 이외의 나라에서 다니는 자동차에다가는 굳이 그렇게 안 해 줘도 된다. 미국의 프리웨이는 속도 제한도 시속 55~65마일이라고 적혀 있는데 그게 얼추 시속 100km에 대응한다.

3. 차선의 색깔, 가변 차로 등

외국의 자동차 주행 동영상을 보면서 본인이 굉장히 놀란 점이 있는데..
중앙선 차선이 우리나라처럼 황색 실선이 아니라 그냥 흰색 실선이기 때문이다. 내 기억이 맞다면 북한도 그랬던 것 같다. (물론 거기는 아예 차선이 안 그려지고 길만 덩그러니 놓여 있거나, 그냥 중앙분리대가 따로 있는 경우가 더 많지만)

흰색 실선은 같은 방향인데 차선 변경을 할 수는 없는 터널 같은 구간에서 쓰는 게 아닌가?
하나만 그은 것과 두 줄을 그은 것으로 구분할 수 있을지는 모르겠지만 일단 나 같은 사람은 좀 혼동할 것 같다.
실제로 이것 때문에 우리나라에서 차를 외국으로 수출할 때, 고급차에 들어가는 중앙선 침범 감지 장치의 알고리즘까지 고쳐야 한 사례가 있었다.

또한 우리나라에서 중앙선이 아니라 도로의 가장자리에 그어진 황색 실선은 이 도로가 주· 정차 금지 구간임을 뜻하고, 황색 점선은 잠시 정차만 가능하다는 걸 뜻한다. 흰색 선이거나 가장자리에 선이 없으면 그런 제약이 없다는 뜻이고.
차선 색깔의 구분이 없으면 그런 것도 표현을 못 할 텐데 말이다.

다음으로 생각할 만한 사항은 가변차로이다.
가변차로는 양쪽의 방향이 같은 것이 있고 다른 것이 있다. 전자는 고속도로에서 시간대별로 갓길과 차로를 병행하는 구간으로, 점선이든 실선이든 흰색 선이 그어져 있다. 예전에 고속도로에 간간이 있었던 버스 정류장 부지가 지금은 진짜 갓길 내지 졸음 쉼터로 재활용되는 추세이다. 갓길이 차로 모드가 아니라 갓길 모드일 때 무단으로 통행했다가는 나중에 피본다.

한편, 후자는 시간대별로 상· 하행의 교통량의 편차가 큰 시내 구간에서 중앙의 몇 개 차선을 방향별로 가변적으로 운행하는 구간이다. 차선으로는 황색 점선이 그어져 있다. 전체 차선 수가 애매하게 홀수 개가 됐다거나 할 때도 가변차로를 검토할 만하다.

후자 가변차로는 일상생활에서 많이 볼 수 있지는 않다. 서울에서 대표적인 곳은 서울 지하철 2호선 신당-상왕십리-왕십리 구간의 지상 도로 정도이다.
여기는 운전자가 헷갈리면 차선을 잘못 진입해서 자동차끼리 정면충돌 사고가 날 수 있어 88 올림픽 고속도로 뺨치게 대단히 위험하다. 위에 지금 진입 가능 방향과 금지 방향이 전광판으로 표시되어 있으니 그걸 잘 봐야 한다. 오거리· 육거리에서 어느 신호등이 우리 방향 것인지를 헷갈려서 잘못 진입하는 식의 실수를 해서는 안 된다.

물론 가변차로라고 해서 대책 없는 막장으로만 운영되는 건 아닌지라, 한 차로의 통행 방향이 바뀔 예정이라면 그로부터 한참 전부터(거의 10분 가까이) 완충 타이밍을 둔다. 모든 방향으로부터 차들의 통행을 금지시키 시작하여, 해당 구간 전체가 텅 비었을 때 비로소 방향을 반대로 바꾼다. 재미있지 않은가?

지하철만 해도 승강장이 섬식이면 한 승강장을 양방향 승객이 모두 공유하는 관계로, 출퇴근 때처럼 방향별 이용객 수의 편차가 클 때 공간 활용 효율이 더 올라간다. 그리고 선로가 단순히 복선이 아니라 3선이라면, 한 선로를 무정차 회송 선로로 활용하여 몰리는 방향의 열차를 반대 방향 열차보다 더 자주 투입시키는 게 가능하다.

가변차로는 자동차의 통행에서 비슷한 효과를 노린 발상이라 할 수 있다. 하지만 시설을 구축하는 데 든 노력에 비해 효과가 크지 않고 심리적으로 위험하다고 느껴지는지라 요즘은 더 만들지 않고 기피되는 추세이다. 마치 옛날에 산업화· 근대화의 상징이었던 서울 시내 고가도로들이 요즘은 반대로 철거되는 추세이듯이 말이다.

아이고, 차선 하나만 갖고도 색깔부터 시작해서 할 얘기가 굉장히 많았다.
자동차가 어느 정도 신호 대기 없이 쭉쭉 달리는 곳이라면 어지간한 4차선짜리 국도에도 요즘은 단순 중앙선 대신 중앙분리대가 설치되곤 한다.

졸음운전 내지 빗길에 미끄러진 차가 중앙분리대를 들이받고 멈춰선 경우가 지금까지 한둘이었던가. 중앙분리대는 중앙선 침범 정면충돌 교통사고를 예방해 주는 긍정적인 효과가 크다는 걸 알 수 있다.
또한 중앙분리대는 밤에 반대 방향 차들의 헤드라이트 불빛을 가려 주는 역할도 해서 더욱 좋다.
양방향 사이에 화단을 조성하거나 아예 방향별로 도로를 따로 만든 경우도 있는데, 우리나라에서는 그렇게 흔치 않다.

실선 차선 구간이라 하더라도 자동차 운전 중에 차선을 변경하려면 C/C++에서 서로 다른 타입의 포인터끼리 대입할 때처럼 깜빡이라는 형변환 연산자를 꼭 넣어 줘야 할 것이다. 안 하면 최소한 쌍라이트+쌍욕+경적이라는 warning과, 최악의 경우 사고라는 에러가 날 가능성이 커진다.

Posted by 사무엘

뭐, 무식이 자랑이랄 수는 없겠지만,
본인은 전산학 내지 컴퓨터공학의 여러 분야들 중에서 문외한에 가깝게 제일 모르는 분야는 통신, 네트워크, 웹, 보안 쪽이다.
왜 제일 모르느냐 하면, 저건 컴퓨터 한 대만으로 독학이 가능하지 않고, 뭔가 '감'을 터득할 수 없는 분야이기 때문이다. 그래서 그런 걸 잘하는 사람들이 부럽다..

일례로 완전 최저수준 소켓 API와, 고수준 HTTP API 사이의 중간 과정에 대한 감이 전혀 없다. 후자도 분명 전자를 이용해서 구현됐을 텐데, 내부 구현이 어찌 돼 있는지 난 아는 게 없다.
그리고 네트워크 트래픽이 컴퓨터의 I/O 병목엔 어떤 영향을 끼치는지, 그 패킷이 어떻게 해서 한 운영체제 내부의 특정 응용 프로그램으로 잘 전달이 되는지, DDoS 공격이 서버 컴퓨터에 어떤 물리적인 영향을 끼쳐서 서버를 뻗게 할 수 있는지, (아님 단순히 프로세스/스레드의 무한 스폰으로 인해 소프트웨어적인 자원 고갈만으로 뻗는 건가?)

HTTP 프로토콜에서 파일 업로드는 어떤 절차를 거쳐서 되는지, 방화벽이라는 게 정확히 뭘 하는 물건인지,
왜 구닥다리 윈도 2000/XP sp0을 띄운 채로 랜선을 꽂으면 뭐가 뚫려서 어떻게 되는지..
요즘은 네트워크 패킷은 하부 계층에서 압축이나 암호화를 좀 하는 게 있는지 등등..

이런 것들은 난 하나도 모..른..다. 저런 거 하나도 몰라도 <날개셋> 한글 입력기 개발하는 덴 아무 지장이 없기 때문이다.
그렇다고 해서 내가 컴퓨터 명령어 체계나 운영체제/소프트웨어 자체의 내부 구조나 보안에 대해 전혀 모르느냐 하면 그것도 물론 아니니.. 지식의 분포가 좀 불균형하다면 불균형한 셈이다.

본인은 초딩 중고학년 때 개인용 PC, 중학교 때 모뎀과 PC 통신, 고등학교 때 인터넷과 이메일, 그리고 대학교 때 무선 인터넷과 휴대전화의 순으로 문명의 이기들을 접했다. 랜 선이라는 걸 태어나서 처음으로 구경한 게 고등학교 때부터인데, 그 기간 동안 언젠가 집도 인터넷 접속 방식이 전화 모뎀에서 전용선으로 바뀌었다. 그때가 한창 전국적으로 인터넷 전용선이 깔리던 시절이었으니까.

지금까지 통신 기술은 정말 눈부신 속도로 발전했다.
신문· 방송에서 기자의 이메일을 공개하는 게 대세가 된 게 1990년대 후반부터이다.
지금으로부터 10여 년 전엔 '블로그'라는 단어가 도전 골든벨의 마지막 문제의 답이었다는 게 믿어지시는가? (그것도 학생이 못 맞혔고 그 당시엔 내게도 생소했다)

옛날에는 인터넷 연결을 위해서도 PC 통신을 할 때처럼 먼저 전화를 걸어야 했다. 사용 시간 카운터가 올라가는 자그마한 인터넷 연결 창이 뜬 동안만 인터넷을 이용할 수 있었다.
또한, 모뎀과 마우스를 동시에 사용하려면 두 물건을 서로 COM 포트가 충돌하지 않게 배치를 해야 했다.
Windows 3.x에서는 운영체제 차원의 네트워크 지원이 전무하기 때문에 트럼펫 Winsock인지 뭔지 하는 걸 먼저 설치해야 했다.

이 모든 것들이 지금은 까마득한 옛날 이야기가 됐다.
지금은 뭔가 그렇게 상태를 확인하면서 인터넷을 해야 하는 상황은 스마트폰 태더링으로 무선 인터넷을 쓸 때 정도이고 이것도 제약, 압박감, 부담 같은 건 옛날과는 비교할 수 없이 작아졌다.
메인보드가 어떻게 공간 워프를 했는지, 요즘은 유선 랜과 무선 랜도 전부 내장되어 나온다. 따로 뭘 장착조차 할 필요 없이 바로 접속만 하면 된다.

오늘날 인터넷이라고 불리는 그 통신망은 OSI 레이어 계층 중 제3계층(네트워크 계층)을 차지하는 IP라는 프로토콜을 기반으로 동작한다. IPv4, IPv6 같은 주소 체계도 이 계층에서 규정하는 것이기 때문에 모든 인터넷 통신은 이 체계를 기반으로 구성되어 있다.

그리고 그 아래의 제4계층(전송 계층)에는 인터넷 프로토콜을 따르는 네트워크 패킷을 보내는 방식의 차이를 규정하는 프로토콜이 있는데, 크게 TCP와 UDP가 있다.
TCP는 보낸 패킷이 반드시 순서대로 도착한다는 것은 보장되지만, 보냈던 단위랄까 형태가 그대로 도착하지는 않는다.
aaa, bb, ccccc, ddd, e 이렇게 패킷을 보냈으면 받는 쪽은 aa, ab, bccc, cc, dd, d, e 뭐 이렇게 받을 수도 있고 다른 형태가 될 수도 있다. 조립은 받는 쪽에서 알아서 해야 한다.

UDP는 TCP와는 달리 보낸 패킷이 원래의 형태 그대로 간다는 보장은 되지만.. 일부 패킷이 전송 과정에서 누락될 수가 있다.
즉, 위의 경우 ddd가 누락돼서 aaa, bb, ccccc, e 이렇게 갈지도 모르지만.. 일단 간 놈은 원래 형태 그대로 간다. 패킷의 누락 여부 판단을 받는 쪽에서 알아서 해야 한다.
그래서 TCP는 일종의 스트림 지향적이며, UDP는 개개의 패킷이 모 아니면 도 형태로 가는 메시지 지향적이다.

형태도 보존되고 누락 현상도 없는 만능 프로토콜이 없는 이유야 뭐, 세상에 값도 싸고 성능도 좋은 물건은 존재하지 않기 때문인 것과 같은 맥락일 것이다.
그게 필요하면 UDP 같은 걸 기반으로 패킷 누락을 감지하고 재전송을 요청하는 로직을 응용 프로그램이 별도로 구현해 줘야 한다.

온라인 게임에서는 “기관총 난사 내지 캐릭터 이동 같은 것만 UDP이고 나머지는 다 TCP”라는 말 한 마디로 요약된다.
자주 발생하기 때문에 반응성이 중요하고 적당히 좀 씹혀도 상관 없는 것만 UDP이고.. 나머지 크리티컬한 것들은 다 TCP를 써야 한다는 뜻이다.
그러나 온라인 게임에서 발생하는 트래픽의 상당수, 대략 70% 가까이는 그래도 UDP 방식이라고 한다.

실시간으로 스트리밍되는 대용량 오디오/비디오 데이터도 자명한 이유로 인해 UDP 방식으로 전송된다.
이런 차이를 보면, TCP와 UDP의 관계는 사실상 무손실 압축과 손실 압축의 관계나 마찬가지인 것 같다.

TCP의 경우 응용 프로그램이 아니라 아래의 프로토콜 차원에서 패킷의 누락을 감지하여 누락이 있는 경우 재전송 요청을 한다.
그런데 모바일처럼 네트워크 환경이 원래 워낙 열악해서 패킷 손실이 굉장히 자주 발생하는 곳에서는
TCP 방식에서는 끝도 없이 재전송 요청을 하고 받은 데이터에 결함이 없는지 체크와 빠꾸만 반복하느라 응용 프로그램이 그 동안 멍하니 있어야만 하는 일이 발생한다고 한다.
즉, TCP가 구조적으로 오버헤드가 더 크니, 네트워크가 열악한 곳에서는 그런 동작을 감안해야 한다.

게임에서 그래픽 엔진, 물리 엔진, 동영상/캡처 엔진도 아니고 네트웍 엔진 미들웨어로 먹고 사는 분이 국내에 일단 한 분 계신다. 넷텐션의 대표이사인 배 현직 씨. 이 업계에서는 이미 유명인사이다.

난 네트워크 쪽 프로그래밍을 해 본 건 먼~ 옛날에 소켓 API 대충 뚝딱해서 오목을 만들고..
DirectPlay를 써서 스크래블 정도 보드 게임에다가 네트웍 플레이를 넣어 본 게 전부이다. 그래도 그것만으로도 굉장히 재미있는 경험이었다.
저수준에서 패킷 암호화, 각종 오류 처리 그런 건 모른다. DPlay는 나름 하드웨어 독립을 추구한 통신 API이긴 한데, 요즘은 모뎀이고 시리얼 케이블 그딴 건 다 없어졌으니 그런 추상화 계층이 필요가 없어지면서 자연스레 도태했다. 잘은 모르겠지만 제1계층(물리 계층)은 거의 획일화가 돼 버린 것 같다.

※ 여담. IPX는 어디로 갔는가?

스타크래프트에서 배틀넷 말고 그냥 LAN으로 친구들끼리 팀플을 할 때, 옛날에는 배틀넷 다음으로 위에서 둘째인 IPX를 으레 고르곤 했다. 그러나 어느 패치 때부터인가 맨 아래에 UDP가 추가되었으며 그걸 고르는 걸로 구조가 바뀌었다. IPX는 동작하지 않기 시작했다. 어찌 된 일일까?

IPX라는 프로토콜은 똑같이 이더넷 랜선으로 통신을 하지만, 오늘날의 인터넷과는 다른 방식으로 통신을 한다. 즉, IP와 대등한 제3계층에서 방식이 다른 프로토콜인 것이다. IPX는 옛날에 네트워크 솔루션으로 유명했던 노벨 사에서 개발했고 실제로 매우 널리 쓰이기도 했지만 오늘날은 IP에 밀려서 사라졌다.

Windows 95때까지만 해도 네트워크 구성요소들을 설치하고 나면 기본으로 깔리는 것은 IPX였다. TCP/IP 지원 기능은 운영체제 CD를 넣어서 별도로 설치해야 했다. 무슨 말이냐 하면, 오늘날 당연시되고 있는 이 컴퓨터의 IP 주소를 설정하는 기능이 Windows 95에는 기본으로 없었다는 뜻이다. (심지어 네트워크 기능이 설치된 컴에서도)

그 다음 1990년대 중후반, Windows 98부터는 인터넷의 중요성이 워낙 크게 부각되기 시작했으니 TCP/IP 지원도 같이 포함되었다.
여담이지만 Windows에서는 등록정보/속성을 나타내는 단축키가 R인 편인데, 95에서는 유독 저 대화상자에서만 R은 삭제이고, 등록정보는 P였다. 무척 불편했는데 이 역시 98부터는 다같이 R로 개선됐다.

하긴, 본인도 옛날부터.. Windows가 근거리 네트워크 차원에서 제공하는 컴퓨터 간의 폴더 공유 기능과, 웹브라우저로 띄우는 인터넷은 기술적으로 무슨 관계인가 궁금하긴 했다.
인터넷 열풍 앞에서 IPX는 점점 잉여로 전락했으며, Vista부터는 드디어 IPX 지원이 hlp 도움말만큼이나 짤렸다. 그래서 스타크래프트도 근거리 팀플에 인터넷 프로토콜을 사용하는 UDP 지원이 추가된 것이다.

Posted by 사무엘

1. 오픈소스

잘 알다시피 C/C++은 메모리 할당이나 문자열 등, 바이너리 차원에서 뭔가 언어나 구현체가 buliding block을 규정해 놓은 게 없다시피하며, 그나마 표준이 나온 것도 강력한 구속력을 갖고 있지는 못하다. 그러니 이 지저분함을 참다 못해서 COM 같은 바이너리 규격이 나오고 닷넷 같은 완전히 새로운 프레임워크도 나왔다.

아니면 일각에서는 소프트웨어 컴포넌트를 재배포할 때, 빌드된 라이브리러리를 주는 게 아니라 난독화 처리만 한 뒤 소스 코드를 통째로 넘겨주면서 빌드는 이 코드를 쓰는 쪽에서 자기 입맛대로 알아서 하라는 극단적인 조치를 취하기도 한다. 차라리 오픈소스 진영이 이런 점에서는 융통성이 더 있는 셈이다.
하지만 어지간한 컴덕력을 갖추지 못한 사람은.. 복잡한 빌드 시스템/configuration들을 이해할 수 없어서 소스 코드까지 통째로 줬는데도 줘도 못 먹는 촌극이 벌어진다.

이런 라이브러리 내지 유닛, 패키지는 기계어 코드로든 다른 바이트 코드로든 소스 코드가 바이너리 형태로 용이하게 재사용 가능한 형태로 가공되어 있는 파일이다.
그런데 실행문이 들어있는 소스 코드가 반드시 그대로 노출돼야만 하는 분야도 있다.

크게 두 갈래인데, 하나는 C++의 템플릿 라이브러리이고, 다른 하나는 웹 프로그래밍 언어 중에서도 전적으로 클라이언트 사이드에서 돌아가는 자바스크립트이다.
동작하는 환경 내지 타겟은 둘이 서로 완전히 극과 극으로 다르지만, 전자는 컴파일 때 최적화 스케일의 유연성 때문에, 그리고 후자는 선천적으로 기계 독립적이고 극도로 유연해야만 하는 웹의 특성상 오픈소스가 강제되어 있다.

자바스크립트는 비록 전통적인 기계어 EXE를 만드는 데 쓰이는 언어는 아니지만 그렇다고 해서 만만하게 볼 물건이 절대로 아니다. 람다, 클로저 등 어지간한 최신 프로그래밍 언어에 있는 기능은 다 있으며, 플래시에 하드웨어 가속 3D 그래픽까지 다 지원 가능한 경지에 도달한 지가 오래다.
또한 웹에서의 영향력이 워낙 막강하다 보니 전세계의 소프트웨어 업체들이 눈에 불을 켜고 실행 성능을 필사적으로 끌어올려 놓았다. 비록 컴파일을 통한 보안 유지는 안 되지만, 어느 수준 이상의 코드 난독화 기능도 당연히 있다.

뭐, C++ 표준 템플릿 라이브러리도 헤더 파일을 열어 보면, 남이 못 알아보게 하려고 코드를 일부러 저렇게 짰나 싶은 생각이 든다. 온갖 주석이 곁들여져서 알아보기 쉽게 널널하게 작성된 C 라이브러리의 소스들과는 형태가 달라도 너무 다르다..

C++ 템플릿에 대해서 한 마디 더 첨언하자면.. 제한적으로나마 함수나 몸체를 일일이 인클루드해서 노출하지 않아도 되는 방법이 있긴 하다.
몸체를 한 cpp(= 번역 단위)에다가만 구현해 놓은 뒤, 거기에다가 소스 코드 전체를 통틀어 그 템플릿이 인자가 주어져서 쓰이는 모든 형태를 명시만 해 주면 된다.

template Sometype<char>;
template Sometype<wchar_t>;

템플릿 함수에 대해서 template<> 이렇게 시작하는 특정 타입 전용 케이스를 만드는 것과 비슷해 보이는데..
위와 같은 식으로 써 주면, 해당 코드가 컴파일될 때 이 템플릿이 저런 인자로 실현되었을 때의 대응 코드가 모두 생성되고, 이게 다른 오브젝트 파일들이 링크될 때 같이 연결되게 된다. 이런 문법이 있다는 것을 15년 동안 C++ 프로그래밍을 하면서 처음 알았다.

물론 저것 말고 다른 임의의 새로운 타입으로 템플릿을 사용하고 싶다면 그렇게 템플릿을 사용하는 번역 단위에서 또 다시 템플릿의 선언부와 몸체를 싹 읽어들여서 분석을 해야 한다.
아마 과거의 export 키워드가.. 저런 템플릿 인자의 사용 형태를 자동으로 파악하는 걸 의도하지 않았나 싶은데 그래도 세상에 쉬운 일이란 없었던 듯하다.

2. 웹 프로그래밍의 성격

HTML, CSS, 자바스크립트 삼신기는 마치 웹 프로그래밍계에서의 삼권 분립이기라도 한 것 같다. 아무래도 당장 화면에 표시되는 핵심 컨텐츠가 HTML이니 요게 행정부에 대응하는 듯하며, HTML을 표시할 규격을 정하는 CSS는 사법부에 가깝다. 끝으로, 인터랙티브한 동작을 결정하는 자바스크립트는 입법부 정도?
물론 HTM 파일 하나에다가 스타일과 자바스크립트 코드를 다 우겨 넣었다면 그건 뭐 “짐이 곧 국가다, 법이다” 식으로 코드를 작성한 형태일 것이다.

예로부터 본인이 느끼기에 웹 프로그래밍은 뭔가 시대의 최첨단을 달리는 것 같고 간지와 뽀대가 나고 실행 결과가 사용자에게 가장 직접적으로 드러나 보이는 신기한 영역인 것 같았다. 하지만 (1) 코드와 데이터, 클라이언트와 서버, 코딩과 디자인의 역할 구분이 영 모호하며, 컴퓨터의 성능을 100% 뽑아내는 듯한 전문적이고 하드코어한 느낌이 안 들어서 마음에 안 들었다. 가령, 도대체 어디서는 java이고 어디서는 jsp이고 어디서는 js인지?

(2) 또한 이 바닥은 작성한 소스 코드가 제대로 보호되지 못한다. 서버 사이드에서만 돌아가는 PHP 같은 건 클라이언트에게는 노출이 안 되겠지만 그것도 서버 개발자들끼리는 결국 오픈소스 형태로 공유될 수밖에 없으니 말이다. 옛날에 제로보드의 소스가 그랬듯이.

끝으로, (3) 특정 CPU 아키텍처나 플랫폼에 구애되는 게 없다 보니 기반이 너무 붕 뜨는 느낌이고, 브라우저마다 기능이 제각각으로 달라지는 거 호환 맞추는 노가다가 필요한 것도 싫었다.
뭐, IE와 넷스케이프가 경쟁하고 IE6이 세계를 사실상 평정했던 먼 옛날에는 그랬고 지금은 이 문제는 많이 해소됐다. 바야흐로 2015년, HTML5 표준안까지 다 완성된 지경이니, 웹 프로그래밍도 이제 충분히 성숙했고 기반이 탄탄히 잡혔다. 격세지감이다. ActiveX도 점점 퇴출되는 중이다.

2004년에 IE6에 대한 대항마로 파이어폭스 0.8이 혜성처럼 등장했고, 2008년엔 구글 크롬이 속도 하나로 세계를 평정해서 IE의 독점 체계를 완전히 견제해 냈다. 지금은 크롬이 속도는 괜찮은 반면, 메모리 사용량이 너무할 정도로 많아서 파이어폭스가 다시 반사 이득을 보는 구도이다. 오페라는 Windows에서는 영 좀 마이너한 콩라인 브라우저가 아닌가 모르겠다.
그리고 무슨 브라우저든지 버전업 숫자 증가폭이 굉장히 커졌으며, 탭 브라우징에  메뉴와 제목 표시줄을 숨겨 놓는 인터페이스가 필수 유행이 돼 있다.

3. 보안 문제

세월이 흐르면서 웹 프로그래밍 환경이 좋아지고 있는 건 사실이지만, 보안 때문에 예전엔 바로 할 수 있었던 일을 지금은 못 하고 뭘 허가를 얻고 번거로운 절차를 거쳐야 하는 건 다소 불편한 점이다.
특히 내가 느끼는 게 뭐냐 하면, 한 HTML 파일에서 자신과 다른 도메인에 있는 CSS나 JS 같은 걸 덥석 인클루드 하는 걸 브라우저가 굉장히 싫어하게 됐다는 점이다. 이런 걸 이용한 보안 취약점 공격이 지금까지 많았는가 보다.

"이 사이트에는 안전한 컨텐츠와 위험한 컨텐츠가 같이 섞여 있습니다. 위험한 것도 모두 표시하시겠습니까?"라는 메시지가 바로 이런 상황에서 뜬다.
IE의 경우 예전에 잘 표시되던 사이트가 갑자기 표시되지 않을 때, 권한 취득을 위해 레지스트리에다 자기 프로그램 이름이나 사이트를 등록하는 등 조치를 취해야 했다.
구글 크롬은 발생 조건이 IE와 동일하지는 않지만, 자체 판단하기에 악성 코드의 실행을 유도하는 걸로 의심되는 지시문이 HTML 소스에 있는 경우, 화면 전체가 위험 경고 질문 화면으로 바뀐다.

최근에는 크롬과 IE에서는 멀쩡하게 보이는 웹 페이지가 파이어폭스에서만 제대로 표시되지 않는 문제가 있어서 회사 업무 차원에서 사이트 디버깅을 한 적이 있었다. 요즘 세상이 무슨 세상인데 웹 표준이나 렌더링 엔진의 버그 때문일 리는 없고, 파이어폭스가 자바스크립트 엔진으로 하여금 외부 도메인로부터 인클루드된 CSS 속성에 접근하는 걸 허용하지 않아서 발생한 문제였다.

4. 파일 관리가 되는 게시판

본인도 여느 프로그래머와 마찬가지로 다니는 회사에서 요즘 모바일에 웹까지 별별 걸 다 손대며 지냈다. 하긴, 공학 박사라 해도 취업 후에는 돈 되는 분야, 뜨는 분야를 따라 자기 주전공 연구 분야가 아닌 것도 손대 봐야 할 텐데 하물며 그보다 급이 낮은 단순 엔지니어들은 말이 필요하지 않을 것이다.

요즘은 게시판이나 블로그 엔진을 만들려면 단순무식한 텍스트 기본 폼이 아니라 위지윅 웹 에디터가 필수이다. ckeditor 컴포넌트에다가 이미지 업로드 기능을 연결해 넣을 일이 있었는데 이것도 여간 골치아픈 일이 아니라는 걸 작업을 하면 할수록 깨닫게 됐다.
손이 정말 많이 간다. 하지만 그걸 일일이 하지 않으면 이미지는 단순 외부 링크밖에 못 넣는 반쪽짜리가 된다.

이미지 파일이 하나 HTTP 규격대로 업로드되어 왔으면 서버 측에서는(PHP든 JSP든 무엇이든) 파일 크기가 적당한지(개별 파일 크기와 지금까지 업로드된 파일의 전체 크기 모두) 체크하여 적당하다면 이름을 중복 없는 랜덤 이름으로 바꿔서 서버에 저장한다. 이름에 한글이 들어간 파일이라고 업로드나 로딩이 제대로 안 되는 일이 없어야 하니까.

그 뒤에 그 그림을 불러올 수 있는 URL을 에디터 컴포넌트에다가 알려 준다. 이것도 간단하게 만들자면 그냥 서버의 특정 디렉터리를 그대로 노출하는 식으로 만들면 되겠지만 보안상 위험하니 가능한 한 제3의 장소에서 파일을 되돌리는 서버 프로그램 URL을 주는 게 안전하다.

위지윅 에디터에서는 임의의 개수의 파일이 업로드될 수 있기 때문에 글에 얽힌 첨부 파일들을 따로 디렉터리나 DB 형태로 관리해서 글이 삭제될 때 같이 지워지게 해야 한다.
사실, 이쪽으로 조금만 더 신경 쓰면 글별로 아예 첨부 파일 관리자라도 간단한 형태로 만들어야 하게 된다. 우와..;;

그리고 골때리는 건, 아직 작성 중이고 정식으로 등록하기 전의 임시 상태인 글에 첨부된 그림들을 처리하는 방식이다.
일단은 그림들이 임시 폴더에다가 올라가고 주소도 임시 폴더 기준이지만 글이 정식으로 등록됐다면 글 중에 삽입된 이미지들의 주소를 수동으로 바꿔야 하고 파일도 옮겨야 한다.
또한 그 상태로 글이 더 등록되지 않고 사용자가 back을 눌렀다면, 서버에 올라왔던 임시 파일들도 나중에 지워 줘야 한다. 이런 것까지 도대체 어떻게 다 구현하지?

이건 일게 위지윅 에디터 컴포넌트가 감당할 수 있는 수준이 아니기 때문에 그걸 블로그 엔진이나 게시판에다 붙여 쓰는 웹 프로그래머가 자기 서버의 사정에 맞게 세팅을 해야 한다.
겨우 이미지 업로드 기능 하나만 달랑 구현하는 테크닉을 소개한 블로그만으로는 정보가 너무 부족했다.
Windows에서 공용 컨트롤에다 드래그 드롭을 처음부터 직접 구현하는 것만큼이나 손이 많이 갔다. 나 같은 이 바닥 초짜로서는 그저 경악스러울 뿐.

프로그램의 완성도를 더 높이려면, 사용자가 곱게 이미지 파일만 올리는 게 아니라 php나 html 같은 보안상 위험한 파일을 올리는 건 아닌지 감시해야 한다. 첨부 파일 정도가 아니라 위지윅 웹 에디터 자체도 위험하다고 그런다. HTML이 근본적으로 문서와 코드가 뒤섞인 형태이다 보니 정말 매크로가 잔뜩 든 Office 문서처럼 취급되는가 보다.
아무튼, 나모 웹에디터와 제로보드가 뜨던 시절에 비해 요즘 웹은 너무 방대하고 복잡하다.

Posted by 사무엘