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

내 프로그램의 중복 실행 여부를 판단하려면? (물론 윈도우 프로그래밍 기준)

실행 직후에 자신만 식별할 수 있는 이름으로 커널 오브젝트를 만들어서, 이놈의 생성 여부로 판단하는 게 제일 무난하고 안전하다. 커널 오브젝트라 함은 메모리 맵드 파일, 뮤텍스, 이벤트 등 이름의 scope가 전역적인 어느 것이라도 될 수 있겠다.

다른 방법으로 중복 실행을 판단하는 방법은 크게 윈도우 아니면 파일로 식별하는 것으로 나뉘는데, 커널 오브젝트만치 완전하지는 못하다. 그 이유를 지금부터 설명하겠다.

※ 응용 프로그램이 생성한 윈도우로 판단하는 법

FindWindow 함수로 나만이 지정하는 윈도우 클래스 이름이나 윈도우 캡션 이름을 검색하여 그게 존재하면 그 윈도우로 포커스를 옮겨 버리고 나는 실행을 종료한다. 대개, 이미 존재하는 인스턴스로 포커스를 옮겨 주는 작업이 필요할 것이므로 윈도우로 검색하는 방법은 어지간해서는 상당히 간편하고 직관적이고 좋은 방법이긴 하다. 다만,

만약 MFC 같은 프레임워크로 프로그램을 개발하고 있었다면, 메인 윈도우의 클래스 이름을 나만의 명칭으로 변경하기 위해 PreCreateWindow 같은 함수를 번거롭게 오버라이드해야 한다.

또한 클래스 이름이 아니라 캡션 이름으로 검색하는 것은 어지간해서는 피해야 한다. 캡션 이름 검색은 모든 top-level 윈도우들에 WM_GETTEXT 메시지를 보내는 방법으로 행해지기 때문에 오버헤드가 클 뿐만 아니라, 이미 실행된 내 프로그램 윈도우가 작업 중이어서 응답을 안 하고 있다면 프로그램 실행이 의도대로 되지 않을 우려가 크다.

윈도우로 검색하는 방법은 근본적으로 큰 약점이 있다. 일반적으로 프로그램이 실행된 직후 로딩, 각종 초기화를 끝내어 메인 윈도우를 생성하기까지는 적지 않은 시간이 소요된다는 것이다. 커널 오브젝트를 생성하는 것처럼 즉시 생성되는 게 아니다. 그렇기 때문에 첫 인스턴스가 아직 메인 윈도우를 만들기 전에 사용자가 실수나 고의로 또 엔터를 눌러서 둘째 인스턴스까지 실행한 경우 여전히 프로그램이 두 개가 실행되어 버릴 수가 있다. 프로그램이 어떤 경우에도 절대로 두 인스턴스 이상이 실행돼서는 안 되는 중요한 프로그램인 경우 윈도우 검색의 결과에만 의존해서는 안 된다.

※ 파일 차원에서 판단하는 법

윈도우 3.1 시절에는 WinMain 함수의 둘째 인자인 hPrevInstance를 살펴보는 것만으로도 내 프로그램의 중복 인스턴스를 판단할 수 있었다.
32비트 이후의 운영체제에서는 인스턴스 핸들의 의미가 한 주소공간 안의 포인터로 완전히 바뀌어 버렸기 때문에, 주소공간 자체가 독립적인 프로세스를 식별할 수는 없게 되었다. 오로지 그 주소공간 안에 로드되어 있는 여러 DLL 같은 모듈들만 식별할 수 있다.

그 반면, 지금도 EXE 내지 DLL 내부에 공유 가능한 섹션을 따로 생성하여 여기에 중복 인스턴스와 관련된 정보를 간단하게 집어넣을 수도 있다. 즉,
#pragma data_seg()
#pragma comment(linker, "/Section:SHARED,RWS")
이런 지시문 안에다가 전역변수를 선언하면 그 변수는 운영체제의 가상 메모리 상으로 나의 모든 인스턴스들이 공유하게 된다는 뜻이다. 자세한 것은 MSDN 참고. 번거롭게 메모리 맵드 파일 API를 호출할 필요 없이 간단한 데이터 공유에는 이 방법이 굉장히 편리하다.

이렇게 파일 차원에서 식별하는 방법은 윈도우 차원에서 식별하는 방법이 잠재적으로 갖고 있는 부작용들이 전혀 없어서 좋으나, 말 그대로 파일에 전적으로 종속적이라는 큰 한계가 있다.
같은 EXE를 이름만 바꿔 복사해서 실행한 것은 중복 인스턴스로 전혀 판단하지 못한다는 것이다. 이 점이 매우 중요하며, 이는 대부분의 경우 원치 않는 결과일 것이다. 결국 실행 파일 그 자체가 아니라 그 실행 파일이 만들어 놓은 결과를 추적해서 중복 실행을 판단하는 접근 방식이 필요하게 된다.

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

http://blog.naver.com/mhangulo/20054140906
여기서 본인의 눈길을 끈 정보는
"서울-부산간 KTX 전기 요금은 100만원 남짓."
열차 주행뿐만 아니라 객실 내부의 전기 공급까지 다 포함한 비용이겠죠.

본인은 어디선가 다른 출처를 통해, 서울 지하철 5호선급의 노선에서 전동차 한 편성이 편도 운행하는 데 드는 전기 요금이 10몇 만원이라는 얘기를 들은 적이 있습니다.

서울-부산간 거리는 약 408km에 약 100만원. KTX는 18량에 최대 935명이 타고.
지하철 노선 길이는 약 40~50km에 약 10몇 만원. 전동차는 8~10량에 초만원일 때 1600~2000명까지 탈 수 있음.

※ 408km는 곧게 뻗은 고속신선으로 달려서 산출된 거리에요. 기존선으로 달리면 서울-부산은 440km가 좀 넘습니다.

요금과 거리의 비율이 얼추 맞죠.
KTX는 빠르게 운행하느라 힘들지만, 지하철 전동차는 고가감속으로 시도 때도 없이 가다 서다를 반복해야 하기 때문에, 역시 만만찮게 힘듭니다.

정확한 비교가 되긴 어렵지만 그래도 얼추 짐작해 보면 굉장히 수긍이 가는 결과인 것 같습니다.
서울-부산 KTX 편도 운임이 거의 5만원에 육박하니 935명이 타는 열차에 겨우 20여 명, 객차 딱 한 량의 1/3밖에 안 되는 인원만 타도 "수송원가"는 건진다는 황당한 얘기가 나옵니다.

또한 상일동-방화 교통카드 운임이 요즘 1600원이니, 지하철 한 칸에 성인이 좌석 승객(40여 명)과 입석 승객이 비슷한 양만치만 타도 "수송원가" 건집니다.
우리나라에서 전기가 얼마나 저렴한 동력원인지를 알 수 있습니다. 원자력 발전 캡숑 짱 만쉐이입니다.

서울-부산을 기름으로 달린다면?
<과학 기술로 달리는 철도>란 책을 보면 우리나라 특대형 디젤 기관차는 1km 주행에 경유를 3.32리터 쓰는 기름 먹는 하마라고 합니다. 1리터로 3.32km가 절대 아님. 운행 조건이 전혀 명시되어 있지 않으니 무척 부정확한 통계가 될 수밖에 없긴 하지만.. 감만 잡도록 하죠.

여기에다 408이든 440이든 곱하면 소모되는 기름 양은 약 1460리터에 달합니다.
철도에 무슨 비닐하우스나 어선처럼 면세유 쓴다는 말은 못 들었으므로, 세금이 그대로 붙은 자동차 경유값 리터 당 1800을 곱하면... 네, 무려 이미 260만원이 넘습니다.

그 디젤 기관차 하나로는 객차도 최고 많아야 8~9개까지만 끌 수 있습니다. 그 반면 KTX는 한번에 18개에 달하는 객차를 끕니다.
수송량에서도 차이가 나는데, 디젤은 거기에다 발전차 가동에 드는 기름값도 추가해야겠죠? 발전차의 연료 및 유류비에 대해서는 전혀 아는 게 없으니 제끼더라도, 이런 것들을 감안하면 전기는 디젤보다 수송원가가 비교가 안 될만큼 무지막지 싸다는 것을 알 수 있습니다.

전철화가 되고 나서 철도 수송원가가 거의 1/3이나 그 이하 수준으로 떨어졌다는 말은 결코 과장이 아닌 것 같습니다. 특히나 우리나라처럼 기름값 비싼 나라에서는!

Posted by 사무엘

Posted by 사무엘

1. 다른 언어는 어떤지 모르겠지만, 최소한 영어와 일본어는 임의의 인명을 소리만 듣고 받아적기는 거의 불가능에 가깝다.
영어는 언문 일치가 개떡이기 때문이요, 일본어는 한자 때문이다. 특히 한자 문화권에서는 내 자식은 특별하게 키우려고 일부러 잘 안 쓰이는 어려운 한자만 골라서 집어넣는 경우도 흔하다. 그래서 그런 문화권은 일상 생활에서는 잘 알려진 쉬운 이름만 사용하는 애칭이 발달해 있는 것이다. 영어 알파벳은 단어 단위로 한자 같은 뜻글자를 이루고 있는 것에 가깝다. ^^

한국어가 영어보다 문법이 복잡하고 어렵고, 띄어쓰기 같은 맞춤법도 엄밀하게 정착해 있지 못한 면모가 있는 것은 사실이지만 그렇다고 해서 사정이 꼭 절망적이기만 한 것은 아니다. 한글은 그런 게 필수불가결한 변별 요소가 아니기 때문에, 그런 걸 꼭 안 지켜도 어지간하면 뜻이 잘 통하기 때문이다. 사실 영어에서 단어 철자나 띄어쓰기가 틀리는 것은 한글 자모를 잘못 적는 것이나 마찬가지이다. ㅈ을 ㅊ으로 잘못 적는 게 아니라 아예 ∨ 같은 엉뚱한 글자로 적는 것과 비슷한 맥락인 것이다.

2. better than nothing은 이게 다른 것보다 나은 게 하나도 없다는 '꼴찌, 무익'이라는 뜻일까,
아니면 그래도 '아예 없는 것보다는 낫다'는 '위안' 뉘앙스일까? 영어로 이 둘은 어떻게 구분하면 좋을까?
'아닌' 것과 '없는' 것은 의미가 비슷하지만 다를 때도 있다. 이런 게 헷갈릴 때가 있다.

3. 영어에서 비교급을 쓸 때 간단한 형용사에 대해서는 잘 알다시피 -er, -est 어미가 붙지만,
3음절 이상의 긴 단어이거나 형용사 자체가 -ous, -ful 같은 접미사가 붙은 단어라면 그런 어미가 또 붙지는 않고, more, most 같은 부사가 비교급을 만들어 준다.
그런데 문제는 more, most 자체도 many의 비교급으로서 형용사의 의미가 있다는 것.
나의 영문법 지식에 따르면, "더 유명한 사람들이 오고 있다"와 "유명한 사람들이 더 오고 있다"가 영작을 할 때 구분이 안 되는 상황이 벌어질 수 있다는 뜻이다.
마치 한국어에서 조사 '과(와)', '랑'이 and라는 의미도 있고 with라는 의미도 어느 정도 동시에 갖고 있어서 발생하는 모호성/중의성 정도와 비슷한 차원인 것 같다.

4. '한번'은 붙일까 띄울까?
인간의 언어에서 1이라는 숫자는 두 가지 방면에서 매우 중요한 의미가 있다.
첫째는 0이 아니라 1이라는 의미일 때(부재가 아니라 실존)이다. 이때는 영어에서도 a, the 같은 관사가 붙는다.
둘째는 복수가 아니라 1이라는 의미이다. 이때는 영어로 정확하게 one이라는 숫자가 쓰인다.

그래서 0이 아니라는 부정관사에 가까운 의미로 쓰는 '한번'은 붙여 쓰고, 진짜 정확하게 one time이 되어야 할 때는 '한 번'이라고 띄어 쓴다고 생각하면 대체로 맞다.

"언제 한번 놀러 오시죠." / "우리 한번 맞장 떠 볼까?" / "그런 방법도 한번 써 봤지만, 잘 먹히지 않았다." (놀러 오는 것, 맞장 뜨는 것처럼 안 하던 행위를 해 본다는 게 중요함)
"이미 접수가 되어 있으니 글쓰기 버튼은 한 번만 눌러야 합니다." / "한 번만 더 틀렸다간 진짜 죽는다" (왜 띄었는지 명확하다)

Posted by 사무엘

<너는 참 열심히 살았다>라는 공 병우 박사의 글은 본인이 10년도 더 전에 고등학교 시절에 접했고 내 홈페이지의 자료실에도 있을 뿐만 아니라 본인이 개발한 타자연습 프로그램의 연습글에도 등재되어 있다. 이 글을 요 며칠 전 다시 읽어 봤다.
http://moogi.new21.org/book1.htm

내가 어렸을 때는 그저 감성적으로 세벌식을 지지한 것도 없지 않았지만, 좀더 성숙하고 나이가 들면서 생각해 보니 공 박사는 예전에 생각했던 것보다 더욱, 정말 무서울 정도로 천재이고 선각자였다는 생각이 들며 전율을 느낀다. 그 시절에 벌써 저런 걸 생각해 냈다니! ㅎㄷㄷ 하는 그런 느낌 말이다.
(글을 보면 알겠지만, 심지어 이메일조차도 없고 ‘팩시밀리는 놔두고 얻다가 쓰나?’ 그러던 옛날이다.)

90년대 초반에 이미 80대의 나이로 매킨토시를 애마로 사용하면서 글을 쓰신 고인이 지금도 살아 계셔서 인터넷, 채팅, 댓글 문화, 휴대전화 문자, 블로그, 심지어 스마트폰이라는 걸 접했다면, 어떻게 대응하고 한글 세벌식을 응용해서 어떤 발명을 해냈을까? 아마 그런 것도 시간을 아껴 주는 기계라고 아주 좋아하셨을 것 같다. ^^;;
그런데 나는 노트북에 너무 익숙해진 나머지 노트북보다 작은 기계에는 관심이 없어진 것도 있다. 10년 전엔 내가 시대를 앞서 갔지만, 지금은 오히려 뒤쳐지고 있는 느낌이다. -_-

어쨌든, 이렇게 기계가 작아지면서 한글 기계화 역사에서도 뭔가 중요한 변화가 생겼다. ‘기계간의 글자판 통일’이라는 관점에서 두벌식, 세벌식이라는 논쟁은 그리 의미가 없어졌다는 것이다. 마치 유니코드 앞에서 조합형 완성형 논쟁이 의미가 없어진 것과 비슷한 맥락이라 할 수 있겠다.
그렇다면 앞으로 타자기와 호환되는 기계화 방식은 정말로 의미가 없어진 것일까? 작은 화면에 버튼 수도 더 줄일 수 있는 두벌식이 세벌식에 비해 우위를 차지하게 되는 걸까?

본인은 그렇지는 않다고 생각한다. 컴퓨터가 더 작아질 수가 없는 주된 이유 중 하나는 입력 속도 때문이다. 두 손으로 누르는 범용적인(=속기가 아닌) 입력 방식 중에 오늘날의 타자기/일반 키보드보다 더 빠른 입력 방식은 내가 알기로는 없다. 또한 12키나 아이폰 20키 같은 제한된 입력 환경에서도 음절 모호성이나 도깨비불 현상이 존재하지 않는 세벌식 입력 방식을 구현하려는 연구는 여전히 진행 중이다.
세벌식은 모바일에서도 죽지 않았다. 그 몇 가지 결과물을 소개한다.
http://moonhwawon.ye.ro/zboard/zboard.php?id=00_notice&no=64 (휴대전화 12키)
http://www.hopark.info/?p=1315 (아이폰 15키)

Posted by 사무엘

윈도우 3.x 시절에 MS에 한글 글꼴을 공급한 업체는 왕년의 유명한 국내 벤처 기업이던 큐닉스 컴퓨터였습니다. 한때 프린터까지 만들던 곳인데, 지금은 망하고 글꼴 개발 부분만 모리스 디자인으로 상호를 바꿔 명맥을 유지 중인 걸로 알고 있습니다. 개성체를 비롯해 동글동글한 이솝체를 만든 곳이죠.

이 글꼴들은 같은 명조, 고딕, 궁서라 할지라도 당시 아래아한글 2.x 전문용이 번들로 제공하던 한양 글꼴 equivalent에 비해 미려함이 덜하고 단조로워 보였습니다. 하지만 외국산의 품질 좋은 래스터라이저와 힌팅 정보에 힘입어, 작은 크기에서의 품질 하나는 아래아한글이 적수가 될 수 없을 만큼 정말 좋았지요.
그때는 유니코드라는 개념 자체가 없었고 한글 글꼴은 2350자를 일일이 다 그려 넣는 것밖에 선택의 여지가 없었습니다.

그러던 것이 윈도우 95에 와서는 한글 글꼴 체계가 크게 향상됩니다. 그리고 이때 첫 라이선스 한 한양 글꼴은 그 최신 기술이 모두 반영된 작품이었습니다. 어떤 게 있는지 예를 들면 이렇습니다.

첫째, TTC. 굴림과 돋움, 바탕과 궁서가 한 글꼴 컬렉션으로 병합됨으로써 둘이서 한 한자 글립을 공유할 수 있게 되었으며, 나머지는 다 같은데 영문만 불변폭 글꼴인 ‘-체’ 글꼴 변종도 기억 장소의 낭비 없이 손쉽게 구현할 수 있게 됐습니다. 이런 기술은 작은 고유 문자와 한자를 공용하는 일본에서도 더욱 필요했을 것입니다.
(하지만 이제 굴림과 궁서도 별도의 한자 글립이 있으면 더 좋을 것 같네요. 한국에서는 지금도 명조 고딕 외의 한자 글꼴은 가정용 PC에서 좀체 보기 힘듭니다.)

둘째, 비트맵 자형 내장. 알파벳 글꼴이야 아예 비트맵밖에 없는 FON 파일만 쓰든가, 아니면 트루타입은 정교한 수제 힌팅만으로 작은 크기에서도 아주 보기 좋은 자형을 만들어 냈지만 한글/한자 같은 문자는 아예 비트맵을 만들어 넣어 주는 게 당장 더 유리합니다. 윈도우 3.1 시절엔 이런 개념이 없었던 것 같습니다. 그 바탕체 12포인트는 BT16.TBM이라고 TTF와는 완전히 별개의 파일에 글립이 저장되어 있으며 운영체제가 임의로 불러들이고 출력해 주더군요. 12포인트 말고도 15포인트용 BT20.TBM 파일도 있습니다.
TTF가 자체적으로 다양한 크기의 비트맵을 내장하게 된 것이 윈도우 95부터입니다. 덕분에 굴림, 바탕, 돋움이 모두 자체적으로 비트맵을 갖게 되고 결과적으로 윈도우 3.1보다 글꼴의 품질은 크게 향상되었죠.

끝으로 유니코드 지원입니다. 확장완성형 때문에 큰 물의를 빚긴 했으나 어쨌든 모로 가도 서울만 가면 된다고, 윈도우에서 운영체제 차원에서 11172자 한글 표현이 가능해지고 한글을 조합 글립으로 표현할 수도 있게 된 것이 95에 와서부터입니다.

윈도우 9x를 직접 설치해 본 분들은 아시겠지만 얘네 계열들은 설치 GUI가 정확하게 윈도우 3.1 커널 기반입니다. 16비트 코드와 32비트 코드가 짬뽕이어서 그런지 한글 글꼴도 두 체계가 완전히 짬뽕인 것을 볼 수 있죠. 첨부하는 그림을 보시면 설치 마법사 대화상자 안의 모든 글꼴들은 9x에서 볼 수 있는 ‘한양 시스템’ 굴림이지만, 그 바깥에 있는 약간 조악한 느낌이 드는 글씨들은 전부 윈도우 3.1 ‘큐닉스 굴림’ 10포인트입니다. 둘의 품질의 차이가 한눈에 보이시죠?

컴퓨터의 성능이 향상되고 운영체제가 발달하면서 문자 입출력 기술도 알게 모르게 더욱 정교해지고 범용성이 향상되고 있습니다. 언뜻 보기에 똑같은 기능을 하면서 덩치만 아무 이유 없이 커지는 건 아니거든요.
예전에는 동아시아 버전 아랍권 버전 이렇게 따로 적용되던 기술이 이제는 전세계 어느 기계 내지 소프트웨어에나 동일하게 들어가고 있다는 뜻입니다.

Posted by 사무엘

BannerMania라고 무려 1989~90년대에 나온 도스용 프로그램이 있다. 나름대로 다양한 윤곽선 폰트를 사용하여 당대로서는 환상적이기 그지없는 글자 비틀기와 특수효과를 모니터와 프린터에 동시 구현하였다. 본인도 무려 286 AT 쓰던 시절에 이 프로그램을 돌려 봤다.

지금 생각해도 정말 잘 만든 프로그램이다. 굉장히 복잡 정교한 다각형 합성/채우기 계산 알고리즘이 쓰인 것은 두말할 나위도 없거니와 다양한 그래픽 카드와 프린터 지원, 프로페셔널한 디자인 세트 등은 각 분야 최고의 전문가들의 두뇌가 결집하여 만들어진 작품임을 인정하지 않을 수 없게 만든다.

이 프로그램이 사용하는 윤곽선 글꼴 파일을 읽어서 글자를 찍어 주는 프로그램을 나는 무려 2001년에 내 홈페이지 개설과 거의 동시에 만들어 올렸었다. 물론 내가 포맷을 분석한 건 아니고, 타인이 짠 코드를 포팅한 것이었다.
http://moogi.new21.org/src11.htm

이제 그로부터 7년 반 후,
본인은 그 글꼴 파일 자체를 아예 OTF로 변환하는 데 일단 성공했다. 짠~

WAVE 같은 단어도 보기 좋은 간격으로 찍히고, 글자의 ascent, descent 경계 구분도 자동으로 한다. 즉, 똑같은 줄이라면 AG의 A는 Ag의 A보다 더 크게 찍힌다는 것이다. 소문자 g가 차지하는 아랫부분 공간을 계산할 필요가 없기 때문이다. 정말 꼼꼼하게 잘 만든 프로그램이다.

글꼴 파일의 관행이 다 그렇기라도 한지는 모르겠는데, BannerMania 글꼴도 빅 엔디언을 쓴다. 이는 TTF, OTF 다 마찬가지이다. 단, 글꼴이 디자인된 공간의 크기를 나타내는 EM size는 220 남짓밖에 안 된다. (요즘은 1000~2000대가 대세)

윈도우 운영체제는 3.1 시절부터 TTF를 지원하다가 2000에 와서야 OTF도 지원하게 되었다. 글꼴 관리자를 꺼내 보면 전통적인 T자 아이콘 말고 O자 아이콘이 찍힌 글꼴을 심심찮게 볼 수 있을 것이다. 이것들이 OTF이다. 단, OTF 자체는 TTF 글꼴에다가 TTF의 고유 2차 스플라인뿐만 아니라 포스트스크립트 Type 2방식의 3차 스플라인도 포함할 수 있게 규격을 확장하고 몇몇 기능을 더 추가한, TTF superset에 가까운 개념이다.

윈도우 2000에서부터 Verdana, Times 같은 주요 영문 글꼴들이 OpenType으로 표시는 되나, 이들은 내부적인 윤곽선 표현 방식은 여전히 TTF 방식인 ‘껍데기만 OTF’들이다. 그것 말고 Type 2 방식의 진짜배기 OTF 글꼴도 윈도우 2000부터 지원은 하기 시작했으나, 그 지원 수준은 윈도우 비스타에 이르기까지 여전히 미비하다(7은 잘 모르겠음). OTF는 ClearType 안티 앨리어싱이 아직 지원되지 않으며, MS 오피스의 WordArt를 만들거나 오피스 2007이 제공하는 PDF 저장 기능으로 저장을 해 보면, 서체가 윤곽선 글립이 아닌 비트맵 이미지로 저장된다! 마치 아래아한글에서 hft 고유 글꼴을 처리하듯이 말이다. 이걸 보고 적지 않게 실망했다.

90년대에 아래아한글(휴먼 컴퓨터 포함)이 통합 글꼴을 별도로 만들지 않고 TTF를 썼다면 역사가 또 많이 바뀌지 않았을까 싶다. 물론 그렇게 하더라도 코드 페이지는 독자적으로 정해서 쓰고 있었으니 아래아한글용 TTF와 윈도우용 TTF가 서로 호환될 수는 없었을 것이다.

아마 독자적인 한글 표현 방식이라든가, 글꼴 압축/암호화의 용이성, 글꼴 드라이버 계층의 독립 가능성 등으로 인해 통합 글꼴이 채택된 게 아닌가 싶지만, 결국 현재 통합 글꼴을 사용하는 제품은 지구상에서 아래아한글밖에 남아 있지 않고, 그나마도 어쩔 수 없이 legacy 차원에서 지원하고 있는 실정이다.

Posted by 사무엘