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

1. Windows의 컴퓨터 비트 수 변화

과거에 주류 PC 환경이 (1) 16비트에서 32비트로 바뀌면서 소프트웨어 개발 환경이 크게 바뀌었다.
int와 WPARAM, handle, 포인터가 모두 4바이트 크기로 바뀌었고, 이로 인해 메시지도 몇몇은 스펙이 불가피하게 바뀌었다.
좌표계의 기본 단위도 다들 32비트로 확장됐고, 이로 인해 GDI 함수들이 상당수가 Ex 버전으로 바뀌었다. 왜냐하면 예전처럼 x, y 좌표 둘을 long 하나에다 묶어서 전달할 수가 없어졌기 때문이다.

하지만 선점형 멀티스레드가 지원되고 그 전에 모든 프로세스들이 자기만의 독립된 주소 공간을 갖는다는 건.. 과거엔 정말 상상도 못 할 혜택이다.
8비트야 거의 임베디드 급의 열악한 환경이니 멀티태스킹 따위는 별나라 얘기였다. 16비트 시절엔.. 어정쩡하게 아주 불편하고 힘들게 가능했던 반면.. 32비트가 되니 주소 공간도 넉넉하고 이제 좀 그럭저럭 할 만해진 것이다.

그리고 32비트에 와서는 예전에 깐깐하게 구분해야 했던 게 이제는 구분이 필요 없어지고(예: HINSTANCE vs HMODULE, far vs near), 예전에는 꼭 할당하고 해제해 줘야 했던 게 지금은 그럴 필요가 없는 등(resource 관련 API, MAKEPROC 따위).. 프로그래밍 하기가 전반적으로 더 간편해지고 편리해지기도 했다.

그에 비해 (2) 32비트에서 64비트로의 변화는 뭐.. int와 포인터의 크기가 달라진 것으로 인한 자잘한 충돌과 이식성 문제가 고작이다. 4GB 한계가 없어지기만 했을 뿐, 체감되는 변화는 아주 미미하다.
Windows의 경우, int는 물론 long조차도 여전히 32비트 크기로 유지된다. 그러나 WPARAM은 64비트로 확장됐다.

전에도 한번 얘기했듯이 게임기는 1990년대 후반, PC는 2000년대 후반, 스마트폰은 2010년대 후반이 돼서야 슬슬 64비트 시대에 들어섰다.
이런 곳은 비트 수가 점진적으로 늘어났기 때문에 기존 코드와의 호환성이 중요했다. 그렇기 때문에 포인터만 빼고 int나 long은 4바이트로 할지 8바이트로 할지 고민이 많은 편이었다.

그 반면.. 슈퍼컴퓨터 전용 아키텍처가 있던 시절 말이다. 197, 80년대에 처음부터 64비트로 시작했던 컴터 환경에서는 레거시 고민 따위 없었다. Cray 같은 플랫폼에서는 쿨하게 처음부터 int고 포인터고 몽땅 다 무식하게 64비트 모델을 채용한 곳도 있었다고 한다. 물론 오늘날이야 int까지 8바이트인 컴퓨팅 환경은 없다고 봐도 되지만..
그리고 저런 옛날 컴퓨터들은 데이터를 취급하고 연산하는 단위만 64비트였다. 아무리 슈퍼컴이라 해도 자기네 메모리 용량이 4GB에 미치지는 못했기 때문에 64비트 컴퓨팅이 곧 64비트 addressing을 의미하지는 않았다고 한다. addressing까지 다 되는 64비트 CPU는 1990년대가 돼서야 등장했다. (MIPS, DEC Alpha 따위) 아하~

얘기가 좀 옆길로 샜는데.. 아무튼 Windows는 16비트에서 32비트로 넘어갈 때 변화가 좀 있었고, 32에서 64비트로의 변화는 미미한 편이었다. 그럼 Windows의 역사상 16비트에서 32비트로의 전환만이 대격변이었던 것일까?
꼭 그렇지는 않았다. 오히려 더 옛날, (3) Windows 1 (+2)과 3 사이는 플랫폼 SDK의 변화, C 컴파일러의 변화 등의 단절이 더 심했다.

Windows 1과 2는 아직도 리얼 모드 내지 끽해야 286 표준 모드에서 멀티태스킹을 구현하던 정말 암울한 시절이다.
Windows의 오랜 역사를 좀 아는 guru라면, 20세기에 Windows에서 가장 혁신적인 변화는 바로 95나 NT도 아니고 3.0에서 "386 확장(enhanced) 모드"가 정식 도입되었던 사건이라고 말할 정도이다. (☞ 링크)

그랬기 때문에 Windows 1과 3은 같은 16비트 기계어에 같은 NE 포맷임에도 불구하고 1용 프로그램이 후대의 3 내지 9x에서 제대로 실행되지 않을 가능성이 매우 높았다.
게다가 저 1980년대의 구닥다리 C 컴파일러는 함수를 정의하는 문법조차 ANSI가 아닌 기괴한 K&R 방식이었다니.. 소스 레벨의 호환성도 기대하기 어렵겠다. 더 자세한 건 여기 글을 참고하시라. (☞ 링크)

2. 마소의 16비트 P-code 기술

마소와 관련된 옛날 이야기가 계속 이어진다. 이 블로그에서 본인이 지금까지 이 얘기를 한 번도 꺼낸 적이 없었다니 놀랍다.;;
네이티브 기계어가 아니라 다른 중립적인 바이트코드 기반으로 돌아가는 '가상 기계 프로그램'이라 하면 흔히 Java (JVM)나 C# (.NET, CLR) 같은 것만 떠올리기 쉽다. 이런 건 최소 32비트 이상의 컴퓨팅 환경에서 등장한 런타임 환경이다. 고유한 클래스 라이브러리도 갖고 있고 쓰레기 수집기도 제공한다.

하지만 마소는 창립하자마자 그 허접한 197, 80년대 8비트 컴퓨터로 제일 먼저 만들었던 게 BASIC 인터프리터였다. 현대적인 가상 머신 정도로 거창하지는 않지만, 그래도 고유한 바이트코드 가상머신 기술을 보유해서 16비트 컴퓨팅 시대까지 잘 써먹었다.

마소에서는 그 바이트코드를 스스로 P-code라고 불렀다. P는 pseudo-, portable, packed(조밀) 등을 뜻했다고 한다. 그리고 그걸 Basic뿐만 아니라 C/C++ 언어 컴파일러에다가도 접목했었다. 아니, 베이식은 그렇다 치지만 기계어 직통 컴파일이 당연시되는 언어이던 C/C++에다가는 성능(= 실행 속도) 희생까지 감수하면서 도대체 왜..?

이 바이트코드는 크기가 작았기 때문이다. 이게 packed의 의미이다.
같은 프로그램 소스를 비슷한 최적화 수준으로 컴파일 했을 때, 네이티브 x86 기계어 코드보다 훨씬 더 작은 크기로 표현할 수 있었다. 심지어 P-code를 해독하는 가상머신 코드의 오버헤드(9K 남짓?)를 포함시키더라도 수지맞는 장사였을 정도라니.. 이건 뭐 실행 파일 압축 기능까지 약간이나마 겸한 셈이었다.

컴퓨터 역사의 관점에서 볼 때 x86 자체도 골수 CISC 구조로서, 현대적인 아키텍처 대비 기계어 코드가 조밀하고 크기가 아주 작은 축에 드는 아키텍처라고 여겨진다. (그 대신 읽어들이고 디코딩하는 난이도가 쥐약이고, 저전력 모바일과 상극)
그런데 마소의 P-code는 그 악명 높던 x86 기계어보다도 더 조밀하고 작다니.. 그 시절에 얼마나 메모리가 비싸고 귀했고 메모리를 어떻게든 아껴야 했는지가 실감이 간다. PC에서도 386 486 같은 32비트 CPU는 진작에 등장하고 값도 내려갔지만.. 메모리가 아직 병목이었다. 이게 더 싸지고 풍부해진 뒤에야 본격적으로 Windows 95/NT가 쓰일 수 있었다.

Visual Basic이야 exe를 생성한다 해도 런타임 dll이 따로 필요하고 내부 코드는 P-code 기반이었다. 1997년에 출시된 5.0.. 최초로 32비트 전용으로 출시된 이 버전에 이르러서야 네이티브 코드 컴파일 기능이 도입됐다.
C/C++의 경우, MS C/C++ 7.0과 Visual C++ 1.x 시절.. 16비트 한정으로 이런 기능이 있다가 32비트부터는 폐기됐다. 그 대신, 16비트이기만 하면 플랫폼은 DOS와 Windows를 모두 지원했다.

따지고 보면 Windows NT의 32비트 PE (portable executable)는 저런 P-code와는 접점이 없었던 셈이다. 32비트 Visual Basic 5나 6을 쓰지 않는 한 말이다
자세한 것은 이 링크의 설명을 참고하시라. 마소의 전설적인 P-code에 대해서 구체적으로 소개한 글은 "Microsoft P-Code Technology" by Andy Padawer이 유일한 것 같다.

QuickBasic이나 GWBASIC은 소스 코드를 고유한 바이너리 포맷으로 저장하는 기능이 있었다. 이건 세상 그 어느 프로그램 개발 환경에서도 없는 기능이었지 싶다.
그 반면, 저 P-code는 소스 코드가 아니라 나름 기계어를 표방하고 컴파일된 코드였다는 차이가 있다.

3. 마소와 볼랜드 프로그래밍 툴의 Windows 지원 내력

(1) 아마 예전에 이 얘기를 한 적이 있었을 텐데..
1980년대 말부터 마소와 볼랜드에서는 주요 프로그래밍/개발툴을 내놓으면서 뭔가 교육용 저가 보급형 제품군에다가는 각각 Quick과 Turbo라는 스피디한 브랜드명을 붙였고, 기업용 기함급 모델에다가는 그냥 자기 회사 이름을 붙였었다.

(2) 1990년대 초엔 C 컴파일러에는 C++의 지원이 추가되었다. 그래서 지원 언어 표기가 C/C++이라고 바뀌었다.
마소의 경우, QuickC는 Microsoft C를 먼저 만들다가 곁다리로 병행하며 잠깐 만들었던 제품이다. 이건 C++ 지원 없이 겨우 2.0에서 맥이 끊겼다. 그 대신 이전부터 만들어 오던 MS C 6의 다음 버전이 MS C/C++ 7이 되었다(1992). 그리고 이거 다음 버전부터는 그 이름도 찬란한 Visual 브랜드가 시작됐고, C는 떼어낸 채 Visual C++ 1로 넘어갔다.

저 때는 1993년 무렵이었다. Visual C++은 Windows NT와도 역사를 함께한다. 이게 마소에서 최초로 내놓은 32비트 C/C++ 컴파일러이며, Windows NT 내부의 각종 프로그램들을 빌드하는 용도로, 즉 자체적으로도 쓰였기 때문이다.
물론 Visual C++도 1.5까지는 16비트 버전이 같이 나오긴 했었다. 그리고 대외적인 버전 번호는 1로 리셋됐지만 얘 역시 MS C를 계승한 제품이라는 흔적은 MSC_VER이던가 그 매크로 상수의 번호에 남아 있다.

(3) 한편, 볼랜드 진영에서는 Turbo C 2.0의 다음 작품이 Turbo C++ 1.0이 되었다. 제품명과 버전이 다 리셋됐다니 좀 이례적이다.
그리고 그 다음 버전인 Turbo C++ 2때부터 같은 버전의 Borland C++도 나란히 나오기 시작했다고는 하는데.. 실질적으로 Turbo와 Borland의 구분이 생겼다고 일반인들이 존재감을 인지하는 첫 버전은 3이다.
Turbo C++은 3인가 3.1에서 맥이 끊겼다. 그 뒤 적어도 4~5 버전부터는 Borland C++만 나오다가 RAD 툴인 C++ Builder 1로 넘어갔다.

(4) 그 시절 C/C++ 컴파일러 업계에서는 C++ 지원뿐만 아니라 Windows 플랫폼의 지원도 중요한 이슈였다.
마소는 DOS에 이어 Windows를 만들던 본가였고, C는 어셈블리어와 더불어 자기들 제품을 만들 때 사용되는 주력 언어이기도 했다. 그러니 MS C는 처음부터 Windows를 지원하는 게 너무 당연한 일이었다.

1980년대 중반, 정말 구닥다리 MS C 4~5 시절부터.. 그야말로 전설적인 Windows 1.x, 2.x 프로그램을 만들 수 있었다. 단, QuickC는 DOS용 버전 2.x대와 별개로 QuickC for Windows 1.0이 딱 한 번만 나오고 말았던 듯하다. 요컨대 마소는 QuickC의 Windows 버전만이 버전 리셋을 했고, 볼랜드는 C++ 컴파일러를 구현할 때 버전 리셋을 했다.

그에 비해 볼랜드 제품에서 Windows 지원이 추가된 건 버전 3.x부터로, C++까지 지원되고 난 이후의 일이다. 심지어 Win32의 지원은 Windows 95가 출시되고 4.x 정도는 된 뒤부터다. 후발주자 3rd-party 업체이니 이런 것 수용은 한 발 늦을 수 있다지만.. Windows용 32비트 extender까지 미리 만들었던 Watcom 같은 업체하고는 개발 방향이 많이 달랐던 것 같다. 그 대신 볼랜드에서는 OWL이라고 꽤 잘 만든 객체지향 프레임워크를 연구 개발했다.
이렇듯, Windows 지원과 관련해서는 볼랜드와 마소 개발툴 간에 이런 내력의 차이가 있었던 셈이다.

(5) 자, 그럼 C/C++ 다음으로 파스칼의 세계로 가면..
볼랜드에서 Turbo Pascal을 내놓으면서 1980년대를 호령하고 재미를 봤다. 도스 아니면 기껏해야 OS/2에서 말이다. 그러다가 1990년대 초, Turbo Pascal 6 타이밍 때 TP for Windows를 1.0과 1.5 두 차례 내놓았다. 아마 5.x던가 6이던가..
이때 ObjectPascal이라는 객체지향 문법이 언어에 도입되기도 했지만 이건 TP의 버전에 영향을 주지 않았다. 그 대신 Windows용을 1.0부터 다시 내놓았다는 점이 Turbo C++과는 다르다.

그러다가 Turbo Pascal 버전 7이 Borland Pascal 7과 나란히 출시됐으며.. 이 BP7은 TP for Windows 2를 통합· 포함한 형태가 됐다. 제품 라인업 한번 복잡하네..;;
TPW는 about 대화상자에 수학자 파스칼 얼굴이 그려져 있는 반면, BPW는 그렇지 않다는 차이가 있다.;;;

1992년에 출시된 Borland C++ 3.1, 그리고 Borland Pascal 7이 도스와 Win16을 풍미했던 장수만세 안정판으로 여겨진다.
Borland C++은 C++ Builder로 넘어가기 전 1993~1995년 사이에 자체적으로 버전이 4~5까지 올라가기도 한 반면, BP는 델파이로 넘어가기 전에 딱히 버전업이 없었다.
심지어 Delphi도 1995년의 첫 버전 1은 Win16, 16비트용이었고 버전 2부터 Win32로 넘어갔으니, 32비트화도 C++보다 늦은 셈이다.

한편, 마소는?? 처음에 Microsoft Pascal을 1980년대에 4.x 버전까지 개발했었다. 하지만 이건 Turbo Pascal과의 경쟁에서 승산이 없다고 판단했는지 접었다. 그렇게 접기 직전에 경쟁사 제품처럼 뽀대나는 IDE를 얹은 QuickPascal 1.0을 최후의 발악 차원에서 한번 내놓았을 뿐이다. Windows 지원 같은 것도 당연히 없었고 제품의 맥이 끊겼다.
볼랜드에서는 Turbo Basic을 만들었다가 반대로 마소의 QuickBasic 대비 승산이 없다고 생각해서 포기해 버렸으니.. 행보가 서로 정반대인 셈이다.

Posted by 사무엘

1. 단품 판매되는 DOS

(1) 197, 80년대에는 컴 단말기가 아니라 개인용 컴퓨터라는 건 이제 막 정립되고 있었고, 소프트웨어도 하드웨어와 함께 딸려 나오는 게 아니라 독립된 제품이라는 인식이 이제 막 정립되던 중이었다.
그래서.. 마소에서 만들었던 MS-DOS도 말이다. 1.0부터 4.x에 이르기까지는 다들 PC와 함께 OEM 형태로만 공급됐다. 도스 자체가 단품 패키지로 개별 소비자에게 retail 판매되기 시작한 건 1991년, 무려 5.0부터였다고 한다. himem.sys와 DOS=HIGH가 첫 도입됐던 그 역사적인 물건 말이다.

아 글쎄.. Windows 1.x 시절이던 1986년에 3.2 버전도 단품 패키지가 있긴 했다. 하지만 이때는 이 방식이 오래 지속되지는 못한 듯하다.

현실적으로 대다수 사용자들이 패키지 판매를 기억하는 건 아무래도 끝물인 6.x버전이지 싶다. 이 무렵에 마소는 IBM과 사이가 단단히 틀어져서 PC-DOS와 MS-DOS의 격차도 벌어지고, Windows와 OS/2도 격차가 벌어졌었다.
1990년대 들어서 MS-DOS는 이렇게 독립을 했는데, 매크로 어셈블러(Macro Assembler)는 그 무렵쯤에 반대의 길을 갔다. 단독 독립 제품으로서는 단종이고, MS C/C++이나 Visual Studio 같은 더 큰 제품에서 제공되는 유틸리티로 흡수되었다.

(2) MS-DOS가 대기업의 PC와 함께 공급되던 시절, 대략 쌍팔년도 정도까지는 한글 MS-DOS에 내장돼 있던 한글 바이오스도 PC 제조사들별로 제각각이었다.

• PC 제조사: 대우, 금성, 현대, 삼보 등
• 제3자 써드파티: 도깨비, 한메, 태백 등
• 마소 자체 개발: hbios, mshbios. Windows 3.1 + MS-DOS 6부터.

한글 바이오스 만드는 게 첨단 시스템 프로그래밍이던 시절이 있었다니.. 추억 돋는다. =_=;;
기능이 제일 많고 성능도 뛰어나던 건 역시 써드파티 제품들이었다. 조합형도 지원하고, 다양한 폰트와 글자판(세벌식까지)도 지원했지만.. 역시 1990년대 중후반쯤부터는 개발의 맥이 끊겼다.
현재 한글 바이오스가 돌아가는 중인지를 무슨 API를 호출해서 어떻게 판별했는지 궁금하다.

(3) MS-DOS는 버전 1부터 4까지는 OEM이었고 5~6 사이에 잠깐 독립 제품.. 그리고 마지막 7~8 버전은 Windows 9x에 포함된 채로 제공.. 이렇게 역사가 정리된다.
그 중에 OEM 끝자락이던 MS-DOS 4는 DOS shell이 처음 도입되었고 FAT16 파일 시스템의 개편으로 하드디스크 용량을 2GB까지 인식할 수 있게 하는 큰 변화가 있었다(종전에는 꼴랑 32MB까지만.. =_=) 하지만 4.0은 버그가 너무 많아서 곧 4.01로 패치가 돼야 했다.

이건 마치 버그가 너무 많아서 온갖 서비스 팩들이 덕지덕지 나와야 했던 Windows NT 4의 행로와도 비슷해 보인다.
그리고 개발툴 중엔 Visual Studio .NET 첫 버전(2002, 7.0)이 금세 묻혀 버렸던 것과도 처지가 비슷하다.

(4) 끝으로.. MS-DOS의 대체품으로 DR-DOS라는 게 있기도 했고, 그걸 한때 네트워크 솔루션으로 유명했던 어느 기업에서 인수하여 노벨 도스로 계승되었다.
한편, MS-DOS의 셸만 대체해서 강화한 제품으로 4DOS라는 게 있었다. 그걸 노턴 유틸리티에서 인수해서 더 발전시킨 게 NDOS...이다. 노벨 도스와 이니셜이 같지만 이들은 서로 다른 제품이다.

2. Rational

옛날에 Rational이라는 이름을 가진 컴퓨터 소프트웨어 회사가 둘 있었다.

(1) Rational Software는 소프트웨어공학 툴이라고 해야 하나.. 딱 정확하게 개발툴, IDE나 컴파일러는 아니지만 어쨌든 소프트웨어 설계· 개발과 관련이 있는 전문 도구를 개발해 왔다. 콕 집어 코딩, 프로그래밍이라기보다는.. 더 거시적인 소프트웨어 개발 말이다.
Rose라는 툴이 유명했다. 꽃하고는 별 관련 없고, 다른 단어들의 이니셜이 저렇게 된 거지 싶다. 내 기억으로 Visual C++ 6 시절에 엔터프라이즈 에디션에는 Rose의 데모 축소판이 번들로 제공됐던 적이 있었다.

얘의 제조사는 2003년에 IBM에 인수됐다. IBM이 PC용으로 소프트웨어를 만든 게 지금은 망한 운영체제 OS/2, 그리고 유구한 역사를 자랑하는 통계 패키지 SPSS 정도밖에 없는 줄 알았는데.. 지금은 Rose도 IBM 휘하로 넘어갔는가 보다.
하긴, 엑셀에 대항하여 넥셀이 있고, AutoCAD에 대항하여 캐디안이 있는 것처럼.. Rose의 저렴한 국산 대체제로 StarUML이라는 제품도 있다.

개인적으로는 직장에서 보고서 쓸 때 각종 UML 다이어그램 그리는 용도로 사용해 봤다.;; 클래스 관계 모식도라든가 각종 시퀀스 다이어그램 따위..
하긴, 그 비싼 프로그램에 겨우 다이어그램을 그리는 기능밖에 없으면 그냥 Visio 같은 벡터 드로잉 툴과 아무 차이가 없을 것이다. 그럴 리는 없고, 여기서 만든 설명대로 Java 클래스 파일을 생성하고 문서를 생성하는 기능도 있었던 걸로 기억한다.

(2) 그 다음으로 Rational Systems라는 곳이 있었다. 얘는 1980년대부터 DOS extender만 전문으로 개발해 왔다. 16비트에 640KB 메모리에 쩔어 있던 도스 환경에서 보호 모드를 구현하고, 메모리를 골치 아픈 제약 없이 32비트 그대로 접근하게 해 주는 획기적인 런타임 말이다.

사실, DOS extender라는 걸 처음으로 개척한 회사는 Phar Lap이었다. 워크스테이션에서나 돌릴 만한 거대한 업무용 프로그램을 PC용으로 포팅할 때 원래 Phar Lap의 extender가 주로 쓰였다. 옛날에 도스용 아래아한글도 전문용 내지 32비트 에디션은 얘를 사용했다.

그러나 Rational Systems에서는 DOS/4G라는 제품을 개발하고, 이걸 Watcom C/C++ 컴파일러에 DOS/4GW라는 번들 버전으로 아주 저렴하게 공급해 줬다. 1993년 말에 Doom이라는 게임이 딱 이 솔루션을 사용해서 출시되면서 DOS/4GW라는 32비트 extender는 세계적인 히트를 치게 됐다.

환상적인 그래픽을 선보였던 Doom이 어셈블리어를 거의 쓰지 않고 이식성 높은 C 코딩으로만 구현될 수 있었던 비결엔 이런 신기술이 있었던 것이다. 물론 그래픽을 제대로 보려면 그 당시로서는(1993~1995) 아직 가격이 부담되는 고성능 컴터이던 486급이 필요했지만 말이다.

그리고 Doom은 이 장르에서 하드웨어 가속이 없이 CPU 연산/소프트웨어만으로 동작한 마지막 게임이기도 했다. ^^ 이렇게만 동작해서는 320*200보다 더 높은 해상도에서 3D 폴리곤 그래픽이 실시간 애니메이션으로 나오기란 굉장히 무리였을 것이다. 뭐, 그래픽의 하드웨어 가속에도 더 높은 데이터 대역폭이 필요할 것이고, 32비트 버프가 기여했다고 볼 수 있다.

1990년대 중후반까지 덩치 큰 도스용 게임들은 처음 실행될 때 DOS/4GW 로고가 뜨는 게 무척 많았다. 이게 무슨 흥행 보증수표처럼 느껴질 정도로..;;
PC 역사에 한 획을 그었던 이 개발사는 훗날 Tenberry Software이라고 이름이 바뀌고 2000년대 초반까지는 살아 있었다. 하지만 도스 시절이 끝난 뒤엔 없어졌는지 근황을 모르겠다.

요컨대, 두 Rational들은 분야는 다르지만 과거에 뭔가 비범한 소프트웨어들을 개발하곤 했다. ^^.

3. 옛날에 C++ 코딩 환경

난 왕년에 이런 시퍼런 화면에서 코딩을 해 봤다. -_-;;

쌍팔년도를 넘어서 1990년대가 되자.. 이제 막 C가 아니라 C++ 직통 컴파일러라는 게 처음으로 등장했다. 그리고.. IDE의 텍스트 에디터에 syntax coloring이라는 게 제공되기 시작했다.
코드에서 예약어는 진하게 표시하고, 전처리기는 별도의 색깔로, 상수 리터럴이나 주석도 별도의 색깔로.. 이거 말이다. 하긴, 1990년대는 이제 막 VGA와 컬러 모니터가 보급되었던 시절이고, 286이니 386이니 하던 컴터 성능도 실시간 컬러링을 구현해도 될 정도로 향상됐다.

그 당시 도스용 컴파일러의 본좌는 볼랜드...였는데, Turbo C++ 3.0 버전부터 IDE에서 컬러링이 지원되기 시작했다. 1과 2 시절엔 저런 게 아직 없었다.
오 그런데... 말로만 듣던 Turbo C++와 Borland C++가 차이가 있었나 보다. 난 Turbo C++ 것만 어린 시절에 직접 봤었다.
일반 명칭은 초록색, 문자열 상수는 빨강, 전처리기는 저렇게 청록색 바탕, 기호가 노란색 말이다.

그러나 Borland C++은 보니까 일반 명칭이 노랑, 문자열 상수는 청록, 전처리기가 초록, 기호는 하양이다.
난 도스용 볼랜드 개발툴 IDE에서 C++의 컬러링이 저렇게 되는 건 직접 본 적이 없고, 구글 검색을 통해서 난생 처음 본다. 비슷한 시기에 동일 회사에서 내놓았던 Borland Pascal과 더 비슷해졌다. 우와..

사실, Turbo와 Borland의 차이는 Visual Studio로 치면 standard 에디션(개인용)과 enterprise 에디션(기업용) 같은.. 에디션 급의 차이와 비슷하다.
아.. 옛날에.. 볼랜드 IDE를 따라 djgpp 진영에서 개발했던 rhide는.. C/C++ 코드에 대한 컬러링이 Turbo가 아니라 Borland C++ 스타일이었다. 자, 난 저런 것도 기억하는 세대다. -_-;;;;

프로그래밍, 코딩이라는 건 30년 전이나 지금이나 재미있다.
참고로, 코딩 하다가 .이나 ->를 찍었을 때 멤버가 쫘르륵 나오고 명칭이 자동 완성되는 기능은..
1990년대 "말"이 돼서야 제공되기 시작했다. 그건 그만큼 구현하기 더 어려운 기능이었고, PC가 못해도 펜티엄 2 이상급으로 성능이 좋아진 뒤에나 쓸 만했다.

요즘은 이 기능이 없으면 너무 불편해서 코딩을 못 할 것이다. 옛날에 텍스트 에디터가 불편하고 컴퓨터 메모리가 부족하던 시절에는 각종 함수 명칭을 아주 짧고 암호 같이 붙이는 게 관행이었지만..
지금은 코드 양이 너무 방대해지고 저런 자동 완성 기능도 발달하니 길게 길게 풀어서 써 주는 편이다. setmemmgr() 대신에 SetMemoryManager() 같은 식.

4. PowerBasic

198~90년대에.. BASIC이라는 프로그래밍 언어는 입문하기 간편한 대신, 인터프리터 방식 위주이고 실행 속도가 느리다는 게 상식 겸 통념이었다. 즉, 언제까지나 교육용이지, 실무용은 "영 아니올시다"였다. 그러나 BASIC에 대해 그 통념을 정면으로 도전하고 반박하는 이단아 제품이 있었으니, 바로 PowerBasic(파베)이었다.

얘는 BASIC이라는 언어에다가 C/C++ 같은 이념을 접목했다. 마소처럼 느린 P-code 갖고 깨작거리거나 비주얼 RAD 툴 컨셉을 씌우는 게 아니라, 최적화되고 단독 실행 가능한 네이티브 코드 컴파일을 추구했다. 그렇다, 이 컴파일러 엔진을 만든 주 개발자는 그야말로 x86 어셈블리어에 정통한 smaller, faster 최적화 덕후 장인이었다.

PowerBasic은 마이너 비주류 제품군이지만 나름 존재의 의미는 있었다. 베이식 언어로 C/C++ 급의 작고 빠른 프로그램을 생성해 줬기 때문이다. 자기 자신의 덩치도 Visual Studio에 비하면 그냥 깃털 같은 수준이니 아주 실용적이었다.

얘는 16비트 도스에서 32비트 Windows까지는 잘 갈아탔다. 하지만 그 이후의 시대 변화에는 따라가지 못한 채, 2020년대에 와서는 명줄이 사실상 끝난 상태이다.
일단, 주 개발자인 Bob Zale 할아버지가 별세한 지가 이미 10년이 넘었다. 적절한 후임 개발자를 양성하지 못했는지, 파베는 x64건 arm64건 일단 64비트 버전이 못 나오고 있다.

살상가상으로.. PowerBasic 컴파일러 자체부터가 통짜 어셈블리어=_=;;;로 개발됐고, 코드가 호락호락 maintainance 가능한 구조가 아니라고 한다. 이러면 뭐 과거의 OS/2나 dBASE 같은 꼴 나면서 죽는 건 시간 문제지..
그렇게도 성능에 목숨 걸었다지만, 최신 멀티코어 프로세서나 GPU에 맞춰진 컴퓨팅을 잘 지원한다는 얘기도 난 못 들었다. 이러면 머신러닝 스크립트인 파이썬의 용도를 대체하기도 대략 곤란해진다.

지금 생각하면 PowerBasic이 뭔가 슈퍼컴 Cray 같은 물건이라는 생각도 든다. 고전적인 성능 덕후 장인이 애지중지 만들었지만 시 대에 뒤쳐지고 도태됐다는 점에서 말이다.
글쎄, 쟤는 그 성능빨에다가.. 마소에서 버린 자식인 클래식 Visual Basic 6 코드를 지원하는 후속 써드파티 개발툴을 표방하고 나섰으면.. 마르지 않는 고객 수요를 확보하고 절대로 망할 일이 없었을 것 같은데 말이다. 그렇지 않은가? 이렇게 사라지기에는 아깝고 아쉽다.

쌍팔년도 시절에 볼랜드와 마소가 PC용 베이식, C, 파스칼 컴파일러 시장을 꽉 잡고 있긴 했다. 하지만 그 컴파일러들은 처음부터 그 회사에서 만든 게 아니었다. 다들 다른 사람이나 영세업체의 제품을 인수한 것에서부터 개발을 시작했다.

• BASIC/Z by Bob Zale --> Turbo Basic (요게 PowerBasic의 전신)
• Wizard C by Bob Jervis --> Turbo C 1.0 in 1987
• PolyPascal by Anders Hejlsberg --> Turbo Pascal
• Lattice C --> Microsoft C

Posted by 사무엘

1. 혼을 얻는 자

잠 11:30 he that winneth souls is wise.
통상적으로는 주변 사람들에게서 호의를 얻고 마음을 사서 다들 자기 편으로 만들 줄 아는 사람은 지혜롭다~~ 이런 뜻이다. 그러나 좀 더 영적으로 들어가면 이건 '전도'하는 거.. 복음 전해서 남을 회개시키고 예수 그리스도에게서 이끌어 온다는 뜻이 된다. soul winning.

말씀 보존 학회의 한킹은 저 구절이 동사가 win이라는 이유로 "혼들을 이겨 오는 자"라고 정말 단순무식 투박하게 번역했다. =_=;;
"우리 교회는 거리설교를 통해 매년 수십 명의 혼들을 그리스도께로 이겨 오고 있습니다" 자기들끼리 말도 저렇게 전투적으로 한다. 옛날 개역성경의 "강하고 담대하라"처럼 언어에 대한 비표준 확장이라고 봐야 할지.. ^^

당연한 말이지만 저건 win a prize(상을 탄다/받는다) 할 때의 win이다. 경쟁 상대를 꺾거나 제쳐서 이긴 것은 beat라고 한다.
예전에 언급한 적이 있는 예시이다만, "1994년 올해의 명작 게임이라는 영예를 차지하고(win) 싶은 작품이 있다면 먼저 Doom부터 제쳐야/능가해야(beat) 할 것이다." 이렇게 말이다.

세상을 이기거나 마귀를 이기는 것도 아니고 혼들을 이기는 건 뭘까.. =_=;;
그렇다고 평범하게 get obtain acquire과 아무 차이 없이 얻는다고만 하면 성이 안 차니.. '쟁취'라는 말이 어떨까 하는 생각을 오래 전부터 개인적으로 했다.
오, 근데 유일하게 표준역이 저기서 쟁취라고 번역했구나. 우리말 성경 중에서는 첫 사례인 것 같다.
표준역이 논란이 많은 역본이긴 하지만.. 저기서는 단어를 잘 고른 것 같다.

I am not a prize to be won! 나는 무슨 남자들의 전리품이 아니라구요! (디즈니 알라딘에서 자스민 공주의 대사. Prince Ali 노래가 끝나고 얼마 뒤에..ㄲㄲㄲㄲㄲ)

2. 강하고 담대하라?

우리말 국어에서는 형용사 뒤에 명령문이 바로 오는 게 잘못됐다면서 여호수아의 저 유명한 말 "강하고 담대하라"라든가 예수님의 "진리가 너희를 자유케 하리라"가 비문(문법에 어긋난)이라고 비판이 제기되곤 했다.
그런데 기껏 대안이란 게 훨씬 더 길어지고 장황해지고 거추장스러워진 "마음을 강하게 하라, 담대해져라"이면.. 어떡해야 할까?

그리고.. "내가 거룩하니 너희도 거룩하라" (벧전 1:16) 같은 구절도 있다. 표준어를 준수했다는 최신 우리말 성경들도 이 구절은 거의 건드리지 않고 놔두고 있다.
'거룩하다'도 형용사인데? 동사가 아니기 때문에 '거룩한다'라는 말이 없는 거다. 쉽게 말해 '거북하다'(불편하다)와 완전히 동일한 품사이다.

하지만 '거룩하라'라는 말이 너무 간결하고 잘 와 닿는다. "거룩해져라, 거룩하게 살아라" 이렇게 군더더기를 붙일 필요가 없고, 저걸 그대로 그냥 성경 언어적 허용이라고 정착시키는 게 더 합리적이지 않을까? 난 그렇게 본다.
우리말은 '맞다/틀리다/맞는/알맞은'처럼 근본적으로 형용사와 동사의 경계가 애매한 구석이 있어서 더욱 그러하다.

새로 번역되는 우리말 성경은 현행 언어 규범을 가능한 한 따를 필요가 있다. 그러나 거기에만 절대적으로 얽매일 필요는 없을 것 같다.
오히려 한킹은 흠정역 같은 후대의 역본 대비, 개역성경 스타일의 간결함이 있어서 더 잘 읽히는 게 아닌가 하는 생각이 들기도 한다. "예수님께서 말씀하시되"보다 "예수께서 가라사대"가 더 간결한 것처럼 말이다.;;

그리고 울나라 헌법도 생각해 보자. 1987년 개헌 이후에 맞춤법이 개정되는 바람에 지금 관점에서 맞춤법에 어긋난 문장(..."투표에 붙이다")이 생겨 있다. 하지만 그렇다고 헌법을 호락호락 또 수정하지는 않는다. 그건 개헌이라는 엄청난 과업이 되어 버리며, 헌법에는 무슨 위키백과 같은 '사소한 수정'이라는 것도 존재하지 않기 때문이다. 헌법이 그러한데 하물며 성경 본문에도 그런 정도의 권위와 무게감이 있어야하지 않겠나 싶다.

3. help meet for him

한국어 '맞다'뿐만 아니라 영어에도 드물게 형용사-동사 품사통용이 있는 것 같다. 대표적으로 meet.
옛날 영어에서는 '만나다'가 뭔가 '만족시키다, 충족시키다' it meets the requirement으로 확장되고, 그게 '-에 적합한, 알맞은'이라는 형용사로 더 확장된 듯하다.

그게 바로 창세기 2:18에서 아담을 위한 합당한 조력자(help meet for him)라고 번역되었다. meet는 형용사이므로 "help meet - for him"이 아니라 "help - meet for him"이라고 끊는 게 바람직하겠다.

근데 저 문맥에서 조력자란 곧 '배우자'이지 않은가?
이게 얼마나 임팩트가 컸으면 helpmeet라는 한 단어가 생겨서 배필, 배우자라는 뜻이 됐고.. helpmate라는 말까지 파생돼 나왔다. 이거는 마치 비키니에서 모노키니가 나온 것처럼, 어원상 관계는 없지만(meet ≠ mate) 걍 비슷한 조어가 튀어나온 것으로 보인다.

즉, help가 먼저이고 helpmeet는 후대의 해석 내지 파생 의미이다. 그러니 성경 번역을 helpmeet로 미리 할 필요는 없을 것 같다. 조력자/도우미가 1차 의미이기 때문이다.

그나저나 help는 굳이 helper이라고 하지 않아도 help만으로 어느 정도 '도와주는 사람'이라는 뜻이 얼추 들어있는가 보다. 물론 반대로 helper이라고 해서 굳이 사람일 필요가 없고 사물, 기계가 모두 가능하다.
게다가 help me라고 외치면 "사람 살려!!"가 되니.. help가 생각보다 인간적인 단어인 것 같다.

4. God forbid? The LORD forbid?

성경에는 그냥 No를 넘어서 천부당만부당, Absolutely not이나 May it never be 같은 강한 부정을 나타내는 관용구가 있다. 킹 제임스 성경은 이를 God forbid라고 번역했다.
성경에서 이 표현을 제일 많이 사용한 책은 로마서이다. "그럼 그렇다고 우리가 이렇게 하리? ㄴㄴ 절대 그럴 수 없음" 이런 패턴으로 말이다.

그래서 킹 제임스 진영에서는 이 구절에 대해 "반드시 God을 살려서 '하나님이 금하시리'라고 번역해야 한다" vs "아니다, 저기서 God은 원어에도 없는 그냥 영어의 관용 어휘일 뿐이다~ 저거 한 덩어리 전체가 '절대 안 됨'이라는 뜻이다" 갖고 치고 받고 싸우는 일이 많다.
본인은 이런 소모적인 논쟁에 진지하게 가담하고 싶지는 않다. 다만, 이 문제에 대해 뭔가 가타부타 의견을 내려면 다음 경우도 생각해서 일관되게 적용 가능한 답을 제시해야 한다는 점을 지적하고자 한다.

(1) 성경엔 God forbid뿐만 아니라 God save the king (국왕 폐하 만세 vs 하나님이 울 국왕을 보우하시리)라든가 God speed (축복 인사. 요즘으로 치면 God bless you에 가까운..)도 있다는 걸 감안해야 한다. 전자는 구약 성경 역사서에서 두루두루 나오는 편이지만, 후자는 요한이서에서만 딱 두 번 등장하는 희귀 관용구이다.

(2) 짤막한 God forbid 감탄사뿐만 아니라 "God forbid that ..." 이런 문장도 있다. 창세기 44장에서 요셉의 형들이 "저희가 감히 파라오님의 술잔을 훔쳐 가다니요~ 저흰 절대 그러지 않았습니다" 이럴 때 최초로 이 문장이 쓰였다. God forbid를 '하나님이 금하시리라'라고 옮기려면 창 44:7이나 창 44:17도 그렇게 옮길 수 있겠는지를 따져 봐야 한다.

(3) 그리고 끝으로.. 성경엔 God forbid만 있는 게 아니라 the LORD forbid도 구약에 있다. "주가 금하신다"..이고, 개역성경 용어로는 "여호와가 금하신다"이다. 단, 이건 단독 감탄사는 아니고 문장 형태만 있다.
삼상 24:6, 26:11에서 다윗이 사울 왕을 해코지할 수 없다고, 하나님이 기름 부으신 사람에게 내가 감히 손을 댄다니~~~ "절대 그리할 수 없다"라고 말할 때 쓰였다.
그리고 왕상 21:3에서 나봇이 아합 왕에게 조상 대대로 살아 온 땅을 처분한다니 절대 그럴 수 없다고 말할 때도 이 표현이 쓰였다.

내가 궁금한 건.. 우리말 성경들이 God forbid의 문장형은.. "결코 그럴 수 없다"라고 옮긴 반면, The LORD forbid의 문장형은.. "주께서 금하신다"라고 옮겼다는 것이다. 개역성경 이래로 표킹을 제외한 킹 계열 역본들이 모두 동일하다. (표준역은 '하나님이 금하신다'를 첫 시도했음)

이렇게 LORD forbid와 God forbid의 번역이 달라질 만한 이유가 원어 차원에서나 다른 이유로 인해 있는지 개인적으로 궁금하다.

하긴, 우리말에도 딱히 하나님을 진심으로 의식하지 않는 "하나님맙소사" 이런 말도 있고, 영어 Good-bye도 god be with you에서 유래되기는 했다고 들었다. 재채기 인사인 Bless you도 그렇고..
그리고 예전에 영국에서 찰스 3세 국왕이 즉위했을 때 국가적으로 참 오랜만에 God save the king 인사가 울려퍼졌고.. 그게 자막에서는 우리말 애국가 가사 "하나(느)님이 보우하사"처럼 번역돼 나갔었다. 흥미로운 일이다.

사실 지금이야 우리말 '만세'는 hooray banzai-_-라는 평범한 감탄사로 많이 쓰이지만, 원래는 국왕의 '만수무강'을 기원할 때만 쓰이는 아주 존귀한 단어였다고 한다. 오죽했으면 그 만세를 국왕 폐하가 아니라 자기 나라에다가 끌어다 쓴 삼일 운동이 정말 파격적이고 민주적인 발상이었으니 말이다.
이를 감안하면 God save the king을 "국왕 폐하 만세"라고 옮긴 건 더욱 적절한 용례인 것 같다. 영어의 God이 우리말의 만세에 대응하는 거나 마찬가지이기 때문이다.

5. 하루살이를 걸러내나, 모기에 긴장하나

성경의 마 23:24는 대략 "이 눈깔이 썩은 가이드놈들아. 니들은 하루살이는 걸러내면서 낙타는 잘도 꿀꺽하네?" 이런 의미의 책망 구절이다. ㄲㄲㄲㄲㄲ
개념적으로 "달면 삼키고 쓰면 뱉는다" 같은 구조이다. 그리고 본질적이지 않은 디테일에는 왕창 목숨 걸면서 진짜 큰 잘못은 슬쩍 답습하고 넘기는 부조리가 잘못됐다는 뜻이다.

저 구절에서 후반부, 낙타를 삼킨다는 말은 지구상의 모든 성경 역본들 간에 이견이 없다.
하지만 전반부, strain at a gnat은 역본마다 번역이 좀 갈리는 편이다.

먼저 gnat이 하루살이냐 모기냐를 갖고 갈리는데, 이건 이 글에서는 논외로 하겠다.
다음 strain가 진짜 문제다. "힘주다, 끙끙대다, 애쓰다, 신경 곤두세우다"인지 아니면 '걸러내다'인지가 갈린다. 참고로 현대에 strainer라고 하면 주방에서 쓰이는 걸러내는 동그란 체를 뜻한다.

거의 모든 성경들.. 심지어 킹 계열이라는 한킹, 근본역 표준역까지 다 "하루살이/모기를 걸러낸다"라고 옮겼다. 비킹과 다를 바 없다.
하지만 딱 하나.. 흠정역만이 유일하게 "모기에 긴장하고"라고 옮겼다. 뭐, 이것도 '대언'과 마찬가지로 안티오크 권위역에서 처음으로 유래된 번역이다.

서로 자기 번역이 맞다고 스트롱 성구 사전이 어떻고 웹스터 영영사전이 어떻고 심지어 원어 사전이 어떻고 막 떠드는데, 내가 이 문제를 접근하는 방식은 이렇다.

strain out도 아니고 strain at이라면
뭔가를 '걸러 내는(out)' 것보다는 '-에(at) 신경이 곤두선다, 긴장한다'라는 의미가 더 강하게 느껴지는 게 사실이다. 흠정역 측의 견해에 일면 동의한다.

하지만, 다만, 그럼에도 불구하고.. 생각해 보자.
모기한테 왜 긴장하는데? 왜 눈 부릅뜨고 신경을 곤두세우고 난리인데?

모기가 무서워서 긴장할 리는 없다. 쬐끄맣지만 성가신 놈이 있으니까, 잡으려고, 걸러내려고 저러는 거다.
불 끄고 침대에 누웠는데.. 짜증나는 앵앵~ 소리가 들릴 때.
잡가시가 왕창 많은 생선살을 씹어먹으려 할 때.. 그 심정 말이다. =_=;;

이런 차원에서 "모기한테는 긴장하고"라는 말이 결국은 "모기를 걸러내고"라는 말과 다를 바 없다고 여겨진다.
'긴장하고'는 표면적인 동작이고, '걸러내고'는 본질적인 의미이다.
"선물은 넙죽넙죽 받으면서"라는 의미를 "선물만 보면 입 헤 벌리면서", "선물만 있으면 손 잘도 내밀면서"라고 표현한 것과 비슷하다는 것이다. 오키?

피터 럭크만이 저기서 at은 out이라는 뜻과 다를 바 없다고 얘기까지 했다는데.. 당연히 문법적으로야 at이 on도 아니고 어떻게 out이랑 같을 수 있냐? 저 구절에 한해서 화용론적으로 동치라는 뜻일 것이다.

그러니 킹의 영어 표현을 존중해서 "모기에 긴장하고"라고 번역을 하려거들랑, 여기 긴장이 최소한 무서워서 쫄아서 긴장한다는 뜻은 아니라고 옆의 성경 교사가 보충 설명을 하면 좋을 것 같다. 저 표현이 '걸러낸다'라는 의미와 별개가 아니기 때문이다.
차라리 두 동작을 합쳐서 "기를 쓰고/눈 부릅뜨고 걸러내면서" 이렇게 표현하는 것도 괜찮을 수 있겠다. win을 "쟁취하다"(이겨서 얻음)라고 표현하는 것처럼 말이다.

사실은 한킹이 영어 킹 제임스 성경을 번역한 게 아니라고 비판받는 다른 여러 표현들도 이런 식으로 해명이 가능하다.
작은 숲(외형) vs 아세라(정체, 실체)라든가, 생활방식 vs 시민권 따위 말이다. 결국은 같은 뜻이다.
차라리 의역이 지나치다고(?) 비판할지언정, 최소한 오역이나 변개는 아니다.

Posted by 사무엘

날개셋 한글 입력기의 다음 버전이 일단은 다음 달 4월 하순쯤에 나올 예정이다. 버전이 10.9가 되었으면 좋겠지만 현실적으로는 무리=_=;;이고, 아마 10.8이 될 가능성이 높다.
타자연습도 오랜만에 버전업 해서 4.0을 만들고 싶은데 얘는 또 언제 작업하려나.. ㅠㅠㅠ
아무튼, 현재 작업이 진행된 자랑거리들을 몇 가지 나열하자면 다음과 같다.

1. 외부 모듈: 안정성 개선

날개셋 한글 입력기는 사용자가 입력 설정을 바꿔서 imeconf.dat를 저장해 놓은 게 없는 경우, 마소 한글 IME의 설정 레지스트리 값을 참조하여 동일하게 두벌/세벌 설정을 세팅해서 동작한다.
그 레지스트리 주소는 운영체제의 버전에 따라 다를 수 있기 때문에 일종의 탐색 알고리즘을 거쳐서 결정된다.

그런데 그 로직에 심각한 버그가 있었다. 그것도 꽤 오랫동안 존재해 왔다.
한번 구한 주소값을 저장해 놓는다는 것이.. 지역변수 버퍼의 주소를 static 변수에다가 저장해 버리고는 계속 써먹는 병크가 벌어졌다.

이 때문에 날개셋 제어판에서 '프로그램 설치 직후 상태'로 팩토리 리셋 명령을 여러 번 내려 보면, 마소 한글 IME로 분명히 세벌식을 사용하고 있음에도 불구하고 제1글자판이(0번) 두벌식으로 지정되곤 했다.
이건 잘못된 메모리 주소를 넘겨준 것이기 때문에 원래는 실행 실패만으로 곱게 넘어가지 않는다. 일부 민감한 환경에서는 프로그램이 뻗을 수도 있다.

오랜 고질병이 있었구나.. 문제를 당장 개선했다.
더구나 외부 모듈은 imeconf.dat가 있더라도 매번 이렇게 디폴트 세팅부터 먼저 했다가 다시 파일 내용으로 세팅을 다시 하는 삽질을 지금까지 하고 있었다.
이를 개선했기 때문에 "메모리 문제 해결", "애초에 문제의 동작 자체를 하지 않게" 이렇게 2중으로 문제를 원천봉쇄 해결했다.

나무위키에 올라와 있던 "Windows 95에서 IE 4~5 + Active desktop을 켠 환경에서 날개셋을 기본 IME로 지정해 놓으면 부팅 과정에서 운영체제가 뻗어 버린다".....;;
이건 내가 직접 확인은 못 해 봤지만, 어쩌면 이 문제도 같이 해결되었을 가능성이 높다.

2. 편집기: ctrl+ins, shift+ins/del 단축키 지원

날개셋 편집기는 1.0 이래로 지난 20여 년 동안, 복사/잘라내기/붙여넣기 기능의 단축키로 Ctrl+C, X, V만을 지원했다. 이들 기능은 Ctrl+Ins, Shift+Del, Shift+Ins라는 단축키로도 통용되고 있지만, 내 프로그램에서는 지금까지 지원되지 않았다.
일단 내가 개인적으로 저런 제2군 단축키를 전혀 사용하지 않았고, 그리고 shift+ins는 한글 낱자 수정 - 글자 전체 수정을 전환하는 용도로 이미 사용 중이었기 때문이다.

그러나 정신을 차리고 보니.. 텍스트 입력 기능을 갖춘 주변의 각종 에디터나 워드 프로세서에서 제2군 단축키를 지원하지 않는 프로그램은 없다. 정말 내 프로그램밖에 없는 것 같다. -_-;; 이는 거스를 수 없는 대세라 여겨지고 또 사용자의 건의도 있으니 이걸 이제야 반영했다.

그럼 낱자/글자 모드를 전환하는 기존 shift+ins를 어디로 옮길지가 문제인데.. 의외로 간단하게 해결했다. 그냥 ctrl+ins로 옮겼다.
Ctrl+ins는 텍스트에 블록이 잡혀 있을 때는 복사 기능을 수행하고, 블록이 없을 때는 낱자/글자 모드를 전환하게 했다. 텍스트를 타이핑으로 수정하는데 블록을 잡을 일은 전혀 없을 테니 이렇게 해도 영역이 전혀 겹치지 않는다.

3. 편집기: 자잘한 UI 개선

(1) 도구 메뉴에 있는 텍스트 분량 계산 기능을 크게 강화했다.
텍스트 중의 확장 평면(surrogate) 글자 수, 대략의 공백(whitespace) 수와 단어 수를 추가로 표시해 준다.
일본어· 중국어는 띄어쓰기가 없으니 전각 구두점만으로도 단어 구분이 되게 했다.
그리고 블록을 잡았다면 블록이 텍스트 전체에서 몇 % 정도 차지하는지도 나오게 했다.

(2) 예전에 날개셋 편집기에서는 텍스트를 스크롤 하거나 인쇄할 때, 화면 내지 페이지의 맨 마지막 줄은 그 아래의 줄 간격을 계산에 또 반영하지 않도록 동작이 개선된 적이 있었다. 그럴 필요가 없기 때문이다.
이와 비슷한 최적화가 세로뿐만 아니라 가로 스크롤에 대해서도 행해졌다. cursor가 줄의 맨 끝에 있을 때는 굳이 반각 한 칸 공간을 확보하면서 스크롤되지 않는다. 홀쭉한 cursor를 표시할 공간만 있으면 스크롤을 더 하지 않게 했다.

(3) 계산기 대화상자에서 오류가 있는 수식을 입력하더라도 그저 씹히는 게 아니라..
텍스트 전체가 블록으로 잡히고, 히스토리를 보관하는 콤보 상자에도 제일 최근 아이템으로 "1회 임시 등록"되게 했다.
그러면 사용자가 수식에서 오류가 있는 부분만 고쳐서 다시 계산을 시도할 수 있다.
수식이 오류 없이 정상적으로 계산되면 오류 수식은 히스토리에서 제거되고 맞는 수식으로 대체된다.

(4) 찾기 명령을 내렸는데 텍스트가 더 없으면 "도로 역방향으로 찾으시겠습니까, 문서 처음부터 다시 찾으시겠습니까?" 물음이 뜬다. 이 두 번째 시도에서도 텍스트가 전혀 나오지 않으면 그때는 "찾는 문자열이 없습니다" 메시지가 뜨게 돼 있다. 이 로직 자체는 맞다.

그런데 내 프로그램에는 애초부터 '문서의 맨 처음부터 검색'하는 옵션이 있다. 이 옵션을 켰는데도 match가 발견되는 게 없다면 저렇게 "찾는 방향이나 위치를 변경해서 재시도 하시겠습니까?"라고 또 물을 필요가 없다. 그때는 바로 "찾는 문자열이 없습니다"를 출력하도록 로직을 개선했다.

(5) 내 프로그램에는 문자열을 찾는 게 아니라 특정 코드값을 만족하는 문자를 찾는 기능이 있다. 얘로 검색을 시도했는데 찾는 문자열이 없으면.. 대화상자가 종료되지 않고 다시 검색을 시도할 수 있게 UI 동작을 고쳤다.

4. 입력 패드: 미세하게나마 성능 개선

날개셋 한글 입력기의 구현체 중에 입력 패드는.. 아무래도 편집기나 외부 모듈에 비해 존재감이 없는 잉여에 가깝다. 한번 엔진을 만들고 나서는 고칠 게 거의 없는 물건이다만, 이번에 의외로 대대적인 '최적화/성능 개선' 작업이 행해졌다.

(1) 이 프로그램은 동작 원리의 특성상, 64비트 OS에서도 32비트 프로그램들을 지원하기 위해서는 64비트 버전과 32비트 버전을 모두 실행해서 메시지 훅킹을 제각기 구동해야 한다.
그러니 32비트 버전의 경우, 32비트 운영체제에서 단독 실행될 수도 있고, 64비트 버전을 보조하는 간편 모드로 실행될 수도 있다.

간편 모드로 실행됐을 때는 자체적으로 GUI를 표시하는 게 전혀 없고(전부 64비트 버전이 전담하니) 하는 일도 매우 단순하다. 그렇기 때문에 굳이 32비트용 날개셋 커널을 로딩할 필요가 없다.
32비트 버전이 간편 모드로 실행됐을 때는 날개셋 커널을 로딩하지 않도록 동작을 개선했다. 뭐 그래 봤자 메모리 1MB 남짓 절약한 것에 불과하지만.. 불필요한 군살을 이렇게 하나 뺐다. ㄲㄲㄲㄲ

(2) 그리고 32비트 호스트를 내부적으로 실행하는 것도 무조건이 아니라 입력 도구를 하나 끄집어냈을 때, 키 입력 모드를 켰을 때처럼.. 사용자가 진짜로 그런 기능을 수행할 때만 하도록 했다.
이런 최적화는 해 봤자 당장 성능에 큰 차이는 없겠지만.. 64비트 환경에서 32비트 의존을 최대한 줄이겠다는 상징적인 차원에서 행해졌다.

5. 보조 입력 도구: 화면 키보드

날개셋 한글 입력기에 '화면 키보드'는 정말 유구한 역사를 자랑하는 입력 도구이다. 다음 버전에서는 다음과 같이 외형이 바뀌고 자잘한 기능이 추가될 예정이다.

(1) Windows 글꼴을 사용하는 경우, 문자들이 진하게 표시되게 했다. 이렇게 하니 가독성이 훨씬 더 나아졌다.
지금은 문자 키의 우측 상단에 자그맣게 고정적으로 붙어 있는 123 QWERTY...가 쓸데없이 진하게 찍혀 있었는데 로직을 바꿨다. 또한, 구형 운영체제에서 그 123 QWERTY...의 크기가 잘못 계산되어 큼직하게 찍히던 문제를 같이 해결했다.

(2) 한 글쇠에 대해 글쇠배열은 원래 자리와 shift를 합쳐서 2줄로 출력된다. 그러나 평소에는 원래 자리의 것만 표시되게 하는 '1줄 모드' 옵션을 이번에 추가했다. 윗글쇠 자리는 shift를 누르고 있는 동안에만 표시된다.
이렇게 하면 글쇠배열이 더 깔끔하고 알아보기 편할 것이다.

(3) 자체 비트맵 글꼴은 Windows 글꼴과 달리 크기 조절이 되지 않는다. 그래서 글쇠배열을 크게 키워도 너무 작게 찍혀서 문제인데..
이제 창 크기를 '대형'으로 하면 글자를 2배로 확대해서 출력하게 했다. 1줄 모드일 때는 창 크기를 '중형'으로만 해도 2배로 확대된다.

Posted by 사무엘

전등, 텔레비전, 전화기, 냉장고 같은 평범한 백색 가전제품 이후로 21세기에 인간들의 전기 소비량을 특별히 크게 증가시킨 물건은 시대별로 다음과 같다.

1. 2000년대: 에어컨

20세기 중반에 미국에서 이게 처음 도입됐을 때는 사무실의 시원한 에어컨 바람이 너무 좋아서 직장인들이 퇴근을 안 하고 잔업· 야근을 자처했을 정도였다고 한다. ㄲㄲㄲㄲ
그 당시엔 에어컨이 집집마다 비치되기에는 너무 비싸고, 결정적으로 전기 소모도 장난이 아니었으니까.. 회사와 직원 모두 윈윈이다.;;

1990년대까지만 해도 버스나 지하철 열차 안에 에어컨 냉방이 없었고, 학교 교실에도 천장엔 에어컨이 아니라 선풍기가 달려 있었다.;;
그렇잖아도 비효율적이고 열 풀풀 나는 저항 제어 전동차를 여름엔 어떻게 타고 다녔을까? 찜통 그 자체였을 텐데. ㅠㅠㅠㅠ 1990년대엔 지하철 승강장도 너무 덥다고 TV 뉴스의 카메라 출동 같은 시사 고발 섹션에서 지적할 정도였다.

1970년대에 울나라에서는 그 비싼 에어컨이 석굴암 내부에 설치된 적이 있었다. 습도 조절 때문에.
그런데 그 시절에 운행됐던 관광호 및 새마을호 열차는 객실에 벌써부터 에어컨이 있었을 정도라니 이건 뭐 초 호화 금수저 열차였다.

통계에 따르면 가정집 에어컨 한 대가 가정용 선풍기 30대의 전기를 잡아먹는다는 말이 있고, 소형 승용차용 에어컨은 엔진 출력을 4~5마력 정도 깎아먹는다고 한다.
지금도 이북 평양의 아파트들 풍경에서 에어컨 실외기가 눈에 띈 적은 없을 것이다.;;

2. 2010년대: 스마트폰

이건 그야말로 사람이 머무는 곳 어디에나 콘센트나 보조 배터리를 필요하게 만든 주범이다.
요즘 전화기는 간단한 전화기 기능만 있던 2000년대 폴더폰/피처폰 시절에 비해 전력 소모가 정말 어마어마하게 늘어나 있다. 매일 AA 사이즈 건전지 5~6개씩을 소모하는 것에 맞먹는다고 한다.

나 옛날에 초창기 폴더폰/피처폰 쓸 때는.. 배터리 용량이 총 4칸으로 표시됐는데, 걸거나 받지 않고 가만히 있으면.. ‘이틀’ 지난 뒤에 한 칸이 줄어들어던 적이 있다. 그대로 방치하면 진짜 6~7일 가까이는 갔다.;; 도저히 믿어지지 않지? ㅡ,.ㅡ;;
우리나라 KTX 고속철 최초 차량의 내부에 콘센트가 없었던 이유도 1990년대에 이런 걸 예측을 못 했기 때문이었다. 서울-부산을 1시간 56분 만에 찍을 건데 굳이 저런 시설까지 갖출 필요는 없다고 여기고 넣지 않았었다.;;

30여 년 전 Windows 3.x 및 9x 시절에는 컴터를 쓰면서 사용자가 운영체제의 리소스 퍼센티지를 민감하게 관찰하곤 했었다.
그러나 요즘 사람들이 뭔가 퍼센티지를 들여다보는 건.. 폰 배터리일 것이다.

비슷한 맥락으로, 30여 년 전에 사람들이 컴퓨터에서 뭔가 먼지를 주기적으로 청소해 주는 건 볼 마우스 안이었지 싶다. =_=;; 그러나 요즘 사람들이 먼지를 청소하는 건 폰 충전 단자 주변이지 싶다.
폰 충전 단자도 규격이 통합되지 않아서 기기마다 제각각이던 시절이 있었는데.. 이제는 아이폰까지 USB C로 통합되는 나날이 도래했다.

3. 2020년대 이후 전기 등골 브레이커계의 다크호스는 과연 전기차가 차지할까?

그 많은 자동차들까지 전기 인프라에 빨대를 꽂기 시작한다면 이건 원자력 발전이 없이는 도저히 감당이 안 될 텐데 말이다.;;
핵융합은 지금보다 더 낮은 온도에서 일으키려고 애쓰는 현상이고,
초전도는 지금보다 더 높은 온도에서 일으키려고 애쓰는 현상이구만. 하지만 둘 다 아직은 SF의 영역이다.

전기차는 비슷한 체급, 성능의 기름차보다 무게가 수백 kg 이상 더 나간다.
오~ 지금까지 생각을 안 하고 지냈네. 현타가... =_=
전기차는 정작 엔진룸 안은 기름차보다 훨씬 더 단순하고 깔끔하고 가벼운데도 말이다.

쟤들이 엔진오일이 필요하나, 냉각수가 필요하나~ 점화 플러그가 필요하나~ 연료 필터 공기 필터가 필요하나, 터보차저가 필요하나, 배기가스 정화 장치가 필요하나.. ㄲㄲㄲㄲ
그런데 빳데리가 이 모든 장점을 싹 씹어먹는다.
게다가 빳데리가 야기하는 공간 복잡도 무게 복잡도는 필요한 전력량(= 차 크기 내지 모터 출력)의 제곱 이상에 비례해서 급격히 커진다.

옛날에 구닥다리 브라운관 방식으로 텔레비전을 지금 수준으로 대형화하는 게 도저히 불가능했던 것과 비슷한 맥락이라고 생각하면 되겠다.
이러니 빳데리 전기 방식으로 버스나 대형 트레일러, 군용차, 국가원수 의전차, F1 레이싱카는 요원한 거지 싶다. 승용차나 시내버스, 소형 트럭 같은 일부 분야만 대체하겠지..

참 어려운 문제이다. 오늘날의 배터리 기술이 용량은 많이 늘렸지만, 그게 아무 부작용 없이 늘린 게 아니고 아직 갈 길이 멀다. 무게, 가격, 안전성 따위.. 기름 담긴 말통을 대체하는 게 쉽지 않다.

Posted by 사무엘

인류가 물 위를 건너기 위해 선박이라는 물건을 만들어서 띄운 지는 수천 년이 됐다. 심지어 그걸로 바다 위에서 전쟁도 치렀다.
하지만 그걸로 사람만 잔뜩 실어 나르는 장거리 전문 여객선이라는 게 등장한 건 역사가 의외로 짧다.

전근대 시절에는 평민들의 경제력과 교통 수요가 그런 걸 받쳐 주지 못했다. 거기에다 그 당시엔 선박 자체가 너무 위험하고 느리고 정시성을 장담 못 하는 물건이었다.
배 타고 망망대해로 나가는 것의 포스와 리스크가 요즘으로 치면 과장 보태서 무려 우주로 나가는 것에 맞먹었다. 보험 회사의 이름이 'oo 화재, xx 생명'뿐만 아니라 'xx 해상'이 괜히 있는 게 아니었다. 낭만적인 여행이 절대 아니고 모험 탐험이었다.

그 시절에 사람을 잔뜩 태운 배가 있다면 그건 지하에 노꾼이 잔뜩 탄 갤리선이거나, 아니면 아예 노예 무역선. 둘 중 하나일 뿐이었다. -_-;; 사람을 살인적인 중노동을 시키거나, 아니면 용변도 제대로 못 볼 정도로 꼼짝달짝 묶어서 짐짝처럼 쌓아 놓거나.. 둘 중 하나였다.
(단, 노예이면서 동시에 노꾼이지는 않았다. 많은 사람들이 호흡 맞춰서 엉킴 없이 노 젓는 건 극심한 중노동일 뿐만 아니라 전문성도 필요했다. 일자무식에다 더 잃을 것도 없는 노예에게 믿고 맡길 수 있는 일이 아니었다. ㄲㄲㄲ 질 낮은 죄수를 호락호락 총 쥐어 주고 군인으로 부려먹지는 않는 것과 비슷한 이치..)

상식적으로 생각해도 50미터 남짓한 길이에 엔진이 아니라 돛-_-이 달렸고 배수량도 200톤이 채 안 될 대항해시대 나무 범선 갖고 호화로운 장거리 여객선 영업이 가능할 리가 없잖아..

근데 그 시절에는 그 가냘프고 열악한 배에 남자들 수십 명이 낑겨 앉아서 신대륙을 개척하러 갔다는 거다. 이 정도면 교도소 복역이랑 선원 생활을 퉁쳐도 될 것 같은데 말이다.
지금 우리가 잠수함에 대해서 생각하는 위험함, 갑갑함, 열악함 등등이 그때는 일반 수상 범선에 적용됐고 수위가 더 높았다.

선박을 굴려서 돈을 벌려면 그 비좁은 공간에 화물을 왕창 실어야 했다. 그러니 선원들 복지는 더 열악해질 수밖에 없었다. 전근대 시절에 선박은 화물 수송이 main이었고, 여객은 거기에 꼽사리로 낑겨 타는 정도였다.

자, 그러면 성경의 요나서도 어떤 배경인지가 완벽하게 이해가 될 것이다. 요나 역시 여느 상선 화물선에 낑겨 탔기 때문에, 편안한 좌석이나 선실이 아니라 어디 한구석에 짱박혀서 잠들었다. 그리고 배가 위험에 처하자 선원들이 손해를 감수하고라도 무거운 화물들을 바다에 버린 것이다. 그건 승객 개인이 들고 다니던 더플빽이나 캐리어 같은 덩치의 짐이 아니었다.

참고로, 옛날 목선 범선에 대해 생각해 볼 거리를 좀 더 나열하자면 이렇다.

(1) 노아의 방주도 오늘날 기준에서는 그렇게까지 막 큰 배는 아니다. 길이 150미터 남짓한 목선이니 대항해시대 범선보다 좀 큰 정도이고, 20세기에 등장한 여객선이나 군함에 비할 바는 아니다. 이 크기와 부피이면 배수량은 여러 자료로 추정하건대 1만 톤 안팎쯤 됐을 거라고 여겨진다.
참고로, 현대의 조선공학 관점에서는 목선은 길이가 100미터, 배수량 2000톤 정도가 현실적인 한계로 여겨진댄다. 목재는 금속처럼 단단하지 못하고, 용접으로 이어붙이지도 못하기 때문이다.

(2) 노아, 요나 이상으로 성경에서 바다 항해를 제일 진지하게 다루는 곳은 사도행전 27장이지 싶다. 바울이 죄수 호송선을 타고 이스라엘에서 이탈리아 로마로 가는 장면 말이다. 자료를 찾아보니 뱃길로 약 2400km 거리라고 한다.
이건 부담 없는 단거리는 절대 아니고 2000여 년 전의 항해 기술로는 더욱 만만찮았을 것이다. 하지만 그래 봤자 태평양이나 대서양도 아니고 기껏해야 지중해 횡단일 뿐인데 그걸 한 번에 못 가서 중간 정박을 하고 겨울을 나네 마네 논쟁이 오갔던 것이다.
게다가 배에 사람이 276명이나(행 27:37) 탔었다. 선내에 공간이 절대로 넉넉하지 않았을 것이고 승선 환경은 몹시 열악했을 것이다.

(2) 500여 년 전, 마젤란의 세계일주 항해는 대장인 마젤란을 비롯해 250명에 달하는 선원을 잃고 배 세 척 중에 한 척만 겨우 귀환하는 개막장 거지꼴 패잔병 상태로 종결됐다. 그럼에도 불구하고..!! 그 배 한 척에 실린 외국 향신료만으로도 그들은 항해 비용을 다 뽑고 남는 흑자 장사를 했다고 한다.
그 시절에 향신료 가격이 지금의 마약 가격 정도라도 됐나 싶다. =_=;; 후추가 아니라 필로폰이었는지.. -_-;; 하긴, 그때는 화약 가격도 그렇게도 비쌌다니까 말이다.

암튼, 이런 열악한 상황은 증기 기관이 발명되면서 획기적으로 바뀌었다. 얘 덕분에 선박이 바람을 거스르는 정시 항해가 가능해지고, 해풍이 불지 않는 육지 한가운데 운하도 주행할 수 있고, 그러면서도 배가 더 크고 무거워질 수 있게 됐다.
배의 재질이 나무 대신 철로 바뀌었고, 동력 전달 매체도 처음에 외륜이 쓰이다가 스크루 프로펠러로 바뀌었다. 엔진조차도 왕복이던 게 터빈으로.. 19세기 후반에 일어난 혁명적인 변화가 아닐 수 없다.

이제 좀 뭔가 호텔 같은 배가 등장할 수 있게 됐다. (해상 호텔이라, 옛날 범선 시절에는 정말 상상도 할 수 없었던 사치.. ㄲㄲㄲㄲ) 민간이 아닌 군함은 훨씬 더 강하고 사정거리 긴 함포를 장착해서 적을 압도할 수 있게 됐다.
1906년경에 영국에서 만든 여객선 루시타니아 호, 그리고 드레드노트 전함이 민간과 군함 각 분야에서 최첨단 과학기술의 산물이었다.

그래서 민간에서는 대서양· 태평양을 건너는 장거리 대형 여객선이라는 게 운항을 시작하고, 군에서는 순양함을 넘어 전함이라는 등급이 등장했다. 19세기 말에 서 재필이니 이 승만이니 하는 우리나라 선각자들도 저런 배를 타고 미국을 다녀올 수 있었다. (비행기 1시간이 선박 1일에 맞먹으니, 편도로 2주 이상 걸렸을 듯.)
그 이름도 유명한 타이타닉이 이 바닥의 정점을 찍었다. 인류가 이런 배를 구경하게 된 지 얼마 되지 않았다.

1차 세계 대전을 겪은 뒤 세계 열강들은 군함만 만들다가 등골 빠지고 공멸하지 말고, 군함을 일정 배수량 이상은 다같이 만들지 말자고 군축 조약을 맺었을 정도였다. 그때는 전함을 더 만들지 말자는 게 지금으로 치면 핵무기를 다같이 만들지 말자고 약속하는 것이나 마찬가지 개념이었다.

그 뒤 선박은 연료가 석탄에서 석유 디젤 기관으로 바뀌면서 리즈 시절을 찍었지만, 비행기가 발명되면서 추세가 또 바뀌었다. 비행기는 터빈을 기반으로 한 제트 엔진이 도입되면서 세계의 하늘을 석권하게 됐다.
오늘날 배가 거대한 건 항공모함이나 초대형 유조선/화물선 정도이고, 인명을 태우는 건 말 그대로 해상 호텔인 관광 크루즈선만이 남았다. 100년 전과 같은 ocean liner(대륙 횡단 정기 여객선)라는 개념은 없어졌다.

거함거포주의는 항공모함 때문에 논파됐고, 지금은 미사일 때문에 더욱 확인사살됐다.
요즘은 해군보다도 해병대에서 상륙작전을 벌일 때 정도에나.. 뒤에서 펑펑 쏴 주는 전함의 함포를 그리워하는 지경이 됐다. 포탄이 그래도 비행기나 미사일보다는 화력 대비 훨씬 더 저렴하기도 하지.

20세기 초-중에는 여객선과 비행선이 대륙을 횡단했다. 그러나 20세기 중-후부터는 여객기와 미사일이 대륙을 횡단하면서 오늘날에 이르고 있다. =_=;;
우리나라 기준으로 여객선으로는 부산에서 일본, 인천에서 중국, 동해안에서 러시아 정도만 갈 수 있다. 즉, 아주 단거리 한정이다.

Posted by 사무엘

(1) 옛날 아폴로 계획 시절의 새턴 V 로켓, (2) F-22 전투기, (3) KTX-산천 열차.
분야가 서로 완전히 다른 교통수단이지만, 이들은 모두 공통적으로.. 맨 앞에 무슨 총검처럼 길쭉하게 삐죽 튀어나온 부위가 있다.
이건 각각..

1. 로켓: 비상 탈출용 로켓이다.

발사 초기에 이상이 발생했을 경우, 승무원이 탄 캡슐을 로켓 본체로부터 사출· 생환시킬 용도로 장착되었다. 승무원들의 탑승 공간을 통째로 사출시키니.. 이건 경비행기에 장착되는 비상 탈출용 낙하산이라든가, 전투기에 장착되는 사출 좌석보다 더 강화된 버전인 셈이다.
단, 2단 엔진까지 무난하게 분리됐을 때쯤이면 이제 고도와 속도가 너무 올라갔고 비상 탈출이 의미가 없어지기 때문에 탈출용 로켓도 같이 분리되고 버려진다.

아폴로 계획 전체를 통틀어서 이 로켓이 실제로 사용된 적은 없었다. 1969년 말의 12호 때.. 로켓이 발사되자마자 벼락을 맞는 바람에 이걸로 승무원들을 비상 탈출시키고 임무를 실패 처리시킬까 사령실에서 고민하긴 했었다. 하지만 그리하지 않았고, 임무도 다행히 성공했다.

2. 전투기: 피토 관이다.

기체 주변의 맞바람의 세기를 측정해서 이 기체의 비행 속도를 구하는 아주 중요한 장비이다. 레이더나 GPS 같은 기술이 개발되기 전엔 비행 속도를 측정하는 방법이 이것밖에 없었기 때문이다. 자동차처럼 바퀴의 회전수로 속도를 산출할 수가 없으니까..
정비 불량으로 인해 피토 관이 제대로 동작하지 않아서 계기판 바늘이 엉뚱하게 폭주하고, 이 때문에 조종사가 조종을 잘못해서 비행기가 추락까지 한 사고도 역사적으로 있었다.

다만, 피토 관이 꼭 저렇게 앞에 돌출된 형태로 장착될 필요는 없다. 그렇기 때문에 여객기의 피토 관은 옆구리나 꼬리날개 쪽에 훨씬 작게 장착되기도 한다. 자동차에 안테나가 옛날에 길쭉한 삼단봉 형태이다가 지금은 작은 상어 지느러미 모양으로 바뀐 것처럼 말이다.

3. 그리고 열차: 이 쇠막대기 빨대의 정체는 무려.. 독일제 최첨단 차량 연결기의 센서이다.

떼제베 기반의 1세대 KTX의 이후에 국내에 도입된 고속철 차량들은 무지막지한 20량 1편성이 아니라, 10량 1편성을 기본으로 하고 필요 시 중련· 연결 운행이 가능하게 만들어졌다.
열차의 연결과 분리를 간편 신속하게, 한편으로 견고하게 하는 건 나름 엄청난 기술이다. 양 차량을 물리적으로 붙들거나 놓을 뿐만 아니라, 서로 전기· 통신 배선 같은 것도 바로 연결이나 분리가 돼야 하기 때문이다.

두 차량이 합체할 일이 있으면 저 삐져나온 빨대가 먼저 상대 차량 연결기를 쑥 접촉하고, 나머지 부위도 찰칵 연결된다. 항공우주 업계에서는 우주 비행체의 합체를 도킹(docking)이라고 하는 반면, 철도에서는 이런 연결을 커플링(coupling)이라고 부른다. 오옷~!
참고로 우리나라의 철도 차량에서 일반적으로 쓰이는 연결기는 이런 것이다.

철도는 동력원뿐만 아니라 선로 분기기나 신호 시스템, 그리고 전철의 집전 방식(가공전차선=_=)까지 하나하나가 다 첨단 기술이다.
달리는 증기 기관차를 배경으로 하는 옛날 서부물을 보면 아주 흔히 등장하는 장면이 둘 있다. (1) 말 타고 달려가서 열차를 따라잡고 탑승하는 거(현대라면 오토바이-_-), (2) 그리고 열차 안에서 무슨 작업을 하고 나서는 뭔가를 조작해서 객차와 기관차를 분리시키는 것..

아마 영화적 허용이 많이 들어갔겠지만, 옛날 열차는 연결기도 구조가 더 허술해서 차량을 분리시키는 게 더 쉬웠던 것 같다.

Posted by 사무엘

1. 단 한 가지 장점

세상에는 단점이 많고 정말 불편하고 너무 비효율적이어 보이지만.. 여전히 쓰지 않을 수 없는 물건, 기계, 방법론 따위가 있다. 장점이 단점들을 다 씹어먹는 수준이고 다른 대안이 현실적으로 도저히 없기 때문이다.

(1) 교류 전기: 전기공학 이론의 난이도를 한 100배쯤 더 끌어올린 주범이다=_=. 직류보다 취급하기 너무 복잡하고 어렵고, 전자기기들에서는 어차피 직류로 변환도 해야 된다.
하지만 발전과 변압이 간편하고, 덕분에 대용량 전기의 초장거리 송전이 용이하다는 거.. 이 독보적인 장점 하나가 다른 모든 단점을 씹어먹었다. 건전지나 깨작거리는 수준으로는 오늘날 같은 눈부신, 찬란한 전기 문명이 절대 이뤄질 수 없었다.

(2) 헬리콥터: 고정익기보다 느리고 연비 안 좋고 대량 수송도 안 되고 너무 시끄럽고..;; 온통 단점뿐이지만 활주로 없이 수직 이착륙 가능하고 공중에서 정지할 방법이 이것 말고 더 있으리..??
(로켓도 양력이 아니라 추력만으로 공중에 뜨니 헬기 같은 기동이 이론적으로 가능은 하다. 하지만 걔는 헬기보다도 연비가 훨씬 더 안 좋다. -_- 로켓은 동체 대부분이 연료로 꽉 차 있으면서도 자동차나 비행기와 달리 엔진을 겨우 '분 단위'로밖에 가동을 못 한다.)

(3) 주사기: 아프고 공포스러운 데다 감염 위험도 있다. 하지만 먹거나 바르는 약보다 훨씬 더 빠르고 효과 좋으면서, 대놓고 배를 가르는 수술보다는 훨씬 더 간편하고 안전하다. 이 독보적인 장점을 대체할 다른 수단이 없다.

과학기술 분야는 전혀 아니지만, 복음 전하는 방법으로 거리 설교도 이와 비슷한 부류라고 개인적으로 생각한다.
불신자뿐만 아니라 교인들조차도 상당수가 부정적인 편견과 안 좋은 인식을 갖고 있다. "저래 갖고 누가 듣나", "광신자라고 욕 먹고 신고나 당하지", "그냥 어려운 주변 이웃 도우면서 이미지 제고나 하는 게 낫다" 등등..

근데 저 방법 말고 세상 사람들이 예수 천당 불신 지옥 메시지를 듣고 경고를 받고 복음을 들을 통로가 뭐가 있겠나? 그 사람들이 제 발로 기독교 방송을 듣겠나 스스로 성경을 찾아 읽겠나? 거부, 거절, 부정적인 피드백은 당연한 것이니 제대로 전한 것만으로 씨앗을 뿌린 것이다. 저건 주사기만큼이나 더 나은 다른 대안이 없다.

다시 과학기술 얘기로 돌아오면..
저 사례들과는 정반대로, 언뜻 보기에 많은 장점이 있어 보이지만 치명적인 단점 한두 가지가 해결이 안 되어 주류가 못 되고 묻혀 버린 기술도 있다.
무탄피총이라든가 비행선, 반켈 엔진 같은 거 말이다.

2. 세분화, 전문화

대학 이상의 고등교육을 받고 인간이 이룩한 온갖 과학기술, 특히 공학의 세계를 맛보기나마 접하면서 느끼는 점 중 하나는..
이 바닥은 정말 깊게 세분화돼 있어서 한 사람이 모든 걸 다 알기가 불가능하다는 것, 그리고 기계도 하나만으로 이것저것 다 대응 가능하게 만들지는 않는/못한다는 것이다.

현실에서는 스타크래프트 테란과 달리, 단일 차체로 곡사 자주포와 장갑차 역할을 동시에 수행하는 탱크를 만들지 못한다.
미사일 하나만 해도 대공이냐 대잠이냐 대전차냐.. 전투기가 발사하냐 잠수함에서 발사하냐에 따라 미사일의 형태와 폭약과 추진제의 구조가 다 달라진다. 하나 만드는 정밀 기술로 다른 분야를 커버할 수 없다.

물에서 항해도 가능하고 공중 비행도 가능한 비행정은 비행기의 태동 초기에 잠깐 쓰이다가 말았다. 물 저항을 적게 받는 디자인과 공기 양력을 잘 받는 디자인에 서로 교집합이 없기 때문이다.
항해도 가능하고 지상 주행도 가능한 호버크래프트/수륙양용차 같은 건 해병대 상륙 작전용으로나 쓰이지, 여객용..?? 아니올시다. 가성비가 맞지 않는다.
로터를 기울여서 헬리콥터도 되고 프로펠러기도 되는 비행기조차도 성능이 어정쩡하고 비싸서 널리 실용화되지 못했다.

그리고.. 비행체 엔진만 해도 지상에서 뜰 때, 아음속 비행, 초음속 비행, 심지어 우주 기동에 적합한 엔진의 형태가 다 다르다.
단일 엔진 단일 기체만으로 단 분리 없이 대기권과 우주를 모두 비행..??? 현재 인간의 기술로는 불가능하다.
이러니 SF물만 많이 봤던 사람들이 아폴로 우주선의 '달 착륙선'을 보면 깜짝 놀라는 것이다. 유체역학적인 디자인이 전혀 아니기 때문에.

• 이거 뭐 첫 이륙과 출발 때는 터보 팬이나 터보 제트를 썼다가 극초음속에서는 램 제트..?? 변속기를 넣어서 자동차처럼 기어비를 바꿀 게 아니라 아예 속도별로 엔진을 바꿔 끼워야 할 지경이다. 기술적으로 당연히 불가. ㄲㄲㄲㄲㄲㄲㄲ
• F1 레이싱용 자동차들은 정말 서킷 전용으로 극도로 특수하게 만들어진 놈들이다. 시내를 달리는 일반 자동차들처럼 신호 받으면서 저속으로 가고 서다 하다가는 다 퍼지고 고장날 거라고 한다.
  
• 시속 200짜리 기록 도전용으로 만들어지는 특수한 자전거도 마찬가지. 기어비를 극단적으로 높게 맞춘 채로, 공기 저항을 몸빵해 주는 자동차를 졸졸 뒤쫓아가는 것에만 특화돼 있다. 이 자전거를 사람이 정지 상태에서 페달 밟아서 시속 200까지 몽땅 가속시키는 건 아니며 그럴 수는 없다고 한다.. -_-;;;
  

동력 기관 말고 안전 장치만 해도, 총알을 막아 주는 방탄유리가 교통사고 때 쉽게 깨지지 않는 안전유리의 역할까지 동시에 수행하지는 못한다.
오토바이 헬멧이랑 공사장 헬멧도 역할이 다르며, 방검조끼와 방탄조끼 역시 한쪽이 다른쪽 영역까지 동시에 보호해 주지 못한다는 한계가 있다.

하긴, 굳이 물건뿐만 아니라 사람의 전문성도 마찬가지이다.
미친 난이도를 자랑하는 리스트의 클래식 피아노를 치는 전공자라도 재즈 반주를 보면 벙 쩔 수 있다. 영역이 완전히 다르기 때문에.
공기총 스포츠 사격 금메달이랑, 군대 육군 소총수의 특등사수 사격, 그리고 특전사 저격수의 사격은 다들 영역이 다르고 잘 호환되지 않는다. 한쪽을 잘하는 사람이 다른 분야까지 전문가를 겸하지 못하며, 그나마 원래 전문인 분야도 며칠만 연습· 훈련을 게을리하면 금세 감이 무더져 버린다.

그러니 사람뿐만 아니라 총기도 용도별로 특성이 모두 다른 건 당연지사다.
저격수 정도로 극도로 민감하고 전문적인 분야로 오면 총도 무슨 악기마냥 전용 케이스에 넣어서 고이 간직해야 하고, 수시로 닦아 주고 손질해야 한다.
유효 사정거리를 겨우 100~200m로 잡는 일반 쫄병들이야 훈련용 총 따로, 실전용 총이 따로이고 소총과 함께 진흙탕에 막 뛰고 뒹굴기도 한다만.. 그런 건 저격수한테는 상상조차 할 수 없다.

3. 한 10년 전부터, 앞으로 2~30년 안으로 없어질 거라고 난리였던 것들

(1) Java, C# 같은 가상 머신 언어가 주류가 되고, 구닥다리 C/C++ 프로그래밍은 한물 갈 거다
그럴 리가.. C++이 2010년대 이후부터 얼마나 괴물 같은 문법과 기능들이 마구 추가되고 상상을 초월하게 바뀌었는지를 알면.. 저건 이불킥 수준의 단견임이 느껴질 거다.
아 물론 MFC 같은 일부 프레임워크는 한물 간 거 맞다. 기존 프로젝트들을 유지보수 하는 용도로만 쓰이지 신규 제품 프로젝트를 저걸 써서 진행하는 경우는 거의.. (간단한 내부 툴, 데모, 쌤플 정도나 만드는 경우 말고) 전멸이다.

(2) Windows NT 커널이 없어질 거다
마소에서 차세대 Windows를 표방하며 한때 개발했던 Midori니, Windows 10X 같은 건 전부 망했다. 만들려다 말았고 개발 중단됐다. NT 커널이 없어진다니 그게 말이나 되는 소리인가.;;
마치 인텔에서 x86 말고 다른 계열 CPU를 만들려다가 만 것과 비슷한 취급이다. 과거의 Itanium이라든가 i860, i960 같은 거.

(3) 폰트에서 힌팅이란 게 없어질 거다
요즘 서브픽셀 안티앨리어싱 기술이 많이 발달했고, 어지간한 디스플레이 해상도가 30~40년 전의 도트 프린터에 근접하기는 했지만..
그래도 작은 본문 글씨에서 힌팅이 있고 없고의 차이는 유의미한 걸요?? 힌팅 없으면 획이 뿌옇고 뭉개지는 게 여전히 티가 난다.
맑은 고딕도 언뜻 보기엔 100% ClearType빨인 것 같지만.. 똠 뷁처럼.. 2350자 밖의 비완성형 글자를 작게 찍어 보시라. 힌팅이 적용된 일반 2350자 글자보다 훨씬 못생겨진다.

물론 옛날처럼 한땀 한땀 쑤제로 정교하게 힌팅을 할 필요는 없고, 심지어 대부분의 절차가 자동화, AI화는 될 것이다. 그러나 완전히 없어지지는 못할 거다. 마치 비행기 유인기 vs 무인기의 역할 분담과 비슷한 관계가 될 듯하다.

Posted by 사무엘

1. 증기 기관차 지하철

1863년 1월, 영국 런던에서는 세계 최초의 지하철 메트로폴리탄 선이라는 게 개통했다.
이때는 미국에서 남북전쟁이 한창이던 시절이었다. 링컨이니 남북전쟁이니 하는 얘기랑, 대도시 지하철이 동시대라니 도저히 어울리지 않는 것 같다. 그때 우리나라 조선은?? 이제 겨우 대동여지도가 만들어진 지 얼마 안 됐다. ㄲㄲㄲㄲㄲㄲ

허나, 남북전쟁은 일개 내전 주제에 기관총 저격총에, 철도 보급 총력전에 초보적인 잠수함까지 등장한 의외의 첨단 과학기술 전쟁이었다. 그 와중에 런던에서는 지하철이 개통하긴 했는데..
지하철에서는 증기 기관차가 다녔다. ㅡ,.ㅡ;; 아직 전기 철도라는 게 개발되지 않았기 때문이다. 그러니 지하에서 석탄 매연 문제가 장난 아니게 심각했다.

1890년이 돼서야 영국 지하철에서 처음으로 전기 철도라는 게 등장하고 지하철의 주 동력원은 전기로 바뀌었다. 증기 기관차를 경험한 적 있는 지하철은 당연히 세계 전체를 통틀어 저기가 유일하다.

이렇게 전철이 개발되면서부터 유럽 열강들 대도시의 지하철은 1890~1910년 사이에 집중적으로 만들어졌다.
일본은 최초의 도쿄 지하철인 긴자 선이 딱 영국 스타일로 표준궤에 제3궤조 집전식으로 만들어졌지만, 그 뒤에는 전부 협궤에 가공전차선으로 바뀌었다.

2. 원자력 기관차

1950년대 냉전 초창기는 증기 기관차가 슬슬 끝물을 보던 시절이었다. 이때 미국과 소련에서는 탄수차 대신 원자로를 얹어서 물을 끓이고 터빈을 돌리는 원자력 기관차라는 무시무시한 물건을 생각했었다.;; 이른바 atomic train, nuclear locomotive..

역시 원자력답게 연료봉을 하나 꽂아 주면 거의 1년은 마일트레인 급의 무시무시한 화차들을 잘 끌고 다닐 수 있겠다는 계산이 나오긴 했다. 원자로를 표준궤 열차 수준으로 소형화하는 게 쉬운 일이 아니었지만, 이건 도저히 극복 불가능한 문제는 아니었다.

하지만 안전 문제가 너무 노답인 데다, 그 시절엔 기름값이 확 싸지고 디젤 내지 전기 기관차 기술도 눈부시게 발달해 버렸다. 경쟁 후보 대비 가성비가 확 떨어진 바람에 이 계획은 1950년대에 구상 단계에서 다 백지화됐다. 오늘날 원자로가 탑재된 교통수단은 전부 해군에 소속되어 망망대해에서만 뛰고 있다(잠수함, 항공모함).

3. 가스 터빈 고속철

1964년 10월에 개통된 일본 신칸센은 자동차와 비행기에 밀려 몰락하던 세계의 철도 업계에 신선한 충격을 선사했다.
100여 년 전, 영국에서 "철도를 지하에다 집어넣어서 도시 교통체증을 해결해 보자",
30여 년 전, 독일에서 "신호 대기 없이 쭉쭉 달리는 자동차만의 전용 도로를 만들어 보자"에 이어..
일본에서는 "건널목을 몽땅 없애고 총알탄 열차를 만들어서 교통난을 해소하자"라는 엄청난 아이디어를 구상하고 실현한 것이다. 물론 쟤들은 미래가 없는 노답 협궤 기존선들 때문에 상황이 더 절박했던 것도 있고 말이다.

일본 신칸센이 열차로서 시속 200km를 최초로 넘자, 프랑스에서는 TGV라는 고속철을 자체 개발했다. 그런데 얘들은 처음엔 가스 터빈을 동력원으로 검토했다. 즉, 프랑스는 내연기관 고속열차를 연구 개발해 본 유일한 나라이다.

1963년에 신칸센 전철이 시운전 시속 250km를 돌파한 데 이어, TGV 001호는 가스 터빈 엔진으로 1972년에 시운전 시속 318km를 기록하기도 했었다. 그러나 1973년 이후 오일쇼크가 닥치자 기름값 유지비가 감당이 안 됐고.. 이를 계기로 TGV도 개발 차량이 아닌 영업용 차량은 신칸센처럼 100% 전철로 동력원이 바뀌었다.

아까 원자력 기관차는 기름값 하락이 몰락에 일조했던 반면, 얘는 반대로 기름값 상승이 몰락에 기여했다는 차이가 있다.
교통수단에서 터보샤프트 급 가스 터빈 엔진은 헬리콥터나 탱크 정도에서 쓰이고 있다. 철도 차량의 동력원으로는 사례가 없지는 않지만 아주 마이너하다.
초창기 가스터빈 떼제베 001과, 후대의 전철 떼제베는 관계가 마치 우리나라 DEC / EEC 열차쌍과 비슷해 보인다.

4. 제트 엔진 고속철

이건 초음속 자동차의 철도 버전이며, 앞의 2번과 3번을 합친 것 같은 무시무시한 야사이다.
미국과 소련에서는 가스 터빈 정도가 아니라 노즐까지 달린 제트 엔진을 철도 차량에 접목할 생각도 했었다. 1960년대 중후반까지 말이다.

그래서 이런 게 실제로 개발됐었다. 달에 먼저 가겠다고 우주 경쟁을 하던 시절에 서로 이런 것도 만들었다는게 참.. ㄷㄷㄷㄷ 얘들는 바퀴식 고속전철이 한참 나중에야 달성한 시속 300~400을 1960년대에 진작에 찍기도 했다.

오오~ 전차선과 팬터그래프가 달리지 않은 고속철도라니.. 게다가 얘는 바퀴를 굴리는 게 아니라 공기를 뒤로 밀어내면서 달리니 마찰이 부족해서 발생하는 공전 현상 따위의 영향도 받지 않겠다.
과거 우리나라의 새마을호 디젤 동차가 잠수함 엔진을 얹었다면, 쟤들은 폭격기 엔진을 얹었다.

그러나 이런 게 실용화되지 못한 이유는 뭐.. 더 설명이 필요하지 않을 것이다.
연료 소모가 너무 극심할 뿐만 아니라, 선로 주변에 배기가스와 귀를 찢는 소음 문제가 장난이 아니었기 때문이다.
게다가 이때는 훨씬 더 경제적이고 주변에 민폐 덜 끼치면서 시속 200~300을 찍는 신칸센 고속전철이 개통돼 있었기 때문에 가성비 면에서 더욱 수지가 맞지 않았다.

철도 차량의 제트 엔진은 차체를 통째로 공중에 들어올리는 건 아니니까 비행기보다 연료 소모가 적을 거라는 생각이 들지 모르겠다. 하지만 꼭 그런 것만은 아니다. 이 지표면은 비행기들의 순항 고도 지점보다 공기의 밀도가 높고 공기 저항이 훨씬 더 심하기 때문이다.

비행기만 해도 저고도에서는 속도와 연비가 우리 생각 이상으로 급격히 떨어진다. 비행기가 괜히 힘들게 수 km 이상 위로 상승하는 건 단순히 승객들에게 멋진 구름 경치를 제공하기 위해서인 게 아니다. 자동차에 경제 속도가 있듯이 비행기에도 경제 고도가 있는 셈이다.

10km 고도에서 마하 1~2를 찍는 전투기라도 겨우 수백 m 고도에서는 그 속도로 날지 못한다. 엔진에 과부하가 걸리는 걸 넘어 기체가 공기 저항을 못 버티고 부서진다고 한다.;;
이걸 생각하면 사막에서 제트 엔진 얹어서 시속 1600km대로 주행한다는 초음속 자동차가 대단하게 느껴진다.

옛날에는 rocket이라는 말이 지금처럼 대중화되지 않아서 진짜로 로켓을 연구하는 NASA의 연구소마저 이름이 '제트 추진 연구소'였었다. 그런데 훨씬 더 옛날에 영국에서 증기 기관차의 이름이 그 당시로서는 초고속이었다고 '로켓 호'라고 지어졌다니.. 이것도 참 의미심장하다.

Posted by 사무엘

2024년이 벌써 두 달이나 지났다.
본인은 늘 해 오던 것처럼 직장을 잘 다니고 있고, 날개셋 한글 입력기의 다음 버전을 틈틈이 개발하고 있다.
교회 생활이랑 멧돼지 호박 덕질도 변함없고... 그러던 와중에 올해 초에는 예쁘고 착한 여친을 사귀기 시작했다.
나이 40을 넘겨서도 20대 같은 연애가 가능하다는 게 참 신기하다.;; 한편으로 결혼을 위해서 앞으로 집은 어찌 하고 살림을 어떻게 합칠지~~ 이것저것 고민도 많다.

오늘은 오랜만에 호박 덕질 근황을 좀 업데이트 하도록 하겠다.

1. 먹은 호박

작년 10월 초에 옥상에서 땄던 그 500그램짜리 꼬마 호박. (직접 씨 뿌리고 키우고, 내 손으로 직접 암꽃에다 꽃가루 묻혀 줘서 만든 열매 ^^)
그리고 작년 11월 초에 길거리에서 샀던 큼직한 풋호박. (설익은 놈이어서 저 크기가 만 원도 안 했었음)
둘 다 처음엔 짙은 초록색이었는데.. 3개월이 넘는 숙성 기간 동안 다들 정말 많이 누래졌다.

생각 같아서는 이 아이들을 천 년 만 년 놔두고 싶다. 하지만 이젠 보내 줄 때가 됐다고 여겨진바, 지난 2월 중순쯤에 드디어 같이 도축해서 죽을 쑤어 먹었다.
죽의 색깔이 주황보다는 노랑에 더 가깝다. 뭐, 상태 좋고 달콤하고 맛있더라. 여친과 데이트 때도 가져가서 같이 나눠 먹었다.

2. 시장에서 본 호박

올해 1~2월 사이에 가락시장에서 본 귀여운 아이들이다.
내 인생에서 이렇게 큰 호박은 거의 처음 본 거 같은데..
아~ 크기 비교를 쉽게 할 수 있게 내 호박 쿠션을 위에다 올려 놓고 사진을 찍었어야 했다. 그리하지 못한 건 실수다.;;;
한 덩이 사고 싶었지만 정작 이 호박을 쌓아 놓은 상점 주인은 보이지 않았다.

늘 드는 생각이지만.. 우리나라에서 늙은호박은 주로 어디서 재배돼서 어떻게 유통되고 주로 어디로 팔려 나가서 소비되는지 개인적으로 참 궁금하다.
늙은호박은 애호박이나 단호박 정도로 end-user 지향적인 제품은 아니니 말이다.
상표가 부착되는 것도 없고, 가격도 그냥 상인이 부르는 게 값인 거 같고.. 농민들이 이익을 제대로 남기기는 하는지.. 궁금하네.. ^^

참고로 요건 본인이 2024년 2월 현재 집에서 보유하고 있는 관상용· 식용 겸용 호박이다. 다들 가락시장에서 샀다. 올해 3~4월 사이에 죽을 쒀서 먹을 것이다.

3. 키우는 호박

지난 겨울 동안 집에서는 이런 걸 키워 놓고 구경했다.
호박은 싹이 나고 어느 순간까지는 길쭉하게 자라고 미친 듯이 꽃도 피우더니..
어느 순간부터는 갑자기 탈진한 듯 기력이 다하고 잎이 폭삭 시들고 죽곤 했다.

에구, 추위를 피하게 해 준답시고 무작정 실내에서만 키우는 것만이 답이 아닌 듯.. 그래도 몇 년 전에는 실내에서도 암꽃이 피고 나름 큼직한 열매까지도 구경했는데 말이다.
이제 한두 달 뒤면 호박을 밖에서 키울 수 있게 될 테니, 이걸 기대해 보련다.

이 상자에다가는 올해 초 1월쯤부터 호박씨를 10여 개 파묻어 봤다. 그런데 1주, 2주를 넘어서 1달 가까이 지나도록 싹이 안 나서 본인은 씨를 곳곳에다 더 심었는데..
이게 웬걸, 2월 중순쯤부터 하나 둘 싹이 나더니 3월 초에는 대부분의 씨앗에서 싹이 몽땅  돋아서 화분이 저렇게 콩나물시루가 돼 버렸다.

얘를 앞으로 어찌 다뤄야 할지 난감하다.. ^^
참고로 별도의 종자를 구매하는 건 아니다. 모든 호박씨는 그냥 죽 쒀 먹고 남은 늙은호박 안에 있던 씨들이다.

4. 호박 쿠션

끝으로.. 짜잔~~
생일 선물로 여친에게서 호박 쿠션을 받았다. ^^
원래 내 꺼보다 더 크고 더 포동포동 토실토실 푹신한 아이.
이런 착한 여친을 둔 나라는 사람, 억만장자가 안 부럽다!!

늙은호박은 둥글고 납작하고 쭈글쭈글하고 귀엽다!! 호박은 세계에서 가장 큰 '열매'를 맺는 식물이다. 가장 큰 잎이나 가장 큰 덩굴이 아니라 가장 큰 열매.
우리 모두 귀여운 호박 많이 가꾸고 맛있는 호박 많이 먹도록 하자~~ ^^

Posted by 사무엘