---
title: "Excel은 아직도 1900년을 윤년으로 처리한다 — 그리고 고칠 생각이 없다"
published: 2026-03-15T23:34:35.000Z
canonical: https://jeff.news/article/623
---
# Excel은 아직도 1900년을 윤년으로 처리한다 — 그리고 고칠 생각이 없다

Excel이 1900년을 윤년으로 처리하는 것은 Lotus 1-2-3에서 시작된 의도적 버그. Microsoft는 호환성 때문에 이를 채택했고, 고쳤을 때의 피해가 더 크다고 판단해 40년 넘게 유지 중.

- 1900년은 윤년이 아님 (세기 연도는 400으로 나눠떨어져야 윤년). 그런데 Excel은 1900년 2월 29일이 존재한다고 가정하고 날짜를 계산함. 이 버그는 **Lotus 1-2-3에서 시작된 유산**임
- Lotus 1-2-3가 처음 출시됐을 때 1900년을 윤년으로 처리했는데, 이렇게 하면 윤년 처리 로직이 단순해지고 대부분의 날짜 계산에 실질적 영향이 없었기 때문. Microsoft Multiplan과 Excel이 출시될 때 **Lotus 1-2-3와의 호환성**을 위해 동일한 직렬 날짜 체계를 채택하면서 이 버그도 그대로 가져옴
- Microsoft의 공식 입장: 기술적으로는 고칠 수 있지만, **고쳤을 때의 단점이 안 고쳤을 때의 단점보다 크다**
- 고치면 생기는 문제들:
  - 기존 모든 Excel 워크시트와 문서의 날짜가 하루 밀림. 이걸 수정하는 데 엄청난 시간과 노력이 필요
  - WEEKDAY 같은 함수의 반환값이 바뀌어서 수식이 깨질 수 있음
  - 다른 프로그램과의 직렬 날짜 호환성이 깨짐
- 안 고치면 생기는 문제: WEEKDAY 함수가 **1900년 3월 1일 이전** 날짜에 대해서만 잘못된 값을 반환함. 대부분의 사용자가 이 범위의 날짜를 쓸 일이 없으니 사실상 영향 없음

> [!NOTE]
> 2100년 같은 다른 세기 연도는 정확하게 처리함 (윤년 아님으로 올바르게 판단). 오직 1900년만 잘못 처리하는 것. Lotus 1-2-3 호환성이라는 이유로 40년 넘게 유지되고 있는 의도적 버그

## 핵심 포인트

- 1900년은 윤년이 아니지만 Excel은 2월 29일이 존재한다고 가정
- Lotus 1-2-3 호환성을 위해 Microsoft가 동일한 직렬 날짜 체계 채택
- 수정 시 기존 모든 날짜가 1일 밀리고 함수 반환값 변경 → 비용이 더 큼
- 영향 범위는 1900년 3월 1일 이전 날짜의 WEEKDAY 함수뿐

## 인사이트

하위 호환성을 위해 의도적으로 유지하는 버그의 교과서적 사례. 개발자라면 공감할 '고치는 것보다 안 고치는 게 나은' 레거시 이야기.