글을 쓰는 일은 쉬운 일이 아니다. 자신의 생각을 글로 변환하는 과정이 어렵다는 얘기는 아니다. (물론 그것은 어렵다.) 약간은 성격 탓이기도 할텐데, 자신의 생각이 다른 누군가의 뇌리 속에 또는 영원히 검색 엔진의 캐시를 떠돌며 다른 사람들에게 보여질지도 모른다는 생각은 글을 쓰는 행위 자체를 불편하게 만든다. 글을 한번 쓰게 되면 관련된 모든 정보 – 초기 역사로부터 모든 권위있는 평가 – 를 모아서 써야한다는 강박증도 있다. 이런 강박관념을 떨쳐내야지 하면서도 매번 잊게 된다. 어차피 내가 쓴 글은 일시적인 나의 생각일 뿐이고, 수정 가능하며, 사람들이 심각하게 생각하지도 않는다는 것.

XP의 프랙티스 중에 Small Releases라는 것이 있다. 말그대로 작은 릴리즈, 즉 릴리즈를 작은 단위로 자주 하라는 것이다. 작은 릴리즈의 장점은 여러가지가 있지만 내가 얘기하고 싶은 것은 즐거움이다. 릴리즈를 하면 ‘뭔가를 만들었다는 기쁨’을 느낄 수 있다. 그런 조그만 즐거움은 그 일을 계속 즐겁게 할 수 있도록 해주는 힘이 된다. 하루만에 릴리즈할 수 있는 일은 하루만에 릴리즈하라. 퇴근할 때 즐거운 마음으로 퇴근할 수 있을 것이다.

다른 하나 중요한 것은 필요한 일의 양을 초과하지 않게 해준다는 것이다. 작은 릴리즈를 하기 위해서는 필연적으로 일의 범위를 줄일 수 밖에 없는데, 그 과정에서 핵심적인 일이 무엇인지 가려내는 작업이 들어가게 된다. 다음 릴리즈에서 그 다음으로 핵심적인 일이 무엇인지도 쉽게 파악이 될 뿐만 아니라, 핵심적인 일이 더이상 없다면 일을 하지 않아도 된다!

작은 릴리즈는 소프트웨어 개발에서만 적용되는 것은 아니다. 뭔가가 비효율적인 것 같다는 생각이 들면, 당장은 부족하다 싶을 정도로 시간 제약을 두고 다음으로 미루어라. 정말 중요한 것만 다룰 수 있게 되고 덜 중요한 것은 버려지게 될 것이다. 만약 중요하나 잊어버린 것이 있다면 자연스럽게 생각이 날 것이다.

예를 들어, 회의가 너무 짜증나게 길다고 생각되면, 당장 회의 시간을 반으로 줄여보면 된다. 부족하다고 생각될지도 모르지만, 의외로 알찬 회의가 될 지 모른다. 물론 모자랄 수도 있다. 작은 릴리즈의 정신은 조그만 실험을 반복함으로써 더 좋은 방법을 찾아나가는 방식이다. 실패를 두려워하지 말고 변화에 적응하라는 것은 그런 얘기다.

문득 매일 매일 일터에서 생각하고 다른 사람들에게 특히 후배들에게 얘기한 것들을 돌아보면서 어딘가에 남겨두면 나중에 좋은 기록이 될거라는 생각이 들었다. 이 글도 그런 작은 릴리즈의 시도 중 하나다.

리눅스 데스크탑에서는 VMware Workstation을 구입해서 윈도우즈를 사용하고 있고, 윈도우즈 데스크탑에서는 VMware player를 이용해 리눅스를 사용하고 있습니다. VirtualBox는 국내 리눅스 사용자들의 IRC 대화와 블로그를 통해 알게 되었는데, VirtualBox는 VMWare, Microsoft의 Virtual PC와 함께 국내에서도 어느 정도 지명도가 있는 VM 소프트웨어 입니다. VirtualBox에 대한 재미있는 소식이 있더군요.

Sun이 VirtualBox를 만든 Innotek을 인수한다고 합니다. (via Tim Bray)

VM 기술은 사용자에게 매력이 있는 기술이나 중요한 기술의 수준을 넘어서서, 기술 자산으로 보유할 매력이 있을만큼, 점점 보편화된 – 다르게 말하면 싼 – 기술이 되어가고 있는 것 같습니다. ‘싼 기술’이란 것은 중요하지 않다는 것이 아니라 ‘시장’이 그 기술이 중요하다는 것을 인정했다는 것을 의미하는 것이죠.

이 글은 최철호 군의 local function object를 stl algorithm function들에 사용하지 못하는 이유에 대한 답변입니다.

한마디로 말하면, 로컬 클래스(local class)는 템플릿 인자로 사용될 수 없기 때문입니다.

local function object는 로컬 클래스이고, for_each는 functor (function object)의 타입을 템플릿 인자로 받는 템플릿 함수입니다. 함수 인자로부터 템플릿 인자가 deduce되기 때문에 템플릿 인자가 생략되어 일반 함수처럼 보이는 것 뿐이죠.

템플릿 인자는 linkage를 필요로 합니다. 특정 템플릿 인자에 대한 템플릿의 인스턴스는 서로 다른 컴파일 유닛에서 사용되므로 특정 컴파일 유닛에 속한다고 할 수가 없을거라는 걸 생각하면 당연히 그럴테죠. (컴파일 과정에서 생성된 템플릿 인스턴스는 다른 소스 파일에 존재한다고 생각하시면 편합니다.)

한편, 로컬 클래스는 linkage가 없습니다. (C++ Standard의 [basic.link] 부분을 참조하세요.) 정확한 이유는 모르겠으나, linkage를 가지게 되는 순간부터 문법과 구현 모두 복잡해지기 시작할 것임을 쉽게 상상할 수 있습니다.

gcc 4.1를 사용한 컴파일에서는 ‘no matching function for call to …’와 같은 오류를 발생합니다. 이러한 오류가 발생한 이유는 이해할 수 있으나, 약간이라도 가능성이 있는 경우들을 잘 보여주지 않는 불친절한 gcc 컴파일 오류의 사례를 보여주고 있네요.

로컬 클래스의 인스턴스를 로컬 스코프에서 사용한 이런 자연스러운 경우를 표현하지 못하는 것은 좀 아쉽습니다. C++의 algorithm과 functional은 C++에서 빼놓을 수 없는 요소일 뿐만 아니라 그 사용이 상당히 권장되고 있습니다. 이 때 사용되는 functor들을 일일이 namespace 스코프에 정의해서 namespace에 난립하게 하는 것도 그다지 바람직하지 않은 것 같구요. 로컬 클래스는 오히려 functor와 같은 크기도 작고 용도도 한정적인 경우에 가장 유용하겠죠. 그래서인지 Anthony Williams에 의해 로컬 클래스에 linkage를 부여하자는 제안 (Making Local Classes more Useful)도 나와있네요.

유니코드 지원

프로그래밍 언어에서 유니코드 (Unicode) 지원은 크게 두가지로 나누어볼 수 있다. 바로 소스 코드(source code)에서의 유니코드 지원과 문자열(string)에서의 유니코드 지원이다. 소스 코드에서의 유니코드 지원은 문자열 리터럴과 클래스, 변수 이름과 같은 심볼들의 이름에서 유니코드 문자를 표현할 수 있음을 의미한다. 문자열에서의 유니코드 지원은 소스 코드에서의 유니코드 지원을 포함한다. 문자열에서의 유니코드 지원은 문자열 변수, 리터럴이 유니코드 문자를 표현할 수 있는가 뿐만 아니라, 문자열과 문자를 다루는 방법, 문자열과 바이너리의 구분, 여러가지 다른 인코딩으로의 변환 등을 포함한다.

이 글에서는 ‘문자열에서의 유니코드 지원’을 중심으로 얘기를 해보자.

C 문자열

C/C++, PHP, Python (< 2.0), Ruby와 같은 언어들에서는 다음과 같은 문자열을 가지고 있다.

• 문자열은 외부에서 주어진 인코딩으로 인코딩된 바이너리 형태며, 문자열 자체만으로 어떤 인코딩인지는 구분할 수 없는 방식.
• 문자열과 문자를 다루는 함수는 시스템 로케일 또는 컴파일러에게 주어진 설정에 따른 인코딩을 가정함.
• 이를 다른 인코딩의 문자열로 변환하는 방법을 문자열에 대한 언어적인 지원이나 라이브러리로 제공.

이러한 문자열 방식의 문제점은 그동안 수많은 프로그래머들을 괴롭혀온 것이라고 볼 수 있다.

• 유니코드 문자를 사용할 수 없다. 동시에 여러 문자집합을 사용하기 어렵다.
• 특정 문자집합 인코딩(charset encoding)을 가정하고 프로그래밍하는 경우가 잦아서, I18N이 매우 어렵다.

C와 함께하는 프로그래밍 역사에는 ‘a byte is a character’라는 생각이 깃들여있다. 하나의 문자가 실제로 ‘문자’에 해당하는 문자집합 인코딩을 가진 영어 또는 서유럽 언어에서는 크게 문제가 안되지만, 이른바 멀티바이트(multibyte) 문자열을 사용하는 한국, 중국, 일본과 같은 국가에서는 인코딩 지옥(encoding hell)이라고 부를만큼 사용자나 프로그래머들이 어려움을 겪어왔다고 볼 수 있다.

Java 문자열

Java는 유니코드 지원과 함께 탄생했다. 국제 표준에 해당하는 유니코드에 대한 개념이 그리 보편화되지 않았던 1996년에 Unicode 1.1을 반영하는 Java 1.0이 발표되었다.

• 타입을 사용한 문자열과 바이너리의 구분: 문자는 char형, 바이트는 byte형을 이용하고, 문자열과 바이너리는 각각의 배열로 표현한다. 문자와 이를 인코딩한 형태를 타입을 이용해 구분했다는 것은 당시로서는 획기적인 것이었다.
• 유니코드 문자집합 (UCS-2)의 지원: 내부적으로 2byte로 표현되는 char형은 유니코드에서 정의한 UCS-2 문자집합의 코드포인트(codepoint)에 해당했다. Java 5에서 Unicode 4.0을 반영하면서 char형은 UTF-16의 코드유닛(codeunit)을 나타내게 되었다.
• 문자열과 문자를 다루는 함수는 UTF-16 이외에 더이상 인코딩을 신경쓸 필요가 없게 되었음. (UCS-2에 속하는 문자만 사용한다면 아예 신경 쓸 필요가 없음.)
• 문자열을 특정 인코딩으로 인코딩하는 방법을 언어적인 지원과 라이브러리로 제공.

Java 초기에는 유니코드 지원으로 인한 성능 문제에 대한 논란이 많았던 걸로 기억한다. 지금 돌이켜보면, 유니코드 문자열의 도입으로 인한 성능 하락은 그리 큰 문제가 아닌 듯하다.

Java의 유니코드 지원 방식은 다른 언어들의 모범이 될만큼 깔끔하고 성공적으로 적용되었다고 생각한다. 개인적으로 가장 맘에 드는 Java의 특징 중 하나가 바로 유니코드 지원이다.

To Be Continued…

다음에는 C/C++의 wchar_t, Perl의 유니코드 지원, Python 2.0의 유니코드 문자열, Python 3000과 PHP 6의 유니코드 문자열, Ruby의 유니코드 지원에 대해서 다루어보겠다.

Excerpted from Wiki-inspired "transparent" search-engine by Cory Doctorow

But "security through obscurity" is widely discredited in information security circles. Obscurity stops dumb attackers from getting through, but it lets the smart attackers clobber you because the smart defenders can’t see how your system works and point out its flaws.

Jim Starkey, a Senior Software Architect for MySQL, said,

what a bother mapping back and forth between fixed-length declaration and variable-length storage! If the Standard would let us, the user could just say, "It’s a number—Just deal with it." Modern languages and frameworks have strings without size. Why not databases?

So that’s how I prefer to deal with ease-of-use versus performance: Make it easy for the user to let the software do the smart thing.

(…)

We’ll change the data model, the data types, the application topology, and the network interface, but they’ll still be relational databases.

S. Somasegar, Vice President of the Developer Division at Microsoft, said,

LINQ closes the gap between programming objects and data by providing a common query facility for in-memory and external data (external sources of data plug into LINQ by implementing a common query interface).