20년 묵은 버그를 잡다 — Enlightenment E16 윈도우 매니저 디버깅 이야기

20년이나 숨어있던 버그가 있다?

리눅스 데스크톱을 오래 쓴 분이라면 Enlightenment라는 이름을 한 번쯤 들어보셨을 거예요. 1990년대 후반부터 개발된 윈도우 매니저인데요, 그중에서도 E16은 가장 오래된 버전으로 아직까지 소수의 사용자들이 쓰고 있거든요. 그런데 이 E16에 무려 20년 넘게 숨어있던 버그가 최근에야 수정됐어요. 개발자 Iczelia가 이 버그를 추적하고 고치는 과정을 상세하게 공유했는데, 디버깅이란 게 어떤 건지를 아주 잘 보여주는 사례라서 소개해 드릴게요.

어떤 버그였나

문제의 증상은 이랬어요. E16 윈도우 매니저에서 특정 조건이 되면 창이 이상하게 배치되거나, 예상치 못한 위치에 나타나는 현상이 있었거든요. 사용자 입장에서는 "가끔 창이 이상한 데 가 있네" 정도로 느끼는 거라 심각하게 보고되지 않았고, 워낙 재현 조건이 까다로워서 오랫동안 방치돼 있었어요.

이게 뭐냐면, 윈도우 매니저는 화면에 떠 있는 모든 창의 위치와 크기를 관리하는 프로그램이에요. 우리가 창을 드래그해서 옮기거나, 최대화 버튼을 누르거나 할 때 그 동작을 처리하는 게 바로 윈도우 매니저거든요. 그래서 여기에 버그가 있으면 창이 엉뚱한 곳에 나타나거나 크기가 이상해지는 현상이 생기는 거예요.

디버깅 과정이 인상적인 이유

이 버그를 잡는 과정에서 가장 흥미로운 부분은 "오래된 코드베이스에서 버그를 찾는 방법론"이에요. E16은 C 언어로 작성된, 수십 년 된 코드베이스거든요. 최신 프로젝트처럼 테스트 커버리지가 잘 갖춰져 있지도 않고, 문서화도 충분하지 않아요.

개발자가 취한 접근 방식은 전형적이면서도 교과서적이었어요. 먼저 문제를 안정적으로 재현할 수 있는 조건을 찾았고, 그 다음에 관련 코드 경로를 좁혀 나갔어요. 20년 된 코드를 읽으면서 원래 개발자의 의도를 파악하고, 어디서 그 의도와 실제 동작이 어긋나는지를 추적한 거죠.

실제로 문제의 근본 원인은 좌표 계산 로직에 있었어요. 특정 상황에서 정수 오버플로우 비슷한 문제가 발생하거나, 경계 조건에서 예외 처리가 제대로 되지 않았던 건데요. 이런 종류의 버그는 대부분의 경우에는 정상적으로 동작하다가, 아주 특정한 화면 해상도나 창 배치 조합에서만 나타나기 때문에 재현이 어려웠던 거예요. 마치 1년에 한두 번만 나타나는 귀신 같은 버그인 셈이죠.

오래된 코드와 씨름하는 모든 개발자를 위한 교훈

사실 이런 경험은 레거시 시스템을 다루는 개발자라면 누구나 공감할 수 있을 거예요. 한국의 많은 기업에서도 10년, 15년 된 시스템을 유지보수하고 있거든요. 금융권의 코어 뱅킹 시스템이나, 제조업의 MES 시스템, 공공기관의 전자정부 프레임워크 기반 시스템 같은 것들이요.

이런 레거시 코드에서 버그를 찾을 때 중요한 점 몇 가지를 이 사례에서 배울 수 있어요. 첫째, 재현 조건을 찾는 데 시간을 투자하는 게 결국 가장 빠른 길이에요. "가끔 발생한다"에서 "이 조건에서 항상 발생한다"로 만들어야 디버깅을 시작할 수 있거든요. 둘째, git blame이나 커밋 히스토리를 통해 해당 코드가 왜 그렇게 작성됐는지 맥락을 파악하는 게 중요해요. 20년 전 코드라면 그때의 하드웨어 제약이나 API 한계 때문에 지금 보면 이상한 방식으로 작성됐을 수도 있거든요.

윈도우 매니저 생태계의 현재

Enlightenment E16이 아직 사용된다는 것 자체가 놀라울 수도 있는데요, 리눅스 데스크톱 세계에서는 꽤 흔한 일이에요. 지금 주류 윈도우 매니저나 데스크톱 환경을 보면 GNOME, KDE Plasma, i3, Sway 같은 것들이 있어요. 특히 최근에는 Wayland 프로토콜로의 전환이 큰 흐름인데, E16은 여전히 X11 기반이에요. Wayland와 X11의 차이를 간단히 말하면, X11은 1987년에 나온 디스플레이 프로토콜이고 Wayland는 그 한계를 극복하기 위해 2008년부터 개발된 차세대 프로토콜이에요.

이런 오래된 프로젝트가 계속 유지된다는 건, 오픈소스 생태계의 강점이기도 하고 동시에 도전이기도 해요. 누군가는 20년 된 코드를 읽고 버그를 고칠 수 있어야 하니까요.

한국 개발자에게 주는 시사점

이 이야기가 실무에 바로 적용 가능한 건 아니지만, 디버깅 마인드셋 측면에서 배울 게 많아요. 특히 "오래된 버그 = 못 고치는 버그"가 아니라는 점이요. 재현 조건만 찾으면 20년 된 버그도 고칠 수 있다는 사실은, 우리가 일상에서 마주하는 "원인 불명"의 버그들에 대해서도 희망을 줘요.

만약 여러분이 레거시 시스템을 담당하고 있다면, 이런 디버깅 사례를 팀 내에서 공유하는 것도 좋은 방법이에요. 디버깅은 혼자 하면 막막하지만, 과정을 문서화하고 공유하면 팀 전체의 역량이 올라가거든요.