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

프로그래밍에서 메모리를 가리키는 포인터라는 건.. 그 특성상 돌아가는 컴퓨터의 machine word와 크기가 동일하다. 하지만 현실에서 포인터(= 메모리 주소)를 구성하는 모든 비트가 골고루 쓰이는 일은 몹시 드물었다.

먼저, 컴퓨터의 실제 메모리 양이 포인터가 가리킬 수 있는 범위보다 훨씬 적다. Windows의 경우, 32비트 시절에는 user mode에서는 대부분의 경우 포인터의 상위 비트가 언제나 0이었던 것이 잘 알려져 있다(하위 2GB까지만 사용).
하물며 64비트는 공간이 커도 너무 크기 때문에 가상 메모리 관리 차원에서도 아직은 40~48비트까지만 사용한다. 상위의 무려 16비트가량이 쓰이지 않는다는 것이다. 램이 32GB여도 겨우 35비트면 충분하니까..

가난하고 배고프던 20세기 16비트 시절에는.. 반대로 포인터 하나만으로 겨우 몇백 KB~수 MB 남짓한 메모리도 한번에 다루지 못했다. 그래서 far 포인터니 huge 포인터니 별 삽질을 다 해야 했는데 그때에 비하면 지금은 격세지감이 따로 없다.

저렇게 상위 비트뿐만 아니라 하위 비트도 마찬가지이다. padding, align 같은 이유로 인해, 메모리 할당 함수의 포인터 리턴값이 홀수가 될 일은 일반적으로 없다. 아니, 겨우 2의 배수가 아니라 4나 8의 배수가 될 수도 있으며, 이 경우 하위 2~3개 비트도 0 이외의 값을 가질 일이 없게 된다.

그러니 포인터를 저장하는 공간에서 0 이외의 값이 들어올 일이 없는 비트에다가 자신만의 정보를 넣는 꼼수를 부리는 프로그램이 예로부터 줄곧 존재해 왔다.
이거 무슨 변태 같은 짓인가 싶지만.. 이제 막 32비트로 넘어가긴 했지만 아직 가정용 컴퓨터들의 평균적인 메모리 양이 수 MB대밖에 안 됐던 시절이 있었다. 이때는 메모리가 부족해서 하드디스크 스와핑이 일상이었다. RAM을 1바이트라도 더 아끼는 최적화가 필수였다.

가령, 다재다능한 자료구조인 빨강-검정 나무를 생각해 보자.
노드의 색깔을 나타내는 겨우 1비트짜리 정보를 위해서 굳이 bool 멤버를 추가하는 건 굉장한 낭비라는 생각이 들지 않는가? 단 1비트 때문에 구조체 패딩까지 감안하면 무려 2~4바이트에 달하는 공간이 매 노드마다 허비되기 때문이다.
안 그래도 노드의 내부엔 left/right 같은 딴 노드 포인터가 있을 것이고, 포인터 내부에 쓰이지 않는 1비트 공간이 있으면 거기에다 색깔 정보를 박아 넣고 싶은 생각이 들 수밖에 없다. 비트필드와 포인터의 union 써서 말이다.

물론, 그렇게 0으로만 채워지던 공간을 운영체제에서도 나중에 유의미하게 사용하기 시작하면.. 그 꼼수 프로그램은 재앙을 맞이하게 된다.
대표적인 예로 마소에서는 32비트 기준으로 사용자:커널이 통상적인 2GB:2GB가 아니라 3GB:1GB로 주소 공간을 분할하는 기능을 Windows에다가 추가했다.

이러면 사용자 모드의 포인터도 2GB가 넘는 영역에 접근할 수 있으며 최상위 비트가 1이 될 수 있다. 그런데 포인터의 최상위 비트를 자기 멋대로 사용하고 있는 프로그램은.. 뭐 메모리 뻑나고 죽을 수밖에 없다.
64비트 환경에서는 겨우 1비트가 아니라 상위 word 전체를 다른 용도로 전용해도 당장 이상이 없으며 이 추세가 앞으로 몇 년은 가지 싶다. 컴퓨터의 램이 256~512GB나 1테라까지 간다면 모를까..

요즘 컴퓨터야 메모리가 워낙 많고 풍족하니, 굳이 저런 꼼수를 동원하는 프로그램은 별로 없을 것이다.
하지만 저 때가 되면 또 꼼수 부리는 말썽꾸러기 프로그램과의 호환성 때문에 주소 공간을 옛날처럼 상위 16~32GB까지로 봉인하는 옵션 같은 게 또 등장할지도 모른다.;;; HIGH_DPI_AWARE처럼 LARGE_ADDRESS_AWARE 시즌 2 말이다.

여담이지만 Windows의 경우, 실행 파일은 시작 주소가 언제나 64KB의 배수 단위로 부여되기 때문에 HINSTANCE/HMODULE은 아래쪽은 무려 word 덩어리가 언제나 0이 된다. 이 특성을 이용해서 운영체제의 LoadLibraryEx 함수도 하위 몇 비트를 자기 마음대로 활용하기도 한다.

※ 나머지 메모

(1) unsigned 타입에 대해서 단항 연산자 -를 적용해서 -a 이런 값을 구하는 코드를 우연히 보고는 개인적으로 신박하다는 생각이 들었다. 흐음~ Visual C++의 경우 이건 원래 경고인데, 요즘 버전에서는 더 엄격하게 에러로 처리하는가 보다.
-a는 2의 보수의 특성상 ~a+1과(비트 not보다 1 크게) 완전히 동일한 효과를 내며, 앞에 0을 붙여서 이항 연산자로 만들어도 에러를 회피할 수 있다.

(2) ANSI C에서는 함수의 prototype을 선언할 때 매개변수 리스트에 타입만 써 넣고 이름을 빼먹으면 안 된다는 걸 최근에야 알게 됐다.
아니 도대체 왜..? 거기서 매개변수의 이름은 거의 잉여 옵션에 불과할 텐데.. void func(int);라고만 쓰면 틀리고 void func(int x);라고 아무 이름이라도 붙여야 된다는 것이다.
이건 먼 옛날에 C언어에서 void func(a) int a; 같은 구닥다리 문법이 쓰이던 시절의 잔재인 것 갈다.

Posted by 사무엘

컴퓨터그래픽에서 벡터 그래픽의 반의어로 픽셀과 비트맵을 다루는 체계를 래스터 그래픽이라고 흔히 부른다. 종이가 아니라 해상도가 상대적으로 낮은 모니터 화면이 주 무대이고, 면을 채우는 기본 단위가 scan line(주사선)이라는 관점에서 정립된 용어이다.

그리고 2D 비트맵(더 정확한 명칭은 래스터..?) 그래픽 API를 보면 어떤 플랫폼용 어떤 언어의 라이브러리이든지 점과 직선, 곡선을 그리는 함수가 있고, 사각형과 원을 그리는 함수가 있다. 이게 기본이다.
점이나 사각형이야 그리는 방식이 너무 trivial하니 제끼고, 원이나 곡선을 빠르게 그리는 원리는 기하 알고리즘의 일종으로 다뤄지기도 한다. 그 단순한 직선조차도 굵기가 2픽셀 이상이 되면 중심점을 생각해야 할 것이고, 무거운 부동소수점 연산 없이 anti-aliasing까지 하면서 그린다는 조건이 추가되면 결코 쉽지 않은 일이 된다.

그리기 기능 중에서 특정 픽셀부터 시작하는 flood fill은 무척 독특한 동작이다. 기하 알고리즘이라기보다는 스택 메모리를 동원해서 컴에게 길 찾기 재귀호출 노가다를 시키는 코딩의 영역이다. 빼곡한 미로의 내부에 있는 한 점에서 flood fill을 시켜 보면 이건 본질적으로 길 찾기와 다를 바 없다는 걸 알 수 있을 것이다.

글쎄, flood fill은 그래픽 에디터에서 사용자가 내리는 채우기 명령을 구현하는 형태로나 쓰이지, 직선과 곡선, 사각형과 원처럼 그림을 그리는 구성요소로서 프로그램이 내부적으로 사용할 일은.. 정말 아주 특수한 상황이 아니라면 없을 것이다. 도형 자체를 처음부터 내부가 채워진 형태로 그려야지, 도형의 윤곽만 그린 뒤에 도형 내부의 임의의 점을 따로 주고 채우는 건 몹시 비효율적이기 때문이다.

그래서 그래픽 라이브러리에는 다각형을 그리는 함수가 있다. 다각형의 경계선만 찍찍 그리는 것이야 LineTo만으로 얼마든지 할 수 있으므로, 이런 함수는 내부가 채워진 다각형을 그리는 것이 핵심이다. 그러니 이 함수는 다른 함수와 달리, 반드시 다각형의 꼭지점들이 담긴 배열을 전달받아야 한다.
옛날 도스 시절의 베이식은 타 언어들에 비해 그래픽 모드의 접근성이 좋았지만, 정작 다각형을 그리는 API는 없었다.

그럼 다각형을 채우는 기능은 어떤 방식으로 동작하는 걸까?
이걸 구현하기 위해서는 어떤 점이 다각형의 내부에 속하는지를 판단해야 한다. 더 나아가서 이 점에서 한쪽으로 scan line을 그어 나갈 때 어디까지가 동일하게 다각형의 내부 또는 외부인지를 판단해야 한다.

이걸 판단하는 방법은 의외로 간단하다. 그 점으로부터 아무 방향으로(예: x축 양의 방향) 한없이 직선을 그을 때, 그 선이 다각형을 구성하는 선분과 얼마나 몇 번이나 마주치는지를 판단하면 되며, 이걸 판단하는 방법도 크게 두 갈래로 나뉜다. 바로 (1) 홀짝 아니면 (2) 0여부이다.

홀짝법은 마주친 선분이 짝수 개이면 다각형의 외부이고, 홀수 개이면 내부라고 판단한다. 다시 말하지만 이 가상의 선은 정말 아무 방향으로나 그리면 된다. 다각형이 모든 방향으로 닫혀서 내부에 공간이 존재한다는 사실 자체가 이 판별법의 correctness를 보장해 준다.

0여부는.. 홀짝보다 더 절묘하다. 초기값이 0인 가중치라는 걸 두는데, 마주친 선분이 우리가 그은 가상의 선을 위에서 아래로 교차한다면 가중치에 1을 더한다. 그렇지 않고 아래에서 위로 교차한다면 1을 뺀다.
이렇게 해서 최종적으로 가중치가 양수든 음수든 0이 아닌 값이 나온 점은 다각형의 내부라고 간주하고, 0인 점은 외부라고 간주한다.

0이나 홀짝이나 그 말이 그 말 같은데.. 실제로 자기네 선분끼리 배배 꼬아서 교차하지 않는 일반적인, 평범한 오목/볼록다각형이라면 어느 판별법을 사용하든 결과에는 아무 차이가 없다.
하지만 당장 오각형 별표를 한붓그리기로 그린 궤적을 줘 보면 둘은 서로 차이를 보인다.

오각형 별표에서 별의 중앙에 생긴 공간을 보면.. 그 옆으로 다각형 경계를 나타내는 선이 어느 방향이든 두 개가 존재한다(짝수). 그런데 이들은 방향이 둘 다 오르막 아니면 둘 다 내리막이며, 이 때문에 winding value는 nonzero가 된다. 그러니 ALTERNATE일 때는 이 공간이 비워지지만 WINDING일 때는 공간이 채워지는 것이다.

그 위의 더 복잡한 꼬인 사각형도 상황이 비슷하다. 잘 살펴보면 이 궤적도 홀수점이란 게 전혀 존재하지 않으며 한붓그리기가 가능하다.
그런데 WINDING일 때는 궤적이 꼬여서 생긴 내부의 사각형 공간 둘 중에서 좌측 하단 한 곳만 채워져 있다. 그 이유는 역시 저기서만 winding value가 nonzero이기 때문이다.

일반적으로 WINDING(0여부)이 판정하는 다각형 영역은 ALTERNATE(홀짝)의 상위 호환이다. ALTERNATE가 판정하는 영역을 100% 포함하면서 일부 영역을 추가적으로 더 판정한다는 뜻이다. 그렇다고 해서 모든 닫힌 영역을 한 치의 예외 없이 몽땅 내부라고 판정하는 건 아니다.

뭐.. 현실의 벡터 그래픽에서 이 따위 선끼리 교차하는 배배 꼬인 폴리곤을 생성하는 것은 애초부터 권장되지 않는 금지 사항이다. 가령, 속이 빈 오각별을 그리고 싶으면 저렇게 보이는 대로 삼각형 다섯 개로 풀어서 표현하라는 것이다. 윤곽선 폰트 등 벡터 그래픽 편집기들은 그렇게 폴리곤의 모양을 자동으로 수정해 주는 기능도 제공한다.
그러니 이렇게 fill mode의 차이점을 미주알고주알 관찰할 일이 현업에서는 거의 없을 것이고, 이런 건 그냥 학교에서 컴퓨터그래픽스 기초를 공부할 때 이런 방식도 있다는 걸 알기만 하고 넘어가면 될 것 같다.

하지만 그게 전부가 아니다. 다각형 채우기의 기능이 더 확장되면 다음 영역에도 도달하는데, 이때 fill mode의 차이점이 다시 드러나게 된다.

1. 여러 다각형을 한꺼번에 그리기
이건 내부에 구멍이 뚫린 다각형을 그릴 수 있다는 것에 의의가 있다. 구멍은 Polygon 함수를 연달아 호출하는 것으로는 표현할 수 없기 때문이다.

Windows에는 여러 다각형을 한꺼번에 그리는 PolyPolygon이라는 함수가 있다. 그런데 아까처럼 한 다각형에서 변들이 서로 교차하고 꼬였을 때뿐만 아니라, 변은 꼬이지 않았고 여러 다각형들의 영역이 서로 겹칠 때에도 fill mode의 차이는 유의미한 동작의 차이를 만들어 낸다.

위의 그림은.. 뭐 이론적으로는 한붓그리기가 가능하기 때문에 역시 꼬인 단일 다각형으로 궤적을 나타낼 수 있다. 하지만 앞서 예를 들었던 오각별이나 그 사각형 그림과 달리, 일부 점과 점이 겹치는 건 피할 수 없을 것이다. 무슨 말인가 하면, 저 궤적을 꼭지점 좌표의 배열로 기술했을 때, 4개의 선분과 만나는 점은 두 번 등장하는 부분이 생긴다는 것이다.

꼬인 단일 다각형이 아니라 영역이 일부 겹치는 사각형과 삼각형을 서로 떼어서 PolyPolygon으로 그린 경우.. ALTERNATE(홀짝)에서는 짝수 개의 다각형에 속하는 영역은 비우고, 홀수 개에 속하는 영역만 칠한다. 그러고 보니 동작이 뭔가 XOR스러워 보인다. 각 다각형들의 꼭지점이 기술된 방향은 어느 쪽이건 무관하다 (시계 or 반시계 방향)

그러나 WINDING(0여부)일 때는 그 특성상 방향이 같은 다각형들은 겹치더라도 영역을 모두 칠한다. 겉의 껍데기가 시계 방향이라면.. 그 안의 구멍은 반시계 방향으로.. 다른 방향으로 칠해져야 구멍이 비게 된다! 다시 말하자면, WINDING에서도 위의 그림의 왼쪽처럼 중앙이 비어진 그림을 그리고 싶다면 사각형과 삼각형의 좌표 방향이 서로 반대여야 한다.
꼬인 단일 다각형에서 fill mode의 차이점을 설명하는 프로그래밍 서적들이.. 다중 다각형까지 연계해서 동일 개념을 설명하는 경우는 내가 딱히 못 본 것 같다.

2. 직선뿐만 아니라 베지어 곡선까지 포함된 궤적의 내부를 채우기
위와 같은 구멍 감지에다가 곡선 지원까지 포함되면.. 이건 뭐 윤곽선 글꼴 래스터라이저가 번듯하게 완성된다. 물론 본격적인 폰트 엔진은 거기에다 작은 크기에 대비한 정교한 안티앨리어싱과 힌팅, 글꼴 글립 캐시, 더 나아가 복잡한 유니코드 문자 형태 분석까지 추가되는데 이것들 하나하나가 별개의 전문 영역일 정도이다.

FreeType 라이브러리는 그 중에서 제일 저수준인 그리기, 안티앨리어싱, 힌팅까지만 담당한다. 요즘 소프트웨어들은 글자 하나를 찍는 것도 겨우 8*16, 16*16 비트맵 글꼴 찍던 시절과는 차원이 다르게 더 복잡해져 있는 셈이다.
그건 그렇고.. Windows API에는 직선과 곡선이 포함된 도형을 한꺼번에 그리는 것은 윤곽선만으로 한정이다. PolyDraw라는 함수가 있다.

내부를 채우는 것은 한 함수로 지원되지 않으며, path라는 걸 써야 한다. 얘는 Windows GDI가 제공하는 강력한 벡터 그래픽 라이브러리로, 직선, 베지어 곡선, 원과 원호, 심지어 다른 트루타입 글꼴의 글립까지 몽땅 궤적으로 표현해서 한꺼번에 내부를 채울 수 있다. 구멍 처리도 물론 된다.
BeginPath (그리기) CloseFigure (그리기) EndPath 이런 식으로 말이다. 위의 1과 2를 모두 할 수 있다.

내 경험상 트루타입 폰트는 WINDING 방식으로 래스터라이징을 한다. 글꼴 글립을 그릴 때부터 제일 밖의 path는 시계 방향이고, 그 안의 구멍 윤곽을 기술하는 path는 반시계 방향이고, 구멍 안의 칠하는 영역은 또 시계 방향.. 이런 식으로 디자인을 해야 한다.

허나, 예전에 MS Office 2003 이하 버전에서 제공되던 클래식 WordArt는 이 원칙을 지키지 않고 트루타입 글꼴도 홀짝 ALTERNATE 방식으로.. 짝수 회 overlap 영역은 무조건 비웠던 것 같다.
그래서 composite glyph 형태로 표현되는 비완성형 한글 글꼴에서 글립이 겹칠 수 있는 복잡한 글자를 찍어 보면 저렇게 흰 부위 glitch가 발생하곤 했다. (아래 그림에서 ㅆ, ㅠ, ㅔ 부분 참고)

Office 2007 이상부터 제공되는 WordArt는 이 문제가 해결됐다. 그리고 아래아한글의 글맵시도 0여부 WINDING 방식으로 맞게 색칠을 하기 때문에 glitch가 발생하지 않는다.

그러고 보니.. MS Office는 지난 2007때부터 그래픽 엔진이 크게 바뀌었다. 워드아트의 글자 장식 기능도 리뉴얼 됐고 PowerPoint 같은 데서도 직통으로 사용 가능해졌는데, 정작 본가인 Word에서는 2003 이하의 클래식 워드아트가 제공됐다. 다음 버전인 Office 2010부터 Word에서도 동일하게 리뉴얼된 워드아트가 제공되기 시작했다.

Posted by 사무엘

우리나라 영토는 남북으로 분단되어 있다. 휴전선이라고도 불리는 군사분계선이 중앙에 있고, 거기 곁을 비무장지대와 민간인 통제 구역이 감싸고 있다. 여기 주변은 위험하기 때문에 비행 금지 구역임은 물론, 지리 정보가 민간 지도에 표시되지 않는다. 여기서 민간 지도란, 자동차 내비게이션도 포함하는 개념이다.

전자는 원칙적으로 군인과 민간인 그 누구도 들어갈 수 없고 가끔 GP를 지키는 소수의 군인들만이 경찰처럼 둔갑해서 몰래 들어간다. 그 반면, 후자는 민간인만 출입 금지이다. 거기에 조상 대대로 밭이나 묘소를 소유하고 있던 사람이 농사나 성묘 같은 정당한 볼일이 있을 때만 인근 군부대의 허가를 받고 낮 시간대에 한해 드나들 수 있다.

그럼 전국의 모든 민통선 안(= 민통선 이북)은 밤엔 군인을 제외하면 쥐새끼 한 마리 얼씬거리지 않는 암흑 지대인가 하면, 꼭 그렇지는 않다. 거기에 주민이 상주하는 마을도 있기 때문이다.

그 원조 1호는 판문점에서 제일 가까이 있고 휴전 직후부터 조성됐던 대성동 마을이다. 이 마을은 처음부터 이 근처에 존재했던 마을이며, 6· 25 정전(휴전) 협정에 따라 존재를 인정받고 보장받았다.
여기는 휴전 회담이 진행된 판문점의 근처인 덕분에, 1951년 하반기부터는 전쟁의 포화에 휘말릴 일이 없이 안전하게 지낼 수 있었다. 그 대신 여기는 우리나라가 땅을 수복하지도 못하고 오히려 방어하기 불리한 곳을 포기하게 됐음이 주지의 사실이다. 그래서 해주 반도와 개성 시내를 내어주고 북한이 서울과 더 가까워졌다.

사실 대성동 마을 일대는 민통선과 남방한계선의 구분도 아직 없어서 코앞이 군사분계선이며, 강원도 전방에다 비유하자면 아예 비무장지대 안이나 마찬가지이다. GOP도 아니고 GP가 있을 곳에 민간인 마을이 있다는 뜻이다. 그만치 엄청나게 위험하고 거주민들의 행동과 이동에 제약이 크다.

한때 우리나라 대성동과 건너편 북한의 기정동에서 국기 높이 달기 병림픽(?)을 벌인 적이 있었고, 그게 초등인가 중인가 도덕/윤리의 마지막 단원 북한 통일 문제에서 언급되기도 했다. 나중엔 남한이 그냥 gg 치고 손 떼서 북괴의 160m짜리 깃대가 한동안 세계에서 제일 높은 깃대 기록을 수립하기도 했다는데.. 구체적으로 몇 년대에 벌어진 일인지는 아무리 찾아 봐도 정확한 기록이 나오는 게 없다. 팩트 확인이 잘 안 된다.

나중에는 저기 말고도 통일촌, 해마루촌, 횡산리 등 민통선 안 마을들이 몇 곳 더 조성됐다. 아래 그림을 보시라. (☞ 출처)

이들 민통선 마을은 출입이 까다롭긴 하지만, 대성동만치 군사분계선과 북한이 코앞이고 위험하고 유엔군의 통제를 받을 정도로 수위가 높은 곳은 아니다. 그림에서도 대성동은 다른 마을들과는 성격이 다름을 언급하고 있다.

단적인 예로, 통일촌이나 해마루촌은 파주의 도라 전망대 및 제3 땅굴 임진각 안보 관광 패키지에도 포함돼 있어서 일반인이 비교적 쉽게 찾아갈 수 있다. 그러나 대성동을 아무 연고 없는 일반인이 단순 호기심 차원에서 관광..?? 어림도 없는 일이다. 그쪽의 관광 난이도는 판문점의 관광 난이도와 대등하다.

이런 마을들은 전쟁 때 원주민들이 다 피난 가면서 폐허가 되고, 그 상태로 민통선 구역으로 봉인됐다가 뒤늦게 마을로 재건되었다. 사람을 받아들일 거면, 밭은 몰라도 주택이 있는 곳은 그냥 민통선에서 해제해 주지 싶은 생각도 든다만.. 지형상의 한계나 군사 관리의 편의성 때문에 그리 하지 않은 것 같다.

철원에 이런 마을이 유난히 많은 이유는 저기가 넓은 평야를 낀 천혜의 곡창 지대이기 때문이다. 6 25 때 우리나라가 수복해 냈고 김일성이 빼앗긴 걸 통탄했을 정도인 금싸라기 땅이다. 그 유명한 민통선 안 메기 매운탕 식당인 '전선 휴게소'도 이 지대(정연리-유곡리) 사이에 있다.

그 반면, 철원보다 더 동쪽부터는 산세가 더욱 험해지고 지형이 너무 메롱이 되는 관계로, 민통선 마을 같은 게 없으며 거주민도 없다. 가령, 동쪽 끝의 고성군 수동면 같은 곳은 마을이 산과 휴전선으로 완전히 고립되게 생겼으니 주민들이 모두 이주하게 되었다. 그래서 거기는 주민이 전무하여 사문화된 행정구역으로 전락했다.

그림에 표시된 마을들 중에서 마현1리는 혼자 조성 시기가 1959년인 게 이색적이다. 얘는 바로 그 시기에 나라의 동남부 지방을 깡그리 삭제해 버린 태풍 ‘사라’의 피해 이재민들이 이주해서 개척한 마을이기 때문이다.
어느 지역이냐 하면 부산이 아니라 무려 울진이다. 1963년 이전엔 울진이 경북이 아니라 강원도 소속이었던 관계로, 강원도 도지사가 이재민들에게 이 참에 정부 지원금도 받아서 같은 강원도인 철원으로 이주를 주선했다..;;

그렇게 66세대 359명의 주민들이 군용 트럭 23대를 나눠 타고 저 마을로 가는 데만 3박 4일이 걸렸다고 한다. 그 시절에 울진에서 철원까지 가는 경로에 아스팔트로 잘 포장된 도로 따위는 없었으니까..
그리고 그들은 한동안 군용 텐트에서 살면서 근성으로 황무지를 일궈서 밭을 만들었다. 여기가 한때 격전지였던 관계로 땅 조금 파면 탄피들이 무슨 광물처럼 튀어나왔나 보다. 그걸 주워 팔아서 입에 풀칠을 했다.

그랬는데 이듬해 봄엔 이 승만 정권이 갑자기 무너지면서 마을에 파격적인 지원을 약속했던 강원도 도지사와 철원 군수는 모두 교체됐다. 이 사람들이 마현1리에 정착한 때가 1960년 4월 7일이니 4 19 의거로부터 겨우 두 주 전... 말 다 했다. =_=;;
그리고 기껏 고생해서 밭을 일궈 놨더니 여기에 진짜 원래부터 살았던 원주민이 찾아와서 땅 내놓으라면서 소송을 걸기도 했는데.. 이 때문에 자금이 부족한 입주민은 여기서도 소작농 신세로 전락하기도 했다.

이때 선조들이 얼마나 고생했으면.. 그로부터 30여 년 뒤인 1989년, 마현리 주민의 세대가 바뀔 즈음에 건립된 입주기념비에는 "그대들은 알아야 한다. 조국강산의 가장 중심된 이 농토가 누구의 피땀으로 가꾸어졌는가를…. 괭이와 호미로 6·25 동란 이후 버려진 황무지를 옥토로 가꾼 개척 정신의 빛나는 업적을 우리는 알아야 한다"라는.. 정말 피를 토하는 듯한 비장하고 처절한 문구가 새겨져 있다.

핵심은 대성동 말고도 민통선 안에 자리잡은 민간인 마을이 있다는 것, 그리고 그 중에서도 마현리 주민들은 실제 이곳 출신이 아니며 오히려 진짜 여기 원주민들과 분쟁을 겪었다는 것이다. 이에 대해서 더 관심 있으신 분은 다음과 같은 다양한 기존 보도 자료들을 참고하시기 바란다. (☞ 링크 1, 링크 2, 링크 3, 링크 4)

그리고 요즘은 마현리는 주변의 밭은 몰라도 마을 자체는 민통선 안이 아닌 것 같다. 국도 5호선에서 멀쩡히 진입할 수 있고 마을 내부도 버젓이 로드뷰가 제공되고 있기 때문이다.
그러나 주변의 이길리에 소재한 마을은 민통선 안이다. 72~73년에 조성된 민통선 마을들, 특히 이름이 대놓고 통일촌이라고 지어진 저 마을은 임진각이 건립되면서 같이 만들어진 거라고 생각하면 되겠다.

해마루촌은 시기가 시기인 만큼 김 대중 대통령의 햇볕 정책 내지 경의선 연결과 같은 맥락에서 조성된 실향민 마을이다. 상공에서 보면 마을 도로가 높은음자리표 모양으로 꼬불꼬불하게 만들어져 있는 걸로 유명하다.

끝으로, 철원도 아니고 서쪽 끝도 아닌 중간(연천)에 마을이 딱 하나 있는 게 연천의 횡산리이다. 시기도 혼자 1977년으로 따로 떨어져 있는데.. 얘는 임진강과 군사분계선의 선형이 굉장히 교묘하게 꼬이는 곳에 있어서 뭔가 섬 같은 느낌이 들며, 제2의 대성동처럼 느껴지기도 한다.
여기는 특별한 사연 없이 원래 여기서 살던 사람들이 나중에 민통선 마을이 조성됐다는 소식을 듣고 되돌아온 경우가 대부분이라고 한다. 정확하게는 1977년, 1985년 두 차례에 걸쳐서이다.

이상이다.
대성동 마을의 주민이 납세와 병역의 의무가 면제된다는 건 이제 다들 알려질 대로 알려져 있다.
그런데 나무위키에는 거기뿐만 아니라 저런 다른 민통선 마을 거주민에게도 같은 혜택이 적용된다고 쓰여 있는데.. 실제로 그러한지 법적 근거를 잘 모르겠다.

병역법이나 병역법 시행령 등 관련 법을 아무리 찾아봐도 장애인이나 탈북자가 면제이지, 저 지역 출신에 대한 언급은 딱히 안 나오기 때문이다.
또한, 육지 말고 바다 쪽 민통선도 생각해 봐야 한다. 교동도는 통제가 아주 느슨하긴 하지만 그래도 민통선에 속한 곳이며, 백령도나 연평도 같은 서해5도도 개념적으로 대성동 및 타 민통선 마을에 준하는 특이한 오지이다. 그러니 면제 혜택을 주려면 그쪽과의 형평성도 생각해야 한다.

물론 저 정도로 특이하게 사는 극소수의 사람들한테, 부정 수급의 가능성도 전무한 혜택을 주는 것 자체야 형평성 불만이 제기될 여지가 없다. 다만, 아무리 생각해도 다른 민통선 마을들과 대성동을 완전히 같은 급에 두는 건 좀 아닌 것 같다.

지난 2019년경엔 대성동 마을 토박이인 어느 친자매(유 수빈· 유 정빈)가 대학 졸업 후에 무려 여군 장교를 같이 나란히 지원해서 매스컴을 탔다. (☞ 관련 링크)
남자였어도 합법적으로 군대를 안 갈 수 있는 신분인데 여자가 그것도 언니와 동생 둘 다 군대 쪽으로 진로를 정했다니 매우 특이한 경우가 아닐 수 없다. 어릴 때부터 맨날 군인들을 보고 살았는데 자기도 그런 군인처럼 남을 돕는 사람이 되고 싶다고 포부를 밝혔다..; 세상엔 이런 일도 있었다.

Posted by 사무엘

1. 소멸 위기? 제주어

한 1990년대, 한국어에 대해서 우랄 알타이 어족 기원설이 유효했고 학교에서도 가르쳐지던 시절엔..
"바른말 고운말을 씁시다, 한글을 사랑합시다, 한자어와 외래어보다는 가능한 한 순우리말을 살려 씁시다, 특히 일본식 한자어를 순화합시다" 같은 계몽 운동이 많이 벌어지고 있었다.

이런 운동을 하는 사람들 중에는 아마추어뿐만 아니라 국어학 교수 타이틀까지 거머쥔 전문가도 있었다.
심지어 이때는 "미래(21~22세기)엔 세계 언어들의 90% 이상이 사멸할 것이다. 지금부터 정신을 바짝 차리지 않으면 한국어도 외국어에게 잠식 당해 사멸할지 모른다"라고.. 거의

• 정신을 바짝 차리지 않으면 북괴가 다시 남침해서 적화통일 될지 모른다,
  
• 일본에게 나라를 다시 빼앗길지 모른다
• 지금 이 상태로 문화건 농산물이건 영화건 공산품이건 시장을 확 개방했다간 다 빼앗기고 내수 시장은 망할 것이다
  
• 한국은 UN이 지정한 물 부족 국가이다. (...!!)

이런 급의 괴담이 언어 분야에서도 나돌기도 했다.
지금은 교통· 통신의 발달과 함께 영어가 그야말로 넘사벽 급의 세계 공용어가 됐으며, 반대급부로 소수 민족 언어들이 야금야금 사멸하고 있는 건 사실이다.

언어 순수주의에 입각한 계몽 운동에 대해 이해 못 하는 바는 아니다. 언어의 어휘와 문법 구조는 이미 사람의 생각과 정신 세계에 끼치는 영향이 결코 작지 않다. 문법 차원에서 단· 복수를 엄격하게 구분하는 언어, 성별 구분이 있는 언어, 높임법이 존재하는 언어.. 이런 것 말이다.

그러니 말과 글과 얼이 하나라는 말까지 나왔으며, 멀쩡한 자국어 어휘가 외국어에게 잠식 당하는 게 마치 자국 정신 세계의 영토를 침략자에게 빼앗기는 것과 비슷한 급의 위기라고 생각하는 것이다. 더구나 20세기 초중반 우리나라의 너무 처절하고 비극적이었던 역사에 대한 트라우마가 이런 식으로 투영되어 들어가기도 했다.

하지만.. 지금은 100여 년 전처럼 식민지 제국주의 군국주의가 횡행하는 시기가 전혀 아니며, 더구나 우리나라는 세계 10위 안팎의 국력과 지위를 자랑하는 상위권 선진국이다.
극심한 저출산 때문에 미래가 걱정되긴 하지만 지금 대한민국의 인구가 소수 민족 수준인 것도 아니며, 한류다 뭐다 하면서 오히려 한국어를 배우는 외국인도 있다.

그러니 한국어는 듣보잡 소수 민족 언어와는 처지가 다르다. 예측 가능한 짧은 미래에 사멸을 걱정해야 할 처지인 언어는 절대 아니다.
또한 고유어나 외래어, 언어 순수주의에 대해서는 본인은 공감하는 것도 있고, 별 영양가 없으니 그 정도로 민감하게 반응할 필요는 없다고 선을 긋는 사항도 있다.

사실, 멀쩡히 잘 쓰이던 고유어가 외래어에 먹힌다기보다는 애초에 고유어에 전혀 존재하지 않던 새로운 개념 내지 변별이 안 되는 개념 때문에 외래어가 쓰이는 것이 훨씬 더 많다. 내가 좋아하는 분야의 예를 좀 들자면 로켓이나 제트 엔진 같은 건 도대체 무슨 수로 순화할 생각인가?

정말 순우리말을 살려 쓰고 싶으면 멀쩡히 잘 알아들을 수 있는 컴퓨터, 인터넷 이런 말을 셈틀, 누리그물 따위로 바꾸는 것보다.. '장'이 너무 답답하고 변별력이 떨어져서 페이지/챕터라고 바뀌는 것부터 막는 게 '훨씬' 더 시급하다! 이건 뭔 한자 따위 동원한다고 해결 가능한 문제가 아니다.

너무 까다롭고 거추장스러운 호칭과 격식을 파괴하기 위해서 '너님', 심지어 극단적으로 '유님'(you)이라는 말이 생겨서 아무나 간편하게 가리키는 중립적인 2인칭 대명사로 통용된다면.. 그건 오히려 바람직한 현상이다. 이에 대해 누가 국어 파괴니 깐죽거리며 감 놔라 배 놔라 오지랖 부릴 수 없다.

글쎄, 그런 것 말고 붉은피톨· 말본 셈본· 넘보랏살 같은 순우리말 용어를 괜히 천하고 경박스럽다고 생각하고 한자어· 영어 용어만 자연스럽게 받아들이는 것 자체가 나조차 이미 의식 세계가 외국어 외세에 침략(?)을 당하고 세뇌 당하고 더럽혀진 결과인 건지는 모르겠다.
하지만 이런 침략을 당한 덕분에 초록(green)과 파랑(blue)을 언어적으로 구분할 수 있게 됐다면 그건 꼭 나쁜 침략만은 아닐 것 같기도 하다. =_=;;;;

본인은 이 주제에 대해서 저런 것 말고도 오랜 지론과 할 말이 많이 있다. 하지만 시간과 지면의 부족으로 인해 이 자리에서 더 자세히 다루지 않겠다.
그리고 이런 단어 수준이 아니라 언어 정체성 레벨에서 정말로 사멸을 걱정해야 하는 대상은 한국어 자체가 아니라 한국어의 방언 중 하나인 '제주어'인 것 같다.

저런 게 있다는 것, 정확하게 표기하기 위해서 아래아가 쓰인다는 것 정도는 어렴풋이 들어서 알고 있었다. 그런데 제대로 구사하는 걸 들어 보니 이 정도로 이질감이 큰 방언인지는 몰랐다. 차이가 더 벌어졌으면 북경어 vs 광동어 정도로 벌어졌을 수도 있을 것 같은데.. (☞ 푸른거탑 제주어 버전;)

천상천하 유아독존 고립어인 줄로만 알았던 한국어에도 이 정도로 편차가 큰 지역 바리에이션이 있었다니~! 이건 고대/중세 국어의 모습은 어땠을지에 대한 통찰도 제공할 수 있겠다.

예전에(2000년대쯤..) 제주어를 제대로 채록하기 위해서는 컴퓨터에서 아래아를 입력할 수 있는 한글 입력기가 있어야 한다고 '김 익두'라는 분이 인터넷 상으로 활동을 많이 하셨다. 본인에게도 문의를 하신 적이 있었던 걸로 기억하는데 지금은 먼 과거의 일이 되었다. 그분이 지금은 뭘 하고 계시나 모르겠다.

2. 질적 저하? 사이소리

영어에 2음절 이상의 단어마다 악센트라는 게 있다면, 한국어에는 사이소리라는 아주 아주 기괴한 초분절요소가 존재한다.
이건 높임법만큼이나 한국어의 맞춤법과 발음법, 학습 난이도를 크게 끌어올리는 주범이다. 전에도 몇 번 언급한 적이 있지만..

• 성과는 성꽈이고 결과는 왜 결과인지..?
  
• 물고기는 물꼬기인데 불고기는 왜 불고기인지?
  
• 비빔밥은 비빔빱인데 볶음밥은 왜 그대로 보끔밥인지?

이건 아주 작은 예일 뿐이다. 정말 도무지 원칙이 없고 답이 없다.
더 골때리는 예를 들자면.. 0, 1, 부터 9(영, 일, ..., 구)까지의 숫자 뒤에 '단, 단계, 반, 점' 같은 단위 접사를 붙여 보자. 6이야 받침이 ㄱ이니까 언제나 된소리화가 발생하겠지만 나머지 숫자들은 도대체 언제 사이소리가 들어갈까?

내 언어 직관에 따르면 ㄹ 받침인 1, 7, 8은 언제나 '딴계, 쩜'으로 바뀐다. 하지만 교실을 나타내는 '반'은 사이소리가 전혀 들어가지 않는다. 도대체 왜? 이러니 한국어를 공부하는 외국인 학습자가 뒷목 잡지 않을 수 없다.
물론 사이소리 정도는 꼬박꼬박 정확하게 넣지 않아도 의사소통에 큰 지장은 없다. 하지만 원어민 화자가 듣기에는 충분히 어색함과 이질감과 부자연스러움을 느끼게 된다.

그런데 과거에는 이렇게 사이소리가 불필요하게(?) 들어가서 된소리가 발생하고 어감이 강해지는 걸 아주 부정적으로 보고 경계하는 시각이 지배적이었던 것 같다. 그러지 말아야 한다고, 국어 교육 제대로 다시 시켜야 된다는 의견이 이미 1970년대에부터 신문에 실리곤 했다. 관심 있으신 분은 네이버 뉴스 라이브러리에서 '된소리'라고 쳐서 검색 한번 해 보시라~~

라떼는 말이야 ‘간단하게’도 그냥 평범하게 ‘간단하게’라고 부드럽게 발음했는데 사람들이 어느 샌가 ‘간딴하게’라고 무슨 북괴가 ‘원수’를 ‘원쑤’라고 발음하는 걸 닮아 가고 있다고.. 이런 걸 방치하면 사람들 정서가 망가지고 심성이 병들고 가정이 무너지고 사회가 무너질 수 있다는 식이다.
저게 도대체 뭔 소리인가 싶지만, 저 때는 선풍기 괴담이나 일제 쇠말뚝 괴담 따위가 진지하게 받아들여지고 있었고, 저질 불량 만화 화형식도 하던 시절이었다.;;; 언어에 대해서도 이 정도의 순수주의로 접근하는 분위기가 주류이긴 했을 것 같다.

바로 이런 생각을 하는 사람들이 방송 같은 데서 반드시 강조하는 게 뭐냐 하면 ‘효과’, ‘김밥’도 절대로 ‘효꽈’, ‘김빱’이라고 둘째 음절을 경음화하지 말라는 것이다. 실제로 이 단어들은 표준 국어 대사전에 발음이 경음화하지 않는 게 맞다고 기재되어 있다. 그리고 방송 기자라는 사람들이 그 업계 입사를 위해서 KBS 한국어 시험 같은 건 머리 싸매고 준비했을 테고..

하지만 개인적으로 저건 굉장히 어색하고 비현실적이고 부자연스럽게 들린다. 본인은 억지스러운 경음화 금지에 반대 소신이다.
‘짜장면’을 자장가 발음하듯이 억지로 자장면~~ 이러고, 영어에서 speak를 ‘스삐이크’ 대신 ‘스피이크’ 이러는 것과 비슷하게 들린다.

마치 다르다/틀리다처럼 뭔가 합리적이고 예측 가능한 구분 원칙이 존재해서 그걸 근거로 이때는 경음화하지 말라고 한다면 따르겠는데..
앞서 얘기했듯이 한국어의 사이소리라는 건 그 어떤 날고 기는 국어학자도 규칙으로 예측과 통제를 해내지 못한 난감한 물건이다. 수학에다 비유하면 거의 '소수(솟수??)의 생성 규칙'만큼이나 말이다!!

어차피 아무렇게나 임의로 정하기 나름이고 익숙해지기 나름일 뿐인 사항이라면 그건 그냥 시장에게 맡기고 자유방임을 허용해야 한다. 인위적이고 부자연스러운 언어 갑질 꼰대질에 난 공감할 수 없다.
심지어 반대 사례도 있다. 나는 ‘교통 체증’도 글자 그대로 ‘체증’이라고 오랫동안 발음해 왔지, 표준 발음이 반대로 ‘체쯩’인 것은 최근에야 알게 됐다. 병을 나타내는 ‘증’과 증명서를 나타내는 ‘증’에서 둘 중 하나는 경음화가 발생하는 건지는 잘 모르겠다. (영수증? 영수쯩?)

사이소리가 참 더럽고 구리게 형성되어 있긴 하지만, 이런 것들이 몽땅 다 ‘원쑤’ 같은 부정적이고 잘못된 현상은 절대 아니다. 대부분의 경우, 사이소리는 형태소 경계(파생어 접사와 어근!!)를 구분하고, 한자 동음이의어를 구분하고, 보통명사와 일반명사를 구분하려는 사람들의 매우 복잡미묘한 심리가 반영되어 들어간다.

한자어에서 사이소리를 최대한 표기하지 않는 쪽으로 찍어누르면서 맞춤법을 정했지만, ‘초점’(focus)의 발음은 지구가 멸망하는 일이 있어도 ‘초쩜’이지 ‘초점’이 될 수 없을 것이다.
‘소수’의 경우도 마찬가지다. 소수점이랑 적은 수는 일말의 유사점이라도 있지만 prime number는 정말 아무 관계 없는 의미인데 표기를 저 따위로 해 놓으면.. 정말 답이 없다. 한자 아니면 영단어로 가야지..

이렇게 애초에 사이소리라는 게 한국어에서 없어질 수 없는 요소일진대, ‘효과’를 결과가 아닌 성과처럼 보고 ‘꽈’라고 주류 발음이 바뀌는 것은 그냥 취향의 변화일 뿐이다. 옳고 그름이라는 가치 판단의 대상이 아니라고 본다.
미래에는 하나님의 발음조차도 '하난님'으로 바뀔 수 있다. 사이소리라는 게 꼭 된소리화만을 의미하는 게 아니다. 개인적으로는 이렇게 rule 기반으로 기술할 수 없는 사이소리야말로 다량의 데이터를 기반으로 패턴을 연구할 필요가 생각한다.

성우 겸 배우 이 종구 씨는(1950년생) “오글거리게 효과효과 그러지 말고 평소대로 소신껏 효꽈라고 발음합시다”라고 이미 옛날부터 글 쓰고 홍보를 많이 해 온 걸로 유명하다. 이분 역시 우리말의 올바른 표현과 표준 발음 쪽으로 관심 많고 소신을 갖추신 분이다.

그런데 ‘간단하다’는 ‘간’과 ‘단’을 쪼개서 생각할 여지가 없고, 비슷한 형태의 다른 단어들을 생각해 봐도 정말로 굳이 ‘간딴’이라고 발음할 필요가 없어 보이긴 한다. 그런데 왜 어쩌다가 경음화된 발음이 주류가 돼 버렸나 모르겠다. 옛날에 처음부터 그러지는 않았는데 진짜로 일제 말기와 6 25를 겪으면서 사람들 심성이 피폐해져서 ‘간딴’으로 바뀐 걸까..??? 이건 정말 의문이라 하겠다.

Posted by 사무엘

날개셋 한글 입력기의 다음 버전은 6월 언젠가 정도로 계획하고 있다.
획기적인 새 기능까지는 아니지만 지금까지 자잘하게 개선된 사항들, 그리고 새 버전 정식 공개 전에 미리 알릴 필요가 있는 변화 사항들을 나열하면 다음과 같다.

1. 크롬 브라우저 버그가 이제 크롬 쪽에서 해결된 듯

오~ 크롬 브라우저--요즘은 같은 엔진 기반인 Edge도 포함해서--가 어째 정신을 차렸는지..
지난 4월 하순쯤의 버전 90대 최신 업데이트를 받고 나니, 한글 조합 중에 딴 데를 클릭했을 때 자기 혼자 조합이 덧나는 등의 잡다한 오동작이 싹 없어졌다.
그래서 이제는 내 입력기에서 기본적으로 제공하던 보정 옵션은 "반대로 꺼 줘야" 조합이 사라지는 오동작이 발생하지 않겠다.

지난 9.x 대 후반부터 거의 2년 동안 크롬과 내 입력기와의 악연이 계속돼 왔다.
물론 내 입력기도 마소 기본 IME하고는 다르게 동작하는 게 있긴 했겠지만.. 그래도 내 입력기에 대해서도 지금까지 그렇게 동작한 특이한 프로그램은 역사상 크롬(크로뮴 엔진)밖에 없었다.

IME/TSF 담당 개발자가 수시로 교체되기라도 했는지.. 크롬은 혼자서 여기저기서 갖~가지 자잘하고 기괴한 오동작들을 일으키면서 날 귀찮게 해 왔다.
한때는(1년 전쯤 버전??) 누가 언제 소스의 어디를 건드렸는지, 메트로 앱이 아닌데도 메트로 앱이라고 IME에게 거짓 보고를 하기도 하고, TSF를 제대로 지원하지 않는데 지원한다고 거짓 보고까지 했었다. (지금은 다 고쳐짐)

그럼에도 불구하고 크롬은 날개셋과는 비교가 되지 않는, 그야말로 전세계 전지구 넘사벽급 메이저 프로그램이라는 게 문제.. 내 프로그램이 수동 보정으로 크롬의 동작에 맞춰 주는 수밖에 없었다.
그랬는데 드디어 크롬 쪽에서 문제를 해결한 것으로 보인다.

심지어는 지난 3~4월 사이엔 한글 조합을 종료하면 이전에 입력했던 글자들이 쭈루룩 삽입되는 오동작도 가끔 발생한다고 본인에게 버그 신고를 하신 분이 있었다.
이걸 본인도 잠깐 확인하긴 했다. 하지만 정확한 재연 경로를 파악하지 못했으며, 특히 업데이트를 받은 뒤부터는 그 문제를 다시는 재연하지 못하고 있다. 그래서 이건 일단 '공소권 없음'으로 사건을 내사 종결하고자 한다. 혹시 크롬 최신 버전 + 날개셋 10.2에서 저 문제를 또 재연 가능하신 분은 알려 주시면 좋겠다.

이로써.. 혼자서 독보적인 수동 보정 옵션을 필요로 하는 특이한 프로그램의 끝판왕으로는 사실상 Windows Terminal밖에 남지 않았다. 얘는 버전업도 하지 않는지, 오동작 현상을 처음으로 확인했던 1년 전이나 지금이나 변함없다.

수동 보정 옵션이 갈수록 내용이 적어지고 궁극적으로는 필요 없어지는 날이 왔으면 좋겠다.
그럼에도 불구하고 이번 버전에서는 수동 보정 UI를 이렇게 쇄신했다. 증상, 조건, 주 적용 대상을 일목요연하게 나열하고, 보정 대상인 이상 동작을 심지어 움짤로도 표시하게 했다.

2. 확대 배율(DPI)이 서로 다르게 지정된 다중 모니터 환경에 대한 지원

결론부터 말하자면.. 날개셋 외부 모듈에서 제어판을 꺼냈는데 이 창을 DPI가 다르게 설정된 모니터로 옮겼을 때 각종 컨트롤들 배치가 엉망이 되는 문제를 "일단은" 해결했다. 알고 보니 이건 Windows 10의 대략 2017~18년도 버전 때부터 존재해 온 문제였다.

옛날에 컴퓨터 모니터의 해상도가 낮던 시절에는 확대 배율이라는 건 거의 건드릴 일이 없었으며, 그냥 시각 장애인을 위한 잉여 옵션에 지나지 않았다. 이걸 바꾸려면 운영체제 재부팅/재로그인도 해야 했다.
그랬는데 2000년대 이후로는 이게 재부팅 없이 간편하게 설정 가능한 옵션으로 바뀌었으며, 심지어 모니터별로 서로 다르게 지정도 할 수 있게 됐다. 응용 프로그램에 요구되는 준비 수준도 점점 더 높아졌다.

• (1) 가변 DPI 자체를 지원할 것: 이를 지원하지 않는 프로그램은 100% 외의 배율에서는 창 크기가 기계적으로 확대되어 뿌연 저화질로 표시된다.
  
• (2) 프로그램 실행 중에 DPI 설정이 바뀌는 것을 유동적으로 지원할 것: 이를 지원하지 않으면 DPI 설정 변경 뒤부터는 역시 보정 샌드박스가 발동되어 뿌연 저화질크리.
  
• (3) 이 모니터에 있던 창을 저 창으로 옮김으로써 DPI 설정이 바뀌는 것을 유동적으로 지원할 것(창 크기 변경까지 포함!!). 아예 한 프로그램 안에서 윈도우별로 DPI 설정을 따로 관리할 것.

그런데 날개셋 한글 입력기는 주요 UI에서 16 아니면 24픽셀로 크기가 고정된 비트맵 글꼴을 사용한다. 둘 중 하나를 고른 뒤에는 다른 걸로 변경이 전혀 불가능은 아니지만 좀 난감한 형태이다.

그리고 이것보다 더 큰 문제로.. 날개셋 제어판은 창 크기를 사용자가 유동적으로 조절 가능하며 대화상자 안에 또 대화상자가 들어있는 꽤 복잡 정교한 물건이다. 다른 프로그램들은 도대체 어떻게 동작하는지 모르겠지만, 이런 데서 화면 DPI가 바뀔 때마다 내부적인 수치 계산을 정확하게 다시 해 주는 것, 그리고 운영체제가 대화상자에 대해서 내부 컨트롤들을 바뀐 크기와 위치대로 재배치하는 것이 영 정확하게 연계해서 동작하지 않았다.

이 두 가지 난관 때문에 날개셋 편집기 등의 프로그램들은 가변 DPI를 어쩔 수 없이 최소한의 기본인 (1) 수준만 지원하고 있다.
허나, 날개셋 외부 모듈은 메모장, 크롬 등 가변 DPI를 (3) 수준까지 다 지원하는 프로그램에서도 동작해야 하는데.. 대화상자 창 크기가 바뀌었을 때 자체적으로 컨트롤을 재배치하는 기능과 운영체제가 DPI 변화로 인해 컨트롤을 재배치하는 기능이 충돌해서 정말 굉장히 이상한 오동작이 발생하고 있었다.

둘을 조화를 이루는 방법을 아직까지는 못 찾았다. 그냥 운영체제의 기능을 꺼 버리고, 어느 모니터에서나 가변 DPI를 고려하지 않고 동일한 픽셀 크기로 대화상자가 표시되게 함으로써 오동작을 회피했다. (3)은 이제 어떤 경우에도 뿌연 저화질 대화상자가 표시되지 않는 모드이기 때문에 이것 말고 다른 선택의 여지가 없다.

3. 나머지 자잘한 개선 사항

(1) 날개셋 한글 입력기에는 "지정된 데이터에 들어있는 한글"만 입력 가능하게 하는 제약 기능이 있는데.. 그 데이터는 후보 변환 데이터와 마찬가지로 직접 입력해서 내장시킬 수도 있고, 외부의 텍스트 파일을 지정할 수도 있다.
그런데, 텍스트 파일을 지정하고 나면 그 파일의 내용도 설정 대화상자에서 곧장 표시되어서 확인 가능하게 했다. 아래 스크린샷을 참고할 것.

(2) "부수로 한자 입력" 도구가 호환용 한자는 크기를 약간 줄여서 표시하게 했다. 호환용 한자는 대부분 검정색 상용 한자에 있지만, 아주 드물게 그렇지 않은 것도 있다.
그리고 특정 부수에 속하는 한자들이 모두 표시된 경우, BMP 한자 한정으로 이 한자가 부수를 제외한 획수가 몇 획인지도 툴팁에 같이 나오게 했다.

(3) 제어판의 시스템 계층에 있는 "... 자동으로 띄울 입력 도구" 목록은 체크를 하다 보면 선택 막대가 자꾸 진하게 덧칠되는 문제가 있었다. 이건 엄밀히 말하면 오로지 Windows 10만의 버그이다. 그 전의 XP, 7, 8.1 등 그 어떤 버전에서도 이런 현상이 없었다.

그랬는데.. Windows 10에서도 이 현상을 회피하는 방법을 우여곡절 끝에 찾아내서 그걸 내 프로그램에다가 적용했다.
허나.. 그 방법은 이젠 공용 컨트롤 6이 적용되지 않은 옛날 레거시 프로그램에서는 또 다른 화면 잔상 부작용을 일으키는지라, -_-;; 이건 조건부로 제한적으로 적용해야 했다. 살다 살다 이런 지저분한 버그는 참 오랜만에 다시 본다. -_-

(4) 날개셋 편집기에서 따옴표(") 다음에 한 줄의 길이보다 더 긴 영어 알파벳을 늘어놓으면.. 단어 전체가 다음 줄로 밀려나고 원래 줄에는 따옴표 하나만 달랑 남던..-_- 이상한 문단 정렬 방식을 개선했다.
15년도 더 전, 2.x, 3.x 버전 시절부터 이렇게 동작했던 것을 바로잡았다.

Posted by 사무엘

1. 함수 명칭만으로 오버로딩 분간하기

C++에는 그 이름도 유명한 함수 오버로딩이라는 게 존재하기 때문에 어떤 함수를 이름만으로 유일하게 식별할 수 없다. 링크를 위한 심벌을 생성할 때는 자신이 받아들이는 인자들의 개수와 타입도 이름에다가 일일이 곁들여 줘야 동명이인(?) 함수들을 구분할 수 있다. 이 절차를 decoration이라고 한다.

그런데 바이너리 차원에서 함수 이름에 대한 구체적인 decoration 방식은 표준으로 정해진 것이 없어서 컴파일러마다 완전히 제각각이다. 이 때문에 동일한 타겟에다 동일한 포맷의 obj/lib(기껏해야 OMF 아니면 COFF..)라도 C++ 클래스 라이브러리는 컴파일러를 넘나드는 이식성이 크게 떨어진다.

C 단독이 거의 쓰이지 않는 오늘날까지도 유명 라이브러리들이 C언어 형태의 단순한 인터페이스를 고집하는 이유 중의 하나가 바로 이것이다. 아니면 그런 C 함수를 아주 얇게 감싸는(생성자, 소멸자, 오버로딩..) C++ wrapper 클래스를 만들더라도 하는 일이 정말 C 함수 호출밖에 없고, C++ 멤버 함수는 몽땅 인라이닝이 되게 만든다. 인라이닝이 됐다면 decoration이고 뭐고 걱정할 필요가 전혀 없어지기 때문이다.

그런데.. C++에서 함수를 (1) 실제로 호출하지 않고, (2) 저렇게 decoration 정보가 있는 link time도 아니면서 소스 코드 차원에서(= compile time) 오버로딩 동명이인 함수를 구분할 수는 없을까?

엥? (1)도 (2)도 아닌 애매한 상황은 C++에서 한동안 고려할 필요가 없었다. 그러나 2010년대부터 modern C++이 등장하고, 명칭만으로 type을 유추할 수 있는 auto와 decltype 키워드가 도입되면서 발생할 수 있게 됐다.

void foo() {}

라는 함수를 정의해 놓았다면

auto ptr = &foo;
decltype(&foo) ptr = ...;

이런 식으로 foo를 얼마든지 써먹을 수 있다. auto와 decltype이 자동으로 void (*)()이라는 타입을 유추해 내기 때문이다. 그런데 문제는..

void foo(int) {}

같은 overload를 더 만들었을 때이다.
그러면 이때부터 auto와 decltype에다가 foo를 언급할 수 없게 된다. 이 이름이 가리키는 함수의 prototype이 하나로 딱 떨어지지 않기 때문이다.

이에 대해 C++ 표준 스펙은 오버로딩된 함수 이름을 저기에다 집어넣는 것은 ill-formed라고만 지적하고 넘어간다. (☞ 링크)
이건 컴파일된 obj가 아니라 소스 코드 레벨이기 때문에 decorate된 저수준 명칭을 사용할 수도 없다. 어느 오버로드인지를 지목하는 문법은 딱히 마련하지 않고 넘어간 듯하다.

글쎄, 생각 같아서는 foo as_in () 내지 foo as_in (int) 같은 오버로딩 식별을 위한 토큰이 필요해 보인다.
파이썬이라면 모를까 C++에서 겨우 이런 용도를 위해 영단어 예약어를 도입하는 건 보기 좋지 않다. 그냥 foo 다음에 -> : []처럼.. 데이터 포인터가 아닌 함수 포인터라면 쓰일 일이 없는 기존 연산자 토큰을 늘어놓아서 이 함수의 인자들의 타입을 기술해 주면 될 것이다.

참고로, 함수의 포인터를 얻는 상황에서는 static_cast가 아주 유용하게 쓰인다.
void *p = static_cast<int (*)(int,int)>( func_ptr );

이렇게 해 주면 이 형변환은 func_ptr이 int 2개를 받고 int를 리턴하는 놈이 실제로 선언이나 정의돼 있을 때에만 성공한다. 그런 게 없으면 에러.. 그러니 안전하다. 흥미롭지 않은가? 형변환 연산자가 함수의 동명 오버로드를 분간할 때도 쓰인다니 말이다.
C-style cast나 reinterpret_cast는 그런 면모가 없고 무조건 될 것이다.

2. 복합 포인터 간의 더 세밀한 형변환 연산자

C/C++에서 void*라는 포인터 타입은 잘 알다시피 다른 아무 자료형을 가리키는 포인터를 받아서 대입될 수 있다. 공집합은 다른 모든 집합들의 부분집합이며, 1은 다른 모든 자연수의 약수인 것과 같은 이치이다.
malloc을 비롯해 메모리를 할당하는 함수들은 특정 자료형에 구애받지 않는 void*를 되돌린다. 그런데 이 포인터값을 함수의 리턴값이 아니라 함수 인자로 전달된 포인터가 가리키는 주소에다 받게 하려면 어떡해야 할까?

그럴 때는 별 수 없이 이중 포인터가 쓰이게 된다. 자주 보는 물건은 아니지만 Windows에서 COM 객체를 다루다 보면 QueryInterface 메소드, CoCreateInstance 함수 때문에 접하게 된다. COM에서는 함수 리턴값은 에러코드(정수값)를 되돌리고, 포인터는 인자로 전달된 주소를 통해 받기 때문이다.

여기서 우리는 문법 차원에서 약간의 어색함을 경험하게 된다.
void*는 int*, char* 등 다른 포인터 타입과 호환되지만 이중 포인터끼리는 그렇지 않다. 가령, void**와 int**, char** 따위는 호환되지 않는다.
상속 관계도 마찬가지이다. IUnknown**에다가 IUnknown의 파생 클래스의 포인터의 주소를 바로 넘겨줄 수는 없다.

단순 포인터는 한쪽은 호환되고, 역변환은 static_cast만 해 주면 된다. 그러나 이중 이상의 포인터는 가리키는 타입도 타입 그 자체가 아니라 그 타입의 포인터이다. 그렇다 보니 타입간의 아무런 계층 관계가 인정되지 않는다. 어느 방향으로든 얄짤없이 무식하게 reinterpret_cast만 써야 한다.

글쎄, 이런 일이 자주 발생하고 구분해 줄 필요가 꼭 있다면 pointer_cast 내지 reference_cast라고 해서.. 다중 포인터라도 참조 깊이가 동일하고 최종적으로 도달하는 타입이 서로 static_cast급으로 호환된다면 변환을 허용하는 형변환 연산자를 둘 법도 해 보인다. 저건 굳이 reinterpret_cast까지 사용해야 할 정도로 과격하고 위험해 보이지는 않기 때문이다.

하지만 저 상황만을 위해서 별도의 키워드까지 추가하는 건 좀 overkill 낭비로 보이니 그렇게 되지 않은 것 같다. 배열이야 필요에 따라 3차원 이상의 다차원 배열이 쓰일 수 있지만, 포인터는 본인도 20여 년에 달하는 프로그래밍 인생 이래로 3중 이상 깊이의 포인터를 사용할 일은 전혀 없었다. 즉, void ***p라든가, 이중 포인터에 대한 주소값 같은 것 말이다.

포인터라는 게 크게.. (1) 타 자료형에 대한 포인터, (2) 함수에 대한 포인터, (3) 구조체 및 클래스의 멤버에 대한 포인터라는 세 갈래로 나뉘는 것 같다. 물론, (1)~(3) 종류 불문하고 포인터를 가리키는 포인터는 자동으로 (1)에 속하게 된다. (2)와 (3)은 void*로 싸잡아 일컫는 것이 권장되지 않거나 원천적으로 가능하지 않다.

멤버 포인터의 포인터 내지 배열 같은 것은.. 잠깐 테스트를 해 보니 그래도 문법적인 한계나 typedef 땜빵 없이 이렇게 바로 선언해서 쓸 수 있긴 하다. 물론 멤버 포인터 자체도  쓰일 일이 극도로 드문데 하물며 그걸 또 가리키는 포인터는.. 삼중 이상의 포인터만큼이나 정말 레어템이다. 아래처럼 말이다.

class A {
public:
    void func(int x);
};

void (A::*pfn)(int) = &A::func;
void (A::**ppfn)(int) = &pfn;
void (A::*apfn[1])(int) = { &A::func };

A obj;
(obj.*pfn)(1);
(obj.**ppfn)(2);
(obj.*apfn[0])(3);

복잡한 포인터에서 세부 속성 간의 형변환은 비단 다중 포인터에만 존재하는 게 아니다. 함수 포인터에다가 인자의 개수와 calling convention 같은 건 완전히 일치하고, 일부 인자나 리턴값만이 void*와 char*처럼 미묘하게 다른 함수를 집어넣는 상황을 생각해 보자. 일반 함수뿐만 아니라 C++ 멤버 함수의 포인터도 해당된다.

이때도 지금 문법에서는 닥치고 C-style 또는 reinterpret_cast를 쓰는 수밖에 없다. 하지만 static_cast와 reinter_*의 중간 완충 역할을 해서 저럴 때만 유도리를 허용하는 연산자가 있다면 문법 차원에서 실수가 더 줄어들 수 있고 더 깔끔한 코드를 작성할 수 있다. 프로그래밍 언어에서 type theory의 심오함이 문득 느껴진다.

3. 복수 인터페이스의 구현체에서 IUnknown 베이스 얻기

C++로 COM 인터페이스를 지원하는 클래스를 구현하다 보면.. 다중 상속 기능을 이용하여 한 클래스에다가 2개 이상의 인터페이스를 한꺼번에 집어넣는 경우가 있다.
예를 들어 한 윈도우가 drag & drop을 양방향으로 지원해서 데이터를 밖으로 날릴 수도 있고 받을 수도 있다면, 그 윈도우를 나타내는 클래스(가령, CMyWnd)에다가 IDataObject, IDropSource와 IDropTarget를 몽땅 때려박는 게 편하다.

이렇게 하고 나면, 그 CMyWnd를 상대로 인터페이스들의 베이스인 IUnknown의 QueryInterface, AddRef, Release 메소드를 호출하는 것이야 아무 문제 없이 된다.
다중 상속의 특성상, CMyWnd를 IDataObject, IDropSource, IDropTarget 등으로 캐스트한 포인터 값은 제각각 달라질 수 있다. 왜냐하면 멤버 변수가 없는 인터페이스이더라도 상속을 하나 할 때마다 vtable 포인터의 크기 하나씩은 클래스에다가 차지하게 되기 때문이다.

하지만 이들의 vtable에서 IUnknown 파트는 모두 공통으로 CMyWnd가 구현한 동일한 QueryInterface, AddRef, Release 함수를 가리키게 된다. 이게 바로 마법의 비결이다.
단, 둘째, 셋째, n째 인터페이스들은 this 포인터 값을 살짝 보정한 뒤에 원래 함수를 호출하는 thunk가 추가된다. 마법이 공짜는 아닌 셈이다. 그래서 다중 상속에서는 내가 함수를 호출한 객체의 주소와, 해당 멤버 함수가 받은 this 포인터의 값이 일치하지 않을 수 있다.

그렇게 다중 상속에서 함수 호출과 this 보정 문제가 해결되었는데.. 정작 CMyWnd 오브젝트의 포인터를 IUnknown* 자체로 cast 하는 것은..??? 뜻밖에도 되지 않고 컴파일 에러가 난다. 암시적 자동 형변환은 물론이고, static_cast와 C-style cast도 통하지 않는다.
왜냐하면 얘는 2개 이상 여러 인터페이스를 구현했는데 어느 놈을 기준으로 삼아서 IUnknown으로 cast 해야 할지 알 수 없기 때문이다. 모호성이 존재한다는 것이다. 뜨악~

현실에서 어지간해서는 이런 일을 겪을 일이 거의 없다. 그냥 파생 클래스 구현체가 베이스 인터페이스의 완벽한 상위 호환이니, 어지간한 상황에서는 그냥 그 클래스를 쓰면 되지 굳이 베이스로 형변환을 할 일 자체가 없기 때문이다.

하지만 아무 인터페이스 오브젝트나 받아들여서 레퍼런스 카운트 관리만 한답시고 IUnknown을 인자로 받는 함수가 드물게 있을 수 있다. 그 함수에다가 이런 오브젝트를 덥석 넘겨주면 어느 베이스의 IUnknown을 골라야 할지 모르겠다는 태클에 걸린다. 저 인터페이스들이 IUnknown을 가상(virtual) 상속을 한 게 아니기 때문에 이 문제를 피해 갈 수 없다. 어차피 인터페이스에는 데이터 멤버도 없으니 아무거나 골라도 됨에도 불구하고 말이다.

그 클래스가 상속한 베이스들 중 가상 함수가 존재하는 제일 첫 놈이 IUnknown 기반의 인터페이스라면.. 그 클래스의 인스턴스의 포인터는 그대로 직통으로 IUnknown으로 형변환해도 된다. 하지만 이건 이게 C++의 문법 차원에서 안전이 보장될 수 없는 동작이기 때문에 컴파일 에러가 발생하는 것이다.

C-style cast는 static_*과 reinterpret_*의 중간 정도 위상을 차지하는 물건이며, 포인터 간의 형변환에서는 오히려 후자에 더 가까운 위치에 있다. 하지만 다중 상속에 대해서는 의외로 선 넘지 않는 안전 장치가 걸려 있는가 보다.
저 때 자기 자신을 베이스인 IUnknown으로 강제로 둔갑시키는 수단은 reinterpret_cast밖에 없다.
아니면!! 자신을 void*로 먼저 전환한 뒤에 그걸 IUnknown으로.. static_cast를 두 번 적용하면 된다. 물론 이것들은 다 at your own risk를 감수하고 해야 한다.

이 문제를 해결한답시고 CMyWnd에 대해서 무식하게 QueryInteface(IID_IUnknown, &obj)를 하는 건 너무 오버 같다.
뭐, 어느 베이스를 선택할지 static_cast<IDataObject*>(&obj) 이렇게 명시적으로 지정을 해 주면 모호성이 해소되어 C++ 차원에서 IUnknown으로 cast도 가능해진다.
하지만 이것도 언어 차원에서 더 깔끔하게 해결할 방법이 없는지, const 객체뿐만 아니라 베이스 인터페이스에 대해서도 select_any 같은 속성을 지정해 줄 수는 없을지 궁금하다.

참고로 이런 형변환이 일어나는 곳은 해당 객체 자체가 아니라 십중팔구 그 객체의 포인터들이다. 그러니 그 클래스에서 operator IUnknown*() { return static_cast<****>(this); } 이렇게 전용 형변환 연산자를 구비하는 것은.. 성능 오버헤드는 없지만 언어 문법 차원에서의 아주 깔끔한 해결책으로 보기는 어려워 보인다.;;;

Posted by 사무엘

밤에 일반 공도에서 주변 민폐를 끼치면서 차나 오토바이로 과속· 폭주를 즐기는 양아치한테 일반인들이 흔히 하는 핀잔 중 하나는 "그렇게 폭주가 좋으면 그런 짓은 서킷에나 가서 해라"이다.

본인도 나름 성질이 급하고 운전대를 잡으면 과속을 즐기며, 난폭운전은 직접 하는 것과 남의 차에 탑승하는 걸 다 좋아하는 취향이다.
하지만 그렇다고 그런 짓을 주변 차에다가 피해를 주면서까지 하지는 말아야 한다. 차가 없고 시야가 확보돼 있는 한적한 고속도로에서야 150~200km/h까지도 밟지만, 엄폐물이 많고 당장 앞과 옆에서 뭐가 튀어나올지 모르는 좁은 골목길에서는 시속 20도 안 밟으면서 천천히 가는 게 베스트 드라이버의 덕목이라 하겠다.

그건 그렇고 본인은 이 시점에서 의문이 들었다. 그 말로만 듣던 서킷에서는 어떤 일이 벌어지고 있을까? 더 나아가 Formula 1처럼 지금까지 말로만 들어 온 자동차 경주라는 업계의 사정은 어떠할까..?

1. 도로 시설

서킷은 통제된 환경에서 프로 선수들이 처음부터 작정하고 차를 위험하게 다루면서 극한의 속도 경쟁을 하는 곳이다. 공도가 전혀 아니며, 통상적인 도로교통법이나 자동차 보험 등에서 완전히 열외되어 있다. 일반인이 차를 슬금슬금 몰다가 실수해서, 혹은 극소수의 술 먹은 미치광이가 난입해서 사고가 나는 곳이 아니다.
이는 군인이 전투 중에 적군을 사살하는 건 살인죄가 전혀 아니며, 반대로 자기가 전사하는 것에 대해서도 통상적인 민간 생명보험이 적용되지 않는 것과 같다. 위험도와 사고 발생 형태가 규모와 차원 면에서 완전히 다르기 때문이다.

자동차가 발명된 이래로 자동차 경주라는 건 경마의 업그레이드 버전 차원에서 옳다구나 거의 곧장 존재해 왔다. 물론 이건 말 그대로 기름을 길바닥에다 뿌리는 짓이며, 장비값, 기름값, 보험료, 선수 인건비 등 돈이 굉장히 많이 깨지는 비싼 스포츠이다.
하지만 자동차 경주는 나름 흥미진진한 볼거리를 제공하며, 자동차 제조사들이 자기 제품의 기술력을 뽐내는 중요한 자리이기도 하다. 이런 이벤트가 하나쯤 있는 것은 자동차 산업의 관점에서 이해타산이 맞고도 남는다.

그렇기 때문에 자동차 경주 대회는 망할 일이 없으며, 기업 후원을 통해 꾸준히 잘 유지되고 있다. 아니, 그저 명맥만 유지하는 수준이 아니라 올림픽이나 축구 월드컵에 맞먹는 팬을 보유하고 있고 장사가 잘 된다. 물론 경주용 자동차들의 표면과 레이서들의 옷은 온~~통 스폰서의 광고들로 덕지덕지 도배된다.

우리나라는 10여 년 전에 전라남도 영암에서 F1 서킷을 건설하고 경기를 유치하기도 했다. 하지만 경기를 진행해 보니 수지가 맞지 않고 적자만 쌓인지라, 몇 년 못 가 중단됐다.
우리나라는 세계 선진국들의 평균 추세에 비해 경주처럼 자동차 자체를 즐기는 문화가 영 발달하지 못한 것 같다. 그러니 모터쇼도 자동차가 아니라 반쯤 레이싱걸 모델 전시장처럼 됐고 말이다..;;

2. 레이서

레이싱에서는 머신(자동차)뿐만 아니라 레이서, 즉 사람의 역량도 매우 중요하다. 사고가 나지 않을 만치만 차의 성능을 극한까지 짜내면서 최대의 급가속 급선회 기동을 적절한 타이밍 때 수시로 구사해야 한다. 그리고 전투기 조종사만큼이나 사방에서 발생하는 가속도를 잘 견뎌야 한다.

그래서 이 사람들도 몸 쓰는 게 아니라 기계를 조종한다고 해서 심신 단련을 안 하는 게 절대 아니다. 여느 운동 선수나 정예 군인에 준하는 수준으로 한다.
키와 체중은 일정 수준 이하여야 하며 높은 시력도 타고나야 한다. 말 타는 기수도 아니고 몇백 마력의 출력을 자랑하는 자동차를 모는데 체중이 10kg 가까이 더 나가 봤자 무슨 차이가 있겠는지 이해는 안 되지만.. 그 바닥 사정이 그러하다.

오죽했으면 세계적으로 봤을 때, 각 스포츠 분야의 1인자들 중에서 연봉과 사회적 지위가 제일 높은 사람은 무슨 축구나 농구 스타가 아니라 특급 카레이서이다~! 물론 여기에는 위험 수당도 있고, 타 스포츠와 달리 자동차 산업으로부터의 자본 투입이 많아서 그런 것도 있을 것이다.

3. 차량

그럼 서킷을 달리는 차들은 어떤 형태일까?
레이싱의 성격에 따라서는 일반 양산차를 쓰기도 하고 그보다 더 뛰어난 스포츠카를 쓰기도 한다. 하지만 속도가 생명인 경주용 차들은 공도를 달리는 평범한 차들과는 지향하는 특성이 다소 차이가 있다.

• 무게 최소화: 일반 양산차로 경주를 한다면, 불필요한 좌석이나 편의장치를 몽땅 떼어내는 정도의 개조가 무조건 필수이다.
  
• 접지력 최대화: 그래서 스포츠카들은 조금만 툭 튀어나온 과속방지턱도 제대로 지나기 어려울 정도로 바닥이 낮다(무게중심이 아래에 있어야..). 그리고 주름이 하나도 없는 타이어를 장착한다. 주름 없는 타이어는 접지력은 좋지만 도로가 조금이라도 젖으면 미끄러져서 위험하다. 공도에서는 이런 타이어를 장착하고 주행할 수 없다.
  
• 공기 저항 최소화: 더 이상의 자세한 설명은 생략한다.

그러니 자동차 경주에서는 양산차도 아니고 부가티· 포르셰 같은 차도 아니라, 큼직한 바퀴가 네 짝 달리긴 했는데 굉장히 특이하게 생겼고 한 명만 탈 수 있는.. 그 경주 전용 자동차들이 등장한다.

얘네들은 그야말로 배기량이 제한된 엔진의 힘을 이용해서 수단과 방법을 가리지 않고 제일 먼저 결승선에 도달하는 것만을 목표로 아주 특수하게 커스텀 제작된 물건이다.
부가티· 포르셰 같은 차는 성능에다가 일반인 운전자의 편의성까지 생각한 자동차이지만, F1용 머신은.. 오로지 성능 지향이다.

그런데 F1 경주라고 해서 무슨 부가티· 포르셰 급의 8기통 이상 6000~8000cc짜리 엔진이 장착된 차량이 달리는 게 절대 아니다.
이런 경주에서 엔진에 아무 제한을 걸지 않으면 온갖 기상천외한 짓거리를 한 머신이 등장해서 사고의 위험이 커지며, 자동차 제작 비용이 너무 치솟아서 경기가 제대로 진행될 수 없게 된다. 거기에다 아무리 속도만을 즐긴다고 해도 배기가스 환경 문제도 전혀 고려하지 않을 수는 없다.

그래서 격투기에 체중에 따른 체급 구분과 제한이 있는 것처럼 자동차 경주에는 엔진의 배기량 제한이 있는데.. 이게 낮아지고 낮아지기를 반복한 끝에 2014년부터는 F1 기준으로 겨우 1600cc라고 한다..;; 헐~~ 쏘나타보다도 작은 아반떼 배기량인데..

요즘 F1 차량은 그 배기량만으로 1000마력이 넘는 출력을 내고 2~3초대의 사기적인 제로백을 자랑한다. 즉, 튀어나가는 성능은 당연히 부가티· 포르셰에 뒤지지 않는다.
차 무게를 600kg대까지로 후려치고, 엔진 내구성도 후려치고.. 차량을 그야말로 경주를 위해 몇 시간 동안만 돌아가는 사실상의 일회용품 수준으로 쥐어짠 덕분이다.

컴퓨터계는 해커들이 겨우 100KB짜리 압축된 실행 파일로 거의 5분, 10분짜리 3차원 그래픽 데모를 선보이는 미친 최적화를 하기도 하는데, F1 머신에는 그런 식의 마개조가 일상이다.

그 대신 이런 F1 머신 같은 차들은 시동 걸고 운전하는 방식이 일반 차들과는 완전히 다르며, 사실 일반 공도를 제대로 주행하지도 못한다. 일반 자동차들은 동력원이 전기로 바뀌고 자율 주행 기술이 도입되고 있으니 경주용 자동차와는 개발 방향이 더욱 달라지고 이질화되고 있다. 스포츠 사격과 군대 저격수의 사격이 성격이 서로 다른 것처럼 말이다.

※ 그 밖에

(1) 지금까지 주로 F1을 기준으로 얘기했지만.. 이것보다 더 작은 체급으로 '카트'를 이용한 레이싱이 있다. 우리나라에서는 넥슨의 캐주얼 게임인 카트라이더의 인지도가 높다.

얘는 너무 작기 때문에 아무래도 큰 엔진을 얹어서 막 빠르게 달리지는 못한다. 그래도 바닥에 주저앉다시피해서 달리기 때문에 체감 속도는 굉장히 높게 느껴진다.
F1 프로 레이서들도 어린 시절에 카트부터 먼저 시작한 경우가 많다. 카트는 아무래도 양발을 한데 모을 수 없으니 브레이크는 어쩔 수 없이 언제나 왼발로 밟게 된다.

(2) 비포장 도로를 주행하는 오프로드 레이싱이라는 것도 있다. 얘들은 아무래도 속도에만 최적화된 타 레이싱과 같은 속도를 느낄 수는 없지만, 또 다른 방면으로 스릴과 박진감을 선사한다.
여기를 달리는 차들은 아주 큼직한 타이어를 장착하고 차체가 높은 게 특징이다. F1 머신과는 디자인이 정반대이다.

먼 옛날에 Ivan "Ironman" Stewart's Super Off Road, 일명 방구차라는 게임이 바로 오프로드 레이싱을 다뤘었다.

얘는 자동차 경주 게임이지만 화면 스크롤이 없다~! 한 화면에서 모든 경주가 행해진다. 스크롤도 없고 콩알만 한 자동차 스프라이트로 무슨 박진감을 표현하겠나 싶지만 평면에서 나름 복잡한 지형과 입체적인 자동차의 움직임을 그 시절 하드웨어로 표현하는 것은 딱 봐도 결코 쉬운 일이 아니어 보인다. 방향과 각도별 스프라이트 로직 설계를 어떻게 했을까? 나보고 저것과 똑같은 게임을 만들라고 하면 못 하거나 엄청 고생하지 싶다.

우리 주인공은 빨간 차인데, 노랑과 파랑은 제끼고 회색 차가 유난히 잘한다. 쟤만 따돌리면 된다.
이 게임의 별명이 '방구차'인 이유는.. Nitro라는 아이템을 먹어서 그걸 터뜨리면 마치 스타크래프트 마린이 스팀팩을 쓰듯이 일시적으로 차의 추진력이 올라갔기 때문이다.

(3) 사회 각지에서 금녀의 벽이 허물어진 지 오래이지만, 교통수단을 다루는 분야는 여성의 진출이 더딘 편이다.
옆의 레이서들에게 양산 씌워 주거나 자동차 옆에서 포즈만 취하고 있는 레이싱걸 병풍 말고.. 현업 여성 카레이서도 있다. '권 봄이'라는 사람이 지난 2010년대 동안 꽤 유명했는데 요즘은 뭘 하고 지내나 모르겠다.

또한, 여성 오토바이 라이더들도 모임이 있을 정도이며, (☞ 링크)
20대 여성 고속버스 기사 (☞ 링크),
20대 여성 트레일러 기사 (☞ 링크),
도 있다~!
한때는 " '이 운전사는 저의 아버지가 아닙니다.' / '이 아이는 제 자식입니다' 그럼 저 버스 기사의 정체는?" (아이의 어머니)
이게 "논리야 XXX" 시리즈 책에 실려 있을 정도로.. 짙은 선입견 때문에 일반인이 답을 선뜻 떠올리기 어려운 퀴즈였는데.. 그때에 비하면 지금은 세상이 많이 바뀌었다.

Posted by 사무엘

과거에 일제가 조선의 주권을 빼앗고 저지른 만행 중에서 물자나 노동력을 저렴하게 착취한 것, 사람을 차별 대우한 것, 독립 운동을 탄압한 것 자체는 아무래도 식민 통치를 하고 식민지에서 뽕을 뽑으려는 주체로서 당연히 할 만한 짓을 한 것이다. 잘했다는 것은 아니지만 우생학과 제국주의가 만연하던 그 시절에 일제만의 독보적인 악행이라고 보기는 어렵다. 더구나 조선에서의 양반 쌍놈 차별이라든가 기존 탐관오리들의 악행도 같이 비교한다면 상대적인 수위가 더욱 낮아진다.

그 반면, 일제 말기의 태평양 전쟁 관련 뻘짓과 악행은 성격이 좀 다르며 별개로 생각해야 할 것이다.
이렇게 (1) 일반적인 차별과 착취, 그리고 (2) 전쟁 준비에 속하지 않으면서 일제가 특별히 큰 죄악을 저지른 것, 정당하지 않은 명분으로 조선 민간인을 싹 학살한 만행을 추려내면 제암리 학살이라든가 관동 대지진 학살 정도가 남는다. 특히 개인적인 생각으로는 위안부보다도 관동 대지진 학살이 죄질이 더 나쁘다고 본다.

뭐, 일제도 한 마을 사람을 아무 이유 없이 싸이코패스마냥 몰살시키고 마을을 지도에서 지워 버린 건 아니었다.
3· 1 운동 만세 시위를 진압하던 헌병인가 누군가 한두 명이 성난 군중에게 구타 당해 죽었다. 그러자 일제는 범인이 저 마을 사람 중에 있다는 명목으로 보복을 저렇게 저지른 것이었다.

그런데 그렇게 따지면.. 처음엔 태극기만 들고 평화롭게 함성 지르며 행진하던 시위대가 격분· 흥분한 건 일본 헌병들이 실탄을 발사하고 피를 보게 만들었기 때문이다.
오죽했으면 유 관순 같은 시위대 리더들이 우리까지 폭력으로 나서면 안 된다고.. 그랬다가는 더 큰 보복을 당하고 만세 시위가 더 큰 참극으로 바뀐다고 군중을 말렸지만 혼란스러운 와중에 의사소통이 잘 되지 않았다.

결과는 잘 알다시피.. 처음에 일부 헌병 주재소가 박살나고 유치장 수용자들이 풀려나긴 했지만, 일본 쪽의 추가 지원 병력이 도착한 뒤부터는 시위대는 공중분해되고 더 많은 사람들이 죽거나 다쳤다. 헌병들도 흥분해서 다 죽이거나 잡아 가두고, 마을 집까지 불지르게 되었다.

이때는 오늘날 민주 국가의 경찰처럼 폴리스라인 치고 공포탄 경고 사격부터 몇 발 한 뒤에 암염탄이니 테이저건이니 발사하는 신사적인 매뉴얼이 없었다. 일제 저놈의 입장에서도 남의 나라 식민 통치라는 건 처음 해 보고, 반항하는 애들에 대해서는 그냥 닥치고 총칼로 위협하고 고문하고 죽여서 제압한다는 매뉴얼밖에 없었다.
(하물며 우리나라조차도 해방 이후에 4 19 같은 시위를 진압할 때 잘 알다시피 경찰이 대놓고 시위대에게 총질을 할 정도였다. 그때는 보고 배우고 행한 관행이 그랬기 때문이다.)

1919년 4월, 제암리 학살은 이런 배경에서 벌어졌다.
석 호필이라는 이름으로 유명한 프랭크 스코필드 선교사가 제암리 학살 현장의 참상을 촬영하고 세계에 타전해 줬다.

우리 선조들은 민족 자결주의 하나만 달랑 믿고 무슨 "꿈은 이루어진다"마냥 "대한 독립 만세"를 열심히 외치면 진짜 일제가 물러날 거라고 생각했던 걸까?
냉정한 현실에 비춰 본다면야 3· 1 운동은 그냥 숱한 인명과 재산의 피해만 야기한 순진해 빠진 망상이었을 것이다. 하지만 저런 희생을 치른 덕분에 조선은 일본과 다른 민족이며 일제의 통치를 원하지 않는다는 메시지 하나는 세계에 확실하게 전하고 일제의 입장을 굉장히 난처하게 만들 수 있었다. 전술의 패배 대신 전략의 승리를 얻은 건지..?

강대국이 식민 통치를 하는 것 자체는 합법이고 관행이던 제국주의 시절에도 "당신 일본은 식민지를 얼마나 개판으로 관리했으면 10년을 못 채우고 저런 대규모 항쟁이 전국에서 벌어졌냐? 그리고 그걸 또 그 따구 방식으로 겨우 진압했냐?"라는 질타가 들어왔을 정도였다. 그러니 조선 총독도 본토로부터 당연히 내리갈굼을 먹었다. -_-;;

그래도 3· 1 운동 같은 발악이 있었던 덕분인지 일본 내부에도 조선의 식민 통치를 반대하고 조선의 독립을 지지하는 소수의 일본인이 생겨났으며, 그 흐름이 지금까지 이어져서 자국의 만행을 사죄하는 사람들이 있다.
이거 마치 임진왜란 시절에 조선으로 귀순한 왜군 장수를 보는 듯한 느낌인데.. 이런 사람들이 제일 최근에 대대적으로 매스컴을 탄 건 2년 전, 2019년 2월경이다. (☞ 링크)

우와, 읽는 내가 눈물이 나려 한다. (반어법이 아님!)
저 사람들이 다른 사회· 정치 쪽으로 다른 이상한 운동에 연루돼 있지 않고, 신학 노선이 그리 이상한 곳도 아니라고 가정한다면, 난 저 사죄가 진심 레알임을 인정한다.

정치인들의 정식 사죄?? 바라지도 않는다. 사실 외교적으로는 우리나라는 이미 일본의 까임권을 다 써 버린 지 오래다. 그걸 아직도 우려먹는 게 비정상이고, 외교 신뢰를 깎아먹는 바보짓이다. (이제 더 논하지 않기로 약속하고 퉁쳤잖아! 그런데 이거 뭐 정권이 바뀔 때마다 말이 달라지니..)

정치인이 아니면 민간에서라도.. 저렇게 자기 나라 참전 때문에 남북 분단을 영구히 고착시켜 버린 것을 안타까워하고 미안해하는 대륙 사람이나 조선족이 어디 있나? 비열한 전쟁과 테러 공작에 대해서 진심으로 유감스러워하고 화해하고 싶어 하는 동족이 이북에 어디 있긴 하냐?
이러니 내가 종북이 친일보다 더 나쁘다고 논리적으로 정정당당하게 주장하는 거다.

저렇게 대표 기도를 한 '오야마 레이지'(尾山令仁)라는 목사는 나이가 이미 90을 넘은 고령인데..
행적이 정말 엄청난 분이더라. 제암리 학살에 대한 사죄와 추모를 50년 이상 전부터, 1965년 한일 수교가 최초로 이뤄졌던 시절부터 일평생을 바쳐 해 왔다!
1969년 4월 15일, 인류가 아직 달에도 가기 전이었던 시절의 중앙일보 보도를 보자. (☞ 링크)

오야마 이마히도(미산금인).. 저 사람 맞다. 령을 금이라고 표기한 건 종이 신문 OCR의 한자 판독 오류일 테고..
그는 진작부터 하나님께 나아오기 전에 니 형제와 화해부터 먼저 하라(마 5:23-24)는 말씀으로부터 깊은 부담을 느꼈고, 60년대부터 "일본은 히로시마· 나가사키를 기억하기 전에 제암리부터 먼저 기억해야 합니다"라고 주장했다. (☞ 링크)

"제암 교회 방화 사건 속죄 실행 위원회"라는 걸 만들어서 자국에서 성금을 1천만 원(50년 전 물가.. 책 한 권 가격이 백원대 단위이던 시절)을 모아서.. 제암리 교회를 재건하고 주민 의료 진료소까지 만들려고 했다...;;

감리교 교단에서는 이를 환영하고 동의했으나(오리지널 제암리 교회도 감리교였음).. 문제는 민심이었다.
제암리 학살 피해자 유족들은 "왜놈들의 더러운 돈으로 교회를 세우는 건 순국선열에 대한 모독이다. 죽어도 결사 반대!!" 이렇게 나오면서 성금 따위 한 푼도 안 받으려 했으며, 오야마 씨를 만나 주지도 않았다.

1960년대의 우리나라는 그야말로 반공과 반일이 가히 하늘을 찌를 기세였던 시절이다. 일가족이 몰살당했던 유족들의 저 까칠한 반응에 대해서도 후손인 우리 세대가 뭐라 할 수는 없다.
하지만 오야마 목사는 저런 냉대조차도 담담히 감내하면서 몇십 년을 한결같이.. 2019년까지도 "일본의 과거 침탈을 깊이 사죄합니다. 주여, 우리 일본인들을 용서해 주십시오." 이래 왔던 것이다. 한국, 일본 모두로부터 그다지 지지나 환영받지 못했는데도 말이다.

이 정도면 대인배만으로는 표현이 부족하고.. 예수쟁이로서 좀 거시기한 표현이긴 하지만.. 가히 보살 급이지 않은가..??
이 뿐만이 아니다. 쟤들은 무려 20년 전에 세상을 떠난 의사자 이 수현 씨를 아직도 기억하면서 매년 추모식을 연다.

JR 서일본(☞ 링크)은 2005년 후쿠치야마 선 탈선 사고에 대한 사죄와 반성 문구를 자사 홈페이지에다가 15년째.. 지금까지도 사실상 영구 박제 수준으로 걸어 놓고 있다. 이런 걸 보면 일본인의 근성에 참으로 놀라움을 느낀다.

오야마 이마히도 목사도 신학을 한 구체적인 배경은 잘 모르겠지만.. 한국인으로서 꼭 기억할 만한 양심적이고 훌륭한 일본인이라 하겠다. 얼마 안 있으면 소천해서 근황을 못 보게 될 수도 있다.

그럼 제암리 학살과 관련하여 다른 이야기 하나만 더 꺼내고 글을 맺겠다.
미국 독립 전쟁을 배경으로 20년 전 옛날 영화 '패트리어트'에서는 영국군 레드 코트들을 개 싸이코 악마 병신으로 묘사하기 위해, 어디서 본 건 있는지 제암리 학살 사건을 오마주 한 듯한 장면이 들어갔다.
니들이 식민지군 반역자들을 숨기고 있다는 죄목으로 주민들을 예배당 안에 한데 모아 놓고 문을 못질 하고 건물을 불지른 것.

하지만 영국군이 그런 잔학한 짓까지 실제로 한 적은 없었기 때문에 영국은 이 장면에서 언짢은 반응을 보였다고 한다.
심지어 제암리 학살조차도 여자, 아이들까지 다 예배당에다 가두고 문에 못질을 한 건 아니었다고 사료가 정정되고 있다. 키가 일정 수준 이상인 15세 이상 남자만 죽였다고.. 뭐 그것도 비무장 양민에 대한 반인륜적인 학살인 건 변하지 않지만 말이다.

심지어 그때 불타는 예배당 안에서 어떤 여인이 "제발 우리 아이만은 살려 주오"라고 담요에 둘러싸인 아기를 밖으로 내밀었는데 헌병들이 칼질을 했던가 총질을 했던가.. 그런 얘기까지 전해지는데.. 그것도 일단은 현실성을 의심해야 할 것 같다.;;

Posted by 사무엘

1. 2021년 상반기, 교통 분야의 변화

여의대로와 경인로 사이엔 길 중앙을 틀어막고 공사가 몇 년째 벌어지고 있었는데.. 공사가 끝난 깔끔한 모습을 본인은 며칠 전에야 드디어 처음으로 목격했다.
신안산선이나 GTX 같은 지하철 공사인가 막연히 생각했는데 그게 아니다. 여의도-신월 지하 유료 도로. 여의도와 경인 고속도로가 이렇게 곧장 연결되었다니 신기한 노릇이다.

그건 반가운 소식이지만, 정말 노이로제 걸릴 정도로 난무하는 변태 같은 시속 50, 50, 50, 50 소리 때문에 미치겠다. 시속 80~100은 밟아도 될 것 같은 멀쩡한 6~8차로 도로에서 이게 무슨 개짓거리냐?? 저 신월-여의 지하 도로 출입구에도 시속 50 단속 카메라가 붙어 있더라.

작년에 재난지원금 뿌려서 재정이 부족한 걸 이딴 식으로 회수하려 든다는 합리적인 의심이 든다.
정상적인 애매한 자동차들 속도를 찍어누르지 말고 악성 무단횡단자나 엄하게 처벌하면 도로가 훨씬 더 안전해질 것 같은데 말이다.
멀쩡한 대만 유학생을 죽게 한 음주운전 가해자놈한테는 솜방망이 처벌로 나라 망신이나 시키고.. 사법 분야는 영 마음에 안 든다.

뭐 그건 그렇고, 자동차뿐만 아니라 도시철도 쪽도..
서울 지하철 5호선의 동쪽 종점이 상일동에서 무려 몇십 년 만에 하남 검단산으로 바뀌었다.
공교롭게도 6호선은 봉화산, 7호선은 도봉산 이렇게 종점 근처에 산이 있었는데 5호선도 그 관행을 따르게 된 듯하다.

그 검단산 근처에 성남시에도 영장산과 망덕산 사이에 '검단산'이 있긴 하다. 하지만 성남 검단산은 두 산 사이에 끼여 있고 정상에 군부대도 있어서 접근성과 존재감이 하남 검단산보다는 훨씬 떨어진다. 굳이 '하남'을 붙일 필요는 없는데 왜 저렇게 작명을 했는지는 잘 모르겠다.

요즘 안 그래도 외국 여행을 못 가서 국내 여행과 등산이 젊은 사람들 사이에서도 각광 받고 있다는데, 나도 등산 다시 가 보고 싶네..
앞으로 신분당선 강남-신사 구간, 그리고 서울 동부의 29번 고속도로를 연결하는 한강 교량, 400번 제2순환 고속도로, 동해남부선 복선 전철, 경기도 GTX 등이 기대된다.

2. 프로그램 개발

보통 프로그램 개발 근황은 날개셋 카테고리에다가 올리는 편인데 이번에는 분량이 짧고 별 컨텐츠가 없기 때문에 여기에다가도 간단히 언급하고 넘어가겠다.

지난달에 나온 날개셋 한글 입력기 10.2는 외부 모듈의 동작 안정성과 프로그램 호환성이 크게 개선되었음을 당당하게 내세운 버전이었다. 실제로 한글과 비한글(조합과 비조합)을 섞어 가며 입력할 때 프로그램별로 자잘하게 발생하는 문제들은 이제 확실하게 해결됐다.

그래서 정말 답이 없는 Windows Terminal 요놈에 대한 인위 보정만 제외하면 나머지 수동 보정 옵션은 없어졌다.
사실은 MS IME조차도 이 프로그램에 대해서는 놀랍게도 일종의 보정을 해서 동작하고 있다(타 프로그램일 때와는 기능 수행 순서가 정반대). 무슨 기준으로 보정하는지를 알 길이 없어서 내 프로그램에서는 불가피하게 수동 보정으로 남겨 놨을 뿐이다.

하지만 크롬 브라우저에서는 여전히 그것도 버전업 될 때마다 계속해서 새로운 문제가 발생하고 있다. 한글을 입력하는 것 자체가 아니라 조합이 마우스 클릭 등 외부에 의해 강제 종료됐을 때의 처리가 영 원활하지 않다.
그리고 심지어 조합이 종료됐을 때 이전에 입력됐던 글자들이 무더기로 삽입되는 현상까지도 본인이 발견은 했지만.. 정확한 재연 조건을 도무지 모르겠다. 크롬과의 악연은 2년쯤 전인 2019년부터 지금까지 계속 이어지는 중이다. 어휴~~ㅠㅠㅠ

그것 말고도 제어판 대화상자를 DPI 설정이 다른 모니터로 옮겼을 때 내부 컨트롤 배치가 확 깨지는 문제를 버그 신고를 통해 발견해서 해결했고, 입력 도구와 대화상자 UI 곳곳에서 버그를 고치고 외형이나 동작을 자잘하게 고쳤다.
다음 버전은 일단은 6월애 내놓으려 하는데, 10.3이 될 수 있을지 그 이상이나 이하가 될지 잘 모르겠다.

3. 캠핑 노숙

요즘처럼 날씨가 좋을 땐 본인은 밤에 집에서 잠을 자지 않는다.
금요일 밤엔 자전거만 몰고 갈 수 있는 곳에 가고, 토요일 밤에는 차로 좀 가야 하는 곳에서 텐트를 친다. 이튿날 아침에 곧장 교회에 가기 위해 운전을 또 하니까 이게 합리적인 선택이다.

차로 간 곳은 충분히 외져서 인적이 전혀 없고 보안 걱정을 할 필요가 없었다.
하지만 자전거로 간 곳은 속세와 완전히 떨어지지는 않은 단순 공원 안에서 짱박힌 수준.. 그래서 한밤중이나 이른 아침에 산책을 하는 주변 사람들 눈에 가끔 띌 수도 있었다.
프로그래머로서 이런 건 hash값의 충돌과 비슷한 상황이라고 생각한다.;;;

가끔은 텐트 근처까지 누군가가 데리고 오는 개가 짖는 소리가 들리곤 한다. 물론 텐트는 창과 문을 다 닫았으니 보이지는 않고..
텐트 주변에 시시하게 겨우 개가 아니라 야생 멧돼지가 다가오는 날은 언제쯤 도래할지 모르겠다.

자연 속의 환상적인 내 개인 연구실 겸 침실을 놔두고.. 더워서 선풍기를 틀어야 하는 갑갑한 콘크리트 구조물에서 도대체 왜 자리요? 그건 무술 연마 없이 그냥 총 쏴서 사람을 제압하는 것과 같고, 등산 없이 그냥 헬기나 케이블카 타고 산을 오르는 것과 같다.

내게 집은 주민등록 근거지와 수도 전기의 보급, 씻기 등의 개인정비=_=, 책과 옷 등을 보관하는 창고 정도의 역할을 한다. 먹고 자는 곳은 아님. 처자식 없이 혼자 사는 동안 당분간은 계속 그럴 것 같다.
쓰레기 버리고 오존층 파괴하고 이산화탄소 농도 늘리는 것만 자연에 대한 비매너인 게 아니다. 이런 날 자연 속에서 밤을 보내지 않는 것도 자연에 대한 예의가 아니라는 것이 나의 신념이다.

한겨울은 엄청나게 춥다.
나야 추운 것 자체는 아주 땡큐이지만.. 이 때문에 추가 담요와 잠바 같은 방한 보온 장비가 많이 필요해져서 보행 시의 무게 부담(payload)이 증가하며, 이동 반경이 감소한다.
그리고 -10도 밑으로 내려가면 전자기기들도 잘 못 버틴다. 폰의 배터리가 일시적으로 곤두박질치거나 차의 스마트키가 버벅거릴 정도로..

여름이 되면 짐은 한결 가벼워진다. 더 멀리 이동 가능하고 간편하게 텐트 칠 수도 있다.
하지만 낮이 길고 이동에 부담이 없기 때문에 다른 사람들도 산이나 공원 내부의 더 깊숙한 곳까지 이른 시간부터 접근한다. 그렇기 때문에 보안이 상대적으로 떨어진다.

그리고 기온이 올라가면 야생에서는 벌레도 증가한다. 더워서 텐트 창문도 열어야 할 판인데 도대체 어디서 냄새를 맡았는지 모기 떼들이 5분 안으로 창문 방충망에 덕지덕지 달라붙는다.

이런 장단점을 감안하면..
적당히 추워서 최소한의 장비만으로 간단하게 보온이 되고, 산에 조금씩 초록색이 늘어 가고, 아직 모기도 들끓지 않는 지금이야말로 텐트 캠핑 노숙에 입문하기 최적의 시기라고 할 수 있다.

Posted by 사무엘

1. 압축 유틸

요즘은 Adobe Reader 같은 거 설치할 필요 없이 크롬이나 Edge 같은 브라우저만으로도 자체적으로 pdf 문서를 바로 열어 볼 수 있다.
압축 유틸리티에서 광학 디스크 이미지 파일의 내용을 바로 볼 수 있게 된 것과 비슷해 보인다. 한 분야의 프로그램이 비슷한 다른 분야의 프로그램의 역할을 일부 흡수해 버렸다.

물론 이미지 파일을 새로운 드라이브로 mount 시키는 것까지 압축 유틸이 지원하지는 않는다. 그것까지 지원하면 압축 유틸의 기능이 옛날 도스 시절의 Double Space 같은 디스크 압축 유틸 급으로 커지는데.. 요즘은 그런 기능이 필요할 정도로 디스크의 용량이 부족한 시절이 아니기 때문에 유행이 지났다. 그리고 결정적으로 드라이브 mount는 이제 운영체제(Windows 10)가 자체적으로 제공해 주는 기능으로 흡수되기도 했다;;

국내의 경우 20여 년 전, 이 바닥이 WinZip, WinRAR 같은 외국산 압축 유틸리티 일색이던 시절에 이스트소프트의 '알집'이 처음에 적절한 마케팅 덕분에 시장 선점을 잘 해서 폭발적인 인기를 누렸다. 그러나 버그· 안정성 문제에 적절히 대처하지 못해서 2000년대 말쯤에 컴덕들 사이에 욕을 엄청 먹었으며, 그 와중에 기업 대상 유료화까지 선언하는 바람에 입지를 더욱 잃게 됐다.

그 와중에 개인 개발자 1인의 작품인 '빵집'이 알집의 대체제로 각광 받아서 2000년대 후반에 큰 인기를 끌었다.. 하지만 빵집은 개발자의 개인 취미 생활이다 보니 유지보수에 한계가 있었고, 결국 개발이 중단되어 역사 속으로 사라졌다.
그리고 오늘날이야.. 그 틈새를 저격한 반디소프트의 '반디집'이 탁월한 완성도로 천하를 평정했다.

압축 유틸의 역사를 읽어 보노라면, 소프트웨어는 모름지기 수요와 타이밍, 시장 공략을 잘 해야겠다는 걸 느낀다.
zip은 압축 해제뿐만 아니라 생성까지 소스가 완전히 공개돼 있고 그 다음부터 7z, ace, rar 등 압축 알고리즘들의 압축률은 이론적인 정보량 한계에 근접해서 거기서 거기이다 보니.. 알고리즘은 zip 하나만 있으면 되고 그 뒤 멀티코어, 64비트, 유니코드, 기본적인 보안, 운영체제 셸과 잘 연계하는 UI...

이것만 제공되면 그 다음부터 굳이 유료 유틸을 쓸 필요가 크게 줄어드는 것 같다. 실제로 본인도 '-집' 계열 유틸을 사용하기 시작한 뒤부터는 Windows에서 zip 말고 rar 등 다른 압축 파일을 '생성'해 본 적이라고는 전혀 없는 것 같다.

2. 유튜브

(1) 유튜브 동영상에 광고가 5~10여 년 전에 비해 굉장히 많이 늘어난 게 느껴진다.
뭐, 쟤들도 흙 파서 먹고 사는 건 아닐 테니, 오랫동안 무료로 잔뜩 뿌리고 투자했던 것을 회수할 때가 됐다. 전세계에서 발생하는 천문학적인 수의 동영상들을 저장하고 전송 트래픽을 감당할.. 서버 유지비가 장난 아니게 깨질 것이며.. 몸값 비싼 엔지니어들을 고용하는 인건비도 상상을 초월할 것이다. 서버 관리자, 웹 UI 디자이너 및 개발자, 동영상 코덱 전문가, 동영상 컨텐츠들의 검색과 분류 알고리즘 전문가 등..

그러니 동영상 포털이 사용자에게 거부감을 제일 덜 주면서 수익을 내는 건 광고 또는 사용자에게 "광고 안 뜨는 기간제 유료 계정" 판매로 자연스럽게 귀착될 것이다. 나도 광고가 너무 잦아지니 잠시 동안만이라도 광고 없는 유튜브 프리미엄 유료 계정을 써 보고 싶다는 생각이 종종 든다. 유튜브도 사용자를 이렇게 적당히만 귀찮게 하는 걸 목표로 하지 싶다.

요즘 친구들끼리 생일 선물로 카카오톡으로 이모티콘이라든가 커피 상품권을 주고 받는 게 있다. 그런 것처럼 몇천 내지 1~2만원대의 유튜브 프리미엄 n개월 이용권이 온라인/모바일 생일 선물로 오가는 건 어떨까 싶다.

여담이지만, 유튜브뿐만 아니라 평소에 위키백과를 지식 습득용으로 유용하게 사용해 온 사람이라면 거기에도 후원금을 소액이나마 내는 게 좋을 것이다. 특정 기업의 입맛에 휘둘리지 않고 상업 광고도 없는 개방된 지식 저장소는 컴퓨터와 인터넷을 지금 같이 누구에게나 평등하고 투명하게 개방된 정보의 바다로 만드는 데 절대적인 기여를 했기 때문이다.

(2) 다음으로, 돈이나 광고와 별개로 본인이 요 근래에 유튜브에 대해서 느끼는 굉장히 큰 불만이 하나 있다.
HD급 이상의 무거운 고화질 동영상일수록 더 두드러지는 것 같은데.. 슬라이더에서 좌우 화살표를 눌러서 앞뒤 5초 남짓 단위로 seek를 한번 하는 데 걸리는 딜레이가 너무 길다는 것이다. 동일 화질 기준으로 그냥 하드에 저장된 동영상을 데스크톱용 플레이어 앱에서 seek하는 것만치 빨리 즉시는 절대 못 한다. 답답하지 않으신가?

옛날 저화질 동영상은 이렇지 않다. 이건 다운로드 자체는 이미 다 된 구간을 돌아다니는 것만 말한다. 그러니 네트워크 상태하고도 무관하다.
기술적인 한계 때문에 느린 건지 아니면 이것도 설마 현질 유도를 위해 고의로 들어간 핸디캡인지는 잘 모르겠다.

(3) 끝으로, 유튜브 유료 계정에 제공되는 서비스로는 광고 제거뿐만 아니라 동영상을 아예 로컬에다 다운로드하는 것도 있었다.
하지만 그건 별도의 서비스가 없더라도 뒷구멍을 통한 다운로드 서비스가 넘쳐나다 보니 유튜브에서도 단속을 포기한 것 같다. 별도의 앱이던 게 더 간편한 웹으로 바뀌기까지 하고 말이다. 사실 이건 기술적으로, 근본적으로 막을 수 있어 보이지는 않는다.

3. 이메일: 대용량 파일 첨부, 발송 확인 및 취소 기능

15년쯤 전에 구글 gmail이 최초로 1GB짜리 웹 기반 무료 이메일을 개설한 이래로 요즘은 어디건 이메일 서비스는 기본이고 용량이 기가바이트급이다. 하지만 이메일은 편지함 용량과 컴퓨터의 하드 용량이 증가한 것에 ‘비하면’, 무슨 영화 파일 급의 대용량 첨부 파일을 주고 받기에는 여전히 좀 버거운 수단이다. 기껏해야 수~수십 MB 정도가 한계?

초대용량 파일은 메일에다가 직접 붙이는 게 아니라 다른 클라우드/웹하드에다 올리고 나서 그거 링크만 메일에다 넣는 형태로 대체되는 게 요즘 추세이다.
수신 확인 및 오발신 취소 같은 것도 이메일의 정식 프로토콜/스펙에 규정된 기능이 아니라 각 웹메일 서비스 사이트에서 자기 계정간 이메일에 한해서만 제공되는 비표준 편의 기능인데.. 이것도 좀 표준으로 승격됐으면 하는 바람이 있다.

4. 크롬 브라우저로 네이버 블로그 첨부 파일 다운로드

크롬 브라우저로는 네이버 블로그 기반의 사이트에서 첨부 파일 다운로드가 잘 되지 않는 문제가 있다.
나만 겪는 현상인 줄 알았는데 아니었구나..

검색을 해 보니, 네이버 블로그는 https 기반인데 다운로드 링크는 보안이 취약한 http 기반이어서 크롬이 의심스럽다는 이유로 다운로드를 차단한 것이었다.
즉, 네트워크 구조에 문제가 있어서이지, 첨부 파일의 내용에 문제가 있어서가 아니었다.

이렇게 웹페이지의 구성요소에 https와 http가 뒤섞여 있으면 브라우저가 의심스럽고 불안하다고, 그래도 내용을 다 보고 싶냐고 온갖 귀찮은 확인 메시지를 사용자에게 띄운다. 다들 한 번쯤은 그 모습을 본 적이 있을 것이다.

그런데 크롬의 경우, 그 어떤 에러 메시지도 없이 그냥 일방적으로 네이버 블로그로부터의 다운로드를 씹어 버리니 당혹스러웠다. 은행 ActiveX도 아니고 파일 다운로드를 위해서 구닥다리 IE를 끄집어내는 촌극이 벌어지기도 했다.
뭐, 궁극적으로는 천하의 네이버가 이 문제를 해결하고 네트워크 구조를 불안 요소가 없게 어서 고쳤으면 좋겠다.

크롬은 이제 올해부터 플래시조차 지원을 완전히 끊었다. 아직도 메뉴가 플래시 기반인 웹사이트는 한 몇 년은 관리를 안 한 완전 구닥다리.. "1024*768 해상도에서 IE 6 브라우저에서 가장 잘 보입니다" 이러면서 제로보드 게시판까지 같이 붙어 있는 사이트일 가능성이 높을 것이다.
세월이 참 많이도 흘렀다. 플래시, 제로보드, Visual Basic 6, 재래식 hlp.. 이런 것들이 역사 속으로 사라졌다.

5. 마이너한 검색들

일반적으로 널리 쓰이는 기능은 아닐 테니 유료 서비스 형태로 제공되더라도..

(1) 많고 많은 웹툰들은 그림 파일뿐만 아니라 말풍선 안의 대사들도 색인화돼서 대사로 해당 컷의 검색이 됐으면 좋겠다.
짤방으로 써먹고 싶은데 그 그림이 긴 웹툰 시리즈의 어느 화에 있었는지 기억을 못 할 때가 많다.
물론 "이 학교의 주인은 이사장인 나예요."(사립정글고), "네놈을 살려 두긴 쌀이 아까워!"(이말년), "선 넘네"(엉덩국 애기공룡 둘리) 같은 거야 너무 강렬하고 유명하니 일반 검색 엔진으로도 대사와 컷 이미지가 개념적으로 연결돼 버렸지만.. 그렇지 않은 컷도 많다.

(2) 주선율 음표 표기로 음악 검색. 밖에서 재생되는 음원을 들려줘서 비슷한 음반의 노래를 찾는 건 이미 서비스 되는 게 있지만.. 그건 음원이 없고 사람의 오랜 기억 속에만 존재하는 음악을 찾아 주지는 못한다. 내가 말하는 건 음악들의 주선율 악보를 색인화해서 검색하는 것이다. 다만, 이걸로 검색하려면 사용자도 최소한의 채보· 기보 능력이 있어야 한다.

검색 엔진이란 게 처음에는 같은 웹에서 텍스트 위주로만 검색을 지원했다. 그러나 요즘은 웹뿐만 아니라 종이책, 잡지, 옛 신문들과 방송 자료, 논문 같은 오프라인 매체로 범위가 확장되었으며, 정보의 형태도 텍스트에 국한되지 않고 그림과 동영상까지 취급한다.

그러니 이게 앞으로는 텍스트뿐만 아니라 사람이 마우스로 얼추 끄적인 스케치와 비슷하게 생긴 그림이나 실제 로고타입을 찾아 주고, 콩나물 배열만으로 음악을 찾아 주는 경지에 도달하지 않을까 싶다. 그야말로 사람의 기억을 보조해 주는 도구가 되는 것이다. 그리고 국내 웹툰뿐만 아니라 과거의 뉴스 보도, 특히 대한뉴스들도 다 색인화되면 엄청난 도움이 될 것이다.

Posted by 사무엘