지금이야 고등학생이 스마트폰 앱을 뚝딱 만들고 안드로이드나 애플 사의 앱스토어에다 등록하는 소프트웨어 유통망까지 확립된 시대이다. 하지만 지금으로부터 20여 년 전에는 개인이 만든 소위 '공개 소프트웨어'라는 것들이 PC 통신을 통해 배포되곤 했다. 게임, 업무 등 분야도 엄청 많았으며, 이거 하나로 스타 개발자로 유명세 타는 사람 역시 응당 있었다.

개발자들 중엔 대학생이 많았다. 도움말이나 리드미 파일을 보면, PC 통신 ID뿐만 아니라 개발자 자신의 소속 학교, 학과, 학번(연도만)까지 밝히곤 했다. 그들은 지금은 다 어디서 뭘 하고 있을까?
더 어린 중· 고등학생이 그 정도 퀄리티의 도스용 프로그램을 만들기엔 리소스도 부족하고 컴퓨터에 대한 인식이 부족했으며 기계값이 아직 너무 비쌌다. 하물며 Windows용 프로그램을 만들려면 더 좋은 컴퓨터에 더 비싼 개발 환경이 필요했을 테고.

국내 개발자들은 당연히 자기 프로그램의 UI를 한국어로 만들었다.
그리고 세월이 흐르면서 프로그램들은 아무리 간단하고 작은 규모라 해도, 한글 바이오스에 의존하는 텍스트 모드보다는 그래픽 모드에서 '자체 한글' 기반으로 동작하는 경우가 많아졌다.
이때 자연스럽게 필요해지는 것은 그래픽 모드에서 한글을 찍어 주고 때로는 입력까지 처리해 주는 일명 '한글 라이브러리'이다.

옛날에 도스 시절에 자체 한글을 구현한 라이브러리를 만들어서 PC통신으로 뿌리고 잡지에 강좌를 올리고 책도 쓰며 유명세 타던 프로그래머들은 굉장히 날고 기는 수재들이었다.
아예 게임을 만드는 급까지는 아니더라도 나름 VGA 그래픽 하드웨어를 제어하고 여러 래스터 그래픽 알고리즘을 최적화된 어셈블리어 코드로 직접 짜는 건 쉬운 일이 아니었다. 또한 한글 입력 오토마타를 깔끔하게 짜는 것도 아무나 선뜻 할 수 있는 난이도는 아니었다(특히 두벌식은 더 어려움).

그래서 공개 소프트웨어 리드미의 '감사의 글'(acknowledgements)을 보면, “본 프로그램은 이런 한글 라이브러리를 사용하였으며, 우수한 미들웨어를 무료로 공개해 주신 누구누구에게 감사합니다” 같은 문구도 심심찮게 볼 수 있었다.

열악한 환경의 특성상, 그 시절에 한글 라이브러리는 사실상 그래픽 라이브러리나 마찬가지였다. 그리고 더 나아가면 마우스에 간단한 대화상자까지 제공하는 통합 GUI 라이브러리로 발전하곤 했다.

아래아한글의 개발사로 유명한 한글과컴퓨터 사에서는 아무래도 저런 기술의 본좌이었을 테니, 1991년엔가 <컴퓨터 속의 한글>이라는 책을 출간했다. 싸제 한글 라이브러리를 개발한 많은 프로그래머들이 이 책을 참고하여 터를 닦은 뒤, 자기만의 살을 붙이고 자신만의 방식으로 API를 설계해서 물건을 만들었다.

회사가 아닌 개인 자격으로는 PC 통신 시절에 '터보이빨'이라는 닉으로 유명하던 임 인건 씨가 있다. 이분은 그 이름도 유명한 '한라프로'라는 걸출한 물건을 개발하여 상업용으로 판매도 했으며, 아마 서울대 기계공학과 재학 시절에 터보 C 정복이라고 책도 하나 썼다. 본인 역시 아래아한글 1.x로 편집· 조판되어 있던 이 고전을 읽으면서 C언어 기초를 닦았었다.

어디 그 뿐이랴? 지금까지도 인터넷 검색을 하면 굴러다니는 '프로그래머 십계명'이라는 글도 저분 작품이다.
이 정도면 저분은 거의 프로급 소프트웨어 엔지니어 같은데... 프로필을 보면 알 수 있듯 저분은 프로그래밍이 본업이 아니다. 훗날 저분은 같은 학교에서 박사까지 마친 뒤, 업계에서 고급 엔지니어 경력을 쌓다가 지금은 '성진 C&C'라고 금속, 재료 쪽 중소기업의 부사장 자리에 올랐다.

그리고 또 '한라프로'와 더불어 한글 라이브러리의 양대 산맥이던 물건으로는 '허르미'가 있는데, 이걸 개발한 분은 한 우진 씨이다. 국내의 유명 철덕인 한 우진 씨(미래철도 DB)와는 동명이인임.

저분 역시 물건만 만들어 공개하고 끝이 아니라, 한글을 구현하는 기술 디테일을 친절하게 저술까지 해서 이름을 날렸다. 그리고 카이스트 전산학과에서 학, 석, 박을 마치면서 멀티미디어 데이터 압축 알고리즘 쪽 전문가가 되었다. 졸업 후엔 삼성 전자에서 몇 년 근무하다가 나중에는 가천 대학교 교수로 부임했다.

다들 왜 저렇게 똑똑한 거야..;;; ㅜㅜ
후대에 등장한 많은 한글 출력 라이브러리들은 한컴 사의 책이든, 위의 두 제품의 영향을 어떤 형태로든 받았다고 생각하면 된다. 1990년대 중반 이후에 만들어진 것들은 시대의 흐름답게 슈퍼 VGA를 지원하고 32비트 환경(Watcom C/C++ 내지 DJGPP)을 지원하는 식의 발전이 이뤄지기도 했다.

저런 선구자들에 비해, 본인은 도스 시절이 다 끝난 뒤에야 한글 관련 솔루션의 개발에 입문했다. 하드웨어 제어나 그래픽 알고리즘, GUI 따위를 자체 구현할 필요는 전혀 없고 내 입력기는 그렇다고 자동 완성, 상용구, 속기 같은 NLP/lexicon 기반요소가 등장하는 것도 전혀 아닌데 도대체 이 바닥에서 무슨 일을 한 걸까?

그런 것들이 없는 대신에 내 프로그램은 그야말로 한글을 자모 단위로 조작하는 기본 동작에만 초인적인 집중과 최적화를 했으며, 온갖 똘끼 넘치는 아이디어들을 구현하게 됐다.

아울러, 내 프로그램은 다른 건 몰라도 자체 편집기에서 도스 시절의 비트맵 글꼴을 출력하는 루틴만은 여전히 답습하고 있다. 옛날 추억과 한글 프로그래밍 정신 계승(?), 그리고 기술적으로는 한글 조합 자모나 옛한글 표현 같은 여러가지 이유 때문이다.
이건 한글을 가장 가볍고 단순하게, 마치 컴퓨터 속의 기계식 타자기처럼 원시적으로 출력해 주는 시스템이라는 상징적인 의미가 크다.

본인은 지금은 타자기 시절이나 도스 시절과는 다른 차원의 한글 프로그래밍이 여전히 필요하다고 생각하며, 심지어 한국어를 개입시키지 않더라도 한글 자체에 대한 엔지니어링이 연구할 여지가 있다고 생각한다. <날개셋> 한글 입력기의 개발을 다 마치고, 가까운 미래에 박사까지 다 마치고 20년쯤 뒤 먼 미래엔 뭘 하고 있을까? 한글 가지고 더 창의적으로 먹고 살 거리가 없으면 진짜로 철도로 업종 전환할지 알 수 없는 노릇이다. ㅎㅎ

Posted by 사무엘

2014/09/09 08:30 2014/09/09 08:30
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1005

작년 가을엔 <응답하라 199x>라는 레트로 장르의 TV 드라마가 인기가 많았다.
요즘은 사극 드라마라도 하나 방영되면 전국의 역덕후들이 벌떼처럼 일어나서 별 희한한 곳에서 고증 오류들을 찾아 올리는 게 관행이다. 이 드라마 역시 예외가 아니었다.

2013년 10월 18일 방영분에는 아래와 같은 유명한 장면이 나온다.

사용자 삽입 이미지

서울 지하철 1호선의 노선색이 빨간색이고 역명판이 둥글게 만들어져 있던 옛날 시절을 재현한 것까지는 좋다. 솔직히 말하면 본인조차도 그 실물을 본 적은 없다. 본인은 서울 태생이 아니며 서울 지하철을 이용하기 시작한 건 21세기부터이기 때문이다.

그럼에도 불구하고 저 장면에는 여러 크고 작은 고증 오류가 존재한다.
벽면의 인테리어가 실제 지하철 서울 역과 다르며 섬식 승강장 역을 상대식 승강장으로 만들어 놓은 건 애교라 친다만...
역명판의 글꼴을 2003년에 만들어진 걸로 쓰면 어떡하냐. 무려 코레일체!

20세기 설정에 너무 깔끔한 21세기 서체가 혼자 확 튀어 보인다.
게다가 저건 철도청/코레일의 전속 서체이지 서울 지하철에서 쓰던 서체도 아니다.
완전 어처구니없는 고증 오류가 아닐 수 없다.ㅋㅋㅋㅋㅋ

또한, 글꼴만치 부각되는 건 아니지만 '서울驛'이라는 한자 병기가 들어간 것도 오류다.
서울 지하철이 처음 개통했을 때는 역명판에 한자 병기가 없었기 때문이다. 그건 1999~2000년대가 돼서야 추가되었다. 딱 그 시기에 로마자 표기법 개정분 반영, 한자 병기와 더불어 국철(= 광역전철) + 지하철 노선색 통합까지 몽땅 진행되었으니 수도권 전철의 외형이 크게 바뀌는 시기였다.

그건 그렇고 아무튼...
그럼 1994년 기준으로 코레일체 대신 저기에 무슨 글꼴이 들어가야 맞는지 궁금하다면, 아래의 '진짜' 옛날 사진을 참고하시기 바란다. 엔하위키엔 관련 자료가 이미 다 올라와 있다. ㅎㅎ

사용자 삽입 이미지

시대를 풍미해 온 지금의 지하철 전속 서체와 같거나 최소한 비슷한 투의 납작한 헤드라인이 그때에도 쓰였다.
초롱테크에서 1990년대 중반에 정식으로 내놓은 그 디지털 서체는 그걸 좀 더 세련되게 다듬은 게 아닐까 싶다.

사용자 삽입 이미지

본인은 개인적으로 이 서체를 굉장히 좋아한다. 마치 런던 지하철의 전속 서체가 그야말로 런던 지하철 전체의 정체성을 대변하는 명물이 되어 있듯, 저 서체는 수도권 전철까지는 아니어도 서울 지하철을 대표하는 서체가 되기에 손색이 없다고 생각한다.

사용자 삽입 이미지

그런데 왜 그걸 함부로 바꾸고, 이미 만들어 놓은 멀쩡한 시설까지 돈 들여서 뜯어고치고 있는지 모를 일이다.
서울 도시철도 공사 관할역들의 경우, 지상에 있는 검은 배경의 세로형 역 폴사인의 서체가 어느 샌가 야금야금 서울 남산체로 바뀌고 있다.

오히려 지하철이 아니라 광역전철 소속이어서 우측도 아닌 좌측통행으로 건설된 신분당선이 클래식 지하철체를 살려 쓰고 있으니.. 혼란스럽다.

음, 그나저나 응답하라 1994의 오류가 또 생각 났다.
내가 언뜻 본 기억으로는 그 드라마 내부에서 등장하는 TV 뉴스 화면의 자막이...
굴림은 양반이고 아예 나눔고딕인 장면이 있었다!

서 태지가 은퇴하는 소식이 나오는 20세기 복고 드라마에, 2008년 한글날에 무료 배포된 서체가 등장한다는 게 말이 되냐.. ㅋㅋㅋㅋ

요즘은 유튜브만 검색하면 1990년대 옛날 영상 매체의 주요 장면을 아주 쉽게 구할 수 있다.
자막에다가는 엑스포체나 그래픽체만 넣었어도 지금으로부터 2, 30년 전의 영상 매체의 구리구리한(?) 분위기를 아주 손쉽게 낼 수 있었을 것이다. 무슨 서체를 쓰든 CG 처리는 똑같이 필요했을 텐데, 이게 무슨 돈이 더 드는 일도 아니고!

사용자 삽입 이미지

* 결론

1. 이렇듯 글꼴 유행도 시대에 따라 변한다.
2. 철도와 성경의 융합에 이어 철도와 글꼴의 융합도 얼마든지 가능하다.

Posted by 사무엘

2014/01/06 08:13 2014/01/06 08:13
, , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/917

유니코드 1.x가 제정되었을 때는 믿거나 말거나 한글도 글자마디는 완성형 몇천 자만 지금과는 딴판의 영역에 등록되어 있었다. 단, 글자마디뿐만 아니라 옛한글을 포함한 자모도 자음 134개(물론 초성과 종성의 개수는 서로 다르고 따로 등록됨), 모음 66개가 등록되어서 이 자모들을 아래아한글 2.x가 한컴 2바이트 코드에서 그대로 채택해서 썼다. 한컴 2바이트 코드는 기존 조합형 코드와 유니코드를 적당히 짬뽕한 문자 코드였던 것이다.

유니코드는 첫 도입 배경이 저렇다 보니 “유니코드 = all 2바이트 단일 문자 체계 = wide character 문자 체계”라고 혼동하는 사람이 적지 않다. 그러나 이는 개념적으로 올바른 관계가 아니다. 2바이트 문자 체계로만 치자면 한컴 2바이트 코드도 이에 해당하며, 윈도 이외에 유닉스 계열 OS에서는 wide character는 16비트가 아니라 32비트인 경우도 있다. 왜 32비트이냐 하면 6만 5천여 개라는 집합 크기도 시간이 흐르다 보니 부족해졌기 때문이다.

1996년에 유니코드 2.0이 제정되면서 유니코드는 오늘날 우리가 아는 유니코드와 같은 뼈대가 갖춰졌다. 한번 등록한 문자는 이제부터 재배치나 제거 없이 영구불변으로 굳히기로 했으며, 이때 현대 한글 글자마디 11172자가 순서대로 고스란히 등록되었다. 2바이트 조합형처럼 비트 연산은 못 쓰지만 그래도 테이블 없이 뺄셈과 나눗셈, 나머지 연산으로 한글의 자소 정보를 얻을 수 있으니, 과거 조합형 한글 코드의 장점을 유니코드에서도 물려받은 셈이다.

외국 위원들의 반대를 무릅쓰고 한글에다 유니코드의 금싸라기 영역을 이만치 할당 받기 위해 한국 위원회 사람들이 애를 많이 썼다. 사실 확장완성형도 유니코드 등록 근거를 대기 위해 급히 만들어진 것이라고 한다.
이와 더불어 유니코드 2.0에서는 중요한 개념 내지 꼼수가 추가로 도입되었는데, 바로 surrogate이다.
16비트 공간 중 일부 영역은 그대로 쓰지 말고 따로 떼어 내서 두 글자를 뭉쳐서 더 많은 종류의 글자를 표현하는 데 쓰자는 것이다.

0xD800부터 0xDBFF는 high surrogat이고, 0xDC00부터 0xDFFF까지는 low surrogate이다. high는 언제나 앞에, low는 언제나 뒤에 오는 식으로 역할이 딱 고정되어 있다. 1024개의 앞짝과 1024개의 뒷짝이 만나니, 총 2048개의 독립 글자를 희생하여 2의 20승, 약 100만여 개의 글자 공간을 추가로 확보할 수 있게 된다. 요컨대 유니코드에 U+D800 같은 글자는 없고, U+D7FF 다음에는 곧바로 U+E000이 이어진다. 그 대신 0xD800과 0xDC00이 만나면 U+10000이라는 surrogate, 즉 확장 평면이 시작될 뿐이다. 예전의 16비트 단일 영역은 '기본 다국어 평면'(BMP)이라고 불리게 되었다.

비록 과거의 1바이트/2바이트 혼합 체계보다는 사정이 훨씬 낫고 문자열 처리가 수월한 건 사실이지만, 어쨌든 유니코드도 확장으로 인해 2바이트 단일 표현(UCS2)이라는 깔끔한 장점은 포기해야 하게 되었다. 이쯤 되니 유니코드라는 개념에서 문자 코드와 인코딩을 구분해서 표현해야 할 필요가 생겼다.

유니코드 자체는 UCS, 즉 universal character set이라 불리는 단일 문자 집합이다. 얘는 '가'라는 한글 글자에다가 U+AC00이라는 코드값을 부여해 줄 뿐, 그 코드값이 메모리나 파일에 어떻게 표현되는지에 대해서는 규정하지 않는다. 이를 표현하는 방식이 바로 Unicode transfer format, 즉 인코딩이 된다.

모든 유니코드 번호를 아무 뒤끝 없이 32비트 정수 하나로 균일하게 표현하면 그것은 UTF32이다. 아까 wide character가 4바이트인 플랫폼은 바로 UTF32를 구현하는 자료형인 것이다. 가장 깔끔하고 공간도 넉넉하고 모든 글자를 하나씩 쉽게 접근할 수 있지만 한 글자가 4바이트나 차지하여 메모리 낭비가 심하다.

BMP 영역에 있는 놈은 종전대로 16비트 정수 하나로 표현하고 확장 평면에 있는 놈만 surrogate 두 개로 쪼개서 표현하는 방식은 UTF16이라고 불린다. UCS2를 개념적으로 확장한 것이기 때문에 처음부터 2바이트 wide character를 표방하며 개발된 Windows 플랫폼이 매우 사랑하는 방식이다. 비록 Windows의 wchar_t는 이제 유니코드 코드 포인트 하나를 온전히 표현할 수 있을 정도로 충분히 크지 못한데도 말이다.

끝으로, 그 이름도 유명한 UTF8이 있다. 얘는 U+007F 안에 드는 전통적인 알파벳· 숫자, 제어 문자들은 1바이트로 유지하고, 나머지 BMP 영역의 외국어들은 2~3바이트로 표현하고 surrogate는 BMP와 동일한 4바이트로 늘여 표현하는 진정한 multibyte 인코딩이다.

n째 문자를 찾는 무작위 접근은 안 되겠지만, Windows NT처럼 커널을 처음부터 16비트 문자 단위로 설계하지 않고도 기존 8비트 문자 시스템에서 유니코드를 단절감 없이 표현할 수 있다는 엄청난 장점이 있다. CPU의 엔디언(비트 배열 순서)의 영향을 받지 않으며, tail byte가 기존 영문· 숫자와 충돌을 일으키지도 않는다는 점도 좋고 말이다.
그래서 얘는 웹에서 매우 사랑받고 있고 윈도 이외의 플랫폼에서는 파일뿐만 아니라 메모리 저장용으로도 UTF8이 즐겨 쓰인다. 사실 윈도만 이례적으로 UTF16을 너무 사랑하고 있는 것이고.. ㅎㅎ

여담이지만 UTF32, 16, 8 중 유니코드의 문자 집합이 먼 미래에 또 확장되어야 할 때, 공간이 가장 넉넉하게 남아 있는 놈은 두 말할 나위 없이 UTF32이다. UTF8이야 애초부터 들쭉날쭉 가변 길이 인코딩을 표방했기 때문에 한 글자당 4바이트보다 더 긴 5~6바이트까지 약간 더 확장할 여지가 있다. 지금 당장은 그것까지는 쓰이지 않지만 말이다.

하지만 UTF16은 유일하게 확장의 여지가 전혀 없다. 지금 surrogate 영역이 다 차 버리면 surrogate의 surrogate라도 또 만들지 않는 이상 답이 없다. 그리고 그런 헛짓을 할 바에야 차라리 UTF16을 폐기하고 UTF8 아니면 UTF32로 갈아타는 게 낫지..;; 이런 미묘한 면모가 있다.

다만, 한글 표현의 관점에서는 메모리가 가장 적게 드는 인코딩이 UTF16이라는 것도 감안할 점이다. 현대 한글 글자마디의 경우 UTF8은 3바이트, UTF32는 4바이트이지만 UTF16은 2바이트다. 초-중-종성이 모두 갖춰진 옛한글이라면 UTF8과 UTF32는 각각 9바이트, 12바이트를 차지하지만 UTF16은 6바이트이니 차이가 더 벌어지게 된다. 유니코드에는 한글이 완성형(글자마디+호환용 자모) 방식과 조합형(세벌 한글 자모) 방식이 모두 등록되었으며 완성형 방식도 11172자가 순서대로 모두 등록되었으니, 예전의 조합형· 완성형 논쟁을 완전히 종결짓는 데 성공했다.

Windows NT도 처음에 개발될 때 문자 처리 단위를 wide로 무리해서 넓히느라 고생하지 말고, 그냥 UTF8만 도입했으면 어땠을까 싶지만 이제 와서는 다 지난 일이다. 아무래도 UTF8보다야 UTF16이 컴퓨터의 입장에서는 더 빠르고 간편하게 각각의 문자를 인식할 수 있으며, 이것이 메모리와 성능 소모면에서 UTF32와 UTF8 사이의 완충지대 역할을 해 온 건 부인할 수 없기 때문이다. 덕분에 Windows API의 관점에서는 UTF8조차도 native 인코딩인 유니코드 UTF16으로부터 '변환'되어야 하는 여러 multibyte 인코딩 중의 하나일 뿐이다~! ㅎㅎ

옛날에 인터넷 익스플로러의 버전이 5~6이던 시절엔 한글로 된 URL이 인식이 잘 안 돼서 맨날 “URL을 UTF8로 보냄” 옵션을 끄라는 지시가 팁처럼 공유되곤 했다. 당시엔 Unicode-aware하지 않은 웹 서버가 아직 많아서 말이다. 오늘날로 치면 UAC(사용자 계정 컨트롤)를 끄거나 팝업 창 허용 기능을 사용하는 것과 비슷한 편법이다.
하지만 요즘은 UTF8 방식 URL이 표준으로 정착한 지 오래다. 호환성을 중요시하는 IE에나 그런 옵션이 있지, 크롬 같은 브라우저는 선택의 여지 없이 무조건 UTF8이기도 하고 말이다.

유니코드는 문자 처리 기술의 발전과 함께 더욱 덩치가 커졌으며, 한편으로 더욱 복잡해지고 지저분해지고 있다.
UTF32가 아닌 인코딩으로는 어차피 메모리 배열 인덱스만으로 실제 글자 인덱스를 얻을 수 없는 것은 물론이거니와, 메모리 상으로 존재하는 글자 코드 포인트 수와, 화면에 출력되는 글자의 수도 일대일 대응이 전혀 이뤄지지 않게 되었다. 옛한글이라는 것도 유니코드 관련 기술이 방대해지면서 덤으로 같이 처리 가능해졌을 뿐이다. 진짜 미치도록 복잡한 문자에 비하면 옛한글 쯤이야 양반이지... 동일한 글자를 나타내는 방법이 여러 가지 존재하게 되어서 정규화라는 것도 필요해졌다.

코드 포인트 값만으로 정렬을 하는 것 역시 상당수 의미를 잃었다. 옛한글 자모는 유니코드 5.2 때 한양 PUA 비표준에만 존재하던 것들이 추가 등록되었는데, 이것들의 코드 포인트상의 순서를 따지는 건 부질없는 짓이다. 가뜩이나 부족한 BMP 공간의 여러 틈새에 산발적으로 간신히 등록된 것 자체를 감지덕지해야 할 판이다.

한자는 더욱 가관이다. 유니코드에서 공간을 압도적으로 제일 많이 차지하고 있는 문자인 건 두 말할 나위도 없거니와.. BMP 영역에 이미 등록돼 있고 호환용 같은 이유도 없는데 작업자의 실수로 인해 나중에 surrogate 확장 평면에 중복 등록된 글자도 있고, 일본 문자 코드의 실수 때문에 문헌에 전혀 등장한 적이 없는 유령 한자가 등재돼 있기도 하다.

이것이 오늘날의 컴퓨터 문명을 지배하고 있는 가장 원초적인 규범에 속하는 유니코드의 현실이다. ㅎㅎ
수십 년 주기로 유니코드를 전면 reset하고 코드값을 재정리하면 어떨까 싶지만 그건 기존 컴퓨터 문명이 핵 전쟁 같은 걸로 폭삭 없어지지 않는 한, 상상 속에서나 가능한 일일 것이다.

Posted by 사무엘

2013/12/16 08:25 2013/12/16 08:25
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/909

디지털 컴퓨터는 전자 신호로 0과 1만을 인식할 수 있다. 그렇기 때문에 컴퓨터에서는 문자 역시 0과 1의 조합인 숫자로 표현되며, 문자를 그런 숫자에다가 대응시키는 규칙이 바로 문자 코드이다. 정보 교환을 원활히 하기 위해서는 보내는 쪽과 받는 쪽이 모두 문자 코드가 통일돼 있어야 함은 두 말할 나위가 없다.

정보량의 최소 단위는 1비트이지만 현실적으로 컴퓨터의 기억 장치들이 한 글자로 취급하는 정보량의 최소 단위는 8비트, 즉 바이트이다. 8비트, 2^8승, 즉 256이라는 정보량은 숫자와 알파벳을 정하는 데는 충분하고 상위 1비트를 잉여화하여 오류 검출용으로까지 사용할 수 있을 정도이지만, 한글이나 한자 같은 문자를 담는 데는 턱없이 부족하다.

한자는 글자를 체계적으로 부분글자로 분해할 뾰족할 방도가 없는 상태로 글자 수가 너무 많다. 한글은 글자 생성 체계는 한자보다 훨씬 더 유리한 위치에 있지만, 실용적으로 편하게 다루려면 여전히 1만여 개의 미리 조합된 음절 형태를 그대로 배당해야 한다.

예를 들어 현실에서 '학교'라는 단어는 두 글자로 간주되지, 데이터베이스나 문서 분량 같은 데서 5글자라고 계수되는 곳은 아무도 없다. 코드 차지 영역을 줄이자니 메모리 사용량이 늘며, 그리고 오늘날로 치면 화면에 보이는 글자 길이와 메모리를 차지하는 글자 길이가 서로 완전히 따로 노는 complex script 급의 복잡한 기술이 필요해진다.

결국 한글과 한자는 1바이트만으로 표현할 수 없고 통상 2바이트로 표현된다. 그런데 기존 1바이트 영문· 숫자를 건드릴 수는 없으니 1바이트와 2바이트 문자가 공존하는 multi-byte 코드 체계가 만들어진다. 영문권에서 패리티 비트 내지 유럽 특수문자를 표현하는 데 쓰이는 최상위 1비트는, 이 문자가 1바이트로 끝인지 아니면 2바이트 문자의 첫 바이트(lead byte)인지를 판별하는 비트로 쓰인다.
공교롭게도 한글· 한자는 폭도 균일한 2글자 분량을 차지하여 비주얼 상 잘 어울린다. 전각· 반각이라는 개념이 여기서 유래된다.

그런데 lead byte는 그렇다 쳐도 2바이트의 다음 둘째 바이트인 tail byte도 기존 순수 1바이트 문자들과(영문· 숫자 같은) 전혀 겹치지 않게 할 것인지? 아니면 어차피 얘는 lead byte에 의해 변별이 됐으니 좀 문맥 의존적으로 겹치는 걸 허용할 것인지가 문제가 된다. 한글 코드의 경우 완성형은 겹치지 않으나 조합형은 겹친다.

그렇기 때문에 조합형은 tail byte가 대문자 알파벳과 소뭇자 알파벳이 제각기 따로 될 수 있고 심지어 \ 역슬래시 문자가 나올 수도 있다. 이런 이유로 인해 조합형은 1비트 + 초중성 5비트씩 한글의 구성 원리를 매우 잘 반영하여 설계된 문자 코드임에도 불구하고 당시 8.3 제약이 있던 시절에 파일 이름을 사실상 한글로 지정할 수 없었으며, 심지어 이론적으로는 // 주석을 조합형 한글로 지정한 경우 \ 때문에 2-byte aware 하지 않은 컴파일러에서는 충돌이 발생할 수도 있었다.

옛날에 한글 MS-DOS 시절에 한글 도스 셸이나 QBasic처럼 텍스트 GUI(?)를 구현한 프로그램들을 실행해 보면 한국 마소가 굉장히 잘 만든 게 있었다. 메뉴나 대화상자 같은 게 표시되어서 배경에 있던 2바이트 텍스트를 반토막 내더라도 깨진 문자열을 보여주는 법이 결코 없었다. 늘 짝수 바이트가 유지돼야 하는 한글/한자 영역이 홀수 바이트로 줄어들면 가장자리를 하나 삭제해 주면 된다.

그러나 문맥 의존적인 문자 코드로 그런 걸 구현하려면 문자열을 처음부터 읽어 봐야 하고, 두 바이트 중 하나가 소실됐을 때의 뒷처리가 문맥 독립 코드보다 더 어려우면 어렵지 쉽지는 않을 것이다. 불가능하다는 뜻은 아니지만.

조합형을 옹호하고 완성형을 까기에만 바쁜 분들의 심정이야 세벌식+한글 에반젤리스트로서 본인은 적극 이해한다. 그러나 과거의 2바이트 한글 코드의 이면엔 이런 면모도 있었음을 지적하고자 한다. 완성형은 여러 이슈가 얽혀서 그렇게 만들어졌지, 작정하고 한글을 난도질하려는 악의적인 의도로 만들어진 건 아니었다. 문맥 독립성뿐만 아니라 굉장히 보수적인 국제 규격 권장 사항을 만족하는 방식으로 문자 코드를 만들려다 보니, 한글 11172자에다 한자와 각종 특수문자들까지 넣을 절대적인 공간 자체가 부족했기 때문이다.

나중에 완성형에다 어거지로 한글 부족분을 채워 넣은 cp949 확장완성형은 어차피 조합형처럼 문맥 독립성이 깨졌다. 물론, 어차피 이렇게 만들 거면 처음부터 조합형으로 가지 하는 비판은 피할 수 없게 된 게 사실이다. 그런데, 이런 비슷한 삽질을 일본도 문자 코드를 만들면서 했으며, 이를 우리나라도 그대로 답습했을 뿐이다.

조합형과 완성형은 11172자와 2350자의 차이뿐만 아니라 한글 낱자를 표현하는 방식에서 매우 큰 차이가 있다.
조합형은 글자마디와 자모의 차이가 사실상 없다. 그냥 초 중 종성 중 한 성분만 있으면 자모이고, 초성과 중성이 갖춰졌으면 글자마디이다. 초성 ㄱ과 종성 ㄱ을 구분해서 표현할 수 있고 초성+종성이나 중성+종성 같은 '미완성 한글'도 얼마든지 표현할 수 있다.

그러나 완성형엔 그런 개념이 없다. 한글 입력을 처음 시작했을 때 쓰라고 '호환용 한글 자모'라는 게 있는데 그건 한글이 아니라 명목상으로는 '특수문자' 영역이다. 그냥 한글 자모 모양인 그림일 뿐이다. 초성+종성 구분이나 미완성 한글 표현 같은 건 없다.

메모리 1바이트가 아깝던 16비트 도스 시절에 국내에서는 조합형 한글 코드+글꼴이 쓰였지 마소의 윈도처럼 2350자 완성형 코드+글꼴로 돈지랄을 하는 프로그램은 전혀 없었다. 이런 압도적인 인지도의 차이로 인해 조합형은 1992년에 한국의 복수 표준으로 승격되어서 cp1361이라는 이름으로 나름 운영체제의 코드 페이지에 등록도 됐다.

자, 이렇게 컴퓨터는 1바이트 인코딩에다가 한중일 문화권을 위한 1+2바이트 멀티바이트 인코딩 구도가 유지되었고 마소에서는 이를 도스 시절부터 코드 페이지라고 불렀다. 그런데 이런 문자 코드들은 (1) 알파벳· 숫자 같은 공통 문자를 제외하면 같은 문자라 해도 국가마다 배당된 코드값이 같을 수가 없고, (2) 문자 집합 자체의 크기가 너무 작아서 세계 모든 문자들을 한 코드 페이지에다 담을 수 없다는 문제가 있었다.

人(사람 인)이라는 한자가 한국· 중국· 일본의 표준 코드에서의 코드값이 같을 리가 없으니 (1)은 자명한 문제다. (2)의 경우, 2바이트 코드라 해도 앞서 보았듯이 1바이트 문자와의 충돌을 피하기 위해 매우 제한된 영역의 바이트들만 묶을 수 있다. 이 때문에, 문맥 의존까지 시킨다 해도 추가로 만들 수 있는 문자는 1만여 자에 불과하다. CJK에서 쓰는 상용 한자들이나 간신히 다 집어넣을 정도이다.

그래서 1980년대 말부터 이런 발상의 전환이 이뤄졌다. “앞으로 컴퓨터의 메모리는 증가하고 소프트웨어 국제화의 중요성은 커질 테니, 글자 하나의 크기를 16비트로 쿨하게 확장하고 6만여 자의 공간에다가 전세계 언어 문자들을 집어넣고 동일 문자 동일 코드값을 실현하는 게 어떨까?”

이것이 바로 유니코드의 존재 목적 되시겠다. 컴공 전공자가 아니더라도 컴퓨터에서 '유니코드'라는 말은 한 번쯤은 다들 들어 보셨을 것이다. 이건 그야말로 컴퓨터 문자 코드계의 바벨 탑 내지 에스페란토 같은 물건이다.

마이크로소프트는 소프트웨어의 국제화에 굉장한 혜안이 있던 기업이었다. 그래서 OS/2와 결별하고 Windows NT를 첫 개발할 때, 애초부터 8비트 문자가 아니라 유니코드를 담을 수 있는 16비트 문자를 기반으로 설계했다. 심지어는 NTFS 파일 시스템까지도. 그리고는 이를 독자적으로 wide character이라고 부르기 시작했다. 어차피 8비트 문자만으로 충분하던 라틴 문화권에서는 별로 득이 되는 것도 없이 메모리 사용량만 두 배로 뻥튀기되는 대가를 감수하고라도 말이다.

Win32 API는 기존 16비트 윈도 API를 최대한 닮게 설계되었지만, 문자열을 다루는 모든 API에 A 버전과 W 버전 구분이 생겼다. 다만, 32비트 시절에 처음으로 도입된 OLE/COM 같은 기술은 처음부터 오로지 유니코드(= wide) 문자열만 취급하게 만들어졌다.

PE 방식으로 만들어진 32비트 EXE/DLL은 string 테이블, 메뉴, 대화상자 같은 리소스의 저장 포맷도 다 유니코드 방식으로 바뀌었다. 윈도 3.1에다가 Win32s를 설치하면 32비트 커널 DLL뿐만 아니라 각종 코드 페이지 변환 테이블도 설치되는 걸 볼 수 있다. 그게 바로 리소스를 변환하기 위해서이다.

윈도 NT가 3.x나 9x보다 메모리 사용량이 매우 많았던 이유 중 하나도 유니코드 때문이며, 반대로 윈도 9x가 유니코드 API를 지원하지 않았던 이유도 가정용 PC의 부족한 메모리 문제 때문이다.
이 때문에 컴파일 스위치만 바꿔서 유니코드와 기존 멀티바이트를 모두 커버할 수 있는 TCHAR, _T 같은 개념도 그때 생겼다. 두 개의 문자 포맷을 모두 지원하는 작업은 정말 엄청난 대공사였을 것 같다.

Posted by 사무엘

2013/12/13 08:24 2013/12/13 08:24
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/908

1. 중국 (+대만, 홍콩, 마카오): 100%

중국어는 딱히 굴절이나 활용이 심하지 않은 고립형이고 1글자 1의미(형태소) 1음절이 성립하다 보니... 한자 같은 문자는 글자 수가 너무 많고 복잡하다는 단점을 빼면 자기 나라 말을 적는 데 그리 나쁜 솔루션은 아니다. 중국이 한자 종주국인 것엔 이유가 있는 셈이다. 물론, 그 단점이 꽤 큰 단점이긴 하지만 말이다.
중국어는 성조를 빼면 언어적으로 동음이의어도 많다. 그래서 한자로 '팔다'와 '사다'가 모두 같은 음(매)이고, 밝을 명(明)만 있는 게 아니라 어두울 명(冥)도 있다. 그걸 글자에다 뜻을 밝혀 적어서 구분하려는 생각을 한 듯하다.

이런 이유로 인해 중국은 한자 자체를 폐지하기보다는 획을 과감히 줄인 간체자를 만들어서 정착시켰는데, 이는 여타 한자 사용 국가들과의 단절과 혼란을 야기했다는 비판도 받고 있다. 지금과 같이 문자를 기계식이 아닌 전자식으로 다룰 수 있는 성능 좋은 기계가 일찍 발달했으면 쟤들은 굳이 간체자를 만들 생각을 안 했을지도 모른다.

2. 일본: 90% 보조 문자만 도입

일본어는 구조적으로 중국어보다는 한국어에 훨씬 더 가까운 언어이기 때문에 애초부터 한자만을 표기 수단으로 쓰는 것엔 불편함이 있었다. 일본어는 성조가 없고 음운 구조도 간단한 대신, 한자 하나를 여러 음절로 읽을 수 있고 훈독과 음독으로 모두 읽을 수 있다. 그래서 자기네 단순한 음운 구조에 맞춘 히라가나· 가타카나라는 표음문자를 보조적으로 덧붙여서 쓰고 있다.

한자를 없애고 고유 문자만으로 자기네 언어를 다 표기하는 건 불가능하지는 않다. 하지만 길어지고 보기 안 좋아지는 관계로 한자를 완전히 대체하는 건 영 한계가 있다. 마치 한글 자모가 단독이 아닌 모아쓰기를 전제로 만들어져 있는 것만큼이나 일본의 고유 문자는 한자 같은 여타 문자를 보조하는 용도로 만들어졌다는 성격이 강하다.

중국어와 일본어 텍스트에 쓰이는 복잡한 한자들은 한 글자씩 짜 맞춰서 입력하기가 너무 느리고 불편하다. 그렇기 때문에 문장이나 어절 단위로 더 긴 문자열을 입력함으로써 context를 만들고 후보 수를 줄인 뒤에 한꺼번에 변환을 한다. 즉, 이들 언어는 NLP 기술이 동원된 복잡한 입력 프로그램이 필요하다.

3. 한국 (대한민국, 북한): legacy로서 극소수 1% 미만. 고유 문자로 사실상 대체

교착어인 한국어의 복잡 미묘한 용언 활용을 한자로 제대로 표기할 수는 없는 노릇이며, 한국어는 음운 구조도 일본어보다 더 풍부하고 복잡하다. 이런 배경 속에서 세종대왕은 인류 역사상 유례를 찾기 힘든 똘끼를 발휘하여 세계가 놀라고 극찬하는 완전한 형태(full-featured, stand-alone)의 고유 문자를 만들어 버렸다.

한글은 단독으로 써도 시각성과 변별성이 충분히 우수하며, 한국어에서는 한자와 음의 대응이 일본어보다 훨씬 단순한 편이다. 의미상 모순되는 동음이의어만 피해 가면 한자 대신 고유 문자 전용이 어렵지 않게 가능하며, 그것이 이미 실제로 일어났다! 게다가 한글은 NLP 기술 없이 매우 빠르고 편리하게 입력도 되고 기계화가 가능하다.

그래서 20세기 중반 이후로 한반도에서는 한자가 빠른 속도로 도태되어 사라졌으며, 한자는 아주 예외적인 상황에서나 희소하게 등장하는 물건이 되었다. 한국어가 중국어와 아예 완전히 다른 언어이고 한자 표기가 어울리지 않는 구조이기 때문에 이에 대처하는 솔루션도 아예 극단적으로 새롭고 과격하게 출발 가능했던 것 같다.

4. 베트남, 몽골: 0% 완전히 폐지하여 흔적조차 없애고 여타 문자로 대체

베트남은 로마자로 공식 문자를 바꾸고 한자를 폐지했다. 단, 베트남어는 중국어보다도 성조가 더 다양해서 이런 걸 알파벳에다 덧붙이는 표기가 꽤 복잡한 편이다. 그래서 베트남 문자는 로마자 기반임에도 불구하고 컴퓨터에서 마치 아랍어 같은 complex script로 분류되고 있다.

몽골은 먼 옛날에 한자를 잠시 쓰긴 했지만 이내 자기네 고유 문자 내지 러시아 키릴 문자로 문자를 갈아탔다. 그렇기 때문에 오늘날은 베트남보다도 더 한자의 흔적을 찾을 수 없는 나라이다.

내가 한자에 대해서 글을 쓰면서 늘 느끼는 점인데,
한자는 말을 받아 적는 여러 문자 중의 하나이며, 그냥 legacy 그 이상도 그 이하도 아니다. 그러니 각 나라마다 자기 언어 사정에 맞게 편한 대로 처분하면 그만이다. 간체자 개량을 하든, 보조 문자를 만들든, 아니면 다른 문자로 완전히 대체를 하든 말이다. 그리고 그건 아주 자연스러운 현상이다. 굳이 중국어 같은 언어를 쓰는 문화권이 아닌 이상, 저렇게까지 불편하고 무거운 문자를 굳이 고집할 필요가 전혀 없기 때문이다.

한중일 3국간의 한자 통합이 가능해서 사람들이 필담이 가능하다면, 그건 불가능한 것보다는 나을지 모르겠다. 하지만 그건 정치· 언어· 문화의 장벽을 감안했을 때 호락호락 가능하지 않다. 불가능한 걸 가능하게 만들겠다고 높으신 분들이 머리를 맞대고 고민해 봤자 돈과 시간 들인 것에 비해 영양가 있는 결과가 나오지는 않을 거라는 데 한 표 건다. 조금 심하게 말하면, 그건 같은 라틴 알파벳을 쓴다고 해서 유럽 국가들이 다 필담으로 의사소통이 가능할 거라고 생각하는 것만큼이나 무모한 발상이다.

한자는 원칙이 있는 것 같으면서도 결국은 없는 chaotic한 글자이다.
뭔가 제자 원리를 봤을 때 한자처럼 생기긴 했는데 인류 역사상 그 어떤 문헌에도 존재한 적이 없는 '유령 한자'가 있다는 건 문자 코드에 관심이 있는 분이라면 이미 아실 것이다. 중국이나 일본에서 문자 코드를 제정하면서 글자들을 수집할 때, 어느 작업 인부가 실수를 한 모양이다.

빽빽한 중국어 자연어 텍스트처럼 생겼는데 실제로는 언어적인 의미가 전혀 없고 실존한 적이 없는 한자처럼 생긴 글자들로만 구성된 텍스트 디자인을 만든 사람도 있다. 그래, 한자는 역시 그런 문자이다.

Posted by 사무엘

2013/10/20 08:32 2013/10/20 08:32
, , , ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/889

한글 글꼴 처리 기술의 변천사

※ 0세대

0이라는 숫자는 뒤에 나올 1~3세대와 비교했을 때 '상대적인' 관점에서 붙여졌다. 1~3에 비해 0은 기계/아날로그적인 성격이 짙다.
한글을 모아쓰기+네모꼴 형태로 표현할 여건이 도저히 안 되는 환경을 말한다. 한 낱자를 상황에 따라 여러 벌로 분간해서 처리할 수가 없고, 최소 수천 자에 달하는 한글을 글자 단위로 부호화할 수도 없다.

옛날에 전보가 한글을 풀어쓰기 형태로 찍었다고 그러고, 김 정수 교수가 고안한 한글 두벌식 기울여 풀어쓰기도 0세대 기술이다. 굳이 풀어쓰기가 아니라도, 쓰이는 한글 몇 글자만 그림처럼 다루는 것도 딱히 기술이란 게 쓰인 게 아니므로 넓게는 0세대 기술로 간주한다.

그나마 0세대 기술 중에서 한글의 원리를 가장 잘 반영한 바람직한 기술은 공 병우 한글 세벌식 타자기, 그리고 그 이념을 물려받은 직결식 글꼴이다.

※ 1세대

제한된 벌수의 자모를 조합하여 한글 글자를 정사각형에다 모아쓰기 형태로 찍을 수 있다. 16*16 크기의 화면용 조합형 한글 글꼴이 바로 1세대의 상징이다.

옛날에 자체 한글을 지원하던 국내 도스용 프로그램들은 전부 이 수준의 기술을 사용하였으며, 도스용 아래아한글 1.x는 더 나아가서 간단한 수준의 옛한글과 자체 조합 로직까지 구현했다. 1세대 기술은 작고 간결하면서도 한글의 조합 원리와 무척 잘 부합한다는 큰 장점이 있기 때문에, <날개셋> 편집기 역시 최소주의를 추구하는 차원에서 딱 이 수준의 기술만을 의도적으로 고수하고 있다.

철도역 승강장의 전광판이 0세대인 롤지나 플랩에서 LED로 바뀌면서 1세대 기술로 한글을 표현한 것들이 많다.

※ 2세대

1세대보다 많이 발전했다. 8*16, 16*16의 한계를 벗어나 글자 크기를 자유롭게 조절할 수 있고 심지어 윤곽선 글꼴을 지원한다. 영문의 경우 W와 I의 폭이 다른 가변폭 글꼴을 지원한다. Windows의 경우 트루타입 글꼴이 도입되면서 글꼴의 기술 수준이 1.x세대에서 2세대 수준으로 껑충 뛰었으며, 아래아한글도 2.x 버전으로 넘어가면서 이 수준에 도달했다.

디스플레이 소자의 기술이 발달하면서 요즘은 전광판이 청색이나 흰색을 포함한 원색도 잘 표현하고 해상도도 더욱 높아졌다. 그래서 종전의 16*16만으로는 글자의 크기가 너무 작기 때문에 2세대로의 전환은 필수이다.
그러나 2세대 기술은 구현체마다 차이는 있지만, 1세대에 비해 한글 자체만의 조합 가능성이나 옛한글 표현 능력은 오히려 퇴보한 경우가 많다. 1코드 포인트당 반드시 한 글자가 대응한다는 한계에 여전히 매여 있기 때문이다.

※ 3세대

글꼴 처리 기술의 만렙으로, PC에는 21세기 무렵부터 도입되었다. 한글까지 가변폭 글꼴의 처리가 완벽하게 지원되며, 가변폭으로도 모자라서 커닝까지 처리된다. OpenType 기술을 이용하여 아랍· 태국어 문자까지도 꼼수 없이 잘 처리할 수 있을 정도인데 하물며 옛한글쯤이야 모아쓰기 형태로 표시를 못 할 이유가 전혀 없다.

유니코드라는 건 이런 글꼴 처리 기술과 결부되지 않을 수가 없는 규격이다. 그렇기 때문에 문자의 서식을 전혀 고려하지 않는 텍스트 에디터를 만든다 해도, 이제는 유니코드를 완벽하게 지원하려면 워드 프로세서를 만들 때나 필요할 것 같은 이런 기술을 어느 정도 사용하지 않을 수 없게 되었다.

3세대에서는 글꼴의 화면 렌더링도 단순한 grayscale 수준을 넘어서서 LCD 화면의 픽셀 구조에 특화된 subpixl 방식을 지원한다.

Posted by 사무엘

2013/08/31 19:47 2013/08/31 19:47
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/872

북한의 한글 서체

북한에서 만든 한글 서체의 중요한 특징 중 하나:
ㅌ을 E 모양이 아니라 ㅡ+ㄷ 모양으로 쓰는 걸 선호한다! 즉, 위의 가로줄을 아래의 몸통과 분리해서 따로 적는다는 뜻이다.

사용자 삽입 이미지

물론, 북한 서체 중에도 E자 모양인 물건이 없는 건 아니다.
그러나 일단 북한의 굴림-바탕-돋움-궁서에 해당하는 4대 기본 글꼴인 천리마-청봉-광명-붓글이 모두 ㅌ이 ㅡ+ㄷ모양이니, 북한에서는 이걸 ㅌ의 공식적인 기본형으로 간주하는 듯하다.

남한에서 쓰는 글꼴 중에는 ㅌ이 그렇게 돼 있는 물건은 진짜 궁서체밖에 없지 싶다.
북한이야 원래 문화가 196, 70년대-_-의 복고풍을 추구하고 서체도 순명조 내지 붓글씨 계열을 쓰는 걸 좋아하는 동네이긴 하지만, 명조 계열 서체까지 ㅌ을 그렇게 적는 관행은 남한에서는 좀체 찾아볼 수 없다.

북한과 한글 서체라는 두 분야에 모두 평균 이상으로 관심이 많은 나조차 이걸 눈치채는 데 시간이 굉장히 오래 걸린 이유는, 역시 ㅌ이 자주 쓰이는 자음이 아니기 때문이어서인 것 같다.

두음법칙만큼이나 한글의 자형의 미세한 차이도 남북의 문화 차이를 나타낼 수 있는 잣대가 된 듯하다.
원래 ㅌ의 모양은 ㅡ+ㄷ이 맞다는 설명도 옛날에 본 것 같으나, 그 근거를 모르겠다. 당장 훈민정음해례 같은 엄청 옛날 문헌을 봐도 ㅌ은 E 모양으로 그려져 있는데?

Posted by 사무엘

2013/07/23 08:36 2013/07/23 08:36
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/858

1. 라틴 알파벳의 위엄

오늘날 세계 문자들 중에 라틴 알파벳은 인지도와 실용성 면에서 단연 절대적인 '갑'임을 부정할 수 없다. 라틴 알파벳은 다음과 같은 여러 장점과 유리한 점이 있다.

  • 어느 한 국가나 민족만의 문자가 아니다. 물론 나라의 정서법마다 알파벳을 읽는 방식에 대동소이한 차이가 있어서 혼동스러운 면모도 있지만, 어쨌든 가장 국제적이다.
  • 음소문자여서 나름 다양한 언어의 말소리에 대응하기 유리하다. 또한 풀어쓰기를 하는 구조여서 언어의 다양한 음절 구조에 대응하기에도 유리하다.
  • 글자 수가 적어서 간편하며 활용하기도 쉬운 구조이다. 가령, 세계의 문자들 중에 기계식 타자기로도 만들고 또 겨우 8*8 크기의 비트맵에 각 글자의 모양을 다 담을 수 있는 문자는 얼마 되지 않을 게다.
  • 각각의 글자들이 들쭉날쭉하고 개성이 뚜렷해서 한데 뭉쳤을 때 시각성이 뛰어나며, 기호로서의 역할도 하기 좋다.
  • 타이포그래피 관점에서는 문자 차원에서 대소문자 구분이 존재하고, 또 이탤릭체 같은 같은 방식으로도 호소력을 높일 수 있다.

물론 라틴 알파벳은 표음· 음소문자라는 취지와는 달리 현실은 시궁창으로 언문일치가 개떡이며, 구조적으로 모음 글자가 너무 부족하다는 한계도 있긴 하다.

그럼에도 불구하고 라틴 알파벳은 신경 써야 하는 글자 수가 겨우 수십 개에 불과하기 때문에, 개개의 글자가 그야말로 왕이며, 서체 디자이너는 각 글자에 대해 완전 올인 몰빵 최적화가 가능하다. 이게 개인적으로 가장 부럽게 느끼는 점이다.
가령, A~Z까지 아주 정교하게 테스트된 수제 힌팅 프로그램을 집어넣는 여유를 부리는 건 이미 20여 년 전에 트루타입 글꼴이 처음으로 도입됐을 때부터 있었던 일이다.

그리고 요즘 글꼴이라는 건, 그저 코드값별로 고정된 글자의 폭과 벡터 이미지만을 기술하는 static한 데이터의 집합이 아니다. OpenType 기술 규격 덕분에 자기 옆에 무슨 글자가 오느냐에 따라서 다른 모양을 제공할 수 있고(GSUB), 폭을 미세하게 달리할 수도 있다(커닝.. 이게 개념적으로 더 확장되어 GPOS).

알파벳 정도야 문자 개수를 제곱해 봐야 몇백~몇천 정도까지의 조합밖에 안 나오니, 그 정도는 감당 가능하다. 한글이 '가' 할 때 ㄱ과 '고'나 '강' 할 때 ㄱ의 모양이 서로 달라지는 게, 알파벳으로 치면 W 다음에 A가 올 때와 W 다음에 P가 올 때의 간격을 미세하게 달리 설정하는 것과 같다는 뜻이다. 무슨 뜻인지 아시겠는가?

이런 기술은 이런 게 반드시 있어야만 정서법 차원에서 제대로 표시가 가능한, 복잡한 외국어 문자(complex script. 태국어나 아랍어 문자 같은)를 위해서 개발된 것이다. 그런데 라틴 알파벳은 원래 그런 기술의 도움을 받아야 할 정도로 복잡한 문자가 아님에도 불구하고, 더 정교하고 아름다운 타이포그래피를 위해 서체 디자이너가 그런 최신 기술까지 적용하여 시쳇말로 가히 잉여짓을 하고 있는 것이다. 가령, 라틴 알파벳도 아주 정교하고 미려한 필기체 중에는 그렇게 다이나믹한 표시 조건이 필요한 것도 있으니 말이다.

2. 반대편 극단에 있는 한자와 가나

이렇게 소수의 유한한 글자들이 왕인 라틴 알파벳 문화권에 비해, 글자 수가 엄청 많은 CJK는 상황이 굉장히 다르다.
한자는 전세계의 문자들 중 유일하게 '열린-_- 집합'인 무지막지한 문자 시스템이다. 덕분에 가변폭-_-이라든가 글자간의 다이나믹한 상호작용 같은 개념은 전혀 존재하지 않는다. 그래도 각각의 글자 자체가 워낙 그림처럼 생겼기 때문에 그 특성을 살린 타이포그래피가 존재한다.

거기에다 일본어 정서법은 한자에다가 자기네만의 간단한 표음문자가 더해져서 상황이 또 달라진다.
일본어는 입력하기가 굉장히 복잡하고 어려운 축에 든다. 그리고 '가나'라고 불리는 고유 문자는 구조적으로 불완전하며 한글에 비해 스케일이 작고 표음 능력에 한계가 있는 게 사실이다. 일본어 정서법은 가나 전용이 현실적으로 무리이다. 한자를 쓰지 않으면 안 되는 상황이며, 한글하고는 분명 상황이 다르다.

그러나 이런 형태가 단점만 있는 건 아니다. 굵직한 의미를 강조하는 한자와, 비교적 단순한 모양인 가나가 어우러지면 그것도 또 개성이 있으며 시각성이 살아나서 읽기도 꽤 좋다. 유식한 용어를 동원하자면 function word와 content word가 딱 잘 구분돼 보인다.
또한 입력이 어려운 대신, 한번 입력된 일본어 문장은 문자 차원에서 한자, 히라가나, 가타카나 같은 적지 않은 양의 NLP 정보가 담기기 때문에, 형태소 분석이나 번역을 의외로 유리하게 만들기도 한다. 히라가나-가타카나 구분이 라틴 알파벳으로 치면 대소문자에 얼추 비슷하게 대응한다고 볼 수도 있다(완전히 같지는 않지만).

3. 한글은 멀티 패러다임

자, 이렇게 라틴 알파벳 쪽의 정황과 한자 및 일본어 정서법의 정황을 살펴보았다.
그렇다면 세종대왕이 창제한 그 우수하고 독창적인 문자라는 '한글'을 사용하는 우리는 상황이 어떨까?

한글과 관련해서 우리가 절대로 간과해서는 안 되는 점은, 한글은 단일 패러다임만으로 설명이 되지 않는 문자라는 점이다. 단적인 예로, 단일 패러다임으로 설명이 되지 않기 때문에 한글이 총 몇 자냐는 질문에 24자부터 시작해 67자, 11172자, 심지어 160여만 자 같은 사람마다 뒤죽박죽인 대답이 나오는 것이다. 각각의 숫자가 한글의 규모를 어떤 관점에서 측정한 것이겠는지는 독자 여러분이 알아서 생각해 보시라.

차라리 한자는 총 몇 자냐는 질문에 대해 “아무도 모른다”라는 대답이라도 곧바로 나오지, 한글은 대단히 특이한 경우가 아닐 수 없다. 그래서 유니코드에는 고육지책으로 한글이 자모와 글자마디가 모두 등록되어 있으며 이것은 내가 보기에 나쁜 선택이 아니다. 그러나 한글을 바라보는 패러다임의 대립은 심지어 컴퓨터 전문가 사이에서도 거의 종교적인 신념의 대립에 가깝다. 이 말이 무슨 뜻인지 잘 모르겠으면, 본인에게 개별적으로 물으면 대답해 주겠다.

한글이 이런 유별난 위치에 있는 이유는 두 말할 나위도 없이 초-중-종성을 모아서 한 글자를 이루는 구조이기 때문이다. 만약에 한글이 IPA의 지위를 노리는 범용 음성 부호를 염두에 두고 만들어졌다면, 굳이 모아쓰기를 할 필요가 없다. 로마자의 예에서 볼 수 있듯, 풀어 쓰는 게 자음이나 모음의 중첩 같은 각종 외국어들의 변화무쌍한 음운 구조의 대처에 더 유리하다. 지금의 모아쓰기 체계는 모음의 발음이 분명하고 받침이 자주 등장하는 한국어의 음운 구조에 좀 더 최적화/로컬라이즈 전략을 선택한 귀결이다.

그래서 한글은 한국어의 음절 구분이 분명하며 시각성과 개성이 더 뛰어난 문자가 되었으며, 구조적으로는 알파벳 같은 계열보다 한자 계열과 좀 더 비슷한 형태가 되었다. 이 선택은 매우 큰 장점과 개성과 자부심을 가져온 것이 사실이다. 그러나 한편으로는 우리가 기술적으로 풀어야 할 과제도 많이 만들었다. 로마자처럼 소수의 글자를 최적화하고 품질을 다듬는 데 투자될 수 있는 기술과 노력이, 한글 조합 그 자체의 문제만을 푸는 데 다 소비되어 버리게 되었다. 입력이든 출력이든 모두에서 말이다.

다시 말해, 1만 개, 1백만 개, 심지어 1억 개의 글자를 조합해서 생성할 수 있다고 하는 한글의 그런 잠재성은, 알파벳처럼 개개의 글자마다 완전 정교한 힌팅, 커닝, 이탤릭, 필기체 따위로 최적화가 가능한 면모와 기술적으로 공존할 수가 없거나, 최소한 상호 조화시키기가 대단히 매우 어렵다는 뜻이다. 그렇다면 모아쓰기라는 걸 현실에서 반드시 절대적으로 일방적인 장점이라고만 간주해도 되는 것일까?

그래서 옛날 한글 선각자 중에는 로마자의 직관적인 기계화 기술과 먼치킨 급의 타이포그래피 최적화에 너무 한이 맺힌 나머지, “우린 안 될 거야 아마”라는 비관적인 결론으로 빠져서 아예 <글자의 혁명> 급으로 한글을 풀어쓰기 형태로 마개조할 생각을 한 분까지 있었다. 다중 패러다임이 독이라고 생각했던 것 같다.

물론 그 의도는 이해하지만 그건 너무 과격하고 비현실적인 주장이다. 개개의 한글 낱자는 마치 일본어 가나만큼이나 완성도가 부족하다. 가나가 한자와 섞어 쓰라고 만들어진 문자라면, 한글 낱자는 모아 쓰라고 만들어진 문자인 것이다. 한글 낱자만으로 풀어 쓰려면 진짜로 모음 ㅡ라면 U처럼 바꾸는 식으로, 글자 자형을 좀 더 변별성 있게 고쳐야 하고 맞춤법까지 대대적으로 손을 봐야 한다. 위험 비용이 너무 클 뿐만 아니라, 풀어쓰기를 실제로 오랫동안 시행해 본 분의 증언에 따르면, 한글 풀어쓰기의 시각적 능률은 모아 쓴 한글 음절을 도저히 따라갈 수 없었다고 한다.

4. 이제는 한글 자체의 고유한 특성을 살려서 입출력 기술을 발전시켜야

결국 이 모아쓰기에 따른 다중 패러다임은 우리가 한글을 고유 문자로 사용하는 한, 우리가 언제까지나 지고 가야 하는 숙제이다. 예전에 컴퓨터의 성능이 열악하던 시절에는 한글 같은 복잡한 문자를 심을 길이 안 보여서 풀어쓰기라도 생각해야 할 것처럼 상황이 암울했다. 그보다 상황이 약간 나아졌을 때에도 겨우 일본의 자국 문자 로컬라이즈 방식을 모방한 2바이트 한글 코드에다 전/반각 문자 따위밖에 선택의 여지가 없었다.

그러나 지금은 그런 기술적인 제약이 없다. 유니코드에, 화려한 OpenType 기술까지 완비되어 있는데 뭘 더 바라겠는가? 한글은 기계화가 유리한 문자인 건 명백한 사실이다. 그러나 딱 그거 하나만 믿고, 기계화 수준이라는 게 과거의 타자기 내지 2바이트 한글 코드 시절의 기술적 수준에서 멈춘 채 발전이 정지해 있다. 그런 낙후된 기술 수준은 한글에서 제한된 일부 패러다임밖에 수용을 할 수 없다.

일례로 입력부터 먼저 살펴보면, 15년도 더 전의 윈도우 95의 마소 한글 IME의 설정 대화상자와, 지금 윈도우 8의 한글 IME의 설정 대화상자는 제공하는 기능이 차이가 거의 없다. 이거 좀 문제가 있다.
어차피 조합이 필요하고 IME 같은 계층이 필요하다면 그걸 살려서 IME 계층이 있어야만 할 수 있는 일을 추가로 많이 지원해 줘야 한다.. 이것은 내가 <날개셋> 한글 입력기를 통해 어느 정도 기술적으로 실현시켰으며, 이 분야의 발전에 대한 필요성은 내 석사 논문에다가도 충분히 언급해 놨다.

출력 쪽도 마찬가지이다. 앞서 언급했듯이 라틴 알파벳은 적당히 꼬불꼬불하고 스스로 들쭉날쭉해서 보기가 좋으며, 일본어는 한자와 가나가 어우러져서 보기 좋다. 그렇다면 한글은 단일 종류의 문자가 빽빽하게 모였을 때 어떤 미를 추구해야만 할까?
이제는 한글도 한자 중심의 획일적인 정사각형 타이포그래피를 벗어나서 커닝도 생각하고, OpenType 기술을 적극 활용한 다이나믹 글꼴이 더 많이 나와야 한다. 한글은 굳이 한자가 섞일 필요가 없는 stand-alone, self-contained 문자이기 때문이다.

한글은 각 낱자는 직선 아니면 원밖에 없어서 기하학적으로 의외로 무척 추상적이고 단순하다. 그러면서 초중종성의 개성이 아주 분명하니, 한자나 로마자와는 달리 각종 로고타입이나 픽토그래픽으로 형상화하기가 좀 까다로운 면모가 있다(여전히 그림이나 아이콘 같아 보이지 않고, 글자처럼 보임). 그러나 그런 식으로 모아 쓰는 한글의 특성 때문에 오로지 한글에만 적용할 수 있는 글꼴이 나올 수도 있다. 모아쓰기를 그저 거추장스럽게 한글 자모를 정사각형에다가 예쁘게 끼워 넣는 overhead, burden으로만 받아들이지 말고 좀 더 창조적으로 활용할 수는 없을까? 이것이 내가 현재 고민하고 있는 분야이다.

요컨대,

  • 한글을 굳이 여타 문자와 더 비슷하게 만들어서 단점을 상쇄하려 하기보다는, 한글의 개성과 장점을 더 살린다. “넌 그걸 할 수 있냐? 난 그걸 못 하는 대신이 완전히 새로운 이걸 할 수 있다. 놀랍지?”를 지향한다는 뜻이다.
  • 한국어의 특성은 배제하고 오로지 한글의 형태 자체만을 생각한다.

이것이 내가 전통적으로 생각해 온 연구 방향이다. 입력기도 그렇고 글꼴도 그렇다. 더 이상의 자세한 설명은 생략한다. 연구 결과물이 다 나온 뒤에 빵! 터뜨려야 하는 것이기 때문에 당분간은 비밀이다. 그렇다고 해서 그렇게 심하게 거창한 건 아니고.. <날개셋> 한글 입력기도 겨우 1.x~2.x 시절에는 아이디어만 새로웠지, 기술적으로는 그다지 거창하지 않았으며 허접함 그 자체였었다.

이런 식으로 입력과 출력 모두에서 한글의 기술적 가능성을 한 걸음 확장하는 시도를 골고루 달성하고 나면, 그것이 대중적으로 성공하든, 아니면 너무 과격하거나 시장성이 없어서 실패하든 난 대한민국이라는 나라에서 태어난 보람을 느낄 것이고 죽어도 여한이 없을 것 같다.

Posted by 사무엘

2013/03/27 19:38 2013/03/27 19:38
,
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/811

한글 타이포그라피 학교 수강

1. 한글 운동꾼

평생을 '한글 운동'에만 몸바친 어르신이 한 분 계신다.
한글 운동이 뭐냐고? 일상생활이나 대외적으로(도로 표지판, 간판, 출판물 등) 최대한 한글을 많이 쓰게 하고 드러나게 하고, 세종대왕을 밀고, 덤으로 바른 한글 맞춤법과 순우리말을 가능한 한 미는 일체의 활동을 일컫는다. 한국어와 한글은 서로 다르지만, 그렇다고 완전 무관한 별개도 아니니...

일부 운동은 국문과 전공자가 보기에도 좀 과격하고 융통성 없어 보이고, 시대에 뒤떨어지는(?) 국수주의· 전투종족스러운 인상이 느껴지기도 할 정도이다. 허나 이런 분들의 헌신 덕분에 CJK 중 한국만이 한자를 일상생활에서 사실상 완전히 떼어 낸 편리한 자국 문자 전용을 이뤄 냈고, 끈질긴 전투 기질 덕분에 한글날을 빨간날로 추가하는 데 성공했다.

그 열정과 노력을 폄하하지 말지어다. 이거 그냥 된 게 아니다. 문자 습관이라는 건 인간 문화에서 굉장히 보수적이고 안 변하는 분야 중 하나이다.

내가 그분에 대해서 놀라는 면모는 인맥 네트워크이다. 한글 운동계에서 연륜과 짬밥에 관한 한, 이제 타의 추종을 불허하는 만렙이다 보니, 언어학, 공학, 역사학 등 갖가지 분야에 종사하고 있다가 뭔가 깨달은 게 있어 한글 덕후가 된 후학들은 알아서 이분을 제 발로 찾아가서 무릎 꿇고 “선생님, 한 수 가르쳐 주십쇼”를 한다. 자기 전공에서는 자신이 그 선생님과 비교가 안 되는 더 전문가인데도, 자기가 쓴 책이나 논문을 그분께 알아서 “드.. 드리겠습니다!”도 한다. 나 자신도 그분께 그랬고, 다른 사람들이 그러는 것 역시 내가 종종 봤다.

이쯤 되면 그분이 누구신지 눈치 채는 독자도 있을 것이다.
본인의 아버지보다도 연세가 더 많으신 그 운동꾼 선생님께서 쓰시는 글이나 주장은 내용이 거의 한글교 교리 수준이다. 내가 내 스스로 철도교 신자라고 하는 것만큼이나, 비하나 비꼬는 의미가 절대 아니니 오해하지 마시길.

그분은 늘 강조하셨다. “한글에 희망이 있다. 한글을 잘 활용하여 이 나라를 일으키고 잘 살아 보자. 한글 속에 (심지어) 돈벌이 아이템도 있다.”
과연 그럴까?

한글은 어린 시절부터 나의 오덕질 장난감이었다.
내가 비록 언어학이나 세계 문자학의 권위자는 아니지만, 그래도 주변의 메이저 문자들을 살펴봐도 세상에 조형적으로 이렇게 오묘한 문자는 없다. 단군의 후손들이 세계에 가장 강렬하게 내세울 수 있는 자기 정체성이자 고유 아이템은 아무리 봐도 한글밖에는 없는 게 분명해 보였다.
게다가 이런 문자가 그 정도의 수난사를 겪고 변모해 왔다니 피끓는 젊은 청춘의 감성을 자극하기에 충분한 수준이지 않은가?

2. 나의 적성과 진로 고민

그 원동력으로 본인은 지난 13년간 <날개셋> 한글 입력기를 만들었다.
이 분야와 관련된 완전 독자적인 노하우와 기술만 빼면 나는 그렇게까지 뛰어난 프로그래머가 아니며, 어쩌면 IT쪽 체질 자체가 아닌지도 모른다. 극단적으로 말하면, 10년쯤 뒤에 난 철도로 업종을 바꿔 있다 해도 이상할 게 없다.

남들은 다 대기업, 공무원, 의사 등등을 노리는데 난 도대체 무슨 부귀영화를 바라고서, 사용자가 1억도 안 되는 자국 문자를 위해 이런 일을 한 걸까?
난 지인들로부터 내 능력에 비해 내가 다닌 대학원이나 지금 다니는 회사의 수준은 아깝다는 말을 많이 들었다. 그 사람들의 말도 틀린 말은 아니다.

허나, 예전에도 이미 내 심경에 대해 토로한 바 있듯, 내가 지금과 같은 처지에 있게 된 이유는 간단하다. 나는 그것보다 더 수준 높은 대학원이나 연봉 캡숑 많이 주는 회사에서 하는 일에는 전혀 관심이 없고 그런 게 적성에 맞지 않기 때문이다. 평양 감사도 자기가 싫으면 그만이다. 내가 박사 진학에 괜히 실패했겠나?

<날개셋> 한글 입력기를 만드는 것 말고 다른 스마트폰용 소프트웨어를 개발하거나, 더 빠른 컴퓨터를 만들거나, 대박 내는 온라인 게임을 만드는 일엔 아무 관심이 없다는 것이다. 그건 나보다 더 똑똑한 공돌이들이 알아서 실컷 발전시켜 줄 분야들이다.
그렇다고 초창기 몇 년만 좀 허세 부리며 편하게 살자고 나의 피와 땀이 담긴 날개셋 핵심 기술을 대기업에다 홀랑 다 넘긴 뒤, 나중에 토사구팽 당하는 건 더욱 원하지 않는다. 그러니 나는 현실과 이상을 나름 가장 잘 절충한 지금과 같은 상황에 있게 된 것이다.

덕업일치를 바라지 않을 거면 차라리 나도 애초에 IT와 무관하면서 적당히 편하게 칼퇴근이 보장되는 공무원 사무직 같은 거나 구한 뒤, 퇴근 후의 개인 시간에 오덕질을 실컷 하는 게 좋지 않았을까 하는 생각도 가끔은 한다.

그러나 후회는 없다. 공무원 사무직이 무슨 동네 개 이름처럼 쉽게 구해지는 직업도 아닐 뿐더러, 그랬으면 또 그거 준비하느라 잃었을 기회비용도 만만찮고, <날개셋> 버전 자체가 애초에 지금과 같은 수준으로 올라갈 수도 없었을 것이다. 어쨌든 이 세상에 거저 되는 쉬운 일은 없다.

3. 글꼴 공부 시작

그래서.. 나도 나이가 있고 사회적인 책임이 있으며, 언제까지나 돈 안 되는 오덕질만 붙들고 있을 수는 없다. 어떻게든 내가 하는 일로 부와 명성을 쌓고 싶다. 나도 결혼도 하고 가정도 좀 꾸려야지 이제? -_-;;;

한글을 변형해서 무슨 외국어를 표기하는 문자를 만들고 보급..? 그런 건 지금까지 시행착오를 하도 많이 봐 왔고 이젠 바라지도 않는다.
무슨 맹목적인 한글 쇼비니즘 따위도 허상과 오류를 지금까지 이골이 날 정도로 경험했다.

그러나 그럼에도 불구하고 한글은 scope을 한국/한국어로 한정한다 해도 정말 뛰어나고 멋진 문자이다. 그냥 관습상 쓰던 것처럼만 활용하는 건 너무 아깝다.
한글로 이런 것도 할 수 있다는 것을 세계에 선보일 만한 아이템이 '아직까지는' 있으며, 남이 먼저 발견한 적은 없는 것 같다.
이걸 발굴하면 아까 그 운동가 선생님께서 부르짖으신 메시지가 실현될 가능성이 단 몇 퍼센트라도 더 높아지지 않을까?

그래서 한글 입력기로 시작한 연구를 출력에 해당하는 한글 글꼴로 끝낼 계획이다. 그래서 한글 공학의 종지부를 찍고 그랜드슬램을 달성할 수 있을 것이다.
박사 과정에 진학을 못 한 대신 자그마한 학원을 다니면서 수업을 듣고, 멘토 교수님과 종종 만나면서 연구를 할 생각이다.
2013년은 본인에게 한글 글꼴 연구의 원년이다.

Posted by 사무엘

2013/01/21 08:28 2013/01/21 08:28
,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/786

명조(바탕)체의 역사

오늘날 인쇄물에서 본문용으로 타의 추종을 불허하는 압도적인 지위와 인지도를 자랑하고 있는 한글 서체는 명조, 혹은 바탕체이다.

너무 흔하게 보는 서체여서 잘 모를 뿐이지, 명조는 상당히 미려하고 잘 만든 서체이다.
붓글씨 계열과는 미묘하게 다르고 그렇다고 펜글씨 계열과도 완전히 같지는 않은 그 획과 삐침들은, 명조와 같은 계열로 곁들여져 쓰이는 알파벳이나 한자 서체와는 성격이 다르다. 예를 들어, 한자의 삐침을 그대로 적용한 한글 서체는 '순명조'라고 따로 있지, 일반적인 명조가 아니다. 한글의 명조와 조형이 가장 비슷한 계열을 찾자면 차라리 일본 문자의 명조인지도 모르겠다.

그런데 이 명조체는 생각보다 역사가 굉장히 짧다. 역사가 100년도 채 안 됐다.
영문의 Times체가 1931년에 나와서 Garamond나 Bodoni에 비해서 굉장히 젊은 서체 소리를 듣는다만, 명조는 더 어리다.

한글 서체는 20세기 이전에는 전부 흔히 말하는 옛체든 궁서체든 목판체든 어쨌든 붓글씨 형태가 전부였다.
그러다가 일제 강점기 때 흔히 말하는 성경체(산돌성경체..!) 같은 궁서와 명조 사이의 짬뽕 과도기를 거친 후,
1939년에 소년조선일보를 통해 발표된 '박경서체'에서 그나마 명조의 전신이라 할 수 있는 프로토타입이 나왔다.
이제야 붓글씨 서체가 아닌 활판 인쇄용 한글 서체가 논의되기 시작한 것이다.

그 후 1958년에 국정 교과서 활자체로 지정된 '최정순체'가 오늘날의 모든 명조 파생형의 원조라 할 수 있는 명조다운 명조로 자리잡았다.
그리고, 한글 서체 디자인의 아버지인 최 정호가 원도를 그린 '동아출판사체'도 비슷한 시기에 나와서 해당 출판사에서 나온 책과 사전의 본문에 쓰였다.

사용자 삽입 이미지
* 출처: 명조체의 역사를 한눈에 잘 정리해 놓은 곳

아하! 나 이 서체 기억한다. 'SM세명조'는 이 '동아출판사체'를 얇게만 고친 버전과 거의 일치한다. 어쩐지 비슷하더라. 옛날에 동아 출판사의 책들만 본문 서체의 모양이 약간 다른 게 이유가 있었다.
훗날 1991년에는 명조 계열 한글 표준 서체라는 타이틀로 '문화바탕체'가 나온다. 문화바탕은 동아출판사체 이래로 ㅈㅊ의 세로 꼭지가 오른쪽 끝이 아니라 중앙에서 시작하는 명조 계열을 계승했다.

1990년대엔 PC에서는 아래아한글이 보급한 한양 시스템 명조가 히트를 쳤으나, 출판계의 대세는 최 정호의 원도를 바탕으로 만들어진 SM계열 명조였다.
그러다 21세기에 들어서야 더 동글동글한 명조인 윤명조 시리즈가 유행을 주도하며 오늘날에 이르고 있는 중. 그 전에는 산돌이나 윤 디자인 서체들은 사실상 매킨토시에서나 볼 수 있었다. PC에서도 그런 서체들을 쓸 수 있게 된 건 빨리 잡아도 90년대 후반부터이다.

2000년대 이후부터야 최 정순의 명조 원도에서 더욱 변화를 준 나눔명조, 함초롬바탕 등 여러 본문용 서체들이 계속해서 발표되고 있는 중이다.

이런 우리나라에 비해, 북한은 서체 하나만 봐도 정말 시간이 수십 년 전에서 정지해 있음을 알 수 있다.;;
북한 서체는 여전히 남한으로 치면 1970년대 같고, 틀에 박힌 동일한 조합 로직에다 글자 꼴만 양산형으로 바꿔서 찍어 내는 것 같다. =_=;;
글쎄, 이런 것도 우열이 아니라 문화적 상대성이라고 존중해 줘야 하는 건가..?

북한에서 쓰이는 본문용 서체는 청봉이나, 역시 우리나라 서체와는 형태가 살짝 다르다.
그리고 우리나라의 순명조에 해당하는 서체로 북한에는 '광명'이 있다.
남과 북은 글꼴도 서로 이질적으로 바뀌고 있는 셈이다.

Posted by 사무엘

2013/01/17 08:33 2013/01/17 08:33
, , ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/784

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/10   »
          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
31            

Site Stats

Total hits:
1670194
Today:
287
Yesterday:
598