2008년 03월 11일
유니코드에 관한 잡상.
조엘 씨 블로그의 주옥 같은 글들이 모여 출간된 『조엘 온 소프트웨어Click』는 유니코드에 대해 다음처럼 조언한다.
이 시점에서 저는 선전포고를 하겠습니다. 21세기를 살아가는 전문 개발자인 여러분이 문자, 문자집합, 인코딩, 유니코드를 모른다면 당신을 체포한 다음에 잠수함에서 6개월 동안 양파 껍질을 까는 벌칙을 줄 겁니다. 맹세합니다.
조엘 씨가 단지 Microsoft에서 일했다고 미국인인줄 알면 큰 오산인데, 그의 조국은 국민개병제를 채택한 이스라엘이다. 그렇게 보면 잠수함 내에서 화생방 훈련을 시키겠다는 농담이 농담처럼 들리지가 않는다.
이쯤에서 누군가는 약간 두려움을 느끼면서도 머뭇머뭇 손을 들고 반문할 것이다. “에이, 설마하니 현대인 중에 유니코드도 지원하지 않는 걸 만드는 프로그래머가 있겠어요?” 아이 참, 있으니까 조엘 씨가 저런 말씀을 하지요. 이 세상에 로마자를 제외한 글자라곤 히브리 문자나 그리스 문자밖에 없는 줄 아는 몰지각한 미국인 개발자를 한번 떠올려봅시다.
미국 국적 프로그래머는 실제로 U+00FF 상위에 존재하는 코드 포인트를 거의 사용하지 않은 일반 영문 텍스트를 바라보며, “저 많은 0을 보라!”고 외쳤습니다. 아, 물론 이런 불평은 냉소적이면서 자유분방한 캘리포니아 프로그래머 사이에서 터져 나왔습니다. 원리원칙을 따지는 텍사스 사람이라면, 게걸스럽게 두 바이트씩 먹어 버리는 상황에 대해 그렇게 개의치 않을 것입니다. 하지만 캘리포니아 꽁생원들은 문자열을 저장하기 위해 사용하는 공간을 두 배로 낭비한다는 사상은 결코 용납하지 않습니다. 또 다양한 ANSI와 DBCS 문자 집합을 사용한 수많은 빌어먹을 문서 전부를 도대체 누가 다 변환하겠습니까? 예? 지금 저를 지적하셨나요?
이 역시 조엘 씨의 익살스러운 언변으로서 UTF-8을 이야기하는 부분에서 발췌했다.
그런데 내가 왜 지금 이런 글이나 쓰고 있는가 하면…

…이름만 대면 날던 새도 떨어진다는 유명 게임음악 뮤지션 코우사키 사토루(神前暁) 씨가 글자 깨짐 현상에 봉변을 당해 팔자에도 없는 코우사키 코우(神前口) 씨로 개명되어버린 것이다.
WinAmp야 저렇게 플레이 리스트가 깨지긴 해도 문제 없이 작동하기 때문에 아쉬운대로 쓰고 있는데, 이미지 뷰어는 아예 없는 자식… 아니, 없는 파일 취급을 한다.

자자, 소녀가 임신했느니 어쩌니 하는 한자에는 신경쓰지 말고 ?로 표시된 부분에 주목합시다. 원래는 ‘お楽しみ 学芸会(즐거운 학예회)’인데 일본 한자가 깨지고 없다. 일본 한자를 한국 한자로 바꾸어 ‘お樂しみ 學藝會’라고 쓰면 문제될 게 없지만, 양국의 한자가 언제나 1대 1로 매치되는 것은 아니기에 완벽한 해결책이라고 볼 수는 없다.
object 님께서 쓰신 「VC++ 6.0을 쓰지 말아야 하는 이유Click」에서도 유니코드 문제가 언급되고 있다.
아직까지도 유니코드가 아닌 MBCS로 시작하는 (윈도우) 프로그래머가 있으면 이건 기본도 모르는 사람이다. “아직 저희 제품이 윈도우 98을 지원해야 해서…”라는 변명도 통하지 않는다. 그럴 경우에는 윈도우 95/98을 위한 Unicode Layer를 쓰면 된다. VS 2005에서 프로젝트를 하나 생성하면 디폴트가 유니코드이다. (…중략…) 따라서 아스키, MBCS를 써야할 이유가 이제는 없다. “윈도우 98 사용자들을 그래도…” 닥쳐라. 그냥 무시해라. 내 블로그 통계에 아예 Windows 98은 잡히지도 않는다. (ㅋㅋ)
영문 윈도우에서 non-Unicode 세팅을 영어로 했을 때, 여전히 ???와 같은 글씨가 보이는 프로그램들을 보면 한숨만 팍팍 나온다. 유니코드로 전환하는 것이 그렇게 어려운 것도 아니다. 사실, 제대로 공부 좀 했는 윈도우 프로그래머라면 10년 전부터 이미 TCHAR, _T(x)와 같이 Unicode prepared된 코드를 만들었어야만 했다. 그러나 위에서도 말했듯이 이제는 모두 NT 기반 커널을 사용하기 때문에 TCHAR을 사용할 필요도 없다. 그냥 바로 wchar_t, L"Hello, World!"로 하면 된다.
정말 동감이에요… 저도 ???와 같은 글씨가 보이는 응용프로그램들에 절망하고 있어요… 하지만 얼마 전까지만 해도 ‘2000년’은 절대 오지 않을 거라 생각한 엔지니어들이 너무 많았던 나머지 Y2K 버그라는 세계적인 해프닝을 치르기도 했으니 뭐, 글자 수 많은 나라에 사는 사람들마저 Unicode unprepared한 코드를 짜도 이상할 것 없는 게 현실이라면 현실.
내가 쓰는 이미지 뷰어는 ACD See v3.1 SR-1으로, 서구 중세사에서 르네상스가 태동할 무렵에 개발된 골동품이다. 지독하게 오래되었지만 그래도 구관이 명관이라고, 이미지를 보는 데 충실한 기능과 간결함 그리고 가벼운 구동에 매력을 느껴 아직까지 애용하고 있다.
그래, 이건 오래된 응용프로그램이라서 MBCS(ANSI)로 동작하는 거라고 눈감아줍시다. 그런데 십수 메가바이트에 육박하면서 왠갖 쓸데없는 기능들을 덕지덕지 붙이고 나온 최신 버전 ACD See를 비롯해 내가 테스트한 모든 이미지 뷰어가 유니코드를 제대로 지원하지 못하고 있다. 심지어는 한국인이 개발한 알씨마저도.
Windows XP 기본 응용인 ‘Windows Picture and Fax Viewer’를 제외하고 유일하게 다국어 지원이 되는 이미지 뷰어는 (내가 테스트한 것들 중에선) 구글 피카사 하나뿐이다. 아휴, 이름도 귀엽지. 그렇지 않아도 난 츠카사Click를 좋아하는데 이건 또 피카사라네.
구글 피카사는 언어에 대해서만큼은 완벽하다. 하지만 이미지를 보려고 하면 꼭 자체 데이터베이스로 import해야 하는 성미 까다로운 녀석이라 좋아할 수만은 없다. 단순미의 결여라고 하기엔 도가 지나친 복잡함. 일본 다도의 와비와 사비 정신까지는 바라지도 않는다. 왜 꼭 하드디스크에 있는 이미지를 전부 import하지 않으면 안 되는 거냐.
이 시점에서 저는 선전포고를 하겠습니다. 21세기를 살아가는 전문 개발자인 여러분이 문자, 문자집합, 인코딩, 유니코드를 모른다면 당신을 체포한 다음에 잠수함에서 6개월 동안 양파 껍질을 까는 벌칙을 줄 겁니다. 맹세합니다.
조엘 씨가 단지 Microsoft에서 일했다고 미국인인줄 알면 큰 오산인데, 그의 조국은 국민개병제를 채택한 이스라엘이다. 그렇게 보면 잠수함 내에서 화생방 훈련을 시키겠다는 농담이 농담처럼 들리지가 않는다.
이쯤에서 누군가는 약간 두려움을 느끼면서도 머뭇머뭇 손을 들고 반문할 것이다. “에이, 설마하니 현대인 중에 유니코드도 지원하지 않는 걸 만드는 프로그래머가 있겠어요?” 아이 참, 있으니까 조엘 씨가 저런 말씀을 하지요. 이 세상에 로마자를 제외한 글자라곤 히브리 문자나 그리스 문자밖에 없는 줄 아는 몰지각한 미국인 개발자를 한번 떠올려봅시다.
미국 국적 프로그래머는 실제로 U+00FF 상위에 존재하는 코드 포인트를 거의 사용하지 않은 일반 영문 텍스트를 바라보며, “저 많은 0을 보라!”고 외쳤습니다. 아, 물론 이런 불평은 냉소적이면서 자유분방한 캘리포니아 프로그래머 사이에서 터져 나왔습니다. 원리원칙을 따지는 텍사스 사람이라면, 게걸스럽게 두 바이트씩 먹어 버리는 상황에 대해 그렇게 개의치 않을 것입니다. 하지만 캘리포니아 꽁생원들은 문자열을 저장하기 위해 사용하는 공간을 두 배로 낭비한다는 사상은 결코 용납하지 않습니다. 또 다양한 ANSI와 DBCS 문자 집합을 사용한 수많은 빌어먹을 문서 전부를 도대체 누가 다 변환하겠습니까? 예? 지금 저를 지적하셨나요?
이 역시 조엘 씨의 익살스러운 언변으로서 UTF-8을 이야기하는 부분에서 발췌했다.
그런데 내가 왜 지금 이런 글이나 쓰고 있는가 하면…

…이름만 대면 날던 새도 떨어진다는 유명 게임음악 뮤지션 코우사키 사토루(神前暁) 씨가 글자 깨짐 현상에 봉변을 당해 팔자에도 없는 코우사키 코우(神前口) 씨로 개명되어버린 것이다.
WinAmp야 저렇게 플레이 리스트가 깨지긴 해도 문제 없이 작동하기 때문에 아쉬운대로 쓰고 있는데, 이미지 뷰어는 아예 없는 자식… 아니, 없는 파일 취급을 한다.

자자, 소녀가 임신했느니 어쩌니 하는 한자에는 신경쓰지 말고 ?로 표시된 부분에 주목합시다. 원래는 ‘お楽しみ 学芸会(즐거운 학예회)’인데 일본 한자가 깨지고 없다. 일본 한자를 한국 한자로 바꾸어 ‘お樂しみ 學藝會’라고 쓰면 문제될 게 없지만, 양국의 한자가 언제나 1대 1로 매치되는 것은 아니기에 완벽한 해결책이라고 볼 수는 없다.
object 님께서 쓰신 「VC++ 6.0을 쓰지 말아야 하는 이유Click」에서도 유니코드 문제가 언급되고 있다.
아직까지도 유니코드가 아닌 MBCS로 시작하는 (윈도우) 프로그래머가 있으면 이건 기본도 모르는 사람이다. “아직 저희 제품이 윈도우 98을 지원해야 해서…”라는 변명도 통하지 않는다. 그럴 경우에는 윈도우 95/98을 위한 Unicode Layer를 쓰면 된다. VS 2005에서 프로젝트를 하나 생성하면 디폴트가 유니코드이다. (…중략…) 따라서 아스키, MBCS를 써야할 이유가 이제는 없다. “윈도우 98 사용자들을 그래도…” 닥쳐라. 그냥 무시해라. 내 블로그 통계에 아예 Windows 98은 잡히지도 않는다. (ㅋㅋ)
영문 윈도우에서 non-Unicode 세팅을 영어로 했을 때, 여전히 ???와 같은 글씨가 보이는 프로그램들을 보면 한숨만 팍팍 나온다. 유니코드로 전환하는 것이 그렇게 어려운 것도 아니다. 사실, 제대로 공부 좀 했는 윈도우 프로그래머라면 10년 전부터 이미 TCHAR, _T(x)와 같이 Unicode prepared된 코드를 만들었어야만 했다. 그러나 위에서도 말했듯이 이제는 모두 NT 기반 커널을 사용하기 때문에 TCHAR을 사용할 필요도 없다. 그냥 바로 wchar_t, L"Hello, World!"로 하면 된다.
정말 동감이에요… 저도 ???와 같은 글씨가 보이는 응용프로그램들에 절망하고 있어요… 하지만 얼마 전까지만 해도 ‘2000년’은 절대 오지 않을 거라 생각한 엔지니어들이 너무 많았던 나머지 Y2K 버그라는 세계적인 해프닝을 치르기도 했으니 뭐, 글자 수 많은 나라에 사는 사람들마저 Unicode unprepared한 코드를 짜도 이상할 것 없는 게 현실이라면 현실.
내가 쓰는 이미지 뷰어는 ACD See v3.1 SR-1으로, 서구 중세사에서 르네상스가 태동할 무렵에 개발된 골동품이다. 지독하게 오래되었지만 그래도 구관이 명관이라고, 이미지를 보는 데 충실한 기능과 간결함 그리고 가벼운 구동에 매력을 느껴 아직까지 애용하고 있다.
그래, 이건 오래된 응용프로그램이라서 MBCS(ANSI)로 동작하는 거라고 눈감아줍시다. 그런데 십수 메가바이트에 육박하면서 왠갖 쓸데없는 기능들을 덕지덕지 붙이고 나온 최신 버전 ACD See를 비롯해 내가 테스트한 모든 이미지 뷰어가 유니코드를 제대로 지원하지 못하고 있다. 심지어는 한국인이 개발한 알씨마저도.
Windows XP 기본 응용인 ‘Windows Picture and Fax Viewer’를 제외하고 유일하게 다국어 지원이 되는 이미지 뷰어는 (내가 테스트한 것들 중에선) 구글 피카사 하나뿐이다. 아휴, 이름도 귀엽지. 그렇지 않아도 난 츠카사Click를 좋아하는데 이건 또 피카사라네.
구글 피카사는 언어에 대해서만큼은 완벽하다. 하지만 이미지를 보려고 하면 꼭 자체 데이터베이스로 import해야 하는 성미 까다로운 녀석이라 좋아할 수만은 없다. 단순미의 결여라고 하기엔 도가 지나친 복잡함. 일본 다도의 와비와 사비 정신까지는 바라지도 않는다. 왜 꼭 하드디스크에 있는 이미지를 전부 import하지 않으면 안 되는 거냐.
# by | 2008/03/11 01:15 | mono | 트랙백(1) | 덧글(10)






☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : 오늘의 한마디(Bill Gates)
Why did it take God only six days to create the world? He didn't have to worry about the installed base... - Bill Gates, Microsoft -...more
까마귀님// 맞아요. NT부터는 유니코드 기반으로 코딩하는 게 오히려 더 빠르고 안정적이라고 하지요? 사실 Microsoft에서 다 encapsulation 해놓은 문자 관련 라이브러리를 쓰니까 유니코드 지원도 대폭 수월해진 것 같은데, 듣자니 부분적으로 직접 implementation 해야 하는 데이터베이스 IO라든가 하는 작업에서는 아직도 유니코드가 골칫거리인 것 같아요. 말씀 들으니 프로그래미어신가 보군요? 골치 아프시겠어요. 힘내세요. :)
pond님// 앗, 그렇습니까? 어서 구해다 한번 써봐야겠군요. 정보 감사드립니다. :)
AnonymousY님// 8도 마찬가지예요.ㅠㅠ 다국어 지원만 제대로 된다면 느려터진 거 감수하면서라도 사용하고픈데...
독극물님// 앗! 반갑습니다. 저도 ACDSee2.43가 최고라고 생각해요. 저는 압축 파일을 해제하지 않고 봐야 할 일이 있어서 3.1을 쓰고 있긴 하지만 그 전까지는 2.X을 썼었어요. 정말 빠르고 시원시원하지요. ^^
리스트에서 깨지는것도 유니코드 지원 폰트로 리스트 폰트를 변경한 다음 사이즈를 조정해가면서 깨지지 않는 사이즈를 찾아야 -_-;;;
(제 경우 12에선 깨지는데 13에선 제대로 나오더군요 -_-;;;)
이미지 뷰어의 경우...
...하도 기다리다 지쳐서 직접 만들고 있습니다 -_-;;;
위에도 언급된 어샴프제품을 2년쯤 썼는데 도저히 익숙해지지가 않아서 ㅠ.ㅠ
이미지 뷰어의 경우... 저도 직접 만들어 쓸까 궁리중입니다. 헌데 위에 pond님께서 추천해주신 Brennig's를 한번 써봤는데, 저는 스크롤 속도가 느리다는 것만 빼면 이것도 꽤 맘에 드네요. +_+ 유니코드도 완벽 지원되구.
내가 몇년째 애용하는 프로그램.
가볍기도 무식하다 싶을 정도로 가벼운데다가
유니코드는 기본이고,
보면 알겠지만..... 지가 무슨 포토샵인줄 안다. -_-
(색감조정은 기본이고 필터에 매크로에.....)
게다가..... 공짜다.
내가 알기론 프랑스제 프로그램이여.
#Teminian Robin.
http://teminian.oladay.com
P.S:
한글 언어팩 지원된다.