기 타 Y2K 유사 문제 - 2038년 문제와 GPS WNRO

1999년 12월 31일에서 2000년 1월 1일로 넘어가던 때 전세계는 Y2K 문제가 발생해 난리가 날꺼라고들 했었습니다.

아주 극소수의 분야에서만 문제가 발생했었고 대다수는 큰 문제없이 지나갔던것을 기억합니다.

비슷한 문제가 유닉스(리눅스) 시스템과 GPS에도 있습니다. 이름하여 각각 2038년 문제와 WNRO(Week Number Rollover)

먼저 유닉스 시스템을 살펴 보면 시간 표시를 32비트를 이용해 합니다. 따라서 UTC+00:00 기준 2038년 1월 19일 오전 3시 14분 07초(한국시간 2038년 1월 19일 오후 12시 14분 07초)가 되면 32비트로 표시되는 시간 정보가 01111111 11111111 11111111 11111111 이 됩니다. 그다음 초에 10000000 00000000 00000000 00000000 이 되어 컴퓨터는 현재 시간을 UTC+00:00 기준 1901년 12월 13일 20시 45분 52초로 표기해 엉망이 됩니다.

2038년이 먼 훗날처럼 생각되지만 오늘부터 19년 후 일이고 일로 하면 6653일 후의 일이며 1977년생이 61세부터 연금을 탄다고 가정할 때 2038년부터 연금을 수령하게 되는데, 만약 이들이 연금수령 예상액등을 조회할 경우 1970년부터 연금을 수령한다고 나올 수 있습니다. 태어나기전에 연금부터 수령하는 꼴...

시간 표시를 64비트로 하면 해결될거라 생각할 수 있지만 그렇게 하면 다른 프로그램들의 실행파일, 라이브러리등을 모조리 손봐야하는 엄청난 문제가 생깁니다.

참고로 64비트로 시간 표시를 하면 서기 292,277,026,596년까지 동일한 증상없이 사용 가능합니다. 292,277,026,596년이 읽기 힘들것 같아서 풀어 쓰면 서기 2922억 7702만 6596년입니다. 2922억 7702만 4577년 후의 일입니다. 현재까지의 우주 나이를 138억년으로 계산하면 21번 지나야 오는 엉겁의 시간입니다.

이를 잘 표현한 이미지입니다. 참고로 시간은 세계 표준시입니다.

이 문제는 리눅스 커널 4.18 이후에 해결되었습니다.

이번에는 GPS 시스템상 오류로 인해 발생하는 WNRO입니다.

GPS 시스템을 처음 설계할 때 1980년을 기준으로 주 표시를 1024비트를 이용해 표기했습니다. 따라서 1024주 후 즉 약 19.7년 후에 모든것이 리셋되어 다시 0이 됩니다.

1980년부터 19.7년이 지난 시점이 1999년에 한번 왔었고 지난 2019년 4월 7일에 두번째 주기가 도달해 문제가 발생했었습니다. 지난 4월 7일 이 문제를 해결하지 못한 구형 GPS 칩셋을 장착한 네비게이터등은 오류를 일으켰으나 uBlox 같은 GPS 칩셋이나 휴대전화에서는 미리 프로그램 패치를 해 문제없이 지나갔습니다.

Y2K 때도 마찬가지로 처음 프로젝트를 설계할 당시 미쳐 생각하지 못한 부분이거나 해당 시스템이 그렇게 오래 사용될 줄 예상 못해 생긴 문제입니다.

그러나 GPS 이후에 나온 위성 항법체계인 러시아의 글로나스나 유럽연합의 갈릴레오 그리고 중국의 베이도우(북극성) 시스템은 GPS에서 이미 겪었던 문제라 같은 문제는 발생하지 않습니다.