2025년 새해가 밝은지 얼마 지나지 않았습니다. 개발자로서 해가 바뀔 때마다 묘한 긴장감을 느끼는 건 저뿐만이 아닐 겁니다. 2000년의 Y2K 사태를 직접 겪었거나 혹은 전설처럼 들어본 분들이라면 더욱 그렇겠죠. 오늘은 커피 한 잔 내려놓고, 일본 개발자들을 긴장하게 했던 '쇼와 100년 문제'에 대해 이야기해보려 합니다. 결론부터 말하자면 2025년 1월 1일 자정, 일본의 전산망은 멈추지 않았습니다. 하지만 이 에피소드에는 우리가 곱씹어봐야 할 엔지니어링의 본질이 숨어 있습니다.
일본은 그레고리력(서기)과 함께 천황의 재위 기간을 기준으로 하는 연호(Era name)를 공문서나 금융 시스템에서 널리 사용합니다. 올해 2025년은 '레이와 7년'이지만, 만약 1926년에 시작된 '쇼와' 시대가 계속되었다면 '쇼와 100년'이 되는 해이기도 합니다. 이게 왜 개발자들에게 공포의 대상이었을까요? 쇼와 시대는 1926년부터 1989년까지 무려 62년 넘게 지속되었습니다. 이 시기는 메인프레임 컴퓨터와 개인용 PC가 폭발적으로 보급되던 시기와 정확히 겹칩니다. 당시 개발자들은 메모리 절약을 위해 연도를 두 자리 숫자로 저장하는 경우가 많았고, 쇼와 연호가 이렇게 오래 지속되리라, 혹은 이 시스템이 100년 가까이 살아남으리라 예상하지 못했습니다.
우리가 흔히 겪는 기술 부채의 전형적인 모습이 여기 있습니다. 1989년 쇼와 천황이 서거하고 헤이세이 시대로 넘어갔을 때, 많은 시스템은 근본적인 데이터 구조를 바꾸는 대신 '쇼와 연도가 63을 넘으면 보정해서 보여주는' 식의 포맷팅 트릭(Formatting Trick)으로 떼웠을 가능성이 높습니다. 내부적으로는 여전히 쇼와 연도 기준의 두 자리 숫자를 카운팅하고 있었던 것이죠. 만약 그 로직이 그대로 2025년까지 살아남았다면, 카운터가 '99'에서 '00'으로 넘어가는 순간 시스템은 2025년이 아닌 1925년으로 인식하여 대혼란을 일으켰을 겁니다. 이것이 바로 일본판 Y2K라 불린 '쇼와 100년 문제'의 실체입니다.
다행히 1월 1일은 조용히 지나갔습니다. 이에 대해 두 가지 해석이 가능합니다. 첫째, 그 정도로 오래된 레거시 시스템들은 이미 물리적 수명을 다해 자연스럽게 도태되었을 가능성이 큽니다. 둘째, 엔지니어들이 사전에 치밀하게 대응했기 때문일 겁니다. 하지만 여기서 놓치지 말아야 할 기술적 디테일이 하나 더 있습니다. 개발자들이 흔히 저지르는 'Off-by-one error(1 차이로 발생하는 오류)'의 가능성입니다. 서기는 0년 없이 1년부터 시작하듯, 일본 연호도 1년(원년)부터 시작합니다. 만약 어떤 시스템이 내부적으로 인덱스를 0부터 시작하도록 설계되어 있고 출력할 때만 1을 더하는 방식이라면, 오버플로우 문제는 올해가 아니라 내년, 즉 쇼와 101년(2026년)에 터질 수도 있습니다.
저도 신입 시절, "이 코드는 임시로 쓰는 거니까 하드코딩해도 괜찮아"라고 생각하며 특정 날짜나 값을 고정해 둔 적이 있습니다. 그때 사수님께 코드 리뷰 시간에 호되게 혼났던 기억이 납니다. "네가 짠 '임시 코드'가 회사의 표준이 되어 10년 뒤에도 돌아가고 있을 수 있다"는 말씀이었죠. 실제로 제가 짠 코드가 레거시가 되어 후배들을 괴롭히는 상황을 마주했을 때의 그 부끄러움은 이루 말할 수 없었습니다. 쇼와 100년 문제는 단순히 날짜 계산의 문제가 아닙니다. '지금 내가 작성하는 코드가 내가 생각하는 것보다 훨씬 오래 살아남을 수 있다'는 엄중한 경고입니다.
우리는 지금도 클라우드 환경에서 MSA(마이크로서비스 아키텍처)를 구축하고, 최신 AI 도구를 활용해 코드를 작성합니다. 하지만 30년 뒤의 후배 개발자들에게 이 코드들이 또 다른 '쇼와 100년 문제'가 되지 않으리란 보장은 없습니다. 변수명 하나, 데이터 타입 하나를 정할 때도 미래의 확장성을 고민하는 태도, 그것이 10년 차 개발자가 된 지금도 제가 가장 중요하게 여기는 원칙입니다. 당장의 기능 구현도 중요하지만, 오늘은 100년 뒤에도 부끄럽지 않을 코드를 작성했는지 한 번쯤 되돌아보는 건 어떨까요?
