심우주 통신망

인류는 19세기에 전깃줄을 이용한 전화라는 유선 통신 기술을 발명해 냈으며, 20세기 초에는 아예 전자기파를 이용한 장거리 무선 통신 기술까지 개발했다.
그리고 1960년대에는 통신 위성 덕분에 아예 둥근 지구의 반대편으로 전화와 TV의 전파를 실시간으로 주고 받는 게 가능해졌다. 위성 생중계가 최초로 시작된 올림픽이 1964년의 도쿄 올림픽이었다고 그런다.

그러니 유선 전화에 전혀 의존하지 않는 무선 전화도 오래 전부터 있긴 했다. 단지 기계값과 시간 당 통화료가 아주 비싸기 때문에 자동차나 선박에 장착되는 사치품 내지 아주 특수한 물건으로 취급되었을 뿐이다.
그러던 것이 1990년대 말부터는 그냥 전국민 1인 1휴대전화 시대가 시작됐다. 이를 위해서 전국 곳곳에 휴대전화 기지국이 건설되었으며, 각종 건물과 지하철 내부에도 중계기가 설치되었다.

전깃줄 중에 진짜로 전기를 보내는 용도로만 사용되는 굵은 송전선은 지상의 산들과 철탑 위로 아주 높고 길게 뻗어 있다. 요즘 만드는 도시들 내부에서는 지중화되어서 지하로 지난다.
다음으로, 동축 케이블이니 광섬유 케이블이니 하는 이름으로 데이터 통신을 담당하는 전깃줄들은 대륙과 대륙을 연결해야 하기 때문에 바다 밑으로 쫙 깔려 있다. 해저 지진이 나서 이런 케이블이 파손되면 주변 국가들의 인터넷 속도가 느려지는 사태가 발생한다.

인간이 지난 수십 년 동안 지구 곳곳에 깔아 놓은 통신 인프라를 생각하면 경이로움마저 느껴진다. 민간보다는 군용에 더 가까운 레이더(radar) 관련 기술도 말이다. 따지고 보면 레이더의 발명은 비행기의 발명 그 자체만큼이나 비행기의 운용· 관제 방식과 공중전의 양상을 근본적으로 바꿔 놓았다.

2차 세계 대전 당시에 일본에서는 자국인 과학자/공학자가 아주 훌륭한 레이더용 안테나(야기-우다 안테나)를 발명했는데, 그걸 군부에서 제대로 활용하지 않는 병크를 저질렀다. 그래서 정작 적국인 연합국(영국)이 그 기술을 활용해서 전쟁에서 일본을 관광 태웠다는 안습한 일화까지 전해진다.
레이더도 원래 레이저(laser)처럼 복잡한 단어들 이니셜로 만들어진 단어이지만, 지금은 그 자체가 새로운 형태소처럼 쓰인다.

그런데 경이로운 통신 기술은 지구 대 지구 스케일만 있는 게 아니다. 지구 대 우주 분야도 있다.
까놓고 말해 달에 착륙한 아폴로 11호 승무원들의 활동 동영상은 어떻게 해서 지구로 실시간 중계될 수 있었을까?
뉴 호라이즌스 호가 보낸 명왕성 사진은 어떻게 해서 지구로 잘 전달될 수 있었을까?
신호가 가는 데 편도로만 17시간이 넘게 걸린다는 보이저 탐사선은 어떻게 지금도 지구와 교신이 되고 있을까?

우주로 나가려면 적도 근처에다 우주 센터와 발사대를 만들고 로켓만 죽어라고 쏴 올릴 게 아니라, 로켓에 실린 탐사선이 보내 주는 정보를 넙죽넙죽 잘 받기 위한 통신 시설도 반드시 개발해야 한다. 그래서 미국 NASA에서는 진작부터 Deep Space Network(심우주 네트워크)라는 이름으로 전파 수신용 거대한 접시형 안테나 기지를 만들었다.

사용자 삽입 이미지

20세기 초· 중반까지만 해도 우주는커녕 지구 표면의 남극이나 에베레스트 산 정상을 탐험하는 사람들과도 실시간 무선 통신이 가능하지 않았으며 그들의 생사를 곧장 확인할 수 없었다. 주변 풍경 인증샷은 탐험가들이 카메라로 찍은 뒤에 무사 귀환할 때까지 필름을 반드시 잘 간수해야만 전해질 수 있었다!

아폴로 우주선의 달 탐사가 그런 식으로 답답하게 진행되지 않고 전세계 텔레비전으로 전파를 타고 생중계된 것은 매우 다행스러운 일이 아닐 수 없다.
이런 안테나 기지는 로켓이 실제로 발사되고 수많은 관중들이 몰리는 우주 센터보다는 존재감이 훨씬 덜하다. 하지만 이런 시설에서 일하는 사람들도 우주 탐사의 숨은 일등공신이라 불리기에 전혀 손색이 없을 것이다.

NASA 내부에서 이 안테나 기지를 관리하는 부서는 '제트 추진 연구소'이다. 이름만 봐서는 만년 발사체 연구만 할 것 같은 곳에서 통신망까지 연구한 것은 우연이 아니라 하겠다. 우리나라의 인터넷 인프라의 대부인 전 길남 박사/교수도 젊은 시절에 저기서 근무한 경력이 있는 것이 잘 알려져 있다.

저기는 비행기용 제트 엔진(터보 팬 같은..?)을 연구하는 곳이 전혀 아니다. 엄연히 산화제까지 같이 들어있는 우주 발사체용 로켓 엔진의 연구가 본업이다. 하지만 저 연구소가 처음 생겼던 당시에는 '로켓'이라는 단어가 그리 대중적이지 않았기 때문에 이름이 저렇게 붙은 것이다.

비슷한 다른 예로는 IBM이 있다. 이름에 '컴퓨터, 정보' 같은 단어가 들어가기에는 역사가 너무 긴 기업인 관계로, 오늘날까지도 고작 '국제 사무용품 기기'라는.. 마치 국제시장 같은 매우 낡은 명칭으로 통용되고 있지 않은가? 그래도 워낙 넘사벽급의 기술과 인지도를 자랑하는 세계구급 기업이니 이름 따위는 바꿀 필요가 없다.

제트 추진 연구소 때문에 이야기가 잠시 옆으로 샜는데, 다시 안테나 얘기로 돌아오기로 한다.
사진을 보면 알겠지만, 이들 기지에 만들어진 안테나는 지름이 30m대 내지 70m대까지 있을 정도로 매우 거대하다.
그리고 한 곳에만 있는 게 아니라 다음과 같이 대략 120도대의 경도 간격으로 세 군데가 존재한다. 그래야 임의의 지표면에 도달한 전파가 지구의 자전에 구애받지 않고 셋 중 적어도 한 곳 이상에서 언제나 수신 가능하기 때문이다.

  • 미국 서부의 캘리포니아 바스토우 모하비 사막 (UTC-08:00)
  • 스페인 마드리드 (UTC+01:00)
  • 오스트레일리아 캔버라 (UTC+10:00)

사용자 삽입 이미지
위의 그림은 지구를 북극점 위에서 내려다본 시점에서 세 기지가 감지 가능한 신호 영역을 나타낸 것이다.
가령, 1969년 아폴로 11호의 달 착륙 신호를 최초로 잡아서 전세계에 타전한 곳은 미국이 아닌 오스트레일리아 기지였다. 미국에서도 잡히긴 했지만 저쪽이 신호가 더 또렷했다고 한다.

보행자와 차들로 북적대는 육지의 도로와 달리, 비행기가 순항하는 공중이나 배가 항해하는 공해는 장애물이 없다시피하다.
하물며 우주의 스케일은 지구를 훨씬 능가한다. 우주는 정말 우리가 상상하기 어려울 정도로 너무 방대 광대하게 텅 빈 공간이다. 태양계 행성들의 크기는 행성들 간의 거리에 비하면 새 발의 피 수준에 지나지 않는다. 우주 탐사선은 한번 가속을 한 뒤엔 관성으로 한없이 등속 운동만 하면 되며, 전파도 그냥 조준만 잘 해서 쏴 주면 지구나 탐사선에 도착하는 건 그냥 시간 문제일 뿐이다. 다른 장애물에 부딪칠 걱정은 사실상 할 필요가 없다.

우주 공간에서 지구와 탐사선의 사이에 물리적인 장애물 걱정을 할 필요가 없는 건 일면 다행이다.
하지만 외행성 탐사선의 경우, 지구와 워낙 너무 멀리 떨어져 있기 때문에 전파도 진행하는 동안 점점 넓게 퍼지고 신호가 약해진다. 게다가 지표면에서는 주변에 숱하게 돌아다니는 지구 발 노이즈들을 걸러내고 그 약한 우주 발 신호만 증폭해서 받아야 한다.

신호를 보낼 때야 지구에서 최신 설비로 최고 출력 고주파로 그나마 최대한 빵빵하게 쏘겠지만, 가녀린 탐사선에서 지구로 보낸 신호를 받는 것은 정말 보통일이 아닐 것 같다.
안테나가 괜히 저렇게 거대한 게 아니다. 그나마 지금은 기술의 발달 덕분에 옛날 같은 지름 70m짜리는 필요하지 않고 30m대만으로도 충분하다고 그런다.

그나마 보이저보다 나중에 더 최신 기술로 발사됐고 지구에 훨씬 더 가까이 있는 뉴 호라이즌 호도 거기서 지구까지 전파가 도달하는 데 4~5시간을 잡아야 한다. 그런 propagation delay와는 별개로, 데이터의 전송 속도도 초당 수백 바이트, 1980년대의 2400~9600bps 모뎀 수준에 지나지 않는다고 한다. 거리가 너무 멀고, 탐사선의 전파 출력에도 한계가 있기 때문에 이건 뭐 어쩔 수가 없다.

그렇기 때문에 탐사선은 자기 메모리에 저장해 놓은 수십 GB에 달하는 사진들을 지구로 찔끔찔금 보내느라 그야말로 세월아 네월아 애써야 했다.
propagation delay인 4~5시간만 지나고 나면 지구에서 인터넷 하듯이 고화질 명왕성 사진이 짠~ 뜨는 건 인류의 기술로는 아직 가능하지 않다.

지구가 둥글다는 건 말할 것도 없고, 빛의 속도조차도 느리다는 걸 실감하는 직업에 종사하는 사람들은 평소에 자기 전공과 생업에 대해서 무슨 생각이 들지 궁금해진다.
더 나아가 달 같은 데서 지구의 인터넷을 연계해서 쓰는 게 가능해질까? 흥미로운 상상이 아닐 수 없다.

Posted by 사무엘

2019/04/18 08:31 2019/04/18 08:31
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1609

Trackback URL : http://moogi.new21.org/tc/trackback/1609

Leave a comment

요즘 근황

올해 1사분기 동안 본인에게 무슨 일이 있었는지.. 사는 얘기 기록을 좀 남기도록 하겠다.

0. 미세먼지

4월이 되니 날씨가 그럭저럭 좋은 편이다. 하지만 지난 3월 초에는.. 어휴, 정말 역대급 최악의 독스모그 미세먼지가 전국을 뒤덮었던 게 본인의 기억에도 트라우마로 남아 있다. 최장 기간, 최대 면적, 최고 농도... 이런 날이 잠깐 하루 이틀이면 집에 틀어박혀서 버티겠지만, 저게 1주일 가까이 계속되니 본인도 미쳐 버릴 것 같았다.

층간· 벽간 소음이라든가 주차 문제 때문에 미치겠다면서 이웃 간에 싸움 나고 최악의 경우 살인까지 벌어지는데, 미세먼지는 그런 부류의 갈등이 개인이 아닌 국가 단위로 벌어지는 것이나 마찬가지이다. 이 스케일에서는 이론적으로, 정말 최악의 경우 전쟁까지 날 수도 있다.

미세먼지 자체가 정치인 탓은 물론 아닐 것이다. 그리고 우리나라가 정말로 국력이나 기술이 부족해서 옆의 나라에다 항의나 응징 한번 제대로 못 하고 찌그러져 있는 거라면 그것도 어쩔 수 없다.
하지만, 같은 강도의 미세먼지여도 그게 어디에서 오는지에 따라서, 그리고 지금 누가 여당이고 집권했느냐에 따라서 조건부로 정반대로 완전히 다르게 반응하는 더러운 종자들을 생각하면 생각할수록 짜증이 치솟으며 욕을 한 바가지 퍼붓지 않을 수가 없다.

사용자 삽입 이미지

저게 무슨 환경 단체냐? 정치 운동 선동꾼일 뿐이지! 비싼 밥 쳐먹으면서 도대체 왜 인생을 저 따위로 사는 걸까? 2MB 시절의 747 공약보다 더 허무맹랑하고 황당하고 전혀 안 지켜진 공약이 뭐가 있는지 진지하게 생각해 본 적은 있으려나 모르겠다.
하긴, 쟤들은 광우뻥 vs 멜라민, 그리고 산에서 케이블카 만드는 것조차 반대하더니 되도 않은 태양광 한답시고 산 깎고 산림 몽땅 파괴하는 것에는 절대침묵 등.. 일관성과 정당성과 명분은 진작부터 상실했다.

평생을 일제 식민지 일본 탓, 분단의 원흉 미국 탓 지랄하면서 살던 놈들이.. 미세먼지에 대해서는 아이고, 어지간한 종교인들 뺨치는 "내 탓이오" 모드가 돼서 고등어 탓, 포항제철 탓(!!), 디젤 차량 탓 내부 요인 운운하는 거다. 왜? 일본이나 미국에서 온 미세먼지가 아니기 때문이다. 지구의 자전 방향이 반대였으면 이거 정말 큰일 났겠다. 어휴~

그나저나 병X은 국내뿐만 아니라 어디에나 있는지, 옛날에 일본에서는 "먹어서 응원하자"(후쿠시마 지역 방사능 유출 의심 농산물...ㅜㅜ) 구호가 나오더니만 중국에서는 "다같이 구보하면서 공기를 마셔서 정화하자"(우웩..ㅠㅠ) 캠페인이 나왔던가 보다.

1. 찬양 인도 경력 10년

2019년을 기해 본인은 개인적으로 다니는 교회에서 예배/집회 전의 준비 찬송(회중 찬양) 인도를 맡은 지 딱 10년이 됐다. 주일 예배를 새마을호 열차 운행에다 비유한다면, 시발역 출발 전에 Looking for you가 흘러나오는 것 같은 10분 남짓한 예비 시간을 책임지게 됐다.
우리 교회에서는 유튜브 방송으로 예배를 실황 중계를 하는데, 이 때문에 내 얼굴도 지금까지 인터넷으로 많이 팔린 모양이다.

준비 찬송이라는 말을 안 좋아하는 분도 있다. "이거 찬송 부르는 시간도 엄연히 예배의 일부이다. 예배 중에 주보에 기재된 찬송가는 부르면서, 준비 찬송(?)은 불러도 되고 안 불러도 되는 식으로 격을 낮게 취급해서는 안 된다" 식으로 말이다.

그렇게 생각해 준다면 나야 고마운 일이긴 하다만, 그런 격식을 따지기에 각 성도들이 정말로 찬송을 진심으로 부르고 싶어서 불렀으면 좋겠다.
너무 짠한 얘기를 자주 남발하고 싶지는 않지만.. 저 이북에서는 굶주림 때문도, 정치적 자유 때문도 아니고 "찬송 좀 마음 놓고 불러 보고 싶어서" 탈북을 한 사람도 있었다.

난 어디처럼 감미로운 BGM과 함께 "할렐루야~ 우리 다함께 찬양하며 주님 앞에 나아가길 원합니다~ / 성령이여 불같이 임하소서~~!! / 우리 다같이 주여삼창 통성으로 기도하시겠~슙니다~ !@#@!#@!#@!" 같은 건 오글거려서 못 하고...;;; 그냥 "찬송가 xx장입니다"와 함께 진~짜 행진곡 풍으로 크고 정확하게만 부른다.

그리고 잘 부르는 것뿐만 아니라 잘 고르는 것도 중요하다.
내 찬송가 책은 비슷한 시기에 구매한 다른 사람의 책에 비해 종이가 굉장히 낡았고 너덜너덜하다. 매주 곡을 고르기 위해서 책 전체를 뒤적이고 연구하기 때문이다. (신자라면 사실은 찬송가보다도 성경책이 더 그래야 되는데..)
학교에서 교육용으로 재래식 칠판과 분필을 따라갈 물건이 없듯, 선곡을 위해 책을 뒤적이는 도구로는 답답한 컴퓨터 화면 스크롤이 종이책을 결코 대체할 수 없더라.

그 결과, 회중 찬송용으로 적합한 수십여 곡의 신곡들이 내가 직접 들은 적 없이 악보를 읽어서 분위기를 추측한 것만으로 많이 개척됐다.
형제님 덕분에 새로운 좋은 찬송가를 많이 배워서 좋고, 준비 찬송 장면을 녹음해서 집에 가서 다시 들으면서 익힌다는 어느 어르신의 말씀이 굉장한 격려가 됐다.

하루는 주보의 '읽어 보세요' 코너에 영적 성장과 관련된 시가 한 편 실렸는데..
동일한 시가 그대로 가사로 쓰인 곡을 내가 언젠가 찬송가 책을 뒤적이고 악보를 읽어다가 본 적이 있었다. 그 곡을 찾아내어 신곡이 하나 발굴됐다.

또한, 우리 교회는 오전 예배 때 다같이 성경 구절 암송을 하는 게 있는데.. 그 구절을 가사로 쓴 찬양이 있으면 오전 준비 찬송곡에 넣기도 했다. 이거야말로 찬송가를 최고 적절하게 활용하는 게 아니겠는가?
그리고 매 사분기마다 주일학교 애들이 발표를 하는 날이면 오후 예배 준비 찬송 때도 걔들에 대한 courtesy 차원에서 어린이 찬송가를 한두 곡 준비 찬송에 넣는다.

그런 특별한 변수가 없을 때 다음 주에 부를 찬송가를 컴퓨터 추첨 뺑뺑이로 자동화를 좀 했으면 좋겠지만..
곡을 고를 때는 각 곡별 개인적인 선호도와 가중치, 친숙한 정도 등등 딱 수치화할 수 없는 변수들이 굉장히 많이 동원된다. 그래서 자동화가 안 되고 있다.
요런 게 찬양 인도의 묘미이다.

2. 먹빵과 취향

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

내가 이 정도로 먹는 날은 1년에 두 번 남짓이다. 생일, 그리고 3년쯤 전부터 관행이 되어 온 하계 휴가를 갔을 때 말이다. 본인은 공교롭게도 생일이 겨울이어서 두 날이 반 년에 가까운 간격으로 떨어져 있기 때문에 서로 시기적으로 균형도 잘 맞다.

덧붙이자면 본인은 종교관과 취향의 이유로 인해 술· 담배를 안 하는 사람이다.
하지만 그것과 별개로.. 안 그래도 건강에 안 좋은 저런 기호품을 사람들이 굳이 왜 즐길까, 저게 무슨 일말의 순기능이 있을까 하는 생각 자체는 해 봤다.

담배의 경우, 다같이 일하다가 휴식할 만한 적절한 명분과 휴식 시간, 휴식 방식을 제공해 준다. "화장실 다녀오겠습니다"만큼이나, "잠시 담배나 좀 한 대 피웁시다"가 휴식 선언이다.
그리고 상급자와 하급자가 같이 담배 쪽쪽 빨면서 대화 나누면 자연스럽게 친해지기는 하겠더라. 둘 중 한 명이 그냥 가만히 있기만 하면 민망하고 뻘쭘하니까 말이다. 그에 반해 화장실은 대화와 친교가 오갈 만한 공간은 아니다.

담배 다음으로 술은 사람 정신을 몽롱하게 만들어서 본성을 드러나게 하고, 맨정신으로 하기 힘든 얘기가 선뜻 나옴으로써 사람끼리 가까워지게(?) 하는 효과가 있어 보인다. 또한, 인체에 탈을 일으키는 물질을 흡입하고도 자기는 멀쩡하다고 남자들 세계에서 부심을 조장하는 추가적인 효과도 있다.

그리고 술은 음식을 안주감으로 소비하게 만들지만 한편으로 음식의 소모 속도를 늦추기도 한다. 술 없이 회만 먹으니 내 경험상 음식이 없어지는 속도가 감당이 안 되더라..;; 뭐, 저 때는 나 혼자가 아니라 가족과 같이 먹은 것이었다.

그래도 그렇지 사람을 중독시키고 건강 망치는 물건을 도대체 누가 자기 돈 주면서 마시고 피울까?? 저게 도대체 어떻게 장사가 될까? 세상에는 단순한 경제 논리만으로는 이해되지 않는 원리가 종교 영역 말고 다른 곳에서도 적용되는 것 같다.

그나마 이것들이 건강에 워낙 나쁘다는 인식이 널리 퍼졌고(특히 담배), 예전에 비해 집단 전체주의 똥군기 관행이 사그라든 덕분에 간접 흡연이니 술 강요니 하는 것도 많이 없어졌다.
성경의 잠 16:27 "그의 입술에는 타오르는 불 같은 것이 있느니라"이 과연 미래에 등장할 담배까지 저격한 말씀일까? 그럴싸해 보인다.

3. 일요일 결혼식

난 개인적으로는 일요일 정오 결혼식은 예수 믿는 사람은 오지 말라고 or 안 와도 된다고 대놓고 선언하는 거라고 간주한다. 오전 예배를 완전히 대놓고 생까라는 걸 어쩌라고..??
"왜 하필 저 때로 잡았어? 날 엿 먹이려고?" 같은 다른 아쉬움이나 감정이 들어가는 게 아니라, "아 그래? 난 시간· 장소가 안 맞아서 가지는 못하겠네. 어쨌든 결혼 축하해." 그냥 딱 그 이상도 그 이하도 아니라는 것이다. 외국 출장 가 있어서 못 가는 것과 동급으로.

그리고 그것처럼 남 결혼식 정도는 주일 예배를 빠질 명분이 되지 못한다는 것이다. 그걸 일일이 다 챙겨서 가고 예외를 전부/일부 인정해 버리면 예배 제대로 못 드린다.

마치 자동차 교통사고로 치면.. (1) 까방권이 성립할 정도로 불가피하지 않으며 그렇다고 (2) 형사처벌 될 정도로 고의· 악의적인 것도 아닌, 그냥 (3) 정당하지 않은 급차로 변경이나 급정거 정도에 대응한다.
길을 잘못 들었거나, 실었던 짐이 떨어졌다거나 해서 고속도로에서 멍청하게 어영부영 하다가 뒷차로부터 추돌 사고가 나는 거 말이다. 그건 앞차의 과실이 더 크게 잡힌다.

난 무슨 에릭 리들 같은 위인이 아니며, 율법적인 주일성수 덕후가 아니다. 다른 사람이 친구 결혼식 때문에 주일 오전 예배를 수시로 빠지는 걸 정죄할 생각도 없다. 그것과 별개로 나 본인은 남의 결혼식 정도로 예배 시간을 빼앗기고 싶지 않다.
무슨 길거리에서 복음 전해라, 거리설교 해라, 술자리 거부해라, 신앙을 지키기 위해 금전적인 손실을 감수해라 정도의 큰 risk가 필요한 일도 아니고, 원래 개인 사생활 시간대에 예배 드리는 시간 정도는 대외적으로 사수할 배짱이 어느 신자에게든 있어야 하리라고 여겨진다.

Posted by 사무엘

2019/04/15 08:33 2019/04/15 08:33
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1608

Trackback URL : http://moogi.new21.org/tc/trackback/1608

Leave a comment

Windows의 Region

Windows API에는 region(영역)이라는 일종의 자료구조 라이브러리가 있다. 얘는 2차원 래스터(픽셀/비트맵) 그래픽 공간에서 각 픽셀별로 "영역에 포함되냐 안 되냐"라는 일종의 '집합'을 표현한다.
그리고 운영체제는 이 자료구조를 이용하여 각종 그래픽이 그려지는 영역을 정한다. 즉, region은 클리핑(clipping) 영역을 표현하는 데 쓰인다는 것이다.

도스 시절의 여느 그래픽 라이브러리에도 간단한 사각형 영역에만 그림이 그려지게 하는 초보적인 수준의 클리핑 기능은 있었다. 하지만 Windows의 region은 여러 사각형이 겹친 것, 임의의 다각형, 원 등 아무 모양이나 표현하고, 그 영역 안에만 그림이 그려지게 만들 수 있다.

그도 그럴 것이 Windows 같은 GUI 운영체제라면 창들의 Z-order 같은 걸 구현하는 과정에서 밥 먹고 맨날 하는 짓이 정교한 클리핑일 수밖에 없게 된다. 뒤쪽에 있는 창 내용은 앞쪽에 있는 창의 영역을 침범하지 않고 그려져야 하기 때문이다. 그러니 그런 기능을 사용자들에게도 쓰라고 제공해 주는 게 결코 이상한 일이 아니다.

region은 가장 먼저, (1) 직사각형, 타원, 모서리가 둥근 직사각형, 다각형(CreatePolygonRgn, CreatePolyPolygonRgn)처럼.. 속이 닫힌 도형을 그리는 다양한 API를 통해 생성할 수 있다. 당연히 그 도형의 모양이 영역의 모양이 된다.

다음으로, GDI가 제공하는 기능인 (2) path로부터 region을 생성할 수 있다(PathToRegion). path란 마치 윤곽선 글꼴 글립처럼 직선(MoveTo, LineTo)과 곡선(PolyBezirTo)을 임의로 조합하여 어떤 궤적이나 경계선을 기술하는 자료구조이다. region과 달리 벡터 기반이며, 별도의 자료구조로 존재하는 게 아니라 DC의 내부 상태에 종속인 형태로 보관된다는 차이가 있다.

path를 사용하면 경계선이 베지어 곡선인 region을 만들 수 있으며, TextOut 같은 글자 출력 함수를 path에다 넣으면 임의의 글자의 윤곽선도 따서 고스란히 region으로 만들 수 있다. 커다란 두 글자를 포개 놓은 뒤, 겹치는 영역만 다른 색깔로 칠하는 게 region으로는 가능하다. 그 비결은 바로...

사용자 삽입 이미지

(3) CombineRgn이라는 함수를 통해 region 간에 일종의 집합 연산을 할 수 있기 때문이다. 두 region의 교집합, 합집합, 차집합을 구함으로써 더 복잡한 형태의 region을 만들 수 있다.

위의 그림을 보아라. 운영체제나 하드웨어 차원에서 제공되는 layer이나 alpha channel 합성 같은 걸 쓴 게 아니다. 옅은 회색(B), 짙은 회색(S), 검정(겹침)이 차지하는 영역을 2차원적으로 완전히 따로 떼어내서 서로 완전히 다른 색깔과 무늬로 칠할 수 있다. 뚝 떨어진 영역도 당연히 같이 감안해서 말이다. 이런 게 평범한 글자 찍기 API로는 가능하지 않을 것이다.
다만, region은 anti-aliasing을 지원하지 않는 boolean 흑백 자료구조이다 보니, 글자 경계가 거친 것은 아쉬운 점이며 요즘 그래픽 기술의 트렌드와 맞지 않다.

그리고 끝으로.. region은 내부 자료구조를 어느 정도 노출해 주고 있기까지 하다. 그래서 그걸 직통으로 저장하고 불러오는 식으로 생성할 수도 있다. 데이터를 얻는 함수는 GetRegionData이고, (4) 그걸로부터 region을 다시 생성하는 함수는 ExtCreateRegion이다.

어떤 방식으로 region을 생성했건, 얘는 내부적으로 크게 세 부류로 나뉜다. region을 생성하거나 받아들이는 함수들이 그 region의 유형을 리턴값을 통해 알려주기도 한다.

  • 아무 영역도 없는 공집합인 NULLREGION
  • 직교좌표 직사각형 하나로만 구성된 SIMPLEREGION
  • 그 외의 다른 모든 모양을 표현하는 COMPLEXREGION.. 얘는 내부적으로 2개 이상의 사각형, 아니 scan line들로 구성된다.

자연에서 관찰되는 힘이라는 것들이 중력이나 원자력과 관계 있는 게 아니면 나머지는 출처가 몽땅 전자기력이듯이(폭발력, 마찰력, 탄성, 자석, 정전기, 표면장력, 생물 근육 등등등..),
그리고 사람이 생성(...)되는 방식이 흙을 빚어서 직통, 여자의 씨 같은 극소수 예외를 제외하면 나머지 수십~수백 억의 인간들은 몽땅 남자의 씨 기반이듯이.. 그런 것처럼 region도 일상생활에서 보는 단순하지 않은 물건들은 몽땅 complex라고 생각하면 되겠다.

region이 내부적으로 구현된 방식의 특성상(벡터/오브젝트 기반이 아닌 비트맵/픽셀 스캔라인 기반) 무한을 구현할 수 있지는 않으니, 집합 연산에서도 not 연산인 여집합이 지원되지는 않는 걸 볼 수 있다. 차라리 이미 있는 집합끼리 차집합이 대신 지원되고 말이다.

region을 식별하는 핸들 내지 포인터 자료형은 HRGN이다. 그런데 Create...처럼 HRGN을 리턴값으로 주는 함수 말고, Get...Rgn, CombineRgn 이런 이름이면서 HRGN을 인자로 받는 함수들은... 이미 있는 HRGN에다가 값만 바꿔서 넣어 준다. 그런 함수를 쓰려면 null region 하나라도 미리 미리 생성해서 전해 줘야 한다.

그런데 Windows API에는 많고 많은 region 생성 함수들 중에 null region만을 달랑 생성하는 함수는 의외로 없다. 좌표가 모두 0인 직사각형.. CreateRectRgn(0,0,0,0) 이게 그냥 텅 빈 region을 생성하는 역할을 한다. 좀 교묘한 점이다.

그럼 이 region는 어떤 용도로 쓰이며, 할 수 있는 일이 무엇일까? 본인이 생각하기에 다음과 같다.

1. 단독

그냥 저거 자체만으로 뭔가 2차원 공간 상의 기하/집합 알고리즘 구현체로.. 다른 GDI API와의 연계 없이, 심지어 명령 프롬프트용 프로그램에서도 쓰일 수 있다. 펜, 브러시, 글꼴, 비트맵 같은 타 오브젝트들이 DC와의 연계 없이는 거의 쓸모없는 것과 굉장히 대조적이다.
하지만 region이 그렇게 단독으로 쓰이는 경우는 그리 많지 않아 보인다.

2. 창의 invalid 영역 표현

어떤 창의 앞을 가리던 다른 창이 없어지고 내 창의 내용이 다시 그려지게 됐을 때.. 그 이름도 유명한 WM_PAINT 메시지가 날아온다.
BeginPaint와 함께 제공되는 DC는 창 전체가 아니라 정확하게 다시 그려져야 하는 영역에만 그림이 그려지도록 클리핑 처리가 돼 있는데, 이 영역이 말 그대로 region으로 표현되며 GetUpdateRgn 함수를 통해 얻어 올 수 있다.

WM_PAINT 때 이 영역에 대해서 PtInRegion이나 RectInRegion을 적절히 호출하면서 그림을 그리면, 무식하게 화면 전체를 그리는 것보다 프로그램 성능과 반응성을 향상시킬 수 있다.
물론 DC 차원에서 클리핑 처리가 되는 것만으로도 화면 전체를 그리는 것보다는 속도가 향상되지만, 애초에 그리기 요청을 안 하고 CPU 계산을 안 하는 게 더 낫기 때문이다.

3. 내부 클리핑

운영체제뿐만 아니라 사용자 역시 임의의 region을 생성해서 클리핑 용도로 쓸 수 있다. 비트맵이 사각형 모양이 아니라 원 모양으로만 뿌려진다거나, 특정 글자 모양으로만 뿌려지게 할 수 있다는 것이다.
그렇게 하려면 HRGN을 DC에다가 지정하면 된다. 이것은 SelectObject로 해도 되고 SelectClipRgn으로 해도 된다. 완전히 동일하다.
단지, 클리핑을 해제하는 것은 SelectClipRgn로만 가능하다. HRGN 값으로 NULL을 전해야 하기 때문이다. null region은 그림이 전혀 그려지지 않게 하는 효과를 낼 테니까..

HRGN은 기술적으로는 HPEN, HBRUSH, HBITMAP, HFONT와 마찬가지로 여러 GDI 오브젝트 중 하나로 취급된다. 상술한 바와 같이 DC에 SelectObject 될 수 있으며, 소멸 함수가 DeleteObject인 것까지도 동일하다.
하지만 얘는 다른 오브젝트들과 달리 select나 get 될 때 내부 메모리가 복사될 뿐, 핸들값 자체를 주고 받지는 않는다. 즉, HRGN은

HRGN oldRgn = (HRGN)SelectObject(dc, newRgn);
(.....)
SelectObject(dc, oldRgn);

이런 식으로 운용되지 않는다는 것이다. 옛날 핸들값을 보관하고 되돌리는 식의 절차가 필요하지 않다.
DC와 region은 서로 따로 논다. 이렇게 설정한 뒤에 원래 있던 HRGN 핸들은 곧장 삭제해 버려도 된다.

본인은 MFC의 CGdiObject처럼 GDI 객체 핸들만 한데 뭉뚱그린 템플릿 클래스를 만들어서 쓰고 있다. (소멸자에는 DeleteObject가 있고..)
그런데 다른 오브젝트들은 template<T> Handle(T v=NULL) 이런 식으로 NULL이 default 인자인 생성자를 만들어서 초기화할 수 있는 반면,
HRGN에 대해서는 인자가 없는 경우에 대해 specialize된 생성자를 따로 만들어서 이때는 null region을 생성해 놓게 했다. 그래야 이놈을 region을 얻어 오는 다른 함수에다가 인자로 줄 수 있기 때문이다.

4. 칠하고 그리는 공간

그리고 region 자체가 도형을 나타내니 그 모양대로 클리핑이 아니라 내부를 칠하는 용도로 응당 활용할 수 있다. 내부를 칠하는 FillRgn과, 내부의 경계선을 그려 주는 FrameRgn이라는 함수가 제공된다.
흥미로운 것은 경계선을 그릴 때도 pen 대신 brush가 쓰인다는 것이다. region은 path와 달리 벡터 드로잉이 아니기 때문이다. 경계선은 그냥 픽셀 차원에서 색깔이 변하는 곳을 얼추 감지해서 표시해 주는 것일 뿐이다.

5. 창 자체의 외형

끝으로, region은 윈도우의 모양을 지정하는 용도로도 쓰인다. 통상적인 사각형 모양이 아니라 리모콘 같은 다른 물건처럼 생긴 프로그램 창, 현란한 스플래시 윈도우, 내부에 구멍까지 있는 윈도우.. 전부 SetWindowRgn 함수의 산물이다.
한번 SetWindowRgn에다 전해 준 HRGN은 이제 운영체제가 관리하기 때문에 사용자가 DeleteObject 하지 말아야 한다고 문서에 거듭 명시되어 있다.

SetWindowRgn를 지정하는 순간부터 그 창은 운영체제가 non-client 영역과 테두리 경계에 기본 제공하는 각종 테마와 반투명 프레임, 둥그런 테두리, 그림자 효과들로부터 완전히 열외된다. 그 대신 고전 테마의 완전 무미건조한 테두리만이 그려진다. 일반적으로는 당연히 아래처럼 그려질 프로그램 창이 위처럼 그려지게 된다는 뜻이다.

사용자 삽입 이미지

그런 창은 어차피 non-client 영역이 전혀 없이 외형을 사용자가 완전히 customize하는 형태로 쓰일 테니 말이다. 제목 표시줄과 테두리의 외형은 보급품 그대로이면서 중앙에만 region을 지정해서 총알 구멍 같은 게 숭숭 뚫린 프로그램 창 같은 건 만들 수 없다는 뜻이다.

보통은.. 공용 컨트롤 6.0 매니페스트가 없는 프로그램의 경우, 버튼 같은 컨트롤들이 구닥다리 고전 스타일로 그려지고 non-client 영역은 운영체제가 자동으로 쌈빡하게 그려 준다. (그림에서 아래 오른쪽) 그런데 SetWindowRgn을 지정하면 반대로 컨트롤들은 정상적으로 그려지는데 non-client 영역이 고전 스타일로 돌아간다는 게 흥미롭다.

단, 지난 Windows 2000부터는 SetWindowRgn가 아닌 다른 방법으로도 사각형 모양이 아닌 윈도우를 표현할 수 있게 되었다. 바로 layered window이다. WS_EX_LAYERED 스타일을 준 윈도우에다가 SetLayeredWindowAttributes 함수를 호출하면 (1) 이 창에 대해서 투명도를 지정할 수 있고, (2) 특정 RGB 값을 color key로 지정해서 그 색깔은 투명으로 처리할 수 있다. 배경색을 칠하는 것만으로 그 부위가 투명해지니, 번거로운 region보다 훨씬 더 편리해지기까지 했다.

과거 MS Office 97~2000 시절의 흑역사 중에는 'Office 길잡이'라는 "취지만 좋았다" 급의 물건이 있었다. 애니메이션 캐릭터가 화면에 나타나서 돌아다니는데.. 첫 도입되었던 97은 캐릭터가 사각형 창 안에 갇힌 형태였던 반면, 2000부터는 배경 없이 창이 시시각각 애니메이션 캐릭터 모양으로 변했다.

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

이게 Windows 2000에서는 하드웨어빨을 탄 layered window로 비교적 간편하게 구현됐던 반면.. 9x에서는 일일이 window region을 바꿔 가면서 동작했다. 그 밑의 창은 매번 WM_PAINT가 발생하면서 성능 페널티가 장난이 아니었을 것이다.

본인은 먼 옛날에 이런 프로그램도 구경한 적이 있었다. 실행하면 만화영화 그림체로 그려진 병아리 한 마리가 마치 저 Office 길잡이처럼 튀어나왔는데, 그냥 가만히 있는 게 아니라 각종 프로그램 창들 위를 돌아다녔다. 나름 중력도 구현했던지라, 마우스로 집어다가 공중에다 옮겨 놓으면 아래의 근처에 있는 창으로 떨어지기까지 했다. 내 기억이 맞다면 꽤 재미있는 프로그램이었는데.. 지금 인터넷으로 다시 검색하고 구할 길이 없다.

이 프로그램에 대해서 본인이 현재 기억하고 있는 건 아마 일본에서 만들어진 걸로 추정된다는 것, 그리고 무려 Windows 3.x용 16비트 프로그램이었다는 것이다. 그 열악한 Windows 3.x에서도 타이머를 걸어서 최소화 아이콘에다가 애니메이션을 구현하고, 창의 경계가 시시각각 곡선 윤곽으로 바뀌는 저런 액세서리 프로그램이 만들어지기도 했다.

이렇듯, SetWindowRgn을 이용해서 이런 재미있는 활용을 할 수 있는데.. 날개셋 한글 입력기에서 사각형이 아닌 모양의 창이 나타나는 곳은 마우스 휠을 눌렀을 때 나타나는 동그란 자동 스크롤 앵커가 유일하다.

사용자 삽입 이미지

에디트 컨트롤은 자동 스크롤 모드가 없고, MS 오피스 제품들은 동그란 테두리 없이 그냥 배경에다가 회색 화살표가 나타나는 듯하지만.. 마소에서 만든 웹 브라우저(IE, Edge)에서는 앵커 윈도우가 나타난다. 날개셋의 앵커 윈도우도 먼 옛날에 얘를 참고해서 만들어진 것이다. 맨 처음에는 region만 쓰다가 이내 layered window도 사용하도록 형태가 바뀌었다.

여담: 좌표계 관련 문제

아, region의 경계면과 관련해서 주의해야 할 점이 있다.
같은 좌표를 줬을 때, 직사각형은 pen으로 그려지는 테두리와 region의 영역이 픽셀 단위로 정확하게 일치한다. 다시 말해 같은 RECT rc에 대해서 CreateRectRgn + SetClipRgn을 한 뒤에Rectangle을 호출한 결과는 클리핑을 안 했을 때와도 동일하다.

하지만 타원(Ellipse vs CreateEllipticRgn)이나 폴리곤(Polygon vs CreatePolygonRgn) 같은 다른 도형에 대해서는 이것이 성립하지 않는다. region은 오른쪽과 아래 끝의 1픽셀이 미묘하게 잘린다.

//직사각형
CRgn rg; CRect rc(10, 10, 80, 80);
rg.CreateRectRgnIndirect(rc);
dc.SelectClipRgn(&rg); dc.Rectangle(rc);
rc.OffsetRect(40, 40); dc.Rectangle(rc);

//원
CRgn rg; CRect rc(110, 10, 180, 80);
rg.CreateEllipticRgnIndirect(rc);
dc.SelectClipRgn(&rg); dc.Ellipse(rc);
rc.OffsetRect(40, 40); dc.Ellipse(rc);

//폴리곤으로 표현한 직사각형
CRgn rg; POINT pt[4] = {
{10, 100}, {80, 100}, {80, 170}, {10, 170} };
rg.CreatePolygonRgn(pt, 4, ALTERNATE);
dc.SelectClipRgn(&rg); dc.Polygon(pt, 4);

이 코드를 실행한 결과는 다음과 같이 차이가 난다.

사용자 삽입 이미지

폴리곤으로 직사각형 좌표를 지정해 줘도, 아예 직사각형 전용 생성 함수를 줬을 때와 달리, region은 영역이 살짝 덜 생긴다. 그래서 그 region 안에서 동일 좌표로 도형을 직접 그려 보면 테두리의 오른쪽과 아래쪽이 잘린다.

이를 감안해서 원형 region을 생성할 때는 그리기 함수일 때보다 1픽셀 정도 더 크게 원을 그리면 잘리는 현상은 막을 수 있다. 하지만 그래도 그리기 함수와 region 함수는 경계 계산 결과가 서로 미묘하게 달라서 직사각형일 때처럼 깔끔하게 일치하는 모양이 나오지 않는다.
그러니 region 자체의 경계를 그려 주는 FrameRgn 함수를 대신 쓸 수밖에 없다. 허나, 얘가 그려 주는 테두리는 전문적인 원 그리기 함수에 비해 표면이 거칠며 별로 예쁘지 않다.

본인은 처음에 이런 특성을 몰라서 한동안 삽질을 했었다. 이럴 때도 region 대신 layered window는 순수하게 그리기 결과에 따라서 투명색을 자동으로 처리해 주니 더욱 유용하다.

Posted by 사무엘

2019/04/12 08:34 2019/04/12 08:34
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1607

Trackback URL : http://moogi.new21.org/tc/trackback/1607

Leave a comment

1. 재부팅 이벤트

본인은 지금까지 Windows가 시스템 종료/재시작/로그아웃 될 때.. 메시지에 즉각 응답하면서 정상적으로 돌아가는 프로그램이라면 종료 처리도 당연히 정상적으로 되는 줄로 알고 있었다.
사용자가 [X] 버튼이나 Alt+F4를 눌러서 종료할 때와 완전히 동일하게 말이다. WM_CLOSE에 이어 WM_DESTROY, WM_NCDESTROY가 날아오고, WM_QUIT이 도달하고, message loop이 종료되고, MFC 프로그램으로 치면 ExitInstance와 CWinApp 소멸자가 호출되고 말이다.

왜냐하면 시스템이 종료될 때 발생하는 현상이 언뜻 보기에 정상적인 종료 과정과 동일했기 때문이다. 저장되지 않은 문서가 있는 프로그램에서는 문서를 저장할지 확인 질문이 뜨고, 운영체제는 그 프로그램 때문에 시스템 종료를 못 하고 있다고 통보를 한다. 좋게 WM_CLOSE 메시지를 보내는 걸로 반응을 안 하는 프로그램에 대해서만 운영체제가 TerminateProcess 같은 강제 종료 메커니즘을 동원할 것이다.

그런데 알고 보니 그게 아니었다.
정상적인 종료라면 ExitInstance 부분이 실행되어야 할 것이고 프로그램 설정들을 레지스트리에다 저장하는 부분도(본인이 구현한..) 실행돼야 할 텐데, 내 프로그램이 실행돼 있는 채로 시스템 종료를 하고 나니까 이전 설정이 저장되어 있지 않았다.

꼭 필요하다면 WM_ENDSESSION 메시지에서 사실상 WM_DESTROY 내지 ExitInstance와 다를 바 없는 cleanup 작업을 해야 할 듯했다. 뭐, 날개셋 한글 입력기에서 이 부분이 반영되어 수정돼야 할 건 딱히 없었지만 아무튼 이건 내 직관과는 다른 부분이었다.

시스템이 종료될 때 발생하는 일은 딱히 디버거를 붙여서 테스트 가능하지 않다. =_=;; 로그 파일만 기록하게 해야 하고, 매번 운영체제를 재시작해야 하니 가상 머신을 동원한다 해도 몹시 불편하다. 꽤 오래 전 일이 됐다만, 날개셋 외부 모듈이 특정 운영체제와 특정 상황에서 시스템 종료 중에 운영체제 시스템 프로세스 안에서 죽는 문제가 발생해서 디버깅을 한 적이 있었다. 몹시 골치 아팠었던 걸로 기억한다.

2. 파일의 동등성 비교

파일 이름을 나타내는 어떤 문자열이 주어졌을 때,

  • 상대 경로(현재의 current directory를 기준) vs 절대 경로
  • 과거 Windows 9x 시절이라면 ~1 같은 게 붙은 8.3 짧은 이름 vs 원래의 긴 이름
  • 대소문자 (Windows는 대소문자 구분이 없으므로. 그런데 이것도 A~Z 26자만 기계적으로 되나? 언어별로 다른 문자의 대소문자는?)
  • 그리고 옵션으로는 정규 DLL search path와 환경 변수

이런 것들을 몽땅 다~ 감안해서 다음과 비스무리한 일을 하는 가벼운 API가 좀 있으면 좋겠다. 보다시피 동일한 파일을 표현하는 방법이 굉장히 다양하기 때문이다.

  • 두 개의 파일 명칭이 서로 동일한 파일인지 여부를 판단. 당연히 파일을 직접 open/load하지 않고 말이다.
  • 그 파일의 대소문자 원형을 유지한 절대 경로. 일명 '정규화된' 이름을 되돌린다. 이게 동일한 파일은 물리적으로, 절대적으로 동일한 파일임이 물론 보장된다.
    참고로 Windows API 중에서 얼추 비슷한 일을 한다고 여겨지는 GetFullPathName이나 GetModuleFileName 함수는 절대 경로 말고 파일의 대소문자 원형 복원이 제대로 되지 않는다.
  • 혹은 그 파일의 시작 지점이 디스크에서 물리적으로 어디에 있는지를 나타내는 64비트 정수 식별자를 구한다. 포인터가 아니지만 파일의 동등성 여부 판단은 가능한 값이다. 정수를 넘어 UUID급이어도 무방함.

본인은 비슷한 목적을 수행하기 위해, 그냥 두 파일을 CreateFileMapping으로 열어 보고 리턴된 주소가 동일하면 동일한 파일로 간주하게 한 적이 있었다. 핸들 말고 MapViewOfFile 말이다. 본질적으로 동일한 파일이라면 운영체제가 알아서 같은 주소에다 매핑을 하고 레퍼런스 카운트만 증가시킬 테니까..
Windows 9x에서는 주소가 시스템 전체 차원에서 동일하겠지만 NT 계열에서는 한 프로세스 내부에서만 동일할 것이다.

하지만 내가 필요한 건 파일의 내용이 아니라 그냥 두 파일의 동등성뿐인데 이렇게 매핑을 하는 건 overkill 삽질 같다는 인상을 지울 수 없었다.
비슷한 예로, LoadLibrary도 같은 파일에 대해서는 같은 리턴값이 돌아온다. HMODULE도 오늘날은 핸들이 아니라 메모리 map된 주소이니까.. 다만, 오버헤드를 줄인답시고 LoadLibraryEx + LOAD_LIBRARY_AS_DATAFILE 이렇게 열어서는 안 된다. 그러면 로딩 방식이 크게 달라지더라.

3. JNI에서 문자열 처리하기

Java 언어는 JNI라고 해서 자기네 바이트코드 가상 머신이 아닌 C/C++ 네이티브 코드를 호출하는 통로를 제공한다.
프로그램 자체를 C/C++로 짜던 시절에는 극한의 성능을 짜내야 하는 부분에 어셈블리어를 집어넣는 게 관행이었는데.. 이제는 일반적인 코딩은 garbage collector까지 있는 상위 계층에서 수행하고, 극한의 성능을 짜내야 하는 부분에서만 C/C++ 코드를 호출한다는 게 흥미롭다.

JNI는 그냥 언어 스펙에 가까운 광범위한 물건이다. Windows 환경에서는 그냥 Visual C++로 빌드한 DLL이 export하는 함수를 그대로 연결할 수도 있다. 물론 그 DLL을 빌드하기 위해서는 Java SDK에서 제공하는 jni 인터페이스 헤더와 static 라이브러리를 사용해야 한다.
한편, 안드로이드 앱 개발에서 쓰이는 NDK는 JNI 스펙을 기반으로 자체적인 C++ 컴파일러까지 갖춘 네이티브 코드 빌드 도구이다.

Java의 문자열은 JNI에서는 jstring이라고 내부 구조를 알 수 없는 자료형의 포인터 형태로 전달된다. C++에서는 UTF-8과 UTF-16 중 편한 형태로 바꿔서 참조 가능하다.
UTF-8로 열람하려면 JNIEnv::GetStringUTFChars를 호출하면 된다. 길이를 알아 오려면 GetStringUTFLength부터 호출한다. 전해받은 문자열 포인터는 ReleaseStringUTFChars로 해제한다.

그 반면, UTF-16 형태로 열람하려면 위의 함수 명칭에서 UTF를 빼면 된다. GetStringChars, GetStringLength, ReleaseStringChars의 순이다. Java가 내부적으로 문자를 2바이트 단위로 처리하기 때문에 이들이 주로 취급하는 자료형은 jchar*이다. 그러니 얘는 char16_t 자료형과 호환된다고 간주해도 좋다. 참고로 wchar_t는 NDK 컴파일러의 경우 4바이트로 처리되더라.

UTF-16이나 UTF-8이나 다 UTF이긴 마찬가지인데, Java는 변별 요소인 8을 생략하고 함수 이름을 왜 저렇게 지었나 개인적으로 의구심이 든다. 물론 GetStringChars는 Java가 내부적으로 문자열을 원래부터 2바이트 단위로 처리하다 보니 우연히 UTF-16과 대응하게 됐을 뿐, 대놓고 UTF-16을 표방했던 건 아닐 것이다. 뭐, 이제 와서 그 체계를 바꾸는 건 불가능하고 "자바 문자열 = 2바이트 단위"는 완전히 고정되고 정착했지만 말이다.

또한 GetStringChars는 GetStringUTFChars와 달리 굉장히 치명적으로 불편한 단점이 하나 있다. 바로.. 변환된 문자열이 NULL-terminated라는 보장이 없다는 것이다!
그래서 본인은 이 포인터를 사용할 때 메모리를 n+1글자만치 또 할당해서 null문자를 추가해 주는 매우 번거로운 두벌일을 하고, 아예 클래스를 이렇게 따로 만들어야 했다. 좀 개선의 여지가 없으려나 모르겠다.

class CJstrToString16 {
    JNIEnv *_ev;
    jstring _jstr;
    const jchar *_ret;
    char16_t *_arr;
public:
    CJstrToString16(JNIEnv *ev, jstring js): _ev(ev), _jstr(js) {
        jsize n = ev->GetStringLength(js);
        _ret = ev->GetStringChars(js, NULL);
        _arr = new char16_t[n+1];
        memcpy(_arr, _ret, n*sizeof(char16_t));
        _arr[n] = 0; //고작 요거 하나 때문에..
    }
    ~CJstrToString16() {
        ev->ReleaseStringChars(_jstr, _ret);
        delete[] _arr;
    }
    operator const char16_t*() const { return _arr; }
};

4. Visual C++의 STL

C++은 타 프로그래밍 언어들과 달리, 심지어 전신인 C와도 달리, 언어가 개발되고 나서 자신의 특성을 잘 살린 라이브러리가 언어 차원에서 붙박이로 곧장 제정되지 않았던 모양이다. 그래서 각 컴파일러들이 중구난방으로 파편화된 형태로 라이브러리를 제공해 오다가.. 표준화라는 게 1990년대 말이 돼서야 논의되기 시작했다.

템플릿이 추가되어 C++에서도 제네릭, 메타프로그래밍이라는 게 가능해진 뒤부터 말이다. 처음에는 자료구조 컨테이너 위주로 STL이라는 이름이 붙었다가 나중에는 그냥 C++ library가 된 걸로 본인은 알고 있다.

Windows용으로 가장 대중적인 C++ 컴파일러야 두 말할 나위 없이 MS Visual C++이다. 얘는 거의 20여 년 전 6.0 시절부터 P.J. Plauger라는 사람이 구현한 C++ 라이브러리를 제공해 왔다. C 라이브러리와 달리 C++ 라이브러리는 소스가 비교도 안 될 정도로 복잡하고 난해하다는 것(암호 같은 템플릿 인자들..=_=), 그리고 저렇게 마소 직원이 아닌 개인 이름이 붙어 있다는 게 인상적이었다. 2000년대 초까지만 해도 휴렛-패커드라는 회사명도 주석에 기재돼 있었다.

P.J. Plauger는 현재는 Dinkumware라고 C++ 라이브러리만 전문적으로 관리하고 라이선스 하는 회사를 설립해 있다. 나이도 생각보다 지긋한 듯..
그런데 이런 세계적인 제품에 들어가는 라이브러리가.. 성능이 의외로 시원찮은가 보다. Visual C++이 제공하는 컨테이너 클래스가 유난히도 느리다고 까이는 걸 여러 사이트에서 봐 왔다.

최근에는 본인 직장의 상사마저도 같은 말씀을 하시기에 "헐~!" 했다. 업무상 필요해서 string, set, map 등을 써서 수십, 수백 MB에 달하는 문자열을 분석하는 프로그램을 돌렸는데, 자료 용량이 커질수록 속도가 급격히 느려져서 자료구조를 직접 새로 짜야 할 판이라고 한다.

난 개인적으로는 C++ 라이브러리를 거의 사용하지 않고, 더구나 그걸로 그 정도까지 대용량 작업도 해 보지 않아서 잘 모르겠다. 그 날고 기는 전문가가 만든 코드에 설마 그런 결함이 있으려나? 아니면 컴파일러의 최적화 문제인지?

글쎄.. 이런 게 있을 수는 있다. MFC의 CString은 그냥 포인터와 크기가 동일하며 값으로 전할 때의 reference counting도 처리한다. 그러나 std::string은 자주 쓰이는 짧은 문자열을 번거로운 heap 메모리 할당 없이 빠르게 취급하기 위한 배열까지 내부에 포함하고 있다. 이런 특성을 모르고 std::string도 함수에다 매번 value로 전달하면 성능에 악영향을 줄 수밖에 없다.

그런 식으로 임시 객체가 쓸데없이 생겼다가 사라지는 구조적인 비효율이 C++ 라이브러리에 좀 있는 걸로 들었다. R-value 참조자 &&가 도입된 것도 vector의 내부 처리에서 그런 삽질을 예방하는 근거를 언어 차원에서 마련하기 위해서라지 않는가? 그리고 Visual C++이 그런 비효율을 보정하는 성능이 좀 시원찮다거나 한 것 같다. 전부 다 그냥 추측일 뿐이다.

그러고 보니 cout<<"Hello world"가 printf("Hello world")보다 코드 오버헤드가 작아지는 날이 과연 올지 모르겠다. 이것도 그냥 떡밥인 건지..?? =_=;;

Posted by 사무엘

2019/04/09 08:32 2019/04/09 08:32
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1606

Trackback URL : http://moogi.new21.org/tc/trackback/1606

Leave a comment

요즘 컴퓨터 프로그램들은 상업용이라 해도 과거처럼 디스켓이나 씨디가 담긴 패키지 박스의 형태로 배포되는 경우가 거의 없어졌다. 바이너리의 배포 자체는 인터넷으로 하며, 패키지가 있다 해도 그 안에는 시리얼 번호 쪽지 정도나 달랑 들어있다. 그 뒤, 사용자가 구매한 카피 개수만큼만 프로그램을 동시에 구동하고 있는지, 사용 기한이 경과하지 않았는지 같은 인증은 인터넷으로 진행한다.

정식 사용자가 확인되지 않은 프로그램은 일단 평가판 모드로 동작한다. 정품 인증이 안 됐고 평가판 기간도 경과했다면 그 다음부터는 기능 제한 모드로 동작한다. 문서나 데이터를 취급하는 업무용 프로그램이라면 이제 문서를 편집할 수 없고 일종의 viewer 형태로만 동작하게 된다.

과거에는 소프트웨어 개발사들이 사용자에게 자기 제품의 기능을 자랑하는 한편으로 정품 구매에 대한 동기를 부여하기 위해 셰어웨어, 평가판, 데모 같은 것을 따로 배포하곤 했다.
하지만 지금은 인터넷이 워낙 발달한 덕분에.. subset 구분 없이 전체 제품을 통째로 뿌린다. 그 뒤 제품을 구입하고 해금 비밀번호/일련번호를 받은 사용자에게만 전체 기능이 제공되도록 한다. 아래아한글, MS Office 같은 거대한 프로그램들도 이제는 다 이런 식으로 동작하고 있다.

과거에는 그런 일련번호를 수학 공식을 기반으로 생성하곤 했다. 하지만 오프라인 환경에서 소프트웨어적인 알고리즘에만 의존하는 copy-protection은 역공학을 통해 뚫릴 수 있다. 마치 주민 등록 번호 자동 생성기처럼 말이다. 어둠의 경로를 개척하는 사람들이 이만저만 똘똘한 게 아니기 때문이다.

하지만 인터넷이 소프트웨어의 배포와 불법 복제만 편하게 만든 건 아니며, 까놓고 말해 개발사가 사용자의 사용 패턴을 미주알고주알 파악하는 것도 더 용이하게 만들었다. (뭐, 서버 유지 비용은 부담해야 하지만..) 제아무리 클라이언트 프로그램을 복제하고 뿌려도 온라인 게임을 돈 안 내고 즐기는 건 불가능하며, 스타크래프트 불법 복제 립버전으로 배틀넷 접속은 할 수 없다. 또한, 주민 등록 번호는 생성하더라도 방대한 DB에 일일이 접속하는 실명 인증은 수학 공식만으로 뚫을 수 없지 않던가? 그런 식으로 창과 방패는 발전하는 것 같다.

물론 업무용 프로그램들은 온라인 게임과 달리 업데이트 체크나 인증을 할 때만 인터넷에 접속하지, 나머지 동작은 전부 어차피 오프라인에서 행해지는 게 대부분이다. 그런 부류라면 실행 파일을 분석해서 인증을 시도하는 부분만 변조하고 크랙해 버릴 수도 있다. 파일이 전부 암호화되지 않고 헤더에만 암호가 기록돼 있다면 그 부분만 건너뛰어 버리면 되듯이 말이다. 그렇기 때문에 오프라인에서의 소프트웨어 보안도 예나 지금이나 여전히 필요하다.

이렇게 소프트웨어의 정품 사용 여부를 파악하기 위해서 반드시 필요한 절차가 있다. 바로 프로그램이 돌아가고 있는 기기 내지 제품의 사용자를 중복 없이 유일하게 식별하는 것이다!
매번 변하는 난수 씨앗이야 그냥 현재 시각을 기반으로 생성한다고 하지만, 한 컴퓨터에만 고유하게 적용되는 시리얼 키 같은 걸 생성하려면 전세계에서 유일하고 불변하고 전무후무한 식별 번호가 하드웨어 차원에서 부여되어 있어야 한다.

하다못해 예전에 도스용 게임 중에서도 저장 기능이 없는 대신, 각 레벨별로 암호 코드가 부여되는 게 있었다. 그 코드값을 알면 나중에 상위 레벨에서부터 게임을 시작할 수 있다.
그런데 문제는 그 코드값이 컴퓨터마다 제각각으로 생성된다는 것.. 그러니 매 컴퓨터에서 게임을 새로 시작해서 상위 레벨에 직접 진입을 해야만 코드값을 알 수 있었다.

그리고 어떤 소프트웨어가 정품 인증을 받았다거나, 셰어웨어의 경우 등록판이 생성되었는데.. 그 인증 정보는 레지스트리나 파일 형태로 저장되곤 한다. 물론 꼼꼼하게 암호화해서 말이다.
그 인증 정보에는 당연히 특정 컴퓨터의 식별자도 들어있어야 할 것이다. 그래야 그 인증 정보만 다른 컴퓨터에다가 슬쩍 복사해서 집어넣더라도 명의가 도용되지 않을 테니 말이다.
이런 식으로 컴퓨터의 고유 식별자는 프로그램 개발자의 입장에서는 매우 다양하게 활용될 수 있다.

자동차에는 외부에 노출된 번호판과 별개로, 자동차 껍데기 자체를 식별하는 차대 번호라는 게 있어서 엔진룸이나 도어 한구석에서 확인할 수 있다.
노트북 PC는 시리얼 번호가 밑바닥에 적혀 있다. 그리고 스마트폰도 기기를 식별하는 고유 번호가 있는 건 마찬가지이다. 사용자를 식별하는 USIM과는 당연히 별개로 말이다.

그런데 PC는 컴퓨터를 유일하게 식별하는 깔끔한 단일 통합 메커니즘이 의외로 존재하지 않는다.
먼 옛날에 펜티엄 3~4 시절에는 CPU의 일련번호를 얻어 오는 명령이 있었던 듯하나.. 예제 코드가 어셈블리어여서 이식성이 전혀 없으며, 요즘 CPU에서는 통하지도 않는다고 한다.

컴퓨터를 식별하기 위해서 지금까지 제일 만만하게 쓰여 온 방법은 맥 어드레스(mac address)라는 48비트짜리 숫자이다. 요즘은 휴대전화 번호가 사람을 식별하는 준 주민 등록 번호나 마찬가지이지 않는가? 그것처럼 통신망에서의 주소는 기기 식별 용도로 나쁘지 않은 선택이다.
하지만 얘를 쓰기에는 요즘 컴퓨터 네트워크는 계층과 종류가 너무 다양해졌으며, 사용자가 값을 변조도 그리 어렵지 않게 할 수 있기 때문에 여러 모로 약발이 다했다.

하드웨어적인 방법에만 너무 의존하면.. 사용자가 램을 더 달거나 하드디스크를 교체한 것만으로 프로그램 정품 인증이 실패하는 불상사가 벌어진다. 도대체 한 컴퓨터의 정체성을 결정하는 것이 무엇인가 하는 본질적인 고민에 부딪히게 된다.
소프트웨어적인 방법으로는 HKEY_LOCAL_MACHINE 상에 있는 Windows의 product ID라든가 Machine GUID가 있는데.. 이것은 변조하기 쉽고 운영체제를 다시 설치하는 것만으로도 무력화될 수 있는 게 약점이다.

최근엔 본인도 이런 쪽으로 고민할 일이 좀 있었다. 그러다가 WMI(Windows Management Instrumentation)라는 DB인지 API인지.. 정체를 알 수 없는 방대한 물건을 최근에야 난생 처음으로 접했다. 여기에 시스템 정보와 관련된 것들이 다 있었다. 하드디스크의 시리얼 번호, 마더보드의 시리얼 번호, 뭐 별별 것까지 다.. 그야말로 끝판왕이었다.

그 중 Win32_ComputerSystemProduct라는 클래스에 있는 uuid 값이.. SMBIOS, 즉 펌웨어 레벨에서 새겨져 있는 불변 유일한 컴퓨터 식별자 역할을 얼추 하겠다는 결론을 내리게 됐다. 최소한 맥 어드레스보다는 더 믿을 만하지 않을까? 명령 프롬프트에서는 wmic csproduct get uuid라고 하면 얻을 수 있다.

WMI에 접근하는 건 C#에서는 꽤 간단하고 쉽게 할 수 있어 보이던데 C++에서는 COM을 초기화하고 온갖 복잡한 인터페이스를 몇 단계씩 생성해야만 가능했다. DB 아니랄까봐, COM으로도 모자라서 팔자에 없는 SQL 쿼리까지 날려야 되더라! SELECT * from Win32_ComputerSystemProduct 같은 식으로 말이다.
누가 클래스 라이브러리 하나 만들어 놓은 것조차 없는 듯... 저 GUID 하나만 달랑 얻어 오는 용도로 쓰기에는 낭비가 꽤 심해 보인다.

Windows와 달리 mac 계열은 하드웨어/소프트웨어가 워낙 딱딱 들어맞는 일체형이니 저 정도의 복잡한 고민은 필요 없을 듯하다. 시스템 정보를 보면 나오는 시리얼 번호와 하드웨어 UUID만으로 식별과 관련된 모든 고민이 끝이지 않을까?
게다가 gethostuuid라는 함수 한 방으로 그 값을 바로 구할 수 있었다.

이미 유비쿼터스니 사물 인터넷 IoT니 뭐니 하면서 운영체제 불문하고 수많은 기기들이 인터넷에 접속하고 있으며, 그에 맞춰서 주소 공간이 월등히 넓어진 ipv6도 서서히 보급되고 있다. ipv6는 주소 공간의 크기가 UUID의 그것과 동일한 128비트이다.

그러니 Windows/mac, 그리고 안드로이드/iOS를 불문하고 전세계 전무후무 유일불변이 보장되는 기기 식별자 같은 것도 제정되지 않을까 싶다. 이미 제정돼 있는데 본인이 아직 모르는 것일 수도 있겠지만, PC 한정으로는 내가 알기로 딱 떨어지는 답은 아직까지 없다. 심증에 속하는 여러 정황상의 단서들을 모아서 물증인 것처럼 편의상 활용하고 있을 뿐이다.

Posted by 사무엘

2019/04/06 08:35 2019/04/06 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1605

Trackback URL : http://moogi.new21.org/tc/trackback/1605

Leave a comment

1. 옛날 언어의 간결함

예전에도 한번 언급한 적이 있었지만.. 세상에 생명의 기원보다도 더 알 수 없는 게 바로 언어의 기원이다.
먼 옛날, 최초의 언어가 어떠했는지는 문헌 기록도 음성 녹음도 없고, 아예 문자조차 없으니 제대로 알 길이 없다. 이런 게 저절로 우연히 생겨날 수는 없다고 믿어 버리면 증명도 반증도 할 수 없고 그냥 개인 신념의 영역이 된다.

언어별로 차이가 있긴 하겠지만, 대체로 고대 언어는 현대의 언어보다 문법이 더 복잡하고 불규칙도 더 많고, 사용되는 음운도 더 다양했으리라고 추측된다. 그런데 한편으로는 반대로 옛날 언어가 어휘나 표현이 더 간결한 것도 있었다.

(1) 예를 들어.. 영어 고어에는 before보다 더 짧은 ere(air, heir와 같은 '에어')가 있고.. enemy보다 더 짧은 foe가 있다. 그리고 뻔한 문맥에서 목적어 같은 걸 생략도 많이 했다. 아래의 KJV 구절을 살펴보자.

  • Abimelech king of Gerar sent, and took Sarah. (창 20:2)
  • Bring these men home, and slay, and make ready. (창 43:16)

'사람을 보내어'인데 그냥 sent를 자동사인 듯이 썼으며
'가축을 잡아서'인데 그냥 slay 한 단어로만 씨크하게 표현했다.

(2) 그런데 영어 이전의 성경의 언어였던 히브리어· 그리스어 레벨에서는 이런 자비심 없는 축약이 더 많았던 모양이다.
그래서 KJV 영어 본문에서 이탤릭체 처리된 단어들을 찾아보면.. 없으면 단순히 문법적으로만 어색하거나, 아까 사람 내지 가축처럼 어렴풋이 유추 가능한 정도를 넘어서 뜻이 완전히 달라지는 것들도 있다.

시 12:5 끝부분의 "I will set [him] in safety [from him that] puffeth at him."에서 []로 둘러싸인 부분이 전부 이탤릭이다. 도대체 히브리어 원어 원문은 얼마나 암호처럼 짧게 기록됐길래 영어에서 저런 목적어와 수식어를 창작해서 집어넣어 줘야 했는지가 궁금해진다. (물론 KJV 외의 타 성경들도 동일하게 저렇게 번역했음)

(3) KJV는 they라는 짤막한 단어를 3인칭 복수 대명사로도 쓰고, people 같은 '일반적인 사람' 용도로도 쓴다. 이것 자체는 현대 영어에서도 존재하는 관행이지만, KJV는 중의성· 모호성이 느껴지기도 할 정도로 they를 즐겨 쓰는 감이 있다.
왕하 19:35를 보면.. "they가 아침에 일어나 보니 they는 모두 죽은 송장이 되어 있었더라"처럼.. 서로 다른 대상에 대해서도 똑같은 they가 쓰인다.

출 20:13 "살인하지 말라"도 타 성경들은 murder 정도를 넣었지만 KJV만은 그냥 짧은 kill이다.

(4) 영어를 비롯한 성경 언어 쪽 얘기가 길어졌는데, 반대편의 한국어도 마찬가지이다. 훈민정음 서문이라든가 이 윤탁 한글 영비 같은 걸 보면.. "영한 비라. 거운 사람은 재화를 입으리라" 말이 굉장히 짧다는 생각이 들지 않는가?
요즘 같으면 못해도 "이것은 신령한 비입니다. 이 비를 무너뜨리는 사람은 재앙을 당할 것입니다" 정도로는 풀어서 쓸 텐데? 띄어쓰기가 없는 고어체를 감안하더라도 주어 생략에다 '거우다?'라는 짤막한 단어.. 뭔가 현대 한국어의 화자는 알지 못하는 옛 한국어의 면모인 것 같다.

2. 의존명사

한국어에는 의존명사라는 게 있다. '리', '수' 같은 건 분명 고유한 뜻과 뉘앙스가 있긴 한데, 그게 구체적으로 뭔지를 설명해 보라고 하면 난감하다. 얘들은 '-ㄹ' 꼴로 활용된 용언으로부터 수식을 받은 바로 다음에만 등장하며(그럴 리, 할 수..), 특히 '리' 다음에는 '없다'만 쓰인다.

어처구니, 어이 같은 단어는 그런 통상적인 의존명사에 속하지는 않지만.. 뒤에 붙는 용언이 답정너 너무 뻔하고 다른 형태로 쓰이는 일이 없다시피하다. 그래서 '어이없다, 어처구니없다'가 그냥 한 단어로 인정될 지경이다. '쓸데없다'처럼 말이다.

한국어 맞춤법과 띄어쓰기가 너무 어렵고 일관성이 부족하다고 원성이 자자하지만.. 한국어가 단어와 형태소의 경계를 구분하는 게 그만치 어렵다. 이것 때문에 사전 편찬자와 국어 문법학자들도 고충이 많다. 용언에 극도로 제한된 뻔한 형태로만 활용되는 불완전동사가 있는 것만큼이나(더불다, 가로다, 달다) 체언에는 아주 제한된 형태로만 쓰이는 의존명사 같은 물건이 있는 셈이다.

그런데.. 이렇게 제한된 형태, 관용구 형태로만 쓰이는 명사가 영어에도 있는 것 같다. 유익· 편의라는 뜻인 sake 내지 behalf 같은 단어 말이다. 얘들은 오로지 one's sake, ?n behalf of .., for the sake of 형태로만 쓰이고 단독 내지 다른 형태로 쓰이는 일이 없다. 이것 말고 다른 예도 있지 싶다.

3. 일관성을 찾을 수 없는 혼돈의 카오스

(1) 외래어 표기법의 노답 문제

  • 자음 음절 경계: 플룻 플루트 로보트 백 태그..;; 답이 없다. ㅡ는 음가가 참 불분명한 모음이다.
  • 장모음: 윈도우 보우 리모트 보트 스노우.. [ou]라는 영어 장모음은 u를 무시하고 '오'로만 표기하는 게 원칙이지만 snow나 window 같은 단어는 여전히 '우'까지 표기한 형태가 더 익숙하다.
  • 모음 경계: washer는 와셔일까, 워셔일까? ㅏ~ㅓ, ㅗ~ㅓ 경계가 의외로 헷갈린다.

(2) 한글 맞춤법 및 발음에서 노답 문제

  • 사잇소리와 사이시옷: 비빔밥/볶음밥 중에서 왜 전자만 밥이 '빱'으로 바뀔까? 물고기/불고기 중에서 왜 전자만 '꼬' 소리가 날까? '김밥'의 발음은 밥과 빱 중에 무엇이 더 바람직할까?
  • 띄어쓰기: 한자어 복합명사들의 띄어쓰기부터가 아주 모호하다. 또한, 순우리말 중에도 '잘 만 듯 못' 요런 어절들은 단어도 되고 접사도 되기 때문에, 뒤에 '+하다' 같은 게 이어질 때 띄어쓰기 여부가 아주 구리다.

4. ㅐ와 ㅔ의 발음

이건 한국어 음운 체계에 남아 있는 희대의 미스터리이다.
원래 '아 다르고 어 다르다'만큼이나, I와 you를 구분할 정도로 완전히 다른 소리였는데 어쩌다가 요즘 사람들이 절대로 구분하지 못하는 소리의 쌍으로 전락했나 모르겠다. 서로 다르게 발음도 못 하고, 알아듣지도 못한다. 장음· 단음 구분이 망가진 것처럼 말이다.

요즘 통용되는 그 소리는 원래의 ㅐ도, ㅔ도 아닌 중간의 소리라고들 한다. 그런데 그 소리가 영어나 일본어에서도 쓰이는 보편적인(?) 소리인 건지도 모르겠다.
ㅐ/ㅔ뿐만 아니라 ㅒ와 ㅖ의 구분도 완전히 사라졌으며, ㅙ/ㅞ/ㅚ도 서로 변별력을 완전히 상실했다. 덕분에 재련과 제련, 결재와 결제, 제제와 제재 같은 한자어의 표기도 굉장히 헷갈리게 되었다.

한글이 처음 창제되던 당시에는 저 모음들이 어떻게 구분되어 발음되었는지.. 몇백 년 전 사람을 만나서 물어 보고 싶기라도 한 심정이다.

5. 사라져 가는 순우리말

까닭(이유), 달걀(계란), 뭍(육지, 땅) 같은 순우리말 단어는 한 1990년대 초반까지만 해도 방송과 도서에서 종종 접할 수 있는 단어였는데 갈수록 용례가 줄어들고 있는 게 보인다. 특히 '뭍'의 경우, 옛날에 전래동화 책에서 봤던 기억이 남아 있기도 하지만 이제는 사전에서나 찾을 수 있는 단어로 전락했다.

이런 식으로 '미덥다, 미쁘다, 미련하다' 같은 단어도 사라지는 것 같다. 어째 다 '미'짜로 시작한다는 공통점이 있다.
콩팥은 신장에 밀려서, 허파도 폐에 밀려서 앞날을 장담하기 어려워 보인다.
지금 세대는 알아듣기라도 하지만 다음 세대 애들한테는 완전히 듣보잡이 되겠지?

Posted by 사무엘

2019/04/03 08:35 2019/04/03 08:35
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1604

Trackback URL : http://moogi.new21.org/tc/trackback/1604

Comments List

  1. 신세카이 2019/04/13 21:16 # M/D Reply Permalink

    맞춤법 같은 경우는 어느 정도 재정립이 필요하다고 판단됩니다
    언어생활에서 문자의 경우 쓸데없이 맞춤법이 복잡해서는 되고
    일관성과 규칙성이 있어야 할 텐데
    이런 거 있잖아요 본동사 뒤에 보조동사에서
    아 어 다음은 띄어쓰는 게 원칙이지만 붙여쓰는 것도 허용한다
    허용할 거면 아예 다 붙여쓰자고 하든지 아니면 허용하지 말든지

    또 대부분 사람들이 맞춤법을 잘 지키지 않드라고요
    모두가 지킬 수 없는 신호등이 있다면 모두가 그 신호등에 맞추는 게 아니라
    그 신호등을 대부분이 맞출 수 있게 바꾸는 게 맞겠죠

    일본어는 띄어쓰기가 아예 없고 로마자를 쓰는 나라는 대부분 단어 별로 띄어쓰죠

    언어에서 중요한 것은 청각적 분별력인데 이것에 문제가 되지 않는다면
    꼭 순우리말이 아니여도 상관없다고 판단됩니다
    이미 한국어는 한자의 영향을 많이 받아서 아닌 경우도 많지만 한자를 알면
    단어를 이해하기에 도움이 되는 것도 일부분 사실이긴 합니다
    그렇다고 한자를 같이 표기하자는 것은 엇나간 것이고
    스마트폰으로 디지털화 된 시대에 바람직하지 않겠죠

    그리고 언어는 그 사회 구성원들의 가치관이 스며들어 있는데
    한국어에서 '우리'라는 단어를 영어에서 '나'가 들어갈 자리에 많이 쓰느데
    이것은 한국인들이 자신의 정체성을 스스로 정립하지 않고
    자신이 속한 집단에 투영하는 것을 나타내는 듯 합니다
    저는 우리라는 단어를 잘 사용하지 않습니다
    내 집 내 회사 내 팀 이라고 말하죠
    또 다르다 와 틀리다를 구분하지 않는 것은
    나와 다른 의견을 틀린 의견으로 간주하는
    남이 나와 다름을 인정하지 않는 집단주의적 사고가 들어 있는 거 같습니다

    그리고 쓸데없이 높임법이 발달된 것도
    존중의 의미보다는 남과 나를 동등한 인간으로 대하지 않고
    서열을 매기는 성리학적 세계관이 들어있는 것 같다는 느낌도 받습니다
    영어권처럼 그냥 이름을 부르던지 상대를 you라고 편하게 부르는 게
    저 개인적으로는 더 좋습니다

    저는 제 직장 상사나 사장도 제 위에 있는 사람이 아니라
    그냥 거래 관계라고 생각하거든요

    그런데 언어라는 것이 혼자서만 좋다고 할 수 있는 게 아니기에
    사회의 변화에 맞게 언어도 변하고
    개인은 그 흐름에 맞춰야겠죠

    1. 사무엘 2019/04/14 00:18 # M/D Permalink

      여러 좋은 의견에 감사드립니다.

      청각적 변별이 중요하니, 괜히 잘 쓰이고 있는 외래어들을 어설프게 순화할 게 아니라 장(chapter) 같은 동음이의어가 너무 많은 단음절 한자어나 대체 용어를 만들어야 할 것입니다.
      그리고 중국과 일본어에서 상용 한자의 한계를 정했듯이.. 우리말 한자어들도 한글로만 표기했을 때 의미 파악에 지장이 없는 것의 한계를 정하고 나머지 듣보잡들은 실생활에서는 쓰지 말거나 순화해서 쓰는 식으로 정리가 필요하다고 생각됩니다.

      '나-우리', '다르다-틀리다'에 대한 생각에도 동의하구요,
      쓸데없는 높임법 대신 아무나 이름과 you로 부를 수 있는 언어가 더 합리적이고 편하다는 것 역시 공감합니다.
      하지만 당장 모국어와 문자가 이런 식으로 형성돼 버렸고 언어의 사회성이라는 걸 개인이 하루아침에 뜯어고칠 수 있는 게 아니니..;; 비합리적이고 불편하게 느껴지는 것에 대한 국민적인 공감이 먼저 형성돼야겠네요..;;

Leave a comment

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/04   »
  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 29 30        

Site Stats

Total hits:
1155877
Today:
2
Yesterday:
857