나는 꽤 겸손한 사람이라 대부분의 사람들이 나에 관한 이 엄청나게 대단한 사실을 모른다. Raymond Chen이 클래식 Windows 개발 블로그인 The Old New Thing에서 나를 한 번 언급한 적이 있다는 사실이다.

물론 내 이름을 직접 언급한 것도 아니고 나를 특정할 수 있는 정보를 남긴 것도 아니지만, 이 놀라운 업적을 두고도 거의 자랑하지 않는 것만으로도 나는 충분히 칭찬받을 만하다.

내가 해결하려던 문제

Raymond는 글에서 나를 “고객”이라고 소개했지만, 당시 나는 사실 그의 Microsoft 동료였다. 대학교를 졸업하고 첫 직장으로 Microsoft에서 개발자로 일한 지 거의 2년이 되어가던 스물세 살 때였다.

나는 Windows에서 디스크 드라이브를 암호화하는 기능인 BitLocker를 담당하고 있었다. 당시 우리는 Windows 8 개발을 막 시작하던 참이었고, 내 프로젝트는 BitLocker의 설정 경험을 개선하는 일이었다.

BitLocker에는 관리자가 조직 수준 설정(Windows 용어로는 그룹 정책(Group Policy))을 통해 조정할 수 있는 수많은 세부 설정이 있었다. IT 관리자는 “조직 내 모든 BitLocker 암호는 최소 12자 이상이어야 한다” 같은 규칙을 조직 전체에 적용할 수 있었고, 그러면 BitLocker는 사용자들이 최소 12자 이상의 암호를 만들도록 강제했다.

BitLocker 설정에서 골치 아픈 점 중 하나는 오류 메시지가 모호하다는 것이었다. 예를 들어 암호가 최소 1000자 이상이어야 한다는 규칙을 설정하려고 하면, BitLocker는 “안 됩니다, 너무 깁니다” 같은 오류를 띄울 뿐 한계가 얼마인지는 알려주지 않았다.

Microsoft에서는 모든 사용자용 텍스트를 현지화 팀이 다른 언어로 번역해야 했기 때문에 C++ 코드 안에 오류 메시지를 직접 넣을 수 없었다. 그래서 모든 사용자용 텍스트는 다음과 같이 생긴 .mc 파일에 들어 있었다.

SymbolicName=ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG
The BitLocker minimum passphrase length is too high.
.
SymbolicName=...

그리고 C++ 코드 어딘가에는 이런 검사가 있었다.

#define MAX_PASSPHRASE_MINIMUM 20

UINT32 minimumPassphraseLength = ReadGroupPolicy(GP_BITLOCKER_MINIMUM_PASSPHRASE_LENGTH);
if (minimumPassphraseLength > MAX_PASSPHRASE_MINIMUM) {
  ShowError(ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG);
}

나는 BitLocker 오류 메시지를 바꿔서 오류가 발생한 구체적인 이유를 사용자에게 알려주고 싶었다. 그래서 이렇게 보이는 대신,

BitLocker 최소 암호 길이가 너무 길다.

사용자가 이렇게 보게 하고 싶었다.

BitLocker 최소 암호 길이는 20을 초과할 수 없다.

나는 C++ 코드에 있는 20이라는 값을 .mc 파일에 그대로 복사하고 싶지 않았다. 나중에 MAX_PASSPHRASE_MINIMUM 값을 바꾸게 되면 .mc 파일과 동기화가 깨져 오류 메시지가 틀리게 될 것이기 때문이다.

Raymond Chen이 어떻게 엮이게 되었나

나는 .mc 파일을 처리하는 Message Compiler 도구에 대해 잘 몰랐다. .mc 파일에서 C++ 값을 참조하는 예시를 하나도 찾을 수 없었지만, 분명 방법이 있을 것 같았다.

나는 사내 메일링 리스트에 .mc 파일을 이렇게 작성할 수 있는지 물었다.

SymbolicName=ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG
The BitLocker minimum passphrase length cannot exceed ${MAX_PASSPHRASE_MINIMUM}.

Raymond Chen은 이런 메일링 리스트에 자주 글을 올렸다. 2009년 당시에도 그는 이미 Microsoft에서 아주 오래 일한 베테랑이었고 Windows 개발과 관련된 모든 것에 대해 백과사전 같은 지식을 가지고 있었다. 그의 답변은 도움이 되고 권위 있었지만, 질문하기 전에 충분히 조사하지 않았다고 판단되면 비꼬는 투가 섞여 있었다.

내 기억이 맞다면, Raymond는 내 스레드에 “프리프로세서를 쓰지 말라는 법은 없다”라는 짧은 답변과 함께 프리프로세서 명령으로 .mc 파일을 생성하는 예시를 남겼다.

그가 무슨 말을 하려는 건지 이해하는 데도 한참이 걸렸다. C++ 컴파일러에게 전처리 단계만 실행하라고 시킬 수 있다는 것조차 몰랐기 때문이다.

Raymond Chen의 시간을 낭비한 셈이다

이 이야기의 부끄러운 부분은 위대한 Raymond Chen에게 조언까지 받고도 결국 그 방법을 쓰지 않고 꼬리를 내렸다는 것이다.

Raymond Chen은 블로그 글에서 Makefile에서 몇 줄만 바꾸면 소스 파일을 .mc 파일 대신 .mcp 파일로 만들 수 있을 만큼 간단하다고 설명했다. 너무 쉽다는 것이다!

하지만 Windows 빌드 시스템은 Makefile보다 무한히 복잡했다. 정확히 어떤 모습이었는지는 기억나지 않지만, 무섭고 혼란스러웠다는 것만은 분명하다.

더 나쁜 점은 빌드를 망치면 다음 날 아침에야 “당신이 nightly 빌드를 깨뜨렸다”는 이메일을 받고서야 알게 된다는 것이었다. 그 때문에 수십, 수백 명의 사람들이 당일 Windows 빌드를 받지 못하게 된 것이다.

그래서 나는 선택해야 했다. 빌드 시스템에서 처음으로 새로운 시도를 하며 예상치 못한 문제를 고치는 데 일주일이나 이주일을 허비할 위험을 감수할 것인가. 아니면 BitLocker 오류 메시지에 구체적인 숫자를 넣겠다는 아이디어 자체를 없었던 일로 하고 설정을 더 쉽게 만드는 다른 방법에 집중할 것인가.

나는 후자를 택했다.

지금도 여전히 해결 방법을 모른다

당시 나는 “와, C 프리프로세서를 이렇게 쓸 수 있다는 걸 몰랐다니 나는 바보다”라고 생각했던 기억이 난다.

대체로 몇 년 전에 애먹었던 소프트웨어 문제를 돌아보면 오늘날에는 해법이 훨씬 분명하게 보인다. 보통은 더 나은 해결책을 떠올릴 수 있다.

하지만 16년이 지난 지금도, C/C++ 파일이 아닌 파일에 C 프리프로세서를 돌리라는 Raymond의 해결책은 여전히 예상 밖으로 느껴진다. Raymond Chen에 대한 이 기억 하나를 제외한 모든 경험을 그대로 가지고 있다 해도, 같은 문제를 다시 해결하라고 하면 2009년만큼이나 헤맬 것 같다.

오늘날 다른 점이 있다면 이 문제를 해결하지 못했다고 해서 스스로 바보라고 느끼지 않는다는 것이다. 이제는 이를 Microsoft 내부 도구의 약점으로 본다. Microsoft의 대표 제품에서 개발자가 오류 메시지와 C++ 코드 양쪽에서 상수 값을 참조할 표준 방법이 없었다는 게 말이 되는가?

소프트웨어 엔지니어로서 어떤 문제는 불쾌해도 이를 악물고 연습해서 나아져야 한다. 다른 문제는 맡을 일과 프로젝트를 신중하게 고름으로써 그냥 피하면 된다.

난해한 빌드 시스템을 이해하는 일은 내가 피해 온 문제 중 하나이며, 그 선택에 만족한다. Nix를 쓸 때를 제외하고는 말이다.