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

일본에 대해서

(사무엘) — Fri, 23 Oct 2026 08:35:00 +0900

1. 현재의 사회 풍경에서 인상적인 것

-- 체제가 안정적이다. 1947년 이래로 헌법이 한 번도 개정되지 않았으며, 공포되고 시행된 날이 둘 모두 공휴일인 게 대단하다. 그 전쟁 와중에도 화폐개혁이 20세기 이래로 없었던 거, 춘분과 추분이 공휴일인 것 역시 인상적이다.

-- 전철역 승강장에 스크린도어가 별로 없다.
-- 버스를 우리나라와는 정반대로 뒤에서 타서 앞에서 내리기도 한다. 요금이 후불인데, 승무원이 앞문 쪽에 있기 때문이다.
-- 별의별 물건을 파는 자판기가 많고, 편의점 잡화점도 아주 발달해 있다.
-- 물건에 가격은 언제나 2개가 표시되어 있다. (면세 할인 적용 여부)

-- 우리나라보다는 현금 사용이 여전히 더 활발하다. 하긴, 현금에 대한 가중치가 일본 > 한국 > 중국의 순인 듯하다. 중국은 위조지폐 문제도 있고 해서 한국보다도 더 현금 퇴출에 진심이라는데.. 거지가 동냥을 해도 계좌 QR코드를 목에 걸어 놓고 할 정도랜다.;;;
-- 학교에 수영장이 있고, 초딩들은 꼭 동그랗고 노란 모자를 쓰고 다닌다. 이것도 국가 차원에서 지급되는 학용품인지?

2. 문자

-- 한국과 중국에서는 진작에 사라지고 없는 세로쓰기가 일본에서는 여전히 현역이고 활발히 쓰인다.
-- 둥근고딕(굴림/디나루 세나루)에 정말 진심이다. 똑같은 한자라도 이 폰트로 쓰인 것만 봐도 바로 일본이 떠오를 정도이다.
하지만 이 폰트는 종전 후에 개발되고 보급됐다는 게 매우 놀랍다. 즉, 일제 시대까지만 해도 지금 우리가 아는 둥근고딕 일본어 문구 같은 건 없었다. 아니, 그때는 지금 같은 신자체 한자가 없었고 히라가나 위주의 정서법조차 없었으니 그때와 지금은 문자의 이질감이 매우 심하다.

-- 히라가나가 문자 차원에서 획이 붓글씨 계열 디자인이어서 그런지.. 일본에서는 한자가 궁서 붓글씨 폰트로 쓰인 건 보기 힘들다. 한자 궁서체는 중국에서 활발히 쓰인다.

3. 언어

-- 독일어는 Gift가 독 poison이라는 뜻이고 hell이 ‘밝은’이라는 뜻이라는데... 일본어는 hi가 잘 알다시피 '옙~ 넷!' 이런 뜻이다. 하이~!! 그래서 쟤들은 간단한 영어 인사도 hi 대신 hello를 더 선호한다고 한다. (전화 받을 때는 영어로 hello이지만 일본어는 '무시무시'~)
영화 킬 빌에서 일본 여고생 킬러인 ‘고고 유바리’가 주인공에게 의외로 “hi~~” 이렇게 인사하던 게 인상적이었다. ㄲㄲㄲㄲ

-- 일본어 소리를 한글로 표기할 때는 도요타/토요타, 가타카나처럼 유음· 탁음이 늘 헷갈리고 tsu 소리는 츠/쓰가 하나로 통일되지 않고 늘 난립하는 것 같다.
す는 일본 현지인도 모음을 길게 발음해서 '스~' 이러거나, 아니면 진짜 영어 S처럼 들릴락말락 짤막하게 '스'로 발음하거나.. 둘 다 케바케인 듯하다.

-- 영어에서 스펠링 gh의 발음이 제멋대로라면, 일본어에서는 날 생 生의 발음이 그렇게도 제멋대로 제각각이라고 그런다.;; 한국어에서는 ㅢ가 발음이 굉장히 제멋대로 불안정한 모음으로 전락하긴 했다만, 그래도 쟤들에 비할 바는 아니지 않을까.

-- 지브리(Gibli), 휴렛(Hewlett) 패커드, 모토로라(Motorola) 같은 예를 생각해 보면, 우리는 외국 고유명사에서 L 소리를 덜 반영하는 경우가 생각보다 많다. 일본어의 영향인 걸까..??
뭐, '겨우내(겨울)'. '홍도야 우지 마라' 처럼 우리말에도 자체적인 ㄹ 음운 생략이 있긴 하지만 저건 좀 다른 경우인 것 같다.

4. 건축과 인테리어 스타일

-- 일본은 옛날 목조건물들도 우리나라의 옛날 건물보다 층수가 더 많고 더 "높다". 그리고 우리나라의 목조건물들은 기둥이 적갈색· 황갈색 계통인 반면, 일본 건물의 기둥은 그냥 검다. 다 똑같은 기와 지붕 목조건물 같아도 세부 디테일은 이렇게 미묘한 차이가 있다.
-- 조선은 온돌바닥에 진심이었던 반면, 일본은 중앙 난로를 애용했댄다.

5. 옛날에 한미일의 기술 격차: 교통

-- 1960년대에 한국 경인/경부 고속도로, 일본 신칸센(세계 최초 고속철), 미국 아폴로 우주선(인간을 달나라로....)
미국이야 1920년대부터 뉴욕에서 자동차 교통체증이라는 걸 겪었던 나라이며, 1940년대의 LA 길거리가 대한민국의 한 1970년대와 비슷한 분위기였다.
그 반면, 한반도는 1940년대까지 광화문과 조선총독부 바로 앞에도 아스팔트 포장이나 중앙선, 횡단보도, 신호등 같은 게 없었다.

-- 일본 신칸센은 차량과 선로 모두 100% 자체 기술과 자본만으로 만들어졌다는 것도 생각할 점.. 저게 갑자기 툭 튀어나온 건 아니고, 1950년대에 이미 협궤에서 열차 주행 속도 150~160을 찍었었다.

-- 또한, 신칸센뿐만 아니라 세이칸 터널도 엄청난 근성의 산물이다. 그때 신칸센 규격으로 터널을 미리 만들어 놔서 250에 달하는 속도로 주행 가능하게 해놨다.
한국은 강 아래로 지하철 터널 뚫을 기술도 없었고 북괴는 두만강 평양 지하철 실패했던 시절이다.

6. 옛날에 한미일의 기술 격차: 애니메이션

-- 1980년대 말에 한국 머털도사, 일본 토토로(..!!!!), 미국 인어공주(ㄷㄷㄷㄷㄷㄷ)
미국이야 1940년대에 이미 DC 코믹스 배트맨, 슈퍼맨, 미키마우스가 있었던 나라이다;;
일본은 군국주의에 쩔어 있다가 패전 후에 글자부터 히라가나에 동글동글 굴림체로 갈아타면서 정신을 개조하더니.. 아톰이니 에디트맨부터 시작해서 어쩌다가 약 빤 만화영화 강국이 됐는지 정말 신기한 노릇이다.

-- 하긴, 옛날에 한국에서는 그냥 불량만화 추방 운동을 했지만, 일본은 과학 교양 학습만화를 잔뜩 만들었다. 이게 양국의 문화 풍토와 정서의 차이를 만들어 냈다.
물론 2000년대 이후부터는 한국도 그때에 비해서는 강대국들을 정말 많이 잘 따라잡았다.
오히려 저 나라 사람들이 "이러다가는 우리가 코리아한테 따라잡힌다" 살짝 걱정도 할 지경이 됐다.

7. 역사: 교통 인프라

-- 일본은 19세기 말에 근대화 산업화 잘 하긴 했지만, 서유럽이나 미국과는 달리 자동차나 도로 인프라는 미흡했다. 땅이 길쭉해서 그런지 작정하고 철도에만 완전 올인했다.
일본 도쿄에서는 1920년대에 이미 증기 기관차가 대도시에서 고가 철교 위를 달렸고 20년대 말에 지하철까지 개통됐다. 하지만 미국의 스테이트 하이웨이, 독일의 아우토반 같은 건 없었다. 길거리에는 노면전차와 인력거만이 달릴 뿐이었고 자동차는 그 국력과 경제력 대비 극히 드물었다.

-- 현재까지도 일본은 국력과 경제력 대비 서민들 자동차는 너무 작다.;; 뭐, 경제 선진국이니 아예 이륜차 삼륜차 툭툭이가 주류는 아닌 거다. 그리고 제일 먼저 하이브리드 차량을 개척하긴 했지만 그 뒤로 배터리 전기차에서 특별히 일본차가 막 부각되는 것 같지는 않다.

8. 타 국가와의 근현대사 비교

-- 1860년대에 미국에서는 남북전쟁이라는 내전이 벌어졌고, 일본에서는 보신전쟁이라는 내전이 벌어졌다.
미국 껀 체제는 유지하면서 다른 이슈를 갖고 싸운 내전인 반면, 일본 껀 체제 교체 혁명형 내전에 더 가까웠다.
비슷한 시기에 조선은 병인양요니, 제너럴 셔먼 사건 같은 걸 겪었다.

-- 소련군에서 여군 저격수가 독특한 병과였다면, 일본군은 병 계급의 파일럿이 그런 독특한 병과였던 듯하다.
그리고 나치 독일이 세계에서 가장 거대한 비행선과 땅끄를 만들었다면, 일본은 세계에서 가장 거대한 전함을 만들었다.

-- 일본은 1차 세계대전 때 마이너한 연합국 승전국이었다가, 2차 때 추축국 패전국이 됐다.
-- 2차 세계대전 때 독일은 소련과 불가침 조약을 맺었지만 나중엔 그걸 어기고 소련을 침략했다.
소련은 일본과 불가침 조약을 맺었지만 나중엔 그걸 어기고 일본에 쳐들어가서 패망 직전의 일본을 확인사살했다.

-- 아주 특수한 연구 개발 분야에서는 납 성분이 전혀 들어가지 않은 옛날 공기를 어디 남북극 빙하에서 찾아서 쓴다고 한다.
그것처럼 인류가 핵실험을 하기 전, 방사선이 조금도 들어가지 않은 옛날 철을.. 태평양 전쟁 때 격침되어 바닷물에 가라앉아 있는 일본 전함으로부터 구해다 쓴다고도 한다.

9. 역사에서 명과 암

-- 19세기 말이 조선은 다 망해가던 암울한 시절이었지만 일본은 그야말로 희망이 넘치던 시기였다. 서양 열강과 맺었던 불평등 조약을 도로 개정하고, 자기들도 말석이나마 열강으로 인정받고 영국과 동맹 맺고.. 청일 러일 전쟁에서 이겼을 때 얼마나 도파민 뿜뿜했겠나?
왜군 사무라이가 갑자기 검은 군복 일본군으로 바뀌었고, 검은 군복이 또 카키색으로 바뀌었을 때가 일본의 역사에서 무척 중요한 전환점이었다.

-- 다만.. 일본은 그렇게 과학기술과 군사만 애매하게 근대화됐지 사회 분위기나 국민 의식수준, 민주화 척도 같은 건 전혀 서구 스타일이 아니었다.
그 상태로 폭주했더니 2차 대전 태평양 전쟁 때는 인외마경 급의 광기와 악행이 벌어졌다.

-- "일본 쇼와 천황에게 태평양 전쟁 범죄에 대한 책임이 있는가?"
이 케케묵은 질문은 성경으로 치면 "본디오 빌라도에게 예수님 죽음에 대한 책임이 있는가..?"와 아주 비슷한 유형인 것 같다. (책임이 없을 리가..)

-- 우리나라는 '통일 지향'을 명시하는 문구를 헌법에서 삭제할지, 군대를 모병제로 바꾸는 날이 올지 모르겠다.
일본은 설마 평화 헌법을 개정해서 자위대를 일본군으로 정식 승격시킬지 모르겠다.

10. 나머지 타 국가와의 비교

-- 일본은 55년 동안 자민당 장기집권기가 있었다. 우리나라는 장기간 휴전 중(사실상 종전)이고, 20년 넘게 군인 출신 대통령 집권기가 있었다. 대만은 1949년부터 1987년까지 38년 동안이나 계엄 상태였다고 한다;;
-- 1991년에 한국은 범죄와의 전쟁이 있었고, 일본은 야쿠자 특별법이 제정됐었다.

-- 한국이 전세가 발달했다면.. 일본은 사철이 발달한 것 같다. 미국은 치안이 private해졌고 일본은 철도 인프라가 많이 private해졌다.
-- 미국은 의료비가 너무 비싸서 회사 지원이 없으면 병원 한번 못 갈 거라는데.. 일본은 교통비가 너무 비싸서 회사 지원이 없으면 매일 신칸센 타고 도쿄로 출퇴근 엄두를 못 낼 거라고 그런다.

-- 한국 학교에서는 급식을 몽땅 무료로 하고 있다. 일본 학교에는 수영장이 보급돼 있다.
-- 일본은 컵라면의 원조이다. 한국은 커피믹스의 원조이다.

성경 용어: 예언 또는 대언

(사무엘) — Mon, 19 Oct 2026 19:35:00 +0900

1.
성경에는 prophe- 이라는 형태소로 시작하는 '예언' 관련 단어 3인방이 있다.
prophecy 예언(명사), prophesy 예언하다(동사), 그리고 prophet 저걸 행하는 사람 예언자(명사). 이건 매우 중요한 개념이다.
우리나라 기독교계에서는 개역성경의 표현인 '선지자'라는 번역도 익숙할 것이다.

그런데 '킹제임스 흠정역'은 저 prophe- 단어군(-sy, -cy, -t)을 한 치의 예외 없이 모두 '대언-'이라고 옮겼다. 이건 우리말 성경 중에 1990년대 중반, 안티오크 권위역에서 처음으로 시도했고 그걸 흠정역이 그대로 계승한 관행이다.

(0) '하나님으로부터 말씀을 받아서 대신 전하기, 또는 그렇게 전하는 사람'이라는 뜻에서 '대언'이 틀린 말은 아니다.
그러나 하나님의 말씀의 중요한 속성은 미래 예언이다. 성경이 인간의 개똥철학이 아니라 하나님의 영감받은 말씀인 증거 중 하나도 바로 예언이 확률적으로 절대 불가능할 정도로 문자적으로 많이 적중했다는 것에 있다.

쉽게 말해 성경의 모든 말씀이 하나님 말씀을 "대언"한 것이긴 한데, 그 대언 중에 (1) 미래 "예언"도 있다는 것이다. 관계가 이렇게 정리된다.
성경 중에서 요한계시록은 prophecy에 속하는 책이라고 분류된다. 이건 당연히 예언을 말한다. 후자까지 몽땅 대언이라고 싸잡아 풀이해 버리면 문제가 생긴다. 요한계시록이 성경 중에서도 어떤 특성을 갖는지를 알 수 없어진다. 사도행전이 교회의 역사서라면 계시록은 미래 예언서이지 않겠는가.

흠정역이 성경 번역으로서 매우 아쉬운 점은 성경에서 예언이라는 키워드를 완전히 없애 버렸다는 것이다. 이건 본인뿐만 아니라 여러 목사님들도 지적하며 우려하는 면모이다. 흠정역이 다른 부분에서는 완성도 높게 잘 번역된 것도 있지만, 이건 좀 아니다 싶다.
표면적인 이유는 예언이라고 하면 자꾸 은사주의 점쟁이의 예언 기도... 가령, "너는 몇 월 몇 일 몇 시에 무슨 일이 터질 것이고.. 이 번호의 로또를 사면 당첨될 것이다" 이런 걸 떠올리기 때문이라고 한다.
그래서 고린도전서 14장에다가 '예언'이라는 단어를 넣는 걸 껄끄러워한 것이다.

하지만 시한부 종말 갖고 뻘짓 하는 인간들이 있다고 해서 휴거나 종말, 예수 지상 재림이라는 개념 자체가 비성경적이고 잘못된 건 아니다. 그와 마찬가지로, 예언 갖고 이상한 뻘짓 하는 인간들이 있다고 해서 성경에 예언이라는 개념이 없는 건 아닐 것이다.

꼭 초자연적인 점쟁이급 예언이 아니더라도.. "너는 언젠가는 죽을 것이고 구원받지 못한 채 죄 가운데 죽는다면 지옥에 가게 된다" 같은 원론적인 얘기만으로도 이미 미래에 대한 예언이다. 그러면서 동시에 하나님 말씀을 대언한 것이다. 예언과 대언은 서로 대립하고 상충하는 관계가 아니다.

말씀 보존 학회에서는 흠정역을 20여 년째 아주 부정적으로 까내리고 비방하는 편인데.. "우리 한킹을 도둑질한 짝퉁" 같은 영양가 없는 저질 네거티브 말고 "예언이 없는 성경" 이런 식으로 흠정역의 진짜 약점에 대한 공략은 왜 안 하는지 모르겠다.

계 19:10 "... testimony of Jesus is the spirit of prophecy"의 경우, 옛날 한글 개역 성경에서는 '대언'이었다가 나중에 나온 개역개정에서는 '예언'으로 바뀌었다~!
이는 킹 제임스 계열이 아닌 성경을 만드는 진영에서도 prophecy의 번역이 쉽지 않은 고민거리라는 걸 시사한다. "예수 믿는 증거는 말씀 선포/대언" vs "예수님이 하나님인 증거는 미래 예언 능력" 이렇게 뉘앙스가 달라지기 때문이다.

그럼에도 불구하고, 대언에 예언이라는 뜻도 있다고 풀이하고 넘기는 것보다는..
반대로 예언에 대언이라는 뜻도 있다고 간주하는 게 솔직히 훨씬 더 나은 발상이 아닐까 싶다.
세상에서는 '예언'이라고 하면 점쟁이 예언을 떠올리지만 성경에서 말하는 예언은 미래 예언뿐만 아니라 하나님의 권위가 담긴 진리, 선언 등등이 다 포함된다고 뜻을 확장하는 게 나을 것이다. 그렇게 뜻을 확장하는 데는 대언보다는 그냥 예언이 더 유리하기 때문이다.

2.
예전에 흠정역 진영의 모 목사님이 쓰신 글을 보니 성경의 '예언'은 豫言(미리 예)이 아니라 預言(맡길 예)이라고 주장한 게 있었다.
엥? 그게 무슨 소리인지? 그 두 한자는 우리 국어에서는 딱히 유의미한 차이는 없다.
둘 다 '미리'라는 뜻이 있고, 預에 보조적으로 '맡기다'라는 훈이 덤으로 들어가 있는 정도이다.
잘 모르겠으면 사전 찾아보고 예+한자 한번 눌러 보시라.

옛날 국한문 혼용 개역성경에서 고린도전서 14장을 펴 봐도 내가 찾아보기로 다 豫言이다. 預言이 아니다.
더 옛날, 19세기 이 수정 번역본에서 預言을 썼는지는 모르겠는데, 내가 보기엔 그것조차도 그냥 '미리'라는 뜻에서 豫와 별 차이 없는 뉘앙스와 의도로 預를 쓴 것이다.
맨 처음에 預言으로 맞게 시작했다가 무슨 은사주의 물 먹어서 변질돼서 豫言으로 바뀐 것 같지는 않다.

우리말에서 예언, 예고, 예지, 예상.. 이런 미래의 의미일 때는 모두 豫이다.
예금, 예치, 예탁 등 금융 문맥에서나 '맡기다'라는 뜻으로 預가 들어간 게 고작이다. 그리고 이런 용례는 현대에 와서 일본어의 영향을 받아 도입됐을 뿐이다.

그럼 예언이 豫言이 아니라 預言이면, 저 조어 원리대로라면 돈이 아니라 말을 맡긴다는 뜻인가? 하나님 말씀이 아니라 자기 말을 남에게 맡긴다고??
그런 뉘앙스를 단어로 표현하려면 하다못해 '차력'이랑 같은 조어법으로 차언이라고 해야 한다! 借力도 자기 원래 힘이 아닌 원천을 빌려서 괴력을 발휘하는 거잖아. 차언은 이와 완전히 동일한 상황이 아니겠느냐 말이다. 이런 한자 구분은 사실도 아닐 뿐더러, '대언'의 옹호에도 별 도움이 되지 않아 보인다.

3.
한자가 무엇이건 '예언'에는
"앞으로 다가올 일을 미리 알거나 짐작하여 말함."(1) 이라는 뜻이 확장되어
"신탁을 받은 사람이 하나님으로부터 직접 계시된 진리를 사람들에게 전하는 일, 또는 그런 말"(2)이라고 아주 훌륭한 뜻풀이가 국어사전에 등재돼 있다.

표준 국어대사전을 인용했다는 네이버 사전에는 (2)가 豫言에 들어가 있고, 고려대 한국어 사전도 그러하다.
현재 표준 국어대사전의 공식 홈페이지에는 (2)가 預言로 옮겨지긴 했는데, 이건 아마 후대에 인위로 수정 변경된 것으로 보인다. 그러니 네이버 사전과 결과가 다른 거겠지..
이런 차이점에서 알 수 있듯, 豫와 預는 처음부터 의미가 칼같이 딱 구분돼 있지 않았다.

이 '예언'은 고린도전서 14장 일대에서는 거의 다 말씀 선포, 설교에 가까운 의미이다. 사실, '방언'조차도 이 문맥에서는 타 외국어로 설교를 한다는 뜻이다. 종합하면 "예언이 방언보다 낫다"는 말은 "말씀 선포를 자국어로 하는 게 외국어로 하는 것보다 더 낫다"는 뜻이 된다.

그리고 복음서에서 폭도들이 예수님을 결박한 뒤, 눈 가리고 죽빵 날리고서 한 말이 "누가 너 때렸게? 알아맞혀 봐라 ㅋㅋㅋ"이었다. 이 '알아맞히다'는 prophesy이다.
에스겔 37장에서 메마른 뼈들을 살아나라고 선포 내지 주문을(?) 외우는 것도 prophesy였다.
계시록 19:10 예수님의 증언이 prophecy의 영.. 이건 아까 언급했었고.

이 모든 상황을 가장 잘 커버하는 의미는 "하나님으로부터 직접 계시된 진리"라는 뜻인 예언(2)이다. 그 진리 중에 "미래에 일어날 일"도 있을 수 있으며.. 그걸 인간이 전한다는 뜻에서 대언이라는 뉘앙스가 저절로 포함된다.
출 7:1 "모세는 신이고 아론은 모세의 prophet"이 될 것이다.. 요 구절이 그나마 거창한 예언자 선지자가 아니라 단순 대변인, 대언자와 가장 가까운 용례이다. 마치 히브리서 9장에서 언약과 유언(16절)이 갈리는 것 같은 미묘한 상황이 된다.

그 반면, 대언(0)에는 표준 국어 대사전 어디에도 기독교적인 의미가 공식적으로 없다. 보충 설명을 더 많이 해 줘야 된다.
겨우 은사주의 예언기도(!!!) 뻘짓을 두려워해서 성경에서 예언이라는 개념을 모조리 없애 버리고, 별자리 점쟁이들한테나 예언을 남겨두는 건(사 47:13).. 좀 많이 무리수가 아닐지?
그건 신천지들이 성경 공부 많이 한다니까 우리는 성경 공부 하지 말자는 식의 발상이다.

성경은 애초에 참 선지자와 거짓 선지자를 구분하는 기준부터 미래 예언이 이뤄지느냐, 빗나가느냐(신18:22)였다.
예언의 세속적인 원래 뜻 (1)을 먼저 존중하고서, 성경적으로 (2)라는 용례와 의미도 더 있다고 보조하는 쪽으로 이해하는 게 더 자연스러울 것이다. 그 시작점은 (0) 대언보다는 (1) 예언이 더 적절하다고 하겠다.

날개셋 한글 입력기 11.01, 타자연습 4.01

(사무엘) — Thu, 15 Oct 2026 08:35:00 +0900

2026년의 끝을 앞두고 날개셋 브랜드 프로그램이 소폭 버전업됐다. 늘 그렇듯이 유용하게 사용하시기 바란다.
입력기에 ARM64EC 지원이 추가됐다는 소식은 예전에 귀가 따갑도록 전했으니 그 얘기는 또 하지 않겠다. 그것 말고 또 바뀌거나 달라진 내역은 다음과 같다.

1. 스크롤바 개선

이 프로그램에서 자체 구현하여 제공하는 스크롤바의 아주 아주 오랜 고질병을 고쳤다. 이 스크롤바는 문자표, 부수 한자 입력 같은 입력 도구에도 있고, 외부 모듈의 한자 변환 UI에서도 볼 수 있다.

◀▶▲▼ 같은 thumb이나, 막대 자체를 아주 잠깐만 클릭하고 뗐는데도 스크롤이 기본적으로 2단계씩 되던 것,
그리고 정작 그것들을 오랫동안 누르고 있으면 스크롤 속도가 너무 느리던 것 말이다.
이를 드디어 개선하여 운영체제의 표준 스크롤바와 거의 동일하게 동작하게 했다. 짧게 눌렀다 떼면 한 단계만 스크롤되고, 오래 누르고 있으면 빠르게 스크롤된다.

그리고 운영체제의 스크롤바는 막대를 shift+클릭하면 그 지점으로 바로 이동하는 기능이 있다. 이것도 내 한글 입력기의 스크롤바에서 지원되게 했다.
요 기능을 넣는 과정에서 저 고질병도 이번 기회에 조치를 취했다. 너무 늦은 감이 있지만 유의미한 개선이다.

2. 편집기에서 글꼴 목록을 표시하는 방식을 개선

날개셋 편집기의 '편집 화면 설정'에서 볼 수 있는 요 글꼴 목록 말이다.
일단, 예문을 나타내는 회색이 기존 일반적인 검정색과 잘 구분돼 보이지 않아서 색을 더 약하게 바꿨다. 이건 Windows 10/11에서 system color값이 바뀌어서 발생한 현상이다. (왜 이렇게 바꿨는지..)

그리고 예문에서 '아래아 한'이 옛한글 지원 글꼴을 나타내듯, 그 다음 '굩'이라는 글자는 KS X 1001 완성형에 없는 글자이다. 완성형 글꼴의 예문에서는 이 글자가 표시되지 않게 함으로써 자연스럽게 글꼴의 한계를 알 수 있게 했다.

끝으로, 위의 스크린샷에서 볼 수 있듯..
글꼴 이름이 너무 길어서 예문까지 한 줄에 모두 표시할 수 없을 때 말이다.
일반적인 경우라면 글꼴 이름을 다 표시하기 위해 예문을 저렇게 밀어내고 짜른다.
그러나 글꼴 이름에 해당 문자가 충분히 들어있지 않으면.. 반대로 글꼴을 짜르고 예문을 원래 있던 곳에 변함없이 표시하게 했다.

한글 글꼴의 이름이 영문이 잔뜩 들어있고 길기까지 하다면.. 이건 굳이 이 자리에서 표시할 필요가 없다고 간주되기 때문이다. 영문 글꼴의 이름에 영문 이외의 문자가 많이 들어있는 경우에도 마찬가지이다.
물론 프로그램에서 기본 제공되는 글꼴만으로는 이 로직이 동작하는 것을 볼 일이 없다. 하지만 저런 경우에 더 똑똑하게 대비하는 로직이 미리 구현되었다.

3. 나머지 정말 사소하고 자잘한 것들

- 상태 표시줄에 '블록 n개'라는 표시는 블록을 2개 이상 만들었을 때만 표시하게 했다. 1개만 만들었을 때는 그냥 가만히 있는 게 더 나아 보인다.

- 파일명이 없는(= 아직 저장을 한 적 없는) 빈 문서에서 저장 옵션(인코딩 등)만 변경했는데도 그 창을 닫을 때 저장 확인 질문이 나오던 것을 수정했다. ㄲㄲㄲ

- 편집기의 열기-저장 대화상자에 기본적으로 뜨는 확장자 필터가 다음과 같이 바뀌었다. 일반 텍스트, 정형화된 데이터, 웹 관련, 명령 스크립트 이렇게 카테고리를 4개로 나눠서 자주 쓰이는 확장자를 신속하게 고를 수 있게 했다.
다만, 날개셋 편집기는 전문적인 프로그래머용 에디터가 아닌 관계로, 프로그래밍 언어들의 확장자를 이런 식으로 일일이 나열은 일부러 하지 않았다.

- 세로쓰기 상태에서 90도로 돌려져서 표시되는 전각 부호를 10여 종류 더 추가했다.
- 프로그램 도움말에는.. 프로그램 설치와 관련하여 스마트 앱 컨트롤을 꺼 보라는 말을 추가했다.

- 프로그램의 설정 저장과 관련하여 일단 일반적인 사용자에게는 거의 존재감이 없을 논리 불일치 버그가 하나 있었는데.. 코딩 AI가 의심해서 찾아준 게 맞았다. 하나 잡았다.

- About처럼 내용 결과를 보고 닫는 버튼 하나밖에 없는 대화상자에 대해서 내 프로그램은 전통적으로 버튼 이름을 '닫기'라고 붙이곤 했는데.. 이것을 도로 '확인'으로 변경했다. 영문으로는 어차피 똑같이 OK이기도 하니..

4. 타자연습 4.01

타자연습은 작년 여름에 오랜만에 4.0이 나왔었다. 64비트로 포팅, 굴림체 UI 탈피 같은 최소한의 구색내기를 했다.
이번 새 버전에서는 프로그램이 영문 Windows에서 실행될 때 자잘한 glitch가 있던 것을 주로 해결했다. 과거 3.x 버전에서는 존재하지 않다가 코드 리팩터링과 포팅 과정에서 재발했던 문제를 다시 해결한 것에 가깝다.

- 기본 코드페이지가 cp949가 아닌 곳에서 콤보박스의 내장 데이터값이 깨지는 거,
- 기본 언어가 한국어가 아닌 곳에서 프로그램 창이 맑은 고딕 대신 다른 폰트로 지정되어서 한글이.. 깨지지는 않지만 너무 작고 알아보기 힘들게 찍히는 것,
- 150% hdpi 환경에서 좌우 대조 긴글 연습 대화상자의 아래쪽이 살짝 깨지는 것, '통계'의 그래프 숫자들이 아래가 짤리는 것 (폰트 폭 계산이 맑은 고딕 특유의 줄 간격을 반영하지 못해서)

요것들을 말끔히 해결했다. 원래부터 100% dpi에 한글 Windows를 사용해 오신 분은 업데이트할 필요가 별로 없으실지도 모르겠지만ㅠㅠ, 그 외에도..

- 날개셋 편집기에서 글꼴 목록 콤보박스의 로직이 개선된 것 역시.. 타자연습에도 동일하게 적용됐다.
- 도움말의 세벌식 FAQ에 신세벌식이나 3-18Na처럼 중-종성 절충 세벌식에 대한 설명을 더 추가했다.

- 이 프로그램은 날개셋 한글 입력기 없이 단독으로 설치해도 글꼴만 기본 내장 글꼴로 고정될 뿐 사용은 가능하다. 단, 기본 내장 글꼴은 16픽셀 것만 제공된다. 이게 없으면 까마득히 높은 dpi 환경에서도 프로그램이 16픽셀 형태로만 실행된다.
24픽셀 글꼴을 사용하려면 결국 글꼴 파일이 온전히 들어있는 한글 입력기 본체를 설치해야 하는데.. 이에 대한 설명이 별로 없어서 도움말과 프로그램 메시지 상으로도 추가했다.
날개셋 한글 입력기 없이 타자연습만 설치해서 쓰는 건.. 뭔가 테란 스타포트를 지어 놓고 컨트롤 타워 애드온 없이 그냥 레이쓰만 뽑는 것과 비슷하게 보일 수 있다.;;;

그나저나, 타자연습도 마음만 먹으면 ARM64 전용 에디션을 만들 수는 있지만 아직 보류했다.
ARM64 기기에서도 사용하는 데 아무 불편이 없고, 이런 x64용 프로그램에서는 날개셋 한글 입력기도 ARM64EC 에디션이 잘 돌아가고 있기 때문이다. 당분간 타자연습은 x64만 밀고 나갈 것이다.

5. 타자연습 게임의 글자 투명색 버그

끝으로, 날개셋 타자 게임에서 떨어지는 단어들이 투명 배경색이 제대로 처리되지 못하고 이렇게 표시되는 걸... 목격하신 분이 혹시 계신가?

타자 게임은 주요 로직이 20년 넘게 전에 완성돼서 지금까지 이어지고 있는 엄청난 고인물이다. 그런데 저런 오동작이 발생하는 걸 본인은 요 근래에 직장의 PC에서 난생 처음으로 구경했다.
그래서 언제 날잡아서 디버깅 좀 해야겠다고 마음먹었는데.. 그만 PC가 바뀌어 버렸고, 새 컴에서는 애석하게도 그 문제가 더 재연되지 않았다;;;;;

그렇잖아도 이번 타자연습 4.01에서는 자잘하게 버그가 고쳐진 게 많은데, 이 참에 저 버그도 같이 좀 고쳐졌으면 좋겠다 싶었는데..ㅠㅠㅠ
다행히 ARM64 환경 개발용으로 사용하던 MS 서피스 장비에서도 놀랍게도 똑같은 문제가 발생했다. 그래서 이걸 기준으로 버그를 고쳤다. 만세~! 서피스가 정말 유용하게 쓰이고 있다.
그래픽 알고리즘이나 픽셀 format에 문제가 있는 건 아니었다. 2020년대 이후의 그래픽 드라이버의 동작이 살짝 달라진 듯.. ㄲㄲㄲㄲ 호환성 관련 플래그만 하나 추가하니 저 현상이 사라졌다.

Visual C++의 유구한 역사 -- 下

(사무엘) — Sun, 11 Oct 2026 08:35:00 +0900

※ 10.0 (2010)

2008 이후 2010도 참 걸출한 작품이었다.
IDE가 MS Office 엔진이 아닌 WPF 기반으로 다시 만들어졌으며, 프로젝트 파일은 현재처럼 확장자에 x자가 붙고 내부 형식이 미묘하게 달라졌다. IDE와 툴체인 및 SDK 간의 분리가 가능해지고 융통성이 생겼다.
인텔리센스 엔진이 구닥다리 ncb 파일을 버리고, 전문적인 백그라운드 컴파일러와 DB 엔진을 기반으로 전면 개편됐다. 덕분에 정확도가 6.0이나 200x 시절보다 훨씬 더 향상됐다. 그리고 이제 #include 헤더 파일에 대해서도 우클릭해서 '요 파일 열기'가 가능해졌다.

CRT와 MFC DLL에 대해 side-by-side assembly 강제 정책은 철회됐으며... C++11 문법이 초보적인 수준으로나마 도입됐다. R-value 참조자 &&라든가 auto 람다 함수를 쓸 수 있게 됐다.
다만, 내 개인적으로는 시퍼런 IDE 외형이 좀 구리고 이질적으로;; 느껴진다. 그리고 UI 요소를 customize할 때 toolbar의 폭을 마우스 드래그가 아니라 픽셀수 숫자로 입력한다던가(뜨악~);; 몇몇 UI 기능은 200x시절보다 불편해졌다.
그게 오늘날 202x까지 개선 없이 그대로 이어지고 있다. 개발 우선순위가 낮아서 그런지 이런 것까지 살펴볼 여유가 없는가 보다.

※ 2012 (버전 11)

얘는 일단 IDE의 외형이.. 그 시절 유행하던 Windows 8 metro 디자인 물을 먹었는지 아주 새끈한 은백색 풍으로 바뀌었다. 프로그램 창에서 caption이나 border 같은 non-client 영역까지 전부 운영체제의 표준 외형을 벗어난 첫 버전이 바로 2012이다.

개발툴로서는 같은 최적화 세팅에서 컴파일 속도가 2010보다 더 빨라졌고.. 정적 분석이 bundle로 제공되기 시작했다.
신택스 컬러링도 예전보다 더 컬러풀해져서 #define, typedef, num 등이 모두 구분되어 나오기 시작했다.
#if에 걸려서 컴파일되지 않는 부분이 흐려지기 시작한 건 2010부터인지 2012부터인지 모르겠다. 200x는 확실히 아니었음..

그리고 이 버전부터 서비스 팩이라는 게 없어지고 update N 이렇게 명칭이 바뀌었다. 마소 제품들은 2010년을 전후한 Windows 7, Office 2010, Visual Studio 2010이 서비스 팩이란 게 존재했던 마지막 버전이었다.
로컬 하드에 설치 저장되던 방대한 규모의 MSDN 레퍼런스도 이때부터 사실상 없어졌다.

※ 2013 (버전 12)

2012 이후로 겨우 1년 남짓 만에 메이저 버전이 또 올라갔다. 마치 Windows 8과 8.1의 관계인 것 같은데..

얘는 C++11 문법 지원이 더 강화된 것, 그리고 무엇보다 Express 에디션 대신, 개인/인디 개발자를 위한 Community 에디션이 도입된 것이 크게 기억에 남는다.
Community 에디션은 5인 이하, 매출 얼마 이하의 소규모 인디 개발자이기만 하면 무료로 사용 가능하다. Express에서는 봉인돼 있던 MFC고 x64고 다 사용 가능하다. 2010년대의 컴퓨팅 환경에서 MFC는 몰라도 이제 x64 타겟을 만들 수 없다는 건 어불성설이 됐으니까..

뭐, Visual Studio만 그런 건 아니겠지만 요즘 버전들은 시리얼 번호 입력이란 게 없이 바로 설치 가능하다. 그 대신 실행 후에 마소 계정 로그인이 필요해졌을 뿐이다. 선설치, 후접속 결제인 듯..

※ 2015 (버전 14)

얘는 CRT 체계가 Windows 10 스타일로 전면 개편된 것이 가장 중요하다. 이때부터 지금까지 툴체인의 메이저 버전이 14, _MSC_VER 값도 19xx대로 변함없이 유지되고 있기 때문이다. vcruntime140, mfc140, msvcp140 말이다. Visual Studio의 버전만 올라가지, 툴체인은 메이저 버전이 올라가지 않기 시작했다.

그리고 2010 시절에 전면 개편됐던 인텔리센스 겸 심벌 browse DB의 내부 구조도 2015의 어느 업데이트 때부터 야금야금 바뀌었다. 원래 *.sdf 파일을 쓰던 게 *.VC.db 라고 바뀌었으며, DB 엔진도 자기네 Microsoft SQL Server Compact edition을 쓰던 게 SQLite로 교체됐다. 이것도 오늘날까지 이어지는 꽤 중요한 변화이다.
2015 이전 버전은 Visual Studio를 설치하면서 MS SQL server 2008이니 어쩌구가 야금야금 같이 설치됐던 반면, 현재는 그런 관행이 없어졌다.

※ 2017 (버전 15)

얘는 프로그램의 설치 및 업데이트 시스템이 현재 형태로 전면 개편된 최초의 버전이다. 소규모 업데이트도 워낙 잦아지니 지금처럼 버전 번호에 숫자를 하나 더 추가하는 형태로 바꿨다. (그러므로 Update N라는 표기는 2012부터 2015까지만 사용된 셈..)
IDE의 기본 색상도 흰색이 아니라 약간 연보라색 같은 파란색.. 지금과 비슷해졌다. 이렇게 2010년대 전반부 버전과 후반부 버전 사이의 차별화가 진행됐다.

세월이 세월이니 C++14 문법과 라이브러리도 야금야금 도입됐다. 가령, unique_ptr뿐만 아니라 make_unique도 사용할 수 있게 됐다. 일반적인 함수뿐만 아니라 매크로 함수나 람다에다가도 가변인자를 넣을 수 있게 됐다.

※ 2019 (버전 16)

IDE의 색상에 연보라색이 2017보다 더 가미되어 채도가 올라갔다. 2017은 제목 표시줄에 Visual Studio라는 이름이 있었지만 2019부터는 그게 빠지고 최상단에 메뉴가 바로 표시되기 시작했다.
2019의 초창기 버전은 내 기억으로 win32 대화상자 리소스를 편집하던 중에 IDE가 잘 뻗기도 했었다. 여러 업데이트를 거치면서 그 버그는 다행히 고쳐졌다.

아 참, 이 2019 시기에.. 마소의 C++ 라이브러리에 꽤 흥미로운 변화가 생겼다.
Visual C++은 200x 시절부터 전통적으로 Dinkumware 사의 STL을 라이선스 받아 공급해 왔으며, 이 때문에 헤더 파일의 뒷부분에 언제나 P. J. Plauger라는 제작자와 제작사 이름이 들어가 있었다. 그랬는데 마소에서는 2019 하반기부로 이 라이브러리를 오픈소스화하고 자체 관리하기 시작했다. 그러면서 Dinkumware 관련 copyright 문구가 사라졌다.
사실, C++ 라이브러리는 갈수록 언어 구조에 종속적이고 내부 구현도 컴파일러 제조사의 재량에 종속적인 형태로 바뀌어 가는 게 요즘 추세라고 한다.

※ 2022 (버전 17)
IDE 자체가 드디어 64비트로 포팅됐다...!! 이걸로 끝..???

※ 2026
테마가 자매품인 Visual Studio Code 급으로 엄청 다양해지고 휘황찬란해졌다는 것밖에 아직 확인을 못 했다.;;

이상이다.
개인적으로 날개셋 한글 입력기의 개발이나 직장 현업 용도로 진지하게 오래 써 본 버전은 6.0, 2003, 2010, 2012, 2019, 2022 정도이다.

(1) Browse info에 대해

Visual C++은 아주 초창기 시절부터, 빌드 때 겸사겸사 browse info를 같이 생성하는(.sbr, .bsc) 기능이 있었다.
물론 이건 빌드 시간과 디스크 공간을 추가로 소모하는 작업이기 때문에 사용자가 원해서 옵션으로 지정했을 때만 수행한다. 지금도 프로젝트 설정 대화상자를 열어보면 C/C++의 아래에 Browse info라는 카테고리로 당당히 남아있다.

하지만 오늘날은 매번 빌드하지 않고도 IDE에서 소스 코드의 심벌을 실시간으로 조회하는 기술이 눈부시게 발달했다. 그렇기 때문에 이 browse info 기능은 완전히 과거 레거시가 돼서 거의 쓰이지 않는 기능이 됐다. 다만, 업계에서 이 sbr/bsc 파일을 이용해서 다른 분석을 하는 3rd-party 툴 제품이 있기는 하다고 한다.
오늘날은 소스코드를 컴파일하는 과정에서 '덤'으로 할 만한 작업은 정적 분석인 듯하다. 허나, 이젠 그마저도 on-the-fly로 수행돼서 의심 지점을 소스코드의 밑줄로 쫙 쳐서 표시하는 경지에 이르렀다.

(2) 버전 체계에 대해

Visual C++은 버전 관리 체계가 생각보다 복잡하다. 크게 세 가지 버전 시스템이 있다.

- Visual Studio IDE 자체의 버전: Help - About 대화상자에서 볼 수 있는 그 버전이다. 새로운 연도 브랜드가 출시될 때마다 메이저 버전 번호가 1씩 올라간다. 6.0 이후로 2010의 버전은 10이었고, 2015는 14, 2022의 버전은 17까지 올라갔다. 버전 13은 건너뛰었다.

- 툴체인의 버전: 오랫동안 Visual C++ IDE의 버전과 동일하다가(13을 skip한 것까지) 2015 및 Windows 10 때부터 14에서 멈췄다. CRT/MFC DLL의 ABI와도 버전이 연계되는지, 현재는 마이너 버전만 쭉 올라가고 있다. 프로젝트 세팅의 '플랫폼 도구 집합'에 해당한다.

- 컴파일러의 버전: cl.exe를 실행했을 때, 또는 소스 코드에서 _MSC_VER의 값을 넣어서 확인 가능한 버전이다. 얘는 Visual C++의 전신인 Microsoft C/C++의 버전값을 승계했기 때문에 Visual C++ 1.0 시절에 이미 800부터 시작됐다. MS C/C++의 마지막 버전이 7이었고, VC++ 1은 MS C/C++ 8과 같다고 간주됐기 때문이다.
다만, Visual C++ 2에서 4로 넘어갔을 때는 값이 200이 아니라 100만 늘었다. VC++ 6의 컴파일러 버전은 500이 아니라 400이 증가한 1200이었다. (12.0)

그 뒤 IDE의 버전이 14인 2015에서는 800이 아니라 700이 증가한 19.0에 도달했고(13 skip이 없으므로), 이때부터는 툴체인의 버전과 마찬가지로 메이저 버전의 번호가 오르지 않고 있다.

Visual C++의 유구한 역사 -- 上

(사무엘) — Wed, 07 Oct 2026 19:35:00 +0900

* 무려 2010년쯤에, 2008 버전이 최신이었던 시절에 썼던 글을 내용을 보강하고 업데이트 하여 다시 올렸다. 심지어 분량이 엄청나게 늘어나서 글을 둘로 나눴다.

※ 1.0

(스샷의 출처는 Malcolm Smith (malxau)이라는 분의 유명 홈페이지)

1993년에 출시된 Visual C++ 1.0은 Microsoft C/C++ 7.0의 차기 버전 겸 Windows NT 전속 개발툴 역할을 하기 시작했다. 이웃 BASIC 팀에서 MS Basic PDS 7의 다음 버전이 Visual Basic이라고 선례를 남겼으니, C/C++ 팀도 비슷한 작명을 도입했던 게 아닌가 싶다. BASIC은 RAD 툴로 바뀌었고 C/C++은 32비트로 갈아탔다.

물론 이때는 16비트에서 32비트로 한창 넘어가는 과도기였기 때문에 Win32s 타겟이 지원되기도 했다. 그리고 Win32s가 아닌 순수 16비트용 에디션도 나중에 출시되기는 했다. (VB 1도 Windows용 이후에 DOS용이 따로 출시됐듯이..) 하지만 VC++ 16비트용은 개발 계보가 32비트 에디션과는 상이했다.

32비트 환경에서는 메모리 모델 구분이 없는 대신, CRT에 링크 방식(static/DLL)과 멀티스레드 지원 여부라는 속성이 새로 도입되었다.
참고로 Visual Basic은 1996년엔가, 버전 4에서야 32비트가 도입됐다는 것도 기억할 점이다. 16/32비트 에디션이 따로 나왔으며, VB5부터는 32비트 전용으로 바뀌었다.

※ 1.52

얘는 16비트 Windows를 정식 지원하는 마지막 버전이어서 매우 중요하다.
프론트 엔드 IDE는 모두 16비트 Windows 프로그램인 반면, 커맨드 라인에서 동작하는 컴파일러, 링커 같은 주요 툴들은 도스 익스텐더 stub을 내장하고 있는 32비트 PE 포맷인 점이 무척 인상적이다.

※ 2.0

이제부터 완전히 32비트 전용으로 바뀌었다. 하지만 이때는 아직 Windows 95가 나오기도 전이고 NT는 인지도와 점유율이 아주 미미했었다. 그래서 VC++ 역시 아직까지는 별 존재감이 없고 주목을 못 받았다. 아직까지는 16비트 Windows에서 볼랜드의 OWL 라이브러리도 쌩쌩히 현역이었다.

Windows 95의 워드패드가 바로 듣보잡 MFC 3.0 기반이었는데, 이게 Visual C++ 2.0의 흔적이다.
그리고 이 시절 Visual C++ RISC edition 어쩌구 하던 건 Windows CE가 아니라 NT를 염두에 둔 타겟이었다. 이건 eMbedded Visual C++과는 다른 제품군이었다.

※ 4.0

DirectX에는 4라는 버전이 없듯, Visual C++에는 3.x대 버전이 없다. 내부적으로 꾸준히 버전업이 돼 온 MFC의 버전 번호에 맞춰 곧바로 4.0으로 건너뛰게 된다.
VC++ 4.0은 Windows NT뿐만 아니라 정통 95용 32비트 프로그램을 만들 수 있다는 이점으로 인해 인지도가 급격히 올라갔다. IE가 넷스케이프를 제쳤듯이 Visual C++이 Borland C++을 제치기 시작했다.

4.0에 와서야 비로소 IDE가 오늘날의 Visual C++과 비슷한 골격이 갖춰졌다. 즉 코딩, 리소스 편집, 클래스 마법사, 도움말 열람을 모두 한 프로그램에서 할 수 있는 진정한 통합 환경 Developer Studio가 이 버전부터 생겼다.
msdev.exe라는 프로그램 이름은 훗날 6.0까지 이어졌다. MFC ClassWizard라든가, ClassView도 이때 도입됐다.

※ 4.2

4.1을 거쳐 4.0이 마이너 업그레이드된 버전으로, 제법 인지도를 얻었다. ActiveX 컨트롤, STL 같은 기능이 추가되고 MFC DLL의 이름도 이때부터 MFC42로 이름이 바뀌어 큰 뼈대의 변경 없이 훗날의 6.0까지 이어졌다. MFC42는 윈도우 98 이래로 운영체제가 이제 known DLL로 인정하는 마지막 버전 숫자이기도 하니 더욱 의미가 있다.

4.2에서부터 Win32s의 지원이 중단되었다. 오죽했으면 설치할 때 “이 버전부터 Win32s를 더 지원하지 않으니, 그 환경 개발하고 싶으면 이거 설치하지 말고 옛날 버전 쓰셈!”이란 경고문까지 나온다.

※ 5.0

얘와 6은 도구모음줄과 메뉴가 MS Office 97 스타일로 바뀌었다. 다만, 5는 도움말은 여전히 RTF 기반이고 인텔리센스도 아직 없었다.
외형뿐만 아니라 내부 기능도.. 한번에 여러 프로젝트들을 담을 수 있는 workspace 개념이 이때 도입됐다. 단, dsw/dsp라는 파일 포맷 자체는 5와 6 두 버전에서만 쓰이고 이후 버전에서는 또 바뀌게 되었다.

몇몇 C++ 최신 표준이 반영되어 bool이 built-in type으로 지원되기 시작했다. 그리고 이때부터 빌드하는 EXE 파일에 PE 재배치 정보가 기본적으로 생략되었으며.. 그 유명한 Rich 시그니처가 슬쩍 들어가기 시작했다.
다만, 이 5.0은 이듬해에 나온 6.0에 밀려 존재감을 완전히 상실했다. 뭔가 아래아한글 97이 나오기 전의 96이 묻혀 버린 것과 비슷하달까?

※ 6.0

개발툴계의 Windows XP 같은 만수장세 결정판이었다. 이 버전 이후로 거의 4년 가까이 버전업이 없었고, 다음 버전인 닷넷이 변화폭이 너무 크기도 했기 때문이다.

6에서는 인텔리센스(초보적인 수준), edit and continue, delay-loaded DLL 같은 획기적인 기능이 처음으로 추가되고 도움말이 별도의 MSDN 라이브러리로 독립함과 동시에 HTML 기반으로 모두 바뀌었다.
이 버전은 윈도우 9x에서 설치 가능한 마지막 버전임과 동시에 MSVCRT, MFC42 같은 known DLL만 사용하는 바이너리를 생성할 수 있는 마지막 버전이기도 하다. 주요 라이브러리를 DLL 링크하고도 DLL 배포 걱정을 할 필요가 전혀 없다는 장점이 있다.

4.2 때는 ClassView에 있는 각종 클래스, 변수 정보가 소스 파일을 매번 저장할 때에만 업데이트됐다. 이것이 내용이 바뀔 때마다 실시간으로 바뀌기 시작한 것도 5.0은 아니고 6.0부터인 걸로 기억한다.
Visual C++이 C++ 표준을 준수하지 않는다고 비판이 많긴 했지만, 라이브러리의 헤더 파일에서 .h 확장자가 없어지고 namespace std가 도입된 건 6.0부터였지 싶다.

※ 7.1 (2003)

Visual C++의 다음 버전은 처음엔, 버전 번호나 연도가 아닌 닷넷이라는 브랜드로 출시되었다.
MFC를 써서 개발된 VC 특유의 전통적인 msdev.exe는 퇴출되고 devenv라는 MS Office 내지 VB 스타일의 IDE가 등장했됐다. 이는 완전히 새로운 것이라기보다는 예전에 Visual Studio에 있던 Visual InterDev와 비슷한 형태였다. 단지 거기에다 외형만 MS 오피스 XP 스타일 UI를 그대로 물려받았다.

덕분에 Visual C++과는 영 인연이 없고 VB만의 전유물인 것 같던 Property grid가 도입되어 Visual C++ IDE 특유의 납작한 등록정보 대화상자를 대체했다. 클래스 마법사도 이 형태로 대체됐다. 도움말은 5.0 시절처럼 IDE 내부에 띄울 수도 있고 6.0처럼 외부에 띄울 수도 있는 융통성 있는 형태로 바뀌었다.
dsw/dsp 대신, sln(솔루션)과 vcproj 요렇게 프로젝트 파일의 확장자와 포맷이 바뀌었다.

이제 주류로 내세운 게 C#, 공용 언어 런타임 같은 닷넷 환경이긴 했지만 네이티브 C/C++ 쪽도 크게 향상되었다. 네이티브 wchar_t 형식이 지원되기 시작했다.
6에서 첫 도입됐던 인텔리센스도 굉장히 강력해져 특히 #define 매크로 심볼에 대해서도 동작하기 시작했다. 별도의 browse info를 만들지 않아도 선언/정의로 가기 기능을 바로 사용할 수도 있게 됐다. 닷넷 정도만 써 보면 이제 6.0은 충분히 열악함을 느끼기에 충분할 것이다.

64비트 크로스컴파일은 불가능하지는 않으나 불편하고 디버깅도 되지 않고 IDE 차원의 적극적인 보조는 못 받는 어정쩡한 위상을 차지하고 있다. 이 불완전한 면모들은 후속 버전인 8에서 보완되었다.

참고로.. 2003 이전, 2002년에 Visual Studio .NET이라는 이름으로 먼저 출시된 버전 7.0은 정말 놀라울 정도로 존재감 없이 신속히 잊혀졌다.
글쎄, 6.0 이후로 오랫동안 버전업이 없다가 닷넷과 CLR이라는 걸 도입한 첫 버전이니 너무 불안정하고 버그가 많았던 걸까? 저 제품에 대해서는 내가 아는 게 없다. 금세 .NET 2003 (7.1)으로 대체됐다.

※ 8.0 (2005)

얘도 생각해 보니 변화가 굉장히 많았다.
for 문의 변수 scope처럼 그동안 Visual C++ 컴파일러가 표준을 어기고 있던 문법을 교정했으며.. 멀티코어를 표방했는지 빌드 로그에 코어 번호가 왼쪽에 표시되기 시작했다.
CRT의 보안이 이때 크게 강화됐다. strcpy_s와 gets_s(대상 버퍼 크기), qsort_s(콜백 함수에 데이터 전달 가능), strtok_s(토큰 중복 호출 가능) 같은 함수가 새롭게 등장하고 strchr 같은 경우, C++에서는 const 포인터를 되돌리는 버전과 비const 포인터를 되돌리는 함수가 오버로딩으로 분리해 나갔다. 무척 신선한 변화라 느껴진다. STL 디버깅도 훨씬 더 편해졌다.

이 버전부터 별도의 플랫폼 SDK를 설치할 필요 없이 IDE 차원에서 x64 타겟 빌드와 디버깅이 정식 지원되기 시작했다.
그리고 이때 MSVCR80, MFC80의 배포 방식이 side-by-side assembly 방식으로 완전히 바뀌었다. 이와 덩달아, 리소스 편집기로 수동으로 해야 하던 메니페스트 생성/편집 기능도 상당 부분 자동화됐다.
이 버전부터는 생성하는 프로젝트의 디폴트 기반 인코딩이 드디어 유니코드로 바뀌었다.

UI 상으로도 이제 MS 오피스 스타일에서 독립한 새로운 외형 비주얼을 갖기 시작했으며, 도구모음줄 아이콘도 256색으로 더 화려해졌다. 전통적으로 ClassView에 클래스와 멤버들이 한 트리에 쫙 나열되던 것이 멤버는 별도의 리스트에 뜨도록 바뀌기도 했다. 도킹 창을 드래그할 때 나타나는 도킹 다이아몬드도 2005에서 첫 도입된 물건이다.
Visual Studio의 무료 에디션인 Express 에디션이 이때 첫 도입됐다. (무료이지만 MFC 없고 64비트 타겟도 미지원)

※ 9.0 (2008)

8이 질적으로 많이 바뀌었다면 9는 Windows Vista의 등장처럼 8 출시 이후에 생긴 변화를 IDE나 MFC 라이브러리 같은 데에 적극 반영하여 양적인 향상을 꾀했다. 일단 MS Office 스타일의 GUI를 손쉽게 만들 수 있는 feature pack을 MFC에 드디어 도입했다.
그리고 2005는 설치하려면 sp1에, Vista 지원 패치.. 등 덕지덕지 땜빵을 해야 할 게 많았는데 2008은 그걸 당연히 모두 기본 접수했다.

Windows Vista에서 도입된 시작 주소 랜덤화 기능이 요 2008에서 정식 추가됐다. 2008에서는 이 보안 기능을 사용하는 EXE를 만들 수 있다는 뜻이다.
10여 년 전, 5.0에서 누락되기 시작한 EXE의 재배치 정보가 2008부터는 기본적으로 다시 들어가기 시작했다. 옛날에는 fixed address를 지원하지 않는 win32s와의 호환 때문에 그게 필요했었지만, 지금은 보안 기능 때문에 필요해진 것이다.

2008은 설치하기 위해 Windows XP 이상을 요구하며(2000 지원 중단), 지원하는 타겟 플랫폼에서도 Windows 9x는 공식적으로 완전히 제외됐다. 링커 옵션에서 바이너리의 최소 요구 운영체제 버전이 4에서 5로 껑충 뛰었고, 이보다 낮은 값은 지정 자체가 안 된다.
또한 single threaded CRT 라이브러리 옵션도 없어졌다. C 라이브러리는 이제부터 무조건 multi threaded이다.

Windows의 지원 CPU의 변천사

(사무엘) — Sat, 03 Oct 2026 08:35:00 +0900

1. 클래식 16비트 DOS 기반 Windows: x86 하에서 여러 모드 존재

초창기 16비트 Windows는 DOS로 부팅된 컴퓨터에서 추가로 실행되던 운영환경 프로그램이었다. 자신만의 하드웨어 인식 모델, 자신만의 API, 자신만의 실행 파일 포맷이 있었지만 자체적으로 컴퓨터를 부팅시킬 능력은 없었다.
그 MS-DOS가 x86 전용이었으니 Windows도 자연스럽게 x86 전용으로 출발했다. 그 대신 그때는 x86 계열 CPU 자체가 시시각각 성장하고 변모하고 있었던지라, Windows도 그에 맞춰 다양한 실행 모드를 지원했다.

8086 real mode, 80286 standard 모드, 그리고 80386 enhanced 모드.
1.0이야 당연히 8086 real에서 시작했다. 주 메모리 최대 640KB밖에 지원을 못하는 초 열악 모드.
그러다가 Windows 2.x 시절에는 Windows/286, Windows/386 에디션이 추가로 도입됐는데.. 이거 마치 옛날에 아래아한글이 1.x 시절에 도트 프린터 에디션, 레이저 프린터 에디션을 세분화했던 것과 비슷한 느낌이 든다.;;; (폰트)

그러다가 Windows 3.0에서는 한 프로그램에서 세 에디션이 모두 같이 제공되기 시작했다.
286 표준 모드에서는 80286에서 추가된 보호 모드를 활용하여, 컴터의 메모리를 더 많이(최대 24비트, 16MB) 끌어다 쓸 수 있었다. 그리고 도스창을 연 상태에서도 백그라운드에서 딴 프로그램과의 멀티태스킹이 가능해졌다.
386 확장 모드에서는 그에 덧붙여 가상 메모리(스왑 파일 페이징)까지 더 끌어다 쓰고, 도스창을 여러 개 동시에 만들 수도 있게 됐다.

즉, Windows 3.x의 386 확장 모드는 여전히 16비트 코드 기반이지만 80386 CPU의 기능을 일부 활용했던 모드였다.
여기에다가 Win32s가 도입되고 커널이 통째로 Windows 9x로 바뀐 과정은 참 드라마틱하게 그지없다. DOS는 Windows를 띄워 주는 하부 인프라가 아니라, Windows 안에서 돌아가는 샌드박스로 위상이 바뀌었다.
수많은 DOS용 프로그램과의 호환성을 최대한 유지하면서, 또 저사양 똥컴에서의 성능도 최대한 살리면서 DOS를 도태시키는 길은 멀고도 험난했다;;

2. 1990년대 Windows NT: x86 + MIPS, Alpha, PowerPC

저런 클래식 Windows와 달리, Windows NT는 DOS와는 완전히 동떨어진 별세계 신세계 이상향을 추구했다.
x86은 지원하는 여러 CPU 중 하나일 뿐이며, 처음부터 100% 32비트 기반으로 동작했다. 지저분한 DOS나 16비트 호환성 따위는 우선적으로 고려하지 않았다.
실행 파일 포맷도 Portable Executable이라고 새로 제정하고.. 노는 물이 정말 완전히 달랐다.

Windows NT는 초창기에 x86뿐만 아니라 MIPS와 DEC Alpha를 추가로 지원해서 UNIX 일색이던 워크스테이션 시장에 도전장을 내밀었다. 원래 제일 처음 계획은 인텔 i860을 지원하는 것이었으나, 이건 모종의 사정으로 인해 이뤄지지 못했다.
NT 3.51부터 4.0 sp2까지 잠깐 동안은 PowerPC까지 추가로 지원했다. 그 당시 매킨토시가 돌아가던 그 CPU가 맞다. 물론 PC와 맥은 CPU 말고도 컴퓨터 하드웨어 규격이 매우 달랐기 때문에, 저런다고 맥에서 Windows NT PPC 에디션을 돌릴 수는 없었다.

Windows가 x86과는 특성이 상극인 RISC 구조에, 심지어 big endian인 CPU에서도 이식되어 돌아간 적이 있었다니.. 지금으로서는 참 믿어지지 않는다.
Windows NT의 개발 본진은 DEC Alpha에 가까웠다. 심지어 Alpha는 64비트 CPU이기도 했으나.. NT 3~4는 그냥 32비트 ABI를 그대로 사용했다. 이 Alpha의 후대 버전은 Windows가 진짜 64비트로 포팅되던 시절에 테스트 장비로도 쓰였다고 한다.

물론 이상향을 추구한 것에는 댓가가 따랐다. 1993~95년 사이, 어지간한 가정용 컴퓨터들이 램이 2MB~8MB 이러던 시절에 NT는 이미 12~16MB 이상을 요구했다. 그것도 한글 한자 지원 없이 오리지날 영문판이 말이다.
그 시절엔 CPU와 메모리 가격이 지금으로서는 상상하기 어려울 정도로 희귀하고 비쌌었다. 이러니 NT는 초창기엔 가정용 PC 생태계에서 도저히 발을 들일 수 없었다.

마소에서 개발하던 프로그래밍 언어/개발툴 중에 BASIC은 RAD로 지향점이 바뀌면서 Visual이라는 브랜드가 먼저 붙었다. (1991년) 그 반면, MS C는 7.0 버전에서 C++ 지원이 추가되면서 C/C++이 됐고, 그 다음 Windows NT용 32비트 타겟 빌드가 추가되면서 Visual C++ 1.0으로 다시 태어났다. 거기에다 IDE도 Programmer's workbench라고 언어 공용이던 게 Windows용 자체 에디터로 덤으로 바뀌었으니 겸사겸사 Visual이라는 단어를 붙인 듯하다.

이때는 크로스 컴파일이라는 개념이 약했는지 VC++이 x86용, MIPS용, Alpha용, PowerPC 용으로 제각기 따로 출시됐다.
아~ 그래서.. 개인적으로는 VC++ 4 시절에 PowerPC 타겟 흔적을 많이 봤던 것 같다. 그건 Windows NT를 염두에 둔 기능이지, CE용이 아니었다. 나중에 VC++ 6 IDE를 기반으로 출시됐던 eMbedded Visual C++와는 다른 제품군이었다.

3. Windows 2000: x86 단일 황금기

그 뒤.. 세기말이 되자 Windows 2000이라는 걸출한 제품이 Windows NT 5.0을 표방하며 출시됐다. 얘는 연도 숫자로나, 기술 계보로나 정말 너무 절묘한 교차점에 놓였다.
NT는 전통적으로 OpenGL이 있을지언정 DirectX 따위는 없던 운영체제였다. 그러나 2000은 일단 표면적으로는 NT 계열과 9x 계열의 통합을 추구했다. 그래서 DirectX라든가 plug & play, USB처럼 9x에 먼저 들어갔던 기능들을 대거 수용했다.

이제는 가정용 컴터들도 많이 빨라지고 램 용량도 크게 늘어서 NT 커널을 돌릴 수 있다고 여겨졌기 때문이다. 둘을 통합할 때가.. 아니, 구닥다리 DOS와 9x 커널을 퇴출시킬 때가 됐다.
이 참에, NT 구버전이 지원하던 타 CPU들은 미래가 없다고 여겨져서 때문에 지원을 끊었다. 그 대신 마소에서는 인텔의 새 밀레니엄 64비트 CPU로 여겨지던 Itanium을 지원하겠다고 벼르고 있었는데.. 이게 사실상 베이퍼웨어 나가리로 끝나 버렸다.

이런 이유로 인해 Windows 2000은 NT 계열임에도 불구하고 마치 9x처럼 사실상 x86 전용 운영체제로 출시됐다. 그리고 2000년대 초, 2000과 그 다음 XP 시기가 어찌 보면 32비트 x86의 황금기였다.
램은 128~256MB대.. 주소 공간이 부족하지 않고 32비트로 적당히 커버 가능해서 정수도 4바이트, 포인터도 4바이트.. 딱딱 절묘하게 떨어졌기 때문이다.
컴퓨터 클럭 속도는 기하급수적으로 증가하던 무어의 법칙의 끝물 상태였고, CPU도 x86 only에 가까운 상황.. 얼마나 깔끔하냐? 그 와중에 구닥다리 9x는 역사 속으로 사라져 가고.. 모든 게 파편화 없이 한데 집중됐었다. 새천년에 말이다.

4. 2000년대: Itanium과 x64의 명암

Windows의 역사상 어떤 형태로든 64비트 ABI라는 게 등장한 게 저 1990년대 중후반, Itanium 포팅을 할 때였다. PE 실행 파일의 포맷을 확장하고, 플랫폼 SDK에 INT_PTR이라든가 GetWindowLongPtr 이런 게 등장한 게 그 때라는 뜻이다.

하지만 IA64라고 불리는 Itanium은 처절한 실패로 끝났고, 21세기 초부터는 x64라는 x86 호환 CPU가 64비트 PC 시대를 주도하기 시작했다. 얼리어답터 컴덕이 아닌 일반인들은 컴퓨터 램의 용량이 실질적으로 4GB를 넘어선 2000년대 중후반, Windows Vista나 7쯤부터 64비트를 체감한 듯하다.

Windows는 일반인 클라이언트 제품군에서는 XP에서 딱 한 번 IA64를 지원하고는 학을 뗐다.
서버 제품군에서는 Vista에 대응하는 Server 2008까지 IA64를 조금 더 지원했고, 그 다음부터 지원을 끊었다.
그 대신 서버 제품군은 32비트 x86 전용 에디션을 클라보다 훨씬 일찍 끊었다.

클라에서는 Windows 10까지만 해도 x86 전용 에디션도 출시해 오다가 2020년대 11에 와서야 중단했다.
그러나 서버에서는 IA64를 약간 더 오래 지원한 대신, 그 Server 2008부터 x86을 끊고 x64로 완전히 갈아탔다. 클라와 서버의 컴퓨터 특성이 서로 다르기 때문일 것이다.
개발툴인 Visual C++은 2005부터 x64로 크로스 컴파일을 정식 지원하기 시작했다.

5. 2010년대 말: ARM64의 추가 도입

그 뒤, 마소는 2010년대 중반엔 경영진이 싹 바뀌었다. 새 경영진은 기존 CE나 폰/모바일 제품군을 포기하고 정리했다. Android/iOS와의 경쟁에서는 승산이 전혀 없다는 결론을 내렸으며, Windows 8 시절 같은 삽질은 더 하지 않기로 했다.
그 대신 Windows on ARM이라 해서 데스크톱용 기존 운영체제를 ARM64로 그대로 포팅해서 오늘에 이르고 있다.

너무 자명한 얘기지만, ARM64는 클라 제품군 한정이다. 서버 제품군을 그렇게 포팅하지는 않는다.
얘는 마소에서 ARM64EC니, ARM64X니 하는 온갖 하이브리드 규격도 만들어서 x64와 최대한 같이 포용하려 애쓰는 중이다.
예전의 Itanium처럼 호환성 없는 별개 취급을 하지 않고 있다.

2010년대 초, Windows RT 시절에 잠깐 나돌았던 ARM32는.. 2000년대 초 IA64와는 좀 다른 의미로 낙동강 오리알로 전락하고 역사 속으로 사라졌다. 한쪽이 64비트 삽질이었다면 다른 쪽은 모바일 삽질이라 하겠다.

이상이다.
한때는 온갖 CPU들이 난립하다가 x86으로 천하통일 되는 것 같았는데.. 지금은 그 뒤에 x64와 ARM64가 올라타서 상황이 좀 더 복잡해졌다. 날개셋 한글 입력기 작업을 하다가 이 이야기를 하고 싶어서 이렇게 글을 써 보았다.

한때, 1990년대부터 2000년대 초까지는 (1) 컴퓨터의 단일 코어 속도가 크게 증가했었다..
그 다음으로 1990년대 중후반부터는 (2) RAM이건 디스크건 메모리가 용량이 크게 증가하고 가격이 싸졌다. 이때쯤부터 C드라이브 디렉터리와 파일 구조를 DOS 시절처럼 몽땅 한데 조회하는 게 거의 무의미해지고 불가능해졌다.
끝으로, 2000년대부터는 (3) 인터넷 속도가 급격히 빨라지고 심지어 무선화까지 됐다.

이런 기술이 발달하고 저렴하게 널리 보급된 덕분에 일반 사용자들도 과거에 상상도 할 수 없었던 방대한 규모의 소프트웨어를 컴퓨터로 아무렇지 않게 돌릴 수 있게 됐다.

* 덧붙임: Windows CE

1990년대 중반, 가정용 PC에서는 Windows 95가 이제 막 정착했고 NT는 아직 별나라이던 시절에.. 마소에서는 PC보다 작은 기기에다가도 win32 API를 심어서 Windows 생태계를 가꿀 생각을 했다. 이름하여 Windows CE라는 게 이때 태동했다.

CE가 지원했던 CPU 중에는 NT에서 지원했던 MIPS, PowerPC 같은 것도 있었고 심지어 ARM32에다 x86도 있었다.
하지만 컴퓨터에 오로지 CPU만이 구성요소의 전부인 게 아니고, CE는 근본적으로 ‘임베디드’ 환경을 추구했다. CPU의 특성이나 메모리, 파일 시스템, 비디오, 소프트웨어 환경 등이 범용 컴퓨터와는 완전히 딴판이다. 그렇기 때문에 일반적인 Windows 프로그램을 돌리지는 못한다.

Windows CE용 프로그램을 개발하는 환경은 기존 Visual C++에다가 해당 플랫폼용 툴키트를 구매해서 추가로 설치하는 형태로 세팅했다. 2000년대 초에는 eMbedded Visual C++라고 IDE가 통째로 새로 나오기도 했었으나.. 그건 얼마 못 가 단종됐다.

Windows 9x가 21세기로 진입하지 못하고 세기말에 맥이 끊겼다면.. CE는 2010년 초쯤에 명맥이 끊겼다.
CE 커널은 9x와 달리 wide char로 대표되는 유니코드 버프는 당연히 받은 채로 시작했다. 하지만 2000년대 말의 트렌드이던 64비트 환경으로 포팅되지는 못했다. 동작 환경의 특성상, Itanium이나 DEC Alpha와도 접점이 당연히 없었다.

그 대신, 마소에서는 CE 커널을 스마트폰에다 얹을 생각을 했다. CE 커널이 한때는 PDA에도 쓰였으니 이는 자연스러운 귀결이었다. 그래서 통상적인 임베디드용 CE는 Windows Embedded Compact라는 이름으로 제품을 유지하고, CE를 기반으로 Windows Mobile을 만들고 나중엔 이름을 Windows Phone으로 대놓고 바꿨다.

나중에 마소는 Windows Phone을 CE가 아니라 NT 커널을 기반으로 다시 만드는 무리수까지 둬 봤지만.. 안드로이드나 iOS 같은 신흥 모바일 강자를 꺾을 수는 없었고 실패했다.
이런 사건을 거쳐 오늘날, 2020년대 기준으로 CE는 원래의 나와바리이던 임베디드 제품들의 유지보수 이상으로 신규 개발은 끝나고 성장이 멈춘 플랫폼이 됐다. 시장이 특수하기 때문에 무슨 Windows 9x가 사라진 것처럼 사라지지는 않겠지만.. 그야말로 고인물로 전락한 셈이다.

우리나라의 공항과 관제 시설들

(사무엘) — Tue, 29 Sep 2026 08:35:00 +0900

우리나라는 인천 공항이 그야말로 나라를 대표하는 넘사벽 킹왕짱 대표 '중추' 공항으로 등극해 있다. 전국의 지방자치단체들의 우두머리 중에서 서울 시장, 여러 국립대들 중에서 서울대, 여러 교육대학교들 중에서 교원대의 총장이 더 예우를 받는 것처럼(차관급이 아니라 유일하게 장관급), 국내 공항들 중에서는 인천이 유아독존이다.
얘는 운영 주체부터가 '인천 공항 공사'로 따로 있을 정도이다. 한국 공항 공사의 관할이 아니다.

이런 인천 제1군의 다음으로, 그나마 수요가 많고 흑자를 내고 있는 제2군 '거점' 공항은 다음과 같다.

(1) 김포: 수도권에 제일 가까이 있기 때문에 입지와 수요가 압도적이다. 다만, 근처의 인천 공항의 영향으로 인해 국제선이 막 활성되지는 않았다. 그냥 국내선(특히 제주)에다 중국(+대만)· 일본 단거리 수요로 먹고 산다. 정확히는.. 김포는 규정상 반경 2000km 이내 노선만 취항한댄다.

(2) 김해: 전국 모든 공항을 통틀어, 인천 "다음으로" 장거리 국제선이 가장 많이 활성화돼 있다. 쉽게 말해 인천을 제외하고, 전국에서 유럽· 미주 노선이 있는 유일한 국제공항이다.
수도권에서 멀리 떨어진 대도시라는 입지 덕분이다. 게다가 그 경남· 부산권에서 미국으로 가는데 인천 공항부터 가는 건 방향도 안 맞으니..

참고로 김포는 인천 공항의 개항 직후부터 약 2년 반 동안은 100% 국내선 전용 공항으로 격하됐던 적이 있었다. 그러다가 2003년 11월 말에 하네다 행부터 재취항하면서 단거리 노선 한정으로 국제선 간판을 다시 달았다.
2003년 10월 말엔 초음속 여객기인 콩코드가 완전히 퇴역했는데, 그로부터 1달쯤 뒤의 일이었다.

김포에 국제선이 다시 생긴 것처럼, 지금은 반대로 인천에서도 제주 국내선을 야금야금 뚫으려는 움직임이 있다. 과연 성사될지 모르겠다. 철도에다 비유하자면 "영등포 역, 대구 역에도 KTX 정차"와 비슷한 떡밥이지 싶다.

(3) 제주: 대도시는 아니지만 섬, 그것도 가장 큰 섬이라는 독보적인 특징이 있다. 여기와 본토 사이엔 육상 교통수단이 없기 때문에 비행기 100% 독점이다. 국내선 때문에 승객이 엄청나게 많고 바쁘며, 국제선도 중국· 일본을 넘어 동남아 정도는 있다.

김포-제주는 시내버스 급의 간격으로 비행기가 다니는 엄청난 트래픽을 자랑한다. 세계에서 가장 바쁜 항로라고 세계 항덕들과 항공업계 차원에서도 익히 유명하다. 오죽했으면 철도도 아닌 주제에 항로가 복선화됐을 정도이다.

"그렇게도 수요가 많고 비행기표를 못 구해서 난리이면 B747/A380 같은 대형 광동체기를 팍팍 집어넣지?" 이렇게 생각할 수 있고 이는 매우 설득력 있는 지적이다. 하지만 문제는 제주 공항이 그 정도로 거대하지 못하다는 것이다.

물론 제주 공항의 활주로도 스펙상으로 법적으로, 대형기가 이착륙을 하라면 할 수는 있다. 그러나 그거 한 대 받는 동안 737급 기체 네댓 대가 꼼짝달싹 못 하고 존버해야 된댄다. 공항이 마비돼 버리니 단위 시간 동안 처리 가능한 승객 수가 오히려 감소하며, 수지타산도 떨어진다.

(제주 공항에는 활주로가 X자 모양으로 2개 있긴 하지만.. 다른 하나는 2km도 안 될 정도로 너무 짧아서 실용적으로 쓸 게 못 된다. 그래서 사실상 원래 것 하나밖에 안 쓰이는 상황이다.
원래는 한쪽 바람으로 바람이 너무 심할 때 다른쪽 활주로를 쓰라는 취지로 활주로가 평행이 아닌 수직교차형으로 만들어졌었다.)

이 문제를 제대로 해결하려면 서귀포 공항을 어정쩡한 크기로 새로 지을 게 아니라 제주 공항을 어떻게든 확장하는 게 더 나을지도 모르겠다. 물론 이것도 공항 바로 근처까지 건물이 다닥다닥 늘어선 현 상황에서는 매우 난감해져 있다. 여러 모로 답이 없군;;

다음으로, 김포-김해는 김포-제주보다는 덜 혼잡하지만 그래도 여전히 수요가 많고 수지타산이 맞는다.
육지에서 그 많은 고속버스와 고속철도들이 수요를 엄청나게 흡수하고 있는데도 항공 수요가 여전히 그만큼 또 있다는 게 대단한 지경이다.
이렇게 김포, 김해, 제주 다음으로는 청주, 대구, 무안도 일단 지방 거점 공항이라고 한다.

(4) 청주는 우리나라의 정중앙에 있으니 대전 같은 곳에서 이용하기 좋겠다. 게다가 통금 없는 24시간 운영이라는 이점도 있다.
하지만 좁은 우리나라에서 어정쩡한 위치로 인해 국내선은 일단 제주밖에 없으며.. 국제선도 역시 중국 일본에 일부 동남아밖에 없다. 시간 제약은 없지만 공군과 활주로를 같이 쓴다는 한계도 있다.

대구는 군위군을 합병까지 했는데 군부대 겸 공항이 그리로 이전할 것으로 보인다.
무안은 사고가 났다고 언제까지 영업을 중단하고 반영구적으로 공항을 폐쇄하려는지 모르겠다.

흑자가 나는 공항은 김포, 김해, 제주 다음으로 청주가 거의 마지노 선이라고 한다.
울산, 여수, 광주, 사천 같은 3군으로 가면 인지도가 더욱 감소한다. 어떤 공항은 아예 국제선을 취급하지 않는 국내선 전용이기도 하다.

원주 공항은 공식 명칭이 '원주(횡성)'이지만, 포항 공항은 공식 명칭이 '포항경주'로 바뀌었다. 전자는 공군과 겸용하는 공항이지만 후자는 해군과 겸용하는.. 전국 유일의 해군 소유 공항이라는 차이가 있다.
그 반면, 울산 공항은 군과의 접점이 전혀 없는 순수 민간 공항이다. 얘는 KTX 울산 역보다도 울산 시내에 더 가까이 있으며 태화강 역과의 연계도 괜찮은 편이다.

※ 공항 안팎의 관제소

비행기가 다니는 활주로나 심지어 공중에 무슨 신호등· 신호기 따위를 설치할 수는 없다. 그렇기 때문에 항공에서는 교통 통제가 지상 관제 시설과의 무선 교신으로 행해진다.
항공 관제라 하면 공항 활주로의 중앙에 제일 높이 솟아 있는 관제탑이 으레 떠오른다. 거기만 해도 사진 촬영조차 금지되는 중요 보안 시설이지만, 공항 관제탑만이 관제의 전부인 건 아니다.

비행기가 순항 중일 때는 매우 넓은 영역에서 항로 관제(지역, area)를 받는다. 그리고 착륙을 앞두고 공항 반경 수십 km 이내에 왔을 때는 접근 관제(approach)를 받으며.. 한 공항 안에 들어왔거나 아직 거기 안에 머물러 있을 때에 공항 관제(tower / ground)를 받는다.
즉, 항로-접근-공항 순의 3단계 tier가 존재한다. 항공 관제사를 육상 선수에 비유하자면, 이들 영역은 마치 단거리 장거리처럼 세부 종목이 다른 셈이다.

항로 관제는 "현재 고도 어디 피트로 상승을 요청합니다" / "귀 항공기를 고도 어디 피트로 허가합니다" 이러는 관제를 말한다. 항공 사건사고 다큐에서 어디 고장이 발생한 비행기의 조종사가 다급하게 지상과 대화를 나누는 상대도 이쪽이다. 국제선 비행기가 남의 나라에 지불하는 영공통과료엔 이런 항로 관제를 받는 비용이 포함돼 있다.

우리나라 권역에서 항로 관제를 하는 곳은 '항공 교통 본부' 소속의 '인천 항공 교통 관제소'이다. 본부 사무소는 대구에 있지만 실제 관제소는 인천 공항의 동북쪽에 있는 듯.. 철도로 치면 지금 서울 구로에 있는 철도 교통 관제센터와 비슷한 위상이다.

사실, 항로와 공항의 중간에 있는 tier 2 '접근 관제소'가 대외적으로 거의 국정원 급으로 제일 베일에 싸인 것 같다. 전국 곳곳에 딱 14곳이 있는데, 인천, 김포, 서울성남 권역은 '서울 지방 항공청' 소속의 '서울 접근 관제소'에서 맡는다. 서울 접근 관제소는 인천 공항의 동북쪽에 항로 관제소의 바로 옆에 나란히 놓여 있다.

인천처럼 몰려드는 비행기가 많은 곳에서는 접근 관제소가 "너는 뺑뺑이 좀 돌다가 저 비행기 다음으로 들어가세요"라고 정리를 해 주고, 최종적으로 공항 관제탑에서 "너는 저 n번 활주로에 요 방향으로 착륙하세요"라고 허가를 내 준다.

공항뿐만 아니라 이런 관제 시설에 대해서도 생각해 보면 재미있다.
옛날에 찰스 린드버그 같은 사람은 그야말로 최초로 대서양 무착륙 횡단 비행을 시도한 덕분에.. 저런 복잡한 관제 절차 따위 하나도 없이 깔끔하게 날아갔으며, 남의 나라에 무단 입국도 할 수 있었다. 옛날엔 위험도 있었지만 저런 낭만도 있었다~!

※ trivia

(1) 우리나라는 땅이 좁은 걸 감안하더라도, 그 국력과 인구와 경제력을 감안하면 타 국가 대비 공항이 적은 축에 든다고 한다.
하긴, 일본은 인구 50~100만짜리 소도시에도 그냥 공항도 아니고 국제공항이 떡 있어서 우리나라 LCC 편으로 인천에서 직항을 타고 가기도 한다. 우리나라는 확실히 그 정도는 아닌 것 같다.

(2) 옛~날, 1996년쯤엔가 마이클 잭슨이 방한했을 때는.. 당사자야 물론 김포로 들어왔지만 거대한 공연 장비 화물들은 수송기에 따로 실려서 오산 공군 기지를 통해 반입됐다고 한다. 공간 넉넉한 인천 공항이 그때 있었다면 이렇게 두벌일을 할 필요가 없었을 것이다.

(3) 나라 차원에서 의전이 필요한 외국 정상 귀빈들은 여느 민간 공항이 아니라 군 공항인 서울 공항에 다이렉트로 들어오는 편이다. 꼭 살아 있는 사람이 아니어도, 무슨 6 25 전사자 유해라도 송환한다면 역시 무조건 서울 공항행이다. 그리고 이건 착륙 후 활주로에서 의전 정도가 아니라 아예 수송 단계에서 전투기까지 보내서 호위해 준다.
허나, 북한의 고위 정상은 예외다. 무슨 회담이나 국제 스포츠 행사 때문에 북한 사람이 판문점 육로가 아니라 뱅기로 방남한다면.. 그냥 인천 공항으로 들어오게 한다. 주적에게 서울 공항의 내부를 보여주지는 않는다는 게 우리 측 방침이기 때문이다.;; 흥미로운 차이점이다.

(4) 우리나라에서 가까운 미래에 새로 만들려고 하는 공항들은..
-- 대도시: 부산 동남권 가덕도, 대구-군위, 현 서울 공항의 민간화(아직은 떡밥 수준)
-- 섬: 울릉도, 백령도, 제주 서귀포
정도인 것 같다. 공항의 분야와 성격이 서로 꽤 다르다.
여객기는 꼭 200명씩 타는 보잉 7xx급 제트기여야 한다는 고정관념을 버리고, 인구 적은 섬에는 버스 한 대 체급의 붕붕 프로펠러기라도 실속 차리면서 날아다니면 좋을 것이다.

(5) 우리나라 역사상 최초의 공항은 무려 1910년대 일제 시대 초기에 개항했던 여의도 공항으로 여겨진다. 그때는 합정과 노량진만 해도 조선 시대 기준으로는 사형장이나 무덤이 있었고, 20세기 기준으로 발전소가 있을 정도의 외곽 오지였다. 그러니 하물며 여의도라면 비행장을 만들고도 남는 교외였다.
그 여의도 공항 활주로가 나중에 여의도 광장으로 바뀌었고, 더 나중에 2000년대부터는 지금의 여의도 공원으로 바뀌었다.

물론 ICAO가 출범하고 현대적인 민간 항공 체계가 정립된 건 2차 세계대전 이후의 일이었으니 이 체계 하에서 우리나라 최초의 국제공항은 두 말할 나위 없이 김포이다.
그래서 해방 이후 임시정부 요원들은 여의도 공항으로 입국한 반면, 훗날 이 승만 대통령은 하야하고 하와이로 갈 때 김포 공항에서 출국했다. 제주 공항은 더 나중인 1969년에야 국제로 승격됐다.

(6) 사람이 무슨 상가 같은 게 없이 복도만 겁나게 길게 늘어서 있는 길을 갈 일은 흔치 않다. 개인적으로 이런 곳은 코엑스 내부의 지하 복도, 지하철 7호선 청담 역 내부, 인천 공항 입국장 정도가 떠오른다.;;

(7) 대전 지하철 1호선 대전 역이 매우 깊은 이유는 고속철도의 대전 시내 구간이 지하에 만들어지는 것을 염두에 두고 그 공간을 피해서 깊게 팠기 때문이다. (하지만 결국 지하화되지 않음)
서해선 김포공항 역이 부산 지하철 만덕 역보다도 깊은 이유는.. 선로가 강이나 언덕 아래가 아니라 활주로 아래를 지나기 때문이다. 게다가 북쪽으로 개화산과 한강 아래도 지나고.. 정말 모든 지상 지형을 쌈싸먹어 버리면서 근성으로 길을 만들었다.

다음 버전 개발 근황: ARM64EC 지원

(사무엘) — Fri, 25 Sep 2026 08:35:00 +0900

호박 농사 근황을 전했으니 다음으로 날개셋 프로그램의 개발 소식도 전하도록 하겠다.
이번 9월 동안 날개셋 한글 입력기는 ARM64 플랫폼의 지원과 관련하여 굉장히 흥미진진한 기능 개선과 개발이 진행됐다.
그 발단은 기존 11.0이 ARM64용 MS Office 프로그램에서 전혀 동작하지 않는다는 버그 신고 메일이었다. 이 글에서는 그 내역을 공개하고자 한다.

지난 7월에 11.0 버전은 프로그램들을 모두 ARM64 방식으로 빌드하고 테스트 하는 단순한 방식으로 만들어졌다.
그렇게 했더니, 날개셋 외부 모듈이 순수하게 ARM64 방식으로 빌드된 프로그램에서는 잘 동작했다. 그러나 ARM64EC라고, ARM64 네이티브이긴 하지만 x64 명령어도 에뮬레이션으로 같이 지원하는 ABI 환경에서는 동작하지 못했다.

ARM64EC 프로세스에서는 x64 또는, 똑같이 ARM64EC 방식으로 빌드된 DLL만 동작 가능하다. 그리고 반대로 x64 프로세스에서도 같은 x64 또는 ARM64EC 방식 DLL을 실행할 수 있다. EC는 emulation compatible의 이니셜이라나..?? 비트 수가 다른 16-32비트, 32-64비트 간에는 thunking이라는 말을 썼는데 같은 64비트끼리는 그냥 에뮬레이션을 하는가 보다.
그 반면, 순수 ARM64는 저런 식으로 x64 바이너리와 소통을 할 수 없다.

마소에서 굳이 ARM64EC라는 걸 번거롭게 만든 이유는.. 그야말로 천문학적으로 방대한 프로그램들을 한순간에 ARM64로 다 포팅하는 게 현실적으로 어렵기 때문이다. x64 레거시를 최대한 활용하기 위해서이다. 그렇기 때문에 한 덩치 하는 거대한 프로그램이 ARM64EC 방식으로 만들어지는 경향이 있다. 저 MS Office처럼 말이다.

그래서 Windows on ARM에서는.. 꽤 삽질스럽고 번거로워 보이지만, 한 파일로 순수 ARM64와 ARM64EC에 모두 대처 가능한 ARM64X라는 변칙적인 fat binary를 도입했다. Windows 10 시절엔 없었고 11에서 새로 추가된 모양이다.
얘들은 크기가 매우 크다. 그리고 이건 당연한 말이지만 EXE는 해당사항 없고 오로지 DLL만을 위한 옵션이다.

과거에 x64 플랫폼이 처음 도입됐을 때는 Program Files와 Program Files (x86), 그리고 system32와 SysWow64처럼 프로그램 디렉터리를 비트수 별로 분리하는 방식이 쓰였다.
그러나 ARM64 기기에서 x64를 포용할 때는 디렉터리를 또 분리하기가 난감하니 EC라는 요상한 ABI를 도입하고 fat binary를 도입한 것으로 보인다.

순수 ARM64 앱에서만 돌아가는 게 확실한 DLL은 예전처럼 ARM64 방식으로만 빌드하면 된다.
그러나 IME처럼 아무 임의의 EXE에서 로딩될 수 있는 범용적인 DLL은 ARM64X 방식으로 빌드해야 하더라. Windows의 시스템 DLL들도 이 방식으로 빌드됐다.

그래서 내 한글 입력기 역시.. 제일 먼저 (1) dll 기반 바이너리들을 모두 ARM64X 방식으로 빌드함으로써 외부 모듈의 제일 급한 문제를 해결했다. 이제 내 프로그램의 ARM64 에디션은 MS Office에서도 잘 동작한다.
이렇게 빌드함으로써 4MB 남짓이던 배포 패키지의 크기도 4.5MB 정도로 약간 더 커졌다.

그리고 이것만 하면 싱거우니 (2) About 대화상자에도 실행 환경과 관련된 정보를 더 추가했다.
현재 날개셋 한글 입력기가 순수 ARM64인지 아니면 ARM64EC인지?? 그리고 ARM64EC인 경우는 날개셋을 사용하는 실행 파일이 x64인지 아니면 ARM64EC인지? 요걸 추가로 알려주게 했다.

운영체제의 버전과 기준 아키텍처
날개셋 한글 입력기의 아키텍처
외부 모듈 한정으로, 구동 중인 EXE 프로그램의 아키텍처

32비트 x86 에디션의 경우, Windows 9x에서 16비트 프로세스가 실행 중인 것을 감지하는 기능이 있었다.
16비트 exe의 내부에서는 32비트 DLL이 GetModuleHandle(NULL)을 호출했을 때 일반적인 32비트 EXE 같은 주소가 아니라 그냥 kernel32.dll 같은 높은 주소가 돌아오기 때문이다. (NT 계열에서는 그냥 ntvdm.exe의 주소가 돌아오기 때문에 해당사항 없음)

과거에 그렇게 16-bit라는 문구가 찍히던 자리에 이제는 x64라는 문구를 찍는 로직이 추가되었다. ARM64EC 코드가 ARM64가 아니라 x64에서 실행될 때 말이다. 아주 재미있는 변화이다.
이 참에 외부 모듈의 x64 에디션이 ARM64 컴터에서 설치와 등록이 시도된 경우, "이 컴터에서는 ARM64 에디션을 사용해 주세요" 경고 메시지도 표시하게 했다. ARM64에서 x64 에디션을 설치하면 외부 모듈이 x64와 ARM64EC 앱에서밖에 동작을 못 할 것이기 때문이다. (순수 ARM64 앱에서는 동작 불가)

외부 모듈에서 ARM64EC 지원 작업은 이렇게 마무리됐다.
하지만 이게 전부가 아니다. 그 다음으로, hooking을 통해 문자 입력을 구현하는 (3) 입력 패드에도 아주 흥미진진한 작업이 진행됐다.
이 프로그램은 모든 프로그램에서 동작하기 위해서 64비트와 32비트 프로그램이 같이 동작하는 형태로 만들어졌다.
system-global hook은 CPU 아키텍처별로 다 따로 만들어서 운용해야 하기 때문이다.

x86과 x64 둘만 고려하면 되던 시절에는 프로그램 로직이 간단한 편이었다. 그러나 여기에 ARM64를 추가하자니 프로그램을 여러 군데 고치고 확장해야 했다.

host와 guest를 단순히 비트 수만으로 분별할 수 없으니 CPU 아키텍처를 명시해야 하며, ARM64는 x86뿐만 아니라 ARM64EC로 guest를 두 가지를 고려해야 한다.
그리고 반대로 x86도 parent host로 가능한 대상이 오로지 x64 단일이 아니라 ARM64일 수도 있는 것을 고려해야 한다.
코딩에서 일대일(단수)이던 게 일대다(복수)로 바뀌는 건 생각보다 복잡한 변화이다.
표로 정리하면 이렇다. 이 모든 것이 단일 소스 코드의 조건부 컴파일만으로 조절된다.

SW ＼ HW	x86	x64	ARM64
x86	단독 host	x64의 guest	ARM64의 guest
x64	N/A	host (+x86)	N/A
ARM64	N/A	N/A	host (+x86, ARM64EC)
ARM64EC	N/A	N/A	ARM64의 guest

그래도 ARM64EC 프로세스에서 hook을 만들고, hook procedure DLL을 ARM64X 방식으로 만들어 주니 ARM64EC 앱과 x64 앱에서도 메시지를 가로채고 변조해서 문자 입력 기능을 구현할 수 있었다.
이로써 외부 모듈과 입력 패드가 ARM64 자체뿐만 아니라 ARM64 Windows에서 실행되는 모든 CPU 방식을 제대로 지원하게 되었다. 만세~! 마소가 ARM64는 과거의 Itanium처럼 서로 생까는 별개의 CPU로 취급하지 않고 x64와 최대한 융합을 도모한다는 게 느껴졌다.

이것만으로도 다음 버전 11.01 이상은 9월이나 10월쯤에 나올 수 있게 됐다. 하지만 달랑 이것뿐만 아니라 다른 개선 사항도 가능한 한 많이 들어갔으면 좋겠다.
이상이다. 2020년대 들어서 날개셋 한글 입력기의 개발 속도가 끔찍히 느려졌음에도 불구하고, 프로그램을 꾸준히 사용해 주시고 후원도 해 주신 분들이 계신 것에 진심으로 감사드린다.

※ 참고: ARM32는?

사실, ARM이라는 건 예로부터 Android 운영체제를 돌리는 스마트폰용 CPU 아키텍처로 더 유명했다. 얘는 처음에는 32비트로 시작했다가 2010년대 후반쯤부터 순식간에 데스크톱 PC와 동일하게 64비트로 넘어갔다.
글쎄, Visual C++에서도 32비트 ARM 플랫폼이 타겟으로 존재는 하던데 이건 뭔지..??

지난 2012~13년 Windows 8 시절에, Windows NT 커널이 32비트 ARM용으로 포팅되어 Windows RT라는 서피스의 전신뻘 기기에 들어간 적이 있었다.
그러나 이건.. 마소에서 ARM CPU 기반의 모바일 기기에 대한 개념이 부족해서 삽질했던 흔적에 더 가깝다. 그 시절에 Windows 8은 아예 시작 버튼이 없었다는 걸 생각해 보자;;;

3rd party 개발자들은 Windows RT 환경에서는 native 데스크톱이 아니라 metro 앱만 만들 수 있었다. 그리고 내 기억이 맞다면 저 기기는 일반적인 데스크톱 PC처럼 임의의 앱을 마음대로 설치할 수 있는 형태가 아니었다.
이 정도면 스마트폰이 아니라 아예 피처폰을 추구한 건지? Windows on ARM이 64비트 기반으로 나중에 괜히 따로 나온 게 아니었다.

ARM32는 퇴물로 전락한 데다, x86처럼 유의미한 호환성 자산도 전혀 아니었다. 그래서 금세 정리되고 잊혀졌다. 적어도 데스크톱용 Windows 생태계에서는 말이다.
그러니 본인은 날개셋 한글 입력기도 ARM 환경에서는 처음부터 64비트만 고려하면 된다는 걸 이번 기회에 확실하게 도장을 찍었다. 32비트를 지원하는 건 x86만으로 족하다.

호박 농사 근황 (열매 5~7호)

(사무엘) — Sun, 20 Sep 2026 08:35:00 +0900

9월도 벌써 하순에 진입했고 추석 연휴가 임박했다. 낮 최고 기온이 30도 아래로 내려가고 덜 더워지긴 했지만.. 그래도 반팔에 에어컨은 여전히 변함없다.
이 와중에 중국과 일본에서는 일부 지역에서 태풍과 폭우 피해를 많이 입었다. 우리나라는 태풍은 맥이 끊겼지만 그래도 경남 통영· 거제에서 폭우 때문에 궤멸적인 피해를 당했다. 어떻게 폭우 홍수만으로 아스팔트 도로가 무슨 지진 난 듯이 갈라지고 박살날 수 있는지 모르겠다.

그 짧은 기간 동안 지진과 화산도 있었다. 결정적으로 네팔에서는 비 한 방울 없는 파란 하늘 아래에서 빙하 녹은 물 쓰나미가 들이닥쳐서 히말라야 산골 마을이 문자 그대로 삭제돼 버렸다.
자연재해라는 게 어제 오늘 있는 일이 아니긴 했지만 참 유별나다.

이 와중에도 개인적인 호박 농사는 계속 진행 중이다.
제헌절 연휴 이후로 지금까지 호박 농사 소식이 없었으니, 오늘은 오랜만에 호박 근황을 전하도록 하겠다. 오늘 다음으로는 호박 농사가 다 끝난 10월 말쯤에나 최종 결산 보고를 올릴 것으로 보인다.

6월에 태어났던 열매 4개 중, 가장 크게 잘 자란 아이는 6월 15일생인 제2호였다.
2호는 생후 4주에 근접하자 표면이 허연 가루가 앉은 듯이 뿌얘졌다. (7월 11일) 그리고, 만 1개월째인 7월 15일엔 위에서 보다시피 눈에 띄게 폭삭 늙어 버렸다. 야호~!!

7월 27일, 열매 4개를 모두 땄다. 1호는 유일한 단호박이고, 2호는 제일 큰 늙은 호박이다.
3호는 제일 작지만 애매하게 황록색으로 바뀌어 가는 녀석이다.
4호는 생후 1개월이 채 안 되어 제일 파릇파릇하고 흰 가루가 앉아 있다.

1호와 3호는 더 자라는 기미가 보이지 않아서 인위로 땄다. 2호와 4호는 열매를 키우고 있던 호박이 통째로 죽어 버리고 가지가 시들었기 때문에 강제로 따게 됐다.

저 아이들을 따고 나서 또 4주 가까이 뒤에 찍은 모습이다. 2호는 더 누래지고 탐스럽게 늙었다. 하지만 1호는 단호박이어서 그런지 늙는 기미가 없다.
4호는 요리해서 먹었기 때문에 위의 사진에는 나오지 않았다. 제일 어린 4호가 속이 물러지려 해서 바로 먹게 됐다.

이렇게 열매 1~4호를 수확하는 걸로 올해의 호박 농사는 '거의' 끝났다.
호박이들이 7월 초에는 폭우와 과습 때문에, 그리고 그 뒤부터 8월 중순까지는 지옥 같은 폭염 때문에 죽다 살아나고 정말 고생이 많았다.

그래서 그런지 6월 30일 4호 이후로는 1달이 넘게, 암꽃이 피지 않았다.
암꽃뿐만 아니라 매일 3~5송이씩 피던 수꽃조차 맥이 끊겼으며, 호박들이 그냥 쥐죽은 듯 똑같이 가만히 있기만 했다.
아니, 현상유지라도 되면 다행이고, 잎들이 하루가 다르게 누래지고 갈변하고 시들면서 덩치가 확 작아졌다. 진짜 너무 더워서 파업이라도 한 것 같았다.

하지만.. 8월 하순부터 날씨가 약간이나마 덜 더워지자 호박들이 다시 생존 신고를 시작했다. 끝날 때까지는 끝난 게 아니고 농사 시즌 2가 시작되기라도 한 것 같았다.

그래서 8월 26일..! 4호 이후로 거의 2달 만에 암꽃이 기적적으로, 거짓말처럼 짠 폈다. 만세!! 꽃은 잎이 큼직하고 씨방도 아주 튼실했다. (5호)
게다가 5호로 모자라서 6호까지 저렇게 노란 펜촉을 만들고 바로 다음날 폈다. 예전에 2호와 3호가 하루 간격으로 나란히 폈듯이 말이다.

8월 27일. 암꽃 6호는 새벽 5시에는 완전히 펼쳐지지 않은 상태였다가, 2시간쯤 뒤에는 완전히 활짝 폈다. 내 경험상 호박꽃은 보통 새벽 5~6시 사이에 펴더라.
수꽃 꽃가루를 묻혀 주는 건 응당 인간의 몫이다.

그 다음 8월 28일. 5호는 겨우 이틀 만에 저렇게 커져서 수분 성공이 확실시되었으며, 6호도 벌써 저만치 부푼 걸 보면 수분 성공이었다.

그런데 경사가 이걸로 끝이 아니었다.
설마 암꽃으로 발전하겠나 싶던 새로운 씨방이 갈수록 커지더니 9월 1일에 폈다!! 전국에 비가 철철 내리고 있던 새벽에 7호 후보 암꽃이 거짓말처럼 활짝 폈다. 위의 사진은 8월 30일부터 9월 1일까지 하루 간격으로 촬영한 것이다.

암술과 수술이 비에 젖지 않게 최대한 조심해서 인공수분을 하자 수분이 됐다. D+2일째(9월 3일)엔 저렇게 커져서 열매 7호의 탄생이 확인됐다. 만세~!
5호와 6호는 표면색이 아주 연한데 7호는 보다시피 진해졌다.

그리고 그 7호는 D+8일째인 9월 9일 현재 이렇게 뚱뚱해졌다.
내 경험상 호박 열매의 외형은 동글 → 납작 → 쭈글 단계를 거치며 커진다.
처음에는 동글동글 둥글다가 종횡비가 변하고, 더 나아가 주름까지 생기면서 우리가 아는 그 호박 모양이 된다.
7호도 동글 단계는 금방 졸업하고 사람 주먹만 한 크기가 됐다.

5호와 6호는 쌍둥이나 마찬가지여서 비슷한 색과 크기, 비슷한 모양이 됐다.
7호 이후로 8호가 될 만한 씨방도 며칠에 하나꼴로 맺히긴 했지만.. 얘들은 더 성공하지 못했다. 암꽃이 딱 하나만 더 펴서 8호까지만 만들면 여한이 없을 것 같다.

다음으로.. 지난 7월에 과습 피해 이후에 새로 돋은 새순은 2개월쯤 뒤, 이 정도까지 자랐다.
옛날 사진과 비교해 보니 많이 잘 자라긴 했다.

그리고 그 당시 수박이 실패했던 자리에 새로 심은 늦둥이 호박도 이 정도로 자랐다. 얘들은 과연 꽃과 열매 단계까지 갈 수 있을지 모르겠다. 뭐, 10월쯤 되면 결론이 나겠지..

지난 5월에 고향집에 전해 줬던 호박은.. 좀체 암꽃 소식이 없다가 9월에야 드디어 탐스러운 암꽃을 피웠다. 어머니께서 인공수분을 해 주셔서 여기서도 탐스러운 열매를 맺었다.

본인의 아내의 언니의 아들 -- 즉, 본인의 처조카가 차창 밖으로 이 놀라운 광경을 우연히 보고는 본인에게 전해 줬다. 이모부가 호박 매니아인 걸 알아서... ^^
9, 10월은 동네 채소 가게 소매점에서도 늙은 호박을 볼 수 있는 시기이다. 다들 커다란 늙은 호박 한두 개를 집안 방구석에 갖다 놓으면 분명 좋은 일이 생길 것이다.

호박에게 인공수분을 할 때마다 내가 인간꿀벌이라도 된 것 같다는 생각을 했는데..
파주· 일산 일대에 인간꿀벌 코스프레를 하며 지내는 사람이 있어서 매스컴을 탔다고 한다. 신기하다~!

요게 정말 호박 덩굴의 매력이다. 꼬불꼬불 덩굴손, 수꽃 펜촉, 암꽃 씨방, 털난 줄기..
작은 사진 안에 호박의 귀여운 요소들이 모두 고스란히 담긴 것 같다. 아래의 덩굴손은 마치 유선전화의 꼬불꼬불 케이블처럼 보이기도 한다.

울릉도에서 유명한 엿이 원래는 '후박엿'인데 호박엿으로 와전돼서 전해지고..
꿀벌 말고 통통하고 털이 북슬북슬 난 귀여운 벌도 '뒤영벌'(뒝벌) 대신 호박벌로 와전돼서 전해지고 있다.
호박은 덩치가 너무 커지는 게 부담되긴 하지만 그만큼 열매도 거대해서 좋다.
그러고 보니 잊을 뻔했군..! 호박 애호가였던 쿠사마 야요이 할머니가 지난 8월에 향년 97세의 나이로 별세했다. 안 그래도 엄청난 고령이었구나. 좋은 일 한 사람이었다.;;

뮤지컬 시데레우스 + 태양계 행성들

(사무엘) — Tue, 15 Sep 2026 08:35:00 +0900

1. 뮤지컬 관람

본인은 지난 6월, 일본 출장을 다녀온 지 얼마 안 됐던 시기에 아내 인맥으로 대학로에서 뮤지컬 '시데레우스'를 관람할 기회가 있었다.

이건 갈릴레이 갈릴레오가 17세기 초에 망원경이라는 도구의 도움으로 목성의 위성들을 발견하고, 요하네스 케플러와 학술 교류를 하면서 지동설을 정립하던 과정을 극화한 작품이다. 과학사를 소재로 한 이례적인 국산 창작 뮤지컬로, 2019년에 초연을 해서 올해는(2026년) 벌써 5연째였다.

아시다시피 갈릴레이 갈릴레오는.. 공기 저항이 없는 한 모든 물체는 언제나 같은 속도로 떨어진다는 걸 규명한 걸로 명성을 떨쳤다. 그리고 진자의 등시성 운동에 대해 진지하게 연구했었다. 그러다가 나중에는 요하네스 케플러를 만나면서 연구의 범위가 우주로 확장됐다.

그도 처음에는 지동설이 정말 맞을까 긴가민가 했다. 하지만 목성의 위성 등, 천동설로 설명이 안 되는 더 복잡한 천체 현상들을 발견하면서 지동설에 확신을 갖게 됐다.
이들이 관측만으로 정립한 사실들을 수십 년 뒤 뉴턴이 미적분학과 고전역학을 정립하면서 수학 이론 차원에서 쐐기를 박았다.

우리가 지금 너무 너무 당연하게 생각하고 있는 천체의 운동 패러다임이 저 1600년대에는 정말 사고방식의 대격변이었겠구나 싶었다. 갈릴레이나 케플러 같은 17세기 우주덕들이 지금처럼 우주 망원경에다 현대 우주론의 연구 성과들을 본다면 놀라서 까무러치지 싶다.

여담으로는..

갈릴레오의 딸은 세례명이 '마리아 첼레스테'였다고 한다. (본명은 따로 있음) 19세기 말에 악명을 떨쳤던 전설적인 유령선도 이름이 '메리 셀러스트'이다! 일단 같은 이름이란 게 공교롭게 느껴진다. 뭐, 얘도 처음엔 이름이 아마존 호였다가 나중에 저렇게 개명됐다.
'토리첼리'가 갈릴레이의 제자였다. 그 옛날에 수은 76cm, 물 10.3m.. 이렇게 대기압이라는 개념을 발견하고 규명한 사람이다.
천체의 운동이 수학적인 질서가 있으면서도, 그게 역설적으로 너무 카오틱하기도 해서 해석적인 일반해를 정확하게 구하는 게 불가능하다는 건.. 훗세에 의해 추가로 증명되었다(삼체 문제..).
천동설 vs 지동설 다음으로 천문학이 비교적 현대에(20세기 중후반) 논쟁을 벌였다가 결판이 난 분야는.. 우주의 기원과 관련하여 정상우주 vs 대폭발이었다. 이때는 갈릴레이나 뉴턴 연배의 사람들은 상상조차 하기 어려웠을 "우주가 팽창한다"라는 개념까지 정립된 상태였다.
17세기 저 때의 물리학은 “현상을 정확히 계산할 수 있다”에 진심이었다. 하지만 사과가 떨어지는 운동에 대해 정확하게 기술하고 계산과 예측하는 데 성공했다 해도.. 그 중력이란 게 본질적으로 왜 생기는지늘 규명하는 건 또 별개의 영역이다. 그걸 캐기 위해 현대 물리학은 상대성 이론, 양자역학 등을 개척했지만.. 여전히 모든 문제가 다 해결된 건 아니다.
그러고 보니 망원경은 거시세계에서 너무 멀리 떨어져 있어서 작고 안 보이는 목표물(건물, 지형, 천체..!)을 확대해 보여주는 기기이고, 현미경은 그냥 크기가 절대적으로 너무 작아서 안 보이는 목표물을 확대해 보여주는 기기이다. 흠, 그럼 안경은 스케일이 둘의 중간인 건지..
역사적으로는 망원경과 현미경 모두 1600년대 초에 비슷한 시기에 첫 등장했다. 그 뒤 둘은 자기 역할에 맞게 특화되고 따로 발전하기 시작했다.

2. 우주에 대한 성경의 서술

내가 아는 한, 성경은 천체를 분류하는 게 해와 달과 별들.. 이걸로 끝이다. 별은 집단으로 다뤄지며, 욥기 38장 같은 데서 특정 별자리 이름이나 좀 나오는 정도이다.

그런데 성경엔 영킹 기준으로 딱~~ 한 번 planet 행성이라는 단어가 나온다(왕하 23:5). 해와 달 다음으로 별들, 하늘의 군대/군상 같은 통상적인 용어가 아니라 행성이라니! 이게 뭘 의미할까? 비킹에서는 그냥 별자리, 성단 등이라고 바뀌어 번역됐다.

성경에는 참교육이나 분노의 질주 같은 개념은 있다.
그러나 성경에 이 땅(지구), 해와 달과 별 말고 '태양계'라든가, 수성 금성 화성 목성 같은 특정 '행성'을 암시하는 용어나 개념은 내가 알기로 전혀 없다. 그런 건 인간들이 훗날 망원경을 발명하고 로켓과 인공위성을 발명하면서 관측과 탐사를 해서 알아낸 것들이다.

물론 그 전 까마득한 옛날에도 인간은 육안으로도 목성을 넘어 무려 토성까지 어렴풋이 관측을 해냈다.
허나, 그때는 지금 우리가 아는 것 같은 항성과 행성이라는 엄밀한 구분이 없었다. 수성이니 화성이니 목성이니도 1~6등성 범주에 드는 독특한 별 중의 하나로 여겨졌을 것이다.
왕하 23:5의 planet은 "어둡지만 가까운" 수성 화성 목성 같은 천체건, "까마득히 멀면서 스스로 빛을 내는" 항성이건.. 뭔가 움직임이 독특하고 인간 눈에 띌 만한 천체 픽셀을 통틀어 가리키는 용어가 아니었을까 싶다.

비슷한 예로 베드로후서 3장에 나오는 elements 원소도 있다.
현대의 과학 교육을 받은 사람들이야 이 단어를 읽으면서 화학 원소를 떠올리겠지만.. 성경의 저 본문은 돌턴의 원자설과 원소 체계 같은 게 없던 시절에 기록되었다. 갈라디아서에서는 같은 단어가 어떤 분야의 101급, '개론, 초등 원리' 비슷한 뜻으로도 쓰였다. 뭐, 화학 원소 내지는 그에 맞먹을 정도로 어떤 system의 구성원, 구성요소 같은 걸 떠올려도 될 것 같다.

3. 과학과 종교의 경계

뮤지컬에서 케플러의 대사 중에는.. "나는 신을 안 믿는 게 아니고 성경의 권위를 부정하는 것도 아니다. 우주는 그저 신이 창조한 미지의 안알랴줌 공간인 것이고 그걸 관찰해서 정체를 밝히는 건 자연과학 하는 사람의 별개의 영역일 뿐이다"란 요지의 말이 있었다.

과학은 자연에서 똑같은 방법으로 실험했을 때 누구에게나 똑같은 결과가 재현되느냐 그렇지 않느냐를 따지는 학문이다. 과연 그러한가, 가설이 맞는가 끊임없이 의심하고 입증하는 학문이다. 이런 정상적인 방법론만 동원했다면 부정이니 사기니 틈탈 여지가 전혀 없다. 증거 없이 일단 믿는 신앙이나 신학하고는 완전히 다른 분야이다.

교황청은 지동설이라는 결과가 나오는 게 마음에 안 들었으면 갈릴레이를 잡아 족칠 게 아니라, 선량한 과학자들의 눈을 현혹하는 결과를 내는 망원경부터 때려부수고 망원경 제조업자부터 화형 시켰어지??? 개인적으로는 뮤지컬을 보면서 이런 생각이 들었다.
그건 뭐 아침이 오는 게 싫다고 수탉을 죽이는 것과 같은 뻘짓이지 않은가? 그런 것처럼 괜히 갈릴레이를 종교 프레임 씌워서 괴롭힌 것도 죄다 뻘짓이었다.

혹시 설마 '안알랴줌'이 불편하거나 불경스럽게 들리시는가? 하나님은 당장 우리 삶 속에서도 갑자기 이유 없는 고난을 주실 때가 있고, 예수님 재림 날짜도 안 알려주시고, 나 언제쯤 죽는지도 안 알려주신다. 우리 일상 속에서 안알랴줌이 엄청 많다. 하물며 자연과학 영역에서 안알랴줌 정도는 하나님의 성품과 관련하여 문제될 게 하나도 없다.

그리고 하나 더.. 여기서 오해하지 말아야 할 점은..
이 교황청이라는 데가 오로지 성경의 문자적인 묘사에만 집착하면서 천체의 움직임을 직접 관찰할 생각이라고는 1도 안 한 고지식한 반지성주의 꼰대 집단이기만 한 건 아니라는 점이다.
오히려 쟤들도 이 바닥에 굉장한 조예가 있었다. 이스터가 언제, 성모승천일이 언제, 날짜와 절기를 따지는 일에 진심이었다. 달력 역법의 이름에 괜히 교황 이름이 붙은 게 아닌 걸 생각해 보자.

1582년에 제정되어 오늘날 전세계 공통으로 통용되고 있는 그레고리력 말이다.
"윤년을 4의 배수 연도마다 한 번씩 무조건 넣으니까 갈수록 오차가 생기더라~ 그래서 400의 배수가 아닌 100의 배수 연도에는 열외를 넣자"
거기 교황과 추기경들은 예나 지금이나 머리 하나는 최고로 날고 기는 똘똘이들이다. 전세계 종교 수장이 아무나 되는 게 아니니.. 지금으로부터 400년도 더 전에 저 정도 관찰을 하고 대안까지 생각해 낸 집단이란 것도 생각해 봐야 한다.

세계 각국에서는 자기네 무슨 왕 재위 n년.. 이렇게 연호를 쓰다가 19세기 말이 돼서야 서구화 근대화 명목으로 서기 연도와 그레고리력을 도입한 편이었다.
그런데 저 동네에서는 임진왜란이 일어나기도 전에 저런 달력을 제정해서 쓰고 애초에 기준 연도도 '서력'이었다니, 이것도 굉장히 대단하게 느껴진다. 그런데도 천동설 지동설 관련해서는 옛날에 이상한 ㄸ고집을 부렸던 것 같다.

4. 태양계 행성들의 주요 제원(?)

자전축: 0도 부근(수성, 토성, 해왕성), 23도 부근(지구, 화성, 목성), 90도 전도(천왕), 180도 전복(금성)
중력가속도: 3.7 (수성, 화성), 8~12 (금성, 천왕성, 지구, 토성, 해왕성), 25 (목성)
자전 주기: 10시간(목성, 토성), 16~17시간(천왕성, 해왕성), 1일(지구, 화성), 58일(수성), 243일(금성) + 27~30일 부근(달, 태양)
표면 대기압: 0 부근(수성, 화성), 1~1.x(지구), 95(금성)

수성은 태양과 워낙 가깝다 보니 공전 주기가 엄청 짧으며(각속도), 실제 공전 속도(선속도)도 혼자 초속 47km에 달할 정도로 겁나게 빠르다. 공전 궤도의 이심률도 독보적으로 가장 크다(타원에 가까움).
화성은 지구와 자전 주기가 비슷하고 자전축 기울기도 비슷하다.

지구야 뭐 표면에 물(바다)이 있고, 달이라는 이례적으로 큰 위성이 있는 게 특이하다.
금성은 지구와 크기가 비슷하고 거리도 가장 가깝지만.. 고체 땅이 있는 지구형 행성으로서는 이례적으로 엄청난 고온 고압 불지옥이다. 자전 속도가 끔찍히 느리고 심지어 역행 자전인 것도 특이점이다. 금성만 왜 저렇게 됐을까.;;

그리고, 화성과 목성 사이에는 행성이 있을 법도 한데 왜 텅 비었고 소행성대만 있는 걸까?
수성이 공전이 빠르다면 목성과 토성은 그 큰 덩치로 자전이 왕창 빠른 게 특징이다. 특히 토성은 자전 원심력 때문에 적도 쪽이 대놓고 부푼 게 티가 날 정도이다. 그렇잖아도 가스형 행성이기도 하니..

끝으로, 하나 더 생각할 만한 건.. '태양일'(또는 회합일)이다.
지구가 스스로 한 바퀴 도는 자전 주기는 23시간 56분 남짓이다. 하지만 그 사이에도 지구가 1/365.25만치 공전을 하니, 지구가 태양을 바라보는 각도도 미세하게 더 나아가 있다. 그래서 지구도 4분만치 더 돌아야 하늘에서의 태양 위치가 다시 원래대로 돌아온다. 이를 더함으로써 지구의 태양일은 24시간이 된다.

이건 1/(자전 시간)이라는 각속도가 1/(공전 시간)이라는 각속도만큼 느려졌다고 생각하면 된다. 그러니 앞의 값에다가 뒤의 값을 빼면 태양일에 해당하는 각속도가 나온다. 그리고 이 각속도의 역수가 곧 태양일이 된다.
지구와 화성은 이렇게 이해하는 게 별로 어렵지 않은데.. 자전이 매우 느린 수성과 금성은 일이 굉장히 재미있어진다.

수성은 자전(약 58.x일)을 3번 하는 동안 공전(약 88일)을 2번 하는 형태로 조석 고정이 돼 있다.
달처럼 1:1이 아니라 3:2라니.. 수성이 공전 궤도가 이심률이 크기 때문에 이런 형태가 된 듯하다.
1/x - 1/(x+1) 의 값은 1/(x*(x+1))이니, 1/2 - 1/3은 1/6이다. (6 = 2*3 = 3*2)
실제로 수성의 태양일은 자전 주기의 3배 겸 공전 주기의 2배인 약 175일이다. 수성의 태양일은 지구나 화성과는 달리, 자기 자전 주기와는 차이가 엄청나게 많이 난다.

그리고 수성의 하늘에서 해가 떴다가 지는 건 단순히 지구 일출 일몰의 slow motion 겸 확대(태양이 훨씬 더 가까이 있으니) 버전이 아닐 것이다.
해가 중천까지 좀 올라가더니만 도로 내려간다. 그런데 이대로 완전히 지는 것도 아니고 다시 뜬다. 게다가 수성의 공전 궤도의 특성상, 태양의 크기 자체도 멀어지면서 작아졌다가 다시 커지기도 한다.
이 모든 과정이 아주 천천히 진행되니 굉장히 기괴한 모양이 될 것이다. 수성은 이 점에서 아주 특이한 행성이다.

다음으로 금성은.. 자전 방향이 역행이어서 해가 서쪽에서 뜬다. 자전 각속도에서 공전 각속도를 빼는 게 아니라 더해 주면 된다. 1/(1/243.02+1/224.70)의 역수는 약 116~117일.. 즉, 금성의 태양일은 각속도 버프를 받는 덕분에 자기 자전 주기의 절반으로 줄어들며, 수성의 태양일보다도 짧다.

금성의 하늘에서 태양의 움직임은 수성 같은 기괴한 변화 없이 지구 일출 일몰의 역주행 slow motion에 가까울 것이다.
다만, 너무 짙은 안개 때문에 실제 금성의 지표면에서는 태양 따위 제대로 볼 수 없을 것이다.

수성이나 금성의 공전 주기는 저 갈릴레이 시대에도 망원경 관측을 통해 일찌감치 알려져 있었다. 이 행성들의 복잡한 위상 변화가(커졌다 작아졌다, 초승달-보름달 등등) 천동설로는 설명하기 어려우니 지동설의 근거로도 제시될 정도였다. 그러나 자전 주기는 행성의 표면을 정밀히 관측해야 하기 때문에 알아내기 몹시 어려웠다.
무려 19세기 말까지만 해도 수성은 1:1로 조석 고정되어 자전 주기도 공전 주기와 동일한 88일일 거라고 잘못 알려져 있었다고 한다. 금성은 구름 때문에 완전 불명 오리무중 미스터리였고.. (하긴 20세기 초까지만 해도 금성은 마이애미 해변 같은 곳일 거라고 예상됐었다ㄲㄲㄲㄲ)

그래서 수성과 금성의 정확한 자전 주기는 1960년대에 전파 레이더가 발명된 뒤에야 알려졌다고 한다. 공전 주기와 자전 주기는 마치 지구 임의의 지점에서 위도와 경도를 측정하는 것과 비슷하달까? 그렇게 엄청난 난이도의 차이가 있었다.