Changwoo's Hacks

예전에 회사 팀장과의 에피소드:

팀장모씨: (팀원들에게) 리포트 쓸 때는 말이지 이건 저렇게 하고 저건 저렇게 하고..  그리고 전문용어 영어 단어같은 거 그냥 영어로 쓰라고. 다 알아들으니까 말이야.

창우: (속으로 투덜투덜...) 얼마나 다 영어로 쓰나요?

팀장모씨: 전부 다. 여기 단어 몇개 영어로 나온다고 문제 될거 없잖아? 오히려 엔지니어들한텐 그게 읽기 좋다고.

창우: 그거보다 훨씬 많아요. encoding, decoding, source code, compile, build, bug, editor, debugger, typing, ....  한글은 몇 개 안 남네요. (다 고쳐서 한 줄에 영어단어가 너덧개씩 있는 보고서를 보여준다) 자 이렇게 쓰면 가독성이 좋을까요?

팀장모씨: ...  (독해에 어려움을 겪는 모씨...)

썬의 번역 가이드

썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.

1.4.2한국어로 번역하지 않는 용어들 (Do not translate)

1. 고유 명사나 소프트웨어, 운영 체제 등의 고유 이름

MySQL (ODBC) -
PostgreSQL
MySQL (JDBC)  
Mozilla
Adabas D      
Microsoft Outlook
Oracle JDBC   
Microsoft Windows
JDBC          
LDAP
ODBC          
Evolution
XStorable
...

이 부분은 내가 오픈오피스 번역 중에서 가장 못 마땅하게 생각하는 부분이다. 번역 가이드의 다른 부분은 몰라도 위 사항은 절대 따르지 않고 번역이나 음역하기를 권장한다. 특히 Gnome은 영문 그대로 쓰지 말고 "그놈"이라고 표기하기를...

Branding

"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 3가지 방법 중에 하나를 선택하게 될 것이다.

1. 본래 브랜딩의 철자를 그대로 가져간다.
2. 본래 브랜딩을 그 나라의 언어에 맞게 음역한다.
3. 본래 브랜딩을 포기한다. 새로운 브랜드를 만들어 낸다.
   

실제로 한국에 진출한 글로벌 기업은 어떤 전략을 사용했을까?

영어 약자로 된 브랜드는 (KFC, HP, ...) 음역으로 쓸 수 없기 때문에 다른 선택이 없지만, 그 외에 1의 선택을 하는 경우는 의외로 별로 많지 않다. 길거리에서 영어로 가득한 간판을 보긴 하지만, "우리 STARBUCKS는..."이라고 회사 소개를 하지는 않는다. 거의 모든 회사가 "맥도나알드~"라고 멋드러지게 한글 음역을 이용하지 TV 화면을 영어로 가득 채우지는 않는다.  우리들도 일상 생활에서 "아웃백에서 봐요"라고 문자를 보내지 "Outback에서 봐요"라고 쓰지는 않는다. (게다가 1바이트 더 많다!)

3번째로 새로운 브랜드를 만들어 내는 경우도 잘 찾아보면 드물지 않게 볼 수 있다. 햄버거 체인점인 하디스(Hardees)는 미국의 찰스 쥬니어를 가져온 것인데 찰스 쥬니어는 말도 길어지고 왠지 맛있는 느낌이 안 나니까한국판에서는 새로운 말을 만들어 냈다. 한솥도시락은 일본의 도시락 체인점인 혼께가마도야의 메뉴와 시스템과 인테리어를 그대로 가져왔지만 이름은 우리말로 다시 지었다.

1과 2의 장단점을 적당히 취하는 경우도 볼 수 있다. 많이 사용하는 방법이 로고는 원래 영어가 들어간 로고를 무슨 그림 마냥 그대로 사용하면서 글자로 쓸 경우는 한글 음역을 사용하는 방법이다. (스타벅스, 커피빈, 아웃백 스테이크하우스, 리바이스, ...)  원래 로고와 한글 로고를 둘 다 만들어 놓거나 원래 로고의 영어에 한글 표기를 추가하는 식으로 동시에 사용하면서 글자로 표기할 때는 한글 음역을 쓰는 경우도 있다. (맥도날드, 버거킹, 철수하기 전의 월마트, ...)

하지만 로고나 간판을 원래 브랜드 그대로 이용하는 경우는 많아도, 일반 광고나 보도자료 등의 일반 텍스트 문서에서 영어 표기를 고집한 회사는 한국에 들어온 글로벌 기업중에 거의 없었다. (약자로 된 브랜드는 제외.) 몇가지 예외가 있으니 바로 소프트웨어 회사들이다. 마이크로소프트는 양지사 와의 상표 분쟁에서 패소했기 때문인지는 몰라도 "Windows 95" 이후 계속해서 한글마이크로소프트의 제품 설명에서도 "Microsoft Windows" 영문 표기를 고집하고 (그 전에는 "윈도우"라고 사용했다) 오피스의 경우에도 프로그램 메뉴에까지 "Microsoft Word"라고 영문으로 들어가 있다. 어도비, 오라클 등등 모두 영문 표기를 고집하고 있다. (하지만 광고나 그렇지 절대로 언론은 영문 표기로 보도해 주지 않는다.)

한글로 음역해서 쓰는 이유는 그게 세종대왕과 주시경선생께서 기뻐하시는 옳은 방향이라서가 아니라, 그게 더 올바른 브랜딩 전략이기 때문이다. 잠재적인 소비자들에게 쉽게 인식되고, 쉽게 기억되고, 눈에 잘 뜨이는 게 좋은 브랜드이다. 현재 평균적인 한국 소비자들은 왠만큼 교육 수준이 높은 경우에도, 영어 그대로 쓴 브랜드는 기억하거나 인식하기에 힘든 게 현실이다. 물론 본래 브랜드를 지역화하는 비용도 있고 본래 브랜드가 손상될 우려가 있어서 본래 로고를 남겨두고 일부만 지역화한다든지 선택을 할 수는 있다. 하지만 트레이드오프로 그런 선택을 할 수는 있어도 영어로 쓰는 게 한글로 쓰는 것보다 더 원래 의미를 전달하니까 좋은 브랜딩이다라고는 할 수 없다.  구찌, 버버리, 까르티에의 영문 철자를 기억하고 있는 사람이 얼마나 될까?  (소프트웨어 회사들이 예외적인 전략을 쓰는 이유는 한국의 소프트웨어 소비자들이 영어에 익숙하기 때문일까?)

에볼루션은 있는데 Evolution은 어딨지

썬의 번역 가이드는 첫째로 한국에 진출한 브랜드들이 취한 현실과 다르다. 위에서 말한 것처럼 한국에 진출한 글로벌 기업의 대부분은 브랜드를 한글로 음역했다. 특히 그놈 에볼루션은 분명히 (내가!) 한글로 "에볼루션"이라고 음역했고 한국어 데스크탑에는 프로그램 정보 창을 보지 않는 한, Evolution이라는 단어도 찾아보기 힘든데 예제에까지 "Evolution"이라고 써 놓는 건 맞지 않다.

또 (소프트웨어 회사들의 상업용 소프트웨어들도 그렇지만) 그 지역의 언어로 표기하는 편이 쉽게 인지되고 기억되는 더 좋은 브랜딩인데도, 왜 OpenOffice.org, Firefox 따위의 번역도 그 "OpenOffice.org", "Firefox"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)

그놈 에볼루션은 비교적 최근에 만들어진 메일 프로그램이라서 그런지 인터넷 메일의 표준에는 맞지만 현실과는 동떨어진 방식으로 동작하기도 한다. 슬프게도 한글과 관련된 부분에서 그런 모습이 많이 보인다.

예를 들어 좀 구버전의 MS-Outlook 혹은 MS-Outlook Express에는 헤더를 RFC2047 인코딩할 때 UTF-8로 인코딩하면 제대로 읽지를 못했다. 멀티바이트 인코딩은 본문 인코딩과 관계없이 대충 UTF-8로 보내는 정책을 사용했기 때문이다. 이렇게 동작하는 게 틀린 건 전혀 아니고, RFC2047을 지원하면서 UTF-8 인코딩이 지원되는 환경이므로 당연히 MS-Outlook의 잘못이고, 이 제목이 제대로 읽히도록 MS가 Outlook을 고쳐야 하는 게 맞다. 하지만 현실적으로 MS-Outlook은 사용자가 많아서 무시하기 힘든데다가 상업용 소프트웨어는 이러한 버그가 수정되려면 너무 오래 걸린다. (최근 버전에 고쳐질 때까지 2-3년은 걸린 듯)  표준을 지키는 다른 방법이 있으면서, 많이 사용하는 프로그램의 버그를 피해가는 방법이 있다면 꼭 에볼루션이 맞다고 고집할 필요는 없지 않을까? 하지만 게으른 개발자의 속성상 자기 잘못도 아닌데 귀찮게 고치기도 힘들 노릇이어서 결국 아직까지도 그렇게 동작한다. 내가 직접 본문이 EUC-KR일 때 제목이 EUC-KR 인코딩되도록 패치까지 만들었지만, 적용될 수는 없었다. (기술적인 이유도 있었다. 에볼루션의 코드의 메일 처리 라이브러리쪽에서 헤더를 독립적으로 UTF-8 인코딩해 버리는 구조였는데, 메일 설정이 넘어가도록 고치려면 상당히 귀찮은 작업이 필요하다.)

오히려 이런 문제는 MS-Outlook같은 데스크탑 프로그램보다는 각종 웹메일들에서 특히 잘 드러난다.  (아무래도 웹메일들이 데스크탑용 프로그램보다는 메일 표준을 구현한 완성도가 비교적 떨어지는 게 사실이다.)  마침 한메일이 개선사항을 모집한다고 하니 에볼루션과 한메일이 메일을 주고받을 때 생기는 버그 및 기타 리눅스 환경에서 생기는 문제를 짚어본다.

(1) Q 인코드된 제목의 디코딩

이 문제는 보고를 했는데 고객센터에서도 전달되었다고 하고, 다른 경로(?)로도 전달되었는데 우선순위가 밀렸는지 아직 버그가 남아 있는 상태이다.

위의 예에서와 같이 에볼루션에서 보내는 메일의 한글 제목은 UTF-8 인코딩하게 되는데, 그것도 Quoted Printable 인코딩이다. 그런데 에볼루션에서 메일을 이렇게 보내면,


한메일에서는 이렇게 공백이 밑줄로 나온다..


그런데 이상하게도 클릭해서 본문을 읽어보면 제대로 나와 있다.

Subject: =?UTF-8?Q?=EC=A0=9C=EB=AA=A9?=
        =?UTF-8?Q?_=ED=85=8C=EC=8A=A4=ED=8A=B8?=

"제목 테스트"라는 제목을 UTF-8 QP 인코딩하면 위와 같이 된다. RFC2047에 따르면 Quoted Printable을 디코딩할 때 밑줄(_)을 공백으로 해석해야 하는데 실수를 한 것 같다. 그런데 대체 왜? 메일 본문을 읽어보면 제대로 나오는 걸까? 메일 목록과 메일 본문의 QP 디코드 코드가 다른 걸까?


(2) 첨부파일 내용 인코딩

에볼루션이 아니라 (이제 거의 모두 UTF-8환경인) 리눅스 환경과의 호환성 문제이지만, 첨부 파일의 Content-Type의 charset 정보를 제대로 인식하지 않는다.


Content-Type의 charset 정보를 무시하고 EUC-KR로 해석하는 듯?
 

--=-ObVHrT1mp3C0HEttZi/U
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; name*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
=EC=97=90=EB=B3=BC =EB=A7=8C=EC=84=B8
 
 
--=-ObVHrT1mp3C0HEttZi/U--

(3) EUC-KR 페이지의 한계

다음이 많은 부분에서 UTF-8 페이지로 변환하고 있지만, 아직 한메일은 그렇지 못하다. 그래서 아무래도 해외 메일을 받는 용도로는 한계가 있을 수밖에 없다. 일본어 메일만 해도 많은 한자가 물음표 투성이가 된다.



(4) 보너스#1 - 빈 파일을 첨부하면

이 글을 쓰면서 발견한 건데...  사이즈가 0인 파일을 첨부한 다음에 첨부한 파일을 열려고 하면 오류가 발생한다.

--=-Jc22aP0z5j1kvSIVKmG+
Content-Description: =?UTF-8?Q?=EC=97=90=EB=B3=BC?=
    =?UTF-8?Q?_=EB=A7=8C=EC=84=B8=EC=97=AC?=
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
 
 
--=-Jc22aP0z5j1kvSIVKmG+--

(5) 보너스#2 - HTML 메일이 싫어요~

또 찾아낸 명백한 버그, 보낼때 하단에 있는 옵션을 어떻게 하든 항상 HTML 메일만 날아온다.

며칠에 걸쳐서 잠깐 잠깐씩, 재미가 없으면 내버려뒀다가 다시 생각나면 좀 만져보고 하는 일을 반복한 끝에...

lifepod openAPI의 인증 부분을 짰습니다.  며칠에 걸쳐서 lifepod API 서버의 버그로 잠깐 헤매다가, open ID에 http://를 넣었다가 뺐다가, 해시 부분을 소문자로 써야 하는 API의 숨겨진 사실을 깨닫기도 하다가, gnutls_fingerprint() 함수의 버그성 동작에 헷갈리다가 하면서 인증 부분만 완료.

• 상단의 openid, userkey, appid, appkey는 자기에 맞게 바꾸세요.
  
• 컴파일은 gcc -o example-lifepod `pkg-config --cflags libsoup-2.2` example-lifepod.c `pkg-config --libs libsoup-2.2`
• 스프(libsoup)는 GObject를 이용해서 만든 것이라서, synchronous하게 쓰려면 상관없지만 asynchronous하게 사용하려면 glib main loop가 필요합니다.

사실 인증보다 더 어려운 건 response로 날아온 XML을 파싱하는 거지만 그건 다른 종류의 내공이니까요. evolution frontend를 만드려고 했지만, evolution이 내부 데이터로 ical을 쓰고 있기 때문에 이건 lifepod xml to/from ical 변환 프로그램 만드는 꼴이 될 듯 합니다. 또 잠시 접어뒀다가 생각나면 조금씩 해 봐야죠.

(1)

RFC822에서 이메일 주소의 형식을 보면 다음과 같다.

addr-spec   =  local-part "@" domain        ; global address
local-part  =  word *("." word)                ; uninterpreted
                                                       ; case-preserved

local-part는 대소문자를 구별한다.  하지만 예전에 하이텔이 PC통신 회원들을 상대로 이메일 서비스를 개시할 때..  대소문자만 달라서 중복된 아이디는 구별되게 바꾸도록 조치했다.  학교 동기 중의 하나가 그 대상이었는데..  하이텔의 변명은 "메일 주소의 인터넷 표준을 따르기 위해"였다.  당연히 하이텔이 틀렸고, 복잡한 싸움 끝에 담당자가 "표준때문은 아니다"라고 인정하긴 했지만 아이디를 바꿀 수밖에 없었다.  :D  

진짜 이유는 이메일 서버들이 관행적으로 대소문자를 구별하지 않았기 때문이다.  지금도 아마 모든 어떤 메일 서버에서도 이메일 주소의 대소문자를 바꿔써서 보냈을 때 아마 같은 사람에게 도착할 것이다.  (이메일 주소마다 1개의 아이디만 만들 수 있는 웹사이트중에 어떤 경우는 이 점을 이용하면 아이디를 여러 개 만들 수도 있다.)

(2)

Evolution이 보낸 메일 제목이 MS Outlook/Outlook Express에서 깨져 나왔다.  (최근 버전의 Outlook에서는 올바르게 처리한다.)  그 이유는 Evolution이 메일 제목을 무조건 UTF-8로 RFC2047 인코딩해 버리기 때문이었는데, Outlook이 본문이 EUC-KR 인코딩되고 제목이 UTF-8 인코딩된 경우를 제대로 처리하지 못했다. 

결국 버그는 거부당했는데, Outlook의 버그일 뿐인데 왜 신경 써야 되냐는 얘기였다.  (사실 구조상 호환성을 깨지 않고는 고치기도 매우 어려웠기 때문에 좋은 핑계가 되었다.)

(3)

mediawiki에서 옛한글을 입력하면 유니코드에서는 자모로 "ㅈㅕㅇ" 세 개 자모를 입력해야 하는데 (ㅇ이 꼭지이응이라고 가정하면), mediawiki는 글을 입력하는 순간 이걸 "져ㅇ"과 같이 normalize해 버린다.  normalize해서 "음절+종성자모"로 만드는 게 잘못된 건 아니고 분명히 올바른 코드이지만, 문제는 옛한글을 지원하는 트루타입 글꼴이라면 보통 "ㅈㅕㅇ"을 제대로 음절로 표시하는 반면 "져ㅇ"은 제대로 표시하지 못한다.

mediawiki의 잘못일까?  유니코드 표준을 충분히 구현하지 않은 세상의 한글 글꼴들 잘못일까?


표준은 중요하지만, 표준보다 더 많은 것을 고려해야 할 때도 있고, 표준을 어기는 소프트웨어들을 욕만 할 수는 없고 맞춰야 할 때도 있다..  표준을 어기지 않으면서 맞추는 방법을 찾아야 겠지만?