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

지난 7월은 한 달 내내 날씨가 지독하게 더웠다.
본인은 올해의 하계 휴가는 예전의 관행과 달리, 인천· 경기도를 벗어나지 않는 단거리 위주로 산발적으로 다녀왔다. 그리고 새로운 장소를 개척하기보다는 이미 검증된 기존 장소를 찾아갔다. 코로나19 시국과 개인적인 신상 변화가 복합적으로 작용해서 이렇게 움직이게 됐다.

먼저 을왕리 해수욕장에 당일치기로 다녀온 뒤, 다음으로는 양평 계곡에 다녀오고 거기 부근에서 캠핑을 했다. 당초 계획했던 동해 바다를 포기하는 대신, 이걸 황해 바다와 계곡으로 나눠서 퉁친 셈이었다.

방역 때문에 밤에 시원한 바다 코앞에서 텐트 치고 놀지를 못하게 한다니.. 그럼 멀리 동해까지 원정 가는 것의 의미가 없어진다.
하지만 아무리 코로나니 뭐니 해도 이 더위에 어디든 바다는 보고 와야 하니 그냥 가까운 곳을 찾아가게 됐다.

1. 첫째 날: 바다

을왕리는 3년 전에 다녀 온 적이 있다. 그때의 기억이 어디 가지는 않아서 주변 지리가 낯익어 보였다.
그때도 한낮에 찾아가니 물이 다 빠져 있었는데.. 나중에 용유도 일대의 만조· 간조 시간대를 찾아보니 진짜로 오후 2시 반쯤이 물이 제일 없는 시간대였다. 황해에서 물놀이를 생각하고 있다면 이런 것도 고려를 해야겠다.

그래도 만조 ↔ 간조 사이의 간격이 얼추 6시간이니, 두어 시간 정도 지나자 물이 금방 들어왔다. 한참 멀리 떨어져서 바닥에 널부러져 있던 부표들도 금세 물에 잠겼다.
워낙 폭염이 강하고 수심이 얕기도 한지라, 바닷물은 그냥 온수에 가깝다는 생각이 들 정도로 미지근했다. 그리고 아래가 내려다보이지 않을 정도로 탁한 흙탕물이었다.

동해는 시종일관 거센 파도가 휘몰아치고 거품 낀 맑은 물이 솟구치는 대신, 바닥도 급격히 깊어져서 물에 얼마 들어가지를 못했던 것으로 기억한다. 강원도건 부산이건 별 구분 없이 말이다.
이런 사소한 것들도 매년 꾸준히 바다에 다녀오니 차이점이 눈에 들어오고 경험과 노하우가 생긴다.;;

여기서는 발 담그고 해변 산책, 식사와 카페 휴식 정도만 했다. 방역을 빌미로 해수욕장이 폐장 상태이고, 샤워장조차 운영하고 있지 않으니 뭘 더 할 수가 없었다.
그럼 발을 씻을 수 있는 최소한의 야외 수도꼭지 같은 거라도 있어야지? 그것도 없으면 사람들이 나갈 때 온통 공중 화장실로 몰릴 것이고 세면대 하수구가 모래에 막혀서 배기지를 못할 텐데.. 이미 공중 화장실 세면대는 개판이 돼 있었다.;;;

2. 둘째 날: 계곡

이튿날, 본인이 찾아간 곳은 양평의 모 계곡이었다. 여기도 수 년 전에 교회 수련회 일정에 껴서 친구들과 다녀온 적이 있어서 풍경이 낯설지 않았다.
작년에 굉장히 시원하고 인상이 좋았던 안양 병목안 산림욕장의 계곡, 또는 양주 송추 계곡도 후보에 껴 있었다. 하지만 거기는 연계 관광에 대한 정보가 부족한지라, 이번에도 역시 검증된 피서 휴양 코스인 양평을 선택하게 됐다. 서울을 떠나서 국도 6호선을 따라 한강 경치를 감상하는 건 나를 언제나 들뜨게 했다.

계곡에서는 인구 밀도 대비 수량이 부족해서 앉거나 눕는 기동밖에 할 수 없어서 아쉬웠다. 하지만 이 길고 긴 폭염 와중에 이만치라도 맑고 차가운 물이 흐르는 곳, 선풍기와 에어컨 없이 지낼 수 있는 곳이 존재하는 것만으로도 감지덕지였다. 물이 적은 대신 퀄리티가 바닷물을 아득히 뛰어넘는다.

이렇게 물이 졸졸 흐르는 전용석에 기다랗게 누워서 한 30분이 넘게 컴퓨터 작업을 했다.
그늘 밑에 돗자리 깔고 거기서도 낮잠을 자고 간식을 먹었다.

날이 저문 뒤에는 계곡을 나와서 근처를 방황하던 중, 잡초가 무성하게 자란 어느 공터를 발견했다.
놀이터였던 곳이 방치된 것 같은데.. 차도에서 가깝지만 길에서는 공터 안이 수풀에 가려져서 잘 보이지 않는 은폐 보안성을 자랑(?)했다. 게다가 옆에 정자도 있고..

물이 바로 옆에 흐르거나 화장실· 수도꼭지 같은 것만 근처에 있으면 더 좋았겠지만 이 정도만으로도 캠핑을 하기에 아주 좋은 장소였다. 여기서 텐트 치고 밤을 보냈다. 아주 만족스러웠다.

3. 셋째 날: 한강 주변 카페, 두물머리 세미원

계곡에서는 6시간을 채 있지 않았던 반면, 이 캠핑 아지트에서는 자는 시간을 포함해서 무려 12시간 가까이 있었다.
둘째 날까지 물놀이와 캠핑을 했다면 셋째 날엔 두물머리 일대에서 시각 힐링과 관광을 즐겼다. 이런 연계 코스 때문에 계곡에 갈 때도 다른 지역 대신 양평을 선택한 것이었다.
다만, 이 관광지들은 상수원 보호 구역에 있기 때문에 말 그대로 관광만 가능하다. 이제 물놀이는 할 수 없다.

예전에 교회 수련회를 다녀오면서 개척한 적이 있던 카페인데.. 예나 지금이나 주변 경치가 가히 킹왕짱이었다. 날씨도 흐릴 거라는 예보와 달리 쾌청해서 더욱 좋았다. 여기서 제대로 씻고 전자기기들을 충전하고 간식도 먹었다.

이제 햇볕이 내리쬐고 날씨가 많이 더워져서 야외 활동은 자제할까 생각도 했지만.. 기왕 여기까지 온 김에 근처의 '세미원'이라는 곳을 가 봤다.
'평범한 연꽃 공원처럼 보이는데 무슨 입장료까지 받나, 옆에 있는 두물머리 공원과 차이가 뭐냐' 이런 생각을 하면서 들어갔지만 생각이 곧 바뀌었다. 입장료가 아깝지 않을 정도로 시설이 정말 잘 꾸며져 있고 볼거리가 많았다.

특히 저 사진에서 보다시피, 입구에서부터 울창한 나무들 아래로 물이 졸졸 흐르는 징검다리길이 있는 게 굉장히 인상적이었다.

야외에는 이렇게 커다란 연꽃들이 가득했다. 꽃이 피었다가 시든 자리는 무슨 샤워기 같은 모양이었다.

밖에도 이렇게 잘 꾸며진 공원과 연못이 아주 넓게 갖춰져 있었다. 그저 풀숲뿐인 두물머리 공원과는 달랐다.

이건 하늘과 강이 참 예뻐서 한 컷 찍었고..

세미원에서도 다리를 통해 이웃집인 두물머리 공원으로 갈 수 있었다. 단, 두물머리에서 세미원으로 재입장을 하기 위해서는 티켓을 잘 간수하고 있어야 한다.
뙤약볕 아래에서 긴 거리를 걸어 다니느라 다리가 아프고 피곤했지만 그래도 돌아다닐 가치가 있었다.

이건 돌아오면서 강북이 아니라 강남에서 강북 쪽을 바라보며 찍은 한강 경치이다. 한 폭의 그림이 따로 없다.
이상이다. 본인은 이렇게 이번 휴가철엔 바다(3) - 계곡 개울(1) - 큰 강(2)의 순으로 답사를 하고 돌아왔다.
각 장소별로 물놀이는 바다(2 발만..) - 계곡 개울(3 제일 많이) - 큰 강(1 전혀 못 함)의 순으로 했다.
사진은 바다(1 별로) - 계곡 개울(2 조금) - 큰 강(3 제일 많이) 이런 순으로 많이 남겼다.

Posted by 사무엘

남의 코드를 읽으면서 신기하게 느꼈던 점들을 다음과 같이 정리했다. 요즘 C++은 변해도 너무 많이 급격하게 변하고 있는 것 같다. 뭔가 다른 언어에 있던 기능이 비슷한 형태로 그대로 도입되는 편이다.

1. final과 override

본인은 C++에 클래스에 뭔가 제약을 가하는 기능이 부족한 편이라고 볼멘소리를 늘어놓아 왔다. 어떤 클래스가 더 상속이 되지 않게 하기, 이 함수가 더 오버라이딩이 되지 않게 하기, 대입이나 복제가 되지 않게 하기 등...
하긴, 이런 불평은 나만 하는 게 아니며, 오히려 나보다 더 깐깐한 불편러 PL 순수주의 성향인 사람도 많다.

함수 차원에서 제약을 가하는 것은 요즘 C++에서는 = delete 문법이 생겨서 불편이 많이 해소됐다.
그런데 이것 말고도 C++에 final과 override라는 조건부 키워드도 드디어 추가되었다니 참 놀랍다.

class Parent final { }

요렇게 해 주면 Parent를 기반으로 삼는 파생 클래스를 만들 수 없다. class Child: public Parent {} 이런 걸 시도하면 에러가 난다.
한편,

class Parent {
public:
    virtual void foo() {}
};
class Child: public Parent {
public:
    void foo() override {}
};

여기서 override는 Child의 foo가 기반 클래스의 foo를 재정의한다는 것을 나타낸다. 이 표기는 당연히 전적으로 optional이기 때문에 하든 안 하든 컴파일러의 코드 생성과 프로그램의 실행에는 아무 영향을 주지 않는다.

단지, 기반 클래스에 저런 함수가 없는데도 파생 클래스의 함수에 override가 선언돼 있다면 컴파일러는 에러를 찍어 준다. 그러므로 저걸 집어넣으면 내가 함수의 스펠링이나 매개변수를 실수로 잘못 넣었는지 여부를 곧장 알 수 있다.
그리고..

void foo() final;

final을 집어넣으면 짐작하다시피 이 함수는 파생 클래스에서 오버라이딩을 할 수 없게 된다. override와 final을 동시에 지정하는 것도 가능하다.

멤버 함수의 선언 뒤에다가 뭔가 속성을 지정한다는 점에서 const와 비슷해 보인다. 허나, 다시 말하지만 얘들은 전적으로 컴파일 때의 편의를 제공하는 hint일 뿐이다. 코드의 생성 방식이나 심지어 명칭의 decoration에도 전혀 영향을 주지 않는다.
const는 이거 지정 여부로 함수 오버로딩을 가능하게 하는 변별 요인이지만 override와 final은 그렇지 않다는 것이다. 그렇기 때문에 클래스 안에 함수의 선언부에다가만 지정하고 함수의 몸체 정의에다가는 생략도 가능하다. const는 그렇지 않다.

2. [[??]] 속성 지정자

함수의 선언에서 리턴 타입보다도 먼저 맨앞에 붙어 있는 [[nodiscard]] 이런 문구가 정체가 무엇인지 궁금해서 찾아 봤는데..
이 함수의 리턴값을 무시하지 않게 하는 자잘한 속성 지정자였다. 이 함수는 호출만 하고 리턴값을 무시하는 경우, 호출하는 쪽의 코드에다가 경고를 날리게 된다.

&를 두 개 써서 R-value 참조자라는 걸 추가했듯이, 여는 대괄호도 2개를 써서 저런 새로운 문법을 만든 것이다.
nodiscard 말고도 컴파일러의 최적화 전략에 단서를 제공하는 속성이 몇 가지 더 존재하며, C++ 언어의 버전이 올라가면서 아이템들이 추가되곤 했다.

함수의 선언에는 함수의 이름, 리턴 타입, 그리고 인자들 목록과 타입만 있는 줄 알았는데 그 사이에 calling convention 지정부터 시작해서 갖가지 추가적인 정보와 단서들을 지정하는 문법이 야금야금 도입돼 왔다.

extern "C"도 있고, 그리고 Visual C++이 전통적으로 사용한 방법은 __declspec(????)이다.
특히 deprecated는 [[]]와 __declspec()에 모두 존재해서 이제 기능이 완벽하게 겹치는 것 같다. 자기들이 필요하니까 마소에서 먼저 deprecated API를 지정하는 속성을 비표준 방식으로 추가했는데 그게 이제야 표준에도 도입된 셈이다.

그런데 C/C++은 태생적으로 함수를 선언할 때 function이나 그에 준하는 별도의 키워드를 두지 않았고, "리턴값 함수명(인자)"라는 문법 형태만으로 함수를 선언 및 정의할 수 있게 해 놓았다. 그러다 보니 그 사이에다 추가적인 정보를 집어넣는 문법이 좀 지저분해진 것은 피할 수 없어 보인다.
관점에 따라서는 아까 저 final, override 같은 힌트 속성도 [[]] 형태로 일관되게 넣을 수도 있어 보이지 않는가?

이런 부가 정보들을.. 단순히 경고만으로 끝나는 것, 컴파일 가능 여부에 영향을 주는 것(final), 코드의 생성 방식에 영향을 주는 것(호출 규약), 최적화 방식에 영향을 주는 것, C++ name mangling에 포함되는 것(const) 등으로 한데 분류해 보는 것도 의미가 있을 것 같다.

3. Variadic macro

요즘 C/C++에서는 #define 매크로 함수도 마지막 인자에다가 ...를 줘서 가변 인자 형태로 만들 수 있다.

이게 없던 옛날에는 가변 인자를 받는 함수를 매크로 함수로 간단하게 치환할 수 없어서 그냥 이름만 치환하는 매크로 상수를 써야 했다. 그리고 매크로 상수로는 가변 인자의 앞에다가 추가적인 인자를 삽입해서 다른 함수를 호출하는 식의 응용을 할 수 없었다. 하지만 이제는 그게 가능해졌다.

물론 가변 인자라는 건 근본적으로 C++의 이념과 그닥 어울리지 않는 물건이다. C++이 자체 제공하는 함수 오버로딩이나 default argument와 충돌하기 쉬우며, type-safety와 객체지향(특히 임시 객체에 대한 생성자/소멸자) 처리가 보장되지 않는다. 그러니 가변 인자로 주고받는 건 반드시 정수나 포인터 같은 단순 POD로 한정돼야 한다.

C++과 어울리는 물건이 아니다 보니 얘는 auto니 템플릿이니 하는 쪽에 관심이 온통 쏠려 있는 modern C++의 산물이 아니다. C99에서 맨 처음 도입됐던 것을 C++11이 나중에 같이 받아들인 것이다.
애초에 #define 전처리기도 C++보다는 꽤 C스러운 물건이다. 거기에 또 다른 C의 냄새가 풀풀 풍기는 ...이 잘 결합한 것 같다.

전처리기에는 ##이라는 연산자가 있어서 기존 명칭의 스펠링에다가 뭘 앞뒤로 붙여서 새로운 명칭을 만들게 해 준다.
그것처럼 가변 인자 매크로의 내부에는 가변 인자들 묶음을 한꺼번에 나타내는 __VA_ARGS__라는 특수한 매크로 상수가 정의되어서 사용 가능하다. 가변 인자 지원을 위해서 언어 문법이 확장이라면 확장된 셈이다.

사실, 이게 문법도 변형이 존재한다..

#define my_printf(a, ...)   printf(a, __VA_ARGS__) //A형
#define my_printf(a, args...)   printf(a, ##args ) //B형

지금은 A형이 표준인데 GNU C에서는 B형도 존재했는가 보다. Visual C++에서는 B형은 지원되지 않는다.

요즘 가변 인자가 활발하게 쓰이는 분야 중 하나는 printf 가변 인자 스타일로 문자열을 포매팅하는 디버그 로그 쪽일 것이다.
개발자가 잠깐 보고 마는 정보이니 문자열까지 쓸 것도 없이 간단히 char buff[256]으로 때워도 무관할 것이고 굳이 C++ string이나 stream을 쓸 필요가 없다. 더구나 이거야말로 디버그 빌드 여부냐에 따라 각종 조건부 컴파일과 전처리기 치환이 절실히 필요한 분야이니.. 가변 인자 매크로는 생각보다 개발 명분과 정당성이 풍부해 보인다.

추신:
글을 다 써 놓고 나중에 알고 보니 C++도 variadic macro와 비슷한 개념이 더 괴물 같은 형태로 템플릿에 이미 도입되었다.;; 이름하여 variadic template. template<typename... T> void foo(T.. args) {} 이러면 args가 __VA_ARGS__와 얼추 비슷한 argument pack 역할을 하게 된다.
이것 말고도 온갖 복잡한 용법이 많다. 이거 예시를 보이기 위해서 C++ 코드에다가 굳이 printf를 호출하려고 애쓰는 걸 보니 뭔가 느낌이 짠하다.

4. 현재의 함수 이름을 나타내는 매크로 상수

ANSI C에는 디버깅을 위해 __FILE__, __LINE__처럼 현재 컴파일 되는 파일 이름과 줄 번호로 유동적으로 치환되는 표준 매크로가 정의되어 있다. 이런 게 디버그 로그 내지 assert failure 매크로에서 즐겨 쓰인다.

그런데 현업에서는 이 뿐만 아니라 현재의 코드가 소속되어 있는 함수 이름 문자열을 나타내는 매크로도 쓰인다.
ANSI C 급의 원조 표준은 아니지만 #pragma once나 __super처럼 업계에서 오랫동안 사실상의 표준이나 마찬가지였던 물건이 있는데.. 바로 __func__이다.

얘는 C++11에서는 결국 정식 표준으로 등재되기도 했다. C++ 문법과 관계 있는 물건은 아니니 가변 인자 매크로처럼 C99에서 먼저 도입됐던 것이 추후 수용된 게 아닌가 싶다.
그리고 __FUNCTION__이라는 바리에이션도 __func__과 동일한 역할을 한다.

Posted by 사무엘

1. 군대 관련

지난 2011년에 해병대가 총기 난사와 여객기 오인 사격 사건 때문에 욕 먹고 구설수에 올랐다면, 2014년은 육군 전방 부대에서 발생한 총기 난사와 가혹행위 살인 사건 때문에 난리가 났었다(22사단 임 병장, 28사단 윤 일병). 둘 다 지금으로서는 제법 먼 과거의 일이 됐지만 말이다.

그런데 저 2014년에는 친구들과 함께 승용차로 군 입대 이동 중이던 일행에 의한 고속도로 교통사고가 두 건이나 발생하기도 했다. 차는 아마 렌트한 거지 싶은데, 둘 다..

• 승용차에는 사람이 빈틈 없이 꽉 타고 있었고,
  
• 갓길에 정차 중이던 대형 트럭을 들이받았으며,
  
• 탑승자 중에 사망자가 발생

했다는 공통점이 있다.

먼저 5월엔 의정부 306 보충대로 가던 차량이 저렇게 사고가 나는 바람에 탑승자 6명 중 2명이 사망했다. 군 입대 당사자는 중상을 입어서 보충대 대신 병원으로 가게 됐다. (참고로 306 보충대는 2014년 말에 폐지되어 없어짐)

그 뒤 10월 28일에는 아마도 논산 입소대대로 가는 중이던 차량이 호남 고속도로에서 거의 같은 사고를 냈다. 차가 완전히 박살 나면서 운전자, 입대 당사자를 포함한 5명의 청년들이 전원 사망하고 말았다.

어휴~ 이러니 자동차 보험이 26세 이하는 보험료가 왕창 비싼 것이지 싶다.;;
군대와 관련하여 제일 어이없고 안습하고 안타까운 교통사고는 2018년 12월 말, 화천에서 군 복무 중이던 아들을 면회 후 귀가하던 차량이 산길에서 전신주와 나무를 들이받고 수로로 굴러 버린 사고이지 싶다.

더 큰 차량과 부딪친 것도 아닌 단독 사고이고 무슨 수십 m 아래의 절벽으로 떨어진 것도 아니고, 운전자는 음주나 졸음 정황도 없었는데.. 탑승자들은 운전자인 부친을 제외하면 모두 여성이었고(모친, 누이 둘, 여친), 안전벨트를 매지 않았던 것 같다.
차가 구르는 동안 운전자를 제외한 4명 전원이 차 밖으로 튕겨 나가고 ‘사망’했다..;;

그 아들은 그 당시 즉시 위로 휴가, 청원 휴가를 잔뜩 받긴 했다고 전해지는데.. 일가족이 몰살당한 군인한텐 휴가 정도가 아니라 아니라 아예 의병/의가사 제대라도 시켜 줘야 하지 않을까?
운전자도 2016년 부산 싼타페 급발진 당사자와 동일한 트라우마에 평생 시달릴 것 같다. 저 사고도 일가족 4인 몰살에 운전자만 살아남은 비극이었으니..

갑툭튀 한 짐승 같은 걸 피하려고 핸들을 꺾다가 이런 참극이 벌어진 건지? 나로서는 이 정도 추측밖에 못 하겠다.
저기가 무슨 시속 100 이상으로 밟을 수 있는 곳도 아니고, 주변 현장을 봐도 길을 좀 이탈해서 사고가 나 봤자 단독으로는 사람이 죽을 정도는 절대 아니었을 것 같은데.. 탑승자들이 운이 지독하게 나빴던 것 같다. 그래, 과거에 이런 일도 있었다.

2. 안전벨트

탤런트 석 광렬과 조 문정. (전자는 모르겠고 후자는 대우 전자 “탱크주의 제품이거든요. 저희가 노력할수록 더 좋은 제품을 만들 수 있잖아요?” 그 멘트를 날렸던 여성 연구원을 연기한 배우...;; )
각각 1968년, 1970년생인 비슷한 연배인데, 모두 1994년에 자가용 교통사고로 겨우 20대 중반의 꽃다운 나이에 세상을 떠났다는 공통점이 있다.

그런데 그 사고라는 게 음주도 아니고, 고속도로에서 한 150 넘게 밟다가 박은 것도 아니고, 중앙선 침범 정면충돌이나 화재나 추락이나 대형차 사이에 끼인 것도 아니고..
둘 다 그냥 미끄러져서 혼자 주변 구조물을 들이받은 ‘단독사고’에 지나지 않았다.

요즘 차량이라면 일단 ABS가 무조건 필수가 됐으니 저런 사고 자체가 안 나거나 사고 규모가 크게 줄어들었을 것이고, 거기에다 에어백과 안전벨트의 도움을 받았다면 겨우 저 정도 사고로 운전자가 죽기까지 할 가능성은 0으로 쫙 수렴했을 것이다.

허나, 25년 전에 그랜저급이 아닌 승용차였으니(각각 스쿠프, 액센트) ABS와 에어백은 없다 치고.. 거기에다 두 분 다 벨트를 안 했지 싶다. 그래서 충돌과 함께 어디 심하게 부딪치고 튕겨나가고 그 결과가 각각 뇌사와 즉사로 돌아온 것이다. 그러니 안타까움이 더해진다.

3. 대인 역과 사고

교통사고 중에는 차와 차끼리 부딪히는 것 말고 차와 보행자가 부딪히는 것도 있다. 이런 사고는 대물 보상을 할 것은 별로 없을지 모르지만, 저속에서도 사람이 죽거나 중상을 입을 가능성이 차 vs 차 사고보다 훨씬 더 높다.
특히, 사람이 죽을 정도로 차가 과속을 한 게 절대 아니었는데 피해자가 현장 즉사 급으로 죽었다면.. 그건 피해자가 내던져지고 튕겨나갔기 때문이 아니다. 그 자리에서 넘어져서 차 바퀴에 깔리고 짓이겨졌기 때문이다.

(1) 2016년 11월, 서울 도봉 운전 면허 시험장에서는 한 응시생이 앞의 출발 신호만 보고 출발했다가 앞에 불쑥 걸어 들어오던 다른 응시생을 보지 못하고 살짝 쳤다. 가해 응시생은 너무 놀라서 허둥대다가 또 악셀을 밟아 버렸고, 피해자는 바퀴에 깔려서 즉사했다. 이건 군대 사격장에서 사람이 아무 통제 없이 총구 앞을 서성거리다가 오발 사고가 난 거나 마찬가지인 비극이었다.

(2) 2021년 1월, 그 유명한 파주 시내버스 롱패딩 문 끼임 사고도 피해자가 결국은 질질 끌려가다가 신체가 버스 뒷바퀴에 깔리는 바람에 즉사했다. 보아하니 피해자는 내릴 때 카드 태그를 깜빡해서 팔만 황급히 차내로 도로 집어넣다가 변을 당한 것 같다.

(3) 그리고 2021년 5월, 승용차가 좌회전 하다가 신호등 없는 횡단보도에서 어느 모녀를 친 사고도.. 애엄마는 바퀴에 깔리는 바람에 현장에서 즉사했다. 저런 곳에서는 그렇잖아도 A필러에 가려지고 못 봐서 사람을 치는 사고를 내기 쉬운데.. 운전자가 말 그대로 눈깔이 썩어-_- 있는 상태에서 운전을 강행한 것이었다. 이 때문에 여론은 어지간한 음주운전 대인 사고 급으로 크게 분노했다.

4. 나머지

(1) 뒤집힌 채로 머리부터 아래로 떨어짐

• 1994년 10월, 성수대교 붕괴 사고 때 교각에 아슬아슬하게 걸쳐 있다가 아래로 추락한 시내버스는 탑승객 31명 중 운전사 포함한 무려 29명이 사망했다.
  
• 2010년 7월 일명 인천대교 김여사 사고.. 공항 리무진이 사고 차량을 피하려다가 가드레일을 들이받고 뒤집힌 채로 아래로 추락해서 승객 24명 중 12명이 사망했다.

(2) 큰 차의 아래로 쏙 들어감. 엔진룸이 아니라 A필러 쪽만 그대로 충격을 받고 승객 탑승 공간이 짜부러진다. 탑승자 몰살을 면하기 어려움.

• 아까 언급했던 2014년 10월자 군 입대 친구 배웅 사고. 커브를 잘못 돌아서 갓길에 세워졌던 작업용 트럭을 그대로 들이받음.. 입대자 당사자를 포함한 5인 전원 사망.
  
• 역시 아까 언급했던 2016년 8월, 부산 싼타페 급발진 사고. 계속 피하다가 결국 대형 트레일러의 뒤꽁무니를 들이받는 바람에 운전자 제외한 나머지 탑승자 4인 사망.

(3) 반대로 큰 차가 승용차를 들이받거나 심지어 올라타 버려도..

• 2009년 4월, 서울 우이동 교차로에서 공차회송 중이던 관광버스가 긴 내리막에서 브레이크가 고장나서 앞에 서 신호대기 중이던 승용차를 추돌하고 밟고 올라감. 마침 차 한 대에 정원 초과 탑승하여 계모임 장소 이동 중이던 성인 여성 7인 전원 사망.
  
• 2016년 7월, 영동 고속도로 봉평터널 인근 연쇄 추돌 사고.. 졸음운전을 하던 관광버스가 앞의 렌터카 승용차를 시속 100km 남짓한 속도로 그대로 추돌. 운전자 제외한 탑승자 4인 사망.
  
• 2017년 7월, 경부 고속도로 양재IC 인근에서 M 광역버스가 역시 졸음운전으로 앞의 승용차 추돌하여 탑승자 2인 전원 사망.

(4) 작은 차가 큰 차의 앞뒤로 끼임

• 2013년 12월, 경부 고속도로 하행선 경주-울산 부근의 정체 구간에서 벽돌을 가득 실은 25톤 트럭이 앞의 아반떼 승용차를 추돌함. 승용차는 앞의 25톤 탱크로리와 뒤의 트럭 사이에 끼여서 완전히 구겨지고 아작남. 승용차엔 마침 두 집의 어머니와 각각의 아이들 둘.. 총 6명이 타고 있었는데 이 사고로 전원 사망..
  
• 2016년 5월, 남해 고속도로 터널 9중 추돌 사고. 모닝 승용차 하나가 대열 운행 중이던 버스 두 대 사이에 앞뒤로 끼여서 탑승자 4명이 전원 사망했다.

(5) 승용차는 뒤에 연료탱크가 있다. 뒤를 세게 추돌 당하면 낮지 않은 확률로 불이 날 수 있다. 그런데 이건 하필 전부 다 음주운전 사고들이네..

• 2012년 6월 새벽, 음주운전 승용차가 앞에 멀쩡히 잘 가고 있던 승용차를 시속 180km 속도로 추돌.. 앞차는 화재가 발생해서 공항 직원 일가족 4명이 전원 사망했다.
  
• 2015년 2월 새벽, 구미에서도 음주운전 차량이 앞의 경승용차를 엄청난 과속 상태로 추돌.. 앞차는 불이 나서 탑승자 4명이 전원 사망했다.
  
• 그리고.. 다음과 같이 안타깝고 암을 유발하는 사례가 또 있었다.

5. 고속도로 1차로에서 2차 사고 + 차량 전소 + 여성 운전자 사망

(1) 지난 2021년 1월 4일 밤 11시 무렵, 경부 고속도로 상행선 판교IC 부근에서,

• 어떤 30대 여성 운전자가 칼치기 차량 때문에 놀라 피하다가 핸들을 잘못 꺾고.. 1차로의 중앙분리대를 들이받는 단독사고 냄.
  
• 그래서 멈춰 서 버렸는데.. 얼마 후 뒤에서 음주운전 차량이 맹렬한 속도로 역시 1차로를 달리다가 저 차를 들이받음. (심야이기 때문에 버스 전용차로가 시행 중이지는 않음. 승용차도 1차로 주행 가능)
  
• 차에 불 나고 여성 운전자 사망.

(2) 2020년 7월 22일 밤 10시 45분쯤, 제3경인 고속화도로 고잔TG 부근에서,

• 1차로를 달리던 차량 A가 앞차 B를 살짝 추돌해서 사고 처리 때문에 둘 다 멈춰 섬.
  
• 그런데 이때 20대 여대생 두 명이 탔던 차량C는 1차로를 달리다가 얘들을 발견하고 간신히 멈춰 섬.
  
• C는 슬슬 차로를 바꿔서 다시 출발하려 했는데.. 1차로에서 차량D가 맹렬한 속도로 달려오다가 저 차를 추돌. 차량 C는 불이 나서 전소하고.. 탑승해 있던 여대생 두 명은 차에서 빠져나오지 못하고 사망.

(2)의 경우, A와 B 일행은 트렁크 개방이나 삼각대 같은 안전조치를 충분히 취하지 않았다.
게다가 가해자 B는 음주 사실이 들통나지 않으려고.. 여느 사설 바가지 견인차가 아니라 도로 관리 시설에서 안전을 위해 사고 차량을 무료로 밖으로 견인해 주겠다는데도 거절하고, 30분이 넘게 1차로에서 시간 끌며 차 안에서 버티고 있었다. 명목상 자기 보험사의 견인차를 기다린 거라고는 하는데..

요컨대 (1)은 들이받은 차가 음주였고, (2)는 차를 멈춰서게 만든 민폐 당사자가 음주였다. 들이받은 가해자 당사자의 죄질은 그냥 평범한 전방주시 태만과 과속이었다. 그런데 피해는 정말로 된통 당했어야 할 B가 아니라 애매한 C가 고스란히 뒤집어쓴 것이다.;;
괘씸하긴 하지만 그래도 음주운전자가 C 차량 탑승자를 직접 죽인 건 아니어서 인과관계를 따지기가 참 난감하다.

상황이 이러니.. 일반 도로에서는 지방 경찰청이 (1) 신호와 (2) 과속만 죽어라고 단속하고, 고속도로에서는 신호 걱정은 딱히 안 해도 되니 (1) 졸음운전과 (2) 2차 사고를 예방하려고 애쓰는 듯하다.

Posted by 사무엘

(1) 사람이 주먹질이나 몸통박치기를 해서 와장창 깨지는 유리창, 머리 박치기를 해서 깨지는 맥주병은 진짜 유리가 전혀 아니다. 훨씬 더 잘 깨지고 인체에 위험하지도 않은 슈가글래스 같은 다른 소재이다.
현실에서 유리를 그렇게 깼다간 큰일난다. 이런 점에서는 페르시아의 왕자 게임의 설정도 매우 비현실적이고 위험하다. (1편은 레벨 4에서 거울 깨기, 2편은 시작부터 창문 부수고 탈출)

(2) 거대한 선박은 제작비를 아끼기 위해 실제 크기의 90% 남짓한 세트로 대체하고, 그것도 좌우 중 한쪽 현만 만드는 편이다. 맞은편 현 씬은 기존 현에서 촬영 후에 좌우 대칭을 시켜서 연출한다. (배우도 좌우 바뀐 복장과 연기를 하고)
이건 타이타닉과 연평해전에서 공통으로 동원된 테크닉이다. 심지어 연평해전의 경우, 적함과 아군함을 같은 배에서 세팅만 달리해서 찍었다고 전해진다.;;;

90% 크기의 약간 작은 가구 소품은 아파트 모델하우스에서도 쓰이기도 한다. 소비자에게 집이 겉보기보다 더 넓어 보이는 느낌을 준다. 길이를 10%만 후려쳐도 전체 부피는 3제곱의 특성상 27%나 줄어든다. (1 - 0.9^3)

(3) 현금박치기나 돈다발을 불태우는 씬은 영화/드라마 소품용으로 특별히 한국 은행으로부터 허가까지 받고 제작된 가짜 돈, 한 마디로 합법적인 위조지폐로 한다. 병원에서 처방하는 합법적인 마약과 비슷한 존재랄까?
얘는 크기나 재질이나 인쇄 내용 등 어디에 어떤 형태로든 이건 진짜 돈이 아니라는 티를 내는 표식이 반드시 들어간다.

(4) 우리나라나 미국의 경우, 영화나 드라마 화면에 안전하게 노출시키는 용도로 쓰라고 허구의 전화번호 리스트도 통신사 차원에서 생성해서 지원해 준다. 자동차 번호판에도 비슷한 게 있으려나?

(5) 현업에서 쓰이고 있는 것이 그대로 방송을 타지 않도록 각별히 유의해야 하는 의류가 있다. 군복, 그리고 항공사 승무원 유니폼.
그래서 군대를 소재로 하는 영상물에서는 한물 간 옛날 개구리 군복이 즐겨 쓰이며, 스튜어디스 제복도 대충 비슷하게는 생겼지만 실제로 어느 항공사에서도 현재 쓰이지 않는 물건이 소품용으로 따로 만들어져 쓰인다.

(6) 금호 상사처럼 영화 촬영을 위한 올드카 대여 업체가 있다. 포니, 브리사, 봉고, 그라나다 같은 차들 말이다.
말죽거리 잔혹사의 경우, 감독이 실제 1970년대 중문 버스를 구하고 싶었지만.. 그러지 못해서 1980년대 대우 자동차의 등장 이후에 만들어진 BF105를 적당히 개조해서 찍었을 것이라고 예전에 본인이 추측한 바 있다.

(7) 비행기 정도라면 모를까, 현실의 자동차는 꼬라박거나 총 좀 맞는다고 해서 그렇게 쉽게 잘도 펑펑 터지고 불바다가 되지 않는다.
또한, 현실의 수류탄 역시 폭발하더라도 영화나 게임 같은 화끈한 화염이 나오지 않는다. 그냥 총 쏠 때와 비슷한 정도의 불꽃이 잠깐 반짝이고 마는 정도다. 그 대신 폭음과 진동이 영화의 묘사보다 훨씬 더 클 뿐이다.

(8) 비슷한 맥락에서 인체도.. 사람은 저격수나 자객에 의해 총칼로 급소를 강타했을 때 차라리 즉사를 하면 했지, 뒤통수 한 대 퍽 맞았다고 그렇게 호락호락 잘 기절하지는 않는다. 이건 영화적 과장이 많이 가미된 연출이다.

(9) 영화는 전반적인 색깔 톤도 인위적으로 왜곡 보정된 경우가 많다.
가령, 친구(2001) 같은 경우, 빛바랜 느낌을 내려고 영상의 톤이 전반적으로 누렇게 바래져 있다.

아저씨나 타이타닉에서 결말 장면(지하주차장 방탄유리 드립 내지, 배 침몰 후)은 배경에 전부 어두컴컴한 시퍼런 톤이 들어가 있는데... 어느 건물이건 실제 지하주차장의 조명이 그렇게 어두컴컴 시퍼런 게 아니다.
타이타닉도 뭐.. 실제 상황이었으면 그냥 닥치고 깜깜하고 아무것도 안 보였겠지만.. 하지만 이런 것들이 다 영화적 허용이다.

뭐 이런 게 한둘이 아니어서 말이지..?
영화와 현실이 차이가 이렇게 크니 대륙 무술 영화에 나오는 쿵푸도 현실에서는 아무 실속이 없는 무용일 뿐이라는 비판이 나오는가 보다.

Posted by 사무엘

날개셋 한글 입력기의 다음 버전은 올해 연말 정도 공개를 목표로 개발 중이다. 늘 그렇듯이 여러 기능들이 추가되고 자잘한 버그들이 잡혔다.

1. 복합 낱자 입력 로직 생성기에 허용 한글 데이터를 '내장형'으로 연계하기

지난 9.0 버전(4년 전~!)에 사실상 완성되어서 더 변화가 없었던 '복합 낱자 입력 로직 생성기'가 오랜만에 외형이 살짝 바뀌고 자잘한 옵션이 추가되었다. 얘가 뭘 하는 물건인지부터 먼저 복습을 좀 하자면 다음과 같다.

이 빠른설정은 2016년경 8.x 버전 시절부터 슬슬 개발과 구현의 필요성을 느껴서 2017년 초, 8.8 버전에서 드디어 첫 버전이 도입됐었다.
다음 버전인 8.9에서는 허용 한글 범위 제약 기능과 연계해서 로직을 생성하는 기능이 추가되었으며, 그 다음 9.0 버전에서 지금과 같은 세부 기능들이 모두 완성되었다.

다른 빠른설정들은 두벌식, 세벌식, 한글 로마자처럼 특정 문자 입력 방식을 새로 세팅해 주는 물건인 반면..
얘는 기본 자모만 입력 가능한 한글 입력 설정을 받아서 겹받침이나 이중모음 같은 복합 낱자들을 입력 가능한 설정을 세팅하며, 그 과정에서 발생할 수 있는 모호성이나 논리 오류를 찾아내고 바로잡아 준다.
대화상자를 네 단계나 거칠 정도로 설정할 것이 많으며 빠른설정들 중에서 덩치가 압도적으로 제일 크다.

얘는 이미 있는 입력 설정의 동작을 더욱 심화시키는 역할을 한다는 점에서 다른 빠른설정과는 성격이 근본적으로 다르다.
이건 개인적으로 날개셋 한글 입력기의 개발 내력에서 차지하는 의의가 매우 큰 중요한 기능 중 하나라고 생각한다. 현실에서는 한글 입력 엔진 하나만 갖고 이 정도로 미친 수준의 추상화나 잉여질을 생각하는 기업이나 연구소는 딱히 없기 때문이다.;;; 어쨌든 날개셋 한글 입력기에는 이런 기능이 있다.

이 빠른설정은 필요한 경우, 로직 생성 결과를 '지정된 데이터에 들어있는 한글'이라는 허용 한글 범위 제약 기능에서 인식하는 데이터의 형태로 생성해 준다.
가령, KS X 1001 2350자를 기준으로 동작한다면 '썅'은 있는데 중간 입력 과정인 '쌰'가 누락됐다는 것을 찾아내며, '쌰'가 포함된 허용 한글 데이터를 별도로 생성한다는 것이다.

'지정된 데이터에 들어있는 한글'은 별도의 파일에 저장된 데이터를 읽어들여서 동작하곤 했는데.. 지난 10.0 버전부터는 작은 데이터는 그냥 입력 설정에 포함된 내장형으로 동작할 수도 있게 됐다.
하지만 '복합 낱자 입력 로직 생성기'는 이런 변화가 반영되지 못하고 저 허용 한글 범위 제약 기능을 언제나 예전처럼 외장형으로만 운용해 왔다.

그러던 것이 이번 버전에서 드디어 개선될 예정이다. 이 빠른설정도 사용자가 옵션을 지정한다면 내장형을 적극 활용하게 된다.
기존 외장형은 큰 데이터를 부담 없이 취급할 수 있으며 한 파일을 여러 입력 항목이 공유할 때 메모리 공간이 절약된다는 것이 장점이다. 그 반면, 내장형은 덕지덕지 데이터 파일을 들고 다닐 필요가 없으니 관리가 편하다는 장점이 있다.

가장 먼저 대화상자의 외형이 미묘하게 개선되었다는 것부터 언급하도록 하겠다.
세로 길이가 예전보다 아주 약간 작아졌으며, '중간 과정 글자의 표현 방식'과 '낱자 결합 최적화' 콤보 상자의 배치가 삐딱삐딱 제멋대로이던 것을 저렇게 가지런하게 맞췄다.

그리고.. (1) '생성된 데이터가 n KB 이내로 작으면 내장시킴'이라는 옵션이 추가된 걸 볼 수 있다. UTF-16 기준이므로 한글 약 500여 자가 1KB라고 생각하면 된다. KS X 1001 2350자 테이블은 5K 이상은 돼야 내장형으로 들어갈 수 있다.
내장형을 전혀 사용하지 않으려면 숫자를 그냥 0으로 지정하면 된다.

(2) 아울러, 빠른설정을 적용하는 원본 입력 설정에 이미 '지정된 데이터에 들어있는 한글' 제약이 적용되어 있는 경우, 여기 '기본 허용 범위'에도 '현재 지정된 범위 그대로'라는 옵션이 생긴다.

얘를 지정하면 그 입력 항목에 현재 적용되어 있는 한글 데이터가 분석 대상으로 곧장 연계된다. 내장형이건 외장형이건 가리지 않고 자동으로 처리된다.

분석을 통해 새로 생성된 허용 한글 데이터가 내장형과 외장형 중 어떤 형태로 처리되었는지는 이렇게 결과 페이지에서 확인할 수 있다.

2. 화면 키보드 '실제 입력 문자 표시' 옵션의 동작 개선

'화면 키보드'에는 사용자가 누르거나 뗀 글쇠를 별도의 색깔로 알려 주는 '눌린 글쇠 표시' 옵션이 있고, 이 글쇠를 눌렀을 때 실제로 입력되는 문자를 매번 동적으로 다시 계산해서 알려 주는 '실제 입력 문자 표시' 옵션이 있다.
후자는 복벌식/신세벌식처럼 글쇠의 의미가 오토마타 상태에 따라서 달라지는 입력 방식을 사용할 때 매우 유용하다.

그런데 실제 입력 문자는 글쇠에 따라서는 capslock이나 numlock 같은 램프의 점등 여부에 따라서 달라질 수도 있다. 대소문자가 바뀌는 영문 글쇠배열이 대표적인 예이다.
하지만 이건 입력기 오토마타에 직접 들어가는 글쇠가 아니기 때문에 '실제 입력 문자 표시' 옵션만 켰을 때는 바로 바로 업데이트가 되지 않았다. '눌린 글쇠 표시' 옵션까지 같이 켜야 업데이트가 됐다.

이건 이 두 옵션이 구현된 이래로 굉장히 오랫동안 존재해 왔던 한계이다. 그러다가 이제는 '실제 입력 문자 표시' 하나만 켰더라도 키보드 램프 상태가 바뀌어서 달라지는 입력 문자도 맞게 반영되게 했다.

3. 낱자 단위 검색 기능의 버그 수정

날개셋 편집기의 찾기 기능에는 한글을 낱자 단위로 검색하는 옵션이 있다. 그런데 특정 낱자 또는 아무 낱자 말고, 낱자가 없는 것(없는 낱자) 자체를 조건으로 명시하기 위해서 내 프로그램은 초중종성별로 U+F800~F802라는 특수 낱자를 사용하고 있다.

그래서 U+F802 하나만 입력했다면 현대 한글과 옛한글을 막론하고 종성이 없는 한글을 아무거나 찾아내야 하는데.. 지금까지 그 기능이 옛한글 및 미완성 한글에 대해서는 정확하게 동작하지 못했다. 'ㅎㆍㄴ' 같은 글자도 받침이 없는 글자로 잘못 판정했다. 그 이유는.. 글자를 탐색하는 단위가 잘못 지정됐기 때문이었다.

'ㅎㆍㄴ' 자체는 받침이 없는 글자가 아니기 때문에 조건을 만족하지 않아 걸러진다.
그런데 그 다음 지점으로 이동할 때 코드포인트 3개를 이동하는 게 아니라 여느 문자를 검색할 때와 마찬가지로 2개씩만 이동했다.

그러니 다음 글자는 ㅎ만 건너뛰어서 'ㆍㄴ'이 되는데.. 이게 초성 filler가 없고 정규화 규칙을 만족하지 않기 때문에 얘는 실제로는 ㆍ와 ㄴ으로 찢어져서 인식된다.
ㆍ는 종성이 없는 단독 낱자이므로 얘 때문에 'ㅎㆍㄴ'이 통째로 걸려드는.. 뭔가 아햏햏한 결과가 연출되었다.

이게 역방향으로 검색할 때는 더 골치 아픈 문제가 되는데, 어쨌든 문제를 해결은 했다. 다음 버전에서 고쳐질 예정이다. 이 버그는 정 재민 님께서 찾아내서 알려 주셨다.
그렇잖아도 한글에 종성은 별도의 filler가 존재하지 않기 때문에 '받침이 없는 옛한글' 이런 것만 찾기가 약간 난감한데, 날개셋 편집기로는 이걸 그럭저럭 수월하게 할 수 있을 것이다.

4. 블록 잡은 상태에서의 한자 변환 지원

날개셋 한글 입력기는 단어 단위로 한글을 한자로 변환하는 동작이 MS IME와 거의 동일하게 맞춰져 있다.
한자어는 무조건 한글로만 바꿔 버리지, 한글을 거치지 않고 다른 한자어로 바꾸는 기능 정도만이 미구현이다. 이건 뭐 그렇게 크게 이질적이거나 불편한 사항이 아닐 것이다.

내 프로그램이 오랫동안 지원하지 않았던 건 블록을 잡은 상태에서의 한자 변환이었다. 이 상태에서는 무조건 단어의 맨 앞까지 한글을 탐색하는 게 아니라 블록으로 잡힌 영역만 탐색해서 한자나 한글로 변환하면 된다.
하지만 내 프로그램은 텍스트에 블록이 잡혀 있을 때는 한자/한글 변환 기능이 어떤 형태로든 전혀 동작하지 않았다. 그런 상황에 대한 고려가 되어 있지 않았으며 고려할 필요성도 느끼지 못했다.

한글 입력기가 내부적으로 사용하는 텍스트 입출력 프로토콜 자체가 애초에 블록의 존재 가능성에 대한 고려가 전혀 없었다. 날개셋 한글 입력기가 이런 기본적인 동작에 대해 이토록 오랫동안 out of 안중이었다는 게 스스로 생각해 봐도 믿어지지 않을 지경이었다. 뭔가 발상의 전환 같은 걸 경험해서 블록 안 텍스트에 대한 한자/한글 변환 동작을 추가 구현했다.

* 그 밖에

(1) 한글 낱자 하나를 입력받는 자체 콤보박스에.. 내 프로그램에서만 PUA 영역을 사용해서 표현하는 비표준 낱자를 나타나지 않게 하는 옵션을 추가했다.
검색할 때 '없음'을 나타내는 용도로 사용하는 특수 낱자라든가, 원래 초성과 종성 중 한쪽에만 존재하는 낱자의 맞은편 성분 버전 같은 것이 이 범주에 속한다. (초성 ㄱㄴ, 종성 ㄱㄷ 따위)

(2) 편집기의 영문 UI에서 용지 여백이 Margine이라고 잘못 적혀 있던 것-_-, 기본 글자판 빠른설정에서 두벌식 옛한글의 글쇠배열 미리보기에 shift+J(채움 문자)와 shift+M(음절 분리) 자리가 잘못 표시되어 있던 사소한 오류도 뒤늦게 발견해서 고쳤다.

(3) 날개셋 한글 입력기의 제어판에는 글쇠배열 편집기가 있고 한글 낱자 선택 전용 콤보박스가 있다. 글자를 한 칸에 달랑 한 글자밖에 입력받지 않는 자그마한 물건이어서 존재감이 별로 없지만.. 그래도 이들 컨트롤에서도 자체 에디트 컨트롤과 완전히 같은 방식으로 날개셋 자체 입력 엔진 또는 외부 모듈(운영체제 IME, 빈 입력 스키마)을 통해 문자를 입력할 수 있다.
그런데 이들 컨트롤에서 운영체제 IME를 통한 문자 입력이 오랫동안 제대로 되지 않고 있던 것을 뒤늦게 확인하여 고쳤다.

(4) 편집기에서 단어 단위 한자 변환 대화상자를 꺼냈을 때, 변환 영역이 블록으로 지정되었다면 그 영역이 블록 색깔로 표시되어 시각적으로 변별이 되게 했다.

(5) 편집기의 찾기 대화상자에 '한글 방점 무시' 옵션을 추가했다.
방점 없이 한글만 입력해도 방점이 덕지덕지 섞인 텍스트를 검색할 수 있으니 아주 편리하다. 이런 기능을 지금까지 왜 생각하지 못했나 모르겠다.
'공백 무시', '한글 낱자 단위로', '음이 같은 한자도 검색' 같은 옵션과 함께 사용하면 검색 기능이 더욱 강력해질 것이다.

Posted by 사무엘

2021년이 되니 마소 진영으로부터 신선한 소프트웨어 소식이 전해지는 게 좀 있다.
1위는 단연 Windows 11이다.
Windows 10 이후로 주 버전명을 불변으로 고정할 거라더니, 그 정책을 6년 만에 번복하게 됐다. (Windows 10이 처음 나온 게 2015년) 업데이트로 찔끔찔끔 제품을 바꿔 나가는 것에 한계를 느낀 모양이다.

새 버전은 이제 32비트 전용 CPU의 지원을 끊고 64비트로만 나올 예정이다. 이건 뭐.. 서버 제품군에서는 이미 10년도 더 전, Vista인가 7인가 그때부터 32비트의 지원을 끊은 상태이기 때문에 전혀 새삼스러울 게 없는 결정이다. 또한 가정용 개인용 PC도 램 크기가 4GB를 넘어간 지는 이미 10년 이상 전의 일이기는 마찬가지다.

이야 그러면 버전의 명명 방식도 번호(1~3) → 연도(9x, 20xx) → 브랜드명(XP, Vista)이다가 이제 다시 번호로 회귀하는 건가 싶다(7~11). 역시 역사는 돌고 돈다. 7~8 시절에는 커널 버전과 저 번호가 일치하지 않았었는데, 10부터는 커널 버전도 대외적인 버전 번호와 일치하게 됐다.

그리고 운영체제뿐만 아니라 개발툴인 Visual Studio도 말이다. 2019 이후로 3년째 16.9.x까지 마이너 업데이트만 계속하고 있어서 이제 쟤도 메이저 업데이트를 중단했나 싶었는데.. 그렇지는 않다. 2022가 나올 예정이라고 한다.
게다가 2022는 devenv.exe IDE가 드디어 100% 64비트 기반으로 만들어진다. 이것만으로도 메이저 업데이트의 명분은 충분하다고 하겠다.

아니 그럼 지금까지는 64비트가 아니었나? 응, 의외이지만 아니었다. xcode라든가 Android Studio 같은 타 개발툴과는 상황이 다르다.
마소의 제품 중에서도 운영체제인 Windows는 XP/Vista 때 이미 x64 에디션이 나왔고 Office도 10년도 더 전의 2010부터 x64 에디션이 나왔던 반면.. 정작 개발툴 IDE는 기술적인 난관 때문인지 64비트 포팅이 굉장히 늦었다.

물론 컴파일러야 x64 타겟은 네이티브와 32-64 크로스 모두 당연히 진작부터 제공됐다. 하지만 Visual Studio IDE 자체는 여전히 32비트 바이너리였다. 그렇기 때문에 수만 개의 소스 파일들로 구성된 방대한 프로젝트를 열고 소스 코드의 인텔리센스 데이터를 관리하는 것엔 아무래도 한계가 있었다.

그래도 신기한 건 이 32비트 IDE로도 64비트 바이너리의 디버깅까지 32비트의 것과 아무 차이 없이 자연스럽게 할 수 있었다는 점이다. 원래 32비트 프로세스는 64비트 프로세스 주소 공간을 들여다보거나 훅킹 코드를 주입할 수 없다는 걸 생각하면 굉장히 신기한 일이다. Visual Studio IDE가 디버깅을 위한 64비트 호스트 프로그램을 별도로 구동하고, 얘가 32비트 IDE와 IPC(프로세스 간 통신)을 굉장히 정교하게 잘 했던 것으로 보인다.

이렇게 Visual Studio가 32비트 IDE로나마 64비트 개발과 디버깅을 정식으로 지원하기 시작한 건 무려 2005 버전부터였다.
그로부터 17년이나 뒤에야 IDE가 정식으로 64비트 기반으로 만들어지니.. 이때부터는 64비트 바이너리를 저런 별도의 디버깅 호스트 없이 IDE에서 직통으로 디버깅을 할 수 있을 것이다. (이젠 반대로 32비트 프로세스를 디버깅 할 때 디버깅 호스트를 따로 마련해야 할 듯) 취급 가능한 프로젝트의 규모가 64비트에 걸맞게 엄청 커지는 건 덤이고 말이다.

Visual C++에서 생성되는 Windows 프로젝트의 기본 configuration이 ANSI (1바이트 문자 집합) 대신 유니코드로 바뀐 첫 버전도 내 기억으로 2005이지 싶다. TCHAR이 char에서 wchar_t로 바뀌었듯, 프로그램들도 하나 둘 64비트로 포팅되면서 순수 32비트 프로그램은 갈수록 보기 어려워지는 게 느껴진다.

하긴, 과거 레거시의 압박이 훨씬 덜한 안드로이드나 iOS 같은 모바일 진영은 과거에 연연할 게 없으니 진작에 64비트로 다 갈아탔다.
요즘은 경전철이라고 해서 협궤를 쓰는 게 아니듯, 쬐끄만 스마트폰용 CPU조차도 다 64비트이다. 안드로이드와 iOS 모두, 32비트 앱의 지원은 PC보다도 더 일찍 진작에 다 끊었다.

Posted by 사무엘

1. 통일 찬송가에 수록된 제일 최신곡

한때 우리나라 교회에서 널리 쓰인 찬송가는 잘 알다시피 558곡짜리 통일 찬송가였다.
(난 21세기 새찬송가라는 건 진지하게 사용하고 분석해 본 적이 없어서 얘에 대해서는 뭐라 단정적으로 말을 못 하겠음. 그래서 라떼 옛날 것 기준으로..)

통일 찬송가는 편찬 위원들의 창작곡을 일부러 집어넣은 것을 제외하면, 수록곡들 중에 제일 최근에 만들어진 것은 1938년작인 “온 세상 위하여” 정도였다. (명목상 이것보다 미묘하게 더 최근인 곡도 있긴 하지만, 이에 대해서는 추후 다루도록 하겠음)

요컨대 이 클래식 찬송가들은 대체로, 사실상 전부 다 2차 세계 대전 이전에 만들어졌다는 것이다. 컴퓨터와 핵무기, UN 따위의 등장 이전 말이다.
난 개인적으로 저것들이 등장하기 전과 등장한 후의 인류의 보편적인 가치관과 생활 방식은 서로 크게 달라졌다고 생각한다.

또한 음악 자체만 해도.. 내가 잘은 모르지만 국민악파니 신고전주의니를 거친 뒤, 20세기 중반쯤부터는 이전보다 훨씬 더 실용/세속 영역에 속한 '현대 음악'이 주류로 등장했다. 통상적인 클래식 장르는 뭔가 매니악한 별개의 영역으로 바뀌었다.

성탄절을 소재로 하는 노래들도 1940년대쯤부터 예수 성탄 찬송보다는 세속적인 캐롤로 확 바뀌었다. 화이트 크리스마스, the Christmas song 등..
한때는 롤스로이스가 엘비스 프리슬리한테도 “당신 같은 딴따라한테는 우리 차의 품격이 어울리지 않습니다”라고 퇴짜 놓고 차를 안 팔았을 정도였던 것 아시는가? (그래도 나중엔 결국 팔았다고 함)

그리고 분야를 완전히 바꿔서 과학 쪽으로 가면.. 지금 지구의 대기는 이산화탄소 농도만 증가한 게 아니라 방사능도 전지구적으로 극미량이나마 증가해 있다고 한다. 원자폭탄 투하와 각종 핵실험 때문에..
물론 그게 인체에 당장 해를 끼칠 정도는 아니지만, 그 정도 변화에도 민감한 초정밀 기계를 만들 때는 영향을 받는다.

이 때문에 오죽했으면 1945년 이전에 만들어진 강철이 필요하다고 태평양 전쟁 때 가라앉은 일본 전함의 잔해 고철을 끄집어내서 재활용할 정도라고 한다. 바닷물 속에 쳐박혀 있으면 다른 방식으로 부식될지언정, 방사선으로부터는 완벽하게 차폐를 받기 때문이다.
인간의 과학 기술은 공기 중에 정말 새 발의 피만치도 들어있지 않은 방사능을 감지하고, 방사성 원소를 이용한 연대 측정도 하고, 납 성분도 덤으로 감지해서 무연 휘발유까지 만드는 경지에 도달해 있다.

지질학에서 6500만 년 전, 46억 년 전 할 때의 before present 기준 연도는 바로 이런 관측이 시작된 시기 근처인 1950년 1월 1일이다.
그리고 바로 그런 것처럼.. 1950년대 이전에 만들어진 찬송가들은 1945년 이전에 만들어진 철과 비슷한 대표· 상징적인 의미가 영적 분야에 있는 것 같다.
다만, 아까도 언급했듯이 “사철에 봄바람 불어 잇고”, “산마다 불에 탄다 고운 단풍에” 같은 창작곡은 1967년작이다~~ ㅎㅎ

2. 앨버트 심슨, Once it was the blessing

앨버트 심슨은 찬송가 "주와 같이 길 가는 것", "내 주 하나님 넓고 큰 은혜는"를 작사한 캐나다의 목사, 신학자이다.
이 사람이 작사한 찬송가 중에는 저것 말고도 "Once it was the blessing"이라는 게 있다.

송 명희 시 같은 대구로 가득하면서 신앙 생활과 영적 성숙의 본질이 잘 담긴 굉장히 훌륭한 시임이 틀림없다.
본인은 몇 년 전에 울 교회의 주보를 통해서 이 시를 처음으로 접했다. 담임목사님께서 엄청난 학구파 독서광에 거의 걸어다니는 신앙 서적 검색엔진 급이신 분이어서..; 온갖 출처로부터 신앙 생활과 관련된 유익한 글이 있으면 일부 excerpt를 소개하곤 하셨기 때문이다.

난 신앙 서적 검색엔진은 아니지만 회중 찬양 선곡과 인도 짬이 10수 년.. 내 찬송가 책이 다 낡고 성경책 이상으로 너덜너덜할 정도로 책을 많이 뒤진 상태였다. 걸어다니는 찬송가 검색엔진은 얼추 된다.
우리 교회에서 사용하는 '복음 찬송가' 책에 저 시와 비슷한 내용의 가사가 담긴 신곡을 본 적이 어렴풋이 있었다. 직접 불러 보거나 들은 적 없이, 악보를 눈으로 대충 읽고 지나갔던 기억만으로 말이다.

그걸 찾아냄으로써 "768장 복을 바라던 나 주를 바라고"가 울 교회에서 회중 찬송 때 최초로 소개되었다. 요런 것도 찬양 인도자가 경험하는 작은 보람이다.

기존 통일 찬송가에도 "은혜 구한 내게 은혜의 주님"이라고 곡이 실려는 있지만..
얘는 가사가 굉장히 딴판으로 번역되는 바람에 사람이 성숙하여 정반대로 바뀌었다는 원문의 저런 반전 역설을 제대로 반영하지 못하고 있다.
은혜를 구했더니 은혜, 신유를 구했더니 신유..;;;; 바뀐 게 없잖아~~ ㅋㅋㅋㅋㅋ

3. 웬일인가, 웬 말인가

우리말 찬송가 중엔 ‘웬일~’ 이렇게 놀라움, 경악을 뜻하는 ‘웬’이라는 글자로 가사가 시작하는 곡이 두 개 있는데.. 작사자는 서로 다르지만 공교롭게도 멜로디가 동일하다. 가사가 5절까지 있는 것까지도 같다~!
하나는 “웬 말인가, 날 위하여 주 돌아가셨나”라고 예수님이 감히 나 같은 죄인을 살리기 위해 십자가에 달려 죽어 주셨다니~! 그렇게 감격하고 놀라는 내용이다.

하지만 다른 하나는 “웬일인가, 내 형제여”라고 관점이 완전히 다르다. “너 그렇게 안 믿다가 죽어서 지옥 가겠구나, 마귀를 좇고 재물만 좇다가 나중에 쫄딱 망하겠구나, 불에 활활 타겠구나, 인실X을 체험하겠구나..;;” 이렇게 경고하는 굉장히 부정적인 내용이다. 찬송가에 속해 있지만 내용은 찬양이라기보다는 복음성가에 더 가깝다.

게다가.. 찬송가 가사라는 게 보통은 한국어 번역이 영어 원문보다 더 부드럽게 희석되고 미화되는 편이다. 영어에서 hell이 있다 해도 그대로 번역 안 하는 편인데..
“웬일인가 내 형제여”는 한국어 가사가 영어보다도 ‘지옥’이 더 많이 나온다~! 이건 굉장히 이례적인 번역 스타일인 것 같다.

이 정도로 청자에게 부정적인 경고, 책망조의 가사는 개인적으로 딴 데서는 주찬양 1집 “참 소경” 정도밖에 못 봤다.
“(말 못 하는 사람이 아니라 기도를 못 하는 사람이 벙어리, 앞 못 보는 사람이 아니라 주님을 볼 줄 모르는 사람이 소경 등등등~) 당신은 소경이 아닌가 / 당신은 병신이 아닌가” 이런 가사이다.;; 이건 가사가 노래 없이 시의 형태로 먼저 존재했다는 걸 감안할 필요가 있다.

그나저나 영어 찬송가는 tell과 롸임을 맞춰서 hell이 나오는 경향이 있다. “웬일인가..”뿐만 아니라 “그 크신 하나님의 사랑”도 딱 저 롸임이 존재한다~!

4. 주 하나님 지으신 모든 세계

이 유명한 찬송가는 19세기부터 20세기까지 여러 사람의 손을 거쳐서 지금의 형태로 완성됐기 때문에 내력이 좀 복잡한 곡이다. 깔끔하게 단일 작사자나 작곡자에 의해 만들어진 게 아니다.

원곡은 스웨덴 민요 멜로디에다가 언어조차도 영어가 아니었다고 한다. 독일어와 러시어 가사부터 먼저 있다가 나중에 영어 번역이 몇 가지 나왔으며, 가사는 3절까지 있던 것이 추후에 4절이 추가됐다.
이 때문에 이 곡은 처음 1, 2절은 자연의 모습을 보고 하나님을 찬양하는 시편 8편 같은 분위기이지만 3절은 "살아 계신 주" 같은 예수님의 구원 사역 얘기, 그리고 4절은 무려 재림 얘기까지 기독교 교리가 두루 등장하게 된다.

우리나라엔 1949년작 영어 가사가 채택되어 있다. 이거 가사를 번역한 사람이 4절을 추가하고 멜로디를 개작도 한 모양이다. 그렇기 때문에 이 곡은 연식에 비해 최종 작사· 작곡 연도가 2차 세계 대전까지 지난 굉장한 현대라고 기재되어 있다.
게다가 영어 가사만 바리에이션이 있는 게 아니다. 한국어 번역도. 가톨릭 쪽 번역과 개신교 쪽 번역이 서로 나뉜 상태이다.

이 곡의 영어 가사에서 주목할 부분은.. 2절에서 "그랜저"라는 단어가 나온다는 것이다.
grandeur는 우리나라에서는 자동차의 이름으로나 알려져 있지만, 원래는 '웅장함, 장관' 이런 뜻을 지닌 보통명사이기 때문이다. When I look down from lofty mountain grandeur.. 그랜저가 저렇게 쓰인 걸 본인도 난생 처음 봤다.

그랜저는.. 한때 지존파의 살생부에 이 차의 차주가 올라가 있을 정도였고 "어떻게 지내냐는 친구의 물음에 그랜저로 답했습니다" 이런 정신나간 CF도 만들어졌을 정도로 고급차의 상징이었다.;;
지금은 그랜저가 30년 전만치 고급차는 아니지만 그래도 지금도 여전히 아무나 탈 수 있는 서민형 차는 아니다.

5. 샤론의 꽃 예수

멜로디가 굉장히 예쁜 곡답게, 현대에 속하는 1920년대에 발표된 곡이다.
얘는 4개의 절로 된 가사들을 가만히 생각해 보면.. 성결교의 4대 강령과 순서대로 대응하는 것 같다. 중생, 성결, 신유, 재림. 그래서 신유에 해당하는 3절을 보면 얘는 찬송가 중에서는 흔치 않게 “질병을 고쳐 주소서”라는 간구가 들어있다~!

아울러, 영어 가사는 똑같이 my life이지만 1절은 중생(거듭남)이라는 갓 구원 문맥이기 때문에 “내 생명”이고, 2절은 그 뒤의 성화되어 가는 모습(성결) 문맥이기 때문에 “나의 삶”인 것도 주목해 보자.
아 2:1 rose of Sharon은 ‘무궁화’라고 통용되는 단어인데.. 정작 무궁화를 국화로 쓰고 있는 나라에서는 장미나 무궁화도 아니고 수선화라고 더 널리 알려져 있다. ㅎㅎ

이렇듯, 어떤 찬송가는 아주 원론적이고 무난한 메시지만 있는 게 아니라 특정 노선이나 교파의 교리를 좀 더 부각시킨 경우도 있다. 이러니 종말이나 천국을 소재로 한 찬송가는 가사를 쓰기가 난감해진다.

그런데.. “주 하나님께서 정하신 뜻대로 이 거역하는 인생을 은혜로 택했네 … 자랑하지 않게 함이요, 하나님 은혜로… 하나님의 선물!” 요 곡은..
개신교/기독교라면 차이가 존재할 리가 없는 구원과 은혜라는 공통 교리를 다룸에도 불구하고 예정론 냄새가 같이 느껴지는 듯하다. 하지만 이 정도는 꼭 장로교가 아니어도 크게 신경 안 쓰고 부르는 것 같다.

Posted by 사무엘

1. open이라는 타이틀이 붙은 유명 라이브러리들

• OpenGL: 3차원 그래픽. (DirectX만이 직접적인 경쟁자로 남아 있는 듯..)
  
• OpenCV: 2차원 래스터 그래픽에서의 영상 처리. 뽀샵질 보정, 사물 윤곽 인식 따위
  
• OpenMP: 병렬처리 프로그래밍. 단순히 함수· 클래스만 제공하는 게 아니라 프로그래밍 언어 자체의 확장까지 수반한다.
  
• OpenSSL: 각종 보안/암호 키 교환 프로토콜 구현, 해시· 암호화 함수들과 제반 연산 기능(큰 정수) 컬렉션

또 뭐가 있을까?
얘들은 각자 자기 분야에서 유구한 역사와 압도적인 인지도를 자랑하는 데다, 엄청 방대한 기능들을 무료로 덥석 제공한다. 다양한 언어와 플랫폼을 지원할 뿐만 아니라 최신 알고리즘이 수시로 반영되어 추가되고, 최신 하드웨어의 명령어에 맞게 최적화와 검증도 잘 돼 있다. 그야말로 더 바랄 게 없는 상태이다.

그렇기 때문에 개인적으로 내부 동작 원리를 공부를 하는 게 아닌 이상, 누군가가 현업에서 저런 기능들을 굳이 처음부터 다시 구현할 필요는 없다. 방대한 라이브러리의 사용법을 익혀야 한다는 최소한의 부담만이 있을 뿐.

유닉스에 대해서 누가 말했던가..? "유닉스를 쓸 줄 모르는 사람은(grep 등의 각종 명령어와 유틸리티, 정규 표현식 따위..), 유닉스가 제공하는 기능을 결국은 스스로 직접 또 만들게 될 것이다"라고..;; (reinvent the wheel) 그런 것처럼 말이다.

다만, Open이라는 단어가 붙었고 사용이 무료라고 해서 반드시 오픈소스이기까지 하지는 않은 것 같다. 가령, OpenGL이 오픈소스이고 git 저장소가 있다는 얘기는 난 못 들었다.
그리고 폰트 렌더링 분야의 본좌 라이브러리는 이름이 FreeType이다. OpenType은 라이브러리가 아니라 폰트 파일 포맷 규격의 명칭이다.

지금 국내의 오픈소스 진영엔 libhangul이라고 한글 입력 오토마타를 구현해 놓은 라이브러리가 있고 그걸 유수의 공개 한글 IME들이 사용하고 있다. 얘들은 초창기에 이름이 '열린 한글 프로젝트'였던 것 같은데 지금도 그러한지 궁금하다.

한때 '열린 한글'은 1990년대 말에 아래아한글이 개발 중단 위기에 처했을 때 "우리 다같이 힘을 합쳐서 아래아한글의 클론을 오픈소스 형태로 밑바닥부터 만들어 봅시다~!!" 이런 프로젝트의 명칭으로 쓰이기도 했었다..;; 거의 IMF 금 모으기 운동 같은 발상이었다.

이제는 마소에서 개발한 제품조차도 about이나 acknowledgement 화면에.. 제품 내부에 사용된 각종 오픈소스 프로젝트들 목록이 뜨는 날이 올 것 같은데... 격세지감이다. (하지만 나는.. 정작 내 한글 입력기부터가 오픈소스가 아니며 기존 오픈소스를 사용하는 것도 전혀 없다..;; )

2. GWBASIC 소스 공개!!

작년에는 마소에서 GWBASIC의 원본 소스 코드를 공개했다. 오오 +_+ (☞ 링크)
마소에서는 진작부터 MS-DOS와 Word의 옛날 초창기 버전의 소스를 공개한 바 있다. 하지만 그것들은 본인이 직접 써 본 기억이 없는 너무 옛날 버전이어서 그다지 감흥이나 공감이 없다.

그에 비해 GWBASIC은 본인의 어린 시절의 경험이 잔뜩 깃든 물건이고, 프로그램을 만들어 돌리는 프로그램이다 보니 접하는 느낌이 다른 제품들의 소스와는 사뭇 다르다.

• Syntax error, Missing operand, Illegal function call, FOR Without NEXT (한글판은 "문법이 틀렸읍니다, 피연산자가 없읍니다, 기능호출 사용이 잘못되었읍니다" 등등..) 같은 친숙한 에러 메시지 문자열들은 GWDATA.ASM에 있다. 전설적인 Ok 프롬프트 값도 저기에 정의돼 있다.
  
• 그래픽 모드에서 이차차분 알고리즘으로 원을 그리는 함수, 재귀호출로 flood fill을 수행하는(PAINT 문) 함수는 ADVGRP.ASM에 구현돼 있다.
  
• MOTOR문은 하는 일 없이 에러만 내뱉는 것 같았는데, GIOCAS.ASM을 보니 실제로도 그러하다. 저건 카세트 테이프의 잔재일 뿐, 16비트 PC용인 GWBASIC에서는 하는 일이 원래 없다.
  
  
• F1에 LIST부터 시작해 TRON, TROFF, KEY, SCREEN 0,0,0을 기본 배당하는 테이블은 GWRAM.ASM에 있고..
  Alt+A에 AUTO부터 시작해 BSAVE, COLOR, ... 등을 배당하는 테이블은 IBMRES.ASM에 있다.
  
• 소스를 저장할 때 SAVE에다가 P 옵션을 줘서 어설프게 암호화 프로텍션을 거는 부분은 GIODSK.ASM, DISKCOM.ASM을 참고하면 될 듯하다.
  암호화된 파일과 그렇지 않은 파일이 첫 바이트 0xFE 또는 0xFF로 구분된다는 것을 확인 가능하다.
  
• PLAY문에서 A~G 등 각종 문자열들을 해석하는 부분은 GWSTS.ASM을 보라. "MUSIC MACRO LANGUAGE"라고 주석이 돼 있다.
  
  
• 부동소수점 연산?? 요즘처럼 전용 CPU 명령어 한 방으로 끝나는 시절이 아니었으니 전부 자체 구현이다.
  빌 게이츠가 왕년에 직접 고안했다는 MBF 부동소수점의 구현부가 바로 MATH1/2.ASM에 있다. 삼각함수, 로그도 내부적으로 테이블을 내장해서 소프트웨어적으로 직접 계산한다.
  
• 난수를 생성하는 RND 함수의 공식은 MATH1/2.ASM에 있다. 그 유명한 Donald Knuth 아재의 책을 참고해서 구현했다고 주석에 적혀 있다.

아아.. 옛날 추억이 새록새록~~~
어셈블리어 코드를 읽을 수 있다면 흥미로운 유물들이 넘쳐날 것이며 아는 만큼 보일 것이다. 내가 읽을 수 있다는 뜻은 아님..;;
GWBASIC은 아무래도 정상적인 소프트웨어 개발 도구와는 좀 동떨어진 구석이 있지만, 그 옛날에 대화식 프로그래밍 환경이라는 걸 만들 생각을 한 건 충분히 참신하다고 볼 수 있다.

2000년대 이후에 태어난 뉴비 프로그래머들을 위해서 FAQ를 아주 자상하게 써 놨다. 이런 질문의 답변까지..;;

• 아니, 오픈소스라면서 확장자가 C/CPP인 파일이 왜 하나도 안 보이나요?
  
• C 파스칼 놔두고 왜 이렇게 알아보기 어려운 언어로 코딩을 했나요?

저 때는 고급 언어 컴파일러들이 엄청나게 비쌌고, 생성하는 코드의 성능이 좋지 못했다.
빌 게이츠와 그 일당들은 20대 나이 때, 지금보다 컴퓨터가 훨씬 더 열악하고 비싼 기계이던 시절에 여느 평범한 프로그램이 아니라 딴 프로그램을 만들고 돌리는 가상 머신급의 프로그램을 한땀 한땀 어셈블리어로 코딩해서 돌리고 납품하고 팔아먹었다는 거다.
그리고 한 언어의 인터프리터로서의 기능이 다 들어있던 GWBASIC.EXE의 크기는 실행 파일 압축 따위 없이도 겨우 6만 바이트 남짓밖에 안 했다는 거다.

이건 16비트 x86이 다른 CPU 아키텍처와 비교해 봐도 명령어 배치가 이례적으로 굉장히 조밀하기도 했기 때문에 가능한 일이다. 메모리 아끼기 위한 CISC 방식의 승리인 셈이다.

Posted by 사무엘

1. 통상적인 위치와 형태로 만들어지지 않은 지하철역

지하철역이라는 건 ‘대로’급 큰길의 특정 지점에 출입구가 만들어지며, 보통은 길과 길이 만나는 교차로에 만들어지는 게 정석이다.
그런데 이런 통념을 깨는 역도 소수나마 존재한다.

(1) 4차로밖에 안 되는 아담한 크기의 도로에 지하철역이 있는 것만으로도 상당히 이례적으로 보인다. 그런데 종점 부근이나 지형이 특이한 곳에는 지하철이 2차로 골목길 아래로 지나기도 한다.
서울 지하철 7호선 면목-사가정 사이.. 여기는 지상에서 땅을 파헤치는 개착식은 엄두를 낼 수 없고 그냥 지하에서 땅굴을 파서 길을 냈을 것이다.

그리고 6호선 독바위 역, 5호선의 마천 종점 부근도 좁은 골목길이다. 특히 마천의 경우 그나마 큰길이 있는 오금로-마천로를 일부러 회피하고 엄한 곳에다 역을 힘들게 만든 것에 가깝다. 지하철을 만들던 당시에는 그쪽에 군부대가 있었기 때문이다.

(2) 7호선 청담 역은 단일역만으로 학동로의 한 블록(약 600미터;; ) 거리를 몽땅 커버하는 형태로 엄청 길게 만들어졌다. 역을 양 교차로에 두 개 만들고 이들을 지하 상가 통로로 한데 연결한 게 아니라, 중간에 단일역이라니.. 참 특이하다. 그래서 환승역이 아님에도 불구하고 출입구도 종로3가 급으로 엄청 많다.

분당선 서현과 수내는 길이 아니라 건물의 내부와 아래에 역이 들어섰다. 지금도 그런지 모르겠는데 지하철 출입구 번호와 건물의 출입구 번호가 상이한 아주 괴상한 구조가 됐다.

그 뒤, 신분당선· 경강선의 환승역인 판교 역도 교차로가 아니라 건물 공간의 정중앙에 있다. 그래서 주변의 버스 정류장이 "판교 역 동서남북편"이라고 다 있다. 하지만 그렇다고 역을 감싸는 건물이 있는 건 아니다. 뭐, 앞으로 지어질지는 모르겠지만..

그러고 보니 출입구가 하나밖에 없는 지하철역도 아주 드문 편이다. 내가 아는 건 3호선 학여울 정도가 유일하다.

2. 존재감 없거나 봉인된 지하철 출입구

(1) 수도권 전철 4호선의 북쪽 종점인 당고개 역은 마지막 5번 출구가 철덕들 사이에서 오랫동안 유명했다.

영락없이 영화 아저씨의 "나와라, 죽는다" 장면을 떠올리게 하는 좁고 어둡고 음침한 분위기에다, 통로도 엄밀히 말하면 역의 내부가 아니라 외부에 더 가까웠다. 3호선 남부터미널 역의 4-1, 4-2번 출구 같은 느낌??
심지어 이 출구는 안내도에 표시돼 있지도 않았었다(1~4번만..).

그러다가 2010년대 후반이 돼서야 주변의 폐상가 건물들이 다 헐리고 6번 출구까지 생기면서 5번 출구도 회생하게 됐다.
게다가 이 역은 4호선이 산 너머 남양주 별내와 진접까지 연장되면 종착역이 아닌 단순 통과역으로 바뀔 예정이다. 창동 차량기지조차 이전하니까 말이다.

(2) 공교롭게도 같은 4호선의 남쪽 종점인 오이도 역 역시... 마지막 3번 출구는 그냥 버려진 잉여 출구나 마찬가지이다. 20년 전이나 지금이나 동일하게.. 거기는 텃밭과 야산밖에 없는 황무지이다.;;

(3) 분당선 야탑 역은 지상 출입구 말고 근처의 버스 터미널로 직통하는 지하 통로가 만들어져 있긴 했으나, 2000년대 후반까지 모종의 이유로 인해 개방되지 않고 오랫동안 봉인돼 있었다. 그러나 이것도 오래 전부터 옛말이 됐고 2010년쯤부터는 완전히 개방 상태이다.

또 이런 예가 더 있을 것 같은데.. 별로 생각이 안 난다.
출구가 하나밖에 없는 드문 역은 2호선 신답, 3호선 학여울, 6호선 독바위 정도가 전부인 것 같다. 광역전철까지 포함하면 산을 뒤로 낀 한적한 지상 시골역 중에 이런 예가 더 나오겠지만 그건 논외로 하자.
서울 지하철 5호선의 마천, 마곡 역도 처음 만들었을 때는 출구가 1개밖에 없었지만 훗날 공사를 통해 출구가 더 생겼다.

3. 좌석의 테이블 배치 방식

내가 철덕 겸 교통덕으로서 이 주제를 하루 이틀 파고든 게 아니었는데 비교적 최근에야 눈에 띄기 시작한 차이점이 있다. 바로 좌석의 뒤쪽에 그물과 테이블이 비치된 방식이다.

KTX는 기내지가 꽂혀 있는 그물이 좌석의 위쪽에 있고, 테이블은 그 아래에 있다. 그래서 테이블을 펼치려면 아래에 접혀 있던 것을 위로 끄집어내면 된다.
이런 형태의 좌석은 내가 아는 교통수단들 중에서는 KTX만이 유일하다. 산천도 포함해서.

그 반면, 비행기는 이렇게 테이블이 좌석의 위쪽에 있고, 그물이 그 아래에 있다. 테이블을 펼치려면 스위치를 살짝 돌려서 테이블이 아래로 내려오게만 하면 된다. 차이점이 신기하지 않은가?
위의 사진에서 보다시피 SRT도 비행기와 같은 형태로 좌석이 만들어져 있다.

한편, 고속버스는 전통적으로 테이블이 없고 그 특유의 컵 받침대 정도만 있다.
그리고 좌석이 우등 이상으로 안락해져서 간격(피치)이 커지면 테이블은 저렇게 앞좌석의 뒤쪽이 아니라 자기 좌석의 팔걸이나 옆쪽에서 끄집어내는 형태로 바뀌게 된다.

Posted by 사무엘

1. 우한 괴질(폐렴)

2021년도 벌써 절반이 지난 하반기로 접어들었다.
이번 7월은 3년 전의 악몽을 다시 떠올리게 하는 극악의 무더위에다, 급격히 무섭게 확산되기 시작한 우한 괴질 때문에 인해 전국적으로 몹시 힘든 시기가 아닐 수 없었다.
서울과 수도권에는 사회적 거리 두기 등급이 최고 단계(lev 4)로 올라서 저녁 모임이 사실상 봉쇄돼 버렸으며, 교회 예배도 10%나 20%도 아니고 대면 예배가 또 통째로 금지돼 버렸기 때문이다.

이 시국에 대해서 요즘 기독교계에는

• 교회도 방역 시책 꼭꼭 잘 지켜서 괜히 교회에서 확진자 나와서 주변 불신자들한테 욕먹고 간증 상실하는 일이 없게 해야 한다. 비대면 예배는 종교적으로 다른 불순한 의도가 있는 게 절대 아니다.
  
• 우한 괴질은 선동하는 것만치 위험한 게 아니며, 이런 뻘짓 한다고 막을 수 있는 것도 아니다. 저건 효과도 일관성도 없는 정치방역 방역독재일 뿐이며 더 나아가 예배를 못 드리게 하는 교묘한 기독교 박해이다.

대충 이런 두 시각이 공존하면서 첨예하게 대립하는 것으로 보인다. 난 편의상 전자를 좌파, 후자를 우파라고 분류한다.

왼쪽으로 도가 지나치면 "우리 문프달님 짱, K방역 짱, 말 안 듣고 방역수칙 안 지키는 놈들만 나쁜놈. 비대면 예배는 제2의 종교개혁" 이런 쳐돌은 짓거리로 빠지며..
오른쪽으로 도가 지나치면 방역 정책의 무능 모순 정치질 비판을 넘어서 거의 백신 = 666, ㅇㅎ 폐렴 = 여느 독감이나 그에 준하는 이상한 음모론 짓거리로 빠진다.
이에 대해 한데 치우치지 않은 좀 정상적이고 건전한 분별이 필요하다.

나는 우리 주님께서 납세를 손수 실천해 보인 정도로.. 교회도 정부의 방역 시책에 따르는 것이 잘못됐다고 보지는 않는다. "그럼에도 불구하고 우리가 그들을 실족시킬까 염려하노니..." (마 17:27) 마태복음 17장 끝부분 이야기를 방역 시책에다 대입해서 읽어 보시라.

방역 시책이 대놓고 노골적으로 "교회만 예배 금지. 엿먹어라~! 성당이나 절이나 다른 집회들은 몽땅 OK" 이딴 식으로 말하지 않는 한, 그리고 우리가 의대 간호대 약대를 나온 의료인이 아닌 한, 일단은 전문가와 행정가의 말에 순응해 봐라.
최소한의 본분은 다하고 나서 그 다음에, 노골적이지는 않지만 교묘하게 불순한 의도가 있는 것 같으면 편파적인 정치 방역을 욕하고 비판하고 집회를 하고 SNS에다 글 올리고 시위를 하든지 말든지 하는 거다.

이게 가장 이성적이고 건전하고 성경적으로나 개인 양심에 거리낄 게 없는 대처가 아닐까 한다.
그냥 정부 시책에만 100% 따라서 비대면 예배를 드리건, 아니면 벌금 먹으면 내고 말지 생까고 끝까지 모이건.. 그건 각 교회들이 재량껏 결정할 사항이다. 옳고 그름을 따질 문제는 아니어 보인다. 한쪽이 믿음이 좋은 게 아니고 다른 한쪽이 마냥 타협하고 믿음을 저버린 것도 아니다. 내가 보기엔 벌써 그 정도 지경까지 된 건 아니다.

옛날에는 거리설교 때문에 교인이 공권력과 갈등을 빚는 경우가 종종 있었는데 요즘은 예배 자체 때문에 이런 갈등이 생기기도 하는구나.;; 이게 담대함인지, 아니면 그냥 무례 객기 깽판인지 잘 생각해 봐야 할 것이다.

2. 옛날 프로그램 수정 내역

사회가 뒤숭숭하지만 그래도 내 개인적으로 프로그램 개발은 계속되고 있다.
날개셋 한글 입력기의 다음 버전 개발 근황은 오는 8월쯤에 한번 올라올 것이다. 날개셋뿐만 아니라, 옛날 자료실에 있는 '3차원 그래픽 시연 프로그램'과 '삼각형의 오심 그리기 프로그램'을 약간 고친 소식도 여기서 같이 전하고자 한다.
먼저 전자는.. Shift를 누르고 있는 동안 우버튼+드래그(시점 전환)가 되지 않던 고질적인 문제를 해결했다.

Shift는 위/아래 화살표나 마우스 왼쪽 버튼을 눌러서 이동할 때 Z축은 움직이지 않게 한다. 그래서 얘를 누르면 위나 아래를 보는 채로 앞뒤로 이동할 수 있다.
하지만 얘는 이동 말고 시점 전환과는 아무 관계가 없는 기능이니.. 누르든 말든 오른쪽 버튼 드래그는 잘 동작해야 한다.

내가 지난 2010년대 동안 우버튼 드래그가 가능하지 않은 맥북을 사용해서 그런지.. 이 문제를 인지하고 해결해야 할 필요성은 오랫동안 느끼지 못했었다.

그리고 다음으로 오심 그리기 프로그램은 벌써 5년이나 전인 2016년 가을에 기능이 많이 추가되고 업데이트 된 적이 있었는데, 최근에는 또 자그마한 기능을 추가했다. 바로 나폴레옹의 정삼각형을 그리는 기능이다.
얘는 그 특성상 삼각형의 무게중심과 관계가 있기 때문에 무게중심과 동일한 색깔로 그려지게 했다.

3. 식물

부모님께서 은퇴 후에 여기저기 식물을 심고 가꾸는 것에 재미를 붙여 계시는데..
본인도 그걸 어깨 너머로 여러 번 보면서 조금씩 재미를 붙이고 있다.
정식으로 분양받은 텃밭 말고 옥상 화분, 강가, 산기슭 같은 곳에 몰래 씨를 뿌려 놓은 게 자라는 걸 보면.. 무슨 광주리에 담아서 강에다 띄워 보낸 모세(?) 생각도 나고.. 그래도 줄기가 길어지고 잎이 커지고 꽃도 피는 게 참 경이로워 보인다.

오오.. 나름 강가에서 자그맣게나마 인간이 먹을 수 있는 땅의 소출이 나왔다. 지름 8cm 남짓이다.
인간이 만든 각종 복잡한 기계류의 전선· 케이블하고.. 식물의 줄기는 구조적으로 어떤 차이가 있는 걸까.
그래서 성경에서도 첫 열매, 첫 열매 거리는 것일 테고.. (출 23:16, 잠 3:9 등)
박 넝쿨이 죽어 없어진 것 + 더운 것 때문에 버럭 징징거렸던 요나의 심정이 정말 이해가 된다.

천재지변으로 하루아침에 농사를 망치게 됐다면 농부는 완전 멘붕 할 수밖에 없을 것이고..
풍년이라 해도 전근대 시절 옛날 농민들은 수확한 거 대부분을 세금으로 빼앗기고 가난하게 살아야 했다.;;
그 빈곤의 악순환을 끊어 준 건 누가 뭐래도 산업화 근대화이다.

처음에 이랬던 호박은 한 달 남짓한 시간 만에 1m가 넘는 넝쿨로 자랐다.
저 작은 상자로는 감당할 수 없어서 지금은 모처에다가 옮겨 심었는데.. 오랫동안 야생과 같은 급으로 햇볕을 못 받고 뿌리를 마음껏 아래로 내리지 못해서 그런지.. 지금도 발육이 좀 부진한 것 같다.

4. 강과 계곡

본인은 2010년대 중후반쯤에 등산에 처음으로 재미를 붙였다. 그래서 이 블로그에다가도 서울 근교의 산들을 오른 사진 기록을 수십 편씩 올렸다.
그 등산 취미가 나중에는 차박과 캠핑으로 미묘하게 바뀌었다. 산을 정상까지 오르는 것보다는 산기슭이나 중턱 적당한 곳이라도 텐트 치고 자는 것으로 목표가 달라진 것이다.

그러나 한여름에는 등산을 할 수 없을 정도로 너무 덥다. 열대야가 심하면 등산뿐만 아니라 캠핑도 불가능해지고 그냥 집에서 에어컨 틀고 자는 게 더 낫게 된다.
상황이 상황이다 보니 자연에 대한 본인의 관심은 산과 평지를 거쳐서 물로 옮겨졌다.

몇 년 전에 뚝섬 한강 공원에서 오리배를 탄 적이 있었는데 요 근래에는 양화 한강 공원에서도 오리배를 몰아 봤다. 이거 바람 때문에 생각보다 시원하고 좋았다. 평소에 수십 m 이상의 거대한 교량 위에서 내려다보기만 하던 한강 물을 이렇게 가까이에서 볼 일이 언제 있겠는가?

내가 알기로 서울에서 오리배가 있는 한강 공원은 뚝섬, 양화, 여의도 정도이다. 또 더 있는지는 잘 모르겠다.
단, 양화는 내가 갔던 시절에는 전동은 없고 수동 페달만 있어서 주행이 좀 힘들었다.

양화 한강 공원과 가까이 있는 선유도를 나름 보트로 이렇게 접근할 수도 있다.

아.. 이 물 좀 보소~
요즘 같은 계절에 이런 계곡물이 있으면 난 온몸을 담궈서 자가침례를 행하고, 그걸로 모자라서 폭포에서 쏟아지는 물을 벌컥벌컥 마시기도 해야 직성이 풀린다. 그래서..

물 맑고 공기 좋은 자연 속에서 버그 하나 잡고 기능 하나 구현하고 갔다.
참고로, 이 사진을 찍어 주신 분은 저런 짓을 도대체 왜 하냐는 송충이 씹은 표정으로 사진을 찍었다. ㅋㅋㅋㅋㅋㅋㅋ

Posted by 사무엘