지난 2008년 12월 31일, 마이크로소프트의 MP3 인 Zune 30 Gb 모델이 부팅시 다운되는 버그가 발생하여 인터넷 상에서 화제가 된 적이 있었다. 국내에서는 Zune 사용자가 많지 않아서인지 그렇게 널리 알려지지는 않았지만...
(모 사이트에서 2000년대의 대표적인 IT 실패작 중 하나로 Zune 을 꼽기도.. )
Zune 의 부팅 버그를 일으킨, 문제가 된 소스 코드는 다음과 같다 한다.
7 번째 라인에서 days > 366 으로 되어 있어 day == 366 일 경우에는 처리가 되지 않고 무한루프에 빠지게 된다. 2008 년은 윤년이었고, 12월 31일이 2008 년의 366 일째 되는 날이라 12월 31일에 부팅시 다운되는 버그가 발생한 것. boundary value 체크가 안된 흔한 실수. 문제는 상용 프로그램에서 이런 코드가 작성되었다는 것인데...
7번째 라인에서 그냥 '=' 만 추가해서는 버그 수정이 안된다. 왜냐하면 7 라인을 if(days >= 366 ) 으로 고치면 366 일째에 year 가 증가하게 되므로 2008 년 12월 31일이 되는 시점에서 2009 년으로 year += 1 이 되는 것이지.
그러므로 이 코드를 고치려면, if( days > 366 ) 과 대응하는 else 를 추가해서 days == 366 일 째는 break 로 루프를 그냥 건너뛰게 만들고 367 일 째에 year 가 증가하게 하고 days -= 366 을 해야 한당.
Y2K 이야기가 한참 화제가 되었을 때, 우리나라 한 공기업(?) 정부산하기관(?)이 내부 장비들의 날짜표기를 일괄적으로 몇십년쯤 앞으로 땡겨서 문제를 해결했다고 합니다. 나중에 날짜가 겹치게 된다거나, 수정한 날짜표기가 다시 2000년이 되면 어떻게 할 생각이냐는 지적에 대해서는, 그날이 오기 전에 이 장비들은 전부 사용 연한을 넘겨 교체 될 것이라고 답했다는 것 같습니다.
'=' 이거 빼먹은거 같고만... ㅋㅋㅋ 가끔씩 할 수 있는 실수이긴하지.
내부테스트 역량의 문제인듯.
댓글이 재미있네...
7번째 라인에서 그냥 '=' 만 추가해서는 버그 수정이 안된다. 왜냐하면 7 라인을 if(days >= 366 ) 으로 고치면 366 일째에 year 가 증가하게 되므로 2008 년 12월 31일이 되는 시점에서 2009 년으로 year += 1 이 되는 것이지.
그러므로 이 코드를 고치려면, if( days > 366 ) 과 대응하는 else 를 추가해서 days == 366 일 째는 break 로 루프를 그냥 건너뛰게 만들고 367 일 째에 year 가 증가하게 하고 days -= 366 을 해야 한당.
Y2K 이야기가 한참 화제가 되었을 때, 우리나라 한 공기업(?) 정부산하기관(?)이 내부 장비들의 날짜표기를 일괄적으로 몇십년쯤 앞으로 땡겨서 문제를 해결했다고 합니다. 나중에 날짜가 겹치게 된다거나, 수정한 날짜표기가 다시 2000년이 되면 어떻게 할 생각이냐는 지적에 대해서는, 그날이 오기 전에 이 장비들은 전부 사용 연한을 넘겨 교체 될 것이라고 답했다는 것 같습니다.
다시는 문제될 일이 없으니 고칠 필요도 없다는 점에서는 붕어빵이군요
그런데... Y2K 문제가 나온 이유 자체가 2000 년쯤 되면 연도를 2 자리로 표기하는 코드들은 그때 쯤이면 모두 교체될 것이다~ 라는 생각에서 비롯된 것 아닌가영? ㅋㅋ
제 생각에 4 년후에도 Zune 30Gb 버전을 쓰는 사람이 여전히 존재할 것 같습니다... ^^