몇몇 역사 사건 분석

1. 소름 끼칠 정도로 정확하게 적중한 "20년 텀" 예측

(1) 1차 세계대전이 끝난 뒤, 프랑스의 페르디낭 포슈 원수는 1919년 6월에 열린 베르사유 조약(패전국 독일 vs 연합국)에 대해서, "이건 영구적인 평화를 이뤘다고 볼 수 없고 기껏해야 20년 정도의 휴전으로 그칠 것"이라고 전망했다.

==> 딱 20년 뒤인 1939년 9월, 나치 독일이 폴란드를 침공하여 2차 세계대전이 시작됐다.

(2) 1956년 7월, 미국의 전기 기술 전문가 시슬러 박사는 우리나라의 할배 대통령을 만나서 너님 나라는 원자력을 적극 육성해야 한다고 강조했다. "원자력은 화석연료보다 훨씬 더 많은 에너지를 낼 수 있는 꿈의 에너지입니다. 땅이 아니라 머리를 캐서 만드는 에너지이기 때문에 자원 빈국인 한국 실정에 아주 적합합니다."

할배는 이 권고를 적극 받아들여서 그 가난한 나라 살림에 국비를 들여서 원자력 전문가를 양성하기 시작했다. 국비로 유학 보내 주고 교육 파견 보내고..
시슬러는 할배에게 "지금 원자력 프로그램을 시작하면 그 꿈이 20년쯤 뒤에 이루어질 것"이라고 말했다.

==> 거의 정확히 20년 뒤, 1978년 4월, 원조가카의 집권 후반기가 돼서야 우리나라 최초의 원자력 발전소인 고리 1호기가 완공됐다.

2. 나라들 비교

세계 대전 진영

  • 일본은 1차 대전 때는 말석이나마 연합국 승전국 진영에 있었지만, 2차 대전 때는 미국을 대적한 추축국 전범국으로 전락했다.
  • 이와 비슷하게 중국은 2차 대전 때는 일본에게 침략을 당한 뒤 어째 연합국 승전국 쪽 줄을 섰지만, 다음 세계대전(만약 벌어진다면) 때는 얘야말로 추축국이 될 가능성이 아주 높아 보인다.;;

국력과 위상의 차이

  • 미국은 자국 내에서 전쟁이 벌어진 적이 전혀에 가깝게 없고(남북전쟁이나 미영 전쟁은 너무 옛날이고, 진주만이나 9 11 정도나 예외?? 그리고 그걸로 끝), 현재는 세계 곳곳에 자국 군대를 파견해서 다른 나라들을 도와주는 경찰 국가이다. (늘 모범 경찰이지는 않았을 수도 있지만 아무튼)
  • 일본은 옛날에 너무 사고를 친 벌로 군대를 가질 수 없는 나라가 됐다.
  • 그 반면, 한국은.. X도 힘이 없고 자기들끼리도 제대로 못 뭉친 대가로.. 세계 수많은 나라들로부터 도움을 받아서 간신히 살아남았고, 현재는 군대를 안 가면 안 되는 나라가 됐다.

3. 일제강점기 전후에 일본의 변화

일본은 일제강점기의 거의 직전부터 육군 군복이 바뀌었고..
패전(자기네)과 해방(한국) 거의 직후부터 맞춤법이 바뀌었다.
그래서 딱 러일 전쟁까지만 해도 일본군은 군복이 검정이다가 몇 년 뒤 호남 지방 의병을 토벌하던 무렵엔 이미 우리에게 익숙한 그 황토 내지 황록색 군복 차림을 하기 시작했다. (1905년 38식 군복 ~ 1912년 45식 군복)

그 반면, 지금 쓰이고 있는 일본어의 표기 체계는 일제강점기가 끝나면서 정립됐다.
1946년부터 히라가나가 공문서에서도 쓰이기 시작했고 표기하는 방식 자체도 살짝 바뀌었다. 상용 한자를 재정립했으며, 1949년에는 신자체라 해서 우리가 ‘약자’라고 부르는 그 간소화된 한자들도 완전히 공식화됐다. 나라 국을 或이 아니라 玉을 곁들여서 쓰는 것으로 중국 간체자보다 먼저 정한 것이다. (중공은 6 25 사변이 끝나던 때까지도 아직 或이었음)

요컨대 일본은 한반도 일제강점기의 앞에 군복 개편, 뒤에 맞춤법 개편이 있었다는 점이 주목할 만한 점이다.
이와 비슷하게.. 한반도에서 1900~1910년 사이에 일제 시대의 시작을 열었던 철도가 경부선· 경의선(중국 연결)이라면,
1940년대에 일제 시대의 끝을 함께하고 끝내 완성되지 못했던 철도는 동해선(러시아 연결)이다.

금강산선(관광용..)이나 경북선(적자) 같은 철도는 이미 있던 선로도 전쟁 물자 공출 명목으로 뜯어갔었지만 이런 장거리 간선은 미래를 내다보고 일제가 전쟁 중에도 굳이 애써 건설하고 있었던 것이다.

4. 일제 시대에 아직 우리나라에 없었던 것

말이 나왔으니 말인데, 일제 시대에 아직 한반도에 없었고 해방 후나 일제 말기가 돼서야 도입된 것들을 더 늘어놓자면 다음과 같다.

  • 디젤 기관차: 다만, 전기 기관차는 금강산선에 있었다. 195~60년대엔 우리나라에 반대로 디젤 기관차가 있고 전기 기관차는 없었다. (기존 기관차는 금강산선의 폐선과 함께 폐차됨)
  • 명조체: 일제 시대에는 여전히 개역성경체 같은 붓글씨 서체만이 쓰였다. 오늘날의 명조 같은 서체는 해방 이후부터 본격적으로 쓰이기 시작했다.
  • 손목시계: 아직 고가의 사치품이었다. 한반도에 내려왔던 소련군 양아치들이 즐겨 약탈했던 것으로 유명하다.
  • 텔레비전: 천황 옥음방송은 라디오로 송출됐었다~! 다만, 일본 말고 서양의 독일은 아무래도 텔레비전 기술의 선구자이다 보니 1936년 베를린 올림픽을 벌써 영화 필름이 아니라 텔레비전으로 생중계를 했다.
  • 길거리에 중앙선과 신호등: 경성 시내에조차 저런 게 아직 없었다. 일제 시대엔 아직 "자동차는 사람을 피해서 도로의 중앙으로 다닐 것"이라는 단선 철도 같은 규범만이 존재했다. 자동차가 워낙 적고 넓은 도로가 없었으니까..

5. 공작원, 핵 개발

할배는 말기 때 북한이 아니라 일본으로 테러 공작을 위한 공작원을 보냈었다. 다른 반일 감정 때문이 아니라, 일본에서 벌어지고 있던 재일 교포 북송을 저지하기 위해서였다. 심지어 김 구 암살범인 안두희조차 그 공작원 중 하나였다.
할배는 자국이 아니라 남의 나라 영토에 있는 자국민 동포가 거짓말에 낚여서 북한으로 가는 것까지도 저지할 정도로 정말 반공 박애주의자였다.

한편, 원조가카는 말기 때 자주국방을 위해 핵무기를 몰래 개발하고 있었다. 1970년대에 저 사람 최대의 고민거리는 석유 파동과 주한 미군 전면 철수였지 싶다. 이론물리학자이던 이 휘소 박사야 이것과 전혀 무관한 인물이지만, 할배 때부터 육성했던 한국의 원자력 전문가가 이 휘소만 있는 건 아니었고, 핵 개발을 주도한 것 자체는 사실이다.

비공식 회고에 따르면 원조가카는 96년쯤의 올림픽 유치와 행정수도 이전, 핵무기까지 짠~ 마무리 지은 뒤에 퇴임할 생각이었다고 한다.
참고로 행정수도 이전은 요즘 같은 국토 균형 발전 따위가 아니라.. 단순히 지금 서울이 북한과 너무 가까워서 불안한 것 때문에 구상하던 과업이었다.

원조가카가 암살 안 당하고 유신 헌법으로 9대 임기를 만료하면 84년, 10대 임기까지 만료하면 90년까지 가긴 했을 텐데..
공작원과 핵무기 모두 수장이 하야하고 암살당하면서 백지 물거품이 돼 버렸다. 뭐 둘 다 궁극적으로 장점만 있는 건 아니었을 것이고 국제적으로 여러 후폭풍을 감내하는 위험한 일이었지만.. 할배와 원조가카 두 분 다 북한과 관련해서 참 엄청난 일을 하고 있긴 했던 게 사실이다.

그 뒤로 남한이 허울 좋은 민주화니 화해니 평화니 헛소리에 놀아나면서 좋은 기회들을 다 병신같이 날린 바람에, 지금은 반대로 적국이 핵무기를 만들어 버리게 된 게 안타깝다.

6. 국내 최초의 로켓 개발

6· 25 사변의 휴전 이후 딱 정확히 6년 뒤인 1959년 7월 27일.
우리나라에서 국방 과학 연구소의 전신이라 할 수 있는 ‘국방부 과학 연구소’의 주관으로 나름 40km 고도까지 날아간 다단계(3단) 분리 로켓을 개발해서 쏘아올린 적이 있었다.

아니 그 옛날에..?? 지금으로서는 정말 믿기 힘든 소식이며, 관련 전공자들도 이 사실을 뒤늦게 접하고는 “엥??” 이런다. 참관한 대통령은 비교적 친숙한(?) 박통이 아니라 할배였다. 시연 장소는 인천 바닷가. (☞ 대한뉴스 제225호 보도, ☞ 관련 자료)

할배 때 나름 그 없는 살림에 원자력 연구소도 만들었고 서울대와 한양대 공대에 원자력공학과를 신설했다는 얘기는 들었다만, 자기 입김이 직접 개입해서 설립된 인하대에다가는 아예 ‘병기공학과’를 만들었다고 한다.
1957년, 소련의 스푸트니크 인공위성 소식 때문에 미국뿐만 아니라 우리나라도 뭔가 느낀 게 있었던 것 같다.

그런데 뭔가 연구 개발을 했으면 노하우를 꼼꼼히 기록하고 전수하는 것도 중요하다. 안 그러면 예전에 애써 개발했던 걸 또 중복 개발해야 된다.
저 때 우리나라의 로켓 연구는 이듬해 할배 정권의 붕괴으로 인한 나라 혼란, 그리고 한반도에서의 발사체 개발을 싫어하는 미국의 견제로 인해 계속되지 못했다.

할배의 로켓, 원조가카의 핵이 연계됐으면 얼마나 좋을까?
할배가 더 오래 살고 4· 19 따위 안 벌어지고 4대 대통령까지 갔으면 역사가 또 어찌 됐을지 모른다. 마치 “박통이 암살 당하지 않았으면”처럼 말이다.
다른 건 몰라도 한국-일본 재수교가 박통 때의 1965년보다는 확실히 더 늦게 성사됐지 싶다.

7. 최초의 국립공원과 우남 역??

서울 지하철 8호선은 복정과 산성 사이에 제법 긴 지상 구간을 지나는데, 여기 일대가 개발되고 역이 하나 추가될 예정이다. 그런데 이 역은 현재 계획이나 건설 중인 전국의 여러 추가역들 중에 유일하게 이름이 정해진 게 없어서 밋밋하게 ‘8호선 추가역’이라고만 불리고 있다.

이 역의 가칭은 오랫동안 ‘우남’이었다. 초대 대통령인 이 승만 할배가 어째 남한산성에 꽂혔는지 1954년경에 유적지를 대대적으로 보수하고 여기 근처를 지나는 도로를 닦고, 도로의 이름을 자신의 호로 정했기 때문이다. (그때는 ‘우남호’라는 여객기도 있었던 시절인 걸 감안하도록 하자)

우리나라에 국립공원이라는 게 생긴 게 1960년대 박통 시절의 일이고 지리산 국립공원이 제1호 최초라고 알려져 있다. 하지만 그 전에 할배도 국립공원이라는 걸 만들 생각을 했으며, 남한산성을 1호로 지정했었다고 한다.
하지만 그게 할배가 물러난 뒤에 싹 다 리셋돼 버렸고 관련 기록도 별로 전해지지 않는다. 게다가 우남로라는 이름도 지금은 그 도로가 인근의 헌릉로에 흡수되어서 없어졌다.

안 그래도 2010년대 초에 성남시장을 포함해 관련 정치인들은 정치적으로 할배를 매우 싫어하고 할배의 흔적과 존재를 지우고 싶어하는 좌편향이었다. 그래서 개명이 광속으로 추진되어 우남로, 우남 역 모두 금기어가 되었으며, 8호선 추가역은 가칭이 존재하지 않는 유일한 역으로 전락한 것이다. 행정구역의 이름을 감안하여 중립적인 이름을 굳이 정한다면 위례 정도가 돼야 할 것 같다.

현재는 남한산성이 다들 아시다시피 국립이 아니라 도립공원이다(since 1971). 소재지의 행성구역은 광주시 중부면이다가 2015년에 면의 이름 자체가 '남한산성면'으로 바뀌었다.

8. 중국과 북괴

  • 옛날에 우리나라 임시정부의 항일 독립운동을 도와줬던 진영은 장 제스이지 마오 쩌둥이 전혀 절대 아니다! 중공은 대한민국의 북진 멸공 통일을 저지한 원흉이다.
  • 북괴는 일본이 패전 후에 GHQ로부터 참교육 받고 체제가 바뀐 것만치도 달라진 것이 없다. 북괴는 일본이 그나마 립서비스로마나 사과하고 보상한 것만치도 과거사를 사죄한 적 전무하다.

이런 와중에 아직도 친일 청산을 못 했네 하는 헛소리는 많은 말이 필요 없고 그냥 망상 정신병일 뿐이다. 온갖 악하고 삐딱하고 잘못된 사상들의 근원이 바로 존재하지도 않는 일제 잔재나 친일파 따위 탓하는 반일정신병이다.
2010년대에도 아직도 전향을 못 했을 정도이면.. 진짜로 그냥 죽어야 낫는 말기 정도라고 생각하면 되겠다.

저그의 패러사이트는 메딕의 리스토어로 고칠 수라도 있지, 현실의 반일정신병은 그런 것도 없다.. 팩트로 치유되지 않으면 다른 그 어떤 걸로도 치유할 수 없기 때문이다.

Posted by 사무엘

2021/02/24 08:34 2021/02/24 08:34
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1858

1. 요즘 보기 어려워진 것들

  • 길가의 평행주차용 동전 투입 주차기: 각 주차 구획마다 돈 투입구와 시각 카운터가 달려 있는 그 물건 말이다. 만화영화 주토피아에 나오고 미국· 일본에는 지금도 있다. 우리나라는 과거에는 있었지만 지금은 자취를 감춘 것 같다. 요즘 치솟는 인건비 때문에 단순 노동은 다들 무인화 기계화되는 추세이지만, 노상 주차장은 내가 보기에 사람이 운영하는 경우가 더 많다.
  • 기계식 주차 타워: 198, 90년대에는 첨단 기술이라고 소개되는 편이었지만 큰 차가 들어가기 어렵고 운영비가 많이 들고 종종 사고도 나서 그런지 요즘은 잘 안 만드는 것 같다. 그냥 지하 주차장을 큼직하게 만들고 만다.
  • 천장에서 아래로 매달려서 목운동 하듯이 돌아가던 선풍기: 교실과 각종 대중교통에서 볼 수 있었던 물건이지만 요즘은.. 천장형 에어컨에 밀려서 거의 볼 수 없어졌다.

여담으로, 소용돌이형 모기향은 당연히 초록색일 거라고 생각했는데 요즘 팔리는 것들은 다 갈색이다. 모기향에 전통적으로 쓰이던 초록색 색소가 발암 유해물질이라고 판명되어 퇴출됐기 때문이랜다.
우주왕복선도 처음 발사됐을 때는 기체가 몽땅 간지나는 흰색이었는데, 나중에는 액체 연료 탱크 부위는 도색하지 않고 그냥 갈색 단열재 색깔이 노출돼 보이는 형태로 바뀌었다. 이것과 비슷한 느낌이 든다.

2. 옛날 전화기

피처폰과 스마트폰의 기술적인 차이는 정확하게 무엇일까? 피처폰도 컬러 화면이고 카메라가 달려 있고 터치스크린 기반일 수 있다. 하지만 얘는..

  • 소프트웨어 확장성(O): 스마트폰과 달리, 안드로이드나 iOS 같은 범용 모바일 운영체제 기반이 아니며, 기본 내장된 앱만 쓸 수 있다. 임의의 3-rd party 앱들을 자유롭게 설치하거나 지울 수 있지 않다.
  • 사용하는 통신망의 기술 수준(X): 2G냐 3~4G냐 하는 것은 구형폰이냐 최신폰이냐의 차이이지, 피처폰과 스마트폰의 차이가 아니다.
  • 비디오 성능과 글꼴(X): 화면에 비트맵 글꼴이 찍히던 전화기를 쓰던 게 10여 년 남짓 전 같은데.. 요즘 전화기는 고해상도 화면에 트루타입 글꼴과 다국어 레이아웃 엔진을 갖추고 있다. 확장 평면 한자고 아랍어고 이모지고 모두 표현 가능하다. 하지만 이 역시 구형폰과 최신폰의 차이이지, 피처폰과 스마트폰의 차이는 아니다.

2000년대 중후반, 휴대전화라는 게 처음 등장하고 화면이 컬러로 바뀌고 카메라가 내장되는 등.. 전화기가 심상찮게 변모하고 있던 시절에는 충전 단자도 통합 규격이 없어서 서로 제멋대로 완전히 따로 놀았다. 1980년대에 PC에서 한글 코드들이 난립하던 것, 2000년대까지 동영상 코덱들이 난립하던 것과 다를 바 없던 불편한 시절이었다.

지금으로서는 정말 믿어지지 않는 장면인데.. 어느 샌가 싹 교통정리가 됐다. 늘 드는 생각이지만 21세기 이래로 휴대전화가 발전해 온 모습을 보면 경이로움 그 자체이다.

3. 골동품의 가치 함수

자동차, 컴퓨터, 가전기기 같은 물건들은 구입한 직후부터 중고품이 되어 되팔 때의 가격이 서서히 하락하기 시작한다.
완전히 똥차 똥컴 폐급이 되는 시점에서는 가치가 0이 되고 심지어 마이너스가 되기도 한다. 즉, 이 따위 쓰레기는 가져가 주는 사람에게 역으로 돈을 주는 구도가 된다.

그런데 그 물건을 안 버리고 고이 보관한 채로 수십 년의 시간이 흐르면 어떻게 될까?

  • 아직도 포니나 브리사를 생생하게 굴리는 사람이 있다면?
  • 아직도 동작 가능한 286 XT 컴터를 보유한 사람이 있다면?
  • 브라운관 모니터/텔레비전이라든가 볼 마우스, 옛날 애니콜 시절의 전화기를 보관 중인 사람이 있다면?
  • 계몽사 학습 그림 과학 같은 80년대 책을 가진 사람이 있다면?
  • 아직도 1980년대 원화 구권 지폐를 보관 중인 사람이 있다면? 그리고 옛날 디스켓, 카세트 테이프 같은 건 어떨까?

그럼 그 물건은 보존과 관리 상태가 좋다는 전제 하에 희소성 덕분에 가치가 다시 서서히 오르게 된다. 50년 이상~100년 가까이 세월이 흐르면 후손들이 아버지나 할아버지가 수집해 놓은 옛날 물건을 밑천으로 장사도 할 수 있을 것이다. 올드카 대여업 같은 것 말이다.

이렇게 서서히 하락해서 0이나 음수가 됐다가 한참 뒤에 값어치가 서서히 오르는 현상은 나름 보편적인 구석이 있어 보인다. 혹시 시간 t에 대한 수학 함수로 기술할 수는 없을까?
물론 변수가 단순한 형태는 아니다. 보존 상태라든가, 현역일 때 가격이 떨어지는 속도, 그 제품의 평균적인 교환 주기와 수명 등을 다양하게 감안해야 한다. 이건 심리학과 산업공학 같은 걸 한데 연계한 연구 주제가 될 수 있을 것 같다.

4. 단색 화면

요즘이야 천연색 초고화질 카메라가 달린 CCTV와 스마트폰이 넘쳐나고 있지만.. 컴퓨터 모니터와 텔레비전이 단색(모노크롬!)이던 시절이 있었다는 것이 지금으로서는 도저히 믿어지지 않는다. 집의 현관 인터폰은 아직도 흑백인 경우가 많이 눈에 띄지만 이것도 세월이 흐르면 바뀔 것이다.

모니터는 흑백 TV와는 달리 검은 배경에 흰색만 있는 게 아니라 초록과 호박(주황) 이렇게 3색이 있었다. 개인적으로는 학교나 학원 등의 주변에서 초록: 하양: 주황을 본 빈도가 거의 3:2:1의 비율이었던 것 같다. 마치 자동차를 구매하면서 도색을 고르듯이 단색 모니터는 색깔을 고를 수 있었던 것이다.;;

텔레비전이야 기술적으로는 이미 1970년대부터 컬러화가 가능했지만, 우리나라는 원조가카가 여러 모종의 이유 때문에 의도적으로 도입을 저지했다. 그때 우리나라 정도의 경제력과 구매력으로는 라디오도 아니고 TV는 여전히 굉장한 사치품이었기 때문이다.
그래서 TV의 컬러화는 1980년대의 전땅크 5공 시절에 가서야 실현됐다.

딱 그렇게 텔레비전이 가정마다 보급됐을 때 마침 6 25 휴전 30주년도 됐고.. KBS에서 "이산가족을 찾습니다"를 기획해서 방영한 것은 너무 이르지도 늦지도 않게 타이밍을 정말 기막히게 잘 잡은 초대박 이벤트였다.

5. 미래 전망

(1) IPv6: IPv4 주소가 완전히 고갈되고 할당이 종료된지 어언 10년이 돼 가지만 IPv4는 오늘날 여전히 건재하다. IPv6의 보급은 당시 예상과 달리 2020년 현재까지도 여전히 매우 더딘 편이다. 공유기로 유동IP를 쪼개는 편법으로 공간 문제가 그럭저럭 극복되고, 일반인들이 당장 큰 불편이 없기 때문인 듯하다.

(2) ARM64: 과연 ARM 기반 CPU는 스마트폰을 넘어 x86 천지인 PC 시장까지 뚫을 수 있을까? 이건 요즘 컴터쟁이들의 초유의 관심사이다.

  • 먼 옛날, 인텔이 결국 Itanium을 포기하고 x86-64로 갈아탐.
  • 마소가 결국 Windows Phone을 포기하고 데스크톱용 Windows 10을 그대로 ARM64로 포팅함.
  • 마소가 결국 자체 MSEdge 엔진을 포기하고, Edge 브라우저를 크로뮴 기반으로 다시 만듦.

마소뿐만 아니라 애플도 말이다. 과거에 PowerPC에서 인텔로 갈아탔던 것처럼, 거기서도 x86-64를 과감히 버리고 ARM64로 물갈이를 해 버릴까? 세계를 좌지우지하는 공룡 IT 기업의 경영자들은 어떤 생각을 하고 있나 궁금해진다.

(3) 전기차: 배터리 문제를 도저히 극복하지 못해서 만년 소형차에나 머물 것 같고 테슬라는 저래 갖고 버티겠나 싶었는데.. 요즘은 의외로 물건 잘 만들고 잘 나가고 있는 것 같다.
오히려 수소 연료전지를 전통적으로 밀었던 현대차가 미래가 더 불투명해진 것 같기도 하지만.. 그래도 순수 전기차가 넘보지 못하는 대형 상용차(버스, 트럭)을 수출까지 하면서 활로를 찾고 있다. 쟤들은 수소 공급 인프라를 같이 잘 구축해 나가야겠다.

(4) 8200호대 전기 기관차: 21세기 초반에는 철도계에서 아주 각광받는 스타 효자였지만 앞으로 얼마 못 가 계륵 애물단지로 전락할 것 같다.
얘들이 담당하던 무궁화호 객차들이 슬슬 퇴역하고, 신형 여객열차들은 전부 기관차 기반이 아닌 전동차들이고, 화물은 8500이나 7600 같은 전담 기관차가 따로 있으니 얘네들을 써먹을 데가 없기 때문이다. 더구나 나라마다 철도 전기 규격이 제각각인 편인지라, 얘들은 디젤 기관차와 달리 중고품 수출하기도 난감하다!

(5) 미래형 초고속 교통수단: 새로운 초음속기 내지 재래식 레일+바퀴식을 초월하는 초고속 자기부상, 진공 튜브 열차가 과연 2020년대에 선보일 수 있을까? 일본의 츄오 신칸센만 해도 2020년대가 다 끝나야 나올까말까인데 현재로서는 불투명하다.
참고로 16년 전, KTX가 처음 개통했을 때는 KTX가 자기부상 방식이라고 잘못 알던 사람도 많았다. 그때는 그만큼 인지도가 부족했다. 내가 강조하지만 그때는 아직 유튜브가 없어서 “이제 우리가 뜬다” 같은 개통 홍보 동영상조차 지금 남아 있지 않다.. 엄청난 옛날이었다.

Posted by 사무엘

2021/02/21 19:35 2021/02/21 19:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1857

1. 침례교

기독교의 여러 교파 중 침례교는..

  • 딱히 종교 개혁에서 유래되지 않았고, 더 옛날부터 있었다고 여겨진다. 천주교는 물론이고 일부 개신교 교파로부터도 박해를 받았다.
  • 이름이 말하는 바와 같이 세례가 아니라 침례가 성경적으로 옳다고 본다. 온몸이 물에 잠겼다가 나와야 된다.
  • 침례는 이미 구원받은 후의 신앙고백 인증일 뿐이지, 그 자체가 구원의 조건이거나 다른 의미를 지니고 있지 않다.
  • 특히 유아세례를 인정하지 않는다. 그건 할례나 안수 따위와 아무 상관 없는 관행이고, 대상과 방법이 모두 잘못됐다. 적어도 10대 정도의 나이가 됐고 스스로 선과 악을 분별하고 내 믿음을 자기 말로 고백할 능력이 돼야만 침례를 준다.

* 개인의 혼의 자유의지를 매우 존중하며 단호한 정교분리를 주장한다. 미국이 민간에서의 강한 기독교 배경에도 불구하고 독일처럼 국교가 있고 목사가 공무원인 나라가 되지 않은 것에는 침례교인들이 매우 큰 기여를 했다!
미국의 건국 모델은 후대에 세워진 세계 다른 나라들과 정부에도 선한 모범 참고 사례가 되었다.

* 침례를 받을 자격이 안 되는 너무 어린 아이, 스스로 선과 악을 분별할 능력이 없는 아기 등은 죽으면 그냥 바로 천국으로 간다. 유아세례를 받았건 말건 그것과는 전혀 무관하다! 내가 이 개념에다가 개인적으로 붙인 명칭은 ‘특례 구원’이다. 이런 애들은 죄에 대한 책임이 부과되지 않는다.
세종대왕이나 이순신은 자기 죄 가운데 죽었다면 지옥에 갈 수 있다. 하지만 낙태돼서 죽은 애들, 영 유아 때 병에 걸리거나 굶어 죽은 애들, 그리고 특별히 올해 초에 전국민에게 큰 슬픔과 분노를 안겼던 학대 피해자인 정인이 같은 애는 절대로 지옥에 가지 않는다.

사실, 천국에 가 보면 예수 믿어서 구원받은 사람보다, 저런 특례구원으로 온 사람이 인류 역사상 더 많을 거라는 게 내 추측이다.
(예수님 탄생 당시에 헤롯 왕에게 학살당한 2살 이하 동갑내기 아기들이 지옥에 가 있을 거라고는 전혀 여겨지지 않는다. 만약 그런 거라면 개독안티들이 이것 갖고 하나님의 성품에 대해 온갖 신성모독적인 조롱을 늘어놔도 실드를 칠 수 없을 것이며, 사실 나조차 기독교 안 믿었을 것이다. 아니면 믿더라도 민망해서 혼자만 조용히 믿고 말지, 이렇게 당당하게 교리를 설파하고 불신자와 논쟁할 엄두는 못 냈을 것이다.)

그 대신 이렇게 어리고, 특례 구원 실드가 있는 애들에 대해서는 부모가 반드시 의로 양육해서 특례 실드가 끝난 이후의 일생에 대한 대비를 시켜 줘야 한다. 의로 양육한다는 건 필요한 경우 체벌도 불사한다는 뜻이다. 어머니의 회초리를 무서워할 줄 알아야 나중에 지옥 형벌도 무서워할 줄 알게 된다.

난 침례의 대상과 방법에 대한 의미, 개인의 자유의지와 정교 분리, 아기의 구원 여부에 대해 침례교에서 말하는 것만치 논리적이고 합리적이고 원칙과 체계가 있는 교리를 지금까지 접하지 못했다.
난 그래서 이 교리를 믿고 지지한다. 이 정도 완성도는 되니까 주위에 복음도 전할 수 있고 기독교 관련 글을 쓰고 논쟁도 할 수 있게 됐다.

이 주제에 대해서 본인과 생각이 다른 분들은 하나님의 공의와 사랑 성품과 예정 vs 자유의지에 대해 저것보다도 논리적으로 더 잘 분간하는 교리를 믿는 것이었으면 좋겠다. 물론 킹 제임스 성경 유일주의, 삼분법(영 혼 몸 구분), 하나님 왕국과 하늘의 왕국 구분(하나님 ≠ 하느님이듯이!), 창 1:1-2 간극, 문자적인 천년왕국과 세대주의 같은 건 침례교 내부에서도 똑같이 가르치지는 않는 교리들이다.

2. 종교 개혁의 유산

옛 종교개혁자들이 후세의 크리스천들에게 남겨준 것,
혹은 원래 있었다가 모종의 이유로 봉인됐던 것을 성경을 통해 재발굴 재조명해 준 것은..

(1) 이신칭의

  • a. 마음의 회개 없는 거짓 구원, 그저 "울 교회 오세요, 그럼 님하에게 이득입니다, 예수 믿으면 복 받고 잘 삽니다" 거의 종교 영업사원 수준의 easy believism
  • b. 혹은 반대로 아예 행실의 회개와 변화가 없는 건 구원받은 것도 아님. 예수님을 단순 구원자뿐만 아니라 니 행실의 '주권자'로도 반드시 받아들여야 된다 lordship salvation

둘 다 매우 잘못된 극단이다.
내가 여러 번 강조하지만, b가 자주 저지르는 오류가 뭐냐 하면 꼭 나쁜 행실만 죄인 줄 안다는 것이다. 예수 안 믿은 거 자체부터가 엄청난 죄였고 거기서 돌이키는 게 진짜 구원을 가져다주는 회개인 걸 좀 헷갈린다.

"저는 앞으로 술 담배 끊고 모든 악한 행실을 끊고 예수님처럼 경건하게 살기로 결단했습니다. 그러니 저를 구원해 주십시오" 영접 기도를 이딴 식으로 해서는 절대로 구원 못 받는다! 절대로~!! 알겠는가?
a야 너무 수준 낮고 더 논할 가치도 없으니 제낀다.

(2) 만인 제사장

  • a. 목사님은 거~룩한 주의 종님임. 목사의 축도를 안 받으면 예배가 끝난 게 아님. 차 살 때, 가게 개업 했을 때는 영험한 목사님 초빙해서 안수 기도라도 좀 받아야 됨.
  • b. 아예 목사 직분 자체가 니골라 당의 잘못된 교리이다. 예배와 친교의 구분이 없다. 형제들이 돌아가면서 설교한다.;; (헐~)

이 역시 둘 다 잘못된 극단이다.
직분과 역할의 차이를 전부 우열 계급 투쟁으로 프레임 씌우고 체제를 전복시키는 거.. 보통 빨갱이들의 수법이다.

(3) 변개되지 않은 올바른 성경 본문 그 자체
내가 보는 성경은..

  • 헤롯 왕이 지목한 베드로 처형 시점이 유월절이 아니라 이스터라고 돼 있고(행 12:4),
  • 루시퍼와 갈보리라는 명칭이 있으며,
  • 계시록에 증인이 아니라 순교자라는 단어가 존재한다.
  • 예수 그리스도 그분의 피', '지옥' 이런 단어가 여타 성경보다 더 자주 등장한다.
  • '이사야+말라기 = 대언자들'이지.. 이거 무슨 1+1=1도 아니고, 말라기의 예언까지 이사야라고 몽땅 퉁치는 오류 역시 존재하지 않는다. (막 1:1-3)

뭐 등등..
에라스무스로부터 시작해서 루터는 바른 본문에서 독일어 성경을 번역했고, 칼빈은 제네바에서 KJV의 전신인 제네바 성경이 나올 수 있게 해 줬다.

(4) 그 밖에 루터는 너무 엄근진스럽거나 몽환적이기만 하던 교회 음악도 진입장벽을 낮추려 애썼다. "내 주는 강한 성이요"를 직접 작사 작곡하기도 했다.

Posted by 사무엘

2021/02/19 08:36 2021/02/19 08:36
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1856

꿈의 사람 요셉

성경에서 요셉 이야기는 창세기의 끝부분을 장식하는 매우 드라마틱한 에피소드이다. 본인은 먼 옛날에 이집트의 왕자 만화영화와 같이 모세 얘기는 한 적이 있었는데.. 모세 만만찮게 흥미진진한 요셉에 대한 이야기는 지금까지 블로그에다 진지하게 늘어놓은 적이 전혀 없었던 것을 의아하게 생각한다.;;

성경에는 예수님의 예표 인물이 여럿 있다. 하나님 앞에서 개기다가 고래에게 잡아먹히고 죽다 살아 나온 선지자(대언자) 요나조차도 예수님의 위대한 예표이다. 그런데 요셉은 예수님과 무려 100~150가지가 닮았다고.. 무슨 피타고라스 정리의 증명법만큼이나 많은 유사성이 존재한다고 여겨진다.

옛날에 한국 컨티넨탈 싱어즈에서 "꿈의 사람 요셉"이라는 뮤지컬 음반을 내놓은 적이 있고, 드림웍스에서도 이집트의 왕자 다음으로 2000년에 요셉 이야기를 애니로 만들었다. 우리나라는 스토리상 속편이 전혀 아닌 작품도 그냥 2라고 붙이는 걸 좋아해서.. 옹박 2, 이집트의 왕자 2 이런 식의 작명을 거쳐서 개봉했었다.

사용자 삽입 이미지
사용자 삽입 이미지

요셉은 세상 물정 모르는 색동옷 차림의 늦둥이 막내아들 철부지 꿈쟁이였다. 그러나 형들로부터 시기를 받아 인신매매를 당하고 하루아침에 밑바닥 노예로 전락해서 인실X을 혹독하게 체험하게 됐다..;;

그 뒤 이집트에서 겨우 기반을 잡는가 했는데 이번엔 성폭행 흉악범 누명을 쓰고 감방에 갇히고 말았다. 석방되는 동료 죄수의 꿈을 해몽해 줬지만, 그 동료의 무관심으로 인해 2년을 감방에서 더 썩었다. 요즘 현대인들의 정신 상태였다면 꿈도 희망도 없는 현실에 억울하고 원통해서 몇 번이고 자살했을 법도 한 상황이었다.

요셉은 성경에 인생 흑역사나 결점이 기록된 게 전혀에 가깝게 없으며, 특히 이성의 유혹을 성경 전체를 통틀어서 FM대로 제일 모범적으로 잘 대처한 사람이었다. 그런데 그 대가로 당장 돌아온 게 저 지경이었다. 얼마나 억울했겠는가?

성경에 자세히 적혀 있지는 않지만... 보디발의 아내 겁탈 누명의 경우, 보디발도 이건 요셉의 잘못이 아니라는 걸 알았지 싶다. 요셉이 아니라 자기 마눌에게 바람기가 있다는 것을 어느 정도 인지했을 것이다.
일개 노예가 감히 주인의 아내를 범한 건 최악의 파렴치 중범죄이며, 이건 투옥이 아니라 그냥 즉결 사형감이다. 만약 요셉이 진짜 범인이라면 그 역시 죽음을 면치 못했을 것이다.

하지만 반대로 요셉을 완전히 무죄방면해 버리면 자기들의 입장이 심히 난처해진다.
이럴 수도 저럴 수도 없으니, 절충안으로 요셉을 죽이지는 않고 그냥 감옥에 격리시키는 것으로 일을 덮은 게 아닐까? 요셉이 투옥된 뒤 보디발 집안에서는 대판 부부싸움이 벌어졌지 싶다.

이런 우여곡절을 겪은 뒤, 요셉은 "해석이란 건 {주}께 속해 있지 않습니까?"라는 명대사와 함께 파라오가 꾼 뒤숭숭한 꿈을 정확하게 해석해 냈다. 덕분에 그는 이집트에서 의전 서열이 파라오의 바로 다음 2위인 총리로 순식간에 신분이 바뀌었다.

그리고 꿈에서 계시되었던 바와 같이, 7년 풍년 이후에는 세계적으로 엄청난 흉년 기근이 창궐했다. 이에 대한 대비가 철저히 된 나라는 이집트밖에 없었다. 그러니 요셉의 형들도 곡식을 사러 이집트까지 찾아와서 요셉을 대면하게 됐다. 자, 그럼 요셉은 형들을 어떻게 대하면 좋을까?

이건 요셉이 지혜를 발휘해서 거의 하나님 급으로 공의와 사랑을 적절히 보이며 처신해야 하는 순간이었다.
마냥 "오 어째 이런 우연이~! 형님들 잘 오셨습니다~ 난 이집트 총리가 됐답니다~ 멋있쪙?" 할 수도 없고, "오냐, 옛날에 날 노예로 팔아넘겼던 네놈들이 제 발로 찾아왔군. 이제 내가 보복할 차례다. 한번 제대로 엿먹어 봐라" 이럴 수도 없었기 때문이다.

요셉은 처음에는 까칠하게 굴면서 형들이 자기 정체와 과거의 죄를 제 발로 털어놓게 만들었다. 하지만 당장 생존은 가능하게 기본적인 곡식을 무료로 챙겨 주긴 했다. (받았던 곡식값을 자루에다 같이 반환함)
형들이 과거의 죄를 완전히 회개했고, 막내동생 베냐민을 위해서는 필살의 형제애를 발휘하여 차라리 자기들이 대신 노예로 잡혀 있겠다고 호소하는 걸 확인하고서야 요셉도 드디어 엄격 진지 근엄 모드를 풀고 자기 정체를 밝혔다.

성경에서 요셉은 울었다는 장면이 유난히 자주 기록돼 있다.
어린 시절에 형들이 갑자기 자기를 매정하게 생까면서 노예상에게 팔아넘길 때, 억만 리 타지에 끌려가서 노예 취급 받을 때도 당연히 멘붕 해서 "아빠~ 보고 싶어어헝헝" 식으로 엄청나게 울었을 것이다. 하지만 성경엔 그런 건 적혀 있지 않고 더 고차원적인 이유로 운 장면만 기록됐다.

특히 저렇게 형들에게 커밍아웃 하기 직전엔 요셉은 더는 참을 수 없어서 "모두 물러가라"부터 시전했다. 그 뒤엔 궁궐 전체가 쩌렁쩌렁 울릴 정도로 "으허허허헝엉엉~!" 하며 울었다. 우리나라에서도 옛날에 방영했던 "이산가족을 찾습니다" 같은 분위기를 생각하면 된다.

나중에 부친인 야곱이 죽고 장례까지 치르자, 형들은 "이제 아버지가 돌아가시고 안 계시니 요셉이 드디어 본심을 드러내고 우리를 해코지 하면 어떡하지?" 이런 심정으로 요셉에게 자비를 호소하는 애원 간청을 했다. 성경에 따르면 요셉은 이때 마지막으로 또 울었다. 형들이 아직도 믿음이 부족하고 자기 진심을 몰라 준다고.. 이건 요 11에 기록된 예수님의 울음 장면과 매우 비슷한 분위기라고 보면 되겠다.

이것이 성경의 스토리이다. 흥미진진하지 않은가?
요셉이 형들과 이렇게 밀고 당기는 동안, 형뿐만 아니라 아버지 야곱의 믿음도 시험대에 올라서 야곱 모드와 이스라엘 모드를 오락가락했다. 야곱 모드일 때는 멘붕 자포자기 해서 "아이고~ 오래 살아 봤자 험한 꼴밖에 안 보고.. 난 어서 뒈져야지ㅠㅠㅠ" 내지 "요셉으로도 모자라서 베냐민까지? 절대 못 보내~" 같은 육신적이고 꼰대스러운 고집을 시전했었다.

요셉의 일생과 직접적인 관련은 없지만 유다와 며느리 다말 개족보 이야기(38장), 그리고 하몰-세겜 지역 보복 학살극(34장) 사건도 삽입장으로 들어가서 철도 노선으로 치면 간선에서 짧게 뻗어 나간 지선 역할을 한다. ㅎㅎ

Posted by 사무엘

2021/02/16 19:34 2021/02/16 19:34
, , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1855

0. 들어가는 말

한글과 한자 문제는 정말 낡고 케케묵었고, 이미 대세를 거스를 수 없는 결론까지 도출된 주제이다. 본인 역시 나이 40이 임박한 지금까지 20여 년째 동일한 지론을 유지하고 있다. 오늘은 오랜만에 이에 대한 생각을 또 복습해 보고자 한다.

"한글로만 쓰니까 무슨 단어 뜻이 분간이 안 되고 어쩌구저쩌구" 하는 불평들은 나도 하라면 한 트럭을 끄집어낼 수 있다.
"역전의 용사"는 지고 있던 전투를 운동 경기마냥 역전(?)시킨 용사가 아니라는 것,
정부 조직을 가리킬 때의 部와, 삼권 분립을 가리킬 때의 府가 다르다는 것 뭐 등등..
온갖 병신같은 교인이나 목사나 교회 욕하면서 나는 이래서 예수 안 믿는다, 교회 안 다닌다.. 이러는 것과 완전히 똑같은 원리로 늘어놓을 수 있다.

그러나 그러나~~~~ 한글· 한자 문제에서는 다음과 같은 사항을 추가로 고려해야 한다.

1. 쓰기: 문자는 그림보다 아라비아 숫자에 더 가까워야

"한글로만 쓰니까 무슨 단어 뜻이 분간이 안 되고 어쩌구저쩌구" 하는 불평은..
그 자체조차도 나머지 90%에 달하는 이미 잘 분간되는 어휘들을 한글로 정말 편하고 빠르게 잘 읽고 쓰고 있기 때문에 나올 수 있는 불평이다! 알겠는가?

할배가 민주주의를 유린한(? 한 5%쯤?) 독재자라고..??
그 독재를 비판할 수 있는 90~95% 민주주의 토대를 닦아 놓은 사람도 할배다. 그와 같은 이치이다. 자, 이 비유를 들면 좀 이해가 빨리 되려나?

한글이나 알파벳 영단어는 최소한의 문자 체계만 떼고 나면, 최소한 모르는 단어를 사전에서 찾아 보는 거 하나는 아주 수월 간결하게 할 수 있다. 어떤 단어로부터 기본형을 유추하는 게 그리 어렵지 않으며, 유한한 요소만으로 무한의 개념을 표현한다는 체계가 있기 때문이다. 이게 문자와 그림의 본질적인 차이이기도 하다.

허나, 한자는 그림 티를 좀 못 벗은 무한집합-_- 문자이다. 모르는 글자를 옥편에서 찾는 데 시간이 얼마나 걸리며(부수, 획수..) 실패율도 얼마나 높을까?

게다가 읽을 줄 아는 것과 쓸 줄 아는 건.. 또 별개의 문제다. 컴퓨터조차 없던 시절에 "아 배고프다, 밥먹고 싶다" 이런 문장까지 백지 상태에서 한중일 어느 언어 방식이건 한자만으로 써야 한다면..?? 아 정말 끔찍하다.
설령 컴퓨터가 있다 해도 맨손에 펜만 있을 때보다야 쓰기가 편리해질 뿐이다. 다른 간편한 소리글자들도 동일하게 컴퓨터의 혜택을 받고 있다면, 한자는 이것들에 비해 입력하고 취급하기가 번거로우며 여전히 격차가 벌어진다.

2. 말하기/듣기: 글자가 아니라 알아들을 수 있는 말이 먼저

그리고 더 결정적으로, 언어라는 건 말이 먼저지 글이 먼저가 아니다. 한자의 음은 기본적으로 왕창 옛날 중국어 음의 낡은 껍데기일 뿐이다. 한글로만 써 놓으니 분간이 안 되는 문제에 앞서, 말이 글자 그림을 봐야만 이해되는 지경으로 배배 꼬이는 것이 더 문제라는 것이 나의 굳건한 지론이다.

정말 단순하고 상식적인 것에서부터 먼저 의문을 품고 제기해 보자.
수수(授受)와 매매(賣買).
세상에, 지구상의 어느 미친 언어가 '주다'와 '받다'라는 정반대 뜻을 같은 소리로 표현하냐?
'팔다'와 '사다'도 마찬가지.
'방화'는 너무 유명한 예일 테고, 그리고 명왕성의 명(冥)은 '어두울 명'이다. '밝을 명'(明)만 있는 줄 알았지? ㄲㄲㄲㄲㄲㄲ

이건 한자로 적지 않으면 뜻을 알 수 없네 타령을 하기에 앞서 말이 이상한 것이다.
형성자라는 건 알고 보면 굉장히 골때리는 제자 원리이다. 이건 글자를 생성하는 거지, 말을 생성하는 게 아니다.
(저 형성도 formation 形成이 아니라 形聲인 것쯤은 이과 출신인 나도 알고 있음)
이미 만들어지고 익숙해져 버린 명칭들은 어쩔 수 없지만, 최소한 더는 이런 식으로 조어를 하지 말고 청각 변별이 되고 잘 와닿는 쪽으로 말을 만들 생각, 시늉이라도 해야 한다.

중국어에는 성조라는 게 있어서 한국어보다는 한자 변별이 되는 편이다. 중세 땐 우리나라(조선??)조차 한자를 좀더 중국식으로 발음하려고 성조를 도입했던 것 같으나, 지금은 몽땅 사라졌다.
그런데 이 성조라는 게 노래를 부를 때는 전혀 표현될 수 없다. 한자의 발음들은 전부 문맥만으로 분별돼야 하며 의미가 잘못 전달될 수도 있다. 그렇기 때문에 내가 알기로 중국은 자기네 가요 뮤직비디오에 자막을 반드시 넣어 줘야 된다.

일본은..? 한자를 청각적으로 최대한 변별하려다 보니 읽는 방식이 너무 다양하고 복잡해져서 한자 위에 히라가나 토가 널리 쓰인다. 특히 이름 같은 생소한 고유명사의 한자는 이렇게 안 해 주면 거의 못 읽는다.
나는 이런 게 정상적인, 자연스러운 문자 생활이 "아니라고" 생각한다. 한 20년쯤 전부터 했던 생각이고 지금도 변함없다.

3. 결론: 국어 교육의 문제와 한글 전용의 문제를 서로 헷갈리지 말자

(1) 문자의 본질: 문자라는 건 말을 받아적는 도구 이상도 이하도 아니며, 그림보다는 추상적인 '숫자'에 더 가까운 면모를 지니는 게 바람직하다.
한자가 일단 익숙해지고 나면 함축적이고 시각성이 뛰어난 구석이 있는 것은 사실이다. 그러나 '읽기'의 장점을 위해서 치르는 '말하기/듣기'와 '쓰기'의 대가, 단점을 결코 만만하게 봐서는 안 된다!

(2) 한국어의 실정: 한국어는 중국어· 일본어와 달리 장단이고 성조고 훈독이고 뭐고 없다시피하며, 한자들을 정말 단순무식하게 한글 1음절로만 연결시켜 놓았다. 거기에다 한글이라는 문자도 자체적인 구조가 꽤 탄탄하며, 히라가나 카타카나 같은 한자 혼용을 전제로 한 보조용 문자가 아니다.
그러니 동음이의어 정리만 좀 해 주면 한글 전용을 하기에 매우 유리한 면모를 갖췄으며, 오늘날 실제로 그렇게 됐다.

(3) 문자 정책: 한글 전용을 전제로 하고, 마치 생소한 신조어를 드러내기 위해서 영어에서 하이픈이나 일부 음절 대문자화를 하듯이 가끔 괄호 안에 한자 병용만 하는 것으로 족하다.
개인적으로 일본식 한자어를 반대하는 소신은 아니다. 하지만 표기까지 몽땅 한자를 밝혀야 할 정도로 중구난방으로 쓰는 것은 반대다. 민족 감정 때문이 아니라 언어학적, 실용적인 측면에서만 접근한다.

(4) 교육: 뭐든지 도둑질만 아니면 많이 공부하고 배워서 나쁠 건 없고 그건 한자도 예외가 아니다. 그러나 겨우 말을 담는 껍데기 그릇을 공부하는 것 하나가 이렇게 어렵고 사용하기가 불편하고 시간이 많이 걸리는 것은 큰 문제이다. 한자는 한자어의 어원을 변별하고 의미를 정확하게 학습하는 용도로 쓰기가 아닌 '읽기' 위주로만 가르치면 된다.
국어 교육 문제를 한글 전용 문제로 돌릴 필요는 없다. 국어 교육을 똑바로 안 시키고 표기만 한자 병용을 하면? 한글 대신 헷갈려서 잘못 쓰인 한자들만 글에 가득해질 것이다.

그리고 덧붙이자면.. 한글 전용을 지지하는 사람일수록 한글 맞춤법과 띄어쓰기를 더욱 잘 지켜서 글을 써야 한다. 그게 한글의 표의성과 시각성을 살려 주는 규칙이기 때문이다.

4. 여담

(1) 성경조차 히브리건 그리스건 알파벳이건 소리만 받아적는 간결한 소리글자로 기록됐지, 뜻글자가 쓰이지 않았다.
또한, 세상에서 제일 높은 최고존엄에 대해 다루고 있는 텍스트이지만 한국어 같은 복잡한 높임법 따위 존재하지 않고 하나님도 you라고 바로 가리키는 언어로 기록됐다. 예수냐 예수님이냐 이런 게 본질적인 문제가 아니리는 것이다.

(2) 우리나라의 경우는 과거에 일제가 총칼로 한국어 한글을 말살하면서 일본어를 강요했으니 그건 극심한 저항과 반발에 부딪혔다.
그런데 그렇지 않고, 영국 미국 같은 나라가 한국을 식민지로 삼고,

  • 한국어 대신 영어를 쓰면.. X나 골치아픈 호칭, 높임법 신경쓸 필요 없이 누구나 이름으로 부르고 you로 바로 가리킬 수 있어요~!!
  • 어려운 한자로부터 해방될 수 있어요~!
  • 세계의 석학들, 최신 지식 정보와 바로 소통할 수 있어요~!
  • 미개한 붓이 아니라 타자기로 아주 빠르고 편하게 글을 쓸 수도 있어요~!

이렇게 당근만 흔들면서 접근했으면.. 당시 지식인들이 어떻게 반응했을지, 한국어와 한글의 운명이 어찌 됐을지 나는 장담을 못 하겠다. 이런 여건에서도 공 병우 같은 천재가 한글 타자기를 발명할 수 있었을까?
물론 저런 실용주의적인 사고방식 자체가 전후에 20세기 말이 돼서야 슬슬 등장했으니 이건 가정이 현실적이지 않은 뇌피셜일 뿐이다.

Posted by 사무엘

2021/02/14 08:37 2021/02/14 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1854

C/C++은 성능을 위해 컴파일러나 언어 런타임이 프로그래머의 편의를 위해 뭔가를 몰래 해 주는 것을 극도로 최소화한 언어이다. 꾸밈 없고 정제되지 않은 '날것 상태 raw state'에다가 고급 프로그래밍 언어의 패러다임과 문법만을 얹은 걸 추구하다 보니, '초기화되지 않은 쓰레기값'이라는 게 존재하는 거의 유일한 언어이기도 하다.

같은 프로그램이라도 이제 막 선언된 변수나 할당된 메모리 안에 무슨 값이 들어있을지는 컴퓨터 운영체제의 상태에 따라서 그때 그때 달라진다. 반드시 0일 거라는 보장은 전혀 없다. 오히려 0 초기화는 별도의 CPU 부담이 필요한 인위적인 작업이다. global/static에 속하는 메모리만이 무조건적인 0 초기화가 보장된다.

그렇다고 쓰레기값이라는 게 완벽하게 예측 불가이면서 통계적인 질서를 갖춘 난수인 것도 물론 아니다.
그리고 Visual C++에서 프로그램을 debug 세팅으로 빌드하면 쓰레기값이라는 게 크게 달라진다. C++ 개발자라면 이 사실을 이미 경험적으로 충분히 알고 있을 것이다.

1. 갓 할당된 메모리의 기본 쓰레기값: 0xCC(스택)와 0xCD(힙)

가장 먼저, 스택에 저장되는 지역변수들은 자신을 구성하는 바이트들이 0xCC로 초기화된다. 다시 말해 디버그 빌드에서는 int x,y라고만 쓴 변수는 int x=0xCCCCCCCC, y=0xCCCCCCCC와 얼추 같게 처리된다는 것이다. 디스어셈블리를 보면 의도적으로 0xCC를 대입하는 인스트럭션이 삽입돼 들어간다.

0은 너무 인위적이고 유의미하고 깔끔한(?) 값 그 자체이고, 그 근처에 있는 1, 2나 0xFF도 자주 쓰이는 편이다. 그에 비해 0xCC는 형태가 단순하면서도 현실에서 일부러 쓰일 확률이 매우 낮은 값이다. 그렇기 때문에 여기는 초기화되지 않은 쓰레기 영역이라는 것을 시각적으로 곧장 드러내 준다.

int a[10], x; a[x]=100; 같은 문장도 x가 0으로 깔끔하게 자동 초기화됐다면 그냥 넘어가지만, 기괴한 쓰레기값이라면 곧장 에러를 발생시킬 것이다.
또한, 복잡한 클래스의 생성자에서 값이 대입되어 초기화된 멤버와 그렇지 않은 멤버가 뒤섞여 있을 때, 0xCC 같은 magic number는 탁월한 변별력을 발휘한다.

타겟이 align을 꼼꼼하게 따지는 아키텍처라면, 쓰레기값을 0x99나 0xDD 같은 홀수로 지정하는 것만으로도 초기화되지 않은 포인터 실수를 잡아낼 수 있다. 32비트에서 포인터값의 최상위 비트가 커널/사용자 영역을 분간한다면, 최하위 비트는 align 단위를 분간할 테니 말이다. 뭐 0xCC는 짝수이다만..

0xCC라는 바이트는 x86 플랫폼에서는 int 3, 즉 breakpoint를 걸어서 디버기의 실행을 중단시키는 명령을 나타내기도 한다. 그래서 이 값은 실행 파일의 기계어 코드에서 align을 맞추기 위해 공간만 차지하는 잉여 padding 용도로 위해 듬성듬성 들어가기도 한다.
Visual C++ 6 시절엔 거기에 말 그대로 아무 일도 안 하는 nop를 나타내는 0x90이 쓰였지만 2000년대부터는 디버깅의 관점에서 좀 더 유의미한 작용을 하는 0xCC로 바뀐 듯하다. 정상적인 상황이라면 컴퓨터가 이 구역의 명령을 실행할 일이 없어야 할 테니까..

다만, 힙도 아니고 스택 지역변수의 내용이 데이터가 아닌 코드로 인식되어 실행될 일이란 현실에서 전혀에 가깝게 없을 테니, 0xCC는 딱히 x86 기계어 코드를 의식해서 정해진 값은 아닐 것으로 보인다.

Visual C++의 경우, 스택 말고 malloc이나 new로 할당하는 힙(동적) 메모리는 디버그 버전에서는 내용 전체를 0xCD로 채워서 준다. 0xCC보다 딱 1 더 크다. 아하~! 이 값도 평소에 디버그 하면서 많이 보신 적이 있을 것이다.
힙의 관리는 컴파일러 내장이 아니라 CRT 라이브러리의 관할로 넘어기도 하니, 0xCD라는 값은 라이브러리의 소스인 dbgheap.c에서도 _bCleanLandFill이라는 상수명으로 확인할 수 있다.

2. 초기화되지 않은 스택 메모리의 사용 감지

C/C++ 언어는 지역변수의 값 초기화를 필수가 아닌 선택으로 남겨 놓았다. 그러니 해당 언어의 컴파일러 및 개발툴에서는 프로그래머가 초기화되지 않은 변수값을 사용하는 것을 방지하기 위해, 디버그용 빌드 한정으로라도 여러 안전장치들을 마련해 놓았다.
그걸 방지하지 않고 '방치'하면 같은 프로그램의 실행 결과가 debug/release별로 달라지는 것을 포함해 온갖 골치아픈 문제들이 발생해서 프로그래머를 괴롭히게 되기 때문이다.

int x; printf("%d", x);

이런 무식한 짓을 대놓고 하면 30년 전의 도스용 Turbo C에서도 컴파일러가 경고를 띄워 줬다. Visual C++의 에러 코드는 C4700. 그랬는데 한 Visual C++ 2010쯤부터는 이게 경고가 아니라 에러로 바뀌었다.
그리고 그 뿐만이 아니다.

int x;
if( some_condition_met(...)) x=0;
printf("%d", x);

이렇게 문장을 약간만 꼬아 놓으면 초기화를 전혀 안 하는 건 아니기 때문에 컴파일 과정에서의 C4700을 회피할 수 있다. 하지만 보다시피 if문의 조건이 충족되지 않으면 x가 여전히 초기화되지 않은 채 쓰일 수 있다. 이건 정적 분석 정도는 돌려야 감지 가능하다.
(그런데, 글쎄.. 함수의 리턴이 저런 식으로 조건부로 불완전하게 돼 있으면 컴파일만으로도 C4715 not all control paths return value 경고가 뜰 텐데.. 비초기화 변수 접근 체크는 그 정도로 꼼꼼하지 않은가 보다.)

Visual C++은 /RTC라고 디버그용 빌드에다가 run-time check라는 간단한 검사 기능을 추가하는 옵션을 제공한다. 함수 실행이 끝날 때 스택 프레임 주변을 점검해서 버퍼 오버런을 감지하는 /RTCs, 그리고 지역변수를 초기화하지 않고 사용한 것을 감지하는 /RTCu.

사용자 삽입 이미지

저 코드를 Visual C++에서 디버그 모드로 빌드해서 실행해서 if문이 충족되지 않으면 run-time check failure가 발생해서 프로그램이 정지한다. 다만, 이 메모리는 초기화만 되지 않았을 뿐 접근에 법적으로 아무 문제가 없는 스택 메모리이다. 할당되지 않은 메모리에 접근해서 access violation이 난 게 아니다. 심각한 시스템/물리적인 오류가 아니라 그저 의미· 논리적인 오류이며, 쓰기를 먼저 하지 않은 메모리에다가 읽기를 시도한 게 문제일 뿐이다.

그러니 이 버그는 해당 메모리 자체에다가 시스템 차원의 특수한 표식을 해서 잡아낸 게 아니며, 논리적으로 매우 허술하다. (0xCC이기만 하면 무조건 스톱.. 이럴 수도 없는 노릇이고!)
문제의 코드에 대한 디스어셈블리를 보면 if문이 만족되지 않으면 printf으로 가지 않고 그냥 곧장 RTC failure 핸들러를 실행하게 돼 있다.

void do_nothing(int& x) {}

int x; do_nothing(x); printf("%d", x);

그렇기 때문에 요렇게만 해 줘도 RTC를 회피하고 x의 쓰레기값을 얻는 게 가능하다. 글쎄, 정교한 정적 분석은 이것도 지적해 줄 수 있겠지만, 포인터가 등장하는 순간부터 메모리 난이도와 복잡도는 그냥 하늘로 치솟는다고 봐야 할 것이다.

하물며 처음부터 포인터로만 접근하는 힙 메모리는 RTC고 뭐고 아무 안전 장치가 없다. int *p에다가 new건 malloc이건 값이 하나 들어간 것만으로도 초기화가 된 것이거늘, 그 주소가 가리키는 p[0], p[1] 따위에 쓰레기값(0xCD)이 있건 0이 있건 알 게 무엇이겠는가????

나도 지금까지 혼동하고 있었는데, 이런 run-time check failure는 run-time error와는 다른 개념이다. 순수 가상 함수 호출 같은 건 C/C++에 존재하는 얼마 안 되는 run-time error의 일종이고 release 빌드에도 포함돼 들어간다. 하지만 RTC는 debug 빌드 전용 검사이다.

그러니 버퍼 오버런을 감지하는 보안 옵션이 /RTC만으로는 충분하지 않고 /GS가 따로 있는 것이지 싶다. /GS는 release 빌드에도 포함돼 있으며, 마소에서는 보안을 위해 모든 프로그램들이 이 옵션을 사용하여 빌드할 것을 권하고 있다.

3. 해제된 힙 메모리: 0xDD(CRT)와 0xFEEE(???)

일반적인 프로그래머라면 동적으로 할당받은 힙 메모리를 free로 해제했을 때, 거기를 가리키는 메모리 영역이 실제로 어떻게 바뀌는지에 대해 생각을 별로 하지 않는다. 사실, 할 필요가 없는 게 정상이기도 하다.
우리 프로그램은 free를 해 준 주소는 신속하게 영원히 잊어버리고, 그 주소를 보관하던 포인터는 NULL로 바꿔 버리기만 하면 된다. free 해 버린 주소를 또 엿보다가는 곧바로 메모리 에러라는 천벌을 받게 될 것이다.

그런데 실제로는, 특히 디버그 모드로 빌드 후 프로그램을 디버깅 중일 때는 free를 한 뒤에도 해당 메모리 주소가 가리키는 값을 여전히 들여다볼 수 있다. 들여다볼 수 있다는 말은 *ptr을 했을 때 access violation이 발생하지 않고 값이 나온다는 것을 의미한다.
이 공간은 나중에 새로운 메모리 할당을 위해 재사용될 수야 있다. 하지만 사용자가 디버깅의 편의를 위해 원한다면 옵션을 바꿔서 재사용되지 않게 할 수도 있다. (_CrtSetDbgFlag(_CRTDBG_DELAY_FREE_MEM_DF) 호출)

뭐, 메모리를 당장 해제하지 않는다고 해서 free 하기 전의 메모리의 원래 값까지 그대로 남아 있지는 않는다. Visual C++의 디버그용 free/delete 함수는 그 메모리 블록의 값을 일부러 0xDD (_bDeadLandFill)로 몽땅 채워 넣는다. 여기는 할당되었다가 해제된 영역임을 이런 식으로 알린다는 것이다.

실제로, free된 메모리가 곧장 흔적도 없이 사라져서 애초에 존재하지도 않았던 것처럼 접근 불가 ?? 로 표시되는 것보다는 0xDD라고 디버거의 메모리 창에 뜨는 게 dangling pointer 디버깅에 약간이나마 더 도움이 될 것이다. 이 포인터가 처음부터 그냥 쓰레기값을 가리키고 있었는지, 아니면 원래는 valid하다가 지칭 대상이 해제되어 버린 것인지를 분간할 수 있으니 말이다.

그런데 본인은 여기서 개인적으로 의문이 들었다.
본인은 지난 20여 년에 달하는 Visual C++ 프로그래밍과 메모리 문제 디버깅 경험을 떠올려 봐도.. 갓 할당된 쓰레기값인 0xCC와 0xCD에 비해, 0xDD를 본 적은 전혀 없는 건 아니지만 매우 드물었다.

dangling pointer가 가리키는 메모리의 값은 0xD?보다는 0xF?였던 적이 훨씬 더 많았다. 더 구체적으로는 2바이트 간격으로 0xFEEE (0xEE, 0xFE)이다.

사용자 삽입 이미지

인터넷 검색을 해 보니.. 이건 놀랍게도 CRT 라이브러리가 채워 넣는 값이 아니었다. free/delete가 궁극적으로 호출하는 Windows API 함수인 HeapFree가 메모리를 정리하면서 영역을 저렇게 바꿔 놓았었다. 더구나 CRT에서 0xDD로 먼저 채워 넣었던 영역을 또 덮어쓴 것이다.
이 동작에 대해서 놀라운 점은 저게 전부가 아니다.

(1) 0xFEEE 채우기는 프로그램을 Visual C++ 디버거를 붙여서(F5) 실행했을 때만 발생한다. debug 빌드라도 디버거를 붙이지 않고 그냥 Ctrl+F5로 실행하면 0xFEEE가 생기지 않는다. 그리고 release 빌드라도 디버거를 붙여서 실행하면 0xFEEE를 볼 수 있다.

(2) 더 놀라운 점은.. 내가 집과 직장 컴퓨터를 통틀어서 확인한 바로는 저 현상을 볼 수 있는 건 Visual C++ 2013 정도까지이다. 2015부터는 debug 빌드를 디버거로 붙여서 돌리더라도 0xFEEE 채움이 발생하지 않고 곧이곧대로 0xDD만 나타난다~!

운영체제가 정확하게 어떤 조건 하에서 0xFEEE를 채워 주는지 모르겠다. 인터넷 검색을 해 봐도 정확한 정보가 나오는 게 의외로 없다.
하필 Visual C++ 2015부터 저런다는 것은 CRT 라이브러리가 Universal CRT니 VCRuntime이니 하면서 구조가 크게 개편된 것과 관계가 있지 않으려나 막연히 추측만 해 볼 뿐이다.

여담이지만 HeapAlloc, GlobalAlloc, LocalAlloc은 연달아 호출했을 때 돌아오는 주소의 영역이 그리 큰 차이가 나지 않으며, 내부 동작 방식이 모두 비슷해진 것 같다. 물론 뒤의 global/local은 fixed 메모리 할당 기준으로 말이다.

4. 힙 메모리 영역 경계 표시용: 0xFD와 0xBD

0xCD, 0xDD, (0xFEEE) 말고 heap 메모리 주변에서 볼 수 있는 디버그 빌드용 magic number 바이트로는 0xFD _bNoMansLandFill와 0xBD _bAlignLandFill가 더 있다.

얘들은 사용자가 요청한 메모리.. 즉, 0xCD로 채워지는 그 메모리의 앞과 뒤에 추가로 고정된 크기만큼 채워진다. Visual C++ CRT 소스를 보면 크기가 NoMansLandSize인데, 값은 4바이트이다. 사용자가 요청한 메모리 크기에 비례해서 채워지는 0xCD와 0xDD에 비하면 노출 빈도가 아주 작은 셈이다. 특히 0xBD는 0xFD보다도 더욱 듣보잡인 듯..

애초에 얘는 사용자가 건드릴 수 있거나 건드렸던 공간이 아니며 그 반대이다. 사용자는 0xCD로 채워진 공간에다가만 값을 집어넣어야지, 앞뒤  경계를 나타내는 0xFD를 건드려서는 안 된다.
CRT 라이브러리의 디버그용 free/delete 함수는.. 힙을 해제할 때 이 0xFD로 표시해 놨던 영역이 값이 바뀌어 있으면 곧장 에러를 출력하게 돼 있다.

그리고 예전에 메모리를 해제해서 몽땅 0xDD로 채워 놨던 영역도 변조된 게 감지되면 _CrtCheckMemory 같은 디버깅 함수에서 곧장 에러를 찍어 준다. 그러니 0xDD, 0xFD, 0xBD는 모두 오류 검출이라는 용도가 있는 셈이다. 0xCC와 0xCD 같은 쓰레기값 영역은 쓰지도 않고 곧장 읽어들이는 게 문제이지만, 나머지 magic number들은 건드리는 것 자체가 문제이다.

그리고 얘들은 heap 메모리를 대상으로 행해지는 점검 작업이다. 이런 것 말고 스택 프레임에다가 특정 magic number를 둬서 지역변수 배열의 overflow나 복귀 주소 변조를 감지하는 것은 별도의 컴파일러 옵션을 통해 지원되는 기능이다. 요것들은 힙 디버그 기능과는 별개이며, 보안 강화를 위해 release 빌드에도 포함되는 게 요즘 추세이다.

이상이다.
파일 포맷 식별자 말고 메모리에도 디버깅을 수월하게 하기 위해 쓰레기값을 가장한 이런 특수한 magic number들이 쓰인다는 게 흥미롭다. Windows의 Visual C++ 외의 다른 개발 환경에서는 디버깅을 위해 어떤 convention이 존재하는지 궁금해진다.

사실, 16진수 표기용인 A~F에도 모음이 2개나 포함돼 있고 생각보다 다양한 영단어를 표현할 수 있다. 거기에다 0을 편의상 O로 전용하면 모음이 3개나 되며, DEAD, FOOD, BAD, FADE, C0DE 정도는 거뜬히 만들어 낸다. 거기에다 FEE, FACE, FEED, BEEF 같은 단어도.. 유의미한 magic number나 signature를 고안하는 창의력을 발산하는 데 쓰일 수 있다.
그러고 보니 아까 0xFEEE도 원래 free를 의도했는데 16진수 digit에 R은 없다 보니 불가피하게 0xFEEE로 대충 때운 건지 모르겠다.

Posted by 사무엘

2021/02/11 08:36 2021/02/11 08:36
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1853

반비례 함수가 쌍곡선인 이유

두 초점 A, B가 있을 때 A에서의 거리와 B에서의 거리의 차가 동일한 점들의 집합을 쌍곡선이라고 한다. x^2 - y^2 = a 이런 음함수로 정의되며, 그래프를 그려 보면 곡선이 둘 그어지는 것이 특징이다.
그 반면, 합이 동일한 점들의 집합은 잘 알다시피 타원이며, x^2 + y^2 = a 꼴로 정의된다.

그런데 y=a/x, 다시 말해 xy = a 꼴인 반비례 함수는 x^2나 y^2처럼 단일 변수의 제곱이 존재하지 않는다. 하지만 우리는 이게 이차곡선인 쌍곡선의 표준형을 45도 돌린 형태라고 얼추 알고 있다.
어째서 그런 것일까? 수학적으로 더 엄밀히 증명해 볼 수는 없을까?
반비례 함수를 회전 행렬을 이용해서 45도 돌린 뒤, 이 함수가 쌍곡선 표준형과 동치임을 보이면 될 것이다.

45도일 때는 cos와 sin의 값이 sqrt(2)/2로 동일하다. 그렇기 때문에 (x, y)라는 점은 45도 회전하고 나면

사용자 삽입 이미지

요렇게 된다. 그럼 다음으로 45도 돌아간 x', y'를 기반으로 우리의 목표인 쌍곡선 방정식을 재구성하면 된다.
그러면 기존의 x, y 변수를 없애야 하는데, 위의 식을 그대로 제곱해서 빼기만 해도 x'^2 - y'^2 = -2xy로 놀랍게도 x^2와 y^2이 소거되어 없어진다. 이는 앞서 살펴보았듯이 각도가 45도여서 cos와 sin의 함수값이 서로 동일한 덕분에 가능한 일이다.

마지막으로 남은 xy야 원래 반비례 그래프의 정의상 a로 치환하면 되니 금방 처리된다.
그러면 x'^2 - y'^2 = -2a가 되고 쌍곡선과 동일함이 입증된다. 뭔가 허무해 보이지만.. 이차곡선 중에서 x나 y의 제곱이 없는 식은 이렇게 쌍곡선으로 귀결된다.
45도가 아닌 다른 각도라면 기존 x, y가 이렇게 쉽게 소거되지 않기 때문에 문제가 이런 식으로 단순하게 풀리지 않게 된다.

가만히 생각해 보니, 애초에 Ax^2 + Bxy + Cy^2 + Dx+Ey+F = 0에 대해서 그래프의 모양을 결정하는 판별식도 있다. A,B,C 중 적어도 하나 이상은 0이 아닐 때, B^2 - 4AC가 0이면 이 그래프는 포물선이요, 음수이면 타원 또는 원, 양수이면 쌍곡선이 된다. 구체적인 유도 과정은 쉽지 않을 텐데.. 이거 정도면 중등 교육과정 범위에 있다.
그러니 xy=1이야 B만 비영이고 A, C는 0.. 판별식 값은 당연히 양수가 되고 쌍곡선으로 귀결된다. 오오~~

판별식의 형태가 1계수 이차방정식의 근 판별식과도 매우 유사하다. 이차방정식의 경우 A만 비영이라는 조건이지만, 이차곡선 내지 원뿔곡선 방정식의 판별식은 아까 상술하였듯이 A,B,C 중 아무거나 하나 이상만 비영이면 된다.

그리고 A부터 F까지 아무 숫자나 집어넣는다고 해서 원뿔곡선이 튀어나오는 게 아니다. 상수항이 0이거나 하면 원이 극도로 작아져서 그냥 점이 되기도 하며, 쌍곡선은 점근선을 나타내는 직선 두 개로 귀착된다. 당장 xy=0만 해도 x축과 y축을 동시에 나타나내는 직선이 되니까.. 그럼 다음으로 포물선은..? 평행한 두 직선이 돼 버린다.
이차방정식이 x^2+1 = 0 같은 경우 실수 근이 존재하지 않는 것처럼.. 이것의 이변수 상위 호환인 원뿔곡선 방정식도 실수 범위에서 공집합이 될 수도 있다.

이 개념을 degeneracy(축퇴.. 축 쪽으로 퇴화)라고 부른다. 뭔가 행렬에서 행렬식의 값이 0이 돼 버리는 상황 같은 느낌이 들지 않는가? 계수가 주어졌을 때 축퇴 여부를 판별하는 판별식도 있다. 이건

(b^2-4ac)f + ae^2 - bde + cd^2

으로, 곡선 종류 판별식을 포함하면서 다소 복잡한 편이다. 이걸 유도하는 건 확실하게 중등 이상의 더 어려운 영역이며, 더 추상적인 수학 개념이 동원된다. 딱 봤을 때 각 항들에 변수가 2개가 아니라 3개씩 곱해진 것부터가 매우 인상적이다.

쌍곡선에서 시작해서 이차곡선에 대한 더 원론적인 얘기로 주제가 옆길로 좀 샜는데.. 다시 쌍곡선 얘기를 하며 글을 맺겠다.
반비례 그래프는 xy=a, 즉 x의 역수를 구하는 함수인지라 y=-x의 그래프에 대칭인 쌍곡선이 튀어나온다. e^x가 도함수가 자신과 동일한 함수라면, a/x는 역함수가 자신과 동일한 함수이다. f(f(x)) = x가 성립하는 게 어찌 보면 not이나 xor 연산 같아 보이기도 하다..

원의 방정식이 그 정의상 (cos(t), sin(t))라는 매개변수로 표현될 수 있는 것처럼 쌍곡선의 방정식은 (cosh(t), sinh(t))라는 매개변수로 표현될 수 있다. cosh와 sinh의 배치가 바뀌면 쌍곡선의 위치가 상하 또는 좌우로 바뀐다.

그리고 원의 방정식이 y=sqrt(a-x^2) 같은 꼴로 양함수로 표현될 수 있는 것처럼 쌍곡선의 방정식은 y=sqrt(x^2+a)의 꼴로 표현될 수 있다. a의 부호가 무엇이냐에 따라 쌍곡선의 배치(상하 또는 좌우)가 바뀐다. 한편으로 저 모양만 봐도 x의 값이 너무 작거나 커지면 y=x에 가까워질 소지가 다분해 보임을 알 수 있다.

Posted by 사무엘

2021/02/09 08:37 2021/02/09 08:37
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1852

서울 지하철의 건설과 개통 내력

서울 지하철의 건설 형태는
"1 / 2 / 3,4 / 5,6,7,8 / 9 (,10,11,12)"호선.. 이렇게 나뉘었다고 생각하면 된다.

1.
1960년대 말, 서울시의 높으신 분들은 이렇게 서울시가 팽창하고 인구가 증가하다가는 시내의 교통은 체증 때문에 완전히 끝장이 날 것이라고 우려했다. 그래서 선택한 돌파구는 지하철.. 우리도 외국의 대도시들처럼 땅 아래로 길을 파서 지하철을 건설해야겠다는 결론을 내렸다.

그때까지 서울 시내에는 노면전차라는 게 있었다. 하지만 경영 수지가 안 좋아 적자가 쌓여 가고, 차량과 시설의 노후화도 심한 노답 상태였다. 얘는 지하철 건설을 위한 시범타로 완전히 폐선· 퇴출되었다.
전차가 없어진 종로 도로를 파헤쳐서 몇 년 동안 극심한 버스 혼잡과 교통 체증을 감내한 끝에, 서울 최초의 지하철 1호선은 철도청 광역전철 경인(인천)/경부(수원)/경원선(성북)과 직결된 독특한 형태로 건설되고 개통됐다. 차량 운행을 철도청(현 코레일)과 서울 지하철 공사(서울 교통 공사)라는 두 주체가 공동으로 하기 시작했다.

차량은 그 당시 유행이던 중문 달린 식빵 모양 '초저항'(초기 저항 제어 방식 전동차) 차량을 일본으로부터 수입해 와서 굴렸다. 철도청은 차량에 파란 도색을, 서지공은 빨간 도색을 사용했다.

사용자 삽입 이미지

얘는 일본의 신칸센 0계 전동차만큼이나 우리나라 철도 역사의 상징인 매우 귀중한 차량이다. 그렇기 때문에 코레일과 서교공 모두 자기네 초저항 차량을 내구연한 경과로 인해 퇴역한 뒤에도 한 량씩 자기 방식으로 도색해서 정태보존 중이다. (각각 철도 박물관, 신정 차량기지 내부)

저런 식빵 모양의 디자인은 비슷한 시기에 일본 현지에서 다닌 도쿄 지하철 5000계 전동차에도 그대로 남아 있다. 단지, 차폭은 일본 내수인 1067 협궤가 아니라 1435 표준궤로 커진 것이다. 이 때문에 한국의 초저항 전동차는 일본의 철덕들에게도 관심을 받고 있다.

사용자 삽입 이미지

초저항 전동차의 주요 특징 중 하나는 바로 전방 중앙에 출입문이 있다는 것이다. 필요한 경우, 전동차를 그대로 중련 편성해서 기관사가 아니라 승객이 객차 사이를 지나다닐 수 있게 하려는 의도였다!

지하철 1호선이 첫 개통한 날엔 대통령까지 참석하는 성대한 개통식을 치를 예정이었지만.. 하필 개통식 당일의 이전 행사에서 영부인 육 영수 여사가 괴한에게 피격 당하는 바람에 지하철 개통식은 대통령 없이 아주 우울하고 어수선한 분위기에서 치러지게 됐다. 그리고 서울 시장도 경질되고(양 택식 → 구 자춘) 향후의 지하철 건설 계획까지 확 바뀌게 됐다.

2.
서울 지하철 2호선은 1980년부터 84년까지 점진적으로 개통하면서 거대한 순환선으로 만들어졌다. 이때 굉장히 큰 변화가 생겼다.

  • 고유 노선색 패턴 (2호선은 초록색)
  • 저항 제어보다 조금 더 발전한 초퍼 제어 방식 전동차 (MELCO). 국영 공작창이 아닌 민간 기업 중심으로 차량 생산 시작
  • 매큔-라이샤워 로마자 표기법
  • 노인 무임승차(!!!)
  • 지금과 같은 지하철체
  • 최초의 우측통행 (조금 뻘짓 같지만), 최초의 지하철간 환승역 (신설동)
  • 8량 증결 (처음엔 6량 1편성이었음.. 역들의 건설만 10량 기준으로 해 놓고)

이 정도면 서울 지하철의 실질적인 기틀은 2호선 때 완전히 잡혔다고 봐도 되겠다.
용답 역 근처에 있는 군자 차량기지는 서울에서 중심부에 가장 가까이 있는 지하철 차량기지이다. 그러면서도 창동이나 구로 기지와 달리 이전 계획도 없고, 오히려 여기 주변에 서울 교통 공사 본사와 종합 관제센터까지 들어서 있다.

아, 그리고 1호선이 지상 광역전철과 직통 운행하는 지하철을 선보였다면, 2호선은 유의미한 구간을 계속해서 지상 고가로 달리는 지하철? 도시철도?를 최초로 선보였다. 타 노선들은 한강을 건널 때 내지 외곽 종점 차량기지에 다 왔을 때에만 잠시 지상에 나온다는 점을 생각해 보면, 강변-뚝섬이라든가 신대방-대림 지상 구간은 서울 시내에서 보기 드문 형태이다.

3-4.
3호선과 4호선은..

  • 최초로 Y자형 분기(1호선)나 O자형 순환(2호선)이 아닌, 단순한 I자 선형..;;
  • 서울 올림픽에 대비하여 자금의 압박에도 불구하고 최초로 두 노선이 동시에 건설· 개통되어 서울 중심부를 X자로 관통했다. 충무로 역은 최초로 2개 노선이 동시에 건설된 환승역이다.
  • 일본물이 아닌 유럽물을 먹은 광폭형 GEC 초퍼 전동차가 이때 도입돼 들어왔다.
  • 올림픽을 염두에 둬서 그런지 인테리어를 1· 2호선보다 더 신경쓴 역들이 제법 등장했다. 경복궁, 교대, 동대문운동장처럼..
  • 신호 시스템이 ATS보다 더 정교하고 발전된 ATC로 바뀌었다.
  • 얘들이 등장한 시기부터 전동차들이 드디어 10량으로 증결됐다.
  • 얘들은 일산, 분당, 과천 이렇게 새로 건설된 광역전철들과 직통 운행을 시작했다.

참고로 80년대 중반 올림픽 준비의 산물들로 다른 분야로는: 올림픽대로, 현대 그랜저, 유선형 새마을호 열차가 있다.
지금으로서는 상상이 안 되지만 과거에는 2호선에도 1호선의 초저항 전동차, 또는 3-4호선의 GEC 초퍼 전동차가 잠시 다닌 적이 있다. 그 반면, 2호선의 MELCO 초퍼는 2호선 외의 타 노선을 다닌 적이 없다.

5-8.
이제 1990년대에 서울 2기 지하철 노선 4개가 한꺼번에 계획되고 건설됐다. 세부적으로는 이것도 95~96년 사이(5호선 전체, 7호선 강북 구간, 8호선 남쪽 구간)와 99~01년 사이(6호선 전체, 7· 8호선 나머지 구간)의 두 타이밍으로 나뉜다만..
얘는 지난 15년간의 지하철 건설 노하우를 바탕으로 다음과 같은 변화가 생겼다.

  • 1기 시절보다는 환승거리를 최대한 줄이는 쪽으로 역들이 만들어졌으며, 심지어 더 미래에 건설할 3기 지하철까지 염두에 두고 환승 통로와 노반을 미리 만들어 놓았다! (5-9 여의도역처럼)
  • 전동차 외형의 표준화
  • 자갈 대신 콘크리트 노반
  • 재래식 삼발이 대신 깔끔한 개집표기, 무려 하저터널,
  • 롤지 대신 LED 전광판
  • 저항/초퍼보다 더 발전된 VVVF 제어: 자동차 내연기관으로 치면 가변 밸브 개폐량/개방 시간(VVL/VVT) 같은 기술을 떠올리면 되겠다.
  • ATS/ATC보다 더 발전된 ATO 신호 시스템. 차장을 생략한 1인 승무

이렇게 1기 지하철에 비해 정말 정말 많은 부분이 발전했다.
이때는 차량 외형은 다들 비슷해졌지만, 내부의 VVVF 인버터는 제대로 국산화되지 않았기 때문에 제조사별로 ABB, 미쓰비시, GEC 등 갖가지 개성 넘치는 전자악기 소리를 가속 구동음으로 들을 수 있었다. 이게 1990년대의 로망이다. 2기는 1기와 달리, 시각 대신 청각적으로 즐길 것이 다양해진 셈이다.

사용자 삽입 이미지

지하철 건설이란 게 워낙 재정 등골 브레이커이다 보니 2기 지하철을 만들 때는 어떻게든 원가를 줄이려는 노력을 높으신 분들이 했는데, 그 아이디어 중 하나가 2기 지하철부터는 아예 무인 운전을 시키는 것이었다.

하지만 테스트를 해 보니 자동 운전 시스템이 승강장 제 위치에 정차를 정확히 못 했다. 또한 이때는 아직 스크린도어도 없어서 완전 무인 운전을 하기엔 여러 애로사항들이 즐비했다. 이 때문에 현실에서는 2인 승무에서 차장만 뺀 1인 승무로 줄이는 수준에서 머물렀다.

서울 지하철 5호선의 최초 개통 구간이 왕십리-상일동이었으며, 천호대로 구간이 이때 파헤쳐졌다가 복구되면서 국내 최초의 시내 중앙 버스 전용 차로로 탈바꿈한 것은 유명한 일화이다.
응답하라 1997에서 나름 고증을 반영한답시고 지하철 노선도에서 5~8호선은 하얗게 지워 놨던데 그건 오류이다.
그 시절엔 5~8호선도 점선으로 그려 놓고 "건설 중, 개통 예정"이라고 표시해 놓는 게 올바른 고증이다. -_-;;

처음에는 5~8호선만 운영하는 '서울 도시철도 공사'라는 회사가 따로 만들어졌다. 그런데 한 도시의 지하철에 사철도 아니고 공기업이 둘이나 있는 건 꽤 이례적인 경우였기 때문에 2017년부터는 두 회사가 하나로 합쳐져서 서울 교통 공사로 바뀌었다.
회사가 둘이서 따로 놀던 시절엔 한 회사 구간에서 파업이 벌어져도 다른 회사 노선은 영향이 없었는데.. 지금은 파업 발생 시에 지하철 1~8호선이 몽땅 멈춰 버릴 가능성이 생겨 있다.

9.
다음으로 서울 3기 지하철은 계획대로라면 9~12호선이 추가로 건설됐어야 했다. 하지만 외환 위기와 IMF, 이로 인한 긴축 재정 처방 때문에 지하철 건설 계획은 대부분 칼질 당했으며, 이 때문에 5~8호선 건설 때 미리 준비를 해 놨던 환승역 건설 공간과 노반도 상당수 잉여로 전락하게 됐다.;;
3호선과 7호선의 연장(오금 2010 / 부평구청 2012), 그리고 강남의 횡축 노선인 9호선만이 살아남았다. 나머지는 2010년대 이후에 서울 외곽 구간만이 광역전철(10은 신안산선, 11은 신분당선) 아니면 경전철(12는 우이신설선)로 실현됐다.

사용자 삽입 이미지

9호선은 다음과 같은 점에서 큰 의의가 있다.

  • 광역전철이 아닌 단순 도시철도 지하철로서는 이례적인 전구간 급행열차 운행
  • 처음 건설 때부터 모든 역에 스크린도어 시공
  • 마분지 승차권의 완전 퇴출
  • 오 세훈 시장 서울 디자인 가이드라인이 적용된 덕분에 혼자 굉장히 이질적인 인테리어
  • 한국형 표준 전동차 규격. VVVF 인버터도 통합됐기 때문에 구동음은 대전 같은 최신 지방 지하철하고 pitch(음높이)만 다르지 음색은 같다.

그러므로 서울 지하철의 건설 계획이 대판 틀어진 계기는

  • 1기 지하철: 육 영수 여사 피격으로 인한 서울 시장 경질 (신설동 역 유령 승강장이 생긴 이유도 이 때문!)
  • 3기 지하철: IMF ...;;

라고 정리된다. 그리고 차량 운용 계획이 실현되지 않은 것은..

  • 1호선: 유동적인 열차 중련 편성 (그런 것 필요없고 지금은 언제나 10량 꽉꽉 채움..)
  • 2기 지하철: 무인 운전 (현실은 시궁창. 1인 승무만으로 감지덕지)

이렇게 정리된다.
유동적인 열차 중련 편성은 무인 운전하고는 전혀 어울리지 않는 운용 계획이라는 게 흥미롭다. 철도 운영 이념이 세월에 따라 이렇게 바뀌었다.

Posted by 사무엘

2021/02/06 08:35 2021/02/06 08:35
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1851

1. DLL 주소 재배치와 ASLR의 관계

Windows XP 내지 Vista 이후로 (1) 커널 API와 C 런타임 라이브러리 함수 심벌들이 한 DLL 몰빵이 아니라 분야별로 재분류되어 배치되기 시작한 것, (2) 시스템 DLL들이 이제 전혀 rebase되지 않고 고정된 단일 preferred base 주소를 갖기 시작한 것을 보면 참 격세지감이 느껴진다.

위의 둘은 (1) 자잘한 DLL 여러 개보다 큰 DLL 하나가 더 효율적이다(선박처럼??). (2) DLL들은 로딩되는 주소가 겹치지 않게 빌드 후에 반드시 rebasing을 해 줘라
이런 전통적인 고정관념을 역행하는 변화이기 때문이다.

보안 강화를 위해 10여 년 전 Windows Vista 때부터 ASLR (시작 주소 랜덤화)이 도입되면서 DLL은 물론이고 EXE조차도 반드시 자기 preferred base에 고정적으로 로딩이 되지 않게 되었다. 이 때문에 요즘은 EXE도 과거 Win32s 프로그램들처럼 끝에 재배치 정보가 다시 포함돼 들어가고 있다.

하지만 이런 ASLR을 위한 재배치 때는 말 그대로 메모리 오프셋 수정만 행해질 뿐, 재배치의 치명적인 페널티라고 여겨지는 가상 메모리 페이지 파일 재기록이라든가 재사용 불가(여러 프로세스에서 동일 DLL 로딩 시에도 shallow가 아닌 deep copy 발생) 까지 발생하지는 않는다. 운영체제의 보안 기능이 그 정도로 바보는 아니다.

그러므로 오늘날은 DLL을 미리 rebase 하건 안 하건 실행 성능이 달라지는 것은 없다. rebase를 해도 이익을 얻는 것은 없지만 반대로 손해를 보는 것 역시 없다. rebase라는 게 빌드 타임이 아닌 런타임의 영역으로 바뀐 셈이다.

정말 재수가 없어서 엄청 많은 자잘한 DLL들이 로딩되다 보니 한 DLL이 프로세스 A에서는 ASLR 배당 주소로 로딩됐지만 프로세스 B에서는 그 주소로 로딩이 못 되게 됐다면.. 그때는 통상적인 페널티가 부과되는 재배치가 발생할 것이다. 하지만 광대한 주소 공간을 자랑하는 64비트 환경에서는 그럴 가능성이 더욱 희박해졌다.

2. EXE를 LoadLibrary 하기

LoadLibrary 함수는 실행 가능한 코드가 담긴 DLL을 불러오거나 혹은 EXE/DLL로부터 리소스를 얻고자 할 때 즐겨 쓰인다.
그런데 여기서 의문이 든다. LoadLibrary를 호출해서 exe의 단순 리소스가 아니라 코드를 내 프로세스 공간에 가져와 실행하는 게 가능할까?

사실, 기술적으로 볼 때 EXE와 DLL의 차이는 그리 크지 않다. 심지어 EXE도 DLL처럼 심벌 export를 할 수 있다.
그리고 EXE를 LoadLibrary로 그냥 쌩으로 불러와도, 의외로 일단 성공은 한다. GetProcAddress를 해서 심벌을 요청하면 주소값이 돌아오기까지 한다.
하지만 그 함수를 호출해 보면 십중팔구 access violation 에러가 난다. 여기서 대부분의 사람들은 '안 되나 보다'라고 생각하고 단념하게 된다. 왜 이런 현상이 발생하는 것이며, 문제를 해결할 방법은 없는 걸까?

DLL이 아닌 EXE를 LoadLibrary 하면 운영체제는 얘를 반쯤 데이터로 취급하는가 보다. GetProcAddress를 호출했을 때 심벌 검색 결과를 되돌려 주지만 그 포인터가 가리키는 코드를 실행 가능한 상태로 만들어 놓지는 않는다.
특히 (1) 주소 재배치와 관련된 그 어떤 조치도 취하지 않는다. 구체적으로는.. EXE가 사용하는 import table의 주소를 패치하지 않기 때문에 그 EXE의 코드가 실행되면서 Windows API 같은 걸 호출하면 그대로 뻑이 나게 된다.

그리고 (2) EXE의 진입점 함수를 전혀 실행하지 않는다.
EXE건 DLL이건 무조건 맨 먼저 실행할 부분을 가리키는 진입점이란 게 있는데.. 그게 EXE는 int func() 형태이고, DLL은 BOOL func(HMODULE, UINT, PVOID) 형태이다.

즉, EXE는 처음엔 아무 인자 없이 실행됐고 C 라이브러리가 GetStartupInfo 같은 API 함수를 호출해서 실행 인자를 준비한 뒤에 main이나 WinMain을 또 호출하는 형태이다. 그러나 DLL은 진입점 함수의 형태가 DllMain과 완전히 동일하다. 즉, DLL_PROCESS_ATTACH 같은 이벤트 명칭은 이 함수의 호출 인자가 아니면 딴 데서 알아낼 곳이 없다.
LoadLibrary는 원래 DllMain을 호출하게 돼 있는데 EXE는 받아들이는 함수 prototype이 다르므로 아예 호출을 안 하는 것이다.

그러므로 LoadLibrary된 exe의 코드를 강제로 실행한다면 IAT 테이블의 주소가 패치되지 않고 C 라이브러리가 전혀 초기화되지 않은 상태에서 덥석 실행된다. 그 함수에서 내부적으로 전역변수 C++ 객체 같은 걸 사용한다면.. 역시나 제대로 실행되지 못하고 높은 확률로 뻑나게 된다.

IAT 주소를 패치하는 방법까지는 어느 용자가 찾아낸 게 인터넷에 이미 굴러다닌다. (☞ 링크) 이거 패치가 제대로 되려면 EXE는 애초부터 재배치 정보가 들어간 상태로 빌드돼야 한다.
하지만 각종 부작용 없이 C 라이브러리만 감쪽같이 초기화하고 EXE의 export 함수를 실행하는 건.. 굉장히 삽질스럽고 가성비가 낮다. 그냥 EXE와 DLL의 차이가 이러하며 LoadLibrary(EXE)가 기술적으로 왜 권장되지 않는지 이론으로만 알고 넘어가면 될 듯하다.

3. 재빠르게 대체된 파일에 대한 creation date 보정

응용 프로그램 중에는 안전을 위해 문서 저장 기능을 임시 파일을 생성하는 형태로 구현한 것이 있다.
기존 파일을 곧장 덮어써서 저장하는 게 아니라.. 임시 파일에다가 저장을 한 뒤, 기존 파일을 지우고 임시 파일을 기존 파일의 이름으로 바꾼다. 이렇게 하면 저장하는 중에 컴퓨터에 전기가 나가는 등의 이상 현상이 발생하더라도 최소한 기존 자료가 송두리째 날아가는 일은 막을 수 있다.

그런데 이렇게 기존 파일을 덮어쓰는 게 아니라 파일 자체를 딴 것으로 대체하는 식으로 저장을 하면 기존 파일이 갖고 있는 creation time이 보존되지 않게 된다. 그렇기 때문에 기존 파일의 creation time을 따로 얻어 놓은 뒤, 저장을 마친 새 파일에 대해서 creation time을 SetFileTime 함수로 따로 지정해 줘야 한다.

단, Windows NT 계열의 경우, 놀랍게도 보정 동작을 진작부터 지원하고 있었다. 어떤 프로그램이 A라는 파일을 삭제한 뒤에 다른 파일의 이름을 A로 신속하게 거의 곧장 변경한 경우, 그 파일에다가 삭제된 A의 creation time을 자동으로 지정해 줬던 것이다~!

이런 보정을 위해서는 파일 삭제와 개명 알고리즘에다가 삭제된 파일의 생성 시각을 백업해 놓고, 시간차를 감지해서 이 renaming이 기존 파일을 승계하는 동작인지 판단하는 등 여러 귀찮은 작업이 필요할 것이다. 하지만 마소에서는 임시 파일 방식으로 저장하면서 creation time을 관리하지 않는 프로그램이 많은 것을 감안하여 운영체제 차원에서 이런 보정 기능을 구현했다고 한다.

이 보정은 NT 계열에서만 지원되어 왔으며, 9x 계열에서는 존재하지 않는다.

4. 스레드 동기화 deadlock 자동 감지

복잡한 메모리 문제를 잡아내기 위해 C 라이브러리 차원에서 저런 다양한 안전 장치와 디버깅 편의 기능이 제공되듯, 멀티스레드 동기화 오브젝트에도 디버그 버전용은 데드락 정도는 assertion failure 에러를 내면서 곧장 감지하는 기능이 있으면 좋겠다는 생각이 든다.

“당신이 지금 취득을 위해 대기하려는 뮤텍스는 현재 다른 스레드가 잡고 있는데, 문제는 그 스레드도 지금 당신이 요 스레드에서 잡고 있는 뮤텍스를 얻으려고 대기 중이다. 그러니 이 상태로는 상호 무한 대기 교착 상태가 됨.”

이건 레퍼런스 카운트 기반인 오브젝트에서 순환 참조 오류를 감지하는 기능을 구현하는 것과 기술적으로 완전히 동급이다.
Hash 같은 컨테이너를 둬서 스레드 ID별로 각각 현재 진입해 있는 뮤텍스에 대한 기록을 관리하고, 뮤텍스 오브젝트를 감싸는 클래스에다가 현재 자신을 잡고 있는 스레드 정보도 같이 보관하는 정도의 수고만 하면 큰 어려움 없이 구현 가능하다.

하지만 PC용 프로그램에서 돌아가는 스레드의 개수가 무슨 할당된 동적 메모리 블록 개수처럼 많을 리는 없을 것이고, 프로그램의 응답이 멎었을 때 데드락 부위를 찾는 것은 도구의 도움 없이 도저히 못 할 일은 아닐 것이다. 유용성에 비해 저런 기능을 갖추는 건 속도와 메모리 오버헤드가 너무 커서 가성비가 맞지 않으니 데드락 자동 감지 기능은 운영체제나 프로그래밍 언어 런타임이 제공해 주지 않는 듯하다.

개인적으로 직장에서는 심지어 자기 스레드 자신의 실행이 끝나기를 기다리는.. C++ 오브젝트로 치면 delete this.. 무슨 자살이나 다름없는 deadlock도 경험한 적이 있었다.
프로그램의 실행이 종료되어 UnInit() 함수가 호출될 때는 백그라운드 작업 스레드에 대해서도 작업을 중단시키고 작업 스레드의 실행이 끝날 때까지 기다리게 했는데, 뭔가 로직이 꼬여서 작업 스레드에서 UnInit()를 호출하는 상황이 발생한 것이다.

Uninit이 무슨 loop 안에서 1초에 수십, 수백 번씩 실행되어서 성능이 중요한 함수인 건 아니다. 그러니 자기 자신이 무슨 스레드 문맥에서 실행되었는지 검사해서 deadlock을 피할 수도 있다.
하지만 그것보다는 Uninit이 스레드 함수가 아니라 의도했던 대로 main thread에서만 실행되도록 프로그램 구조를 고치는 것이 훨씬 더 나은 해결책이었다.

Posted by 사무엘

2021/02/03 19:36 2021/02/03 19:36
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1850

1. 프로그래밍 용어· 명칭과 타 분야 비교

  • 2의 제곱근 vs 제곱근(루트) 2: 어순의 차이로 의미가 달라지는 new operator/operator new, 함수 템플릿 vs 템플릿 함수 같은 C++ 용어와 상황이 비슷하다. 특히 다들 전자가 후자를 포함하는 편이기도 하다.
  • 전철역에서 논현, 신길, 양평: namespace가 필요한 좋은 예이다..;;; (1) 얘들은 고유명사 지명이 지역간에 충돌하는 사례이고 (2) 월드컵경기장이나 시청은 보통명사 시설명이 충돌하는 예이다.
    (3) 수색, 광명, 신촌 같은 건 지역이 아니라 일반열차 역과 지하철역이 충돌하는 경우이다. 그리고 (4) '회송'은 역의 이름으로는 쓰이지 않는(쓰일 수 없는) reserved word 정도에 대응할 것이다.
  • 배의 명칭 A급 B함/호(포항급 초계함 천안함, 올림픽급 타이타닉 호, 베헤모스급 배틀크루저 히페리온): 프로그래밍으로 치면 A는 타입명이고 B는 변수명이다.

2. 마침표와 세미콜론

우리는 년월일 날짜를 간략하게 표기할 때 2020. 10. 5. 같은 식으로 숫자 뒤에 마침표를 찍곤 한다. 이때 일을 나타내는 마지막 마침표도 생략하지 말고 반드시 다 찍는 것이 한글 맞춤법에 규정된 원칙이다. 각각의 점이 년, 월, 일을 나타내기 때문이다.

이는 마치 파스칼 언어에서는 세미콜론이 문장의 구분자(separator)인 반면, C/C++에서는 문장의 종결자(terminator)인 것과 비슷하다.
파스칼에서는 end나 else 직전에 등장하는 구문의 끝에 ; 이 생략되지만 C/C++은 그렇지 않다. 날짜 숫자의 뒤에다 찍는 .는 파스칼이 아닌 C/C++의 세미콜론과 같은 성격이라고 생각해야 한다.

3. 병렬화

같은 용량의 데이터가 있을 때 압축을 하는 것은 압축을 푸는 것보다 계산량이 훨씬 더 많은 어려운 작업임이 주지의 사실이다.
그 대신, 압축 "하기"는 CPU 멀티코어를 활용해서 속도를 쭉쭉 끌어올릴 수도 있는 반면, "풀기"는 그런 병렬화는 안 되고 그냥 단일 코어에서 linear한 작업에 의존할 수밖에 없다. 기껏해야 풀어야 하는 압축 파일 자체가 여러 개일 때에나 여러 CPU에다가 던져줄 수 있을 것이다.

C/C++ 파일을 빌드하는 절차도 이와 비슷해 보인다. '컴파일'은 아무래도 분산 처리와 병렬화가 가능하지만, 모든 결과물이 하나로 집약되는 '링크'는 그게 불가능한 최종 병목이 될 수밖에 없다.

4. 버퍼의 크기

일상적으로 무슨 모임 같은 데서(본인의 경우는 교회에서 청년부 모임 같은..) 인원수대로 프린트물이나 간식 같은 것을 준비해야 할 때가 있다. 평소에 모임 참석자가 얼마 정도 되는지에 대한 대략의 데이터는 있지만 딱 정확하게 몇 명인지는 알 수 없을 때는 준비물을 몇 개 정도 챙겨야 너무 남거나 모자라는 일이 없이 최대한 딱 맞을 수 있을까?

이건 나름 통계적인 노하우가 필요한 일이다. 가끔 모자라는 일이 발생해도 괜찮은지, 아니면 모자라는 일은 절대 없어야 하는지에 따라서도 전략이 달라진다. 프로그래밍으로 치면 static한 배열의 크기를 잡는 것과 매우 비슷해 보인다는 생각을 본인은 오래 전부터 했다. ㅎㅎ

문자열 클래스의 경우, 사소한 문자열까지 늘 동적 메모리를 할당하는 건 번거로우니 자체적으로 자그마한 배열도 갖고 있고, 그 배열 크기를 초월하는 긴 문자열을 배당할 때만 동적 메모리를 사용하게 하는 구현체도 존재한다. C++의 표준 string 클래스도 반드시 저렇게 동작해야 한다는 조건은 없지만 대체로 이런 식으로 구현된 걸로 본인은 알고 있다.

이런 것 말고도

  • 건물을 지을 때 이 정도 건물에서는 화장실에 변개를 몇 개 설치하는 게 좋을까?
  • 엘리베이터는 어느 정도 크기로 몇 개 설치하는 게 좋을까?
  • 이 정도 도로의 교차로 내지 횡단보도에서는 신호 주기를 어느 정도로 주는 게 좋을까?

같은 문제도 치밀한 공학 및 통계 계산의 산물이지 싶다. 동시에 사용하는 사람의 수가 최대인 시간대에 대기 시간이 너무 길어지지 않게 하는 한편으로, 나머지 한산한 시간대에 시설들이 사용자 없이 놀면서 발생하는 비효율도 최소화해야 하기 때문이다.

5. 훅킹

훅(hook) 내지 훅킹이란 컴퓨터 소프트웨어가 돌아가는 과정을 몰래 들여다보고 필요하면 변조도 하는 메커니즘을 말한다. 훅킹은 대체로 시스템 프로그래밍 분야에 속하며 꽤 강력한 고급 테크닉으로 간주된다.

(1) 메시지 훅
Windows에는 SetWindowsHookEx라는 엄청난 함수가 있어서 시스템과 응용 프로그램 사이에서 오가는 메시지들을 매우 수월하게 들여다볼 수 있다. 그러니 Spy++ 같은 프로그램을 만들 수 있다.
권한 문제만 없다면 심지어 다른 프로그램의 메시지를 들여다볼 수도 있다. 이 경우, 훅 프로시저가 내 프로세스가 아니라 그 메시지를 받은 프로세스의 문맥에서 실행된다는 점을 주의할 것. 32비트와 64비트별로 DLL을 따로 만들고, 프로세스 간의 통신 같은 잡다한 수고만 좀 해 주면 된다.

(2) API 훅
다른 프로그램이 그냥 기계어 수준에서 운영체제의 특정 함수를 호출하는 것을 감지하고, 그 함수 대신 내가 심은 함수가 호출되게 할 수 있다. C 언어 형태의 클래식 API가 제일 쉽고, COM도 결국은 CoCreateInstance 같은 함수를 훅킹하면 이론적으로 가능하다. 실행되는 기계어 코드를 변조하는 게 아니라 import 섹션 주소를 변조하는 고전적인 테크닉이 있다.

16비트 시절에는 API 훅을 시스템 전체에다 걸어서 운영체제 외형을 통째로 마개조 할 수도 있었지만 32비트 이후부터는 그 정도까지는 어렵다. 다만, 시스템 전체에다가 설치한 메시지 훅과 CreateRemoteThread 등 다른 어려운 테크닉들과 연계하면 API 훅도 어느 정도 global하게 설치하는 게 가능은 하다.
과거에 한컴사전이 GDI 그래픽 API에다가 훅을 걸어서 단어 자동 인식 기능을 제공했던 적이 있다. 마우스 포인터 주변의 화면 캡처 + 필기 인식이 아니다~!

(3) 패킷 훅
심지어 시스템 전체에서 오고 가는 네트워크 패킷을 모니터링 할 수도 있다. 이게 기술적으로 가능하니까 packet sniffer이라고 불리는 유틸리티들도 존재 가능할 것이다. 이에 대해서는 본인도 더 아는 게 없다.
macOS는 Windows와 달리 메시지 훅이고 API 훅 같은 건 존재하지 않는 것으로 본인은 알고 있다. 하지만 macOS라도 패킷 모니터링은 아마 가능할 것이다.

packet sniffer이라든가 심지어 VPN 툴 같은 건 어떤 API를 써서 어떻게 만드나 모르겠다. 신기한 물건이다.

Posted by 사무엘

2021/02/01 08:34 2021/02/01 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1849

« Previous : 1 : 2 : 3 : 4 : 5 : ... 173 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/02   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            

Site Stats

Total hits:
1549023
Today:
263
Yesterday:
549