d라이브러리

밀레니엄 버그에 대한 불안이 가중되고 있는 것은 일반인들에게 그 해결 방법을 알려주지 않기 때문이다. 알고보면 무서운 기세의 밀레니엄 버그도 타협선을 가지고 있다.

밀레니엄 버그(Y2K)는 컴퓨터에서 연도를 2자리로 표시했던 관행 때문에 발생한다. 그렇다면 2자리 연도를 4자리로 바꾸면 모든 문제는 해소될까.

Y2K의 본질적인 문제는 연도를 2자리에서 4자리로 바꾸면 거의 해결된다. 그러나 그게 전부는 아니다. 즉 우리가 맞게될 2000년은 너무 ‘0’이 많고, 윤년과 같은 문제가 도사리고 있기 때문이다. 만약 2000년 어느날 00시 00분을 입력하면 유니시스 2200과 같은 컴퓨터는 시스템 고장을 일으키고, 인텔 POS 단말기는 2000년을 1980년이나 1984년으로 환원시켜버릴 수 있다. 이같은 문제는 네트워크를 통해 다른 컴퓨터로 이전된다.

2000년은 2월에 29일이 있는 윤년이다. 그런데 1900년은 윤년이 아니었다. 그래서 앞으로 오게될 00년을 단순히 2000년으로 바꿨다가는 큰일이 난다. 1년은 대략 365.25일이므로, 4년에 한번씩 1일 더 넣은 윤년이 필요하다. 1백년의 윤년은 100의 배수이면서 400의 배수인 해로 정한다.

이처럼 복잡하게 얽혀 있는 Y2K를 한꺼번에 고치겠다고 덤비는 사람은 없을 것이다. 너무 많은 인력과 시간, 그리고 돈이 들어가기 때문이다. 가트너 그룹에서 보고한 바에 따르면 프로그램 1줄을 고치는데 1달러가 들어간다고 한다. 이를 기준으로 하면 세계적으로 6천억달러, 미국은 2천억달러, 우리나라는 90억달러가 Y2K를 수정하는데 들어간다.

또 한가지 주목할 점은 컴퓨터를 사용한지 얼마되지 않았다는 점이다. 즉 1900년과 2000년을 혼동할 경우 발생하는 문제는 주민등록번호와 같은 경우를 제외하고는 많지 않다. 물론 2000년 이후의 연도를 계속 2자리로 표시할 경우 자료분류(sorting)의 문제는 남는다. Y2K가 발생할 2000년 1월 1일이 불과 몇달 앞으로 다가왔더라도 이런 점을 감안해 우선 급한 것부터 고치면 대혼란은 예방할 수 있다.

Y2K를 해결할 때 제일 먼저 해야하는 일은 연도표시에 영향을 받는 프로그램과 파일을 찾아내는 일이다. 정보기술(IT) 분야의 경우 하드웨어(호스트 컴퓨터, 저장장치, 통신장비, PC), 시스템 소프트웨어(운영체계 프로그램, 소스 프로그램, 프로그램 언어), 각종 응용 프로그램, 데이터베이스 등이 있다.

다음에 할 일은 Y2K가 미치는 영향을 조사하는 영향평가. 여기서 어떤 것부터 고쳐야할지의 우선순위도 결정된다. 영향평가가 끝나면 우선순위에 따라 Y2K와 관련있는 날짜변수를 찾아내 변환하게 된다.

날짜변수는 소프트웨어를 이용해 기계적으로 찾아낸다. 날짜를 인식하는 변수 A가 B로 바뀔 수 있기 때문에, 제2, 제3, 제4의 관련변수를 찾아내는 것이 핵심기술이다. 그러나 소프트웨어가 변수를 찾아내는데는 한계가 있어, 소프트웨어가 해결하고 난 나머지의 변수는 인간이 찾아내야 한다. 엉뚱한 변수들이 곳곳에 숨어 있기 때문이다. 날짜변수를 찾는 일은 소프트웨어마다 만든 사람이 다르기 때문에 쉬운 일은 아니다.

문제가 될 변수와 데이터를 찾은 후에는 고쳐야 하는데, 여기서 잠깐 숨을 돌릴 필요가 있다. 돈과 시간을 절약하기 위해 모든 것을 다 고칠 필요는 없다는 것. 그래서 최소 프로그램만 고치거나, 중간에 데이터를 변환시켜주는 프로그램을 두는 경우가 많다. 당장 데이터가 문제가 되지 않을 수 있고, 또 언젠가 Y2K의 문제가 없는 새로운 프로그램으로 바꿔야할지도 모르기 때문이다.

서울시 영등포정수사업소가 2000년이 윤년인 점을 감안해 시스템의 연도를 16년 전인 1984년으로 돌려 놓은 것도 임시방편 중의 하나. 이 경우 데이터를 뽑을 때는 다시 16을 더한다. 만약 전국 7백여 정수장에서 이 방법을 채용한다면 7백억원에 가까운 Y2K 해결비용을 절감할 수 있다. 한편 한국쓰리엠, 존슨앤존슨메디컬과 같은 경우 28년주기론을 이용해 Y2K를 해결했다. 28년을 주기로 날짜, 요일, 윤달, 윤년이 반복되는 점을 이용한 것이다.

이렇게 변환이 끝난 프로그램들은 여러 가지 테스트를 거친다. 이 중에는 미래날짜 테스트와 연계 테스트라는 것이 있다. 미래날짜 테스트는 Y2K가 일어날 만한 날짜를 입력해 확인하는 방법으로 (표1)처럼 99 버그, 00버그, 윤년 등을 확인한다. 99버그는 일부 프로그램에서 9999를 정지명령으로 사용하기 때문에 발생하는 문제. 우리나라의 경우 99년 9월 9일을 99/09/09로 사용해 문제가 비교적 적다. 99/9/9로 쓰는 외국의 경우 99버그는 큰 문제다.

아무리 우리의 Y2K문제를 완벽하게 해결했다고 해도 이와 네트워크로 연결된 다른 곳의 프로그램이 말썽을 일으킨다면 그 영향을 받는다. 자동차를 운전할 때 다른 차의 실수로 일어나는 사고를 막기 위해 방어운전을 하듯이, 연계 테스트는 다른 프로그램으로 인한 사고를 예방하기 위해 꼭 필요한 것이다.

정보기술 분야는 Y2K에 대한 인식이 높아 일찍부터 서둘러 해결해 왔다. 그런데 비정보기술 분야는 그렇지 못해 큰 문제가 되고 있다. 비정보기술 분야라고 하면 마이크로칩이 들어있는 의료기기, 군사장비, 전자기기, 비행기, 자동차 등을 예로 들 수 있다.

비정보기술 분야는 정보기술 분야와 달리 사용자가 Y2K 문제를 파악할 수도, 고칠 수도 없다. 그래서 사용자는 제작사에게 문제가 있는지를 물어본 다음 문제가 있을 경우에는 마이크로칩을 교환하거나 새로운 기기를 구입해야 한다. 따라서 어떤 경우든 많은 돈이 들어간다. 여기서 주의해야 할 점은 가지고 있는 장비가 Y2K 문제가 있는지 없는지를 반드시 제작사에 문의한 후 이를 서류로 남겨놓아야 한다는 것이다. 그래야 나중에 문제가 생겼을 때 책임 유무를 가릴 수 있다.