나는 꽤 겸손한 사람이라 대부분의 사람들이 내게 관한 이 엄청나게 인상적인 사실을 모른다. 레이먼드 첸이 윈도우 개발의 고전 블로그인 The Old New Thing에서 나를 언급한 적이 있다는 사실이다.

물론 그는 내 이름을 직접 언급하지도 않았고 내가 누군지 알 수 있는 단서도 남기지 않았지만, 나는 이 놀라운 업적을 거의 자랑하지 않는 것만으로도 충분히 칭찬받을 만하다.

내가 해결하려던 문제

레이먼드는 글에서 나를 “고객”이라고 표현했지만, 당시 나는 같은 마이크로소프트 직원이었다. 나는 23살이었고 대학을 졸업하고 첫 직장으로 마이크로소프트에 개발자로 입사한 지 거의 2년이 되어가던 때였다.

나는 윈도우의 디스크 드라이브 암호화 기능인 BitLocker를 담당하고 있었다. 당시 우리는 윈도우 8 개발을 막 시작하던 시기였고, 내가 맡은 프로젝트는 BitLocker의 설정 경험을 개선하는 것이었다.

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

BitLocker 설정에서 골치 아팠던 문제 중 하나는 오류 메시지가 모호하다는 것이었다. 예를 들어 암호 길이를 최소 1000자로 설정하려고 하면 BitLocker는 “안 됩니다, 너무 깁니다” 같은 오류를 띄우면서도 정작 한도가 얼마인지는 알려주지 않았다.

마이크로소프트에서는 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 파일과 동기화가 깨져 오류 메시지가 틀리게 될 것이기 때문이다.

레이먼드 첸이 끼어든 경위

나는 .mc 파일을 처리하는 Message Compiler 도구에 대해 잘 몰랐다. .mc 파일에서 C++ 값을 참조하는 사례를 하나도 찾지 못했지만, 분명 방법이 있을 거라고 생각했다.

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

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

레이먼드 첸은 이런 메일링 리스트에 자주 글을 올렸다. 2009년 당시에도 그는 이미 마이크로소프트에서 아주 오래 일한 베테랑이었고 윈도우 개발과 관련된 모든 것에 대해 백과사전 같은 지식을 갖고 있었다. 그의 답변은 도움이 되고 권위 있었지만, 질문하기 전에 충분히 찾아보지 않았다고 판단하면 빈정대는 투였다.

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

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

레이먼드 첸의 시간을 낭비하다

이 이야기에서 부끄러운 부분은 위대한 레이먼드 첸에게 조언까지 받고도 결국 그걸 활용하지 못하고 물러섰다는 점이다.

레이먼드 첸은 블로그 글에서 Makefile 몇 줄만 바꾸면 소스 파일을 .mc 파일 대신 .mcp 파일로 만들 수 있을 만큼 간단하다고 보여줬다. 정말 쉬워 보였다!

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

더 큰 문제는 빌드를 망치면 다음 날 아침 “당신이 nightly 빌드를 망쳤고, 이제 수십 명, 수백 명이 오늘자 윈도우 빌드를 받지 못하게 됐다”는 이메일을 받고 나서야 알게 된다는 것이었다.

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

나는 후자를 택했다.

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

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

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

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

오늘날 달라진 점이 있다면 이 문제를 풀지 못한다고 해서 스스로 멍청하다고 느끼지 않는다는 것이다. 이제는 이걸 마이크로소프트 내부 도구의 약점으로 본다. 마이크로소프트의 대표 제품에서 개발자가 오류 메시지와 C++ 코드 양쪽에서 상수 값을 참조할 표준적인 방법이 없었다는 게 말이 되는가?

소프트웨어 엔지니어로서 불쾌하지만 이를 악물고 연습해서 나아지는 문제도 있다. 반면에 맡는 일과 프로젝트를 신중하게 골라 아예 피하는 문제도 있다.

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