“지금은 이 문제를 당신에게 보여줄 수 없어요.” 아내가 남편에게 집 컴퓨터가 고장 났다고 불평했을 때, 남편이 왜 보여줄 수 없냐고 묻자 아내는 이해하기 힘든 대답을 했습니다. “오늘은 수요일이니까요.”
2009년, 우분투 커뮤니티는 기이한 시스템 버그를 겪었습니다. 많은 사용자가 OpenOffice를 통해 문서를 인쇄할 때 간헐적으로 실패하는 현상을 발견했습니다. 조사 초기 유일한 단서는 다른 애플리케이션의 인쇄 기능은 정상 작동하는데 오직 OpenOffice의 인쇄 작업만 블랙홀로 사라진다는 것이었습니다. 이에 따라 대부분의 개발자들은 OpenOffice 자체의 소프트웨어 결함이라고 의심했습니다.
재설치로도 해결되지 않는 화요일의 저주
일부 사용자들은 시스템 재설치라는 궁극의 해결책을 시도했습니다. 목요일에 재설치를 마치고 인쇄 테스트에 성공해 문제가 해결되었다고 믿었지만, 2주 뒤 화요일에 프린터는 다시 아무 소리 없이 작동을 멈췄습니다.
문제는 OpenOffice의 코드에 있지 않았습니다. 진범은 더 깊은 하부 구성 요소에 숨어 있었습니다. 리눅스 시스템은 file 명령어를 사용하여 파일 유형을 식별하며, 이는 커뮤니티가 수동으로 관리하는 1,600개 이상의 매직 패턴 규칙에 의존합니다. 시스템은 인쇄를 진행하기 전에 file 명령어로 파일이 PostScript 형식인지 확인합니다.
그림: PostScript 파일 헤더의 날짜 줄과 매직 패턴 규칙의 충돌. 출처: 자체 제작 다이어그램
2001년, file 규칙 데이터베이스에 Erlang JAM 파일을 식별하기 위한 규칙이 추가되었습니다. 하지만 공백 이스케이프가 누락되면서 규칙 내부의 Tue가 단독 매칭 항목이 되었고, 그 우선순위가 PostScript보다 높게 설정되었습니다. 이로 인해 파일에 Tue라는 문자열이 포함되어 있으면 시스템이 이를 Erlang 파일로 잘못 판단하게 되었습니다. 하위 구성 요소의 미세한 실수 하나가 전체 시스템의 정상 작동을 멈추게 한 것입니다.
달력이 가장 정확한 디버거다
화요일에 OpenOffice로 PostScript 인쇄 파일을 생성하면, 파일 헤더에 %%CreationDate: (Tue ...)와 같이 생성 시간이 자동으로 기록됩니다. file 명령어가 이 Tue를 스캔하는 순간, 이 파일이 인쇄용 문서가 아니라고 판단하여 프린터로 전송하는 것을 거부했습니다.
그림: 하부 레이어의 미세한 오류가 상위 애플리케이션의 작동 불능으로 이어짐. 출처: 자체 제작 다이어그램
2026년 현재까지도 15년 전의 이 이야기는 Lobsters 인기 게시물 2위에 올랐습니다. 커뮤니티의 개발자들은 이를 문제 해결 방법론의 살아있는 교재로 삼고 있습니다. 복잡한 현대 소프트웨어 공학에서 시간이라는 차원 자체가 기이한 오류를 해결하는 핵심 변수가 될 수 있음을 보여줍니다.
복잡한 시스템에서 중요하지 않은 구성 요소는 없습니다. 기초 도구의 규칙에 누락된 공백 하나가 프린터를 완전히 멈추게 만들었습니다. 특정 날짜에만 발생되는 오류를 만난다면, 어쩌면 달력을 가장 중요한 디버거로 삼아야 할지도 모릅니다. 본 분석은 현재의 엔지니어링 경험과 공개 커뮤니티 토론을 바탕으로 작성되었습니다.
참고 링크:
- OpenOffice는 화요일에 인쇄되지 않는다
- Lobsters 커뮤니티 토론 (s/im3eeh)
